Re: MSDP CACHING PEER VS RPF PEER

Hi Imran,

I didnt understnad ur question properly . Can u rephrase it man.
From what Petr explained, yes if u form a TCP connection between two RP's
from two different AS, u just emit the information of source for this
particular multicast group.
Multicast Source Discovery protocol ( MSDP) emits the information of source
to synchronise the information about Source to RP's present in different AS
other than his own.
So basically there is no RPF check for MSDP SA messages, it justs transmits
the info about the source, so there will no multicast info piggbacked into
multicast packet as Petr mentioned

On Sat, Dec 24, 2011 at 12:02 AM, Petr Lapukhov <petr_at_internetworkexpert.com
> wrote:

> Right, directly connected in this context means "having direct MSDP
> peering session"
>
> 2011/12/23 Imran Ali <immrccie_at_gmail.com>:
> > *THANKS for great info .*
> >
> > but how can you say msdp peer directly connected ? .
> >
> > IN my senario RP's are centrally located in each PIM SM domain , and are
> > physically not directly connected .
> >
> > are you referring to logical tcp connection on port 639 ?
> >
> >
> >
> >
> >
> > On Fri, Dec 23, 2011 at 8:41 PM, Petr Lapukhov
> > <petr_at_internetworkexpert.com>wrote:
> >
> >> 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
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
>
>
>
> --
> 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
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
With Warmest Regards,
CCIE KID
CCIE#29992 (Security)
Blogs and organic groups at http://www.ccie.net