Re: [Isis-wg] draft-ietf-isis-trill-01: Adjacency State Machinery

["Les Ginsberg (ginsberg)" <[e-mail]>]

Donald -

Thanx for the reply.
Inline.

> -----Original Message-----
> From: Donald Eastlake [mailto:[e-mail]]
> Sent: Saturday, August 28, 2010 4:40 PM
> To: Les Ginsberg (ginsberg)
> Cc: isis mailing list; Erik Nordmark; Ralph Droms
> Subject: Re: [Isis-wg] draft-ietf-isis-trill-01: Adjacency State
> Machinery
> 
> Hi Les,
> 
> On Wed, Aug 25, 2010 at 6:05 PM, Les Ginsberg (ginsberg)
> <[e-mail]> wrote:
> 
> > One of the major changes to the IS-IS protocol which is introduced by
> > TRILL is a change in the adjacency state machine. Because of the need
> to
> > advertise a potentially large amount of VLAN information in IIHs, it
> is
> > recognized that it may not always be possible to send a complete set
> of
> > TRILL neighbors (replacement for IS-neighbors) in a given IIH. There
> are
> > also interactions w the new MTU testing PDUs. All of this affects the
> > way adjacencies are brought up and maintained - but the details of
> the
> > revised state machine are not specified. For example, how long should
> > IS-A maintain it's neighbor relationship to IS-B given that an
> > indefinite number of IIHs might be received from IS-B which do not
> > include any verification (positive or negative) that two way
> > connectivity exists between IS-A and IS-B??
> 
> The change due to fragmenting the Neighbor TLV is very minor and, as

A minimal requirement for a protocol standard is to include definition of what the externally visible behavior of an implementation MUST BE in order to comply with the standard. In regards to adjacency maintenance, ISO 10589 is very clear:

<snip>
Section 8.4.2.5.3 
If a Level n LAN IIH PDU is received from neighbour N, and this system's lANAddress is no longer in N's IIH PDU, the IS shall

a)	set the adjacency's adjacencyState to "initialising", and
b)	generate an adjacencyStateChange (Down) event.
<end snip>

Clearly this text is no longer applicable to IS-IS use in support of TRILL. What text is offered to replace the text above? What I can find from draft-ietf-trill-rbridge-protocol-16.txt is the following near the end of Section 4.4.2.1:

<snip>
To ensure that any RBridge RB2 can definitively determine whether RB1
   can hear RB2, RB1's neighbor list must eventually cover every
   possible range of IDs
<end snip>

Now, what is the meaning of "eventually"? Here are two possible meanings:

A)RB1 MUST cover every possible range of IDs at least once within the holding time advertised in its IIHs
B)RB1 MAY take longer than the advertised holding time to cover every possible range of IDs

An implementation written based on "A" would not interoperate with an implementation based on "B" under all circumstances. If RB1 uses interpretation B and under stress takes longer to cover the complete range of IDs in its hellos than the advertised holding time a neighbor implementation on RB2 based on interpretation A will flap the adjacency to RB1 in such a case. Is RB2 correct in flapping the adjacency or not? Given the text we have available it is not possible to know what the correct behavior is.

There are of course other related issues which are worthy of discussion. For example, ISO 10589 default behavior ensures that multiple IIHs which have all neighbors advertised will be sent within the holding time (once every hello interval - where holding time is a multiple of the hello interval). This prevents spurious flaps in the case that one IIH is dropped (either by the transmitter or the receiver) during peak link usage. Given that for TRILL the number of IIHs which cover the range of IDs associated with a given neighbor is reduced, what protection is there against spurious flaps in case of a single dropped IIH?

My point is that the specification as it currently exists lacks a definition of what is the correct behavior. I believe such a definition MUST BE a part of the new protocol standard.

> far as I know, implementers are not having any inordinate problems
> with this. The event of receiving a Hello in which you are not listed
> in the Neighbors TLV (ISO 10589, Section 8.4.2.5.3) is simply replaced
> by the event of receiving a Hello where the TRILL Neighbors TLV covers
> a range of MAC addresses including yours and you are not listed.
> 
> If you have an adjacency but then you continue to get Hellos from that
> Neighbor and never get one that covers a range of MAC addresses
> including you, under the present TRILL standard, the adjacency would
> stay up forever. Given that the Holding Time can be over 18 hours, I
> don't see a practical difference between an obnxious Intermediate
> System that sets an 18 hour+ Holding Time and withholds Hellos for 18
> hours (yes, I'm assuming no other events occur in the interim that
> require a Hello) and an obnoxioius RBridge that regularly sends Hellos
> but, after indicating it can hear you, fails to ever include a TRILL
> Neighbor TLV that covers your MAC address. I suppose, if people do see
> a diffeence, a 2**16 - 1 second time limit could be added.
> 
> > There is some background text in draft-ietf-trill-rbridge-protocol-16
> -
> > but this is not normative and it is difficult to derive exactly what
> an
> > implementation MUST do to be interoperable. Also, while it is logical
> > for the TRILL spec to describe the motivation for the IS-IS protocol
> > changes, the appropriate place to provide a normative description of
> the
> > protocol changes is in draft-ietf-isis-trill.
> 
> Perhaps you mean "not formal"?

My post is not meant to be provocative. I was in no way dismissing the TRILL document as not a standards track document. My comment was that the language in the TRILL document does not provide a clear definition of the required behavior (see my comments above for more detail). 

   Les

> The TRILL base protocol specification
> is an approved standards track document so I don't understand why you
> say that document is not "normative". TRILL is being implemented today
> based on the TRILL base protocol standard (and the code points and
> data structures specified in isis-layer2 and isis-trill), a successful
> TRILL control plane plug-fest has been held at UNH IOL, etc.
> 
> Of course, many parts of the TRILL base protocol specification could
> be improved in various ways.
> 
> > I think this is a necessary part of draft-ietf-isis-trill. A state
> table
> > would be preferable - but other forms could be used if the authors
> wish
> > so long as the result is unambiguous and provides a reference which
> > implementors can use to ensure interoperability and conformance.
> 
> I didn't think the IETF did conformance...
> 
> Although none of the various groups implementing TRILL has complained
> that the specification of the Hello protocol was incomplete or
> difficult to understand, we could produce a separate draft focusing
> just on the Hello protocol, or perhaps covering any other parts of
> TRILL that could benefit from more in depth or more explanatory
> verbiage
> 
> >   Les
> 
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  [e-mail]