[rbridge] [Isis-wg] trill-adj circuit scope

[Les Ginsberg (ginsberg)]

Radia -

It is very easy to demonstrate how what is currently defined can fail - all that has to happen is that a hello which is advertising some AF information is dropped by one of the RBs to whom the the AF information applies. As hello delivery is unreliable this can happen.

If your reply is that reliability can be achieved if the DRB always sends the AF information then I agree - but this solution has very poor scaling properties (and BTW is not clearly specified).

There are multiple ways reliability might be achieved with better scaling properties - I have alluded to some in an earlier post and Donald has presented some ideas below. But as the TRILL specification stands at the moment this issue is not addressed.

   Les


> -----Original Message-----
> From: isis-wg-bounces at ietf.org [mailto:isis-wg-bounces at ietf.org] On
> Behalf Of Radia Perlman
> Sent: Monday, March 07, 2011 3:44 PM
> To: Les Ginsberg (ginsberg)
> Cc: rbridge at postel.org; isis mailing list
> Subject: Re: [Isis-wg] trill-adj circuit scope
> 
> Re: Appointed forwarder mechanism.
> 
> Actually, what is there works fine.  Whether doing a link-specific
> CSNP mechanism to convey this information might be better in some way
> than what is there, given that there are already implementations, it
> might be interesting to figure out in what way it might be better, but
> to change something that works, after there are already
> implementations...either what is there would have to be broken (which
> it is not), or the proposed mechanism would have to be a lot better
> (which I'm not convinced it is.)
> 
> Radia
> 
> On Mon, Mar 7, 2011 at 7:08 AM, Les Ginsberg (ginsberg)
> <ginsberg at cisco.com> wrote:
> > Donald -
> >
> >> -----Original Message-----
> >> From: Donald Eastlake [mailto:d3e3e3 at gmail.com]
> >> Sent: Friday, March 04, 2011 6:12 AM
> >> To: Les Ginsberg (ginsberg); rbridge at postel.org
> >> Cc: isis mailing list
> >> Subject: trill-adj circuit scope
> >>
> >> > Reliable Circuit Scope Flooding
> >> > --------------------------------
> >>
> >> > [RFCTrill] defines a requirement for reliable circuit scoped
> >> > flooding of Appointed Forwarder Information (Section 4.4.2) but it
> >> > is not specified how this is to be achieved. I had hoped this
> >> > document would provide that specification.
> >>
> >> It sound like you are alluding to a link scoped flooding mechanism
> >> which I believed you also referred to in an earlier ISIS WG
> >> post. Presumably something involving some new PDUs like LLSP (link
> >> local state PDU) and LCSNP (local complete sequence number PDU),
> >> perhaps both in L1 and L2 versions and possibly with the primary
> index
> >> being the SNPA rather than the System ID. It is quite an intriging
> >> idea. Is there a draft yet? I don't recall seeing one.
> >
> > The first issue is getting consensus that this is indeed an issue
> which needs to be addressed - which thus far has not been achieved. I
> believe it does need to be addressed. Whether what you suggest below is
> a workable solution can only be evaluated if you provide normative
> language so we understand the solution. At present, RFCTrill says that
> the DRB sends AF information - but the manner in which reliability is
> achieved is unspecified.
> >
> > If you update whatever spec you feel is most appropriate for this I
> will review it.
> >
> > I understand you feel this is out of scope for the review of draft-
> ietf-trill-adj. But as AF information is sent in IIHs and the
> reliability is a new circuit-scoped requirement it seemed appropriate
> for me to mention here.
> >
> >   Les
> >
> >
> >>
> >> In any case, I don't see any need for it in connection with
> appointed
> >> forwarders. In particular I'd like to point out the following:
> >>
> >> - Whether an RBridge believes it is the appointed forwarder for a
> VLAN
> >>   is indicated in TRILL Hellos that it sends on that VLAN. Thus the
> >>   DRB normally has feedback on what other RBridges on the link think
> >>   their Appointed Forwarder status is.
> >>
> >> - An RBridge that believes it is appointed forwader for a particular
> >>   VLAN, when it receives a TRILL Hello on that VLAN from another
> >>   RBridge in which that other RBridge asserts that it is appointed
> >>   forwarder for that VLAN, is temporarily inhibited for that VLAN
> >>   only. This can result in transient loss of end station data but
> that
> >>   is preferable to a loop. (Such inhibition has no effect on TRILL
> >>   Data frames, only on native frame receipt and transmission.)
> >>
> >> - When an RBridge sees the DRB change and it does not become DRB, it
> >>   clears any fowarder appointments that RBridge thinks it has.
> >>
> >> - The spec states that appointing an RBridge appointed forwarde hss
> no
> >>   effect except for VLAN(s) that are enabled on a port that RBridge
> >>   has on the link. Since the network manager will normally have
> >>   control over VLAN enablement, this means that you can appoint an
> >>   RBridge forwarder for, say, all even numbered VLAN by only having
> >>   those VLANs enabled and then sending out a forwader appointment
> >>   appointing it for all VLAMs.
> >>
> >> > The lack of reliable flooding means that either:
> >>
> >> > a)Appointed forwarder information MUST be included by the DRB
> always
> >> > - which does not scale well
> >>
> >> Since the DRB can normally sense, from their Hellos, what other
> >> RBridges on the link think their appointed forwarder status is, it
> >> knows when it needs to refresh the existing appointed forwarder
> >> information or send a new set of appointed forwarder information.
> But,
> >> no doubt, it would be a good practice to send it occasionally
> >> regardless.
> >>
> >> > OR
> >>
> >> > b)Loops and/or loss of traffic for a given VLAN MAY occur
> >>
> >> The inhibition from receiving a Hello indicating an appointed
> >> forwarder conflict and other safety features should stop loops. It
> is
> >> certainly possible, with perverse configurations, to have loss of
> >> native traffic.
> >>
> >> In any case, the appointed forwarder mechanism is out of scope for
> >> draft-ietf-trill-adj.
> >>
> >> Thanks,
> >> Donald
> >> =============================
> >>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> >>  155 Beaver Street
> >>  Milford, MA 01757 USA
> >>  d3e3e3 at gmail.com
> > _______________________________________________
> > Isis-wg mailing list
> > Isis-wg at ietf.org
> > https://www.ietf.org/mailman/listinfo/isis-wg
> >
> _______________________________________________
> Isis-wg mailing list
> Isis-wg at ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg