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

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 3 Aug 2005 13:06:40 +0300

Yaakov and all,
In addition to the comments during the L2VPN WG session today:

I do not see why new LDP messages are required to achieve
exactly the same functionality you want toachieve.

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

Please note that the information carried in the proposed Join message does
not differ from one carried in the already defined FEC 129.

So why such a MAJOR (a new messsage, not just a new TLV!) extension
to LDP?

Regards,
                        Sasha

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 3 Aug 2005 13:16:03 +0200

Sasha, 

> IMO, sending a Label Mapping message with the appropriate FEC 
> 129 to exactly the same set of adjacencies would suffice:

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: Sasha Vainshtein <[email-masked]>
Date: Wed, 3 Aug 2005 13:24:11 +0300

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, 

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 3 Aug 2005 16:42:41 +0200

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 

> From: Sasha Vainshtein [mailto:[email-masked]] 
> Sent: Wednesday, August 03, 2005 12:24
> To: Yaakov Stein
> Cc: [email-masked] '
> 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:-)
> 
> Right now when an LDP peer receives a mapping it may 
> liberally retain it even though it has no use for it.
> 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.
> 
> 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: Sasha Vainshtein <[email-masked]>
Date: Thu, 4 Aug 2005 13:26:51 +0300

Bruce,
Lots of thanks for a prompt response.

Please see a brief comment inline below.

Regards,
                 Sasha

> From: Bruce Davie [mailto:[email-masked]]
> Sent: Thursday, August 04, 2005 11:08 AM
> To: Sasha Vainshtein
> Cc: [email-masked] '; 'Yaakov Stein '
> Subject: Re: A comment on draft-stein-ldp-auto-00.txt
> 
> 
> 
> On Aug 4, 2005, at 5:22 AM, Sasha Vainshtein wrote:
> 
> > Bruce,
> > I have looked up the draft in question.
> > IMHO t mentions the need for non-NULL SAII  and TAII wrt 
> Hierarchical 
> > VPLS
> > rather
> > than Inter-AS. Could you please be a bit more specific as to which 
> > part of
> > the draft
> > do you have in mind?
> 
> Quoting draft-ietf-l2vpn-signaling-04.txt
> 
>         3.2.3   Signaling
> 
>     It is necessary to create Attachment Identifiers which 
> identify the
>     VSIs.  In the preceding section, a VSI-ID was encoded as 
> RD:PE_addr
>     for the purposes of autodiscovery.  For signaling 
> purposes, the same
>     information is carried but is encoded slightly 
> differently.  Noting
>     that the RD is effectively a VPN identifier, we therefore 
> encode the
>     RD in the AGI field, and place the PE_addr in the TAII field.  The
>     SAII can be null.
> 
>   The motivation for this is to enable the inter-AS (not dist. VPLS) 
> procedures that are described in Section 4.2 to work 
> correctly. If you 
> didn't include some sort of PE identifier in the TAII, you 
> would not be 
> able to figure out what to do at an SPE (ASBRs in this case)
> 
> But as your comments below correctly point out, this isn't all that 
> relevant to the original thread. I just wanted to address 
> your question 
> about why non-null AIIs might be needed, and to point out 
> that the base 
> VPLS-LDP draft isn't the last word on that subject.
> 
> It certainly would be good if any attempt to define new autodiscovery 
> methods (e.g. using LDP) drew on the overall approach to 
> autodiscovery 
> and signalling that has been developed over several years and 
> documented in draft-ietf-l2vpn-signaling-xx.txt.
>
[Sasha] I agree wholeheartedly. 
>
> Bruce
> 
> 
> 
> >
> > And, regardless of that, this thread was, IMO, essentially 
> about two 
> > points:
> >
> > - FEC 129 contains ALL the information that would be carried  in the
> > proposed Join/Leave
> >   messages since the AGI is ALWAYS equivalent to the VPLS 
> identifeir. 
> > IMO
> > your comments
> >   indicates that it could contain some additional 
> information as well, 
> > but I
> > do not see
> >   why this could be a problem
> >
> > - There is a regular, well defined procedure in the PWE3 Control 
> > Protocol
> > draft that
> >   requires the receiver of a Label Mapping message for a 
> FEC 129 with
> > unknown/unrecognized
> >   TAI to release the label binding advertized for this FEC. And, to 
> > the best
> > of my
> >   understanding, explicitly released label bindings MUST NOT be 
> > retained
> > even in the
> >   Liberal retention mode. (I would highly appreciate 
> comments by the 
> > LDP
> > gurus on this
> >   specific point.)
> >
> > Regards,
> >                      Sasha
> >
> >
> >> From: Bruce Davie [mailto:[email-masked]]
> >> Sent: Thursday, August 04, 2005 9:25 AM
> >> To: Sasha Vainshtein
> >> Cc: [email-masked] '; 'Yaakov Stein '
> >> Subject: Re: A comment on draft-stein-ldp-auto-00.txt
> >>
> >>
> >> 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
> >>
> >> On Aug 3, 2005, at 9:53 AM, Sasha Vainshtein wrote:
> >>
> >>> 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
> >>> Sent: 8/3/2005 4:42 PM