Re: [bess] [mpls] [Editorial Errata Reported] RFC7510 (4350)

[Xuxiaohu <[e-mail]>]

Hi Carlos,

> -----Original Message-----
> From: Carlos Pignataro (cpignata) [mailto:[e-mail]]
> Sent: Wednesday, April 29, 2015 2:58 AM
> To: Adrian Farrel
> Cc: Loa Andersson; RFC Errata System; Xuxiaohu; [e-mail]; Lucy
> yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alvaro
> Retana (aretana); George Swallow (swallow); [e-mail]
> 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 <[e-mail]> 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
> >