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

From: Adrian Farrel <[email-masked]>
Date: Wed, 8 Sep 1999 17:10:44 +0100

Eric,

Thanks for your prompt response!
Comments interleaved.  Mainly agreement with you, but a couple of questions.

Regards,
Adrian

> Some comments.  I left out parts of your comments
> and questions for which I have no disagreement, comment or
> answer.
> 
> You wrote:
>  
> > 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.)
> 
> It is optional because it is not needed (definition of 'optional').
This really hinges on point 11).  Your answer there shows that on receipt of
a bad Label Mapping Message, a node may choose to send a Notification
upstream or a new Label Request on a different downstream path.  In both
cases the LSP-ID from the initial Label request is required.  It is simply a
question of whether an implementation is _required_ to store this or whether
it can rely on it being on the Label Mapping Message.

I guess the requirements of daft-ash-crlsp-modify mean that the node must
have stored the LSP-ID, so you are correct to say it is not needed on the
Label Mapping Message.

> Not everything that we know needs to be told.
Oh, how true!

> > 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... ."
> 
> Any particular reason why there's an advantage in going from
> words to acronyms?
Perhaps I'm wrong (usually am) but I see an Explicitly Routed LSP as one
which was set up using an ER TLV, where a CR-LSP might not use an ER TLV but
still uses some of the other CR-LDP TLVs.

"Explicit Routing is a subset of the more general constraint-based
routing..."

A minor point of semantics over which it is not worth shedding blood.

> > 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..
> 
> Andersson, et al.
Oops.  No insult intended.

> > 5b) You use "byte" where the LDP draft uses "octet".  I believe "octet"
> is
> > better.
> 
> 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.
Fine.  I wouldn't want to re-start an old religious war.  I point it out
solely so that the authors can be aware and make their decision.

> > 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."
> 
> 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.
Yes.  My carelessness.

> 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."
That looks fine.

> > 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.
> 
> 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.
Yes.  Sorry, what I wrote was crass.  In fact what is written is perfectly
correct (i.e. incremented by one). What I said would result in an increase
of CDR**2 per second.

> > 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)."
> 
> 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?
Referring back to 4.3, The value 0 is not a "valid weight value" but means
that weight is not applicable.  Does "not applicable" mean that the CRLSP
should be allocated no share of the possible excess bandwidth above its
committed rate?

If so, then I'm content.

> > 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.]
> 
> 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.
Largely covered by comments on 2).  There is, however, the race condition
where the new Label Request overtakes the Label Release.  I'm not clear
whether this is handled by draft-ash-crlsp-modify.

> > 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.
> 
> 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.
OK.

> > 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.
> 
> 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.
OK

> > Typographic Markups
>  
> > 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.
> 
> I do not believe that these are strictly redundant.
> Sometimes slightly re-worded repetition adds clarity.
> Rewording sometimes makes things clearer :-).
...and heaven knows some of us need it clarifying!

> > 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"
> 
> However, doing so does not detract from understanding.
ditto.

> > 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."
> 
> '... to neither PDR nor PBS.'
Hmmmm.  You can't get the staff, you know.  My typist is terrible :-(

--
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