Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

[Robert Raszuk <[e-mail]>]

> *[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.

>