Packet format: draft-soliman-monami6-flow-binding-00.txt

 > > => Ok, but can explain how this is different
in this 
 > particular option
 > > from any other option? These extensions you refer
to would 
 > be defined
 > > as suboptions so they're completely transparent
to this option.
 > 
 > I was more thinking the case that someone would like
to extend this 
 > particular suboption. 

=> ok, but s/suboption/option.

  Naturally defining a new suboption solves the 
 > case, but the reason why I'm thinking about the need
to extend this 
 > particular suboption is that I'm trying to figure out
is 
 > there something 
 > else needed besides the fields specified in the draft.
This 
 > is of course 
 > only valid if all flow binding related fields should
be 
 > inside the same 
 > suboption.

=> Well, I don't know of any other field used today but
your point
is well taken. As I mentioned earlier, we can have a version
field
to do what you're asking for. 

 > > I know there is 
 > > a tradeoff with simplicity here, but IMO it's
more important to
 > > be radio efficient than to design for a simple
implementation.
 > > At least from a job security view point 
 > 
 > Well, tradeoffs are tricky...

=> Engineering is tricky ;)

 > The flow field could be extended to 24 bits but
naturally 
 > only 20 bits 
 > would be meaningful.
 > 
 >  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
 >   |        Flow Label                             |   
 Protocol  |
 >  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
 >   |     C. S.     |
 >   +-+-+-+-+-+-+-+-+
 > 
 > There would still be alignment issues (in the case
some of the other 
 > fields would not be present) but at least the SPI
field 
 > would be aligned 
 > correctly.
 > 
 > Extending the flow label field to 32 bits (still only
using 20 bits, 
 > though) would also be something worth considering for:
 > 
 >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
 > |                            SPI                      
         |
 >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
 > |                            Flow Label               
         |
 >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
 > |     Source port               |    Destination port 
         |
 >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
 > |   Protocol    |     C. S.     |
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > 
 > It would surely waste 12 bits but would solve those 
 > alignment issues in 
 > the given format. A tradeoff 

=> I'm fine with either option, but since we're going
to add a 
possibility to define address ranges (a comment in Dallas),
let's 
add that first then decide whether it's better to represent
this 
as a 24 or 32 bits. Probabilistically speaking (only based
on my gutt
feeling) The C.S. is unlikely to be there, so if we can fit
the 
Flow label and protocol in one word that would make sense
IMO. 

Hesham


_______________________________________________
Monami6 mailing list
Monami6ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6