Re: [mpls] [nvo3] Encapsulation considerations

Xuxiaohu <xuxiaohu@huawei.com> Wed, 08 April 2015 03:01 UTC

Return-Path: <xuxiaohu@huawei.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 ADDCF1B2C15; Tue, 7 Apr 2015 20:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.761
X-Spam-Level:
X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 j7LhjUvxnwpH; Tue, 7 Apr 2015 20:01:21 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65DB11B2C14; Tue, 7 Apr 2015 20:01:20 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRD56760; Wed, 08 Apr 2015 03:01:18 +0000 (GMT)
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Apr 2015 04:01:17 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 8 Apr 2015 11:01:09 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Xuxiaohu <xuxiaohu@huawei.com>, 'Erik Nordmark' <nordmark@sonic.net>, "nvo3@ietf.org" <nvo3@ietf.org>
Thread-Topic: Re: [nvo3] Encapsulation considerations
Thread-Index: AdBxodagEeaWbZwEQCSsmj8ZrqiVwQAAXeVA
Date: Wed, 08 Apr 2015 03:01:09 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323576@NKGEML512-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.99.55]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/Var9bYYx3NS38E7Z3YaWsM5de5s>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "bier@ietf.org" <bier@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [mpls] [nvo3] Encapsulation considerations
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: <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: Wed, 08 Apr 2015 03:01:22 -0000

Of course, if it's allowed to make a minor change to the MPLS architecture (i.e., adding a protocol field immediately after the bottom of the label stack to indicate the MPLS payload type ), the first nibble issue imposed on those new encapsulations which may be transported over MPLS would disappear forever. Furthermore, the necessity of allocating local labels just for the purpose of indicating those new encapsulations (imagine how to transport NSH over MPLS) would disappear forever as well.

Best regards,
Xiaohu

> -----Original Message-----
> From: Xuxiaohu
> Sent: Wednesday, April 08, 2015 10:15 AM
> To: 'Erik Nordmark'; nvo3@ietf.org
> Subject: Re: [nvo3] Encapsulation considerations
> 
> Hi Erik,
> 
> As it has said in the draft : "... We later expanded the scope somewhat to
> consider how the encapsulations would play with MPLS "transport", which is
> important because SFC and BIER seem to target being dependent of the
> underlying "transport"...", it would be necessary to consider the first nibble
> issue for those encapsulations which may be transported over MPLS. More
> specifically, for those encapsulations which may be directly encapsulated further
> with an MPLS header, they must not start with the value 4 (IPv4) or the value 6
> (IPv6) in the first nibble. Otherwise, they would be mistakenly interpreted as IP
> payloads by transit LSRs and therefore be subjected to ECMP and potential
> packet misordering.
> 
> Best regards,
> Xiaohu
> 
> > -----Original Message-----
> > From: Erik Nordmark [mailto:nordmark@sonic.net]
> > Sent: 2015年3月26日 5:01
> > To: nvo3@ietf.org
> > Subject: [nvo3] Encapsulation considerations
> >
> >
> > I presented part of this at the most recent NVO3 interim meeting.The
> > full
> 12
> > areas of considerations where presented at RTGWG earlier this week.
> >   The draft is
> >     http://datatracker.ietf.org/doc/draft-rtg-dt-encap/
> >   and the slides are at
> >    http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf
> >
> > There is probably additional things in there to consider for NVO3, and
> advice
> > that can be reused to make it easier to move NVO3 forward.
> >
> > Regards,
> >     Erik
> >
> >
> >
> 
> 
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3