From d3e3e3 at gmail.com  Mon May  3 06:49:45 2010
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 3 May 2010 09:49:45 -0400
Subject: [rbridge] Fwd: question on draft-ietf-trill-rbridge-protocol-16
In-Reply-To: <m2l1028365c1005021438h5957bcb2l8edc9f2c9bcb434d@mail.gmail.com>
References: <309002C0DA137042828828FC53D7A93491B85B6946@IL-MB01.marvell.com>
	<m2l1028365c1005021438h5957bcb2l8edc9f2c9bcb434d@mail.gmail.com>
Message-ID: <r2j1028365c1005030649p77a8bc73r70cf1a8a224746af@mail.gmail.com>

The following may be useful. Forwarded with permission and anonymized as
requested:

---------- Forwarded message ----------
From: Donald Eastlake <d3e3e3 at gmail.com>
Date: Sun, May 2, 2010 at 5:38 PM
Subject: Re: question on draft-ietf-trill-rbridge-protocol-16

Hi ...,

See below...

On Sun, May 2, 2010 at 12:05 PM, ... wrote:

> Hi,
>
> I'm a bit confused about a point in the draft regarding multiple ports
> attached to the same link.
>
> In the two sections below, it states:
>  "All such frames that are part of the same flow must be accepted on the
> same port to avoid re-ordering."
>
>    4.5.2 Multi-destination Frame Checks
>
>      Port Group Check: If an RBridge has multiple ports attached to the
>      same link, a multi-destination frame it is receiving will arrive
>      on all of them. All but one received copy of such a frame MUST be
>      discarded to avoid duplication. All such frames that are part of
>      the same flow must be accepted on the same port to avoid re-
>      ordering.
>
>
>    4.6.1.2 Native Multicast and Broadcast Frames
>
>         If the RBridge has multiple ports attached to the same link, all
> but
>         one received copy of a native multicast or broadcast frame is
>         discarded to avoid duplication. All such frames that are part of
> the
>         same flow must be accepted on the same port to avoid re-ordering.
>
>
> But given that for native multicast only one port of the port group is the
> Appointed VLAN-X Forwarder, and for multi-destination TRILL packets only one
> port of the port group will forward TRILL packets, so I don't see the need
> to be "flow aware" -- packets are just processed in the order the packets
> are received on the port.  Can you explain?
>

Although only a single port is DRB, the appointment of an Appointed
Forwarder on a link is by RBridge, not by port. If you look at the
appointment sub-TLV in draft-ietf-isis-layer2-05 you will see that it is
appointed by nickname. Thus, the particular RBridge that is Appointed
Forwarder for VLAN-X may have multiple ports attached to the link. In this
message I'll call an RBridge with multiple ports on a link a "multiport
RBridge". The easiest thing is just to, in effect, turn all but one of the
ports off, but if the link is actually some complex bridged LAN with lots of
end stations, it might help to spread different VLANs across the different
ports.

The multiport RBridge can, if it is appointed forwarder for more than one
VLAN, distribute those to different ports on the link or, in principle, it
could do even more complex stuff, like splitting the ingress/egress of
native frames in a particular VLAN between ports on the link based on
whether the end station MAC address is odd or even or in even more bizarre
ways.

As far as TRILL data frames go, appointed forwarder status is irrelevant and
any other RBridge on the link can choose to send unicast TRILL data frames
to any of the ports (that it has two way connectivity to as determined by
TRILL Hellos), so it is up to the sending RBridge that, if it wants a simple
strategy, could simply send such unicast TRILL data frames to the port with
the lowest MAC address or whatever. This is all local as, to the rest of the
campus, there just appears to be one adjacency between such an RBridge and
the multiport RBridge.

I guess that in theory special language might not be needed for multicast or
broadcast native frames as the multiport RBridge has to sort out which port
it is going in ingress/egress native frames on anyway, since none of the
native frames are normally addressed to the RBridge itself, but it seems
better to emphasize the point about flows. A TRILL data frame sent to
All-RBridges will arrive on all the ports and the multiport RBridge is
required to not duplicate it but it could, in principle, do something like
process different priorities of such multicast TRILL data frames on
different ports or other bizarre things. As long as it keeps the flows
straight. (GhostBusters quote: "Don't cross the flows...")

So, if they adopt simple strategies, you are right that such RBridges do not
necessarily need to be "flow aware". But if they are trying to be more
efficient by adopting complex strategies, the statements about flows in the
draft are the criterion for correct operation.

...

Thanks,
Donald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100503/40b3664b/attachment.html

From anoop at brocade.com  Mon May  3 22:31:43 2010
From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 3 May 2010 22:31:43 -0700
Subject: [rbridge] Readiness of the VLAN Mapping Draft
In-Reply-To: <20100330105720.NK17R.1449266.root@mp15>
References: <20100330105720.NK17R.1449266.root@mp15>
Message-ID: <26468D0323239E4184C3C4B41E6B63B404E050E1BC@HQ-EXCH-7.corp.brocade.com>

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Anil Rijhsinghani
> Sent: Tuesday, March 30, 2010 7:57 AM
> 
> VLAN mapping is not a standard function, so the answer to
> this isn't straightforward. As with any non-standard thing,
> different people may implement it different ways.

IEEE 802 calls this function "VID translation" and
it is in the standard, but only for s-tags.  And that's
why I've been saying that we should call it by the
same name here as well...

Also, to answer Radia's question -
As far as I recall, the mapping is 1:1, i.e.
if A maps to B, then B must map to something else.
And it is symmetric; i.e. if we translate
the VID going out a port, then we must also
translate on the way in.  This also affects
protocols such as MSTP and M?RP where the
VLAN ID is carried within the control frame.

Anoop


From jrrivers at cumulusnetworks.com  Tue May  4 09:47:03 2010
From: jrrivers at cumulusnetworks.com (JR Rivers)
Date: Tue, 4 May 2010 09:47:03 -0700
Subject: [rbridge] Multicast root observation
In-Reply-To: <j2w1028365c1004201258k56dd337eh682d8873ea7bf578@mail.gmail.com>
References: <93D79258-CF6D-4F53-831D-326F4A93929A@cumulusnetworks.com>
	<x2v1028365c1004180827t88562a04p443b2b720390a596@mail.gmail.com>
	<19F4BE45-B82E-4A70-8FD3-9820D4F96619@cumulusnetworks.com>
	<j2w1028365c1004201258k56dd337eh682d8873ea7bf578@mail.gmail.com>
Message-ID: <92F6E4F6-86D1-42E2-AE3F-F2C5046DA304@cumulusnetworks.com>


Donald-

Sorry it took so long to get back... thoughts in line.

JR


On Apr 20, 2010, at 12:58 PM, Donald Eastlake wrote:

> Hi JR,
> 
> On Mon, Apr 19, 2010 at 3:06 PM, JR Rivers <jrrivers at cumulusnetworks.com> wrote:
>> 
>> ...
>> 
>> On Apr 18, 2010, at 8:27 AM, Donald Eastlake wrote:
>> 
>>> Hi JR,
>>> 
>>> On Sat, Apr 17, 2010 at 3:21 PM, JR Rivers <jrrivers at cumulusnetworks.com> wrote:
>>>> 
>>>> ...
>>> 
>>> Well, that's a reasonable point of view. But since the RBridge
>>> specifying the list of tree roots is the same RBridge that is
>>> specifying the number of trees (although the number of trees can get
>>> reduced if there are RBridges in the campus unable to compute the
>>> requested number...), one wonders why it would specify more than the
>>> number of valid nicknames in the list it is providing.
> 
>> First, there is the case you've enumerated where another RBRIDGE in
>> the network is not able to support the number of multicast roots in
>> the list.
> 
>> The second case is one of simplicity.  From an administrative point
>> of few, you'd like to specify the list of available roots and leave
>> that list intact, regardless of whether these devices are alive or
>> not.  You'd image the common scenario would have each of the desired
>> roots advertising the same list.  Then RBRIDGES are able to
>> calculate the appropriate trees... clearly, you can't calculate a
>> tree to a root that is not in your LSP database.  The alternative is
>> to have the list, as advertised by the highest priority RBRIDGE,
>> shrink and grow each time one of the desired roots comes/goes.  That
>> is a lot of fluctuation in a transitioning system.
> 
> [It's not quite the "highest priority RBridge", although I have been
> using that phrase for simplicity. It's the RBridge that has the
> highest priority nickname, but this only makes a difference if there
> are RBridges with multiple nicknames. For simplicity, I'll continue to
> talk about the "highest priority RBridge".]
> 
> I wasn't suggesting that the list should shrink/grow. In particular,
> why would you bother to shrink the list? There is nothing wrong with
> the highest priority RBridge making the list longer than the number of
> trees that RBridge is specifying as the number that should be
> calculated. Even if the highest priority RBridge is specifying that
> number of trees as exactly the list length, you might still have to
> calculate fewer than are in the list due to some RBridges not being
> capable of calculating all the trees. So RBridges have to be able to
> handle the case where the list is longer than the number of trees being
> computed. Presumably the network manager would normally configure the
> list of roots at all RBridge in the campus.
> 
> I think the only question is what to do if the number of trees to
> calculate is larger than the length of the list. If there is a list of
> distribution tree roots, the network manager must have configured it
> and will presumably configure other aspects of the campus, including
> the priorities of all the nicknames. It seems to me that, to get the
> behavior you want, where no other roots beyond those listed are used,
> the network manager simply configures all the nicknames not on the
> list to have zero priority. That way they won't be used as a tree root
> (except as a last resort where it turns out to be the only tree)
> because zero priority is a special value indicating that you don't
> want to be a root. If the network manager configures them to have
> non-zero priorities, then non-listed nicknames can be selected, in
> priority rank, to fill in the number dictated by the highest priority
> RBridge, if the list is too short.

This is the case that we're talking about.  To make sure we're on the same page, my concern with the current spec is the behavior when a list is specified and one or more of the list members are unreachable (links down, system down, etc).  The current spec indicates that any members in the list that are not in the LSP database should be ignored, and the list should be filled in by the selection process.  This seems a bit dangerous.  From your emails, it sounds like your preferred solution is to configure all other Rbridges with a root priority of 0 to avoid this situation.  Experience would suggest that this solution can lead to deployment errors.  I've seen that distributed protocols/fsms work much more predictably when you configure a small number of devices with the desired behavior as opposed to configuring a large number of devices to avoid an undesired behavior.

To this end, I would re-iterate my suggestion that the spec be modified so that when a list is specified, it is definitive and that ONLY Rbridges in the list can be selected as distribution tree roots.  This must be supplemented with a requirement that any Rbridge that advertises a list must be a member of that list (to avoid the no-distribution-tree scenario).



As an aside, the spec is a not perfectly clear how the root priority of 0 is treated in this situation.  The language from draft 16 is...

   o  A nickname whose tree root priority is zero is never used as a
      tree root except that if all nicknames have priority zero, the
      highest priority among them as determined by the tiebreakers is
      used as a tree root so that there is always guaranteed to be at
      least one distribution tree.

In the situation where you need to select more than one distribution tree root, this requirement can be interpreted in at least two ways...

a) If you have at least one distribution tree root, you must ignore all Rbridges with a root priority of 0 during further distribution tree selection

b) When you need to select a root, don't use Rbridges with root priority 0 unless all remaining, unselected Rbridges have root priority 0

Your paragraph above suggests that a) is the correct behavior, so I'd recommend that the text be modified to make it extremely clear.


> 
>>> It seems clear enough what should happen if the number of trees to
>>> compute specified by the highest priority RBridge [actually
>>> nickanme] is the same or less than the number of valid nicknames it
>>> lists. But consider the corner case when the list has no nicknames
>>> on it that actually exist in the campus. (Perhaps the list is
>>> fairly short and the campus has just partitioned or something...)
>>> In that case, all RBridges have to calculate at least one tree or
>>> the network will not be fully functional.
> 
>> If I understand your scenario correctly, then each RBRIDGE has one
>> of two views of the world.  In the first, it receives the list from
>> the highest priority RBRIDGE (I'm assuming that the highest priority
>> RBRIDGE is a member of the list).  In this case, the RBRIDGE has at
>> least one multicast root.  In the second case, the RBRIDGE does NOT
>> receive the list, in this case, it would select the highest priority
>> RBRIDGE that is sees as the multicast root.
> 
> There is no requirement that the highest priority nickname be on the
> list of distribution trees the RBridge with that nickname
> advertises. Every RBridge logically advertises a list of tree root
> nicknames, although it might be the null list. Since they are part of
> the link state database, every RBridge in the campus has a copy of the
> list advertised by every RBridge in the campus. Under the procedures
> given, in a quiescent network, they will all calculate the same trees.
> 
>>> Since, in that case, you have to calculate a tree not on
>>> the list, the highest priority such tree, it seems to me that it is
>>> slightly more consistent to calculate additional higher priority trees
>>> if the list is shorter that the number of trees being dictated by the
>>> highest priority RBridge...
>>> 
>>>> JR
> 
> Thanks,
> Donald
> 
> PS: By the way, an actual implemention might want to keep around the
> forwarding entries for a tree that it is no longer computing for a
> little while to handle frames still in flight in the campus.
> 
> =============================
> Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> 155 Beaver Street   +1-508-634-2066 (home)
> Milford, MA 01757 USA
> d3e3e3 at gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100504/71790466/attachment.html

From ayabaner at cisco.com  Tue May  4 23:08:58 2010
From: ayabaner at cisco.com (Ayan Banerjee)
Date: Tue, 04 May 2010 23:08:58 -0700
Subject: [rbridge] Do people prefer new ISIS PDU types for advertising
 multicast groups?
In-Reply-To: <n2vc09b97ef1004281333r21ecf051ne02ecb25fcb49ad@mail.gmail.com>
Message-ID: <C806598A.50655%ayabaner@cisco.com>


I believe that we had substantial discussion on the merits of this approach.
I have attached a pointer to the meeting minutes on this after IETF-73 -
http://tools.ietf.org/wg/isis/minutes?item=minutes73.html . There was also a
lot of discussion on this during the Feb/March/April 2009 timeframe in the
IS-IS WG mailing list on this.

In summary, the reasons outlined during those discussions are:
- Separation is desired since the join/leave frequency
  of the multicast members will be much higher than unicast topology
  changes.
- Opens up space for additional fragments to improve scalability
  and carrying capacity of the base protocol
- Operational convenience of having separate unicast and
  multicast information.
- Use of other extensions to the protocols, like Extended LSP,
  Multi-Instance support etc, just fall in place.

This additional PDU introduces very minimal complexity into the process. The
update process of MGROUP-PDU follows the exact same design/update flow as
the regular PDU. This flow is well understood and other than just
maintaining a parallel database, there is really not much of a concern here.

This PDU has been out there in the WG for 18 odd months now. I am a bit
concerned about changing things at this juncture, when we should be really
wrapping things up.

Thanks,
Ayan


On 4/28/10 1:33 PM, "Radia Perlman" <radiaperlman at gmail.com> wrote:

> But I still prefer not doing anything; no flag, no new PDU types.
> 
> IS-IS as originally designed for DECnet/CLNP had endnode information
> in LSPs. The same argument could have been made back then -- that
> there should be a different type of LSP for the endnode information
> because that wouldn't trigger SPF, and would be more volatile.
> 
> Merely recommending that the more volatile, non-SPF-producing
> information go into separate fragments, seems solution enough. Any RB
> not following that will cause a bit of suboptimality, but no other
> problems.
> 
> Radia
> 
> 
> 
> On Wed, Apr 28, 2010 at 12:48 PM, James Carlson
> <carlsonj at workingcode.com> wrote:
>> Radia Perlman wrote:
>>> Re: James question below
>>> 
>>> Ah. I was assuming that you'd only set the flag if the fragment only
>>> contains endnode information, and that fragment number NEVER contained
>>> anything but endnode information.
>>> 
>>> I think you were assuming I was recommending you'd set the flag if the
>>> adjacencies reported there haven't changed, or that previous sequence
>>> numbers of that fragment contained adjacencies that got removed from
>>> that fragment because of going down, or being moved to another
>>> fragment.
>> 
>> Exactly.
>> 
>>> I was recommending setting the flag only if the only TLVs in the
>>> fragment are endnode type information (which in TRILL would only be
>>> multicast groups), and that fragment n *never* contained anything but
>>> endnode information (though it's not a problem if those adjacencies
>>> get moved to a different fragment...it's just a problem if they go
>>> away and their absence is SPF-relevant information). If advertising
>>> multicast groups is relegated to its own fragment, then this wouldn't
>>> be a problem.
>> 
>> Based on what I remember in Quagga, I think that might be hard to
>> achieve there, but I can imagine that someone who tracks fragment
>> contents over time more carefully could do this.
>> 
>> Thanks; I get it now. ?I'm not sure where (in what implementation) it'd
>> be workable, but at least I understand how it'd function.
>> 
>> --
>> James Carlson ? ? ? ? 42.703N 71.076W ? ? ? ? <carlsonj at workingcode.com>
>> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge



From anoop at brocade.com  Fri May  7 18:23:39 2010
From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 7 May 2010 18:23:39 -0700
Subject: [rbridge] Do people prefer new ISIS PDU types for
	advertising	multicast groups?
In-Reply-To: <n2vc09b97ef1004281333r21ecf051ne02ecb25fcb49ad@mail.gmail.com>
References: <v2ic09b97ef1004280942y9269edddx5ce999692498f1fb@mail.gmail.com>
	<4BD87341.6060109@workingcode.com>
	<x2yc09b97ef1004281143p9bcae046kfe96cb9b4d93e144@mail.gmail.com>
	<4BD88490.60804@workingcode.com>
	<u2yc09b97ef1004281218xd8e834e9za851828930c550db@mail.gmail.com>
	<4BD89115.70206@workingcode.com>
	<n2vc09b97ef1004281333r21ecf051ne02ecb25fcb49ad@mail.gmail.com>
Message-ID: <26468D0323239E4184C3C4B41E6B63B404E050E63D@HQ-EXCH-7.corp.brocade.com>

I agree.  We should not make any changes unless they
are absolutely needed.

Anoop

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Radia Perlman
> Sent: Wednesday, April 28, 2010 1:34 PM
> To: James Carlson
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Do people prefer new ISIS PDU types for
> advertising multicast groups?
> 
> But I still prefer not doing anything; no flag, no new PDU types.
> 
> IS-IS as originally designed for DECnet/CLNP had endnode information
> in LSPs. The same argument could have been made back then -- that
> there should be a different type of LSP for the endnode information
> because that wouldn't trigger SPF, and would be more volatile.
> 
> Merely recommending that the more volatile, non-SPF-producing
> information go into separate fragments, seems solution enough. Any RB
> not following that will cause a bit of suboptimality, but no other
> problems.
> 
> Radia
> 
> 
> 
> On Wed, Apr 28, 2010 at 12:48 PM, James Carlson
> <carlsonj at workingcode.com> wrote:
> > Radia Perlman wrote:
> >> Re: James question below
> >>
> >> Ah. I was assuming that you'd only set the flag if the fragment only
> >> contains endnode information, and that fragment number NEVER
> contained
> >> anything but endnode information.
> >>
> >> I think you were assuming I was recommending you'd set the flag if
> the
> >> adjacencies reported there haven't changed, or that previous
> sequence
> >> numbers of that fragment contained adjacencies that got removed from
> >> that fragment because of going down, or being moved to another
> >> fragment.
> >
> > Exactly.
> >
> >> I was recommending setting the flag only if the only TLVs in the
> >> fragment are endnode type information (which in TRILL would only be
> >> multicast groups), and that fragment n *never* contained anything
> but
> >> endnode information (though it's not a problem if those adjacencies
> >> get moved to a different fragment...it's just a problem if they go
> >> away and their absence is SPF-relevant information). If advertising
> >> multicast groups is relegated to its own fragment, then this
> wouldn't
> >> be a problem.
> >
> > Based on what I remember in Quagga, I think that might be hard to
> > achieve there, but I can imagine that someone who tracks fragment
> > contents over time more carefully could do this.
> >
> > Thanks; I get it now. ?I'm not sure where (in what implementation)
> it'd
> > be workable, but at least I understand how it'd function.
> >
> > --
> > James Carlson ? ? ? ? 42.703N 71.076W
> <carlsonj at workingcode.com>
> >
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge


From erik.nordmark at oracle.com  Sun May  9 23:36:52 2010
From: erik.nordmark at oracle.com (Erik Nordmark)
Date: Sun, 09 May 2010 23:36:52 -0700
Subject: [rbridge] Updated charter
Message-ID: <4BE7A984.8050607@oracle.com>


Based on the comments on the mailing list, here is the updated charter.

Description of Working Group:

   The TRILL WG has specified a solution for shortest-path frame
   routing in multi-hop IEEE 802.1-compliant Ethernet networks with
   arbitrary topologies, using an existing link-state routing protocol
   technology and encapsulation with a hop count.
   [Add reference to RFC?]

   The current work of the working group is around operational and
   deployment support for the protocol. This includes a MIB and other
   pieces needed for operations, but also additional ways to extend and
   optimize TRILL for the properties of the networks on which it is 
deployed.

   The WG will work on the following items:

   (1) A MIB for TRILL which specifies the unique pieces needed for the
   protocol while reusing what is in the IS-IS MIB and the IEEE 802.1
   MIB modules for pieces that are not unique to TRILL.

   (2) Addition of optional support for ARP / Neighbor Discovery
   optimization.

   (3) Refinement of the TRILL Header Options feature and specification
   of an initial base set of options.

   (4) Support for RBridge campus VLAN regions, such that the same VLAN
   ID can have different meanings in different regions, requiring
   configuration only at border RBridges.

   (5) Write up how Operations and Management (OAM) will be handled in
   networks using TRILL.

   (6) Determine how TRILL will provide improved support for data
   centers such as support of the IEEE 802.1 "Data Center Bridging"
   standards.

   (7) Document interoperability test results of protocol
   implementations.

Goals and Milestones:
   Done     - Accept base protocol specification as a WG document
   Done     - Accept problem statement and applicability as a WG work
              item
   Done     - Start work with routing area WG(s) to undertake TRILL
              extensions
   Done     - Accept architecture document as a WG work item
   Done     - Accept routing protocol requirements as a WG work item
   Done     - Choose routing protocol(s) that can meet the requirements
   Done     - Submit problem statement and applicability to IESG for
              Informational RFC
   Done     - Submit base protocol specification to IEEE/IETF expert
              review
   Done     - Base protocol specification submitted to the IESG for
              publication as a Proposed Standard RFC
   Done     - First draft showing what is needed for MIB

NEW:
   Done     - Initial WG draft on VLAN Mapping
   Done     - Initial WG draft TRILL Header Options
   Jul 2010 - Initial WG draft on ARP/ND optimizations
   Aug 2010 - Submit TRILL Header Options to IESG for publication as
              Proposed Standard
   Aug 2010 - Submit Rbridge Campus VLAN Regions to IESG for publication
              as Proposed Standard
   Oct 2010 - Submit RBridge MIB to IESG for publication as Proposed
              Standard
   Oct 2010 - Initial WG draft for RBridge support of Data Center
              Bridging
   Oct 2010 - Initial WG draft on RBridge OAM
   Jul 2011 - Re-charter or shut down the WG

From mshand at cisco.com  Tue May 11 04:02:10 2010
From: mshand at cisco.com (mike shand)
Date: Tue, 11 May 2010 12:02:10 +0100
Subject: [rbridge] Some comments about TRILL ESADI processing of CSNPs
Message-ID: <4BE93932.7080502@cisco.com>

I'm sorry, I have only just noticed the following


In section 4.2.5.1 of the TRILL spec it says

"  The ESADI DRB sends TRILL-ESADI-CSNP frames on the ESADI virtual
    link. *For robustness, a participating RBridge that determines that
    some other RBridge should be ESADI DRB on such a virtual link but has
    not received or sent a TRILL-ESADI-CSNP in at least the ESADI DRB
    holding time MAY also send a TRILL-ESADI-CSNP on the virtual link.* A
    participating RBridge that determines that no other RBridges are
    participating in the ESADI protocol for a particular VLAN SHOULD NOT
    send ESADI information or TRILL-ESADI-CSNPs on the virtual link for
    that VLAN.
"

However, ISO/IEC 10589 second edition in clause 7.3.17 says

If an Intermediate system detects that the transmitter had more up to 
date information, the receiving Intermediate system shall multicast a 
Partial Sequence Numbers PDU (PSNP), containing information about LSPs 
for which it has older information. This serves as an implicit request 
for the missing information. Although the PSNP is multicast, *only the 
Designated Intermediate System of the appropriate level shall respond to 
the PSNP.*
NOTE 38 This is equivalent to the PSNP being transmitted directly to the 
Designated Intermediate System, in that it avoids each Intermediate 
System unnecessarily sending the same LSP(s) in response. However, it 
has the advantage of preserving the property that all routeing messages 
can be received on the multi-destination addresses, and hence by a LAN 
adapter dedicated to the multi-destination address.


Presumably in the ESADI case, the intention is that the non-DRB sending 
the CSNP should ALSO respond to the PSNP.

It probably therefore needs some words to clarify this.

However, I am more concerned by the following.

Presumably the intention is that the first non-DRB to notice the lack of 
CSNPs and send one itself will inhibit other RBridges from also sending 
CSNPs, hence avoiding a storm of CSNPs.  However it is possible that 
some number of other RBridges will start to transmit CSNPs before they 
receive the CSNP sent by the first RBridge. Since the CSNP will in most 
cases be a set of CSNPs, is the intention that reception of a CSNP 
should inhibit the sending of further members of the set, or should the 
complete set be transmitted once it has been started, even in the 
presence of CSNPs from another RBridge?

I think it has to be the latter, since two RBridges deciding to send a 
CSNP set at about the same time could mutually inhibit each other, 
resulting in only a partial CSNP set being transmitted by either of the 
RBridges, and thus negating the effect of the "backup" CSNP.

There would appear to be some need of clarification here.



     Mike



-- 
For corporate legal information go to:
www.cisco.com/web/about/doing_business/legal/cri


From d3e3e3 at gmail.com  Tue May 11 07:58:46 2010
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 11 May 2010 10:58:46 -0400
Subject: [rbridge] Multicast root observation
In-Reply-To: <92F6E4F6-86D1-42E2-AE3F-F2C5046DA304@cumulusnetworks.com>
References: <93D79258-CF6D-4F53-831D-326F4A93929A@cumulusnetworks.com>
	<x2v1028365c1004180827t88562a04p443b2b720390a596@mail.gmail.com>
	<19F4BE45-B82E-4A70-8FD3-9820D4F96619@cumulusnetworks.com>
	<j2w1028365c1004201258k56dd337eh682d8873ea7bf578@mail.gmail.com>
	<92F6E4F6-86D1-42E2-AE3F-F2C5046DA304@cumulusnetworks.com>
Message-ID: <AANLkTilHHrKJ-Nv3nC8PNszP06DDqy_rIJHFRV5n5myg@mail.gmail.com>

Hi JR,

On Tue, May 4, 2010 at 12:47 PM, JR Rivers <jrrivers at cumulusnetworks.com>wrote:

>
> ...
>
> On Apr 20, 2010, at 12:58 PM, Donald Eastlake wrote:
>
> Hi JR,
>
> On Mon, Apr 19, 2010 at 3:06 PM, JR Rivers <jrrivers at cumulusnetworks.com>
> wrote:
>
>
> ...
>
>
> On Apr 18, 2010, at 8:27 AM, Donald Eastlake wrote:
>
>
> Hi JR,
>
>
> On Sat, Apr 17, 2010 at 3:21 PM, JR Rivers <jrrivers at cumulusnetworks.com>
> wrote:
>
>
> ...
>
>
> Well, that's a reasonable point of view. But since the RBridge
>
> specifying the list of tree roots is the same RBridge that is
>
> specifying the number of trees (although the number of trees can get
>
> reduced if there are RBridges in the campus unable to compute the
>
> requested number...), one wonders why it would specify more than the
>
> number of valid nicknames in the list it is providing.
>
> First, there is the case you've enumerated where another RBRIDGE in
>
> the network is not able to support the number of multicast roots in
>
> the list.
>
>
> The second case is one of simplicity.  From an administrative point
>
> of few, you'd like to specify the list of available roots and leave
>
> that list intact, regardless of whether these devices are alive or
>
> not.  You'd image the common scenario would have each of the desired
>
> roots advertising the same list.  Then RBRIDGES are able to
>
> calculate the appropriate trees... clearly, you can't calculate a
>
> tree to a root that is not in your LSP database.  The alternative is
>
> to have the list, as advertised by the highest priority RBRIDGE,
>
> shrink and grow each time one of the desired roots comes/goes.  That
>
> is a lot of fluctuation in a transitioning system.
>
>
> [It's not quite the "highest priority RBridge", although I have been
> using that phrase for simplicity. It's the RBridge that has the
> highest priority nickname, but this only makes a difference if there
> are RBridges with multiple nicknames. For simplicity, I'll continue to
> talk about the "highest priority RBridge".]
>
> I wasn't suggesting that the list should shrink/grow. In particular,
> why would you bother to shrink the list? There is nothing wrong with
> the highest priority RBridge making the list longer than the number of
> trees that RBridge is specifying as the number that should be
> calculated. Even if the highest priority RBridge is specifying that
> number of trees as exactly the list length, you might still have to
> calculate fewer than are in the list due to some RBridges not being
> capable of calculating all the trees. So RBridges have to be able to
> handle the case where the list is longer than the number of trees being
> computed. Presumably the network manager would normally configure the
> list of roots at all RBridge in the campus.
>
> I think the only question is what to do if the number of trees to
> calculate is larger than the length of the list. If there is a list of
> distribution tree roots, the network manager must have configured it
> and will presumably configure other aspects of the campus, including
> the priorities of all the nicknames. It seems to me that, to get the
> behavior you want, where no other roots beyond those listed are used,
> the network manager simply configures all the nicknames not on the
> list to have zero priority. That way they won't be used as a tree root
> (except as a last resort where it turns out to be the only tree)
> because zero priority is a special value indicating that you don't
> want to be a root. If the network manager configures them to have
> non-zero priorities, then non-listed nicknames can be selected, in
> priority rank, to fill in the number dictated by the highest priority
> RBridge, if the list is too short.
>
>
> This is the case that we're talking about.  To make sure we're on the same
> page, my concern with the current spec is the behavior when a list is
> specified and one or more of the list members are unreachable (links down,
> system down, etc).  The current spec indicates that any members in the list
> that are not in the LSP database should be ignored, and the list should be
> filled in by the selection process.  This seems a bit dangerous.  From your
> emails, it sounds like your preferred solution is to configure all other
> Rbridges with a root priority of 0 to avoid this situation.  Experience
> would suggest that this solution can lead to deployment errors.  I've seen
> that distributed protocols/fsms work much more predictably when you
> configure a small number of devices with the desired behavior as opposed to
> configuring a large number of devices to avoid an undesired behavior.
>

Well,  that's reasonable but it doesn't seem too bad to just configure all
the RBridges in the campus with the same list of roots and with priority
zero. (See also my response below...)

To this end, I would re-iterate my suggestion that the spec be modified so
> that when a list is specified, it is definitive and that ONLY Rbridges in
> the list can be selected as distribution tree roots.  This must be
> supplemented with a requirement that any Rbridge that advertises a list must
> be a member of that list (to avoid the no-distribution-tree scenario).
>

Saying that all RBridges that advertise a list of roots have to list
themselves doesn't make it so. Since you still have to handle the case where
this suggested requirement was ignored and you always have to have at least
one tree, I don't actually see much point to the requirement.

The provisions in the current TRILL Proposed Standard were arrived at by
discussions among something like half a dozen active TRILL participants and
there are implementations efforts underway, some of which are, I believe,
close to shipping. So, while I can see some merit to your arguments, unless
other people speak up in favor of your views, I don't think this should be
changed.

As an aside, the spec is a not perfectly clear how the root priority of 0 is
> treated in this situation.  The language from draft 16 is...
>
>    o  A nickname whose tree root priority is zero is never used as a
>       tree root except that if all nicknames have priority zero, the
>       highest priority among them as determined by the tiebreakers is
>       used as a tree root so that there is always guaranteed to be at
>       least one distribution tree.
>
> In the situation where you need to select more than one distribution tree
> root, this requirement can be interpreted in at least two ways...
>
> a) If you have at least one distribution tree root, you must ignore all
> Rbridges with a root priority of 0 during further distribution tree
> selection
>
> b) When you need to select a root, don't use Rbridges with root priority 0
> unless all remaining, unselected Rbridges have root priority 0
>
> Your paragraph above suggests that a) is the correct behavior, so I'd
> recommend that the text be modified to make it extremely clear.
>

You are completely correct that this is not clear. I believe that text
should have started "A nickname whose tree root priority is zero is not
selected as a tree root based on priority, except that if all nicknames have
priority zero, ..." In other words, the list of roots dominates priority,
including priority zero.

Initially, the draft only had priority in it. When the list of roots was
added, I think this text wasn't adjusted.


> It seems clear enough what should happen if the number of trees to
>
> compute specified by the highest priority RBridge [actually
>
> nickanme] is the same or less than the number of valid nicknames it
>
> lists. But consider the corner case when the list has no nicknames
>
> on it that actually exist in the campus. (Perhaps the list is
>
> fairly short and the campus has just partitioned or something...)
>
> In that case, all RBridges have to calculate at least one tree or
>
> the network will not be fully functional.
>
>
> If I understand your scenario correctly, then each RBRIDGE has one
>
> of two views of the world.  In the first, it receives the list from
>
> the highest priority RBRIDGE (I'm assuming that the highest priority
>
> RBRIDGE is a member of the list).  In this case, the RBRIDGE has at
>
> least one multicast root.  In the second case, the RBRIDGE does NOT
>
> receive the list, in this case, it would select the highest priority
>
> RBRIDGE that is sees as the multicast root.
>
>
> There is no requirement that the highest priority nickname be on the
> list of distribution trees the RBridge with that nickname
> advertises. Every RBridge logically advertises a list of tree root
> nicknames, although it might be the null list. Since they are part of
> the link state database, every RBridge in the campus has a copy of the
> list advertised by every RBridge in the campus. Under the procedures
> given, in a quiescent network, they will all calculate the same trees.
>
> Since, in that case, you have to calculate a tree not on
>
> the list, the highest priority such tree, it seems to me that it is
>
> slightly more consistent to calculate additional higher priority trees
>
> if the list is shorter that the number of trees being dictated by the
>
> highest priority RBridge...
>
>
> JR
>
>
> Thanks,
> Donald
>
> PS: By the way, an actual implemention might want to keep around the
> forwarding entries for a tree that it is no longer computing for a
> little while to handle frames still in flight in the campus.
>
> Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street   +1-508-634-2066 (home)
Milford, MA 01757 USA
d3e3e3 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100511/287f47ad/attachment-0001.html

From david.bond at iol.unh.edu  Tue May 11 13:03:40 2010
From: david.bond at iol.unh.edu (David Michael Bond)
Date: Tue, 11 May 2010 16:03:40 -0400
Subject: [rbridge] C Bit Clarification
Message-ID: <002601caf145$0cdba880$2692f980$@bond@iol.unh.edu>

Hello Everyone,

I have a question regarding the draft. It's just a minor clarification.

 

Section 4.1.1 says:

The "C" bit shown in Figure 4.2 is not used in TRILL. It MUST be set to zero
and is ignored by receivers.

 

In a transit RBridge situation if an RBridge receives a TRILL data frame
with the C bit set to one in either the Outer or Inner VLAN should it
transparently forward the frame or clear the C bit?

 

Also, I believe "[802.1Qad] S-tags, ." Should be "[802.1ad] S-tags, ."

Thanks,

David

 

                    David Bond                    

.~~~~~.~~~~~.~~~~~.~~~~~~.~~~~~~.~~~~~.~~~~~.~~~~~.
.University of New Hampshire                      .
.    - InterOperability Laboratory                .
.        Research and Development Software Eng.   .
.        Routing & Bridge Functions Consortiums   .
.    - Computer Science PhD Student               .
. 121 Technology Drive, Suite 2, Durham NH, 03824 .
.    (O) 1-603-862-3525     (M) 1-603-845-7514    .

.     http://mokon.net    http://iol.unh.edu      .
.~~~~~.~~~~~.~~~~~.~~~~~~.~~~~~~.~~~~~.~~~~~.~~~~~. 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100511/550d5f82/attachment.html

From d3e3e3 at gmail.com  Tue May 11 13:49:47 2010
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 11 May 2010 16:49:47 -0400
Subject: [rbridge] C Bit Clarification
In-Reply-To: <-4996884809576582520@unknownmsgid>
References: <-4996884809576582520@unknownmsgid>
Message-ID: <AANLkTili0kfW-hUVjMORqD6PHmMxkplW1QJGcAcVm4qZ@mail.gmail.com>

Hi David,

On Tue, May 11, 2010 at 4:03 PM, David Michael Bond
<david.bond at iol.unh.edu> wrote:
> Hello Everyone,
>
> I have a question regarding the draft. It?s just a minor clarification.
>
>
>
> Section 4.1.1 says:
>
> The "C" bit shown in Figure 4.2 is not used in TRILL. It MUST be set to zero
> and is ignored by receivers.
>
>
>
> In a transit RBridge situation if an RBridge receives a TRILL data frame
> with the C bit set to one in either the Outer or Inner VLAN should it
> transparently forward the frame or clear the C bit?

I think this is mostly talking about the Inner.VLAN.

Although TRILL specifies the Outer VLAN ID and priority (which affects
queuing) to be used if a frame is sent tagged, it runs above 802.1Q
ports. For 802.3, which is what the standard focuses on, the C bit
should be clear, but I suspect the bit would just be ignored on
receipt, if it were a 1, by most existing 802.1Q/802.3 ports. However,
for more exotic link types, like 802.5, which I don't know much about
and which are not covered by the TRILL standard, I think you might
have to set the C (actually CFI) bit in the Outer.VLAN.

For the Inner.VLAN, I think transit RBridges should just transparently
forward it.

> Also, I believe ?[802.1Qad] S-tags, ?? Should be ?[802.1ad] S-tags, ??

Yes. Only [802.1ad] appears in the References, so this should be caught later.

Thanks,
Donald

> Thanks,
>
> David
>
>
>
> ??????????????????? David Bond
>
> .~~~~~.~~~~~.~~~~~.~~~~~~.~~~~~~.~~~~~.~~~~~.~~~~~.
> .University of New Hampshire????????????????????? .
> .??? - InterOperability Laboratory ???????????????.
> .??????? Research and Development Software Eng.? ?.
> .??????? Routing & Bridge Functions Consortiums?? .
> .??? - Computer Science PhD Student? ???????? ??? .
> . 121 Technology Drive, Suite 2, Durham NH, 03824 .
> .??? (O) 1-603-862-3525???? (M) 1-603-845-7514??? .
>
> .???? http://mokon.net??? http://iol.unh.edu????? .
> .~~~~~.~~~~~.~~~~~.~~~~~~.~~~~~~.~~~~~.~~~~~.~~~~~.


From radiaperlman at gmail.com  Tue May 11 21:43:31 2010
From: radiaperlman at gmail.com (Radia Perlman)
Date: Tue, 11 May 2010 21:43:31 -0700
Subject: [rbridge] [Isis-wg] Some comments about TRILL ESADI processing
	of CSNPs
In-Reply-To: <4BE93932.7080502@cisco.com>
References: <4BE93932.7080502@cisco.com>
Message-ID: <AANLkTimG9Xl1n7GEGKj3RsM_8cgvkl1GPTVqecR5jGrF@mail.gmail.com>

The possibilities are:

a) don't worry about it -- it doesn't seem like a major problem if
occasionally multiple RBridges send CSNPs. Maybe add explicit
instructions for jitter so all RBridges don't time out at the same
time and send CSNPs.

b) have an RBridge receiving CSNPs defer to a higher priority RBridge
sending CSNPs, in the sense of ceasing to send CSNPs if it gets even a
single CSNP fragment from a higher priority RB.

I think there will be another document describing the details of
ESADI, in which case we can make those clarifications there.

Radia



On Tue, May 11, 2010 at 4:02 AM, mike shand <mshand at cisco.com> wrote:
> I'm sorry, I have only just noticed the following
>
>
> In section 4.2.5.1 of the TRILL spec it says
>
> " ?The ESADI DRB sends TRILL-ESADI-CSNP frames on the ESADI virtual
> ? link. *For robustness, a participating RBridge that determines that
> ? some other RBridge should be ESADI DRB on such a virtual link but has
> ? not received or sent a TRILL-ESADI-CSNP in at least the ESADI DRB
> ? holding time MAY also send a TRILL-ESADI-CSNP on the virtual link.* A
> ? participating RBridge that determines that no other RBridges are
> ? participating in the ESADI protocol for a particular VLAN SHOULD NOT
> ? send ESADI information or TRILL-ESADI-CSNPs on the virtual link for
> ? that VLAN.
> "
>
> However, ISO/IEC 10589 second edition in clause 7.3.17 says
>
> If an Intermediate system detects that the transmitter had more up to date
> information, the receiving Intermediate system shall multicast a Partial
> Sequence Numbers PDU (PSNP), containing information about LSPs for which it
> has older information. This serves as an implicit request for the missing
> information. Although the PSNP is multicast, *only the Designated
> Intermediate System of the appropriate level shall respond to the PSNP.*
> NOTE 38 This is equivalent to the PSNP being transmitted directly to the
> Designated Intermediate System, in that it avoids each Intermediate System
> unnecessarily sending the same LSP(s) in response. However, it has the
> advantage of preserving the property that all routeing messages can be
> received on the multi-destination addresses, and hence by a LAN adapter
> dedicated to the multi-destination address.
>
>
> Presumably in the ESADI case, the intention is that the non-DRB sending the
> CSNP should ALSO respond to the PSNP.
>
> It probably therefore needs some words to clarify this.
>
> However, I am more concerned by the following.
>
> Presumably the intention is that the first non-DRB to notice the lack of
> CSNPs and send one itself will inhibit other RBridges from also sending
> CSNPs, hence avoiding a storm of CSNPs. ?However it is possible that some
> number of other RBridges will start to transmit CSNPs before they receive
> the CSNP sent by the first RBridge. Since the CSNP will in most cases be a
> set of CSNPs, is the intention that reception of a CSNP should inhibit the
> sending of further members of the set, or should the complete set be
> transmitted once it has been started, even in the presence of CSNPs from
> another RBridge?
>
> I think it has to be the latter, since two RBridges deciding to send a CSNP
> set at about the same time could mutually inhibit each other, resulting in
> only a partial CSNP set being transmitted by either of the RBridges, and
> thus negating the effect of the "backup" CSNP.
>
> There would appear to be some need of clarification here.
>
>
>
> ? ?Mike
>
>
>
> --
> For corporate legal information go to:
> www.cisco.com/web/about/doing_business/legal/cri
>
> _______________________________________________
> Isis-wg mailing list
> Isis-wg at ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
>


From rdroms at cisco.com  Wed May 12 03:22:56 2010
From: rdroms at cisco.com (Ralph Droms)
Date: Wed, 12 May 2010 06:22:56 -0400
Subject: [rbridge] Updated charter
In-Reply-To: <4BE7A984.8050607@oracle.com>
References: <4BE7A984.8050607@oracle.com>
Message-ID: <A22E6E05-27F1-4BB6-AB9A-0FB2E2764F17@cisco.com>

This proposed charter mostly looks OK.  In (6), "improved support"  
relative to what?

- Ralph


On May 10, 2010, at 2:36 AM 5/10/10, Erik Nordmark wrote:

>
> Based on the comments on the mailing list, here is the updated  
> charter.
>
> Description of Working Group:
>
>   The TRILL WG has specified a solution for shortest-path frame
>   routing in multi-hop IEEE 802.1-compliant Ethernet networks with
>   arbitrary topologies, using an existing link-state routing protocol
>   technology and encapsulation with a hop count.
>   [Add reference to RFC?]
>
>   The current work of the working group is around operational and
>   deployment support for the protocol. This includes a MIB and other
>   pieces needed for operations, but also additional ways to extend and
>   optimize TRILL for the properties of the networks on which it is
> deployed.
>
>   The WG will work on the following items:
>
>   (1) A MIB for TRILL which specifies the unique pieces needed for the
>   protocol while reusing what is in the IS-IS MIB and the IEEE 802.1
>   MIB modules for pieces that are not unique to TRILL.
>
>   (2) Addition of optional support for ARP / Neighbor Discovery
>   optimization.
>
>   (3) Refinement of the TRILL Header Options feature and specification
>   of an initial base set of options.
>
>   (4) Support for RBridge campus VLAN regions, such that the same VLAN
>   ID can have different meanings in different regions, requiring
>   configuration only at border RBridges.
>
>   (5) Write up how Operations and Management (OAM) will be handled in
>   networks using TRILL.
>
>   (6) Determine how TRILL will provide improved support for data
>   centers such as support of the IEEE 802.1 "Data Center Bridging"
>   standards.
>
>   (7) Document interoperability test results of protocol
>   implementations.
>
> Goals and Milestones:
>   Done     - Accept base protocol specification as a WG document
>   Done     - Accept problem statement and applicability as a WG work
>              item
>   Done     - Start work with routing area WG(s) to undertake TRILL
>              extensions
>   Done     - Accept architecture document as a WG work item
>   Done     - Accept routing protocol requirements as a WG work item
>   Done     - Choose routing protocol(s) that can meet the requirements
>   Done     - Submit problem statement and applicability to IESG for
>              Informational RFC
>   Done     - Submit base protocol specification to IEEE/IETF expert
>              review
>   Done     - Base protocol specification submitted to the IESG for
>              publication as a Proposed Standard RFC
>   Done     - First draft showing what is needed for MIB
>
> NEW:
>   Done     - Initial WG draft on VLAN Mapping
>   Done     - Initial WG draft TRILL Header Options
>   Jul 2010 - Initial WG draft on ARP/ND optimizations
>   Aug 2010 - Submit TRILL Header Options to IESG for publication as
>              Proposed Standard
>   Aug 2010 - Submit Rbridge Campus VLAN Regions to IESG for  
> publication
>              as Proposed Standard
>   Oct 2010 - Submit RBridge MIB to IESG for publication as Proposed
>              Standard
>   Oct 2010 - Initial WG draft for RBridge support of Data Center
>              Bridging
>   Oct 2010 - Initial WG draft on RBridge OAM
>   Jul 2011 - Re-charter or shut down the WG
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge


From touch at isi.edu  Wed May 12 08:11:55 2010
From: touch at isi.edu (Joe Touch)
Date: Wed, 12 May 2010 08:11:55 -0700
Subject: [rbridge] Updated charter
In-Reply-To: <A22E6E05-27F1-4BB6-AB9A-0FB2E2764F17@cisco.com>
References: <4BE7A984.8050607@oracle.com>
	<A22E6E05-27F1-4BB6-AB9A-0FB2E2764F17@cisco.com>
Message-ID: <4BEAC53B.5000800@isi.edu>



Ralph Droms wrote:
> This proposed charter mostly looks OK.  In (6), "improved support"  
> relative to what?

Relative to the currently specified TRILL protocol suite, IMO.

Joe

> On May 10, 2010, at 2:36 AM 5/10/10, Erik Nordmark wrote:
> 
>> Based on the comments on the mailing list, here is the updated  
>> charter.
>>
>> Description of Working Group:
>>
>>   The TRILL WG has specified a solution for shortest-path frame
>>   routing in multi-hop IEEE 802.1-compliant Ethernet networks with
>>   arbitrary topologies, using an existing link-state routing protocol
>>   technology and encapsulation with a hop count.
>>   [Add reference to RFC?]
>>
>>   The current work of the working group is around operational and
>>   deployment support for the protocol. This includes a MIB and other
>>   pieces needed for operations, but also additional ways to extend and
>>   optimize TRILL for the properties of the networks on which it is
>> deployed.
>>
>>   The WG will work on the following items:
>>
>>   (1) A MIB for TRILL which specifies the unique pieces needed for the
>>   protocol while reusing what is in the IS-IS MIB and the IEEE 802.1
>>   MIB modules for pieces that are not unique to TRILL.
>>
>>   (2) Addition of optional support for ARP / Neighbor Discovery
>>   optimization.
>>
>>   (3) Refinement of the TRILL Header Options feature and specification
>>   of an initial base set of options.
>>
>>   (4) Support for RBridge campus VLAN regions, such that the same VLAN
>>   ID can have different meanings in different regions, requiring
>>   configuration only at border RBridges.
>>
>>   (5) Write up how Operations and Management (OAM) will be handled in
>>   networks using TRILL.
>>
>>   (6) Determine how TRILL will provide improved support for data
>>   centers such as support of the IEEE 802.1 "Data Center Bridging"
>>   standards.
>>
>>   (7) Document interoperability test results of protocol
>>   implementations.
>>
>> Goals and Milestones:
>>   Done     - Accept base protocol specification as a WG document
>>   Done     - Accept problem statement and applicability as a WG work
>>              item
>>   Done     - Start work with routing area WG(s) to undertake TRILL
>>              extensions
>>   Done     - Accept architecture document as a WG work item
>>   Done     - Accept routing protocol requirements as a WG work item
>>   Done     - Choose routing protocol(s) that can meet the requirements
>>   Done     - Submit problem statement and applicability to IESG for
>>              Informational RFC
>>   Done     - Submit base protocol specification to IEEE/IETF expert
>>              review
>>   Done     - Base protocol specification submitted to the IESG for
>>              publication as a Proposed Standard RFC
>>   Done     - First draft showing what is needed for MIB
>>
>> NEW:
>>   Done     - Initial WG draft on VLAN Mapping
>>   Done     - Initial WG draft TRILL Header Options
>>   Jul 2010 - Initial WG draft on ARP/ND optimizations
>>   Aug 2010 - Submit TRILL Header Options to IESG for publication as
>>              Proposed Standard
>>   Aug 2010 - Submit Rbridge Campus VLAN Regions to IESG for  
>> publication
>>              as Proposed Standard
>>   Oct 2010 - Submit RBridge MIB to IESG for publication as Proposed
>>              Standard
>>   Oct 2010 - Initial WG draft for RBridge support of Data Center
>>              Bridging
>>   Oct 2010 - Initial WG draft on RBridge OAM
>>   Jul 2011 - Re-charter or shut down the WG
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20100512/515d08ed/signature.bin

From d3e3e3 at gmail.com  Wed May 19 12:02:03 2010
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Wed, 19 May 2010 15:02:03 -0400
Subject: [rbridge] TRILL WG meeting in Maastricht
Message-ID: <AANLkTilRAeLAG4WmoBpAOhfvxbSzJaAfuKW9SvVsMaa-@mail.gmail.com>

Hi,

There appears to be enough going on in the TRILL WG, what with the items on
the draft new Charter with dates coming up moderately soon, to warrant a
meeting in Maastricht. Please post or contact the co-chairs if you have an
opinion on this or to suggest topics.

Thanks,
Donald & Erik
=============================
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street   +1-508-634-2066 (home)
Milford, MA 01757 USA
d3e3e3 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100519/58175210/attachment.html

From jrrivers at cumulusnetworks.com  Tue May 25 11:35:02 2010
From: jrrivers at cumulusnetworks.com (JR Rivers)
Date: Tue, 25 May 2010 11:35:02 -0700
Subject: [rbridge] Multicast root observation
In-Reply-To: <AANLkTilHHrKJ-Nv3nC8PNszP06DDqy_rIJHFRV5n5myg@mail.gmail.com>
References: <93D79258-CF6D-4F53-831D-326F4A93929A@cumulusnetworks.com>
	<x2v1028365c1004180827t88562a04p443b2b720390a596@mail.gmail.com>
	<19F4BE45-B82E-4A70-8FD3-9820D4F96619@cumulusnetworks.com>
	<j2w1028365c1004201258k56dd337eh682d8873ea7bf578@mail.gmail.com>
	<92F6E4F6-86D1-42E2-AE3F-F2C5046DA304@cumulusnetworks.com>
	<AANLkTilHHrKJ-Nv3nC8PNszP06DDqy_rIJHFRV5n5myg@mail.gmail.com>
Message-ID: <84F3A5A8-F0AB-4A13-A1B5-30D7E39CE221@cumulusnetworks.com>


Donald-

Thanks for the lengthy discussion on this topic.

From what I've gathered, two problems have been noted.  One is an ambiguous section regarding root priority 0.  You've concurred that this is a specification issue.  The second is the "list member availability problem", which you've also asserted is a problem; however, you've asserted a specific configuration level workaround to attempt fix it.  Will either of these issues be addressed in an upcoming draft?

Cheers,

JR

On May 11, 2010, at 7:58 AM, Donald Eastlake wrote:

> Hi JR,
> 
> On Tue, May 4, 2010 at 12:47 PM, JR Rivers <jrrivers at cumulusnetworks.com> wrote:
> 
> ...
> 
> On Apr 20, 2010, at 12:58 PM, Donald Eastlake wrote:
> 
>> Hi JR,
>> 
>> On Mon, Apr 19, 2010 at 3:06 PM, JR Rivers <jrrivers at cumulusnetworks.com> wrote:
>>> 
>>> ...
>>> 
>>> On Apr 18, 2010, at 8:27 AM, Donald Eastlake wrote:
>>> 
>>>> Hi JR,
>>>> 
>>>> On Sat, Apr 17, 2010 at 3:21 PM, JR Rivers <jrrivers at cumulusnetworks.com> wrote:
>>>>> 
>>>>> ...
>>>> 
>>>> Well, that's a reasonable point of view. But since the RBridge
>>>> specifying the list of tree roots is the same RBridge that is
>>>> specifying the number of trees (although the number of trees can get
>>>> reduced if there are RBridges in the campus unable to compute the
>>>> requested number...), one wonders why it would specify more than the
>>>> number of valid nicknames in the list it is providing. 
> 
>>> First, there is the case you've enumerated where another RBRIDGE in
>>> the network is not able to support the number of multicast roots in
>>> the list.
>> 
>>> The second case is one of simplicity.  From an administrative point
>>> of few, you'd like to specify the list of available roots and leave
>>> that list intact, regardless of whether these devices are alive or
>>> not.  You'd image the common scenario would have each of the desired
>>> roots advertising the same list.  Then RBRIDGES are able to
>>> calculate the appropriate trees... clearly, you can't calculate a
>>> tree to a root that is not in your LSP database.  The alternative is
>>> to have the list, as advertised by the highest priority RBRIDGE,
>>> shrink and grow each time one of the desired roots comes/goes.  That
>>> is a lot of fluctuation in a transitioning system.
>> 
>> [It's not quite the "highest priority RBridge", although I have been
>> using that phrase for simplicity. It's the RBridge that has the
>> highest priority nickname, but this only makes a difference if there
>> are RBridges with multiple nicknames. For simplicity, I'll continue to
>> talk about the "highest priority RBridge".]
>> 
>> I wasn't suggesting that the list should shrink/grow. In particular,
>> why would you bother to shrink the list? There is nothing wrong with
>> the highest priority RBridge making the list longer than the number of
>> trees that RBridge is specifying as the number that should be
>> calculated. Even if the highest priority RBridge is specifying that
>> number of trees as exactly the list length, you might still have to
>> calculate fewer than are in the list due to some RBridges not being
>> capable of calculating all the trees. So RBridges have to be able to
>> handle the case where the list is longer than the number of trees being
>> computed. Presumably the network manager would normally configure the
>> list of roots at all RBridge in the campus.
>> 
>> I think the only question is what to do if the number of trees to
>> calculate is larger than the length of the list. If there is a list of
>> distribution tree roots, the network manager must have configured it
>> and will presumably configure other aspects of the campus, including
>> the priorities of all the nicknames. It seems to me that, to get the
>> behavior you want, where no other roots beyond those listed are used,
>> the network manager simply configures all the nicknames not on the
>> list to have zero priority. That way they won't be used as a tree root
>> (except as a last resort where it turns out to be the only tree)
>> because zero priority is a special value indicating that you don't
>> want to be a root. If the network manager configures them to have
>> non-zero priorities, then non-listed nicknames can be selected, in
>> priority rank, to fill in the number dictated by the highest priority
>> RBridge, if the list is too short.
> 
> This is the case that we're talking about.  To make sure we're on the same page, my concern with the current spec is the behavior when a list is specified and one or more of the list members are unreachable (links down, system down, etc).  The current spec indicates that any members in the list that are not in the LSP database should be ignored, and the list should be filled in by the selection process.  This seems a bit dangerous.  From your emails, it sounds like your preferred solution is to configure all other Rbridges with a root priority of 0 to avoid this situation.  Experience would suggest that this solution can lead to deployment errors.  I've seen that distributed protocols/fsms work much more predictably when you configure a small number of devices with the desired behavior as opposed to configuring a large number of devices to avoid an undesired behavior.
> 
> Well,  that's reasonable but it doesn't seem too bad to just configure all the RBridges in the campus with the same list of roots and with priority zero. (See also my response below...)
> 
> To this end, I would re-iterate my suggestion that the spec be modified so that when a list is specified, it is definitive and that ONLY Rbridges in the list can be selected as distribution tree roots.  This must be supplemented with a requirement that any Rbridge that advertises a list must be a member of that list (to avoid the no-distribution-tree scenario).
> 
> Saying that all RBridges that advertise a list of roots have to list themselves doesn't make it so. Since you still have to handle the case where this suggested requirement was ignored and you always have to have at least one tree, I don't actually see much point to the requirement.
> 
> The provisions in the current TRILL Proposed Standard were arrived at by discussions among something like half a dozen active TRILL participants and there are implementations efforts underway, some of which are, I believe, close to shipping. So, while I can see some merit to your arguments, unless other people speak up in favor of your views, I don't think this should be changed.
> 
> As an aside, the spec is a not perfectly clear how the root priority of 0 is treated in this situation.  The language from draft 16 is...
> 
>    o  A nickname whose tree root priority is zero is never used as a
>       tree root except that if all nicknames have priority zero, the
>       highest priority among them as determined by the tiebreakers is
>       used as a tree root so that there is always guaranteed to be at
>       least one distribution tree.
> 
> In the situation where you need to select more than one distribution tree root, this requirement can be interpreted in at least two ways...
> 
> a) If you have at least one distribution tree root, you must ignore all Rbridges with a root priority of 0 during further distribution tree selection
> 
> b) When you need to select a root, don't use Rbridges with root priority 0 unless all remaining, unselected Rbridges have root priority 0
> 
> Your paragraph above suggests that a) is the correct behavior, so I'd recommend that the text be modified to make it extremely clear.
> 
> You are completely correct that this is not clear. I believe that text should have started "A nickname whose tree root priority is zero is not selected as a tree root based on priority, except that if all nicknames have priority zero, ..." In other words, the list of roots dominates priority, including priority zero.
> 
> Initially, the draft only had priority in it. When the list of roots was added, I think this text wasn't adjusted.
>  
>>>> It seems clear enough what should happen if the number of trees to
>>>> compute specified by the highest priority RBridge [actually
>>>> nickanme] is the same or less than the number of valid nicknames it
>>>> lists. But consider the corner case when the list has no nicknames
>>>> on it that actually exist in the campus. (Perhaps the list is
>>>> fairly short and the campus has just partitioned or something...)
>>>> In that case, all RBridges have to calculate at least one tree or
>>>> the network will not be fully functional.
>> 
>>> If I understand your scenario correctly, then each RBRIDGE has one
>>> of two views of the world.  In the first, it receives the list from
>>> the highest priority RBRIDGE (I'm assuming that the highest priority
>>> RBRIDGE is a member of the list).  In this case, the RBRIDGE has at
>>> least one multicast root.  In the second case, the RBRIDGE does NOT
>>> receive the list, in this case, it would select the highest priority
>>> RBRIDGE that is sees as the multicast root.
>> 
>> There is no requirement that the highest priority nickname be on the
>> list of distribution trees the RBridge with that nickname
>> advertises. Every RBridge logically advertises a list of tree root
>> nicknames, although it might be the null list. Since they are part of
>> the link state database, every RBridge in the campus has a copy of the
>> list advertised by every RBridge in the campus. Under the procedures
>> given, in a quiescent network, they will all calculate the same trees.
>> 
>>>> Since, in that case, you have to calculate a tree not on
>>>> the list, the highest priority such tree, it seems to me that it is
>>>> slightly more consistent to calculate additional higher priority trees
>>>> if the list is shorter that the number of trees being dictated by the
>>>> highest priority RBridge...
>>>> 
>>>>> JR
>> 
>> Thanks,
>> Donald
>> 
>> PS: By the way, an actual implemention might want to keep around the
>> forwarding entries for a tree that it is no longer computing for a
>> little while to handle frames still in flight in the campus.
> Thanks,
> Donald
> =============================
> Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> 155 Beaver Street   +1-508-634-2066 (home)
> Milford, MA 01757 USA
> d3e3e3 at gmail.com
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100525/d851d89f/attachment.html

From d3e3e3 at gmail.com  Tue May 25 11:56:29 2010
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 25 May 2010 14:56:29 -0400
Subject: [rbridge] Multicast root observation
In-Reply-To: <84F3A5A8-F0AB-4A13-A1B5-30D7E39CE221@cumulusnetworks.com>
References: <93D79258-CF6D-4F53-831D-326F4A93929A@cumulusnetworks.com>
	<x2v1028365c1004180827t88562a04p443b2b720390a596@mail.gmail.com>
	<19F4BE45-B82E-4A70-8FD3-9820D4F96619@cumulusnetworks.com>
	<j2w1028365c1004201258k56dd337eh682d8873ea7bf578@mail.gmail.com>
	<92F6E4F6-86D1-42E2-AE3F-F2C5046DA304@cumulusnetworks.com>
	<AANLkTilHHrKJ-Nv3nC8PNszP06DDqy_rIJHFRV5n5myg@mail.gmail.com>
	<84F3A5A8-F0AB-4A13-A1B5-30D7E39CE221@cumulusnetworks.com>
Message-ID: <AANLkTilkAtPtOx3lPB-7dhpTfAqeQ12lj3YL0_UUrV9d@mail.gmail.com>

Hi JR,

On Tue, May 25, 2010 at 2:35 PM, JR Rivers <jrrivers at cumulusnetworks.com>wrote:

>
> Donald-
>
> Thanks for the lengthy discussion on this topic.
>
> From what I've gathered, two problems have been noted.  One is an ambiguous
> section regarding root priority 0.  You've concurred that this is a
> specification issue.  The second is the "list member availability problem",
> which you've also asserted is a problem; however, you've asserted a specific
> configuration level workaround to attempt fix it.  Will either of these
> issues be addressed in an upcoming draft?
>

I believe that they should be a draft with clarifications and errata for the
TRILL base protocol standard. A few clarifications have accumulated on this
mailing list. Not sure there are any actual errata yet...

Cheers,
>
> JR
>

Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100525/07d3175e/attachment-0001.html

From harih at cisco.com  Wed May 26 08:14:54 2010
From: harih at cisco.com (Hari Balasubramanian (harih))
Date: Wed, 26 May 2010 08:14:54 -0700
Subject: [rbridge] Do people prefer new ISIS PDU types for advertising
	multicast groups?
In-Reply-To: <C806598A.50655%ayabaner@cisco.com>
References: <n2vc09b97ef1004281333r21ecf051ne02ecb25fcb49ad@mail.gmail.com>
	<C806598A.50655%ayabaner@cisco.com>
Message-ID: <1CCF0A858F9B194FABEA71E9B65EA88B0CE714FB@xmb-sjc-214.amer.cisco.com>

I agree with Ayan's comments here. It has been the understanding of early implementers of TRILL spec that the pros and cons of using new ISIS PDU types for advertising multicast groups  were discussed and  it was agreed to use new PDU types as early as April 2009. It has been more than an year since such an understanding was reached and it is concerning that the issue is being opened again. Are there any new concerns that are being raised now that did not come up during the discussions last year? 

I understand the early implementers of any protocol, especially before standardization, should be well aware of the risk of some churn in the specs, based on wider comments etc. But I believe it is not unreasonable to hope that the approaches on which a consensus was developed will substantially retain the structure as per the consensus, especially the ones that have been made an year or more back.

Thanks, Hari

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Ayan Banerjee (ayabaner)
> Sent: Tuesday, May 04, 2010 11:09 PM
> To: Radia Perlman; James Carlson
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Do people prefer new ISIS PDU types for
> advertising multicast groups?
> 
> 
> I believe that we had substantial discussion on the merits of this
> approach.
> I have attached a pointer to the meeting minutes on this after IETF-73
> -
> http://tools.ietf.org/wg/isis/minutes?item=minutes73.html . There was
> also a
> lot of discussion on this during the Feb/March/April 2009 timeframe in
> the
> IS-IS WG mailing list on this.
> 
> In summary, the reasons outlined during those discussions are:
> - Separation is desired since the join/leave frequency
>   of the multicast members will be much higher than unicast topology
>   changes.
> - Opens up space for additional fragments to improve scalability
>   and carrying capacity of the base protocol
> - Operational convenience of having separate unicast and
>   multicast information.
> - Use of other extensions to the protocols, like Extended LSP,
>   Multi-Instance support etc, just fall in place.
> 
> This additional PDU introduces very minimal complexity into the
> process. The
> update process of MGROUP-PDU follows the exact same design/update flow
> as
> the regular PDU. This flow is well understood and other than just
> maintaining a parallel database, there is really not much of a concern
> here.
> 
> This PDU has been out there in the WG for 18 odd months now. I am a bit
> concerned about changing things at this juncture, when we should be
> really
> wrapping things up.
> 
> Thanks,
> Ayan
> 
> 
> On 4/28/10 1:33 PM, "Radia Perlman" <radiaperlman at gmail.com> wrote:
> 
> > But I still prefer not doing anything; no flag, no new PDU types.
> >
> > IS-IS as originally designed for DECnet/CLNP had endnode information
> > in LSPs. The same argument could have been made back then -- that
> > there should be a different type of LSP for the endnode information
> > because that wouldn't trigger SPF, and would be more volatile.
> >
> > Merely recommending that the more volatile, non-SPF-producing
> > information go into separate fragments, seems solution enough. Any RB
> > not following that will cause a bit of suboptimality, but no other
> > problems.
> >
> > Radia
> >
> >
> >
> > On Wed, Apr 28, 2010 at 12:48 PM, James Carlson
> > <carlsonj at workingcode.com> wrote:
> >> Radia Perlman wrote:
> >>> Re: James question below
> >>>
> >>> Ah. I was assuming that you'd only set the flag if the fragment
> only
> >>> contains endnode information, and that fragment number NEVER
> contained
> >>> anything but endnode information.
> >>>
> >>> I think you were assuming I was recommending you'd set the flag if
> the
> >>> adjacencies reported there haven't changed, or that previous
> sequence
> >>> numbers of that fragment contained adjacencies that got removed
> from
> >>> that fragment because of going down, or being moved to another
> >>> fragment.
> >>
> >> Exactly.
> >>
> >>> I was recommending setting the flag only if the only TLVs in the
> >>> fragment are endnode type information (which in TRILL would only be
> >>> multicast groups), and that fragment n *never* contained anything
> but
> >>> endnode information (though it's not a problem if those adjacencies
> >>> get moved to a different fragment...it's just a problem if they go
> >>> away and their absence is SPF-relevant information). If advertising
> >>> multicast groups is relegated to its own fragment, then this
> wouldn't
> >>> be a problem.
> >>
> >> Based on what I remember in Quagga, I think that might be hard to
> >> achieve there, but I can imagine that someone who tracks fragment
> >> contents over time more carefully could do this.
> >>
> >> Thanks; I get it now. ?I'm not sure where (in what implementation)
> it'd
> >> be workable, but at least I understand how it'd function.
> >>
> >> --
> >> James Carlson ? ? ? ? 42.703N 71.076W
> <carlsonj at workingcode.com>
> >>
> >
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge


From d3e3e3 at gmail.com  Wed May 26 08:37:44 2010
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Wed, 26 May 2010 11:37:44 -0400
Subject: [rbridge] TRILL and L2-IS-IS EtherTypes assigned
Message-ID: <AANLkTin6ogE1OGbzT0XgedK6taEJIii0T65_T4r2ucMR@mail.gmail.com>

Hi,

The IEEE Registration Authority has assigned the following Ethertypes:

     0x22F3   TRILL
     0x22F4   L2-IS-IS

These, along with the block of multicast addresses previously
assigned, complete all the IEEE Registration Authority actions
required for implementation of the TRILL base protocol standard.

Thanks,
Donald

PS: See http://www.postel.org/pipermail/rbridge/2010-April/003980.html
for information on the earlier multicast address block assignment.
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com

From radiaperlman at gmail.com  Wed May 26 09:45:20 2010
From: radiaperlman at gmail.com (Radia Perlman)
Date: Wed, 26 May 2010 09:45:20 -0700
Subject: [rbridge] Do people prefer new ISIS PDU types for advertising
	multicast groups?
In-Reply-To: <1CCF0A858F9B194FABEA71E9B65EA88B0CE714FB@xmb-sjc-214.amer.cisco.com>
References: <n2vc09b97ef1004281333r21ecf051ne02ecb25fcb49ad@mail.gmail.com>
	<C806598A.50655%ayabaner@cisco.com>
	<1CCF0A858F9B194FABEA71E9B65EA88B0CE714FB@xmb-sjc-214.amer.cisco.com>
Message-ID: <AANLkTin7D2RmrDQyGtOADhuqc-bkk_6ryS_k60n2_-Vp@mail.gmail.com>

It was never discussed on the TRILL list, and a lot of people
(including me) assumed that the l2-ISIS spec was just defining syntax
of the fields explicitly called out in the TRILL protocol spec, which
lists all the fields to be included in Hello and LSP.  A design issue
like that should be discussed on the TRILL mailing list and, if there
were a consensus in TRILL for something like that, it should be
covered in the TRILL protocol spec (in addition to having the syntax
in the l2-ISIS spec).

So, definitely I'm sorry I didn't pay more attention to that spec,
but my understanding was that the fields TRILL needed were explicitly
listed in the TRILL protocol document, and so I assumed the l2-isis
document was just syntax, so I could safely ignore it.

Radia



On Wed, May 26, 2010 at 8:14 AM, Hari Balasubramanian (harih)
<harih at cisco.com> wrote:
> I agree with Ayan's comments here. It has been the understanding of early implementers of TRILL spec that the pros and cons of using new ISIS PDU types for advertising multicast groups ?were discussed and ?it was agreed to use new PDU types as early as April 2009. It has been more than an year since such an understanding was reached and it is concerning that the issue is being opened again. Are there any new concerns that are being raised now that did not come up during the discussions last year?
>
> I understand the early implementers of any protocol, especially before standardization, should be well aware of the risk of some churn in the specs, based on wider comments etc. But I believe it is not unreasonable to hope that the approaches on which a consensus was developed will substantially retain the structure as per the consensus, especially the ones that have been made an year or more back.
>
> Thanks, Hari
>
>> -----Original Message-----
>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
>> Behalf Of Ayan Banerjee (ayabaner)
>> Sent: Tuesday, May 04, 2010 11:09 PM
>> To: Radia Perlman; James Carlson
>> Cc: rbridge at postel.org
>> Subject: Re: [rbridge] Do people prefer new ISIS PDU types for
>> advertising multicast groups?
>>
>>
>> I believe that we had substantial discussion on the merits of this
>> approach.
>> I have attached a pointer to the meeting minutes on this after IETF-73
>> -
>> http://tools.ietf.org/wg/isis/minutes?item=minutes73.html . There was
>> also a
>> lot of discussion on this during the Feb/March/April 2009 timeframe in
>> the
>> IS-IS WG mailing list on this.
>>
>> In summary, the reasons outlined during those discussions are:
>> - Separation is desired since the join/leave frequency
>> ? of the multicast members will be much higher than unicast topology
>> ? changes.
>> - Opens up space for additional fragments to improve scalability
>> ? and carrying capacity of the base protocol
>> - Operational convenience of having separate unicast and
>> ? multicast information.
>> - Use of other extensions to the protocols, like Extended LSP,
>> ? Multi-Instance support etc, just fall in place.
>>
>> This additional PDU introduces very minimal complexity into the
>> process. The
>> update process of MGROUP-PDU follows the exact same design/update flow
>> as
>> the regular PDU. This flow is well understood and other than just
>> maintaining a parallel database, there is really not much of a concern
>> here.
>>
>> This PDU has been out there in the WG for 18 odd months now. I am a bit
>> concerned about changing things at this juncture, when we should be
>> really
>> wrapping things up.
>>
>> Thanks,
>> Ayan
>>
>>
>> On 4/28/10 1:33 PM, "Radia Perlman" <radiaperlman at gmail.com> wrote:
>>
>> > But I still prefer not doing anything; no flag, no new PDU types.
>> >
>> > IS-IS as originally designed for DECnet/CLNP had endnode information
>> > in LSPs. The same argument could have been made back then -- that
>> > there should be a different type of LSP for the endnode information
>> > because that wouldn't trigger SPF, and would be more volatile.
>> >
>> > Merely recommending that the more volatile, non-SPF-producing
>> > information go into separate fragments, seems solution enough. Any RB
>> > not following that will cause a bit of suboptimality, but no other
>> > problems.
>> >
>> > Radia
>> >
>> >
>> >
>> > On Wed, Apr 28, 2010 at 12:48 PM, James Carlson
>> > <carlsonj at workingcode.com> wrote:
>> >> Radia Perlman wrote:
>> >>> Re: James question below
>> >>>
>> >>> Ah. I was assuming that you'd only set the flag if the fragment
>> only
>> >>> contains endnode information, and that fragment number NEVER
>> contained
>> >>> anything but endnode information.
>> >>>
>> >>> I think you were assuming I was recommending you'd set the flag if
>> the
>> >>> adjacencies reported there haven't changed, or that previous
>> sequence
>> >>> numbers of that fragment contained adjacencies that got removed
>> from
>> >>> that fragment because of going down, or being moved to another
>> >>> fragment.
>> >>
>> >> Exactly.
>> >>
>> >>> I was recommending setting the flag only if the only TLVs in the
>> >>> fragment are endnode type information (which in TRILL would only be
>> >>> multicast groups), and that fragment n *never* contained anything
>> but
>> >>> endnode information (though it's not a problem if those adjacencies
>> >>> get moved to a different fragment...it's just a problem if they go
>> >>> away and their absence is SPF-relevant information). If advertising
>> >>> multicast groups is relegated to its own fragment, then this
>> wouldn't
>> >>> be a problem.
>> >>
>> >> Based on what I remember in Quagga, I think that might be hard to
>> >> achieve there, but I can imagine that someone who tracks fragment
>> >> contents over time more carefully could do this.
>> >>
>> >> Thanks; I get it now. ?I'm not sure where (in what implementation)
>> it'd
>> >> be workable, but at least I understand how it'd function.
>> >>
>> >> --
>> >> James Carlson ? ? ? ? 42.703N 71.076W
>> <carlsonj at workingcode.com>
>> >>
>> >
>> > _______________________________________________
>> > rbridge mailing list
>> > rbridge at postel.org
>> > http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>


From d3e3e3 at gmail.com  Thu May 27 20:30:58 2010
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 27 May 2010 23:30:58 -0400
Subject: [rbridge] Fwd: [Pppext] I-D
	Action:draft-ietf-pppext-trill-protocol-01.txt
In-Reply-To: <20100527164502.B487E3A6AFA@core3.amsl.com>
References: <20100527164502.B487E3A6AFA@core3.amsl.com>
Message-ID: <AANLkTikORZ1dtSQQMSdLyMpTxGzOijuFu5NdERq8t4n_@mail.gmail.com>

Hi,

A new version of the TRILL over PPP draft has been posted.

Thanks,
Donald

---------- Forwarded message ----------
From:  <Internet-Drafts at ietf.org>
Date: Thu, May 27, 2010 at 12:45 PM
Subject: [Pppext] I-D Action:draft-ietf-pppext-trill-protocol-01.txt
To: i-d-announce at ietf.org
Cc: pppext at ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Point-to-Point Protocol Extensions
Working Group of the IETF.


? ? ? ?Title ? ? ? ? ? : PPP TRILL Protocol Control Protocol
? ? ? ?Author(s) ? ? ? : J. Carlson
? ? ? ?Filename ? ? ? ?: draft-ietf-pppext-trill-protocol-01.txt
? ? ? ?Pages ? ? ? ? ? : 6
? ? ? ?Date ? ? ? ? ? ?: 2010-05-27

The Point-to-Point Protocol (PPP) [1] defines a Link Control Protocol
(LCP) and a method for negotiating the use of multi-protocol traffic
over point-to-point links. ?This document describes support for
Transparent Interconnection of Lots of Links (TRILL) Protocol,
allowing direct communication between Routing Bridges (RBridges) via
PPP links.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Pppext mailing list
Pppext at ietf.org
https://www.ietf.org/mailman/listinfo/pppext


From erik.nordmark at oracle.com  Fri May 28 05:44:24 2010
From: erik.nordmark at oracle.com (Erik Nordmark)
Date: Fri, 28 May 2010 05:44:24 -0700
Subject: [rbridge] Do people prefer new ISIS PDU types for advertising
 multicast groups?
In-Reply-To: <1CCF0A858F9B194FABEA71E9B65EA88B0CE714FB@xmb-sjc-214.amer.cisco.com>
References: <n2vc09b97ef1004281333r21ecf051ne02ecb25fcb49ad@mail.gmail.com>	<C806598A.50655%ayabaner@cisco.com>
	<1CCF0A858F9B194FABEA71E9B65EA88B0CE714FB@xmb-sjc-214.amer.cisco.com>
Message-ID: <4BFFBAA8.6090608@oracle.com>

On 05/26/10 08:14 AM, Hari Balasubramanian (harih) wrote:
> I agree with Ayan's comments here. It has been the understanding of early implementers of TRILL spec that the pros and cons of using new ISIS PDU types for advertising multicast groups  were discussed and  it was agreed to use new PDU types as early as April 2009. It has been more than an year since such an understanding was reached and it is concerning that the issue is being opened again. Are there any new concerns that are being raised now that did not come up during the discussions last year?

I don't recall such discussion in the TRILL WG. Do you have references 
to minutes or emails for the TRILL WG indicating when we discussed this?

Ayan was referring to ISIS minutes, which is different.

    Erik

> I understand the early implementers of any protocol, especially before standardization, should be well aware of the risk of some churn in the specs, based on wider comments etc. But I believe it is not unreasonable to hope that the approaches on which a consensus was developed will substantially retain the structure as per the consensus, especially the ones that have been made an year or more back.
>
> Thanks, Hari
>
>> -----Original Message-----
>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
>> Behalf Of Ayan Banerjee (ayabaner)
>> Sent: Tuesday, May 04, 2010 11:09 PM
>> To: Radia Perlman; James Carlson
>> Cc: rbridge at postel.org
>> Subject: Re: [rbridge] Do people prefer new ISIS PDU types for
>> advertising multicast groups?
>>
>>
>> I believe that we had substantial discussion on the merits of this
>> approach.
>> I have attached a pointer to the meeting minutes on this after IETF-73
>> -
>> http://tools.ietf.org/wg/isis/minutes?item=minutes73.html . There was
>> also a
>> lot of discussion on this during the Feb/March/April 2009 timeframe in
>> the
>> IS-IS WG mailing list on this.
>>
>> In summary, the reasons outlined during those discussions are:
>> - Separation is desired since the join/leave frequency
>>    of the multicast members will be much higher than unicast topology
>>    changes.
>> - Opens up space for additional fragments to improve scalability
>>    and carrying capacity of the base protocol
>> - Operational convenience of having separate unicast and
>>    multicast information.
>> - Use of other extensions to the protocols, like Extended LSP,
>>    Multi-Instance support etc, just fall in place.
>>
>> This additional PDU introduces very minimal complexity into the
>> process. The
>> update process of MGROUP-PDU follows the exact same design/update flow
>> as
>> the regular PDU. This flow is well understood and other than just
>> maintaining a parallel database, there is really not much of a concern
>> here.
>>
>> This PDU has been out there in the WG for 18 odd months now. I am a bit
>> concerned about changing things at this juncture, when we should be
>> really
>> wrapping things up.
>>
>> Thanks,
>> Ayan
>>
>>
>> On 4/28/10 1:33 PM, "Radia Perlman"<radiaperlman at gmail.com>  wrote:
>>
>>> But I still prefer not doing anything; no flag, no new PDU types.
>>>
>>> IS-IS as originally designed for DECnet/CLNP had endnode information
>>> in LSPs. The same argument could have been made back then -- that
>>> there should be a different type of LSP for the endnode information
>>> because that wouldn't trigger SPF, and would be more volatile.
>>>
>>> Merely recommending that the more volatile, non-SPF-producing
>>> information go into separate fragments, seems solution enough. Any RB
>>> not following that will cause a bit of suboptimality, but no other
>>> problems.
>>>
>>> Radia
>>>
>>>
>>>
>>> On Wed, Apr 28, 2010 at 12:48 PM, James Carlson
>>> <carlsonj at workingcode.com>  wrote:
>>>> Radia Perlman wrote:
>>>>> Re: James question below
>>>>>
>>>>> Ah. I was assuming that you'd only set the flag if the fragment
>> only
>>>>> contains endnode information, and that fragment number NEVER
>> contained
>>>>> anything but endnode information.
>>>>>
>>>>> I think you were assuming I was recommending you'd set the flag if
>> the
>>>>> adjacencies reported there haven't changed, or that previous
>> sequence
>>>>> numbers of that fragment contained adjacencies that got removed
>> from
>>>>> that fragment because of going down, or being moved to another
>>>>> fragment.
>>>>
>>>> Exactly.
>>>>
>>>>> I was recommending setting the flag only if the only TLVs in the
>>>>> fragment are endnode type information (which in TRILL would only be
>>>>> multicast groups), and that fragment n *never* contained anything
>> but
>>>>> endnode information (though it's not a problem if those adjacencies
>>>>> get moved to a different fragment...it's just a problem if they go
>>>>> away and their absence is SPF-relevant information). If advertising
>>>>> multicast groups is relegated to its own fragment, then this
>> wouldn't
>>>>> be a problem.
>>>>
>>>> Based on what I remember in Quagga, I think that might be hard to
>>>> achieve there, but I can imagine that someone who tracks fragment
>>>> contents over time more carefully could do this.
>>>>
>>>> Thanks; I get it now.  I'm not sure where (in what implementation)
>> it'd
>>>> be workable, but at least I understand how it'd function.
>>>>
>>>> --
>>>> James Carlson         42.703N 71.076W
>> <carlsonj at workingcode.com>
>>>>
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> rbridge at postel.org
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge


From harih at cisco.com  Fri May 28 06:25:50 2010
From: harih at cisco.com (Hari Balasubramanian (harih))
Date: Fri, 28 May 2010 06:25:50 -0700
Subject: [rbridge] Do people prefer new ISIS PDU types for advertising
	multicast groups?
In-Reply-To: <4BFFBAA8.6090608@oracle.com>
References: <n2vc09b97ef1004281333r21ecf051ne02ecb25fcb49ad@mail.gmail.com>	<C806598A.50655%ayabaner@cisco.com><1CCF0A858F9B194FABEA71E9B65EA88B0CE714FB@xmb-sjc-214.amer.cisco.com>
	<4BFFBAA8.6090608@oracle.com>
Message-ID: <1CCF0A858F9B194FABEA71E9B65EA88B0CF1EA25@xmb-sjc-214.amer.cisco.com>

> Do you have references
> to minutes or emails for the TRILL WG indicating when we discussed
> this?

Sorry, I do not recall any emails on TRILL WG on this topic. I was also
referring to ISIS WG minutes.

Thanks, Hari

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Erik Nordmark
> Sent: Friday, May 28, 2010 5:44 AM
> To: rbridge at postel.org
> Subject: Re: [rbridge] Do people prefer new ISIS PDU types for
> advertising multicast groups?
> 
> On 05/26/10 08:14 AM, Hari Balasubramanian (harih) wrote:
> > I agree with Ayan's comments here. It has been the understanding of
> early implementers of TRILL spec that the pros and cons of using new
> ISIS PDU types for advertising multicast groups  were discussed and
it
> was agreed to use new PDU types as early as April 2009. It has been
> more than an year since such an understanding was reached and it is
> concerning that the issue is being opened again. Are there any new
> concerns that are being raised now that did not come up during the
> discussions last year?
> 
> I don't recall such discussion in the TRILL WG. Do you have references
> to minutes or emails for the TRILL WG indicating when we discussed
> this?
> 
> Ayan was referring to ISIS minutes, which is different.
> 
>     Erik
> 
> > I understand the early implementers of any protocol, especially
> before standardization, should be well aware of the risk of some churn
> in the specs, based on wider comments etc. But I believe it is not
> unreasonable to hope that the approaches on which a consensus was
> developed will substantially retain the structure as per the
consensus,
> especially the ones that have been made an year or more back.
> >
> > Thanks, Hari
> >
> >> -----Original Message-----
> >> From: rbridge-bounces at postel.org
[mailto:rbridge-bounces at postel.org]
> On
> >> Behalf Of Ayan Banerjee (ayabaner)
> >> Sent: Tuesday, May 04, 2010 11:09 PM
> >> To: Radia Perlman; James Carlson
> >> Cc: rbridge at postel.org
> >> Subject: Re: [rbridge] Do people prefer new ISIS PDU types for
> >> advertising multicast groups?
> >>
> >>
> >> I believe that we had substantial discussion on the merits of this
> >> approach.
> >> I have attached a pointer to the meeting minutes on this after
IETF-
> 73
> >> -
> >> http://tools.ietf.org/wg/isis/minutes?item=minutes73.html . There
> was
> >> also a
> >> lot of discussion on this during the Feb/March/April 2009 timeframe
> in
> >> the
> >> IS-IS WG mailing list on this.
> >>
> >> In summary, the reasons outlined during those discussions are:
> >> - Separation is desired since the join/leave frequency
> >>    of the multicast members will be much higher than unicast
> topology
> >>    changes.
> >> - Opens up space for additional fragments to improve scalability
> >>    and carrying capacity of the base protocol
> >> - Operational convenience of having separate unicast and
> >>    multicast information.
> >> - Use of other extensions to the protocols, like Extended LSP,
> >>    Multi-Instance support etc, just fall in place.
> >>
> >> This additional PDU introduces very minimal complexity into the
> >> process. The
> >> update process of MGROUP-PDU follows the exact same design/update
> flow
> >> as
> >> the regular PDU. This flow is well understood and other than just
> >> maintaining a parallel database, there is really not much of a
> concern
> >> here.
> >>
> >> This PDU has been out there in the WG for 18 odd months now. I am a
> bit
> >> concerned about changing things at this juncture, when we should be
> >> really
> >> wrapping things up.
> >>
> >> Thanks,
> >> Ayan
> >>
> >>
> >> On 4/28/10 1:33 PM, "Radia Perlman"<radiaperlman at gmail.com>  wrote:
> >>
> >>> But I still prefer not doing anything; no flag, no new PDU types.
> >>>
> >>> IS-IS as originally designed for DECnet/CLNP had endnode
> information
> >>> in LSPs. The same argument could have been made back then -- that
> >>> there should be a different type of LSP for the endnode
information
> >>> because that wouldn't trigger SPF, and would be more volatile.
> >>>
> >>> Merely recommending that the more volatile, non-SPF-producing
> >>> information go into separate fragments, seems solution enough. Any
> RB
> >>> not following that will cause a bit of suboptimality, but no other
> >>> problems.
> >>>
> >>> Radia
> >>>
> >>>
> >>>
> >>> On Wed, Apr 28, 2010 at 12:48 PM, James Carlson
> >>> <carlsonj at workingcode.com>  wrote:
> >>>> Radia Perlman wrote:
> >>>>> Re: James question below
> >>>>>
> >>>>> Ah. I was assuming that you'd only set the flag if the fragment
> >> only
> >>>>> contains endnode information, and that fragment number NEVER
> >> contained
> >>>>> anything but endnode information.
> >>>>>
> >>>>> I think you were assuming I was recommending you'd set the flag
> if
> >> the
> >>>>> adjacencies reported there haven't changed, or that previous
> >> sequence
> >>>>> numbers of that fragment contained adjacencies that got removed
> >> from
> >>>>> that fragment because of going down, or being moved to another
> >>>>> fragment.
> >>>>
> >>>> Exactly.
> >>>>
> >>>>> I was recommending setting the flag only if the only TLVs in the
> >>>>> fragment are endnode type information (which in TRILL would only
> be
> >>>>> multicast groups), and that fragment n *never* contained
anything
> >> but
> >>>>> endnode information (though it's not a problem if those
> adjacencies
> >>>>> get moved to a different fragment...it's just a problem if they
> go
> >>>>> away and their absence is SPF-relevant information). If
> advertising
> >>>>> multicast groups is relegated to its own fragment, then this
> >> wouldn't
> >>>>> be a problem.
> >>>>
> >>>> Based on what I remember in Quagga, I think that might be hard to
> >>>> achieve there, but I can imagine that someone who tracks fragment
> >>>> contents over time more carefully could do this.
> >>>>
> >>>> Thanks; I get it now.  I'm not sure where (in what
implementation)
> >> it'd
> >>>> be workable, but at least I understand how it'd function.
> >>>>
> >>>> --
> >>>> James Carlson         42.703N 71.076W
> >> <carlsonj at workingcode.com>
> >>>>
> >>>
> >>> _______________________________________________
> >>> rbridge mailing list
> >>> rbridge at postel.org
> >>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>
> >>
> >> _______________________________________________
> >> rbridge mailing list
> >> rbridge at postel.org
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge


From jukka.manner at tkk.fi  Fri May 28 07:43:08 2010
From: jukka.manner at tkk.fi (Jukka Manner)
Date: Fri, 28 May 2010 17:43:08 +0300
Subject: [rbridge] Threat and security analysis?
In-Reply-To: <4BFFBAA8.6090608@oracle.com>
References: <n2vc09b97ef1004281333r21ecf051ne02ecb25fcb49ad@mail.gmail.com>
	<C806598A.50655%ayabaner@cisco.com>
	<1CCF0A858F9B194FABEA71E9B65EA88B0CE714FB@xmb-sjc-214.amer.cisco.com>
	<4BFFBAA8.6090608@oracle.com>
Message-ID: <4BFFD67C.4060804@tkk.fi>

Hi,

I was wondering, has anyone done a detailed analysis of the threats 
associated with deploying and using TRILL? All the WG documens basically 
just go around the topic by comparing and refering to other similar 
technologies and saying that TRILL should not be worse.

Regards,
Jukka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jukka_manner.vcf
Type: text/x-vcard
Size: 359 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20100528/b9fb26a3/jukka_manner.vcf

From touch at isi.edu  Fri May 28 08:18:50 2010
From: touch at isi.edu (Joe Touch)
Date: Fri, 28 May 2010 08:18:50 -0700
Subject: [rbridge] Threat and security analysis?
In-Reply-To: <4BFFD67C.4060804@tkk.fi>
References: <n2vc09b97ef1004281333r21ecf051ne02ecb25fcb49ad@mail.gmail.com>	<C806598A.50655%ayabaner@cisco.com>	<1CCF0A858F9B194FABEA71E9B65EA88B0CE714FB@xmb-sjc-214.amer.cisco.com>	<4BFFBAA8.6090608@oracle.com>
	<4BFFD67C.4060804@tkk.fi>
Message-ID: <4BFFDEDA.1090907@isi.edu>

Hi, Jukka,

Jukka Manner wrote:
> Hi,
> 
> I was wondering, has anyone done a detailed analysis of the threats
> associated with deploying and using TRILL? All the WG documens basically
> just go around the topic by comparing and refering to other similar
> technologies and saying that TRILL should not be worse.

While I realize that such analyses are currently popular, what exactly
is worth stating beyond "we're not worse than Ethernet"? Does that need
to be shown in detail, e.g., in regards to the protocols/mechanisms we add:

- IS-IS
	which we now depend on, rather than STP

- edge label tables
	which should have the same issues as ARP

It would be useful to point us to a similar threat analysis of Ethernet
to build upon, but the key question I would have is:

	what do you expect in this doc that isn't already in
	the Security Considerations of the RFCs?

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20100528/6a60d8dd/signature.bin

From jukka.manner at tkk.fi  Fri May 28 08:44:58 2010
From: jukka.manner at tkk.fi (Jukka Manner)
Date: Fri, 28 May 2010 18:44:58 +0300
Subject: [rbridge] Threat and security analysis?
In-Reply-To: <4908_1275060733_ZZ0L3400BMJZ5HB0.00_4BFFDEDA.1090907@isi.edu>
References: <n2vc09b97ef1004281333r21ecf051ne02ecb25fcb49ad@mail.gmail.com>
	<C806598A.50655%ayabaner@cisco.com>
	<1CCF0A858F9B194FABEA71E9B65EA88B0CE714FB@xmb-sjc-214.amer.cisco.com>
	<4BFFBAA8.6090608@oracle.com> <4BFFD67C.4060804@tkk.fi>
	<4908_1275060733_ZZ0L3400BMJZ5HB0.00_4BFFDEDA.1090907@isi.edu>
Message-ID: <4BFFE4FA.7000405@tkk.fi>

Hi Joe,

I was mostly thinking in the direction of

a) Deployment guidelines: what people should understand when looking for 
deploying TRILL. Yes, concrete details would be good.

b) Future work: how could we make TRILL more secure and trustworthy than 
legacy Ethernet since we don't need to carry all that legacy (yes, I 
know, the simplicity requirement of TRILL is against this).

I don't have a pointer to Ethernet for comparison.

Jukka

On 28.5.2010 18:18, Joe Touch wrote:
> Hi, Jukka,
>
> Jukka Manner wrote:
>> Hi,
>>
>> I was wondering, has anyone done a detailed analysis of the threats
>> associated with deploying and using TRILL? All the WG documens basically
>> just go around the topic by comparing and refering to other similar
>> technologies and saying that TRILL should not be worse.
>
> While I realize that such analyses are currently popular, what exactly
> is worth stating beyond "we're not worse than Ethernet"? Does that need
> to be shown in detail, e.g., in regards to the protocols/mechanisms we add:
>
> - IS-IS
> 	which we now depend on, rather than STP
>
> - edge label tables
> 	which should have the same issues as ARP
>
> It would be useful to point us to a similar threat analysis of Ethernet
> to build upon, but the key question I would have is:
>
> 	what do you expect in this doc that isn't already in
> 	the Security Considerations of the RFCs?
>
> Joe
>
>
>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jukka_manner.vcf
Type: text/x-vcard
Size: 359 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20100528/0d4bcb9c/jukka_manner-0001.vcf

From andy at nosignal.org  Fri May 28 09:11:48 2010
From: andy at nosignal.org (Andy Davidson)
Date: Fri, 28 May 2010 17:11:48 +0100
Subject: [rbridge] Threat and security analysis?
In-Reply-To: <4BFFE4FA.7000405@tkk.fi>
References: <n2vc09b97ef1004281333r21ecf051ne02ecb25fcb49ad@mail.gmail.com>
	<C806598A.50655%ayabaner@cisco.com>
	<1CCF0A858F9B194FABEA71E9B65EA88B0CE714FB@xmb-sjc-214.amer.cisco.com>
	<4BFFBAA8.6090608@oracle.com> <4BFFD67C.4060804@tkk.fi>
	<4908_1275060733_ZZ0L3400BMJZ5HB0.00_4BFFDEDA.1090907@isi.edu>
	<4BFFE4FA.7000405@tkk.fi>
Message-ID: <4702981D-CF6B-4D55-BAD7-662B8520C120@nosignal.org>

On 28 May 2010, at 16:44, Jukka Manner <jukka.manner at tkk.fi> wrote:

> Hi Joe,
> 
> I was mostly thinking in the direction of
> 
> a) Deployment guidelines: what people should understand when looking for deploying TRILL. Yes, concrete details would be good.

Yes, please. 

> b) Future work: how could we make TRILL more secure and trustworthy than legacy Ethernet since we don't need to carry all that legacy (yes, I know, the simplicity requirement of TRILL is against this).

No, thank you.  Not every packet on a network segment will pass through an inter switch link that encapsulates the frame inside a trill packet.  Therefore, operators will need to do everything at the security layer that they do today, and can't rely on new security features in trill. Let's stick to building a robust method to mesh layer 2 networks with loops, and get this shipped!

Andy    

From erik.nordmark at oracle.com  Fri May 28 10:28:25 2010
From: erik.nordmark at oracle.com (Erik Nordmark)
Date: Fri, 28 May 2010 10:28:25 -0700
Subject: [rbridge] Threat and security analysis?
In-Reply-To: <4BFFE4FA.7000405@tkk.fi>
References: <n2vc09b97ef1004281333r21ecf051ne02ecb25fcb49ad@mail.gmail.com>	<C806598A.50655%ayabaner@cisco.com>	<1CCF0A858F9B194FABEA71E9B65EA88B0CE714FB@xmb-sjc-214.amer.cisco.com>	<4BFFBAA8.6090608@oracle.com>
	<4BFFD67C.4060804@tkk.fi>	<4908_1275060733_ZZ0L3400BMJZ5HB0.00_4BFFDEDA.1090907@isi.edu>
	<4BFFE4FA.7000405@tkk.fi>
Message-ID: <4BFFFD39.1060903@oracle.com>

On 05/28/10 08:44 AM, Jukka Manner wrote:
> Hi Joe,
>
> I was mostly thinking in the direction of
>
> a) Deployment guidelines: what people should understand when looking for
> deploying TRILL. Yes, concrete details would be good.
>
> b) Future work: how could we make TRILL more secure and trustworthy than
> legacy Ethernet since we don't need to carry all that legacy (yes, I
> know, the simplicity requirement of TRILL is against this).

Earlier we had talked about the option of getting more security using 
the combination of:
  - IS-IS with reasonable security (something which already exists in IS-IS)
  - Using ESADI for host address announcements (supported in the 
standard with higher confidence then the learned addresses)
  - Using 802.1X or similar as the only want an edge rbridge would add a 
MAC address to its ESADI announcements.

If somebody wants to work on this it might make sense to right it up as 
an informational document. I don't think any new standards work would be 
needed - it is more a question about gluing together the pieces and 
looking at what the resulting security would be for such an approach.

    Erik



From touch at isi.edu  Sat May 29 10:16:25 2010
From: touch at isi.edu (Joe Touch)
Date: Sat, 29 May 2010 10:16:25 -0700
Subject: [rbridge] Threat and security analysis?
In-Reply-To: <4BFFE4FA.7000405@tkk.fi>
References: <n2vc09b97ef1004281333r21ecf051ne02ecb25fcb49ad@mail.gmail.com>
	<C806598A.50655%ayabaner@cisco.com>
	<1CCF0A858F9B194FABEA71E9B65EA88B0CE714FB@xmb-sjc-214.amer.cisco.com>
	<4BFFBAA8.6090608@oracle.com> <4BFFD67C.4060804@tkk.fi>
	<4908_1275060733_ZZ0L3400BMJZ5HB0.00_4BFFDEDA.1090907@isi.edu>
	<4BFFE4FA.7000405@tkk.fi>
Message-ID: <4C014BE9.2000102@isi.edu>

Hi, Jukka,

Jukka Manner wrote:
> Hi Joe,
> 
> I was mostly thinking in the direction of
> 
> a) Deployment guidelines: what people should understand when looking for
> deploying TRILL. Yes, concrete details would be good.
> 
> b) Future work: how could we make TRILL more secure and trustworthy than
> legacy Ethernet since we don't need to carry all that legacy (yes, I
> know, the simplicity requirement of TRILL is against this).

I don't understand this goal; TRILL relies on Ethernet. Just as it can't make
Ethernet scale, it can't make Ethernet more secure than it already is.

*IF* we're going to address TRILL security, IMO it needs to be limited to the
ways in which TRILL extends Ethernet only.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20100529/f7eac697/signature.bin