Subject: RE: A comment on draft-stein-ldp-auto-00.txt

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 3 Aug 2005 16:53:58 +0300

Yaakov,
I follow the assumptions in draft-ietf-l2vpn-vpls-ldp-07.txt, section
6.1.1 that says that AGI is the VPLS identifier, while SAII and TAII are
NULL (and explains whyit is so).

I am not aware of any alternative proposals. 
Did I miss one in your draft?

Regards,
                      Sasha
-----Original Message-----
From: Yaakov Stein
To: Sasha Vainshtein
Cc: [email-masked]
Sent: 8/3/2005 4:42 PM
Subject: RE: A comment on draft-stein-ldp-auto-00.txt

Sasha, 

What exactly are you assuming as the connection
between the VPLS identity and the TAIs for the
various MS PWs that need to be set up for each 
PE in the VPLS instance ?

Y(J)S 

> -----Original Message-----
> From: Sasha Vainshtein [mailto:[email-masked]] 
> Sent: Wednesday, August 03, 2005 12:24
> To: Yaakov Stein
> Cc: [email-masked] '
> Subject: RE: A comment on draft-stein-ldp-auto-00.txt
> 
> Yaakoc,
> I do not think that you are right there.
> 
> The procedure (as listed in Section 5.3.3) mandates the 
> receiver of a FEC 129 with unknown TAI to release the label.
> 
> I do not think that the LDP liberal retention mode includes 
> ability to retain a label binding that has been explicitly 
> released. Such behavior does not much sense to me, since the 
> entity that has advertised the binding can now re-use a 
> released label making the retained original binding somewhat 
> meaningless and possibly harmful. 
> 
> 
> (This does not preclude the fact that some broken LDP 
> implementations do exactly that:-)
> 
> Do I miss something here?
> 
> Regards,
>                    Sasha
> 
> 
> -----Original Message-----
> From: Yaakov Stein
> To: Sasha Vainshtein
> Cc: [email-masked]
> Sent: 8/3/2005 1:16 PM
> Subject: RE: A comment on draft-stein-ldp-auto-00.txt
> 
> Sasha, 
> 
> > IMO, sending a Label Mapping message with the appropriate FEC
> > 129 to exactly the same set of adjacencies would suffice:
> > - adjacencies that participate in the VPLS intstance defined by this
> >   FEC would respond with their own Label Mapping message back
> > - adjacencies that do NOT participate in the VPLS instance defined
> >   by this FEC would respond with the Label Release message using
> >   the LDP Status Code "Unassigned/Unrecognized TAI" as defined
> >   in Section 5.3.3 of the current PWE3 control protocol draft
> >   (draft-ietf-pwe3-control-protocol-17.txt).
> 
> Yes, this is one of the alternatives we considered.
> 
> Although it re-uses a TLV, it requires a procedure change, 
> which I am not sure is better. 
> 
> Right now when an LDP peer receives a mapping it may 
> liberally retain it even though it has no use for it.
> There certainly is no procedure for conditioning acceptance 
> on information maintained in a table.
> 
> In addition, in the naive way of doing this it would require 
> propagation of the label mapping into whole domains where I 
> don't (access networks where there are no PEs belonging to 
> the VPLS instance). Yes this could also be fixed by having 
> the S-PE snoop the mapping message, but then it would have to 
> process every LDP packet (even non-VPLS joining ones) in this 
> fashion. 
> 
> Finally, PEs that are not VPLS-aware will mis-handle the 
> mapping request. In our case PEs that do not handle VPLS will 
> silently ignore the message.
> 
> > 
> > Please note that the information carried in the proposed 
> Join message 
> > does not differ from one carried in the already defined FEC 129.
> 
> Yes, this is discussed in the draft.
> 
> > 
> > So why such a MAJOR (a new messsage, not just a new TLV!) 
> extension to 
> > LDP?
> 
> I do not see a major advantage in saving IANA a little bit of 
>  work in allocating two new TLVs, if we have to overload a 
> lot of logic on existing ones.
> 
> Y(J)S
> 
>

---

From: Bruce Davie <[email-masked]>
Date: Thu, 4 Aug 2005 06:12:56 -0400

Sasha,
  You may want to look at draft-ietf-l2vpn-signaling-04.txt which 
explains why non-null SAII and TAII values are needed when building 
inter-AS PWs between the VSIs.

Bruce

---

From: Bruce Davie <[email-masked]>
Date: Thu, 4 Aug 2005 04:25:10 -0400

Sasha,

Bruce