Snipped -----Original Message----- From: Lin, Zhi-Wei (Zhi) [mailto:zwlin@lucent.com] Sent: Thursday, January 23, 2003 12:24 AM To: Wijnen, Bert (Bert); Scott Bradner (E-mail); 'iesg@ietf.org'; 'ietf@ietf.org'; 'kireeti@juniper.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.