The MPLS WG Archive

["Vach Kompella" <vkompella@timetra.com>]

I'm ok with that.

-Vach 

> -----Original Message-----
> From: mpls-bounces@lists.ietf.org 
> [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Bob Thomas
> Sent: Wednesday, September 01, 2004 3:15 PM
> To: Arashmid Akhavain
> Cc: 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
> 


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