From nobody Sat Apr 11 23:04:01 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7D71B34DB; Sat, 11 Apr 2015 23:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.5 X-Spam-Level: X-Spam-Status: No, score=-101.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Bg9XuZOWSdRu; Sat, 11 Apr 2015 23:03:56 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.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 0AB731B34D8; Sat, 11 Apr 2015 23:03:55 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-7b-5529b4114d58 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F3.FD.12456.214B9255; Sun, 12 Apr 2015 01:53:54 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0210.002; Sun, 12 Apr 2015 02:03:46 -0400 From: Gregory Mirsky To: "draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Subject: Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Topic: Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Index: AdBz6EeHlPEjW31GTZaF4ZwMtm3+Cg== Date: Sun, 12 Apr 2015 06:03:46 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B948347eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXRPoK7QFs1Qg6M7xSwuPnzKbHFr6UpW i89/tjFaNM3dxWTR+mMHiwOrx5IlP5k8vlz+zBbAFMVlk5Kak1mWWqRvl8CVsev+EfaCLXMZ K37OXM3SwPirg7GLkZNDQsBE4tmthWwQtpjEhXvrgWwuDiGBo4wS7dvfsUA4yxklfgOtAqli EzCSeLGxhx3EFhE4zSjxpVEJxGYW8JK49HwaM4gtLGAr0d/9hgmixknizLIrULaexJO578G2 sQioSmz7+JQFxOYV8JV4/PQeWJwR6Irvp9YwQcwUl7j1ZD4TxHUCEkv2nGeGsEUlXj7+xwph K0l8/D2fHaI+X2Lh+dtsEDMFJU7OfMIygVF4FpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY +8yBx0zI4gsY2VcxcpQWp5blphsZbGIERtIxCTbdHYx7XloeYhTgYFTi4X3grhEqxJpYVlyZ e4hRmoNFSZx30YODIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYhX0OJQgcSRWNLD3yTClF Idn9TnS22wvXBfnt/1f2fN5qLVvA/dm59ujJBeIV7wMuXjkVbrJy+36rzw9keCeYVlm98L8W P63tV5n+/bIbu88uVg9tttFnmPJ9v43V2h7pw8kz9klFB35qaBK/drRJVPf2v8l7sxztcooS 84quzv4gaGEcyletxFKckWioxVxUnAgAAAoC14UCAAA= Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 06:03:59 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B948347eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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; o I think that "global protection" is not commonly used term, "end-to-end= protection" seems to be commonly used instead. * 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. 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" 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). * 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. 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. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B948347eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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;

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

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

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;

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

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

 

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.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B948347eusaamb103erics_-- From nobody Sun Apr 12 11:04:28 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1BB1A1B60; Sun, 12 Apr 2015 11:04:25 -0700 (PDT) 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 r_K4h-p9ygPo; Sun, 12 Apr 2015 11:04:19 -0700 (PDT) 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 127251A1B5E; Sun, 12 Apr 2015 11:04:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRH69625; Sun, 12 Apr 2015 18:04:15 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 12 Apr 2015 19:04:14 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Sun, 12 Apr 2015 11:03:39 -0700 From: Huaimo Chen To: Gregory Mirsky , "draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Topic: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Index: AdBz6EeHlPEjW31GTZaF4ZwMtm3+CgBSx/EQ Date: Sun, 12 Apr 2015 18:03:38 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E37EE98@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B948347@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.94] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D44E37EE98SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 18:04:26 -0000 --_000_5316A0AB3C851246A7CA5758973207D44E37EE98SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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@iet= f.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. 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. 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. * 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. 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. Can you give more details about the cases in which false positives may be p= roduced? Regards, Greg --_000_5316A0AB3C851246A7CA5758973207D44E37EE98SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: mpls [ma= ilto: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-cha= irs@ietf.org; 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.

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.

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.

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

 

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.

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

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_5316A0AB3C851246A7CA5758973207D44E37EE98SJCEML701CHMchi_-- From nobody Mon Apr 13 11:58:40 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ABE1B2FDD; Mon, 13 Apr 2015 11:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.8 X-Spam-Level: X-Spam-Status: No, score=-102.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 mmZbqyi_vR7v; Mon, 13 Apr 2015 11:58:35 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965A61B2A2D; Mon, 13 Apr 2015 11:58:35 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-5d-552baee739f4 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 40.FB.17241.7EEAB255; Mon, 13 Apr 2015 13:56:23 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Mon, 13 Apr 2015 14:58:28 -0400 From: Gregory Mirsky To: "draft-ietf-teas-rsvp-egress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Subject: Comments to draft-ietf-teas-rsvp-egress-protection Thread-Topic: Comments to draft-ietf-teas-rsvp-egress-protection Thread-Index: AdB055+jr3+smJ3uSuiCZj3/NJvp6A== Date: Mon, 13 Apr 2015 18:58:28 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B948D85@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B948D85eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXSPn+7zddqhBluatS2mvv3JbHFr6UpW i89/tjFaNM3dxWTR+mMHiwOrx5IlP5k8vlz+zBbAFMVlk5Kak1mWWqRvl8CVMWFNL3PBdM+K 8xPOsjQwbrfvYuTgkBAwkZhxuqiLkRPIFJO4cG89WxcjF4eQwFFGiYWXeplBEkICyxklNp4N A7HZBIwkXmzsYQexRQROMkr83Q5mMwt4SVx6Pg2sXljARmLe5S5GkPkiAo4SKxfnQJTrSax5 DtHKIqAq8flLHwtICa+Ar8ST7fogYUagE76fWsMEMVFc4taT+UwQpwlILNlznhnCFpV4+fgf K4StJDFp6TlWiPp8ie/rp7CA2LwCghInZz5hmcAoPAvJqFlIymYhKYOI60gs2P2JDcLWlli2 8DUzjH3mwGMmZPEFjOyrGDlKi1PLctONDDcxAqPnmASb4w7GBZ8sDzEKcDAq8fAmVGmFCrEm lhVX5h5ilOZgURLnLbtyMERIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD4+GANV6lIdocZzVW qm8+3rrleElRfmzOPKbFO9yfJlj2qXVvYZZTupPJ929XiUWXvoXCcxZbz51pb2bGXDnO4rFG Xe36qh1Cvh8c02yE70hYt3Us0U5fYv4rw5UtwuNY3Ycbv23/ydxfdvqkS9a/r+XyD24rHpu3 58izKRumFDjlXQ25XM56XomlOCPRUIu5qDgRAKBq0SN/AgAA Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 18:58:38 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B948D85eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. 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. * 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. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B948D85eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.

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.

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

 

Regards,

    &= nbsp;           Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B948D85eusaamb103erics_-- From nobody Mon Apr 13 20:19:37 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE37C1B3291; Mon, 13 Apr 2015 20:19:35 -0700 (PDT) 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 L8qd5lRbyHBD; Mon, 13 Apr 2015 20:19:33 -0700 (PDT) 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 B057F1B3293; Mon, 13 Apr 2015 20:19:31 -0700 (PDT) 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 BUU73010; Tue, 14 Apr 2015 03:19:30 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Apr 2015 04:19:29 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Mon, 13 Apr 2015 20:19:26 -0700 From: Huaimo Chen To: Gregory Mirsky , "draft-ietf-teas-rsvp-egress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Subject: RE: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection Thread-Topic: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection Thread-Index: AdB055+jr3+smJ3uSuiCZj3/NJvp6ABbWMEw Date: Tue, 14 Apr 2015 03:19:26 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E37F079@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B948D85@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B948D85@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.193] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D44E37F079SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 03:19:36 -0000 --_000_5316A0AB3C851246A7CA5758973207D44E37F079SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. 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. * 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. Regards, Greg --_000_5316A0AB3C851246A7CA5758973207D44E37F079SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: mpls [ma= ilto: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-chai= rs@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.

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.

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

 

Regards,

    &= nbsp;           Greg=

--_000_5316A0AB3C851246A7CA5758973207D44E37F079SJCEML701CHMchi_-- From nobody Thu Apr 16 16:58:12 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D641A033B; Thu, 16 Apr 2015 16:58:09 -0700 (PDT) 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 dKOP9Gn9E8Hz; Thu, 16 Apr 2015 16:58:04 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.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 A599C1A028A; Thu, 16 Apr 2015 16:58:03 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-04-552ff59759ef Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FC.95.12456.795FF255; Thu, 16 Apr 2015 19:47:04 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Thu, 16 Apr 2015 19:57:58 -0400 From: Gregory Mirsky To: Huaimo Chen , "draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Topic: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Index: AQHQdUsbhXhJtQ5lC02wWl3AD+NymZ1QUc6g Date: Thu, 16 Apr 2015 23:57:58 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B94CD49@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D44E37EE98@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D44E37EE98@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_7347100B5761DC41A166AC17F22DF1121B94CD49eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyuXSPn+6Mr/qhBlOPM1lcfPiU2WLr0yuM FreWrmS1+PxnG6NF09xdTBatP3awOLB5tBx5y+qxZMlPJo8vlz+zBTBHcdmkpOZklqUW6dsl cGVMObyfreDyG8aKGx8WMzYwLj7D2MXIySEhYCJx9cFxJghbTOLCvfVsILaQwFFGifvTNboY uYDs5YwSXe8+s4Mk2ASMJF5s7GEHSYgIfGaU+LL6CStIglnAS+LS82nMILawgLtE180DYLaI gIfEimtzgKZyANlGEm83uIKEWQRUJV7uewZWwivgK3Fv/zw2iGUzGSV2rPwMdgWnQJjE7D3z wK5jBLru+6k1TBC7xCVuPZkPdbWAxJI955khbFGJl4//sULYihL7+qezQ9TnSzye3gW1TFDi 5MwnLBMYRWchGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FSNHaXFqWW66 kcEmRmA0HpNg093BuOel5SFGAQ5GJR7eBeL6oUKsiWXFlbmHGKU5WJTEeRc9OBgiJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgTGaZffp/YX/tk/e+2CxgsqKmKinqqyRxlOPHfH6UN54SeVa xuE5B87JFCkK/Q/8bPz9Xkb6t3b1eTpFV+oVLI0erj03W3TDt5JTs5fee/0gbkd2jZ2x7vvU ksfF0oGXDV+v/bI6tLV5fSLDA3XbdQ0iXEILapjun35+la2ofPJm/dspy/LVbzgrsRRnJBpq MRcVJwIAJY6OpKcCAAA= Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 23:58:10 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B94CD49eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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;= 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. 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. 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. * 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. 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. 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_7347100B5761DC41A166AC17F22DF1121B94CD49eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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-protection@tools.ie= tf.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 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<= 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.

 

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.

 

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.

 

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

 

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.

 

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_7347100B5761DC41A166AC17F22DF1121B94CD49eusaamb103erics_-- From nobody Sat Apr 18 04:49:22 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B087A1A6F5D; Sat, 18 Apr 2015 04:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Il6yRqLGhyTf; Sat, 18 Apr 2015 04:49:20 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5CAC1A1EF9; Sat, 18 Apr 2015 04:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1180; q=dns/txt; s=iport; t=1429357759; x=1430567359; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7f6gAKg4q8PR7d9lkuQWtZaVdrnhk7gKgHKob2Bv+0E=; b=JXSZZdipAhm0DO/Tbyv8uSLwGZeNfeLr4pCyBvACR2izjz8eoWKnI9B6 TRB/MRouONNGQUPGLrmLNsdD5JbpRG3M1nN3ayiEudjRqH4W+lC+Jk7+w RCo37X7NsEmNfccLhI5/iD7z8bOumQbCIVeCaZSoER/MsQVDMa8q3mGhi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ByBABFRDJV/5FdJa1dgwxSXAXFQ2YJgU+GAwKBODgUAQEBAQEBAX2EIAEBAQQ6PwwEAgEIEQQBAQsUCQchERQJCAEBBAENBQiIDwMRDcF9DYU7AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLKYJHgVIRASAxBwaDEYEWAQSRI4N8hFaCbIM6iXOGQiKCHoFVbwGBCjmBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,599,1422921600"; d="scan'208";a="142409607" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP; 18 Apr 2015 11:49:19 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t3IBnIlh020173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 18 Apr 2015 11:49:19 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.170]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Sat, 18 Apr 2015 06:49:18 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "rtg-bfd@ietf.org" , "pals@ietf.org" , "l2tpext@ietf.org" Subject: RE: Requesting comments on SBFD-VCCV drafts Thread-Topic: Requesting comments on SBFD-VCCV drafts Thread-Index: AdBcG8bbDt4lFsaSQwiuvYh/1U3PNAdqn65w Date: Sat, 18 Apr 2015 11:49:17 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D543E79BF@xmb-rcd-x15.cisco.com> References: <315041E4211CB84E86EF7C25A2AB583D54337F7C@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D54337F7C@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.56.217] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Carlos Pignataro \(cpignata\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 11:49:21 -0000 Hello all, Including the L2TP list for comments from them on the two drafts describe= d in the email below. A gentle reminder to the pals and bfd WG lists. Pleas= e note that some discussion when these drafts were presented at PALS and BF= D WG at Dallas (IETF-92).=20 Thanks Prasad -----Original Message----- From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Vengada Prasad Govin= dan (venggovi) Sent: Wednesday, March 11, 2015 10:23 PM To: rtg-bfd@ietf.org; pals@ietf.org Cc: Jeffrey Haas (jhaas@pfrc.org); Carlos Pignataro (cpign= ata); agmalis@gmail.com; nobo.akiya.dev@gmail.com; Stewart Bryant (stbryant= ) Subject: [Pals] Requesting comments on SBFD-VCCV drafts Hello all, We have submitted two new drafts: a. draft-gp-pals-seamless-vccv: This draft defines the SBFD protocol operat= ion for VCCV. https://datatracker.ietf.org/doc/draft-gp-pals-seamless-vccv/ b. draft-gp-l2tpext-sbfd-discriminator: This draft defines AVPs for adverti= sement of SBFD discriminators in L2TP. We welcome comments/ feedback on these drafts. https://datatracker.ietf.org/doc/draft-gp-l2tpext-sbfd-discriminator/ Thanks Prasad From nobody Sun Apr 19 01:14:44 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0061B2A5E; Sun, 19 Apr 2015 01:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 r-wUVHEC4qnR; Sun, 19 Apr 2015 01:14:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AECEC1B2A67; Sun, 19 Apr 2015 01:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2261; q=dns/txt; s=iport; t=1429431280; x=1430640880; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7IIYKeQEBV0Hn23jIPCA6agwXu43SBhJDwZtCuEE7kM=; b=ibl+Sas+Z/haE8Q7GbAsZFOvZ/zOI7Eo/4CwvU8Cj7/cqMq3M1rjnpO9 FAK2foEmWAfxU58cJ9oSEV92zBAKKDE7HnC06AyN9g9i4n42FgAeifenn 6BlPs14afyFCMqEBFGsgTonJIA0/n5nY1lyBtkd5nkwEa4IIPyBje/Us0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DoBQCvYjNV/4UNJK1cgwxSXAXFT4I+hX8CAgKBI0wBAQEBAQF+hCABAQEEOj8MBAIBCBEEAQELFAkHIREUCQgBAQQBDQUIiA8DEQ3CWw2FOwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEizeCTYIGMQcGgxGBFgEEkSuDfIRXgm2DPIoAgnmDTiKCHoFVbwGBQ4EAAQEB X-IronPort-AV: E=Sophos;i="5.11,602,1422921600"; d="scan'208";a="412946823" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP; 19 Apr 2015 08:14:39 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t3J8EdVx014198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 19 Apr 2015 08:14:39 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.170]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Sun, 19 Apr 2015 03:14:39 -0500 From: "Vengada Prasad Govindan (venggovi)" To: Jiangyuanlong , "rtg-bfd@ietf.org" , "pals@ietf.org" Subject: RE: Requesting comments on SBFD-VCCV drafts Thread-Topic: Requesting comments on SBFD-VCCV drafts Thread-Index: AdBcG8bbDt4lFsaSQwiuvYh/1U3PNAKKHR4wBQ0YfaA= Date: Sun, 19 Apr 2015 08:14:39 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D543E7C38@xmb-rcd-x15.cisco.com> References: <315041E4211CB84E86EF7C25A2AB583D54337F7C@xmb-rcd-x15.cisco.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A8C38BB@szxema506-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A8C38BB@szxema506-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.42.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Carlos Pignataro \(cpignata\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 08:14:43 -0000 Hello Yuanlong, The intent of these drafts is not to deprecate BFD with SBFD but make them = co-existent. A guideline section will be included in the next revision as y= ou suggest. Thanks for your suggestion and apologies for the delay in the r= eply. Thanks to Andy Malis for pointing out the same. Thanks Prasad -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Tuesday, March 24, 2015 11:50 PM To: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org; pals@ietf.org Cc: Jeffrey Haas (jhaas@pfrc.org); Carlos Pignataro (cpign= ata); agmalis@gmail.com; nobo.akiya.dev@gmail.com; Stewart Bryant (stbryant= ) Subject: RE: Requesting comments on SBFD-VCCV drafts Hi Stewart, Jeffrey and other authors, If the purpose of this draft is not to deprecate the original VCCV BFD (0x1= 0) function for MPLS PW, please make it clear: - One option is clearly removing MPLS/PW-ACH Encapsulation from SBFD so tha= t BFD and SBFD complement with each other. - Another option is as the document describes, the same MPLS/PW is supporte= d by both SBFD and original BFD, then a guideline section is needed so that= consistent BFD type (SBFD or original BFD) can be chosen by the peer PEs (= e.g., both BFD types are supported by two PEs associated with a specific BF= D session). Regards, Yuanlong -----Original Message----- From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Vengada Prasad Govin= dan (venggovi) Sent: Thursday, March 12, 2015 12:53 AM To: rtg-bfd@ietf.org; pals@ietf.org Cc: Jeffrey Haas (jhaas@pfrc.org); Carlos Pignataro (cpign= ata); agmalis@gmail.com; nobo.akiya.dev@gmail.com; Stewart Bryant (stbryant= ) Subject: [Pals] Requesting comments on SBFD-VCCV drafts Hello all, We have submitted two new drafts: a. draft-gp-pals-seamless-vccv: This draft defines the SBFD protocol operat= ion for VCCV. https://datatracker.ietf.org/doc/draft-gp-pals-seamless-vccv/ b. draft-gp-l2tpext-sbfd-discriminator: This draft defines AVPs for adverti= sement of SBFD discriminators in L2TP. We welcome comments/ feedback on these drafts. https://datatracker.ietf.org/doc/draft-gp-l2tpext-sbfd-discriminator/ Thanks Prasad From nobody Tue Apr 21 08:27:47 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C0A1ACE5E; Tue, 21 Apr 2015 08:27:44 -0700 (PDT) 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 eGje1vuHflgg; Tue, 21 Apr 2015 08:27:36 -0700 (PDT) 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 9A1351ACE4D; Tue, 21 Apr 2015 08:27:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRQ88849; Tue, 21 Apr 2015 15:27:27 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Apr 2015 16:27:26 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Tue, 21 Apr 2015 08:27:23 -0700 From: Huaimo Chen To: Gregory Mirsky , "draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Topic: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Index: AdBz6EeHlPEjW31GTZaF4ZwMtm3+CgBSx/EQAOobtwAA2TtZ4A== Date: Tue, 21 Apr 2015 15:27:22 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E3804B5@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D44E37EE98@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B94CD49@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B94CD49@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.156] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D44E3804B5SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 15:27:44 -0000 --_000_5316A0AB3C851246A7CA5758973207D44E3804B5SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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; te= as-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, 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_5316A0AB3C851246A7CA5758973207D44E3804B5SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

Thanks for your comments.

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

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@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,<= /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.co= m]
Sent: Sunday, April 12, 2015 11:04 AM
To: Gregory Mirsky; 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-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; 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_5316A0AB3C851246A7CA5758973207D44E3804B5SJCEML701CHMchi_-- From nobody Tue Apr 21 12:59:02 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D417E1A1A20 for ; Tue, 21 Apr 2015 12:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 3pBCqNkn6y2h for ; Tue, 21 Apr 2015 12:59:00 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B75271A0277 for ; Tue, 21 Apr 2015 12:58:49 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 74311C16E; Tue, 21 Apr 2015 15:58:49 -0400 (EDT) Date: Tue, 21 Apr 2015 15:58:49 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: BFD generic crypto/sha documents Message-ID: <20150421195849.GA1600@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 19:59:01 -0000 https://datatracker.ietf.org/doc/draft-ietf-bfd-hmac-sha/ https://datatracker.ietf.org/doc/draft-ietf-bfd-generic-crypto-auth/ The following documents have expired and could use a refresh. Mail to the document aliases have yielded multiple bounces. :-) -- Jeff From nobody Fri Apr 24 00:45:14 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07AA1B2EC4; Fri, 24 Apr 2015 00:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 zvBvJ7h7W8KC; Fri, 24 Apr 2015 00:45:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC04B1B353D; Fri, 24 Apr 2015 00:44:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-mpls-mib-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150424074444.23105.22571.idtracker@ietfa.amsl.com> Date: Fri, 24 Apr 2015 00:44:44 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 07:45:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD Management Information Base (MIB) extensions for MPLS and MPLS-TP Networks Authors : Sam Aldrin Venkatesan Mahalingam Kannan KV Sampath Thomas D. Nadeau Filename : draft-ietf-bfd-mpls-mib-06.txt Pages : 23 Date : 2015-04-24 Abstract: This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it extends the BFD Management Information Base and describes the managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol for MPLS and MPLS-TP networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mpls-mib-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-mpls-mib-06 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 Sun Apr 26 11:33:55 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE711B2C36 for ; Sun, 26 Apr 2015 11:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 YnSa58t3t76A for ; Sun, 26 Apr 2015 11:33:51 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09071B2C2E for ; Sun, 26 Apr 2015 11:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1701; q=dns/txt; s=iport; t=1430073232; x=1431282832; h=from:to:cc:subject:date:message-id:mime-version; bh=2H2yB7h8yq3yx7q5vsdozCQ4CP+fKN3L4kcETL0yyOE=; b=bIyycxDzaWlwDFVY6vuS/ZMcvNNMHwv2kBrWGXuFlhq2P6r+s60cbXh9 jwwBvkBdPgmacz0LC4TFCbnalVaLCDYO4MFP4surDnhOFOiOqSJLaTPou 5FlrraxTJ4JCm3B/AWDmLC74z7SShqVK9s2lfsWg66WHdxqciKaTi/7dz s=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CMBACHLj1V/40NJK1cgwyBNIMVwiBmCYdWgR04FAEBAQEBAQGBCoQjBCNWEgEWNAI0JwQBDROIHbFYkz0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXkD2Cby+BFgWRVYFygTeHEIEig0iQdyNggQWCD4IzgQABAQE X-IronPort-AV: E=Sophos;i="5.11,652,1422921600"; d="asc'?scan'208";a="144687883" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP; 26 Apr 2015 18:33:52 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t3QIXou2027529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Apr 2015 18:33:51 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.188]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Sun, 26 Apr 2015 13:33:50 -0500 From: "Carlos Pignataro (cpignata)" To: Jeff Haas , Nobo Akiya Subject: S-BFD Document Status Thread-Topic: S-BFD Document Status Thread-Index: AQHQgE+KoAzE1zNTz0qnYCDorHLlSg== Date: Sun, 26 Apr 2015 18:35:16 +0000 Message-ID: <65EE612C-B125-4981-B3D3-6257F4FA99A4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.208.241] Content-Type: multipart/signed; boundary="Apple-Mail=_C4C9F182-FB67-4B2F-9877-6E6A05D142BD"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 18:33:53 -0000 --Apple-Mail=_C4C9F182-FB67-4B2F-9877-6E6A05D142BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, BFD Chairs, The first set of S-BFD documents (-base, -ip, and -use-cases) have been = stable for a while. Looking at the Milestones [1], the WG is past due on submitting these = three documents to the IESG. There is a small mention of this in the end = of the Minutes from Dallas, but nothing too definitive or explicit. There are no pending dependencies for -base. No dependencies for = -use-case, and -base is a dependency on -ip. Given all this, could you please initiate a WG LC on these three S-BFD = documents? Thanks, =E2=80=94 Carlos. [1] Mar 2015 Submit the BFD Seamless IP draft to the = IESG to be considered as a Proposed Standard draft-ietf-bfd-seamless-ip Mar 2015 Submit the BFD Seamless Base draft to = the IESG to be considered as a Proposed Standard draft-ietf-bfd-seamless-base Dec 2014 Submit the BFD Seamless Use Case = document to the IESG to be considered as a Proposed Standard draft-ietf-bfd-seamless-use-case --Apple-Mail=_C4C9F182-FB67-4B2F-9877-6E6A05D142BD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlU9L5EACgkQtfDPGTp3USz9UgCgrc+9RWIwM/w3c45bVh/IH87D vxIAn0AQOapsKjmjqYROQd920PmPllBp =SV9q -----END PGP SIGNATURE----- --Apple-Mail=_C4C9F182-FB67-4B2F-9877-6E6A05D142BD-- From nobody Tue Apr 28 16:29:35 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C4C1A8A03; Tue, 28 Apr 2015 16:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 I-JUsuLIy_C0; Tue, 28 Apr 2015 16:29:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A30E1A8A0C; Tue, 28 Apr 2015 16:29:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-seamless-use-case-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150428232931.27118.99810.idtracker@ietfa.amsl.com> Date: Tue, 28 Apr 2015 16:29:31 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 23:29:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Seamless Bidirectional Forwarding Detection (BFD) Use Case Authors : Manav Bhatia Satoru Matsushima Greg Mirsky Nagendra Kumar Filename : draft-ietf-bfd-seamless-use-case-02.txt Pages : 10 Date : 2015-04-28 Abstract: This document provides various use cases for Bidirectional Forwarding Detection (BFD) such that extensions could be developed to allow for simplified detection of forwarding failures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-use-case/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-02 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-use-case-02 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/