The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Oct> msg00551



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[IP-Optical] Joint Routing was RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh

  • From: Mark Stewart <Mstewart@nexen.com>
  • Date: Fri, 27 Oct 2000 11:02:26 -0400
  • CC: alchiu <alchiu@research.att.com>, "'Yakov Rekhter'" <yakov@cisco.com>, ip-optical <ip-optical@lists.bell-labs.com>, mpls <mpls@UU.NET>, sc <sc@tellium.com>, xuyg <xuyg@lucent.com>, yxue <yxue@UU.NET>

Hi Dave

Why are we equating joint routing with centralized computation? Few (if
any) members of the IETF would dispute that centralized computation has
nasty scaling problems; but I thought we were discussing joint routing.

Mark


David Allan wrote:

>
>
> Mark:
>
> I would agree that this is true if we are looking at a relatively
> invariant network topology and the entity in the network performing
> the "design" of the protection scheme for the new paths and SLA has a
> comprehensive view of network state. I also think that the optical
> space has a lot of complexity (consideration for amplifiers, regen
> etc.) which would suggest that we are going to have a relatively
> invariant topology for a while (although we are all working hard to
> eliminate much of this complexity or at least the need for its
> visibility to higher layers).
>
> At some point though, when it is common that a fiber carries 80 OC192s
> so I have a capacity to configure some 15000 STS-1s on a given span in
> varying degress of concatenation, and we are trying to get STS
> provisioning down to LSP setup times, then we need to acknowledge that
> some central entity doing all of this is eventually going to break. At
> that point we need distributed algorithms and possibly hierarchical
> routing, with all the issues that entails (including the possiblity of
> "no-solution"). At the risk of inflamming the audience, as far as SLAs
> are concerned, what is an ATM SVC, and PNNI, other than a distributed
> means of establishing paths with a given SLA?
>
> If the expectation is that we are only going to do "gross tweaking"
> and the granulatity of the managed paths is always going to track
> technology at some fixed fraction of what is capable (e.g. if STSn is
> the biggest path, then STSn/x (where 'x' is fixed), will be the
> smallest granularity manipulated regardless of the value of 'n'.),
> then we are doing a lot of work simply to preserve the status quo and
> probably assuming that there is only going to be one type of payload
> (e.g. IP packets). We are limiting ourselves to traffic engineering.
> Given all the points brought up on this thread so far, that is not a
> good assumption. It is probably more reasonable to say that the core
> of the network needs to scale faster that the requirements for
> bandwidth of individual clients and centralized path establishment
> will be inadequate at some point.
>
> regards
> Dave
>
>
>
>      -----Original Message-----
>      From:   Mark Stewart [SMTP:Mstewart@nexen.com]
>      Sent:   Thursday, October 26, 2000 9:41 AM
>      To:     Allan, David [CAR:NS00:EXCH]
>      Cc:     alchiu; 'Yakov Rekhter'; ip-optical; mpls; sc; xuyg; yxue
>
>      Subject:        Re: [IP-Optical] RE: Optical link bundling. Was
>      Re: DraftMinutes From  Pittsburgh
>
>      Hi Dave
>
>      The concept of jointly routing primary and protection paths has
>      been
>      well accepted by Bell heads looking at optimizing their networks
>      for a
>      long time. Part of the reason for this is the assumption that
>      protection
>      path(s) must also be conformant to the same SLA as the primary
>      path, and
>      joint routing is the most likely to achieve this.
>
>      This does not of course address your concerns about race
>      conditions at
>      connection establishment. But joint routing is guaranteed to
>      produce a
>      solution not worse than independent routing, and results in a
>      lower
>      commitment of network resources.
>
>      ciao
>
>      mark
>      <snip>
>