2 Mar 2012 16:17
time to request slots for IETF 83 RTGWG meeting
Alia Atlas <akatlas <at> gmail.com>
2012-03-02 15:17:30 GMT
2012-03-02 15:17:30 GMT
This would be a good time to request time-slots for RTGWG at IETF 83. RTGWG will be meeting on Thursday March 29 from 17:40-19:40. We have already had a few slot requests, of course. When requesting a slot, please a) include the relevant draft b) specify how long you'd like - both maximum and minimum times I'd also strongly encourage that we have discussion on the mailing list. There is more time for thoughtful comments here. Once we have the agenda together, we'll send it out. I expect a rather full meeting. Thanks, Alia
Russ
==
Due to the important semantics of source address, recent years see
increasing works on adding source addresses into routing controls.
Could you point to some more recent efforts than source routing (which
is years old)? I'm not certain source addresses would actually need to
be added to a routing protocol to use them for anything --it might be
worth discussing under what circumstances adding such addresses might be
add information that's not already present in the routing system.
==
If the host is using address A, and the link l1 or l3 fails. Then the
host can immediately detect the failure, then switch to address B, and
continue to communicate with the Internet via ISP2.
How would you see the host detecting and reacting to the failure more
quickly than the routed control plane, itself, could detect and react to
the failure?
==
Within destination-based routing, traffic towards the same destination
has to travel along the same path in the network.
This really isn't true --in reality, almost every implementation load
shares based on the some bits or another in the packet header today. One
of those sets of bits can be the source address in many implementations
(if not all?). I'm not certain how your proposal adds anything to this.
==
If there is congestion on the link between b and d, and router b moves
the traffic towards d to the north path via c. Thus, the probe packets
will flow on the path a-b-c-d, which does not include the link between b
and d.
This seems like a more specific case of traffic engineering, which is
actually covered in the next section.
==
The section on FIST is interesting, but it's at the implementation
level, rather than the protocol level, so I'm not certain how applicable
is within an IETF draft.
==
With these preconditions, each edge router can announce the foreign
Internet prefixes combined with its own router identification to the
network, each PE router can announce the customer prefixes combined with
the corresponding customer domain number, PE routers are also
responsible for announcing the preference of customer networks on edge
routers.
Figuring out how to advertise sources/destination pairs isn't really a
problem overall.. What I don't understand is how this is different than
the information already in the table today --every source and
destination is already there, just not matched together. What is the
value in matching them together in a single piece of control plane
information? None of the use cases supplied in the draft seem to require
the information to be paired in this way, nor does building a
source/destination pair routing table (that I can see, at any rate).
==
TwoD-IP routing will enhance the security level of the networks, because
routers will check source addresses, which is an important identity of
the senders.
I'm not certain I understand why this would be, given the ease with
which source addresses can be spoofed. I suppose you could say that you
could do an rpf check at every ingress interface, but you can already do
that (to the degree that aggregation and load sharing allow). You could
claim that the additional state provided in pairing source and
destination addresses in the routing table would allow more specific
checks --but probably no more than simply getting rid of all
aggregation, or even flooding host routes throughout the network --and I
don't know if there would be more state in pairing source/destination
sets, or flooding host routes, so it's hard to analyze the actual case
for this claim.
RSS Feed