From ginsberg at cisco.com  Mon May  2 09:41:11 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Mon, 2 May 2011 09:41:11 -0700
Subject: [rbridge] [Isis-wg] Comments
	ondraft-ietf-trill-rbridge-af-02.txt
In-Reply-To: <BANLkTiks3HPE=a=08DniOhAdjzhFXOT=sw@mail.gmail.com>
References: <20110419230001.13811.8107.idtracker@ietfc.amsl.com><AE36820147909644AD2A7CA014B1FB520E0A32EE@xmb-sjc-222.amer.cisco.com>
	<BANLkTiks3HPE=a=08DniOhAdjzhFXOT=sw@mail.gmail.com>
Message-ID: <AE36820147909644AD2A7CA014B1FB520E1E57B4@xmb-sjc-222.amer.cisco.com>

Donald -

I suspect we are at an impasse - but interestingly not on technical
issues but rather on what the minimal requirements of the protocol might
be.

I commented on how AF advertisement diverges from the newly introduced
ability of providing partial updates in hellos. You replied that in the
case of AF this shouldn't be needed because the set of Rbridges used to
act as AF should always be small.

I commented on the poor scalability of having to send hellos on all the
VLANs for which one is appointed forwarder. The math you provided (2*V +
N) supports my conclusion.

I commented on the fact that in order for the advertisement logic
presented in the draft to work the set of VLANs supported by some
Rbridges would have to be altered following the addition/subtraction of
an Rbridge from the LAN. You agreed.

Where we disagree is regarding the significance of these issues.

You apparently believe a customer will not want to load balance AF
functionality across a diverse set of Rbridges. I suspect at least some
customers will want this ability.

You apparently believe that receiving (2*V + N) hellos/LAN each hello
interval is not a significant issue in the presence of a large # of
supported VLANs - I disagree.

You apparently believe that customers will find the restrictions on VLAN
configuration in order to make AF advertisement work as described in
this draft acceptable. These restrictions include:

a)Disjoint sets of enabled VLANs on the set of Rbridges to be used as AF
b)Reconfiguration of the set of enabled VLANs on Rbridges in the event
the set of Rbridges on a LAN changes (addition or removal, planned or
unplanned)
c)Reconfiguration of the set of enabled VLANs on an Rbridge which
becomes DRB following failure of the old DRB

These restrictions amount to static configuration of AF - which is
especially ironic given the emphasis on minimal configuration for TRILL
RBs.
I would be very surprised to find that customers would be happy with
this. 

In the big picture, I think there is a need for a scalable way to
advertise AF assignments and have this be adaptable in the face of RB
failure, maintenance, introduction, etc. and to have delivery of this
information be reliable. I don't think the current draft meets these
requirements.

   Les


> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Donald Eastlake
> Sent: Friday, April 29, 2011 8:18 PM
> To: Les Ginsberg (ginsberg); rbridge at postel.org
> Cc: isis mailing list
> Subject: Re: [rbridge] [Isis-wg] Comments ondraft-ietf-trill-rbridge-
> af-02.txt
> 
> Hi Les,
> 
> On Sun, Apr 24, 2011 at 6:54 PM, Les Ginsberg (ginsberg)
> <ginsberg at cisco.com> wrote:
> 
> > Section 2.2 states:
> >
> > "When the DRB sends any appointments in a TRILL Hello, it
> >  must send all appointments for that link in that Hello."
> >
> > This policy seems inconsistent w the policy for other information
> sent
> > in hellos and with one of the motivations for introducing a
different
> > Hello protocol than that used by the base IS-IS specification.
> Section
> > 2.5 of TRILL_ADJ states:
> >
> > " One other issue with TRILL LAN Hellos is to ensure that subsets of
> >   the information can appear in any single message, and be
> processable,
> >   in the spirit of IS-IS LSPs and CSNPs. TRILL Hello frames, even
> >   though they are not padded, can become very large..."
> >
> > Yet here a strategy is adopted which REQUIRES ALL information
> regarding
> > AF to be sent in a single hello. Please explain the inconsistency.
> 
> It is necessary for all the neighbors to be communicated in Hellos in
> order to correctly know the network topology. Due to the TRILL Hello
> bounded size, the TRILL Neighbor TLV was made fragmentable to
> accomplish this.
> 
> Appointed forwarders are different. By default, the DRB is appointed
> forwarder for all VLANs, which should enable correct behavior. The
> optional ability to load split by assigning native frame handling for
> some VLANs to other RBridges on the link was something requested by
> some memebers of the TRILL WG, presumably to optimize the path of some
> native traffic or in cases where the link is a complex bridged LAN.
> 
> Complex link arrangements with large numbers of appointed forwards do
> not seem like a particularly good idea, especially given that they are
> torn down and have to be re-established if the DRB changes.
> 
> > ***********************************
> >
> > Section 2.2.2 discusses the frequency of sending AF information and
> (by
> > implication) how reliable announcement of the AF information is
> > achieved. It states that the DRB in most cases will receive an
> > indication from the non-DRBs as to whether they consider themeselves
> AF
> > for a given VLAN. This is based on the information in the VLAN Flags
> > sub-TLV (#1) of the MT-PORT_CAP TLV (143). But this requires
Rbridges
> to
> > send IIHs on every VLAN for which they are the AF. In the terms used
> by
> > RFC-Trill this means that the set of Announcing VLANS MUST == the
set
> of
> > Enabled VLANs. This does not scale well.
> 
> By default the set of announcing VLANs is the set of enabled VLANs.
> The upper limit on the number of Hellos scales as 2*V + N where there
> are V VLANs on which end station service is offered and N RBridges on
> the link. This is worse than the N Hellos you need in TRILL if there
> is no end station service being offered on the link. But it is better
> than the V*N Hellos that some people in the TRILL WG wanted.
> 
> > ****************************************
> >
> > Section 2.2.3 does an analysis suggesting that the space available
in
> an
> > IIH should be more than adequate to allow advertisement of the
> complete
> > set of AF information in a single hello. This analysis assumes that
> the
> > set of enabled VLANs on the non-DRB Rbridges on a circuit is
disjoint
> > (with the exception of the Designated VLAN). This raises some
> concerns.
> >
> > 1)In the event of the failure of a non-DRB Rbridge it would seem
that
> > assignment of a different Rbridge to be AF for the VLANs for which
> the
> > failed Rbridge had been AF now requires manual intervention to be
> > effective i.e. additional VLANs have to be enabled on the Rbridge
> which
> > is assuming the AF duties of the failed Rbridge.
> 
> It is true that in general, with randomly scattered VLANs, VLAN
> enablement might have to change. (On would hope there are at least
> some networks where appointed forwarders could be set based on solid
> blocks of contiguous VLANs.) But I'm not sure why you assume manual
> intervention. I would think that if a network manager was maintaining
> complex sets of appointed forwarder VLANs on a link, they would have
> some system using SNMP or some other configuration protocol to control
> VLAN enablement appropriately.
> 
> > 2)If the DRB fails, one of the non-DRB Rbridges will assume the role
> of
> > DRB. If the set of enabled VLANs on the new DRB is a subset of the
> union
> > of enabled VLANs for all Rbridges on the circuit (as is required for
> the
> > analysis in Section 2.2.3 to be correct) then its ability to
function
> as
> > DRB is compromised.
> 
> Sure, but it isn't a fatal compromise or anything. Say RB2 is the new
> DRB because RB1 failed. And RB2 wants to appoint RB3 AF for VLAN
> 42. RB3's appointed forwarder status should have been reset when it
> saw the DRB change. If RB2 doesn't have VLAN 42 enabled, so it can't
> see Hellos on that VLAN from RB3, then it doesn't get
> confirmation... Let's say there are lots of appointed forwarders and
> RB2 is a real head-in-the-sand kind of RBridge that only has the
> Designated VLAN enabled. Well, it should be sending out the AF
> information at least once a holding time and things should straighten
> out eventually. The problems might be that (1) it would take longer
> for an AF to get appointed if the initial attempt fails because the
> DRB wouldn't get notice of the failure and try again more quickly, and
> (2) there might be some case involving misconfiguration where more
> than one RBridges got appointed for the same VLAN, in which case they
> should just inhibit each other until things are straightened
> out. Generally speaking, the appointed forwarder system is designed to
> be robust and fail in the direction of not providing service for a
> brief period rather than looping.
> 
> >   Les
> 
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  d3e3e3 at gmail.com
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge


From iesg-secretary at ietf.org  Tue May  3 09:14:09 2011
From: iesg-secretary at ietf.org (The IESG)
Date: Tue, 03 May 2011 09:14:09 -0700
Subject: [rbridge] Protocol Action: 'RBridges: Adjacency' to Proposed
	Standard	(draft-ietf-trill-adj-07.txt)
Message-ID: <20110503161409.1634.80015.idtracker@ietfa.amsl.com>

The IESG has approved the following document:
- 'RBridges: Adjacency'
  (draft-ietf-trill-adj-07.txt) as a Proposed Standard

This document is the product of the Transparent Interconnection of Lots
of Links Working Group.

The IESG contact persons are Ralph Droms and Jari Arkko.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-trill-adj/




Technical Summary

   TRILL supports multi-access LAN links that can have multiple end
   stations and RBridges attached. This document describes four aspects
   of the TRILL LAN Hello protocol used on such links, particularly
   adjacency, designated RBridge selection, and MTU and pseudonode
   procedures, with state machines. There is no change for IS-IS point-
   to-point Hellos used on links configured as point-to-point in TRILL.

Working Group Summary

   This document was developed in the TRILL working group with significant
   review from participants in the IS-IS WG. The scope of the document
   is based on a list of four items where that the IESG wanted to see
   clarified for the TRILL LAN Hello protocol.

Document Quality

    There are implementations of TRILL that were developed without the
    benefits of this additional document. The assumptions is that future
    implementors will benefit from the additional level of detail in
    this document.

Personnel

   Erik Nordmark <nordmark at acm.org> is the document shepherd.  Ralph
   Droms <rdroms.ietf at gmail.com> is the responsible AD.

From hi2narenk at gmail.com  Fri May  6 00:16:51 2011
From: hi2narenk at gmail.com (Narendra kishore)
Date: Fri, 6 May 2011 12:46:51 +0530
Subject: [rbridge] Fwd: Welcome to the "rbridge" mailing list (Digest mode)
In-Reply-To: <mailman.37021.1304663212.752.rbridge@postel.org>
References: <mailman.37021.1304663212.752.rbridge@postel.org>
Message-ID: <BANLkTincK-OfK67ZQ=Nj7O+=ZY_Ae6mfOg@mail.gmail.com>

Hi,

I want to post my queries to the rbridge list
My E-Mail id is  hi2narenk at gmail.com


---------- Forwarded message ----------
From: <rbridge-request at postel.org>
Date: Fri, May 6, 2011 at 11:56 AM
Subject: Welcome to the "rbridge" mailing list (Digest mode)
To: hi2narenk at gmail.com


Welcome to the rbridge at postel.org mailing list!

To post to this list, send your email to:

 rbridge at postel.org

General information about the mailing list is at:

 http://mailman.postel.org/mailman/listinfo/rbridge

If you ever want to unsubscribe or change your options (eg, switch to
or from digest mode, change your password, etc.), visit your
subscription page at:

 http://mailman.postel.org/mailman/options/rbridge/hi2narenk%40gmail.com


You can also make such adjustments via email by sending a message to:

 rbridge-request at postel.org

with the word `help' in the subject or body (don't include the
quotes), and you will get back a message with instructions.

You must know your password to change your options (including changing
the password, itself) or to unsubscribe.  It is:

 nainamma

Normally, Mailman will remind you of your postel.org mailing list
passwords once every month, although you can disable this if you
prefer.  This reminder will also include instructions on how to
unsubscribe or change your account options.  There is also a button on
your options page that will email your current password to you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20110506/47cf3ae9/attachment.html

From Internet-Drafts at ietf.org  Fri May  6 14:30:08 2011
From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org)
Date: Fri, 06 May 2011 14:30:08 -0700
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-bfd-00.txt
Message-ID: <20110506213008.8760.7864.idtracker@ietfa.amsl.com>



From d3e3e3 at gmail.com  Sun May  8 07:01:28 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Sun, 8 May 2011 10:01:28 -0400
Subject: [rbridge] Comments on draft-ietf-trill-rbridge-af-02.txt
In-Reply-To: <4DBB369B.7010009@acm.org>
References: <4DB5B256.7050102@acm.org>
	<BANLkTikk3phN0Bgd4oLbuJ00zE=xf0a1wQ@mail.gmail.com>
	<4DBB369B.7010009@acm.org>
Message-ID: <BANLkTinJhD-WT9H1myTz2xmBhz=+0vEn9A@mail.gmail.com>

Hi Erik,

On Fri, Apr 29, 2011 at 6:07 PM, Erik Nordmark <nordmark at acm.org> wrote:
> On 4/29/11 11:56 AM, Donald Eastlake wrote:
>
>>> The document mentions "trunk port", but neither it nor RFCtrill defines
>>> what that is. RFCtrill has some text about it in an appendix. Would it
>>> make sense to put a definition for it in section 1.1?
>>
>> I think it would make sense to add something in Section 1.1 like:
>>
>> A "trunk port" is a port configured with the "end station service
>> disable" bit on, as described in Section 4.9.1 of [RFCtrill].
>
> OK
>
>>> The item 2 in section 3 doesn't actually say how the DRB inhibition
>>> timer is set initially! It says how it is set when the RB believes it
>>> has become DRB. If the intent is to initially set it to the Holding time
>>> it would make sense to state that in item 1 e.g.,
>>> ? ? ? ? All
>>> ? ? ? ? inhibition timers are set to expired except the DRB inhibition
>>> ? ? ? ? timer which is set to the Holding Time. The DRB
>>> ? ? ? ? inhibition timer is handled differently because each port will
>>> ? ? ? ? initially believe it is DRB.
>>
>> I don't actually see what's all that confusing in the current wording
>> but I'm fine with changiing to the wording you suggest and it may be
>> clearer.
>
> The current item 2 says
> ? ? ?2. When an RBridge believes that it has become DRB on a link, ...
> which looks confusing. Based on item 1 I'd expect it to say something about
> the initial setting, but it looks like it only talks about the case when it
> becomes a DRB. It might be that it always becomes a DRB initially, but that
> is a bit too subtle.

OK. I'll work on improving the wording.

> I hope that explains my request for working it more explicitly.
>
> ? Erik

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com


From d3e3e3 at gmail.com  Sun May  8 18:56:50 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Sun, 8 May 2011 21:56:50 -0400
Subject: [rbridge] [Isis-wg] Comments
	ondraft-ietf-trill-rbridge-af-02.txt
In-Reply-To: <AE36820147909644AD2A7CA014B1FB520E1E57B4@xmb-sjc-222.amer.cisco.com>
References: <20110419230001.13811.8107.idtracker@ietfc.amsl.com>
	<AE36820147909644AD2A7CA014B1FB520E0A32EE@xmb-sjc-222.amer.cisco.com>
	<BANLkTiks3HPE=a=08DniOhAdjzhFXOT=sw@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520E1E57B4@xmb-sjc-222.amer.cisco.com>
Message-ID: <BANLkTinxQDWX6kQ7WJs4fwFdBN6q9G68Jw@mail.gmail.com>

Hi Les,

On Mon, May 2, 2011 at 12:41 PM, Les Ginsberg (ginsberg)
<ginsberg at cisco.com> wrote:

> Donald -
>
> I suspect we are at an impasse - but interestingly not on technical
> issues but rather on what the minimal requirements of the protocol might
> be.
>
> I commented on how AF advertisement diverges from the newly introduced
> ability of providing partial updates in hellos. You replied that in the
> case of AF this shouldn't be needed because the set of Rbridges used to
> act as AF should always be small.

I guess we differ on the definition of "small" in this context.

> I commented on the poor scalability of having to send hellos on all the
> VLANs for which one is appointed forwarder. The math you provided (2*V +
> N) supports my conclusion.

That's default behavior, not mandatory if you configure different
behavior.

> I commented on the fact that in order for the advertisement logic
> presented in the draft to work the set of VLANs supported by some
> Rbridges would have to be altered following the addition/subtraction of
> an Rbridge from the LAN. You agreed.

The particular technique given in the draft to accommodate many
perversely scattered VLANs generally requires changing VLAN
enablement. That's not the same as saying you would always have to
change VLAN enablement.

> Where we disagree is regarding the significance of these issues.

Right.

> You apparently believe a customer will not want to load balance AF
> functionality across a diverse set of Rbridges. I suspect at least some
> customers will want this ability.

I don't think a customer will want to load balance native traffic
to/from a link by VLAN across hundreds of RBridges. I think that 65+
or so diverse RBridges (actually up to twice that if VLANs are not
perversely scattered) will be diverse enough.

> You apparently believe that receiving (2*V + N) hellos/LAN each hello
> interval is not a significant issue in the presence of a large # of
> supported VLANs - I disagree.

It may or may not be an issue depending on the capabilities of the
links and RBridges involved. (Note that TRILL Neighbor TLVs, probably
a TLV in a TRILL Hello that is relatively expensive to process, is
only processed in the N Hellos on the Designated VLAN and is probably
not present in Hellos on other VLANs.) However, I don't know what you
can do if there isn't a better default that preserves robustness and
other characteristics.

For example, you can cut the (2*V + N) Hellos to N Hellos by
configuring the announcing VLANs set at the RBridge ports on the link
to be the null set. This would be safe on a link in the absence of
devices such a bridges, for example on a LAN link that is actually
point-to-point, as is very common in modern networks. (Although in
that case it might be easier to just configure it as a point-to-point
link.) So, if the network manager is sure their configuration is like
that, they can reduce the number of Hellos to N.

Given the wonderous and complex ways in which bridges and bridge ports
can be configured, it is hard for me to see how you can be reasonably
loop safe without having something like the inhibition mechanism and
having each RBridge periodically send a message on each VLAN for which
it is an Appointed Forwarder. It is convenient for this message to be
a Hello for DRB election and other reasons.

> You apparently believe that customers will find the restrictions on VLAN
> configuration in order to make AF advertisement work as described in
> this draft acceptable. These restrictions include:
>
> a)Disjoint sets of enabled VLANs on the set of Rbridges to be used
> as AF

This is only needed if many VLANs are perversely configured on a link
and even then does not apply to the DRB. If there are a small number
of VLANs or if there are many but the are rationally allocated to
Appointed Forewarders in contiguous blocks, there is no need to use
this technique.

> b)Reconfiguration of the set of enabled VLANs on Rbridges in the event
> the set of Rbridges on a LAN changes (addition or removal, planned or
> unplanned)

This is never needed unless the set of RBridges on the link acting as
Appointed Forwarders changes. RBridge can come and go. As long as
those RBridges are only used for TRILL Data through traffic (plus
control traffic such as TRILL IS-IS frames) and don't become DRB and
change the Designated VLAN, no changes would be needed in the enabled
VLANs on any of the RBridges on the link.

Nor, with RBridges that are or are to be Appointed Forwarders, is this
needed if you have a small number of VLANs you are dealing with or a
large number that are rationally organized so that appointments can be
made for contiguous blocks.

On in the case where there are many VLANs where you want to do
perversely scattered appointments do you need to use the technique
outlined in the draft... Probably the simpler alternatives and the
cases where they are applicable should get more mention in the draft.

> c)Reconfiguration of the set of enabled VLANs on an Rbridge which
> becomes DRB following failure of the old DRB

As above, this would be required only under limited circumstances. And
since this RBridge knows it has become DRB, it doesn't seem very hard
for it to change its own VLAN enablement on the port that became DRB.
And should the DRB fail to enable some VLAN that it wants some other
RBridge to be Appointed Forwarder for, things still work, the DRB just
doesn't get feedback on the AF status of other RBridges on the link.
This might slow down convergence to the desired AF state.

> These restrictions amount to static configuration of AF - which is
> especially ironic given the emphasis on minimal configuration for TRILL
> RBs.
> I would be very surprised to find that customers would be happy with
> this.

The idea in TRILL is that things should work with minimal
configuration. The do as far as appointed forwarders go. The DRB is
it, with no particular configuration required. If you want to try to
load share native traffic from a link by VLAN, that seems like a great
place to apply various forms of creative cleverness and knowledge of
the traffic characteristics of the end stations and network which is
unreasonable to expect to be in TRILL standards documents. In many
case something is going to have to configure the load sharing. And if
many VLANs are perversely scattered, VLAN enablement will probably
need to be configured. I see no reason why such enablement cannot be
automated.

> In the big picture, I think there is a need for a scalable way to
> advertise AF assignments and have this be adaptable in the face of RB
> failure, maintenance, introduction, etc. and to have delivery of this
> information be reliable. I don't think the current draft meets these
> requirements.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com

>   Les
>
>
>> -----Original Message-----
>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
> On
>> Behalf Of Donald Eastlake
>> Sent: Friday, April 29, 2011 8:18 PM
>> To: Les Ginsberg (ginsberg); rbridge at postel.org
>> Cc: isis mailing list
>> Subject: Re: [rbridge] [Isis-wg] Comments ondraft-ietf-trill-rbridge-
>> af-02.txt
>>
>> Hi Les,
>>
>> On Sun, Apr 24, 2011 at 6:54 PM, Les Ginsberg (ginsberg)
>> <ginsberg at cisco.com> wrote:
>>
>> > Section 2.2 states:
>> >
>> > "When the DRB sends any appointments in a TRILL Hello, it
>> >  must send all appointments for that link in that Hello."
>> >
>> > This policy seems inconsistent w the policy for other information
>> sent
>> > in hellos and with one of the motivations for introducing a
> different
>> > Hello protocol than that used by the base IS-IS specification.
>> Section
>> > 2.5 of TRILL_ADJ states:
>> >
>> > " One other issue with TRILL LAN Hellos is to ensure that subsets of
>> > ? the information can appear in any single message, and be
>> processable,
>> > ? in the spirit of IS-IS LSPs and CSNPs. TRILL Hello frames, even
>> > ? though they are not padded, can become very large..."
>> >
>> > Yet here a strategy is adopted which REQUIRES ALL information
>> regarding
>> > AF to be sent in a single hello. Please explain the inconsistency.
>>
>> It is necessary for all the neighbors to be communicated in Hellos in
>> order to correctly know the network topology. Due to the TRILL Hello
>> bounded size, the TRILL Neighbor TLV was made fragmentable to
>> accomplish this.
>>
>> Appointed forwarders are different. By default, the DRB is appointed
>> forwarder for all VLANs, which should enable correct behavior. The
>> optional ability to load split by assigning native frame handling for
>> some VLANs to other RBridges on the link was something requested by
>> some memebers of the TRILL WG, presumably to optimize the path of some
>> native traffic or in cases where the link is a complex bridged LAN.
>>
>> Complex link arrangements with large numbers of appointed forwards do
>> not seem like a particularly good idea, especially given that they are
>> torn down and have to be re-established if the DRB changes.
>>
>> > ***********************************
>> >
>> > Section 2.2.2 discusses the frequency of sending AF information and
>> (by
>> > implication) how reliable announcement of the AF information is
>> > achieved. It states that the DRB in most cases will receive an
>> > indication from the non-DRBs as to whether they consider themeselves
>> AF
>> > for a given VLAN. This is based on the information in the VLAN Flags
>> > sub-TLV (#1) of the MT-PORT_CAP TLV (143). But this requires
> Rbridges
>> to
>> > send IIHs on every VLAN for which they are the AF. In the terms used
>> by
>> > RFC-Trill this means that the set of Announcing VLANS MUST == the
> set
>> of
>> > Enabled VLANs. This does not scale well.
>>
>> By default the set of announcing VLANs is the set of enabled VLANs.
>> The upper limit on the number of Hellos scales as 2*V + N where there
>> are V VLANs on which end station service is offered and N RBridges on
>> the link. This is worse than the N Hellos you need in TRILL if there
>> is no end station service being offered on the link. But it is better
>> than the V*N Hellos that some people in the TRILL WG wanted.
>>
>> > ****************************************
>> >
>> > Section 2.2.3 does an analysis suggesting that the space available
> in
>> an
>> > IIH should be more than adequate to allow advertisement of the
>> complete
>> > set of AF information in a single hello. This analysis assumes that
>> the
>> > set of enabled VLANs on the non-DRB Rbridges on a circuit is
> disjoint
>> > (with the exception of the Designated VLAN). This raises some
>> concerns.
>> >
>> > 1)In the event of the failure of a non-DRB Rbridge it would seem
> that
>> > assignment of a different Rbridge to be AF for the VLANs for which
>> the
>> > failed Rbridge had been AF now requires manual intervention to be
>> > effective i.e. additional VLANs have to be enabled on the Rbridge
>> which
>> > is assuming the AF duties of the failed Rbridge.
>>
>> It is true that in general, with randomly scattered VLANs, VLAN
>> enablement might have to change. (On would hope there are at least
>> some networks where appointed forwarders could be set based on solid
>> blocks of contiguous VLANs.) But I'm not sure why you assume manual
>> intervention. I would think that if a network manager was maintaining
>> complex sets of appointed forwarder VLANs on a link, they would have
>> some system using SNMP or some other configuration protocol to control
>> VLAN enablement appropriately.
>>
>> > 2)If the DRB fails, one of the non-DRB Rbridges will assume the role
>> of
>> > DRB. If the set of enabled VLANs on the new DRB is a subset of the
>> union
>> > of enabled VLANs for all Rbridges on the circuit (as is required for
>> the
>> > analysis in Section 2.2.3 to be correct) then its ability to
> function
>> as
>> > DRB is compromised.
>>
>> Sure, but it isn't a fatal compromise or anything. Say RB2 is the new
>> DRB because RB1 failed. And RB2 wants to appoint RB3 AF for VLAN
>> 42. RB3's appointed forwarder status should have been reset when it
>> saw the DRB change. If RB2 doesn't have VLAN 42 enabled, so it can't
>> see Hellos on that VLAN from RB3, then it doesn't get
>> confirmation... Let's say there are lots of appointed forwarders and
>> RB2 is a real head-in-the-sand kind of RBridge that only has the
>> Designated VLAN enabled. Well, it should be sending out the AF
>> information at least once a holding time and things should straighten
>> out eventually. The problems might be that (1) it would take longer
>> for an AF to get appointed if the initial attempt fails because the
>> DRB wouldn't get notice of the failure and try again more quickly, and
>> (2) there might be some case involving misconfiguration where more
>> than one RBridges got appointed for the same VLAN, in which case they
>> should just inhibit each other until things are straightened
>> out. Generally speaking, the appointed forwarder system is designed to
>> be robust and fail in the direction of not providing service for a
>> brief period rather than looping.
>>
>> >   Les
>>
>> Thanks,
>> Donald
>> =============================
>>  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  Tue May 10 16:28:33 2011
From: radiaperlman at gmail.com (Radia Perlman)
Date: Tue, 10 May 2011 16:28:33 -0700
Subject: [rbridge] Questions and comments to
	draft-ietf-trill-rbridge-af-02
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F60514536B@dfweml503-mbx.china.huawei.com>
References: <4A95BA014132FF49AE685FAB4B9F17F60514536B@dfweml503-mbx.china.huawei.com>
Message-ID: <BANLkTikHjpxffxjjoT=7rrYs+sDqCVC0SA@mail.gmail.com>

Hi Linda,

On Tue, May 10, 2011 at 4:00 PM, Linda Dunbar <linda.dunbar at huawei.com> wrote:
> Hi Radia,
>
> I have a few questions and comments to the draft-ietf-trill-rbridge-af-02.
> Hope you can help me out.
>
>
>
> For a RBridge connected with point to point link to an end station (or
> multiple end stations when a 802.1 bridge/switch is used), does this RBridge
> automatically become the Appointed Forwarder for all the VLANs enabled on
> the ports?

Yes.  Since there is no other RBridge on the link, there's nobody to
delegate to.

> Section 2, 3rd paragraph: ?while the cases of multiple ports on a link for
> one RBridge and multiple port with the same MAC address are fully
> accommodated, ??
>
> Do you mean ?while the cases of one Bridge with multiple ports with same MAC
> address on one link are fully accommodated, ???
> If yes, can you change the text a bit to make it more clear?
>

No.  It does not mean that. It is meant to cover both the cases of:
a) a single RBridge with multiple ports on the same link with the same
MAC address, and
b) multiple RBridges using the same MAC address on the link...i.e.,
both R1 and R2 are using MAC address M on the same link.

I agree that paragraph will not win any journalism awards and will
think about how to reword it.


> Section 2.2.1, 2nd paragraph: ?if the TRILL Hello is from the winning DRB
> port ?, then it loses all Appointed Forwarder status?
>
> Do you mean the DRB loses its Appointed Forwarder status or the receiving
> Rbridge loses its AF status for the VLAN not included in the Hello message?
> Since the Receiving RBridge wasn?t AF, why you call ?lose its status??
>

Again, you've found another case of less than clear wording.  There's
probably a simpler way of saying what is intended, which is that the
RBridge will only be AF for the VLANs specified in that Hello.


> Section 3: The Inhibition Mechanism: Does each VLAN enabled has an
> ?Inhibition Timer?? Why need this timer?
>
>

I'm going to let Donald answer this one...

> Thank you very much.
>
> Linda Dunbar
>


From d3e3e3 at gmail.com  Tue May 10 18:38:48 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 10 May 2011 21:38:48 -0400
Subject: [rbridge] Questions and comments to
	draft-ietf-trill-rbridge-af-02
In-Reply-To: <BANLkTikHjpxffxjjoT=7rrYs+sDqCVC0SA@mail.gmail.com>
References: <4A95BA014132FF49AE685FAB4B9F17F60514536B@dfweml503-mbx.china.huawei.com>
	<BANLkTikHjpxffxjjoT=7rrYs+sDqCVC0SA@mail.gmail.com>
Message-ID: <BANLkTiksqy-ALkpD+4+aRr4YuuNvx+ZVRw@mail.gmail.com>

Hi Linda,

On Tue, May 10, 2011 at 7:28 PM, Radia Perlman <radiaperlman at gmail.com> wrote:
> Hi Linda,
>
> On Tue, May 10, 2011 at 4:00 PM, Linda Dunbar <linda.dunbar at huawei.com> wrote:
>> Hi Radia,
>>
>> I have a few questions and comments to the draft-ietf-trill-rbridge-af-02.
>> Hope you can help me out.
>>
>>...
>>
>
>> Section 3: The Inhibition Mechanism: Does each VLAN enabled has an
>> ?Inhibition Timer?? Why need this timer?
>
> I'm going to let Donald answer this one...

Those Inhibition timers (or the equivalent) are needed to be loop safe
in the case of misconfigured bridges on the link. For a very simple
example, assume that RB1 and RB2 are the only RBridges on the link,
that RB1 is higher priority to be DRB, and that they both want VLAN 1
to be the designated VLAN. But there is a bridge between them
configured so that RB1 can see all the frames sent by RB2 but none of
the frames from RB1 can get through to RB2. Both will think they are
DRB, RB1 because it is higher priority even though it sees the Hellos
from RB2 and RB2 because it doesn't see the Hellos from RB1 and thinks
it is highest priority.

Say RB1 chooses to act as appointed forwarder for VLANs 2 and 3 while
RB2 chooses to act as appointed forwarder for VLANs 3 and 4. There is
no problem with VLANs 2 and 4 but if you do not do something about it,
you could have a loop involving VLAN 3. RB1 will see the Hellos RB2
issues on VLAN 3 declaring itself AF and so RB1 will be inhibited on
VLAN 3. RB2 does not see the Hellos issued by RB1 on VLAN 3 and so RB2
is uninhibited and will handle VLAN 3 native traffic.

But this situation may change. RB2 might crash or the bridge might
crash or RB2 might be re-configured so it no longer tried to act as
appointed forwarder for VLAN 3 or ... So RB1 has to maintain a VLAN 3
inhibition timer and if it sees no Hellos from any other RBridge on
the link claiming to be AF for VLAN 3 in a long enough time, then RB1
becomes uninhibited for that VLAN on the port in question and can
handle end station traffic in VLAN 3.

>> Thank you very much.
>>
>> Linda Dunbar

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com


From hi2narenk at gmail.com  Wed May 11 23:42:52 2011
From: hi2narenk at gmail.com (Narendra kishore)
Date: Thu, 12 May 2011 12:12:52 +0530
Subject: [rbridge] Port configurations
Message-ID: <BANLkTi=+E3rMf5B8pKCQXjVguBoF-f4O2g@mail.gmail.com>

Hi Donald,

I need information on ports configurations in RBRidges.

Is the RBridge having 2 level of port configuration, i mean first Layer2
port configuration (Access, Trunk) and TRILL port configuration ( Access,
Trunk and None).
If there are 2 level port configuration then, can you please help me out a
bit in understanding the difference in those port configurations.

Also let me know whether AF can be appointed on Access port or Trunk port
(Layer2/TRILL).

Also please explain me a bit in the below paragraph present in AF Draft,

The Appointed Forwarder mechanism is irrelevant to any link on which
end station service is not offered. This includes links configured as
point-to-point and any link with all RBridge ports on that link
configured as trunk ports. (In TRILL, configuration of a port as a
"trunk port" just means that no end station service will be provided.
It does not imply that all VLANs are enabled on that port.)


Thanks and regards,
Naren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20110512/7516cae9/attachment.html

From d3e3e3 at gmail.com  Thu May 12 19:40:07 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 12 May 2011 22:40:07 -0400
Subject: [rbridge] Port configurations
In-Reply-To: <BANLkTi=+E3rMf5B8pKCQXjVguBoF-f4O2g@mail.gmail.com>
References: <BANLkTi=+E3rMf5B8pKCQXjVguBoF-f4O2g@mail.gmail.com>
Message-ID: <BANLkTik=gOuMBQE2ZcEjY8HE9dqG9a7PNw@mail.gmail.com>

Hi Narendra,

On Thu, May 12, 2011 at 2:42 AM, Narendra kishore <hi2narenk at gmail.com> wrote:
> Hi Donald,
>
> I need information on ports configurations in RBRidges.
>
> Is the RBridge having 2 level of port configuration, i mean first Layer2
> port configuration (Access, Trunk) and TRILL port configuration ( Access,
> Trunk and None).

Yes, you can view an RBridge port as having two layers.
     The lower layer (the one closest to the link) is the same as an
802.1Q-2005 bridge port except for how it handles some low level
bridging control frames. So you can configure that level the same ways
that you can configure an 802.1Q-2005 port. Can you point to a part of
the 802.1Q-2005 specification which defines "trunk port" and "access
port"? I believe the term "trunk port" is sometimes used at Layer 2 to
indicate a port connected to a point-to-point link between bridges
where all VLANs are enabled. What do you think it means to configure a
Layer 2 802.1Q-2005 port as an access port or a trunk port?
     For an incoming frame, the 802.1Q-2005 port classifies the frame
into a VLAN and mapped prority and, as the frame passes up through the
EISS interface provides the VLAN ID and priority as well as the
frame...

Then there is the TRILL port layer above the 802.1Q-2005 layer. At the
TRILL level, you can configure a port as point-to-point, trunk, or
access. As it says in the TRILL base protocol standard, there is a
dominance relations between these. point-to-point > access > trunk  If
you configure the port as point-to-point, the other two bits are
ignored. If you do not configure it as point-to-point in TRILL but
configure it as an access node then the trunk node bit is ignored.
Only if you do not configure it as point-to-point and do not configure
it as access does TRILL pay any attention to whether you have
configured it as trunk.

If you configure an TRILL port as point-to-point, the point-to-point
IS-IS Hellos are used on it and the assumption is that no other
devices are on the link including no end stations. So there is no end
station service offered by the port.

If you configure an TRILL port as a access port and not as a
point-to-point port, you are saying you want, as far as practical, to
use that port only for end station service. So no TRILL Data frames
should be sent through it and no TRILL IS-IS frames except Hellos for
loop safety.

If you configure an TRILL port as a trunk port and not as an access
port or a point-to-point port, then you are saying that you only want
to use the port for TRILL Data and TRILL IS-IS frames. No native
frames are sent and any received are discarded.

> If there are 2 level port configuration then, can you please help me out a
> bit in understanding the difference in those port configurations.

They are more or less independent. Incoming frames go through the
802.1Q-2005 layer up to the EISS and then the TRILL layer. Outgoing
frames go through the TRILL layer and then the EISS to the 802.1Q-2005
layer...

> Also let me know whether AF can be appointed on Access port or Trunk port
> (Layer2/TRILL).

I don't know what you think a Layer 2 access port or a Layer 2 trunk
port are. But appointed forwarder status has nothing to do with the
lower 802.1Q-2005 layer of an RBridge port.

Configuring the TRILL layer of an RBridge port as an Access Port just
means you want to use it primarily for native frames. Of course the
full Appointed Forwarder logic applies to such a port.

Configuring the TRIL layer of an RBridge port as a Trunk Port means
that you don't want to use it for any native frames. I don't see why
you would appoint such a port forwarder for one or more VLANs since
they are not going to act as an appointed forwarder anyway.

> Also please explain me a bit in the below paragraph present in AF Draft,
>
> The Appointed Forwarder mechanism is irrelevant to any link on which
> end station service is not offered. This includes links configured as
> point-to-point and any link with all RBridge ports on that link
> configured as trunk ports. (In TRILL, configuration of a port as a
> "trunk port" just means that no end station service will be provided.
> It does not imply that all VLANs are enabled on that port.)

I not sure how to clarify it much. "end station service" is ingressing
or egressing native frames. That's what appointed forwarders are all
about. If there is no end station service on a link, then no native
frames will be ingressed or egressed, no matter what you think you are
doing about appointing forwarders. So what you do about appointed
forwarders is "irrelevant", that is, it doesn't make any difference.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com

> Thanks and regards,
> Naren


From d3e3e3 at gmail.com  Fri May 13 05:19:01 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 13 May 2011 08:19:01 -0400
Subject: [rbridge] RBridge Channel 1/3: Egress-RBridges multicast address
Message-ID: <BANLkTinkfDrxZYkDL2iRKFRtmHUY8DOv2g@mail.gmail.com>

Hi,

draft-ietf-trill-rbridge-channel-00 currently provides for allocating
a new multicast address from the small pool of 16 multicast MAC
address dedicated to TRILL. This would be used as a special
Inner.MacDA to indicate RBridge Channel frames and would be noticed
when the frame is egressed.

This is actually very similar to what the All-ESADI-RBridges special
Inner.MacDA does. I believe that they both work for current silicon
implementations by directing the frame to the slow path. Furthermore,
these two kinds of frames are distinguished by their Inner.Ethertype.
So I don't actually see that it is necessary to use up anther
multicast address from the small pool so they can have different
Inner.MacDAs.

So, I propose to change the RBridge Channel draft to use the same
Inner.MacDA as ESADI and to have that draft update the IANA registry
to show "All-Egress-RBridges" as an alternative name for that
multicast MAC address.

Thanks,
Donald

PS: This is the first of three suggested tweaks to the RBridge Channel
draft. I'm posting them separately to make discussion easier.
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com


From d3e3e3 at gmail.com  Fri May 13 05:22:28 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 13 May 2011 08:22:28 -0400
Subject: [rbridge] RBridge Channel 2/3: Alert Bit move
Message-ID: <BANLkTim7JtQ8t8F+NO64jJPVJK5oUzOpzA@mail.gmail.com>

Hi,

Since the Alert extended TRILL Header flag bit is potentially useful
for more things than just RBridge Channel / OAM protocols, I would
like to move its specification from the RBridge Channel draft
(draft-ietf-trill-rbridge-channel-00) to the TRILL Header Extensions
(formerly Options) draft. The Alert bit just forces the frame to be
delivered to the slow path at a transit RBridge. (Since, I believe,
with current silicon, the presence of any non-zero length header
extension area will send the frame to the slow path, specifying an
Alert extended header flag will actually work quite well.)

Thanks,
Donald

PS: This is the second of three suggested tweaks to the RBridge
Channel draft. I'm posting them separately to make discussion easier.
This one also affects the TRILL Header Extension draft.
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com


From d3e3e3 at gmail.com  Fri May 13 05:34:15 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 13 May 2011 08:34:15 -0400
Subject: [rbridge] RBridge Channel 3/3: Indicating support for RBridge
	Channel protocols
Message-ID: <BANLkTimnrNQf0v4vvUHeNrwm61GaAeL3yA@mail.gmail.com>

Hi,

Currently draft-ietf-trill-rbridge-channel-00 allocates an ISIS GENAPP
ID for TRILL and specifies an APPsub-TLV with just one bit that
indicates whether the RBridge supports the Channel Facility or not. I
think it would be better to specify an APPsub-TLV with a bit per
RBridge Channel protocol to indicate support of that protocol. See
draft text fragment pasted at the bottom of this message.

Thanks,
Donald

PS: This is the third of three suggested tweaks to the RBridge Channel
draft. I'm posting them separately to make discussion easier.
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com



Support for RBridge Channel protocols is indicated by the presence of
one or more Channel Protocols TRILL APPsub-TLVs in an RBridge's link
state.  The Channel Protocols TRILL APPsub-TLV has as its value one or
more byte aligned bit vectors where a one bit indicates support of a
particular RBridge Channel protocol. Each byte aligned bit vector is
formatted as follows:

| 0  1  2  3  4  5  6  7| 8  9 10 11 12 13 14 15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Bit Vector Length |     Bit Vector Offset    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  bits
+--+--+--...

Note that the bit vector length (BVL) is a seven bit unsigned integer
field and the bit vector offset (BVO) is a nine bit unsigned integer
field.  The bits in each bit vector are numbered in network order, the
high order bit of the first byte of bits being bit 0 + 8*BVO, the low
order bit of that byte being 7 + 8*BVO, the high order bit of the
second byte being 8 + 8*BVO, and so on for BVL bytes. An RBridge
Channel protocols supported bit vector MUST NOT extend beyond the end
of the value in the APPsub-TLV in which it occurs. If multiple byte
aligned bit vectors are present in one such APPsub-TLV, they are
contiguous, the BVL field for the next starting immediately after the
last byte of bits for the previous.  The one or more bit vectors
present MUST exactly fill the APPsub-TLV value.

If different bit vectors overlap in the protocol number space they
refer to and have inconsistent bit values for a protcol, support for
the protocol is assumed if any of these bit vectors has a 1 for that
protocol.

The absence of any occurrences of this APPsub-TLV in the link state
for an RBridge implies that that RBridge does not support the RBridge
Channel feature. Because RBridge Channel protocols 0 and 0xFFF are
reserved and protocol 1, the RBridge Channel error protocol, MUST be
implemented as part of the RBridge Channel feature, should bit
positions for those protocols appear in bit vectors in this
APPsub-TLV, the bits for protocols 0 and 0xFFF MUST be 0 and the bit
for protocol 1 MUST be one; however, these bits are ignored on receipt
and support for protocol 1 is always assumed if there are any
occurrences of this APPsub-TLV.  To avoid wasted space, trailing bit
vector zero bytes SHOULD be eliminated by reducing BVL and any null
bit vectors (ones with BVL equal to zero) eliminated.


From mshand at cisco.com  Fri May 13 08:00:41 2011
From: mshand at cisco.com (mike shand)
Date: Fri, 13 May 2011 16:00:41 +0100
Subject: [rbridge] RBridge Channel 3/3: Indicating support for RBridge
 Channel protocols
In-Reply-To: <BANLkTimnrNQf0v4vvUHeNrwm61GaAeL3yA@mail.gmail.com>
References: <BANLkTimnrNQf0v4vvUHeNrwm61GaAeL3yA@mail.gmail.com>
Message-ID: <4DCD4799.8000209@cisco.com>

Hi Donald,
     I'm trying to understand the rationale for this using GENAPP rather 
than, say, a router capability TLV. Is it the case that support for 
channels is considered to be an application as far as routing is 
concerned? i.e. all you are doing is advertising some information which 
is used by some other "application", such as OAM or BFD, as opposed to 
some information that is used by "routing" itself? I guess an important 
differentiator is to ask whether "routing" would ever make any different 
decisions on the basis of this information. From what I can see, the 
answer to that question is NO. Is that a correct assessment?

     Mike


On 13/05/2011 13:34, Donald Eastlake wrote:
> Hi,
>
> Currently draft-ietf-trill-rbridge-channel-00 allocates an ISIS GENAPP
> ID for TRILL and specifies an APPsub-TLV with just one bit that
> indicates whether the RBridge supports the Channel Facility or not. I
> think it would be better to specify an APPsub-TLV with a bit per
> RBridge Channel protocol to indicate support of that protocol. See
> draft text fragment pasted at the bottom of this message.
>
> Thanks,
> Donald
>
> PS: This is the third of three suggested tweaks to the RBridge Channel
> draft. I'm posting them separately to make discussion easier.
> =============================
>   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>   155 Beaver Street
>   Milford, MA 01757 USA
>   d3e3e3 at gmail.com
>
>
>
> Support for RBridge Channel protocols is indicated by the presence of
> one or more Channel Protocols TRILL APPsub-TLVs in an RBridge's link
> state.  The Channel Protocols TRILL APPsub-TLV has as its value one or
> more byte aligned bit vectors where a one bit indicates support of a
> particular RBridge Channel protocol. Each byte aligned bit vector is
> formatted as follows:
>
> | 0  1  2  3  4  5  6  7| 8  9 10 11 12 13 14 15|
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> |  Bit Vector Length |     Bit Vector Offset    |
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> |  bits
> +--+--+--...
>
> Note that the bit vector length (BVL) is a seven bit unsigned integer
> field and the bit vector offset (BVO) is a nine bit unsigned integer
> field.  The bits in each bit vector are numbered in network order, the
> high order bit of the first byte of bits being bit 0 + 8*BVO, the low
> order bit of that byte being 7 + 8*BVO, the high order bit of the
> second byte being 8 + 8*BVO, and so on for BVL bytes. An RBridge
> Channel protocols supported bit vector MUST NOT extend beyond the end
> of the value in the APPsub-TLV in which it occurs. If multiple byte
> aligned bit vectors are present in one such APPsub-TLV, they are
> contiguous, the BVL field for the next starting immediately after the
> last byte of bits for the previous.  The one or more bit vectors
> present MUST exactly fill the APPsub-TLV value.
>
> If different bit vectors overlap in the protocol number space they
> refer to and have inconsistent bit values for a protcol, support for
> the protocol is assumed if any of these bit vectors has a 1 for that
> protocol.
>
> The absence of any occurrences of this APPsub-TLV in the link state
> for an RBridge implies that that RBridge does not support the RBridge
> Channel feature. Because RBridge Channel protocols 0 and 0xFFF are
> reserved and protocol 1, the RBridge Channel error protocol, MUST be
> implemented as part of the RBridge Channel feature, should bit
> positions for those protocols appear in bit vectors in this
> APPsub-TLV, the bits for protocols 0 and 0xFFF MUST be 0 and the bit
> for protocol 1 MUST be one; however, these bits are ignored on receipt
> and support for protocol 1 is always assumed if there are any
> occurrences of this APPsub-TLV.  To avoid wasted space, trailing bit
> vector zero bytes SHOULD be eliminated by reducing BVL and any null
> bit vectors (ones with BVL equal to zero) eliminated.
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

From d3e3e3 at gmail.com  Fri May 13 09:08:39 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 13 May 2011 12:08:39 -0400
Subject: [rbridge] RBridge Channel 3/3: Indicating support for RBridge
 Channel protocols
In-Reply-To: <4DCD4799.8000209@cisco.com>
References: <BANLkTimnrNQf0v4vvUHeNrwm61GaAeL3yA@mail.gmail.com>
	<4DCD4799.8000209@cisco.com>
Message-ID: <BANLkTi=Ayb0pyJiBU6pVTqbEmhupF0A2Dg@mail.gmail.com>

Hi Mike,

On Fri, May 13, 2011 at 11:00 AM, mike shand <mshand at cisco.com> wrote:
> Hi Donald,
> ? ? I'm trying to understand the rationale for this using GENAPP rather
> than, say, a router capability TLV. Is it the case that support for
> channels is considered to be an application as far as routing is
> concerned? i.e. all you are doing is advertising some information which
> is used by some other "application", such as OAM or BFD, as opposed to
> some information that is used by "routing" itself?

Right. It's just about whether you can originate or understand certain
types of data messages. The RBridge Channel messages are strictly
conformant to the specification for a TRILL Data frame. The only clue
is that the encapsulated Ethernet frame has a magic multicast
destination MAC address, which pushes it to the slow path at the
"egress" and then the Etherype indicates that it needs to be processed
as an RBridge Channel message.

> I guess an important
> differentiator is to ask whether "routing" would ever make any different
> decisions on the basis of this information. From what I can see, the
> answer to that question is NO. Is that a correct assessment?

Yes. It has no effect on any routing decisions.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com

> ? ? Mike
>
>
> On 13/05/2011 13:34, Donald Eastlake wrote:
>> Hi,
>>
>> Currently draft-ietf-trill-rbridge-channel-00 allocates an ISIS GENAPP
>> ID for TRILL and specifies an APPsub-TLV with just one bit that
>> indicates whether the RBridge supports the Channel Facility or not. I
>> think it would be better to specify an APPsub-TLV with a bit per
>> RBridge Channel protocol to indicate support of that protocol. See
>> draft text fragment pasted at the bottom of this message.
>>
>> Thanks,
>> Donald
>>
>> PS: This is the third of three suggested tweaks to the RBridge Channel
>> draft. I'm posting them separately to make discussion easier.
>> =============================
>> ? Donald E. Eastlake 3rd ? +1-508-333-2270 (cell)
>> ? 155 Beaver Street
>> ? Milford, MA 01757 USA
>> ? d3e3e3 at gmail.com
>>
>>
>>
>> Support for RBridge Channel protocols is indicated by the presence of
>> one or more Channel Protocols TRILL APPsub-TLVs in an RBridge's link
>> state. ?The Channel Protocols TRILL APPsub-TLV has as its value one or
>> more byte aligned bit vectors where a one bit indicates support of a
>> particular RBridge Channel protocol. Each byte aligned bit vector is
>> formatted as follows:
>>
>> | 0 ?1 ?2 ?3 ?4 ?5 ?6 ?7| 8 ?9 10 11 12 13 14 15|
>> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>> | ?Bit Vector Length | ? ? Bit Vector Offset ? ?|
>> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>> | ?bits
>> +--+--+--...
>>
>> Note that the bit vector length (BVL) is a seven bit unsigned integer
>> field and the bit vector offset (BVO) is a nine bit unsigned integer
>> field. ?The bits in each bit vector are numbered in network order, the
>> high order bit of the first byte of bits being bit 0 + 8*BVO, the low
>> order bit of that byte being 7 + 8*BVO, the high order bit of the
>> second byte being 8 + 8*BVO, and so on for BVL bytes. An RBridge
>> Channel protocols supported bit vector MUST NOT extend beyond the end
>> of the value in the APPsub-TLV in which it occurs. If multiple byte
>> aligned bit vectors are present in one such APPsub-TLV, they are
>> contiguous, the BVL field for the next starting immediately after the
>> last byte of bits for the previous. ?The one or more bit vectors
>> present MUST exactly fill the APPsub-TLV value.
>>
>> If different bit vectors overlap in the protocol number space they
>> refer to and have inconsistent bit values for a protcol, support for
>> the protocol is assumed if any of these bit vectors has a 1 for that
>> protocol.
>>
>> The absence of any occurrences of this APPsub-TLV in the link state
>> for an RBridge implies that that RBridge does not support the RBridge
>> Channel feature. Because RBridge Channel protocols 0 and 0xFFF are
>> reserved and protocol 1, the RBridge Channel error protocol, MUST be
>> implemented as part of the RBridge Channel feature, should bit
>> positions for those protocols appear in bit vectors in this
>> APPsub-TLV, the bits for protocols 0 and 0xFFF MUST be 0 and the bit
>> for protocol 1 MUST be one; however, these bits are ignored on receipt
>> and support for protocol 1 is always assumed if there are any
>> occurrences of this APPsub-TLV. ?To avoid wasted space, trailing bit
>> vector zero bytes SHOULD be eliminated by reducing BVL and any null
>> bit vectors (ones with BVL equal to zero) eliminated.


From d3e3e3 at gmail.com  Fri May 13 10:18:14 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 13 May 2011 13:18:14 -0400
Subject: [rbridge] Fwd: [Pppext] Working group last call for PPP TRILL [was
	I-D Action: draft-ietf-pppext-trill-protocol-04.txt]
In-Reply-To: <4DC812D4.2010307@workingcode.com>
References: <20110509160227.21325.4443.idtracker@ietfa.amsl.com>
	<4DC812D4.2010307@workingcode.com>
Message-ID: <BANLkTimBN509Li3etTXk2dZ9fSJn_HWMbA@mail.gmail.com>

Hi,

TRILL participant may be interested in the below Last Call in the
PPPEXT Working Group.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com

---------- Forwarded message ----------
From: James Carlson <carlsonj at workingcode.com>
Date: Mon, May 9, 2011 at 12:14 PM
Subject: [Pppext] Working group last call for PPP TRILL [was I-D
Action: draft-ietf-pppext-trill-protocol-04.txt]
To: PPP Extensions <pppext at ietf.org>


internet-drafts at ietf.org wrote:
> 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) ? ? ? : James Carlson
> ? ? ? Filename ? ? ? ?: draft-ietf-pppext-trill-protocol-04.txt
> ? ? ? Pages ? ? ? ? ? : 7
> ? ? ? Date ? ? ? ? ? ?: 2011-05-09

In this new version, I've removed stray footnote references from the
stand-alone Abstract section and added a bit of detail to the Security
Considerations -- specifically citing at least a few of the protocols
involved. ?There's a slippery slope here, in that I could easily end up
describing all the possible deployment scenarios and incorporating
essentially all of rfc-index.txt by reference, but I hope I've struck a
reasonable balance.

I've left the system ID issue as an informative reference. ?No matter
how I read this PPP document, providing system IDs is not a requirement
for implementing this protocol. ?It _might_ be a requirement for IS-IS
implementations. ?But the protocol described here isn't IS-IS.

So, with that, I'm starting up the last call period again. ?Please
respond by May 23rd, 2011, if you have any comments. ?After that date,
I'll ask the IESG to consider publishing.

--
James Carlson ? ? ? ? 42.703N 71.076W ? ? ? ? <carlsonj at workingcode.com>
_______________________________________________
Pppext mailing list
Pppext at ietf.org
https://www.ietf.org/mailman/listinfo/pppext


From rakeshk at ipinfusion.com  Mon May 16 00:01:46 2011
From: rakeshk at ipinfusion.com (Rakesh Kumar)
Date: Mon, 16 May 2011 12:31:46 +0530
Subject: [rbridge] rbridge Digest, Vol 84, Issue 8[d-vlan]
Message-ID: <BANLkTimb_EC9BnyCoX0JnHCyUyUwPXrcMQ@mail.gmail.com>

Hi,
I have doubt that TRILL may enable VLAN attacks.

consider the case where end station enabled vlan is selected as D-Vlan
then end station on this D-vlan can emulate or spoof an RBridge, and
therefore gain access and control to the entire network.


Consider another case where Two rbridges(RB1 and RB2) connected through B2
as follows:

   +----+         +----+         +----+
   | RB1|---------| B2 |---------| RB3|
   +----+         +----+         +----+

 RB1 is in an insecure location, where an user might gain physical access
and compromise it.B2 and RB3 are in a secure location, and have ports
configured on VLAN 2 with servers attached. The administrator wants RB1 to
have access to VLAN 1, and to prevent a RB1 from being able to access the
servers on VLAN 2.

one might naturally expect a TRILL VLAN to behave like an 802.1Q VLAN, so
that VLAN 2 will still be constrained by the configuration on B2 but this is
not the case. Since VLAN tag isn?t copied to the outer MAC header, and
instead TRILL forwards the frame over a single common VLAN called the
designated VLAN.An attacker that compromised RB1 could configure full access
to any end station on VLAN 2 attached to B2 and RB3.



regards,

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

From d3e3e3 at gmail.com  Mon May 16 06:52:08 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 16 May 2011 09:52:08 -0400
Subject: [rbridge] rbridge Digest, Vol 84, Issue 8[d-vlan]
In-Reply-To: <BANLkTimb_EC9BnyCoX0JnHCyUyUwPXrcMQ@mail.gmail.com>
References: <BANLkTimb_EC9BnyCoX0JnHCyUyUwPXrcMQ@mail.gmail.com>
Message-ID: <BANLkTinY0V9ZSYbeCNn0R2pwjD4Z3UG0Rg@mail.gmail.com>

Hi Rakesh,

On Mon, May 16, 2011 at 3:01 AM, Rakesh Kumar <rakeshk at ipinfusion.com> wrote:
> Hi,
> I have doubt that TRILL may enable VLAN attacks.
>
> consider the case where end station enabled vlan is selected as D-Vlan
> then?end station?on this D-vlan can emulate or spoof an RBridge, and
> therefore gain access and control to the entire network.

I assume that by "D-vlan" you mean Designated VLAN. If you want be
sure people will understand you, it is better to spell things out.

For the most part, I don't see why you think your concern above has
anything to do with TRILL. It is a general characteristic of any
dynamic routing protocol that if you cannot authenticate the routing
messages, someone can "spoof" a router, send routing control messages,
and screw things up. Using IS-IS authentication can help in the TRILL
case.

> Consider another case where Two rbridges(RB1 and RB2) connected through B2
> as follows:
>
>    +----+         +----+         +----+
>    | RB1|---------| B2 |---------| RB3|
>    +----+         +----+         +----+
>
> RB1 is in an insecure location, where an?user might gain physical access and
> compromise it.

By putting a router that can be compromised in an insecure location,
you have already abandoned security.

> B2 and RB3 are in a secure location,?and have ports configured
> on VLAN 2 with servers attached. The administrator wants RB1 to have access
> to VLAN 1, and to prevent a RB1 from being able to access the servers on
> VLAN 2.

Is it actually that you don't want RB1 to access these VLAN 2 servers?
Or is it that you don't want end stations attached to RB1 to access
these VLAN 2 servers? If it the first, then you shouldn't be trusting
RB1 as a router at all. If it is the second and you can trust RB1,
then all you have to do is disable VLAN 2 (or arrange for there to
never be a VLAN 2 appointed forwarder) on all the RB1 ports that might
lead to one of the end stations you want to restrict.

> one might naturally expect a TRILL VLAN to behave like an 802.1Q VLAN, so
> that VLAN 2 will still be constrained by the configuration on B2 but this is
> not the case.

Right. TRILL enables connectivity between all end stations in the same
VLAN and, if you replace bridges with RBridges, glues together what
might otherwise be VLAN islands. It was the consensus of the TRILL WG
that it work this way. This can have advantages. Say, for example,
that two parts of your campus are connected by carrier Ethernet
facilities that only pass frames labeled with some particular
arbitrary VLAN, say VLAN 2473. Then all you have to do is configure
that as the Designated VLAN on that link and you have full
connectivity.

Perhaps to get the effect you may want, you need something like the
optional feature described in
http://tools.ietf.org/html/draft-ietf-trill-rbridge-vlan-mapping-05

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com

> Since VLAN tag isn?t copied to the outer MAC header, and
> instead TRILL forwards the frame over a single common VLAN called the
> designated VLAN. An attacker that compromised RB1 could configure full access
> to any end station on VLAN 2 attached to B2 and RB3.
>
> regards,
> RAKESH


From nordmark at acm.org  Mon May 16 11:28:26 2011
From: nordmark at acm.org (Erik Nordmark)
Date: Mon, 16 May 2011 11:28:26 -0700
Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-mib-02.txt
Message-ID: <4DD16CCA.90100@acm.org>


This starts a two week last call on our MIB documents, which ends on May 
31st.

Please send comments to the list.

If you've reviewed it and think it is good, also send a message to the list.

    Erik


From ginsberg at cisco.com  Mon May 16 12:45:12 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Mon, 16 May 2011 12:45:12 -0700
Subject: [rbridge] RBridge Channel 3/3: Indicating support for RBridge
	Channel protocols
In-Reply-To: <BANLkTi=Ayb0pyJiBU6pVTqbEmhupF0A2Dg@mail.gmail.com>
References: <BANLkTimnrNQf0v4vvUHeNrwm61GaAeL3yA@mail.gmail.com><4DCD4799.8000209@cisco.com>
	<BANLkTi=Ayb0pyJiBU6pVTqbEmhupF0A2Dg@mail.gmail.com>
Message-ID: <AE36820147909644AD2A7CA014B1FB520E3B2B4B@xmb-sjc-222.amer.cisco.com>

Donald -

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Donald Eastlake
> Sent: Friday, May 13, 2011 9:09 AM
> To: Mike Shand (mshand)
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] RBridge Channel 3/3: Indicating support for
> RBridge Channel protocols
> 
> Hi Mike,
> 
> On Fri, May 13, 2011 at 11:00 AM, mike shand <mshand at cisco.com> wrote:
> > Hi Donald,
> > ? ? I'm trying to understand the rationale for this using GENAPP
> rather
> > than, say, a router capability TLV. Is it the case that support for
> > channels is considered to be an application as far as routing is
> > concerned? i.e. all you are doing is advertising some information
> which
> > is used by some other "application", such as OAM or BFD, as opposed
> to
> > some information that is used by "routing" itself?
> 
> Right. It's just about whether you can originate or understand certain
> types of data messages. The RBridge Channel messages are strictly
> conformant to the specification for a TRILL Data frame. The only clue
> is that the encapsulated Ethernet frame has a magic multicast
> destination MAC address, which pushes it to the slow path at the
> "egress" and then the Etherype indicates that it needs to be processed
> as an RBridge Channel message.

I too was confused regarding the use of GENAPP as the use of the proposed GENAPP info is not discussed in the draft. I can only presume that the intended use is to have IS-IS inform some "application" running on the router that a particular Rbridge has indicated that it does/does not support a particular Data Capability. Is that the intent? If so, could you explain why this is needed i.e. what will break if an application did not have this information? 

GENAPP is intended to support the use of the reliable flooding mechanism which the IS-IS update process provides on behalf an application specific information - not simply to indicate that an application exists. This is why in Section 5 of the GENAPP draft we specify that a separate non-zero instance of IS-IS MUST be used to send GENAPP information - which does not seem to align with what you are doing here.

Can you please clarify the requirements?

   Les

> 
> > I guess an important
> > differentiator is to ask whether "routing" would ever make any
> different
> > decisions on the basis of this information. From what I can see, the
> > answer to that question is NO. Is that a correct assessment?
> 
> Yes. It has no effect on any routing decisions.
> 
> Thanks,
> Donald
> =============================
> ?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
> ?155 Beaver Street
> ?Milford, MA 01757 USA
> ?d3e3e3 at gmail.com
> 
> > ? ? Mike
> >
> >
> > On 13/05/2011 13:34, Donald Eastlake wrote:
> >> Hi,
> >>
> >> Currently draft-ietf-trill-rbridge-channel-00 allocates an ISIS
> GENAPP
> >> ID for TRILL and specifies an APPsub-TLV with just one bit that
> >> indicates whether the RBridge supports the Channel Facility or not.
> I
> >> think it would be better to specify an APPsub-TLV with a bit per
> >> RBridge Channel protocol to indicate support of that protocol. See
> >> draft text fragment pasted at the bottom of this message.
> >>
> >> Thanks,
> >> Donald
> >>
> >> PS: This is the third of three suggested tweaks to the RBridge
> Channel
> >> draft. I'm posting them separately to make discussion easier.
> >> =============================
> >> ? Donald E. Eastlake 3rd ? +1-508-333-2270 (cell)
> >> ? 155 Beaver Street
> >> ? Milford, MA 01757 USA
> >> ? d3e3e3 at gmail.com
> >>
> >>
> >>
> >> Support for RBridge Channel protocols is indicated by the presence
> of
> >> one or more Channel Protocols TRILL APPsub-TLVs in an RBridge's link
> >> state. ?The Channel Protocols TRILL APPsub-TLV has as its value one
> or
> >> more byte aligned bit vectors where a one bit indicates support of a
> >> particular RBridge Channel protocol. Each byte aligned bit vector is
> >> formatted as follows:
> >>
> >> | 0 ?1 ?2 ?3 ?4 ?5 ?6 ?7| 8 ?9 10 11 12 13 14 15|
> >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> >> | ?Bit Vector Length | ? ? Bit Vector Offset ? ?|
> >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> >> | ?bits
> >> +--+--+--...
> >>
> >> Note that the bit vector length (BVL) is a seven bit unsigned
> integer
> >> field and the bit vector offset (BVO) is a nine bit unsigned integer
> >> field. ?The bits in each bit vector are numbered in network order,
> the
> >> high order bit of the first byte of bits being bit 0 + 8*BVO, the
> low
> >> order bit of that byte being 7 + 8*BVO, the high order bit of the
> >> second byte being 8 + 8*BVO, and so on for BVL bytes. An RBridge
> >> Channel protocols supported bit vector MUST NOT extend beyond the
> end
> >> of the value in the APPsub-TLV in which it occurs. If multiple byte
> >> aligned bit vectors are present in one such APPsub-TLV, they are
> >> contiguous, the BVL field for the next starting immediately after
> the
> >> last byte of bits for the previous. ?The one or more bit vectors
> >> present MUST exactly fill the APPsub-TLV value.
> >>
> >> If different bit vectors overlap in the protocol number space they
> >> refer to and have inconsistent bit values for a protcol, support for
> >> the protocol is assumed if any of these bit vectors has a 1 for that
> >> protocol.
> >>
> >> The absence of any occurrences of this APPsub-TLV in the link state
> >> for an RBridge implies that that RBridge does not support the
> RBridge
> >> Channel feature. Because RBridge Channel protocols 0 and 0xFFF are
> >> reserved and protocol 1, the RBridge Channel error protocol, MUST be
> >> implemented as part of the RBridge Channel feature, should bit
> >> positions for those protocols appear in bit vectors in this
> >> APPsub-TLV, the bits for protocols 0 and 0xFFF MUST be 0 and the bit
> >> for protocol 1 MUST be one; however, these bits are ignored on
> receipt
> >> and support for protocol 1 is always assumed if there are any
> >> occurrences of this APPsub-TLV. ?To avoid wasted space, trailing bit
> >> vector zero bytes SHOULD be eliminated by reducing BVL and any null
> >> bit vectors (ones with BVL equal to zero) eliminated.
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge


From anoop at alumni.duke.edu  Mon May 16 16:46:07 2011
From: anoop at alumni.duke.edu (Anoop Ghanwani)
Date: Mon, 16 May 2011 16:46:07 -0700
Subject: [rbridge] rbridge Digest, Vol 84, Issue 8[d-vlan]
In-Reply-To: <BANLkTimb_EC9BnyCoX0JnHCyUyUwPXrcMQ@mail.gmail.com>
References: <BANLkTimb_EC9BnyCoX0JnHCyUyUwPXrcMQ@mail.gmail.com>
Message-ID: <BANLkTi=VLP2shd_2b5sKh-iLis2pN0GUJg@mail.gmail.com>

On Mon, May 16, 2011 at 12:01 AM, Rakesh Kumar <rakeshk at ipinfusion.com>wrote:

> Hi,
> I have doubt that TRILL may enable VLAN attacks.
>
> consider the case where end station enabled vlan is selected as D-Vlan
> then end station on this D-vlan can emulate or spoof an RBridge, and
> therefore gain access and control to the entire network.
>
>
> Consider another case where Two rbridges(RB1 and RB2) connected through B2
> as follows:
>
>    +----+         +----+         +----+
>    | RB1|---------| B2 |---------| RB3|
>    +----+         +----+         +----+
>
>  RB1 is in an insecure location, where an user might gain physical access
> and compromise it.B2 and RB3 are in a secure location, and have ports
> configured on VLAN 2 with servers attached. The administrator wants RB1 to
> have access to VLAN 1, and to prevent a RB1 from being able to access the
> servers on VLAN 2.
>
>From a TRILL standpoint, B2 can be thought of as being
"open" to all VLANs i.e. if RB1 and RB2 were regular bridges,
then B2 is open to all VLANs on both ports.

Since RB1 is untrusted, the way to implement the policy
would be restrict decapsulation of RB1 traffic at RB3 to
only those VLANs which RB1 is allowed to send to RB3
which can be accomplished using ACLs.

In general, as Donald pointed out in his reply, it doesn't
make sense to have an untrusted device be part of
the same TRILL campus.  To solve the above, problem,
it would be better to design the network such that B2
is an RBridge and it receives regular, non-TRILL Ethernet
traffic from "RB1" which should be a regular bridge.

Your issue is valid, but the problem is with how the
network is constructed and not a problem with
TRILL itself.  Any MAC-in-MAC encapsulation protocol
(e.g. 802.1ah) would have a similar problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20110516/9450be64/attachment.html

From abhinavb at ipinfusion.com  Tue May 17 09:40:59 2011
From: abhinavb at ipinfusion.com (Abhinav Bhatia)
Date: Tue, 17 May 2011 22:10:59 +0530
Subject: [rbridge] RBridge issue with selecting designated vlan
Message-ID: <BANLkTi=do2uX08Wj7x-9x31ZGP1RPy_ycQ@mail.gmail.com>

Hi Donald,

As part the initial trill study I am facing following critical issue:

In trill protocol the designated router bridge(drb) selects the designated
vlan(dvlan) on which all the router bridges will
communicate. This designated vlan should be enabled on all the vlans.

Now the next thing is to make sure that this designated vlan is enabled vlan
on each of the neighbors,
since we dont have separate tlv for enabled vlans, we need to keep track of
vlans on which hellos are received from each of the neighbors.

But Doing this does not guarantee the proper working, problems with doing
that:

1) If we make announcing vlan set as null, then hellos will only be sent on
designated vlan by non-drb. But drb can not
    select designated vlan other than the one on which hello was sent by non
drb. If this designated vlan gets disabled on non-drb
    then it may be totally isolated (new designated vlan selected by drb may
not be enabled on the non-drb router bridge).

2) Even if the announcing vlan is not null, still the sending of hellos on
different vlans depends upon the set of appointed
    forwarders and if drb makes the non-drb appointed forwarder for limited
set of vlans then again hellos wont be sent on all
    vlans leading to the incomplete knowledge of enabled vlans.


There can be be two approaches to that:

a) Fix the designated vlan and make sure that is enabled on all router
bridges, not giving the router bridges an option to change
    designated vlan. Again using this approach an router bridge will be
isolated if designated vlan gets disabled.

b) Send an extra tlv containg enabled vlans, i think using this should
resolve the above mentioned issues.

It will be great if you can help us with this issue.

Thanks,
Abhinav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20110517/840afc54/attachment.html

From sgai at cisco.com  Tue May 17 15:04:33 2011
From: sgai at cisco.com (Silvano Gai)
Date: Tue, 17 May 2011 15:04:33 -0700
Subject: [rbridge] Retiring
Message-ID: <C9F83F01.2D434%sgai@cisco.com>


Friends,

I am retiring from Cisco at the end of this week.
I want to thank all the inspiring people I have worked with during my
fourteen years in the US.
Cisco is a great company to work for and it will remain in my heart forever.

I wish you all a bright future.

We can keep in touch using linkedin.
> http://www.linkedin.com/pub/silvano-gai/1/63b/152
  
All the best
>   
>  -- Silvano
>   
>   

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

From d3e3e3 at gmail.com  Tue May 17 15:53:17 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 17 May 2011 18:53:17 -0400
Subject: [rbridge] Retiring
In-Reply-To: <C9F83F01.2D434%sgai@cisco.com>
References: <C9F83F01.2D434%sgai@cisco.com>
Message-ID: <BANLkTimz743iTbBTDPTZkO+CJH6oKH3yCA@mail.gmail.com>

Hi Silvano,

Good luck, and thanks for your contributions to TRILL.

Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com

On Tue, May 17, 2011 at 6:04 PM, Silvano Gai <sgai at cisco.com> wrote:
>
> Friends,
>
> I am retiring from Cisco at the end of this week.
> I want to thank all the inspiring people I have worked with during my
> fourteen years in the US.
> Cisco is a great company to work for and it will remain in my heart forever.
>
> I wish you all a bright future.
>
> We can keep in touch using linkedin.
>
> http://www.linkedin.com/pub/silvano-gai/1/63b/152
>
>
> All the best
>
>
> ?-- Silvano
>
>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>


From sgai at cisco.com  Tue May 17 17:26:50 2011
From: sgai at cisco.com (Silvano Gai)
Date: Tue, 17 May 2011 17:26:50 -0700
Subject: [rbridge] Retiring
In-Reply-To: <BANLkTimz743iTbBTDPTZkO+CJH6oKH3yCA@mail.gmail.com>
Message-ID: <C9F8605A.2D453%sgai@cisco.com>

Thank You

-- Silvano


On 5/17/11 3:53 PM, "Donald Eastlake" <d3e3e3 at gmail.com> wrote:

> Hi Silvano,
> 
> Good luck, and thanks for your contributions to TRILL.
> 
> Donald
> =============================
> ?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
> ?155 Beaver Street
> ?Milford, MA 01757 USA
> ?d3e3e3 at gmail.com
> 
> On Tue, May 17, 2011 at 6:04 PM, Silvano Gai <sgai at cisco.com> wrote:
>> 
>> Friends,
>> 
>> I am retiring from Cisco at the end of this week.
>> I want to thank all the inspiring people I have worked with during my
>> fourteen years in the US.
>> Cisco is a great company to work for and it will remain in my heart forever.
>> 
>> I wish you all a bright future.
>> 
>> We can keep in touch using linkedin.
>> 
>> http://www.linkedin.com/pub/silvano-gai/1/63b/152
>> 
>> 
>> All the best
>> 
>> 
>> ?-- Silvano
>> 
>> 
>> 
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>> 
>> 



From d3e3e3 at gmail.com  Wed May 18 05:20:00 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Wed, 18 May 2011 08:20:00 -0400
Subject: [rbridge] RBridge issue with selecting designated vlan
In-Reply-To: <BANLkTi=do2uX08Wj7x-9x31ZGP1RPy_ycQ@mail.gmail.com>
References: <BANLkTi=do2uX08Wj7x-9x31ZGP1RPy_ycQ@mail.gmail.com>
Message-ID: <BANLkTimdYxvTSRs_6JdvWfnqwM-Ji=GL0w@mail.gmail.com>

Hi Abhinav,

On Tue, May 17, 2011 at 12:40 PM, Abhinav Bhatia
<abhinavb at ipinfusion.com> wrote:
> Hi Donald,
>
> As part the initial trill study I am facing following critical issue:
>
> In trill protocol the designated router bridge(drb) selects the designated
> vlan(dvlan) on which all the router bridges will
> communicate. This designated vlan should be enabled on all the vlans.

Pretty much right, assuming your last word above was intended to be
"Rbridges" or "Rbridge ports on the link" or the like.

However, I don't think your word "selects" corresponds very well with
the TRILL base protocol standard. In the standard, each RBridge port
on the link is configured with a desired Designated VLAN and whichever
port wins the DRB elections dictates that that VLAN be the Designated
VLAN on the link. There is no "selection" process for the Designated
VLAN except to the extent that there is a selection process, the DRB
election, for the DRB.

> Now the next thing is to make sure that this designated vlan is enabled vlan
> on each of the neighbors,
> since we dont have separate tlv for enabled vlans, we need to keep track of
> vlans on which hellos are received from each of the neighbors.

Actually, there is the Enabled VLANs sub-TLV, as documented in Section
2.2.2 of draft-ietf-is-is-trill-05, which can be included in the MT
Port Capabilities TLV; however, sending it is optional. There is no
requirement to keep track of all the VLANs on which you receive Hellos
from neighbors. See draft-ietf-trill-adj-07.

The way to make sure the Designated VLAN is enabled on all the
neighbor RBridge ports on the link is to properly configure the
neighbor RBridges so this is true.

> But Doing this does not guarantee the proper working, problems with doing
> that:
>
> 1) If we make announcing vlan set as null, then hellos will only be sent on
> designated vlan by non-drb. But drb can not
> ??? select designated vlan other than the one on which hello was sent by non
> drb. If this designated vlan gets disabled on non-drb
> ??? then it may be totally isolated (new designated vlan selected by drb may
> not be enabled on the non-drb router bridge).

The ability to configuring the announcing set to be a smaller set
(null in the limit) is intended for network operators who want fewer
Hellos, are confident that their networks are properly configured, and
are willing to accept the higher chance of loops or orphaned
(isolated) RBridge ports if they turn out to be wrong and their
networks are not properly configured.

On a properly configured link, all the RBridge ports are configured
with the same desired Designated VLAN and that VLAN is enabled on all
RBridge ports. If that is not true, the link is not properly
configured. And if you such an improperly configured link and then
configure the announcing VLAN set to be null at one or more RBridge
port on the link, you are making the configuration even worse and
possibly no longer loop-safe.

> 2) Even if the announcing vlan is not null, still the sending of hellos on
> different vlans depends upon the set of appointed
> ??? forwarders and if drb makes the non-drb appointed forwarder for limited
> set of vlans then again hellos wont be sent on all
> ??? vlans leading to the incomplete knowledge of enabled vlans.
>
> There can be be two approaches to that:
>
> a) Fix the designated vlan and make sure that is enabled on all router
> bridges, not giving the router bridges an option to change
> ??? designated vlan. Again using this approach an router bridge will be
> isolated if designated vlan gets disabled.

I'm not sure exactly what you mean in (a) above, but configuring all
the RBridge ports on the link so the same VLAN is desired Designated
VLAN and enabled on them all is proper configuration. TRILL tries hard
to be safe for improperly configured links but does not worry about
efficient operation for improperly configured links.

> b) Send an extra tlv containg enabled vlans, i think using this should
> resolve the above mentioned issues.

How to select the priorities of different RBridge ports to be DRB, how
to select the desired  Designated VLAN to configure in the ports on a
link (if it is not he default VLAN 1), how to determine which RBridges
to appoint forwarder for which VLANs, when to send an Enabled VLANs
sub-TLV, etc., are all beyond the scope of the TRILL base protocol
standard.

In summary, things will work well for a properly configured link as
described above. Things will not work so well if desired Designated
VLANs and/or enabled VLANs are inconsistent -- and there are no
provisions in the TRILL base protocol standard to try to automatically
fix improper configurations. And if you decrease the membership of the
announcing set below its default membership, you accepting an
increased chance of unsafe operation in exchange for fewer Hellos.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com

> It will be great if you can help us with this issue.
>
> Thanks,
> Abhinav


From zhangmingui at huawei.com  Wed May 18 17:33:18 2011
From: zhangmingui at huawei.com (Zhangmingui, (Mingui))
Date: Thu, 19 May 2011 00:33:18 +0000
Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-mib-02.txt
In-Reply-To: <4DD16CCA.90100@acm.org>
References: <4DD16CCA.90100@acm.org>
Message-ID: <4552F0907735844E9204A62BBDD325E737E350@SZXEML503-MBX.china.huawei.com>

Hi,

I have read the draft. It looks good. 

Please read the following notes.

On page 3, it says, "like routers, they terminate the bridge spanning tree protocol."
Actually, STP and routing protocol run in parallel in the same network.

On page 4, it says "some MIB objects are not applicable". 
This is not clear. As I understood, it can be replace with "some IS-IS MIB objects are not applicable in TRILL".

On page 4, it says "RBridges provide optimal pair-wise forwarding without configuration using IS-IS routing and encapsulation of traffic." 
(1) Personally, the word "optimal" is not accurate, while "shortest" may be more proper. 
(2) "without configuration" is not accurate either. It is appropriate to say "with least configuration". 
(3) I know TRILL uses routing (control layer) of ISIS, but I do not know that TRILL use the encapsulation (data layer) of IS-IS? 

Rbridge->RBridge
"RBridge" are freqently typed as "Rbridge" in the text.

My apologies if you receive duplicates of this email. I was changing my registered email address for the mailing list.

--
Mingui Zhang
Huawei Technologies Co.,Ltd


> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Erik Nordmark
> Sent: Tuesday, May 17, 2011 2:28 AM
> To: rbridge at postel.org
> Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-mib-02.txt
> 
> 
> This starts a two week last call on our MIB documents, which ends on May
> 31st.
> 
> Please send comments to the list.
> 
> If you've reviewed it and think it is good, also send a message to the list.
> 
>     Erik
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

From zhangmingui at huawei.com  Thu May 19 01:04:17 2011
From: zhangmingui at huawei.com (Zhangmingui, (Mingui))
Date: Thu, 19 May 2011 08:04:17 +0000
Subject: [rbridge] codepoint consideration for Multi Topology mapping
Message-ID: <4552F0907735844E9204A62BBDD325E737E3E6@SZXEML503-MBX.china.huawei.com>

Hi, 

Multi topology routing should be naturally supported by TRILL since it reuse the control layer of IS-IS. However, the current trill header does not have the code point for MT routing. We know that ISIS can use the DSCP field to map the MT IDs. I think that we can extend a new option field of TRILL header or to occupy some bits of the VLAN field to map the MT IDs. 

What is your opinion?

--
Mingui Zhang
Huawei Technologies Co.,Ltd 



From d3e3e3 at gmail.com  Thu May 19 06:38:27 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 19 May 2011 09:38:27 -0400
Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-mib-02.txt
In-Reply-To: <4552F0907735844E9204A62BBDD325E737E350@SZXEML503-MBX.china.huawei.com>
References: <4DD16CCA.90100@acm.org>
	<4552F0907735844E9204A62BBDD325E737E350@SZXEML503-MBX.china.huawei.com>
Message-ID: <BANLkTim4agDcQE0RO7kShBg0+BR2ViZF2g@mail.gmail.com>

Hi Mingui,

I hope Anil won't mind if I respond to some of your points...

On Wed, May 18, 2011 at 8:33 PM, Zhangmingui, (Mingui)
<zhangmingui at huawei.com> wrote:
> Hi,
>
> I have read the draft. It looks good.

Thanks.

> Please read the following notes.
>
> On page 3, it says, "like routers, they terminate the bridge spanning tree protocol."
> Actually, STP and routing protocol run in parallel in the same network.

I don't actually understand your comment. Maybe it should say "like
routers and other end stations, ...". The point is that, although an
RBridge port can optionally participate in spanning tree as a leaf
node, it never interacts with other ports of the same RBridge to form
a spanning tree branch through the RBridge. So it terminates the
spanning tree protocol and does not propagate it through the RBridge.
On the other hand, RBridges do propagate IS-IS and form least cost
routes through RBridges...

> On page 4, it says "some MIB objects are not applicable".
> This is not clear. As I understood, it can be replace with "some IS-IS MIB objects are not applicable in TRILL".

I'll leave that for Anil to comment on.

> On page 4, it says "RBridges provide optimal pair-wise forwarding without configuration using IS-IS routing and encapsulation of traffic."
> (1) Personally, the word "optimal" is not accurate, while "shortest" may be more proper.

The word "optimal" assumes there is some metric. I think people
generally understand it is least cost. "Shortest" would only be
accurate if it was based on number of hops. Since it is based on link
cost, if one was to replace "optimal", I think the best replacement
would be "least cost".

> (2) "without configuration" is not accurate either. It is appropriate to say "with least configuration".

What do you have to configure? If you hook together RBridges, they
will find each other and be able to forward over least cost paths
based on link costs auto-configured from link speed.

> (3) I know TRILL uses routing (control layer) of ISIS, but I do not know that TRILL use the encapsulation (data layer) of IS-IS?

Is there an data layer of IS-IS? IS-IS just discovers the topology and
provides least cost routes. I don't think IS-IS says anything about
the data frame format which could be CLNP or IP or TRILL or
whatever...

> Rbridge->RBridge
> "RBridge" are freqently typed as "Rbridge" in the text.

According to the TRILL base protocol standard: "The second letter in
Rbridge is case insensitive. Both Rbridge and RBridge are correct."

> My apologies if you receive duplicates of this email. I was changing my registered email address for the mailing list.

No problem,
Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com

> --
> Mingui Zhang
> Huawei Technologies Co.,Ltd
>
>> -----Original Message-----
>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
>> Behalf Of Erik Nordmark
>> Sent: Tuesday, May 17, 2011 2:28 AM
>> To: rbridge at postel.org
>> Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-mib-02.txt
>>
>>
>> This starts a two week last call on our MIB documents, which ends on May
>> 31st.
>>
>> Please send comments to the list.
>>
>> If you've reviewed it and think it is good, also send a message to the list.
>>
>> ? ? Erik
>>
>> _______________________________________________
>> 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 anil at charter.net  Thu May 19 08:24:52 2011
From: anil at charter.net (Anil Rijhsinghani)
Date: Thu, 19 May 2011 11:24:52 -0400 (EDT)
Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-mib-02.txt
Message-ID: <173f2ab1.b32dd.13008dbfb26.Webtop.48@charter.net>

Mingui,

I agree with Donald's response below; as for the one that remained:

> On page 4, it says "some MIB objects are not applicable".
> This is not clear. As I understood, it can be replace with "some IS-IS 
> MIB objects are not applicable in TRILL".

Yes that is what was meant, and we'll make that clarification in the 
next draft.

Regards,
Anil

On Thu, May 19, 2011 at 9:38 AM, Donald Eastlake wrote:

> Hi Mingui,
>
> I hope Anil won't mind if I respond to some of your points...
>
> On Wed, May 18, 2011 at 8:33 PM, Zhangmingui, (Mingui)
> <zhangmingui at huawei.com> wrote:
>> Hi,
>>
>> I have read the draft. It looks good.
>
> Thanks.
>
>> Please read the following notes.
>>
>> On page 3, it says, "like routers, they terminate the bridge spanning 
>> tree protocol."
>> Actually, STP and routing protocol run in parallel in the same 
>> network.
>
> I don't actually understand your comment. Maybe it should say "like
> routers and other end stations, ...". The point is that, although an
> RBridge port can optionally participate in spanning tree as a leaf
> node, it never interacts with other ports of the same RBridge to form
> a spanning tree branch through the RBridge. So it terminates the
> spanning tree protocol and does not propagate it through the RBridge.
> On the other hand, RBridges do propagate IS-IS and form least cost
> routes through RBridges...
>
>> On page 4, it says "some MIB objects are not applicable".
>> This is not clear. As I understood, it can be replace with "some 
>> IS-IS MIB objects are not applicable in TRILL".
>
> I'll leave that for Anil to comment on.
>
>> On page 4, it says "RBridges provide optimal pair-wise forwarding 
>> without configuration using IS-IS routing and encapsulation of 
>> traffic."
>> (1) Personally, the word "optimal" is not accurate, while "shortest" 
>> may be more proper.
>
> The word "optimal" assumes there is some metric. I think people
> generally understand it is least cost. "Shortest" would only be
> accurate if it was based on number of hops. Since it is based on link
> cost, if one was to replace "optimal", I think the best replacement
> would be "least cost".
>
>> (2) "without configuration" is not accurate either. It is appropriate 
>> to say "with least configuration".
>
> What do you have to configure? If you hook together RBridges, they
> will find each other and be able to forward over least cost paths
> based on link costs auto-configured from link speed.
>
>> (3) I know TRILL uses routing (control layer) of ISIS, but I do not 
>> know that TRILL use the encapsulation (data layer) of IS-IS?
>
> Is there an data layer of IS-IS? IS-IS just discovers the topology and
> provides least cost routes. I don't think IS-IS says anything about
> the data frame format which could be CLNP or IP or TRILL or
> whatever...
>
>> Rbridge->RBridge
>> "RBridge" are freqently typed as "Rbridge" in the text.
>
> According to the TRILL base protocol standard: "The second letter in
> Rbridge is case insensitive. Both Rbridge and RBridge are correct."
>
>> My apologies if you receive duplicates of this email. I was changing 
>> my registered email address for the mailing list.
>
> No problem,
> Thanks,
> Donald
> =============================
> ?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
> ?155 Beaver Street
> ?Milford, MA 01757 USA
> ?d3e3e3 at gmail.com
>
>> --
>> Mingui Zhang
>> Huawei Technologies Co.,Ltd
>>
>>> -----Original Message-----
>>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] 
>>> On
>>> Behalf Of Erik Nordmark
>>> Sent: Tuesday, May 17, 2011 2:28 AM
>>> To: rbridge at postel.org
>>> Subject: [rbridge] WG last call on 
>>> draft-ietf-trill-rbridge-mib-02.txt
>>>
>>>
>>> This starts a two week last call on our MIB documents, which ends on 
>>> May
>>> 31st.
>>>
>>> Please send comments to the list.
>>>
>>> If you've reviewed it and think it is good, also send a message to 
>>> the list.
>>>
>>> ? ? Erik
>>>
>>> _______________________________________________
>>> 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 d3e3e3 at gmail.com  Thu May 19 09:48:12 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 19 May 2011 12:48:12 -0400
Subject: [rbridge] RBridge Channel 3/3: Indicating support for RBridge
 Channel protocols
In-Reply-To: <AE36820147909644AD2A7CA014B1FB520E3B2B4B@xmb-sjc-222.amer.cisco.com>
References: <BANLkTimnrNQf0v4vvUHeNrwm61GaAeL3yA@mail.gmail.com>
	<4DCD4799.8000209@cisco.com>
	<BANLkTi=Ayb0pyJiBU6pVTqbEmhupF0A2Dg@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520E3B2B4B@xmb-sjc-222.amer.cisco.com>
Message-ID: <BANLkTikPQC6DHU-Ua5t326w2KpbDANcdcQ@mail.gmail.com>

Hi Les,

On Mon, May 16, 2011 at 3:45 PM, Les Ginsberg (ginsberg)
<ginsberg at cisco.com> wrote:

> Donald -
>
>> -----Original Message-----
>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
>> Behalf Of Donald Eastlake
>> Sent: Friday, May 13, 2011 9:09 AM
>> To: Mike Shand (mshand)
>> Cc: rbridge at postel.org
>> Subject: Re: [rbridge] RBridge Channel 3/3: Indicating support for
>> RBridge Channel protocols
>>
>> Hi Mike,
>>
>> On Fri, May 13, 2011 at 11:00 AM, mike shand <mshand at cisco.com>
>> wrote:
>> > Hi Donald,
>> >    I'm trying to understand the rationale for this using GENAPP
>> > rather than, say, a router capability TLV. Is it the case that
>> > support for channels is considered to be an application as far as
>> > routing is concerned? i.e. all you are doing is advertising some
>> > information which is used by some other "application", such as
>> > OAM or BFD, as opposed to some information that is used by
>> > "routing" itself?
>>
>> Right. It's just about whether you can originate or understand
>> certain types of data messages. The RBridge Channel messages are
>> strictly conformant to the specification for a TRILL Data
>> frame. The only clue is that the encapsulated Ethernet frame has a
>> magic multicast destination MAC address, which pushes it to the
>> slow path at the "egress" and then the Ethertype indicates that it
>> needs to be processed as an RBridge Channel message.
>
> I too was confused regarding the use of GENAPP as the use of the
> proposed GENAPP info is not discussed in the draft. I can only
> presume that the intended use is to have IS-IS inform some
> "application" running on the router that a particular Rbridge has
> indicated that it does/does not support a particular Data
> Capability. Is that the intent? If so, could you explain why this is
> needed i.e. what will break if an application did not have this
> information?

I'm not sure why you are looking at the relatively feeble proposed use
of GENAPP in the currently posted draft when my message was about
replacing that with what I consider a better use case. But, in any
case, the typical result of not knowing whether some remote RBridge
supports some particular data capability, which seems to almost always
translates into some variation is data frame formatting, is that if
you send such variant formatting to it, the data is discarded or
improperly distributed.

> GENAPP is intended to support the use of the reliable flooding
> mechanism which the IS-IS update process provides on behalf of an
> application specific information - not simply to indicate that an
> application exists. This is why in Section 5 of the GENAPP draft we
> specify that a separate non-zero instance of IS-IS MUST be used to
> send GENAPP information - which does not seem to align with what you
> are doing here.
>
> Can you please clarify the requirements?

I always thought that an RBridge would want to advertise a variety of
additional information to other RBridges in the campus, information
that has no effect on topology or routing or the like. While it is not
possible to predict all such requirements in advance, perhaps a couple
of examples will help.

- RBridge Channel protocol support. That's what the
  draft-ietf-trill-rbridge-channel change is about. Nothing that
  terrible happens if you send an RBridge channel data message to an
  RBridge that does not support the RBridge channel protocol you are
  using. There is even an error message that can be sent back,
  assuming the destination RBridge supports the general RBridge
  channel facility but not the particular RBridge channel protocol you
  are trying to use. However, in the absence of some mechanism, you
  would have no way of knowing if it did support the general RBridge
  channel facility and, if it didn't, your RBridge channel message
  might get decapsulated and spewed out some of the output ports of
  the destination RBridge. Even if we assume that you did know which
  RBridges supported the general RBridge channel facility, and, as is
  anticipated, there were just a handful of specific RBridge channel
  protocols in use, it would take O(N**2) messages for each RBridge to
  query every other RBridge about which it supported. (It is patterned
  somewhat after the MPLS Generic Channel, only a handful of which
  have been allocated.) This seems like a fine task to be handled by
  flooding a small bit map.

- VLAN/priority mapping info. That's what
  draft-ietf-trill-rbridge-vlan-mapping is about. The desire is to be
  able to cross check the mappings at various border RBridges between
  regions of an RBridge campus for consistency. As stated in the
  Security Considerations section of that draft, such mapping has no
  effect at all on the sequence of RBridges through which a TRILL Data
  frame would pass, i.e., no effect on routing.

The above could be handled in various ways, through a TLV or sub-TLVs
or whatever. But they seem to fit with all the restrictions on
GENAPP. They have no effect on adjacencies or routing or the like. Of
course, these things are always a bit grey. Even if it fit the
restrictions of GENAPP, if something was one bit and could be called a
router capability, it would probably be better to try to find a
reserved bit you could define in an appropriate existing router
capability or the lik. But if it is a number of bytes, but relatively
slow changing and not too big and TRILL specific, I'm sure why GENAPP
is such a bad idea.

draft-ietf-isis-genapp-04, in Section 5, requires use in a separate
instance for GENAPP TLVs "except when the use in the zero instance is
defined in a Standards Track RFC". Draft-ietf-trill-rbridge-channel
being targeted at standards track, I don't quite see what the problem
is. If a particular type of TRILL APPsub-TLV was big enough, or
something, then it would be reasonable to require TRILL GENAPP TLVs
with it be in a separate instance. But I can't see why it would be
worth requiring a separate instance for something small and slow
changing.

Would you prefer that the RBridge Channel protocols supported
information be in a Router Capabilities sub-TLV?

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com

>   Les
>
>>
>> > I guess an important differentiator is to ask whether "routing"
>> > would ever make any different decisions on the basis of this
>> > information. From what I can see, the answer to that question is
>> > NO. Is that a correct assessment?
>>
>> Yes. It has no effect on any routing decisions.
>>
>> Thanks,
>> Donald
>> =============================
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  155 Beaver Street
>>  Milford, MA 01757 USA
>>  d3e3e3 at gmail.com
>>
>> >     Mike
>> >
>> >
>> > On 13/05/2011 13:34, Donald Eastlake wrote:
>> >> Hi,
>> >>
>> >> Currently draft-ietf-trill-rbridge-channel-00 allocates an ISIS
>> GENAPP
>> >> ID for TRILL and specifies an APPsub-TLV with just one bit that
>> >> indicates whether the RBridge supports the Channel Facility or not.
>> I
>> >> think it would be better to specify an APPsub-TLV with a bit per
>> >> RBridge Channel protocol to indicate support of that protocol. See
>> >> draft text fragment pasted at the bottom of this message.
>> >>
>> >> Thanks,
>> >> Donald
>> >>
>> >> PS: This is the third of three suggested tweaks to the RBridge
>> Channel
>> >> draft. I'm posting them separately to make discussion easier.
>> >> =============================
>> >> ? Donald E. Eastlake 3rd ? +1-508-333-2270 (cell)
>> >> ? 155 Beaver Street
>> >> ? Milford, MA 01757 USA
>> >> ? d3e3e3 at gmail.com
>> >>
>> >>
>> >>
>> >> Support for RBridge Channel protocols is indicated by the presence
>> of
>> >> one or more Channel Protocols TRILL APPsub-TLVs in an RBridge's link
>> >> state. ?The Channel Protocols TRILL APPsub-TLV has as its value one
>> or
>> >> more byte aligned bit vectors where a one bit indicates support of a
>> >> particular RBridge Channel protocol. Each byte aligned bit vector is
>> >> formatted as follows:
>> >>
>> >> | 0 ?1 ?2 ?3 ?4 ?5 ?6 ?7| 8 ?9 10 11 12 13 14 15|
>> >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>> >> | ?Bit Vector Length | ? ? Bit Vector Offset ? ?|
>> >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>> >> | ?bits
>> >> +--+--+--...
>> >>
>> >> Note that the bit vector length (BVL) is a seven bit unsigned
>> integer
>> >> field and the bit vector offset (BVO) is a nine bit unsigned integer
>> >> field. ?The bits in each bit vector are numbered in network order,
>> the
>> >> high order bit of the first byte of bits being bit 0 + 8*BVO, the
>> low
>> >> order bit of that byte being 7 + 8*BVO, the high order bit of the
>> >> second byte being 8 + 8*BVO, and so on for BVL bytes. An RBridge
>> >> Channel protocols supported bit vector MUST NOT extend beyond the
>> end
>> >> of the value in the APPsub-TLV in which it occurs. If multiple byte
>> >> aligned bit vectors are present in one such APPsub-TLV, they are
>> >> contiguous, the BVL field for the next starting immediately after
>> the
>> >> last byte of bits for the previous. ?The one or more bit vectors
>> >> present MUST exactly fill the APPsub-TLV value.
>> >>
>> >> If different bit vectors overlap in the protocol number space they
>> >> refer to and have inconsistent bit values for a protcol, support for
>> >> the protocol is assumed if any of these bit vectors has a 1 for that
>> >> protocol.
>> >>
>> >> The absence of any occurrences of this APPsub-TLV in the link state
>> >> for an RBridge implies that that RBridge does not support the
>> RBridge
>> >> Channel feature. Because RBridge Channel protocols 0 and 0xFFF are
>> >> reserved and protocol 1, the RBridge Channel error protocol, MUST be
>> >> implemented as part of the RBridge Channel feature, should bit
>> >> positions for those protocols appear in bit vectors in this
>> >> APPsub-TLV, the bits for protocols 0 and 0xFFF MUST be 0 and the bit
>> >> for protocol 1 MUST be one; however, these bits are ignored on
>> receipt
>> >> and support for protocol 1 is always assumed if there are any
>> >> occurrences of this APPsub-TLV. ?To avoid wasted space, trailing bit
>> >> vector zero bytes SHOULD be eliminated by reducing BVL and any null
>> >> bit vectors (ones with BVL equal to zero) eliminated.


From Internet-Drafts at ietf.org  Thu May 19 11:45:02 2011
From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org)
Date: Thu, 19 May 2011 11:45:02 -0700
Subject: [rbridge] I-D Action:draft-ietf-trill-rbridge-af-03.txt
Message-ID: <20110519184502.16204.56605.idtracker@ietfa.amsl.com>



From zhangmingui at huawei.com  Thu May 19 19:02:47 2011
From: zhangmingui at huawei.com (Zhangmingui, (Mingui))
Date: Fri, 20 May 2011 02:02:47 +0000
Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-mib-02.txt
In-Reply-To: <BANLkTim4agDcQE0RO7kShBg0+BR2ViZF2g@mail.gmail.com>
References: <4DD16CCA.90100@acm.org>
	<4552F0907735844E9204A62BBDD325E737E350@SZXEML503-MBX.china.huawei.com>
	<BANLkTim4agDcQE0RO7kShBg0+BR2ViZF2g@mail.gmail.com>
Message-ID: <4552F0907735844E9204A62BBDD325E737E4C3@SZXEML503-MBX.china.huawei.com>

> > On page 3, it says, "like routers, they terminate the bridge spanning tree
> protocol."
> > Actually, STP and routing protocol run in parallel in the same network.
> 
> I don't actually understand your comment. Maybe it should say "like
> routers and other end stations, ...". The point is that, although an
> RBridge port can optionally participate in spanning tree as a leaf
> node, it never interacts with other ports of the same RBridge to form
> a spanning tree branch through the RBridge. So it terminates the
> spanning tree protocol and does not propagate it through the RBridge.
> On the other hand, RBridges do propagate IS-IS and form least cost
> routes through RBridges...

I thought "terminate" meant "replace" or the like. This sentence makes me thinking of "TRILL is to replace Spanning Tree Protocol". Maybe, we should say "they terminates bridge spanning tree" rather than "they terminates bridge spanning tree protocol".

> > On page 4, it says "RBridges provide optimal pair-wise forwarding without
> configuration using IS-IS routing and encapsulation of traffic."
> > (1) Personally, the word "optimal" is not accurate, while "shortest" may be
> more proper.
> 
> The word "optimal" assumes there is some metric. I think people
> generally understand it is least cost. "Shortest" would only be
> accurate if it was based on number of hops. Since it is based on link
> cost, if one was to replace "optimal", I think the best replacement
> would be "least cost".

Agree.

> > (3) I know TRILL uses routing (control layer) of ISIS, but I do not know that
> TRILL use the encapsulation (data layer) of IS-IS?
> 
> Is there an data layer of IS-IS? IS-IS just discovers the topology and
> provides least cost routes. I don't think IS-IS says anything about
> the data frame format which could be CLNP or IP or TRILL or
> whatever...

I think that TRILL defines its own way of data encapsulation. Is that right?

--
Mingui

From nordmark at acm.org  Wed May 25 10:08:42 2011
From: nordmark at acm.org (Erik Nordmark)
Date: Wed, 25 May 2011 10:08:42 -0700
Subject: [rbridge] Reminder: WG last call on
	draft-ietf-trill-rbridge-mib-02.txt
Message-ID: <4DDD379A.8040305@acm.org>



-------- Original Message --------
Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-mib-02.txt
Date: Mon, 16 May 2011 11:28:26 -0700
From: Erik Nordmark <nordmark at acm.org>
To: rbridge at postel.org


This starts a two week last call on our MIB documents, which ends on May
31st.

Please send comments to the list.

If you've reviewed it and think it is good, also send a message to the list.

     Erik

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge


From trillmails at gmail.com  Wed May 25 23:33:43 2011
From: trillmails at gmail.com (Selvaraj Rajan)
Date: Wed, 25 May 2011 23:33:43 -0700
Subject: [rbridge] IPMC
Message-ID: <BANLkTik-BbGGHss1TKNoPijR+5v-BEpgmw@mail.gmail.com>

Hi,
Nowadays, a switch forwards IPv4 orIPv6 multicast data packets not just
based on the corresponding derived multicast MAC address, but based on IP
address. Because, this is due to the well known issue that more than one IP
multicast addresses maps to the same l2 MAC address.

So, how does a TRILL enabled switch allows to accomplish IP based multicast
forwarding ?
The usual forwarding logic for switches would be that they should do IP
based switching if the L2 Destination MAC address is 01-00-5e-xx-xx-xx
otherwise L2 multicast switching. But I don't see anything mentioned in this
regard in the draft 16.

Probably this would have been already discussed or eliminated.
whatever it would have been, I would appreciate if you can share me the
details.

Thank you!
Selvaraj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20110525/3d84c390/attachment.html

From carlsonj at workingcode.com  Thu May 26 04:45:36 2011
From: carlsonj at workingcode.com (James Carlson)
Date: Thu, 26 May 2011 07:45:36 -0400
Subject: [rbridge] IPMC
In-Reply-To: <BANLkTik-BbGGHss1TKNoPijR+5v-BEpgmw@mail.gmail.com>
References: <BANLkTik-BbGGHss1TKNoPijR+5v-BEpgmw@mail.gmail.com>
Message-ID: <4DDE3D60.3020706@workingcode.com>

Selvaraj Rajan wrote:
> So, how does a TRILL enabled switch allows to accomplish IP based
> multicast forwarding ?
> The usual forwarding logic for switches would be that they should do IP
> based switching if the L2 Destination MAC address is 01-00-5e-xx-xx-xx
> otherwise L2 multicast switching. But I don't see anything mentioned in
> this regard in the draft 16.

A simple way to do this would be to do what an ordinary bridge would do.
 That is, if you're unaware of IP-based multicast forwarding, then just
forward on the L2 address as always.  If you're aware of it, then
inspect the L3 address contained within those TRILL frames, and prune as
necessary (based on the IGMP/MLD-learned groups) when forwarding.

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>

From d3e3e3 at gmail.com  Thu May 26 06:05:12 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 26 May 2011 09:05:12 -0400
Subject: [rbridge] IPMC
In-Reply-To: <4DDE3D60.3020706@workingcode.com>
References: <BANLkTik-BbGGHss1TKNoPijR+5v-BEpgmw@mail.gmail.com>
	<4DDE3D60.3020706@workingcode.com>
Message-ID: <BANLkTi=MmCZKeCLN5BLx2YBE3K7_SCVDsw@mail.gmail.com>

See below.

On Thu, May 26, 2011 at 7:45 AM, James Carlson <carlsonj at workingcode.com> wrote:
> Selvaraj Rajan wrote:
>> So, how does a TRILL enabled switch allows to accomplish IP based
>> multicast forwarding ?

All multi-destinaton frame forwarding in TRILL uses the same
distribution tree or trees. It does not matter if the frame is
broadcast, multicast derived from IP (see RFC 5342, Sections 2.1.1 and
2.3.1 ), multicast not derived from IP, or a unicast frame whose
destination location is unknown.

>> The usual forwarding logic for switches would be that they should do IP
>> based switching if the L2 Destination MAC address is 01-00-5e-xx-xx-xx

Actually 01-00-5e-00-00-00 through 01-00-5e-7F-FF-FF and
33-33-00-00-00-00 through 33-33-FF-FF-FF-FF as per RFC 5342 reference
above.

>> otherwise L2 multicast switching. But I don't see anything mentioned in
>> this regard in the draft 16.

If does not make any difference to basic TRILL forwarding that a
multi-destination frame is IP derived. (As Jim Carlson comments below,
it does make a difference to pruning that tree.) The frame is
forwarded on the distribution tree and it is up to each RBridge to
determine if it should decapsulate a copy of the original native frame
(which it generally does if it is Appointed Forwarder on any port for
the VLAN of the frame) and if it should output a copy of that original
native frame on any particular port (which it generally does if there
is a listener out that port for the multicast group or a multicast
router out that port).

> A simple way to do this would be to do what an ordinary bridge would do.
> ?That is, if you're unaware of IP-based multicast forwarding, then just
> forward on the L2 address as always. ?If you're aware of it, then
> inspect the L3 address contained within those TRILL frames, and prune as
> necessary (based on the IGMP/MLD-learned groups) when forwarding.

I'm not sure, as a practical matter, how much better pruning on IP
address is than just pruning on derived MAC but I believe some
implementations do perform deeper packet inspection and prune on IP
address. They communicate the information about multicast listeners by
IP multicast address using sub-TLVs in the Group Address TLV. The
Group Address TLV is specified in draft-ietf-isis-trill-05.txt, which
is an approved standard. That draft also specifies the Group MAC
Address sub-TLV. The Group IPv4 Address sub-TLV and Group IPv6 Address
sub-TLV are currently specified in draft-drao-isis-otv-00.txt.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com

> --
> James Carlson ? ? ? ? 42.703N 71.076W ? ? ? ? <carlsonj at workingcode.com>


From trillmails at gmail.com  Thu May 26 09:43:39 2011
From: trillmails at gmail.com (Selvaraj Rajan)
Date: Thu, 26 May 2011 09:43:39 -0700
Subject: [rbridge] IPMC
In-Reply-To: <BANLkTi=MmCZKeCLN5BLx2YBE3K7_SCVDsw@mail.gmail.com>
References: <BANLkTik-BbGGHss1TKNoPijR+5v-BEpgmw@mail.gmail.com>
	<4DDE3D60.3020706@workingcode.com>
	<BANLkTi=MmCZKeCLN5BLx2YBE3K7_SCVDsw@mail.gmail.com>
Message-ID: <BANLkTimDHBhA9pofrw+rw8LKOHbTza8Q3g@mail.gmail.com>

Thank you all!
I will come back to discussion if I still see any issue.

Thanks!

On Thu, May 26, 2011 at 6:05 AM, Donald Eastlake <d3e3e3 at gmail.com> wrote:

> See below.
>
> On Thu, May 26, 2011 at 7:45 AM, James Carlson <carlsonj at workingcode.com>
> wrote:
> > Selvaraj Rajan wrote:
> >> So, how does a TRILL enabled switch allows to accomplish IP based
> >> multicast forwarding ?
>
> All multi-destinaton frame forwarding in TRILL uses the same
> distribution tree or trees. It does not matter if the frame is
> broadcast, multicast derived from IP (see RFC 5342, Sections 2.1.1 and
> 2.3.1 ), multicast not derived from IP, or a unicast frame whose
> destination location is unknown.
>
> >> The usual forwarding logic for switches would be that they should do IP
> >> based switching if the L2 Destination MAC address is 01-00-5e-xx-xx-xx
>
> Actually 01-00-5e-00-00-00 through 01-00-5e-7F-FF-FF and
> 33-33-00-00-00-00 through 33-33-FF-FF-FF-FF as per RFC 5342 reference
> above.
>
> >> otherwise L2 multicast switching. But I don't see anything mentioned in
> >> this regard in the draft 16.
>
> If does not make any difference to basic TRILL forwarding that a
> multi-destination frame is IP derived. (As Jim Carlson comments below,
> it does make a difference to pruning that tree.) The frame is
> forwarded on the distribution tree and it is up to each RBridge to
> determine if it should decapsulate a copy of the original native frame
> (which it generally does if it is Appointed Forwarder on any port for
> the VLAN of the frame) and if it should output a copy of that original
> native frame on any particular port (which it generally does if there
> is a listener out that port for the multicast group or a multicast
> router out that port).
>
> > A simple way to do this would be to do what an ordinary bridge would do.
> >  That is, if you're unaware of IP-based multicast forwarding, then just
> > forward on the L2 address as always.  If you're aware of it, then
> > inspect the L3 address contained within those TRILL frames, and prune as
> > necessary (based on the IGMP/MLD-learned groups) when forwarding.
>
> I'm not sure, as a practical matter, how much better pruning on IP
> address is than just pruning on derived MAC but I believe some
> implementations do perform deeper packet inspection and prune on IP
> address. They communicate the information about multicast listeners by
> IP multicast address using sub-TLVs in the Group Address TLV. The
> Group Address TLV is specified in draft-ietf-isis-trill-05.txt, which
> is an approved standard. That draft also specifies the Group MAC
> Address sub-TLV. The Group IPv4 Address sub-TLV and Group IPv6 Address
> sub-TLV are currently specified in draft-drao-isis-otv-00.txt.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  d3e3e3 at gmail.com
>
> > --
> > James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20110526/e48257f3/attachment.html

From anoop at alumni.duke.edu  Thu May 26 10:44:00 2011
From: anoop at alumni.duke.edu (Anoop Ghanwani)
Date: Thu, 26 May 2011 10:44:00 -0700
Subject: [rbridge] Reminder: WG last call on
	draft-ietf-trill-rbridge-mib-02.txt
In-Reply-To: <4DDD379A.8040305@acm.org>
References: <4DDD379A.8040305@acm.org>
Message-ID: <BANLkTikJ=czONEgkifSODNpywFHoAKfKSQ@mail.gmail.com>

The document looks good to me.

On Wed, May 25, 2011 at 10:08 AM, Erik Nordmark <nordmark at acm.org> wrote:

>
>
> -------- Original Message --------
> Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-mib-02.txt
> Date: Mon, 16 May 2011 11:28:26 -0700
> From: Erik Nordmark <nordmark at acm.org>
> To: rbridge at postel.org
>
>
> This starts a two week last call on our MIB documents, which ends on May
> 31st.
>
> Please send comments to the list.
>
> If you've reviewed it and think it is good, also send a message to the
> list.
>
>     Erik
>
> _______________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20110526/6667951f/attachment.html

From anil at charter.net  Fri May 27 06:06:50 2011
From: anil at charter.net (Anil Rijhsinghani)
Date: Fri, 27 May 2011 09:06:50 -0400
Subject: [rbridge] Reminder: WG last call on
	draft-ietf-trill-rbridge-mib-02.txt
In-Reply-To: <4DDD379A.8040305@acm.org>
References: <4DDD379A.8040305@acm.org>
Message-ID: <1A408B23-A602-4646-85A8-DD45071D8E4B@charter.net>

I've received the following question from two WG members (Anoop Ghanwani and Vishwas Manral) so I'll bring it up on the list:

> With respect to IS-IS, if a system is both an RBridge and a 
> router running IS-IS, would I have 2 separate MIB instances?

In early drafts of the IS-IS MIB (RFC4444) there was an "index" object which served to distinguish between multiple instances of the IS-IS MIB, given that it was possible people could use IS-IS for more than one purpose in a bridge-router. In later drafts they removed this index, recognizing that it made the MIB more complex and that SNMPv3 contexts already provide the ability to do such instancing (SNMPv1 has communities).

There are other reasons to use this sort of instancing in MIBs. Virtual routers which implement more than one instance of a given routing protocol will also require such a MIB instancing mechanism. Aside from the SNMP protocol description where contexts are described, this is referenced in draft-kkoushik-snmp-context-map-mib-02. I'll add some text to the MIB to clarify this issue, as I'm not sure if that draft will become an informational RFC.

If there are comments, please bring them up now.

Regards,
Anil


On May 25, 2011, at 1:08 PM, Erik Nordmark wrote:

> 
> 
> -------- Original Message --------
> Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-mib-02.txt
> Date: Mon, 16 May 2011 11:28:26 -0700
> From: Erik Nordmark <nordmark at acm.org>
> To: rbridge at postel.org
> 
> 
> This starts a two week last call on our MIB documents, which ends on May
> 31st.
> 
> Please send comments to the list.
> 
> If you've reviewed it and think it is good, also send a message to the list.
> 
>     Erik
> 
> _______________________________________________
> 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  Fri May 27 06:14:06 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 27 May 2011 09:14:06 -0400
Subject: [rbridge] Fwd: [Pppext] Last Call:
 <draft-ietf-pppext-trill-protocol-06.txt> (PPP TRILL Protocol Control
 Protocol) to Proposed Standard
In-Reply-To: <20110525161357.5909.40860.idtracker@ietfa.amsl.com>
References: <20110525161357.5909.40860.idtracker@ietfa.amsl.com>
Message-ID: <BANLkTi=NKLcakoBGdCTyAd4v1-p-7_GZLA@mail.gmail.com>

---------- Forwarded message ----------
From: The IESG <iesg-secretary at ietf.org>
Date: Wed, May 25, 2011 at 12:13 PM
Subject: [Pppext] Last Call: <draft-ietf-pppext-trill-protocol-06.txt>
(PPP TRILL	Protocol Control Protocol) to Proposed Standard
To: IETF-Announce <ietf-announce at ietf.org>
Cc: pppext at ietf.org

The IESG has received a request from the Point-to-Point Protocol
Extensions WG (pppext) to consider the following document:
- 'PPP TRILL Protocol Control Protocol'
?<draft-ietf-pppext-trill-protocol-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf at ietf.org mailing lists by 2011-06-08. Exceptionally, comments may be
sent to iesg at ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


? The Point-to-Point Protocol (PPP) 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 PPP support for
? Transparent Interconnection of Lots of Links (TRILL) Protocol,
? allowing direct communication between Routing Bridges (RBridges) via
? PPP links.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/


No IPR declarations have been submitted directly on this I-D.

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


From d3e3e3 at gmail.com  Fri May 27 06:24:21 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 27 May 2011 09:24:21 -0400
Subject: [rbridge] Additional draft-ietf-trill-rbridge-af-03 comments
Message-ID: <BANLkTi=SXbA39fG_VA6NUW=-vQKs7ateWw@mail.gmail.com>

I reviewed the draft and noticed that:
- It doesn't explicitly say what to do if an appointment specifies
illegal VLAN IDs 0x000 or 0xFFF and doesn't suggest what to send if
the DRB wants to revoke all appointments.
- It doesn't mention the detection of VLAN mapping within a link. When
this is detected, for loop safety, the DRB needs to assure that there
is only one RBridge that is appointed forwarder for the VLANs involved
in the mapping.

Also, someone has suggested to me that, to avoid confusion, perhaps
some brief version of the definition of "link" be included from
paragraph 3 of Section 1.3 in the TRILL base protocol where it says:
   In this document, the term "link", unless otherwise qualified, means
   "bridged LAN", that is to say, the combination of one or more [802.3]
   links with zero or more bridges, hubs, repeaters, or the like.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com


From d3e3e3 at gmail.com  Fri May 27 06:53:53 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 27 May 2011 09:53:53 -0400
Subject: [rbridge] Reminder: WG last call on
	draft-ietf-trill-rbridge-mib-02.txt
In-Reply-To: <4DDD379A.8040305@acm.org>
References: <4DDD379A.8040305@acm.org>
Message-ID: <BANLkTimjL-2z1QR6JXeDkRuxrR0B7EdmfQ@mail.gmail.com>

I have reviewed this document and it looks good to me.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com

On Wed, May 25, 2011 at 1:08 PM, Erik Nordmark <nordmark at acm.org> wrote:
>
> -------- Original Message --------
> Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-mib-02.txt
> Date: Mon, 16 May 2011 11:28:26 -0700
> From: Erik Nordmark <nordmark at acm.org>
> To: rbridge at postel.org
>
> This starts a two week last call on our MIB documents, which ends on May
> 31st.
>
> Please send comments to the list.
>
> If you've reviewed it and think it is good, also send a message to the list.
>
> ? ? Erik


From mjkantowski at yahoo.com  Sat May 28 20:05:35 2011
From: mjkantowski at yahoo.com (Michael Kantowski)
Date: Sat, 28 May 2011 20:05:35 -0700 (PDT)
Subject: [rbridge] (no subject)
Message-ID: <1306638335.49844.YahooMailMobile@web31801.mail.mud.yahoo.com>

http://magicmaria.com/catalogo/images/mywork.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20110528/15165f0d/attachment.html

From zhai.hongjun at zte.com.cn  Fri May 27 21:30:44 2011
From: zhai.hongjun at zte.com.cn (zhai.hongjun@zte.com.cn)
Date: Sat, 28 May 2011 12:30:44 +0800
Subject: =?GB2312?B?tPC4tDogUmU6IFtyYnJpZGdlXSBSZW1pbmRlcjogV0cgbGFzdCBjYWxsIG9u?=
	=?GB2312?B?CWRyYWZ0LWlldGYtdHJpbGwtcmJyaWRnZS1taWItMDIudHh0?=
In-Reply-To: <BANLkTimjL-2z1QR6JXeDkRuxrR0B7EdmfQ@mail.gmail.com>
Message-ID: <201105300043.p4U0hcAO018423@mse01.zte.com.cn>

I have reviewed this document, I support it.

Thanks
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 
 Zhai Hongjun
 
 Tel: +86-25-52877345
 Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""





Donald Eastlake <d3e3e3 at gmail.com> 
发件人:  rbridge-bounces at postel.org
2011-05-27 21:53

收件人
Erik Nordmark <nordmark at acm.org>
抄送
rbridge at postel.org
主题
Re: [rbridge] Reminder: WG last call on 
draft-ietf-trill-rbridge-mib-02.txt






I have reviewed this document and it looks good to me.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com

On Wed, May 25, 2011 at 1:08 PM, Erik Nordmark <nordmark at acm.org> wrote:
>
> -------- Original Message --------
> Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-mib-02.txt
> Date: Mon, 16 May 2011 11:28:26 -0700
> From: Erik Nordmark <nordmark at acm.org>
> To: rbridge at postel.org
>
> This starts a two week last call on our MIB documents, which ends on May
> 31st.
>
> Please send comments to the list.
>
> If you've reviewed it and think it is good, also send a message to the 
list.
>
>     Erik

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20110528/263c1b13/attachment.html

From d3e3e3 at gmail.com  Mon May 30 11:47:25 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 30 May 2011 14:47:25 -0400
Subject: [rbridge] RBridge Channel: A change re Hop Count
Message-ID: <BANLkTimd0i9iwLTFFh2nTxeqvPJUtahdOQ@mail.gmail.com>

Reviewing draft-ietf-trill-rbridge-channel-00, I notice that it says
that RBridge Channel messages MUST be sent with the maximum Hop Count
of 0x3F. That's useful for checking the a message has only gone one
hop or the like. However, for channel messages to be useful for some
applications like traceroute, they need to be sent with other Hop
Counts values. So I think that provision needs an escape and needs to
say they MUST be sent with a maximum Hop Count unless a particular
channel protocol specifies otherwise.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com


From vishwas.ietf at gmail.com  Mon May 30 12:14:54 2011
From: vishwas.ietf at gmail.com (Vishwas Manral)
Date: Mon, 30 May 2011 12:14:54 -0700
Subject: [rbridge] RBridge Channel: A change re Hop Count
In-Reply-To: <BANLkTimd0i9iwLTFFh2nTxeqvPJUtahdOQ@mail.gmail.com>
References: <BANLkTimd0i9iwLTFFh2nTxeqvPJUtahdOQ@mail.gmail.com>
Message-ID: <BANLkTim_9gFZn_Uo7jS5CGqsAXEqAZ0J5w@mail.gmail.com>

Hi Donald,

You are right.

Thanks,
Vishwas
On Mon, May 30, 2011 at 11:47 AM, Donald Eastlake <d3e3e3 at gmail.com> wrote:

> Reviewing draft-ietf-trill-rbridge-channel-00, I notice that it says
> that RBridge Channel messages MUST be sent with the maximum Hop Count
> of 0x3F. That's useful for checking the a message has only gone one
> hop or the like. However, for channel messages to be useful for some
> applications like traceroute, they need to be sent with other Hop
> Counts values. So I think that provision needs an escape and needs to
> say they MUST be sent with a maximum Hop Count unless a particular
> channel protocol specifies otherwise.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street
>  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/20110530/d8154475/attachment.html

From touch at isi.edu  Mon May 30 14:27:25 2011
From: touch at isi.edu (Joe Touch)
Date: Mon, 30 May 2011 14:27:25 -0700
Subject: [rbridge] RBridge Channel: A change re Hop Count
In-Reply-To: <BANLkTim_9gFZn_Uo7jS5CGqsAXEqAZ0J5w@mail.gmail.com>
References: <BANLkTimd0i9iwLTFFh2nTxeqvPJUtahdOQ@mail.gmail.com>
	<BANLkTim_9gFZn_Uo7jS5CGqsAXEqAZ0J5w@mail.gmail.com>
Message-ID: <26E9F3B8-9F80-49CF-87E0-FB216B23D095@isi.edu>

Any number other than max means MUST is irrelevant since you can't know what app/service sent the packet. I think that's OK, but then IMO just omit the MUST. 

Joe

On May 30, 2011, at 12:14 PM, Vishwas Manral <vishwas.ietf at gmail.com> wrote:

> Hi Donald,
>  
> You are right.
>  
> Thanks,
> Vishwas
> On Mon, May 30, 2011 at 11:47 AM, Donald Eastlake <d3e3e3 at gmail.com> wrote:
> Reviewing draft-ietf-trill-rbridge-channel-00, I notice that it says
> that RBridge Channel messages MUST be sent with the maximum Hop Count
> of 0x3F. That's useful for checking the a message has only gone one
> hop or the like. However, for channel messages to be useful for some
> applications like traceroute, they need to be sent with other Hop
> Counts values. So I think that provision needs an escape and needs to
> say they MUST be sent with a maximum Hop Count unless a particular
> channel protocol specifies otherwise.
> 
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  d3e3e3 at gmail.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20110530/44ee9148/attachment.html

From d3e3e3 at gmail.com  Mon May 30 15:34:11 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 30 May 2011 18:34:11 -0400
Subject: [rbridge] RBridge Channel: A change re Hop Count
In-Reply-To: <26E9F3B8-9F80-49CF-87E0-FB216B23D095@isi.edu>
References: <BANLkTimd0i9iwLTFFh2nTxeqvPJUtahdOQ@mail.gmail.com>
	<BANLkTim_9gFZn_Uo7jS5CGqsAXEqAZ0J5w@mail.gmail.com>
	<26E9F3B8-9F80-49CF-87E0-FB216B23D095@isi.edu>
Message-ID: <BANLkTikzh8qAYov51CEkE7CHNkXFdz9kdw@mail.gmail.com>

Maybe the wording should be something like "... by default the Hop
Count is set to 0x3F but channel protocols MAY specify that it be set
to other values..."

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com



On Mon, May 30, 2011 at 5:27 PM, Joe Touch <touch at isi.edu> wrote:
> Any number other than max means MUST is irrelevant since you can't know what
> app/service sent the packet. I think that's OK, but then IMO just omit the
> MUST.
> Joe
>
> On May 30, 2011, at 12:14 PM, Vishwas Manral <vishwas.ietf at gmail.com> wrote:
>
> Hi Donald,
>
> You are right.
>
> Thanks,
> Vishwas
> On Mon, May 30, 2011 at 11:47 AM, Donald Eastlake <d3e3e3 at gmail.com> wrote:
>>
>> Reviewing draft-ietf-trill-rbridge-channel-00, I notice that it says
>> that RBridge Channel messages MUST be sent with the maximum Hop Count
>> of 0x3F. That's useful for checking the a message has only gone one
>> hop or the like. However, for channel messages to be useful for some
>> applications like traceroute, they need to be sent with other Hop
>> Counts values. So I think that provision needs an escape and needs to
>> say they MUST be sent with a maximum Hop Count unless a particular
>> channel protocol specifies otherwise.
>>
>> Thanks,
>> Donald
>> =============================
>> ?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
>> ?155 Beaver Street
>> ?Milford, MA 01757 USA
>> ?d3e3e3 at gmail.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 touch at isi.edu  Mon May 30 16:05:17 2011
From: touch at isi.edu (Joe Touch)
Date: Mon, 30 May 2011 16:05:17 -0700
Subject: [rbridge] RBridge Channel: A change re Hop Count
In-Reply-To: <BANLkTikzh8qAYov51CEkE7CHNkXFdz9kdw@mail.gmail.com>
References: <BANLkTimd0i9iwLTFFh2nTxeqvPJUtahdOQ@mail.gmail.com>
	<BANLkTim_9gFZn_Uo7jS5CGqsAXEqAZ0J5w@mail.gmail.com>
	<26E9F3B8-9F80-49CF-87E0-FB216B23D095@isi.edu>
	<BANLkTikzh8qAYov51CEkE7CHNkXFdz9kdw@mail.gmail.com>
Message-ID: <4DE422AD.3060008@isi.edu>

That sounds better; it's useful to have a default.

Joe

On 5/30/2011 3:34 PM, Donald Eastlake wrote:
> Maybe the wording should be something like "... by default the Hop
> Count is set to 0x3F but channel protocols MAY specify that it be set
> to other values..."
>
> Thanks,
> Donald
> =============================
>   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>   155 Beaver Street
>   Milford, MA 01757 USA
>   d3e3e3 at gmail.com
>
>
>
> On Mon, May 30, 2011 at 5:27 PM, Joe Touch<touch at isi.edu>  wrote:
>> Any number other than max means MUST is irrelevant since you can't know what
>> app/service sent the packet. I think that's OK, but then IMO just omit the
>> MUST.
>> Joe
>>
>> On May 30, 2011, at 12:14 PM, Vishwas Manral<vishwas.ietf at gmail.com>  wrote:
>>
>> Hi Donald,
>>
>> You are right.
>>
>> Thanks,
>> Vishwas
>> On Mon, May 30, 2011 at 11:47 AM, Donald Eastlake<d3e3e3 at gmail.com>  wrote:
>>>
>>> Reviewing draft-ietf-trill-rbridge-channel-00, I notice that it says
>>> that RBridge Channel messages MUST be sent with the maximum Hop Count
>>> of 0x3F. That's useful for checking the a message has only gone one
>>> hop or the like. However, for channel messages to be useful for some
>>> applications like traceroute, they need to be sent with other Hop
>>> Counts values. So I think that provision needs an escape and needs to
>>> say they MUST be sent with a maximum Hop Count unless a particular
>>> channel protocol specifies otherwise.
>>>
>>> Thanks,
>>> Donald
>>> =============================
>>>   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>>   155 Beaver Street
>>>   Milford, MA 01757 USA
>>>   d3e3e3 at gmail.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  Tue May 31 08:10:18 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 31 May 2011 11:10:18 -0400
Subject: [rbridge] [Pppext] Last Call:
 <draft-ietf-pppext-trill-protocol-06.txt> (PPP TRILL Protocol Control
 Protocol) to Proposed Standard
In-Reply-To: <BANLkTi=NKLcakoBGdCTyAd4v1-p-7_GZLA@mail.gmail.com>
References: <20110525161357.5909.40860.idtracker@ietfa.amsl.com>
	<BANLkTi=NKLcakoBGdCTyAd4v1-p-7_GZLA@mail.gmail.com>
Message-ID: <BANLkTi=4ndxOtgSPk1W+vSvD1wDwFgWJww@mail.gmail.com>

Note: There has been a Routing Area review of this draft which is
available here:
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg01533.html

Thanks,
Donald

On Fri, May 27, 2011 at 9:14 AM, Donald Eastlake <d3e3e3 at gmail.com> wrote:
> ---------- Forwarded message ----------
> From: The IESG <iesg-secretary at ietf.org>
> Date: Wed, May 25, 2011 at 12:13 PM
> Subject: [Pppext] Last Call: <draft-ietf-pppext-trill-protocol-06.txt>
> (PPP TRILL ? ? ?Protocol Control Protocol) to Proposed Standard
> To: IETF-Announce <ietf-announce at ietf.org>
> Cc: pppext at ietf.org
>
> The IESG has received a request from the Point-to-Point Protocol
> Extensions WG (pppext) to consider the following document:
> - 'PPP TRILL Protocol Control Protocol'
> ?<draft-ietf-pppext-trill-protocol-06.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf at ietf.org mailing lists by 2011-06-08. Exceptionally, comments may be
> sent to iesg at ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
> ? The Point-to-Point Protocol (PPP) 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 PPP support for
> ? Transparent Interconnection of Lots of Links (TRILL) Protocol,
> ? allowing direct communication between Routing Bridges (RBridges) via
> ? PPP links.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
> _______________________________________________
> Pppext mailing list
> Pppext at ietf.org
> https://www.ietf.org/mailman/listinfo/pppext
>


From ddutt at cisco.com  Tue May 31 12:17:26 2011
From: ddutt at cisco.com (Dinesh Dutt)
Date: Tue, 31 May 2011 12:17:26 -0700
Subject: [rbridge] RBridge Channel: A change re Hop Count
In-Reply-To: <4DE422AD.3060008@isi.edu>
References: <BANLkTimd0i9iwLTFFh2nTxeqvPJUtahdOQ@mail.gmail.com>	<BANLkTim_9gFZn_Uo7jS5CGqsAXEqAZ0J5w@mail.gmail.com>	<26E9F3B8-9F80-49CF-87E0-FB216B23D095@isi.edu>	<BANLkTikzh8qAYov51CEkE7CHNkXFdz9kdw@mail.gmail.com>
	<4DE422AD.3060008@isi.edu>
Message-ID: <4DE53EC6.6010701@cisco.com>

Agreed,

Dinesh
On 05/30/2011 04:05 PM, Joe Touch wrote:
> That sounds better; it's useful to have a default.
>
> Joe
>
> On 5/30/2011 3:34 PM, Donald Eastlake wrote:
>> Maybe the wording should be something like "... by default the Hop
>> Count is set to 0x3F but channel protocols MAY specify that it be set
>> to other values..."
>>
>> Thanks,
>> Donald
>> =============================
>>    Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>    155 Beaver Street
>>    Milford, MA 01757 USA
>>    d3e3e3 at gmail.com
>>
>>
>>
>> On Mon, May 30, 2011 at 5:27 PM, Joe Touch<touch at isi.edu>   wrote:
>>> Any number other than max means MUST is irrelevant since you can't know what
>>> app/service sent the packet. I think that's OK, but then IMO just omit the
>>> MUST.
>>> Joe
>>>
>>> On May 30, 2011, at 12:14 PM, Vishwas Manral<vishwas.ietf at gmail.com>   wrote:
>>>
>>> Hi Donald,
>>>
>>> You are right.
>>>
>>> Thanks,
>>> Vishwas
>>> On Mon, May 30, 2011 at 11:47 AM, Donald Eastlake<d3e3e3 at gmail.com>   wrote:
>>>> Reviewing draft-ietf-trill-rbridge-channel-00, I notice that it says
>>>> that RBridge Channel messages MUST be sent with the maximum Hop Count
>>>> of 0x3F. That's useful for checking the a message has only gone one
>>>> hop or the like. However, for channel messages to be useful for some
>>>> applications like traceroute, they need to be sent with other Hop
>>>> Counts values. So I think that provision needs an escape and needs to
>>>> say they MUST be sent with a maximum Hop Count unless a particular
>>>> channel protocol specifies otherwise.
>>>>
>>>> Thanks,
>>>> Donald
>>>> =============================
>>>>    Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>>>    155 Beaver Street
>>>>    Milford, MA 01757 USA
>>>>    d3e3e3 at gmail.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 zhangmingui at huawei.com  Tue May 31 23:41:40 2011
From: zhangmingui at huawei.com (Zhangmingui, (Mingui))
Date: Wed, 01 Jun 2011 06:41:40 +0000
Subject: [rbridge] FW: New Version Notification for
 draft-zhang-trill-vlan-extension-00.txt
Message-ID: <4552F0907735844E9204A62BBDD325E7380573@SZXEML503-MBX.china.huawei.com>

A new version of I-D, draft-zhang-trill-vlan-extension-00.txt has been
successfully submitted by Mingui Zhang and posted to the IETF repository.

Filename:	 draft-zhang-trill-vlan-extension
Revision:	 00
Title:		 To Address the Space Limitation of Inner VLAN
Creation date:	 2011-05-31
WG ID:		 Individual Submission
Number of pages: 8

Abstract:
   TRILL is originally designed for customer networks. When it is used
   as a provider network to interconnect multiple separate users, the
   space of current Inner VLAN becomes insufficient. As an easy way, we
   can introduce a new VLAN ID field to TRILL header. The new VLAN ID
   can be use in conjunction with the native Inner VLAN, which is
   usually known as stacked VLANs(or Q-in-Q). The stacked VLANs
   mechanism is analyzed in this document. In addition, a novel MAC
   address rewriting mechanism is also brought forward to break the
   space limitation of the Inner VLAN. The MAC addresses of the native
   frame are not used for forwarding process in transit RBridges. When
   the packet enters the TRILL network, the ingress RBridge (Appointed
   Forwarder) uses a Virtual MAC (VMAC) address to replace the real MAC
   and embedded the native VLAN ID into this virtual MAC address. When a
   packet egresses from the TRILL network, the egress RBridge will use
   the real MAC address to replace the virtual MAC address and deliver
   it to the destination on the local link.



The IETF Secretariat