Return-Path: 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 962231327EC for ; 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-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNI7ilpHFQ1s for ; Sun, 13 Aug 2017 08:39:55 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (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 ; Sun, 13 Aug 2017 08:39:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) 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 ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (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 [192.168.24.54]) (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 ; Sun, 13 Aug 2017 17:39:50 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.154]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0319.002; Sun, 13 Aug 2017 17:39:50 +0200 From: Rolf Winter To: "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-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.204] Content-Type: multipart/alternative; boundary="_000_791AD3077F94194BB2BDD13565B6295DBFAD92AAPALLENEofficehd_" MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 15:39:59 -0000 --_000_791AD3077F94194BB2BDD13565B6295DBFAD92AAPALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. I= s 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 require= ment? It is like saying MPLS must use labels, and then you specify it to us= e labels in the same document and surprise... it fulfills the requirement. It is unclear how you guarantee this requirement: "It must accommodate exis= ting and future signaling and label-distribution protocols of tunnels and b= ypass tunnels". In particular the future ones seems an interesting claim. Y= ou 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 destin= ation to establish or resolve an egress-protected tunnel. The ingress route= r then maps the service to the tunnel for transportation". Not sure this co= unts 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 extend= ed version of the terminology section and repetition. Maybe some text can b= e 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 a= n 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 rou= ter 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 clo= se 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 compu= te 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 routin= g domain and TE domain./E and P must coordinate the context ID in the routi= ng 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 a= re 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 di= stribution protocol session/ This SHOULD: "extensions SHOULD be specified in separate documents" seems w= eird. A) because you already mentioned that without the requirements langua= ge and B) if you do not specify them, where else would such extensions be s= pecified. 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 pa= rticular 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 consid= erations section. The second should maybe recommend to use the available se= curity measures. Best, Rolf --_000_791AD3077F94194BB2BDD13565B6295DBFAD92AAPALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

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

 

Larger editorial things:

 

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

 

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

 

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 pa= rticular the future ones seems an interesting claim. You state something similar in the introduction.<= /p>

 

It is also unclear how you fulf= ill 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 ingres= s router then maps the service to the tunnel for transportation". Not = sure this counts as transparent.

 

I also feel some requirements a= re 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 s= ection and repetition. Maybe some text can be shortened.<= /p>

 

 

Minor editorial things:

 

Abstract

 

s/to ultimate service destinati= on(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 addre= ss/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 lo= cal repair)/

s/the router (aka.  MP, i.= e. merge point) downstream of the failure/the router downstream of the fail= ure (aka.  MP, i.e. merge point)/

 

3. Terminology

 

s/A node failure of an egress r= outer./A failure of an egress router./

TBD protector=

s/A router at point of local re= pair/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 a= round egress/should only involve routers close to the egress/

s/for scalability and performan= ce,/for scalability and performance reasons,/

s/ be agnostic with/ be agnosti= c 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/<= /o:p>

 

5.2 Egress node failure

 

s/At service level,/At the serv= ice level,/

s/or distinguish between a link= /or to distinguish between a link/

 

5.4 Protected egress=

 

s/multiple protected egress'/mu= ltiple protected egresses/

s/two distinct protected egress= /two distinct protected egresses/

 

5.9

 

s/in routing domain and TE doma= in/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 IG= P 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/<= o:p>

s/requires P and PLR/requires P= and the PLR/

 

5.11

 

s/ of egress-protected tunnel/o= f the egress-protected tunnel/

s/of egress protection schema/o= f the egress protection schema/

You should not use [1] for enum= erations and lists, as the square brackets are used for references.

 

5.12

 

s/agnostic with/agnostic to/

s/services labels/service label= s/

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 S= HOULD be specified in separate documents" seems weird. A) because you = already mentioned that without the requirements language and B) if you do n= ot 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 t= his?

 

8

 

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

 

10

 

The first paragraph does not ma= ke much sense as part of the security considerations section. The second sh= ould maybe recommend to use the available security measures.

 

Best,

 

Rolf

 

--_000_791AD3077F94194BB2BDD13565B6295DBFAD92AAPALLENEofficehd_--