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

I agree with Robert.

Also, even though I am not aware of any implementation of the
encapsulation SAFI, I know a few implementations of the RFC5512
encapsulation extended community, hence I don’t think the RFC5512 should
be obsoleted.

Thanks.
Jorge

-----Original Message-----
From: Idr <idr-bounces@ietf.org> on behalf of Robert Raszuk
<robert@raszuk.net>
Date: Tuesday, September 1, 2015 at 11:40 AM
To: "Keyur Patel (keyupate)" <keyupate@cisco.com>
Cc: "idr@ietf.org" <idr@ietf.org>, Lou Berger <lberger@labn.net>,
"draft-ietf-idr-tunnel-encaps@ietf.org"
<draft-ietf-idr-tunnel-encaps@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-00.txt

>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)
><keyupate@cisco.com> 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" <lberger@labn.net> 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, internet-drafts@ietf.org 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
>>>> I-D-Announce@ietf.org
>>>> 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
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>
>_______________________________________________
>Idr mailing list
>Idr@ietf.org
>https://www.ietf.org/mailman/listinfo/idr