Subject: [mpls] [Technical Errata Reported] RFC6790 (3431)

From: RFC Errata System <[email-masked]>
Date: Sun, 16 Dec 2012 11:40:49 -0800 (PST)

The following errata report has been submitted for RFC6790,
"The Use of Entropy Labels in MPLS Forwarding".

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

--------------------------------------
Type: Technical
Reported by: Jeff Wheeler <[email-masked]>

Section: 5.2

Original Text
-------------
This is an optional, transitive BGP attribute of value 28.

Corrected Text
--------------
This is an optional, transitive BGP Attribute having Attribute Type Code 28, length 0, and no data.

Notes
-----
"Value" is (slightly) confusing in this context.  The text should also explicitly specify that there isn't Attribute Data and thus the length will be 0.

Ambiguity on this matter may lead implementations to utilize the data field in some unforeseen way.  Other implementations may then reject the attribute, applying general attribute processing rules, with an Attribute Length Error (RFC 4271 S6.3 paragraph 4.)

Instructions:
-------------
This errata 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. 

--------------------------------------
RFC6790 (draft-ietf-mpls-entropy-label-06)
--------------------------------------
Title               : The Use of Entropy Labels in MPLS Forwarding
Publication Date    : November 2012
Author(s)           : K. Kompella, J. Drake, S. Amante, W. Henderickx, L. Yong
Category            : PROPOSED STANDARD
Source              : Multiprotocol Label Switching
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: Kireeti Kompella <[email-masked]>
Date: Sun, 16 Dec 2012 18:18:45 -0800

Jeff,

Good point.

Seeing the current IDR drama about "low order attribute bits", what's the
best way to state this in a future proof way?

How about:

"This is an optional, transitive BGP attribute of value 28.  The Length
MUST be set to 0 when sending (as the Value field is empty), and SHOULD be
ignored on receipt."

Kireeti

On Sun, Dec 16, 2012 at 11:40 AM, RFC Errata System <
[email-masked]> wrote:

> "Value" is (slightly) confusing in this context.  The text should also
> explicitly specify that there isn't Attribute Data and thus the length will
> be 0.
>
> Ambiguity on this matter may lead implementations to utilize the data
> field in some unforeseen way.  Other implementations may then reject the
> attribute, applying general attribute processing rules, with an Attribute
> Length Error (RFC 4271 S6.3 paragraph 4.)
>
> Instructions:
> -------------

-- 
Kireeti

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 17 Dec 2012 01:07:53 -0500

On Sun, Dec 16, 2012 at 9:18 PM, Kireeti Kompella
<[email-masked]> wrote:
> How about:
>
> "This is an optional, transitive BGP attribute of value 28.  The Length MUST
> be set to 0 when sending (as the Value field is empty), and SHOULD be
> ignored on receipt."

I think the text I supplied in the errata report is a better way to
express the underlying intent, without any confusion, than what you
suggest above.

"value 28" is actually not correct.  The field we are talking about is
literally called the Attribute Type Code and should be referred to as
such so there is not any confusion.  I have made some notes:
http://inconcepts.biz/~jsw/img/1121216aa-rfc6790pg14.jpg

There is disagreement on IDR about whether "sender," "sending," etc.
includes propagators of a route (RR or whatever) or if it only means
the originator of a route.  You use "sending," above, in the same
context as they argue does not mean propagator.  I think if you want
to be that expressive, then you should declare the mandatory behavior
for all of originator, propagator, and receiver.

If Length MUST be set to 0 then there is no possibility of data.  I
think suggesting that a value SHOULD be ignored then confuses the
reader.  If the Length is not 0, a BGP implementation which recognizes
Type Code 28 and knows this Attribute's Length MUST be 0 will follow
the general rules, which is the correct behavior.

In short, I think the corrected text I supplied is a concise
expression of your intent.
-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts