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

[Robert Raszuk <[e-mail]>]

Hi Eric,

> Of course, nothing stops someone from writing a new draft specifying
> something like the Encaps-SAFI, and specifying the semantics of
> attaching various attributes (including the tunnel encapsulation
> attribute) to it.

True that nothing stops to do that work. It is only that such work to
go from draft to RFC will take easily 5-8 years in the current IETF
process.

Use case for encapsulation SAFI I see is described in
https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-00
especially when there is need to do EPE in traditional WAN networks
and not those "trendy" ones Keyur referred to which no longer use ISIS
or OSPF.

As you know (apparently not everyone does) attaching an attribute to
route which is not used for forwarding (due to Admin Distance as
example) makes implementations very ugly and kludgy.

Sorry but I do not buy arguments stating as a main reason that
deploying new SAFI is hard. If you deploy new SAFI in a p2p fashion
between controller and PE/ASBR (which is exactly what is needed for
EPE use case) its deployment is as easy as deploying BGP-LS SAFI.

Cheers,
Robert.

PS1:

> But the feedback (both public and private) has been
> overwhelmingly in favor of obsoleting RFC5512

Just curious if that feedback came from the same folks who voted and
encouraged original specification or completely different ones .... ;)

PS2:

For EPE use case using Encap SAFI for signalling controller to edges
is just an option. There could be of course alternatives worked for
example in I2RS WG or using YANG models and NETCONF. So I will not be
making much noise about keeping it any more. It just looks bizarre to
obsolete something which seems useful.