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

[Lou Berger <[e-mail]>]

- Assuming we keep 5512 and draft-ietf-idr-tunnel-encaps,
draft-ietf-idr-tunnel-encaps should be extended to cover 5566 operation
without encap SAFI. 

Hereto, I can provide text as/if needed.

Lou
On 9/1/2015 3:24 PM, Robert Raszuk wrote:
> Hi Lou,
>
> I think Encap SAFI has number of useful use cases regardless if and
> how it was implemented by vendor XYZ.
>
> I think it does not require extra route lookup for each of the overlay
> prefix at all. So the cost of next hop resolution when next hop
> parameters change I would rather consider a noise when compared to per
> prefix change.
>
> As to multiple "tunnels" to a next hop that is always the case
> (example: native forwarding + 1 encap) and needs to be properly
> handled. Encap SAFI is just a signalling tool. The use it depends on
> the operator's choice and local/global policy.
>
> Sure you can remove Encap SAFI from your code, but likely you will
> need to replace it with some other new SAFI with exact same set of
> problems and pretty much similar use cases :)
>
> Besides last time I checked IDR requires two implementations to
> proceed with a WG last call and move draft to RFC precisely to avoid
> the thread like this later on ....
>
> Best,
> r.
>
>
>
>
>
> On Tue, Sep 1, 2015 at 9: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
>>