Subject: [trill] Network connectivity and AF status

From: Olen Stokes <[email-masked]>
Date: Wed, 23 Jan 2013 08:25:13 -0800

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

2)      Set the "end-station service disable (trunk port)" bit in RB2

3)      Set the "P2P" bit in RB2

4)      Send a null set of Announcing VLANs

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?

Cheers,
Olen

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 23 Jan 2013 13:38:16 -0500

Hi Olen,

On Wed, Jan 23, 2013 at 11:25 AM, Olen Stokes
<[email-masked]> 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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> Cheers,
>
> Olen
>
>
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill
>

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 23 Jan 2013 17:40:58 -0500

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

---

From: Olen Stokes <[email-masked]>
Date: Wed, 23 Jan 2013 14:49:59 -0800

Agreed.  I was looking for something that could be signaled proactively by the RBridge that detects the loss of connectivity.

Thanks for the both the initial reply and this follow-up message.

Cheers,
Olen

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2013 5:41 PM
To: Olen Stokes
Cc: [email-masked]
Subject: Re: [trill] Network connectivity and AF status

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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA  [email-masked]

On Wed, Jan 23, 2013 at 1:38 PM, Donald Eastlake <[email-masked]> 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.
>>
>> 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
>> 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.
>
>  155 Beaver Street, Milford, MA 01757 USA  [email-masked]
>
>> Cheers,
>>
>> Olen
>>
>>