The MPLS WG Archive

[Zhi-Wei Lin <zwlin@lucent.com>]

Hi Sid,

I agree with most of your points. I think they are very valid, and have
been confirmed by several service providers. So this is good.

One thing I'm not so sure about is your comment regarding setting up SRG
being not so complex. I think you are right that specifying the use of
such information is not complex. We only need to include that parameter!
And I'm sure we can come up with a dis-joint algorithm for route
determination that can take SRG into account. 

But, as John (Strand) mentioned, the complexity is trying to get the
necessary information to come up with the SRG value in the first place.
As John said, "Even for a single carrier, keeping track of the data
required to construct an internal SRLG database is a formidable task"
(John I hope I'm not mis-representing your quote! If I am forgive me!)

Now if you consider sharing this with a client (the OIF uses the term
user instead of client) network, and that the connection may traverse
multiple carrier networks, getting the SRLG shared among all the
participants is probably even more of a formidable task...even
considering that including the parameter in a signaling protocol is a
not-so formidable task...

Zhi



Sid Chaudhuri wrote:
> 
> The routers can't figure out the failure scenarios unless they know the SRGs
> within the optical layer. For example, consider three routers A, B, C each
> pair connected by an OC-48 via optical switches, two of which (AB and BC)
> may share part of the way the same conduit and hence may fail in a single
> event. Routers wouldn't know that unless we assume that each router
> connected to the optical layer receives the SRG information from the optical
> layer.  It's possible to do that if we assume two things: (1) All routers
> and optical switches in a network share the same information - in other
> words peer model, (2) SRG can be defined in so many different ways - sharing
> same WDM, same fiber cable, same WDM, same conduit, same office.  It's
> difficult for me to assume that standards can be erected to define this and
> passed to the routers.  These are the types of things I would presume ISPs
> would inquire before connecting their routers to the optical layer service
> provider and then request via signaling the type of services (Gold, Silver,
> Bronze, etc.) they need.  The ISPs would know based on the optical layer
> restoration, SRG implementation etc. what these service levels mean in terms
> of availability, protection switching time, etc.
> 
> Setting up diverse routes within an optical layer which implements the
> concept of SRGs is really not so complex.  Request by routers to provide
> diverse routes in the optical layer is already incorporated in the OIF UNI
> spec.
> 
> Regards.
> 
> Sid
> 
>                 -----Original Message-----
>                 From:   Jim Boyle [mailto:jboyle@Level3.com]
>                 Sent:   Monday, October 23, 2000 2:09 PM
>                 To:     Sid Chaudhuri
>                 Cc:     'Kireeti Kompella'; xuyg@lucent.com; yxue@UU.NET;
> ip-optical@lists.bell-labs.com; mpls@UU.NET
>                 Subject:        RE: [IP-Optical] RE: Optical link bundling.
> Was Re: DraftMinutes  From         Pittsburgh
> 
>                 if the lambda's are unprotected (which is debatable), then
> the routers can
>                 communicate amongst themselves and decide what are the
> failure scenarios,
>                 and request more or less capacity based on that analysis.
> 
>                 A complex alternative is to support things like:
> 
>                 a) "setup these two circuits in a diverse manner"
>                 b) same as (a) but over different UNIs, in fact in different
> towns
>                 (e.g. setup nyc-sfo diverse from wdc-lax)
>                 c) "setup this circuit diverse from SRLG A,B,C" (which may
> be infeasible
>                 if the circuit which those SRLGs were derived from preclude
> a diverse
>                 route).
> 
>                 As for path selection in general, a knowledge of the
> underlying topology
>                 is probably necessary for most optimal path selection when
> establishing
>                 lightpaths for non-direct traffic.
> 
>                 This only makes sense in the 2001 timeframe to support one's
> ISP over
>                 one's optical network.  An argument can be made that a good
> OSS makes a
>                 lot of this level of integration unnecessary.  Inter-company
> is a whole
>                 other issue.
> 
>                 regards,
> 
>                 Jim
> 
>                 On Mon, 23 Oct 2000, Sid Chaudhuri wrote:
> 
>                 > I don't see why TE and protection require the routers to
> specify explicit
>                 > routes.
>                 > The routers can simply specify to the optical layer what
> type of optical
>                 > layer protection
>                 > it requires.  Based on its traffic flow a router only
> needs to know between
>                 > which
>                 > two routers it needs to establish a new lightpath.  How
> the lightpath is
>                 > routed in the
>                 > optical layer seems to me irrelevant to TE.
>                 >
>                 > Sid Chaudhuri
>                 >
>                 >
>                 >               -----Original Message-----
>                 >               From:   Kireeti Kompella
> [mailto:kireeti@juniper.net]
>                 >               Sent:   Monday, October 23, 2000 11:43 AM
>                 >               To:     xuyg@lucent.com; yxue@UU.NET
>                 >               Cc:     ip-optical@lists.bell-labs.com;
> mpls@UU.NET
>                 >               Subject:        Re: [IP-Optical] RE: Optical
> link bundling.
>                 > Was Re: DraftMinutes From         Pittsburgh
>                 >
>                 >               Hi,
>                 >
>                 >               > > (router determines the explicit routes).
> 
>                 >               >
>                 >               > This point has been raised by several
> folks. It really
>                 > confuses me. If the
>                 >               > optical switches are equipped with path
> calculation
>                 > ability, what's the benefit
>                 >               > to bother router to determine the explicit
> routes within
>                 > optical domain
>                 >               > (assuming router can be smart enough to
> handle all optical
>                 > network specific
>                 >               > attributes and constrains) than just have
> routers to
>                 > determine the end points of
>                 >               > optical trails.
>                 >
>                 >               Why does this confuse you?  Routers may want
> to determine
>                 > the exact
>                 >               path that their LSPs take for a number of
> reasons, including
>                 > TE and
>                 >               protection.  If a router doesn't care where
> its LSPs are
>                 > laid out,
>                 >               it can install loose hops at the boundaries
> of the optical
>                 > cloud.
>                 >
>                 >               Kireeti.
>                 >

-- 
Zhi-Wei Lin
Lucent Technologies                       Tel: +1 732 949 5141
101 Crawfords Corner Rd, Rm 3C-512        Fax: +1 732 949 3210
Holmdel, New Jersey 07733-3030 USA      Email: zwlin@lucent.com