Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Tue, 11 Mar 2003 12:59:35 -0500

Hi Gert,

Just to clarify, the separation of calls and connections is useful for SPCs, not just UNI.
So it would not be appropriate to draw a conclusion re disconnects on the assumption that
call/connection separation is all about UNI.

By the way, call/connection separation was also mentioned within the ipo wg document

http://www.ietf.org/internet-drafts/draft-ietf-ipo-carrier-requirements-05.txt

Best regards,
Eve

-----Original Message-----
From: Gert Grammel [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 10:47 AM
To: Lazer, Monica A, ALABS
Cc: [email-masked]; [email-masked];
[email-masked]; Ash, Gerald R (Jerry), ALABS; [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Monica,

there is nothing wrong with improving a solution. The key is to know where to
start and where to go.
You may agree that CCAMP had another starting point than ITU-T/ASON.  However my
feeling is, that even this issue is not really understood by many of the folks
out there. If there is no acceptance that priorities in another SDO is different
from the own one, we won't come to an agreement at any time soon.
Look at the hottest issue under discussion: We are talking a lot about UNI
features like call/connection separation. Neither Mark nor Neil see the UNI
becoming service relevant at any time soon - so why is it under discussion right
now? Is this your priority 1 issue in ITU-T? Is Mark or Neil in a minority
position in ITU-T? Referring to the Yokohama Meeting this was basically
Kireeti's request: Please explain what you need and for what purpose.

What I am trying to achieve is to make the priorities transparent such that
either side can see where is the difference and where is the overlap. Otherwise
we will endlessly continue to discuss about feature requirements and whether
they seem to be relevant or not.

In short I repeat my previous statement using some of your own words:

     In my view, the main issue <snip> is about what is bringing more value
     to a carrier's network:

        * a single Control Plane Paradigm not optimized for a specific
          Layer or
        * a variety of control plane paradigms optimized for specific Layer
          needs

Regards

Gert

"Lazer, Monica A, ALABS" wrote:

> Gert,
> I have some comments, inline, below. The short of it is that I don't
> agree with your perspective.
> In my view, the main issue is not about taking sides in these debates,
> but about what is bringing more value to a carrier's network.
>
> Monica A. Lazer
> Network Architecture and Reliability
>
> 908 234 8462
> [email-masked]
>
> -----Original Message-----
> From: Gert Grammel [mailto:[email-masked]]
> Sent: Monday, March 10, 2003 7:19 AM
> To: Lazer, Monica A, ALABS
> Cc: [email-masked]; [email-masked];
> [email-masked]; Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Monica,
>
> I think there were lots of discussions about what is best for layer XYZ
> and also
> Neil was arguing in this direction. This argumentation is of course
> valid if you
> focus on layer XYZ and look for a (new) control plane. Let's name it a
> classical
> ASON point ov view. What I tried to raise as an issue is, that from a
> CCAMP
> point of view the question is the other way round. You have already a
> control
> plane defined and the question is: how to apply it in the best way to
> layer XYZ?
> There is an issue about what is the main backwards compatibility issue
> here, I guess. From the ccamp perspective, it seems to be compatibility
> with the defined GMPLS work. From the network perspective, however, it
> means compatibility with how the transport network works. It may indeed
> be an issue of priorities.
> So coming back to your argument. You've said correctly:
>
>      ... while when going from HO to LO one is within the same paradigm.
>
> One conclusion could be: you should use the same Control Plane paradigm
> for
> different layers in order to let them interoperate seamlessly. First it
> needs to support each layer!
>  Further more, scalability becomes a very real issue
> To sum up a bit: in my view all the discussion about features of ASON
> and/or
> GMPLS is flawed right from the beginning if it is not clear what should
> be
> achieved:
>
>   1. If you focus on a single paradigm arcoss layers you should consider
> GMPLS
>      with all its features and limitations
> Why must one take things with limitations, what is wrong with
> improvements?
> The control plane focus is on saving operations cost for the given
> layer!
>
>   2. If you are interesting on getting some specialized control planes
> for
>      SDH/SONET you are free to choose anything.
>
> in ITU-T you have the choice, in IETF you have not. Do you really mean
> this?? That seems to be a flawed attitude. Saying that in ietf there is
> no choice, or room for improvements (your point above about accepting
> all its limitations) seems to be a serious judgment call on this forum.
> Are you saying that one should not even bother with problem statements
> or requirements?
>  For sure the choice is not
> between transport and packet technology, the choice is your focus.
>
> Regards
>
> Gert
>
> "Lazer, Monica A, ALABS" wrote:
>
> > Gert,
> > I think that one of the main drivers of the different needs when going
> > from L1 to L2 is the fact L1, in SONET is TDM-based, while L2 can be
> > packet based and have a different paradigm, while when going from HO
> to
> > LO one is within the same paradigm. So, point 1 indicates that one
> > should consider using the same control plane architecture for the
> > sublayers within L1, but it does not necessarily support the idea that
> > the same paradigm is best for both L1 and higher layers.  Regarding
> the
> > backbone/regional structure, more than only 2 levels may be needed for
> > global transport networks.
> >
> > Regards,
> >
> > Monica A. Lazer
> > Network Architecture and Reliability
> >
> > 908 234 8462
> > [email-masked]
> >
> > -----Original Message-----
> > From: Gert Grammel [mailto:[email-masked]]
> > Sent: Thursday, March 06, 2003 3:38 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; Ash, Gerald R
> > (Jerry), ALABS; [email-masked]
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > Mark,
> >
> > I am happy to read that we could find some common understanding. About
> > your
> > multi-layer issue you've raised, I suggest to figure out more to which
> > extend
> > this is an issue for UNI. Some thoughts on that:
> >
> >   1. Wideband Crossconnects are able to crossconnect low order
> circuits
> > (LO),
> >      and put them into high order circuits (HO). Those Crossconnects
> are
> > managed
> >      by one manager able to control both Layers: LO and HO. I've never
> > heard
> >      that an operator let one part of the organization implement HO
> only
> > on a
> >      country wide basis, while another part of the organization is
> > taking care
> >      about LO only.
> >   2. So rather than the pure layering, a kind of regional/backbone
> > structure is
> >      in place. Regional NOCs deal with HO and LO whithin the region
> > while in
> >      backbone you use HO only because you don't need the finer
> > granularity
> >      there. So what appears to be a layering from a management point
> of
> > view
> >      seems to me more a regional kind of separation.
> >
> > To be clear: I don't want to discuss the fact that there is a layering
> > in the
> > network. My point is to highlight that SDH/SONET is in reality not a
> > single
> > layer but has at least 4 of them (RS, MS, LO, HO). In theory we should
> > find in
> > the network an RS-manager, an MS-Manager, a LO-Manager and a
> HO-Manager.
> > Moreover a single Wideband Crossconnect would have had to be managed
> by
> > all 4
> > managers at the same time. Obviously this is not really practical
> > (immagine: 4
> > managers, one worker ;-) such that most vendors and carriers decided
> to
> > put all
> > 4 layers into one management box - quite similar to what a GMPLS
> Control
> > Plane
> > does with SONET/SDH control.
> >
> > Just to avoid misunderstandings here: I don't want to start a new
> thread
> > on
> > layering issues. I just want to provide you some food for your own
> > thoughts
> > hoping that we can find some common understanding at some point in
> > future.
> >
> > Regards
> >
> > Gert
> >
> > [email-masked] wrote:
> >
> > > Gert,
> > >
> > > Thanks for outlining the history and your current position for going
> > > forward.  Mostly, I agree with you.
> > >
> > > My major point of disagreement is with your characterization of the
> > > ITU-T direction.  Though the ITU-T ASON documents might enable
> > > "'Bandwidth on Demand' services (BOND)" to some degree, that was not
> > the
> > > primary focus.  The Optical UNI was a development that came out of
> the
> > > OIF and not the ITU-T.  Most carriers have seen the Optical UNI as a
> > > potential customer interface with far more realistic applications
> > > internal to networks, i.e. between the L3/L2 elements and the L1/L0
> > > elements.  Those who have attended the OIF in the past probably
> > remember
> > > my unpopular statement on the plenary floor that we were wasting out
> > > time working on a UNI that had questionable (no?) business
> advantages
> > > for the carrier.
> > >
> > > I do support the approach you mention (from Kireeti?) that we focus
> on
> > > the service points and the information that needs to be exchanged
> > > between them.  Where most of the services are of the L3/L2 variety,
> > that
> > > approach should be successful.  Those items should be fully covered
> by
> > > the IETF solutions.
> > >
> > > However, that doesn't address the multi-layer issue that we are
> > > struggling to address, which is one of the root causes of this
> > conflict
> > > between the IETF and ITU-T.  The signaling/control for L1/L0 is
> where
> > > the ITU-T participants have found the IETF solutions to be
> inadequate.
> > > That's not necessarily because the IETF solutions wouldn't work, but
> > > because they would not satisfy the stringent requirements and models
> > by
> > > which we base our management and control for L1/L0.
> > >
> > > This whole problem could be blamed on the IP success in the
> industry.
> > > If IP had not proven to be so successful, the ITU-T might have
> chosen
> > > the optical control plane based on extensions to SS7.  :-)  (Not
> > meaning
> > > to ignore the ITU-T alternative solution based on PNNI.)
> > >
> > > Regards,
> > >
> > > Mark Loyd Jones
> > > Optical Transport and Networking
> > > Sprint - Wireline Technology Development
> > > 913-794-2139
> > >
> > >
> > > -----Original Message-----
> > > From: Gert.Grammel [mailto:[email-masked]]
> > > Sent: Thursday, March 06, 2003 1:21 PM
> > > To: Mark.Jones
> > > Cc: ccamp; dwfedyk; gash; mpls
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > Mark,
> > >
> > > 'improving the coordination between the IETF and ITU-T' is one of
> the
> > > things I'd
> > > like to see since years. However in my experience the true barrier
> > > between both
> > > groups is not so much the technology as such, but some ignorance
> about
> > > the core
> > > aspects in both organizations. To give a balanced figure here:
> > >
> > >   1. You remember the thread about the non-standard SDH/SONET
> > > extensions. Here
> > >      some guys active in GMPLS tried to push their ideas about
> > > transparency.
> > >      Obviously this was perceived on ITU-T side as a challenge on
> the
> > > purity of
> > >      a standard (G.707). This one was (almost) setteled by moving
> all
> > >      non-standard features to an informal draft.
> > >   2. Now it is the other way round. Somehow ITU-T extensions got
> > > accepted (again
> > >      informational) in IETF which do not comply to the purity of
> > > RSVP-TE. Due to
> > >      the fact that this informational RFC was not reviewed in CCAMP
> > > before, it
> > >      is perceived as an assault.
> > >
> > > So the match is tied up 1:1 but maybe it's now the right time to
> find
> > a
> > > solution
> > > on how to proceed. What I've seen so far was a complete
> misperception
> > of
> > > what is
> > > required on either side and why.
> > >
> > >   1. ITU-T basically started by defining user services having in
> mind
> > > layered
> > >      transport platforms like OTH and SDH/SONET. Those services can
> be
> > >      summarized as 'Bandwidth on Demand' services (BOND). Naturally
> > this
> > > led to
> > >      a very strong focus on UNI interfaces and a kind of ignorance
> of
> > > networking
> > >      protocols. You probably remember the discussions on why not
> using
> > > SS7? (For
> > >      those not familar with the issue: SS7 is the signaling protocol
> > > between
> > >      PSTN switches)
> > >   2. IETF started with established L2/3 protocols (OSPF, RSVP-TE,
> ...)
> > > and
> > >      extending their scope to L1 technologies namely SDH/SONET and
> > OTH.
> > >      Naturally this led to a very strong focus on protocol
> consistency
> > > and a
> > >      kind of ignorance on service aspects other than those already
> > > available in
> > >      MPLS. You may remember here the discussion about whether UNI is
> > > useful at
> > >      all some time ago.
> > >
> > > So putting everything together means that it is required to keep
> > (IETF)
> > > protocol
> > > consistency but adding some (ITU-T) specific extensions to well
> > defined
> > > service
> > > points in the network (UNI).
> > > Unfortunately service points tend to exchange messages between
> > > themselves and
> > > this would mean that an intermediate protocol would have had to
> > support
> > > such
> > > kind of communication. What concerns the IETF community is probably
> > not
> > > the fact
> > > that there is a UNI somewhere, but the changes and extensions to
> > > etablished
> > > protocols in order to achieve a collaboration between them.
> > >
> > > I recall that this was the basic issue with the ITU-T proposal when
> it
> > > was
> > > presented for the first time in Yokohama. The way I've got Kireeti's
> > > message
> > > there was: please authors try to let us understand what problem you
> > want
> > > to
> > > solve and tell us which kind of information you have to exchange
> > between
> > > which
> > > points to achieve it. We'll sort out then in CCAMP what would be the
> > > most
> > > appropriate way to implement it, while maintaining consistency in
> our
> > > protocols.
> > >
> > > Although it didn't work the first time I still consider Kireeti's
> > > suggestion to
> > > be a wise way to move forward and perhaps the key for harmonic
> > > collaboration.
> > >
> > > Regards
> > >
> > > Gert
> > >
> > > [email-masked] wrote:
> > >
> > > > Gert,
> > > >
> > > > I agreed with the intent in generalizing MPLS for the wide range
> of
> > > > expected applications.  It was my hope that it would succeed.  At
> > this
> > > > point, one might say that the intent has only been partially
> > achieved.
> > > > The problem that has come to light over the past year is the fact
> > that
> > > > there are finer points of the ITU-T model and requirements that
> are
> > > not
> > > > supported by the current IETF GMPLS RFCs and standards track
> drafts.
> > > > Those aspects are considered significant enough by many carriers
> and
> > > > their suppliers to warrant further extensions outside of the IETF.
> > > (My
> > > > apologies for not understanding those points well enough to
> clarify
> > > them
> > > > even in examples, but there are many people on this list would
> could
> > > do
> > > > so if they thought it necessary.  To avoid any misunderstand, all
> > > should
> > > > know that Sprint does not yet have a company position on this.)
> It
> > is
> > > > my hope that we can come up with ways of improving the
> coordination
> > > > between the IETF and ITU-T.  This thread of discussion is bringing
> > out
> > > > the issues to make that happen.
> > > >
> > > > Regards,
> > > >
> > > > Mark Loyd Jones
> > > > Optical Transport and Networking
> > > > Sprint - Wireline Technology Development
> > > > 913-794-2139
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Gert.Grammel [mailto:[email-masked]]
> > > > Sent: Thursday, March 06, 2003 10:17 AM
> > > > To: Mark.Jones
> > > > Cc: dwfedyk; gash; ccamp; mpls
> > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > >
> > > > Mark,
> > > >
> > > > please don't forget that due to the 'Generalization' of GMPLS you
> > are
> > > > free to do
> > > > the split at any application level you wish. This was always the
> > > > advantage of
> > > > the GMPLS approach compared to the ITU-T model where initially
> each
> > > > layer had
> > > > its own control plane. So the fact that in theory you could use a
> > > single
> > > > control
> > > > plane for all your network means also that you are able to stop
> > where
> > > > you want.
> > > > Nice feature isn't it?
> > > >
> > > > Regards
> > > >
> > > > Gert
> > > >
> > > > [email-masked] wrote:
> > > >
> > > > > I agree with the separation of GMPLS into the two applications.
> > > There
> > > > > does not appear to be any significant move to collapse the
> > > management
> > > > or
> > > > > signaling for L3/2 and L1/0 at this time, given the different
> > models
> > > > > that apply for them and the infrastructures in our companies
> that
> > > > manage
> > > > > them.  The plan for addressing the two applications need not be
> > the
> > > > > same.
> > > > >
> > > > > The L3/2 application is near and dear to the heart of the IETF.
> > The
> > > > > L1/0 application is of interest to those who wish to collapse
> the
> > > > > management into a single layer.  In my opinion, the IETF might
> > also
> > > > > address this approach, given the IETF participants are the ones
> in
> > > > > support of this collapsed management or at least common protocol
> > > > > solution for what is today two signaling layers.  However, as
> > stated
> > > > > before, the collapse approach is not realistic today for a
> > > > > multi-service, multi-protocol network.
> > > > >
> > > > > On the other hand, the L1/0 application requirements and models
> > have
> > > > > been defined and are best understood at the ITU-T.  Ideally, the
> > > > > protocol expertise at the IETF would be applied to the ITU-T
> model
> > > and
> > > > > requirements to address the L1/0 application, but attempts to do
> > > that
> > > > > have been met with great resistance in the past.  Perhaps that
> was
> > a
> > > > > result of the fact that GMPLS implementations were not separated
> > out
> > > > > into the two different applications.  However, I don't think it
> is
> > > > > realistic to expect the IETF experts to be motivated to
> understand
> > > the
> > > > > ITU-T models and requirements, given the application is outside
> of
> > > > their
> > > > > primary area of interest.  That said, I believe the IETF should
> > > reach
> > > > an
> > > > > agreement on how to work with outside groups that develop "major
> > > > > extensions" to the protocol.
> > > > >
> > > > > Mark Loyd Jones
> > > > > Optical Transport and Networking
> > > > > Sprint - Wireline Technology Development
> > > > > 913-794-2139
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: dwfedyk [mailto:[email-masked]]
> > > > > Sent: Thursday, March 06, 2003 7:49 AM
> > > > > To: gash
> > > > > Cc: mpls; ccamp
> > > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > > >
> > > > > Along the lines of Jerry's comments.
> > > > >
> > > > > When we put together GMPLS the first drafts were under specified
> > > > > intentionally to capture the essence of GMPLS. We put aside many
> > > > > arguments saying lets specify at a high level and fill in the
> > > details
> > > > > later. The discussions on this thread are in two major veins one
> > > > > attempting to fill the details and the other containing and
> > > > controlling
> > > > > the changes. GMPLS needs to be specified more accurately and in
> my
> > > > > opinion it needs to be decomposed to a more layered approach.  I
> > > think
> > > > > if we applied GMPLS at at some layers (L3/2), (L1/L0) for
> example,
> > > > > independently but self similar it would offer a mechanism to
> move
> > > > > forward where some legacy systems could be specified to be GMPLS
> > > > > friendly. For example signaling for Layer 3/2 can be tunneled
> > > through
> > > > > the a lower layer. We already have some work in this direction.
> > > > >  Similarly traffic engineering information for L1/L0 in a TE
> > > database
> > > > >  would need different  attributes than a the TE database at
> L3/2.
> > I
> > > > > don't think you want to burden a L3/L2 system with these
> > attributes
> > > in
> > > > > an overlay model. The expertise for these layer is not all
> > contained
> > > > in
> > > > > the IETF. I think we should put a plan forward to make this
> happen
> > > > > within the IETF process. After this was accomplished  I think
> some
> > > > > people are thinking of collapsing layers even more but the
> logical
> > > > > partitioning of layers may help keep the protocols and databases
> > > > > simpler.   Right now were are treating GMPLS like a big bowl of
> > > jelly
> > > > > when it should look more like a layer cake.
> > > > >
> > > > > Regards,
> > > > > Don
> > > >
> > > > --
> > > > Alcatel Optical Network Division    Gert Grammel
> > > > Network Strategy                    phone: +49 711 821 47368
> > > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > > D-70435 Stuttgart                   mailto:[email-masked]
> > >
> > > --
> > > Alcatel Optical Network Division    Gert Grammel
> > > Network Strategy                    phone: +49 711 821 47368
> > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > D-70435 Stuttgart                   mailto:[email-masked]
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:[email-masked]
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

---

From: Gert Grammel <[email-masked]>
Date: Wed, 12 Mar 2003 10:48:59 +0100

Eve,

thank's for this comment. In the IPO document you refered to, I could only find the following
sentence as a motivator:

     To support many enhanced optical services, such as scheduled bandwidth on demand,
     diverse circuit provisioning and bundled connections, a call model based on the
     separation of call control and connection control is essential.

Probably we are in agreement when I say that from this sentence it is difficult to understand
*why* the separation is needed for these kind of services and potential others as you've
mentioned . So it could be beneficial to elaborate a bit on the question 'why is call
connection separation needed to support these kind of services'  to achieve a common
understanding and eventually agree on an implementation.

Regards

Gert