Subject: RE: [IP-Optical] RE: GMPLS Last Calls

From: [email-masked]
Date: Tue, 29 May 2001 10:40:17 +0100

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:[email-masked]]
> 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: [email-masked] [mailto:[email-masked]]On
> > Behalf Of George Swallow
> > Sent: Tuesday, May 15, 2001 2:52 AM
> > To: [email-masked]; [email-masked]
> > 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
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical

---

From: Eve Varma <[email-masked]>
Date: Tue, 29 May 2001 13:43:05 -0400

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

---

From: Dimitri Papadimitriou <[email-masked]>
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.

---

From: Eve Varma <[email-masked]>
Date: Tue, 29 May 2001 17:06:15 -0400

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

---

From: Eve Varma <[email-masked]>
Date: Tue, 29 May 2001 17:09:13 -0400

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

---

From: Dimitri Papadimitriou <[email-masked]>
Date: Tue, 29 May 2001 23:24:07 +0200

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.

---

From: Eve Varma <[email-masked]>
Date: Tue, 29 May 2001 17:40:17 -0400

Hi Dimitri,
   Yes - I'm also trying to better understand the scope of the teams.
                         Cheers,
                             Eve

---

From: Dimitri Papadimitriou <[email-masked]>
Date: Tue, 29 May 2001 23:47:28 +0200

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.