John, > Making the Remote Endpoint sub-TLV mandatory effectively associates the attribute with the remote endpoint.
I am not sure why you draw such conclusion. Including remote endpoint address does not bind this sub-TLV to be advertised with the remote end point NLRI. Quite contrary this information is needed on a per NLRI basis. How could you not send endpoint address if the entire purpose of this extension is to signal the address where the encapsulation should be terminated at - no ? Thx, R. On Wed, Jun 26, 2019 at 8:27 PM John E Drake <jdrake= [email protected]> wrote: > John, > > > > Oopsie, I missed that. Do we really want to have this behavior? Having > it optional would give us a lot more flexibility and I thought an attribute > was supposed to be associated with a route. Making the Remote Endpoint > sub-TLV mandatory effectively associates the attribute with the remote > endpoint. > > > > Yours Irrespectively, > > > > John > > > > > > Juniper Business Use Only > > *From:* John Scudder <[email protected]> > *Sent:* Wednesday, June 26, 2019 2:06 PM > *To:* Linda Dunbar <[email protected]>; John E Drake < > [email protected]> > *Cc:* [email protected]; [email protected] > *Subject:* Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in > draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt > > > > Linda, John, > > > > Your discussion is premised on the assumption that the remote endpoint > sub-TLV is optional. Consider this paragraph, from section 5: > > > > When the Tunnel Encapsulation attribute is carried in an UPDATE of > > one of the AFI/SAFIs specified in the previous paragraph, each TLV > > MUST have a Remote Endpoint sub-TLV. If a TLV that does not have a > > Remote Endpoint sub-TLV, that TLV should be treated as if it had a > > malformed Remote Endpoint sub-TLV (see Section 3..1 > <https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-12#section-3.1>). > > > > There’s both a MUST clause and directions to ignore the sub-TLV if the > remote endpoint is missing. To me this seems clear without any changes to > the draft. > > > > Regards, > > > > —John > > > > On Jun 21, 2019, at 8:25 AM, Linda Dunbar <[email protected]> > wrote: > > > > John, > > > > I am with you hoping that the Tunnel-encap authors can clarify more. > > Based on the description of how the receivers of the Tunnel UPDATE msg add > the Encapsulation Headers to client routes described in the Tunnel-Encap > draft, it should be: > > - If the “Remote endpoint” sub-TLV was present and containing the same > address as the route itself, then the receivers of the Tunnel UPDATE would > construct the encapsulation header with the Outer Destination Address equal > to the “route itself” (which is carried in the Remote Endpoint sub-TLV). > > I think this can be a serious problem. > > > > - if the “Remote Endpoint” sub-TLV was not present, the receivers of > the Tunnel UPDATE would assume the UPDATE originator’s address as the > Tunnel Remote end point. > > > > If the processing behavior described above is NOT what the Tunnel-Encap > draft intended, then the Tunnel-Encap draft needs to add text to clarify > the description. > > > > Nevertheless, do you have objections of those gaps that Tunnel-Encap and > Secure-EVPN: > > > > - Doesn’t have the functionality that would help the C-PE to register its > WAN Port properties. Some WAN ports are facing public internet with ISP > assigned addresses that are in different address space than the SD-WAN > address space, some WAN ports are assigned with private addresses which > need to propagate NAT information to the trusted peers via Controllers, > such as the virtual C-PEs instantiated in public Cloud DCs, and some WAN > ports are facing the trusted MPLS network. > > > > - For the same Client route, e.g. 10.1.x.x, attached to a C-PE, need to be > encrypted when forwarding to the WAN ports facing untrusted network, and > can be forwarded without any encryption towards WAN ports facing trusted > network. > > > > > > Thank you very much for the discussion. I have updated the Gap analysis to > reflect what has been discussed in this email thread... > > > > Linda > > > > *From:* John E Drake <[email protected]> > *Sent:* Friday, June 21, 2019 8:14 AM > *To:* Linda Dunbar <[email protected]>; [email protected]; > [email protected] > *Subject:* RE: Tunnel-Encap Gaps for SD-WAN described in > draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt > > > > Linda, > > > > It would be useful to get a clarification from the authors. I had always > thought that if the remote endpoint sub-TLV was either not present or > present and containing the same address as the route itself, then the > information in the tunnel encapsulation attribute pertains to the address > specified in the route. This is the assumption made in the Secure EVPN > draft that I mentioned earlier in this thread. > > > > Alternatively, the route could specify a loopback address of the C-PE and > the tunnel encapsulation attribute could contain the interface address and > characteristics of each of its WAN-facing ports; this is completely > compliant with your interpretation that the address specified in the route > is reachable through an address specified in the remote endpoint sub-TLV. > > > > [Linda] But there is no field to indicate the property of the WAN ports. > > > > Yours Irrespectively, > > > > John > > > > > > Juniper Internal > > *From:* Linda Dunbar <[email protected]> > *Sent:* Thursday, June 20, 2019 7:08 PM > *To:* John E Drake <[email protected]>; [email protected]; [email protected] > *Subject:* RE: Tunnel-Encap Gaps for SD-WAN described in > draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt > > > > John, > > > > Those addresses stated in the quoted paragraphs are for Clients Routes, > i.e. the routes attached to the PE, not the PE’s lookback address, correct? > > The Loopback Address is specified in the “Remote Endpoint” SubTLV, so that > receivers of the UPDATE can establish the Encapsulation with the outer > destination address equal to the one specified by the “Remote endpoint” > SubTLV. > > > > That was discussed in the long email discussion thread last week. > > > > We can ask the Tunnel-Encap authors to confirm. > > > > Linda > > > > *From:* John E Drake <[email protected]> > *Sent:* Thursday, June 20, 2019 5:50 PM > *To:* Linda Dunbar <[email protected]>; [email protected]; > [email protected] > *Subject:* RE: Tunnel-Encap Gaps for SD-WAN described in > draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt > > > > Linda, > > > > From section 5 on the Tunnel Encapsulation Attribute draft: > > > > “[RFC5512] specifies the use of the Tunnel Encapsulation attribute in > > BGP UPDATE messages of AFI/SAFI 1/7 and 2/7. That document restricts > > the use of this attribute to UPDATE messsages of those SAFIs. This > > document removes that restriction. > > > > The BGP Tunnel Encapsulation attribute MAY be carried in any BGP > > UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 > > Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), > > 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), > > or 25/70 (Ethernet VPN, usually known as EVPN)). Use of the Tunnel > > Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is > > outside the scope of this document.” > > > > What this means is that the tunnel encapsulation draft can be use exactly > > as I described in my previous email to describe the characteristics of > > of an SD-WAN port. > > > > Yours Irrespectively, > > > > John > > > > > > Juniper Internal > > *From:* Linda Dunbar <[email protected]> > *Sent:* Thursday, June 20, 2019 6:08 PM > *To:* John E Drake <[email protected]>; [email protected]; [email protected] > *Subject:* RE: Tunnel-Encap Gaps for SD-WAN described in > draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt > > > > John, > > > > Thank you very much for the feedback. > > Comments are inserted below: > > > > *From:* John E Drake <[email protected]> > *<Snip> * > > > > ------------------------------------------- > > > > - [Tunnel-Encap] doesn’t have the functionality that would help the > C-PE to register its WAN Port properties. > > > > - A SD-WAN tunnel, e.g. IPsec-based, requires a negotiation between > the tunnel’s end points for supported encryption algorithms and tunnel > types before it can be properly established, whereas [Tunnel-Encap] only > allow the announcement of one endpoint’s supported encapsulation > capabilities for specific attached routes and no negotiation between tunnel > end points is needed. > > > > *[JD] What you need to do is implement the model described in the Secure > EVPN draft (https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-01 > <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint...com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Ftools.ietf.org-252Fhtml-252Fdraft-2Dsajassi-2Dbess-2Dsecure-2Devpn-2D01-26data-3D02-257C01-257Clinda.dunbar-2540futurewei.com-257C28557a27c1c64de4997708d6f5b30f7f-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C1-257C636966546754208641-26sdata-3DqLd2LVx5Lng7QccAIB0weIfpXE3IBOQfq0kiLUJqFMs-253D-26reserved-3D0%26d%3DDwMFAg%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DCRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE%26m%3Dv-ZrS-NTEa3rPqhwNaoM5gNU8iL1zGd7DutDZaH0C4w%26s%3DnivOMac2lUDvbaJX-GTBeiLAWMqfyKOsTpqvG3AB27A%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei..com%7C84c6ed1f7cb342efda1208d6f64a6827%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636967196777678003&sdata=3wnRuxLXyDo9qPVXcIfbGNWZMNC37wef0hd4kBJlEWQ%3D&reserved=0>). > Viz, the SD-WAN C-PEs are attached to a route reflector and each uses the > route reflector to advertise its security-related information the other > C-PEs. As we discussed in Prague the tunnel encapsulation attribute is not > associated with client routes. Rather it is associated with the loopback > or interface addresses of the advertising SD-WAN C-PE. I.e., IPv4/IPv6 > addresses rather than VPN IPv4/IPv6 addresses* > > > > *[Linda]Yes, using Loopback address would be a good way for tunnel, but > that is not what Tunnel-Encap specified. The draft Tunnel-Encap is to > advertise supported Encap capabilities for specified routes.* > > *I have another section (4.3) on the gap analysis for SECURE-EVPN, > specifically, Secure-EVPN does not address the scenario of C-PE having some > ports facing trusted MPLS VPN and other ports facing the untrusted public > Internet. The document assumes that a client route is either forwarded all > encrypted through one tunnel, or not encrypted at all through a different > tunnel. In SD-WAN, one client route can be forwarded encrypted at one time > through the untrusted network and be forwarded unencrypted at different > time through MPLS VPN.* > > *If you think the secure-evpn has addressed those scenarios, can you > please indicate which section? Thank you.* > > > > > > The establishment of a SD-WAN tunnel can fail, e.g., in case the two > endpoints support different encryption algorithms. That is why a SD-WAN > tunnel needs to be established and maintained independently from > advertising client routes attached to the edge node. > > > > *[JD] See above * > > > > - [Tunnel-Encap] requires all tunnels updates are associated with > routes. There can be many client routes associated with the SD-WAN IPsec > tunnel between two C-PEs’ WAN ports; the corresponding destination prefixes > (as announced by the aforementioned routes) may also be reached through the > VPN underlay without any encryption.. A more realistic approach to separate > SD-WAN tunnel management from client routes association with the SD-WAN > tunnels. > > > > *[JD] See above * > > > > - When SD-WAN tunnel and clients routes are separate, the SD-WAN > Tunnel establishment may not have routes associated. > > There is a suggestion on using a “Fake Route” for a SD-WAN node to use > [Tunnel-Encap] to advertise its SD-WAN tunnel end-points properties. > However, using “Fake Route” can raise some design complexity for large > SD-WAN networks with many tunnels. For example, for a SD-WAN network with > hundreds of nodes, with each node having many ports & many endpoints to > establish SD-WAN tunnels with their corresponding peers, the node would > need as many “fake addresses”. For large SD-WAN networks (such as those > comprised of more than 10000 nodes), each node might need 10’s thousands of > “fake addresses”, which is very difficult to manage and requires lots of > configuration tasks to get the nodes properly set up. > > > > *[JD] There is no need for a ‘Fake Route’. We advertise a tunnel > encapsulation attribute with security-related information for a specific > SD-WAN port on the C-PE as identified by its IPv4/IPv6 interface address. > If a set of SD-WAN ports have common security-related information a tunnel > encapsulation attribute can be advertised with a C-PE’s loopback address.* > > > > *[Linda] this section is for Tunnel-Encap, which doesn’t allow Loopback > address to be associated with the tunnel. If you think it does, can you > please indicate which section? Thank you.* > > > > *Linda* > > > > _______________________________________________ > Idr mailing list > [email protected] > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=iOdQsUCt3t0401DmUlaGf2LNe6GNFoppcHL9UmnRFs0&s=oVYZHedRWOsvb3oxa8GsufcZaZuDs9SgOtCSaMCwEmM&e= > > > > _______________________________________________ > Idr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/idr >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
