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

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 4 Aug 2005 12:22:50 +0300

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?

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

> -----Original Message-----
> 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
> > -----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:35 -0400

> than Inter-AS. Could you please be a bit more specific as to which 

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.

Bruce

---

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

3.2.3   Signaling

Bruce