Subject: [forces] comments #13

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 16 Aug 2011 06:55:43 -0400

I still have a few comments, but we are getting close:

----------
37) 5.3.4.1
"Two output ports are defined to output results."
to:
"Two output LFB ports are defined."

38) 5.3.4.1
"ICMP packet needs to be generated"
Just like before, i think it would be valuable at least to
state what these ICMP packets are or quote some relevant RFC and say
"as described in RFC blah"

39)5.3.4.1
"For example, there are Ethernet and other
tunnel Encapsulation, then BasicMetadataDispatch can use the L3PortID
metadata to dispatch packets to different Encapsulator."
to:
"For example, when the downstream LFB is BasicMetadataDispatch,
and there exist Ethernet and other tunnel Encapsulation downstream
from BasicMetadataDispatch, then the BasicMetadataDispatch LFB can use
the L3PortID metadata to dispatch packets to the different Encapsulator
LFBs."

40) 5.3.4.1 MediaEncapInfoIndex

"The CE sets it to a
value that is not allocated in downstream LFB tables. (If a
downstream LFB lookup fails to find it, it indicates some other
way to resolve it may be needed.)"

to:
"In some cases, depending on implementation, the CE may set the
MediaEncapInfoIndex passed downstream to a value that will fail
lookup when it gets to a target encapsulation LFB; such a lookup
failure at that point is an indication that further resolution
is needed. For a discussion on how such an approach could be used
refer to section XXX which describes the IPv4NextHop LFB."

41)  5.4.1.1
"RedirectIn LFB is defined with only one output, while without any
input."
to:
"RedirectIn LFB is defined with a single output LFB port (and no input LFB
port"

XXX: should that be "output LFB port group"? Later on you seem to
indicate that ’RedirectIndex’ is used to select output LFB port.
42) 5.4.1.1
"The CE may associate some metadata to indicate the frame types and may
also associate other metadata to indicate various information on the
packets."

I think that first "may" should be "must".

43)  5.4.1.1
"All metadata from the CE other than the ’RedirectIndex’ metadata will
output from the RedirectIn LFB along with their binding packets."

to:
"Any other metadata, in addition to ’RedirectIndex’, will be passed untouched
along the packet delivered by the CE."

44)5.4.2.1
"the RedirectOut LFB is defined with only one input,
while without any output."
to:
"RedirectOut LFB is defined with a single input LFB port (and no output LFB
port"

45)5.4.2.1 technical question
dont we have something equivalent to ’RedirectIndex’ that the CE
can use to deduce source LFBs etc for the purpose of maybe multiplexing
when it receives the redirected packet?
--------

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 31 Aug 2011 22:07:26 +0800

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>
Subject: comments #13

----------
37) 5.3.4.1

Re: fixed all document as well as this on the "output ports"  with  "output LFB  ports".

38) 5.3.4.1

Re: Chuanhuang, can you help to provide some text here?

39)5.3.4.1

Re: a good update.

"The CE sets it to a

to:

Re: updated.

41)  5.4.1.1

Re: yes, it is a single output LFB port with group type.  I also udpated the 
All metadata from the CE other than the 'RedirectIndex' metadatum will output from the RedirectIn LFB along with their binding packets to downstream LFB. This means the 'RedirectIndex' metadatum from CE will be consumed by the RedirectIn LFB and will not output to downstream LFB. Note that, a packet from CE without a 'RedirectIndex' metadatum associated will be dropped by the LFB.

42) 5.4.1.1

Re: there is another sentence followed state that "Among them, there MUST exist a 'RedirectIndex' metadatum, ...", so I think the constrain "may" here is enough.

43)  5.4.1.1

to:

Re: I rewrote the last paragraph: 
All metadata from the CE other than the 'RedirectIndex' metadata will output from the RedirectIn LFB along with their binding packets. Note that, a packet without a 'RedirectIndex' metadata associated will be dropped by the LFB.

to: 

Any other metadata, in addition to ’RedirectIndex’, will be passed untouched along the packet delivered by the CE to downstream LFB. This means the 'RedirectIndex' metadatum from CE will be "consumed” by the RedirectIn LFB and will not be passed to downstream LFB. Note that, a packet from CE without a 'RedirectIndex' metadatum associated will be dropped by the LFB.

44)5.4.2.1

Re: based on the discussion, the following text is added: 
All metadata associated with the input packets of RedirectOut LFB will be delivered to CE via the ForCES protocol redirect message [RFC5810]. CE can then decide how to process the packets according to these metadata. For instance, if packets that can not find L2 information in EtherEncap LFB, they may be redirected to CE for ARP processing. An "ExecptionID" metadatum indicating the exception case will be associated to every such packet in EtherEncap LFB. When the packet with this metadatum is redirected to CE via RedirectOut LFB, CE knows the exception case and know what to do next. 

But Chuanhuang,  please note that currently, we have not defined any ExceptionID for lack of L2 information in EtherEncap LFB, only one  exception case is defined there: 
o MediaEncapInfoIndex value is not allocated in the EncapTable. 
 
Do you think we should add some new exception cases?

thanks,
Weiming

---

From: "Chuanhuang Li" <[email-masked]>
Date: Thu, 1 Sep 2011 09:19:02 +0800

Hi, all

I have answered this question in Jamal's comments #11 (the last one). 
We can modify this execption to "There are no routes for the packet" 
or "Packets can not find any valid routes in the NextHop table."

Exactly, execption "The HopSelector is invalid" is the espeical case 
of  "Packets can not find any valid routes in the NextHop table" .

There may be such case: the HopSelector is valid, but the nexthop information 
in the entry is None or invalid. Execption "Packets can not find any valid routes in 
the NextHop table" mainly means this case.  

>Do you think we should add some new exception cases?

"MediaEncapInfoIndex value is not allocated in the EncapTable" is 
the especial case of lacking of L2 information.

The same as in Nexthop, I think we need add an execption like "Packets can not find 
any valid L2 information"

Yours,
Chuanhuang

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 1 Sep 2011 10:23:34 +0800

----- Original Message ----- 
From: "Chuanhuang Li" <[email-masked]>

> the NextHop table" mainly means this case.  

Re: all the exception cases has been changed as below: 

o The HopSelector for the packet is invalid.

   o The packet failed lookup of the NextHop table even though the HopSelector is valid.

o The MTU for outgoing interface is less than the packet size.

The same chagnes applied to IPv4NextHop LFB also.

Chuanhuang: pls modify the xml accordingly.

> any valid L2 information"
Re: I'm not sure what you mean. Do you mean to add another item of exception? Can you just send out the text for the change like the format "from ...text to ...text?

Weiming

---

From: "Chuanhuang Li" <[email-masked]>
Date: Thu, 1 Sep 2011 11:05:32 +0800

>>>But Chuanhuang,  please note that currently, we have not defined any ExceptionID for lack of L2 information in EtherEncap LFB, only one  >>>exception case is defined there: 
Yes, we need add another item, similar to NextHop,

 o  MediaEncapInfoIndex value is not allocated in the EncapTable.
 o  The packet failed lookup of the EncapTable table even though the MediaEncapInfoIndex is valid.

These remind me of that we maybe need add an "ExceptionOut" LFB port in EtherClassfier.
Now, EtherClassfier only defined an output port: ClassifyOut,  group output
If we can't classfy the packet , owing to some reasons, How the packets will be processed?

Joel, what's your opinion?

Yours,
Chuanhuang

---

From: Joel <[email-masked]>
Date: Wed, 31 Aug 2011 23:07:20 -0400

I suppose that the correct answer is a noMatchingClassification output 
port.  Which will usually point nowhere, but which some devices could 
point to the path to the CE.

Yours,
Joel

On 8/31/2011 11:05 PM, Chuanhuang Li wrote:
>>>> But Chuanhuang,  please note that currently, we have not defined any ExceptionID for lack of L2 information in EtherEncap LFB, only one>>>exception case is defined there:
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 1 Sep 2011 12:31:57 +0800

Chuanhuang, 

pls open another comment on the classifier udpate and provide xml definition and xml for the update.

More reply inline on this comment #13.

tks,
Weiming

----- Original Message ----- 
From: "Joel" <[email-masked]>
Subject: Re: [forces] comments #13

>>   o  The packet failed lookup of the EncapTable table even though the MediaEncapInfoIndex is valid.
Re: as below, pls change the XML file also.
   o The MediaEncapInfoIndex value of the packet is invalid and can not be allocated in the EncapTable.   
   O The packet failed lookup of the EncapTable table even though the MediaEncapInfoIndex is valid.