[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stable state on ASON signaling requirements?

jonathan, all, see in-line

Jonathan Sadler wrote:

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. 

imho comments are not logged *against*, they are logged to make
progress within the scope of the wg

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)


would you clarify the functional requirement that is not currently
covered in RFC 3471 that is needed to support this capability and
that is not covered in the ason-requirement doc. ? [hint: support
of TNA/Egress label (which includes the logical port identifier) as
defined in 3474/76 is not really a functional requirement]. In other
words where do you see from the current text that this capability
can not be delivered ?

  - the handling of SPCs through the same Call process as UNI requests
      (which has implications for SPC/UNI interworking issues)


would you please indicate where it has being said that the "null
call" for SPC's and the call for SC's *must* be implemented as
indicated in your statement ? isn't the above an implementation
requirement rather than a functional requirement ?

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)


section 4 intends to address this requirement - ditto:
"  This document provides signalling requirements for G.8080 distributed
   call and connection management based on GMPLS, within a GMPLS based
   control domain and between GMPLS based control domains. It does not
   restrict use of other protocols within a control domain. Interworking
   aspects, including mapping of non-GMPLS protocol signaling requests
   and support of non-GMPLS address formats, are strictly under the
   responsibility of the non-GMPLS control domain, and thus outside the
   scope of this document."

 - reuses network address used in a different domain, but with different meaning
This is not discussed in the current document.


please be more specific concerning the address space to which you
refer and to which meanings you refer ?

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.


this is beyond the scope of the present discussion, liase the doc.
is good thing but it doesn't preclude opening discussion on solutions

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



--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491