> > => 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. <snip> > > => 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. 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. > 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. 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. It's orthogonal to the choice of protocol, which is what Jari's thread was about. 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. Hesham > > Alex > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
