Re: ASON reqts

[Jonathan Sadler <jonathan.sadler@tellabs.com>]

Adrian -

Some more information on the issues raised previously, and a
couple more missing requirements...

Jonathan Sadler

Adrian Farrel wrote:

> Jonathan,
>
> > Likewise, dropping
> > the items handled in RFC 3474 would requires an active decision to
> > be made by the authors.  The document should include this reasoning.
>
> Perhaps you have an example or two of things in RFC 3474 that are dropped by
> ASON-REQ but are ASON architectural requirements?

In addition to the two in my previous email, here are some more:
  - Explicit support for connection partitioning in different
    administrative domains. (G.8080 Amd.1)
  - Use of transport plane names instead of DCN addresses when
    refering to transport plane resources. (G.8080 Amd.1)

Again, I'm interested in why these and the previously mentioned
two items which were covered in RFC 3474 have not been included in
the ASON-REQ draft.

> > For those unfamiliar with some of the differences, a cursorary review
> > of the G.7713 reveals:
> >   - Discussion of required behavior at E-NNI and UNI reference points
>
> I should say that this is covered in the Problem Statement in section 3
>
>    The ASON control plane specification is meant to be applicable to
>    different transport technologies (e.g., SDH/SONET, OTN) in various
>    networking environments (e.g., inter-carrier, intra-carrier). Also,
>    ASON model distinguishes reference points (representing points of
>    protocol information exchange) defined (1) between an administrative
>    domain and a user (2) between administrative domains and (3) between
>    areas of the same administrative domain and when needed between
>    control components (or simply controllers) within areas. A full
>    description of the ASON terms and relationship between ASON model
>    and GMPLS protocol suite may be found in [IPO-ASON].
>
> Further in section 4
>
>    Note: support of the above functions is independent of any user-to-
>    network interface and is therefore not constrained nor restricted by
>    its implementation specifics (see [ITU-T G.8080] and [ITU-T G.7713])

However, the text above is not a discussion of required
behavior -- its just an acknowledgement that the reference
points exist.

For example, G.8080 defines separation of the address spaces
used by the Network and used by Users.  RFC 3474 provides for this
separation in defining new UNI and E-NNI Address C-types.

The requirements document is remarkably silent on this issue.

> >   - Support for complete Call/Connection separation, including
> >     0-connection calls
>
> Hmmm?
> Are you saying that ASON-REQ doesn't include a discussion of complete
> call/connection separation?
> 4.2 seems to have that covered.

Sorry, I wasn't completely clear.  G.8080 allows for 0-connection
calls -- Section 4.2 of the proposed document does not deal with
this.  RFC 3474 provides a mechanism that allows nodes that have
implemented the CALL_OPS object to handle this case.


============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================