Re: MSDP CACHING PEER VS RPF PEER

From: Petr Lapukhov <petr_at_internetworkexpert.com>
Date: Fri, 23 Dec 2011 09:41:18 -0800

I belive your question is "whether the SA messages in SA Response are
subject to peer-RPF checks" and "whether the caching peer must be on
RPF path toward the originating RP". The answer is no to both
questions, and there are two reasons:

1) MSDP SA request/response messages are not relayed, they are
exchanged on pure p2p basis between two directly connected MSDP
speakers (peers). Therefore, there is no need for RPF check for
request message - it could be sent to any caching peer. Futhermore,
the requesting RP does not know the originating RP address prior to
requesting group state. There is even no field in SA Request message
to encode this information :) So even if you want, you can't do an RPF
check - only request the cached state for a group.

2) MSDP SA response messages do not carry any piggy-backed multicast
data, unlike the SA message, so there is no need to relay that
information either, and hence no need to RPF check the SA Response
message.

It is interesting to notice, that details on SA Request message
exchange did not make it to MSDP RFC, though you can find them in the
draft documents. The final RFC only specifies the TLV codes for
request/response messages.

-- 
Petr Lapukhov, petr_at_INE.com
CCIE #16379 (R&S/Security/SP/Voice)
CCDE #20100007
Internetwork Expert, Inc.
http://www.INE.com
Toll Free: 877-224-8987
Outside US: 775-826-4344
2011/12/23 Imran Ali <immrccie_at_gmail.com>:
> hI
>
> Does the caching RP in MSDP must be a peer RPF neighbor to the RP sending
> SA request messages ?
>
> can a non rpf peer in msdp act like a caching RP ??
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Fri Dec 23 2011 - 09:41:18 ART

This archive was generated by hypermail 2.2.0 : Sun Jan 01 2012 - 08:27:01 ART