[mpls] Fwd: [Teas] status of draft-ietf-teas-rsvp-ingress-protection

Loa Andersson <loa@pi.nu> Sat, 30 January 2016 12:19 UTC

Return-Path: <loa@pi.nu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138F61A1A5A for <mpls@ietfa.amsl.com>; Sat, 30 Jan 2016 04:19:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcPv1pmKlPvT for <mpls@ietfa.amsl.com>; Sat, 30 Jan 2016 04:18:59 -0800 (PST)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BFCE1A1A58 for <mpls@ietf.org>; Sat, 30 Jan 2016 04:18:58 -0800 (PST)
Received: from [192.168.1.13] (unknown [49.149.162.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 114D418013CB for <mpls@ietf.org>; Sat, 30 Jan 2016 13:18:55 +0100 (CET)
References: <56AB96E6.8030503@labn.net>
To: "mpls@ietf.org" <mpls@ietf.org>
From: Loa Andersson <loa@pi.nu>
X-Forwarded-Message-Id: <56AB96E6.8030503@labn.net>
Message-ID: <56ACAA24.4090300@pi.nu>
Date: Sat, 30 Jan 2016 20:18:44 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56AB96E6.8030503@labn.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/gE6zcw3cmcdIpaHzoZAcSweluG8>
Subject: [mpls] Fwd: [Teas] status of draft-ietf-teas-rsvp-ingress-protection
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jan 2016 12:19:01 -0000

Working Group,

draft-ietf-teas-rsvp-ingress-protection was one of the documents that
was moved to the teas working from mpls, when teas wg was created.

teas had an interim on Thursday (Jan 28) to discuss how to progress
the draft. The mail from the teas chairs below is the teas chairs
summary after that meeting.

Take discussion, comments and questions, both on the draft itself and
the approach Lou and Pavan outline to the teas working group list.

/Loa



-------- Forwarded Message --------
Subject: [Teas] status of draft-ietf-teas-rsvp-ingress-protection
Date: Fri, 29 Jan 2016 11:44:22 -0500
From: Lou Berger <lberger@labn.net>
To: TEAS WG <teas@ietf.org>
CC: TEAS WG Chairs <teas-chairs@ietf.org>, BRUNGARD, DEBORAH A (ATTLABS) 
<db3546@att.com>

All,
    Based on yesterday's interim as well as input we have received, both 
on and off list, we have concluded that there is interest in ensuring 
that a particular problem is documented and that there may be multiple 
possible solutions to this problem.  We also conclude that there is not 
support for new Standards Track mechanisms *at this time*.  We'd like to 
propose the following:

1) The -03 rev of the draft serve as the foundation for the next rev, as 
the -04 version doesn't represent any WG consensus.  And that this rev 
have 'Experimental' listed as its intended status.

For those who really want a PS, we'd like to remind you that the WG can 
revisit this at a later time, even after publication.  See rfc5467 as an 
example of work that went through a similar evolution and then was 
eventually replaced by a PS in rfc6387.

2) That the WG* agree on a brief (say 1-2 page) description of the 
problem to be solved.

This should be discussed on list and eventually captured in a draft of 
the Author's choosing - which may or may not be an existing one. Adding 
information on any real-world experience would be very useful.

* - WG includes authors+anyone else who wishes to contribute, e.g., 
Adrian has volunteered to help.

3) That draft-ietf-teas-rsvp-ingress-protection be updated with a brief 
summary of why existing RFC documented mechanisms don't address the 
problem.  Authors should lead this update, but all WG participants 
should feel free to contribute.

4) That draft-ietf-teas-rsvp-ingress-protection be updated with a brief 
summary of what other non-standard mechanisms have been considered as 
possible solutions and why they were rejected. Authors should lead this 
update, but all WG participants should feel free to contribute.

We believe these steps move us beyond the state represented by the -04 
rev of this document and balances the various views that have been 
expressed.  These steps should not be viewed as representing any 
departure from future normal WG processing of this draft, including 
anticipated refinement, review and, when ready, LC.

Please feel free to discuss as you may see appropriate.  If your comment 
relates to this document's process, please respond to this message.  If 
your comment is technical, please start a new thread.

Thank you,
Pavan and Lou



_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64