Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04

[Lou Berger <[e-mail]>]

On May 26, 2017 12:32:05 PM Eric C Rosen <[e-mail]> wrote:

> On 5/25/2017 4:33 PM, Lou Berger wrote:
>> How about something adding something like the following to section 1
>>
>>    RFC5566 uses the mechanisms defined in RFC5512, while this document 
>>    replaces RFC5512
>>    it does not address how the tunnel types defined in RFC5566 can be used 
>>    with SAFIs other
>>    than the Encapsulation SAFI.
>
> I'll be happy to add this text.
>
>> Allowing a choice of tunnels between a pair of endpoints should not
>> require the origination of multiple routes with different NLRIs, or
>> (even worse) the use of add-paths.  I don't really see the merit of
>> this suggestion.
>>> The point is simplification for an unused use case.  Is your position
>>> based on theory or actual use?
>
> As it happens, I was just yesterday asked by an implementer whether a
> receiving endpoint could advertise two tunnels and allow the
> transmitting endpoint to select one, so there does seem to be an
> immediate use case.
>
> However, I regard it as very obvious that you might want to advertise
> several tunnels, along with some criteria for selecting which traffic
> goes into which tunnel.   There are numerous cases where this is done by
> configuring the transmitting and receiving endpoints of the tunnel, so I
> don't see why someone would regard the ability to signal this
> information as "theoretical".
>

Humm it also seems obvious to define a way to advertise changes in number 
of tunnels and tunnel attributes without also having to re advertising all 
the prefixes reachable over the tunnels - let's do that too as it obviously 
dramatically reduces update processing.  Think of it no need to advertise 
those thousands of prefixes just because some tunnels were added/removed, 
right?

But wait - we did that and have now decided that the complexity of the 
processing isn't worth optimizing such advertisment as *in practice* it is 
a corner use case. So, while I agree that supporting multiple tunnels for 
the same prefix is a real use case, I still question if having a second 
"optimized" mechanism to signal the tunnel information (in multiple 
sub-TLVs in the same attribute) is worth the implementation overhead. Note 
that the " suboptimal" mechanism will still have to be supported anyway 
since it just falls out of the definition, and also supports different 
lifetimes in tunnel endpoint management.

Lou
...