[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Last Call Complete: draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt

All,

Looks like last call is done with just Jerry's comments. No comments were received from the IGP or routing area working groups.

Thanks for your thoughts, Jerry. To expand a little upon what Zafar said... 

1. I'm bothered by the statement in Section 3:
"The maximum number of hierarchical RA levels to be supported is
NOT specified (outside the scope)."
Why is it outside the scope, I think there should be some explanation.
Does the number of levels not matter?

I think it does matter, however, we need to reflect the requirements as stated by ITU-T SG15 Question 14 in G.7715. We can't play with those requirements.

Section 6 of G.7715.1 states...
Routing areas contain routing areas that recursively define successive hierarchical routing levels. The number of hierarchical levels to be supported is implementation?specific and outside the scope of this Recommendation.

But note (and as some comfort to us) RAs do not necessarily reflect protocol levels (such as IGP areas) but may represent arbitrary subdivisions of protocol levels such as protection domains.

Is one level (i.e., flat network, no hierarchy at all) OK?

I believe this is in scope, and acceptbale within the requirements.

I would much prefer to have the maximum number of required hierarchical levels stated in the draft.

You and me too. But SG15 determined that such a limit would be arbitrary from their perspective and so they made it out of scope.

2. There is quite a bit of discussion about hierarchy evolution, e.g.,
in Section 3:
"- The requirements support architectural evolution, e.g. a change in
the number of RA levels, as well as aggregation and segmentation of RAs."

This begins to suggest automatic 'insertion/deletion' of hierarchical levels, which I believe is too complex.

I don't believe that there intent to describe the mechanism for insertion/
deletion of levels. In particular, as you point out below, protocols are
not expected to be automatically adaptive to such changes. The
requirement is really that there should be the architectural flexibility.

But I do believe that the intent is to allow levels to be inserted without
major disruption to other levels (in particular those that are not parents
or children).

Again, we are simply picking up a requirement which we cannot control.

However, I find in Section 4.4:
"The routing protocol SHOULD be capable of supporting architectural
evolution in terms of number of hierarchical levels of RAs, as well as aggregation and segmentation of RAs. RA IDs uniqueness within an administrative domain MAY facilitate these operations. The routing protocol is not expected to automatically initiate and/or execute these
operations."

It is the final "not" that says that automatic insertion/deletion is not required within the protocol. Perhaps this NOT should be capitalized for emphasis.

New addition to RFC2119? :-)

3. Regarding Adrian's comment on the text I referenced in comment #2:
"The routing protocol is not expected to automatically initiate and/or execute these operations. Reconfiguration of the RA hierarchy MAY not
## Surely this is MUST?
disrupt calls in progress, though calls being set up may fail to complete, and the call setup service may be unavailable during reconfiguration actions."

I think this should stay a "MAY". In normal hierarchy reconfiguration, calls are going to be disrupted. It is far more complex to insist somehow that the protocol keeps calls in tact during such reconfigurations.

The final version retained "MAY"

Hoping that we are closed on this and can move the draft forwards.

Thanks,
Adrian