Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00

Xuxiaohu <xuxiaohu@huawei.com> Thu, 05 June 2014 01:23 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3711A03E6 for <isis-wg@ietfa.amsl.com>; Wed, 4 Jun 2014 18:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 y_SIo-IkoTsB for <isis-wg@ietfa.amsl.com>; Wed, 4 Jun 2014 18:23:16 -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 17DD41A03DB for <isis-wg@ietf.org>; Wed, 4 Jun 2014 18:23:11 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHV76773; Thu, 05 Jun 2014 01:23:05 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 02:22:10 +0100
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 02:23:03 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 5 Jun 2014 09:22:58 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "isis-chairs@tools.ietf.org" <isis-chairs@tools.ietf.org>
Thread-Topic: Request for WG adoption of draft-xu-isis-mpls-elc-00
Thread-Index: Ac9z2gorbAmJYe4UTpeoTQ6gc4g+PgIyyZiAAKATQMAAGsmn0AALs7NwAAFqsOAACLdkoAAclDSQ
Date: Thu, 5 Jun 2014 01:22:57 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827E408@NKGEML512-MBS.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <9818_1401797825_538DBCC1_9818_12387_1_9E32478DFA9976438E7A22F69B08FF920133A5@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827DF1B@NKGEML512-MBS.china.huawei.com> <18316_1401864106_538EBFAA_18316_9423_1_9E32478DFA9976438E7A22F69B08FF92019077@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827E037@NKGEML512-MBS.china.huawei.com> <10697_1401881659_538F043B_10697_5233_1_9E32478DFA9976438E7A22F69B08FF9201B2F2@OPEXCLILM34.corporate.adroot.infra.ftgroup>
In-Reply-To: <10697_1401881659_538F043B_10697_5233_1_9E32478DFA9976438E7A22F69B08FF9201B2F2@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/zuGoPbld_RvqN-AM8YHx8P0i1tE
Cc: "draft-xu-isis-mpls-elc@tools.ietf.org" <draft-xu-isis-mpls-elc@tools.ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 01:23:19 -0000


> -----Original Message-----
> From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com]
> Sent: Wednesday, June 04, 2014 7:34 PM
> To: Xuxiaohu; isis-chairs@tools.ietf.org
> Cc: draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org
> Subject: RE: Request for WG adoption of draft-xu-isis-mpls-elc-00
> 
> Worst scenario (that I would not push for :) ) : What would you do with your
> capability if the conclusion is that EL insertion would not be supported for
> stacked tunnels because too complex ?

I have to disagree with your assumption. At least for option 1 (i.e., inserting a single EL at the bottom of the LSP stack), do you believe it's too complex? In addition, remember that one of the use cases of SPRING is IGP-based MPLS Tunneling (see section 2 of draft-filsfils-spring-segment-routing-use-cases-00).

> What's the problem for you to delay a bit your doc ? As it will never been
> implemented until there is an EL insertion solution ...

It's no problem for me to delay a bit as long as that delay is meaningful.

Best regard,
Xiaohu

> 
> -----Message d'origine-----
> De : Xuxiaohu [mailto:xuxiaohu@huawei.com] Envoyé : mercredi 4 juin 2014
> 10:22 À : LITKOWSKI Stephane SCE/IBNF; isis-chairs@tools.ietf.org Cc :
> draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org Objet : RE: Request for
> WG adoption of draft-xu-isis-mpls-elc-00
> 
> Hi Stephane,
> 
> > -----Original Message-----
> > From: stephane.litkowski@orange.com
> > [mailto:stephane.litkowski@orange.com]
> > Sent: Wednesday, June 04, 2014 2:42 PM
> > To: Xuxiaohu; isis-chairs@tools.ietf.org
> > Cc: draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org
> > Subject: RE: Request for WG adoption of draft-xu-isis-mpls-elc-00
> >
> > Hi,
> >
> > I completely agree this is orthogonal, but the solution for adding EL
> > is stacked tunnels is unfortunately not as easy as for a single LSP.
> > I just like to be sure that we would have a consensus on a solution
> > for inserting the ELC/EL before worrying on encoding the capability.
> > What would happen if we cannot have a consensus on the solution for
> > the label insertion ? It just a
> 
> Since the ELC advertisement is orthogonal to the EL insertion solution, it doesn't
> matter whether the consensus on the best EL insertion solution can be reached
> or not. Furthermore, IMHO, since each option has its pros and cons, the final
> result may be "make your own choice according to your network capabilities
> and your applications". However, no matter whichever EL insertion option is
> enabled on the ingress LSR in practice, the ELC advertisement is a necessity.
> Don't you think so?
> 
> Best regards,
> Xiaohu
> 
> > question of delaying a bit ... I don't think this is a big issue ...
> > and may be you can push at your side also to have the solution progressing for
> the label insertion ...
> >
> > Stephane
> >
> >
> > -----Message d'origine-----
> > De : Xuxiaohu [mailto:xuxiaohu@huawei.com] Envoyé : mercredi 4 juin
> > 2014
> > 04:16 À : LITKOWSKI Stephane SCE/IBNF; isis-chairs@tools.ietf.org Cc :
> > draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org Objet : RE:
> > Request for WG adoption of draft-xu-isis-mpls-elc-00
> >
> > Hi Stephane,
> >
> > > -----Original Message-----
> > > From: stephane.litkowski@orange.com
> > > [mailto:stephane.litkowski@orange.com]
> > > Sent: Tuesday, June 03, 2014 8:17 PM
> > > To: Xuxiaohu; isis-chairs@tools.ietf.org
> > > Cc: draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org
> > > Subject: RE: Request for WG adoption of draft-xu-isis-mpls-elc-00
> > >
> > > Hi,
> > >
> > > IMHO, before defining the capability, I would be more interrested on
> > > seeing some progress on a solution for EL over SPRING. A draft
> > > exists with multiple options, maybe we should wait for one option to
> > > have consensus before worrying about ELC encoding (quite easy part
> > > of the EL for
> > SPRING).
> >
> > IMHO, the following rationale for the EL concept has never been
> > changed no matter the EL mechanism is used for a single LSP or stacked
> > LSPs: An ingress LSR cannot insert ELs for packets going into a given
> > LSP unless the egress LSR of that LSP has indicated that it can
> > process ELs on that LSP. SPRING is just an approach of constructing
> > explicitly routed tunnels using stacked LSPs (see
> > http://tools.ietf.org/html/draft-gredler-spring-mpls-06). Therefore,
> > no matter option 1 (i.e., inserting a single EL at the bottom of the
> > LSP stack), option 2(i.e., inserting an EL at every LSP of the LSP
> > stack), option 3 (i.e., re-uses the EL of the terminated LSP for the
> > next inner LSP) or option 4 (i.e., inserting ELs at readable label stack depths) is
> used, the ELC advertisement is necessary. In other word, the ELC advertisement
> mechanism is orthogonal to the EL inserting options.
> >
> > Best regards,
> > Xiaohu
> >
> > > Stephane
> > >
> > > -----Message d'origine-----
> > > De : Isis-wg [mailto:isis-wg-bounces@ietf.org] De la part de
> > > Xuxiaohu
> > Envoyé :
> > > samedi 31 mai 2014 10:05 À : isis-chairs@tools.ietf.org Cc :
> > > draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org Objet :
> > > [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
> > >
> > > Hi WG co-chairs,
> > >
> > > This draft (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00)
> > > describes how to advertise the MPLS Entropy Label Capability (ELC)
> > > using IS-IS in SPRING networks. Since
> > > (http://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensio
> > > ns
> > > -00) has been adopted as a WG draft, as co-authors of
> > > draft-xu-isis-mpls-elc-00, we hope you could consider the WG
> > > adoption for
> > this draft as well.
> > >
> > > Best regards,
> > > Xiaohu (on behalf of all-authors)
> > >
> > > _______________________________________________
> > > Isis-wg mailing list
> > > Isis-wg@ietf.org
> > > https://www.ietf.org/mailman/listinfo/isis-wg
> > >
> > >
> >
> _____________________________________________________________
> > >
> >
> ____________________________________________________________
> > >
> > > Ce message et ses pieces jointes peuvent contenir des informations
> > > confidentielles ou privilegiees et ne doivent donc pas etre
> > > diffuses, exploites ou copies sans autorisation. Si vous avez recu
> > > ce message par erreur, veuillez le signaler a l'expediteur et le
> > > detruire ainsi que les pieces jointes. Les messages electroniques
> > > etant susceptibles d'alteration, Orange decline toute responsabilite
> > > si ce message a ete altere,
> > deforme ou falsifie. Merci.
> > >
> > > This message and its attachments may contain confidential or
> > > privileged information that may be protected by law; they should not
> > > be distributed, used or copied without authorisation.
> > > If you have received this email in error, please notify the sender
> > > and delete this message and its attachments.
> > > As emails may be altered, Orange is not liable for messages that
> > > have been modified, changed or falsified.
> > > Thank you.
> >
> >
> >
> _____________________________________________________________
> >
> ____________________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> > que les pieces jointes. Les messages electroniques etant susceptibles
> > d'alteration, Orange decline toute responsabilite si ce message a ete altere,
> deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> > delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> > been modified, changed or falsified.
> > Thank you.
> 
> 
> _____________________________________________________________
> ____________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute responsabilite
> si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.