The MPLS WG Archive

["Eric Gray" <egray@westridgenetworks.com>]

In addition to Bob's observation, one of the "known bugs" with MPLS/BGP
is that the BGP peers MUST know (in some un-specified way) that there is
a continuous LSP from peer to peer before they can use the LSP to carry
MPLS/BGP labeled packets. In this case, the ingress PE should not have
forwarded the packet using the MPLS/BGP label without "knowing" that 
the LSP was continuous peer to peer. An example technique might rely on
the Hop-Count loop detection mechanism, possibly in conjunction with an
IGP routing protocol.

As Bob points out, if the LSP is incomplete, the LSR where it terminates
SHOULD discard the labeled packets it receives. Remembering that the LSR
in the example gave the label L10 out for a FEC for Z, that LSR SHOULD
be
anticipating that it would forward the enclosed packet toward Z. Finding
that the underlying packet is not - as expected - an un-labeled packet
(it
SHOULD expect this, because it does not have a downstream mapping for a
FEC corresponding to Z), it SHOULD discard the packet without processing

further. This would result in black-holing the packets, rather than mis-
directing them - and would actually be because of a misguided MPLS/BGP
implementation, rather than an LDP problem.

Even if the LSR did do further processing, it is NOT correct for the LSR
to 
assume that it issued the underlying label - since (as Bob points out)
it
did not issue the original (freshly popped) label (L10) for itself as a
destination FEC. Looking further, it would see that it did not receive 
any such label from the next hop for FEC Z, either, and would then
discard
the packet. If the LSR pops a label expecting to have terminated an LSP
(in other words, not as a result of PHP) associated with an IPv4 FEC, it

should expect the underlying packet to be an IPv4 packet and discard it
if
it is not.

We should write specifications to tell people what they need to do the
right thing, not to tell them all the wrong things they should not do.


> -----Original Message-----
> From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org]
On Behalf Of Bob Thomas
> Sent: Tuesday, August 31, 2004 7:04 AM
> To: Arashmid Akhavain
> Cc: 'mpls@ietf.org'
> Subject: Re: [mpls] Requesting your feedback -
issues/errors/clarification s
> 
> > 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

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