Hi Xiaohu, > On Apr 29, 2015, at 4:40 AM, Xuxiaohu <[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]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
