Subject: Re: Proposed strategy for Inter-area/AS

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 20 Apr 2004 08:47:25 +0100

Hi Greg, 

> Nice work breakdown Adrian.  Agree that the
> applicability should be tackled early on.  One of the
> issues that has been a problem in the past was of
> differing applicabilities.

Agree. 

> Thanks also for putting the drafts in once nice easy
> to access place. The only one I didn't see there was
> the kompella-multi-area-te draft that you mention
> below.

Thanks.
Yes, that draft was quite useful (and frankly, I missed it when I started
on the inter-domain stuff which turns out to be really annoying because it
contains some good text), however, it expired in December last year. 

I am parsing it to include relevant material in the framework draft. 

> Also agree in principle with Vishal's path computation
> hierarchy.  When dealing with different granularity
> signal types, e.g., from 1 or 2Mbps MPLS LSPs all the
> way to lambda or waveband switched GMPLS LSPs
> different methods are generally called for.  For
> example, a distributed PCS approach would initially be
> overkill, versus a centralized approach (not that many
> LSPs to get set up that often) while if one is dealing
> with lower rate  MLPS LSPs a distributed PCS approach
> (hopefully) would be more  appropriate.

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Apr 2004 12:44:59 +0100

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. 

> 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. 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

---

From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Date: Fri, 23 Apr 2004 14:09:44 +0200

Hi Adrian and Kireeti,

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 ? 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). 

Hope this will help.

Regards,

JL

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la 
> part de Adrian Farrel Envoyé : mercredi 14 avril 2004 13:50
> À : [email-masked]
> Objet : Proposed strategy for Inter-area/AS
> 
> 
> All,
> 
> JP and Arthi have done a fine job of pulling together all of the 
> threads of inter-area and inter-AS solutions into a single draft. This 
> gives us a single place to look for information, but the resulting 
> draft is (of course) quite large. As additional details need to be 
> filled in, it is clear that this draft would only grow and that would 
> make it unusably large.
> 
> So, we are proposing to use the material in the draft to produce a 
> series of detailed drafts that would, over time, replace JP and 
> Arthi's document.
> 
> 1. Framework for Interdomain MPLS and GMPLS
>     A short draft that introduces the routing and signaling options
>     for multi-domain LSPs, and explains the options for path
>     computation.
>     This does not describe applicability or any necessary protocol
>     procedures or extensions.
>     Material will be taken from draft-vasseur-ccamp-inter-area-as-te
>     and draft-kompella-mpls-multiarea-te as required.
>     Authors: Adrian, JP, Arthi
>     Due date: End of April.
> 
>  2. Individual signaling extension drafts
>     If any one of the signaling approaches described in 1.
>     requires additional protocol procedures or extensions
>     then a single draft will be written for each.
>    The base assumption is that such a draft will only be
>    written if there someone planning to implement and
>    deploy.
>    Authors: Dependent on extension
>    Due date: Aim for San Diego
> 
>  3. Individual routing extension drafts
>     There are two dimensions to this:
>      - the different routing protocols (IGPs and EGPs)
>      - the different solution models
>      The aim should be to have one draft per protocol to provide the
>      generic mechanisms, and one draft per model per protocol to
>      provide procedures and field values etc.
>      Note that path computation functions are described under point
>      5, below.
>      As with the signaling extensions, this work will only be done 
> once
>      we understand that there is a need *and* what is needed.
>      Authors: Again dependent on deployment plans
>      Due date: Slightly later than signaling work
> 
>  4. Applicability
>     A draft to explain when it is appropriate to use which model and
>     options. The aim is not to rubbish the opposition, but to say when
>     a particular model can/should be used.
>     Much of this material can already be found in
>     draft-vasseur-ccamp-inter-area-as-te, but it may need
>     some tidying up.
>     For political/expediency reasons this may result in multiple
>     applicability drafts in the first instance.
>     Authors: A supporter of each model
>     Due date: Quite soon - to accompany signaling extensions.
> 
> 5. Path computation
>     Some solution models call for a (or many) path computation
>     servers (PCS). This demands several functions:
>     - discovery of PCS by network elements
>     - communication protocol between PCS and network elements
>     - some regulation of computation technique to avoid looping etc.
>     At the moment we are discussing precisely where this work should
>     be done, but that should not stop us starting the work within 
> CCAMP
>     since it is clearly related to the inter-area/AS solution.
> 
> 6. Advanced functions.
>     There are several advanced functions that will be required, but 
> which
>     are not part of the immediate work.
>     - Path reoptimization
>     - Protection path diversity
>     - crankback
>      We expect that once the initial work has been done on
> the solutions, it
>      will be possible to set out the requirements for these 
> functions and to
>      develop solutions based on the many drafts that are 
> already out there.
> 
> Comments please.
> 
> Thanks,
> Adrian and Kireeti
> 
> 
>

---

From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Date: Fri, 23 Apr 2004 16:23:53 +0200

Adrian,

See inline

> De : Adrian Farrel [mailto:[email-masked]] 
> Envoyé : vendredi 23 avril 2004 13:45
> À : LE ROUX Jean-Louis FTRD/DAC/LAN; [email-masked]
> Cc : [email-masked]
> Objet : Re: Proposed strategy for Inter-area/AS
> 
> 
> 
> Jean-Louis 
> 
> 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 

OK

> Perhaps I should have said "distibution of TE and other 
> information by the routing protocol or by other means". This 
> is not path computation. 
> 
> There are comments on scalability which are, of course, 
> related. There are also lots of comments about TE aggregation 
> which might be 
> 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Apr 2004 16:01:09 +0100

Hi, 

Thanks for clarifying. See below... 

>> 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). 

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. 

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!) 

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. 

. . . . . 

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? 

Thanks,
Adrian

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Mon, 26 Apr 2004 12:35:27 -0400

At 06:15 PM 4/26/2004 +0200, LE ROUX Jean-Louis FTRD/DAC/LAN wrote:
>Hi Fabio,
>
>Advertising only a subset would improve scalability, but
>this would not be enough to correclty select the best path.
>
>Let's assume that there are three paths from a given ABR X to a given 
>destination D
>Path 1: bw 100M admin group {green;blue}
>Path 2: bw 50M admin group {red; blue}
>Path 3: bw 5M admin group {red;green}
>
>and a TE-LSP L : Destination D, bw= 4M, affinity= exlude blue
>
>If you advertise only Path 1 and Path 2 as virtual links, ABR X will never 
>be selected as next ABR for this TE-LSP, while path 3 is a feasible path.

and moreover, this gets even more difficult if two ABRs must be traversed 
between the source and the destination ....

JP.

>Regards
> > De : [email-masked]
> > [mailto:[email-masked]] De la part de ricciato
> > Envoyé : lundi 26 avril 2004 09:48
> > À : LE ROUX Jean-Louis FTRD/DAC/LAN
> > Cc : [email-masked]; [email-masked]
> > Objet : Re: RE : Proposed strategy for Inter-area/AS
> >
> >
> > Hi JL,
> >
> > just a quick remark: would it make sense in this case to
> > advertise only
> > a selected subset of the N virtual links (say the two with
> > most residual
> > bw) ?
> >
> > ciao
> > fabio
> >
> > LE ROUX Jean-Louis FTRD/DAC/LAN wrote:
> >
> > >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.
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >

---

From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Date: Tue, 27 Apr 2004 09:51:25 +0200

Hi Fabio and all,

I see what you suggest, but IMHO this would not be sufficient, as an LSP affinity can be a combination of colors inclusion/exclusion

Using your proposed advertisement, there is no mean to know that there is no path through the ABR, for
an LSP bw=50M and affinity = exclude red & blue.

Basically, IMHO in case you have N paths, each with a distinct adm-group, the only solution, if you want to
compute an optimal path using this approach, is to advertise N virtual links.
Note that an ABR would have to compute and advertise many paths to many potential destinations, 
This may generate higher flooding than the direct advertisement of TE-links...
and you are likely to loose all the interest for area partitionning.

Cheers,

JL

> De : ricciato [mailto:[email-masked]] 
> Envoyé : lundi 26 avril 2004 18:59
> Objet : Re: RE : RE : Proposed strategy for Inter-area/AS
> 
> 
> Dear JL,
> 
> you´re right.
> 
> Just a quick proposal.
> In an attempt to limit the number of virtual link advertised, 
> would it make sense to advertise only K virtual links, where 
> K={number 
> of colors}, and for each of them  (say j) advertise the maximum 
> bandwdith over all links that have color j into their admin_group ?
> 
> For example, in your example (with Path 4 added)
> 
> Path 4: bw 50M admin group {red}
> 
> One should advertise 
> Virtual Link 1: bw 100M admin group {green} --->max(100M,5M) 
> Virtual Link 2: bw 50M admin group {red} --->max(50M,5M,50M) 
> Virtual Link 3: bw 100M admin group {gblue} --->max(100M,50M)
> 
> 
> Assuming that the number of colors << number of possible 
> links, this approach might cap the amount of advertisement.
> 
> But I´m not sure it works ... 
> 
> ciao
> fabio
> 
> >destination D Path 1: bw 100M admin group {green;blue} Path 
> 2: bw 50M 
> >admin group {red; blue} Path 3: bw 5M admin group {red;green}
> >
> >If you advertise only Path 1 and Path 2 as virtual links, ABR X will 
> >never be selected as next ABR for this TE-LSP, while path 3 is a 
> >feasible path.
> >
> >Regards
> >
> >JL
> >
> >
> >
> >  
> >