[trimmed cc] Hi Tim, Jie, Thanks for your review, Tim. I see Jie has not yet had a chance to respond or update the draft. My evaluation of Tim’s review is that none of the comments are “show stoppers”, so I’ve issued the IESG ballot for the document to be on the agenda of the February 20 IESG telechat, but you should still resolve these comments and publish the update as soon as you’re ready. Thanks, —John > On Feb 7, 2025, at 4:57 AM, yutianpengietf@xxxxxxx wrote: > > 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". > > 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. > > > 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." > > 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
