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

From: "Nicholas, Jonathan - ACD " <[email-masked]>
Date: Fri, 1 Feb 2008 07:45:05 -0500

Hm,  I think you may be making an incorrect equivalence statement.

A PMBR would use a (*,*,RP) to pull from an RP, which does not make it a
push equivalent.

Recapping PIM-SM briefly:

Group speakers push to the RP.
Group members pull from the RP.
During/after source tree switchover, group members pull from group
speakers.

In contrast, with PIM-DM:

Group speakers push to *everyone*.
Non-group members attempt to prune.

As to what is better, it very much depends on the multicast use you
intend.  As John Zwiebel correctly points out, there isn't really a
cohesive multicast structure in the internet.  I am aware of private
enterprise networks that use both PIM-SM and PIM-DM depending on the
application that needs multicast distribution.

Jonathan Nicholas

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Maren Peasley
> Sent: Thursday, January 31, 2008 4:02 PM
> To: Nicholas, Jonathan - ACD
> Cc: [email-masked]
> Subject: Re: [pim] (*,*,RP) state
>
> Hello Jonathan,
>
> If I understand correctly, PIM-SM (per RFC 4601) has the
> ability to support a push-equivalent that PIM-DM and DVMRP
> use, but PIM-DM and DVMRP do not have a pull-equivalent that
> PIM-SM uses.  This tells me that it is better to (*,*,RP)
> pull from n PMBRs to m RPs within PIM-SM than it is to pull
> from k PIM-DM-speakers to n PMBRs.  At known levels of state
> overhead in PIM-DM/DVMRP and PIM-SM, it seems like we could
> determine the density of RPs in a PIM-SM domain within which
> it makes sense to operate in a pull-manner and at what level
> it makes sense to operate in a push-manner.
>
> I am uncertain as to how solid the last statement is.  I
> would very much appreciate any thoughts, feedback, etc.
>
> Thank you,
>
> ________________________________
>
> Maren Peasley, CISSP, CCNP
> Technical Support Engineer
> High-End Security Products
> Symantec Technical Support
> Symantec Corporation
> www.symantec.com
>
>
> -----Original Message-----
> From: Nicholas, Jonathan - ACD [mailto:[email-masked]]
> Sent: Thursday, January 31, 2008 11:43 AM
> To: Maren Peasley
> Cc: [email-masked]
> Subject: RE: [pim] (*,*,RP) state
>
> PIM-DM doesn't have any such mechanism.  It really isn't
> needed, since by default all multicast get pushed to
> everyone, any such PMBR would get the messages without doing
> anything.  If the PMBR doesn't want the messages, then they
> can issue a (*,G) Prune.
>
> Jonathan Nicholas
>
> > -----Original Message-----
> > From: Maren Peasley [mailto:[email-masked]]
> > Sent: Thursday, January 31, 2008 2:27 PM
> > To: Christopher Thomas Brown
> > Cc: [email-masked]
> > Subject: RE: [pim] (*,*,RP) state
> >
> > Hello Chris,
> >
> > Thank you for replying.  It makes sense that in order for PIM-DM or
> > DVMRP to receive information from PIM-SM, that a PMBR would need to
> > reach into PIM-SM and pull everything (with subsequent
> prunes reducing
>
> > traffic flow to the needed level).  This seems like projecting
> > push-mode concepts into the pull-mode domain.  I haven't looked at
> > PIM-DM or DVMRP in any detail, so please pardon my
> ignorance, but is
> > there an equivalent concept in these to project a pull-mode concept
> > into them?  Maybe something like the idea of a (*,G) Join:
> > every PIM-DM/DVMRP router registering with the PMBR(s) when
> it has any
>
> > IGMP requests for a particular group?  The PMBR could then
> (*,G) Prune
>
> > from the PIM-SM
> > domain(s) if there was a source within the PIM-DM/DVMRP domain.
> >
> > Thank you again,
> >
> > ________________________________
> >
> > Maren Peasley, CISSP, CCNP
> > Technical Support Engineer
> > High-End Security Products
> > Symantec Technical Support
> > Symantec Corporation
> > www.symantec.com
> >
> >
> > -----Original Message-----
> > From: Christopher Thomas Brown [mailto:[email-masked]]
> > Sent: Wednesday, January 30, 2008 8:01 PM
> > To: Maren Peasley
> > Cc: [email-masked]
> > Subject: Re: [pim] (*,*,RP) state
> >
> > Maren Peasley initiated a hyperspace jump with:
> > > Hello,
> > >
> > > I apologize if this has already been asked before, but
> what is the
> > > purpose of (*,*,RP) state?  It is mentioned in RFC 4601 with some
> > > details given in section 4.1.
> >
> > To allow sources in a PIM-SM domain to be reachable in a PIM-DM or
> > DVMRP domain. A border router gets all the sources
> forwarded to it so
> > that it can then flood it into the other protocol(s).
> >
> > Chris
> >
> > _______________________________________________
> > pim mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pim
> >
>
> This e-mail and any files transmitted with it may be
> proprietary and are intended solely for the use of the
> individual or entity to whom they are addressed. If you have
> received this e-mail in error please notify the sender.
> Please note that any views or opinions presented in this
> e-mail are solely those of the author and do not necessarily
> represent those of ITT Corporation. The recipient should
> check this e-mail and any attachments for the presence of
> viruses. ITT accepts no liability for any damage caused by
> any virus transmitted by this e-mail.
> _______________________________________________
> pim mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/pim
>

This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.
_______________________________________________
pim mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pim

---

From: "Maren Peasley" <[email-masked]>
Date: Fri, 1 Feb 2008 13:22:22 -0700

Hello Chris, 

What is a hyperspace jump?

Why do you say that there is no need for any support in other protocols?

Thank you,

  CISSP Logo CCNP Logo

-----Original Message-----
From: Christopher Thomas Brown [mailto:[email-masked]] 
Sent: Thursday, January 31, 2008 4:13 PM
To: Maren Peasley
Cc: [email-masked]
Subject: Re: [pim] (*,*,RP) state

Maren Peasley initiated a hyperspace jump with:
> reach into PIM-SM and pull everything (with subsequent prunes reducing

> PIM-DM or DVMRP in any detail, so please pardon my ignorance, but is 
> into them?  Maybe something like the idea of a (*,G) Join: every 
> PIM-DM/DVMRP router registering with the PMBR(s) when it has any IGMP 
> requests for a particular group?  The PMBR could then (*,G) Prune from

> the PIM-SM

No need for any support in the other protocols.

The PMBR register encapsulates sources from the DM or DVMRP domain to
the RP(G). Similarly, it prunes once it has received a register stop
(presuming no other PIM-SM state would keep it unpruned like an (S,G)
join)).

Chris

---

From: "Maren Peasley" <[email-masked]>
Date: Fri, 1 Feb 2008 13:33:56 -0700

Hello John,

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.

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?

Thank you,

-----Original Message-----
From: John Zwiebel [mailto:[email-masked]] 
Sent: Thursday, January 31, 2008 5:41 PM
To: Maren Peasley
Cc: John Zwiebel; Nicholas, Jonathan - ACD ; [email-masked]
Subject: Re: [pim] (*,*,RP) state

On Jan 31, 2008, at 1:02 PM, Maren Peasley wrote:

>
> I am uncertain as to how solid the last statement is.  I would very 
> much appreciate any thoughts, feedback, etc.
>

2cents (meaning my opinion)

You generally don't want to try to do interdomain multicast routing with
a flood and prune protocol.

You'd have to have a very good reason do do so.

WRT:
>  At known levels
> of state overhead in PIM-DM/DVMRP and PIM-SM, it seems like we could 
> determine the density of RPs in a PIM-SM domain within which it makes 
> sense to operate in a pull-manner and at what level it makes sense to 
> operate in a push-manner.
>
After 15 years of working on PIM -- I'm not going to tell you you can't
do this.  But you might want to consider that many of us are advocating
simplifying multicast to just SSM and Bidir.

And then you have to determine how you plan on getting the folks who
have the deployed multicast (using ASM, MSDP and MBGP) to configure
their networks to support your proposal, and what equipment you are
going to have them run it on.

But I'm assuming you want to connect to the internet.  Perhaps not.

And I'm not claiming to know what might happen in the future.  Maybe you
have a really great idea?
_______________________________________________
pim mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pim

---

From: John Zwiebel <[email-masked]>
Date: Fri, 1 Feb 2008 12:49:23 -0800

> 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.

---

From: "Maren Peasley" <[email-masked]>
Date: Fri, 1 Feb 2008 14:15:09 -0700

Hello Jonathan,

I see where I went wrong in my statement.

Thank you for the correction! :)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nicholas, Jonathan - ACD 
Sent: Friday, February 01, 2008 4:45 AM
To: Maren Peasley
Cc: [email-masked]
Subject: Re: [pim] (*,*,RP) state

Jonathan Nicholas

> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Maren Peasley
> If I understand correctly, PIM-SM (per RFC 4601) has the ability to 
> support a push-equivalent that PIM-DM and DVMRP use, but PIM-DM and 
> DVMRP do not have a pull-equivalent that PIM-SM uses.  This tells me 
> that it is better to (*,*,RP) pull from n PMBRs to m RPs within PIM-SM

> than it is to pull from k PIM-DM-speakers to n PMBRs.  At known levels

> PIM-DM doesn't have any such mechanism.  It really isn't needed, since

> by default all multicast get pushed to everyone, any such PMBR would 
> get the messages without doing anything.  If the PMBR doesn't want the

> messages, then they can issue a (*,G) Prune.
>
> Jonathan Nicholas
>
> This e-mail and any files transmitted with it may be proprietary and 
> are intended solely for the use of the individual or entity to whom 
> they are addressed. If you have received this e-mail in error please 
> notify the sender.
> Please note that any views or opinions presented in this e-mail are 
> solely those of the author and do not necessarily represent those of 
> ITT Corporation. The recipient should check this e-mail and any 
> attachments for the presence of viruses. ITT accepts no liability for 
> any damage caused by any virus transmitted by this e-mail.

This e-mail and any files transmitted with it may be proprietary and are
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this e-mail in error please notify the
sender. Please note that any views or opinions presented in this e-mail
are solely those of the author and do not necessarily represent those of
ITT Corporation. The recipient should check this e-mail and any
attachments for the presence of viruses. ITT accepts no liability for
any damage caused by any virus transmitted by this e-mail.
_______________________________________________
pim mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pim
_______________________________________________
pim mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pim

---

From: "Maren Peasley" <[email-masked]>
Date: Mon, 4 Feb 2008 14:12:01 -0700

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!

-----Original Message-----
From: John Zwiebel [mailto:[email-masked]] 
Sent: Friday, February 01, 2008 12:49 PM
To: Maren Peasley
Cc: John Zwiebel; Nicholas, Jonathan - ACD ; [email-masked]
Subject: Re: [pim] (*,*,RP) state

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

> 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.

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.

> 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

> widely used, it must be backwards compatible with a number of 
> multicast routing protocols and deployments, not just PIM-DM and 
> DVMRP.
>

---

From: "Maren Peasley" <[email-masked]>
Date: Wed, 6 Feb 2008 12:13:23 -0700

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,

www.symantec.com <http://www.symantec.com/>  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Shilpi Sinha
Sent: Monday, February 04, 2008 11:45 PM
To: Maren Peasley; John Zwiebel
Cc: Nicholas, Jonathan - ACD ; [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of
Maren Peasley
Sent: Tuesday, February 05, 2008 2:42 AM
To: John Zwiebel
Cc: Nicholas, Jonathan - ACD ; [email-masked]
Subject: Re: [pim] (*,*,RP) state

Hello John, 

WRT: comments

WRT: lipstick on pig

Thank you very much!

Symantec Corporation

www.symantec.com 

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

To: Maren Peasley

 

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

:-)

internet.

 

pim mailing list

[email-masked]