Subject: [PWE3] [Technical Errata Reported] RFC5003 (3411)

From: RFC Errata System <[email-masked]>
Date: Thu, 15 Nov 2012 12:09:56 -0800 (PST)

The following errata report has been submitted for RFC5003,
"Attachment Individual Identifier (AII) Types for Aggregation".

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

--------------------------------------
Type: Technical
Reported by: Rajiv Asati <[email-masked]>

Section: 3.2

Original Text
-------------

     o Prefix = The 32-bit prefix is a value assigned by the provider or
       it can be automatically derived from the PE's /32 IPv4 loopback
       address.  Note that, for IP reachability, it is not required that
       the 32-bit prefix have any association with the IPv4 address
       space used in the provider's IGP or BGP.

Corrected Text
--------------

     o Prefix = The 32-bit prefix is a value assigned by the provider or
       it can be automatically derived from the PE's router-id i.e. LSR Id.
       Note that it is not required that
       the 32-bit prefix is IP routable or have any association with the 
       IPv4 address space used in the provider's IGP or BGP. 

Notes
-----
The intent of this RFC is to treat the 32bit prefix as a number that provides uniqueness in the network (within the ASN). While it can be derived from the IPv4 /32 Loopback address, it causes confusion when routers are configured with no IPv4. It is better to suggest using router-id used by LDP for calculating the LSR identifier. How is router-id calculated is outside the scope of this document.`

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. 

--------------------------------------
RFC5003 (draft-ietf-pwe3-aii-aggregate-02)
--------------------------------------
Title               : Attachment Individual Identifier (AII) Types for Aggregation
Publication Date    : September 2007
Author(s)           : C. Metz, L. Martini, F. Balus, J. Sugimoto
Category            : PROPOSED STANDARD
Source              : Pseudo Wire Emulation Edge to Edge INT
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

---

From: Luca Martini <[email-masked]>
Date: Thu, 15 Nov 2012 19:28:04 -0700

RFC Editor,

I propose to reject this Errata.
There is no technical merit in changing the example on how one might
possibly choose the 32bit number.
This is a NIT , and does not affect implementations, nor service
provider policies.
the text "Prefix = The 32-bit prefix is a value assigned by the provider
" is the main definition of how this 32 bit value is to be assigned.

Luca

Is the main point of this

---

From: Brian Haberman <[email-masked]>
Date: Fri, 16 Nov 2012 08:15:44 -0500

I have no issues with marking this erratum as rejected.  Are there other 
opinions?

Regards,
Brian

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 16 Nov 2012 13:41:10 +0000

The issue is the inclusion of IPv4 in that definition, which many implementations could swear by. You would be surprised to find most implementations simply copying IPv4 address here, because it is easy and automatic. 

In fact, I am not aware of any implementation that provides a mean to statically assign this 32-bit prefix to something other than IPv4 interface address.

Imagine an IPv6-only network, where the current definition would require many implementations to change, and force operators to do more manually assignments than needed.

So, router-id has to be manually configured, and then this 32-bit prefix has to be manually configured.

Such definition does not help when IPv6 PSN comes along. Wouldn't it be nice if the spec provided an automatic way, yet, stayed away from IP version here. A bit of definition change (cosmetic really) could go a long way in keeping our specs clear. 

Cheers,
Rajiv

Sent from my Phone

On Nov 16, 2012, at 8:16 AM, "Brian Haberman" <[email-masked]> wrote:

> I have no issues with marking this erratum as rejected.  Are there other opinions?
> 
> Regards,
> Brian
>

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 18 Nov 2012 06:10:41 +0000

I agree with Luca that it is a nit, 
and the existing text doesn't say that one MUST use the loopback address if not configured.

On the other hand the text is there to provide guidance,
and as such should help implementers that don't want to statically assign.

I think the proper classification is "Hold for Document Update", since that is how nits of this sort are usually handled.
Luca - note that that the guidelines say that this merely means that 
"any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update".

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Friday, November 16, 2012 15:16
To: Luca Martini
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] [Technical Errata Reported] RFC5003 (3411)

Regards,
Brian

>> "Attachment Individual Identifier (AII) Types for Aggregation".

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 18 Nov 2012 13:17:59 +0000

To me, the inclusion of an IPv4 address (/32 loopback) is one example and not part of the definition. As such I am not too concern about it since the definition piece is "32-bit prefix is a value assigned by the provider". That said, the example might be incorrectly extrapolated and not help clarify.

Consequently, I support Yaakov's proposed disposition of "Hold for Document Update". As a technical erratum it should be rejected, as an editorial it should be clarified.

Thanks,

-- Carlos.