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

["Keyur Patel (keyupate)" <[e-mail]>]

+1. I have not seen a major implementation as well as any deployment of
encap safi.

The extended community defined in RFC5512 has been used in certain
scenarios.

I would be in favor of:

1) Deprecating the SAFI. Deprecating the RFC5512.

2) Rollover meaningful contents of RFC5512 into current draft.

A single documents helps! ;)

Regards,
Keyur

On 9/1/15, 12:14 PM, "Lou Berger" <[e-mail]> wrote:

>Robert,
>    Great explanation of why the Encap safi *should* be very useful.
>Yes, there should be really nice advertisement scaling properties when
>an encap next hop changes (e.g., 1M routes over a tunnel and the tunnel
>endpoint changes, 1vs 1M prefixes updated).
>
>What motivated my proposal is reality, more specifically (a) the extra
>route lookup resolution causes all sorts of complexity in code that
>needs fully resolved forwarding information and has multiple tunnels to
>the same next hop, (b) I know of only one implementation, and (c) we
>aren't seeing the value of the encap safi outweighing the complexity in
>implementation. 
>
>That said, if there's a real desire to keep 5512 as is, I can live with
>it and we can still remove the encap SAFI from our code whenever we
>want;-)
>
>Lou
>
>On 9/1/2015 2:40 PM, Robert Raszuk wrote:
>> 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
>
>