Subject: [rbridge] RBridge Channel 3/3: Indicating support for RBridge Channel protocols

From: Donald Eastlake <[email-masked]>
Date: Fri, 13 May 2011 08:34:15 -0400

Hi,

Currently draft-ietf-trill-rbridge-channel-00 allocates an ISIS GENAPP
ID for TRILL and specifies an APPsub-TLV with just one bit that
indicates whether the RBridge supports the Channel Facility or not. I
think it would be better to specify an APPsub-TLV with a bit per
RBridge Channel protocol to indicate support of that protocol. See
draft text fragment pasted at the bottom of this message.

Thanks,
Donald

PS: This is the third of three suggested tweaks to the RBridge Channel
draft. I'm posting them separately to make discussion easier.
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

Support for RBridge Channel protocols is indicated by the presence of
one or more Channel Protocols TRILL APPsub-TLVs in an RBridge's link
state.  The Channel Protocols TRILL APPsub-TLV has as its value one or
more byte aligned bit vectors where a one bit indicates support of a
particular RBridge Channel protocol. Each byte aligned bit vector is
formatted as follows:

| 0  1  2  3  4  5  6  7| 8  9 10 11 12 13 14 15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Bit Vector Length |     Bit Vector Offset    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  bits
+--+--+--...

Note that the bit vector length (BVL) is a seven bit unsigned integer
field and the bit vector offset (BVO) is a nine bit unsigned integer
field.  The bits in each bit vector are numbered in network order, the
high order bit of the first byte of bits being bit 0 + 8*BVO, the low
order bit of that byte being 7 + 8*BVO, the high order bit of the
second byte being 8 + 8*BVO, and so on for BVL bytes. An RBridge
Channel protocols supported bit vector MUST NOT extend beyond the end
of the value in the APPsub-TLV in which it occurs. If multiple byte
aligned bit vectors are present in one such APPsub-TLV, they are
contiguous, the BVL field for the next starting immediately after the
last byte of bits for the previous.  The one or more bit vectors
present MUST exactly fill the APPsub-TLV value.

If different bit vectors overlap in the protocol number space they
refer to and have inconsistent bit values for a protcol, support for
the protocol is assumed if any of these bit vectors has a 1 for that
protocol.

The absence of any occurrences of this APPsub-TLV in the link state
for an RBridge implies that that RBridge does not support the RBridge
Channel feature. Because RBridge Channel protocols 0 and 0xFFF are
reserved and protocol 1, the RBridge Channel error protocol, MUST be
implemented as part of the RBridge Channel feature, should bit
positions for those protocols appear in bit vectors in this
APPsub-TLV, the bits for protocols 0 and 0xFFF MUST be 0 and the bit
for protocol 1 MUST be one; however, these bits are ignored on receipt
and support for protocol 1 is always assumed if there are any
occurrences of this APPsub-TLV.  To avoid wasted space, trailing bit
vector zero bytes SHOULD be eliminated by reducing BVL and any null
bit vectors (ones with BVL equal to zero) eliminated.

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

---

From: mike shand <[email-masked]>
Date: Fri, 13 May 2011 16:00:41 +0100

Hi Donald,
     I'm trying to understand the rationale for this using GENAPP rather 
than, say, a router capability TLV. Is it the case that support for 
channels is considered to be an application as far as routing is 
concerned? i.e. all you are doing is advertising some information which 
is used by some other "application", such as OAM or BFD, as opposed to 
some information that is used by "routing" itself? I guess an important 
differentiator is to ask whether "routing" would ever make any different 
decisions on the basis of this information. From what I can see, the 
answer to that question is NO. Is that a correct assessment?

     Mike

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 13 May 2011 12:08:39 -0400

Hi Mike,

On Fri, May 13, 2011 at 11:00 AM, mike shand <[email-masked]> wrote:
> some information that is used by "routing" itself?

Right. It's just about whether you can originate or understand certain
types of data messages. The RBridge Channel messages are strictly
conformant to the specification for a TRILL Data frame. The only clue
is that the encapsulated Ethernet frame has a magic multicast
destination MAC address, which pushes it to the slow path at the
"egress" and then the Etherype indicates that it needs to be processed
as an RBridge Channel message.

> I guess an important

Yes. It has no effect on any routing decisions.

Thanks,
Donald

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 16 May 2011 12:45:12 -0700

Donald -

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Donald Eastlake
> Sent: Friday, May 13, 2011 9:09 AM
> To: Mike Shand (mshand)
> Cc: [email-masked]
> Subject: Re: [rbridge] RBridge Channel 3/3: Indicating support for
> RBridge Channel protocols
> 
> Hi Mike,
> 

I too was confused regarding the use of GENAPP as the use of the proposed GENAPP info is not discussed in the draft. I can only presume that the intended use is to have IS-IS inform some "application" running on the router that a particular Rbridge has indicated that it does/does not support a particular Data Capability. Is that the intent? If so, could you explain why this is needed i.e. what will break if an application did not have this information? 

GENAPP is intended to support the use of the reliable flooding mechanism which the IS-IS update process provides on behalf an application specific information - not simply to indicate that an application exists. This is why in Section 5 of the GENAPP draft we specify that a separate non-zero instance of IS-IS MUST be used to send GENAPP information - which does not seem to align with what you are doing here.

Can you please clarify the requirements?

   Les

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 19 May 2011 12:48:12 -0400

Hi Les,

On Mon, May 16, 2011 at 3:45 PM, Les Ginsberg (ginsberg)
<[email-masked]> wrote:

>> >    I'm trying to understand the rationale for this using GENAPP
>> > rather than, say, a router capability TLV. Is it the case that
>> > support for channels is considered to be an application as far as
>> > routing is concerned? i.e. all you are doing is advertising some
>> > information which is used by some other "application", such as
>> > OAM or BFD, as opposed to some information that is used by
>> > "routing" itself?
>>
>> Right. It's just about whether you can originate or understand
>> certain types of data messages. The RBridge Channel messages are
>> strictly conformant to the specification for a TRILL Data
>> frame. The only clue is that the encapsulated Ethernet frame has a
>> magic multicast destination MAC address, which pushes it to the
>> slow path at the "egress" and then the Ethertype indicates that it
>> needs to be processed as an RBridge Channel message.
>
> I too was confused regarding the use of GENAPP as the use of the
> proposed GENAPP info is not discussed in the draft. I can only
> presume that the intended use is to have IS-IS inform some
> "application" running on the router that a particular Rbridge has
> indicated that it does/does not support a particular Data
> Capability. Is that the intent? If so, could you explain why this is
> needed i.e. what will break if an application did not have this
> information?

I'm not sure why you are looking at the relatively feeble proposed use
of GENAPP in the currently posted draft when my message was about
replacing that with what I consider a better use case. But, in any
case, the typical result of not knowing whether some remote RBridge
supports some particular data capability, which seems to almost always
translates into some variation is data frame formatting, is that if
you send such variant formatting to it, the data is discarded or
improperly distributed.

> GENAPP is intended to support the use of the reliable flooding
> mechanism which the IS-IS update process provides on behalf of an
> application specific information - not simply to indicate that an
> application exists. This is why in Section 5 of the GENAPP draft we
> specify that a separate non-zero instance of IS-IS MUST be used to
> send GENAPP information - which does not seem to align with what you
> are doing here.
>

I always thought that an RBridge would want to advertise a variety of
additional information to other RBridges in the campus, information
that has no effect on topology or routing or the like. While it is not
possible to predict all such requirements in advance, perhaps a couple
of examples will help.

- RBridge Channel protocol support. That's what the
  draft-ietf-trill-rbridge-channel change is about. Nothing that
  terrible happens if you send an RBridge channel data message to an
  RBridge that does not support the RBridge channel protocol you are
  using. There is even an error message that can be sent back,
  assuming the destination RBridge supports the general RBridge
  channel facility but not the particular RBridge channel protocol you
  are trying to use. However, in the absence of some mechanism, you
  would have no way of knowing if it did support the general RBridge
  channel facility and, if it didn't, your RBridge channel message
  might get decapsulated and spewed out some of the output ports of
  the destination RBridge. Even if we assume that you did know which
  RBridges supported the general RBridge channel facility, and, as is
  anticipated, there were just a handful of specific RBridge channel
  protocols in use, it would take O(N**2) messages for each RBridge to
  query every other RBridge about which it supported. (It is patterned
  somewhat after the MPLS Generic Channel, only a handful of which
  have been allocated.) This seems like a fine task to be handled by
  flooding a small bit map.

- VLAN/priority mapping info. That's what
  draft-ietf-trill-rbridge-vlan-mapping is about. The desire is to be
  able to cross check the mappings at various border RBridges between
  regions of an RBridge campus for consistency. As stated in the
  Security Considerations section of that draft, such mapping has no
  effect at all on the sequence of RBridges through which a TRILL Data
  frame would pass, i.e., no effect on routing.

The above could be handled in various ways, through a TLV or sub-TLVs
or whatever. But they seem to fit with all the restrictions on
GENAPP. They have no effect on adjacencies or routing or the like. Of
course, these things are always a bit grey. Even if it fit the
restrictions of GENAPP, if something was one bit and could be called a
router capability, it would probably be better to try to find a
reserved bit you could define in an appropriate existing router
capability or the lik. But if it is a number of bytes, but relatively
slow changing and not too big and TRILL specific, I'm sure why GENAPP
is such a bad idea.

draft-ietf-isis-genapp-04, in Section 5, requires use in a separate
instance for GENAPP TLVs "except when the use in the zero instance is
defined in a Standards Track RFC". Draft-ietf-trill-rbridge-channel
being targeted at standards track, I don't quite see what the problem
is. If a particular type of TRILL APPsub-TLV was big enough, or
something, then it would be reasonable to require TRILL GENAPP TLVs
with it be in a separate instance. But I can't see why it would be
worth requiring a separate instance for something small and slow
changing.

Would you prefer that the RBridge Channel protocols supported
information be in a Router Capabilities sub-TLV?

Thanks,
Donald

>   Les
>
>>
>> > I guess an important differentiator is to ask whether "routing"
>> > would ever make any different decisions on the basis of this
>> > information. From what I can see, the answer to that question is
>> > NO. Is that a correct assessment?
>>