The MPLS WG Archive

["Eric Gray" <egray@westridgenetworks.com>]

Arashmid,

I agree with Bob that the kind of statement you're looking for 
makes more sense (assuming it is technically correct) in an
applicability guide.  However, there are two fairly fundamental
problems with making this particular statement anywhere.

One of them is that we would essentially be saying that the way
in which a large number of implementations work by default (i.e. -
downstream unsolicited, independent control) would be either the
one we advise against, or the one we disallow. That would be 
very much counter to the intention of taking an RFC from a 
Proposed Standard to a Draft Standard.

The other is that the distinction apparently assumed in your 
analysis is much less apparent in real implementations. For
example, many (if not most - or even all) independent control
LDP implementations tend to do label advertisements as driven
by (at least changes in) routing advertisements. If you think
about how routing advertisements typically progress in networks
(from a destination network outward) and imagine that labels 
are advertised following routing advertisements, you see that
the difference between independent control and ordered control
is more philosophical than real. To make this point even more
abundantly clear, consider this case:

S ---> L1 ---> L2 ---> ... ---> Ln ---> Rm ---> ... ---> D

Where S is a packet source, D is a destination, L1 -> Ln are 
active label switching routers and Rm is currently a "plain
old" router. If we use ordered control to set up an LSP for 
the FEC for D from L1 to Ln, the LSP is setup from Ln back 
to L1. Now, if an operator/administrator turns on LDP in Rm,
what do we expect to happen?

I believe that - in real implementations - the answer is that
Rm (now Lm) would simply send a label mapping to Ln completing
the LSP now from L1 to Ln. This behavior is more consistent 
with independent control than with ordered control, yet the
"proper" ordered control behavior would be very disruptive
(hence not very "robust").

Also note that - if we accept the argument that the combination
of downstream unsolicited and ordered control is somehow more
"robust" than downstream unsolicited independent control - then
we may expect slightly more disruptive activity in existing LSP
signaling for this combination in the face of a dramatic change 
in routing topology. IMO, "disruptive" and "robust" are not good
friends.

Finally, as one highly respected routing implementer once said, 
you don't build "robustness" into a protocol, you build it into 
an implementation. In this case, you can put the ability to 
determine the continuity of an LSP into an implementation. 
However, you only need it there - hence it is not necessary for 
the LDP specification to describe how to do it for any specific 
implementation.

--
Eric

> -----Original Message-----
> From: Bob Thomas [mailto:rhthomas@cisco.com]
> Sent: Wednesday, September 01, 2004 6:15 PM
> To: Arashmid Akhavain
> 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