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
document.
Oh good, that'll keep us on our toes.
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.
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.
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).
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.
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.)
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.
------------------------------------------------------------
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?
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 ;-]
------------------------------------------------------------
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?
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?
------------------------------------------------------------
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).
That's an easy piece of editorial good sense that we can do.
------------------------------------------------------------
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.
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.
------------------------------------------------------------
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).
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.
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.
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.
------------------------------------------------------------
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.
OK we can add that. It would be standard RSVP processing of an unsupported
ERO subobject per RFC3209.
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.
Noted.
I think the "Why don't you and your XRO F Off?" Error Code that you
suggested above may cover this.
============================================================
Editorial/NITs:
--------------
In section 3, first paragraph, "exlude" should be "exclude"
(middle of the 3rd line of the paragraph).
Ah, please exuse my typing.
------------------------------------------------------------
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.
Worth us checking the whole I-D.
------------------------------------------------------------
In section 3.2, bullet number 2, "SHOULDreturn" should be
"SHOULD return" (middle of second line of the bullet text).
------------------------------------------------------------
Excellent job, Eric.
Many thanks,
Adrian
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
