The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] Requesting your feedback - issues/errors/clarification s
> Please see my comments below: > > > + I agree with Luca. I have not seen much use for loop detection in > DU mode of operation. So, it would be nice to either clarify its use. > > + I also agree with removal of the HOST FECs. Although they are > + supported > by the protocol, I have not seen them being advertised. > > + I agree that the selection of FECs for which LDP sends label mapping > + message > should not be a requirements of the protocol spec. The FECs should be > either > determined by the applications as Ina mentioned, or controlled via > policies. > > + As for the use of DU in conjunction with independent control mode of > + operation, > I agree with Vach that DU and IC can result in black holes or packet > misrouting How does it result in "misrouting"? > in the network. The scheme works fine for IP forwarding, but as Vach > pointed out > in his e-mail, it creates issues in VPN networks. It seems to me that the appropriate place to address this issue is in the protocol applicability document (i.e., rfc3037 as opposed to rfc3036). Bob > Arashmid > > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com <mailto:lmartini@cisco.com> ] > Sent: Thursday, August 26, 2004 5:19 PM > To: Ina Minei > Cc: mpls@ietf.org; vach.kompella@alcatel.com > Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications > > > Ina, > > Please note the following points: > > - the LDP loop detection mechanisms do not make much sense in DU mode. > This is the hop count TLV, and the Path Vector TLV. ( When LDP > interoperability testing was just starting , I had most vendors out > there remove it for DU mode ). We should add something explicitly that > says that these TLVs should not be used in DU mode. ( This is the > current practice in all implementations that I know of ) > > - The Host FEC is accepted by most implementations I worked with , but > sent by none. So I also think it's probably a good idea to remove it. > > Luca > > > > Ina Minei wrote: > > >>>Issue: do we really have to send all FECs in our database whenever we > >>>have an LDP session between two peers? > >>> > >>> > >>This should not be a requirement of the protocol spec, the application > >>which is using the protocol should determine which FECS get sent. > >> > >> > > > > I agree. This is not a specification issue, but rather a > best-practice > >based on the application for which the protocol is used. If you only > >need the loopbacks as FECs for your application, then it is best if you > >_ask_ LDP to only redistribute the loopbacks, because it will make your > >network easier to troubleshoot. > > > > Ina > > > > > > > > > >>>Issue: with all the combinations of Downstream Unsolicited, > >>>Downstream on Demand, Ordered Control, Independent Control, etc., it > >>>makes sense to define a mandatory combination. DU/OC seems to be the > >>>favored one. > >>> > >>> > >>I believe this would put a majority of the deployed LDP speakers > >>out of spec. Such a change cannot be made as part of going to DS. > >> > >> > >> > > > >_______________________________________________ > >mpls mailing list > >mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls > <https://www1.ietf.org/mailman/listinfo/mpls> > > > > > > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > <https://www1.ietf.org/mailman/listinfo/mpls> > > > > ------_=_NextPart_001_01C48EAA.0073F34F > Content-Type: text/html > Content-Transfer-Encoding: quoted-printable > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> > <HTML> > <HEAD> > <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = > charset=3Dus-ascii"> > <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = > 5.5.2656.31"> > <TITLE>RE: [mpls] Requesting your feedback - = > issues/errors/clarifications</TITLE> > </HEAD> > <BODY> > <BR> > > <P><FONT SIZE=3D2 FACE=3D"Courier New">Please see my comments = > below:</FONT> > </P> > <BR> > > <P><FONT SIZE=3D2 FACE=3D"Courier New">+ I agree with Luca. I have not = > seen much use for loop detection in</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New"> DU mode of operation. = > So, it would be nice to either clarify its use.</FONT> > </P> > > <P><FONT SIZE=3D2 FACE=3D"Courier New">+ I also agree with removal of = > the HOST FECs. Although they are </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">+ supported</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New"> by the protocol, I have = > not seen them being advertised.</FONT> > </P> > > <P><FONT SIZE=3D2 FACE=3D"Courier New">+ I agree that the selection of = > FECs for which LDP sends label mapping </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">+ message</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New"> should not be a = > requirements of the protocol spec. The FECs should be either</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New"> determined by the = > applications as Ina mentioned, or controlled via policies.</FONT> > </P> > > <P><FONT SIZE=3D2 FACE=3D"Courier New">+ As for the use of DU in = > conjunction with independent control mode of </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">+ operation,</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New"> I agree with Vach that = > DU and IC can result in black holes or packet misrouting</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New"> in the network. The = > scheme works fine for IP forwarding, but as Vach pointed out</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New"> in his e-mail, it = > creates issues in VPN networks.</FONT> > </P> > <BR> > > <P><FONT SIZE=3D2 FACE=3D"Courier New">Arashmid</FONT> > </P> > > <P><FONT SIZE=3D2 FACE=3D"Courier New">-----Original = > Message-----</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">From: Luca Martini [</FONT><A = > HREF=3D"mailto:lmartini@cisco.com"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 = > FACE=3D"Courier New">mailto:lmartini@cisco.com</FONT></U></A><FONT = > SIZE=3D2 FACE=3D"Courier New">] </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">Sent: Thursday, August 26, 2004 = > 5:19 PM</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">To: Ina Minei</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">Cc: mpls@ietf.org; = > vach.kompella@alcatel.com</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">Subject: Re: [mpls] Requesting = > your feedback - issues/errors/clarifications</FONT> > </P> > <BR> > > <P><FONT SIZE=3D2 FACE=3D"Courier New">Ina,</FONT> > </P> > > <P><FONT SIZE=3D2 FACE=3D"Courier New">Please note the following = > points:</FONT> > </P> > > <P><FONT SIZE=3D2 FACE=3D"Courier New">- the LDP loop detection = > mechanisms do not make much sense in DU mode. </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">This is the hop count = > TLV, and the Path Vector TLV. ( When LDP </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">interoperability testing was = > just starting , I had most vendors out </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">there remove it for DU mode ). = > We should add something explicitly that </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">says that these TLVs should not = > be used in DU mode. ( This is the </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">current practice in all = > implementations that I know of )</FONT> > </P> > > <P><FONT SIZE=3D2 FACE=3D"Courier New">- The Host FEC is accepted by = > most implementations I worked with , but </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">sent by none. So I also think = > it's probably a good idea to remove it.</FONT> > </P> > > <P><FONT SIZE=3D2 FACE=3D"Courier New">Luca</FONT> > </P> > <BR> > <BR> > > <P><FONT SIZE=3D2 FACE=3D"Courier New">Ina Minei wrote:</FONT> > </P> > > <P><FONT SIZE=3D2 FACE=3D"Courier New">>>>Issue: do we really = > have to send all FECs in our database whenever we</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>>>have an LDP session = > between two peers?</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier = > New">>>> </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>>></FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>>This should not be a = > requirement of the protocol spec, the application</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>>which is using the = > protocol should determine which FECS get sent.</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>> = > </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>></FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">></FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier = > New">> I agree. This is not a = > specification issue, but rather a best-practice</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>based on the application = > for which the protocol is used. If you only </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>need the loopbacks as FECs = > for your application, then it is best if you </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>_ask_ LDP to only = > redistribute the loopbacks, because it will make your </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>network easier to = > troubleshoot.</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">></FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier = > New">> = > = > = > Ina</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">></FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">></FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">> </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">></FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>>>Issue: with all the = > combinations of Downstream Unsolicited,</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>>>Downstream on = > Demand, Ordered Control, Independent Control, etc., it </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>>>makes sense to = > define a mandatory combination. DU/OC seems to be the </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>>>favored one.</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier = > New">>>> </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>>></FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>>I believe this = > would put a majority of the deployed LDP = > speakers</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>>out of spec. Such = > a change cannot be made as part of going to DS.</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>></FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>> = > </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>></FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">></FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier = > New">>_______________________________________________</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>mpls mailing list</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">>mpls@lists.ietf.org = > </FONT><A HREF=3D"https://www1.ietf.org/mailman/listinfo/mpls"><U><FONT = > COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier = > New">https://www1.ietf.org/mailman/listinfo/mpls</FONT></U></A> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">></FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">> </FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">></FONT> > </P> > <BR> > > <P><FONT SIZE=3D2 FACE=3D"Courier = > New">_______________________________________________</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">mpls mailing list</FONT> > <BR><FONT SIZE=3D2 FACE=3D"Courier New">mpls@lists.ietf.org</FONT> > <BR><A HREF=3D"https://www1.ietf.org/mailman/listinfo/mpls"><U><FONT = > COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier = > New">https://www1.ietf.org/mailman/listinfo/mpls</FONT></U></A> > </P> > <BR> > > </BODY> > </HTML> > ------_=_NextPart_001_01C48EAA.0073F34F-- > > > --===============0921775444== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > --===============0921775444==-- > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|