Subject: RPF checking is a must in case of ingress repliction of MVPN

From: xuxiaohu 41208 <[email-masked]>
Date: Wed, 21 Dec 2005 20:50:25 +0800

Dear Eric,

  On the IETF64 meeting in vancouver,  I sent you two slides to explain
  why the RPF checking is a must in case of ingress replication of MVPN.
  The following are some related descriptions which is quoted from RFC
  2362.  FYI.

  The description includes two situations, one is switching from RPT to
  SPT, the other is SPT change triggered by unicast routing change. In
  order to realize smooth switching from old SPT to new SPT and avoid
  duplicated date stream to be forwarded during the convergence,  it still
  need to be known  whether any given data packet came on the old SPT or
  the new one.

  Any comment is expected.

  Best regards

  Xiaohu Xu

  ***************************************
  2.8 Multicast data packet processing

     Data packets are processed in a manner similar to other multicast
     schemes.  A router first performs a longest match on the source and
     group address in the data packet. A (S,G) entry is matched first if
     one exists; a (*,G) entry is matched otherwise. If neither state
     exists, then a (*,*,RP) entry match is attempted as follows: the
     router hashes on G to identify the RP for group G, and looks for a
     (*,*,RP) entry that has this RP address associated with it. If none
     of the above exists, then the packet is dropped. If a state is
     matched, the router compares the interface on which the packet
     arrived to the incoming interface field in the matched route entry.
     If the iif check fails the packet is dropped, otherwise the packet is
     forwarded to all interfaces listed in the outgoing interface list.

     Some special actions are needed to deliver packets continuously while
     switching from the shared to shortest-path tree. In particular, when
     a (S,G) entry is matched, incoming packets are forwarded as follows:

        1 If the SPT-bit is set, then:

             1 if the incoming interface is the same as a matching
               (S,G) iif, the packet is forwarded to the oif-list of
               (S,G).

             2 if the incoming interface is different than a matching
               (S,G) iif , the packet is discarded.

        2 If the SPT-bit is cleared, then:

             1 if the incoming interface is the same as a matching
               (S,G) iif, the packet is forwarded to the oif-list of
               (S,G). In addition, the SPT bit is set for that entry if
               the incoming interface differs from the incoming interface
               of the (*,G) or (*,*,RP) entry.

             2 if the incoming interface is different than a matching
               (S,G) iif, the incoming interface is tested against a
               matching (*,G) or (*,*,RP) entry. If the iif is the same as
               one of those, the packet is forwarded to the oif-list of
               the matching entry.

             3 Otherwise the iif does not match any entry for G and
               the packet is discarded.

     Data packets never trigger prunes.  However, data packets may trigger
     actions that in turn trigger prunes. For example, when router B in
     figure 3 decides to switch to SP-tree at step 3, it creates a (S,G)
     entry with SPT-bit set to 0. When data packets from S arrive at
     interface 2 of B, B sets the SPT-bit to 1 since the iif for (*,G) is
     different than that for (S,G). This triggers the sending of prunes
     towards the RP.[on page 9 of RFC 2362]

  2.10 Unicast Routing Changes

     When unicast routing changes, an RPF check is done on all active
     (S,G), (*,G) and (*,*,RP) entries, and all affected expected incoming
     interfaces are updated.  In particular, if the new incoming interface
     appears in the outgoing interface list, it is deleted from the
     outgoing interface list. The previous incoming interface may be added
     to the outgoing interface list by a subsequent Join/Prune from
     downstream.  Join/Prune messages received on the current incoming
     interface are ignored.  Join/Prune messages received on new
     interfaces or existing outgoing interfaces are not ignored. Other
     outgoing interfaces are left as is until they are explicitly pruned
     by downstream routers or are timed out due to lack of appropriate
     Join/Prune messages. If the router has a (S,G) entry with the SPT-bit
     set, and the updated iif(S,G) does not differ from iif(*,G) or
     iif(*,*,RP), then the router resets the SPT-bit.

     The router must send a Join/Prune message with S in the Join list out
     any new incoming interfaces to inform upstream routers that it
     expects multicast datagrams over the interface.  It may also send a
     Join/Prune message with S in the Prune list out the old incoming
     interface, if the link is operational, to inform upstream routers
     that this part of the distribution tree is going away.[on page 12]

  3.2.1 Sending Join/Prune Messages
     ……
    We do not trigger prunes onto interfaces based on data packets.  Data
     packets that arrive on the wrong incoming interface are silently
     dropped.  However, on point-to-point interfaces triggered prunes may
     be sent as an optimization.[on the bottom of Page 18]

[email-masked] 于 2005-12-19 10:39:44

收件人:     [email-masked]
抄送:

主题:  forward:Re: I would like to know your viewpoint on RPF checking in
      case of ingress repliction

----- Original Message -----

From: Eric Rosen

To: [email-masked]

Subject: Re: I would like to know your viewpoint on RPF checking in case of
ingress repliction

Sent: Tue Dec 13 01:12:21 CST 2005

> When the upstream PE for an SPT changes, I am told that current practice
> is to immediately send a Join(S,G) toward the new PE and a Prune(S,G) toward
> the old PE. That is, the Prune(S,G) for the old tree is not delayed while
> waiting for data to be received on the new tree. Therefore one doesn't
> really have to know whether any given data packet came on the old SPT or the
> new one.
> I have not checked the PIM-SM specification myself to see whether this
> practice is conformant or not. Do you have a citation which indicates that 
> it is not?

Xiaohu Xu
Huawei Technologies Co.,Ltd