Subject: Progressing the three inter-domain I-Ds

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 9 Jan 2007 22:13:10 -0000

Hi,

We now have updated versions of the three inter-domain signaling I-Ds:

- draft-ietf-ccamp-inter-domain-rsvp-te-04.txt
- draft-ietf-ccamp-lsp-stitching-04.txt
- draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt

Our plan is:
1. WG chairs do detailed review over the next couple of weeks
2. Editors apply necessary updates
3. We hold a WG last call for the three I-Ds together

If you are interested in this work, I suggest that now might be a good time 
to remind yourself about the I-Ds, have a good read, and see if you can get 
any substantial comments in to coincide with the WG chairs' review.

Thanks,
Adrian

---

From: [email-masked]
Date: Sat, 13 Jan 2007 12:49:30 +0100

hi adrian

o) a couple of generic comments on the third doc

- the doc. states applicability to GMPLS but sometimes only ref. MPLS-TE
signaling further on e.g. section 3.1

" - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209])."

and many others in section 4.

- the are many comparison with PCE technique along the doc. - well that's 
fine but outside the scope of the document except if the purpose is to 
indicate how different techniques can be combined together and which 
interop issues may result from it

o) a couple of specific comments 

end of section 2: 

section 3.1: "* The complete list of boundary LSRs along the path"
-> list of domain identifier e.g. AS numbers also applies here ?

last § of section 3.1 is the most important one, signaling protocol are
independent of the routing topology itself, i.e. not because a node is
an ABR or an ASBR that comp. occurs but simply because he has no path 
to reach the next (loose) hop - an intermediate node should still maintain
capacity to perform such operation

section 3.3 "The path computation
   technique described in this document applies to the case of a single
   AS made of multiple IGP areas, multiples ASs made of a single IGP
   areas or any combination of the above.  For the sake of simplicity,
   each routing domain will be considered as single area in this
   document. "

-> not sure to understand the reasoning, at the end these examples must
remain illustrative and not restrict applicability - all these tutorial
like material should better go in an appendix -

section 3.1 "In any case,
   no topology or resource information needs to be distributed between
   domains (as mandated per [RFC4105] and [RFC4216]), which is critical
   to preserve IGP/BGP scalability and confidentiality in the case of TE
   LSPs spanning multiple routing domains."

then Section 4
"In terms of computation of an inter-AS TE LSP path, an interesting
   optimization technique consists of allowing the ASBRs to flood the TE
   information related to the inter-ASBR link(s) although no IGP TE is
   enabled over those links (and so there is no IGP adjacency over the
   inter-ASBR links).  ...
"Thanks to such an optimization, the inter-ASBRs TE link information
   corresponding to the links originated by the ASBR is made available
   in the TED of other LSRs in the same domain that the ASBR belongs to."

but after
"Note that no topology
   information is flooded and these links are not used in IGP SPF
   computations.  Only the TE information for the outgoing links
   directly connected to the ASBR is advertised."

-> can one of the author clarify 1) is flooding involved or not ?
2) what get's flooded and under which conditions 3) what is the 
scope of the flooding 4) how this mechanism positions against the
requirements of 4105 and 4216

o) a couple of edits
 
section 1:

ABR Router, ASBR Router - redundant R

the most important def. is the "domain" def. which can be found in the
frm doc but not recorded here this would clarify sentence like

"The mechanisms proposed in this document are also applicable to MPLS
 TE domains other than IGP areas and ASs."

ref. H-LSP and S-LSP with the appropriate docs

state that inter-domain recovery is going to be addressed in a set of
specific docs

hope this will help,
- d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
09/01/2007 23:13
Please respond to "Adrian Farrel"
 
        To:     <[email-masked]>
        cc: 
        Subject:        Progressing the three inter-domain I-Ds

Hi,

Our plan is:

If you are interested in this work, I suggest that now might be a good 
time 
to remind yourself about the I-Ds, have a good read, and see if you can 
get 
any substantial comments in to coincide with the WG chairs' review.

Thanks,
Adrian

---

From: "Peng He" <[email-masked]>
Date: Sat, 13 Jan 2007 09:55:43 -0500

Hi,

Sill about the the third doc:

1. in the "3.1.  Common assumptions" part, it is assumed that
"Boundary LSRs are assumed to be capable of performing local path
computation ..." . So I guess that ABR or ASBR has the function (or
part of) of PCE.

2. My understanding to Dimitri's questions:
I believe there is flooding here but only within the domain that the
ASBR belongs to. So now a domain includes non-ABSR LSRs and ABSR LSRs
and the links among them, AND the inter-domain links originating (not
terminating) from the ASBRS of this domain. Tthe flooding is among
these LSRs, but not between domains. So, it is still can be considered
as intra-domain flooding and it happens when the TE info changes I
guess.

3. The purpose of the above is to "improve the chance of successful
signaling along the next AS in case of resource  shortage ..." I
understand this, I just want to mention that it seems only true in
theory and the practical effect is not so good as expected. I
simulated this years ago when we extended DCR into inter-domain case
and just no encouraging results found.

Regards,
Peng

---

From: Mach Chen <[email-masked]>
Date: Mon, 15 Jan 2007 10:41:20 +0800

Dimitri and all,

After reading these docs I also have the same concern with you about inter-ASBR links flooding.
I think, in oder to perform  inter-AS path computation, inter-ASBR links fooding is desired. But 
such kind of inter-ASBR link info should include more information than "normal" TE links do, 
e.g: the inter-ASBR links info SHOULD still include the peer AS number and peer ASBR router id 
besides those link info which has been specified in rfc3630 and rfc3784.

So I think there need a document to clarify and specify inter-ASBR links flooding. we are considering to 
write such a document. If someone interested in such work, we could cooperate.

Best regards,

Mach

----- Original Message ----- 
From: <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Saturday, January 13, 2007 7:49 PM
Subject: Re: Progressing the three inter-domain I-Ds

hi adrian

end of section 2: 

then Section 4

but after
"Note that no topology

o) a couple of edits
 
section 1:

hope this will help,
- d.

        To:     <[email-masked]>
        cc: 

Hi,

Our plan is:

Thanks,
Adrian

---

From: "Peng He" <[email-masked]>
Date: Sun, 14 Jan 2007 22:26:27 -0500

Hello Mach,

I am interested in such work. But I am not sure what you said "in oder
to perform  inter-AS path computation, inter-ASBR links fooding is
desired", say, different computing methods might need different
information about the inter-AS links and various flood ranges, and if
not a general method is considered as default, it seems to me hard to
define what exact info should be flooded. Just my personal thoughts.

Regards,
Peng

---

From: Mach Chen <[email-masked]>
Date: Mon, 15 Jan 2007 13:02:57 +0800

Hi Peng,

I means that no matter what kind of path computation methods(Per-domain, BRPC, etc.) we adopt, 
if we want to compute a path spaning mutiple ASes, the compute element(Head-end, ASBR, or PCE)
SHOULD get the inter-ASBR links info.

With respect to the flooding scope and specification of inter-ASBR links info,  we need more discussion.
But I think the inter-ASBR link should have AS flooding scope.

----- Original Message ----- 
From: "Peng He" <[email-masked]>
To: "Mach Chen" <[email-masked]>
Cc: <[email-masked]>; "Adrian Farrel" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, January 15, 2007 11:26 AM
Subject: Re: Progressing the three inter-domain I-Ds

Hello Mach,

Regards,
Peng

---

From: "Peng He" <[email-masked]>
Date: Mon, 15 Jan 2007 22:17:31 -0500

Hello Mach,

I understood that the path compute element(Head-end, ASBR, or PCE)
should  have the inter-ASBR links info to compute an optimal or
near-optimal inter-domain path.

You said "But I think the inter-ASBR link should have AS flooding
scope." What do you mean by "AS flooding scope"? Is it within an AS or
among ASes? If within an AS, then that's the example shown in the
third document and mentioned in Dimitri's questions; if among ASes,
then how many ASes would be enough?

I just guess the contents of inter-AS link info to be flooded seems
easily to be decided (consider it as a special intra-AS TE link with
AS # attached), and might just need a simple document to define it;
the difficult thing is the flooding scope, which might be varied with
different path computing approaches or even the agreement among
operators.  Still seems to me hard to define a standard to rule it.
Or, leave every options open?

Regards,
Peng

---

From: Mach Chen <[email-masked]>
Date: Tue, 16 Jan 2007 12:16:12 +0800

Hi Peng,

>Sent: Tuesday, January 16, 2007 11:17 AM

>then how many ASes would be enough?

I means it's just within an AS, and it's enough for those proposed 
path computation methods, e.g: Per-Domain, BRPC, etc. 

If such inter-ASBR links are flooded among ASes, there would be scalabilty
and confidentiality issues. 

Best regards,

Mach

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Jan 2007 14:11:33 -0000

Hi Dimitri,

Thanks for your observations. We will fold them in with our review (unless 
the authors want to spin a new version first?)

> o) a couple of specific comments

Missing comment?

With regard to the discussion about advertising inter-AS TE links, you are 
right that this needs clarification. I also feel that this I-D is not the 
place to do it. *If* IGP advertisement of inter-AS TE links is supported, it 
will need documentation and this I-D can point to it.

Adrian

---

From: JP Vasseur <[email-masked]>
Date: Tue, 16 Jan 2007 09:42:57 -0500

Hi Dimitri,

> and many others in section 4.

ok.

> interop issues may result from it

Because there are indeed two path computation techniques, it is  
useful to keep these references in order to provide a fair  
comparison. We could of course come up with a separate applicability  
ID, but there are already quite a few related IDs, thus it is  
preferable to keep the text here. I'll double check if there's any  
redundancy though.

> like material should better go in an appendix -

Not sure why ?

> -> can one of the author clarify 1) is flooding involved or not ?

I'll be happy to clarify. The idea is to flood the TE info for the  
Inter-AS link(s). Note that this does not contradict the requirements  
of RFC4216:
(1) Confidentiality relates to the topology of another domain: the TE  
information flooded in a domain is only augmented by Inter-AS links,  
not to any link in another domain.
(2) Scalability: of course, flooding the TE info of a few Inter-AS  
links will not compromise the scalability of the IGP.

> requirements of 4105 and 4216

Did I clarify ? If so, I'll add a paragraph in the ID.

> state that inter-domain recovery is going to be addressed in a set of

Thanks for the edits.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 16 Jan 2007 09:50:38 -0500

Hi,

On Jan 14, 2007, at 9:41 PM, Mach Chen wrote:

> I think, in oder to perform  inter-AS path computation, inter-ASBR  
> links fooding is desired.

As pointed out in the document, this is not a MUST, but an optimization.

> But

I don't think that the peer AS number info should be included in the  
IGP for sure. You should rely on BGP for that purpose.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 16 Jan 2007 09:48:24 -0500

Hi Peng,

On Jan 13, 2007, at 9:55 AM, Peng He wrote:

> ASBR belongs to.

Right.

> So now a domain includes non-ABSR LSRs and ABSR LSRs

This is right.

Example:

<---- AS 1 --->                    <--- AS 2 ---->
                     ASBR1----ASBR2

ASBR1 advertises in AS1 the links that belongs to AS1 + the ASBR1- 
ASBR2 links.
Same thing for ASBR2.

> and just no encouraging results found.

It of course depends of the assumptions that you used in your  
simulations (topology, TMs, ...) but flooding that piece of data can  
only improve the success rate of course. To what extent ? That  
depends of a few parameters. For example, if your Inter-ASBR are over- 
provisioned, that won't help since the cause of CAC rejection is not  
likely to be because of insufficient bandwidth on your links but  
there are certainly cases where this can happen, in which case this  
will help.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 16 Jan 2007 09:53:37 -0500

Hi Mach,

On Jan 15, 2007, at 11:16 PM, Mach Chen wrote:

>> Cc: <[email-masked]>; "Adrian Farrel"  
>> <[email-masked]>; <[email-masked]>; <owner- 
>> [email-masked]>

So far, we're in sync, and this is what the ID points out. I'll  
clarify this part to avoid confusion.

> and confidentiality issues.

No (see my previous emails).

Thanks.

JP.

>> Cc: <[email-masked]>; "Adrian Farrel"  
>> <[email-masked]>; <[email-masked]>; <owner- 
>> [email-masked]>
>>> So I think there need a document to clarify and specify inter- 
>>> ASBR links flooding. we are considering to

---

From: [email-masked]
Date: Wed, 17 Jan 2007 01:21:34 +0100

hi j-p - see inline:

JP Vasseur <[email-masked]>
Sent by: [email-masked]
16/01/2007 15:42
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[email-masked]>, [email-masked], 
[email-masked]
        Subject:        Re: Progressing the three inter-domain I-Ds

Hi Dimitri,

ok.

[dp] i don't think i found much statements clarifying potential
interop aspects - hence the question becomes rather simple 

either there are prescriptive statements to be provided to ensure 
interop and henceforth these are to be addressed in this document 

or these are not prescriptive and hence an applicability document
would also do the job

otherwise there are no statements (interop is not resulting in any
specific behaviour) and then there is no need to perform any sort
of reference to the PCE technique

Not sure why ?

[dp] e.g. the last sentence of the paragraph pointed here above shows
the issue - why this doc considers (from the examples it provides) and
or restricts routing domain (AS) composed by a single area ?

[dp] point 3, you flood the inter-AS information "inside the connected 
AS" but what is the flooding scope ? - flooding of a link local info
inside the AS that is terminating that end of the link -

[dp] i think that the optimization provided here holds iff that info
is made available to the head-end area of that AS not only the tail-
end area

Thanks for the edits.

JP.

---

From: [email-masked]
Date: Wed, 17 Jan 2007 01:45:11 +0100

hi adrian - see inline for a couple of clarifications

16/01/2007 15:11
 
        cc:     <[email-masked]>

Hi Dimitri,

Missing comment?

[dp] yes the following sentence

"the appropriate technique must be driven by the set of
   requirements for the paths attributes and the applicability to a
   particular technique with respect to the deployment scenario"

the beginning of the sentence is not recommending an approach, 
the "must" as indicated becomes authoritative, this sentence is
cyclic and reads 

"the appropriate technique must be driven by the applicability 
to a particular technique with respect to the deployment scenario"

is the term "path attribute" referring to any kind of LSP attr. ?
if yes please state so, if not please use the correct term ?

right that this needs clarification. I also feel that this I-D is not the 
place to do it. *If* IGP advertisement of inter-AS TE links is supported, 
it 
will need documentation and this I-D can point to it.

[dp] i would agree that the reasoning throughout the draft is deductive
and the proposed method defined for MPLS-TE (how does this works for bi-
directional LSP for inst. when the inter-domain can be crossed by both
bi and unidirectional LSPs) is put in a path.comp context 

[dp] i mean here that beyond the specific per-domain operations the only
protocol addition is an OSPF one (i leave this question to whether needs
for a separate i-d is more appropriate, but the level of detail must be
the same in both cases, not because embedded in this i-d that accurate
description of processing shall be skipped)

Adrian

---

From: ZhangRenhai <[email-masked]>
Date: Wed, 17 Jan 2007 12:11:19 +0800

> IGP for sure. You should rely on BGP for that purpose.
[ZhangRenhai>] maybe BGP is not enough for some circumstance, take this
scenario for example:
                    
                     /  ASBR4
ASBR1--------ASBR2--
                    \  ASBR3
------AS 1----------||-----AS 2----------

ASBR2 in AS 1 would only advertise the optimal route received respectively
from ASBR3 and ASBR4 (both are from AS 2) to ASBR1, ASBR1 also doesn't have
the full knowledge of topology(such as which AS the ASBR2 is connected to
and which router is in that AS)between the two AS. PCE would have the
similar problem when performing the brpc.
Another issue, when ASBR1 receives a path mesg from upstream domain
containing a loose ERO:AS number(say AS2), there should be a method for it
to locate the asbr(say ASBR2) in the local domain connected to AS2. 

Regards,
Zhang Renhai

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 17 Jan 2007 11:00:53 -0000

Hi,

Since this discussion is blossoming, it can have its own thread...

I'd like to try to bring some focus.

The motivation seems clear...
When computing a path through one AS into another AS, the computation point 
needs to know about TE links that connect to the next AS. This enables it to 
select:
- A TE link that connects to the next AS
- A TE link that is suitable for the LSP.

Other questions about reachability and TE connectivity across the next AS 
are out of scope and have been defined as problems that PCE is used to 
solve. This is an important point! We are not talking about distributing 
information to provide a graph to compute multi-AS TE paths. That is (IMHO) 
out of scope and what PCE was invented to solve.

I see two scenarios.
1. An ASBR has two links to the next AS.
2. An AS has two ASBRs to the next AS.
In either case, the AS may have multiple ASBRs.

The path computation point must determine:
a. The set of ASBRs that connect to the next AS.
b. Which ASBR to use.
c. Which inter-AS link to use.

Some cases are easy:
- If the ERO already includes the ASBR address
  no choice to be done
- If the ASBR has multiple inter-AS links then
  the choice can be a local matter (no
  advertising required)

But other cases require advertisement of the inter-AS link as a TE link 
with:
- the normal TE information
- an indication that this is an inter-AS link
- the identity of the remote ASBR
- the identity of the remote AS

This information is needed through-out the local AS. That is, although all 
of the ASBRs may be interested for LSPs that entirely cross the local AS, 
and although a PCE could be a BGP speaker, the information is also needed 
for LSPs that are originated within the AS.

Thus we must decide how paths for LSPs that exit the AS will be computed:

- If we require computation by a PCE that
  is (somewhat) centralised within the AS
  we can use BGP to distribute the information
  and require that the PCEs are BGP speakers.
  (Note that the information is only needed
  within the local AS, so we would limit its
  flooding by BGP.)

- If we require computation by any LSR in
  the AS (i.e. PCE function is fully
  distributed) then we require IGP flooding
  of the information across the whole AS.

In both cases the cost is not particularly high since the number of inter-AS 
TE links will not be large.

Thanks,
Adrian

---

From: [email-masked]
Date: Wed, 17 Jan 2007 12:26:41 +0100

adrian

agreed on the analysis - there is one additional case that 
needs to be addressed

AS_1 is connected to AS_2 and AS_3 both connected to AS_4

the ERO, includes AS_1 and AS_4, perfectly clear there is
no intention to pass AS_2 - AS_4 and AS_3 - AS_4 TE link
information to AS_1

but what about AS_1 - AS_2 and AS_1 - AS_3 whose info. is
defacto available 

the issue is one sentence, the initial linearization does
not hold in the generic case of loose abstract AS's

comments ?

-d.

17/01/2007 12:00
 
        To:     "ZhangRenhai" <[email-masked]>, "'JP Vasseur'" 
<[email-masked]>, "'Mach Chen'" <[email-masked]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>
        Subject:        Advertising of inter-AS TE links

Hi,

The motivation seems clear...
When computing a path through one AS into another AS, the computation 
point 
needs to know about TE links that connect to the next AS. This enables it 
to 
select:
- A TE link that connects to the next AS
- A TE link that is suitable for the LSP.

information to provide a graph to compute multi-AS TE paths. That is 
(IMHO) 

I see two scenarios.

Some cases are easy:

In both cases the cost is not particularly high since the number of 
inter-AS 
TE links will not be large.

Thanks,
Adrian

---

From: JP Vasseur <[email-masked]>
Date: Wed, 17 Jan 2007 07:12:13 -0500

Hi,

On Jan 16, 2007, at 11:11 PM, ZhangRenhai wrote:

> ASBR2 in AS 1

In your example, both ASBR1 and ASBR2 are in AS1 ?

> would only advertise the optimal route

I guess that you're referring to the BGP route here.

> received respectively
> and which router is in that AS)between the two AS.

.... This is IP Inter-AS routing ... With the per-domain approach  
(inter-AS), BGP can of course be used, thus all necessary information  
for ASBR selection is available.

> PCE would have the

I don't see the scenario you're referring to ...

JP.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 17 Jan 2007 12:15:07 -0000

Yes, Dimitri, I agree that the situation you describe is not solved by 
limited flooding of inter-AS TE links within only their adjacent ASes.

It is my view that this wider problem space has been delegate for resolution 
by PCE. That is, in order to fully resolve the problem by flooding of TE 
link information it would be necessary to also aggregate TE reachabilty 
across AS_2 and AS_3 in your example. Such aggregation is non-trivial given 
the number of TE parameters and the number of potential routes, and so we 
would have at least one of:
- excess information flooding
- excess aggregation processing
- valueless information flooding.
In the light of these options we (the Routing Area) decided to pursue PCE as 
a solution.

Adrian

----- Original Message ----- 
From: <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; "'JP Vasseur'" <[email-masked]>; "'Mach Chen'" 
<[email-masked]>; <[email-masked]>; "ZhangRenhai" 
<[email-masked]>
Sent: Wednesday, January 17, 2007 11:26 AM
Subject: Re: Advertising of inter-AS TE links

---

From: [email-masked]
Date: Wed, 17 Jan 2007 22:35:02 +0100

adrian

what i am saying is that flooding inter-AS TE link when the topology
is in Y (AS_1 connected to both AS_2 and AS_3) is de-facto covered

the point is that PCE or not PCE the resulting problematic in terms
of blocking is identical

either the problem is linearized beforehand and then both solution
would lead to a result or it is not and then the path discovery aka
path exploration issue is left unsolved by both techniques

thanks,
- d.

17/01/2007 13:15

It is my view that this wider problem space has been delegate for 
resolution 
by PCE. That is, in order to fully resolve the problem by flooding of TE 
link information it would be necessary to also aggregate TE reachabilty 
across AS_2 and AS_3 in your example. Such aggregation is non-trivial 
given 
the number of TE parameters and the number of potential routes, and so we 
would have at least one of:
- excess information flooding
- excess aggregation processing
- valueless information flooding.
In the light of these options we (the Routing Area) decided to pursue PCE 
as 
a solution.

Adrian

----- Original Message ----- 
From: <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; "'JP Vasseur'" <[email-masked]>; "'Mach 
Chen'"

---

From: ZhangRenhai <[email-masked]>
Date: Sat, 27 Jan 2007 15:00:49 +0800

Hi, Adrian
I have submitted a draft last year in which the BGP extension to advertise
inter-as link connection information is described:
http://tools.ietf.org/wg/pce/draft-zhang-pce-locate-asbr-00.txt
I'm now drafting the problem statements and corresponding IGP(so far only
OSPF in the doc) extension, it's upcoming soon.

Regards,
Zhang Renhai

point
to
(IMHO)
inter-AS