Subject: RE: [Pce] A New Internet-Draft on Advertising of inter-AS TE links

From: "Greg Mirsky" <[email-masked]>
Date: Mon, 5 Feb 2007 13:24:43 -0800

Dear Zhang,
thank you for your response. I've read the newer version of the draft as
you suggested and below are my questions:
- would you agree that usually ASBRs are eBGP speakers and are fully
mesh connected. In that case eBGP can be viable solution for the
inter-AS TE links computation by ASBR.
- I'm concerned with scaling aspect of flooding inter-AS TE information
throughout both AS and an area and I see that you're concerned as well
(SHOULD for Type 10 and MAY for Type 11). I think that it would be
helpful if use of both Type 10 and Type 11 for inter-AS TE Link
advertisement be illustrated by scenarios. I think that use of area
scope makes these OSPF extensions less applicable to inter-AS path
computation by the head-end LSR/LER.
- Could you please illustrate which links are excluded by the following:
"   Routers or PCEs that are capable of processing advertisements of 
   inter-AS TE links SHOULD NOT use such links to compute paths that 
   exit an AS to a remote ASBR and then immediately re-enter the AS. 
   Such paths would constitute extremely rare occurrences and MUST only 
   be allowed as the result of specific policy configuration at the 
   router or PCE computing the path."
Are there two links that interconnect a pair of ASBRs that belong to two
different neighboring ASes?

	Regards,
		Greg

-----Original Message-----
From: Zhang Renhai [mailto:[email-masked]] 
Sent: Thursday, February 01, 2007 6:36 PM
To: Greg Mirsky; [email-masked]; [email-masked]
Subject: Re: [Pce] A New Internet-Draft on Advertising of inter-AS TE
links

Hi, Greg

Thanks a lot for your question.
See inline please.

Dear Zhang,
I have couple questions related to Link ID of inter-AS link. According
to the document it is the Router ID of Remote ASBR. 
[ZRH]Yes, and this can be easily got by manual configuration in the
local ASBR.

My question:
- as I understand the mechanism of how TE information for links R6-R9
and R8-R10 is populated into R5's TE DB is outside the scope of this
document. I this mechanism is not IGP but EGP (BGP), then what is the
benefit to introduce new LSA in IGP (OSPF) and not use exisitng
mechanisms.

[ZRH]I think BGP could also be another alternative especially for PCE
scenario, but it's not very applicable to per-domian method because the
inter-AS TE information may be needed throughout the local AS in case
that the path computation function is distributed among LSRs in the
local AS, and BGP can hardly advertise the TE information among those
LSRs if BGP sessions are not established between the ASBR and those
LSRs. So IGP extension is considered in this draft.

We have submitted the revised version of this draft, hoping make the
problem statement more clear, and relax the use of type 11 opaque lsa,
also allow Type 10 lsa (by which the advertising scope is an area of
OSPF).
http://www.ietf.org/internet-drafts/draft-chen-ccamp-ospf-interas-te-ext
ension-01.txt

Cheers,
Zhang Renhai

Regards,
Greg

PS. I think that OSPF WG needs to be informed as well.

-----Original Message-----
From: Zhang Renhai [mailto:[email-masked]]
Sent: Tuesday, January 30, 2007 7:38 PM
To: [email-masked]; [email-masked]
Subject: [Pce] A New Internet-Draft on Advertising of inter-AS TE links

Hi, allWe have just submitted the following draft in which we describe
some problemsin inter-AS TE scenarios and the corresponding OSPF
extension is introduced.PCE environment is also considerd in this I-d so
I'd also like pce working groupto pay attention to it.we'd highly
appreciate your comments.Thanks a lot,Zhang Renhai & Mach A New
Internet-Draft is available from the on-line Internet-Drafts 
directories.

Title : OSPF Extensions in Support of Inter-AS (G)MPLS TE 
Author(s) : M. Chen, R. Zhang
Filename : draft-chen-ccamp-ospf-interas-te-extension-00.txt
Pages : 9
Date : 2007-1-30

   This document describes extensions to the OSPF to support inter-AS 
   Traffic engineering (TE). It defines OSPF extensions for the flooding

   of inter-AS links information which can be used to perform inter-AS 
   path computation. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-ccamp-ospf-interas-te-ext
ension-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body
of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-chen-ccamp-ospf-interas-te-extension-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
mailserv at ietf.org.
In the body type:
"FILE
/internet-drafts/draft-chen-ccamp-ospf-interas-te-extension-00.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-chen-ccamp-ospf-interas-te-ext
ension-00.txt> 
_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 6 Feb 2007 00:11:49 -0000

Hi Greg,

> - would you agree that usually ASBRs are eBGP speakers
> and are fully mesh connected. In that case eBGP can be
> viable solution for the inter-AS TE links computation by
> ASBR.

So the question has to be:
Do other nodes apart from ASBRs need this information?

What about an ingress LSR trying to compute a path out of the AS?

If we require that the ingress LSR always consults an external PCE that is a 
BGP speaker, then I guess this is fine, but most LSRs today are capable of 
path computation and could handle this case (for example, for the pd-path 
scenario) without needing to consult an external PCE.

> - I'm concerned with scaling aspect of flooding inter-AS TE
> information throughout both AS and an area

I have this concern, too, but I wonder how many TE links we are talking 
about, and how this compares with the number of TE links within an area.

> and I see that  you're concerned as well (SHOULD for Type
> 10 and MAY for Type 11). I think that it would be
> helpful if use of both Type 10 and Type 11 for inter-AS
> TE Link advertisement be illustrated by scenarios. I think
> that use of area scope makes these OSPF extensions less
> applicable to inter-AS path computation by the head-end
> LSR/LER.

Yes, that would be the case.
I agree that we need to look more closely at the scenarios. I don't think we 
have given enough thought to the nested domains case (i.e. areas in ASes) 
given that both pd-path and brpc (largely) treat the nested case as simply a 
flat sequence.

> different neighboring ASes?

Renhai can comment, but I assumed that this meant that two ASes are linked 
by more than two TE links. The LSP should not under normal circumstances 
leave AS1 to AS2 through TE link 1 and return to AS1 from AS2 through TE 
link 2.

The example you give (ASBR1 in AS1 connects to ASBR2 in AS2 with two links, 
the LSP goes out on one and back on the other) would be detected as a loop 
in RSVP-TE, and would not offer any benefit anyway.

Regards,
Adrian

---

From: JP Vasseur <[email-masked]>
Date: Mon, 5 Feb 2007 20:45:10 -0500

Hi Adrian,

On Feb 5, 2007, at 7:11 PM, Adrian Farrel wrote:

> If we require that the ingress LSR always consults an external PCE  
> that is a BGP speaker, then I guess this is fine, but most LSRs  
> today are capable of path computation and could handle this case  
> (for example, for the pd-path scenario) without needing to consult  
> an external PCE.
>
> I have this concern, too, but I wonder how many TE links we are  
> talking about, and how this compares with the number of TE links  
> within an area.
>

It is probably negligible ... Note that by contrast with the approach  
proposing to flooding Inter-ASBR TE LSP, we're only looking at  
flooding the TE information of the inter-ASBR *links*.

> I agree that we need to look more closely at the scenarios. I don't  
> think we have given enough thought to the nested domains case (i.e.  
> areas in ASes) given that both pd-path and brpc (largely) treat the  
> nested case as simply a flat sequence.

Looking at the nested case, what would be the point of domain-scope  
since all TE-related info for the intra-area links have an area scope ?

> Renhai can comment, but I assumed that this meant that two ASes are  
> linked by more than two TE links. The LSP should not under normal  
> circumstances leave AS1 to AS2 through TE link 1 and return to AS1  
> from AS2 through TE link 2.
>
> The example you give (ASBR1 in AS1 connects to ASBR2 in AS2 with  
> two links, the LSP goes out on one and back on the other) would be  
> detected as a loop in RSVP-TE, and would not offer any benefit anyway.

Thanks.

JP.

---

From: Zhang Renhai <[email-masked]>
Date: Tue, 06 Feb 2007 14:11:32 +0800

Hi,

See in-line please.

>> viable solution for the inter-AS TE links computation by
[ZRH]What do you mean by "eBGP", should it be "iBGP"?
> about, and how this compares with the number of TE links within an area.
[ZRH]Indeed, so I don't think the additional advertisement in this draft will 
bring out a new scalability issue.

>> TE Link advertisement be illustrated by scenarios. 
[ZRH]Indeed, as Adrian said below, we still havn't consider very clear some
inter-AS TE applications, consequently, the way for choosing  type 11 or type 10 is not 
given in the draft so far. I just want to relax it for the future discussion and revise this accordingly.

I think
>> applicable to inter-AS path computation by the head-end
[ZRH]Currently, I also think the type 11 may be the batter choice. but I don't think now we have
enough proof to abandon the use of type 10.
> leave AS1 to AS2 through TE link 1 and return to AS1 from AS2 through TE 
[ZRH]Yes, here I meant that we should have some method to prevent computation loop.
Think that there are two pairs of ABSR (R1, R2 belong to AS1 and R3, R4 belong to AS2)
and two links interconnect them(R1 connected with R3, R2 connected with R4 )
and a intra-AS link interconnects R3 and R4. There would be a possibility of computation
loop.

Regards,
Zhng Renhai

---

From: Zhang Renhai <[email-masked]>
Date: Tue, 06 Feb 2007 14:26:26 +0800

Hi, JP

See in-line please.

> since all TE-related info for the intra-area links have an area scope ?
[ZRH]I try to give an answer.
With a new sub-tlv(remote AS number)and a new link type
(inter-AS link type) are specified, in a multi-areas AS, the entry ASBR 
when receving a path mesg can get the exit ASBR(in another area) with
this AS-scope advertisement and the path mesg(downstream AS number
is given in ERO). then, the inter-area computation can be performed.

Regards,
Zhang Renhai

---

From: "Peng He" <[email-masked]>
Date: Tue, 6 Feb 2007 21:35:56 -0500

I agreed with the following:

"... we need to look more closely at the scenarios. I don't
> since all TE-related info for the intra-area links have an area scope ?"

I guess following the thinking line of this draft, we might need
another extension so as to advertising "inter-area" TE links into
non-backbone areas, or, just treat one area as a "domain"?

And in Renhai's "[ZRH]I try to give an answer.", last line, how to
perform this inter-area computation? per-area? or Backward Recursive
Path Computation in a multi-area AS?

Regards,
Peng

---

From: Zhang Renhai <[email-masked]>
Date: Wed, 07 Feb 2007 14:52:02 +0800

Hi, Peng

> non-backbone areas, or, just treat one area as a "domain"?
Not sure if there really are inter-area TE links. Apart from the inter-AS links,
all physical links exist exactly in one area for sure.

> Path Computation in a multi-area AS?
Currently, there is no limitation of computation method, I think this is not what
is intended to be discussed in this draft. However, this draft does provide the 
necessary info no matter which method is deployed.

Thanks,
Zhang Renhai

---

From: JP Vasseur <[email-masked]>
Date: Wed, 7 Feb 2007 07:41:17 -0500

** with no PCE co-chair hat **

> non-backbone areas, or, just treat one area as a "domain"?

!!! I firmly disagree ... this would mean doing TE aggregation for  
inter-area MPLS TE.
Please refer to my previous email wrt to this type of solution, that  
has been discussed
in length and rejected (please refer to RFC4105 + MLs archives).  
There is a fundamental
difference between flooding the Inter-AS TE links and what you call  
the inter-area TE links
(TE aggregation).

> perform this inter-area computation? per-area?

Looks like we're in a loop here ... pd-domain path computation and  
PCE-based have
been designed for that.

Thanks.

JP.

> or Backward Recursive