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

[Dimitri Papadimitriou <dpapadimitriou@psg.com>]

hi lyndon, see in-line for some additional comments:

Ong, Lyndon wrote:

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

it has the drawback of imposing the support of G_UNI processing 
(containing the SPC_label) where SPC will start/end and thus 
break one of the paradigms being the independence of UNI and NNI 
implementation - also the interworking function should allow for 
asymmetric environment (and not only symmetric as presented),
therefore the SPC_label which is in fact a sub-object including 
two fields an interface_id and a label,  the question becomes 
what happens when the ERO includes only an interface_id (note 
that the same issue arise with the RFC3474 egress label for 
switched connections) 

note that "marking" services is not "advantageous" for intermediate
subnetworks/domains while 3473 end-points can deduce this very 
easily without requiring any explicit marking

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

you may want also to take a look at the appendix of

<http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt>

> 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...
 
additionally there is no "notify" message interworking possible
except if it is explicitly asked to change the ip address within 
the notify request object to be the interworking point

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

this "transparency" is limited due to two major issues:
1. interworking is not necessarily symmetric (there is no reason
   why the other end-point can process the RFC3474 information)
   so each ingress must be aware of the capabilities of the end-
   point in terms of RFC3474 support 
2. whenever applying the IWF, a "TNA lookup" is needed obliging any 
   intermediate node that performs such operations to support all 
   the addressing schemes
3. it is also interesting to know how the ingress core-node will
   be made aware of the reachable TNA's ? 

note also that the topological examples given in the iw i-d are
rather simplistic and one can be sure that at the end the control
plane will end up by performing iw'ing at each node

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

the main issue comparing to the gmpls vpn approach is that the
latter refers to "identifiers" while TNA refers to "Addresses"
allowing the transport of the latter as explained here above is
more complex than the approach proposed in gmpls-vpn which 
performs the translation at the edges of the provider network
- the section 2.2 of the gmpls vpn i-d explains this -

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

then please indicate this more clearly in the introductory 
sections - also section 3.3 gives the impression that 3474
does meet the identified requirements while in fact (if i 
well understand your statement) it does not

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

here the problem is that the for call  w/o connection the use of the
RFC3474 technique is simply not appropriated, the method proposed
here above does not solve the problem in the sense that these specific
values (and corr. processing) aren't supported by the standard RFC 3473 
nodes anyway

ps: i don't see described also the iw for the extended_tunnel id of the
uni/e_nni session objects (C-Type 11/12 and 15/16) that rfc 3474 requires 
when crossing these ref points.

thanks,
- dimitri.

> Cheers,
> 
> Lyndon