Subject: [forces] LFBLib v3: comment #1

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 9 Mar 2011 07:41:12 -0500

LFBLib authors,

I am going to try and post one comment a day as long
as i am getting some responses back.

Here's the first comment on section 3.

1) There is mention of port LFB which doesnt exist in the draft.
Perhaps somewhere we need to say that a "port" constitutes
a unique combination of PHY and MAC combo.

2) There is only mention of dynamic routing protocols on page 8.
ForCES can work with static routing.

3) Figure 1 is missing a few input/outputs/errors for all LFBs
depicted in that diagram. It probably makes sense for the sake
of simplicity to illustrate the important pieces like you did;
however, if that is what you are intending then please state
so in leading text.

4) To avoid the diagram being mangled I am attaching a
txt file to illustrate a small correction.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 10 Mar 2011 10:46:26 +0800

Hi Jamal,

Thks for the comments. Pls see inline the reply. 

thanks,
Weiming

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>

> a unique combination of PHY and MAC combo.

Pls review the folloing text modification to see if it is enough? 

-----original: 
In a typical packet flow within an IP router, a port LFB receives
   packets and decapsulates them to form IP level packets.  Different
   port media will have different ways to achieve the goal of
   decapsulating media-specific headers and therefore LFBs for various
   media will have to be defined although this document sticks to
   ethernet only.  IP packets emanating from port LFBs are then
   processed by a validation LFB before being further forwarded to the
   next LFB. 

----changed to: 
In a typical packet flow within an IP router, an LFB which abstracts a media port receives packets and decapsulates them to form IP level packets. Different port media will have different ways to achieve the goal of decapsulating media-specific headers and therefore various LFBs for individual media will have to be defined though this document sticks to Ethernet port media only. IP packets emanating from various media port LFBs are then processed by a validation LFB before being further forwarded to the next LFB.

> ForCES can work with static routing.
Do you mean this paragraph of text ?
-----
   (5) Usually support an interior gateway protocol (IGP) to carry out
   distributed routing and reachability algorithms with the other
   routers in the same autonomous system.  In addition, some routers
   will need to support an exterior gateway protocol (EGP) to exchange
   topological information with other autonomous systems.
------
It is just copied from rfc1812. Would you provide a text to modify the text? thanks.

> however, if that is what you are intending then please state

---- original: 
   Figure 1 shows the typical LFB processing path for the IPv4 unicast
   forwarding case with Ethernet media interfaces.  Section 7.1 will
   describe the LFB topology in more details.
-----to: 
Figure 1 shows the typical LFB processing path for the IPv4 unicast forwarding case with Ethernet media interfaces. Note that to make focused on data forwarding function, the diagram is drawn with some LFB inputs or outputs which are not related to IP forwarding missing.  Section 7.1 will describe the LFB topology in more details.
----

> txt file to illustrate a small correction.

The diagram will be drawn again to make it more lined up. thanks.

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

---

From: Tina Tsou <[email-masked]>
Date: Wed, 09 Mar 2011 18:55:49 -0800

Hi,
I would like to understand the similarity of current Forces and the current
OpenFlow 1.1. Are they totally different now?

We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 10 Mar 2011 09:09:22 -0500

Hi Weiming,

> In a typical packet flow within an IP router, an LFB which abstracts a media port receives packets and decapsulates them to form IP level packets. Different port media will have different ways to a…

Probably something along the lines of:
Packets in an IP router packets are received and
transmitted on physical media typically referred to as "ports". Different
physical port media will have different way for encapsulating outgoing
frames and decapsulating incoming frames. The different physical media will
also have different attributes that influence its behavior and how frames
get encapsulated or decapsulated. This document will only deal with ethernet
physical media. Other future documents may deal with other types of media.
This document will also interchangeably refer to a port to
be an abstraction that constitutes a PHY and a MAC as described by the LFBs
blah blah..

> It is just copied from rfc1812. Would you provide a text to modify the text? thanks.

I think an IP router will _usually_ support IGP and EGP but MUST minimally
support static input. I am not sure - i just wanted to make sure that the reader
understands that you can still conform to this document without caring about
presence of I/EGP.

> Figure 1 shows the typical LFB processing path for the IPv4 unicast forwarding case with Ethernet media interfaces. Note that to make focused on data forwarding function, the diagram is drawn with…

Good but there are a lot of inputs/outputs related to IP forwarding that
are missing (eg ECMP etc). So how about second sentence to:
Note that this diagram is simplified to illustrate the most important parts
of a simple IP forwarding FE.

I have more comments I will post - I need to find my annotated copy of the
draft.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 10 Mar 2011 09:24:10 -0500

Brief summary:
The end goal of opening up TheBigBadBox is the same.
The approach is different both from a technical, philosophical and
business point of view. ForCES is a lot more revolutionary, technically
richer, vetted over at least two interops, being done at the IETF
and could be used to implement openflow (the other direction
is not true).

cheers,
jamal

---

From: Tina Tsou <[email-masked]>
Date: Thu, 10 Mar 2011 11:45:13 -0800

Hi Jamal,
Thank and respect your summary.

Therefore, if there will be a WG "OpenFlow 1.1", is it WG Forces? Or could
be a new WG?

Best Regards,
Tina TSOU

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: Thursday, March 10, 2011 6:24 AM
To: Tina Tsou
Cc: Wang,Weiming; [email-masked]
Subject: Re: Forces and OpenFlow 1.1

Brief summary:

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 10 Mar 2011 20:35:36 -0500

Hi Tina,

If they decide to come to the IETF, it seems to be a natural fit with ForCES.

cheers,
jamal