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

Hi Donald

Please see my comments in-line

-----Original Message-----
From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Donald Eastlake
Sent: Thursday, July 12, 2012 8:26 AM
To: Naveen Nimmu
Cc: trill@ietf.org
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  d3e3e3@gmail.com

On Mon, Jun 18, 2012 at 3:12 PM, Naveen Nimmu <naveen@broadcom.com> 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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Monday, June 18, 2012 8:13 AM
> To: tsenevir@cisco.com
> Cc: aldrin.ietf@gmail.com; ginsberg@cisco.com; Naveen Nimmu; 
> ayabaner@gmail.com
> 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
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill