RE: draft-ong-ccamp-3473-3474-iw-00.txt

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

Hi Adrian, John,

Thank you for the comments.  The document is a work in progress
and could certainly use input.  I decided to put some initial responses to
your comments into a single email rather than parcel things out.


First Adrian's issues:

a) SPC services - while 3473 provides some functionality 
associated with SPC such as egress label specification, there
is no explicit definition of SPC service (esp. ASON SPC
service) in either 3471 or 3473.  In fact,
you point out that there are several possible techniques
that could be applied.

3474 defines a specific mechanism for ASON SPC service
using an SPC_Label sub-object.  It has one benefit of marking 
connections explicitly as SPC connections, while explicit label
control does not.  It has the drawback that both ends need to
understand the sub-object, but, then, it's a new service,
so that shouldn't be surprising.

b) Restart - I'll defer to restart experts here.   If there are
issues it would be good to find these out!  I would hope, though,
that GMPLS restart procedures are robust enough that you can add
persistent storage to a system without interfering with the
restart procedure.

BTW, it should be clear to people that 3474 defines an interface
between two nodes, it does not define a nodal characteristic.  It
would be very natural to have a border node with both 3474 and 3473 
interfaces.

c)  Call_ID and Call_OPS - I think you're right, if a 3473 node
sends PathErr, you would need to regenerate Call_ID and Call_OPS
at the interworking point.  More on calls/connections later...


John's issues:

d)  client address space - as I understand it, Hamid's GVPN draft
calls for the PE to support some mapping of the identifiers at the
CE-PE boundary, allowing the CE to use a separate identifier space.
3474 uses a different mechanism, with its own characteristics:
the TNA is allowed to take on formats other than IP address, it
is carried transparently across the intervening subnetworks, and
it is intended to be unique within a carrier domain, more like a
telephone number (whereas the GVPN identifier is local to the
particular GVPN).  Both mechanisms can work, they are aimed at
different applications.

It sounds like some of the mapping functions might be similar,
though.

e)  call without connection - this is frankly an area where there
has not been much implementation as yet and does need more work.

On your specific comment I would expect that a PATH for call without
connection would be addressed at the IP level to a destination that
is 3474-capable and bypass intermediate nodes that are not 3474-capable.
That could avoid the problem of intermediate GMPLS nodes actually allocating
resources.  Also, the specific encoding of Label_Request, Sender_TSpec
and Upstream_Label objects for call without connection is not defined
in 3474 or G.7713.2 so it's not clear what resources if any would end
up being reserved.  One way to approach this might be to identify 
suggested encodings that would cause no resources to be reserved.



Cheers,

Lyndon