RE: Liaison to ITU-T regarding feedback on G.7713.2

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

Hi Kireeti,

This is a really good start, I think this is far
more detailed information than has been sent to
ITU before.

A few questions and comments:

a) G.7713.2 does not actually say that ResvErr and ResvTear
are deprecated, although it does say that these are not used for
G.7713.2-based signaling.  The implication (to be investigated)
is that the cases using ResvErr and ResvTear do not come up
within the networks that ASON addresses.  Perhaps an example
of an operational scenario using ResvErr or ResvTear would
be helpful.

b) I think comments 2 and 3 need some further clarification - G.7713.2 
cannot specify the procedures for processing of new objects
by an RFC 3473 entity, since RFC 3473 already has its own
procedures for processing of unrecognized objects.  It's 
not clear what procedures you are asking to be added to
G.7713.2 as a result (maybe a description of the backward
compatibility issues?).

I believe the codepoints requested for the new objects in
G.7713.2 are in the range that are to be passed transparently
by transit nodes that do not recognize them, using the 
standard procedures documented by IANA.

c) On comment 4, the G.7713.2 Session object will contain the
address of the next hop only at borders such as the UNI or E-NNI,
not in all cases.

d) On comment 6, I wonder if there is some inconsistency in
saying that NSAP can be supported within IPv6 and at the same 
time saying that multi-address family resolution should not
be supported (since it appears to be possible even within
IPv6 according to the comment).

Also, we really need to understand the issue of why people 
believe the EVERY entity must support multi-address family
resolution - my prior assumption was that (i) this depends
on what the carrier wants to support as a UNI Transport 
Resource Identifier and (ii) resolution occurs once, at the
ingress, and thereafter you use the ERO.

e) On comment 8, it may be premature to conclude that 
multiple sessions per connection or connection segment are
incompatible with the definition of RSVP - how does this
with RSVP when used with NATs or VPN?  In cases of 
address mapping you may need to swap the contents of the Session
object, since the original endpoint address may be a private
address.  Doesn't this result also in two linked sessions?

Cheers,

Lyndon

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net]
Sent: Monday, December 08, 2003 4:43 PM
To: ccamp@ops.ietf.org
Subject: Liaison to ITU-T regarding feedback on G.7713.2


Hi All,

We (the CCAMP WG) have been asked to send a Liaison to the ITU-T SG 15
regarding G.7713.2 and GMPLS RSVP-TE.  Here is draft text.  Please
send your comments to the list by 17:00 PST Dec 15.

Thanks!
Kireeti.
-------