LDP IGP Synchronization for Broadcast Networks
draft-ietf-mpls-ldp-igp-sync-bcast-06

[Ballot comment]
The security considerations text states (in its entirety)

  This document does not introduce any new security considerations
  beyond those already described in [LDP-IGP-SYNC].

This is not clear to most readers, but the authors provided excellent rationale for this statement in discussions
with the Secdir reviewer.  It would be helpful, IMHO, to add that rationale to the security considerations section.

UPDATED Document Writeup

Updates as a result of discussions with authors, shepherd, WG chairs, and as the result of document updates.

-------------------------------------------------
Writeup for draft-ietf-mpls-ldp-igp-sync-bcast-04
-------------------------------------------------

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Martin Vigoureux (martin.vigoureux@alcatel-lucent.com), MPLS WG Secretary, is the Document Shepherd for draft-ietf-mpls-ldp-igp-sync-bcast.

The Document Shepherd personally reviewed the Document and believes
this version (02) is ready for forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document received relatively light comments during Working Group
Last Call, but was previously discussed on the mailing list and in private emails.

The Document Shepherd believes that the Document has had adequate review.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

The Document Shepherd does not have concerns on these matters.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues 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.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

The Document Shepherd does not have any issue nor concern with the Document.

An IPR discloure exists for draft-lu-ldp-igp-sync-bcast that was
replaced by draft-ietf-mpls-ldp-igp-sync-bcast:
https://datatracker.ietf.org/ipr/1123/
This was not discussed on the mailing list.

  (1.e)  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?

There has been plenty of oportunity to comment on the document.

The low level of comments is put down to a relatively low interest in the work, and the fact that the solution is simple.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No strong or extreme position was raised against the Document.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

The 04 version is clean in idnits.

The Document does not contain content that would need specific review,
beyond what has already been done up to now.

  (1.h)  Has the document split its references into normative and
          informative?  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
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The Document has two References Sections (Normative and Informative).

The authors beleive that RFC5443 is already implemented in several products across several vendors, and that the typical case when a vendor would use the techniques described in this document is to avoid the problems of applying RFC5443 techniques for broadcast interfaces while continuing to apply the RFC5443 techniques for non-broadcast interfaces.

Further, also one must 'read and understand the implementation of RFC5443' before implementing the draft to be sure that the two solutions
can co-exist in the network simultaneously (though on separate interface types).

Please note also that RFC 5443 is Informational.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The Document has an appropriate IANA Secion. The Document does not
specify protocol extensions.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

No section of the Document is written -and would need to be written- in
a given formal language.

  (1.k)  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-

LDP IGP Synchronization ([RFC5443]) describes a mechanism to
prevent black-holing traffic (e.g. VPN) when an interior gateway
protocol (IGP) is operational on a link but Label Distribution
Protocol (LDP) is not. If this mechanism is applied to broadcast
links that have more than one LDP/IGP peer, the cost-out
procedure can only be applied to the link as a whole but not an
individual peer. When a new LDP peer comes up on a broadcast
network, this can result in loss of traffic through other
established peers on that network. This document describes a
mechanism to address that use-case without dropping traffic. The
mechanism does not introduce any protocol changes.

- Working Group Summary-

Nothing worth noting.

-Document Quality-

This is an Informational document.

This is not a protocol extension but implementations that utilize the descibed mechanism are believed to exist.

The document quality is good as well as the review.

-Personnel-

Martin Vigoureux is the Document Shepherd
Adrian Farrel is the responsible Area Director

UPDATED Document Writeup

Updates as a result of discussions with authors, shepherd, WG chairs, and as the result of document updates.

-------------------------------------------------
Writeup for draft-ietf-mpls-ldp-igp-sync-bcast-04
-------------------------------------------------

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Martin Vigoureux (martin.vigoureux@alcatel-lucent.com), MPLS WG Secretary, is the Document Shepherd for draft-ietf-mpls-ldp-igp-sync-bcast.

The Document Shepherd personally reviewed the Document and believes
this version (02) is ready for forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document received relatively light comments during Working Group
Last Call, but was previously discussed on the mailing list and in private emails.

The Document Shepherd believes that the Document has had adequate review.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

The Document Shepherd does not have concerns on these matters.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues 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.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

The Document Shepherd does not have any issue nor concern with the Document.

An IPR discloure exists for draft-lu-ldp-igp-sync-bcast that was
replaced by draft-ietf-mpls-ldp-igp-sync-bcast:
https://datatracker.ietf.org/ipr/1123/
This was not discussed on the mailing list.

  (1.e)  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?

There has been plenty of oportunity to comment on the document.

The low level of comments is put down to a relatively low interest in the work, and the fact that the solution is simple.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No strong or extreme position was raised against the Document.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

The 04 version is clean in idnits.

The Document does not contain content that would need specific review,
beyond what has already been done up to now.

  (1.h)  Has the document split its references into normative and
          informative?  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
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The Document has two References Sections (Normative and Informative).

The authors beleive that RFC5443 is already implemented in several products across several vendors, and that the typical case when a vendor would use the techniques described in this document is to avoid the problems of applying RFC5443 techniques for broadcast interfaces while continuing to apply the RFC5443 techniques for non-broadcast interfaces.

Further, also one must 'read and understand the implementation of RFC5443' before implementing the draft to be sure that the two solutions
can co-exist in the network simultaneously (though on separate interface types).

Please note also that RFC 5443 is Informational.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The Document has an appropriate IANA Secion. The Document does not
specify protocol extensions.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

No section of the Document is written -and would need to be written- in
a given formal language.

  (1.k)  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-

LDP IGP Synchronization ([RFC5443]) describes a mechanism to
prevent black-holing traffic (e.g. VPN) when an interior gateway
protocol (IGP) is operational on a link but Label Distribution
Protocol (LDP) is not. If this mechanism is applied to broadcast
links that have more than one LDP/IGP peer, the cost-out
procedure can only be applied to the link as a whole but not an
individual peer. When a new LDP peer comes up on a broadcast
network, this can result in loss of traffic through other
established peers on that network. This document describes a
mechanism to address that use-case without dropping traffic. The
mechanism does not introduce any protocol changes.

- Working Group Summary-

Nothing worth noting.

-Document Quality-

This is an Informational document.

This is not a protocol extension but implementations that utilize the descibed mechanism are believed to exist.

The document quality is good as well as the review.

-Personnel-

Martin Vigoureux is the Document Shepherd
Adrian Farrel is the responsible Area Director

AD Review

Hi,

Don't panic!

I have performed my AD review of your draft. The purpose of the
review is to catch any nits or issues before the document goes
forward to IETF last call and IESG review. By getting these issues
out at this stage we can hope for a higher quality review and a
smoother passage through the process.

The draft looks pretty good to me, and what I have found are
basically simple questions of understanding. If you are able to
answer my questions, then it would help to make changes/additions
to the text to save you having to handle the same quesitons again.

I think my comments will be easy for you to address in a new
revision of the draft. None of the comments is mandatory: all are
open for discussion.

I have moved the draft into "AD-review:Revised-ID-needed" state in
the datatracker, and I look forward to seeing the new revision which
I can put forward for IETF last call.

Thanks,
Adrian

---

Please remove the reference citation from the Abstract. (Abstracts
have to be standalone pieces of text.)

I suggest
OLD
    LDP IGP Synchronization ([LDP-IGP-SYNC]) describes a mechanism to
NEW
    LDP IGP Synchronization is a mechanism to

---

Abstract

Is the term "cost-out procedure" widely known?
Would the Abstract be clearer if you explained it?

---

As clearly stated in the Abstract, this document does not introduce
any protocol changes. In view of this, I wondered why it is Standards
Track. Wouldn't it be better targetted as a BCP (if it affects how
the network operates) or Informational (if it is advice to
implementers)?

Given that RFC 5443 is Informational, and this document describes
procedures for operating LDP Synch in certain topologies, I would
have thought this I-D would be Informational as well.

What is the morivation for this being Standards Track?

---

Thanks to Martin for pointing out the Downref in the shephers write-up.

This is obviously linked to the previous point.
We can handle the Downref if necessary, but usually the existence of a
Downref is a red flag; it warns us that there is something out of phase.

---

It feels to me that [LDP] should be a normative reference. None of this
document makes sense in the absence of LDP.

I suspect that [OSPF] and [ISIS] are similarly normative.

---

Section 4

Question. How are LDP messages between two routers routed if the
routers have not advertised themselves in the IGP (because they are
waiting for LDP to come up)?

---

Section 4

You have some "must not" etc. in this section. Are you sure you
should not use RFC 2119 language?

-------------------------------------------------
Writeup for draft-ietf-mpls-ldp-igp-sync-bcast-02
-------------------------------------------------

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Martin Vigoureux (martin.vigoureux@alcatel-lucent.com), MPLS WG Secretary,
is the Document Shepherd for draft-ietf-mpls-ldp-igp-sync-bcast.
The Document Shepherd personally reviewed the Document and believes
this version (02) is ready for forwarding to the IESG for publication.


  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document was appropriately discussed during Working Group Last Call.
The Document Shepherd believes that the Document has had adequate review.


  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

The Document Shepherd does not have concerns on these matters.


  (1.d)  Does the Document Shepherd have any specific concerns or
          issues 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.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

The Document Shepherd does not have any issue nor concern with the Document.
An IPR discloure exists for draft-lu-ldp-igp-sync-bcast that was replaced by
draft-ietf-mpls-ldp-igp-sync-bcast:
https://datatracker.ietf.org/ipr/1123/
This was not discussed.


  (1.e)  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?

While the document was appropriately discussed during Working Group Last Call,
the poll for Working Group adoption has shown less attraction.


  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No strong or extreme position was raised against the Document.


  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

There is one oustanding error:
  ** Downref: Normative reference to an Informational RFC: RFC 5443 (ref.
    'LDP-IGP-SYNC'), this needs to be indicated in the IETF last call.

The Document does not contain content that would need specific review,
beyond what has already been done up to now.


  (1.h)  Has the document split its references into normative and
          informative?  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
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The Document has two References Sections (Normative and Informative).

There is one normative downward reference (to RFC 5443).

The authors beleive that RFC5443 is already implemented in several products
across several vendors, and that the typical case when a vendor would implement
draft-ietf-mpls-ldp-igp-sync-bcast is to to undo the erroneous solution
of RFC5443 for broadcast interfaces and implement the draft while retaining
the RFC5443 solution for non-broadcast interfaces.
Further, also one must 'read and understand the implementation of RFC5443'
before implementing the draft to be sure that the two solutions
can co-exist in the network simultaneously (though on separate interface types).

Please note also that while RFC 5443 is Informational, this Document is
Standard Track.



  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The Document has an appropriate IANA Secion. The Document does not
specify protocol extensions. The Document is Standard Track.


  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

No section of the Document is written -and would need to be written- in
a given formal language.


  (1.k)  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
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

LDP IGP Synchronization ([LDP-IGP-SYNC]) describes a mechanism to
prevent black-holing traffic (e.g. VPN) when an interior gateway
protocol (IGP) is operational on a link but Label Distribution
Protocol (LDP) is not. If this mechanism is applied to broadcast
links that have more than one LDP/IGP peer, the cost-out
procedure can only be applied to the link as a whole but not an
individual peer. When a new LDP peer comes up on a broadcast
network, this can result in loss of traffic through other
established peers on that network. This document describes a
mechanism to address that use-case without dropping traffic. The
mechanism does not introduce any protocol changes.


          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

Nothing worth noting, except for the level of interest expressed during
the poll for Working Group adoption.


          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?

This is not a protocol extension but implementations of the descibed mechanism
may exist.
The document quality is good as well as the review.


          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

Martin Vigoureux is the Document Shepherd
Adrian Farrel is the responsible Area Director