#
#     msdp-and-anycast-rp.txt
#
#
#	David Meyer
#	dmm@cisco.com
#	Tue Jul  6 14:50:38 1999
#
#	$Header: /ftp/ipmulticast/RCS/msdp-and-anycast-rp.txt,v 1.2 1999/07/30 22:37:52 dmm Exp $
#


      Simple Toplogy Rules
      ====================

      (i).    A singly homed MSDP speaker always accepts SA 
              messages from its peer

      (ii).   A MSDP speaker always accepts SAs for which the 
              RP in the SA message is a peer

      (iii).  A MSDP speaker always rejects an SA from any peer if it
              the RP in the SA message.

      (iv).   If a MSDP speaker has one or more default peers 
              configured, then it will accept an SA message if 
              comes from the default peer for the RP in the SA 
              message.

        
      Complex Scenario
      ================

      R1, R2, and R3 form a logical RP for an AS. C1 and C2 are 
      customer routers (and the BGP session not multi-hop); RP is C1's
      RP. P1 is a peer router.  


           MSDP/MBGP        Logical RPs
      C1 ============= R1----------------R2 
       |  SA(S,G,RP)    \                /  
       |                 \              /
       |  MBGP/MSDP       \ MSDP  MSDP /
       |                   \          /
       |                    \        /
      C2 SA(S',G',RP')       \      /
                              \    /
                                R3 ============== P1
                                     SA(S,G,RP)
                                      ------->
          

      Internal MSDP Peering
      =====================
      When R1 sees SA(S,G,RP) from C1, it sees the next-hop toward
      prefix covering RP is through C1, so R1 accepts the SA. R1 will
      forward SA(S,G,RP) to R2 and R3, which will only accept
      SA(S,G,RP) if R1 is announcing  (and is) the next-hop towards
      the originating RP each SA message. Note that operationally,
      this means next-hop needs to be the same as the MSDP
      connect-source.

      This implies that if you want to pass on an SA internally,
      you have to be announcing the next-hop towards the AS that
      originates the prefix covering the originating RP. Note that
      the MSDP connect-source has to be the interface that is
      configured with the address of the next-hop.
      
      Now, if C2 tries MSDP peer with R1 directly (cutting out
      transit provider C1), then C2's SA RPF fails at R1, because
      R1 expects SA message to come from a MSDP peer in the next
      AS in the AS-PATH towards the originating RP, which in this
      case would C1. 
      
      RULE: An internal MSDP peer will accept an SA message from
            another internal peer iff that peer is the advertiser of
            towards the prefix covering the RP which originated
            the SA.  


      External MSDP Peering
      =====================
      External peer P1 will accept an SA from R3 iff R3 comes from the 
      next AS in the path. This breaks, for example, if P1 
      peers with C1.

      RULE: An external MSDP peer will accept an SA message from
            another peer iff the peer is in the next AS in the path
            towards the AS originating the prefix covering the
            RP in the SA message.


      Mesh Groups
      ===========
      First, it is important to note that mesh-groups don't change the
      above rules. What mesh-groups avoid is the RPF check if one of
      the members of the mesh-group forwards the SA. In practice,
      however, mesh-groups do significantly simplify the MSDP toplogy
      you need in certain cases. In particular, you can simplify your
      MSDP topology by creating a single core mesh-group in which each
      of the mesh-group members terminates some number of external
      MSDP sessions. That is, instead of having to include the border
      router, you can simplify the topology to a single mesh-group, 
      and terminate all external MSDP sessions on the members of mesh-group.
	
      





.