[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: spc connections
Hi Deborah,
I was hoping to avoid interworking for SPC service, esp.
as 3473 does not explicitly support carrying an SPC Label
so there would be no conflict if we used a new object.
It seems to be turning out that people have gone ahead
with something based on an extension/clarification
to 3473 that still needs to be documented (is there at least
running code somewhere?).
It then becomes an interworking issue for the 3473-3474 document.
BTW, I think you're being too simplistic in your analysis
of 7713.2, the main differences are architectural
(multi- vs. single session) rather than implementation.
Cheers,
Lyndon
-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com]
Sent: Tuesday, November 18, 2003 8:26 AM
To: Kireeti Kompella; Ong, Lyndon
Cc: ccamp@ops.ietf.org
Subject: RE: spc connections
Lyndon,
It's been a long thread and I am not sure anymore what we are discussing:
- use of the ERO for SPC? Can you be more specific on your concerns as this is where OIF/ITU chose for a different implementation. We need to understand if it resulted from an unclear description or technical concern (as both Yakov and Kireeti requested).
- use of G7713.2 (3474) as a solution? This is also a needed discussion item to progress the ASON signaling work.
On the use of G7713.2: we all agree it provides a *solution*. The question is - is a G7713.2 network overlay (not to be confused with the GMPLS overlay model) the only solution needed? Or do we need a 3473 solution?
Your 3473/3474 interworking draft and the new appendix added to the draft on GMPLS signalling for ASON both describe the 3473/3474 differences. The key driver for defining new 3474 objects was the implementation decision to support multiple addresses (IPv4, IPv6, NSAP) in the protocol objects (vs. address mapping at ingress/egress (e.g. G7713.1 ASON PNNI's implementation)). Multiple family address resolution/management and support of the new objects are part of 3474 node processing (regardless if one is tunneling a new transparent object as an overlay/terminating or if one is using IP-only addressing).
Operators are well familiar with the tradeoffs of using interworking functions, address mapping, and the operations to support multiple address families. And the use of interworking/overlays vs. a GMPLS backward compatible solution have been viewed as two different solutions to very different applications (for both operators and vendors depending on their network evolution/product support). Are you saying (below) that you view G7713.2 overlays as *one solution* or you view it as the *only one* solution needed?
Deborah