Re: TE-operator call for presentations/input (multi-area)

[Dimitri.Papadimitriou@alcatel.be]

john,

thanks, this means (following your below observation) 
that the most we could achieve is a 1:n diversity on 
a per as basis, and even then multiple spaces might
have to be considered; as such the constraint you 
mention here below says there is no way today to 
device any mapping between these spaces, so if an lsp 
covers several as's and has to be diverse from n other 
lsp's, the "exclusion" mechanism would allow to ensure
1:n diversity on a "per common topological segment" 
basis but not an global end-to-end one; please correct 
me if i misunderstood the below statement

thanks,
- dimitri.

jls@research.att.com wrote:
> 
> Dimitri,
> Assuming a single inter-as srlg space would be folly at present.
> In fact, even within a single carrier network it is more likely
> than not that there isn't a single srlg space - for example, most
> large carriers have acquired other carriers in the last few years,
> and I would bet a large amount of money that they haven't
> integrated their physical maps in the detail required if there is
> any significant overlap.
> 
> John
> 
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Tuesday, February 25, 2003 3:49 PM
> To: Ed Kern
> Cc: te-wg@ops.ietf.org
> Subject: Re: TE-operator call for presentations/input (multi-area)
> 
> ed,
> 
> i have a question directed to the user community
> on inter-as srlg diverse path, how can we ensure
> a single srlg id space exists ? i.e. even if the
> signalling allows for carrying an exclusion set
> (for inst. is as_1 uses set {1,2,3} and as_2 the
> set {4,5,6} the rro gives the set {2,5}, and the
> for the protecting lsp the he selects 1, how to
> be sure that 1 and 5 do not share a common risk,
> for inst. a common fiber cable ?)
> 
> thanks,
> - dimitri.
> 
> Ed Kern wrote:
> >
> >  We are starting to take the first steps in the direction of defining
> >  requirements for multi-area TE.
> >
> >  This was not fully fleshed out in Network Hierarchy and Multilayer
> >  Survivability (RFC3386) for several reasons.  At the time, the
> >  chairs, AD's, design team and WG simply werent sure if this was
> >  necessary or that if there was enough operator need to properly scope
> >  this work.
> >
> >  Currently on the list we have been discussing requirements in the
> >  context of draft-zhang-mpls-interas-te-req-01.txt.  Before we proceed
> >  much further, the chairs would like to hear from operators who are:
> >
> >  1. *Currently* in need of a multi-area solution on a production
> >  2. Currently deploying a version/flavor of multi-area TE.
> >  3. Waiting on a standard/guidance before planning/deploying
> >  4. Feel that these requirements should be scoped out regardless of
> >     current operational requirements.
> >
> >  This is not an attempt to rope you into assisting with the current
> >  draft but more a request to:
> >
> >  1. Present current protocol limitations/concerns at next ietf
> >  2. Discuss them on the list here
> >
> >  We are specifically trying to target front-line engineering and
> >  operational efforts.  We understand that from an architectural
> >  perspective, having the path to multi-area and multi-as solutions
> >  is desirable.  However, we are uncertain how much of this is pulling
> >  up into *real* obstacles at this time.
> >
> > Ed & Jim
> 
> --
> Papadimitriou Dimitri
> E-mail : dimitri.papadimitriou@alcatel.be
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : dpapadimitriou@psg.com
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491