Subject: Re: ForCES Intra-NE routing mechanism

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 13 Oct 2005 12:07:25 -0700

I think this could be a good Informational RFC at the least. 
I am not sure if this is what Xiaoyi Guo has in mind, but I wouldn't
have any objection to having an informational rfc on this.

Xiaoyi Guo, you should look at the Topology draft as well, there is some
overlap here.

regards
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern

2) I don't see the value in creating a new kind of forwarding table.
For 
each FE, the forwarding table it is given ought to translate an IP
prefix 
into a next hop, and the next hop into an egress port.  You seem to be 
trying to add a third layer of mapping.  The benefit I can see for such
a 
thing might be that it could reduce slightly the differences in the
tables 
across the FEs. However, I would be really unhappy at mandating such an 
architecture.

Yours,
Joel

At 05:58 AM 10/13/2005, Xiaoyi Guo wrote:
>All,
>
>I'm currently putting a draft of the ForCES Intra-NE routing mechaniam,
>and will submit it by Thusday.Below are the major points, please
comment.
>
>About ForCES Intra-NE routing mechanism
>                  -----------------
>                  |      CE       |
>                  -----------------
>                 A ^    B ^    C ^
>                  /       |       \
>                 /      A v        \
>                /      ------- B    \
>               /    +->| FE3 |<-+    \
>              /     |C |     |  |     \
>           A v      |  -------  |      v A
>           -------B |           |E -------
>           | FE1 |<-+           +->| FE2 |
>           |     |<--------------->|     |
>           ------- C             D -------
>            E ^ D|                 C ^  | B
>              |  |                   |  |
>              |  v                   |  v
>
>When a packet comes in FE1 port E and it want to forwaring to FE2 port
B,
>it must across the Intra-NE FEs.
>
>There has two ways to generate the routing paths :
>1, static configuration from FEM / CEM ,
>2, dynamic generated by system .
>
>Obviously the first method is not a good choice , so we focus on the 
>latter one.
>We aleardy know the full topology from the CE topology table , this is 
>designed and generated by
>Intra-NE topology discovery mechanism.
>
>But this topology table need to caculate and generate to the CE's 
>Intra-routing table.
>For example , in this Figure , there exist two path from FE1 to FE2, so
we 
>must use some policy
>to select a better one which the cost is smaller. The method maybe like

>the OSPF SPF tree algorithm
>or other similar algorithm.
>
>See the CE topology table
>----------------------------------------------
><Node>   <Port>   <Node>   <Port>
>   FE1                B      FE2     D
>   FE2                E      FE3     D
>   FE1                B      FE2     C
>
>We will add a Intra-FIB in each FE , this table is distributed by
master CE:
>i will add some structure such as nexthop(port) , nextNode(FE), so it 
>looks like a table as below
>
>FE1 IFIB (part)
>-----------------------------------------------------------------------
-------------------------
><Node>   <Port>   <DstNode>   <Port>   <NextNode>   <NextPort>
>   FE1             B              FE3            D            FE2 
>           D
>
>  FE2 IFIB (part)
>-----------------------------------------------------------------------
------------------------
><Node>   <Port>   <DstNode>   <Port>   <NextNode>   <NextPort>
>   FE2            E                FE3             D           FE3 
>       D
>
>When the packet arrived at FE1 , Then  FE1 find the Nexthop by
searching 
>FIB ,
>and then searching IFIB , FE1 will know the routing path is from FE1 to

>FE3 then to FE2. In FE3 ,
>only search the IFIB, the packet forward to FE2 with the correct path ,

>then FE2 will forward it out the NE .
>
>This two table searching mechanism is a bit similar to such as MPLS or 
>other VPN label pursh/pop action.
>
>The advantages as below :
>1, The Intra-NE full topylogy need not known by each FE.
>2, Intra-FE do not need the outer routing information.
>
>
>Best Regards
>
>Xiaoyi Guo
>------------------------------------------------
>Huawei Technologies.
>No. 3 Xinxi Rd., Shang-Di Information Industry Base,
>Hai-Dian District Beijing, P.R. China  100085
>Tel:   +86-10-8288-2290
>Fax:   +86-10-8288-2770
><<mailto:[email-masked]>mailto:[email-masked]>
><http://www.huawei.com>
>------------------------------------------

---

From: Xiaoyi Guo <[email-masked]>
Date: Fri, 14 Oct 2005 17:39:06 +0800

hi, Hormuzd,

Yes , this is what i think in mind.
I already take a look at the Topology draft several times.
And when i write this draft , i think i should add this section here for clarity .
If others also take this point as you , i will delete these contents from my draft later.

Best Reards,
Xiaoyi.

----- Original Message ----- 
From: "Khosravi, Hormuzd M" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 14, 2005 3:07 AM
Subject: Re: ForCES Intra-NE routing mechanism

regards
Hormuzd

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

Yours,
Joel

comment.
B,
we 

------------------------
searching