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

From: [email-masked]
Date: Thu, 6 Mar 2003 10:38:14 -0600

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]

---

From: Gert Grammel <[email-masked]>
Date: Thu, 06 Mar 2003 20:21:25 +0100

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

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 Mar 2003 20:51:27 -0500

Coments inline.

In message <[email-masked]>, Gert Grammel writes:
>  
> 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 (agai n informational) in IETF which do not comply to
>      the purity of RSVP-TE. Due t o 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 solutio n on how to proceed. What I've seen so far was a complete
> misperception of what i s 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 networkin g 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)

SDH/SONET bandwidth on demand has never been deployed.  There is
serious question about whether this is a viable service.  The
technology has existed for about a decade (a little less maybe) for
provide ATM SVC service doing essentially the same thing.  Market
penetration after a decade is very close to zero for SVC.  Market
penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
market seems to be shrinking as well.  FR SVC market is zero.
SDH/SONET does not have the bandwidth on demand capability but there
is ample evidence that implementing it would be a waste of time.

ASON is a requirements document from ITU that assumes the SDH/SONET
BOND is a viable service.  This is an enormous leap of faith given the
trends in the market.  The IETF doesn't buy into it.

And yes, most of us are familiar with SS7 and the whole SCP/STP AIN
mess, so if you want to extend TCAP to support ASON, go right ahead.
We in the IETF would get a real good laugh over that.

>   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.

Initially IP and voice ran over TDM.  The bandwidth demands of IP were
much less than voice a decade ago.  As IP penetration grew roughly
exponentially through the early, mid, and most of the late 1990s, this
reversed and IP consumed far more bandwidth than voice.  Switched
services also grew but at a slower rate and in the late 1990s
experienced negative growth for many SPs.  One factor may have been
notable outages in FR (US nationwide one day at one major provider and
intermittent for 10 days in another a few years later) shot a big hole
in the "much more reliable than IP" story.

Initially MPLS served as traffic enginnering strictly for IP.  With IP
still growing substantially, voice growing very slowly (and losing
revenue) and switched services growing slowly to shrinking, there was
motivation to carry voice, switched services, and leased line services
over the IP and/or MPLS infrastructure and decommission older
SDH/SONET ADM and FR or ATM switches.  This led to the tunneling work.

Another factor which led to GMPLS was the (unrealized) promise/hype of
optical switching in the very late 1990s.  IP over an ATM overlay was
a poor design and IP providers did not want to repeat that mistake so
the control of the underlying optical domain was accommodated by what
has evolved into GMPLS.  GMPLS was extended to accommodate TDM in
addition to FSC, LSC and PSC.

> 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.

ASON was never accepted by the IETF as requirements and for very good
reason.  To say that IETF must accept the ASON requirements simply
because they came in a liason statement and that the IETF must
accommodate this ITU folly is absurd.

> 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 .

Regardless of how this was handled in Yokohama, some of the
fundamental premise of ASON is flawed.  It would be best if ITU
members go off and waste their own time pursuing ASON capabilities,
just as the ATM Forum went off and wasted their time on Q.2931
capability in UNI 3.x, 4.x, but ITU should do so without extending
protocols which originated in the IETF.

> 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

I look forward to seeing the IETF come up with a formal statement of
liason policy.  It would be useful to have explicitly documented that
liason statements carry no more weight than any individual
internet-draft submission.

Curtis

---

From: Don Fedyk <[email-masked]>
Date: Fri, 07 Mar 2003 00:34:25 -0500

Curtis

Some comments, inline.

>trends in the market.  The IETF doesn't buy into it.
This is not correct. I have had this discussion with the authors and 
they assure me bandwidth on demand not the expected model of deployment. 
It is not precluded true but they realize the current situation.

>in the "much more reliable than IP" story.
We know the world is changing and that is why we are trying to reuse IP 
technology.  I think it is a big win if we reuse similar technology 
components. It won't happen overnight. But it wont happen if we don't 
move forward. There is a lot of history in optical networks and they are 
evolving and simplifying. This is similar to the early packet industry. 
We used to have many protocols for different traffic. Only with the 
advent of cheaper bandwidth could we afford IP. 

<snip> History of GMPLS

>accommodate this ITU folly is absurd.
I don't think it is about accepting ASON per se. We would not have the 
ITU if that were true. It is about parallel requirements that can be 
solved by the same mechanisms. Is there a one to one mapping? In many 
cases yes. Are there differences yes again. Do we need the IETF to 
accept all the changes?  Well that is THE question. What would be great 
is if the IETF could accommodate, and filter the information that is 
relevant and suggest solutions to features that the IETF cannot see 
value in. That's what I saw happen in other WGs.  You know the ITU has 
taken a lot of technology from the IETF. It is common practice not to 
reinvent technology.

 I can't think of system that was deployed that turned out the way 
everyone thought it would. We wouldn't be deploying IP version 6 if 
there wasn't some room for changes.   There are many profitable ATM 
networks in the world. Guess what?  There are even profitable X.25 
networks still kicking.

>protocols which originated in the IETF.
Your instance that they are all irrelevant and should go away is tiresome.

>internet-draft submission.
Curtis you have proven that even the weight of any individual has a 
pretty high threshold!

Don

---

From: Gert Grammel <[email-masked]>
Date: Mon, 10 Mar 2003 13:24:06 +0100

Curtis,

you've wrote:

     It would be best if ITU members go off and waste their own time
     pursuing ASON capabilities, just as the ATM Forum went off and wasted
     their time on Q.2931 capability in UNI 3.x, 4.x, ...

and I don't agree with that. In my view it would be best if ITU-T members were
able to understand and accept the ideas behind GMPLS and would provide valuable
input to bring this work forward.

Regards

Gert

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 11 Mar 2003 11:40:51 -0500

In message <[email-masked]>, Gert Grammel writes:
> and I don't agree with that. In my view it would be best if ITU-T members
> were able to understand and accept the ideas behind GMPLS and would
> provide valuable input to bring this work forward.
> 
> Regards
> 
> Gert

I absolutely agree with your statement above.

If there is consensus in the IETF that ASON should not be considered
as a set of requirements it would also be best if ITU-T members tried
to understand why this consensus was reached rather than try to
initiate procedural changes to allow it to be jammed through
regardless of whether is makes technical sense.

Perhaps I should have qualified my statement that if ITU-T members
continue to behave as they are now doing, then "It would be best if
ITU members go off and waste their own time ...".

Curtis