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

[<jls@research.att.com>]

Dimitri,
It's a little worse than that. It's likely that as's physically overlap ...
for example if they separately lease lines from the same transport carrier.
It's also common for 2 separate transport carriers to unknowingly have a
single shared point of failure ... for example they both might have fiber
buried under the same street in Manhattan.

I have a little on these problems in the 2/2001 article Angela Chiu and I
did in IEEE Communications, along with some suggestions on approaches for
optical networks.

John

John Strand
  AT&T Transport Network Evolution Dept.
  200 Laurel Ave., Room A5-1D33
  Middletown, NJ 07748
  +1 732 420-9036
  jls@research.att.com 

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] 
Sent: Wednesday, February 26, 2003 3:03 PM
To: Strand,John L
Cc: ejk@tech.org; te-wg@ops.ietf.org
Subject: Re: TE-operator call for presentations/input (multi-area)


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