The MPLS WG Archive

["Arashmid Akhavain" <arashmid@nortelnetworks.com>]

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

I agree...These types of discussions are best to be discussed under RFC 3037.

Regards,
Arashmid

-----Original Message-----
From: Bob Thomas [mailto:rhthomas@cisco.com]
Sent: Wednesday, September 01, 2004 6:15 PM
To: Akhavain, Arashmid [CAR:NP62:EXCH]
Cc: 'Eric Gray'; mpls@ietf.org
Subject: Re: [mpls] Requesting your feedback - issues/errors/clarification s

> 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