RE: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

["Ferrell, William" <William.Ferrell@titan.com>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

 Gert / All

 I am Will Ferrell of Titan working at DISA on an MPLS security 
project. I have worked with Barry Raveendran Greene (Cisco) on a major DISA
ACL project of which he provided invaluable guidance/support/ tech reference
that led to the projects success.


Ive checked RFC's 2547,3036,2702 et. al.  It appears that there isnt a lot
of interest in securing MPLS. Can you refer me to other work for MPLS
security requirements and all phases of MPLS security to include secure
implementation. 

> > > 
> > >William Ferrell 
> > >Information Assurance Eng. CCNP 
> > >Titan Corp. 
> > >703-882-2474 



-----Original Message-----
From: Gert Grammel
To: curtis@fictitious.org
Cc: Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
dwfedyk@nortelnetworks.com; gash@att.com; mpls@UU.NET
Sent: 3/10/03 7:24 AM
Subject: Re: {Possible Spam} Re: I-D
ACTION:draft-andersson-mpls-g-chng-proc-00.txt

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


Curtis Villamizar wrote:

> Coments inline.
>
> In message <3E679FB5.542FBF09@alcatel.de>, 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

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