Re: [mpls] MPLS-RT review draft-shen-mpls-egress-protection-framework-06
Yimin Shen <yshen@juniper.net> Tue, 24 October 2017 15:48 UTC
Return-Path: <yshen@juniper.net>
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 ACEA213F6B0; Tue, 24 Oct 2017 08:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Level:
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 vBmIZci5WBlF; Tue, 24 Oct 2017 08:48:12 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0097.outbound.protection.outlook.com [104.47.40.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2D6139209; Tue, 24 Oct 2017 08:48:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Op9+FeKmhf88sfdx8Mu+BJpnYUBB7UBfVn0IMhDwUWU=; b=eU7CLJAcda+vErOQfmw/pA8YMNceSoNQ7yDZYTDlD1k3Gq+XESLhsGwDZWqgn4hGXype068vTKGOCPU4f1YvbIeHzmyASkK1viGDYyQJihoZ/WSrUzzkz1CkDiBuwxsYqdbSY/hIAeAgGCCdZUElhG7Rl+qtsVLS5eE79Yki4b8=
Received: from BN3PR0501MB1554.namprd05.prod.outlook.com (10.161.217.144) by BN3PR0501MB1555.namprd05.prod.outlook.com (10.161.217.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Tue, 24 Oct 2017 15:48:08 +0000
Received: from BN3PR0501MB1554.namprd05.prod.outlook.com ([10.161.217.144]) by BN3PR0501MB1554.namprd05.prod.outlook.com ([10.161.217.144]) with mapi id 15.20.0156.007; Tue, 24 Oct 2017 15:48:08 +0000
From: Yimin Shen <yshen@juniper.net>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "lizho.jin" <lizho.jin@gmail.com>
CC: Ignas Bagdonas <ibagdona@gmail.com>, "draft-shen-mpls-egress-protection-framework@ietf.org" <draft-shen-mpls-egress-protection-framework@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, mpls-chairs <mpls-chairs@ietf.org>
Thread-Topic: MPLS-RT review draft-shen-mpls-egress-protection-framework-06
Thread-Index: AQHTN7QTYiHHxQCdPUyP+DqkHVmAUqLiGvKAgAX96gCAA08bgIAHi8WAgABPaoD//8lcgA==
Date: Tue, 24 Oct 2017 15:48:08 +0000
Message-ID: <4689FC33-1062-40B3-A771-84F12C829385@juniper.net>
References: <bd225c04-7f6b-4290-f494-f9de3341fc28@pi.nu> <D31A3193-01A7-4B6D-9B13-8CA969122CE2@gmail.com> <400238D2-1309-432A-B2F5-2897410ADF3A@juniper.net> <E2957991-5F71-4B32-927F-246BD6C9116A@gmail.com> <81C84133-DF70-4DE8-86D1-2F19ECA48D00@juniper.net> <AM4PR03MB17135EB5E43E3C75F4BF95839D470@AM4PR03MB1713.eurprd03.prod.outlook.com>
In-Reply-To: <AM4PR03MB17135EB5E43E3C75F4BF95839D470@AM4PR03MB1713.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1555; 6:Ooir6ReqVnsl4qs88BVKFhmHHrG4Gk+yb7wwu2z4km0ivBG0gWeMWY9N5/RJ1p0WN3vh6m7fL0A4062K0hJ5nePdoVhUIve1ldxVL/ZWSZp6HyhEKejnSHvItj+27PddhsNpptKW6nOpHvEn4IDAwo3uMbsKg/O0/srFsqSm/bHPVzEWqrlTJ7GlcWGrgDRFuboU2rSK+t5KEEcIZjZvO0mhP2baEhSg90S7od4a0ubOE/uJrBPwWszmwGNUWybovwAj3dEdgD1Yh7K1bD4F4q5Mwj8DJ2beCs8Ay9RwbSKi+RDU2R0FmC4RCXQouZF8yQZXs+ZFYVSrWKhRDGEl1Q==; 5:ds0Rw+To5ibEk2J6oqBmiaV1tajBXx9lsIttKJ89Rb5F8KynZKr/9ypfpcps4uu1ZXjv2638D3Y+nQ0tVZLpSEQVK2/M9F5oJuj43Fn/bJt7W5MD+rKcRICJbb5vetBR2b03OT3wCNl7j/iNrSWEqw==; 24:EXzsWrBoGajklJLtfIaZS9baOec5TCrsFwFyt4XhgyB7Ha4ODc5Ga8P+yuUCUvnygofv3cv/p59lzsk3jzr1ZvylSa9cbR0i9YdMgAJPVWw=; 7:eLpQkxpzJMbdKz7Kz2pGpgvrzsAMtJkGeAvqLY56r6uFUGWXJFFgaM6/gWtffh3erWkzloqs9M3OVk1aEUtwuwVh2SzvEmy1yHRjHhjZZTMIBRZqkEstI8himSjJOY5iSzrlcEsLUghSHit4o9mLjzQAukDVQQdMywDUYIwW4n6IvFaC4PH1AI+xubP6YRKfReZvMqgCeXj4OciyITDHreV5/31TFprqOC78Q3qFYJQ=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: d8b39881-7b20-4a3d-05b7-08d51af69fc4
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229); SRVR:BN3PR0501MB1555;
x-ms-traffictypediagnostic: BN3PR0501MB1555:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=yshen@juniper.net;
x-exchange-antispam-report-test: UriScan:(37575265505322)(10436049006162)(138986009662008)(95692535739014)(18271650672692)(21748063052155)(279101305709854)(50582790962513);
x-microsoft-antispam-prvs: <BN3PR0501MB1555C54734836FA94CF3C79ABD470@BN3PR0501MB1555.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231020)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1555; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1555;
x-forefront-prvs: 047001DADA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(199003)(189002)(37854004)(252514010)(51914003)(53754006)(316002)(53546010)(229853002)(6506006)(6486002)(606006)(66066001)(3280700002)(39060400002)(77096006)(82746002)(4326008)(86362001)(2950100002)(83716003)(230783001)(53936002)(6436002)(93886005)(110136005)(189998001)(33656002)(5660300001)(25786009)(7736002)(6246003)(54906003)(58126008)(14454004)(83506002)(9326002)(99286003)(2906002)(68736007)(81156014)(54896002)(8936002)(76176999)(2900100001)(81166006)(53946003)(6306002)(236005)(6512007)(101416001)(8676002)(3846002)(6116002)(102836003)(50986999)(3660700001)(478600001)(36756003)(105586002)(106356001)(54356999)(97736004)(55754003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1555; H:BN3PR0501MB1554.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_4689FC33106240B3A77184F12C829385junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: d8b39881-7b20-4a3d-05b7-08d51af69fc4
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2017 15:48:08.6869 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1555
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/I4JEaRP6dcr_8g5m0X8VNv9RMRs>
Subject: Re: [mpls] MPLS-RT review draft-shen-mpls-egress-protection-framework-06
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 24 Oct 2017 15:48:17 -0000
Hi Sasha, Thanks for the comment. Yes, RFC 6389<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_rfc6389_-3Finclude-5Ftext-3D1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=RACb_2-5a7D6F3yJr9p2mhvx8Z06zeGfZ21zgMRj1ms&s=ZzameNNmRJBo1AMtKHH-_cOZlR-Zp2fRoUsoZ65xSWM&e=> describes a case where LDP may use upstream assigned label across a LAN for a P2MP tunnel. In particular, section 6 says the following. Ru transmits the MPLS packet using the procedures defined in [RFC5331] and [RFC5332]. The MPLS packet transmitted by Ru contains as the top label the context label assigned by Ru on the LAN interface, Li. The bottom label is the upstream label assigned by Ru to the LDP P2MP LSP. The top label is looked up in the context of the LAN interface (Li) by a downstream LSR on the LAN. This lookup enables the downstream LSR to determine the context-specific label space in which to look up the inner label. For local repair in egress node protection, the “inner/bottom” label of the LDP tunnel is swapped to the label (or label stack) of a bypass tunnel. So, there is really no difference than the case of “down-stream assigned” label. IOW, whether the label is up-/down-stream assigned doesn’t matter. Thanks, -- Yimin From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Date: Tuesday, October 24, 2017 at 11:03 AM To: Yimin Shen <yshen@juniper.net>, "lizho.jin" <lizho.jin@gmail.com> Cc: Ignas Bagdonas <ibagdona@gmail.com>, "draft-shen-mpls-egress-protection-framework@ietf.org" <draft-shen-mpls-egress-protection-framework@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, mpls-chairs <mpls-chairs@ietf.org> Subject: RE: MPLS-RT review draft-shen-mpls-egress-protection-framework-06 Hi all, I have looked up RFC 4875<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4875&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=RACb_2-5a7D6F3yJr9p2mhvx8Z06zeGfZ21zgMRj1ms&s=pUL9vngZDS914eQ-0W9a8h2s-LnemCXr59z8S94SwNg&e=> that defines setup of P2MP LSPs using RSVP-TE and found the following text in section 6.2 (irrelevant text is skipped): As usual, the Resv message carries the label allocated by the egress LSR. ... A node upstream of the egress node MUST allocate its own label and pass it upstream in the Resv message. ... The node that sends the Resv message, for a P2MP LSP, upstream MUST associate the label assigned by this node with all the labels received from downstream Resv messages, for that P2MP LSP. IMHO and FWIW, this means that P2MP LSPs set up by RSVP-TE only used downstream-allocated labels - hardly surprising since RFC 4875 has been published in May-2007, while RFC 5331<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5331&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=RACb_2-5a7D6F3yJr9p2mhvx8Z06zeGfZ21zgMRj1ms&s=W7GZMW6Kf6XeRJTuKwLN3JLDMwg9ReAix-ibVHBAnuM&e=> (that defines upstream-allocated labels) – only in Aug-2008. And I am not aware of any extensions to RFC 4875 that would result in using upstream-allocated labels in P2MP LSPs that can be set up with RSVP-TE. At the same time, P2MP and MP2MP LSPs set up by mLDP may use upstream-allocated labels as described in RFC 6389<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_rfc6389_-3Finclude-5Ftext-3D1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=RACb_2-5a7D6F3yJr9p2mhvx8Z06zeGfZ21zgMRj1ms&s=ZzameNNmRJBo1AMtKHH-_cOZlR-Zp2fRoUsoZ65xSWM&e=>. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen Sent: Tuesday, October 24, 2017 5:19 PM To: lizho.jin <lizho.jin@gmail.com> Cc: Ignas Bagdonas <ibagdona@gmail.com>; draft-shen-mpls-egress-protection-framework@ietf.org; mpls@ietf.org; mpls-chairs <mpls-chairs@ietf.org> Subject: Re: [mpls] MPLS-RT review draft-shen-mpls-egress-protection-framework-06 Hi Lizhong, Thanks for the comments. Please see below for [yshen_1]. 3. section 5.12. It seems bypass tunnel sharing or facility backup scenario missed in this section. [yshen] The section 5.12 does talk about bypass sharing at the beginning. Bypass sharing is also talked about in some other sections. This framework does not use facility backup. [Lizhong] this section talks about the label swapping operation on PLR, and I do not see similar words for bypass tunnel sharing. I consider the bypass tunnel sharing as similar mechanism of facility backup, is that correct? [yshen_1] Yes, that is correct. The description in this section is generic and applicable to the case of bypass tunnel sharing. We can add text to mention this. 4. section 8. "On PE3, a context label 100 is assigned to the context ID, " The label 100 should be assigned to the RSVP-TE tunnel with address of context ID, not only to the context ID, since one-to-one backup is used in this example. [yshen] The context label is assigned to the context ID. If any RSVP tunnel is destined to the context ID, yes, it will automatically get bound to the context label as well. [Lizhong] It seems I understand you meaning. If there are two RSVP-TE bypass tunnel to the same context ID, then same context label will be used for the two RSVP-TE bypass tunnel, right? [yshen_1] Correct. In that case, how about the upstream label in P2MP LSP? It is not possible for the P to distinguish different upstream labels assigned from different ingress if there are two P2MP share one of the same egress. [yshen_1] Not sure about the septic case of P2MP LSP using upstream labels. In general, a PLR should pop all the labels of a transport tunnel, before sending a packet (with only a service label) through a bypass tunnel to a protector. Thanks, -- Yimin From: "lizho.jin" <lizho.jin@gmail.com<mailto:lizho.jin@gmail.com>> Date: Thursday, October 19, 2017 at 11:05 AM To: Yimin Shen <yshen@juniper.net<mailto:yshen@juniper.net>> Cc: loa <loa@pi.nu<mailto:loa@pi.nu>>, "draft-shen-mpls-egress-protection-framework@ietf.org<mailto:draft-shen-mpls-egress-protection-framework@ietf.org>" <draft-shen-mpls-egress-protection-framework@ietf.org<mailto:draft-shen-mpls-egress-protection-framework@ietf.org>>, "'Carlos Pignataro (cpignata)'" <cpignata@cisco.com<mailto:cpignata@cisco.com>>, 'Eric Gray' <eric.gray@ericsson.com<mailto:eric.gray@ericsson.com>>, Ignas Bagdonas <ibagdona@gmail.com<mailto:ibagdona@gmail.com>>, mpls-chairs <mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>>, "mpls@ietf.org<mailto:mpls@ietf.org>" <mpls@ietf.org<mailto:mpls@ietf.org>> Subject: Re: MPLS-RT review draft-shen-mpls-egress-protection-framework-06 Hi Yimin Thanks for the reply. See inline below. Regards Lizhong On 10/18/2017 00:33,Yimin Shen<yshen@juniper.net><mailto:yshen@juniper.net> wrote: Hi, Lizhong Thanks very much for your kind review! Please see inline for our response. Thanks, Yimin Shen Juniper Networks From: "lizho.jin" <lizho.jin@gmail.com<mailto:lizho.jin@gmail.com>> Date: Friday, October 13, 2017 at 1:03 PM To: loa <loa@pi.nu<mailto:loa@pi.nu>>, "draft-shen-mpls-egress-protection-framework@ietf.org<mailto:draft-shen-mpls-egress-protection-framework@ietf.org>" <draft-shen-mpls-egress-protection-framework@ietf.org<mailto:draft-shen-mpls-egress-protection-framework@ietf.org>> Cc: "'Carlos Pignataro (cpignata)'" <cpignata@cisco.com<mailto:cpignata@cisco.com>>, 'Eric Gray' <eric.gray@ericsson.com<mailto:eric.gray@ericsson.com>>, Ignas Bagdonas <ibagdona@gmail.com<mailto:ibagdona@gmail.com>>, mpls-chairs <mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>>, "mpls@ietf.org<mailto:mpls@ietf.org>" <mpls@ietf.org<mailto:mpls@ietf.org>> Subject: Re: MPLS-RT review draft-shen-mpls-egress-protection-framework-06 Resent-From: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.org>> Resent-To: <yshen@juniper.net<mailto:yshen@juniper.net>>, Jeyananth <minto@juniper.net<mailto:minto@juniper.net>>, <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>, <hannes@rtbrick.com<mailto:hannes@rtbrick.com>>, <c.michel@telekom.de<mailto:c.michel@telekom.de>>, <huaimo.chen@huawei.com<mailto:huaimo.chen@huawei.com>>, <jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>> Resent-Date: Friday, October 13, 2017 at 1:04 PM Hi, Authors I've been asked to do MPLS-RT review. Overall this kind of egress protection is much easy to deploy, and the mechanism is useful, and technically sound. It is ready to consider for WG adoption. And I still have some questions as below: 1. section 1. " example of such extension is [RSVP-EP]." Typo? It should be RSVP-TE? [yshen] This is supposed to refer to draft-ietf-teas-rsvp-egress-protection, which is missing in the reference section. We will add it. 2. section 5.9. The protected egress {E, P} which is called a "context ID" is actually an anycast address, right? The terminology of "anycast" used here will be much clear, but it depends on you to choose. [yshen] The section 5.9 describes context ID strictly from reachability’s perspective. We want to avoid the word “anycast”, because a context ID should not be used in anycast. IOW, it should not be the destination address in any IP headers. 3. section 5.12. It seems bypass tunnel sharing or facility backup scenario missed in this section. [yshen] The section 5.12 does talk about bypass sharing at the beginning. Bypass sharing is also talked about in some other sections. This framework does not use facility backup. [Lizhong] this section talks about the label swapping operation on PLR, and I do not see similar words for bypass tunnel sharing. I consider the bypass tunnel sharing as similar mechanism of facility backup, is that correct? 4. section 8. "On PE3, a context label 100 is assigned to the context ID, " The label 100 should be assigned to the RSVP-TE tunnel with address of context ID, not only to the context ID, since one-to-one backup is used in this example. [yshen] The context label is assigned to the context ID. If any RSVP tunnel is destined to the context ID, yes, it will automatically get bound to the context label as well. [Lizhong] It seems I understand you meaning. If there are two RSVP-TE bypass tunnel to the same context ID, then same context label will be used for the two RSVP-TE bypass tunnel, right? In that case, how about the upstream label in P2MP LSP? It is not possible for the P to distinguish different upstream labels assigned from different ingress if there are two P2MP share one of the same egress. 5. section 8.1. "R1 computes a bypass path to 198.51.100.1 while avoiding PE2. " Could you give more explicit way to achieve above without RSVP-TE protocol extensions? [yshen] Section 5.10 and 5.11. Regards Lizhong On 9/28/2017 01:14,Loa Andersson<loa@pi.nu<mailto:loa@pi.nu>> wrote: Carlos, Eric, Ignas and Lizhong You have been selected as MPLS-RT reviewers for draft-shen-mpls-egress- protection-framework-06. Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound? We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start). Please remember that it often is easier to progress the document when it has become a working group document. All comments in the MPLS-RT review needs to be addressed, but please think carefully about whether a comment is gating the adoption or could just as easily be addressed after the adoption. Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs. If you have technical comments you should try to be explicit about what needs to be resolved before adopting it as a working group document, and what can wait until the document is a working group document and the working group has the revision control. Are you able to review this draft by October 13, 2017? Please respond whether you are available to do the review in a timely fashion. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@pi.nu<mailto:loa@pi.nu> Senior MPLS Expert Huawei Technologies (consultant) phone: +46 739 81 21 64 ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________
- Re: [mpls] MPLS-RT review draft-shen-mpls-egress-… lizho.jin
- Re: [mpls] MPLS-RT review draft-shen-mpls-egress-… Yimin Shen
- Re: [mpls] MPLS-RT review draft-shen-mpls-egress-… lizho.jin
- Re: [mpls] MPLS-RT review draft-shen-mpls-egress-… Yimin Shen
- Re: [mpls] MPLS-RT review draft-shen-mpls-egress-… Alexander Vainshtein
- Re: [mpls] MPLS-RT review draft-shen-mpls-egress-… Yimin Shen
- Re: [mpls] MPLS-RT review draft-shen-mpls-egress-… Alexander Vainshtein
- Re: [mpls] MPLS-RT review draft-shen-mpls-egress-… Lizhong Jin
- Re: [mpls] MPLS-RT review draft-shen-mpls-egress-… Yimin Shen
- Re: [mpls] MPLS-RT review draft-shen-mpls-egress-… Lizhong Jin
- Re: [mpls] MPLS-RT review draft-shen-mpls-egress-… Yimin Shen
- Re: [mpls] MPLS-RT review draft-shen-mpls-egress-… Lizhong Jin
- Re: [mpls] MPLS-RT review draft-shen-mpls-egress-… Yimin Shen
- Re: [mpls] MPLS-RT review draft-shen-mpls-egress-… Alexander Vainshtein
- Re: [mpls] MPLS-RT review draft-shen-mpls-egress-… Yimin Shen