Alex,
Based on your previous response on this specific question, and
- especially - in combination with the additional clarification you've
provided below, I am satisfied that the question I had about receiving
a non-preferred BSM from the elected (or pending) BSR is a non-issue.
Thanks!
--
Eric Gray
Principal Engineer
Ericsson
> -----Original Message-----
> From: Alexander Gall [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 15, 2007 6:58 AM
> To: Eric Gray (LO/EUS)
> Cc: Stig Venaas; James Lingard; [EMAIL PROTECTED]; Bill
> Fenner; [email protected]
> Subject: RE: Gen-ART LC Review of draft-ietf-pim-sm-bsr-10.txt
> Importance: High
>
> [ Changed Nidhi's address ]
>
> Eric,
>
> On Wed, 14 Mar 2007 11:27:47 -0500, "Eric Gray \(LO/EUS\)"
> <[EMAIL PROTECTED]> said:
>
> > Thanks, I missed that. But, now that I see how it is meant
> > (in what context), I wonder that the same action is not expected
> > if a C-PSR receives a Non-Preferred BSM from a P-BSR. Or is it
> > the case that the P-BSR state is so temporary that a C-BSR would
> > treat a likely P-BSR as if it is already the elected BSR?
>
> The event can only occur in C-BSR state, because that is the only
> state in which the router considers a different router to be the
> elected BSR. When in P-BSR state, it considers itself to be the BSR
> with highest weight but only originates a BSM when it transitions to
> the E-BSR state. When a BSM is received, the local router knows that
> the originating router considered itself to be the elected BSR.
>
> > When I read the event, I was not clear on the context - i.e.
> > - "non-preferred" with respect to what? If the "non-preferred" is
> > with respect to the local C-BSR, then I think it should also be an
>
> Yes, for this event, "non-preferred" is with respect to the local
> C-BSR (this is explained in section 3.1.4).
>
> > argument that the same transistion (C-BSR -> P-BSR) should apply
> > in receiving a non-preferred BSM from a current P-BSR.
>
> There is no notion of a "current P-BSR" (see above), but I know what
> you mean (the router receives a BSM from a router that is not the
> currently elected BSR, which can happen, of course). In that case,
> the weight is compared with that of the elected BSR, not the one of
> the local C-BSR, which is lower than the latter by definition.
>
> If the weight is lower, the new BSM is considered to be non-preferred
> and is ignored. This event is omitted from the state table because it
> triggers no action.
>
> If the weight is higher, the originator of this BSM becomes the
> elected BSR.
>
> In both cases, the local router remains in the C-BSR state.
>
> > This is pretty murky, since we appear to be trying to guess
> > the transition that should be occuring in a peer. Does the elected
> > BSR that sent the non-preferred BSM know that it is no-longer the
> > elected BSR, or is that transition assumed to take place when it
> > receives a reciprocal (assumed symmetric) preferred BSM from the
> > local BSR?
>
> I don't think any assumptions are necessary. At any point in time,
> there is a strict ordering within the set of candidate BSRs according
> to their weight. The state machine must guarantee that the router
> with highest weight eventually starts flooding its BSMs, which will
> cause all other routers to enter C-BSR state and stay there.
>
> In this particular case, when the priority of the elected BSR is
> lowered in such a manner that a different C-BSR now has higher weight,
> that router will start flooding BSMs. These BSMs will be considered
> to be preferred by the former elected BSR which will then transition
> to C-BSR and stop sending BSMs.
>
> If you find a scenario, in which the C-BSR with highest weight remains
> in the C-BSR state indefinitely, that would be a problem.
>
> > Would the same apply if that BSR were still in the
> > temporary P-BSR state?
>
> > Possibly these things are clear to people who've followed the
> > discussion-history, but the answers to these questions don't jump
> > out at me...
>
> Essentially, we convinced ourselves (and the WG), that the state
> machine does indeed cover all cases, although not in a formal manner.
>
> This has not been the subject of discussion for a long time. There
> also exist various implementations of this specification which did not
> reveal any problems so far.
>
> I hope my explanations above helped to make things clearer.
>
> --
> Alex
>
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
