Re: [pim] (*,*,RP) state

["Maren Peasley" <[e-mail]>]

Hello Shilpi,
 
Thank you for replying to me.  Thank you also for your description of
PIM mechanics.  I have received the reply that I was looking for.
 
Thank you,
 
________________________________

Maren Peasley, CISSP, CCNP
Technical Support Engineer
High-End Security Products
Symantec Technical Support
Symantec Corporation
www.symantec.com <http://www.symantec.com/>  
 

________________________________

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Shilpi Sinha
Sent: Monday, February 04, 2008 11:45 PM
To: Maren Peasley; John Zwiebel
Cc: Nicholas, Jonathan - ACD ; [e-mail]
Subject: Re: [pim] (*,*,RP) state



Hi Maren,

 

To me it appears that the reasoning for why it is being done this way is
more governed by the underlying principles for dense mode and sparse
mode protocol. 

 

Any dense mode protocol is a flood based protocol. It always assumes
that traffic from source would anyway reach its first hop router. It
does nothing to pull the traffic from source. So in case you had to
change this wouldn't you be playing with the underlying criteria?

 

On the contrary PIM SM had always been a pull based protocol and even
for providing this interop with dense mode networks, it is doing nothing
against its principles of pulling. Even in case of downstream IGMP
interest, it sends a (*,G) or a (S,G) join towards the upstream. The
only difference here is that when it comes for interop with dense mode,
it doesn't know of a G or SG for which it should join for and requires
pulling of all the traffic whose source happens to be in SM domain. Thus
a PMBR (router linking SM and DM) should take care of pulling all SGs as
downstream dense mode network should get the traffic anyway. Now since
any specific G or SG is not known, (*,G) or (S,G) joins cannot be sent.
Since RP is suppose to be known by all routers in SM domain, for pulling
traffic, PMBR would initiate (*,*,RP1) to (*,*,RPn) joins where 1-n are
the RPs for different groups configured in that domain.

 

I am not sure if I have made my point clear but to me this appears to be
a more obvious choice as we don't dilute the concept behind a pull or
push based protocols.

 

I hope this helps.

 

Thanks and regards

Shilpi

 

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Maren Peasley
Sent: Tuesday, February 05, 2008 2:42 AM
To: John Zwiebel
Cc: Nicholas, Jonathan - ACD ; [e-mail]
Subject: Re: [pim] (*,*,RP) state

 

Hello John, 

 

Thank you again for your answers and insight - I definitely appreciate

the time that you are taking to reply to my questions.

 

WRT: comments

 

Just to allay any confusion, I didn't mean my PIM-DM comments or

questions about (*,*,RP) state.  I meant my comments to RFC 4601.

 

WRT: lipstick on pig

 

If (*,*,RP) isn't used for backwards compatibility with older multicast

routing protocols (I am new to this, I am not sure what is old and what

is new yet), then why was the decision made to mod PIM-SM to handle

other multicast routing protocols instead of the other way around?  I

understand that given PIM-SM, PIM-DM or DVMRP and the behaviour

specified in Appendix A of RFC 4601, there is no further need to "add"

anything - this comprises a complete system that is functional.  I guess

what I don't understand is not that it functions, but rather why it

functions the way it functions - why wasn't effort put into PIM-DM to

make it compatible with PIM-SM?  Why isn't there some function within

DVMRP that speaks to a border router that handles dealings with other

protocols?  Why were state and protocol mechanisms put into PIM-SM to

make it work with these other protocols?

 

I'm new at this an likely missing much.  Perhaps, as this is a

working-group, these questions are inappopriate (someone please tell me

if this is so).  For me to understand something, I need to not only

understand how it functions, but also why it was designed the way it was

- what problem is this solution solving?

 

Thank you very much!

 

________________________________

 

Maren Peasley, CISSP, CCNP

Technical Support Engineer

High-End Security Products

Symantec Technical Support

Symantec Corporation

www.symantec.com 

 

 

-----Original Message-----

From: John Zwiebel [mailto:[e-mail]] 

Sent: Friday, February 01, 2008 12:49 PM

To: Maren Peasley

Cc: John Zwiebel; Nicholas, Jonathan - ACD ; [e-mail]

Subject: Re: [pim] (*,*,RP) state

 

 

On Feb 1, 2008, at 12:33 PM, Maren Peasley wrote:

 

> 

> 

> WRT: 2cents

> 

> I am of the same opinion.

> 

> WRT: SSM and Bidir

> 

> I look forward to reviewing each of these! :)  I am reticent to begin 

> my next review as my previous comments have gone undebated and I would

 

> like to complete the discussion of these before taking up the next 

> one.

 

If you want to review ancient history....

:-)

 

Look, there are some excellent reasons to deploy dense mode protocols.

There has been a lot of work on PIM dense mode and there are some good

implementations.  Jonathan has put a lot of effort into it.

 

But -not- in an interdomain environment.  Not across the internet.

 

WRT backward compatibility: why?

There isn't enough interdomain multicast being deployed now?

 

PIM-SM/MSDP/MBGP have been deployed for over 10 years across the

internet.

We went through all the backward compatibility problems already.

There's no reason to keep putting lipstick on that pig.

 

Customers aren't asking for it.

 

We do not support dense-mode on NX-OS.

 

 

> 

> Your statements seem to reflect my perception that multicast is not 

> largely deployed, at least across the Internet.  I was curious as to 

> the design decision to make PIM-SM yank traffic into PIM-DM instead of

 

> having PIM-DM request traffic from PIM-SM (or any PMBR), especially as

 

> both PIM-DM and PIM-SM fall under the purview of the PIM-WG.  Your 

> statements also made me realize that if PIM-SM is to be adopted and 

> widely used, it must be backwards compatible with a number of 

> multicast routing protocols and deployments, not just PIM-DM and 

> DVMRP.

> 

> Is this a correct summary?

> 

 

_______________________________________________

pim mailing list

[e-mail]

http://www.ietf.org/mailman/listinfo/pim

_______________________________________________
pim mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/pim