From Internet-Drafts at ietf.org  Sun Jan  2 19:45:02 2011
From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org)
Date: Sun, 02 Jan 2011 19:45:02 -0800
Subject: [rbridge] I-D Action:draft-ietf-trill-adj-01.txt
Message-ID: <20110103034502.26291.28724.idtracker@localhost>



From dromasca at avaya.com  Mon Jan  3 08:09:55 2011
From: dromasca at avaya.com (Romascanu, Dan (Dan))
Date: Mon, 3 Jan 2011 17:09:55 +0100
Subject: [rbridge] Request for review
	ofdraft-ietf-trill-rbridge-mib-01.txt
In-Reply-To: <AANLkTinR4jaqvEaFDnPYKS38H1zPMba17aN8fQbmTtr3@mail.gmail.com>
References: <4D08ED04.2050503@acm.org>
	<AANLkTinR4jaqvEaFDnPYKS38H1zPMba17aN8fQbmTtr3@mail.gmail.com>
Message-ID: <EDC652A26FB23C4EB6384A4584434A0402A2C768@307622ANEX5.global.avaya.com>

I did not have time for a full review, but here are my comments from a first quick examination of the document

1. The relationship with other MIB module sections refer to the IETF RFCs. However, since 2006 the development of the Bridge MIB modules and their successors were transferred to IEEE 802.1. I suggest to define the relationship sections in relation to the IEEE MIB modules defined in IEEE 802.1ap

2. Some of the objects with read-create MAX-ACCESS need DEFAULT clauses. In some cases the default is mention in the DESCRIPTION clause - this is not sufficient

3. MIB structure - better group all MIB groups that define objects under one sub-tree 

rbridgeObjects           OBJECT IDENTIFIER ::= { rbridgeMIB 1 } 

4. The current level of detail in the Security Considerations section is not sufficient. 

5. running libsmi compilation leads to a number of errors and warnings that need to be fixed. 

Regards,

Dan


> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Donald Eastlake
> Sent: Tuesday, December 28, 2010 5:26 AM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Request for review 
> ofdraft-ietf-trill-rbridge-mib-01.txt
> 
> Hi,
> 
> It would be helpful if people would review the MIB document. 
> Here is a comment of mine:
> 
> I think that Sz, the campus wide minimum MTU that an RBridge 
> has calculated, should be a read-only per-RBridge MIB object 
> and that it should be possible for a change in Sz to cause a 
> notification.
> 
> Thanks,
> Donald
> 
> On Wed, Dec 15, 2010 at 11:29 AM, Erik Nordmark 
> <nordmark at acm.org> wrote:
> >
> > In Beijing there were not that many that had read the MIB document.
> > Bill Fenner volunteered to read it and send comments, but 
> it would be 
> > good to get some other reviewers.
> >
> > Any additional volunteers?
> >
> > Particular things to look at is whether there are other traps that 
> > would be useful for an operator.
> >
> > ? Erik
> >
> >
> >
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
> 


From nordmark at acm.org  Mon Jan  3 10:53:31 2011
From: nordmark at acm.org (Erik Nordmark)
Date: Mon, 03 Jan 2011 10:53:31 -0800
Subject: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
Message-ID: <4D221B2B.2020207@acm.org>


This starts a two-week WG last call on "RBridges: Adjacency"
<draft-ietf-trill-adj-01.txt>, available at
http://tools.ietf.org/html/draft-ietf-trill-adj-01

The last call ends on 1/17/2011.

Send any comments to the TRILL WG mailing list.

     Erik



From nordmark at acm.org  Mon Jan  3 11:43:54 2011
From: nordmark at acm.org (Erik Nordmark)
Date: Mon, 03 Jan 2011 11:43:54 -0800
Subject: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <4D221B2B.2020207@acm.org>
References: <4D221B2B.2020207@acm.org>
Message-ID: <4D2226FA.3040001@acm.org>

On 01/ 3/11 10:53 AM, Erik Nordmark wrote:
>
> This starts a two-week WG last call on "RBridges: Adjacency"
> <draft-ietf-trill-adj-01.txt>, available at
> http://tools.ietf.org/html/draft-ietf-trill-adj-01
>
> The last call ends on 1/17/2011.
>
> Send any comments to the TRILL WG mailing list.

I have a small editorial suggestion for the draft.

Currently the events are numbered 1-8 and 1-5. Thus "event 5" isn't 
sufficient to specify the name of an event. It would be more clear if 
they were numbered A1-A8 and D1-D5 (or P1-P5).

That means we don't need text like e.g., "an adjacency event 5 occurs 
for the adjacency", but can instead say "an event A5 occurs for the 
adjacency".

    Erik

From d3e3e3 at gmail.com  Sun Jan  9 18:48:01 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Sun, 9 Jan 2011 21:48:01 -0500
Subject: [rbridge] Fwd: [Pppext] I-D
	Action:draft-ietf-pppext-trill-protocol-02.txt
In-Reply-To: <20110106154501.15655.20204.idtracker@localhost>
References: <20110106154501.15655.20204.idtracker@localhost>
Message-ID: <AANLkTi=spm3QE1_rgL7obOWQPu1C3c-zPiOw-1wqau9C@mail.gmail.com>

---------- Forwarded message ----------
From:  <Internet-Drafts at ietf.org>
Date: Thu, Jan 6, 2011 at 10:45 AM
Subject: [Pppext] I-D Action:draft-ietf-pppext-trill-protocol-02.txt
To: i-d-announce at ietf.org
Cc: pppext at ietf.org

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

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

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

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
Pppext mailing list
Pppext at ietf.org
https://www.ietf.org/mailman/listinfo/pppext


From nordmark at acm.org  Wed Jan 12 11:01:03 2011
From: nordmark at acm.org (Erik Nordmark)
Date: Wed, 12 Jan 2011 11:01:03 -0800
Subject: [rbridge] Change of affiliation
Message-ID: <4D2DFA6F.1000807@acm.org>


Just to keep everyone informed.
As of this week I'm an employee of Cisco Systems.

Regards,
    Erik


From ginsberg at cisco.com  Thu Jan 13 17:36:54 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Thu, 13 Jan 2011 17:36:54 -0800
Subject: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <4D221B2B.2020207@acm.org>
References: <4D221B2B.2020207@acm.org>
Message-ID: <AE36820147909644AD2A7CA014B1FB520D0DF50D@xmb-sjc-222.amer.cisco.com>

(resending w corrected TRILL WG address)

Attached please find my comments on draft-ietf-trill-adj-01. 

The file draft-ietf-trill-adj-01_comments.txt contains substantive
comments identified by Section # - except in a couple of cases where the
remarks are more generic.

The file draft-ietf-trill-adj-01_editorial.txt is portions of the draft
annotated with editorial comments. Search for "LES:" in the file.

As context, the requirements of [TRILL] introduce the need to send a
great deal more circuit scoped information on a LAN as compared to Layer
3 IS-IS. Extensions to the IS-IS protocol defined in [TRILL],
[TRILL-ISIS], and [TRILL-ADJ] are designed to support this new
information and to provide robust loop prevention in the forwarding of
data. But I believe the extensions as currently defined have significant
scalability issues in the presence of a large number of neighbors on a
LAN and/or a large number of enabled VLANs. In my comments I have
confined myself to pointing out where I believe such issues arise. If
there is consensus that these are issues which should be addressed, then
additional discussions can be started as to how to do so.

Finally, I would like to thank the authors of draft-ietf-trill-adj-01
for the effort and diligence they obviously applied to the writing of
this draft.

   Les

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: draft-ietf-trill-adj-01_comments.txt
Url: http://mailman.postel.org/pipermail/rbridge/attachments/20110113/846200ef/draft-ietf-trill-adj-01_comments.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: draft-ietf-trill-adj-01_editorial.txt
Url: http://mailman.postel.org/pipermail/rbridge/attachments/20110113/846200ef/draft-ietf-trill-adj-01_editorial.txt

From vishwas.ietf at gmail.com  Thu Jan 13 20:16:57 2011
From: vishwas.ietf at gmail.com (Vishwas Manral)
Date: Thu, 13 Jan 2011 20:16:57 -0800
Subject: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <AE36820147909644AD2A7CA014B1FB520D0DF50D@xmb-sjc-222.amer.cisco.com>
References: <4D221B2B.2020207@acm.org>
	<AE36820147909644AD2A7CA014B1FB520D0DF50D@xmb-sjc-222.amer.cisco.com>
Message-ID: <AANLkTikKAD86kLWo7w9ExcsNWAtu9y4Zv0cmCg=qz+uM@mail.gmail.com>

Hi Les,

My comments attached on the technical comments:

Reliable Circuit Scope Flooding
--------------------------------

[RFCTrill] defines a requirement for reliable circuit scoped flooding of
Appointed Forwarder Information (Section 4.4.2) but it is not specified
how this is to be achieved. I had hoped this document would provide that
specification.

The lack of reliable flooding means that either:

a)Appointed forwarder information MUST be included by the DRB always -
which does not scale well

OR

b)Loops and/or loss of traffic for a given VLAN MAY occur

VM> One way to do it will be to send it Hello Multiplier + 1 times in
the Hello. If a neighbor misses all the Hellos it will anyway bring
down its adjacency and it will be noticed, otherwise the information
will be reliably exchanged.

Preventing Multiple DRBs on a LAN
---------------------------------

It is not clear to me how the use of multiple announcing VLANs achieves
the stated goal of one and only one DRB in the presence of inconsistent
connectivity / configuration. Consider the following simple example where
VLANs(1,2,3) are in the enabled set on all RBs:

RB Name/     DVLAN   Announcing VLANs   VLAN Connectivity
Priority
--------------------------------------------------------
RB1/50         1       1,2              1,2,3
RB2/60         1       1                1
RB3/70         3       2                2,3

Given the above the following would ensue:

RB Name     Neighbors       DRB/
             Detected       DVLAN
--------------------------------------------------------
RB1            2,3          3/2
RB2            1            2/1
RB3            2,3          3/2

Now, given the above, both RB3 and RB2 will think they are DRB and potentially
assign multiple AFs for each of the VLANs. Keeping in mind [TRILL]
Section 4.4.3

"Great care should be taken in configuring an RBridge
   to not send TRILL Hellos on any VLAN where that RBridge is appointed
   forwarder as, under some circumstances, this can lead to loops."

it becomes apparent that at a minimum at least one RB MUST send IIHs on each
enabled VLAN in order to implement loop prevention. But this does not scale
well.

VM> Les it is stated that:

 Designated VLAN: the VLAN being used on the link for all TRILL frames
except some TRILL Hellos.  This is RBn's Desired Designated VLAN if
RBn believes it is the DRB or the Designated VLAN in the DRB's Hellos
if RBn is not the DRB.

This means is that there is atleast one VLAN which is common to all
devices on the link. The example you have given above would be a
configuration issue. The protocol does not deal with configuration
issues.

Section 3.3
-------------

Text says that for hellos received on a VLAN Other than the D-VLAN

"any TRILL Neighbor TLV in such a Hello is ignored..."

I assume this means that it is an implementation choice as to whether to
include the neighbor TLV in such hellos? A clear statement of this would
be helpful.
VM> Neighbor TLV is ignored on receipt and not sent. It is in the
spirit of being liberal while accepting, and being strict while
sending.

Section 4
----------

There needs to be a description of the DRB election process -
equivalent to what is in [IS-IS] Section 8.4.5. For example, the set of
DRB candidates includes all RBs to which the local system has an adjacency
in Detect, 2-way, or Report State ...correct?

You also need to specify in what DRB election states a DRB reports neighbors
in pseudo-node LSPs. It would seem that if neighbors are advertised in
pre-DRB state that we could attract traffic which we are not yet able to
forward.
VM> I think it is well specified. Like clearly mentioned DRB election
happens independent of the neighbor state.

Section 4.2
-----------

When a DRB change causes a change in D-VLAN, the draft says:

      o  The non-Designated VLAN Hello Holding timer is set to the
         maximum of its time to expiration and the time to expiration of
         the Designated VLAN Hello Holding timer.

The "Designated VLAN Hello Holding timer" referred to is the OLD Designated
VLAN Hello Holding timer, correct? If so adding that clarification would help.
VM> That is correct.

Also, if we are NOT DRB and the new D-VLAN is NOT in the set of announcing
VLANs then the non-DRBs have to include the new D-VLAN in the set of VLANS for
which they send hellos, correct? This should be specified.
VM> OK.

It is also apparent that DRB changes are very disruptive - even more so than
at Layer 3. In Layer 3 on a DIS change optimal behavior is to do a "make
before break" to minimize disruption. However, that is not possible here as
all adjacencies will go into "Detect" state following a DRB change.
Should it be recommended then to avoid DRB changes whenever possible
(e.g.
by setting LAN priority)?

VM> I think it is stated in multiple places that DRB change is
diruptive and that is why the algorithm is designed the way it is.

Section 5
---------

[TRILL] 4.3.2 states:

"The MTU-probe MAY be multicast to All-RBridges, or unicast to a specific
RBridge. The MTU-ack is  normally unicast to the source of the MTU-probe
to which it responds  but MAY be multicast to All-RBridges."

How does the sender of the Probe/ACK determine whether to use unicast or
multicast destination address?

VM> By default MTU-Probe and ACK will be unicast. It could be
configured to do it a different way. A reason MTU-probe could be
multicast is when a new device first joins a link, which already has
Rbridges attached.

If an MTU-ACK is sent to multicast address what should the receivers who
did not initiate the probe do with the ACK? Ignore? Process?
VM> It is processed.

On a LAN should MTU probes only be sent to/from the DRB when pseudo-node
bypass is NOT set? It seems useless to do otherwise - but this is not
discussed.

Also, don't you need PORT ID in the Probe Source/ACK Source in the MTU PDU
to fully identify the source/responder?

It would have been better in terms of use of the limited PDU type space to
define only one new PDU type and encode the probe/ack inside of the PDU.

Also, this particular area exemplifies how difficult it is to come to a
full understanding of proper behavior. [TRILL] must be consulted to find
a description of how to send the PDUs, [RFCtisis] must be consulted to find
the PDU code points and formats, and the TRILL-adj document must be consulted
to find a description of how to incorporate MTU test results into the
hello process.

Section 6
-----------

I find the discussion of what RBs should do when the bypass bit is set/not
set unclear. The intent is for RBs to advertise neighbors in Report state
in their non-pseudo-node LSPs when the Bypass bit is set - and to advertise
the neighbor to the pseudo-node when Bypass bit is NOT set - but the
wording used

"directly report their adjacencies"

isn't as clear as it could be.

Also, I assume that when advertising the neighbor to the pseudo-node, the state
 (2-way or Report) is inherited from the state of the adjacency to the DRB? A
clear satement of this would be helpful.
VM> Clarity could be added.

Section 7.2
------------
Is IIH padding ignored on receipt?? Or is a padded IIH discarded?

In regards to what TLVs should be in an IIH, the text says:

   If there are no adjacencies with a non-zero Designated VLAN Hello
   Holding timer, an empty TRILL Neighbor TLV MUST be included in each
   Hello.  If there are such adjacencies, then the Hello MAY contain a
   TRILL Neighbor TLV as described in Section 4.4.2.1 of [RFCtrill].

The Neighbor TLV is ONLY used to report neighbors I have
seen in IIHs received on the D-VLAN and if I have NO such neighbors I MUST
send an empty neighbor TLV - but if I do have one or more such neighbors
then sending a neighbor TLV is optional??? What is the motivation for this?
VM> The idea is we should not pad, because packets may not get through
due to difference in MTU. However if it is received I think there is
no reason to do anything different for it.

Thanks,
Vishwas

On Thu, Jan 13, 2011 at 5:36 PM, Les Ginsberg (ginsberg)
<ginsberg at cisco.com> wrote:
> (resending w corrected TRILL WG address)
>
> Attached please find my comments on draft-ietf-trill-adj-01.
>
> The file draft-ietf-trill-adj-01_comments.txt contains substantive
> comments identified by Section # - except in a couple of cases where the
> remarks are more generic.
>
> The file draft-ietf-trill-adj-01_editorial.txt is portions of the draft
> annotated with editorial comments. Search for "LES:" in the file.
>
> As context, the requirements of [TRILL] introduce the need to send a
> great deal more circuit scoped information on a LAN as compared to Layer
> 3 IS-IS. Extensions to the IS-IS protocol defined in [TRILL],
> [TRILL-ISIS], and [TRILL-ADJ] are designed to support this new
> information and to provide robust loop prevention in the forwarding of
> data. But I believe the extensions as currently defined have significant
> scalability issues in the presence of a large number of neighbors on a
> LAN and/or a large number of enabled VLANs. In my comments I have
> confined myself to pointing out where I believe such issues arise. If
> there is consensus that these are issues which should be addressed, then
> additional discussions can be started as to how to do so.
>
> Finally, I would like to thank the authors of draft-ietf-trill-adj-01
> for the effort and diligence they obviously applied to the writing of
> this draft.
>
> ? Les
>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>


From ginsberg at cisco.com  Fri Jan 14 09:02:09 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Fri, 14 Jan 2011 09:02:09 -0800
Subject: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <AANLkTikKAD86kLWo7w9ExcsNWAtu9y4Zv0cmCg=qz+uM@mail.gmail.com>
References: <4D221B2B.2020207@acm.org><AE36820147909644AD2A7CA014B1FB520D0DF50D@xmb-sjc-222.amer.cisco.com>
	<AANLkTikKAD86kLWo7w9ExcsNWAtu9y4Zv0cmCg=qz+uM@mail.gmail.com>
Message-ID: <AE36820147909644AD2A7CA014B1FB520D0DF658@xmb-sjc-222.amer.cisco.com>

Vishwas -

Thanx for the reply.
Inline.

> -----Original Message-----
> From: Vishwas Manral [mailto:vishwas.ietf at gmail.com]
> Sent: Thursday, January 13, 2011 8:17 PM
> To: Les Ginsberg (ginsberg)
> Cc: isis-wg at ietf.org; rbridge at postel.org
> Subject: Re: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
> 
> Hi Les,
> 
> My comments attached on the technical comments:
> 
> Reliable Circuit Scope Flooding
> --------------------------------
> 
> [RFCTrill] defines a requirement for reliable circuit scoped flooding
> of
> Appointed Forwarder Information (Section 4.4.2) but it is not specified
> how this is to be achieved. I had hoped this document would provide
> that
> specification.
> 
> The lack of reliable flooding means that either:
> 
> a)Appointed forwarder information MUST be included by the DRB always -
> which does not scale well
> 
> OR
> 
> b)Loops and/or loss of traffic for a given VLAN MAY occur
> 
> VM> One way to do it will be to send it Hello Multiplier + 1 times in
> the Hello. If a neighbor misses all the Hellos it will anyway bring
> down its adjacency and it will be noticed, otherwise the information
> will be reliably exchanged.

This only works (with some caveats) in the case where the complete set of Appointed Forwarder information is contained within a single hello. But in large scale deployments it is likely that each hello will only contain a subset of the appointed forwarder information, in which case the strategy you suggest only guarantees that at least one of the subsets has been seen by the neighbor.


> 
> Preventing Multiple DRBs on a LAN
> ---------------------------------
> 
> It is not clear to me how the use of multiple announcing VLANs achieves
> the stated goal of one and only one DRB in the presence of inconsistent
> connectivity / configuration. Consider the following simple example
> where
> VLANs(1,2,3) are in the enabled set on all RBs:
> 
> RB Name/     DVLAN   Announcing VLANs   VLAN Connectivity
> Priority
> --------------------------------------------------------
> RB1/50         1       1,2              1,2,3
> RB2/60         1       1                1
> RB3/70         3       2                2,3
> 
> Given the above the following would ensue:
> 
> RB Name     Neighbors       DRB/
>              Detected       DVLAN
> --------------------------------------------------------
> RB1            2,3          3/2
> RB2            1            2/1
> RB3            2,3          3/2
> 
> Now, given the above, both RB3 and RB2 will think they are DRB and
> potentially
> assign multiple AFs for each of the VLANs. Keeping in mind [TRILL]
> Section 4.4.3
> 
> "Great care should be taken in configuring an RBridge
>    to not send TRILL Hellos on any VLAN where that RBridge is appointed
>    forwarder as, under some circumstances, this can lead to loops."
> 
> it becomes apparent that at a minimum at least one RB MUST send IIHs on
> each
> enabled VLAN in order to implement loop prevention. But this does not
> scale
> well.
> 
> VM> Les it is stated that:
> 
>  Designated VLAN: the VLAN being used on the link for all TRILL frames
> except some TRILL Hellos.  This is RBn's Desired Designated VLAN if
> RBn believes it is the DRB or the Designated VLAN in the DRB's Hellos
> if RBn is not the DRB.
> 
> This means is that there is atleast one VLAN which is common to all
> devices on the link. The example you have given above would be a
> configuration issue. The protocol does not deal with configuration
> issues.

Misconfiguration is not what the example is trying to show. All VLANs are enabled on all RBs in the example above, but there is a connectivity issue on VLANS 2,3 for RB2. This is obviously a pathological case, but as [TRILL] emphasizes the importance of being able to handle such cases I am simply demonstrating that the extensions are not able to deal with all cases.

If we can assume that there are never any connectivity issues and - as you say - the protocol "does not deal with configuration issues", then sending hellos on one VLAN would be sufficient - but the concern throughout all of the TRILL documents is that such an assumption is not safe.

> 
> Section 3.3
> -------------
> 
> Text says that for hellos received on a VLAN Other than the D-VLAN
> 
> "any TRILL Neighbor TLV in such a Hello is ignored..."
> 
> I assume this means that it is an implementation choice as to whether
> to
> include the neighbor TLV in such hellos? A clear statement of this
> would
> be helpful.
> VM> Neighbor TLV is ignored on receipt and not sent. It is in the
> spirit of being liberal while accepting, and being strict while
> sending.

Agreed - but it would be better to state that explicitly.

> 
> Section 4
> ----------
> 
> There needs to be a description of the DRB election process -
> equivalent to what is in [IS-IS] Section 8.4.5. For example, the set of
> DRB candidates includes all RBs to which the local system has an
> adjacency
> in Detect, 2-way, or Report State ...correct?
> 
> You also need to specify in what DRB election states a DRB reports
> neighbors
> in pseudo-node LSPs. It would seem that if neighbors are advertised in
> pre-DRB state that we could attract traffic which we are not yet able
> to
> forward.
> VM> I think it is well specified. Like clearly mentioned DRB election
> happens independent of the neighbor state.

I do think more clarity would be desirable.
Can you comment on the second point regarding in what "DRB election state" (NOT neighbor state) neighbors are advertised?

> 
> Section 4.2
> -----------
> 
> When a DRB change causes a change in D-VLAN, the draft says:
> 
>       o  The non-Designated VLAN Hello Holding timer is set to the
>          maximum of its time to expiration and the time to expiration
> of
>          the Designated VLAN Hello Holding timer.
> 
> The "Designated VLAN Hello Holding timer" referred to is the OLD
> Designated
> VLAN Hello Holding timer, correct? If so adding that clarification
> would help.
> VM> That is correct.
> 
> Also, if we are NOT DRB and the new D-VLAN is NOT in the set of
> announcing
> VLANs then the non-DRBs have to include the new D-VLAN in the set of
> VLANS for
> which they send hellos, correct? This should be specified.
> VM> OK.
> 
> It is also apparent that DRB changes are very disruptive - even more so
> than
> at Layer 3. In Layer 3 on a DIS change optimal behavior is to do a
> "make
> before break" to minimize disruption. However, that is not possible
> here as
> all adjacencies will go into "Detect" state following a DRB change.
> Should it be recommended then to avoid DRB changes whenever possible
> (e.g.
> by setting LAN priority)?
> 
> VM> I think it is stated in multiple places that DRB change is
> diruptive and that is why the algorithm is designed the way it is.
> 

Agreed. I am suggesting that because of the highly disruptive nature of DRB changes that it would be prudent to recommend taking steps to minimize the occurrence of such changes.


> Section 5
> ---------
> 
> [TRILL] 4.3.2 states:
> 
> "The MTU-probe MAY be multicast to All-RBridges, or unicast to a
> specific
> RBridge. The MTU-ack is  normally unicast to the source of the MTU-
> probe
> to which it responds  but MAY be multicast to All-RBridges."
> 
> How does the sender of the Probe/ACK determine whether to use unicast
> or
> multicast destination address?
> 
> VM> By default MTU-Probe and ACK will be unicast. It could be
> configured to do it a different way. A reason MTU-probe could be
> multicast is when a new device first joins a link, which already has
> Rbridges attached.

I have not found any statement in any of the relevant TRILL documents that states "unicast is the default". Apologies if I missed it.

That said, on a LAN it would be more efficient for the DRB to multicast the probes, non-DRB to unicast probes to the DRB only, and all ACKS be multicast.

> 
> If an MTU-ACK is sent to multicast address what should the receivers
> who
> did not initiate the probe do with the ACK? Ignore? Process?
> VM> It is processed.
> 
> On a LAN should MTU probes only be sent to/from the DRB when pseudo-
> node
> bypass is NOT set? It seems useless to do otherwise - but this is not
> discussed.
> 
> Also, don't you need PORT ID in the Probe Source/ACK Source in the MTU
> PDU
> to fully identify the source/responder?
> 
> It would have been better in terms of use of the limited PDU type space
> to
> define only one new PDU type and encode the probe/ack inside of the
> PDU.
> 
> Also, this particular area exemplifies how difficult it is to come to a
> full understanding of proper behavior. [TRILL] must be consulted to
> find
> a description of how to send the PDUs, [RFCtisis] must be consulted to
> find
> the PDU code points and formats, and the TRILL-adj document must be
> consulted
> to find a description of how to incorporate MTU test results into the
> hello process.
> 
> Section 6
> -----------
> 
> I find the discussion of what RBs should do when the bypass bit is
> set/not
> set unclear. The intent is for RBs to advertise neighbors in Report
> state
> in their non-pseudo-node LSPs when the Bypass bit is set - and to
> advertise
> the neighbor to the pseudo-node when Bypass bit is NOT set - but the
> wording used
> 
> "directly report their adjacencies"
> 
> isn't as clear as it could be.
> 
> Also, I assume that when advertising the neighbor to the pseudo-node,
> the state
>  (2-way or Report) is inherited from the state of the adjacency to the
> DRB? A
> clear satement of this would be helpful.
> VM> Clarity could be added.
> 
> Section 7.2
> ------------
> Is IIH padding ignored on receipt?? Or is a padded IIH discarded?
> 
> In regards to what TLVs should be in an IIH, the text says:
> 
>    If there are no adjacencies with a non-zero Designated VLAN Hello
>    Holding timer, an empty TRILL Neighbor TLV MUST be included in each
>    Hello.  If there are such adjacencies, then the Hello MAY contain a
>    TRILL Neighbor TLV as described in Section 4.4.2.1 of [RFCtrill].
> 
> The Neighbor TLV is ONLY used to report neighbors I have
> seen in IIHs received on the D-VLAN and if I have NO such neighbors I
> MUST
> send an empty neighbor TLV - but if I do have one or more such
> neighbors
> then sending a neighbor TLV is optional??? What is the motivation for
> this?
> VM> The idea is we should not pad, because packets may not get through
> due to difference in MTU. However if it is received I think there is
> no reason to do anything different for it.

In regards to padding, I agree - but would like to see an explicit statement.

You have not commented on the motivation for omitting a neighbor TLV from a hello when adjacencies are present.

   Les


> 
> Thanks,
> Vishwas
> 
> On Thu, Jan 13, 2011 at 5:36 PM, Les Ginsberg (ginsberg)
> <ginsberg at cisco.com> wrote:
> > (resending w corrected TRILL WG address)
> >
> > Attached please find my comments on draft-ietf-trill-adj-01.
> >
> > The file draft-ietf-trill-adj-01_comments.txt contains substantive
> > comments identified by Section # - except in a couple of cases where
> the
> > remarks are more generic.
> >
> > The file draft-ietf-trill-adj-01_editorial.txt is portions of the
> draft
> > annotated with editorial comments. Search for "LES:" in the file.
> >
> > As context, the requirements of [TRILL] introduce the need to send a
> > great deal more circuit scoped information on a LAN as compared to
> Layer
> > 3 IS-IS. Extensions to the IS-IS protocol defined in [TRILL],
> > [TRILL-ISIS], and [TRILL-ADJ] are designed to support this new
> > information and to provide robust loop prevention in the forwarding
> of
> > data. But I believe the extensions as currently defined have
> significant
> > scalability issues in the presence of a large number of neighbors on
> a
> > LAN and/or a large number of enabled VLANs. In my comments I have
> > confined myself to pointing out where I believe such issues arise. If
> > there is consensus that these are issues which should be addressed,
> then
> > additional discussions can be started as to how to do so.
> >
> > Finally, I would like to thank the authors of draft-ietf-trill-adj-01
> > for the effort and diligence they obviously applied to the writing of
> > this draft.
> >
> > ? Les
> >
> >
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> >


From vishwas.ietf at gmail.com  Fri Jan 14 10:17:14 2011
From: vishwas.ietf at gmail.com (Vishwas Manral)
Date: Fri, 14 Jan 2011 10:17:14 -0800
Subject: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <AE36820147909644AD2A7CA014B1FB520D0DF658@xmb-sjc-222.amer.cisco.com>
References: <4D221B2B.2020207@acm.org>
	<AE36820147909644AD2A7CA014B1FB520D0DF50D@xmb-sjc-222.amer.cisco.com>
	<AANLkTikKAD86kLWo7w9ExcsNWAtu9y4Zv0cmCg=qz+uM@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520D0DF658@xmb-sjc-222.amer.cisco.com>
Message-ID: <AANLkTim2Zyx_NTHxm35K6b5gseMkO4RR-9um4b-YL=Wt@mail.gmail.com>

Hi Les,

Good we are nearly on the same page regarding most of it.

>> VM> One way to do it will be to send it Hello Multiplier + 1 times in
>> the Hello. If a neighbor misses all the Hellos it will anyway bring
>> down its adjacency and it will be noticed, otherwise the information
>> will be reliably exchanged.
>
> This only works (with some caveats) in the case where the complete set of Appointed Forwarder information is contained within a single hello. But in large scale deployments it is likely that each hello will only contain a subset of the appointed forwarder information, in which case the strategy you suggest only guarantees that at least one of the subsets has been seen by the neighbor.

VM> I agree, with the information in more then one Hello (which should
not be a very common case) we may have to send the information more
times. That said in most Layer-2 protocols, just sending an
information like 3 times is treated as reliable sending.

>> Preventing Multiple DRBs on a LAN
>> ---------------------------------
>>
>> It is not clear to me how the use of multiple announcing VLANs achieves
>> the stated goal of one and only one DRB in the presence of inconsistent
>> connectivity / configuration.
>> VM> Les it is stated that:
>>
>> ?Designated VLAN: the VLAN being used on the link for all TRILL frames
>> except some TRILL Hellos. ?This is RBn's Desired Designated VLAN if
>> RBn believes it is the DRB or the Designated VLAN in the DRB's Hellos
>> if RBn is not the DRB.
>>
>> This means is that there is atleast one VLAN which is common to all
>> devices on the link. The example you have given above would be a
>> configuration issue. The protocol does not deal with configuration
>> issues.
> Misconfiguration is not what the example is trying to show. All VLANs are enabled on all RBs in the example above, but there is a connectivity issue on VLANS 2,3 for RB2. This is obviously a pathological case, but as [TRILL] emphasizes the importance of being able to handle such cases I am simply demonstrating that the extensions are not able to deal with all cases.
>
> If we can assume that there are never any connectivity issues and - as you say - the protocol "does not deal with configuration issues", then sending hellos on one VLAN would be sufficient - but the concern throughout all of the TRILL documents is that such an assumption is not safe.

VM> I think the idea is that we need to do things for most of the
cases. However there might be a very minor percentage(.0001%) of the
cases where things may not work. That however does not mean we leave
it as best effort.


> I do think more clarity would be desirable.
> Can you comment on the second point regarding in what "DRB election state" (NOT neighbor state) neighbors are advertised?
VM> Neighbors are still advertized after the 2-way state. BTW, IS-Is
does not itself deal with corner cases. So unlike OSPF where the
entire data base needs to be acknowledged before a neighbor is
advertized in the LS information, in IS-Is we advertize it before,
which could always lead to the case you mention. On Broadcast links
CSNP's are periodically advertized, if I remember it right.

>> VM> By default MTU-Probe and ACK will be unicast. It could be
>> configured to do it a different way. A reason MTU-probe could be
>> multicast is when a new device first joins a link, which already has
>> Rbridges attached.
>
> I have not found any statement in any of the relevant TRILL documents that states "unicast is the default". Apologies if I missed it.
>
> That said, on a LAN it would be more efficient for the DRB to multicast the probes, non-DRB to unicast probes to the DRB only, and all ACKS be multicast.

VM> I agree with you. It is left to an implementation to decide how to do it.

>> VM> The idea is we should not pad, because packets may not get through
>> due to difference in MTU. However if it is received I think there is
>> no reason to do anything different for it.
>
> In regards to padding, I agree - but would like to see an explicit statement.

VM> Ok.

> You have not commented on the motivation for omitting a neighbor TLV from a hello when adjacencies are present.
VM> I think the intent is the reverse.  If we have Neighbors and after
adjacency down we do not have any adjacencies, the aim is to still
send the Hello to the neighbor stating that there are no other
neighbors remaining.

Thanks,
Vishwas

>>
>> On Thu, Jan 13, 2011 at 5:36 PM, Les Ginsberg (ginsberg)
>> <ginsberg at cisco.com> wrote:
>> > (resending w corrected TRILL WG address)
>> >
>> > Attached please find my comments on draft-ietf-trill-adj-01.
>> >
>> > The file draft-ietf-trill-adj-01_comments.txt contains substantive
>> > comments identified by Section # - except in a couple of cases where
>> the
>> > remarks are more generic.
>> >
>> > The file draft-ietf-trill-adj-01_editorial.txt is portions of the
>> draft
>> > annotated with editorial comments. Search for "LES:" in the file.
>> >
>> > As context, the requirements of [TRILL] introduce the need to send a
>> > great deal more circuit scoped information on a LAN as compared to
>> Layer
>> > 3 IS-IS. Extensions to the IS-IS protocol defined in [TRILL],
>> > [TRILL-ISIS], and [TRILL-ADJ] are designed to support this new
>> > information and to provide robust loop prevention in the forwarding
>> of
>> > data. But I believe the extensions as currently defined have
>> significant
>> > scalability issues in the presence of a large number of neighbors on
>> a
>> > LAN and/or a large number of enabled VLANs. In my comments I have
>> > confined myself to pointing out where I believe such issues arise. If
>> > there is consensus that these are issues which should be addressed,
>> then
>> > additional discussions can be started as to how to do so.
>> >
>> > Finally, I would like to thank the authors of draft-ietf-trill-adj-01
>> > for the effort and diligence they obviously applied to the writing of
>> > this draft.
>> >
>> > ? Les
>> >
>> >
>> > _______________________________________________
>> > rbridge mailing list
>> > rbridge at postel.org
>> > http://mailman.postel.org/mailman/listinfo/rbridge
>> >
>> >
>


From ginsberg at cisco.com  Fri Jan 14 12:32:45 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Fri, 14 Jan 2011 12:32:45 -0800
Subject: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <AANLkTim2Zyx_NTHxm35K6b5gseMkO4RR-9um4b-YL=Wt@mail.gmail.com>
References: <4D221B2B.2020207@acm.org><AE36820147909644AD2A7CA014B1FB520D0DF50D@xmb-sjc-222.amer.cisco.com><AANLkTikKAD86kLWo7w9ExcsNWAtu9y4Zv0cmCg=qz+uM@mail.gmail.com><AE36820147909644AD2A7CA014B1FB520D0DF658@xmb-sjc-222.amer.cisco.com>
	<AANLkTim2Zyx_NTHxm35K6b5gseMkO4RR-9um4b-YL=Wt@mail.gmail.com>
Message-ID: <AE36820147909644AD2A7CA014B1FB520D0DF816@xmb-sjc-222.amer.cisco.com>

Vishwas -

> -----Original Message-----
> From: Vishwas Manral [mailto:vishwas.ietf at gmail.com]
> Sent: Friday, January 14, 2011 10:17 AM
> To: Les Ginsberg (ginsberg)
> Cc: isis-wg at ietf.org; rbridge at postel.org
> Subject: Re: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
> 
> Hi Les,
> 
> Good we are nearly on the same page regarding most of it.

That is good. :-)

> 
> >> VM> One way to do it will be to send it Hello Multiplier + 1 times
> in
> >> the Hello. If a neighbor misses all the Hellos it will anyway bring
> >> down its adjacency and it will be noticed, otherwise the information
> >> will be reliably exchanged.
> >
> > This only works (with some caveats) in the case where the complete
> set of Appointed Forwarder information is contained within a single
> hello. But in large scale deployments it is likely that each hello will
> only contain a subset of the appointed forwarder information, in which
> case the strategy you suggest only guarantees that at least one of the
> subsets has been seen by the neighbor.
> 
> VM> I agree, with the information in more then one Hello (which should
> not be a very common case) we may have to send the information more
> times. That said in most Layer-2 protocols, just sending an
> information like 3 times is treated as reliable sending.

So you agree there is an issue that needs to be addressed? I hope so - because otherwise we have a specification that is not guaranteed to work all the time.

> 
> >> Preventing Multiple DRBs on a LAN
> >> ---------------------------------
> >>
> >> It is not clear to me how the use of multiple announcing VLANs
> achieves
> >> the stated goal of one and only one DRB in the presence of
> inconsistent
> >> connectivity / configuration.
> >> VM> Les it is stated that:
> >>
> >> ?Designated VLAN: the VLAN being used on the link for all TRILL
> frames
> >> except some TRILL Hellos. ?This is RBn's Desired Designated VLAN if
> >> RBn believes it is the DRB or the Designated VLAN in the DRB's
> Hellos
> >> if RBn is not the DRB.
> >>
> >> This means is that there is atleast one VLAN which is common to all
> >> devices on the link. The example you have given above would be a
> >> configuration issue. The protocol does not deal with configuration
> >> issues.
> > Misconfiguration is not what the example is trying to show. All VLANs
> are enabled on all RBs in the example above, but there is a
> connectivity issue on VLANS 2,3 for RB2. This is obviously a
> pathological case, but as [TRILL] emphasizes the importance of being
> able to handle such cases I am simply demonstrating that the extensions
> are not able to deal with all cases.
> >
> > If we can assume that there are never any connectivity issues and -
> as you say - the protocol "does not deal with configuration issues",
> then sending hellos on one VLAN would be sufficient - but the concern
> throughout all of the TRILL documents is that such an assumption is not
> safe.
> 
> VM> I think the idea is that we need to do things for most of the
> cases. However there might be a very minor percentage(.0001%) of the
> cases where things may not work. That however does not mean we leave
> it as best effort.
> 

OK - so we agree this is an issue which needs to be addressed it seems.

> 
> > I do think more clarity would be desirable.
> > Can you comment on the second point regarding in what "DRB election
> state" (NOT neighbor state) neighbors are advertised?
> VM> Neighbors are still advertized after the 2-way state. BTW, IS-Is
> does not itself deal with corner cases. So unlike OSPF where the
> entire data base needs to be acknowledged before a neighbor is
> advertized in the LS information, in IS-Is we advertize it before,
> which could always lead to the case you mention. On Broadcast links
> CSNP's are periodically advertized, if I remember it right.

TRILL makes no changes to the Update Process - which has been proven reliable - so LSP flooding/CSNP usage is not relevant. My question is regarding in what "DRB election state" a neighbor should be advertised in LSPs. The draft specifies that when in "pre-DRB" state there is a pre-forwarding timer running and we are inhibited from ingressing/egressing native frames. If we were to advertise neighbors in LSPs while in pre-DRB state we would therefore be attracting traffic that we cannot deliver for some significant number of seconds. I am asking for more explicit definition of when neighbor advertisements should be added to LSPs. Clearly an adjacency must be in Report State for that to happen - but I think the DRB election state is also relevant and I don't think that is clearly specified.

> 
> >> VM> By default MTU-Probe and ACK will be unicast. It could be
> >> configured to do it a different way. A reason MTU-probe could be
> >> multicast is when a new device first joins a link, which already has
> >> Rbridges attached.
> >
> > I have not found any statement in any of the relevant TRILL documents
> that states "unicast is the default". Apologies if I missed it.
> >
> > That said, on a LAN it would be more efficient for the DRB to
> multicast the probes, non-DRB to unicast probes to the DRB only, and
> all ACKS be multicast.
> 
> VM> I agree with you. It is left to an implementation to decide how to
> do it.

OK. I do think some guidance would be good as the use of MTU PDUs is an entirely new functionality.

> 
> >> VM> The idea is we should not pad, because packets may not get
> through
> >> due to difference in MTU. However if it is received I think there is
> >> no reason to do anything different for it.
> >
> > In regards to padding, I agree - but would like to see an explicit
> statement.
> 
> VM> Ok.
> 
> > You have not commented on the motivation for omitting a neighbor TLV
> from a hello when adjacencies are present.
> VM> I think the intent is the reverse.  If we have Neighbors and after
> adjacency down we do not have any adjacencies, the aim is to still
> send the Hello to the neighbor stating that there are no other
> neighbors remaining.
> 

To requote the draft:

" If there are no adjacencies with a non-zero Designated VLAN Hello
   Holding timer, an empty TRILL Neighbor TLV MUST be included in each
   Hello.  If there are such adjacencies, then the Hello MAY contain a
   TRILL Neighbor TLV..."

I understand the motivation for an explicit "no neighbors" advertisement - but I am asking why you want to make inclusion of TRILL Neighbor TLV optional when you do have adjacencies?

   Les

> Thanks,
> Vishwas
> 
> >>
> >> On Thu, Jan 13, 2011 at 5:36 PM, Les Ginsberg (ginsberg)
> >> <ginsberg at cisco.com> wrote:
> >> > (resending w corrected TRILL WG address)
> >> >
> >> > Attached please find my comments on draft-ietf-trill-adj-01.
> >> >
> >> > The file draft-ietf-trill-adj-01_comments.txt contains substantive
> >> > comments identified by Section # - except in a couple of cases
> where
> >> the
> >> > remarks are more generic.
> >> >
> >> > The file draft-ietf-trill-adj-01_editorial.txt is portions of the
> >> draft
> >> > annotated with editorial comments. Search for "LES:" in the file.
> >> >
> >> > As context, the requirements of [TRILL] introduce the need to send
> a
> >> > great deal more circuit scoped information on a LAN as compared to
> >> Layer
> >> > 3 IS-IS. Extensions to the IS-IS protocol defined in [TRILL],
> >> > [TRILL-ISIS], and [TRILL-ADJ] are designed to support this new
> >> > information and to provide robust loop prevention in the
> forwarding
> >> of
> >> > data. But I believe the extensions as currently defined have
> >> significant
> >> > scalability issues in the presence of a large number of neighbors
> on
> >> a
> >> > LAN and/or a large number of enabled VLANs. In my comments I have
> >> > confined myself to pointing out where I believe such issues arise.
> If
> >> > there is consensus that these are issues which should be
> addressed,
> >> then
> >> > additional discussions can be started as to how to do so.
> >> >
> >> > Finally, I would like to thank the authors of draft-ietf-trill-
> adj-01
> >> > for the effort and diligence they obviously applied to the writing
> of
> >> > this draft.
> >> >
> >> > ? Les
> >> >
> >> >
> >> > _______________________________________________
> >> > rbridge mailing list
> >> > rbridge at postel.org
> >> > http://mailman.postel.org/mailman/listinfo/rbridge
> >> >
> >> >
> >


From vishwas.ietf at gmail.com  Fri Jan 14 12:43:46 2011
From: vishwas.ietf at gmail.com (Vishwas Manral)
Date: Fri, 14 Jan 2011 12:43:46 -0800
Subject: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <AE36820147909644AD2A7CA014B1FB520D0DF816@xmb-sjc-222.amer.cisco.com>
References: <4D221B2B.2020207@acm.org>
	<AE36820147909644AD2A7CA014B1FB520D0DF50D@xmb-sjc-222.amer.cisco.com>
	<AANLkTikKAD86kLWo7w9ExcsNWAtu9y4Zv0cmCg=qz+uM@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520D0DF658@xmb-sjc-222.amer.cisco.com>
	<AANLkTim2Zyx_NTHxm35K6b5gseMkO4RR-9um4b-YL=Wt@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520D0DF816@xmb-sjc-222.amer.cisco.com>
Message-ID: <AANLkTi=h-+9evvY7z0w1eV2xXNpwTvkDLqNFoGb_EVhA@mail.gmail.com>

Hi Les,

VM> One way to do it will be to send it Hello Multiplier + 1 times
>> in
>> >> the Hello. If a neighbor misses all the Hellos it will anyway bring
>> >> down its adjacency and it will be noticed, otherwise the information
>> >> will be reliably exchanged.
>> >
>> > This only works (with some caveats) in the case where the complete
>> set of Appointed Forwarder information is contained within a single
>> hello. But in large scale deployments it is likely that each hello will
>> only contain a subset of the appointed forwarder information, in which
>> case the strategy you suggest only guarantees that at least one of the
>> subsets has been seen by the neighbor.
>>
>> VM> I agree, with the information in more then one Hello (which should
>> not be a very common case) we may have to send the information more
>> times. That said in most Layer-2 protocols, just sending an
>> information like 3 times is treated as reliable sending.
>
> So you agree there is an issue that needs to be addressed? I hope so - because otherwise we have a specification that is not guaranteed to work all the time.
VM> I think things can be done better and needs to be looked at, but
it should not block the work of the current draft.

>> VM> I think the idea is that we need to do things for most of the
>> cases. However there might be a very minor percentage(.0001%) of the
>> cases where things may not work. That however does not mean we leave
>> it as best effort.
> OK - so we agree this is an issue which needs to be addressed it seems.
VM> Again same as above.

>> > I do think more clarity would be desirable.
>> > Can you comment on the second point regarding in what "DRB election
>> state" (NOT neighbor state) neighbors are advertised?
>> VM> Neighbors are still advertized after the 2-way state. BTW, IS-Is
>> does not itself deal with corner cases. So unlike OSPF where the
>> entire data base needs to be acknowledged before a neighbor is
>> advertized in the LS information, in IS-Is we advertize it before,
>> which could always lead to the case you mention. On Broadcast links
>> CSNP's are periodically advertized, if I remember it right.
>
> TRILL makes no changes to the Update Process - which has been proven reliable - so LSP flooding/CSNP usage is not relevant. My question is regarding in what "DRB election state" a neighbor should be advertised in LSPs. The draft specifies that when in "pre-DRB" state there is a pre-forwarding timer running and we are inhibited from ingressing/egressing native frames. If we were to advertise neighbors in LSPs while in pre-DRB state we would therefore be attracting traffic that we cannot deliver for some significant number of seconds. I am asking for more explicit definition of when neighbor advertisements should be added to LSPs. Clearly an adjacency must be in Report State for that to happen - but I think the DRB election state is also relevant and I don't think that is clearly specified.
VM> Like I mentioned the neighbor advertizement should not change from IS-IS.

>> VM> I agree with you. It is left to an implementation to decide how to
>> do it.
>
> OK. I do think some guidance would be good as the use of MTU PDUs is an entirely new functionality.
VM> A clarification could be added.

> To requote the draft:
>
> " If there are no adjacencies with a non-zero Designated VLAN Hello
> ? Holding timer, an empty TRILL Neighbor TLV MUST be included in each
> ? Hello. ?If there are such adjacencies, then the Hello MAY contain a
> ? TRILL Neighbor TLV..."
>
> I understand the motivation for an explicit "no neighbors" advertisement - but I am asking why you want to make inclusion of TRILL Neighbor TLV optional when you do have adjacencies?
VM> This can again be treated in the context of the fact that if the
data does not fit in one Hello, we could send the other data in the
other Hello, and include empty TRILL Neighbor TLV. It could also be
treated in the context of the fact that we should allow receiving the
empty TLV.

I know this could be removed by itself, as there is no harm or benefit
of the same, based on how the spec stands, however it could help to
state that for some future use like mentioned above.

Thanks,
Vishwas

>> >>
>> >> On Thu, Jan 13, 2011 at 5:36 PM, Les Ginsberg (ginsberg)
>> >> <ginsberg at cisco.com> wrote:
>> >> > (resending w corrected TRILL WG address)
>> >> >
>> >> > Attached please find my comments on draft-ietf-trill-adj-01.
>> >> >
>> >> > The file draft-ietf-trill-adj-01_comments.txt contains substantive
>> >> > comments identified by Section # - except in a couple of cases
>> where
>> >> the
>> >> > remarks are more generic.
>> >> >
>> >> > The file draft-ietf-trill-adj-01_editorial.txt is portions of the
>> >> draft
>> >> > annotated with editorial comments. Search for "LES:" in the file.
>> >> >
>> >> > As context, the requirements of [TRILL] introduce the need to send
>> a
>> >> > great deal more circuit scoped information on a LAN as compared to
>> >> Layer
>> >> > 3 IS-IS. Extensions to the IS-IS protocol defined in [TRILL],
>> >> > [TRILL-ISIS], and [TRILL-ADJ] are designed to support this new
>> >> > information and to provide robust loop prevention in the
>> forwarding
>> >> of
>> >> > data. But I believe the extensions as currently defined have
>> >> significant
>> >> > scalability issues in the presence of a large number of neighbors
>> on
>> >> a
>> >> > LAN and/or a large number of enabled VLANs. In my comments I have
>> >> > confined myself to pointing out where I believe such issues arise.
>> If
>> >> > there is consensus that these are issues which should be
>> addressed,
>> >> then
>> >> > additional discussions can be started as to how to do so.
>> >> >
>> >> > Finally, I would like to thank the authors of draft-ietf-trill-
>> adj-01
>> >> > for the effort and diligence they obviously applied to the writing
>> of
>> >> > this draft.
>> >> >
>> >> > ? Les
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > rbridge mailing list
>> >> > rbridge at postel.org
>> >> > http://mailman.postel.org/mailman/listinfo/rbridge
>> >> >
>> >> >
>> >
>


From ginsberg at cisco.com  Fri Jan 14 13:51:32 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Fri, 14 Jan 2011 13:51:32 -0800
Subject: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <AANLkTi=h-+9evvY7z0w1eV2xXNpwTvkDLqNFoGb_EVhA@mail.gmail.com>
References: <4D221B2B.2020207@acm.org><AE36820147909644AD2A7CA014B1FB520D0DF50D@xmb-sjc-222.amer.cisco.com><AANLkTikKAD86kLWo7w9ExcsNWAtu9y4Zv0cmCg=qz+uM@mail.gmail.com><AE36820147909644AD2A7CA014B1FB520D0DF658@xmb-sjc-222.amer.cisco.com><AANLkTim2Zyx_NTHxm35K6b5gseMkO4RR-9um4b-YL=Wt@mail.gmail.com><AE36820147909644AD2A7CA014B1FB520D0DF816@xmb-sjc-222.amer.cisco.com>
	<AANLkTi=h-+9evvY7z0w1eV2xXNpwTvkDLqNFoGb_EVhA@mail.gmail.com>
Message-ID: <AE36820147909644AD2A7CA014B1FB520D0DF884@xmb-sjc-222.amer.cisco.com>

Vishwas -

> -----Original Message-----
> From: Vishwas Manral [mailto:vishwas.ietf at gmail.com]
> Sent: Friday, January 14, 2011 12:44 PM
> To: Les Ginsberg (ginsberg)
> Cc: isis-wg at ietf.org; rbridge at postel.org
> Subject: Re: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
> 
> Hi Les,
> 
> VM> One way to do it will be to send it Hello Multiplier + 1 times
> >> in
> >> >> the Hello. If a neighbor misses all the Hellos it will anyway
> bring
> >> >> down its adjacency and it will be noticed, otherwise the
> information
> >> >> will be reliably exchanged.
> >> >
> >> > This only works (with some caveats) in the case where the complete
> >> set of Appointed Forwarder information is contained within a single
> >> hello. But in large scale deployments it is likely that each hello
> will
> >> only contain a subset of the appointed forwarder information, in
> which
> >> case the strategy you suggest only guarantees that at least one of
> the
> >> subsets has been seen by the neighbor.
> >>
> >> VM> I agree, with the information in more then one Hello (which
> should
> >> not be a very common case) we may have to send the information more
> >> times. That said in most Layer-2 protocols, just sending an
> >> information like 3 times is treated as reliable sending.
> >
> > So you agree there is an issue that needs to be addressed? I hope so
> - because otherwise we have a specification that is not guaranteed to
> work all the time.
> VM> I think things can be done better and needs to be looked at, but
> it should not block the work of the current draft.

This seems very basic to correct operation i.e having introduced the support for sending subsets of the information in a given hello it seems that it is necessary to solve the problem of how to guarantee delivery of the full set of information. 

The only way to provide reliability under the current specification is to send the information all the time. This guarantees that the information will be received "eventually" - but also means convergence time is lengthy and indeterminate - and it places a burden on both sender and receiver to continually process information which changes rarely. And this burden becomes worse as the number of VLANs/neighbors increases. 

Potential solutions will likely not be backwards compatible. So to suggest that we defer this issue means that at some later date (perhaps) a new version of the specification will come out which addresses the issues but it will not interoperate with existing versions. And since the issues here are related to scale - and currently there is no defined solution - I would expect that folks who intend to deploy TRILL would be quite correctly very concerned about this.

> 
> >> VM> I think the idea is that we need to do things for most of the
> >> cases. However there might be a very minor percentage(.0001%) of the
> >> cases where things may not work. That however does not mean we leave
> >> it as best effort.
> > OK - so we agree this is an issue which needs to be addressed it
> seems.
> VM> Again same as above.

And my response is again the same as above. :-)
You have snipped out the context for this, so let me remind that this issue concerns correct operation in the event of pathological connectivity issues. The more relevant point is one that I made earlier:

<snip>
If we can assume that there are never any connectivity issues and - as you say - the protocol "does not deal with configuration issues", then sending hellos on one VLAN would be sufficient - but the concern throughout all of the TRILL documents is that such an assumption is not safe.
<end snip>

The justification for the extensions that have been defined becomes very weak if they do not actually reliably solve the problem they were designed to address. 

> 
> >> > I do think more clarity would be desirable.
> >> > Can you comment on the second point regarding in what "DRB
> election
> >> state" (NOT neighbor state) neighbors are advertised?
> >> VM> Neighbors are still advertized after the 2-way state. BTW, IS-Is
> >> does not itself deal with corner cases. So unlike OSPF where the
> >> entire data base needs to be acknowledged before a neighbor is
> >> advertized in the LS information, in IS-Is we advertize it before,
> >> which could always lead to the case you mention. On Broadcast links
> >> CSNP's are periodically advertized, if I remember it right.
> >
> > TRILL makes no changes to the Update Process - which has been proven
> reliable - so LSP flooding/CSNP usage is not relevant. My question is
> regarding in what "DRB election state" a neighbor should be advertised
> in LSPs. The draft specifies that when in "pre-DRB" state there is a
> pre-forwarding timer running and we are inhibited from
> ingressing/egressing native frames. If we were to advertise neighbors
> in LSPs while in pre-DRB state we would therefore be attracting traffic
> that we cannot deliver for some significant number of seconds. I am
> asking for more explicit definition of when neighbor advertisements
> should be added to LSPs. Clearly an adjacency must be in Report State
> for that to happen - but I think the DRB election state is also
> relevant and I don't think that is clearly specified.
> VM> Like I mentioned the neighbor advertizement should not change from
> IS-IS.

This does not answer my question. :-(

   Les

> 
> >> VM> I agree with you. It is left to an implementation to decide how
> to
> >> do it.
> >
> > OK. I do think some guidance would be good as the use of MTU PDUs is
> an entirely new functionality.
> VM> A clarification could be added.
> 
> > To requote the draft:
> >
> > " If there are no adjacencies with a non-zero Designated VLAN Hello
> > ? Holding timer, an empty TRILL Neighbor TLV MUST be included in each
> > ? Hello. ?If there are such adjacencies, then the Hello MAY contain a
> > ? TRILL Neighbor TLV..."
> >
> > I understand the motivation for an explicit "no neighbors"
> advertisement - but I am asking why you want to make inclusion of TRILL
> Neighbor TLV optional when you do have adjacencies?
> VM> This can again be treated in the context of the fact that if the
> data does not fit in one Hello, we could send the other data in the
> other Hello, and include empty TRILL Neighbor TLV. It could also be
> treated in the context of the fact that we should allow receiving the
> empty TLV.
> 
> I know this could be removed by itself, as there is no harm or benefit
> of the same, based on how the spec stands, however it could help to
> state that for some future use like mentioned above.
> 
> Thanks,
> Vishwas
> 
> >> >>
> >> >> On Thu, Jan 13, 2011 at 5:36 PM, Les Ginsberg (ginsberg)
> >> >> <ginsberg at cisco.com> wrote:
> >> >> > (resending w corrected TRILL WG address)
> >> >> >
> >> >> > Attached please find my comments on draft-ietf-trill-adj-01.
> >> >> >
> >> >> > The file draft-ietf-trill-adj-01_comments.txt contains
> substantive
> >> >> > comments identified by Section # - except in a couple of cases
> >> where
> >> >> the
> >> >> > remarks are more generic.
> >> >> >
> >> >> > The file draft-ietf-trill-adj-01_editorial.txt is portions of
> the
> >> >> draft
> >> >> > annotated with editorial comments. Search for "LES:" in the
> file.
> >> >> >
> >> >> > As context, the requirements of [TRILL] introduce the need to
> send
> >> a
> >> >> > great deal more circuit scoped information on a LAN as compared
> to
> >> >> Layer
> >> >> > 3 IS-IS. Extensions to the IS-IS protocol defined in [TRILL],
> >> >> > [TRILL-ISIS], and [TRILL-ADJ] are designed to support this new
> >> >> > information and to provide robust loop prevention in the
> >> forwarding
> >> >> of
> >> >> > data. But I believe the extensions as currently defined have
> >> >> significant
> >> >> > scalability issues in the presence of a large number of
> neighbors
> >> on
> >> >> a
> >> >> > LAN and/or a large number of enabled VLANs. In my comments I
> have
> >> >> > confined myself to pointing out where I believe such issues
> arise.
> >> If
> >> >> > there is consensus that these are issues which should be
> >> addressed,
> >> >> then
> >> >> > additional discussions can be started as to how to do so.
> >> >> >
> >> >> > Finally, I would like to thank the authors of draft-ietf-trill-
> >> adj-01
> >> >> > for the effort and diligence they obviously applied to the
> writing
> >> of
> >> >> > this draft.
> >> >> >
> >> >> > ? Les
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > rbridge mailing list
> >> >> > rbridge at postel.org
> >> >> > http://mailman.postel.org/mailman/listinfo/rbridge
> >> >> >
> >> >> >
> >> >
> >


From vishwas.ietf at gmail.com  Fri Jan 14 14:25:24 2011
From: vishwas.ietf at gmail.com (Vishwas Manral)
Date: Fri, 14 Jan 2011 14:25:24 -0800
Subject: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <AE36820147909644AD2A7CA014B1FB520D0DF884@xmb-sjc-222.amer.cisco.com>
References: <4D221B2B.2020207@acm.org>
	<AE36820147909644AD2A7CA014B1FB520D0DF50D@xmb-sjc-222.amer.cisco.com>
	<AANLkTikKAD86kLWo7w9ExcsNWAtu9y4Zv0cmCg=qz+uM@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520D0DF658@xmb-sjc-222.amer.cisco.com>
	<AANLkTim2Zyx_NTHxm35K6b5gseMkO4RR-9um4b-YL=Wt@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520D0DF816@xmb-sjc-222.amer.cisco.com>
	<AANLkTi=h-+9evvY7z0w1eV2xXNpwTvkDLqNFoGb_EVhA@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520D0DF884@xmb-sjc-222.amer.cisco.com>
Message-ID: <AANLkTi=c9ZLQa53CzV1yZnW0J2ncfFdgbeZZ2mzFduRh@mail.gmail.com>

Hi Les,

You have good comments.

Like I said we could send the same information multiple times to
assume the information has reached its neighbor. If the information is
in one Hello we already have the solution.

I agree this can be improved, however I feel we do not need to do
every optimization at this point.

Thanks,
Vishwas

>>
>> >> VM> I agree with you. It is left to an implementation to decide how
>> to
>> >> do it.
>> >
>> > OK. I do think some guidance would be good as the use of MTU PDUs is
>> an entirely new functionality.
>> VM> A clarification could be added.
>>
>> > To requote the draft:
>> >
>> > " If there are no adjacencies with a non-zero Designated VLAN Hello
>> > ? Holding timer, an empty TRILL Neighbor TLV MUST be included in each
>> > ? Hello. ?If there are such adjacencies, then the Hello MAY contain a
>> > ? TRILL Neighbor TLV..."
>> >
>> > I understand the motivation for an explicit "no neighbors"
>> advertisement - but I am asking why you want to make inclusion of TRILL
>> Neighbor TLV optional when you do have adjacencies?
>> VM> This can again be treated in the context of the fact that if the
>> data does not fit in one Hello, we could send the other data in the
>> other Hello, and include empty TRILL Neighbor TLV. It could also be
>> treated in the context of the fact that we should allow receiving the
>> empty TLV.
>>
>> I know this could be removed by itself, as there is no harm or benefit
>> of the same, based on how the spec stands, however it could help to
>> state that for some future use like mentioned above.
>>
>> Thanks,
>> Vishwas
>>
>> >> >>
>> >> >> On Thu, Jan 13, 2011 at 5:36 PM, Les Ginsberg (ginsberg)
>> >> >> <ginsberg at cisco.com> wrote:
>> >> >> > (resending w corrected TRILL WG address)
>> >> >> >
>> >> >> > Attached please find my comments on draft-ietf-trill-adj-01.
>> >> >> >
>> >> >> > The file draft-ietf-trill-adj-01_comments.txt contains
>> substantive
>> >> >> > comments identified by Section # - except in a couple of cases
>> >> where
>> >> >> the
>> >> >> > remarks are more generic.
>> >> >> >
>> >> >> > The file draft-ietf-trill-adj-01_editorial.txt is portions of
>> the
>> >> >> draft
>> >> >> > annotated with editorial comments. Search for "LES:" in the
>> file.
>> >> >> >
>> >> >> > As context, the requirements of [TRILL] introduce the need to
>> send
>> >> a
>> >> >> > great deal more circuit scoped information on a LAN as compared
>> to
>> >> >> Layer
>> >> >> > 3 IS-IS. Extensions to the IS-IS protocol defined in [TRILL],
>> >> >> > [TRILL-ISIS], and [TRILL-ADJ] are designed to support this new
>> >> >> > information and to provide robust loop prevention in the
>> >> forwarding
>> >> >> of
>> >> >> > data. But I believe the extensions as currently defined have
>> >> >> significant
>> >> >> > scalability issues in the presence of a large number of
>> neighbors
>> >> on
>> >> >> a
>> >> >> > LAN and/or a large number of enabled VLANs. In my comments I
>> have
>> >> >> > confined myself to pointing out where I believe such issues
>> arise.
>> >> If
>> >> >> > there is consensus that these are issues which should be
>> >> addressed,
>> >> >> then
>> >> >> > additional discussions can be started as to how to do so.
>> >> >> >
>> >> >> > Finally, I would like to thank the authors of draft-ietf-trill-
>> >> adj-01
>> >> >> > for the effort and diligence they obviously applied to the
>> writing
>> >> of
>> >> >> > this draft.
>> >> >> >
>> >> >> > ? Les
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > rbridge mailing list
>> >> >> > rbridge at postel.org
>> >> >> > http://mailman.postel.org/mailman/listinfo/rbridge
>> >> >> >
>> >> >> >
>> >> >
>> >
>


From vishwas.ietf at gmail.com  Fri Jan 14 14:25:24 2011
From: vishwas.ietf at gmail.com (Vishwas Manral)
Date: Fri, 14 Jan 2011 14:25:24 -0800
Subject: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <AE36820147909644AD2A7CA014B1FB520D0DF884@xmb-sjc-222.amer.cisco.com>
References: <4D221B2B.2020207@acm.org>
	<AE36820147909644AD2A7CA014B1FB520D0DF50D@xmb-sjc-222.amer.cisco.com>
	<AANLkTikKAD86kLWo7w9ExcsNWAtu9y4Zv0cmCg=qz+uM@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520D0DF658@xmb-sjc-222.amer.cisco.com>
	<AANLkTim2Zyx_NTHxm35K6b5gseMkO4RR-9um4b-YL=Wt@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520D0DF816@xmb-sjc-222.amer.cisco.com>
	<AANLkTi=h-+9evvY7z0w1eV2xXNpwTvkDLqNFoGb_EVhA@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520D0DF884@xmb-sjc-222.amer.cisco.com>
Message-ID: <AANLkTi=c9ZLQa53CzV1yZnW0J2ncfFdgbeZZ2mzFduRh@mail.gmail.com>

Hi Les,

You have good comments.

Like I said we could send the same information multiple times to
assume the information has reached its neighbor. If the information is
in one Hello we already have the solution.

I agree this can be improved, however I feel we do not need to do
every optimization at this point.

Thanks,
Vishwas

>>
>> >> VM> I agree with you. It is left to an implementation to decide how
>> to
>> >> do it.
>> >
>> > OK. I do think some guidance would be good as the use of MTU PDUs is
>> an entirely new functionality.
>> VM> A clarification could be added.
>>
>> > To requote the draft:
>> >
>> > " If there are no adjacencies with a non-zero Designated VLAN Hello
>> > ? Holding timer, an empty TRILL Neighbor TLV MUST be included in each
>> > ? Hello. ?If there are such adjacencies, then the Hello MAY contain a
>> > ? TRILL Neighbor TLV..."
>> >
>> > I understand the motivation for an explicit "no neighbors"
>> advertisement - but I am asking why you want to make inclusion of TRILL
>> Neighbor TLV optional when you do have adjacencies?
>> VM> This can again be treated in the context of the fact that if the
>> data does not fit in one Hello, we could send the other data in the
>> other Hello, and include empty TRILL Neighbor TLV. It could also be
>> treated in the context of the fact that we should allow receiving the
>> empty TLV.
>>
>> I know this could be removed by itself, as there is no harm or benefit
>> of the same, based on how the spec stands, however it could help to
>> state that for some future use like mentioned above.
>>
>> Thanks,
>> Vishwas
>>
>> >> >>
>> >> >> On Thu, Jan 13, 2011 at 5:36 PM, Les Ginsberg (ginsberg)
>> >> >> <ginsberg at cisco.com> wrote:
>> >> >> > (resending w corrected TRILL WG address)
>> >> >> >
>> >> >> > Attached please find my comments on draft-ietf-trill-adj-01.
>> >> >> >
>> >> >> > The file draft-ietf-trill-adj-01_comments.txt contains
>> substantive
>> >> >> > comments identified by Section # - except in a couple of cases
>> >> where
>> >> >> the
>> >> >> > remarks are more generic.
>> >> >> >
>> >> >> > The file draft-ietf-trill-adj-01_editorial.txt is portions of
>> the
>> >> >> draft
>> >> >> > annotated with editorial comments. Search for "LES:" in the
>> file.
>> >> >> >
>> >> >> > As context, the requirements of [TRILL] introduce the need to
>> send
>> >> a
>> >> >> > great deal more circuit scoped information on a LAN as compared
>> to
>> >> >> Layer
>> >> >> > 3 IS-IS. Extensions to the IS-IS protocol defined in [TRILL],
>> >> >> > [TRILL-ISIS], and [TRILL-ADJ] are designed to support this new
>> >> >> > information and to provide robust loop prevention in the
>> >> forwarding
>> >> >> of
>> >> >> > data. But I believe the extensions as currently defined have
>> >> >> significant
>> >> >> > scalability issues in the presence of a large number of
>> neighbors
>> >> on
>> >> >> a
>> >> >> > LAN and/or a large number of enabled VLANs. In my comments I
>> have
>> >> >> > confined myself to pointing out where I believe such issues
>> arise.
>> >> If
>> >> >> > there is consensus that these are issues which should be
>> >> addressed,
>> >> >> then
>> >> >> > additional discussions can be started as to how to do so.
>> >> >> >
>> >> >> > Finally, I would like to thank the authors of draft-ietf-trill-
>> >> adj-01
>> >> >> > for the effort and diligence they obviously applied to the
>> writing
>> >> of
>> >> >> > this draft.
>> >> >> >
>> >> >> > ? Les
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > rbridge mailing list
>> >> >> > rbridge at postel.org
>> >> >> > http://mailman.postel.org/mailman/listinfo/rbridge
>> >> >> >
>> >> >> >
>> >> >
>> >
>


From ginsberg at cisco.com  Fri Jan 14 14:32:35 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Fri, 14 Jan 2011 14:32:35 -0800
Subject: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <AANLkTi=c9ZLQa53CzV1yZnW0J2ncfFdgbeZZ2mzFduRh@mail.gmail.com>
References: <4D221B2B.2020207@acm.org><AE36820147909644AD2A7CA014B1FB520D0DF50D@xmb-sjc-222.amer.cisco.com><AANLkTikKAD86kLWo7w9ExcsNWAtu9y4Zv0cmCg=qz+uM@mail.gmail.com><AE36820147909644AD2A7CA014B1FB520D0DF658@xmb-sjc-222.amer.cisco.com><AANLkTim2Zyx_NTHxm35K6b5gseMkO4RR-9um4b-YL=Wt@mail.gmail.com><AE36820147909644AD2A7CA014B1FB520D0DF816@xmb-sjc-222.amer.cisco.com><AANLkTi=h-+9evvY7z0w1eV2xXNpwTvkDLqNFoGb_EVhA@mail.gmail.com><AE36820147909644AD2A7CA014B1FB520D0DF884@xmb-sjc-222.amer.cisco.com>
	<AANLkTi=c9ZLQa53CzV1yZnW0J2ncfFdgbeZZ2mzFduRh@mail.gmail.com>
Message-ID: <AE36820147909644AD2A7CA014B1FB520D0DF8B6@xmb-sjc-222.amer.cisco.com>

Vishwas -

This isn't an optimization in my view. While things work "most of the time" - when they don't work you run the risk of loops, blackholes, or indeterminate convergence times - as well as very poor scaling behavior - which makes the likelihood of failure greater.

If you think these are all issues which "can be addressed later" then we will simply have to agree to disagree.

   Les

> -----Original Message-----
> From: Vishwas Manral [mailto:vishwas.ietf at gmail.com]
> Sent: Friday, January 14, 2011 2:25 PM
> To: Les Ginsberg (ginsberg)
> Cc: isis-wg at ietf.org; rbridge at postel.org
> Subject: Re: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
> 
> Hi Les,
> 
> You have good comments.
> 
> Like I said we could send the same information multiple times to
> assume the information has reached its neighbor. If the information is
> in one Hello we already have the solution.
> 
> I agree this can be improved, however I feel we do not need to do
> every optimization at this point.
> 
> Thanks,
> Vishwas
> 
> >>
> >> >> VM> I agree with you. It is left to an implementation to decide
> how
> >> to
> >> >> do it.
> >> >
> >> > OK. I do think some guidance would be good as the use of MTU PDUs
> is
> >> an entirely new functionality.
> >> VM> A clarification could be added.
> >>
> >> > To requote the draft:
> >> >
> >> > " If there are no adjacencies with a non-zero Designated VLAN
> Hello
> >> > ? Holding timer, an empty TRILL Neighbor TLV MUST be included in
> each
> >> > ? Hello. ?If there are such adjacencies, then the Hello MAY
> contain a
> >> > ? TRILL Neighbor TLV..."
> >> >
> >> > I understand the motivation for an explicit "no neighbors"
> >> advertisement - but I am asking why you want to make inclusion of
> TRILL
> >> Neighbor TLV optional when you do have adjacencies?
> >> VM> This can again be treated in the context of the fact that if the
> >> data does not fit in one Hello, we could send the other data in the
> >> other Hello, and include empty TRILL Neighbor TLV. It could also be
> >> treated in the context of the fact that we should allow receiving
> the
> >> empty TLV.
> >>
> >> I know this could be removed by itself, as there is no harm or
> benefit
> >> of the same, based on how the spec stands, however it could help to
> >> state that for some future use like mentioned above.
> >>
> >> Thanks,
> >> Vishwas
> >>
> >> >> >>
> >> >> >> On Thu, Jan 13, 2011 at 5:36 PM, Les Ginsberg (ginsberg)
> >> >> >> <ginsberg at cisco.com> wrote:
> >> >> >> > (resending w corrected TRILL WG address)
> >> >> >> >
> >> >> >> > Attached please find my comments on draft-ietf-trill-adj-01.
> >> >> >> >
> >> >> >> > The file draft-ietf-trill-adj-01_comments.txt contains
> >> substantive
> >> >> >> > comments identified by Section # - except in a couple of
> cases
> >> >> where
> >> >> >> the
> >> >> >> > remarks are more generic.
> >> >> >> >
> >> >> >> > The file draft-ietf-trill-adj-01_editorial.txt is portions
> of
> >> the
> >> >> >> draft
> >> >> >> > annotated with editorial comments. Search for "LES:" in the
> >> file.
> >> >> >> >
> >> >> >> > As context, the requirements of [TRILL] introduce the need
> to
> >> send
> >> >> a
> >> >> >> > great deal more circuit scoped information on a LAN as
> compared
> >> to
> >> >> >> Layer
> >> >> >> > 3 IS-IS. Extensions to the IS-IS protocol defined in
> [TRILL],
> >> >> >> > [TRILL-ISIS], and [TRILL-ADJ] are designed to support this
> new
> >> >> >> > information and to provide robust loop prevention in the
> >> >> forwarding
> >> >> >> of
> >> >> >> > data. But I believe the extensions as currently defined have
> >> >> >> significant
> >> >> >> > scalability issues in the presence of a large number of
> >> neighbors
> >> >> on
> >> >> >> a
> >> >> >> > LAN and/or a large number of enabled VLANs. In my comments I
> >> have
> >> >> >> > confined myself to pointing out where I believe such issues
> >> arise.
> >> >> If
> >> >> >> > there is consensus that these are issues which should be
> >> >> addressed,
> >> >> >> then
> >> >> >> > additional discussions can be started as to how to do so.
> >> >> >> >
> >> >> >> > Finally, I would like to thank the authors of draft-ietf-
> trill-
> >> >> adj-01
> >> >> >> > for the effort and diligence they obviously applied to the
> >> writing
> >> >> of
> >> >> >> > this draft.
> >> >> >> >
> >> >> >> > ? Les
> >> >> >> >
> >> >> >> >
> >> >> >> > _______________________________________________
> >> >> >> > rbridge mailing list
> >> >> >> > rbridge at postel.org
> >> >> >> > http://mailman.postel.org/mailman/listinfo/rbridge
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >
> >


From d3e3e3 at gmail.com  Sat Jan 15 13:29:19 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Sat, 15 Jan 2011 16:29:19 -0500
Subject: [rbridge] [Isis-wg] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <AE36820147909644AD2A7CA014B1FB520D0DF509@xmb-sjc-222.amer.cisco.com>
References: <4D221B2B.2020207@acm.org>
	<AE36820147909644AD2A7CA014B1FB520D0DF509@xmb-sjc-222.amer.cisco.com>
Message-ID: <AANLkTimETdWyO-_9=rzJtmv9M_MzrQb+7zZ=6V+e9OGh@mail.gmail.com>

Hi Les,

On Thu, Jan 13, 2011 at 8:32 PM, Les Ginsberg (ginsberg)
<ginsberg at cisco.com> wrote:
> Attached please find my comments on draft-ietf-trill-adj-01.
>
> The file draft-ietf-trill-adj-01_comments.txt contains substantive
> comments identified by Section # - except in a couple of cases where the
> remarks are more generic.
>
> The file draft-ietf-trill-adj-01_editorial.txt is portions of the draft
> annotated with editorial comments. Search for "LES:" in the file.
>
> ...
>
> Finally, I would like to thank the authors of draft-ietf-trill-adj-01
> for the effort and diligence they obviously applied to the writing of
> this draft.

Thanks. Sounds like the adj draft has achieved its purpose "to improve
the quality of the
description of the TRILL LAN Hello protocol". Below is a response to
your editorial comments. My comments are at <DEE3>. I will reply to
your technical comments separately.

> ? Les

2. The TRILL Hello Environment and Purposes

   [IS-IS] has subnet independent functions and subnet dependent

LES: I believe all occurences of "subnet" should really be "subnetwork".

<DEE3> OK.

   functions. Currently Layer 3 use of IS-IS supports two types of
   subnets: point-to-point link subnets between routers and general
   broadcast (LAN) subnets. Because of the differences between the
   environment of Layer 3 routers and the environment of TRILL RBridges,
   the TRILL protocol uses a different type of LAN subnet from the
   broadcast (LAN) subnet type encountered at Layer 3. The environmental
   differences are described below followed by a summation, in Section
   2.5, of the purposes of the TRILL LAN Hello protocol.

LES: Suggested rewrite
  "the TRILL protocol uses a different type of LAN subnet from the
   broadcast (LAN) subnet type encountered at Layer 3" to be

to become

  "The TRILL protocol uses different subnetwork dependent functions
  from those specified in [IS-IS] Section 8.4."

<DEE3> It seems to me that the current wording int he draft is more
specific. I don't see that advantage of changing to more vague
wording... How about "instead of the broadcast (LAN) subnetwork
functions encountered at Layer 3, which are specified in [IS-IS]
Section 8.4, the TRILL protocol uses different functions for a LAN
subnetwork."

...

2.5 Purposes of the TRILL Hello Protocol

...

   In Layer 3 IS-IS all three of these functions are combined. Hellos
   are padded to the maximum length so that a router neighbor is not
   even discovered if it is impossible to communicate with it using
   maximum sized packets. Also, even if Hellos from a neighbor R2 are
   received by R1, if connectivity to R2 is not 2-way (i.e., R2 does not


LES: Padding in [IS-IS] is optional. See RFC 3719 Section 6 for a discussion.

<DEE3> OK, I'll replace "area padded" with "are usually padded".

...

4.2 DRB Election Events

   Determination of events 3 and 4 occurs by comparing priorities (with
   neighbor MAC address (SNPA) as a tie breaker and Port ID as a
   secondary tie breaker) across all entries in the port's adjacency
   table including those in the Detect and 2-Way states as well as those
   in the Report state.

LES: The highest Port ID is preferred??? Need an explicit statement.

<DEE3> Yes, highest, considered as an unsigned integer. I can add that.

...

5. MTU Matching

...

   An RBridge, RB1, determines the desired campus link MTU by
   calculating the minimum of its originatingL1LSPBufferSize and the
   originatingLSPBufferSize advertised in the link state database by

LES: These should all be "originatingL1LSPBufferSize".
(you have omitted "L1" in some cases)

<DEE3> I believe the variable in the LSP is just
originatingLSPBufferSize and is L1 or L2 depending on whether the LSP
is L1 or L2.

6. Pseudonodes

   The Designated RBridge (DRB), determined as described above, controls
   whether a pseudonode will be used on a link.

   It is anticipated that many links between RBridges will actually be
   point-to-point, in which case using a pseudonode merely adds to the
   complexity. If the DRB sets the bypass pseudonode bit in its TRILL
   LAN Hellos, the RBridges on the link just directly report their
   adjacencies that are in the Report state. If the DRB does not set the
   bypass pseudonode bit in its TRILL Hellos, then it specifies a
   pseudonode for the link and sends LSPs on behalf of the pseudonode as
   usual. Setting the bypass pseudonode bit has no effect on how LSPs
   are flooded on a link. It only affects what LSPs are generated.

LES: The phrase "specifies a pseudo-node for the link" suggests that
the LANID sent by the DRB may be different depending on whether the
bypass pseudo-node bit is set or not. Do you really mean that?

<DEE3> No, it is not meant to imply that. How about, "..., then the LAN
ID in the DRB's Hellos specifies the pseudonode for the link and the
DRB sends ..."

he DRB does not set the
   bypass pseudonode bit in its TRILL Hellos, then it specifies a
   pseudonode for the link and sends LSPs on behalf of the pseudonode as
   usual. Setting the bypass pseudonode bit has no effect on how LSPs
   are flooded on a link. It only affects what LSPs are generated.

LES

<DEE3> Thanks, Donald


From ginsberg at cisco.com  Sat Jan 15 14:45:01 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Sat, 15 Jan 2011 14:45:01 -0800
Subject: [rbridge] [Isis-wg] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <AANLkTimETdWyO-_9=rzJtmv9M_MzrQb+7zZ=6V+e9OGh@mail.gmail.com>
References: <4D221B2B.2020207@acm.org><AE36820147909644AD2A7CA014B1FB520D0DF509@xmb-sjc-222.amer.cisco.com>
	<AANLkTimETdWyO-_9=rzJtmv9M_MzrQb+7zZ=6V+e9OGh@mail.gmail.com>
Message-ID: <AE36820147909644AD2A7CA014B1FB520D0DFA2C@xmb-sjc-222.amer.cisco.com>

Donald -

Thanx for the prompt reply.
Comments on open issues inline.

> 
> 2. The TRILL Hello Environment and Purposes
> 
>    functions. Currently Layer 3 use of IS-IS supports two types of
>    subnets: point-to-point link subnets between routers and general
>    broadcast (LAN) subnets. Because of the differences between the
>    environment of Layer 3 routers and the environment of TRILL
> RBridges,
>    the TRILL protocol uses a different type of LAN subnet from the
>    broadcast (LAN) subnet type encountered at Layer 3. The
> environmental
>    differences are described below followed by a summation, in Section
>    2.5, of the purposes of the TRILL LAN Hello protocol.
> 
> LES: Suggested rewrite
>   "the TRILL protocol uses a different type of LAN subnet from the
>    broadcast (LAN) subnet type encountered at Layer 3" to be
> 
> to become
> 
>   "The TRILL protocol uses different subnetwork dependent functions
>   from those specified in [IS-IS] Section 8.4."
> 
> <DEE3> It seems to me that the current wording int he draft is more
> specific. I don't see that advantage of changing to more vague
> wording... How about "instead of the broadcast (LAN) subnetwork
> functions encountered at Layer 3, which are specified in [IS-IS]
> Section 8.4, the TRILL protocol uses different functions for a LAN
> subnetwork."

I did not realize what I suggested was less specific. The intent of my
suggested change is to correctly state that the nature of the subnetwork
(LAN) has not changed at all, but the subnetwork dependent functions are
different for TRILL. Your suggested wording indicates that about as well
as mine - but the "standard terminology" used in "ISO speak" is
"subnetwork dependent functions" or "subnetwork dependent convergence
functions(SNDCF)". A bit obfuscatory in an IP centric world, but I would
like something that conforms to "ISO speak". 

Sorry for the nit picking...

> 
> ...
> 
> 2.5 Purposes of the TRILL Hello Protocol
> 
> ...
> 
>    In Layer 3 IS-IS all three of these functions are combined. Hellos
>    are padded to the maximum length so that a router neighbor is not
>    even discovered if it is impossible to communicate with it using
>    maximum sized packets. Also, even if Hellos from a neighbor R2 are
>    received by R1, if connectivity to R2 is not 2-way (i.e., R2 does
> not
> 
> 
> LES: Padding in [IS-IS] is optional. See RFC 3719 Section 6 for a
> discussion.
> 
> <DEE3> OK, I'll replace "area padded" with "are usually padded".

I think "may be padded" is better. There are some strong opinions on
both sides of the aisle in regards to the benefits/drawbacks of padding.
I don't want to suggest unaninimity where it does not exist.
(For the record, I am in favor of padding)


> 
> 5. MTU Matching
> 
> ...
> 
>    An RBridge, RB1, determines the desired campus link MTU by
>    calculating the minimum of its originatingL1LSPBufferSize and the
>    originatingLSPBufferSize advertised in the link state database by
> 
> LES: These should all be "originatingL1LSPBufferSize".
> (you have omitted "L1" in some cases)
> 
> <DEE3> I believe the variable in the LSP is just
> originatingLSPBufferSize and is L1 or L2 depending on whether the LSP
> is L1 or L2.

The TLV name is originatingLSPBufferSize(or LSPBufferSize in IANA). Per
ISO 10589 there are two variables which an implementation maintains:

originatingL1LSPBufferSize
originatingL2LSPBufferSize
(they are often the same - but do not have to be as the set of circuits
in use at the two levels may be different)

Whether L1 or L2 is in the TLV is determined by the type of PDU it is in
(Level1LSP or Level2LSP).

There is no variable named originatingLSPBufferSize.
Since TRILL is limited to L1 only at present, you should be using
originatingL1LSPBufferSize everywhere.

In cases where I have written text which is layer independent I have
used the term "originatingLxLSPBufferSize" - but this has no official
support. :-)

> 
> 6. Pseudonodes
> 
>    The Designated RBridge (DRB), determined as described above,
> controls
>    whether a pseudonode will be used on a link.
> 
>    It is anticipated that many links between RBridges will actually be
>    point-to-point, in which case using a pseudonode merely adds to the
>    complexity. If the DRB sets the bypass pseudonode bit in its TRILL
>    LAN Hellos, the RBridges on the link just directly report their
>    adjacencies that are in the Report state. If the DRB does not set
> the
>    bypass pseudonode bit in its TRILL Hellos, then it specifies a
>    pseudonode for the link and sends LSPs on behalf of the pseudonode
> as
>    usual. Setting the bypass pseudonode bit has no effect on how LSPs
>    are flooded on a link. It only affects what LSPs are generated.
> 
> LES: The phrase "specifies a pseudo-node for the link" suggests that
> the LANID sent by the DRB may be different depending on whether the
> bypass pseudo-node bit is set or not. Do you really mean that?
> 
> <DEE3> No, it is not meant to imply that. How about, "..., then the
LAN
> ID in the DRB's Hellos specifies the pseudonode for the link and the
> DRB sends ..."
> 
> he DRB does not set the
>    bypass pseudonode bit in its TRILL Hellos, then it specifies a
>    pseudonode for the link and sends LSPs on behalf of the pseudonode
> as
>    usual. Setting the bypass pseudonode bit has no effect on how LSPs
>    are flooded on a link. It only affects what LSPs are generated.
> 

If we agree that the contents of the LANID field are not affected by the
state of the bypass bit - which I think we do - then I think removing
the phrase is the best thing to do. 

   Les



From carlsonj at workingcode.com  Sun Jan 16 11:23:01 2011
From: carlsonj at workingcode.com (James Carlson)
Date: Sun, 16 Jan 2011 14:23:01 -0500
Subject: [rbridge] working group last call for PPP TRILL protocol control
 protocol [was Re: [Pppext] I-D
 Action:draft-ietf-pppext-trill-protocol-02.txt]
In-Reply-To: <20110106154501.15655.20204.idtracker@localhost>
References: <20110106154501.15655.20204.idtracker@localhost>
Message-ID: <4D334595.3030507@workingcode.com>

On 1/6/2011 10:45 AM, Internet-Drafts at ietf.org wrote:
> 	Title           : PPP TRILL Protocol Control Protocol
> 	Author(s)       : J. Carlson
> 	Filename        : draft-ietf-pppext-trill-protocol-02.txt
> 	Pages           : 6
> 	Date            : 2011-01-06
> 
> The Point-to-Point Protocol (PPP) [1] defines a Link Control Protocol
> (LCP) and a method for negotiating the use of multi-protocol traffic
> over point-to-point links.  This document describes support for
> Transparent Interconnection of Lots of Links (TRILL) Protocol,
> allowing direct communication between Routing Bridges (RBridges) via
> PPP links.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-02.txt

I'm starting a working group last-call comment period for this draft.
The new version incorporates changes for all of the comments received up
to this point.

Last call will run for two weeks.  Please submit any comments,
questions, or concerns you might have to me or to the pppext at ietf.org
mailing list (or both) on or before Sunday, January 30th, 2011.

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

From vishwas.ietf at gmail.com  Mon Jan 17 10:17:18 2011
From: vishwas.ietf at gmail.com (Vishwas Manral)
Date: Mon, 17 Jan 2011 10:17:18 -0800
Subject: [rbridge] draft-ietf-trill-rbridge-mib
Message-ID: <AANLkTi=Rd=w_nU2QMYH4Qh2-FqqU-Z3LH-KiEK-SLYm9@mail.gmail.com>

Hi Anil/ Kate,

I briefly looked at the TRILL MIB and had the following top level comments:

1. I think we should have a seperate tree for the Rbridge. I notice
some of the tables are the same as IS-IS. It will be very confusing to
code a MBI which is half IS-IS and half TRILL IS-IS.
2. There is no information for MultiTopology.
3. Another thing that needs to be kept is the MTU table. Which has MTU
information received from all the devices in the network. I know we
have MTU objects at a link and neighbor basis.
4. We probably need tohave Multicast Address listner  table too.
5. We will need a table for the the information in the system for
distribution trees, and information advertized by each system, or
atleast a way to change the values to be configured for a system.

Thanks,
Vishwas

From d3e3e3 at gmail.com  Tue Jan 18 07:31:19 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 18 Jan 2011 10:31:19 -0500
Subject: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <4D2226FA.3040001@acm.org>
References: <4D221B2B.2020207@acm.org> <4D2226FA.3040001@acm.org>
Message-ID: <AANLkTikNsMAk3p_h66zo+9=wVHS2APXVToLkDceHLcRj@mail.gmail.com>

Hi Erik,

On Mon, Jan 3, 2011 at 2:43 PM, Erik Nordmark <nordmark at acm.org> wrote:
> On 01/ 3/11 10:53 AM, Erik Nordmark wrote:
>>
>> ...
>
> I have a small editorial suggestion for the draft.
>
> Currently the events are numbered 1-8 and 1-5. Thus "event 5" isn't
> sufficient to specify the name of an event. It would be more clear if
> they were numbered A1-A8 and D1-D5 (or P1-P5).

I'm fine with that change. Unless there are some arguments the other
way, I'll make the change.

Thanks,
Donald

> That means we don't need text like e.g., "an adjacency event 5 occurs
> for the adjacency", but can instead say "an event A5 occurs for the
> adjacency".
>
> ? ?Erik


From nordmark at acm.org  Tue Jan 18 09:43:39 2011
From: nordmark at acm.org (Erik Nordmark)
Date: Tue, 18 Jan 2011 09:43:39 -0800
Subject: [rbridge] Fwd: Re: [Isis-wg] WG last call on
	draft-ietf-trill-adj-01.txt
Message-ID: <4D35D14B.6000604@acm.org>

Forwarded from the isis list so all the trill discussion is visible on 
the rbridge list.

    Erik

-------- Original Message --------
Subject: Re: [Isis-wg] [rbridge] WG last call on draft-ietf-trill-adj-01.txt
Date: Tue, 18 Jan 2011 13:36:48 +0000
From: mike shand <mshand at cisco.com>
To: isis-wg at ietf.org

  Vishwas,
     If the consequences of failure for this information to be correctly
exchanged, as a result of loss a single message, are that "bad things
happen", then I don't think it can be considered an optimization to
provide a mechanism which guarantees correct delivery.

     An optimization, in my view, is something like the sending of CSNPs
on pt-pt circuit start up. If they are correctly received the
synchronization process is speeded up, but if they are not, correct
synchronization is still guaranteed to occur, albeit at the expense of
further message exchanges.

     What am I failing to understand? How likely is a failure scenario,
and what is the extent of the damage caused? It is a truism that if
something CAN go wrong it WILL go wrong just at the point where it will
cause maximum disruption. The Boston Hospital meltdown is but one of the
oft cited examples of this phenomenon.

     Mike




On 14/01/2011 22:25, Vishwas Manral wrote:
> Hi Les,
>
> You have good comments.
>
> Like I said we could send the same information multiple times to
> assume the information has reached its neighbor. If the information is
> in one Hello we already have the solution.
>
> I agree this can be improved, however I feel we do not need to do
> every optimization at this point.
>
> Thanks,
> Vishwas
>
>>>>> VM>  I agree with you. It is left to an implementation to decide how
>>> to
>>>>> do it.
>>>> OK. I do think some guidance would be good as the use of MTU PDUs is
>>> an entirely new functionality.
>>> VM>  A clarification could be added.
>>>
>>>> To requote the draft:
>>>>
>>>> " If there are no adjacencies with a non-zero Designated VLAN Hello
>>>>    Holding timer, an empty TRILL Neighbor TLV MUST be included in each
>>>>    Hello.  If there are such adjacencies, then the Hello MAY contain a
>>>>    TRILL Neighbor TLV..."
>>>>
>>>> I understand the motivation for an explicit "no neighbors"
>>> advertisement - but I am asking why you want to make inclusion of TRILL
>>> Neighbor TLV optional when you do have adjacencies?
>>> VM>  This can again be treated in the context of the fact that if the
>>> data does not fit in one Hello, we could send the other data in the
>>> other Hello, and include empty TRILL Neighbor TLV. It could also be
>>> treated in the context of the fact that we should allow receiving the
>>> empty TLV.
>>>
>>> I know this could be removed by itself, as there is no harm or benefit
>>> of the same, based on how the spec stands, however it could help to
>>> state that for some future use like mentioned above.
>>>
>>> Thanks,
>>> Vishwas
>>>
>>>>>>> On Thu, Jan 13, 2011 at 5:36 PM, Les Ginsberg (ginsberg)
>>>>>>> <ginsberg at cisco.com>  wrote:
>>>>>>>> (resending w corrected TRILL WG address)
>>>>>>>>
>>>>>>>> Attached please find my comments on draft-ietf-trill-adj-01.
>>>>>>>>
>>>>>>>> The file draft-ietf-trill-adj-01_comments.txt contains
>>> substantive
>>>>>>>> comments identified by Section # - except in a couple of cases
>>>>> where
>>>>>>> the
>>>>>>>> remarks are more generic.
>>>>>>>>
>>>>>>>> The file draft-ietf-trill-adj-01_editorial.txt is portions of
>>> the
>>>>>>> draft
>>>>>>>> annotated with editorial comments. Search for "LES:" in the
>>> file.
>>>>>>>> As context, the requirements of [TRILL] introduce the need to
>>> send
>>>>> a
>>>>>>>> great deal more circuit scoped information on a LAN as compared
>>> to
>>>>>>> Layer
>>>>>>>> 3 IS-IS. Extensions to the IS-IS protocol defined in [TRILL],
>>>>>>>> [TRILL-ISIS], and [TRILL-ADJ] are designed to support this new
>>>>>>>> information and to provide robust loop prevention in the
>>>>> forwarding
>>>>>>> of
>>>>>>>> data. But I believe the extensions as currently defined have
>>>>>>> significant
>>>>>>>> scalability issues in the presence of a large number of
>>> neighbors
>>>>> on
>>>>>>> a
>>>>>>>> LAN and/or a large number of enabled VLANs. In my comments I
>>> have
>>>>>>>> confined myself to pointing out where I believe such issues
>>> arise.
>>>>> If
>>>>>>>> there is consensus that these are issues which should be
>>>>> addressed,
>>>>>>> then
>>>>>>>> additional discussions can be started as to how to do so.
>>>>>>>>
>>>>>>>> Finally, I would like to thank the authors of draft-ietf-trill-
>>>>> adj-01
>>>>>>>> for the effort and diligence they obviously applied to the
>>> writing
>>>>> of
>>>>>>>> this draft.
>>>>>>>>
>>>>>>>>    Les
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> rbridge mailing list
>>>>>>>> rbridge at postel.org
>>>>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>>>>
>>>>>>>>
> _______________________________________________
> Isis-wg mailing list
> Isis-wg at ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
>
_______________________________________________
Isis-wg mailing list
Isis-wg at ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg


From nordmark at acm.org  Tue Jan 18 09:44:00 2011
From: nordmark at acm.org (Erik Nordmark)
Date: Tue, 18 Jan 2011 09:44:00 -0800
Subject: [rbridge] Fwd: Re: [Isis-wg] WG last call on
	draft-ietf-trill-adj-01.txt
Message-ID: <4D35D160.9020602@acm.org>

Forwarded from the isis list so all the trill discussion is visible on 
the rbridge list.

    Erik

-------- Original Message --------
Subject: Re: [Isis-wg] [rbridge] WG last call on draft-ietf-trill-adj-01.txt
Date: Tue, 18 Jan 2011 12:44:53 +0000
From: mike shand <mshand at cisco.com>
To: isis-wg at ietf.org

  To be absolutely clear on this, perhaps the text should also describe
what the non DRBs do. I appreciate that the example includes this,
but it is somewhat anomalous that the normative text describes the
changed actions of the DRB, but not (explicitly) those of the non-DRBs.

So how about:-


"If the DRB sets the bypass pseudonode bit in its TRILL
    LAN Hellos, the RBridges on the link (including the DRB) just
directly report all their
    adjacencies on the LAN that are in the Report state. If the DRB does
not set the
    bypass pseudonode bit in its TRILL Hellos, then (as in ISO/IEC
10589) it sends LSPs on behalf of the pseudonode, and all RBridges
report only their adjacency to the pseudonode. Setting the bypass
pseudonode bit has no effect on how LSPs
    are flooded on a link. It only affects what LSPs are generated."


     Mike


On 15/01/2011 22:45, Les Ginsberg (ginsberg) wrote:
>> 6. Pseudonodes
>> >
>> >      The Designated RBridge (DRB), determined as described above,
>> >  controls
>> >      whether a pseudonode will be used on a link.
>> >
>> >      It is anticipated that many links between RBridges will actually be
>> >      point-to-point, in which case using a pseudonode merely adds to the
>> >      complexity. If the DRB sets the bypass pseudonode bit in its TRILL
>> >      LAN Hellos, the RBridges on the link just directly report their
>> >      adjacencies that are in the Report state. If the DRB does not set
>> >  the
>> >      bypass pseudonode bit in its TRILL Hellos, then it specifies a
>> >      pseudonode for the link and sends LSPs on behalf of the pseudonode
>> >  as
>> >      usual. Setting the bypass pseudonode bit has no effect on how LSPs
>> >      are flooded on a link. It only affects what LSPs are generated.
>> >
>> >  LES: The phrase "specifies a pseudo-node for the link" suggests that
>> >  the LANID sent by the DRB may be different depending on whether the
>> >  bypass pseudo-node bit is set or not. Do you really mean that?
>> >
>> >  <DEE3>  No, it is not meant to imply that. How about, "..., then the
> LAN
>> >  ID in the DRB's Hellos specifies the pseudonode for the link and the
>> >  DRB sends ..."
>> >
>> >  he DRB does not set the
>> >      bypass pseudonode bit in its TRILL Hellos, then it specifies a
>> >      pseudonode for the link and sends LSPs on behalf of the pseudonode
>> >  as
>> >      usual. Setting the bypass pseudonode bit has no effect on how LSPs
>> >      are flooded on a link. It only affects what LSPs are generated.
>> >
> If we agree that the contents of the LANID field are not affected by the
> state of the bypass bit - which I think we do - then I think removing
> the phrase is the best thing to do.
>
>     Les
_______________________________________________
Isis-wg mailing list
Isis-wg at ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg


From d3e3e3 at gmail.com  Tue Jan 18 14:11:15 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 18 Jan 2011 17:11:15 -0500
Subject: [rbridge] [Isis-wg] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <AE36820147909644AD2A7CA014B1FB520D0DFA2C@xmb-sjc-222.amer.cisco.com>
References: <4D221B2B.2020207@acm.org>
	<AE36820147909644AD2A7CA014B1FB520D0DF509@xmb-sjc-222.amer.cisco.com>
	<AANLkTimETdWyO-_9=rzJtmv9M_MzrQb+7zZ=6V+e9OGh@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520D0DFA2C@xmb-sjc-222.amer.cisco.com>
Message-ID: <AANLkTimus5DuV+LvoBN83vd97g6TzNUTkFD_gFvj2rOn@mail.gmail.com>

Hi Les,

On Sat, Jan 15, 2011 at 5:45 PM, Les Ginsberg (ginsberg)
<ginsberg at cisco.com> wrote:
> Donald -
>
> Thanx for the prompt reply.
> Comments on open issues inline.
>
>> 2. The TRILL Hello Environment and Purposes
>>
>> ? ?functions. Currently Layer 3 use of IS-IS supports two types of
>> ? ?subnets: point-to-point link subnets between routers and general
>> ? ?broadcast (LAN) subnets. Because of the differences between the
>> ? ?environment of Layer 3 routers and the environment of TRILL
>> RBridges,
>> ? ?the TRILL protocol uses a different type of LAN subnet from the
>> ? ?broadcast (LAN) subnet type encountered at Layer 3. The
>> environmental
>> ? ?differences are described below followed by a summation, in Section
>> ? ?2.5, of the purposes of the TRILL LAN Hello protocol.
>>
>> LES: Suggested rewrite
>> ? "the TRILL protocol uses a different type of LAN subnet from the
>> ? ?broadcast (LAN) subnet type encountered at Layer 3" to be
>>
>> to become
>>
>> ? "The TRILL protocol uses different subnetwork dependent functions
>> ? from those specified in [IS-IS] Section 8.4."
>>
>> <DEE3> It seems to me that the current wording int he draft is more
>> specific. I don't see that advantage of changing to more vague
>> wording... How about "instead of the broadcast (LAN) subnetwork
>> functions encountered at Layer 3, which are specified in [IS-IS]
>> Section 8.4, the TRILL protocol uses different functions for a LAN
>> subnetwork."
>
> I did not realize what I suggested was less specific. The intent of my
> suggested change is to correctly state that the nature of the subnetwork
> (LAN) has not changed at all, but the subnetwork dependent functions are
> different for TRILL. Your suggested wording indicates that about as well
> as mine - but the "standard terminology" used in "ISO speak" is
> "subnetwork dependent functions" or "subnetwork dependent convergence
> functions(SNDCF)". A bit obfuscatory in an IP centric world, but I would
> like something that conforms to "ISO speak".
>
> Sorry for the nit picking...

OK, "instead of the broadcast (LAN) subnetwork dependent functions
encountered at Layer 3, which are specified in [IS-IS] Section 8.4,
the TRILL protocol uses different subnetwork dependent functions for a
LAN subnetwork."

>> ...
>>
>> 2.5 Purposes of the TRILL Hello Protocol
>>
>> ...
>>
>> ? ?In Layer 3 IS-IS all three of these functions are combined. Hellos
>> ? ?are padded to the maximum length so that a router neighbor is not
>> ? ?even discovered if it is impossible to communicate with it using
>> ? ?maximum sized packets. Also, even if Hellos from a neighbor R2 are
>> ? ?received by R1, if connectivity to R2 is not 2-way (i.e., R2 does
>> not
>>
>>
>> LES: Padding in [IS-IS] is optional. See RFC 3719 Section 6 for a
>> discussion.
>>
>> <DEE3> OK, I'll replace "are padded" with "are usually padded".
>
> I think "may be padded" is better. There are some strong opinions on
> both sides of the aisle in regards to the benefits/drawbacks of padding.
> I don't want to suggest unaninimity where it does not exist.
> (For the record, I am in favor of padding)

OK, in context "may be padded" is all right. I think I'll also add an
informational reference to RFC 3719.

>> 5. MTU Matching
>>
>> ...
>>
>> ? ?An RBridge, RB1, determines the desired campus link MTU by
>> ? ?calculating the minimum of its originatingL1LSPBufferSize and the
>> ? ?originatingLSPBufferSize advertised in the link state database by
>>
>> LES: These should all be "originatingL1LSPBufferSize".
>> (you have omitted "L1" in some cases)
>>
>> <DEE3> I believe the variable in the LSP is just
>> originatingLSPBufferSize and is L1 or L2 depending on whether the LSP
>> is L1 or L2.
>
> The TLV name is originatingLSPBufferSize(or LSPBufferSize in IANA). Per
> ISO 10589 there are two variables which an implementation maintains:
>
> originatingL1LSPBufferSize
> originatingL2LSPBufferSize
> (they are often the same - but do not have to be as the set of circuits
> in use at the two levels may be different)
>
> Whether L1 or L2 is in the TLV is determined by the type of PDU it is in
> (Level1LSP or Level2LSP).
>
> There is no variable named originatingLSPBufferSize.
> Since TRILL is limited to L1 only at present, you should be using
> originatingL1LSPBufferSize everywhere.

I note that RFC 3719, to which you referred me above, uses
originatingL1LSPBufferSize in some contexts and
originatingLSPBufferSize in others. Whether there is a "variable"
named originatingLSPBufferSize depends on what you think a variable
is. We seem to agree that there is a TLV field called
originatingLSPBufferSize and the reference from the draft above to "in
the link state database" was meant to refer to that field by its
proper name.

> ...
>
>> 6. Pseudonodes
>>
>> ? ?The Designated RBridge (DRB), determined as described above,
>> controls
>> ? ?whether a pseudonode will be used on a link.
>>
>> ? ?It is anticipated that many links between RBridges will actually be
>> ? ?point-to-point, in which case using a pseudonode merely adds to the
>> ? ?complexity. If the DRB sets the bypass pseudonode bit in its TRILL
>> ? ?LAN Hellos, the RBridges on the link just directly report their
>> ? ?adjacencies that are in the Report state. If the DRB does not set
>> the
>> ? ?bypass pseudonode bit in its TRILL Hellos, then it specifies a
>> ? ?pseudonode for the link and sends LSPs on behalf of the pseudonode
>> as
>> ? ?usual. Setting the bypass pseudonode bit has no effect on how LSPs
>> ? ?are flooded on a link. It only affects what LSPs are generated.
>>
>> LES: The phrase "specifies a pseudo-node for the link" suggests that
>> the LANID sent by the DRB may be different depending on whether the
>> bypass pseudo-node bit is set or not. Do you really mean that?
>>
>> <DEE3> No, it is not meant to imply that. How about, "..., then the
> LAN
>> ID in the DRB's Hellos specifies the pseudonode for the link and the
>> DRB sends ..."
>>
>> he DRB does not set the
>> ? ?bypass pseudonode bit in its TRILL Hellos, then it specifies a
>> ? ?pseudonode for the link and sends LSPs on behalf of the pseudonode
>> as
>> ? ?usual. Setting the bypass pseudonode bit has no effect on how LSPs
>> ? ?are flooded on a link. It only affects what LSPs are generated.
>>
>
> If we agree that the contents of the LANID field are not affected by the
> state of the bypass bit - which I think we do - then I think removing
> the phrase is the best thing to do.

Yes, I agree on that. Deleting "specifies a pseudonode for the link
and" seems OK.

> ? Les

Thanks,
Donald


From ginsberg at cisco.com  Tue Jan 18 16:49:06 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Tue, 18 Jan 2011 16:49:06 -0800
Subject: [rbridge] [Isis-wg] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <AANLkTimus5DuV+LvoBN83vd97g6TzNUTkFD_gFvj2rOn@mail.gmail.com>
References: <4D221B2B.2020207@acm.org>
	<AE36820147909644AD2A7CA014B1FB520D0DF509@xmb-sjc-222.amer.cisco.com>
	<AANLkTimETdWyO-_9=rzJtmv9M_MzrQb+7zZ=6V+e9OGh@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520D0DFA2C@xmb-sjc-222.amer.cisco.com>
	<AANLkTimus5DuV+LvoBN83vd97g6TzNUTkFD_gFvj2rOn@mail.gmail.com>
Message-ID: <AE36820147909644AD2A7CA014B1FB520D17770B@xmb-sjc-222.amer.cisco.com>

Donald -

> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3 at gmail.com]
> Sent: Tuesday, January 18, 2011 2:11 PM
> To: Les Ginsberg (ginsberg)
> Cc: rbridge at postel.org; isis-wg at ietf.org
> Subject: Re: [Isis-wg] [rbridge] WG last call on draft-ietf-trill-adj-
> 01.txt
> 
> Hi Les,
> 
> On Sat, Jan 15, 2011 at 5:45 PM, Les Ginsberg (ginsberg)
> <ginsberg at cisco.com> wrote:
> > Donald -
> >
> > Thanx for the prompt reply.
> > Comments on open issues inline.
> >
> >> 2. The TRILL Hello Environment and Purposes
> >>
> >> ? ?functions. Currently Layer 3 use of IS-IS supports two types of
> >> ? ?subnets: point-to-point link subnets between routers and general
> >> ? ?broadcast (LAN) subnets. Because of the differences between the
> >> ? ?environment of Layer 3 routers and the environment of TRILL
> >> RBridges,
> >> ? ?the TRILL protocol uses a different type of LAN subnet from the
> >> ? ?broadcast (LAN) subnet type encountered at Layer 3. The
> >> environmental
> >> ? ?differences are described below followed by a summation, in
> Section
> >> ? ?2.5, of the purposes of the TRILL LAN Hello protocol.
> >>
> >> LES: Suggested rewrite
> >> ? "the TRILL protocol uses a different type of LAN subnet from the
> >> ? ?broadcast (LAN) subnet type encountered at Layer 3" to be
> >>
> >> to become
> >>
> >> ? "The TRILL protocol uses different subnetwork dependent functions
> >> ? from those specified in [IS-IS] Section 8.4."
> >>
> >> <DEE3> It seems to me that the current wording int he draft is more
> >> specific. I don't see that advantage of changing to more vague
> >> wording... How about "instead of the broadcast (LAN) subnetwork
> >> functions encountered at Layer 3, which are specified in [IS-IS]
> >> Section 8.4, the TRILL protocol uses different functions for a LAN
> >> subnetwork."
> >
> > I did not realize what I suggested was less specific. The intent of
> my
> > suggested change is to correctly state that the nature of the
> subnetwork
> > (LAN) has not changed at all, but the subnetwork dependent functions
> are
> > different for TRILL. Your suggested wording indicates that about as
> well
> > as mine - but the "standard terminology" used in "ISO speak" is
> > "subnetwork dependent functions" or "subnetwork dependent convergence
> > functions(SNDCF)". A bit obfuscatory in an IP centric world, but I
> would
> > like something that conforms to "ISO speak".
> >
> > Sorry for the nit picking...
> 
> OK, "instead of the broadcast (LAN) subnetwork dependent functions
> encountered at Layer 3, which are specified in [IS-IS] Section 8.4,
> the TRILL protocol uses different subnetwork dependent functions for a
> LAN subnetwork."

ACK

> 
> >> ...
> >>
> >> 2.5 Purposes of the TRILL Hello Protocol
> >>
> >> ...
> >>
> >> ? ?In Layer 3 IS-IS all three of these functions are combined.
> Hellos
> >> ? ?are padded to the maximum length so that a router neighbor is not
> >> ? ?even discovered if it is impossible to communicate with it using
> >> ? ?maximum sized packets. Also, even if Hellos from a neighbor R2
> are
> >> ? ?received by R1, if connectivity to R2 is not 2-way (i.e., R2 does
> >> not
> >>
> >>
> >> LES: Padding in [IS-IS] is optional. See RFC 3719 Section 6 for a
> >> discussion.
> >>
> >> <DEE3> OK, I'll replace "are padded" with "are usually padded".
> >
> > I think "may be padded" is better. There are some strong opinions on
> > both sides of the aisle in regards to the benefits/drawbacks of
> padding.
> > I don't want to suggest unaninimity where it does not exist.
> > (For the record, I am in favor of padding)
> 
> OK, in context "may be padded" is all right. I think I'll also add an
> informational reference to RFC 3719.

ACK

> 
> >> 5. MTU Matching
> >>
> >> ...
> >>
> >> ? ?An RBridge, RB1, determines the desired campus link MTU by
> >> ? ?calculating the minimum of its originatingL1LSPBufferSize and the
> >> ? ?originatingLSPBufferSize advertised in the link state database by
> >>
> >> LES: These should all be "originatingL1LSPBufferSize".
> >> (you have omitted "L1" in some cases)
> >>
> >> <DEE3> I believe the variable in the LSP is just
> >> originatingLSPBufferSize and is L1 or L2 depending on whether the
> LSP
> >> is L1 or L2.
> >
> > The TLV name is originatingLSPBufferSize(or LSPBufferSize in IANA).
> Per
> > ISO 10589 there are two variables which an implementation maintains:
> >
> > originatingL1LSPBufferSize
> > originatingL2LSPBufferSize
> > (they are often the same - but do not have to be as the set of
> circuits
> > in use at the two levels may be different)
> >
> > Whether L1 or L2 is in the TLV is determined by the type of PDU it is
> in
> > (Level1LSP or Level2LSP).
> >
> > There is no variable named originatingLSPBufferSize.
> > Since TRILL is limited to L1 only at present, you should be using
> > originatingL1LSPBufferSize everywhere.
> 
> I note that RFC 3719, to which you referred me above, uses
> originatingL1LSPBufferSize in some contexts and
> originatingLSPBufferSize in others. Whether there is a "variable"
> named originatingLSPBufferSize depends on what you think a variable
> is. We seem to agree that there is a TLV field called
> originatingLSPBufferSize and the reference from the draft above to "in
> the link state database" was meant to refer to that field by its
> proper name.


We agree that if referring to the type name of the TLV the correct name is originatingLSPBufferSize.
I think we also agree that what is advertised in the TLV (the value) is either originatingL1LSPBufferSize or originatingL2LSPBufferSize. In reviewing the draft I think all uses are actually referring to the value advertised - not the type name of the TLV - so that is why I suggest that all uses in the draft should be originatingL1LSPBufferSize.


> 
> > ...
> >
> >> 6. Pseudonodes
> >>
> >> ? ?The Designated RBridge (DRB), determined as described above,
> >> controls
> >> ? ?whether a pseudonode will be used on a link.
> >>
> >> ? ?It is anticipated that many links between RBridges will actually
> be
> >> ? ?point-to-point, in which case using a pseudonode merely adds to
> the
> >> ? ?complexity. If the DRB sets the bypass pseudonode bit in its
> TRILL
> >> ? ?LAN Hellos, the RBridges on the link just directly report their
> >> ? ?adjacencies that are in the Report state. If the DRB does not set
> >> the
> >> ? ?bypass pseudonode bit in its TRILL Hellos, then it specifies a
> >> ? ?pseudonode for the link and sends LSPs on behalf of the
> pseudonode
> >> as
> >> ? ?usual. Setting the bypass pseudonode bit has no effect on how
> LSPs
> >> ? ?are flooded on a link. It only affects what LSPs are generated.
> >>
> >> LES: The phrase "specifies a pseudo-node for the link" suggests that
> >> the LANID sent by the DRB may be different depending on whether the
> >> bypass pseudo-node bit is set or not. Do you really mean that?
> >>
> >> <DEE3> No, it is not meant to imply that. How about, "..., then the
> > LAN
> >> ID in the DRB's Hellos specifies the pseudonode for the link and the
> >> DRB sends ..."
> >>
> >> he DRB does not set the
> >> ? ?bypass pseudonode bit in its TRILL Hellos, then it specifies a
> >> ? ?pseudonode for the link and sends LSPs on behalf of the
> pseudonode
> >> as
> >> ? ?usual. Setting the bypass pseudonode bit has no effect on how
> LSPs
> >> ? ?are flooded on a link. It only affects what LSPs are generated.
> >>
> >
> > If we agree that the contents of the LANID field are not affected by
> the
> > state of the bypass bit - which I think we do - then I think removing
> > the phrase is the best thing to do.
> 
> Yes, I agree on that. Deleting "specifies a pseudonode for the link
> and" seems OK.

ACK.

   Les

> 
> > ? Les
> 
> Thanks,
> Donald


From d3e3e3 at gmail.com  Thu Jan 20 17:35:51 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 20 Jan 2011 20:35:51 -0500
Subject: [rbridge] [Isis-wg] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <AE36820147909644AD2A7CA014B1FB520D17770B@xmb-sjc-222.amer.cisco.com>
References: <4D221B2B.2020207@acm.org>
	<AE36820147909644AD2A7CA014B1FB520D0DF509@xmb-sjc-222.amer.cisco.com>
	<AANLkTimETdWyO-_9=rzJtmv9M_MzrQb+7zZ=6V+e9OGh@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520D0DFA2C@xmb-sjc-222.amer.cisco.com>
	<AANLkTimus5DuV+LvoBN83vd97g6TzNUTkFD_gFvj2rOn@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520D17770B@xmb-sjc-222.amer.cisco.com>
Message-ID: <AANLkTikydKQiU6mYWeV88WQoBf0NNFE2sspk=+kn32po@mail.gmail.com>

Hi Les,

On Tue, Jan 18, 2011 at 7:49 PM, Les Ginsberg (ginsberg)
<ginsberg at cisco.com> wrote:
> Donald -
>
>> -----Original Message-----
>> From: Donald Eastlake [mailto:d3e3e3 at gmail.com]
>> Sent: Tuesday, January 18, 2011 2:11 PM
>> To: Les Ginsberg (ginsberg)
>> Cc: rbridge at postel.org; isis-wg at ietf.org
>> Subject: Re: [Isis-wg] [rbridge] WG last call on draft-ietf-trill-adj-
>> 01.txt
>>
>> Hi Les,
>>
>> On Sat, Jan 15, 2011 at 5:45 PM, Les Ginsberg (ginsberg)
>> <ginsberg at cisco.com> wrote:
>> > Donald -
...
>> >> 5. MTU Matching
>> >>
>> >> ...
>> >>
>> >> ? ?An RBridge, RB1, determines the desired campus link MTU by
>> >> ? ?calculating the minimum of its originatingL1LSPBufferSize and the
>> >> ? ?originatingLSPBufferSize advertised in the link state database by
>> >>
>> >> LES: These should all be "originatingL1LSPBufferSize".
>> >> (you have omitted "L1" in some cases)
>> >>
>> >> <DEE3> I believe the variable in the LSP is just
>> >> originatingLSPBufferSize and is L1 or L2 depending on whether the
>> LSP
>> >> is L1 or L2.
>> >
>> > The TLV name is originatingLSPBufferSize(or LSPBufferSize in IANA).
>> Per
>> > ISO 10589 there are two variables which an implementation maintains:
>> >
>> > originatingL1LSPBufferSize
>> > originatingL2LSPBufferSize
>> > (they are often the same - but do not have to be as the set of
>> circuits
>> > in use at the two levels may be different)
>> >
>> > Whether L1 or L2 is in the TLV is determined by the type of PDU it is
>> in
>> > (Level1LSP or Level2LSP).
>> >
>> > There is no variable named originatingLSPBufferSize.
>> > Since TRILL is limited to L1 only at present, you should be using
>> > originatingL1LSPBufferSize everywhere.
>>
>> I note that RFC 3719, to which you referred me above, uses
>> originatingL1LSPBufferSize in some contexts and
>> originatingLSPBufferSize in others. Whether there is a "variable"
>> named originatingLSPBufferSize depends on what you think a variable
>> is. We seem to agree that there is a TLV field called
>> originatingLSPBufferSize and the reference from the draft above to "in
>> the link state database" was meant to refer to that field by its
>> proper name.
>
> We agree that if referring to the type name of the TLV the correct name is originatingLSPBufferSize.
> I think we also agree that what is advertised in the TLV (the value) is either originatingL1LSPBufferSize or originatingL2LSPBufferSize. In reviewing the draft I think all uses are actually referring to the value advertised - not the type name of the TLV - so that is why I suggest that all uses in the draft should be originatingL1LSPBufferSize.

I still think it is the field in the link state database that is being
referred to and it should be called originatingLSPBufferSize. But I'm
willing to change it to originatingL1LSPBufferSize with other changes
that make if refer to the originating RBridge's variable. How about:

"An RBridge, RB1, determines the desired campus link MTU by
calculating the minimum of its originatingL1LSPBufferSize and the
originatingL1LSPBufferSize of other RBridges in the campus, as
advertised in the link state database, but not less than 1,470 bytes."

>>
>> > ...
...

>
> ? Les

I glanced at your other comments and think they are best handled via
separate mail threads.

Thanks,
Donald


From ginsberg at cisco.com  Thu Jan 20 22:23:41 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Thu, 20 Jan 2011 22:23:41 -0800
Subject: [rbridge] [Isis-wg] WG last call on draft-ietf-trill-adj-01.txt
In-Reply-To: <AANLkTikydKQiU6mYWeV88WQoBf0NNFE2sspk=+kn32po@mail.gmail.com>
References: <4D221B2B.2020207@acm.org>
	<AE36820147909644AD2A7CA014B1FB520D0DF509@xmb-sjc-222.amer.cisco.com>
	<AANLkTimETdWyO-_9=rzJtmv9M_MzrQb+7zZ=6V+e9OGh@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520D0DFA2C@xmb-sjc-222.amer.cisco.com>
	<AANLkTimus5DuV+LvoBN83vd97g6TzNUTkFD_gFvj2rOn@mail.gmail.com>
	<AE36820147909644AD2A7CA014B1FB520D17770B@xmb-sjc-222.amer.cisco.com>
	<AANLkTikydKQiU6mYWeV88WQoBf0NNFE2sspk=+kn32po@mail.gmail.com>
Message-ID: <AE36820147909644AD2A7CA014B1FB520D20FC3E@xmb-sjc-222.amer.cisco.com>

Donald -

> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3 at gmail.com]
> Sent: Thursday, January 20, 2011 5:36 PM
> To: Les Ginsberg (ginsberg)
> Cc: rbridge at postel.org; isis-wg at ietf.org
> Subject: Re: [Isis-wg] [rbridge] WG last call on draft-ietf-trill-adj-
> 01.txt
> 
> Hi Les,
> 
> On Tue, Jan 18, 2011 at 7:49 PM, Les Ginsberg (ginsberg)
> <ginsberg at cisco.com> wrote:
> > Donald -
> >
> >> -----Original Message-----
> >> From: Donald Eastlake [mailto:d3e3e3 at gmail.com]
> >> Sent: Tuesday, January 18, 2011 2:11 PM
> >> To: Les Ginsberg (ginsberg)
> >> Cc: rbridge at postel.org; isis-wg at ietf.org
> >> Subject: Re: [Isis-wg] [rbridge] WG last call on draft-ietf-trill-
> adj-
> >> 01.txt
> >>
> >> Hi Les,
> >>
> >> On Sat, Jan 15, 2011 at 5:45 PM, Les Ginsberg (ginsberg)
> >> <ginsberg at cisco.com> wrote:
> >> > Donald -
> ...
> >> >> 5. MTU Matching
> >> >>
> >> >> ...
> >> >>
> >> >> ? ?An RBridge, RB1, determines the desired campus link MTU by
> >> >> ? ?calculating the minimum of its originatingL1LSPBufferSize and
> the
> >> >> ? ?originatingLSPBufferSize advertised in the link state database
> by
> >> >>
> >> >> LES: These should all be "originatingL1LSPBufferSize".
> >> >> (you have omitted "L1" in some cases)
> >> >>
> >> >> <DEE3> I believe the variable in the LSP is just
> >> >> originatingLSPBufferSize and is L1 or L2 depending on whether the
> >> LSP
> >> >> is L1 or L2.
> >> >
> >> > The TLV name is originatingLSPBufferSize(or LSPBufferSize in
> IANA).
> >> Per
> >> > ISO 10589 there are two variables which an implementation
> maintains:
> >> >
> >> > originatingL1LSPBufferSize
> >> > originatingL2LSPBufferSize
> >> > (they are often the same - but do not have to be as the set of
> >> circuits
> >> > in use at the two levels may be different)
> >> >
> >> > Whether L1 or L2 is in the TLV is determined by the type of PDU it
> is
> >> in
> >> > (Level1LSP or Level2LSP).
> >> >
> >> > There is no variable named originatingLSPBufferSize.
> >> > Since TRILL is limited to L1 only at present, you should be using
> >> > originatingL1LSPBufferSize everywhere.
> >>
> >> I note that RFC 3719, to which you referred me above, uses
> >> originatingL1LSPBufferSize in some contexts and
> >> originatingLSPBufferSize in others. Whether there is a "variable"
> >> named originatingLSPBufferSize depends on what you think a variable
> >> is. We seem to agree that there is a TLV field called
> >> originatingLSPBufferSize and the reference from the draft above to
> "in
> >> the link state database" was meant to refer to that field by its
> >> proper name.
> >
> > We agree that if referring to the type name of the TLV the correct
> name is originatingLSPBufferSize.
> > I think we also agree that what is advertised in the TLV (the value)
> is either originatingL1LSPBufferSize or originatingL2LSPBufferSize. In
> reviewing the draft I think all uses are actually referring to the
> value advertised - not the type name of the TLV - so that is why I
> suggest that all uses in the draft should be
> originatingL1LSPBufferSize.
> 
> I still think it is the field in the link state database that is being
> referred to and it should be called originatingLSPBufferSize. But I'm
> willing to change it to originatingL1LSPBufferSize with other changes
> that make if refer to the originating RBridge's variable. How about:
> 
> "An RBridge, RB1, determines the desired campus link MTU by
> calculating the minimum of its originatingL1LSPBufferSize and the
> originatingL1LSPBufferSize of other RBridges in the campus, as
> advertised in the link state database, but not less than 1,470 bytes."
> 

Works for me.
Thanx.

   Les

> >>
> >> > ...
> ...
> 
> >
> > ? Les
> 
> I glanced at your other comments and think they are best handled via
> separate mail threads.
> 
> Thanks,
> Donald


From carlsonj at workingcode.com  Mon Jan 24 09:05:47 2011
From: carlsonj at workingcode.com (James Carlson)
Date: Mon, 24 Jan 2011 12:05:47 -0500
Subject: [rbridge] [Pppext] working group last call for PPP TRILL
 protocol control protocol [was Re: I-D
 Action:draft-ietf-pppext-trill-protocol-02.txt]
In-Reply-To: <4D3DADF9.4040009@gmail.com>
References: <20110106154501.15655.20204.idtracker@localhost>	<4D334595.3030507@workingcode.com>
	<4D3DADF9.4040009@gmail.com>
Message-ID: <4D3DB16B.5080803@workingcode.com>

William Allen Simpson wrote:
> In any case, I disagree with section 3 item 3 regarding the OUI.  I'm a big
> fan of completely finishing a specification, not leaving holes for later.
> And a bigger fan of zero configuration that eliminates even the possibility
> of an additional operational consideration!

I agree that it'd be nice to fill in this hole, but I'm not so sure how
to accomplish that task.  I don't think IETF OUI plus LCP Magic Number
works -- the Magic Number value is unique for a given endpoint on a
given link, but is not guaranteed to be unique across a network.  But
the IS-IS System ID number does need to be unique across the network,
and its construction based on MAC addresses normally protects that
requirement.

One way to avoid the hole would be to outlaw the use of systems that
lack any way to form an IS-IS System ID, but that seems a little harsh.
 Forcing that corner case to use manual configuration is distasteful,
but the alternatives seem worse, at least to me.

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

From carlsonj at workingcode.com  Mon Jan 24 12:41:55 2011
From: carlsonj at workingcode.com (James Carlson)
Date: Mon, 24 Jan 2011 15:41:55 -0500
Subject: [rbridge] [Pppext] working group last call for PPP TRILL
 protocol control protocol [was Re: I-D
 Action:draft-ietf-pppext-trill-protocol-02.txt]
In-Reply-To: <4D3DCD97.7040005@gmail.com>
References: <20110106154501.15655.20204.idtracker@localhost>	<4D334595.3030507@workingcode.com>	<4D3DADF9.4040009@gmail.com>
	<4D3DB16B.5080803@workingcode.com>	<4D3DC516.1000105@gmail.com>
	<4D3DCD97.7040005@gmail.com>
Message-ID: <4D3DE413.80908@workingcode.com>

William Allen Simpson wrote:
> I'm staring at the TRILL draft, and cannot find anything in the protocol
> to detect, eliminate, or resolve duplicate System ID numbers.  Obviously,
> I'm missing something.  Please advise.

I don't believe that anything can or will do that.  It's assumed into
existence, as far as I understand.

The System ID is used (among other things) for pseudonode generation and
TRILL nickname resolution.  If those aren't unique, then my
understanding is that the network will fly to bits.

I'm not the IS-IS expert here.  If someone else (preferably on the
RBridge mailing list) has an opinion about running a TRILL IS-IS network
where some of the nodes using only point-to-point links have System IDs
that are possibly non-unique, then now is the time to speak up.

But I certainly don't feel comfortable endorsing this sort of usage in
the PPP TRILL draft without review by at least the TRILL group, and
probably the IS-IS group as well.

> Thus, I got the routing religion....  Never use a bridge where a router
> could be used instead.

Indeed.  I agree completely, though I don't think it's really the
problem at hand.  If the user has PPP TRILL links, he's already decided
(for whatever reason) that he wants to bridge.

> Of course, this assumes that the PPP Magic Number has been implemented
> correctly, and it checks the number against all its interfaces to avoid
> loops.  It also assumes you haven't deployed Junipers with the fairly evil
> "ppp magic-number ignore-mismatch".

I see nothing in RFC 1661 section 6.4 requiring or even suggesting a
check across all of the node's interfaces.  Off hand, I don't know of
any that do that, and I do know of a few implementations where such a
test would be architecturally impractical (if not outright impossible).

In any event, I think this is a detour: the real issue is that the IS-IS
System ID must be unique across the IS-IS campus, and PPP's Magic-Number
option doesn't have that quality, even if it has the checks you're
suggesting.

With Ethernet, the assumption is that MAC addresses among systems that
speak IS-IS are unique per the standards.  Whether any vendor is able to
achieve that and/or whether relying on MAC uniqueness is a smart thing
to do is possibly an interesting topic, but I think is certainly one for
a different mailing list.  It doesn't involve PPP.

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

From carlsonj at workingcode.com  Mon Jan 24 17:16:45 2011
From: carlsonj at workingcode.com (James Carlson)
Date: Mon, 24 Jan 2011 20:16:45 -0500
Subject: [rbridge] [Pppext] working group last call for PPP TRILL
 protocol control protocol [was Re: I-D
 Action:draft-ietf-pppext-trill-protocol-02.txt]
In-Reply-To: <4D3E00B9.7050509@gmail.com>
References: <20110106154501.15655.20204.idtracker@localhost>	<4D334595.3030507@workingcode.com>	<4D3DADF9.4040009@gmail.com>
	<4D3DB16B.5080803@workingcode.com>	<4D3DC516.1000105@gmail.com>
	<4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com>
	<4D3E00B9.7050509@gmail.com>
Message-ID: <4D3E247D.9090201@workingcode.com>

On 1/24/11 5:44 PM, William Allen Simpson wrote:
> On 1/24/11 3:41 PM, James Carlson wrote:
>> William Allen Simpson wrote:
>>> I'm staring at the TRILL draft, and cannot find anything in the protocol
>>> to detect, eliminate, or resolve duplicate System ID numbers. 
>>> Obviously,
>>> I'm missing something.  Please advise.
>>
>> I don't believe that anything can or will do that.  It's assumed into
>> existence, as far as I understand.
>>
>> The System ID is used (among other things) for pseudonode generation and
>> TRILL nickname resolution.  If those aren't unique, then my
>> understanding is that the network will fly to bits.
>>
> There is some text about resolving nicknames that aren't unique.  Nicknames
> aren't deterministic on the System ID, though.  They're small, so they have
> a 2*8 average chance of collision.  (Section 3.7)
> 
> I cannot find a description of pseudonode generation.  (Or even a
> definition for "pseudonode".)

It's part of RFC 1142.  I'm no IS-IS expert; it could possibly be just a
LAN-type feature.

The bottom line, though, is that I'm not willing to define a new mode of
operation for IS-IS on my own.  If there's some documentation of how
existing IS-IS systems with only point-to-point links operate without a
System ID, I'll be happy to provide a pointer to it along with an
appropriate synopsis to make it as clear as possible.

I am unable to locate any documentation of that sort.  If you have
pointers, please supply them, and I'll incorporate.

I wrote this draft as a favor to the RBridges chair to describe how the
protocol would work on some medium other than Ethernet.  The TRILL
protocol is designed so that it should be medium-agnostic (at least on
the transport side), but without an existence proof, it's hard to know,
and that's what this draft helps accomplish.

But I don't intend this draft as an extension or modification of IS-IS
in any way.  If extensions are required, then I think it would be best
to withdraw the draft and call it a day.  Someone else will have to
design whatever extensions you and the other reviewers feel are
necessary.  (I don't believe any such extensions are required, but if
that's the case, then I'm out.  I can't do that work.)

> OK, let's wait a bit.
> 
> The questions are:
> 
>  - How does TRILL handle System IDs that are not unique?

I do not know.  But I do know that RFC 1142 goes out of its way to say
that MAC addresses are unique, and that System IDs must also be unique.
 As far as I can tell, it's just assumed.

But this is *not* the IS-IS working group.  I think any questions about
how IS-IS does or does not work really ought to be directed to that
group.  I can't answer them in any reasonable way, and I'm pretty sure
that questions like that are just plain out of scope for this draft.

For that matter, this draft also doesn't address TRILL itself.  It only
addresses the operation of TRILL over PPP links.  If there are design
problems in TRILL itself -- if there needs to be some magic in TRILL
that checks for the "impossible" duplicate System IDs -- then I believe
that this is a generic issue with TRILL, and it should be addressed
outside the scope of the last call for this draft.

If there's a fix to the problem you're describing, then surely it's not
dependent on PPP for operation.  Right?

>  - Are System IDs ever used in the ethernet source or destination fields?

Not that I'm aware of.  They are used in the generation of LSPs as part
of IS-IS, though.

>> I see nothing in RFC 1661 section 6.4 requiring or even suggesting a
>> check across all of the node's interfaces.  Off hand, I don't know of
>> any that do that, and I do know of a few implementations where such a
>> test would be architecturally impractical (if not outright impossible).
>>
> The whole point is to avoid loops.  It is "a unique number".  You cannot
> avoid a loop with your *own* interfaces without checking against any
> existing interfaces to see whether your chosen number is unique....

It's to avoid looped-back interfaces.  That's exactly what the RFC says.
 Not "avoid loops."  The RFC goes to great length to describe when and
why an implementation must generate a new Magic Number value due to
conflict, and at no point does it describe comparisons against any value
except the two values used by the two peers on the link.

I agree that it'd be nice to have it do more, and that what you're
suggesting sounds reasonable.  However, it's certainly not what the RFC
says.

And worse still, even if the RFC were to describe the mechanism you're
suggesting, IT WOULD NOT HELP!  The requirement in IS-IS is for
network-wide uniqueness, and merely checking all of your own links --
but not those of all of the nodes in the network -- is insufficient to
meet that goal.  Nothing PPP does can help with that.

Thus, I believe this entire discussion about the operation of the LCP
Magic-Number option is without a point.

> Certainly, I'd never expect connecting serial port 1 to serial port 2
> on the same machine would ever pass the magic number test.
> 
> (Sometimes I wonder, how many more details must we write in specifications,
> when something this obvious is missed by some implementers?)

If you'd like to publish an update to RFC 1661 with this sort of
restriction, that sounds fine to me.  For what it's worth, though, I
can't say I know of any implementations that will pass this new stricter
test.

In particular, the common CMU/ANU/samba.org pppd implementation would
not pass.  It has no means of comparing Magic-Number option values
across links.  The control portion of each link runs in a completely
different address space -- different processes.  It'd require a database
similar to the one currently used for RFC 1990 E-Ds and MP in order to
implement it, and given the sorts of problems seen with that, it's not
what I'd call an improvement.

>> With Ethernet, the assumption is that MAC addresses among systems that
>> speak IS-IS are unique per the standards.  Whether any vendor is able to
>> achieve that and/or whether relying on MAC uniqueness is a smart thing
>> to do is possibly an interesting topic, but I think is certainly one for
>> a different mailing list.  It doesn't involve PPP.
>>
> I don't like assumptions.  That's a tautology.
> 
> If the proven existing MAC uniqueness in the field is already *less* than
> known mathematical uniqueness of the PPP Magic Number, then there's no
> PPP-specific issue to be solved.  In either case of conflict, then manual
> configuration is required.
> 
> The chance of PPP collision is *much* rarer.  Automatic PPP configuration
> should be part of this specification.

I still don't understand why this draft has to define this new special
usage.  We're talking about a corner case out of a corner case -- a
special TRILL-speaking system with PPP links but that has zero Ethernet
interfaces.  Who is going to build such a beast?  And why?

In the unlikely case that someone does build that thing, I'd be happy to
let that person define exactly how the required IS-IS System ID is
computed, formed, configured, guessed, or drawn carefully out of the
ether.  For the simple case of allowing a TRILL-speaking system that
already has its own means of deriving a System ID (whatever that may be)
to use PPP links between other cooperating systems, I believe the
existing text is sufficient.

To be clear: TRILL over PPP allows the packets to be exchanged in a
reasonable manner.  Unlike Ethernet, it does not come with a burned-in
"guaranteed globally unique" MAC address, and thus any existing text in
TRILL and/or IS-IS documents that assume the existence of such an
address on at least one link in the system -- such as section B.2.1.3 of
RFC 1142 -- will have to look elsewhere for that value.  PPP can't
supply it.

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

From d3e3e3 at gmail.com  Mon Jan 24 23:35:30 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 25 Jan 2011 02:35:30 -0500
Subject: [rbridge] [Pppext] working group last call for PPP TRILL
 protocol control protocol [was Re: I-D
 Action:draft-ietf-pppext-trill-protocol-02.txt]
In-Reply-To: <4D3DCD97.7040005@gmail.com>
References: <20110106154501.15655.20204.idtracker@localhost>
	<4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com>
	<4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com>
	<4D3DCD97.7040005@gmail.com>
Message-ID: <AANLkTinH-EjsxxO5DkKWRnuKXP+iA9X=hKO79L03WGRz@mail.gmail.com>

Hi,

On Mon, Jan 24, 2011 at 2:05 PM, William Allen Simpson
<william.allen.simpson at gmail.com> wrote:
> On 1/24/11 1:29 PM, William Allen Simpson wrote:
>>
>> On 1/24/11 12:05 PM, James Carlson wrote:
>>>
>>> I agree that it'd be nice to fill in this hole, but I'm not so sure how
>>> to accomplish that task. I don't think IETF OUI plus LCP Magic Number
>>> works -- the Magic Number value is unique for a given endpoint on a
>>> given link, but is not guaranteed to be unique across a network. But
>>> the IS-IS System ID number does need to be unique across the network,
>>> and its construction based on MAC addresses normally protects that
>>> requirement.
>>>
>> It must be nice to live in a world with unique MAC addresses! In my
>> experience, I've run into rather a lot of them that are not -- and it
>> will be much worse in this cross-linked multi-media environment. Many
>> vendors think that it's OK to reuse the MAC address for different link
>> speeds and types.
>>
> I'm staring at the TRILL draft, and cannot find anything in the protocol
> to detect, eliminate, or resolve duplicate System ID numbers. ?Obviously,
> I'm missing something. ?Please advise.

You are looking in the wrong place. The unique System ID requirement
is an IS-IS requirement.

It is my impression that manufacturers of ISIS routers either allocate
a MAC address under their OUI to use as System ID or use the MAC
address of one of their interfaces. Maybe, in this instance, they are
more careful to not duplicate from some other box they built. But it
doesn't matter what they do. It's an IS-IS requirement and their
problem.

Maybe the draft should just say less about this.

Donald

PS: Current traveling so I'm a bit out of phase...

>> The only way that the Magic Number has any significant chance to ever be
>> non-unique would be a very large number of PPP-only bridges in the
>> network,
>> on the order of 2**16. Probably best to stick an IP router in there....
>>
> To elaborate, I've an old story to tell. ?Once upon a time, Michigan State
> University supposedly had the world's largest bridged ethernet, covering
> many square miles. ?Performance was abysmal. ?But once I stuck a 286 box
> with KA9Q net (this was circa 1985) between the computing center and
> engineering, performance miraculously improved!
>
> (The problem turned out to be fragments inserted by the IBM in the
> administration building next door to the computing center.)
>
> Thus, I got the routing religion.... ?Never use a bridge where a router
> could be used instead.
>
> I really doubt we'll ever see more than one or two PPP-only Rbridges in a
> single installation. ?The point being that PPP is vastly more robust than
> ethernet -- and you shouldn't let the good enough (ethernet) be the enemy
> of the better (PPP).
>
>> If the PPP-only bridges are talking to each other, there will *never* be
>> any non-unique numbers. That's the more likely case of centrally
>> located PPP-only bridges.
>>
> Of course, this assumes that the PPP Magic Number has been implemented
> correctly, and it checks the number against all its interfaces to avoid
> loops. ?It also assumes you haven't deployed Junipers with the fairly evil
> "ppp magic-number ignore-mismatch".


From d3e3e3 at gmail.com  Mon Jan 24 23:58:00 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 25 Jan 2011 02:58:00 -0500
Subject: [rbridge] [Pppext] working group last call for PPP TRILL
 protocol control protocol [was Re: I-D
 Action:draft-ietf-pppext-trill-protocol-02.txt]
In-Reply-To: <4D3E00B9.7050509@gmail.com>
References: <20110106154501.15655.20204.idtracker@localhost>
	<4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com>
	<4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com>
	<4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com>
	<4D3E00B9.7050509@gmail.com>
Message-ID: <AANLkTinqbPiGKRYsy4YwQA65-1eszKd4Xv5QPEGAUeRs@mail.gmail.com>

Hi,

On Mon, Jan 24, 2011 at 5:44 PM, William Allen Simpson
<william.allen.simpson at gmail.com> wrote:
> On 1/24/11 3:41 PM, James Carlson wrote:
>>
>> William Allen Simpson wrote:
>>>
>>> I'm staring at the TRILL draft, and cannot find anything in the protocol
>>> to detect, eliminate, or resolve duplicate System ID numbers. ?Obviously,
>>> I'm missing something. ?Please advise.
>>
>> I don't believe that anything can or will do that. ?It's assumed into
>> existence, as far as I understand.
>>
>> The System ID is used (among other things) for pseudonode generation and
>> TRILL nickname resolution. ?If those aren't unique, then my
>> understanding is that the network will fly to bits.
>>
> There is some text about resolving nicknames that aren't unique. ?Nicknames
> aren't deterministic on the System ID, though. ?They're small, so they have
> a 2*8 average chance of collision. ?(Section 3.7)

Nickname resolution is dynamic so collisions get resolved.

> I cannot find a description of pseudonode generation. ?(Or even a
> definition for "pseudonode".)

That's because all of that is part of IS-IS. You need to start with
ISO 10589, the 2002 edition.

>> I'm not the IS-IS expert here. ?If someone else (preferably on the
>> RBridge mailing list) has an opinion about running a TRILL IS-IS network
>> where some of the nodes using only point-to-point links have System IDs
>> that are possibly non-unique, then now is the time to speak up.
>>
>> But I certainly don't feel comfortable endorsing this sort of usage in
>> the PPP TRILL draft without review by at least the TRILL group, and
>> probably the IS-IS group as well.
>>
> OK, let's wait a bit.
>
> The questions are:
>
> ?- How does TRILL handle System IDs that are not unique?

System IDs are used to uniquely identify IS-IS router in the link
state database. There is no TRILL specific stuff related to non-unique
System IDs. It's all IS-IS.

> ?- Are System IDs ever used in the ethernet source or destination fields?

There is no requirement to ever to that. Since they are the same size
you can. As far as I know (which isn't that much), most manufacturers
of IS-IS switches either allocate an MAC address they control to use
as the System ID for a box or, a bit more commonly, use the MAC
address of one of the boxes interface, such as the numerically lowest
interface MAC address.

There is no requirement for the MAC interfaces of RBridges in a campus
to all have unique addresses as long as all the RBridges connected to
a particular link have unique MAC addresses over that link. But the
System IDs must be unique across the campus as per IS-IS subnet
independent functions requirement.

>> I see nothing in RFC 1661 section 6.4 requiring or even suggesting a
>> check across all of the node's interfaces. ?Off hand, I don't know of
>> any that do that, and I do know of a few implementations where such a
>> test would be architecturally impractical (if not outright impossible).
>>
> The whole point is to avoid loops. ?It is "a unique number". ?You cannot
> avoid a loop with your *own* interfaces without checking against any
> existing interfaces to see whether your chosen number is unique....
>
> Certainly, I'd never expect connecting serial port 1 to serial port 2
> on the same machine would ever pass the magic number test.
>
> (Sometimes I wonder, how many more details must we write in specifications,
> when something this obvious is missed by some implementers?)
>
>
>> With Ethernet, the assumption is that MAC addresses among systems that
>> speak IS-IS are unique per the standards. ?Whether any vendor is able to
>> achieve that and/or whether relying on MAC uniqueness is a smart thing
>> to do is possibly an interesting topic, but I think is certainly one for
>> a different mailing list. ?It doesn't involve PPP.
>>
> I don't like assumptions. ?That's a tautology.
>
> If the proven existing MAC uniqueness in the field is already *less* than
> known mathematical uniqueness of the PPP Magic Number, then there's no
> PPP-specific issue to be solved. ?In either case of conflict, then manual
> configuration is required.

See above. MAC address uniqueness isn't the same as System ID
uniqueness although in practice they might be conflated sometimes.

Donald


From d3e3e3 at gmail.com  Tue Jan 25 10:08:50 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 25 Jan 2011 13:08:50 -0500
Subject: [rbridge] [Pppext] working group last call for PPP TRILL
 protocol control protocol [was Re: I-D
 Action:draft-ietf-pppext-trill-protocol-02.txt]
In-Reply-To: <4D3E247D.9090201@workingcode.com>
References: <20110106154501.15655.20204.idtracker@localhost>
	<4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com>
	<4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com>
	<4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com>
	<4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com>
Message-ID: <AANLkTi=+K-Kzsc+kahrmBoj1oC0WBzj7DYquS5ySCpP6@mail.gmail.com>

Hi James,

I think your position below is reasonable. The System ID of an IS-IS
router is certainly not required to be any sort of MAC address, it
just has to be a 48-bit quantity unique among the IS-IS routers whose
link state entries need to be distinguished.

Perhaps Section 3, point 3, should be reworded to something like: "In
the case of an RBridge with only PPP links, the practice of using the
MAC address of an interface for the IS-IS System ID will not be
available. The implementor will have to use other means, such as
deriving a System ID from a MAC address allocated to the device as a
whole, to assure that it has a campus-wide unique System ID."

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

On Mon, Jan 24, 2011 at 8:16 PM, James Carlson <carlsonj at workingcode.com> wrote:
> On 1/24/11 5:44 PM, William Allen Simpson wrote:
>> On 1/24/11 3:41 PM, James Carlson wrote:
>>> William Allen Simpson wrote:
>>>> I'm staring at the TRILL draft, and cannot find anything in the protocol
>>>> to detect, eliminate, or resolve duplicate System ID numbers.
>>>> Obviously,
>>>> I'm missing something. ?Please advise.
>>>
>>> I don't believe that anything can or will do that. ?It's assumed into
>>> existence, as far as I understand.
>>>
>>> The System ID is used (among other things) for pseudonode generation and
>>> TRILL nickname resolution. ?If those aren't unique, then my
>>> understanding is that the network will fly to bits.
>>>
>> There is some text about resolving nicknames that aren't unique. ?Nicknames
>> aren't deterministic on the System ID, though. ?They're small, so they have
>> a 2*8 average chance of collision. ?(Section 3.7)
>>
>> I cannot find a description of pseudonode generation. ?(Or even a
>> definition for "pseudonode".)
>
> It's part of RFC 1142. ?I'm no IS-IS expert; it could possibly be just a
> LAN-type feature.
>
> The bottom line, though, is that I'm not willing to define a new mode of
> operation for IS-IS on my own. ?If there's some documentation of how
> existing IS-IS systems with only point-to-point links operate without a
> System ID, I'll be happy to provide a pointer to it along with an
> appropriate synopsis to make it as clear as possible.
>
> I am unable to locate any documentation of that sort. ?If you have
> pointers, please supply them, and I'll incorporate.
>
> I wrote this draft as a favor to the RBridges chair to describe how the
> protocol would work on some medium other than Ethernet. ?The TRILL
> protocol is designed so that it should be medium-agnostic (at least on
> the transport side), but without an existence proof, it's hard to know,
> and that's what this draft helps accomplish.
>
> But I don't intend this draft as an extension or modification of IS-IS
> in any way. ?If extensions are required, then I think it would be best
> to withdraw the draft and call it a day. ?Someone else will have to
> design whatever extensions you and the other reviewers feel are
> necessary. ?(I don't believe any such extensions are required, but if
> that's the case, then I'm out. ?I can't do that work.)
>
>> OK, let's wait a bit.
>>
>> The questions are:
>>
>> ?- How does TRILL handle System IDs that are not unique?
>
> I do not know. ?But I do know that RFC 1142 goes out of its way to say
> that MAC addresses are unique, and that System IDs must also be unique.
> ?As far as I can tell, it's just assumed.
>
> But this is *not* the IS-IS working group. ?I think any questions about
> how IS-IS does or does not work really ought to be directed to that
> group. ?I can't answer them in any reasonable way, and I'm pretty sure
> that questions like that are just plain out of scope for this draft.
>
> For that matter, this draft also doesn't address TRILL itself. ?It only
> addresses the operation of TRILL over PPP links. ?If there are design
> problems in TRILL itself -- if there needs to be some magic in TRILL
> that checks for the "impossible" duplicate System IDs -- then I believe
> that this is a generic issue with TRILL, and it should be addressed
> outside the scope of the last call for this draft.
>
> If there's a fix to the problem you're describing, then surely it's not
> dependent on PPP for operation. ?Right?
>
>> ?- Are System IDs ever used in the ethernet source or destination fields?
>
> Not that I'm aware of. ?They are used in the generation of LSPs as part
> of IS-IS, though.
>
>>> I see nothing in RFC 1661 section 6.4 requiring or even suggesting a
>>> check across all of the node's interfaces. ?Off hand, I don't know of
>>> any that do that, and I do know of a few implementations where such a
>>> test would be architecturally impractical (if not outright impossible).
>>>
>> The whole point is to avoid loops. ?It is "a unique number". ?You cannot
>> avoid a loop with your *own* interfaces without checking against any
>> existing interfaces to see whether your chosen number is unique....
>
> It's to avoid looped-back interfaces. ?That's exactly what the RFC says.
> ?Not "avoid loops." ?The RFC goes to great length to describe when and
> why an implementation must generate a new Magic Number value due to
> conflict, and at no point does it describe comparisons against any value
> except the two values used by the two peers on the link.
>
> I agree that it'd be nice to have it do more, and that what you're
> suggesting sounds reasonable. ?However, it's certainly not what the RFC
> says.
>
> And worse still, even if the RFC were to describe the mechanism you're
> suggesting, IT WOULD NOT HELP! ?The requirement in IS-IS is for
> network-wide uniqueness, and merely checking all of your own links --
> but not those of all of the nodes in the network -- is insufficient to
> meet that goal. ?Nothing PPP does can help with that.
>
> Thus, I believe this entire discussion about the operation of the LCP
> Magic-Number option is without a point.
>
>> Certainly, I'd never expect connecting serial port 1 to serial port 2
>> on the same machine would ever pass the magic number test.
>>
>> (Sometimes I wonder, how many more details must we write in specifications,
>> when something this obvious is missed by some implementers?)
>
> If you'd like to publish an update to RFC 1661 with this sort of
> restriction, that sounds fine to me. ?For what it's worth, though, I
> can't say I know of any implementations that will pass this new stricter
> test.
>
> In particular, the common CMU/ANU/samba.org pppd implementation would
> not pass. ?It has no means of comparing Magic-Number option values
> across links. ?The control portion of each link runs in a completely
> different address space -- different processes. ?It'd require a database
> similar to the one currently used for RFC 1990 E-Ds and MP in order to
> implement it, and given the sorts of problems seen with that, it's not
> what I'd call an improvement.
>
>>> With Ethernet, the assumption is that MAC addresses among systems that
>>> speak IS-IS are unique per the standards. ?Whether any vendor is able to
>>> achieve that and/or whether relying on MAC uniqueness is a smart thing
>>> to do is possibly an interesting topic, but I think is certainly one for
>>> a different mailing list. ?It doesn't involve PPP.
>>>
>> I don't like assumptions. ?That's a tautology.
>>
>> If the proven existing MAC uniqueness in the field is already *less* than
>> known mathematical uniqueness of the PPP Magic Number, then there's no
>> PPP-specific issue to be solved. ?In either case of conflict, then manual
>> configuration is required.
>>
>> The chance of PPP collision is *much* rarer. ?Automatic PPP configuration
>> should be part of this specification.
>
> I still don't understand why this draft has to define this new special
> usage. ?We're talking about a corner case out of a corner case -- a
> special TRILL-speaking system with PPP links but that has zero Ethernet
> interfaces. ?Who is going to build such a beast? ?And why?
>
> In the unlikely case that someone does build that thing, I'd be happy to
> let that person define exactly how the required IS-IS System ID is
> computed, formed, configured, guessed, or drawn carefully out of the
> ether. ?For the simple case of allowing a TRILL-speaking system that
> already has its own means of deriving a System ID (whatever that may be)
> to use PPP links between other cooperating systems, I believe the
> existing text is sufficient.
>
> To be clear: TRILL over PPP allows the packets to be exchanged in a
> reasonable manner. ?Unlike Ethernet, it does not come with a burned-in
> "guaranteed globally unique" MAC address, and thus any existing text in
> TRILL and/or IS-IS documents that assume the existence of such an
> address on at least one link in the system -- such as section B.2.1.3 of
> RFC 1142 -- will have to look elsewhere for that value. ?PPP can't
> supply it.
>
> --
> 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 carlsonj at workingcode.com  Tue Jan 25 10:17:23 2011
From: carlsonj at workingcode.com (James Carlson)
Date: Tue, 25 Jan 2011 13:17:23 -0500
Subject: [rbridge] [Pppext] working group last call for PPP TRILL
 protocol control protocol [was Re: I-D
 Action:draft-ietf-pppext-trill-protocol-02.txt]
In-Reply-To: <AANLkTi=+K-Kzsc+kahrmBoj1oC0WBzj7DYquS5ySCpP6@mail.gmail.com>
References: <20110106154501.15655.20204.idtracker@localhost>
	<4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com>
	<4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com>
	<4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com>
	<4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com>
	<AANLkTi=+K-Kzsc+kahrmBoj1oC0WBzj7DYquS5ySCpP6@mail.gmail.com>
Message-ID: <4D3F13B3.9070706@workingcode.com>

Donald Eastlake wrote:
> Hi James,
> 
> I think your position below is reasonable. The System ID of an IS-IS
> router is certainly not required to be any sort of MAC address, it
> just has to be a 48-bit quantity unique among the IS-IS routers whose
> link state entries need to be distinguished.
> 
> Perhaps Section 3, point 3, should be reworded to something like: "In
> the case of an RBridge with only PPP links, the practice of using the
> MAC address of an interface for the IS-IS System ID will not be
> available. The implementor will have to use other means, such as
> deriving a System ID from a MAC address allocated to the device as a
> whole, to assure that it has a campus-wide unique System ID."

That seems quite reasonable to me.  I just want to steer clear of
writing too much of the IS-IS requirements into this draft, as I think
the overall system design implications are out of scope.

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

From vishwas.ietf at gmail.com  Tue Jan 25 10:31:55 2011
From: vishwas.ietf at gmail.com (Vishwas Manral)
Date: Tue, 25 Jan 2011 10:31:55 -0800
Subject: [rbridge] [Pppext] working group last call for PPP TRILL
 protocol control protocol [was Re: I-D
 Action:draft-ietf-pppext-trill-protocol-02.txt]
In-Reply-To: <4D3F13B3.9070706@workingcode.com>
References: <20110106154501.15655.20204.idtracker@localhost>
	<4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com>
	<4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com>
	<4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com>
	<4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com>
	<AANLkTi=+K-Kzsc+kahrmBoj1oC0WBzj7DYquS5ySCpP6@mail.gmail.com>
	<4D3F13B3.9070706@workingcode.com>
Message-ID: <AANLkTikJjMcc1es7qyabddcXBFS93sRwcRO7XvPQzbe2@mail.gmail.com>

Hi James,

IMHO there should be no mention of IS-IS in the PPP draft. As IS-IS is
a control plane protocol (we could as well use static Rbridge route
entries - a requirement we have heard from 2 of our customers) and PPP
is the data plane.

Thanks,
Vishwas

On Tue, Jan 25, 2011 at 10:17 AM, James Carlson
<carlsonj at workingcode.com> wrote:
> Donald Eastlake wrote:
>> Hi James,
>>
>> I think your position below is reasonable. The System ID of an IS-IS
>> router is certainly not required to be any sort of MAC address, it
>> just has to be a 48-bit quantity unique among the IS-IS routers whose
>> link state entries need to be distinguished.
>>
>> Perhaps Section 3, point 3, should be reworded to something like: "In
>> the case of an RBridge with only PPP links, the practice of using the
>> MAC address of an interface for the IS-IS System ID will not be
>> available. The implementor will have to use other means, such as
>> deriving a System ID from a MAC address allocated to the device as a
>> whole, to assure that it has a campus-wide unique System ID."
>
> That seems quite reasonable to me. ?I just want to steer clear of
> writing too much of the IS-IS requirements into this draft, as I think
> the overall system design implications are out of scope.
>
> --
> James Carlson ? ? ? ? 42.703N 71.076W ? ? ? ? <carlsonj at workingcode.com>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>


From carlsonj at workingcode.com  Tue Jan 25 11:04:13 2011
From: carlsonj at workingcode.com (James Carlson)
Date: Tue, 25 Jan 2011 14:04:13 -0500
Subject: [rbridge] [Pppext] working group last call for PPP TRILL
 protocol control protocol [was Re: I-D
 Action:draft-ietf-pppext-trill-protocol-02.txt]
In-Reply-To: <AANLkTikJjMcc1es7qyabddcXBFS93sRwcRO7XvPQzbe2@mail.gmail.com>
References: <20110106154501.15655.20204.idtracker@localhost>	<4D334595.3030507@workingcode.com>	<4D3DADF9.4040009@gmail.com>	<4D3DB16B.5080803@workingcode.com>	<4D3DC516.1000105@gmail.com>	<4D3DCD97.7040005@gmail.com>	<4D3DE413.80908@workingcode.com>	<4D3E00B9.7050509@gmail.com>	<4D3E247D.9090201@workingcode.com>	<AANLkTi=+K-Kzsc+kahrmBoj1oC0WBzj7DYquS5ySCpP6@mail.gmail.com>	<4D3F13B3.9070706@workingcode.com>
	<AANLkTikJjMcc1es7qyabddcXBFS93sRwcRO7XvPQzbe2@mail.gmail.com>
Message-ID: <4D3F1EAD.5040901@workingcode.com>

Vishwas Manral wrote:
> Hi James,
> 
> IMHO there should be no mention of IS-IS in the PPP draft. As IS-IS is
> a control plane protocol (we could as well use static Rbridge route
> entries - a requirement we have heard from 2 of our customers) and PPP
> is the data plane.

I assume you're talking about the discussion of the System ID issue, and
not the TLSP Packet Format described in section 2.3 for carrying IS-IS
packets.  (If you *do* mean TLSP, then I'll probably need some
additional clarification.)

I certainly agree with the sentiment (I don't like duplicating
documentation at all, particularly for this issue), but the existing
notation about MAC addresses (and the lack of them on PPP) was added at
the behest of other reviewers who found that it was confusing to match
up the PPP TRILL draft with the primary TRILL documentation without some
indication that there are differences here.

I find I'm walking a narrow line.  I want to provide a little guidance
so that it's clear what's expected here, but I also want to avoid either
just copying hunks of the TRILL and IS-IS documentation or (worse)
carving out special exceptions.  I probably can't please everyone.

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

From anil at charter.net  Wed Jan 26 08:23:41 2011
From: anil at charter.net (Anil Rijhsinghani)
Date: Wed, 26 Jan 2011 11:23:41 -0500
Subject: [rbridge] Request for review of
 draft-ietf-trill-rbridge-mib-01.txt
Message-ID: <20110126112341.AA6XN.11297223.root@mp08>

Hi Donald,

> I think that Sz, the campus wide minimum MTU that an RBridge has
> calculated, should be a read-only per-RBridge MIB object and that it
> should be possible for a change in Sz to cause a notification.

I?ll add Sz as a read-only object to the TRILL group, next to MinMtuDesired which
is a read-write object.

I would suggest we not make a changing value of this a notification, as it could
lead to the trap sink being flooded simultaneously with a large number of
notifications. This is an object that an NMS will want to monitor or poll when
necessary.

Regards,
Anil

From: Donald Eastlake <d3e3e3 at gmail.com>
Date: December 27, 2010 10:26:12 PM EST
To: "Developing a hybrid router/bridge." <rbridge at postel.org>
Subject: Re: [rbridge] Request for review of draft-ietf-trill-rbridge-mib-01.txt

Hi,

It would be helpful if people would review the MIB document. Here is a
comment of mine:

I think that Sz, the campus wide minimum MTU that an RBridge has
calculated, should be a read-only per-RBridge MIB object and that it
should be possible for a change in Sz to cause a notification.

Thanks,
Donald



From anil at charter.net  Wed Jan 26 08:42:52 2011
From: anil at charter.net (Anil Rijhsinghani)
Date: Wed, 26 Jan 2011 11:42:52 -0500
Subject: [rbridge] Request for review
 ofdraft-ietf-trill-rbridge-mib-01.txt
Message-ID: <20110126114252.N5ZK9.11297420.root@mp08>

Hi Dan,

> 1. The relationship with other MIB module sections refer to the IETF RFCs.
> However, since 2006 the development of the Bridge MIB modules and their
> successors were transferred to IEEE 802.1. I suggest to define the
> relationship sections in relation to the IEEE MIB modules defined in
> IEEE 802.1ap

Will do.

> 2. Some of the objects with read-create MAX-ACCESS need DEFAULT clauses.
> In some cases the default is mention in the DESCRIPTION clause - this is not
> sufficient

OK, I'll add these clauses.

> 3. MIB structure - better group all MIB groups that define objects under one
> sub-tree
> rbridgeObjects           OBJECT IDENTIFIER ::= { rbridgeMIB 1 }

In other words, define a single sub-tree for objects, one for
notifications & one for conformance? It adds another level, but can certainly
be done. I?ve structured it in a manner parallel to earlier versions of the
Bridge MIB.

> 4. The current level of detail in the Security Considerations section is not
> sufficient.

Yes, will expand this section.

> 5. running libsmi compilation leads to a number of errors and warnings that need
> to be fixed. 

I compiled with a commercial manager prior to publication; will try libsmi. It would
be nice to have a MIB compiler on the IETF tools directory to check compliance,
if at all possible.

Regards,
Anil

From: "Romascanu, Dan (Dan)" <dromasca at avaya.com>
Date: January 3, 2011 11:09:55 AM EST
To: "Donald Eastlake" <d3e3e3 at gmail.com>, "Developing a hybrid router/bridge." <rbridge at postel.org>
Subject: Re: [rbridge] Request for review ofdraft-ietf-trill-rbridge-mib-01.txt

I did not have time for a full review, but here are my comments from a first quick examination of the document

1. The relationship with other MIB module sections refer to the IETF RFCs. However, since 2006 the development of the Bridge MIB modules and their successors were transferred to IEEE 802.1. I suggest to define the relationship sections in relation to the IEEE MIB modules defined in IEEE 802.1ap

2. Some of the objects with read-create MAX-ACCESS need DEFAULT clauses. In some cases the default is mention in the DESCRIPTION clause - this is not sufficient

3. MIB structure - better group all MIB groups that define objects under one sub-tree 

rbridgeObjects           OBJECT IDENTIFIER ::= { rbridgeMIB 1 } 

4. The current level of detail in the Security Considerations section is not sufficient. 

5. running libsmi compilation leads to a number of errors and warnings that need to be fixed. 

Regards,

Dan



From anil at charter.net  Wed Jan 26 08:59:28 2011
From: anil at charter.net (Anil Rijhsinghani)
Date: Wed, 26 Jan 2011 11:59:28 -0500
Subject: [rbridge] draft-ietf-trill-rbridge-mib
Message-ID: <20110126115928.NLY9L.11297578.root@mp08>

Hi Vishwas,

> 1. I think we should have a seperate tree for the Rbridge. I notice 
> some of the tables are the same as IS-IS. It will be very confusing to 
> code a MBI which is half IS-IS and half TRILL IS-IS.

IETF convention is to leverage pre-existing MIBs for pre-defined protocols.
Otherwise, we would end up with bloated MIBs and duplicated work.
In this MIB we have re-used management work done for IS-IS as well as Bridges,
and added new objects defined by the TRILL protocol.

> 2. There is no information for MultiTopology.

We do not yet have multi-topology in TRILL.

> 3. Another thing that needs to be kept is the MTU table. Which has MTU 
> information received from all the devices in the network. I know we 
> have MTU objects at a link and neighbor basis.

What would be the management benefit of adding such a (potentially
huge) table? It seems to me that it would suffice for a manager to know
the configurable Desired MTU per Rbridge, its neighbors, and the agreed MTU for
the campus. For information regarding other Rbridges, it can visit those Rbridges.

> 4. We probably need tohave Multicast Address listner  table too.

The group rbridgeSnooping contains a minimal level of multicast listener and snooping information necessary to support TRILL. Adding all objects necessary for
IPv4 and IPv6 snooping is a non-goal and belongs in an independent Snooping/Listener MIB, as this is not functionality defined by TRILL. If there
are additional objects you believe are necessary specifically to support TRILL,
please list.

> 5. We will need a table for the the information in the system for 
> distribution trees, and information advertized by each system, or 
> atleast a way to change the values to be configured for a system.

There is a group and table for distribution trees, rbridgeDtree and rbridgeDtreeTable. If you believe there are useful configurable objects
missing, could you please list them?

Regards,
Anil

-----Original Message-----
From: Vishwas Manral [mailto:vishwas.ietf at gmail.com]
Sent: Monday, January 17, 2011 1:17 PM
To: rbridge at postel.org
Cc: Rijhsinghani, Anil; kate.zebrose at alum.mit.edu
Subject: draft-ietf-trill-rbridge-mib

Hi Anil/ Kate,

I briefly looked at the TRILL MIB and had the following top level comments:

1. I think we should have a seperate tree for the Rbridge. I notice some of the tables are the same as IS-IS. It will be very confusing to code a MBI which is half IS-IS and half TRILL IS-IS.
2. There is no information for MultiTopology.
3. Another thing that needs to be kept is the MTU table. Which has MTU information received from all the devices in the network. I know we have MTU objects at a link and neighbor basis.
4. We probably need tohave Multicast Address listner  table too.
5. We will need a table for the the information in the system for distribution trees, and information advertized by each system, or atleast a way to change the values to be configured for a system.

Thanks,
Vishwas


From dromasca at avaya.com  Wed Jan 26 09:48:12 2011
From: dromasca at avaya.com (Romascanu, Dan (Dan))
Date: Wed, 26 Jan 2011 18:48:12 +0100
Subject: [rbridge] Request for review
	ofdraft-ietf-trill-rbridge-mib-01.txt
In-Reply-To: <20110126114252.N5ZK9.11297420.root@mp08>
References: <20110126114252.N5ZK9.11297420.root@mp08>
Message-ID: <EDC652A26FB23C4EB6384A4584434A0402B3190F@307622ANEX5.global.avaya.com>

Hi Anil,

Thank you for your response and for addressing my comments. 

To your last point - libsmi
http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/ is not maintained by
the IETF tools team but by volunteers from a German university. It is
however referenced from the OPS Area wiki page - see
https://svn.tools.ietf.org/area/ops/trac/wiki/mib-review-tools

Regards,

Dan


> -----Original Message-----
> From: Anil Rijhsinghani [mailto:anil at charter.net] 
> Sent: Wednesday, January 26, 2011 6:43 PM
> To: Romascanu, Dan (Dan)
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Request for review 
> ofdraft-ietf-trill-rbridge-mib-01.txt
> 
> Hi Dan,
> 
> > 1. The relationship with other MIB module sections refer to 
> the IETF RFCs.
> > However, since 2006 the development of the Bridge MIB modules and 
> > their successors were transferred to IEEE 802.1. I suggest 
> to define 
> > the relationship sections in relation to the IEEE MIB 
> modules defined 
> > in IEEE 802.1ap
> 
> Will do.
> 
> > 2. Some of the objects with read-create MAX-ACCESS need 
> DEFAULT clauses.
> > In some cases the default is mention in the DESCRIPTION 
> clause - this 
> > is not sufficient
> 
> OK, I'll add these clauses.
> 
> > 3. MIB structure - better group all MIB groups that define objects 
> > under one sub-tree
> > rbridgeObjects           OBJECT IDENTIFIER ::= { rbridgeMIB 1 }
> 
> In other words, define a single sub-tree for objects, one for 
> notifications & one for conformance? It adds another level, 
> but can certainly be done. I've structured it in a manner 
> parallel to earlier versions of the Bridge MIB.
> 
> > 4. The current level of detail in the Security 
> Considerations section 
> > is not sufficient.
> 
> Yes, will expand this section.
> 
> > 5. running libsmi compilation leads to a number of errors 
> and warnings 
> > that need to be fixed.
> 
> I compiled with a commercial manager prior to publication; 
> will try libsmi. It would be nice to have a MIB compiler on 
> the IETF tools directory to check compliance, if at all possible.
> 
> Regards,
> Anil
> 
> From: "Romascanu, Dan (Dan)" <dromasca at avaya.com>
> Date: January 3, 2011 11:09:55 AM EST
> To: "Donald Eastlake" <d3e3e3 at gmail.com>, "Developing a 
> hybrid router/bridge." <rbridge at postel.org>
> Subject: Re: [rbridge] Request for review 
> ofdraft-ietf-trill-rbridge-mib-01.txt
> 
> I did not have time for a full review, but here are my 
> comments from a first quick examination of the document
> 
> 1. The relationship with other MIB module sections refer to 
> the IETF RFCs. However, since 2006 the development of the 
> Bridge MIB modules and their successors were transferred to 
> IEEE 802.1. I suggest to define the relationship sections in 
> relation to the IEEE MIB modules defined in IEEE 802.1ap
> 
> 2. Some of the objects with read-create MAX-ACCESS need 
> DEFAULT clauses. In some cases the default is mention in the 
> DESCRIPTION clause - this is not sufficient
> 
> 3. MIB structure - better group all MIB groups that define 
> objects under one sub-tree 
> 
> rbridgeObjects           OBJECT IDENTIFIER ::= { rbridgeMIB 1 } 
> 
> 4. The current level of detail in the Security Considerations 
> section is not sufficient. 
> 
> 5. running libsmi compilation leads to a number of errors and 
> warnings that need to be fixed. 
> 
> Regards,
> 
> Dan
> 
> 


From d3e3e3 at gmail.com  Wed Jan 26 10:07:26 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Wed, 26 Jan 2011 13:07:26 -0500
Subject: [rbridge] Request for review of
	draft-ietf-trill-rbridge-mib-01.txt
In-Reply-To: <20110126112341.AA6XN.11297223.root@mp08>
References: <20110126112341.AA6XN.11297223.root@mp08>
Message-ID: <AANLkTimmfYsGSei0-Chhy_Er82s2ExoajgL3SuitxfyR@mail.gmail.com>

Hi Anil,

On Wed, Jan 26, 2011 at 11:23 AM, Anil Rijhsinghani <anil at charter.net> wrote:
> Hi Donald,
>
>> I think that Sz, the campus wide minimum MTU that an RBridge has
>> calculated, should be a read-only per-RBridge MIB object and that it
>> should be possible for a change in Sz to cause a notification.
>
> I?ll add Sz as a read-only object to the TRILL group, next to MinMtuDesired which
> is a read-write object.
>
> I would suggest we not make a changing value of this a notification, as it could
> lead to the trap sink being flooded simultaneously with a large number of
> notifications. This is an object that an NMS will want to monitor or poll when
> necessary.

On further thought, I agree. It should very rarely change but when it
does it will likely change for many RBridges at once.

> Regards,
> Anil

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

> From: Donald Eastlake <d3e3e3 at gmail.com>
> Date: December 27, 2010 10:26:12 PM EST
> To: "Developing a hybrid router/bridge." <rbridge at postel.org>
> Subject: Re: [rbridge] Request for review of draft-ietf-trill-rbridge-mib-01.txt
>
> Hi,
>
> It would be helpful if people would review the MIB document. Here is a
> comment of mine:
>
> I think that Sz, the campus wide minimum MTU that an RBridge has
> calculated, should be a read-only per-RBridge MIB object and that it
> should be possible for a change in Sz to cause a notification.
>
> Thanks,
> Donald
>
>


From carlsonj at workingcode.com  Wed Jan 26 11:47:10 2011
From: carlsonj at workingcode.com (James Carlson)
Date: Wed, 26 Jan 2011 14:47:10 -0500
Subject: [rbridge] [Pppext] working group last call for PPP TRILL
 protocol control protocol [was Re: I-D
 Action:draft-ietf-pppext-trill-protocol-02.txt]
In-Reply-To: <4D4065F2.3080305@gmail.com>
References: <20110106154501.15655.20204.idtracker@localhost>	<4D334595.3030507@workingcode.com>	<4D3DADF9.4040009@gmail.com>	<4D3DB16B.5080803@workingcode.com>	<4D3DC516.1000105@gmail.com>	<4D3DCD97.7040005@gmail.com>	<4D3DE413.80908@workingcode.com>	<4D3E00B9.7050509@gmail.com>	<4D3E247D.9090201@workingcode.com>	<AANLkTi=+K-Kzsc+kahrmBoj1oC0WBzj7DYquS5ySCpP6@mail.gmail.com>	<4D3F13B3.9070706@workingcode.com>	<AANLkTikJjMcc1es7qyabddcXBFS93sRwcRO7XvPQzbe2@mail.gmail.com>	<4D3F1EAD.5040901@workingcode.com>
	<4D4065F2.3080305@gmail.com>
Message-ID: <4D407A3E.2000708@workingcode.com>

William Allen Simpson wrote:
> On 1/25/11 2:04 PM, James Carlson wrote:
>> I find I'm walking a narrow line.  I want to provide a little guidance
>> so that it's clear what's expected here, but I also want to avoid either
>> just copying hunks of the TRILL and IS-IS documentation or (worse)
>> carving out special exceptions.  I probably can't please everyone.
>>
> Probably not.  But it's fundamentally wrong to specify a configuration
> requirement for two protocols that are both premised on auto-configuration!

The other possible solution to avoid manual configuration (as I think I
mentioned) is to outlaw the use of TRILL systems that have only PPP
links and that also have no built-in (implementation-dependent) means of
acquiring a System ID automatically.

That's obviously possible, but besides being draconian in nature (how is
it my business how you plan to work with network administrators?), it
seems to strike a bit too close to the fundamentals of IS-IS.

In other words, I think I can point out the potential issue that exists
over in IS-IS to readers who might not be aware that (as part of an
overall system design, not as part of PPP TRILL itself) they could be
stepping in an area that lacks good solutions, but I don't think I
should say anything here that's at the level of requirement.  It's not
my place to repeat IS-IS requirements.  I can only do so badly and
out-of-sync with the original.  ;-}

Informative works for me on this issue, but normative doesn't.

> I'm sorry that I was off-line yesterday.  We've had responses about the
> requirements, and that clarifies things immensely.  But I'm busy
> cleaning up
> yesterday's mess today.  I promise some text tomorrow....  TIA!

Delay is not a problem.  I set a standard two-week timer to make sure
that folks would follow up.  But if there's still discussion going on at
that point, I'll continue with it as long as necessary to close it out.
 (Or until I remember that I have other things to do, I suppose ...)

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

From d3e3e3 at gmail.com  Wed Jan 26 12:08:52 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Wed, 26 Jan 2011 15:08:52 -0500
Subject: [rbridge] [Pppext] working group last call for PPP TRILL
 protocol control protocol [was Re: I-D
 Action:draft-ietf-pppext-trill-protocol-02.txt]
In-Reply-To: <4D4065F2.3080305@gmail.com>
References: <20110106154501.15655.20204.idtracker@localhost>
	<4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com>
	<4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com>
	<4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com>
	<4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com>
	<AANLkTi=+K-Kzsc+kahrmBoj1oC0WBzj7DYquS5ySCpP6@mail.gmail.com>
	<4D3F13B3.9070706@workingcode.com>
	<AANLkTikJjMcc1es7qyabddcXBFS93sRwcRO7XvPQzbe2@mail.gmail.com>
	<4D3F1EAD.5040901@workingcode.com> <4D4065F2.3080305@gmail.com>
Message-ID: <AANLkTimi5vsYbGb0QXhyg_jdE2aCPKkUL9Y_Qj=g0Jpo@mail.gmail.com>

Hi,

On Wed, Jan 26, 2011 at 1:20 PM, William Allen Simpson
<william.allen.simpson at gmail.com> wrote:
> On 1/25/11 2:04 PM, James Carlson wrote:
>>
>> I certainly agree with the sentiment (I don't like duplicating
>> documentation at all, particularly for this issue), but the existing
>> notation about MAC addresses (and the lack of them on PPP) was added at
>> the behest of other reviewers who found that it was confusing to match
>> up the PPP TRILL draft with the primary TRILL documentation without some
>> indication that there are differences here.
>>
> I agree with the other reviewers. ?Pretty hard to understand TRILL over
> PPP without mentioning System IDs and the lack of MAC addresses.

I don't understand why you say that. Seem to me that TRILL over PPP
just involves the formats, code points, and PPP procedures. Anyway, it
isn't clear to me that anyone will build a practical RBridge that
doesn't have a MAC address Ethernet interface even if it is just a
virtual internal interface for a virtual internal end station. If that
doesn't exist, you can't really address the RBridge for management or
maintenance.

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


From vishwas.ietf at gmail.com  Wed Jan 26 12:38:22 2011
From: vishwas.ietf at gmail.com (Vishwas Manral)
Date: Wed, 26 Jan 2011 12:38:22 -0800
Subject: [rbridge] draft-ietf-trill-rbridge-mib
In-Reply-To: <20110126115928.NLY9L.11297578.root@mp08>
References: <20110126115928.NLY9L.11297578.root@mp08>
Message-ID: <AANLkTi=JgvnR+TUo=wSANnObVtD0QGYPmrMU=5zBSMJm@mail.gmail.com>

Hi Anil,

> IETF convention is to leverage pre-existing MIBs for pre-defined protocols.
> Otherwise, we would end up with bloated MIBs and duplicated work.
> In this MIB we have re-used management work done for IS-IS as well as Bridges,
> and added new objects defined by the TRILL protocol.
No the MIB's will not be bloated.

By having control protocols for 2 different layers use the same MIB,
you are forcing to have the entire functionality in one address space,
or having to have an unnecessary middle layer which will have to probe
two different protocol modules.

Note using the same protocol machine does not mean we reuse the same
MIB. A similar example is OSPFv2 and OSPFv3. They share protocol
mechansims and not all OSPFv2 mechanisms are duplicated in OSPFv3,
however the MIB's have to be different.

>> 2. There is no information for MultiTopology.
>
> We do not yet have multi-topology in TRILL.
May be you want to see the Layer-2 IS-IS and TRILL IS-IS draft.

>> 3. Another thing that needs to be kept is the MTU table. Which has MTU
>> information received from all the devices in the network. I know we
>> have MTU objects at a link and neighbor basis.
>
> What would be the management benefit of adding such a (potentially
> huge) table? It seems to me that it would suffice for a manager to know
> the configurable Desired MTU per Rbridge, its neighbors, and the agreed MTU for
> the campus. For information regarding other Rbridges, it can visit those Rbridges.

Note a MIB is a logical way of manipulating data. You do not need to
have special tables for them. The data I am talking about is already
present in IS-IS. The idea here is to let management access to it.

We can discuss the other smaller points later.

Thanks,
Vishwas

>> 4. We probably need tohave Multicast Address listner ?table too.
>
> The group rbridgeSnooping contains a minimal level of multicast listener and snooping information necessary to support TRILL. Adding all objects necessary for
> IPv4 and IPv6 snooping is a non-goal and belongs in an independent Snooping/Listener MIB, as this is not functionality defined by TRILL. If there
> are additional objects you believe are necessary specifically to support TRILL,
> please list.

>> 5. We will need a table for the the information in the system for
>> distribution trees, and information advertized by each system, or
>> atleast a way to change the values to be configured for a system.
>
> There is a group and table for distribution trees, rbridgeDtree and rbridgeDtreeTable. If you believe there are useful configurable objects
> missing, could you please list them?
>
> Regards,
> Anil
>
> -----Original Message-----
> From: Vishwas Manral [mailto:vishwas.ietf at gmail.com]
> Sent: Monday, January 17, 2011 1:17 PM
> To: rbridge at postel.org
> Cc: Rijhsinghani, Anil; kate.zebrose at alum.mit.edu
> Subject: draft-ietf-trill-rbridge-mib
>
> Hi Anil/ Kate,
>
> I briefly looked at the TRILL MIB and had the following top level comments:
>
> 1. I think we should have a seperate tree for the Rbridge. I notice some of the tables are the same as IS-IS. It will be very confusing to code a MBI which is half IS-IS and half TRILL IS-IS.
> 2. There is no information for MultiTopology.
> 3. Another thing that needs to be kept is the MTU table. Which has MTU information received from all the devices in the network. I know we have MTU objects at a link and neighbor basis.
> 4. We probably need tohave Multicast Address listner ?table too.
> 5. We will need a table for the the information in the system for distribution trees, and information advertized by each system, or atleast a way to change the values to be configured for a system.
>
> Thanks,
> Vishwas
>
>


From carlsonj at workingcode.com  Wed Jan 26 13:38:36 2011
From: carlsonj at workingcode.com (James Carlson)
Date: Wed, 26 Jan 2011 16:38:36 -0500
Subject: [rbridge] [Pppext] working group last call for PPP TRILL
 protocol control protocol [was Re: I-D
 Action:draft-ietf-pppext-trill-protocol-02.txt]
In-Reply-To: <AANLkTimi5vsYbGb0QXhyg_jdE2aCPKkUL9Y_Qj=g0Jpo@mail.gmail.com>
References: <20110106154501.15655.20204.idtracker@localhost>	<4D334595.3030507@workingcode.com>
	<4D3DADF9.4040009@gmail.com>	<4D3DB16B.5080803@workingcode.com>
	<4D3DC516.1000105@gmail.com>	<4D3DCD97.7040005@gmail.com>
	<4D3DE413.80908@workingcode.com>	<4D3E00B9.7050509@gmail.com>
	<4D3E247D.9090201@workingcode.com>	<AANLkTi=+K-Kzsc+kahrmBoj1oC0WBzj7DYquS5ySCpP6@mail.gmail.com>	<4D3F13B3.9070706@workingcode.com>	<AANLkTikJjMcc1es7qyabddcXBFS93sRwcRO7XvPQzbe2@mail.gmail.com>	<4D3F1EAD.5040901@workingcode.com>
	<4D4065F2.3080305@gmail.com>
	<AANLkTimi5vsYbGb0QXhyg_jdE2aCPKkUL9Y_Qj=g0Jpo@mail.gmail.com>
Message-ID: <4D40945C.1070906@workingcode.com>

Donald Eastlake wrote:
> I don't understand why you say that. Seem to me that TRILL over PPP
> just involves the formats, code points, and PPP procedures. Anyway, it
> isn't clear to me that anyone will build a practical RBridge that
> doesn't have a MAC address Ethernet interface even if it is just a
> virtual internal interface for a virtual internal end station. If that
> doesn't exist, you can't really address the RBridge for management or
> maintenance.

Sure, you could.  It would just have to be addressed via IP (e.g., via
SNMP, ssh, or even TELNET) rather than by something locked into Ethernet.

One could imagine a large TRILL bridge designed for telecom applications
exclusively on the interior of the cloud, where the only possible links
are point-to-point; no Ethernet need apply.

Whether anyone ever builds that beast -- and, if so, whether it lacks
any built-in mechanism for automatic System ID assignment -- is a
different question.

What we're really discussing is whether failing to cover this case with
some sort of automatic resolution is a hole in the specification (as I
think Mr. Simpson is contending), or whether it's just an unlikely
corner that implementors should be warned away from (as I believe).

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

From d3e3e3 at gmail.com  Thu Jan 27 06:33:34 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 27 Jan 2011 09:33:34 -0500
Subject: [rbridge] [Pppext] working group last call for PPP TRILL
 protocol control protocol [was Re: I-D
 Action:draft-ietf-pppext-trill-protocol-02.txt]
In-Reply-To: <4D40945C.1070906@workingcode.com>
References: <20110106154501.15655.20204.idtracker@localhost>
	<4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com>
	<4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com>
	<4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com>
	<4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com>
	<AANLkTi=+K-Kzsc+kahrmBoj1oC0WBzj7DYquS5ySCpP6@mail.gmail.com>
	<4D3F13B3.9070706@workingcode.com>
	<AANLkTikJjMcc1es7qyabddcXBFS93sRwcRO7XvPQzbe2@mail.gmail.com>
	<4D3F1EAD.5040901@workingcode.com> <4D4065F2.3080305@gmail.com>
	<AANLkTimi5vsYbGb0QXhyg_jdE2aCPKkUL9Y_Qj=g0Jpo@mail.gmail.com>
	<4D40945C.1070906@workingcode.com>
Message-ID: <AANLkTi=RTh8YWh4Ck8P97Qv7YugbtoVOncko=mhA5ahN@mail.gmail.com>

Hi James,

On Wed, Jan 26, 2011 at 4:38 PM, James Carlson <carlsonj at workingcode.com> wrote:
> Donald Eastlake wrote:
>> I don't understand why you say that. Seem to me that TRILL over PPP
>> just involves the formats, code points, and PPP procedures. Anyway, it
>> isn't clear to me that anyone will build a practical RBridge that
>> doesn't have a MAC address Ethernet interface even if it is just a
>> virtual internal interface for a virtual internal end station. If that
>> doesn't exist, you can't really address the RBridge for management or
>> maintenance.
>
> Sure, you could. ?It would just have to be addressed via IP (e.g., via
> SNMP, ssh, or even TELNET) rather than by something locked into Ethernet.

Really? RBridge don't route on IP addresses. They route based on
nickname and, on ingress, they convert to nickname from MAC/VLAN. How
are you going to get an RBridge to route on an IP address?

Thanks,
Donald

> One could imagine a large TRILL bridge designed for telecom applications
> exclusively on the interior of the cloud, where the only possible links
> are point-to-point; no Ethernet need apply.
>
> Whether anyone ever builds that beast -- and, if so, whether it lacks
> any built-in mechanism for automatic System ID assignment -- is a
> different question.
>
> What we're really discussing is whether failing to cover this case with
> some sort of automatic resolution is a hole in the specification (as I
> think Mr. Simpson is contending), or whether it's just an unlikely
> corner that implementors should be warned away from (as I believe).
>
> --
> James Carlson ? ? ? ? 42.703N 71.076W ? ? ? ? <carlsonj at workingcode.com>


From carlsonj at workingcode.com  Thu Jan 27 06:50:31 2011
From: carlsonj at workingcode.com (James Carlson)
Date: Thu, 27 Jan 2011 09:50:31 -0500
Subject: [rbridge] [Pppext] working group last call for PPP TRILL
 protocol control protocol [was Re: I-D
 Action:draft-ietf-pppext-trill-protocol-02.txt]
In-Reply-To: <AANLkTi=RTh8YWh4Ck8P97Qv7YugbtoVOncko=mhA5ahN@mail.gmail.com>
References: <20110106154501.15655.20204.idtracker@localhost>
	<4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com>
	<4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com>
	<4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com>
	<4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com>
	<AANLkTi=+K-Kzsc+kahrmBoj1oC0WBzj7DYquS5ySCpP6@mail.gmail.com>
	<4D3F13B3.9070706@workingcode.com>
	<AANLkTikJjMcc1es7qyabddcXBFS93sRwcRO7XvPQzbe2@mail.gmail.com>
	<4D3F1EAD.5040901@workingcode.com> <4D4065F2.3080305@gmail.com>
	<AANLkTimi5vsYbGb0QXhyg_jdE2aCPKkUL9Y_Qj=g0Jpo@mail.gmail.com>
	<4D40945C.1070906@workingcode.com>
	<AANLkTi=RTh8YWh4Ck8P97Qv7YugbtoVOncko=mhA5ahN@mail.gmail.com>
Message-ID: <4D418637.10007@workingcode.com>

On 01/27/11 09:33, Donald Eastlake wrote:
> Hi James,
> 
> On Wed, Jan 26, 2011 at 4:38 PM, James Carlson <carlsonj at workingcode.com> wrote:
>> Donald Eastlake wrote:
>>> I don't understand why you say that. Seem to me that TRILL over PPP
>>> just involves the formats, code points, and PPP procedures. Anyway, it
>>> isn't clear to me that anyone will build a practical RBridge that
>>> doesn't have a MAC address Ethernet interface even if it is just a
>>> virtual internal interface for a virtual internal end station. If that
>>> doesn't exist, you can't really address the RBridge for management or
>>> maintenance.
>>
>> Sure, you could.  It would just have to be addressed via IP (e.g., via
>> SNMP, ssh, or even TELNET) rather than by something locked into Ethernet.
> 
> Really? RBridge don't route on IP addresses. They route based on
> nickname and, on ingress, they convert to nickname from MAC/VLAN. How
> are you going to get an RBridge to route on an IP address?

You provide it with access to a management network, perhaps also through
PPP.  This could be done via separate interfaces or, if desired, by
running IPCP in parallel with TRILL on the existing PPP links.

Who said all management must be in-band with the data network?

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

From d3e3e3 at gmail.com  Thu Jan 27 11:24:07 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 27 Jan 2011 14:24:07 -0500
Subject: [rbridge] trill-adj Section 4 comments
Message-ID: <AANLkTikWNuQJQU9fFuGVNVPy1AicMSp37+rqffsMW9Xm@mail.gmail.com>

Response to some comments by Les Ginsberg:

> Section 4
> ----------

> There needs to be a description of the DRB election process -
> equivalent to what is in [IS-IS] Section 8.4.5. For example, the set
> of DRB candidates includes all RBs to which the local system has an
> adjacency in Detect, 2-way, or Report State ...correct?

I'm certainly willing to re-word it, but it seems to me that the
following existing paragraph says what is needed:

   Determination of events 3 and 4 occurs by comparing priorities (with
   neighbor MAC address (SNPA) as a tie breaker and Port ID as a
   secondary tie breaker) across all entries in the port's adjacency
   table including those in the Detect and 2-Way states as well as those
   in the Report state.

I could make this into a separate sub-section, add references to it,
and perhaps re-word as follows:

   Events 3 and 4 consistute losing and winning the DRB election at
   the port, respectivly.

   The candidates are the local RBridge and all RBridges with which
   there is an adjacency on the port in a state other than Down. The
   winner is the RBridge with highest priority to be DRB, as
   determined from the 7-bit priority field in the Hellos received and
   the local port's priority to be DRB field, with MAC address (SNPA)
   as a tie breaker and Port ID as a secondary tie breaker. These
   fields are compared as unsigned inteered with the larger magnitude
   being considered higher priority.

> You also need to specify in what DRB election states a DRB reports
> neighbors in pseudo-node LSPs. It would seem that if neighbors are
> advertised in pre-DRB state that we could attract traffic which we
> are not yet able to forward.

An RBridge in DRB or Pre-DRB state (unless it is asserting bypass
pseudonode) report all adjacencies in the Report state in pseudo-node
LSPs. Perhaps "Pre-DRB" should be renamed "Inh-DRB" for inhibited
DRB. An RBridge in either Pre-DRB or DRB states is the Designated
RBridge for the link. It is just that in "Pre-DRB" it can't ingress or
egress native frames. In any state other than Down, it can handle
TRILL Data frames just fine.

Note the existing description of "Pre-DRB":

         The port has become DRB but is in a pre-forwarding state with
         regard to native frames and is inhibited from ingressing or
         egressing them.

> Section 4.2
> -----------

> When a DRB change causes a change in D-VLAN, the draft says:

      o  The non-Designated VLAN Hello Holding timer is set to the
         maximum of its time to expiration and the time to expiration of
         the Designated VLAN Hello Holding timer.

> The "Designated VLAN Hello Holding timer" referred to is the OLD
> Designated VLAN Hello Holding timer, correct? If so adding that
> clarification would help.

I don't like "old". How about if I change "the Designated VLAN Hello
Holding timer" to "the pre-existing Designated VLAN Hello Holding
timer".

> Also, if we are NOT DRB and the new D-VLAN is NOT in the set of
> announcing VLANs then the non-DRBs have to include the new D-VLAN in
> the set of VLANS for which they send hellos, correct? This should be
> specified.

The specification of what VLANs you send Hellos on is seems quite
clear in the TRILL base protocol standard Section 4.4.3. An RBridge
port not configured as point-to-point always sends TRILL Hellos on the
Designated VLAN, except where that VLAN is actually disabled at the
port, and the Announcing VLANs set has no effect on that.

> It is alpso apparent that DRB changes are very disruptive - even more
> so than at Layer 3. In Layer 3 on a DIS change optimal behavior is
> to do a "make before break" to minimize disruption. However, that is
> not possible here as all adjacencies will go into "Detect" state
> following a DRB change. Should it be recommended then to avoid DRB
> changes whenever possible (e.g.  by setting LAN priority)?

I don't see how a DRB change is any more disruptive to TRILL Data than
a Layer 3 DIS change is to Layer 3 data forwarding. As above, perhaps
it needs to be clarified that the purpose of the Pre-DRB state is just
to temporarily inhibit ingress and egress of native frames.

A change in Designated VLAN is somewhat disruptive. Could add at the
end of Section 4.2 "Because of the temporary disruption caused by a
change in the Designated VLAN on a link that has multiple RBridges
attached, it is RECOMMENDED that all RBridges attached to a link have
the same desired Designated VLAN for their ports on that link."

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


From carlsonj at workingcode.com  Thu Jan 27 12:34:36 2011
From: carlsonj at workingcode.com (James Carlson)
Date: Thu, 27 Jan 2011 15:34:36 -0500
Subject: [rbridge] [Pppext] proposed TRILL IS-IS System ID text
In-Reply-To: <4D41ABED.5070308@gmail.com>
References: <4D415111.4010009@gmail.com> <4D41ABED.5070308@gmail.com>
Message-ID: <4D41D6DC.2040406@workingcode.com>

On 01/27/11 12:31, William Allen Simpson wrote:
> On 1/27/11 6:03 AM, William Allen Simpson wrote:
>> 3. An implementation that has only PPP links might have no previously
>> configured Media Access Control (MAC) that can function as an
>> IS-IS System ID. In this case, the System ID is formed by adding
>> a randomly generated 14-bit leading number (in place of an OUI) to
>> the link's unique LCP Magic Number. The Magic Number MUST be
>> unique for all links and all known link peers. This pseudo-MAC
>> MUST have both the "locally-assigned" and "broadcast/multicast"
>> (group) bits set to 1; that is, the least significant two bits of
>> the most significant octet are both set to 1.
>>
> Looking at this again, and remembering how fanatic the new RFC Editors (TM)
> are about abbreviations, probably needs to expand OUI, too:
> 
>                .... In this case, the System ID is formed by appending
>   the link's unique 32-bit LCP Magic Number after a randomly generated
>   14-bit number in place of an Organizationally Unique Identifier (OUI).
> 
> [Also makes the number of bits explicit: N/2**23 birthday attack;
> considerably less than having 2 identical MACs from the same vendor, or
> being killed by lightning.  Could put that in the Security Considerations?]

[Sorry for the duplicate on the PPP list; Thunderbird hurt me with the
CC-list again.]

Yes, I see where you're going with this.  I don't think it's a
"Security" issue.  It's actually a correctness issue -- if there are
duplicates, then IS-IS falls down.

That aside, what you're suggesting is still a bit uncomfortable to me.
You're essentially saying that this draft can forge up a new way of
creating IS-IS System IDs on its own just to be helpful.  I'm not so
sure that it can or should.  I think it's out of scope.

While I certainly agree that, if implemented properly (and if existing
system architectures allow implementation), what you're describing
should work nicely, I don't want to run afoul of the IS-IS folks by
tromping so squarely on their turf.

In particular, IS-IS simply mandates that System IDs must be unique
across the domain in which they're used.  Not that they're "extremely
unlikely to be duplicated" -- but that they're _never_ duplicated.  The
existing protocol clearly puts the responsibility for that in the hands
of system implementers, not the link layer designers.

Now, you're certainly within your rights to claim that MAC addresses are
a feeble mechanism, and you may well be right that there are systems
that duplicate them (though I can't say *I* have ever seen this), but
the ISO people behind IS-IS appear (to me at least) to think
differently.  It's not a matter of statistics, or of field experience,
but of specification.

Instead, I think the issue you're talking about is really a fundamental
issue in IS-IS itself, and is not one that is created by or altered by
or in any way related to PPP or TRILL.  IS-IS already supports
point-to-point links without PPP or TRILL.  And if you were to build an
IS-IS router with only point-to-point links and without some source of a
System ID, you would run into exactly this problem.  But as the links on
this hypothetical router are just plain old point-to-point links, you
would not have the benefit of the mechanism you're proposing to have to
this draft.

And the same problem occurs if you run an IS-IS router with only PPP
links using OSINLCP.  So, it's not specifically a TRILL issue.

It's the same problem, and it's not something that I think we ought to
be addressing.  We can certainly call it out, though.

I think that if this is to be addressed -- it's probably the least
important issue I can imagine in TRILL, and likely needs no fixing at
all, as I strongly suspect that real systems won't have the problem --
it should be addressed in the TRILL IS-IS document, or perhaps in the
base IS-IS documents themselves.  It's IS-IS itself that demands a
single unique System ID (PPP frankly doesn't care), and it's TRILL that
demands zero configuration.

At a minimum, I want to hear from IS-IS and TRILL experts before I go
ahead with proposing any new random-number-based System ID mechanism.
If they sign on, then I'll go ahead with it.

But my off-the-cuff guess is that they'll have objections, and more
objections probably aren't helpful in getting to consensus.

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

From d3e3e3 at gmail.com  Thu Jan 27 18:52:11 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 27 Jan 2011 21:52:11 -0500
Subject: [rbridge] trill-adj Section 3.3 comments
Message-ID: <AANLkTini2Q1rwYFjETFkqLs1710n1BzfRmndGqMsT=UQ@mail.gmail.com>

Response to some comments by Les Ginsberg:

> Section 3.3
> -------------

> Text says that for hellos received on a VLAN Other than the D-VLAN

> "any TRILL Neighbor TLV in such a Hello is ignored..."

> I assume this means that it is an implementation choice as to
> whether to include the neighbor TLV in such hellos? A clear
> statement of this would be helpful.

To avoid the posibility of temporary confusion if there is a change in
the Designated VLAN, the TRILL Neighbor TLV sent on a VLAN should
reflect the neighbors seen on that VLAN. Since an implementation
conformant to this draft is only assured of having per VLAN neighbor
information for the Deisgnated VLAN, I think something like the
following should be added in Section 7.2:

"The TRILL Neighbor TLV sent on a VLAN MUST show the neighbor
information, as sensed by the transmitting RBridge, on that
VLAN. Since implementations conformant to this document maintain such
information on a per VLAN basis only for the Designated VLAN, such
implementations only send the TRILL Neighbor TLV in TRILL Hellos on
the Deisgnated VLAN."

You could imagine an implementation that kept more state and had
neighbor information for multiple VLANs but it doesn't seem worth going
into that.

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


From carlsonj at workingcode.com  Fri Jan 28 11:10:12 2011
From: carlsonj at workingcode.com (James Carlson)
Date: Fri, 28 Jan 2011 14:10:12 -0500
Subject: [rbridge] [Pppext] proposed TRILL IS-IS System ID text
In-Reply-To: <4D430123.8010101@gmail.com>
References: <4D415111.4010009@gmail.com> <4D41ABED.5070308@gmail.com>
	<4D41D6DC.2040406@workingcode.com> <4D430123.8010101@gmail.com>
Message-ID: <4D431494.6090906@workingcode.com>

William Allen Simpson wrote:
> On 1/27/11 3:34 PM, James Carlson wrote:
>> That aside, what you're suggesting is still a bit uncomfortable to me.
>> You're essentially saying that this draft can forge up a new way of
>> creating IS-IS System IDs on its own just to be helpful.  I'm not so
>> sure that it can or should.  I think it's out of scope.
>>
> It's a point-to-point link specific issue.  In the IETF, it belongs in a
> PPP document.  In the past, we had enough on our plates to ensure our
> *own* protocols worked.  We didn't fuss about some other organization.

The leap I think your argument might be making is that PPP is the only
possible point-to-point protocol over which IS-IS would run, and that
this is thus the right place to write this specification.

I strongly disagree.

The existing OSINLCP in PPP allows you to run IS-IS over PPP *TODAY*,
and the problem you're citing isn't solved.  Moreover, it isn't solved
even if I put this special text into the draft under consideration,
because this draft addresses only TRILL usage of PPP.  And it's not
fixed when IS-IS is run over _other_ point-to-point media.

In other words, it's an IS-IS issue, not a PPP issue.

>> While I certainly agree that, if implemented properly (and if existing
>> system architectures allow implementation), what you're describing
>> should work nicely, I don't want to run afoul of the IS-IS folks by
>> tromping so squarely on their turf.
>>
> It's a sad comment on the IETF that it's become so fussy about "turf"!
> 
> Remember the fights with ANSI T1 about defining a link layer over "their"
> bits?  Or defining PPP over SONET/SDH (with two competing bodies)?
> 
> Let's just get the job done.

If you don't like the word, then I can certainly use another.

IS-IS operation is simply outside the purview of the IETF PPP Extensions
working group.  It's got nothing to do with us.  We don't define IS-IS
any more than we define SONET/SDH.  We just live with it.

I believe the best we can reasonably do here is say, gee, IS-IS people,
it looks like you have a possibly ugly hole in your specification.  If
you care about it, please fix it, because we can't fix it for you.  As a
bonus, we can offer you these bits from our neck of the woods, if
they'll help.

>> In particular, IS-IS simply mandates that System IDs must be unique
>> across the domain in which they're used.  Not that they're "extremely
>> unlikely to be duplicated" -- but that they're _never_ duplicated.  The
>> existing protocol clearly puts the responsibility for that in the hands
>> of system implementers, not the link layer designers.
>>
> I cannot "clearly" find that "responsibility" anywhere in RFC-1142.  Please
> cite references.

How about 7.1.1, where it's defined?

  ID, a 6 octet system identification. Correct operation of the routeing
  protocol requires that this field be unique within an area for End
  Systems and Level 1 Intermediate systems, and unique within the
  routeing domain for Level 2 Intermediate systems.

It's unique; end of story.  It doesn't say "you must demand this from
your link layer interfaces."  It doesn't say "you can optionally create
one out of thin air by generating random numbers if you want."  It
doesn't even say whether administrative intervention is needed or desired.

That puts it in the hands of the implementer.

> It is the responsibility of protocol designers to completely specify the
> protocol, including error recovery!  Only after changing to a prescriptive
> specification, PPP achieved wide-spread interoperability in '91.

I agree, and I believe I've done that here.

I think the only way I can comply with your demand is to put text like
this into the draft:

	If the TRILL implementation using PPP links also uses IS-IS,
	then the IS-IS implementation MUST have a network-wide unique
	System ID.  Commonly, this is derived from a link layer MAC
	address (which is not available on PPP) or from a system-wide
	MAC address (which may be available on certain systems).
	Acceptable means of determining a System ID for this use are
	covered in the IS-IS and TRILL IS-IS documentation.

In other words, call out the issue, and effectively outlaw (via "MUST")
the degenerate mode of operation where a system has only PPP links and
_also_ has no means of getting a system-wide identifier.

> Apparently, you've never operated an ISP, nor read the NANOG list.

I refuse to respond to ad hominem attacks.  Stick to the topic, please.

>> It's the same problem, and it's not something that I think we ought to
>> be addressing.  We can certainly call it out, though.
>>
> If you insist on waiting for ISO to issue a specification, then arguably
> you MUST wait to publish this document, as that would be a Normative
> Reference....

I don't understand what you're saying.  How is it Normative?

What part of this specification changes in any way depending on what the
IS-IS folks decide to do about this decades-old hole in their document?

Do any of the PPP bits on the wire change as a result?  Are there any
configuration option changes?  Or new packet formats?  Or state machine
variations?

I see no dependency here at all, so no way the reference you're
requiring could be Normative.  It does not define the protocol.

>> At a minimum, I want to hear from IS-IS and TRILL experts before I go
>> ahead with proposing any new random-number-based System ID mechanism.
>> If they sign on, then I'll go ahead with it.
>>
>> But my off-the-cuff guess is that they'll have objections, and more
>> objections probably aren't helpful in getting to consensus.
>>
> We don't have consensus now.

In observing the TRILL discussions with the IS-IS group, it seemed clear
to me that making changes to IS-IS (beyond adding a few new data types)
was not a substantial area of interest.

I still don't see why any sort of System ID fabrication mechanism needs
to be part of this specification.  It's not a requirement that any given
TRILL implementation uses IS-IS.  And even if a given TRILL/IS-IS system
doesn't have PPP links, the implementor already has substantial issues
to resolve in getting the System ID right.  (E.g., dealing with hot-swap
hardware is a very interesting problem.)

I do not believe it's PPP's fault if a given IS-IS implementation can't
get the System ID it needs to run.  It wouldn't be Ethernet's fault,
either, if the implementor doesn't know how to deal with hot-swap, and
uses a "bad" MAC address as a result.

I think the fix you're proposing just polishes the tip of an iceberg.

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

From ginsberg at cisco.com  Mon Jan 31 01:44:44 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Mon, 31 Jan 2011 01:44:44 -0800
Subject: [rbridge] trill-adj Section 4 comments
In-Reply-To: <AANLkTikWNuQJQU9fFuGVNVPy1AicMSp37+rqffsMW9Xm@mail.gmail.com>
References: <AANLkTikWNuQJQU9fFuGVNVPy1AicMSp37+rqffsMW9Xm@mail.gmail.com>
Message-ID: <AE36820147909644AD2A7CA014B1FB520D323EC9@xmb-sjc-222.amer.cisco.com>

Donald -

Thanx for the response.
Please include the IS-IS WG on all emails associated with trill-adj review comments.

Inline.

> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3 at gmail.com]
> Sent: Thursday, January 27, 2011 11:24 AM
> To: Les Ginsberg (ginsberg); rbridge at postel.org
> Subject: trill-adj Section 4 comments
> 
> Response to some comments by Les Ginsberg:
> 
> > Section 4
> > ----------
> 
> > There needs to be a description of the DRB election process -
> > equivalent to what is in [IS-IS] Section 8.4.5. For example, the set
> > of DRB candidates includes all RBs to which the local system has an
> > adjacency in Detect, 2-way, or Report State ...correct?
> 
> I'm certainly willing to re-word it, but it seems to me that the
> following existing paragraph says what is needed:
> 
>    Determination of events 3 and 4 occurs by comparing priorities (with
>    neighbor MAC address (SNPA) as a tie breaker and Port ID as a
>    secondary tie breaker) across all entries in the port's adjacency
>    table including those in the Detect and 2-Way states as well as
> those
>    in the Report state.

Given that you have introduced new adjacency states, it would help if you had more explicit language. See ISO 10589 Section 8.4.5d.

> 
> I could make this into a separate sub-section, add references to it,
> and perhaps re-word as follows:
> 
>    Events 3 and 4 consistute losing and winning the DRB election at
>    the port, respectivly.
> 
>    The candidates are the local RBridge and all RBridges with which
>    there is an adjacency on the port in a state other than Down. The
>    winner is the RBridge with highest priority to be DRB, as
>    determined from the 7-bit priority field in the Hellos received and
>    the local port's priority to be DRB field, with MAC address (SNPA)
>    as a tie breaker and Port ID as a secondary tie breaker. These
>    fields are compared as unsigned inteered with the larger magnitude
>    being considered higher priority.

Yes - something like this would be good.

> 
> > You also need to specify in what DRB election states a DRB reports
> > neighbors in pseudo-node LSPs. It would seem that if neighbors are
> > advertised in pre-DRB state that we could attract traffic which we
> > are not yet able to forward.
> 
> An RBridge in DRB or Pre-DRB state (unless it is asserting bypass
> pseudonode) report all adjacencies in the Report state in pseudo-node
> LSPs. Perhaps "Pre-DRB" should be renamed "Inh-DRB" for inhibited
> DRB. An RBridge in either Pre-DRB or DRB states is the Designated
> RBridge for the link. It is just that in "Pre-DRB" it can't ingress or
> egress native frames. In any state other than Down, it can handle
> TRILL Data frames just fine.
> 
> Note the existing description of "Pre-DRB":
> 
>          The port has become DRB but is in a pre-forwarding state with
>          regard to native frames and is inhibited from ingressing or
>          egressing them.

This is exactly my point. If there is two way connectivity and the reachable VLAN/MAC addresses have been advertised by the respective appointed forwarders, then traffic will be attracted even though it cannot be delivered. Is this desirable? If the pseudo-node LSP did NOT advertise neighbors in pseudo-node LSPs then such packets could be dropped closer to the source until the pre-forwarding state had expired.

> 
> > Section 4.2
> > -----------
> 
> > When a DRB change causes a change in D-VLAN, the draft says:
> 
>       o  The non-Designated VLAN Hello Holding timer is set to the
>          maximum of its time to expiration and the time to expiration
> of
>          the Designated VLAN Hello Holding timer.
> 
> > The "Designated VLAN Hello Holding timer" referred to is the OLD
> > Designated VLAN Hello Holding timer, correct? If so adding that
> > clarification would help.
> 
> I don't like "old". How about if I change "the Designated VLAN Hello
> Holding timer" to "the pre-existing Designated VLAN Hello Holding
> timer".

What I want clarified is that the Designated VLAN Holding timer mentioned here is associated with the D-VLAN specified by the "old DRB" - not the new DRB. How about:

"the Designated VLAN Hello Holding Timer associated with the D-VLAN specified by the previous DRB"

??


> 
> > Also, if we are NOT DRB and the new D-VLAN is NOT in the set of
> > announcing VLANs then the non-DRBs have to include the new D-VLAN in
> > the set of VLANS for which they send hellos, correct? This should be
> > specified.
> 
> The specification of what VLANs you send Hellos on is seems quite
> clear in the TRILL base protocol standard Section 4.4.3. An RBridge
> port not configured as point-to-point always sends TRILL Hellos on the
> Designated VLAN, except where that VLAN is actually disabled at the
> port, and the Announcing VLANs set has no effect on that.

Yes - but as this specification is attempting to fully describe the operation of the adjacency machinery it seems worth including explicit language here - rather than requiring people to go to another document. It may be commonplace for all Rbridges to be configured with the same D-VLAN, but for cases where that is NOT the case (which is of course necessary for a D-VLAN change to be possible at all) it is a requirement for all Rbridges on the LAN to send hellos on whatever D-VLAN is specified by the DRB - which means Rbridges have to take this action on a DRB change which involves a D-VLAN change. Discussing this seems very relevant to the scope of this document.



> 
> > It is alpso apparent that DRB changes are very disruptive - even more
> > so than at Layer 3. In Layer 3 on a DIS change optimal behavior is
> > to do a "make before break" to minimize disruption. However, that is
> > not possible here as all adjacencies will go into "Detect" state
> > following a DRB change. Should it be recommended then to avoid DRB
> > changes whenever possible (e.g.  by setting LAN priority)?
> 
> I don't see how a DRB change is any more disruptive to TRILL Data than
> a Layer 3 DIS change is to Layer 3 data forwarding.

A DRB change will cause a pre-forwarding timer to be started - which means that native frames will not be deliverable for some period of time. This delay/black-holing period does not occur at Layer 3 - which is why I say a DRB change in TRILL is more disruptive as you have deliberately designed in a black-holing period as a safety mechanism. This argues that we should avoid unnecessary DRB changes.

   Les


> As above, perhaps
> it needs to be clarified that the purpose of the Pre-DRB state is just
> to temporarily inhibit ingress and egress of native frames.
> 
> A change in Designated VLAN is somewhat disruptive. Could add at the
> end of Section 4.2 "Because of the temporary disruption caused by a
> change in the Designated VLAN on a link that has multiple RBridges
> attached, it is RECOMMENDED that all RBridges attached to a link have
> the same desired Designated VLAN for their ports on that link."
> 
> Thanks,
> Donald
> =============================
> ?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
> ?155 Beaver Street
> ?Milford, MA 01757 USA
> ?d3e3e3 at gmail.com


From ginsberg at cisco.com  Mon Jan 31 02:19:51 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Mon, 31 Jan 2011 02:19:51 -0800
Subject: [rbridge] trill-adj Section 3.3 comments
In-Reply-To: <AANLkTini2Q1rwYFjETFkqLs1710n1BzfRmndGqMsT=UQ@mail.gmail.com>
References: <AANLkTini2Q1rwYFjETFkqLs1710n1BzfRmndGqMsT=UQ@mail.gmail.com>
Message-ID: <AE36820147909644AD2A7CA014B1FB520D323ECB@xmb-sjc-222.amer.cisco.com>

Donald -

Thanx for the response.
Please include the IS-IS WG on all emails associated with trill-adj review comments.

Inline.


> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3 at gmail.com]
> Sent: Thursday, January 27, 2011 6:52 PM
> To: Les Ginsberg (ginsberg); rbridge at postel.org
> Subject: trill-adj Section 3.3 comments
> 
> Response to some comments by Les Ginsberg:
> 
> > Section 3.3
> > -------------
> 
> > Text says that for hellos received on a VLAN Other than the D-VLAN
> 
> > "any TRILL Neighbor TLV in such a Hello is ignored..."
> 
> > I assume this means that it is an implementation choice as to
> > whether to include the neighbor TLV in such hellos? A clear
> > statement of this would be helpful.
> 
> To avoid the posibility of temporary confusion if there is a change in
> the Designated VLAN, the TRILL Neighbor TLV sent on a VLAN should
> reflect the neighbors seen on that VLAN. Since an implementation
> conformant to this draft is only assured of having per VLAN neighbor
> information for the Deisgnated VLAN, I think something like the
> following should be added in Section 7.2:
> 
> "The TRILL Neighbor TLV sent on a VLAN MUST show the neighbor
> information, as sensed by the transmitting RBridge, on that
> VLAN. Since implementations conformant to this document maintain such
> information on a per VLAN basis only for the Designated VLAN, such
> implementations only send the TRILL Neighbor TLV in TRILL Hellos on
> the Deisgnated VLAN."
> 
> You could imagine an implementation that kept more state and had
> neighbor information for multiple VLANs but it doesn't seem worth going
> into that.

Yes - I agree.

Section 3.2 states:

      o  Two Hello holding timers, each consisting of an 16-bit unsigned
         integer number of seconds: a Designated VLAN holding timer and
         a non-Designated VLAN holding timer.

This text indicates that adjacencies are NOT per VLAN - but that a timer is kept indicating the reception of hellos on a VLAN other than the D-VLAN. Which raises the question as to whether this timer simply tracks reception of a hello on all VLANs other than the D-VLAN (which is what I thought) or is meant to be a separate timer for each VLAN other than the D-VLAN.

Your response indicates that if an implementation were to send neighbor information in a hello sent on a VLAN other than the D-VLAN that it MUST reflect only those neighbors seen on that VLAN - which makes sense to me - but would require that the implementation have a VLAN specific timer. 

I think your suggested text helps a lot and is definitely needed.

   Les

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