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 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
