Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC146C14F69E; Tue, 30 Jul 2024 00:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEGgkavnrTae; Tue, 30 Jul 2024 00:44:43 -0700 (PDT) Received: from mail-m1019.netease.com (mail-m1019.netease.com [154.81.10.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2BBC14F5E0; Tue, 30 Jul 2024 00:44:39 -0700 (PDT) Received: from LAPTOP09T7970K (unknown [219.142.69.76]) by smtp.qiye.163.com (Hmail) with ESMTPA id EF3207E0139; Tue, 30 Jul 2024 15:43:53 +0800 (CST) From: "Aijun Wang" To: "'Dhruv Dhody'" References: <000b01dadc1a$d5fe1570$81fa4050$@tsinghua.org.cn> <36EC6ACA-2A0A-4E1B-9978-2E9235DD740A@juniper.net> <002c01dae19a$a0385330$e0a8f990$@tsinghua.org.cn> In-Reply-To: Date: Tue, 30 Jul 2024 15:43:53 +0800 Message-ID: <00aa01dae254$3a120280$ae360780$@tsinghua.org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AB_01DAE297.48378C70" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGKMJNDnfr//7qAKTNGtQ6ZfiPzKQK4m/YJAVVCbwgCdnlxrgH2loXysmxucJA= Content-Language: zh-cn X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVkaGB5CVklOTU9IT09KSB0ZT1YeHw5VEwETFh oSFyQUDg9ZV1kYEgtZQVlJSkJVSk9JVU1CVUxNWVdZFhoPEhUdFFlBWU9LSFVKS0lCTUpKVUpLS1 VLWQY+ X-HM-Tid: 0a9102987f8b03a2kunmef3207e0139 X-HM-MType: 10 X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6N006Hyo*TzI5HzUKEyFNCRcB HgowCgNVSlVKTElJSElOT0hOSkNPVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxNWVdZCAFZQUxKQklJNwY+ Message-ID-Hash: FZ6XHHHYFD5NWFFTJKNONRL34OUDOZWE X-Message-ID-Hash: FZ6XHHHYFD5NWFFTJKNONRL34OUDOZWE X-MailFrom: wangaijun@tsinghua.org.cn X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pce.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: draft-ietf-pce-pcep-extension-native-ip@ietf.org, pce@ietf.org, bhassanov@yahoo.com, tanren@huawei.com, zhu.chun1@zte.com.cn X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?b?W1BjZV0g562U5aSNOiDnrZTlpI06IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLXBj?= =?utf-8?b?ZS1wY2VwLWV4dGVuc2lvbi1uYXRpdmUtaXAtMzA=?= List-Id: Path Computation Element Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_00AB_01DAE297.48378C70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Dhruv: =20 Thanks for your comments=EF=BC=81 I have updated the draft according to your suggestions and will post it = later in conjunction with the other updates later from the IETF LC. =20 Is there any procedure to accelerate the forwarding of = https://datatracker.ietf.org/doc/draft-dhody-pce-iana-update/, or can we = start it now? =20 Best Regards =20 Aijun Wang China Telecom =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Dhruv Dhody [mailto:dd@dhruvdhody.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2024=E5=B9=B47=E6=9C=8830=E6=97=A5 = 13:52 =E6=94=B6=E4=BB=B6=E4=BA=BA: Aijun Wang =E6=8A=84=E9=80=81: = =E3=80=90=E5=A4=96=E9=83=A8=E8=B4=A6=E5=8F=B7=E3=80=91 John Scudder = ; draft-ietf-pce-pcep-extension-native-ip@ietf.org; = pce@ietf.org; bhassanov@yahoo.com; tanren@huawei.com; = zhu.chun1@zte.com.cn =E4=B8=BB=E9=A2=98: Re: [Pce] =E7=AD=94=E5=A4=8D: AD review of = draft-ietf-pce-pcep-extension-native-ip-30 =20 Hi Aijun,=20 =20 Thanks for making these changes.=20 =20 I did a review of = https://author-tools.ietf.org/iddiff?url1=3Ddraft-ietf-pce-pcep-extension= -native-ip-30 = = &url2=3Ddraft-ietf-pce-pcep-extension-native-ip-32&difftype=3D--html =20 A few things to consider alongside any other IETF LC comments -=20 =20 - Section 3, we have added references for a few but not for others. = Consider adding references for terms that are already defined in other = RFCs to keep it consistent. - Section 12, capitalize "if" in the last paragraph.=20 - Section 14.6, 14.7 and 14.8, please change "standard action" to "IETF = review".=20 =20 Note that, for section 14.2 allocation, we need to wait for = draft-dhody-pce-iana-update to make progress.=20 =20 Thanks!=20 Dhruv =20 =20 On Mon, Jul 29, 2024 at 2:36=E2=80=AFAM Aijun Wang = > wrote: Hi, John: =20 I have uploaded the updated version at = https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-nativ= e-ip-32 and wish it address all your concerns. If there is no more comments, we can put forward it to the IESG LC = review then. Thanks in advance for your efforts! =20 Some detail replies can see inline below. =20 =20 Best Regards =20 Aijun Wang China Telecom =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: forwardingalgorithm@ietf.org = = [mailto:forwardingalgorithm@ietf.org] =E4=BB=A3=E8=A1=A8 = =E3=80=90=E5=A4=96=E9=83=A8=E8=B4=A6=E5=8F=B7=E3=80=91 John Scudder =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2024=E5=B9=B47=E6=9C=8826=E6=97=A5 = 23:59 =E6=94=B6=E4=BB=B6=E4=BA=BA: Aijun Wang > =E6=8A=84=E9=80=81: draft-ietf-pce-pcep-extension-native-ip@ietf.org = ; pce@ietf.org = ; bhassanov@yahoo.com = ; fsheng@huawei.com ; tanren@huawei.com = ; zhu.chun1@zte.com.cn = =20 =E4=B8=BB=E9=A2=98: Re: AD review of = draft-ietf-pce-pcep-extension-native-ip-30 =20 Hi Aijun,=20 =20 Thanks for the update. I have a few more comments, below. I have trimmed = for brevity, indicated by [=E2=80=A6], anything trimmed is agreed or = anyway doesn=E2=80=99t need more discussion. =20 If you can update to reflect these comments I think we can send it for = IETF last call. =20 On Jul 22, 2024, at 5:37=E2=80=AFAM, Aijun Wang = > wrote: Hi, John: I have updated draft according to your suggestions at = = https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-i= etf-pce-pcep-extension-native-ip__;!!NEt6yMaO-gk!B09SQ9s42Y1hsFo8BANfznJ4= lysLpngvzlzwp9ULLAbS_FzVRmaT6Jx-RsCqbWt6uHiW1t3973FwFYcuh7li0A$ For the document track, I think it is OK to move it forward as the = experimental track, we will try to update it later to the standard track = after its experimental deployment. The detail responses are inline below=E3=80=90WAJ=E3=80=91 If there is more suggestions, please let us know. Or else, can we = schedule the IESG Last Call then? Best Regards Aijun Wang China Telecom =20 [=E2=80=A6] =20 During the establishment procedure, PCC should report to the PCE the status of the BGP session via the PCRpt message, with the status @@ = -453,7 +547,16 @@ When PCC receives this message with the R bit set to 1 in SRP object in PCInitiate message, the PCC should clear the BGP session that is indicated by the BPI object. ++--- +jgs: The term "clear the BGP session" isn't standard (although it is +common colloquial usage). Looking at RFC 4271, in one place (Section 3) +it does talk about "resetting any BGP connections" so I think you would +be on firm ground if you want to say "reset". Or you might consider +referencing the AutomaticStop event (RFC 4271, Section 8.1.2, Event 8). =E3=80=90WAJ=E3=80=91=EF=BC=9A Here, =E2=80=9Cclear the BGP = session=E2=80=9D is just want to express the deletion of the BGP = configuration on PCC, not reset the BGP connection. Should it be more clearer, if we instead say "clear the BGP session = configuration"?------Have updated the descriptions accordingly. =20 Yes, that=E2=80=99s an improvement. This leaves it ambiguous whether the = session should be torn down immediately or not, do you intend that? E.g. = in some implementations, a configuration change is not reflected in the = operational state until a commit (or equivalent) is performed. =E3=80=90WAJ=E3=80=91How about =E2=80=9Cthe PCC should clear the BGP = configuration and tear down the BGP session that is indicated by the BPI = object.=E2=80=9D? I think it is more clear. I have updated the contents = according to the above statements. [=E2=80=A6] Such explicit routes operate the same as static routes installed by network management protocols (Network Configuration Protocol (NETCONF)/YANG). The procedures of such explicit route addition and = @@ -582,6 +689,9 @@ The PCInitiate message should be sent to the on-path routers respectively. In the example, for explicit route from R1 to R7, the ++--- +jgs: What does =E2=80=9Crespectively=E2=80=9D mean here? Can it be = removed? =E3=80=90WAJ=E3=80=91Here, we just want to describe such message should = be sent every router on the path, each may has different content, for = example, the different next hop information. =20 OK thanks. In that case, while removing the word = =E2=80=9Crespectively=E2=80=9D would be enough, I suggest you revise it = to use the language you=E2=80=99ve used above. That is, =20 OLD: The PCInitiate message should be sent to the on-path routers respectively. =20 NEW: The PCInitiate message should be sent to every router on the=20 path. =20 =E3=80=90WAJ=E3=80=91Done =20 [=E2=80=A6] =20 BGP Peer Info Object-Class is 46 BGP Peer Info Object-Type is 1 for IPv4 and 2 for IPv6 @@ -1071,6 = +1233,10 @@ - 2: Peer IP can't be reached, BGP Session Failure - 3-255: Reserved ++--- +jgs: Shouldn't you have a generic error code as well, e.g. "0: Generic +error", to catch cases other than the ones described by 1 and 2? ++--- =E3=80=90WAJ=E3=80=91 What we thought is the following, that if there is = some new error that lets to the BGP Session Failure, we should define = exactly the code from the reserved range. The "generic" error gives no more detail indication of the error reason. = Is it right? =20 Right. In my experience, it=E2=80=99s hard to enumerate every possible = error that could lead to a session failure. It=E2=80=99s probably not = the best use of your efforts to try to come up with a comprehensive = list, even the BGP document set itself doesn=E2=80=99t contain one, = consider the list of OPEN error subcodes = (https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp= -parameters-6). The first one is =E2=80=9Cunspecific=E2=80=9D. In my = view, when an implementor encounters a case where the error = isn=E2=80=99t one that has a specific mapping in the error codes, = it=E2=80=99s better for them to still be able to send an error, and = it=E2=80=99s better for the code to be =E2=80=9Cunspecific=E2=80=9D or = =E2=80=9Cgeneric=E2=80=9D than it is for them to choose an error code = that is *wrong*.=20 =20 I agree that the ideal is to never need to use the generic code, but if = the need does arise, it=E2=80=99s better to use the generic code than a = wrong code. =E3=80=90WAJ=E3=80=91Thanks for your advice. I have changed the code 0 = as =E2=80=9Cunspecific=E2=80=9D =20 Flag: 1 Byte. @@ -1104,6 +1270,12 @@ establish the BGP session with the peer in AFI/SAFI=3D2/1. 7.3. Explicit Peer Route Object ++--- +jgs: you describe this object as "peer route", but isn't it just a +generic host route, in your architecture you happen to use for BGP +peers? It seems to me it would be a more accurate description if you +replaced the word "Peer" with "Host" throughout this section. ++--- =E3=80=90WAJ=E3=80=91: Here, the "Peer Route" just wants to emphasize = the route is to the peer, although actually is a host route( to the = peer). Describe it solely only with "Host" can't have such refer and maybe = mislead to the reader? We would like to keep it in this way? =20 The problem with this is that although in your implementation you might = only plan to use it for installing a route to the peer, some other = implementation might choose to use it for something different. History = shows that when a generic mechanism is introduced, it is often used in = ways the inventors didn=E2=80=99t intend. So, my preference is you use = an accurate description. Maybe a happy medium would be to make the = suggested change but also add descriptive text clarifying the intended = use? Something like, =20 OLD: The Explicit Peer Route object is defined to specify the explicit peer route to the corresponding peer address on each device that is on the E2E Native-IP TE path. This Object should be sent to all the devices on the path that is calculated by the PCE. =20 NEW: The Host Route object is defined to install a host route to the=20 corresponding peer address on each device that is on the E2E Native-IP TE path. This Object should be sent to all the devices on the path that is calculated by the PCE. Although this object could be used to install host routes for other purposes,=20 any such use is outside the scope of this specification. =20 The other way would be to retain the name but add a different = explanation, as in, =20 NEW: Although the object is named =E2=80=9CExplicit Peer Route=E2=80=9D, = it can be seen that the routes it installs are simply host routes. The use of this object to install host routes for any purpose other than reaching the corresponding peer address on each device that is on the E2E Native-IP TE path is outside the scope of this specification. =20 My preference is the first approach but either one works for me. If one = of them is ok for you, just pick it and proceed forward. =E3=80=90WAJ=E3=80=91Considering to limit the change in smaller = scope(other parts within the document, the IANA temporarily allocation = etc.) and reduce the risk of mismatch, I select the second = approach.------And, there is another consideration, that is, to = accomplish the overall task that described in this document, we must = install the route to the peer on every router on the path, not arbitrary = host route that name =E2=80=9CHost Route Object=E2=80=9D which may be = mishandled. =20 The Explicit Peer Route object is defined to specify the explicit peer route to the corresponding peer address on each device that is = @@ -1189,7 +1361,18 @@ establishment. No TLVs are currently defined. 7.4. Peer Prefix Advertisement Object ++--- +jgs: It appears there is an assumption that IPv4 routes will be sent +over an IPv4 peering, and IPv6 routes will be sent over an IPv6 = peering. +This might be problematic especially for IPv4 routes, if the provider +network doesn=E2=80=99t use IPv4 in the underlay and uses tunnel mode = to carry +IPv4 traffic across an IPv6 backbone. +Well this restriction doesn't seem necessary to me, I think it would be +OK to flag it without correcting, if you switch to the Experimental +track. ++--- =E3=80=90WAJ=E3=80=91It is possible to mix the carrier's transport = address family with different address family of the actual traffic.=20 =20 Are you saying that this is possible with the protocol you specify here? = Can you outline how? As far as I could see, if my BGP session is between = IPv6 loopbacks, only IPv6 prefixes can go in the Prefix Advertisement = Object, and simiilarly for IPv4. =20 On the other hand if you=E2=80=99re just saying that this is possible in = real networks, even though your protocol can=E2=80=99t support it, then = we agree. =20 And, again, we want to simplify the parameter negotiations between the = PCCs(and PCE), then solidify the encoding as IPv4 traffic is carried by = IPv4 transport, and the same as for IPv6 address family. Anyway, the = devices within the operator network all support such behavior, but not = all of them support the hybrid comination. =20 As I said in my earlier comment, I=E2=80=99m ok with the restriction = given the Experimental track. I do think you need to flag it though. For = example, =20 NEW: If in the future, a requirement is identified to advertise IPv4 prefixes towards an IPv6 peering address, or IPv6 prefixes towards an IPv4 peering address, then new Peer Prefix Advertisement Object-Types can be defined for these purposes.=20 =E3=80=90WAJ=E3=80=91This is what my exact meanings. I have updated the = content accordingly as your suggestions. =20 [=E2=80=A6] =20 @@ -1637,7 +1827,48 @@ validity of the PCE and ensure a secure communication channel between them. Thus, the mechanisms described in [RFC8253] and [RFC9050] should be used. ++--- +jgs: I appreciate that you are trying to provide bare-bones BGP session +establishment here, and I see the text in Section 9 that says, + This document defines the procedures and objects to create the BGP + sessions and advertise the associated prefixes dynamically. Only = the + key information, for example peer IP addresses, peer AS number are + exchanged via the PCEP protocol. Other parameters that are needed + for the BGP session setup should be derived from their default + values. + +but your design makes it impossible to provide transport security, such +as TCP-AO, because although there is a way to tell the PCC what its BGP +peer is, there is no way to tell the PCC what key to use in +communicating with that peer. In the case of session keying, it's not +reasonable to suggest the key should be "derived from their default +values". Even if the practice of using a single default key for all +internal sessions is used (and I'm not saying that would be a best +practice!), this simply can't work for EBGP, and you do propose to +cover EBGP. + +If you do switch to the Experimental track, in my opinion, something +like the following would be adequate: + +NEW: + Because this specification does not provide a way to communicate + properties beyond peer address and AS number for the BGP sessions + that are established, it will not always be possible to follow best + practices as described in [BCP194], if suitable default values as + discussed in [Section 9] cannot be used. An example would be keying + for use with TCP-AO [RFC5925]. + + If such functionality is required in the future, it can be provided + through the addition of optional TLVs to the BGP Peer Info object, + that convey the necessary additional information (for example, a key + chain [RFC8177] name). + +Note, it's just my opinion that this would be good enough, other +reviewers might have their own thoughts (notably SECDIR and the SEC +ADs). ++--- =E3=80=90WAJ=E3=80=91=EF=BC=9AYes, we plan to add additional TLV to = convey the information about the secure of the BGP session. I think your = recommendation is appropriate for the security considerations. I have = adopted part of your recommendation text as the followings: If suitable default values as discussed in section 9 isn't enough and = securing the BGP transport is required(for example, the TCP-AO(RFC5925), = it can be provided through the addition of optional TLV to the BGP Peer = Info object that convey the necessary additional information(for = example, a key chain(RFC8177) name =20 Cool. I think it is OK to make RFC 8177 an informative reference, since = it=E2=80=99s only a =E2=80=9Cfor example=E2=80=9D. =E3=80=90WAJ=E3=80=91Done =20 =20 _______________________________________________ Pce mailing list -- pce@ietf.org =20 To unsubscribe send an email to pce-leave@ietf.org = =20 ------=_NextPart_000_00AB_01DAE297.48378C70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

H= i, Dhruv:

<= o:p> 

T= hanks for your comments=EF= =BC=81

I= have updated the draft according to your suggestions and will post it = later in conjunction with the other updates later from the IETF = LC.

<= o:p> 

I= s there any procedure to accelerate the forwarding of ht= tps://datatracker.ietf.org/doc/draft-dhody-pce-iana-update/, or can = we start it now?

<= o:p> 

B= est Regards

<= o:p> 

A= ijun Wang

C= hina Telecom

<= o:p> 

=E5=8F=91=E4=BB= =B6=E4=BA=BA: Dhruv Dhody = [mailto:dd@dhruvdhody.com]
=E5=8F=91=E9=80= =81=E6=97=B6=E9=97=B4: = 2024=E5=B9=B47=E6=9C=8830=E6=97=A5 13:52
=E6=94=B6=E4=BB=B6=E4=BA=BA: Aijun Wang = <wangaijun@tsinghua.org.cn>
=E6=8A=84=E9=80=81: = =E3=80=90=E5=A4=96=E9=83=A8=E8=B4=A6=E5=8F=B7=E3=80=91 John Scudder <jgs@juniper.net>; = draft-ietf-pce-pcep-extension-native-ip@ietf.org; pce@ietf.org; = bhassanov@yahoo.com; tanren@huawei.com; = zhu.chun1@zte.com.cn
=E4=B8=BB=E9=A2=98: Re: [Pce] = =E7=AD=94=E5=A4=8D: AD review of = draft-ietf-pce-pcep-extension-native-ip-30

 

Hi Aijun, 

 

Thanks for making these = changes. 

 

 

A few things to consider alongside any = other IETF LC comments - 

 

- Section 3, we have added references for = a few but not for others. Consider adding references for terms that are = already defined in other RFCs to keep it consistent.

- Section 12, = capitalize "if" in the last paragraph. 

- Section 14.6, 14.7 and 14.8, please = change "standard action" to "IETF = review". 

 

Note that, for section 14.2 allocation, we = need to wait for draft-dhody-pce-iana-update to make = progress. 

 

Thanks! 

Dhruv

 

 

On Mon, Jul 29, 2024 at = 2:36=E2=80=AFAM Aijun Wang <wangaijun@tsinghua.org.cn&g= t; wrote:

H= i, John:

&= nbsp;

I have uploaded = the updated version at https://datatracker.ietf.org/doc/html/draft-ietf-pce-pc= ep-extension-native-ip-32 and wish it = address all your concerns.

If there is no = more comments, we can put forward it to the IESG LC review = then.

Thanks in advance = for your efforts!

 

Some detail = replies can see inline below.

 

&= nbsp;

B= est Regards

&= nbsp;

A= ijun Wang

C= hina Telecom

&= nbsp;

=E5=8F=91=E4=BB= =B6=E4=BA=BA: forwardingalgorithm@ietf.org [mailto:forwardingalgorithm@ietf.org] = =E4=BB=A3=E8=A1= =A8 =E3=80=90=E5=A4= =96=E9=83=A8=E8=B4=A6=E5=8F=B7=E3=80=91 John = Scudder
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2024=E5=B9=B47=E6=9C=8826=E6=97=A5 23:59
=E6=94=B6=E4=BB=B6=E4=BA=BA: Aijun Wang <wangaijun@tsinghua.org.cn>
=E6=8A=84= =E9=80=81: draft-ietf-pce-pcep-extension-native-ip@ietf.org; = pce@ietf.org; bhassanov@yahoo.com; fsheng@huawei.com; tanren@huawei.com; zhu.chun1@zte.com.cn
=E4=B8=BB=E9=A2=98= : Re: AD review of = draft-ietf-pce-pcep-extension-native-ip-30

 

Hi Aijun,

 

Thanks for the update. I have a few more comments, below. I = have trimmed for brevity, indicated by [=E2=80=A6], anything trimmed is agreed or anyway = doesn=E2=80=99t need more = discussion.

 

If you can update to reflect these comments I think we can = send it for IETF last call.

 

On Jul 22, 2024, at 5:37=E2=80=AFAM, Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:


Hi, = John:

I have updated draft according to your suggestions at =  https://urld= efense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep= -extension-native-ip__;!!NEt6yMaO-gk!B09SQ9s42Y1hsFo8BANfznJ4lysLpngvzlzw= p9ULLAbS_FzVRmaT6Jx-RsCqbWt6uHiW1t3973FwFYcuh7li0A$
For the = document track, I think it is OK to move it forward as the experimental = track, we will try to update it later to the standard track after its = experimental deployment.
The detail responses are inline = below=E3=80=90WAJ=E3=80=91

If = there is more suggestions, please let us know. Or else, can we schedule = the IESG Last Call then?


Best Regards

Aijun = Wang
China Telecom

 

[=E2=80=A6]

 

  =  During the establishment procedure, PCC should report to the PCE = the
   status of the BGP session via the PCRpt = message, with the status @@ -453,7 +547,16 @@
   When = PCC receives this message with the R bit set to 1 in SRP = object
   in PCInitiate message, the PCC should clear = the BGP session that is
   indicated by the BPI = object.
++---
+jgs: The term "clear the BGP session" = isn't standard (although it is
+common colloquial usage). Looking at = RFC 4271, in one place (Section 3)
+it does talk about = "resetting any BGP connections" so I think you would
+be on = firm ground if you want to say "reset". Or you might = consider
+referencing the AutomaticStop event (RFC 4271, Section = 8.1.2, Event 8).

=E3=80=90WAJ=E3=80=91=EF=BC=9A Here, = =E2=80=9Cclear the BGP session=E2=80=9D is just want to express the = deletion of the BGP configuration on PCC, not reset the BGP = connection.
Should it be more clearer, if we instead say "clear = the BGP session configuration"?------Have updated the descriptions = accordingly.

 

Yes, that=E2=80=99s an = improvement. This leaves it ambiguous whether the session should be torn = down immediately or not, do you intend that? E.g. in some = implementations, a configuration change is not reflected in the = operational state until a commit (or equivalent) is = performed.

=E3=80=90WAJ=E3=80=91How about = =E2=80=9Cthe PCC should clear the BGP = configuration and tear down the BGP session that is indicated by the BPI = object.=E2=80=9D? I think it is more clear. I = have updated the contents according to the above = statements.

[=E2=80=A6]

  =  Such explicit routes operate the same as static routes installed = by
   network management protocols (Network = Configuration Protocol
   (NETCONF)/YANG).  The = procedures of such explicit route addition and @@ -582,6 +689,9 = @@

   The PCInitiate message should be sent to the = on-path routers
   respectively.  In the example, = for explicit route from R1 to R7, the
++---
+jgs: What does = =E2=80=9Crespectively=E2=80=9D mean here? Can it be = removed?
=E3=80=90WAJ=E3=80=91Here, we = just want to describe such message should be sent every router on the = path, each may has different content, for example, the different next = hop information.

 

OK thanks. In that case, while removing the word = =E2=80=9Crespectively=E2=80=9D would be enough, I suggest you revise it to use the = language you=E2=80=99ve used above. That = is,

 

OLD:

   The PCInitiate message should be sent to the = on-path routers

  =  respectively.

 

NEW:

   The PCInitiate message should be sent to every = router on the 

   path.

&= nbsp;

=E3= =80=90WAJ=E3=80=91Done

&= nbsp;

[=E2=80=A6]

 

   BGP Peer Info Object-Class is = 46

 &n= bsp; BGP Peer Info Object-Type is 1 for IPv4 and 2 for IPv6 @@ = -1071,6 +1233,10 @@
      -  2: = Peer IP can't be reached, BGP Session = Failure

      -  3-255: = Reserved
++---
+jgs: Shouldn't you have a generic error code as = well, e.g. "0: Generic
+error", to catch cases other than = the ones described by 1 and 2?
++---
=E3=80=90WAJ=E3=80=91 What we = thought is the following, that if there is some new error that lets to = the BGP Session Failure, we should define exactly the code from the = reserved range.
The "generic" error gives no more detail = indication of the error reason. Is it right?

 

Right. In my experience, it=E2=80=99s hard to enumerate every possible error that could lead to = a session failure. It=E2=80=99s probably not = the best use of your efforts to try to come up with a comprehensive = list, even the BGP document set itself doesn=E2=80=99t contain one, consider the list of OPEN error subcodes (https://www.iana.org/assignments/bgp-parameters/bgp-par= ameters.xhtml#bgp-parameters-6). The first one is = =E2=80=9Cunspecific=E2=80=9D. In my view, when an implementor encounters a case where = the error isn=E2=80=99t one that has a = specific mapping in the error codes, it=E2=80=99s better for them to still be able to send an error, and = it=E2=80=99s better for the code to be = =E2=80=9Cunspecific=E2=80=9D or =E2=80=9Cgeneric=E2=80=9D than it is for = them to choose an error code that is = *wrong*. 

 

I agree that the ideal is to never need to use the generic = code, but if the need does arise, it=E2=80=99s = better to use the generic code than a wrong = code.

=E3=80=90WAJ=E3=80=91Thanks for your = advice. I have changed the code 0 as =E2=80=9Cunspecific=E2=80=9D

 


 &n= bsp;    Flag: 1 Byte.

@@ -1104,6 +1270,12 = @@
   establish the BGP session with the peer in = AFI/SAFI=3D2/1.

7.3.  Explicit Peer Route = Object
++---
+jgs: you describe this object as "peer = route", but isn't it just a
+generic host route, in your = architecture you happen to use for BGP
+peers? It seems to me it = would be a more accurate description if you
+replaced the word = "Peer" with "Host" throughout this = section.
++---
=E3=80=90WAJ=E3=80=91: Here, the = "Peer Route" just wants to emphasize the route is to the peer, = although actually is a host route( to the peer).
Describe it solely = only with "Host" can't have such refer and maybe mislead to = the reader? We would like to keep it in this way?

 

The problem with this is that although in your = implementation you might only plan to use it for installing a route to = the peer, some other implementation might choose to use it for something = different. History shows that when a generic mechanism is introduced, it = is often used in ways the inventors didn=E2=80=99t intend. So, my preference is you use an accurate = description. Maybe a happy medium would be to make the suggested change = but also add descriptive text clarifying the intended use? Something = like,

 

OLD:

   The Explicit Peer Route object is defined to = specify the explicit

   peer route to the corresponding peer address = on each device that is

   on the E2E Native-IP TE path.  This = Object should be sent to all the

   devices on the path that is calculated by the = PCE.

 

NEW:

   The Host Route object is defined to install a = host route to the 

   corresponding peer address on each device that = is

   on the E2E Native-IP TE path.  This = Object should be sent to all the

   devices on the path that is calculated by the = PCE.  Although this

   object could be used to install host routes = for other purposes, 

   any such use is outside the scope of this = specification.

 

The other way would be to retain the name but add a = different explanation, as in,

 

NEW:

   Although the object is named = =E2=80=9CExplicit Peer = Route=E2=80=9D, it can be = seen

   that the routes it installs are simply host = routes. The use of this

   object to install host routes for any purpose = other than reaching the

   corresponding peer address on each device that = is on the E2E

   Native-IP TE path is outside the scope of this = specification.

 

My preference is the first approach but either one works = for me. If one of them is ok for you, just pick it and proceed = forward.

=E3=80=90WAJ=E3=80=91Considering to limit = the change in smaller scope(other parts within the document, the IANA = temporarily allocation etc.) and reduce the risk of mismatch, I select = the second approach.------And, there is another consideration, that is, = to accomplish the overall task that described in this document, we must = install the route to the peer on every router on the path, not arbitrary = host route that name =E2=80=9CHost Route = Object=E2=80=9D which may be = mishandled.

 

  =  The Explicit Peer Route object is defined to specify the = explicit
   peer route to the corresponding peer = address on each device that is @@ -1189,7 +1361,18 = @@
      establishment.  No TLVs = are currently defined.

7.4.  Peer Prefix Advertisement = Object
++---
+jgs: It appears there is an assumption that IPv4 = routes will be sent
+over an IPv4 peering, and IPv6 routes will be = sent over an IPv6 peering.
+This might be problematic especially for = IPv4 routes, if the provider
+network doesn=E2=80=99t use IPv4 in the = underlay and uses tunnel mode to carry
+IPv4 traffic across an IPv6 = backbone.

+Well this restriction doesn't seem necessary to me, I = think it would be
+OK to flag it without correcting, if you switch to = the Experimental
+track.
++---
=E3=80=90WAJ=E3=80=91It is = possible to mix the carrier's transport address family with different = address family of the actual traffic.

 

Are you saying that this is possible with the protocol you = specify here? Can you outline how? As far as I could see, if my BGP = session is between IPv6 loopbacks, only IPv6 prefixes can go in the = Prefix Advertisement Object, and simiilarly for = IPv4.

 

On the other hand if you=E2=80=99re just saying that this is possible in real networks, even = though your protocol can=E2=80=99t support it, = then we agree.

 

And, again, = we want to simplify the parameter negotiations between the PCCs(and = PCE), then solidify the encoding as IPv4 traffic is carried by IPv4 = transport, and the same as for IPv6 address family. Anyway, the devices = within the operator network all support such behavior, but not all of = them support the hybrid comination.

 

As I said in my earlier comment, I=E2=80=99m ok with the restriction given the Experimental track. I = do think you need to flag it though. For = example,

 

NEW:

   If in the future, a requirement is identified = to advertise IPv4

   prefixes towards an IPv6 peering address, or = IPv6 prefixes towards an

   IPv4 peering address, then new Peer Prefix = Advertisement Object-Types

   can be defined for these = purposes. 

=E3=80=90WAJ=E3=80=91This is what my exact = meanings. I have updated the content accordingly as your = suggestions.

 

[=E2=80=A6]

 

@@ -1637,7 = +1827,48 @@
   validity of the PCE and ensure a secure = communication channel between
   them.  Thus, the = mechanisms described in [RFC8253] and = [RFC9050]
   should be used.
++---
+jgs: I = appreciate that you are trying to provide bare-bones BGP = session
+establishment here, and I see the text in Section 9 that = says,

+   This document defines the procedures and = objects to create the BGP
+   sessions and advertise the = associated prefixes dynamically.  Only the
+   key = information, for example peer IP addresses, peer AS number are
+ =   exchanged via the PCEP protocol.  Other parameters that = are needed
+   for the BGP session setup should be derived = from their default
+   values.
+
+but your design = makes it impossible to provide transport security, such
+as TCP-AO, = because although there is a way to tell the PCC what its BGP
+peer = is, there is no way to tell the PCC what key to use in
+communicating = with that peer. In the case of session keying, it's not
+reasonable = to suggest the key should be "derived from their = default
+values". Even if the practice of using a single default = key for all
+internal sessions is used (and I'm not saying that would = be a best
+practice!), this simply can't work for EBGP, and you do = propose to
+cover EBGP.
+
+If you do switch to the Experimental = track, in my opinion, something
+like the following would be = adequate:
+
+NEW:
+   Because this specification does = not provide a way to communicate
+   properties beyond peer = address and AS number for the BGP sessions
+   that are = established, it will not always be possible to follow best
+ =   practices as described in [BCP194], if suitable default = values as
+   discussed in [Section 9] cannot be used. An = example would be keying
+   for use with TCP-AO = [RFC5925].
+
+   If such functionality is required in = the future, it can be provided
+   through the addition of = optional TLVs to the BGP Peer Info object,
+   that convey = the necessary additional information (for example, a key
+ =   chain [RFC8177] name).
+
+Note, it's just my opinion = that this would be good enough, other
+reviewers might have their own = thoughts (notably SECDIR and the SEC
+ADs).
++---
=E3=80=90WAJ=E3=80=91=EF=BC=9AYes, we = plan to add additional TLV to convey the information about the secure of = the BGP session. I think your recommendation is appropriate for the = security considerations. I have adopted part of your recommendation text = as the followings:
If suitable default values as discussed in section = 9 isn't enough and securing the BGP transport is required(for example, = the TCP-AO(RFC5925), it can be provided through the addition of optional = TLV to the BGP Peer Info object that convey the necessary additional = information(for example, a key chain(RFC8177) name

 

Cool. I think it is OK to make RFC 8177 an informative = reference, since it=E2=80=99s only a = =E2=80=9Cfor example=E2=80=9D.

=E3=80=90WAJ=E3=80=91Done

 

 

_______________________________________________
Pce = mailing list -- pce@ietf.org
To unsubscribe send an email to pce-leave@ietf.org

------=_NextPart_000_00AB_01DAE297.48378C70--