The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [MPLS]New comments and ideas for <draft-ietf-mpls-ldp-p2mp-02>
Thank you for the comments. The new revision of the draft will reflect this discussion. Ina On Mon, 19 Mar 2007 jin.lizhong@zte.com.cn wrote: > Hi Ina: > > Thank you for your reply and comments. > > You are right, LDP error notification can handle the unknow TLV for LDP > P2MP TLV. > > When not using capability TLV > 1. If we use error notification to handle it, and when LSR receives the > error notification with unknow tlv, then it does not send the mLDP mapping > message. It is not explicitly expressing the error. I don't think its a > nice processing for mLDP. > > When using capability TLV > 1. If we don't use the above mechanism, and if the LSR don't know its > neighbor does not support mLDP capability, it will continue sending mLDP > mapping message to its neighbor, and many error notification messages will > be continuely received for each P2MP LSP. If we use mLDP capability > negotiation, then LSR will not send mLDP mapping message to its neighbor, > and save many processings of LDP protocol messages. > > 2. For mLDP is very new, when deploying, there must be some LSRs that not > supporting mLDP. Using mLDP capability TLV, it can be very easy to see > what's wrong with this P2MP LSP, and can easily avoid P2MP LSP partially > being set up. > > 3. If we use mLDP capability TLV, then mLDP can be very clearly co-existed > with many other LDP capabilities, such as upstream label assigning > capability. And the virtue of LDP capability TLV also has been described > in [draft-thomas-mpls-ldp-capabilities-02]. > > Thanks you very much. > > > Best Regards > Jin Lizhong > > > .............................................. > ZTE Corporation > Add: No.68 Zijinghua Rd,Yuhuatai District, > Nanjing. P.R.China. > Zip: 210012 > Mail: jin.lizhong@zte.com.cn > .............................................. > > > > > Ina Minei <ina@juniper.net> > 2007-03-14 23:20 > > To: jin.lizhong@zte.com.cn > cc: LE ROUX Jean-Louis RD-CORE-LAN > <jeanlouis.leroux@orange-ftgroup.com>, shane.amante@level3.com, > lufang@cisco.com, hitoshi.fukuda@ntt.com, "zzx-Huji KAMITE > y.kamite@nttt.com" <y.kamite@ntt.com>, kireeti@juniper.net, > rhthomas@cisco.com, lei.wang@telenor.com, ice@cisco.com, > mpls@lists.ietf.org > Subject: RE: [MPLS]New comments and ideas for > <draft-ietf-mpls-ldp-p2mp-02> > > > > Jin, > > What would the capability accomplish? If it is a way to > enable > error notification, then this is already available in LDP today. Is there > any other functionality that would be accomplished by turning on the > capability advertisement? > > Ina > > On Wed, 14 Mar 2007 jin.lizhong@zte.com.cn wrote: > >> Hi JL >> >> Thank you very much for your comments. >> >> Does any other guys think P2MP capability TVL is necessary? >> >> Best Regards >> Jin Lizhong >> >> .............................................. >> Add: No.68 Zijinghua Rd,Yuhuatai District, >> Nanjing. P.R.China. >> Zip: 210012 >> Tel: 0086-13912967531 >> Mail: jin.lizhong@zte.com.cn >> .............................................. >> >> >> >> >> "LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@orange-ftgroup.com> >> 2007-03-08 18:16 >> >> To: <jin.lizhong@zte.com.cn>, <shane.amante@level3.com>, >> <lufang@cisco.com>, <hitoshi.fukuda@ntt.com>, "zzx-Huji KAMITE >> y.kamite@nttt.com" <y.kamite@ntt.com>, <kireeti@juniper.net>, >> <ina@juniper.net>, <rhthomas@cisco.com>, <lei.wang@telenor.com>, >> <ice@cisco.com>, <mpls@lists.ietf.org> >> cc: >> Subject: RE: New comments and ideas for >> <draft-ietf-mpls-ldp-p2mp-02> >> >> >> Hi Jin, >> >> Procedures to advertise the P2MP capability should rely on encoding > rules >> and procedures defined in draft-thomas-mpls-ldp-capabilities-02.txt. >> This simply requires defining a new capability parameter, the P2MP >> capability, and requesting for a TLV code point. >> Also note that v01 of draft-ietf-mpls-ldp-upstream (submitted last > monday) >> is now aligned with draft-thomas. >> >>> Second, in section 7.1.Protocol event, line 11, I think the word > 'LSR-D' >> should be 'LSR-U', it is misunderstanding in both the version 1 and 2 >> . >> Actually this applies indifferently to LSR D and LSR U. >> >> Kind Regards, >> >> JL >> >> De : jin.lizhong@zte.com.cn [mailto:jin.lizhong@zte.com.cn] >> Envoyé : jeudi 8 mars 2007 10:28 >> À : shane.amante@level3.com; lufang@cisco.com; > zzx-hitoshi.fukuda@ntt.com; >> zzx-Huji KAMITE y.kamite@nttt.com; kireeti@juniper.net; ina@juniper.net; >> LE ROUX Jean-Louis RD-CORE-LAN; rhthomas@cisco.com; > lei.wang@telenor.com; >> ice@cisco.com; mpls@lists.ietf.org >> Objet : New comments and ideas for <draft-ietf-mpls-ldp-p2mp-02> >> >> >> Dear all: >> >> I read the draft <draft-ietf-mpls-ldp-p2mp-02>, and have some comments >> below. Thank you. >> >> First, it is very necessary to use the mLDP capability TLV to signal the >> capability of LDP Session. Just like the capability described in >> <draft-ietf-mpls-ldp-upstream-00>, using the capability TLV, it is quite >> convenient to the trouble shooting. Without the capability TLV, if the >> P2MP LSP does not set up successfully, one has to check the upstream > LSR; >> and if the upstream LSR does not show any information of P2MP LSP and > FEC, >> we can not figure whether the mapping message sent by the downstream LSR >> is silently discarded by upstream LSR or lost during the transmission. >> >> Because the mLDP is very new, and many equipments that have been > deployed >> in the network do not support mLDP, then the scenario described above > will >> always happen when deploying. And this is only one of the scenarios for >> capability TLV; it will be more useful and convenient for deploying > mLDP. >> >> Following is the format of the mLDP Capability TLV, much like defined in >> <draft-ietf-mpls-ldp-upstream-00>: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |1|0| Capability TLV (TBD) | Length (= 4) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sub-TLVs... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Following is the format of the mLDP Capability sub-TLV: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | mLDP Cap = 1 | Length (= 4) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> If a LSR includes the mLDP Capability sub-TLV in LDP Initialization >> Messages it implies that the LSR is capable of processing both >> distributing P2MP FEC Element and MP2MP FEC Element. Reserved bits MUST > be >> set to zero on transmission and MUST be ignored on receipt. >> >> Second, in section 7.1.Protocol event, line 11, I think the word 'LSR-D' >> should be 'LSR-U', it is misunderstanding in both the version 1 and 2. >> >> Hope for your comments, thank you very much. >> >> Best Regards >> Jin Lizhong >> >> .............................................. >> Add: No.68 Zijinghua Rd,Yuhuatai District, >> Nanjing. P.R.China. >> Zip: 210012 >> Tel: 0086-13912967531 >> Mail: jin.lizhong@zte.com.cn >> .............................................. >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail > is >> solely property of the sender's organization. This mail communication is >> confidential. Recipients named above are obligated to maintain secrecy > and >> are not permitted to disclose the contents of this communication to >> others. >> This email and any files transmitted with it are confidential and > intended >> solely for the use of the individual or entity to whom they are > addressed. >> If you have received this email in error please notify the originator of >> the message. Any views expressed in this message are those of the >> individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam >> system. >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail > is >> solely property of the sender's organization. This mail communication is >> confidential. Recipients named above are obligated to maintain secrecy > and >> are not permitted to disclose the contents of this communication to >> others. >> This email and any files transmitted with it are confidential and > intended >> solely for the use of the individual or entity to whom they are > addressed. >> If you have received this email in error please notify the originator of >> the message. Any views expressed in this message are those of the >> individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam >> system. >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail > is solely property of the sender's organization. This mail communication > is confidential. Recipients named above are obligated to maintain secrecy > and are not permitted to disclose the contents of this communication to > others. >> This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you have received this email in error please notify the > originator of the message. Any views expressed in this message are those > of the individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. >> > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy and > are not permitted to disclose the contents of this communication to > others. > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the originator of > the message. Any views expressed in this message are those of the > individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|