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

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:
> - 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