The MPLS WG Archive

[Luca Martini <lmartini@cisco.com>]

Loa,

Comments in line...

.....

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

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 ?

> 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.
>
this document  should probably point to the pwe3 document and it's 
security section ...

Luca

>
> /Loa and George
>

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls