Subject: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

From: Donald Eastlake <[email-masked]>
Date: Tue, 6 Nov 2012 15:42:42 -0500

Hi,

As announced at the TRILL WG meeting today, this starts a two week WG
Last Call on draft-ietf-trill-fine-labeling ending 19 November.

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

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 14 Nov 2012 00:56:10 +0000

Support.

Mingui

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald
>Eastlake
>Sent: Wednesday, November 07, 2012 4:43 AM
>To: [email-masked]
>Subject: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt
>
>Hi,
>
>_______________________________________________
>trill mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/trill

---

From: Jon Hudson <[email-masked]>
Date: Tue, 13 Nov 2012 18:09:59 -0700

Support!!

---

From: [email-masked]
Date: Wed, 14 Nov 2012 09:11:56 +0800

+1, Support! 

Jon Hudson <[email-masked]> 
发件人:  [email-masked]
2012-11-14 09:09

收件人
Mingui Zhang <[email-masked]>
抄送
Donald Eastlake <[email-masked]>, "[email-masked]" <[email-masked]>
主题
Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Support!!

---

From: gayle noble <[email-masked]>
Date: Tue, 13 Nov 2012 18:03:19 -0800

support

---

From: "Naveen Nimmu" <[email-masked]>
Date: Wed, 14 Nov 2012 04:42:14 +0000

Support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jon Hudson
Sent: Wednesday, November 14, 2012 6:40 AM
To: Mingui Zhang
Cc: Donald Eastlake; [email-masked]
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Support!!

---

From: [email-masked]
Date: Wed, 14 Nov 2012 13:15:33 +0800

Support.

Best Regards,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 
 Zhai Hongjun
 
 Tel: +86-25-52877345
 Email: [email-masked]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Donald Eastlake <[email-masked]> 
发件人:  [email-masked]
2012-11-07 04:42

收件人
[email-masked]
抄送

主题
[trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Hi,

Thanks,
Donald

---

From: Sunny Rajagopalan <[email-masked]>
Date: Wed, 14 Nov 2012 09:13:13 -0800

Support!

From:   Donald Eastlake <[email-masked]>
To:     [email-masked], 
Date:   11/06/2012 12:43 PM
Subject:        [trill] WG Last Call: 
draft-ietf-trill-fine-labeling-02.txt
Sent by:        [email-masked]

Hi,

Thanks,
Donald

---

From: Radia Perlman <[email-masked]>
Date: Wed, 14 Nov 2012 09:15:47 -0800

Support!

---

From: "Rajeev Manur" <[email-masked]>
Date: Thu, 15 Nov 2012 00:19:07 +0000

Support!

I have the following editorial comments,

* Section 4.0
    -- First line in third paragraph : FLG should be changed to FGL
    -- Similar typo needs to be fixed in the 4th paragraph, LFG should be changed to FGL
* Section 5.0
    -- Suggest changing the following sentence as below make the intent more explicit and remove ambiguity,

Current: "The FGL ingress process MUST place the priority and DEI associated with an ingressed native frame in upper 4 bits of the Inner.Label Low Order part."

New: "The FGL ingress process MUST copy the priority and DEI from an ingressed native frame to upper 4 bits of the Inner.Label Low Order part."

* Section 7.0
    -- I see reference to first and second part of FGL. In previous sections same fields are referred to as High and Low parts of FGL. It may be better to use one name consistently across the doc.

Thanks!
--Rajeev

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Tuesday, November 06, 2012 12:43 PM
To: [email-masked]
Subject: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Hi,

Thanks,
Donald

---

From: Yizhou Li <[email-masked]>
Date: Thu, 15 Nov 2012 08:53:21 +0800

Support

Yizhou

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Donald Eastlake
Sent: Wednesday, November 07, 2012 4:43 AM
To: [email-masked]
Subject: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Hi,

Thanks,
Donald

---

From: Sujay Gupta <[email-masked]>
Date: Fri, 16 Nov 2012 15:48:12 +0530

Support.

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 16 Nov 2012 12:40:32 -0500

Hi Rajeev,

>     -- Similar typo needs to be fixed in the 4th paragraph, LFG should be changed to FGL

It would be sort of interesting to try to include all possible
permutations in the draft, but I think you are right and these should
be fixed.

> New: "The FGL ingress process MUST copy the priority and DEI from an ingressed native frame to upper 4 bits of the Inner.Label Low Order part."

OK.

>     -- I see reference to first and second part of FGL. In previous sections same fields are referred to as High and Low parts of FGL. It may be better to use one name consistently across the doc.

OK.

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

---

From: Olen Stokes <[email-masked]>
Date: Sun, 18 Nov 2012 09:27:33 -0800

Comparing the -01 and the -02 versions of this draft shows some very
important changes.  I understand the desire to finalize this draft.
However, I am concerned that the changes in the -02 version may have
created some inconsistencies in the document.  There may also be
opportunities to more clearly state some of the implications of the
changes.

Section 1.1 still defines a FGL RBridge as a ³TRILL switch that support[s]
both FGL and VL².  However, Section 9 states, ³no TRILL data frames can be
exchanged between VL and FGL RBridges².  It would be helpful to better
describe scenarios where a FGL RBridge needs to support a VL mode of
operation if a FGL RBridge cannot exchange packets with a VL RBridge.

Section 3 states that the default port configuration for a FGL RBridge
port is VL.  A scenario where this is utilized would also be helpful.

Otherwise, if a FGL RBridge does not have to support a VL mode of
operation, a specific statement to that effect would be appropriate.

Section 7, Item 2, only discusses ³Silicon Considerations² from an
ingress/egress point of view.  It does not discuss it from a transit
RBridge perspective.

However, there appears to be several statements in the draft that could
have important effects on how existing silicon could be used for transit
FGL RBridge operation.  Section 5.1 states:

³An FGL ingress RBridge MAY serially TRILL unicast a multi-destination
TRILL Data frame to the relevant egress TRILL switches after encapsulating
it as a TRILL known unicast data frame (M=0)².

This would appear to allow silicon that can TRILL forward unicast FGL
packets to operate as a TRILL transit FGL node regardless of whether it
can TRILL forward FGL multi-destination packets.  If that is the intent,
it would be helpful to state that in Section 7, Item 2.

Section 5.2.2 states:

³Pruning is an optimization. If a transit TRILL switch does less pruning
than it could, there may be greater link utilization than strictly
necessary but the campus will still operate correctly.²

This would appear to allow silicon that can TRILL forward FGL
multi-destination packets to operate as a TRILL transit FGL node
regardless of whether it can prune FGL packets.  If that is the intent, it
would be helpful to state that in Section 7, Item 2.

Section 5.2.2 also discusses pruning based only on the High Part or the
Low Part of a FGL.  A statement about silicon that can prune based only on
half of a FGL would also be helpful in Section 7, Item 2.

Thanks for any consideration of these items.

Cheers,
Olen

---

From: Haoweiguo <[email-masked]>
Date: Mon, 19 Nov 2012 09:23:09 +0000

Support.

________________________________________
发件人: Sujay Gupta [[email-masked]]
发送时间: 2012年11月16日 18:18
到: Donald Eastlake
Cc: [email-masked]
主题: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Support.

---

From: Thomas Narten <[email-masked]>
Date: Mon, 19 Nov 2012 10:34:11 -0500

(repost with proper subject)

I have read the document, and want to raise some basic questions about
this document.

An original premise for this document was that it would use the same
Ethertype=0x8100 encoding for the inner header as the the base
protocol. This was done for backwards-compatability with base RBs and
to allow non-FGL aware RBs to forward FGL frames. Under this
assumption, having the labels split into two different parts using
separate fields made sense.

However, with the -01 revision, the above assumption has been thrown
out. FGLs now use a different ethertype encoding, and various parts of
the document make it clear that an RB operates in either FGL or VL
mode, with no overlap or backwards compatability. RBs implementing VL
are not supposed to receive or process FGL formatted TRILL data
frames.

Given that, I do not see a compelling justification for retaining the
"double tagging" encoding format the current document
supports. Specifically, I'd suggest:

1) not having separate high-order and low-order FGL fields; just
define one field that is 24 bits long.

2) Remove the second ethertype=0x893B field completely. We are just
wasting 2 bytes. (the field serves no useful purpose and must always
hold the value of 0x893B.)

3) While I don't have a strong opinion either way, I would also like
to see a justification for having an "Alternate Priority" field. The
base TRILL protocol doesn't have one. Why is it needed for FGLs?

Under the previous encapsulation format, we got the extra priority
"for free" since it was part of the TAG, but I'd like to see the
rational/use case for having this extra field stand on its own
merits. Is this just a "what the heck, why not" field? Or is there a
compelling use case for it?

I am also uncomfortable with some of the wording in the document
regarding "silicon".

>    2. Silicon Considerations
> 
>       Fine-grained labeling (FGL) should, to the extent practical, use
>       existing features, processing, and fields that are already
>       supported in at least some fast path silicon implementations that
>       currently support the TRILL base protocol.

This makes sense. We do not want to pick encodings that will be
problematatic for silicon (generally).  However, we also need to
balance such a desire against not restricting our design solely to
favor, say, one particular implementation. (I am not suggesting that
is being done here, just pointing out that if the current encoding
does favor certain implementations, we need to be upfront about that,
and discuss the implications openly.)

>    2. Silicon Considerations: Existing TRILL fast path silicon chips can
>       perform base TRILL Header insertion and removal to support ingress
>       and egress. In addition, it is believed that most such silicon
>       chips can also perform the native frame to FGL mapping and the
>       encoding of the FGL as specified herein, as well as the inverse
>       decoding and mapping. Some existing silicon can perform only one
>       of these operations on a frame in the fast path and is thus not
>       suitable to implement fast path TRILL FGL processing; however,
>       other existing chips are believed to be able to perform both
>       operations on the same frame in the fast path and are suitable for
>       FGL implementation.

My impression in talking to folk familiar with silicon implementations
is that silicon has gotten pretty good at being able to extract fields
from fixed arbitrary offsets into a packet. Thus, while they may be
able to extract the two separate labels and combine them (as the
current proposal calls for), they can just as easily extract a single
label of 24 bits.

If we are going to stick with the current encoding, I'd like to hear
directly from the silicon implementors why that is *necessary* and why
they cannot support the more natural/obvious format for 24-bit labels.

I have additional comments on the draft, but they may not be relevant
depending on how the above points are resolved.

Thomas

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 19 Nov 2012 20:19:01 -0500

Hi Olen,

Thanks for the comments. See responses below.

On Sun, Nov 18, 2012 at 12:27 PM, Olen Stokes
<[email-masked]> wrote:
> important changes.

I agree.

>                     I understand the desire to finalize this draft.

I don't think there are any inconsistencies. However, it is certainly
possible that some clarifications and/or editorial changes would
improve the draft.

> Section 1.1 still defines a FGL RBridge as a "TRILL switch that
> support[s] both FGL and VL".  However, Section 9 states, "no TRILL
> data frames can be exchanged between VL and FGL RBridges".  It would
> be helpful to better describe scenarios where a FGL RBridge needs to
> support a VL mode of operation if a FGL RBridge cannot exchange
> packets with a VL RBridge.

Yes, an FGL RBridge must support Fine Grained Labeling (FGL) and
support VLAN Labeling (VL) as the inner data label. In other words, an
FGL RBridge must be able to ingress a native frame to an FGL TRILL
data frame, handle an FGL TRILL data frame as a transit switch, and
egress an FGL TRILL data frame to a native frame. In addition, an FGL
RBridge must be able to ingress a native frame to a VL TRILL data
frame, handle a VL TRILL data frame as a transit switch, and egress a
VL TRILL data frame as a native frame, all this VL stuff as described
in the TRILL base protocol RFC 6325.

So an FGL RBridge can safely handle VL data traffic. But if you give
an FGL data frame to a VL RBridge, it is very likely to be mishandled.
This problem with VL RBridges, which by definition are FGL ignorant,
is the reason for not allowing TRILL data traffic between FGL and VL
RBridges.

> Section 3 states that the default port configuration for a FGL
> RBridge port is VL.  A scenario where this is utilized would also be
> helpful.

Here are three uses that come to mine immediately:

- If you are upgrading a campus from VL to FGL RBridges, it might be
  some time, if ever, before you configured connectivity between all
  end stations to make use of FGL. In the mean time, you would want VL
  to continue working.

- It would be possible to standardize data connection between VL and
  FGL RBridges if it was specified how to do multi-topology. You could
  then have one topology with just FGL RBridges and a second topology
  with all RBridges. As long as FGL frames were limited to the FGL
  topology and that topology was fully connected, all would be
  well. Requiring FGL RBridges to support VL maintains this as a
  future possibility by merely adding multi-topology. Otherwise you
  would have to both add multi-topology and retro-fit VL support.

- Due to the way TRILL works, it appears that it will be desirable to
  have a maintenance VLAN in which all RBridges in a campus indicate
  interest (see, for example, draft-ietf-trill-oam-framework). You
  could, I suppose, have a maintenance FGL but it might as well work
  the same way for a VL campus as for an FGL campus.

> operation, a specific statement to that effect would be appropriate.

The current FGL draft, just like all previous versions of the FGL WG
and preceeding personal draft, does require support of VL by FGL
RBridges. Since you specifically talk about -01 to -02 changes, you
might not it is not a change that just appeared in the current
version.

> Section 7, Item 2, only discusses "Silicon Considerations" from an

Good point, transit processing should be mentioned briefly in Section
7, Item 2. However, the items in Section 7 are parallel with the same
number items in Section 2.1 and are just intended to discuss the
extent to which the goals in 2.1 are met, not to be a complete
discussion or summary of the named topics... Perhpas "Silicon
Considerations" should be replaced with "Silicon Goal".

> However, there appears to be several statements in the draft that
> could have important effects on how existing silicon could be used
> for transit FGL RBridge operation.  Section 5.1 states:
>
> "An FGL ingress RBridge MAY serially TRILL unicast a
> multi-destination TRILL Data frame to the relevant egress TRILL
> switches after encapsulating it as a TRILL known unicast data frame
> (M=0)".
>
> This would appear to allow silicon that can TRILL forward unicast
> FGL packets to operate as a TRILL transit FGL node regardless of
> whether it can TRILL forward FGL multi-destination packets.  If that
> is the intent, it would be helpful to state that in Section 7, Item
> 2.

Your statement seems a odd to me.  I don't understand what you mean
when you say "regardless of whether it can TRILL forward FGL
multi-destination packets". If it can't do that, I don't think it is
an FGL RBridge.

An FGL RBridge is required to be able to forward known unicast data
that is TRILL unicast (M=0), multi-destination data that is TRILL
multicast (M=1), and, due to the text you quote, multi-destination
data that is TRILL unicast (M=0).  Since your specifically talk about
-01 to -02 changes, you might note that this has been required in all
previous versions of the FGL WG draft and preceeding personal draft.
It is not a change that just appeared in the current -02 version.

> Section 5.2.2 states:
>
> "Pruning is an optimization. If a transit TRILL switch does less
> pruning than it could, there may be greater link utilization than
> strictly necessary but the campus will still operate correctly."
>
> regardless of whether it can prune FGL packets.  If that is the
> intent, it would be helpful to state that in Section 7, Item 2.

Pruning is a SHOULD in the base TRILL protocol standard and it is the
same here. The provisions here are similar to those in the base
standard for VL pruning. I don't see any problem adding something to
clarify although I don't think Section 7, Item 2, is the best place.
How about just adding, at the end of the last sentence in Section
5.2.2, the following words "or not prune FGL frames at all"?

> Section 5.2.2 also discusses pruning based only on the High Part or
> the Low Part of a FGL.  A statement about silicon that can prune
> based only on half of a FGL would also be helpful in Section 7, Item
> 2.

But the whole point is that, since pruning is just a SHOULD
optimization, the silicon could prune on whatever subset of FGL bits
it feels like and still be conformant. For example, it could prune on
just the highest order bit or just the highest order byte of the FGL
or something. How about, including the addition above, changing

"For example, a transit TRILL switch could prune based on only part of
the FGL such as only the High Part or only the Low Part."

to

"A transit TRILL switch could prune based on an arbitrary subset of
the FGL label bits, such as only the High Part or only the Low Part,
or not prune FGL frames at all."

Actually an RBridge could adopte even more strange or exotic pruning
methods, although I can't see why it would want to. For example, it
could prune based on the data label value modulo some arbitrary
integer divisor less than the maximum label value...sort of a
ridiculous thing to do but frames would still be routed correctly so I
believe such behavior is allowed.

Thanks,
Donald

---

From: Thomas Narten <[email-masked]>
Date: Mon, 19 Nov 2012 20:40:27 -0500

Hi.

> in the TRILL base protocol RFC 6325.

I'm still a bit confused by this discussion.

My understanding (from reading the draft earlier today) was that an RB
either operates in FGL mode or VL mode. It doesn't mix and
match. I.e., you don't have an RB with some ports understanding FGL
and others VL.  (To do that, you'd an RB would have to convert between
the the two formats which could result in loss of information...)

And the way to look at VL mode, is that it is the fallback for the
case where not all of the RBs in the compus are FGL capable.

Is my understanding correct?

Skimming the document again, this could perhaps be clearer.

I.e., what is supposed o happen in a campus where some RBs say they do
FGL and others do not? Is the intention that one TRILL campus gets
formed with all nodes falling back to VL mode?

Thomas

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 19 Nov 2012 22:24:29 -0500

Hi Thomas,

I guess the draft is not as clear as I thought it was.

> the the two formats which could result in loss of information...)

So what exactly did you think text like the following meant:
   "An FGL RBridge MAY be configured, on one or more ports, to ingress
   native frames as FGL. Any ports not so configured that accepts a
   native frame perform the previously specified VL ingress processing
   on native frames [RFC6325]."

I also can't see why you would think that the ability to ingress,
transit, and egress both VL and FGL frames implies having to "convert"
between those formats. The whole idea of data labeling is
separation/isolation. Why would you convert between them anymore than
you would convert between a random pair of different VLANs?

Anyway, the intent is that ports operate in either VL or FGL mode. And
all the ports of a VL RBridge are VL ports. But an FGL RBridge is
required to support an arbitrary mix of VL and FGL ports. VL and FGL
frames are ships in the night just like VL frames for different VLANs
for FGL frames for different FGLs.

> case where not all of the RBs in the compus are FGL capable.

The word "mode" does not occur anywhere in the body of the draft. FGL
RBridges are supersets. FGL RBridges can handle VL frames fine. It is
just that VL RBridges can't handle FGL frames and it is very hard to
guarantee that an FGL frame will never be routed to a VL RBridge
without either multi-topology (which is not yet fully specified for
TRILL) or stopping all data flow between VL and FGL RBridges (whcih is
what this draft does).

> Is my understanding correct?

See above.

> Skimming the document again, this could perhaps be clearer.

I guess so.

> formed with all nodes falling back to VL mode?

As stated in the draft, the assumption in that case is that you wanted
a completely FGL campus and whatever VL RBridges are present are
isolated misconfigurations. So the provisions are that all the
RBridges peer for control but VL and FGL RBridges do not peer for
data. You don't want the attachment of one RBridge misconfigured to be
a VL RBridge to kill your whole FGL campus. You can't "fall back" a
port configured for FGL without violating security policy.

Maybe clarifying text should be added and the "FGL RBridges" should be
referred to as "FGLVL RBridges".

Thanks,
Donald

---

From: Radia Perlman <[email-masked]>
Date: Mon, 19 Nov 2012 20:13:35 -0800

Ah.  So the intent is that an FGL RBridge must be able to parse either VL
or FGL, which would allow an edge RB that only supports VL to work OK, and
to have some number of VLANs (4000 of them) that would be reachable via old
edge RBs?

And we're assuming that old edge RBs that only do VL will know to drop
something tagged with FGL?

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 19 Nov 2012 23:29:47 -0500

Hi Radia,

On Mon, Nov 19, 2012 at 11:13 PM, Radia Perlman <[email-masked]> wrote:
> Ah.  So the intent is that an FGL RBridge must be able to parse either VL or
> FGL, which would allow an edge RB that only supports VL to work OK, and to
> have some number of VLANs (4000 of them) that would be reachable via old
> edge RBs?

Yes on parsing. But it is hard to be sure no FGL frame can get to a VL
RBridge. Say you have VLRB1 connected to the campus through FGLRB2.
And FGLRB2 is connected to FGLRB3. What if connectivity appears
between VLRB1 and FGLRB3 and perhaps the link between FGLRB2 and
FGLRB3 breaks? How can you stop FGL frames from going between FGLRB2
and FGLRB3 via VLRB1 keeping in mind that you have to assume no
changes in the old VL RBridges? (Without multi-topology. With
multi-topology, it's relatively easy.)

> something tagged with FGL?

A VL RBridge should, in my opinion, drop an FGL frame based on RFC
6325. However, if it did not, it would presumably mean it was ignoring
the 0x893B value where it should be requiring 0x8100. As a result, it
would believe the FGL frame was in some VLAN and might egress it to
the wrong end-stations, violating security policy.

Thanks,
Donald

---

From: Thomas Narten <[email-masked]>
Date: Tue, 20 Nov 2012 07:35:25 -0500

Hi Donald.

>    on native frames [RFC6325]."

Personally, I thought the wording was somewhat odd, and made a note to
figure out what the real intention was. :-) Also, "MAY" means it's not
part of the spec, but not being disallowed either. That is not the
same thing as saying it is something that implementations would want
or need to do.

> you would convert between a random pair of different VLANs?

No disagreement. My assumption had been that if you have an RB that
understands both VL and FGL, that such a mode would only be useful if
one was converting from one format to the other, or if one fell back
from from FGL to VL mode if it didn't make sense to operate in FGL
mode. But I wasn't 100% sure what the draft's intention was...

But on rereading parts of the draft, it seems that a single TRILL
campus can actually consist of a mixture of both VL and FGL-capable
RBs. And that campus is effectively partitioned, where some of the
links/RBs operate in FGL mode (only) and the rest operate in VL mode
(only) with the data planes of the "two networks" operating likes
ships in the night.

You can even have a single RB supporting both modes (on some
links). E.g., you could have RB1 with links L1 and L2 operating in VL
mode and links L3 and L4 operating in FGL mode. Right? (This is
because it is the individual links that operate in a given mode, not
the RB per se.)

If so, let me push back on this model.  The document says:

   The usual DRB election operates on a link with mixed FLG and VL
   ports. If an FGL RBridge port is DRB, it MUST handle all native
   traffic or appoint only other FGL ports as forwarder for one or more
   VLANs, so that all end stations will get service to the FGL campus.
   If a VL RBridge port is DRB, it will not understand that FGL RBridge
   ports are different. To the extent that a VL DRB handles native
   frames or appoints other VL ports on a link to handle native frames
   for one or more VLANs, the end stations sending and receiving those
   native frames will be isolated from the FGL campus. To the extent
   that a VL DRB happens to appoint an FGL port as Appointed Forwarder
   for one or more VLANs, the end stations sending and receiving native
   frames in those VLANs will get service to the FGL campus. This
   somewhat odd corner case behavior is considered acceptable because it
   is assumed that VL TRILL switches in an FGL campus are infrequent
   misconfigurations.

I would not just call this a "corner case" that can be ignored. What
it seems to mean is that you can deply TRILL, but get disconnected
VLAN islands. That is, C-VID X at one edge is processed by FGL RBs
(say RB1), but elsewhere on the network, only VL RBs connect to C-VID
X (say via RB2). Because the VL and FGL networks are isolated from
each other, the result is that devices in VLAN X connected to RB1 will
be unable to communicated with devices in VLAN X connected to
RB2. Right?

I wouldn't consider that a "corner case" to be ignored. I'd consider
that an operational nightmare that can't be allowed to happen (by
default).

> for FGL frames for different FGLs.

Why must FGL capable devices be required to support VL? I understand
that it is probably a good thing to do (so you can support either
mode, depending on what other RBs are capable of). But does the FGL
*protocol* require this in order to work correctly? Does proper
operation of FGL require being able to support VL as well? Or is the
real intent just to allow a graceful way to "fall back" into VL mode
to intereperate with non FGL-aware RBs? (I think that is a fine thing
to require, btw.)

> TRILL) or stopping all data flow between VL and FGL RBridges (whcih is

IMO, this spec should not say anything about multi-topology (that is
future work) and should ensure that a standards compliant
implementation cannot and will not forward FGL packets to VL-only
RBs. Anything else will likely lead to operational problems...

> isolated misconfigurations.

I think this is an unreasonable assumption. You will get deployments
that have both. Accidents can happen, etc. I think we'd be better off
with very clear ways for the operator to specify what they want to
have happen in a mixed mode. We can have a default mode, but the
operator needs to be able to override the defaults.

I.e., if only one (or a small number of) switches supports FGL, you
want the default mode to be to have the entire TRILL campus to try to
use FGL? I'm not sure. 

> So the provisions are that all the RBridges peer for control but VL
> and FGL RBridges do not peer for data. You don't want the attachment
> of one RBridge misconfigured to be a VL RBridge to kill your whole
> FGL campus. You can't "fall back" a port configured for FGL without
> violating security policy.

I don't understand the "security policy" reference here.

> referred to as "FGLVL RBridges".

No. The issue isn't terminology. The text needs to be clearer what the
intention is. For me, it's sometimes hard to pull out the overriding
intention from the specific rules that are layed out in the document.

Thomas

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 20 Nov 2012 11:19:59 -0800

> multi-topology, it's relatively easy.)

FGL frames should never be forwarded to an RB that doesn't
support FGL.  This is easy to figure out since IS-IS can tell us
what the capabilities of an RBridge are before forwarding to
that RBridge begins.  And as a result of this requirement, we
should probably disallow FGL and non-FGL bridges being
reachable from the same RBridge port, otherwise it would be
challenging to implement this control for multicast frames.

> the wrong end-stations, violating security policy.

We need to make the spec clear on this aspect; i.e. FGL or non-FGL
RBridges must discard a received frame if the inner tag (FGL or VLAN
depending on what mode the port is operating in) is absent.

Anoop

---

From: Phanidhar Koganti <[email-masked]>
Date: Tue, 20 Nov 2012 11:29:30 -0800

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Wednesday, November 21, 2012 12:50 AM
To: Donald Eastlake
Cc: Radia Perlman; [email-masked]
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

On Mon, Nov 19, 2012 at 8:29 PM, Donald Eastlake <[email-masked]<mailto:[email-masked]>> wrote:
Hi Radia,

[Phanidhar Koganti] Does this mean non-FGL RBridges cannot act as transit nodes? Why can't the transit nodes just rely on TRILL SA/DA to forward. Agree there will be issues for multicast in terms of the optimal pruned forwarding as a non-FGL RB will not have access to the inner IP header or VLAN (FGL based). However isn't this an optimization for multicast pruning? The transit RBs can forward based on the non-pruned multicast tree.

Anoop

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 20 Nov 2012 13:53:18 -0800

On Tue, Nov 20, 2012 at 11:29 AM, Phanidhar Koganti <[email-masked]>wrote:

> multi-topology, it's relatively easy.)****
>
> ** **
>
> FGL frames should never be forwarded to an RB that doesn't****
>
> support FGL.  This is easy to figure out since IS-IS can tell us ****
>
> what the capabilities of an RBridge are before forwarding to****
>
> that RBridge begins.  And as a result of this requirement, we****
>
> should probably disallow FGL and non-FGL bridges being ****
>
> reachable from the same RBridge port, otherwise it would be ****
>
> challenging to implement this control for multicast frames. ****
>
> *[Phanidhar Koganti] Does this mean non-FGL RBridges cannot act as
> transit nodes? Why can’t the transit nodes just rely on TRILL SA/DA to
> forward. Agree there will be issues for multicast in terms of the optimal
> pruned forwarding as a non-FGL RB will not have access to the inner IP
> header or VLAN (FGL based). However isn’t this an optimization for
> multicast pruning? The transit RBs can forward based on the non-pruned
> multicast tree.*****
>
> **
>

There are security issues as pointed out by Donald.  If the device that
we thought was going to be just a transit device, but it also had edge
ports, it could end up leaking these frames on edge ports.

The other option would be for the FGL spec to update RFC 6325 to
say that if the inner VLAN tag is not present then the frame must not be
egressed in native form, and to state that if one wants to use a non-FGL
RBridge as a transit device, then it must support this behavior.

Anoop

---

From: Olen Stokes <[email-masked]>
Date: Tue, 20 Nov 2012 21:07:37 -0800

Trying NOT to add anything more in lineŠ

It seems that multiple different people have multiple different migration
scenarios in mind.  I think that several of us could benefit from
something that better spells out what scenario(s) the authors have in
mind.  Donald's scenarios described in his response to my previous email
would have helped the draft.  We can then discuss if there are others that
need to be considered.

We seem to be discussing three types of nodes:

1) VL-only capable RBridges
2) VL and FGL capable RBridges
3) FGL-only capable Rbridges

For the third (FGL-only) type, remember that at some point people will
want to drop support for the VL RBridges.  There may also be silicon out
that that can operate in VL mode or in FGL mode but not both at the same
time.  Note, I am not a silicon person.

If these three types are intended, a more clear statement of the
requirements for each time might be of benefit.  The requirements should
describe ingress, egress, transit, and transit plus egress RBridges. If
one of these types is not intended, then a clear statement that it is not
supported may be in order.  It could then be debated.

I believe that Donald has described that the second type above (VL and FGL
capable RBridge) is a requirement.  To me, the best case for that
requirement is in a multi-topolgy environment.  Stating that use case
would have made the document and that requirement more clear to me.  I
leave it to others to figure out how to reference something that might be
defined in another draft (at some point in the future).  Note that to me,
a "VL and FGL capable" node acting only as a VL node is just a VL RBridge.

Cheers,
Olen

---

From: "Rajeev Manur" <[email-masked]>
Date: Wed, 21 Nov 2012 19:24:54 +0000

My understanding is we have only 2 modes, VL-mode and FGL-mode (superset mode supporting both VL and FGL). I feel it would be useful to add more text to clarify the processing/compliance requirements for ingress / transit / egress RB contexts separately for each of these two modes. This will help implementations they may want to support transit only functions and still be compliant.

For example, it is not clear to me when an RB wants to operate as transit-only RB, VL/FGL capability can be configured per port or all ports on that RB must be configured to operate in the same mode? I am assuming it is the latter.

Thanks!
--Rajeev

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Olen Stokes
Sent: Tuesday, November 20, 2012 9:08 PM
To: Thomas Narten; Donald Eastlake
Cc: [email-masked]
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Cheers,
Olen

---

From: Radia Perlman <[email-masked]>
Date: Wed, 21 Nov 2012 15:28:33 -0800

I'd think it ought to be possible to have a really simple transit-only RB
R that doesn't bother looking beyond the TRILL header...so doesn't care
what VLAN or FGL it is...R won't do any filtering, but filtering is only an
optimization, except at the edges, where it is mandatory.

Anyway...back to two tags vs a single 24-bit tag...we really have to pick
one and go with it.  Either one works, and although one tag might be a bit
more elegant, I've informally asked some implementers and some of them said
they don't care, and others say they prefer two 12-bit pieces in two tags,
so I vote that we stick with that.

As for the spec...yeah, as people pointed out, there are places where the
spec could be clarified, and we should do that.

Of the combinations possible, which should be described in the spec?

I think FGL+VL, and VL definitely.  And the base spec already describes
VL-only.

We might also want to mention neither FGL nor VL (transit only, no
filtering).

We might also want to mention eventually dropping support for VL, and
allowing a mixture of FGL+VL and FGL-only.  But for simplicity, I think we
should not describe that variant at that point, and only describe (in this
document), FGL+VL and its interoperability with VL-only.

Does anyone have any strong opinions?

Radia

On Wed, Nov 21, 2012 at 11:24 AM, Rajeev Manur <[email-masked]> wrote:

>
> My understanding is we have only 2 modes, VL-mode and FGL-mode (superset
> mode supporting both VL and FGL). I feel it would be useful to add more
> text to clarify the processing/compliance requirements for ingress /
> transit / egress RB contexts separately for each of these two modes. This
> will help implementations they may want to support transit only functions
> and still be compliant.
>
> For example, it is not clear to me when an RB wants to operate as
> transit-only RB, VL/FGL capability can be configured per port or all ports
> on that RB must be configured to operate in the same mode? I am assuming it
> is the latter.
>
> Thanks!
> --Rajeev
>
>
> Olen Stokes

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 21 Nov 2012 20:14:14 -0500

Hi Thomas,

On Tue, Nov 20, 2012 at 7:35 AM, Thomas Narten <[email-masked]>
wrote:
>> > My understanding (from reading the draft earlier today) was that
>> > an RB either operates in FGL mode or VL mode. It doesn't mix and
>> > match. I.e., you don't have an RB with some ports understanding
>> > FGL and others VL.  (To do that, you'd an RB would have to
>> > convert between the the two formats which could result in loss of
>> > information...)

If it's an FGL RBridge, all ports must understand FGL TRILL Data
frames and VL TRILL Data frames. It also may be able to ingress/egress
native frames to/from FGL TRILL Data frames but must be able to
ingress/egress native frames to/from VL TRILL Data frames.

If it's a VL RBridges, all port must understand VL TRILL Data frames
and none of its ports will understand FGL TRILL Data frames. It also
must be able to ingress/egress native frames to/from VL TRILL Data
frames but will be unable to ingress/egress native frames to/from FGL
TRILL Data frames.

>> So what exactly did you think text like the following meant: "An
>>    FGL RBridge MAY be configured, on one or more ports, to ingress
>>    native frame perform the previously specified VL ingress
>>    processing on native frames [RFC6325]."  >
>
> Personally, I thought the wording was somewhat odd, and made a note
> to figure out what the real intention was. :-) Also, "MAY" means
> it's not part of the spec, but not being disallowed either. That is
> not the same thing as saying it is something that implementations
> would want or need to do.

So, I think it should be MAY because the way "FGL RBridge" is used in
this draft, an RBridge that can only correctly transit FGL frames but
can't ingress or egress them still counts as an FGL RBridge. This
would probably be a legacy RBridge of some sort that had been upgraded
and whose silicon can handle transit (perhaps it simplifies the
transit problem by not doing an pruning of multi-destinaiton FGL
frames) but whose silicon isn't up to the additional requirements to
ingress/egress FGL.

>> transit, and egress both VL and FGL frames implies having to
>> "convert" between those formats. The whole idea of data labeling is
>> separation/isolation. Why would you convert between them anymore
>> than you would convert between a random pair of different VLANs?
>
> understands both VL and FGL, that such a mode would only be useful
> if one was converting from one format to the other, or if one fell
> back from from FGL to VL mode if it didn't make sense to operate in
> FGL mode. But I wasn't 100% sure what the draft's intention was...
>

There are no "modes". I think that word is just confusing.

Obviously, you can have a campus of mixed VL and FGL RBridges, just
plug the cables in and there you are. But, as it says in the draft,
the assumption is that, in that situation, you wanted an FGL campus
and there are just a few misconfigured/whatever VL RBridges, so they
are data isolated (but still peer in the control plane). VL RBridges
can only handle VL frames. FGL RBridges handle both.

In the future, some extension of TRILL such as multi-topoogy, may
permit data connectivity between VL and FGL RBridges.

If you update a VL RBridge so that it can do FGL transit, but not FGL
ingress/egress, then it becomes a (limiated) FGL RBridge and is fully
inter connected. Furthermore, end stations attached to such a limited
FGL RBridge can communicate with end stations attached to full FGL
RBridges (ones that can to ingress/egress as well as transit), they
just have to use VL frames for that communication.

> because it is the individual links that operate in a given mode, not

There are no "modes". A link can be just a piece of wire. It can't be
VL or FGL. However, a port can be VL or FGL. Note that the VLAN label
or FG label is hidden inside the frame. If the link happens to be an
Ethernet link, then frames on it can also have an outer VL -- but if
that frame is a TRILL Data frame, this outer VL doesn't have anything
to do with whether the payload inside is VL or FGL or what its label
value is.

>    The usual DRB election operates on a link with mixed FGL and VL
> it seems to mean is that you can deploy TRILL, but get disconnected

Yes. If you want full connectivity and you want to be able to use fine
grained labels, you need all your RBridges to be FGL RBridges (at
least "limited" FGL RBridges as used above).

The assumption is that you want an FGL campus and that any VL RBridges
are isolated misconfigurations. Since VL RBridges cannot safely handle
traffic from FGL RBridges, which might contain FGL frames, the VL and
FGL RBridges can't talk to each other in the data plane. As long as
you have only a few scattered VL RBridges in an FGL campus, things
will work pretty well except that those VL RBridges (and any end
stations attached to them) will be data isolated. (And the inverse is
also true. If you have only a few scattered FGL RBridges in a VL
campus, the FGL RBridges will be data isolated. If you have a random
mix, you're screwed because they cannot safely talk to each other and
connectivity will probably be pretty poor if they are randomly
intermingled.)

> that an operational nightmare that can't be allowed to happen (by

Come on. People all the time assume you update all the switches in
some network simultaneously. Furthermore the mixed VL and FGL RBridges
still have control connectivity so you can see in the limk state
exactly what is going on. The isolation of VL and FGL RBridges is only
for the flow of TRILL Data frames. Sure, you can get an "operational
nightmare" is you grossly misconfigure a TRILL network just like you
can by grossly misconfiguring a wide variety of other networks.

> to intereperate with non FGL-aware RBs? (I think that is a fine thing

Given the assumption is that you want an FGL campus and that any VL
RBridges are isolated misconfigurations, if the presence of one or
more VL RBridges (due to misconfiguriaton) forced a fall back, you
would be screwed. Why is it that you want to break VL handling in FGL
RBridges just because they can handloe FGL? In the future, with a
variety of TRILL extensions, it will be possible to have data
connectivity from legacy VL RBridges to FGL RBridges. One such
extension is multi-topology with one topology for all RBridges and one
for just FGL RBridges. Assuming the FGL RBridges are fully connected
with each other and that you put FGL frames on the FGL topology and VL
frames on the all RBridges topology, everything would work
fine. Another possible extension would be multi-level IS-IS TRILL. As
long as a level 1 area was all VL or all FGL and level 2 was FGL (and
you don't try to heal level 2 partitions by sending frames through a
random level 1) then it will all work fine. And in both cases, end
stations attached to legacy VL RBridge could talk to end stations
attached to FGL RBridges as long as they talk only with VL frames.

>> > And the way to look at VL mode, is that it is the fallback for
>> > the case where not all of the RBs in the compus are FGL capable.
>
>> The word "mode" does not occur anywhere in the body of the
>> draft. FGL RBridges are supersets. FGL RBridges can handle VL
>> frames fine. It is just that VL RBridges can't handle FGL frames
>> and it is very hard to guarantee that an FGL frame will never be
>> routed to a VL RBridge without either multi-topology (which is not
>> yet fully specified for TRILL) or stopping all data flow between VL
>> and FGL RBridges (whcih is what this draft does).
>

"Multi-topology" is not mentioned anywhere in the draft but given this
conversation, it seems essential to mention the possibility of future
enhancements such as multi-topology as the motivation for requiring
FGL RBridges to be capable of handling VL frames. If you are going to
treat FGL and VL frames differently for what is permitted between some
ports on a link, then you pretty much need multi-topology. In
particular, consider the problems of computing distribution trees.

>> > I.e., what is supposed to happen in a campus where some RBs say
>> > they do FGL and others do not? Is the intention that one TRILL
>> > campus gets formed with all nodes falling back to VL mode?
>
>> As stated in the draft, the assumption in that case is that you
>> wanted a completely FGL campus and whatever VL RBridges are present
>> are isolated misconfigurations.
>
> that have both. Accidents can happen, etc. I think we'd be better
> off with very clear ways for the operator to specify what they want
> to have happen in a mixed mode. We can have a default mode, but the

A random mixture of VL and FGL RBridges is not going to work well at
all. A goal of TRILL is to be zero/minimal configuration. It might be
a good idea to have a should/must requirement that FGL RBridges can be
configured to act exactly like a VL RBridge. Then, if you really
wanted a VL campus, you just configure your FGL RBridges to be VL
RBridges. This shouldn't be too hard given that FGL is a superset of
VL.

> want the default mode to be to have the entire TRILL campus to try to

Well, in fact, if you have only few scattered RBridges that are FGL
RBridges, the provisions currently in the draft work fine and data
isolate those FGL RBridges because, at that level, they are
symmetric. Because all they do is disable TRILL Data transfer between
ports on a link if one or more port is on a VL RBridge and the one or
more port is on an FGL RBridge. Everything else works fine including
TRILL Data transfer if all are on VL RBridges or all are on FGL
RBridges. And the TRILL IS-IS control plane works fine no matter which
type of RBridges the ports are on.

If you had, say, one compact area of VL RBridges and another compact
area of FGL RBridges, with links between them, each would work fine
internally, there just wouldn't be any data transfer between them (in
the absence of future TRILL extensions such a multi-topology or
multi-level).

It's only if you have a random mixture of intermingled VL and FGL
RBridges that things really don't work.

>> and FGL RBridges do not peer for data. You don't want the
>> attachment of one RBridge misconfigured to be a VL RBridge to kill
>> your whole FGL campus. You can't "fall back" a port configured for
>> FGL without violating security policy.
>

Deliverying data by egressing to a port not labeled with the VL or FGL
of the data is a violation of security policy. If a port was
configured to ingress VLAN-Y native frames to FGL-X, "falling back" so
the port ingresses them as VLAN-Y would, in general, violate security
policy because they could then be egress through VLAN-Y labeled ports
rather than just FLG-X labeled ports.

> No. The issue isn't terminology.

That's why I said "clarifying text should be added".
.
> The text needs to be clearer what the

I agree that clarification is needed.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 21 Nov 2012 21:55:55 -0500

On Wed, Nov 21, 2012 at 9:09 PM, Xuxiaohu <[email-masked]> wrote:
>
>
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Radia Perlman
> 发送时间: 2012年11月22日 7:29
> 收件人: Rajeev Manur
> 抄送: Thomas Narten; Donald Eastlake; [email-masked]
> I'd think it ought to be possible to have a really simple transit-only RB R
> that doesn't bother looking beyond the TRILL header...so doesn't care what
> VLAN or FGL it is...R won't do any filtering, but filtering is only an
> Does it ought to have another type of transit RB which needs to do filtering
> but can’t do it based on the full FGL due to some reasons (e.g. the lack of
> enough hardware memory capability)? For example, it could do a
> coarse-grained filtering based on partial bits in the FGL. In other words,
> The transit RB could have a flexibility to determine how many bits (0~24) in
> the FGL would be used for filtering.
>
>
>
> Since there is no need to worry about the backwards compatibility anymore,
> could you please explain why others prefer two 12-bit tags to a single
> 24-bit tag?

Already existing silicon.

Thanks,
Donald

> Best regards,
> Xiaohu
> mode supporting both VL and FGL). I feel it would be useful to add more text
> to clarify the processing/compliance requirements for ingress / transit /
> egress RB contexts separately for each of these two modes. This will help
> implementations they may want to support transit only functions and still be
> compliant.
>

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 22 Nov 2012 03:06:55 +0000

发件人: Xuxiaohu
发送时间: 2012年11月22日 10:10
收件人: 'Radia Perlman'; Rajeev Manur
抄送: Thomas Narten; Donald Eastlake; [email-masked]
主题: re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

I'd think it ought to be possible to have a really simple transit-only RB R that doesn't bother looking beyond the TRILL header...so doesn't care what VLAN or FGL it is...R won't do any filtering, but filtering is only an optimization, except at the edges, where it is mandatory.

Does it ought to have another type of transit RB which needs to do filtering but can’t do it based on the full FGL due to some reasons (e.g. the lack of enough hardware memory capability)? For example, it could do a coarse-grained filtering based on partial bits in the FGL. In other words, The transit RB could have a flexibility to determine how many bits (0~24) in the FGL would be used for filtering.

Anyway...back to two tags vs a single 24-bit tag...we really have to pick one and go with it.  Either one works, and although one tag might be a bit more elegant, I've informally asked some implementers and some of them said they don't care, and others say they prefer two 12-bit pieces in two tags, so I vote that we stick with that.

Since there is no need to worry about the backwards compatibility anymore, could you please explain why others prefer two 12-bit tags to a single 24-bit tag?

Best regards,
Xiaohu

As for the spec...yeah, as people pointed out, there are places where the spec could be clarified, and we should do that.

I think FGL+VL, and VL definitely.  And the base spec already describes VL-only.

We might also want to mention neither FGL nor VL (transit only, no filtering).

We might also want to mention eventually dropping support for VL, and allowing a mixture of FGL+VL and FGL-only.  But for simplicity, I think we should not describe that variant at that point, and only describe (in this document), FGL+VL and its interoperability with VL-only.

Radia
On Wed, Nov 21, 2012 at 11:24 AM, Rajeev Manur <[email-masked]<mailto:[email-masked]>> wrote:

Thanks!
--Rajeev

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Olen Stokes
Sent: Tuesday, November 20, 2012 9:08 PM
To: Thomas Narten; Donald Eastlake
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Cheers,
Olen

On 11/20/12 7:35 AM, "Thomas Narten" <[email-masked]<mailto:[email-masked]>> wrote:

>Hi Donald.
>
>Donald Eastlake <[email-masked]<mailto:[email-masked]>> writes:
>
>
>[email-masked]<mailto:[email-masked]>

_______________________________________________
trill mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trill

_______________________________________________
trill mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trill

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 23 Nov 2012 14:39:24 -0500

Hi Phanidhar,

On Tue, Nov 20, 2012 at 2:29 PM, Phanidhar Koganti
<[email-masked]> wrote:
>> Ah.  So the intent is that an FGL RBridge must be able to parse
>> either VL or FGL, which would allow an edge RB that only supports
>> VL to work OK, and to have some number of VLANs (4000 of them) that
>> would be reachable via old edge RBs?  >
>
> <Donald> Yes on parsing. But it is hard to be sure no FGL frame can
> get to a VL RBridge. Say you have VLRB1 connected to the campus
> through FGLRB2.  And FGLRB2 is connected to FGLRB3. What if
> connectivity appears between VLRB1 and FGLRB3 and perhaps the link
> between FGLRB2 and FGLRB3 breaks? How can you stop FGL frames from
> going between FGLRB2 and FGLRB3 via VLRB1 keeping in mind that you
> have to assume no changes in the old VL RBridges? (Without
> multi-topology. With multi-topology, it's relatively easy.)
>
> <Anoop> FGL frames should never be forwarded to an RB that doesn't
> what the capabilities of an RBridge are before forwarding to that
> RBridge begins.  And as a result of this requirement, we should
> probably disallow FGL and non-FGL RBridges being reachable from the
> same RBridge port, otherwise it would be challenging to implement
> this control for multicast frames.

I am not sure what you mean by "disallow" but if some physical
topology is trivially realizable by someone plugging in the wrong
cables, you have to take it into account and say what happens. In this
case, where FGL and non-FGL RBridges are on the same link, the FGL
RBridges just refuse to report any adjacencies on the link, thus
excommunicating the link for TRILL Data traffic.

> [Phanidhar Koganti] Does this mean non-FGL RBridges cannot act as
> transit nodes? Why can’t the transit nodes just rely on TRILL SA/DA
> to forward.  Agree there will be issues for multicast in terms of
> the optimal pruned forwarding as a non-FGL RB will not have access
> to the inner IP header or VLAN (FGL based). However isn’t this an
> optimization for multicast pruning?  The transit RBs can forward
> based on the non-pruned multicast tree.

If an RBridge has been modified from existing legacy VL RBridge so
that you can safely use it as a transit node, then it *is* an FGL
RBridge (even if it is a limited FGL RBridge that can't do FGL ingress
and egress). If it has not been so modified, then it remains a VL
RBridge and will likely mishandle or discard and FGL frames it
receives.

>> <Radia> And we're assuming that old edge RBs that only do VL will
>> know to drop something tagged with FGL?

I believe they should but it does not seem wise to depend on that.

> <Donald> A VL RBridge should, in my opinion, drop an FGL frame based
> on RFC 6325. However, if it did not, it would presumably mean it was
> ignoring the 0x893B value where it should be requiring 0x8100. As a
> result, it would believe the FGL frame was in some VLAN and might
> egress it to the wrong end-stations, violating security policy.
>
> <Anoop> We need to make the spec clear on this aspect; i.e. FGL or
> non-FGL RBridges must discard a received frame if the inner tag (FGL
> or VLAN depending on what mode the port is operating in) is absent.

In the draft, ports have an FGL/VL configuration "mode" for
ingressing/egressing native frames but that don't have any "mode" for
TRILL Data frames. If they are a VL RBridge, they can only handle VL
TRILL Data frames. If they are an FGL RBridge, the can handle both VL
and FGL TRILL Data frames.

Thanks,
Donald

---

From: Phanidhar Koganti <[email-masked]>
Date: Fri, 23 Nov 2012 18:10:21 -0800

Hi Donald,

Please see below inline

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Saturday, November 24, 2012 1:09 AM
To: Phanidhar Koganti
Cc: Anoop Ghanwani; [email-masked]
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Hi Phanidhar,

On Tue, Nov 20, 2012 at 2:29 PM, Phanidhar Koganti <[email-masked]> wrote:
>> either VL or FGL, which would allow an edge RB that only supports VL 
>> to work OK, and to have some number of VLANs (4000 of them) that 
> support FGL.  This is easy to figure out since IS-IS can tell us what 
> the capabilities of an RBridge are before forwarding to that RBridge 
> begins.  And as a result of this requirement, we should probably 
> disallow FGL and non-FGL RBridges being reachable from the same 
> RBridge port, otherwise it would be challenging to implement this 
> control for multicast frames.

I am not sure what you mean by "disallow" but if some physical topology is trivially realizable by someone plugging in the wrong cables, you have to take it into account and say what happens. In this case, where FGL and non-FGL RBridges are on the same link, the FGL RBridges just refuse to report any adjacencies on the link, thus excommunicating the link for TRILL Data traffic.

> transit nodes? Why can't the transit nodes just rely on TRILL SA/DA to 
> forward.  Agree there will be issues for multicast in terms of the 
> optimal pruned forwarding as a non-FGL RB will not have access to the 
> inner IP header or VLAN (FGL based). However isn't this an 
> optimization for multicast pruning?  The transit RBs can forward based 
> on the non-pruned multicast tree.

If an RBridge has been modified from existing legacy VL RBridge so that you can safely use it as a transit node, then it *is* an FGL RBridge (even if it is a limited FGL RBridge that can't do FGL ingress and egress). If it has not been so modified, then it remains a VL RBridge and will likely mishandle or discard and FGL frames it receives.
[Phanidhar Koganti] Understand and my concern is to strictly state that a VL only RBridge will never become a transit RB. There can be deployments where customers might want to reuse their older hardware for transit only where table sizes or VLAN aware might not be necessary. The transit VL-RBs need not have any non-TRILL ports. 

>> know to drop something tagged with FGL?
[Phanidhar Koganti] Yes or there are no non-TRILL ports so the VL-RB is only a pure transit RB.

I believe they should but it does not seem wise to depend on that.
[Phanidhar Koganti] True we cannot generalize and make such assumptions but on the goal to fit into existing VL-RB environments, should we not give some room for VL only RB hardwares that are potentially capable of such selective drops? 

> or VLAN depending on what mode the port is operating in) is absent.

In the draft, ports have an FGL/VL configuration "mode" for ingressing/egressing native frames but that don't have any "mode" for TRILL Data frames. If they are a VL RBridge, they can only handle VL TRILL Data frames. If they are an FGL RBridge, the can handle both VL and FGL TRILL Data frames.

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

---

From: Tal Mizrahi <[email-masked]>
Date: Sat, 24 Nov 2012 07:48:02 +0200

Support.
(sorry for late response).

Tal.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Tuesday, November 06, 2012 10:43 PM
To: [email-masked]
Subject: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Hi,

As announced at the TRILL WG meeting today, this starts a two week WG Last Call on draft-ietf-trill-fine-labeling ending 19 November.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA  [email-masked] _______________________________________________
trill mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trill

---

From: Olen Stokes <[email-masked]>
Date: Mon, 26 Nov 2012 07:09:10 -0800

>From Donald below:

"If an RBridge has been modified from existing legacy VL RBridge so that you can safely use it as a transit node, then it *is* an FGL RBridge (even if it is a limited FGL RBridge that can't do FGL ingress and egress). If it has not been so modified, then it remains a VL RBridge and will likely mishandle or discard and FGL frames it receives."

We seem to be moving in the direction where RBridges with differing capabilities are all considered to be FGL RBridges.  Do we need to consider advertising the differences in capabilities in the ISIS extensions for FGL?  

Cheers,
Olen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Friday, November 23, 2012 2:39 PM
To: Phanidhar Koganti
Cc: Anoop Ghanwani; [email-masked]
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Hi Phanidhar,

Thanks,
Donald

---

From: Olen Stokes <[email-masked]>
Date: Mon, 26 Nov 2012 07:31:41 -0800

Since the two emails below were written about a week ago, there has been a lot of discussion about the RBridge capabilities required to be classified as an FGL RBridge.  I am still unclear about one part of the exchange below.

There is a discussion about the implications of a TRILL ingress RBridge serially unicasting "a multi-destination TRILL Data frame to the relevant egress TRILL switches after encapsulating it as a TRILL known unicast data frame (M=0)". 

What is the use case envisioned when there is more than one "relevant egress FGL RBridge"?

FWIW, Donald noted below that this provision has been in all of the previous versions.  I agree.  I did not mean to imply otherwise. 

Cheers,
Olen

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Monday, November 19, 2012 8:19 PM
To: Olen Stokes
Cc: [email-masked]
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Hi Olen,

I agree.

> opportunities to more clearly state some of the implications of the 

I don't think there are any inconsistencies. However, it is certainly possible that some clarifications and/or editorial changes would improve the draft.

> packets with a VL RBridge.

Yes, an FGL RBridge must support Fine Grained Labeling (FGL) and support VLAN Labeling (VL) as the inner data label. In other words, an FGL RBridge must be able to ingress a native frame to an FGL TRILL data frame, handle an FGL TRILL data frame as a transit switch, and egress an FGL TRILL data frame to a native frame. In addition, an FGL RBridge must be able to ingress a native frame to a VL TRILL data frame, handle a VL TRILL data frame as a transit switch, and egress a VL TRILL data frame as a native frame, all this VL stuff as described in the TRILL base protocol RFC 6325.

So an FGL RBridge can safely handle VL data traffic. But if you give an FGL data frame to a VL RBridge, it is very likely to be mishandled.
This problem with VL RBridges, which by definition are FGL ignorant, is the reason for not allowing TRILL data traffic between FGL and VL RBridges.

> operation, a specific statement to that effect would be appropriate.

The current FGL draft, just like all previous versions of the FGL WG and preceeding personal draft, does require support of VL by FGL RBridges. Since you specifically talk about -01 to -02 changes, you might not it is not a change that just appeared in the current version.

> ingress/egress point of view.  It does not discuss it from a transit 

Good point, transit processing should be mentioned briefly in Section 7, Item 2. However, the items in Section 7 are parallel with the same number items in Section 2.1 and are just intended to discuss the extent to which the goals in 2.1 are met, not to be a complete discussion or summary of the named topics... Perhpas "Silicon Considerations" should be replaced with "Silicon Goal".

> could have important effects on how existing silicon could be used for 
> transit FGL RBridge operation.  Section 5.1 states:
>
> "An FGL ingress RBridge MAY serially TRILL unicast a multi-destination 
> TRILL Data frame to the relevant egress TRILL switches after 
> encapsulating it as a TRILL known unicast data frame (M=0)".
>
> packets to operate as a TRILL transit FGL node regardless of whether 
> it can TRILL forward FGL multi-destination packets.  If that is the 

Your statement seems a odd to me.  I don't understand what you mean when you say "regardless of whether it can TRILL forward FGL multi-destination packets". If it can't do that, I don't think it is an FGL RBridge.

An FGL RBridge is required to be able to forward known unicast data that is TRILL unicast (M=0), multi-destination data that is TRILL multicast (M=1), and, due to the text you quote, multi-destination data that is TRILL unicast (M=0).  Since your specifically talk about
-01 to -02 changes, you might note that this has been required in all previous versions of the FGL WG draft and preceeding personal draft.
It is not a change that just appeared in the current -02 version.

> intent, it would be helpful to state that in Section 7, Item 2.

Pruning is a SHOULD in the base TRILL protocol standard and it is the same here. The provisions here are similar to those in the base standard for VL pruning. I don't see any problem adding something to clarify although I don't think Section 7, Item 2, is the best place.
How about just adding, at the end of the last sentence in Section 5.2.2, the following words "or not prune FGL frames at all"?

> the Low Part of a FGL.  A statement about silicon that can prune based 
> only on half of a FGL would also be helpful in Section 7, Item 2.

But the whole point is that, since pruning is just a SHOULD optimization, the silicon could prune on whatever subset of FGL bits it feels like and still be conformant. For example, it could prune on just the highest order bit or just the highest order byte of the FGL or something. How about, including the addition above, changing

"For example, a transit TRILL switch could prune based on only part of the FGL such as only the High Part or only the Low Part."

to

"A transit TRILL switch could prune based on an arbitrary subset of the FGL label bits, such as only the High Part or only the Low Part, or not prune FGL frames at all."

Actually an RBridge could adopte even more strange or exotic pruning methods, although I can't see why it would want to. For example, it could prune based on the data label value modulo some arbitrary integer divisor less than the maximum label value...sort of a ridiculous thing to do but frames would still be routed correctly so I believe such behavior is allowed.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 27 Nov 2012 21:59:52 -0500

HI Olen,

> What is the use case envisioned when there is more than one "relevant egress FGL RBridge"?

We are talking about multi-destination TRILL Data frames. That is,
frames where the Inner.MacDA is the broadcast address, a multicast
address, or a unicast address who egress TRILL switch is unknown to
the ingress TRILL switch. In such cases, all TRILL switches indicating
interest in the frame's VLAN are potentially relevant although in the
multicast case this should be further limited to TRILL switches where
a listener for the multicast group or a multicast router is attached.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 27 Nov 2012 22:00:51 -0500

Hi Olen,

> We seem to be moving in the direction where RBridges with differing capabilities are all considered to be FGL RBridges.  Do we need to consider advertising the differences in capabilities in the IS…

I don't think so in this case.

It seems to me that there isn't a need to distinguish a limited FGL
TRILL switch (FGL transit only) from a full FGL TRILL switch (FGL
ingress, transit, and egress) in the link state. A port doesn't
ingress to FGL unless it is configured to do so and you can't
configure a port of a limited FGL TRILL switch that way. And an FGL
TRILL Data frame can't be egressed at a port unless the port is
labeled with the same FGL label as the frame which can't be done with
a limited FLG TRILL switch.

Thanks,
Donald

---

From: Olen Stokes <[email-masked]>
Date: Wed, 28 Nov 2012 07:38:41 -0800

Thanks.  I understand that.  I am trying to understand under what circumstances it is being proposed that multiple unicast packets be sent instead of a single multi-destination packet?  In other words, **WHY** would an RBridge use this unicast method rather than use the existing multi-destination D-Tree method?

Cheers,
Olen

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Tuesday, November 27, 2012 10:00 PM
To: Olen Stokes
Cc: [email-masked]
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

HI Olen,

> What is the use case envisioned when there is more than one "relevant egress FGL RBridge"?

We are talking about multi-destination TRILL Data frames. That is, frames where the Inner.MacDA is the broadcast address, a multicast address, or a unicast address who egress TRILL switch is unknown to the ingress TRILL switch. In such cases, all TRILL switches indicating interest in the frame's VLAN are potentially relevant although in the multicast case this should be further limited to TRILL switches where a listener for the multicast group or a multicast router is attached.

Thanks,
Donald

>> RBridge port is VL.  A scenario where this is utilized would also be helpful.
>
>> switches after encapsulating it as a TRILL known unicast data frame (M=0)".
>>
>> based only on half of a FGL would also be helpful in Section 7, Item 2.
>

---

From: Thomas Narten <[email-masked]>
Date: Wed, 28 Nov 2012 10:53:10 -0500

Olen's original comment was about the following text in the document:

> it as a TRILL known unicast data frame (M=0)".

Does the base TRILL spec forbid the above behavior? 

Is this sentence even needed? Can we just remove it? (FWIW, it seems
to me to be unnecessary.)

Thomas

---

From: Radia Perlman <[email-masked]>
Date: Thu, 29 Nov 2012 01:48:46 +0100

Even if the base spec doesn't preclude doing serial unicast, it might be
worth mentioning the possiblity here because if there is a huge campus with
so many different FGLs in use that the inner RBridges have trouble
filtering, and there's only a few edge guys participating in the FGL, it
might wind up being more optimal for the ingress switch to do serial
unicast.  So saying MAY just gives an implementer the hint that it might be
a good thing to allow.

At any rate, I don't think it hurts to have that sentence in the FGL spec.

Radia

On Wed, Nov 28, 2012 at 4:53 PM, Thomas Narten <[email-masked]> wrote:

> encapsulating

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 28 Nov 2012 23:19:11 -0500

Hi,

In addition to Radia's comment about reducing pruning state, see below:

On Wed, Nov 28, 2012 at 10:38 AM, Olen Stokes
<[email-masked]> wrote:
>
> Thanks.  I understand that.  I am trying to understand under what
> circumstances it is being proposed that multiple unicast packets be
> sent instead of a single multi-destination packet?  In other words,
> **WHY** would an RBridge use this unicast method rather than use the
> existing multi-destination D-Tree method?

Consider a large TRILL campus in which, say, 100 end stations are in
some particular FGL data label.

At one extreme, if all 100 end stations were attached to a single
TRILL switch, then no other TRILL switch would be advertising interest
in that FGL and likely a multidestination (say broadcast) frame from
one such end station would, even if put on a distribution tree,
because of pruning, not get sent any another TRILL switch.

At the other extreme, assume the 100 end stations are attached, one
each, to 100 different end stations; in that case you are almost
certainly better off using a distribution tree because if you tried to
serially unicast you would cause much higher link utilitization,
probably have to output some multiple copies through the same port,
etc.

But what if these 100 end stations are connected to exactly two TRILL
switches, say 75 to one and 25 to the other. Using unicast TRILL Data
frames between these TRILL switches is better because they will follow
least cost paths, possibly with such traffic spread over an arbitrary
number of equal cost least cost paths. On the other hand, if one or
more distribution trees were used, each frame would be constrained to
the tree used for that frame and would likely follow a more circuitous
route, depending on where the tree roots are. That's why the draft
says "SHOULD" use unicast if there exactly two TRILL switches involed.

It's a more complex decision whether to use a distribution tree or
serial unicast if the end stations are connected to a "small" number
of TRILL switches greater than two. So the draft just says "MAY" in
that case.

> Does the base TRILL spec forbid the above behavior?

While I do not think it has a statement explicitly prohibiting such
behavior, it implicitly prohibits it by mandating that
multidestination frames be encoded into TRILL Data frames with a TRILL
Header having M=1 and sent on the distribution tree indicated by the
egress nickname.

There is also the corresponding egress statement that requires FGL
TRILL switches to be able to egress such multi-destination inner
frames encoded with M=0:

"FGL TRILL switches MUST accept multi-destination TRILL Data frames
that are sent to them as TRILL unicast frames, that is, frames that
may have a multicast or broadcast Inner.MacDA (or are being sent to an
unknown unicast Inner.MacDA) and the TRILL Header M bit = 0."

(Actually, the current standard in effect requires all TRILL switches
to be able to egress unknown unicast frames when encoded that
way. That's because a destination MAC and VLAN can be known to the
ingress TRILL switch, which then encodes the TRILL Data frame with M=0
and unicasts it to the egress, but then turn out to be unknown to that
egress switch because its tables of attached MACs have overflowed or
the entry has timds out or it has re-booted or whatever.)

> to me to be unnecessary.)

What do you mean by "needed"? It is an intentional change in TRILL; as
such it does something, causing significant improvement in some cases
as in my response to Olen above. But it is just a matter of efficiency
so FGL TRILL would still work without it.

Thanks,
Donald

---

From: Thomas Narten <[email-masked]>
Date: Thu, 29 Nov 2012 10:45:00 -0500

I think it is clear that there are circumstances where using unicast
rather than multicast would be a useful optimization. What the
document would benefit from is text explaining where that might be
useful and making it clear that implementations might want to do that
- as an optimization under appropriate circumstances. It doesn't have
that background, just a couple of MAY/SHOULD statements. Taking some
of the explanation in this email thread and putting it into the
document would probably help clarify the intent.

I suggested pulling out the text because it was apparently confusing,
and I didn't think it was necessary. There are lots of optimizations a
product might make besides this one. The document surely doesn't aim
to cover them all.

Thomas

---

From: Olen Stokes <[email-masked]>
Date: Thu, 29 Nov 2012 08:20:37 -0800

It would seem that in order for an "inner" or transit-only RBridge to improve its scaling by not including the "filtering" for a certain FGL, it would have to either:

1)      Know which FGLs are being sent using multi-destination packets and which are being sent using multiple unicast packets, or

2)      Use a cache driven design which traps on unknown FGL labels and installs "filtering" only when a FGL is seen for the first time.  This approach also opens up the discussion about knowing when to remove inactive "filters".

I believe that the Interested Labels and Spanning Tree Roots sub-TLV in RFC6326bis should use a reserved bit to indicate whether multi-destination packets or multiple unicast packets will be used with the indicated label(s).

Cheers,
Olen

From: Radia Perlman [mailto:[email-masked]]
Sent: Wednesday, November 28, 2012 7:49 PM
To: Thomas Narten
Cc: Olen Stokes; Donald Eastlake; [email-masked]
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Even if the base spec doesn't preclude doing serial unicast, it might be worth mentioning the possiblity here because if there is a huge campus with so many different FGLs in use that the inner RBridges have trouble filtering, and there's only a few edge guys participating in the FGL, it might wind up being more optimal for the ingress switch to do serial unicast.  So saying MAY just gives an implementer the hint that it might be a good thing to allow.

Radia

On Wed, Nov 28, 2012 at 4:53 PM, Thomas Narten <[email-masked]<mailto:[email-masked]>> wrote:

Thomas

---

From: Olen Stokes <[email-masked]>
Date: Thu, 29 Nov 2012 08:53:49 -0800

I am not opposed to the concept, but it does seem to violate the base protocol.  I believe that Section 4.6.2.4 of RFC 6325 would tell an egress VL RBridge to discard such a packet.  Given that a FGL RBridge is supposed to be able to forward both VL and FGL packets, should the description indicate that this behavior is to be used only with FGL packets?

I agree with Tom that this example should be included in the draft.  

Cheers,
Olen

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Wednesday, November 28, 2012 11:19 PM
To: Thomas Narten; Olen Stokes
Cc: [email-masked]
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Hi,

> existing multi-destination D-Tree method?

Consider a large TRILL campus in which, say, 100 end stations are in some particular FGL data label.

At one extreme, if all 100 end stations were attached to a single TRILL switch, then no other TRILL switch would be advertising interest in that FGL and likely a multidestination (say broadcast) frame from one such end station would, even if put on a distribution tree, because of pruning, not get sent any another TRILL switch.

At the other extreme, assume the 100 end stations are attached, one each, to 100 different end stations; in that case you are almost certainly better off using a distribution tree because if you tried to serially unicast you would cause much higher link utilitization, probably have to output some multiple copies through the same port, etc.

But what if these 100 end stations are connected to exactly two TRILL switches, say 75 to one and 25 to the other. Using unicast TRILL Data frames between these TRILL switches is better because they will follow least cost paths, possibly with such traffic spread over an arbitrary number of equal cost least cost paths. On the other hand, if one or more distribution trees were used, each frame would be constrained to the tree used for that frame and would likely follow a more circuitous route, depending on where the tree roots are. That's why the draft says "SHOULD" use unicast if there exactly two TRILL switches involed.

It's a more complex decision whether to use a distribution tree or serial unicast if the end stations are connected to a "small" number of TRILL switches greater than two. So the draft just says "MAY" in that case.

> Does the base TRILL spec forbid the above behavior?

While I do not think it has a statement explicitly prohibiting such behavior, it implicitly prohibits it by mandating that multidestination frames be encoded into TRILL Data frames with a TRILL Header having M=1 and sent on the distribution tree indicated by the egress nickname.

There is also the corresponding egress statement that requires FGL TRILL switches to be able to egress such multi-destination inner frames encoded with M=0:

"FGL TRILL switches MUST accept multi-destination TRILL Data frames that are sent to them as TRILL unicast frames, that is, frames that may have a multicast or broadcast Inner.MacDA (or are being sent to an unknown unicast Inner.MacDA) and the TRILL Header M bit = 0."

(Actually, the current standard in effect requires all TRILL switches to be able to egress unknown unicast frames when encoded that way. That's because a destination MAC and VLAN can be known to the ingress TRILL switch, which then encodes the TRILL Data frame with M=0 and unicasts it to the egress, but then turn out to be unknown to that egress switch because its tables of attached MACs have overflowed or the entry has timds out or it has re-booted or whatever.)

> to me to be unnecessary.)

What do you mean by "needed"? It is an intentional change in TRILL; as such it does something, causing significant improvement in some cases as in my response to Olen above. But it is just a matter of efficiency so FGL TRILL would still work without it.

Thanks,
Donald

On Wed, Nov 28, 2012 at 7:48 PM, Radia Perlman <[email-masked]> wrote:
> Even if the base spec doesn't preclude doing serial unicast, it might 
> be worth mentioning the possiblity here because if there is a huge 
> campus with so many different FGLs in use that the inner RBridges have 
> trouble filtering, and there's only a few edge guys participating in 
> the FGL, it might wind up being more optimal for the ingress switch to 
> do serial unicast.  So saying MAY just gives an implementer the hint 
> that it might be a good thing to allow.
>

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 30 Nov 2012 00:27:52 -0500

Hi Olen,

On Thu, Nov 29, 2012 at 11:53 AM, Olen Stokes
<[email-masked]> wrote:
> I am not opposed to the concept, but it does seem to violate the base protocol.

That's right. Anything that changes the base protocol "violates"
provisions of the base protocol. Saying that 0x893B can occur after
the Inner.MacSA violates the base protocol specification. That's a
common purpose of drafts that update or replace earlier documents. The
upper left of the title page of this draft says it updates RFC 6325.

However, I do think of FGL capabilities as optional. If it is not
clear in the draft, a statement should be added that a VL TRILL switch
conformant to RFC 6325 (as updated by RFC 6327 and the Clarifications
and Corrections draft) is still a valid implementation of the TRILL
protocol.

> I believe that Section 4.6.2.4 of RFC 6325 would tell an egress VL RBridge to discard such a packet.

Correct with the exception, as I pointed out in a previous message, if
the Inner.MacDA was unicast because the multi-destination frame being
serially unicast was an unknown unicast frame.

> Given that a FGL RBridge is supposed to be able to forward both VL and FGL packets, should the description indicate that this behavior is to be used only with FGL packets?

Given that this is an FGL draft, it would be reasonable to make that
clear. The provisions are in sub-sections that are about ingressing,
transiting, and egressing FGL TRILL data frames.

> I agree with Tom that this example should be included in the draft.

I have no problem with adding some material along those lines, but not
a lot of material.

It seems to me that the decision whether to use a distribution tree or
to serially unicast, in cases where there is more than one destination
TRILL switch, and the basis for such a decision should be beyond the
scope of this draft. Similar examples are the decision of which TRILL
switches, if any, to designate as appointed forwarders for which VLANs
on a link or where to configure roots for your distribution trees are
decisions outside the scope of the TRILL standard. Because the number
of factors that could influence making such decisions in an optimal
way is essentially unbounded and could extend to specific knowledge of
application behavior on specific data sets and the like.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 30 Nov 2012 00:31:55 -0500

Hi Olen,

On Thu, Nov 29, 2012 at 11:20 AM, Olen Stokes
<[email-masked]> wrote:
> It would seem that in order for an “inner” or transit-only RBridge
> to improve its scaling by not including the “filtering” for a
> certain FGL, it would have to either:

I prefer calling it "pruning", the term that, I believe, is
consistently used in the TRILL standard documents, rather than
"filtering" which may have other meanings to some people. Note that
this aspect of optimization is not something I brought up in
connection with serial unicast but something that Radia brought up. I
think it is justified based on link utilization, traffic spreading,
and latency considerations but saving on pruning state at transit
TRILL switches is an additional justification which, as you point out
below, probably requires some additional mechanism.

> 1)      Know which FGLs are being sent using multi-destination packets and
> which are being sent using multiple unicast packets, or
>
> 2)      Use a cache driven design which traps on unknown FGL labels and
> installs “filtering” only when a FGL is seen for the first time.  This
> approach also opens up the discussion about knowing when to remove inactive
> “filters”.

Technique 2 seems way too complex to me.

Technique 1 is the way I have been thinking about doing it but
requires per data label announcement of whether serial multicast is
being used for multi-destination traffic and/or per data label
announcement by some elected TRILL switch for a data label that all
TRILL switches MUST use serial multi-cast for multi-destination for
the data label or the like.

> I believe that the Interested Labels and Spanning Tree Roots sub-TLV
> in RFC6326bis should use a reserved bit to indicate whether
> multi-destination packets or multiple unicast packets will be used
> with the indicated label(s).

Exactly. That's the right place for capability/command information for
this sort of thing for FGL and the Interested VLANs sub-TLV for VL
data labels.

You also want to prune the set of serial unicast transmissions to be
made at the source so each possible source for the data label needs to
know the multicast listener situation. But it is wasteful of link
state space to flood that information everywhere. So you want to
distribute it through ESADI if all the TRILL switches interested in a
data label are capable of serial unicast and ESADI participants for
that data label.

So my inclination is to put little about this in the FGL draft and
most of this into the ESDAI draft. The current ESADI draft already has
material in it about a capability bit for serially unicasting ESADI
PDUs which could be generalized to a broader capability for serially
unicating multi-destination frames.

Since the FGL draft is about FGL, I think the best it should do is as
it presently does: FLG TRILL switches MUST be able to receive serially
unicast multi-destination FGL frames, MAY transmit such frames, and
SHOULD so transmit multi-destination frames if there is only one
relevant destination TRILL switch.

Thanks,
Donald

---

From: Olen Stokes <[email-masked]>
Date: Fri, 30 Nov 2012 12:42:36 -0800

No hang-ups on "pruning" versus "filtering".  I just wanted to use the same term as Radia had used since I was responding to her email.

>From below:

>"Technique 1 is the way I have been thinking about doing it but requires per data label announcement of whether serial multicast is being used for multi->destination traffic and/or per data label announcement by some elected TRILL switch for a data label that all TRILL switches MUST use serial multi-cast for >multi-destination for the data label or the like."

It would seem possible that each edge RBridge could use a unique/different algorithm to determine whether or not it should serially send multi-destination traffic.  Therefore, to me, the indication that we are discussing is one that says that a particular edge RBridge is currently using serial transmission.  In other words, it says that it **IS** using serial transmissions as opposed to saying that it **CAN**use serial transmission.  

An individual transit RBridge could then optimize its pruning resources by detecting whether any edge RBridge has indicated interest in a FGL and has also indicated that it is not using serial transmission of multi-destination packets.  This would avoid having to elect a RBridge for controlling the transmission technique to be used for a particular FGL (as well as what to do when the elected RBridge disappears).

Based on your discussion, as the number of RBridges interested in a FGL increases, one or more edge RBridges may decide to switch from serial transmission to the use of normal D-Tree multi-destination transmission.  At that point they would change their usage indication.  The transit RBridges would have to detect the change in settings and react accordingly.

Cheers,
Olen

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Friday, November 30, 2012 12:32 AM
To: Olen Stokes
Cc: [email-masked]
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Hi Olen,

On Thu, Nov 29, 2012 at 11:20 AM, Olen Stokes <[email-masked]> wrote:
> It would seem that in order for an "inner" or transit-only RBridge to 
> improve its scaling by not including the "filtering" for a certain 
> FGL, it would have to either:

I prefer calling it "pruning", the term that, I believe, is consistently used in the TRILL standard documents, rather than "filtering" which may have other meanings to some people. Note that this aspect of optimization is not something I brought up in connection with serial unicast but something that Radia brought up. I think it is justified based on link utilization, traffic spreading, and latency considerations but saving on pruning state at transit TRILL switches is an additional justification which, as you point out below, probably requires some additional mechanism.

> installs "filtering" only when a FGL is seen for the first time.  This 
> approach also opens up the discussion about knowing when to remove 
> inactive "filters".

Technique 1 is the way I have been thinking about doing it but requires per data label announcement of whether serial multicast is being used for multi-destination traffic and/or per data label announcement by some elected TRILL switch for a data label that all TRILL switches MUST use serial multi-cast for multi-destination for the data label or the like.

> with the indicated label(s).

Exactly. That's the right place for capability/command information for this sort of thing for FGL and the Interested VLANs sub-TLV for VL data labels.

You also want to prune the set of serial unicast transmissions to be made at the source so each possible source for the data label needs to know the multicast listener situation. But it is wasteful of link state space to flood that information everywhere. So you want to distribute it through ESADI if all the TRILL switches interested in a data label are capable of serial unicast and ESADI participants for that data label.

So my inclination is to put little about this in the FGL draft and most of this into the ESDAI draft. The current ESADI draft already has material in it about a capability bit for serially unicasting ESADI PDUs which could be generalized to a broader capability for serially unicating multi-destination frames.

Since the FGL draft is about FGL, I think the best it should do is as it presently does: FLG TRILL switches MUST be able to receive serially unicast multi-destination FGL frames, MAY transmit such frames, and SHOULD so transmit multi-destination frames if there is only one relevant destination TRILL switch.

Thanks,
Donald

---

From: Radia Perlman <[email-masked]>
Date: Fri, 30 Nov 2012 23:23:58 +0100

So I think Olen, you are saying that it's useful for an edge RB in FGL #x
to say "I'm planning on using serial unicast when transmitting to FGL #x.
If all the edge RBs in FGL x say that, then the core RBs don't have to
bother storing pruning state about FGL x, since they will never see
multidestination frames for FGL x.  I don;'t think the draft currently says
that, and it does sound useful.

Another topic...suppose a transit RB ignores all tags on unicast...in other
words, it forwards based solely on the "egress nickname" in the TRILL
header...then it seems like it ought to be able to work fine for FGLs that
are transmitted as serial unicast. I'd assume all RBs behave that way today
(not looking for VLAN tags inside when forwarding TRILL unicast). So it
might be another strategy for mixed VL/FGL campuses for FGL edge RBs to
MUST serial unicast if there are any transit VL RBs.

And furthermore, if an implementation of a transit RB were to be "lazy"
about pruning, and not bother looking for VLAN tags, and only transmit on
the tree, then it ought to work fine as a transit RB, even if it doesn't
know how to parse FGL. Might there be implementations that could more
trivially be upgraded to indicate this behavior than to be upgraded to
parse FGL?

Or if it looked for a VLAN tag, couldn't find it (because there was an
FGL), and it decides, because it sees this weird unknown tag, to forward it
anyway rather than drop it, then it also would work fine as a transit RB.
Do we know how current VL implementations behave if they can't find a VLAN
tag?  If they all happen to behave in this way (forward frames with no VLAN
tag on the tree), then again, it seems like we can say it's fine to have VL
RBs as transit.

I suppose if it's trivial to upgrade all the current RBs to parse FGL, then
it probably doesn't matter...

Radia

On Fri, Nov 30, 2012 at 9:42 PM, Olen Stokes <[email-masked]>wrote:

> No hang-ups on "pruning" versus "filtering".  I just wanted to use the
> same term as Radia had used since I was responding to her email.
>
> From below:
>
> >"Technique 1 is the way I have been thinking about doing it but requires
> per data label announcement of whether serial multicast is being used for
> multi->destination traffic and/or per data label announcement by some
> elected TRILL switch for a data label that all TRILL switches MUST use
> serial multi-cast for >multi-destination for the data label or the like."
>
> It would seem possible that each edge RBridge could use a unique/different
> algorithm to determine whether or not it should serially send
> multi-destination traffic.  Therefore, to me, the indication that we are
> discussing is one that says that a particular edge RBridge is currently
> using serial transmission.  In other words, it says that it **IS** using
> serial transmissions as opposed to saying that it **CAN**use serial
> transmission.
>
> An individual transit RBridge could then optimize its pruning resources by
> detecting whether any edge RBridge has indicated interest in a FGL and has
> also indicated that it is not using serial transmission of
> multi-destination packets.  This would avoid having to elect a RBridge for
> controlling the transmission technique to be used for a particular FGL (as
> well as what to do when the elected RBridge disappears).
>
> Based on your discussion, as the number of RBridges interested in a FGL
> increases, one or more edge RBridges may decide to switch from serial
> transmission to the use of normal D-Tree multi-destination transmission.
>  At that point they would change their usage indication.  The transit
> RBridges would have to detect the change in settings and react accordingly.
>
> Cheers,
> Olen
>
>
> I prefer calling it "pruning", the term that, I believe, is consistently
> used in the TRILL standard documents, rather than "filtering" which may
> have other meanings to some people. Note that this aspect of optimization
> is not something I brought up in connection with serial unicast but
> something that Radia brought up. I think it is justified based on link
> utilization, traffic spreading, and latency considerations but saving on
> pruning state at transit TRILL switches is an additional justification
> which, as you point out below, probably requires some additional mechanism.
>
> Technique 1 is the way I have been thinking about doing it but requires
> per data label announcement of whether serial multicast is being used for
> multi-destination traffic and/or per data label announcement by some
> elected TRILL switch for a data label that all TRILL switches MUST use
> serial multi-cast for multi-destination for the data label or the like.
>
> this sort of thing for FGL and the Interested VLANs sub-TLV for VL data
> labels.
>
> You also want to prune the set of serial unicast transmissions to be made
> at the source so each possible source for the data label needs to know the
> multicast listener situation. But it is wasteful of link state space to
> flood that information everywhere. So you want to distribute it through
> ESADI if all the TRILL switches interested in a data label are capable of
> serial unicast and ESADI participants for that data label.
>
> So my inclination is to put little about this in the FGL draft and most of
> this into the ESDAI draft. The current ESADI draft already has material in
> it about a capability bit for serially unicasting ESADI PDUs which could be
> generalized to a broader capability for serially unicating
> multi-destination frames.
>
> Since the FGL draft is about FGL, I think the best it should do is as it
> presently does: FLG TRILL switches MUST be able to receive serially unicast
> multi-destination FGL frames, MAY transmit such frames, and SHOULD so
> transmit multi-destination frames if there is only one relevant destination
> TRILL switch.
>
> Thanks,
> Donald