Re: [trill] Benjamin Kaduk's No Objection on draft-ietf-trill-multilevel-single-nickname-15: (with COMMENT)

[Donald Eastlake]

Hi Benjamin,

I have posted a -17 version which I believe resolves your comments.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com
On Sun, Oct 10, 2021 at 12:36 PM Donald Eastlake  wrote:
>
> Hi,
>
> Thanks for the detailed review. Sorry for the slow response. See below.
>
> On Wed, Sep 22, 2021 at 7:33 PM Benjamin Kaduk via Datatracker 
>  wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-trill-multilevel-single-nickname-15: No Objection
> >
> > --
> > COMMENT:
> > --
> >
> > ...
> >
> > Section 3.1
> >
> >-  RB3, when forwarding into area {3,30}, replaces the egress
> >   nickname in the TRILL header with RB44's nickname (44). (The
> >
> > I strongly suggest spending a few words to reiterate how RB3 knows to
> > replace 3 with 44 in this scenario.  (I.e., looking up based on D from
> > the packet contents.)
>
> OK. (It looks it up based on the destination MAC and data label (VLAN or 
> FGL).)
>
> > Section 3.2
> >
> >All border RBridges of an area MUST agree on a pseudorandom
> >algorithm as the tie-breaker to locally determine the DBRB. The same
> >pseudorandom algorithm will be reused in Section 4 for the purpose of
> >load balancing. It's also possible to implement a certain election
> >protocol to elect the DBRB. However, such kind of implementations are
> >out the scope of this document. By default, the border RBridge with
> >the smallest nickname, considered as an unsigned integer, is
> >elected
> >DBRB.
> >
> > (Editorial) It seems a little weird to me to write this as "MUST agree
> > on a pseudorandom algorithm ... oh but you could use leader election
> > instead as well, we just don't say how to" -- the "MUST" requirement
> > doesn't seem to match up with the actual requirement for correct
> > operation.  I tried to shuffle things around to make the actual "MUST"
> > requirement match up, as follows, though I'm not fully confident that my
> > proposal is actually correct...
> >
> > NEW:
> >
> > All border RBridges of an area MUST agree on a procedure for
> > determining the DBRB for the area.  This document assumes that the
> > border RBridge with smallest nickname (considered as an unsigned
> > integer) is elected DBRB, and that there is an agreed pseudo-random
> > algorithm as a tie-breaker (and reuses that algorithm in Section 4
> > for the purpose of load balancing), but that does not preclude the
> > use of leader-election or similar procedures.
>
> How about:
>For proper operation, all border RBridges of an area MUST agree on
>the DBRB for the area.  This document assumes that the
>border RBridge with smallest nickname (considered as an unsigned
>integer) is elected DBRB, and that there is an agreed pseudo-random
>algorithm as a tie-breaker (and reuses that algorithm in Section 4
>for the purpose of load balancing), but that does not preclude the
>use of leader-election or other procedures.
>
> >-  RB3, when forwarding into area {3,30}, replaces the egress
> >   nickname in the TRILL header with the root RBridge nickname of a
> >   distribution tree of L1 area {3,30} say 30. (Here, the ingress
> >   nickname MAY be replaced with a different area nickname selected
> >   from {2,20}, the set of border RBridges to the ingress area, as
> >   specified in Section 4.) Now suppose that RB27 has learned the
> >   location of D (attached to nickname 3), but RB3 does not know
> >   where D is. In that case, RB3 must turn the packet into a multi-
> >   destination packet and floods it on the distribution tree of L1
> >   area {3,30}.
> >
> > I think either there's a missing paragraph break here, or we need to
> > s/RB27/RB3/ -- RB27 is attached to S, but this part of the procedure is
> > discussing how RB3 is performing level transition to inject the packet
> > into area {3,30}.
>
> The wording can be improved. The two things it is talking about are (1) 
> multidestination frames, in which case they would always have been sent on an 
> L2 tree and are transitioned to an L1 tree, and (2) unicast frames that might 
> have been sent to the border by unicast inside the source L1 and sent by 
> unicast across L2 but have to b

Re: [trill] Benjamin Kaduk's No Objection on draft-ietf-trill-multilevel-single-nickname-15: (with COMMENT)

[Donald Eastlake]

Hi,

Thanks for the detailed review. Sorry for the slow response. See below.

On Wed, Sep 22, 2021 at 7:33 PM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-trill-multilevel-single-nickname-15: No Objection
>
> --
> COMMENT:
> --
>
> ...
>
> Section 3.1
>
>-  RB3, when forwarding into area {3,30}, replaces the egress
>   nickname in the TRILL header with RB44's nickname (44). (The
>
> I strongly suggest spending a few words to reiterate how RB3 knows to
> replace 3 with 44 in this scenario.  (I.e., looking up based on D from
> the packet contents.)

OK. (It looks it up based on the destination MAC and data label (VLAN or
FGL).)

> Section 3.2
>
>All border RBridges of an area MUST agree on a pseudorandom
>algorithm as the tie-breaker to locally determine the DBRB. The same
>pseudorandom algorithm will be reused in Section 4 for the purpose of
>load balancing. It's also possible to implement a certain election
>protocol to elect the DBRB. However, such kind of implementations are
>out the scope of this document. By default, the border RBridge with
>the smallest nickname, considered as an unsigned integer, is
>elected
>DBRB.
>
> (Editorial) It seems a little weird to me to write this as "MUST agree
> on a pseudorandom algorithm ... oh but you could use leader election
> instead as well, we just don't say how to" -- the "MUST" requirement
> doesn't seem to match up with the actual requirement for correct
> operation.  I tried to shuffle things around to make the actual "MUST"
> requirement match up, as follows, though I'm not fully confident that my
> proposal is actually correct...
>
> NEW:
>
> All border RBridges of an area MUST agree on a procedure for
> determining the DBRB for the area.  This document assumes that the
> border RBridge with smallest nickname (considered as an unsigned
> integer) is elected DBRB, and that there is an agreed pseudo-random
> algorithm as a tie-breaker (and reuses that algorithm in Section 4
> for the purpose of load balancing), but that does not preclude the
> use of leader-election or similar procedures.

How about:
   For proper operation, all border RBridges of an area MUST agree on
   the DBRB for the area.  This document assumes that the
   border RBridge with smallest nickname (considered as an unsigned
   integer) is elected DBRB, and that there is an agreed pseudo-random
   algorithm as a tie-breaker (and reuses that algorithm in Section 4
   for the purpose of load balancing), but that does not preclude the
   use of leader-election or other procedures.

>-  RB3, when forwarding into area {3,30}, replaces the egress
>   nickname in the TRILL header with the root RBridge nickname of a
>   distribution tree of L1 area {3,30} say 30. (Here, the ingress
>   nickname MAY be replaced with a different area nickname selected
>   from {2,20}, the set of border RBridges to the ingress area, as
>   specified in Section 4.) Now suppose that RB27 has learned the
>   location of D (attached to nickname 3), but RB3 does not know
>   where D is. In that case, RB3 must turn the packet into a multi-
>   destination packet and floods it on the distribution tree of L1
>   area {3,30}.
>
> I think either there's a missing paragraph break here, or we need to
> s/RB27/RB3/ -- RB27 is attached to S, but this part of the procedure is
> discussing how RB3 is performing level transition to inject the packet
> into area {3,30}.

The wording can be improved. The two things it is talking about are (1)
multidestination frames, in which case they would always have been sent on
an L2 tree and are transitioned to an L1 tree, and (2) unicast frames that
might have been sent to the border by unicast inside the source L1 and sent
by unicast across L2 but have to be transitioned to a tree inside the
destination L1 because the L2-to-L1 border RBridge has forgotten (or never
knew if it just came up or it fell out of cache or whatever) the
MAC of the destination end station. These should be more clearly
distinguished but I think it makes sense to leave it as one paragraph since
it is all talking about transitioning from L2 to an L1 distribution tree.

>-  RB30, will receive the packet flooded on the L1 tree by RB3. It is
>   important that RB30 does not transition this packet back to L2.
>   RB30 should also examine the ingress nickname of this packet. If
>   this nickname is found to be an L2 border RBridge nickname, RB30
>   must not transition the packet back to L2.
>
> The way this condition is written ("to be an L2 border RBridge
> nickname", with no restriction to the area in which it's received) seems
> to imply an assumption that any given border RBridge is in exactly 

[trill] Fwd: New Version Notification for draft-ietf-trill-multilevel-single-nickname-13.txt

[Donald Eastlake]

-- Forwarded message -
From: 
Date: Mon, Jul 27, 2020 at 8:04 AM
Subject: New Version Notification for
draft-ietf-trill-multilevel-single-nickname-13.txt
To: Mingui Zhang , Margaret Cullen
, Hongjun Zhai ,
Radia Perlman , Donald E. Eastlake



A new version of I-D, draft-ietf-trill-multilevel-single-nickname-13.txt
has been successfully submitted by Donald E. Eastlake and posted to the
IETF repository.

Name:   draft-ietf-trill-multilevel-single-nickname
Revision:   13
Title:  Transparent Interconnection of Lots of Links (TRILL)
Single Area Border RBridge Nickname for Multilevel
Document date:  2020-07-27
Group:  Individual Submission
Pages:  20
URL:
https://www.ietf.org/internet-drafts/draft-ietf-trill-multilevel-single-nickname-13.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-single-nickname/
Htmlized:
https://tools.ietf.org/html/draft-ietf-trill-multilevel-single-nickname-13
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-trill-multilevel-single-nickname
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-multilevel-single-nickname-13

Abstract:
   A major issue in multilevel TRILL is how to manage RBridge nicknames.
   In this document, area border RBridges use a single nickname in both
   Level 1 and Level 2. RBridges in Level 2 must obtain unique nicknames
   but RBridges in different Level 1 areas may have the same nicknames.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] posting revisions of a couple of TRILL drafts

[Donald Eastlake]

Hi,

I'm posting revisions of a couple of TRILL drafts to note my
affiliation with Futurewei Technologies.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Request for AD Sponsorship of draft-ietf-trill-multilevel-single-nickname

[Donald Eastlake]

Hi Martin,

draft-ietf-trill-multilevel-single-nickname has recently been revised to
version -08. I believe this draft is now ready for AD Review / IETF Last
Call. We request that you AD Sponsor this draft.

It probably doesn't matter but I notice that this draft is in the "In WG
Last Call" status in the Datatracker...

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] [Idr] I-D Action: draft-ietf-idr-ls-trill-04.txt

[Donald Eastlake]

This revision is intended to resolve John Scudder's comments.

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


On Sun, Apr 15, 2018 at 12:48 PM,   wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Inter-Domain Routing WG of the IETF.
>
> Title   : Distribution of TRILL Link-State using BGP
> Authors : Donald E. Eastlake
>   Weiguo Hao
>   Yizhou Li
>   Sujay Gupta
>   Muhammad Durrani
> Filename: draft-ietf-idr-ls-trill-04.txt
> Pages   : 15
> Date: 2018-04-15
>
> Abstract:
>This draft describes a TRILL link state and MAC address reachability
>information distribution mechanism using a BGP LS extension.
>External components such as an SDN Controller can use the information
>for topology visibility, troubleshooting, network automation, and the
>like. This document updates RFC 7752.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-idr-ls-trill/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-idr-ls-trill-04
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-ls-trill-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ls-trill-04
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Draft TRILL minute uploaded

[Donald Eastlake]

Draft minutes of the last TRILL WG meeting in London have been
uploaded to the meeting material page:
https://datatracker.ietf.org/doc/minutes-101-trill/

Comments/corrections welcome.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Mirja Kühlewind's Discuss on draft-ietf-trill-over-ip-16: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi Mirja,

On Mon, Apr 9, 2018 at 11:12 AM, Mirja Kuehlewind (IETF)
<i...@kuehlewind.net> wrote:
>
> Hi Donald,
>
> sorry for my late reply. Please see below.
>
> > Am 04.04.2018 um 20:10 schrieb Donald Eastlake <d3e...@gmail.com>:
> >
> > Hi Mirja,
> >
> > On Thu, Mar 29, 2018 at 10:58 AM, Mirja Kühlewind <i...@kuehlewind.net> 
> > wrote:
> >> Mirja Kühlewind has entered the following ballot position for
> >> draft-ietf-trill-over-ip-16: Discuss
> >>
> >> ...
> >>
> >> --
> >> DISCUSS:
> >> --
> >>
> >> Usage of encapsulation schemes
> >> 
> >> The document does not clearly explain and justify why different 
> >> encapsulations
> >> are needed. The document should more extensively discuss the different
> >> properties and trade-offs for each encapsulation and give clear 
> >> recommendations
> >> when you to use which encapsulation. E.g. the document does not clearly 
> >> specify
> >> when to use IPSec (besides saying „if security in needed“), however, the
> >> document needs to explain more clearly what is meant by this: given the
> >> over-the-Internet path is always not trusted, does that mean that IPSec 
> >> should
> >> always be used in that scenario? Why is IPSec specified instead of using 
> >> TLS or
> >> DTLS with the TCP or UDP encapsulations respectively?
> >
> > More information can be added about properties of different encapsulations.
> >
> > In the latest revision (-16), Appendix A was added (page 48) briefly
> > discussing the IP security decision: (1) Is the information presented
> > in Appendix A sufficient? (2) Would you like that material moved into
> > the body of the document.
>
> Sorry, I actually missed that appendix. So, yes, I think further guidance 
> needs to be provided in the body and not only explaining why IPSec was 
> selected (focusing on the technical point(s) and not so much on the wg 
> process behind it) but more importantly you need to give more detailed 
> guidance when it needs to/should be used.

OK.

> Also, what you mean by "Other security protocols can be used by agreeing 
> TRILL over IP transport ports“?

Perhaps the sentence you ask about was completely superfluous but I
don't understand what question there is on its meaning. If there is
agreement by the end points of the connection and, instead of the
mandatory to implement IPsec they decide to use something else like
DTLS or SSH, they can certainly do that.

> >> Why is both UDP and TCP
> >> encapsulation needed, given that UDP is the default that is mandatory to
> >> implement anyway? Why are the short-comings of UDP and when is it
> >> recommended/beneficial to switch to TCP?
> >
> > I would say that the primary problem with UDP is fragmentation.
>
> That is a good point but given that UDP is the mandatory, and only mandatory 
> to implement solution anyway, you need to address the fragmentation problem 
> anyway. In this case it is still not very clear when it is beneficial to 
> negotiate TCP instead.

We'll see what we can add but it seems unreasonable, in the absence of
field experience, to demand that this document should precisely
indicate when which option should be used.

> >> DSCP
> >> -
> >> 1) Section 4.3 should also talk about decapsulation as DCSP is often
> >> overwritten on the path and therefore the DCSP of the inner and other IP
> >> headers can differ on decapsulation. Please see RFC2983 for further 
> >> guidance.
> >> You probably should specify to discard the outer DSCP at tunnel egress in 
> >> your
> >> use case.
> >
> > OK.
> >
> >> 2) Further it is not clear to me if the use of CS7 in appropriate for this 
> >> use
> >> case as RFC 4594 says "   o  CS7 marked packets SHOULD NOT be sent across
> >> peering points.
> >>  Exchange of control information across peering points SHOULD be
> >>  done using CS6 DSCP and the Network Control service class."
> >
> > Although providing generally similar guidance, I note that RFC 8100 is
> > a more recent Informational RFC on this topic than RFC 4594.
>
> RFC8100 is only on guidance for interconnected networks. So I would say 
> RFC4594 is actually the more general reference. Anyway the recommendation is 
> the same.
> >
> > We can add some guidance that CS6 and CS7 shou

Re: [trill] [Idr] WGLC for draft-ietf-idr-ls-trill-03

[Donald Eastlake]

Hi John,

Thanks for these comments, See below.

On Wed, Mar 21, 2018 at 11:32 AM, John G. Scudder  wrote:
> Hi All,
>
> This WGLC collected exactly one expression of support other than from
> co-authors, from zhuangyan.zhu...@huawei.com. I'm afraid we don't have
> consensus to progress the document right now, or evidence that the document
> has received much in the way of review.
>
> I do note several problems that will need to be resolved:
>
> 1. There are six front-page authors. There should be five or fewer, see the
> final bullet of
> https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-related%20draft

OK.

> 2. The IANA section has
>
>IANA is requested to assign one Node Flag bit for "Layer 3 Gateway"
>from the BGP-LS registry of BGP-LS Attribute TLVs.
>
> however, the registry BGP-LS Node Descriptor, Link Descriptor, Prefix
> Descriptor, and Attribute TLVs actually has no provision for registering new
> flag bits. https://tools.ietf.org/html/rfc7752#section-3.3.1.1 simply lists
> them as "Reserved for future use". Possibly address this by requesting IANA
> to create the registry within the "Border Gateway Protocol - Link State
> (BGP-LS) Parameters" and allocate your bit from there. You would also have
> to make your draft update RFC 7752. I've cc'd Adrian and Hannes, the
> Designated Experts for that group of registries, in case they have further
> comment.

Creating a registry in this document seems like the appropriate course
of action.

> 3. Not precisely a problem, but are there implementations of the draft? As
> you know, if there aren't, by IDR WG convention we will stall until we do
> have some, even if we do complete a WGLC.

I am not aware of any right now.

> 4. I'd kind of prefer you remove tables 1 and 2. They aren't authoritative
> and table 1 is actually obsolete.

OK.

> 5. Section 3.3.1.1 has
>
>+--++---+
>| Bit  |  Description   | Reference |
>+--++---+
>| 'G'  | Layer 3 Gateway Bit| [RFC7176] |
>| Reserved | Reserved for future use|   |
>+--++---+
>
> I think the reference must be wrong. RFC 7176 ("Transparent Interconnection
> of Lots of Links (TRILL) Use of IS-IS") doesn't include the string "gateway"
> at all, so if the ref is correct, it's at best obscure.
>
> But in any case, per #2 above, probably this is not the right table in the
> right place.

I'll see what I can do to improve this.

> 6. I have read section 3.3.1.2 several times and don't understand it. Other
> than "what does it mean?" I wonder what the intent of table 6 is. It kind of
> resembles the table in section 5.2 of RFC 7176? I'm confused.

I think Section 3.3.1.2 is enumerating TRILL link state information
that can be transported in BGP-LS using the opaque node attribute TLV
as of some point in time (perhaps when the -00 draft was created).
However, additional possible TRILL link state information has been
specified since [RFC7176]. In any case, I think this subsection should
be recast in a more general way and the Table 6 should probably be
eliminated.

> 7. Is this a typo?
>
>o  Does any fixed length TLV correspond to the TLV Length field in
>   this document ?
>
> Do you mean "every"?

I believe it should be "every".

> 8. In this:
>
>  opaque TLV support the range of ISIS-TLV/SUB-TLV shown in Table
> 3,  and link TLVs support the range in Figure 8.
>
> there is no figure 8 in the document.

I think it is just trying to say that you check that items of link
state information are inside the right envelope; but, it is not very
clear and refers to Figure 8 when it probably means Table 7. I'll try
to improve it.

> 9. I don't know if the security section will fly, but then again I don't
> know if it won't. Once the doc is revised to address the above I'll ask the
> Sec Dir for a review.

OK.

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

> Thanks,
>
> --John
>
>
> On Oct 19, 2017, at 3:33 PM, John Scudder  wrote:
>
> Hi All,
>
> An IDR working group last call has been requested for
> draft-ietf-idr-ls-trill-03. Please reply to the list with your comments. As
> usual note we cannot advance the draft without participation from the group.
> Please get your comments in before November 3, 2017.
>
> Authors, please confirm that any relevant IPR has been disclosed.
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Didr-2Dls-2Dtrill-2D03=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=hLt5iDJpw7ukqICc0hoT7A=YQIHKfaMAUOrl3hLdgq6nw1PcXtmtpICF3XlGCVFreQ=6fwhGLRqq-HwpYC9ZJyaR60B_kl8F-1BV0Gd5B7XPl8=
>
> Thanks,
>
> --John
>
> 

Re: [trill] Publication has been requested for draft-ietf-trill-over-ip-14

[Donald Eastlake]

There is something funny here. The current version is -16, not -14.
Ahh, I see. It is a reply of this message:
https://www.ietf.org/mail-archive/web/trill/current/msg08203.html
It's even dated February 20th.

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


On Wed, Mar 21, 2018 at 6:47 PM, Jon Hudson  wrote:
>
> This may be the biggest accomplishment of them all =)
>
>
>> On Feb 20, 2018, at 6:12 AM, Susan Hares  wrote:
>>
>> Susan Hares has requested publication of draft-ietf-trill-over-ip-14 as 
>> Proposed Standard on behalf of the TRILL working group.
>>
>> Please verify the document's state at 
>> https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/
>>

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-over-ip-15: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi Eric,

On Sun, Mar 18, 2018 at 4:56 AM, Eric Rescorla  wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-trill-over-ip-15: Discuss
>
> ...
>
> --
> DISCUSS:
> --
>
> Hopefully this is easy to resolve. In the best case, you will be
> able to demonstrate that this is not a problem in practice and
> document that. If not, the actual fix is straightforward, though
> incompatible.
>
> S 7.1.1.
> I am concerned about the use of the IS-IS key in this way. First, on
> general principles, you should not use a single key both as input to a
> KDF and directly as a working key. Specifically, however, RFC 5310
> defines the use of HMAC authentication with IS-IS-key as the HMAC
> key, and HKDF-Expand is really just SHA-256. Thus, if an attacker
> was able to observe (or cause to be created) an IS-IS packet that
> happened to have the same contents as the HKDF Info value you
> provide would then know the IKE PSK.
>
> The correct practice here is to separately expand both the IS-IS
> key *and* the IKE PSK from the same original value. If you cannot
> do that, you should at least generate an Info value which is
> guaranteed to not be the input to any RFC 5310 MAC.

The source may not be easily accessible.

The first byte of the data to which the RFC 5310 MAC is applied is always
0x83, the Interdomain Routeing Discriminator. The first byte of the data
below is 0x54 ('T') so they cannot be the same.

 HKDF-Expand-SHA256 ( IS-IS-key,
 "TRILL IP" | P1-System-ID | P1-Port | P2-System-ID | P2-Port )


Could also add some text such as "Note that the value to which the HKDF
function is applied starts with 0x54 ('T') while the data to which RFC 5310
authentication is applied (an IS-IS PDU) starts with 0x83, the Interdomain
Routeing Discriminator, thus, although they are both SHA256 based, they are
never applied to the same value."

>When IS-IS security is in use, IKEv2 SHOULD use a pre-shared key that
>incorporates the IS-IS shared key in order to bind the TRILL data
>session to the IS-IS session.  The pre-shared key that will be used
>
> The technique you provide does not guarantee a binding between the
> sessions. It merely ensures (modulo the caveat above) that both sides
> know the IS-IS Key. It's easy to see this by noting that you could
> move IS-IS traffic from one IPsec association to another. If you
> actually want to bind these sessions, you must do something different.

I think the idea was just that, in conjunction with the text later in this
section, the IPsec key wouldn't be used for longer than the IS-IS key.

How about just deleting the words "in order to bind the TRILL data session
to the IS-IS session."?

> --
> COMMENT:
> --
>
> I see that native encapsulation is incompatible with NATs (S 8).
> That's probably worth stating upfront to minimize confusion.
>
> S 5.4.2.
>
>   f. No middleboxes are allowed in the TRILL over IP transport link
>  because middlebox support is beyond the scope of this document.
>
> How would you know if no middleboxes were in the link?

Well, if they map IP addresses, the "neighbor" values inside the Hellos
will not get mapped, will not match, and thus you will be unable to
establish adjacency and nothing will flow over the link except Hellos (no
data, LSPs, etc.). You need an application specific gateway for TRILL to
operate through a NAT. On the other hand, a sufficiently benign middlebox
(if there are such things) which, for example, only had a black list of
some IP protocols / ports / addresses, that had no effect on the TRILL data
or control traffic would be pretty invisible and TRILL should work fine
through it.

How about the following replacement text:

f. This document assumes there are no middleboxes in the path and thus does
not cover restrictions on such middleboxes. Middlebox support is beyond the
scope of this document.


> S 5.5.
> Can you use VXLAN with IPsec?

"VXLAN" is really Ethernet over VXLAN over UDP. I don't see a problem with
doing Ethernet over VXLAN over UDP over IPsec.

> S 5.6.
> What security mechanism do you expect to use for TCP? IPsec again?

Yes.

>the timing and implementation details may be such that P! and P2 each
>
> Nit: P1, right?

Yes, sorry about that pesky shift key...

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-2270> (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-address-flush-05: (with COMMENT)

[Donald Eastlake]

Version -06 posted as requested.

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

On Sun, Mar 18, 2018 at 7:16 AM, Alia Atlas <akat...@gmail.com> wrote:

> Donald,
>
> Could you please submit this ?
>
> Thanks,
> Alia
>
> On Wed, Mar 14, 2018 at 8:32 PM, Donald Eastlake <d3e...@gmail.com> wrote:
>
>> Hi Alvaro,
>>
>> Attached is a candidate -06 version of draft-ietf-trill-address-flush
>> (my internal version 39) intended to resolve your comments. Also
>> attached is a diff against the currently posted -05. Can you take a
>> looks and see if your comments are satisfied?
>>
>> Thanks,
>> Donald
>> ===
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>> <https://maps.google.com/?q=155+Beaver+Street,+Milford,+MA+01757+USA=gmail=g>
>>  d3e...@gmail.com
>>
>>
>> On Thu, Feb 8, 2018 at 11:39 AM, Donald Eastlake <d3e...@gmail.com>
>> wrote:
>> > Hi Alvaro,
>> >
>> > On Wed, Feb 7, 2018 at 12:28 PM, Alvaro Retana <aretana.i...@gmail.com>
>> wrote:
>> >> Alvaro Retana has entered the following ballot position for
>> >> draft-ietf-trill-address-flush-05: No Objection
>> >>
>> >> ...
>> >>
>> >> --
>> >> COMMENT:
>> >> --
>> >>
>> >> I have some non-blocking comments/questions:
>> >>
>> >> (1) Why are the 2 VLAN Block encodings needed?  More important, when
>> should
>> >> each be used?  Section 2.2 says that "All RBridges implementing the
>> Address
>> >> Flush RBridge Channel message MUST implement types 1 and 2, the VLAN
>> types...",
>> >> but I didn't see anything about the VLAN Block Only Case (2.1).  I'm
>> wondering
>> >> if there will be cases where the support won't match and the message
>> will then
>> >> be ineffective.
>> >
>> > I suppose some wording could be added but the idea is that the VLAN
>> > Block Only Case is part of the basic message and always has to be
>> > implemented, as opposed to the extensible list of TLV types. The
>> > message is structured so that you can't use both the VLAN Block Only
>> > Case and the extensible TLV structure to specify VLANs at the same
>> > time. The VLAN Block Only Case is expected to be common and
>> > corresponds more closely to deployed code.
>> >
>> >> (2) In the 2.2.* sections, the description of some of the TLVs says
>> (when the
>> >> Length is incorrect) that "...the Address Flush message MUST be
>> discarded if
>> >> the receiving RBridge implements Type x".  What if that type is not
>> supported
>> >> -- I would assume you still want to discard?  BTW, the Type 5
>> description
>> >> doesn't qualify dropping based on the type support.
>> >
>> > If the Type is not implemented, then how would you know that the
>> > length is not valid? How would you currently code a length validity
>> > check for types to be specified in the future as part of the
>> > extensibility of the message? But, since there is a length field, you
>> > can always skip over a TLV you don't understand. The qualification
>> > based on type support should be there for Type 5 also. (Of course, in
>> > the real world, I think inconsistent Address Flush message type
>> > support in a TRILL campus will be very rare.)
>> >
>> >> (2a) Other descriptions (type 1,2,6) just talk about ignoring (not
>> discarding).
>> >>  Is there an intended difference in the behavior?
>> >
>> > There is no intended difference between "ignoring" and "discarding" an
>> > Address Flush message. (Types 1, 2, and 6 are the mandatory to support
>> > types so there is no conditional on support.)
>> >
>> >> (3) Section 2 says that "Address Flush protocol messages are usually
>> sent as
>> >> multi-destination packets...Such messages SHOULD be sent at priority
>> 6".  It is
>> >> not clear to me whether unicast packets (mentioned later) should also
>> have the
>> >> same priority.
>> >
>> > Yes, probably throwing in "including unicast Address Flush messages"
>> > would clarify.
>> >
>> > Thanks,
>> > Donald
>> > ===
>> >  Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-2270> (cell)
>> >  155 Beaver Street, Milford, MA 01757 USA
>> <https://maps.google.com/?q=155+Beaver+Street,+Milford,+MA+01757+USA=gmail=g>
>> >  d3e...@gmail.com
>>
>> ___
>> trill mailing list
>> trill@ietf.org
>> https://www.ietf.org/mailman/listinfo/trill
>>
>>
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)

[Donald Eastlake]

Hi Alvaro,

A -07 version of draft-ietf-trill-multilevel-unique-nickname has been
posted with the intent of resolving your comment as per my response
below.

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


On Tue, Mar 13, 2018 at 11:50 AM, Donald Eastlake <d3e...@gmail.com> wrote:
> Hi Alvaro,
>
> On Tue, Mar 6, 2018 at 12:37 PM, Alvaro Retana <aretana.i...@gmail.com> wrote:
>> Alvaro Retana has entered the following ballot position for
>> draft-ietf-trill-multilevel-unique-nickname-06: No Objection
>>
>> ...
>>
>> --
>> COMMENT:
>> --
>>
>> (1) The nickname selection process for multilevel is not backwards compatible
>> because of the use of the NickBlockFlags APPsub-TLV.  That is ok since the
>> border RBridges can recognize "old" Rbridges (ones that don't support this
>> specification) in an area. A couple of related comments:
>>
>> (1.1) Section 4.4. (Capability Indication) says that "Non border RBridges in 
>> an
>> area SHOULD understand the NickBlockFlags APPsub-TLV."  That statement is
>> somewhat contradictory (maybe that's not the right word, but the only one 
>> that
>> comes to mind):
>>
>> - On one hand, non border RBridges could be just be "old" (ones that don't
>> support this specification).  We can't normatively specify something that by
>> definition nodes that don't support this specification won't know about.
>>
>> - On the other hand, if the non border Rbridge does support this 
>> specficiation,
>> then why wouldn't it understand the NickBlockFlags APPsub-TLV?  IOW, why 
>> isn't
>> the "SHOULD" a "MUST" instead?  When is it ok to not do it?
>>
>> All this is to say that I think that "SHOULD" should not be used normatively.
>> s/SHOULD/should
>
> Sounds reasonable to me.
>
>> (1.2) Given that rfc6325 specifies a single Level 1 network, it is reasonable
>> to expect that networks implementing these multilevel extensions will grow 
>> from
>> a single area to multiple.  It would be ideal to include Deployment
>> Considerations to discuss what a Migration Path would look like.
>>
>> (2) Maybe I missed it somewhere...  The Security Considerations section says
>> that "border RBridges need to fabricate the nickname 
>> announcements...Malicious
>> devices may also fake the NickBlockFlags APPsub-TLV to announce a range of
>> nicknames."  I'm sure that malicious devices don't only include ones that are
>> unauthenticated, but may include over or under claiming by existing border
>> RBridges or even non border RBridges originating the NickBlockFlags 
>> APPsub-TLV.
>>
>> (2.1) Is the origination of the NickBlockFlags APPsub-TLV restricted to 
>> border
>> RBridges?  If so, why isn't there a check to make sure that the 
>> NickBlockFlags
>> APPsub-TLV came from a border RBridge?
>
> Such a check would add some complexity and it is not clear there would
> be much gain as an RBridge that is forging NickBlockFlags APPsub-TLVs
> would presumably just falsely claim it is a border RBridge by claiming
> ownership of at least one Level 2 nickname.
>
>> (2.2) rfc8243 talks about the (potential) ability of border RBridges to
>> "discover each other...by using the IS-IS "attached bit" [IS-IS] or by
>> explicitly advertising in their LSP "I am a border RBridge".  But I didn't 
>> see
>> these options/mechanisms mentioned in this document.
>
> Border RBridges know they are border RBridges because, by
> configuration, they are talking to both Level 1 and 2. They act
> specially but it is not clear what good looking at the attached bit or
> border RBridges advertising that explicitly in the LSP would do. If
> you are in Level 2 and see some Level 2 RBridge advertising that it
> owns Level 1 nicknames, you know it is a border RBridge and likewise,
> if you are in Level 1 and see some Level 1 RBridge advetising that it
> owns Level 2 nicknames, you know it is a border RBridge. And the
> nicknames are distinguished by being taken from mutually exclusive
> ranges of nicknames.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)

[Donald Eastlake]

Hi Eric,

A -07 version of draft-ietf-trill-multilevel-unique-nickname has been
posted with the intent of resolving your comment.

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


On Mon, Mar 12, 2018 at 11:49 PM, Donald Eastlake <d3e...@gmail.com> wrote:
> Hi Eric,
>
> On Thu, Mar 8, 2018 at 9:27 AM, Eric Rescorla <e...@rtfm.com> wrote:
>>
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-trill-multilevel-unique-nickname-06: No Objection
>>
>> ...
>>
>> --
>> COMMENT:
>> --
>>
>> In the security considerations,  isn't the requirement not that you configure
>> IS-IS authentication but that you actually have to require it on receipt? Or
>> are these the same things.
>
> I must admit that the current wording just talks about inclusion of
> authentication TLVs in a way which seems to leave out checking them
> :-)
>
> The wording should be improved.
>
>> Even with ordinary trill, can't you just spoof a lot of announcements with
>> other people's nicknames? Why is this different?
>
> Well, it is a bit more complex with IS-IS. It depends on just what you
> try to spoof. If you spoof an announcement from some existing RBridge,
> as soon as it is flooded to the claimed source RBridge that RBridge
> will issue an overwritting announcement or purge. But, unless you turn
> on appropriate security, there are ways to spoof announcements that
> would have bad effects.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Kathleen Moriarty's Discuss on draft-ietf-trill-transport-over-mpls-07: (with DISCUSS)

[Donald Eastlake]

Hi Kathleen,

On Wed, Mar 14, 2018 at 2:28 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:
> Hi Donald,
>
> Thanks for the proposed text.  Please see inline.
>
> On Mon, Mar 12, 2018 at 10:01 PM, Donald Eastlake <d3e...@gmail.com>
wrote:
>> Hi Kathleen,
>>
>> Would the following replacement Security Considerations section for
>> draft-ietf-trill-transport-over-mpls be adequate?
>>
>>
>>This document specifies methods using existing standards and
>>facilities in ways that do not create new security problems.
>>
>>For general VPLS security considerations, including discussion of
>>isolating customers from each other, see [RFC4761] and [RFC4762].
>>
>>For transport of TRILL by Pseudowires security consideration, see
>>[RFC7173]. In particular, since pseudowires are support by MPLS or IP
>>which are in turn supported by a link layer, that document recommends
>>using IP security or the lower link layer security.
>>
>>For added security against the compromise of data end-to-end
>>encryption and authentication should be considered; that is,
>>encryption and authentication from source end station to destination
>>end station.
>
> Would this be accomplished through IPsec?

For end-to-end security, it could be. Or DTLS. Whatever is convenient for
the information you want to protect. Since end stations are connected to
edge TRILL switches via Ethernet, if you wanted to protect all of the data
between two end stations, you could use IEEE Std 802.1AE. Do you want a
list added?

> If encryption and authentication are not employed, what are the risks
> to tenant isolation since this draft joins TRILL campuses?

I wouldn't say that the draft "joins TRILL campuses". If a TRILL campus is
actually structured so that the connectivity being provided is connecting
two islands, then you could say it is making those TRILL switches parts of
the same campus. The term "campus" in TRILL is not intended to have any
geographic (or academic) implication but rather, to be for TRILL switches
the same as the term "bridged LAN" is for IEEE 802.1 bridges.

Whenever a link extends outside local physical control, there is increased
risk. Assuming a link between two TRILL switch ports in a TRILL campus is
Ethernet, it could be anything from a little copper on a backplane inside a
cabinet to Ethernet connectivity purchased from a carrier and extending
hundreds of miles.

If you are talking about the risk of a TRILL campus merging with a
malicious TRILL switch, that can be avoided by IS-IS PDU authentication.
Until adjacency is establish (RFC 7177), which requires successful exchange
of IS-IS Hellos PDUs, no data will flow.

> I think
> there should be text that explains this risk in addition to the text
> already proposed.

How about adding text like the following:


Transmission outside the customer environment through the provider
environment, as described in this document, increases risk of compromise or
injection of false data through failure of tenant isolation or by the
provider. In the VPLS model (Section 3), the use of link encryption and
authentication between the CEs of a tenant that is being connected through
provider facilities should be a good defense. In the VPTS model (Section
4), it is assumed that the CEs will peer with virtual TRILL switches of the
provider network and thus link security between TRILL switch ports is
inadequate as it will terminate at the edge PE. Thus, end station to end
station encryption and authentication is more appropriate for the VPTS
model.


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

> Thanks,
> Kathleen
>
>>
>>For general TRILL security considerations, see [RFC6325].
>>
>>
>> Thanks,
>> Donald
>> ===
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  d3e...@gmail.com
>>
>> On Wed, Mar 7, 2018 at 5:35 PM, Andrew G. Malis <agma...@gmail.com>
wrote:
>>>
>>> Kathleen,
>>>
>>> I don’t want to speak for the authors. However, I did contribute to this
>>> draft (although not this specific section). So that said, here’s my two
>>> cents ….
>>>
>>> I agree that first sentence could have been worded better, but the
bottom
>>> line is that depending on the model used, the security considerations
for
>>> RFC 7173, 4761, or 4762 applies, including the discussions in those
RFCs on
>>> issues such as isolation and end-to-end security. Those RFCs are
referenced
>>> in 

Re: [trill] Alissa Cooper's Discuss on draft-ietf-trill-smart-endnodes-10: (withDISCUSS and COMMENT)

[Donald Eastlake]

Hi Alissa,

A -11 version of draft-ietf-trill-smart-endnodes has been uploaded
with the intent of resolving your discuss. Please look at it and see
if you can clear.

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


On Wed, Mar 7, 2018 at 2:35 PM, Donald Eastlake <d3e...@gmail.com> wrote:
> On Wed, Mar 7, 2018 at 10:01 AM, Alissa Cooper <ali...@cooperw.in> wrote:
>> Hi Fangwei,
>>
>> As I noted in response to the Gen-ART reviewer, I managed to ballot before
>> reading the rest of this thread (sorry!), but I still think the diagram in
>> 4.3 is confusing and not consistent with the text. To my eye row 3 shows
>> two
>> bytes’ worth of fields but the label says “4 bytes.” RSV is depicted as 2
>> bits but the text says it is 6 bits. The combination of these two
>> inconsistencies makes it hard to know what the actual lengths are supposed
>> to be.
>
> I agree that the figure is a little confusing. I suggest the following:
>
> +-+-+-+-+-+-+-+-+
> |Type=Smart-MAC |  (1 byte)
> +-+-+-+-+-+-+-+-+
> |   Length  |  (1 byte)
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+
> |F|M|  RSV  |  VLAN/FGL Data Label |  (4 bytes)
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |  MAC (1)(6 bytes)|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |  .   |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |  MAC (N)(6 bytes)|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com
>
>
>> Alissa
>>
>> On Mar 7, 2018, at 12:55 AM, hu.fang...@zte.com.cn wrote:
>>
>> Hi，Alissa Cooper
>>
>> Thanks for your review and comments.
>>
>> The new version(version 10)  has updated to fix your comments.
>>
>> The format of Smart-MAC APP sub-TLV and the text  has been changed to the
>> following:
>>
>> The length of F,M,RSV,VLAN/FGL data Label is 4 bytes. and the length of
>> VLAN/FGL Data Label field is 24 bits.
>>
>>
>>+-+-+-+-+-+-+-+-+
>> |Type=Smart-MAC |  (1 byte)
>> +-+-+-+-+-+-+-+-+
>> |   Length  |  (1 byte)
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |F|M|RSV|  VLAN/FGL Data Label  |  (4 bytes)
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |  MAC (1)   (6 bytes) |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |  .   |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |  MAC (N)   (6 bytes) |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>  Figure 3 Smart-MAC APPsub-TLV
>>
>>
>>o  VLAN/FGL Data Label: 24bits.  If F is 1, this field is a 24-bit
>>   FGL Data Label for all subsequent MAC addresses in this APPsub-
>>   TLV.  Otherwise, if F is 0, the lower 12 bits is the VLAN of all
>>   subsequent MAC addresses in this APPsub-TLV, and the upper 12 bits
>>   is not used(sent as zero and ignored on receipt).  If there is no
>>   VLAN/FGL data label specified, the VLAN/FGL Data Label is zero.
>>
>>
>>
>>
>> Regards.
>>
>> Fangwei.
>>
>> 原始邮件
>> 发件人：AlissaCooper <ali...@cooperw.in>
>> 收件人：The IESG <i...@ietf.org>
>> 抄送人：draft-ietf-trill-smart-endno...@ietf.org
>> <draft-ietf-trill-smart-endno...@ietf.org>trill-cha...@ietf.org
>> <trill-cha...@ietf.org>sha...@ndzh.com <sha...@ndzh.com>trill@ietf.org
>> <trill@ietf.org>
>> 日 期 ：2018年03月07日 04:45
>> 主 题 ：Alissa Cooper's Discuss on draft-ietf-trill-smart-endnodes-10:
>> (withDISCUSS and COMMENT)
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-trill-smart-endnodes-10: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this

Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-smart-endnodes-10: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi Eric,

A -11 version of draft-ietf-trill-smart-endnodes has been uploaded
with the intent of resolving your Discuss. Please look at it and see
if you can clear.\

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


On Sat, Mar 10, 2018 at 9:22 PM, Donald Eastlake <d3e...@gmail.com> wrote:
> Hi Eric,
>
> On Thu, Mar 8, 2018 at 8:44 AM, Eric Rescorla <e...@rtfm.com> wrote:
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-trill-smart-endnodes-10: Discuss
>>
>> ...
>>
>> --
>> DISCUSS:
>> --
>>
>> Review in context at: https://mozphab-ietf.devsvcdev.mozaws.net/D3548
>>
>>Smart Endnodes would not bring more security and vulnerability issues
>>than the TRILL ES-IS security defined in [RFC8171].
>>
>> IMPORTANT: I think you need to discuss the security implications of
>> checking and/or not checking the smart endnodes MAC address (a MAY in
>> S 5.2). My understanding is that TRILL is kind of wishy-washy on MAC
>> spoofing in general, but if you *do* have some sort of MAC enforcement
>> in place but you don't enforce here, then this obviously bypasses
>> that. Similar comments apply to the SmartHello filtering, I think.
>
> OK on data.
>
> Smart Hellos are a very different thing. They are TRILL ES-IS PDUs
> always sent to the TRILL-ES-IS multicast Ethernet address (see
> Sections 5 and 7.6 of RFC 8171). The source MAC address of such PDUs
> is an important protocol field that is made available to the code
> processing the PDU. The first Smart Hello received from an End Station
> would be from an unknown MAC until adjacency is established, unless
> that MAC address was specially configured or something, even if that
> end station is a valid Smart Endnode. You might want an RBridge port
> to drop all Ethernet frames that are not from white-listed MACs or
> something, but that sort of general Ethernet port security feature
> isn't properly part of TRILL.
>
> Since connections from end stations to edge RBridge ports are
> Ethernet, such ports can always require end stations to authenticate
> themselves with [802.1X} and encrypt and authenticate traffic between
> the end station and the edge RBridge port with [802.1AE] (MACSEC) as
> discussed in the base TRILL protocol specification draft [RFC6325].
> This seems more powerful than just checking a MAC address although you
> could always do both.
>
> I'm not sure it should be necessary for every TRILL draft the
> optionally further empowers an end station to have to go into all
> these layer 2 security options given that MACSEC is mentioned in the
> base TRILL protocol specification that is referenced.
>
>>Smart-Hellos can be secured by using Authentication TLVs based on
>>[RFC5310].
>>
>> I concur with Ben that you should explain the consequences of doing this or 
>> not.
>
> OK, although I don't think there is much to say other than that
> checking such authentication stops rogue end nodes not in possession
> of the required keying material from being recognized as a valid smart
> end node.
>
>> --
>> COMMENT:
>> --
>>
>>
>> If SE1 wishes to correspond with destination MAC D, and no endnode
>>entry exists, SE1 will encapsulate the packet as an unknown
>>
>> Should D be shown on the diagram below? I don't see it.
>
> Yeah, probably the network connection to Endnode1 should be labelled D.
>
>>   the same meaning as the Holding Time field in IS-IS Hellos [IS-IS]
>>   . A Smart Endnode and an Edge RBridge supporting Smart Endnodes
>>   MUST send a Smart-Hello at least three times during their Holding
>>
>> Ooh, bad break here at this period.
>
> OK.
>
>>o  MAC(i): This is a 48-bit MAC address reachable in the Data Label
>>   given from the Smart Endnode that is announcing this APPsub-TLV.
>>
>> does "given from" mean something different than "sent by"?
>
> No. "sent by" would be more usual wording.
>
>>o  When SE1 wishes to send a multi-destination (multicast, unknown
>>   unicast, or broadcast) to the TRILL campus, SE1 encapsulates the
>>   packet using one of the trees that RB1 has specified.
>>
>> I see this called "BUM" in other documents. T

Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)

[Donald Eastlake]

Hi Alvaro,

On Tue, Mar 6, 2018 at 12:37 PM, Alvaro Retana  wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-multilevel-unique-nickname-06: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> (1) The nickname selection process for multilevel is not backwards compatible
> because of the use of the NickBlockFlags APPsub-TLV.  That is ok since the
> border RBridges can recognize "old" Rbridges (ones that don't support this
> specification) in an area. A couple of related comments:
>
> (1.1) Section 4.4. (Capability Indication) says that "Non border RBridges in 
> an
> area SHOULD understand the NickBlockFlags APPsub-TLV."  That statement is
> somewhat contradictory (maybe that's not the right word, but the only one that
> comes to mind):
>
> - On one hand, non border RBridges could be just be "old" (ones that don't
> support this specification).  We can't normatively specify something that by
> definition nodes that don't support this specification won't know about.
>
> - On the other hand, if the non border Rbridge does support this 
> specficiation,
> then why wouldn't it understand the NickBlockFlags APPsub-TLV?  IOW, why isn't
> the "SHOULD" a "MUST" instead?  When is it ok to not do it?
>
> All this is to say that I think that "SHOULD" should not be used normatively.
> s/SHOULD/should

Sounds reasonable to me.

> (1.2) Given that rfc6325 specifies a single Level 1 network, it is reasonable
> to expect that networks implementing these multilevel extensions will grow 
> from
> a single area to multiple.  It would be ideal to include Deployment
> Considerations to discuss what a Migration Path would look like.
>
> (2) Maybe I missed it somewhere...  The Security Considerations section says
> that "border RBridges need to fabricate the nickname announcements...Malicious
> devices may also fake the NickBlockFlags APPsub-TLV to announce a range of
> nicknames."  I'm sure that malicious devices don't only include ones that are
> unauthenticated, but may include over or under claiming by existing border
> RBridges or even non border RBridges originating the NickBlockFlags 
> APPsub-TLV.
>
> (2.1) Is the origination of the NickBlockFlags APPsub-TLV restricted to border
> RBridges?  If so, why isn't there a check to make sure that the NickBlockFlags
> APPsub-TLV came from a border RBridge?

Such a check would add some complexity and it is not clear there would
be much gain as an RBridge that is forging NickBlockFlags APPsub-TLVs
would presumably just falsely claim it is a border RBridge by claiming
ownership of at least one Level 2 nickname.

> (2.2) rfc8243 talks about the (potential) ability of border RBridges to
> "discover each other...by using the IS-IS "attached bit" [IS-IS] or by
> explicitly advertising in their LSP "I am a border RBridge".  But I didn't see
> these options/mechanisms mentioned in this document.

Border RBridges know they are border RBridges because, by
configuration, they are talking to both Level 1 and 2. They act
specially but it is not clear what good looking at the attached bit or
border RBridges advertising that explicitly in the LSP would do. If
you are in Level 2 and see some Level 2 RBridge advertising that it
owns Level 1 nicknames, you know it is a border RBridge and likewise,
if you are in Level 1 and see some Level 1 RBridge advetising that it
owns Level 2 nicknames, you know it is a border RBridge. And the
nicknames are distinguished by being taken from mutually exclusive
ranges of nicknames.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)

[Donald Eastlake]

Hi Eric,

On Thu, Mar 8, 2018 at 9:27 AM, Eric Rescorla  wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-trill-multilevel-unique-nickname-06: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> In the security considerations,  isn't the requirement not that you configure
> IS-IS authentication but that you actually have to require it on receipt? Or
> are these the same things.

I must admit that the current wording just talks about inclusion of
authentication TLVs in a way which seems to leave out checking them
:-)

The wording should be improved.

> Even with ordinary trill, can't you just spoof a lot of announcements with
> other people's nicknames? Why is this different?

Well, it is a bit more complex with IS-IS. It depends on just what you
try to spoof. If you spoof an announcement from some existing RBridge,
as soon as it is flooded to the claimed source RBridge that RBridge
will issue an overwritting announcement or purge. But, unless you turn
on appropriate security, there are ways to spoof announcements that
would have bad effects.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Kathleen Moriarty's Discuss on draft-ietf-trill-transport-over-mpls-07: (with DISCUSS)

[Donald Eastlake]

Hi Kathleen,

Would the following replacement Security Considerations section for
draft-ietf-trill-transport-over-mpls be adequate?


   This document specifies methods using existing standards and
   facilities in ways that do not create new security problems.

   For general VPLS security considerations, including discussion of
   isolating customers from each other, see [RFC4761] and [RFC4762].

   For transport of TRILL by Pseudowires security consideration, see
   [RFC7173]. In particular, since pseudowires are support by MPLS or IP
   which are in turn supported by a link layer, that document recommends
   using IP security or the lower link layer security.

   For added security against the compromise of data end-to-end
   encryption and authentication should be considered; that is,
   encryption and authentication from source end station to destination
   end station.

   For general TRILL security considerations, see [RFC6325].


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

On Wed, Mar 7, 2018 at 5:35 PM, Andrew G. Malis  wrote:

> Kathleen,
>
> I don’t want to speak for the authors. However, I did contribute to this
> draft (although not this specific section). So that said, here’s my two
> cents ….
>
> I agree that first sentence could have been worded better, but the bottom
> line is that depending on the model used, the security considerations for
> RFC 7173, 4761, or 4762 applies, including the discussions in those RFCs on
> issues such as isolation and end-to-end security. Those RFCs are referenced
> in the security section. So the substance is already there, perhaps the
> draft just needs better pointers to it.
>
> Cheers,
> Andy
>
>
> On Wed, Mar 7, 2018 at 5:01 PM, Kathleen Moriarty <
> kathleen.moriarty.i...@gmail.com> wrote:
>
>> Kathleen Moriarty has entered the following ballot position for
>> draft-ietf-trill-transport-over-mpls-07: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-trill-transport-over-mpls/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> I was very surprised to see the following in the security considerations
>> section and would like to work with you on improvements.
>>As an informational document specifying methods that use only
>>existing standards and facilities, this document has no effect on
>>security.
>>
>> Having watched many TRILL documents go by in the last 4 years, we didn't
>> push
>> too hard on security in some cases as a result of the restriction to a
>> campus
>> network.  This particular document extends into multi-tenancy where there
>> are
>> certainly security considerations introduced to be able to provide
>> isolation
>> properties.  MPLS offers no security and it is being used to join TRILL
>> campuses as described int his draft.  This is done without any
>> requirement of
>> an overlay protocol to provide security - why is that the case?
>> Minimally, the
>> considerations need to be explained.  Ideally, a solution should be
>> offered to
>> protect tenants when TRILL campuses are joined.
>>
>>
>>
>>
>> ___
>> trill mailing list
>> trill@ietf.org
>> https://www.ietf.org/mailman/listinfo/trill
>>
>
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-smart-endnodes-10: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi Eric,

On Thu, Mar 8, 2018 at 8:44 AM, Eric Rescorla  wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-trill-smart-endnodes-10: Discuss
>
> ...
>
> --
> DISCUSS:
> --
>
> Review in context at: https://mozphab-ietf.devsvcdev.mozaws.net/D3548
>
>Smart Endnodes would not bring more security and vulnerability issues
>than the TRILL ES-IS security defined in [RFC8171].
>
> IMPORTANT: I think you need to discuss the security implications of
> checking and/or not checking the smart endnodes MAC address (a MAY in
> S 5.2). My understanding is that TRILL is kind of wishy-washy on MAC
> spoofing in general, but if you *do* have some sort of MAC enforcement
> in place but you don't enforce here, then this obviously bypasses
> that. Similar comments apply to the SmartHello filtering, I think.

OK on data.

Smart Hellos are a very different thing. They are TRILL ES-IS PDUs
always sent to the TRILL-ES-IS multicast Ethernet address (see
Sections 5 and 7.6 of RFC 8171). The source MAC address of such PDUs
is an important protocol field that is made available to the code
processing the PDU. The first Smart Hello received from an End Station
would be from an unknown MAC until adjacency is established, unless
that MAC address was specially configured or something, even if that
end station is a valid Smart Endnode. You might want an RBridge port
to drop all Ethernet frames that are not from white-listed MACs or
something, but that sort of general Ethernet port security feature
isn't properly part of TRILL.

Since connections from end stations to edge RBridge ports are
Ethernet, such ports can always require end stations to authenticate
themselves with [802.1X} and encrypt and authenticate traffic between
the end station and the edge RBridge port with [802.1AE] (MACSEC) as
discussed in the base TRILL protocol specification draft [RFC6325].
This seems more powerful than just checking a MAC address although you
could always do both.

I'm not sure it should be necessary for every TRILL draft the
optionally further empowers an end station to have to go into all
these layer 2 security options given that MACSEC is mentioned in the
base TRILL protocol specification that is referenced.

>Smart-Hellos can be secured by using Authentication TLVs based on
>[RFC5310].
>
> I concur with Ben that you should explain the consequences of doing this or 
> not.

OK, although I don't think there is much to say other than that
checking such authentication stops rogue end nodes not in possession
of the required keying material from being recognized as a valid smart
end node.

> --
> COMMENT:
> --
>
>
> If SE1 wishes to correspond with destination MAC D, and no endnode
>entry exists, SE1 will encapsulate the packet as an unknown
>
> Should D be shown on the diagram below? I don't see it.

Yeah, probably the network connection to Endnode1 should be labelled D.

>   the same meaning as the Holding Time field in IS-IS Hellos [IS-IS]
>   . A Smart Endnode and an Edge RBridge supporting Smart Endnodes
>   MUST send a Smart-Hello at least three times during their Holding
>
> Ooh, bad break here at this period.

OK.

>o  MAC(i): This is a 48-bit MAC address reachable in the Data Label
>   given from the Smart Endnode that is announcing this APPsub-TLV.
>
> does "given from" mean something different than "sent by"?

No. "sent by" would be more usual wording.

>o  When SE1 wishes to send a multi-destination (multicast, unknown
>   unicast, or broadcast) to the TRILL campus, SE1 encapsulates the
>   packet using one of the trees that RB1 has specified.
>
> I see this called "BUM" in other documents. This is a nit, but do you
> want to use consistent terminology?

I think too many documents overuse acronyms. If this draft wants to
list out the sub-types or use "multi-destination" instead of the
acronym, I think that's good.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Mirja Kuehlewind's Discuss on draft-ietf-trill-over-ip-

[Donald Eastlake]

Hi Mirja,

I though I would try to respond to your discuss/comments so far to expedite
things.

> DSCP
> -

> 1) Section 4.3 should also talk about decapsulation as DCSP is often
> overwritten on the path and therefore the DCSP of the inner and
> other IP headers can differe on decapsulation. Please see RFC2983
> for further guidance. You probabably should specify to discard the
> outer DSCP at tunnel egress in your use case.

Yes, I don't think there is anything in the draft even hinting about
copying outer DSCP into inner DSCP and in any case the payload will not
always be IP. Adding something specific saying don't do that is fine.

> 2) Further it is not clear to me if the use of CS7 in appropriate
> for this use case as RFC 4594 says

"   o  CS7 marked packets SHOULD NOT be sent across peering points.
  Exchange of control information across peering points SHOULD be
  done using CS6 DSCP and the Network Control service class."

My question is: Does this 12 year old advice from an Informational RFC
still apply? The mapping to DSCP provisions have been specifically looked
at by
knowledgeable people, including David Black, and no one has mentioned a
prohibition against the use of CS7 before.

> 3) Moreover, if my understanding is correct, the high priority
> classes in TRILL are not exclusively reserved for control data.
> However, CS6 and CS7 is only meant for control and rounting traffic.
> If those classes are used it must be ensure that the traffic sent
> with these DSCP is not overloading the network. I think further
> (security) considertations are needed here.

OK.

> Broadcast Link Encapsulation Considerations
> --
> Not every transport encapsualtion can be used for
> Broadcast/Multicast. TCP cannot be used. This is mention later but
> also be consider in the text in section 5.3

OK.

> TCP Encapsulation
> -

> If my understanding is correct than TRILL does not know that the
> connect of a TRILL data packet is. That means the data could can
> also contain traffic that is runing over TCP, right? Encapsulating
> TCP in TCP should generally avoided if possible and need further
> considerations as loss in the outer control loop that is used on the
> TRILL IP link appears as strongly varying delays to the inner
> control loop and therefore can have very negative effects.

Would it be sufficient to note this problem and say that TCP should only be
used where loss rates are low?

> TCP Connection Establishment (section 5.6.1)
> -
> This section seem to assume for all configured or discovered tunnel
> endpoints there should be immeditately (at node start up time) and
> permantly a/multiple open TCP connections. I'm in general uncertain
> if this is the right approach. However, even if the connection is
> not closed, it might not be usable after an idle time, as middlebox
> on the path may have removed their state. Therefore to keep a
> connection permanently the endpoint need probaly to send
> keep-alives, or alternative a meachism to detect such a failure
> (quickly) and re-establish the connection such be used. However,

Middleboxes are out of scope for this draft. However, I think we'd be happy
to add a little parenthetical encouraging keep alives. Failures will be
detected, perhaps somewhat slowly, by Hellos not getting through. For more
rapid detection, BFD, which TRILL supports (RFC 7175), should be used.

> Comment (2018-03-08)

> Editorial coments:

> 1) It is really confusing that the whole document is talking about
> ports as tunnel endpoints while it also often talks about transport
> (TCP/UDP) ports. It makes it really hard to read this document.
> Maybe these things can be better distighlished somehow.

I must admit that I'm a little confused about what are the best words to
use in meeting the TRILL Charter goal of specifying "TRILL over IP". I
think the important thing, as usual with IETF protocols, is the bits on the
wire, and just changing the words shouldn't change the bits. The word
"transport" is a very recent addition throughout the draft and could be
removed if that is desired.

Whatever gets packets from a TRILL switch port to another TRILL switch port
is typically thought of as a "link" from the TRILL viewpoint. The base
TRILL protocol RFC specified this for Ethernet and treats an arbitrary
bridged LAN, including the common simple case of a point-to-point Ethernet
wire, as a link. There are RFCs specifying PPP and pseudowire technology
"links" between TRILL switch ports. This draft just treats various IP based
encapsulations as a way to get packets from one TRILL switch port to
another.

> 2) This document should not re-specify the UDP header (5.4). At
> minimum the text should be changed the following way.

> OLD
> "Where he UDP Header is as follows:"
> NEW
> "Where he UDP Header is as follows as specified in [RFC0768] :"

OK. Could change to "Where the UDP Header is as specified in [RFC0768]."
and drop the diagram.

Thanks,
Donald

Re: [trill] Kathleen Moriarty's No Objection on draft-ietf-trill-vendor-channel-00: (with COMMENT)

[Donald Eastlake]

Hi Kathleen,

Thanks. I'll get this -01 version posted and ask Alia to release it to the
RFC Editor.

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

On Fri, Mar 9, 2018 at 3:41 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Hi Donald,
>
> On Thu, Mar 8, 2018 at 12:46 AM, Donald Eastlake <d3e...@gmail.com> wrote:
> > Hi Kathleen,
> >
> > On Wed, Mar 7, 2018 at 10:57 AM, Kathleen Moriarty
> > <kathleen.moriarty.i...@gmail.com> wrote:
> >> Kathleen Moriarty has entered the following ballot position for
> >> draft-ietf-trill-vendor-channel-00: No Objection
> >>
> >> ...
> >>
> >> --
> >> COMMENT:
> >> --
> >>
> >> Could you please expand the text in the security considerations section
> as to
> >> why security properties (integrity, authentication, and encryption
> since they
> >> are not part of RBridge Channel messages except when explicitly added
> on in the
> >> extension draft) were not built in?  I'm assuming it is the limited
> scope of
> >> use for the protocol.  I am glad that options exist to add it in, but
> wish the
> >> text were a bit more encouraging so that would actually happen.
> Vendors need
> >> to be motivated to provide these options for customers who may want to
> use
> >> them, without that motivation, the features won't be provided.
> >
> > See attached candidate draft-ietf-trill-vendor-channel-01.txt and diff
> > against the currently posted -00. Does this answer your request for an
> > explanation as to why the basic TRILL RBridge Channel does not provide
> > security services?
>
> The text helps to explain the background, so thank you for that.  I
> would have liked to see more on the scope or reasons why this
> extension might not need more (or if it does), but won't press for it
> as this is an improvement.
>
> Thanks,
> Kathleen
>
> >
> > Thanks,
> > Donald
> > ===
> >  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> >  155 Beaver Street, Milford, MA 01757 USA
> >  d3e...@gmail.com
>
>
>
> --
>
> Best regards,
> Kathleen
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Genart telechat review of draft-ietf-trill-over-ip-15

[Donald Eastlake]

Hi Matthew,

On Thu, Mar 8, 2018 at 1:59 AM, Matthew Miller
 wrote:
> Reviewer: Matthew Miller
> Review result: Ready with Nits
>
> 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
>
> .
>
> Document: draft-ietf-trill-over-ip-15
> Reviewer: Matthew A. Miller
> Review Date: 2018-03-07
> IETF LC End Date: 2018-03-06
> IESG Telechat date: 2018-03-08
>
> Summary:  Ready with nits
>
> Major issues: NONE
>
> Minor issues: NONE
>
> Nits/editorial comments:

I find the way you have formatted your comments to be confusing. I
think there should be a clear demarkation where all the material
related to a comment ends and that for the next comment begins. You
seem to use the same unusual triple double quotation mark delimiter
between your comment and your marked up text from the draft related to
that comment.

> * In Section 4.5. "TRILL Over IP Transport IS-IS SubNetwork Point
> of Attachment", the word "of" between ""
>
> """
> The Hellos transmitted out [of] a port indicate what neighbor ports
> that port can see on the link by listing what IS-IS refers to as the
> neighbor port's SubNetwork Point of Attachment (SNPA)
> """
>
> * In Section 5.2. "Encapsulation Agreement", the first sentence is
> difficult to understand; I think it is missing the word "on" between
> "sent out" and "a TRILL over IP":
>
> """
> TRILL Hellos sent out [on] a TRILL over IP transport port indicate the
> encapsulations for which that port is offering full support through a
> mechanism initially specified in [RFC7178] and [RFC7176] that is
> hereby extended.
> """

I do not think the insertions you recommend are necessary but I'm
willing to make them.

> * In Section 5.4. "Native Encapsulation", the word "he" should be
> "the" in the sentence "Where he UDP Header is as follows".

OK

> * In Section 5.6.1. "TCP Connection Establishment", the word
> "connections" should be singular (or the leading "a" dropped) in the
> fragment "try to establish a TCP connections to each of them".

Changing "connections" to "connection" seems best.

> * In Section 5.6.1. "TCP Connection Establishment", the occurrence of
> "P!" should be changed to "P1".

OK.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-multi-topology-05: (with COMMENT)

[Donald Eastlake]

Hi Eric,

On Thu, Mar 8, 2018 at 9:05 AM, Eric Rescorla  wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-trill-multi-topology-05: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> Review in context: https://mozphab-ietf.devsvcdev.mozaws.net/D3642
>
> A diagram in the introduction would have helped me.
>
> Grained Label [RFC7172]. By implication, an "FGL TRILL
> switch" does not support MT.
> You are using MT before expansion here. But I actually don't understand why it
> does not. Can you explain?
>
> implication, a "VL RBridge" or "VL TRILL switch" does not
> support FGL or MT.
> My same question here as above. Why can't a VL TRILL switch support MT?

All TRILL implementations support VLANs. See TRILL Base Protocol
specification RFC 6325.

Fine grained labels were added in RFC 7172. There are actually two
levels: (1) FGL safe, which means it can transit fine grained labels
but cannot ingress or egress them, and (2) full FGL support which can
also ingress/egress to/from fine grained labeled TRILL Data packets.
It is really desirable to have RBridges be FGL safe so you can have,
say, a TRILL campus with an island or two of fully FGL capable
RBridges and not have to worry that data packets they produce will get
tossed if they happen to hit an older RBridge. And it's pretty easy to
be FGL safe, you just have to not explicitly check in the inner label
and drop the frame if it isn't an ordinary VLAN.

When Multi-Topology was added, it could have been independent of FGL
so you have a lattice of capabilities but the decision was made to
have a sequence instead to avoid starting on a combinatorial explosion
of combinations of options, simplify testing, etc. So its VL < FGL <
MT with each implying support of the previous.

>(1) all TRILL switch ports on the link advertise topology T support
>in their Hellos and
>(2) if any TRILL switch port on the link requires explicit TRILL Data
> Probably stupid question but how do you know that there aren't TRILL switches
> that you haven't heard from yet that don't support T?

If you haven't heard from then, then you haven't established adjacency
with them (see adjacency establishment mechanism in RFC 7177) and you
will therefore ignore data packets from them and will not attempt to
send data packets to them. The process of adjacency establishment
includes learning about MT support in the exchanged Hellos.

>  V -  The version number of the MT label. This document specifies
>  version zero.
> What do I do if I receive an unknown version?

I think if the label has a non-zero version, it would not be
understood by an RBridge that implements this draft and the packet
must be dropped. Any other behavior seems unsafe. This should probably
be explicitly stated.

>  +  There may be non-zero topologies with no multi-destination
> traffic or, as descried in [RFC5120], even topologies with
> no traffic at all. For example, if only known destination
> Nit: described

OK

> topology, there would be no need for a distribution tree for
> topology T.  For this reasons, a Number of Trees to Compute
> of zero in the Trees sub-TLV for the TRILL switch holding
> Nit: "reason"

OK.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-directory-assisted-encap-10: (with COMMENT)

[Donald Eastlake]

Hi Eric,

On Wed, Mar 7, 2018 at 11:41 PM, Eric Rescorla  wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-trill-directory-assisted-encap-10: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> I support Alvaro's DISCUSS and Kathleen's comment
>
> I also think it would be useful to emphasize the need for some security on the
> links between the egress and ingress nodes, although presumably that's a
> standard TRILL consideration.

Sure. The links between TRILL nodes can be a variety of technologies.
So security on on the links depends on the link technology and is
discussed in the RFC covering TRILL over that link technology.

> Finally
>   nodes. Such spoofing cannot cause looping traffic because TRILL has a
>  hop count in the TRILL header [RFC6325] so that, should there be a
>   loop, a TRILL packet caught in that loop (i.e., an encapsulated
>   frame) will be discarded.
>
> Is it in fact the case that it cannot cause looping or merely that the loop is
> contained by the hop count? Perhaps this is just a terminology issue and in
> routing loop just means infinite loop?

Should probably say "...persistently looping traffic...".

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-smart-endnodes-10: (with DISCUSS)

[Donald Eastlake]

Hi Alvaro,

On Mon, Mar 5, 2018 at 4:34 PM, Alvaro Retana  wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-smart-endnodes-10: Discuss
>
> ...
>
> --
> DISCUSS:
> --
>
> This document feels tightly coupled with
> draft-ietf-trill-directory-assisted-encap, even though there are no
> cross-references.  If I understand the mechanisms correctly, a Smart Endnode
> (discussed in this draft) can then do directory assisted encapsulation
> (described in draft-ietf-trill-directory-assisted-encap).  In fact, the
> encapsulation/decapsulation seems to be the main motivation in defining a 
> Smart
> Endnode.

There are similarities, but I'm not sure I would say that
draft-ietf-trill-directory-assisted-encap and
draft-ietf-trill-smart-endnodes are "tightly coupled".

trill-directory-assisted-encap is the best you can do with no changes
to RBridges as specified in the TRILL Base Protocol [RFC6325]. Special
end stations can do the encapsulation but edge RBridges always do the
decapsuation.

trill-smart-endnodes requires additional mechanisms in the edge
RBridges to shake hands with the smart endnode, recognize when a
destination MAC is being handled by the smart endnode and just forward
it without decapslation, etc. As a result, this also support smart
endnodes that are fine grained label aware.

> I think then that this document also falls short in the exploration of
> potential issues, so I am also balloting DISCUSS.  The same cases that I
> pointed at for draft-ietf-trill-directory-assisted-encap [1] are applicable
> here -- with the added caveat that the Smart Endnode, in general, has other
> sources of information (learning, etc.), which means that there are 
> potentially
> more doors to close.

OK, similar security consideration text improvements can presumably be
made to this draft.

> The Multi-homing Scenario (Section 6) adds some complexity to the ability to
> check whether the Ingress RBridge is set correctly in the encapsulation.  It
> would be nice to explore this case a little further and highlight the issues 
> as
> the topologies get more complex.
>
> As I wrote in [1], I don't think that there are easy mitigations for these
> issues, but at least mentioning them so that operators are aware of the risk
> would be enough to clear this DISCUSS.  Given that the authors partially
> overlap, it may be a good idea to solve the issue in this document (which is
> the general case) and then just have the other one point this way.
>
> [1]
> https://mailarchive.ietf.org/arch/msg/trill/xZvEj_9FtSgHSp4DnKCVxr670gc/?qid=1e5a9496ac80237a3f7cc6aeea09d24d

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Alissa Cooper's Discuss on draft-ietf-trill-smart-endnodes-10: (withDISCUSS and COMMENT)

[Donald Eastlake]

On Wed, Mar 7, 2018 at 10:01 AM, Alissa Cooper  wrote:
> Hi Fangwei,
>
> As I noted in response to the Gen-ART reviewer, I managed to ballot before
> reading the rest of this thread (sorry!), but I still think the diagram in
> 4.3 is confusing and not consistent with the text. To my eye row 3 shows
two
> bytes’ worth of fields but the label says “4 bytes.” RSV is depicted as 2
> bits but the text says it is 6 bits. The combination of these two
> inconsistencies makes it hard to know what the actual lengths are supposed
> to be.

I agree that the figure is a little confusing. I suggest the following:

+-+-+-+-+-+-+-+-+
|Type=Smart-MAC |  (1 byte)
+-+-+-+-+-+-+-+-+
|   Length  |  (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+
|F|M|  RSV  |  VLAN/FGL Data Label |  (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  MAC (1)(6 bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  .   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  MAC (N)(6 bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

> Alissa
>
> On Mar 7, 2018, at 12:55 AM, hu.fang...@zte.com.cn wrote:
>
> Hi，Alissa Cooper
>
> Thanks for your review and comments.
>
> The new version(version 10)  has updated to fix your comments.
>
> The format of Smart-MAC APP sub-TLV and the text  has been changed to the
> following:
>
> The length of F,M,RSV,VLAN/FGL data Label is 4 bytes. and the length of
> VLAN/FGL Data Label field is 24 bits.
>
>
>+-+-+-+-+-+-+-+-+
> |Type=Smart-MAC |  (1 byte)
> +-+-+-+-+-+-+-+-+
> |   Length  |  (1 byte)
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |F|M|RSV|  VLAN/FGL Data Label  |  (4 bytes)
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |  MAC (1)   (6 bytes) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |  .   |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |  MAC (N)   (6 bytes) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  Figure 3 Smart-MAC APPsub-TLV
>
>
>o  VLAN/FGL Data Label: 24bits.  If F is 1, this field is a 24-bit
>   FGL Data Label for all subsequent MAC addresses in this APPsub-
>   TLV.  Otherwise, if F is 0, the lower 12 bits is the VLAN of all
>   subsequent MAC addresses in this APPsub-TLV, and the upper 12 bits
>   is not used(sent as zero and ignored on receipt).  If there is no
>   VLAN/FGL data label specified, the VLAN/FGL Data Label is zero.
>
>
>
>
> Regards.
>
> Fangwei.
>
> 原始邮件
> 发件人：AlissaCooper 
> 收件人：The IESG 
> 抄送人：draft-ietf-trill-smart-endno...@ietf.org
> trill-cha...@ietf.org
> sha...@ndzh.com trill@ietf.org
> 
> 日 期 ：2018年03月07日 04:45
> 主 题 ：Alissa Cooper's Discuss on draft-ietf-trill-smart-endnodes-10:
> (withDISCUSS and COMMENT)
> Alissa Cooper has entered the following ballot position for
> draft-ietf-trill-smart-endnodes-10: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/
>
>
>
> --
> DISCUSS:
> --
>
> This should hopefully be easy to fix and was pointed out by the Gen-ART
> reviewer:
>
> All of section 4.3 is confusing as to what the length of the TLV really
is.
> Row 3 in the diagram says 2 bytes or 4 bytes, but the number of bits
called
> out
> in bullets 4 and 5 below it don't seem to add up to those things. Maybe it
> would
> be better to draw a diagram with F=0 and a separate diagram with F=1.
>
> Please make it clear both in the diagram and in the text what the expected
> lengths of the fields are -- I find it particularly confusing that the
> number
> of bits pictured doesn't align with 

Re: [trill] Alissa Cooper's Discuss on draft-ietf-trill-vendor-channel-00: (with DISCUSS and COMMENT)

[Donald Eastlake]

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


On Wed, Mar 7, 2018 at 10:23 AM, Alissa Cooper <ali...@cooperw.in> wrote:
>
> On Mar 6, 2018, at 11:11 PM, Donald Eastlake <d3e...@gmail.com> wrote:
>
> Hi Alissa,
>
> On Tue, Mar 6, 2018 at 3:28 PM, Alissa Cooper <ali...@cooperw.in> wrote:
>
> Alissa Cooper has entered the following ballot position for
> draft-ietf-trill-vendor-channel-00: Discuss
>
> ...
>
> --
> DISCUSS:
> --
>
> I'm having trouble understanding what function this specification serves
> given
> that the RBridge Channel Protocol registry has a range reserved already for
> private use and that the document doesn't specify any requirements around
> vendor-specific protocol semantics. So any implementation of this that needs
> to
> interoperate with another implementation will need to do so according to
> some
> specification generated by the vendor, and that specification can select a
> code
> point from the private use range. What does allocating a single code point
> for
> all such vendor-specific protocols achieve, aside from specifying a
> structured
> way of conveying the OUI/CID (which seems superfluous anyway for multiple
> implementations from a single vendor interoperating with each other)?
>
>
> What if two TRILL campuses using the same private code point for
> incompatible purposes are accidentally interconnected?
>
> What if someone wants to use TRILL switches from two different vendors
> each of which uses the same private code point for incompatible
> purposes? Say one vendor makes highly flexible/desirable edge TRILL
> switches while the other make particularly cost effective core TRILL
> switches or particularly nifty Level 1 / Level 2 border TRILL
> switches, or whatever.
>
> "private" code points seem pretty flakey compared with the more robust
> mechanism in this draft.
>
> Maybe this document should also depredate the use of private code points.
>
>
> Right, both of those examples make it sound like the purpose of having this
> document specify a code point is because the existing private use range is
> problematic. Your first example seems to directly contradict the guidance in
> RFC 7178 about the use of the private range, so if that is a real concern
> and it outweighs the utility of having the private range for private network
> use, then it seems like deprecation of the private range might make sense.
>
> The second example I see is the compelling use case for this. I will clear.
>
> Thanks,
> Alissa
>
>
> --
> COMMENT:
> --
>
> I agree with the Gen-ART reviewer that the text in the Acknowledgements
> section
> is not appropriate. See RFC 7322.
>
>
> OK.
>
> Thanks,
> Donald
> ===
> Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> d3e...@gmail.com
>
>

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Kathleen Moriarty's No Objection on draft-ietf-trill-vendor-channel-00: (with COMMENT)

[Donald Eastlake]

Hi Kathleen,

On Wed, Mar 7, 2018 at 10:57 AM, Kathleen Moriarty
 wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-trill-vendor-channel-00: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> Could you please expand the text in the security considerations section as to
> why security properties (integrity, authentication, and encryption since they
> are not part of RBridge Channel messages except when explicitly added on in 
> the
> extension draft) were not built in?  I'm assuming it is the limited scope of
> use for the protocol.  I am glad that options exist to add it in, but wish the
> text were a bit more encouraging so that would actually happen.  Vendors need
> to be motivated to provide these options for customers who may want to use
> them, without that motivation, the features won't be provided.

OK.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Alissa Cooper's Discuss on draft-ietf-trill-vendor-channel-00: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi Alissa,

On Tue, Mar 6, 2018 at 3:28 PM, Alissa Cooper  wrote:
> Alissa Cooper has entered the following ballot position for
> draft-ietf-trill-vendor-channel-00: Discuss
>
> ...
>
> --
> DISCUSS:
> --
>
> I'm having trouble understanding what function this specification serves given
> that the RBridge Channel Protocol registry has a range reserved already for
> private use and that the document doesn't specify any requirements around
> vendor-specific protocol semantics. So any implementation of this that needs 
> to
> interoperate with another implementation will need to do so according to some
> specification generated by the vendor, and that specification can select a 
> code
> point from the private use range. What does allocating a single code point for
> all such vendor-specific protocols achieve, aside from specifying a structured
> way of conveying the OUI/CID (which seems superfluous anyway for multiple
> implementations from a single vendor interoperating with each other)?

What if two TRILL campuses using the same private code point for
incompatible purposes are accidentally interconnected?

What if someone wants to use TRILL switches from two different vendors
each of which uses the same private code point for incompatible
purposes? Say one vendor makes highly flexible/desirable edge TRILL
switches while the other make particularly cost effective core TRILL
switches or particularly nifty Level 1 / Level 2 border TRILL
switches, or whatever.

"private" code points seem pretty flakey compared with the more robust
mechanism in this draft.

Maybe this document should also depredate the use of private code points.

> --
> COMMENT:
> --
>
> I agree with the Gen-ART reviewer that the text in the Acknowledgements 
> section
> is not appropriate. See RFC 7322.

OK.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-directory-assisted-encap-10: (with DISCUSS)

[Donald Eastlake]

Hi Alvaro,

On Mon, Mar 5, 2018 at 2:32 PM, Alvaro Retana  wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-directory-assisted-encap-10: Discuss
>
> ...
>
> --
> DISCUSS:
> --
>
> I have significant concerns about this document; as currently written, I
> believe the technology is underspecified and can cause significant damage to a
> DC network where it might be deployed.  I am then balloting a DISCUSS.
>
> The document (including the security considerations) is written assuming that
> the TRILL-ENs can be trusted (and are not compromised), and that the directory
> information is accurate.  However, I believe there are several cases that have
> been overlooked.
>
> (1) There aren't any basic safeguards specified to at least make sure that a
> TRILL-EN is doing the right thing (or something sensible).  For example, what
> if the Ingress RBridge Nickname field in the TRILL header doesn't correspond 
> to
> the first rBridge at the domain boundary?  Should that frame be accepted?

This concern doesn't seem very different from the general insecurity of Layer 2.

If a link has no TRILL router adjacencies, then I guess it it
reasonable to check that the ingress nickname is that of the receiving
RBridge but it gets harder if you have a mixed link with both end
stations and TRILL routers (probably rare in deployments but, on the
other hand, in TRILL a "link" can be a bridged LAN...).

> (2) rfc8171 talks about issues with incorrect directory mappings.  Consider 
> the
> case where a TRILL-EN uses (on purpose!) an incorrect mapping.  That "can
> result in data being delivered to the wrong end stations, or set of end
> stations in the case of multi-destination packets, violating security policy."
> [rfc8171]  How can this risk be mitigated?

I'm not sure how using "an incorrect mapping" is that different from
just using whatever nicknames it feels like...

> I don't think that there are easy mitigations for these issues, but at least
> mentioning them so that operators are aware of the risk would be enough to
> clear this DISCUSS.

It is certainly reasonable to mention these. One possible mitigation
is the use of end-to-end encryption.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Kathleen Moriarty's No Objection on draft-ietf-trill-directory-assisted-encap-09: (with COMMENT)

[Donald Eastlake]

Hi Kathleen,

Thanks for you comment, which seems like a reasonable suggestion. We have
uploaded a -10 with that change and also a typo fix.

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

On Sat, Mar 3, 2018 at 3:05 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-trill-directory-assisted-encap-09: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-trill-
> directory-assisted-encap/
>
>
>
> --
> COMMENT:
> --
>
> Thanks for your work on this document.  I'd like to see stronger language
> used
> in the security considerations section.  I'll propose edits for you to
> consider:
>
> OLD:
> Therefore, there could be a potential security risk
>when the TRILL-ENs are not trusted.  In addition, if the path between
>the directory and the TRILL-ENs are attacked, false mappings can be
>sent to the TRILL-EN causing packets from the TRILL-EN to be sent to
>wrong destinations, possibly violating security policy. Therefore, a
>combination of authentication and encryption should be used between
>the Directory and TRILL-EN. The entities involved will need to
>properly authenticate with each other to protect sensitive
>information.
>
> NEW:
>Therefore, there could be a potential security risk
>when the TRILL-ENs are not trusted or are compromised.  In addition, if
> the
>path between the directory and the TRILL-ENs are attacked, false
> mappings
>can be sent to the TRILL-EN causing packets from the TRILL-EN to be
> sent to
>wrong destinations, possibly violating security policy. Therefore, a
>combination of authentication and encryption is RECOMMENDED between the
>Directory and TRILL-EN. The entities involved will need to properly
>authenticate with each other, provide session encryption, maintain
> security
>patch levels, and configure their systems to allow minimal access and
>running processes to protect sensitive information.
>
>
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Adam Roach's Discuss on draft-ietf-trill-ecn-support-05: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi Adam,

The just posted revision -07 is believed to resolve your comments.

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

On Fri, Feb 23, 2018 at 6:57 PM, Bob Briscoe <i...@bobbriscoe.net> wrote:

> @Adam, Thx for your patience. (It turned out I didn't see your DISCUSS cos
> I had created a bug in my own e-mail filters - sry for that).
>
> @Donald (as editor), Adam's right that we risk implementers doing their
> own thing if they judge that Table 3 might be wrong, because its apparent
> illogicality is not explained without reading the references. So, I've
> suggested one further change to text, inline...
>
>
>
> On 20/02/18 22:22, Adam Roach wrote:
>
> Bob --
>
> Thanks for taking the time to explain the history and rationale of Table 3
> to me. I'm going to clear my DISCUSS based on this explanation, since it
> seems that the technical solution in the document is correct, if a bit
> non-obvious. Some additional comments inline.
>
> [For those of you who did not see Bob's response: it appears that my
> original DISCUSS email did not reach him,  so he replied to a reduced
> audience. I have restored the traditional IESG review distribution to this
> email. For this reason, I am eliding less of Bob's response than I usually
> would]
>
> On 2/20/18 12:51 PM, Bob Briscoe wrote:
>
>
>
>>> On Thu, Feb 8, 2018 at 2:15 PM, Adam Roach <a...@nostrum.com> wrote:
>>>
>>>> On 2/8/18 11:53 AM, Donald Eastlake wrote:
>>>>
>>>> Hi Adam,
>>>>
>>>> On Wed, Feb 7, 2018 at 8:12 PM, Adam Roach <a...@nostrum.com> wrote:
>>>> > Adam Roach has entered the following ballot position for
>>>> > draft-ietf-trill-ecn-support-05: Discuss
>>>> >
>>>> > ...
>>>> >
>>>> > 
>>>> --
>>>> > DISCUSS:
>>>> > 
>>>> --
>>>> >
>>>> > Thanks to the authors, chairs, shepherd, and working group for the
>>>> effort that
>>>> > has been put into this document.
>>>> >
>>>> > I have concerns about some ambiguity and/or self-contradiction in this
>>>> > specification, but I suspect these should be easy to fix. In
>>>> particular, the
>>>> > behavior defined in Table 3 doesn't seem to be consistent with the
>>>> behavior
>>>> > described in the prose.
>>>> >
>>>> > For easy reference, I've copied Table 3 here:
>>>> >
>>>> >>   +-+--+
>>>> >>   | Inner   |  Arriving TRILL 3-bit ECN Codepoint Name |
>>>> >>   | Native  +-+++--+
>>>> >>   | Header  | Not-ECT | ECT(0) | ECT(1) | CE   |
>>>> >>   +-+-+++--+
>>>> >>   | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) ||
>>>> >>   |  ECT(0) |  ECT(0) |  ECT(0)|  ECT(1)| CE   |
>>>> >>   |  ECT(1) |  ECT(1) |  ECT(1)(*) |  ECT(1)| CE   |
>>>> >>   |CE   |  CE |  CE|  CE(*) | CE   |
>>>> >>   +-+-+++--+
>>>> >>
>>>> >>  Table 3. Egress ECN Behavior
>>>> >>
>>>> >>  An asterisk in the above table indicates a currently unused
>>>> >>  combination that SHOULD be logged. In contrast to [RFC6040], in
>>>> TRILL
>>>> >>  the drop condition is the result of a valid combination of events
>>>> and
>>>> >>  need not be logged.
>>>> >
>>>> > The prose in this document indicates:
>>>> >
>>>> >  1. Ingress gateway either copies the native header value to the
>>>> TRILL ECN
>>>> > codepoint (resulting in any of the four values above) or doesn't
>>>> insert
>>>> > any ECN information in the TRILL header.
>>>> >
>>>> >  2. Intermediate gateways can set the CCE flag, resulting in "CE" in
>>>> the
>>>> > table above.
>>>> >
>>>

Re: [trill] TRILL meeting at IETF London meeting

[Donald Eastlake]

Hi,

The TRILL WG meeting at the upcoming IETF meeting in London, although still
subject to possible change, has been confirmed for 17:40 to 18:80 Monday
afternoon 19 March.

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

On Sun, Feb 18, 2018 at 6:38 PM, Donald Eastlake <d3e...@gmail.com> wrote:

> Hi,
>
> The TRILL WG meeting at the upcoming IETF meeting in London has been
> tentatively scheduled for 17:40 to 18:80 Monday afternoon 19 March.
>
> If you would like to present at this meeting, send mail to the TRILL
> WG mailing list or to trill-cha...@ietf.org.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] AD review of draft-ietf-trill-over-ip-14

[Donald Eastlake]

Hi Alia,

The just posted version -15 attempts to resolve your comments.

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

On Tue, Feb 20, 2018 at 8:39 PM, Alia Atlas <akat...@gmail.com> wrote:

> Hi Donald,
>
> On Tue, Feb 20, 2018 at 8:30 PM, Donald Eastlake <d3e...@gmail.com> wrote:
>
>> Hi Alia,
>>
>> On Tue, Feb 20, 2018 at 6:55 PM, Alia Atlas <akat...@gmail.com> wrote:
>>
>>> As is traditional, I have done my AD review of
>>> draft-ietf-trill-over-ip-14. First I would like to thank the authors -
>>> Donald, Margaret, Mingui, and Dacheng, as well as the reviewers for their
>>> work on this document.
>>>
>>> I did find one minor issue (below) and would recommend a spell-checker
>>> to catch several minor typos.  I will send this to IETF Last Call and place
>>> it on the IESG telechat on March 8.
>>>
>>> Minor:
>>>
>>> 1) In Sec 5.2: " An adjacency can be formed between two TRILL over IP
>>> transport ports if the intersection of the sets of encapsulation methods
>>> they support is not null. If that intersection is null, then no adjacency
>>> is formed."
>>> Given that Sec 5.0 says that the native encapsulation MUST be supported,
>>> how can the set be null?  Is this the set of encapsulation methods other
>>> than the native encapsulation?  Please clarify.
>>>
>>
>> Unless the port is configured to use some other encapsulation X for all
>> types of traffic, then a port has to "support" UDP for the low bandwidth of
>> Hellos and other adjacency establishment PDUs. This is different from
>> advertising support for UDP which means a willingness to use it for data
>> traffic and LSPs. This needs to be clarified. Maybe "limited support"
>> versus "full support".
>>
>
> Thanks, that would work.  The draft currently doesn't indicate limited
> support and the previous paragraph indicates that signaling nothing assumes
> "native encapsulation".
>
> Regards,
> Alia
>
> Thanks,
>> Donald
>> ===
>>  Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-2270> (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>> <https://maps.google.com/?q=155+Beaver+Street,+Milford,+MA+01757+USA=gmail=g>
>>  d3e...@gmail.com
>>
>>
>>> Regards,
>>> Alia
>>>
>>
>>
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Fwd: IPR Declaration for draft-ietf-trill-multilevel-unique-nickname

[Donald Eastlake]

Forwarding to the WG list for the record.

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

-- Forwarded message --
From: li...@gsta.com 
Date: Tue, Feb 20, 2018 at 10:14 PM
Subject: Re: Dongxin: You need to post an IPR Declaration for
draft-ietf-trill-multilevel-unique-nickname
To: d3e3e3 
Cc: trill-chairs , zhangmingui <
zhangmin...@huawei.com>


Hi,
   I don't know any IPR that has not been declared for this draft.

Thanks,
Dongxin
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] AD review of draft-ietf-trill-over-ip-14

[Donald Eastlake]

Hi Alia,

On Tue, Feb 20, 2018 at 6:55 PM, Alia Atlas  wrote:

> As is traditional, I have done my AD review of
> draft-ietf-trill-over-ip-14. First I would like to thank the authors -
> Donald, Margaret, Mingui, and Dacheng, as well as the reviewers for their
> work on this document.
>
> I did find one minor issue (below) and would recommend a spell-checker to
> catch several minor typos.  I will send this to IETF Last Call and place it
> on the IESG telechat on March 8.
>
> Minor:
>
> 1) In Sec 5.2: " An adjacency can be formed between two TRILL over IP
> transport ports if the intersection of the sets of encapsulation methods
> they support is not null. If that intersection is null, then no adjacency
> is formed."
> Given that Sec 5.0 says that the native encapsulation MUST be supported,
> how can the set be null?  Is this the set of encapsulation methods other
> than the native encapsulation?  Please clarify.
>

Unless the port is configured to use some other encapsulation X for all
types of traffic, then a port has to "support" UDP for the low bandwidth of
Hellos and other adjacency establishment PDUs. This is different from
advertising support for UDP which means a willingness to use it for data
traffic and LSPs. This needs to be clarified. Maybe "limited support"
versus "full support".

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


> Regards,
> Alia
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] draft-ietf-trill-parent-selection-02 - WG LC (2/2 to 2/16)

[Donald Eastlake]

I support this draft. I think documentation of the considerations covered
by this draft will be useful for TRILL.

Thanks,
Donald

On Fri, Feb 2, 2018 at 12:00 Susan Hares  wrote:

> This begins a 2 week WG LC on  draft-ietf-trill-parent-selection-02.txt
> (2/2 to 2/16)  which you can find at:
>
> https://datatracker.ietf.org/doc/draft-ietf-trill-parent-selection/
>
>
>
> In your comments, please consider:
>
> 1)   will the documentation of this problem and its solution benefit
> operation of TRILL networks?
>
> 2)   Is this document ready for publication?
>
>
>
> As a chair who is concerned about the operational aspects of TRILL, I
> encourage you to read and review this TRILL document.
>
>
>
> Sue Hares
>
-- 
Sent from Gmail Mobile
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Call for IPR Declarations on draft-ietf-trill-multilevel-unique-nicknme

[Donald Eastlake]

I don't know of any IPR in this draft.

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

On Fri, Feb 16, 2018 at 3:54 PM, Donald Eastlake <d3e...@gmail.com> wrote:

> Hi,
>
> The authors of draft-ietf-trill-multilevel-unique-nickname need to post
> an IPR declaration for this draft.
>
> Thanks,
> Donald (TRILL WG Secretary)
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-2270> (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com
>
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] TRILL meeting at IETF London meeting

[Donald Eastlake]

Hi,

The TRILL WG meeting at the upcoming IETF meeting in London has been
tentatively scheduled for 17:40 to 18:80 Monday afternoon 19 March.

If you would like to present at this meeting, send mail to the TRILL
WG mailing list or to trill-cha...@ietf.org.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Call for IPR Declarations on draft-ietf-trill-multilevel-single-nickname

[Donald Eastlake]

I don't know of any IPR in this draft.

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


On Fri, Feb 16, 2018 at 3:53 PM, Donald Eastlake <d3e...@gmail.com> wrote:
> Hi,
>
> The authors of draft-ietf-trill-multilevel-single-nickname need to post an
> IPR declaration for this draft.
>
> Thanks,
> Donald (TRILL WG Secretary)
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Call for IPR Declarations on draft-ietf-trill-vendor-channel

[Donald Eastlake]

I don't know of any IPR in this draft.

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


On Fri, Feb 16, 2018 at 4:19 PM, Donald Eastlake <d3e...@gmail.com> wrote:
> Hi,
>
> The authors of draft-ietf-trill-vendor-channel need to post an IPR
> declaration for this draft.
>
> Thanks,
> Donald (Secretary, TRILL WG)
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Call for IPR Declarations on draft-ietf-trill-vendor-channel

[Donald Eastlake]

Hi,

The authors of draft-ietf-trill-vendor-channel need to post an IPR
declaration for this draft.

Thanks,
Donald (Secretary, TRILL WG)
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Call for IPR Declarations on draft-ietf-trill-multilevel-unique-nicknme

[Donald Eastlake]

Hi,

The authors of draft-ietf-trill-multilevel-unique-nickname need to post an
IPR declaration for this draft.

Thanks,
Donald (TRILL WG Secretary)
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Call for IPR Declarations on draft-ietf-trill-multilevel-single-nickname

[Donald Eastlake]

Hi,

The authors of draft-ietf-trill-multilevel-single-nickname need to post an
IPR declaration for this draft.

Thanks,
Donald (TRILL WG Secretary)
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Fwd: Call for IPR declarations on draft-ietf-trill-transport-over-mpls

[Donald Eastlake]

This didn't seem to make it into the TRILL mailing list. Forwarding
for the record.

Thanks,
Donald
-- Forwarded message --
From:  <lucyy...@gmail.com>
Date: Thu, Feb 15, 2018 at 12:34 AM
Subject: Re: Call for IPR declarations on draft-ietf-trill-transport-over-mpls
To: Mohammed Umair <mohammed.uma...@gmail.com>
Cc: Donald Eastlake <d3e...@gmail.com>, trill@ietf.org,
trill-cha...@ietf.org, draft-ietf-trill-transport-over-m...@ietf.org


I am not aware of any IPR for this draft.
Lucy

Sent from my iPhone

> On Feb 14, 2018, at 11:32 PM, Mohammed Umair <mohammed.uma...@gmail.com> 
> wrote:
>
> I am not aware of any IPR for this draft.

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10

[Donald Eastlake]

Hi Magnus,

Could you look at the -13 version which is intended to resolve your
remaining unresolved comments?

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

On Fri, Feb 2, 2018 at 4:29 AM, Magnus Westerlund <
magnus.westerl...@ericsson.com> wrote:

> Hi Donald,
>
> I have reviewed the changes and my comments. Please see inline for my
> feedback. I will remove text not necessary to provide context. It is almost
> ready now. There are two areas where I think there needs to be some further
> improvements, DSCPs and TCP encapsulation. But the needed changes are
> relatively straightforward.
>
> Den 2018-01-31 kl. 06:25, skrev Donald Eastlake:
>
> Hi Magnus,
>
> It has been a while but the just posted version -12 is intended to
> resolve your comments except those related to middle boxes. (The TRILL
> WG has decided middle boxes will be out of scope for this draft.)
>
>
>
> On Thu, Jun 29, 2017 at 10:17 PM, Donald Eastlake <d3e...@gmail.com> 
> <d3e...@gmail.com> wrote:
>
> On Tue, Jun 27, 2017 at 1:13 PM, Magnus 
> Westerlund<magnus.westerl...@ericsson.com> <magnus.westerl...@ericsson.com> 
> wrote:
>
> Den 2017-06-26 kl. 02:07, skrev Donald Eastlake:
>
> On Thu, Jun 15, 2017 at 1:32 PM, Magnus 
> Westerlund<magnus.westerl...@ericsson.com> <magnus.westerl...@ericsson.com> 
> wrote:
>
>
> Diffserv usage
> --
>
> Section 4.3:
>
>
> The new text from -12:
>
>The default TRILL priority and DEI to DSCP mapping, which may be
>configured per TRILL over IP port, is an follows. Note that the DEI
>value does not affect the default mapping and, to provide a
>potentially lower priority service than the default priority 0,
>priority 1 is considered lower priority than 0. So the priority
>sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7, as
>it is in [802.1Q].
>
>   TRILL Priority  DEI  DSCP Field (Binary/decimal)
>   --  ---  -
>   0   0/1  001000 / 8
>   1   0/1  10 / 0
>   2   0/1  01 / 16
>   3   0/1  011000 / 24
>   4   0/1  10 / 32
>   5   0/1  101000 / 40
>   6   0/1  11 / 48
>   7   0/1  111000 / 56
>
>The above all follow the recommended DSCP values from [RFC2474]
>except for the placing of priority 1 below priority 0, as specified
>in [802.1Q], and for the DSCP value of 10 binary for low effort
>as recommended in [LEphb].
>
>
> I don't really understand this change. Now you have priority 1 which
> points to the proposed new mapping for Lower than Best Effort, being the
> least prioritized. Then priority 0 intended to be more prioritized is CS1
> which may still be lower than best effort (thus basically same as prio 1),
> or end up being receiving a more prioritized PHB than best effort. Why
> isn't 0 mapped to best effort (00)? That appears that it would provide
> a more consistent behaviour.
>
>
>
>
>
> MTU and Fragmentation
> -
>
>
> With the changes introduced and the no middlebox applicability it looks
> like the issues are resolved.
>
>
> Zero Checksum:
> --
>
>
> The IPv6 zero checksum section (5.4.2) looks good.
>
> TCP Encapsulation issue
> ---
>
>
>
> So the TCP encapsulation section (5.6) is significantly improved, but some
> comments:
>
>
> "All packets in a particular TCP stream SHOULD use the same DSCP
> codepoint or packet re-ordering may occur."
>
>
>
>
>
>
> I think that SHOULD is a MUST. You get no benefit from trying to send
> different packets in a TCP connection with different DSCPs. It will really
> only result in reordering, and additional retransmissions. Also the TCP
> stacks Head of line blocking will also not really allow any received
> payload to be released early. Thus, only downsides and now gain to use
> different DSCPs for a single connection.
>
> "It is RECOMMEDED that
>at least two TCP connections be provided, for example one for
>priority 6 and 7 traffic and one for priority 0 through 5 taffice, in
>order to insure that urgent control traffic, including control
>traffic related to establishing and maintaining adjacency, is not
>significantly delayed by lower priority traffic."
>
> I think this is fine, there is one potential issue here, but likely not a
> significant. If the high priority traffic is ver

Re: [trill] WG Last Call for draft-ietf-trill-over-ip-13 (14-Feb to 20-Feb)

[Donald Eastlake]

Hi Joe,

On Wed, Feb 14, 2018 at 10:39 PM, Joe Touch <to...@strayalpha.com> wrote:
>
> I’ve already expressed my views on this document.
>
> The changes have not addressed the points I have raised.

Many of your earlier points have been incorporated. I believe a
response to your most recent points will be posted shortly.

> Given its current state, I would appreciate if the authors would remove my 
> name from the list of acknowledgments. I do not want to be associated with 
> its content in any way in its current form if (gasp) it becomes an RFC.

You will not be listed in the acknowledgements unless you send further
instructions.

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

> Joe
>
> > On Feb 14, 2018, at 6:42 PM, Donald Eastlake <d3e...@gmail.com> wrote:
> >
> > On behalf of the TRILL WG co-chairs, this starts a one week 2nd WG
> > Last Call on draft-ietf-trill-over-ip. This draft previously passed WG
> > LC and the transport related changes since then have all appeared on
> > the WG mailing list.
> >
> > Thanks,
> > Donald (TRILL WG Secretary)
> > ===
> > Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> > 155 Beaver Street, Milford, MA 01757 USA
> > d3e...@gmail.com
> >
> > ___
> > trill mailing list
> > trill@ietf.org
> > https://www.ietf.org/mailman/listinfo/trill
>

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Call for IPR declarations on draft-ietf-trill-transport-over-mpls

[Donald Eastlake]

I am not aware of any IPR on this draft.

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

On Thu, Feb 15, 2018 at 12:34 AM,  wrote:

> I am not aware of any IPR for this draft.
> Lucy
>
> Sent from my iPhone
>
> > On Feb 14, 2018, at 11:32 PM, Mohammed Umair 
> wrote:
> >
> > I am not aware of any IPR for this draft.
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Call for IPR declarations on draft-ietf-trill-transport-over-mpls

[Donald Eastlake]

Hi,

The authors of draft-ietf-trill-transport-over-mpls need to post an
IPR declaration for this draft.

Thanks,
Donald (TRILL WG Secretary)
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] WG Last Call for draft-ietf-trill-over-ip-13 (14-Feb to 20-Feb)

[Donald Eastlake]

On behalf of the TRILL WG co-chairs, this starts a one week 2nd WG
Last Call on draft-ietf-trill-over-ip. This draft previously passed WG
LC and the transport related changes since then have all appeared on
the WG mailing list.

Thanks,
Donald (TRILL WG Secretary)
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Opsdir last call review of draft-ietf-trill-ecn-support-05

[Donald Eastlake]

Hi Sarah,

My apologies for my intemperate language below and anything you found
offensive.

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

On Mon, Feb 5, 2018 at 11:27 PM, Donald Eastlake <d3e...@gmail.com> wrote:

> Hi,
>
> On Mon, Feb 5, 2018 at 1:22 PM, Sarah Banks <sba...@encrypted.net> wrote:
> > Reviewer: Sarah Banks
> > Review result: Has Nits
> >
> > I have reviewed this document as part of the Operational directorate's
> ongoing
> > effort to review all IETF documents being processed by the IESG.  These
> > comments were written with the intent of improving the operational
> aspects of
> > the IETF drafts. Comments that are not addressed in last call may be
> included
> > in AD reviews during the IESG review.  Document editors and WG chairs
> should
> > treat these comments just like any other last call comments.
> >
> > Status: Ready with Nits
> >
> > Overall, I think this is a well written document, that could flow better
> with
> > minor revisions.
>
> Perhaps.
>
> > The Abstract and the Introduction include the exact same
> > information;
>
> The Introduction is much more detailed.
>
> > I think the document would benefit from having more information in
> > the Introduction section, something that expands upon the current text,
> or
> > discusses the use case, and why I care.
>
> I do not agree that the current introduction section needs any
> expansion on the topics it already covers. I do not agree that a "use
> case" is needed to justify specifying how to add a well know
> congestion control building block, already deployed in other contexts,
> to a general routing protocol. Not knowing anything about your
> background, I have no idea why you should care.
>
> > From time to time I find myself
> > wanting to red line the text, for missing words (like "the") - a style
> > preference perhaps, but flowing english sentences make a document read
> easier.
>
> As far as I know the English sentences flow fine. Both I and my
> co-author are native English speakers. However, as with any document
> of significant length, there are probably some cases that read about
> as well with or without an article or the like. And it is certainly
> possible there are a tiny number of cases where the flow is rough. If
> you had bothered to send a list of the changes you want, I would
> probable have made all or almost all of them -- in cases where it is
> about as good either way, I usually find it easier not to argue with a
> reviewer. But I decline to run in circles trying to guess what you
> don't like.
>
> > A lack of discussion on ECT (1) and ECT (0) (Table 1) made this reader
> stop and
> > google; a bit of conversation here would have been helpful.
>
> I am not sure why you went to Google rather look at the ECN RFC 3168
> referenced right there in the draft. In any case, the question is how
> deep an explanation of the intricacies of ECN marking needs to appear
> in a specification of how to support ECN in a particular protocol. I
> don't think discussion of ECT(0) and ECT(1) is needed in this
> document. However, it would probably be useful to make the referenced
> to [RFC3168] more specific by pointing specifically at Section 20
> ("The Motivation for the ECT Codepoints") of [RFC3168].
>
> > Last, NITS is
> > mostly clean, but not entirely. I applaud the call out to ongoing work,
> and
> > Appendix A, but a minor tweak to the doc from Nits output before you
> send this
> > into the queue would be helpful.
>
> The automated Nits checker reports zero errors, its most serious
> problem indication, zero flaws, the next most serious, and zero
> warnings, its least serious problem indication. True, it does report
> one "comment", however, this comment from the Nits checker is
> erroneous. Nits checker comments are called comments because they can
> often be wrong. There is no real code in the draft that might need to
> be extracted and compiled, just one instance of psuedo-code. I think
> adding the nits suggested markers for extractable real code to the
> psudo-code in this document would just be confusing.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com
>
> > Thanks
> > Sarah
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Spencer Dawkins' Yes on draft-ietf-trill-ecn-support-05: (with COMMENT)

[Donald Eastlake]

Hi Spencer,

On Wed, Feb 7, 2018 at 3:32 PM, Spencer Dawkins
 wrote:
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-trill-ecn-support-05: Yes
>
> ...
>
> --
> COMMENT:
> --
>
> I agree with Mirja about the status of L4S, but would go even farther - L4S is
> only one of the ECN experiments that https://datatracker.ietf.org/doc/rfc8311/
> was intended to accommodate, so you might want to capture that in the appendix
> (basically saying "L4S is one example of the ways TRILL ECN handling may
> evolve", or something like that).

OK.

> Is
>
>   If an RBridge supports ECN, for the two cases of an IP and a non-IPR
>inner packet, the egress behavior is as follows:
>
> really "non-IPR"? I'm guessing it should be "non-IP".

Yeah, probably not good to make last minutes changes in a draft while
you are on vacation for a few days :-)

> s/significnat/significant/

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-address-flush-05: (with COMMENT)

[Donald Eastlake]

Hi Alvaro,

On Wed, Feb 7, 2018 at 12:28 PM, Alvaro Retana  wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-address-flush-05: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> I have some non-blocking comments/questions:
>
> (1) Why are the 2 VLAN Block encodings needed?  More important, when should
> each be used?  Section 2.2 says that "All RBridges implementing the Address
> Flush RBridge Channel message MUST implement types 1 and 2, the VLAN 
> types...",
> but I didn't see anything about the VLAN Block Only Case (2.1).  I'm wondering
> if there will be cases where the support won't match and the message will then
> be ineffective.

I suppose some wording could be added but the idea is that the VLAN
Block Only Case is part of the basic message and always has to be
implemented, as opposed to the extensible list of TLV types. The
message is structured so that you can't use both the VLAN Block Only
Case and the extensible TLV structure to specify VLANs at the same
time. The VLAN Block Only Case is expected to be common and
corresponds more closely to deployed code.

> (2) In the 2.2.* sections, the description of some of the TLVs says (when the
> Length is incorrect) that "...the Address Flush message MUST be discarded if
> the receiving RBridge implements Type x".  What if that type is not supported
> -- I would assume you still want to discard?  BTW, the Type 5 description
> doesn't qualify dropping based on the type support.

If the Type is not implemented, then how would you know that the
length is not valid? How would you currently code a length validity
check for types to be specified in the future as part of the
extensibility of the message? But, since there is a length field, you
can always skip over a TLV you don't understand. The qualification
based on type support should be there for Type 5 also. (Of course, in
the real world, I think inconsistent Address Flush message type
support in a TRILL campus will be very rare.)

> (2a) Other descriptions (type 1,2,6) just talk about ignoring (not 
> discarding).
>  Is there an intended difference in the behavior?

There is no intended difference between "ignoring" and "discarding" an
Address Flush message. (Types 1, 2, and 6 are the mandatory to support
types so there is no conditional on support.)

> (3) Section 2 says that "Address Flush protocol messages are usually sent as
> multi-destination packets...Such messages SHOULD be sent at priority 6".  It 
> is
> not clear to me whether unicast packets (mentioned later) should also have the
> same priority.

Yes, probably throwing in "including unicast Address Flush messages"
would clarify.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Tsvart last call review of draft-ietf-trill-ecn-support-04

[Donald Eastlake]

Hi Michael,

I've fixed these nits and posted a -05 version.

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


On Sun, Feb 4, 2018 at 9:44 PM, Donald Eastlake <d3e...@gmail.com> wrote:
> Hi Michael,
>
> Thanks for the comments, see below.
>
> On Sun, Feb 4, 2018 at 1:54 PM, Michael Tüxen <tue...@fh-muenster.de> wrote:
>> Reviewer: Michael Tüxen
>> Review result: Ready with Nits
>>
>> I've reviewed this document as part of the transport area directorate's 
>> ongoing
>> effort to review key IETF documents. These comments were written primarily 
>> for
>> the transport area directors, but are copied to the document's authors for
>> their information and to allow them to address any issues raised.
>> When done at the time of IETF Last Call, the authors should consider this
>> review together with any other last-call comments they receive.
>> Please always CC tsv-...@ietf.org if you reply to or forward this review.
>>
>> This draft is basically ready for publication, but has nits that should be 
>> fixed before publication.
>>
>> Nits:
>>
>> Section 1:
>>
>> Old text:
>> This can improve network efficiency through better flow
>> control without packet drops.
>>
>> New text:
>> This can improve network efficiency through better congestion
>> control without packet drops.
>
> OK.
>
>> Old text:
>> This specification provides for any ECN marking in the traffic at the
>> ingress to be copied into the TRILL Extension Header Flags Word.
>>
>> New Text:
>> This specification specifies for any ECN marking in the traffic at the
>> ingress to be copied into the TRILL Extension Header Flags Word.
>
> Well, it specifies how to copy the ECN marking for any traffic and it
> mandates that it be copied from IP traffic but it doesn't and can't
> mandate that it be copied from all arbitrary protocols that might have
> ECN marking...  Also, I don't like "... specification specifies ..."
>
> How about:
> "This document specifies how ECN marking in traffic at the ingress is
> copied into the TRILL Extension Header Flags Word and requires such
> copying for IP traffic."
>
>> Section 2:
>>
>> Old text:
>> after the Extesnion Flags Word.
>>
>> New text:
>> after the Extension Flags Word
>
> OK.
>
>> Section 3.3
>>
>> Please define "3-bit ECN codepoint" and refer to Table 3 BEFORE using it.
>> This might result in swapping Table 2 and Table 3.
>
> We'll look into doing that.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Shepherd's report on draft-ietf-trill-ecn-support-04

[Donald Eastlake]

Hi Bob,

All your changes look good to me.

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


On Sat, Feb 3, 2018 at 8:31 PM, Bob Briscoe  wrote:
> Sue,
>
> Thanks for the editorial suggestions.
> Donald, I'm happy with Sue's specific suggestions if you are.
>
> Responses inline...
>
> On 22/01/18 15:18, Susan Hares wrote:
>
> As part of the shepherd’s duties, I’ve review
> draft-ietf-trill-ecn-support-04.txt to determine if it is ready for
> publication.
>
>
>
> Status: Ready with editorial nits
>
>
>
> General comment:  I’m thrilled to see an RBridge specification enacting aids
> for advanced congestion control mechanisms.
>
> What I’ve checked: normative references including
> draft-ietf-twvwg-enc-encap-guidelines-01/txt
>
> BTW, it's currently -09, not -01.
>
> I suggest the following changes to each occurrence of a citation of
> [ECNencapGuide]:
>
> 1. Introduction
>  general>
>
> 3. ECN Support
>
> CURRENT:
>
>... which correspond to the recommended provisions of
>[ECNencapGuide].
>
>
> SUGGESTED:
>
>... which correspond to the recommended provisions in section 3 and
> sections 5.1-5.4 of
>[ECNencapGuide].
>
>
> 3.1. Ingress ECN Support
>
> CURRENT:
>
>   ... it MUST follow the guidelines in [ECNencapGuide]
>   to add a Flags Word to the TRILL Header.
>
>
> SUGGESTED:
>
>   ... it MUST follow the guidelines in Section 5.3 of [ECNencapGuide]
>   to add a Flags Word to the TRILL Header.
>
>
> 3.3 Egress ECN Support
>
> CURRENT:
>
>Drop is the intended behavior for such a packet, as required by
>[ECNencapGuide].
>
>
> SUGGESTED:
>
>Drop is the intended behavior for such a packet, as required by Section
> 5.4 of
>[ECNencapGuide].
>
>
> CURRENT:
>
>o  When decapsulating a non-IP protocol frame with a means of
>   indicating ECN that is understood by the RBridge, it MUST follow
>   the guideines in [ECNencapGuide] when setting the ECN information
>   in the decapsulated native frame.
>
>
> SUGGESTED:
>
>o  When decapsulating a non-IP protocol frame with a means of
>   indicating ECN that is understood by the RBridge, it MUST follow
>   the guideines in Section 5.4 of [ECNencapGuide] when setting the ECN
> information
>   in the decapsulated native frame.
>
>
>
>
>
> Editorial nits are below.  You can adopt or ignore the editorial nits.
>
>
>
> Sue Hares
>
> ===
>
>
>
> Editorial nits:
>
>
>
> General – it may be helpful to specify section in the [ECNencapGuide] –
> document, and RFC7567.  While the way you specify it is correct, it may help
> the reader to narrow down the scope within the document.
>
>
>
> #1
>
>Explicit congestion notification (ECN [RFC3168]) allows a forwarding
>
>element, such as a router, to notify downstream devices, including
>
>the destination, of the onset of congestion without having to drop
>
>packets.
>
>
>
> The multiple commons in this sentence do not lend to easy reading of the
> initial sentence.
>
> One alternative is:
>
>
>
>Explicit congestion notification (ECN [RFC3168]) allows a forwarding
>
>Element (such as a router) to notify downstream devices, including
>
>the destination, of the onset of congestion without having to drop
>
>packets.
>
>
>
> However you may wish to revise the sentence in an alternative way.
>
>
>
>
>
> #2 – Section 2. Paragraph 2. Sentences 4
>
> Old/Extesnion Flags Word./
>
> New/Extension Flags Word./
>
>
>
>
>
> #3 – Section 3.3 is dense and thoughtful text.  I am not sure you can
> improve it, but it too me several reads to make sure I understood it
> correctly.
>
>
>
> I think it might help if we created two subsections within 3.3 for:
> 3.3.1: "Non-ECN Egress RBridge" the first para
> 3.3.2: "ECN Egress RBridge" for the rest of the section
>
> Also, it might make it clearer if the two bullets were explicitly flagged as
> mutually exclusive alternatives:
>
> CURRENT:
>
>If an RBridge supports ECN, the egress behavior is as follows:
>
> SUGGESTED:
>
>If an RBridge supports ECN, for the two cases of an IP and a non-IP inner
> packet,
>the egress behavior is as follows:
>
>
> Then, instead of the two bullet symbols, perhaps use hanging indented
> headers:
>
>Decapsulating an inner IP packet: The RBridge sets the ECN
>   ...
>Decapsulating a non-IP protocol frame: If the frame has a means of
>   indicating ECN that is understood by the RBridge, the RBridge MUST
> follow
>   ...
>
>
>
> Other suggested edits to make the going easier:
>
> CURRENT:
>
>  In the case where the TRILL 3-bit ECN codepoint indicates
>   congestion experienced (CE) but the encapsulated native IP frame
>   indicates a not ECN-capable transport (Not-ECT), the RBridge MUST
>   drop the packet.
>
>
> SUGGESTED:
>
>  In the case where the TRILL 3-bit ECN codepoint indicates

Re: [trill] Tsvart last call review of draft-ietf-trill-ecn-support-04

[Donald Eastlake]

Hi Michael,

Thanks for the comments, see below.

On Sun, Feb 4, 2018 at 1:54 PM, Michael Tüxen  wrote:
> Reviewer: Michael Tüxen
> Review result: Ready with Nits
>
> I've reviewed this document as part of the transport area directorate's 
> ongoing
> effort to review key IETF documents. These comments were written primarily for
> the transport area directors, but are copied to the document's authors for
> their information and to allow them to address any issues raised.
> When done at the time of IETF Last Call, the authors should consider this
> review together with any other last-call comments they receive.
> Please always CC tsv-...@ietf.org if you reply to or forward this review.
>
> This draft is basically ready for publication, but has nits that should be 
> fixed before publication.
>
> Nits:
>
> Section 1:
>
> Old text:
> This can improve network efficiency through better flow
> control without packet drops.
>
> New text:
> This can improve network efficiency through better congestion
> control without packet drops.

OK.

> Old text:
> This specification provides for any ECN marking in the traffic at the
> ingress to be copied into the TRILL Extension Header Flags Word.
>
> New Text:
> This specification specifies for any ECN marking in the traffic at the
> ingress to be copied into the TRILL Extension Header Flags Word.

Well, it specifies how to copy the ECN marking for any traffic and it
mandates that it be copied from IP traffic but it doesn't and can't
mandate that it be copied from all arbitrary protocols that might have
ECN marking...  Also, I don't like "... specification specifies ..."

How about:
"This document specifies how ECN marking in traffic at the ingress is
copied into the TRILL Extension Header Flags Word and requires such
copying for IP traffic."

> Section 2:
>
> Old text:
> after the Extesnion Flags Word.
>
> New text:
> after the Extension Flags Word

OK.

> Section 3.3
>
> Please define "3-bit ECN codepoint" and refer to Table 3 BEFORE using it.
> This might result in swapping Table 2 and Table 3.

We'll look into doing that.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10

[Donald Eastlake]

Hi Magnus,

Thanks for the quick response.

On Fri, Feb 2, 2018 at 4:29 AM, Magnus Westerlund <
magnus.westerl...@ericsson.com> wrote:

> Hi Donald,
>
> I have reviewed the changes and my comments. Please see inline for my
> feedback. I will remove text not necessary to provide context. It is almost
> ready now. There are two areas where I think there needs to be some further
> improvements, DSCPs and TCP encapsulation. But the needed changes are
> relatively straightforward.
>
> Den 2018-01-31 kl. 06:25, skrev Donald Eastlake:
>
> Hi Magnus,
>
> It has been a while but the just posted version -12 is intended to
> resolve your comments except those related to middle boxes. (The TRILL
> WG has decided middle boxes will be out of scope for this draft.)
>
>
>
> On Thu, Jun 29, 2017 at 10:17 PM, Donald Eastlake <d3e...@gmail.com> 
> <d3e...@gmail.com> wrote:
>
> On Tue, Jun 27, 2017 at 1:13 PM, Magnus 
> Westerlund<magnus.westerl...@ericsson.com> <magnus.westerl...@ericsson.com> 
> wrote:
>
> Den 2017-06-26 kl. 02:07, skrev Donald Eastlake:
>
> On Thu, Jun 15, 2017 at 1:32 PM, Magnus 
> Westerlund<magnus.westerl...@ericsson.com> <magnus.westerl...@ericsson.com> 
> wrote:
>
>
> Diffserv usage
> --
>
> Section 4.3:
>
>
> The new text from -12:
>
>The default TRILL priority and DEI to DSCP mapping, which may be
>configured per TRILL over IP port, is an follows. Note that the DEI
>value does not affect the default mapping and, to provide a
>potentially lower priority service than the default priority 0,
>priority 1 is considered lower priority than 0. So the priority
>sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7, as
>it is in [802.1Q].
>
>   TRILL Priority  DEI  DSCP Field (Binary/decimal)
>   --  ---  -
>   0   0/1  001000 / 8
>   1   0/1  10 / 0
>   2   0/1  01 / 16
>   3   0/1  011000 / 24
>   4   0/1  10 / 32
>   5   0/1  101000 / 40
>   6   0/1  11 / 48
>   7   0/1  111000 / 56
>
>The above all follow the recommended DSCP values from [RFC2474]
>except for the placing of priority 1 below priority 0, as specified
>in [802.1Q], and for the DSCP value of 10 binary for low effort
>as recommended in [LEphb].
>
>
> I don't really understand this change. Now you have priority 1 which
> points to the proposed new mapping for Lower than Best Effort, being the
> least prioritized. Then priority 0 intended to be more prioritized is CS1
> which may still be lower than best effort (thus basically same as prio 1),
> or end up being receiving a more prioritized PHB than best effort. Why
> isn't 0 mapped to best effort (00)? That appears that it would provide
> a more consistent behaviour.
>

I think that in updating this section there was too much focus on updating
the DSCP value for low effort and not as much focus on the rest. We'll see
what we can do to straighten this out.

> MTU and Fragmentation
> -
>
>
> With the changes introduced and the no middlebox applicability it looks
> like the issues are resolved.
>

Thanks

> Zero Checksum:
> --
>
>
> The IPv6 zero checksum section (5.4.2) looks good.
>

Thanks

> TCP Encapsulation issue
> ---
>
> So the TCP encapsulation section (5.6) is significantly improved, but some
> comments:
>
>
> "All packets in a particular TCP stream SHOULD use the same DSCP
> codepoint or packet re-ordering may occur."
>
>
>
>
>
>
> I think that SHOULD is a MUST. You get no benefit from trying to send
> different packets in a TCP connection with different DSCPs. It will really
> only result in reordering, and additional retransmissions. Also the TCP
> stacks Head of line blocking will also not really allow any received
> payload to be released early. Thus, only downsides and now gain to use
> different DSCPs for a single connection.
>
> "It is RECOMMEDED that
>at least two TCP connections be provided, for example one for
>priority 6 and 7 traffic and one for priority 0 through 5 taffice, in
>order to insure that urgent control traffic, including control
>traffic related to establishing and maintaining adjacency, is not
>significantly delayed by lower priority traffic."
>
> I think this is fine, there is one potential issue here, but likely not a
> significant. If the high priority traffic is very sparse, then the TCP
> connection marked with 

Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10

[Donald Eastlake]

Hi Magnus,

It has been a while but the just posted version -12 is intended to
resolve your comments except those related to middle boxes. (The TRILL
WG has decided middle boxes will be out of scope for this draft.)

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


On Thu, Jun 29, 2017 at 10:17 PM, Donald Eastlake <d3e...@gmail.com> wrote:
> HI Magnus,
>
> On Tue, Jun 27, 2017 at 1:13 PM, Magnus Westerlund
> <magnus.westerl...@ericsson.com> wrote:
>>
>> Hi Donald,
>>
>> After having read your response I think there is an important question
>> about the applicability of this document that affects several of the issues
>> below and what solution you need. That is the question of what type of paths
>> one expect to get Trill over IP working over. Because if the target is
>> general Internet and also through middleboxes such as NATs and Firewall (Not
>> intending to block) then there are a lot more work to ensure this. If you
>> for example changes the applicability to require any on path middleboxes to
>> fulfill certain requirements things can be more easily addressed.
>
>
> The use cases in the document support communication over the general
> Internet in the brach office case but that does not necessarily imply
> NATs/Firewalls.
>
>> Den 2017-06-26 kl. 02:07, skrev Donald Eastlake:
>>
>> Hi Magnus,
>>
>> Thanks for the extensive review. See my responses below.
>>
>> On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund
>> <magnus.westerl...@ericsson.com> wrote:
>>
>>
>> Diffserv usage
>> --
>>
>> Section 4.3:
>>
>>TRILL over IP implementations MUST support setting the DSCP value in
>>the outer IP Header of TRILL packets they send by mapping the TRILL
>>priority and DEI to the DSCP. They MAY support, for a TRILL Data
>>packet where the native frame payload is an IP packet, mapping the
>>DSCP in this inner IP packet to the outer IP Header with the default
>>for that mapping being to copy the DSCP without change.
>>
>> I think it is fine to require that implementations are capable  of setting
>> DSCP values on the outer IP header. However, I fail to see any discussion
>> of
>> the potential issues with actually setting the DSCP values. It is one
>> thing to
>> do this in an IP back bone use case where one can know and have control
>> over
>> the PHB that the DSCP values maps to. But otherwise, over general internet
>> the
>> behavior is not that predictable. One can easily be subject to policers or
>> remapping. Also as the actual DSCP code point usage is domain specific
>> this is
>> difficult. Priority reversal is likely the least of the problems that this
>> can
>> run into over general Internet.
>>
>> It sounds like appropriate discussion and warnings about these issues
>> would resolve the above comment.
>>
>> I would note that the choice of encapsulation here do becomes important.
>> Your's and Joe Touch's observation that for TCP, you can only have a single
>> DSCP marking per TCP connection for example. For others, see the discussion
>> in Section 5.1 of https://datatracker.ietf.org/doc/rfc7657/ on this issue.
>
>
> Well, if a TRILL over IP implementation using TCP transport wants to have
> more than one priority category for traffic where there might be one or more
> intervening IP routers, which would be the normal case, it would just need a
> TCP connection per priority category. Mapping the 8 priority levels into a
> smaller number of categories is a routine thing to do. Note that the base
> TRILL protocol specification (RFC 6325) says:
>
>RBridges are not required to implement any
>particular number of distinct priority levels but may treat one or
>
>more adjacent priority levels in the same fashion.
>
>>
>> David Black also raised an important question if one should treat this as
>> a tunnel with a single predictable behavior or let the inner networks
>> marking show through. Establishing a tunnel with a single PHB has less risk
>> of running into issues than multiple different markings.
>
>
> It is an implementation choice whether to have a single PHB or eight, one
> per priority level, or something in between.
>>
>> Section 4.3:
>>
>>The default TRILL priority and DEI to DSCP mapping, which may be
>>configured per TRILL over IP port, is an follows. Note that the DEI
>>value does not affect the default mapping and, to prov

Re: [trill] Genart last call review of draft-ietf-trill-address-flush-05

[Donald Eastlake]

HI Robert,

On Fri, Jan 26, 2018 at 3:29 PM, Robert Sparks  wrote:

> Reviewer: Robert Sparks
> Review result: Ready
>
> 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
>
> .
>
> Document: draft-ietf-trill-address-flush-05
> Reviewer: Robert Sparks
> Review Date: 2018-01-26
> IETF LC End Date: 2018-02-05
> IESG Telechat date: 2018-02-08
>
> Summary: Ready for publication as a proposed standard
>
> micro-nit: Expand FGL on its first use in the introduction.
>

Thanks for the review. I've added an expansion of FGL to the Introduction
to the master sources so the next time a revision is uploaded, this will be
fixed.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Working group LC on draft-ietf-trill-multi-topology-04 (9/27-10/11) - Consensus has been reached

[Donald Eastlake]

I am not aware of any IPR relevant to this draft.

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


On Mon, Jan 22, 2018 at 10:44 PM, Zhangmingui (Martin)
<zhangmin...@huawei.com> wrote:
> I am not aware of any IPR relevant to this document.
>
>
>
> Thanks
>
> Mingui
>
>
>
> From: Susan Hares [mailto:sha...@ndzh.com]
> Sent: Tuesday, January 23, 2018 2:23 AM
> To: trill@ietf.org
> Cc: trill-cha...@ietf.org; 'Donald Eastlake'; Zhangmingui (Martin);
> ayaba...@cisco.com; 'Alia Atlas'
> Subject: RE: [trill] Working group LC on draft-ietf-trill-multi-topology-04
> (9/27-10/11) - Consensus has been reached
>
>
>
> It appears our absent minded chair did not close the
> draft-ietf-trill-multi-topology-04.txt WG LC that occurred from 9/27 to
> 11/11/2017.
>
>
>
> The working group has reached consensus on this draft.  The chair also
> forgot to call for IPR on this draft.
>
> Donald, Minqui, and Ayan – will you respond this message with your IPR
> Statement.
>
>
>
> I will forward the draft to the AD once I have received your IPR statements.
>
>
>
> Cheerily, Sue Hares

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] I-D Action: draft-ietf-trill-transport-over-mpls-07.txt

[Donald Eastlake]

This revision is intended to resolve the comments from Andy Malis and myself.

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

On Fri, Jan 19, 2018 at 7:11 PM,  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transparent Interconnection of Lots of Links 
> WG of the IETF.
>
> Title   : TRILL Transparent Transport over MPLS
> Authors : Mohammed Umair
>   Kingston Smiler Selvaraj
>   Donald E. Eastlake 3rd
>   Lucy Yong
> Filename: draft-ietf-trill-transport-over-mpls-07.txt
> Pages   : 19
> Date: 2018-01-19
>
> Abstract:
>This document specifies methods to interconnect multiple Transparent
>Interconnection of Lots of links (TRILL) sites with an intervening
>MPLS network using existing TRILL and VPLS standards. This draft
>addresses two problems as follows:
>
>1) Providing connection between more than two TRILL sites that are
>   separated by an MPLS provider network.
>
>2) Providing a single logical virtualized TRILL network for different
>   tenants that are separated by an MPLS provider network.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-trill-transport-over-mpls/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-trill-transport-over-mpls-07
> https://datatracker.ietf.org/doc/html/draft-ietf-trill-transport-over-mpls-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-transport-over-mpls-07
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] [RTG-DIR] RtgDir review: draft-ietf-trill-directory-assisted-encap-02

[Donald Eastlake]

Hi Ben,

On Thu, Jan 18, 2018 at 2:40 PM, Ben Niven-Jenkins <b...@niven-jenkins.co.uk>
wrote:

> Hi Donald,
>
> -08 addresses all my comments, thanks. BTW 1 more editorial nit introduced
> in -08, in the new paragraph in the security considerations you have
> misspelt encapsulation.
>

Thanks. The nit you found encouraged me to actually do a spell check :-)
and I found
   snown -> shown
   ecapsulation -> encapsulation

So these are fixed in -09.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-2270> (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


> Regards
> Ben
>
> On 17 Jan 2018, at 23:23, Donald Eastlake <d3e...@gmail.com> wrote:
>
> Hi Ben,
>
> Thanks for the further review and comments. See below.
>
> Version -08 has been uploaded with the goal of resolving these comments.
>
> On Wed, Jan 17, 2018 at 8:48 AM, Ben Niven-Jenkins
> <b...@niven-jenkins.co.uk> wrote:
>
>
> Hi Donald,
>
> Apologies for not responding sooner, I have reviewed the latest version
> (-07) and still have a couple of comments, see inline below. I have also
> included at the bottom of this email some additional editorial nits I found
> when reading -07. I have trimmed previous comment and responses from you
> that are now covered in the document.
>
> On 10 Jan 2018, at 20:05, Donald Eastlake <d3e...@gmail.com> wrote:
>
> ...
>
> On Thu, Oct 26, 2017 at 10:29 PM, Donald Eastlake <d3e...@gmail.com>
> wrote:
>
>
> Hi Ben,
>
> Thanks for your review. It appears that is was not responded to in a
> timely fashion. Apologies on behalf of the authors.
>
> (Your review was of the -02 version. The current version is -05.)
>
> On Sun, Apr 24, 2016 at 4:28 AM, Ben Niven-Jenkins
> <b...@niven-jenkins.co.uk> wrote:
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review. The purpose of the review is to provide assistance to the
> Routing ADs. For more information about the Routing Directorate,
> please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing
> ADs, it would be helpful if you could consider them along with any
> other IETF Last Call comments that you receive, and strive to
> resolve them through discussion or by updating the draft.
>
>
> Document: draft-ietf-trill-directory-assisted-encap-02.txt
> Reviewer: Ben Niven-Jenkins
> Review Date: 21 April 2016
> Intended Status: Proposed Standard
>
> Summary:
> I have significant concerns about this document and recommend that
> the Routing ADs discuss these issues further with the authors.
>
>
> Hopefully the changes made between the version -02 you reviewed and
> the current -05 have made some improvements and, based on your
> comments and WG LC comments, further improvements can be made.
>
>
>
> I think the -07 is almost good to go, the only outstanding concern I have
> is with regards to the security considerations section, see below.
>
>
> Thanks.
>
> Comments:
> Overall this is not the easiest document to read although some of
> that might be due to my lack of background in TRILL and its
> terminology.
>
> Major Issues:
>
> 1) The document has an Intended Status of Proposed Standard, however
> it does not contain any RFC2119 keywords and does not seem to make
> any normative statements about required behaviour which I would have
> expected in a Proposed Standard.
>
>
> Well, in version -05 there is at least one keyword instance.
> Furthermore, I don't know that such keywords need to always be used
> when an implementation requirement level is being specified. That
> said, we could see if additional RFC 2119 keywords are warranted.
>
>
> I noted this as a flag to the ADs because the lack of RFC2119 key words
> seemed unusual to me. If the ADs are happy for this to be proposed standard
> then I am happy with it being a proposed standard.
>
>
> OK.
>
> 2) Section 4: If I understand correctly the TRILL-EN spoofs the
> Ingress RBridge edge node's nickname in the source address field of
> the TRILL header. Is this likely to introduce problems? E.g. if
> RBridges will accept & forward frames that have their own source
> address in, does it perpetuate routing loops or present security
> considerations that the document should discuss?
>
>
> TRILL goes to great lengths to avoid loops and has a hop count in the
> TRILL header so that, should there be a transient loo

Re: [trill] RtgDir review: draft-ietf-trill-directory-assisted-encap-02

[Donald Eastlake]

Hi Ben,

Thanks for the further review and comments. See below.

Version -08 has been uploaded with the goal of resolving these comments.

On Wed, Jan 17, 2018 at 8:48 AM, Ben Niven-Jenkins
<b...@niven-jenkins.co.uk> wrote:
>
> Hi Donald,
>
> Apologies for not responding sooner, I have reviewed the latest version (-07) 
> and still have a couple of comments, see inline below. I have also included 
> at the bottom of this email some additional editorial nits I found when 
> reading -07. I have trimmed previous comment and responses from you that are 
> now covered in the document.
>
> On 10 Jan 2018, at 20:05, Donald Eastlake <d3e...@gmail.com> wrote:
>
> ...
>
> On Thu, Oct 26, 2017 at 10:29 PM, Donald Eastlake <d3e...@gmail.com> wrote:
>>
>> Hi Ben,
>>
>> Thanks for your review. It appears that is was not responded to in a
>> timely fashion. Apologies on behalf of the authors.
>>
>> (Your review was of the -02 version. The current version is -05.)
>>
>> On Sun, Apr 24, 2016 at 4:28 AM, Ben Niven-Jenkins
>> <b...@niven-jenkins.co.uk> wrote:
>> > Hello,
>> >
>> > I have been selected as the Routing Directorate reviewer for this
>> > draft. The Routing Directorate seeks to review all routing or
>> > routing-related drafts as they pass through IETF last call and IESG
>> > review. The purpose of the review is to provide assistance to the
>> > Routing ADs. For more information about the Routing Directorate,
>> > please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>> >
>> > Although these comments are primarily for the use of the Routing
>> > ADs, it would be helpful if you could consider them along with any
>> > other IETF Last Call comments that you receive, and strive to
>> > resolve them through discussion or by updating the draft.
>> >
>> >
>> > Document: draft-ietf-trill-directory-assisted-encap-02.txt
>> > Reviewer: Ben Niven-Jenkins
>> > Review Date: 21 April 2016
>> > Intended Status: Proposed Standard
>> >
>> > Summary:
>> > I have significant concerns about this document and recommend that
>> > the Routing ADs discuss these issues further with the authors.
>>
>> Hopefully the changes made between the version -02 you reviewed and
>> the current -05 have made some improvements and, based on your
>> comments and WG LC comments, further improvements can be made.
>
>
> I think the -07 is almost good to go, the only outstanding concern I have is 
> with regards to the security considerations section, see below.

Thanks.

>> > Comments:
>> > Overall this is not the easiest document to read although some of
>> > that might be due to my lack of background in TRILL and its
>> > terminology.
>> >
>> > Major Issues:
>> >
>> > 1) The document has an Intended Status of Proposed Standard, however
>> > it does not contain any RFC2119 keywords and does not seem to make
>> > any normative statements about required behaviour which I would have
>> > expected in a Proposed Standard.
>>
>> Well, in version -05 there is at least one keyword instance.
>> Furthermore, I don't know that such keywords need to always be used
>> when an implementation requirement level is being specified. That
>> said, we could see if additional RFC 2119 keywords are warranted.
>
> I noted this as a flag to the ADs because the lack of RFC2119 key words 
> seemed unusual to me. If the ADs are happy for this to be proposed standard 
> then I am happy with it being a proposed standard.

OK.

>> > 2) Section 4: If I understand correctly the TRILL-EN spoofs the
>> > Ingress RBridge edge node's nickname in the source address field of
>> > the TRILL header. Is this likely to introduce problems? E.g. if
>> > RBridges will accept & forward frames that have their own source
>> > address in, does it perpetuate routing loops or present security
>> > considerations that the document should discuss?
>>
>> TRILL goes to great lengths to avoid loops and has a hop count in the
>> TRILL header so that, should there be a transient loop, a TRILL packet
>> in that loop (i.e., an encapsulated frame) will be discarded. In the
>> potentially more dangerous case of multi-destination packets, as
>> compared with known unicast, where copies could multiply due to forks
>> in the distribution tree, a Reverse Path Forwarding Check is used to
>> discard packets that appear to be on the wrong link or when there is
>> disagreement about the distribution 

[trill] Comments on draft-ietf-trill-transport-over-mpls-06

[Donald Eastlake]

Hi,

There are a bunch of RFCs referenced in this draft but not listed in the
References section. They need to be added to the References.

I think the Security Considerations section, while it provides a good set
of references, needs one added sentence: something about how the document
does not change the security considerations because it uses existing
standards without change.

Section 5 is very short and seems like it could be moved up and merged with
the Introduction. (The section number of the following sections would be
reduced by one.)

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] AD review of draft-ietf-trill-resilient-trees-08

[Donald Eastlake]

Hi,

I've reviewed this draft in light of Alia's comments and have comments as
follows:

   - It should be clearer that each primary distribution tree may have at
   most one back-up tree associated with it. This is controlled by the highest
   priority root bridge RBridge which specified the roots of the back-up trees.
   - Behavior of an RBridge RB2 for multi-destination frames ingressed at
   RB1 depends on the protection mode of operation of RB1, particularly the
   difference between 1:1 and 1+1. Thus, either every RBridge in the campus
   must be configured with information about the mode of protection being used
   by every other RBridge (or at least every ingress RBridge) or RBridges must
   signal what mode they are using. It seems much more in keeping with TRILLs
   philosophy to use signaling which could, for example, be accomplished by
   use a 2-bit field in the Extended Capabilities which would be zero if no
   protection is supported and various non-zero values for various protection
   modes.
   - I think the method given in the draft for calculating a back-up tree
   is reasonable and will provide substantial protection although it does not
   guarantee that the primary and backup trees are maximally disjoint and
   should not claim that.
   - Due to the TRILL RPF check, local protection seems limited to RBridges
   where the primary and backup trees fork.

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

On Mon, Dec 18, 2017 at 4:23 PM, Alia Atlas  wrote:

> As is customary, I have done my AD review of draft-ietf-trill-resilient-
> trees-08.
> First, I would like to thank the authors Mingui, Tissa, Janardhanan, Ayan,
> and Anoop
> for their work on this document.
>
> Unfortunately, I have several serious concerns about this document.
>
> First, and most importantly, there is not a clear and mandatory algorithm
> for computing the backup distribution trees that is given. Sec 3.2.1.1
> provides a recommendation that is still not fully specified.
> I do see the idea that the root of a backup distribution tree need not be
> the same as the root of the primary distribution tree - but I see no
> indication of what decides which the root is.  Perhaps it is the root of
> the primary distribution tree?What is computing the backup distribution
> trees?  My assumption is that each RBridge does.  Can  a backup
> distribution tree be associated with only one primary distribution tree?
>
> Second, I don't believe that the suggested algorithm of raising the link
> costs for links used in a primary distribution tree will work to find
> maximally disparate paths.  Consider the simpler case with Suurballe's
> algorithm  (https://en.wikipedia.org/wiki/Suurballe's_algorithm) that is
> just looking for 2 disparate paths.   In that example, the shortest path is
> A-B-D-F which gives no disjoint path between A and F - but different pairs
> of paths are possible.
>
> Obviously MRT (RFC7811) solves this issue - and it is possible to have
> different roots for the RED and BLUE trees by simply creating a proxy node
> that attaches to the potential roots.  There may be a bit of work to be
> done - but it is similar to other proxy nodes used in RFC7811 and RFC7812.
>
> You may have different solutions - and that is fine - but failing to fully
> specify an algorithm and having what is specified not work is not ok.
>
> Third, pulling back and clearly explaining the different pieces of this
> technology is badly needed.  For instance:
> (a) The root for a multicast distribution tree computes a backup
> distribution tree and identifies the root to use.
> (b) A PLR determines the backup distribution tree (how?)
> (c) Each RBridge computes its part of the backup distribution tree -
> by pinning specific links into the backup distribution tree as advertised
> as affinity links (??)
> (d) Is traffic looked for on the backup distribution tree?  How does a
> merge point/receiver make that decision?
>
> Some of these details are in the draft - but it is quite hard to pull out
> clearly.
>
> Are there any implementations of this draft?
>
> Regards,
> Alia
>
>
>
>
>
> ___
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] WG adoption call for draft-eastlake-trill-vendor-channel-03.txt

[Donald Eastlake]

Hi Ramkumar,

Thanks for the support suggestion below. A -04 version has been uploaded
incorporating your suggestion. See
https://tools.ietf.org/html/draft-eastlake-trill-vendor-channel-04

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

On Sun, Jan 14, 2018 at 3:42 AM, R Parameswaran 
wrote:

>
> Hi,
>
>
> I support the adoption of this draft, please see inline:
>
>
> TRILL WG:
>
>
>
> This is a WG adoption call for draft-eastlake-trill-vendor-channel-03.txt
> (11/15 to 11/29).
>
>
>
> In this WG Adoption call please consider,
>
>
>
> 1)  Is this vendor specific message channel useful to deployments?
>
>
> [RP]: Yes, the draft provides a framework for potentially useful extensions, 
> allows vendor specific features, feature prototyping etc..
>
> 2)  Is this mechanism ready for standardization?  The TRILL WG group
> must move rapidly from adoption of this draft to WG LC in December?
>
>
> [RP]: Yes in my opinion - I had one suggestion on the body of the text - it 
> may be useful to add a sentence in Section 3.1 that the flags in the Channel 
> Header and the semantics of the SL bit are defined in RFC 7178, may help 
> readers put this draft in context.
>
> 3)  Do you know of any IPR related to this draft?
>
>
> [RP]: Not aware of any IPR relating to this draft.
>
>
> thanks,
>
>
> Ramkumar
>
>
>
> Susan Hares
>
>
>
> ___
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-centralized-replication-12: (with COMMENT)

[Donald Eastlake]

Hi Eric,

Thanks for your comments.

On Mon, Jan 8, 2018 at 9:13 AM, Eric Rescorla  wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-trill-centralized-replication-12: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
>
>if a triple of {ingress nickname, tree, receiving RBridge port} is
>allowed. (The tree is indicted by the nickname of its root which is
>stored in the TRILL Header "egress nickname" field.) When
> I think this probably should be "indicated"

Thanks, that was fixed in the -12 version.

> 7. Centralized replication forwarding process
> This diagram would be helpful earlier
>
>
>
>  *   --*-*--^
>  * | ^
>   LAALP1 *  LAALP2 |  ^
> What are the asterisks?

The asterisks are intended to show the connection of CE1 to RB1, RB2, and RB3.

>equals (m mod k) as egress nickname for BUM traffic unicast TRILL
>encapsulation.
> This text might be easier to read as:
>
> "For data label ID m, choose R-nickname = m mod k"
>
> The "equals" isn't that helpful here, but if you wanted to say it that way, 
> you might try
> "choose the R-nickname n which is equal to m (mod k)"

Well, its not the R-nickname=m mod K but rather that, as stated in
point 1 immediately above the point 2 we are talking about, m mod k
give the number of the R-nickname in the ordered and numbered list.

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

> o C = If C flag is one, it indicates that the TRILL traffic
>with this nickname as an ingress nickname that requires the special
> Nit: I would use ":" here instead of equals

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Adam Roach's No Objection on draft-ietf-trill-centralized-replication-12: (with COMMENT)

[Donald Eastlake]

Hi Adam,

On Wed, Jan 10, 2018 at 4:27 PM, Adam Roach  wrote:
>
> Adam Roach has entered the following ballot position for
> draft-ietf-trill-centralized-replication-12: No Objection
>
>...
>
> --
> COMMENT:
> --
>
> TRILL is pretty far outside my area of expertise, so I might be simply
> misunderstanding the protocol extension model here, but it seems to me that 
> the
> changes to the RPF port calculation represent a formal update to RFC6325. If
> so, the metadata and abstract should indicate that.

That's an interesting point which no one else has raised. I'm not sure
that "the changes to the RPF port calculation represent a formal
update to RFC6325". The RPF calculation is still done in generally the
same way based on the point where the packets are injected into the
distribution tree -- it's just that with centralized replication it is
injected at a tree root rather than an edge node. However, the
unicasting of multi-destination TRILL data frames from an edge node
where they were ingressed to the tree root from which they will be
distributed does appear to clearly and directly contradict RFC6325 so
I guess this draft does update RFC 6325...

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-centralized-replication-11: (with COMMENT)

[Donald Eastlake]

Hi Spencer,

On Mon, Jan 1, 2018 at 3:46 PM, Spencer Dawkins at IETF
<spencerdawkins.i...@gmail.com> wrote:
>
> Hi, Donald,
>
> On Fri, Dec 29, 2017 at 7:39 PM, Donald Eastlake <d3e...@gmail.com> wrote:
>>
>> Hi Spencer,
>>
>> On Wed, Dec 27, 2017 at 11:24 AM, Spencer Dawkins
>> <spencerdawkins.i...@gmail.com> wrote:
>> > Spencer Dawkins has entered the following ballot position for
>> > draft-ietf-trill-centralized-replication-11: No Objection
>> >
>> >...
>> >
>> > --
>> > COMMENT:
>> > --
>> >
>> > No TSV concerns from me, but I was interested in the MUST/SHOULD mismatch 
>> > that
>> > Joseph Salowey mentioned in his review of -10. I didn't see a change about 
>> > that
>> > in -11.
>>
>> It looks like there were two cases of a "SHOULD" that needed to be
>> changed to a "MUST", one in the Abstract and one near the end of
>> Section 1, the Introduction. Should (must?) be easy to fix.
>
>
> :-)
>
> I wouldn't have mentioned this, except that I saw Joseph's review was on -10 
> and the change hadn't been made in -11. I know it's easy to miss comments 
> late in the year!

Fixed in version -12.

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

> Spencer
>
>>
>>
>> > I'm assuming the right thing will happen after the holidays, so no Discuss 
>> > :-)
>> > ...
>>
>> Thanks,
>> Donald
>> ===
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  d3e...@gmail.com
>
>

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-centralized-replication-11: (with COMMENT)

[Donald Eastlake]

Hi Alvaro,

Thanks for the comments, see below.

On Fri, Jan 5, 2018 at 12:17 AM, Alvaro Retana 
wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-centralized-replication-11: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> I have some non-blocking comments.  I would like to see the ones related
to
> Normative Language addressed before publication.
>
> - From the Abstract: "RPF checks on each RBridge MUST be calculated as if
the
> centralized node was the ingress RBridge..."  Using Normative Language in
the
> Abstract seems strange to me, specially since the same language is not
used
> later in the text.  The document does get to the same point later, but
not with
> the same language.
>
> - The Introduction says that "...a centralized node, which SHOULD be a
> distribution tree root", but Section 3 says otherwise: "The centralized
node
> MUST be a distribution tree root."  Suggestion: use Normative Language in
just
> one place.  IMO, the Introduction may not be the right place for it.

Well, the inconsistency, which was also noted by another reviewer, seemed
like a problem. When the SHOULDs were being changed to MUSTs the one in
Section 1 was missed. A -12 version of the draft has been uploaded with
that SHOULD changed to MUST to be consistent with the rest of the draft.

> - BTW, what is a "distribution tree root"?  The definition is probably
> intuitive since we're talking about replication, but explicitly defining
it
> would clear any possible confusion.

TRILL uses distribution trees for multi-destination packets. These trees
are grown from a root RBridge and a tree is identified by a TRILL nickname
held by the root RBridge. I suppose an entry could be added to the
terminology list in Section 2 of this draft pointing to Section 4.5
(Distribution Trees) of RFC 6325, the base TRILL protocol specification.

> - I appreciate the background and the description of the problem and the
> mechanism, but there's a lot of repetition.  Section 3 presents for the
third
> time an overview of the mechanism -- Abstract, Introduction, and Section
> 3...note that even the last paragraph repeats information about the
replication
> from this same section.

I think major deletions of text at this stage is not a good idea...

> - Section 9: "An edge group using CMT [RFC7783] MUST NOT set the
C-nickname
> flag on the pseudo-nickname it is using. This is already mandatory
behavior..."
> If "already mandatory" then there's no need to use Normative Language
here,
> right?

The sentence beginning "This is already mandatory behavior..." should
probably be deleted. It's based on the theory that RBridges using CMT would
"not know about" centralized replication which is a peculiar assumption.

> - Section 11.1 ("R" and "C" Flag in the Nickname Flags APPsub-TLV):  I'm
not
> sure if I understand correctly, but because there's a distinction between
the
> R-nickname and the C-nickname, both bits should not be set at the same
time,
> right?  What happens if they are?  It seems that the last paragraph tries
to
> address that question ("due to errors")...but I'm then not sure what the
action
> is: "it is RECOMMENDED that the nickname be treated as if the R / C flag
was
> set if any Nickname Flags APPsub-TLV for that nickname has the R / C flag
set."
> Again, what if both are set?  And "RECOMMENDED" implies that there are
reasons
> not to do it this way...what are those cases?

My belief is as follows:

   - The R-nickname flag indicates a nickname for a distribution tree root
   RBridge using centralized replication and the C-nickname flag indicates a
   nickname for an edge RBridge using centralized replication. (An RBridge can
   actually hold multiple nicknames...)
   - Setting the R-nickname flag on a nickname held by a non-root RBridge
   has no effect because the R-nickname flag will be ignored. Setting the
   R-nickname flag for a distribution tree root RBridge that doesn't actually
   implement centralized replication might attract multi-destination data from
   the edge that was unicast to that RBridge for distribution but would
   actually not be distributed.
   - Setting the C-nickname flag on a non-edge RBridge has no effect
   because the C-nickname flag is only consulted for the ingress nickname in
   the TRILL Header. If an RBridge is not an edge RBridge, its nickname should
   never appear in the ingress nickname field of the TRILL Header for a TRILL
   data packet. Setting the C-nickname flag for an edge RBridge that does not
   actually implement centralized replication would mean that the edge RBridge
   would try to normally distribute multi-destination data on the
   bi-directional distribution tree while the transit nodes in the tree would
   be pruning based on centralized distribution so it is likely the packet
   would 

Re: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-centralized-replication-11: (with COMMENT)

[Donald Eastlake]

Hi Spencer,

On Wed, Dec 27, 2017 at 11:24 AM, Spencer Dawkins
 wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-trill-centralized-replication-11: No Objection
>
>...
>
> --
> COMMENT:
> --
>
> No TSV concerns from me, but I was interested in the MUST/SHOULD mismatch that
> Joseph Salowey mentioned in his review of -10. I didn't see a change about 
> that
> in -11.

It looks like there were two cases of a "SHOULD" that needed to be
changed to a "MUST", one in the Abstract and one near the end of
Section 1, the Introduction. Should (must?) be easy to fix.

> I'm assuming the right thing will happen after the holidays, so no Discuss :-)
> ...

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] [secdir] Secdir last call review of draft-ietf-trill-p2mp-bfd-07

[Donald Eastlake]

Hi Stephen,

Thanks for your review.

On Thu, Dec 28, 2017 at 9:54 AM, Stephen Farrell
 wrote:
> Reviewer: Stephen Farrell
> Review result: Has Issues
>
> Mostly this draft is just bookkeeping so BFD can use trill's P2MP
> capabilities.
>
> I think there is one issue to consider, though since I've not read all the
> referenced documents in detail, I'm open to correction as to whether or
> not this is a real issue.
>
> IIRC, BFD has some pretty crappy "authentication" schemes, such as
> allowing a cleartext password, and not using HMAC when doing keyed
> hashes. That's been justified by performance and implementation
> requirements for BFD. (Not that I ever found those justifications that
> satisfactory myself:-) I don't think TRILL has the same issues in
> that (again IIRC) TRILL doesn't define such "dodgy" schemes, so that
> leads me to wonder if this text is really correct/wise:

The BFD standard was adopted in 2010 and does indicate that its keyed
SHA1 method is strongest and points designers of future BFD
authentication types towards HMAC...

> "...there is little reason to use the [RFC7978] security mechanisms at
> this time..."
>
> I'd have thought that avoiding the more-dodgy BFD mechanisms would
> be a reason for using TRILL authentication mechanisms.

TRILL essentially clones the IS-IS cryptographic authentication
mechanisms which do use HMAC (RFC5310).

> In addition, it's not clear (to me) from the draft if the security
> assumptions made for BFD still hold in the environments where
> TRILL is likely to be used. If not, then that'd be another reason to
> argue that  TRILL authentication ought be used.

It seems to me that perhaps the direction of the recommendation should
be flipped so that RFC 7978 authentication is recommended over BFD
multipoint authentication. Maybe something like:

OLD
   However, [RFC7978],
   while it provides both authentication and encryption for point-to-
   point extended RBridge Channel messages, provides only authentication
   for multipoint RBridge Channel messages. Thus, there is little reason
   to use the [RFC7978] security mechanisms at this time. However, it is
   expected that a future document will provide for group keying; when
   that occurs, the use of RBridge Channel security will also be able to
   provide encryption and may be desirable.

NEW
   [RFC7978] provides encryption only for point-to-point extended
   RBridge Channel messages so its encryption facilities are not
   applicable to this draft. However [RFC7978] provides stronger
   authentication than that currently provided in BFD. Thus, there is
   little reason to use the BFD security mechanisms if [RFC7978]
   authentication is in use. It is expected that a future TRILL
   document will provide for group keying; when that occurs, the use
   of [RFC7978] RBridge Channel security will be able to provide both
   encryption and authentication.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Secdir last call review of draft-ietf-trill-centralized-replication-10

[Donald Eastlake]

Hi Joseph,

Thanks for the review, see below.

On Sun, Dec 10, 2017 at 4:32 PM, Joseph Salowey  wrote:

> Reviewer: Joseph Salowey
> Review result: Has Issues
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> Document is ready with issues.
>
> I think the document has appropriate security considerations.
>
> One issue I see in the document is that in the intro it states:
> "The basic idea is that all ingress RBridges send BUM traffic to a
> centralized
> node, which SHOULD be a distribution tree root, using unicast TRILL
> encapsulation." In section 3 it states : "The centralized node MUST be a
> distribution tree root."
>
> The MUST and SHOULD seem to be at odds here.
>

Indeed, a number of "SHOULD"s were changed in a recent revision to "MUST"s
and it looks like one of the most prominent, in the Abstract, was
overlooked.

Thanks,
Donald (document shepherd)
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] TRILL WG minutes uploaded for Singapore meeting

[Donald Eastlake]

Hi,

Draft minutes of the TRILL WG meeting in Singapore have been uploaded to
the meeting materials area. See
https://datatracker.ietf.org/meeting/100/materials/minutes-100-trill/

Any corrections welcome.

Thanks,
Donald (TRILL Secretary)
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] I-D Action: draft-ietf-trill-directory-assisted-encap-07.txt

[Donald Eastlake]

Hi,

I believe this revision resolves the outstanding WG Last Call comments.

Ben: Could you check if you RTGDIR Early Review comments are resolved?

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


On Tue, Dec 5, 2017 at 3:01 PM,  <internet-dra...@ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transparent Interconnection of Lots of Links 
> WG of the IETF.
>
> Title   : Directory Assisted TRILL Encapsulation
> Authors : Linda Dunbar
>   Donald Eastlake
>   Radia Perlman
> Filename: draft-ietf-trill-directory-assisted-encap-07.txt
> Pages   : 15
> Date: 2017-12-05
>
> Abstract:
>This draft describes how data center networks can benefit from non-
>RBridge nodes performing TRILL encapsulation with assistance from a
>directory service.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assisted-encap/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-trill-directory-assisted-encap-07
> https://datatracker.ietf.org/doc/html/draft-ietf-trill-directory-assisted-encap-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-directory-assisted-encap-07
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] I-D Action: draft-ietf-trill-over-ip-11.txt

[Donald Eastlake]

This revision has changes intended to resolve most, but not all, of the
comments in the Transport Area review of this draft. Thus some additional
work on this draft is needed. The comments concerning NAT traversal were
resolved, as discussed at the TRILL WG meeting at the IETF meeting in
Singapore, by declaring NAT traversal out of scope for this draft.

Additional comments on any of these changes are welcome.

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

On Sat, Dec 2, 2017 at 11:32 PM, <internet-dra...@ietf.org> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transparent Interconnection of Lots of
> Links WG of the IETF.
>
> Title   : TRILL (Transparent Interconnection of Lots of
> Links) over IP
> Authors : Margaret Cullen
>   Donald Eastlake
>   Mingui Zhang
>   Dacheng Zhang
> Filename: draft-ietf-trill-over-ip-11.txt
> Pages   : 42
> Date: 2017-12-02
>
> Abstract:
>The TRILL (Transparent Interconnection of Lots of Links) protocol
>supports both point-to-point and multi-access links and is designed
>so that a variety of link protocols can be used between TRILL switch
>ports. This document specifies transmission of encapsulated TRILL
>data and TRILL IS-IS over IP (v4 or v6). so as to use an IP network
>as a TRILL link in a unified TRILL campus. This document updates RFC
>7177 and updates RFC 7178.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-trill-over-ip-11
> https://datatracker.ietf.org/doc/html/draft-ietf-trill-over-ip-11
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-over-ip-11
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] I-D Action: draft-ietf-trill-directory-assisted-encap-06.txt

[Donald Eastlake]

Hi,

This revision of draft-ietf-trill-assisted-encap resolves my last call
comments here:
https://www.ietf.org/mail-archive/web/trill/current/msg07883.html

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

On Mon, Nov 27, 2017 at 11:51 PM, <internet-dra...@ietf.org> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transparent Interconnection of Lots of
> Links WG of the IETF.
>
> Title   : Directory Assisted TRILL Encapsulation
> Authors : Linda Dunbar
>   Donald Eastlake
>   Radia Perlman
> Filename: draft-ietf-trill-directory-assisted-encap-06.txt
> Pages   : 15
> Date: 2017-11-27
>
> Abstract:
>This draft describes how data center networks can benefit from non-
>RBridge nodes performing TRILL encapsulation with assistance from a
>directory service.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-trill-
> directory-assisted-encap/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-trill-directory-assisted-encap-06
> https://datatracker.ietf.org/doc/html/draft-ietf-trill-
> directory-assisted-encap-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-
> directory-assisted-encap-06
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] I-D Action: draft-ietf-trill-ecn-support-04.txt

[Donald Eastlake]

Hi,

The revision is due to a change in Bob Briscoe's affiliation and to
avoid expiration of the draft, which is awaiting write-up.

(This draft already has been judged to have WG consensus:
https://www.ietf.org/mail-archive/web/trill/current/msg07908.html)

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

On Mon, Nov 20, 2017 at 11:06 PM,   wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transparent Interconnection of Lots of Links 
> WG of the IETF.
>
> Title   : TRILL: ECN (Explicit Congestion Notification) 
> Support
> Authors : Donald E. Eastlake
>   Bob Briscoe
> Filename: draft-ietf-trill-ecn-support-04.txt
> Pages   : 19
> Date: 2017-11-20
>
> Abstract:
>Explicit congestion notification (ECN) allows a forwarding element to
>notify downstream devices, including the destination, of the onset of
>congestion without having to drop packets. This can improve network
>efficiency through better flow control without packet drops. This
>document extends ECN to TRILL switches, including integration with IP
>ECN, and provides for ECN marking in the TRILL Header Extension Flags
>Word (see RFC 7179).
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-trill-ecn-support/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04
> https://datatracker.ietf.org/doc/html/draft-ietf-trill-ecn-support-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-ecn-support-04
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] draft-ietf-trill-group-keying

[Donald Eastlake]

Unless there is some objection in the next couple of days, I will
proceed as described at today's TRILL WG meeting (see
https://datatracker.ietf.org/meeting/100/materials/slides-100-trill-sessa-group-keying-update/)
with the draft-ietf-trill-group-keying draft.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] CORRECTION: Re: TRILL WG Meeting Moved to Monday afternoon

[Donald Eastlake]

On Sun, Nov 12, 2017 at 12:43 AM, Donald Eastlake <d3e...@gmail.com> wrote:
>
> Hi,
>
> Note that the TRILL WG Meeting in Singapore has been moved earlier from 
> Thursday afternoon to Monday afternoon. It will be replacing I2RS for the 
> 15:50 to 17:20 slot in the VIP A Room.

Correction: the TRILL WG Meeting will be Monday afternoon in the VIP A
Room but will be from 17:40 to 18:40. (The 15:50 to 17:20 time slot in
VIP A is still the I2RS WG.)

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] I-D Action: draft-ietf-trill-multi-topology-05.txt

[Donald Eastlake]

Hi,

This was a trivial update to change references to
draft-ietf-trill-rfc6439bis to be references to RFC 8139 and to avoid
expiration.

Note that this draft is still in WG Last Call. Please post indicating your
opinion on the draft.

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

On Sun, Nov 12, 2017 at 10:27 PM, <internet-dra...@ietf.org> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transparent Interconnection of Lots of
> Links WG of the IETF.
>
> Title   : TRILL: Multi-Topology
>     Authors : Donald Eastlake
>   Mingui Zhang
>   Ayan Banerjee
> Filename: draft-ietf-trill-multi-topology-05.txt
> Pages   : 25
> Date: 2017-11-12
>
> Abstract:
>This document specifies extensions to the IETF TRILL (Transparent
>Interconnection of Lots of Links) protocol to support multi-topology
>routing of unicast and multi-destination traffic based on IS-IS
>(Intermediate System to Intermediate System) multi-topology specified
>in RFC 5120. This document updates RFC 6325 and RFC 7177.
>
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-trill-multi-topology/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-trill-multi-topology-05
> https://datatracker.ietf.org/doc/html/draft-ietf-trill-multi-topology-05
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-multi-topology-05
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] TRILL WG Meeting Moved to Monday afternoon

[Donald Eastlake]

Hi,

Note that the TRILL WG Meeting in Singapore has been moved earlier from
Thursday afternoon to Monday afternoon. It will be replacing I2RS for the
15:50 to 17:20 slot in the VIP A Room.

Thanks,
Donald (TRILL WG Secretary)
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Final call for TRILL WG presentations

[Donald Eastlake]

Hi,

This is a final call for presentations to the TRILL WG meeting
Thursday afternoon at the IETF Singapore meeting this coming week. If
you would like to present either respond to me or to
trill-cha...@ietf.org or to this mailing list.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-arp-optimization-09: (with COMMENT)

[Donald Eastlake]

Oh.

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


On Thu, Nov 9, 2017 at 9:29 AM, Eric Rescorla <e...@rtfm.com> wrote:
> Sorry, this is just the result of bad tooling combined with lack of coffee.
> When you change a Discuss to a No Objection it keeps the comments. I agree
> the current text is fine.
>
> On Thu, Nov 9, 2017 at 6:26 AM, Donald Eastlake <d3e...@gmail.com> wrote:
>>
>> Hi Eric,
>>
>> Thanks for clearing your DISCUSS. See responses below to your
>> remaining COMMENTs.
>>
>> On Thu, Nov 9, 2017 at 8:40 AM, Eric Rescorla <e...@rtfm.com> wrote:
>> >
>> > Eric Rescorla has entered the following ballot position for
>> > draft-ietf-trill-arp-optimization-09: No Objection
>> >
>> >
>> > --
>> > COMMENT:
>> > --
>> >
>> > S 2.
>> >
>> >plane on the edge RBridges, it should be possible to completely
>> >suppress flooding of ARP/ND messages in a TRILL Campus, When all end-
>> >station MAC addresses are similarly known, it should be possible to
>> >suppress unknown unicast flooding by dropping any unknown unicast
>> >received at an edge RBridge.
>> >
>> > Are these "should be possibles" normative? Descriptive?
>>
>> The following sentence was added earlier in Section 2 to make it clear
>> that these were not normative:
>>"This section is a general discussion of this
>>problem and is not intended to be normative."
>>
>> > S 4.
>> > This is a sequence of steps, so it would be nice to preface them with
>> > a list of the steps. It's also odd to have SEND considerations right
>> > in the middle here.
>> >
>> > 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP
>> > Please explain what a non-zero IP is and why it's relevant.
>> > This graf also needs an introductory sentence or something before
>> > the bullets.
>>
>> Section 4.3 has been re-named. "non-zero" no longer occurs anywhere in
>> this document. An introductory paragraph was added before the bullets.
>>
>> > S 4.4.
>> >It is not essential that all RBridges use the same strategy for which
>> >option to select for a particular ARP/ND query. It is up to the
>> >implementation.
>> >
>> > This seems inconsistent with the MUST in arm (b) below, because I
>> > can just take some other arm. It's also kind of surprising to be this
>> > non-prescriptive.
>>
>> This is not actually inconsistent. The paragraph at the beginning of
>> Section 4.4 explains that which lettered "arm" you take is fixed by
>> the situation; it is an implementation choice which numbered sub-arm
>> to take under each lettered arm.
>>
>> > S 8.
>> >some other location (MAC/VM Mobility) and gets connected to egde-
>> >
>> > Nit: edge is mispelled.
>>
>> As far as I can see, the misspelling of edge has been fixed in -09.
>>
>> Thanks,
>> Donald
>> ===
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  d3e...@gmail.com
>
>

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-arp-optimization-09: (with COMMENT)

[Donald Eastlake]

Hi Eric,

Thanks for clearing your DISCUSS. See responses below to your
remaining COMMENTs.

On Thu, Nov 9, 2017 at 8:40 AM, Eric Rescorla  wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-trill-arp-optimization-09: No Objection
>
>
> --
> COMMENT:
> --
>
> S 2.
>
>plane on the edge RBridges, it should be possible to completely
>suppress flooding of ARP/ND messages in a TRILL Campus, When all end-
>station MAC addresses are similarly known, it should be possible to
>suppress unknown unicast flooding by dropping any unknown unicast
>received at an edge RBridge.
>
> Are these "should be possibles" normative? Descriptive?

The following sentence was added earlier in Section 2 to make it clear
that these were not normative:
   "This section is a general discussion of this
   problem and is not intended to be normative."

> S 4.
> This is a sequence of steps, so it would be nice to preface them with
> a list of the steps. It's also odd to have SEND considerations right
> in the middle here.
>
> 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP
> Please explain what a non-zero IP is and why it's relevant.
> This graf also needs an introductory sentence or something before
> the bullets.

Section 4.3 has been re-named. "non-zero" no longer occurs anywhere in
this document. An introductory paragraph was added before the bullets.

> S 4.4.
>It is not essential that all RBridges use the same strategy for which
>option to select for a particular ARP/ND query. It is up to the
>implementation.
>
> This seems inconsistent with the MUST in arm (b) below, because I
> can just take some other arm. It's also kind of surprising to be this
> non-prescriptive.

This is not actually inconsistent. The paragraph at the beginning of
Section 4.4 explains that which lettered "arm" you take is fixed by
the situation; it is an implementation choice which numbered sub-arm
to take under each lettered arm.

> S 8.
>some other location (MAC/VM Mobility) and gets connected to egde-
>
> Nit: edge is mispelled.

As far as I can see, the misspelling of edge has been fixed in -09.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] I-D Action: draft-ietf-trill-centralized-replication-10.txt

[Donald Eastlake]

Hi,

Thanks to Hao Weiguo for updating this draft.

The -09 version had changes intended to resolve the comments in Alia's
AD review. This -10 version just fixes a few small nits.

Thanks,
Donald (document Shepherd)
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


On Sun, Oct 29, 2017 at 10:07 PM,   wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transparent Interconnection of Lots of Links 
> WG of the IETF.
>
> Title   : Centralized Replication for Active-Active BUM 
> Traffic
> Authors : Weiguo Hao
>   Yizhou Li
>   Muhammad Durrani
>   Sujay Gupta
>   Andrew Qu
> Filename: draft-ietf-trill-centralized-replication-10.txt
> Pages   : 17
> Date: 2017-10-29
>
> Abstract:
>In TRILL active-active access, an RPF check failure issue may occur
>when using the pseudo-nickname mechanism specified in RFC 7781. This
>draft describes a solution to resolve this RPF check failure issue
>through centralized replication. All ingress RBridges send BUM
>(Broadcast, Unknown unicast and Mutlicast) traffic to a centralized
>node with unicast TRILL encapsulation. When the centralized node
>receives the BUM traffic, it decapsulates the packets and forwards
>them to their destination RBridges using a distribution tree
>established as per TRILL base protocol RFC 6325. To avoid RPF check
>failure on a RBridge sitting between the ingress RBridge and the
>centralized replication node, some change in the RPF calculation
>algorithm is required. RPF checks on each RBridge should be
>calculated as if the centralized node was the ingress RBridge,
>instead of being calculated using the actual ingress RBridge.
>
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-trill-centralized-replication/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-trill-centralized-replication-10
> https://datatracker.ietf.org/doc/html/draft-ietf-trill-centralized-replication-10
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-centralized-replication-10
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] RtgDir review: draft-ietf-trill-directory-assisted-encap-02

[Donald Eastlake]

Hi Ben,

Thanks for your review. It appears that is was not responded to in a
timely fashion. Apologies on behalf of the authors.

(Your review was of the -02 version. The current version is -05.)

On Sun, Apr 24, 2016 at 4:28 AM, Ben Niven-Jenkins
 wrote:
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review. The purpose of the review is to provide assistance to the
> Routing ADs. For more information about the Routing Directorate,
> please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing
> ADs, it would be helpful if you could consider them along with any
> other IETF Last Call comments that you receive, and strive to
> resolve them through discussion or by updating the draft.
>
>
> Document: draft-ietf-trill-directory-assisted-encap-02.txt
> Reviewer: Ben Niven-Jenkins
> Review Date: 21 April 2016
> Intended Status: Proposed Standard
>
> Summary:
> I have significant concerns about this document and recommend that
> the Routing ADs discuss these issues further with the authors.

Hopefully the changes made between the version -02 you reviewed and
the current -05 have made some improvements and, based on your
comments and WG LC comments, further improvements can be made.

> Comments:
> Overall this is not the easiest document to read although some of
> that might be due to my lack of background in TRILL and its
> terminology.
>
> Major Issues:
>
> 1) The document has an Intended Status of Proposed Standard, however
> it does not contain any RFC2119 keywords and does not seem to make
> any normative statements about required behaviour which I would have
> expected in a Proposed Standard.

Well, in version -05 there is at least one keyword instance.
Furthermore, I don't know that such keywords need to always be used
when an implementation requirement level is being specified. That
said, we could see if additional RFC 2119 keywords are warranted.

> 2) Section 4: If I understand correctly the TRILL-EN spoofs the
> Ingress RBridge edge node's nickname in the source address field of
> the TRILL header. Is this likely to introduce problems? E.g. if
> RBridges will accept & forward frames that have their own source
> address in, does it perpetuate routing loops or present security
> considerations that the document should discuss?

TRILL goes to great lengths to avoid loops and has a hop count in the
TRILL header so that, should there be a transient loop, a TRILL packet
in that loop (i.e., an encapsulated frame) will be discarded. In the
potentially more dangerous case of multi-destination packets, as
compared with known unicast, where copies could multiply due to forks
in the distribution tree, a Reverse Path Forwarding Check is used to
discard packets that appear to be on the wrong link or when there is
disagreement about the distribution tree.

Security Considerations should probably say more on this.

> Section 8 on Security Considerations also looks very light on
> text. If you are allowing TRILL-ENs to spoof RBridge source
> addresses (which I think you are, see comment above) I think you
> should have a discussion about that somewhere in the document.

I agree that some further discussion is needed in the Security
Considerations section.

> Minor Issues:
>
> 1) Section 3. I am not sure what Figure 2 is trying to convey and it
> is not referred to by the main text. Is it required?

Figure 2 is intended to show the header of a pre-encapsulated frame
going from a TRILL-EN to an edge TRILL switch. If it is retained in
the draft, there should be clarifying text that references it.

> 2) Section 3 says:
>
>Editor's note: [Directory] has defined Push and Pull methods for edge
>RBridges to get directory mapping information. The Pull Model is
>relative simple for TRILL-EN to implement (see Section 9). Pushing
>Directory information requires some reliable flooding mechanism, like
>the one used by IS-IS, between the edge RBridge and the TRILL
>encapsulating node.
>
> which gives me the impression the authors prefer pull and discourage
> push as it would require something extra like IS-IS.

That note no longer exists in the draft. Also the "[Directory]" draft
referred to has been issued as RFC 8171 and the draft should be
updated to reflect that.

> However, Section 4 says
>
>The TRILL-EN learns this nickname by listening
>to the TRILL IS-IS Hellos from the Ingress RBridge.
>
> which makes me think if the TRILL-EN is running IS-IS for hellos, is
> pushing the directory such an obstacle?

That text refers to snooping on IS-IS messages, not running IS-IS.

There are problems with using IS-IS, designed for communication
between routers (Intermediate Systems) and the end station
implementing pre-encapsulation as described 

Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi Eric,

I realize that most of the delay has been on the TRILL WG end but I hope
you don't mind if I ping you again on looking at the -09 revision of this
draft...

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

On Mon, Oct 9, 2017 at 7:05 PM, Donald Eastlake <d3e...@gmail.com> wrote:

> Hi Eric,
>
> A -09 version of draft-ietf-trill-arp-optimization has been posted. Could
> you look at it to see if it resolves your comments?
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-2270> (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com
>
> On Mon, Oct 2, 2017 at 2:12 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>>
>>
>> On Mon, Oct 2, 2017 at 4:54 PM, Donald Eastlake <d3e...@gmail.com> wrote:
>>
>>> Hi Eric,
>>>
>>> My apologies for the delay in response. (For part of the time I was on
>>> a cruise...)
>>>
>>> It looks like we are in agreement on most items.
>>>
>>> See below.
>>>
>>> On Fri, Sep 22, 2017 at 9:18 AM, Eric Rescorla <e...@rtfm.com> wrote:
>>> >
>>> >
>>> > On Wed, Aug 23, 2017 at 12:38 PM, Donald Eastlake <d3e...@gmail.com>
>>> wrote:
>>> >>
>>> >> Hi Eric,
>>> >>
>>> >> On Wed, Jul 5, 2017 at 7:38 AM, Eric Rescorla <e...@rtfm.com> wrote:
>>> >> > Eric Rescorla has entered the following ballot position for
>>> >> > draft-ietf-trill-arp-optimization-08: Discuss
>>> >> >
>>> >> > 
>>> --
>>> >> > DISCUSS:
>>> >> > 
>>> --
>>> >>
>>> >> As a general comment, the Security Consideration section could use
>>> >> clarification and some expansion.
>>> >>
>>> >> Although one can imagine various mixed modes, to the first
>>> approximation
>>> >> there are two ways of doing the optimization of various
>>> multi-destination
>>> >> messages discussed in this document:
>>> >>
>>> >> + Using data plane learning by observing ARP/ND and similar messages
>>> (in
>>> >> addition to the learning of MAC addresses from the data plane which is
>>> >> enabled by default in TRILL). As described in this document, such
>>> data plane
>>> >> learning by TRILL switches can be used to sometimes optimize
>>> >> ARP/ND/RARP/unknown-destination messages. But the result isn't
>>> particularly
>>> >> more or less secure than it is when this data plane learning is done
>>> by end
>>> >> stations rather than by TRILL switches (or bridges or other kinds of
>>> >> switches) in the middle doing some optimization of the relevant
>>> >> multi-destination messages. Interface address information learned
>>> through
>>> >> data plane learning by edge TRILL switches can also be propagated via
>>> the
>>> >> control plane but this is not significantly different from
>>> propagating that
>>> >> information via the multi-destination messages that are being
>>> optimized to
>>> >> unicast or optimized away.
>>> >> + Using a complete, trusted directory as might be based on an
>>> orchestration
>>> >> system in a data center. Since the messages between TRILL switches
>>> doing
>>> >> ARP/ND/RARP/unknown-destination optimization can be secured and the
>>> TRILL
>>> >> switches can be configured to ignore data plane learning, this
>>> enables TRILL
>>> >> switches to provide answers that are "correct" in that they
>>> correspond to
>>> >> the data in this complete, trusted directory. However, there can
>>> still be
>>> >> various forged messages/addresses on a local link between end
>>> station(s) and
>>> >> edge TRILL switches. Such a local link can, with TRILL, be a bridged
>>> LAN, so
>>> >> such forgeries emitted by an end station may be seen by other end
>>> stations
>>> >> and cause incorrect learning from the data plane.
>>> >>
>>> >

Re: [trill] trill - Requested session has been scheduled for IETF 100

[Donald Eastlake]

Hi,

We have a one hour slot at the Singapore meeting. People who would like to
present should contact trill-cha...@ietf.org.

Thanks,
Donald (TRILL WG Secretary)
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

On Fri, Oct 20, 2017 at 8:24 PM, "IETF Secretariat" <age...@ietf.org> wrote:

> Dear Donald Eastlake,
>
> The session(s) that you have requested have been scheduled.
> Below is the scheduled session information followed by
> the original request.
>
> trill Session 1 (1:00:00)
> Thursday, Afternoon Session III 1810-1910
> Room Name: Bras Basah size: 100
> -
>
>
>
> Request Information:
>
>
> -
> Working Group Name: Transparent Interconnection of Lots of Links
> Area Name: Routing Area
> Session Requester: Donald Eastlake
>
> Number of Sessions: 1
> Length of Session(s):  1 Hour
> Number of Attendees: 24
> Conflicts to Avoid:
>  First Priority: saag netconf netmod bess isis
>  Second Priority: sfc spring sidr babel i2rs idr
>  Third Priority: intarea lpwan dnsop grow i2nsf
>
>
> People who must be present:
>   Susan Hares
>   Donald E. Eastlake 3rd
>   Alia Atlas
>   Jon Hudson
>
> Resources Requested:
>
> Special Requests:
>
> -
>
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] WGLC for draft-ietf-idr-ls-trill-03

[Donald Eastlake]

I support this draft as an author.

I am not aware of any IPR in this draft that needs to be declared.

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

On Thu, Oct 19, 2017 at 10:33 AM, John Scudder  wrote:

> Hi All,
>
> An IDR working group last call has been requested for
> draft-ietf-idr-ls-trill-03. Please reply to the list with your comments. As
> usual note we cannot advance the draft without participation from the
> group. Please get your comments in before November 3, 2017.
>
> Authors, please confirm that any relevant IPR has been disclosed.
>
> https://tools.ietf.org/html/draft-ietf-idr-ls-trill-03
>
> Thanks,
>
> --John
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] I-D Action: draft-ietf-trill-address-flush-04.txt

[Donald Eastlake]

This revision is intended to resolve Ramkumar's comments.

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

On Wed, Oct 18, 2017 at 2:57 PM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transparent Interconnection of Lots of
> Links WG of the IETF.
>
> Title   : TRILL: Address Flush Message
> Authors : Weiguo Hao
>   Donald E. Eastlake
>   Yizhou Li
>   Mohammed Umair
> Filename: draft-ietf-trill-address-flush-04.txt
> Pages   : 20
> Date: 2017-10-18
>
> Abstract:
>The TRILL (TRansparent Interconnection of Lots of Links) protocol, by
>default, learns end station addresses from observing the data plane.
>In particular, it learns local MAC addresses and edge switch port of
>attachment from the receipt of local data frames and learns remote
>MAC addresses and edge switch of attachment from the decapsulation of
>remotely sourced TRILL Data packets.
>
>This document specifies a message by which a TRILL switch can
>explicitly request other TRILL switches to flush certain MAC
>reachability learned through the decapsulation of TRILL Data packets.
>This is a supplement to the TRILL automatic address forgetting and
>can assist in achieving more rapid convergence in case of topology or
>configuration change.
>
>
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-trill-address-flush/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-trill-address-flush-04
> https://datatracker.ietf.org/doc/html/draft-ietf-trill-address-flush-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-address-flush-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Fwd: New Version Notification for draft-eastlake-trill-vendor-channel-02.txt

[Donald Eastlake]

As per the presentation at the Berlin IETF meeting here
https://datatracker.ietf.org/meeting/99/materials/slides-99-trill-vendor-channel-protocol/
the vendor channel draft has been revived.

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

-- Forwarded message --
From: 
Date: Fri, Sep 1, 2017 at 3:56 PM
Subject: New Version Notification for
draft-eastlake-trill-vendor-channel-02.txt
To: Hao Weiguo , Yizhou Li ,
Ayan Banerjee , "Donald E. Eastlake" 

A new version of I-D, draft-eastlake-trill-vendor-channel-02.txt
has been successfully submitted by Donald E. Eastlake and posted to the
IETF repository.

Name:   draft-eastlake-trill-vendor-channel
Revision:   02
Title:  TRILL: Vendor Specific TRILL Channel Protocol
Document date:  2017-09-01
Group:  Individual Submission
Pages:  14
URL:https://www.ietf.org/internet-drafts/draft-eastlake-trill-
vendor-channel-02.txt
Status: https://datatracker.ietf.org/doc/draft-eastlake-trill-
vendor-channel/
Htmlized:   https://tools.ietf.org/html/draft-eastlake-trill-vendor-
channel-02
Htmlized:   https://datatracker.ietf.org/doc/html/draft-eastlake-trill-
vendor-channel-02
Diff:   https://www.ietf.org/rfcdiff?url2=draft-eastlake-trill-
vendor-channel-02

Abstract:
   The IETF TRILL (TRansparent Interconnection of Lots of Links)
   protocol is implemented by devices called TRILL switches or RBridges
   (Routing Bridges). TRILL includes a general mechanism, called RBridge
   Channel, for the transmission of typed messages between RBridges in
   the same campus and between RBridges and end stations on the same
   link. This document specifies a method to send vendor specific
   messages over the RBridge Channel facility.






Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Draft TRILL minutes posted

[Donald Eastlake]

Hi,

Draft minutes of the TRILL WG at the recent Prague IETF meeting have been
posted the meeting materials page. Corrections welcome. See
https://datatracker.ietf.org/meeting/99/materials

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Comments on draft-ietf-trill-smart-endnodes

[Donald Eastlake]

Hi,

Having just refreshed myself on both the smart-endnode and directory
assisted encap drafts, I think the smart-endnode draft should be
changed from using native RBridge Channel messages to using the TRILL
ES-IS specified in RFC 8171. ES-IS would allow a much larger amount of
data to be synchronized between edge-RBridges and smart endnodes, for
example if a smart endnode were actually some sort of gateway and was
handling a very large number of MAC addresses. Just how to use a
native RBridge Channel message, as is currently specified in this
draft, seems underspecified and would probably need a state diagram,
etc., to be complete.

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


On Fri, Jul 21, 2017 at 5:07 AM, Donald Eastlake <d3e...@gmail.com> wrote:
> I support this draft and have the following comments:
>
> Technical
> -
>
> It is not made clear how Smart End Nodes learn the Designated VLAN of
> the link they are on or, considering the paragraph just before the
> Section 5.2 header, the Appointed Forwarder for a VLAN or the DRB. It
> seems to me the draft needs to say explicitly that the smart end node
> snoops on TRILL IS-IS Hellos. Also, it needs to say that a smart end
> node, when encapsulating traffic in VLAN X, needs to use the nickname
> of the appointed forwarder for VLAN X, regardless of which edge
> RBridge it sends the encapsulated frame to, to avoid MAC flip-flop at
> the egress RBridge.
>
> The point paragraph just before the Section 6 header provides two
> approaches to handling a hybrid local link (a hybrid link is one with
> both smart and non-smart end nodes on it). As a Proposed Standard and
> in accordance with TRILL's general design approach, the document needs
> to select one and make it be the default.
>
> Section 6 also has two alternatives and does not seem clear.
> Presumably there isn't a single link with SE1, RB1, and RB2 on it
> since that case is well handled by the smart end node using the
> appointed forwarder nickname regardless of which edge RBridge it sends
> the encapsulated user data to. So it must be that SE1 is dual ported.
> If so, probably these ports have different MAC addresses and I'm not
> sure what the problem is
>
> I think it is inconsistent that IANA Considerations says "Smart-Hello"
> while near the start of the draft, the TLV is called
> "Smart-Parameters".
>
> "The mechanism for querying a directory is out of scope for this
> document." -> "The mechanism for querying a directory is given in
> [RFC8171]."
>
> Editorial
> ---
>
> Change ".While when" to ". When"
>
> "nicknamae" -> "nickname"
>
> There are also some other more minor editorial things I can
> communicate directly to the principal author.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Comments on draft-ietf-trill-directory-assisted-encap

[Donald Eastlake]

I support this draft. See comments below:

Technical


To avoid MAC flip-flop at the remote egress RBridge, the TRILL-EN node
needs to use the Appointed Forwarder for the encapsulated data frame's
VLAN regardless of which edge RBridge it sends it to. This also solves
a potential problem with return traffic. If return traffic arrived for
egress at other than the Appointed Forwarder, it would be dropped.

Editorial
---

Update references for the issuance of RFC 8171.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Comments on draft-ietf-trill-smart-endnodes

[Donald Eastlake]

I support this draft and have the following comments:

Technical
-

It is not made clear how Smart End Nodes learn the Designated VLAN of
the link they are on or, considering the paragraph just before the
Section 5.2 header, the Appointed Forwarder for a VLAN or the DRB. It
seems to me the draft needs to say explicitly that the smart end node
snoops on TRILL IS-IS Hellos. Also, it needs to say that a smart end
node, when encapsulating traffic in VLAN X, needs to use the nickname
of the appointed forwarder for VLAN X, regardless of which edge
RBridge it sends the encapsulated frame to, to avoid MAC flip-flop at
the egress RBridge.

The point paragraph just before the Section 6 header provides two
approaches to handling a hybrid local link (a hybrid link is one with
both smart and non-smart end nodes on it). As a Proposed Standard and
in accordance with TRILL's general design approach, the document needs
to select one and make it be the default.

Section 6 also has two alternatives and does not seem clear.
Presumably there isn't a single link with SE1, RB1, and RB2 on it
since that case is well handled by the smart end node using the
appointed forwarder nickname regardless of which edge RBridge it sends
the encapsulated user data to. So it must be that SE1 is dual ported.
If so, probably these ports have different MAC addresses and I'm not
sure what the problem is

I think it is inconsistent that IANA Considerations says "Smart-Hello"
while near the start of the draft, the TLV is called
"Smart-Parameters".

"The mechanism for querying a directory is out of scope for this
document." -> "The mechanism for querying a directory is given in
[RFC8171]."

Editorial
---

Change ".While when" to ". When"

"nicknamae" -> "nickname"

There are also some other more minor editorial things I can
communicate directly to the principal author.

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

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Genart last call review of draft-ietf-trill-arp-optimization-08

[Donald Eastlake]

Hi Dale,

Thanks for the review. See below.

On Wed, Jun 28, 2017 at 10:35 PM, Dale Worley  wrote:
> Reviewer: Dale Worley
> Review result: Ready with Nits
>
> 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.
>
> Document:  draft-ietf-trill-arp-optimization-08
> Reviewer:  Dale R. Worley
> Review Date:  2017-06-28
> IETF LC End Date:  2017-06-29
> IESG Telechat date:  unknown
>
> Summary:
>
>This draft is basically ready for publication, but has nits
>that should be fixed before publication.
>
>Abstract
>
>This document describes mechanisms to optimize the ARP (Address
>Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
>campus.
>
> s/in TRILL campus/in a TRILL campus/

OK.

> Perhaps summarize what the optimizations are:
>
>Each edge RBridge maintains a cache of IP/MAC address/Data Label
>bindings that are learned from ARP/ND requests and responses that
>pass through it.  This cache allows it to avoid flooding an ARP/ND
>request by either responding to it directly or by encapsulating it
>and unicasting it to the location where it is in use.

Wording along those lines sounds like a good addition.

>2 ARP/ND Optimization Requirement and Solution
>
>(including DHCP or gratuitous ARP_messages).
>
> s/_//

I think the underscore should be replaced by a space rather than the
null string.

>and should allow an end station to
>detect duplicate IP addresses.
>
> Unless this is a well-known phrase, it would be best if it was clear
> whether the end station is detecting that its own IP address is
> duplicated, or whether it is detecting that some other station's IP
> address is duplicated.

This is talking about the end station doing normal DAD by probing for
its own IP address.
"detect duplicate IP addresses" -> "detect duplication of its IP address".

>TRILL already provides an option to disable data-plane learning from
>the source MAC address of end-station frames on a per port basis (see
>Section 5.3 of [RFC6325]).
>
> Given how this section is written, shouldn't this option be considered
> an option to *enable* data-plane learning?  And in particular, doesn't
> that imply that TRILL already includes a solution to suppress ARP
> flooding?

By default RBridges learn the source MAC addresses of the Ethernet
frames they receive from attached end stations in a way similar to
such data plane learning by bridges. A change in that default, to not
learn such MAC addresses requires optional configuration. I don't
think just learning MAC addresses is useful for the types of ARP
flooding suppression talked about in this document.

> Also, what is the meaning of "learning from the source MAC address"?
> It seems like you'd want to specify what the learning is *of*, and
> then perhaps what it is learned *from*.
>
> Or is this particular learning of MAC addresses alone, and not of
> IP/MAC bindings?  If so, then isn't this feature orthogonal to ARP/ND
> optimization?

As per RFC 6325, RBridge default to data plane learning of MAC
addresses but not IP addresses. Although TRILL has ways of arbitrating
between conflicting addressing information learned through different
paths, it may be useful to disable data plane MAC address learning
when a directory is being used or the like.

> As a design matter, I'm curious why an RBridge can't learn IP/MAC
> bindings by snooping data packets, and only by snooping ARP packets.
> I suspect there are good reasons for it, but the naive reader (me) is
> left wondering...

You can get miscellaneous data packets at line speed so MAC address
learning is frequently implemented in hardware. While there is no
reason you couldn't do that for IP addresses, if you don't want to
require hardware changes from that in most existing implementations,
you would learn from ARP/ND in software which is generally practical
as they are not normally received that frequently.

>4.1 SEND Considerations
>
>Secure SEND messages require knowledge of cryptographic keys. Methods
>of communicating such keys to RBridges for use in SEND are beyond the
>scope of this document. Thus, using the optimizations in this
>document, RBridges do not attempt to construct SEND messages and are
>generally transparent to them. RBridges only construct ARP, RARP, or
>insecure ND messages, as appropriate.
>
> This doesn't flow quite correctly.  The second sentence suggests that
> there are known mechanisms for distributing keys to RBridges, but that
> this document doesn't describe them.

I disagree. Saying "X is beyond the scope of this document" means what
it says: that the topic is not further touched on in this document. I
do not think it implies that techniques to do X do or do not exist.

>

Re: [trill] [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations

[Donald Eastlake]

Hi David,

On Mon, Jun 26, 2017 at 3:04 PM, Black, David <david.bl...@dell.com> wrote:
> Adding some comments on ECN and DSCP ...
>
>> > Section 4.3:
>> >
>> >TRILL over IP implementations MUST support setting the DSCP value in
>> >the outer IP Header of TRILL packets they send by mapping the TRILL
>> >priority and DEI to the DSCP. They MAY support, for a TRILL Data
>> >packet where the native frame payload is an IP packet, mapping the
>> >DSCP in this inner IP packet to the outer IP Header with the default
>> >for that mapping being to copy the DSCP without change.
>> >
>> > I think it is fine to require that implementations are capable of setting
>> > DSCP values on the outer IP header. However, I fail to see any discussion 
>> > of
>> > the potential issues with actually setting the DSCP values. It is one 
>> > thing to
>> > do this in an IP back bone use case where one can know and have control
>> > over the PHB that the DSCP values maps to. But otherwise, over general
>> > internet the
>> > behavior is not that predictable. One can easily be subject to policers or
>> > remapping. Also as the actual DSCP code point usage is domain specific 
>> > this is
>> > difficult. Priority reversal is likely the least of the problems that this 
>> > can
>> > run into over general Internet.
>>
>> It sounds like appropriate discussion and warnings about these issues
>> would resolve the above comment.
>
> For ECN, see RFC 6040 and draft-ietf-tsvwg-rfc6040update-shim.  In particular,
> copying the inner ECN codepoint to the outer IP header encapsulation without
> requiring decapsulation processing as specified in RFC 6040 or the 
> 6040update-shim
> draft can lose congestion indications from the network and hence is wrong
> (it's also wrong wrt RFC 3168, but RFC 6040 and the 6040update-shim drafts are
> better and more current references).

That's a good point.

> For DSCPs, start with RFC 2983 - thinking about the validity (or likely 
> validity)
> of the outer DSCP at the decapsulator may help in choosing whether to
> recommend a uniform model (e.g., copy DSCP out at ingress, copy back in at
> egress) or a pipe model (e.g., do something reasonable for outer DSCP at
> ingress, ignore it on egress) as the implementation default.

I believe the default behavior in the current draft is the best
default. That sets DSCP based on the same TRILL Header indicia that
controls default QoS on non-IP links.

> -- DSCP mapping to/from TRILL/Ethernet priorities
>
>> The intent in the draft is to reflect the default relative priority of
>> the different priority code points in IEEE Std 802.1Q where priority 1
>> is lower than priority 0. At a quick look, it appears to me that RFC
>> 2474 requires that 0x001000 be handled as being of a priority not
>> lower than the priority with which 0x00 is handled. Yet RFC 3662,
>> which you point to, seems to suggest using 0x001000 as a lower
>> priority code point than 0x00. Given that 3662 not only does not
>> update 2474 but is only Informational while 2474 is Standards Track, I
>> would say that 2474 dominates and that this draft makes the best
>> assumptions it can about default behavior...
>
> Well ... that's a discussion about text in RFCs that are well over a decade
> old, and in an area (less-than-best-effort service) where the aspirations
> of at least RFC 3662 weren't realized ... but that RFC is not safe to ignore,
> either.
>
> In practice, the specification of CS1 for less-than-best-effort service has
> been promulgated by RFC 4594 rather than RFC 3662, and RFC 4594 has
> had significant "running code" impact on network design and operation.
>
> As Magnus mentioned RFC7657, I strongly suggest starting from the
> RFC 7657 discussion of this topic in order to figure out what to do.  I'm
> not sure what to recommend, but I do think that starting from
> RFC 7657 (rather than RFC 2474 and RFC 3662) is the better approach.

OK.

> FWIW, the TSVWG WG is in the process of figuring out which DSCP
> to recommend for less-than-best-effort-service in place of CS1 - that's
> likely to be an active topic of discussion in Prague.

I'll try to attend that session.

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

> Thanks, --David
>
>> -Original Message-
>> From: Tsv-art [mailto:tsv-art-boun...@ietf.org] On Behalf Of Donald
>> Eastlake
>> Sent: Sunday, June 25, 2017 8:07 PM
>> To: Magnus Westerlund <magnus.w