Subject: 2 different signaling procedures for vpls-ldp

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Tue, 21 Mar 2006 12:44:02 -0500

As I am reading through the recent version of
draft-ietf-l2vpn-signaling-07 and contrasting it to
draft-ietf-l2vpn-vpls-ldp-08.txt, I find out that there is
an issue that need some clarification with respect to signaling 
procedures for VPLS using LDP protocol. 

I noticed we have in fact two different signaling procedures 
for vpls-ldp that do exactly the same thing and 
are not inline and cannot interoperate.

In draft draft-ietf-l2vpn-vpls-ldp-08.txt section 6.1.1
("Using the Generalized PWid FEC Element", part of section 6.1 
Signaling for LDP...), it says:

"TAII, SAII: These are null because the mesh of PWs in a VPLS 
 terminate on MAC learning tables, rather than on individual 
 attachment circuits.  The use of non-null TAII and SAII is reserved 
 for future enhancements."

But draft draft-ietf-l2vpn-signaling-07 says in the
"signalling" section 3.2.3 (part of section 3.2 VPLS):

"The SAII MUST be set to the PE_addr of the sending PE (or, more
generally, 
 the VSI-ID, without the RD, of the VSI associated with this VPLS in the
 sending PE), to enable signaling of the reverse half of the PW if
 needed.

   The structure of the AGI and AII fields for the Generalized ID FEC in
   LDP is defined in [I-D.ietf-pwe3-control-protocol].  The AGI field in
   this case consists of a Type of 1, a length field of value 8, and the
   8 bytes of the RD.  The TAII consists of a Type of 1, a length field
   of value 4, followed by the 4-byte PE address (or other 4-byte
   identifier)."

These two signaling procedures are non interoperable in their way
of handling the SAII, TAII. A PE (that is signaling compliant
to draft draft-ietf-l2vpn-signaling-07) talking to a PE
that is only signaling compliant to draft-ietf-l2vpn-vpls-ldp-08.txt 
will not be able to establish a pseudowire to it.

If one wants to implement VPLS using ldp which draft should 
she/he pick for signaling purposes? or to be more precise which 
signaling procedures are the minimum required for standard purposes? 

Note that both are doing exactly the same thing establish 
pseudowires between VSIs. This needs clarification.

Hamid.

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Tue, 21 Mar 2006 19:41:17 -0500

Bruce,

> 
>   The vpls-ldp does not *intentionally* preclude autodiscovery.  
> However, because autodiscovery (and its impact on signaling) had not  
> been fully specified at the time of the WG last call for vpls-ldp,  
> the signaling procedures there are incomplete for the purposes of  
> autodiscovery. Specifically they don't convey enough information to  
> work in an inter-AS environment with autodiscovery and multisegment  
> PWs.  

In fact ideally l2vpn-signaling draft is in
fact obsoleting the signaling procedures of vpls-ldp with
respect to the use of FEC129.

>The key words in vpls-ldp are:
> 
> " The use of non-null TAII and SAII is reserved
> Autodiscovery turns out to be a future enhancement relative to the  
> vpls-ldp spec.
> 

The above statement is too vague. If that is the case then somewhere 
this needs to be captured (or section 5 updated and the signaling 
section removed?). 

>   Since the signaling procedures defined in draft-ietf-l2vpn- 
> signaling work with or without autodiscovery, one might choose to  
> implement only those procedures.
> 
>   It is worth noting that a device knows whether or not it is doing  
> autodiscovery, so it could choose to use the signaling messages of  
> vpls-ldp when it does not do autodiscovery and the messages of l2vpn- 
> signaling when it is doing autodiscovery. 

The problem may arise if some PEs are using one form of signaling
while other PEs (or other provider network) are using the signaling 
draft form. Even if the device can do auto-discovery, the remote device
(which doesn't participate in the discovery) may send to this device a 
label mapping formatted using vpls-ldp procedures.
What should the receiving device do in this case? Use null SAII, TAII
for some PE and VSI-IDs for others for the same VPLS? In that case there

will be a need to specify the interworking rules between the two schemes
(lack of better term). This is assuming that some provider may take 
them more time to switch to l2vpn-signaling model...

> I agree that this is not  
> ideal. But I don't think it causes fundamental breakage either.
> 

It may not as long as it is clear and documented. Right now it doesn't 
seem so just from the texts we have!

Hamid.

> 
> Bruce
> 
> On Mar 21, 2006, at 3:10 PM, Hamid Ould-Brahim wrote:
> 
> > Bruce,
> >
> >>
> >> I pointed out this problem to the authors of 
> draft-ietf-l2vpn-vpls- 
> >> ldp  a little more than 12 months ago. They were reluctant 
> to change 
> >> a draft that had already passed WG last call.
> >>
> >> I think the answer is that if you want to do 
> autodiscovery, they you 
> >> should do what is specified in draft-ietf-l2vpn-signaling. If you 
> >> don't care about autodiscovery, then the procedures 
> draft-ietf-l2vpn- 
> >> vpls-ldp will work.
> >
> > But that's not what draft-ietf-l2vpn-vpls-ldp is saying
> > (and also is not what draft-ietf-l2vpn-signaling is saying). The 
> > vpls-ldp draft does not preclude the use of an auto-discovery 
> > mechanism referring to the BGP and Radius drafts (with no reference 
> > and dependency on draft-ietf-l2vpn-signaling from discovery 
> point of 
> > view (according to section 5)).
> >
> > While what you are saying is
> >
> > a) if one needs to implement a *BGP* auto-discovery for VPLS then
> >    it MUST use the signaling procedures described in
> >    draft-ietf-l2vpn-signaling (BTW it wasn't clear to me
> >    that to use draft-ietf-l2vpn-signaling-07 then one MUST deploy
> >    bgp auto-discovery mechanism). While the vpls-ldp draft is saying
> >    that the signaling procedures described in vpls-ldp draft
> >    work whether you use an auto-discovery mechanism or not.
> >
> > b) if one wants to use the signaling procedures described in
> >    draft-l2vpn-signaling-07 then it MUST implement and use
> >    a BGP auto-discovery mechanism. While the requirement draft seems
> >    implying that an auto-discovery mechanism is optional for
> >    l2vpn not a MUST have mechanism.
> >
> > This implies that if one wants to deploy first VPLS
> > solution without an auto-discovery mechanism then
> > it needs to use the signaling procedures described in 
> vpls-ldp draft. 
> > But if later on, this provider wants to deploy a BGP auto-discovery 
> > (for scalability reasons) then this provider MUST change all its 
> > signaling scheme including provisioning deployed using 
> vpls-ldp draft. 
> > This doesn't seem right.
> >
> > Looks like there is no other option then to have one signaling 
> > standard procedures for VPLS using LDP (for SAII, TAII, 
> etc) not two 
> > different ones.
> >
> > Hamid.
> >
> >
> >> As a practical matter, I think that all
> >> implementations of draft-ietf-l2vpn-vpls-ldp today are 
> using FEC 128,
> >> not 129. I would expect that as vendors start to implement
> >> autodiscovery, they will have to implement FEC 129 (it's the only
> >> thing specified in draft-ietf-l2vpn-signaling) and fill in the SAII
> >> and TAII fields as specified in draft-ietf-l2vpn-signaling.
> >>
> >> Bruce
> >>
> >> On Mar 21, 2006, at 12:36 PM, Hamid Ould-Brahim wrote:
> >>
> >>>
> >>>> I noticed we have in fact two different signaling procedures for 
> >>>> vpls-ldp that do exactly the same thing and are not inline
> >> and cannot
> >>>> interoperate.
> >>>>
> >> ("Using the
> >>>> Generalized PWid FEC Element", part of section 6.1 Signaling for 
> >>>> LDP...), it says:
> >>>>
> >>>> But draft draft-ietf-l2vpn-signaling-07 says in the "signalling" 
> >>>> section 3.2.3 (part of section 3.2 VPLS):
> >>>>
> >>>> generally,  the VSI-ID, without the RD, of the VSI 
> associated with 
> >>>> this VPLS in the  sending PE), to enable signaling of 
> the reverse 
> >>>> half of the PW if  needed.
> >>>>
> >>>>    The structure of the AGI and AII fields for the
> >> Generalized ID FEC
> >>>> in
> >>>>    LDP is defined in [I-D.ietf-pwe3-control-protocol].
> >> The AGI field
> >>>> in
> >>>>    this case consists of a Type of 1, a length field of
> >> value 8, and
> >>>> the
> >>>>    8 bytes of the RD.  The TAII consists of a Type of 1, 
> a length 
> >>>> field
> >>> These two signaling procedures are non interoperable in
> >> their way of
> >>> handling the SAII, TAII. A PE (that is signaling 
> compliant to draft
> >>> draft-ietf-l2vpn-signaling-07) talking to a PE that is only
> >> signaling
> >>> compliant to draft-ietf-l2vpn-vpls-ldp-08.txt will not be able to 
> >>> establish a pseudowire to it.
> >>>
> >>> If one wants to implement VPLS using ldp which draft 
> should she/he 
> >>> pick for signaling purposes? or to be more precise which 
> signaling 
> >>> procedures are the minimum required for standard purposes?
> >>>