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

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 11 Jul 2011 08:17:31 -0700

Donald -

Sorry for the long delay in response...

As a matter of clarification, the purpose of GENAPP is to handle cases where the information to be advertised is not information relevant to the operation of IS-IS. In theory, IS-IS should not advertise this information at all - but there have been enough real world examples of cases where folks found it convenient to take advantage of the reliable flooding mechanism to send such information that we defined a means to do this while minimizing the impact on the primary operation of the protocol. This involves two key provisions:

1)The use of the GENAPP TLV to eliminate consumption of the limited TLV space

2)The use of a separate instance of the protocol to isolate the flooding of GENAPP information from information used by IS-IS itself

Section 5 of GENAPP allowed for a possible exception to the second rule - but required a standards track document as a necessary (but not sufficient) prerequisite. The current wording - which was revised during IESG review - unfortunately seems to imply that a standards track document is "sufficient" - which is not what is intended.

The current wording:

"Advertisement of GENINFO therefore MUST occur in the context of a
   non-zero instance of the IS-IS protocol as defined in
   [I-D.ietf-isis-mi] except when the use in the zero instance is
   defined in a Standards Track RFC."

The pre-IESG review wording:

"Advertisement of GENINFO therefore MUST occur in the context of a
   non-zero instance of the IS-IS protocol as defined in
   [I-D.ietf-isis-mi].  Exceptions to this policy MAY be allowed only
   when there exists a standards track RFC which defines the
   application."

The latter better captures the "necessary but not sufficient" intent.

That issue I will take up w IESG, but what is relevant here is that simply because you have a standards track RFC does not mean any use of GENAPP is justified. 

Below you say:

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

So the key issue is whether the lack of advertisement of the supported channel information represents an unacceptable omission from an implementation. If so, then it seems to me that the channel information is necessary to correct operation of TRILL and would therefore need to be part of the base specification and would not use GENAPP but use some other TLV. If not - and I interpret your response as indicating it is not the case - then this represents exactly the class of information that should NOT be advertised by IS-IS at all. I acknowledge that advertising such information may be convenient and useful, but so could advertisement of any/all OAM endpoint information - but that is not something I think IS-IS should be doing.

   Les

> -----Original Message-----
> From: Donald Eastlake [mailto:[email-masked]]
> Sent: Thursday, May 19, 2011 9:48 AM
> To: Les Ginsberg (ginsberg)
> Cc: Mike Shand (mshand); [email-masked]
> Subject: Re: [rbridge] RBridge Channel 3/3: Indicating support for
> RBridge Channel protocols
> 
> Hi Les,
> 
> On Mon, May 16, 2011 at 3:45 PM, Les Ginsberg (ginsberg)
> <[email-masked]> wrote:
> 
> > 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,
> >>
> >> On Fri, May 13, 2011 at 11:00 AM, mike shand <[email-masked]>
> >> wrote:
> >> > 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?
> >>
> >> 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.
> >
> > Can you please clarify the requirements?
> 
> 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
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  [email-masked]
> 
> >   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?
> >>
> >> Yes. It has no effect on any routing decisions.
> >>
> >> Thanks,
> >> Donald
> >> =============================
> >>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> >>  155 Beaver Street
> >>  Milford, MA 01757 USA
> >>  [email-masked]
> >>
> >> >     Mike
> >> >
> >> >
> >> > On 13/05/2011 13:34, Donald Eastlake wrote:
> >> >> 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