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

[Kireeti Kompella <kireeti@juniper.net>]

Hi Lyndon,

On Tue, 9 Dec 2003, Ong, Lyndon wrote:

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

Glad to hear that!  Thanks for your comments.

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

I used the word 'deprecated' in the following sense:

   deprecated

   Said of a program or feature that is considered obsolescent and in
   the process of being phased out, usually in favour of a specified
   replacement. (...)

   Source: The Free On-line Dictionary of Computing,  1993-2003 Denis Howe

If you have an alternative word, that would be fine.

One of the issues is if GMPLS nodes exist in an ASON network, they
may generate ResvErr/ResvTear messages; it is not clear what ASON
RSVP nodes will do with these, and what the result will be.

> Perhaps an example
> of an operational scenario using ResvErr or ResvTear would
> be helpful.

The examples are the latter part of point 1.

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

A description of the compatibility issues would be a great start.

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

While some codepoints are indeed in that range, the semantics are not
really compatible.  Many sub-objects of a GENERALIZED_UNI object do
need to be processed by intermediate hops (see below), especially
since the session destination is to an intermediate hop, not (as with
normal RSVP sessions) to the session endpoint -- this confuses the
notion of 'transit node' and 'end node'.

However, the new SESSION objects are not in the 'pass transparently'
range of codepoints.

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

This is not clear from the text.  But if this is indeed the case, it
seems more confusing.  It's more consistent if the SESSION destination
is always the session endpoint, or always the next hop.  Of these two
choices, the former is preferable, and easily doable.  For example,
the GMPLS UNI document follows this paradigm, and keeps RSVP sessions
consistent with what they've always been.

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

Carrying NSAP addresses within IPv6 has been standardized, and no
translation is needed.  Carrying NSAP addresses as such requires some
(non-standard) mechanism to figure out where this address lies and how
to get there.

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

Since the spec contains NSAP addresses, a compliant implementation
must support some means to resolving NSAP addresses.  Your statement
(ii) is not written anywhere; in any case, ERO expansion may need to
be done many times in many places (e.g., every region boundary).
Finally, ERO processing needs to know where the session ends, and
since every node has to process the ERO, they need to resolve the
destination address.

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

I hope you were not serious about NAT -- GMPLS to the home PC??? :-)
In any case, the fact that addresses have to be translated does not
change the fact that there is a single end-to-end RSVP session.

For VPNs, please see the GMPLS UNI and the GVPN documents.  Please
also see the multi-region LSP document
(draft-ayyangar-inter-region-te-01.txt).  Note that in both those
examples, there is a single RSVP session per connection/connection
segment.  There may be several connection segments for a given
end-to-end connection; this is in-line with G.8080 A.

It's good to get this dialog going.  Let's also get the Liaison done,
so that the rest of SG15 can get up-to-speed.

Kireeti.
-------