Subject: [pim] RP is pim neighbor

From: "Julie Mcgray" <[email-masked]>
Date: Wed, 9 Jan 2008 17:47:56 -0500

Is it a requirement that the RPF(RP) (according to the MRIB) is
a known PIM neighbor?  What about RPF(S)?
I don't see anything explicit in the RFC, only that Join/Prune and
Assert 
messages must come from a known PIM neighbor.  
Thanks!
_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Su Haiyang <[email-masked]>
Date: Thu, 10 Jan 2008 10:15:06 +0800

Here you are, refer to the section 4.5 of RFC 4601:

"

In general, a PIM Join/Prune message should only be accepted for

processing if it comes from a known PIM neighbor.  A PIM router hears

about PIM neighbors through PIM Hello messages.  If a router receives a

Join/Prune message from a particular IP source address and it has not

seen a PIM Hello message from that source address, then the Join/Prune

message SHOULD be discarded without further processing.  In addition, if

the Hello message from a neighbor was authenticated using IPsec AH (see

Section 6.3) then all Join/Prune messages from that neighbor MUST also

be authenticated using IPsec AH.

"

Have Fun

Su Haiyang

  _____  

From: Julie Mcgray [mailto:[email-masked]] 
Sent: Thursday, January 10, 2008 6:48 AM
To: [email-masked]
Subject: [pim] RP is pim neighbor

Is it a requirement that the RPF(RP) (according to the MRIB) is 
a known PIM neighbor?  What about RPF(S)? 
I don't see anything explicit in the RFC, only that Join/Prune and Assert 
messages must come from a known PIM neighbor.  
Thanks!

---

From: "Julie Mcgray" <[email-masked]>
Date: Wed, 9 Jan 2008 21:42:23 -0500

Hi Su,
I know about this requirement, as well as the requirement that an Assert
message
come from a valid Pim neighbor.  However, I don't see anything that
indicates
that the reverse-path neighbor toward the RP must be a PIM neighbor.
For example, in the case of an MRIB change such that the nexthop toward
the
RP has changed.  Must it be verified that the nexthop is a PIM neighbor
as seen
via Hello messages before sending Joins upstream toward the RP?  The RP,
of
course, would not accept the Join if the Join was not sent from a PIM
neighbor, but
my concern is the opposite.
Thanks!!
Julie

________________________________

From: Su Haiyang [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 9:15 PM
To: Mcgray, Julie (BL60:SF23); [email-masked]
Subject: RE: [pim] RP is pim neighbor

"

"

Have Fun

Su Haiyang

________________________________

---

From: Su Haiyang <[email-masked]>
Date: Thu, 10 Jan 2008 11:05:36 +0800

Hi, Julie,

 You'r  right. It hasn't been clearly mentioned at the draft if a
RPF_NBR(RP)/RPF_NBR(S) should be chosen 

before any PIM hello packets are received from it. Generally in order to
lower the join latency or make the converge time shorter,

it's better to trust the nexthop informed by MRIB before the neighborship is
established with it. But there is a tip; the router can trigger a PIM hello
neighbor 

before sending any join/assert guarantying the triggered join/assert can be
accepted by the MRIB's nexthop. Remember, PIM neighbor is a uni-directional
neighborship.

Have Fun

Su Haiyang

  _____  

From: Julie Mcgray [mailto:[email-masked]] 
Sent: Thursday, January 10, 2008 10:42 AM
To: Su Haiyang; [email-masked]
Cc: Julie Mcgray
Subject: RE: [pim] RP is pim neighbor

Hi Su,

For example, in the case of an MRIB change such that the nexthop toward the

RP has changed.  Must it be verified that the nexthop is a PIM neighbor as
seen

via Hello messages before sending Joins upstream toward the RP?  The RP, of

Thanks!!

Julie

  _____  

"

"

Have Fun

Su Haiyang

  _____

---

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

> messages must come from a known PIM neighbor.  

Look at the definitions of the RPF'(*,G) and RPF'(S,G) macros (page 24,25).
Assuming no assert loser state for which you would need neighbor state
then they return NBR(I, A).

Unfortunately there is no nice pseudo-code definition of NBR(I, A).
There is only the following on page 25:

"The function NBR( I, A) uses information gathered through PIM Hello
 messages to map the IP address A of a directly connected PIM neighbor
 router on interface I to the primary IP address of the same router
 (Section 4.3.4).  The primary IP address of a neighbor is the address
 that it uses as the source of its PIM Hello messages."

It is probably safest to argue that NBR should return NULL if there is
no PIM hello state with a mapping for A on I. If you go with this
arguement then the answer to your question is yes, there is such a
requirement.

The alternative would be to return A itself. If A is an IPv4 address this
is OK unless the link has multiple logical subnets on it. If A is an IPv6
address this is OK if A is a link local address.

In either case, once the mapping is learned you may need to correct the
internal state you have stored.

Chris

---

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

On Jan 9, 2008, at 6:42 PM, Julie Mcgray wrote:

> Hi Su,
> I know about this requirement, as well as the requirement that an  
> Assert message

The question is not relevant.

Send the join to a router not running PIM, what happens?

Since the URIB is where the RPF information is discovered,
it isn't like you are going to put RPF routes into PIM so you
can ignore the non-neighbor with the better routing metric
to choose a PIM neighbor with the worse metric.