Re: [bess] [Idr] FW: Review of draft-ietf-bess-evpn-ipvpn-interworking-05.txt

[Susan Hares <[e-mail]>]

Jorge:

Thank you for responding late last night.   IETF draft day is so busy.

Let's plan to meet briefly at 2pm so I can confirm your answers on EBGP/IBGP issues.  One  big question is the lack of an OPEN Capability for DPATH.

After we chat, I'll work on the write-up (word doc and xml) for your document.

Sue Hares


From: Rabadan, Jorge (Nokia - US/Sunnyvale) <[e-mail]>
Sent: Tuesday, July 12, 2022 3:52 AM
To: Susan Hares <[e-mail]>; UTTARO, JAMES <[e-mail]>; [e-mail]
Subject: Re: [bess] [Idr] FW: Review of draft-ietf-bess-evpn-ipvpn-interworking-05.txt

Hi Sue, Sorry for missing your email. Please see my comments with [jorge4]. Thanks. Jorge From: BESS <[e-mail]<mailto:[e-mail]>> on behalf of Susan Hares <[e-mail]<mailto:[e-mail]>>Date: Monday, July 11
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzU1ODAwN2RlMzFlYzRjYmJiNmUwZjUzODg4OTFjNjk1LzE2NTc2MTIzMTQuNzg=#key=575a8d22fa92b12598b88663b2699240>  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

Hi Sue,

Sorry for missing your email. Please see my comments with [jorge4].

Thanks.
Jorge

From: BESS <[e-mail]<mailto:[e-mail]>> on behalf of Susan Hares <[e-mail]<mailto:[e-mail]>>
Date: Monday, July 11, 2022 at 1:58 AM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[e-mail]<mailto:[e-mail]>>, UTTARO, JAMES <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] [Idr] FW: Review of draft-ietf-bess-evpn-ipvpn-interworking-05.txt
Jorge:

Maybe I was too brief with the first sentence - so let me try again.

I hit something in the text where I need additional details before finishing my shepherd's comments.  If you can get back to me early on Monday (by 11am PDT), I can finish the shepherd details we talked about.

Sue


From: Susan Hares <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, July 10, 2022 5:41 PM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; Rabadan, Jorge (Nokia - US/Sunnyvale) <[e-mail]<mailto:[e-mail]>>; UTTARO, JAMES <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: [bess] [Idr] FW: Review of draft-ietf-bess-evpn-ipvpn-interworking-05.txt

Jorge:

I hit place where I need additional details before finishing my shepherd's comments.

If you get time today (Sunday), could you let me know how the Domain relates to IBGP or EBGP in BGP.  If your domain BGP Path Attribute is exchanged within Pes in a single AS (or AS confederation), this should be clearly specified.
[jorge4] the gateway model does not impose any limitation, that's why we define the concept of a domain, where a domain:

  *   May map to an AS or AS confederation
  *   May map to an IGP instance
  *   But an AS or AS confederation could also contain multiple domains
The gateway PE can have IBGP, EBGP or both types of sessions.
As an example, a DC Gateway is a use-case of a gateway PE. And DC Gateways use IBGP or/and EBGP.

[Sue4] - Thank you for your response. Error handling and loop detection rules are different for IBGP (within an AS),  between ASes (E-BGP) .
                Your document must acknowledge this difference.  You must also indicate if this interacts with a Route Reflector.
If you are focused on an IGP instance rather than an AS, why are you using BGP?

If your BGP routes (EVPN, IPv4-VPN, IPv4, IPv6, IPv6-VPN) have domain boundaries where PE-gateways always use EVPN, then this should be clearly specified.
If your domain boundaries are either in IBGP or EBGP, this should be specified.
I cannot tell based on figure 3, figure 4, or figure 5, figure 7, or figure 8, or figure 9.

[jorge4] it is not specified because the document does not impose any type.
                    Would something like the text in my previous comment help?

[Sue]:  An example needs to be clear.  There are two options could fix this:
            a) clearly indicate one example with AS boundaries  (IBGP, EBGP, RR)
            b) Give a generic example (as you have) with EBGP and IBGP
               and also provide specific examples to an appendix and specify several useful formats.


Section 5.2 speaks about importing routes and propagating routes with IBGP-only Path attributes.   This leads to my confusion.
[jorge4] ok, that can be clarified further, but that's why that section 5.2 specifies what to do if the gateway has an IBGP or an EBGP peer for attributes that have special consideration depending on whether the peer is IBGP or EBGP:

   2.  When propagating an ISF route to a different IBGP peer, the
       gateway PE SHOULD keep the AS_PATH of the originating ISF route
       and add it to the destination ISF SAFI without any modification.
       When re-advertising to an EBGP peer, the gateway PE SHOULD keep
       the AS_PATH of the originating ISF route and prepend the IP-VRF's
       AS before sending the route.

   3.  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.

[Sue]: The link to specific eBGP and iBGP propagation rules and error handling is unclear.
       You also do not cover the case of IBGP Route Reflectors versus this Domain.


Your text in section 6 that modifies RFC4271, is using the D-PATH to remove routes from consideration.
[jorge4] yes, one of the authors (Eric) suggested that wording (following RFC4271) that we thought it was appropriate.
[Sue]:  Are you mandating this change for all BGP routers, or just the ones that indicate the capability for D-PATH?

In section 6, example 1, has route selection on routes with the same AS Path (100, 200).
In section 6, example 2, has a route with a longer AS path (100,200), SAFI=EVPN, D-PATH(6500:3:IPv6) being selected due to the default policy on D-PATH.

Is PE1 exchanging these routes in an E-BGP connection or an I-BGP connection?
[jorge4] the document updates RFC4271 by inserting the D-PATH tie-breaker just before the phase 2 tie-breaker (a) of the decision process (section 9.1.2.2 of RFC4271).
[Sue4] This part was clear, but see comments above with question.

That is why in section 6, step 1 specifies the D-PATH as tie breaker before step 2, which includes all the tie-breakers in section 9.1.2.2 of RFC4271. After step 2, steps 3 and 4 are specific to this document. The new rules defined in this document apply to routes received from an IBGP or EBGP peer.
[Sue4] For all BGP routers everywhere or just routers that support the DPATH capability?
            If you specify all routers, then how are you handling routers that do not understand DPATH?
            What about a domain that has half DPATH capable routers and half routers that do not understand DPATH?
            Where is the OPEN capability that specifies this function?

Step 2 refers to RFC4271, which specifies how to apply the rules based on whether the routes are received from an IBGP or EBGP peer.
About the examples, they do not specify if the routes are received from an IBGP or EBGP peer, but example 1 should be for routes from IBGP peers (Local-Pref is not expected from an EBGP peer unless Confederations are used) and example 2 for routes from EBGP peers (although it could be from IBGP too). Would that clear the concern if we clarify that?

[Sue4] The text and the examples must specify clearly the rules.

[Sue3]  I'm thrilled to see the multiple vendors supporting this work:


PATH solves loops in a multi-vendor environment:
EANTC-InteropTest2022-TestReport.pdf<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJw9j11PwjAUhv8KLF7KunW0G3oDA0OGBCLMQLxZuvXUTUY728r8iP9dhsa78z5v8py8X86brp2bnlNa25gbhM6RgwBpwC3UEZ0ClGV_HTBpC5cDElUNjB8r-YsQV62sFeMGwQmkNQh7GKO7ySqdDhJpQasmBWM7OuiODTRKW7fhIstu-_245GlfKrHH1LxvApxCVUVtu9lmOV0tD3buEbNOnmq9jxPyuguteJCTXewtDNkG1YfIp5QUq_vFbGbj-eMCdskyXAftlXPdcw7dNglW6WffIxEd-RiZkmkwY8k_y8tGQiLPCzkEPhTDIs9zCp4gQRRFI7-gI4J8SkLq48AfumHUWaGzvpyd4GqWM87kWKpDxTpd1_PL13_y_QO8H3IW.MEQCIHTX5O3tBBiKgi3rcWAkYcxFsVdflG2LbsK_YPWDwnRAAiBynS2WZ2-PeUKSinbQPMMpZRCUjs-Yo-P2Vk1qS0UlgA>

Please check out sections: "EVPN and IP-VPN Interworking" or "IPVPN over SRv6/EVPN RT5 over SR-MPLS Interworking"

It would be good to have a IDR style implementation report.  I can help you collect the data into that format.



[jorge4] sure, happy to do so.



One problem,  EANTC diagrams do not show the AS boundaries or the details of the AS tests.



Let me know so that I can still complete this work on Monday.

[jorge4] obviously Monday is gone. Let me know if you want to still meet on Tuesday or we move it to Wednesday.

More comments below.



[Sue4] Let's meet briefly on Tuesday at 2pm to make sure I understand this work.



Sue

From: BESS <[e-mail]<mailto:[e-mail]>> On Behalf Of Susan Hares
Sent: Thursday, July 7, 2022 11:27 AM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[e-mail]<mailto:[e-mail]>>; UTTARO, JAMES <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [bess] [Idr] FW: Review of draft-ietf-bess-evpn-ipvpn-interworking-05.txt



Jorge:

I've included short answers below for the first section. I'll send additional comments to you privately.
I'll work on a word document late today,  but if you send me XML for the document I will also edit in changes directly to the XML.

The sending of changes in word and XML has speed up other teams.   I look forward to chatting with you on July 12 and 13.

Sue

From: Rabadan, Jorge (Nokia - US/Sunnyvale) <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, July 7, 2022 9:58 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; UTTARO, JAMES <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [bess] [Idr] FW: Review of draft-ietf-bess-evpn-ipvpn-interworking-05.txt


Hi Sue,

Thanks for your prompt reply, it helps me understand better some of your points.
Please see some answers in-line with [jorge3].

Thx
Jorge

From: Susan Hares <[e-mail]<mailto:[e-mail]>>
Date: Thursday, July 7, 2022 at 2:38 AM
To: UTTARO, JAMES <[e-mail]<mailto:[e-mail]>>, Rabadan, Jorge (Nokia - US/Sunnyvale) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [bess] [Idr] FW: Review of draft-ietf-bess-evpn-ipvpn-interworking-05.txt
Jorge:

I want to get back to you quickly just in case you wanted to finish these edits before the IETF Draft deadline.

I agree with you that this method of critique and then responses 3 months later is working well.  It is not resolving my concerns, and it is slowing down the publication of the draft.  A draft that lingering does not benefit your author team or BESS WG.
[jorge3] this is my bad, (and my day-to-day job's fault), my apologies again. No need to publish before the cut-off, I prefer to make sure we address all your concerns and then make sure all the co-authors are good with the changes before we publish.
[Sue-v3] Sounds like a good plan.

I used the diff created by the mechanisms to check for specific differences between version -06 and -07.
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-ipvpn-interworking-07.txt<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJw9zcsOwiAQBdBfMazl1QqlJkZ_hcdgsUobQGs0_rvFhZu7mDs5943u6Yr2GzSUMuc9pcuykADFkymdafLWBe-P609zcEn7gmuHDeSM4TFHHOZfxgJpmdIY4hmzjpRnQdsNGiscoawUZ0LJnjc0DzpBPkX3GoidblQIxVjnoOVgd9YYI4F50Sqlem5lLyiXopO8afmOdKqqUNXLagJJ2min4ylOY9CVq737rf4vny-gvEgL.MEYCIQDzB9ECp24XAFo34fgKzO5kEDjX9ql0VRM_1PNa1ATbKwIhAPLBvm592meU3eg_HJSiw9yI0nle-BC4AeBHG5nmNon3>

In order to quickly respond to you, I have answered just the first section.  My comments to your changes are marked as sue-v2.  I can see you have tried to address my concerns, but not all the concerns have been addressed.

I will gladly meet with you Thursday or Friday this week to walk through my concerns so you can publish.  I'm open except for 7-9am PDT (10-12am PDT) for my IDR Chairs meeting.  If you agree to meet, I'll provide you with a marked up set of text.  Just let me know what form you want the mark-up in. Word works best for me.
[jorge3] word is good. I'll contact you offline to schedule a meeting. Thank you so much!
[Sue-v3] Sounds good

I have three types of concerns:
a) Lack of specific definitions in key terms (e.g. ISF) or in the document header.
b) Clearly defined BGP Attribute (my main concern)
c) Confusing text that may/may not be technical issues

This is category "c" are optional, but I am flagging these because John and Alvaro are careful reviewers.

Examples of these type of concerns
=====================
Technical issue to start with:
Type-a)  ISF route does not provide specific AFI/SAFs.

    ISF route: a route for a given prefix, whose ISF SAFI may change
      as it transits different domains.  BGP IP routes as in [RFC4760<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJw9zUsSgyAQBNCrWKxTDKh8dOVVBhiD0UgKySap3D2SRbbd1a_f7Jk3NjYslvI4RoCABUtGv1LmC5WZp3yFkDzEct8gz743WrBLw9a62qmcvRTK6kG2cETMdEx7eEXu0x2UskKYQJ0k33vnnCYxq85aO0ivBwVSK6Nl28meG1tVqurtNIlndBhwn_a0Lli52off6z_5fAGcOzo6.MEUCIQCaiM_b-dXl1uP9FsssCCu2LLu4m5mx4kaL7aRqquKUKQIge2fo7AnRy4784BJ78Son-TEknh7Xc_RpUjS04FgNiiE>]
      [RFC8950<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJw9zUEOgyAUBNCrGNYNH1QQXHmVD3yL1UqDdNOmd6900e1M5s2bPfPGxobFUh7HCBCwYMnoV8p8oTLzlK8QkodY7hvk2RurBLs0bK2rncrZS6GMtrKFI2KmY9rDK3Kf7qCUEWII1EnyvXfOaRKz6owxVnptFUitBi3bTvZ8MFWlqt5Ok3hGhwH3aU_rgpWrffi9_pPPF58BOj8.MEUCIDMWFZZz5pSJ3TcDFSP1Ictrqt8Mx0rTujROflxTgBx3AiEAlaM20F2ER6mWmGBivQELKt220TWc_DXTrKKy6Mf8eog>] IPVPN routes as in [RFC4364<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJw9zUkSwiAUBNCrpFhbfAhDSFa5CsOPxESwCG60vLvBhdvu6tdv8iw7mToSa30cE0Cw1dZi_YaFrlgXmssVQvYQ632HsngptCSXjmxtlbCePWfK6JH3cERb8JhTeEXq8x2UMowNAQVHL71zTiNblDDGjNzrUQHXatC8F1zSwTQVm3o7TaTFOhtsmlPeVtu41off6z_5fAGcMzo6.MEUCICHSF-esuVDwQKzqnwj76PRRBvW2Or-OVPkSjihCQbHmAiEAyZoYk0vCQunzEvtw3_I6nLcnmLua0zCWJlqsCb2RgXM>] [RFC4659<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJw9zUEOgyAUBNCrGNYNH1QQXHmVD3yL1UqDdNOmd6900e1M5s2bPfPGxobFUh7HCBCwYMnoV8p8oTLzlK8QkodY7hvk2fdaWXZp2FpXO5Wzl0IZbWULR8RMx7SHV-Q-3UEpI8QQqJPke--c0yRm1RljrPTaKpBaDVq2nez5YKpKVb2dJvGMDgPu057WBStX-_B7_SefL6AFOkE.MEUCIDhMFoQNaxXbrHgVGbJPqVYMkQ0LNKnXeZF4P4Q7A4I0AiEArsX6jeiB1E_72ztKVygd5Mjpnq7hsezvwSdtWLNiNoA>] or EVPN IP
      Prefix routes as in [RFC9136<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJw9zT0SgyAUBOCrONQZHoggWHkVfp7BaCCDpEkmd4-kSLs7--2bPMtOpo7EWh_HBBBstbVYv2GhK9aF5nKFkD3Eet-hLN5wocilI1tbJaxnz5nUyvAejmgLHnMKr0h9voOUmrExoODoB--cU8gWKbTWhntlJHAlR8V7wQc66qZiU2-nibRYZ4NNc8rbahvX-vB7_SefL51ROjw.MEQCIHw3YihP5OtqRf98KxesdXhwGkd1slSUcuOBUVlyaI-CAiA1YuzjR6weiQeiSTMoOZh0D_UJMTZBvTtjE1-sEBSYbg>] are considered ISF routes in this
      Document.

This definition is not specific for the AFI/SAFIs.
Please give a specific definition of the AFI/SAFIs supported some place in your
Document.
[jorge3] I thought the above definition of ISF route along with the definition of ISF SAFI was enough to identify the AFI/SAFIs affected by the spec. We can discuss how to improve the current definitions:

   o  ISF SAFI: Inter-Subnet Forwarding (ISF) SAFI is a MP-BGP Sub-
      Address Family that advertises reachability for IP prefixes and
      can be used for inter-subnet forwarding within a given tenant
      network.  The ISF SAFIs are 1 (including IPv4 and IPv6 AFIs), 128
      (including IPv4 and IPv6 AFIs) and 70 (EVPN, including only AFI
      25).  This document uses the following terms interchangeably: ISF
      SAFI 1 or BGP IP, ISF SAFI 128 or IPVPN, ISF SAFI 70 or EVPN.

   o  ISF route: a route for a given prefix, whose ISF SAFI may change
      as it transits different domains.  BGP IP routes as in [RFC4760<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJw9zUsSgyAQBNCrWKxTDKh8dOVVBhiD0UgKySap3D2SRbbd1a_f7Jk3NjYslvI4RoCABUtGv1LmC5WZp3yFkDzEct8gz743WrBLw9a62qmcvRTK6kG2cETMdEx7eEXu0x2UskKYQJ0k33vnnCYxq85aO0ivBwVSK6Nl28meG1tVqurtNIlndBhwn_a0Lli52off6z_5fAGcOzo6.MEUCIQCaiM_b-dXl1uP9FsssCCu2LLu4m5mx4kaL7aRqquKUKQIge2fo7AnRy4784BJ78Son-TEknh7Xc_RpUjS04FgNiiE>]
      [RFC8950<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJw9zUEOgyAUBNCrGNYNH1QQXHmVD3yL1UqDdNOmd6900e1M5s2bPfPGxobFUh7HCBCwYMnoV8p8oTLzlK8QkodY7hvk2RurBLs0bK2rncrZS6GMtrKFI2KmY9rDK3Kf7qCUEWII1EnyvXfOaRKz6owxVnptFUitBi3bTvZ8MFWlqt5Ok3hGhwH3aU_rgpWrffi9_pPPF58BOj8.MEUCIDMWFZZz5pSJ3TcDFSP1Ictrqt8Mx0rTujROflxTgBx3AiEAlaM20F2ER6mWmGBivQELKt220TWc_DXTrKKy6Mf8eog>] IPVPN routes as in [RFC4364<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJw9zUkSwiAUBNCrpFhbfAhDSFa5CsOPxESwCG60vLvBhdvu6tdv8iw7mToSa30cE0Cw1dZi_YaFrlgXmssVQvYQ632HsngptCSXjmxtlbCePWfK6JH3cERb8JhTeEXq8x2UMowNAQVHL71zTiNblDDGjNzrUQHXatC8F1zSwTQVm3o7TaTFOhtsmlPeVtu41off6z_5fAGcMzo6.MEUCICHSF-esuVDwQKzqnwj76PRRBvW2Or-OVPkSjihCQbHmAiEAyZoYk0vCQunzEvtw3_I6nLcnmLua0zCWJlqsCb2RgXM>] [RFC4659<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJw9zUEOgyAUBNCrGNYNH1QQXHmVD3yL1UqDdNOmd6900e1M5s2bPfPGxobFUh7HCBCwYMnoV8p8oTLzlK8QkodY7hvk2fdaWXZp2FpXO5Wzl0IZbWULR8RMx7SHV-Q-3UEpI8QQqJPke--c0yRm1RljrPTaKpBaDVq2nez5YKpKVb2dJvGMDgPu057WBStX-_B7_SefL6AFOkE.MEUCIDhMFoQNaxXbrHgVGbJPqVYMkQ0LNKnXeZF4P4Q7A4I0AiEArsX6jeiB1E_72ztKVygd5Mjpnq7hsezvwSdtWLNiNoA>] or EVPN IP
      Prefix routes as in [RFC9136<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJw9zT0SgyAUBOCrONQZHoggWHkVfp7BaCCDpEkmd4-kSLs7--2bPMtOpo7EWh_HBBBstbVYv2GhK9aF5nKFkD3Eet-hLN5wocilI1tbJaxnz5nUyvAejmgLHnMKr0h9voOUmrExoODoB--cU8gWKbTWhntlJHAlR8V7wQc66qZiU2-nibRYZ4NNc8rbahvX-vB7_SefL51ROjw.MEQCIHw3YihP5OtqRf98KxesdXhwGkd1slSUcuOBUVlyaI-CAiA1YuzjR6weiQeiSTMoOZh0D_UJMTZBvTtjE1-sEBSYbg>] are considered ISF routes in this
      document.

[Sue]  My understanding is that you are not defining a new SAFI.
           Since routes are based on AFI/SAFI pairs, your text is a bit confusing.
           I think you mean that you support the following AFI/SAFI pairs:
           IPv4 (1/1), IPv6 (2/1), IPVPN (1/128), IPv6 VPN (2/128),
           EVPN (25/70).

          Your use of the SAFI is abnormal (and I suspect the RFC editor would find it incorrect).
          Your specifications defines the procedures to transform routes between AFI/SAFI formats
          at gateways supporting this feature.   It would be better to restate this as a ISF Route
          and list the AFI/SAFIs that the gateways transform.
[jorge4] ok, I'll work on improving the wording.

It is surprising that you do not signal this capability on
         the BGP open with a capability so that BGP peers know they are working with a peer that can support
         this capability.   Perhaps we can chat about why you do not signal this on an OPEN?
[jorge4] we didn't see a reason to signal the support for this Path Attribute in a capability. Actually the desired behavior is that the attribute is optional transitive. We can chat more about it.



Type-b ) Domain Path Attribute

Here are 11 concepts I expect to find in the definition of a new BGP Attribute:
[jorge3] we can be explicit about each and every of these points, but I'm replying your questions below one by one.
[Sue3] given the answers the answer below, I will go through the document making comments.
            I'll send suggestions

1) What AFI/SAFI does your specification guarantee this
     Attribute works with?
     Given ISF route definition, it is unclear.
[jorge3] as per the definition of ISF route and ISF SAFI: SAFIs 1 (including IPv4 and IPv6 AFIs),
128 (including IPv4 and IPv6 AFIs) and 70 (EVPN, including only AFI 25).
[Sue3]: See my comments above.

2) What other attributes does the attribute conflict with?
     See section 5 for some of your restrictions on attributes being passed.

[jorge3] no conflicts with other attributes are imposed for D-PATH
[Sue3]:  Your document should specifically define interactions with all other attributes in a section.
The section can be very short.  In IDR WG, we would ask you to provide an implementation report.
[jorge4] it would be great if you can point at any other IDR draft/RFC that defines a new attribute and has that section. We can use it as a model for this document. Otherwise could you provide an example?

              3) What attributes does the attribute work with given your specification?
     (some, none or all)?
[jorge3] no restrictions are imposed by D-PATH
[Sue3] see answer to #2.  Just be clear that you work with all current attributes defined.


4) What attribute field checking is done to check for malformed attribute in the PDU?
[jorge3] the domain segment length of the last domain segment, as per section 4g:
       1.  A received D-PATH attribute is considered malformed if it
           contains a malformed Domain Segment

       2.  A Domain Segment is considered malformed in any of the
           following cases:

           *  The Domain Segment length of the last Domain Segment
              causes the D-PATH attribute length to be exceeded.

           *  After the last successfully parsed Domain Segment there
              are less than eight octets remaining.

           *  The Domain Segment has a Domain Segment Length of zero.

[Sue3] What happens if the total length of the attribute is wrong?
[jorge4] I think the total length can be wrong only if the domain segment length of the last domain segment makes the total length to be exceeded, which is captured above.
                What happens

5) What error handling occurs when the attribute is malformed or
     duplicated?  (logging, dropping attribute, etc.)
[jorge3] if malformed, as per section 4g:
       3.  A PE receiving an UPDATE message with a malformed D-PATH
           attribute SHALL apply "treat-as-withdraw" [RFC7606<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJw9zUsSgyAQBNCrWKxTDKh8dOVVBhiD0UgKySap3D2SRbbd1a_f7Jk3NjYslvI4RoCABUtGv1LmC5WZp3yFkDzEct8gz95oodmlYWtd7VTOXgpl9SBbOCJmOqY9vCL36Q5KWSFMoE6S771zTpOYVWetHaTXgwKpldGy7WTPja0qVfV2msQzOgy4T3taF6xc7cPv9Z98vp1SOjw.MEYCIQDR-rR2ToY4z3wDO4AAVqDiAVbh-mygLEflO8tccx7RVQIhAOXDxgLA0KorOm_KYXGgLakdeSZUckKJtE03S4I_GUZa>]


[Sue] this is a reasonable mechanism (editorial note your numbering in this section is confusing).

[jorge3] if duplicate, as per 4g:
       5.  In case a PE receives more than one D-PATH attribute with a
           route, the PE SHALL process the first one in the list and not
           store and propagate the others.

[Sue] this is reasonable.

6) What syntactical checking per field (meaning of each field) is done
     to help you create the routing infrastructure using this attribute?
[jorge3] there are no specific checks for domain_segment_length, domain-id or isf_safi_type.
          Any value within the octet limits is accepted.
[Sue3] Are you accepting values of zero for domain-id? Just checking.
[jorge4] yup, no restriction

7) What happens if you find the attribute's fields are syntactically incorrect?
    (logging, dropping attribute, etc.)
[jorge3] see above -
[Sue3] What happens if domain-ID is zero? IS this an error.
[jorge4] no

8) What checking is done to make sure the combination of fields
     is correct?
[jorge3] no checks, other than the lengths as per the malformed attribute checks.
[Sue3]  Are you stating that the ISF SAFI type can be anything?  Why then define values?
[jorge4] it provides great information for traceability and troubleshooting, but it is not checked for error handling

9) What happens when you find there is a problem with the combination
     of the fields is correct?  (logging, toss out attribute, etc.)
[jorge3] see above
[Sue3]  see above.

10) How easy is it to maintain over time for interoperable implementations?

      For example, would you like to add an IANA Registry for well-known
      Domain-IDs 6-octet field as an option (4 Global Admin/2 local) or
      values for the 4-octet global administrator.
[jorge3] the domain-id is a 6-byte identifier that has to be configured on the gateways, there is no need for IANA registry.
[Sue3] Would it be useful to have an Well-known value registry?
[jorge4] I can't think of a use-case where it can be useful.. but maybe others can.

11) How does BGP signal this capability?
[jorge3] there is no specific capability signaling in open messages.
This is an optional transitive attribute, similar to other attributes used with IPVPN/EVPN routes.
[Sue3]: I'm concerned about this answer.  Let's chat in person.

12) What security implications does this attribute have?
[jorge3] the security considerations section contains a paragraph about the D-PATH.
Please let us know if you think there are other implications.
[Sue3] As stands, I do not see a definition that it is deployed in a
Limited secure environment (as BESS/IDR chairs have claimed with other drafts).
[jorge4] ok, I can add text clarifying that its use is limited to the use-cases in the draft (gateway PEs) and it is not expected to be used in public networks. Would something like that help?


Type-c) Confusing text (I think this is editorial)

5.  BGP Path Attribute Propagation across ISF SAFIs

   Based on its configuration, a gateway PE is required to propagate an
   ISF route between two domains that use the same or different ISF
   SAFI.

Note: you do not propagate across two ISF SAFIs, but you
Do propagate a route across domains with different ISF SAFIs.
The title and text do not match.
[jorge3] good point. We'll change the title to "5.  BGP Path Attribute Propagation across domains"

Cheers Sue
[jorge3] more comments along your [sue-v2] comments below.
[Sue3] I will send more comments to you privately.
           Do you want me to send these to BESS WG?
[jorge4] we'll socialize the outcome of the discussions with BESS WG for sure. It is up to you if you want to share all the comments with BESS. They will be reflected in the document anyway.
Thank you Sue!
Jorge

From: UTTARO, JAMES <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 6, 2022 11:07 AM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[e-mail]>>
Subject: RE: [bess] [Idr] FW: Review of draft-ietf-bess-evpn-ipvpn-interworking-05.txt


Comments In-Line..

Thanks,
          Jim Uttaro

From: BESS <[e-mail]<mailto:[e-mail]>> On Behalf Of Rabadan, Jorge (Nokia - US/Sunnyvale)
Sent: Wednesday, July 6, 2022 10:56 AM
To: [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] [Idr] FW: Review of draft-ietf-bess-evpn-ipvpn-interworking-05.txt

Hi Sue,

Sorry, it took us longer than we wanted.

We appreciate your comments. We put some work onto the draft with some back and forth discussions among the authors and other WG members. Based on that, we published version 7.
With version 7 in mind, please see my responses in-line with [jorge2].

If this new version and my responses below do not clear your concerns, it is probably better to schedule a meeting among authors, BESS chairs and yourself. We can do it face to face in Philadelphia.

Thank you,
Jorge


From: BESS <[e-mail]<mailto:[e-mail]>> on behalf of Susan Hares <[e-mail]<mailto:[e-mail]>>
Date: Monday, March 21, 2022 at 1:28 PM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] [Idr] FW: Review of draft-ietf-bess-evpn-ipvpn-interworking-05.txt

Jorge:



Thank you for your patience in my response.  I am sorry I missed this email on [e-mail]<mailto:[e-mail]>.



[individual contributor hat on]



My inline responses are marked [sue].



High-level:



1) Draft content:

1-a) This draft modifies RFC4271 - this should be in the header.

I believe without this in the header,

Not enough people paid attention in IDR.

[jorge2] ok, added in the abstract and introduction.

[Sue-v2]:  Thanks for changing the text, but you need to change the header on

             The draft.

[jorge3] ah, got it. Will change in the next version.



1-b) Why did you not break out just the DPATH attribute description

into a separate document?



A draft which modifies RFC4271 and DPATH could be broken

out and separately reviewed in IDR.   I think this would help clarify your

mechanisms versus the VPN procedures.

[jorge2] D-PATH was needed in the context of the use cases defined in this document. Without explaining the use cases and procedures, D-PATH did not make sense. Or in other words, D-PATH cannot be specified without the procedures explained in the rest of the document. Also, after a few years since its inception, multiple vendors have implemented it and follow the procedures in this draft, which is the reference for implementors. I don't think we should put it in a different document for those two reasons.

[Jim U>] +1.. D-PATH is required to facilitate the interworking between 2547 and EVPN and ensure that routing loops are prevented at the service level. I am unsure if D-PATH is being used for other FOUs.

[Sue-2] If you think the specification is clearer by combining it, I am fine as long as we do a WG LC call on

this feature in IDR and BESS.   This WG LC would not open your whole draft, but ask IDR Regarding the D-path attribute.





2) this proposal lacks a clear section on error handling.



The error handling exist on malformed D-PATH attribute, but does not deal with

Syntax error (e.g. if ISF_SAF_TYPE = 2), or interworking

(What happens if RFC9012 attribute is in a route.   Does it just get tossed?)



[jorge2] we added a new (hopefully clear) section about error handling. It should cover all cases. The two examples you give are covered, i.e., unknown ISF_SAFI_TYPE or reception of RFC9012 attribute (addressed by the normative references to the other RFCs). This document does not impose new rules except for the ones related to D-PATH. Any gaps in the other specs should be covered in updates for those specifications. By the way, I'm personally happy to participate in those updates if the BESS/IDR think it is needed.

[sue-v2]: I see now that we are not communicating.  See my list of things I expect to find in your attribute description in my introduction.

Let's see how we can both be happy with the text.   I gave examples to help you see the problem, but that did not work.

[jorge3] agree that we need to find a way.



3) The changes to RFC4271 do not give ample proof for "no loops case"
or scale.

[jorge2] the section about d-path and the security considerations sections describe how D-PATH can be used to prevent control plane loops in the described use-cases. Only the described use-cases are exposed to this new type of "loops". As mentioned, the solution is implemented and working in real live networks. Please check out the new version, and if you want us to provide more information or text, please be more specific on what else is needed to address your concern.

More comments below with [jorge2].

[Sue-v2] What I am looking for here is for you to provide to the WG theoretical and practical proof on the lack of loops.

If you have done this in a BESS presentation, just send me the list.

If you have not done this, I remained concerned.  Loop prevention is difficult, and unless you constrain the topology or the technology,

It is an n**2 problem.

(this is a discussion point and not a "no").

[jorge3] we need to discuss this on our meeting, please.



For these reasons, as an individual contributor I believe this

Draft needs work before publishing.



Sue



[From here down, I have still to respond to your email.  I will do this by 8am PDT).



============

My apologies for the delay.



Thank you very much for your review!

We've just published rev 06 which addresses some of your comments.



Please see below in-line with [jorge].



Thanks.

Jorge





From: BESS [mailto:[e-mail]] On Behalf Of Susan Hares

Sent: Tuesday, July 27, 2021 12:19 PM

To: [e-mail]<mailto:[e-mail]>

Cc: 'idr-chairs'; [e-mail]<mailto:[e-mail]>

Subject: [bess] Review of draft-ietf-bess-evpn-ipvpn-interworking-05.txt



Bess chairs reminded me that IDR WG was requested at IETF 110 to review draft-ietf-bess-evpn-ipvpn-interworking-05.txt. Since we did not receive reviews from the IDR WG, the IDR chairs have taken on the task of reviewing this document.



Full review is at:

https://trac.ietf.org/trac/idr/wiki/Hares-review-draft-ietf-bess-evpn-ipvpn-internetworking-05<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJw9j19PwjAUxb8KLD66tdtoN_AFJwmCiuGPgfCyrOsdq8MO28pE43d3XYwvNzn33PzOPd_Ohzo6o55TGnPSI4RayaEAqcHL6zd0DlGa_nlGZbknwBRerQ6dQoIr1IhKoPtMgXYVnAU0LldZYVx76TLQ2oXzSbri1E1pQEkwTa0qIQ8uJml60-8nJd_0ZV3sAqo_V2GwASHiplmtU0YXj5WZYqKfZ_uj2iUz8r6NTLGUt9sEzzVZh-JSsDtK8sXDfDIxyfRlDpennUz3yyvnuudUtl4b2T7tYxLToR8gXdp_x5J_lV1NQmKMIw6hD_kgZ4xRwAUJ4zge-jkdEuRTElE_CP2BF8WWCpb62jLBUxnLeCbHsq5EZnHW513q_-bnF0kjdWE.MEQCIEVaSbpYyZw35heaZzkI_nZEcHgb6-VWr-2rLUG0cfNrAiADPernQuFT0cf85xHCxpfE5piEWuQ8uc29_akpgdptkw>

High level points at:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-bess-evpn-ipvpn-interworking<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJw9j9FOwjAUhl8FFi_dum60K3iDk4SABiNgWLxZ1vWU1WGHbWWi8d1li_HmJP_5ku-c_9v7MAdvMvAq5452gtAlCpCgLQRl84ZOMcrzP-ZMUQYKnAwas-8TUsKgVtUKCVNI53fQ52CtD6ej9tWxn9qBaRtTK73P85vhMK3EdqgbmUXUfq7jaAtKsbZdb3JOVw-1m4fEPi5eDiZLF-R9lzj5pG93abi0ZBOrs-R3lJSr--Vs5tL581KufDzPzvsr73rg1V0XDe7yIQ4Jo2McIVsVBuxUi6-q70QIC8NEQIyhHJWccwqhJDFjbIxLOiYIU5JQHMV4FCSss0Jnfb04ITAFL0Shp7qpVdHpOi76q_-bn1-0FW4_.MEUCIQCst6WUtwIp9YvP92lKb-GVe6pTEuy8NuFgWNhJwFpSfQIgC_aYXgVM5-QN7KOK4P7DdrGa5Fi9TwfcsGFJTQA3tzo>



Summary Review:

========

The desire of users to have gateways between EVPNs and IPVPNs is evident due to the deployment of these technologies in the market place.  The BESS chairs request is due to the changes made to BGP in addition of a BGP Attribute and changes to RFC4271's route selection.  In addition, the IDR and BESS chairs have begun to discuss additional BGP error handling for embedded NRLIs beyond RFC7606.



This email is about 6 high-level issues in this draft and major editing issues.  It does not consider editorial issues in the text.



Deployment information on this draft draft-ietf-bess-evpn-ipvpn-interworking would help in the consideration of solutions to these high-level issues.  If this specification has 2 implementations, then these implementation teams may be able to quickly fill in the missing pieces of the document.

<<<<<<<<<<<<<<

[jorge] The document has several implementations. In particular, Nokia has a full implementation of this draft. Also interoperability across implementations has been recently demonstrated.

<<<<<<<<<<<<<<



=======

High level technical issues:



1) Lack of error handling for NLRIs which carry semantics beyond prefixes.



RFC7606 focused on the error handling for prefixes accompanied by attributes and

Communities (basic and extended) specified by RFCs 4271, 4360, 4456, 4760,

5543, 5701, 6368.



The embedded prefixes which combine prefixes with external information

(RD, EVI, ET, MPLS label, Domain, SID, and other tags) create a new  class of errors where the packet can be well-formed and invalid.   The handling of this information requires

careful consideration of the error handling.  The technology specified in this draft does

not consider the error cases of well-formed and invalid.



The IDR chairs suggest that this type of error handling should be defined as a general BGP functionality to expand RFC7606 to the embedded prefixes by the IDR WG.  This general functionality will then need to be applied to the handling of embedded prefixes.



This draft and existing RFCs (e.g. RFC7432) would be updated with the new error handling.



<<<<<<<<<<<<<<

[jorge] I fail to see if any action specific to this document is required from the above point. Seems a generic statement that applies to existing standards track documents that define NLRIs in EVPN, but not to this document specifically. This document does not define any new NLRI, and therefore no action related to (1) is needed. Can you please confirm?



[Sue] Incorrect.



The only error handling mentioned is on page 13, item g covering only the malformed of the D-PATH attribute.

I find no other consideration or error handling in the draft.  There are a lot of proposed methods.

Where is your error handling section for these methods?



For example, what happens the wrong types of communities are kept?   What happens if conflict occurs with RFC9012?

As an individual contributor, I want to know.

[jorge2] Please check out the new error handling section.



<<<<<<<<<<<<<<







2) Domain BGP Path Attribute (section 4) debugging and scaling



Domain Path IDs provide parallel numbering scheme that does not have a universal definition.  Debugging these Domain IDs in the Internet wild without this definition seems difficult at best.  It is unclear why the Domain IDs did settle on ASN (4 byte) plus some identifier.  There are numerous private AS numbers that can be used for DC tenants.



The automatic generation of AS numbers based on the starting point of private as numbers should take care of most Data Center automation tools.  Why does this specification stick with AS numbers?



<<<<<<<<<<<<<<<<<<<<<<

[jorge] the domain-id is really a 6-byte arbitrary number, it does not need to contain an ASN, but the authors thought it could be convenient for the operator give it a structure with a global and a local identifiers, where the global id may or may not match the ASN. Again, only on those cases that it makes sense for the operator, and if it helps the troubleshooting and debugging. If it helps, we can clarify that? For instance, we could make the following change:



OLD:



   o  DOMAIN-ID is a 6-octet field that represents a domain.  It is



      composed of a 4-octet Global Administrator sub-field and a 2-octet



      Local Administrator sub-field.  The Global Administrator sub-field



      MAY be filled with an Autonomous System Number (ASN), an IPv4



      address, or any value that guarantees the uniqueness of the



      DOMAIN-ID when the tenant network is connected to multiple



      Operators.



NEW:







   o  DOMAIN-ID is an arbitrary 6-octet field that represents a domain.  It is



      composed of a 4-octet Global Administrator sub-field and a 2-octet



      Local Administrator sub-field.  The Global Administrator sub-field



      MAY be filled with an Autonomous System Number (ASN), an IPv4



      address, or any value that guarantees the uniqueness of the



      DOMAIN-ID (when the tenant network is connected to multiple



      Operators) and simplifies troubleshooting and debugging.

<<<<<<<<<<<<<<<<<<<<<<

[Sue]: This does not address the original question regarding private ASN

in the 4 byte range.   You gave me a placebo answer which does not

address the question regarding the private AS number and DC.

Since this is an "explanatory" draft, it would be nice to point people

to that freely available space.



[jorge2] I didn't make myself clear, sorry about that. What I meant is that the authors agreed that the domain-id had to be 6-bytes long. The spec uses those 6-byte values as unique identifiers that are allocated by the operator of the network, and are not globally assigned nor have other semantics than the unique identification of a domain in a multi-domain network. It is entirely up to the operator if they encode IP address values or ASN (public or private) values or any other value that the operator deems useful/easy to trace/troubleshoot. The use of private ASNs is of course an option, but not the only one.

[Sue-v2] I'm asking if would be useful to have an IANA well-known Domain ID registry.

If not, why not?

[jorge3] I don't think so. The domain-id is processed in the context of a virtual private network (in a VRF), not in the Internet. If two operators need to coordinate to connect two VPNs, they will agree on a value anyway. Similar to the way they will agree on picking a set of route-target values.



============================



Error handling: (section 4 - pages 11-14)

The error handling of the DPATH seeks to define:

(4.a) add/delete/change conditions for transit routes and locally generated routes

(4.b) malformed DPATH attributes.



It does not define error conditions if the syntax conditions

cause (4.a) to fail.

<<<<<<<<<<<<<<<<<<<<<<

[jorge] not sure if I understand your 4.a. The document specifies under what conditions D-PATH is added, and modified (new domain-id prepended). It also specifies the propagation between ISF SAFIs on Gateways in section 5. Can you please be more specific on what things you are missing so that we can clarify better? Maybe an example would help. Sorry if I'm missing something.

[Sue]:

4a) What happens if your implementation goes parsing through attribute list,

And it fails to find a correct type in the tuple:  <doman-id:ISF-SAFI-type>

What happens if the segment has an illegal ISF-SAFI_type?  Say the value 2.

[jorge2] As per the text, value 2 is not invalid. Any value is accepted since the type is really an informational field not processed on reception:
       4.  Domains in the D-PATH attribute with unknown ISF_SAFI_TYPE
           values are accepted and not considered an error.





Section 4.g. gives malformed at the byte count level.

Am I missing your error section?

[jorge2] please check out the new section and let us know.



<<<<<<<<<<<<<<<<<<<<<<





3) Route selection process modifies the RFC4271 and may not scale



This draft modifies the RFC4271 to include D-PATH (page 17) without providing a solid

reasoning why it is necessary and why it scales.  Proof of the scalability may be included in another document or by public reports. As the topics of the ANRW indicates, BGP research for scalability of an application is always a "hot" research topic.



The definition of the BGP route selection changes (page 17)  #3 and 4 is not tightly defined using an example rather that specification. Any proposed changes to the BGP route selection should be done in formal language for changes to the text.



Language such as "could possible leave" or "by default" is not specific (page 17) is not specific enough.



<<<<<<<<<<<<<<<<<<<<<<

[jorge] About scale:

D-PATH was added to provide visibility and avoid loops in Service Provider networks, where multiple Gateways are deployed, for ISF SAFIs 128 and 70. So VPNs really. We later added SAFI 1, mostly due to PE-CE routes, but this is not envisioned to be used in the wide Internet, so I don't think scale would be an issue. For SAFI 1 among Providers, the AS-PATH already provides the visibility and loop protection needed. Note that D-PATH is only added or modified in the context of an IP-VRF, and it is NOT modified by a router if no IP-VRF is present. We can add some text about this, if it helps?



About the BGP route selection changes, let me know if the following changes we made in rev 06 remove your concerns:



OLD:



<snip>

   4.  Steps 1-3 could possibly leave Equal Cost Multi-Path (ECMP)

       between non-EVPN and EVPN paths.  By default, the EVPN path is

       considered (and the non-EVPN path removed from consideration).

       However, if ECMP across ISF SAFIs is enabled by policy, and one

       EVPN path and one non-EVPN path remain at the end of step 3, both

       path types will be used.

<snip>



NEW:



<snip>



   4.  If Steps 1-3 leave Equal Cost Multi-Paths (ECMP)

       between non-EVPN and EVPN paths, the EVPN path MUST

       be considered (and the non-EVPN path removed from consideration).

       However, if ECMP across ISF SAFIs is enabled by policy, and one

       EVPN path and one non-EVPN path remain at the end of step 3, both

       path types MUST be used.



The above process modifies the [RFC4271] selection criteria to include

the shortest D-PATH so that operators minimize the number of Gateways

and domains through which packets need to be routed.

<snip>



[Sue]: We have operators in IDR claiming issues with scaling SR + EVPN (some now, some in the future).

Therefore, scale is a question you should have an answer other than "so I don't think scale would be an issue".



Adding something to RFC4271 to fix your scaling issues must have proof of:

[jorge2] I think I didn't make myself clear, sorry about that. This spec is NOT "adding something to RFC4271 to fix your scaling issues". It is adding an attribute that modifies the RFC4721 best path selection only for multi-protocol BGP routes of SAFIs 1, 128 and EVPN. Because the interworking PEs may receive the same prefix from those three SAFIs at the same time, the best path selection affects routes across those three SAFIs. But the spec is not making scale worse or better in the use-cases that describes, it is solving those use-cases.





1) no loops created due to step 1.

2) scaling issues by adding step 4.



You are asking IDR to change RFC4721.  Without experimental results or proof that it does not loops.

This is a "big" ask.  Your word tweaks do not change the facts on scaling on step 4.

[jorge2] As discussed above, there is no attempt or goal to fix any scale issue, and there is no description of any scale issue either. It describes a loop situation for MP-BGP routes SAFI 1, 128 and EVPN IP Prefix routes in the context of IP-VRF instances. Since the spec does not attempt to fix any scale issue, we can't show any report showing scale tests. But we can show a public report that proves D-PATH solves loops in a multi-vendor environment:
EANTC-InteropTest2022-TestReport.pdf<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJw9j11PwjAUhv8KLF7KunW0G3oDA0OGBCLMQLxZuvXUTUY728r8iP9dhsa78z5v8py8X86brp2bnlNa25gbhM6RgwBpwC3UEZ0ClGV_HTBpC5cDElUNjB8r-YsQV62sFeMGwQmkNQh7GKO7ySqdDhJpQasmBWM7OuiODTRKW7fhIstu-_245GlfKrHH1LxvApxCVUVtu9lmOV0tD3buEbNOnmq9jxPyuguteJCTXewtDNkG1YfIp5QUq_vFbGbj-eMCdskyXAftlXPdcw7dNglW6WffIxEd-RiZkmkwY8k_y8tGQiLPCzkEPhTDIs9zCp4gQRRFI7-gI4J8SkLq48AfumHUWaGzvpyd4GqWM87kWKpDxTpd1_PL13_y_QO8H3IW.MEQCIHTX5O3tBBiKgi3rcWAkYcxFsVdflG2LbsK_YPWDwnRAAiBynS2WZ2-PeUKSinbQPMMpZRCUjs-Yo-P2Vk1qS0UlgA>

Please check out sections: "EVPN and IP-VPN Interworking" or "IPVPN over SRv6/EVPN RT5 over SR-MPLS Interworking"

Let us know if it helps please.



<<<<<<<<<<<<<<<<<<<<<<



4) Error handling in Gateway PE (section 8)  between different AFI/SAFI prefixes is unclear



This draft defines translation between certain embedded prefixes see table below.  The interworking of the embedded prefix depends the basic error handling working correctly for embedded prefixes (#1) and the Domain Path (#2). Since these two items are unclear AND

I do not see definitions "well-formed but invalid" case is not covered for this draft.



AFI with SAFIs

1 - 1, 128

2 -  1, 128

25 - 70



Section 8 attempts to provide this rules as an example.  However section 8 requires the following syntax validity checks beyond well-formed:

1) It must be a ISF route from AFI/SAFI pairs + allowed by policy (?)

2) for gateway PE advertising ISF routes, must

    a) include a D-PATH attribute

    b) EVPN to other VPNS must append Domain with

2) The domain inside D-PATH must have a specific Domain-ID

3) determination on what Route Distinguisher or Route Targets are valid,

4) determination on what support for import/export of routes with different RD and RTs.



<<<<<<<<<<<<<<<<<<<<<<

[jorge] section 8 has been re-written in rev 06 clarifying the rules based on your feedback. Please let us know if this helps.



[Sue] Some improvement, but substantial things are l eft ou.



1. ISF Route text - improved

2. Gateway - point A.

     Statement " Rules to

    determine if a route is well-formed or valid for a given ISF

     SAFI are out of scope of this document, and are defined

      By the specification of each ISF SAFI."



You at least need 1 ISF SAFI pointed to with an error case to see if your logic works.

This section does not work for me.

[jorge2] see the modified text please.



2. Gateway - Point B

     Here you pointed to the fact you can have a looped ISF route

     Due to one or more of the gateway's PE's locally

     Associated domains for the IP-VRF.



   I repeated my questions on where have you proved that this

   Addition to RFC4271 will not cause loops.

[jorge2] because of this (2b) we avoid a loop since we do not export the route that we previously received with a domain-id that matches a local one. Check out the figure in that section:

-    Without (2b) we have a loop: IP1/24 is received and imported on PE1's VRF. PE1 re-exports the route into the IPVPN domain, hence it gets to PE2. Without (2b) PE2 may export the route back to the EVPN domain.

-    With (2b) PE2 will never re-export the route back into the EVPN domain, hence avoiding the loop.

So (2b) is preventing loops, not creating loops. Not sure if this helps?



Going on from point 2, your text states:



"The D-PATH attribute MUST be included so that loops can

be detected in remote gateway PEs. ...

(text)



The rest of my text still applies your revised text:

3) determination on what RD or RT are valid

    Points b (May) and d. (MUST) in your new text - give more details, but

    not firm details or error handling .

4) determination on what support for import/export of routes

   Improved some, but can policy override this case. Item d, leaves me wondering.

[jorge2] those are rules when advertising into the ISF SAFI-y once the route passes the checks to be exported. Policy can modify any attributes on export, as for any IP-VRF case in any PE.

<<<<<<<<<<<<<<<<<<<<<<





5) Section 7 - normative or informative



It is unclear if section 7 provides normative details on the Route Reflector or informative.  It is also unclear if the EVPN forwarding constraints are normative or informative.

<<<<<<<<<<<<<<<<<<<<<<

[jorge] section 7 has been re-written in rev 06 to clarify this. Please let us know if this helps.

[Sue]

item 1 is normative,

item 2 is not normative,

Item 3 is unclear,

Item 4 is unclear.

Item 5 is unclear,

Item 6 is non-normative.



You need to clearly state 3-5 if you are going to mix normative and non-normative in a list.

Why didn't you break this list a part?

Is there some benefit I am missing?

[jorge2] please check out the new text, let us know if it clears your concern.



<<<<<<<<<<<<<<<<<<<<<<



Phrases like "as a consequence of this, the indirection provided by RT's recursive resolution and its benefits in a scaled network, will not be available in all PEs in the network" (page 20) is worrisome.  If it is normative, then is this solution only partial?

<<<<<<<<<<<<<<<<<<<<<<

[jorge] We modified the text in rev 06. This is informative, and it simply says that if the gateway PE selects an IPVPN route for prefix P instead of an EVPN route, the EVPN specific attributes or NLRI fields are not available. Simply because IPVPN and EVPN routes are different.



[Sue]: yes - I understood that IPVPN and EVPN routes are different.

The question is how does this interworking deal with the gaps.

Does the solution

a) translate IPVPN to/from EVPN, or

b) does the interworking simply facilitate pass routes across the gaps (EVPN or IVPN in coverage).



[jorge2] It should be (b), if I understood your question. The spec does not attempt to improve IPVPN to match EVPN capabilities, but provide a way for EVPN and IPVPN to interwork for the basic inter-subnet forwarding.

<<<<<<<<<<<<<<<<<<<<<<



6) Section 11 security considerations needs to align with document



The proof of phrase "a correct use of the D-PATH will prevent control plane and data plane loops in the network"  exhibits facts not in evidence in the document.



The proof of the phrase "incorrect configuration of the DOMAIN-IDs on the gateway PEs may lead to the detection of false route loops and the blackholing of the traffic"  also exhibits facts not in evidence in the document.



The security considerations need to be based on a revised error handling.



It is appropriate to mention that stripping path attributes at a gateway will cause problems.

<<<<<<<<<<<<<<<<<<<<<<

[jorge] we modified the text to mention that last part in rev 06. I hope the rest is clarified with the modified sections 7 and 8. Let us know otherwise please.

[Sue]: you are asking to modify RFC4271 with text that gives me great concern (as an RFC4271) regarding

the loop-free qualities and scale.



We have reports of the implementations (from operators) having trouble scaling EVPN.

[jorge2] please see my comments about scale and loops. The document is oblivious to scale and only adds a new optional attribute in the limited cases described in the document:

-    Only if the gateway PE function is enabled in the VRF

-    Only for MP-BGP routes of SAFI 1, 128 and 70 (only type EVPN IP Prefix routes in SAFI 70)

The new attribute (D-PATH) solves the loop situations only in the above two cases, and due to the use of redundant gateway PEs. There is no need for D-PATH if no redundant gateway PEs exist.

With that in mind, if we didn't manage to clear your concerns I think it would be better to have a meeting so that we understand how to clear them.

Thanks again for your help improving the document.





I do not feel the security concerns have been resolved with changes.



<<<<<<<<<<<<<<<<<<<<<<