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
Dimitri, The para from your email as I quoted below or some form of it, explaining or atleast mentioning the independence of the protocol to the model should be included in the text. This will go a long way in future helping the readers in understanding the position of the protocol with reference to the models. Irfan Lateef >You speak about GMPLS profiles for the UNI at the OIF, and potentially >in the future for ASTN/ASON which are completely independent of the >current GMPLS specification (self-consistency). We don't taylor a >protocol suite based on the model to which we have to apply it since >if the model change - you have to re-design your protocol ! -. Today >GMPLS can be accomodated to any UNI/NNI interfaces coming from >wherever you want. Why ? Because from the beginning it is a model >independent specification ! By defining the profile you desire you >can apply it to the OIF UNI / ASON UNI (if still needed) / etc. >From: Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be> >To: Eve Varma <elv@hotair.hobl.lucent.com> >CC: ccamp@ops.ietf.org, mpls@UU.NET, ip-optical@lists.bell-labs.com, >tsg15q11@itu.int, t1x15@t1.org >Subject: Re: [IP-Optical] RE: GMPLS Last Calls >Date: Tue, 29 May 2001 22:40:31 +0200 > >Hi, > >In this e-mail you speak about a "Requirements Design Team" >do you refer to the NNI OIF project here i guess ? > >I wouldn't like to (re-)explain here the nice "reception" offered >during the San Diego IETF meeting on the BT draft. Moreover, what's >sound very strange here is that the author himself didn't present >his draft during the last IETF meeting (since there was a -01 version)! >Are you serious when you speak about ASON UNI requirements at the >IETF ? > >You speak about GMPLS profiles for the UNI at the OIF, and potentially >in the future for ASTN/ASON which are completely independent of the >current GMPLS specification (self-consistency). We don't taylor a >protocol suite based on the model to which we have to apply it since >if the model change - you have to re-design your protocol ! -. Today >GMPLS can be accomodated to any UNI/NNI interfaces coming from >wherever you want. Why ? Because from the beginning it is a model >independent specification ! By defining the profile you desire you >can apply it to the OIF UNI / ASON UNI (if still needed) / etc. Also, >don't spend to many time at the OIF to define the architecture it is >already done... > >Now you mention one question which is under discussion about the >correlation between the planes... the good point is that with the >current work done at the IETF and OIF a solution will be found. >However this does not mean AT ALL that the current GMPLS >specifications are not going toward a very good direction. Therefore >i don't think we need the additional text as you propose. In fact this >is clearly an extended problem of the "restoration" issue already >discussed on this mailing list and we already agree upon. > >Thanks, >- Dimitri. > >Eve Varma wrote: > > > > 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 > > > > _______________________________________________ > > IP-Optical mailing list > > IP-Optical@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/ip-optical ><< dimitri.papadimitriou.vcf >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com |
|