Hi Jorge, Thanks for the quick response. I’m fine with with replies, just on:
“ Section 5.2: When gateway PE receives a route from iBGP and re-advertises to iBGP, do you consider that it’s doing route-reflection and should apply the RR procedures related to OriginatorID and cluster list attributes ? It should probably be clarified if it’s the case or not. [jorge] no, it is not a route reflection. The gateway has VRFs, installs the ISF routes from the received ibgp route and reoriginates the ibgp route. This existing point should address your comment, but let us know if it is not the case: "When propagating an ISF route to IBGP peers, the gateway PE SHOULD keep the IBGP-only Path Attributes from the originating route to the re-advertised route." “ In fact, when reading it, it was not fully clear if having one side being RRC was still required or not and the “propagation” keyword used in the sentence is not helping, it’s not really propagation but re-origination. May be a small sentence would clarify such as “As the route ISF route is re-originated, route-reflector function [RFC4456] is not required on the gateway PE.” Brgds, Stephane From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> Sent: Tuesday, January 28, 2025 2:23 PM To: Stephane Litkowski (slitkows) <slitk...@cisco.com>; draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org; bess@ietf.org Subject: Re: Review of draft-ietf-bess-evpn-ipvpn-interworking-12 Hi Stephane, Thanks for the review. We made the changes required to address your comments and will be published in version 13. Since there is a short last call being held on version 12, we will publish version 13 shortly after the end of the last call, along with any other comments suggested by the WG. Please find below my comments with [jorge]. From: Stephane Litkowski (slitkows) <slitk...@cisco.com<mailto:slitk...@cisco.com>> Date: Monday, January 27, 2025 at 2:19 AM To: draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org<mailto:draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org> <draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org<mailto:draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Subject: Review of draft-ietf-bess-evpn-ipvpn-interworking-12 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Authors, Please find below my last review of draft-ietf-bess-evpn-ipvpn-interworking-12. Introduction: s/that the end to end tenant/that the end-to-end tenant [jorge] changed in abstract and introduction. Section 4: b. Bullet 2: I would clarify that <DOMAIN-ID:ISF_SAFI_TYPE> to be added is the one associated with the received path. The third bullet provides an example and we should make the normative statement more clear IMO. [jorge] I modified it as follows: "Whenever a prefix arrives at a gateway PE in a particular ISF SAFI route, if the gateway PE needs to export that prefix to a BGP peer, the gateway PE MUST prepend a <DOMAIN-ID:ISF_SAFI_TYPE> to the list of domains in the D-PATH of the received route, as long as the gateway PE works in Uniform-Propagation-Mode, as explained in Section 5.2<https://author-tools.ietf.org/api/export/1db2b7cb-b8e5-4649-acf2-6d02b139c3a2/draft-ietf-bess-evpn-ipvpn-interworking-13.html#sect-5.2>." g. I would rephrase: s/”A received D-PATH attribute is considered malformed if it”/ “A received D-PATH attribute MUST be considered malformed if it” s/“A domain segment is considered as malformed in …”/“A domain segment MUST be considered as malformed in …”/ s/“The D-PATH attribute MUST be at least 8 octets in length or it is malformed.” /“The D-PATH attribute length is less than 8 bytes”. [jorge] took all the suggestions. g. 5. What is the procedure if multiple D-PATH attribute are present ? [jorge] follow RFC7606, but I added this text explicitly: "The D-PATH Path Attribute MUST NOT occur more than once in the BGP UPDATE's Path Attributes. If the D-PATH Path Attribute appears more than once in an UPDATE message, then all the occurrences of the attribute other than the first one are discarded and the UPDATE message will continue to be processed, as per [RFC7606<https://author-tools.ietf.org/api/export/8f97cfdd-d3d3-4d42-abd4-8c09712ae4c5/draft-ietf-bess-evpn-ipvpn-interworking-13.html#RFC7606>]." g. 6. The written statement requires update of code for all other address-families (even outside context of gateway PE). Is it realistic ? [jorge] this was really part of the IDR chair review. Since the attribute modifies the best path selection, the IDR chairs wanted to restrict the use of D-PATH to an IPVPN/EVPN "walled garden” and make sure it does not leak outside the walled garden. The whole code change because of the revision agreed with the IDR chairs is underway. For instance, we already changed two implementations because of that. I think others are doing the same. Section 5.2: When gateway PE receives a route from iBGP and re-advertises to iBGP, do you consider that it’s doing route-reflection and should apply the RR procedures related to OriginatorID and cluster list attributes ? It should probably be clarified if it’s the case or not. [jorge] no, it is not a route reflection. The gateway has VRFs, installs the ISF routes from the received ibgp route and reoriginates the ibgp route. This existing point should address your comment, but let us know if it is not the case: "When propagating an ISF route to IBGP peers, the gateway PE SHOULD keep the IBGP-only Path Attributes from the originating route to the re-advertised route." Bullet 5. Have we considered how it works in case of ADD-PATH being used in advertising domain ? [jorge] the document does not introduce any modification in the way of using ADD-PATH, that’s why we didn’t think there is a need to say anything about it. Section 8. 1 d) s/ ISAF SAFI-y/ ISF SAFI-y [jorge] fixed, thanks. Thanks! Jorge Brgds, Stephane
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
