The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2004-Aug> msg00032



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[mpls] Requesting your feedback - issues/errors/clarifications

  • From: Luca Martini <lmartini@cisco.com>
  • Date: Thu, 26 Aug 2004 15:19:00 -0600
  • Cc: mpls@ietf.org, vach.kompella@alcatel.com
  • User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

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


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