RE: AII differences between PW routing and l2vpn signalling draftprovisionong methods.

"Chris Metz \(chmetz\)" <chmetz@cisco.com> Fri, 02 December 2005 23:20 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiKD2-0006Td-8Y; Fri, 02 Dec 2005 18:20:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiKCz-0006T8-WB for l2vpn@megatron.ietf.org; Fri, 02 Dec 2005 18:20:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12241 for <l2vpn@ietf.org>; Fri, 2 Dec 2005 18:20:06 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiKXl-0007vk-In for l2vpn@ietf.org; Fri, 02 Dec 2005 18:42:22 -0500
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 02 Dec 2005 15:20:44 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.99,208,1131350400"; d="scan'208"; a="16440037:sNHT25639988"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB2NKX4b022039; Fri, 2 Dec 2005 18:20:41 -0500 (EST)
Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Dec 2005 18:20:37 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 02 Dec 2005 18:20:35 -0500
Message-ID: <EAE1CBBD071180449FC50C37CFC78394DC6738@xmb-rtp-202.amer.cisco.com>
Thread-Topic: AII differences between PW routing and l2vpn signalling draftprovisionong methods.
Thread-Index: AcX3bCNCqUrVybg+SZyj42ms6hyplAAA6RjQAAa+pBA=
From: "Chris Metz (chmetz)" <chmetz@cisco.com>
To: Mustapha Aissaoui <mustapha.aissaoui@alcatel.com>, "Luca Martini (lmartini)" <lmartini@cisco.com>, L2VPN <l2vpn@ietf.org>
X-OriginalArrivalTime: 02 Dec 2005 23:20:37.0411 (UTC) FILETIME=[00B80730:01C5F797]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d16ce744298aacf98517bc7c108bd198
Content-Transfer-Encoding: quoted-printable
Cc: David McDysan <dave.mcdysan@mci.com>, bsd@cisco.com
Subject: RE: AII differences between PW routing and l2vpn signalling draftprovisionong methods.
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l2vpn.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
Sender: l2vpn-bounces@ietf.org
Errors-To: l2vpn-bounces@ietf.org

Hey Folks-
Here is my take on this interesting question:

- AII Type 1 is for provisioning models that best make use of a
fixed-length 32-bit value. L2VPN signaling is one and does not need
anything more (from the AII perspective). Another might be FEC129
compatibility with AC's previously configured with original Pwid.
Selective VPWS with no aggregation is not one. 

- AII Type 2 is necessary for Selective VPWS because a) many discrete
AII values can be summarized, b)provides structure for global
uniqueness.

- Either AII type should not infer reachability to the TT-PE between or
within an AS. That can only be determined by the locality of the ST-PE
and the precision of the routing information (IP, PW L2, etc.) it
possesses to route the PW signaling messages to the TT-PE. Examples:
ST-PE in one AS will have complete IP reachability and LDP session to
TT-PE in another AS. FEC129/AII Type 2 (or AII Type 1) is then used in
PW setup. 

Conversely there may be </32 AII prefix, LDP next_hop> tuples in PW L2
routing table and MS-PW signaling would be required to reach the TT-PE.
Why can't the ST-PE include an AII Type 1 value in the FEC129 field and
expect PW routing to progress it towards the TT-PE? 

There could also be FEC129/AII Type 2 PWs setup between ST-PE and TT-PE
in the same AS.

- Having different AII types for different applications/services is
useful for network management, trouble-shooting, provisioning and
logical functional separation in the network elements. I am not entirely
clear, in the absense of a different AII types, how a local ST-PE would
know when/how to launch PW setups if there was only one AII Type and
they all arrived via BGP? I can smell new BGP attributes on the horizon
:-) ... "here is the new BGP AII Type 2 attribute " yuck, yuck, yuck ...


- I have said it before and will say it again: we can debate on one or
two AII types but eventually we will need more because some
application/service/provisioning model will come along and AII Type 1/2
will be insufficient (read IPv6).

IMHO we should:

- go with the two AII types ...

- decouple MS-PW LDP signaling procedures from AII Type 2. Really
shouldn't any AII type suffice?

Thanks, 

Chris






 







	 

 



  

> -----Original Message-----
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] 
> On Behalf Of Mustapha Aissaoui
> Sent: Friday, December 02, 2005 10:58 AM
> To: Luca Martini (lmartini); 'L2VPN'
> Cc: 'David McDysan'; bsd@cisco.com
> Subject: RE: AII differences between PW routing and l2vpn 
> signalling draftprovisionong methods.
> 
> Luca,
> I do not believe there is any substantial difference that 
> warrants to standardize two different AII types. A MS-PW can 
> also terminate on a VSI, e.g., VPLS.
> 
> The issue is to be able to encode the target termination 
> interface: an endpoint for a p2p PW or a VSI for a VPLS in a 
> way such that it will work for both single hop PWs and 
> MS-PWs. Both types can be used for the various L2VPN applications.
> 
> Pragmatically, the way to go is to deprecate the FEC 129 as 
> defined in draft-ietf-l2vpn-signaling-06.txt (Type 1) and 
> extend the Type 2 to cover the various applications. One 
> other reason to deprecate Type 1 is that we do not want an 
> implementation to use different FEC 129 types for single-hop 
> PW and MS-PW. FEC 128 will be restricted to singe hop PW and 
> will be fine as long as we specify a way to reach U-PEs which 
> are on a FEC 129 Type 2 network.
> 
> Mustapha.
> -----Original Message-----
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] 
> On Behalf Of Luca Martini
> Sent: Friday, December 02, 2005 1:09 PM
> To: L2VPN
> Cc: David McDysan; bsd@cisco.com
> Subject: AII differences between PW routing and l2vpn 
> signalling draft provisionong methods.
> 
> WG,
> 
> After a good discussion with Bruce Davie,  we came up with 
> the following explanation on why we need to have different 
> AII type int he PW setup and maintenance protocol.
> This note explains why draft-ietf-l2vpn-signaling-06.txt (the 
> L2VPN Signaling draft) and 
> draft-balus-bocci-martini-dyn-ms-pwe3-00.txt (the MS PW
> draft) make use of different AII types, as defined in 
> draft-metz-aii-aggregate-01.txt.
>  In a nutshell, the two drafts use different AII types 
> because they are tackling different problems. Specifically, 
> L2VPN Signaling draft is concerned with setting up all the 
> PWs for a given L2VPN, while the MS PW draft is concerned 
> with setting up individual PWs.
>  Because it is concerned with building L2VPNs, the L2VPN 
> Signaling draft makes use of the AGI (the contents of which 
> effectively identify the
> VPN) plus the AII to identify a particular PW. Hence, the AII 
> only needs to identify a "pool" or a VSI relative to a 
> particular AGI. Hence a simple 32 bit AII is sufficient.
> By contrast, because the MS PW draft is concerned with 
> setting up individual PWs, not L2VPNs, it has no use for the 
> AGI - there is no "group" concept.
> Hence it fully identifies the PW in the AII. Because there 
> may be many PWs connected to a given U-PE device, it is 
> necessary to identify the PWs relative to a given U-PE. And 
> it is necessary to identify the U-PE within the AII so that 
> the signaling message can be routed toward the correct U-PE.
> Hence the requirements for the AII are quite different, and 
> it makes sense to use an AII type that is designed to meet 
> these requirements.
> It is obvious that the simple AII type could be encoded in 
> the more complex AII type by leaving various fields set to 
> zero, but this does not seem to serve any useful purpose.
> 
> Luca
> 
> 
>