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 protected]
https://www1.ietf.org/mailman/listinfo/gen-art
