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

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

Hi Kireeti,

It's good to be making progress, at least towards some
common understanding.  A few follow-up questions in-line.

Thanks,

Lyndon

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net]
Sent: Wednesday, December 10, 2003 11:08 AM
To: Ong, Lyndon
Cc: ccamp@ops.ietf.org
Subject: RE: Liaison to ITU-T regarding feedback on G.7713.2


Hi Lyndon,

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

[LYO] I don't think the intent in G.7713.2 was to consider the
messages obsolescent, just not applicable to the environment
being addressed.  How about "G.7713.2 specifies that ResvErr
and ResvTear are not used for ASON" instead?

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

[LYO] Can we add this to the liaison?

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

[LYO] It's pretty clear now that the models for compatibility were
different in the two groups - compatibility in the IETF definition
implies that you can insert a new node arbitrarily within an
existing domain without causing a disturbance.  In the ITU model
there are strict boundaries between domains such that the UNI
or E-NNI used to access a domain may differ from what is used
within the domain;  however, it was intended that use of a core
protocol such as GMPLS/RFC 3473 within the domain is unchanged
(except carrying transparent objects).  The UNI and E-NNI Session
C-Types are deliberately chosen to be different so that a UNI
or E-NNI interface can be distinguished from an I-NNI.

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

[LYO] RFC 1884 has a pretty short description of how to carry an
NSAP address, basically it is preceded by "0000001" - the remainder
is labeled to be defined - it seems to me that the address
translation itself would end up being the same process once you
strip off the initial 7 bits.

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

[LYO] Wouldn't ERO expansion rely on the information in the ERO,
rather than the session endpoint?  It seems to me that you should
be able to do such expansion without having to know where the 
session ends, otherwise you are repeating full path calculation.

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

[LYO] I meant NAT for IP use of RSVP, not GMPLS :o)  Hate to think
what a tdm/lambda/fiber NAT would be!  My question was maybe more
precisely what determines single vs. multiple sessions - e.g.,
if the Session object is changed, does this constitute a new
session?  Or is it sufficient that there is a one-to-one mapping
from the old to the new Session contents?  In both NAT and VPN
cases, the contents of the Session object might be changed to
take into account different addressing spaces.