The MPLS WG Archive

[Bob Thomas <rhthomas@cisco.com>]

> Let's put the VPN network aside for a bit and suppose we were dealing with a
> pure IP network. Now here is what is going to happen:
> 
> 1- Using the independent mode of operation, B associates L10 with the loop
> back address of node Z and sends a label mapping (L10, Z) to node A.
> 
> 2- A transmits packets destined to Z using L10.
> 
> 3- B receives the labeled packet, pops the label, resumes normal IP
> forwarding and forwards the packet based on its DA.
> 
> Now, RFC 3031 as Bob mentioned in his e-mail advices against such a practice
> and suggests that the safest thing to do is to drop the packet. But I think
> we should be very explicit in the spec. My point is that DU and independent
> mode of operation at best can result in packet drop. So, we might want to
> advice against it or at least mention this in RFC 3036.

RFC 3036 Section 2.6.1.1 clearly states:

   A consequence of using independent mode is that an upstream label can
   be advertised before a downstream label is received.

One can draw one's own conclusions from that.

I continue to believe that any further discussion of the pros and cons
of Independent and Ordered modes is a topic for RFC 3037 (LDP
Applicability), not RFC 3036.

Bob



> Please find my other comments below:
> 
> Arashmid
> 
> 
> -----Original Message-----
> From: Eric Gray [mailto:egray@westridgenetworks.com] 
> Sent: Tuesday, August 31, 2004 11:10 AM
> To: Bob Thomas; Akhavain, Arashmid [CAR:NP62:EXCH]
> Cc: mpls@ietf.org
> Subject: RE: [mpls] Requesting your feedback - issues/errors/clarification s
> 
> 
> 
> 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.
> 
> [Arashmid]
> Yes, as you mentioned, the issue with this "known bug" is that BGP peers do
> not know that there is a continuous LSP from peer to peer. This is the basic
> issue with the use of DU and independent mode of operation. The head node of
> LSP receives a label and would be under the impression that there is a full
> path while the path could only be partially complete. DU and ordered mode is
> more robust in this regard.
> [Arashmid]
> 
> 
> 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.
> 
> [Arashmid] Given that the same setup would have worked correctly in a pure
> IP network, I think the key point in your statement is that the underlying
> packet is not an un-labeled packet. As such, since node B does not have a
> downstream mapping for the FEC, it must drop the packet. I agree with your
> pint here, but again the use of DU and ordered mode would have bettered
> guaranteed the existence of the downstream mapping.
> [Arashmid]
> 
> 
> 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.
> 
> [Arashmid]
> True, we should write spec to tell people what they need to do the right
> thing. Therefore, we should tell them to use DU in conjunction with Ordered
> control.
> {Arashmid]
> 
> > -----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

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