Subject: RE: source address in assert packet.

From: "Shekhar, Ravi" <[email-masked]>
Date: Mon, 11 Oct 1999 15:45:47 -0400

> I don't have the archive either. It should be the source address,
> because that is the "raw" information about the packets causing such
> asserts. Also in case of error, the local box may have a different
> idea of who the RP should be. Instead of changing the protocol
> actions, we would be better off keeping the source address in the
> asserts.
> 
> -Liming
> 

Thanks Liming.

I take it to mean that <*, *, RP> asserts are not allowed in this version.
Is that right?

If thats the case, then section 3.5 might need slight correction in the
following paragraph:

>   Receiving Asserts on an entry's incoming interface
>
>   If the Assert arrived on the incoming interface of an existing (S,G),
>   (*,G), or (*,*,RP) entry, the Assert is processed as follows.  If the
>   Assert message does not match the entry, exactly, it is ignored; i.e,
>   longest-match is not used in this case.
 
  It talks about "exactly" matching <*, *, RP>, which should never happen.

  Also prehaps it would be appropriate to create <*, G> entry (or may be
wait 
  till data triggers it to be created) like the preceding paragraph on 
  "receiving assert on outgoing interface" specifically states.

  Regards.

  - Ravi Shekhar.

---

From: Liming Wei <[email-masked]>
Date: Mon, 11 Oct 1999 13:28:33 -0700 (PDT)

> From: "Shekhar, Ravi" <[email-masked]>
> 

I would say "a packet can arrive on an out going interface of a
(*,*,RP) entry, and an assert needs to happen as a result".

>   "receiving assert on outgoing interface" specifically states.

Yes makes sense. The language here should be "if a longest match lookup
does not find anything, the Assert is ignored". "if a longest match
lookup finds an entry, do the following:...". Fixed.

-Liming