Subject: Re: [mpls] Review comments on Draft "LDP Downstream-on-Demand in Seamless MPLS"

From: "Maciek Konstantynowicz (mkonstan)" <[email-masked]>
Date: Sat, 2 Feb 2013 20:20:24 +0000

Eric,

Many thanks for your review.

We have modified the text of the draft to reflect your suggestions. Will publish updated version shortly.
Pls let us know if any further comments.

More inline [mk]

Thanks,
Maciek.

e: [email-masked]<mailto:[email-masked]>

On 17 Jan 2013, at 22:03, Eric Gray wrote:

Authors,

                I found this draft to be fairly complete and – with some minor changes – it should be relatively easy to
read.

                One aspect of this draft that I find somewhat unsettling is the implication that most LSRs do not support
downstream on demand label distribution.  This would seem to be at odds with the implementation report used
in writing RFC 5036 (Draft Standard "LDP Specification"), or DoD would have been omitted in that RFC.

                The latter half of the 3rd paragraph on page 5 is an interpretation of one reason for specification of DoD
label allocation, and is not quite accurate even in that sense.  The main reason for DoD allocation with ATM – in
particular – was because of the great difficulty associated with merging too many upstream paths into a single
downstream LSP – when the downstream LSP is in fact an ATM VCC.  It should be sufficient to state that – in at
least some implementations – LDP DoD is not implemented and leave the justification for this implementation
decision unspecified.

                Speculation as to why implementers make the choices they do is just that – speculation..

[mk] The paragraph in question got removed.

                Note that RFC 5036 was itself published in October of 2007, when ATM and Frame Relay deployments
were scarce in general and new deployments of MPLS-based ATM and Frame Relay were non-existent.

                Readers might also want to realize that the MPLS Architecture assumes both DU and DoD capabilities
exist in MPLS but may or may not be implemented in any specific MPLS implementation.

                I do have some issues with the fact that this draft seems intent on describing a subset of DoD specified
in RFC 5036 that applies specifically to the use cases that this draft identifies.

                Might it not be a great deal simpler to state that DoD – as specified in RFC 5036 and described in RFCs
3031 and 3215 – should be implemented for support of those use cases? Will we need to describe a different
subset when we discover additional use cases?

[mk] Authors of this draft agree that the described design use cases represent major network deployments and due to the specific nature of MPLS LSR devices used, warrant the functional description of LDP DoD operations and their applicability to access use cases.

                The document does provide a really good discussion of interactions between control and distribution
modes for labels and the use/support of DoD.
It appears to have missed one or two points that originally came
out when all of this stuff was being initially specified.

1) The combination of liberal retention and downstream on demand is a very inefficient approach to populating
     an LSR's label tables.  If you're going to ask for them all anyway, why not indicate to your peer that you want
     all of them sent to you in the first place?

[mk] The point here is not to ask for all of the labels ( this would be downstream unsolicited ), but only for those that are needed.

2) The combination of ordered control mode and downstream on demand means that a LSR only needs to bind
      any FEC to a label when –
     a) it knows how to forward packets for that FEC (i.e. – it has a route corresponding to the FEC) and
     b) it has received at least one label-request message from an upstream LSR.

                The latter point is incorrectly reflected in the second bullet in section 4.1.

[mk] New text:

      Ordered mode - an LSR needs to bind a label to a particular FEC if
      it knows how to forward packets for that FEC ( i.e. it has a route
      corresponding to that FEC ) and if it has already received at
      least one label request message from an upstream LSR.

                The paragraph after the bullets describing conservative and liberal retention modes seems to
assume a very weak (or very literal) implementation of conservative retention mode, in assuming that a
label will not be retained if it is not associated with the current active route.  Obviously an LSR may retain
any labels it needs to meet all of the requirements of the services it supports and still be using conservative
retention mode if it does not retain every label ever distributed to it.

NITs

In the second paragraph of the Introduction section, the last two sentences should be a separate paragraph.
The two sentences address a different aspect of the focus of this document.

[mk] New text:

   In general MPLS Label Switching Routers implement either LDP or RSVP
   for MPLS label distribution.

   The focus of this document is on LDP, as Seamless MPLS design does
   not include a requirement for general purpose explicit traffic
   engineering and bandwidth reservation.  Document concentrates on the
   unicast connectivity only.  Multicast connectivity is subject for
   further study.

In the 4th paragraph of the Introduction, the expression "a very insufficient" is not particularly meaningful as the
degree of insufficiency is subjective and likely immeasurable.  Replace this phrase with "an inadequate …" Also,
replace "as they" with "which" in the portion of the same sentence that follows the comma.

[mk] New text:

   The amount of MPLS forwarding state however requires additional
   consideration.  In general MPLS routers implement LDP Downstream
   Unsolicited (LDP DU) label advertisement [RFC5036] and advertise MPLS
   labels for all valid routes in their RIB.  This is seen as an
   inadequate approach for ANs, which requires a small subset of the
   total routes (and associated labels) based on the required
   connectivity for the provisioned services.

The phrase "MPLS routers" that is used earlier in the same paragraph is unclear and is most likely meant to be
"Label Switching Routers" or "LSRs."

[mk] New text:

   In general MPLS Label Switching Routers implement either LDP or RSVP
   for MPLS label distribution.

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls