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

[Kireeti Kompella <kireeti@juniper.net>]

Hi Lyndon,

On Fri, 12 Dec 2003, Ong, Lyndon wrote:

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

Yes, indeed!  Thanks for the comments -- I'll incorporate them into
the liaison.  See inline for more details.

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

Well, the messages are obsolescent as far as 7713.2 is concerned.
Furthermore, the text that I read (might be an older version) said
that ResvErrs and ResvTears are converted to PathTear/PathErr.  That
is a major structural change to RSVP (RFC 2205).

I'll replace 'deprecates' with 'removes'.

> A description of the compatibility issues would be a great start.
>
> [LYO] Can we add this to the liaison?

Okay.

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

"Compatibility" in the ITU model requires an interworking node -- that
is hardly compatibility.  There was a (now expired) draft on
CR-LDP-to-RSVP interworking -- does that mean CR-LDP and RSVP are
"compatible"?

For example, the fundamental notion of session changes from the ASON
nodes to the GMPLS nodes; the destination has to be translated from
the GEN_UNI object to the session destination.  Carrying objects
transparently is the easy part; a lot of other work has to be done so
that the GMPLS nodes can do the right thing.  From a 'how much work
does it take to interwork' point of view, it's possible that CR-LDP is
more compatible to GMPLS than 7713.2 -- at least, there is a simple,
one-to-one mapping of almost all objects.

However, I will add text to the liaison suggesting that Q14/15 clearly
define what compatibility means, and how it can be achieved.

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

But 1884 is a standard.  What is the need to do it again?

I remember how much grief the ITU-T folk gave us when we even talked
about SDH (note that NONE of the GMPLS work ever attempted to redefine
SDH).  Now, the ITU-T has redefined basic notions and messages in
RSVP, and has also defined a new way to carry NSAP addresses.  This is
hardly conducive to a strong, productive relationship.

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

You should reread the ERO processing rules.  And with the multi-region
work coming up, it is even more important that a node know what the
destination is.

I will add text to clarify this.

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

Again with NAT!  Are you suggesting that NAT will be used in a carrier
environment?

In any case, the essential notion doesn't change with NAT: with GMPLS,
the session destination is the connection destination.  If the names
change, they change in concert.  What 7713.2 does is to redefine
session destination to the nexthop, which is already carried in the
HOP object.  This is not NAT, this is a concept alien to RSVP.

As for VPNs, you should read the GMPLS Overlay doc and the GVPN doc.
They describe how VPN addresses are handled.

Kireeti.
-------