Snipped
-----Original Message-----
From: Lin, Zhi-Wei (Zhi) [mailto:zwlin(_at_)lucent(_dot_)com]
Sent: Thursday, January 23, 2003 12:24 AM
To: Wijnen, Bert (Bert); Scott Bradner (E-mail); 'iesg(_at_)ietf(_dot_)org';
'ietf(_at_)ietf(_dot_)org'; 'kireeti(_at_)juniper(_dot_)net'
Cc: Lam, Hing-Kam (Kam); Malcolm Betts (E-mail); Stephen Shew (E-mail);
Lyndon Ong (E-mail); Alan McGuire (E-mail); Trowbridge, Stephen J
(Steve)
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational
<zhi> Where do you see that we deprecate ResvErr and ResvTear? (for the
record: these are not deprecated)
Where do you see that we deprecate FILTER_SPEC and LABEL objects? (for the
record: these are not deprecated)
Also, where do you see that we wish to identify the RSVP session endpoints
with GENERALIZED_UNI? (for the record: the RSVP session is still SESSION
object)
</zhi>
============================================================================
====================================
JD: I've obviously misread the follwing text:
"Note that from the perspective of the ASON model ResvErr and ResvTear
messages are not used. For backwards compatibility, when an ASON-compliant
GMPLS node receives either a ResvErr or ResvTear as a response during the
setup phase of message exchange, the GMPLS-ASON node should instead issue a
PathTear message downstream and a PathErr (with Path_State_Removed flag set)
message upstream. This is so that RSVP states are immediately removed upon
error during the setup process."
"... the SPC services support for the ASON model uses the GENERALIZED_UNI
object for this extension to help align the model for both switched
connection and soft permanent connection, as well as to use the service
level and diversity attributes of the GENERALIZED_UNI object"
"Note that although the GENERALIZED_UNI and CALL_ID objects are optional for
GMPLS signaling, these objects are mandatory for ASON-compliant networks,
i.e., the Path message MUST include both GENERALIZED_UNI and CALL_ID
objects."
"Note that LABEL_REQUEST, SENDER_TSPEC and UPSTREAM_LABEL are not required
for a call; however these are mandatory objects. As such, for backwards
compatibility purposes processing of these objects for a call follows the
following rules:
- These objects are ignored on receipt; however, a valid-formatted
object (e.g., by using the received valid object in the
transmitted message) must be included in the generated message."
============================================================================
====================================
<zhi>The statement above about G.709 is irrelevant to the discussion. In
terms of sending G.7713 to IETF and asking to develop protocol...that's what
was done. Back on 2001 discussions were started on what requirements and
architectures are needed to support G.8080. Individuals (who happens to
participate in both IETF and ITU) then started submitting protocol
extensions. People either choose to ignore these or expressed opposition to
making these extensions simply because it went beyond the traditional IP
services.</zhi>
JD: What you saying is not the same as what I am saying. I am asking for
G.7713 to be sent as a formal liason to the IETF (CCAMP). I am not asking
for individuals' interpretations of ITU specs.
<zhi>Existing mechanisms we mentioned may be used, but the preference would
be to use GEN_UNI for SPC (and this is in fact what we use for the ASON
specification). This is because (again) of the architecture assumptions made
in G.8080. An ASON network is assumed to be composed of multiple domains. In
the vision of a global ASON network you might have multiple carriers
connecting together (but also multiple domains within a single carrier
network). The interfaces defined for these inter-domain signaling is the
E-NNI interface. However, across an E-NNI the ERO object is an optional
object, and in certain instances the information may not be passed due to
policies that carriers may impose on the inter-domain interface.
If we were to use the ERO to carry the SPC information, then conceivably
there are cases where this information would not pass the interface.</zhi>
JD: What standards body has defined the E-NNI?
<zhi>I hope this helps to explain the issues expressed by John (of course I
expected John to understand call/connection as he was a member of ATM Forum
in developing the PNNI specification...)
JD: During my time at the ATM Forum we were never able to get
call/connection to work.