Subject: RE: Assert on outgoing interface

From: vishwas <[email-masked]>
Date: Tue, 10 Nov 98 21:12:00 PST

In message <[email-masked]>you write:
>A new draft 01 is released, it would be nice to have another writeup
>giving the difference between the previous version and this.

I did a diff; there were several minor wording changes and a couple of
extra sentences added.

1. Change "flooding" to "broadcasting" in 4th paragraph of section 4,   
even
though for PIM-DM, "flooding" is the more correct term.

[vishwas]
True.
2. Slight wording change in the beginning of section 5.
[vishwas]
:-(
3. Slight wording change in 2nd para of section 5.1
[vishwas]
:-)
4. Clarify wording about Asserts in 3rd para of 5.1 (don't say "prunes")
[vishwas]
:-)
5. Strengthen wording about not sending prunes in response to each packet
you get on a negative cache entry (1st para of 5.2.1).

[vishwas]
must ->  MUST
6. Minor wording change when talking about filling in 0.0.0.0 as upstream
router.

7. Added rate-limiting prunes when receiving prunes on an outgoing P2P
interface.

[vishwas]
But is the rate limiting really required for prunes or asserts in   
general..?
esp. for prunes when HOLDTIME in the join/prune message will cause the   
upstream to block data and so prunes may not be sent that regularly. Same   
thing applys to asserts too I suppose..!!!
8. Minor wording change with Assert timer.
[vishwas]  ?????
9. A little more info about the graft packet format.
[vishwas]
:-))

I have a slight problem with #1.  I think I have a real problem
with #7.  Pruning off redundant P2P links fits so nicely into the
job of Asserts, and kind of poorly into the job of Prunes.

  Bill

[vishwas]

section 5, first pyra, last sentence,     or can be replaced by,

1) and/or .....host members for group G.
2) Also in the begining of this pyra, it should be made clear that the   
forwarding entry is created only on recept of multicast data, so the   
sentence "If a receiving router does not already have a forwarding entry,   
it creates it for the  source and group G." may need to be re-phrased.   
And it should also be mention in this pyra that, if mcast data fails RPF   
lookup then, the packet should be dropped.

3) I find that many drafts are not making a proper use of section 2   
Terminology, though they include it.

I suppose may and must be in CAPITALS to stress it.
Authors pl. give a thought to this in the next version of  this draft.

4) Section 5.4 DR Election
    I think its time to mention "The implementations confirming to this   
version of the draft should use IGMPv2"

5) Section 5.5 How to assign a preference value in asserts, for sources   
which are directly connected...?
    I read some where saying it should be zero. Why this deviation..?

6) I feel it is un-necessary to send an assert AGAIN by an assert winner,   
just to tell other routers who WON, when they allready know they are the   
LOOSERS. Can this sentence be eliminated from section 5.5.....?

7) A small typo in section 5.5 last sentence,  ... 3   whent he --->   
  when the
Comments please.!!!

8) Another typo in section 6.7
      .... The source address SHOULD be included in THE ....

I better do a spell check now... use WINDOZE...

9) Typo section 1    "employs"

10) Typo section 5.2.1 8th pyra 2nd sentence,
      WINDOZE says   "occurrence"

11) Typo section 5.4 2nd pyra
     "periodically"

COMMENTS PLEASE....

Regards
vishu

---

From: vishwas <[email-masked]>
Date: Thu, 12 Nov 98 13:31:00 PST

it is agreed that, outgoing interfaces referred in the assert section, do
not
include the pruned interfaces.

am i right?
[vishwas]
Right, For more confirmance consider the following example,

                        O  R1
          ________ |___________
              |                       |
        R3 O                      O R2
        ___ |_____________ |____
                        |
                       O R4

R3 is currently down. R2 is currently forwarding for R4, and has a better   
metric [1,15]
Later when R3 comes up, R2 sends an assert for [1,15]. R3 has [1,20] and   
HE WILL PRUNE HIS INTERFACE (to be metioned in draft) and will send an   
assert [1,20]
R2 will now come to know he is the winner and HE WILL SEND ANOTHER ASSERT   
[1,15] (according to the draft) which I feel is un-necessary, as R4 has   
received asserts from both of the upstreams and taken a proper decision.

Now If we want still R2 to send assert, THEN WE SHOULD MENTION IN THE   
DRAFT, WHAT R3 WILL DO..? As he has allready pruned his outgoing   
interface based on the previous assert. IT SHOULD BE MENTIONED IN THE   
DRAFT as 5th point saying, Asserts received on pruned outgoing interfaces   
should be discarded and no asserts should be sent in responce to this.

I also feel the winner sending the last assert confirming its winning, is
unnecessary.

[vishwas]

DONE.

DS

---

From: vishwas <[email-masked]>
Date: Thu, 12 Nov 98 14:22:00 PST

In message <[email-masked]> you write:
>Can't do that. Others need to know who won.

I think Vishu is right.  If this router has sent an Assert already, then
it doesn't need to send it again -- it only needs to send the "I won"
Assert message if it hasn't sent an Assert recently.

i.e.
1. A sends Assert saying [1,20]
2. B sends Assert saying [1,15]
3. A receives B's Assert and shuts up
4. B receives A's Assert and decides that it has won.  B sends another   
Assert
  saying [1,15].
What is the value of the 2nd Assert message from B?

[vishwas]

It will again be [1,15], which is un-necessary to send
 -vishu

---

From: vishwas <[email-masked]>
Date: Thu, 12 Nov 98 14:31:00 PST

In message <[email-masked]>you write:
>I thought any way it is going to be discarded, so why send it at all..!!

The case where it needs to be sent is:
1. A forwards multicast packet Pa on lan L
2. B receives Pa from lan L, which is in its outgoing interface list.
3. B sends Assert with metrics [1,20] for the (S,G) in Pa.
4. A receives B's Assert, compares with its metrics [1,15] and knows that   
it
   is the winner.

Note that since B didn't forward any packets yet (e.g. due to
propogation delay), A didn't sends out its own Assert message, so
C and D (downstream routers) don't know that A won the Assert (and
B doesn't either, come to think of it).

The "don't send Asserts if you've already sent one" can probably
be considered to be part of the Assert rate-limiting described
elsewhere, although the step in the spec might get reworded to
something like "send an Assert if doing so does not violate the
rate limit" just to remind the implementor.

  Bill

[vishwas]

I was talking of the opposite scenario, As I allready mailed, with a   
figure.
1) B sends [1,15]
2) A sends [1,20] and prunes its interface
3) B sends again [1,15] telling he is the winner, which is un-necessary.

 -vishu

---

From: vishwas <[email-masked]>
Date: Tue, 17 Nov 98 16:37:00 PST

I think we are talking of Asserts not Prunes. Bill said, Assert winner   
will send (N-1) Asserts. But it was recently replyed by one of the   
authors as, it SHOULD send another prune, as per the draft. This means   
(N+1) Asserts will be sent by the Assert Winner.
Bill, the auther did not reply for ur mail I suppose...!!
 ----- here is the cut paste-----
In message <[email-masked]>you write:
>The spec says it SHOULD send another assert.

draft-ietf-pim-v2-dm-01.txt says "The assert winder sends an assert".
I didn't see any "SHOULD".

  Bill
 -------------
 -vishu

Regards
Vishwanath S. Edavayyanamath
 --------------------------------------------------------------------------  
 ------------------------
Software Engineer, Future Software Pvt. Ltd, Chennai, India
Ph : +91-44-4330550 (335)
Private e-mail : [email-masked]

 -----Original Message-----
From: Ahmed A-G Helmy [SMTP:[email-masked]]
Sent: Tuesday, November 17, 1998 2:49 PM
To: vishwas
Cc: [email-masked]
Subject: RE: Assert on outgoing interface

> I think it is (N+1) if the assert winner were to send another asser.
>
> Ref : Recent discussion saying ">The spec says it SHOULD send another   

> assert."

hmm... why another Assert ?! I believe that a prune would do the trick,
and it is no different than the usual behavior (see my prev email).

As for the pathological case, I agree, if the winner would send this
prune immediately, there may be N+1 prunes,... however, what actually
happens is that the winner would schedule the prune of the interface
(perhaps 3 to 5 sec.s.. forgot what we say in the spec re. the value),
and shortly before the timer fires, say in the 3rd sec of the 5 secs, the   

prune (or prune-alert if u will) would be sent.
 This would make it practically very highly unlikely to run into
the pathological case, or even close to it, IMHO. !

or have I missed something ?!

Regs,
 -A

>
> Regards
> Vishwanath S. Edavayyanamath
>   
 -------------------------------------------------------------------------  
 -
>  ------------------------
> Software Engineer, Future Software Pvt. Ltd, Chennai, India
> Ph : +91-44-4330550 (335)
> Private e-mail : [email-masked]
>
>  -----Original Message-----
> From: Bill Fenner [SMTP:[email-masked]]
> Sent: Monday, November 16, 1998 9:41 PM
> To: Liming Wei
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: Assert on outgoing interface
>
> Sorry for sending multiple messages in response to one.  I just came
> back from travel and haven't restarted my brain yet.
>
> In message <[email-masked]>you write:
> >One can choose not
> >to do so if one think saving that one assert message is more
> >important than the benefit of sending it.
>
> Except it's N-1 assert messages; in a pathological case, with
> 100 routers on the LAN, the Assert winner could be sending 99
> "I-won-the-Assert" messages.
>
>   Bill
>