PIM Designated Router Load Balancing
draft-ietf-pim-drlb-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-04-22
|
15 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-03-27
|
15 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-03-06
|
15 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-01-07
|
15 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-01-06
|
15 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-01-06
|
15 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-01-06
|
15 | (System) | RFC Editor state changed to EDIT |
2020-01-06
|
15 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-01-06
|
15 | (System) | Announcement was received by RFC Editor |
2020-01-03
|
15 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-01-03
|
15 | (System) | IANA Action state changed to In Progress |
2020-01-03
|
15 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-01-03
|
15 | Amy Vezza | IESG has approved the document |
2020-01-03
|
15 | Amy Vezza | Closed "Approve" ballot |
2020-01-03
|
15 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-01-03
|
15 | Alvaro Retana | Ballot approval text was generated |
2020-01-03
|
15 | Stig Venaas | New version available: draft-ietf-pim-drlb-15.txt |
2020-01-03
|
15 | (System) | New version approved |
2020-01-03
|
15 | (System) | Request for posting confirmation emailed to previous authors: Andy Green , Sri Vallepalli , mankamana mishra , Heidi Ou , Yiqun Cai , Stig Venaas |
2020-01-03
|
15 | Stig Venaas | Uploaded new revision |
2020-01-03
|
14 | Benjamin Kaduk | [Ballot comment] Thank you for the updates that address my original Discuss points! At the time of this writing, we're still having a little more … [Ballot comment] Thank you for the updates that address my original Discuss points! At the time of this writing, we're still having a little more discussion in email about some of the specifics of the 32-bit masking procedure, but it seems unlikely to cause problems in practice, and the algorithm selection allows for a fix to be made in the future without needing changes at present (provided that the procedure to apply the mask is clearly specified). |
2020-01-03
|
14 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-12-11
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-12-11
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-12-11
|
14 | Stig Venaas | New version available: draft-ietf-pim-drlb-14.txt |
2019-12-11
|
14 | (System) | New version approved |
2019-12-11
|
14 | (System) | Request for posting confirmation emailed to previous authors: Andy Green , Sri Vallepalli , mankamana mishra , Heidi Ou , Yiqun Cai , Stig Venaas |
2019-12-11
|
14 | Stig Venaas | Uploaded new revision |
2019-12-05
|
13 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-12-04
|
13 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from No Record |
2019-12-04
|
13 | Barry Leiba | [Ballot comment] Some very minor comments: Please expand “PIM-SM” on first use in both the Abstract and the Introduction. This allows the forwarding … [Ballot comment] Some very minor comments: Please expand “PIM-SM” on first use in both the Abstract and the Introduction. This allows the forwarding of multicast packets to be restricted only to segments leading to receivers who have indicated their interest in multicast groups using either IGMP or MLD. Nit: Let’s not personify our devices: please change “who” to “that”. However, if there was a way that allowed multiple routers to forward to the LAN for different groups, failure of one of the Nit: “if there were a way”, subjunctive mood with a conditional. — Section 3 — The extension specified in this document applies to PIM-SM when they act as last hop routers (there are directly connected receivers). I can’t find the antecedent to “they”; what is it? It looks like it’s “PIM-SM”, but that’s not something that can be “they”, is it? Maybe you mean to say “PIM-SM routers”? — Section 4 — For each multicast flow, that is, (*,G) for ASM and (S,G) for SSM, a Hash Algorithm is used to select one of the routers to be the GDR. “Hash Algorithm” might do well to include a forward reference to Section 5.1. |
2019-12-04
|
13 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2019-12-04
|
13 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-12-04
|
13 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-12-03
|
13 | Adam Roach | [Ballot comment] Please consider formatting IPv6 address as per the recommendations in RFC 5952, and section 4.3 of that document (https://tools.ietf.org/html/rfc5952#section-4.3) in … [Ballot comment] Please consider formatting IPv6 address as per the recommendations in RFC 5952, and section 4.3 of that document (https://tools.ietf.org/html/rfc5952#section-4.3) in particular. |
2019-12-03
|
13 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-12-03
|
13 | Roman Danyliw | [Ballot comment] I support Ben Kaduk's DISCUSS position. |
2019-12-03
|
13 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2019-12-03
|
13 | Benjamin Kaduk | [Ballot discuss] I think we need greater clarity on whether the list of GDR candidate addresses is sorted or not (i.e., whether it is required … [Ballot discuss] I think we need greater clarity on whether the list of GDR candidate addresses is sorted or not (i.e., whether it is required for protocol operation), as indicated by the rtgdir reviewer. Specifically, Section 5.3 is clear in the descriptive text that the list is sorted (as if a recipient might rely on that behavior), but Section 5.3.2 and Section 5.4 only have it as RECOMMENDED. Given my understanding of the protocol, it seems that all routers need to receive the DRLB-List in order to perform the GDR selection algorithm, in which case the extra information about the addresses being sorted would not be useful for the calculation. That would actually suggest that we do not need RFC 2119 keywords here, and could just say (as we do in Section 5.4) that it's recommended for the DR to use a deterministic procedure, such as sorting. I also think the text should be more clear in Section 5.3.2 about the use of the Router Identifier as the "GDR Candidate Address". I believe (but am not certain) that the intended behavior is that the elected DR use all the PIM Hellos it has received (from candidate GDRs) to assemble the list of candidate "addresses", but instead of using the actual IP addresses it uses the Router Identifier construction described here when assembling the "GDR Candidate Address(es)" field. The current text leaves unsaid what entity is performing this operation and how the PIM Hello+Router Identifier corresponds to an entry in the list of addresses. Furtheremore, for the IPv6 case, it seems like this substitution procedure interacts very poorly with the masking procedure when the network includes a mix of routers that do/don't send a Router ID (as it may not be possible to set a 32-bit contiguous mask that captures the varying parts of IPv6 router addresses and the space reserved here for "Router ID"). I'm concerned about hash algorithm agility (in the vein of BCP 201, though since this is not a cryptographic hash that BCP does not strictly speaking apply), as the rtg-dir review noted. Specifically, each router has to commit in its Hello to a single hash algorithm, so transitioning to a new algorithm will require accepting reduced functionality during the transition period (a reduced list of potential GDR candidates), which is contrary to the goals of algorithm negotiation espoused in BCP 201. Is this not a significant concern for this use case? I see that Section 6 attempts to disclaim discussion of algorithm migration, but I am not yet convinced that it is appropriate to do so. Please also remove from Section 5.7 the stale statement referring to the previous section (see COMMENT). |
2019-12-03
|
13 | Benjamin Kaduk | [Ballot comment] Thank you for the Backward Compatibility section; it's great to see that covered explicitly! Per the rtg-dir review, please clarify that each router … [Ballot comment] Thank you for the Backward Compatibility section; it's great to see that covered explicitly! Per the rtg-dir review, please clarify that each router advertises at most one Hash Algorithm at any given time (or how a multi-algorithm scenario would work). Limiting the GDR candidates to those with the same (highest) priority as the PIM DR seems like it will in practice encourage having multiple routers advertise the same priority value (if that is not already the case). Are there any operational considerations or risks in having to use the IP-address tie-breaker more often for the non-GDR-capable routers? Section 1 Interesting to 1-index the routers but 0-index the links in Figure 2. Section 3 The extension specified in this document applies to PIM-SM when they act as last hop routers (there are directly connected receivers). It nit: this sentence makes more sense when I insert the word "routers" after "PIM-SM". does not alter the behavior of a PIM DR, or any other routers, on the first hop network (directly connected sources). This is because the source tree is built using the IP address of the sender, not the IP address of the PIM DR that sends the registers towards the RP. The load balancing between first hop routers can be achieved naturally if an IGP provides equal cost multiple paths (which it usually does in practice). Also distributing the load to do registering does not justify the additional complexity required to support it. In this last sentence, does "registering" refer to setting up the sender or the registration of receivers from DR to RP? Section 4 In order to share forwarding load among last hop routers, besides the normal PIM DR election, the GDR is also elected on the multi-access LAN. There is only one PIM DR on the multi-access LAN, but there might be multiple GDR Candidates. nit: this reads as if there is only a single GDR per LAN the same way that there is only one PIM DR. But my understanding is that the GDR is per-group, so perhaps a wording tweak is in order, even given the exposition in the following paragraph. A Hash Algorithm based on the announced Source, Group, or RP masks allows one GDR to be assigned to a corresponding multicast state. And that GDR is responsible for initiating the creation of the multicast forwarding tree for multicast traffic. nit: s/And that/That/ Section 5.1 Do we expect the hash masks to be a contiguous set of bits (i.e., not 0xf0f0f0f0)? The DRLB-List Hello Option contains a list of GDR Candidates. The first one listed has ordinal number 0, the second listed ordinal number 1, and the last one has ordinal number N - 1 if there are N candidates listed. The hash value computed will be the ordinal number of the GDR Candidate that is acting as GDR. nit: I suggest "acting as GDR for the flow in question". I would also consider having some lead-in text to introduce the purpose of the bulleted list that follows, perhaps something like "the input to be hashed is determined according to the following procedure:". Section 5.2 I suspect that the "keeping only the last 32 bits of the result" step could result in pathological behavior for certain IPv6 addressing schemes; this risk should be discussed in the security considerations (or the limitation removed). Presumably any hash algorithm more complicated than modulo would not need this step of trimming down to 32 bits, too? Please define (e.g., by reference to a specific version of the C language) the notation used for these calculations. (I note that the algorithm applied to IPv6 addresses would require a 128-bit unsigned integer type.) Section 5.3 All PIM routers include a new option, called "Load Balancing Capability (DRLB-Cap)" in their PIM Hello messages. nit: I suggest a minor rewording to """PIM routers include a new option, called "Load Balancing Capability (DRLB-Cap)" in their PIM Hello messages, to indicate support for this specification""". (With the current text the reader is responsible for scoping the "All PIM routers" to "ones that implement this specificiation.) Besides this DRLB-Cap Hello Option, the elected PIM DR also includes a new "DR Load Balancing List (DRLB-List) Hello Option". The DRLB- List Hello Option consists of three Hash Masks as defined above and also a sorted list of GDR Candidate addresses on the LAN. Would you mind pointing me at the part of RFC 7761 that describes the procedure/delay used by a router to determine that it is the DR (and thus, when it should start sending DRLB-List)? It's not entirely clear that we'd need to include that reference in this document, but I'd like to sate my curiousity. Section 5.3.1 Hash Algorithm: Hash Algorithm type. 0 for the Modulo algorithm defined in this document. Maybe mention the registry again here? Section 5.3.2 This DRLB-List Hello Option MUST only be advertised by the elected PIM DR. It MUST be ignored if received from a non-DR. The option MUST also be ignored if the hash masks are not the correct number of bits, or GDR Candidate addresses are in the wrong address family. I'm not sure that any of the cases listed in the last sentence are reliably detectable. Section 5.4 the order in which the DR learns of new candidates. Note that, as non-DR routers, the DR also advertises the DRLB-Cap Hello Option to indicate its ability to support the new functionality and the type of GDR election Hash Algorithm. nits: "as for non-DR routers", "the type of GDR election Hash Algorithm it uses" Section 5.6 The requirement in step 1 to run the Hash Algorithm for all groups with local receiver interest seems to imply that all GDR candidates must track and store local receiver interest for all groups, as opposed to without this extension where only the DR strictly needs to do so. I imagine that generally all/most routers will be tracking this information, though, so in practice this will not be an additional operational burden [that would need to be documented]. But this is not my area of expertise, so please correct me if I'm wrong! Section 5.7 When a router stops acting as the GDR for a group, or source and group pair if SSM, it MUST set the Assert metric preference to maximum (0x7FFFFFFF) and the Assert metric to one less than maximum (0xFFFFFFFE). This was also mentioned in the previous section. That This was not mentioned in the previous section. Section 6 An administrator needs to consider what the total bandwidth requirements are and find a set of routers that together has enough total capacity, while making sure that each of the routers can handle its part, assuming that the traffic is distributed roughly equally among the routers. Ideally, one should also have enough bandwidth to In a scenario where an attacker can create groups or control how some amount of traffic is split across groups, this assumption of roughly equal distribution will not hold. Please discuss this in the security considerations. The default masks will use the entire group addresses, and source addresses if SSM, as part of the hash. An administrator may set (side note: of course, the only hash algorithm currently defined will only use the last 32 bits of IPv6 addresses) |
2019-12-03
|
13 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-12-03
|
13 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-12-03
|
13 | Warren Kumari | [Ballot comment] Thank you for this document -- I found it easy to read and helpful. I'd note that the document has 6 authors instead … [Ballot comment] Thank you for this document -- I found it easy to read and helpful. I'd note that the document has 6 authors instead of the "recommended" 5 -- I don't care, just noting it. Also, please see the OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-pim-drlb-13-opsdir-lc-clarke-2019-10-30/ ) for some useful editorial fixes. |
2019-12-03
|
13 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-12-03
|
13 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-12-03
|
13 | Mirja Kühlewind | [Ballot comment] Please have a look at the TSV-ART review, there is an editorial suggestion that might be worth considering (and thanks Michael for the … [Ballot comment] Please have a look at the TSV-ART review, there is an editorial suggestion that might be worth considering (and thanks Michael for the TSV-ART review!). |
2019-12-03
|
13 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-12-02
|
13 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2019-12-01
|
13 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. The short document is easy to read. I have one COMMENT and one NIT … [Ballot comment] Thank you for the work put into this document. The short document is easy to read. I have one COMMENT and one NIT below, feel free to ignore them. Regards, -éric == COMMENT == -- Section 5.1 -- Some more explanations about "These default values are likely acceptable" would be welcome. == NIT == -- Section 1 -- s/ on behalf of any local members/on behalf of all local members/ ? |
2019-12-01
|
13 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-11-29
|
13 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-11-14
|
13 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Carl Wallace. Submission of review completed at an earlier date. |
2019-11-09
|
13 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Carl Wallace. |
2019-11-07
|
13 | Amy Vezza | Placed on agenda for telechat - 2019-12-05 |
2019-11-07
|
13 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-11-07
|
13 | Alvaro Retana | Ballot has been issued |
2019-11-07
|
13 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2019-11-07
|
13 | Alvaro Retana | Created "Approve" ballot |
2019-11-07
|
13 | Alvaro Retana | Ballot writeup was changed |
2019-11-07
|
13 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-11-06
|
13 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2019-11-06
|
13 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-pim-drlb-13. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-pim-drlb-13. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the PIM-Hello Options registry on the Protocol Independent Multicast (PIM) Parameters page located at: https://www.iana.org/assignments/pim-parameters/ the early allocations of type 34 for the PIM DR Load Balancing Capability (DRLB-Cap) Hello Option, and type 35 for the PIM DR Load Balancing List (DRLB-List) Hello Option will be made permanent and their references changed to [ RFC-to-be ]. Second, a new registry is to be created called the Designated Router Load Balancing Hash Algorithms registry. The new registry will be located on the Protocol Independent Multicast (PIM) Parameters page located at: https://www.iana.org/assignments/pim-parameters/ New registrations in the new registry will be made via IETF Review as defined by RFC 8126. There are initial registrations in the new registry as follows: Type Name Reference ---- ------------- -------------- 0 Modulo [ RFC-to-be ] 1-255 Unassigned The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-11-05
|
13 | Pete Resnick | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Pete Resnick. Sent review to list. |
2019-11-05
|
13 | Ben Niven-Jenkins | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Ben Niven-Jenkins. Sent review to list. |
2019-10-30
|
13 | Joe Clarke | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Joe Clarke. Sent review to list. |
2019-10-29
|
13 | Michael Scharf | Request for Last Call review by TSVART Completed: Ready. Reviewer: Michael Scharf. Sent review to list. |
2019-10-28
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2019-10-28
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2019-10-27
|
13 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Michael Scharf |
2019-10-27
|
13 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Michael Scharf |
2019-10-25
|
13 | Min Ye | Request for Last Call review by RTGDIR is assigned to Ben Niven-Jenkins |
2019-10-25
|
13 | Min Ye | Request for Last Call review by RTGDIR is assigned to Ben Niven-Jenkins |
2019-10-25
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2019-10-25
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2019-10-24
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2019-10-24
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2019-10-24
|
13 | Alvaro Retana | Requested Last Call review by RTGDIR |
2019-10-24
|
13 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-10-24
|
13 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-11-07): From: The IESG To: IETF-Announce CC: draft-ietf-pim-drlb@ietf.org, mmcbride7@gmail.com, pim-chairs@ietf.org, pim@ietf.org, aretana.ietf@gmail.com … The following Last Call announcement was sent out (ends 2019-11-07): From: The IESG To: IETF-Announce CC: draft-ietf-pim-drlb@ietf.org, mmcbride7@gmail.com, pim-chairs@ietf.org, pim@ietf.org, aretana.ietf@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (PIM Designated Router Load Balancing) to Proposed Standard The IESG has received a request from the Protocols for IP Multicast WG (pim) to consider the following document: - 'PIM Designated Router Load Balancing' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2019-11-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract On a multi-access network, one of the PIM-SM routers is elected as a Designated Router. One of the responsibilities of the Designated Router is to track local multicast listeners and forward data to these listeners if the group is operating in PIM-SM. This document specifies a modification to the PIM-SM protocol that allows more than one of the PIM-SM routers to take on this responsibility so that the forwarding load can be distributed among multiple routers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pim-drlb/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pim-drlb/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1713/ |
2019-10-24
|
13 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-10-24
|
13 | Alvaro Retana | Last call was requested |
2019-10-24
|
13 | Alvaro Retana | Ballot approval text was generated |
2019-10-24
|
13 | Alvaro Retana | Ballot writeup was generated |
2019-10-24
|
13 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-10-24
|
13 | Alvaro Retana | Last call announcement was generated |
2019-10-24
|
13 | Alvaro Retana | Changed consensus to Yes from Unknown |
2019-10-24
|
13 | Stig Venaas | New version available: draft-ietf-pim-drlb-13.txt |
2019-10-24
|
13 | (System) | New version approved |
2019-10-24
|
13 | (System) | Request for posting confirmation emailed to previous authors: Andy Green , Sri Vallepalli , mankamana mishra , Heidi Ou , Yiqun Cai , Stig Venaas |
2019-10-24
|
13 | Stig Venaas | Uploaded new revision |
2019-10-23
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-10-23
|
12 | Stig Venaas | New version available: draft-ietf-pim-drlb-12.txt |
2019-10-23
|
12 | (System) | New version approved |
2019-10-23
|
12 | (System) | Request for posting confirmation emailed to previous authors: Andy Green , Sri Vallepalli , mankamana mishra , Heidi Ou , Yiqun Cai , Stig Venaas |
2019-10-23
|
12 | Stig Venaas | Uploaded new revision |
2019-10-18
|
11 | Alvaro Retana | === AD Review of draft-ietf-pim-drlb-11 === https://mailarchive.ietf.org/arch/msg/pim/jmnAu-EIa2nDIE-SoLu87BBSYkA |
2019-10-18
|
11 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2019-10-11
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-10-11
|
11 | Stig Venaas | New version available: draft-ietf-pim-drlb-11.txt |
2019-10-11
|
11 | (System) | New version approved |
2019-10-11
|
11 | (System) | Request for posting confirmation emailed to previous authors: Andy Green , Sri Vallepalli , pim-chairs@ietf.org, mankamana mishra , Yiqun Cai , Heidi Ou , … Request for posting confirmation emailed to previous authors: Andy Green , Sri Vallepalli , pim-chairs@ietf.org, mankamana mishra , Yiqun Cai , Heidi Ou , Stig Venaas |
2019-10-11
|
11 | Stig Venaas | Uploaded new revision |
2019-06-24
|
10 | Alvaro Retana | === AD Review of draft-ietf-pim-drlb-10 === https://mailarchive.ietf.org/arch/msg/pim/8eyqWap1Xnohlp_ZAhvCZ3Qttw4 |
2019-06-21
|
10 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2019-06-05
|
10 | Alvaro Retana | Notification list changed to aretana.ietf@gmail.com |
2019-06-05
|
10 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2019-02-15
|
10 | Alvaro Retana | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. Standards Track is indicated on the draft and is appropriate particularly with the new PIM Hello Option Types being assigned to DRLB. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary On a multi-access network, one of the PIM routers is elected as a Designated Router (DR). On the last hop network, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operating in PIM-SM. In this document, we propose a modification to the PIM-SM protocol that allows more than one of these last hop routers to be selected so that the forwarding load can be distributed among these routers. Working Group Summary There was very thorough review by the WG particularly by one of the WG members. There were many comments and all were addressed to this individuals (and the lists) satisfaction. Alia, AD at the time, had a long list of issues. The authors took a few years to address them... Last year, Mankamana and Stig decided it was time to have this published and revised the draft based on her comments. There has since been good wg review and consensus to finally move it forward. We may not be fast but at least we are slow. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Cisco has an implementation of this protocol. No other vendors have indicated plan to implement the specification but they support publication of this draft. The only reviewers were from the PIM WG and were very thorough. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Mike McBride is the document shepherd and Alvaro Retana is the responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. This version is ready for publication and has been reviewed by the shepherd and the co-chair. For years. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. Very thorough reviews were performed with extensive comments. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, there is IPR and it has been declared with #1713. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes, IPR has been declared and the WG has been notified. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document as a whole has been understood but, to be fair, there were only a few vocal individuals who helped thoroughly review the document. Non cisco individuals. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No other formal review other then the PIM WG and AD. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Referenced IANA registries have been clearly identified and the Hello options have been assigned. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Two new PIM Hello Option Types have been assigned to the DR Load Balancing messages. [HELLO-OPT], this document recommends 34(0x22) as the new "PIM DR Load Balancing Capability Hello Option", and 35(0x23) as the new "PIM DR Load Balancing GDR Hello Option". (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A |
2019-02-15
|
10 | Alvaro Retana | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-02-15
|
10 | Alvaro Retana | IESG state changed to Publication Requested from AD is watching |
2019-01-15
|
10 | Alvaro Retana | IESG state changed to AD is watching from Dead |
2019-01-14
|
10 | Mike McBride | Tag Doc Shepherd Follow-up Underway set. Tag Revised I-D Needed - Issue raised by AD cleared. |
2019-01-14
|
10 | Mike McBride | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2019-01-14
|
10 | Mike McBride | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. Standards Track is indicated on the draft and is appropriate particularly with the new PIM Hello Option Types being assigned to DRLB. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary On a multi-access network, one of the PIM routers is elected as a Designated Router (DR). On the last hop network, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operating in PIM-SM. In this document, we propose a modification to the PIM-SM protocol that allows more than one of these last hop routers to be selected so that the forwarding load can be distributed among these routers. Working Group Summary There was very thorough review by the WG particularly by one of the WG members. There were many comments and all were addressed to this individuals (and the lists) satisfaction. Alia, AD at the time, had a long list of issues. The authors took a few years to address them... Last year, Mankamana and Stig decided it was time to have this published and revised the draft based on her comments. There has since been good wg review and consensus to finally move it forward. We may not be fast but at least we are slow. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Cisco has an implementation of this protocol. No other vendors have indicated plan to implement the specification but they support publication of this draft. The only reviewers were from the PIM WG and were very thorough. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Mike McBride is the document shepherd and Alvaro Retana is the responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. This version is ready for publication and has been reviewed by the shepherd and the co-chair. For years. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. Very thorough reviews were performed with extensive comments. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, there is IPR and it has been declared with #1713. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes, IPR has been declared and the WG has been notified. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document as a whole has been understood but, to be fair, there were only a few vocal individuals who helped thoroughly review the document. Non cisco individuals. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No other formal review other then the PIM WG and AD. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Referenced IANA registries have been clearly identified and the Hello options have been assigned. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Two new PIM Hello Option Types have been assigned to the DR Load Balancing messages. [HELLO-OPT], this document recommends 34(0x22) as the new "PIM DR Load Balancing Capability Hello Option", and 35(0x23) as the new "PIM DR Load Balancing GDR Hello Option". (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A |
2018-11-13
|
10 | Stig Venaas | New version available: draft-ietf-pim-drlb-10.txt |
2018-11-13
|
10 | (System) | New version approved |
2018-11-13
|
10 | (System) | Request for posting confirmation emailed to previous authors: Andy Green , Sri Vallepalli , pim-chairs@ietf.org, mankamana mishra , Yiqun Cai , Heidi Ou , … Request for posting confirmation emailed to previous authors: Andy Green , Sri Vallepalli , pim-chairs@ietf.org, mankamana mishra , Yiqun Cai , Heidi Ou , Stig Venaas |
2018-11-13
|
10 | Stig Venaas | Uploaded new revision |
2018-10-22
|
09 | Stig Venaas | New version available: draft-ietf-pim-drlb-09.txt |
2018-10-22
|
09 | (System) | New version approved |
2018-10-22
|
09 | (System) | Request for posting confirmation emailed to previous authors: Andy Green , Sri Vallepalli , pim-chairs@ietf.org, mankamana mishra , Yiqun Cai , Heidi Ou , … Request for posting confirmation emailed to previous authors: Andy Green , Sri Vallepalli , pim-chairs@ietf.org, mankamana mishra , Yiqun Cai , Heidi Ou , Stig Venaas |
2018-10-22
|
09 | Stig Venaas | Uploaded new revision |
2018-07-13
|
08 | Stig Venaas | Added to session: IETF-102: pim Tue-1550 |
2018-06-19
|
08 | Mankamana Mishra | New version available: draft-ietf-pim-drlb-08.txt |
2018-06-19
|
08 | (System) | New version approved |
2018-06-19
|
08 | (System) | Request for posting confirmation emailed to previous authors: Andy Green , Sri Vallepalli , pim-chairs@ietf.org, mankamana mishra , Yiqun Cai , Heidi Ou , … Request for posting confirmation emailed to previous authors: Andy Green , Sri Vallepalli , pim-chairs@ietf.org, mankamana mishra , Yiqun Cai , Heidi Ou , Stig Venaas |
2018-06-19
|
08 | Mankamana Mishra | Uploaded new revision |
2018-03-27
|
07 | Alvaro Retana | Shepherding AD changed to Alvaro Retana |
2018-01-16
|
07 | Mankamana Mishra | New version available: draft-ietf-pim-drlb-07.txt |
2018-01-16
|
07 | (System) | New version approved |
2018-01-16
|
07 | (System) | Request for posting confirmation emailed to previous authors: Andy Green , Sri Vallepalli , pim-chairs@ietf.org, mankamana mishra , Yiqun Cai , Heidi Ou , … Request for posting confirmation emailed to previous authors: Andy Green , Sri Vallepalli , pim-chairs@ietf.org, mankamana mishra , Yiqun Cai , Heidi Ou , Stig Venaas |
2018-01-16
|
07 | Mankamana Mishra | Uploaded new revision |
2017-12-30
|
06 | (System) | Document has expired |
2017-11-08
|
06 | Stig Venaas | Added to session: IETF-100: pim Tue-0930 |
2017-06-28
|
06 | Mankamana Mishra | New version available: draft-ietf-pim-drlb-06.txt |
2017-06-28
|
06 | (System) | New version approved |
2017-06-28
|
06 | (System) | Request for posting confirmation emailed to previous authors: Andy Green , Sri Vallepalli , pim-chairs@ietf.org, Yiqun Cai , Heidi Ou |
2017-06-28
|
06 | Mankamana Mishra | Uploaded new revision |
2015-10-14
|
05 | (System) | Notify list changed from pim-chairs@ietf.org, draft-ietf-pim-drlb@ietf.org to (None) |
2015-02-14
|
05 | (System) | Document has expired |
2015-02-14
|
05 | (System) | IESG state changed to Dead from AD is watching |
2015-02-13
|
05 | Alia Atlas | Tag Revised I-D Needed - Issue raised by AD set. Tag Revised I-D Needed cleared. |
2015-02-13
|
05 | Alia Atlas | IETF WG state changed to WG Document from Submitted to IESG for Publication |
2015-02-13
|
05 | Alia Atlas | Returning to WG after 3 months for improvements. |
2015-02-13
|
05 | Alia Atlas | IESG state changed to AD is watching::Revised I-D Needed from AD Evaluation::Revised I-D Needed |
2014-11-06
|
05 | Alia Atlas | Much clearer specifics needed for describing the intended behavior. |
2014-11-06
|
05 | Alia Atlas | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2014-07-03
|
05 | Heidi Ou | New version available: draft-ietf-pim-drlb-05.txt |
2014-07-02
|
04 | Cindy Morgan | Intended Status changed to Proposed Standard from None |
2014-07-01
|
04 | Mike McBride | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. Standards Track is indicated on the draft and is appropriate particularly with the new PIM Hello Option Types being assigned to DRLB. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary On a multi-access network, one of the PIM routers is elected as a Designated Router (DR). On the last hop network, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operating in PIM-SM. In this document, we propose a modification to the PIM-SM protocol that allows more than one of these last hop routers to be selected so that the forwarding load can be distributed among these routers. Working Group Summary There was very thorough review by the WG particularly by one of the WG members. There were many comments and all were addressed to this individuals (and the lists) satisfaction. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Cisco has an implementation of this protocol. No other vendors have indicated plan to implement the specification but they support publication of this draft. The only reviewers were from the PIM WG and were very thorough. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Mike McBride is the documet shepherd and Adrian Farrel is the responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. This version is ready for publication and has been reviewed by the shepherd and the co-chair. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. Very thorough reviews were performed with extensive comments. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, there is IPR and it has been declared with #1713. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes, IPR has been declared and the WG has been notified. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document as a whole has been understood but, to be fair, there were only a few vocal individuals who helped thoroughly review the document. Non cisco individuals. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No other formal review other then the PIM WG. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Referenced IANA registries have been clearly identified and the Hello options have been assigned. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Two new PIM Hello Option Types have been assigned to the DR Load Balancing messages. [HELLO-OPT], this document recommends 34(0x22) as the new "PIM DR Load Balancing Capability Hello Option", and 35(0x23) as the new "PIM DR Load Balancing GDR Hello Option". (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A |
2014-07-01
|
04 | Mike McBride | Document shepherd changed to Mike McBride |
2014-07-01
|
04 | Mike McBride | State Change Notice email list changed to pim-chairs@tools.ietf.org, draft-ietf-pim-drlb@tools.ietf.org |
2014-07-01
|
04 | Mike McBride | Responsible AD changed to Alia Atlas |
2014-07-01
|
04 | Mike McBride | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2014-07-01
|
04 | Mike McBride | IESG state changed to Publication Requested |
2014-07-01
|
04 | Mike McBride | IESG process started in state Publication Requested |
2014-06-11
|
04 | Heidi Ou | New version available: draft-ietf-pim-drlb-04.txt |
2014-02-14
|
03 | Heidi Ou | New version available: draft-ietf-pim-drlb-03.txt |
2013-02-25
|
02 | Heidi Ou | New version available: draft-ietf-pim-drlb-02.txt |
2012-03-25
|
01 | Heidi Ou | New version available: draft-ietf-pim-drlb-01.txt |
2012-03-12
|
(System) | Posted related IPR disclosure: Cisco Systems' Statement about IPR related to draft-ietf-pim-drlb-00 | |
2012-03-06
|
00 | Heidi Ou | New version available: draft-ietf-pim-drlb-00.txt |