Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths
draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09

[Ballot comment]


The RFC editor might do this for you but I can't remember: to avoid a trivial errata (and yes we get these) please consider re-ordering the RFC references numbers to be lowest # to highest #.

[Ballot comment]

The RFC editor might do this for you but I can't remember: to avoid a trivial errata (and yes we get these) please consider re-ordering the RFC references numbers to be lowest # to highest #.

[Ballot comment]
1) The abstract contains the RFC2119 conventions text, including references. This should be in the main body of the text, not the abstract.

2) in 2.4, I think the text could be clearer that the notify message only supplements the path error. It is not used INSTEAD of the path error message.

3) IANA is requested to assign a new error subcode, but the text (2.4) never mentions the use of the IANA-assigned value.

[Ballot comment]
RRO is used a couple of times before being expanded

The secdir reviewer asked a question [1] to which I didn't
see an answer but it doesn't look like it warrants a
discuss.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg02855.html

IANA understands that, upon approval of this document, there are three
IANA actions which need to be completed.

First, in the Attribute Flags registry of the Resource Reservation
Protocol-Traffic Engineering (RSVP-TE) Parameters registry located at:

http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.xml

a new Attribute Flag will be registered as follows:

Bit number: [ tbd ]
Name: Non Penultimate Hop Popping Behavior
Attribute Flags Path: Yes
Attribute Flags Resv: No
RRO: Yes
Reference: [ RFC-to-be ]

Second, also in the Attribute Flags registry of the Resource Reservation
Protocol-Traffic Engineering (RSVP-TE) Parameters registry located at:

http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.xml

another new Attribute Flag will be registered as follows:

Bit number: [ tbd ]
Name: Out of Band Mapping
Attribute Flags Path: Yes
Attribute Flags Resv: No
RRO: Yes
Reference: [ RFC-to-be ]

Third, in the Sub-Codes ‒ 25 Notify Error subregistry of the Error Codes
and Globally-Defined Error Value Sub-Codes registry for RSVP located at:

http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml

The following new subcode will be assigned as follows:

Value: [ tbd ]
Description: No OOB mapping received
Reference: [ RFC-to-be ]

IANA understands that these are the only actions that need to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Non Penultimate Hop Popping Behavior and out-of-band mapping for RSVP-TE Label Switched Paths) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Non Penultimate Hop Popping Behavior and out-of-band mapping for RSVP-
  TE Label Switched Paths'
  as a 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
ietf@ietf.org mailing lists by 2011-08-12. 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

      There are many deployment scenarios which require Egress Label
      Switching Router (LSR) to receive binding of the Resource
      ReserVation Protocol Traffic Engineered (RSVP-TE) Label Switched
      Path (LSP) to an application, and payload identification, using
      some "out-of-band" (OOB) mechanism. This document defines
      protocol mechanisms to address this requirement. The procedures
      described in this document are equally applicable for point-to-
      point (P2P) and point-to-multipoint (P2MP) LSPs.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-te-no-php-oob-mapping/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-te-no-php-oob-mapping/


No IPR declarations have been submitted directly on this I-D.

This document makes a DownRef in the form of a Normative reference to an Informational RFC: RFC 5920

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
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.

I found number of small issues and questions. These are mainly
concerns with clarity, and editorial issues.

All of my comments are up for discussion, and you should not feel
rail-roaded into making changes. But I do think my comments need to be                   
addressed before this document is presented for IETF last call, and
I would like you to have a look and see whether you can work to improve
the text before I take it forward.

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

---

It would be best to expand the acronyms PHP and LSP in the document
title.

---

Acronyms need to be expanded on first use in the main body of the text.   
The Abstract should be seen as stand-alone, and you have to start
expanding them again. I find:

RSVP-TE
MVPN
VPLS
LSR
LSP

---

Please decide between "out-of-band" and "out of band" and update the
document accordingly.

---

Abstract

s/proposes/defines/

---

Section 2.1   

  When signaling a P2MP LSP, a source node may wish to solicit
  individual response to "non-PHP behavior flag" from the leaf
  nodes. Given the constraints on how the LSP_ATTRIBUTES may be
  carried in Path and Resv Messages according to RFC5420, in this
  situation a source node MUST use a separate Path message for
  each leaf.

This is wrong, isn't it?

P2MP signaling is defined in RFC 4875. That document clearly describes
how LSP_ATTRIBUTES are used in the P2MP case. You have the RRO flags
available to record egress LSR behavior.

The same issue arrises in Section 2.2.

---

Section 2.1

      If the egress LSR 

      - supports the LSP_ATTRIBUTES object but does not recognize the
        Attributes Flags TLV; or 

      - supports the LSP_ATTRIBUTES object and recognize the Attributes
        Flags TLV, but does not recognize "non-PHP behavior flag"; 

      then it SHOULD silently ignore this request.

The behavior in these two cases is not something you can define here
since such LSRs will not be conformant to this document. Fortunately,
this behavior is defined in RFC 5420, so you can re-write as:

      then it will silently ignore this request according to the
      processing rules of [RFC5420].

The same applies in Section 2.2

---

Section 2.2

I had a bit an "I wouldn't have done it this way" moment. Can you                   
explain why you opted for a mechanism that signals the fact that
another mechanism will be used to bind LSPs, rather than enhancing
RSVP-TE to actually signal the use? Actually, RSVP-TE already
includes mechanisms that could very easily have carried the
binding information.

Obviously you need to support existing non-RSVP mechanisms, but
that could have been rolled in.

---                                       

Section 2.4

It would be interesting to know whether OAM is expected to work or not
while the egress is black-holing data pending binding.

---

Section 3

Since you have introduced a dependence on an external communications
method, you have also introduced a new security consideration.

You have also introduced some new vectors that can be used to
attack the LSP. For example, changing the label reported in the RRO
can cause it to be torn down. Although this does not change the
overall security model or techniques, it should be pointed out so
that an operator can consider the additional pressure to apply
adequate security mechanisms.

You should include a reference to RFC 5920.

---

Section 4

You are missing a subsection header

4.2.  New RSVP Return Code

---

Section 4.1

Please remove suggested values from this section and the whole document.
You will notice that flag 6 has already been assigned. Including
suggested values in a draft is only likely to result in confusion.

---
                                                                                                 
Section 4.1

      o  These flags are to be used in the Attributes Flags TLV in both
        Path and Resv messages. 

Please be more explicit so that IANA can fill in the table at
http://www.iana.org/assignments/rsvp-te-parameters

The easiest is to supply all the table entries except for the TBD
values.

---

---------------------------------------------------------
Writeup for draft-ietf-mpls-rsvp-te-no-php-oob-mapping-07
---------------------------------------------------------

  (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-rsvp-te-no-php-oob-mapping.
The Document Shepherd personally reviewed the Document and believes
this version (06) 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?

At the time of Working Group adoption, technical comments were expressed
and taken into account by the authors.
The Document was also presented and dicussed at, at least, 3 IETF meetings.
No issue was raised 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.
No IPR disclosure exists for the Document.


  (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?

The document received good support during Working Group adoption and no issue
was raised during Working Group Last Call.


  (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.

No nits found.
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 Normative Section only includes documents which are either in
RFC or STD status. There are no normative downward references.


  (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 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.

There are many deployment scenarios which require Egress Label
Switching Router (LSR) to receive binding of the Resource ReserVation
Protocol Traffic Engineered (RSVP-TE) Label Switched Path (LSP)
to an application, and payload identification, using some "out-
of-band" (OOB) mechanism. This document proposes protocol
mechanisms to address this requirement. The procedures described
in this document are equally applicable for point-to-point (P2P)
and point-to-multipoint (P2MP) LSPs.


          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.


          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?

The Document Shepherd is unaware of any implementation.


          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