Subject: RE: 2 different signaling procedures for vpls-ldp

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

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:
> 
> >
> >> 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: Bruce Davie <[email-masked]>
Date: Tue, 21 Mar 2006 16:48:45 -0500

Hamid,

  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.  The key words in vpls-ldp are:

" The use of non-null TAII and SAII is reserved
   for future enhancements."

Autodiscovery turns out to be a future enhancement relative to the  
vpls-ldp spec.

  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. I agree that this is not  
ideal. But I don't think it causes fundamental breakage either.

Bruce