Ross, I agree with the reasoning you lay out — but I would add that there is a difference between updating an IANA registry with an extra citation (mostly harmless, possibly useful), versus updating a Standards Track RFC with an Erratum. I would further add that a reference description for how to use the Tunnel Type 13 is still missing, as RFC 7510 does not accomplish that.
Thanks! — Carlos (speaking as Carlos) > On Apr 29, 2015, at 5:22 PM, Ross Callon <[email protected]> wrote: > > I may be a bit confused here regarding what sort of references are intended > to be listed in the registry. > > Looking at the “Border Gateway Protocol (BGP) Parameters”, and scrolling down > to “BGP Tunnel Encapsulation Attribute Tunnel Types”, I see entries for > various encapsulation types with various references. As some examples: > > For the GRE tunnel type, I see a reference to RFC5512. RFC 5512 is “The BGP > Encapsulation SAFI and the BGP Tunnel Encapsulation Attribute”, and is > specifically not the RFC that defines GRE. > > For the IPsec in Tunnel-mode tunnel type, I see a reference to RFC 5566. > Again RFC 5566 is not the RFC that specifies IPsec in Tunnel-mode. > > For the VXLAN tunnel type, I see a reference to draft-sd-l2vpn-evpn-overlay. > One issue is that this is an out of date reference > (draft-sd-l2vpn-evpn-overlay has been replaced by > draft-ietf-bess-evpn-overlay). More importantly, this again is not the > document that defines VXLAN. Rather, draft-ietf-bess-evpn-overlay talks about > how to use various encapsulations (of which VXLAN is one) along with BGP > signaling to accomplish something. > > Thus to me, referencing RFC 7510 in this particular registry is not the same > sort of reference that is included along with the other tunnel types. > However, I don’t see any problem with referencing the document that defines > the tunnel method as an additional reference for each entry. If we are going > to do this then perhaps we (for some definition of “we”) should also add > other references to the registry, specifically the document that defines the > tunnel mechanism for each of the other tunnel types. > > Ross (speaking as co-author of RFC 7510) > > From: Carlos Pignataro (cpignata) [mailto:[email protected]] > Sent: Wednesday, April 29, 2015 3:25 PM > To: Xiaohu Xu > Cc: Adrian Farrel; Loa Andersson; RFC Errata System; Nischal Sheth; Lucy > yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alvaro > Retana (aretana); George Swallow (swallow); [email protected]; [email protected] > Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) > > Hi Xiaohu, > > On Apr 29, 2015, at 4:40 AM, Xuxiaohu <[email protected] > <mailto:[email protected]>> wrote: > > Hi Carlos, > > > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:[email protected] > <mailto:[email protected]>] > Sent: Wednesday, April 29, 2015 2:58 AM > To: Adrian Farrel > Cc: Loa Andersson; RFC Errata System; Xuxiaohu; [email protected] > <mailto:[email protected]>; Lucy > yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alvaro > Retana (aretana); George Swallow (swallow); [email protected] > <mailto:[email protected]> > Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) > > Hi, Adrian, > > Thanks for the additional context. Note that I did not object any changes made > to the registry itself (although I still think that pointing to RFC 7510 is > incorrect), > only to the errata. Modifying the data plane document to include an IANA > action > for BGP sounds off. > > In other words, I see two problems with the approach from the errata (or > really > two sides of the same issue): > > 1. RFC 7510 specifies the data plane encapsulation, and not the BGP > signaling. As > such, it does not make for a good reference for the BGP Tunnel Encapsulation > Attribute Tunnel Type 13. > > 2. Existing entries in the "BGP Tunnel Encapsulation Attribute Tunnel Types" > registry point to the documents which specify how that attribute is used. > > For example, the value 1, L2TPv3 over IP, points to RFC 5512 and not to RFC > 3931. The value 2, GRE, points to RFC 5512 and not to RFC 2784. The value 4 > points to RFC 5566 and not to RFC4302, RFC4303. > > In fact, I had ever followed the above logic by specifying the BGP signaling > for MPLS-in-UDP in a separate doc > (https://tools.ietf.org/html/draft-xu-softwire-encaps-udp-00 > <https://tools.ietf.org/html/draft-xu-softwire-encaps-udp-00>) which has been > moved to BESS WG (see https://tools.ietf.org/html/draft-xu-bess-encaps-udp-00 > <https://tools.ietf.org/html/draft-xu-bess-encaps-udp-00>) recently. However… > > > I am not implying that a new I-D is necessarily required. I am saying that: > 1. It seems a step was skipped with this Errata, where a BGP parameter points > to a data plane definition, and > 2. It appears to be technically incorrect, since there are two potential > modes (with and without DTLS) but one entry only. > > Thanks, > > — Carlos. > > > Best regards, > Xiaohu > > > There is another technical problem with the current approach: RFC 7510 > specifies two UDP ports, for MPLS-in-UDP and MPLS-in-UDP with DTLS > respectively. To which one of these two does the BGP Tunnel Encapsulation > Attribute Tunnel Type value of 13 correspond to? Do you actually need two > Types? Further, do you need to consider the LB from RFC 5640? > > Please see more inline. > > > On Apr 28, 2015, at 8:34 AM, Adrian Farrel <[email protected] > <mailto:[email protected]>> wrote: > > Hi Carlos, > > Since I raised the issue... > > The text that was omitted was agreed for inclusion between the RFC > Editor, IANA, and responsible AD before the publication of the RFC, > but was fumbled by the RFC Editor. > > The RFC Editor requested this report to be submitted to resolve this > issue, and I checked with the ADs before I posted it. > > The problem it solves is that the existing registry entry points at an > I-D that caused the allocation of the code point, but that I-D is not > a good reference for explaining what "MPLS in UDP" is. This document > provides a better indication. > > > The reference should not explain what "MPLS in UDP" is. The reference should > explain what is the BGP Tunnel Encapsulation Attribute Tunnel Type 13 for MPLS > in UDP. > > > You said... > > > RFC 7510 states that it ³specifies an IP-based encapsulation for > MPLS, called MPLS-in-UDP² but there is no mention to the > specification of any signaling associated to setting up said > encapsulation. In other words, it self-concerns itself with the encap. > > That is correct. And there is no attempt to define any signaling or > add any mention of signaling to this document. > > This is not a forward pointer, but a request to include a backward > pointer. That is, it is a request to update the entry that already > exists in the registry with a pointer to this document so that people > can see what "MPLS in UDP" is when they encounter the value in the registry. > > > I understand. My comment is that the reference should not be to "MPLS in > UDP". The same way that the Type 1 does not point to RFC 3931. > > > Further, there is no mention in RFC 7510 of ³BGP² and no reference to > RFC 5512. For a document specifying a BGP Tunnel Encapsulation > Attribute Tunnel Type, I¹d expect a reference (normative) to RFC 5512 > (such as in RFC 5566). > > This document does not specify a BGP Tunnel Encapsulation Attribute > and there is no request for it to make such a specification. > > References could be included, but they would be pointless because > there is nothing to hook the references to. The *only* change > requested is to attach a pointer to the existing entry in the registry. > > > Lastly, the IANA page points to a different document: > http://www.iana.org/assignments/bgp-parameters/bgp- > <http://www.iana.org/assignments/bgp-parameters/bgp-> > parameters.xhtml#tunnel- > types > > Value Name Reference > 13 MPLS in UDP Encapsulation > [draft-ietf-l3vpn-end-system] > > Yes. > Have you read that document? > > This errata report does not request removal of that reference. It > requests the addition of an extra reference. How is that a problem? > > > I see not problem with the addition of a reference in an IANA registry. > > I do see a problem with modifying the RFC by way of an errata. > > > For those of you who have read around the subject, you may recall a > prolonged series of emails across a number of mailing lists where a > number of different new I-Ds were proposed to give a more substantive > reference for the tunnel type. > > This errata report solves that issue without needing further documents. > > > Can the reference be added without the Erratum? That seems possible to me. > > > You may also like to note that we are dealing with a FCFS registry > where the documents supplied as references do not always provide a > good explanation. Is it better to leave the registry with a poor > reference, or to add a somewhat better one? > > > Net-net, this RFC is not the right place to be a pointer for this > assignment. > > I respect your right to hold that opinion, but I don't think you have > given any valid reasons for holding it. Perhaps this lack is caused by > unfamiliarity with FCFS registries. > > > I am happy to be educated. I re-read the FCFS definition form RFC 5226. Why > does RFC 7510 need to be modified for this? > > Thanks, > > - Carlos. > > > Adrian
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
