The MPLS WG Archive

[Loa Andersson <loa@pi.se>]

Marc,

inline please.

Marc Lasserre wrote:

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

Luca suggested that we try to substantiate this concern, I've
suggested that we try to do so through some testing site. I would
be open to discuss options.

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

Re-reading the draft actually made me even more confused.
Do you say that the MAC TLV is used only in one message? If so
this should clearly be stated in the draft, if not we would need a
list of the message in which the MAC TLV could appear.

The message the you explictly say that the MAC TLV could go
into is "MAC Address Withdraw Message".

I would also prefer if we used the LDP terminology consistently,
adding a new TLV won't change the name of an LDP message, I assume
that a a "MAC Address Withdraw Message" is just an "Address Withdraw
Message"?

It is also said that:

"  The LDP Address Withdraw Message contains a FEC TLV (to identify the
    VPLS in consideration), a MAC Address TLV and optional parameters.
    No optional parameters have been defined for the MAC Address
    Withdraw signaling. "

To be precise the LDP Address Withdraw Message base specification
don't contain the FEC TLV, and I actually can't find where it
has been specified as an optional TLV for the Address Withdraw Message.


After re-reading the draft once more, and refering to the base LDP
specification it is my impression that a major rework of the draft
would be in place to align with the  LDP concepts, terminology and
style.

/Loa


> 
> I agree with the other comments from the group which call for 
> clarification.
> 
> Marc
> 
> ----- Original Message ----- From: "Luca Martini" <lmartini@cisco.com>
> To: "Loa Andersson" <loa@pi.se>
> Cc: "L2VPN" <l2vpn@ietf.org>; <mpls@ietf.org>; "Rick Wilder" 
> <rick.wilder@alcatel.com>; "Bill Fenner" <fenner@research.att.com>; 
> "Mark Townsley" <townsley@cisco.com>; "Margaret Wasserman" 
> <margaret@thingmagic.com>; "Vach Kompella" <vach.kompella@alcatel.com>
> Sent: Monday, April 25, 2005 6:53 PM
> Subject: [mpls] Re: Summary: mpls wg review of 
> thedraft-ietf-l2vpn-vpls-ldp-06.txt
> 
> 
>> 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
>>
>>
> 
> 
> 
> 


-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson@acreo.se
                                            loa@pi.se

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