Skip to main content

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