RE: ASON reqts

["Varma, Eve L (Eve)" <evarma@lucent.com>]

Please see Steve's email.

Eve

-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 14, 2003 9:56 AM
To: 'Varma, Eve L (Eve)'; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan
Sadler
Cc: ccamp@ops.ietf.org
Subject: RE: ASON reqts


Eve,

I am having trouble parsing your e-mail.

I thought my previous e-mail was stating what was, to use
Yakov's phrase, "obvious to the informed reader".

Thanks,

John

> -----Original Message-----
> From: Varma, Eve L (Eve) [mailto:evarma@lucent.com]
> Sent: Wednesday, May 14, 2003 6:47 AM
> To: John Drake; Varma, Eve L (Eve); 'Ong, Lyndon'; 'Adrian Farrel';
> Jonathan Sadler
> Cc: ccamp@ops.ietf.org
> Subject: RE: ASON reqts
> 
> 
> Hi,
> 
> Then the purpose of the reqts. draft is not explaining ITU-T 
> requirements for
> ASON in an IETF friendly way.
> 
> Eve
> 
> -----Original Message-----
> From: John Drake [mailto:jdrake@calient.net]
> Sent: Wednesday, May 14, 2003 9:42 AM
> To: 'Varma, Eve L (Eve)'; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan
> Sadler
> Cc: ccamp@ops.ietf.org
> Subject: RE: ASON reqts
> 
> 
> Eve,
> 
> Let me try again.  We are talking about the support of ASON in GMPLS
> networks, and
> we are trying to identify the ASON requirements on GMPLS signalling
> (RSVP-TE).  By
> definition, the E-NNI/I-NNI in a GMPLS network will be 
> RSVP-TE (with IP
> addressing).
> If the signalling protocol within a domain is also RSVP-TE 
> then the only
> thing a
> domain boundary node will do is modify the RSVP signalling 
> messages subject
> to local
> policy.
> 
> If the signalling protocol within a domain is not RSVP-TE, 
> then a domain
> boundary
> node for such a domain will have to build an interworking 
> function between
> its
> signalling protocol and RSVP-TE.  This is not within the 
> scope of this work.
> 
> Thanks,
> 
> John
> 
> 
> > -----Original Message-----
> > From: Varma, Eve L (Eve) [mailto:evarma@lucent.com]
> > Sent: Wednesday, May 14, 2003 5:27 AM
> > To: John Drake; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
> > Cc: ccamp@ops.ietf.org
> > Subject: RE: ASON reqts
> > 
> > 
> > Hi,
> > 
> > I strongly disagree.  The concept of control domains is one of the 
> > key elements of G.8080 Am. 1, and support for such is part of the
> > requirements.  This makes no statement re proprietary protocols.
> > 
> > Eve
> > 
> > -----Original Message-----
> > From: John Drake [mailto:jdrake@calient.net]
> > Sent: Tuesday, May 13, 2003 5:36 PM
> > To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler
> > Cc: ccamp@ops.ietf.org
> > Subject: RE: ASON reqts
> > 
> > 
> > Lyndon,
> > 
> > I think it is out of scope.  The only requirement is that a 
> > group of one or
> > more nodes running a proprietary control plane (e.g., OSRP) 
> > must appear to
> > be one or more GMPLS nodes, and this is a requirement on the vendor
> > implementing the proprietary control plane.
> > 
> > Thanks,
> > 
> > John 
> > 
> > > -----Original Message-----
> > > From: Ong, Lyndon [mailto:LyOng@Ciena.com]
> > > Sent: Tuesday, May 13, 2003 2:03 PM
> > > To: 'Adrian Farrel'; Jonathan Sadler
> > > Cc: ccamp@ops.ietf.org; Ong, Lyndon
> > > Subject: RE: ASON reqts
> > > 
> > > 
> > > Hi Folks,
> > > 
> > > I think one aspect that may not come out clearly in the draft
> > > is that ASON defines a concept of "control domains" (which is
> > > included in the terminology section of the draft) and in the
> > > amendment goes on to say that the structure and protocols used
> > > in each domain may be different (e.g., centralized control in
> > > one domain and distributed in another, RSVP in one and non-RSVP
> > > in another).
> > > 
> > > I suggested that this be added to the draft, but we did not
> > > get agreement on this before we decided to send it out, perhaps
> > > because it was considered to be out of scope (?).
> > > 
> > > Cheers,
> > > 
> > > Lyndon
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
>