From nobody Tue Dec 1 18:12:25 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EC01B3117; Tue, 1 Dec 2015 18:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 SohmIGagXwVF; Tue, 1 Dec 2015 18:12:18 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526371B3116; Tue, 1 Dec 2015 18:12:17 -0800 (PST) X-AuditID: c618062d-f79d16d000001b1c-aa-565e536bfd74 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 3A.6F.06940.B635E565; Wed, 2 Dec 2015 03:11:55 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Tue, 1 Dec 2015 21:12:16 -0500 From: Gregory Mirsky To: Huaimo Chen , "draft-ietf-teas-rsvp-egress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection Thread-Index: AQHQdmHVRgLHg1W7rkaJKE/Q3gfump64OmSQ Date: Wed, 2 Dec 2015 02:12:15 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1122194CF4D@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B948D85@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D44E37F079@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D44E37F079@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1122194CF4Deusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyuXSPn252cFyYweFNZhZT3/5kttj69Aqj xa2lK1ktPv/ZxmjRNHcXk0Xrjx0sDmweLUfesnosWfKTyePL5c9sAcxRXDYpqTmZZalF+nYJ XBnty1awFzw4zljx78wmlgbG32sYuxg5OSQETCS+HeligrDFJC7cW8/WxcjFISRwhFFi8cxu dghnGaPEje3rwarYBIwkXmzsAUuICHxklGh/tJIFJMEs4CVx6fk0ZhBbWMBNouXtH7C4iIC7 xP3m88wQtpFE+9PzYHEWARWJ8xPOsYLYvAK+Es82roZaPZNRYs/RqWDbOAXCJJa9h7AZge77 fmoNE8QycYlbT+ZD3S0gsWQPxAIJAVGJl4//sULYihL7+qezQ9TnS3zdfosZYpmgxMmZT1gm MIrOQjJqFpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypGjtLigpzcdCODTYzA iDwmwaa7g/H+dM9DjAIcjEo8vAVqcWFCrIllxZW5hxglOJiVRHi9ZIBCvCmJlVWpRfnxRaU5 qcWHGKU5WJTEeRkZGBiEBNITS1KzU1MLUotgskwcnFINjHoXoqqq0oW1ZT5zn/1k8MxayKNj rpi/TM7zj7ff7fugyCiRKHpfejrfNpPrEpNTO4vNI2p0Xb9qLT1wPPbDxL1v0rYEnY7dnHTX WGjVO65vXOq2ke0CfvXfTb+95nB9HO2kKb7+ocqCCy+lLfdeOflqInvPDZ7f6ts1RZiXxnDs iI/Mf7pyvhJLcUaioRZzUXEiAO/J4B7EAgAA Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [Teas] [mpls] Comments to draft-ietf-teas-rsvp-egress-protection X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 02:12:23 -0000 --_000_7347100B5761DC41A166AC17F22DF1122194CF4Deusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, et. al, apologies for such very late response. I've read the -02 version and below = you'll find my notes to changes I've found. My responses to our discussion = are in-line and tagged GIM>>. Notes to -02 version: * section 5.1 states A backup egress SHOULD be configured on the ingress of an LSP to protect a primary egress of the LSP. Are there scenario when this SHOULD NOT be done, when the backup egress(es)= are not configured? And if this is such strong requirement, then the same is applicable to the = next sentence that currently reads as "...optional egress backup descriptor= list for protecting egresses of the LSP". I think that the descriptor list= SHOULD be included in the Path message by the ingress. * section 5.2 states: If the transit node is the upstream node of a primary egress to be protected, it determines the backup egress, obtains a path for the backup LSP and sets up the backup LSP along the path. Which, in my view, contradicts with the statement in section 5.1 that backu= p egress(es) SHOULD be configured at LSP ingress. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Monday, April 13, 2015 8:19 PM To: Gregory Mirsky; draft-ietf-teas-rsvp-egress-protection@tools.ietf.org; = teas-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection Hi Greg, Thanks for your comments. My answers/explanations are inline below. Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Monday, April 13, 2015 2:58 PM To: draft-ietf-teas-rsvp-egress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection Dear Editors, please kindly consider my comments to the current version of this work: * Introduction o The third paragraph mentions that an end-to-end protection may be slowe= r to detect failure and perform switchover then an arbitrary local protecti= on method. I believe that that is not the case and, as been demonstrated by= deployments of G.8031, G.8032 and RFC 6378 end-to-end provides sub-50 msec= switchover and G.8013/Y.1731 and RFC 5884 failure detection is 10 msec. [Huaimo] It seems that the statement in the paragraph is true. For a globa= l protection (or an end-to-end protection), it may take more time since the= time includes the propagation time and processing time. The propagation ti= me may depend on the size of the network. In general, the bigger the networ= k, the longer the propagation delay. The processing time may comprise the r= elated processing time on every node along the path from the egress node to= a node interesting the failure and doing switchover. GIM>> I think that distance, whether in number of intermediate hops or mile= s, does not affect guaranteed defect detection time when continuity check p= rotocol being used. In that case detection time depends only on definition = of Loss of Continuity defect for the given protocol. For example, in CFM it= is period of time between 3.25 and 3.5 CCM intervals when no CCM received = from remote MEP. BFD is little different and DetectMultiplier can be negoti= ated between end points of the given BFD session. But regardless of these d= ifferences, using CFM or BFD enables detection of LoC defect within 10 ms r= egardless of the distance between end-points. o The last in Section 1.1 suggests that node R3 may detect failure of the= node L1 through monitoring BFD session between two nodes. Firstly, if this= is multi-hop BFD session over IP network, then there's no guarantee that i= ts path is co-routed with the LSP segment R1-L3. Secondly, if it is assumed= that RFC 5884 may be used, I have to remind, that RFC 5884 operates betwee= n LSP end points and R1 is not end point. Thus, Sub-Path Maintenance Entity= (SPME) co-routed with the segment R1-L3 MUST be established. [Huaimo] It seems that R3 is the upstream node of L1 and there is no multi-= hop BFD session between R3 and L1. This current version of the document focuses on extending the protection of= RFC 4090 from a transit node to an egress node. It seems that it is better= to have another document for others if needed. GIM>> I couldn't find in the document statement that the PLR R3 MUST be ups= tream to the egress. If this is the requirement, then it must be explicitly= stated as, in my view, it is restrictive and limits number of networks whe= re proposed method can be used. * Section 5.2 o The third paragraph assumes that if a PLR cannot establish LSP to any l= isted LSR in the EGRESS_BACKUP object it SHOULD select it locally and recor= d it in the EGRESS_BACKUP object. I believe that that implies that a PLR, i= .e. any LSR in the MPLS domain is aware of all services, i.e. CEs, as that = is required when selecting backup egress. That is serious security concern = and must be properly addressed in Security Considerations section of the dr= aft. [Huaimo] This paragraph says that the upstream node of the primary egress k= nows/determines that there is not any backup egress given for the primary = egress. In this case, the upstream node selects a backup egress according t= o a local policy. The upstream node may not need to be aware of any service= s or CEs. GIM>> As commented above to section 5.2, this contradicts statement made in= section 5.1 that backup egress(es) SHOULD be configured at LSP ingress. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1122194CF4Deusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo, et. al,

apologies for such ver= y late response. I’ve read the -02 version and below you’ll fin= d my notes to changes I’ve found. My responses to our discussion are = in-line and tagged GIM>>.

Notes to -02 version:<= o:p>

·         section 5.1 st= ates

   A backup egress SHOULD be configured on the ingress of an= LSP to

   protect a primary egress of the LSP.

Are there scenario when this SHOULD NOT be done, when the backup egres= s(es) are not configured?

And if this is such strong requirement, then the same is applicable to= the next sentence that currently reads as “…optional egress ba= ckup descriptor list for protecting egresses of the LSP”. I think that the descriptor list SHOULD be included in the Pat= h message by the ingress.

·         section 5.2 st= ates:

   If the transit node is the upstream node of a primary egr= ess to be

   protected, it determines the backup egress, obtains a pat= h for the

   backup LSP and sets up the backup LSP along the path.

Which, in my view, contradicts with the statement in section 5.1 that = backup egress(es) SHOULD be configured at LSP ingress.

 

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Monday, April 13, 2015 8:19 PM
To: Gregory Mirsky; draft-ietf-teas-rsvp-egress-protection@tools.iet= f.org; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments to draft-ietf-teas-rsvp-egress-protecti= on

 

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Monday, April 13, 2015 2:58 PM
To: draft-ietf-teas-rsvp-egress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection

 

Dear Editors,

please kindly consider my comments to the current ve= rsion of this work:

·         Introduction

o   The third paragraph mentions that an end-to-= end protection may be slower to detect failure and perform switchover then = an arbitrary local protection method. I believe that that is not the case a= nd, as been demonstrated by deployments of G.8031, G.8032 and RFC 6378 end-to-end provides sub-50 msec switchover = and G.8013/Y.1731 and RFC 5884 failure detection is 10 msec.

[Huaimo] It seems that= the statement in the paragraph is true.  For a global protection (or = an end-to-end protection), it may take more time since the time includes th= e propagation time and processing time. The propagation time may depend on the size of the network. In general, the bi= gger the network, the longer the propagation delay. The processing time may= comprise the related processing time on every node along the path from the= egress node to a node interesting the failure and doing switchover.

GIM>> I think th= at distance, whether in number of intermediate hops or miles, does not affe= ct guaranteed defect detection time when continuity check protocol being us= ed. In that case detection time depends only on definition of Loss of Continuity defect for the given protocol. For exa= mple, in CFM it is period of time between 3.25 and 3.5 CCM intervals when n= o CCM received from remote MEP. BFD is little different and DetectMultiplie= r can be negotiated between end points of the given BFD session. But regardless of these differences, usin= g CFM or BFD enables detection of LoC defect within 10 ms regardless of the= distance between end-points.

o   The last in Section 1.1 suggests that node R= 3 may detect failure of the node L1 through monitoring BFD session between = two nodes. Firstly, if this is multi-hop BFD session over IP network, then = there’s no guarantee that its path is co-routed with the LSP segment R1-L3. Secondly, if it is assumed that R= FC 5884 may be used, I have to remind, that RFC 5884 operates between LSP e= nd points and R1 is not end point. Thus, Sub-Path Maintenance Entity (SPME)= co-routed with the segment R1-L3 MUST be established.

[Huaimo] It seems that= R3 is the upstream node of L1 and there is no multi-hop BFD session betwee= n R3 and L1.

This current version o= f the document focuses on extending the protection of RFC 4090 from a trans= it node to an egress node. It seems that it is better to have another docum= ent for others if needed.

GIM>> I couldn&#= 8217;t find in the document statement that the PLR R3 MUST be upstream to t= he egress. If this is the requirement, then it must be explicitly stated as= , in my view, it is restrictive and limits number of networks where proposed method can be used.

·         Section 5.2

o   The third paragraph assumes that if a PLR ca= nnot establish LSP to any listed LSR in the EGRESS_BACKUP object it SHOULD = select it locally and record it in the EGRESS_BACKUP object. I believe that= that implies that a PLR, i.e. any LSR in the MPLS domain is aware of all services, i.e. CEs, as that is requ= ired when selecting backup egress. That is serious security concern and mus= t be properly addressed in Security Considerations section of the draft.

[Huaimo] This paragrap= h says that the upstream node of the primary egress knows/determines that &= nbsp;there is not any backup egress given for the primary egress. In this c= ase, the upstream node selects a backup egress according to a local policy. The upstream node may not need to be aware of= any services or CEs.   

GIM>> As comment= ed above to section 5.2, this contradicts statement made in section 5.1 tha= t backup egress(es) SHOULD be configured at LSP ingress.<= /p>

 

 

Regards,

    &= nbsp;           Greg=

--_000_7347100B5761DC41A166AC17F22DF1122194CF4Deusaamb103erics_-- From nobody Sun Dec 6 22:04:24 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4061B2F75; Sun, 6 Dec 2015 22:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 prjMVYQJLNbp; Sun, 6 Dec 2015 22:04:18 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C24D31B2F74; Sun, 6 Dec 2015 22:04:17 -0800 (PST) Received: by igcmv3 with SMTP id mv3so72224327igc.0; Sun, 06 Dec 2015 22:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YIY2qZxo4OvmULpX0WjWvcsgSQ0n6k6H6n1KRb/28y8=; b=BOCMXRhuIfiybcXQwwQyEy7U3NauymtuokcGGlD/JfsjjzcmTc20Cn68VjUsQsHrjr 5W+QcLewbdSoAtIpyiq+uGXNRILgNNTjT0bPFuMla8nFMdf24hpRwA4LqAbyLeI2w2cy kcn4gFYXt3LD6bs4zv4s6/P7ELu3UqyWHBwYYzK+N2orm0eI4IE79AGDucMg/vW8sdWX fBWV0VPipqwEiesfjei7I3PFu65AiuIGxkXhGFwwD5szsIZoXOLrXYczEdq3Sstmw/1e YUUKf66Rq82pA+oq3hO9fo8tDobhJ23eCCZU1Ywc8ojomT/afuITPB445zRFehk5sqRg k4Fg== MIME-Version: 1.0 X-Received: by 10.50.73.199 with SMTP id n7mr13775938igv.1.1449468256988; Sun, 06 Dec 2015 22:04:16 -0800 (PST) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.190.138 with HTTP; Sun, 6 Dec 2015 22:04:16 -0800 (PST) In-Reply-To: <6F154112-526C-46C5-8B39-78F0819A91E0@jvknet.com> References: <5650CCAC.3090702@jvknet.com> <6F154112-526C-46C5-8B39-78F0819A91E0@jvknet.com> Date: Mon, 7 Dec 2015 11:34:16 +0530 X-Google-Sender-Auth: cEEWYcQ4z938zTONdY4sF3s3kZk Message-ID: From: Dhruv Dhody To: Victor Kuarsingh Content-Type: multipart/alternative; boundary=089e011827589243ae052648a00f Archived-At: Cc: "ops-dir@ietf.org" , "BRUNGARD, DEBORAH A" , "teas-chairs@ietf.org" , "TEAS WG \(teas@ietf.org\)" , Vishnu Pavan Beeram , Joel Jaeggli , "dhruv.dhody@huawei.com" , Benoit Claise , Lou Berger , "draft-ietf-teas-rsvp-te-domain-subobjects.all@ietf.org" Subject: Re: [Teas] OPS-DIR Review draft-ietf-teas-rsvp-te-domain-subobjects X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 06:04:20 -0000 --089e011827589243ae052648a00f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Victor, Regarding the open issue with the use of word "advised" v/s "SHOULD" at - OLD: For the purpose of this experiment, it is advised to use 4-Byte AS number subobject as default. SUGGESTED: For the purpose of this experiment, 4-Byte AS number subobject =E2=80=8BSHOULD be used=E2=80=8B as default.=E2=80=8B =E2=80=8BThe AD, chairs and authors discussed, though we can go either way,= *but* for an experimental draft to use the word "advised" seems appropriate. In case this was on standards track use of SHOULD would be required. To *advise* how to run an experiment seems more appropriate than the use of "SHOULD". =E2=80=8BWould you be okay with text if kept, as it currently is= ? WG, This is the only open issue, =E2=80=8Bthe document is ready to be sent to R= FC editor after this. https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-domain-subobjects-05 Regards, Dhruv On Wed, Nov 25, 2015 at 9:27 AM, Victor Kuarsingh wrote= : > Dhruv, > > Yes, that looks good. > > Regards, > > Victor K > > Sent from my iPad > > On Nov 23, 2015, at 12:03 AM, Dhruv Dhody wrote: > > Hi Victor, > > Thanks for your review. Please see inline... > > On Sun, Nov 22, 2015 at 1:27 AM, Victor Kuarsingh > wrote: > >> Dear Authors, >> >> I have reviewed this document as part of the Operational directorate's >> ongoing effort to review all IETF documents being processed by the IESG. >> These comments were written with the intent of improving the operational >> aspects of the IETF drafts. Comments that are not addressed in last call >> may be included in AD reviews during the IESG review. Document editors = and >> WG chairs should treat these comments just like any other last call >> comments. >> >> Document Reviewed - draft-ietf-teas-rsvp-te-domain-subobjects-03 >> Link to Document - >> https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-domain-subobjects-03 >> >> Summary: >> >> This document outlines an experimental set of new sub-objects within the >> RSVP-TE / GMPLS framework which includes 4-byte Autonomous Systems and >> Interior Gateway Protocol Area (IGP) during path setup. The new ERO >> (Explicit Route Objects), XRO (Exclude Route Object) and EXRS (Explicit >> Inclusion Route) sub-objects are defined within the document, including = the >> mode of operation in how they are to be used. >> >> General Comments and Feedback: >> >> Backwards compatibility is generally address by reference to RFC3209 >> which describes behavior of implementations which do not yet have these = new >> sub-objects defined (i.e. PathErr). This behavior is both expected and >> valid. >> >> In section 3.2.1, when defining the behavior of nodes which support this >> new 4-byte option capability, it is suggested that the 4-byte sub-object= ed >> be used for both 2-byte and 4-byte ASs information transfer. It's >> understand that this document is designated for Experimental, so >> operational challenges which can arise may be better suited for review w= hen >> an Standard-Track document is released, however, I would suggested that = we >> consider making it a MUST or SHOULD by default. I would also think tha= t >> one may consider saying that if the 4-byte sub-option is used, then the >> 2-byte sub-option should not be used at the same time (although the >> information would be consistent (likely), it's my opinion that the same >> information not be advertised at the same time using two different optio= ns. >> (point of consideration, not a must). >> > > =E2=80=8B [Dhruv]: So that it's clear on what change is being requested..= . > OLD: > For the purpose of this experiment, it is advised to use > 4-Byte AS number subobject as default. > SUGGESTED: > For the purpose of this experiment, 4-Byte AS number > subobject =E2=80=8BSHOULD be used=E2=80=8B as default.=E2=80=8B > > Chairs/AD - what do you think? > > =E2=80=8BSecond, =E2=80=8Bsay you want to encode AS 100 in ERO, you would= include it as > 0x0064 in 4-byte AS or as 0x64 in 2-byte AS. You would have to pick betwe= en > one of these, both would not be included. If it's okay with you I would > prefer to not make any text change for this. > > Regards, > Dhruv > > > >> Textual Review: >> >> No specific text changes were / are suggested from this review. >> >> >> > --089e011827589243ae052648a00f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Victor,=C2=A0

<adding = TEAS>

Regarding the open issue with the=C2=A0use of word "advised&q= uot; v/s "SHOULD" at -=C2=A0=C2=A0

OLD:
=C2=A0 =C2=A0 =C2=A0 For the pur= pose of this experiment, it is advised to use=C2=A0
=C2=A0 =C2=A0 =C2=A0 4-Byte AS number= subobject as default.
SUGGESTED:
=C2=A0 =C2=A0 =C2=A0 For the purpose of this experiment, 4-Byte AS nu= mber=C2=A0
=C2= =A0 =C2=A0 =C2=A0 subobject =E2=80=8BSHOULD be used=E2=80=8B as default.=E2= =80=8B

=E2=80=8B= The AD, chairs and authors discussed, though we can go either way, *but* fo= r an experimental draft to use the word "advised" seems appropria= te. In case this was on standards track use of SHOULD would be required.=C2= =A0
To *advise* how to run an experiment= seems more appropriate than the use of "SHOULD". =C2=A0=E2=80=8B= Would you be okay with text if kept, as it currently is?=C2=A0

WG,=C2=A0
=
This is the only open issue, =E2=80=8Bthe doc= ument is ready to be sent to RFC editor after this.=C2=A0
Regards,
Dhruv


On Wed, Nov 25, 2015 at 9:27 AM, Victor Kuarsingh <victor@jvkne= t.com> wrote:
Dhru= v,

Yes, =C2=A0that looks good. =C2=A0
Regards,

Victor K

Sent from my= iPad

On Nov 23, 2015, at 12:03 AM, Dh= ruv Dhody <dhr= uv.ietf@gmail.com> wrote:

Hi Victor,=C2=A0

Than= ks for your review. Please see inline...
On Sun, Nov 22, 2015 at 1:27 AM, Victor Kuarsi= ngh <victor@jvknet.com> wrote:
Dear Auth= ors,

I have reviewed this document as part of the Operational directorate's = ongoing effort to review all IETF documents being processed by the IESG.=C2= =A0 These comments were written with the intent of improving the operationa= l aspects of the IETF drafts. Comments that are not addressed in last call = may be included in AD reviews during the IESG review.=C2=A0 Document editor= s and WG chairs should treat these comments just like any other last call c= omments.

Document Reviewed - draft-ietf-teas-rsvp-te-domain-subobjects-03
Link to Document - https://t= ools.ietf.org/html/draft-ietf-teas-rsvp-te-domain-subobjects-03

Summary:

This document outlines an experimental set of new sub-objects within the RS= VP-TE / GMPLS framework which includes 4-byte Autonomous Systems and Interi= or Gateway Protocol Area (IGP) during path setup. The new ERO (Explicit Rou= te Objects), XRO (Exclude Route Object) and EXRS (Explicit Inclusion Route)= sub-objects are defined within the document, including the mode of operati= on in how they are to be used.

General Comments and Feedback:

Backwards compatibility is generally address by reference to RFC3209 which = describes behavior of implementations which do not yet have these new sub-o= bjects defined (i.e. PathErr).=C2=A0 This behavior is both expected and val= id.

In section 3.2.1, when defining the behavior of nodes which support this ne= w 4-byte option capability, it is suggested that the 4-byte sub-objected be= used for both 2-byte and 4-byte ASs information transfer.=C2=A0 It's u= nderstand that this document is designated for Experimental, so operational= challenges which can arise may be better suited for review when an Standar= d-Track document is released, however, I would suggested that we consider m= aking it a MUST or=C2=A0 SHOULD by default.=C2=A0 I would also think that o= ne may consider saying that if the 4-byte sub-option is used, then the 2-by= te sub-option should not be used at the same time (although the information= would be consistent (likely), it's my opinion that the same informatio= n not be advertised at the same time using two different options. (point of= consideration, not a must).

=E2=80=8B [Dhruv]: So that it's clear on what change is being requeste= d...=C2=A0
OLD:
=C2=A0 =C2=A0 =C2=A0 For the purpose of= this experiment, it is advised to use=C2=A0
=C2=A0 =C2=A0 =C2=A0= 4-Byte AS number subobject as default.
SUGGESTED:
=C2= =A0 =C2=A0 =C2=A0 For the purpose of this experiment, 4-Byte AS number=C2= =A0
=C2=A0 =C2=A0 =C2=A0 subobject =E2=80=8BSHOULD be used=E2=80= =8B as default.=E2=80=8B

Chairs/AD - what do you t= hink?=C2=A0

=E2=80=8BSecond, =E2= =80=8Bsay you want to encode AS 100 in ERO, you would include it as 0x0064 = in 4-byte AS or as 0x64 in 2-byte AS. You would have to pick between one of= these, both would not be included. If it's okay with you I would prefe= r to not make any text change for this.=C2=A0

Regards,
Dhruv



Textual Review:

No specific text changes were / are suggested from this review.




--089e011827589243ae052648a00f-- From nobody Wed Dec 16 11:39:40 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54501A8957; Wed, 16 Dec 2015 11:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ABidPeTd9WOW; Wed, 16 Dec 2015 11:39:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA03A1A8953; Wed, 16 Dec 2015 11:39:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFN88651; Wed, 16 Dec 2015 19:39:23 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 16 Dec 2015 19:39:20 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.81]) by SJCEML702-CHM.china.huawei.com ([169.254.4.118]) with mapi id 14.03.0235.001; Wed, 16 Dec 2015 11:39:13 -0800 From: Huaimo Chen To: Gregory Mirsky , "draft-ietf-teas-rsvp-egress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection Thread-Index: AdB055+jr3+smJ3uSuiCZj3/NJvp6ABbWMEwLaU6DoAC01Ez0A== Date: Wed, 16 Dec 2015 19:39:13 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E4BF43F@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B948D85@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D44E37F079@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1122194CF4D@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1122194CF4D@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.4] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D44E4BF43FSJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5671BDEC.00DD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 78969ca1155697374f738bcf5f69e4c6 Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [Teas] [mpls] Comments to draft-ietf-teas-rsvp-egress-protection X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 19:39:36 -0000 --_000_5316A0AB3C851246A7CA5758973207D44E4BF43FSJCEML701CHMchi_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Greg=1B$B!$=1B(B See my answers/explanations inline below. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Tuesday, December 01, 2015 9:12 PM To: Huaimo Chen; draft-ietf-teas-rsvp-egress-protection@tools.ietf.org; tea= s-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection Hi Huaimo, et. al, apologies for such very late response. I=1B$B!G=1B(Bve read the -02 version= and below you=1B$B!G=1B(Bll find my notes to changes I=1B$B!G=1B(Bve found= . My responses to our discussion are in-line and tagged GIM>>. Notes to -02 version: * section 5.1 states A backup egress SHOULD be configured on the ingress of an LSP to protect a primary egress of the LSP. Are there scenario when this SHOULD NOT be done, when the backup egress(es)= are not configured? And if this is such strong requirement, then the same is applicable to the = next sentence that currently reads as =1B$B!H!D=1B(Boptional egress backup = descriptor list for protecting egresses of the LSP=1B$B!I=1B(B. I think tha= t the descriptor list SHOULD be included in the Path message by the ingress= . Huaimo: Yes. See the paragraph below in the draft. The PLR (upstream node of the primary egress) extracts the backup egress from the respective EGRESS_BACKUP object in the egress backup descriptor list. If no matching EGRESS_BACKUP object is found or the list is empty, the PLR may apply a local policy to determine the backup egress and add an EGRESS_BACKUP object with the backup egress and primary egress into a Path message to the primary egress. * section 5.2 states: If the transit node is the upstream node of a primary egress to be protected, it determines the backup egress, obtains a path for the backup LSP and sets up the backup LSP along the path. Which, in my view, contradicts with the statement in section 5.1 that backu= p egress(es) SHOULD be configured at LSP ingress. Huaimo: It seems that this is not contradicts with the statement in section= 5.1 that backup egress(es) SHOULD be configured at LSP ingress. Just in t= he paragraph below the one you mentioned, it gives the details. =1B$B!H=1B(BThe PLR (upstream node of the primary egress) extracts the back= up egress from the respective EGRESS_BACKUP object in the egress backup descriptor list. If no matching EGRESS_BACKUP object is found or the list is empty, the PLR may apply a local policy to determine the backup egress and add an EGRESS_BACKUP object with the backup egress and primary egress into a Path message to the primary egress.=1B$B!I=1B(B Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Monday, April 13, 2015 8:19 PM To: Gregory Mirsky; draft-ietf-teas-rsvp-egress-protection@tools.ietf.org; = teas-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection Hi Greg, Thanks for your comments. My answers/explanations are inline below. Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Monday, April 13, 2015 2:58 PM To: draft-ietf-teas-rsvp-egress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection Dear Editors, please kindly consider my comments to the current version of this work: * Introduction o The third paragraph mentions that an end-to-end protection may be slowe= r to detect failure and perform switchover then an arbitrary local protecti= on method. I believe that that is not the case and, as been demonstrated by= deployments of G.8031, G.8032 and RFC 6378 end-to-end provides sub-50 msec= switchover and G.8013/Y.1731 and RFC 5884 failure detection is 10 msec. [Huaimo] It seems that the statement in the paragraph is true. For a globa= l protection (or an end-to-end protection), it may take more time since the= time includes the propagation time and processing time. The propagation ti= me may depend on the size of the network. In general, the bigger the networ= k, the longer the propagation delay. The processing time may comprise the r= elated processing time on every node along the path from the egress node to= a node interesting the failure and doing switchover. GIM>> I think that distance, whether in number of intermediate hops or mile= s, does not affect guaranteed defect detection time when continuity check p= rotocol being used. In that case detection time depends only on definition = of Loss of Continuity defect for the given protocol. For example, in CFM it= is period of time between 3.25 and 3.5 CCM intervals when no CCM received = from remote MEP. BFD is little different and DetectMultiplier can be negoti= ated between end points of the given BFD session. But regardless of these d= ifferences, using CFM or BFD enables detection of LoC defect within 10 ms r= egardless of the distance between end-points. o The last in Section 1.1 suggests that node R3 may detect failure of the= node L1 through monitoring BFD session between two nodes. Firstly, if this= is multi-hop BFD session over IP network, then there=1B$B!G=1B(Bs no guara= ntee that its path is co-routed with the LSP segment R1-L3. Secondly, if it= is assumed that RFC 5884 may be used, I have to remind, that RFC 5884 oper= ates between LSP end points and R1 is not end point. Thus, Sub-Path Mainten= ance Entity (SPME) co-routed with the segment R1-L3 MUST be established. [Huaimo] It seems that R3 is the upstream node of L1 and there is no multi-= hop BFD session between R3 and L1. This current version of the document focuses on extending the protection of= RFC 4090 from a transit node to an egress node. It seems that it is better= to have another document for others if needed. GIM>> I couldn=1B$B!G=1B(Bt find in the document statement that the PLR R3 = MUST be upstream to the egress. If this is the requirement, then it must be= explicitly stated as, in my view, it is restrictive and limits number of n= etworks where proposed method can be used. * Section 5.2 o The third paragraph assumes that if a PLR cannot establish LSP to any l= isted LSR in the EGRESS_BACKUP object it SHOULD select it locally and recor= d it in the EGRESS_BACKUP object. I believe that that implies that a PLR, i= .e. any LSR in the MPLS domain is aware of all services, i.e. CEs, as that = is required when selecting backup egress. That is serious security concern = and must be properly addressed in Security Considerations section of the dr= aft. [Huaimo] This paragraph says that the upstream node of the primary egress k= nows/determines that there is not any backup egress given for the primary = egress. In this case, the upstream node selects a backup egress according t= o a local policy. The upstream node may not need to be aware of any service= s or CEs. GIM>> As commented above to section 5.2, this contradicts statement made in= section 5.1 that backup egress(es) SHOULD be configured at LSP ingress. Regards, Greg --_000_5316A0AB3C851246A7CA5758973207D44E4BF43FSJCEML701CHMchi_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Greg=1B$B!$=1B(B=

 

See my answers/explanations inline below.

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Tuesday, December 01, 2015 9:12 PM
To: Huaimo Chen; draft-ietf-teas-rsvp-egress-protection@tools.ietf.o= rg; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments to draft-ietf-teas-rsvp-egress-protecti= on

 

Hi Huaimo, et. al,

apologies for such ver= y late response. I=1B$B!G=1B(Bve read the -02 version and below you=1B$B!G= =1B(Bll find my notes to changes I=1B$B!G=1B(Bve found. My responses to our= discussion are in-line and tagged GIM>>.

Notes to -02 version:<= o:p>

·        section 5.1 st= ates

   A backup egress SHOULD be configured on the ingress of an= LSP to

   protect a primary egress of the LSP.

Are there scenario when this SHOULD NOT be done, when the backup egres= s(es) are not configured?

And if this is such strong requirement, then the same is applicable to= the next sentence that currently reads as =1B$B!H!D=1B(Boptional egress ba= ckup descriptor list for protecting egresses of the LSP=1B$B!I=1B(B. I think that the descriptor list SHOULD be included in th= e Path message by the ingress.

 

Huaimo: Yes. See the p= aragraph below in the draft.

The PLR (upstream node of the primary egress) extracts= the backup

egress from the respective EGRESS_BACKUP object in the= egress backup

descriptor list. If no matching EGRESS_BACKUP object i= s found or the

list is empty, the PLR may apply a local policy to det= ermine the

backup egress and add an EGRESS_BACKUP object with the= backup egress

and primary egress into a Path message to the primary egress.

 

·        section 5.2 st= ates:

   If the transit node is the upstream node of a primary egr= ess to be

   protected, it determines the backup egress, obtains a pat= h for the

   backup LSP and sets up the backup LSP along the path.

Which, in my view, contradicts with the statement in section 5.1 that = backup egress(es) SHOULD be configured at LSP ingress.

 

Huaimo: It seems that this is not contradicts with the statement in= section 5.1 that backup egress(es) SHOULD be configured at LSP ingress. &n= bsp;Just in the paragraph below the one you mentioned, it gives the details.

=1B$B!H=1B(BThe PLR (upstream node of the primary egress) extracts the backup=

egress from the respective EGRESS_BACKUP object in the= egress backup

descriptor list. If no matching EGRESS_BACKUP object i= s found or the

list is empty, the PLR may apply a local policy to det= ermine the

backup egress and add an EGRESS_BACKUP object with the= backup egress

and primary egress into a Path message to the primary egress.=1B$B!I=1B(B<= /span>

 

 

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Monday, April 13, 2015 8:19 PM
To: Gregory Mirsky; draft-ietf-teas-rsvp-egress-protection@tools.iet= f.org; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments to draft-ietf-teas-rsvp-egress-protecti= on

 

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Monday, April 13, 2015 2:58 PM
To: draft-ietf-teas-rsvp-egress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection

 

Dear Editors,

please kindly consider my comments to the current ve= rsion of this work:

·        Introduction

o   The third paragraph mentions that an end-to-= end protection may be slower to detect failure and perform switchover then = an arbitrary local protection method. I believe that that is not the case a= nd, as been demonstrated by deployments of G.8031, G.8032 and RFC 6378 end-to-end provides sub-50 msec switchover = and G.8013/Y.1731 and RFC 5884 failure detection is 10 msec.

[Huaimo] It seems that= the statement in the paragraph is true.  For a global protection (or = an end-to-end protection), it may take more time since the time includes th= e propagation time and processing time. The propagation time may depend on the size of the network. In general, the bi= gger the network, the longer the propagation delay. The processing time may= comprise the related processing time on every node along the path from the= egress node to a node interesting the failure and doing switchover.

GIM>> I think th= at distance, whether in number of intermediate hops or miles, does not affe= ct guaranteed defect detection time when continuity check protocol being us= ed. In that case detection time depends only on definition of Loss of Continuity defect for the given protocol. For exa= mple, in CFM it is period of time between 3.25 and 3.5 CCM intervals when n= o CCM received from remote MEP. BFD is little different and DetectMultiplie= r can be negotiated between end points of the given BFD session. But regardless of these differences, usin= g CFM or BFD enables detection of LoC defect within 10 ms regardless of the= distance between end-points.

o   The last in Section 1.1 suggests that node R= 3 may detect failure of the node L1 through monitoring BFD session between = two nodes. Firstly, if this is multi-hop BFD session over IP network, then = there=1B$B!G=1B(Bs no guarantee that its path is co-routed with the LSP segment R1-L3. Secondly, if it is assumed that R= FC 5884 may be used, I have to remind, that RFC 5884 operates between LSP e= nd points and R1 is not end point. Thus, Sub-Path Maintenance Entity (SPME)= co-routed with the segment R1-L3 MUST be established.

[Huaimo] It seems that= R3 is the upstream node of L1 and there is no multi-hop BFD session betwee= n R3 and L1.

This current version o= f the document focuses on extending the protection of RFC 4090 from a trans= it node to an egress node. It seems that it is better to have another docum= ent for others if needed.

GIM>> I couldn= =1B$B!G=1B(Bt find in the document statement that the PLR R3 MUST be upstre= am to the egress. If this is the requirement, then it must be explicitly st= ated as, in my view, it is restrictive and limits number of networks where proposed method can be used.

·        Section 5.2

o   The third paragraph assumes that if a PLR ca= nnot establish LSP to any listed LSR in the EGRESS_BACKUP object it SHOULD = select it locally and record it in the EGRESS_BACKUP object. I believe that= that implies that a PLR, i.e. any LSR in the MPLS domain is aware of all services, i.e. CEs, as that is requ= ired when selecting backup egress. That is serious security concern and mus= t be properly addressed in Security Considerations section of the draft.

[Huaimo] This paragrap= h says that the upstream node of the primary egress knows/determines that &= nbsp;there is not any backup egress given for the primary egress. In this c= ase, the upstream node selects a backup egress according to a local policy. The upstream node may not need to be aware of= any services or CEs.   

GIM>> As comment= ed above to section 5.2, this contradicts statement made in section 5.1 tha= t backup egress(es) SHOULD be configured at LSP ingress.<= /p>

 

 

Regards,

    &= nbsp;           Greg=

--_000_5316A0AB3C851246A7CA5758973207D44E4BF43FSJCEML701CHMchi_-- From nobody Thu Dec 17 09:12:48 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78F71B2FDA; Thu, 17 Dec 2015 09:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jf31QgOwJe3A; Thu, 17 Dec 2015 09:12:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558261B2FE0; Thu, 17 Dec 2015 09:12:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFP04772; Thu, 17 Dec 2015 17:12:29 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.218.25.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 17 Dec 2015 17:12:27 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.81]) by SJCEML703-CHM.china.huawei.com ([169.254.5.130]) with mapi id 14.03.0235.001; Thu, 17 Dec 2015 09:12:20 -0800 From: Huaimo Chen To: Gregory Mirsky , "rtorvi@juniper.net" , "draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Index: AdBz6EeHlPEjW31GTZaF4ZwMtm3+CgBSx/EQAOobtwAA2TtZ4Cv1H2mAAzJyqkA= Date: Thu, 17 Dec 2015 17:12:19 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E4BF71B@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D44E37EE98@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B94CD49@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D44E3804B5@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1122194BD8B@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1122194BD8B@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.130] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D44E4BF71BSJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5672ECFE.0143, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fd72317a4f92f41bf0d83c1edc565e7e Archived-At: Subject: Re: [Teas] [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 17:12:47 -0000 --_000_5316A0AB3C851246A7CA5758973207D44E4BF71BSJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, My answers/explanations to your comments/questions are inline below. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Monday, November 30, 2015 7:50 PM To: Huaimo Chen; rtorvi@juniper.net; draft-ietf-teas-rsvp-ingress-protectio= n@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Hi Huaimo and authors, apologies for the extended period of silence. Thank you for your answers. I= 'll use this thread of discussion to review and comment on the latest versi= on of the document. I believe that we were discussing -02 version and the most current is -04. = Thus I've reviewed changes from -02 through -04 versions. Please find my co= mments and questions below: * Source Detects Failure I cannot agree with several assertions and statements made in this section: o the source node (S in Fig.1) detects failure not just of R1 but S-R1 pa= th. The text "the backup ingress MUST use a method to reliably detect the f= ailure of the primary ingress" concentrates only of failure of the R1, thus= excluding failure of S-R1 path; Huaimo: It seems that the failure of the link between S and R1 is outside t= he scope of the LSP ingress local protection. That link failure may be pro= tected in some other ways. Even though the failure of the link between sour= ce S and primary ingress R1 happens and source S switches the traffic to th= e backup ingress after the failure (source S detected it) and the backup in= gress does not use any method to detect the failure of the link, the traffi= c will be delivered to its destination(s) as expected. The traffic is sent = to the backup ingress by source S, which is imported into the backup LSP(s)= from the backup ingress to the next hop(s) of the primary ingress of the p= rimary LSP, where the traffic is merged into the primary LSP and transporte= d to the egress(es) of the primary LSP. o Similar omission seen in the last paragraph that concentrates only on s= cenario when R1 fails and excludes scenario when path S-R1 does fail even t= hough from the perspective of S these are equally defects; Huaimo: See answer/explanation above. o And it is not obvious why discussion of monitoring role of the backup i= ngress located in this section. Huaimo: When the primary ingress fails, the backup ingress MUST "detect" th= e failure of the primary ingress reliably to support the protection of the = primary ingress through some ways (or say through monitoring the primary in= gress). * Backup and Source Detect Failure o as noted earlier, the backup ingress has no means to reliably detect fa= ilure of S-R1 path. Thus state of the LSP from S perspective and Ra may not= be the same without explicit protocol similar to Protection Switchover Coo= rdination [RFC6378]. Huaimo: It seems that the failure of the link between S and R1 is outside t= he scope of the LSP ingress protection. That link failure may be protected= in some other ways. Even though ... (See details above). * Failure Detection and Refresh PATH Messages o as noted earlier, the backup ingress cannot "accurately detect that the= ingress node has failed" for all the cases where the Source detects a fail= ure. Huaimo: It seems that there are some ways for the backup ingress to accurat= ely detect the failure of the primary ingress after the primary ingress has= failed. For example, as described in the draft, "After the primary ingress= fails, it will not be reachable after routing convergence. Thus checking w= hether the primary ingress (address) is reachable is a possible method." * several new places now use normative SHOULD, e.g. section Revert t= o Primary Ingress: If "Revert to Primary Ingress" is desired for a protected LSP, the (primary) ingress of the LSP SHOULD re-signal the LSP that starts from the primary ingress after the primary ingress restores. Is there an alternative to re-signaling the LSP? After the LSP is re-signaled successfully, the traffic SHOULD be switche= d back to the primary ingress from the backup ingress on the source node and redirected into the LSP starting from the primary ingress. Similarly, is there alternative to switching traffic back to the primary af= ter the LSP been re-signaled successfully? Huaimo: Regarding to normative language, it seems better to follow the styl= e of the description about the revertive behavior in RFC 4090. * Security Considerations I believe that the Source-Detect approach introduces several security conce= rns that were not in scope of RFC 4090. For example, the Source required to= monitor S-R1 path thus increasing, if not opening possibility of DDoS atta= ck. Huaimo: From RSVP-TE protocol's point of view, there is no RSVP-TE message = transmitted between Source S and primary ingress R1. For Source S to detect= the failure of primary ingress R1, if a bfd session is used between S and = R1, the bfd messages between S and R1 need to be trusted. It seems that bf= d authentication is defined in RFC 5880 and may be used. BTW, the traffic is already sent to primary ingress R1 from source S, why = monitoring the link between S and R1 increase possibility of DDoS attack? B= ad (or attack) messages can be sent to S or R1 even though there is not any= monitoring on the link between S and R1. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Tuesday, April 21, 2015 8:27 AM To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org<= mailto:draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org>; teas-chairs= @ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Hi Greg, Thanks for your comments. My answers/explanations are inline below with [Huaimo 2]. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, April 16, 2015 7:58 PM To: Huaimo Chen; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@ie= tf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Hi Huaimo, thank you for kind consideration of my comments. Please find more in-lined = and tagged GIM>> notes. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Sunday, April 12, 2015 11:04 AM To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org<= mailto:draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org>; teas-chairs= @ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Hi Greg, Thanks for your comments. My answers/explanations are inline below. Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Sunday, April 12, 2015 2:04 AM To: draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Dear Editors, chairs, WG community, please find my comments to the current version of your work below: * Introduction o The first paragraph may leave an impression that local protection of tr= ansit LSRs is not being already addressed, neither by RFC 4090, nor RFC 487= 5; [Huaimo] Will revise it accordingly. o I think that "global protection" is not commonly used term, "end-to-end= protection" seems to be commonly used instead. [Huaimo] It seems that "global protection" is better here since we mentione= d "local protection" here. It seems that Global Protection is used often. * Section 3.1 o Third paragraph contains the following requirement: "For a P2P LSP, after the primary ingress fails, the backup ingress must us= e a method to reliably detect the failure of the primary ingress before the= PATH message for the LSP expires at the next hop of the primary ingress." But that is not obvious that such requirement is really needed. Since this = is RSVP-TE LSP, why not to use MP2MP construct and let the Source node to c= ontrol switchover. Especially since, as noted in the last paragraph of Sect= ion 2.1, primary and backup ingress nodes must be connected by a logical li= nk, which in general case will be a tunnel. Thus this solution puts a requi= rement, implicitly though, to instantiate a tunnel per protection group, tu= nnel that would not be used to carry traffic. [Huaimo] The requirement above seems necessary. If the backup ingress does = not detect the failure of the primary ingress before the timer for the PATH= message for the LSP at the next hop of the primary ingress expires, the LS= P will be down after the primary ingress fails. If the backup ingress detec= ts the failure and sends/refreshes the PATH message to the next hop before = the timer expires after the primary egress fails, the LSP will continue bei= ng up and carry the traffic from the backup ingress via the backup LSP. For a P2P LSP, it seems that MP2MP construct is not used in RFC 4090 to pro= tect a transit node of a P2P LSP. The logical link between the primary ingr= ess and the backup ingress can be a direct link or a tunnel. It seems that = a direct link is common. GIM>> I think it is strange to cite requirement on scale of seconds if not = tens of seconds in discussion of method of local protection that supposed t= o perform protection switchover in sub-second if not sub-50msec time. [Huaimo 2] The requirement is for the control plane. More specifically, it = is for the PATH message (not to be cleaned up) for the LSP at the next hop = of the primary ingress of the LSP when the primary ingress fails. After the= primary ingress fails, the next hop will not receive any PATH message from= the primary ingress. In order to prevent the PATH message from clean up at= the next hop, the backup ingress seems required to detect the failure of t= he primary ingress and send/refresh the PATH message to the next hop before= the PATH message is cleaned up. Thus it seems reasonable for the requireme= nt to have the time for detecting the failure of the primary ingress in sec= onds or even tens of seconds instead of sub-seconds or within 50 ms. o In addition, what is importance of requirement quoted above: "... before the PATH message for the LSP expires at the next hop of the pri= mary ingress" [Huaimo] This seems very important. If the timer for the PATH message for t= he LSP at the next hop of the primary egress expires, then the LSP will be = down. So the PATH message must be refreshed before the timer for the PATH m= essage for the LSP expires at the next hop of the primary LSP. GIM>> As noted above, these seem as requirements of different scale. [Huaimo 2] See the explanation above. o Fourth paragraph makes very questionable assumption in: "After the primary ingress fails, it will not be reachable after routing co= nvergence." I believe that if OAM session is between two nodes there's no reliable way = to differentiate between node and link failure. Thus, to declare a node unr= eachable there must be N tunnels for N OAM sessions that monitor all possib= le paths between two nodes. (Note, that if there was no requirement to use = a tunnel between primary and backup ingress, multi-hop BFD could be used th= ough its detection time being limited by IGP convergence, which may be too = slow comparing with your requirement of tens milliseconds). [Huaimo] It is true that "After the primary ingress fails, it will not be r= eachable after routing convergence." From routing's point of view, there i= s no need for us to have any OAM session between two nodes. The timer for a= PATH message seems in tens of seconds. Routing convergence is not limited = to tens of milliseconds. GIM>> Routing convergence may take seconds. Is that acceptable as failure d= etection time for local protection? Protection switchover expected to be fa= st, perhaps on sub-50 msec scale. From TDM world we carry 10 msec failure d= etection, and BFD implementations can support that. but here, it appears, y= ou describe failure detection mechanism with detection time on scale of sec= onds if not tens of seconds. [Huaimo 2] The routing convergence is for the control plane. Refer to the e= xplanation above. * Section 5.1 o Regarding "Ingress local protection in use" flag As demonstrated earlier, backup ingress node has no reliable way to detect = that primary ingress node is not reachable to the Source and thus protectio= n must be activated. [Huaimo] It seems that there is no need for the backup ingress to detect wh= ether the primary ingress is reachable to the Source and the focus is on th= e failure of the primary ingress. GIM>> In that case, the text is not needed either. [Huaimo 2] Can you give more details regarding to "the text is not needed e= ither"? Which part of the text (do you think) is not needed in section 5.1? Considering that backup ingress may initiate described in the document acti= ons not when primary ingress became unavailable to Source, I believe that c= ases that may produce false positives must be removed along with extensions= that intended to support these cases. In my opinion, the only viable case = of ingress protection is Source-centric where Source monitors availability = of both primary and backup ingress nodes and controls traffic switchover. I= 'd ask WG to discuss these comments and, if agreed, ask Editors to make app= ropriate changes to the document. [Huaimo] It seems that the current version already indicates that the sourc= e-detect (i.e., Source detects the failure of the primary ingress and switc= hes traffic to the backup ingress when the primary ingress fails) is used. = There were a few of modes for detecting the failure of the primary ingress= that were proposed in the previous versions of the document. A different m= ode may have a different control on the traffic switch over and/or forwardi= ng. After discussions, the current version selects the source-detect. GIM>> If this is historical part, then it may be moved to Appendix or taken= from the document altogether. [Huaimo 2] A couple of detection modes were removed from the document. One = more will be smoothed out. Thus there will be only one mode in the document= . Can you give more details about the cases in which false positives may be p= roduced? GIM>> If current proposal is limited to Source-detect case only then possi= bility of false positive/negative depends on Source to Ingress connection a= nd OAM mechanism used. But that is deployment issue and is outside of scope= of this document Regards, Greg --_000_5316A0AB3C851246A7CA5758973207D44E4BF71BSJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

My answers/explanations to your comments/questions are inline below.<= o:p>

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Monday, November 30, 2015 7:50 PM
To: Huaimo Chen; rtorvi@juniper.net; draft-ietf-teas-rsvp-ingress-pr= otection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protect= ion

 

Hi Huaimo and authors,=

apologies for the exte= nded period of silence. Thank you for your answers. I’ll use this thr= ead of discussion to review and comment on the latest version of the docume= nt.

I believe that we were= discussing -02 version and the most current is -04. Thus I’ve review= ed changes from -02 through -04 versions. Please find my comments and quest= ions below:

·        Source Detects= Failure

I cannot agree with several assertions and statements made in this sec= tion:

o   the source nod= e (S in Fig.1) detects failure not just of R1 but S-R1 path. The text ̶= 0;the backup ingress MUST use a method to reliably detect the failure of th= e primary ingress” concentrates only of failure of the R1, thus excluding failure of S-R1 path;<= /p>

Huaimo: It seems that = the failure of the link between S and R1 is outside the  scope of the = LSP ingress local protection. That link failure may be protected in some ot= her ways. Even though the failure of the link between source S and primary ingress R1 happens and source S switches= the traffic to the backup ingress after the failure (source S detected it)= and the backup ingress does not use any method to detect the failure of th= e link, the traffic will be delivered to its destination(s) as expected. The traffic is sent to the backup ingre= ss by source S, which is imported into the backup LSP(s) from the backup in= gress to the next hop(s) of the primary ingress of the primary LSP, where t= he traffic is merged into the primary LSP and transported to the egress(es) of the primary LSP.

o   Similar omissi= on seen in the last paragraph that concentrates only on scenario when R1 fa= ils and excludes scenario when path S-R1 does fail even though from the per= spective of S these are equally defects;

Huaimo: See answer/exp= lanation above.

o   And it is not = obvious why discussion of monitoring role of the backup ingress located in = this section.

Huaimo: When the prima= ry ingress fails, the backup ingress MUST “detect” the failure = of the primary ingress reliably to support the protection of the primary in= gress through some ways (or say through monitoring the primary ingress).  

·        Backup and Sou= rce Detect Failure

o   as noted earli= er, the backup ingress has no means to reliably detect failure of S-R1 path= . Thus state of the LSP from S perspective and Ra may not be the same witho= ut explicit protocol similar to Protection Switchover Coordination [RFC6378].

Huaimo: It seems that = the failure of the link between S and R1 is outside the  scope of the = LSP ingress protection. That link failure may be protected in some other wa= ys. Even though … (See details above).

·        Failure Detect= ion and Refresh PATH Messages

o   as noted earli= er, the backup ingress cannot “accurately detect that the ingress nod= e has failed” for all the cases where the Source detects a failure.

Huaimo: It seems that = there are some ways for the backup ingress to accurately detect the failure= of the primary ingress after the primary ingress has failed. For example, = as described in the draft, “After the primary ingress fails, it will not be reachable after routing convergence.= Thus checking whether the primary ingress (address) is reachable is a poss= ible method.”

·        several new pl= aces now use normative SHOULD, e.g. section Revert to Primary Ingress:=

   If "Revert to Primary Ingress" is desired for = a protected LSP, the

   (primary) ingress of the LSP SHOULD re-signal the LSP th= at starts

   from the primary ingress after the primary ingress resto= res.

Is there an alternative to re-signaling the LSP?

   After the LSP is re-signaled successfully, the traffic S= HOULD be switched

   back to the primary ingress from the backup ingress on t= he source

   node and redirected into the LSP starting from the prima= ry ingress.

Similarly, is there alternative to switching traffic back to the prim= ary after the LSP been re-signaled successfully?

Huaimo: Regarding to n= ormative language, it seems better to follow the style of the description a= bout the revertive behavior in RFC 4090.

·        Security Consi= derations

I believe that the Source-Detect approach introduces several security= concerns that were not in scope of RFC 4090. For example, the Source requi= red to monitor S-R1 path thus increasing, if not opening possibility of DDoS attack.

Huaimo: From RSVP-TE p= rotocol’s point of view, there is no RSVP-TE message transmitted betw= een Source S and primary ingress R1. For Source S to detect the failure of = primary ingress R1, if a bfd session is used between S and R1,  the bfd messages between S and R1 need to be trust= ed. It seems that bfd authentication is defined in RFC 5880 and may be used= .  

BTW, the traffic is al= ready sent to primary ingress R1  from source S, why monitoring the li= nk between S and R1 increase possibility of DDoS attack? Bad (or attack) me= ssages can be sent to S or R1 even though there is not any monitoring on the link between S and R1.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

 

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Tuesday, April 21, 2015 8:27 AM
To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-p= rotection@tools.ietf.org; teas-chairs@ietf.org<= span style=3D"font-size: 10.0pt;font-family:"Tahoma","sans-serif"">; teas@ietf.org
Cc: mpls@ietf.org= ; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protect= ion

 

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below with [Huaimo 2].<= /span>

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, April 16, 2015 7:58 PM
To: Huaimo Chen; draft-ietf-teas-rsvp-ingress-prot= ection@tools.ietf.org; teas-chairs@ietf.org<= span style=3D"font-size: 10.0pt;font-family:"Tahoma","sans-serif"">; teas@ietf.org
Cc: mpls@ietf.org= ; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protect= ion

 

Hi Huaimo,<= /span>

thank you for kind con= sideration of my comments. Please find more in-lined and tagged GIM>>= notes.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Sunday, April 12, 2015 11:04 AM
To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-p= rotection@tools.ietf.org; teas-chairs@ietf.org<= span style=3D"font-size: 10.0pt;font-family:"Tahoma","sans-serif"">; teas@ietf.org
Cc: mpls@ietf.org= ; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protect= ion

 

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: mpls [mailto:mpls-bounces= @ietf.org] On Behalf Of Gregory Mirsky
Sent: Sunday, April 12, 2015 2:04 AM
To: draft-ietf-teas-rsvp-ingress-protection@tools.= ietf.org; teas-chairs@ietf.org<= span style=3D"font-size: 10.0pt;font-family:"Tahoma","sans-serif"">; teas@ietf.org
Cc: mpls@ietf.org= ; rtg-bfd@ietf.org
Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection<= o:p>

 

Dear Editors, chairs, WG community,

please find my comments to the current version of yo= ur work below:

·        Introduction

o   The first paragraph may leave an impression = that local protection of transit LSRs is not being already addressed, neith= er by RFC 4090, nor RFC 4875;

[Huaimo] Will revise i= t accordingly.

o   I think that “global protection”= is not commonly used term, “end-to-end protection” seems to be= commonly used instead.

[Huaimo] It seems that= “global protection” is better here since we mentioned “l= ocal protection” here. It seems that Global Protection is used often.=

·        Section 3.1

o   Third paragraph contains the following requi= rement:

“For a P2P LSP, af= ter the primary ingress fails, the backup ingress must use a method to reli= ably detect the failure of the primary ingress before the PATH message for = the LSP expires at the next hop of the primary ingress.”

But that is not obvious = that such requirement is really needed. Since this is RSVP-TE LSP, why not = to use MP2MP construct and let the Source node to control switchover. Espec= ially since, as noted in the last paragraph of Section 2.1, primary and backup ingress nodes must be connected by a lo= gical link, which in general case will be a tunnel. Thus this solution puts= a requirement, implicitly though, to instantiate a tunnel per protection g= roup, tunnel that would not be used to carry traffic.

[Huaimo] The requireme= nt above seems necessary. If the backup ingress does not detect the failure= of the primary ingress before the timer for the PATH message for the LSP a= t the next hop of the primary ingress expires, the LSP will be down after the primary ingress fails. If the back= up ingress detects the failure and sends/refreshes the PATH message to the = next hop before the timer expires after the primary egress fails, the LSP w= ill continue being up and carry the traffic from the backup ingress via the backup LSP. =

For a P2P LSP, it seem= s that MP2MP construct is not used in RFC 4090 to protect a transit node of= a P2P LSP. The logical link between the primary ingress and the backup ing= ress can be a direct link or a tunnel. It seems that a direct link is common.

GIM>> I think it= is strange to cite requirement on scale of seconds if not tens of seconds = in discussion of method of local protection that supposed to perform protec= tion switchover in sub-second if not sub-50msec time.

[Huaimo 2] The require= ment is for the control plane. More specifically, it is for the PATH messag= e (not to be cleaned up) for the LSP at the next hop of the primary ingress= of the LSP when the primary ingress fails. After the primary ingress fails, the next hop will not receive any = PATH message from the primary ingress. In order to prevent the PATH message= from clean up at the next hop, the backup ingress seems required to detect= the failure of the primary ingress and send/refresh the PATH message to the next hop before the PATH message = is cleaned up. Thus it seems reasonable for the requirement to have the tim= e for detecting the failure of the primary ingress in seconds or even tens = of seconds instead of sub-seconds or within 50 ms.

 

o   In addition, what is importance of requireme= nt quoted above:

“… before th= e PATH message for the LSP expires at the next hop of the primary ingress&#= 8221;

[Huaimo] This seems ve= ry important. If the timer for the PATH message for the LSP at the next hop= of the primary egress expires, then the LSP will be down. So the PATH mess= age must be refreshed before the timer for the PATH message for the LSP expires at the next hop of the primary LS= P.

GIM>> As noted a= bove, these seem as requirements of different scale.

[Huaimo 2] See the exp= lanation above.

 

o   Fourth paragraph makes very questionable ass= umption in:

“After the primary= ingress fails, it will not be reachable after routing convergence.”<= o:p>

I believe that if OAM se= ssion is between two nodes there’s no reliable way to differentiate b= etween node and link failure. Thus, to declare a node unreachable there mus= t be N tunnels for N OAM sessions that monitor all possible paths between two nodes. (Note, that if there was no requirem= ent to use a tunnel between primary and backup ingress, multi-hop BFD could= be used though its detection time being limited by IGP convergence, which = may be too slow comparing with your requirement of tens milliseconds).

[Huaimo] It is true th= at “After the primary ingress fails, it will not be reachable after r= outing convergence.”  From routing’s point of view, there = is no need for us to have any OAM session between two nodes. The timer for a PATH message seems in tens of seconds. Routing convergence= is not limited to tens of milliseconds.

GIM>> Routing co= nvergence may take seconds. Is that acceptable as failure detection time fo= r local protection? Protection switchover expected to be fast, perhaps on s= ub-50 msec scale. From TDM world we carry 10 msec failure detection, and BFD implementations can support that. but h= ere, it appears, you describe failure detection mechanism with detection ti= me on scale of seconds if not tens of seconds.

[Huaimo 2] The routing= convergence is for the control plane. Refer to the explanation above.=

 

·        Section 5.1

o   Regarding “Ingress local protection in= use” flag

As demonstrated earlier,= backup ingress node has no reliable way to detect that primary ingress nod= e is not reachable to the Source and thus protection must be activated.

[Huaimo] It seems that= there is no need for the backup ingress to detect whether the primary ingr= ess is reachable to the Source and the focus is on the failure of the prima= ry ingress.

GIM>> In that ca= se, the text is not needed either.

[Huaimo 2] Can you giv= e more details regarding to “the text is not needed either”? Wh= ich part of the text (do you think) is not needed in section 5.1?

 

Considering that backup ingress may initiate describ= ed in the document actions not when primary ingress became unavailable to S= ource, I believe that cases that may produce false positives must be remove= d along with extensions that intended to support these cases. In my opinion, the only viable case of ingress pro= tection is Source-centric where Source monitors availability of both primar= y and backup ingress nodes and controls traffic switchover. I’d ask W= G to discuss these comments and, if agreed, ask Editors to make appropriate changes to the document.

[Huaimo] It seems that= the current version already indicates that the source-detect (i.e., Source= detects the failure of the primary ingress and switches traffic to the bac= kup ingress when the primary ingress fails) is used.  There were a few of modes for detecting the failure = of the primary ingress that were proposed in the previous versions of the d= ocument. A different mode may have a different control on the traffic switc= h over and/or forwarding.  After discussions, the current version selects the source-detect.

GIM>> If this is= historical part, then it may be moved to Appendix or taken from the docume= nt altogether.

[Huaimo 2] A couple of= detection modes were removed from the document. One more will be smoothed = out. Thus there will be only one mode in the document.

 

Can you give more deta= ils about the cases in which false positives may be produced?

GIM>> If current= proposal is limited to Source-detect case only  then possibility of f= alse positive/negative depends on Source to Ingress connection and OAM mech= anism used. But that is deployment issue and is outside of scope of this document

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_5316A0AB3C851246A7CA5758973207D44E4BF71BSJCEML701CHMchi_-- From nobody Fri Dec 18 14:29:36 2015 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA2E1B398C; Fri, 18 Dec 2015 14:26:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: , , , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151218222638.30243.60692.idtracker@ietfa.amsl.com> Date: Fri, 18 Dec 2015 14:26:38 -0800 Archived-At: X-Mailman-Approved-At: Fri, 18 Dec 2015 14:29:35 -0800 Cc: Deborah Brungard , Common Control and Measurement Plane Discussion List , JP Vasseur , Traffic Engineering Architecture and Signaling Discussion List , Alia Atlas , Vishnu Pavan Beeram , The IETF Chair , Path Computation Element Discussion List , Alvaro Retana , David Sinicrope , Jonathan Hardwick , michael.fargano@centurylink.com, Lou Berger , Fatai Zhang , Daniele Ceccarelli , Julien Meuric Subject: [Teas] New Liaison Statement, "Achieving Packet Network Optimization using DWDM Interfaces" X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 22:26:38 -0000 Title: Achieving Packet Network Optimization using DWDM Interfaces Submission Date: 2015-12-18 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1449/ Please reply by 2016-01-25 From: "Michael Fargano" To: vbeeram@juniper.net, lberger@labn.net,akatlas@gmail.com,aretana@cisco.com,db3546@att.com,jonathan.hardwick@metaswitch.com,jpv@cisco.com,julien.meuric@orange.com,daniele.ceccarelli@ericsson.com,zhangfatai@huawei.com Cc: Alvaro Retana ,Deborah Brungard ,Julien Meuric ,David Sinicrope ,Jonathan Hardwick ,Fatai Zhang ,Alia Atlas ,Path Computation Element Discussion List ,Vishnu Pavan Beeram ,The IETF Chair ,Daniele Ceccarelli ,Traffic Engineering Architecture and Signaling Discussion List ,Lou Berger ,Common Control and Measurement Plane Discussion List ,JP Vasseur , Response Contacts: michael.fargano@centurylink.com Technical Contacts: Purpose: For comment Body: Dear IETF Routing Area and Working Group Leaders: Thank you very much for your timely response to our last liaison concerning our document WT-319 Part B, Achieving Packet Network Optimization using DWDM Interfaces – Physically Separated, Logically Separated. We understand the time constraints you faced with IETF94. We appreciate your effort to send us preliminary feedback on the document despite these constraints and your kind offer to do a thorough technical review of our document. We respect the expertise of the IETF Routing Area and graciously accept your offer. We discussed and addressed your preliminary feedback in our recent Puerto Vallarta meeting (Nov 16-20). Attached, please find an updated version of the document for your review and comment. Our next meeting is February 1-6, 2016 in Hong Kong. If possible, we would appreciate your response by January 25, 2016 to help us prepare for our meeting. Please let us know if this time frame is insufficient. We want to again express our appreciation for your continued consideration and support with this important topic. Sincerely, Michael Fargano, Broadband Forum Technical Committee Chair Attachments: Straw Ballot https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-12-18-broadband-forum-rtg-ccamp-pce-teas-achieving-packet-network-optimization-using-dwdm-interfaces-attachment-1.pdf Liaison https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-12-18-broadband-forum-rtg-ccamp-pce-teas-achieving-packet-network-optimization-using-dwdm-interfaces-attachment-2.pdf From nobody Sat Dec 19 07:42:44 2015 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DCE1A8A74; Sat, 19 Dec 2015 07:42:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151219154240.13615.45797.idtracker@ietfa.amsl.com> Date: Sat, 19 Dec 2015 07:42:40 -0800 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-egress-protection-03.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2015 15:42:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Extensions to RSVP-TE for LSP Egress Local Protection Authors : Huaimo Chen Ning So Autumn Liu Tarek Saad Fengman Xu Filename : draft-ietf-teas-rsvp-egress-protection-03.txt Pages : 17 Date : 2015-12-19 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting egress nodes of a Traffic Engineered (TE) Label Switched Path (LSP), which is a Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-egress-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-teas-rsvp-egress-protection-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-egress-protection-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 31 09:06:41 2015 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1357F1A87A9; Thu, 31 Dec 2015 09:06:35 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151231170635.21239.70729.idtracker@ietfa.amsl.com> Date: Thu, 31 Dec 2015 09:06:35 -0800 Archived-At: Cc: db3546@att.com, teas-chairs@ietf.org, teas@ietf.org, draft-ietf-teas-rsvp-te-domain-subobjects@ietf.org, vbeeram@juniper.net, The IESG , rfc-editor@rfc-editor.org Subject: [Teas] Document Action: 'Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering (RSVP-TE)' to Experimental RFC (draft-ietf-teas-rsvp-te-domain-subobjects-05.txt) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2015 17:06:35 -0000 The IESG has approved the following document: - 'Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering (RSVP-TE)' (draft-ietf-teas-rsvp-te-domain-subobjects-05.txt) as Experimental RFC This document is the product of the Traffic Engineering Architecture and Signaling Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-domain-subobjects/ Technical Summary The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further Exclude Routes extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup. This document specifies new subobjects to include or exclude domain during path setup where domain is a collection of network elements within a common sphere of address management or path computational responsibility (such as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS)). This is a companion document to Path Computation Element Protocol (PCEP) extensions for the domain sequence [PCE-DOMAIN] (http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-domain-sequence/). Working Group Summary This document moved from the CCAMP WG to TEAS WG as part of the routing WG changes. The progress of the draft through the WG (first CCAMP, then TEAS) has been smooth. Document Quality The base (G)MPLS RSVP protocol has been implemented. The extensions defined in this document are compatible with earlier implementations. There have been no public statements on implementation. Three of the four authors are from the same vendor organization while the fourth is from a research institute – implementation for experimental purposes is expected. Personnel Who is the Document Shepherd? Vishnu Pavan Beeram Who is the Responsible Area Director? Deborah Brungard