The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [IP-Optical] RE: GMPLS Last Calls
I agree fully with the proposed text in "" in Eve's suggestion below John Eaves TyCom (US) Labs -----Original Message----- From: Eve Varma [mailto:evarma@lucent.com] Sent: Tuesday, May 29, 2001 1:43 PM To: ccamp@ops.ietf.org; mpls@UU.NET; ip-optical@lists.bell-labs.com Cc: tsg15q11@itu.int; t1x15@t1.org Subject: Re: [IP-Optical] RE: GMPLS Last Calls Hi all, Watching the various emails regarding the GMPLS drafts, I see several issues being raised related to some concerns that service provider requirements haven't been sufficiently reflected in the GMPLS signaling specifications - or at least, not been tested against. (An initial set of requirements was provided by BT on Considerations on the development of an Optical Control Plane - http://search.ietf.org/internet-drafts/draft-freeland-octrl-cons-01.txt. Monica has mentioned other currently available sources of service provider requirements as well, such as the Carriers Optical Services Framework and Associated Requirements for the UNI, developed in the OIF and submitted to T1 and ITU-T. Some requirements were also submitted earlier in the draft Requirements on the ASON UNI - http://search.ietf.org/internet-drafts/draft-lin-mpls-ipo-ason-uni-00.txt. ) For example, assuring separation of the control plane from the data plane continues to arise - the GMPLS architecture document mentions this separation, but it's not clear how the GMPLS signaling specifications reflect the implications of this decoupling. This is best illustrated in the handling of control plane failures. In particular, what happens to established circuit connections if the control plane fails? If the control plane recovers, how do we sync the connection state? As an example, from RSVP RFC: "RSVP takes a "soft state" approach to managing the reservation state in routers and hosts. RSVP soft state is created and periodically refreshed by Path and Resv messages. The state is deleted if no matching refresh messages arrive before the expiration of a "cleanup timeout" interval." This means that if for whatever reason control messages are lost, the associated data paths will be released. Thus there is strong failure correlation between the control plane and data plane, which is inconsistent with the GMPLS architecture document, and also results in tearing down optical connections resulting from even temporary failures in the control plane. I also understand the other comments from Hirokazu and Shehzad re exclusion of NSAP, having been at the last OIF meeting where there was considerable and spirited discussion of this issue. The current GMPLS architecture document specifically excludes NSAP, and from the last OIF meeting 6 out of 12 operators discussing this issue felt there was some need to support NSAP addressing. Given that the Requirements Design Team will be starting shortly, I concur with Yuri's suggestion for inclusion of a clear statement of what is - and isn't - covered in the GMPLS Signaling Description, RSVP Extensions, LDP Extensions drafts. A suggestion for such text is provided below (the intro will need to be tailored to each draft): "Overall, the objective of Generalized MPLS is to adapt MPLS signaling and other protocols to enable their applicability to various switching technologies. A key motivating application has been applicability to support a distributed control plane for various circuit-switching technologies. The signaling specifications contained within the these drafts offer a starting point towards this goal; their current scope and applicability, and areas for further assessment, are summarized below: These drafts provide some extensions to traditional MPLS signaling and the basic signaling mechanisms provided in RSVP and LDP Ids (RFCs and standard track documents) have not been modified. It is noted that MPLS signaling has been designed with a focus upon packet-switched network based applications, utilizing requirements and architectural constructs suitable for such applications. There may be significant distinguishing characteristics with regard to requirements and architectural considerations for a distributed control plane that supports circuit-switched network applications. One well acknowledged instance involves the decoupling of the control plane from the data plane. Such differences may have substantive impact on the signaling mechanisms, the details of which require further study. In addition, upon further study of operational requirements and circuit-switching technology specific aspects, further signaling extensions may be required. These drafts are focussed upon intra-area signaling interfaces, and do not address issues and considerations related to other domains of usage. Applicability to inter-area and inter-domain interfaces requires further study." Hope this helps us move forward. Cheers, Eve itu shehzad.mirza@bt.com wrote: > > Hi, > > I fully agree with Hirokokazu Ishimatsu's concerns on the GMPLS signalling > drafts. > > (1) Decoupling of the control plane from the data plane should be clearly > stated. > > This decoupling clearly has an impact on how the protocols should be defined > to cope with control plane failures. > > (2) Exclusion of NSAP > > The GMPLS architecture document, (which logically speaking should perhaps > have been put forward for last call, ahead of the functional description) > explicitly excludes NSAP. NSAP addressing is used within SDH/SONET > communications channels (DCC bytes) therefore the use of alternative > addressing within the same channels may have an adverse effect on > interworking with legacy equipment, particularly with regard to management. > This raises the general concern of what level of compatibility is > required/desired with legacy SDH/SONET equipment. This debate whilst likely > to be contentious, is unavoidable as the interworking of control plane, > management plane and transport will have a direct impact on how this > equipment is deployed and the economics of whether such deployments will > ever pay off. > > (3) Requirements from both security and OSS has not been discussed fully > yet. > > Security concerns have not been fully addressed, particularly at the > architectural level. The use of separate control network may necessitate > the need for 24 hour staff to protect against 'Denial of Service' attacks as > currently happens for IP router networks. The interaction between the > management plane and control plane need to be addressed, for example it is > undesirable to have multiple alarms generated when circuits are created and > torn down otherwise the management of a large scale network will become > impossible. Discussions on service aspects need to take place, otherwise > the adoption of GMPLS equipment may be hampered, by these (solvable) > concerns. > > Best regards > > Shehzad Mirza > > > > > -----Original Message----- > > From: Hirokazu Ishimatsu [SMTP:hirokazu@japan-telecom.co.jp] > > Sent: 29 May 2001 02:46 > > To: George Swallow; ccamp; mpls > > Cc: ip-optical; tsg15q11; tsg13q10 > > Subject: [IP-Optical] RE: GMPLS Last Calls > > > > Hi, > > > > From a carrier's perspective, my concerns about GMPLS signaling drafts > > are as follows: > > > > (1) Decoupling of the control plane from the data plane should be clearly > > stated. > > (2) Exclusion of NSAP > > (3) Requirements from both security and OSS (Operating Support System) > > has not been discussed fully yet. > > > > Best regards, > > Hirokazu Ishimatsu > > Japan Telecom > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of George Swallow > > > Sent: Tuesday, May 15, 2001 2:52 AM > > > To: ccamp@ops.ietf.org; mpls@uu.net > > > Subject: GMPLS Last Calls > > > > > > > > > This message initiates a last call on four GMPLS drafts. The last > > > call is being issued jointly in the MPLS and CCAMP workgroups. > > > > > > The drafts are: > > > > > > 1. Generalized MPLS - Signaling Functional Description > > > > > > <draft-ietf-mpls-generalized-signaling-04.txt> > > > > > > > > > 2. Generalized MPLS Signaling - RSVP-TE Extensions > > > > > > <draft-ietf-mpls-generalized-rsvp-te-03.txt> > > > > > > > > > 3. Generalized MPLS Signaling - CR-LDP Extensions > > > > > > <draft-ietf-mpls-generalized-cr-ldp-03.txt> > > > > > > > > > 4. GMPLS Extensions for SONET and SDH Control > > > > > > <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt> > > > > > > > > > The last call closes May 29, 12 pm GMT. > > > > > > > > > - V2KG (Vijay, Vijay, Kireeti, & George) > > > > > > > > > ====================================================================== > > > George Swallow Cisco Systems (978) 244-8143 > > > 250 Apollo Drive > > > Chelmsford, Ma 01824 > > > > > > > > > > > > > > > > > > > _______________________________________________ > > IP-Optical mailing list > > IP-Optical@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/ip-optical > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical |
|