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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 Apr 2004 09:59:47 +0100

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 Apr 2004 11:41:39 +0100

Ooops,
I forgot my own last call comments. 

Can the team please incorporate my nits and re-publish?
Thanks,
Adrian