Subject: [rbridge] Consensus Check: Decapsulation check optional

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Fri, 4 Apr 2008 17:27:40 -0400

This is a check via the mailing list to confirm or refute an apparent
consensus at the Philadelphia meeting:

******* Keep the reporting by RBridges in the link state database of
root bridge IDs observed mandatory, as in the current (-07) draft, but
make the "decapsulation" check optional.

If no particular controversy arises over this in the next two weeks,
We will declare it to be the working group consensus.

Thanks,
Donald & Erik

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Fri, 4 Apr 2008 17:39:09 -0400

******* The Outer VLAN ID will be duplicated in a TLV inside TRILL IS-IS
Hellos to test for VLAN mapping.

Thanks,
Donald & Erik

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Fri, 4 Apr 2008 17:44:01 -0400

******* Change the base protocol draft so that where the pseudocode and
text conflict, the text is normative.

If no particular controversy arises over this in the next two weeks, We
will declare it to be the working group consensus.

Thanks,
Donald & Erik

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 7 Apr 2008 16:41:07 -0400

******* The TRILL Base Protocol draft should only mention and use IEEE
802.1 C-tags. It should not mention or use S-tags, except possibly to
distinguish them from C-tags, state that they are not used, or the like.

Thanks,
Donald & Erik

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 7 Apr 2008 16:36:54 -0400

******* Leave the provisions in the base protocol (version 07) draft for
critical option summary bits if the options area has non-zero length and
leave further details about options to another document or documents.

Thanks,
Donald & Erik

---

From: Dinesh G Dutt <[email-masked]>
Date: Mon, 07 Apr 2008 14:18:12 -0700

Why did we decide this ?

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 7 Apr 2008 17:35:41 -0400

In short, read the minutes:
http://www.ietf.org/proceedings/08mar/minutes/trill.txt

At slightly greater length: I brought up the change that Q-tag had been
replaced by C-tag in the protocol draft, which I thought was purely
editorial. This lead to a bunch of discussion which Erik and I judge to
have produced this consensus at the meeting.

Thanks,
Donald

-----Original Message-----
From: Dinesh G Dutt [mailto:[email-masked]] 
Sent: Monday, April 07, 2008 5:18 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: C-Tags

Why did we decide this ?

Dinesh
> If no particular controversy arises over this in the next two weeks,
We

---

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 7 Apr 2008 18:03:03 -0400

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Dinesh G Dutt
> Sent: Monday, April 07, 2008 2:18 PM

I wasn't present, but the most obvious reason is that
a forwarding database that supported both C-Tags and
S-Tags would be unpleasantly complicated.

---

From: James Carlson <[email-masked]>
Date: Mon, 7 Apr 2008 17:44:23 -0400

> Why did we decide this ?

S-tags are for provider backbone bridges (802.1AH), and we won't have
support for service instances.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Dinesh G Dutt <[email-masked]>
Date: Mon, 07 Apr 2008 18:25:57 -0700

I'm fine with stating only about C-tags and not mention anything about 
S-tags. I wouldn't want the spec to explicitly prohibit the use of S-tags.

Dinesh

---

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 7 Apr 2008 21:59:10 -0400

-----Dinesh Dutt wrote ----
Sent: Mon 4/7/2008 6:25 PM
Subject: Re: [rbridge] Consensus Check: C-Tags
 
I'm fine with stating only about C-tags and not mention anything about 
S-tags. I wouldn't want the spec to explicitly prohibit the use of S-tags.
----------------------------

Nothing constricts the 802.1 service that an RBridge uses to access
a given LAN (and its VLANs). The actual physical port could use S-Tags,
just as long as the RBridge does not.

But within the RBridge itself, its Forward Databases and the information
shared between RBridges, I don't see how you can mix C-Tag and S-Tag
domains without requiring *every* RBridge to fully understand Provider
Backbones.

I don't see any benefit for that even approaches the complexity required.

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 7 Apr 2008 22:16:08 -0400

Hi Dinesh,

I'm not sure exactly what you mean by "explicitly prohibit the use of
S-tags" but wherever the protocol spec requires a VLAN tag (Outer or
Inner), it currently specifies the use of the C-tag Ethertype. 

It is my impression that people are thinking that the current protocol
spec is for customer Rbridges and that, perhaps, at some point in the
future a separate "provider Rbridge" document could be written which
talks about S-tags, etc.

Thanks,
Donald

-----Original Message-----
From: Dinesh G Dutt [mailto:[email-masked]] 
Sent: Monday, April 07, 2008 9:26 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: C-Tags

I'm fine with stating only about C-tags and not mention anything about 
S-tags. I wouldn't want the spec to explicitly prohibit the use of
S-tags.

Dinesh
We

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 8 Apr 2008 07:31:22 -0500

As a response to the general question - together with a response to
the follow-on response so far - I would like to make the following
points:

1) I am very uncomfortable with explicitly limiting the applicability
   of RBridges to the case where "Enterprise" is defined specifically
   to exclude service provider networks (remember that an SP is also
   an "Enterprise" - unless explicitly excluded).
2) I agree with Dinesh that we should not explicitly exclude S-TAGs,
   even though it is (as Donald points out) necessary to be specific
   in a protocol specification.  A key reason for this is that - in
   the case where a SP might want to use RBridges to support their
   own use of an Ethernet (or Ethernet-like) infratructure (which 
   very-well might include both C-TAGs and S-TAGs).
3) One way to get around this is to state - up-front - that the use 
   of C-TAGs is assumed in the protocol specification, but there is 
   no intention to prohibit use of S-TAGs, and probably further say
   that any additional specification required to support S-TAGs is
   out of scope in this protocol specification.
4) The concerns expressed by Caitlin are not - and should not be -
   relevant to the protocol specification (especailly if scoped as
   I suggest above), since they are very explicitly related to an
   implementation (or assumptions about implementations) that may
   not be true for every implementation, and could very well be
   avoided entirely by simply making the implementation choice to
   onyl support C-TAGs.

--
Eric Gray
Principal Engineer
Ericsson  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Monday, April 07, 2008 10:16 PM
> To: Dinesh G Dutt
> Cc: [email-masked]

---

From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 8 Apr 2008 10:57:11 -0400

>    avoided entirely by simply making the implementation choice to

A set of RBridges collectively implement a single distributed database
of VLAN IDs and end station addresses (FID + MAC Address).

Depending on what semantics are expected with "supporting S-Tags" that
means that the VLAN IDs being tracked either become 13 or 24 bits
rather than 12.

Because this information is shared it is *not* limited to any
single implementation unless there is a clear definition that
allows RBRidges to be explicitly customer scoped, and only the
"Provider RBridges" would have to deal with the issues of S-Tags.

Stating that for *this* document, the only form of Q-Tag supported
is a C-Tag does that. And yes, somebody could define how a Provider
RBridge would work in a separate document.

---

From: James Carlson <[email-masked]>
Date: Tue, 8 Apr 2008 10:23:33 -0400

>    out of scope in this protocol specification.

It sounds like we're in violent agreement: this specification uses
C-tags, and S-tags are just out of scope.  A future document might
address them.

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 8 Apr 2008 11:27:51 -0500

James,

	Not exactly.  It is my opinion that support for the use 
of S-TAGs _requires_ no further specification.  Consider the
following quote from 802.1Q-2006:

"The semantics and structure of the S-TAG is identical to that 
 of the C-TAG, with the exception that bit 5 in octet 1, the
 Drop Eligible Indicator (DEI) bit, does not convey a CFI (9.6).
 The priority and drop_eligible parameters are conveyed in the
 3-bit PCP field and the DEI bit as specified in 6.7.3."

	Given this description of the differences between C-TAGs
and S-TAGs, it seems quite reasonable to me to suppose that any
one wanting to support S-TAGs should be able to without further
specification in either the TRILL WG, or in the IETF.

	However, it is possible that additional specification may
be needed.  Any such additional specification could be treated 
as out of scope (for now).  To tell the truth, I am unconvinced
of the need to do that - but I can live with a WG decision to
do so.

	But it is essentially wrong - IMHO - to assert that S-TAG
use cannot be done without further specification.

	With this subtle distinction, we are probably otherwise
in agreement.

--
Eric Gray
Principal Engineer
Ericsson  

> From: James Carlson [mailto:[email-masked]] 
> Sent: Tuesday, April 08, 2008 10:24 AM
> To: Eric Gray
> Cc: Eastlake III Donald-LDE008; Dinesh G Dutt; Caitlin 
> Bestler; [email-masked]
> Importance: High

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 8 Apr 2008 12:06:20 -0500

Caitlin,

	I think it is obvious that the issues you raise only exist
if the protocol specification is already over-specifying details 
of TRILL's use of Ethernet as a transport mechanism.

	In other specifications - within the IETF - where we have
needed to interface with Ethernet encapsulation, we have used a
common "interface" model that allows implementations to use any
form of defined Ethernet encapsulation available (provided they
can conform at the protocol level with a common interface model).

	On the specific potential conflict instance you point out - 
i.e. - the possibility that an S-TAG may be associated with a
larger number of VIDs than a C-TAG, I think you may be confusing
S-TAGs with the combination of S-TAGs and I-TAGs (defined in IEEE
802.1ah - which is not yet a standard, though it soon will be).
See the quote from 802.1Q-2006 that I provided in my response to
James Carlson, to see why it is obvious that the actual S-TAG does
not itself provide a larger VID space.  

	I-TAGs are used in conjunction with S-TAGs only at the PBB 
ingress and egress (I-component, in IEEE-ese).  It is possible 
that defining how an RBridge might also be an I-Component may 
require additional specification.  I doubt it - but this may be 
the case if we over-specify requirements in TRILL for using any 
specific Ethernet technologies.

	Part of the reason I doubt further explicit specification is
need in TRILL, is because the issue you are raising is not only 
limited to a specific implementation - it also would only apply 
to a specific deployment and configuration (i.e. - one in which 12 
bits of VID is insufficient to provide unambiguous differentiation 
of backbone services using the S-TAG).  Given that the size of a 
network (whether SP or Enterprise), for which this would be true, 
would probably overwhelm IS-IS routing scalability flat-out from 
the start, I question the reason why we should base our discussion 
on this case.

	In any case, the discussion is on whether or not S-TAGs 
should be explicitly disallowed in TRILL protocol specification
- not whether or not PBB (802.1ah) should be.

--
Eric Gray
Principal Engineer
Ericsson  

> From: Caitlin Bestler [mailto:[email-masked]] 
> Sent: Tuesday, April 08, 2008 10:57 AM
> To: Eric Gray; Eastlake III Donald-LDE008; Dinesh G Dutt
> Cc: [email-masked]
> Subject: RE: [rbridge] Consensus Check: C-Tags
> Importance: High
> 
> Eric Gray wrote:
>

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 8 Apr 2008 12:57:20 -0500

James,

	As a not-so-subtle distinction, I-TAGs are used to identify
service instances - not S-TAGs.

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:[email-masked]] On Behalf Of James Carlson
> Sent: Monday, April 07, 2008 5:44 PM
> To: Dinesh G Dutt
> Cc: [email-masked]

---

From: James Carlson <[email-masked]>
Date: Tue, 8 Apr 2008 13:09:53 -0400

> use cannot be done without further specification.

Out of scope == not addressed by this specification.

Once we've called it "out of scope," I don't really care whether an
additional document is _needed_ to complete that effort.  I suspect
one will be needed, and you seem to be asserting that one will not,
but I also think that it's completely immaterial for this document.

Ruling it out of scope means that we don't have to have the discussion
about what (if anything) to do about provider bridging _now_.

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 8 Apr 2008 12:54:08 -0500

James,

	Perhaps the subtlety was lost on you, or perhaps I am
reading something into the proposed consensus suggested by
Donald.  Part of what Donald proposed as a consensus was:

"[The protocol specification] should not mention or use S-tags, 
except possibly to distinguish them from C-tags, state that 
they are not used, or the like."

I believe it was the statement "they are not used" that formed
the basis of Dinesh' comments:

"Why did we decide this ?"

- and -

"I'm fine with stating only about C-tags and not mention anything 
 about S-tags. I wouldn't want the spec to explicitly prohibit the 
 use of S-tags."

Donald responded to this with:

"I'm not sure exactly what you mean by 'explicitly prohibit the
 use of S-tags' but wherever the protocol spec requires a VLAN 
 tag (Outer or Inner), it currently specifies the use of the
 C-tag Ethertype.

"It is my impression that people are thinking that the current
 protocol spec is for customer Rbridges and that, perhaps, at
 some point in the future a separate 'provider Rbridge' document
 could be written which talks about S-tags, etc."

	Hence the subtle issue is that - while I can agree with a
statement that use of S-TAGs is out of scope in this version of
the protocol specification - I agree with what I believe Dinesh
was saying when he indicated that we should not prohibit use of
S-TAGs in this specification by including a statement to the 
effect that S-TAGs are not used.  Any statement such as "S-TAGs
are not used" is innappropriate.  Further, I suggested using a
phrase to the effect that while the specification assumes use
of C-TAGS, it does not explicitly prohibit the use of S-TAGs.
While S-TAG use may be out of scope for this specification, it
may or may not require further specification (which means it is 
also out-of-scope to make any assertion about whether, or not,
additional specification is needed).

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Tuesday, April 08, 2008 1:10 PM
> To: Eric Gray

---

From: Dinesh G Dutt <[email-masked]>
Date: Tue, 08 Apr 2008 11:08:58 -0700

I agree with all points that Eric makes here. Consider the following 
scenarios:
- Rbridges are used within the provider backbone that isn't interested 
in doing much with ISIDs
- Rbridges are used within the enterprise but using S-Tags to carry the 
DEI bit.

I understand that there are complications if you attempt to mix C-Tags 
and S-Tags. That is why I'm fine with Rbridges stating that they're 
talking about C-Tags only. I don't want it to explicitly state that 
S-Tags are prohibited.

As Caitlin pointed out in an earlier email, STag is merely the ethertype 
to carry the VLAN info (same size, 12b since that is how big the field 
is in the Stag as well)

Dinesh
Eric Gray wrote:
>>> This is a check via the mailing list to confirm or refute 
>>>       
>> an apparent
>>     
>>> ******* The TRILL Base Protocol draft should only mention 
>>>       
>> and use IEEE
>>     
>>> 802.1 C-tags. It should not mention or use S-tags, except 
>>>       
>> possibly to
>>     
>>> distinguish them from C-tags, state that they are not used, or the
>>>       
>> like.
>>

---

From: James Carlson <[email-masked]>
Date: Tue, 8 Apr 2008 14:04:05 -0400

> service instances - not S-TAGs.

Right.  We won't have support for I-tags, so what are we doing
specifying any S-tag behavior?

I fail to see the usefulness of that.

---

From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 8 Apr 2008 14:28:10 -0400

Dinesh Dutt wrote:
> As Caitlin pointed out in an earlier email, STag is merely the
> ethertype to carry the VLAN info (same size, 12b since that is
> how big the field is in the Stag as well)
> 

To tie this in with some other recent threads, if we view RBridge as
a consumer of 802.1 services then the encapsulated 802.3 frame shown
in the protocol document is merely illustrative of how we presume
those 802.1 and 802.3 services will generate the frame.

Technically, all the RBridge specifies is the *information* that goes
in the outer Ethernet frame and then the enclosed payload (with the
TRILL Header, Inner Etherent Header and Ethernet Payload).

Perhaps we need some language that clarifies that *any* 802.1 service
the conveys the Trill Frame to the next hop RBridge meets the needs
of this document.

With that approach actual products would be totally free to make use
of S-Tags, just a long as S-Tag semantics did not penetrate the shared
RBridge forwarding information. Two RBridges are "adjacent" is there is
an 802.1 service that allows them to exchange encapsulated TRILL frames.
We can illustrate an 802.3 encapsulation using the C-TAG ethertype
without explicitly listing all other possible 802.1 services that could
deliver TRILL frames (such as using S-Tags, 802.11, metro Ethernet,
etc.).

That would let us focus on RBridge semantics, and let 802.1 focus on
C-Tags vs. S-Tags, etc.

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 8 Apr 2008 13:40:44 -0500

James,

	See Dinesh' point (as well as my own point on the 
context in which S-TAGs are defined); S-TAGs may be used
without I-TAGs.

	A somewhat larger point is that even if I-TAGs are
used, intermediate bridges do not see them.  I believe 
S-TAGs are deliberately defined in such a way as to make
it quite easy to have basic Q-Bridges forward frames with
S-TAGs instead of C-TAGs.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Tuesday, April 08, 2008 2:04 PM
> To: Eric Gray
> Cc: Dinesh G Dutt; [email-masked]

---

From: Dinesh G Dutt <[email-masked]>
Date: Tue, 08 Apr 2008 11:34:48 -0700

Well put, Caitlin. I agree,

Dinesh
Caitlin Bestler wrote:
>> - Rbridges are used within the enterprise but using S-Tags to carry
>>     
> the
>   
>>   DEI bit.
>>

---

From: James Carlson <[email-masked]>
Date: Tue, 8 Apr 2008 14:03:23 -0400

> additional specification is needed).

At the level that you're describing S-tags, any equipment that
understands an ordinary C-tag would perform the right functions,
leaving the issue essentially moot.

I read Donald's comments differently.  Equipment that processes what
are *known* to be S-tags should be dealing with the 'I' bits as well
and should know about provider-based bridging.  The current RBridges
specification does not do that.

So, sure, if you have packets on the wire that happens to look like
they have C-tags, and you don't tell an RBridge otherwise, then it'll
just do the right thing with respect to interpreting it as a VLAN.  It
won't look for the nested headers, though.

For that reason, I think our current spec leaves S-tags out of scope.
You're on your own if you use them with RBridges.  If someone cares
enough about S-tags to do them right, a future document _should_
discuss how to do that.  It shouldn't be the base document, though,
and we shouldn't discuss how to use them in that text.

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 8 Apr 2008 13:36:34 -0500

James,

	I think there is still something missing in your view;
S-TAGs are defined in 802.1Q, I-TAGs are defined in 802.1ah.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Tuesday, April 08, 2008 2:03 PM
> To: Eric Gray

---

From: James Carlson <[email-masked]>
Date: Tue, 8 Apr 2008 14:57:36 -0400

> S-TAGs instead of C-TAGs.

And nobody will be able to stop that from happening, even if the
RBridges specification were to say "we don't support S-tags."

There's nothing in the document or proposed for the document that will
somehow cause S-tags to stop working on any network, so I don't see
what the complaint is about.

If it's purely about the wording, then let's just delete every
instance of "S-tag" from the document (to be replaced by C-tag), and
say *NOTHING* about S-tags one way or the other.

I believe that to be exactly what the original consensus proposal
said.  And, as best I can tell, it does nothing to prohibit anyone
from doing whatever he wants with S-tags.

---

From: Dinesh G Dutt <[email-masked]>
Date: Tue, 08 Apr 2008 12:32:02 -0700

Agreed, that is all I asked for, to not explicitly prohibit S-Tag,

Dinesh

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 8 Apr 2008 18:23:01 -0500

James,

	If the original consensus proposal were altered to remove
the possibility of saying "[S-TAGs] are not used", then you'd 
be correct (at least in essence - the document currently does
not include a single instance of the expression "S-TAG", so it
would be unnecessary to replace those instances with "C-TAG" or
"C-Tag" or "C-tag" as the case might be).  It has not yet been 
so modified, so you are incorrect...

	If the currently proposed consensus is simply to omit any 
reference to S-TAGs, then I can live with that.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Tuesday, April 08, 2008 2:58 PM
> To: Eric Gray

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Tue, 8 Apr 2008 17:41:10 -0700

> [mailto:[email-masked]] On Behalf Of Dinesh G Dutt
> Sent: Tuesday, April 08, 2008 11:09 AM
> To: Eric Gray
> Cc: [email-masked]; Caitlin Bestler

> talking about C-Tags only. I don't want it to explicitly state that 

I agree with this.

Anoop

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 10 Apr 2008 16:31:44 -0400

Based on the discussion on the list, please consider the consensus
statement below to have been modified by replacing "used" with "in
scope" so it now reads:

******* The TRILL Base Protocol draft should only mention and use IEEE
802.1 C-tags. It should not mention or use S-tags, except possibly to
distinguish them from C-tags, state that they are not in scope, or the
like.

Donald & Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Monday, April 07, 2008 4:41 PM
To: [email-masked]
Subject: [rbridge] Consensus Check [modified]: C-Tags

Thanks,
Donald & Erik

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Tue, 15 Apr 2008 23:16:18 -0400

This is the last of the consensus checks via the mailing list to confirm
or refute an apparent
consensus at the Philadelphia meeting.

******* The VLANs on which an Rbridge sends TRILL IS-IS Hellos is
expanded to include those for which it is an appointed forwarder except
to the extent that it is configured not to send these additional Hellos.

If no particular controversy arises over this in the next two weeks, we
will declare it to be the working group consensus.

Thanks,
Donald & Erik

PS: There was not complete agreement on this although there did appear
to be a rough consensus at the meeting. However, in light of the other
consensus from that meeting to no longer require the "decapsulation
check" (see
http://www.postel.org/pipermail/rbridge/2008-April/002939.html) and the
discussions of the trade-offs, perhaps the consensus should be that, by
default, Rbridges MUST either (1) send these additional Hellos if they
are an appointed forwarder or (2) perform the decapsulation check.

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Wed, 16 Apr 2008 15:43:00 -0700

I had a problem with the general wording and 
had sent an email to the list about this a 
while back.

While I think it's OK to have the designated
forwarder send hellos on all VLANs, I would
prefer it be worded such that:

(a) We clearly state that the intent for this
is to detect connectivity issues.  In other
words, this will not be used for forming 
adjacencies (and there we will have something
in the hello that distinguishes it from the
hellos that are actually used to form adjacencies).

(b) That this behavior is optional because there
are other ways to detect connectivity issues
such as 802.1ag.  There is also the L2 Gateway
Protocol defined in 802.1ah that we can look into.
As such, I prefer that the default be to _not_ 
send such messages unless explicitly configured
to do so.

Anoop 

> Sent: Tuesday, April 15, 2008 10:16 PM
> To: [email-masked]
> Subject: [rbridge] Consensus Check: Hellos
> 
> This is the last of the consensus checks via the mailing list 
> to confirm or refute an apparent consensus at the 
> Philadelphia meeting.
> 
> 
> ******* The VLANs on which an Rbridge sends TRILL IS-IS 
> Hellos is expanded to include those for which it is an 
> appointed forwarder except to the extent that it is 
> configured not to send these additional Hellos.
> 
> 
> If no particular controversy arises over this in the next two 
> weeks, we will declare it to be the working group consensus.
> 
> Thanks,
> Donald & Erik
> 
> PS: There was not complete agreement on this although there 
> did appear to be a rough consensus at the meeting. However, 
> in light of the other consensus from that meeting to no 
> longer require the "decapsulation check" (see
> http://www.postel.org/pipermail/rbridge/2008-April/002939.html
) and the discussions of the trade-offs, perhaps the consensus > should
be that, by default, Rbridges MUST either (1) send 
> these additional Hellos if they are an appointed forwarder or 
> (2) perform the decapsulation check.
>

---

From: James Carlson <[email-masked]>
Date: Thu, 17 Apr 2008 08:10:02 -0400

> hellos that are actually used to form adjacencies).

I agree that's the intent, but I see no reason to "have something" in
the hello to distinguish it.  Merely omitting the peer system IDs will
have the desired effect, and we shouldn't need any special changes.

---

From: "Eric Gray" <[email-masked]>
Date: Thu, 17 Apr 2008 18:51:12 -0500

Anoop,

	As I recall, the reason for having this behavior was not at
all - or at least not primarily - for detecting missing connectivity.
As I recall, it was (primarily) about preventing looping as a result
of not detecting that there was more than one designated forwarder.

	See in particular Radia's discussion on "TRILL things" in the 
minutes at http://www.ietf.org/proceedings/08mar/minutes/trill.txt.

	Even if your assumption about why we might want to do it was
correct, I don't see how you could argue that we should have default
behavior that assumes the existence (and use) of some unspecified 
alternative for detecting connectivity issues.

	Hence the default should rely on the use of hellos as Donald's
note suggests.

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
> Sent: Wednesday, April 16, 2008 6:43 PM
> To: Eastlake III Donald-LDE008; [email-masked]
> Subject: Re: [rbridge] Consensus Check: Hellos
> 
>

---

From: "Ayan Banerjee (ayabaner)" <[email-masked]>
Date: Mon, 21 Apr 2008 10:52:45 -0700

I have a few questions on these: 

Does this mean that there is a single IS-IS adjacency on the LAN among
all nodes (assuming that K identical VLANs are configured on each node)
? 

Alternatively, are there K adjacencies per vlan among the IS-IS members
on the VLAN? 

Is the DRB being run per VLAN? 

Thanks,
Ayan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Gray
Sent: Thursday, April 17, 2008 4:51 PM
To: Anoop Ghanwani; Eastlake III Donald-LDE008; [email-masked]
Subject: Re: [rbridge] Consensus Check: Hellos

Anoop,

	As I recall, the reason for having this behavior was not at all
- or at least not primarily - for detecting missing connectivity.
As I recall, it was (primarily) about preventing looping as a result of
not detecting that there was more than one designated forwarder.

--
Eric Gray
Principal Engineer
Ericsson  

> I had a problem with the general wording and had sent an email to the 
> list about this a while back.
> 
> While I think it's OK to have the designated forwarder send hellos on 
> all VLANs, I would prefer it be worded such that:
> 
> (a) We clearly state that the intent for this is to detect 
> connectivity issues.  In other words, this will not be used for 
> forming adjacencies (and there we will have something in the hello 
> that distinguishes it from the hellos that are actually used to form 
> adjacencies).
> 
> (b) That this behavior is optional because there are other ways to 
> detect connectivity issues such as 802.1ag.  There is also the L2 
> Gateway Protocol defined in 802.1ah that we can look into.
> As such, I prefer that the default be to _not_ send such messages 
> unless explicitly configured to do so.
> 
> Anoop
> 
> > This is the last of the consensus checks via the mailing list to 
> > confirm or refute an apparent consensus at the Philadelphia meeting.
> > 
> >

---

From: Dinesh G Dutt <[email-masked]>
Date: Mon, 21 Apr 2008 13:28:36 -0700

Ayan,

> all nodes (assuming that K identical VLANs are configured on each node)
Yes.
> Alternatively, are there K adjacencies per vlan among the IS-IS members
No.
> Is the DRB being run per VLAN? 
No,

Dinesh

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 21 Apr 2008 15:55:05 -0400

See below at @@@

-----Original Message-----
From: Ayan Banerjee (ayabaner) [mailto:[email-masked]] 
Sent: Monday, April 21, 2008 1:53 PM
To: Eric Gray; Anoop Ghanwani; Eastlake III Donald-LDE008;
[email-masked]
Subject: RE: [rbridge] Consensus Check: Hellos

@@@ If by LAN you mean a possibly bridged LAN bounded by Rbridges and
end stations, then there would be a single core instance IS-IS adjacency
in the case your describe.

@@@ "K adjacencies per vlan"? Perhaps you are asking if core IS-IS
instance adjacencies are per VLAN. The answer is no.

@@@ No.

Thanks,
Ayan

@@@ Donald

-----Original Message-----

Anoop,

--
Eric Gray
Principal Engineer
Ericsson

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 24 Apr 2008 23:19:47 -0400

The following consensus has been confirmed.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Friday, April 04, 2008 5:44 PM
To: [email-masked]
Subject: [rbridge] Consensus Check: Text trumps pseudocode

Thanks,
Donald & Erik

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 24 Apr 2008 23:21:25 -0400

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Friday, April 04, 2008 5:39 PM
To: [email-masked]
Subject: [rbridge] Consensus Check: Test for VLAN mapping

Thanks,
Donald & Erik

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 24 Apr 2008 23:20:41 -0400

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Friday, April 04, 2008 5:28 PM
To: [email-masked]
Subject: [rbridge] Consensus Check: Decapsulation check optional

Thanks,
Donald & Erik

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Fri, 25 Apr 2008 23:40:45 -0400

The following consensus is confirmed.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Monday, April 07, 2008 4:37 PM
To: [email-masked]
Subject: [rbridge] Consensus Check: Critical Option Summary Bits

Thanks,
Donald & Erik

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sun, 27 Apr 2008 21:41:19 -0400

The consensus below is confirmed as modified.

Thanks,
Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Thursday, April 10, 2008 4:32 PM
To: [email-masked]
Subject: [rbridge] Consensus Check [modified]: C-Tags

Donald & Erik

-----Original Message-----

Thanks,
Donald & Erik