Subject: RE: [pim] question on pim assert

From: "Ju, Yu" <[email-masked]>
Date: Tue, 26 Mar 2002 18:17:23 -0500

Mark,

I am getting clearer what I am confused at. However, I am wondering wether
the following idea will simply the assert and keep the protocol behaviour.

1) The (S,G) assert state machine will NOT response to a (*,G) assert(RPTbit
set) with souce S.
   As a result, an upstream router will continue to forward data from S for
G if it has (S,G) forwarding state. A downstread router keeps its view in
terms of who is its (S,G) upstream router.
   This means (S,G) assert in NoInfo state will not transit to W state when
receiving assert with RPTBit set and CouldAssert(S,G,I) as it does now in
the table on page 78.

2) For (S,G) assert (RPTbit clear), (S,G) assert state machine transits
according to the table on page 78.

3) The (*,G) assert state machine will NOT response to a (S,G) assert(RPTbit
clear).
   For (*,G) assert state machine, my_assert_metric(*,G,I) is defined as the
rpt_assert_metric(G,I) if CouldAssert(*,G,I) is ture and
infinite_assert_metric otherwise.

4) The (*,G) assert machine will always response to a (*,G) assert(RPTbit
set) according to the table on page 87.

5) A pim router, upon receiving data from S for G, will do the forwarding
according to the current rules. 
   
   Plese point out if there is any major problem.

Yu

> -----Original Message-----
> From: Mark Handley [mailto:[email-masked]]
> Sent: Tuesday, March 26, 2002 3:05 PM
> To: [email-masked]
> Cc: 'Ju, Yu'; 'John Zwiebel'; [email-masked]
> Subject: Re: [pim] question on pim assert 
> 
> 
> 
> >Well in the last I must say that at least the assert portion 
> of the draft
> >could have been written in more simpler way!!
> 
> If you have suggestions, and they don't change the protocol behaviour,
> we'd be happy to hear them.  
> 
> I believe the current Assert section is not hard to implement
> correctly, but unfortunately it is hard to understand the rationale
> behind what's there.  In part this is because we didn't manage to
> preserve all the rationale from our discussions, and in part it's
> because we concentrated primarily on producing a spec that is correct
> and possible to correctly implement from or verify against.  Our ToDo
> notes perpetually say "add more rationale for Asserts" :-)
> 
> Mostly though it's because we failed to find a good simple way of
> expressing all the possible Assert interactions. The macros are
> complex because the interactions are complex.  We really tried hard to
> come up with simple rules.  The simple rules just don't work.
> Unfortunately as the macros are complex, it's hard to read them and
> intuit what's going on.  
> 
> The problem is that when we try to provide high-level intuition about
> this part of the spec, we always end up glossing over cases that
> matter for correctness.  
> 
> So suggestions, and especially contributions of explanatory text would
> be most welcome.
> 
> Cheers,	
> 	Mark
> 
> 
> 
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> http://catarina.usc.edu/mailman/listinfo/pim
> 
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim