Re: [rbridge] TRILL control frames communication

Thanks Donald!

On Thu, Apr 5, 2012 at 8:26 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:

> Hi Muhammad,
>
> On Thu, Apr 5, 2012 at 1:55 AM, Muhammad Mohsin Sardar
> <mohsin.sardar@seecs.edu.pk> wrote:
>
> > Hi!
> >
> > Given in RFC6325 section 4.2.3
> > TRILL IS-IS frames are never forwarded by an RBridge but are locally
> > processed on receipt.  (Such processing may cause the RBridge to send
> > additional TRILL IS-IS frames.)
> > Given in RFC6325 section 4.6.2
> > 1. If the Outer.MacDA is All-IS-IS-RBridges and the Ethertype is
> L2-IS-IS,
> > the frame is handled as described in Section 4.6.2.1.
> > 4.6.2.1. TRILL Control Frames: The frame is processed by the TRILL IS-IS
> > instance on RBn and is not forwarded.
> >
> > As IS-IS frames are never forwarded by an RBridge, why All-IS-IS-RBridges
> > multicast address is used? Please clarify.
>
> The All-IS-IS-RBridges multicast Ethernet address is used on Ethernet
> links to be sure that the frame reaches all the interfaces on the
> link. Keep in mind that in TRILL terms a "link" can be a bridged LAN.
> TRILL has always supported multi-access links.
>
> > As per my understanding TRILL IIH frames are sent to the neighbors,
> > bounded by RBridges ( Broadcast domain is link) Am I right?
>
> Bounded by RBridges, Layer 3 routers, and end stations.
>
> Your figure below was garbled in transmission. Trying to send wide
> ASCII art through email is not such a good idea... I've attempted to
> reconstruct it narrower below and have also added RB5.
>
> +-----+  +-------+  +-------+     +-------+  +------+  +-----+
> | ESa +--+ RB1   +--+ RB3   +--+--+ RB4   +--+ RB2  +--+ ESb |
> |     |  |ingress|  |transit|  |  |transit|  |egress|  |     |
> +-----+  +-------+  +-------+  |  +-------+  +------+  +-----+
>                               |
>                             +-+-+
>                             |RB5|
>                              +---+
>
> > If all RBridges are just up, following pattern will be followed:
> > RB1 send TRILL IIH to RB3
> > RB2 send TRILL IIH to RB4
> > RB3 send TRILL IIH to RB1 and RB4
> > RB4 send TRILL IIH to RB2 and RB3
> > Please correct me, if I am misinterpreting it.
>
> RB1 also sends Hellos to ESa and RB2 also sends Hellos to ESb. Beause
> Ethernet supports multi-access links and the Hellos are sent to a
> multicast address, in my expanded version of your diagram, Hellos sent
> by RB3 on the link it shares with RB4 are also delivered to RB5,
> Hellos sent by RB4 on that link are also delivered to RB5, and Hellos
> send by RB5 are delivered to both RB3 and RB4. It does not matter
> particulrly if the link connecting RB3, RB4, and RB5 is some
> inherently multi-access technology or perhaps consists of three
> point-to-point physical Ethernet links connected by a bridge or
> whatever.
>
> > TRILL IS-IS LSP's are used to communicate the link information to
> > the campus. That's how, RBridges know each other.
> > As RBridges do not forward TRILL IS-IS frames, how information
> > (TRILL IS-IS LSP) of RB1 is communicated to RB2?
>
> "not forward" just means that the frames are not automatically
> forwarded at a low level. If every RBridge that received an LSP
> immediately forwarded it out all of its ports, other than the one it
> received it on, for any non-tree topology you would quickly find your
> network saturated with loooping LSPs. The ISO standard update process
> for the link state database is described in Section 7.3 of ISO/IEC
> 10589-2002. The techniques used in Layer 3 IS-IS are generally
> applicable to TRILL. Commonly, if an LSP is received that is not a
> duplicate of one alrady held by the RBridge it will be stored in the
> link state database and flags are set so it will be promptly
> forwarded.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3@gmail.com
>
> > Thank you!
> >
> > --
> > Best Regards,
> > Muhammad Mohsin Sardar
>

-- 
Best Regards,
Muhammad Mohsin Sardar