Eric, Thanks for the response — please find some follow-ups inline.
> On Feb 15, 2016, at 12:22 PM, Eric C Rosen <ero...@juniper.net> wrote: > > 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. > 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) > Sure. Thank you. >> >> 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. 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. >> … >> 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. 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. >> >> 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”. 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) >> Should an example be also added about MPLS-over-L3TPv3? > 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. >> >> 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 ;-)) 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>. >> >> 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. 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). > >> >> I hope these are clear and useful — Thanks! >> > 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
