Subject: Re: Re: [pim] Re : RPT - SPT cross roads.

From: "Bakar" <[email-masked]>
Date: 16 Jul 2002 04:45:18 -0000

Hi Z,

   Thanks for the detailed analysis. But i couldnt
understand the T-bit stuff. draft speaks about a T-bit which is 
xchanged in hello messages to track suppression of join 
messages.

   But you seem to be talking something new. Could you point me a 
reference on where to look more about this T-bit decision ?

thanx and regards,
Bakar

On Sun, 14 Jul 2002 John Zwiebel wrote :
>On 7/11/02 1:22 AM, "O.L.N.Rao" <[email-masked]> wrote:
>
> > Hi Bakar,
> >
> >   Protocol Overview -> Multi-access Transit LANS : States,
> >       "Assertion comes into picture only when
> >       there is more than one upstream router".
> >
> >   Assertion do not occur on if2 in this case as there are no 
>two
> >   upstream routers for B.
> >
>
>In this topology, you do have two upstream routers.  One is 
>upstream
>On the SPT and the other is upstream on the RPT.  The RPT 
>always
>Loses to the SPT, but there is still an assert that takes 
>place.
>
>Remember the T-bit.  It belongs to the last hop router.  Any
>Router upstream that decides to not forward traffic down the 
>RPT
>Without having received a (S,G,R) prune is taking the T-bit 
>decision
>Away from the last hop -- potentially cutting off that receiver 
>if
>Data never flows down the shared-tree, which is one of the 
>possibilities
>Here if we follow the suggestion.
>
>And as far as the receiver down the if3 branches, he doesn't 
>care
>Whether it got to A on the RPT or SPT he just wants the packet 
>and
>Wants it now.
>
>When the assert happens A loses because its on the RPT.  At 
>that
>Point A creates (S,G) state and prunes the RPT.
>
>Traffic for all receivers will now be delivered down the SPT to
>Routers A and B.
>
>What about the receiver on if5 you ask, its on the (*,G) tree.
>So, B has (S,G) state with an inherited interface (if5).  It
>Stays that way until the  receiver on if5 joins the SPT and
>Sends (S,G,R) prunes up to RTR b.
>
>WRT the question of forwarding data from the RPT on an S,G 
>route,
>Is the T-bit set?
>z
>
> > Thanks & Regards, O.L.N.Rao
> >
> >
> > ----- Original Message -----
> > From: "Bakar" <[email-masked]>
> > To: <[email-masked]>
> > Sent: Thursday, July 11, 2002 12:14 PM
> > Subject: [pim] RPT - SPT cross roads.
> >
> >
> >> Hi,
> >>
> >>    I couldnt come to conclusion on what should be the 
>behaviour
> >> of
> >> PIM in a particular scenario.
> >>
> >>         +-------+      +-------+
> >> -if1---|   A   |--if2-|   B   |---if4--
> >>         |_______|      |_______|
> >>              |              |
> >>             if3            if5
> >>              |              |
> >>
> >> B rx (*,G) join on if5, sends (*,G) join to A on if2.
> >> A sends (*,G) join on if1 towards RP.
> >>
> >> A rx (S,G) join on if3, and forwards (S,G) join on if2 to B, 
>and
> >> B
> >> forwards (S,G) join on if4 towards S.
> >>
> >> when data comes via RPT for S, the data at A is forwarded 
>only
> >> on
> >> if2 and B forwards on if5 only though
> >> A and B has (S,G) join states on if3 and if2 they are not
> >> forwarded for the simple reason that it is RPT data.
> >> This fine.
> >>
> >> Lets say Data comes via SPT also for S. when B first rx data 
>on
> >> if4, it sets the SPTbit and starts to forward data on if2 and 
>on
> >> if5. B also sends (S,G,rpt) prune on
> >> if2 to A.
> >>
> >> This will lead to a assert situation, even though we are not 
>on
> >> a
> >> multi access LAN.
> >>
> >> I am not very clear on how the scenario proceeds from here.
> >>
> >> Is the forwarding of RPT data on an (S,G) IIF acceptable ?
> >> Should
> >> A in the first place should'nt have forwarded the RPT data 
>on
> >> if2
> >> ?
> >>
> >> regards,
> >> Bakar
> >>
> >> _________________________________________________________
> >> There is always a better job for you at Monsterindia.com.
> >> Go now http://monsterindia.rediff.com/jobs
> >>
> >> _______________________________________________
> >> pim mailing list
> >> [email-masked]
> >> http://catarina.usc.edu/mailman/listinfo/pim
> >>
> > _______________________________________________
> > pim mailing list
> > [email-masked]
> > http://catarina.usc.edu/mailman/listinfo/pim
> >
>
>_______________________________________________
>pim mailing list
>[email-masked]
>http://catarina.usc.edu/mailman/listinfo/pim

_________________________________________________________
There is always a better job for you at Monsterindia.com.
Go now http://monsterindia.rediff.com/jobs

_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: John Zwiebel <[email-masked]>
Date: Tue, 16 Jul 2002 12:13:38 -0700

> reference on where to look more about this T-bit decision ?

The "T-bit" is very old.  Look on p18 section 4.2.  In this
Draft it is called the "SPTbit", which is too long to show up
In a "sh ip mr" on a cisco router, and since nearly everything
Else is "S", only "T" was left.  Basically, this is the bit that
Is set in an (S,G) mroute that indicates the router has actually
Received packets on the RPF interface for that mroute, so that
Now it should only forward those packets and no longer forward
Packets received on the shared-tree.

My point about the "T-bit" belonging to the last-hop router
Is somewhat misleading.  Every router with both (*,G) and (S,G)
State has to make that decision.  The point I was trying to make
Is that upstream routers can not make that decision for downstream
Routers.  Ie, an upstream router can't determine whether or not
A downstream router is on the RPT or SPT, but has to forward
Data based on the interfaces in its Olist.

The question you asked was whether or not to forward data received
On the RPT out the IIF in the (S,G).  And the answer is yes you can
Unless the T-bit (SPTbit) is set for that mroute.  And the SPTbit
Is set because of the assert process.

Look at section 4.2.2 page 19.

---

From: Mark Handley <[email-masked]>
Date: Tue, 16 Jul 2002 12:26:02 -0700

>Packets received on the shared-tree.

I think you're talking at cross-purposes.  I think Bakar is referring
to the T but in the LAN Prune Delay option:

     o OptionType 2: LAN Prune Delay

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Type = 2             |         Length = 4            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |T|        LAN Delay            |      Override_Interval        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       The LAN_Prune_Delay option is used to tune the prune propagation
       delay on multi-access LANs.

     The T bit specifies the ability of the sending router to disable
     joins suppression.

     LAN Delay and Override_Interval are time intervals in units of
     milliseconds are are used to tune the value of the
     Override_Interval(I) and its derived timer values. Section 4.3.3
     describes how these values affect the behavior of a router.

Basically if all the routers on a LAN set the T bit, and explicitly
track all the neighbors who joined a group, the you don't need to do
Join suppression.

But this is not currently fully specified - don't set the T bit unless
you're sure you know what you're doing.

Cheers,
	Mark

---

From: John Zwiebel <[email-masked]>
Date: Tue, 16 Jul 2002 12:49:03 -0700

> to the T but in the LAN Prune Delay option:

T-bit is an overloaded term.  Bakar looked for "T-bit" in the draft
And found only the option you show.

T-bit is what it is (was) called in the cisco IOS implementation
When discussing the SPTbit.

Bakar wanted to know what I meant when I said T-bit and I meant
"T-bit" as in "cisco" or "SPTbit" as in the current draft.