The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] Re: Summary: mpls wg review ofthedraft-ietf-l2vpn-vpls-ldp-06.txt
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" <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 > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|