The MPLS WG Archive

[Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>]

Hello Eve,

I think there is a section dedicated to the UNI within the
GMPLS Architecture document (see section 7. UNI and NNI)... 
please re-read carefully the document it might be useful 
before the OIF NNI conference-call. This is a demonstration 
of my previous statement: "Today GMPLS specification can be 
accomodated to any UNI/NNI interfaces coming from wherever 
you want"

Kind Regards,
Dimitri. 

Eve Varma wrote:
> 
> Hi Dimitri,
> 
>    Sorry, I'm a bit confused by your response. My input is based upon
> looking at the email flying around. I tried to cite some requirements
> from different sources related to the optical control plane that could
> be used for input, as they have started to be discussed on the mailing
> list.  The GMPLS arch document does mention UNI also, so I think the
> input from the documents related to UNI are also relevant.  Re the BT
> document, you'll have to ask the BT authors.
> 
>                                   Eve
> 
> Dimitri Papadimitriou wrote:
> >
> > 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
begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard