Subject: [mpls] [Technical Errata Reported] RFC3107 (4499)

From: RFC Errata System <[email-masked]>
Date: Tue, 13 Oct 2015 15:05:29 -0700 (PDT)

The following errata report has been submitted for RFC3107,
"Carrying Label Information in BGP-4".

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

--------------------------------------
Type: Technical
Reported by: Alexander Okonnikov <[email-masked]>

Section: 3

Original Text
-------------
   A BGP speaker can withdraw a previously advertised route (as well as
   the binding between this route and a label) by either (a) advertising
   a new route (and a label) with the same NLRI as the previously
   advertised route, or (b) listing the NLRI of the previously
   advertised route in the Withdrawn Routes field of an Update message.
   The label information carried (as part of NLRI) in the Withdrawn
   Routes field should be set to 0x800000.  (Of course, terminating the
   BGP session also withdraws all the previously advertised routes.)

Corrected Text
--------------
   A BGP speaker can withdraw a previously advertised route (as well as
   the binding between this route and a label) by either (a) advertising
   a new route (and a label) with the same NLRI as the previously
   advertised route, or (b) listing the NLRI of the previously
   advertised route in the Withdrawn Routes field of
   an MR_UNREACH_NLRI attribute of an Update message.
   The label information carried (as part of NLRI) in the Withdrawn
   Routes field should be set to 0x000001.  (Of course, terminating the
   BGP session also withdraws all the previously advertised routes.)

Notes
-----
1. Labeled routes are withdrawn by virtue of MR_UNREACH_NLRI attribute.
2. Label value should be set to 0x00000 with BoS=1.  Value 0x800000 was carried from draft, where BoS was high-order bit.

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. 

--------------------------------------
RFC3107 (draft-ietf-mpls-bgp4-mpls-04)
--------------------------------------
Title               : Carrying Label Information in BGP-4
Publication Date    : May 2001
Author(s)           : Y. Rekhter, E. Rosen
Category            : PROPOSED STANDARD
Source              : Multiprotocol Label Switching
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 16 Oct 2015 16:16:19 -0400

Nice bit of detective work figuring out where the 0x800000 value came from.

However, I don't think the erratum can be accepted, given its potential 
for causing interoperability issues.

To the best of my knowledge, section 4 ("Advertising Multiple Routes to 
a Destination") is not widely implemented (to say the least), so the 
issue of "which route to the prefix did you intend to withdraw?" doesn't 
really come up.

On 10/13/2015 6:05 PM, RFC Errata System wrote:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Alexander Okonnikov <[email-masked]>
Date: Fri, 16 Oct 2015 23:40:01 +0300

Good. I know that at least three major vendors interwork correctly. One 
of them use 0x800000, and two others - 0x000000. No problems with 
interoperability were noticed. My point was to make label stack encoding 
consistent for both cases - when single and multiple routes are 
advertised. By the way, it is not clear for me why don't encode label 
from previously advertised route when this one is being withdrawn.

Thank you.

On 10/16/2015 11:16 PM, Eric C Rosen wrote:
> However, I don't think the erratum can be accepted, given its 
> potential for causing interoperability issues.
>
> To the best of my knowledge, section 4 ("Advertising Multiple Routes 
> to a Destination") is not widely implemented (to say the least), so 
> the issue of "which route to the prefix did you intend to withdraw?" 
> doesn't really come up.
>
>> 2. Label value should be set to 0x00000 with BoS=1.  Value 0x800000 
>> was carried from draft, where BoS was high-order bit.
>>
>> Instructions:
>> -------------

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 19 Oct 2015 13:46:03 -0400

On 10/16/2015 4:40 PM, Alexander Okonnikov wrote:
> interoperability were noticed.

Probably no one pays much attention to the label value in the Withdraw, 
because no one implements the capability to advertise multiple routes 
with the same prefix but different labels.

> By the way, it is not clear for me why don't encode label

If you only advertise one label per prefix, there's no real need to 
specify that label in the withdraw.  I think one of the implementers 
said that it would be easier if you didn't have to specify the label. 
But I'm pretty sure that there's no one who still remembers what the 
reasoning actually was at the time ;-)