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

Hi all,
There is an aggregation scheme for AII PW routing defined in 
[draft-ietf-pwe3-dynamic-ms-pw]. In a pure IPv6 network, the 32bit address 
would LDP Router-id, and could not be aggregated. If we still use the 
32bit number in an IPv6 network, there would be less or no aggregation for 
AII type2 PW routing entries. I even doubt if the longest match for PW 
routing table lookup is still needed in IPv6 network. This is also an 
concern for draft-ietf-pwe3-dynamic-ms-pw.

Thanks
Lizhong

> 
> ------------------------------
> 
> Message: 2
> Date: Sun, 18 Nov 2012 13:17:59 +0000
> From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
> To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
> Cc: Brian Haberman <brian@innovationslab.net>,   "Chris Metz \(chmetz\)"
>    <chmetz@cisco.com>,   "Luca Martini \(lmartini\)" 
<lmartini@cisco.com>,
>    "florin.balus@alcatel-lucent.com" <florin.balus@alcatel-lucent.com>,
>    "pwe3@ietf.org" <pwe3@ietf.org>,   "rdroms.ietf@gmail.com"
>    <rdroms.ietf@gmail.com>,   "sugimoto@nortel.com" 
<sugimoto@nortel.com>,
>    "andrew.g.malis@verizon.com" <andrew.g.malis@verizon.com>
> Subject: Re: [PWE3] [Technical Errata Reported] RFC5003 (3411)
> Message-ID:
>    <95067C434CE250468B77282634C96ED320DBD2A7@xmb-aln-x02.cisco.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> 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 
thisdocument.`
> >>>> 
> >>>> 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
> > 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
> 
> 
> End of pwe3 Digest, Vol 103, Issue 20
> *************************************