Subject: Re: [trill] FW: New Version Notification for draft-tissa-trill-mt-encode-01.txt

From: Donald Eastlake <[email-masked]>
Date: Thu, 12 Jul 2012 11:26:25 -0400

A few comments:

It seems to me that the top level difficulty with this draft is that
it assumes that TRILL is an Ethernet protocol. But it isn't. Where do
these tags go in the TRILL Data frame on a PPP link [RFC6361] or in
the possible IPv4/6 link format in draft-mrw-trill-over-ip or in the
possible MPLS TRILL Data format in draft-ietf-l2vpn-trill-evpn? You
could put new tags after the Inner.VLAN or you could expand the TRILL
Header but trying to put new tags in front of the TRILL Header seems
problematic and also guarantees that only new hardware can process the
frame at all.

Ignoring the above problem and commenting on the multi-topology and
nickname expansion aspects of the draft:

I'm not sure why the topology ID tag has 16 bits of topology when all
the other IS-IS related topology things I know about have 12 bits of
topology ID and, in the real world, I understand it is very rare to
use more than around 8 topologies. Also, the interesting alternative
of encoding the topology in the Outer.VLAN tag, which only works on
Ethernet links, would tend to use the 12-bit VLAN ID for topology
although I suppose, depending on how big a change you are making in
the port silicon, you could repurpose the priority and DEI bits...
Anyway, having a few reserved flag bits sometimes turns out to be
extremely useful so I'm thinking that sticking with 12 bits would be
better. And, in any case, redefining the content of the VLAN tag while
continuing to use the C-VLAN Ethertype would be viewed as a problem by
some.

I'm not sure why there has to be an MT Capability bit. Wouldn't just
not including the MT TLV be a good enough indication if you required
even an MT capable RBridge only participating in base topology zero to
include the MT TLV?

If you are going to expand the nickname space, I don't quite see why
you only add 8 bits and why, it appears, you are going for a larger
flat nickname space. There is power in hierarchy. Perhaps you mean for
the 8 bits to be used somewhat hierarchically for naming areas in
multi-level or the like but it doesn't sound like that. Going to a
flat 24-bit nickname seems like it, in general, requires new silicon
and biases the design towards high end switches with bigger tables,
etc. If you need new silicon anyway, I think that adding 16-bits with
a fixed hierarchy split of the upper and lower 16-bit parts and using
something like the "swap nickname" logic suggest in
draft-perlman-trill-rbridge-mulilevel-04.txt would enable forwarding
tables to remain small and better support a wider range of switches.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Mon, Jun 18, 2012 at 3:12 PM, Naveen Nimmu <[email-masked]> wrote:
> A new version of this draft is posted. This version adds  proposed  extensions to support TRILL nickname space from 16bits to 24 bits.
> Please review and provide feedback.
> Thanks
> \naveen
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, June 18, 2012 8:13 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Naveen Nimmu; [email-masked]
> Subject: New Version Notification for draft-tissa-trill-mt-encode-01.txt
>
>
> A new version of I-D, draft-tissa-trill-mt-encode-01.txt
> has been successfully submitted by Tissa Senevirathne and posted to the
> IETF repository.
>
> Filename:        draft-tissa-trill-mt-encode
> Revision:        01
> Title:           Multi Topology Encoding within TRILL data frames
> Creation date:   2012-06-17
> WG ID:           Individual Submission
> Number of pages: 12
> URL:             http://www.ietf.org/internet-drafts/draft-tissa-trill-mt-encode-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-tissa-trill-mt-encode
> Htmlized:        http://tools.ietf.org/html/draft-tissa-trill-mt-encode-01
> Diff:            http://tools.ietf.org/rfcdiff?url2=draft-tissa-trill-mt-encode-01
>
> Abstract:
>    Two alternate methods of encoding Multi Topology Identifier within
>    the TRILL data frames are presented. Methods proposed herein do not
>    require overloading TRILL RBridge nickname to encode Multi Topology
>    Identifier. A method that expands TRILL nickname space from 16bits
>    to 24 bits is also presented in this draft.
>
>
>
>
> The IETF Secretariat
>
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 13 Jul 2012 04:13:16 +0000

Hi Donald

Please see my comments in-line

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Thursday, July 12, 2012 8:26 AM
To: Naveen Nimmu
Cc: [email-masked]
Subject: Re: [trill] FW: New Version Notification for draft-tissa-trill-mt-encode-01.txt

A few comments:

It seems to me that the top level difficulty with this draft is that it assumes that TRILL is an Ethernet protocol. But it isn't. Where do these tags go in the TRILL Data frame on a PPP link [RFC6361] or in the possible IPv4/6 link format in draft-mrw-trill-over-ip or in the possible MPLS TRILL Data format in draft-ietf-l2vpn-trill-evpn? You could put new tags after the Inner.VLAN or you could expand the TRILL Header but trying to put new tags in front of the TRILL Header seems problematic and also guarantees that only new hardware can process the frame at all.

[Answer] These are encoded hop-by-hop. Superior RBridge do not include when interfacing with older RBridges.

Ignoring the above problem and commenting on the multi-topology and nickname expansion aspects of the draft:

I'm not sure why the topology ID tag has 16 bits of topology when all the other IS-IS related topology things I know about have 12 bits of topology ID and, in the real world, I understand it is very rare to use more than around 8 topologies. Also, the interesting alternative of encoding the topology in the Outer.VLAN tag, which only works on Ethernet links, would tend to use the 12-bit VLAN ID for topology although I suppose, depending on how big a change you are making in the port silicon, you could repurpose the priority and DEI bits...
Anyway, having a few reserved flag bits sometimes turns out to be extremely useful so I'm thinking that sticking with 12 bits would be better. And, in any case, redefining the content of the VLAN tag while continuing to use the C-VLAN Ethertype would be viewed as a problem by some.

[Answer] Point taken. It was made 16 bit aligned. But next rev we can carve out the upper 4-bits as reserved bits.

I'm not sure why there has to be an MT Capability bit. Wouldn't just not including the MT TLV be a good enough indication if you required even an MT capable RBridge only participating in base topology zero to include the MT TLV?

[Answer] MT capability bit was added to identify the MT capability in the Hello message itself. However, we can discuss the use of the MT TLV for the purpose. I did not quite understand the inclusion of MT TLV in base topology question.

If you are going to expand the nickname space, I don't quite see why you only add 8 bits and why, it appears, you are going for a larger flat nickname space. There is power in hierarchy. Perhaps you mean for the 8 bits to be used somewhat hierarchically for naming areas in multi-level or the like but it doesn't sound like that. Going to a flat 24-bit nickname seems like it, in general, requires new silicon and biases the design towards high end switches with bigger tables, etc. If you need new silicon anyway, I think that adding 16-bits with a fixed hierarchy split of the upper and lower 16-bit parts and using something like the "swap nickname" logic suggest in draft-perlman-trill-rbridge-mulilevel-04.txt would enable forwarding tables to remain small and better support a wider range of switches.

[Answer] How upper 8 bits be used to construct the 24 bit address is an administrative manner. We did not want to go 32 bit address space, then we are facing the question why TRILL lets use IP in place TRILL. 

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA  [email-masked]

On Mon, Jun 18, 2012 at 3:12 PM, Naveen Nimmu <[email-masked]> wrote:
> has been successfully submitted by Tissa Senevirathne and posted to 
> the IETF repository.
>