[Xorp-hackers] IGMPv3 and related

Pavlin Radoslavov pavlin@icir.org
Mon, 15 Aug 2005 19:01:51 -0700


> > I notice that IGMPv3 is on the roadmap and that there
> > were posts last month about someone getting ready to
> > add IGMPv3 to the CVS tree. However, I recognize that
> > until it has been thoroughly beaten up by testers, it
> > is not going to be in any kind of final form and so
> > any answers will be slightly speculative.
> > 
> > If I recall correctly, the last time I looked at the
> > IGMPv3 RFC I noted that it supported extensions to the
> > basic protocol, and that there was at least one draft
> > extension for authentication.
> > 
> > Will the Xorp IGMPv3 implementation be just the raw
> > IGMPv3 protocol, the raw protocol with hooks to allow
> > for extensions, or will draft extensions be included?
> Since I won't be doing the implementation I can't say 
> anything for sure. But IMHO I think that we shouldn't 
> implement to much drafts but wait for them to be more
> generally accepted before implementing.
> On the other hand XORP is meant as a development and
> testing platform and thus it would make sense writing
> experimental stuff as well.

In general, the approach we are taking is that first we implement
the basic protocol, and after that we implement the extra stuff (as
time allows us). There is also the trade-off between implementing
new stuff (i.e.., new protocol) and enhancing an existing protocol
implementation.
But in general I agree with Kristian that we should implement drafts
only if they are generally accepted.

> > On a related note, I see that the IETF has a number of
> > multicast security protocols (RFCs 3547, 3740, 3830,
> > 4046 and 4082). They also seem to have a number of
> > drafts in circulation. Are there any plans to add any
> > of these in (assuming they're not there already)? I
> > didn't notice them on the roadmap, so wasn't sure what
> > the current status was.

Eventually, we want to implement the multicast security protocols,
but before doing that we want to have the multicast routing
related protocols and modules (IGMPv3/MLDv2, Bidir-PIM, multicast
interoperability module as in RFC-2715, etc).

Furthermore, there are various non-multicast tasks that are probably
higher priority than the multicast security protocols and that are
not on the roadmap.
Hence, at this time adding the multicast security protocols to the
roadmap will be pointless because there is very high probability
their implementation will be postponed a number of times by
higher-priority tasks.

> > Out of the multicast arena and into the mobility. The
> > IETF seems to have three areas of development, at the
> > moment - mobile IP (manet), mobile networks (nemo) and
> > mobile IPSec (mobike). In addition, they have
> > IPv4-specific (mip4) and IPv6-specific (mip6 and
> > mipshop) mobility work.
> > 
> > How much of this is going to end up being implemented
> > in Xorp? There seems to be an awful lot defined, but
> > using Freshmeat as an extremely crude form of
> > popularity poll, I'm not seeing as much interest as
> > I'd have expected in it.
> I think XORP should have support for different types of
> Mobile IP. What, how and when is something I really can't
> answer. Someone has to write it and mip is not the focus
> right now.
> It's better to do a few things well than a lot of things
> not so well. The focus is more on the basic routing as of
> now and should stay there for a bit longer ;)

Agree. Mobile IP is probably higher priority than multicast security
protocols, but for similar reasons as those I described above it is
not on our roadmap (yet).

> > Next up are the router redundancy protocols - VRRP and
> > CARP. CARP seems to be the "truly free" protocol, with
> > some questions as to the usability of VRRP in open
> > software. What (if any) plans on fail-over support are
> > in the air?
> CARP handles failover on interface level.
> XORP is a routing suite. It's in a routers nature to support
> failover. If one router breakes, OSPF (or some other protocol)
> will choose a different path - failover!
> 
> Now if you would build a virtual router out of several machines
> it would require another level of failover. We would need to
> copy the routing table between the machines and so on.
> 
> Of course, the configuration of CARP could be integrated into
> XORP and this is something I would love to see. It would be 
> great to be able to configure a complete router without ever
> leaving the xorpshell. But I think interface configuration
> from within XORP should be done first :)

Agree.

> > QoS seems to be a hot area at the moment, too -
> > nothing much on the IETF website, but citeseer
> > indicates that the number of methods tried and tested
> > number in the upper 20s, lower 30s. There WILL be
> > others I've missed, so this is a low-end figure. What
> > sort of QoS support is Xorp likely to have in future?
> This is kinda the same as the above. XORP should not handle
> QoS as it doesn't forward any traffic but it would be nice if
> XORP could configure dummynet/ALTQ.

Agree.
Again, it is question of time and task prioritization to have it
done.

> > And finally, a bugbear that seems to be widely used by
> > major ISPs but where the Linux implementation seems to
> > be dead - MPLS. As with some of the others, there
> > seems to be a vast amount defined for it - it's not a
> > simple thing. Most seems to be in the MPLS working
> > group's pages, but there's some in the BFD
> > (bi-directional forwarding detection) and CCAMP
> > (Common Control and Measurement Plane) groups. There's
> > even a L1VPN group - no RFCs or drafts yet - for
> > really low-level tunneling for it. There are probably
> > other relevent(ish) papers out in the wild blue yonder
> > not included in those three. How much - if any - is
> > going to make it into Xorp?
> I'm not into MPLS, but since it's a lot of layer 2
> forwarding of packets it's not really XORPs domain. Though
> I suppose it requires some form of routing protocols and 
> this should perhaps be developed for XORP.

Agree.


Pavlin