Subject: [pim] Some comments on draft-farinacci-pim-pop-count-02

From: Stig Venaas <[email-masked]>
Date: Tue, 10 Jun 2008 10:23:19 +0200

I have a few comments and questions regarding pop-count-02.

1. Encoding

    I think you should use join-attributes as in
    draft-ietf-pim-join-attributes-03.txt

    This is a generic way of adding TLVs to joins. One advantage of
    this is that if routers support this generic format, then pop-count
    will to some degree work through routers that don't support
    pop-count itself.

2. SPT/RPT interaction

    Is it worth saying something about this? E.g. I wonder if when an RP
    builds SPT towards the source, should it then include stats from the
    RPT?

3. Registers

    Do you account for registers when you set MTU and tunnel flag?

4. How should it work with reliable transport?

5. TZ count

    I'm a bit sceptical to how well this can work. Can you expect the
    routers to have the necessary information? I wouldn't be surprised
    if there are cases where the tree crosses the same TZ multiple times.

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

---

From: "Greg Shepherd" <[email-masked]>
Date: Wed, 11 Jun 2008 18:23:27 -0700

>    will to some degree work through routers that don't support

I believe this makes sense (our original work on POP count predates
join-attributes) but will let Dino reply.

>    builds SPT towards the source, should it then include stats from the

Personally I don't think it's of much use. Can you perhaps give an
example of what RPT stats may be included?

>    Do you account for registers when you set MTU and tunnel flag?

Registers aren't part of the tree, so no.

> 4. How should it work with reliable transport?

Sorry, I don't understand the question. The stats are carried back in
the PIM joins. What form of reliable transport do you think may apply?

>    if there are cases where the tree crosses the same TZ multiple times.

Well, yes... So the skepticism should be around both how well you can
gather this info per node, and how useful this data is overall. I'm
not married to carrying TZ, but we did ask for some brainstorming
about other data we may want to carry in POP and maybe this was an
example talking point. ;-)

Thanks,
Greg

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 13 Jun 2008 01:23:02 -0700

> join-attributes) but will let Dino reply.

Right, agree. We will have a look at it. But can't get to it for a  
while. Both Shep and I are distracted on other things.

> example of what RPT stats may be included?

Agree with Shep, since in ASM the shared-tree is for bootstrapping in  
practice.

> Registers aren't part of the tree, so no.

No, but when the RP sends joins to the source DR, the effective MTU  
will be known. So the DR knows. It could send then a TooBig message to  
the source host. But this is all outside scope of this draft.

> the PIM joins. What form of reliable transport do you think may apply?

Shep, Stig is referring to the pim-port draft. If we send JPs over TCP  
and they are no longer periodic by nature, then we can't do what we  
want in the PIM pop-count draft.

Answer is you still send periodic ones but not that often. And you can  
send them over a TCP connection and minimize lost JPs and therefore,  
lost stats.

> example talking point. ;-)

Well, if I am in San Jose and you are in Oslo, and we connect a link  
between each other. We can configure that the timezone is different.  
So we don't have to calculate it.

Dino

---

From: Stig Venaas <[email-masked]>
Date: Fri, 13 Jun 2008 12:16:45 +0200

> Agree with Shep, since in ASM the shared-tree is for bootstrapping in 

I may agree with this. In theory some people may have configured their
routers to not switch to SPT though. Anyway, there is nothing in the
draft that says it should not be done for the RPT, so maybe you should
point that out? I don't think the current text is sufficiently clear.
> No, but when the RP sends joins to the source DR, the effective MTU will 
> be known. So the DR knows. It could send then a TooBig message to the 
> source host. But this is all outside scope of this draft.

ok, fine.

> and they are no longer periodic by nature, then we can't do what we want 
> in the PIM pop-count draft.
> 
> between each other. We can configure that the timezone is different. So 
> we don't have to calculate it.

Well yes, it can be useful, but I am a bit skeptical... I should point
out that I personally like this draft, although it does need more work.

Stig

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 13 Jun 2008 04:11:06 -0700

> out that I personally like this draft, although it does need more  

Indeed it needs more work.

Dino