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

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.

On Nov 16, 2012, at 8:41 AM, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:

> 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" <brian@innovationslab.net> wrote:
> 
>> I have no issues with marking this erratum as rejected.  Are there other opinions?
>> 
>> Regards,
>> Brian
>> 
>> On 11/15/12 9:28 PM, Luca Martini wrote:
>>> 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
>>> On 11/15/2012 01:09 PM, RFC Errata System wrote:
>>>> 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 <rajiva@cisco.com>
>>>> 
>>>> 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
>> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
> 