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

From: [email-masked]
Date: Fri, 22 Jul 2011 15:38:58 +0800

Hi Frederick,
In the current operation of TE OSPF, the LSRs at each end of a TE link 
emit LSAs describing the link.The databases in the LSRs then have two 
entries (one locally generated, the other from the peer)that describe the 
different 'directions' of the link. 
For the inter-AS link, there is no IGP peering , so both of the two ASBRs 
connected by an inter-AS link only has TE link information in one 
direction(i.e.,the direction from local to remote ASBR). 

RFC5392 has extended OSPF to get the basic information about the other 
direction(i.g., Remote AS Number and Remote ASBR ID). But for other TE 
properties,such as bandwith, the ASBR can not get the latest information 
in the reverse direction(i.e.,the direction from remote ASBR to 
local)timely.In order to solve the problem , RFC5392 has introduced a 
"proxy" as following:

"In order for the CSPF route computation entity to include the link as a 
candidate path, we have to find a way to get LSAs describing its 
(bidirectional) TE   properties into the TE database.This is achieved by 
the ASBR advertising, internally to its AS,information about both 
directions of the TE link to the next AS.  The ASBR will normally generate 
an LSA describing its own side of a link; here we have it 'proxy' for the 
ASBR at the edge of the other AS and generate an additional LSA that 
describes that device's 'view' of the   link."

But how to realize the proxy is a probelm. A method  intruduced in my 
draft has solved this problem simply by selecting the proper inter-AS 
links and carrying them in a PCRep to let neighbour PCE know which 
inter-AS link satisfy the required constraints.  

Thanks a lot.

Xuerong Wang / Best Regards

Frederick Robinson <[email-masked]> 
2011-07-22 11:26

收件人
[email-masked]
抄送
JP Vasseur <[email-masked]>, [email-masked], [email-masked]
主题
Re: request timeslot for draft-wang-pce-inter-as-extentions-01

Hi Wang,

I read the draft. It is interesting but one point isn't clear for me.
Why couldn't we extend routing protocol to make border nodes get the 
bidirectional inter-AS links?

Thanks,

Frederick

> 
> Hi JP and PCEers, 
> 
> Thank you for  the promotion.We would like to trigger the 
> discussion, and greatly appreciate your comments and participatory. 
> 
> We add some scenarios to describe why we need to extend BRPC 
> procedure in the case of computing inter-AS bi-directional path. 
> 
> Suppose the inter-AS link fails in one direction(e.g., from C1 to B1). 
> As border node just have unidirectional inter-AS TE link properties,
> for a bi-direction path computation from A to Z, PCE1 doesn't know 
> that the link from C1 to  B1 can not be used. How PCEs select the 
> inter-AS links for the bidirectional path?  
> 
>  Similarly,Suppose uni-direction LSP along A1-C-B-Z1 have already been 
setup. 
> After that we setup a bi-direction LSP from A to Z, neither PCE1 nor
> PCE2 knows that whether the inter-AS link can 
> satisfy the constraints in both of the directions or not.   
> 
> For a bi-direction path computation from A to Z : 
> PCE2 computes bi-direction optimal paths(i.e.,VSPT): EGZ and FZ. 
> 
> Suppose the uni-direction inter-AS link from E to C doesn't satisfy 
> the constraints. Only inter-AS links C-F,D-E and D-Fcan 
> satisfy the constraints in bi-direction. But neither PCE1 nor PCE2 
> knows that information, they don't know which inter-AS 
> links should be selected. 
> Actually the optimal paths between exit BN of AS1 and node Z are 
> shown in red color bellow, but PCE2 cannot compute 
> these bi-direction optimal paths by adding the inter-AS links .  On 
> the other hand, PCE1 cannot compute the 
> bi-direction optimal paths by adding the inter-AS links either (i.
> e.,PCE1 can not compute the bi-direction path from A to E and A to F). 
> 
> 
> 
>  Thanks .
> 
>  Xuerong Wang / Best Regards

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

---

From: Frederick Robinson <[email-masked]>
Date: Fri, 22 Jul 2011 11:26:24 +0800

Hi Wang,

Thanks,

Frederick

setup.