Subject: RE: [mpls] Requesting your feedback - issues/errors/clarification s

From: "Arashmid Akhavain" <[email-masked]>
Date: Mon, 30 Aug 2004 11:57:07 -0400

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

Arashmid

-----Original Message-----
From: Luca Martini [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, August 26, 2004 5:19 PM
To: Ina Minei
Cc: [email-masked]; [email-masked]
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
>[email-masked] https://www1.ietf.org/mailman/listinfo/mpls
<https://www1.ietf.org/mailman/listinfo/mpls> 

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls
<https://www1.ietf.org/mailman/listinfo/mpls> 

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Bob Thomas <[email-masked]>
Date: Mon, 30 Aug 2004 12:57:45 -0400

>   I agree with Vach that DU and IC can result in black holes or packet

How does it result in "misrouting"?

>   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

> ------_=_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">&nbsp; 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">&nbsp; 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">&nbsp; should not be a =
> requirements of the protocol spec. The FECs should be either</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; 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">&nbsp; 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">&nbsp; in the network. The =
> scheme works fine for IP forwarding, but as Vach pointed out</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; 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:[email-masked]"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
> FACE=3D"Courier New">mailto:[email-masked]</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: [email-masked]; =
> [email-masked]</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,&nbsp; 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">&gt;&gt;&gt;Issue: do we really =
> have to send all FECs in our database whenever we</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;&gt;have an LDP session =
> between two peers?</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New">&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;&gt;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;This should not be a =
> requirement of the protocol spec, the application</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;which is using the =
> protocol should determine which FECS get sent.</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;&nbsp;&nbsp;&nbsp; =
> </FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I agree. This is not a =
> specification issue, but rather a best-practice</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;based on the application =
> for which the protocol is used. If you only </FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;need the loopbacks as FECs =
> for your application, then it is best if you </FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;_ask_ LDP to only =
> redistribute the loopbacks, because it will make your </FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;network easier to =
> troubleshoot.</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ina</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&nbsp; </FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;&gt;Issue: with all the =
> combinations of Downstream Unsolicited,</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;&gt;Downstream on =
> Demand, Ordered Control, Independent Control, etc., it </FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;&gt;makes sense to =
> define a mandatory combination.&nbsp; DU/OC seems to be the </FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;&gt;favored one.</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New">&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;&gt;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;I believe&nbsp; this =
> would&nbsp; put a majority&nbsp; of the&nbsp; deployed LDP =
> speakers</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;out of spec.&nbsp; Such =
> a change cannot be made as part of going to DS.</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;&nbsp;&nbsp;&nbsp; =
> </FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier =
> New">&gt;_______________________________________________</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;mpls mailing list</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;[email-masked] =
> </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">&gt;</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&nbsp; </FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</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">[email-masked]</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
> 
> --===============0921775444==--
>