Subject: [pim] reverse path question

From: "Julie Mcgray" <[email-masked]>
Date: Tue, 8 Jan 2008 18:09:55 -0500

Hi there,

I have a question about the determination of the IIF for a newly created
(s,g) entry due to a cache miss (no existing entry, first data packet
received from that source).

>From the PIM RFC, it states the following:

On receipt of data from S to G on interface iif:

 if( DirectlyConnected(S) == TRUE ) {
      set KeepaliveTimer(S,G) to Keepalive_Period
      # Note: a register state transition or UpstreamJPState(S,G)
      # transition may happen as a result of restarting
      # KeepaliveTimer, and must be dealt with here.
 }

 Update_SPTbit(S,G,iif)
 oiflist = NULL

 if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
    oiflist = inherited_olist(S,G)
    if( oiflist != NULL ) {
        set KeepaliveTimer(S,G) to Keepalive_Period
    }
 } else if( iif == RPF_interface(RP(G)) AND SPTbit(S,G) == FALSE) {
   oiflist = inherited_olist(S,G,rpt)
   CheckSwitchToSpt(S,G)
 } else {
    # Note: RPF check failed
    if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) {
       send Assert(S,G) on iif
    } else if ( SPTbit(S,G) == FALSE AND
                iif is in inherited_olist(S,G,rpt) {
       send Assert(*,G) on iif
    }
 }

 oiflist = oiflist (-) iif
 forward packet on all interfaces in oiflist

Question:  if the packet arrives on an interface/port that is NOT the
EXPECTED interface/port
as determined by the MRIB for the Source (the RPF_interface(S)) but it
is also not the case that it is the EXPECTED
interface/port as determined by the MRIB for the RP (the
RPF_interface(RP(g)).

ie for some reason the MRIB has a different idea of the reverse path
toward the source than 
where the data actually arrived on.   This is not a wrong-iif scenario
because the (s,g) entry does
not exist yet, we are just seeing data for the first time from a
non-local source.

Should the (s,g) be created with an IIF == the ACTUAL ingress
interface/port?  OR should it be
created with the MRIB view of the IIF?   OR should it not be created at
all, and just dropped with
no data forwarded??  

On a related topic, if Router B is an intermediate router on the path
from the LHR to the RP, and
the LHR initiates a switch to the SPT, the LHR will send an (s,g) Join
towards the RP, and be
received by Router B.  Router B looks up the RPF_interface(S) using the
MRIB, and creates
an (s,g,iif) entry where IIF is from the MRIB.     However, what happens
if data arrives from the
source on an interface NOT the same as the RPF_interface(RP), but also
NOT the same as
the expeced interface from RPF_interface(S)?    Do we accept the packet
and update the IIF to
be the actual ingress interface/port?  Or do we drop it since it is not
the EXPECTED interface?

Thanks for any information, I am not sure what to do in the case where
perhaps the MRIB doesn't
quite match reality.

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Su Haiyang <[email-masked]>
Date: Wed, 09 Jan 2008 10:47:45 +0800

Both of the Questions are implement-specific. You can create a dummy (S, G)
entry at the MRIB in order to drop all the successive data 

or just do nothing. But anyway, your system shouldn't forward any RPF failed
packets.

Have fun

Su Haiyang

  _____  

From: Julie Mcgray [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 7:10 AM
To: [email-masked]
Subject: [pim] reverse path question

Hi there, 

 Update_SPTbit(S,G,iif) 
 oiflist = NULL 

Question:  if the packet arrives on an interface/port that is NOT the
EXPECTED interface/port 
as determined by the MRIB for the Source (the RPF_interface(S)) but it is
also not the case that it is the EXPECTED 
interface/port as determined by the MRIB for the RP (the
RPF_interface(RP(g)). 

ie for some reason the MRIB has a different idea of the reverse path toward
the source than 
where the data actually arrived on.   This is not a wrong-iif scenario
because the (s,g) entry does 
not exist yet, we are just seeing data for the first time from a non-local
source. 

Should the (s,g) be created with an IIF == the ACTUAL ingress
interface/port?  OR should it be 
created with the MRIB view of the IIF?   OR should it not be created at all,
and just dropped with 
no data forwarded??  

On a related topic, if Router B is an intermediate router on the path from
the LHR to the RP, and 
the LHR initiates a switch to the SPT, the LHR will send an (s,g) Join
towards the RP, and be 
received by Router B.  Router B looks up the RPF_interface(S) using the
MRIB, and creates 
an (s,g,iif) entry where IIF is from the MRIB.     However, what happens if
data arrives from the 
source on an interface NOT the same as the RPF_interface(RP), but also NOT
the same as 
the expeced interface from RPF_interface(S)?    Do we accept the packet and
update the IIF to 
be the actual ingress interface/port?  Or do we drop it since it is not the
EXPECTED interface?

---

From: "Julie Mcgray" <[email-masked]>
Date: Tue, 8 Jan 2008 23:07:06 -0500

Thanks for the quick response Su!
 
So if the packet arrives on an interface that is not the expected
interface according
to the MRIB then I should not forward on it at all?   
I guess if there is a mismatch in the actual vs expected IIF, then it's
a problem either way.
 
So, for example,  an intermediate router from the LHR to the RP gets an
(s,g) join from
the LHR to join the SPT to the Source S.  It creates a (s,g,iif) where
iif is determined from the MRIB.
When it actually gets the first data packet, IF the packet arrives on a
different 
interface than MRIB suggests, then we get a WRONG-IIF.   Since we are in
the middle
of switching to the SPT, we want to update the IIF to be that of the
RPF_interface(S).
However, if the new IIF is NOT the RPF_interface(S), then we should NOT
update
the IIF and set it to the SPT?  WE should just ignore it until we get a
packet on the
interface that we EXPECT for S? 
 
Thanks again Su!

________________________________

From: Su Haiyang [mailto:[email-masked]] 
Sent: Tuesday, January 08, 2008 9:48 PM
To: Mcgray, Julie (BL60:SF23); [email-masked]
Subject: RE: [pim] reverse path question

Both of the Questions are implement-specific. You can create a dummy (S,
G) entry at the MRIB in order to drop all the successive data 

or just do nothing. But anyway, your system shouldn't forward any RPF
failed packets.

Have fun

Su Haiyang

________________________________

 

Hi there, 

 Update_SPTbit(S,G,iif) 
 oiflist = NULL

---

From: Su Haiyang <[email-masked]>
Date: Wed, 09 Jan 2008 12:14:24 +0800

Correct!

Have fun

Su Haiyang

  _____  

From: Julie Mcgray [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 12:07 PM
To: Su Haiyang; [email-masked]
Cc: Julie Mcgray
Subject: RE: [pim] reverse path question

So if the packet arrives on an interface that is not the expected interface
according

I guess if there is a mismatch in the actual vs expected IIF, then it's a
problem either way.

the LHR to join the SPT to the Source S.  It creates a (s,g,iif) where iif
is determined from the MRIB.

interface than MRIB suggests, then we get a WRONG-IIF.   Since we are in the
middle

Thanks again Su!

  _____  

Have fun

Su Haiyang

  _____  

 

Hi there, 

 Update_SPTbit(S,G,iif) 
 oiflist = NULL

---

From: John Zwiebel <[email-masked]>
Date: Wed, 9 Jan 2008 08:04:12 -0800

If we are talking about the last-hop, if (S,G) state is created,  
there is no reason
to not trigger a PIM join toward the source.  If it is a transient  
router, creating
state on receipt of a non-RPF packet can be problematic because you  
don't
want to trigger joins toward the source.

WRT your other questions, Julie, the RPF info is held by the MRIB and  
data is
only forwarded when received on the RPF interface for the longest- 
matched route.
ie. (S,G) and if (S,G) does not exist  (*,G).  The PIM spec discusses  
accepting
packets on the (*,G) interface when (S,G) exists (with a different  
RPF of course)
only on the last-hop while waiting for the first packet to actually  
arrive on the (S,G) RPF.

I'm not disagreeing with Su.

On Jan 8, 2008, at 6:47 PM, Su Haiyang wrote:

> Both of the Questions are implement-specific. You can create a  
> dummy (S, G) entry at the MRIB in order to drop all the successive  
> data
>
> or just do nothing. But anyway, your system shouldn’t forward any  
> RPF failed packets.
>
>
> Have fun
>
> Su Haiyang
>
>
>
> Question:  if the packet arrives on an interface/port that is NOT  
> the EXPECTED interface/port
> as determined by the MRIB for the Source (the RPF_interface(S)) but  
> it is also not the case that it is the EXPECTED
> ie for some reason the MRIB has a different idea of the reverse  
> path toward the source than
> where the data actually arrived on.   This is not a wrong-iif  
> scenario because the (s,g) entry does
> created with the MRIB view of the IIF?   OR should it not be  
> created at all, and just dropped with
> no data forwarded??
>
> On a related topic, if Router B is an intermediate router on the  
> path from the LHR to the RP, and
> the LHR initiates a switch to the SPT, the LHR will send an (s,g)  
> Join towards the RP, and be
> received by Router B.  Router B looks up the RPF_interface(S) using  
> the MRIB, and creates
> an (s,g,iif) entry where IIF is from the MRIB.     However, what  
> happens if data arrives from the
> source on an interface NOT the same as the RPF_interface(RP), but  
> also NOT the same as
> the expeced interface from RPF_interface(S)?    Do we accept the  
> packet and update the IIF to
> be the actual ingress interface/port?  Or do we drop it since it is  
> not the EXPECTED interface?
>
> Thanks for any information, I am not sure what to do in the case  
> where perhaps the MRIB doesn't
> quite match reality.
>
>

---

From: "Julie Mcgray" <[email-masked]>
Date: Wed, 9 Jan 2008 12:33:33 -0500

Hi John, thanks for your feedback!  Please see INLINE.
Thanks!
Julie

From: John Zwiebel [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 11:04 AM
To: Su Haiyang
Cc: John Zwiebel; Mcgray, Julie (BL60:SF23); [email-masked]
Subject: Re: [pim] reverse path question

If we are talking about the last-hop, if (S,G) state is created, there
is no reason 
to not trigger a PIM join toward the source.  If it is a transient
router, creating 
state on receipt of a non-RPF packet can be problematic because you
don't
want to trigger joins toward the source. 
[JM] Why is LHR different from intermediate router in this case?  If the
LHR 
        sends an (S,G) Join toward the source (whether for SSM case or
the
        case where it is initiating a switch to the SPT), it can send
the Join
        on the interface that it thinks is correct according to the
MRIB.  However,
        when it gets the data packet back (1st data packet in the SSM
case, 
        and 1st data packet on the SPT in the SM switching case), it
must check
        that the packet arrived on the interface that it expected for
that Source
        or it shouldn't forward the data on the OIL.   It cannot just
pick up whatever
        interface the packet came in on and use that as the IIF,
according to the spec.
        I'm not sure I understand what you're saying....

WRT your other questions, Julie, the RPF info is held by the MRIB and
data is 
only forwarded when received on the RPF interface for the
longest-matched route.
ie. (S,G) and if (S,G) does not exist  (*,G).  
[JM] Right, if we only have (*,g) state when we get a packet, we can
still accept the
       data and forward it on the (*,g) OIL.  Say we are at the RP and
we get data from
       a source and all we have is (*,g) state.  It is probably OK at
that point to get data from
       non RPF (I'll have to think about that -- not sure).  
       However, IF the RP does an (s,g) Join back towards the Source, 
       then when it gets the 1st native (non-register encapsulated
packet) packet from the Source, it MUST
       check that the packet arrived on the RPF interface according to
the MRIB (taking into
       account assert state).  If it doesn't arrive on the expected
interface/port, it should drop the packet
       and NOT switch to the SPT.  Correct?
 
       The other example is the intermediate router from the RP to the
Source, when the RP initiated
       a switch to the SPT, it sends a (s,g) Join toward the Source
through the intermediate router (Rx).
       Rx has no state because the original data was sent unicast to the
RP.
       Rx creates (S,G, IIF-towards-Source, OIF-from-Join) and forwards
the Join.  It creates state for the
       (S,G) entry.   When it gets the 1st data packet, IF it arrives on
a non-IIF interface, then PIM gets
       a WRONG-IIF.  But since the wrong-iif is NOT in the OIL, and Rx
is NOT in the middle of switching
       to the SPT, it DROPS the data and ignores the WRONG-IIF.   So, we
MUST make sure that
       the IIF is according to the MRIB, and we drop anything that that
doesn't match up with that.

  The PIM spec discusses accepting
packets on the (*,G) interface when (S,G) exists (with a different RPF
of course)
only on the last-hop while waiting for the first packet to actually
arrive on the (S,G) RPF.
[JM] Right, the switch to the SPT can be initiated from the LHR or the
RP toward the Source.
  In either case, we must know what the expected SPT IIF interface is or
we should not 
  accept it as switch completion.

	Both of the Questions are implement-specific. You can create a
dummy (S, G) entry at the MRIB in order to drop all the successive data 

	or just do nothing. But anyway, your system shouldn't forward
any RPF failed packets.

	Have fun

	Su Haiyang

	

	 

	Hi there, 

	I have a question about the determination of the IIF for a newly
created 
	(s,g) entry due to a cache miss (no existing entry, first data
packet 
	received from that source). 

	      # Note: a register state transition or
UpstreamJPState(S,G) 

	 Update_SPTbit(S,G,iif) 
	 oiflist = NULL 

	 if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined
) { 
	    oiflist = inherited_olist(S,G) 
	    if( oiflist != NULL ) { 
	        set KeepaliveTimer(S,G) to Keepalive_Period 
	    } 
	 } else if( iif == RPF_interface(RP(G)) AND SPTbit(S,G) ==
FALSE) { 
	   oiflist = inherited_olist(S,G,rpt) 
	   CheckSwitchToSpt(S,G) 
	 } else { 
	    # Note: RPF check failed 
	    if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G)
) { 
	       send Assert(S,G) on iif 
	    } else if ( SPTbit(S,G) == FALSE AND 
	                iif is in inherited_olist(S,G,rpt) { 
	       send Assert(*,G) on iif 
	    } 
	 } 

	 

	Question:  if the packet arrives on an interface/port that is
NOT the EXPECTED interface/port 
	as determined by the MRIB for the Source (the RPF_interface(S))
but it is also not the case that it is the EXPECTED 
	interface/port as determined by the MRIB for the RP (the
RPF_interface(RP(g)). 

	On a related topic, if Router B is an intermediate router on the
path from the LHR to the RP, and 
	the LHR initiates a switch to the SPT, the LHR will send an
(s,g) Join towards the RP, and be 
	received by Router B.  Router B looks up the RPF_interface(S)
using the MRIB, and creates 
	an (s,g,iif) entry where IIF is from the MRIB.     However, what
happens if data arrives from the 
	source on an interface NOT the same as the RPF_interface(RP),
but also NOT the same as 
	the expeced interface from RPF_interface(S)?    Do we accept the
packet and update the IIF to 
	be the actual ingress interface/port?  Or do we drop it since it
is not the EXPECTED interface?

---

From: John Zwiebel <[email-masked]>
Date: Wed, 9 Jan 2008 09:48:36 -0800

On Jan 9, 2008, at 9:33 AM, Julie Mcgray wrote:

> [JM] Why is LHR different from intermediate router in this case?

Transient routers should not initiate setting up an SPT.
Only the LHR should (that includes the RP, it is a LHR)

>   If the LHR
>         sends an (S,G) Join toward the source (whether for SSM case  
> or the
>         case where it is initiating a switch to the SPT), it can  
> send the Join
>         when it gets the data packet back (1st data packet in the  
> SSM case,
>         and 1st data packet on the SPT in the SM switching case),  
> it must check
>         that the packet arrived on the interface that it expected  
> for that Source
>         or it shouldn't forward the data on the OIL.   It cannot  
> just pick up whatever

I never said anything about forwarding.

---

From: "Julie Mcgray" <[email-masked]>
Date: Wed, 9 Jan 2008 13:02:32 -0500

Thanks John, 
 
> Only the LHR should (that includes the RP, it is a LHR)
 
Ok, you were only talking about the switch to the SPT.
I thought you were talking about the LHR in general.  The LHR 
can set up (s,g) state due to an SSM join that is NOT a switch to the
SPT.  
In which case it should only forward the subsequent data to it's
reciever host
if it arrives on the correct MRIB interface.
Thanks again!
Julie

From: John Zwiebel [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 12:49 PM
To: Mcgray, Julie (BL60:SF23)
Cc: John Zwiebel; Su Haiyang; [email-masked]
Subject: Re: [pim] reverse path question

	

	If we are talking about the last-hop, if (S,G) state is created,
there is no reason 
	to not trigger a PIM join toward the source.  If it is a
transient router, creating 
	state on receipt of a non-RPF packet can be problematic because
you don't
	want to trigger joins toward the source. 
	[JM] Why is LHR different from intermediate router in this case?

	
	  If the LHR 
	        sends an (S,G) Join toward the source (whether for SSM
case or the
	        case where it is initiating a switch to the SPT), it can
send the Join
	        on the interface that it thinks is correct according to
the MRIB.  However,
	        when it gets the data packet back (1st data packet in
the SSM case, 
	        and 1st data packet on the SPT in the SM switching
case), it must check
	        that the packet arrived on the interface that it
expected for that Source
	        or it shouldn't forward the data on the OIL.   It cannot
just pick up whatever
	        interface the packet came in on and use that as the IIF,
according to the spec.
	        I'm not sure I understand what you're saying....

---

From: Christopher Thomas Brown <[email-masked]>
Date: Wed, 9 Jan 2008 20:59:33 -0800

> only on the last-hop while waiting for the first packet to actually  

This is not quite correct.

 else if( iif == RPF_interface(RP(G)) AND SPTbit(S,G) == FALSE) {
     oiflist = inherited_olist(S,G,rpt)
     CheckSwitchToSpt(S,G)
 }

A router forwards on (*,G), ie out the inherited_olist(S,G,rpt),
regardless if it is LHR or an intermediate until the SPT-bit is set.

---

From: John Zwiebel <[email-masked]>
Date: Thu, 10 Jan 2008 09:22:26 -0800

> This is not quite correct.

The (S,G,R) is not the (S,G), it is still the shared tree.
It is impossible to have (S,G,R) with a different RPF interface
than (*,G)

It is also very rare to have a (S,G,R) entry that doesn't have a
NULL Olist.

CheckSwitchToSpt only happens on the last-hop.

    In Sparse-Mode PIM, last-hop routers join the shared tree towards  
the
    RP.  Once traffic from sources to joined groups arrives at a last- 
hop
    router, it has the option of switching to receive the traffic on a
    shortest path tree (SPT).

---

From: Christopher Thomas Brown <[email-masked]>
Date: Thu, 10 Jan 2008 11:17:50 -0800

> It is impossible to have (S,G,R) with a different RPF interface

If (S,G,SPT) exists then you will never accept the packet for forwarding
on the (*,G) interface without regard to if the router is a last hop or not.

However, an implementation may have (S,G) state internally without
the SPT-bit being set. For example, an intermediate router may have
received a PIM (S,G) as a downstream last-hop router is switching to
the SPT.  This router may also be on the RP tree. This router still
forwards based on the (*,G) entry or in the pseudo-code it arrived on the
RPF_Interface(RP(G)) and it is forwarded out the inherited_olist(S,G,RPT).

My point was accepting the packet for forwarding has nothing to do with
the router being a last-hop or not but only which interface it arrived on
and is the SPT bit set or not.

> CheckSwitchToSpt only happens on the last-hop.

It only performs a switch at a last-hop router. In the pseudo-code it
is still called but since there is no local membership state it will
not initiate a switch.

Chris