> > => That's fine, so please question the approach. It's best to > > have clear questions/doubts to progress the discussion. Or > > feel free to respond to my earlier comments. But it's hard to > > respond to statements like "A is better than B" without an > > associated explanation. > > I think that separating filter rules as much as possible > from mobility > management protocols (mmp) is good because:
=> I think the keyword above is "as much as possible". Because as you know, in the "one solution" approach, you *do* add extensions to the mmp. More below. > > * integrating a new mmp to the framework is easier because > the impact on > the mmp is kept minimal => This becomes an implementation issue. The "minimal" impacts you refer to are based on the assumption that the flow descriptors are defined in your mobility module. This need not be the case as I mentioned earlier. The mobility protocol can simply be a carrier for this information. So one could have a generic module with a generic API to any mobility protocol. The format of the option can also be the same if needed. > * changes in filter rules do not always necessitate additional mmp > signaling, signaling of course but not mmp signaling => Changes in filters will necessitate signalling. what difference does it make whether this signalling is done in mmp or not? > * filter rules can be distributed to nodes (or received from > nodes) that > would not normally receive mmp signals from the terminal (or > would not > send mmp signals to the terminal) => That's false. What's the point of sending filter rules that describe a flow without binding that flow to an address?? If you're binding that flow to an address in your generic signalling then you've invented a new mobility protocol that runs on top of whatever you already have. > > I fully acknowledge that these present just my personal > opinions because > one of the tricky aspects in this whole vs. discussion is > that I think > it is possible get both approaches to work. => I'm glad you listed those points. It's clear to me that more detail is needed in this discussion to clarify the issues to others on the list. Hesham > > /Tero > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
