Subject: Re: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 2 Aug 2011 09:55:26 +0200

Hi, 

If I understand correctly the problem PCE (i+1) has complete knowledge the inter AS link (i+1) -> i but not the i->(i+1) link properties (upstream).

First I would tend to understand the following section of RFC5441 as : 

  PCE (i) can verify the link properties in the i->(i+1) direction  

This should solve the problem mentioned except in the case the algorithm require to know the link properties in both direction at the same time, but the draft does not address this problem either.

Please indicate if I missed something.

“

Step i:

   For i=n-1 to 2: PCE(i) computes VSPT(i), the tree made of the

   shortest constrained paths between each BN-en(j,i) and the TE LSP

   destination.  It does this by considering its own TED and the

   information in VSPT(i+1).

   In the case of inter-AS TE LSP computation, this also requires adding

   the inter-AS TE links that connect the domain(i) to the domain(i+1).

“

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext JP Vasseur
Sent: Wednesday, July 27, 2011 12:05 AM
To: Fatai Zhang
Cc: [email-masked]; [email-masked]; 王磊
Subject: Re: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01

That was my question too

On Jul 26, 2011, at 1:55 PM, Fatai Zhang wrote:

Hi all,

RFC5392 is a kind of mechamism and it is already there.

Why we need to define another solution based on some nonexistent assumption?

 

Fatai

Thanks

	----- Original Message -----

	From: JP Vasseur <mailto:[email-masked]> 

	To: [email-masked]

	Cc: [email-masked] ; [email-masked] ; ͵ <mailto:[email-masked]> 

	Sent: Tuesday, July 26, 2011 1:20 AM

	Subject: Re: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01

	Hi,

	On Jul 25, 2011, at 11:16 AM, [email-masked] wrote:

	
	Hi JP, 
	
	IMO, we don't need two methods. The method of extending IGP may impact on large aspect. 
	Extending BRPC and PCEP defined in this draft is enough. 

	So let the WG decide which one of the methods is most appropriate

	Thanks.

	JP.

	Thanks, 
	
	Xihua 

JP Vasseur <[email-masked]> 
ȋ:  [email-masked]

2011-07-25 ςΧ 08:30

ʕȋ

͵ <[email-masked]>

ˍ

[email-masked]

ַ̢

Re: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01

	
	
	Thanks for your feed-back. It would be interesting to hear from the WG if indeed 
	we need two methods. To each specific problem we can certainly find a number 
	of way to solve it, but let's try to make sure that we do not specify a new technique 
	if we can use what exist today. 
	
	WG ? 
	
	Thanks. 
	
	JP. 
	On Jul 25, 2011, at 12:25 AM, ͵ wrote: 

	Hi, Xuerong and PCEers
	
	I have read the draft. It provides an alternate method that extends
	BRPC and PCEP protocol to get TE information of Inter-AS biderectional
	links. In my opinion, It is useful for the smooth upgrade of existing
	MPLS/GMPLS networks to support Inter-AS bidirectional path
	computation, because it need not any extension or modification to the
	IGP (such as OSPF and IS-IS) used in MPLS/GMPLS-enabled
	routers/switches. However, the method of IGP extension is also
	applicable and suitable for new network-equipments. So, I think there
	is no conflict between these two metods. The draft could be used in
	the scenario where the IGP extension of Inter-AS biderectional links
	can not be supported.
	
	Thanks.
	
	Lei Wang
	Tsinghua University, Beijing, China
	[email-masked] <mailto:[email-masked]>  or [email-masked] <mailto:[email-masked]> 
	_______________________________________________
	Pce mailing list
	[email-masked] <mailto:[email-masked]> 
	https://www.ietf.org/mailman/listinfo/pce <https://www.ietf.org/mailman/listinfo/pce> 

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

	
________________________________

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

---

From: Ramon Casellas <[email-masked]>
Date: Tue, 02 Aug 2011 10:28:12 +0200

Salut Cyril, all

On 08/02/2011 09:55 AM, Margaria, Cyril (NSN - DE/Munich) wrote:
>
> Hi,
>
> If I understand correctly the problem PCE (i+1) has complete knowledge 
> the inter AS link (i+1) -> i but not the i->(i+1) link properties 
> (upstream).
>
Or seen the other way round, the PCE(i) does not have the TE link 
ASBR(i+1) -> ASBR(i) -- I should say does not have it by OSPF-TE InterAS 
extesions -- I nitpick since  I humbly believe that, in the spirit of 
BRPC, the role of PCE(i+1) should stop at entry ASBR. Reducing paths / 
trimming and applying BRPC should be done by PCE(i) eventually in a two 
step: interAS + own AS.

>   PCE (i) can verify the link properties in the i->(i+1) direction
Yes, OSPF-InterAs [RFC5392] addresses this.

> This should solve the problem mentioned except in the case the 
> algorithm require to know the link properties in both direction at the 
> same time, but the draft does not address this problem either.
>
Indeed, the problem is _bidirectional_ LSPs. The draft does address this 
by "embedding" the upstream link in the BRPC response. For 
unidirectional LSPs, the existing method works out of the box. In this 
sense, if PCE(i) just constructs a generic graph parsing both opaque 
types, it can just apply BRPC as in a multi-area, since its "TED" would 
include the InterAs links anyway.

> "
> "
For bidirectional it would also need the InterAS TE links that connect 
domain(i+1) to domain(i), e.g the TE link advertised by ASBR(i+1).

Hypothetically / theoretically, we have several solutions

* a proxy injects opaque 10 or 11 opaque type 6 advertised by ASBR(i+1) 
within domain(i+1) into domain(i) [*]

* some adjacency is brought up between ASBRs which exchange both sides 
of the TE link. RFC 5392 seems to exclude this.

* the TE links are included in the response within the PCRep when vspt=1 
and some other flag

Thanks

Ramon

[*] RFC5392

4.1.  Origin of Proxied TE Information

    Section 4 describes how an ASBR advertises TE link information as a
    proxy for its neighbor ASBR, but does not describe where this
    information comes from.
(...)
    to obtain some of the required configuration
    information from BGP.  Whether and how to utilize these possibilities
    is an implementation matter.

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 2 Aug 2011 10:46:11 +0200

Hi Ramon, 

From: ext Ramon Casellas [mailto:[email-masked]] 
Sent: Tuesday, August 02, 2011 10:28 AM
To: [email-masked]; Margaria, Cyril (NSN - DE/Munich)
Subject: Re: [Pce] request timeslot for
draft-wang-pce-inter-as-extentions-01

Salut Cyril, all

Hi, 

[Cyril] If one follow strictly the rfc, yes, but the text could be
extended (via errata for example)

This should solve the problem mentioned except in the case the algorithm
require to know the link properties in both direction at the same time,
but the draft does not address this problem either.

Indeed, the problem is _bidirectional_ LSPs. The draft does address this
by "embedding" the upstream link in the BRPC response. For
unidirectional LSPs, the existing method works out of the box. In this
sense, if PCE(i) just constructs a generic graph parsing both opaque
types, it can just apply BRPC as in a multi-area, since its "TED" would
include the InterAs links anyway.
[Cyril]  : well, for bidirectional LSP you need to check the properties
in both direction, but both direction are not required to be checked at
the same time : PCE (i+1) check the inter-AS link in direction i+1->i
(one direction); PCE (i) check the inter-AS link in direction i->(i+1).

In case the algorithm really need to consider both te-properties
(upstream and downstream)  you would need the TE-properties to be known
by PCE(i). I Currently doubt that such requirement from an algorithm
exist, if there is a example of an algorithm that really requires it
(with BRPC and Dijkstra  I think not), its welcomed.

The draft does include the inter-as link identifiers (which are known)
but not their TE-properties, so in this regard the draft is not solving
the problem.

"

"

Thanks

Ramon

[*] RFC5392

---

From: Ramon Casellas <[email-masked]>
Date: Tue, 02 Aug 2011 11:52:05 +0200

El 02/08/2011 10:46, Margaria, Cyril (NSN - DE/Munich) escribió:
>
> Hi Ramon,
>
> *From:*ext Ramon Casellas [mailto:[email-masked]] **
>
>
> Indeed, the problem is _bidirectional_ LSPs. The draft does address 
> this by "embedding" the upstream link in the BRPC response. For 
> types, it can just apply BRPC as in a multi-area, since its "TED" 
> would include the InterAs links anyway.
>

> [Cyril]  : well, for bidirectional LSP you need to check the 
> properties in both direction, but both direction are not required to 
> be checked at the same time : PCE (i+1) check the inter-AS link in 
> direction i+1->i (one direction); PCE (i) check the inter-AS link in 
> direction i->(i+1).
>
[Ramon] Yes,  good point. I was sticking/assuming  BRPC as in current 
RFC5441 (narrow minded :) ?) . As you stated BRPC would need to be 
extended / clarified to allow this use case, and as far as I understood, 
draft-wang covers this, where the TE links that have been 
included/excluded by PCE(i+1) should be notifed to PCE(i) as the draft 
proposes, shouldn't they?

> (upstream and downstream)  you would need the TE-properties to be 
> known by PCE(i). I Currently doubt that such requirement from an 
> algorithm exist, if there is a example of an algorithm that really 
> requires it (with BRPC and Dijkstra  I think not), its welcomed.
>
[Ramon] Good point too. Even in intra-domain case, without extra 
assumptions such as both TE metrics are equal in both directions, it is 
not straightforward to compute the shortest bidirectional path. CSPF can 
check both directions of the TE link at the same time to insure that 
(asymmetric) unreserved bandwidth for that priority is enough when 
considering a link for relaxation. In any case, since only single 
InterAS links are to be considered, I agree such requirement is not clear.

> but not their TE-properties, so in this regard the draft is not 
> solving the problem.
>

So, to get the whole picture, let's try to summarize:

a) If a single entity (PCE(i)) is able to know TE atts for both 
directions, current BRPC is ok. RFC5392 does not solve how, and other 
routing extensions would be needed, or TE attributes manually provisioned

b) Otherwise, both directions of InterAS links should be checked 
independently, but this requires extending RFC5441, PCE(i+1) notifying 
of excluded / included links and draft-wang-pce-inter-as-extentions-01 
addresses this.

I guess my point, probably not well explained in previous mails, is that 
I would slightly prefer a) provided a good solution allows the upstream 
InterAS links to be known although I would not object to b) since no 
such good solution exists?.

Finally, I am a bit confused by your last statement. If b) is considered 
(i.e. independent checking, and link exclusion) what problem is left to 
solve? sorry for being dense.

Thanks
R.

---

From: [email-masked]
Date: Wed, 3 Aug 2011 15:02:55 +0800

Ramon Casellas <[email-masked]> 
发件人:  [email-masked]
2011-08-02 17:52

收件人
"Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
抄送
[email-masked]
主题
Re: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01

 
Indeed, the problem is _bidirectional_ LSPs. The draft does address this 
by "embedding" the upstream link in the BRPC response. For unidirectional 
LSPs, the existing method works out of the box. In this sense, if PCE(i) 
just constructs a generic graph parsing both opaque types, it can just 
apply BRPC as in a multi-area, since its "TED" would include the InterAs 
links anyway.

[Cyril]  : well, for bidirectional LSP you need to check the properties in 
both direction, but both direction are not required to be checked at the 
same time : PCE (i+1) check the inter-AS link in direction i+1->i (one 
direction); PCE (i) check the inter-AS link in direction i->(i+1).
     [Xuerong Wang]:If every ASBR only connect to one ASBR, PCE(i+1)and 
PCE(i) can check the inter-AS link seprately.But consider following 
scenario,there are two inter-AS bi-direction links connect to 
ASBR4(i.e.,link A and link B),PCE2 must let PCE1 know which of them 
satisfy the constraints in direction i+1->i.  Similar situation is the 
inter-AS bi-direction links connect to ASBR5 (There are two inter-AS 
bi-direction links connect to ASBR5,i.e.,link C and link D).

In case the algorithm really need to consider both te-properties (upstream 
and downstream)  you would need the TE-properties to be known by PCE(i). I 
Currently doubt that such requirement from an algorithm exist, if there is 
a example of an algorithm that really requires it (with BRPC and Dijkstra 
I think not), its welcomed.
[Ramon] Good point too. Even in intra-domain case, without extra 
assumptions such as both TE metrics are equal in both directions, it is 
not straightforward to compute the shortest bidirectional path. CSPF can 
check both directions of the TE link at the same time to insure that 
(asymmetric) unreserved bandwidth for that priority is enough when 
considering a link for relaxation. In any case, since only single InterAS 
links are to be considered, I agree such requirement is not clear.

The draft does include the inter-as link identifiers (which are known) but 
not their TE-properties, so in this regard the draft is not solving the 
problem.

[Xuerong Wang]:I think PCE(i+1) need not to include TE-properties of 
inter-AS links, because the selected inter-AS links already satisfy the 
required constraints,such as bandwith. Perhaps the only TE-property need 
to carry is TE metrics. But in the case of co-routed bidirectional LSP 
computation,maybe TE metrics need to be equeal in both directions? Or if 
there is indeed exist such requirement,the metric can carry in the PCRep 
too.

[Xuerong Wang]:At first,in the case of bidirectional LSP computation,there 
indeed exist some problem as discussed in the maillist.And RFC5392 also 
point out the problem.Secondly,inter-AS computation is the very important 
scenario of PCE application,so we need to solve the problem.RFC5392 
introduces a method of IGP proxy,but how to do it is not clear. Proxy 
method should not be a local mechanism because it is related to the 
co-operate among different carrier.So at last,how to solve the prolem must 
be standalized. The method in draft-wang is very simple and valid. 
b) Otherwise, both directions of InterAS links should be checked 
independently, but this requires extending RFC5441, PCE(i+1) notifying of 
excluded / included links and draft-wang-pce-inter-as-extentions-01 
addresses this.

I guess my point, probably not well explained in previous mails, is that I 
would slightly prefer a) provided a good solution allows the upstream 
InterAS links to be known although I would not object to b) since no such 
good solution exists?.

[Xuerong Wang]:There are some cases that can not check the both directions 
of InterAS links independently. I'v described the scenario above in this 
mail. 

Thanks 
R.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.