Hesham Soliman wrote:
=> 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.
=> What are you talking about? RFC 3775 doesn't say a host should set
the TC field.
Ok, rfc3775 requires both the MN and the HA to use generic encapsulation
with a written reference to another RFC that says when encapsulating
copy the traffic-class field (optionally pre-configure it). Which means
that if MN decides to use a certain class then the intermediary router
HA respects its decision. Right?
So is Traffic Class actually used? I'd say yes, by and large.
=> 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.
=> I never said that. That would be nonesense.
So you didn't say core routers don't look at any fields, didn't say core
routers dont change some fields (in order to achieve their flow
splitting). Since this is undocumented in an RFC, the only thing I
could is to ask you how do you think the core routers do this flow
splitting?
You don't say what exactly method is used.
=> I said they do it on a per-flow basis, meaning a flow is expected
to take the same path in the network. But two different flows can
take different paths.
Is a 'flow' an application-level flow, like srcport-dstport go this path
and other pair other path? Or is it a dstaddress-based 'flow'? Or is
it a src-dst flow? Are there other distinctors than address and port?
Does the endnode learn at any time what paths and path selection are
used by the core routers (signalling from router to endnode)?
If I understand these, then I can say whether that particular deployment
is in support of flow bindings monami6 w/o LFN involvement make sense or
not.
I'm very surprised when it's said that Traffic Class isn't used and
other method is in wide use (flow splitting) but can't characterize it
more than just flows taking different paths.
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.
=> That's fine, but as I mentioned earlier (and so did Thierry) this
is a separate point and can augment any proposal.
In a sense yes, I agree it's separated issue, like one can HTTP between
two endnodes and then UDP between one of these nodes and a third.
But remark HTTP and UDP have IP in common, use IP header fields in the
same way. With flowbindings context if one wants to use RSVP on LFN and
flow balancing according to the Traffic Class in the MR (all specified
currently) then this will not work, because you suggest that MR uses the
Flow Identification Option for this classification, or the MR uses the
Traffic Class.
So at this point Traffic Class fields and Flow Identification Options
are competitors. It's not like HTTP and UDP both use IP in the same
way, now you have Flow Identification Options and Traffic Class trying
to do same thing.
This is the crux of our argument and we differ - you say flow
bindings monami6 don't need that LFN preferences.
=> You must be reading different text from what I wrote, I never said
that. I said it's a separate issue and I hope it gets solved.
What if solving that issue means actually using Traffic Class? Doesn't
it mean that solving that issue means Flow Identification Option isn't
used? Which of the two RFCs will be used? Which will be a fact?
It's orthogonal to the choice of protocol, which is what Jari's
thread was about.
I think choosing a flow bindings protocol (among three) drafts is
indeed a separate issue. I think then that this issue of competition
between Traffic Class and Flow Identification Option (or Filter Rules in
draft-larsson-monami6-filter-rules-01.txt or Policy Data Set in
draft-mitsuya-monami6-flow-distribution-policy-02.txt) is a second issue.
For example, if there's a means that any of these three drafts rules
makes use of the Traffic Class pre-defined in an RFC (assured
forwarding, etc) then I think I'm basically fine.
I'm also very fine if there's a means for LFN to tell MR via this
Traffic Class field what class it prefers, and fine if MR copies the
Traffic Class field.
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.
=> Sorry, I don't know what you're talking about.
Well, as you know in the NEMO WG there's been rechartering to identify
requirements for Route Optimization. While gathering these
requirements, it may be found out that LFN wants to send the BU to HA
(instead of MR sending BU for its prefix). For LFN to do that, it may
be that MR sends to LFN what are the subnets to which it connects. At
that point the flow bindings should be established by LFN somehow.
Or, this may be a solution to the problem we discussed, that LFN knows
nothing about MR decisions and that is bad. That's why I'm saying NEMO
RO and flow bindings for NEMO are tightly related.
There may be additional issues directly related: one would want to make
sure that when NEMO RO is used and LFN sends a BU, it's the Flow
Bindings specified by that BU that prevail, and not the Flow Bindings in
the BU MR would send.
Now more clear?
Alex
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
