Subject: Re: [pim] draft-farinacci-pim-pop-count-02.txt as wg draft

From: Jean-Jacques Pansiot <[email-masked]>
Date: Mon, 07 Jul 2008 16:43:46 +0200

Stig Venaas a écrit :
> The PIM Pop Count draft was presented at the last wg meeting. At
> the meeting there were 15 people in favour of making it a wg work
> item, and 4 against. The draft is available at
> http://www.ietf.org/internet-drafts/draft-farinacci-pim-pop-count-02.txt
>
> To determine whether we should adopt it, we need your input. Please
> review the draft and respond to the list with opinions on wg adoption
> by Saturday June 28th.
>   
I know that it's too late, but anyway I support the draft

I have a few questions/remarks on the draft
In section 2.2 it is said "allows a single router to be queried"
however no mechanism is proposed to query a router. Is there any plan to 
have
a minimal tool to do that (an snmp MIB ?).  Or is it left to each router 
maker to invent its
own interface ?
It seems to me that some of the collected information could be very 
useful for a SSM source,
for example speed of links, MTU and number of oif. The number of oif 
(both transit and stub)
could be an indication on the number of receivers  .
So we could use two distinct querying mechanisms
- one for debugging/management on any multicast router
- one for the source to the first hop router (a la defunct msnip)

Some comments on the name of variables :
there are basically two kinds of variables :
some variables compute a sum over the whole (sub-)tree
such as "node count"  : I would reserve the name count for these,
and use another name such as depth for variables such as "TZ count" => 
TZ depth
(similarly for domain count, unless one wants to compute the number of 
all downstream domains ?).
Also it seems to me that "Diameter count" is not the diameter,
but somehow the radius (or the height ) of the tree

hope this helps

Jean-Jacques

> Stig
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
>   

_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 7 Jul 2008 10:39:30 -0700

> however no mechanism is proposed to query a router. Is there any  
> plan to have
> a minimal tool to do that (an snmp MIB ?).  Or is it left to each  
> router maker to invent its
> own interface ?

Our intent of the term use "query" meant, that you can ssh into the  
router and type a show command to get the data for the tree from that  
point southbound. If you wanted to do this today, you'd have to SNMP  
query that box and fanout to all boxes southbound on the multicast tree.

> - one for the source to the first hop router (a la defunct msnip)

This data could be put into a MIB so you can SNMP query for the stats  
data in the draft. So anyone volunteering to do a pim-pop-count  
MIB?  ;-)

> such as "node count"  : I would reserve the name count for these,

Sure.

> and use another name such as depth for variables such as "TZ count"  
> => TZ depth
> (similarly for domain count, unless one wants to compute the number  
> of all downstream domains ?).

Well the intent was count the number of time zones the tree crosses.

I'm not sure we have a variable that is "depth-based".

> but somehow the radius (or the height ) of the tree

Well, we thought about this term. Radius means middle or "half way"  
and that is not what is being conveyed here. Diameter count is telling  
you the number of hops to the farthest receiver from one point in the  
tree. So it's from one end (the root end)  to the farthest end  
(receiver leaf).

Dino

---

From: Stig Venaas <[email-masked]>
Date: Mon, 07 Jul 2008 23:46:47 +0200

Dino Farinacci wrote:
[...]
> Well, we thought about this term. Radius means middle or "half way" and 
> that is not what is being conveyed here. Diameter count is telling you 
> the number of hops to the farthest receiver from one point in the tree. 
> So it's from one end (the root end)  to the farthest end (receiver leaf).

I believe mathematically this is generally called the height,
alternatively the depth. I would not know what the diameter of a tree
is. If I were to guess, I would say something like maximum number of
nodes on the same level of the tree perhaps).

Hence, I would suggest height or depth rather than diameter.

Stig

---

From: JW Atwood <[email-masked]>
Date: Mon, 07 Jul 2008 19:57:46 -0400

Gents,

In fact, the diameter of a graph is a technical term, which for a 
multicast tree happens to be identical to the height, but this is only 
understood by mathematicians.

So, Stig is right: use "height", and you will be understood.  Use 
"diameter", and (some) people will scratch their heads...

  Bill

P.S. The diameter of a graph is the longest shortest path between any 
two graph vertices.  In other words, a graph's diameter is the largest 
number of vertices that must be traversed in order to travel from one 
vertex to another when paths that backtrack, detour or loop are excluded 
from consideration.

For a directed tree, the diameter happens to be equal to the height.  
For an undirected tree, it could be up to twice the height.

Stig Venaas wrote:
>> and that is not what is being conveyed here. Diameter count is 
>> telling you the number of hops to the farthest receiver from one 
>> point in the tree. So it's from one end (the root end)  to the 
>> farthest end (receiver leaf).
>

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email: [email-masked]
1455 de Maisonneuve Blvd. West    http: //users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 7 Jul 2008 17:05:47 -0700

Upstream-router
              ^
              |
           Me-the-root
           /      \
          R1      R3
          /        \
         R2        R4
                    \
                    R5

When Me-the-root announces what so far is called the "Diameter" to
Upstream-router, i think it will announce 3 (longest shortest path
from any leaf router to Me-the-root). The way you define diameter
i think it would rather be 5, not 3 (R1->R2->Me-the-root->R3-R4-R5) ?

Thats why diameter is probaby an incorrect term to use.

How about:

MaBaHoC = Max Branch Hop Count 

or MBHC ?

MTL = Min TTL to Leaves
(but using TTL in conjunction with multicast is politically incorrect ;-)

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
"The strategy is what you do, not what you write" - Wesley Clark
"Vision without ressources is hallucination" - James L. Jones
_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: Thomas Morin <[email-masked]>
Date: Fri, 11 Jul 2008 09:49:40 +0200

Support.

-Thomas

---

From: Stig Venaas <[email-masked]>
Date: Tue, 15 Jul 2008 13:47:08 +0200

> review the draft and respond to the list with opinions on wg adoption

I believe the objections we got on the list are among the 4 against at
the meeting. Of the people in favour on the list, I see two that were
not present at the meeting (according to the list of IETF attendees),
so I believe we have in total 4 against and 17 in favour.

While there have not been as many votes as I would have liked, I believe
this is sufficient for a rough consensus to adopt the draft.

Unless I hear anyone violently disagreeing with this conclusion by the
end of this week, the draft will become a pim work item.

Stig

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 16 Jul 2008 08:39:53 +0200

stig,

at this point in time motivation/rationales and impact are imho prime
decision points. 

- specific examples, the doc. states: 

"Putting the mechanism in PIM allows efficient distribution and
maintenance of such accounting information." the tree size/membership
independence is necessary but is it sufficient for efficiency ?

"Due to the periodic nature of PIM, the values can be accurately
obtained at 1 minute intervals (or whatever Join/Prune interval used)."
what about min/max bw rate ?  

- from the list an additional motivation was stated that would change
protocol operations:

"this mechanism could be used for admission control based on "weight" of
branches (number of receivers)."
 
so it is not just "out-of-band accounting exchanged via J/P messaging"
it has an impact on protocol operation. it is even more problematic than
initially thought. what is an heavy branch ? and is there a need to
account as proposed here to prevent overloads ?

at the end i would like to know what is this mechanism providing for the
protocol to perform better than it does today ?

thanks,
-d.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stig Venaas
> Sent: Tuesday, July 15, 2008 1:47 PM
> To: [email-masked]
> Subject: Re: [pim] draft-farinacci-pim-pop-count-02.txt as wg draft
> 
> Stig Venaas wrote:

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 16 Jul 2008 06:50:12 -0700

> branches (number of receivers)."

There was no intention to put admission control inside of PIM. PIM is  
just providing the raw data so possibly a source multicast host can  
decide, for example, what rate to send, to not overrun receivers.

> so it is not just "out-of-band accounting exchanged via J/P messaging"

Nope, that is all that is being transmitted. We are not duplicating an  
RSVP function.

> account as proposed here to prevent overloads ?

Since PIM maintains multicast trees, we just piggyback parameter data  
with the tree. And it is left to another design how to use it. Other  
designs can:

1) Specify how the first-hop PIM router delivers the accounting data  
to a source host that might want to do admission control.

2) Specify how any PIM router informs network management stations  
about the accounting data acquired.

> protocol to perform better than it does today ?

We are not saying this draft makes PIM run "better" or "faster" or  
"more efficient" but it provides a simpler way to get accounting data  
on a "per-tree" basis rather than today polling all devices on a  
multicast tree and correlating/compiling all of it together.

Dino

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 17 Jul 2008 08:37:46 +0200

> Behalf Of Dino Farinacci
> Sent: Wednesday, July 16, 2008 3:50 PM
> To: PAPADIMITRIOU Dimitri
> Cc: Stig Venaas; [email-masked]

accounting is not about protocol itself but the mcast trees/properties
as resulting from the actual protocol J/P exchanges. 

do i read correctly that you see as potential use a source adapting its
transmitting rate from the locally configured/ measured min/max rate ?

> Nope, that is all that is being transmitted. We are not 
> duplicating an RSVP function.

so, if the sole motivation is here about querying a single branch (part.
case the root) instead of n nodes the proposed mechanism is not within
scope since node queries via external systems is not within PIM scope.

the sole aspect upon PIM WG interest is whether or not a given msg
exchange gave rise to the expected action/processing - which is defeated
by the current mechanism that uses PIM to transport and compile
information that is not within its scope - 

> > it has an impact on protocol operation. it is even more 
> problematic  
> > than

same as above: you are mixing within the term accounting, information
that have mcast tree topological significance with others that are
(partially) characterizing the links (e.g. min/max rates) used by these
trees and a last set concerns the mcast group membership.

> about the accounting data acquired.

same as above: why adapting "queri-able" information to an external
management protocol needs to be standardized in PIM ? 

> multicast tree and correlating/compiling all of it together.

following this reasoning any combination of parameters determining the
resulting forwarding topology and bw rates should be piggybacked into
the routing protocol. you have used many times the fact that since being
a tree-building protocol it is conceivable to make use of such mechanism
-- but this argument does not answer the initial question: 

- why individual protocol engines have to be involved in compiling
global (i.e. non-local) information which are out side scope of their
local decision process ? while it involves information that PIM does not
process (at least today) ?
 
-d.
> >> I believe the objections we got on the list are among the 
> 4 against  
> >> at
> >> Unless I hear anyone violently disagreeing with this 
> conclusion by  
> >> the

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 17 Jul 2008 11:33:17 -0700

>>> "weight" of

Well the source figures that stuff out now by itself. But if the  
network had the information when the tree is built (before the source  
sends a packet), it could adapt pretty quickly.

If the network has the info, it could be used.

> scope since node queries via external systems is not within PIM scope.

I don't understand what you are saying.

> information that is not within its scope -

And I don't understand what you are trying to say here as well. Can  
you rephrase more clearly please?

> trees and a last set concerns the mcast group membership.

It has been commented by others that "accounting" isn't the right word  
to use. We have plans to change it in the next rev of the spec.

> management protocol needs to be standardized in PIM ?

I didn't say that work was done in the PIM working group.

> process (at least today) ?

Because if you want the per-tree state information, you'll have to do  
it in another protocol. PIM does process this information. And yes, we  
are using the PIM protocol to carry this information.

Look at it this way, we have could have 3 protocols:

o PIM for multicast tree building
o RSVP for available bandwidth management
o New protocol X to do what PIM-pop-count does

Wouldn't it be more efficient to do it all in one protocol? Now don't  
misunderstand me here, I am not proposing that PIM do RSVP  
functionality but carrying some simple tree-based parameters is pretty  
straight-forward.

People have been complaining for a decade, that multicast networks are  
hard to manage and they can't get the information from the network  
they need. This is a solution to that.

Dino

---

From: "Marshall Eubanks" <[email-masked]>
Date: Thu, 17 Jul 2008 15:34:00 -0400

> end of this week, the draft will become a pim work item.

I support the adoption of this draft.

Regards
Marshall