[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IP-Optical] RE: GMPLS Last Calls
Eve,
There are today lot of design teams at the TE WG, PPVPN etc.
Do you speak here about the ones being proposed at the TE WG
on "network survivability" and "hierarchical TE" ? I think
that some additional information would be useful to understand
to which one you refer here.
Thanks,
Dimitri.
Eve Varma wrote:
>
> Hi Dimitri,
> Sorry - missed your first question. I was not referring to an NNI
> OIF team; I was referring to the IETF team being formed.
> 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