Subject: [rbridge] WG last call on draft-ietf-trill-adj-01.txt

From: Erik Nordmark <[email-masked]>
Date: Mon, 03 Jan 2011 10:53:31 -0800

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

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

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 03 Jan 2011 11:43:54 -0800

> 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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 13 Jan 2011 17:36:54 -0800

(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

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 13 Jan 2011 20:16:57 -0800

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 14 Jan 2011 09:02:09 -0800

Vishwas -

Thanx for the reply.
Inline.

> -----Original Message-----
> From: Vishwas Manral [mailto:[email-masked]]
> Sent: Thursday, January 13, 2011 8:17 PM
> To: Les Ginsberg (ginsberg)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [rbridge] WG last call on draft-ietf-trill-adj-01.txt
> 
> Hi Les,
> 

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

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

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

> Section 4

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

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.

> multicast is when a new device first joins a link, which already has

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.

> to find a description of how to incorporate MTU test results into the

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

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 14 Jan 2011 10:17:14 -0800

Hi Les,

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

> 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 h…

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.

>> connectivity / configuration.

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.

> 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.

> 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.

> 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

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 14 Jan 2011 12:43:46 -0800

Hi Les,

VM> One way to do it will be to send it Hello Multiplier + 1 times
>> in
>> > 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.
>>
> 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.

> OK - so we agree this is an issue which needs to be addressed it seems.
VM> Again same as above.

>> > Can you comment on the second point regarding in what "DRB election
>> state" (NOT neighbor state) neighbors are advertised?
> 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.

> 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
>   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

>> >> > comments identified by Section # - except in a couple of cases
>> where
>> >> the
>> >> > information and to provide robust loop prevention in the
>> forwarding
>> >> of
>> >> > scalability issues in the presence of a large number of neighbors
>> on
>> >> a
>> >> > there is consensus that these are issues which should be
>> addressed,
>> >> then

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 14 Jan 2011 12:32:45 -0800

Vishwas -

> Sent: Friday, January 14, 2011 10:17 AM

That is good. :-)

> > 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.
> 

> > 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.
> 

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

To requote the draft:

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 14 Jan 2011 13:51:32 -0800

Vishwas -

> Sent: Friday, January 14, 2011 12:44 PM
> > 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.

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.

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

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>
<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. 

> > 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.

This does not answer my question. :-(

   Les

> 
> >> VM> I agree with you. It is left to an implementation to decide how
> to
> >> do it.
> >
> > 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?
> >> >> > The file draft-ietf-trill-adj-01_editorial.txt is portions of
> the
> >> >> draft
> >> >> > 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
> >> >> > confined myself to pointing out where I believe such issues
> arise.
> >> If
> >> >> > for the effort and diligence they obviously applied to the
> writing
> >> of
> >> >> > this draft.
> >> >> >
> >> >> >   Les
> >> >> >
> >> >> >

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 14 Jan 2011 14:25:24 -0800

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

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 14 Jan 2011 14:25:24 -0800

Hi Les,

You have good comments.

Thanks,
Vishwas

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 14 Jan 2011 14:32:35 -0800

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

> Sent: Friday, January 14, 2011 2:25 PM
> >> > OK. I do think some guidance would be good as the use of MTU PDUs
> is
> >> an entirely new functionality.
> >> >> >> > Finally, I would like to thank the authors of draft-ietf-
> trill-
> >> >> adj-01

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 15 Jan 2011 16:29:19 -0500

Hi Les,

On Thu, Jan 13, 2011 at 8:32 PM, Les Ginsberg (ginsberg)
<[email-masked]> wrote:
> ...

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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 15 Jan 2011 14:45:01 -0800

Donald -

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

> Section 8.4, the TRILL protocol uses different functions for a LAN

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...

> <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)

> originatingLSPBufferSize and is L1 or L2 depending on whether the LSP

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. :-)

>    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: Donald Eastlake <[email-masked]>
Date: Tue, 18 Jan 2011 10:31:19 -0500

Hi Erik,

> 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

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 18 Jan 2011 17:11:15 -0500

Hi Les,

> 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."

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

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

> 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.

> the phrase is the best thing to do.

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

Thanks,
Donald

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 18 Jan 2011 16:49:06 -0800

Donald -

> From: Donald Eastlake [mailto:[email-masked]]
> Sent: Tuesday, January 18, 2011 2:11 PM
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] [rbridge] WG last call on draft-ietf-trill-adj-
> 01.txt
> 
> Hi Les,
> 

ACK

> informational reference to RFC 3719.

ACK

> the link state database" was meant to refer to that field by its

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.

> >>    pseudonode for the link and sends LSPs on behalf of the
> pseudonode
> >> as
> >>    pseudonode for the link and sends LSPs on behalf of the
> pseudonode
> >> as

ACK.

   Les

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 20 Jan 2011 20:35:51 -0500

Hi Les,

...
> 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 referri…

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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 20 Jan 2011 22:23:41 -0800

Donald -

> Sent: Thursday, January 20, 2011 5:36 PM
> >> > The TLV name is originatingLSPBufferSize(or LSPBufferSize in
> IANA).
> >> Per
> >> > Whether L1 or L2 is in the TLV is determined by the type of PDU it
> is
> >> in
> > 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.
> 

Works for me.
Thanx.

   Les