Hi authors, Thank you for this draft. In preparation of a WG LC, I've done a review of the draft. Please find below some comments and questions. I may have other comments once the below points are clarified and a new draft version is published.
======== Main technical point: ======== This document proposes to reserve a flag in the SRH. This is a scarce resource since we only have 8 flags for the SRv6 lifetime. IMO, this flag was not clearly stated in the draft adoption time and I don't recall much discussion on the list about it. Is this flag really needed? Is this supported by the WG? If so, may be this flag could be generalized? (depending on some clarifications below) Alternatively, this flag may not be really needed, or at least not today: * SR-MPLS PSID does not need this and encode the PSID as the last SID in the sid list (only processed by the egress) * "Depending on the use case, a PSID may be distributed to the SRv6 nodes along the SRv6 path. In this case, the SRv6 nodes that learned the PSID may process the PSID depending on the use case. This is out of the scope of this document, and may be studied in the future if needed." This seems to indicate that processing of the PSID on SRv6 nodes along the path is not really defined nor needed. If so, may be the flag could also be defined "in the future if needed"? Finally, this flag seems to require the addition of the SRH in all cases, while currently some uses cases do not require the SRH e.g. VPN & compressed SID. This is a significant drawback which should be indicated. (and removing this flag would remove this constraint) ======== Technical: ======== "Furthermore, by using SRv6 PSIDs, any SRv6 path within an SRv6 policy can be identified and measured, even when they use the same segment list. » "A PSID is used for identify a SRv6 path represented by a segment list." Identified by which node? Read the use cases in section 2, it seems that identification is only required on the final destination node. Can this be clarified? (as a reminder, the SR-MPLS PSID identifies an SR path on the egress node of the path. So if the goal is to port the SR-MPLS PSDI to SRv6, as indicated in the abstract, the requirements should be the same) "Some use cases only require the ingress node and egress node to process the PSID, while the intermediate nodes ignore the PSID. Some use cases may require all the segment nodes along the path to process the PSID." What are the use cases requiring intermediate nodes to process the PSID? "intermediate nodes" Please use the terminology from RFC8754. I would assume that you mean "SR Segment EndPoint Node". ---- "To avoid the value conflict, the value of a PSID MUST be global unique within the SRv6 domain." Why is so if the identification is only done on the egress? --- "SRv6 PSID follows this structure, where the LOC part identifies the egress node that allocates the PSID," Is this part of the specification of the solution or is this an illustrative proposal for PSID allocation? As indicated in the document, PSID are not used for routing, so we don't really require a LOCator to route to. Also, depending on the above point, PSID would be local to the egress/final destination so don't need to be globally unique. (they may be if the network operator chose to) ---- "The SRv6 PSID MUST appear only once in a segment list, and it MUST appear as the last entry in the segment list." "last entry in the segment list" seems subject to misunderstanding to me. In general, the SID list is order from source to destination. So "last entry in the segment list" would be the final destination. However the Figure 3 puts the SRv6 PSID in SRH Segment List [n] (which is the first segment in the segment list) As per RFC 8754 https://datatracker.ietf.org/doc/html/rfc8754 : "At its SR Policy headend, the Segment List <S1,S2,S3> results in SRH (S3,S2,S1; SL=2) represented fully as: Segments Left=2 Last Entry=2 Flags=0 Tag=0 Segment List[0]=S3 Segment List[1]=S2 Segment List[2]=S1 » So please clarify in a way which is not ambiguous. §6 has also related text about this: "The SRv6 PSID MUST appear only once in a segment list, and it MUST appear as the last entry. Placing an SRv6 PSID at any other location in the SID list will result in unpredictable forwarding behavior. Only the one that appears as the last entry in the SID list will be processed." --- Depending on the above, does the source needs to perform a specific treatment on the "Segment Left" field? E.g. set if to n-2 (to skip the PSID). §6 talks about this but mostly with example. It rather see a clear spec of the chages compared to RFC8754 (which says "The Segments Left field is set to n-1, where n is the number of elements in the SR Policy.") --- "When SRv6 compression [I-D.ietf-spring-srv6-srh-compression] is not supported" Please update the reference. Do you need to make a distinction between NEXT & REPLACE CSID flavors? IOW, both works? --- "This document does not define the details of pseudo code of the implementation." What do you mean? This document is the specification so need to specify the pseudo code. ---- " S01. if SRH.P-flag processing is enabled: S02. if intermediate node SRv6 PSID processing is disabled: S03. if SRH.P-flag is set and the node is the egress node: ;;ref1 S03. SRv6 PSID processing ;;ref2 S04 else: S05. if SRH.P-flag is set: S06. SRv6 PSID processing " Processing seems to be the same whether or not the node is the egress node. Is this expected? If so, pseudo code could be simplified. If not, please correct. Also where is pseudo code placed in the existing pseudo code? (In particular, is it processed before or after the SR behavior of the current SID? --- Please note RFC8754 "New SIDs defined in the future MUST specify the mutability properties of the Flags, Tag, and Segment List and indicate how the Hashed Message Authentication Code (HMAC) TLV (Section 2.1.2<https://datatracker.ietf.org/doc/html/rfc8754#HMACTLV>) verification works." So please specify those points. (you may want to look at TFC 8986 section 9) --- It's not clear to me how "End.PSID" is used. My understanding is that it has no pseudo code since it never processed on a SR End Point. ======== Editorial: ======== Abstract and Introduction sections use SR-MPLS Path ID as a justification of SRv6 path ID. This may not age well, and this is likely not of interest to a reader only interested in SRv6. Surely there is a justification of SRv6 path ID independently of SR-MPLS. Could you rephase the abstract and Introduction with the focus on SRv6 path ID? -- "In SR, a path needs to be identified for several use cases such as binding bidirectional paths [I-D.ietf-pce-sr-bidir-path<https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-15>] and end-to-end performance measurement [I-D.ietf-spring-stamp-srpm<https://datatracker.ietf.org/doc/html/draft-ietf-spring-stamp-srpm-17>]." If this is a _need_ I would expect [I-D.ietf-spring-stamp-srpm<https://datatracker.ietf.org/doc/html/draft-ietf-spring-stamp-srpm-17>] to have a normative reference to draft-ietf-spring-srv6-path-segment. This is not the case. Also quickly reading [I-D.ietf-spring-stamp-srpm<https://datatracker.ietf.org/doc/html/draft-ietf-spring-stamp-srpm-17>], I'm not sure that this is an absolute requirement. So may be :s/needs/may need. To some extend, same comment for [I-D.ietf-pce-sr-bidir-path<https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-15>] although I didn't read the two PCEP drafts. -- "Further, an SRv6 path cannot be identified by the information carried by the SRH in reduced mode [RFC8754<https://www.rfc-editor.org/info/rfc8754>] as the first SID is not present in the SRH." So don't use reduced mode if it's not appropriate. (IOW, I don't think that this is a valid argument to justify a protocol extension). I would suggest to delete this sentence -- "the length of a segment list is flexible according to the number of required SIDs" "Using a 128-bit Path ID has the better processing performance than using a flexible length of Segment list as a path ID." I'm not a native speaker but I don't think that "flexible "is the best term. May be :s/flexible length/variable length -- SPRING WG policy requires an Implementation section. https://wiki.ietf.org/en/group/spring/WG_Policies Could you please add it in the draft? -- "Using an SRv6 PSID is used in reduced mode SRH [RFC8754] can solve the problem of cannot identifying a segment list by the reduced segment list, while the overhead is equivalent to the SRH in normal mode." The sentence does not parse very well. Could you please entirely rewrite it? --- §1.2 "SR-MPLS: Segment Routing with MPLS data plane." Hopefully there would be no need to refer to SR-MPLS in this SRv6 document. Please check whether this term may be removed from the draft and section 1.2 Thanks, Regards, --Bruno ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
