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

[Eric C Rosen <[e-mail]>]

On 2/11/2016 6:38 PM, Carlos Pignataro (cpignata) wrote:
> 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).
Thanks!
>
> 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.
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 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.
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.
>
> 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
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.
>
> 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.
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!
>
> 3.3.1.  IPv4 DS Field
>
> 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 ;-))
>
> 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 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!