[mpls] review of draft-shen-mpls-egress-protection-framework

Rolf Winter <Rolf.Winter@neclab.eu> Sun, 13 August 2017 15:39 UTC

Return-Path: <Rolf.Winter@neclab.eu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 962231327EC for <mpls@ietfa.amsl.com>; Sun, 13 Aug 2017 08:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ZNI7ilpHFQ1s for <mpls@ietfa.amsl.com>; Sun, 13 Aug 2017 08:39:55 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03ECD132635 for <mpls@ietf.org>; Sun, 13 Aug 2017 08:39:55 -0700 (PDT)
Received: from localhost (localhost []) by mailer1.neclab.eu (Postfix) with ESMTP id 02318102BC8; Sun, 13 Aug 2017 17:39:53 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([]) by localhost (atlas-a.office.hd []) (amavisd-new, port 10024) with ESMTP id V8CfleElTM4d; Sun, 13 Aug 2017 17:39:52 +0200 (CEST)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from METHONE.office.hd (methone.office.hd []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id C46E4102A5A for <mpls@ietf.org>; Sun, 13 Aug 2017 17:39:50 +0200 (CEST)
Received: from PALLENE.office.hd ([]) by METHONE.office.hd ([]) with mapi id 14.03.0319.002; Sun, 13 Aug 2017 17:39:50 +0200
From: Rolf Winter <Rolf.Winter@neclab.eu>
To: "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: review of draft-shen-mpls-egress-protection-framework
Thread-Index: AdMUSfvs0Lx4dgGASryWMWjX65vxAw==
Date: Sun, 13 Aug 2017 15:39:49 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295DBFAD92AA@PALLENE.office.hd>
Accept-Language: en-US, de-DE
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_791AD3077F94194BB2BDD13565B6295DBFAD92AAPALLENEofficehd_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/cJenLrfeBeKLnPJGCH-YZqIuuYc>
Subject: [mpls] review of draft-shen-mpls-egress-protection-framework
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: Sun, 13 Aug 2017 15:39:59 -0000


I have reviewed draft-shen-mpls-egress-protection-framework and have a few comments:

Larger editorial things:

None of the requirements in section 4 have a requirements language MUSTs. Is that by intention and if yes, why?

You write "The framework must be based on local failure detection and local repair". But you have specified it that way. Why spell it out as a requirement? It is like saying MPLS must use labels, and then you specify it to use labels in the same document and surprise... it fulfills the requirement.

It is unclear how you guarantee this requirement: "It must accommodate existing and future signaling and label-distribution protocols of tunnels and bypass tunnels". In particular the future ones seems an interesting claim. You state something similar in the introduction.

It is also unclear how you fulfill some of the other requirements. E.g. you say as a requirement: "be transparent to ingress routers". But the ingress is involved e.g. you say "The ingress router uses the context ID as destination to establish or resolve an egress-protected tunnel. The ingress router then maps the service to the tunnel for transportation". Not sure this counts as transparent.

I also feel some requirements are missing. E.g. dual-homing of the site to two routers of the MPLS network, which received at least a MUST in 5.14.

Much of section 5 (at least the first few subsections) feels like an extended version of the terminology section and repetition. Maybe some text can be shortened.

Minor editorial things:


s/to ultimate service destination(s)./to the ultimate service destination(s)./
s/service label distribution to protector/service label distribution to the protector/

1. Intro

s/based on IP destination address/based on the destination IP address/
s/the router (aka.  PLR, i.e. point of local repair) upstream adjacent to an anticipated failure/the router upstream to an anticipated failure (aka.  PLR, i.e. point of local repair)/
s/the router (aka.  MP, i.e. merge point) downstream of the failure/the router downstream of the failure (aka.  MP, i.e. merge point)/

3. Terminology

s/A node failure of an egress router./A failure of an egress router./
TBD protector
s/A router at point of local repair/A router at the point of local repair/
s/The scenario where protector/The scenario where a protector/

4. Requirements

s/should only involve routers around egress/should only involve routers close to the egress/
s/for scalability and performance,/for scalability and performance reasons,/
s/ be agnostic with/ be agnostic to/ (search replace this... comes up a few times)
s/or TE topology to compute or resolve path for/or the TE topology to compute or resolve a path for/

5.2 Egress node failure

s/At service level,/At the service level,/
s/or distinguish between a link/or to distinguish between a link/

5.4 Protected egress

s/multiple protected egress'/multiple protected egresses/
s/two distinct protected egress/two distinct protected egresses/


s/in routing domain and TE domain/in the routing domain and the TE domain/ (this appears multiple times in the document)


s/for context ID is done on/for a context ID is done on/ (same in the title)
s/E and P must coordinate in IGP advertisement for the context ID in routing domain and TE domain./E and P must coordinate the context ID in the routing domain and the TE domain via IGP advertisements. /
s/but not PLR/but not the PLR/
s/requires P and PLR/requires P and the PLR/


s/ of egress-protected tunnel/of the egress-protected tunnel/
s/of egress protection schema/of the egress protection schema/
You should not use [1] for enumerations and lists, as the square brackets are used for references.


s/agnostic with/agnostic to/
s/services labels/service labels/
s/on per-service basis/on a per-service basis/


s/be a session of service label distribution protocol/be a service label distribution protocol session/
This SHOULD: "extensions SHOULD be specified in separate documents" seems weird. A) because you already mentioned that without the requirements language and B) if you do not specify them, where else would such extensions be specified. At least make it a "should".


s/is the number of/is equal to the number of/
"{egress router, protector}" diverts from the previous nomenclature. Any particular reason for this?


You should use the IP prefixes set aside for documentation in your document (see https://tools.ietf.org/html/rfc5737)


The first paragraph does not make much sense as part of the security considerations section. The second should maybe recommend to use the available security measures.