Subject: Re: [Tsvwg] New Version: draft-ietf-tsvwg-ecn-tunnel-01

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 10 Nov 2008 09:57:04 +0100

Hi Bob,

I support making the behaviour proposed by your draft as standards track to be put on that track.

You further propose a slightly different tunnel marking behaviour in Appendix C. The Appendix C 
behaviour should at least be put on informational track (however I will not object against putting 
Appendix C behaviour on standards track).

Further, you suggest to have a separate informational document discussing general L2 tunnel issues
(Ethernet, MPLS and others). I favour this split, as I hope this split will speed up progress of 
the standards track content (and that of Appendix C).

Regards, Rudiger

Please note, that I won't respond to emails from 11. November until 20. November.

------- Original message posted by Bob Briscoe ---------------
Hi,

As of a couple of weeks ago, this became a tsvwg wg item. I posted an -00 then, but I've just posted a corrected -01.

I'd appreciate review comments as this is effectively a (minor) change to IP forwarding, so there could be weird dependencies I've not thought of (I've tried my hardest to make sure there aren't).

The top level questions I'd like to pose for reviewers are:

Q1. I've convinced myself no harm to any existing mechanisms would result if I made the proposed new decapsualtion behaviour in Appendix C normative for standards track. Do you agree? Have I missed anything?

Q2. I'm planning on splitting this into two docs as it's trying to cover two different scopes:

1/ Stand's track: define specific changes to IP in IP tunnelling of ECN

2/ Informational: give guidelines on how to design encapsulation of congestion notification by general L2 protocols (e.g. Ethernet etc).

As it stands, a reader in a hurry could mistake guidelines for encapsulating IP in ethernet etc as instructions for how to implement standard IP in IP tunnelling. Do people agree I should avoid having two different scopes in the same doc?

Cheers

Bob

    From: IETF I-D Submission Tool <idsubmission at ietf.org>
    To: <bob.briscoe at bt.com>
    Subject: New Version Notification for draft-ietf-tsvwg-ecn-tunnel-01
    Date: Mon, 27 Oct 2008 11:05:28 -0700

    X-OriginalArrivalTime: 27 Oct 2008 18:05:35.0563 (UTC) FILETIME=[9C35E9B0:01C9385E]

    X-Spam-Score: 0 ()
    X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158

    A new version of I-D, draft-ietf-tsvwg-ecn-tunnel-01.txt has been successfuly submitted by Bob Briscoe and posted to the IETF repository.

    Filename:       draft-ietf-tsvwg-ecn-tunnel
    Revision:       01
    Title:          Layered Encapsulation of Congestion Notification
    Creation_date:  2008-10-27
    WG ID:          tsvwg
    Number_of_pages: 37

    Abstract:
    This document redefines how the explicit congestion notification
    (ECN) field of the outer IP header of a tunnel should be constructed.
    It brings all IP in IP tunnels (v4 or v6) into line with the way
    IPsec tunnels now construct the ECN field.  It includes a thorough
    analysis of the reasoning for this change and the implications.  It
    also gives guidelines on the encapsulation of IP congestion
    notification by any outer header, whether encapsulated in an IP
    tunnel or in a lower layer header.  Following these guidelines should
    help interworking, if the IETF or other standards bodies specify any
    new encapsulation of congestion notification.

    The IETF Secretariat.

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 10 Nov 2008 12:49:37 +0000

Ruediger,

>Appendix C behaviour on standards track).

I've decided to ask to put Appx C on the stds track for the next rev, 
as I've realised it proposes a change to a behaviour that no other 
standard relies on, and as far as I can work out, no app can ever 
have relied on it as it was, so there will be no harm changing it.

If I didn't put Appx C on the stds track, I'd go for experimental 
track (not informational) because it's a protocol behaviour change.

Thanks for your comments.

Cheers

Bob

>As of a couple of weeks ago, this became a tsvwg wg item. I posted 
>an -00 then, but I've just posted a corrected -01.
>
>I'd appreciate review comments as this is effectively a (minor) 
>change to IP forwarding, so there could be weird dependencies I've 
>not thought of (I've tried my hardest to make sure there aren't).
>
>Q1. I've convinced myself no harm to any existing mechanisms would 
>result if I made the proposed new decapsualtion behaviour in 
>Appendix C normative for standards track. Do you agree? Have I missed anything?
>
>2/ Informational: give guidelines on how to design encapsulation of 
>congestion notification by general L2 protocols (e.g. Ethernet etc).
>
>As it stands, a reader in a hurry could mistake guidelines for 
>encapsulating IP in ethernet etc as instructions for how to 
>implement standard IP in IP tunnelling. Do people agree I should 
>avoid having two different scopes in the same doc?
>
>Cheers
>
>
>
>Bob
>
>
>     A new version of I-D, draft-ietf-tsvwg-ecn-tunnel-01.txt has 
> been successfuly submitted by Bob Briscoe and posted to the IETF repository.
>

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196