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 protected]> 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 protected]
> https://www.ietf.org/mailman/listinfo/bess
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
