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

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

[Susan Hares]

Joe: 

I am confused as to your concerns.  I'll take this offline to see if I can get 
some clarity on the concerns.  Thank you for your continued comments on this 
document. 

Sue Hares 

-Original Message-
From: Joe Touch [mailto:to...@strayalpha.com] 
Sent: Friday, February 2, 2018 12:56 PM
To: Susan Hares
Cc: Magnus Westerlund; Donald Eastlake; tsv-...@ietf.org; trill IETF mailing 
list; draft-ietf-trill-over-ip@ietf.org; Alia Atlas
Subject: Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10

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

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

[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  wrote:
> HI Magnus,
>
> On Tue, Jun 27, 2017 at 1:13 PM, Magnus Westerlund
>  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
>>  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 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.
>>
>>   TRILL Priority  DEI  DSCP Field (Binary/decimal)
>>   --  ---  -
>>   0   0/1  001000 / 8
>>   1   0/1  00 / 0
>>   2   0/1  01 / 16
>>   3   0/1  011000 / 24
>>   4   0/1  10 / 32
>>   5   0/1  101000 / 40
>>  

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

[Donald Eastlake]

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  
> 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 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.
>
>   TRILL Priority  DEI  DSCP Field (Binary/decimal)
>   --  ---  -
>   0   0/1  001000 / 8
>   1   0/1  00 / 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
>
> This appear to be an problematic mapping. At least for prio 0 and 1. As
> priority 1 appears to be intended to be higher than priority 0, it is
> interesting that it is mapped to CS1, which to 
> quotehttps://datatracker.ietf.org/doc/rfc7657/:
>
> CS1 ('001000') was subsequently designated as the recommended
>   codepoint for the Lower Effort (LE) PHB [RFC3662].
>
> So what is proposed can in a network using default mapping, result in that you
> ge

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

[Magnus Westerlund]

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.


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

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.







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

  TRILL Priority  DEI  DSCP Field (Binary/decimal)
  --  ---  -
  0   0/1  001000 / 8
  1   0/1  00 / 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

This appear to be an problematic mapping. At least for prio 0 and 1. As
priority 1 appears to be intended to be higher than priority 0, it is
interesting that it is mapped to CS1, which to quote
https://datatracker.ietf.org/doc/rfc7657/:

CS1 ('001000') was subsequently designated as the recommended
  codepoint for the Lower Effort (LE) PHB [RFC3662].

So what is proposed can in a network using default mapping, result in that you
get priority 0 to be lower priority than 1. Plus that in some networks this can
also results in strange remapping that results in a different PHB for CS1 than.



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

David Black provide a good answer on this.






MTU and Fragmentation
-

I think there are two main issue here. The first one is MTUD discovery
of the actual IP path MTU between the ports. That will be needed to prevent
a lot of traffi

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

[Joe Touch]

PS - the idea that TCP segments within a single connection should ever
have different DSCPs is a good example of why it's a bad idea to even
'think' of TRILL over TCP as direct encapsulation. I.e., that concept is
inherently hazardous and should be avoided.

Joe


On 6/26/2017 10:15 AM, Joe Touch wrote:
> Hi, Donald,
>
>
> On 6/25/2017 5:07 PM, Donald Eastlake wrote:
>> Hi Magnus,
>>
>> Thanks for the extensive review. See my responses below.
>>
>> On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund
>>  wrote:
>>> Reviewer: Magnus Westerlund
>>> Review result: Not Ready
>>>
>>> Early review of draft-ietf-trill-over-ip-10
>>> Reviewer: Magnus Westerlund
>>> Review result: Not Ready
>>>
>>> TSV-ART review comments:
>>>
>>> I have set this to not ready as there are several issues, some significant 
>>> that
>>> could affect the protocol realization significantly. Some may be me missing
>>> things in TRILL, I was not that familiar with it before this review and I 
>>> have
>>> only tried looking up things, not reading the whole earlier specifications. 
>>> So
>>> don't hesitate to push back and provide pointers to things that can resolve
>>> issues. The authors and the WG clearly have thought about a lot of issues 
>>> and
>>> dealt with much already.
>> OK. Hopefully we can resolve these one way or the other.
>>
>> ...
>>> TCP Encapsulation issue
>>> ---
>>>
>>> Section 5.6:
>>>
>>> The TCP encapsulation appear to be missing an delimiter format allowing each
>>> individual TRILL packet/payload to be read out of the TCP's byte stream. In
>>> other words, a normal implementation has no way of ensuring that the TCP
>>> payload starts with the start of a new TRILL payload. Multiple small TRILL
>>> payloads may be included in the same TCP payload, and also only parts as 
>>> TCP is
>>> one way of dealing with TRILL packets that are larger than the 
>>> IP+Encapsulation
>>> MTU that actually will work.
>>>
>>> This comment is based on that there appear to be no length fields included 
>>> in
>>> the TRILL header. The most straight forward delimiter is a 2-byte length 
>>> field
>>> for the TRILL payload to be encapsulated.
>> Right. It might also be useful to include some sort of check field, as
>> is done in BGP, to detect if you are out of sync in parsing the TCP
>> stream.
> There is nothing in BGP that ever assumes that TCP write boundaries are
> preserved. BGP uses markers and length fields to create message
> boundaries in TCP's bytestream. The same is needed here.
>
> Note that BGP also never claims to craft TCP packets by 'encapsulating'
> a BGP message in a TCP segment. That part of this document needs to be
> removed - it not how TCP is ever used.
>
>> Another point is that, while with UDP it seems fine to send packets
>> with assorted QoS, you don't want to encourage re-ordering of TCP
>> packets in a stream. So if TCP encapsulation is being used,
> Again - please, NO. NEVER use this term.
>
>> you want
>> to use the same DSCP value for the packets in a particular TCP stream.
> Again, this is nonsensical. TCP would set a DSCP for the connection,
> never in different ways for individual segments of a connection.
>
>
>> So, generally, you need to have a TCP connection per priority handling
>> category. Mapping the 8 priority levels into a smaller number of
>> handling categories is a normal thing to do so you certainly don't
>> necessarily need 8 TCP connections. Adding material on this should not
>> be too hard.
> Perhaps, but please - again, please - omit any mention or implication
> that this occurs via encapsulation.
>
> If you want to use TCP, please use it properly.
>
>>> Section 5.6:
>>>
>>> TCP endpoint requirements. I do wonder if an application like TRILL actual
>>> would need to discuss performance impacting implementation choices or
>>> limitations. For example use of NAGLE, the requirements on buffer sizes in
>>> relation to Bandwidth delay products, as buffer memory in a RBridge will 
>>> impact
>>> performance.
>> Well, I'm not sure how deeply this document should get into such
>> performance issues. What about just saying something about
>> consideration being given to tuning TCP for performance and pointing
>> to one or a few other RFCs that talk about this?
> Because your use of TCP (even if changed to describe it correctly) isn't
> listed in those TCP RFCs.
>
> And it's not so simple - NAGLE helps performance for interactive systems
> that use single-byte messages (e.g., telnet) and reduces the number of
> outstanding "less than full" segments. When used for encapsulation,
> turning NAGLE off is the right thing for multibyte messages (e.g., TRILL
> messages) and can avoid the "gathering" delay (200 ms stalls when there
> isn't enough source data - i.e., incoming TRILL packets - to keep up
> with the outgoing segments), but could also generate a large number of
> small segments (which can interfere with segment-based congestion
> control, vs. ABC).
>
> Unless you want a

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

[Joe Touch]

Hi, Donald,


On 6/25/2017 5:07 PM, Donald Eastlake wrote:
> Hi Magnus,
>
> Thanks for the extensive review. See my responses below.
>
> On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund
>  wrote:
>> Reviewer: Magnus Westerlund
>> Review result: Not Ready
>>
>> Early review of draft-ietf-trill-over-ip-10
>> Reviewer: Magnus Westerlund
>> Review result: Not Ready
>>
>> TSV-ART review comments:
>>
>> I have set this to not ready as there are several issues, some significant 
>> that
>> could affect the protocol realization significantly. Some may be me missing
>> things in TRILL, I was not that familiar with it before this review and I 
>> have
>> only tried looking up things, not reading the whole earlier specifications. 
>> So
>> don't hesitate to push back and provide pointers to things that can resolve
>> issues. The authors and the WG clearly have thought about a lot of issues and
>> dealt with much already.
> OK. Hopefully we can resolve these one way or the other.
>
> ...
>> TCP Encapsulation issue
>> ---
>>
>> Section 5.6:
>>
>> The TCP encapsulation appear to be missing an delimiter format allowing each
>> individual TRILL packet/payload to be read out of the TCP's byte stream. In
>> other words, a normal implementation has no way of ensuring that the TCP
>> payload starts with the start of a new TRILL payload. Multiple small TRILL
>> payloads may be included in the same TCP payload, and also only parts as TCP 
>> is
>> one way of dealing with TRILL packets that are larger than the 
>> IP+Encapsulation
>> MTU that actually will work.
>>
>> This comment is based on that there appear to be no length fields included in
>> the TRILL header. The most straight forward delimiter is a 2-byte length 
>> field
>> for the TRILL payload to be encapsulated.
> Right. It might also be useful to include some sort of check field, as
> is done in BGP, to detect if you are out of sync in parsing the TCP
> stream.

There is nothing in BGP that ever assumes that TCP write boundaries are
preserved. BGP uses markers and length fields to create message
boundaries in TCP's bytestream. The same is needed here.

Note that BGP also never claims to craft TCP packets by 'encapsulating'
a BGP message in a TCP segment. That part of this document needs to be
removed - it not how TCP is ever used.

> Another point is that, while with UDP it seems fine to send packets
> with assorted QoS, you don't want to encourage re-ordering of TCP
> packets in a stream. So if TCP encapsulation is being used,
Again - please, NO. NEVER use this term.

> you want
> to use the same DSCP value for the packets in a particular TCP stream.
Again, this is nonsensical. TCP would set a DSCP for the connection,
never in different ways for individual segments of a connection.


> So, generally, you need to have a TCP connection per priority handling
> category. Mapping the 8 priority levels into a smaller number of
> handling categories is a normal thing to do so you certainly don't
> necessarily need 8 TCP connections. Adding material on this should not
> be too hard.
Perhaps, but please - again, please - omit any mention or implication
that this occurs via encapsulation.

If you want to use TCP, please use it properly.

>
>> Section 5.6:
>>
>> TCP endpoint requirements. I do wonder if an application like TRILL actual
>> would need to discuss performance impacting implementation choices or
>> limitations. For example use of NAGLE, the requirements on buffer sizes in
>> relation to Bandwidth delay products, as buffer memory in a RBridge will 
>> impact
>> performance.
> Well, I'm not sure how deeply this document should get into such
> performance issues. What about just saying something about
> consideration being given to tuning TCP for performance and pointing
> to one or a few other RFCs that talk about this?
Because your use of TCP (even if changed to describe it correctly) isn't
listed in those TCP RFCs.

And it's not so simple - NAGLE helps performance for interactive systems
that use single-byte messages (e.g., telnet) and reduces the number of
outstanding "less than full" segments. When used for encapsulation,
turning NAGLE off is the right thing for multibyte messages (e.g., TRILL
messages) and can avoid the "gathering" delay (200 ms stalls when there
isn't enough source data - i.e., incoming TRILL packets - to keep up
with the outgoing segments), but could also generate a large number of
small segments (which can interfere with segment-based congestion
control, vs. ABC).

Unless you want a very poorly performing result, *THIS* is what you need
to drill down into.

Joe

___
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 extensive review. See my responses below.

On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund
 wrote:
>
> Reviewer: Magnus Westerlund
> Review result: Not Ready
>
> Early review of draft-ietf-trill-over-ip-10
> Reviewer: Magnus Westerlund
> Review result: Not Ready
>
> TSV-ART review comments:
>
> I have set this to not ready as there are several issues, some significant 
> that
> could affect the protocol realization significantly. Some may be me missing
> things in TRILL, I was not that familiar with it before this review and I have
> only tried looking up things, not reading the whole earlier specifications. So
> don't hesitate to push back and provide pointers to things that can resolve
> issues. The authors and the WG clearly have thought about a lot of issues and
> dealt with much already.

OK. Hopefully we can resolve these one way or the other.

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

> 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 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.
>
>   TRILL Priority  DEI  DSCP Field (Binary/decimal)
>   --  ---  -
>   0   0/1  001000 / 8
>   1   0/1  00 / 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
>
> This appear to be an problematic mapping. At least for prio 0 and 1. As
> priority 1 appears to be intended to be higher than priority 0, it is
> interesting that it is mapped to CS1, which to quote
> https://datatracker.ietf.org/doc/rfc7657/:
>
> CS1 ('001000') was subsequently designated as the recommended
>   codepoint for the Lower Effort (LE) PHB [RFC3662].
>
> So what is proposed can in a network using default mapping, result in that you
> get priority 0 to be lower priority than 1. Plus that in some networks this 
> can
> also results in strange remapping that results in a different PHB for CS1 
> than.

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

> MTU and Fragmentation
> -
>
> I think there are two main issue here. The first one is MTUD discovery
> of the actual IP path MTU between the ports. That will be needed to prevent
> a lot of traffic going into MTU black holes. Especially as TRILL requries
> 1470 byte support which is likey above a lot of paths.

Seems like it would depend on the environments where TRILL was used.
For example, I do not think 1470 would be a problem in most Data
Center or Internet Exchange point uses, for example. Data Centers
sometimes support 9K jumbo frames and the like.

In fact, it is probably bad to focus too much on 1470 -- that is a
required minimum to be sure that re

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

[Susan Hares]

Magnus: 

Thank you for the very careful review.  Please let me chat with the authors 
regarding this document.  It make take some time, but each of your points will 
be responded to by the authors. 

Sue Hares 

-Original Message-
From: Magnus Westerlund [mailto:magnus.westerl...@ericsson.com] 
Sent: Thursday, June 15, 2017 1:33 PM
To: tsv-...@ietf.org
Cc: trill@ietf.org; i...@ietf.org; draft-ietf-trill-over-ip@ietf.org
Subject: Tsvart early review of draft-ietf-trill-over-ip-10

Reviewer: Magnus Westerlund
Review result: Not Ready

Early review of draft-ietf-trill-over-ip-10
Reviewer: Magnus Westerlund
Review result: Not Ready

TSV-ART review comments:

I have set this to not ready as there are several issues, some significant that 
could affect the protocol realization significantly. Some may be me missing 
things in TRILL, I was not that familiar with it before this review and I have 
only tried looking up things, not reading the whole earlier specifications. So 
don't hesitate to push back and provide pointers to things that can resolve 
issues. The authors and the WG clearly have thought about a lot of issues and 
dealt with much already.

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.

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

  TRILL Priority  DEI  DSCP Field (Binary/decimal)
  --  ---  -
  0   0/1  001000 / 8
  1   0/1  00 / 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

This appear to be an problematic mapping. At least for prio 0 and 1. As 
priority 1 appears to be intended to be higher than priority 0, it is 
interesting that it is mapped to CS1, which to quote
https://datatracker.ietf.org/doc/rfc7657/:

CS1 ('001000') was subsequently designated as the recommended
  codepoint for the Lower Effort (LE) PHB [RFC3662].

So what is proposed can in a network using default mapping, result in that you 
get priority 0 to be lower priority than 1. Plus that in some networks this can 
also results in strange remapping that results in a different PHB for CS1 than.

MTU and Fragmentation
-

I think there are two main issue here. The first one is MTUD discovery of the 
actual IP path MTU between the ports. That will be needed to prevent a lot of 
traffic going into MTU black holes. Especially as TRILL requries
1470 byte support which is likey above a lot of paths.

Section 8.4:

   Path MTU discovery [RFC4821] should be useful
   in determining the IP MTU between a pair of RBridge ports with IP
   connectivity.

The issue with RFC4821 is that it has requirements on the packetization layer.
Trill appears to have several components that are useful. However, it will 
require a specification of the procedure to result in a useful tool.

Section 8.4:

   TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in
   [RFC7177], can be used to obtain added assurance of the MTU of a
   link.

Yes, that can confirm working MTUs that are at 1470 or above, but appears 
prevented from working below 1470?

Thus, it appears that there is a lack of mechanism here to actually get a valid 
and functional MTU from TRILL in the cases where the Path MTU is below 1470. If 
I am wrong good, but I think this is an important piece for how to handle the 
next main issue.

UDP encapsulation and IP f