Subject: Comments on draft-ietf-mpls-cr-ldp-02

From: Adrian Farrel <[email-masked]>
Date: Wed, 8 Sep 1999 13:24:55 +0100

Bilel,

As before, I have some substantive comments and a bunch of typographic
markups.  The latter are clustered at the end of this email so as not to
muddy the waters.  I've tried to filter out comments that have been made by
others on the list recently.

I hope you don't think I am raising too many points.  In general the draft
seems very stable.

Regards,
Adrian

Substantive Points

1)  Section 2.1.  Penultimate paragraph.  I think that, for completeness,
this paragraph should include some mention of ordering.  Perhaps by
extending the final sentence with "in the order in which they appear in the
TLV."

2) Section 3.3.  Why is the LSPID TLV optional on a Label Mapping Message?
It is always available (because it is mandatory on a Label Request Message
and because Label Mapping is limited to downstream on demand).  The LSPID
would be of use in circumstances described by points 4) and 11) below (i.e.
when a Notification is sent after a Label Mapping Message fails.)

3) Section 3.4.  First paragraph.  The text reads "Establishment of an
Explicitly Routed LSP may fail... ."  I believe that this should be widened
to "Establishment of a CR-LSP may fail... ."

4) Section 3.4.  The text says that "the Notification Message must carry the
LSPID TLV of the corresponding CRLSP" but the encoding diagram does not show
this TLV.

5) Section 4.1 and subsequent.  There are two inconsistencies with
draft-ietf-mpls-ldp-05 which you may want to resolve with Andresson et al..
5a) You have described Type and Length for each TLV where the LDP draft puts
that information in a separate section at the front.  (I prefer your
version!)
5b) You use "byte" where the LDP draft uses "octet".  I believe "octet" is
better.

6) Section 4.2, description of Contents.  This is a little unclear.  Would
the following text be better?
"A variable length field containing a series of nodes and abstract nodes
that identify the consecutive nodes that make up the explicitly routed part
of the LSP."

7) Section 4.3  Add text to indicate that the value 1 is a lower Weight than
the value 255.  This is important because the ordering is reversed compared
with, say, pre-emption priority. Alternatively, put this information in
4.3.1.7.

8) Section 4.3.1.5 and 4.3.1.6.  I think it would be useful to suggest what
might happen when a packet is in excess of one of the rates.  A simple
statement that implementations may choose to drop or mark the packets, and a
forward reference to Appendix B.

9)  Section 4.3.1.6  First set of bullets.  The rules for incrementing Tc
and Te should say "incremented by one times CDR" not incremented by one.

10)  Section 4.3.2.1, third paragraph.  Is it acceptable to negotiate Weight
down to zero?  I would suggest not since "not applicable" is subtly
different from the lowest Weight value.   Insert "but not including" to read
"a lower value (down to but not including 0)."

11) Section 4.3.2.2.  When a Label Mapping Message fails because PDR is less
than CDR in the Traffic Parameters TLV, it is not sufficient to send a Label
Release downstream.  This releases the resources and labels reserved at the
downstream nodes, but does not release the resources at the upstream nodes.
It is necessary to also send a Notification Message upstream.  [See points
2) and 4) above.]

12) Section 4.4, first paragraph  Are you mandating that the default value
of the setup and holding priorities be 4?  The subsequent sections that
define the fields suggest that you are, but the text in this first paragraph
is looser.  

I think that this is an implementation decision but that you should make a
recommendation.  Change the text to read as follows.  "The default value of
the setup and holding priorities is an implementation decision at each LSR
but should ideally be in the middle of the range (i.e. 4) so that...."

Alternatively, if you are mandating 4, you need to change "e.g." to "i.e."
in your text.

13) Section 4.7.4.  In the LSPID TLV the field is known as Local CRLSP ID
(see section 4.5).  Shouldn't it have the same name here?

14) Section 4.8.1, step 1.  Insert "using a Notification Message sent
upstream." at the end of the sentences that conclude "... return a _Bad
initial ER-Hop_ error." and "... return a _Bad Explicit Routing TLV_ error."

15) Section 4.8.1.  I think it is insufficiently clear that if any action is
taken in step 1, then no other steps (apart maybe from step 7) are
performed.  It would, perhaps, be enough to insert "and continues processing
at step 7" at the end of the sentence that currently concludes "...selects a
next hop that is along the path to the abstract node described by the first
ER-Hop."

16) Section 4.8.1.  Is step 6 necessary if the first ER-Hop is loose?
Compare with step 1 where it is acceptable to process a first ER-Hop with L
bit and local node not part of the abstract node described by the first
ER-Hop.

17) Section 4.9.  This section is unusual in that it does not contain a
paragraph on usage of the TLV.

18) Section 4.11.  Notwithstanding the discussions about Setup Abort or
Label Request Aborted, I see no reference to this status code in the
document.  Similarly, Modify Request Not Supported is not mentioned in the
text.  I think that both of these are implicit in actions described through
references to other specifications, but could usefully be made explicit.

19) Section 4.11.  Need to add No Route to the list of status codes.  See
section 4.2.

20) Appendix A.1, first sequence of steps, step 1.  This text should read as
follows.
"1) The node LSR2 is part of the abstract node described by the first hop
<a>.  Therefore, the first step passes the test.  Go to step 2."

21) Appendix A.1, second sequence of steps, step 1.  This text should read
as follows.
"1) The node LSR4 is part of the abstract node described by the first hop
<c>.  Therefore, the first step passes the test.  Go to step 2."

22) Appendix A.2, second sequence of steps, step 8.  This is missing the
description of the removal of (Group 2) and the removal of (B) from the
ER-Hop TLV, and the consequent removal of the entire TLV.

23) Appendix B.3.  Might it be useful to mention the trade-off between
pre-emption and downwards negotiation?

Typographic Markups

CR-LSP versus CRLSP.  These are use interchangeably, but it might be better
to settle on one of them.

Similarly, CR-LDP and CRLDP also both appear in the draft.

There are also mixed uses of "a LSR" and "an LSR"

Section 1, final paragraph.  The acronym CR-LDP is introduced here for the
first time without expansion.

Section 2.1, first line.  For "an CRLSP" read "a CRLSP"

Section 2.1, first paragraph.  Delete comma in "The reason for setting up
CRLSPs, might be..."

Section 2.3, final paragraph.  Insert the word "the" to read "and be bumped
by the next _equivalent_ request."

Section 2.4.  Change "because" to "even when" to read "...undesirable to
change the path used by an LSP even when a better next hop..." since
"because" could be taken to apply to "undesirable".

Section 2.5.  For "When an CR-LSP" read "When a CR-LSP".

Section 3.  Bullet list of minimal LDP behaviors.  Insert "of" after "Use"
in five separate instances.

Section 3.  Bullet list of additional functionality.  Final bullet.  Append
trailing "s" to read "in the CR-TLVs."

Section 3.3,  diagram.  Justification of right bar in LRM ID and LSP ID.

Section 3.4,  first paragraph.  In my copy of draft-ietf-mpls-ldp-05, the
Status TLV is defined in section 3.4.6

Section 4, first line.  Delete plural "s" in "The Label Request Messages"

Section 4.2, description of the L bit.  The second sentence in the first
paragraph is duplicated by the second and third sentences in the second
paragraph.  I suggest dropping the first occurrence.

Section 4.3, description of Frequency.  Insert line breaks between "2 -
VeryFrequent" and "3-255 - Reserved", and between "3-255 - Reserved" and
"Reserved..."

Section 4.3.1.1  For "VeryFrequently" and "Frequently" read VeryFrequent"
and "Frequent"

Sections 4.3.1.5 and 4.3.1.6  Actions when Tp(t) - B >= 0.  It is not really
necessary to include "down to the minimum value of 0"

Section 4.3.1.5  Paragraph after bullets.  Insert "n" to read "never" in
"...arriving packets are never in excess..."

Section 4.3.2.1 and 4.3.2.2, first paragraph.  Use underscores around
Traffic Parameters Unavailable

Section 4.3.2.1, third paragraph.  Delete "adjust"

Section 4.3.2.1, final paragraph.  Use underscores around Resource
Unavailable

Section 4.4, description of Type.  The value should be 0x820 not 0x810.

Section 4.5, second paragraph.  Insert underscore to read  "An _action
indicator flag_ is carried..."

Section 4.5, third paragraph.  It is section 4.1 of [10] that describes the
procedure for _modify_

Section 4.5, definition of Local CRLSP ID.  For "CRLDP" read "CRLSP"

Section 4.5, definition of Ingress LSR Router ID.  Why is this in quote
marks?

Section 4.5, definition of Ingress LSR Router ID.  Insert the word
"addresses" after "IPv4"

Section 4.7.  Title.  This section addresses syntax and semantics.  Strike
the word "semantics" from the title.

Section 4.7.4, definition of Ingress LSR Router ID.  Why is this in quote
marks?

Section 4.8.1, first line.  For "a explicit" read "an explicit"

Section 4.8.1, step 1.  For "_Bad initial ER-Hop_" read "_Bad Initial
ER-Hop_"

Section 4.8.1, step 5.a.  For "_Bad strict node_" read "_Bad Strict Node_"

Section 4.11  For "Setup abort" read "Setup Abort"

Section 4.11  For "Modify request not supported" read "Modify Request Not
Supported"

Section 9.  Tom worster probably merits a capital W ;-)

Appendix A.1, second paragraph.  Surplus spaces between words.

Appendix A.1, first sequence of steps, step 4.  For "Go to Section 4.8.2"
read "Processing continues with Section 4.8.2"

Appendix A.2, third paragraph.  For " a ER-TLV" read "an ER-TLV"

Appendix 2, second set of steps, step 3.  For "...Label Request Message to a
node..." read "...Label Request Message to another node..."

Appendix B.1, first paragraph.  Surplus spaces between words.

Appendix B.2, first paragraph.  For "applications such voice and video."
read "applications such as voice and video."

Appendix B.2, third  paragraph.  Delete "that" to read "...require Frequent
frequency to be requested..."

Appendix B.3, third paragraph.  Delete "are do not" to read "The edge rules
will also include dropping packets that conform to neither PDR not PBS."
--
Adrian Farrel  mailto:[email-masked]
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

---

From: Eric Gray <[email-masked]>
Date: Wed, 08 Sep 1999 10:27:28 -0400

Adrian,

	Some comments.  I left out parts of your comments
and questions for which I have no disagreement, comment or
answer.

> I hope you don't think I am raising too many points.  In general the draft
[..]
> when a Notification is sent after a Label Mapping Message fails.)

It is optional because it is not needed (definition of 'optional').

Not everything that we know needs to be told.  The LSP-ID is
redundant precisely because it is provided in the Label Request
message - as is also the Label Request ID.  The Label Request
ID is mandatory for other reasons, so why require both?  Doing
so will probably lead to trouble in future versions of CR-LDP.

I think it's reasonable to include it if you want to (or don't
want to change code that does), and I would forward it if I get
it, but I think it silly to treat the absence of the LSP-ID in
a Label Mapping as a protocol error.

Which is what it would be if it is mandatory and not included.

> to "Establishment of a CR-LSP may fail... ."

Any particular reason why there's an advantage in going from
words to acronyms?

> LSPID TLV of the corresponding CRLSP" but the encoding diagram does not show

This has been pointed out - Bilel indicated that the text will
be removed.

> draft-ietf-mpls-ldp-05 which you may want to resolve with Andresson et al..

Andersson, et al.

> that information in a separate section at the front.  (I prefer your

Style issues are not inconsistencies.  Also, it is generally
not useful to comment on style issues unless the style chosen
causes the writing to be difficult to understand.  This is not
the case in either of these styles.

> 5b) You use "byte" where the LDP draft uses "octet".  I believe "octet" is

This is barely more than a style issue.  Both are used in numerous
RFCs, though octet is used slightly more often (I believe I lost a
bet on this a few years back). A few use both terms interchangeably.

This also hardly constitutes an inconsistency.

> that identify the consecutive nodes that make up the explicitly routed part

The current text is somewhat mangled.  However, your proposed
replacement text is slightly wrong.  "Content" is describing
the content in a single ER-Hop TLV - which is a single node.
I propose the following based on your suggestion:

 "A variable length field containing a node or abstract node which is
 one of the consecutive nodes that make up the explicitly routed LSP."

[..]
> and Te should say "incremented by one times CDR" not incremented by one.

I don't think so.

The paragraph above say that Tc and Te are updated CDR times 
each second.  It seems to me that updating Tc and Te by CDR,
CDR times a second is a bit of overkill.

> "a lower value (down to but not including 0)."

Disagree.  Indicating that weight is negotiable should mean
that it can be negotiated down to no weight.  What purpose
does it serve to allow weight to be negotiated from 255 down
to one but not to zero?

> It is necessary to also send a Notification Message upstream.  [See points

Possibly.  Certainly if the current LSR is not going to try 
to establish the downstream LSP again - possibly using some
other downstream neighbor, if that is allowed by the CR-LSP
'constraints'.

However, it seems inappropriate to mandate tearing down the
LSP upstream unless the local LSR is unable to do anything
else.

> Alternatively, if you are mandating 4, you need to change "e.g." to "i.e."

I believe it is fairly clear that the current text is making a
recommendation.  I do not believe that your proposed re-wording
makes this any clearer.

For example, it is generally understood by specification readers
that 'should' (even in lower case) means 'implementation choice'
- with the additional caveat the 'SHOULD' means that significant
weight should be given to the recommendation.

[..]
> references to other specifications, but could usefully be made explicit.

Setup Abort is the same as Label Request Aborted in the 
current (05) version of LDP.  It should not be redefined
or described in this specification as that would simply
increase the amount of text that might need to change as
a result of updating LDP.

> pre-emption and downwards negotiation?
[..]
> paragraph.  I suggest dropping the first occurrence.

I do not believe that these are strictly redundant.
Sometimes slightly re-worded repetition adds clarity.
Rewording sometimes makes things clearer :-).

[..]
> necessary to include "down to the minimum value of 0"

However, doing so does not detract from understanding.

[..]
> will also include dropping packets that conform to neither PDR not PBS."

'... to neither PDR nor PBS.'

---

From: Kishore V Chitrapu <[email-masked]>
Date: Wed, 8 Sep 1999 20:18:06 -0500

Hi All,
 
 I have a question regarding explicit routing. I understand that when a
connection is required with explicit routing, *-LDP is used to
establish LSP. But what about a bi-directional flow as in TCP or any
network management utility like ping. The client
can be smart enough to request a specific path, but what about the server,
should it follow the hop-by-hop ( as it is a point-to-multipoint )  . 
Does it scale?

Can someone please point me a draft/paper which explains this?

thnx,
kishore

---

From: Tony Li <[email-masked]>
Date: Thu, 09 Sep 1999 00:13:28 -0700

> should it follow the hop-by-hop ( as it is a point-to-multipoint )  .

I believe that it has been clearly established that

a) CR-LDP is only one possible mechanism for establishing explicit routing.
RSVP is being used
as the other obvious mechanism.

b) That explicit routing is today intended for traffic aggregates, not for
individual TCP connections,
precisely because of the scalability issues.  Note that this is independent of
the signaling protocol.

c) Traffic engineering (the primary driver of explicit routing today) is most
likely not to require end-host involvement and is likely to be performed
within a single domain today.

Tony