Presentation is loading. Please wait.

Presentation is loading. Please wait.

RFC 4601 Revision Prague, March 2011 Rishabh Parekh (Cisco)

Similar presentations


Presentation on theme: "RFC 4601 Revision Prague, March 2011 Rishabh Parekh (Cisco)"— Presentation transcript:

1 RFC 4601 Revision Prague, March 2011 Rishabh Parekh (Cisco)
Jeffrey Zhang (Juniper) Vero Zheng (Huawei)

2 Motivations Advancing PIM specification from Proposed Standard to Draft Standard Address about 100 open errata Identify optional features that do not meet the following requirements per RFC 2026: at least two independent & interoperable implementations From different code bases sufficient & successful operational experience

3 Work & Plan -00 draft in 2~3 weeks
With all verified errata corrected -01 draft with certain optional features removed before July meeting Per consensus on the mailing list Implementation/deployment survey required Adopted as WG draft in July meeting?

4 Errata: Reference & Past Effort
Reported/Verified/Rejected/Held-for-update Stig’s swag in November, 2009 Stig’s presentation in March, 2010 meeting Bill’s response in March, 2010

5 Errata: On-going Effort
Three volunteers from Cisco/Huawei/Juniper Went through all the errata and past discussions No real technical errors A brief report Reasons for rejections One open issue: 1161 Feedback really important!

6 Optional Features Candidates Survey: vendors and operators
(*,*,RP) and Border bit for PIM registers Explicit tracking Group to RP mappings Referring to the new group-to-rp mapping RFC? Hashing - for BSR only or static as well, or nothing at all? Survey: vendors and operators Implementations & Deployments Operational experiences

7 Request For Comments! Your involvement and feedback are very important
Past effort by Stig/Bill have not got much responses The RFC advancement needs to proceed The 2+3 party have got consensus on the errata Stig/Bill + Rishabh/Jeffrey/Vero Would prefer to get more feedback Optional feature discussion/survey needs wider involvement

8 Errata 1161 (1/2) Section 4.5.6 says:
bool JoinDesired(*,G) { if (immediate_olist(*,G) != NULL OR (JoinDesired(*,*,RP(G)) AND AssertWinner(*, G, RPF_interface(RP(G))) != NULL)) return TRUE else return FALSE } JoinDesired(*,G) is true when the router has forwarding state that would cause it to forward traffic for G using shared tree state. Question: When would immediate_olist(*,G) be NULL and forwarding state exist? Answer: When there is a (*, *, RP) join

9 Errata 1161 (2/2) Our follow-up question:
Why would we want to send a (*, G) join, if we only have a (*, *, RP) join but no (*, G) join downstream, even if there is a (*, G) assert winner?


Download ppt "RFC 4601 Revision Prague, March 2011 Rishabh Parekh (Cisco)"

Similar presentations


Ads by Google