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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess