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

[Luca Martini <[e-mail]>]

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.
What happens when a new provisioning model comes along ? do we put all 
the fields to 0xffff ?

> 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 )


> 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"

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 ?

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.

Thanks.
Luca


> Regards,
> Florin 
>
>   
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> On Behalf Of Mustapha Aissaoui
>> Sent: Friday, December 02, 2005 1:58 PM
>> To: 'Luca Martini'; 'L2VPN'
>> Cc: 'David McDysan'; [e-mail]
>> 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: [e-mail] [mailto:[e-mail]]
>> On Behalf Of Luca Martini
>> Sent: Friday, December 02, 2005 1:09 PM
>> To: L2VPN
>> Cc: David McDysan; [e-mail]
>> 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
>>
>>
>>
>>
>>
>>
>>     
>
>