Hi Carlos, > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:[email protected]] > Sent: Wednesday, April 29, 2015 2:58 AM > To: Adrian Farrel > Cc: Loa Andersson; RFC Errata System; Xuxiaohu; [email protected]; Lucy > yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alvaro > Retana (aretana); George Swallow (swallow); [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) which has been moved to BESS WG (see https://tools.ietf.org/html/draft-xu-bess-encaps-udp-00) recently. However... 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]> 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- > >> 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 > > _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
