Subject: Re: parallel p2p links

From: [email-masked] (Ravi Shekhar)
Date: Thu, 5 Nov 1998 12:44:15 -0500 (EST)

>Yes, you are correct. So this just needs to be generalized for p2p links. 
    
    I am wondering if there a need for assert-winner to actually "schedule" 
    the pruning of the interface and wait for prune-override. As there is 
    no third router on the link, it can be pruned right away.

    Actually, is there need of chosing an assert-winner either. The moment
    first assert is seen (from either of the router), both the routers can 
    prune the interface right away. A potential assert-winner need not 
    send a assert in reply to the assert from potential assert-loser.    

    Thanks 
    - Ravi Shekhar.

>
>Thanks, 
>Tom 
>
>In message <[email-masked]> you write: 
>>In message <[email-masked]> you write: 
>>>The difference with Asserts in p2p links is that you should always 
>>>remove the interface from the downstream interface list when a prune 
>>>is received on a p2p link. There's no such thing as an assert winner 
>>>or loser (both sides lose). 
>> 
>>This isn't different from the what draft -00 says (other than talking 
>>about LANs): 
>> 
>> Asserts received on outgoing interface: 
>>... 
>> 3 If you have won the election but there are no directly connected 
>> members on the LAN, schedule to prune the interface. The LAN might 
>> be a stub LAN with no members (and no downstream routers). ... 
>> 
>>The loser will lose and prune the interface. The winner will prune the 
>>interface unless there are group members or the loser sends a prune-override 
>>(which it won't, since it's not the incoming interface). 
>> 
>> Bill

---

From: Bill Fenner <[email-masked]>
Date: Thu, 5 Nov 1998 09:59:00 PST

Ravi,

  You're right that Assert processing can probably be optimized on
P2P links -- I was just trying to point out that what's in the spec
now for LANs is also sufficient (but perhaps not optimal) for P2P
links.

  I think you can make the following slightly broader Assert optimization
statement:
If the Assert winner knows that the Assert loser is the only other
PIM router on the link and there are no group members present, it
may prune immediately without waiting for an override.

  That way, it works on 2-router LANs too.

  You suggested having both routers on a P2P link prune on the first
Assert message.  This is probably OK unless there are group members
present.  Having group members present on such a P2P link is probably
rare but should not be precluded.  And it only saves a single
message, so it's not clear that it's worth doing.

  Bill

---

From: [email-masked] (Ravi Shekhar)
Date: Thu, 5 Nov 1998 14:30:37 -0500 (EST)

Thanks Bill.
    I was under the impression that P2P links dont have group members.
    But if that is not the case, then it boils down to the 2-router LAN 
    configuration, and as you said, it becomes necessary to chose an 
    assert-winner if there are hosts interested in the data from the group. 

    - Ravi Shekhar.

---

From: Liming Wei <[email-masked]>
Date: Tue, 10 Nov 1998 17:34:34 -0800 (PST)

Ravi, upto your last message, I hope we all see that after the so
called assert optimization, the "assert on p2p links" really is just a
prune, no matter what it is called.  And assert is meant to be a
parallel path resolution mechanism on multi-access LANs. We don't want
to duplicate design it for p2p links.

Sorry for the late reply.

-Liming
---------
> From: [email-masked] (Ravi Shekhar)
>

---

From: Steve Deering <[email-masked]>
Date: Tue, 10 Nov 1998 18:05:01 -0800

> to duplicate design it for p2p links.

Liming,

A p2p link is just a degenerate case of a multi-access LAN, that is, a LAN
with a maximum of two attached routers.  Two routers attached to a p2p
link can both decide they are responsible for forwarding multicast from a
given source onto that link (i.e., the link is not on either router's
reverse path to the source; thus "parallel paths" can exist).  Wouldn't
the assert mechanism the natural way to resolve that in PIM?

I agree with others that it's conceptually cleaner to have prunes be things
you send "upstream" towards sources (i.e., only on RPF interfaces), and
asserts be things you send "downstream" (i.e., on non-RPF interfaces).

Steve

---

From: Liming Wei <[email-masked]>
Date: Tue, 10 Nov 1998 18:30:49 -0800 (PST)

> From: Steve Deering <[email-masked]>
> 
> Liming,
> 

Hey Steve,

How about lets rename a prune message sent on a p2p link an "assert"
:-), because that is the message carrying all sufficient information
(but not much more than sufficient information) and which yields the
right behavior, similar tor the "assert optimization for p2p
links". [Let's not start a thread on why p2p needs special treatment,
like so called "assert optimization" even if it were just a degenerate
case of multi-access LAN.]

Seriously, I'd say "prune" is a message to prune traffic off from
where they come from. There is no element of negotiation, not like the
assert message suggests, which has all information about metrics,
metric preference, IP address based arbitration, scheduled prune to
make sure no one indeed still wants traffic etc. "prune" has the right
semantics, that undiputedly expresses its intention to *prune*.

-Liming

---

From: [email-masked] (Ravi Shekhar)
Date: Tue, 10 Nov 1998 23:40:32 -0500 (EST)

I think from the last two messages posted by me and Bill on this
topic, it was clear that "assert optimization" cannot be done on 
PtoP links because there can be group-members attached to the PtoP links.
We need an assert winner which will forward the data on the PtoP link for the
group-members.

If that is true, prunes wont work on PtoP links.
There is not enough information in prunes to elect a winner which will
forward data on the link for group-members. So looks to me that assert
is a necessity here.

    - Ravi Shekhar.

---

From: Steve Deering <[email-masked]>
Date: Tue, 10 Nov 1998 20:58:25 -0800

At 6:30 PM -0800 11/10/98, Liming Wei wrote:
> where they come from.

"Pruning" is the removal of branches from a tree, not the removal of
arcs from DAGs.

Steve

---

From: Liming Wei <[email-masked]>
Date: Tue, 10 Nov 1998 23:04:16 -0800 (PST)

A host group member will NOT forward packets, and thus will not
be competing to win asserts, nor will it send any PIM packets.

-Liming

---

From: Liming Wei <[email-masked]>
Date: Tue, 10 Nov 1998 23:29:31 -0800 (PST)

> "Pruning" is the removal of branches from a tree, not the removal of

Come on Steve, did you tell your gardener to prune the branches of
your trees, but ASSERT the other stuff in your front yard ?

-Liming

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 10 Nov 1998 23:57:25 -0800 (PST)

>> "Pruning" is the removal of branches from a tree, not the removal of

    Maybe in DVMRP but not in PIM-DM.

Dino

---

From: Bill Fenner <[email-masked]>
Date: Wed, 11 Nov 1998 07:41:56 PST

>Seriously, I'd say "prune" is a message to prune traffic off from

Then there should be an explicit description of this in the spec.  All
mentions of prunes are of sending them to the RPF neighbor, other than
the brief mention in section 5.2.2 which doesn't say why one would want
to do it.  The spec should describe that the flooding graph is reduced
down to a multicast tree by
a) leaf routers sending prunes which get propogated upstream
b) redundant [links onto] multi-access LANs get removed from the graph
    by Asserts
c) redundant point-to-point links get removed from the graph by Prunes

Once you look at it that way, you might see why some people think that
it's more straightforward to use prunes for reducing the multicast
tree and asserts for reducing the graph to a tree.  Then the rules would
be:
a) leaf routers sending prunes which get propogated upstream
b) redundant links get removed from the graph by Asserts

  Bill

---

From: Steve Deering <[email-masked]>
Date: Wed, 11 Nov 1998 08:04:55 -0800

>     Maybe in DVMRP but not in PIM-DM.

Dino,

I know how the word "pruning" is used in DVMRP and PIM-DM.  My point was
that its usage in PIM-DM does not conform to its well-known, literal
meaning.  That can lead to confusion or misunderstanding.

Steve

---

From: [email-masked] (Ravi Shekhar)
Date: Wed, 11 Nov 1998 11:01:28 -0500 (EST)

>be competing to win asserts, nor will it send any PIM packets.
    
    I understand that part. And thats why "scheduling to prune" is not
    required on P2P links (or any LAN which has only 2 routers) because
    there wont be any third router to override the prune.

    But there is a second side to the problem, which is choosing a router
    to forward data for LOGAL GROUP MEMBERSHIPS.

    Host group members need to recv the data being sent for that group.
    The interest in the group would have been conveyed to both the 
    routers using IGMP membership report.

    Which of the two routers will be chosen to forward the data if both 
    send prunes to each other simultaneously? Either both will discard the
    prunes thinking there is a local group member and thereby sending two 
    copies of the data OR both will prune leaving the host group member 
    without any data.

    Assert-winner is one way of electing the router which will forward the
    data for such hosts.

    - Ravi Shekhar.