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!
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
