RE: spc connections

Title: [전체회신] Re: [ AuA¼E¸½A ] spc connections

Lyndon,

You weren't paying attention to Adrian's e-mail, below:

Lyndon,

Thank you for raising this. There is certainly a lack of clarity in 3473 in this regard,
which is perhaps unfortunate.

In the earlier versions of the GMPLS work, this was made very explicit (sic) because
egress label control was invented before it was generalized to explicit label.

There is some reference to this in RFC3471 (of course, the function was originally
independent of signaling protocol), but no explicit procedures.

This descriptive deficiency has been addressed in draft-ccamp-gmpls-overlay. There is no
change in protocol to enable this function, merely a description of how it all works.

Hope this helps.

Cheers,
Adrian

-----Original Message-----
From: Ong, Lyndon [mailto:LyOng@Ciena.com]
Sent: Friday, November 14, 2003 10:16 AM
To: 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org
Subject: Re: spc connections

Hi Young,

I support your conclusion. With this approach it is also unnecessary to modify the

procedures defined in RFC 3473 for Explicit Label Control, which make sense in their

original use.

Regarding RFC 3476, this was submitted by Bala Rajagopalan, who chairs the Signaling

Working Group of OIF, and was needed for agreement with IETF/IANA on codepoint assignments

in RSVP and LDP for the OIF UNI interface. The signaling defined in the OIF UNI is

basically a subset of G.7713.2 and G.7713.3 for the UNI, although the ITU-T specifications

were completed later.

Cheers,

Lyndon

-----Original Message-----
From: yhwkim@etri.re.kr [mailto:yhwkim@etri.re.kr]
Sent: Friday, November 14, 2003 7:18 AM
To: jonathan.sadler@tellabs.com; yhwkim@etri.re.kr
Cc: adrian@olddog.co.uk; Ong, Lyndon; kireeti@juniper.net; ccamp@ops.ietf.org
Subject: [????] Re: [ AuA¼E¸½A ] spc connections

Hi,

I reviewed OIF E-NNI 1.0 document(oif2003.179.00) that includes the definition of SPC_Label.
The following description shows the definition of the SPC_Label.

"This attribute represents the SNP used at the destination network-to-user connection. The SPC SNP ID is locally unique to the destination end and provided to the control plane by an external agent (e.g., the management system that initiated the SPC connection request). Note that in the case of the SPC connection, both source and destination user-to-network connections are provisioned. As such, when setting up a network switched connection to support the SPC service, the destination SNP associated with the provisioned connection needs to be specified to allow the control plane to connect the switched connection to the destination portion of the provisioned connection."

After reading this clause, I bacame to understand the reason that "Generalized_UNI" object included the SPC_Label subobject. Like the definition above, SPC_Label shows the provisioned connection label over UNI portion, not NNI portion.

As such, I think it is right for "Generalized_UNI" object to include the SPC_Label subobject. In addition, by using this subobject and other information(maybe, ERO etc), the destination egress network node could idntify itself to be the last network node and not to invoke connection establishment over UNI interface.

I hope this email conclude the discussion of SPC connections.
And, I'd like to know which WG rfc3476 is an output from because I think it is not a output of ccamp WG.

Thanks,
Young