Subject: [mpls] Summary: mpls wg review of the draft-ietf-l2vpn-vpls-ldp-06.txt

From: Loa Andersson <[email-masked]>
Date: Fri, 22 Apr 2005 12:07:19 +0200

All,

the mpls wg review of the draft-ietf-l2vpn-vpls-ldp-06.txt
has ended.

The comments sent to the list has been scarce.

We have received a few comments off-line, and also
comments from four reviewers that we asked to review
the documents. We want to thank Bob T, Ina, Eric G and
Dimitri for their reviews. Part of their comments are
very useful as "wg chair comments" and will be sent to
ADs and authors.

Below are the major points captured, based on the
reviewer input.

Targeted LDP sessions
----------------------
One recurring theme is that a choice to use LDP to signaling
vpls de-multiplexors will lead to a full mesh of targeted
ldp session between PEs. It has been appointed out that this
will potentially cause scaling problems.

WG-chair comment: LDP was never intended to support a full mesh of 
targeted LDP sessions.

If LDP is used in this way it must clearly be stated that this is a
factor that will limit the scaling of the vpls application,
However this is nothing the changes or affects the workings of
other usages of LDP. This is local to this draft and should be
handled here.

MAC List TLV:
-------------
A second point is made that the added TLV "MAC List TLV"
is an example of using LDP for something it was not intended
for. One issue here is that the already, as compared to a routing
protocol, long LDP convergence time could be even longer. This
will have effects on both "traditional" LDP convergence and the
vpls application.

The encoding of this TLV is not clearly defined.
First the diagram of the TLV depicts MAC addresses that are
only 4 bytes long.
Second, given the historic confusion between IEEE and IETF
encodings some discussion of bit and byte order and some
pointers to documents such as RFC1042 would be in order.

WG-chair comment:
The MPLS working group is concerned about this issue.  However
we need a better understanding of the dynamics involved before
a recommendation can be made.

The text on the usage of this TLV is very difficult to parse.
Some clean-up is needed.  Further use of this TLV should be
incorporated into the examples.

Use of Generalized PWid FEC Element
-----------------------------------

Several fields are not clearly specified.

E.g. in section 4.1.1:
 >>  Control bit (C): Depending on whether, on that particular PW, the
 >>  control word is desired or not, the control bit may be specified.

simply say:

    This bit is used to signal use of the control word as specified in
    [PWE3-CTRL].

 >>  PW type: The allowed PW types in this version are Ethernet and
 >>  Ethernet VLAN.

The phrase "in this version" should be deleted.

 >>  AGI Type field

Either a value should be specified (along with a corresponding format)
or it should be stated how values are to be selected.

 >>     - Requested VLAN ID: If the PW type is Ethernet VLAN, this
 >>       parameter may be used to signal the insertion of the
 >>       appropriate VLAN ID.

This looks under specified.

 >> Section  7. Operation of a VPLS

Since FEC 128 has been moved to an appendix, this section should be
recast in terms of FEC 129.

 >> Section    8.2.2. Failure detection and recovery

The hello message only detect control plane failures and not at a
particularly fast rate.  If fast detection is needed, then
VCCV or BFD on the PSN tunnel should be employed.

MD5 and security
----------------

A third point that has been made is that the security
considerations of the LDP specification were never designed
to meet the requirements of VPLS.

WG-chair comment: This would definitely be of great concern,
but again it does not effect the LDP as a protocol but is
limited to the usage of LDP in this application.

/Loa and George

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Luca Martini <[email-masked]>
Date: Mon, 25 Apr 2005 10:53:30 -0600

Loa,

Comments in line...

.....

> Targeted LDP sessions
I would like someone to actually substantiate that there would be a 
problem with a large number of targeted LDP sessions.
It had been my experience that targeted LDP scales very easily beyond 
any number of session that would be deployed in this application.
This is NOT BGP ! Let's not just assume that because BGP with hundreds 
of thousands routes, and very complex policies , does not scale in a 
full mesh environment, LDP will have the same fate.

> MAC List TLV:

As far as i remember , this is a TLV that is going to be used to 
indicate  withdrawal of the mac addresses.
When there is a link failure LDP does not advertise new IP label 
mappings, hence the only "slow down" will be in possibly withdrawing LDP 
IP label mappings ...
And since these are targeted sessions it very likely that there will be 
no LDP ip label mappings in the first place.
Nobody should care about LDP withdrawing IP label mapping , as the IGP 
is the master , and determines the convergence time.
So what is going to be slowed down ?

> Use of Generalized PWid FEC Element
this document  should probably point to the pwe3 document and it's 
security section ...

Luca

---

From: "Marc Lasserre" <[email-masked]>
Date: Mon, 25 Apr 2005 22:09:04 +0200

Besides agreeing with Luca's comments, I'd like to add that the
VPLS-LDP draft specifies how to reduce the size of the T-LDP full
mesh through hierarchical constructs in order to prevent scalability
problems with a large number of LDP adjacencies. Existing
deployments have demonstrated that large full mesh designs have
not caused scalabilty problems.

As far as MAC withdrawal is concerned, it is only used when a
primary AC fails, specifically in the case of dual-homed MTUs. Hence,
I do not see why LDP convergence time should be impacted.

I agree with the other comments from the group which call for clarification.

Marc

----- Original Message ----- 
From: "Luca Martini" <[email-masked]>
To: "Loa Andersson" <[email-masked]>
Cc: "L2VPN" <[email-masked]>; <[email-masked]>; "Rick Wilder" 
<[email-masked]>; "Bill Fenner" <[email-masked]>; "Mark 
Townsley" <[email-masked]>; "Margaret Wasserman" 
<[email-masked]>; "Vach Kompella" <[email-masked]>
Sent: Monday, April 25, 2005 6:53 PM
Subject: [mpls] Re: Summary: mpls wg review of 
thedraft-ietf-l2vpn-vpls-ldp-06.txt

> It had been my experience that targeted LDP scales very easily beyond any 
> number of session that would be deployed in this application.
> This is NOT BGP ! Let's not just assume that because BGP with hundreds of 
> thousands routes, and very complex policies , does not scale in a full 
> mesh environment, LDP will have the same fate.
>
>
>> MAC List TLV:
>> -------------
> As far as i remember , this is a TLV that is going to be used to indicate 
> withdrawal of the mac addresses.
> When there is a link failure LDP does not advertise new IP label mappings, 
> hence the only "slow down" will be in possibly withdrawing LDP IP label 
> mappings ...
> And since these are targeted sessions it very likely that there will be no 
> LDP ip label mappings in the first place.
> Nobody should care about LDP withdrawing IP label mapping , as the IGP is 
> the master , and determines the convergence time.