Robert, John: First, I don’t see an issue with sending endpoint sub-TLV along with a route from underlay space. Second, [Tunnel-Encap] provides recursive resolution and coloring so that we don’t need to send the Tunnel Attribute with every VPN routes. Third, secure-evpn talks about route hierarchy for finer level of granularity of tunnel setup.
Robert, wrt section 3.1, I think this special case is in context of section 4.1. Cheers, Ali From: Idr <[email protected]> on behalf of Robert Raszuk <[email protected]> Date: Wednesday, June 26, 2019 at 2:30 PM To: John E Drake <[email protected]> Cc: "[email protected]" <[email protected]>, Linda Dunbar <[email protected]>, John E Drake <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt [JD] You could issue an UPDATE for the tunnel endpoint itself which contained the tunnel encapsulation attribute sans an endpoint sub-TLV. What next would this UPDATE contain ? See there seems to be already a provision for what I think you are trying to do by this special case from section 3.1: There is one special case: the Remote Endpoint sub-TLV MAY have a value field whose Address Family subfield contains 0. This means that the tunnel's remote endpoint is the UPDATE's BGP next hop. If the Address Family subfield contains 0, the Address subfield is omitted, and the Autonomous System number field is set to 0. Any routes that use that tunnel endpoint would also include the tunnel encapsulation attribute that contains only the endpoint sub-TLV. Well one could argue that if you properly mark next hop with proper tunnel encapsulation selection and tunnel endpoint address you would not need to attach any tunnel attribute at all as simple BGP recursion will inherit the properties of next hop carried prefixes are pointing to. Thx. R.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
