Subject: [MEXT] flow binding draft 3

From: Christian Kaas-Petersen <[email-masked]>
Date: Thu, 16 Jul 2009 09:09:29 +0000 (GMT)

A few comments on draft-ietf-mext-flow-binding-03

 * chapter 2, paragraph 2, "other specifications" AND
   section 5.1, paragraphs 3, "another document": Will it harm to make
   a reference to draft-tsirtsis-mext-binary-filters, in order to
   give one example of what a flow description could look like?

 * chapter 3: After reading the document, I think a flow should be
   defined as follows.  "Flow: A flow is a subset of all IP packets
   sent *to* a mobile node.  The packets of the subset match
   a flow description."  With this definition, it makes more sense
   that a flow description can use source address, will never use
   destination address, and can use both source and destination ports.

 * section 4.1, BID-PRI paragraph: Suggest to add a sentence like
   "This field is needed in case a packet does not match any flow
   description."  A similar top-level motivation is given for the
   FID-PRI field in section 4.2.

 * section 4.2, Status paragraph: A suggestion for easing the reading,
   let the sentences "Values from 0 to 127 indicate success.  Values
   of 128 and higher indicate failure." be the second and third sentences,
   which are then followed by detailing the relevance of the field.

 * section 4.2: I wonder, isn't the Forward action forgotten?  The
   Forward action is certainly mentioned in section 5.3.2.1.

 * section 5.2.2.1, last paragraph: Shouldn't a third bullet be added
   concerning if action indicates 'Forward', where one BID must be
   included?

 * section 5.2.4, last paragraph:  The last sentence describes one way
   for an inactive flow binding to become active, namely by modifying
   the flow entry such that it maps to already existing BIDs.  I think
   there is a second way, namely to send a Binding Identifier Mobility
   option re-introducing the BID-value.

Christian

      ___________________________________________________________ 
Skal du købe ny bil? Sammenlign priser på brugte biler med Kelkoo og find et godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 16 Jul 2009 19:20:09 +1000

>    give one example of what a flow description could look like?

=> Hopefully in the next revisions that draft will be a WG draft and
progress together with the flow binding draft so we can reference it as a
default. 

>    destination address, and can use both source and destination ports.

=> I actually prefer RFC 2460's definition:
   A flow is a sequence of packets sent from a particular source to a
   particular (unicast or multicast) destination for which the source
   desires special handling by the intervening routers

I think we should reuse it as much as possible.

>    FID-PRI field in section 4.2.

=> ok.

>    which are then followed by detailing the relevance of the field.

=> ok.

>    Forward action is certainly mentioned in section 5.3.2.1.

=> It was removed, you must've found a left over one that I forgot to
remove. N-cast now covers the forward action.

>    concerning if action indicates 'Forward', where one BID must be

=> There is always one or more in n-cast.

>    option re-introducing the BID-value.

=> An inactive flow should not point to anything, so (re)-installing a BID
should have no effect unless explicitly bound to a flow. I don't think we
should keep records of what a flow used to be bound to. It's a memoryless
operation. If there is text suggesting otherwise please let me know.

Hesham

> Skal du købe ny bil? Sammenlign priser på brugte biler med Kelkoo og find et
> godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext