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

From: "Arashmid Akhavain" <[email-masked]>
Date: Wed, 1 Sep 2004 12:10:50 -0400

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.

Please find my other comments below:

Arashmid

-----Original Message-----
From: Eric Gray [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2004 11:10 AM
To: Bob Thomas; Akhavain, Arashmid [CAR:NP62:EXCH]
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]]
On Behalf Of Bob Thomas
> Sent: Tuesday, August 31, 2004 7:04 AM
> To: Arashmid Akhavain
> Cc: [email-masked]'
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Bob Thomas <[email-masked]>
Date: Wed, 01 Sep 2004 18:14:56 -0400

> 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

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 1 Sep 2004 16:19:52 -0700

I'm ok with that.

-Vach 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bob Thomas
> Sent: Wednesday, September 01, 2004 3:15 PM
> To: Arashmid Akhavain
> Cc: [email-masked]
> > 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.
> > 
> > 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.
> 
> 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
> 
> 
> 
> > 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, 
> > [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
> > 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]
> > 
> > > > + Z advertises label L100 for one of its VPN routes to A via 
> > > > + MP-BGP.
> > > >
> > > > + Receiving L10 for the loop back address of Z, A will be under 
> > > > + the
> > > > impression
> > > > + 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.
> > > >