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

From: "Irwin Lazar" <[email-masked]>
Date: Tue, 11 Mar 2003 08:49:51 -0700

There are a few drafts on the topic:

http://www.ietf.org/internet-drafts/draft-behringer-mpls-security-03.txt

http://www.ietf.org/internet-drafts/draft-tsenevir-smpls-02.txt

Also see: Cisco MPLS based VPNs: Equivalent to the security of Frame Relay and ATM - available at www.miercom.com

Irwin

> -----Original Message-----
> From: Ferrell, William [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2003 10:07 AM
> To: 'Gert Grammel '; [email-masked] '
> Cc: [email-masked] '; [email-masked] ';
> [email-masked] '; [email-masked] '; [email-masked] '
> Subject: RE: {Possible Spam} Re: I-D
> ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
>  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: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> 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 <[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
> 
> --
> 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]
> 
>