Linda Dunbar | 4 Feb 18:22 2016

review comments to draft-ietf-tsvwg-circuit-breaker-11

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments.

 

Major issue with the proposed approach:

 

Traffic continuously go from Ingress and egress.

If the Ingress and egress nodes don’t  have synchronized timers as SONET/SDH (most packet routers/switches don’t have synchronized timer), the meters collected by both ends can’t be correlated  properly (i.e. they are meaningless).

 

The only ways for the meters on both Ingress and Egress to work reliably (without synchronized timer) is via ECN, or via synthetic data (like IPPM).

 

For “Circuit Breaker based on RTP”, DPI has to be deployed to detect RTP if the Ingress and egress nodes are the end points of tunnel (i.e. aggregated traffic). The approach is very expensive.

 

Minor issue:

Typos:

 

-        Page 5: The  paragraph before 1.1:

“Circuit Breaker has in fact being tripped”: do you mean “being triggered”?

 

 

Regards, Linda Dunbar

 

Barry Leiba | 3 Feb 20:06 2016
Picon
Gravatar

Barry Leiba's No Objection on draft-ietf-tsvwg-sctp-failover-15: (with COMMENT)

Barry Leiba has entered the following ballot position for
draft-ietf-tsvwg-sctp-failover-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In addition to the 2119 issues that Ben has raised...

In Section 3.2 bullet 1:

        The RECOMMENDED value of PFMR is
        0, but other values MAY be used.

"SHOULD do X, but MAY do Y" makes no sense.  In this case, you can
(should) just remove "but other values MAY be used".  You might instead
say *why* 0 is recommended at a 2119 level (implying that it has
interoperability implications).

In bullet 9, I found this to be oddly worded:

        A SCTP sender MAY clear the error counter
        and move a destination address back to active state if it has
        other information, than the acknowledgment, that uniquely
        determines which destination, among multiple destination
        addresses, the chunk reached.

Perhaps this?:

NEW
        A SCTP sender MAY clear the error counter
        and move a destination address back to active state if it has
        information other than the acknowledgment that uniquely
        determines which destination, among multiple destination
        addresses, the chunk reached.
END

Stephen Farrell | 3 Feb 14:41 2016
Picon
Picon

Stephen Farrell's No Objection on draft-ietf-tsvwg-sctp-failover-15: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-tsvwg-sctp-failover-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for a clearly written specification.

- Should this formally UPDATE 4960? I don't care but some
might:-) If you want new SCTP implementations to include
this then adding the UPDATES may make sense.

- 3.2, step 9: Just wondering: is this still true even if
the implementation knows that the ack was received from a
destination address that is currently in the PF state?
(Say if all destination addresses are on different
interfaces, and I can see on which interface I rx'd the
ack, and that maps 1:1 with a destination address in the PF
state.)

Ben Campbell | 2 Feb 23:56 2016

Ben Campbell's No Objection on draft-ietf-tsvwg-sctp-failover-15: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-tsvwg-sctp-failover-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 3.2: Since PMR is allowed to be greater than zero, there is the
potential to have a non-zero error count but not yet have entered the
potentially failed state. Did I miss guidance on when the error count
might be reset under those conditions? (I found guidance for when in the
potentially failed state.)

-3.2, 4:
The paragraph says the sender MUST follow the following rules, but both
of those rules just say SHOULD. I'm not sure what that means. 

- 3.2, 7: "sender SHOULD clear the error counter"
Why not MUST?

- 4, 3rd paragraph: "handling SHOULD NOT
   be coupled"
Why not MUST?

- 6: The recommended value for PFMR is redundant with an earlier
section.

Editorial:

- There are a number of places where paragraphs are put into long
numbered lists for no apparent reason. Could those not just be normal
paragraphs?  As it is, I keep getting section numbers and paragraph
numbers confused.

- 3.2, 3.ii:"...the sender thus by [RFC4960], section 6.4.1, should
attempt..."

The wording is confusion. I think you mean something to the effect of
"According to [RFC4960] section 6.4.1, when the sender retransmits data
that has timed out, it should attempt..." 

- 3.2, 4, last paragraph:
The current wording can be interpreted ambiguously. I think you mean the
following:
OLD
  The sender MUST NOT change the state and the error counter of
   any destination address regardless of whether it has been chosen
   for transmission or not.
NEW
  The sender MUST NOT change the state and the error counter of
   any destination address simply because it has been chosen for
   transmission.
END

- 6:
RECOMMENDATIONS should not be capitalized.

-7: The section says it's informational. Does that include child
sections? I found at least one 2119 MAY at te end of 7.2.

Benoit Claise | 2 Feb 22:42 2016
Picon

Benoit Claise's No Objection on draft-ietf-tsvwg-sctp-failover-15: (with COMMENT)

Benoit Claise has entered the following ballot position for
draft-ietf-tsvwg-sctp-failover-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

As discussed by Jürgen Schönwäder (part of this OPS DIR review) and the
authors.

Jürgen: Since the I-D introduces the new state Potentially Failed, does
this
  imply that an update of the SCTP-MIB [RFC3873] (sctpAssocState) is
  needed as well? Are there additional MIB objects to report, e.g.,
  spt_pathpfthld and spt_pathcpthld? I see some additional SCTP
  related docs in TSVWG and perhaps after they have been completed an
  update of the SCTP-MIB would make sense to consider.

Yoshifumi Nishida: I think it makes senses to update MIB. We'll check
with implementors and other experts. 
Thanks for pointing it out. 

Ideally, you should add a sentence or two expressing that RFC3873 should
be updated to support this functionality with a few objects that ...

Lloyd Wood | 30 Jan 20:34 2016
Picon

Re: : Q: transport recommendations for "routing protocols"

Toeless,
To me, "message exchange" is at a higher layer than exchanging binary frames. It's XML interaction or better.
If I understand you right, you want your own messaging, but you don't want to have to reinvent transport and reliable message delivery. But you'll still have to reinvent the messaging stack above that. Good luck with that.

CoAP translates to http rather like WAP did, with binary substitution and proxying to http; limited binary http equivalence is of limited use. As such, it might do as well longterm as WAP did. Adopting http as much as possible makes more sense to me longterm, and that's what we were suggesting with http-dtn.
Lloyd Wood 


----- Original Message -----
From: Toerless Eckert <eckert <at> cisco.com>
To: lloyd.wood <at> yahoo.co.uk
Sent: Saturday, 30 January 2016, 11:47
Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols"

Thanks, Lloyd, but i was rather trying to avoid some undesired
layer on top of TCP/SCTP. Rather continue my own choice of (reliable)
message exchanges. Maybe i do not understand well why i need to
be interested in http-dtn... Can you maybe rephrase ?

Cheers
    Toerless

On Fri, Jan 29, 2016 at 05:24:26AM +0000, lloyd.wood <at> yahoo.co.uk wrote:
> > And then the IOT space says TCP is bad, use CoAP, but then i don't even
> > have messagee exchanges anymore but put would ahve to reinvent it on top
> > of something like PUT/GET primitives... ? *sigh*
>
> I know.
>
> That's why we came up with http-dtn.
>
> http://http-dtn.sourceforge.net/
>
> Then you could do RESTful exchanges, M2M with SOAP etc., on top of HTTP/TCP.

> Lloyd Wood lloyd.wood <at> yahoo.co.uk http://about.me/lloydwood
>
>
>
>
> ________________________________
> From: Toerless Eckert <eckert <at> cisco.com>
> To: tsvwg <at> ietf.org
> Sent: Thursday, 28 January 2016, 10:36
> Subject: [tsvwg] : Q: transport recommendations for "routing protocols"
>
>
> Are there any drats/RFC that would give me guidance if i wanted to design
> packet exchanges hop-by-hop between eg: routers/switches, with traffic
> patterns lets say like a routing protocol.
>
> I see even new protocols like Babel run on top of datagram and have
> all their own retransmission/ultimate-consistency schemes, and i was
> wondering what opinions TSVWG has about this.
>
> Or let me turn this around: I'd rather like to build a protocol that
> just uses hop-by-hop TCP and not reinvent all the transport aspects
> that go along with that (including remote adjacencies/tunnels across stupidly
> bad internet adjacencies with jitter and loss). But the ongoing reality of
> protocols like this does not seem to indicate that there's any evolving
> wisdom that this would be a good thing.
>
> And then the IOT space says TCP is bad, use CoAP, but then i don't even
> have messagee exchanges anymore but put would ahve to reinvent it on top
> of something like PUT/GET primitives... ? *sigh*
>
> So, really wondering.
>
> Thanks!

>    Toerless

--
---
Toerless Eckert, eckert <at> cisco.com
lloyd.wood | 30 Jan 07:08 2016
Picon

Re: : Q: transport recommendations for "routing protocols"

To me, "message exchange" is at a higher layer than exchanging 
binary frames. It's XML interaction or better. 

If I understand you right, you want your own messaging, but 
you don't want to have to reinvent transport and reliable 
message delivery. But you'll still have to reinvent the messaging 
stack above that. Good luck with that. 

CoAP translates to http rather like WAP did, with binary 
substitution and proxying to http; limited binary 
http equivalence is of limited use. Adopting http as much 
as possible makes more sense to me longterm.

 Lloyd Wood lloyd.wood <at> yahoo.co.uk http://about.me/lloydwood 

----- Original Message -----
From: Toerless Eckert <eckert <at> cisco.com>
To: lloyd.wood <at> yahoo.co.uk
Sent: Saturday, 30 January 2016, 11:47
Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols"

Thanks, Lloyd, but i was rather trying to avoid some undesired
layer on top of TCP/SCTP. Rather continue my own choice of (reliable)
message exchanges. Maybe i do not understand well why i need to
be interested in http-dtn... Can you maybe rephrase ?

Cheers
    Toerless

On Fri, Jan 29, 2016 at 05:24:26AM +0000, lloyd.wood <at> yahoo.co.uk wrote:
> > And then the IOT space says TCP is bad, use CoAP, but then i don't even 
> > have messagee exchanges anymore but put would ahve to reinvent it on top 
> > of something like PUT/GET primitives... ? *sigh*
> 
> I know.
> 
> That's why we came up with http-dtn.
> 
> http://http-dtn.sourceforge.net/
> 
> Then you could do RESTful exchanges, M2M with SOAP etc., on top of HTTP/TCP.
>  
> Lloyd Wood lloyd.wood <at> yahoo.co.uk http://about.me/lloydwood 
> 
> 
> 
> 
> ________________________________
> From: Toerless Eckert <eckert <at> cisco.com>
> To: tsvwg <at> ietf.org 
> Sent: Thursday, 28 January 2016, 10:36
> Subject: [tsvwg] : Q: transport recommendations for "routing protocols"
> 
> 
> Are there any drats/RFC that would give me guidance if i wanted to design
> packet exchanges hop-by-hop between eg: routers/switches, with traffic
> patterns lets say like a routing protocol.
> 
> I see even new protocols like Babel run on top of datagram and have
> all their own retransmission/ultimate-consistency schemes, and i was
> wondering what opinions TSVWG has about this.
> 
> Or let me turn this around: I'd rather like to build a protocol that
> just uses hop-by-hop TCP and not reinvent all the transport aspects
> that go along with that (including remote adjacencies/tunnels across stupidly
> bad internet adjacencies with jitter and loss). But the ongoing reality of
> protocols like this does not seem to indicate that there's any evolving
> wisdom that this would be a good thing.
> 
> And then the IOT space says TCP is bad, use CoAP, but then i don't even
> have messagee exchanges anymore but put would ahve to reinvent it on top
> of something like PUT/GET primitives... ? *sigh*
> 
> So, really wondering.
> 
> Thanks!

>     Toerless

--

-- 
---
Toerless Eckert, eckert <at> cisco.com

Lucy yong | 29 Jan 00:41 2016

FW: I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-09.txt

Hi All,

This version has quite editing changes which were suggested by the chair (David Black) and better aligns
with 5405bis. The draft specifies gre/udp tunnel usage in two environments: general Internet and
well-managed operator network (WMON), and names the two applications as Default GRE-in-UDP Tunnel and
WMON GRE-in-UDP Tunnel, respectively. It specifies the requirements for each type of tunnels. 

The draft further defines a well-managed operator network as of an IP network that is traffic-engineered
and/or otherwise
managed (e.g., via use of traffic rate limiters) to avoid congestion. Under a well-managed operator
network, a gre/udp tunnel is less restrictive comparing to be used in general Internet.

The draft has addressed all comments from the meetings and mails. One caviar is:

Use of UDP src port for entropy may impact with middlebox behavior (see draft). To address this conflict,
the draft recommends:

   If a GRE-in-UDP tunnel is expected to pass a middlebox, to avoid the
   impact, the operator either disable UDP source port for entropy or
   configure the middlebox to deal with the UDP source port variation.

This operation can be done easily for a well-managed operator network. Maybe hard in general Internet.
Like to get the community feedback if this will be a concern or not. If yes, what is the better alternative?

We like to thank David Black a lot for the detail review and suggestions. 

Thanks,
Lucy








-----Original Message-----
From: tsvwg [mailto:tsvwg-bounces <at> ietf.org] On Behalf Of internet-drafts <at> ietf.org
Sent: Tuesday, January 26, 2016 7:49 PM
To: i-d-announce <at> ietf.org
Cc: tsvwg <at> ietf.org
Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-09.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Area Working Group Working Group of the IETF.

        Title           : GRE-in-UDP Encapsulation
        Authors         : Edward Crabbe
                          Lucy Yong
                          Xiaohu Xu
                          Tom Herbert
	Filename        : draft-ietf-tsvwg-gre-in-udp-encap-09.txt
	Pages           : 24
	Date            : 2016-01-26

Abstract:
   This document describes a method of encapsulating network protocol
   packets within GRE and UDP headers. In this encapsulation, the
   source UDP port can be used as an entropy field for purposes of load
   balancing, while the protocol of the encapsulated packet in the GRE
   payload is identified by the GRE Protocol Type. This document
   specifies requirements for two applicability scenarios for this
   encapsulation: (1) General Internet and (2) well-managed operator
   networks; less restrictive requirements apply to the latter scenario
   by comparison to the former.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/


There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-09


A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-gre-in-udp-encap-09



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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

IETF Secretariat | 28 Jan 16:47 2016
Picon

Milestones changed for tsvwg WG

Changed milestone "Submit 'Behavioral Requirements Updates'’ as a BCP
RFC", resolved as "Done".

URL: https://datatracker.ietf.org/wg/tsvwg/charter/

Black, David | 28 Jan 16:42 2016

TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12 - ends Feb 13

This email announces a TSVWG Working Group Last Call (WGLC) on:

             DSCP and other packet markings for WebRTC QoS
                     draft-ietf-tsvwg-rtcweb-qos-12

This WGLC will be for about 2 weeks, ending at midnight US Eastern Time on
Saturday, February 13.  Comments should be sent to the tsvwg <at> ietf.org
list, although purely editorial comments may be sent directly to the authors
at draft-ietf-tsvwg-rtcweb-qos <at> ietf.org - if doing that, please cc: the WG chairs
at tsvwg-chairs <at> ietf.org.  The WG chairs express our thanks to Michael Tuexen
for recently reviewing the SCTP aspects of this draft.

The related transports draft in the rtcweb WG (draft-ietf-rtcweb-transports-11)
has recently been updated for consistency with this TSVWG rtcweb-qos draft,
so it's important that only the latest version of that rtcweb-transports draft be
consulted for the WGLC on this tsvwg-rtcweb-qos draft.

Thanks, --David & Gorry
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953     Cell: +1 (978) 394-7754
david.black <at> emc.com        
----------------------------------------------------

Toerless Eckert | 28 Jan 00:36 2016
Picon

: Q: transport recommendations for "routing protocols"

Are there any drats/RFC that would give me guidance if i wanted to design
packet exchanges hop-by-hop between eg: routers/switches, with traffic
patterns lets say like a routing protocol.

I see even new protocols like Babel run on top of datagram and have
all their own retransmission/ultimate-consistency schemes, and i was
wondering what opinions TSVWG has about this.

Or let me turn this around: I'd rather like to build a protocol that
just uses hop-by-hop TCP and not reinvent all the transport aspects
that go along with that (including remote adjacencies/tunnels across stupidly
bad internet adjacencies with jitter and loss). But the ongoing reality of
protocols like this does not seem to indicate that there's any evolving
wisdom that this would be a good thing.

And then the IOT space says TCP is bad, use CoAP, but then i don't even
have messagee exchanges anymore but put would ahve to reinvent it on top
of something like PUT/GET primitives... ? *sigh*

So, really wondering.

Thanks!
    Toerless


Gmane