Re: ASON reqts

[Jonathan Sadler <[e-mail]>]

Deborah -

Let me clarify:

"Brungard, Deborah A, ALABS" wrote:

> G7713.2 as you are noting (and Jonathan's mail) is using a subset of GMPLS signaling.

I am unware of making such a statement.  If anything, I see G.7713.2 as a superset of GMPLS signaling as it addresses the gaps that exist relative to ASON requirements.

> It is not based on GMPLS i.e. it uses a different addressing scheme ( based on OIF addresses, not based on IP).

Actually, the issues that I brought up are not based on any addressing implementation offered by the OIF (or any other body), but are based on the implementation-independant requirements stated in G.8080 Amd.1.  Lets focus on the requirements, not the solution.

> G7713.2 requires an interworking function plus upgrades to a RFC 3473 domain. And as G7713.2 states it "focuses on the UNI and E-NNI.. the I-NNI ..is for further study". G7713.2 is not based on any I-NNI.

G7713.2 is a solution that meets the requirements.  The extensions are necessary as the base GMPLS signalling protocol specs don't meet the requirements as-is.

> The rsvp-te-ason draft provides extensions to RFC3473 to support ASON. It is analogous to G7713.1 (for non-ITU, G7713.1 is ASON PNNI-based E-NNI/I-NNI). No one questioned the need for G7713.1 (or that it only supports NSAP addresses for E-NNI). And no one questioned a potential conflict of G7713.1 and G7713.2. And we (ITU) used G7713.1 and our relationship with the ATM Forum as an example of our expectations for working with IETF. It is really confusing to have ITU participants now questioning the need for IETF's work on a "G7713.1".

I'm not certain what your trying to get at here.  The ATM Forum certainly did add Information Elements in order to support ASON services -- and they didn't need to write a new requirements document (with "overlooked" requirements) in the process.

As for G.7713.1 only supporting NSAP addresses at the E-NNI: NSAPs have an Address Format Identifier (AFI) as the first octet that describes the remaining information in the Address.  An AFI exists for IPv6 (AFI 34 -- see ISO/IEC 8348 Amd.1) allowing for IPv6 and IPv4 addresses to be turned in NSAPs.  No separate IE Type is necessary to support IPv4 or IPv6 when NSAP support exists.

G.7713.2 could have done the same thing as G.7713.1 and only supported NSAP addresses.  However, since IPv4, and IPv6 address C-types had already been defined, they were included for backward compatability purposes.

> If you think G7713.2 meets the requirements for extending RFC3473, contribute it.

draft-lin-ccamp-gmpls-ason-rsvpte-00.txt was originally contributed in June 2002.  .01 was contributed in August 2002, and .02 was contributed in Sept 2002...

> The problem statement is "use of GMPLS (RFC3471) to provide call and connection management". The problem statement is aligned with G7713.1 on control domain definition, addressing, and functionality.

Its interesting to see that:
 - G7713.1 includes text and pictures defining control domains and how G.7713.1 fits into the definition,
 - G.7713.1 includes text describing how to support both NSAP and IP addressing
while the proposed ASON requirements draft does not...

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