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

[Mark.Jones@mail.sprint.com]

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