Subject: [Gen-art] Gen-ART LC Review of draft-ietf-ccamp-rsvp-te-exclude-route-05.tx t

From: "Gray, Eric" <[email-masked]>
Date: Fri, 8 Sep 2006 17:07:26 -0400

Authors,

	I am the Gen-ART assigned Last Call Reviewer for this
document.

	For background on Gen-ART, please see the FAQ at:

	http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html

Please resolve these comments along with any other Last Call 
comments you may receive.

============================================================
Summary:
-------
This document is almost ready for publication as a Proposed
Standard RFC.  It is - over-all - clear, concise and easy to 
read.  There are a few comments below that I feel should be
addressed in some way before it is published.

============================================================
Comments:
---------
In section 1.1, you say:

"This document does not preclude a route exclusion from 
 listing  arbitrary nodes or network elements to avoid. 
 The intent is, however, to indicate only the minimal 
 number of subobjects to be avoided."

This is an aspect of probably the most serious drawback
to what this draft proposes.  I can't easily come up with
scenarios in which it is more difficult to specify the
elements you want a route to include than it is to say 
which elements you want it to exclude.

In fact, it is reasonably easy to see that the complexity
of an "include description" is on the same order as the
complexity of the desired end-product route.  Not so, at
all, for an "exclude description" whose complexity is not
bound at all (effectively) since you _could_ describe a
route explicitly as the one route that is left after you
exclude all others (including routes that have loops in 
them).

What does this document propose as a means to protect an
implementation from another implementations proposing a
literally arbitrarily complex exclusion list?

IMO, a new error code - corresponding to "XRO too complex"
would be one approach - if an XRO exceeds some measurement
of complexity RECOMMENDED by the specification.

(Of course, this introduces a management consideration,
as it should then be possible to determine tolerance for
complexity of at least the locally managed nodes.)

------------------------------------------------------------
In section 2, you include the following sentence:

"This subobject might also be appropriate for use within
 Explicit Routes or Record Routes, but this is outside the 
 scope of this document."

I read this is "You could do 'X', but this document does 
not discuss 'X'."

What's the point in including this sentence?

------------------------------------------------------------
In section 2.1, you describe the format of a new SRLG object
- which is itself "word aligned" by inclusion of a two-octet
"Reserved" field, but which does not "word align" the SRLG
ID itself by simply putting the Reserved field in the first
word.

I realize this comment comes up frequently and that it is 
not usually a problem for modern implementations to deal 
with word-alignment problems, but wanted to know what the
authors' thinking was in this case.  Is the Reserved field
purely for padding to a word boundary, or do the authors
anticipate that it might eventually by used for something
else?  If it might be used for something else, do authors
anticipate that something else might scope the SRLG, or be
scoped by it?

------------------------------------------------------------
In two places, you refer to the SRLG object type as "TBD by
IANA" - in section 2.1 (in the description of "Type" under
the format figure) and again in section 3.1 (in the table of
XRO subobjects).

In section 3.1, you have two places in which you refer to 
"Exclude Route Class value" - once in the first paragraph
(as [TBD]) and once just above the figure showing format
of the object (as "Class = TBD by IANA").

This seems to set up some possibly complicated instructions
to IANA (which are not - by the way - included in the IANA
Considerations section), and the RFC Editor, in order to 
avoid the embarassing situation in which the draft gets 
published as a Proposed Standard with values that appear to 
be [TBD].

I recommend replacing these references with recognizable
"variable names" - e.g. [SRLGO-IANA] and [XRClass-IANA] - 
which are then referenced in IANA considerations as well.

Then the RFC Editor instructions could be as simple as
"please replace all instances of [XXX-IANA] with the 
appropriate values assigned by IANA..."

This same observation applies to "Explicit Exclusion 
Route Subobject" - but there you have a "variable name"
(EXRS).

------------------------------------------------------------
In section 3.2, bullet 3, you state that ERO and XRO MUST
NOT contradict each other - and then go into a relatively
interesting and complicated description of how to resolve
such a contradiction.

You should make up your mind.  Either the ERO and XRO 
"SHOULD NOT contradict each other" and here is what you
do if they do, or they "MUST NOT contradict each other"
and here is the error code you return.

IMO, the request initiator SHOULD construct a request 
that is free of contradictions between XRO and ERO.
In the event that expansion of one or the other later
introduces a contradiction, the steps you describe
would apply to resolving it.

------------------------------------------------------------
In section 3.2, very little is said about what it means to
say "SHOULD be avoided" - other than the text in the 3rd
bullet on resolving a contradiction and the short bit in
the 4th bullet about minimizing the number of instances of
selecting resources that were listed as "SHOULD avoid".

IMO, this is insufficient.  Since the XRO can be reduced,
and it is not necessarily the case that any node could
determine how many instances of "SHOULD be avoided" have
already occurred, the quality of this control knob is a
bit weak.

For one thing, short of explicitly listing examples of 
when it might be appropriate to select an expansion that
does not minimize "SHOULD avoid" resources - or at least
explicitly stating the considerations involved - this
document SHOULD say "MUST be minimized" ("minimised" is
perfectly acceptable, since you're using that version of
the English language).

Also, it would be useful to include some text about the
process of route selection in the case where multiple
routes exist and the local node is not in the process 
of expanding an ERO.

------------------------------------------------------------
In the 2nd bullet of section 6, you state that support for
EXRS is optional.

IMO, you need to state how messages containing an EXRS are
handled by an implementation that does not support EXRS, if
support for EXRS is optional.

If this is included in section 4.2 (which may or may not 
be a good idea - since that SHOULD be a description of how
EXRS is supported, not "not supported"), it does not jump
out at me.

I recommend describing how this is done (or why it does 
not matter) in the body of this second bullet.

------------------------------------------------------------
I disagree with section 7.  The current document introduces
a potentially arbitrarily complex object without offering
an "opt-out" mechanism.  This at least slightly increases
the exposure of resulting implementations to a DoS attack
against the signaling control plane.

============================================================
Editorial/NITs:
--------------
In section 3, first paragraph, "exlude" should be "exclude"
(middle of the 3rd line of the paragraph).

------------------------------------------------------------
In section 3.1, first paragraph after the format figure,
"subojbects" should be "subobjects" (beginning of the 3rd
line of the paragraph).

------------------------------------------------------------
In the description of the "L" bit under all of the objects
in section 3.1, you use the words "MUST be excluded" and 
"SHOULD be avoided" - is there a difference in meaning of
"excluded" and "avoided"?  Note that in the general text,
toward the beginning of section 3.1, you say:

"The concept of loose or strict hops has no meaning in 
 route exclusion. The L bit, defined for ERO subobjects 
 in [RFC3209], is reused here to indicate that an abstract 
 node MUST be avoided (value 0) or SHOULD be avoided 
 (value 1)."

It's not a big deal (hence it is in the "NITs"), but it
probably would raise less dust if the wording was more
consistent.

------------------------------------------------------------
In section 3.2, bullet number 2, "SHOULDreturn" should be
"SHOULD return" (middle of second line of the bullet text).

------------------------------------------------------------

Ta
--
Eric

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 8 Sep 2006 23:55:37 +0100

Hi Eric,

(Note change in Cheng Yin's email)

(Added Deborah as CCAMP chair)

> I am the Gen-ART assigned Last Call Reviewer for this

Oh good, that'll keep us on our toes.

> which elements you want it to exclude.

The point really is that if you can compute the full path, you are probably
done and you can send an ERO, but if you either don't care about the path or
can't compute the whole path, then you have to specify the exclusions.

As the Abstract says...
   In some networks where precise explicit paths are not computed at the
   head end it may be useful to specify and signal abstract nodes and
   resources that are to be explicitly excluded from routes.

> exclude all others (including routes that have loops in

Right!
That is true.
You still assume that the guy who will compute the next piece of path will
use CSPF or similar.
So you don't *need* to specify everything you want to avoid. As you say,
specifying everything you want to avoid is a long list and it is easier to
specify the explicit path.

But, if there are specific things that you want to avoid that might turn up
on the CSPF-computed path (e.g. I would prefer not to go through Haalem)
then these are what you state in the exclusion.

Clearly we did not make it obvious that the ERO is still the primary way of
controlling the route, and I would welcome your suggestion about where we
should best clarify this in the I-D.

> complexity of at least the locally managed nodes.)

The error code is a good idea.
The decision can be entirely a local policy matter.
If I don't like your XRO I can reject it. You can retry on a different
route, reduce the XRO, or give up.
I would not like to make a recommendation about what a reasonable XRO is in
an RFC.

Hmmm.
Well, other sub-objects we use are identical to ERO sub-objects.
We find ourselves defining a new sub-ibject for exclusions, and we believe
it may well have use in an ERO, but clearly that is not our business.

We could drop this sentence IMHO (and where it shows up in section 1). [You
saw that as well, but you were too polite to mention it ;-]

All RSVP objects are padded to four-byte boundaries. It is common for
implementations to make this quick check before parsing further.

However, you are completely right about moving the padding to be before the
SRLG I-D. That would also allow easy extension for other SRLG formats in the
future. I need to check with the other authors, but this seems reasonable.

But we may get some push-back from implementations, and since it is not
really a significant issue, perhaps we can let it go?

That's an easy piece of editorial good sense that we can do.

Ah. You have caught the nub of an argument between the authors that I
thought we had cleaned out :-(

As is clear from the presence of the text explaining how to resolve
contradictions, the intention is "SHOULD" not "MUST". I think we can safely
make this relaxation without needing to call this a significant change in
the protocol.

OK so far.
Yes the definition of the should/must bit could use some more words to
explain what should means in this context.
We'll work on that.

Wrt to minimise/minimize, I know you understand that the responsiblity of
the communicator is to be understood, and that our audience is primarily
American, so we will fix this and save the RFC Editor some red ink.

> routes exist and the local node is not in the process

Interesting.
There is not a whole lot to say (especially if you count loose routing as a
form of ERO expansion).
If you are not doing ERO expansion, the ERO tells you everything you need to
know to get to the next node.
But we'll look at this. There may be something for (for example) resource
exclusions even when the ERO is complete.

OK we can add that. It would be standard RSVP processing of an unsupported
ERO subobject per RFC3209.

> not matter) in the body of this second bullet.

Noted.
I think the "Why don't you and your XRO F Off?" Error Code that you
suggested above may cover this.

Ah, please exuse my typing.

Worth us checking the whole I-D.

Excellent job, Eric.

Many thanks,
Adrian