[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [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