Hi Tim, Thanks again for the comment. The example with SRv6 in section 3.1 is based on SRv6 H.Encaps.Red behavior. PE1 as the ingress node can add the outer IPv6 header with one SRH which includes both the SRv6 service SID and the SIDs of the intermediate endpoints. The example with SR-MPLS in section 3.2 is using SR-MPLS tunnel to carry SRv6 service packet, thus following the MPLS label stack there is an IPv6 packet header with PE1 as SA, and the SRv6 Service SID as DA. Hope this helps. Best regards, Jie > -----Original Message----- > From: yutianpengietf@xxxxxxx <yutianpengietf@xxxxxxx> > Sent: Saturday, February 8, 2025 11:33 AM > To: Dongjie (Jimmy) <jie.dong@xxxxxxxxxx>; 'David Black' > <david.black@xxxxxxxx>; tsv-art@xxxxxxxx > Cc: draft-ietf-idr-cpr.all@xxxxxxxx; idr@xxxxxxxx; last-call@xxxxxxxx > Subject: Re: [Idr] Re: Re: Tsvart last call review of draft-ietf-idr-cpr-06 > > Dear Jie, > Could you please help to check if the label stack in section 3.1 is: > " > PE1 ->P1: (PE1, P1)(PE3:CL1.DT6, ASBR11; SL=2)(C-pkt) > P1 ->ASBR11: (PE1, ASBR11)(PE3:CL1.DT6, ASBR11; SL=1)(C-pkt) > " > Or > " > PE1 ->P1: (PE1, P1)(ASBR11; SL=1))(PE1, PE3:CL1.DT6)(C-pkt) > P1 ->ASBR11: (PE1, ASBR11)(PE1, PE3:CL1.DT6)(C-pkt) > " > In section 3.2, the MPLS forwarding plane is: > " > PE1-> P1: Label-stack(P1, ASBR11)(PE1, PE3:CL1.DT6)(C-pkt) > P1->ASBR11: Label-stack(ASBR11)(PE1, PE3:CL1.DT6)(C-pkt) > " > Is there any particular reason that SRv6 encapsulation behavior differs from > MPLS one? > The logic in section 3.2 and other part of section 3.1 make sense. > Thanks a lot. > Br, > Tim > > -----邮件原件----- > 发件人: forwardingalgorithm@xxxxxxxx <forwardingalgorithm@xxxxxxxx> 代表 > yutianpengietf@xxxxxxx > 发送时间: Saturday, February 8, 2025 10:58 AM > 收件人: 'Dongjie (Jimmy)' <jie.dong=40huawei.com@xxxxxxxxxxxxxx>; 'David > Black' <david.black@xxxxxxxx>; tsv-art@xxxxxxxx > 抄送: draft-ietf-idr-cpr.all@xxxxxxxx; idr@xxxxxxxx; last-call@xxxxxxxx > 主题: [Idr] 回复: Re: Tsvart last call review of draft-ietf-idr-cpr-06 > > Thanks a lot Jie, > I have seen the updated document. > It solves all my comments. > Br, > Tim > > > -----邮件原件----- > 发件人: forwardingalgorithm@xxxxxxxx <forwardingalgorithm@xxxxxxxx> 代表 > Dongjie (Jimmy) > 发送时间: Saturday, February 8, 2025 10:48 AM > 收件人: yutianpengietf@xxxxxxx; 'David Black' <david.black@xxxxxxxx>; > tsv-art@xxxxxxxx > 抄送: draft-ietf-idr-cpr.all@xxxxxxxx; idr@xxxxxxxx; last-call@xxxxxxxx > 主题: [Idr] Re: Tsvart last call review of draft-ietf-idr-cpr-06 > > Hi Tim, > > Thanks for the detailed review and comments. Please see replies inline: > > > -----Original Message----- > > From: yutianpengietf@xxxxxxx <yutianpengietf@xxxxxxx> > > Sent: Friday, February 7, 2025 5:57 PM > > To: 'David Black' <david.black@xxxxxxxx>; tsv-art@xxxxxxxx > > Cc: draft-ietf-idr-cpr.all@xxxxxxxx; idr@xxxxxxxx; last-call@xxxxxxxx > > Subject: Re: [Idr] Tsvart last call review of draft-ietf-idr-cpr-06 > > > > Dear authors, > > Sorry for raising questions on last day of the last call. > > But when I am reading this draft, I find nits.. > > 1. > > In section 3.1, the document says: > > In AS1, the SRv6 Policy for (ASBR11, C1) is represented with SID list > > (P1, ASBR11). > > > > in the section 2.1 of RFC 9256, it says: > > An SR Policy MUST be identified through the tuple <Headend, Color, > > Endpoint>. In the context of a specific headend, an SR Policy MUST be > > identified by the <Color, Endpoint> tuple. > > > > But the description of this document it says, "in AS1", instead of "On > > PE1 in AS1". > > Thanks for catching this. In the latest update (v-07), we have changed the text > to "In AS1, the SRv6 Policy on PE1 for (ASBR11, C1)..." > > > > > > 2. > > Also in the RFC 8986, it says: > > "An SR Policy is resolved to a SID list. A SID list is represented as > > <S1, S2, S3> where S1 is the first SID to visit, S2 is the second SID > > to visit, and S3 is the last SID to visit along the SR path. > > > > (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: > > > > Source Address (SA), Destination Address (DA), and next header (SRH). > > SRH with SID list <S1, S2, S3> with Segments Left = SL." > > > > Could you please change the description in this document with SID list > > using <> instead of (). > > As the sequences of the SIDs when using <> and () are reversed if we > > follow the logic in RFC 8986, unless you describe the logic being used > > clearly in the document. > > Thanks for catching this nit. In the description of SID lists, we have replaced "()" > with "<>". > > > > 3. The packet encapsulation and forwarding process looks confusing, E.g. > > PE1 ->P1: (PE1, P1)(PE3:CL1.DT6, ASBR11; SL=2)(C-pkt) > > P1 ->ASBR11: (PE1, ASBR11)(PE3:CL1.DT6, ASBR11; SL=1)(C-pkt) > > > > Does this format follow the logic described in the RFC 8986 which > > means source address and destination address, or (PE1, P1) is a SRv6 > encapsulation? > > Description in RFC 8986 > > " (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: > > > > Source Address (SA), Destination Address (DA), and next header (SRH). > > SRH with SID list <S1, S2, S3> with Segments Left = SL." > > The encapsulation follows the logic in RFC 8986. > > Taking (PE1, P1)(PE3:CL1.DT6, ASBR11; SL=2)(C-pkt) as an example, it is an IPv6 > packet with PE1 as SA, P1 as DA, and (PE3:CL1.DT6, ASBR11; SL=2) is the SRH > with SID list < ASBR11, PE3:CL1.DT6>. > > The C-pkt is the inner customer packet received from the attaching CE. We've > added one sentence to clarify this. Hope it is clear now. > > Best regards, > Jie > > > > > Thanks in advance. > > Br, > > Tim > > -----邮件原件----- > > 发件人: forwardingalgorithm@xxxxxxxx <forwardingalgorithm@xxxxxxxx> 代 > 表 > > David Black via Datatracker > > 发送时间: Saturday, February 1, 2025 5:45 AM > > 收件人: tsv-art@xxxxxxxx > > 抄送: draft-ietf-idr-cpr.all@xxxxxxxx; idr@xxxxxxxx; last-call@xxxxxxxx; > > david.black@xxxxxxxx > > 主题: [Idr] Tsvart last call review of draft-ietf-idr-cpr-06 > > > > Reviewer: David Black > > Review result: Ready with Nits > > > > This document has been reviewed as part of the transport area review > > team's ongoing effort to review key IETF documents. These comments > > were written primarily for the transport area directors, but are > > copied to the document's authors and WG to allow them to address any > > issues raised and also to the IETF discussion list for information. > > > > When done at the time of IETF Last Call, the authors should consider > > this review as part of the last-call comments they receive. Please > > always CC tsv-art@xxxxxxxx if you reply to or forward this review. > > > > This document describes how to advertise colored IPv6 prefixes for > > SRv6 via BGP. As a routing protocol document that extends BGP, this > > document does not raise any transport-specific concerns. > > > > I noticed one nit - this draft has a strong dependence on > > draft-hr-spring-intentaware-routing-using-color, which is an Expired > > Internet-Draft. That draft is cited as the source of requirements and > > problem statement for this draft, and that draft is cited twice in the > > Operational Considerations section as a foundation for guidance to > operators. > > I strongly encourage the authors to find a better reference for these > > purposes than an expired Internet-Draft and/or include more material > > on these topics in the absence of an equally useful reference. > > > > > > > > _______________________________________________ > > Idr mailing list -- idr@xxxxxxxx > > To unsubscribe send an email to idr-leave@xxxxxxxx > > _______________________________________________ > Idr mailing list -- idr@xxxxxxxx > To unsubscribe send an email to idr-leave@xxxxxxxx > > _______________________________________________ > Idr mailing list -- idr@xxxxxxxx > To unsubscribe send an email to idr-leave@xxxxxxxx -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
