Re: [trill] Network connectivity and AF status

[Donald Eastlake <[e-mail]>]

An additional thought and a correction:

The correction is that reference below to section 4.2.5 of RFC 6325
should be to Section 4.2.4.

The thought is that RFC 6325 deliberately puts the criterion the DRB
uses to decide who to appoint a forwarder as out of scope to give
different implementers freedom to come up with different strategies.
But one reasonable factor to use is such decisions is the connectivity
to the campus of the TRILL switch being considered for appointment.
RB1 will learn from former neighbors of RB2 that they are no longer
connected to RB2 and it would be reasonable for RB1 to use that as the
basis for revoking any forwarder appointments of RB2.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]


On Wed, Jan 23, 2013 at 1:38 PM, Donald Eastlake <[e-mail]> wrote:
> Hi Olen,
>
> On Wed, Jan 23, 2013 at 11:25 AM, Olen Stokes
> <[e-mail]> wrote:
>> Take a simple network where RB1 and RB2 are connected to a TRILL network and
>> also connected together over an access link (bridged network).  Assume that
>> RB1 is DRB on the access link.  Assume that RB1 is the AF for half of the
>> access VLANs and that RB2 is the AF for the other half of the access VLANs.
>>
>> One scenario of interest is to assume that RB1 loses all of its connectivity
>> to the TRILL network (all of its trunk ports go down).  RB1 can simply give
>> RB2 AF status for all of the VLANs and access traffic can all go through RB2
>> to use the TRILL network.
>>
>> A second scenario of interest is to assume that RB2 loses all of its
>> connectivity to the TRILL network.  In this case, RB2 would like for RB1 to
>> become AF for all of the VLANs.  The question becomes, how does RB2 signal
>> to DRB RB1 to revoke AF from RB2 for all of its AF VLANs?   The following
>> methods come to mind:
>>
>> 1)      Set the “disable port” bit in RB2’s Hellos to RB1
>
> I believe there actually isn't such a bit in Hellos. (It would be in
> the Special VLANs and Flags sub-TLV.) The disable bit is a
> configuration bit associated with a TRILL switch port. As shown in
> Section 6 of draft-ietf-trill-clear-correct-06.txt, turning on the
> disable bit will stop any Hellos from being sent. RB1 will conclude
> that RB2 is down and presumably start handling all native traffic
> itself. Lack of Hellos is a bit slow, but if RB1 wants to find out
> more quickly when RB2 goes down, if should be using BFD
> (draft-ietf-trill-rbridge-bfd-07.txt) or the like.
>
>> 2)      Set the “end-station service disable (trunk port)” bit in RB2
>
> That seem like a good way to me. It will notify RB1 more rapidly. It
> takes, typically, three Hellos times to decide the other end has died
> while the "end-station service disable" bit could be noticed in the
> very next Hello. RB1 would be specifically prohibited from appointing
> RB2 as an Appointed Forwarder by the text about this configuration bit
> on page 72 of RFC 6325,
>
>> 3)      Set the “P2P” bit in RB2
>
> That is also a bit not in the Hello. It would cause RB2 to start
> sending IS-IS P2P Hellos. RB1 should ignore these Hellos (unless it is
> also configured for P2P, which is inconsistent with the situation as
> described) as provided in Section 4.2.5 of RFC 6325. So, logically,
> this is the same as 1. RB1 stops seeing any Hellos that it can accept
> from RB2 and the adjacency falls away.
>
>> 4)      Send a null set of Announcing VLANs
>
> Well, you could use the Enabled VLANs sub-TLV to announce a null set
> of VLANs enabled for end-station service.
>
> The Announcing VLANs set is an internal configuration at a TRILL
> switch port. It is used to optionally reduce the number of Hellos that
> TRILL sends on a port.
>
>> Setting the “disable port” bit seems to be the most appropriate.  However, I
>> cannot find where this is discussed in RFC 6325 or RFC 6439.  Have I missed
>> it someplace?  Is there another more appropriate method to accomplish this?
>
> See discussion above.
>
> By the way, the draft-ietf-trill-clear-correct-06.txt,
> draft-ietf-trill-rbridge-bfd-07.txt, and
> draft-ietf-trill-rbridge-channel-08.txt drafts are all fully approved
> and in the RFC Editor's queue. They are just as binding as published
> RFCs.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
>
>> Cheers,
>>
>> Olen
>>
>>
>> _______________________________________________
>> trill mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trill
>>