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

On 9/1/2015 2:48 PM, Rabadan, Jorge (Jorge) wrote:
> I agree with Robert.
>
> Also, even though I am not aware of any implementation of the
> encapsulation SAFI, 
We have one on top of quagga and expect to post it on gitub sometime soon.
> I know a few implementations of the RFC5512
> encapsulation extended community, hence I don’t think the RFC5512 should
> be obsoleted.

I guess I wasn't clear.  I'm only proposing deprecating encap safi
(which requires 5512 to be obsoleted/replaced).  All other 5512
mechanisms will need to be documented somewhere and rather than a
5512bis, I'm proposing using draft-ietf-idr-tunnel-encaps.

Lou

>
> 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