Subject: RE: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Sun, 25 Apr 2004 21:11:09 -0500

I have a couple of comments:

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?  Is one level (i.e., flat network, no hierarchy at all) OK?  I would much prefer to have the maximum number of required hierarchical levels stated in the draft.

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.

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.

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.

Thanks,
Jerry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Kireeti Kompella
Sent: Wednesday, April 14, 2004 7:46 PM
To: [email-masked]
Subject: Re: FW: I-D
ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt

Hi All,

On Wed, 14 Apr 2004, Brungard, Deborah A, ALABS wrote:

> The ASON Routing Reqts DT has updated the following draft based on
> ITU Q14/15's Liaison and CCAMP mail list comments.
>
> We recommend this document as ready for WG Last Call.

This commences a two-week WG Last Call on the GMPLS ASON routing
requirements.  Last Call ends April 28th, 5pm PDT.  Please send your
comments to the list.

The proposed category is Informational.

Kireeti.
-------

---

From: "zafar ali" <[email-masked]>
Date: Sun, 25 Apr 2004 23:14:07 -0400

Hi Jerry, 

Please see in-line.

Thanks
 
Regards... Zafar

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Ash, Gerald R 
>(Jerry), ALABS
>Sent: Sunday, April 25, 2004 10:11 PM
>To: [email-masked]
>Cc: Ash, Gerald R (Jerry), ALABS
>Subject: RE: FW: I-D 
>"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?  Is one level (i.e., flat 
>network, no hierarchy at all) OK?  I would much prefer to have 
>the maximum number of required hierarchical levels stated in the draft.
>

I would disagree here. The number varies depending on networking scenario.
Furthermore, the problem is that as soon as we start picking a number here,
we tend to imply the solution.  Let's keep it as an attribute of the
networking scenario.

>"- 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 agree completely. I also think complexity greatly over-weight the benefit.

<snip>