Subject: PR-bit in the BGMP protocol

From: [email-masked]
Date: Mon, 16 Apr 2001 16:30:37 -0700

From:  James Huang@MITEL on 04/16/2001 04:30 PM PDT
Dave:

     Could you explain the purpose of the PR-bit (poison-reverse) in the BGMP
protocol?  When is it set or reset?  How does it affect the protocol?  I will
appreciate it if you could give some examples.

Thanks,
-- James Huang

"Dave Thaler" <[email-masked]> on 04/12/2001 07:02:04 PM

To:   James Huang/USA/Mitel@Mitel
cc:   [email-masked], [email-masked], [email-masked]

Subject:  RE: Accepting packets on a multi-access interface owned by BGMP

I think you're right in that the text needs to be changed to
cover the downstream case.

Thanks,
-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, April 12, 2001 6:37 PM
> To: Dave Thaler; [email-masked]; [email-masked]; [email-masked]
> Subject: Accepting packets on a multi-access interface owned by BGMP
>
>
> Hi all,
>
>      Section 5.2 of the latest BGMP spec
> (draft-ietf-bgmp--spec-02.txt)
> specifies the following rules on accepting packets arrived on
> an interface owned
> by BGMP:
>
> (1) If the packet was received over a point-to-point
> interface owned by BGMP,
> the packet is accepted.
>
> (2) If the packet arrived on a multiaccess network interface
> owned by BGMP, the
> packet is accepted if it is receiving data on a
> source-specific branch, if it is
> the designated forwarder for the longest matching route for
> S, or for the
> longest matching route for the nominal root of G.
>
> The second rule is for multiaccess network.  But it seems to
> me that this rule
> will only work for packets being forwarded upstream toward
> the root of the tree.
> For packets being forwarded down the tree, the downstream
> border router will not
> be the designated forwarder. So packets travelling downstream
> will not be
> accepted.  Am I missing something here??
>
>
> Thanks,
> James Huang
>
>
>
>
>

---

From: "Dave Thaler" <[email-masked]>
Date: Tue, 17 Apr 2001 11:40:14 -0700

I have a set of powerpoint slides somewhere that give
examples (starting from an example topology Isidor raised),
and I haven't tracked down where the slides are.

The PR-bit is discussed in the BGMP spec, which does
describe exactly when it's set or reset.

Its basic purpose is to indicate to BGMP nodes whether
they need to forward packets up towards the root domain.
For example, in a case where an (S,G) branch exists,
a transit domain may get packets along the (S,G) branch,
and needs to know whether to (also) forward them up
towards the root domain.  If the domain in question
is on the path between S and the root domain, then
the answer is yes (and the PR bit will be set on the
S,G state).  If the domain in question is not on the
path between S and the root domain, then the answer
is no (and the PR bit will be clear on the S,G state).

Hope this helps.

-Dave

> Sent: Monday, April 16, 2001 4:31 PM
> To: Dave Thaler
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: PR-bit in the BGMP protocol
> 
> 
> 
>

---

From: [email-masked]
Date: Tue, 17 Apr 2001 14:08:35 -0700

From:  James Huang@MITEL on 04/17/2001 02:08 PM PDT
Dave:

     Thanks for your reply.  From your email, it seems to imply that PR-bit in a
(S,G) state will affect how data packet is forwarded.  But I can not find any
rules regarding PR bit in section 5.2 (Multicast Data Packet Processing).  Do I
miss understand something?

     Also if you are able to track down the powerpoint slides, could you post it
in the bgmp mailing distribution?

Thanks,
-- James Huang

"Dave Thaler" <[email-masked]> on 04/17/2001 11:40:14 AM

To:   James Huang/USA/Mitel@Mitel, "Dave Thaler"
      <[email-masked]>
cc:   [email-masked], [email-masked], [email-masked]

Subject:  RE: PR-bit in the BGMP protocol

Hope this helps.

-Dave

---

From: "Dave Thaler" <[email-masked]>
Date: Tue, 17 Apr 2001 19:06:02 -0700

There's nothing in the data packet processing since the
other places in the spec talk about using the PR bit
to add/remove the target towards the root domain
in the target list.  For example:

"After the border router sends a BGMP (S,G) Join, if its (S,G) state
has the PR-bit clear, a (S,G) Poison-Reverse message (with the PR-bit
clear)
is sent to the ingress router for G.  The ingress router then creates
(S,G) if it does not already exist, and removes the next hop towards
the nominal root of G from the target list."

Since the forwarding is done using the target list, the 
forwarding rules implicitly take the PR-bit into account.

-Dave

> Sent: Tuesday, April 17, 2001 2:09 PM
> To: Dave Thaler

---

From: [email-masked]
Date: Wed, 18 Apr 2001 11:16:41 -0700

From:  James Huang@MITEL on 04/18/2001 11:16 AM PDT

Dave:

     The two rules regarding add/remove the target towards the root domain
to/from the target list of a BGMP (S,G) state are specified in the section for
PIM-SM (sec 5.4.2).  What is the reason they do not also apply to the other
intra-domain protocols??

     Also I have the following question with regarding to BGMP <-> PIM-SM
interaction.
     Given a domain X which is on the best path from S to G and a border router
R which is the best exit for G in domain X. How does the PIM-SM component of
router R knows that it should forward (S,G) traffic it receives internally from
the domain to its BGMP component?  This is required so that the BGMP component
will forward the (S,G) traffic upstream towards G.

Thanks,
- James C. Huang

"Dave Thaler" <[email-masked]> on 04/17/2001 07:06:02 PM

-Dave

---

From: [email-masked]
Date: Thu, 19 Apr 2001 13:59:53 -0700

From:  James Huang@MITEL on 04/19/2001 01:59 PM PDT

Dave:

Thanks,
- James C. Huang

-Dave