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

[Yimin Shen <[e-mail]>]

Hi Rolf,

Again, thanks very much for your detailed review and great comments! Please see inline for our clarification and responses. We shall address the comments in the next revision. Thanks for helping us improve the clarity and quality of the draft.

Best regards,

-- Yimin Shen
Juniper Networks


From: mpls <[e-mail]> on behalf of Rolf Winter <[e-mail]>
Date: Sunday, August 13, 2017 at 11:39 AM
To: "[e-mail]" <[e-mail]>
Subject: [mpls] review of draft-shen-mpls-egress-protection-framework

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?

[yshen] This section of “Requirements” describes what we considered as the requirements in designing the mechanism, rather than the requirements which the draft raises for implementation of this draft. Therefore, we are not using MUSTs. We can clarify this.

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.

[yshen] This does sounds redundant. We will remove it.

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.

[yshen] As you can see, when talking services, this draft doesn’t refer to any specific type of service. Instead, it talks about services generically, by modeling each service as an entity consisting of a common set of pieces, including service instance(s), service label, service label distribution protocol, service transport tunnel, etc. This generic service model has been used for all existing services, and hence we believe future services will continue to conform to this model as well. We can add text to clarify this assumption.

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.

[yshen] Yes, we need to clarify this. When doing the above, the ingress router is not aware of the special semantics of the context ID. It only views the context ID as an IP address of the remote peer (received in service advertisement). IOW, it behaves in the same manner as resolving a regular transport tunnel, although the end result will be an egress-protected tunnel. From that perspective, egress protection is transparent to it.

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.

[yshen] Will consider this suggestion.

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.

 [yshen] Will consider shortening the terminology section. It is intended to help readers understand the main sections.

Minor editorial things:

[yshen] We will incorporate the suggestions below.

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.

[yshen] Yes, that is good point.

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

[yshen]  Agreed.

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?

[yshen] Good catch! Will fix them.

8

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

[yshen] Will do. Thanks for pointing it out.

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.

[yshen] We can rephrase the 1st paragraph. What we intended to say was that traffic rerouting should not introduce any security concerns.

Best,

Rolf