Hesham Soliman wrote:
This is really getting away from the relevant monami issues but I'll
give you my last 2 cents.
=> This is not related to reality in deployed networks. End hosts
don't use RSVP and hosts hardly ever mark TOS fields.
Huh? RSVP-related RFCs date of last year,
=> And that means they're used?
Would you like _your_ flow bindings document to become an RFC and one
year later people say it doesn't mean it's used just because it has an
RFC number on it.
include COPS, and end hosts routinely mark Traffic Class.
=> I didn't say COPS is not used. I'd love to know about the
deployment that you're referring to (where hosts are setting the TC
routinely)...
Well TC marking is used in my lab, works according to specs.
All MIPv6 implementations supposedly use it too, because the MIP6 spec
says so.
Anyway, your response is not related to what I said
earlier, routers
do split flows to different links all the time (of course
one flow is
expected to take the same path in the network under normal
circumstances).
Routers split flows based on what specs? I think you agree we
can't say that because some non-specified flow splitting happens
then we need to specify a similar thing. It means actually we
don't want to specify a similar thing.
=> You seem to think that a product can't implement an algorithm
unless it's specified in an RFC. This is obviously wrong.
I agree with you if I implied so. But no, far from me that idea. I
think it is a very good idea in some contexts to do just that, specify
locally (non-IETF) a protocol, implement test debug and benefit from the
feature (sell other things in the mean time). Google features (earth,
sitemaps, and more) are just that, widely used, and so on.
Remark in the case of Google, although the methods are not standardized,
they're publicly documented, so we can talk about sitemaps.
Anyone can do whatever they want, hopefully, provided that they don't
break existing specs.
I agree.
And that's the case here.
No no, it's different. An assumption is made on the behaviour of the
network and no proof is given. I'm not even mentioned a protocol name
that is not IETF and that does that flow splitting for an uncoscious
endnode. Doesn't mean I don't believe it exists - it may very well.
But flow splitting can happen in so many different ways that some of
them may be in support of your proposal of MR doing flow bindings on
behalf of LFN, others against.
Being silent about what you mean (what non-IETF flow splitting is widely
used?) means that I can't understand you.
What if for example the flow splitting you mean happens in a network
where only two types of applications are possible, with the
distinguisher being WAP or TCP/IP. The network indeed splits the flows
and gives more ressources to WAP and less to TCP/IP. But it is still
the endnode to decide to use either WAP or TCP/IP.
With flow bindings draft we can't say we choose WAP vs TCP/IP, it's just
TCP/IP. The flow bindings draft qualifies only on TCP/IP parameters.
This is a fact
What RFC number?
=> Fact != RFC....
This is very disappointing. Because it means _your_ draft could become
an RFC and thus a non-fact.
If on the other hand, the decision to choose a different interface
is based on application needs, and MR may _think_ the LFN's
application prefers a certain interface - then it's totally
different thing. And I believe flow bindings fall into this
category, because it has filters on all possible fields in an
application payload.
Have I got this right?
=> No. I don't think you understand that routers can select any next
hop they think is appropriate. Link down/up events are only one
factor in this selection. This is a perfectly acceptable behaviour.
Ok, let me try cool down. I agree routers select a next hop they think
appropriate w/o endnode involvement. That selection happens based on
the src and dst address and the traffic class, all being set by the endnode.
You seem to say other routers do it differently, not looking at any
field, or changing some of the fields. You don't say what exactly
method is used. But you say that because other fixed routers don't care
of LFN then MR could either.
I think that is not enough of support for flow bindings monami6.
I also think that the flow binding monami6 methods could make a lot
sense _if_ the MR were informed by the LFN of LFN's preferences. This
is the crux of our argument and we differ - you say flow bindings
monami6 don't need that LFN preferences. And knowing that in NEMO WG
they look _probably_ at exactly MR communicating with LFN for parameter
exchange for RO then I think they should be done in tandem. Ie flow
bindings in monami6 aren't possible w/o RO in NEMO.
Alex
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
