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

[John Drake <jdrake@calient.net>]

Comments inline

> -----Original Message-----
> From: Ong, Lyndon [mailto:LyOng@Ciena.com]
> Sent: Friday, November 07, 2003 2:41 PM
> To: 'Adrian Farrel'; Jonathan Sadler; Varma, Eve L (Eve);
> dimitris@us.ibm.com
> Cc: ccamp@ops.ietf.org
> Subject: RE: draft-ong-ccamp-3473-3474-iw-00.txt
> 
> 
> 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.


JD:  You misunderstood.  You made an assertion about a separate 
address object, 'It also allows full overlap of the client address
range with the address range used in the network, since separate
objects are used for each.', that I questioned.  I then offered a
counter example, Hamid's I-D, to show that this functionality does
NOT require a separate address object.


> 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.


JD:  As described in my previous comment, addresses carried in RSVP
messages in the normal way, e.g., RFC3473 compliant networks, would
have the same characteristics you describe.  (Non IP address support
in a GMPLS ASON network is not required but could be supported in
a variety of ways based upon the techniques described in Hamid's I-D.)
  

> 
> 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.


JD:  I would agree with this statement wrt to RFC 3474/G.7713.2.


> 
> 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.


JD:  This wouldn't work, since you're still instantiating state in all of
the intermediate nodes.  I would agree with your comment that many things
are not defined in RFC 3474/G.7713.2.


> 
> 
> 
> Cheers,
> 
> Lyndon
> 
> 
>