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

From: Lou Berger <[email-masked]>
Date: Tue, 1 Sep 2015 11:55:23 -0400

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, [email-masked] 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
> [email-masked]
> 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
>

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Tue, 1 Sep 2015 17:31:19 +0000

Lou,

That¹s a good idea. We authors did discuss it amongst ourselves and do
plan to cover it in next revision.

Regards,
Keyur

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 1 Sep 2015 20:40:50 +0200

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)
<[email-masked]> wrote:
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Tue, 1 Sep 2015 18:48:08 +0000

I agree with Robert.

Also, even though I am not aware of any implementation of the
encapsulation SAFI, I know a few implementations of the RFC5512
encapsulation extended community, hence I don’t think the RFC5512 should
be obsoleted.

Thanks.
Jorge

-----Original Message-----
From: Idr <[email-masked]> on behalf of Robert Raszuk
<[email-masked]>
Date: Tuesday, September 1, 2015 at 11:40 AM
To: "Keyur Patel (keyupate)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Lou Berger <[email-masked]>,
"[email-masked]"
<[email-masked]>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-00.txt

>>>>  This draft is a work item of the Inter-Domain Routing Working Group
>>>>of
>>>>the IETF.
>>>>

---

From: Lou Berger <[email-masked]>
Date: Tue, 1 Sep 2015 14:57:52 -0400

On 9/1/2015 2:48 PM, Rabadan, Jorge (Jorge) wrote:
> encapsulation SAFI, 
We have one on top of quagga and expect to post it on gitub sometime soon.
> I know a few implementations of the RFC5512

I guess I wasn't clear.  I'm only proposing deprecating encap safi
(which requires 5512 to be obsoleted/replaced).  All other 5512
mechanisms will need to be documented somewhere and rather than a
5512bis, I'm proposing using draft-ietf-idr-tunnel-encaps.

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 1 Sep 2015 15:14:02 -0400

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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 1 Sep 2015 21:24:52 +0200

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.

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Tue, 1 Sep 2015 19:33:28 +0000

+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" <[email-masked]> wrote:

>>>>>         Title           : Using the BGP Tunnel Encapsulation
>>>>>Attribute
>>>>> without the BGP Encapsulation SAFI
>>>>>         Authors         : Eric C. Rosen
>>>>>                           Keyur Patel
>>>>>                           Gunter Van de Velde

---

From: Lou Berger <[email-masked]>
Date: Tue, 1 Sep 2015 15:46:19 -0400

- 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

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 2 Sep 2015 12:35:46 -0400

Originally I was hoping to leave RFC5512 in place, and just have the
tunnel-encaps draft update it.  But the feedback (both public and
private) has been overwhelmingly in favor of obsoleting RFC5512, with
the goal of having a single RFC that specifies the tunnel encapsulation
attribute.  Then folks won't have to figure out exactly which parts of
RFC5512 still apply and which parts don't.

With regard to encaps-SAFI, given that there are zero implementations
(assuming that Lou withdraws his ;-)), zero deployments, and (as far as
I can tell) no current interest in implementing or deploying it, I don't
think it makes sense to carry it forward in the new document.

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.

If the tunnel-encaps draft is to obsolete RFC5512, I think it will need
to incorporate the material on the encapsulation extended community, and
on the various sub-tlvs that are defined in RFC5512.  Note that the
tunnel-encaps draft already specifies how the encapsulation extended
community interacts with the tunnel encapsulation attribute.

I believe that the material in RFC5566 (on using the tunnel
encapsulation attribute to specify various sorts of IPsec tunnels) is
complex enough to merit an RFC of its own.  So I would propose that the
tunnel-encaps draft not include material from RFC5566, but that a
separate rfc5566bis draft be prepared.

---

From: Lou Berger <[email-masked]>
Date: Wed, 2 Sep 2015 12:42:16 -0400

Eric,
    I (obviously) support deprecating the Encap SAFI.  If this is the WG
consensus, then I sign up to  doing/driving a 5566bis that is aligned
with your new draft (I already have the core text done.)

If for some reason the WG decides to preserve  the Encap SAFI, I think
draft-ietf-idr-tunnel-encaps needs to cover how 5566 functionality works
with just using Encap Attribute.

Lou

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 2 Sep 2015 20:50:18 +0200

Hi Eric,

> attaching various attributes (including the tunnel encapsulation

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 2 Sep 2015 19:03:43 +0000

Hi Robert, 

>and not those "trendy" ones Keyur referred to which no longer use ISIS

Are you sure you meant to reference the BGP EPE draft? AFAIK, there is no
requirement for the encapsulation SAFI in this draft. The advertised EPE
SIDs are local segment routing labels - MPLS is the implied encapsulation.

Thanks,
Acee

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 2 Sep 2015 21:13:22 +0200

Hi Acee,

Of course I meant to include reference to EPE not the BGP-LS extension to
it :)
​Thank you !​

​The correct one is this:​

https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-central-epe-04

​To be precise the section I am referring to in this doc is section 5 where
using an encap SAFI would be section 5.6 when one would send next hops in
the NLRI with SR attribute or Encap Attribute carrying the egress
engineered labels, GRE keys etc....

Note that how the packet is sent over the network from ingress to egress
would be orthogonal. .

Best,
Robert.

---

From: Lucy yong <[email-masked]>
Date: Thu, 3 Sep 2015 02:17:32 +0000

My 2 cent is inline below.

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Wednesday, September 02, 2015 11:36 AM
To: Keyur Patel (keyupate); Lou Berger; Robert Raszuk
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-00.txt

Originally I was hoping to leave RFC5512 in place, and just have the tunnel-encaps draft update it.  But the feedback (both public and
private) has been overwhelmingly in favor of obsoleting RFC5512, with the goal of having a single RFC that specifies the tunnel encapsulation attribute.  Then folks won't have to figure out exactly which parts of
RFC5512 still apply and which parts don't.

With regard to encaps-SAFI, given that there are zero implementations (assuming that Lou withdraws his ;-)), zero deployments, and (as far as I can tell) no current interest in implementing or deploying it, I don't think it makes sense to carry it forward in the new document.

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.
[Lucy] For the given situation (RFC5512 and what the tunnel-encap draft covers), agree this approach. When specifying a new SAFI, the semantics in using the tunnel encapsulation attribute will be different from what the semantics described in the tunnel encap. draft, otherwise, no point to define a new SAFI for it. As Keyur mentioned in offline discussion, the tunnel encap. draft aims in for BGP and MP-BGP to support VXLAN/IP, NVGRE/IP transport in data plane, no intention to support any new BGP application.       

If the tunnel-encaps draft is to obsolete RFC5512, I think it will need to incorporate the material on the encapsulation extended community, and on the various sub-tlvs that are defined in RFC5512.  Note that the tunnel-encaps draft already specifies how the encapsulation extended community interacts with the tunnel encapsulation attribute.
[Lucy] if we expand the encapsulation attribute and allow it to work with certain AFI/SAFI, we may obsolete the encapsulation extended community or at least discourage use of it.

I believe that the material in RFC5566 (on using the tunnel encapsulation attribute to specify various sorts of IPsec tunnels) is complex enough to merit an RFC of its own.  So I would propose that the tunnel-encaps draft not include material from RFC5566, but that a separate rfc5566bis draft be prepared.
[Lucy] Agree. There are quite stuff related to tunnel security, good to cover all in a separate draft that obsoletes the RFC5566 as we talked offline.

Lucy

---

From: Lucy yong <[email-masked]>
Date: Thu, 17 Sep 2015 19:00:21 +0000

One comment:

Tunnel Encapsulation Extended Community defined in [RFC5512] is adopted and is specified in this draft. The changes are 1) can be attached to any AFI/SAFI which Tunnel Encapsulation attribute may be attached; 2) has a Remote Endpoint sub-TLV in Tunnel encapsulation Extended Community; 3) has no other sub-TLVs.

If tunnel encapsulation attribute is used to convey the tunnel property applying to a NLRI, no need to keep this extended community since tunnel encapsulation attribute can meet these 3 points.

In addition, this community specified here will not have the backward compatibility.

Regards,
Lucy 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Wednesday, September 02, 2015 11:36 AM
To: Keyur Patel (keyupate); Lou Berger; Robert Raszuk
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-00.txt

Lucy