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

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 11 Feb 2016 23:38:24 +0000

Hi, Eric,

Thanks for sending this out — I am interested in this document, and will give it a critical review (in particular the sections you call out below).

In the mean time, however, I wanted to send a few high-level comments (prepended with “CMP”) from scanning through it. I hope these are useful.

3.2.  Encapsulation Sub-TLVs for Particular Tunnel Types

   This section defines Tunnel Encapsulation sub-TLVs for the following
   tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE
   ([RFC7637]), GTP ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890],
   [RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890],
   [RFC4023]).

CMP: More comments below, but I am a bit confused about the need to include MPLS-in-GRE, and the lack of IP-in-IP (Tunnel Type 7) for example.

CMP: A couple of editorial comments as well: For GRE, I think you also need to cite RFC 7676 (GRE over IPv6)

CMP: Also, having this document Obsolete RFC 5512 effectively also orphans a number of Tunnel types and sub-TLVs. For example, Tunnel Types values 3-6 from RFC 5566 (IPsec Tunnel Encap) and IPsec Tunnel Authenticator sub-TLV. I do not know if the answer is to also have that incorporated (useful parts as you say) and obsoleted. Maybe not, maybe it does make sense given it is a short doc, which would lead to a complete self-contained set of Tunnel types.

3.2.4.  L2TPv3
…
      Cookie: an optional, variable length (encoded in octets -- 0 to 8
      octets) value used by L2TPv3 to check the association of a

CMP: The cookie can only take sizes 0, 4, or 8 octets, and not 0..8

3.2.7.  MPLS-in-GRE

CMP: This seems to be an example and not a separate encapsulation type. This is GRE Type, with MPLS as protocol sub-TLV. I see that the section says:

   While it is not really necessary to have both the GRE and MPLS-in-GRE
   tunnel types, both are included for reasons of backwards
   compatibility.

CMP: I will also note that having two different ways of doing the same thing (Tunnel Type 2 and protocol 0x8847 vs. Tunnel Type 11) takes us away from interop., and that there does not seem to be MPLS-in-GRE defined in any RFC (so it seems like potentially a good time to rationalize instead of perpetuate). My $0.02 only.

CMP: Should MPLS-over-GRE be an example only? Or otherwise, how do we interop the two types of “ MPLS-over-GRE”? Should an example be also added about MPLS-over-L3TPv3?

3.3.1.  IPv4 DS Field

CMP: Why not also define this for IPv6?

3.3.2.  UDP Destination Port

CMP: One additional thought. Obsoleting RFC 5512 also removes the anchor from RFC 5640 — that is not a terrible deal in itself, but is there also an opportunity to generalize the Load-Balancing approach thereby defined to also include the new encapsulations’ LB, UDP-based (port as the LB Field), etc?

I hope these are clear and useful — Thanks!

— Carlos.

> On Dec 28, 2015, at 10:20 AM, Eric C Rosen <[email-masked]> wrote:
> 
> The -01 revision of draft-ietf-idr-tunnel-encaps has the following changes from the -00 revision:
> 
> - By popular request, it has been written in such a way as to obsolete RFC5512.  This means that anything useful in RFC5512 had to be incorporated into the new draft.  I would welcome opinions on whether this was done correctly.
> 
> - Two new sub-TLVs are specified:  "MPLS Label Stack" and "Prefix-SID".  I would welcome opinions on whether these are useful or not.  (I'm pretty sure that the first is useful, the second is more speculative.)
> 
> - If you are familiar with deployed uses of the Encapsulation Extended Community, the Color Extended Community, or the Router's MAC Extended Community, it may be worth checking section 4 to make sure that the draft does not introduce any problems.
> 
> - I wish more folks would take a critical look at section 8, which is primarily about the use of VXLAN/NVGRE/VXLAN-GPE together with labeled address families.
> 
> I would also be interested in hearing if anyone has an opinion on the utility of using this sort of mechanism to signal IPsec tunnels.  Once RFC 5512 is obsoleted, RFC 5566 ("BGP IPsec Tunnel Encapsulation Attribute") will need to be revised.  It might be possible to generalize that in such a way as to facilitate the secure interconnection of two private ASes across the public Internet.  Comments on whether RFC 5566 takes a reasonable approach would be welcome.
> 
> 
> 
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 15 Feb 2016 12:22:05 -0500

> Thanks for sending this out — I am interested in this document, and will give it a critical review (in particular the sections you call out below).
Thanks!
> CMP: More comments below, but I am a bit confused about the need to include MPLS-in-GRE, and the lack of IP-in-IP (Tunnel Type 7) for example.
MPLS-in-GRE is included in section 3.2 because there is already a tunnel 
type codepoint allocated for it, and if that tunnel type is used, an 
encapsulation sub-TLV is needed in order to signal the GRE key.

One can argue that there is no need for the MPLS-in-GRE tunnel type, 
since everything you can do with it could be done instead with the GRE 
tunnel type.  But unless and until we decide to deprecate the 
MPLS-in-GRE tunnel type, it needs to be included.    In theory, I would 
love to see the MPLS-in-GRE tunnel type deprecated, but I worry that 
that might introduce a backwards compatibility problem.    This is 
certainly something that can be discussed by the WG.

IP-in-IP is not mentioned in section 3.2 because, although there is a 
tunnel type codepoint allocated for it, no one has ever defined an 
encapsulation sub-TLV for it.  Also, if it is necessary to signal values 
for the fields of the outer iP header, it might make more sense to use 
an "outer encapsulation sub-TLV" (section 3.3).  Do you have an opinion 
about this?
> CMP: A couple of editorial comments as well: For GRE, I think you also need to cite RFC 7676 (GRE over IPv6)
Sure.
> CMP: Also, having this document Obsolete RFC 5512 effectively also orphans a number of Tunnel types and sub-TLVs. For example, Tunnel Types values 3-6 from RFC 5566 (IPsec Tunnel Encap) and IPsec T…
I think RFC 5566 will have to be obsoleted and replaced.  I've been 
thinking about that, but I'm still not sure how much of 5566 should be 
moved into the tunnel-encaps draft and how much should be in a separate 
draft.  There are some non-obvious issues to consider.  For example, 
5566 really is  just intended to facilitate iPsec Security Associations 
between BGP Next Hops, but with the tunnel encapsulation attribute we 
could presumably set up Security Associations from ingress to egress.
> CMP: The cookie can only take sizes 0, 4, or 8 octets, and not 0..8
Do you have a reference for that?  Section 4.1 of RFC 3931 seems to say 
only that the field is variable length with a maximum size of 64 bits.
> CMP: I will also note that having two different ways of doing the same thing (Tunnel Type 2 and protocol 0x8847 vs. Tunnel Type 11) takes us away from interop., and that there does not seem to be M…
Tunnel type 11 is used by draft-ietf-bess-evpn-overlay.
>
> CMP: Should MPLS-over-GRE be an example only? Or otherwise, how do we interop the two types of “ MPLS-over-GRE”?
Well, the two ways of doing the same thing are explicitly defined to be 
equivalent, so I don't think there is an interop issue, the issue is 
more of "can we get rid of the MPLS-in-GRE type without causing a 
backwards compatibility problem".
> Should an example be also added about MPLS-over-L3TPv3?
Surely no one will ever propose MPLS-over-L2TPv3 again!
> CMP: Why not also define this for IPv6?
There are a lot of possible Outer Encapsulation sub-TLVs that could be 
created, I only included a couple of examples that seemed like they 
might be useful.  If you have some sub-TLVs to suggest for the case 
where the outer encapsulation is IPv6, please suggest some text.   (Some 
IPv6-specific text will probably make it easier to get the draft past 
the IESG ;-))
> CMP: One additional thought. Obsoleting RFC 5512 also removes the anchor from RFC 5640 — that is not a terrible deal in itself, but is there also an opportunity to generalize the Load-Balancing app…
I wasn't aware of RFC 5640.

I don't think there's anything in RFC 5640 that requires the 
Encapsulation-SAFI.  So at a minimum, I think we can get by with saying 
that the tunnel-encaps draft updates RFC 5640, and that the LB Block 
sub-TLV can be included in the a tunnel TLV of a tunnel encapsulation 
attribute that is attached to an update of any AFI/SAFI.

If you think it is worthwhile to generalize the load balancing approach 
of RFC 5640, perhaps the best approach would be to do a 5640bis.

> I hope these are clear and useful — Thanks!
Looking forward to any additional comments you might have!

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 29 Feb 2016 02:56:32 +0000

Eric,

Thanks for the response — please find some follow-ups inline.

> On Feb 15, 2016, at 12:22 PM, Eric C Rosen <[email-masked]> wrote:
> 
> MPLS-in-GRE is included in section 3.2 because there is already a tunnel type codepoint allocated for it, and if that tunnel type is used, an encapsulation sub-TLV is needed in order to signal the GRE key.
> 
> One can argue that there is no need for the MPLS-in-GRE tunnel type, since everything you can do with it could be done instead with the GRE tunnel type.  But unless and until we decide to deprecate the MPLS-in-GRE tunnel type, it needs to be included.    In theory, I would love to see the MPLS-in-GRE tunnel type deprecated, but I worry that that might introduce a backwards compatibility problem.    This is certainly something that can be discussed by the WG.
> 

I agree — and would welcome that discussion as well.

> IP-in-IP is not mentioned in section 3.2 because, although there is a tunnel type codepoint allocated for it, no one has ever defined an encapsulation sub-TLV for it.  Also, if it is necessary to signal values for the fields of the outer iP header, it might make more sense to use an "outer encapsulation sub-TLV" (section 3.3).  Do you have an opinion about this?

You are right, Section 3.2 is indeed about the sub-TLVs. I believe I was reacting to IP-in-IP not being mentioned anywhere (other than briefly in the IANA section).

Perhaps I was expecting something like this, although I agree with you it’s a no-op:

3.2.x. IP-in-IP

   This document does not defines an encapsulation sub-TLV for IP-in-IP tunnels.
   When the tunnel type is IP-in-IP, the encapsulation sub-TLV MUST NOT be used.

Now, IP-in-IP and other tunnels (like for example MPLS-over-UDP) present an interesting question (that you raise above): In these, is the encapsulation IP and UDP, or is this a null encapsulation with an outer encapsulation of IP and UDP?

To me, the pragmatic case is to use the Outer encapsulation sub-TLV for IP fields in IP-in-IP, and for UDP fields in MPLS-over-UDP.

However, if the Tunnel Type is IP-in-IP (7), then using an Outer-encapsulation sub-TLV would imply IP-in-IP-in-IP. Is IP-in-IP a null tunnel type with outer encapsulation and with protocol = 0x0800? No. It is an IP-in-IP tunnel type. No protocol (since the tunnel encap constraints it to IP), and no outer encap. It is not “further encapsulated inside UDP and/or IP” as the text in section 1.3

It would certainly help to explain this explicitly.

It gets equally interesting with MPLS-over-UDP, because “UDP” is not a tunnel type specified just yet, which could be used with MPLS protocol type sub-TLV. Or a more limiting and duplicative MPLS-in-UDP tunnel type.  What tunnel type is used there? null encap? protocol type sub-TLV?

One additional comment — I could not figure out the sorting order for the encapsulations in subsections 3.2.x. I would consider sorting by tunnel type value in ascending order, and starting each sub-section with a “This encapsulation sub-TLV is used when the Tunnel Type is XYZ (numerical value)"

>> CMP: A couple of editorial comments as well: For GRE, I think you also need to cite RFC 7676 (GRE over IPv6)

Thank you.

> I think RFC 5566 will have to be obsoleted and replaced.  I've been thinking about that, but I'm still not sure how much of 5566 should be moved into the tunnel-encaps draft and how much should be in a separate draft.  There are some non-obvious issues to consider.  For example, 5566 really is  just intended to facilitate iPsec Security Associations between BGP Next Hops, but with the tunnel encapsulation attribute we could presumably set up Security Associations from ingress to egress.

Indeed. Thank you — the goal would be that 5566 does not get completely out-of-sync.

>> 3.2.4.  L2TPv3

I forgot to mention, the way in which the encapsulation sub-TLV is defined, this specifies only encapsulation for L2TPv3 directly over IP. This section, as well as all references to it, should be “L2TPv3 over IP” (like the tunnel type is named now) http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types <http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types>

L2TPv3 can run:
* over IP: https://tools.ietf.org/html/rfc3931#section-4.1.1.1 <https://tools.ietf.org/html/rfc3931#section-4.1.1.1>
* over UDP: https://tools.ietf.org/html/rfc3931#section-4.1.2.1 <https://tools.ietf.org/html/rfc3931#section-4.1.2.1>

And L2TPv3 over UDP has a slightly different encap header, so using the outer encap sub-TLV is not the way to define L2TPv3 over UDP. Consequently, I’d explicitly say “L2TPv3 over IP” everywhere.

> Do you have a reference for that?  Section 4.1 of RFC 3931 seems to say only that the field is variable length with a maximum size of 64 bits.

Yes, RFC 3931, when defining the Assigned Cookie: https://tools.ietf.org/html/rfc3931#page-50 <https://tools.ietf.org/html/rfc3931#page-50> as well as the 4th paragraph of S8.2 of RFC 3931.

> Well, the two ways of doing the same thing are explicitly defined to be equivalent, so I don't think there is an interop issue, the issue is more of "can we get rid of the MPLS-in-GRE type without causing a backwards compatibility problem”.

Sorry, what I meant was if an endpoint understands one way, and the other endpoint the other way only.

I do not disagree with what you write, but an explicit statement would not hurt (and may help)

> Surely no one will ever propose MPLS-over-L2TPv3 again!

I meant it in the sense of why a special case for MPLS-over-GRE as its own type.

> There are a lot of possible Outer Encapsulation sub-TLVs that could be created, I only included a couple of examples that seemed like they might be useful.  If you have some sub-TLVs to suggest for the case where the outer encapsulation is IPv6, please suggest some text.   (Some IPv6-specific text will probably make it easier to get the draft past the IESG ;-))

Sorry I was not clear — this is what I meant:

Section 3.3.1 is defining a DS field based on RFC 2474. RFC 2474 in turn defines the DS field for the IPv4 TOS and the IPv6 TC octets.

Therefore, why would this sub-section be suddenly limited to IPv4, when 2474 applies to both IPv4 and IPv6?

In other words, why not: “3.3.1.  IP DS Field”?

[I did not mean let’s have some IPv6-specific sub-TLVs]

I have been thinking about the Flow Label advertisement for IPv6, but I’m still thinking about it :-)

Lastly, this reminds me of a very small nit: Sections 3.6 (and others?) refers to the MPLS ToS field, when that’s been renamed to the TC field https://tools.ietf.org/html/rfc5462 <https://tools.ietf.org/html/rfc5462>.

> I don't think there's anything in RFC 5640 that requires the Encapsulation-SAFI.  So at a minimum, I think we can get by with saying that the tunnel-encaps draft updates RFC 5640, and that the LB Block sub-TLV can be included in the a tunnel TLV of a tunnel encapsulation attribute that is attached to an update of any AFI/SAFI.

Exactly.

> 
> If you think it is worthwhile to generalize the load balancing approach of RFC 5640, perhaps the best approach would be to do a 5640bis.

If you don’t disagree, I think saying what you described two paragraphs above would really help (and most likely be sufficient).

> Looking forward to any additional comments you might have!

Apologies for the delay in sending these out as well as with this follow-up.

One additional small request — in Section 12.5, could we please reserve a couple of values for experiments?

“
   IANA is requested to assign two codepoints from the "BGP Tunnel
   Encapsulation Tunnel Types" registry for experimentation. The
   values 65534 and 65535 are recommended for experimental use.
“

Thanks!

— Carlos.