RE: ASON reqts

["Ong, Lyndon" <LyOng@Ciena.com>]

Title: RE: ASON reqts

Hi Folks,

 

Slightly off the topic, but for routing, I think one impact of the control and bearer

plane separation is that the identification of the link (in the transport plane)

is really separate from the identification of the routing controller advertising

the link (in the control plane).  You could also implement the routing controller

as a physically separate system from the transport node, as opposed to being

combined as in an LSR.

 

Cheers,

 

Lyndon

-----Original Message-----
From: Stephen Shew [mailto:sdshew@nortelnetworks.com]
Sent: Friday, May 16, 2003 8:08 AM
To: 'Ash, Gerald R (Jerry), ALABS'; Jonathan Sadler
Cc: ccamp@ops.ietf.org
Subject: RE: ASON reqts

On #4, use of transport plane names is an important part of ASON architecture which separates control from bearer planes.  In G.7713.x we have the following text:

"Addressing of transport resources in the protocol is done by SNPP identifiers.  A pair of these would identify an SNPP link.  SNPP names are defined from transport name spaces (see Section 10, G.8080) and it is important to note that control plane names/addresses are not used for these.  For example, neither routing controller nor connection manager identifiers are used for bearer link names."

This affects things that describe the context of a GMPLS label.  For example, the hop objects in an explicit route.  They need to make sense to the transport plane in the absence of signalling.

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
Sent: Thursday, May 15, 2003 18:52
To: Jonathan Sadler
Cc: Ash, Gerald R (Jerry), ALABS; ccamp@ops.ietf.org
Subject: RE: ASON reqts

Jonathan,

I've looked back over your posts, and have a few comments.

We agree with you that at this stage we should 'focus on the requirements, not the solution'.  Regarding your suggestions on the requirements, so far I think you've suggested 4 additional requirements:

1. Discussion of required behavior at E-NNI and UNI reference points. 2. Support for complete Call/Connection separation, including 0-connection calls 3. Explicit support for connection partitioning in different administrative domains.

4. Use of transport plane names instead of DCN addresses when referring to transport plane resources.

#2 is clear, and we agree to add '0-connection calls' to the requirements I-D.  #1, 3, and 4 aren't very specific/clear, and we'd like some clarification:

#1 What does 'required behavior' mean here?
#3 Connection partitions are not across ADs, perhaps this issue relates to session split across ADs? #4 We're using transport plane names, however GMPLS allows for both, perhaps this is an implementation issue?