Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

Curtis Villamizar <curtis@ipv6.occnc.com> Sat, 25 January 2014 20:35 UTC

Return-Path: <curtis@ipv6.occnc.com>
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 EC4121A0040 for <mpls@ietfa.amsl.com>; Sat, 25 Jan 2014 12:35:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level:
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-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 yZMJ9-98IHEZ for <mpls@ietfa.amsl.com>; Sat, 25 Jan 2014 12:35:02 -0800 (PST)
Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 431401A0027 for <mpls@ietf.org>; Sat, 25 Jan 2014 12:35:02 -0800 (PST)
Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0PKYrAF048759; Sat, 25 Jan 2014 15:34:53 -0500 (EST) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201401252034.s0PKYrAF048759@maildrop2.v6ds.occnc.com>
To: Xuxiaohu <xuxiaohu@huawei.com>
From: Curtis Villamizar <curtis@ipv6.occnc.com>
In-reply-to: Your message of "Fri, 24 Jan 2014 02:42:06 +0000." <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082478FD@NKGEML512-MBS.china.huawei.com>
Date: Sat, 25 Jan 2014 15:34:53 -0500
Cc: "joelja@bogus.com" <joelja@bogus.com>, "mpls@ietf.org" <mpls@ietf.org>, "lars@netapp.com" <lars@netapp.com>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: curtis@ipv6.occnc.com
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: <http://www.ietf.org/mail-archive/web/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, 25 Jan 2014 20:35:04 -0000

In message <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082478FD@NKGEML512-MBS.china.huawei.com>
Xuxiaohu writes:
> > 
> > I am not against the bulk of RFC6936. But unlike '36,
> > RFC6935 is very much written for the benefit of tunnelers.
> > 
> > RFC6935 and 36 can be read to give conflicting advice (35 - zero!
> > 36 - um, that leads to these subtle and nuanced prroblems, so maybe not), so
> > just referring to them and leaving the implementer without clear
> > direction is not sufficient imo.
>  
> If so, wouldn't it be better to solve such confliction and confusion
> caused by 6935 and 6936 by updating them? Since these two drafts are
> originated from the TSV WG, it should represent the rogue WG consensus
> instead of making confusion to others.
>  
> Best regards,
> Xiaohu 


I believe you meant "rough" but perhaps "rogue" works too.  :-)

Curtis