Skip to main content

Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)
draft-ietf-teas-lsp-attribute-ro-05

Yes

(Adrian Farrel)

No Objection

(Alia Atlas)
(Barry Leiba)
(Benoît Claise)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Martin Stiemerling)
(Richard Barnes)
(Stephen Farrell)
(Ted Lemon)

Note: This ballot was opened for revision 03 and is now closed.

Adrian Farrel Former IESG member
Yes
Yes (for -03) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (2015-03-10 for -04) Unknown
Some suggested changes:

- Section 2 : s/The ERO Hop Attributes subobject MAY be carried/The ERO Hop Attributes subobject is carried/

- Section 3.1 : s/The RRO Hop Attributes subobject MAY be carried/The RRO Hop Attributes subobject is carried/

- Each requested IANA action should use a unique identifier (e.g., TBA-1, TBA-2) rather than a generic TBA.  That simplifies IANA's job.
Jari Arkko Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2015-03-11 for -04) Unknown
Similar to Brian's comment:

2.2:

s/One or more TLVs MAY be present in each object/Each object MAY contain one or more TLVs

s/The Attribute Flags TLV defined in [RFC5420] MAY be carried in an ERO Hop Attributes Subobject/The Attribute Flags TLV defined in [RFC5420] are carried in an ERO Hop Attributes Subobject.

3.2.2/3.2.3: s/MAY/can
Richard Barnes Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (2015-03-10 for -04) Unknown
I'll leave this as a comment. If it's important, a RTG AD can say so ...

In this text:

   If a node is processing an ERO Hop Attributes subobject and does not
   support handling of the subobject it will behave as described in
   [RFC3209] when an unrecognized ERO subobject is encountered.  This
   node will return a PathErr with error code "Routing Error" and error
   value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object
   included, truncated (on the left) to the offending unrecognized
   subobject.

The behavior is a bit different from what I thought was the corresponding text in [RFC3209]:

      It is anticipated that new subobjects may be defined over time.  A
   node which encounters an unrecognized subobject during its normal ERO
   processing sends a PathErr with the error code "Routing Error" and
   error value of "Bad Explicit Route Object" toward the sender.  The
   EXPLICIT_ROUTE object is included, truncated (on the left) to the
   offending subobject.  The presence of an unrecognized subobject which
                         ^
          I'm not seeing ^ this part reproduced in the draft
                         
   is not encountered in a node's ERO processing SHOULD be ignored.  It
   is passed forward along with the rest of the remaining ERO stack.
   
I'm no RSVP-TE jockey, but I would have thought if you behaved as in [RFC3209], you would have done everything in that paragraph ... and obviously, I only compared these because the description was imported by reference AND sort-of-by value at the same time. 

Maybe providing only the reference, as you do in the next couple of instances would be better?
Stephen Farrell Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Ted Lemon Former IESG member
No Objection
No Objection (for -04) Unknown