Re: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt

In support of Mike's comments, I would also suggest we look at this in
the context of the recent agreement that draft-ward-l2isis be the home
for all L2 IS-IS extensions. We therefore want to minimize the overlap
between the architecture document and draft-ward-l2isis so as to avoid
even the appearance of diverging specifications.

It may make sense for the architecture document to discuss the required
functionality at a high level, but currently there is considerable text
which specifies the procedural extensions of an L2-IS-IS instance - and
that clearly is the province of draft-ward-l2isis.

So in addition to working out the technical issues on points Mike
describes below, the architecture document needs to be revised in such a
way as to not duplicate or be in conflict with the protocol extensions
draft as it develops.

   Les

> -----Original Message-----
> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org]
On
> Behalf Of Mike Shand (mshand)
> Sent: Wednesday, November 26, 2008 10:18 AM
> To: Erik Nordmark
> Cc: rbridge@postel.org
> Subject: Re: [rbridge] WG last call on
draft-trill-rbridge-protocol-10.txt
> 
> I have reviewed the draft from the viewpoint of IS-IS, and I have the
> following comments. In view of the dependency on IS-IS protocol
encoding
> AND protocol operation changes, I believe it is important that we get
> agreement with the IS-IS WG on those aspects that affect the operation
> of the IS-IS protocol before this draft is set in stone.
> 
> The points where I believe some discussion between the working groups
is
> required include, but may not be limited to, the items I have
enumerated
> below.
> 
> 1. The problem of IIH space limitations (typically a maximum of < 1500
> octets) and potential number of VLAN tags (4.2.3.1.1) is not
discussed.
> Even if some range based compression is used there is the possibility
of
> pathological distributions of VLAN ids (e.g. just the odd ones)
causing
> problems. There needs to be some guidance on what limitations this may
> impose etc.
> 
> 2. The number of IIHs required to be sent when large numbers of VLANs
> are in use (4.2.3.1.1) is of some concern. Again there needs to be
some
> discussion of what impact this may have in terms of limiting the
> scaleability of the protocol, and whether such limitations are
acceptable.
> 
> 3. The loop avoidance mechanisms described in 4.2.3.3 needs to be
> verified by the IS-IS WG. In addition the last bullet needs some
further
> explanation as to what aspect "already provided in IS-IS" is being
> referenced.  IS-IS will normally only elect a single DIS in such
> circumstances, but there is no provision for disabling forwarding as
is
> implied here.
> 
> 4. The VLAN mapping detection (4.2.3.1.3) needs to be verified by
IS-IS
> WG. In particular the mechanism of setting the  mapping detected bit
in
> the next 5 hellos seems dangerous, since such messages could be lost
in
> the looping which would ensue when mapping was configured. This should
> either be latched until reset, or at the very least latched until it
is
> detected that it has been actioned by the DRB.
> 
> 5. It is not clear how the existing VLAN mapping detection will
> interoperate with the proposed VLAN mapping extensions discussed in
> Minneapolis.
> 
> 6. Section 4.2.1 states that a pseudonode is assigned a 7-octet ID
> USUALLY by appending another octet to the 6 octet system ID owned by
the
> DRB. This suggests that the possibility of some other way is intended.
> If so this needs to be described.
> 
> 7. The second para of 4.2.4.1 (ESADI participation) needs some
rational
> for the sending of CSNPs by the non-DRB.
> 
> 8. Section 4.4.2.1 (TRILL IS-IS frames) states "If the frame protocol
is
> not IS-IS NSAP..." What does this mean?
> 
> 
> Mike
> 
> 
> Erik Nordmark wrote:
> > This message begins a working group last call on
> > draft-ietf-trill-rbridge-protocol-10.txt. Because of the size of the
> > document, it will run for three weeks until Wednesday, November
26th.
> >
> > There are three issues in connection with this draft that you may
wish
> > to note:
> >    1. A method of doing VLAN mapping was discussed on the working
> > group mailing list. This protocol draft is compatible with that
method
> > which has been written up in
> > draft-perlman-trill-rbridge-vlan-mapping-00. This separate draft
could
> > be considered for adoption as a working group draft and be
progressed
> > separately or it could be considered as material to add to the
> > protocol draft, perhaps as an appendix.
> >    2. The protocol draft does incorporate a change in the
> > encapsulation of TRILL IS-IS frames (they are no longer encapsulated
> > but are always sent to a different multicast address) and a minor
> > change in the encapsulation of TRILL ESADI frames (they have a
> > different new inner multicast address). There was discussion of this
> > on the mailing list but sufficiently little that it was hard to
gauge
> > working group opinion.
> >    3. There was discussion on the mailing list of alternatives for
> > distribution tree root selection and announcement but no changes
along
> > these lines were made in the draft.
> >
> > At least items 1 and 3 above are expected to be discussed at the
> > working group meeting in Minneapolis. Should those discussions
result in
> > any changes to the base draft then we will separately last call
those
> > changes.
> >
> > Erik and Donald
> > _______________________________________________
> > rbridge mailing list
> > rbridge@postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> >
> 
> _______________________________________________
> rbridge mailing list
> rbridge@postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge