Skip to main content

Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)
RFC 7570

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 steering group member) Yes

Yes (for -03)

                            

(Alia Atlas; former steering group member) No Objection

No Objection (for -04)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (for -04)

                            

(Benoît Claise; former steering group member) No Objection

No Objection (for -04)

                            

(Brian Haberman; former steering group member) No Objection

No Objection (2015-03-10 for -04)
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 steering group member) No Objection

No Objection (for -04)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -04)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (for -04)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -04)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (2015-03-11 for -04)
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 steering group member) No Objection

No Objection (for -04)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (2015-03-10 for -04)
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 steering group member) No Objection

No Objection (for -04)

                            

(Ted Lemon; former steering group member) No Objection

No Objection (for -04)