RE : Proposed strategy for Inter-area/AS

["LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@francetelecom.com>]

Adrian,

See inline

> -----Message d'origine-----
> De : Adrian Farrel [mailto:olddog@clara.co.uk] 
> Envoyé : vendredi 23 avril 2004 13:45
> À : LE ROUX Jean-Louis FTRD/DAC/LAN; ccamp@ops.ietf.org
> Cc : adrian@olddog.co.uk
> Objet : Re: Proposed strategy for Inter-area/AS
> 
> 
> 
> Jean-Louis 
> 
> > I think this is a good strategy.
> 
> Thanks! 
> 
> I think we're pretty close to agreement on the points you 
> raise. It may not have been apparent from my original email 
> that I am NOT 
> suggesting the work in one phase must complete before the 
> work on the next 
> phase can start. I am, however, saying that I expect the work 
> to start in 
> the order shown.
> This is not unreasonable and should reflect the natural 
> processes anyway. 

OK

> 
> > I have two comments:
> >
> > 1) As already mentionned by Vishal, we cannot,
> >     IMHO, decorrelate 6 from 1, 2 3 and 5.
> > -The support of additional functions may require important
> >   modifications, if they are not taken into account during the
> >   initial step of specifications.
> >-Path Reoptimization is a MUST requirement and Path diversity is a  
> >SHOULD  requirement ( inter-area and inter-as reqt drafts). So we  
> >should not address them as advanced functions, but rather as base  
> >functions of the inter-area/AS tool-kit.
> >
> > 2) I'm not sure to well understand what do you put in 3.
> > What do you exaclty mean by routing model, and how do you 
> distinguish 
> > it from the path computation model ?
> 
> Perhaps I should have said "distibution of TE and other 
> information by the routing protocol or by other means". This 
> is not path computation. 
> 
> > Requirement drafts clearly point out that routing (IGP, EGP) 
> > extensions should be avoided, except some minor extensions to 
> > advertise static parameters such as PCS capabilities for instance 
> > (addressed in point 5).
> 
> I am not sure that I can find any text in the two TEWG drafts 
> that actually 
> says what you suggest.
> There are comments on scalability which are, of course, 
> related. There are also lots of comments about TE aggregation 
> which might be 
> considered as extensions. 
> Regardless of how or where the path is computed the full 
> system must have 
> visibility across the whole of the system. This may be 
> compartmentalised and 
> restricted to domains relying on crankback, it may use 
> cooperative PCEs, it 
> may use some leakage of (aggregated) TE information. 

In the inter-area requirement draft, we clearly  point out that information 
propagation for path-selection should continue to be localized and that leaking of TE link information across areas
MUST be precluded (section 5.3.1). 
Note that this includes any summarized/aggregated TE link information. 
I agree that this is not clear in current version, we will clarify in next revision.


Cheers

JL

> What is 
> up for debate 
> is closely linked to the choice of computation point(s) and 
> focuses on what 
> information is distributed and how. 
> 
> > Hope this will help.
> 
> Very much appreciate your support and opinions. 
> 
> Cheers,
> Adrian 
> 
>