Adrian, et al,
Please see additional comments or expansion, on earlier
comments, below.
...
-->
--> > 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
--> and signal abstract nodes and resources that are to be
--> explicitly excluded from routes.
Yes, I understand the intent. The above was simply set-up text
for the rest of the comment.
My point is - hopefully captured below - that, unlike the ERO
(which is inherently bounded), the XRO is inherently unbounded.
The applications for which it is useful - in my current under-
standing - are relatively simple. Particularly as illustrated
by the SRLG example which - in examples I've seen - typically
involves nothing more than saying "don't choose a path that is
associated with this SRLG."
However, reality is bound to rear its ugly head - for example
when part of a path you want excluded, cannot be identified by
SRLG. I suspect this sort of thing will arise in deployoment,
when not excluding a path selection option results in surprise
misbehavior.
It is also probable - in deployment - that administrators will
be unlikely to remove an exclusion (unless it is necessary to
do so for other reasons) when adding new ones. Hence the net
effect is likely to be accumulative complexity.
As you saw in the remaining comments, what I am looking for is
a bit more text around this issue and some form of "opt-out"
capability that is un-ambiguous.
-->
--> > 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.
-->
This is true, but not relevant to my point.
-->
--> 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.
-->
Having stepped off of the 13th floor balcony and discovering
that he could now see all the way to the asphalt below, our
intrepid young scientist concluded that maybe there is such
a thing as too much clarity.
You're correct that - in practice - you will continue to want
the ERO to be the primary "control knob." Nothing about that
prevents us from making the "other knob" very complicated,
thus making operations difficult for - shall we say - our less
intelligent neighbors.
Nor is there anything about the specification that requires an
ERO as a pre-requisite for an XRO - even if the option of not
having an ERO is not useful in practice (at least as far as we
know - now).
-->
--> > 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.
-->
You don't think recommending a common minimal complexity a
compliant implementation MUST support is necessary in order
to avoid an essential break-down in interoperability?
I suspect that we should require a compliant implementation to
support (at least N - where N might equal 1 - of) the set of
exclusions we know about in some reasonable minimal complexity,
or we can expect that compliant implementations might not agree
on "acceptable complexity."
--> > ------------------------------------------------------------
--> > 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.
-->
Yeah, I know that.
-->
--> 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?
-->
Actually, many of the RSVP objects are aligned similarly to the
way that yours is now, so I would not change it. I wanted to
know if the choice was a deliberate one.
-->
--> > ------------------------------------------------------------
--> > 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.
Great.
-->
--> > ------------------------------------------------------------
--> > 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.
-->
Interesting. :-)
You're making an assumption about implementations that is not
- AFAIK - built into any document. Of course, this is an area
in which I might be confused.
Is it always necessary to expand an ERO at the edge of an Area
(or AS or other domain), or is it accetable to rely on routing
(within a domain) to "do the right thing" locally, using the
unexpanded (or removed) ERO next hop?
I would think that an acceptable "expansion" in crossing an AS
- for example - would be to replace the abstract node for the
AS with a "loose hop" specification of the egress BGP peer.
If expansion MUST occur, then I withdraw my comment.
--> 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.
-->
Is that what you (authors) want? I wasn't sure...
-->
--> > 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.
-->
I think that would help. However, if that is the remedy, it may
be a good idea to say so in the security section.
-->
--> > ============================================================
--> > 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
