The MPLS WG Archive

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



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

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

  • From: Bob Thomas <rhthomas@cisco.com>
  • Date: Tue, 31 Aug 2004 07:03:35 -0400
  • Cc: "'mpls@ietf.org'" <mpls@ietf.org>

> Packet misrouting can happen under the following circumstance.
> Consider the following L3-VPN network
> 
> 
> A----------B----- ... ------Z
> 
> + B sends a label mapping message for loop back address of Z to A using
>   the independent control mode of operation. Let's call this label L10.
> 
> + Z advertises label L100 for one of its VPN routes to A via MP-BGP. 
> 
> + B could also be a PE and could have allocated label value L100
>   to one of its links to a CE device it is connecting to.
> 
> + Receiving L10 for the loop back address of Z, A will be under the
> impression
>   that it has a full path to Z.
> 
> + A starts transmitting packets with outer label L10 and inner label L100.
> Meanwhile
>   no label representing the loop back address of Z has arrived at B. 
> 
> + B receives the labeled packet and pops L10.
> 
> + B then proceeds with the processing of L100.
> 
> + B recognizes L100 as a local label and transmits the un labeled packet to
> the
>   wrong CE device.

This behavior of B appears to be in violation of the spirit (if not the
letter) of the advice in Section 3.22 (Lack of Outgoing Label) of rfc3031.

Unless label L10 refers to B itself (which it doesn't in the scenario
described above), forwarding the packet according to the label beneath
it (L100) is a forwarding error.

Bob




> Arashmid
> 
> 
> -----Original Message-----
> From: Bob Thomas [mailto:rhthomas@cisco.com] 
> Sent: Monday, August 30, 2004 12:58 PM
> To: Akhavain, Arashmid [CAR:NP62:EXCH]
> Cc: mpls@ietf.org
> Subject: Re: [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