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

[John Drake <jdrake@calient.net>]

Lyndon,

Something else occured to me.  One of the issues associated with RFC3474 is
that in a network with RFC3473 compliant nodes, a call w/o connection will
be treated by those nodes as a connection setup request and they will
allocate resources to it.

How does your interworking draft address this issue?

Thanks,

John

P.S.  Did you have any thoughts on my other question (below)?

> -----Original Message-----
> From: John Drake 
> Sent: Monday, November 03, 2003 3:56 PM
> To: 'Adrian Farrel'; Ong, Lyndon; 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
> 
> 
> Lyndon,
> 
> I also had a question about the folllowing from Section 3.2:  
> '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.'  Why do you think separate object are 
> required to support this?
> 
> Are you familiar, for example, with 
> draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-04.txt?
> 
> Thanks,
> 
> John
> 
> > -----Original Message-----
> > From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> > Sent: Saturday, November 01, 2003 6:12 PM
> > To: Ong, Lyndon; Jonathan Sadler; Varma, Eve L (Eve);
> > dimitris@us.ibm.com
> > Cc: ccamp@ops.ietf.org
> > Subject: draft-ong-ccamp-3473-3474-iw-00.txt
> > 
> > 
> > Hi,
> > 
> > A couple of quick questions...
> > 
> > Section 3.3 says
> >    As RFC 3473 does not support call and connection separation
> >    or soft permanent connection
> > 
> > But surely RFC 3473 does support soft permanent connections? 
> > There are several techniques,
> > but perhaps the most popular is explicit label control. In 
> > view of this, you need to
> > describe how you map between the two techniques when 
> > transiting between 3473 and 3474
> > network types. (Not just how you carry one technique across 
> > the other type of network, but
> > how you handle the case where the end points are in different 
> > types of network.)
> > 
> > 
> > Section 3.3 also says
> >    c) support for extended restart capabilities
> > and
> >    (c) is a local procedure and has no interworking implications
> > 
> > Are you sure that the Hello interactions and state recovery 
> > between 3473 and 3474 LSRs has
> > no interworking implications?
> > 
> > 
> > 
> > Section 5.4 says
> >    Other objects may be received at the 3474/3473 interface,
> >    esp. the Call_ID and Call_OPS objects defined in RFC 3474.
> >    These are passed transparently across the 3473 domain.
> > 
> > This may be true, but you need to cover the case where the 
> > 3473 domain generates an error
> > (such as PathErr). Presumably the mandatory Call_IS and 
> > Call_OPS are added back in to the
> > message when it reaches the 3474 domain?
> > 
> > 
> > Cheers,
> > Adrian
> > 
> > 
> > 
>