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

["Florin Balus" <[e-mail]>]

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:[e-mail]]
>Sent: Monday, December 05, 2005 12:26 PM
>To: Balus, Florin [CAR:6955:EXCH]
>Cc: Mustapha Aissaoui; L2VPN; David McDysan; [e-mail]
>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: [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
>>>
>>>
>>>
>>>
>>>
>>>
>>>     
>>
>>   
>
>