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 000010 / 0 > 2 0/1 010000 / 16 > 3 0/1 011000 / 24 > 4 0/1 100000 / 32 > 5 0/1 101000 / 40 > 6 0/1 110000 / 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 000010 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 (000000)? 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 very sparse, then the TCP > connection marked with a higher priority DSCP may have a very small > congestion window. So when the high priority traffic is to be sent it will > in fact be delayed more by the TCP stacks congestion control than the lower > priority that has a larger window established. However, that is only really > an issue if the high priority traffic is multiple packets that comes in > burst. Also, if there is on path contention the lower priority traffic may > still not make it even if sent earlier, so not using a high priority DSCP > is not really an option either. > > I think the IP/TCP/Trill and TCP header figures are simply non-relevant > here. I think they can give the impression that a receiving node can > process each TCP packet individually rather than running a full TCP > implementation here. What is relevant is the framing format that delimit > each Trill packet sent by TCP. > > +--------+-------- // ----+ | Length | TRILL packet | > +--------+----- // -------+ > > The above figure is a bit confusing, I assume the intention is to indicate > previous Trill packet with framing and the following one. I think you be > more explicit about that as an explanation. > > > If the > initial 2 bytes of the TRILL packet are not one of these > Ethertypes, then the receiver assumes that framing > synchronization has been lost and MUST close that TCP > connection. > > Yes, this is very important text. I would recommend that it is moved into > its own paragraph rather than hidden in a figure explanation. I am also > missing the specification what to do when one have closed the connection. I > assume that it is to have either part re-initiate. But, is it the closing > party (receiver) that should do this, or the sending part? As TCP > connections are bi-directional, but I assume that these are used only > unidirectionally, and thus it matters who should establish them in relation > to signalling? Congestion Control > > Flow and ECMP > ------------- > > > > Issues resolved in the more limited applicability scope. > > NAT and TRILL over IP: > > > I think it is fine with the WG saying that NATs are out of scope for > Trill. However, I really think you need to say this upfront in the document > that this specification relies on that there are no NAT in the path between > the trill nodes using this specification. And be explicit if there would be > NATs then things will not work as intended. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Media Technologies, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > <+46%2010%20714%2082%2087>Torshamnsgatan 23 > <https://maps.google.com/?q=Torshamnsgatan+23&entry=gmail&source=g> > | Mobile +46 73 0949079 <+46%2073%20094%2090%2079> > SE-164 80 Stockholm, Sweden | mailto: magnus.westerl...@ericsson.com > ---------------------------------------------------------------------- > >
_______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
