Hi Ruizhao, Thanks for the feedback and suggestion on the draft. I’m not an author, but do have a few comments regarding your proposal. Not sure I agree that embedding the Path Attribute object as a sub-object of the ERO would be better, due to Path Attribute Object being an object that describes a complete path definition and not an individual hop inside of the path definition. As well, it appears to me a precedence exists in somewhat related, but not PCEP, RFCs to use the ERO sub objects as per-hop information, and embed complete path attributes outside of the ERO.
Some snippets: https://tools.ietf.org/html/rfc5440#section-7.9 states: The ERO is used to encode the path of a TE LSP through the network. The ERO is carried within a PCRep message to provide the computed TE LSP if the path computation was successful. The contents of this object are identical in encoding to the contents of the Resource Reservation Protocol Traffic Engineering Extensions (RSVP-TE) Explicit Route Object (ERO) defined in [RFC3209], [RFC3473], and [RFC3477]. That is, the object is constructed from a series of sub-objects. Any RSVP-TE ERO sub-object already defined or that could be defined in the future for use in the RSVP-TE ERO is acceptable in this object. https://tools.ietf.org/html/rfc8664 section 4.3 states: An ERO carrying an SR-TE path consists of one or more ERO subobjects, and it MUST carry only SR-ERO subobjects. When building the MPLS label stack from ERO, a PCC MUST assume that SR-ERO subobjects are organized as a last-in-first-out stack. The first subobject relative to the beginning of ERO contains the information about the topmost label. The last subobject contains information about the bottommost label. https://tools.ietf.org/html/draft-koldychev-pce-multipath-01 states: We define the PATH-ATTRIB object that is used to carry per-path information Taking the above snippets into consideration: - When I read the above, to me it says ERO is the path. Path Attribute Object carries attributes about the path definition, not the path itself. The Path Attribute object isn't actually part of the path, so it shouldn't really be contained within the path definition but instead "wrap around it" / attach to it at a higher level. - Carrying path attribute as a subObject would go against RFC 8664 statements. Those can be amended/extended of course, but something I think is relevant to point out. - For a similar use case, RFC5420 also embeds “complete path” attributes outside of the ERO object construct in the context of RSVP signalled, and uses the RRO subobjects to capture per-hop feedback. - From my p.o.v, https://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsvp-parameters-24 (which defines the sub-objects used in PCEP as well) defines sub objects that are related to a specify node/hop in the path, not about the complete path. For example, RFC7570 defines a sub-object that is per-hop specific, not for the overall path. Cheers Andrew From: Pce <[email protected]> on behalf of huruizhao <[email protected]> Date: Monday, May 11, 2020 at 6:35 AM To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Cc: Lihanlin <[email protected]>, Tanren <[email protected]> Subject: [Pce] Change Path Attrubute Object to a Sub-object Hi authors, In the section 4.2 of [draft-koldychev-pce-multipath-01], Path Attribute Object is defined as a new object that is used to carry per-path information and to act as a separator between several ERO/RRO objects.. The newly defined object describes the attributes of the ERO object (path ID, Multipath Weight TLV, Multipath Backup TLV). Therefore, we recommend changing it to a Sub-object carried in the ERO / RRO object. This way can make the information in the ERO object centralized and complete. And from an implementation perspective, this approach can avoid the operational complexity when dealing with the pairing of Path Attribute Object and ERO Object. If you have other considerations, please contact me. Thanks. Best Regards, Ruizhao.
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
