Re: AII differences between PW routing and l2vpn signallingdraftprovisionong methods.

Jixiong Dong <dongjixiong@huawei.com> Thu, 08 December 2005 02:58 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 1EkByq-000355-55; Wed, 07 Dec 2005 21:58:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkBym-00033A-Ez; Wed, 07 Dec 2005 21:57:58 -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 VAA13950; Wed, 7 Dec 2005 21:57:03 -0500 (EST)
Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkCKZ-0005yw-UW; Wed, 07 Dec 2005 22:20:29 -0500
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR500L0ISDLX0@szxga03-in.huawei.com>; Thu, 08 Dec 2005 11:00:58 +0800 (CST)
Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR500F49SDLWD@szxga03-in.huawei.com>; Thu, 08 Dec 2005 11:00:57 +0800 (CST)
Received: from d10570a ([10.70.77.239]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR500HBPSL8TK@szxml02-in.huawei.com>; Thu, 08 Dec 2005 11:05:32 +0800 (CST)
Date: Thu, 08 Dec 2005 10:55:19 +0800
From: Jixiong Dong <dongjixiong@huawei.com>
To: Florin Balus <balus@nortel.com>, pwe3 <pwe3@ietf.org>, Luca Martini <lmartini@cisco.com>
Message-id: <012e01c5fba2$d35390b0$ef4d460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <9671A92C3C8B5744BC97F855F7CB64650758AEFA@zcarhxm1.corp.nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1
Content-Transfer-Encoding: 7bit
Cc: L2VPN <l2vpn@ietf.org>, David McDysan <dave.mcdysan@mci.com>, Mustapha Aissaoui <mustapha.aissaoui@alcatel.com>, bsd@cisco.com
Subject: Re: AII differences between PW routing and l2vpn signallingdraftprovisionong 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

Hi Florin,

I agree with you on this point completely.

Thanks,
Dong

----- Original Message ----- 
From: "Florin Balus" <balus@nortel.com>
To: "Jixiong Dong" <dongjixiong@huawei.com>; "pwe3" <pwe3@ietf.org>; "Luca Martini" <lmartini@cisco.com>
Cc: <bsd@cisco.com>; "Mustapha Aissaoui" <mustapha.aissaoui@alcatel.com>; "David McDysan" <dave.mcdysan@mci.com>; "L2VPN" <l2vpn@ietf.org>
Sent: Wednesday, December 07, 2005 8:28 PM
Subject: RE: AII differences between PW routing and l2vpn signallingdraftprovisionong methods.



Hi Dong,

[..]

>Moreover, I suggest we should reserve the AGI field in ms-pw 
>signaling so that we can use it for group status notification 
>or group pw teardown and 
>so on as indicated in the draft 
>"draft-ietf-pwe3-control-protocol-17.txt".
>When AGI = 0, we can ignore this field.

There is a TLV already in place for that (see 5.3.2.2  PW Grouping TLV
in the above draft)... AGI in my opinion should still be used during the
signaling process for the same functionalities as described in L2VPN
Signaling: e.g. VPN membership...

Regards,
Florin
>
>Regards,
>Dong
>
>----- Original Message ----- 
>From: "Florin Balus" <balus@nortel.com>
>To: "Luca Martini" <lmartini@cisco.com>
>Cc: "L2VPN" <l2vpn@ietf.org>; "David McDysan" 
><dave.mcdysan@mci.com>; "Mustapha Aissaoui" 
><mustapha.aissaoui@alcatel.com>; <bsd@cisco.com>
>Sent: Wednesday, December 07, 2005 12:33 AM
>Subject: RE: AII differences between PW routing and l2vpn 
>signallingdraftprovisionong methods.
>
>
>
>Luca,
>
>It looks like we are making progress here. Let me summarize 
>what I understood from your follow up:
>- you are acknowledging that VPLS/VPWS might use either one or 
>a combination of both MS and SS-PWs to interconnect their 
>VSIs/VFs associated with their pools?
>- in your view AII type 1 and implicitly the (AGI, 32 bit AII) 
>addressing scheme solves in the simplest way the provisioning 
>model for VPLS/VPWS based on <BGP> Autodiscovery of the endpoints?
>
>Can you confirm my summary? 
>
>I am happy with the first part. For the second part we should 
>also note there are a good chunk of L2VPNs (all currently 
>deployed LDP-VPLS) provisioning models where no AD is 
>used/available. In my opinion, AII type 2 is a must in these 
>scenarios whenever at least one MS-PW is involved. That is the 
>first reason for saying that there is not a clear delineation 
>- AII type 1 for L2VPNs, type 2 for Individual MS-PWs.
>
>On the other hand, I agree that until a new scheme for 
>AD-based provisioning model is described, the one described in 
>L2VPN Signaling is the only one available. Still I still think 
>what is happening during the <BGP> AD process does not dictate 
>what is included in the fields used for PW Signaling phase. 
>Furthermore before closing on where each AII type should be 
>used, I think we should spend some time looking into options 
>to streamline the BGP AD procedures for the generalized case 
>(where either a MS/SS-PW may be used for L2VPNs).
>
>See also in-line...
>
>Thanks,
>Florin
>
>
>>-----Original Message-----
>>From: Luca Martini [mailto:lmartini@cisco.com]
>>Sent: Monday, December 05, 2005 12:26 PM
>>To: Balus, Florin [CAR:6955:EXCH]
>>Cc: Mustapha Aissaoui; L2VPN; David McDysan; bsd@cisco.com
>>Subject: Re: AII differences between PW routing and l2vpn
>>signalling draftprovisionong methods.
>>
>>
>>Florin,
>>
>>Florin Balus wrote:
>>> I agree with Mustapha's proposal: we should just deprecate
>>AII type 1
>>> before people start implementing it. All its functionality could be 
>>> easily reproduced if need be using AII type 2: just set
>>Global ID and
>>> Prefix fields to zero. L2VPN Signaling itself proposes a similar
>>>   
>>Prefixing the fields to 0 just means that you really have 
>encoded a new
>>AII type , but you are hiding it.
>
>Is that a problem? Isn't the same thing proposed for BGP 
>Autodiscovery in L2VPN Signaling: all the NLRI fields from BGP 
>VPLS SAFI are set to zero except a 32 bits one... 
>
>In any case I just mentioned the above option (set Global ID, 
>Prefix fields to zero) as a posibility. I don't really see a 
>problem to include the real values for the Global ID and 
>Prefix fields when signaling any PW, regardless of whether it 
>connects VSIs/Pools/VFs, or whether it is SS/MS type.
>
>>What happens when a new provisioning model comes along ? do 
>we put all 
>>the fields to 0xffff ?
>
>I was speaking about the well known L2VPN models we are aware 
>of: i.e. individual VCs, VPWS, VPLS. Provisioned or 
>autodiscovered. I am saying that in all three of them you can 
>use nicely an AII type 2 to signal the PW building blocks, 
>without worrying whether it is a SS/MS-PW. As per my first 
>in-line note, I think it's actually a good idea to include for 
>all of them Global ID and Prefix field. The AC ID is the only 
>field that needs to be set to 0 only for non-distributed VPLS.
>
>>
>>> approach for the 32 bits field associated with AII type 1 when it 
>>> comes to BGP auto-discovery: i.e. just re-use 32 bits from the NLRI 
>>> for BGP VPLS SAFI and set the other unnecessary fields to zero...
>>>
>>> Note that AII type 2 will be required for L2VPN addressing: all the 
>>> Use Cases (e.g. MAN-WAN, Inter-provider, Scalability, private PE
>>> addressing) described in MS-PW requirements draft apply also for
>>> L2VPNs (PWs being used as infrastructure).
>>>
>>> So there won't be a clear cut between the 2 cases outlined by Luca
>>> below: there will be plenty of scenarios where 2 VSIs (VPLS)/Pools
>>> (VPWS) will need to be connected via a MS-PW.
>>>
>>>   
>>Yes , and this case is handled properly in the l2vpn-signaling draft. 
>>For VPLS the PW-Switching point PE is a BGP speaker, hence it can
>>advertise the VPLS with itself as a next hop. This will initiate the 
>>MS-PW segments correctly through the S-PE ( basically , the 
>>BGP speaker 
>>itself )
>>
>
>See my reply in the summary (for the second part)...
>
>>
>>> Moreover there will be cases where the same PE will have to connect 
>>> its VSI to remote ones using both SS and MS-PWs. How does the PE 
>>> choose when to use one AII type versus the other? Definitely that 
>>> should not happen based on whether the PW goes one hop or multiple 
>>> hops.
>>>
>>>   
>>there is no need to choose. In this case , the BGP message contains 2 
>>piece of information: "please setup a PW to myself" , and " 
>here is the
>>VSI you should connect the PW to"
>
>I understand and agree with the AD description in L2VPN 
>Signaling. But then during the Signaling step, what stops us 
>from putting "myself" info in the AII type 2 fields? 
> 
>>
>>This is very different from the MS-PW BGP message that simply 
>says "you
>>can reach this PW AC address here" .
>>
>>> Everybody will require sooner or later support for MS-PWs.
>>So I think
>>> it's a good idea to put in place early in the L2 build up, the L2 
>>> addressing that will easily accommodate the MS-PW expansion
>>instead of
>>> trying to live with 2 addressing plans: one unique per AGI 
>(AII type 
>>> 1), one globally unique (AII type 2).
>>>
>>> Focusing on one addressing format will maximize also
>>technology re-use
>>> (MS/SS-PWs transparently applicable to Individual VCs, VPWS,
>>VPLS) and
>>> will avoid interoperability issues between vendors and SPs.
>>>
>>>   
>>The reason we had an AII type field is to allow different 
>provisioning 
>>schemes ... what would be the point to have only one AII type ?
>>
>
>Yes I agree as long as it is clear that one can't do it easily 
>with existing ones.
>
>>Although I think this is fairly complicated, keeping the AII 
>type 1 as 
>>is , ( which is used in a different context ) does not 
>preclude any of 
>>the MS-PW technology from being used. On the contrary , only 
>using AII 
>>type 2 , precludes the autodiscovery methodology described in the 
>>l2vpn-signaling draft, unless most fields are set to 0
>>which gets us right back to AII type 1.
>
>I would just say here that we should spend more time 
>discussing options before reaching a conclusion.
>
>>
>>Thanks.
>>Luca
>>
>>
>>> Regards,
>>> Florin
>>>
>>>   
>>>> -----Original Message-----
>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On 
>>>> Behalf Of Mustapha Aissaoui
>>>> Sent: Friday, December 02, 2005 1:58 PM
>>>> To: 'Luca Martini'; '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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>     
>>>
>>>   
>>
>>
>
>