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

[Ross Callon <[e-mail]>]

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:[e-mail]]
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); [e-mail]; [e-mail]
Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350)

Hi Xiaohu,

On Apr 29, 2015, at 4:40 AM, Xuxiaohu <[e-mail]<mailto:[e-mail]>> wrote:

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]<mailto:[e-mail]>; Lucy
yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alvaro
Retana (aretana); George Swallow (swallow); [e-mail]<mailto:[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...


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 <[e-mail]<mailto:[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