Subject: RE: independent vs ordered

From: Adrian Farrel <[email-masked]>
Date: Fri, 14 Jan 2000 11:07:22 -0000

Nava,

Sorry.  I see what you meant by your original question.

Yes, Control mode appears to be missing from the LDP MIB.
I think it should be in the LdpPeerTable next to
mplsLdpPeerLabelDistributionMethod 

Joan, would you like to comment?

While we're on (or near) the subject, does anyone know why
mplsLdpEntityLabelDistributionMethod is in the LdpEntityTable as well?  It
would seem that an LDP entity needs to know what method of label
distribution to use, but that this could vary per session (i.e. per peer).
In addition, according to draft-ietf-mpls-ldp-06, ...

   However, for any given LDP session, each
   LSR must be aware of the label distribution method used by its peer
   in order to avoid situations where one peer using Downstream
   Unsolicited label distribution assumes its peer is also.

which suggests that this information should be added to the LdpPeerTable,
too.

Regards,
Adrian
--
Adrian Farrel  mailto:[email-masked]
ATM, MPLS and Telecoms Development Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

>From: Nava.Zvaig [mailto:[email-masked]]
>
>How is an LSR defined to be independent or ordered?  Is there 
>a standard way or is it proprietary for each router?
>
>>From: Adrian Farrel [mailto:[email-masked]]
>>
>>Look at section 4.12 of "A Framework for Multiprotocol Label Switching"
>><draft-ietf-mpls-framework-05.txt>
>>
>>Also 3.19 of "Multiprotocol Label Switching Architecture"
>><draft-ietf-mpls-arch-06.txt>
>>
>>>From: Nava.Zvaig [mailto:[email-masked]]
>>>
>>>Where, or how, are independent and ordered label distribution 
>>>contol modes
>>>defined?

---

From: Eric Gray <[email-masked]>
Date: Fri, 14 Jan 2000 08:58:37 -0500

Adrian,

	This turf feels familiar.

	The control modes "ordered" and "independent" are
implementation choices.  It's good to have the terms so
that we can have intelligible discussions about some types
of control operations and how they work.

	However, real world implementations are likely to
implement one mode for some operations and the other for
other operations and some hybrid of the two for still more
operations.  Examples:

o Ordered Control - satisfying CR-LDP Label Requests.
o Independent Control - allocating new labels as a
  result of a route change.
o Hybrid - use Independent Control for initial labels
  and Ordered Control for additional labels in an MPLS
  network consisting entirely of non-merge capable LSRs.

Another instance of hybrid operation is exemplified by
the following:

        - - - LSR-n --- LSR-p --- LSR-q --- (LS)R-t

If initially LDP is not enabled for (LS)R-t, then LSR-q
is the LSP egress for traffic going through (LS)R-t.  If
LDP is now turned on at (LS)R-t, LSR-q will detect that 
its next hop for traffic going through (LS)R-t is an LSR
and it is no longer the egress for LSPs toward (LS)R-t.

What does LSR-q do for the short period of time that will
transpire between detecting that (LS)R-t is an LSR and 
getting all the Labels it requires in order to complete
the existing LSPs toward (LS)R-t?

If LSR-q immediately tears down all such LSPs, then it is
using Ordered Control in the strictest sense.  One might
want to do this, if one is concerned about looping data
traffic, for instance.  However, this would be extremely
disruptive and anti-social behavior in many cases.

If LSR-q sends new Label Mapping messages for all such 
LSPs to reflect that the hop-count is now unknown, it
is possibly just as disruptive since upstream LSRs may 
elect not to use the LSP until the hop count is known
(another way to avoid looping data).  If LSR-q elects
to do this, however, it is not strictly using ordered
control.

If LSR-q simply continues to forward packets (as it was
doing) to (LS)R-t as IP packets until it receives new
Label Mappings (and forwards the new hop count upstream)
there will be minimal disruption.  However, in this case,
LSR-q is clearly not using Ordered Control mode.

What - you might ask - is my point?

One - given any specific implementation - it is not at
all guaranteed what control mode means in every case.
Therefore, if a vendor elects to make control mode an
option, they must provide the management hooks and
description of behavior that fits their implementation.
Trying to generalize this looks like a rat-hole.

Two - with the exception of cases where the control mode
is explicitly defined (i.e. - CR-LDP) - behavior of MPLS
systems is not dependent on having a consistent control
mode.  Control modes of individual LSRs do not normally
affect how other LSRs behave in an MPLS network.  Thus,
there is no general requirement to be able to configure
control mode in LSRs.

Three - largely because of one and two above - there is
no general requirement for any implementation to support 
any particular control mode.  If vendor A builds LSRs 
that only use ordered control and vendor B builds LSRs
that only use independent control, having management
hooks in place to read/set the control mode is useless.

In short, IMHO, having standard MIB variables for control 
mode is meaningless, unnecessary and ineffectual.  :-)

Does this make sense?