RE: ASON reqts

["Brungard, Deborah A, ALABS" <dbrungard@att.com>]

Hi Steve,

Thanks for asking specifically..

RFC3473 is to support multi-layer equipment. IP-subnetworks? Generic transport networks using ASON extensions? Using G8080 terminology, RFC3473 supports a control domain (multi-(transport)layer /multi-vendor) based on GMPLS (i.e. uses IP addressing).

G7713.2 as you are noting (and Jonathan's mail) is using a subset of GMPLS signaling. It is not based on GMPLS i.e. it uses a different addressing scheme ( based on OIF addresses, not based on IP). 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.

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".

If you think G7713.2 meets the requirements for extending RFC3473, contribute it. 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.

Deborah



-----Original Message-----
From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
Sent: Wednesday, May 14, 2003 10:04 AM
To: Brungard, Deborah A, ALABS
Cc: Wijnen, Bert (Bert); Bart.Rousseau@alcatel.be; ccamp@ops.ietf.org
Subject: Re: ASON reqts


Deborah,
I am a little confused here:
We have two versions of the protocol:
- Base GMPLS, developed to the requirements for controlling TDM, WDM layers
  that are used below the packet layer(s) in IP networks.
- GMPLS plus ASON extensions, developed to also address requirements of
  general (not necessarily IP) transport networks.
What I think you are suggesting is to address how these versions of the
protocol interwork. The primary case that I can envision is the following:
- IP subnetworks using base GMPLS, interconnected across generic transport
  networks using ASON extensions. With the IP subnetworks on the edge and
  the generic transport in the middle, I think there is no problem with
  the current protocols.
But what you seem to suggest is the following:
- Subnetworks using ASON extensions interconnected across a core using
  only base GMPLS.
This case seems a little farfetched - that you would interconnect subnetworks
that support a combination of circuit and packet traffic across a base GMPLS
only (non-circuit traffic aware?) core. Lets make sure this is a real network
configuration before we undertake an effort to change the protocols to support
it.
Regards,
Steve

"Brungard, Deborah A, ALABS" wrote:
> 
> Hi Bert,
> 
> Can you provide clarification on your email?
> 
> - the January ASON email exchange and the previous ITU-T liaisons clearly identified RFC-3471 and RFC-3473 lacked ASON support. The two ason drafts submitted are to initiate this work.
> - majority of the email supports the reqs draft becoming a WG document. And hopefully, those concerned will also support as WG document based on the understanding a WG doc is a work in progress as posted by one email:
> > There are a few issues that I don't quite understand and/or need
> > clarification on, but the current vote is WG acceptance, not last-call.
> > I have no issues with it that would keep it out from the WG.
> 
> Most of the email is on clarifying G7713.2 and the rsvp-te-ason draft. This draft addresses a totally different application/solution than G7713.2. The rsvp-te-ason draft covers the necessary extensions to RFC-3473 to support ASON for a GMPLS network. The difference of this draft and G7713.2 is that this draft is backward and forward compatible for GMPLS networks; i.e. transit nodes (ITU term: Internal Protocol Controller (I-PC)) do not need to be updated.  G7713.2 is an E-NNI which is using GMPLS but it is not based on GMPLS e.g. G7713.2 does not provide call and connection functional separation because it was not based on use with an RFC-3473 network. Eve's mail clarifies this regarding the domain definitions. If the draft is confusing in this regard, we can work on the wording.
> 
> The draft is on extending RFC-3473 to support ASON. If IETF does not extend RFC-3473, then GMPLS will not support ASON. This work is totally independent of the existence of G7713.2. As we discuss the draft, we can clarify if this is confusing.
> 
> Deborah
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Tuesday, May 13, 2003 10:38 AM
> To: Bart.Rousseau@alcatel.be
> Cc: ccamp@ops.ietf.org
> Subject: RE: ASON reqts
> 
> AD-hat on.
> 
> Bart writes:
> >
> >
> > Stephen,
> >
> > I think the point was rather to go back to
> > just a single GMPLS spec instead of two (let alone three) variants...
> >
> If that is the case, and if we want to do that in IETF CCAMP
> (not sure it is part of the current CCAMP charter),
> then it seems to me that we (CCAMP) should excercise these steps:
> 
> - send some liason to ITU-T SG 15 to explain that we found that
>   there seems to be a GMPLS (for IETF) and a GMPLS-ASON standard
> - that we think that this is NOT goodness, and that we regret that
>   we did send the ASON people away a few years back and did not
>   closely follow their work in ITU
> - that we now believe that we should have worked better together,
> - that we would like to explore ways to try and mrege the two
>   solution back into one common solution
> 
> And then await the response and hope ITU will agree and then see
> how the work can be organized.
> 
> >
> > Bart
> >
> Bert