Subject: [rbridge] TRILL WG last call on draft-ietf-trill-adj

From: Erik Nordmark <[email-masked]>
Date: Tue, 05 Apr 2011 10:51:24 -0700

We've received last call comments from a few people, and as a result the 
draft has been revised over the last three months, and we've also 
created draft-perlman-trill-rbridge-af-00.txt with some separate 
clarifications.

BUT I'd like to make sure we have sufficient number of reviewers for 
draft-ietf-trill-adj. If you've read it during the last call process 
(whether the -01 we started with, the most recent -05, or a version in 
between), please send a note to the mailing list.
Please do this even if you didn't find any issues with the document.

Thanks,
     Erik

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

---

From: Jon Hudson <[email-masked]>
Date: Tue, 5 Apr 2011 13:02:55 -0700

Reviewing; No issues
.

---

From: [email-masked]
Date: Wed, 6 Apr 2011 02:53:20 +0200

I've read the adjacency document(draft-ietf-trill-adj), and the document 
is fine.

Erik Nordmark <[email-masked]> 
发件人:  [email-masked]
2011-04-05 19:51

收件人
[email-masked], [email-masked]
抄送

主题
[rbridge] TRILL WG last call on draft-ietf-trill-adj

Thanks,
     Erik

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 5 Apr 2011 19:15:15 -0700

Looks great to me too!!!

-Vishwas

---

From: Yizhou Li <[email-masked]>
Date: Wed, 06 Apr 2011 10:58:10 +0800

I am fine with -05.

Yizhou

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Erik Nordmark
Sent: Wednesday, April 06, 2011 1:51 AM
To: [email-masked]; [email-masked]
Subject: [rbridge] TRILL WG last call on draft-ietf-trill-adj

Thanks,
     Erik

---

From: Dinesh Dutt <[email-masked]>
Date: Wed, 06 Apr 2011 09:21:09 -0700

I've read the draft and have no unresolved issues,

Dinesh

---

From: Jon Hudson <[email-masked]>
Date: Wed, 6 Apr 2011 10:11:11 -0700

Reviewing. No issues.

---

From: [email-masked]
Date: Thu, 7 Apr 2011 13:14:00 +0800

I've read the adj draft, i support it.

2011-04-06 01:51

收件人

主题

Thanks,
     Erik

--------------------------------------------------------
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.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: sujay gupta <[email-masked]>
Date: Thu, 7 Apr 2011 15:01:35 +0530

Hi,

I have read the draft and support it.

There is some clarity required at Section 4.1
Suspended:
         Operation of the port is suspended because there is a higher
         priority port on the link with the same MAC address (SNPA).

IMO;
It should have been the "with the same LAN ID" as also mentioned in

Section 8, RB1 can detect
   this condition based on receiving TRILL LAN Hello messages with the
   same LAN ID on multiple ports.

BR,
-Sujay

---

From: mike shand <[email-masked]>
Date: Thu, 07 Apr 2011 13:29:51 +0100

Erik,

I've reviewed -5 and it looks good to me. Just a few very minor typos 
and one issue below.

     Mike

3.4 just below the table

TYPO:

"The special A0 even can transitions all"

Presumably should be "The special A0 event transitions all..."

4

SNPA. Technically, that should be SNPA address, not just SNPA. The MAC 
address is the address of the subnetwork point of attachment.

The same goes for other instances of SNPA where you really mean the 
address rather the point of attachment itself.

But this is a very small point. (similarly one should always talk about 
an NSAP address when one means the address, not "an NSAP" or indeed an 
IP address, not "an IP". But people do....

4.2 final para, final sentence

TYPO:
"If was..." -> "If it was..."

4.2.3?

TYPO:?

"in case the winning the DRB election changes,"

first "the" is probably superfluous

or perhaps "the winning of the...."

4.3

Apologies if I have missed the previous discussion of this, but I am a 
little surprised to see that event D1 now leads directly to DRB state 
given the stringent requirement to avoid duplicate DRBs. I would have 
expected a delay after being enabled, during which it listened for other 
hellos, before concluding that it was alone on the LAN and could become 
DRB. i.e. the previous pre-DRB state. I assume that this is covered by 
the inhibition of appointed forwarders referred to in the change notes 
and discussed in draft-perlman-trill-rbridge-af (which I have not yet read)

Assuming this is all benign, and given the stress placed in this 
document on not allowing multiple DRBs, I wonder if a short description 
of why this really is benign would be appropriate, or at least a 
reference to the af draft pointing out that this too affects DRB state..

Mike

On 05/04/2011 18:51, Erik Nordmark wrote:
>
> We've received last call comments from a few people, and as a result 
> the draft has been revised over the last three months, and we've also 
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 7 Apr 2011 09:18:56 -0400

Hi,

> It should have been the "with the same LAN ID" as also mentioned in

I do not agree.

The LAN ID is a seven (technically length of System ID +1) byte field
in the fixed header portion of IS-IS Hello PDUs. It can be viewed as
the name of the link as assigned by the Designated Intermediate System
(DIS / DRB). In the steady state, every Intermediate System / RBridge
port on the link that is sending Hellos will be sending those Hellos
with the LAN ID field set to the value that is being dictated by the
DIS / DRB. Thus, if a port was suspended when it received a Hello from
a higher priority RBridge with the same LAN ID as it was sending, all
ports would be suspended except for the highest priority port of the
DRB. Since a suspended port cannot send or receive TRILL Data frames,
it would be impossible to send data in the campus except between end
stations that happened to be attached to the same RBridge.

Thus, I believe that MAC or Sub Network Point of Attachment address is correct.

>   same LAN ID on multiple ports.

The condition referred to is one RBridge having multiple ports on a
link. (This is not the same as there being two or more ports on the
link with the same MAC/SNPA address, which is what suspension is based
on.) Since, in the stable state, every RBridge port on the link will
be sending Hellos with the same LAN ID, the text you quote from
Section 8 is one correct way for an RBridge to determine if it has two
or more ports on the same link.

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

---

From: Radia Perlman <[email-masked]>
Date: Thu, 7 Apr 2011 06:47:49 -0700

I agree that Donald (and the document) are correct.  Section 4.1 is
about suspending ports when multiple things are using the same MAC
address on a links, and section 8 is about an RBridge detecting that
multiple of its (unsuspended) ports are on the same link.  These can
be used for load splitting and do not need to be suspended (since they
are not using the same MAC address).

Radia

---

From: Ayan Banerjee <[email-masked]>
Date: Fri, 08 Apr 2011 01:46:22 -0700

I have read this draft.

On page 8: 
   In contrast, this behavior is not acceptable for TRILL, since in
   TRILL it is essential that all RBridges on the link know about each
   other, and choose a single RBridge to be the DRB and to control the
   native frame ingress and egress on that link.

I am not sure if this is entirely accurate. If there are two or more sets of
nodes which are disjoint from vlans that are configured on them, then it
would also appear as two separate LANs. I realize that the intent of the
above is to say when things are not dis-joint, this would be harmful. It
would be good to have a sentence on that.

Just a small nit with respect to the flow - it would be great if sections
7.1 and 7.2 can be re-ordered. It would be nice to see the transmission
operation described before the reception operation.

Thanks,
Ayan

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 8 Apr 2011 08:52:03 -0400

Hi Mike,

On Thu, Apr 7, 2011 at 8:29 AM, mike shand <[email-masked]> wrote:
> Erik,
>
> I've reviewed -5 and it looks good to me. Just a few very minor typos and
> one issue below.

Thanks.

> Presumably should be "The special A0 event transitions all..."

Yes, thanks.

> The same goes for other instances of SNPA where you really mean the address
> rather the point of attachment itself.
>
> But this is a very small point. (similarly one should always talk about an
> NSAP address when one means the address, not "an NSAP" or indeed an IP
> address, not "an IP". But people do....

I'll take a look. May be easy to add in some cases...

> "If was..." -> "If it was..."

Right.

> or perhaps "the winning of the...."

I think it should be either "in case the winner of the DRB election
changes," or "in case the winning port in the DRB election
changes,". Since the first is a little shorter and simpler, seems best
to go with that.

> little surprised to see that event D1 now leads directly to DRB state given
> the stringent requirement to avoid duplicate DRBs. I would have expected a
> delay after being enabled, during which it listened for other hellos, before
> concluding that it was alone on the LAN and could become DRB. i.e. the
> previous pre-DRB state. I assume that this is covered by the inhibition of
> appointed forwarders referred to in the change notes and discussed in
> draft-perlman-trill-rbridge-af (which I have not yet read)

The former "pre-DRB" state didn't have anything to do with the
requirement to have only one DRB on a link and wasn't for the purpose
of listening for Hellos. It only had to do with the inhibition of
native frame ingress and egress. That isn't in scope for this draft,
which is limited to adjacency formation, DRB (aka DIS) election, rules
for two-way and MTU matching for advertisements, and creation and use
of pseudo-nodes. There are a variety of reasons an RBridge can be
inhibited from ingressing or egressing native frames and they are all
covered in one document, draft-ietf-trill-rbridge-af which is now
posted as a WG draft.

> Assuming this is all benign, and given the stress placed in this document on
> not allowing multiple DRBs, I wonder if a short description of why this
> really is benign would be appropriate, or at least a reference to the af
> draft pointing out that this too affects DRB state..

The adjacency draft covers all the mechanisms whose purpose is to
avoid multiple DRBs on a link. The appointed forwarder draft has
nothing in it about not allowing multiple DRBs or, to be more precise,
how the DRB is elected. The "pre-DRB" state should not have been
included in the adjacency document in the first place, because it is
concerned with native frame handling inhibition which is out of scope
for the adjacency draft.

Thanks,
Donald

>> draft has been revised over the last three months, and we've also created
>> draft-perlman-trill-rbridge-af-00.txt with some separate clarifications.
>>

---

From: Radia Perlman <[email-masked]>
Date: Fri, 8 Apr 2011 12:14:38 -0700

Yes, you are correct, Ayan...if R1 only handles, say, even numbered
VLANs, and R2 only handles odd numbered VLANs, then they will not see
each other, couldn't possibly see each other, and it will be as if it
is two links, one with DRB R1, and the other with DRB R2, and this
isn't a problem.

But I'm not sure there's any quick way of saying that.  The paragraph
you quoted below is just to explain the problem for people that don't
understand layer 2 that well, and who find it mysterious that what
works in layer 3 woudln't work for TRILL.  So being absolutely correct
about weird layer 2 corner cases, I think, would not help in the
intuitive understanding.

Perhaps if you could suggest a sentence that wouldn't further confuse
people who are more layer 3-oriented, then we could add it as another
editorial change, but I'd actually prefer not going into that level of
detail here.  Because that paragraph is really just intended to be
tutorial.

Radia

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 10 Apr 2011 08:05:20 -0700

I would like to take this opportunity to once again thank the authors of
trill-adj for their efforts in producing this document. In particular I
commend Donald for his diligence and skillful exposition.

In regards to comments I have previously made regarding the draft I
believe V5 satisfactorily addresses all of my comments save two:

1)Reliable Circuit Scope Flooding

This issue is being addressed in draft-ietf-trill-rbridge-af and
therefore will be reviewed independently.

2)Preventing Multiple DRBs on a LAN

I have commented that the solution provided is imperfect and this
observation has been acknowledged by the authors.

In defining the use of IS-IS for Layer 2 two fundamental choices are
available:

A)Use the existing base protocol mechanisms w/o change adding only new
TLV information as required

B)Extend/revise base protocol mechanisms

Other L2 IS-IS technologies have chosen A - but in the case of adjacency
adjacency formation on a LAN TRILL chose to significantly revise the
existing protocol machinery. The clearly stated motivation for this
choice is the requirement that a single DRB be elected on a LAN circuit.
Although base protocol mechanisms insure that a single DRB would be
elected in most circumstances, some pathological cases are not handled.
The intent of the TRILL Hello Protocol is to more robustly guarantee a
single DRB would be elected even in the event of some pathology, but as
the solution is still imperfect it calls into question whether the
introduction of the new machinery is warranted.

   Les

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Erik Nordmark
> Sent: Tuesday, April 05, 2011 10:51 AM
> Subject: [Isis-wg] TRILL WG last call on draft-ietf-trill-adj
> 
> 
> the

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 10 Apr 2011 13:54:18 -0400

Hi Ayan,

On Fri, Apr 8, 2011 at 4:46 AM, Ayan Banerjee <[email-masked]> wrote:
> ...

I don't care what order sections 7.1 and 7.2 are in and I doubt that
very many other people do either. I'm fine with swapping them.

Thanks,
Donald

---

From: sujay gupta <[email-masked]>
Date: Mon, 11 Apr 2011 10:18:44 +0530

Thanks,

I am sure I have missed the discussion leading to "Suspended State",
but has there been any practical scenarios where multiple nodes
on the same link bounce off the same MAC address?

A few more minor points;

1.
Section 1. Introduction
-
 It includes reference
   implementation details.
-
Does the draft include implementation details or at best suggestions?

2.
Section 2.1. Title "Incrementally Replacing 802.1Q-2005 Bridges"
and the content in the para below, does not exactly chime well.
It sounded more of interaction and inter-op with existing 802.1 Bridges
and they way TRILL is supposed to behave.

A slight rephrase of the statement "
 When a frame is
   presented to an [802.1Q-2005] port for queuing and transmission, it
   must be accompanied by a VLAN ID and frame priority, although whether
   the frame, if actually transmitted, will be VLAN tagged is determined
   by whether the port is configured to "strip VLAN tags" in that case.
"
would sound better;
 " When a frame is
   presented to an [802.1Q-2005] port for queuing and transmission, it
   must be accompanied by a VLAN ID and frame priority, although whether
   the frame, if actually transmitted, will be VLAN tagged is determined
   by whether the port is configured to "strip VLAN tags" or not."

3. Section 2.2 ; Para 4
"This is the
   Designated RBridge which is elected using TRILL LAN Hellos as further
   described in Sections 2.5 and 4 below."
This would be the case if DRB is playing the role of AF for all
VLAN's, which may be
generally true , hence the statement could be;
"This is generally the Designated RBridge ...... "

4.
Section 4.1
  Each RBridge port is in one of the following five DRB states:

Change to;

  Each RBridge port is in one of the following four DRB states:

5.
Section 7.2
" except that no Hellos are sent if a port is in the
   Suspended state."

Change to;
"except that no Hellos are sent if a port is in the
   Suspended state & Down state"

Thanks,
-Sujay

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 11 Apr 2011 08:14:56 -0400

Hi Sujay,

> on the same link bounce off the same MAC address?

I believe there are switch manufacturers that have used the same MAC
address for all of the ports on a switch. So I think the most likely
case is where two (or more) ports from such a switch are connected to
the same link (which for TRILL can be a bridged LAN). But there are
other cases. I have been told that some switches from one manufacturer
have the characteristic that, while all the ports on the switch have
different MACs that count up from a base MAC by +1 per port, the base
MAC address used on different switches from that manufacturer differ
by less than the number of ports and, in fact, the base MAC address on
some different switches from the manufacturer may only differ by one.
Then there is the case of accidental re-use of MAC addresses between
switches, usually from the same manufacturer...

> Does the draft include implementation details or at best suggestions?

"reference implementation details" are like "reference code". If you
follow all the details, it will come out right. But (except where
there is mandatory implementation language: "MUST", "MUST NOT") you
can implement differently as long as it produces allowed behavior.

>   by whether the port is configured to "strip VLAN tags" or not."

OK.

> "This is generally the Designated RBridge ...... "

I believe the text is correct as it stands. It does not say that the
DRB does all the ingressing and egress of native frames. It says that
the DRB is "in charge of ingressing and egressing native frames".
Whether the DRB does the ingressing and egressing for some particular
VLAN itself or the DRB directs some other RBridge to do it, the DRB is
still "in charge".

>  Each RBridge port is in one of the following four DRB states:

Thanks, there were five states at one point and I missed this in
changing to four.

>   Suspended state & Down state"

The Down state is defined as the port being administratively disabled
or down at the link state. Does Layer 3 IS-IS sends Hellos on ports
that are Down in that sense?

To cover all bases, I'll change the text you quote to the following:
"; however, no Hellos are sent if a port is in the Suspended or Down
states"

Thanks,
Donald

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Apr 2011 09:51:34 -0700

Based on the comments from folks that have read the document and the 
fact that Donald fixed things based on the last round of comments and 
issued 06, I conclude that there is consensus in the TRILL WG to advance 
the document.

I know that there was one request to change how 
draft-ietf-trill-rbridge-protocol-16 announces appointed forwarders, 
even though the current mechanism isn't broken (it might be suboptimal 
in some cases). I don't think such a change is warranted, and I haven't 
seen any indication that the WG would have consensus to do a protocol 
change at this point in time.
Furthermore, the scope the ADs gave us when they requested that we 
produce the adj document was to do clarifications, such as adding state 
machines and the like. That scope didn't include doing protocol changes 
and improvements.
There was ample time to review the draft-ietf-trill-rbridge-protocol 
before it was approved by the IESG (with WG last calls in both TRILL and 
later in ISIS, and an IETF last call), thus the bar for protocol changes 
1.5 years later should be pretty high.

I hope that TRILL will be widely implemented and deployed, and that we 
can learn from that and see what protocol changes, if any, might be 
warranted as we move TRILL along the standards track. TRILL has been a 
proposed standard for over a year now.

Thanks to all those careful reviews of the adj document.

    Erik