Re: [Pce] Change Path Attrubute Object to a Sub-object

["Mike Koldychev (mkoldych)" <[e-mail]>]

Hi Andrew,

Thanks a lot for compiling all the information very nicely!

Hi Ruizhao,

The idea of putting PATH-ATTRIBUTES inside the ERO object was actually considered at IETF 105 in Montreal. We decided against it, for the reasons that Andrew listed.

Thanks,
Mike.

From: Stone, Andrew (Nokia - CA/Ottawa) <[e-mail]>
Sent: Tuesday, May 12, 2020 10:32 AM
To: huruizhao <[e-mail]>; [e-mail]; [e-mail]
Cc: Lihanlin <[e-mail]>; Tanren <[e-mail]>
Subject: Re: [Pce] Change Path Attrubute Object to a Sub-object

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 <[e-mail]<mailto:[e-mail]>> on behalf of huruizhao <[e-mail]<mailto:[e-mail]>>
Date: Monday, May 11, 2020 at 6:35 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Lihanlin <[e-mail]<mailto:[e-mail]>>, Tanren <[e-mail]<mailto:[e-mail]>>
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.