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

[Robert Raszuk <[e-mail]>]

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