RE: Requesting your feedback - issues/errors/clarification s
2004-09-01 16:10:50 GMT
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:egray <at> westridgenetworks.com]
Sent: Tuesday, August 31, 2004 11:10 AM
To: Bob Thomas; Akhavain, Arashmid [CAR:NP62:EXCH]
Cc: mpls <at> 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 <at> lists.ietf.org [mailto:mpls-bounces <at> lists.ietf.org]
On Behalf Of Bob Thomas
> Sent: Tuesday, August 31, 2004 7:04 AM
> To: Arashmid Akhavain
> Cc: 'mpls <at> 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 <at> lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
RSS Feed