headers
Chris Benson | 2 Jun 2010 03:16

Re: Call for WG Adoption of draft-tuexen-tsvwg-sctp-chunk-flags-00

All,

>>  "draft-tuexen-tsvwg-sctp-chunk-flags-00":

I support WG adoption.  I consider the draft already acceptable.  
I cannot promise to review a future version.

Chris Benson.

On Tue, 25 May 2010, Gorry Fairhurst wrote:

>>  Date: Tue, 25 May 2010 10:20:40 +0100
>>  From: Gorry Fairhurst <gorry <at> erg.abdn.ac.uk>
>>  To: tsvwg <tsvwg <at> ietf.org>
>>  Subject: Call for WG Adoption of draft-tuexen-tsvwg-sctp-chunk-flags-00
>>  
>>  
>>  TSVWG Please note and respond:
>>  
>>  This is a formal request asking people if they would support WG adoption of
>>  "draft-tuexen-tsvwg-sctp-chunk-flags-00":
>>  http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-chunk-flags-00
>>  
>>  If this is adopted, the WG would seek to write a standards-track document
>>  that updates RFC 4960 by defining new IANA procedure for SCTP Chunk flags
>>  and the creation of new registries.
>>  
>>  At the last IETF meeting, there was general support for this, and no notes
>>  against adopting this as a work item. This email is to confirm whether we
>>  should now adopt this with a suggested milestone of October 2010.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gorry Fairhurst | 3 Jun 2010 06:52
Picon
Picon

Re: Call for WG Adoption of draft-tuexen-tsvwg-sctp-chunk-flags-00

So I conclude that the WG appears to have consensus to proceed with this 
as a working group items.

The following people supported adoption of this work item:

i.ruengeler <at> fh-muenster.de
seggelmann <at> fh-muenster.de
vladislav.yasevich <at> hp.com
ka-cheong.poon <at> oracle.com
bidulock <at> openss7.org
cbenson <at> adax.com

Authors, please submit a new revision with the draft renamed as a 
working group item: draft-ietf-tsvwg-sctp-chunk-flags-00.

Gorry

On 25/05/2010 10:20, Gorry Fairhurst wrote:
>
> TSVWG Please note and respond:
>
> This is a formal request asking people if they would support WG adoption
> of "draft-tuexen-tsvwg-sctp-chunk-flags-00":
> http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-chunk-flags-00
>
> If this is adopted, the WG would seek to write a standards-track
> document that updates RFC 4960 by defining new IANA procedure for SCTP
> Chunk flags and the creation of new registries.
>
> At the last IETF meeting, there was general support for this, and no
(Continue reading)

Permalink | Reply | 0 comments |
headers
James M. Polk | 4 Jun 2010 01:20
Picon
Favicon

Fwd: IETF 78 - Meeting and Sponsorship Information


>78th IETF Meeting
>Maastricht, Netherlands
>July 25-30, 2010
>
>1. Sponsorship Opportunities
>2. Registration Types
>3. Visas and Letters of Invitation
>4. Accommodations & Breakfast Information
>5. IETF 79 (Beijing) Visa Information
>
>1) Sponsorship Opportunities
>There are still sponsorship opportunities and benefits for high 
>profile company/organizational exposure at the upcoming IETF meeting 
>in Maastricht, Netherlands from July 25-30, 2010.  All sponsorship 
>fees go directly to fund the operations of the IETF.  See the 
>options at: http://www.ietf.org/meeting/78/index.html "Sponsorship 
>Opportunities" under "General".  Each of the sponsorship options 
>provide extended and repeat exposure at this weeklong meeting.
>
>Please contact Drew Dvorshak, dvorshak <at> isoc.org, with any questions 
>and/or to reserve your organization's spot.  Thanks in advance for 
>supporting the critical work of the IETF!
>
>2) Register online at:  http://www.ietf.org/meetings/78/
>
>3) Letters of Invitation and Visas
>Letters of Invitation
>After you complete the meeting registration process, you will be 
>given the option to request a letter of invitation. You can request
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 6 Jun 2010 21:45
Picon
Favicon

I-D Action:draft-ietf-tsvwg-sctp-chunk-flags-00.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           : Stream Control Transmission Protocol (SCTP) Chunk Flags Registration
	Author(s)       : M. Tuexen, R. Stewart
	Filename        : draft-ietf-tsvwg-sctp-chunk-flags-00.txt
	Pages           : 8
	Date            : 2010-06-06

The current definition of the Stream Control Transmission Protocol
(SCTP) is missing a procedure for registering chunk flags for already
defined chunk types.  This document defines this procedure.  It does
not change SCTP in any other way.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-chunk-flags-00.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-tsvwg-sctp-chunk-flags-00.txt): message/external-body, 70 bytes
Permalink | Reply | 0 comments |
headers
Gorry Fairhurst | 7 Jun 2010 14:51
Picon
Picon

TSVWG Status for 7th June 2010


The email below gives a brief snapshot of the current WG status for June.

There are a few individual drafts that have been around for a while,
and it would be good to receive comments on this list.

We look forward to more discussions on the list,

Gorry & James
(TSVWG Chairs)

==================================================================

Published

   RFC 5865 draft-ietf-tsvwg-admitted-realtime-dscp-07

------------------------------------------------------------------
IDs in RFC Editor Queue

  draft-ietf-tsvwg-emergency-rsvp
     Norm. ref to router alert draft (in the INT-area WG)

  draft-ietf-tsvwg-rsvp-proxy-approaches

  draft-ietf-tsvwg-rsvp-proxy-proto

------------------------------------------------------------------
IDs in IESG processing
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael H. Behringer | 7 Jun 2010 16:56
Picon
Favicon

Re: TSVWG Status for 7th June 2010

On 07/06/2010 14:51, "Gorry Fairhurst" <gorry <at> erg.abdn.ac.uk> wrote:
[....]
> WG Drafts
> 
>   draft-ietf-tsvwg-rsvp-security-groupkeying
>      SECDIR review comments, and WGLC completed.
>      New revision expected.
>      Short WGLC needed to confirm new text.
>      Editors need to respond.
>    James is Shepherd.

Gorry, James, 

Please apologise for the delay in getting a new version out. Expect an
update before the IETF.

Thanks for your patience!
Michael
Permalink | Reply | 0 comments |
headers
Lars Eggert | 17 Jun 2010 05:39
Picon
Gravatar

Re: I-D Action:draft-ietf-tsvwg-iana-ports-06.txt

Hi,

On 2010-5-26, at 23:54, Eggert Lars (Nokia-NRC/Espoo) wrote:
> We editors believe that this revision addresses all comments we have received so far, and it's basically
ready for WGLC. If you have commented on this draft in the past, please let us know if we have addressed the
issue you have raised.

I have not seen any comments on -06. I would like to think that this is because everyone agrees we can ask the
chairs to start WG last call on the document...

Lars
Attachment (smime.p7s): application/pkcs7-signature, 3815 bytes
Permalink | Reply | 0 comments |
headers
Randall Stewart | 17 Jun 2010 15:27

Re: sctp multihoming heartbeat behavior


In-line

On Jun 17, 2010, at 8:54 AM, Harendra Pratap Singh wrote:

> Hi All,
>
> I have a query regarding sctp multihoming behavior.
>
> I have setup a multi-homed association and this is my observation
>
> Host_A (IP a(Primary), IP b(secondary)):): Local MultiHomed endpoint
>
> Host_B (IP c(Primary), IP d(secondary)): Remote multiHomed endpoint
>
> During Heartbeat I see that even though the Heart beat request is  
> sent to the secondary
> ip of Host_B from primary ip of host_A, the Host_B uses its primary  
> ip as source when sending back the
> Heartbeat Ack.
> I.e. Host_A (IP a) --------HEART_BEAT_REQ-----------> Host_B(IP d)
>      Host_A (IP a)<--------- HEART_BEAT_ACK---------- Host_B(IP c)
>
> 1. Is this the expected behavior, shouldn't the node use the same ip  
> on which it
> received the Heart_beat_req on while sending back the  
> response(Heart_beat_ack)?

The recommended behavior is you SHOULD send back to the destination that
sent you the HB.. i.e. send back to IP a. This does NOT speak to what
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kiss, Zoltan (NSN - HU/Budapest | 17 Jun 2010 18:07

RE: sctp multihoming heartbeat behavior

Sorry, I didn't noticed, that Harendra sent the message to a wrong email address :)

__________________________________

Hi,

1. This is not the expected behaviour, but happens frequently. The reason for this that Host_B's IP routing
table says IP_a is accesible through IP_c, so it overwrites the the SCTP layer's wish about source IP (if
any). A solution for this could be policy based routing, under Linux, you can specify source based routing
rules there.
2. Yes, it can. But as I see it's a regular practice in the real networks that both endpoint has two IP (a
primary and a secondary), and primary IP's and secondary IP's can reach only each other, and a
primary-secondary connection is not possible. In your case a failure of IP_a doesn't mean necessarily an
association break. If IP_b and IP_d can reach each other, the association will work. But you have to
configure on both side the routing properly, so IP_d should be accesible through IP_b in the primary, and
vice versa.
3. No, the endpoint could receive packets in every configured IP.

Regards,

Kiss Zoltán 

______________________________

From: ext Harendra Pratap Singh [mailto:harendra.singh <at> globallogic.com] 
Sent: Thursday, June 17, 2010 2:54 PM
To: tsvwg-request <at> ietf.org; Randy Stewart; Kiss, Zoltan (NSN - HU/Budapest)
Subject: sctp multihoming heartbeat behavior

Hi All,
(Continue reading)

Permalink | Reply | 0 comments |
headers
RFC Errata System | 21 Jun 2010 16:31
Favicon

[Editorial Errata Reported] RFC3168 (2307)


The following errata report has been submitted for RFC3168,
"The Addition of Explicit Congestion Notification (ECN) to IP".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3168&eid=2307

--------------------------------------
Type: Editorial
Reported by: Nikolai Malykh <nmalykh <at> protocols.ru>

Section: 6.1

Original Text
-------------
   This proposal specifies two new flags in the Reserved field of the
   TCP header.  The TCP mechanism for negotiating ECN-Capability uses
   the ECN-Echo (ECE) flag in the TCP header.  Bit 9 in the Reserved
   field of the TCP header is designated as the ECN-Echo flag.  The
   location of the 6-bit Reserved field in the TCP header is shown in
   Figure 4 of RFC 793 [RFC793] (and is reproduced below for
   completeness).  This specification of the ECN Field leaves the
   Reserved field as a 4-bit field using bits 4-7.

Corrected Text
--------------
   This proposal specifies two new flags in the Reserved field of the
   TCP header.  The TCP mechanism for negotiating ECN-Capability uses
   the ECN-Echo (ECE) flag in the TCP header.  Bit 9 in the Reserved
(Continue reading)

Permalink | Reply | 1 comment |

Gmane