mcohort: RE: New draft on embedding the RP address in IPv6 multicast address

["Mike O'Connor" <moc@es.net>]

Greg,

I'd like to throw out an MSDP architecture issue to you and the mcohorts
group. I'm running into problems with MSDP rule checking rejecting most
of the SA's ESnet receives from it's peering with Abilene in Sunnyvale
CA. 

The SA's are being rejected because the path to a particular SA may exit
ESnet in New York rather than Sunnyvale. So the quick and dirty solution
is to ignore the MSDP RPF rule checking and get the customer up and
running. But then I have to concern myself with the consequences of
ignoring the RPF rules, or solving world hunger by attempting to align
all of my MSDP peerings with BGP peerings and make sure all transit
networks do the same.

I mostly concerned with MSDP loops being created by ignoring the RPF
rules and there may be some evidence of this within the last week. I had
to turn on rule checking again and have not had the MSDP instability in
our core return, it still exists on a few of our peers though.

One solution I've considered appears to turn the conventional MSDP
architecture model inside out or upside down, which is usually a fun
thing to do as long as you don't hurt yourself.  

Core router mesh:
Currently the ESnet core routers are configured in an N^2 MSDP mesh, the
peerings are type mesh-group so the SA's from other mesh group members
are not forwarded to the rest of the group and MSDP RFP rule checking is
deactivated.

MSDP peering:
Our MSDP peers are configured as standard, all SA's accepted from peers
are forwarded to all peers and RPF rule checking is enforced.

The quick and dirty solution to Abilene was to put this peering in it's
own mesh group so the RPF rules could be bypassed.
 
I've been thinking of converting our Core to MSDP standard, to enforce
rule checking between core routers and prevent loops through ESnet. I'd
like to place the MSDP peers at each peering router in a local
mesh-group in order to relax the MSDP rule checking to them. Of course
when we assume our peers are meshed, ESnet will no longer forward
transit SA's between our peers but this is not our role anyway, we
simply want to forward ESnet site SA's and receive SA's from each peer.

By doing this we hope to gain more control over the routing and rule
checking, this could likely achieve larger MSDP SA acceptance resulting
in fewer calls and happier customers.

Comments and alternative approaches greatly appreciated.

-Mike

--
Mike O'Connor,                  E-mail: moc@es.net
Network Engineer                Energy Sciences Network (ESnet)
East coast: +1 631 344-7410     West coast: +1 510 486-7421
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)


-------------------------------------------------------------------
Archive:   http://darkwing.uoregon.edu/~llynch/mcastwks/mcohort/
sub/unsub: http://darkwing.uoregon.edu/~llynch/mcastwks/mcohort.html