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

From: [email-masked]
Date: Fri, 7 Mar 2003 09:10:22 -0000

Don, you observed 07 March 2003 05:34
<snip>
> >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.

NH=> Mark has said effectively the same and I can confirm this.  To make
switched services work you basically need (i) very large numbers and (ii)
knowledge of the calling-rate/holding-times.  We have neither at SDH rates
or lower (ie OTN).  However, using generalised models you can show that to
had a stab at a reasonably efficient network/service-model the expected
waiting-time for a given BW 'post demand' needs to be the same order as the
holding-time of that BW.  If the expected holding-time is the order
days/weeks/months on a relatively small network population you can see that
its a nonsense to even think about going here at this point.  Note that you
can extend this arguement to the ethernet BOD case....the fundamantal
problem is the same (you can of course address niche markets in limited
locations, but not large/general-case geographical areas).

Wrt to your other observations on ATM/FR.  Yes, its been very difficult to
justify SVCs here.  This is also due to their use as product substitution
for TDM-leased-line services (to build private networks) rather than new
services.  And from what we see, the FR market is now flat but the ATM
market is still showing fairly high growth rates.
> >
> >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.
> >
> 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.
NH=> Again I can confirm what Don is saying is correct.  We have been
consistent on this from the start.....we never saw BOD at L1 as the main
driver.  It was those driving GMPLS who were the main group arguing for BOD
at L1 to set-up 'LSPs' at will for the IP client layer.....and I can
remember arguing with them a couple of years ago on this saying 'please
don't go there'.  In fact its really hard to justify using a control-plane
at all at L1.  The benefits are minimal in our opinion (but to be fair, I
have to admit that we have some very slick NMS/OSS solutions here).
Restoration/S-PVC-like constructs are useful.  Having a control-plane
external NNI is arguably better than a NMS-plane NNI (eg less real damange
possible from any hacking).  Any control-plane solution must play
second-fiddle to the NMS.  And given operators have multiple clients, none
of which will be 'peering' with the L1/0 networks then there is no
compelling argument to select a specific control-plane solution.....the
components can therefore be chosen based on what an operator perceives to be
best-of-breed.
<snip>
> >Initially IP and voice ran over TDM.
NH=> Don, they always will in core networks.  Cct-switching is a fine way to
aggregate *any* forms of large traffic volumes, irrespective of its source
nature.  This is just a fact that any operator could confirm.

regards, Neil
<snipped to end>

---

From: "Ferrell, William" <[email-masked]>
Date: Thu, 13 Mar 2003 11:22:13 -0500

"Since MPLS implements the same routing protocols such as OSPF and BGP in
LSRs in performing routing functions, it would have  the same
vulnerabilities, such as routing tables being poisoned and IP header fields
being changed, as in the IP networks using regular routers in routing IP
traffic"

Same old arguement here : 
MPLS uses LDP is that to say that it is "like " OSPF ? NO. MPLS uses the
Routing protocol to get routing information. But ultimately , yes I agree
that by useing ISIS , OSPF and BGP the routing tables are suspect to attack
and same old vulnerbilities are now transposed onto the MPLS net, but
conversely so is the signalling and hellos in LDP.  

Will

---

From: [email-masked]
Date: Thu, 13 Mar 2003 17:47:36 -0000

William Ferrell wrote 13 March 2003 16:22
> conversely so is the signalling and hellos in LDP.  
Will,  Not really sure where you are going here but one thing you need to
think about is making sure the network itself has some form of self-checking
so that security problems don't arise as a results of network failures.  We
regard this as very important (especially for arbitrary X/MPLS client/server
relationships, eg ATMoverMPLS) so let me try and explain:

In a cnls network each/every pkt contains full SA/DA.  So you can pick a pkt
up from anywhere and drop it somewhere else and (subject to TTL exhaust) it
will find its way to the right destination.  Not true however in MPLS (any
type).

The links between MPLS nodes use link-connection identifiers, which are only
required to be unique for the link between a pair of adjacent nodes.  These
link-connection identifiers only possess networking currency when they are
allocated to a parent LSP entity at it's creation time.  Similarly, the
link-connection identifiers lose their networking currency when their parent
LSP entity is destroyed.

A specific link-connection identifier can be used: (i) on different links in
the same LSP, or (ii) on any links in other LSPs.  This means one cannot
take a packet out of a given LSP at any point and drop it into the network
at some other point and expect it to find it's way to the correct
destination.  There are 2 possible outcomes from doing this:

1	The packet will black-hole at the next receiving node if the
link-connection identifier has no currency at that node, ie it is not
allocated to some parent LSP;  or,

2	The packet will be forwarded at the next receiving node if the
link-connection identifier has currency at that node (and thereafter
forwarded on all subsequent links to the connection sink point), ie it is
allocated to some parent LSP.  Note also that this case can be *recursive*
if there are nested client/server LSP relationships....so the black-holing
or further forwarding behaviour can continue upwards in the affected client
LSPs.

Any failures that result in MPLS packets being misdirected raise traffic
integrity/security concerns.  So not only must such defects be automatically
detectable, but they must also automatically elicit the right type of
consequent actions, eg in this case squelch the traffic, as well as
informing the higher client (eg ATM) of the failure.....note that the client
network may be an external customer of the MPLS layer network
service-provider and so in a completely different management domain.

So this is why in SDH, for example, you find a trail-trace function in the
user-plane, ie a periodic identifier sent by the source to the sink so that
the sink can verify it has correct connectivity.  The same should also apply
to MPLS (or at least those versions of MPLS that are p2p.....mp2p LSPs raise
a whole raft of other issues).  The requirements for this are given in
Y.1710 and the solutions are given in Y.1711, ie we require that a
Connectivity Verification OAM packet be periodically sent in the user-plane
from the source to the sink that identifies where the pkt came from. In
doing so we can detect all failure modes, eg simple breaks, swapped LSPs,
and mismerged LSPs, and take the right consequent actions quickly.

This does not address all the security concerns of course, and its not
intended to protect against malicious attacks....it merely helps protect the
network from creating security breaches due to its own failures.

regards, Neil