[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Diversity of Routes Doubt



3 observations:

1	It difficult to understand the need for diversity and SVC-like
connections......diversity becomes an increasingly important factor as trail
holding time increases.  So diversity is something important for
permanent/semi-permanent trails set under the management-plane or, in a
management proxy-type mode, by the control-plane (S-PVC-like).

2	All client layers inherit their connectivity from the duct
network....so a knowledge of the topology of the duct network is essential
to ensure diversity in a client network.  However, no operator will own all
the layers 'to the duct' globally......so peering via exterior-NNIs will be
essential.  This means that there will be no visibility of the duct topology
(nor allowed control of L1 resources) outside of a single domain.  Hence,
the ability to calculate/force a strict source explicit route (or routes for
diversity) across inter-oprerator boundaries will in general not be
possible.

3	Item 2 above will impact other issues related to resilience.  For
example, even assuming one believes pre-emption will yield any
tangible/deterministic benefit within a single domain it is hard to see how
this concept could be extended across exterior-NNIs.
 
Neil


> -----Original Message-----
> From: Fong Liaw [mailto:fliaw@zaffire.com]
> Sent: 23 June 2001 01:25
> To: 'manoj juneja'; ccamp@ops.ietf.org
> Subject: RE: Diversity of Routes Doubt
> 
> 
> Manoj
> 
> I am not sure CCAMP is the right email list to discuss
> OIF UNI specific attributes/object. I will respond here, 
> but we can take it off-line or to oif-signal@oiforum.com 
> if needed.
> 
> >  -----Original Message-----
> >  From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
> >  Sent: Friday, June 22, 2001 4:43 PM
> >  To: ccamp@ops.ietf.org
> >  Subject: Diversity of Routes Doubt
> >  
> >  
> >  Hi All,
> >            The OIF-UNI draft contains diversity sub-object (part of
> >  Generalized UNI Attribute object). There is no such object in GMPLS
> >  drafts. In a typical scenario, where one O-UNI request has to be
> >  converted/translated/mapped to one GMPLS (NNI) request, how to
> >  interpret/translate the diversity TLV/object ?
> 
> The UNI diversity subobject includes a connection identifier and
> the diversity requirement, e.g. node, link, etc.  The first
> switch (ONE) should use the connection identifier to find out 
> the path (links and nodes) of the identified connection and 
> then use it to compute ERO that would diverse from the nodes,
> links, or SRLG.
> 
> >  Is it the responsibility of network manager to offline 
> calculate the
> >  ERO (and pass in the path message from the edge/ingress ONE) which
> >  statisfies the diverstiy of the route desired by the client
> 
> I don't think this can be done offline, since it changes
> according to which connection you want to diversify from.
> But it can be done by either centralized or distributed 
> computation, and precomputation might be possible.
> 
> >  equipment ? Does this mean the usage of strict routes in ERO ?
> >  Should we be having the diversity object in GMPLS drafts also ?
> 
> Use of strict route in ERO is probably the simplest and common
> approach in single domain. Using loose route ERO is possible
> but could be more complicate. This may come into GMPLS/OIF NNI 
> if diversity across multiple domain becomes a requirement. 
> We don't have this requirement yet, so there is no need to introduce 
> it into GMPLS yet.
> 
> Regards,
> -Fong
> 
> >  
> >  Please clarify my doubt.
> >  
> >  Regards,
> >  manoj.
> >  
> >  
> >  _________________________________________________________________
> >  Get your FREE download of MSN Explorer at http://explorer.msn.com
> >  
> >  
>