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

[Magnus Westerlund]

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

On Tue, Jun 27, 2017 at 1:13 PM, Magnus Westerlund
  wrote:
Den 2017-06-26 kl. 02:07, skrev Donald Eastlake: 

On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund
  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 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 

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

[Joe Touch]

Hi, all,

This doc is very confusing.

Its title and discussion throughout indicates “TRILL over IP”, including figs 
in Sec 4, but the only actual encapsulations described are TRILL over UDP and 
TRILL over TCP.

IMO, this needs a very deep scrub to resolve. It would help to understand that 
the root issue is that the encapsulation headers are *all* those added to the 
TRILL packet trying to transit the IP network; there’s no “inserting” of 
encapsulation between IP and TRILL.

That includes:

- explaining why you require IPsec tunnel mode, when the encapsulations 
presented would be completely secure using TLS/DLS or any variant of IPsec on 
the encapsulated traffic

- explaining the relation between TRILL MTU discovery and the MTU of the 
transport level, and how these interact (or could interfere) with each other

- why are not other more obvious encapsulations being considered, notably any 
TCP/UDP encapsulation that already supports Ethernet, including GRE (which 
might then allow this doc to be condensed to instructions for configuration, 
rather than trying to specify a new encapsulation system)

Joe


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

[trill] WG LC on draft-ietf-trill-group-keying-01 and draft-ietfltrill-link-gk-profiles-00

[Susan Hares]

This begins a 2 week WG LC on two drafts on group keying:   Simple Group
Keying Protocol and the profiles for simple key profiles to apply simple
group keying to the multi-destination TIRLL Extended Rbridge Channel message
and the TRILL -over IP (trill-over-ip) packet security. 

 

draft-ietf-trill-group-keying which can be found at: 

https://datatracker.ietf.org/doc/draft-ietf-trill-group-keying/

 

draft-ietf-trill-link-gk-profiles

https://datatracker.ietf.org/doc/draft-ietf-trill-link-gk-profiles/

 

These two drafts are being WG LC together because the provide a solution for
security for TRILL.

 

Please consider: 

1)  Is this technology which we have discussed for the last 2 years -
ready for publication? 

2)  Do you think these will solve the security issues we've discussed
with TRILL Extended Rbridge Channel message TRILL-over-IP packet security? 

3)  Do you see any problems with the solution? 

 

Cheerily,

Susan Hares 

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

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

[Susan Hares]

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 

___
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

[Susan Hares]

Joe:

As WG chair, I need to manage the last of the WG calls for the TRILL.   We are 
closing the TRILL WG and pushing to handle all the drafts in an effective 
manner.  Therefore,  I am going to be more blunt that I normally am. 

Are you asking to utilize TLS/DTLS instead of IPSEC tunnel mode on a link?   
Are you suggesting to run a routing protocol should intermix with data 
forwarding without security? 

If you are asking a draft to be rewritten at this point to explain these 
issues, I would like some substantiating background or theory from the routing 
side to indicate why you feel TLS/DTLS is better than an IPSEC tunnel or that a 
routing protocol should not be protected within a secure tunnel against data 
traffic.  The directions you are asking to document has not be successful in 
routing IGPs or path vector protocols.  

 If you are suggesting a tutorial is added to a protocol document, provide 
operational reasons why this should be contained within a TRILL protocol 
specification.   If you feel that these reasons for these choices should be 
document in an independent draft, then you are welcome to suggest this to Alia 
Atlas.  I'm sure that Donald Eastlake will consider an independent draft 
explain reasons if Alia Atlas thinks it is useful. 

I will hold the WG LC for trill-over-ip until Monday morning at noon ET (9am 
PT) while you start a focused discussion on this topic.  By Monday at noon ET, 
this discuss needs to come to a conclusion.   

Sue Hares 
Trill co-chair

-Original Message-
From: trill [mailto:trill-boun...@ietf.org] On Behalf Of Joe Touch
Sent: Friday, February 2, 2018 10:34 AM
To: Magnus Westerlund
Cc: Donald Eastlake; tsv-...@ietf.org; trill IETF mailing list; 
draft-ietf-trill-over-ip@ietf.org
Subject: Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10

Hi, all,

This doc is very confusing.

Its title and discussion throughout indicates “TRILL over IP”, including figs 
in Sec 4, but the only actual encapsulations described are TRILL over UDP and 
TRILL over TCP.

IMO, this needs a very deep scrub to resolve. It would help to understand that 
the root issue is that the encapsulation headers are *all* those added to the 
TRILL packet trying to transit the IP network; there’s no “inserting” of 
encapsulation between IP and TRILL.

That includes:

- explaining why you require IPsec tunnel mode, when the encapsulations 
presented would be completely secure using TLS/DLS or any variant of IPsec on 
the encapsulated traffic

- explaining the relation between TRILL MTU discovery and the MTU of the 
transport level, and how these interact (or could interfere) with each other

- why are not other more obvious encapsulations being considered, notably any 
TCP/UDP encapsulation that already supports Ethernet, including GRE (which 
might then allow this doc to be condensed to instructions for configuration, 
rather than trying to specify a new encapsulation system)

Joe


___
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] [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10

[Black, David]

A couple of Diffserv-related follow-ups to Magnus’s comments:

[1]

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

+1 – zero should be best effort in all contexts.   Moreover, the table has 
additional problems:


  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 entry for priority 1 is inconsistent – 10 Binary is *not* 0 decimal.

If 10 was an attempt to anticipate a possible TSVWG assignment of DSCP 
10 / 2 as the default DSCP for less than best effort traffic, this serves 
as a practical lesson in why that sort of attempt to predict the future is not 
appropriate for a standard.   While that DSCP was suggested in some earlier 
TSVWG drafts, better understanding of some unfortunate “running code” in the 
Internet that zeros only the most significant 3 bits in the DSCP has led to 
TSVWG’s current direction (as of the Singapore meeting week) to open up the 
pool of DSCPs that end in 01 (01) for standards usage in order to assign 
either DSCP 1 (01) or DSCP 5 (000101) as the default DSCP for less than 
best effort service.

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

+1, and see RFC 7657 for further discussion, including this text on why having 
a single TCP connection use DSCPs that vary only in drop precedence (i.e., 
aren’t supposed to cause reordering) is pointless:

   There are situations in which drop precedences should not be mixed.
   A simple example is that there is little value in mixing drop
   precedences within a TCP connection, because TCP's ordered delivery
  behavior results in any drop requiring the receiver to wait for the
   dropped packet to be retransmitted.

There are no “MUST” keywords in RFC 7657 because that RFC is informational 
design guidance, but its guidance justifies the “MUST” that Magnus suggests.  I 
would also suggest citing RFC 7657 as an informative reference.

Thanks, --David

From: Tsv-art [mailto:tsv-art-boun...@ietf.org] On Behalf Of Magnus Westerlund
Sent: Friday, February 2, 2018 4:29 AM
To: Donald Eastlake 
Cc: tsv-...@ietf.org; draft-ietf-trill-over-ip@ietf.org; trill@ietf.org
Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10


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

On Tue, Jun 27, 2017 at 1:13 PM, Magnus Westerlund

 wrote:
Den 2017-06-26 kl. 02:07, skrev Donald Eastlake:

On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund

 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)

  ---

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

[Joe Touch]

Hi Susan,

> On Feb 2, 2018, at 9:16 AM, Susan Hares  wrote:
> 
> Joe:
> 
> As WG chair, I need to manage the last of the WG calls for the TRILL.   We 
> are closing the TRILL WG and pushing to handle all the drafts in an effective 
> manner.  Therefore,  I am going to be more blunt that I normally am. 
> 
> Are you asking to utilize TLS/DTLS instead of IPSEC tunnel mode on a link?   

I’m indicating the doc fails to justify the required use of IP-level security 
for a transport encapsulation solution. 

> Are you suggesting to run a routing protocol should intermix with data 
> forwarding without security? 

No. 

> If you are asking a draft to be rewritten at this point to explain these 
> issues, I would like some substantiating background or theory from the 
> routing side to indicate why you feel TLS/DTLS is better than an IPSEC tunnel 
> or that a routing protocol should not be protected within a secure tunnel 
> against data traffic.  The directions you are asking to document has not be 
> successful in routing IGPs or path vector protocols.

Trill goes inside TCP or UDP in this doc. For that part of the path anything 
that protects that payload is sufficient. If the payload needs to be protected 
elsewhere ie before or after this transit then that is a separate issue. 

> 
> If you are suggesting a tutorial is added to a protocol document, provide 
> operational reasons why this should be contained within a TRILL protocol 
> specification.   If you feel that these reasons for these choices should be 
> document in an independent draft, then you are welcome to suggest this to 
> Alia Atlas.  I'm sure that Donald Eastlake will consider an independent draft 
> explain reasons if Alia Atlas thinks it is useful. 

None of this is relevant to my comment. 

> I will hold the WG LC for trill-over-ip until Monday morning at noon ET (9am 
> PT) while you start a focused discussion on this topic.  By Monday at noon 
> ET, this discuss needs to come to a conclusion.   
> 
> Sue Hares 
> Trill co-chair
> 
> -Original Message-
> From: trill [mailto:trill-boun...@ietf.org] On Behalf Of Joe Touch
> Sent: Friday, February 2, 2018 10:34 AM
> To: Magnus Westerlund
> Cc: Donald Eastlake; tsv-...@ietf.org; trill IETF mailing list; 
> draft-ietf-trill-over-ip@ietf.org
> Subject: Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10
> 
> Hi, all,
> 
> This doc is very confusing.
> 
> Its title and discussion throughout indicates “TRILL over IP”, including figs 
> in Sec 4, but the only actual encapsulations described are TRILL over UDP and 
> TRILL over TCP.
> 
> IMO, this needs a very deep scrub to resolve. It would help to understand 
> that the root issue is that the encapsulation headers are *all* those added 
> to the TRILL packet trying to transit the IP network; there’s no “inserting” 
> of encapsulation between IP and TRILL.
> 
> That includes:
> 
> - explaining why you require IPsec tunnel mode, when the encapsulations 
> presented would be completely secure using TLS/DLS or any variant of IPsec on 
> the encapsulated traffic
> 
> - explaining the relation between TRILL MTU discovery and the MTU of the 
> transport level, and how these interact (or could interfere) with each other
> 
> - why are not other more obvious encapsulations being considered, notably any 
> TCP/UDP encapsulation that already supports Ethernet, including GRE (which 
> might then allow this doc to be condensed to instructions for configuration, 
> rather than trying to specify a new encapsulation system)
> 
> Joe
> 
> 
> ___
> 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] [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10

[Black, David]

In looking back at this email, I realize that all I did about [1] was criticize.
Here’s a concrete suggestion for what to do:


  TRILL Priority  DEI  DSCP Field (Binary/decimal)

  --  ---  -

  0   0/1  00 / 0

1 0/1  --TBD- / TBD



[... snip ...]



RFC Editor: Please change the TBD DSCP for TRILL Priority 1 in the above

table to the DSCP value that is recommended for the Lower Effort PHB

(LE PHB) by draft-ietf-tsvwg-le-phb [LEphb] draft when that draft is

published as an RFC.

Anticipating a question about why the normative reference to the le-phb draft 
does not suffice –
the above text makes it clear to implementers that there is no DSCP that is 
(yet) appropriate to
use for TRILL Priority 1.

Thanks, --David

From: Black, David
Sent: Friday, February 2, 2018 12:21 PM
To: Magnus Westerlund ; Donald Eastlake 

Cc: tsv-...@ietf.org; draft-ietf-trill-over-ip@ietf.org; trill@ietf.org; 
Black, David 
Subject: RE: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10

A couple of Diffserv-related follow-ups to Magnus’s comments:

[1]

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

+1 – zero should be best effort in all contexts.   Moreover, the table has 
additional problems:


  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 entry for priority 1 is inconsistent – 10 Binary is *not* 0 decimal.

If 10 was an attempt to anticipate a possible TSVWG assignment of DSCP 
10 / 2 as the default DSCP for less than best effort traffic, this serves 
as a practical lesson in why that sort of attempt to predict the future is not 
appropriate for a standard.   While that DSCP was suggested in some earlier 
TSVWG drafts, better understanding of some unfortunate “running code” in the 
Internet that zeros only the most significant 3 bits in the DSCP has led to 
TSVWG’s current direction (as of the Singapore meeting week) to open up the 
pool of DSCPs that end in 01 (01) for standards usage in order to assign 
either DSCP 1 (01) or DSCP 5 (000101) as the default DSCP for less than 
best effort service.

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

+1, and see RFC 7657 for further discussion, including this text on why having 
a single TCP connection use DSCPs that vary only in drop precedence (i.e., 
aren’t supposed to cause reordering) is pointless:

   There are situations in which drop precedences should not be mixed.
   A simple example is that there is little value in mixing drop
   precedences within a TCP connection, because TCP's ordered delivery
  behavior results in any drop requiring the receiver to wait for the
   dropped packet to be retransmitted.

There are no “MUST” keywords in RFC 7657 because that RFC is informational 
design guidance, but its guidance justifies the “MUST” that Magnus suggests.  I 
would also suggest citing RFC 7657 as an informative reference.

Thanks, --David

From: Tsv-art [mailto:tsv-art-boun...@ietf.org] On Behalf Of Magnus Westerlund
Sent: Friday, February 2, 2018 4:29 AM
To: Donald Eastlake mailto:d3e...@gmail.com>>
Cc: tsv-...@ietf.org; 
draft-ietf-trill-over-ip@ietf.org;
 trill@ietf.org
Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10


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.

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  
>  wrote:
>
> On Tue, Jun 27, 2017 at 1:13 PM, Magnus 
> Westerlund  
> wrote:
>
> Den 2017-06-26 kl. 02:07, skrev Donald Eastlake:
>
> On Thu, Jun 15, 2017 at 1:32 PM, Magnus 
> Westerlund  
> 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 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 fi

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

[Donald Eastlake]

Hi David,

On Fri, Feb 2, 2018 at 12:20 PM, Black, David  wrote:
>
> A couple of Diffserv-related follow-ups to Magnus’s comments:
>
> [1]
>
> > 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.
>
> +1 – zero should be best effort in all contexts.   Moreover, the
>  table has additional problems:
>
>
>   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 entry for priority 1 is inconsistent – 10 Binary is *not* 0 decimal.

Yes, the decimal version was not updated when it should have been.

> If 10 was an attempt to anticipate a possible TSVWG assignment
> of DSCP 10 / 2 as the default DSCP for less than best effort
> traffic, this serves as a practical lesson in why that sort of
> attempt to predict the future is not appropriate for a standard.
> While that DSCP was suggested in some earlier TSVWG drafts, better
> understanding of some unfortunate “running code” in the Internet
> that zeros only the most significant 3 bits in the DSCP has led to
> TSVWG’s current direction (as of the Singapore meeting week) to open
> up the pool of DSCPs that end in 01 (01) for standards usage in
> order to assign either DSCP 1 (01) or DSCP 5 (000101) as the
> default DSCP for less than best effort service.

Thanks very much for your subsequent message suggesting specific
wording a copy of which is here:
https://www.ietf.org/mail-archive/web/trill/current/msg08112.html

Your suggested wording looks reasonable to me.

> > "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.
>
> +1, and see RFC 7657 for further discussion, including this text on
> why having a single TCP connection use DSCPs that vary only in drop
> precedence (i.e., aren’t supposed to cause reordering) is pointless:
>
>
>There are situations in which drop precedences should not be
>mixed.  A simple example is that there is little value in mixing
>drop precedences within a TCP connection, because TCP's ordered
>delivery behavior results in any drop requiring the receiver to
>wait for the dropped packet to be retransmitted.
>
>
> There are no “MUST” keywords in RFC 7657 because that RFC is
> informational design guidance, but its guidance justifies the “MUST”
> that Magnus suggests.  I would also suggest citing RFC 7657 as an
> informative reference.

Seems reasonable.

> Thanks, --David

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