Fw: AD-review comments on draft-ietf-ccamp-gmpls-ason-routing-reqts

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

The AD (Alex) has now had a chance to go through the ASON routing requirements draft and
has a few comments we need to fix before the draft can go forward to the IESG.

Process:
- Please look at the comments with my notes, below, and
  if there is any debate have it with me on the list (cc Alex).
- Please produce a new version of the draft BUT do not
  submit it.
- Bring the draft to me and persuade me that it addresses
   all of Alex's points.
- Submit the draft.

Thanks,
Adrian

----- Original Message ----- 
From: "Alex Zinin" <zinin@psg.com>
To: "Kireeti Kompella" <kireeti@juniper.net>; "Adrian Farrel" <adrian@olddog.co.uk>
Sent: Friday, June 04, 2004 7:14 PM
Subject: AD-review comments on draft-ietf-ccamp-gmpls-ason-routing-reqts


> draft-ietf-ccamp-gmpls-ason-routing-reqts:
> ------------------------------------------
>
> The list of authors is too long according to the recent RFC Editor policies.

The issue is only the title page.
I suggest you show one Editor (Deborah?) and list the authors in the
authors' section as currently.
You could list the DT in section 1 to give them full prominence.

>  Since 2119 talks about protocol specifications and implementations, a note
>  along the following lines would be helpful:
>
>   "While [2119] describes interpretations of these key words in terms of
>    protocol specifications and implementations, they are used in this document
>    to describe design requirements for protocol extensions."
>
>  Regarding MAY/SHOULD/MUST themselves. The way these key words are used in
>  the document is not consistent. One would assume that they would be used
>  to specify what features or functionality would need to be supported.
>  However, in certain places, the way they are used is questionable.

I suggest you add Alex's text in section 2.
You'll just have to grep the doc for MAY/SHOULD/MUST and try to be consistent. In
particular, don't use capitalisation for emphasis, but only for specific requirements.

> Comments on specific parts of the text:
>
> > 4. ASON Routing Architecture and Requirements
> ...
> >    The failure of a RC, or the failure of communications between RCs,
> >    and the subsequent recovery from the failure condition MUST NOT
> >    disrupt calls in progress and their associated connections. Calls
>              ^^^^^^^^^^^^^^^^^
>
> it took a while to realize that what's meant here wasn't calls in the process of
> being established, but those already established. Some wording changes might
> help here.

Suggest you add a clarification "(i.e. already established.)"

> > 4.2 Hierarchical Routing Information Dissemination
> ...
> >                                             If routing information is
> >    exchanged between a RC, its parent, and its child RCs, it SHOULD
> >    include reachability and MAY include (upon policy decision) node and
> >    link topology. Communication between RAs only takes place between
> >    RCs with a parent/child relationship.
>
> the definition of "reachability" has been given at this point and the reader
> wonders what it is.

Yes. This is worth defining since it is a key requirement.

> >    Multiple RCs bound to the same RA MAY transform (filter, summarize,
> >    etc.) and then forward information to RCs at different levels.
> >    However in this case the resulting information at the receiving
> >    level must be self-consistent; this MAY be achieved using a number
> >    of mechanisms.
>
> it would be useful to explain what "self-consistent" means in this
> context.

Yes.

> >    3. Method of Communication
> >
> >       Two approaches exist for communication between Level N and N+1.
> >
> >       - The first approach places an instance of a Level N routing
> >         function and an instance of a Level N+1 routing function in the
> >         same system. The communications interface is within a single
> >         system and is thus not an open interface subject to
> >         standardization.
>
> This is right in a sense that one doesn't have to define how to _take_ info
> level N for later announcement to N+1. However, certain aspects of such
> reannouncement or leaking will have to be done in a consistent manner to ensure
> interoperability and basic protocol correctness (e.g., cost/metric value).

Alex seems to be saying that we need to standardise *what* information is exchanged and
how it is used in the
other level. We do not need to standardise *how* that exchange takes place.

> > 4.5 Routing Attributes
> >
> >    Routing for transport networks is performed on a per layer basis,
> >    where the routing paradigms MAY differ among layers and within a
> >    layer. Not all equipment supports the same set of transport layers
> >    or the same degree of connection flexibility at any given layer. A
> >    server layer trail may support various clients, involving different
> >    adaptation functions. Additionally, equipment may support variable
> >    adaptation functionality, whereby a single server layer trail
> >    dynamically supports different multiplexing structures. As a result,
> >    routing information MAY include layer specific, layer independent,
> >    and client/server adaptation information.
>
> The notions of "server", "layer", "server layer trail", "client", etc. haven't
> been defined and are completely foreign for a usual IETF reader.

Ah! Terminology creep. I think you can add these to appendix 1.

> > 4.5.3 Node Attributes
> >
> >    All nodes belong to a RA, hence, the RA ID can be considered an
> >    attribute of all nodes. Given that no distinction is made between
> >    abstract nodes and those that cannot be decomposed any further, the
> >    same attributes MAY be used for their advertisement. In the
> >    following tables, Capability refers to the level of support required
> >    in the realization of a link state routing protocol, whereas Usage
> >    refers to the degree of operational and implementation flexibility.
>
> The last sentence doesn't really help understanding what "Usage" below is used
> for from the protocol design perspective. Please clarify.

Yes.

> >    The following Node Attributes are defined:
> >
> >        Attribute        Capability      Usage
> >        -----------      -----------     ---------
> >
> > 4.5.4 Link Attributes
> >
> >    The following Link Attributes are defined:
> >
> >        Link Attribute                   Capability      Usage
> >        ---------------                  -----------     ---------
> >        Local SNPP link ID               REQUIRED        REQUIRED
> >        Remote SNPP link ID              REQUIRED        REQUIRED
> >        Layer Specific Characteristics   see Table 3
> >
> >                          Table 2. Link Attributes
> >
> >    The SNPP link ID MUST be sufficient to uniquely identify the
> >    corresponding transport plane resource taking into account
>
> Is it in conjunction with the Node ID?

Just need to clarify the scope of "uniquely".

> > 5. Security Considerations
> >
> >    ASON routing protocol MUST deliver the operational security
> >    objectives where required.
>
> What are they?

:-)

My fault. I should not have let you get this far without a better security section.

> References.
>
> Is it possible to easily access the ITU-T documents referenced?
> Can URLs be included?

I have told Alex that this is unlikely.
Does anyone know of any way to make theses references available?

Cheers,
Adrian