Re: ASON reqts

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

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