Subject: RE: [Monami6] Packet format: draft-soliman-monami6-flow-binding-00.txt

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 13 Apr 2006 10:18:53 -0700

> ==> As Tero showed/told in his mail we think that the 
 > multihoming should 
 > be regarded as a general technical issue and the MIPv6 is needed to 
 > enable the practical use of multihoming. I mean MIPv6 is 
 > needed so the 
 > MN can use its identifier (HoA) for traffic flows instead of the 
 > locators (CoAs). This way if one flow moves between CoAs (possibly 
 > interfaces) the traffic flow does not stop. If the monami6 
 > charter says 
 > that the multihoming should be regarded as something which 
 > can only be 
 > achieved if you use MIPv6 

=> Monami is based on MIPv6 as far as I know. 

  and in the way the monami6 
 > describes (only in 
 > foreign link), it is IMO wrong. 

=> Monami is not intended to work only in the foreign link
but it's a side effect of MIPv6 that the signalling only takes
place while your not home. Perhaps you have another idea for doing
this while the MN is home? If so please propose it. I assume it's not
based on MIPv6. If you can see a way of doing this with MIPv6 please
propose that too. Otherwise I'm not sure how to solve this perceived
problem. I just want to make it clear that this is how MIPv6 works
today.

 > that MNs have 
 > a need to bind flows to interfaces or different HoAs even if 
 > they are 
 > attached to home network. When the MN moves away from the 
 > home network 
 > these flows must also be mapped to CoAs (BIDs) and when it 
 > returns again 
 > they are mapped to interfaces or HoAs again.

=> I think it would be nice to do that but I don't know 
of a reliable way of doing that other than sessions signalling/ SRV
records ...etc. In practice, I think that requiring this in a home 
network is not necessary since almost all MIP deployments rely 
on virtual home networks. 

 > I don't know if this is something that should be 
 > standardized or should 
 > it be left to implementors. I do however think that if you 
 > already have 
 > a need for some general policy data structure in multihomed node you 
 > should not make a specification which says that you need this 
 > information also to be copied into MIPv6 data structures if 
 > there is no 
 > reason for having it there. 

=> Of course there is a reason to have it. While the binding is
available, 
packets are routed based on the policy stored. When there is no binding
there is no policy. 

I mean it is enough to map a policy to 
 > interface(s), HoA(s) or CoA(s) with BID(s) which is specified in the 
 > MCoA draft.

=> I don't understand that. Did you read the usage scenarios section in
the draft?
You seem to assunme that policies are static.

 > ==> As I mentioned above I think that the MNs have a need for the 
 > multihoming mechanism even if they are located at home network. One 
 > situation could be that the MN has two interfaces which are both 
 > attached to their home links. In this case some policies are 
 > needed to 
 > map flows between the interfaces and HoAs and if one or both 
 > interfaces 
 > make a handover then these flows need to be mapped to BIDs. 

=> This is different from what you said earlier. You can use the current
draft to set policies when one interface is at home and the other is 
away. You can't use it when both interfaces are at home. And I was 
questioning the need for that. 

 > I don't know 
 > if this is reasonable scenario? At least its possible but might be 
 > unlikely. Hey, at least I tried. =)

=> I can't say it's unreasonable, I do think it's unlikely. I'm 
not saying it can't or shouldn't be solved. I'm saying that it's not 
doable with MIPv6 and that it's not a high priority scenario given what
we know about current MIP deployments. Feel free to shed a different
light
on this though.

 > ==> The drafts ( "Motivations and Scenarios for Using Multiple 
 > Interfaces and Global Addresses" and "Analysis of 
 > Multihoming in Mobile 
 > IPv6" ) in the monami6 WG say that this could be used in 
 > some scenarios. 
 > Anyway, I would not be too concern how the packets would 
 > arrive (TCP) or 
 > how the security is handled in this situation. I think this 
 > is a whole 
 > new technical discussion which is not part of the monami6 charter. 

=> Well, it would be a broken solution. I'm sure somewhere in IETF
there is a doc that says we don't want to produce a broken solution :)

I 
 > think that in this WG it should be researched if this is possible or 
 > not, technically I mean. 

=> Sure. Feel free to provide input on this topic. I'm happy to discuss
it.

 > Finally, I'm not saying that the flow binding draft is completely 
 > useless. I think that in some cases the BU would be good place to 
 > distribute policies. One good issue is that the MIPv6 security 
 > mechanisms can be used to secure also the policies. However, I think 
 > that these policies should be kept in the general policy 
 > data structure 
 > and they should be mapped to CoAs with BIDs not FIDs. 

=> Policy-based routing is a very old concept. The MIP BC can be 
implemented as a separate data structure, or in the routing table, 
or in the NC ...etc. We don't require people to implement it in the BC. 
It's up to you. 

Hesham

Bad 
 > thing is that 
 > if you want to enable multihoming for MNs in home link the 
 > BU cannot be 
 > used to distribute the policies.
 > 
 > -Heikki
 > 
 > > Hesham
 > > 
 > > Best regards,
 > > 
 > > Heikki Mahkonen
 > > 
 > > Tero Kauppinen (JO/LMF) wrote:
 > >  > I started reading the draft and got all the way to page 6. :)
 > >  >
 > >  > I agree that it is important to save bytes, but IMO not 
 > at the cost of
 > >  > making the format non-extendable.
 > >  >
 > >  > At minimum the described format should follow the 
 > alignment rules which
 > >  > is not true here. If all fields are present, there are 
 > more than one
 > >  > alignment errors: Flow Label, the SPI field, and the 
 > C.S. field which
 > >  > doesn't even fall into natural 32-bit word boundaries. 
 > I realize that
 > >  > one or more fields can be missing in which case the 
 > layout is different,
 > >  > but still alignment rules should be obeyed in all cases.
 > >  >
 > > 
 > > 
 > > _______________________________________________
 > > Monami6 mailing list
 > > [email-masked]
 > > https://www1.ietf.org/mailman/listinfo/monami6
 > > 
 > > 
 > > 
 > -------------------------------------------------------------
 > -----------
 > > 
 > > _______________________________________________
 > > Monami6 mailing list
 > > [email-masked]
 > > https://www1.ietf.org/mailman/listinfo/monami6
 > 
 > 
 > _______________________________________________
 > Monami6 mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/monami6
 > 

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 13 Apr 2006 10:34:00 -0700

> 
 > The situation could be improved at least to some extend with the 
 > following re-arrangement of the fields:

=> This format is not correct (see my earlier email), but another 
option might be to represent the flow label in 24 or 32 bits, with 
redundant 4, or 12 bits, respectively. I'm ok with this approach. 

Hesham

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 18 Apr 2006 08:23:13 -0700

> > => 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