[rbridge] FW: Proposed replacement for a paragraph in section 2.3 ofdraft-ietf-trill-rbridge-protocol-07

[Anoop Ghanwani]

(Resent message.)

I have a few clarifications about this proposal.
See below. 

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Claudio DeSanti
> Sent: Monday, March 10, 2008 7:19 AM
> To: Rbridge at postel.org
> Subject: [rbridge] Proposed replacement for a paragraph in 
> section 2.3 ofdraft-ietf-trill-rbridge-protocol-07
> 
> Hi all,
> 
> as just presented, this is a proposed clarification for an 
> existing paragraph in section 2.3 of the base protocol spec.
> Thanks,
> 
>               Claudio.
> 
> -------
> 
> 
> Existing paragraph:
> 
>    By default, RBridges tag IS-IS Hellos with VLAN 1. However, an
>    RBridge MAY be configured to transmit Hellos on a set of VLANs, and
>    if elected DRB, to designate to the other RBridges on the 
> link which
>    VLAN to tag Hellos with. Once the DRB, say RB1, is elected, and
>    specifies the designated VLAN, say VLAN-x, on which to send Hellos,
>    (1) all RBridges on the link, except the DRB, transmit 
> Hellos tagged
>    only with VLAN-x, (2) all RBridge-RBridge communication (including
>    Hellos, forwarded data packets, and LSPs) are tagged with 
> VLAN-x, and
>    (3) the DRB only lists, in its Hello, and in the 
> pseudonode LSP, the
>    set of RBridges from which the DRB hears VLAN-V tagged packets.
> 
> 
> Proposed replacement:
> 
> 
> An RBridge maintains per each port the following parameters:
> a) Announcing VLANs set: the set of VLANs where an RBridge 
> port announces IS-IS Hellos on a link;
> b) Designated VLAN: the VLAN used by an RBridge port to 
> communicate with other RBridge ports on a link; and
> c) Forwarding VLANs set: the set of VLANs for which an 
> RBridge port is appointed VLAN forwarder on a link.
> 
> By default the Announcing VLANs set contains all the VLANs 
> active on the port, however it may be configured to contain a 
> subset of them.

What is the set of active VLANs?  If Ingress VLAN 
filtering is not enabled is this all the 4094 VLANs?

> When a port of an RBridge becomes operational, the RBridge 
> MUST transmit IS-IS Hellos on each VLAN of the Announcing 
> VLANs set of that port.

Because of the above 4094 number, I would be opposed
to having this as a MUST.  In addition, it should be
clearly specified that the purpose of these hellos is
only for connectivity/misconfiguration detection.
In other words, there is no IS-IS adjacency established,
and it should be possible to operate with just a single
VLAN hello if one chooses to not use this mechanism
for connectivity/misconfiguration detection.
 
> If the RBridge is elected DRB for the link to which that port 
> is connected, the RBridge MUST:
> a) continue to send IS-IS Hellos per each VLAN of the 
> Announcing VLANs set of that port;
> b) designate the Designated VLAN to be used to communicate 
> with the other RBridges connected to that link; and
> c) establish the Forwarding VLANs set per each RBridge 
> connected to that link, including itself.
> 
> If the RBridge is not elected DRB for the link to which that 
> port is connected and its Forwarding VLANs set is not empty, 
> the RBridge MUST:
> a) learn from the DRB the Designated VLAN on that link;
> b) act as a VLAN forwarder for the VLANs included in its 
> Forwarding VLANs set; and
> c) transmit IS-IS Hellos messages only on the Designated VLAN 
> and on the VLANs of its Forwarding VLANs set.
> 
> If the RBridge is not elected DRB for the link to which that 
> port is connected and its Forwarding VLANS set is empty, the 
> RBridge MUST:
> a) learn from the DRB the Designated VLAN on that link; and
> b) transmit IS-IS Hellos messages only on the Designated VLAN.

BTW, in the meeting Silvano had mentioned that it is
never possible to configure an 802.1 network such that
spanning tree will not take care of loops.  This is 
incorrect.  In cases where the PVIDs are different on
both ends of the link, it is actually possible to have
a persistent loop when using MSTP.

In 802.1ah (provider backbone bridging) they also have
the same problem of loops that we have here.  They
solve that problem using an enhancement to STP, called
the Layer 2 gateway protocol, but it doesn't look like
it's well enough defined in the text.  I would have
to look at the STP state machines to understand its
operation.

The point is, we need to be reasonable about the
overhead imposed for detecting connectivity problems
and misconfiguration.

Anoop