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

RE : Proposed strategy for Inter-area/AS



Hi Adrian,

See inline

> -----Message d'origine-----
> De : Adrian Farrel [mailto:olddog@clara.co.uk] 
> Envoyé : vendredi 23 avril 2004 17:01
> À : LE ROUX Jean-Louis FTRD/DAC/LAN; ccamp@ops.ietf.org
> Cc : adrian@olddog.co.uk
> Objet : Re: Proposed strategy for Inter-area/AS
> 
> 
> Hi, 
> 
> Thanks for clarifying. See below... 
> 
> >> > 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.
> 
> > 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.
> 
> How right you are :-) 
> 
> The draft currently says...
>   The solution MUST entirely preserve the concept of IGP hierarchy. In
>   other words, flooding of TE link information across areas MUST be
>   precluded. 
> 
> I took "flooding" to be a more free distibution of information that 
> "leaking". 
> 
> For example, I would consider that the Summary LSA is 
> "leaking" routing information from one LSA to another, but it 
> is not flooding that 
> information. 

Right, we will clarify.

> 
> If you are saying that ABSOLUTELY NO TE information may be 
> exchanged between areas, then I wonder how an ingress LSR can 
> know the reachability to the egress (let alone the 
> availability of suitable paths) when areas have more than one 
> ABR. (Note that TE addresses are not necessarily routable!)

No, we are not saying that. What we only want to preclude is the leaking of 
 TE information related to bandwidth availability, including summarized TE information because this definitely does not scale:
Let's assume that there are N distinct paths from ABR A to a destination X, each with a distinct bandwidth and
distinct admin-group (a path admin group being expressed as a logical AND of the link admin groups along the path)
How can you summarize such topology ? Actually you need to advertise N virtual links, each with a distinct admin-group and available bandwidth.

Note that in return, we don't preclude the leaking of static TE information related to LSR properties (such as PCE capabilities, TE router ids...),
Provided that there is no impact on the IGP.

We are going to clarify that in next revision (01 posted next week)), and your comments are highly welcome.
 
> 
> I would have a problem with the requirements draft if it is 
> precluding ALL exchange of TE information between areas. A 
> more appropriate requirement would describe scalability and 
> impact on existing operation of routing protocols, but would 
> not constrain the solution in this way. 
> 

Yes this would be an approach, but as we consider that TE summarization does not scale what about
not precluding it directly in the requirement draft ?
Note that this is a strong requirement expressed by 6 distinct ISPs.

> . . . . . 
> 
> Can you tell me the status of this draft? Is it still alive 
> in the TEWG? Is TEWG working on it? When is it scheduled to 
> be completed? 

This is a WG document of the TEWG, it was approved in March and TEWG is still working on it.

Cheers,

JL

> 
> Thanks,
> Adrian
>