Re: Stable state on ASON signaling requirements?

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

Hi Adrian -

Adrian Farrel wrote:

> You're right that developing solutions too far while requirements are not stable is a bad
> thing.
>
> However...
>
> We have had only one comment about the latest version of the requirements draft from the
> WG (in Minneapolis and on the list) suggesting that either the draft is stable or the WG
> doesn't care. (The amount of noise about the solution draft suggests the WG *does* care).

> So, is there any more requirements work to do, or are we at a stable state?

While only one comment may have been specifically logged against the document, the discussion
that has been going on regarding SPCs implicates the requirements document as not being
complete.  If the requirements were complete we wouldn't be debating:
   - call addressing that allows service providers to keep network resource
      names (SNPP and SNP names) and their formats private (3474 handles
      this through TNA addresses, port identifier and egress label)
  - the handling of SPCs through the same Call process as UNI requests
      (which has implications for SPC/UNI interworking issues)

To further amplify the separation of addressing mentioned above -- it is not the same as what
is discussed in the VPN draft.  What the VPN draft provides is a way for a customer's address
space to be held separate from a single, global network address space.  The separation
required by G.8080 goes further by allowing that the network address space within a network
domain be private to that domain.  This means that a different network domains may have
network address spaces that:
 - use different formats (potentially necessitated by the protocols being used in that
domain)
 - reuses network address used in a different domain, but with different meaning
This is not discussed in the current document.

Finally, it may be best to liaise the requirements document to SG12/15 for their review prior
to declaring it "stable state" and taking on solutions in the working group.  It is certainly
possible that other subtle nuances of G.8080 have not been properly captured in the
requirements document.

Jonathan Sadler



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