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

[Gert Grammel <Gert.Grammel@alcatel.de>]

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

"Varma, Eve L (Eve)" wrote:

> 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:Gert.Grammel@alcatel.de]
> Sent: Tuesday, March 11, 2003 10:47 AM
> To: Lazer, Monica A, ALABS
> Cc: Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
> dwfedyk@nortelnetworks.com; Ash, Gerald R (Jerry), ALABS; mpls@UU.NET
> 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
> > mlazer@att.com
> >
> > -----Original Message-----
> > From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> > Sent: Monday, March 10, 2003 7:19 AM
> > To: Lazer, Monica A, ALABS
> > Cc: Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
> > dwfedyk@nortelnetworks.com; Ash, Gerald R (Jerry), ALABS; mpls@UU.NET
> > 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
> > > mlazer@att.com
> > >
> > > -----Original Message-----
> > > From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> > > Sent: Thursday, March 06, 2003 3:38 PM
> > > To: Mark.Jones@mail.sprint.com
> > > Cc: ccamp@ops.ietf.org; dwfedyk@nortelnetworks.com; Ash, Gerald R
> > > (Jerry), ALABS; mpls@UU.NET
> > > 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
> > >
> > > Mark.Jones@mail.sprint.com 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:Gert.Grammel@alcatel.de]
> > > > 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
> > > >
> > > > Mark.Jones@mail.sprint.com 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:Gert.Grammel@alcatel.de]
> > > > > 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
> > > > >
> > > > > Mark.Jones@mail.sprint.com 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:dwfedyk@nortelnetworks.com]
> > > > > > 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:Gert.Grammel@alcatel.de
> > > >
> > > > --
> > > > Alcatel Optical Network Division    Gert Grammel
> > > > Network Strategy                    phone: +49 711 821 47368
> > > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> > >
> > > --
> > > Alcatel Optical Network Division    Gert Grammel
> > > Network Strategy                    phone: +49 711 821 47368
> > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de