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

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

Hi,

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

Since I'm an author I will sit out of the drafting process at this point and will run
wholly as a co-chair. If anyone has an issue with that, please speak up and Kireeti will
step in.

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-reqts


> draft-ietf-ccamp-gmpls-ason-reqts:
> ---------------------------------
>
> Section 2: conventions.
>
>  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.
>  For example:
>
> > 3. Introduction
> ...
> >    This document concentrates on requirements related to the signaling
> >    aspects of the GMPLS suite of protocols. It discusses functional
> >    requirements required to support Automatically Switched Optical
> >    Networks that MAY lead to additional extensions to GMPLS signaling
>                    ^^^
> >    (see [RFC 3471] and [RFC 3473]) to support these capabilities.
>
> or:
>
> >                                          It MUST NOT be assumed that
>                                               ^^^^^^^^
> >    there is a one-to-one relationship of control plane interfaces and
> >    transport plane (physical) links, or that there is a one-to-one
> >    relationship of control plane entities and transport plane entities,
> >    or that there is a one-to-one relationship of control plane
> >    identifiers for transport plane resources.
>
>   On the other hand, for instance, section 4 does not have these words
>   capitalized:
>
> > 4.2 Support for Call and Connection Separation
> ...
> >    To support the introduction of the call concept, GMPLS signaling
> >    should include a call identification mechanism and allow for end-to-
>      ^^^^^^
> >    end call capability exchange.
>
>
>   Please go through the document and make sure cases like these are corrected.

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.

>   Some notes on the contents of the document:
>
> >   Section 4.4:
> ...
> >    - Any control plane failure must not result in releasing established
> >      calls and connections (including the corresponding transport plane
> >      connections).
>
>   Does "any control plane failure" include fatal and unrecoverable ones?
>   Does it only include single failure, or double/multiple failures also?
>   These are important questions to answer, especially in comparison with
>   the assumptions behind IETF graceful restart work.

I have discussed with Alex that "any" was intended in the full meaning of the word.
If you can think of a way to emphasise this point, that would be good.
We don't want to try to produce an inclusive list of all failure conditions, but there may
be a short list of categories?

I have asked Alex to clarify his point about graceful restart.

It might help to be a bit more explicit about the requirement here. I.e. "It must be
possible to hold a transport plane connection (LSP) up despite control plane or transport
plane failures unless explicitly torn down."

> > 4.6 Support for Crankback
> ...
> >    - Rerouting attempts limitation: to prevent an endless repetition of
> >      connection setup attempts (using crankback information), the
> >      number of retries should be strictly limited. The maximum number
> >      of crankback rerouting attempts allowed can be limited per
> >      connection, per node, per area or even per administrative domain.
>
> It is not clear what is meant here for the per-area/domain case.
>
> Is it the sum of rerouting attempts that all nodes in an area can make (which
> would require some sort of distributed coordination mechanism) or the number of
> attempts that the connection initiator can make through a specific area?

We need to clarify this text to indicate that in all cases, it is the number of attempts
that can be made *at* a spatial coordinate.

> Section 9: 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?

I don't think there is anything to be done. However, I notice that G.8080 is listed as a
normative reference. Given the difficulty in accessing this document, it should be moved
to the informational references section.

Thanks,
Adrian