Subject: [mpls] [Editorial Errata Reported] RFC7510 (4350)

From: RFC Errata System <[email-masked]>
Date: Mon, 27 Apr 2015 13:21:10 -0700 (PDT)

The following errata report has been submitted for RFC7510,
"Encapsulating MPLS in UDP".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7510&eid=4350

--------------------------------------
Type: Editorial
Reported by: Adrian Farrel <[email-masked]>

Section: 7

Original Text
-------------
Absent

Corrected Text
--------------
7.1  BGP Tunnel Encapsulation Attribute Tunnel Type

   IANA maintains a registry called "Border Gateway Protocol (BGP)
   Parameters" with a sub-registry called "BGP Tunnel Encapsulation
   Attribute Tunnel Types".  IANA has previously allocated a code point
   called "MPLS in UDP Encapsulation" with value 13. IANA has added
   this document as a further reference for that code point.

Notes
-----
This text reflects a pre-publication agreement to include a request to IANA for the action that it describes.

Note that the text supplied here shows the use of the past tense as is normal in an RFC that reports IANA action.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7510 (draft-ietf-mpls-in-udp-11)
--------------------------------------
Title               : Encapsulating MPLS in UDP
Publication Date    : April 2015
Author(s)           : X. Xu, N. Sheth, L. Yong, R. Callon, D. Black
Category            : PROPOSED STANDARD
Source              : Multiprotocol Label Switching
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: Loa Andersson <[email-masked]>
Date: Tue, 28 Apr 2015 10:00:45 +0200

Deborah,

I'm a bit uncertain on who actually have the final says about
errata - I think it is the AD responsible for the wg producing
the RFC, after consultation with authors and wg chairs/shepherd.

Anyhow I think this errata should be approved.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 28 Apr 2015 10:55:40 +0000

Hi,

I do not think this erratum should be approved, and I do not believe it is
Editorial in nature.

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.

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).

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]

Net-net, this RFC is not the right place to be a pointer for this
assignment.

Thanks,

‹ Carlos

-----Original Message-----
From: Loa Andersson <[email-masked]>
Date: Tuesday, April 28, 2015 at 4:00 AM
To: RFC Errata System <[email-masked]>, Xiaohu Xu
<[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>, Ross Callon
<[email-masked]>, "[email-masked]" <[email-masked]>, Alia
Atlas <[email-masked]>, "[email-masked]" <[email-masked]>, Alvaro
Retana <[email-masked]>, "George Swallow (swallow)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350)

>> Note that the text supplied here shows the use of the past tense as is
>>normal in an RFC that reports IANA action.
>>
>> Instructions:
>> -------------
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Apr 2015 13:34:35 +0100

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.

You said...

> 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.

> Tunnel Type, I¹d expect a reference (normative) to RFC 5512 (such as in

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.

> 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?

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.

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

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.

Adrian

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 28 Apr 2015 18:58:21 +0000

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.

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-masked]> wrote:
> 
> Hi Carlos,
> 

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.

> 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.

> 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.

> This errata report solves that issue without needing further documents.

Can the reference be added without the Erratum? That seems possible to me.

> valid reasons for holding it. Perhaps this lack is caused by unfamiliarity with

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.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 29 Apr 2015 08:40:33 +0000

Hi Carlos,

> From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
> Sent: Wednesday, April 29, 2015 2:58 AM
> To: Adrian Farrel
> Cc: Loa Andersson; RFC Errata System; Xuxiaohu; [email-masked]; Lucy
> yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alvaro
> Retana (aretana); George Swallow (swallow); [email-masked]
> 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.
> 
> 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.
> 
> > 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.
> >
> > This errata report does not request removal of that reference. It
> > requests the addition of an extra reference. How is that a problem?
> >
> 
> > 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.
> > 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?
> >
> > 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
> >

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 29 Apr 2015 19:24:42 +0000

Hi Xiaohu,

> On Apr 29, 2015, at 4:40 AM, Xuxiaohu <[email-masked]> wrote:
> 
> Hi Carlos,
> 
>> From: Carlos Pignataro (cpignata) [mailto:[email-masked] <mailto:[email-masked]>]
>> Cc: Loa Andersson; RFC Errata System; Xuxiaohu; [email-masked] <mailto:[email-masked]>; Lucy
>> Retana (aretana); George Swallow (swallow); [email-masked] <mailto:[email-masked]>
> 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.

---

From: Ross Callon <[email-masked]>
Date: Wed, 29 Apr 2015 21:22:01 +0000

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

Hi Xiaohu,

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

Hi Carlos,

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Wednesday, April 29, 2015 2:58 AM
To: Adrian Farrel
Cc: Loa Andersson; RFC Errata System; Xuxiaohu; [email-masked]<mailto:[email-masked]>; Lucy
yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alvaro
Retana (aretana); George Swallow (swallow); [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350)

Hi, Adrian,

In other words, I see two problems with the approach from the errata (or really
two sides of the same issue):

Thanks,

- Carlos.

Best regards,
Xiaohu

Please see more inline.

On Apr 28, 2015, at 8:34 AM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

You said...

Lastly, the IANA page points to a different document:
http://www.iana.org/assignments/bgp-parameters/bgp-
parameters.xhtml#tunnel-
types

Value     Name                                                     Reference

Yes.

Thanks,

- Carlos.

Adrian

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 29 Apr 2015 21:30:05 +0000

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-masked]> wrote:
> 
> 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.
> 
> 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.
> 
> On Apr 29, 2015, at 4:40 AM, Xuxiaohu <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Carlos,
> 
> 
> On Apr 28, 2015, at 8:34 AM, Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Carlos,
> 
> http://www.iana.org/assignments/bgp-parameters/bgp- <http://www.iana.org/assignments/bgp-parameters/bgp->
> parameters.xhtml#tunnel-
> types
> 
> Value     Name                                                     Reference