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

From: Rolf Winter <[email-masked]>
Date: Sun, 13 Aug 2017 15:39:49 +0000

Hi,

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:

Abstract

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/

5.9

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

5.10

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/

5.11

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.

5.12

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

5.13

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".

5.14

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

8

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

10

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.

Best,

Rolf