Re: [mpls] 答复: 答复: MPLS WG last call on draft-ietf-mpls-in-udp-03.txt

Sriganesh Kini <sriganesh.kini@ericsson.com> Fri, 27 September 2013 23:59 UTC

Return-Path: <sriganeshkini@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A8221F92DA for <mpls@ietfa.amsl.com>; Fri, 27 Sep 2013 16:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dvv1Uz9jVAQi for <mpls@ietfa.amsl.com>; Fri, 27 Sep 2013 16:59:24 -0700 (PDT)
Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 90F6B21F9223 for <mpls@ietf.org>; Fri, 27 Sep 2013 16:59:24 -0700 (PDT)
Received: by mail-pb0-f46.google.com with SMTP id rq2so3181524pbb.19 for <mpls@ietf.org>; Fri, 27 Sep 2013 16:59:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/WZPlzTWgbn1nnCJp7VJOoYM1CCupMlOMUraV+5oQmE=; b=aeMDodC7ulugmYaswVr1F6U4EeYozfsY6NUVHl48rEDnA+UdNTr12xUr3/ROs1TuN5 3ZRgBbUBbZmq4I/8z2SHVW6JnJLj+/R7aL3Zmft9OredSwhPXtGHn4uUXUGQ/Qf4NrIo 1NzgbjoN9aSkxiwu7r5BuXwBKyZ+OdYyhRDoWrXrg7v26YWT9s/dy8t7XggxiqF72ox/ 5TeUh82gm83lj57bgQgwc6hQlbP0JJvgUX+0Kw1Qr60q7YyJAg6c9eqle8exmguEJb+i DSwsjIzvZz3AJrZU9YH115uYwjVaJIK5CMsJ0TzEgwQGZk1eVAnwDqYC2I7B8gc3m7E9 P+sQ==
X-Received: by 10.68.113.99 with SMTP id ix3mr10085663pbb.180.1380326364237; Fri, 27 Sep 2013 16:59:24 -0700 (PDT)
MIME-Version: 1.0
Sender: sriganeshkini@gmail.com
Received: by 10.70.0.225 with HTTP; Fri, 27 Sep 2013 16:58:54 -0700 (PDT)
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08211EDA@NKGEML512-MBS.china.huawei.com>
References: <98952a55996f40da8cbcb663561f580b@BLUPR05MB070.namprd05.prod.outlook.com> <CAOndX-tKDYahywihZ8fAv3MyRRUHW2=cNG+FSfkNucpcLws0tw@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08211182@NKGEML512-MBS.china.huawei.com> <CAOndX-uiMYt_m=jxhPnr6v_cDRn1ZHeDzgjBDF74-_6TUzpzgQ@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082115B5@NKGEML512-MBS.china.huawei.com> <CAOndX-v+0-=S7gxMbjHC384w_gvpNO5kNQQYNcUYwwTjD826Xw@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08211EDA@NKGEML512-MBS.china.huawei.com>
From: Sriganesh Kini <sriganesh.kini@ericsson.com>
Date: Fri, 27 Sep 2013 16:58:54 -0700
X-Google-Sender-Auth: UUJESP1hzONRlBaqVGHZ0SCBuAw
Message-ID: <CAOndX-tvVHw80w1DbYLCrbhc8jMU4tV5Zb7g3+WiDL0qP0kaTw@mail.gmail.com>
To: Xuxiaohu <xuxiaohu@huawei.com>
Content-Type: multipart/alternative; boundary="047d7b6d82dc9d5bdb04e76646d2"
Cc: Ross Callon <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "fanyb@gsta.com" <fanyb@gsta.com>
Subject: Re: [mpls] 答复: 答复: MPLS WG last call on draft-ietf-mpls-in-udp-03.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
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: <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: Fri, 27 Sep 2013 23:59:25 -0000

Xu,

The other draft I referred to was just an example to point out the
difference with draft-ietf-mpls-in-udp.

Let me re-phrase my concerns without referring to other drafts.
1. The approach uses dest UDP port number to map to a protocol identifier
(in this case, MPLS) for the user-payload. If other protocols were to
follow this approach we would be assigning a UDP port number for each such
protocol identifier. This unnecessarily consumes the UDP port number space.
Would be better to have a shim header that has a "protocol type". This
should be after the UDP header but before the user payload.
2. This draft has no text on OAM issues for this encapsulation. Even though
the UDP provides the advantage of load-balancing, how can a connectivity
check at the IP layer that follows the same path as a user-payload be
performed ? Having a shim header should allow such functions to be
incorporated.

These issues must be addressed before this is adopted as an RFC. In its
current form I do not support this draft.

- Sri



On Wed, Sep 25, 2013 at 6:37 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

>  Hi Sri,****
>
> ** **
>
> Since you don’t see how that draft (
> http://tools.ietf.org/html/draft-yong-l3vpn-nvgre-vxlan-encap-00) helps,
> I’m curious to know why you had intentionally mentioned
> draft-quinn-vxlan-gpe before. Have you found any significant difference
> between them?****
>
> ** **
>
> Best regards,****
>
> Xiaohu****
>
> ** **
>
> *发件人:* sriganeshkini@gmail.com [mailto:sriganeshkini@gmail.com] *代表 *Sriganesh
> Kini
> *发送时间:* 2013年9月26日 7:14
> *收件人:* Xuxiaohu
> *抄送:* Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org;
> fanyb@gsta.com
> *主题:* Re: [mpls] 答复: MPLS WG last call on draft-ietf-mpls-in-udp-03.txt***
> *
>
>  ** **
>
> Hi Xu,****
>
> ** **
>
> I read the other draft you pointed to and I don't see how that helps. What
> I had said earlier was that having a protocol-id in a header following the
> UDP header but before the user payload (in this draft the MPLS packet is
> the user payload) keeps the design generic and any protocol (not just MPLS
> applications) can then use such an encapsulation. Standardizing UDP port
> numbers to denote protocol types consumes the port number space and is
> unnecessary. Another important point is that developing OAM using a header
> after the UDP hdr but before the user-payload is easier.****
>
>  ****
>
> - Sri****
>
> ** **
>
> On Mon, Sep 23, 2013 at 7:00 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:****
>
> Hi Sri,****
>
>  ****
>
> It’s no problem provided that anybody was willing to use VXLAN-GPE to
> replace the existing MPLS-based applications such as L2 or L3 VPN services.
> Furthermore, there is another choice for VXLAN extension other than
> VXLAN-GPE, which has been described in
> http://tools.ietf.org/html/draft-yong-l3vpn-nvgre-vxlan-encap-00. I’m
> willing to hear your further comments on the comparison of these two
> options for VXLAN extension (Maybe MPLS WG is not a suitable place to talk
> about this topic).****
>
>  ****
>
> Xiaohu****
>
>  ****
>
> *发件人:* sriganeshkini@gmail.com [mailto:sriganeshkini@gmail.com] *代表 *Sriganesh
> Kini
> *发送时间:* 2013年9月24日 3:40
> *收件人:* Xuxiaohu
> *抄送:* Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org;
> fanyb@gsta.com
> *主题:* Re: [mpls] 答复: MPLS WG last call on draft-ietf-mpls-in-udp-03.txt***
> *
>
>  ****
>
> Hi Xu,****
>
>  ****
>
> The existing encapsulations you pointed out were defined a long time ago.
> Whereas the other two are just being proposed now. Moreover if we follow
> this approach it will require standardizing UDP port numbers for each new
> protocol to encap into UDP.****
>
>  ****
>
> - Sri****
>
>  ****
>
> On Sun, Sep 22, 2013 at 11:02 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:***
> *
>
> Hi Sri,****
>
>  ****
>
> *发件人:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *代表 *Sriganesh
> Kini
> *发送时间:* 2013年9月21日 7:06
> *收件人:* Ross Callon
> *抄送:* mpls@ietf.org; mpls-chairs@tools.ietf.org; fanyb@gsta.com
> *主题:* Re: [mpls] MPLS WG last call on draft-ietf-mpls-in-udp-03.txt****
>
>  ****
>
> There is no reference cited for the "MPLS-in-IP" encapsulation.****
>
>  ****
>
> [Xiaohu] MPLS-in-IP and MPLS-in-GRE are actually specified in the same RFC
> that is RFC4023.****
>
>  ****
>
> What is the applicability of this encapsulation compared to the
> generalized mechanism in draft-quinn-vxlan-gpe ?****
>
>  ****
>
> [Xiaohu] The applicability of this encapsulation is the same as the
> existing IP-based encapsulations for MPLS (e.g., MPLS-in-GRE).****
>
>  ****
>
> Best regards,****
>
> Xiaohu****
>
>  ****
>
> - Sri****
>
>  ****
>
> On Thu, Sep 12, 2013 at 9:42 AM, Ross Callon <rcallon@juniper.net> wrote:*
> ***
>
> Working Group,****
>
>  ****
>
> This is to start Working Group last call on  draft-ietf-mpls-in-udp-03.txt
> ****
>
>  ****
>
> Please send your comments to the mpls working group mailing list (
> mpls@ietf.org).****
>
>  ****
>
> Please send both technical comments, and (if you are happy with the
> document as is) ****
>
> also send indications of support.****
>
>  ****
>
> There is one IPR claim that applies to this draft, which can be seen at:**
> **
>
> https://datatracker.ietf.org/ipr/1941/****
>
>  ****
>
> The coauthors and contributor have indicated that they don’t know of any
> other ****
>
> IPR applicable to this draft. If anyone else in the working group is aware
> of IPR ****
>
> claims against this draft, the time to disclose that is now.****
>
>  ****
>
> This working group last call will end on September 27, 2013.****
>
>  ****
>
> Ross****
>
> for the wg co-chairs****
>
>  ****
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls****
>
>  ****
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls****
>
>  ****
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls****
>
> ** **
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>