Re: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-00.txt

[Robert Raszuk <[e-mail]>]

Hi Keyur, Lou

> That¹s a good idea.

Well let's think about it a bit more ...

BGP power is in its indirection and recursion. The native BGP
hierarchy is a very powerful tool. Decoupling transport from
forwarding has proven in many cases useful.

Now imagine the underlay vs overlay split .. moreover imagine that my
underlay is controlled centrally in some sort of software defined way.

If we obsolete Encap SAFI in order to modify encapsulation parameters
used by transport layer to send traffic from ingress to bgp next hop
of the underlay I would need to readvertise all overlay routes
(perhaps millions) with new encap attribute. /* I could perhaps try to
readvertise the next hops but with much higher AD of IBGP those are
not used normally for route resolution as IGP wins race to RIB. */

However with Encap SAFI I need to advertise only new parameters with
few next hops.

IMO it is not that Encap SAFI idea which is bad here. It is us -
humans - those who did not catch up to it yet :).  Note that recently
in number of EPE discussions this in fact may be a very useful SAFI.

If we depreciate it we will likely create new SAFI with new names,
patents and new authors for doing essentially the same.

So for set of applications which is not that had to imagine I would
rather keep the encap SAFI, allow those who understand its power to
implement it and use it while in the same time have standalone
attribute which could be attached to any SAFI.

Best,
Robert.

PS. Just to make it clear I am in no major way associated with Encap
SAFI (except being listed in the ack section of 5512 :)


On Tue, Sep 1, 2015 at 7:31 PM, Keyur Patel (keyupate)
<[e-mail]> wrote:
> Lou,
>
> That¹s a good idea. We authors did discuss it amongst ourselves and do
> plan to cover it in next revision.
>
> Regards,
> Keyur
>
> On 9/1/15, 8:55 AM, "Lou Berger" <[e-mail]> wrote:
>
>>
>>Authors/WG,
>>    Now that we have a WG draft on this topic, I'd like to propose that
>>this draft deprecate the Encap SAFI and obsolete/replace RFC5512.
>>
>>I'm not sure if anyone else has implemented Encap SAFI, but we have and
>>found it to be much more complex and limiting than just using the Encap
>>Attribute ala the new draft.
>>
>>Also, I can propose specific text changes needed if the Authors wish,
>>but I suspect they can handle this themselves!
>>
>>Thanks,
>>Lou
>>
>>On 8/19/2015 2:59 PM, [e-mail] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>directories.
>>>  This draft is a work item of the Inter-Domain Routing Working Group of
>>>the IETF.
>>>
>>>         Title           : Using the BGP Tunnel Encapsulation Attribute
>>>without the BGP Encapsulation SAFI
>>>         Authors         : Eric C. Rosen
>>>                           Keyur Patel
>>>                           Gunter Van de Velde
>>>      Filename        : draft-ietf-idr-tunnel-encaps-00.txt
>>>      Pages           : 29
>>>      Date            : 2015-08-19
>>>
>>> Abstract:
>>>    RFC 5512 defines a BGP Path Attribute known as the "Tunnel
>>>    Encapsulation Attribute".  This attribute allows one to specify a set
>>>    of tunnels.  For each such tunnel, the attribute can provide
>>>    additional information used to create a tunnel and the corresponding
>>>    encapsulation header, and can also provide information that aids in
>>>    choosing whether a particular packet is to be sent through a
>>>    particular tunnel.  RFC 5512 states that the attribute is only
>>>    carried in BGP UPDATEs that have the "Encapsulation Subsequent
>>>    Address Family (Encapsulation SAFI)".  This document updates RFC 5512
>>>    by deprecating the Encapsulation SAFI (which has never been used),and
>>>    by specifying semantics for the attribute when it is carried in
>>>    UPDATEs of certain other SAFIs.  This document also extends the
>>>    attribute by enabling it to carry additional information needed to
>>>    create the encapsulation headers additional tunnel types not
>>>    mentioned in RFC 5512.  Finally, this document also extends the
>>>    attribute by allowing it to specify a remote tunnel endpoint address
>>>    for each tunnel.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-00
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>>submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>
>>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr