Subject: Re: Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05

From: Donald Eastlake <[email-masked]>
Date: Tue, 1 Sep 2015 10:35:57 -0400

Hi,

Adding a little on two points:

On Sun, Aug 30, 2015 at 11:54 PM, Mingui Zhang <[email-masked]> wrote:
> Hi Russ,
>
> Thanks for the comments. Please see the in-lines below.
>
>> -----Original Message-----
>> From: Russ Housley [mailto:[email-masked]]
>> Sent: Friday, August 28, 2015 5:59 AM
>> ...
>>
>> Document: draft-ietf-trill-pseudonode-nickname-05
>> Reviewer: Russ Housley
>> Review Date: 2015-08-24
>> IETF LC End Date: 2015-09-01
>> IESG Telechat date: unknown
>>
>> Summary: Almost Ready
>>
>> Major Concerns:
>>
>> ...
> ...
>
>> (2)  Also, in Section 5.2, Step 1, I think the intended sort order depends on all
>> of the LAALP IDi values being represented with the same number of bits.
>> Since Section 9.1 provides a variable length field to carry a LAALP ID value, I
>> assume that they are not always the same length.  Is a step needed to
>> encode the LAALP ID to a consistent length?
>
> [MZ] The sort is done in the per-LAALP base. It's not necessary to make the LAALP ID to a constant length. Besides, the 'mod' function always returns a value in [0, k-1] whatever the length of LAALP ID is.

We could add "considering System ID and LAALP ID as byte strings".

>> ...
>
>...
>
>> Minor Concerns:
>>
>> (1)  ...
>...
>
>> (2)  I found the last sentence of Section 2 confusing.  I am suggesting a
>> rewording to see if I figured it out.  If I did not figure it out properly, then the
>> sentence really does need to be reworked.
>>
>>    Under the assumption that the default learning is enabled at
>>    edge RBridges, MAC flip-flopping can be solved by using a
>>    Virtual RBridge together with its pseudo-nickname.  This
>>    document specifies a way to do so.
>
> [MZ] Yes, this is clear. Will be incorporated.

Suggest: "Assuming that the default data-plane learning is enabled at
edge RBridges, MAC flip-flopping can be solved by using a Virtual
RBridge together with its psuedo-nickname. This document specifies a
way to do so."

>> ...
> ...
>> ...

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

> Thanks,
> Mingui

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 1 Sep 2015 02:15:58 +0000

Hi Sandy,

> I just replied to Russ's message before I read your response.
> 
> The draft language is just as Russ said.

[MZ] That's OK :)

> 
>    It is important that the VLAN membership of all the RBridge ports in
>    an LAALP MUST be the same.  Any inconsistencies in VLAN membership
>    may result in packet loss or non-shortest paths.
> 
> Following this, there is a paragraph fully describing an inconsistent
> configuration.

[MZ] Yes, that paragraph further explains the possible consequences of inconsistency. 

> 
> If it is not possible for inconsistencies to occur, then why are you mentioning
> them?  Why give an explicit example of an inconsistent VLAN configuration?

[MZ] This is to explain why consistency becomes a requirement for LAALP implementations that are connected to TRILL edge. Implementations that cannot fulfill this requirement should not be used to connect to TRILL edge. IOW, it is not qualified as an LAALP as defined in TRILL. You can also refer to the second 'c)' of Section 2.1 [RFC7379]. 

> 
> You say "if the consistence cannot be maintained, it is not qualified as a LAALP".
> But the example shows a configuration case where inconsistency happens.

[MZ] As explained above.

> Does that mean it is not an LAALP?  

[MZ] No, it's not an LAALP as TRILL defined and required. 

> Does the spec for LAALP ensure
> consistency (and if so, why mention inconsistencies and provide examples)?

[MZ] There are several proprietary link aggregation techniques in the industry. It's possible that some of them does not meet this requirement. So the requirement is a criteria for choosing LAALP implementations. I think this is easy for operators. 
It's possible that operators want to do manual configuration. In that case, the consistency requirement still holds. 

> Does anything in TRILL detect the absence of consistency?

[MZ] I think the detection of inconsistency is out the scope of TRILL. However, it's natural that an edge RBridge device implements both TRILL and LAALP. This device can detect the consistence by using LAALP.

Thanks,
Mingui

> -Sandy

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Sep 2015 12:17:42 -0400

> We could add "considering System ID and LAALP ID as byte strings".

I am not sure that is enough unless all of the System IDs are the same length.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Sep 2015 12:19:27 -0400

I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair.  Please treat these comments just like
any other last call comments.  For more information, please see the
FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-trill-pseudonode-nickname-06
Reviewer: Russ Housley
Review Date: 2015-09-11
IETF LC End Date: 2015-09-01
IESG Telechat date: 2015-09-17

Summary: Almost Ready

Thanks for resolving my comments on the -05 version of this document.

Remaining Concern:

Building on the comment from my previous review on Section 5.2, Step 1:

Your response said, "The sort is done in the per-LAALP base. It's not
necessary to make the LAALP ID to a constant length. Besides, the 'mod'
function always returns a value in [0, k-1] whatever the length of
LAALP ID is."  The role of the 'mod' function was clear to me.

In Section 5.2, Step 1, the updated text says, "System ID and LAALP ID
are considered as byte strings", but the Step 2 text refers to "the
numerically sorted list".  If all of the System IDs are the same
length, then these are obviously the same.  Is that always the case?

---

From: Mingui Zhang <[email-masked]>
Date: Mon, 14 Sep 2015 03:24:17 +0000

Hi Russ,

Let me use an example.
Suppose there are four (k=4) RBridges: RB1, RB2, RB3 and RB4. Their SystemIDs are 001, 010, 011 and 100. Suppose the LAALP ID is 1. Then the four concatenations are 0011, 0101, 0111 and 1001 while the four 'mod' values are 3, 2, 3, 1. So, these are not always the same, even for the same LAALP ID. 

For the above example, the sorted list would be (RB4, RB2, RB1, RB3). Here, RB1 and RB3 have been sorted using their unsigned-integer-SystemID as a tie-breaker. Have I cleared the doubt?

Thanks,
Mingui

> Sent: Saturday, September 12, 2015 12:19 AM
> To: [email-masked]
> Cc: IETF Gen-ART; IETF
> Subject: Gen-ART Review of draft-ietf-trill-pseudonode-nickname-06
> 
> I am the assigned Gen-ART reviewer for this draft.  The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.  For more information, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Your response said, "The sort is done in the per-LAALP base. It's not necessary
> to make the LAALP ID to a constant length. Besides, the 'mod'
> function always returns a value in [0, k-1] whatever the length of LAALP ID is."
> The role of the 'mod' function was clear to me.
> 
> In Section 5.2, Step 1, the updated text says, "System ID and LAALP ID are
> considered as byte strings", but the Step 2 text refers to "the numerically
> sorted list".  If all of the System IDs are the same length, then these are
> obviously the same.  Is that always the case?

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 16 Sep 2015 03:05:01 -0400

See below:

> I am not sure that is enough unless all of the System IDs are the same length.

I believe that currently all LAALP IDs are 8-byte System Identifiers
as specified in Clause 6.3.2 of IEEE Std 802.1AX-2014 used for MC-LAGs
or DRNIs; however, there could be other kinds in the future. Perhaps
the draft should say that the LAALP ID needs to be unique across the
TRILL campus, that it is a System Identifier as above if it is
8-bytes, and that the meaning for other length is reserved. But that
doesn't really answer the sort order or mod arithmetic questions.

How about just saying that they are treated as unsigned integers with
the bytes in network order?

Thanks,
Donald

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Sep 2015 06:22:26 -0700

Thanks for the in-depth review, Russ! Very much appreciated.

I believe we still has to resolve what to do about the sort order.

(Maybe this helps: I’m not actually sure why in a k-element set you order them based <something> mod k because that would seem to produce likely duplicates. Since your backup option in the case of duplicates is proper numeric sort, why just not do that and only that? E.g. "RBridges are sorted in byte string ascending order by their LAALP IDs, or if they are equal, by their System IDs considered as unsigned integers.” But it could also be that it is too early and I have not yet had enough Diet Coke…)

Also, I am not sure I understand this in Section 5.2:

   Assuming there are … k member RBridges in an RBv; ... each RBridge is
   referred to as RBj where 0 <= j < k-1

Wouldn’t that mean that for 2 bridges you have RB0 only, because j=1 does not satisfy 0 <= j < k-1 because 0 <= 1 < 1 is untrue. But again, it is too early here and maybe I’m missing something.

Jari

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 18 Sep 2015 00:54:34 -0400

Hi Jari,

> (Maybe this helps: I’m not actually sure why in a k-element set you order them based <something> mod k because that would seem to produce likely duplicates. Since your backup option in the case of…

I believe the idea is to quasi-randomize the order. The DF election is
per VLAN and a goal is to spread the multicast traffic across the
RBridges in the active-active edge group.

> Wouldn’t that mean that for 2 bridges you have RB0 only, because j=1 does not satisfy 0 <= j < k-1 because 0 <= 1 < 1 is untrue. But again, it is too early here and maybe I’m missing something.

It is interesting that no one else noticed this. I agree it should
either be "... j <= k=1" or "... j < k".

Thanks,
Donald

---

From: Jari Arkko <[email-masked]>
Date: Fri, 18 Sep 2015 06:49:15 -0700

Donald,

> RBridges in the active-active edge group.

It is a fine goal to randomise the order.

My only observation of the current setup is that if you randomise a
k-element group through "mod k” operation, you will likely have
some number of collisions in the result. I don’t know enough
about math to calculate the percentage. But for the sake of
argument, if k=2 it seems that the likelihood of collision is 50%.

And for every collision, your order becomes no longer random
but simply numerical order of the identifiers. In our degenerate
k=2 example it seems that in 50% of the cases you have a random
order and 50% of the cases you have numerical order. I’m sure
there would be other ways to randomise the order with less
collisions, if avoiding numerical order is important.

Jari

---

From: Steve Crocker <[email-masked]>
Date: Sat, 19 Sep 2015 12:17:52 -0400

Jari,

I think you’re referring to the “birthday problem,” i.e. in a room of 23 randomly selected people, there’s a 50% probability that two people will have the same birthday (month and day, not year).

For populations of other sizes, the probability is related to the square root.  For example, if you create three letter acronyms at random, the probability of collision reaches 50% somewhere just above 150 TLAs.

This math comes into play in the design of hash algorithms.  If you want to keep the probability of finding two messages with the same hash below, say, 1/2^128, then you need a 256 bit hash.

Steve

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 20 Sep 2015 16:38:53 -0400

> collisions, if avoiding numerical order is important.

Well, the way to randomize the order with quite low probability of
collisions is to sort by the hash of  (System IDj | LAALP IDi), for
example SHA-1(System IDj | LAALP IDi). Ties could still be broken by
System ID which is guaranteed to be unique but ties would be quite
rare. This seems like a minor localized change.

Thanks,
Donald

---

From: Russ Housley <[email-masked]>
Date: Fri, 25 Sep 2015 10:30:25 -0400

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-mpls-self-ping-04
Reviewer: Russ Housley
Review Date: 2014-09-25
IETF LC End Date: 2014-10-02
IESG Telechat date: unknown

Summary:  Ready.

Major Concerns:  None.

Minor Concerns:  None.

Other Comments:

At the end of Section 1, the document says: "Each protocol listens on
its own UDP port and executes its own unique procedures."  What does
"unique" mean here?  What changes if "unique" is dropped from this
sentence?

Would it be more obvious to the reader the purpose of Section 6 if it
were turned into an appendix?

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 29 Sep 2015 14:38:55 +0000

Russ,

Agree on both points. I have:

- removed the word "unique"
- moved Section 6 to an appendix

Thanks for the review.

                                   Ron

> Sent: Friday, September 25, 2015 10:30 AM
> To: [email-masked]
> Cc: IETF Gen-ART <[email-masked]>; IETF <[email-masked]>
> Subject: Gen-ART Review of draft-ietf-mpls-self-ping-04
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-
> ART, please see the FAQ at
> Please resolve these comments along with any other Last Call comments you
> may receive.
> 
> At the end of Section 1, the document says: "Each protocol listens on its own
> UDP port and executes its own unique procedures."  What does "unique"
> mean here?  What changes if "unique" is dropped from this sentence?
> 
> Would it be more obvious to the reader the purpose of Section 6 if it were
> turned into an appendix?