Subject: Re: [rbridge] Adopt draft-perlman-trill-rbridge-af-00.txt as a WG draft?

From: Erik Nordmark <[email-masked]>
Date: Thu, 07 Apr 2011 11:51:06 -0700

I haven't seen any objections so let's make this a WG draft.

I'd recommend that folks read it so we can determine whether this is 
good enough quality to issue a WG last call.

Thanks,
     Erik

On 3/29/11 4:39 AM, Erik Nordmark wrote:
>
> This draft was just submitted with clarifications for the appointed
> forwarder mechanism in draft-ietf-trill-rbridge-protocol.
>
> Are there an objections in making this a working group draft?
>
> Erik
>
> -------- Original Message --------
> Subject: I-D Action:draft-perlman-trill-rbridge-af-00.txt
> Date: Tue, 29 Mar 2011 03:15:01 -0700
> From: [email-masked]
> Reply-To: [email-masked]
> To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> Title : RBridges: Appointed Forwarders
> Author(s) : R. Perlman, et al.
> Filename : draft-perlman-trill-rbridge-af-00.txt
> Pages : 17
> Date : 2011-03-29
>
> The IETF TRILL protocol provides optimal pair-wise data forwarding
> without configuration, safe forwarding even during periods of
> temporary loops, and support for multipathing of both unicast and
> multicast traffic. TRILL accomplishes this by using IS-IS link state
> routing and by encapsulating traffic using a header that includes a
> hop count. Devices that implement TRILL are called RBridges.
>
> TRILL supports multi-access LAN links that can have multiple end
> stations and RBridges attached. Where multiple RBridges are attached
> to a link, native traffic to and from end stations on that link is
> handled by a subset of those RBridges called Appointed Forwarders,
> with the intent that native traffic in each VLAN be handled by at
> most one RBridge. The purpose of this document is to improve the
> documentation of the Appointed Forwarder mechanism.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-perlman-trill-rbridge-af-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: mike shand <[email-masked]>
Date: Fri, 08 Apr 2011 12:17:05 +0100

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?

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?

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.)

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). 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. 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?

     Mike

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 10 Apr 2011 19:45:44 -0400

Hi Mike,

On Fri, Apr 8, 2011 at 7:17 AM, mike shand <[email-masked]> wrote:
> 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.

> 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.

> 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. 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).

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd  +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: mike shand <[email-masked]>
Date: Mon, 11 Apr 2011 10:50:48 +0100

On 11/04/2011 00:45, Donald Eastlake wrote:
> Hi Mike,
>
> On Fri, Apr 8, 2011 at 7:17 AM, mike shand<[email-masked]>  wrote:
Yes, that is as I thought. As you suggest it may be clearer to state 
that hellos received from the wrong tuple are ignored.
> 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.

> 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
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