Re: [rbridge] [Isis-wg] Questions about draft-ietf-trill-rbridge-af-00.txt

[mike shand <[e-mail]>]

On 11/04/2011 00:45, Donald Eastlake wrote:
> Hi Mike,
>
> On Fri, Apr 8, 2011 at 7:17 AM, mike shand<[e-mail]>  wrote:
>> I have a few questions about the AF draft, which are probably the result
>> of my lack of understanding, but perhaps some clarification is required.
>>
>> 2.2.1 Processing Forwarder Appointments
>>
>> "When a non-DRB RBridge that can offer end station service on a link
>> receives a TRILL Hello from the DRB on the Designated VLAN sent from
>> the port that won the DRB election, that RBridge examines the Hello
>> for Appointed Forwarder sub-TLVs."
>>
>> Does this imply a requirement to check that the TRILL hello was indeed sent
>> from the port that won the DRB election. i.e. if the source MAC address of
>> the hello is wrong the hello is NOT examined for AF sub-TLVs?
> Actually, you need to check the MAC Source Address, Port ID, and
> System ID triplet to be sure to do the right thing in corner cases and
> perhaps that should be clarified. I think Intermediate Systems need to
> look at the MAC Source Address anyway, when processing Hellos, for
> adjacency purposes.
>
> I would imagine every Hello received (unless it is discarded for one
> of the resons provided in the adjacency draft) is examined and parsed
> for known TLVs/sub-TLVs. If it is not from the port that is in charge
> of the link, any AF sub-TLVs found would be ignored. Maybe the
> "examines" wording should be changed to "ignored" wording.
Yes, that is as I thought. As you suggest it may be clearer to state 
that hellos received from the wrong tuple are ignored.
>> 2nd para
>>
>> So, is it possible that subsequent to the sending of the hello by the DRB
>> with AF TLVs appointing a range of VLANs, a VLAN in that range which was not
>> previously enabled, becomes enabled on the local system? In that case is the
>> RBridge required to enable itself as AF for that VLAN on the basis of that
>> previously sent hello? i.e. is it required to store the VLAN range?
> No, it is not intended to have to store anything about the AF sub-TLVs
> as such. They are processed when received, which may or may not change
> the receiving RBridges Appointed Forwarder status for various VLANs.
>
>> Or does it have to wait until the next AF advertisement from the
>> DRB? (since these are recommended, but not required, to be sent
>> every holding time.)
> It has to wait, but I'm not sure exactly what the scenario here is. If
> the network manager wants RBx to be AF for VLAN-y which was previously
> disabled, you would think that right after it cause VLAN-y to be
> enabled at RBx it would cause the DRB to send appointments. And if the
> DRB wants some RBridge to be AF for VLAN-x and the DRB is not getting
> Hellos on VLAN-x from the RBridge saying it is acting as AF, it knows
> there is a problem of some sort, and could send the appointments more
> often. In common cases, with a hand full of forwarders and RBridges on
> a link, it would not be a problem for the DRB to send the appointments
> in every TRILL Hello if it wants to.

Yes, its clear that the DRB can eventually sort things out. My question 
was more along the lines of whether there was an expected requirement to 
keep the AF state as sent by the DRB. That was one possible, though 
admittedly obscure,  reading of the text. I'm generally not in favour of 
stating what NOT to do (e.g. don't store the information), since there 
are an infinite number of things you could specify not to do, and 
singling out particular ones can be confusing. So perhaps we can just 
leave this as it stands, given that the natural reading is indeed the 
desired operation.

>> 3. The inhibition mechanism
>>
>> So let me see if I understand this (which I admit I may well not). When a
>> port is turned on, that RBridge instantly becomes DRB for that link
>> (according to my understanding of trill-adj), and therefore does things like
>> generating a pseudonode if required, and sending CSNPs and such like until
>> such time as it receives a hello from someone else which has a better claim
>> to be DRB (which may be very soon).
> Normally, it would not generate a pseudonode but rather assert
> bypass-pseudonode in its Hellos until it has at least two adjacencies
> in the Report state.
Ah yes. I'd forgotten that would cause pseudonodes to be inhibited for 
lone DRBs.
>   And I don't think it would normally get around to
> sending a CSNP before the DRB election was straightened out.
>
>> However, it doesn't make itself AF for
>> any VLANs on that link because it has set its DRB inhibition timer to its
>> own holding time on that port.
> Actually, it makes itself AF for whatever VLANs it wants but is an
> inhibited AF. The different is that, in its Hellos on those VLANs, it
> asserts that it is AF.
>
>> That appears to be safe, but it seems odd
>> that it should still have to go through the motions of performing normal
>> IS-IS DIS actions, only to have to withdraw them a few seconds later.
>>
>> Also, what about the case where the local holding time is set very short WRT
>> to the hello transmission timers of the other RBridges on the LAN? I assume
>> it operates the usual holding time = 3* the hello time, so this is very
>> unlikely, but presumably faulty configuration could cause this. Wouldn't
>> this temporary allow multiple AFs?
> Multiple AFs do not actually cause a loop unless more than one of them
> is un-inhibited and native frames can get from one uninhibited AF to
> another. If RB1 comes up and starts sending Hellos once a second it is
> always possible, due to misconfigurations such a VLAN-diodes or the
> like, that it doesn't get Hellos from other RBridges. So it would
> continue to think it is DRB and eventually become an un-inhibited AF
> for various VLANs; but its Hellos will be inhibiting any other
> RBridges that think they are AF for the same VLAN(s).
Ah yes, I hadn't grasped that an inhibited AF still claimed to be an AF 
in its hellos (hence inhibiting others, as you point out). I now see 
that this is clearly specified in section 4 para 4, so that was down to 
me not reading carefully enough.

Thanks.

     Mike

> Thanks,
> Donald
> =============================
>   Donald E. Eastlake 3rd  [phone] (cell)
>   155 Beaver Street
>   Milford, MA 01757 USA
>   [e-mail]
>
>>    Mike
_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge