[mpls] AD review of draft-ietf-mpls-rsvp-te-no-php-oob-mapping-07

[Adrian Farrel <[e-mail]>]

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.

---