From stbryant@cisco.com Fri Jan 3 05:57:18 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC73B1ADFAF for ; Fri, 3 Jan 2014 05:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 8HBIilQs4ykd for ; Fri, 3 Jan 2014 05:57:16 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 81F961AD937 for ; Fri, 3 Jan 2014 05:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25828; q=dns/txt; s=iport; t=1388757428; x=1389967028; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=cMeGUnNvIiOnf4NBv2LjZR0T9WD19jCkQzrItgB5HDk=; b=ak5SUIKeV0S+LRWgrFsJyA1yVheGUWoR6bJLmZWu3zkkq27nxxtiqno9 5F/5A8CzIbeyZKMCX8JjcCkPrW0/UY8pBCGRhFQNh6gD7MBztqLECXRkS kr6uWZ1jkpBNYF0fYNHMLvhaMYlFVC07f5H1p6T4FDQqfu5fL9asA7ym4 0=; X-IronPort-AV: E=Sophos;i="4.95,598,1384300800"; d="scan'208,217";a="2475097" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 03 Jan 2014 13:57:07 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s03Dv773006310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jan 2014 13:57:07 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s03Dv5UJ015264; Fri, 3 Jan 2014 13:57:06 GMT Message-ID: <52C6C1B1.5050100@cisco.com> Date: Fri, 03 Jan 2014 13:57:05 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Bharath R , "rtgwg@ietf.org" , "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "imc.shand@gmail.com" , "cfilsfil@cisco.com" , "sprevidi@cisco.com" , "Ning.So@tatacommunications.com" Subject: Re: Regarding cost based algorithm for finding Extended P-Space. References: <9ecf740f25084ccd9834ffb0a63e60e2@BY2PR05MB568.namprd05.prod.outlook.com> In-Reply-To: <9ecf740f25084ccd9834ffb0a63e60e2@BY2PR05MB568.namprd05.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------080709010309060309070308" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 13:57:18 -0000 This is a multi-part message in MIME format. --------------080709010309060309070308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 03/01/2014 11:35, Bharath R wrote: > Hi, > I have a query on cost based formula for finding Extended P-space. > The current formula applies to Node y that is > 1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) > + D_opt(Protected_link.RemoteNode, Y)) Bharath I cannot see this text in the draft. Is it from the text or your code? Also the example below has been corrupted. Not that asymmetric costs are always problematic in LFA solutions, but it is not clear how frequently they show in real topologies other than by accident. Stewart > I guess the rationale behind the current formula is that the packet on > the LDP tunnel should not traverse the ProtectedLink. > But, please consider the following toplogy. > A2àB cost is 5 and A2àS cost is 3; (Both only in the direction as > indicated., the other direction cost is unity) > All other costs are unity. > Following the formula, both A1 and A2 can become backup neighbors(with > P-Space B and C). > However, an LDP tunnel setup via A2 will loopback to S, taking A2àSàA1 > path. > |-------------| > | S | > |-------------| > | | | > | | | > | | |ProtectedLink > | | | > | | | > | | | > --------------- | ---------------- > | | | > | | | > | | | > | | | > | |5 | > |-----------| |-----------| |-----------| > | A1 | | > A2 | | E | > |-----------| |-----------| |-----------| > | > | > | | > | | > | | > | | > |-----------| |-----------| > | B | > | D | > |-----------| |-----------| > | | > | | > | |-----------| | > |--------------| C |-----------| > |-----------| > How about using the following basic formula instead? > 2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) > Advantages: > > * The formula two ensures that the packet does not loopback to S. > * Also as per my understanding, if there is Neighbor Ni that > satisfies 1), but does not satisfy 2), it implies that there is > definitely one more Neigbhro Nj which satisfies 1) both 1) and 2). > > (Because if there is a neighbor satisfying 1) and not satisfy 2), then > the packet will loopback via some other neighbor which satisfies 2)). > > Given that formula 2) ensures that we don't select any neighbor which > simply loopbacks the packet to the source and forwards via other > viable Neighbor, it will be more advantageous to employ Formula 2). > Please let me know if I am missing something, or if there is a good > use case that may prefer backup-neighbor A2 in this example, over > backup neighbor A1.(Given that traffic will exit via A1 anyway). > Thanks and Regards, > Bharath R. -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------080709010309060309070308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 03/01/2014 11:35, Bharath R wrote:
Hi,
I have a query on cost based formula for finding Extended P-space.
The current formula applies to Node y that is
1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))

Bharath

I cannot see this text in the draft. Is it from the text or your code?

Also the example below has been corrupted.

Not that asymmetric costs are always problematic in LFA solutions, but
it is not clear how frequently they show in real topologies other than
by accident.

Stewart



 
I guess the rationale behind the current formula is that the packet on the LDP tunnel should not traverse the ProtectedLink.
 
 
But, please consider the following toplogy.
A2àB cost is 5 and A2àS cost is 3; (Both only in the direction as indicated., the other direction cost is unity)
All other costs are unity.
Following the formula, both A1 and A2 can become backup neighbors(with P-Space B and C).
However, an LDP tunnel setup via A2 will loopback to S, taking A2àSàA1 path.
 
                                                                 |-------------|
                                                                  |     S       |
                                                                  |-------------|
                                                                    |      |      |
                                                                   |      |      |
                                                                    |      |      |ProtectedLink
                                                                   |      |      |
                                                                    |      |      |
                                                 |      |      |
                                                  ---------------      |      ----------------
                                                  |                       |                          |
                                                  |                       |                          |
                                                  |                       |                          |
                                                  |                       |                          |
                                                  |                        |5                        |
                                            |-----------|         |-----------|        |-----------|
                                            |     A1   |         |    A2     |        |     E       |
                                            |-----------|         |-----------|        |-----------|
                                                  |                                                   |
                                                  |                                                |
                                                  |                                                    |
                                                  |                                                   |
                                                  |                                                   |
                               |-----------|                          |-----------|
                                            |     B       |                                |     D    | 
                                            |-----------|                                |-----------| 
                                                  |                                                  |
                                                  |                                                  |
                                                  |                  |-----------|              |
                                                  |--------------|     C      |-----------|
                                                                       |-----------|   
 
How about using the following basic formula instead?
2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))
 
 
Advantages:
  • The formula two ensures that the packet does not loopback to S.
  • Also as per my understanding, if there is Neighbor Ni that satisfies 1), but does not satisfy 2), it implies that there is definitely one more Neigbhro Nj which satisfies 1) both 1) and 2).
(Because if there is a neighbor satisfying 1) and not satisfy 2), then the packet will loopback via some other neighbor which satisfies 2)).

Given that formula 2) ensures that we don’t select any neighbor which simply loopbacks the packet to the source and forwards via other viable Neighbor, it will be more advantageous to employ Formula 2).
 
Please let me know if I am missing something, or if there is a good use case that may prefer backup-neighbor A2 in this example, over backup neighbor A1.(Given that traffic will exit via A1 anyway).
 
 
 
 
Thanks and Regards,
Bharath R.
 
 


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------080709010309060309070308-- From rbharath@juniper.net Fri Jan 3 06:40:21 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA52B1ADFB8 for ; Fri, 3 Jan 2014 06:40:21 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PREIIshUi_vU for ; Fri, 3 Jan 2014 06:40:18 -0800 (PST) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2003C1ADFB1 for ; Fri, 3 Jan 2014 06:40:17 -0800 (PST) Received: from mail78-db8-R.bigfish.com (10.174.8.242) by DB8EHSOBE010.bigfish.com (10.174.4.73) with Microsoft SMTP Server id 14.1.225.22; Fri, 3 Jan 2014 14:40:09 +0000 Received: from mail78-db8 (localhost [127.0.0.1]) by mail78-db8-R.bigfish.com (Postfix) with ESMTP id 38A50440219; Fri, 3 Jan 2014 14:40:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zzbb2dI98dI9371Ic89bhc85dhzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail78-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbharath@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(24454002)(479174003)(377454003)(199002)(189002)(19580405001)(19580395003)(83322001)(4396001)(49866001)(47736001)(19300405004)(50986001)(47976001)(87936001)(87266001)(2656002)(81686001)(16236675002)(81816001)(80976001)(74876001)(15202345003)(74706001)(15975445006)(76576001)(76796001)(76786001)(18717965001)(85306002)(81342001)(81542001)(69226001)(74316001)(83072002)(85852003)(56816005)(90146001)(33646001)(74366001)(65816001)(31966008)(74502001)(74662001)(80022001)(54316002)(59766001)(77982001)(63696002)(47446002)(79102001)(56776001)(53806001)(46102001)(51856001)(76482001)(66066001)(54356001)(24736002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB567; H:BY2PR05MB568.namprd05.prod.outlook.com; CLIP:116.197.184.15; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail78-db8 (localhost.localdomain [127.0.0.1]) by mail78-db8 (MessageSwitch) id 1388760007383240_27064; Fri, 3 Jan 2014 14:40:07 +0000 (UTC) Received: from DB8EHSMHS010.bigfish.com (unknown [10.174.8.240]) by mail78-db8.bigfish.com (Postfix) with ESMTP id 57592780049; Fri, 3 Jan 2014 14:40:07 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS010.bigfish.com (10.174.4.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 3 Jan 2014 14:40:05 +0000 Received: from BY2PR05MB567.namprd05.prod.outlook.com (10.141.220.22) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 3 Jan 2014 14:40:04 +0000 Received: from BY2PR05MB568.namprd05.prod.outlook.com (10.141.220.27) by BY2PR05MB567.namprd05.prod.outlook.com (10.141.220.22) with Microsoft SMTP Server (TLS) id 15.0.842.7; Fri, 3 Jan 2014 14:40:02 +0000 Received: from BY2PR05MB568.namprd05.prod.outlook.com ([10.141.220.27]) by BY2PR05MB568.namprd05.prod.outlook.com ([10.141.220.27]) with mapi id 15.00.0842.003; Fri, 3 Jan 2014 14:40:02 +0000 From: Bharath R To: "stbryant@cisco.com" , "rtgwg@ietf.org" , "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "imc.shand@gmail.com" , "cfilsfil@cisco.com" , "sprevidi@cisco.com" , "Ning.So@tatacommunications.com" Subject: RE: Regarding cost based algorithm for finding Extended P-Space. Thread-Topic: Regarding cost based algorithm for finding Extended P-Space. Thread-Index: Ac8Id9tfGC7DxP3KTpWaJMen1KzBtgAE9PWAAADSKUA= Date: Fri, 3 Jan 2014 14:40:02 +0000 Message-ID: References: <9ecf740f25084ccd9834ffb0a63e60e2@BY2PR05MB568.namprd05.prod.outlook.com> <52C6C1B1.5050100@cisco.com> In-Reply-To: <52C6C1B1.5050100@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.15] x-forefront-prvs: 00808B16F3 Content-Type: multipart/alternative; boundary="_000_cd72c8f9dde94d3ca2f7694f04bee95aBY2PR05MB568namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Fri, 03 Jan 2014 07:49:07 -0800 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 14:40:22 -0000 --_000_cd72c8f9dde94d3ca2f7694f04bee95aBY2PR05MB568namprd05pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for your reply Stuart Sorry, the formula is not verbatim from the draft, but if you refer to the = formula in Compute_Extended_P_Space()snippet in the http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-04, you will find that the formula used maps to D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_opt(= Protected_link.RemoteNode, Y)) Here: S : Source Node. Ni: Neighbor, D_opt(x, y): Optimal distance from x to y. Sorry for the corruption in topology. I am recreating it here: and A2-->S cost is 5; (Only in the direction as indicated., the other direc= tion cost is unity) All other costs are unity. |--------= -----| | = S | |--------= -----| | |= | | |= |ProtectedLink | |= | | |= | --------------- | = ---------------- | |= | | |= | | |= | | |= 5 | |-----------| |--------= ---| |-----------| | A1 | | A2 = | | E | |-----------| |--------= ---| |-----------| | = | | = | | = | |-----------| = |-----------| | B | = | D | |-----------| = |-----------| | = | | = | | |-----= ------| | |--------------| C = |-----------| |----= -------| Yes, even I am not sure of the practicality of the above topology, But, my only point was that we have a simpler, easier to use formula: D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) to find viable backups Neighbors to reach P-Space. Further, the formula does not result in exclusion of any viable Neighbor th= at loop-back to the source. Would be great if you can comment on that. Thanks and Regards, Bharath R. From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Friday, January 03, 2014 7:27 PM To: Bharath R; rtgwg@ietf.org; draft-ietf-rtgwg-remote-lfa@tools.ietf.org; = imc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So@tataco= mmunications.com Subject: Re: Regarding cost based algorithm for finding Extended P-Space. On 03/01/2014 11:35, Bharath R wrote: Hi, I have a query on cost based formula for finding Extended P-space. The current formula applies to Node y that is 1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_= opt(Protected_link.RemoteNode, Y)) Bharath I cannot see this text in the draft. Is it from the text or your code? Also the example below has been corrupted. Not that asymmetric costs are always problematic in LFA solutions, but it is not clear how frequently they show in real topologies other than by accident. Stewart I guess the rationale behind the current formula is that the packet on the = LDP tunnel should not traverse the ProtectedLink. But, please consider the following toplogy. A2-->B cost is 5 and A2-->S cost is 3; (Both only in the direction as indic= ated., the other direction cost is unity) All other costs are unity. Following the formula, both A1 and A2 can become backup neighbors(with P-Sp= ace B and C). However, an LDP tunnel setup via A2 will loopback to S, taking A2-->S-->A1 = path. |---------= ----| | S = | |--------= -----| | = | | | |= | | = | |ProtectedLink | |= | | = | | | | | --------------- | = ---------------- | |= | | |= | | |= | | |= | | = |5 | |-----------| |--------= ---| |-----------| | A1 | | A2 = | | E | |-----------| |--------= ---| |-----------| | = | | = | | = | | = | | = | |-----------| |----= -------| | B | = | D | |-----------| = |-----------| | = | | = | | |-----= ------| | |--------------| C = |-----------| |---= --------| How about using the following basic formula instead? 2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) Advantages: =B7 The formula two ensures that the packet does not loopback to S. =B7 Also as per my understanding, if there is Neighbor Ni that sati= sfies 1), but does not satisfy 2), it implies that there is definitely one = more Neigbhro Nj which satisfies 1) both 1) and 2). (Because if there is a neighbor satisfying 1) and not satisfy 2), then the = packet will loopback via some other neighbor which satisfies 2)). Given that formula 2) ensures that we don't select any neighbor which simpl= y loopbacks the packet to the source and forwards via other viable Neighbor= , it will be more advantageous to employ Formula 2). Please let me know if I am missing something, or if there is a good use cas= e that may prefer backup-neighbor A2 in this example, over backup neighbor = A1.(Given that traffic will exit via A1 anyway). Thanks and Regards, Bharath R. -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_cd72c8f9dde94d3ca2f7694f04bee95aBY2PR05MB568namprd05pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thank you for your reply = Stuart

 <= /p>

Sorry, the formula is not= verbatim from the draft, but if you refer to the formula in

= Compute_Extended_P_Space()snippet

= in the http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-04,

=  

= you will find that the formula used maps to

D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected= _link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))

Here:

S : Source Node.

Ni:  Neighbor,

D_opt(x, y): Optimal distance from x to y.

 

Sorry for the corruption in topology. I am recreating it= here:

and A2=E0S cost is 5; (Only in the direction as indicated., the other direction cos= t is unity)

All other costs are unity.

 

 

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |        S &nbs= p;     |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =       |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |    &nbs= p; |       |ProtectedLink

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =       |

         &n= bsp;            = ;            &n= bsp;            = ;             &= nbsp;      |      | =       |

         &n= bsp;            = ;            &n= bsp;            = ;   ---------------     |   &n= bsp;  ----------------

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              | =             &nb= sp;            |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  &nbs= p;            &= nbsp;          |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  = ;            &n= bsp;           |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |5=             &nb= sp;           |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; A1    |          = ;|    A2     |    &n= bsp;   |     E       |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;   |           = ;            &n= bsp;             &nb= sp;             |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =                =              &= nbsp;           |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              &n= bsp;             &nb= sp;             |

         &n= bsp;            &nbs= p;             =         |-----------|  &n= bsp;            &nbs= p;              = ; |-----------|

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; B       |       =              &n= bsp;           | &nb= sp;   D      | 

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;            =             &nb= sp;     |-----------| 

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =         |-----------|    =           |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |--------------|     C    =   |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          |-----------| &n= bsp; 

=  

= Yes, even I am not sure of the practicality of the above topology,

= But, my only point was that we have a simpler,
easier to use formula:

D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))<= /o:p>

= to find viable backups Neighbors to reach P-Space.

= Further, the formula does not result in exclusion of any viable Neighbor th= at loop-back to the source.

=  

= Would be great if you can comment on that.

=  

= Thanks and Regards,

= Bharath R.

=  

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Friday, January 03, 2014 7:27 PM
To: Bharath R; rtgwg@ietf.org; draft-ietf-rtgwg-remote-lfa@tools.iet= f.org; imc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So= @tatacommunications.com
Subject: Re: Regarding cost based algorithm for finding Extended P-S= pace.

 

On 03/01/2014 11:35, Bharath R wrote:

Hi,

I have a query on cost based formula for finding Extende= d P-space.

The current formula applies to Node y that is

1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Prote= cted_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))=


Bharath

I cannot see this text in the draft. Is it from the text or your code?

Also the example below has been corrupted.

Not that asymmetric costs are always problematic in LFA solutions, but
it is not clear how frequently they show in real topologies other than
by accident.

Stewart




 

I guess the rationale behind the current formula is that= the packet on the LDP tunnel should not traverse the ProtectedLink.

 

 

But, please consider the following toplogy.

A2=E0B c= ost is 5 and A2=E0S cost is 3; (Both only in the direction as indicated., the other direction = cost is unity)

All other costs are unity.

Following the formula, both A1 and A2 can become backup = neighbors(with P-Space B and C).

However, an LDP tunnel setup via A2 will loopback to S, = taking A2=E0S=E0A1 path.

 

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |     S    = ;   |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;        |      | = ;     |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =      |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;        |    &nb= sp; |      |ProtectedLink

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =      |

         &n= bsp;            = ;            &n= bsp;            = ;             &= nbsp;       |      | = ;     |

         &n= bsp;            = ;             &= nbsp;           &nbs= p; |      |      |

         &n= bsp;            = ;            &n= bsp;            = ;   ---------------      |  &n= bsp;   ----------------

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              | =             &nb= sp;            |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              | =             &nb= sp;            |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  &nbs= p;            &= nbsp;          |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  = ;            &n= bsp;           |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =               |= 5            &n= bsp;           |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; A1   |         | = ;   A2     |     &nb= sp;  |     E       |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;   |           = ;            &n= bsp;             &nb= sp;             |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =               &= nbsp;            &nb= sp;          |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              &n= bsp;              &n= bsp;             |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =                =              &= nbsp;           |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              &n= bsp;             &nb= sp;             |

         &n= bsp;            &nbs= p;        |-----------|   = ;             &= nbsp;         |-----------|=

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; B       |       =              &n= bsp;           | &nb= sp;   D    | 

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;            =             &nb= sp;     |-----------| 

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =         |-----------|    =           |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |--------------|     C    =   |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;           |-----------|&n= bsp;  

 

How about using the following basic formula instead?

2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))

 

 

Advantages:

=B7         The formula two ensures that the packet does not= loopback to S.

=B7         Also as per my understanding, if there is Neighb= or Ni that satisfies 1), but does not satisfy 2), it implies that there is = definitely one more Neigbhro Nj which satisfies 1) both 1) and 2).

(Because if there is a neighbor satisfying 1) and not sa= tisfy 2), then the packet will loopback via some other neighbor which satis= fies 2)).


Given that formula 2) ensures that we don’t select any neighbor wh= ich simply loopbacks the packet to the source and forwards via other viable= Neighbor, it will be more advantageous to employ Formula 2).

 

Please let me know if I am missing something, or if ther= e is a good use case that may prefer backup-neighbor A2 in this example, ov= er backup neighbor A1.(Given that traffic will exit via A1 anyway).

 

 

 

 

Thanks and Regards,

Bharath R.

 




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 
--_000_cd72c8f9dde94d3ca2f7694f04bee95aBY2PR05MB568namprd05pro_-- From stbryant@cisco.com Fri Jan 3 09:03:53 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D041ADFD4 for ; Fri, 3 Jan 2014 09:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 rO8yDnuQzBWZ for ; Fri, 3 Jan 2014 09:03:50 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id ABBF61AE00E for ; Fri, 3 Jan 2014 09:03:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67617; q=dns/txt; s=iport; t=1388768619; x=1389978219; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=xdAHH2rqnN4j7tpwT1MqqYUaeK9sc5U3IVy/pOBE0Kk=; b=AZ1p5ifXvUCYZ2HphBwZYfqdyf3Djum4HvpHoYeiXliKoTTXIMdT/3MR v02l1QJZk4MEJRKVsrSYLoU1lDsJJUtnto/6qzDITEXlcAQmNCc21csRZ klJNfXuOC+/oRDK6hVpPJoBgVgy4BCg855kPBBtZOrexgPJWmISm6aByd g=; X-IronPort-AV: E=Sophos;i="4.95,598,1384300800"; d="scan'208,217";a="2480807" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 03 Jan 2014 17:03:38 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s03H3cr6021477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jan 2014 17:03:38 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s03H3aKW027701; Fri, 3 Jan 2014 17:03:36 GMT Message-ID: <52C6ED68.50207@cisco.com> Date: Fri, 03 Jan 2014 17:03:36 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Bharath R , "rtgwg@ietf.org" , "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "imc.shand@gmail.com" , "cfilsfil@cisco.com" , "sprevidi@cisco.com" , "Ning.So@tatacommunications.com" Subject: Re: Regarding cost based algorithm for finding Extended P-Space. References: <9ecf740f25084ccd9834ffb0a63e60e2@BY2PR05MB568.namprd05.prod.outlook.com> <52C6C1B1.5050100@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030408050803000404090603" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 17:03:53 -0000 This is a multi-part message in MIME format. --------------030408050803000404090603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit The purpose of the two protected link terms was to make sure that there was no attempt to reach PQ via that link. If we remove them we need to make sure that no topology will cause that path to be taken, and I think that your equation could fail on that account. I need to think about this some more, but even if A2 is in P space, it is not in D's Qspace so surely the point is moot? - Stewart On 03/01/2014 14:40, Bharath R wrote: > > Thank you for your reply Stuart > > Sorry, the formula is not verbatim from the draft, but if you refer to > the formula in > > Compute_Extended_P_Space()snippet > > in the http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-04, > > you will find that the formula used maps to > > D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + > D_opt(Protected_link.RemoteNode, Y)) > > Here: > > S : Source Node. > > Ni: Neighbor, > > D_opt(x, y): Optimal distance from x to y. > > Sorry for the corruption in topology. I am recreating it here: > > and A2àS cost is 5; (Only in the direction as indicated., the other > direction cost is unity) > > All other costs are unity. > > |-------------| > > | S | > > |-------------| > > | | | > > | > | |ProtectedLink > > | | | > > | | | > > --------------- | ---------------- > > | | | > > | | | > > | | | > > | |5 | > > |-----------| |-----------| |-----------| > > | A1 | | A2 | | E | > > |-----------| |-----------| |-----------| > > | | > > | | > > | | > > |-----------| > |-----------| > > | B | | D | > > |-----------| |-----------| > > | | > > | | > > | |-----------| | > > |--------------| C |-----------| > > |-----------| > > Yes, even I am not sure of the practicality of the above topology, > > But, my only point was that we have a simpler, > easier to use formula: > > D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) > > to find viable backups Neighbors to reach P-Space. > > Further, the formula does not result in exclusion of any viable > Neighbor that loop-back to the source. > > Would be great if you can comment on that. > > Thanks and Regards, > > Bharath R. > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Friday, January 03, 2014 7:27 PM > *To:* Bharath R; rtgwg@ietf.org; > draft-ietf-rtgwg-remote-lfa@tools.ietf.org; imc.shand@gmail.com; > cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So@tatacommunications.com > *Subject:* Re: Regarding cost based algorithm for finding Extended > P-Space. > > On 03/01/2014 11:35, Bharath R wrote: > > Hi, > > I have a query on cost based formula for finding Extended P-space. > > The current formula applies to Node y that is > > 1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, > Protected_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y)) > > > Bharath > > I cannot see this text in the draft. Is it from the text or your code? > > Also the example below has been corrupted. > > Not that asymmetric costs are always problematic in LFA solutions, but > it is not clear how frequently they show in real topologies other than > by accident. > > Stewart > > > > > I guess the rationale behind the current formula is that the packet on > the LDP tunnel should not traverse the ProtectedLink. > > But, please consider the following toplogy. > > A2àB cost is 5 and A2àS cost is 3; (Both only in the direction as > indicated., the other direction cost is unity) > > All other costs are unity. > > Following the formula, both A1 and A2 can become backup neighbors(with > P-Space B and C). > > However, an LDP tunnel setup via A2 will loopback to S, taking A2àSàA1 > path. > > |-------------| > > | S | > > |-------------| > > | | | > > | | | > > | | |ProtectedLink > > | | | > > | | | > > | | | > > --------------- | ---------------- > > | | | > > | | | > > | | | > > | | | > > | |5 | > > |-----------| |-----------| |-----------| > > | A1 | | A2 | | E | > > |-----------| |-----------| |-----------| > > | | > > | | > > | | > > | | > > | | > > |-----------| |-----------| > > | B | | D | > > |-----------| |-----------| > > | | > > | | > > | |-----------| | > > |--------------| C |-----------| > > |-----------| > > How about using the following basic formula instead? > > 2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) > > Advantages: > > ·The formula two ensures that the packet does not loopback to S. > > ·Also as per my understanding, if there is Neighbor Ni that satisfies > 1), but does not satisfy 2), it implies that there is definitely one > more Neigbhro Nj which satisfies 1) both 1) and 2). > > (Because if there is a neighbor satisfying 1) and not satisfy 2), then > the packet will loopback via some other neighbor which satisfies 2)). > > > Given that formula 2) ensures that we don't select any neighbor which > simply loopbacks the packet to the source and forwards via other > viable Neighbor, it will be more advantageous to employ Formula 2). > > Please let me know if I am missing something, or if there is a good > use case that may prefer backup-neighbor A2 in this example, over > backup neighbor A1.(Given that traffic will exit via A1 anyway). > > Thanks and Regards, > > Bharath R. > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------030408050803000404090603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
The purpose of the two protected link terms was to
make sure that there was no attempt to reach PQ via
that link. If we remove them we need to make sure
that no topology will cause that path to be taken,
and I think that your equation could fail on that
account.

I need to think about this some more, but
even if A2 is in P space, it is not in D's
Qspace so surely the point is moot?

- Stewart

On 03/01/2014 14:40, Bharath R wrote:

Thank you for your reply Stuart

 

Sorry, the formula is not verbatim from the draft, but if you refer to the formula in

Compute_Extended_P_Space()snippet

in the http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-04,

 

you will find that the formula used maps to

D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))

Here:

S : Source Node.

Ni:  Neighbor,

D_opt(x, y): Optimal distance from x to y.

 

Sorry for the corruption in topology. I am recreating it here:

and A2àS cost is 5; (Only in the direction as indicated., the other direction cost is unity)

All other costs are unity.

 

 

                                                                  |-------------|

                                                                  |        S       |

                                                                  |-------------|

                                                                   |      |       |

                                                                   |      |       |ProtectedLink

                                                                   |      |       |

                                                                   |      |       |

                                                  ---------------     |      ----------------

                                                  |                       |                          |

                                                  |                       |                          |

                                                  |                       |                          |

                                                  |                       |5                        |

                                            |-----------|         |-----------|        |-----------|

                                            |     A1    |          |    A2     |        |     E       |

                                            |-----------|         |-----------|        |-----------|

                                                  |                                                   |

                                                  |                                                   |

                                                  |                                                   |

                                            |-----------|                               |-----------|

                                            |     B       |                                |     D      | 

                                            |-----------|                                |-----------| 

                                                  |                                                  |

                                                  |                                                  |

                                                  |                  |-----------|              |

                                                  |--------------|     C      |-----------|

                                                                      |-----------|   

 

Yes, even I am not sure of the practicality of the above topology,

But, my only point was that we have a simpler,
easier to use formula:

D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))

to find viable backups Neighbors to reach P-Space.

Further, the formula does not result in exclusion of any viable Neighbor that loop-back to the source.

 

Would be great if you can comment on that.

 

Thanks and Regards,

Bharath R.

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Friday, January 03, 2014 7:27 PM
To: Bharath R; rtgwg@ietf.org; draft-ietf-rtgwg-remote-lfa@tools.ietf.org; imc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So@tatacommunications.com
Subject: Re: Regarding cost based algorithm for finding Extended P-Space.

 

On 03/01/2014 11:35, Bharath R wrote:

Hi,

I have a query on cost based formula for finding Extended P-space.

The current formula applies to Node y that is

1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))


Bharath

I cannot see this text in the draft. Is it from the text or your code?

Also the example below has been corrupted.

Not that asymmetric costs are always problematic in LFA solutions, but
it is not clear how frequently they show in real topologies other than
by accident.

Stewart




 

I guess the rationale behind the current formula is that the packet on the LDP tunnel should not traverse the ProtectedLink.

 

 

But, please consider the following toplogy.

A2àB cost is 5 and A2àS cost is 3; (Both only in the direction as indicated., the other direction cost is unity)

All other costs are unity.

Following the formula, both A1 and A2 can become backup neighbors(with P-Space B and C).

However, an LDP tunnel setup via A2 will loopback to S, taking A2àSàA1 path.

 

                                                                 |-------------|

                                                                  |     S       |

                                                                  |-------------|

                                                                    |      |      |

                                                                   |      |      |

                                                                    |      |      |ProtectedLink

                                                                   |      |      |

                                                                    |      |      |

                                                 |      |      |

                                                  ---------------      |      ----------------

                                                  |                       |                          |

                                                  |                       |                          |

                                                  |                       |                          |

                                                  |                       |                          |

                                                  |                        |5                        |

                                            |-----------|         |-----------|        |-----------|

                                            |     A1   |         |    A2     |        |     E       |

                                            |-----------|         |-----------|        |-----------|

                                                  |                                                   |

                                                  |                                                |

                                                  |                                                    |

                                                  |                                                   |

                                                  |                                                   |

                               |-----------|                          |-----------|

                                            |     B       |                                |     D    | 

                                            |-----------|                                |-----------| 

                                                  |                                                  |

                                                  |                                                  |

                                                  |                  |-----------|              |

                                                  |--------------|     C      |-----------|

                                                                       |-----------|   

 

How about using the following basic formula instead?

2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))

 

 

Advantages:

·         The formula two ensures that the packet does not loopback to S.

·         Also as per my understanding, if there is Neighbor Ni that satisfies 1), but does not satisfy 2), it implies that there is definitely one more Neigbhro Nj which satisfies 1) both 1) and 2).

(Because if there is a neighbor satisfying 1) and not satisfy 2), then the packet will loopback via some other neighbor which satisfies 2)).


Given that formula 2) ensures that we don’t select any neighbor which simply loopbacks the packet to the source and forwards via other viable Neighbor, it will be more advantageous to employ Formula 2).

 

Please let me know if I am missing something, or if there is a good use case that may prefer backup-neighbor A2 in this example, over backup neighbor A1.(Given that traffic will exit via A1 anyway).

 

 

 

 

Thanks and Regards,

Bharath R.

 




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
 


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------030408050803000404090603-- From rbharath@juniper.net Fri Jan 3 09:30:31 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717981ADFD7 for ; Fri, 3 Jan 2014 09:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 qGfyFUGY7rUv for ; Fri, 3 Jan 2014 09:30:26 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 773441ADFD4 for ; Fri, 3 Jan 2014 09:30:26 -0800 (PST) Received: from mail19-co1-R.bigfish.com (10.243.78.234) by CO1EHSOBE035.bigfish.com (10.243.66.100) with Microsoft SMTP Server id 14.1.225.22; Fri, 3 Jan 2014 17:30:18 +0000 Received: from mail19-co1 (localhost [127.0.0.1]) by mail19-co1-R.bigfish.com (Postfix) with ESMTP id 5209C380399; Fri, 3 Jan 2014 17:30:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zzbb2dI98dI9371Ic89bhc85dh1418Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail19-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbharath@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(199002)(24454002)(51444003)(377454003)(479174003)(189002)(83072002)(77982001)(80022001)(18717965001)(81816001)(19580395003)(65816001)(66066001)(87266001)(15975445006)(81686001)(80976001)(19300405004)(79102001)(15202345003)(81342001)(85852003)(81542001)(54316002)(59766001)(56776001)(63696002)(74366001)(87936001)(74316001)(46102001)(49866001)(47736001)(50986001)(47976001)(76796001)(76786001)(54356001)(74662001)(85306002)(74876001)(76482001)(4396001)(47446002)(53806001)(83322001)(74706001)(19580405001)(31966008)(74502001)(16236675002)(33646001)(90146001)(69226001)(56816005)(2656002)(76576001)(51856001)(24736002)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB566; H:BY2PR05MB568.namprd05.prod Received: from mail19-co1 (localhost.localdomain [127.0.0.1]) by mail19-co1 (MessageSwitch) id 1388770214812112_12185; Fri, 3 Jan 2014 17:30:14 +0000 (UTC) Received: from CO1EHSMHS030.bigfish.com (unknown [10.243.78.238]) by mail19-co1.bigfish.com (Postfix) with ESMTP id C140FD4004A; Fri, 3 Jan 2014 17:30:14 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS030.bigfish.com (10.243.66.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 3 Jan 2014 17:30:12 +0000 Received: from BY2PR05MB566.namprd05.prod.outlook.com (10.141.220.16) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 3 Jan 2014 17:29:53 +0000 Received: from BY2PR05MB568.namprd05.prod.outlook.com (10.141.220.27) by BY2PR05MB566.namprd05.prod.outlook.com (10.141.220.16) with Microsoft SMTP Server (TLS) id 15.0.842.7; Fri, 3 Jan 2014 17:29:51 +0000 Received: from BY2PR05MB568.namprd05.prod.outlook.com ([10.141.220.27]) by BY2PR05MB568.namprd05.prod.outlook.com ([10.141.220.27]) with mapi id 15.00.0842.003; Fri, 3 Jan 2014 17:29:51 +0000 From: Bharath R To: "stbryant@cisco.com" , "rtgwg@ietf.org" , "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "imc.shand@gmail.com" , "cfilsfil@cisco.com" , "sprevidi@cisco.com" , "Ning.So@tatacommunications.com" Subject: RE: Regarding cost based algorithm for finding Extended P-Space. Thread-Topic: Regarding cost based algorithm for finding Extended P-Space. Thread-Index: Ac8Id9tfGC7DxP3KTpWaJMen1KzBtgAE9PWAAADSKUAABbFuAAAAR+zA Date: Fri, 3 Jan 2014 17:29:51 +0000 Message-ID: <7972e3aa998a4a63b26b4632eae47423@BY2PR05MB568.namprd05.prod.outlook.com> References: <9ecf740f25084ccd9834ffb0a63e60e2@BY2PR05MB568.namprd05.prod.outlook.com> <52C6C1B1.5050100@cisco.com> <52C6ED68.50207@cisco.com> In-Reply-To: <52C6ED68.50207@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.15] x-forefront-prvs: 00808B16F3 Content-Type: multipart/alternative; boundary="_000_7972e3aa998a4a63b26b4632eae47423BY2PR05MB568namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Mon, 06 Jan 2014 08:05:27 -0800 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 17:30:31 -0000 --_000_7972e3aa998a4a63b26b4632eae47423BY2PR05MB568namprd05pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stewart, The point here is not about the P-Space, but the eligible Backup-Neighbor t= o reach P-Space. In the below topology, the P-Space remains unchanged, but we have two possi= ble backup-neighbors: A1, which does not have looping problems A2, which loops back the traffic to S, and then has it going via A1, before= reaching the other P-Space nodes and eventually the PQ node. But, with application of formula 2), we will have only A1 as the viable bac= kup Neighbor. And regarding the second formula ensuring that the packet does not take the= failed link(The SE link): To re-quote the formulae: 1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_= opt(Protected_link.RemoteNode, Y)) 2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) Since formula 2). ensures that the packet does not reach S itself, the ques= tion of taking the SE link does not arise. In fact, the formula 2) gives a 'non-loopingback' subset of neighbors as co= mpared to formula 1). Furthermore, existence of a Neighbor(Ni) satisfying Formula 1), but not sat= isfying formula 2), should imply existence of some other Neighbor(Nj) satis= fying formula 2). Because eventually Ni will loopback the traffic via Nj. So, we will not miss out on finding a viable neighbor if one exists. Please let me know if there is any gap in my understanding/analysis. Thanks and regards, Bharath R. From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Friday, January 03, 2014 10:34 PM To: Bharath R; rtgwg@ietf.org; draft-ietf-rtgwg-remote-lfa@tools.ietf.org; = imc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So@tataco= mmunications.com Subject: Re: Regarding cost based algorithm for finding Extended P-Space. The purpose of the two protected link terms was to make sure that there was no attempt to reach PQ via that link. If we remove them we need to make sure that no topology will cause that path to be taken, and I think that your equation could fail on that account. I need to think about this some more, but even if A2 is in P space, it is not in D's Qspace so surely the point is moot? - Stewart On 03/01/2014 14:40, Bharath R wrote: Thank you for your reply Stuart Sorry, the formula is not verbatim from the draft, but if you refer to the = formula in Compute_Extended_P_Space()snippet in the http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-04, you will find that the formula used maps to D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_opt(= Protected_link.RemoteNode, Y)) Here: S : Source Node. Ni: Neighbor, D_opt(x, y): Optimal distance from x to y. Sorry for the corruption in topology. I am recreating it here: and A2-->S cost is 5; (Only in the direction as indicated., the other direc= tion cost is unity) All other costs are unity. |--------= -----| | = S | |--------= -----| | |= | | |= |ProtectedLink | |= | | |= | --------------- | = ---------------- | |= | | |= | | |= | | |= 5 | |-----------| |--------= ---| |-----------| | A1 | | A2 = | | E | |-----------| |--------= ---| |-----------| | = | | = | | = | |-----------| = |-----------| | B | = | D | |-----------| = |-----------| | = | | = | | |-----= ------| | |--------------| C = |-----------| |----= -------| Yes, even I am not sure of the practicality of the above topology, But, my only point was that we have a simpler, easier to use formula: D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) to find viable backups Neighbors to reach P-Space. Further, the formula does not result in exclusion of any viable Neighbor th= at loop-back to the source. Would be great if you can comment on that. Thanks and Regards, Bharath R. From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Friday, January 03, 2014 7:27 PM To: Bharath R; rtgwg@ietf.org; draft-ietf-rtgwg-remo= te-lfa@tools.ietf.org; i= mc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So@= tatacommunications.com Subject: Re: Regarding cost based algorithm for finding Extended P-Space. On 03/01/2014 11:35, Bharath R wrote: Hi, I have a query on cost based formula for finding Extended P-space. The current formula applies to Node y that is 1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_= opt(Protected_link.RemoteNode, Y)) Bharath I cannot see this text in the draft. Is it from the text or your code? Also the example below has been corrupted. Not that asymmetric costs are always problematic in LFA solutions, but it is not clear how frequently they show in real topologies other than by accident. Stewart I guess the rationale behind the current formula is that the packet on the = LDP tunnel should not traverse the ProtectedLink. But, please consider the following toplogy. A2-->B cost is 5 and A2-->S cost is 3; (Both only in the direction as indic= ated., the other direction cost is unity) All other costs are unity. Following the formula, both A1 and A2 can become backup neighbors(with P-Sp= ace B and C). However, an LDP tunnel setup via A2 will loopback to S, taking A2-->S-->A1 = path. |---------= ----| | S = | |--------= -----| | = | | | |= | | = | |ProtectedLink | |= | | = | | | | | --------------- | = ---------------- | |= | | |= | | |= | | |= | | = |5 | |-----------| |--------= ---| |-----------| | A1 | | A2 = | | E | |-----------| |--------= ---| |-----------| | = | | = | | = | | = | | = | |-----------| |----= -------| | B | = | D | |-----------| = |-----------| | = | | = | | |-----= ------| | |--------------| C = |-----------| |---= --------| How about using the following basic formula instead? 2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) Advantages: =B7 The formula two ensures that the packet does not loopback to S. =B7 Also as per my understanding, if there is Neighbor Ni that sati= sfies 1), but does not satisfy 2), it implies that there is definitely one = more Neigbhro Nj which satisfies 1) both 1) and 2). (Because if there is a neighbor satisfying 1) and not satisfy 2), then the = packet will loopback via some other neighbor which satisfies 2)). Given that formula 2) ensures that we don't select any neighbor which simpl= y loopbacks the packet to the source and forwards via other viable Neighbor= , it will be more advantageous to employ Formula 2). Please let me know if I am missing something, or if there is a good use cas= e that may prefer backup-neighbor A2 in this example, over backup neighbor = A1.(Given that traffic will exit via A1 anyway). Thanks and Regards, Bharath R. -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_7972e3aa998a4a63b26b4632eae47423BY2PR05MB568namprd05pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Stewart,

The point here is not about the P-Space, b= ut the eligible Backup-Neighbor to reach P-Space.

In the below topology, the P-Space remains= unchanged, but we have two possible backup-neighbors:

A1, which does not have looping problems

A2, which loops back the traffic to S, and= then has it going via A1, before reaching the  other P-Space nodes an= d eventually the PQ node.

But, with application of formula 2), we wi= ll have only A1 as the viable backup Neighbor.

 

And regarding the second formula ensuring = that the packet does not take the failed link(The SE link):

 

To re-quote the formulae:

1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Prote= cted_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))=

2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))

 

 

Since formula 2). ensures that the packet = does not reach S itself, the question of taking the SE link does not arise.=

In fact, the formula 2) gives a ‘non= -loopingback’ subset of neighbors as compared to formula 1).

 

Furthermore, existence of a Neighbor(Ni) s= atisfying Formula 1), but not satisfying formula 2), should imply existence= of some other Neighbor(Nj) satisfying formula 2).

Because eventually Ni will loopback the tr= affic via Nj.

So, we will not miss out on finding a viab= le neighbor if one exists.

 

Please let me know if there is any gap in = my understanding/analysis.

 

Thanks and regards,

Bharath R.

 <= /p>

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Friday, January 03, 2014 10:34 PM
To: Bharath R; rtgwg@ietf.org; draft-ietf-rtgwg-remote-lfa@tools.iet= f.org; imc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So= @tatacommunications.com
Subject: Re: Regarding cost based algorithm for finding Extended P-S= pace.

 

The purpose of the two protected link terms was to make sure that there was no attempt to reach PQ via
that link. If we remove them we need to make sure
that no topology will cause that path to be taken,
and I think that your equation could fail on that
account.

I need to think about this some more, but
even if A2 is in P space, it is not in D's
Qspace so surely the point is moot?

- Stewart

On 03/01/2014 14:40, Bharath R wrote:

Thank you for your reply = Stuart

 <= /p>

Sorry, the formula is not= verbatim from the draft, but if you refer to the formula in

Compute_Extended_P_Space()snippet

in the http:= //tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-04,

 

you will find that the formula used maps to

D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected= _link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))

Here:

S : Source Node.

Ni:  Neighbor,

D_opt(x, y): Optimal distance from x to y.

 

Sorry for the corruption in topology. I am recreating it= here:

and A2=E0S cost is 5; (Only in the direction as indicated., the other direction cos= t is unity)

All other costs are unity.

 

 

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |        S &nbs= p;     |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =       |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |    &nbs= p; |       |ProtectedLink

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =       |

         &n= bsp;            = ;            &n= bsp;            = ;             &= nbsp;      |      | =       |

         &n= bsp;            = ;            &n= bsp;            = ;   ---------------     |   &n= bsp;  ----------------

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              | =             &nb= sp;            |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  &nbs= p;            &= nbsp;          |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  = ;            &n= bsp;           |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |5=             &nb= sp;           |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; A1    |          = ;|    A2     |    &n= bsp;   |     E       |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;   |           = ;            &n= bsp;             &nb= sp;             |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =                =              &= nbsp;           |<= /o:p>

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              &n= bsp;             &nb= sp;             |

         &n= bsp;            &nbs= p;             =         |-----------|  &n= bsp;            &nbs= p;              = ; |-----------|

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; B       |       =              &n= bsp;           | &nb= sp;   D      | 

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;            =             &nb= sp;     |-----------| 

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =         |-----------|    =           |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |--------------|     C    =   |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          |-----------| &n= bsp; 

 

Yes, even I am not sure of the practicality of the above = topology,

But, my only point was that we have a simpler,
easier to use formula:

D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))

to find viable backups Neighbors to reach P-Space.=

Further, the formula does not result in exclusion of any = viable Neighbor that loop-back to the source.

 

Would be great if you can comment on that.

 

Thanks and Regards,

Bharath R.

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Friday, January 03, 2014 7:27 PM
To: Bharath R; rtgwg@ietf.org;= draft-ietf-rtgwg-remote-lfa@tools.ietf.org; imc.shand@gmail.com; cfilsfil@cis= co.com; sprevidi@cisco.com; Ning.So@tatacommunications.com
Subject: Re: Regarding cost based algorithm for finding Extended P-S= pace.

 

On 03/01/2014 11:35, Bharath R wrote:

Hi,

I have a query on cost based formula for finding Extende= d P-space.

The current formula applies to Node y that is

1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Prote= cted_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))


Bharath

I cannot see this text in the draft. Is it from the text or your code?

Also the example below has been corrupted.

Not that asymmetric costs are always problematic in LFA solutions, but
it is not clear how frequently they show in real topologies other than
by accident.

Stewart





 

I guess the rationale behind the current formula is that= the packet on the LDP tunnel should not traverse the ProtectedLink.=

 

 

But, please consider the following toplogy.<= /o:p>

A2=E0B c= ost is 5 and A2=E0S cost is 3; (Both only in the direction as indicated., the other direction = cost is unity)

All other costs are unity.

Following the formula, both A1 and A2 can become backup = neighbors(with P-Space B and C).

However, an LDP tunnel setup via A2 will loopback to S, = taking A2=E0S=E0A1 path.

 

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |     S    = ;   |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;        |      | = ;     |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =      |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;        |    &nb= sp; |      |ProtectedLink

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =      |

         &n= bsp;            = ;            &n= bsp;            = ;             &= nbsp;       |      | = ;     |

         &n= bsp;            = ;             &= nbsp;           &nbs= p; |      |      |=

         &n= bsp;            = ;            &n= bsp;            = ;   ---------------      |  &n= bsp;   ----------------

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              | =             &nb= sp;            |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              | =             &nb= sp;            |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  &nbs= p;            &= nbsp;          |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  = ;            &n= bsp;           |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =               |= 5            &n= bsp;           |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; A1   |         | = ;   A2     |     &nb= sp;  |     E       |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;   |           = ;            &n= bsp;             &nb= sp;             |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =               &= nbsp;            &nb= sp;          |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              &n= bsp;              &n= bsp;             |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =                =              &= nbsp;           |<= /o:p>

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              &n= bsp;             &nb= sp;             |

         &n= bsp;            &nbs= p;        |-----------|   = ;             &= nbsp;         |-----------|=

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; B       |       =              &n= bsp;           | &nb= sp;   D    | 

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;            =             &nb= sp;     |-----------| 

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =         |-----------|    =           |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |--------------|     C    =   |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;           |-----------|&n= bsp;  

 

How about using the following basic formula instead?

2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))

 

 

Advantages:

=B7         The formula two ensures that the packet does not= loopback to S.

=B7         Also as per my understanding, if there is Neighb= or Ni that satisfies 1), but does not satisfy 2), it implies that there is = definitely one more Neigbhro Nj which satisfies 1) both 1) and 2).

(Because if there is a neighbor satisfying 1) and not sa= tisfy 2), then the packet will loopback via some other neighbor which satis= fies 2)).


Given that formula 2) ensures that we don’t select any neighbor wh= ich simply loopbacks the packet to the source and forwards via other viable= Neighbor, it will be more advantageous to employ Formula 2).

 

Please let me know if I am missing something, or if ther= e is a good use case that may prefer backup-neighbor A2 in this example, ov= er backup neighbor A1.(Given that traffic will exit via A1 anyway).

 

 

 

 

Thanks and Regards,

Bharath R.

 





-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 
--_000_7972e3aa998a4a63b26b4632eae47423BY2PR05MB568namprd05pro_-- From stbryant@cisco.com Fri Jan 3 09:57:34 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678D91AE00D for ; Fri, 3 Jan 2014 09:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 seFKrwl2nJbQ for ; Fri, 3 Jan 2014 09:57:29 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 42D281ADFC2 for ; Fri, 3 Jan 2014 09:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=81530; q=dns/txt; s=iport; t=1388771839; x=1389981439; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=PUuH09knIyv9HzHvpxcIt5JGYnySvUGKVowpOBb+3Gw=; b=dFR6chb+3efBllNs8dbzxNcNBJODgdnM/SJ3JhanTt76uETyu5OFYUG6 /Lh6ESVdzwpW5s3L392Q7wGjDOeSK09C57ef+QneIK3dGJ/RcLxHS44Qu p0oVeOhWiRP3DPeNIhVwOXtCZU8JLcXIoacuyVptIwCwYCaSHupMW2teo g=; X-IronPort-AV: E=Sophos;i="4.95,599,1384300800"; d="scan'208,217";a="3151603" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 03 Jan 2014 17:57:18 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s03HvHoY006676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jan 2014 17:57:18 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s03HvGso000237; Fri, 3 Jan 2014 17:57:16 GMT Message-ID: <52C6F9FC.9050206@cisco.com> Date: Fri, 03 Jan 2014 17:57:16 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Bharath R , "rtgwg@ietf.org" , "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "imc.shand@gmail.com" , "cfilsfil@cisco.com" , "sprevidi@cisco.com" , "Ning.So@tatacommunications.com" Subject: Re: Regarding cost based algorithm for finding Extended P-Space. References: <9ecf740f25084ccd9834ffb0a63e60e2@BY2PR05MB568.namprd05.prod.outlook.com> <52C6C1B1.5050100@cisco.com> <52C6ED68.50207@cisco.com> <7972e3aa998a4a63b26b4632eae47423@BY2PR05MB568.namprd05.prod.outlook.com> In-Reply-To: <7972e3aa998a4a63b26b4632eae47423@BY2PR05MB568.namprd05.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------040208000102080901010104" X-Mailman-Approved-At: Mon, 06 Jan 2014 08:05:27 -0800 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 17:57:34 -0000 This is a multi-part message in MIME format. --------------040208000102080901010104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Bharath I will run this past Mike when he gets back next week, but I think you are correct. Note that this simplification will not work when we come to node protection since you must look at alternative paths through the nodes, but for link protection, I think you are correct to state that avoiding the repairing node is sufficient. Thanks for picking this up. - Stewart On 03/01/2014 17:29, Bharath R wrote: > > Hi Stewart, > > The point here is not about the P-Space, but the eligible > Backup-Neighbor to reach P-Space. > > In the below topology, the P-Space remains unchanged, but we have two > possible backup-neighbors: > > A1, which does not have looping problems > > A2, which loops back the traffic to S, and then has it going via A1, > before reaching the other P-Space nodes and eventually the PQ node. > > But, with application of formula 2), we will have only A1 as the > viable backup Neighbor. > > And regarding the second formula ensuring that the packet does not > take the failed link(The SE link): > > To re-quote the formulae: > > 1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) > + D_opt(Protected_link.RemoteNode, Y)) > > 2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) > > Since formula 2). ensures that the packet does not reach S itself, the > question of taking the SE link does not arise. > > In fact, the formula 2) gives a 'non-loopingback' subset of neighbors > as compared to formula 1). > > Furthermore, existence of a Neighbor(Ni) satisfying Formula 1), but > not satisfying formula 2), should imply existence of some other > Neighbor(Nj) satisfying formula 2). > > Because eventually Ni will loopback the traffic via Nj. > > So, we will not miss out on finding a viable neighbor if one exists. > > Please let me know if there is any gap in my understanding/analysis. > > Thanks and regards, > > Bharath R. > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Friday, January 03, 2014 10:34 PM > *To:* Bharath R; rtgwg@ietf.org; > draft-ietf-rtgwg-remote-lfa@tools.ietf.org; imc.shand@gmail.com; > cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So@tatacommunications.com > *Subject:* Re: Regarding cost based algorithm for finding Extended > P-Space. > > The purpose of the two protected link terms was to > make sure that there was no attempt to reach PQ via > that link. If we remove them we need to make sure > that no topology will cause that path to be taken, > and I think that your equation could fail on that > account. > > I need to think about this some more, but > even if A2 is in P space, it is not in D's > Qspace so surely the point is moot? > > - Stewart > > On 03/01/2014 14:40, Bharath R wrote: > > Thank you for your reply Stuart > > Sorry, the formula is not verbatim from the draft, but if you > refer to the formula in > > Compute_Extended_P_Space()snippet > > in the http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-04, > > you will find that the formula used maps to > > D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) > + D_opt(Protected_link.RemoteNode, Y)) > > Here: > > S : Source Node. > > Ni: Neighbor, > > D_opt(x, y): Optimal distance from x to y. > > Sorry for the corruption in topology. I am recreating it here: > > and A2àS cost is 5; (Only in the direction as indicated., the > other direction cost is unity) > > All other costs are unity. > > |-------------| > > | S | > > |-------------| > > | | | > > | > | |ProtectedLink > > | | | > > | | | > > --------------- | ---------------- > > | | | > > | | | > > | | | > > | |5 | > > |-----------| |-----------| |-----------| > > | A1 | | A2 | | E | > > |-----------| |-----------| |-----------| > > | | > > | | > > | | > > |-----------| > |-----------| > > | B | | D | > > |-----------| |-----------| > > | | > > | | > > | |-----------| | > > |--------------| C |-----------| > > |-----------| > > Yes, even I am not sure of the practicality of the above topology, > > But, my only point was that we have a simpler, > easier to use formula: > > D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) > > to find viable backups Neighbors to reach P-Space. > > Further, the formula does not result in exclusion of any viable > Neighbor that loop-back to the source. > > Would be great if you can comment on that. > > Thanks and Regards, > > Bharath R. > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Friday, January 03, 2014 7:27 PM > *To:* Bharath R; rtgwg@ietf.org ; > draft-ietf-rtgwg-remote-lfa@tools.ietf.org > ; > imc.shand@gmail.com ; > cfilsfil@cisco.com ; sprevidi@cisco.com > ; Ning.So@tatacommunications.com > > *Subject:* Re: Regarding cost based algorithm for finding Extended > P-Space. > > On 03/01/2014 11:35, Bharath R wrote: > > Hi, > > I have a query on cost based formula for finding Extended P-space. > > The current formula applies to Node y that is > > 1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, > Protected_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y)) > > > Bharath > > I cannot see this text in the draft. Is it from the text or your code? > > Also the example below has been corrupted. > > Not that asymmetric costs are always problematic in LFA solutions, but > it is not clear how frequently they show in real topologies other than > by accident. > > Stewart > > > > > > I guess the rationale behind the current formula is that the > packet on the LDP tunnel should not traverse the ProtectedLink. > > But, please consider the following toplogy. > > A2àB cost is 5 and A2àS cost is 3; (Both only in the direction as > indicated., the other direction cost is unity) > > All other costs are unity. > > Following the formula, both A1 and A2 can become backup > neighbors(with P-Space B and C). > > However, an LDP tunnel setup via A2 will loopback to S, taking > A2àSàA1 path. > > |-------------| > > | S | > > |-------------| > > | | | > > | | | > > | | |ProtectedLink > > | | | > > | | | > > | | | > > --------------- | ---------------- > > | | | > > | | | > > | | | > > | | | > > | |5 | > > |-----------| |-----------| |-----------| > > | A1 | | A2 | | E | > > |-----------| |-----------| |-----------| > > | | > > | | > > | | > > | | > > | | > > |-----------| |-----------| > > | B | | D | > > |-----------| |-----------| > > | | > > | | > > | |-----------| | > > |--------------| C |-----------| > > |-----------| > > How about using the following basic formula instead? > > 2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) > > Advantages: > > ·The formula two ensures that the packet does not loopback to S. > > ·Also as per my understanding, if there is Neighbor Ni that > satisfies 1), but does not satisfy 2), it implies that there is > definitely one more Neigbhro Nj which satisfies 1) both 1) and 2). > > (Because if there is a neighbor satisfying 1) and not satisfy 2), > then the packet will loopback via some other neighbor which > satisfies 2)). > > > Given that formula 2) ensures that we don't select any neighbor > which simply loopbacks the packet to the source and forwards via > other viable Neighbor, it will be more advantageous to employ > Formula 2). > > Please let me know if I am missing something, or if there is a > good use case that may prefer backup-neighbor A2 in this example, > over backup neighbor A1.(Given that traffic will exit via A1 anyway). > > Thanks and Regards, > > Bharath R. > > > > > > -- > > For corporate legal information go to: > > > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------040208000102080901010104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Bharath

I will run this past Mike when he gets back next week, but I think you are
correct. Note that this simplification will not work when we come to node
protection since you must look at alternative paths through the nodes, but
for link protection, I think you are correct to state that avoiding the repairing
node is sufficient.

Thanks for picking this up.

- Stewart

On 03/01/2014 17:29, Bharath R wrote:

Hi Stewart,

The point here is not about the P-Space, but the eligible Backup-Neighbor to reach P-Space.

In the below topology, the P-Space remains unchanged, but we have two possible backup-neighbors:

A1, which does not have looping problems

A2, which loops back the traffic to S, and then has it going via A1, before reaching the  other P-Space nodes and eventually the PQ node.

But, with application of formula 2), we will have only A1 as the viable backup Neighbor.

 

And regarding the second formula ensuring that the packet does not take the failed link(The SE link):

 

To re-quote the formulae:

1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))

2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))

 

 

Since formula 2). ensures that the packet does not reach S itself, the question of taking the SE link does not arise.

In fact, the formula 2) gives a ‘non-loopingback’ subset of neighbors as compared to formula 1).

 

Furthermore, existence of a Neighbor(Ni) satisfying Formula 1), but not satisfying formula 2), should imply existence of some other Neighbor(Nj) satisfying formula 2).

Because eventually Ni will loopback the traffic via Nj.

So, we will not miss out on finding a viable neighbor if one exists.

 

Please let me know if there is any gap in my understanding/analysis.

 

Thanks and regards,

Bharath R.

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Friday, January 03, 2014 10:34 PM
To: Bharath R; rtgwg@ietf.org; draft-ietf-rtgwg-remote-lfa@tools.ietf.org; imc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So@tatacommunications.com
Subject: Re: Regarding cost based algorithm for finding Extended P-Space.

 

The purpose of the two protected link terms was to
make sure that there was no attempt to reach PQ via
that link. If we remove them we need to make sure
that no topology will cause that path to be taken,
and I think that your equation could fail on that
account.

I need to think about this some more, but
even if A2 is in P space, it is not in D's
Qspace so surely the point is moot?

- Stewart

On 03/01/2014 14:40, Bharath R wrote:

Thank you for your reply Stuart

 

Sorry, the formula is not verbatim from the draft, but if you refer to the formula in

Compute_Extended_P_Space()snippet

in the http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-04,

 

you will find that the formula used maps to

D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))

Here:

S : Source Node.

Ni:  Neighbor,

D_opt(x, y): Optimal distance from x to y.

 

Sorry for the corruption in topology. I am recreating it here:

and A2àS cost is 5; (Only in the direction as indicated., the other direction cost is unity)

All other costs are unity.

 

 

                                                                  |-------------|

                                                                  |        S       |

                                                                  |-------------|

                                                                   |      |       |

                                                                   |      |       |ProtectedLink

                                                                   |      |       |

                                                                   |      |       |

                                                  ---------------     |      ----------------

                                                  |                       |                          |

                                                  |                       |                          |

                                                  |                       |                          |

                                                  |                       |5                        |

                                            |-----------|         |-----------|        |-----------|

                                            |     A1    |          |    A2     |        |     E       |

                                            |-----------|         |-----------|        |-----------|

                                                  |                                                   |

                                                  |                                                   |

                                                  |                                                   |

                                            |-----------|                               |-----------|

                                            |     B       |                                |     D      | 

                                            |-----------|                                |-----------| 

                                                  |                                                  |

                                                  |                                                  |

                                                  |                  |-----------|              |

                                                  |--------------|     C      |-----------|

                                                                      |-----------|   

 

Yes, even I am not sure of the practicality of the above topology,

But, my only point was that we have a simpler,
easier to use formula:

D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))

to find viable backups Neighbors to reach P-Space.

Further, the formula does not result in exclusion of any viable Neighbor that loop-back to the source.

 

Would be great if you can comment on that.

 

Thanks and Regards,

Bharath R.

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Friday, January 03, 2014 7:27 PM
To: Bharath R; rtgwg@ietf.org; draft-ietf-rtgwg-remote-lfa@tools.ietf.org; imc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So@tatacommunications.com
Subject: Re: Regarding cost based algorithm for finding Extended P-Space.

 

On 03/01/2014 11:35, Bharath R wrote:

Hi,

I have a query on cost based formula for finding Extended P-space.

The current formula applies to Node y that is

1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))


Bharath

I cannot see this text in the draft. Is it from the text or your code?

Also the example below has been corrupted.

Not that asymmetric costs are always problematic in LFA solutions, but
it is not clear how frequently they show in real topologies other than
by accident.

Stewart





 

I guess the rationale behind the current formula is that the packet on the LDP tunnel should not traverse the ProtectedLink.

 

 

But, please consider the following toplogy.

A2àB cost is 5 and A2àS cost is 3; (Both only in the direction as indicated., the other direction cost is unity)

All other costs are unity.

Following the formula, both A1 and A2 can become backup neighbors(with P-Space B and C).

However, an LDP tunnel setup via A2 will loopback to S, taking A2àSàA1 path.

 

                                                                 |-------------|

                                                                  |     S       |

                                                                  |-------------|

                                                                    |      |      |

                                                                   |      |      |

                                                                    |      |      |ProtectedLink

                                                                   |      |      |

                                                                    |      |      |

                                                 |      |      |

                                                  ---------------      |      ----------------

                                                  |                       |                          |

                                                  |                       |                          |

                                                  |                       |                          |

                                                  |                       |                          |

                                                  |                        |5                        |

                                            |-----------|         |-----------|        |-----------|

                                            |     A1   |         |    A2     |        |     E       |

                                            |-----------|         |-----------|        |-----------|

                                                  |                                                   |

                                                  |                                                |

                                                  |                                                    |

                                                  |                                                   |

                                                  |                                                   |

                               |-----------|                          |-----------|

                                            |     B       |                                |     D    | 

                                            |-----------|                                |-----------| 

                                                  |                                                  |

                                                  |                                                  |

                                                  |                  |-----------|              |

                                                  |--------------|     C      |-----------|

                                                                       |-----------|   

 

How about using the following basic formula instead?

2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))

 

 

Advantages:

·         The formula two ensures that the packet does not loopback to S.

·         Also as per my understanding, if there is Neighbor Ni that satisfies 1), but does not satisfy 2), it implies that there is definitely one more Neigbhro Nj which satisfies 1) both 1) and 2).

(Because if there is a neighbor satisfying 1) and not satisfy 2), then the packet will loopback via some other neighbor which satisfies 2)).


Given that formula 2) ensures that we don’t select any neighbor which simply loopbacks the packet to the source and forwards via other viable Neighbor, it will be more advantageous to employ Formula 2).

 

Please let me know if I am missing something, or if there is a good use case that may prefer backup-neighbor A2 in this example, over backup neighbor A1.(Given that traffic will exit via A1 anyway).

 

 

 

 

Thanks and Regards,

Bharath R.

 





-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
 




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
 


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------040208000102080901010104-- From rbharath@juniper.net Fri Jan 3 10:09:52 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2071AC3FA for ; Fri, 3 Jan 2014 10:09:52 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joWm0oIvePzz for ; Fri, 3 Jan 2014 10:09:46 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id 634691ADFB1 for ; Fri, 3 Jan 2014 10:09:45 -0800 (PST) Received: from mail171-db9-R.bigfish.com (10.174.16.242) by DB9EHSOBE028.bigfish.com (10.174.14.91) with Microsoft SMTP Server id 14.1.225.22; Fri, 3 Jan 2014 18:09:37 +0000 Received: from mail171-db9 (localhost [127.0.0.1]) by mail171-db9-R.bigfish.com (Postfix) with ESMTP id 59CEC440175; Fri, 3 Jan 2014 18:09:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI98dI9371Ic89bh148cIc85dh1418Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail171-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbharath@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(24454002)(51444003)(199002)(189002)(479174003)(377454003)(52604005)(19580405001)(19580395003)(54316002)(83322001)(85852003)(83072002)(56816005)(18717965001)(90146001)(85306002)(76576001)(19300405004)(76786001)(76796001)(74366001)(15975445006)(69226001)(81342001)(79102001)(77982001)(59766001)(80022001)(65816001)(63696002)(66066001)(56776001)(81542001)(16236675002)(87936001)(2656002)(74662001)(31966008)(80976001)(76482001)(87266001)(33646001)(15202345003)(74706001)(47446002)(74502001)(74876001)(81816001)(49866001)(47736001)(4396001)(50986001)(47976001)(51856001)(53806001)(54356001)(81686001)(74316001)(46102001)(24736002)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB567; H:BY2PR05MB568.namprd05.prod.outlook.com; CLIP:116.197.184.15; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail171-db9 (localhost.localdomain [127.0.0.1]) by mail171-db9 (MessageSwitch) id 1388772574748635_1575; Fri, 3 Jan 2014 18:09:34 +0000 (UTC) Received: from DB9EHSMHS010.bigfish.com (unknown [10.174.16.248]) by mail171-db9.bigfish.com (Postfix) with ESMTP id AE6714C004A; Fri, 3 Jan 2014 18:09:34 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS010.bigfish.com (10.174.14.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 3 Jan 2014 18:09:30 +0000 Received: from BY2PR05MB567.namprd05.prod.outlook.com (10.141.220.22) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 3 Jan 2014 18:09:27 +0000 Received: from BY2PR05MB568.namprd05.prod.outlook.com (10.141.220.27) by BY2PR05MB567.namprd05.prod.outlook.com (10.141.220.22) with Microsoft SMTP Server (TLS) id 15.0.842.7; Fri, 3 Jan 2014 18:09:24 +0000 Received: from BY2PR05MB568.namprd05.prod.outlook.com ([10.141.220.27]) by BY2PR05MB568.namprd05.prod.outlook.com ([10.141.220.27]) with mapi id 15.00.0842.003; Fri, 3 Jan 2014 18:09:24 +0000 From: Bharath R To: "stbryant@cisco.com" , "rtgwg@ietf.org" , "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "imc.shand@gmail.com" , "cfilsfil@cisco.com" , "sprevidi@cisco.com" , "Ning.So@tatacommunications.com" Subject: RE: Regarding cost based algorithm for finding Extended P-Space. Thread-Topic: Regarding cost based algorithm for finding Extended P-Space. Thread-Index: Ac8Id9tfGC7DxP3KTpWaJMen1KzBtgAE9PWAAADSKUAABbFuAAAAR+zAAAGX5QAAAAsFkA== Date: Fri, 3 Jan 2014 18:09:23 +0000 Message-ID: References: <9ecf740f25084ccd9834ffb0a63e60e2@BY2PR05MB568.namprd05.prod.outlook.com> <52C6C1B1.5050100@cisco.com> <52C6ED68.50207@cisco.com> <7972e3aa998a4a63b26b4632eae47423@BY2PR05MB568.namprd05.prod.outlook.com> <52C6F9FC.9050206@cisco.com> In-Reply-To: <52C6F9FC.9050206@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.15] x-forefront-prvs: 00808B16F3 Content-Type: multipart/alternative; boundary="_000_f4f8dd80ba2d42d8a35f18c552726badBY2PR05MB568namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Mon, 06 Jan 2014 08:05:27 -0800 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 18:09:52 -0000 --_000_f4f8dd80ba2d42d8a35f18c552726badBY2PR05MB568namprd05pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stewart, Thanks for your inputs. Yes, this formula does not cover the Node-protecting P-Space, for which the= formulae specified in https://ietf.org/doc/draft-psarkar-rtgwg-rlfa-node-protection/ Thanks for your offer of running this by Mike. Hoping to hear from that. Also, I would like one more input, if you may: Do you think there would be some practical use-case for preferring A2(loop = causing neighbor) as the backup-neighbor over A1(non loop-causing Neighbor)= ? Thanks and Regards, Bharath R. From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Friday, January 03, 2014 11:27 PM To: Bharath R; rtgwg@ietf.org; draft-ietf-rtgwg-remote-lfa@tools.ietf.org; = imc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So@tataco= mmunications.com Subject: Re: Regarding cost based algorithm for finding Extended P-Space. Bharath I will run this past Mike when he gets back next week, but I think you are correct. Note that this simplification will not work when we come to node protection since you must look at alternative paths through the nodes, but for link protection, I think you are correct to state that avoiding the rep= airing node is sufficient. Thanks for picking this up. - Stewart On 03/01/2014 17:29, Bharath R wrote: Hi Stewart, The point here is not about the P-Space, but the eligible Backup-Neighbor t= o reach P-Space. In the below topology, the P-Space remains unchanged, but we have two possi= ble backup-neighbors: A1, which does not have looping problems A2, which loops back the traffic to S, and then has it going via A1, before= reaching the other P-Space nodes and eventually the PQ node. But, with application of formula 2), we will have only A1 as the viable bac= kup Neighbor. And regarding the second formula ensuring that the packet does not take the= failed link(The SE link): To re-quote the formulae: 1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_= opt(Protected_link.RemoteNode, Y)) 2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) Since formula 2). ensures that the packet does not reach S itself, the ques= tion of taking the SE link does not arise. In fact, the formula 2) gives a 'non-loopingback' subset of neighbors as co= mpared to formula 1). Furthermore, existence of a Neighbor(Ni) satisfying Formula 1), but not sat= isfying formula 2), should imply existence of some other Neighbor(Nj) satis= fying formula 2). Because eventually Ni will loopback the traffic via Nj. So, we will not miss out on finding a viable neighbor if one exists. Please let me know if there is any gap in my understanding/analysis. Thanks and regards, Bharath R. From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Friday, January 03, 2014 10:34 PM To: Bharath R; rtgwg@ietf.org; draft-ietf-rtgwg-remo= te-lfa@tools.ietf.org; i= mc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So@= tatacommunications.com Subject: Re: Regarding cost based algorithm for finding Extended P-Space. The purpose of the two protected link terms was to make sure that there was no attempt to reach PQ via that link. If we remove them we need to make sure that no topology will cause that path to be taken, and I think that your equation could fail on that account. I need to think about this some more, but even if A2 is in P space, it is not in D's Qspace so surely the point is moot? - Stewart On 03/01/2014 14:40, Bharath R wrote: Thank you for your reply Stuart Sorry, the formula is not verbatim from the draft, but if you refer to the = formula in Compute_Extended_P_Space()snippet in the http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-04, you will find that the formula used maps to D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_opt(= Protected_link.RemoteNode, Y)) Here: S : Source Node. Ni: Neighbor, D_opt(x, y): Optimal distance from x to y. Sorry for the corruption in topology. I am recreating it here: and A2-->S cost is 5; (Only in the direction as indicated., the other direc= tion cost is unity) All other costs are unity. |--------= -----| | = S | |--------= -----| | |= | | |= |ProtectedLink | |= | | |= | --------------- | = ---------------- | |= | | |= | | |= | | |= 5 | |-----------| |--------= ---| |-----------| | A1 | | A2 = | | E | |-----------| |--------= ---| |-----------| | = | | = | | = | |-----------| = |-----------| | B | = | D | |-----------| = |-----------| | = | | = | | |-----= ------| | |--------------| C = |-----------| |----= -------| Yes, even I am not sure of the practicality of the above topology, But, my only point was that we have a simpler, easier to use formula: D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) to find viable backups Neighbors to reach P-Space. Further, the formula does not result in exclusion of any viable Neighbor th= at loop-back to the source. Would be great if you can comment on that. Thanks and Regards, Bharath R. From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Friday, January 03, 2014 7:27 PM To: Bharath R; rtgwg@ietf.org; draft-ietf-rtgwg-remo= te-lfa@tools.ietf.org; i= mc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So@= tatacommunications.com Subject: Re: Regarding cost based algorithm for finding Extended P-Space. On 03/01/2014 11:35, Bharath R wrote: Hi, I have a query on cost based formula for finding Extended P-space. The current formula applies to Node y that is 1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_= opt(Protected_link.RemoteNode, Y)) Bharath I cannot see this text in the draft. Is it from the text or your code? Also the example below has been corrupted. Not that asymmetric costs are always problematic in LFA solutions, but it is not clear how frequently they show in real topologies other than by accident. Stewart I guess the rationale behind the current formula is that the packet on the = LDP tunnel should not traverse the ProtectedLink. But, please consider the following toplogy. A2-->B cost is 5 and A2-->S cost is 3; (Both only in the direction as indic= ated., the other direction cost is unity) All other costs are unity. Following the formula, both A1 and A2 can become backup neighbors(with P-Sp= ace B and C). However, an LDP tunnel setup via A2 will loopback to S, taking A2-->S-->A1 = path. |---------= ----| | S = | |--------= -----| | = | | | |= | | = | |ProtectedLink | |= | | = | | | | | --------------- | = ---------------- | |= | | |= | | |= | | |= | | = |5 | |-----------| |--------= ---| |-----------| | A1 | | A2 = | | E | |-----------| |--------= ---| |-----------| | = | | = | | = | | = | | = | |-----------| |----= -------| | B | = | D | |-----------| = |-----------| | = | | = | | |-----= ------| | |--------------| C = |-----------| |---= --------| How about using the following basic formula instead? 2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) Advantages: =B7 The formula two ensures that the packet does not loopback to S. =B7 Also as per my understanding, if there is Neighbor Ni that sati= sfies 1), but does not satisfy 2), it implies that there is definitely one = more Neigbhro Nj which satisfies 1) both 1) and 2). (Because if there is a neighbor satisfying 1) and not satisfy 2), then the = packet will loopback via some other neighbor which satisfies 2)). Given that formula 2) ensures that we don't select any neighbor which simpl= y loopbacks the packet to the source and forwards via other viable Neighbor= , it will be more advantageous to employ Formula 2). Please let me know if I am missing something, or if there is a good use cas= e that may prefer backup-neighbor A2 in this example, over backup neighbor = A1.(Given that traffic will exit via A1 anyway). Thanks and Regards, Bharath R. -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_f4f8dd80ba2d42d8a35f18c552726badBY2PR05MB568namprd05pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Stewart,

Thanks for your inputs.

Yes, this formula does no= t cover the Node-protecting P-Space, for which the formulae specified in

https://ietf.org/doc/draft-psarkar-rtgwg-rlfa-node-p= rotection/

 

Thanks for your offer of running this by Mike. Hopin= g to hear from that.

 

Also, I would like one more input, if you may:<= /o:p>

Do you think there would be some practical use-case = for preferring A2(loop causing neighbor) as the backup-neighbor over A1(non= loop-causing Neighbor)?

 

Thanks and Regards,

Bharath R.

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Friday, January 03, 2014 11:27 PM
To: Bharath R; rtgwg@ietf.org; draft-ietf-rtgwg-remote-lfa@tools.iet= f.org; imc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So= @tatacommunications.com
Subject: Re: Regarding cost based algorithm for finding Extended P-S= pace.

 

Bharath

I will run this past Mike when he gets back next week, but I think you are<= br> correct. Note that this simplification will not work when we come to node protection since you must look at alternative paths through the nodes, but<= br> for link protection, I think you are correct to state that avoiding the rep= airing
node is sufficient.

Thanks for picking this up.

- Stewart

On 03/01/2014 17:29, Bharath R wrote:

Hi Stewart,

The point here is not about the P-Space, b= ut the eligible Backup-Neighbor to reach P-Space.

In the below topology, the P-Space remains= unchanged, but we have two possible backup-neighbors:

A1, which does not have looping problems

A2, which loops back the traffic to S, and= then has it going via A1, before reaching the  other P-Space nodes an= d eventually the PQ node.

But, with application of formula 2), we wi= ll have only A1 as the viable backup Neighbor.

 

And regarding the second formula ensuring = that the packet does not take the failed link(The SE link):

 

To re-quote the formulae:

1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Prote= cted_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))

2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))

 

 

Since formula 2). ensures that the packet = does not reach S itself, the question of taking the SE link does not arise.=

In fact, the formula 2) gives a ‘non= -loopingback’ subset of neighbors as compared to formula 1).

 

Furthermore, existence of a Neighbor(Ni) s= atisfying Formula 1), but not satisfying formula 2), should imply existence= of some other Neighbor(Nj) satisfying formula 2).

Because eventually Ni will loopback the tr= affic via Nj.

So, we will not miss out on finding a viab= le neighbor if one exists.

 

Please let me know if there is any gap in = my understanding/analysis.

 

Thanks and regards,

Bharath R.

 <= /p>

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Friday, January 03, 2014 10:34 PM
To: Bharath R; rtgwg@ietf.org;= draft-ietf-rtgwg-remote-lfa@tools.ietf.org; imc.shand@gmail.com; cfilsfil@cis= co.com; sprevidi@cisco.com; Ning.So@tatacommunications.com
Subject: Re: Regarding cost based algorithm for finding Extended P-S= pace.

 

The purpose of the two protected link terms was to make sure that there was no attempt to reach PQ via
that link. If we remove them we need to make sure
that no topology will cause that path to be taken,
and I think that your equation could fail on that
account.

I need to think about this some more, but
even if A2 is in P space, it is not in D's
Qspace so surely the point is moot?

- Stewart

On 03/01/2014 14:40, Bharath R wrote:

Thank you for your reply = Stuart

 <= /p>

Sorry, the formula is not= verbatim from the draft, but if you refer to the formula in

Compute_Extended_P_Space()snippet

in the http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-04,

 

you will find that the formula used maps to

D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected= _link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))

Here:

S : Source Node.

Ni:  Neighbor,

D_opt(x, y): Optimal distance from x to y.

 

Sorry for the corruption in topology. I am recreating it= here:

and A2=E0S cost is 5; (Only in the direction as indicated., the other direction cos= t is unity)

All other costs are unity.

 

 

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |        S &nbs= p;     |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =       |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |    &nbs= p; |       |ProtectedLink

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =       |

         &n= bsp;            = ;            &n= bsp;            = ;             &= nbsp;      |      | =       |

         &n= bsp;            = ;            &n= bsp;            = ;   ---------------     |   &n= bsp;  ----------------

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              | =             &nb= sp;            |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  &nbs= p;            &= nbsp;          |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  = ;            &n= bsp;           |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |5=             &nb= sp;           |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; A1    |          = ;|    A2     |    &n= bsp;   |     E       |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;   |           = ;            &n= bsp;             &nb= sp;             |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =                =              &= nbsp;           |<= /o:p>

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              &n= bsp;             &nb= sp;             |

         &n= bsp;            &nbs= p;             =         |-----------|  &n= bsp;            &nbs= p;              = ; |-----------|

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; B       |       =              &n= bsp;           | &nb= sp;   D      | 

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;            =             &nb= sp;     |-----------| 

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =         |-----------|    =           |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |--------------|     C    =   |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          |-----------| &n= bsp; 

 

Yes, even I am not sure of the practicality of th= e above topology,

But, my only point was that we have a simpler,
easier to use formula:

D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))

to find viable backups Neighbors to reach P-Space= .

Further, the formula does not result in exclusion= of any viable Neighbor that loop-back to the source.

 

Would be great if you can comment on that.=

 

Thanks and Regards,

Bharath R.

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Friday, January 03, 2014 7:27 PM
To: Bharath R; rtgwg@ietf.org;= draft-ietf-rtgwg-remote-lfa@tools.ietf.org; imc.shand@gmail.com; cfilsfil@cis= co.com; sprevidi@cisco.com; Ning.So@tatacommunications.com
Subject: Re: Regarding cost based algorithm for finding Extended P-S= pace.

 

On 03/01/2014 11:35, Bharath R wrote:

Hi,

I have a query on cost based formula for finding Extende= d P-space.

The current formula applies to Node y that is

1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Prote= cted_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))


Bharath

I cannot see this text in the draft. Is it from the text or your code?

Also the example below has been corrupted.

Not that asymmetric costs are always problematic in LFA solutions, but
it is not clear how frequently they show in real topologies other than
by accident.

Stewart






 

I guess the rationale behind the current formula is that= the packet on the LDP tunnel should not traverse the ProtectedLink.=

 

 

But, please consider the following toplogy.<= /o:p>

A2=E0B c= ost is 5 and A2=E0S cost is 3; (Both only in the direction as indicated., the other direction = cost is unity)

All other costs are unity.

Following the formula, both A1 and A2 can become backup = neighbors(with P-Space B and C).

However, an LDP tunnel setup via A2 will loopback to S, = taking A2=E0S=E0A1 path.

 

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |     S    = ;   |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;        |      | = ;     |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =      |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;        |    &nb= sp; |      |ProtectedLink

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =      |

         &n= bsp;            = ;            &n= bsp;            = ;             &= nbsp;       |      | = ;     |

         &n= bsp;            = ;             &= nbsp;           &nbs= p; |      |      |=

         &n= bsp;            = ;            &n= bsp;            = ;   ---------------      |  &n= bsp;   ----------------

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              | =             &nb= sp;            |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              | =             &nb= sp;            |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  &nbs= p;            &= nbsp;          |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  = ;            &n= bsp;           |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =               |= 5            &n= bsp;           |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; A1   |         | = ;   A2     |     &nb= sp;  |     E       |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;   |           = ;            &n= bsp;             &nb= sp;             |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =               &= nbsp;            &nb= sp;          |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              &n= bsp;              &n= bsp;             |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =                =              &= nbsp;           |<= /o:p>

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              &n= bsp;             &nb= sp;             |

         &n= bsp;            &nbs= p;        |-----------|   = ;             &= nbsp;         |-----------|=

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; B       |       =              &n= bsp;           | &nb= sp;   D    | 

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;            =             &nb= sp;     |-----------| 

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =         |-----------|    =           |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |--------------|     C    =   |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;           |-----------|&n= bsp;  

 

How about using the following basic formula instead?

2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))

 

 

Advantages:

=B7         The formula two ensures that the packet does not= loopback to S.

=B7         Also as per my understanding, if there is Neighb= or Ni that satisfies 1), but does not satisfy 2), it implies that there is = definitely one more Neigbhro Nj which satisfies 1) both 1) and 2).

(Because if there is a neighbor satisfying 1) and not sa= tisfy 2), then the packet will loopback via some other neighbor which satis= fies 2)).


Given that formula 2) ensures that we don’t select any neighbor wh= ich simply loopbacks the packet to the source and forwards via other viable= Neighbor, it will be more advantageous to employ Formula 2).

 

Please let me know if I am missing something, or if ther= e is a good use case that may prefer backup-neighbor A2 in this example, ov= er backup neighbor A1.(Given that traffic will exit via A1 anyway).

 

 

 

 

Thanks and Regards,

Bharath R.

 






-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 





-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 
--_000_f4f8dd80ba2d42d8a35f18c552726badBY2PR05MB568namprd05pro_-- From rbharath@juniper.net Fri Jan 3 10:20:45 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE901ADFC8 for ; Fri, 3 Jan 2014 10:20:45 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RUpjV6M8DbP for ; Fri, 3 Jan 2014 10:20:40 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id 113F31ADFB1 for ; Fri, 3 Jan 2014 10:20:39 -0800 (PST) Received: from mail203-db9-R.bigfish.com (10.174.16.233) by DB9EHSOBE020.bigfish.com (10.174.14.83) with Microsoft SMTP Server id 14.1.225.22; Fri, 3 Jan 2014 18:20:31 +0000 Received: from mail203-db9 (localhost [127.0.0.1]) by mail203-db9-R.bigfish.com (Postfix) with ESMTP id 3C26D20091; Fri, 3 Jan 2014 18:20:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371Ic89bh1431J148cIc85dh1418Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail203-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbharath@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(24454002)(51444003)(377454003)(479174003)(51694002)(199002)(189002)(52604005)(74316001)(81816001)(81686001)(90146001)(80976001)(74366001)(56816005)(46102001)(85852003)(83072002)(33646001)(51856001)(53806001)(54316002)(76482001)(19300405004)(54356001)(76576001)(74706001)(47736001)(76786001)(76796001)(59766001)(79102001)(50986001)(47976001)(49866001)(77982001)(66066001)(65816001)(76176001)(80022001)(63696002)(85306002)(15975445006)(56776001)(4396001)(74876001)(15202345003)(31966008)(69226001)(18717965001)(16236675002)(74662001)(47446002)(81342001)(74502001)(19580405001)(87936001)(87266001)(19580395003)(83322001)(2656002)(81542001)(24736002)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB565; H:BY2PR05MB568.namprd05.prod.outlook.com; CLIP:116.197.184.15; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail203-db9 (localhost.localdomain [127.0.0.1]) by mail203-db9 (MessageSwitch) id 1388773228142192_9843; Fri, 3 Jan 2014 18:20:28 +0000 (UTC) Received: from DB9EHSMHS008.bigfish.com (unknown [10.174.16.251]) by mail203-db9.bigfish.com (Postfix) with ESMTP id 1CF29120044; Fri, 3 Jan 2014 18:20:28 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS008.bigfish.com (10.174.14.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 3 Jan 2014 18:20:23 +0000 Received: from BY2PR05MB565.namprd05.prod.outlook.com (10.141.220.12) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 3 Jan 2014 18:20:20 +0000 Received: from BY2PR05MB568.namprd05.prod.outlook.com (10.141.220.27) by BY2PR05MB565.namprd05.prod.outlook.com (10.141.220.12) with Microsoft SMTP Server (TLS) id 15.0.842.7; Fri, 3 Jan 2014 18:20:18 +0000 Received: from BY2PR05MB568.namprd05.prod.outlook.com ([10.141.220.27]) by BY2PR05MB568.namprd05.prod.outlook.com ([10.141.220.27]) with mapi id 15.00.0842.003; Fri, 3 Jan 2014 18:20:17 +0000 From: Bharath R To: "'stbryant@cisco.com'" <'stbryant@cisco.com'>, "rtgwg@ietf.org" , "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "imc.shand@gmail.com" , "cfilsfil@cisco.com" , "sprevidi@cisco.com" , "Ning.So@tatacommunications.com" Subject: FW: Regarding cost based algorithm for finding Extended P-Space. Thread-Topic: Regarding cost based algorithm for finding Extended P-Space. Thread-Index: Ac8Id9tfGC7DxP3KTpWaJMen1KzBtgAE9PWAAADSKUAABbFuAAAAR+zAAAGX5QAAAAsFkAAAjBhA Date: Fri, 3 Jan 2014 18:20:17 +0000 Message-ID: <3304a77779394ac4a73c27a1ce1f4680@BY2PR05MB568.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.15] x-forefront-prvs: 00808B16F3 Content-Type: multipart/alternative; boundary="_000_3304a77779394ac4a73c27a1ce1f4680BY2PR05MB568namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Mon, 06 Jan 2014 08:05:27 -0800 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 18:20:45 -0000 --_000_3304a77779394ac4a73c27a1ce1f4680BY2PR05MB568namprd05pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just wanted to make explicit that the loop-causing neighbor packets reachin= g out a loop-causing neighbor A2, would eventually exit out of one of the n= on-loop causing viable Neighbor A1. So, could there still be a practical use-case for choosing A2 over A1? Thanks and Regards, Bharath R. From: Bharath R Sent: Friday, January 03, 2014 11:39 PM To: 'stbryant@cisco.com'; rtgwg@ietf.org; draft-ietf-rtgwg-remote-lfa@tools= .ietf.org; imc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Nin= g.So@tatacommunications.com Subject: RE: Regarding cost based algorithm for finding Extended P-Space. Hi Stewart, Thanks for your inputs. Yes, this formula does not cover the Node-protecting P-Space, for which the= formulae specified in https://ietf.org/doc/draft-psarkar-rtgwg-rlfa-node-protection/ Thanks for your offer of running this by Mike. Hoping to hear from that. Also, I would like one more input, if you may: Do you think there would be some practical use-case for preferring A2(loop = causing neighbor) as the backup-neighbor over A1(non loop-causing Neighbor)= ? Thanks and Regards, Bharath R. From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Friday, January 03, 2014 11:27 PM To: Bharath R; rtgwg@ietf.org; draft-ietf-rtgwg-remo= te-lfa@tools.ietf.org; i= mc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So@= tatacommunications.com Subject: Re: Regarding cost based algorithm for finding Extended P-Space. Bharath I will run this past Mike when he gets back next week, but I think you are correct. Note that this simplification will not work when we come to node protection since you must look at alternative paths through the nodes, but for link protection, I think you are correct to state that avoiding the rep= airing node is sufficient. Thanks for picking this up. - Stewart On 03/01/2014 17:29, Bharath R wrote: Hi Stewart, The point here is not about the P-Space, but the eligible Backup-Neighbor t= o reach P-Space. In the below topology, the P-Space remains unchanged, but we have two possi= ble backup-neighbors: A1, which does not have looping problems A2, which loops back the traffic to S, and then has it going via A1, before= reaching the other P-Space nodes and eventually the PQ node. But, with application of formula 2), we will have only A1 as the viable bac= kup Neighbor. And regarding the second formula ensuring that the packet does not take the= failed link(The SE link): To re-quote the formulae: 1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_= opt(Protected_link.RemoteNode, Y)) 2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) Since formula 2). ensures that the packet does not reach S itself, the ques= tion of taking the SE link does not arise. In fact, the formula 2) gives a 'non-loopingback' subset of neighbors as co= mpared to formula 1). Furthermore, existence of a Neighbor(Ni) satisfying Formula 1), but not sat= isfying formula 2), should imply existence of some other Neighbor(Nj) satis= fying formula 2). Because eventually Ni will loopback the traffic via Nj. So, we will not miss out on finding a viable neighbor if one exists. Please let me know if there is any gap in my understanding/analysis. Thanks and regards, Bharath R. From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Friday, January 03, 2014 10:34 PM To: Bharath R; rtgwg@ietf.org; draft-ietf-rtgwg-remo= te-lfa@tools.ietf.org; i= mc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So@= tatacommunications.com Subject: Re: Regarding cost based algorithm for finding Extended P-Space. The purpose of the two protected link terms was to make sure that there was no attempt to reach PQ via that link. If we remove them we need to make sure that no topology will cause that path to be taken, and I think that your equation could fail on that account. I need to think about this some more, but even if A2 is in P space, it is not in D's Qspace so surely the point is moot? - Stewart On 03/01/2014 14:40, Bharath R wrote: Thank you for your reply Stuart Sorry, the formula is not verbatim from the draft, but if you refer to the = formula in Compute_Extended_P_Space()snippet in the http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-04, you will find that the formula used maps to D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_opt(= Protected_link.RemoteNode, Y)) Here: S : Source Node. Ni: Neighbor, D_opt(x, y): Optimal distance from x to y. Sorry for the corruption in topology. I am recreating it here: and A2-->S cost is 5; (Only in the direction as indicated., the other direc= tion cost is unity) All other costs are unity. |--------= -----| | = S | |--------= -----| | |= | | |= |ProtectedLink | |= | | |= | --------------- | = ---------------- | |= | | |= | | |= | | |= 5 | |-----------| |--------= ---| |-----------| | A1 | | A2 = | | E | |-----------| |--------= ---| |-----------| | = | | = | | = | |-----------| = |-----------| | B | = | D | |-----------| = |-----------| | = | | = | | |-----= ------| | |--------------| C = |-----------| |----= -------| Yes, even I am not sure of the practicality of the above topology, But, my only point was that we have a simpler, easier to use formula: D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) to find viable backups Neighbors to reach P-Space. Further, the formula does not result in exclusion of any viable Neighbor th= at loop-back to the source. Would be great if you can comment on that. Thanks and Regards, Bharath R. From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Friday, January 03, 2014 7:27 PM To: Bharath R; rtgwg@ietf.org; draft-ietf-rtgwg-remo= te-lfa@tools.ietf.org; i= mc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.com; Ning.So@= tatacommunications.com Subject: Re: Regarding cost based algorithm for finding Extended P-Space. On 03/01/2014 11:35, Bharath R wrote: Hi, I have a query on cost based formula for finding Extended P-space. The current formula applies to Node y that is 1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_= opt(Protected_link.RemoteNode, Y)) Bharath I cannot see this text in the draft. Is it from the text or your code? Also the example below has been corrupted. Not that asymmetric costs are always problematic in LFA solutions, but it is not clear how frequently they show in real topologies other than by accident. Stewart I guess the rationale behind the current formula is that the packet on the = LDP tunnel should not traverse the ProtectedLink. But, please consider the following toplogy. A2-->B cost is 5 and A2-->S cost is 3; (Both only in the direction as indic= ated., the other direction cost is unity) All other costs are unity. Following the formula, both A1 and A2 can become backup neighbors(with P-Sp= ace B and C). However, an LDP tunnel setup via A2 will loopback to S, taking A2-->S-->A1 = path. |---------= ----| | S = | |--------= -----| | = | | | |= | | = | |ProtectedLink | |= | | = | | | | | --------------- | = ---------------- | |= | | |= | | |= | | |= | | = |5 | |-----------| |--------= ---| |-----------| | A1 | | A2 = | | E | |-----------| |--------= ---| |-----------| | = | | = | | = | | = | | = | |-----------| |----= -------| | B | = | D | |-----------| = |-----------| | = | | = | | |-----= ------| | |--------------| C = |-----------| |---= --------| How about using the following basic formula instead? 2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y)) Advantages: =B7 The formula two ensures that the packet does not loopback to S. =B7 Also as per my understanding, if there is Neighbor Ni that sati= sfies 1), but does not satisfy 2), it implies that there is definitely one = more Neigbhro Nj which satisfies 1) both 1) and 2). (Because if there is a neighbor satisfying 1) and not satisfy 2), then the = packet will loopback via some other neighbor which satisfies 2)). Given that formula 2) ensures that we don't select any neighbor which simpl= y loopbacks the packet to the source and forwards via other viable Neighbor= , it will be more advantageous to employ Formula 2). Please let me know if I am missing something, or if there is a good use cas= e that may prefer backup-neighbor A2 in this example, over backup neighbor = A1.(Given that traffic will exit via A1 anyway). Thanks and Regards, Bharath R. -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_3304a77779394ac4a73c27a1ce1f4680BY2PR05MB568namprd05pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Just wanted to make expli= cit that the loop-causing neighbor packets reaching out a loop-causing neig= hbor A2, would eventually exit out of one of the non-loop causing viable Neighbor A1.

So, could there still be = a practical use-case for choosing A2 over A1?

 <= /p>

Thanks and Regards,
Bharath R.

 <= /p>

From: Bharath R
Sent: Friday, January 03, 2014 11:39 PM
To: 'stbryant@cisco.com'; rtgwg@ietf.org; draft-ietf-rtgwg-remote-lf= a@tools.ietf.org; imc.shand@gmail.com; cfilsfil@cisco.com; sprevidi@cisco.c= om; Ning.So@tatacommunications.com
Subject: RE: Regarding cost based algorithm for finding Extended P-S= pace.

 

Hi Stewart,

Thanks for your inputs.

Yes, this formula does no= t cover the Node-protecting P-Space, for which the formulae specified in

https://ietf.org/doc/draft-psarkar-rtgwg-rlfa-node-p= rotection/

 

Thanks for your offer of running this by Mike. Hopin= g to hear from that.

 

Also, I would like one more input, if you may:<= /o:p>

Do you think there would be some practical use-case = for preferring A2(loop causing neighbor) as the backup-neighbor over A1(non= loop-causing Neighbor)?

 

Thanks and Regards,

Bharath R.

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Friday, January 03, 2014 11:27 PM
To: Bharath R; rtgwg@ietf.org;= draft-ietf-rtgwg-remote-lfa@tools.ietf.org; imc.shand@gmail.com; cfilsfil@cis= co.com; sprevidi@cisco.com; Ning.So@tatacommunications.com
Subject: Re: Regarding cost based algorithm for finding Extended P-S= pace.

 

Bharath

I will run this past Mike when he gets back next week, but I think you are<= br> correct. Note that this simplification will not work when we come to node protection since you must look at alternative paths through the nodes, but<= br> for link protection, I think you are correct to state that avoiding the rep= airing
node is sufficient.

Thanks for picking this up.

- Stewart

On 03/01/2014 17:29, Bharath R wrote:

Hi Stewart,

The point here is not about the P-Space, b= ut the eligible Backup-Neighbor to reach P-Space.

In the below topology, the P-Space remains= unchanged, but we have two possible backup-neighbors:

A1, which does not have looping problems

A2, which loops back the traffic to S, and= then has it going via A1, before reaching the  other P-Space nodes an= d eventually the PQ node.

But, with application of formula 2), we wi= ll have only A1 as the viable backup Neighbor.

 

And regarding the second formula ensuring = that the packet does not take the failed link(The SE link):

 

To re-quote the formulae:

1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Prote= cted_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))

2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))

 

 

Since formula 2). ensures that the packet = does not reach S itself, the question of taking the SE link does not arise.=

In fact, the formula 2) gives a ‘non= -loopingback’ subset of neighbors as compared to formula 1).

 

Furthermore, existence of a Neighbor(Ni) s= atisfying Formula 1), but not satisfying formula 2), should imply existence= of some other Neighbor(Nj) satisfying formula 2).

Because eventually Ni will loopback the tr= affic via Nj.

So, we will not miss out on finding a viab= le neighbor if one exists.

 

Please let me know if there is any gap in = my understanding/analysis.

 

Thanks and regards,

Bharath R.

 <= /p>

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Friday, January 03, 2014 10:34 PM
To: Bharath R; rtgwg@ietf.org;= draft-ietf-rtgwg-remote-lfa@tools.ietf.org; imc.shand@gmail.com; cfilsfil@cis= co.com; sprevidi@cisco.com; Ning.So@tatacommunications.com
Subject: Re: Regarding cost based algorithm for finding Extended P-S= pace.

 

The purpose of the two protected link terms was to make sure that there was no attempt to reach PQ via
that link. If we remove them we need to make sure
that no topology will cause that path to be taken,
and I think that your equation could fail on that
account.

I need to think about this some more, but
even if A2 is in P space, it is not in D's
Qspace so surely the point is moot?

- Stewart

On 03/01/2014 14:40, Bharath R wrote:

Thank you for your reply = Stuart

 <= /p>

Sorry, the formula is not= verbatim from the draft, but if you refer to the formula in

Compute_Extended_P_Space()snippet

in the http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-04,

 

you will find that the formula used maps to

D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected= _link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))

Here:

S : Source Node.

Ni:  Neighbor,

D_opt(x, y): Optimal distance from x to y.

 

Sorry for the corruption in topology. I am recreating it= here:

and A2=E0S cost is 5; (Only in the direction as indicated., the other direction cos= t is unity)

All other costs are unity.

 

 

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |        S &nbs= p;     |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =       |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |    &nbs= p; |       |ProtectedLink

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =       |

         &n= bsp;            = ;            &n= bsp;            = ;             &= nbsp;      |      | =       |

         &n= bsp;            = ;            &n= bsp;            = ;   ---------------     |   &n= bsp;  ----------------

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              | =             &nb= sp;            |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  &nbs= p;            &= nbsp;          |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  = ;            &n= bsp;           |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |5=             &nb= sp;           |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; A1    |          = ;|    A2     |    &n= bsp;   |     E       |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;   |           = ;            &n= bsp;             &nb= sp;             |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =                =              &= nbsp;           |<= /o:p>

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              &n= bsp;             &nb= sp;             |

         &n= bsp;            &nbs= p;             =         |-----------|  &n= bsp;            &nbs= p;              = ; |-----------|

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; B       |       =              &n= bsp;           | &nb= sp;   D      | 

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;            =             &nb= sp;     |-----------| 

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =         |-----------|    =           |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |--------------|     C    =   |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          |-----------| &n= bsp; 

 

Yes, even I am not sure of the practicality of th= e above topology,

But, my only point was that we have a simpler,
easier to use formula:

D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))

to find viable backups Neighbors to reach P-Space= .

Further, the formula does not result in exclusion= of any viable Neighbor that loop-back to the source.

 

Would be great if you can comment on that.=

 

Thanks and Regards,

Bharath R.

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Friday, January 03, 2014 7:27 PM
To: Bharath R; rtgwg@ietf.org;= draft-ietf-rtgwg-remote-lfa@tools.ietf.org; imc.shand@gmail.com; cfilsfil@cis= co.com; sprevidi@cisco.com; Ning.So@tatacommunications.com
Subject: Re: Regarding cost based algorithm for finding Extended P-S= pace.

 

On 03/01/2014 11:35, Bharath R wrote:

Hi,

I have a query on cost based formula for finding Extende= d P-space.

The current formula applies to Node y that is

1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Prote= cted_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y))


Bharath

I cannot see this text in the draft. Is it from the text or your code?

Also the example below has been corrupted.

Not that asymmetric costs are always problematic in LFA solutions, but
it is not clear how frequently they show in real topologies other than
by accident.

Stewart





 

I guess the rationale behind the current formula is that= the packet on the LDP tunnel should not traverse the ProtectedLink.=

 

 

But, please consider the following toplogy.<= /o:p>

A2=E0B c= ost is 5 and A2=E0S cost is 3; (Both only in the direction as indicated., the other direction = cost is unity)

All other costs are unity.

Following the formula, both A1 and A2 can become backup = neighbors(with P-Space B and C).

However, an LDP tunnel setup via A2 will loopback to S, = taking A2=E0S=E0A1 path.

 

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |     S    = ;   |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |-------------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;        |      | = ;     |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =      |

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;        |    &nb= sp; |      |ProtectedLink

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |      | =      |

         &n= bsp;            = ;            &n= bsp;            = ;             &= nbsp;       |      | = ;     |

         &n= bsp;            = ;             &= nbsp;           &nbs= p; |      |      |=

         &n= bsp;            = ;            &n= bsp;            = ;   ---------------      |  &n= bsp;   ----------------

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              | =             &nb= sp;            |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              | =             &nb= sp;            |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  &nbs= p;            &= nbsp;          |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              |  = ;            &n= bsp;           |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =               |= 5            &n= bsp;           |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; A1   |         | = ;   A2     |     &nb= sp;  |     E       |

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;       |-----------|   &nbs= p;    |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;   |           = ;            &n= bsp;             &nb= sp;             |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =               &= nbsp;            &nb= sp;          |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              &n= bsp;              &n= bsp;             |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =                =              &= nbsp;           |<= /o:p>

         &n= bsp;            = ;            &n= bsp;            = ;   |          =              &n= bsp;             &nb= sp;             |

         &n= bsp;            &nbs= p;        |-----------|   = ;             &= nbsp;         |-----------|=

         &n= bsp;            = ;            &n= bsp;         |   &nb= sp; B       |       =              &n= bsp;           | &nb= sp;   D    | 

         &n= bsp;            = ;            &n= bsp;         |-----------| &nb= sp;            =             &nb= sp;     |-----------| 

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =             &nb= sp;            =              &n= bsp; |

         &n= bsp;            = ;            &n= bsp;            = ;   |          =         |-----------|    =           |<= /p>

         &n= bsp;            = ;            &n= bsp;            = ;   |--------------|     C    =   |-----------|

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;           |-----------|&n= bsp;  

 

How about using the following basic formula instead?

2). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Y))

 

 

Advantages:

=B7         The formula two ensures that the packet does not= loopback to S.

=B7         Also as per my understanding, if there is Neighb= or Ni that satisfies 1), but does not satisfy 2), it implies that there is = definitely one more Neigbhro Nj which satisfies 1) both 1) and 2).

(Because if there is a neighbor satisfying 1) and not sa= tisfy 2), then the packet will loopback via some other neighbor which satis= fies 2)).


Given that formula 2) ensures that we don’t select any neighbor wh= ich simply loopbacks the packet to the source and forwards via other viable= Neighbor, it will be more advantageous to employ Formula 2).

 

Please let me know if I am missing something, or if ther= e is a good use case that may prefer backup-neighbor A2 in this example, ov= er backup neighbor A1.(Given that traffic will exit via A1 anyway).

 

 

 

 

Thanks and Regards,

Bharath R.

 





-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 



-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 
--_000_3304a77779394ac4a73c27a1ce1f4680BY2PR05MB568namprd05pro_-- From curtis@ipv6.occnc.com Mon Jan 6 09:00:15 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CDE1AE064; Mon, 6 Jan 2014 09:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.261 X-Spam-Level: X-Spam-Status: No, score=0.261 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxwxLm98sDdY; Mon, 6 Jan 2014 09:00:11 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id E0F791AE100; Mon, 6 Jan 2014 09:00:10 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s06H00HS011318; Mon, 6 Jan 2014 12:00:01 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401061700.s06H00HS011318@maildrop2.v6ds.occnc.com> To: Lou Berger In-reply-to: Your message of "Wed, 11 Dec 2013 13:57:47 -0500." <52A8B5AB.4040708@labn.net> Subject: (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 From: Curtis Villamizar Date: Mon, 06 Jan 2014 12:00:00 -0500 Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, rtgwg@ietf.org, "rtg-ads@tools.ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 17:00:15 -0000 Lou et al, Resending. I'm not sure if the original (sent Tue, 17 Dec 2013) went through to all recipients. There may have been a problem (due to a self inflicted DNS issue). I did not get a response so I suspect Lou didn't get this email. Curtis In message <52A8B5AB.4040708@labn.net> Lou Berger writes: > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review. The purpose > of the review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-rtgwg-cl-requirement-13.txt > Reviewer: Lou Berger > Review Date: 2013-12-11 > IETF LC End Date: 2013-12-09 > Intended Status: Informational > > Summary: > > I have some minor concerns about this document that I think > should be resolved before publication. > > Comments: > > I think the document is greatly improved since the previous last > call. I have some comments and reservations on the document that are > described below. As discussed on the list, I remain concerned about the > value of defining requirements in terms of nebulous "Performance > Objectives", but as this is acceptable to the WG I will not elaborate on > this concern further. > > Major Issues: > > No major issues found. > > Minor Issues: > > 1. Terminology & consistency: the document coins the term "Advanced > Multipath": > Advanced Multipath is a formalization of multipath techniques > > Do you see this term as a new noun, like LSP, or as an adjective? I > expected the latter, i.e. that it be used like "multipath" is used in > the above sentence, but it seems to be used as a new noun. I'm not sure > coining a new noun really makes sense, but if this the intent then the > last paragraph of section 2 needs to be revised as "Advanced Multipath" > will now have a specific definition as opposed to a generic term. Also I > suggest always capitalizing it (or even using the abbreviation "AM") > will clarify this distinction. I see multipath as a noun and therefore advanced multipath as a noun. Advanced is an adjective, multipath as a noun. Advanced Multipath is the set of techniques that form a solution. An advanced multipath is a collection of componet links. The former is capitalized, the latter is not. I'll check to see if I got that right in all occurances. If you would like I can also add this to the definition making it: OLD Advanced Multipath Advanced Multipath meets the requirements defined in this document. A key capability of advanced multipath is the support of non-homogeneous component links. NEW Advanced Multipath Advanced Multipath is a formalization of multipath techniques that meets the requirements defined in this document. A key capability of Advanced Multipath is the support of non-homogeneous component links. An "advanced multipath" is a collection of component links. In this document the former is capitalized and the latter is not. If we agree on this I'll just search for "advanced" and make capitalization consistent with the above statements. I don't think the phrase "advanced multipath technique" makes it an adjective any more than a statement such as make-before-break is an MPLS technique" makes MPLS an adjective in normal use. The phrase "an X technique" is simply a shorthand for indicating a "technique applicable to X". Even if that makes it an adjective the phrase "MPLS technique" is common and so that should not be a problem. The paragraph in question might be the following. It seems benign to me. The term Advanced Multipath is intended to be used within the context of this document and the related documents, [I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and any other related document. Other advanced multipath techniques may in the future arise. If the capabilities defined in this document become commonplace, they would no longer be considered "advanced". Use of the term "advanced multipath" outside this document, if referring to the term as defined here, should indicate Advanced Multipath as defined by this document, citing the current document name. If using another definition of "advanced multipath", documents may optionally clarify that they are not using the term "advanced multipath" as defined by this document if clarification is deemed helpful. I see no problem with this. Please be more specific if you think there are places where advanced multipath is used as an adjective or where its use is confusing. > 2. Editorial: server and client layer vs upper and lower layer. > > The document uses server and client layer networks and LSPs and, > sometimes interchangeably or redundantly, upper and lower layer networks > and LSPs. I think this issue can be resolved by avoiding the term > client/server when referring to network layers and just using the > lower/upper terminology. The one exception to this is in the definition > Client LSP which should simply be defined in the context of a multipath, > i.e.: > OLD > A client LSP is an LSP which has been set up over a server layer. > NEW > A client LSP is an LSP which has been set up over Advanced Multipath. A client LSP can be set up over a server layer MPLS-TP LSP or any server layer MPLS LSP or over a link layer or over a pseudowire ... or over an advanced multipath. > I think this also means that usage of the term "Client" is limited to > "Client LSP". I searched for all occurances of the word client. All occurances are "client LSP" excexpt the phrase "client of a client LSP" and that is used only in the following paragraph. The ingress and egress of a multipath may be midpoint LSRs with respect to a given client LSP. A midpoint LSR does not participate in the signaling of any clients of the client LSP. Therefore, in general, multipath endpoints cannot determine requirements of clients of a client LSP through participation in the signaling of the clients of the client LSP. THe point is that "A midpoint LSR does not participate in the signaling of any clients of the client LSP" and that non-participation in client (or higher layer) signaling applies to any "client of a client LSP", not just other LSP running over it. I then searched for all occurances of the words upper and lower and higher. There are no occurances of "upper". There were a few occurances of "lower latency" and "higher latency". Other than that, all occurances of lower and higher except one are in the follwoing text: 3.2. Component Links Provided by Lower Layer Networks A component link may be supported by a lower layer network. For example, the lower layer may be a circuit switched network or another MPLS network (e.g., MPLS-TP)). The lower layer network may change the latency (and/or other performance parameters) seen by the client layer. Currently, there is no protocol for the lower layer network to inform the higher layer network of a change in a performance parameter. Communication of the latency performance parameter is a very important requirement. Communication of other performance parameters (e.g., delay variation) is desirable. FR#8 The solution SHALL specify a protocol means to allow a lower layer server network to communicate latency to the higher layer client network. The exception is this sentence: FR#22 The solution SHOULD support the use case where an advanced multipath itself is a component link for a higher order advanced multipath. For example, an advanced multipath comprised of MPLS- TP bi-directional tunnels viewed as logical links could then be used as a component link in yet another advanced multipath that connects MPLS routers. The terms lower layer and higher layer go all the way back to the ISO seven layer model of ancient times (1970s?, 1980s?) and maybe further back but that is before even my time. I don't think this is unclear but I could add the following in definitions: Higher Layers A client layer is the one immediately above a server layer. The client layer and all layers above that layer are higher layers. Lower Layers A server layer is the later immediately below a client laer. The server layer and all layers below are lower layers. Do I really need to put this in the definitions section? If yoy think it is necessary, I will add it. > 3. Technical: The document should make it clear that LSPs can provide > paths from an Advanced Multipath. I suggest adding something like the > the following at the end of page 3 > d. a lower layer LSP. Case "b." is intended to include LSP but is not specifically limited to LSP. Multipath (not Advanced Multipath) includes IGP ECMP, Ethernet Link Aggregation, and all sorts of things that don't involve MPLS at all. For example, a path in Ethernet Link Aggregation Group (LAG) could be supported by a pseudowires or ODU2e or GFP-F, though this would be unknown to the LAG, or in the simplest case each path in the set of LAG members could be supported by a plain Ethernet cable. > and at the end of the Component Link definition: > A component link may be provided via an LSP. I think this is covered in "3.2. Component Links Provided by Lower Layer Networks". 3.2. Component Links Provided by Lower Layer Networks A component link may be supported by a lower layer network. For example, the lower layer may be a circuit switched network or another MPLS network (e.g., MPLS-TP)). This sort of statement could be made earlier. For example in the discussion following the definitions (on page 5) the document covers one case (where a component link is not an LSP) but it is not until later that the other case is mentioned. I could add a paragraph in the discussion following the definitions that mentions that a component link can also be another LSP. OLD: A Component Link may be a point-to-point physical link (where a "physical link" includes one or more link layer plus a physical layer) or a logical link that preserves ordering in the steady state. A component link may have transient out of order events, but such events must not exceed the network's Performance Objectives. For example, a component link may be comprised of any supportable combination of link layers over a physical layer or over logical sub- layers, including those providing physical layer emulation. NEW: A Component Link may be a point-to-point physical link (where a "physical link" includes one or more link layer plus a physical layer) or a logical link that preserves ordering in the steady state. A component link may have transient out of order events, but such events must not exceed the network's Performance Objectives. For example, a component link may be comprised of any supportable combination of link layers over a physical layer or over logical sub- layers, including those providing physical layer emulation, or over MPLS server layer LSP. These are identical except the phrase ", or over MPLS server layer LSP" added to the end of the last sentence. > 4. Editorial: Unless I'm mistaken, the requirements in this document > apply to the Advanced Multipath solution. In most cases the document > states requirements in the form of "The solution", but in a few cases it > just says "advanced multipath". I think these cases should be changed > to apply to an "Advanced Multipath solution". I think this comment > applies to FR1, FR7, FR18, FR23, GR3-5, and MR1-9. That is not correct. For example: FR#1 An advanced multipath MAY be announced in conjunction with detailed parameters about its component links, such as bandwidth and latency. The advanced multipath SHALL behave as a single IGP adjacency. In this requirement the "advanced multipath" is a specific collection of component links that is announced by way of an MPLS Forwarding Adjaccency (FA) in the IGP. The same is true for the other requirements cited. In all of these cases an advanced multipath is a specific collection of component links. There is a typo in MR#1. OLD MR#1 Management Plane MUST support polling of the status and configuration of an advanced multipath and its individual advanced multipath and support notification of status change. NEW MR#1 Management Plane MUST support polling of the status and configuration of an advanced multipath and its individual component links and support notification of status change. In the last line s/advanced multipath/component links/ > 5. Technical: use of "indicate" in FR10-13, FR14, FR15: > In these cases it is unclear if the requirements apply to > (a) a client's ability to indicate a desired service/LSP constraint or > (b) a selected component link's attribute that will be used by a client > LSP, > (c) both, or > (d) something completely different > The requirements should be clear to which entity the requirement applies. This "indication" can be through signaling or the management plane and both must be supported in later framework and protocol definitions and we can argue then whether both must be supported or if one or the other is a "should" in RFC 2119 speak. There was concern that the word "signal" would exclude providing the same informantion through the management plane and therefore the word "indicate" is used. Rather than spell this out many times we hoped this would be clear. I could add clarifying text up front if you think this is necessary. For example, I could add the following before FR#1. FR#0 In requirements that follow in this document the word "indicate" is used where information may be provided by either the combination of link state IGP advertisement and MPLS LSP signaling or via management plane protocols. In later documents providing framework and protocol definitions both signaling and management plane mechanisms MUST be defined. It would be trivial to make this FR#1 and renumber the rest. Should I add it and renumber? > 6. The last paragraph in section 3.3. strikes me as both odd and out of > place. There are so many possible decisions that must be considered by > network operators relative to disruption and optimization. Why mention > just "power reduction"? Is there something special about the > interactions of multipath and power reduction? What value / information > does this paragraph add? The last paragraph in section 3.3 is: Allowing multipath to contain component links with different characteristics can improve the overall load balance and can be accomplished while still accommodating the more strict requirements of a subset of client LSP. I'm not sure if this is the "odd and out of place" paragraph you refer to. It summarizes the purpose of the requirements in this section. I think you mean section 3.5 and not 3.3. The remainder of your paragraph above discusses power reducetion and this is only mentioned in section 3.5 so I think you mean this paragraph. As with any load balancing change, a change initiated for the purpose of power reduction may be minimally disruptive. Typically the disruption is limited to a change in delay characteristics and the potential for a very brief period with traffic reordering. The network operator when configuring a network for power reduction should weigh the benefit of power reduction against the disadvantage of a minimal disruption. The paragraphs following a set of requirements provide discussion related to that set of requirements. I don't see this as out of place. The prior two paragraphs discuss delay discontinuity. This paragraph is a reminder that "As with any load balancing change, a change initiated for the purpose of power reduction may be minimally disruptive." I don't see this as out of place. For example, to compensate for a less than perfect load balance a subset of LSPs may need to be moved and that subset can be chosen from those which will be least affected (and there are plenty of requirements that compell the fussy LSP to tell the network abour their specifial needs). To power down a component link, *all* LSP on that component link need to be moved, even the very fussy ones. Therefore I think mentioning that disruption should be considered is not out of place in the discussion following these requirements. We like to keep the discussion brief so this level of detail was not included. > 7. Terminology: In GR4&5: what is a "MPLS network topology"? Do you mean AS? At the very least it means something similar to same administrative domain. An AS can be subdivided within an organization. Do you have a better way to define intra-domain and inter-domain without going down the rat hole of defining the term "domain"? No on in the WG had an issue with this so far but I'm open for a suggestion for better wording. > Nits: > > - References should be provided in all cases when referring to > "existing ... techniques" References are not allowed in the abstract. In section 3.3 is the sentence: Refer to the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a description of existing techniques and a set of references. Much of that document is dedicated to describing existing techniques and it contains quite a few references. I can move this sentence. Where in the document would you like to see it moved to? > Using line numbers from > http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-13.txt Using line number is a text editor counts the page headers. What tool are you using? I didn't see anything on tools.ietf.org. So I'll guess. Looks like add 10 lines per page. > Line 112 > s/SHOULD/should s/keywords, SHOULD be interpreted/keywords SHOULD be interpreted/ Also remove stray comma. > Line 118 > s/MAY/may s/deployment MAY choose to/deployment may choose to/ OK. Could go either way but s/MAY chose to/MAY/ would work too. > Line 149, match intro: > s/Advanced Multipath meets/Advanced Multipath is a formalization of > multipath techniques that meet OK. > Lines 251-254, beginning with "The" through the end of the paragraph. > This should be an FR. Looks like you mean this: The transient period between some service disrupting event and the convergence of the routing and/or signaling protocols MUST occur within a time frame specified by Performance Objective values. OK. I'll add this as FR#6++. > That's it, > Lou There are a few suggestions for changes to the text based on your comments and a few questions for you. Based on your response to this email I will edit the document. Thanks for the thorough review. Curtis - --rBI3apOu079413.1387337811/maildrop2.v6ds.occnc.com-- ------- End of Forwarded Message From lberger@labn.net Mon Jan 6 15:12:09 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441E31AE2CF for ; Mon, 6 Jan 2014 15:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpz2E6_1rn8j for ; Mon, 6 Jan 2014 15:12:05 -0800 (PST) Received: from alt-proxy16.mail.unifiedlayer.com (alt-proxy16.mail.unifiedlayer.com [70.40.197.35]) by ietfa.amsl.com (Postfix) with SMTP id DF00A1AD8CD for ; Mon, 6 Jan 2014 15:12:04 -0800 (PST) Received: (qmail 30705 invoked by uid 0); 6 Jan 2014 23:11:56 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy4.mail.unifiedlayer.com with SMTP; 6 Jan 2014 23:11:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=XwscWDznVk6EzQ41dBssbWS2FoBmGYgS3pcQchoE0hM=; b=ZI9wA5pmh++NWAs5vUT9Rmv/DdQ4mDpLXI0vZuxugSiTT/+Y32LEN/jnrlMf8vffPVlJrNFrGwtApHbxdwpNwO/MjXzdcmw3jwkxrwHG39Y3KGA4T8h/3kju9+Bi27rm; Received: from box313.bluehost.com ([69.89.31.113]:46664 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1W0JKu-0006hj-3I; Mon, 06 Jan 2014 16:11:56 -0700 Message-ID: <52CB3839.6020704@labn.net> Date: Mon, 06 Jan 2014 18:11:53 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com Subject: Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 References: <201401061700.s06H00HS011318@maildrop2.v6ds.occnc.com> In-Reply-To: <201401061700.s06H00HS011318@maildrop2.v6ds.occnc.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, "rtg-ads@tools.ietf.org" , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 23:12:09 -0000 Hi Curtis, Thanks for the response. See below On 1/6/2014 12:00 PM, Curtis Villamizar wrote: > Lou et al, > > Resending. I'm not sure if the original (sent Tue, 17 Dec 2013) went > through to all recipients. There may have been a problem (due to a > self inflicted DNS issue). > > I did not get a response so I suspect Lou didn't get this email. > > Curtis > > > In message <52A8B5AB.4040708@labn.net> > Lou Berger writes: >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft. >> The Routing Directorate seeks to review all routing or routing-related >> drafts as they pass through IETF last call and IESG review. The purpose >> of the review is to provide assistance to the Routing ADs. For more >> information about the Routing Directorate, please see >> http://www.ietf.org/iesg/directorate/routing.html >> >> Although these comments are primarily for the use of the Routing ADs, it >> would be helpful if you could consider them along with any other IETF >> Last Call comments that you receive, and strive to resolve them through >> discussion or by updating the draft. >> >> Document: draft-ietf-rtgwg-cl-requirement-13.txt >> Reviewer: Lou Berger >> Review Date: 2013-12-11 >> IETF LC End Date: 2013-12-09 >> Intended Status: Informational >> >> Summary: >> >> I have some minor concerns about this document that I think >> should be resolved before publication. >> >> Comments: >> >> I think the document is greatly improved since the previous last >> call. I have some comments and reservations on the document that are >> described below. As discussed on the list, I remain concerned about the >> value of defining requirements in terms of nebulous "Performance >> Objectives", but as this is acceptable to the WG I will not elaborate on >> this concern further. >> >> Major Issues: >> >> No major issues found. >> >> Minor Issues: >> >> 1. Terminology & consistency: the document coins the term "Advanced >> Multipath": >> Advanced Multipath is a formalization of multipath techniques >> >> Do you see this term as a new noun, like LSP, or as an adjective? I >> expected the latter, i.e. that it be used like "multipath" is used in >> the above sentence, but it seems to be used as a new noun. I'm not sure >> coining a new noun really makes sense, but if this the intent then the >> last paragraph of section 2 needs to be revised as "Advanced Multipath" >> will now have a specific definition as opposed to a generic term. Also I >> suggest always capitalizing it (or even using the abbreviation "AM") >> will clarify this distinction. > > I see multipath as a noun and therefore advanced multipath as a noun. > Advanced is an adjective, multipath as a noun. Advanced Multipath is > the set of techniques that form a solution. An advanced multipath is > a collection of componet links. The former is capitalized, the latter > is not. I'll check to see if I got that right in all occurances. If > you would like I can also add this to the definition making it: > > OLD > > Advanced Multipath > Advanced Multipath meets the requirements defined in this > document. A key capability of advanced multipath is the support > of non-homogeneous component links. > > NEW > > Advanced Multipath > Advanced Multipath is a formalization of multipath techniques > that meets the requirements defined in this document. A key > capability of Advanced Multipath is the support of > non-homogeneous component links. Okay. Then I suggest using "AM" will help delineate this usage. > An "advanced multipath" is a > collection of component links. In this document the former is > capitalized and the latter is not. > > If we agree on this I'll just search for "advanced" and make > capitalization consistent with the above statements. the distinction based on capitalization seems likely to introduce confusion in this document and in future uses, so I think it is a really bad idea. > > I don't think the phrase "advanced multipath technique" makes it an > adjective any more than a statement such as make-before-break is an > MPLS technique" makes MPLS an adjective in normal use. The phrase "an > X technique" is simply a shorthand for indicating a "technique > applicable to X". Even if that makes it an adjective the phrase "MPLS > technique" is common and so that should not be a problem. The > paragraph in question might be the following. It seems benign to me. > > The term Advanced Multipath is intended to be used within the context > of this document and the related documents, > [I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and > any other related document. Other advanced multipath techniques may > in the future arise. If the capabilities defined in this document > become commonplace, they would no longer be considered "advanced". > Use of the term "advanced multipath" outside this document, if > referring to the term as defined here, should indicate Advanced > Multipath as defined by this document, citing the current document > name. If using another definition of "advanced multipath", documents > may optionally clarify that they are not using the term "advanced > multipath" as defined by this document if clarification is deemed > helpful. > > I see no problem with this. Please be more specific if you think > there are places where advanced multipath is used as an adjective or > where its use is confusing. > I believe my confusion was not understanding the differences between "Advanced Multipath" (with words capitalized) and "advanced multipath" (with words lower cased). While I understand this is your intent, I see it as just leading to confusion. Ultimately, it's the author's / WG's call, i.e., not mine, to make. >> 2. Editorial: server and client layer vs upper and lower layer. >> >> The document uses server and client layer networks and LSPs and, >> sometimes interchangeably or redundantly, upper and lower layer networks >> and LSPs. I think this issue can be resolved by avoiding the term >> client/server when referring to network layers and just using the >> lower/upper terminology. The one exception to this is in the definition >> Client LSP which should simply be defined in the context of a multipath, >> i.e.: >> OLD >> A client LSP is an LSP which has been set up over a server layer. >> NEW >> A client LSP is an LSP which has been set up over Advanced Multipath. > > A client LSP can be set up over a server layer MPLS-TP LSP or any > server layer MPLS LSP or over a link layer or over a pseudowire ... or > over an advanced multipath. > Would you accept s/server layer/lower layer/g? >> I think this also means that usage of the term "Client" is limited to >> "Client LSP". > > I searched for all occurances of the word client. All occurances are > "client LSP" excexpt the phrase "client of a client LSP" and that is > used only in the following paragraph. > > The ingress and egress of a multipath may be midpoint LSRs with > respect to a given client LSP. A midpoint LSR does not participate > in the signaling of any clients of the client LSP. Therefore, in > general, multipath endpoints cannot determine requirements of clients > of a client LSP through participation in the signaling of the clients > of the client LSP. > > THe point is that "A midpoint LSR does not participate in the > signaling of any clients of the client LSP" and that non-participation > in client (or higher layer) signaling applies to any "client of a > client LSP", not just other LSP running over it. > > I then searched for all occurances of the words upper and lower and > higher. There are no occurances of "upper". > > There were a few occurances of "lower latency" and "higher latency". > Other than that, all occurances of lower and higher except one are in > the follwoing text: > > 3.2. Component Links Provided by Lower Layer Networks > > A component link may be supported by a lower layer network. For > example, the lower layer may be a circuit switched network or another > MPLS network (e.g., MPLS-TP)). The lower layer network may change > the latency (and/or other performance parameters) seen by the client > layer. Currently, there is no protocol for the lower layer network > to inform the higher layer network of a change in a performance > parameter. Communication of the latency performance parameter is a > very important requirement. Communication of other performance > parameters (e.g., delay variation) is desirable. > > FR#8 The solution SHALL specify a protocol means to allow a lower > layer server network to communicate latency to the higher layer > client network. > > The exception is this sentence: > > FR#22 The solution SHOULD support the use case where an advanced > multipath itself is a component link for a higher order advanced > multipath. For example, an advanced multipath comprised of MPLS- > TP bi-directional tunnels viewed as logical links could then be > used as a component link in yet another advanced multipath that > connects MPLS routers. > > The terms lower layer and higher layer go all the way back to the ISO > seven layer model of ancient times (1970s?, 1980s?) and maybe further > back but that is before even my time. > > I don't think this is unclear but I could add the following in > definitions: > > Higher Layers > A client layer is the one immediately above a server layer. The > client layer and all layers above that layer are higher layers. > > Lower Layers > A server layer is the later immediately below a client laer. > The server layer and all layers below are lower layers. > > Do I really need to put this in the definitions section? If yoy think > it is necessary, I will add it. > Perhaps we've talked (okay written) past each other. I was suggesting using/keeping the "higher and lower layer" terminology, not dropping it. And to use it (consistently) in place of "client and server Layer". >> 3. Technical: The document should make it clear that LSPs can provide >> paths from an Advanced Multipath. I suggest adding something like the >> the following at the end of page 3 >> d. a lower layer LSP. > > Case "b." is intended to include LSP but is not specifically limited > to LSP. Multipath (not Advanced Multipath) includes IGP ECMP, > Ethernet Link Aggregation, and all sorts of things that don't involve > MPLS at all. For example, a path in Ethernet Link Aggregation Group > (LAG) could be supported by a pseudowires or ODU2e or GFP-F, though > this would be unknown to the LAG, or in the simplest case each path in > the set of LAG members could be supported by a plain Ethernet cable. > okay, how about: OLD b. may be specific paths across a network to a destination node, or NEW b. specific paths across a network to a destination node (e.g., via an LSP), or >> and at the end of the Component Link definition: >> A component link may be provided via an LSP. > > I think this is covered in "3.2. Component Links Provided by Lower > Layer Networks". > > 3.2. Component Links Provided by Lower Layer Networks > > A component link may be supported by a lower layer network. For > example, the lower layer may be a circuit switched network or another > MPLS network (e.g., MPLS-TP)). > > This sort of statement could be made earlier. For example in the > discussion following the definitions (on page 5) the document covers > one case (where a component link is not an LSP) but it is not until > later that the other case is mentioned. > > I could add a paragraph in the discussion following the definitions > that mentions that a component link can also be another LSP. > > OLD: > > A Component Link may be a point-to-point physical link (where a > "physical link" includes one or more link layer plus a physical > layer) or a logical link that preserves ordering in the steady state. > A component link may have transient out of order events, but such > events must not exceed the network's Performance Objectives. For > example, a component link may be comprised of any supportable > combination of link layers over a physical layer or over logical sub- > layers, including those providing physical layer emulation. > > NEW: > > A Component Link may be a point-to-point physical link (where a > "physical link" includes one or more link layer plus a physical > layer) or a logical link that preserves ordering in the steady state. > A component link may have transient out of order events, but such > events must not exceed the network's Performance Objectives. For > example, a component link may be comprised of any supportable > combination of link layers over a physical layer or over logical sub- > layers, including those providing physical layer emulation, or over > MPLS server layer LSP. > > These are identical except the phrase ", or over MPLS server layer > LSP" added to the end of the last sentence. Sure. > >> 4. Editorial: Unless I'm mistaken, the requirements in this document >> apply to the Advanced Multipath solution. In most cases the document >> states requirements in the form of "The solution", but in a few cases it >> just says "advanced multipath". I think these cases should be changed >> to apply to an "Advanced Multipath solution". I think this comment >> applies to FR1, FR7, FR18, FR23, GR3-5, and MR1-9. > > That is not correct. For example: > > FR#1 An advanced multipath MAY be announced in conjunction with > detailed parameters about its component links, such as bandwidth > and latency. The advanced multipath SHALL behave as a single IGP > adjacency. > > In this requirement the "advanced multipath" is a specific collection > of component links that is announced by way of an MPLS Forwarding > Adjaccency (FA) in the IGP. The same is true for the other > requirements cited. In all of these cases an advanced multipath is a > specific collection of component links. Hereto, the distinction between "advanced multipath" and "Advanced Multipath" was lost on me. > There is a typo in MR#1. > > OLD > > MR#1 Management Plane MUST support polling of the status and > configuration of an advanced multipath and its individual > advanced multipath and support notification of status change. > > NEW > > MR#1 Management Plane MUST support polling of the status and > configuration of an advanced multipath and its individual > component links and support notification of status change. > > In the last line > s/advanced multipath/component links/ > >> 5. Technical: use of "indicate" in FR10-13, FR14, FR15: >> In these cases it is unclear if the requirements apply to >> (a) a client's ability to indicate a desired service/LSP constraint or >> (b) a selected component link's attribute that will be used by a client >> LSP, >> (c) both, or >> (d) something completely different >> The requirements should be clear to which entity the requirement applies. > > This "indication" can be through signaling or the management plane and > both must be supported in later framework and protocol definitions and > we can argue then whether both must be supported or if one or the > other is a "should" in RFC 2119 speak. > > There was concern that the word "signal" would exclude providing the > same informantion through the management plane and therefore the word > "indicate" is used. > > Rather than spell this out many times we hoped this would be clear. I > could add clarifying text up front if you think this is necessary. For > example, I could add the following before FR#1. > > FR#0 In requirements that follow in this document the word > "indicate" is used where information may be provided by either > the combination of link state IGP advertisement and MPLS LSP > signaling or via management plane protocols. In later documents > providing framework and protocol definitions both signaling and > management plane mechanisms MUST be defined. > So is this the IGP/signaling that runs between a client an an AM "LER", between an AM "LSR" and its server network, or between AM LSRs? If I understand AM properly, there may be *up to* there separate instances. Am I missing something? > It would be trivial to make this FR#1 and renumber the rest. > I don't think the FR helped clarify the above question. > Should I add it and renumber? > >> 6. The last paragraph in section 3.3. strikes me as both odd and out of >> place. There are so many possible decisions that must be considered by >> network operators relative to disruption and optimization. Why mention >> just "power reduction"? Is there something special about the >> interactions of multipath and power reduction? What value / information >> does this paragraph add? > > The last paragraph in section 3.3 is: > > Allowing multipath to contain component links with different > characteristics can improve the overall load balance and can be > accomplished while still accommodating the more strict requirements > of a subset of client LSP. > > I'm not sure if this is the "odd and out of place" paragraph you refer > to. It summarizes the purpose of the requirements in this section. I > think you mean section 3.5 and not 3.3. > Correct. > The remainder of your paragraph above discusses power reducetion and > this is only mentioned in section 3.5 so I think you mean this > paragraph. > Right again. > As with any load balancing change, a change initiated for the purpose > of power reduction may be minimally disruptive. Typically the > disruption is limited to a change in delay characteristics and the > potential for a very brief period with traffic reordering. The > network operator when configuring a network for power reduction > should weigh the benefit of power reduction against the disadvantage > of a minimal disruption. > > The paragraphs following a set of requirements provide discussion > related to that set of requirements. I don't see this as out of > place. The prior two paragraphs discuss delay discontinuity. This > paragraph is a reminder that "As with any load balancing change, a > change initiated for the purpose of power reduction may be minimally > disruptive." I don't see this as out of place. > > For example, to compensate for a less than perfect load balance a > subset of LSPs may need to be moved and that subset can be chosen from > those which will be least affected (and there are plenty of > requirements that compell the fussy LSP to tell the network abour > their specifial needs). To power down a component link, *all* LSP on > that component link need to be moved, even the very fussy ones. > Therefore I think mentioning that disruption should be considered is > not out of place in the discussion following these requirements. We > like to keep the discussion brief so this level of detail was not > included. > I guess we see the importance of this topic differently. So will this be the first RFC that uses the term "power reduction"? >> 7. Terminology: In GR4&5: what is a "MPLS network topology"? Do you mean AS? > > At the very least it means something similar to same administrative > domain. An AS can be subdivided within an organization. Do you have > a better way to define intra-domain and inter-domain without going > down the rat hole of defining the term "domain"? I'd use something like "multiple ASes or routing domains". If you really want to avoid domains you could say areas or levels. > No on in the WG had > an issue with this so far but I'm open for a suggestion for better > wording. You're forgetting my "real" name;-) >> Nits: >> >> - References should be provided in all cases when referring to >> "existing ... techniques" > > References are not allowed in the abstract. In section 3.3 is the sentence: > > Refer to the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a > description of existing techniques and a set of references. > > Much of that document is dedicated to describing existing techniques > and it contains quite a few references. > > I can move this sentence. Where in the document would you like to see > it moved to? > (Lines numbers from URL below.) Lines 200/201 and 278 have this issue. Lines 297 and 342 do not. >> Using line numbers from >> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-13.txt > > Using line number is a text editor counts the page headers. What tool > are you using? I didn't see anything on tools.ietf.org. > huh. enter the above URL in a browser and you should see the line numbers. > So I'll guess. Looks like add 10 lines per page. > >> Line 112 >> s/SHOULD/should > > s/keywords, SHOULD be interpreted/keywords SHOULD be interpreted/ > > Also remove stray comma. > I don't think use of 2119 language being applied to the reader is appropriate, but whatever... >> Line 118 >> s/MAY/may > > s/deployment MAY choose to/deployment may choose to/ > > OK. Could go either way but s/MAY chose to/MAY/ would work too. > No. The issue is that this document doesn't place conformance requirements on a service provider so RFC2119 language isn't appropriate here. >> Line 149, match intro: >> s/Advanced Multipath meets/Advanced Multipath is a formalization of >> multipath techniques that meet > > OK. > >> Lines 251-254, beginning with "The" through the end of the paragraph. >> This should be an FR. > > Looks like you mean this: > > The transient period between some service disrupting > event and the convergence of the routing and/or signaling protocols > MUST occur within a time frame specified by Performance Objective > values. > Right. > OK. I'll add this as FR#6++. > >> That's it, >> Lou > > There are a few suggestions for changes to the text based on your > comments and a few questions for you. Based on your response to this > email I will edit the document. > > Thanks for the thorough review. > Thanks for the responses and the resend! Lou > Curtis > > - --rBI3apOu079413.1387337811/maildrop2.v6ds.occnc.com-- > > > ------- End of Forwarded Message > > > > From curtis@ipv6.occnc.com Tue Jan 7 18:56:47 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DAA1AE29D; Tue, 7 Jan 2014 18:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNFgBNWN4llF; Tue, 7 Jan 2014 18:56:41 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 08DF41AE2A7; Tue, 7 Jan 2014 18:56:40 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s082uTjw038207; Tue, 7 Jan 2014 21:56:29 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401080256.s082uTjw038207@maildrop2.v6ds.occnc.com> To: Lou Berger From: Curtis Villamizar Subject: Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 In-reply-to: Your message of "Mon, 06 Jan 2014 18:11:53 -0500." <52CB3839.6020704@labn.net> Date: Tue, 07 Jan 2014 21:56:29 -0500 Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, rtgwg@ietf.org, "rtg-ads@tools.ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 02:56:47 -0000 In message <52CB3839.6020704@labn.net> Lou Berger writes: > > Hi Curtis, > Thanks for the response. See below You pointed out a a few things you thought should be changed but left it open for me to propose how to change things, so we'll need at least one more iteration after this. > On 1/6/2014 12:00 PM, Curtis Villamizar wrote: > > Lou et al, > > > > Resending. I'm not sure if the original (sent Tue, 17 Dec 2013) went > > through to all recipients. There may have been a problem (due to a > > self inflicted DNS issue). > > > > I did not get a response so I suspect Lou didn't get this email. > > > > Curtis FYI - most recent issue I found was an error in IN TXT v=spf1 line. It might be a bad time to be experimenting with IPv6 transition technologies and their effects of email. :-( Go back to plain old dual stack and burn another IPv4 global? Might be the right move. Hopefully mail will get through to everyone now without a resend. If I have to resend I'll put the IPv6 mail server back into the DS subnet before resending. Curtis > > In message <52A8B5AB.4040708@labn.net> > > Lou Berger writes: > >> > >> Hello, > >> > >> I have been selected as the Routing Directorate reviewer for this draft. > >> The Routing Directorate seeks to review all routing or routing-related > >> drafts as they pass through IETF last call and IESG review. The purpose > >> of the review is to provide assistance to the Routing ADs. For more > >> information about the Routing Directorate, please see > >> http://www.ietf.org/iesg/directorate/routing.html > >> > >> Although these comments are primarily for the use of the Routing ADs, it > >> would be helpful if you could consider them along with any other IETF > >> Last Call comments that you receive, and strive to resolve them through > >> discussion or by updating the draft. > >> > >> Document: draft-ietf-rtgwg-cl-requirement-13.txt > >> Reviewer: Lou Berger > >> Review Date: 2013-12-11 > >> IETF LC End Date: 2013-12-09 > >> Intended Status: Informational > >> > >> Summary: > >> > >> I have some minor concerns about this document that I think > >> should be resolved before publication. > >> > >> Comments: > >> > >> I think the document is greatly improved since the previous last > >> call. I have some comments and reservations on the document that are > >> described below. As discussed on the list, I remain concerned about the > >> value of defining requirements in terms of nebulous "Performance > >> Objectives", but as this is acceptable to the WG I will not elaborate on > >> this concern further. > >> > >> Major Issues: > >> > >> No major issues found. > >> > >> Minor Issues: > >> > >> 1. Terminology & consistency: the document coins the term "Advanced > >> Multipath": > >> Advanced Multipath is a formalization of multipath techniques > >> > >> Do you see this term as a new noun, like LSP, or as an adjective? I > >> expected the latter, i.e. that it be used like "multipath" is used in > >> the above sentence, but it seems to be used as a new noun. I'm not sure > >> coining a new noun really makes sense, but if this the intent then the > >> last paragraph of section 2 needs to be revised as "Advanced Multipath" > >> will now have a specific definition as opposed to a generic term. Also I > >> suggest always capitalizing it (or even using the abbreviation "AM") > >> will clarify this distinction. > > > > I see multipath as a noun and therefore advanced multipath as a noun. > > Advanced is an adjective, multipath as a noun. Advanced Multipath is > > the set of techniques that form a solution. An advanced multipath is > > a collection of componet links. The former is capitalized, the latter > > is not. I'll check to see if I got that right in all occurances. If > > you would like I can also add this to the definition making it: > > > > OLD > > > > Advanced Multipath > > Advanced Multipath meets the requirements defined in this > > document. A key capability of advanced multipath is the support > > of non-homogeneous component links. > > > > NEW > > > > Advanced Multipath > > Advanced Multipath is a formalization of multipath techniques > > that meets the requirements defined in this document. A key > > capability of Advanced Multipath is the support of > > non-homogeneous component links. > > Okay. Then I suggest using "AM" will help delineate this usage. Later you indicate you prefer we don't use the same term. Suggestion follows that. > > An "advanced multipath" is a > > collection of component links. In this document the former is > > capitalized and the latter is not. > > > > If we agree on this I'll just search for "advanced" and make > > capitalization consistent with the above statements. > > the distinction based on capitalization seems likely to introduce > confusion in this document and in future uses, so I think it is a really > bad idea. Clarity is good. If it lacks clarity we'll have to fix it. > > I don't think the phrase "advanced multipath technique" makes it an > > adjective any more than a statement such as make-before-break is an > > MPLS technique" makes MPLS an adjective in normal use. The phrase "an > > X technique" is simply a shorthand for indicating a "technique > > applicable to X". Even if that makes it an adjective the phrase "MPLS > > technique" is common and so that should not be a problem. The > > paragraph in question might be the following. It seems benign to me. > > > > The term Advanced Multipath is intended to be used within the context > > of this document and the related documents, > > [I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and > > any other related document. Other advanced multipath techniques may > > in the future arise. If the capabilities defined in this document > > become commonplace, they would no longer be considered "advanced". > > Use of the term "advanced multipath" outside this document, if > > referring to the term as defined here, should indicate Advanced > > Multipath as defined by this document, citing the current document > > name. If using another definition of "advanced multipath", documents > > may optionally clarify that they are not using the term "advanced > > multipath" as defined by this document if clarification is deemed > > helpful. > > > > I see no problem with this. Please be more specific if you think > > there are places where advanced multipath is used as an adjective or > > where its use is confusing. > > > > I believe my confusion was not understanding the differences between > "Advanced Multipath" (with words capitalized) and "advanced multipath" > (with words lower cased). While I understand this is your intent, I see > it as just leading to confusion. Ultimately, it's the author's / WG's > call, i.e., not mine, to make. OK so here is a suggestion to improve this. OLD Advanced Multipath Advanced Multipath meets the requirements defined in this document. A key capability of advanced multipath is the support of non-homogeneous component links. OLD NEW Advanced Multipath Advanced Multipath is a formalization of multipath techniques that meets the requirements defined in this document. A key capability of Advanced Multipath is the support of non-homogeneous component links. NEWER Advanced Multipath Advanced Multipath is a formalization of multipath techniques that meets the requirements defined in this document. A key capability of Advanced Multipath is the support of non-homogeneous component links. Advanced Multipath Group (AMG) An Advanced Multipath Group (AMG) is group of component links where Advanced Multipath techniques are applied. This along the lines of "Link Aggregation" and LAG. The first is 802.1ax (or whatever, see the references). The latter is a group of component links. Not to be confused with Absorbed Glass Mat lead-acid batteries... (which is AGM not AMG). But if you see me write AGM, you'll know why (habit, typo). I think if we use these definitions and make if this terminology change is made everywhere in the document we will acheive the improved clarity that you were looking for. Is this OK? > >> 2. Editorial: server and client layer vs upper and lower layer. > >> > >> The document uses server and client layer networks and LSPs and, > >> sometimes interchangeably or redundantly, upper and lower layer networks > >> and LSPs. I think this issue can be resolved by avoiding the term > >> client/server when referring to network layers and just using the > >> lower/upper terminology. The one exception to this is in the definition > >> Client LSP which should simply be defined in the context of a multipath, > >> i.e.: > >> OLD > >> A client LSP is an LSP which has been set up over a server layer. > >> NEW > >> A client LSP is an LSP which has been set up over Advanced Multipath. > > > > A client LSP can be set up over a server layer MPLS-TP LSP or any > > server layer MPLS LSP or over a link layer or over a pseudowire ... or > > over an advanced multipath. > > > > Would you accept s/server layer/lower layer/g? The definition of server layer is not the same as the definition of lower layer. See below. > >> I think this also means that usage of the term "Client" is limited to > >> "Client LSP". > > > > I searched for all occurances of the word client. All occurances are > > "client LSP" excexpt the phrase "client of a client LSP" and that is > > used only in the following paragraph. > > > > The ingress and egress of a multipath may be midpoint LSRs with > > respect to a given client LSP. A midpoint LSR does not participate > > in the signaling of any clients of the client LSP. Therefore, in > > general, multipath endpoints cannot determine requirements of clients > > of a client LSP through participation in the signaling of the clients > > of the client LSP. > > > > THe point is that "A midpoint LSR does not participate in the > > signaling of any clients of the client LSP" and that non-participation > > in client (or higher layer) signaling applies to any "client of a > > client LSP", not just other LSP running over it. > > > > I then searched for all occurances of the words upper and lower and > > higher. There are no occurances of "upper". > > > > There were a few occurances of "lower latency" and "higher latency". > > Other than that, all occurances of lower and higher except one are in > > the follwoing text: > > > > 3.2. Component Links Provided by Lower Layer Networks > > > > A component link may be supported by a lower layer network. For > > example, the lower layer may be a circuit switched network or another > > MPLS network (e.g., MPLS-TP)). The lower layer network may change > > the latency (and/or other performance parameters) seen by the client > > layer. Currently, there is no protocol for the lower layer network > > to inform the higher layer network of a change in a performance > > parameter. Communication of the latency performance parameter is a > > very important requirement. Communication of other performance > > parameters (e.g., delay variation) is desirable. > > > > FR#8 The solution SHALL specify a protocol means to allow a lower > > layer server network to communicate latency to the higher layer > > client network. > > > > The exception is this sentence: > > > > FR#22 The solution SHOULD support the use case where an advanced > > multipath itself is a component link for a higher order advanced > > multipath. For example, an advanced multipath comprised of MPLS- > > TP bi-directional tunnels viewed as logical links could then be > > used as a component link in yet another advanced multipath that > > connects MPLS routers. > > > > The terms lower layer and higher layer go all the way back to the ISO > > seven layer model of ancient times (1970s?, 1980s?) and maybe further > > back but that is before even my time. > > > > I don't think this is unclear but I could add the following in > > definitions: > > > > Higher Layers > > A client layer is the one immediately above a server layer. The > > client layer and all layers above that layer are higher layers. > > > > Lower Layers > > A server layer is the later immediately below a client laer. > > The server layer and all layers below are lower layers. > > > > Do I really need to put this in the definitions section? If yoy think > > it is necessary, I will add it. > > > Perhaps we've talked (okay written) past each other. I was suggesting > using/keeping the "higher and lower layer" terminology, not dropping it. > And to use it (consistently) in place of "client and server Layer". I guess you missed the distinction in the definition above: For layer X layer Y is: client layer === Y = X+1 server layer === Y = X-1 higher layer === Y > X lower layer === Y < X So the definition client layer is not the same as the definition of higher layer. The definition of server layer is not the same as the definition of lower layer. In some discussions we really do mean "the server layer" and not any layer at any arbitrary depth below this one. > >> 3. Technical: The document should make it clear that LSPs can provide > >> paths from an Advanced Multipath. I suggest adding something like the > >> the following at the end of page 3 > >> d. a lower layer LSP. > > > > Case "b." is intended to include LSP but is not specifically limited > > to LSP. Multipath (not Advanced Multipath) includes IGP ECMP, > > Ethernet Link Aggregation, and all sorts of things that don't involve > > MPLS at all. For example, a path in Ethernet Link Aggregation Group > > (LAG) could be supported by a pseudowires or ODU2e or GFP-F, though > > this would be unknown to the LAG, or in the simplest case each path in > > the set of LAG members could be supported by a plain Ethernet cable. > > > > okay, how about: > OLD > b. may be specific paths across a network to a destination > node, or > NEW > b. specific paths across a network to a destination > node (e.g., via an LSP), or OK. But I like to spell out "for example" and put it after the definition. That would give us: 4. The paths may be: a. parallel links between two nodes, or b. may be specific paths across a network to a destination node, or c. may be links or paths to an intermediate node used to reach a common destination. The paths need not have equal capacity. The paths may or may not have equal cost in a routing protocol. + Paths across a network which serve as a component link in a AMG + may be provided by other LSP acting as server LSP for the + client AMG. Component links of a given AMG need not all use the + same type of server layer technology. For example, one may be a + physical Ethernet, another a Packet Over Sonet (POS) link, + another a pseudowire, and another an LSP with individual hops + using a mix of lower layer technologies. Is that an acceptable clarification? btw - in b. and c. s/may be// since "may be" precedes the list. > >> and at the end of the Component Link definition: > >> A component link may be provided via an LSP. > > > > I think this is covered in "3.2. Component Links Provided by Lower > > Layer Networks". > > > > 3.2. Component Links Provided by Lower Layer Networks > > > > A component link may be supported by a lower layer network. For > > example, the lower layer may be a circuit switched network or another > > MPLS network (e.g., MPLS-TP)). > > > > This sort of statement could be made earlier. For example in the > > discussion following the definitions (on page 5) the document covers > > one case (where a component link is not an LSP) but it is not until > > later that the other case is mentioned. > > > > I could add a paragraph in the discussion following the definitions > > that mentions that a component link can also be another LSP. > > > > OLD: > > > > A Component Link may be a point-to-point physical link (where a > > "physical link" includes one or more link layer plus a physical > > layer) or a logical link that preserves ordering in the steady state. > > A component link may have transient out of order events, but such > > events must not exceed the network's Performance Objectives. For > > example, a component link may be comprised of any supportable > > combination of link layers over a physical layer or over logical sub- > > layers, including those providing physical layer emulation. > > > > NEW: > > > > A Component Link may be a point-to-point physical link (where a > > "physical link" includes one or more link layer plus a physical > > layer) or a logical link that preserves ordering in the steady state. > > A component link may have transient out of order events, but such > > events must not exceed the network's Performance Objectives. For > > example, a component link may be comprised of any supportable > > combination of link layers over a physical layer or over logical sub- > > layers, including those providing physical layer emulation, or over > > MPLS server layer LSP. > > > > These are identical except the phrase ", or over MPLS server layer > > LSP" added to the end of the last sentence. > > Sure. > > > > >> 4. Editorial: Unless I'm mistaken, the requirements in this document > >> apply to the Advanced Multipath solution. In most cases the document > >> states requirements in the form of "The solution", but in a few cases it > >> just says "advanced multipath". I think these cases should be changed > >> to apply to an "Advanced Multipath solution". I think this comment > >> applies to FR1, FR7, FR18, FR23, GR3-5, and MR1-9. > > > > That is not correct. For example: > > > > FR#1 An advanced multipath MAY be announced in conjunction with > > detailed parameters about its component links, such as bandwidth > > and latency. The advanced multipath SHALL behave as a single IGP > > adjacency. > > > > In this requirement the "advanced multipath" is a specific collection > > of component links that is announced by way of an MPLS Forwarding > > Adjaccency (FA) in the IGP. The same is true for the other > > requirements cited. In all of these cases an advanced multipath is a > > specific collection of component links. > > Hereto, the distinction between "advanced multipath" and "Advanced > Multipath" was lost on me. OK. "Advanced Multipath" vs AMG might improve clarity. > > There is a typo in MR#1. > > > > OLD > > > > MR#1 Management Plane MUST support polling of the status and > > configuration of an advanced multipath and its individual > > advanced multipath and support notification of status change. > > > > NEW > > > > MR#1 Management Plane MUST support polling of the status and > > configuration of an advanced multipath and its individual > > component links and support notification of status change. > > > > In the last line > > s/advanced multipath/component links/ > > > >> 5. Technical: use of "indicate" in FR10-13, FR14, FR15: > >> In these cases it is unclear if the requirements apply to > >> (a) a client's ability to indicate a desired service/LSP constraint or > >> (b) a selected component link's attribute that will be used by a client > >> LSP, > >> (c) both, or > >> (d) something completely different > >> The requirements should be clear to which entity the requirement applies. > > > > This "indication" can be through signaling or the management plane and > > both must be supported in later framework and protocol definitions and > > we can argue then whether both must be supported or if one or the > > other is a "should" in RFC 2119 speak. > > > > There was concern that the word "signal" would exclude providing the > > same informantion through the management plane and therefore the word > > "indicate" is used. > > > > Rather than spell this out many times we hoped this would be clear. I > > could add clarifying text up front if you think this is necessary. For > > example, I could add the following before FR#1. > > > > FR#0 In requirements that follow in this document the word > > "indicate" is used where information may be provided by either > > the combination of link state IGP advertisement and MPLS LSP > > signaling or via management plane protocols. In later documents > > providing framework and protocol definitions both signaling and > > management plane mechanisms MUST be defined. > > > > So is this the IGP/signaling that runs between a client an an AM "LER", > between an AM "LSR" and its server network, or between AM LSRs? If I > understand AM properly, there may be *up to* there separate instances. > Am I missing something? Please don't abbreviate Advanced Multipath as AM. Link Aggregation is not LA. The word "indicate" is independent of the method of getting the information there. But yes in the example given the IGP advertisement and MPLS LSP signaling that might be one such mechanism does refer to the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there is only one IGP flooding information for both client and server layer, hence the seemingly endless (and mostly pointless) discussion of sub-layer vs layer from certain ITU people in the MPLS WG mailing list who viewed MPLS as broken for not enforcing a strict layering in this regard. But we need not go into that level of detail in this example of how independent of mechanism the "indicate" is and down that years old MPLS WG terminology rat hole again. > > It would be trivial to make this FR#1 and renumber the rest. > > > > I don't think the FR helped clarify the above question. The choice of the word "indicate" in FR10-13, FR14, FR15 does not imply usage by a specific layer. That is a direct answer to your question. In all of these specific cases, the the client layer is passing a requirement to the server layer so in the IGP + RSVP-TE world that would be a function of RSVP-TE. In the absense of control plane, it would have to be done through management plane interaction where the client indicates requirements of an LSP and the server layer is free to figure out how to meet those requirements. Do you want me to add the clarification on the use of the word "indicate" or not? > > Should I add it and renumber? > > > >> 6. The last paragraph in section 3.3. strikes me as both odd and out of > >> place. There are so many possible decisions that must be considered by > >> network operators relative to disruption and optimization. Why mention > >> just "power reduction"? Is there something special about the > >> interactions of multipath and power reduction? What value / information > >> does this paragraph add? > > > > The last paragraph in section 3.3 is: > > > > Allowing multipath to contain component links with different > > characteristics can improve the overall load balance and can be > > accomplished while still accommodating the more strict requirements > > of a subset of client LSP. > > > > I'm not sure if this is the "odd and out of place" paragraph you refer > > to. It summarizes the purpose of the requirements in this section. I > > think you mean section 3.5 and not 3.3. > > > > Correct. > > > The remainder of your paragraph above discusses power reducetion and > > this is only mentioned in section 3.5 so I think you mean this > > paragraph. > > > Right again. > > > As with any load balancing change, a change initiated for the purpose > > of power reduction may be minimally disruptive. Typically the > > disruption is limited to a change in delay characteristics and the > > potential for a very brief period with traffic reordering. The > > network operator when configuring a network for power reduction > > should weigh the benefit of power reduction against the disadvantage > > of a minimal disruption. > > > > The paragraphs following a set of requirements provide discussion > > related to that set of requirements. I don't see this as out of > > place. The prior two paragraphs discuss delay discontinuity. This > > paragraph is a reminder that "As with any load balancing change, a > > change initiated for the purpose of power reduction may be minimally > > disruptive." I don't see this as out of place. > > > > For example, to compensate for a less than perfect load balance a > > subset of LSPs may need to be moved and that subset can be chosen from > > those which will be least affected (and there are plenty of > > requirements that compell the fussy LSP to tell the network abour > > their specifial needs). To power down a component link, *all* LSP on > > that component link need to be moved, even the very fussy ones. > > Therefore I think mentioning that disruption should be considered is > > not out of place in the discussion following these requirements. We > > like to keep the discussion brief so this level of detail was not > > included. > > > > I guess we see the importance of this topic differently. So will this > be the first RFC that uses the term "power reduction"? Perhaps. A co-author originally wanted it added. The set of authors kicked this around and reworded the original. The wording is brief and vague and the use of MAY in the actual requirement means we will not disallow this. So far no one in the WG has objected to this wording and its been there a long time. Would you like me to remove the requirement and discussion of its implications after the WG concensus so far was to keep it? > >> 7. Terminology: In GR4&5: what is a "MPLS network topology"? Do you mean AS? > > > > At the very least it means something similar to same administrative > > domain. An AS can be subdivided within an organization. Do you have > > a better way to define intra-domain and inter-domain without going > > down the rat hole of defining the term "domain"? > > I'd use something like "multiple ASes or routing domains". If you > really want to avoid domains you could say areas or levels. OK. s/MPLS network topology/routing domain/ > > No on in the WG had > > an issue with this so far but I'm open for a suggestion for better > > wording. > > You're forgetting my "real" name;-) You plan on living up to it I see. :-) > >> Nits: > >> > >> - References should be provided in all cases when referring to > >> "existing ... techniques" > > > > References are not allowed in the abstract. In section 3.3 is the sentence: > > > > Refer to the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a > > description of existing techniques and a set of references. > > > > Much of that document is dedicated to describing existing techniques > > and it contains quite a few references. > > > > I can move this sentence. Where in the document would you like to see > > it moved to? > > > (Lines numbers from URL below.) > Lines 200/201 and 278 have this issue. Lines 297 and 342 do not. > > >> Using line numbers from > >> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-13.txt > > > > Using line number is a text editor counts the page headers. What tool > > are you using? I didn't see anything on tools.ietf.org. > > > huh. enter the above URL in a browser and you should see the line numbers. > > > So I'll guess. Looks like add 10 lines per page. > > > > >> Line 112 > >> s/SHOULD/should > > > > s/keywords, SHOULD be interpreted/keywords SHOULD be interpreted/ > > > > Also remove stray comma. > > > I don't think use of 2119 language being applied to the reader is > appropriate, but whatever... You want me to downcase "SHOULD be interpreted". I missed a M-l in the s/// edit (emacs downcase next word) and got only the stray comma. > >> Line 118 > >> s/MAY/may > > > > s/deployment MAY choose to/deployment may choose to/ > > > > OK. Could go either way but s/MAY chose to/MAY/ would work too. > > > No. The issue is that this document doesn't place conformance > requirements on a service provider so RFC2119 language isn't appropriate > here. No IETF document truly places conformance requirements on either the service provider or implementor, but we put RFC2119 language in telling them what to do all the time. No one in IETF signed a legal document forcing them to adhere to every RFC2119 keyword in each document. The requirements here are 1) implementor SHOULD provide a per feature knob to turn individual features off, 2) provider MAY use those knobs, including knobs that another implementor made available. This is just trying to avoid unnecessarily inflexible specifications or unnecessarily inflexible implementations where some feature doesn't work when an unrelated feature is disabled. This is in here because this inflexibility happens. The framework can outline any feature dependencies. > >> Line 149, match intro: > >> s/Advanced Multipath meets/Advanced Multipath is a formalization of > >> multipath techniques that meet > > > > OK. > > > >> Lines 251-254, beginning with "The" through the end of the paragraph. > >> This should be an FR. > > > > Looks like you mean this: > > > > The transient period between some service disrupting > > event and the convergence of the routing and/or signaling protocols > > MUST occur within a time frame specified by Performance Objective > > values. > > > Right. > > OK. I'll add this as FR#6++. > > > > >> That's it, > >> Lou > > > > There are a few suggestions for changes to the text based on your > > comments and a few questions for you. Based on your response to this > > email I will edit the document. > > > > Thanks for the thorough review. > > > > Thanks for the responses and the resend! > > Lou Sorry to mess up my own DNS and require a resend and a delay. Curtis > > Curtis > > > > - --rBI3apOu079413.1387337811/maildrop2.v6ds.occnc.com-- > > > > > > ------- End of Forwarded Message From lberger@labn.net Wed Jan 8 10:48:08 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617291AE0EE for ; Wed, 8 Jan 2014 10:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable 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 I6d0KbigDizK for ; Wed, 8 Jan 2014 10:48:04 -0800 (PST) Received: from alt-proxy17.mail.unifiedlayer.com (alt-proxy17.mail.unifiedlayer.com [66.147.241.60]) by ietfa.amsl.com (Postfix) with SMTP id 62FA51AE0E9 for ; Wed, 8 Jan 2014 10:48:04 -0800 (PST) Received: (qmail 9686 invoked by uid 0); 8 Jan 2014 18:47:55 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.mail.unifiedlayer.com with SMTP; 8 Jan 2014 18:47:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=4+UnfA4r4QdiT90TYGFBhpReFG2e7UezK27fBTA3lUM=; b=tA68qU/AfMKJj82KpB2WNIBP9fJ0BqzHKd/cO0QKEzC0HvWvvNpD/mchzh3q+32x5l5UKfToJn6lgd+LgzMeaICOUIYFzq2/7aoKQN4j1m6mMycXFmZxP6tRTmiGIf5u; Received: from box313.bluehost.com ([69.89.31.113]:52439 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1W0yAV-0004nS-1I; Wed, 08 Jan 2014 11:47:55 -0700 Message-ID: <52CD9D58.4010109@labn.net> Date: Wed, 08 Jan 2014 13:47:52 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com Subject: Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 References: <201401080256.s082uTjw038207@maildrop2.v6ds.occnc.com> In-Reply-To: <201401080256.s082uTjw038207@maildrop2.v6ds.occnc.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, "rtg-ads@tools.ietf.org" , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 18:48:08 -0000 Hi Curtis, See below. On 01/07/2014 09:56 PM, Curtis Villamizar wrote: > In message <52CB3839.6020704@labn.net> > Lou Berger writes: >> >> Hi Curtis, >> Thanks for the response. See below > > You pointed out a a few things you thought should be changed but left > it open for me to propose how to change things, so we'll need at least > one more iteration after this. > Right, you're the author.... >> On 1/6/2014 12:00 PM, Curtis Villamizar wrote: >>> Lou et al, >>> >>> Resending. I'm not sure if the original (sent Tue, 17 Dec 2013) went >>> through to all recipients. There may have been a problem (due to a >>> self inflicted DNS issue). >>> >>> I did not get a response so I suspect Lou didn't get this email. >>> >>> Curtis > > FYI - most recent issue I found was an error in IN TXT v=spf1 line. > It might be a bad time to be experimenting with IPv6 transition > technologies and their effects of email. :-( Go back to plain old > dual stack and burn another IPv4 global? Might be the right move. > > Hopefully mail will get through to everyone now without a resend. If > I have to resend I'll put the IPv6 mail server back into the DS > subnet before resending. > > Curtis > no problem at all on this one, so I think you're up and working! > >>> In message <52A8B5AB.4040708@labn.net> >>> Lou Berger writes: >>>> ... >> I believe my confusion was not understanding the differences between >> "Advanced Multipath" (with words capitalized) and "advanced multipath" >> (with words lower cased). While I understand this is your intent, I see >> it as just leading to confusion. Ultimately, it's the author's / WG's >> call, i.e., not mine, to make. > > OK so here is a suggestion to improve this. > > OLD > > Advanced Multipath > Advanced Multipath meets the requirements defined in this > document. A key capability of advanced multipath is the support > of non-homogeneous component links. > > OLD NEW > > Advanced Multipath > Advanced Multipath is a formalization of multipath techniques > that meets the requirements defined in this document. A key > capability of Advanced Multipath is the support of > non-homogeneous component links. > > NEWER > > Advanced Multipath > Advanced Multipath is a formalization of multipath techniques > that meets the requirements defined in this document. A key > capability of Advanced Multipath is the support of > non-homogeneous component links. > > Advanced Multipath Group (AMG) > > An Advanced Multipath Group (AMG) is group of component links > where Advanced Multipath techniques are applied. > Ahh. I think this is much better/clearer! > This along the lines of "Link Aggregation" and LAG. The first is > 802.1ax (or whatever, see the references). The latter is a group of > component links. > > Not to be confused with Absorbed Glass Mat lead-acid batteries... > (which is AGM not AMG). But if you see me write AGM, you'll know why > (habit, typo). > > I think if we use these definitions and make if this terminology > change is made everywhere in the document we will acheive the improved > clarity that you were looking for. > > Is this OK? Yes! > >>>> 2. Editorial: server and client layer vs upper and lower layer. >>>> >>>> The document uses server and client layer networks and LSPs and, >>>> sometimes interchangeably or redundantly, upper and lower layer networks >>>> and LSPs. I think this issue can be resolved by avoiding the term >>>> client/server when referring to network layers and just using the >>>> lower/upper terminology. The one exception to this is in the definition >>>> Client LSP which should simply be defined in the context of a multipath, >>>> i.e.: >>>> OLD >>>> A client LSP is an LSP which has been set up over a server layer. >>>> NEW >>>> A client LSP is an LSP which has been set up over Advanced Multipath. >>> >>> A client LSP can be set up over a server layer MPLS-TP LSP or any >>> server layer MPLS LSP or over a link layer or over a pseudowire ... or >>> over an advanced multipath. >>> >> >> Would you accept s/server layer/lower layer/g? > > The definition of server layer is not the same as the definition of > lower layer. See below. > >>>> I think this also means that usage of the term "Client" is limited to >>>> "Client LSP". >>> >>> I searched for all occurances of the word client. All occurances are >>> "client LSP" excexpt the phrase "client of a client LSP" and that is >>> used only in the following paragraph. >>> >>> The ingress and egress of a multipath may be midpoint LSRs with >>> respect to a given client LSP. A midpoint LSR does not participate >>> in the signaling of any clients of the client LSP. Therefore, in >>> general, multipath endpoints cannot determine requirements of clients >>> of a client LSP through participation in the signaling of the clients >>> of the client LSP. >>> >>> THe point is that "A midpoint LSR does not participate in the >>> signaling of any clients of the client LSP" and that non-participation >>> in client (or higher layer) signaling applies to any "client of a >>> client LSP", not just other LSP running over it. >>> >>> I then searched for all occurances of the words upper and lower and >>> higher. There are no occurances of "upper". >>> >>> There were a few occurances of "lower latency" and "higher latency". >>> Other than that, all occurances of lower and higher except one are in >>> the follwoing text: >>> >>> 3.2. Component Links Provided by Lower Layer Networks >>> >>> A component link may be supported by a lower layer network. For >>> example, the lower layer may be a circuit switched network or another >>> MPLS network (e.g., MPLS-TP)). The lower layer network may change >>> the latency (and/or other performance parameters) seen by the client >>> layer. Currently, there is no protocol for the lower layer network >>> to inform the higher layer network of a change in a performance >>> parameter. Communication of the latency performance parameter is a >>> very important requirement. Communication of other performance >>> parameters (e.g., delay variation) is desirable. >>> >>> FR#8 The solution SHALL specify a protocol means to allow a lower >>> layer server network to communicate latency to the higher layer >>> client network. >>> >>> The exception is this sentence: >>> >>> FR#22 The solution SHOULD support the use case where an advanced >>> multipath itself is a component link for a higher order advanced >>> multipath. For example, an advanced multipath comprised of MPLS- >>> TP bi-directional tunnels viewed as logical links could then be >>> used as a component link in yet another advanced multipath that >>> connects MPLS routers. >>> >>> The terms lower layer and higher layer go all the way back to the ISO >>> seven layer model of ancient times (1970s?, 1980s?) and maybe further >>> back but that is before even my time. >>> >>> I don't think this is unclear but I could add the following in >>> definitions: >>> >>> Higher Layers >>> A client layer is the one immediately above a server layer. The >>> client layer and all layers above that layer are higher layers. >>> >>> Lower Layers >>> A server layer is the later immediately below a client laer. >>> The server layer and all layers below are lower layers. >>> >>> Do I really need to put this in the definitions section? If yoy think >>> it is necessary, I will add it. >>> >> Perhaps we've talked (okay written) past each other. I was suggesting >> using/keeping the "higher and lower layer" terminology, not dropping it. >> And to use it (consistently) in place of "client and server Layer". > > I guess you missed the distinction in the definition above: > > For layer X layer Y is: > > client layer === Y = X+1 > server layer === Y = X-1 > higher layer === Y > X > lower layer === Y < X > > So the definition client layer is not the same as the definition of > higher layer. The definition of server layer is not the same as the > definition of lower layer. > > In some discussions we really do mean "the server layer" and not any > layer at any arbitrary depth below this one. > I read your usage of client/server layer to be synonymous with higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense of FR#8 (I think you really mean client layer not lower layer.) Given the current document usage, I still think it makes sense to eliminate the two instances of "client layer": How about the following: OLD Client LSP A client LSP is an LSP which has been set up over a server layer. In the context of this discussion, a client LSP is a LSP which has been set up over a multipath as opposed to an LSP representing the multipath itself or any LSP supporting a component links of that multipath. NEW Client LSP A client LSP is a LSP which has been set up over Advanced Multipath as opposed to an LSP representing the Advanced Multipath itself or any LSP that is part of an Advanced Multipath Group. and OLD The above set of requirements apply to component links with different characteristics regardless as to whether those component links are provided by parallel physical links between nodes or provided by sets of paths across a network provided by server layer LSP. NEW The above set of requirements apply to component links with different characteristics regardless as to whether those component links are provided by parallel physical links between nodes or provided by LSPs that are part of an Advanced Multipath Group. >>>> 3. Technical: The document should make it clear that LSPs can provide >>>> paths from an Advanced Multipath. I suggest adding something like the >>>> the following at the end of page 3 >>>> d. a lower layer LSP. >>> >>> Case "b." is intended to include LSP but is not specifically limited >>> to LSP. Multipath (not Advanced Multipath) includes IGP ECMP, >>> Ethernet Link Aggregation, and all sorts of things that don't involve >>> MPLS at all. For example, a path in Ethernet Link Aggregation Group >>> (LAG) could be supported by a pseudowires or ODU2e or GFP-F, though >>> this would be unknown to the LAG, or in the simplest case each path in >>> the set of LAG members could be supported by a plain Ethernet cable. >>> >> >> okay, how about: >> OLD >> b. may be specific paths across a network to a destination >> node, or >> NEW >> b. specific paths across a network to a destination >> node (e.g., via an LSP), or > > OK. But I like to spell out "for example" and put it after the > definition. That would give us: > > 4. The paths may be: > > a. parallel links between two nodes, or > > b. may be specific paths across a network to a destination > node, or > > c. may be links or paths to an intermediate node used to > reach a common destination. > > The paths need not have equal capacity. The paths may or may not > have equal cost in a routing protocol. > + Paths across a network which serve as a component link in a AMG > + may be provided by other LSP acting as server LSP for the > + client AMG. Component links of a given AMG need not all use the > + same type of server layer technology. For example, one may be a > + physical Ethernet, another a Packet Over Sonet (POS) link, > + another a pseudowire, and another an LSP with individual hops > + using a mix of lower layer technologies. > > Is that an acceptable clarification? Given the the definition of AMG I no longer see a need for the change or proposed text (and would prefer not having to discuss the proposed text.) ... >>>> 5. Technical: use of "indicate" in FR10-13, FR14, FR15: >>>> In these cases it is unclear if the requirements apply to >>>> (a) a client's ability to indicate a desired service/LSP constraint or >>>> (b) a selected component link's attribute that will be used by a client >>>> LSP, >>>> (c) both, or >>>> (d) something completely different >>>> The requirements should be clear to which entity the requirement applies. >>> >>> This "indication" can be through signaling or the management plane and >>> both must be supported in later framework and protocol definitions and >>> we can argue then whether both must be supported or if one or the >>> other is a "should" in RFC 2119 speak. >>> >>> There was concern that the word "signal" would exclude providing the >>> same informantion through the management plane and therefore the word >>> "indicate" is used. >>> >>> Rather than spell this out many times we hoped this would be clear. I >>> could add clarifying text up front if you think this is necessary. For >>> example, I could add the following before FR#1. >>> >>> FR#0 In requirements that follow in this document the word >>> "indicate" is used where information may be provided by either >>> the combination of link state IGP advertisement and MPLS LSP >>> signaling or via management plane protocols. In later documents >>> providing framework and protocol definitions both signaling and >>> management plane mechanisms MUST be defined. >>> >> >> So is this the IGP/signaling that runs between a client an an AM "LER", >> between an AM "LSR" and its server network, or between AM LSRs? If I >> understand AM properly, there may be *up to* there separate instances. >> Am I missing something? > > Please don't abbreviate Advanced Multipath as AM. Link Aggregation is > not LA. Perhaps you should a requirement on this ;-) > > The word "indicate" is independent of the method of getting the > information there. But yes in the example given the IGP advertisement > and MPLS LSP signaling that might be one such mechanism does refer to > the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. > > If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there > is only one IGP flooding information for both client and server layer, > hence the seemingly endless (and mostly pointless) discussion of > sub-layer vs layer from certain ITU people in the MPLS WG mailing list > who viewed MPLS as broken for not enforcing a strict layering in this > regard. But we need not go into that level of detail in this example > of how independent of mechanism the "indicate" is and down that years > old MPLS WG terminology rat hole again. > My comment is that you need to be clear to which layer a requirement applies. Is it the server layer, the client layer or the Advanced Multipath layer? >>> It would be trivial to make this FR#1 and renumber the rest. >>> >> >> I don't think the FR helped clarify the above question. > > The choice of the word "indicate" in FR10-13, FR14, FR15 does not > imply usage by a specific layer. That is a direct answer to your > question. > > In all of these specific cases, the the client layer is passing a > requirement to the server layer so in the IGP + RSVP-TE world that > would be a function of RSVP-TE. In the absense of control plane, it > would have to be done through management plane interaction where the > client indicates requirements of an LSP and the server layer is free > to figure out how to meet those requirements. > > Do you want me to add the clarification on the use of the word > "indicate" or not? I think you need to be clear that the requirement applies to all three layers. > >>> Should I add it and renumber? >>> >>>> 6. The last paragraph in section 3.3. strikes me as both odd and out of >>>> place. There are so many possible decisions that must be considered by >>>> network operators relative to disruption and optimization. Why mention >>>> just "power reduction"? Is there something special about the >>>> interactions of multipath and power reduction? What value / information >>>> does this paragraph add? >>> >>> The last paragraph in section 3.3 is: >>> >>> Allowing multipath to contain component links with different >>> characteristics can improve the overall load balance and can be >>> accomplished while still accommodating the more strict requirements >>> of a subset of client LSP. >>> >>> I'm not sure if this is the "odd and out of place" paragraph you refer >>> to. It summarizes the purpose of the requirements in this section. I >>> think you mean section 3.5 and not 3.3. >>> >> >> Correct. >> >>> The remainder of your paragraph above discusses power reducetion and >>> this is only mentioned in section 3.5 so I think you mean this >>> paragraph. >>> >> Right again. >> >>> As with any load balancing change, a change initiated for the purpose >>> of power reduction may be minimally disruptive. Typically the >>> disruption is limited to a change in delay characteristics and the >>> potential for a very brief period with traffic reordering. The >>> network operator when configuring a network for power reduction >>> should weigh the benefit of power reduction against the disadvantage >>> of a minimal disruption. >>> >>> The paragraphs following a set of requirements provide discussion >>> related to that set of requirements. I don't see this as out of >>> place. The prior two paragraphs discuss delay discontinuity. This >>> paragraph is a reminder that "As with any load balancing change, a >>> change initiated for the purpose of power reduction may be minimally >>> disruptive." I don't see this as out of place. >>> >>> For example, to compensate for a less than perfect load balance a >>> subset of LSPs may need to be moved and that subset can be chosen from >>> those which will be least affected (and there are plenty of >>> requirements that compell the fussy LSP to tell the network abour >>> their specifial needs). To power down a component link, *all* LSP on >>> that component link need to be moved, even the very fussy ones. >>> Therefore I think mentioning that disruption should be considered is >>> not out of place in the discussion following these requirements. We >>> like to keep the discussion brief so this level of detail was not >>> included. >>> >> >> I guess we see the importance of this topic differently. So will this >> be the first RFC that uses the term "power reduction"? > > Perhaps. A co-author originally wanted it added. The set of authors > kicked this around and reworded the original. The wording is brief > and vague and the use of MAY in the actual requirement means we will > not disallow this. So far no one in the WG has objected to this > wording and its been there a long time. > > Would you like me to remove the requirement and discussion of its > implications after the WG concensus so far was to keep it? > I think the text opens the door to the objection/question as to why just this "application" and not others are called out. Now that I've asked the question, we can move on. The AD can always revisit if he so chooses. ... >>>> Nits: >>>> >>>> - References should be provided in all cases when referring to >>>> "existing ... techniques" >>> >>> References are not allowed in the abstract. In section 3.3 is the sentence: >>> >>> Refer to the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a >>> description of existing techniques and a set of references. >>> >>> Much of that document is dedicated to describing existing techniques >>> and it contains quite a few references. >>> >>> I can move this sentence. Where in the document would you like to see >>> it moved to? >>> >> (Lines numbers from URL below.) >> Lines 200/201 and 278 have this issue. Lines 297 and 342 do not. >> >>>> Using line numbers from >>>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-13.txt >>> >>> Using line number is a text editor counts the page headers. What tool >>> are you using? I didn't see anything on tools.ietf.org. >>> >> huh. enter the above URL in a browser and you should see the line numbers. >> >>> So I'll guess. Looks like add 10 lines per page. >>> >> >>>> Line 112 >>>> s/SHOULD/should >>> >>> s/keywords, SHOULD be interpreted/keywords SHOULD be interpreted/ >>> >>> Also remove stray comma. >>> >> I don't think use of 2119 language being applied to the reader is >> appropriate, but whatever... > > You want me to downcase "SHOULD be interpreted". I missed a M-l in > the s/// edit (emacs downcase next word) and got only the stray comma. > Right. >>>> Line 118 >>>> s/MAY/may >>> >>> s/deployment MAY choose to/deployment may choose to/ >>> >>> OK. Could go either way but s/MAY chose to/MAY/ would work too. >>> >> No. The issue is that this document doesn't place conformance >> requirements on a service provider so RFC2119 language isn't appropriate >> here. > > No IETF document truly places conformance requirements on either the > service provider or implementor, but we put RFC2119 language in > telling them what to do all the time. No one in IETF signed a legal > document forcing them to adhere to every RFC2119 keyword in each > document. > > The requirements here are 1) implementor SHOULD provide a per feature > knob to turn individual features off, 2) provider MAY use those knobs, > including knobs that another implementor made available. I'd prefer the first to be a MUST, but you've documented wg consensus. I don't think #2 makes any sense, but we can move on. > > This is just trying to avoid unnecessarily inflexible specifications > or unnecessarily inflexible implementations where some feature doesn't > work when an unrelated feature is disabled. This is in here because > this inflexibility happens. > > The framework can outline any feature dependencies. > >>>> Line 149, match intro: >>>> s/Advanced Multipath meets/Advanced Multipath is a formalization of >>>> multipath techniques that meet >>> >>> OK. >>> >>>> Lines 251-254, beginning with "The" through the end of the paragraph. >>>> This should be an FR. >>> >>> Looks like you mean this: >>> >>> The transient period between some service disrupting >>> event and the convergence of the routing and/or signaling protocols >>> MUST occur within a time frame specified by Performance Objective >>> values. >>> >> Right. >>> OK. I'll add this as FR#6++. >>> >> >>>> That's it, >>>> Lou >>> >>> There are a few suggestions for changes to the text based on your >>> comments and a few questions for you. Based on your response to this >>> email I will edit the document. >>> >>> Thanks for the thorough review. >>> >> >> Thanks for the responses and the resend! >> >> Lou > > Sorry to mess up my own DNS and require a resend and a delay. > NP! Lou > Curtis > >>> Curtis >>> >>> - --rBI3apOu079413.1387337811/maildrop2.v6ds.occnc.com-- >>> >>> >>> ------- End of Forwarded Message > From curtis@ipv6.occnc.com Wed Jan 8 20:34:10 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB001ADF9F; Wed, 8 Jan 2014 20:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptAZQZpdJpWr; Wed, 8 Jan 2014 20:34:06 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id AA47E1ACCF5; Wed, 8 Jan 2014 20:34:05 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s094XtlK060524; Wed, 8 Jan 2014 23:33:55 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401090433.s094XtlK060524@maildrop2.v6ds.occnc.com> To: Lou Berger From: Curtis Villamizar Subject: Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 In-reply-to: Your message of "Wed, 08 Jan 2014 13:47:52 -0500." <52CD9D58.4010109@labn.net> Date: Wed, 08 Jan 2014 23:33:55 -0500 Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, rtgwg@ietf.org, "rtg-ads@tools.ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 04:34:10 -0000 Converging. But maybe one more round trip needed. In message <52CD9D58.4010109@labn.net> Lou Berger writes: > > Hi Curtis, > > See below. > > On 01/07/2014 09:56 PM, Curtis Villamizar wrote: > > In message <52CB3839.6020704@labn.net> > > Lou Berger writes: > >> > >> Hi Curtis, > >> Thanks for the response. See below > > > > You pointed out a a few things you thought should be changed but left > > it open for me to propose how to change things, so we'll need at least > > one more iteration after this. > > > Right, you're the author.... > > >> On 1/6/2014 12:00 PM, Curtis Villamizar wrote: > >>> Lou et al, > >>> > >>> Resending. I'm not sure if the original (sent Tue, 17 Dec 2013) went > >>> through to all recipients. There may have been a problem (due to a > >>> self inflicted DNS issue). > >>> > >>> I did not get a response so I suspect Lou didn't get this email. > >>> > >>> Curtis > > > > FYI - most recent issue I found was an error in IN TXT v=spf1 line. > > It might be a bad time to be experimenting with IPv6 transition > > technologies and their effects of email. :-( Go back to plain old > > dual stack and burn another IPv4 global? Might be the right move. > > > > Hopefully mail will get through to everyone now without a resend. If > > I have to resend I'll put the IPv6 mail server back into the DS > > subnet before resending. > > > > Curtis > > > no problem at all on this one, so I think you're up and working! > > > > > >>> In message <52A8B5AB.4040708@labn.net> > >>> Lou Berger writes: > >>>> > ... > > >> I believe my confusion was not understanding the differences between > >> "Advanced Multipath" (with words capitalized) and "advanced multipath" > >> (with words lower cased). While I understand this is your intent, I see > >> it as just leading to confusion. Ultimately, it's the author's / WG's > >> call, i.e., not mine, to make. > > > > OK so here is a suggestion to improve this. > > > > OLD > > > > Advanced Multipath > > Advanced Multipath meets the requirements defined in this > > document. A key capability of advanced multipath is the support > > of non-homogeneous component links. > > > > OLD NEW > > > > Advanced Multipath > > Advanced Multipath is a formalization of multipath techniques > > that meets the requirements defined in this document. A key > > capability of Advanced Multipath is the support of > > non-homogeneous component links. > > > > NEWER > > > > Advanced Multipath > > Advanced Multipath is a formalization of multipath techniques > > that meets the requirements defined in this document. A key > > capability of Advanced Multipath is the support of > > non-homogeneous component links. > > > > Advanced Multipath Group (AMG) > > > > An Advanced Multipath Group (AMG) is group of component links > > where Advanced Multipath techniques are applied. > > > > Ahh. I think this is much better/clearer! OK. This is easy enough since it is just a terminology change. > > This along the lines of "Link Aggregation" and LAG. The first is > > 802.1ax (or whatever, see the references). The latter is a group of > > component links. > > > > Not to be confused with Absorbed Glass Mat lead-acid batteries... > > (which is AGM not AMG). But if you see me write AGM, you'll know why > > (habit, typo). > > > > I think if we use these definitions and make if this terminology > > change is made everywhere in the document we will acheive the improved > > clarity that you were looking for. > > > > Is this OK? > > Yes! Only 42 occurances in the XML file to look at. Certainly doable. > >>>> 2. Editorial: server and client layer vs upper and lower layer. > >>>> > >>>> The document uses server and client layer networks and LSPs and, > >>>> sometimes interchangeably or redundantly, upper and lower layer networks > >>>> and LSPs. I think this issue can be resolved by avoiding the term > >>>> client/server when referring to network layers and just using the > >>>> lower/upper terminology. The one exception to this is in the definition > >>>> Client LSP which should simply be defined in the context of a multipath, > >>>> i.e.: > >>>> OLD > >>>> A client LSP is an LSP which has been set up over a server layer. > >>>> NEW > >>>> A client LSP is an LSP which has been set up over Advanced Multipath. > >>> > >>> A client LSP can be set up over a server layer MPLS-TP LSP or any > >>> server layer MPLS LSP or over a link layer or over a pseudowire ... or > >>> over an advanced multipath. > >>> > >> > >> Would you accept s/server layer/lower layer/g? > > > > The definition of server layer is not the same as the definition of > > lower layer. See below. > > > >>>> I think this also means that usage of the term "Client" is limited to > >>>> "Client LSP". > >>> > >>> I searched for all occurances of the word client. All occurances are > >>> "client LSP" excexpt the phrase "client of a client LSP" and that is > >>> used only in the following paragraph. > >>> > >>> The ingress and egress of a multipath may be midpoint LSRs with > >>> respect to a given client LSP. A midpoint LSR does not participate > >>> in the signaling of any clients of the client LSP. Therefore, in > >>> general, multipath endpoints cannot determine requirements of clients > >>> of a client LSP through participation in the signaling of the clients > >>> of the client LSP. > >>> > >>> THe point is that "A midpoint LSR does not participate in the > >>> signaling of any clients of the client LSP" and that non-participation > >>> in client (or higher layer) signaling applies to any "client of a > >>> client LSP", not just other LSP running over it. > >>> > >>> I then searched for all occurances of the words upper and lower and > >>> higher. There are no occurances of "upper". > >>> > >>> There were a few occurances of "lower latency" and "higher latency". > >>> Other than that, all occurances of lower and higher except one are in > >>> the follwoing text: > >>> > >>> 3.2. Component Links Provided by Lower Layer Networks > >>> > >>> A component link may be supported by a lower layer network. For > >>> example, the lower layer may be a circuit switched network or another > >>> MPLS network (e.g., MPLS-TP)). The lower layer network may change > >>> the latency (and/or other performance parameters) seen by the client > >>> layer. Currently, there is no protocol for the lower layer network > >>> to inform the higher layer network of a change in a performance > >>> parameter. Communication of the latency performance parameter is a > >>> very important requirement. Communication of other performance > >>> parameters (e.g., delay variation) is desirable. > >>> > >>> FR#8 The solution SHALL specify a protocol means to allow a lower > >>> layer server network to communicate latency to the higher layer > >>> client network. > >>> > >>> The exception is this sentence: > >>> > >>> FR#22 The solution SHOULD support the use case where an advanced > >>> multipath itself is a component link for a higher order advanced > >>> multipath. For example, an advanced multipath comprised of MPLS- > >>> TP bi-directional tunnels viewed as logical links could then be > >>> used as a component link in yet another advanced multipath that > >>> connects MPLS routers. > >>> > >>> The terms lower layer and higher layer go all the way back to the ISO > >>> seven layer model of ancient times (1970s?, 1980s?) and maybe further > >>> back but that is before even my time. > >>> > >>> I don't think this is unclear but I could add the following in > >>> definitions: > >>> > >>> Higher Layers > >>> A client layer is the one immediately above a server layer. The > >>> client layer and all layers above that layer are higher layers. > >>> > >>> Lower Layers > >>> A server layer is the later immediately below a client laer. > >>> The server layer and all layers below are lower layers. > >>> > >>> Do I really need to put this in the definitions section? If yoy think > >>> it is necessary, I will add it. > >>> > >> Perhaps we've talked (okay written) past each other. I was suggesting > >> using/keeping the "higher and lower layer" terminology, not dropping it. > >> And to use it (consistently) in place of "client and server Layer". > > > > I guess you missed the distinction in the definition above: > > > > For layer X layer Y is: > > > > client layer === Y = X+1 > > server layer === Y = X-1 > > higher layer === Y > X > > lower layer === Y < X > > > > So the definition client layer is not the same as the definition of > > higher layer. The definition of server layer is not the same as the > > definition of lower layer. > > > > In some discussions we really do mean "the server layer" and not any > > layer at any arbitrary depth below this one. > > I read your usage of client/server layer to be synonymous with > higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense > of FR#8 (I think you really mean client layer not lower layer.) FR#8 and FR#9 are about the server layer telling the client layer about the delays that can be expected. There is a little redundancy here so s/ower layer server network/server network/ and s/higher layer client network/client network/. No plans to skip layers. > Given the current document usage, I still think it makes sense to > eliminate the two instances of "client layer": How about the following: > OLD > Client LSP > A client LSP is an LSP which has been set up over a server layer. > In the context of this discussion, a client LSP is a LSP which > has been set up over a multipath as opposed to an LSP > representing the multipath itself or any LSP supporting a > component links of that multipath. > NEW > Client LSP > A client LSP is a LSP which > has been set up over Advanced Multipath as opposed to an LSP > representing the Advanced Multipath itself or any LSP that is > part of an Advanced Multipath Group. Nope. In general, a client LSP can be set up over a plain old Ethernet on a given hop, therefore the second definition is too narrow with this change. > and > OLD > The above set of requirements apply to component links with different > characteristics regardless as to whether those component links are > provided by parallel physical links between nodes or provided by sets > of paths across a network provided by server layer LSP. > NEW > The above set of requirements apply to component links with different > characteristics regardless as to whether those component links are > provided by parallel physical links between nodes or provided by > LSPs that are part of an Advanced Multipath Group. What about PW? Those are paths too by the definition of paths, so again, this change makes the definition too narrow. > >>>> 3. Technical: The document should make it clear that LSPs can provide > >>>> paths from an Advanced Multipath. I suggest adding something like the > >>>> the following at the end of page 3 > >>>> d. a lower layer LSP. > >>> > >>> Case "b." is intended to include LSP but is not specifically limited > >>> to LSP. Multipath (not Advanced Multipath) includes IGP ECMP, > >>> Ethernet Link Aggregation, and all sorts of things that don't involve > >>> MPLS at all. For example, a path in Ethernet Link Aggregation Group > >>> (LAG) could be supported by a pseudowires or ODU2e or GFP-F, though > >>> this would be unknown to the LAG, or in the simplest case each path in > >>> the set of LAG members could be supported by a plain Ethernet cable. > >>> > >> > >> okay, how about: > >> OLD > >> b. may be specific paths across a network to a destination > >> node, or > >> NEW > >> b. specific paths across a network to a destination > >> node (e.g., via an LSP), or > > > > OK. But I like to spell out "for example" and put it after the > > definition. That would give us: > > > > 4. The paths may be: > > > > a. parallel links between two nodes, or > > > > b. may be specific paths across a network to a destination > > node, or > > > > c. may be links or paths to an intermediate node used to > > reach a common destination. > > > > The paths need not have equal capacity. The paths may or may not > > have equal cost in a routing protocol. > > + Paths across a network which serve as a component link in a AMG > > + may be provided by other LSP acting as server LSP for the > > + client AMG. Component links of a given AMG need not all use the > > + same type of server layer technology. For example, one may be a > > + physical Ethernet, another a Packet Over Sonet (POS) link, > > + another a pseudowire, and another an LSP with individual hops > > + using a mix of lower layer technologies. > > > > Is that an acceptable clarification? > > Given the the definition of AMG I no longer see a need for the change or > proposed text (and would prefer not having to discuss the proposed text.) > ... OK. We won't make this addition. > >>>> 5. Technical: use of "indicate" in FR10-13, FR14, FR15: > >>>> In these cases it is unclear if the requirements apply to > >>>> (a) a client's ability to indicate a desired service/LSP constraint or > >>>> (b) a selected component link's attribute that will be used by a client > >>>> LSP, > >>>> (c) both, or > >>>> (d) something completely different > >>>> The requirements should be clear to which entity the requirement applies. > >>> > >>> This "indication" can be through signaling or the management plane and > >>> both must be supported in later framework and protocol definitions and > >>> we can argue then whether both must be supported or if one or the > >>> other is a "should" in RFC 2119 speak. > >>> > >>> There was concern that the word "signal" would exclude providing the > >>> same informantion through the management plane and therefore the word > >>> "indicate" is used. > >>> > >>> Rather than spell this out many times we hoped this would be clear. I > >>> could add clarifying text up front if you think this is necessary. For > >>> example, I could add the following before FR#1. > >>> > >>> FR#0 In requirements that follow in this document the word > >>> "indicate" is used where information may be provided by either > >>> the combination of link state IGP advertisement and MPLS LSP > >>> signaling or via management plane protocols. In later documents > >>> providing framework and protocol definitions both signaling and > >>> management plane mechanisms MUST be defined. > >>> > >> > >> So is this the IGP/signaling that runs between a client an an AM "LER", > >> between an AM "LSR" and its server network, or between AM LSRs? If I > >> understand AM properly, there may be *up to* there separate instances. > >> Am I missing something? > > > > Please don't abbreviate Advanced Multipath as AM. Link Aggregation is > > not LA. > > Perhaps you should a requirement on this ;-) Obvious acronym collision here, just like LA. > > The word "indicate" is independent of the method of getting the > > information there. But yes in the example given the IGP advertisement > > and MPLS LSP signaling that might be one such mechanism does refer to > > the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. > > > > If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there > > is only one IGP flooding information for both client and server layer, > > hence the seemingly endless (and mostly pointless) discussion of > > sub-layer vs layer from certain ITU people in the MPLS WG mailing list > > who viewed MPLS as broken for not enforcing a strict layering in this > > regard. But we need not go into that level of detail in this example > > of how independent of mechanism the "indicate" is and down that years > > old MPLS WG terminology rat hole again. > > > My comment is that you need to be clear to which layer a requirement > applies. Is it the server layer, the client layer or the Advanced > Multipath layer? In each of the requirements you cited it is very clear that the client later is communicating a requirement to the server layer, but if you'd like I can reword to make that even more clear by rewording of the form "SHALL provide a means for the client layer to indicate the requirements of a client LSP [regarding X]", where X is minimize latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific component link (FR#13), bidirection co-routed (FR#14), no reordering (FR#15), bounded frequency of rebalance (FR#20). > >>> It would be trivial to make this FR#1 and renumber the rest. > >>> > >> > >> I don't think the FR helped clarify the above question. > > > > The choice of the word "indicate" in FR10-13, FR14, FR15 does not > > imply usage by a specific layer. That is a direct answer to your > > question. > > > > In all of these specific cases, the the client layer is passing a > > requirement to the server layer so in the IGP + RSVP-TE world that > > would be a function of RSVP-TE. In the absense of control plane, it > > would have to be done through management plane interaction where the > > client indicates requirements of an LSP and the server layer is free > > to figure out how to meet those requirements. > > > > Do you want me to add the clarification on the use of the word > > "indicate" or not? > > I think you need to be clear that the requirement applies to all three > layers. There are no distinct three layers. You are imagining a model that is not used in this document so please don't impose model on our document. In your sentence above I have no idea what "the requirement" refers to. In summary: We were discussing why the word "indicate" was used to avoid requiring specific mechanisms for information passing and I asked if I should add the following. FR#0 In requirements that follow in this document the word "indicate" is used where information may be provided by either the combination of link state IGP advertisement and MPLS LSP signaling or via management plane protocols. In later documents providing framework and protocol definitions both signaling and management plane mechanisms MUST be defined. Information is two way. The requirements you cited were all worded in the form "The solution SHALL provide a means to indicate that a client LSP will ...". So far I have offerred to reword this to the form "The solution SHALL provide a means for the client layer to indicate a requirement that a client LSP will ..." (ie: get minimum latency, get bound latency, etc). Is adding FR#0 OK? Do you want this sort of rewording to make it more explicit that the client layer is communication a requirement for a specific client LSP? > >>> Should I add it and renumber? > >>> > >>>> 6. The last paragraph in section 3.3. strikes me as both odd and out of > >>>> place. There are so many possible decisions that must be considered by > >>>> network operators relative to disruption and optimization. Why mention > >>>> just "power reduction"? Is there something special about the > >>>> interactions of multipath and power reduction? What value / information > >>>> does this paragraph add? > >>> > >>> The last paragraph in section 3.3 is: > >>> > >>> Allowing multipath to contain component links with different > >>> characteristics can improve the overall load balance and can be > >>> accomplished while still accommodating the more strict requirements > >>> of a subset of client LSP. > >>> > >>> I'm not sure if this is the "odd and out of place" paragraph you refer > >>> to. It summarizes the purpose of the requirements in this section. I > >>> think you mean section 3.5 and not 3.3. > >>> > >> > >> Correct. > >> > >>> The remainder of your paragraph above discusses power reducetion and > >>> this is only mentioned in section 3.5 so I think you mean this > >>> paragraph. > >>> > >> Right again. > >> > >>> As with any load balancing change, a change initiated for the purpose > >>> of power reduction may be minimally disruptive. Typically the > >>> disruption is limited to a change in delay characteristics and the > >>> potential for a very brief period with traffic reordering. The > >>> network operator when configuring a network for power reduction > >>> should weigh the benefit of power reduction against the disadvantage > >>> of a minimal disruption. > >>> > >>> The paragraphs following a set of requirements provide discussion > >>> related to that set of requirements. I don't see this as out of > >>> place. The prior two paragraphs discuss delay discontinuity. This > >>> paragraph is a reminder that "As with any load balancing change, a > >>> change initiated for the purpose of power reduction may be minimally > >>> disruptive." I don't see this as out of place. > >>> > >>> For example, to compensate for a less than perfect load balance a > >>> subset of LSPs may need to be moved and that subset can be chosen from > >>> those which will be least affected (and there are plenty of > >>> requirements that compell the fussy LSP to tell the network abour > >>> their specifial needs). To power down a component link, *all* LSP on > >>> that component link need to be moved, even the very fussy ones. > >>> Therefore I think mentioning that disruption should be considered is > >>> not out of place in the discussion following these requirements. We > >>> like to keep the discussion brief so this level of detail was not > >>> included. > >>> > >> > >> I guess we see the importance of this topic differently. So will this > >> be the first RFC that uses the term "power reduction"? > > > > Perhaps. A co-author originally wanted it added. The set of authors > > kicked this around and reworded the original. The wording is brief > > and vague and the use of MAY in the actual requirement means we will > > not disallow this. So far no one in the WG has objected to this > > wording and its been there a long time. > > > > Would you like me to remove the requirement and discussion of its > > implications after the WG concensus so far was to keep it? > > > > I think the text opens the door to the objection/question as to why just > this "application" and not others are called out. Now that I've asked > the question, we can move on. The AD can always revisit if he so chooses. > > ... OK > >>>> Nits: > >>>> > >>>> - References should be provided in all cases when referring to > >>>> "existing ... techniques" > >>> > >>> References are not allowed in the abstract. In section 3.3 is the sentence: > >>> > >>> Refer to the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a > >>> description of existing techniques and a set of references. > >>> > >>> Much of that document is dedicated to describing existing techniques > >>> and it contains quite a few references. > >>> > >>> I can move this sentence. Where in the document would you like to see > >>> it moved to? > >>> > >> (Lines numbers from URL below.) > >> Lines 200/201 and 278 have this issue. Lines 297 and 342 do not. > >> > >>>> Using line numbers from > >>>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-13.txt > >>> > >>> Using line number is a text editor counts the page headers. What tool > >>> are you using? I didn't see anything on tools.ietf.org. > >>> > >> huh. enter the above URL in a browser and you should see the line numbers. > >> > >>> So I'll guess. Looks like add 10 lines per page. > >>> > >> > >>>> Line 112 > >>>> s/SHOULD/should > >>> > >>> s/keywords, SHOULD be interpreted/keywords SHOULD be interpreted/ > >>> > >>> Also remove stray comma. > >>> > >> I don't think use of 2119 language being applied to the reader is > >> appropriate, but whatever... > > > > You want me to downcase "SHOULD be interpreted". I missed a M-l in > > the s/// edit (emacs downcase next word) and got only the stray comma. > > > > Right. > > >>>> Line 118 > >>>> s/MAY/may > >>> > >>> s/deployment MAY choose to/deployment may choose to/ > >>> > >>> OK. Could go either way but s/MAY chose to/MAY/ would work too. > >>> > >> No. The issue is that this document doesn't place conformance > >> requirements on a service provider so RFC2119 language isn't appropriate > >> here. > > > > No IETF document truly places conformance requirements on either the > > service provider or implementor, but we put RFC2119 language in > > telling them what to do all the time. No one in IETF signed a legal > > document forcing them to adhere to every RFC2119 keyword in each > > document. > > > > The requirements here are 1) implementor SHOULD provide a per feature > > knob to turn individual features off, 2) provider MAY use those knobs, > > including knobs that another implementor made available. > > I'd prefer the first to be a MUST, but you've documented wg consensus. > I don't think #2 makes any sense, but we can move on. > > > > > This is just trying to avoid unnecessarily inflexible specifications > > or unnecessarily inflexible implementations where some feature doesn't > > work when an unrelated feature is disabled. This is in here because > > this inflexibility happens. > > > > The framework can outline any feature dependencies. > > > >>>> Line 149, match intro: > >>>> s/Advanced Multipath meets/Advanced Multipath is a formalization of > >>>> multipath techniques that meet > >>> > >>> OK. > >>> > >>>> Lines 251-254, beginning with "The" through the end of the paragraph. > >>>> This should be an FR. > >>> > >>> Looks like you mean this: > >>> > >>> The transient period between some service disrupting > >>> event and the convergence of the routing and/or signaling protocols > >>> MUST occur within a time frame specified by Performance Objective > >>> values. > >>> > >> Right. > >>> OK. I'll add this as FR#6++. > >>> > >> > >>>> That's it, > >>>> Lou > >>> > >>> There are a few suggestions for changes to the text based on your > >>> comments and a few questions for you. Based on your response to this > >>> email I will edit the document. > >>> > >>> Thanks for the thorough review. > >>> > >> > >> Thanks for the responses and the resend! > >> > >> Lou > > > > Sorry to mess up my own DNS and require a resend and a delay. > > > NP! > > Lou Curtis From lberger@labn.net Fri Jan 10 09:35:50 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15B11AE126; Fri, 10 Jan 2014 09:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.188 X-Spam-Level: ** X-Spam-Status: No, score=2.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_BIZ=0.288, HELO_MISMATCH_BIZ=0.443, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793, SPF_NEUTRAL=0.779] 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 9M9_A_J5SHpk; Fri, 10 Jan 2014 09:35:47 -0800 (PST) Received: from newdragon.webhostserver.biz (unknown [69.25.137.16]) by ietfa.amsl.com (Postfix) with ESMTP id A1EA71AE119; Fri, 10 Jan 2014 09:35:47 -0800 (PST) Received: from localhost ([::1]:41520 helo=[127.0.0.1]) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W1fzb-0008Sh-Gq; Fri, 10 Jan 2014 20:35:35 +0300 Message-ID: <52D02F67.9070604@labn.net> Date: Fri, 10 Jan 2014 12:35:35 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com Subject: Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 References: <201401090433.s094XtlK060524@maildrop2.v6ds.occnc.com> In-Reply-To: <201401090433.s094XtlK060524@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, "rtg-ads@tools.ietf.org" , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 17:35:50 -0000 Curtis, I think we have one disconnect (and corresponding related text) that we need to resolve before we can be close the discussion. See below for details.. On 1/8/2014 11:33 PM, Curtis Villamizar wrote: > Converging. But maybe one more round trip needed. > > In message <52CD9D58.4010109@labn.net> > Lou Berger writes: >> ... >>>>>> 2. Editorial: server and client layer vs upper and lower layer. >>>>>> >>>>>> The document uses server and client layer networks and LSPs and, >>>>>> sometimes interchangeably or redundantly, upper and lower layer networks >>>>>> and LSPs. I think this issue can be resolved by avoiding the term >>>>>> client/server when referring to network layers and just using the >>>>>> lower/upper terminology. The one exception to this is in the definition >>>>>> Client LSP which should simply be defined in the context of a multipath, >>>>>> i.e.: >>>>>> OLD >>>>>> A client LSP is an LSP which has been set up over a server layer. >>>>>> NEW >>>>>> A client LSP is an LSP which has been set up over Advanced Multipath. >>>>> >>>>> A client LSP can be set up over a server layer MPLS-TP LSP or any >>>>> server layer MPLS LSP or over a link layer or over a pseudowire ... or >>>>> over an advanced multipath. >>>>> >>>> >>>> Would you accept s/server layer/lower layer/g? >>> >>> The definition of server layer is not the same as the definition of >>> lower layer. See below. >>> >>>>>> I think this also means that usage of the term "Client" is limited to >>>>>> "Client LSP". >>>>> >>>>> I searched for all occurances of the word client. All occurances are >>>/>> "client LSP" excexpt the phrase "client of a client LSP" and that is >>>>> used only in the following paragraph. >>>>> >>>>> The ingress and egress of a multipath may be midpoint LSRs with >>>>> respect to a given client LSP. A midpoint LSR does not participate >>>>> in the signaling of any clients of the client LSP. Therefore, in >>>>> general, multipath endpoints cannot determine requirements of clients >>>>> of a client LSP through participation in the signaling of the clients >>>>> of the client LSP. >>>>> >>>>> THe point is that "A midpoint LSR does not participate in the >>>>> signaling of any clients of the client LSP" and that non-participation >>>>> in client (or higher layer) signaling applies to any "client of a >>>>> client LSP", not just other LSP running over it. >>>>> >>>>> I then searched for all occurances of the words upper and lower and >>>>> higher. There are no occurances of "upper". >>>>> >>>>> There were a few occurances of "lower latency" and "higher latency". >>>>> Other than that, all occurances of lower and higher except one are in >>>>> the follwoing text: >>>>> >>>>> 3.2. Component Links Provided by Lower Layer Networks >>>>> >>>>> A component link may be supported by a lower layer network. For >>>>> example, the lower layer may be a circuit switched network or another >>>>> MPLS network (e.g., MPLS-TP)). The lower layer network may change >>>>> the latency (and/or other performance parameters) seen by the client >>>>> layer. Currently, there is no protocol for the lower layer network >>>>> to inform the higher layer network of a change in a performance >>>>> parameter. Communication of the latency performance parameter is a >>>>> very important requirement. Communication of other performance >>>>> parameters (e.g., delay variation) is desirable. >>>>> >>>>> FR#8 The solution SHALL specify a protocol means to allow a lower >>>>> layer server network to communicate latency to the higher layer >>>>> client network. >>>>> >>>>> The exception is this sentence: >>>>> >>>>> FR#22 The solution SHOULD support the use case where an advanced >>>>> multipath itself is a component link for a higher order advanced >>>>> multipath. For example, an advanced multipath comprised of MPLS- >>>>> TP bi-directional tunnels viewed as logical links could then be >>>>> used as a component link in yet another advanced multipath that >>>>> connects MPLS routers. >>>>> >>>>> The terms lower layer and higher layer go all the way back to the ISO >>>>> seven layer model of ancient times (1970s?, 1980s?) and maybe further >>>>> back but that is before even my time. >>>>> >>>>> I don't think this is unclear but I could add the following in >>>>> definitions: >>>>> >>>>> Higher Layers >>>>> A client layer is the one immediately above a server layer. The >>>>> client layer and all layers above that layer are higher layers. >>>>> >>>>> Lower Layers >>>>> A server layer is the later immediately below a client laer. >>>>> The server layer and all layers below are lower layers. >>>>> >>>>> Do I really need to put this in the definitions section? If yoy think >>>>> it is necessary, I will add it. >>>>> >>>> Perhaps we've talked (okay written) past each other. I was suggesting >>>> using/keeping the "higher and lower layer" terminology, not dropping it. >>>> And to use it (consistently) in place of "client and server Layer". >>> >>> I guess you missed the distinction in the definition above: >>> >>> For layer X layer Y is: >>> >>> client layer === Y = X+1 >>> server layer === Y = X-1 >>> higher layer === Y > X >>> lower layer === Y < X >>> >>> So the definition client layer is not the same as the definition of >>> higher layer. The definition of server layer is not the same as the >>> definition of lower layer. >>> >>> In some discussions we really do mean "the server layer" and not any >>> layer at any arbitrary depth below this one. >> >> I read your usage of client/server layer to be synonymous with >> higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense >> of FR#8 (I think you really mean client layer not lower layer.) > > FR#8 and FR#9 are about the server layer telling the client layer > about the delays that can be expected. There is a little redundancy > here so s/ower layer server network/server network/ and > s/higher layer client network/client network/. No plans to skip > layers. > I think we need to hit the points below before this one... >> Given the current document usage, I still think it makes sense to >> eliminate the two instances of "client layer": How about the following: >> OLD >> Client LSP >> A client LSP is an LSP which has been set up over a server layer. >> In the context of this discussion, a client LSP is a LSP which >> has been set up over a multipath as opposed to an LSP >> representing the multipath itself or any LSP supporting a >> component links of that multipath. >> NEW >> Client LSP >> A client LSP is a LSP which >> has been set up over Advanced Multipath as opposed to an LSP >> representing the Advanced Multipath itself or any LSP that is >> part of an Advanced Multipath Group. > > Nope. In general, a client LSP can be set up over a plain old > Ethernet on a given hop, therefore the second definition is too > narrow with this change. > humm, you didn't have that in your OLD text. In fact, the old text reads to me that an Advanced Multipath (solution?) logically sits between a client LSP and an underlying server layer in all cases. So the model I see defined by the text has the following layers Client LSP (layer) ---------- Advanced Multipath (layer/solution/construct) ---------- Server Layer (composed of AMGs which are LSPs and/or links) Is this aligned with your intent? If not, can you explain the relationship you see for Advanced Multipath Client LSPs and Advanced Multipath AMGs? >> and >> OLD >> The above set of requirements apply to component links with different >> characteristics regardless as to whether those component links are >> provided by parallel physical links between nodes or provided by sets >> of paths across a network provided by server layer LSP. >> NEW >> The above set of requirements apply to component links with different >> characteristics regardless as to whether those component links are >> provided by parallel physical links between nodes or provided by >> LSPs that are part of an Advanced Multipath Group. > > What about PW? Those are paths too by the definition of paths, so > again, this change makes the definition too narrow. > PWs weren't mentioned in your OLD text, so I didn't add them. I also have no objections to adding them. The only change I made was s/sets of paths across a network provided by server layer LSP./ LSPs that are part of an Advanced Multipath Group. ... > >>> The word "indicate" is independent of the method of getting the >>> information there. But yes in the example given the IGP advertisement >>> and MPLS LSP signaling that might be one such mechanism does refer to >>> the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. >>> >>> If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there >>> is only one IGP flooding information for both client and server layer, >>> hence the seemingly endless (and mostly pointless) discussion of >>> sub-layer vs layer from certain ITU people in the MPLS WG mailing list >>> who viewed MPLS as broken for not enforcing a strict layering in this >>> regard. But we need not go into that level of detail in this example >>> of how independent of mechanism the "indicate" is and down that years >>> old MPLS WG terminology rat hole again. >>> >> My comment is that you need to be clear to which layer a requirement >> applies. Is it the server layer, the client layer or the Advanced >> Multipath layer? > > In each of the requirements you cited it is very clear that the client > later is communicating a requirement to the server layer, but if you'd > like I can reword to make that even more clear by rewording of the > form "SHALL provide a means for the client layer to indicate the > requirements of a client LSP [regarding X]", where X is minimize > latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific > component link (FR#13), bidirection co-routed (FR#14), no reordering > (FR#15), bounded frequency of rebalance (FR#20). Okay, I think this will/may help. My comment goes back to the model I was asking about above. And to which part of the puzzle the requirement applies. > >>>>> It would be trivial to make this FR#1 and renumber the rest. >>>>> >>>> >>>> I don't think the FR helped clarify the above question. >>> >>> The choice of the word "indicate" in FR10-13, FR14, FR15 does not >>> imply usage by a specific layer. That is a direct answer to your >>> question. >>> >>> In all of these specific cases, the the client layer is passing a >>> requirement to the server layer so in the IGP + RSVP-TE world that >>> would be a function of RSVP-TE. In the absense of control plane, it >>> would have to be done through management plane interaction where the >>> client indicates requirements of an LSP and the server layer is free >>> to figure out how to meet those requirements. >>> >>> Do you want me to add the clarification on the use of the word >>> "indicate" or not? >> >> I think you need to be clear that the requirement applies to all three >> layers. > > There are no distinct three layers. You are imagining a model that is > not used in this document so please don't impose model on our document. > Well your old definition of Client LSP said that it was a client of "multipath" and else where you say that "multipath" operates over a server layer. As mentioned above, this sounds like three layers to me. If this is not your intent, I think you need to make it clear (through revised text) what model you do intend. > In your sentence above I have no idea what "the requirement" refers to. > > In summary: > > We were discussing why the word "indicate" was used to avoid requiring > specific mechanisms for information passing and I asked if I should > add the following. > > FR#0 In requirements that follow in this document the word > "indicate" is used where information may be provided by either > the combination of link state IGP advertisement and MPLS LSP > signaling or via management plane protocols. In later documents > providing framework and protocol definitions both signaling and > management plane mechanisms MUST be defined. > > Information is two way. The requirements you cited were all worded in > the form "The solution SHALL provide a means to indicate that a client > LSP will ...". So far I have offerred to reword this to the form "The > solution SHALL provide a means for the client layer to indicate a > requirement that a client LSP will ..." (ie: get minimum latency, get > bound latency, etc). > > Is adding FR#0 OK? > > Do you want this sort of rewording to make it more explicit that the > client layer is communication a requirement for a specific client LSP? > I think we need to come back to this once we resolve the "model" topic. ... Thanks, Lou From liu.bin21@zte.com.cn Sun Jan 12 16:38:58 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4C61ACCE2 for ; Sun, 12 Jan 2014 16:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 MY2zu9TVX6Md for ; Sun, 12 Jan 2014 16:38:56 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 589A11ACCDC for ; Sun, 12 Jan 2014 16:38:56 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id EEE151269CC2 for ; Mon, 13 Jan 2014 08:38:38 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id D1D09CBE61C for ; Mon, 13 Jan 2014 08:38:37 +0800 (CST) Received: (from root@localhost) by mse01.zte.com.cn id s0D0chda043369 for ; Mon, 13 Jan 2014 08:38:43 +0800 (GMT-8) (envelope-from liu.bin21@zte.com.cn) Message-Id: <201401130038.s0D0chda043369@mse01.zte.com.cn> Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s0C0o2qL005750 for ; Sun, 12 Jan 2014 08:50:02 +0800 (GMT-8) (envelope-from liu.bin21@zte.com.cn) To: rtgwg@ietf.org Subject: Ask for comments: draft-sl-rtgwg-far-dcn-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: liu.bin21@zte.com.cn Date: Sun, 12 Jan 2014 08:50:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-01-12 08:49:51, Serialize complete at 2014-01-12 08:49:51 Content-Type: multipart/alternative; boundary="=_alternative 000494DF48257C5E_=" X-MAIL: mse01.zte.com.cn s0D0chda043369 X-MSS: AUDITRELEASE@mse01.zte.com.cn X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 00:38:58 -0000 This is a multipart message in MIME format. --=_alternative 000494DF48257C5E_= Content-Type: text/plain; charset="US-ASCII" Greeting all, We uploaded a draft that proposed a generic routing method and protocol for a regular data center network, named as the fault-avoidance routing (FAR) protocol. FAR protocol provides a generic routing method for all kinds of network architectures that are proposed for large-scale cloud data centers over the past few years. FAR protocol is well designed to fully leverage the regularity in the topology and compute its routing table in a simple way. We hope to get valuable opinions of experts in the routing group on our draft. Best regards, Richard Bin Liu --------------------------------------------------------------------------- A new version of I-D, draft-sl-rtgwg-far-dcn-00.txt has been successfully submitted by Bin Liu and posted to the IETF repository. Filename: draft-sl-rtgwg-far-dcn Revision: 00 Title: Generic Fault-avoidance Routing Protocol for Data Center Networks Creation date: 2013-12-19 Group: Individual Submission Number of pages: 24 URL: http://www.ietf.org/internet-drafts/draft-sl-rtgwg-far-dcn-00.txt Status: http://datatracker.ietf.org/doc/draft-sl-rtgwg-far-dcn Htmlized: http://tools.ietf.org/html/draft-sl-rtgwg-far-dcn-00 Abstract: This draft proposed a generic routing method and protocol for a regular data center network, named as the fault-avoidance routing (FAR) protocol. FAR protocol provides a generic routing method for all kinds of network architectures that are proposed for large-scale cloud data centers over the past few years. FAR protocol is well designed to fully leverage the regularity in the topology and compute its routing table in a simple way. Fat-tree is taken as an example architecture to illuminate how to apply FAR protocol in this draft. --=_alternative 000494DF48257C5E_= Content-Type: text/html; charset="US-ASCII"
Greeting all,

We uploaded a draft that proposed a generic routing method and protocol for a regular data center network, named as the fault-avoidance routing (FAR) protocol. FAR protocol provides a generic routing method for all kinds of network architectures that are proposed for large-scale cloud data centers over the past few years.  FAR protocol is well designed to fully leverage the regularity in the topology and compute its routing table in a simple way.

We hope to get valuable opinions of experts in the routing group on our draft.

Best regards,
Richard Bin Liu

---------------------------------------------------------------------------
A new version of I-D, draft-sl-rtgwg-far-dcn-00.txt
has been successfully submitted by Bin Liu and posted to the
IETF repository.

Filename:                  draft-sl-rtgwg-far-dcn
Revision:                  00
Title:                                   Generic Fault-avoidance Routing Protocol for Data Center Networks
Creation date:                  2013-12-19
Group:                                   Individual Submission
Number of pages: 24
URL:             http://www.ietf.org/internet-drafts/draft-sl-rtgwg-far-dcn-00.txt
Status:          http://datatracker.ietf.org/doc/draft-sl-rtgwg-far-dcn
Htmlized:        http://tools.ietf.org/html/draft-sl-rtgwg-far-dcn-00


Abstract:
   This draft proposed a generic routing method and protocol for a
   regular data center network, named as the fault-avoidance routing
   (FAR) protocol.  FAR protocol provides a generic routing method for
   all kinds of network architectures that are proposed for large-scale
   cloud data centers over the past few years.  FAR protocol is well
   designed to fully leverage the regularity in the topology and compute
   its routing table in a simple way.  Fat-tree is taken as an example
   architecture to illuminate how to apply FAR protocol in this draft.

                                                                                 

--=_alternative 000494DF48257C5E_=-- From curtis@ipv6.occnc.com Wed Jan 15 16:00:25 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC031AE453; Wed, 15 Jan 2014 16:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKHLMCUT7dD9; Wed, 15 Jan 2014 16:00:21 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id EF7EF1AE454; Wed, 15 Jan 2014 16:00:20 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0G006Pk025219; Wed, 15 Jan 2014 19:00:07 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401160000.s0G006Pk025219@maildrop2.v6ds.occnc.com> To: Lou Berger From: Curtis Villamizar Subject: Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 In-reply-to: Your message of "Fri, 10 Jan 2014 12:35:35 -0500." <52D02F67.9070604@labn.net> Date: Wed, 15 Jan 2014 19:00:06 -0500 Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, rtgwg@ietf.org, "rtg-ads@tools.ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 00:00:26 -0000 In message <52D02F67.9070604@labn.net> Lou Berger writes: > Curtis, > > I think we have one disconnect (and corresponding related text) that we > need to resolve before we can be close the discussion. See below for > details.. > > On 1/8/2014 11:33 PM, Curtis Villamizar wrote: > > Converging. But maybe one more round trip needed. > > > > In message <52CD9D58.4010109@labn.net> > > Lou Berger writes: > >> > ... > > >>>>>> 2. Editorial: server and client layer vs upper and lower layer. > >>>>>> > >>>>>> The document uses server and client layer networks and LSPs and, > >>>>>> sometimes interchangeably or redundantly, upper and lower layer networks > >>>>>> and LSPs. I think this issue can be resolved by avoiding the term > >>>>>> client/server when referring to network layers and just using the > >>>>>> lower/upper terminology. The one exception to this is in the definition > >>>>>> Client LSP which should simply be defined in the context of a multipath, > >>>>>> i.e.: > >>>>>> OLD > >>>>>> A client LSP is an LSP which has been set up over a server layer. > >>>>>> NEW > >>>>>> A client LSP is an LSP which has been set up over Advanced Multipath. > >>>>> > >>>>> A client LSP can be set up over a server layer MPLS-TP LSP or any > >>>>> server layer MPLS LSP or over a link layer or over a pseudowire ... or > >>>>> over an advanced multipath. > >>>>> > >>>> > >>>> Would you accept s/server layer/lower layer/g? > >>> > >>> The definition of server layer is not the same as the definition of > >>> lower layer. See below. > >>> > >>>>>> I think this also means that usage of the term "Client" is limited to > >>>>>> "Client LSP". > >>>>> > >>>>> I searched for all occurances of the word client. All occurances are > >>>/>> "client LSP" excexpt the phrase "client of a client LSP" and that is > >>>>> used only in the following paragraph. > >>>>> > >>>>> The ingress and egress of a multipath may be midpoint LSRs with > >>>>> respect to a given client LSP. A midpoint LSR does not participate > >>>>> in the signaling of any clients of the client LSP. Therefore, in > >>>>> general, multipath endpoints cannot determine requirements of clients > >>>>> of a client LSP through participation in the signaling of the clients > >>>>> of the client LSP. > >>>>> > >>>>> THe point is that "A midpoint LSR does not participate in the > >>>>> signaling of any clients of the client LSP" and that non-participation > >>>>> in client (or higher layer) signaling applies to any "client of a > >>>>> client LSP", not just other LSP running over it. > >>>>> > >>>>> I then searched for all occurances of the words upper and lower and > >>>>> higher. There are no occurances of "upper". > >>>>> > >>>>> There were a few occurances of "lower latency" and "higher latency". > >>>>> Other than that, all occurances of lower and higher except one are in > >>>>> the follwoing text: > >>>>> > >>>>> 3.2. Component Links Provided by Lower Layer Networks > >>>>> > >>>>> A component link may be supported by a lower layer network. For > >>>>> example, the lower layer may be a circuit switched network or another > >>>>> MPLS network (e.g., MPLS-TP)). The lower layer network may change > >>>>> the latency (and/or other performance parameters) seen by the client > >>>>> layer. Currently, there is no protocol for the lower layer network > >>>>> to inform the higher layer network of a change in a performance > >>>>> parameter. Communication of the latency performance parameter is a > >>>>> very important requirement. Communication of other performance > >>>>> parameters (e.g., delay variation) is desirable. > >>>>> > >>>>> FR#8 The solution SHALL specify a protocol means to allow a lower > >>>>> layer server network to communicate latency to the higher layer > >>>>> client network. > >>>>> > >>>>> The exception is this sentence: > >>>>> > >>>>> FR#22 The solution SHOULD support the use case where an advanced > >>>>> multipath itself is a component link for a higher order advanced > >>>>> multipath. For example, an advanced multipath comprised of MPLS- > >>>>> TP bi-directional tunnels viewed as logical links could then be > >>>>> used as a component link in yet another advanced multipath that > >>>>> connects MPLS routers. > >>>>> > >>>>> The terms lower layer and higher layer go all the way back to the ISO > >>>>> seven layer model of ancient times (1970s?, 1980s?) and maybe further > >>>>> back but that is before even my time. > >>>>> > >>>>> I don't think this is unclear but I could add the following in > >>>>> definitions: > >>>>> > >>>>> Higher Layers > >>>>> A client layer is the one immediately above a server layer. The > >>>>> client layer and all layers above that layer are higher layers. > >>>>> > >>>>> Lower Layers > >>>>> A server layer is the later immediately below a client laer. > >>>>> The server layer and all layers below are lower layers. > >>>>> > >>>>> Do I really need to put this in the definitions section? If yoy think > >>>>> it is necessary, I will add it. > >>>>> > >>>> Perhaps we've talked (okay written) past each other. I was suggesting > >>>> using/keeping the "higher and lower layer" terminology, not dropping it. > >>>> And to use it (consistently) in place of "client and server Layer". > >>> > >>> I guess you missed the distinction in the definition above: > >>> > >>> For layer X layer Y is: > >>> > >>> client layer === Y = X+1 > >>> server layer === Y = X-1 > >>> higher layer === Y > X > >>> lower layer === Y < X > >>> > >>> So the definition client layer is not the same as the definition of > >>> higher layer. The definition of server layer is not the same as the > >>> definition of lower layer. > >>> > >>> In some discussions we really do mean "the server layer" and not any > >>> layer at any arbitrary depth below this one. > >> > >> I read your usage of client/server layer to be synonymous with > >> higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense > >> of FR#8 (I think you really mean client layer not lower layer.) > > > > FR#8 and FR#9 are about the server layer telling the client layer > > about the delays that can be expected. There is a little redundancy > > here so s/ower layer server network/server network/ and > > s/higher layer client network/client network/. No plans to skip > > layers. > > > > I think we need to hit the points below before this one... OK. > >> Given the current document usage, I still think it makes sense to > >> eliminate the two instances of "client layer": How about the following: > >> OLD > >> Client LSP > >> A client LSP is an LSP which has been set up over a server layer. > >> In the context of this discussion, a client LSP is a LSP which > >> has been set up over a multipath as opposed to an LSP > >> representing the multipath itself or any LSP supporting a > >> component links of that multipath. > >> NEW > >> Client LSP > >> A client LSP is a LSP which > >> has been set up over Advanced Multipath as opposed to an LSP > >> representing the Advanced Multipath itself or any LSP that is > >> part of an Advanced Multipath Group. > > > > Nope. In general, a client LSP can be set up over a plain old > > Ethernet on a given hop, therefore the second definition is too > > narrow with this change. > > > > humm, you didn't have that in your OLD text. In fact, the old text > reads to me that an Advanced Multipath (solution?) logically sits > between a client LSP and an underlying server layer in all cases. The "OLD" was a quote from you and it was the original text in -13. I said "Nope. ..." to your suggested change to it in this way. Earlier (http://www.ietf.org/mail-archive/web/rtgwg/current/msg04274.html) I had suggested the following change: I don't think this is unclear but I could add the following in definitions: Higher Layers A client layer is the one immediately above a server layer. The client layer and all layers above that layer are higher layers. Lower Layers A server layer is the later immediately below a client laer. The server layer and all layers below are lower layers. Do I really need to put this in the definitions section? If yoy think it is necessary, I will add it. You will find this in the quoted text above. The definition of client LSP does not imply that Advanced Multipath is a layer. This also used lower case "multipath" which we can replace with AMG. There is no LAG layer in a network in with MPLS runs over Ethernet and some of the Ethernets use Link Aggregation. > So the model I see defined by the text has the following layers > > Client LSP (layer) > ---------- > Advanced Multipath (layer/solution/construct) > ---------- > Server Layer (composed of AMGs which are LSPs and/or links) > > Is this aligned with your intent? If not, can you explain the > relationship you see for Advanced Multipath Client LSPs and Advanced > Multipath AMGs? You imaginged this model and are trying to constrain the text to fit into it.. Consider these examples of client layer and server layer. plain old rfc-4206 LSP-1 (PSC-0) = client of LSP-2 LSP-2 (PSC-1) = server of LSP-1 LSP over Ethernet over PW over MPLS LSP-1 = client of Ethernet Ethernet = server of LSP-1, client of PW PW = server of Ethernet, client of LSP-2 LSP-2 = server of PW There is then the question of whether Advanced Multipath is a layer or a set of techniques that can be applied at a given layer. Example potential config language: mple { tunnel x1 { type multipath { component tunnel x2; component tunnel x3; [...] component intf i1; component intf i2; [...] } [...] } [...] } No distinct layer above. An alternate: mple { tunnel x1 { [...] } [...] } interface amg1; type multipath { component tunnel x2; component tunnel x3; [...] component intf i1; component intf i2; [...] } [...] } [...] } In the former example, the tunnel x1 is forced to use a specific set of component links and apply multipath techniques to it. In the latter example, if tunnel x1 happen to find that interface amg1 was the lowest cost or otherwise preferred way to get to its destination it makes use of amg1 and if so inherits the use of the multipath techniques. There is no distinct multipath encapsulation at the date layer so some might argue that even in the second case there is no distinct layer, just a configuration convenience. Claiming that Advanced Multipath is of itself a layer may get us into a bigger can of worms. For example in today's ECMP, the next hop consists of multiple interfaces. ECMP is not considered a layer between IP and those interfaces. Link bundle is also not considered a layer. In the document we have not claimed that Advanced Multipath is a type of layer and we have not claimed that Advanced Multipath is not a type of layer. Either way we would get someone arguing that the opposite was true. [Some individuals it seems would pick the opposite of whatever we picked just because they like to argue about layering.] Need I remind you of the painfully long and mostly pointless arguments in MPLS during the early MPLS-TP work about whether an MPLS LSP carried within another hierarchical MPLS LSP was a layer or a sub-layer. We don't want to repeat that and the best way to do so is to not make any statement about whether Advanced Multipath is a layer or a sub-layer or a layering NOOP. Which of the above is the "right" way to do things may be at most a framework issue but may not come up until management plane entities are defined. It is certainly not a topic for a requirements document because it is deep into the "how it gets done". > >> and > >> OLD > >> The above set of requirements apply to component links with different > >> characteristics regardless as to whether those component links are > >> provided by parallel physical links between nodes or provided by sets > >> of paths across a network provided by server layer LSP. > >> NEW > >> The above set of requirements apply to component links with different > >> characteristics regardless as to whether those component links are > >> provided by parallel physical links between nodes or provided by > >> LSPs that are part of an Advanced Multipath Group. > > > > What about PW? Those are paths too by the definition of paths, so > > again, this change makes the definition too narrow. > > > > PWs weren't mentioned in your OLD text, so I didn't add them. I also > have no objections to adding them. Actually the text you wrote is incorrect. "The above requirement applies to component links" can include physical links and server layer LSP but adding that are part of an Advanced Multipath Group is incorrect. I'm not sure but I think this instance of "server layer" was added to that LSP wording because you were confused on last review about client LSP vs LSP over which Advanced Multipath was applied so I went around changing everything to "client LSP" or "server layer LSP" to make it more clear to you. You now seem to be stuck on the wording that is essentially saying "any type of component link" including "server layer LSP". > The only change I made was > s/sets of paths across a network provided by server layer LSP./ > LSPs that are part of an Advanced Multipath Group. And that change was wrong. A more correct change would be s/provided by server layer LSP/including paths provided by server layer LSP/ That would include any sort of path across the network. PW could be considered an emulated physcial link or another usable type of path across the network. The "above set of requirements" in this case have to do with passing down requirements for min latency, bounded latency, and bounded jitter. The original paragraph is: The above set of requirements apply to component links with different characteristics regardless as to whether those component links are provided by parallel physical links between nodes or provided by sets of paths across a network provided by server layer LSP. The intent is "The above set of requirements apply to component links" followed by "regardless of what type of component links they are" where we had disccssed two types being an interface or emulated interface (or virtual interface in some major vendor terms) or an LSP (which is also a virtual interface in some major vendor terms). I don't understand how you can get so hung up on the wording of what is intended to convey "regardless of what type of component links they are". This has always been clear to the WG. > >>> The word "indicate" is independent of the method of getting the > >>> information there. But yes in the example given the IGP advertisement > >>> and MPLS LSP signaling that might be one such mechanism does refer to > >>> the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. > >>> > >>> If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there > >>> is only one IGP flooding information for both client and server layer, > >>> hence the seemingly endless (and mostly pointless) discussion of > >>> sub-layer vs layer from certain ITU people in the MPLS WG mailing list > >>> who viewed MPLS as broken for not enforcing a strict layering in this > >>> regard. But we need not go into that level of detail in this example > >>> of how independent of mechanism the "indicate" is and down that years > >>> old MPLS WG terminology rat hole again. > >>> > >> My comment is that you need to be clear to which layer a requirement > >> applies. Is it the server layer, the client layer or the Advanced > >> Multipath layer? > > > > In each of the requirements you cited it is very clear that the client > > later is communicating a requirement to the server layer, but if you'd > > like I can reword to make that even more clear by rewording of the > > form "SHALL provide a means for the client layer to indicate the > > requirements of a client LSP [regarding X]", where X is minimize > > latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific > > component link (FR#13), bidirection co-routed (FR#14), no reordering > > (FR#15), bounded frequency of rebalance (FR#20). > > Okay, I think this will/may help. My comment goes back to the model I > was asking about above. And to which part of the puzzle the requirement > applies. In some of the above requirements client layer communicated to the server layer, whatever the server layer is. Means of communication presumed to be RSVP-TE but we can't say that until the framework and same capability needs to be available to management plane. In some of the above requirements server layer communicates to the client layer. Means of communication is presumed to be IGP extensions, again with same capability available to management plane. There is no distinct Advanced Multipath layer in control plane or data plane. And if there was a distinct control plane layer it would be defined in a framework, not a requirements document. > >>>>> It would be trivial to make this FR#1 and renumber the rest. > >>>>> > >>>> > >>>> I don't think the FR helped clarify the above question. > >>> > >>> The choice of the word "indicate" in FR10-13, FR14, FR15 does not > >>> imply usage by a specific layer. That is a direct answer to your > >>> question. > >>> > >>> In all of these specific cases, the the client layer is passing a > >>> requirement to the server layer so in the IGP + RSVP-TE world that > >>> would be a function of RSVP-TE. In the absense of control plane, it > >>> would have to be done through management plane interaction where the > >>> client indicates requirements of an LSP and the server layer is free > >>> to figure out how to meet those requirements. > >>> > >>> Do you want me to add the clarification on the use of the word > >>> "indicate" or not? > >> > >> I think you need to be clear that the requirement applies to all three > >> layers. > > > > There are no distinct three layers. You are imagining a model that is > > not used in this document so please don't impose model on our document. > > > > Well your old definition of Client LSP said that it was a client of > "multipath" and else where you say that "multipath" operates over a > server layer. As mentioned above, this sounds like three layers to me. > If this is not your intent, I think you need to make it clear (through > revised text) what model you do intend. This is the current text in -13: Client LSP A client LSP is an LSP which has been set up over a server layer. In the context of this discussion, a client LSP is a LSP which has been set up over a multipath as opposed to an LSP representing the multipath itself or any LSP supporting a component links of that multipath. The text is trying to clarify what a "client LSP" is in the first sentence and then trying to give two cases of what a client LSP is not. This clarification was specifically added *for you* in the last iteration. There was no intention to imply that Advanced Multipath is or is not in of itself a type of layer. If you are getting that notion from this text, then we need to change it. OLD: Client LSP A client LSP is an LSP which has been set up over a server layer. In the context of this discussion, a client LSP is a LSP which has been set up over a multipath as opposed to an LSP representing the multipath itself or any LSP supporting a component links of that multipath. NEW: Client LSP A client LSP is an LSP which has been set up over a set of one or more lower layers. In the context of this discussion, one type of client LSP is a LSP which has been set up over an AMG. We could also add a clarification to the definitions section that states: This document makes no statement on whether Advanced Multipath is itself a layer or whether an instance of AMG is itself a layer. This is to avoid engaging in long and pointless discussions about what consistitutes a proper layer. I would *really* like to add the above statement. > > In your sentence above I have no idea what "the requirement" refers to. > > > > In summary: > > > > We were discussing why the word "indicate" was used to avoid requiring > > specific mechanisms for information passing and I asked if I should > > add the following. > > > > FR#0 In requirements that follow in this document the word > > "indicate" is used where information may be provided by either > > the combination of link state IGP advertisement and MPLS LSP > > signaling or via management plane protocols. In later documents > > providing framework and protocol definitions both signaling and > > management plane mechanisms MUST be defined. > > > > Information is two way. The requirements you cited were all worded in > > the form "The solution SHALL provide a means to indicate that a client > > LSP will ...". So far I have offerred to reword this to the form "The > > solution SHALL provide a means for the client layer to indicate a > > requirement that a client LSP will ..." (ie: get minimum latency, get > > bound latency, etc). > > > > Is adding FR#0 OK? > > > > Do you want this sort of rewording to make it more explicit that the > > client layer is communication a requirement for a specific client LSP? > > > > I think we need to come back to this once we resolve the "model" topic. > > ... > > Thanks, > Lou I hope it is resolved. Curtis From lberger@labn.net Thu Jan 16 18:03:47 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED041ADBD2 for ; Thu, 16 Jan 2014 18:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kTtVurJvwcV for ; Thu, 16 Jan 2014 18:03:43 -0800 (PST) Received: from alt-proxy11.mail.unifiedlayer.com (alt-proxy11.mail.unifiedlayer.com [74.220.211.241]) by ietfa.amsl.com (Postfix) with SMTP id B7A401ADBD0 for ; Thu, 16 Jan 2014 18:03:43 -0800 (PST) Received: (qmail 20364 invoked by uid 0); 17 Jan 2014 02:03:30 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy16.mail.unifiedlayer.com with SMTP; 17 Jan 2014 02:03:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=IS8TV3pNZ+PrDXWBpB5ruPOhg3zHfwRZj8lpajdbQmc=; b=Zh5kxegxlR7NcjHNppCOU/Ehuxs0Vhyt9K+uPpT3HH6D+Cnuq/7N2cd9Zx6ZTpuUkR02EPTt6H1tTZFv8vzrq7TViHSjH51/JgjIkdHv8YXhKw14Vyxs6ZACZDfBMv9M; Received: from box313.bluehost.com ([69.89.31.113]:35186 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1W3ymP-0002FI-Qm; Thu, 16 Jan 2014 19:03:30 -0700 Message-ID: <52D88F77.5020009@labn.net> Date: Thu, 16 Jan 2014 21:03:35 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com Subject: Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 References: <201401160000.s0G006Pk025219@maildrop2.v6ds.occnc.com> In-Reply-To: <201401160000.s0G006Pk025219@maildrop2.v6ds.occnc.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, "rtg-ads@tools.ietf.org" , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 02:03:47 -0000 Curtis, I'm not sure if we're going around in circles or not, but in either case case I think we're getting caught up in the weeds/details. >From a high level perspective, my comments have been motivated by trying to ensure the requirements are unambiguous -- as documented. I think the text changes that have been agreed to so far (notably the use of the capitalized term and introduction of AMG) will help a lot. I think there is still one more area that is unclear, but it's also possible that we're arguing about text that you are planning to change. Do you have a version that captures all the changes to date that you can distribute (or submit, as you choose)? Perhaps looking at this version we'll find that the ambiguity is resolved or is sufficiently narrowed to not be significant. Either way, the discussion can then continue from the most current text. Thanks, Lou On 1/15/2014 7:00 PM, Curtis Villamizar wrote: > In message <52D02F67.9070604@labn.net> > Lou Berger writes: > >> Curtis, >> >> I think we have one disconnect (and corresponding related text) that we >> need to resolve before we can be close the discussion. See below for >> details.. >> >> On 1/8/2014 11:33 PM, Curtis Villamizar wrote: >>> Converging. But maybe one more round trip needed. >>> >>> In message <52CD9D58.4010109@labn.net> >>> Lou Berger writes: >>>> >> ... >> >>>>>>>> 2. Editorial: server and client layer vs upper and lower layer. >>>>>>>> >>>>>>>> The document uses server and client layer networks and LSPs and, >>>>>>>> sometimes interchangeably or redundantly, upper and lower layer networks >>>>>>>> and LSPs. I think this issue can be resolved by avoiding the term >>>>>>>> client/server when referring to network layers and just using the >>>>>>>> lower/upper terminology. The one exception to this is in the definition >>>>>>>> Client LSP which should simply be defined in the context of a multipath, >>>>>>>> i.e.: >>>>>>>> OLD >>>>>>>> A client LSP is an LSP which has been set up over a server layer. >>>>>>>> NEW >>>>>>>> A client LSP is an LSP which has been set up over Advanced Multipath. >>>>>>> >>>>>>> A client LSP can be set up over a server layer MPLS-TP LSP or any >>>>>>> server layer MPLS LSP or over a link layer or over a pseudowire ... or >>>>>>> over an advanced multipath. >>>>>>> >>>>>> >>>>>> Would you accept s/server layer/lower layer/g? >>>>> >>>>> The definition of server layer is not the same as the definition of >>>>> lower layer. See below. >>>>> >>>>>>>> I think this also means that usage of the term "Client" is limited to >>>>>>>> "Client LSP". >>>>>>> >>>>>>> I searched for all occurances of the word client. All occurances are >>>>> />> "client LSP" excexpt the phrase "client of a client LSP" and that is >>>>>>> used only in the following paragraph. >>>>>>> >>>>>>> The ingress and egress of a multipath may be midpoint LSRs with >>>>>>> respect to a given client LSP. A midpoint LSR does not participate >>>>>>> in the signaling of any clients of the client LSP. Therefore, in >>>>>>> general, multipath endpoints cannot determine requirements of clients >>>>>>> of a client LSP through participation in the signaling of the clients >>>>>>> of the client LSP. >>>>>>> >>>>>>> THe point is that "A midpoint LSR does not participate in the >>>>>>> signaling of any clients of the client LSP" and that non-participation >>>>>>> in client (or higher layer) signaling applies to any "client of a >>>>>>> client LSP", not just other LSP running over it. >>>>>>> >>>>>>> I then searched for all occurances of the words upper and lower and >>>>>>> higher. There are no occurances of "upper". >>>>>>> >>>>>>> There were a few occurances of "lower latency" and "higher latency". >>>>>>> Other than that, all occurances of lower and higher except one are in >>>>>>> the follwoing text: >>>>>>> >>>>>>> 3.2. Component Links Provided by Lower Layer Networks >>>>>>> >>>>>>> A component link may be supported by a lower layer network. For >>>>>>> example, the lower layer may be a circuit switched network or another >>>>>>> MPLS network (e.g., MPLS-TP)). The lower layer network may change >>>>>>> the latency (and/or other performance parameters) seen by the client >>>>>>> layer. Currently, there is no protocol for the lower layer network >>>>>>> to inform the higher layer network of a change in a performance >>>>>>> parameter. Communication of the latency performance parameter is a >>>>>>> very important requirement. Communication of other performance >>>>>>> parameters (e.g., delay variation) is desirable. >>>>>>> >>>>>>> FR#8 The solution SHALL specify a protocol means to allow a lower >>>>>>> layer server network to communicate latency to the higher layer >>>>>>> client network. >>>>>>> >>>>>>> The exception is this sentence: >>>>>>> >>>>>>> FR#22 The solution SHOULD support the use case where an advanced >>>>>>> multipath itself is a component link for a higher order advanced >>>>>>> multipath. For example, an advanced multipath comprised of MPLS- >>>>>>> TP bi-directional tunnels viewed as logical links could then be >>>>>>> used as a component link in yet another advanced multipath that >>>>>>> connects MPLS routers. >>>>>>> >>>>>>> The terms lower layer and higher layer go all the way back to the ISO >>>>>>> seven layer model of ancient times (1970s?, 1980s?) and maybe further >>>>>>> back but that is before even my time. >>>>>>> >>>>>>> I don't think this is unclear but I could add the following in >>>>>>> definitions: >>>>>>> >>>>>>> Higher Layers >>>>>>> A client layer is the one immediately above a server layer. The >>>>>>> client layer and all layers above that layer are higher layers. >>>>>>> >>>>>>> Lower Layers >>>>>>> A server layer is the later immediately below a client laer. >>>>>>> The server layer and all layers below are lower layers. >>>>>>> >>>>>>> Do I really need to put this in the definitions section? If yoy think >>>>>>> it is necessary, I will add it. >>>>>>> >>>>>> Perhaps we've talked (okay written) past each other. I was suggesting >>>>>> using/keeping the "higher and lower layer" terminology, not dropping it. >>>>>> And to use it (consistently) in place of "client and server Layer". >>>>> >>>>> I guess you missed the distinction in the definition above: >>>>> >>>>> For layer X layer Y is: >>>>> >>>>> client layer === Y = X+1 >>>>> server layer === Y = X-1 >>>>> higher layer === Y > X >>>>> lower layer === Y < X >>>>> >>>>> So the definition client layer is not the same as the definition of >>>>> higher layer. The definition of server layer is not the same as the >>>>> definition of lower layer. >>>>> >>>>> In some discussions we really do mean "the server layer" and not any >>>>> layer at any arbitrary depth below this one. >>>> >>>> I read your usage of client/server layer to be synonymous with >>>> higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense >>>> of FR#8 (I think you really mean client layer not lower layer.) >>> >>> FR#8 and FR#9 are about the server layer telling the client layer >>> about the delays that can be expected. There is a little redundancy >>> here so s/ower layer server network/server network/ and >>> s/higher layer client network/client network/. No plans to skip >>> layers. >>> >> >> I think we need to hit the points below before this one... > > OK. > >>>> Given the current document usage, I still think it makes sense to >>>> eliminate the two instances of "client layer": How about the following: >>>> OLD >>>> Client LSP >>>> A client LSP is an LSP which has been set up over a server layer. >>>> In the context of this discussion, a client LSP is a LSP which >>>> has been set up over a multipath as opposed to an LSP >>>> representing the multipath itself or any LSP supporting a >>>> component links of that multipath. >>>> NEW >>>> Client LSP >>>> A client LSP is a LSP which >>>> has been set up over Advanced Multipath as opposed to an LSP >>>> representing the Advanced Multipath itself or any LSP that is >>>> part of an Advanced Multipath Group. >>> >>> Nope. In general, a client LSP can be set up over a plain old >>> Ethernet on a given hop, therefore the second definition is too >>> narrow with this change. >>> >> >> humm, you didn't have that in your OLD text. In fact, the old text >> reads to me that an Advanced Multipath (solution?) logically sits >> between a client LSP and an underlying server layer in all cases. > > The "OLD" was a quote from you and it was the original text in -13. I > said "Nope. ..." to your suggested change to it in this way. > > Earlier > (http://www.ietf.org/mail-archive/web/rtgwg/current/msg04274.html) I > had suggested the following change: > > I don't think this is unclear but I could add the following in > definitions: > > Higher Layers > A client layer is the one immediately above a server layer. The > client layer and all layers above that layer are higher layers. > > Lower Layers > A server layer is the later immediately below a client laer. > The server layer and all layers below are lower layers. > > Do I really need to put this in the definitions section? If yoy think > it is necessary, I will add it. > > You will find this in the quoted text above. > > The definition of client LSP does not imply that Advanced Multipath is > a layer. This also used lower case "multipath" which we can replace > with AMG. There is no LAG layer in a network in with MPLS runs over > Ethernet and some of the Ethernets use Link Aggregation. > >> So the model I see defined by the text has the following layers >> >> Client LSP (layer) >> ---------- >> Advanced Multipath (layer/solution/construct) >> ---------- >> Server Layer (composed of AMGs which are LSPs and/or links) >> >> Is this aligned with your intent? If not, can you explain the >> relationship you see for Advanced Multipath Client LSPs and Advanced >> Multipath AMGs? > > You imaginged this model and are trying to constrain the text to fit > into it.. > > Consider these examples of client layer and server layer. > > plain old rfc-4206 > > LSP-1 (PSC-0) = client of LSP-2 > LSP-2 (PSC-1) = server of LSP-1 > > LSP over Ethernet over PW over MPLS > > LSP-1 = client of Ethernet > Ethernet = server of LSP-1, client of PW > PW = server of Ethernet, client of LSP-2 > LSP-2 = server of PW > > There is then the question of whether Advanced Multipath is a layer or > a set of techniques that can be applied at a given layer. Example > potential config language: > > mple { > tunnel x1 { > type multipath { > component tunnel x2; > component tunnel x3; > [...] > component intf i1; > component intf i2; > [...] > } > [...] > } > [...] > } > > No distinct layer above. > > An alternate: > > mple { > tunnel x1 { > [...] > } > [...] > } > > interface amg1; > type multipath { > component tunnel x2; > component tunnel x3; > [...] > component intf i1; > component intf i2; > [...] > } > [...] > } > [...] > } > > In the former example, the tunnel x1 is forced to use a specific set > of component links and apply multipath techniques to it. > > In the latter example, if tunnel x1 happen to find that interface amg1 > was the lowest cost or otherwise preferred way to get to its > destination it makes use of amg1 and if so inherits the use of the > multipath techniques. > > There is no distinct multipath encapsulation at the date layer so some > might argue that even in the second case there is no distinct layer, > just a configuration convenience. > > Claiming that Advanced Multipath is of itself a layer may get us into > a bigger can of worms. > > For example in today's ECMP, the next hop consists of multiple > interfaces. ECMP is not considered a layer between IP and those > interfaces. Link bundle is also not considered a layer. > > In the document we have not claimed that Advanced Multipath is a type > of layer and we have not claimed that Advanced Multipath is not a type > of layer. Either way we would get someone arguing that the opposite > was true. [Some individuals it seems would pick the opposite of > whatever we picked just because they like to argue about layering.] > > Need I remind you of the painfully long and mostly pointless arguments > in MPLS during the early MPLS-TP work about whether an MPLS LSP > carried within another hierarchical MPLS LSP was a layer or a > sub-layer. We don't want to repeat that and the best way to do so is > to not make any statement about whether Advanced Multipath is a layer > or a sub-layer or a layering NOOP. > > Which of the above is the "right" way to do things may be at most a > framework issue but may not come up until management plane entities > are defined. It is certainly not a topic for a requirements document > because it is deep into the "how it gets done". > >>>> and >>>> OLD >>>> The above set of requirements apply to component links with different >>>> characteristics regardless as to whether those component links are >>>> provided by parallel physical links between nodes or provided by sets >>>> of paths across a network provided by server layer LSP. >>>> NEW >>>> The above set of requirements apply to component links with different >>>> characteristics regardless as to whether those component links are >>>> provided by parallel physical links between nodes or provided by >>>> LSPs that are part of an Advanced Multipath Group. >>> >>> What about PW? Those are paths too by the definition of paths, so >>> again, this change makes the definition too narrow. >>> >> >> PWs weren't mentioned in your OLD text, so I didn't add them. I also >> have no objections to adding them. > > Actually the text you wrote is incorrect. "The above requirement > applies to component links" can include physical links and server > layer LSP but adding that are part of an Advanced Multipath Group is > incorrect. > > I'm not sure but I think this instance of "server layer" was added to > that LSP wording because you were confused on last review about client > LSP vs LSP over which Advanced Multipath was applied so I went around > changing everything to "client LSP" or "server layer LSP" to make it > more clear to you. You now seem to be stuck on the wording that is > essentially saying "any type of component link" including "server > layer LSP". > >> The only change I made was >> s/sets of paths across a network provided by server layer LSP./ >> LSPs that are part of an Advanced Multipath Group. > > And that change was wrong. A more correct change would be > > s/provided by server layer LSP/including paths provided by server > layer LSP/ > > That would include any sort of path across the network. PW could be > considered an emulated physcial link or another usable type of path > across the network. > > The "above set of requirements" in this case have to do with passing > down requirements for min latency, bounded latency, and bounded > jitter. The original paragraph is: > > The above set of requirements apply to component links with > different characteristics regardless as to whether those component > links are provided by parallel physical links between nodes or > provided by sets of paths across a network provided by server layer > LSP. > > The intent is "The above set of requirements apply to component links" > followed by "regardless of what type of component links they are" > where we had disccssed two types being an interface or emulated > interface (or virtual interface in some major vendor terms) or an LSP > (which is also a virtual interface in some major vendor terms). > > I don't understand how you can get so hung up on the wording of what > is intended to convey "regardless of what type of component links they > are". This has always been clear to the WG. > >>>>> The word "indicate" is independent of the method of getting the >>>>> information there. But yes in the example given the IGP advertisement >>>>> and MPLS LSP signaling that might be one such mechanism does refer to >>>>> the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. >>>>> >>>>> If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there >>>>> is only one IGP flooding information for both client and server layer, >>>>> hence the seemingly endless (and mostly pointless) discussion of >>>>> sub-layer vs layer from certain ITU people in the MPLS WG mailing list >>>>> who viewed MPLS as broken for not enforcing a strict layering in this >>>>> regard. But we need not go into that level of detail in this example >>>>> of how independent of mechanism the "indicate" is and down that years >>>>> old MPLS WG terminology rat hole again. >>>>> >>>> My comment is that you need to be clear to which layer a requirement >>>> applies. Is it the server layer, the client layer or the Advanced >>>> Multipath layer? >>> >>> In each of the requirements you cited it is very clear that the client >>> later is communicating a requirement to the server layer, but if you'd >>> like I can reword to make that even more clear by rewording of the >>> form "SHALL provide a means for the client layer to indicate the >>> requirements of a client LSP [regarding X]", where X is minimize >>> latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific >>> component link (FR#13), bidirection co-routed (FR#14), no reordering >>> (FR#15), bounded frequency of rebalance (FR#20). >> >> Okay, I think this will/may help. My comment goes back to the model I >> was asking about above. And to which part of the puzzle the requirement >> applies. > > In some of the above requirements client layer communicated to the > server layer, whatever the server layer is. Means of communication > presumed to be RSVP-TE but we can't say that until the framework and > same capability needs to be available to management plane. > > In some of the above requirements server layer communicates to the > client layer. Means of communication is presumed to be IGP > extensions, again with same capability available to management plane. > > There is no distinct Advanced Multipath layer in control plane or data > plane. And if there was a distinct control plane layer it would be > defined in a framework, not a requirements document. > >>>>>>> It would be trivial to make this FR#1 and renumber the rest. >>>>>>> >>>>>> >>>>>> I don't think the FR helped clarify the above question. >>>>> >>>>> The choice of the word "indicate" in FR10-13, FR14, FR15 does not >>>>> imply usage by a specific layer. That is a direct answer to your >>>>> question. >>>>> >>>>> In all of these specific cases, the the client layer is passing a >>>>> requirement to the server layer so in the IGP + RSVP-TE world that >>>>> would be a function of RSVP-TE. In the absense of control plane, it >>>>> would have to be done through management plane interaction where the >>>>> client indicates requirements of an LSP and the server layer is free >>>>> to figure out how to meet those requirements. >>>>> >>>>> Do you want me to add the clarification on the use of the word >>>>> "indicate" or not? >>>> >>>> I think you need to be clear that the requirement applies to all three >>>> layers. >>> >>> There are no distinct three layers. You are imagining a model that is >>> not used in this document so please don't impose model on our document. >>> >> >> Well your old definition of Client LSP said that it was a client of >> "multipath" and else where you say that "multipath" operates over a >> server layer. As mentioned above, this sounds like three layers to me. >> If this is not your intent, I think you need to make it clear (through >> revised text) what model you do intend. > > This is the current text in -13: > > Client LSP > A client LSP is an LSP which has been set up over a server layer. > In the context of this discussion, a client LSP is a LSP which > has been set up over a multipath as opposed to an LSP > representing the multipath itself or any LSP supporting a > component links of that multipath. > > The text is trying to clarify what a "client LSP" is in the first > sentence and then trying to give two cases of what a client LSP is > not. This clarification was specifically added *for you* in the last > iteration. > > There was no intention to imply that Advanced Multipath is or is not > in of itself a type of layer. If you are getting that notion from > this text, then we need to change it. > > OLD: > > Client LSP > A client LSP is an LSP which has been set up over a server layer. > In the context of this discussion, a client LSP is a LSP which > has been set up over a multipath as opposed to an LSP > representing the multipath itself or any LSP supporting a > component links of that multipath. > > NEW: > > Client LSP > > A client LSP is an LSP which has been set up over a set of one > or more lower layers. In the context of this discussion, one > type of client LSP is a LSP which has been set up over an AMG. > > We could also add a clarification to the definitions section that > states: > > This document makes no statement on whether Advanced Multipath is > itself a layer or whether an instance of AMG is itself a layer. > This is to avoid engaging in long and pointless discussions about > what consistitutes a proper layer. > > I would *really* like to add the above statement. > >>> In your sentence above I have no idea what "the requirement" refers to. >>> >>> In summary: >>> >>> We were discussing why the word "indicate" was used to avoid requiring >>> specific mechanisms for information passing and I asked if I should >>> add the following. >>> >>> FR#0 In requirements that follow in this document the word >>> "indicate" is used where information may be provided by either >>> the combination of link state IGP advertisement and MPLS LSP >>> signaling or via management plane protocols. In later documents >>> providing framework and protocol definitions both signaling and >>> management plane mechanisms MUST be defined. >>> >>> Information is two way. The requirements you cited were all worded in >>> the form "The solution SHALL provide a means to indicate that a client >>> LSP will ...". So far I have offerred to reword this to the form "The >>> solution SHALL provide a means for the client layer to indicate a >>> requirement that a client LSP will ..." (ie: get minimum latency, get >>> bound latency, etc). >>> >>> Is adding FR#0 OK? >>> >>> Do you want this sort of rewording to make it more explicit that the >>> client layer is communication a requirement for a specific client LSP? >>> >> >> I think we need to come back to this once we resolve the "model" topic. >> >> ... >> >> Thanks, >> Lou > > I hope it is resolved. > > Curtis > > > > From internet-drafts@ietf.org Fri Jan 17 05:49:32 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899241AE0CA; Fri, 17 Jan 2014 05:49:32 -0800 (PST) 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 BFt5cysvTCZJ; Fri, 17 Jan 2014 05:49:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D78171AE0CD; Fri, 17 Jan 2014 05:49:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-mofrr-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140117134926.12032.29545.idtracker@ietfa.amsl.com> Date: Fri, 17 Jan 2014 05:49:26 -0800 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 13:49:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Multicast only Fast Re-Route Authors : Apoorva Karan Clarence Filsfils Dino Farinacci IJsbrand Wijnands Bruno Decraene Uwe Joorde Wim Henderickx Filename : draft-ietf-rtgwg-mofrr-03.txt Pages : 14 Date : 2014-01-17 Abstract: As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services. This draft describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast only Fast Re- Route (MoFRR) works by making simple enhancements to multicast routing protocols such as PIM and mLDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mofrr/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-mofrr-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-mofrr-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From curtis@ipv6.occnc.com Fri Jan 17 09:41:25 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B8F1A1F4C; Fri, 17 Jan 2014 09:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtJ0x9UC7z_2; Fri, 17 Jan 2014 09:41:21 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8B71A16F0; Fri, 17 Jan 2014 09:41:21 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0HHf6sb063221; Fri, 17 Jan 2014 12:41:06 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401171741.s0HHf6sb063221@maildrop2.v6ds.occnc.com> To: Lou Berger From: Curtis Villamizar Subject: Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 In-reply-to: Your message of "Thu, 16 Jan 2014 21:03:35 -0500." <52D88F77.5020009@labn.net> Date: Fri, 17 Jan 2014 12:41:06 -0500 Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, rtgwg@ietf.org, "rtg-ads@tools.ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 17:41:25 -0000 In message <52D88F77.5020009@labn.net> Lou Berger writes: > Curtis, > I'm not sure if we're going around in circles or not, but in either > case case I think we're getting caught up in the weeds/details. > > >From a high level perspective, my comments have been motivated by trying > to ensure the requirements are unambiguous -- as documented. I think > the text changes that have been agreed to so far (notably the use of the > capitalized term and introduction of AMG) will help a lot. I think there > is still one more area that is unclear, but it's also possible that > we're arguing about text that you are planning to change. > > Do you have a version that captures all the changes to date that you can > distribute (or submit, as you choose)? Perhaps looking at this version > we'll find that the ambiguity is resolved or is sufficiently narrowed to > not be significant. Either way, the discussion can then continue from > the most current text. > > Thanks, > Lou Lou, I was going to suggest the same (if I understand your suggestion) - that is that a new draft be submitted and you (and others) can review and see if clarity has been sufficiently improved or if there are still issues with clarity. If that is OK with you and compatible with this process I will make two draft submissions back to back. One with just the OpsDir review comments addressed and a second with your comments so far addressed. IMHO it would be easier to discuss the clarity (or lack of) of the wording once changes have been made particularly since there are a few s/old/new/g terminology suggestions in the email thread. Curtis > On 1/15/2014 7:00 PM, Curtis Villamizar wrote: > > In message <52D02F67.9070604@labn.net> > > Lou Berger writes: > > > >> Curtis, > >> > >> I think we have one disconnect (and corresponding related text) that we > >> need to resolve before we can be close the discussion. See below for > >> details.. > >> > >> On 1/8/2014 11:33 PM, Curtis Villamizar wrote: > >>> Converging. But maybe one more round trip needed. > >>> > >>> In message <52CD9D58.4010109@labn.net> > >>> Lou Berger writes: > >>>> > >> ... > >> > >>>>>>>> 2. Editorial: server and client layer vs upper and lower layer. > >>>>>>>> > >>>>>>>> The document uses server and client layer networks and LSPs and, > >>>>>>>> sometimes interchangeably or redundantly, upper and lower layer networks > >>>>>>>> and LSPs. I think this issue can be resolved by avoiding the term > >>>>>>>> client/server when referring to network layers and just using the > >>>>>>>> lower/upper terminology. The one exception to this is in the definition > >>>>>>>> Client LSP which should simply be defined in the context of a multipath, > >>>>>>>> i.e.: > >>>>>>>> OLD > >>>>>>>> A client LSP is an LSP which has been set up over a server layer. > >>>>>>>> NEW > >>>>>>>> A client LSP is an LSP which has been set up over Advanced Multipath. > >>>>>>> > >>>>>>> A client LSP can be set up over a server layer MPLS-TP LSP or any > >>>>>>> server layer MPLS LSP or over a link layer or over a pseudowire ... or > >>>>>>> over an advanced multipath. > >>>>>>> > >>>>>> > >>>>>> Would you accept s/server layer/lower layer/g? > >>>>> > >>>>> The definition of server layer is not the same as the definition of > >>>>> lower layer. See below. > >>>>> > >>>>>>>> I think this also means that usage of the term "Client" is limited to > >>>>>>>> "Client LSP". > >>>>>>> > >>>>>>> I searched for all occurances of the word client. All occurances are > >>>>> />> "client LSP" excexpt the phrase "client of a client LSP" and that is > >>>>>>> used only in the following paragraph. > >>>>>>> > >>>>>>> The ingress and egress of a multipath may be midpoint LSRs with > >>>>>>> respect to a given client LSP. A midpoint LSR does not participate > >>>>>>> in the signaling of any clients of the client LSP. Therefore, in > >>>>>>> general, multipath endpoints cannot determine requirements of clients > >>>>>>> of a client LSP through participation in the signaling of the clients > >>>>>>> of the client LSP. > >>>>>>> > >>>>>>> THe point is that "A midpoint LSR does not participate in the > >>>>>>> signaling of any clients of the client LSP" and that non-participation > >>>>>>> in client (or higher layer) signaling applies to any "client of a > >>>>>>> client LSP", not just other LSP running over it. > >>>>>>> > >>>>>>> I then searched for all occurances of the words upper and lower and > >>>>>>> higher. There are no occurances of "upper". > >>>>>>> > >>>>>>> There were a few occurances of "lower latency" and "higher latency". > >>>>>>> Other than that, all occurances of lower and higher except one are in > >>>>>>> the follwoing text: > >>>>>>> > >>>>>>> 3.2. Component Links Provided by Lower Layer Networks > >>>>>>> > >>>>>>> A component link may be supported by a lower layer network. For > >>>>>>> example, the lower layer may be a circuit switched network or another > >>>>>>> MPLS network (e.g., MPLS-TP)). The lower layer network may change > >>>>>>> the latency (and/or other performance parameters) seen by the client > >>>>>>> layer. Currently, there is no protocol for the lower layer network > >>>>>>> to inform the higher layer network of a change in a performance > >>>>>>> parameter. Communication of the latency performance parameter is a > >>>>>>> very important requirement. Communication of other performance > >>>>>>> parameters (e.g., delay variation) is desirable. > >>>>>>> > >>>>>>> FR#8 The solution SHALL specify a protocol means to allow a lower > >>>>>>> layer server network to communicate latency to the higher layer > >>>>>>> client network. > >>>>>>> > >>>>>>> The exception is this sentence: > >>>>>>> > >>>>>>> FR#22 The solution SHOULD support the use case where an advanced > >>>>>>> multipath itself is a component link for a higher order advanced > >>>>>>> multipath. For example, an advanced multipath comprised of MPLS- > >>>>>>> TP bi-directional tunnels viewed as logical links could then be > >>>>>>> used as a component link in yet another advanced multipath that > >>>>>>> connects MPLS routers. > >>>>>>> > >>>>>>> The terms lower layer and higher layer go all the way back to the ISO > >>>>>>> seven layer model of ancient times (1970s?, 1980s?) and maybe further > >>>>>>> back but that is before even my time. > >>>>>>> > >>>>>>> I don't think this is unclear but I could add the following in > >>>>>>> definitions: > >>>>>>> > >>>>>>> Higher Layers > >>>>>>> A client layer is the one immediately above a server layer. The > >>>>>>> client layer and all layers above that layer are higher layers. > >>>>>>> > >>>>>>> Lower Layers > >>>>>>> A server layer is the later immediately below a client laer. > >>>>>>> The server layer and all layers below are lower layers. > >>>>>>> > >>>>>>> Do I really need to put this in the definitions section? If yoy think > >>>>>>> it is necessary, I will add it. > >>>>>>> > >>>>>> Perhaps we've talked (okay written) past each other. I was suggesting > >>>>>> using/keeping the "higher and lower layer" terminology, not dropping it. > >>>>>> And to use it (consistently) in place of "client and server Layer". > >>>>> > >>>>> I guess you missed the distinction in the definition above: > >>>>> > >>>>> For layer X layer Y is: > >>>>> > >>>>> client layer === Y = X+1 > >>>>> server layer === Y = X-1 > >>>>> higher layer === Y > X > >>>>> lower layer === Y < X > >>>>> > >>>>> So the definition client layer is not the same as the definition of > >>>>> higher layer. The definition of server layer is not the same as the > >>>>> definition of lower layer. > >>>>> > >>>>> In some discussions we really do mean "the server layer" and not any > >>>>> layer at any arbitrary depth below this one. > >>>> > >>>> I read your usage of client/server layer to be synonymous with > >>>> higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense > >>>> of FR#8 (I think you really mean client layer not lower layer.) > >>> > >>> FR#8 and FR#9 are about the server layer telling the client layer > >>> about the delays that can be expected. There is a little redundancy > >>> here so s/ower layer server network/server network/ and > >>> s/higher layer client network/client network/. No plans to skip > >>> layers. > >>> > >> > >> I think we need to hit the points below before this one... > > > > OK. > > > >>>> Given the current document usage, I still think it makes sense to > >>>> eliminate the two instances of "client layer": How about the following: > >>>> OLD > >>>> Client LSP > >>>> A client LSP is an LSP which has been set up over a server layer. > >>>> In the context of this discussion, a client LSP is a LSP which > >>>> has been set up over a multipath as opposed to an LSP > >>>> representing the multipath itself or any LSP supporting a > >>>> component links of that multipath. > >>>> NEW > >>>> Client LSP > >>>> A client LSP is a LSP which > >>>> has been set up over Advanced Multipath as opposed to an LSP > >>>> representing the Advanced Multipath itself or any LSP that is > >>>> part of an Advanced Multipath Group. > >>> > >>> Nope. In general, a client LSP can be set up over a plain old > >>> Ethernet on a given hop, therefore the second definition is too > >>> narrow with this change. > >>> > >> > >> humm, you didn't have that in your OLD text. In fact, the old text > >> reads to me that an Advanced Multipath (solution?) logically sits > >> between a client LSP and an underlying server layer in all cases. > > > > The "OLD" was a quote from you and it was the original text in -13. I > > said "Nope. ..." to your suggested change to it in this way. > > > > Earlier > > (http://www.ietf.org/mail-archive/web/rtgwg/current/msg04274.html) I > > had suggested the following change: > > > > I don't think this is unclear but I could add the following in > > definitions: > > > > Higher Layers > > A client layer is the one immediately above a server layer. The > > client layer and all layers above that layer are higher layers. > > > > Lower Layers > > A server layer is the later immediately below a client laer. > > The server layer and all layers below are lower layers. > > > > Do I really need to put this in the definitions section? If yoy think > > it is necessary, I will add it. > > > > You will find this in the quoted text above. > > > > The definition of client LSP does not imply that Advanced Multipath is > > a layer. This also used lower case "multipath" which we can replace > > with AMG. There is no LAG layer in a network in with MPLS runs over > > Ethernet and some of the Ethernets use Link Aggregation. > > > >> So the model I see defined by the text has the following layers > >> > >> Client LSP (layer) > >> ---------- > >> Advanced Multipath (layer/solution/construct) > >> ---------- > >> Server Layer (composed of AMGs which are LSPs and/or links) > >> > >> Is this aligned with your intent? If not, can you explain the > >> relationship you see for Advanced Multipath Client LSPs and Advanced > >> Multipath AMGs? > > > > You imaginged this model and are trying to constrain the text to fit > > into it.. > > > > Consider these examples of client layer and server layer. > > > > plain old rfc-4206 > > > > LSP-1 (PSC-0) = client of LSP-2 > > LSP-2 (PSC-1) = server of LSP-1 > > > > LSP over Ethernet over PW over MPLS > > > > LSP-1 = client of Ethernet > > Ethernet = server of LSP-1, client of PW > > PW = server of Ethernet, client of LSP-2 > > LSP-2 = server of PW > > > > There is then the question of whether Advanced Multipath is a layer or > > a set of techniques that can be applied at a given layer. Example > > potential config language: > > > > mple { > > tunnel x1 { > > type multipath { > > component tunnel x2; > > component tunnel x3; > > [...] > > component intf i1; > > component intf i2; > > [...] > > } > > [...] > > } > > [...] > > } > > > > No distinct layer above. > > > > An alternate: > > > > mple { > > tunnel x1 { > > [...] > > } > > [...] > > } > > > > interface amg1; > > type multipath { > > component tunnel x2; > > component tunnel x3; > > [...] > > component intf i1; > > component intf i2; > > [...] > > } > > [...] > > } > > [...] > > } > > > > In the former example, the tunnel x1 is forced to use a specific set > > of component links and apply multipath techniques to it. > > > > In the latter example, if tunnel x1 happen to find that interface amg1 > > was the lowest cost or otherwise preferred way to get to its > > destination it makes use of amg1 and if so inherits the use of the > > multipath techniques. > > > > There is no distinct multipath encapsulation at the date layer so some > > might argue that even in the second case there is no distinct layer, > > just a configuration convenience. > > > > Claiming that Advanced Multipath is of itself a layer may get us into > > a bigger can of worms. > > > > For example in today's ECMP, the next hop consists of multiple > > interfaces. ECMP is not considered a layer between IP and those > > interfaces. Link bundle is also not considered a layer. > > > > In the document we have not claimed that Advanced Multipath is a type > > of layer and we have not claimed that Advanced Multipath is not a type > > of layer. Either way we would get someone arguing that the opposite > > was true. [Some individuals it seems would pick the opposite of > > whatever we picked just because they like to argue about layering.] > > > > Need I remind you of the painfully long and mostly pointless arguments > > in MPLS during the early MPLS-TP work about whether an MPLS LSP > > carried within another hierarchical MPLS LSP was a layer or a > > sub-layer. We don't want to repeat that and the best way to do so is > > to not make any statement about whether Advanced Multipath is a layer > > or a sub-layer or a layering NOOP. > > > > Which of the above is the "right" way to do things may be at most a > > framework issue but may not come up until management plane entities > > are defined. It is certainly not a topic for a requirements document > > because it is deep into the "how it gets done". > > > >>>> and > >>>> OLD > >>>> The above set of requirements apply to component links with different > >>>> characteristics regardless as to whether those component links are > >>>> provided by parallel physical links between nodes or provided by sets > >>>> of paths across a network provided by server layer LSP. > >>>> NEW > >>>> The above set of requirements apply to component links with different > >>>> characteristics regardless as to whether those component links are > >>>> provided by parallel physical links between nodes or provided by > >>>> LSPs that are part of an Advanced Multipath Group. > >>> > >>> What about PW? Those are paths too by the definition of paths, so > >>> again, this change makes the definition too narrow. > >>> > >> > >> PWs weren't mentioned in your OLD text, so I didn't add them. I also > >> have no objections to adding them. > > > > Actually the text you wrote is incorrect. "The above requirement > > applies to component links" can include physical links and server > > layer LSP but adding that are part of an Advanced Multipath Group is > > incorrect. > > > > I'm not sure but I think this instance of "server layer" was added to > > that LSP wording because you were confused on last review about client > > LSP vs LSP over which Advanced Multipath was applied so I went around > > changing everything to "client LSP" or "server layer LSP" to make it > > more clear to you. You now seem to be stuck on the wording that is > > essentially saying "any type of component link" including "server > > layer LSP". > > > >> The only change I made was > >> s/sets of paths across a network provided by server layer LSP./ > >> LSPs that are part of an Advanced Multipath Group. > > > > And that change was wrong. A more correct change would be > > > > s/provided by server layer LSP/including paths provided by server > > layer LSP/ > > > > That would include any sort of path across the network. PW could be > > considered an emulated physcial link or another usable type of path > > across the network. > > > > The "above set of requirements" in this case have to do with passing > > down requirements for min latency, bounded latency, and bounded > > jitter. The original paragraph is: > > > > The above set of requirements apply to component links with > > different characteristics regardless as to whether those component > > links are provided by parallel physical links between nodes or > > provided by sets of paths across a network provided by server layer > > LSP. > > > > The intent is "The above set of requirements apply to component links" > > followed by "regardless of what type of component links they are" > > where we had disccssed two types being an interface or emulated > > interface (or virtual interface in some major vendor terms) or an LSP > > (which is also a virtual interface in some major vendor terms). > > > > I don't understand how you can get so hung up on the wording of what > > is intended to convey "regardless of what type of component links they > > are". This has always been clear to the WG. > > > >>>>> The word "indicate" is independent of the method of getting the > >>>>> information there. But yes in the example given the IGP advertisement > >>>>> and MPLS LSP signaling that might be one such mechanism does refer to > >>>>> the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. > >>>>> > >>>>> If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there > >>>>> is only one IGP flooding information for both client and server layer, > >>>>> hence the seemingly endless (and mostly pointless) discussion of > >>>>> sub-layer vs layer from certain ITU people in the MPLS WG mailing list > >>>>> who viewed MPLS as broken for not enforcing a strict layering in this > >>>>> regard. But we need not go into that level of detail in this example > >>>>> of how independent of mechanism the "indicate" is and down that years > >>>>> old MPLS WG terminology rat hole again. > >>>>> > >>>> My comment is that you need to be clear to which layer a requirement > >>>> applies. Is it the server layer, the client layer or the Advanced > >>>> Multipath layer? > >>> > >>> In each of the requirements you cited it is very clear that the client > >>> later is communicating a requirement to the server layer, but if you'd > >>> like I can reword to make that even more clear by rewording of the > >>> form "SHALL provide a means for the client layer to indicate the > >>> requirements of a client LSP [regarding X]", where X is minimize > >>> latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific > >>> component link (FR#13), bidirection co-routed (FR#14), no reordering > >>> (FR#15), bounded frequency of rebalance (FR#20). > >> > >> Okay, I think this will/may help. My comment goes back to the model I > >> was asking about above. And to which part of the puzzle the requirement > >> applies. > > > > In some of the above requirements client layer communicated to the > > server layer, whatever the server layer is. Means of communication > > presumed to be RSVP-TE but we can't say that until the framework and > > same capability needs to be available to management plane. > > > > In some of the above requirements server layer communicates to the > > client layer. Means of communication is presumed to be IGP > > extensions, again with same capability available to management plane. > > > > There is no distinct Advanced Multipath layer in control plane or data > > plane. And if there was a distinct control plane layer it would be > > defined in a framework, not a requirements document. > > > >>>>>>> It would be trivial to make this FR#1 and renumber the rest. > >>>>>>> > >>>>>> > >>>>>> I don't think the FR helped clarify the above question. > >>>>> > >>>>> The choice of the word "indicate" in FR10-13, FR14, FR15 does not > >>>>> imply usage by a specific layer. That is a direct answer to your > >>>>> question. > >>>>> > >>>>> In all of these specific cases, the the client layer is passing a > >>>>> requirement to the server layer so in the IGP + RSVP-TE world that > >>>>> would be a function of RSVP-TE. In the absense of control plane, it > >>>>> would have to be done through management plane interaction where the > >>>>> client indicates requirements of an LSP and the server layer is free > >>>>> to figure out how to meet those requirements. > >>>>> > >>>>> Do you want me to add the clarification on the use of the word > >>>>> "indicate" or not? > >>>> > >>>> I think you need to be clear that the requirement applies to all three > >>>> layers. > >>> > >>> There are no distinct three layers. You are imagining a model that is > >>> not used in this document so please don't impose model on our document. > >>> > >> > >> Well your old definition of Client LSP said that it was a client of > >> "multipath" and else where you say that "multipath" operates over a > >> server layer. As mentioned above, this sounds like three layers to me. > >> If this is not your intent, I think you need to make it clear (through > >> revised text) what model you do intend. > > > > This is the current text in -13: > > > > Client LSP > > A client LSP is an LSP which has been set up over a server layer. > > In the context of this discussion, a client LSP is a LSP which > > has been set up over a multipath as opposed to an LSP > > representing the multipath itself or any LSP supporting a > > component links of that multipath. > > > > The text is trying to clarify what a "client LSP" is in the first > > sentence and then trying to give two cases of what a client LSP is > > not. This clarification was specifically added *for you* in the last > > iteration. > > > > There was no intention to imply that Advanced Multipath is or is not > > in of itself a type of layer. If you are getting that notion from > > this text, then we need to change it. > > > > OLD: > > > > Client LSP > > A client LSP is an LSP which has been set up over a server layer. > > In the context of this discussion, a client LSP is a LSP which > > has been set up over a multipath as opposed to an LSP > > representing the multipath itself or any LSP supporting a > > component links of that multipath. > > > > NEW: > > > > Client LSP > > > > A client LSP is an LSP which has been set up over a set of one > > or more lower layers. In the context of this discussion, one > > type of client LSP is a LSP which has been set up over an AMG. > > > > We could also add a clarification to the definitions section that > > states: > > > > This document makes no statement on whether Advanced Multipath is > > itself a layer or whether an instance of AMG is itself a layer. > > This is to avoid engaging in long and pointless discussions about > > what consistitutes a proper layer. > > > > I would *really* like to add the above statement. > > > >>> In your sentence above I have no idea what "the requirement" refers to. > >>> > >>> In summary: > >>> > >>> We were discussing why the word "indicate" was used to avoid requiring > >>> specific mechanisms for information passing and I asked if I should > >>> add the following. > >>> > >>> FR#0 In requirements that follow in this document the word > >>> "indicate" is used where information may be provided by either > >>> the combination of link state IGP advertisement and MPLS LSP > >>> signaling or via management plane protocols. In later documents > >>> providing framework and protocol definitions both signaling and > >>> management plane mechanisms MUST be defined. > >>> > >>> Information is two way. The requirements you cited were all worded in > >>> the form "The solution SHALL provide a means to indicate that a client > >>> LSP will ...". So far I have offerred to reword this to the form "The > >>> solution SHALL provide a means for the client layer to indicate a > >>> requirement that a client LSP will ..." (ie: get minimum latency, get > >>> bound latency, etc). > >>> > >>> Is adding FR#0 OK? > >>> > >>> Do you want this sort of rewording to make it more explicit that the > >>> client layer is communication a requirement for a specific client LSP? > >>> > >> > >> I think we need to come back to this once we resolve the "model" topic. > >> > >> ... > >> > >> Thanks, > >> Lou > > > > I hope it is resolved. > > > > Curtis From lberger@labn.net Fri Jan 17 10:01:52 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33451A16F0 for ; Fri, 17 Jan 2014 10:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] 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 ZNAd9FlEi_1i for ; Fri, 17 Jan 2014 10:01:49 -0800 (PST) Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 5E1211AC421 for ; Fri, 17 Jan 2014 10:01:49 -0800 (PST) Received: (qmail 22138 invoked by uid 0); 18 Jan 2014 01:01:34 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.mail.unifiedlayer.com with SMTP; 18 Jan 2014 01:01:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=bhaNjsj70kZ0NGIA25t8OOVu+0dOk72/AYTaC9/EvUg=; b=egvK/QZeHDtBZI4TYDnPkcSDm7uzlJhETUhedtfQPCnCdZioSm0j9IBJ/xlvw8AaFsAS6OqW/xIxszyn95vF108k87CBXp5FOVZsLp1WTwixpR4sDe4o8RcmQU2Qqxuu; Received: from box313.bluehost.com ([69.89.31.113]:52546 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1W4Djc-0005YA-Fv; Fri, 17 Jan 2014 11:01:36 -0700 Message-ID: <52D96FFD.1020408@labn.net> Date: Fri, 17 Jan 2014 13:01:33 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com Subject: Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 References: <201401171741.s0HHf6sb063221@maildrop2.v6ds.occnc.com> In-Reply-To: <201401171741.s0HHf6sb063221@maildrop2.v6ds.occnc.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, "rtg-ads@tools.ietf.org" , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 18:01:52 -0000 sounds like a plan! Lou On 01/17/2014 12:41 PM, Curtis Villamizar wrote: > In message <52D88F77.5020009@labn.net> > Lou Berger writes: > >> Curtis, >> I'm not sure if we're going around in circles or not, but in either >> case case I think we're getting caught up in the weeds/details. >> >> >From a high level perspective, my comments have been motivated by trying >> to ensure the requirements are unambiguous -- as documented. I think >> the text changes that have been agreed to so far (notably the use of the >> capitalized term and introduction of AMG) will help a lot. I think there >> is still one more area that is unclear, but it's also possible that >> we're arguing about text that you are planning to change. >> >> Do you have a version that captures all the changes to date that you can >> distribute (or submit, as you choose)? Perhaps looking at this version >> we'll find that the ambiguity is resolved or is sufficiently narrowed to >> not be significant. Either way, the discussion can then continue from >> the most current text. >> >> Thanks, >> Lou > > > Lou, > > I was going to suggest the same (if I understand your suggestion) - > that is that a new draft be submitted and you (and others) can review > and see if clarity has been sufficiently improved or if there are > still issues with clarity. > > If that is OK with you and compatible with this process I will make > two draft submissions back to back. One with just the OpsDir review > comments addressed and a second with your comments so far addressed. > IMHO it would be easier to discuss the clarity (or lack of) of the > wording once changes have been made particularly since there are a few > s/old/new/g terminology suggestions in the email thread. > > Curtis > > >> On 1/15/2014 7:00 PM, Curtis Villamizar wrote: >>> In message <52D02F67.9070604@labn.net> >>> Lou Berger writes: >>> >>>> Curtis, >>>> >>>> I think we have one disconnect (and corresponding related text) that we >>>> need to resolve before we can be close the discussion. See below for >>>> details.. >>>> >>>> On 1/8/2014 11:33 PM, Curtis Villamizar wrote: >>>>> Converging. But maybe one more round trip needed. >>>>> >>>>> In message <52CD9D58.4010109@labn.net> >>>>> Lou Berger writes: >>>>>> >>>> ... >>>> >>>>>>>>>> 2. Editorial: server and client layer vs upper and lower layer. >>>>>>>>>> >>>>>>>>>> The document uses server and client layer networks and LSPs and, >>>>>>>>>> sometimes interchangeably or redundantly, upper and lower layer networks >>>>>>>>>> and LSPs. I think this issue can be resolved by avoiding the term >>>>>>>>>> client/server when referring to network layers and just using the >>>>>>>>>> lower/upper terminology. The one exception to this is in the definition >>>>>>>>>> Client LSP which should simply be defined in the context of a multipath, >>>>>>>>>> i.e.: >>>>>>>>>> OLD >>>>>>>>>> A client LSP is an LSP which has been set up over a server layer. >>>>>>>>>> NEW >>>>>>>>>> A client LSP is an LSP which has been set up over Advanced Multipath. >>>>>>>>> >>>>>>>>> A client LSP can be set up over a server layer MPLS-TP LSP or any >>>>>>>>> server layer MPLS LSP or over a link layer or over a pseudowire ... or >>>>>>>>> over an advanced multipath. >>>>>>>>> >>>>>>>> >>>>>>>> Would you accept s/server layer/lower layer/g? >>>>>>> >>>>>>> The definition of server layer is not the same as the definition of >>>>>>> lower layer. See below. >>>>>>> >>>>>>>>>> I think this also means that usage of the term "Client" is limited to >>>>>>>>>> "Client LSP". >>>>>>>>> >>>>>>>>> I searched for all occurances of the word client. All occurances are >>>>>>> />> "client LSP" excexpt the phrase "client of a client LSP" and that is >>>>>>>>> used only in the following paragraph. >>>>>>>>> >>>>>>>>> The ingress and egress of a multipath may be midpoint LSRs with >>>>>>>>> respect to a given client LSP. A midpoint LSR does not participate >>>>>>>>> in the signaling of any clients of the client LSP. Therefore, in >>>>>>>>> general, multipath endpoints cannot determine requirements of clients >>>>>>>>> of a client LSP through participation in the signaling of the clients >>>>>>>>> of the client LSP. >>>>>>>>> >>>>>>>>> THe point is that "A midpoint LSR does not participate in the >>>>>>>>> signaling of any clients of the client LSP" and that non-participation >>>>>>>>> in client (or higher layer) signaling applies to any "client of a >>>>>>>>> client LSP", not just other LSP running over it. >>>>>>>>> >>>>>>>>> I then searched for all occurances of the words upper and lower and >>>>>>>>> higher. There are no occurances of "upper". >>>>>>>>> >>>>>>>>> There were a few occurances of "lower latency" and "higher latency". >>>>>>>>> Other than that, all occurances of lower and higher except one are in >>>>>>>>> the follwoing text: >>>>>>>>> >>>>>>>>> 3.2. Component Links Provided by Lower Layer Networks >>>>>>>>> >>>>>>>>> A component link may be supported by a lower layer network. For >>>>>>>>> example, the lower layer may be a circuit switched network or another >>>>>>>>> MPLS network (e.g., MPLS-TP)). The lower layer network may change >>>>>>>>> the latency (and/or other performance parameters) seen by the client >>>>>>>>> layer. Currently, there is no protocol for the lower layer network >>>>>>>>> to inform the higher layer network of a change in a performance >>>>>>>>> parameter. Communication of the latency performance parameter is a >>>>>>>>> very important requirement. Communication of other performance >>>>>>>>> parameters (e.g., delay variation) is desirable. >>>>>>>>> >>>>>>>>> FR#8 The solution SHALL specify a protocol means to allow a lower >>>>>>>>> layer server network to communicate latency to the higher layer >>>>>>>>> client network. >>>>>>>>> >>>>>>>>> The exception is this sentence: >>>>>>>>> >>>>>>>>> FR#22 The solution SHOULD support the use case where an advanced >>>>>>>>> multipath itself is a component link for a higher order advanced >>>>>>>>> multipath. For example, an advanced multipath comprised of MPLS- >>>>>>>>> TP bi-directional tunnels viewed as logical links could then be >>>>>>>>> used as a component link in yet another advanced multipath that >>>>>>>>> connects MPLS routers. >>>>>>>>> >>>>>>>>> The terms lower layer and higher layer go all the way back to the ISO >>>>>>>>> seven layer model of ancient times (1970s?, 1980s?) and maybe further >>>>>>>>> back but that is before even my time. >>>>>>>>> >>>>>>>>> I don't think this is unclear but I could add the following in >>>>>>>>> definitions: >>>>>>>>> >>>>>>>>> Higher Layers >>>>>>>>> A client layer is the one immediately above a server layer. The >>>>>>>>> client layer and all layers above that layer are higher layers. >>>>>>>>> >>>>>>>>> Lower Layers >>>>>>>>> A server layer is the later immediately below a client laer. >>>>>>>>> The server layer and all layers below are lower layers. >>>>>>>>> >>>>>>>>> Do I really need to put this in the definitions section? If yoy think >>>>>>>>> it is necessary, I will add it. >>>>>>>>> >>>>>>>> Perhaps we've talked (okay written) past each other. I was suggesting >>>>>>>> using/keeping the "higher and lower layer" terminology, not dropping it. >>>>>>>> And to use it (consistently) in place of "client and server Layer". >>>>>>> >>>>>>> I guess you missed the distinction in the definition above: >>>>>>> >>>>>>> For layer X layer Y is: >>>>>>> >>>>>>> client layer === Y = X+1 >>>>>>> server layer === Y = X-1 >>>>>>> higher layer === Y > X >>>>>>> lower layer === Y < X >>>>>>> >>>>>>> So the definition client layer is not the same as the definition of >>>>>>> higher layer. The definition of server layer is not the same as the >>>>>>> definition of lower layer. >>>>>>> >>>>>>> In some discussions we really do mean "the server layer" and not any >>>>>>> layer at any arbitrary depth below this one. >>>>>> >>>>>> I read your usage of client/server layer to be synonymous with >>>>>> higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense >>>>>> of FR#8 (I think you really mean client layer not lower layer.) >>>>> >>>>> FR#8 and FR#9 are about the server layer telling the client layer >>>>> about the delays that can be expected. There is a little redundancy >>>>> here so s/ower layer server network/server network/ and >>>>> s/higher layer client network/client network/. No plans to skip >>>>> layers. >>>>> >>>> >>>> I think we need to hit the points below before this one... >>> >>> OK. >>> >>>>>> Given the current document usage, I still think it makes sense to >>>>>> eliminate the two instances of "client layer": How about the following: >>>>>> OLD >>>>>> Client LSP >>>>>> A client LSP is an LSP which has been set up over a server layer. >>>>>> In the context of this discussion, a client LSP is a LSP which >>>>>> has been set up over a multipath as opposed to an LSP >>>>>> representing the multipath itself or any LSP supporting a >>>>>> component links of that multipath. >>>>>> NEW >>>>>> Client LSP >>>>>> A client LSP is a LSP which >>>>>> has been set up over Advanced Multipath as opposed to an LSP >>>>>> representing the Advanced Multipath itself or any LSP that is >>>>>> part of an Advanced Multipath Group. >>>>> >>>>> Nope. In general, a client LSP can be set up over a plain old >>>>> Ethernet on a given hop, therefore the second definition is too >>>>> narrow with this change. >>>>> >>>> >>>> humm, you didn't have that in your OLD text. In fact, the old text >>>> reads to me that an Advanced Multipath (solution?) logically sits >>>> between a client LSP and an underlying server layer in all cases. >>> >>> The "OLD" was a quote from you and it was the original text in -13. I >>> said "Nope. ..." to your suggested change to it in this way. >>> >>> Earlier >>> (http://www.ietf.org/mail-archive/web/rtgwg/current/msg04274.html) I >>> had suggested the following change: >>> >>> I don't think this is unclear but I could add the following in >>> definitions: >>> >>> Higher Layers >>> A client layer is the one immediately above a server layer. The >>> client layer and all layers above that layer are higher layers. >>> >>> Lower Layers >>> A server layer is the later immediately below a client laer. >>> The server layer and all layers below are lower layers. >>> >>> Do I really need to put this in the definitions section? If yoy think >>> it is necessary, I will add it. >>> >>> You will find this in the quoted text above. >>> >>> The definition of client LSP does not imply that Advanced Multipath is >>> a layer. This also used lower case "multipath" which we can replace >>> with AMG. There is no LAG layer in a network in with MPLS runs over >>> Ethernet and some of the Ethernets use Link Aggregation. >>> >>>> So the model I see defined by the text has the following layers >>>> >>>> Client LSP (layer) >>>> ---------- >>>> Advanced Multipath (layer/solution/construct) >>>> ---------- >>>> Server Layer (composed of AMGs which are LSPs and/or links) >>>> >>>> Is this aligned with your intent? If not, can you explain the >>>> relationship you see for Advanced Multipath Client LSPs and Advanced >>>> Multipath AMGs? >>> >>> You imaginged this model and are trying to constrain the text to fit >>> into it.. >>> >>> Consider these examples of client layer and server layer. >>> >>> plain old rfc-4206 >>> >>> LSP-1 (PSC-0) = client of LSP-2 >>> LSP-2 (PSC-1) = server of LSP-1 >>> >>> LSP over Ethernet over PW over MPLS >>> >>> LSP-1 = client of Ethernet >>> Ethernet = server of LSP-1, client of PW >>> PW = server of Ethernet, client of LSP-2 >>> LSP-2 = server of PW >>> >>> There is then the question of whether Advanced Multipath is a layer or >>> a set of techniques that can be applied at a given layer. Example >>> potential config language: >>> >>> mple { >>> tunnel x1 { >>> type multipath { >>> component tunnel x2; >>> component tunnel x3; >>> [...] >>> component intf i1; >>> component intf i2; >>> [...] >>> } >>> [...] >>> } >>> [...] >>> } >>> >>> No distinct layer above. >>> >>> An alternate: >>> >>> mple { >>> tunnel x1 { >>> [...] >>> } >>> [...] >>> } >>> >>> interface amg1; >>> type multipath { >>> component tunnel x2; >>> component tunnel x3; >>> [...] >>> component intf i1; >>> component intf i2; >>> [...] >>> } >>> [...] >>> } >>> [...] >>> } >>> >>> In the former example, the tunnel x1 is forced to use a specific set >>> of component links and apply multipath techniques to it. >>> >>> In the latter example, if tunnel x1 happen to find that interface amg1 >>> was the lowest cost or otherwise preferred way to get to its >>> destination it makes use of amg1 and if so inherits the use of the >>> multipath techniques. >>> >>> There is no distinct multipath encapsulation at the date layer so some >>> might argue that even in the second case there is no distinct layer, >>> just a configuration convenience. >>> >>> Claiming that Advanced Multipath is of itself a layer may get us into >>> a bigger can of worms. >>> >>> For example in today's ECMP, the next hop consists of multiple >>> interfaces. ECMP is not considered a layer between IP and those >>> interfaces. Link bundle is also not considered a layer. >>> >>> In the document we have not claimed that Advanced Multipath is a type >>> of layer and we have not claimed that Advanced Multipath is not a type >>> of layer. Either way we would get someone arguing that the opposite >>> was true. [Some individuals it seems would pick the opposite of >>> whatever we picked just because they like to argue about layering.] >>> >>> Need I remind you of the painfully long and mostly pointless arguments >>> in MPLS during the early MPLS-TP work about whether an MPLS LSP >>> carried within another hierarchical MPLS LSP was a layer or a >>> sub-layer. We don't want to repeat that and the best way to do so is >>> to not make any statement about whether Advanced Multipath is a layer >>> or a sub-layer or a layering NOOP. >>> >>> Which of the above is the "right" way to do things may be at most a >>> framework issue but may not come up until management plane entities >>> are defined. It is certainly not a topic for a requirements document >>> because it is deep into the "how it gets done". >>> >>>>>> and >>>>>> OLD >>>>>> The above set of requirements apply to component links with different >>>>>> characteristics regardless as to whether those component links are >>>>>> provided by parallel physical links between nodes or provided by sets >>>>>> of paths across a network provided by server layer LSP. >>>>>> NEW >>>>>> The above set of requirements apply to component links with different >>>>>> characteristics regardless as to whether those component links are >>>>>> provided by parallel physical links between nodes or provided by >>>>>> LSPs that are part of an Advanced Multipath Group. >>>>> >>>>> What about PW? Those are paths too by the definition of paths, so >>>>> again, this change makes the definition too narrow. >>>>> >>>> >>>> PWs weren't mentioned in your OLD text, so I didn't add them. I also >>>> have no objections to adding them. >>> >>> Actually the text you wrote is incorrect. "The above requirement >>> applies to component links" can include physical links and server >>> layer LSP but adding that are part of an Advanced Multipath Group is >>> incorrect. >>> >>> I'm not sure but I think this instance of "server layer" was added to >>> that LSP wording because you were confused on last review about client >>> LSP vs LSP over which Advanced Multipath was applied so I went around >>> changing everything to "client LSP" or "server layer LSP" to make it >>> more clear to you. You now seem to be stuck on the wording that is >>> essentially saying "any type of component link" including "server >>> layer LSP". >>> >>>> The only change I made was >>>> s/sets of paths across a network provided by server layer LSP./ >>>> LSPs that are part of an Advanced Multipath Group. >>> >>> And that change was wrong. A more correct change would be >>> >>> s/provided by server layer LSP/including paths provided by server >>> layer LSP/ >>> >>> That would include any sort of path across the network. PW could be >>> considered an emulated physcial link or another usable type of path >>> across the network. >>> >>> The "above set of requirements" in this case have to do with passing >>> down requirements for min latency, bounded latency, and bounded >>> jitter. The original paragraph is: >>> >>> The above set of requirements apply to component links with >>> different characteristics regardless as to whether those component >>> links are provided by parallel physical links between nodes or >>> provided by sets of paths across a network provided by server layer >>> LSP. >>> >>> The intent is "The above set of requirements apply to component links" >>> followed by "regardless of what type of component links they are" >>> where we had disccssed two types being an interface or emulated >>> interface (or virtual interface in some major vendor terms) or an LSP >>> (which is also a virtual interface in some major vendor terms). >>> >>> I don't understand how you can get so hung up on the wording of what >>> is intended to convey "regardless of what type of component links they >>> are". This has always been clear to the WG. >>> >>>>>>> The word "indicate" is independent of the method of getting the >>>>>>> information there. But yes in the example given the IGP advertisement >>>>>>> and MPLS LSP signaling that might be one such mechanism does refer to >>>>>>> the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. >>>>>>> >>>>>>> If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there >>>>>>> is only one IGP flooding information for both client and server layer, >>>>>>> hence the seemingly endless (and mostly pointless) discussion of >>>>>>> sub-layer vs layer from certain ITU people in the MPLS WG mailing list >>>>>>> who viewed MPLS as broken for not enforcing a strict layering in this >>>>>>> regard. But we need not go into that level of detail in this example >>>>>>> of how independent of mechanism the "indicate" is and down that years >>>>>>> old MPLS WG terminology rat hole again. >>>>>>> >>>>>> My comment is that you need to be clear to which layer a requirement >>>>>> applies. Is it the server layer, the client layer or the Advanced >>>>>> Multipath layer? >>>>> >>>>> In each of the requirements you cited it is very clear that the client >>>>> later is communicating a requirement to the server layer, but if you'd >>>>> like I can reword to make that even more clear by rewording of the >>>>> form "SHALL provide a means for the client layer to indicate the >>>>> requirements of a client LSP [regarding X]", where X is minimize >>>>> latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific >>>>> component link (FR#13), bidirection co-routed (FR#14), no reordering >>>>> (FR#15), bounded frequency of rebalance (FR#20). >>>> >>>> Okay, I think this will/may help. My comment goes back to the model I >>>> was asking about above. And to which part of the puzzle the requirement >>>> applies. >>> >>> In some of the above requirements client layer communicated to the >>> server layer, whatever the server layer is. Means of communication >>> presumed to be RSVP-TE but we can't say that until the framework and >>> same capability needs to be available to management plane. >>> >>> In some of the above requirements server layer communicates to the >>> client layer. Means of communication is presumed to be IGP >>> extensions, again with same capability available to management plane. >>> >>> There is no distinct Advanced Multipath layer in control plane or data >>> plane. And if there was a distinct control plane layer it would be >>> defined in a framework, not a requirements document. >>> >>>>>>>>> It would be trivial to make this FR#1 and renumber the rest. >>>>>>>>> >>>>>>>> >>>>>>>> I don't think the FR helped clarify the above question. >>>>>>> >>>>>>> The choice of the word "indicate" in FR10-13, FR14, FR15 does not >>>>>>> imply usage by a specific layer. That is a direct answer to your >>>>>>> question. >>>>>>> >>>>>>> In all of these specific cases, the the client layer is passing a >>>>>>> requirement to the server layer so in the IGP + RSVP-TE world that >>>>>>> would be a function of RSVP-TE. In the absense of control plane, it >>>>>>> would have to be done through management plane interaction where the >>>>>>> client indicates requirements of an LSP and the server layer is free >>>>>>> to figure out how to meet those requirements. >>>>>>> >>>>>>> Do you want me to add the clarification on the use of the word >>>>>>> "indicate" or not? >>>>>> >>>>>> I think you need to be clear that the requirement applies to all three >>>>>> layers. >>>>> >>>>> There are no distinct three layers. You are imagining a model that is >>>>> not used in this document so please don't impose model on our document. >>>>> >>>> >>>> Well your old definition of Client LSP said that it was a client of >>>> "multipath" and else where you say that "multipath" operates over a >>>> server layer. As mentioned above, this sounds like three layers to me. >>>> If this is not your intent, I think you need to make it clear (through >>>> revised text) what model you do intend. >>> >>> This is the current text in -13: >>> >>> Client LSP >>> A client LSP is an LSP which has been set up over a server layer. >>> In the context of this discussion, a client LSP is a LSP which >>> has been set up over a multipath as opposed to an LSP >>> representing the multipath itself or any LSP supporting a >>> component links of that multipath. >>> >>> The text is trying to clarify what a "client LSP" is in the first >>> sentence and then trying to give two cases of what a client LSP is >>> not. This clarification was specifically added *for you* in the last >>> iteration. >>> >>> There was no intention to imply that Advanced Multipath is or is not >>> in of itself a type of layer. If you are getting that notion from >>> this text, then we need to change it. >>> >>> OLD: >>> >>> Client LSP >>> A client LSP is an LSP which has been set up over a server layer. >>> In the context of this discussion, a client LSP is a LSP which >>> has been set up over a multipath as opposed to an LSP >>> representing the multipath itself or any LSP supporting a >>> component links of that multipath. >>> >>> NEW: >>> >>> Client LSP >>> >>> A client LSP is an LSP which has been set up over a set of one >>> or more lower layers. In the context of this discussion, one >>> type of client LSP is a LSP which has been set up over an AMG. >>> >>> We could also add a clarification to the definitions section that >>> states: >>> >>> This document makes no statement on whether Advanced Multipath is >>> itself a layer or whether an instance of AMG is itself a layer. >>> This is to avoid engaging in long and pointless discussions about >>> what consistitutes a proper layer. >>> >>> I would *really* like to add the above statement. >>> >>>>> In your sentence above I have no idea what "the requirement" refers to. >>>>> >>>>> In summary: >>>>> >>>>> We were discussing why the word "indicate" was used to avoid requiring >>>>> specific mechanisms for information passing and I asked if I should >>>>> add the following. >>>>> >>>>> FR#0 In requirements that follow in this document the word >>>>> "indicate" is used where information may be provided by either >>>>> the combination of link state IGP advertisement and MPLS LSP >>>>> signaling or via management plane protocols. In later documents >>>>> providing framework and protocol definitions both signaling and >>>>> management plane mechanisms MUST be defined. >>>>> >>>>> Information is two way. The requirements you cited were all worded in >>>>> the form "The solution SHALL provide a means to indicate that a client >>>>> LSP will ...". So far I have offerred to reword this to the form "The >>>>> solution SHALL provide a means for the client layer to indicate a >>>>> requirement that a client LSP will ..." (ie: get minimum latency, get >>>>> bound latency, etc). >>>>> >>>>> Is adding FR#0 OK? >>>>> >>>>> Do you want this sort of rewording to make it more explicit that the >>>>> client layer is communication a requirement for a specific client LSP? >>>>> >>>> >>>> I think we need to come back to this once we resolve the "model" topic. >>>> >>>> ... >>>> >>>> Thanks, >>>> Lou >>> >>> I hope it is resolved. >>> >>> Curtis > From internet-drafts@ietf.org Wed Jan 22 05:02:19 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C731A03ED; Wed, 22 Jan 2014 05:02:19 -0800 (PST) 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 LhojH9YF_HZD; Wed, 22 Jan 2014 05:02:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 737411A00CD; Wed, 22 Jan 2014 05:02:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140122130217.15321.92624.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2014 05:02:17 -0800 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 13:02:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Operational management of Loop Free Alternates Authors : Stephane Litkowski Bruno Decraene Clarence Filsfils Kamran Raza Martin Horneffer Pushpasis Sarkar Filename : draft-ietf-rtgwg-lfa-manageability-01.txt Pages : 21 Date : 2014-01-22 Abstract: Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic (and MPLS LDP traffic by extension). Following first deployment experiences, this document provides operational feedback on LFA, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. This proposal is also applicable to remote LFA solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-lfa-manageability-01 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 maik.pfeil@gmail.com Wed Jan 22 06:07:20 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD1F1A0236 for ; Wed, 22 Jan 2014 06:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] 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 m9GGKVBDRkKY for ; Wed, 22 Jan 2014 06:07:19 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id C93941A00D6 for ; Wed, 22 Jan 2014 06:07:18 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ld10so424607pab.24 for ; Wed, 22 Jan 2014 06:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=yhh4kt9xk0j8NPs9tCumLdU0e/Qwir4iQUNPB2qhxeY=; b=DjXTtvQ1IZk9vOvpcLOVj7AHSe2OMcf/8EzhwEyy6zmePfghuraiO9F+PXy95dhVJ6 J4qvQyrbTbTHy9Ib0w+RdICzsAnQy7Dsxg41Y1zOq3TILtP0tu9Swx0NDPHoHaTexo3P TNYhj3Jq5CQpIn3II6yCZSPGgqvc4V8OB3Fuj5jI2Jp2xv5SAmKprJMuL4YkW2pgoRgN kp3jd9L1rAz9pKctRRQ/z6L9DTB96rtHVI+kOp2kStKm1CtNRXrJb21MYUfh4oSrDu8g 8gEtaFhTg3MZGmCoPggW3jwtjYtpb0wYGJOM1KVx85J6Dr7vPfyeT+jXuYzAXfu7KVab FBRA== MIME-Version: 1.0 X-Received: by 10.66.102.4 with SMTP id fk4mr1766872pab.59.1390399638388; Wed, 22 Jan 2014 06:07:18 -0800 (PST) Received: by 10.68.128.72 with HTTP; Wed, 22 Jan 2014 06:07:18 -0800 (PST) In-Reply-To: <20140122130217.15321.92624.idtracker@ietfa.amsl.com> References: <20140122130217.15321.92624.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2014 22:07:18 +0800 Message-ID: Subject: Re: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt From: Maik Pfeil Cc: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=047d7bd8fb488ac59304f08fa458 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 14:07:20 -0000 --047d7bd8fb488ac59304f08fa458 Content-Type: text/plain; charset=ISO-8859-1 Hi, as stated in section 4.2 To enhance such situation, an implementation SHOULD support triggering/activating LFA Fast Reroute for a given link when a manual shutdown is done. The triggering of a FRR could also happen by BFD in some implementations. The last sentence should be more generalized or even get more details. What exactly should a "shutdown" trigger? For e.g. a tx-laser off on local side -> triggers LFA on remote side. // Maik 2014/1/22 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Area Working Group Working Group > of the IETF. > > Title : Operational management of Loop Free Alternates > Authors : Stephane Litkowski > Bruno Decraene > Clarence Filsfils > Kamran Raza > Martin Horneffer > Pushpasis Sarkar > Filename : draft-ietf-rtgwg-lfa-manageability-01.txt > Pages : 21 > Date : 2014-01-22 > > Abstract: > Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast > ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic > (and MPLS LDP traffic by extension). Following first deployment > experiences, this document provides operational feedback on LFA, > highlights some limitations, and proposes a set of refinements to > address those limitations. It also proposes required management > specifications. > > This proposal is also applicable to remote LFA solution. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-lfa-manageability-01 > > > 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/ > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --047d7bd8fb488ac59304f08fa458 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

as stated in section 4.2
= <snip>
 To enhance such situation, an implem=
entation SHOULD
   support triggering/activating LFA Fast Reroute for a given link when
   a manual shutdown is done.
</snip>

The triggering of a FRR could also happen by BFD i=
n some implementations. The last sentence should be more generalized or eve=
n get more details. What exactly should a "shutdown" trigger? For=
 e.g. a tx-laser off on local side -> triggers LFA on remote side. 



// Maik





2014/1/22 <internet-drafts@ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Routing Area Working Group Working Grou= p of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Operational management of Loop = Free Alternates
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Stephane Litkowski
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bruno Decraene
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Clarence Filsfils
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kamran Raza
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Martin Horneffer
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Pushpasis Sarkar
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-rtgwg-lfa-manageabilit= y-01.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 21
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-01-22

Abstract:
=A0 =A0Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast
=A0 =A0ReRoute (IP FRR) mechanism enabling traffic protection for IP traffi= c
=A0 =A0(and MPLS LDP traffic by extension). =A0Following first deployment =A0 =A0experiences, this document provides operational feedback on LFA,
=A0 =A0highlights some limitations, and proposes a set of refinements to =A0 =A0address those limitations. =A0It also proposes required management =A0 =A0specifications.

=A0 =A0This proposal is also applicable to remote LFA solution.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-l= fa-manageability/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-managea= bility-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-r= tgwg-lfa-manageability-01


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg

--047d7bd8fb488ac59304f08fa458-- From stephane.litkowski@orange.com Wed Jan 22 06:22:13 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F3F1A00DF for ; Wed, 22 Jan 2014 06:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 DAuMn8Tt4WuW for ; Wed, 22 Jan 2014 06:22:11 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF0B1A00DD for ; Wed, 22 Jan 2014 06:22:11 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id E75241B81BF; Wed, 22 Jan 2014 15:22:09 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id CBBCF180051; Wed, 22 Jan 2014 15:22:09 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.46]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 22 Jan 2014 15:22:09 +0100 From: To: Maik Pfeil Date: Wed, 22 Jan 2014 15:22:08 +0100 Subject: RE: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt Thread-Index: Ac8Xe0cz4blWJRgLQ1WlxPDayMGB9wAAfmiQ Message-ID: <21858_1390400529_52DFD411_21858_11329_1_EEE55384044474429A926C625D0FCC8109A1A59A5C@PUEXCB2F.nanterre.francetelecom.fr> References: <20140122130217.15321.92624.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC8109A1A59A5CPUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.22.60016 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 14:22:14 -0000 --_000_EEE55384044474429A926C625D0FCC8109A1A59A5CPUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agree, I will clarify with more details. De : rtgwg [mailto:rtgwg-bounces@ietf.org] De la part de Maik Pfeil Envoy=E9 : mercredi 22 janvier 2014 15:07 Cc : rtgwg@ietf.org Objet : Re: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt Hi, as stated in section 4.2 To enhance such situation, an implementation SHOULD support triggering/activating LFA Fast Reroute for a given link when a manual shutdown is done. The triggering of a FRR could also happen by BFD in some implementations. T= he last sentence should be more generalized or even get more details. What = exactly should a "shutdown" trigger? For e.g. a tx-laser off on local side = -> triggers LFA on remote side. // Maik 2014/1/22 > A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Operational management of Loop Free Alternates Authors : Stephane Litkowski Bruno Decraene Clarence Filsfils Kamran Raza Martin Horneffer Pushpasis Sarkar Filename : draft-ietf-rtgwg-lfa-manageability-01.txt Pages : 21 Date : 2014-01-22 Abstract: Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic (and MPLS LDP traffic by extension). Following first deployment experiences, this document provides operational feedback on LFA, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. This proposal is also applicable to remote LFA solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-lfa-manageability-01 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/ _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC8109A1A59A5CPUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Agree,=

 

I will clarify with more details.

 

 

 

De : rtgwg [mailto:rtgwg-bounces@ietf.org] De l= a part de Maik Pfeil
Envoy=E9 : mercredi 22 janvier 2014= 15:07
Cc : rtgwg@ietf.org
Objet : Re: I-D Ac= tion: draft-ietf-rtgwg-lfa-manageability-01.txt

 

Hi,

 

as stated in section 4.2

<snip>

 To enhance such situation, an implementation SHOULD=

=A0=A0=
 support triggering/activating LFA Fast Reroute for a given link when<=
/o:p>
=A0=A0 =
a manual shutdown is done.
</snip>
 
 
The triggering of a FRR coul= d also happen by BFD in some implementations. The last sentence should be m= ore generalized or even get more details. What exactly should a "shutd= own" trigger? For e.g. a tx-laser off on local side -> triggers LFA= on remote side. 
 
 
 
// Maik
 
 
 
 

 

2014/1/22 <internet-drafts@ietf.org>


A New Internet-Draft is avail= able from the on-line Internet-Drafts directories.
 This draft is a= work item of the Routing Area Working Group Working Group of the IETF.
=
        Title           : = Operational management of Loop Free Alternates
      &nbs= p; Authors         : Stephane Litkowski
   = ;                     &nb= sp; Bruno Decraene
              &nbs= p;           Clarence Filsfils
    &n= bsp;                     = Kamran Raza
                &nbs= p;         Martin Horneffer
      &nb= sp;                   Pushpasi= s Sarkar
        Filename        = ;: draft-ietf-rtgwg-lfa-manageability-01.txt
       = Pages           : 21
      &nbs= p; Date            : 2014-01-22

Abstra= ct:
   Loop Free Alternates (LFA), as defined in RFC 5286 is a= n IP Fast
   ReRoute (IP FRR) mechanism enabling traffic prote= ction for IP traffic
   (and MPLS LDP traffic by extension). &= nbsp;Following first deployment
   experiences, this document = provides operational feedback on LFA,
   highlights some limit= ations, and proposes a set of refinements to
   address those = limitations.  It also proposes required management
   spe= cifications.

   This proposal is also applicable to remote= LFA solution.



The IETF datatracker status page for this dra= ft is:
https://datatracker.ietf.org/doc/draft-ie= tf-rtgwg-lfa-manageability/

There's also a htmlized version avai= lable at:
http://tools.ietf.org/html/draft-ietf-rtgw= g-lfa-manageability-01

A diff from the previous version is avail= able at:
http://www.ietf.org/rfcdiff?url2=3D= draft-ietf-rtgwg-lfa-manageability-01


Please note that it ma= y take a couple of minutes from the time of submission
until the htmlize= d version and diff are available at tools.ietf.org.

Internet-Drafts are also available = by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_____________= __________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listin= fo/rtgwg

 

= 
__________________________________________________________=
_______________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_EEE55384044474429A926C625D0FCC8109A1A59A5CPUEXCB2Fnante_-- From akatlas@gmail.com Wed Jan 22 13:41:20 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A647E1A0390 for ; Wed, 22 Jan 2014 13:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_Jlao78-Ndy for ; Wed, 22 Jan 2014 13:41:19 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id E17BD1A0383 for ; Wed, 22 Jan 2014 13:41:18 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id ar20so162196iec.24 for ; Wed, 22 Jan 2014 13:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mVB7SHvlkOxEKpbaMUHtbG030S4Pf60g5pYHqcGCcvs=; b=bmhW7MNJqIVs4GwfISEx4HQZ0Zfad6Uvrh+C69FBvmiVIOG2EXfGkzerSc0gYb7yoy 5UBRKhINQ7LlW0FZl+Sy4MrzyxepSGA8ewWETvp71gepaYUcQ0BI8lcxnpsMjcm86VVZ a+PvJ3ZrFr71tOi8oilplqB8Vo4sc7Rc4wUuE2WUGbOa9JpDavP8Lz++0eiBWl0G8cjv 1MKU0FAmBrZBqg72otPrhrE7zPaVrq5yNszgbPojqdmdVevv3fOo4gWMHYVO9YP6eC57 DZHAU62EoZ6fcEZsVrBjEtfcD68zGpOxC4nCLztW46RSFvIElBlVl9No8G66KjNcpm0B jE4A== MIME-Version: 1.0 X-Received: by 10.42.20.3 with SMTP id e3mr3180750icb.2.1390426878275; Wed, 22 Jan 2014 13:41:18 -0800 (PST) Received: by 10.64.72.132 with HTTP; Wed, 22 Jan 2014 13:41:18 -0800 (PST) Date: Wed, 22 Jan 2014 16:41:18 -0500 Message-ID: Subject: Agenda requests for IETF 89 From: Alia Atlas To: "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary=20cf302447bd2a769c04f095fcbe X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 21:41:20 -0000 --20cf302447bd2a769c04f095fcbe Content-Type: text/plain; charset=ISO-8859-1 It is not too early to start thinking about IETF 89. Alvaro and I would really like to get agenda requests early. We expect that drafts will have discussion on this mailing list before hand. The following are items that we believe will request agenda slots. PLEASE CONFIRM and tell us how much time is needed: draft-aumuganainar-rtgwg-dps-00: intended for last IETF, but author couldn't make it draft-aumuganainar-rtgwg-dps-00: new draft-litkowski-rtgwg-uloop-delay-01: new draft expected draft-ietf-rtgwg-lfa-manageability-01: new draft just published composite link/Advanced Multipath status: Trying to finish up Advanced Multipath work draft-psarkar-rtgwg-rlfa-node-protection -03 We are trying to finish up the following drafts: draft-ietf-rtgwg-mofrr draft-ietf-rtgwg-remote-lfa draft-ietf-rtgwg-cl-use-cases draft-ietf-rtgwg-cl-requirement and would strongly encourage discussion and comments even before WGLC is started on them. Thanks, Alia --20cf302447bd2a769c04f095fcbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It is not too early to start thinking about IETF 89. =A0Al= varo and I would really like to get agenda requests early. =A0We expect tha= t drafts will have discussion on this mailing list before hand.

The following are items that we believe will request agenda slots. =A0= PLEASE CONFIRM and tell us how much time is needed:

=A0 =A0=A0draft-aumuganainar-rt= gwg-dps-00: =A0 intended for last IETF, but author couldn't make it=
=A0 =A0=A0draft-aumuganainar= -rtgwg-dps-00: =A0 new
=A0 =A0=A0draft-litkows= ki-rtgwg-uloop-delay-01: =A0new draft expected
=A0 =A0=A0draft-ietf-r= tgwg-lfa-manageability-01: =A0new draft just published
=A0 =A0 composite link/Advanced Multipath status: =A0Trying to f= inish up Advanced Multipath work

We are trying to finish up the following drafts:
<= div>=A0 =A0draft-ietf-rtgwg-mofrr

and would strongly encourage discussion and comme= nts even before WGLC is started on them.

Thanks,
Alia
--20cf302447bd2a769c04f095fcbe-- From uma.chunduri@ericsson.com Thu Jan 23 13:24:15 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664811A0197; Thu, 23 Jan 2014 13:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YxPePiS4xvu; Thu, 23 Jan 2014 13:24:12 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A4C1B1A023D; Thu, 23 Jan 2014 13:24:12 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-cf-52e1887b4010 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 14.BF.11484.B7881E25; Thu, 23 Jan 2014 22:24:12 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0387.000; Thu, 23 Jan 2014 16:24:11 -0500 From: Uma Chunduri To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: RE: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt Thread-Index: AQHPF3JFo3GE3viSUkOOoMHwgUfchZqSxScw Date: Thu, 23 Jan 2014 21:24:10 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F177B7E@eusaamb105.ericsson.se> References: <20140122130217.15321.92624.idtracker@ietfa.amsl.com> In-Reply-To: <20140122130217.15321.92624.idtracker@ietfa.amsl.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyuXRPuG5Nx8Mgg7ZZIhZLdj1ntvhwN9fi wpvfzA7MHkuW/GQKYIzisklJzcksSy3St0vgyujeXl7ww76iY39UA+Mywy5GTg4JAROJtv5W NghbTOLCvfVANheHkMARRomTDw8wQTjLGSW+zpkFVsUmoCfxcepPdhBbRCBH4u7vpyxdjBwc zAKqEpu32YKYwgJOEo0XhSEqnCU+f/3GAmEbSZzoPsgKYrMAVb/c/A3M5hXwlVh17hrYRCEB R4md2xvA6jmBxnw9uocZxGYEuu37qTVMIDazgLjErSfzmSBuFpBYsuc8M4QtKvHy8T9WCFtJ YtLSc6wQ9ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExjFZiEZOwtJyywkLbOQtCxgZFnFyFFa nFqWm25kuIkRGB3HJNgcdzAu+GR5iFGag0VJnPfLW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xM HJxSDYwiP2TZg2Zdmed+VnSuW9Vavh+T1W78V/8hZaYS8KWHKeFi0T3ebjs1lTlzwlKZajkO zbvGFtzedaE4kfdCexU3y2Pv4vl87V2lU4/M3zZ95T3Rrz7OjycptZ2aLDjFsb6KdxEbv6rl T5HbNg4pDvYnl+7UfHZOLOrJDddbnr3P6j69r7/wsUyJpTgj0VCLuag4EQD2w5qxXAIAAA== Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 21:24:15 -0000 Dear Authors, I have given some comments to you only, on the earlier version of this dra= ft few months back and I see some of them are taken care. Thx. After re-reading this version, I felt this is indeed addressing the import= ant aspect and the value of policy based selection of alternatives=20 As opposed to the alternatives with best protection. This document brings o= ut lot of use cases and the configuration knobs to=20 achieve the goal of the "policy" based preference on possible LFAs. However, I see some of the sections documented are not directly related to = the uses cases presented in Section 2, which in principle=20 shows how and why the best protection is not good (excluding the IS-IS over= load case) in all cases.=20 For example: 1. Section 3.1, which suggests the activation granularity requirement of t= he LFAs from Context, instance to address-family and per-prefix.=20 Here some of the choices are natural but I don't think this addresses= any of the problems documented in Section 2. "..This means that if a specific prefix must be protected due to a configuration request, LFA must be computed and installed for this prefix even if the primary outgoing interface is not configured for protection." Could you clarify the must (2) in the sentence? Do you intend to say = "MUST" there? Also I feel, for example, having per-prefix granularity for provision= ing LFA or not is an implementation choice than an interoperability=20 issue while deployment. 2. Section 4.3, "Required local information" Says - "MUST provide coverage information per activation domain of LFA (area, level, topology, instance, virtual router, address family ...)." To me this is good to have information and be very helpful for the ope= rator but I am not sure mandating the coverage information granularity is addressing any of the issues presented in Section 2. 3. Similarly Section 4.4 coverage monitoring guidelines for the vendor impl= ementations are good ones but these are neither addressing any issues=20 presented in Section 2 nor helping solve any interoperability issue.=20 The problem I see with this is lot of implementations may quickly become no= n-compliant from customers point of view once this becomes RFC. Do you see = that way? Specific review Comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Section 2.1 When the core link R8-R7 fails, R8 switches all traffic destined to all the PEx towards the edge node PE2. What is "all the PEx"?? 2. Section 2.2 "In the figure 2, let us consider the traffic coming from PE1 to PEx. Nominal path is R9-R8-R7-R6-PEx." You might mean to say R9-R8-R7-R10-R6-PEx ? Can you clarify? 3. Section 2.3 Though it's not important to illustrate your point of using sub-optimal = core links as LFA, it's good to mention the link costs of R3-PE1 and PE1-R4= . Otherwise PE1 could become another potential node protecting alternative= via non-core or whatever.. (at least can avoid confusion for the reader). 4. For IGPs what exactly you meant when you say "topology" and how this is= different than first bullet "Per address-family"? 5. Section 3.2.1 "Especially, computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD = to be performed before best alternate selection." =20 SHOULD to be =3D=3D> SHOULD be =20 Also, say you might have a legacy node to deal with and you are not abl= e to establish TLDP with PQ here=20 in that case, you might look for a knob to choose the policy (remote or = local policy). 6. "3.2.5. Details on criterions"=20 Didn't understand the title and all sub-sections listed under should = instead be 3.2.x level? I am saying this because I lost=20 where I was while reading. I would suggest to re-organize better. 7. 3.2.5.1. LFA and ECMP It should have been "ECMP LFAs" =20 And.. "As mentioned in [RFC5286] Section 3.4., protecting a link within an ECMP by another primary nexthop is not a MUST. Moreover, we already presented in this document, that maximizing the coverage of the failure case may not be the right approach and policy based choice of alternate may be preferred." If you just want to prevent one of the other ECMP link as LFA then you c= an provision "local" SRLGs. Then in this case you might get L3 or L4 but you are seeking both as LFA= s. I see the current text put Lot of emphasis on the point of not using one of the primary ECMP path= s as alternatives with citation=20 on RFC 5286.=20 However, you are *also* seeking for an ECMP LFA (if available, instead = of tie breaking and give one=20 LFA eventually from the non-bundle). Also I didn't fully understand how can one enforce this as one can have = another equal cost=20 alternate (non-bundled) path from PE1 to PE2 via P2 or some Px node. It = seems in this case you are looking for all non-ECMP LFAs to be installed as alternatives?=20 8. Section 3.2.5.5 "Rather than tagging interface on each node (using link color) to identify neighbor node type (as example), it would be helpful if routers could be identified in the IGP. " =20 a) After this it completely talks IS-IS language. Probably this should = be revisited to make it generic or applicable to the other IGP. b) Coming to IS-IS, you referred I-D.psarkar-isis-node-admin-tag but th= e text suggests, its own algorithm to identify the neighbor with=20 TLV135 and is not complete in many fronts.=20 =20 I would suggest revisit this section completely to focus on the point your= of "neighbor preference" rather than incomplete IGP details.=20 9. Section 4.5 "4.5. Deterministic and documents LFA selection behavior" The title didn't sound correct. -- Uma C. -----Original Message----- From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Wednesday, January 22, 2014 5:02 AM To: i-d-announce@ietf.org Cc: rtgwg@ietf.org Subject: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Operational management of Loop Free Alternates Authors : Stephane Litkowski Bruno Decraene Clarence Filsfils Kamran Raza Martin Horneffer Pushpasis Sarkar Filename : draft-ietf-rtgwg-lfa-manageability-01.txt Pages : 21 Date : 2014-01-22 Abstract: Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic (and MPLS LDP traffic by extension). Following first deployment experiences, this document provides operational feedback on LFA, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. This proposal is also applicable to remote LFA solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-lfa-manageability-01 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From aretana@cisco.com Thu Jan 23 14:40:35 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABBA1A046A for ; Thu, 23 Jan 2014 14:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 U35yuz0qwnYA for ; Thu, 23 Jan 2014 14:40:29 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D5FE91A045A for ; Thu, 23 Jan 2014 14:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5223; q=dns/txt; s=iport; t=1390516828; x=1391726428; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bkUzxFZMNakIZzwOLMculo130Ssgr9ImpheNrlODanU=; b=DvW574ukDStTAeTtFocMU5MCGMQXGk5+ostjsPDyB2euw7Oj01nXfiS4 J6NkxBY1NTikK2RsJdf99DQeG9SwM49vooDOqFhA0t8hBF5NrYhxHNb/Y wGyWKlVqddxmT92X4YGYcFuco8ko6EksQMparSIQagS3A+LMLveEp9wjv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMIABWa4VKtJV2c/2dsb2JhbABagkhEOFazZYhSgRYWdIImAQEEHWwCAQg/BzIUEQIEE4gFDccTF48HhDgEmCOBMpBmgy2CKg X-IronPort-AV: E=Sophos;i="4.95,709,1384300800"; d="scan'208,217";a="299152146" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 23 Jan 2014 22:40:08 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0NMe8vA023728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 Jan 2014 22:40:08 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.206]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 16:40:08 -0600 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Topic: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Index: AQHOu4CPrWxL1Z2c40Onwd/d+2+N/pqTseGA Date: Thu, 23 Jan 2014 22:40:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_CF0703C2480CBaretanaciscocom_" MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 22:40:35 -0000 --_000_CF0703C2480CBaretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! It took a while to collect the IPR statements from everyone..and for me to = get back on this thread.. There is enough support to adopt this draft as a WG item. Authors: Please republish as draft-ietf-rtgwg-mrt-frr-algorithm Thanks! Alvaro. On 9/27/13 8:53 AM, "Alvaro Retana (aretana)" > wrote: Hi! This message starts a two-week Call for WG Adoption for 'Algorithms for com= puting Maximally Redundant Trees for IP/LDP Fast-Reroute' (draft-enyedi-rtg= wg-mrt-frr-algorithm). http://tools.ietf.org/html/draft-enyedi-rtgwg-mrt-frr-algorithm At the meeting in Berlin the authors asked for the WG adoption of their dra= ft, but here were very few people in the room who had actually reviewed the= document to get any type of read of the room. We want to hear from people who have read and understood the draft (besides= the authors!) about this topic. Please provide some explanation as to why= you support or not the adoption of the draft =97 avoid "+1". This call will be over by EOD on Oct/11, 2013 (pick your favorite time zone= ). Thanks!! Alvaro. --_000_CF0703C2480CBaretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi!

It took a while to collect the IPR statements from everyone..and for m= e to get back on this thread..

There is enough support to adopt this draft as a WG item.

Authors:  Please republish as draft-ietf-rtgwg-mrt-frr-algorithm<= /div>

Thanks!

Alvaro.

On 9/27/13 8:53 AM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!

This message starts a two-week Call for WG Adoption for 'Algorithms fo= r computing Maximally Redundant Trees for IP/LDP Fast-Reroute' (draft-enyed= i-rtgwg-mrt-frr-algorithm).


At the meeting in Berlin the authors asked for the WG adoption of their dra= ft, but here were very few people in the room who had actually reviewed the= document to get any type of read of the room.  

We want to hear from people who have read and understood the draft (besides= the authors!) about this topic.  Please provide some explanation as t= o why you support or not the adoption of the draft =97 avoid "+1&q= uot;.

This call will be over by EOD on Oct/11, 2013 (pick your favorite time zone= ).

Thanks!!

Alvaro.
 --_000_CF0703C2480CBaretanaciscocom_-- From liu.bin21@zte.com.cn Thu Jan 23 19:01:47 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B96E1A0379 for ; Thu, 23 Jan 2014 19:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 NxQfVtEMsK1Z for ; Thu, 23 Jan 2014 19:01:44 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 15E651A035A for ; Thu, 23 Jan 2014 19:01:44 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id 7BFA61284DE1 for ; Fri, 24 Jan 2014 11:01:34 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 03B5ECB545B for ; Fri, 24 Jan 2014 11:01:32 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s0O31PNY038355 for ; Fri, 24 Jan 2014 11:01:25 +0800 (GMT-8) (envelope-from liu.bin21@zte.com.cn) MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Ask for comments: draft-sl-rtgwg-far-dcn-00.txt X-Mailer: Lotus Notes Release 7.0 August 18, 2005 Message-ID: From: liu.bin21@zte.com.cn Date: Fri, 24 Jan 2014 11:01:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-01-24 11:01:18, Serialize complete at 2014-01-24 11:01:18 Content-Type: multipart/alternative; boundary="=_alternative 00109D5E48257C6A_=" X-MAIL: mse01.zte.com.cn s0O31PNY038355 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 03:01:47 -0000 This is a multipart message in MIME format. --=_alternative 00109D5E48257C6A_= Content-Type: text/plain; charset="US-ASCII" Greeting all, We uploaded a draft that proposed a generic routing method and protocol for a regular data center network, named as the fault-avoidance routing (FAR) protocol. FAR protocol provides a generic routing method for all kinds of network architectures that are proposed for large-scale cloud data centers over the past few years. FAR protocol is well designed to fully leverage the regularity in the topology and compute its routing table in a simple way. We hope to get valuable opinions of experts in the routing group on our draft. Best regards, Richard Bin Liu --------------------------------------------------------------------------- A new version of I-D, draft-sl-rtgwg-far-dcn-00.txt has been successfully submitted by Bin Liu and posted to the IETF repository. Filename: draft-sl-rtgwg-far-dcn Revision: 00 Title: Generic Fault-avoidance Routing Protocol for Data Center Networks Creation date: 2013-12-19 Group: Individual Submission Number of pages: 24 URL: http://www.ietf.org/internet-drafts/draft-sl-rtgwg-far-dcn-00.txt Status: http://datatracker.ietf.org/doc/draft-sl-rtgwg-far-dcn Htmlized: http://tools.ietf.org/html/draft-sl-rtgwg-far-dcn-00 Abstract: This draft proposed a generic routing method and protocol for a regular data center network, named as the fault-avoidance routing (FAR) protocol. FAR protocol provides a generic routing method for all kinds of network architectures that are proposed for large-scale cloud data centers over the past few years. FAR protocol is well designed to fully leverage the regularity in the topology and compute its routing table in a simple way. Fat-tree is taken as an example architecture to illuminate how to apply FAR protocol in this draft. --=_alternative 00109D5E48257C6A_= Content-Type: text/html; charset="US-ASCII"
Greeting all,

We uploaded a draft that proposed a generic routing method and protocol for a regular data center network, named as the fault-avoidance routing (FAR) protocol. FAR protocol provides a generic routing method for all kinds of network architectures that are proposed for large-scale cloud data centers over the past few years.  FAR protocol is well designed to fully leverage the regularity in the topology and compute its routing table in a simple way.

We hope to get valuable opinions of experts in the routing group on our draft.

Best regards,
Richard Bin Liu

---------------------------------------------------------------------------
A new version of I-D, draft-sl-rtgwg-far-dcn-00.txt
has been successfully submitted by Bin Liu and posted to the
IETF repository.

Filename:                  draft-sl-rtgwg-far-dcn
Revision:                  00
Title:                                   Generic Fault-avoidance Routing Protocol for Data Center Networks
Creation date:                  2013-12-19
Group:                                   Individual Submission
Number of pages: 24
URL:             http://www.ietf.org/internet-drafts/draft-sl-rtgwg-far-dcn-00.txt
Status:          http://datatracker.ietf.org/doc/draft-sl-rtgwg-far-dcn
Htmlized:        http://tools.ietf.org/html/draft-sl-rtgwg-far-dcn-00


Abstract:
   This draft proposed a generic routing method and protocol for a
   regular data center network, named as the fault-avoidance routing
   (FAR) protocol.  FAR protocol provides a generic routing method for
   all kinds of network architectures that are proposed for large-scale
   cloud data centers over the past few years.  FAR protocol is well
   designed to fully leverage the regularity in the topology and compute
   its routing table in a simple way.  Fat-tree is taken as an example
   architecture to illuminate how to apply FAR protocol in this draft.

                                                                                 

--=_alternative 00109D5E48257C6A_=-- From akatlas@gmail.com Fri Jan 24 15:36:59 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7C71A021B for ; Fri, 24 Jan 2014 15:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83D_ptco7slJ for ; Fri, 24 Jan 2014 15:36:58 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id D57841A0215 for ; Fri, 24 Jan 2014 15:36:57 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id lx4so3657226iec.13 for ; Fri, 24 Jan 2014 15:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TurOcBO6UcWtMb4MTlnRta3MVfFndqB+tlJnmjgaNIc=; b=KKGYT6Zq+xNxl9M61di+zpOvwDOcLlSEb24t/s6VL8DjQ//y5oGXttfH1YbOcppOvZ 51KsMnjf750l1NA+1WEUEnh7N6E97WUYPyESGRFIgxenIYMSSnfy85F8PKYjsEQnf2Vp DRr7lNBSfzVJ4iiUpiBHVSIH2mGkOfkPMDVCjHpd6POTMHTmOoragQj0DAmqittFHc/H Q5igB6/tHtMTTpyDfJKlL27i3bO2a+GDijT0NAYh/HM00K8ABOwC+fsLkPxVwOKlQiJZ /s4sBVgU/S5K6skSew75+BgC8E2f49kC+qUVSfXVZJT5HSz7qrCk9Wy2y1sOxcAXCFc7 IEbw== MIME-Version: 1.0 X-Received: by 10.50.43.134 with SMTP id w6mr7224080igl.20.1390606616597; Fri, 24 Jan 2014 15:36:56 -0800 (PST) Received: by 10.64.72.132 with HTTP; Fri, 24 Jan 2014 15:36:56 -0800 (PST) Date: Fri, 24 Jan 2014 18:36:56 -0500 Message-ID: Subject: process questions about draft-ietf-rtgwg-mofrr-03 From: Alia Atlas To: "rtgwg@ietf.org" , draft-ietf-rtgwg-mofrr@tools.ietf.org Content-Type: multipart/alternative; boundary=089e01184b0c679ec504f0bfd5ec X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 23:36:59 -0000 --089e01184b0c679ec504f0bfd5ec Content-Type: text/plain; charset=ISO-8859-1 Is the intended status still Informational? Are there any implementations? Thanks, Alia --089e01184b0c679ec504f0bfd5ec Content-Type: text/html; charset=ISO-8859-1
Is the intended status still Informational?
Are there any implementations?

Thanks,
Alia
--089e01184b0c679ec504f0bfd5ec-- From wim.henderickx@alcatel-lucent.com Sat Jan 25 01:00:19 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E861C1A01F4 for ; Sat, 25 Jan 2014 01:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 oKh08c4t4QaV for ; Sat, 25 Jan 2014 01:00:18 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id B48831A01F1 for ; Sat, 25 Jan 2014 01:00:17 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s0P90Eb9028387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 25 Jan 2014 03:00:15 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s0P90Csl014173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 Jan 2014 10:00:12 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.122]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Sat, 25 Jan 2014 10:00:12 +0100 From: "Henderickx, Wim (Wim)" To: Alia Atlas , "rtgwg@ietf.org" , "draft-ietf-rtgwg-mofrr@tools.ietf.org" Subject: Re: process questions about draft-ietf-rtgwg-mofrr-03 Thread-Topic: process questions about draft-ietf-rtgwg-mofrr-03 Thread-Index: AQHPGV0xa/WMp53alkOsy7rDNl8H0JqVJPYA Date: Sat, 25 Jan 2014 09:00:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_CF093B99A5FF2wimhenderickxalcatellucentcom_" MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 09:00:20 -0000 --_000_CF093B99A5FF2wimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have an implementation of this. From: Alia Atlas > Date: Saturday 25 January 2014 00:36 To: "rtgwg@ietf.org" >, "draft-ietf-rtgwg-mofrr@tools.ietf.org" > Subject: process questions about draft-ietf-rtgwg-mofrr-03 Is the intended status still Informational? Are there any implementations? Thanks, Alia --_000_CF093B99A5FF2wimhenderickxalcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
We have an implementation of this.

From: Alia Atlas <akatlas@gmail.com>
Date: Saturday 25 January 2014 00:3= 6
To: "rtgwg@ietf.org" <rtg= wg@ietf.org>, "draft-ietf-rtgwg-mofrr@tools.ietf.org" <draft-ietf-rtgwg-mofrr@tools.iet= f.org>
Subject: process questions about dr= aft-ietf-rtgwg-mofrr-03

Is the intended status still Informational?
Are there any implementations?

Thanks,
Alia
 --_000_CF093B99A5FF2wimhenderickxalcatellucentcom_-- From jeff.tantsura@ericsson.com Sat Jan 25 09:37:44 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740BF1A0087 for ; Sat, 25 Jan 2014 09:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKWl_Ln2pg8s for ; Sat, 25 Jan 2014 09:37:43 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 121B71A002A for ; Sat, 25 Jan 2014 09:37:43 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-4d-52e3f665a608 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 51.5A.11484.566F3E25; Sat, 25 Jan 2014 18:37:42 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0387.000; Sat, 25 Jan 2014 12:37:41 -0500 From: Jeff Tantsura To: Alia Atlas Subject: Re: process questions about draft-ietf-rtgwg-mofrr-03 Thread-Topic: process questions about draft-ietf-rtgwg-mofrr-03 Thread-Index: AQHPGV0xYaPAw/X0KECZEN1DvjeZ35qVtY/U Date: Sat, 25 Jan 2014 17:37:40 +0000 Message-ID: <7F20E076-6595-40D9-AF5F-85A885C08BF9@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyuXSPt27at8dBBl2HuCw+PbzEbLFs/TtW iwtvfjM7MHvsnHWX3WPJkp9MHl8uf2YLYI7isklJzcksSy3St0vgypg6p42xYAJzxdIn+1kb GI8zdTFyckgImEhcP/yABcIWk7hwbz1bFyMXh5DAEUaJ7bdesEM4yxklfn3dDVbFJmAg8f/b cSCbg0NEQEli6kthkDCzQIXE3/9XmEDCwgJ2EhvnyoGERQTsJY5s+cgGYRtJTNpygx3EZhFQ lZh9diqYzQtU87x7H5gtJBAgcW35OrDbOAUCJebOWQhmMwLd9v3UGiaIVeISt57Mh7pfQGLJ nvPMELaoxMvH/1ghanQkFuz+xAZha0ssW/iaGWKXoMTJmU9YJjCKzkIyahaSlllIWmYhaVnA yLKKkaO0OLUsN93IcBMjMD6OSbA57mBc8MnyEKM0B4uSOO+Xt85BQgLpiSWp2ampBalF8UWl OanFhxiZODilGhjnbJZ5s25+YnWZtDGXVJbddemfF7jeTgotXXl/a3C8vk6yrcilNzlfmGSj 5W7P2FwinPVBOm+Dy4qGtUEz14ct3jxTUFeMLfrajziBTadFP06bfj3E/srUa10r8sLmiRRH RK+NeiTsF/dl5uk+sfkN0dpuV5cJ2zJ3s1k1Xmb/vzTGZ/U71k1KLMUZiYZazEXFiQDzoIL/ XQIAAA== Cc: "draft-ietf-rtgwg-mofrr@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 17:37:44 -0000 Hi Alia, Yes, we have got an implementation. Thanks! Regards, Jeff > On Jan 24, 2014, at 3:37 PM, "Alia Atlas" wrote: >=20 > Is the intended status still Informational? > Are there any implementations? >=20 > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From ice@cisco.com Sat Jan 25 10:57:23 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F861A0041 for ; Sat, 25 Jan 2014 10:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 NRssWdId4jsL for ; Sat, 25 Jan 2014 10:57:21 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5901C1A003C for ; Sat, 25 Jan 2014 10:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=778; q=dns/txt; s=iport; t=1390676240; x=1391885840; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Es8HIRqwrEATgE4UN69u43nDv0iE2/3VqnkGUE8X81s=; b=Q1CZhcFLZQazEB++QDz4Ai1VIOPukmB4k1qJaEy7X7t2fFw6TY4TFmaI scPiGxweFt30vP12uQ2WChGiojmLBbre3ycqB4UgZnZihYgaximb4PGl8 DE7XMeatr6nfqi+LoL0TyhywKl/WdNREoDpzOmt9OKQ9HuVMc2HjWi5yD Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAFwI5FKQ/khN/2dsb2JhbABagww4vSKBCRZ0giUBAQEDAQEBATc0CwULCw4KLiEGMAYBEodxAwkIDcMPDYVWEwSMd4IWB4MkgRQEljuBbIxdhUGDLjs X-IronPort-AV: E=Sophos;i="4.95,720,1384300800"; d="scan'208";a="3506170" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 25 Jan 2014 18:57:19 +0000 Received: from ams-iwijnand-87111.cisco.com (ams-iwijnand-87111.cisco.com [10.55.191.156]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0PIvIcq007748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 25 Jan 2014 18:57:19 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: process questions about draft-ietf-rtgwg-mofrr-03 From: IJsbrand Wijnands In-Reply-To: <7F20E076-6595-40D9-AF5F-85A885C08BF9@ericsson.com> Date: Sat, 25 Jan 2014 19:57:18 +0100 Content-Transfer-Encoding: 7bit Message-Id: <31BAA599-0ABE-4656-B53E-A4625CB72C84@cisco.com> References: <7F20E076-6595-40D9-AF5F-85A885C08BF9@ericsson.com> To: Alia Atlas , Jeff Tantsura X-Mailer: Apple Mail (2.1510) Cc: draft-ietf-rtgwg-mofrr@tools.ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 18:57:23 -0000 Hi Alia, Likewise, Cisco has an implementation. Its informational because there is no protocol change necessary. Thx, Ice. On 25 Jan 2014, at 18:37, Jeff Tantsura wrote: > Hi Alia, > > Yes, we have got an implementation. > Thanks! > > Regards, > Jeff > >> On Jan 24, 2014, at 3:37 PM, "Alia Atlas" wrote: >> >> Is the intended status still Informational? >> Are there any implementations? >> >> Thanks, >> Alia >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From curtis@ipv6.occnc.com Sat Jan 25 11:21:03 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD691A003B; Sat, 25 Jan 2014 11:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pUtgReEbgMn; Sat, 25 Jan 2014 11:20:58 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 86E2E1A002F; Sat, 25 Jan 2014 11:20:58 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0PJKtA4047788; Sat, 25 Jan 2014 14:20:56 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401251920.s0PJKtA4047788@maildrop2.v6ds.occnc.com> To: Lou Berger From: Curtis Villamizar Subject: Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 In-reply-to: Your message of "Fri, 17 Jan 2014 13:01:33 -0500." <52D96FFD.1020408@labn.net> Date: Sat, 25 Jan 2014 14:20:55 -0500 Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, rtgwg@ietf.org, "rtg-ads@tools.ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 19:21:03 -0000 Lou, I am in the process of submitting a -14 version followed with only the changes for the OpsDir review followed by a -15 version with the additional changes from your RtgDir review. Please wait for the -15 version if you see the -14 and not the -15. Curtis In message <52D96FFD.1020408@labn.net> Lou Berger writes: > > sounds like a plan! > > Lou > > On 01/17/2014 12:41 PM, Curtis Villamizar wrote: > > In message <52D88F77.5020009@labn.net> > > Lou Berger writes: > > > >> Curtis, > >> I'm not sure if we're going around in circles or not, but in either > >> case case I think we're getting caught up in the weeds/details. > >> > >> >From a high level perspective, my comments have been motivated by trying > >> to ensure the requirements are unambiguous -- as documented. I think > >> the text changes that have been agreed to so far (notably the use of the > >> capitalized term and introduction of AMG) will help a lot. I think there > >> is still one more area that is unclear, but it's also possible that > >> we're arguing about text that you are planning to change. > >> > >> Do you have a version that captures all the changes to date that you can > >> distribute (or submit, as you choose)? Perhaps looking at this version > >> we'll find that the ambiguity is resolved or is sufficiently narrowed to > >> not be significant. Either way, the discussion can then continue from > >> the most current text. > >> > >> Thanks, > >> Lou > > > > > > Lou, > > > > I was going to suggest the same (if I understand your suggestion) - > > that is that a new draft be submitted and you (and others) can review > > and see if clarity has been sufficiently improved or if there are > > still issues with clarity. > > > > If that is OK with you and compatible with this process I will make > > two draft submissions back to back. One with just the OpsDir review > > comments addressed and a second with your comments so far addressed. > > IMHO it would be easier to discuss the clarity (or lack of) of the > > wording once changes have been made particularly since there are a few > > s/old/new/g terminology suggestions in the email thread. > > > > Curtis > > > > > >> On 1/15/2014 7:00 PM, Curtis Villamizar wrote: > >>> In message <52D02F67.9070604@labn.net> > >>> Lou Berger writes: > >>> > >>>> Curtis, > >>>> > >>>> I think we have one disconnect (and corresponding related text) that we > >>>> need to resolve before we can be close the discussion. See below for > >>>> details.. > >>>> > >>>> On 1/8/2014 11:33 PM, Curtis Villamizar wrote: > >>>>> Converging. But maybe one more round trip needed. > >>>>> > >>>>> In message <52CD9D58.4010109@labn.net> > >>>>> Lou Berger writes: > >>>>>> > >>>> ... > >>>> > >>>>>>>>>> 2. Editorial: server and client layer vs upper and lower layer. > >>>>>>>>>> > >>>>>>>>>> The document uses server and client layer networks and LSPs and, > >>>>>>>>>> sometimes interchangeably or redundantly, upper and lower layer networks > >>>>>>>>>> and LSPs. I think this issue can be resolved by avoiding the term > >>>>>>>>>> client/server when referring to network layers and just using the > >>>>>>>>>> lower/upper terminology. The one exception to this is in the definition > >>>>>>>>>> Client LSP which should simply be defined in the context of a multipath, > >>>>>>>>>> i.e.: > >>>>>>>>>> OLD > >>>>>>>>>> A client LSP is an LSP which has been set up over a server layer. > >>>>>>>>>> NEW > >>>>>>>>>> A client LSP is an LSP which has been set up over Advanced Multipath. > >>>>>>>>> > >>>>>>>>> A client LSP can be set up over a server layer MPLS-TP LSP or any > >>>>>>>>> server layer MPLS LSP or over a link layer or over a pseudowire ... or > >>>>>>>>> over an advanced multipath. > >>>>>>>>> > >>>>>>>> > >>>>>>>> Would you accept s/server layer/lower layer/g? > >>>>>>> > >>>>>>> The definition of server layer is not the same as the definition of > >>>>>>> lower layer. See below. > >>>>>>> > >>>>>>>>>> I think this also means that usage of the term "Client" is limited to > >>>>>>>>>> "Client LSP". > >>>>>>>>> > >>>>>>>>> I searched for all occurances of the word client. All occurances are > >>>>>>> />> "client LSP" excexpt the phrase "client of a client LSP" and that is > >>>>>>>>> used only in the following paragraph. > >>>>>>>>> > >>>>>>>>> The ingress and egress of a multipath may be midpoint LSRs with > >>>>>>>>> respect to a given client LSP. A midpoint LSR does not participate > >>>>>>>>> in the signaling of any clients of the client LSP. Therefore, in > >>>>>>>>> general, multipath endpoints cannot determine requirements of clients > >>>>>>>>> of a client LSP through participation in the signaling of the clients > >>>>>>>>> of the client LSP. > >>>>>>>>> > >>>>>>>>> THe point is that "A midpoint LSR does not participate in the > >>>>>>>>> signaling of any clients of the client LSP" and that non-participation > >>>>>>>>> in client (or higher layer) signaling applies to any "client of a > >>>>>>>>> client LSP", not just other LSP running over it. > >>>>>>>>> > >>>>>>>>> I then searched for all occurances of the words upper and lower and > >>>>>>>>> higher. There are no occurances of "upper". > >>>>>>>>> > >>>>>>>>> There were a few occurances of "lower latency" and "higher latency". > >>>>>>>>> Other than that, all occurances of lower and higher except one are in > >>>>>>>>> the follwoing text: > >>>>>>>>> > >>>>>>>>> 3.2. Component Links Provided by Lower Layer Networks > >>>>>>>>> > >>>>>>>>> A component link may be supported by a lower layer network. For > >>>>>>>>> example, the lower layer may be a circuit switched network or another > >>>>>>>>> MPLS network (e.g., MPLS-TP)). The lower layer network may change > >>>>>>>>> the latency (and/or other performance parameters) seen by the client > >>>>>>>>> layer. Currently, there is no protocol for the lower layer network > >>>>>>>>> to inform the higher layer network of a change in a performance > >>>>>>>>> parameter. Communication of the latency performance parameter is a > >>>>>>>>> very important requirement. Communication of other performance > >>>>>>>>> parameters (e.g., delay variation) is desirable. > >>>>>>>>> > >>>>>>>>> FR#8 The solution SHALL specify a protocol means to allow a lower > >>>>>>>>> layer server network to communicate latency to the higher layer > >>>>>>>>> client network. > >>>>>>>>> > >>>>>>>>> The exception is this sentence: > >>>>>>>>> > >>>>>>>>> FR#22 The solution SHOULD support the use case where an advanced > >>>>>>>>> multipath itself is a component link for a higher order advanced > >>>>>>>>> multipath. For example, an advanced multipath comprised of MPLS- > >>>>>>>>> TP bi-directional tunnels viewed as logical links could then be > >>>>>>>>> used as a component link in yet another advanced multipath that > >>>>>>>>> connects MPLS routers. > >>>>>>>>> > >>>>>>>>> The terms lower layer and higher layer go all the way back to the ISO > >>>>>>>>> seven layer model of ancient times (1970s?, 1980s?) and maybe further > >>>>>>>>> back but that is before even my time. > >>>>>>>>> > >>>>>>>>> I don't think this is unclear but I could add the following in > >>>>>>>>> definitions: > >>>>>>>>> > >>>>>>>>> Higher Layers > >>>>>>>>> A client layer is the one immediately above a server layer. The > >>>>>>>>> client layer and all layers above that layer are higher layers. > >>>>>>>>> > >>>>>>>>> Lower Layers > >>>>>>>>> A server layer is the later immediately below a client laer. > >>>>>>>>> The server layer and all layers below are lower layers. > >>>>>>>>> > >>>>>>>>> Do I really need to put this in the definitions section? If yoy think > >>>>>>>>> it is necessary, I will add it. > >>>>>>>>> > >>>>>>>> Perhaps we've talked (okay written) past each other. I was suggesting > >>>>>>>> using/keeping the "higher and lower layer" terminology, not dropping it. > >>>>>>>> And to use it (consistently) in place of "client and server Layer". > >>>>>>> > >>>>>>> I guess you missed the distinction in the definition above: > >>>>>>> > >>>>>>> For layer X layer Y is: > >>>>>>> > >>>>>>> client layer === Y = X+1 > >>>>>>> server layer === Y = X-1 > >>>>>>> higher layer === Y > X > >>>>>>> lower layer === Y < X > >>>>>>> > >>>>>>> So the definition client layer is not the same as the definition of > >>>>>>> higher layer. The definition of server layer is not the same as the > >>>>>>> definition of lower layer. > >>>>>>> > >>>>>>> In some discussions we really do mean "the server layer" and not any > >>>>>>> layer at any arbitrary depth below this one. > >>>>>> > >>>>>> I read your usage of client/server layer to be synonymous with > >>>>>> higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense > >>>>>> of FR#8 (I think you really mean client layer not lower layer.) > >>>>> > >>>>> FR#8 and FR#9 are about the server layer telling the client layer > >>>>> about the delays that can be expected. There is a little redundancy > >>>>> here so s/ower layer server network/server network/ and > >>>>> s/higher layer client network/client network/. No plans to skip > >>>>> layers. > >>>>> > >>>> > >>>> I think we need to hit the points below before this one... > >>> > >>> OK. > >>> > >>>>>> Given the current document usage, I still think it makes sense to > >>>>>> eliminate the two instances of "client layer": How about the following: > >>>>>> OLD > >>>>>> Client LSP > >>>>>> A client LSP is an LSP which has been set up over a server layer. > >>>>>> In the context of this discussion, a client LSP is a LSP which > >>>>>> has been set up over a multipath as opposed to an LSP > >>>>>> representing the multipath itself or any LSP supporting a > >>>>>> component links of that multipath. > >>>>>> NEW > >>>>>> Client LSP > >>>>>> A client LSP is a LSP which > >>>>>> has been set up over Advanced Multipath as opposed to an LSP > >>>>>> representing the Advanced Multipath itself or any LSP that is > >>>>>> part of an Advanced Multipath Group. > >>>>> > >>>>> Nope. In general, a client LSP can be set up over a plain old > >>>>> Ethernet on a given hop, therefore the second definition is too > >>>>> narrow with this change. > >>>>> > >>>> > >>>> humm, you didn't have that in your OLD text. In fact, the old text > >>>> reads to me that an Advanced Multipath (solution?) logically sits > >>>> between a client LSP and an underlying server layer in all cases. > >>> > >>> The "OLD" was a quote from you and it was the original text in -13. I > >>> said "Nope. ..." to your suggested change to it in this way. > >>> > >>> Earlier > >>> (http://www.ietf.org/mail-archive/web/rtgwg/current/msg04274.html) I > >>> had suggested the following change: > >>> > >>> I don't think this is unclear but I could add the following in > >>> definitions: > >>> > >>> Higher Layers > >>> A client layer is the one immediately above a server layer. The > >>> client layer and all layers above that layer are higher layers. > >>> > >>> Lower Layers > >>> A server layer is the later immediately below a client laer. > >>> The server layer and all layers below are lower layers. > >>> > >>> Do I really need to put this in the definitions section? If yoy think > >>> it is necessary, I will add it. > >>> > >>> You will find this in the quoted text above. > >>> > >>> The definition of client LSP does not imply that Advanced Multipath is > >>> a layer. This also used lower case "multipath" which we can replace > >>> with AMG. There is no LAG layer in a network in with MPLS runs over > >>> Ethernet and some of the Ethernets use Link Aggregation. > >>> > >>>> So the model I see defined by the text has the following layers > >>>> > >>>> Client LSP (layer) > >>>> ---------- > >>>> Advanced Multipath (layer/solution/construct) > >>>> ---------- > >>>> Server Layer (composed of AMGs which are LSPs and/or links) > >>>> > >>>> Is this aligned with your intent? If not, can you explain the > >>>> relationship you see for Advanced Multipath Client LSPs and Advanced > >>>> Multipath AMGs? > >>> > >>> You imaginged this model and are trying to constrain the text to fit > >>> into it.. > >>> > >>> Consider these examples of client layer and server layer. > >>> > >>> plain old rfc-4206 > >>> > >>> LSP-1 (PSC-0) = client of LSP-2 > >>> LSP-2 (PSC-1) = server of LSP-1 > >>> > >>> LSP over Ethernet over PW over MPLS > >>> > >>> LSP-1 = client of Ethernet > >>> Ethernet = server of LSP-1, client of PW > >>> PW = server of Ethernet, client of LSP-2 > >>> LSP-2 = server of PW > >>> > >>> There is then the question of whether Advanced Multipath is a layer or > >>> a set of techniques that can be applied at a given layer. Example > >>> potential config language: > >>> > >>> mple { > >>> tunnel x1 { > >>> type multipath { > >>> component tunnel x2; > >>> component tunnel x3; > >>> [...] > >>> component intf i1; > >>> component intf i2; > >>> [...] > >>> } > >>> [...] > >>> } > >>> [...] > >>> } > >>> > >>> No distinct layer above. > >>> > >>> An alternate: > >>> > >>> mple { > >>> tunnel x1 { > >>> [...] > >>> } > >>> [...] > >>> } > >>> > >>> interface amg1; > >>> type multipath { > >>> component tunnel x2; > >>> component tunnel x3; > >>> [...] > >>> component intf i1; > >>> component intf i2; > >>> [...] > >>> } > >>> [...] > >>> } > >>> [...] > >>> } > >>> > >>> In the former example, the tunnel x1 is forced to use a specific set > >>> of component links and apply multipath techniques to it. > >>> > >>> In the latter example, if tunnel x1 happen to find that interface amg1 > >>> was the lowest cost or otherwise preferred way to get to its > >>> destination it makes use of amg1 and if so inherits the use of the > >>> multipath techniques. > >>> > >>> There is no distinct multipath encapsulation at the date layer so some > >>> might argue that even in the second case there is no distinct layer, > >>> just a configuration convenience. > >>> > >>> Claiming that Advanced Multipath is of itself a layer may get us into > >>> a bigger can of worms. > >>> > >>> For example in today's ECMP, the next hop consists of multiple > >>> interfaces. ECMP is not considered a layer between IP and those > >>> interfaces. Link bundle is also not considered a layer. > >>> > >>> In the document we have not claimed that Advanced Multipath is a type > >>> of layer and we have not claimed that Advanced Multipath is not a type > >>> of layer. Either way we would get someone arguing that the opposite > >>> was true. [Some individuals it seems would pick the opposite of > >>> whatever we picked just because they like to argue about layering.] > >>> > >>> Need I remind you of the painfully long and mostly pointless arguments > >>> in MPLS during the early MPLS-TP work about whether an MPLS LSP > >>> carried within another hierarchical MPLS LSP was a layer or a > >>> sub-layer. We don't want to repeat that and the best way to do so is > >>> to not make any statement about whether Advanced Multipath is a layer > >>> or a sub-layer or a layering NOOP. > >>> > >>> Which of the above is the "right" way to do things may be at most a > >>> framework issue but may not come up until management plane entities > >>> are defined. It is certainly not a topic for a requirements document > >>> because it is deep into the "how it gets done". > >>> > >>>>>> and > >>>>>> OLD > >>>>>> The above set of requirements apply to component links with different > >>>>>> characteristics regardless as to whether those component links are > >>>>>> provided by parallel physical links between nodes or provided by sets > >>>>>> of paths across a network provided by server layer LSP. > >>>>>> NEW > >>>>>> The above set of requirements apply to component links with different > >>>>>> characteristics regardless as to whether those component links are > >>>>>> provided by parallel physical links between nodes or provided by > >>>>>> LSPs that are part of an Advanced Multipath Group. > >>>>> > >>>>> What about PW? Those are paths too by the definition of paths, so > >>>>> again, this change makes the definition too narrow. > >>>>> > >>>> > >>>> PWs weren't mentioned in your OLD text, so I didn't add them. I also > >>>> have no objections to adding them. > >>> > >>> Actually the text you wrote is incorrect. "The above requirement > >>> applies to component links" can include physical links and server > >>> layer LSP but adding that are part of an Advanced Multipath Group is > >>> incorrect. > >>> > >>> I'm not sure but I think this instance of "server layer" was added to > >>> that LSP wording because you were confused on last review about client > >>> LSP vs LSP over which Advanced Multipath was applied so I went around > >>> changing everything to "client LSP" or "server layer LSP" to make it > >>> more clear to you. You now seem to be stuck on the wording that is > >>> essentially saying "any type of component link" including "server > >>> layer LSP". > >>> > >>>> The only change I made was > >>>> s/sets of paths across a network provided by server layer LSP./ > >>>> LSPs that are part of an Advanced Multipath Group. > >>> > >>> And that change was wrong. A more correct change would be > >>> > >>> s/provided by server layer LSP/including paths provided by server > >>> layer LSP/ > >>> > >>> That would include any sort of path across the network. PW could be > >>> considered an emulated physcial link or another usable type of path > >>> across the network. > >>> > >>> The "above set of requirements" in this case have to do with passing > >>> down requirements for min latency, bounded latency, and bounded > >>> jitter. The original paragraph is: > >>> > >>> The above set of requirements apply to component links with > >>> different characteristics regardless as to whether those component > >>> links are provided by parallel physical links between nodes or > >>> provided by sets of paths across a network provided by server layer > >>> LSP. > >>> > >>> The intent is "The above set of requirements apply to component links" > >>> followed by "regardless of what type of component links they are" > >>> where we had disccssed two types being an interface or emulated > >>> interface (or virtual interface in some major vendor terms) or an LSP > >>> (which is also a virtual interface in some major vendor terms). > >>> > >>> I don't understand how you can get so hung up on the wording of what > >>> is intended to convey "regardless of what type of component links they > >>> are". This has always been clear to the WG. > >>> > >>>>>>> The word "indicate" is independent of the method of getting the > >>>>>>> information there. But yes in the example given the IGP advertisement > >>>>>>> and MPLS LSP signaling that might be one such mechanism does refer to > >>>>>>> the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. > >>>>>>> > >>>>>>> If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there > >>>>>>> is only one IGP flooding information for both client and server layer, > >>>>>>> hence the seemingly endless (and mostly pointless) discussion of > >>>>>>> sub-layer vs layer from certain ITU people in the MPLS WG mailing list > >>>>>>> who viewed MPLS as broken for not enforcing a strict layering in this > >>>>>>> regard. But we need not go into that level of detail in this example > >>>>>>> of how independent of mechanism the "indicate" is and down that years > >>>>>>> old MPLS WG terminology rat hole again. > >>>>>>> > >>>>>> My comment is that you need to be clear to which layer a requirement > >>>>>> applies. Is it the server layer, the client layer or the Advanced > >>>>>> Multipath layer? > >>>>> > >>>>> In each of the requirements you cited it is very clear that the client > >>>>> later is communicating a requirement to the server layer, but if you'd > >>>>> like I can reword to make that even more clear by rewording of the > >>>>> form "SHALL provide a means for the client layer to indicate the > >>>>> requirements of a client LSP [regarding X]", where X is minimize > >>>>> latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific > >>>>> component link (FR#13), bidirection co-routed (FR#14), no reordering > >>>>> (FR#15), bounded frequency of rebalance (FR#20). > >>>> > >>>> Okay, I think this will/may help. My comment goes back to the model I > >>>> was asking about above. And to which part of the puzzle the requirement > >>>> applies. > >>> > >>> In some of the above requirements client layer communicated to the > >>> server layer, whatever the server layer is. Means of communication > >>> presumed to be RSVP-TE but we can't say that until the framework and > >>> same capability needs to be available to management plane. > >>> > >>> In some of the above requirements server layer communicates to the > >>> client layer. Means of communication is presumed to be IGP > >>> extensions, again with same capability available to management plane. > >>> > >>> There is no distinct Advanced Multipath layer in control plane or data > >>> plane. And if there was a distinct control plane layer it would be > >>> defined in a framework, not a requirements document. > >>> > >>>>>>>>> It would be trivial to make this FR#1 and renumber the rest. > >>>>>>>>> > >>>>>>>> > >>>>>>>> I don't think the FR helped clarify the above question. > >>>>>>> > >>>>>>> The choice of the word "indicate" in FR10-13, FR14, FR15 does not > >>>>>>> imply usage by a specific layer. That is a direct answer to your > >>>>>>> question. > >>>>>>> > >>>>>>> In all of these specific cases, the the client layer is passing a > >>>>>>> requirement to the server layer so in the IGP + RSVP-TE world that > >>>>>>> would be a function of RSVP-TE. In the absense of control plane, it > >>>>>>> would have to be done through management plane interaction where the > >>>>>>> client indicates requirements of an LSP and the server layer is free > >>>>>>> to figure out how to meet those requirements. > >>>>>>> > >>>>>>> Do you want me to add the clarification on the use of the word > >>>>>>> "indicate" or not? > >>>>>> > >>>>>> I think you need to be clear that the requirement applies to all three > >>>>>> layers. > >>>>> > >>>>> There are no distinct three layers. You are imagining a model that is > >>>>> not used in this document so please don't impose model on our document. > >>>>> > >>>> > >>>> Well your old definition of Client LSP said that it was a client of > >>>> "multipath" and else where you say that "multipath" operates over a > >>>> server layer. As mentioned above, this sounds like three layers to me. > >>>> If this is not your intent, I think you need to make it clear (through > >>>> revised text) what model you do intend. > >>> > >>> This is the current text in -13: > >>> > >>> Client LSP > >>> A client LSP is an LSP which has been set up over a server layer. > >>> In the context of this discussion, a client LSP is a LSP which > >>> has been set up over a multipath as opposed to an LSP > >>> representing the multipath itself or any LSP supporting a > >>> component links of that multipath. > >>> > >>> The text is trying to clarify what a "client LSP" is in the first > >>> sentence and then trying to give two cases of what a client LSP is > >>> not. This clarification was specifically added *for you* in the last > >>> iteration. > >>> > >>> There was no intention to imply that Advanced Multipath is or is not > >>> in of itself a type of layer. If you are getting that notion from > >>> this text, then we need to change it. > >>> > >>> OLD: > >>> > >>> Client LSP > >>> A client LSP is an LSP which has been set up over a server layer. > >>> In the context of this discussion, a client LSP is a LSP which > >>> has been set up over a multipath as opposed to an LSP > >>> representing the multipath itself or any LSP supporting a > >>> component links of that multipath. > >>> > >>> NEW: > >>> > >>> Client LSP > >>> > >>> A client LSP is an LSP which has been set up over a set of one > >>> or more lower layers. In the context of this discussion, one > >>> type of client LSP is a LSP which has been set up over an AMG. > >>> > >>> We could also add a clarification to the definitions section that > >>> states: > >>> > >>> This document makes no statement on whether Advanced Multipath is > >>> itself a layer or whether an instance of AMG is itself a layer. > >>> This is to avoid engaging in long and pointless discussions about > >>> what consistitutes a proper layer. > >>> > >>> I would *really* like to add the above statement. > >>> > >>>>> In your sentence above I have no idea what "the requirement" refers to. > >>>>> > >>>>> In summary: > >>>>> > >>>>> We were discussing why the word "indicate" was used to avoid requiring > >>>>> specific mechanisms for information passing and I asked if I should > >>>>> add the following. > >>>>> > >>>>> FR#0 In requirements that follow in this document the word > >>>>> "indicate" is used where information may be provided by either > >>>>> the combination of link state IGP advertisement and MPLS LSP > >>>>> signaling or via management plane protocols. In later documents > >>>>> providing framework and protocol definitions both signaling and > >>>>> management plane mechanisms MUST be defined. > >>>>> > >>>>> Information is two way. The requirements you cited were all worded in > >>>>> the form "The solution SHALL provide a means to indicate that a client > >>>>> LSP will ...". So far I have offerred to reword this to the form "The > >>>>> solution SHALL provide a means for the client layer to indicate a > >>>>> requirement that a client LSP will ..." (ie: get minimum latency, get > >>>>> bound latency, etc). > >>>>> > >>>>> Is adding FR#0 OK? > >>>>> > >>>>> Do you want this sort of rewording to make it more explicit that the > >>>>> client layer is communication a requirement for a specific client LSP? > >>>>> > >>>> > >>>> I think we need to come back to this once we resolve the "model" topic. > >>>> > >>>> ... > >>>> > >>>> Thanks, > >>>> Lou > >>> > >>> I hope it is resolved. > >>> > >>> Curtis From internet-drafts@ietf.org Sat Jan 25 11:35:49 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084E91A0095; Sat, 25 Jan 2014 11:35:49 -0800 (PST) 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 KqE_ect6AF89; Sat, 25 Jan 2014 11:35:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD461A002F; Sat, 25 Jan 2014 11:35:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-cl-requirement-14.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140125193547.17771.50081.idtracker@ietfa.amsl.com> Date: Sat, 25 Jan 2014 11:35:47 -0800 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 19:35:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Requirements for Advanced Multipath in MPLS Netwo= rks Authors : Curtis Villamizar Dave McDysan So Ning Andrew Malis Lucy Yong Filename : draft-ietf-rtgwg-cl-requirement-14.txt Pages : 16 Date : 2014-01-25 Abstract: This document provides a set of requirements for Advanced Multipath in MPLS Networks. Advanced Multipath is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to existing multipath techniques. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-requirement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-cl-requirement-14 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 internet-drafts@ietf.org Sat Jan 25 11:53:47 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB7C1A0027; Sat, 25 Jan 2014 11:53:47 -0800 (PST) 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 AS_eGRPnWf9E; Sat, 25 Jan 2014 11:53:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C121A003B; Sat, 25 Jan 2014 11:53:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-cl-requirement-15.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140125195345.10961.21583.idtracker@ietfa.amsl.com> Date: Sat, 25 Jan 2014 11:53:45 -0800 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 19:53:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Requirements for Advanced Multipath in MPLS Netwo= rks Authors : Curtis Villamizar Dave McDysan So Ning Andrew Malis Lucy Yong Filename : draft-ietf-rtgwg-cl-requirement-15.txt Pages : 16 Date : 2014-01-25 Abstract: This document provides a set of requirements for Advanced Multipath in MPLS Networks. Advanced Multipath is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to existing multipath techniques. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-requirement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-cl-requirement-15 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 stephane.litkowski@orange.com Tue Jan 28 01:33:19 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0F11A0360; Tue, 28 Jan 2014 01:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 8xBH0caaxmIS; Tue, 28 Jan 2014 01:33:16 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E77DC1A02DF; Tue, 28 Jan 2014 01:33:11 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 89F9922C231; Tue, 28 Jan 2014 10:33:08 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 69A8C4C07F; Tue, 28 Jan 2014 10:33:08 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.46]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 28 Jan 2014 10:33:08 +0100 From: To: Uma Chunduri , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Date: Tue, 28 Jan 2014 10:33:07 +0100 Subject: RE: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt Thread-Index: AQHPF3JFo3GE3viSUkOOoMHwgUfchZqSxScwgAcbc8A= Message-ID: <30325_1390901588_52E77954_30325_3841_1_EEE55384044474429A926C625D0FCC8109A2C6F491@PUEXCB2F.nanterre.francetelecom.fr> References: <20140122130217.15321.92624.idtracker@ietfa.amsl.com> <1B502206DFA0C544B7A60469152008633F177B7E@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F177B7E@eusaamb105.ericsson.se> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.28.18 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 09:33:19 -0000 Hi Uma, Thanks for your comment, please some mine inline. -----Message d'origine----- De=A0: rtgwg [mailto:rtgwg-bounces@ietf.org] De la part de Uma Chunduri Envoy=E9=A0: jeudi 23 janvier 2014 22:24 =C0=A0: internet-drafts@ietf.org; i-d-announce@ietf.org Cc=A0: rtgwg@ietf.org Objet=A0: RE: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt Dear Authors, I have given some comments to you only, on the earlier version of this dra= ft few months back and I see some of them are taken care. Thx. After re-reading this version, I felt this is indeed addressing the import= ant aspect and the value of policy based selection of alternatives As oppos= ed to the alternatives with best protection. This document brings out lot o= f use cases and the configuration knobs to achieve the goal of the "policy"= based preference on possible LFAs. However, I see some of the sections documented are not directly related to = the uses cases presented in Section 2, which in principle shows how and why= the best protection is not good (excluding the IS-IS overload case) in all= cases.=20 For example: 1. Section 3.1, which suggests the activation granularity requirement of t= he LFAs from Context, instance to address-family and per-prefix.=20 Here some of the choices are natural but I don't think this addresses= any of the problems documented in Section 2. "..This means that if a specific prefix must be protected due to a configuration request, LFA must be computed and installed for this prefix even if the primary outgoing interface is not configured for protection." Could you clarify the must (2) in the sentence? Do you intend to say = "MUST" there? [SLI] "must" is not RFC2119 "MUST" :) The idea is just, as mentioned in the previous sentence that "per prefix pr= otection" overrides "per interface protection" configuration. Also I feel, for example, having per-prefix granularity for provision= ing LFA or not is an implementation choice than an interoperability=20 issue while deployment. [SLI] Agree ...=20 2. Section 4.3, "Required local information" Says - "MUST provide coverage information per activation domain of LFA (area, level, topology, instance, virtual router, address family ...)." To me this is good to have information and be very helpful for the ope= rator but I am not sure mandating the coverage information granularity is addressing any of the issues presented in Section 2. [SLI] When deploying LFA, coverage information is mandatory for the SP as c= overage may change as topology is changing. Maybe we can mention this in se= ction 2. What do you feel ? 3. Similarly Section 4.4 coverage monitoring guidelines for the vendor impl= ementations are good ones but these are neither addressing any issues=20 presented in Section 2 nor helping solve any interoperability issue.= =20 The problem I see with this is lot of implementations may quickly become no= n-compliant from customers point of view once this becomes RFC. Do you see = that way? [SLI] As mentionned in previous comment, coverage informations are mandator= y to be able to maintain LFA deployment (SP experience speaking ...). As pr= oposed, I can add something in section 2 to detail the need.=20 Specific review Comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Section 2.1 When the core link R8-R7 fails, R8 switches all traffic destined to all the PEx towards the edge node PE2. What is "all the PEx"?? [SLI] PEx is a set a PE. 2. Section 2.2 "In the figure 2, let us consider the traffic coming from PE1 to PEx. Nominal path is R9-R8-R7-R6-PEx." You might mean to say R9-R8-R7-R10-R6-PEx ? Can you clarify? [SLI] Right this is a mistake, I will fix it. Thanks 3. Section 2.3 Though it's not important to illustrate your point of using sub-optimal = core links as LFA, it's good to mention the link costs of R3-PE1 and PE1-R4. Otherwise PE1 could become another potential node protecting alternative= via non-core or whatever.. (at least can avoid confusion for the reader). [SLI] Agree, will fix it. 4. For IGPs what exactly you meant when you say "topology" and how this is= different than first bullet "Per address-family"? [SLI] Topology refers to multitopology IGP (MT extensions), this may be dif= ferent from address family (OSPF for IPv6 is not a multitopology OSPF case) 5. Section 3.2.1 "Especially, computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD = to be performed before best alternate selection." =20=20=20 SHOULD to be =3D=3D> SHOULD be =20=20=20 [SLI] will fix it. Also, say you might have a legacy node to deal with and you are not abl= e to establish TLDP with PQ here=20 in that case, you might look for a knob to choose the policy (remote or = local policy). [SLI] This may be managed by "neighbor exclude" policy statement. 6. "3.2.5. Details on criterions"=20 Didn't understand the title and all sub-sections listed under should = instead be 3.2.x level? I am saying this because I lost=20 where I was while reading. I would suggest to re-organize better [SLI] Why not ... the idea is to give details on how each attribute should = be retrieved. So do you prefer to move all subsections to 3.2.x ? I'm ok with that. 7. 3.2.5.1. LFA and ECMP It should have been "ECMP LFAs" [SLI] Ok =20=20=20 And.. "As mentioned in [RFC5286] Section 3.4., protecting a link within an ECMP by another primary nexthop is not a MUST. Moreover, we already presented in this document, that maximizing the coverage of the failure case may not be the right approach and policy based choice of alternate may be preferred." If you just want to prevent one of the other ECMP link as LFA then you c= an provision "local" SRLGs. Then in this case you might get L3 or L4 but you are seeking both as LFA= s. I see the current text put Lot of emphasis on the point of not using one of the primary ECMP path= s as alternatives with citation=20 on RFC 5286.=20 However, you are *also* seeking for an ECMP LFA (if available, instead = of tie breaking and give one LFA eventually from the non-bundle). Also I didn't fully understand how can one enforce this as one can have = another equal cost=20 alternate (non-bundled) path from PE1 to PE2 via P2 or some Px node. It = seems in this case you are looking for all non-ECMP LFAs to be installed as alternatives?=20 [SLI] You are right.=20 8. Section 3.2.5.5 "Rather than tagging interface on each node (using link color) to identify neighbor node type (as example), it would be helpful if routers could be identified in the IGP. " =20=20=20 a) After this it completely talks IS-IS language. Probably this should = be revisited to make it generic or applicable to the other IGP. b) Coming to IS-IS, you referred I-D.psarkar-isis-node-admin-tag but th= e text suggests, its own algorithm to identify the neighbor with=20 TLV135 and is not complete in many fronts.=20 =20=20=20=20 I would suggest revisit this section completely to focus on the point your= of "neighbor preference" rather than incomplete IGP details.=20 [SLI] Agree, will fix it 9. Section 4.5 "4.5. Deterministic and documents LFA selection behavior" The title didn't sound correct. [SLI] Ok will fix it -- Uma C. -----Original Message----- From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Wednesday, January 22, 2014 5:02 AM To: i-d-announce@ietf.org Cc: rtgwg@ietf.org Subject: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Operational management of Loop Free Alternates Authors : Stephane Litkowski Bruno Decraene Clarence Filsfils Kamran Raza Martin Horneffer Pushpasis Sarkar Filename : draft-ietf-rtgwg-lfa-manageability-01.txt Pages : 21 Date : 2014-01-22 Abstract: Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic (and MPLS LDP traffic by extension). Following first deployment experiences, this document provides operational feedback on LFA, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. This proposal is also applicable to remote LFA solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-lfa-manageability-01 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From stephane.litkowski@orange.com Tue Jan 28 06:05:57 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252941A03FE for ; Tue, 28 Jan 2014 06:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 zs5CcLLU9hLa for ; Tue, 28 Jan 2014 06:05:53 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 748431A03FD for ; Tue, 28 Jan 2014 06:05:52 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 4AB132AC862; Tue, 28 Jan 2014 15:05:49 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 3729D384077; Tue, 28 Jan 2014 15:05:49 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.46]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 28 Jan 2014 15:05:49 +0100 From: To: Maik Pfeil Date: Tue, 28 Jan 2014 15:05:48 +0100 Subject: RE: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt Thread-Index: Ac8Xe0cz4blWJRgLQ1WlxPDayMGB9wEto2cA Message-ID: <31713_1390917949_52E7B93D_31713_2037_11_EEE55384044474429A926C625D0FCC8109A2C6F681@PUEXCB2F.nanterre.francetelecom.fr> References: <20140122130217.15321.92624.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC8109A2C6F681PUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 14:05:57 -0000 --_000_EEE55384044474429A926C625D0FCC8109A2C6F681PUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Maik, Here is a proposed new text, let me know if it fits your comment : "Service providers often perform manual link shutdown (using router CLI) to perform some network changes/tests. A manual link shutdown may be done at multiple level : physical interface, logical interface, IGP interface, BFD session ... Especially testing or troubleshooting FRR requires to perform the manual shutdown on the remote end of the link as generally a local shutdown would not trigger FRR. To enhance such situation, an implementation SHOULD support triggering/activating LFA Fast Reroute for a given link when a manual shutdown is done on a component that currently supports FRR activation. For example : o if an implementation supports FRR activation upon BFD session down event, this implementation SHOULD support FRR activation when a manual shutdown is done on the BFD session. But if an implementation does not support FRR activation on BFD session down, there is no need for this implementation to support FRR activation on manual shutdown of BFD session. o if an implementation supports FRR activation on physical link down event (e.g. Rx laser Off detection, or error threshold raised ...), this implementation SHOULD support FRR activation when a manual shutdown at physical interface is done. But if an implementation does not support FRR activation on physical link down event, there is no need for this implementation to support FRR activation on manual physical link shutdown. " Stephane De : rtgwg [mailto:rtgwg-bounces@ietf.org] De la part de Maik Pfeil Envoy=E9 : mercredi 22 janvier 2014 15:07 Cc : rtgwg@ietf.org Objet : Re: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt Hi, as stated in section 4.2 To enhance such situation, an implementation SHOULD support triggering/activating LFA Fast Reroute for a given link when a manual shutdown is done. The triggering of a FRR could also happen by BFD in some implementations. T= he last sentence should be more generalized or even get more details. What = exactly should a "shutdown" trigger? For e.g. a tx-laser off on local side = -> triggers LFA on remote side. // Maik 2014/1/22 > A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Operational management of Loop Free Alternates Authors : Stephane Litkowski Bruno Decraene Clarence Filsfils Kamran Raza Martin Horneffer Pushpasis Sarkar Filename : draft-ietf-rtgwg-lfa-manageability-01.txt Pages : 21 Date : 2014-01-22 Abstract: Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic (and MPLS LDP traffic by extension). Following first deployment experiences, this document provides operational feedback on LFA, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. This proposal is also applicable to remote LFA solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-lfa-manageability-01 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/ _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC8109A2C6F681PUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Maik,

 

=

Here is a proposed new text, let m= e know if it fits your comment :

 

“Service providers often perform manual =
link shutdown (using router

=A0=A0= CLI) to perform some network changes/tests.=A0 A manual link shutdown=

=A0=A0 may be done at multiple level : p= hysical interface, logical

=A0=A0 in= terface, IGP interface, BFD session ...=A0 Especially testing or=

=A0=A0 troubleshooting FRR requires to perform= the manual shutdown on the

=A0=A0 r= emote end of the link as generally a local shutdown would not

=A0=A0 trigger FRR.=A0

 

To enhance su= ch situation, an implementation SHOULD

=A0=A0 a manual shutdown is done= on a component that currently supports FRR

=A0=A0 activation.

&n= bsp;

=A0=A0 For example :

 

=A0= =A0 o=A0 if an implementation supports FRR activation upon BFD session down=

=A0=A0=A0=A0=A0 event, this impleme= ntation SHOULD support FRR activation when a

=A0=A0=A0=A0=A0 manual shutdown is done on the BFD session.=A0 Bu= t if an

=A0=A0=A0=A0=A0 implementat= ion does not support FRR activation on BFD session

=A0=A0=A0=A0=A0 down, there is no need for this implementati= on to support FRR

=A0=A0=A0=A0=A0 ac= tivation on manual shutdown of BFD session.

 

=A0=A0 o=A0 if an i= mplementation supports FRR activation on physical link down

=A0=A0=A0=A0=A0 event (e.g.=A0 Rx laser Off detecti= on, or error threshold raised

=A0=A0= =A0=A0=A0 ...), this implementation SHOULD support FRR activation when a

=A0=A0=A0=A0=A0 manual shutdown at phy= sical interface is done.=A0 But if an

=A0=A0=A0=A0=A0 down event,= there is no need for this implementation to support

<= p class=3DMsoNormal>=A0=A0=A0=A0=A0 FRR activation on manual physical link shu= tdown.

 

 

“

 

 

Stephane

 

 

De : rtgwg = [mailto:rtgwg-bounces@ietf.org] De la part de Maik Pfeil
Envoy= =E9 : mercredi 22 janvier 2014 15:07
Cc : rtgwg@iet= f.org
Objet : Re: I-D Action: draft-ietf-rtgwg-lfa-manageabi= lity-01.txt

 

=

Hi,

=  

as stated in section 4.2

<snip>

 To enhance such s=
ituation, an implementation SHOULD
=A0=A0 support triggering/activating LFA =
Fast Reroute for a given link when
=A0=A0 a manual shutdown is done.
</snip=
>
 
 
The triggering of a FRR could also happen by BFD in some imple=
mentations. The last sentence should be more generalized or even get more d=
etails. What exactly should a "shutdown" trigger? For e.g. a tx-l=
aser off on local side -> triggers LFA on remote side. 
 <=
/span>
 
&nb=
sp;
// =
Maik
 
 
 
 

 

2014/1/22 <internet-drafts@ietf.org>


A New Internet-Draft is available from the on-line Internet-D= rafts directories.
 This draft is a work item of the Routing Area W= orking Group Working Group of the IETF.

        = Title           : Operational management of Loop F= ree Alternates
        Authors       =   : Stephane Litkowski
            &n= bsp;             Bruno Decraene
  &nb= sp;                     &= nbsp; Clarence Filsfils
             =             Kamran Raza
    &nb= sp;                     M= artin Horneffer
                =           Pushpasis Sarkar
     =   Filename        : draft-ietf-rtgwg-lfa-manageab= ility-01.txt
        Pages       &nbs= p;   : 21
        Date       &nb= sp;    : 2014-01-22

Abstract:
   Loop Free Al= ternates (LFA), as defined in RFC 5286 is an IP Fast
   ReRout= e (IP FRR) mechanism enabling traffic protection for IP traffic
  &= nbsp;(and MPLS LDP traffic by extension).  Following first deployment<= br>   experiences, this document provides operational feedback on= LFA,
   highlights some limitations, and proposes a set of re= finements to
   address those limitations.  It also propo= ses required management
   specifications.

   = ;This proposal is also applicable to remote LFA solution.



Th= e IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/<= br>
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-01
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-lfa-manageabili= ty-01


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.o= rg/internet-drafts/

____________________________________________= ___
rtgwg mailing list
rtgwg@ietf.o= rg
https://www.ietf.org/mailman/listinfo/rtgwg

 

______________=
___________________________________________________________________________=
________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_EEE55384044474429A926C625D0FCC8109A2C6F681PUEXCB2Fnante_-- From lberger@labn.net Tue Jan 28 15:06:29 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2180E1A03D8 for ; Tue, 28 Jan 2014 15:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable 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 ker44hEAQNx9 for ; Tue, 28 Jan 2014 15:06:24 -0800 (PST) Received: from oproxy4-pub.mail.unifiedlayer.com (oproxy4-pub.mail.unifiedlayer.com [74.220.216.66]) by ietfa.amsl.com (Postfix) with SMTP id 49EDB1A03CC for ; Tue, 28 Jan 2014 15:06:24 -0800 (PST) Received: (qmail 2888 invoked by uid 0); 28 Jan 2014 23:06:21 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy4.mail.unifiedlayer.com with SMTP; 28 Jan 2014 23:06:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=6QmzKPN4Y81s4kamU7ZtJNJ7UVPuOo3busMaAm9Yocw=; b=P4DEs8/g76V8vWOQ6LrqMWYxolhO2iCaWRsqZ8/Qy3mgEMkZ7MViW9LwvSWDq84OEv5GgnEpSen6Rogf+61+b/whwBwOVCrra73P1Wml3WW6zbVedUXFPFH0UmZv3Zjo; Received: from box313.bluehost.com ([69.89.31.113]:59650 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1W8HjZ-0008Rn-AT; Tue, 28 Jan 2014 16:06:21 -0700 Message-ID: <52E837E8.3000001@labn.net> Date: Tue, 28 Jan 2014 18:06:16 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com Subject: Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 References: <201401251920.s0PJKtA4047788@maildrop2.v6ds.occnc.com> In-Reply-To: <201401251920.s0PJKtA4047788@maildrop2.v6ds.occnc.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, "rtg-ads@tools.ietf.org" , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 23:06:29 -0000 Curtis, The changes in the current rev address most of my comments and the document is significantly less ambiguous. I'm still not a big fan of how client and layers are used in the document, but I think this is in the weeds and we should move on and not engage, as the draft says, "in long and pointless discussions". Lou On 1/25/2014 2:20 PM, Curtis Villamizar wrote: > Lou, > > I am in the process of submitting a -14 version followed with only the > changes for the OpsDir review followed by a -15 version with the > additional changes from your RtgDir review. Please wait for the -15 > version if you see the -14 and not the -15. > > Curtis > > > In message <52D96FFD.1020408@labn.net> > Lou Berger writes: >> >> sounds like a plan! >> >> Lou >> >> On 01/17/2014 12:41 PM, Curtis Villamizar wrote: >>> In message <52D88F77.5020009@labn.net> >>> Lou Berger writes: >>> >>>> Curtis, >>>> I'm not sure if we're going around in circles or not, but in either >>>> case case I think we're getting caught up in the weeds/details. >>>> >>>> >From a high level perspective, my comments have been motivated by trying >>>> to ensure the requirements are unambiguous -- as documented. I think >>>> the text changes that have been agreed to so far (notably the use of the >>>> capitalized term and introduction of AMG) will help a lot. I think there >>>> is still one more area that is unclear, but it's also possible that >>>> we're arguing about text that you are planning to change. >>>> >>>> Do you have a version that captures all the changes to date that you can >>>> distribute (or submit, as you choose)? Perhaps looking at this version >>>> we'll find that the ambiguity is resolved or is sufficiently narrowed to >>>> not be significant. Either way, the discussion can then continue from >>>> the most current text. >>>> >>>> Thanks, >>>> Lou >>> >>> >>> Lou, >>> >>> I was going to suggest the same (if I understand your suggestion) - >>> that is that a new draft be submitted and you (and others) can review >>> and see if clarity has been sufficiently improved or if there are >>> still issues with clarity. >>> >>> If that is OK with you and compatible with this process I will make >>> two draft submissions back to back. One with just the OpsDir review >>> comments addressed and a second with your comments so far addressed. >>> IMHO it would be easier to discuss the clarity (or lack of) of the >>> wording once changes have been made particularly since there are a few >>> s/old/new/g terminology suggestions in the email thread. >>> >>> Curtis >>> >>> >>>> On 1/15/2014 7:00 PM, Curtis Villamizar wrote: >>>>> In message <52D02F67.9070604@labn.net> >>>>> Lou Berger writes: >>>>> >>>>>> Curtis, >>>>>> >>>>>> I think we have one disconnect (and corresponding related text) that we >>>>>> need to resolve before we can be close the discussion. See below for >>>>>> details.. >>>>>> >>>>>> On 1/8/2014 11:33 PM, Curtis Villamizar wrote: >>>>>>> Converging. But maybe one more round trip needed. >>>>>>> >>>>>>> In message <52CD9D58.4010109@labn.net> >>>>>>> Lou Berger writes: >>>>>>>> >>>>>> ... >>>>>> >>>>>>>>>>>> 2. Editorial: server and client layer vs upper and lower layer. >>>>>>>>>>>> >>>>>>>>>>>> The document uses server and client layer networks and LSPs and, >>>>>>>>>>>> sometimes interchangeably or redundantly, upper and lower layer networks >>>>>>>>>>>> and LSPs. I think this issue can be resolved by avoiding the term >>>>>>>>>>>> client/server when referring to network layers and just using the >>>>>>>>>>>> lower/upper terminology. The one exception to this is in the definition >>>>>>>>>>>> Client LSP which should simply be defined in the context of a multipath, >>>>>>>>>>>> i.e.: >>>>>>>>>>>> OLD >>>>>>>>>>>> A client LSP is an LSP which has been set up over a server layer. >>>>>>>>>>>> NEW >>>>>>>>>>>> A client LSP is an LSP which has been set up over Advanced Multipath. >>>>>>>>>>> >>>>>>>>>>> A client LSP can be set up over a server layer MPLS-TP LSP or any >>>>>>>>>>> server layer MPLS LSP or over a link layer or over a pseudowire ... or >>>>>>>>>>> over an advanced multipath. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Would you accept s/server layer/lower layer/g? >>>>>>>>> >>>>>>>>> The definition of server layer is not the same as the definition of >>>>>>>>> lower layer. See below. >>>>>>>>> >>>>>>>>>>>> I think this also means that usage of the term "Client" is limited to >>>>>>>>>>>> "Client LSP". >>>>>>>>>>> >>>>>>>>>>> I searched for all occurances of the word client. All occurances are >>>>>>>>> />> "client LSP" excexpt the phrase "client of a client LSP" and that is >>>>>>>>>>> used only in the following paragraph. >>>>>>>>>>> >>>>>>>>>>> The ingress and egress of a multipath may be midpoint LSRs with >>>>>>>>>>> respect to a given client LSP. A midpoint LSR does not participate >>>>>>>>>>> in the signaling of any clients of the client LSP. Therefore, in >>>>>>>>>>> general, multipath endpoints cannot determine requirements of clients >>>>>>>>>>> of a client LSP through participation in the signaling of the clients >>>>>>>>>>> of the client LSP. >>>>>>>>>>> >>>>>>>>>>> THe point is that "A midpoint LSR does not participate in the >>>>>>>>>>> signaling of any clients of the client LSP" and that non-participation >>>>>>>>>>> in client (or higher layer) signaling applies to any "client of a >>>>>>>>>>> client LSP", not just other LSP running over it. >>>>>>>>>>> >>>>>>>>>>> I then searched for all occurances of the words upper and lower and >>>>>>>>>>> higher. There are no occurances of "upper". >>>>>>>>>>> >>>>>>>>>>> There were a few occurances of "lower latency" and "higher latency". >>>>>>>>>>> Other than that, all occurances of lower and higher except one are in >>>>>>>>>>> the follwoing text: >>>>>>>>>>> >>>>>>>>>>> 3.2. Component Links Provided by Lower Layer Networks >>>>>>>>>>> >>>>>>>>>>> A component link may be supported by a lower layer network. For >>>>>>>>>>> example, the lower layer may be a circuit switched network or another >>>>>>>>>>> MPLS network (e.g., MPLS-TP)). The lower layer network may change >>>>>>>>>>> the latency (and/or other performance parameters) seen by the client >>>>>>>>>>> layer. Currently, there is no protocol for the lower layer network >>>>>>>>>>> to inform the higher layer network of a change in a performance >>>>>>>>>>> parameter. Communication of the latency performance parameter is a >>>>>>>>>>> very important requirement. Communication of other performance >>>>>>>>>>> parameters (e.g., delay variation) is desirable. >>>>>>>>>>> >>>>>>>>>>> FR#8 The solution SHALL specify a protocol means to allow a lower >>>>>>>>>>> layer server network to communicate latency to the higher layer >>>>>>>>>>> client network. >>>>>>>>>>> >>>>>>>>>>> The exception is this sentence: >>>>>>>>>>> >>>>>>>>>>> FR#22 The solution SHOULD support the use case where an advanced >>>>>>>>>>> multipath itself is a component link for a higher order advanced >>>>>>>>>>> multipath. For example, an advanced multipath comprised of MPLS- >>>>>>>>>>> TP bi-directional tunnels viewed as logical links could then be >>>>>>>>>>> used as a component link in yet another advanced multipath that >>>>>>>>>>> connects MPLS routers. >>>>>>>>>>> >>>>>>>>>>> The terms lower layer and higher layer go all the way back to the ISO >>>>>>>>>>> seven layer model of ancient times (1970s?, 1980s?) and maybe further >>>>>>>>>>> back but that is before even my time. >>>>>>>>>>> >>>>>>>>>>> I don't think this is unclear but I could add the following in >>>>>>>>>>> definitions: >>>>>>>>>>> >>>>>>>>>>> Higher Layers >>>>>>>>>>> A client layer is the one immediately above a server layer. The >>>>>>>>>>> client layer and all layers above that layer are higher layers. >>>>>>>>>>> >>>>>>>>>>> Lower Layers >>>>>>>>>>> A server layer is the later immediately below a client laer. >>>>>>>>>>> The server layer and all layers below are lower layers. >>>>>>>>>>> >>>>>>>>>>> Do I really need to put this in the definitions section? If yoy think >>>>>>>>>>> it is necessary, I will add it. >>>>>>>>>>> >>>>>>>>>> Perhaps we've talked (okay written) past each other. I was suggesting >>>>>>>>>> using/keeping the "higher and lower layer" terminology, not dropping it. >>>>>>>>>> And to use it (consistently) in place of "client and server Layer". >>>>>>>>> >>>>>>>>> I guess you missed the distinction in the definition above: >>>>>>>>> >>>>>>>>> For layer X layer Y is: >>>>>>>>> >>>>>>>>> client layer === Y = X+1 >>>>>>>>> server layer === Y = X-1 >>>>>>>>> higher layer === Y > X >>>>>>>>> lower layer === Y < X >>>>>>>>> >>>>>>>>> So the definition client layer is not the same as the definition of >>>>>>>>> higher layer. The definition of server layer is not the same as the >>>>>>>>> definition of lower layer. >>>>>>>>> >>>>>>>>> In some discussions we really do mean "the server layer" and not any >>>>>>>>> layer at any arbitrary depth below this one. >>>>>>>> >>>>>>>> I read your usage of client/server layer to be synonymous with >>>>>>>> higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense >>>>>>>> of FR#8 (I think you really mean client layer not lower layer.) >>>>>>> >>>>>>> FR#8 and FR#9 are about the server layer telling the client layer >>>>>>> about the delays that can be expected. There is a little redundancy >>>>>>> here so s/ower layer server network/server network/ and >>>>>>> s/higher layer client network/client network/. No plans to skip >>>>>>> layers. >>>>>>> >>>>>> >>>>>> I think we need to hit the points below before this one... >>>>> >>>>> OK. >>>>> >>>>>>>> Given the current document usage, I still think it makes sense to >>>>>>>> eliminate the two instances of "client layer": How about the following: >>>>>>>> OLD >>>>>>>> Client LSP >>>>>>>> A client LSP is an LSP which has been set up over a server layer. >>>>>>>> In the context of this discussion, a client LSP is a LSP which >>>>>>>> has been set up over a multipath as opposed to an LSP >>>>>>>> representing the multipath itself or any LSP supporting a >>>>>>>> component links of that multipath. >>>>>>>> NEW >>>>>>>> Client LSP >>>>>>>> A client LSP is a LSP which >>>>>>>> has been set up over Advanced Multipath as opposed to an LSP >>>>>>>> representing the Advanced Multipath itself or any LSP that is >>>>>>>> part of an Advanced Multipath Group. >>>>>>> >>>>>>> Nope. In general, a client LSP can be set up over a plain old >>>>>>> Ethernet on a given hop, therefore the second definition is too >>>>>>> narrow with this change. >>>>>>> >>>>>> >>>>>> humm, you didn't have that in your OLD text. In fact, the old text >>>>>> reads to me that an Advanced Multipath (solution?) logically sits >>>>>> between a client LSP and an underlying server layer in all cases. >>>>> >>>>> The "OLD" was a quote from you and it was the original text in -13. I >>>>> said "Nope. ..." to your suggested change to it in this way. >>>>> >>>>> Earlier >>>>> (http://www.ietf.org/mail-archive/web/rtgwg/current/msg04274.html) I >>>>> had suggested the following change: >>>>> >>>>> I don't think this is unclear but I could add the following in >>>>> definitions: >>>>> >>>>> Higher Layers >>>>> A client layer is the one immediately above a server layer. The >>>>> client layer and all layers above that layer are higher layers. >>>>> >>>>> Lower Layers >>>>> A server layer is the later immediately below a client laer. >>>>> The server layer and all layers below are lower layers. >>>>> >>>>> Do I really need to put this in the definitions section? If yoy think >>>>> it is necessary, I will add it. >>>>> >>>>> You will find this in the quoted text above. >>>>> >>>>> The definition of client LSP does not imply that Advanced Multipath is >>>>> a layer. This also used lower case "multipath" which we can replace >>>>> with AMG. There is no LAG layer in a network in with MPLS runs over >>>>> Ethernet and some of the Ethernets use Link Aggregation. >>>>> >>>>>> So the model I see defined by the text has the following layers >>>>>> >>>>>> Client LSP (layer) >>>>>> ---------- >>>>>> Advanced Multipath (layer/solution/construct) >>>>>> ---------- >>>>>> Server Layer (composed of AMGs which are LSPs and/or links) >>>>>> >>>>>> Is this aligned with your intent? If not, can you explain the >>>>>> relationship you see for Advanced Multipath Client LSPs and Advanced >>>>>> Multipath AMGs? >>>>> >>>>> You imaginged this model and are trying to constrain the text to fit >>>>> into it.. >>>>> >>>>> Consider these examples of client layer and server layer. >>>>> >>>>> plain old rfc-4206 >>>>> >>>>> LSP-1 (PSC-0) = client of LSP-2 >>>>> LSP-2 (PSC-1) = server of LSP-1 >>>>> >>>>> LSP over Ethernet over PW over MPLS >>>>> >>>>> LSP-1 = client of Ethernet >>>>> Ethernet = server of LSP-1, client of PW >>>>> PW = server of Ethernet, client of LSP-2 >>>>> LSP-2 = server of PW >>>>> >>>>> There is then the question of whether Advanced Multipath is a layer or >>>>> a set of techniques that can be applied at a given layer. Example >>>>> potential config language: >>>>> >>>>> mple { >>>>> tunnel x1 { >>>>> type multipath { >>>>> component tunnel x2; >>>>> component tunnel x3; >>>>> [...] >>>>> component intf i1; >>>>> component intf i2; >>>>> [...] >>>>> } >>>>> [...] >>>>> } >>>>> [...] >>>>> } >>>>> >>>>> No distinct layer above. >>>>> >>>>> An alternate: >>>>> >>>>> mple { >>>>> tunnel x1 { >>>>> [...] >>>>> } >>>>> [...] >>>>> } >>>>> >>>>> interface amg1; >>>>> type multipath { >>>>> component tunnel x2; >>>>> component tunnel x3; >>>>> [...] >>>>> component intf i1; >>>>> component intf i2; >>>>> [...] >>>>> } >>>>> [...] >>>>> } >>>>> [...] >>>>> } >>>>> >>>>> In the former example, the tunnel x1 is forced to use a specific set >>>>> of component links and apply multipath techniques to it. >>>>> >>>>> In the latter example, if tunnel x1 happen to find that interface amg1 >>>>> was the lowest cost or otherwise preferred way to get to its >>>>> destination it makes use of amg1 and if so inherits the use of the >>>>> multipath techniques. >>>>> >>>>> There is no distinct multipath encapsulation at the date layer so some >>>>> might argue that even in the second case there is no distinct layer, >>>>> just a configuration convenience. >>>>> >>>>> Claiming that Advanced Multipath is of itself a layer may get us into >>>>> a bigger can of worms. >>>>> >>>>> For example in today's ECMP, the next hop consists of multiple >>>>> interfaces. ECMP is not considered a layer between IP and those >>>>> interfaces. Link bundle is also not considered a layer. >>>>> >>>>> In the document we have not claimed that Advanced Multipath is a type >>>>> of layer and we have not claimed that Advanced Multipath is not a type >>>>> of layer. Either way we would get someone arguing that the opposite >>>>> was true. [Some individuals it seems would pick the opposite of >>>>> whatever we picked just because they like to argue about layering.] >>>>> >>>>> Need I remind you of the painfully long and mostly pointless arguments >>>>> in MPLS during the early MPLS-TP work about whether an MPLS LSP >>>>> carried within another hierarchical MPLS LSP was a layer or a >>>>> sub-layer. We don't want to repeat that and the best way to do so is >>>>> to not make any statement about whether Advanced Multipath is a layer >>>>> or a sub-layer or a layering NOOP. >>>>> >>>>> Which of the above is the "right" way to do things may be at most a >>>>> framework issue but may not come up until management plane entities >>>>> are defined. It is certainly not a topic for a requirements document >>>>> because it is deep into the "how it gets done". >>>>> >>>>>>>> and >>>>>>>> OLD >>>>>>>> The above set of requirements apply to component links with different >>>>>>>> characteristics regardless as to whether those component links are >>>>>>>> provided by parallel physical links between nodes or provided by sets >>>>>>>> of paths across a network provided by server layer LSP. >>>>>>>> NEW >>>>>>>> The above set of requirements apply to component links with different >>>>>>>> characteristics regardless as to whether those component links are >>>>>>>> provided by parallel physical links between nodes or provided by >>>>>>>> LSPs that are part of an Advanced Multipath Group. >>>>>>> >>>>>>> What about PW? Those are paths too by the definition of paths, so >>>>>>> again, this change makes the definition too narrow. >>>>>>> >>>>>> >>>>>> PWs weren't mentioned in your OLD text, so I didn't add them. I also >>>>>> have no objections to adding them. >>>>> >>>>> Actually the text you wrote is incorrect. "The above requirement >>>>> applies to component links" can include physical links and server >>>>> layer LSP but adding that are part of an Advanced Multipath Group is >>>>> incorrect. >>>>> >>>>> I'm not sure but I think this instance of "server layer" was added to >>>>> that LSP wording because you were confused on last review about client >>>>> LSP vs LSP over which Advanced Multipath was applied so I went around >>>>> changing everything to "client LSP" or "server layer LSP" to make it >>>>> more clear to you. You now seem to be stuck on the wording that is >>>>> essentially saying "any type of component link" including "server >>>>> layer LSP". >>>>> >>>>>> The only change I made was >>>>>> s/sets of paths across a network provided by server layer LSP./ >>>>>> LSPs that are part of an Advanced Multipath Group. >>>>> >>>>> And that change was wrong. A more correct change would be >>>>> >>>>> s/provided by server layer LSP/including paths provided by server >>>>> layer LSP/ >>>>> >>>>> That would include any sort of path across the network. PW could be >>>>> considered an emulated physcial link or another usable type of path >>>>> across the network. >>>>> >>>>> The "above set of requirements" in this case have to do with passing >>>>> down requirements for min latency, bounded latency, and bounded >>>>> jitter. The original paragraph is: >>>>> >>>>> The above set of requirements apply to component links with >>>>> different characteristics regardless as to whether those component >>>>> links are provided by parallel physical links between nodes or >>>>> provided by sets of paths across a network provided by server layer >>>>> LSP. >>>>> >>>>> The intent is "The above set of requirements apply to component links" >>>>> followed by "regardless of what type of component links they are" >>>>> where we had disccssed two types being an interface or emulated >>>>> interface (or virtual interface in some major vendor terms) or an LSP >>>>> (which is also a virtual interface in some major vendor terms). >>>>> >>>>> I don't understand how you can get so hung up on the wording of what >>>>> is intended to convey "regardless of what type of component links they >>>>> are". This has always been clear to the WG. >>>>> >>>>>>>>> The word "indicate" is independent of the method of getting the >>>>>>>>> information there. But yes in the example given the IGP advertisement >>>>>>>>> and MPLS LSP signaling that might be one such mechanism does refer to >>>>>>>>> the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. >>>>>>>>> >>>>>>>>> If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there >>>>>>>>> is only one IGP flooding information for both client and server layer, >>>>>>>>> hence the seemingly endless (and mostly pointless) discussion of >>>>>>>>> sub-layer vs layer from certain ITU people in the MPLS WG mailing list >>>>>>>>> who viewed MPLS as broken for not enforcing a strict layering in this >>>>>>>>> regard. But we need not go into that level of detail in this example >>>>>>>>> of how independent of mechanism the "indicate" is and down that years >>>>>>>>> old MPLS WG terminology rat hole again. >>>>>>>>> >>>>>>>> My comment is that you need to be clear to which layer a requirement >>>>>>>> applies. Is it the server layer, the client layer or the Advanced >>>>>>>> Multipath layer? >>>>>>> >>>>>>> In each of the requirements you cited it is very clear that the client >>>>>>> later is communicating a requirement to the server layer, but if you'd >>>>>>> like I can reword to make that even more clear by rewording of the >>>>>>> form "SHALL provide a means for the client layer to indicate the >>>>>>> requirements of a client LSP [regarding X]", where X is minimize >>>>>>> latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific >>>>>>> component link (FR#13), bidirection co-routed (FR#14), no reordering >>>>>>> (FR#15), bounded frequency of rebalance (FR#20). >>>>>> >>>>>> Okay, I think this will/may help. My comment goes back to the model I >>>>>> was asking about above. And to which part of the puzzle the requirement >>>>>> applies. >>>>> >>>>> In some of the above requirements client layer communicated to the >>>>> server layer, whatever the server layer is. Means of communication >>>>> presumed to be RSVP-TE but we can't say that until the framework and >>>>> same capability needs to be available to management plane. >>>>> >>>>> In some of the above requirements server layer communicates to the >>>>> client layer. Means of communication is presumed to be IGP >>>>> extensions, again with same capability available to management plane. >>>>> >>>>> There is no distinct Advanced Multipath layer in control plane or data >>>>> plane. And if there was a distinct control plane layer it would be >>>>> defined in a framework, not a requirements document. >>>>> >>>>>>>>>>> It would be trivial to make this FR#1 and renumber the rest. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I don't think the FR helped clarify the above question. >>>>>>>>> >>>>>>>>> The choice of the word "indicate" in FR10-13, FR14, FR15 does not >>>>>>>>> imply usage by a specific layer. That is a direct answer to your >>>>>>>>> question. >>>>>>>>> >>>>>>>>> In all of these specific cases, the the client layer is passing a >>>>>>>>> requirement to the server layer so in the IGP + RSVP-TE world that >>>>>>>>> would be a function of RSVP-TE. In the absense of control plane, it >>>>>>>>> would have to be done through management plane interaction where the >>>>>>>>> client indicates requirements of an LSP and the server layer is free >>>>>>>>> to figure out how to meet those requirements. >>>>>>>>> >>>>>>>>> Do you want me to add the clarification on the use of the word >>>>>>>>> "indicate" or not? >>>>>>>> >>>>>>>> I think you need to be clear that the requirement applies to all three >>>>>>>> layers. >>>>>>> >>>>>>> There are no distinct three layers. You are imagining a model that is >>>>>>> not used in this document so please don't impose model on our document. >>>>>>> >>>>>> >>>>>> Well your old definition of Client LSP said that it was a client of >>>>>> "multipath" and else where you say that "multipath" operates over a >>>>>> server layer. As mentioned above, this sounds like three layers to me. >>>>>> If this is not your intent, I think you need to make it clear (through >>>>>> revised text) what model you do intend. >>>>> >>>>> This is the current text in -13: >>>>> >>>>> Client LSP >>>>> A client LSP is an LSP which has been set up over a server layer. >>>>> In the context of this discussion, a client LSP is a LSP which >>>>> has been set up over a multipath as opposed to an LSP >>>>> representing the multipath itself or any LSP supporting a >>>>> component links of that multipath. >>>>> >>>>> The text is trying to clarify what a "client LSP" is in the first >>>>> sentence and then trying to give two cases of what a client LSP is >>>>> not. This clarification was specifically added *for you* in the last >>>>> iteration. >>>>> >>>>> There was no intention to imply that Advanced Multipath is or is not >>>>> in of itself a type of layer. If you are getting that notion from >>>>> this text, then we need to change it. >>>>> >>>>> OLD: >>>>> >>>>> Client LSP >>>>> A client LSP is an LSP which has been set up over a server layer. >>>>> In the context of this discussion, a client LSP is a LSP which >>>>> has been set up over a multipath as opposed to an LSP >>>>> representing the multipath itself or any LSP supporting a >>>>> component links of that multipath. >>>>> >>>>> NEW: >>>>> >>>>> Client LSP >>>>> >>>>> A client LSP is an LSP which has been set up over a set of one >>>>> or more lower layers. In the context of this discussion, one >>>>> type of client LSP is a LSP which has been set up over an AMG. >>>>> >>>>> We could also add a clarification to the definitions section that >>>>> states: >>>>> >>>>> This document makes no statement on whether Advanced Multipath is >>>>> itself a layer or whether an instance of AMG is itself a layer. >>>>> This is to avoid engaging in long and pointless discussions about >>>>> what consistitutes a proper layer. >>>>> >>>>> I would *really* like to add the above statement. >>>>> >>>>>>> In your sentence above I have no idea what "the requirement" refers to. >>>>>>> >>>>>>> In summary: >>>>>>> >>>>>>> We were discussing why the word "indicate" was used to avoid requiring >>>>>>> specific mechanisms for information passing and I asked if I should >>>>>>> add the following. >>>>>>> >>>>>>> FR#0 In requirements that follow in this document the word >>>>>>> "indicate" is used where information may be provided by either >>>>>>> the combination of link state IGP advertisement and MPLS LSP >>>>>>> signaling or via management plane protocols. In later documents >>>>>>> providing framework and protocol definitions both signaling and >>>>>>> management plane mechanisms MUST be defined. >>>>>>> >>>>>>> Information is two way. The requirements you cited were all worded in >>>>>>> the form "The solution SHALL provide a means to indicate that a client >>>>>>> LSP will ...". So far I have offerred to reword this to the form "The >>>>>>> solution SHALL provide a means for the client layer to indicate a >>>>>>> requirement that a client LSP will ..." (ie: get minimum latency, get >>>>>>> bound latency, etc). >>>>>>> >>>>>>> Is adding FR#0 OK? >>>>>>> >>>>>>> Do you want this sort of rewording to make it more explicit that the >>>>>>> client layer is communication a requirement for a specific client LSP? >>>>>>> >>>>>> >>>>>> I think we need to come back to this once we resolve the "model" topic. >>>>>> >>>>>> ... >>>>>> >>>>>> Thanks, >>>>>> Lou >>>>> >>>>> I hope it is resolved. >>>>> >>>>> Curtis > > > > > From akatlas@gmail.com Fri Jan 31 17:42:19 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CF51ACCE9 for ; Fri, 31 Jan 2014 17:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yB7qCtAdr6Ca for ; Fri, 31 Jan 2014 17:42:18 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E3FDD1ACCE0 for ; Fri, 31 Jan 2014 17:42:17 -0800 (PST) Received: by mail-yk0-f170.google.com with SMTP id 9so27924974ykp.1 for ; Fri, 31 Jan 2014 17:42:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=af6DAdNWZJtDyMiWedxSGepW+gCg+EEkEFf6oRVUGjU=; b=mXkMggkjvE18Fdza3E5BlqX7IO9piOErpC0xmt1xRIKI3f1eh8dj2dvtXirC4drwAC W1LXViPA3Dyg+QuOz98fRQNUrAJ7qr/8j2963rle0MGuDk1BLRkMvTPsODkJNKLMeyte Fa/ECykZZqFdqZ4tRlr2w1gQDtK6Q83ixSniAGYZCkrgRT0P9GdCV67XVqnr4o7wNk31 6cm33obD5q2vW5GYe3UprEyv1AgXgF9l8WwvsOr9vDivseqmRatxiwlphRO/kL3u2sjk wJQs+Ze8rx/IvmDw+/+FToJQfiHlO8uZHG0WMXbbynU4lsYv8mOzlbdbdI3DTMEVhruJ N+Ow== MIME-Version: 1.0 X-Received: by 10.236.112.242 with SMTP id y78mr44348yhg.94.1391218934050; Fri, 31 Jan 2014 17:42:14 -0800 (PST) Received: by 10.170.186.88 with HTTP; Fri, 31 Jan 2014 17:42:14 -0800 (PST) Date: Fri, 31 Jan 2014 20:42:14 -0500 Message-ID: Subject: rtgwg scheduled Mon 13:00-15:00 (prelim agenda) From: Alia Atlas To: "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary=20cf300e50235e725e04f14e6685 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 01:42:19 -0000 --20cf300e50235e725e04f14e6685 Content-Type: text/plain; charset=ISO-8859-1 Just a quick heads up that rtgwg will be Mon afternoon. Alia --20cf300e50235e725e04f14e6685 Content-Type: text/html; charset=ISO-8859-1
Just a quick heads up that rtgwg will be Mon afternoon.

Alia
--20cf300e50235e725e04f14e6685--