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