From nobody Wed May 6 05:53:50 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6811A6FDB for ; Wed, 6 May 2015 05:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 OEpxfP7MQMj7 for ; Wed, 6 May 2015 05:53:46 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A4E1A6F7C for ; Wed, 6 May 2015 05:53:46 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t46Crhd7016075 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 May 2015 12:53:44 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t46CrfGn017223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 May 2015 14:53:41 +0200 Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 May 2015 14:53:41 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.247]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0235.001; Wed, 6 May 2015 14:53:40 +0200 From: "Wiehe, Ulrich (Nokia - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Load Use Case justifying endpoint load reports Thread-Index: AQHQg3dzbxKdB585Mk+jIr4ro6rrCZ1u7djA Date: Wed, 6 May 2015 12:53:40 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006682288E847@DEMUMBX014.nsn-intra.net> References: <55427AF7.6090002@usdonovans.com> In-Reply-To: <55427AF7.6090002@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4619 X-purgate-ID: 151667::1430916824-00004750-29CD4179/0/0 Archived-At: Subject: Re: [Dime] Load Use Case justifying endpoint load reports X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 12:53:49 -0000 Hi Steve, I'm not against your proposal, however, it has been argued that (according to established routing principles) in step 4) Destination-Host is not part of the information used to determine the route. Any reaction to this? Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Thursday, April 30, 2015 8:57 PM To: dime@ietf.org Subject: [Dime] Load Use Case justifying endpoint load reports All, There has been some offline discussion about whether or not the Diameter=20 Load mechanism should include two types of Load reports. I believe=20 there is consensus that there is the need for a peer load report to=20 support load balancing when routing requests to the next hop. The question is whether or not we should also support an "endpoint" load=20 report. This load report would be the load of a server (or a client)=20 and would be carried end-to-end. The case for an endpoint load report can be supported by the following=20 use case. Assume a Diameter network for a Diameter application where the servers=20 are partitioned across the user space. For simplicity, assume that user=20 identities starting with the numbers 0 through 4 are handled by=20 partition 1 and that user identities starting with the numbers 5 through=20 9 are handled by partition 2. Also assume that each partition has three servers -- P1S1, P1S2 and P1S2=20 in partition 1 and P2S1, P2S2 AND P2S3 in partition 2. Next assume that there is a database that maps user identities to=20 partitions. This scenario assumes that the database is a standalone=20 device that has some query mechanism for accessing the mapping. =20 Different implementations are possible. The query has the user identity=20 as the key and a set of Diameter servers as the response. This query=20 does NOT return anything but the set of servers able to handle requests=20 for the user id presented. Specifically, the query does not return the=20 load of the servers. Now, assume the following network topology: P1S1 P1S2 P1S3 P2S1 P2S2 P2S3 \ | / \ | / ------- ------- / \ / \ P1A1 P1A2 P2A1 P2A2 | | | | ------------------------------------- | | DB---- AA1 AA2-----DB \ / C The lines are for convenience, they are not meant to imply anything=20 physical, just that AA1 has connections to P1A1, P1A2, P2A1 and P2A2,=20 for instance. AA1 and AA2 are "access agents" and have access to the database that map=20 user identities to sets of servers. The flow of a request would be as follows: 1) C - Does realm routing using received peer load reports to load=20 balance between AA1 and AA2. Assume C routes to AA1. 2) AA1 queries the DB. Assume the user identity starts with the number=20 1. The DB returns the set of servers including P1S1, P1S2 and P1S3. 3) AA1 then selects the server that is to handle the request from the=20 set of servers returned. AA1 uses endpoint load reports received from=20 P1S1, P1S2 and P1S3 to makes its selection. Assume in this case that=20 AA1 selection P1S2. As a result AA1 inserts the Destination-Host AVP=20 into the request with a value of P1S2. 4) AA1 then determines the route for the request. In this case the=20 route would need to be determines based on the combination of the=20 Destination-Realm, Application-ID and the Destination-Host in the=20 request. The routing tables would indicate that P1A1 and P1A2 are the=20 candidate next hop servers for the request. This requires AA1 to have a=20 route defined for each of the servers. AA1 then uses peer load=20 information received from P1A1 and P1A2 to select the next hop. Assume=20 AA1 selects P1A1. 5) P1A1 determines that the request is targeted for P1S2 based on the=20 Destination-Host AVP. As a result it routes the request directly to=20 P1S2. P1A1 cannot use a peer report to load balance in this case as the=20 request includes the destination in the Destination-Host AVP. The endpoint load report is used in step 3 to select the server that=20 will handle the request. Peer load reports are used to select the next=20 hop. Regards, Steve _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Wed May 6 11:21:34 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA031B2E19 for ; Wed, 6 May 2015 11:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Q9C43wOaqv-A for ; Wed, 6 May 2015 11:21:31 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20BE1A8A90 for ; Wed, 6 May 2015 11:21:31 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:51997 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Yq3wl-0006Ge-2m; Wed, 06 May 2015 11:21:29 -0700 Message-ID: <554A5BA6.8020703@usdonovans.com> Date: Wed, 06 May 2015 13:21:26 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (Nokia - DE/Munich)" , "dime@ietf.org" References: <55427AF7.6090002@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E847@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006682288E847@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Dime] Load Use Case justifying endpoint load reports X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 18:21:33 -0000 Ulrich, Thanks for pointing out the argument against this use case. I understand that the default set of information used for request routing is the Destination-Realm and application-id. There is nothing, however, that says this is the only set of information that can be used. In fact, the following from section 6.1.6. in RFC6733 affirms that there are cases when additional information will be used: " Realm names and Application Ids are the minimum supported routing criteria, additional information may be needed to support redirect semantics." The case below suggests the use of Destination-Host. There are scenarios where session-ID, for session based applications, can be used. There is no reason that an agent couldn't use any AVP to make routing decisions. In addition, Diameter is being used in ways that were not anticipated by the original authors. That is a good thing. I know of many Diameter networks that fit into this use case. We need to take them into account when designing the load mechanism. Regards, Steve On 5/6/15 7:53 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote: > Hi Steve, > I'm not against your proposal, however, > it has been argued that (according to established routing principles) > in step 4) Destination-Host is not part of the information used to > determine the route. > Any reaction to this? > > Best regards > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Thursday, April 30, 2015 8:57 PM > To: dime@ietf.org > Subject: [Dime] Load Use Case justifying endpoint load reports > > All, > > There has been some offline discussion about whether or not the Diameter > Load mechanism should include two types of Load reports. I believe > there is consensus that there is the need for a peer load report to > support load balancing when routing requests to the next hop. > > The question is whether or not we should also support an "endpoint" load > report. This load report would be the load of a server (or a client) > and would be carried end-to-end. > > The case for an endpoint load report can be supported by the following > use case. > > Assume a Diameter network for a Diameter application where the servers > are partitioned across the user space. For simplicity, assume that user > identities starting with the numbers 0 through 4 are handled by > partition 1 and that user identities starting with the numbers 5 through > 9 are handled by partition 2. > > Also assume that each partition has three servers -- P1S1, P1S2 and P1S2 > in partition 1 and P2S1, P2S2 AND P2S3 in partition 2. > > Next assume that there is a database that maps user identities to > partitions. This scenario assumes that the database is a standalone > device that has some query mechanism for accessing the mapping. > Different implementations are possible. The query has the user identity > as the key and a set of Diameter servers as the response. This query > does NOT return anything but the set of servers able to handle requests > for the user id presented. Specifically, the query does not return the > load of the servers. > > Now, assume the following network topology: > > P1S1 P1S2 P1S3 P2S1 P2S2 P2S3 > \ | / \ | / > ------- ------- > / \ / \ > P1A1 P1A2 P2A1 P2A2 > | | | | > ------------------------------------- > | | > DB---- AA1 AA2-----DB > \ / > C > > The lines are for convenience, they are not meant to imply anything > physical, just that AA1 has connections to P1A1, P1A2, P2A1 and P2A2, > for instance. > > AA1 and AA2 are "access agents" and have access to the database that map > user identities to sets of servers. > > The flow of a request would be as follows: > > 1) C - Does realm routing using received peer load reports to load > balance between AA1 and AA2. Assume C routes to AA1. > > 2) AA1 queries the DB. Assume the user identity starts with the number > 1. The DB returns the set of servers including P1S1, P1S2 and P1S3. > > 3) AA1 then selects the server that is to handle the request from the > set of servers returned. AA1 uses endpoint load reports received from > P1S1, P1S2 and P1S3 to makes its selection. Assume in this case that > AA1 selection P1S2. As a result AA1 inserts the Destination-Host AVP > into the request with a value of P1S2. > > 4) AA1 then determines the route for the request. In this case the > route would need to be determines based on the combination of the > Destination-Realm, Application-ID and the Destination-Host in the > request. The routing tables would indicate that P1A1 and P1A2 are the > candidate next hop servers for the request. This requires AA1 to have a > route defined for each of the servers. AA1 then uses peer load > information received from P1A1 and P1A2 to select the next hop. Assume > AA1 selects P1A1. > > 5) P1A1 determines that the request is targeted for P1S2 based on the > Destination-Host AVP. As a result it routes the request directly to > P1S2. P1A1 cannot use a peer report to load balance in this case as the > request includes the destination in the Destination-Host AVP. > > The endpoint load report is used in step 3 to select the server that > will handle the request. Peer load reports are used to select the next > hop. > > Regards, > > Steve > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed May 6 23:49:17 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0731AD35A for ; Wed, 6 May 2015 23:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 qLxatmL7-hFZ for ; Wed, 6 May 2015 23:49:09 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB801AD2A4 for ; Wed, 6 May 2015 23:49:09 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t476n6Hb023203 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 May 2015 06:49:07 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t476n5bH015173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 May 2015 08:49:06 +0200 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 May 2015 08:49:05 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.247]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0235.001; Thu, 7 May 2015 08:49:05 +0200 From: "Wiehe, Ulrich (Nokia - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Load Use Case justifying endpoint load reports Thread-Index: AQHQg3dzbxKdB585Mk+jIr4ro6rrCZ1u7djAgAA8nwCAAPE5cA== Date: Thu, 7 May 2015 06:49:04 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006682288E970@DEMUMBX014.nsn-intra.net> References: <55427AF7.6090002@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E847@DEMUMBX014.nsn-intra.net> <554A5BA6.8020703@usdonovans.com> In-Reply-To: <554A5BA6.8020703@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6257 X-purgate-ID: 151667::1430981347-00004750-B507F761/0/0 Archived-At: Subject: Re: [Dime] Load Use Case justifying endpoint load reports X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 06:49:15 -0000 Hi Steve, thank you for the clarification. As I said, I'm not against. I rather support your proposal. Ulrich -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Wednesday, May 06, 2015 8:21 PM To: Wiehe, Ulrich (Nokia - DE/Munich); dime@ietf.org Subject: Re: [Dime] Load Use Case justifying endpoint load reports Ulrich, Thanks for pointing out the argument against this use case. I understand that the default set of information used for request=20 routing is the Destination-Realm and application-id. There is nothing,=20 however, that says this is the only set of information that can be=20 used. In fact, the following from section 6.1.6. in RFC6733 affirms=20 that there are cases when additional information will be used: " Realm names and Application Ids are the minimum supported routing criteria, additional information may be needed to support redirect semantics." The case below suggests the use of Destination-Host. There are=20 scenarios where session-ID, for session based applications, can be=20 used. There is no reason that an agent couldn't use any AVP to make=20 routing decisions. In addition, Diameter is being used in ways that were not anticipated by=20 the original authors. That is a good thing. I know of many Diameter networks that fit into this use case. We need=20 to take them into account when designing the load mechanism. Regards, Steve On 5/6/15 7:53 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote: > Hi Steve, > I'm not against your proposal, however, > it has been argued that (according to established routing principles) > in step 4) Destination-Host is not part of the information used to > determine the route. > Any reaction to this? > > Best regards > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Thursday, April 30, 2015 8:57 PM > To: dime@ietf.org > Subject: [Dime] Load Use Case justifying endpoint load reports > > All, > > There has been some offline discussion about whether or not the Diameter > Load mechanism should include two types of Load reports. I believe > there is consensus that there is the need for a peer load report to > support load balancing when routing requests to the next hop. > > The question is whether or not we should also support an "endpoint" load > report. This load report would be the load of a server (or a client) > and would be carried end-to-end. > > The case for an endpoint load report can be supported by the following > use case. > > Assume a Diameter network for a Diameter application where the servers > are partitioned across the user space. For simplicity, assume that user > identities starting with the numbers 0 through 4 are handled by > partition 1 and that user identities starting with the numbers 5 through > 9 are handled by partition 2. > > Also assume that each partition has three servers -- P1S1, P1S2 and P1S2 > in partition 1 and P2S1, P2S2 AND P2S3 in partition 2. > > Next assume that there is a database that maps user identities to > partitions. This scenario assumes that the database is a standalone > device that has some query mechanism for accessing the mapping. > Different implementations are possible. The query has the user identity > as the key and a set of Diameter servers as the response. This query > does NOT return anything but the set of servers able to handle requests > for the user id presented. Specifically, the query does not return the > load of the servers. > > Now, assume the following network topology: > > P1S1 P1S2 P1S3 P2S1 P2S2 P2S3 > \ | / \ | / > ------- ------- > / \ / \ > P1A1 P1A2 P2A1 P2A2 > | | | | > ------------------------------------- > | | > DB---- AA1 AA2-----DB > \ / > C > > The lines are for convenience, they are not meant to imply anything > physical, just that AA1 has connections to P1A1, P1A2, P2A1 and P2A2, > for instance. > > AA1 and AA2 are "access agents" and have access to the database that map > user identities to sets of servers. > > The flow of a request would be as follows: > > 1) C - Does realm routing using received peer load reports to load > balance between AA1 and AA2. Assume C routes to AA1. > > 2) AA1 queries the DB. Assume the user identity starts with the number > 1. The DB returns the set of servers including P1S1, P1S2 and P1S3. > > 3) AA1 then selects the server that is to handle the request from the > set of servers returned. AA1 uses endpoint load reports received from > P1S1, P1S2 and P1S3 to makes its selection. Assume in this case that > AA1 selection P1S2. As a result AA1 inserts the Destination-Host AVP > into the request with a value of P1S2. > > 4) AA1 then determines the route for the request. In this case the > route would need to be determines based on the combination of the > Destination-Realm, Application-ID and the Destination-Host in the > request. The routing tables would indicate that P1A1 and P1A2 are the > candidate next hop servers for the request. This requires AA1 to have a > route defined for each of the servers. AA1 then uses peer load > information received from P1A1 and P1A2 to select the next hop. Assume > AA1 selects P1A1. > > 5) P1A1 determines that the request is targeted for P1S2 based on the > Destination-Host AVP. As a result it routes the request directly to > P1S2. P1A1 cannot use a peer report to load balance in this case as the > request includes the destination in the Destination-Host AVP. > > The endpoint load report is used in step 3 to select the server that > will handle the request. Peer load reports are used to select the next > hop. > > Regards, > > Steve > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Thu May 7 01:18:34 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5C31AD079 for ; Thu, 7 May 2015 01:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 qpO4LHe84UHk for ; Thu, 7 May 2015 01:18:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532E71ACDCA for ; Thu, 7 May 2015 01:18:29 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 96704324556; Thu, 7 May 2015 10:18:27 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 7689F4C06D; Thu, 7 May 2015 10:18:27 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0235.001; Thu, 7 May 2015 10:18:27 +0200 From: To: Matt Holdrege , "dime@ietf.org" Thread-Topic: [Dime] Start of WGLC for draft-ietf-dime-e2e-sec-req-02 Thread-Index: AQHQcRhKGOSaY2smjkihhgOOcLb5Pp1wUxwg Date: Thu, 7 May 2015 08:18:27 +0000 Message-ID: <3095_1430986707_554B1FD3_3095_5616_1_6B7134B31289DC4FAF731D844122B36E0115B8B6@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0115B8B6PEXCVZYM13corpo_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.5.7.71516 Archived-At: Subject: Re: [Dime] Start of WGLC for draft-ietf-dime-e2e-sec-req-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 08:18:32 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0115B8B6PEXCVZYM13corpo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWF0dCwNCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3Lg0KDQpBYm91dCB0aGUgbWlub3Ig Y29tbWVudCwgdGhlIGN1cnJlbnQgdGV4dCBpczoNCg0KDQogICAgICBBcyBhbiBleGFtcGxlLCBj b25zaWRlciB0aGUgRGlhbWV0ZXIgRUFQDQoNCiAgICAgIGFwcGxpY2F0aW9uIFs0PGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGltZS1lMmUtc2VjLXJlcS0wMiNyZWYtND5d IHRoYXQgYWxsb3dzIGtleWluZyBtYXRlcmlhbCBmb3IgdGhlIHByb3RlY3Rpb24gb2YNCg0KICAg ICAgYWlyIGludGVyZmFjZQ0KDQphbmQgaXQgcmVmZXJzIHRvIHRoZSB1c2Ugb2YgRGlhbWV0ZXIg RUFQIHRvIHBlcmZvcm0gRUFQIGF1dGhlbnRpY2F0aW9ucyAoZS5nLiBFQVAtQUtBKSBmb3IgdGhl IGdlbmVyYXRpb24gb2YgY3J5cHRvZ3JhcGhpYyBrZXlzIHRoYXQgIGNvdWxkIGJlIGZ1cnRoZXIg dXNlZCBmb3IgcHJvdGVjdGluZyB0aGUgd2lyZWxlc3MgaW50ZXJmYWNlIChlLmcuIDgwMi4zKS4N ClRoZSB0ZXh0IG1pZ2h0IGJlIGNsYXJpZmllZCBidXQgSSB0aGluayBpdCBpcyBjb3JyZWN0IGFz IGl0IGlzLiBJIHdpbGwgbGV0IEpvdW5pIHNlZSBpZiBhbnkgdXBkYXRlIGlzIHJlcXVpcmVkIG9u IHRoaXMgcGFydC4NCg0KUmVnYXJkcywNCg0KTGlvbmVsDQoNCg0KRGUgOiBNYXR0IEhvbGRyZWdl IFttYWlsdG86aG9sZHJlZ2VAZ21haWwuY29tXQ0KRW52b3nDqSA6IG1hcmRpIDcgYXZyaWwgMjAx NSAxMTo1MQ0Kw4AgOiBkaW1lQGlldGYub3JnDQpDYyA6IE1PUkFORCBMaW9uZWwgSU1UL09MTg0K T2JqZXQgOiBSZTogW0RpbWVdIFN0YXJ0IG9mIFdHTEMgZm9yIGRyYWZ0LWlldGYtZGltZS1lMmUt c2VjLXJlcS0wMg0KDQpJIGp1c3QgZ2F2ZSBpdCBhIGZyZXNoIHJlYWQgYW5kIEkgc2VlIGp1c3Qg b25lIHRpbnkgbml0LiBJbiBzZWN0aW9uIDMgdW5kZXIgRWF2ZXNkcm9wcGluZyBpdCBtZW50aW9u cyBwcm90ZWN0aW5nIHRoZSBhaXIgaW50ZXJmYWNlLiBJIGRvbid0IHJlY2FsbCBpbiBhbnkgb2Yg dGhlIERJTUUgUkZDJ3Mgd2hlcmUgd2UgbWVudGlvbiB0aGUgcGh5c2ljYWwgbWVkaWEsIHJpZ2h0 PyBCZWNhdXNlIG9mIGNvdXJzZSB0aGUgcHJvdG9jb2wgcnVucyBvdmVyIGFueSB0eXBlIG9mIG1l ZGlhIHdoaWNoIGNhcnJpZXMgSVAuDQoNCk5vdCBhIGJpZyBkZWFsIHRvIG1lIGFuZCBpZiB0aGUg YXV0aG9ycyB3YW50IHRvIGxlYXZlIGl0IGluLCBJJ2xsIHRydXN0IHRoZW0gdG8gaXQgYW5kIGdp dmUgbXkgYXBwcm92YWwgdG8gdGhlIGRvY3VtZW50Lg0KDQpSZWdhcmRzLA0KLU1hdHQgSG9sZHJl Z2UNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_6B7134B31289DC4FAF731D844122B36E0115B8B6PEXCVZYM13corpo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1l OiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcw Ljg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBNYXR0LDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFib3V0IHRoZSBtaW5vciBjb21tZW50 LCB0aGUgY3VycmVudCB0ZXh0IGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFzIGFuIGV4YW1wbGUsIGNvbnNp ZGVyIHRoZSBEaWFtZXRlciBFQVA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcHBsaWNhdGlvbiBb PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGlt ZS1lMmUtc2VjLXJlcS0wMiNyZWYtNCIgdGl0bGU9IiZxdW90O0RpYW1ldGVyIEV4dGVuc2libGUg QXV0aGVudGljYXRpb24gUHJvdG9jb2wgKEVBUCkgQXBwbGljYXRpb24mcXVvdDsiPjxzcGFuIGxh bmc9IkVOLVVTIj40PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+XSB0aGF0IGFsbG93cyBr ZXlpbmcgbWF0ZXJpYWwgZm9yIHRoZSBwcm90ZWN0aW9uIG9mPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPmFpciBpbnRlcmZhY2U8bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmFu ZCBpdCByZWZlcnMgdG8gdGhlIHVzZSBvZiBEaWFtZXRlciBFQVAgdG8gcGVyZm9ybSBFQVAgYXV0 aGVudGljYXRpb25zIChlLmcuIEVBUC1BS0EpIGZvciB0aGUgZ2VuZXJhdGlvbiBvZiBjcnlwdG9n cmFwaGljIGtleXMgdGhhdCAmbmJzcDtjb3VsZCBiZQ0KIGZ1cnRoZXIgdXNlZCBmb3IgcHJvdGVj dGluZyB0aGUgd2lyZWxlc3MgaW50ZXJmYWNlIChlLmcuIDgwMi4zKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSB0ZXh0IG1pZ2h0IGJlIGNsYXJpZmllZCBi dXQgSSB0aGluayBpdCBpcyBjb3JyZWN0IGFzIGl0IGlzLiBJIHdpbGwgbGV0IEpvdW5pIHNlZSBp ZiBhbnkgdXBkYXRlIGlzIHJlcXVpcmVkIG9uIHRoaXMgcGFydC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YnI+DQpMaW9uZWw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWF0dCBIb2xkcmVnZSBbbWFpbHRvOmhvbGRyZWdl QGdtYWlsLmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtYXJkaSA3IGF2cmlsIDIw MTUgMTE6NTE8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IGRpbWVAaWV0Zi5vcmc8YnI+DQo8Yj5DYyZu YnNwOzo8L2I+IE1PUkFORCBMaW9uZWwgSU1UL09MTjxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4g UmU6IFtEaW1lXSBTdGFydCBvZiBXR0xDIGZvciBkcmFmdC1pZXRmLWRpbWUtZTJlLXNlYy1yZXEt MDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGp1c3QgZ2F2ZSBpdCBh IGZyZXNoIHJlYWQgYW5kIEkgc2VlIGp1c3Qgb25lIHRpbnkgbml0LiBJbiBzZWN0aW9uIDMgdW5k ZXIgRWF2ZXNkcm9wcGluZyBpdCBtZW50aW9ucyBwcm90ZWN0aW5nIHRoZQ0KPGI+YWlyPC9iPiBp bnRlcmZhY2UuIEkgZG9uJ3QgcmVjYWxsIGluIGFueSBvZiB0aGUgRElNRSBSRkMncyB3aGVyZSB3 ZSBtZW50aW9uIHRoZSBwaHlzaWNhbCBtZWRpYSwgcmlnaHQ/IEJlY2F1c2Ugb2YgY291cnNlIHRo ZSBwcm90b2NvbCBydW5zIG92ZXIgYW55IHR5cGUgb2YgbWVkaWEgd2hpY2ggY2FycmllcyBJUC4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdCBh IGJpZyBkZWFsIHRvIG1lIGFuZCBpZiB0aGUgYXV0aG9ycyB3YW50IHRvIGxlYXZlIGl0IGluLCBJ J2xsIHRydXN0IHRoZW0gdG8gaXQgYW5kIGdpdmUgbXkgYXBwcm92YWwgdG8gdGhlIGRvY3VtZW50 LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LU1hdHQgSG9sZHJlZ2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_6B7134B31289DC4FAF731D844122B36E0115B8B6PEXCVZYM13corpo_-- From nobody Thu May 7 01:36:05 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AAA1A891A; Thu, 7 May 2015 01:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 mX60IIKARaDs; Thu, 7 May 2015 01:36:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF3991A890D; Thu, 7 May 2015 01:36:01 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 0B40E19051B; Thu, 7 May 2015 10:35:55 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id E634538406E; Thu, 7 May 2015 10:35:54 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0235.001; Thu, 7 May 2015 10:35:54 +0200 From: To: "dime@ietf.org" Thread-Topic: Start of WGLC for draft-ietf-dime-e2e-sec-req-02 Thread-Index: AdBtKgybxm3tNN7QT8uEOO7PnY6nkAbddDIQ Date: Thu, 7 May 2015 08:35:54 +0000 Message-ID: <5215_1430987754_554B23EA_5215_492_1_6B7134B31289DC4FAF731D844122B36E0115BE4E@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.4.13.120621 Archived-At: Cc: "dime-chairs@ietf.org" Subject: Re: [Dime] Start of WGLC for draft-ietf-dime-e2e-sec-req-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 08:36:04 -0000 Hi, We have received a rough support for moving forward this document. A bunch of comments have been received and an update is required. However, the next update should not be significantly different of the curre= nt version, even if we will check if the comments have been correctly captu= red by the authors. Therefore, after the next version of this draft, I will propose to launch a= formal IETF LC. Regards, Lionel -----Message d'origine----- De=A0: MORAND Lionel IMT/OLN=20 Envoy=E9=A0: jeudi 2 avril 2015 11:49 =C0=A0: dime@ietf.org Cc=A0: dime-chairs@ietf.org Objet=A0: Start of WGLC for draft-ietf-dime-e2e-sec-req-02=20 During the Dime session at IETF92, the authors of draft-ietf-dime-e2e-sec-r= eq-02 have asked for a Working Group Last Call. This email officially starts a Working Group Last Call for the following do= cument: http://tools.ietf.org/html/draft-ietf-dime-e2e-sec-req-02=20 Please respond to this email to support the document and/or send comments b= y 2015-04-16. In addition, following the strategy for promoting compliance with the IPR d= isclosure rules (RFC6702), the chairs would like to check whether there ar= e claims of Intellectual Property Rights (IPR) on the document that need to= be disclosed. Therefore, the following questions are addressed to the WG a= nd Especially Authors and Contributors of the draft: * Are you personally aware of any IPR that applies to draft-ietf-dime-e2e-s= ec-req-02? If so, has this IPR been disclosed in compliance with IETF IPR r= ules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) * If you are a document author or listed contributor on this document, plea= se reply to this email message regardless of whether or not you are persona= lly aware of any relevant IPR. We might not be able to advance this docume= nt to the next stage until we have received a reply from each author and li= sted contributor. * If you are on the DIME WG email list but are not an author or listed cont= ributor for this document, you are reminded of your opportunity for a volun= tary IPR disclosure under BCP 79. Please do not reply unless you want to = make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . Regards, Lionel ___________________________________________________________________________= ______________________________________________ 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 nobody Thu May 7 01:48:28 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BF11ACE6A; Thu, 7 May 2015 01:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 37ndLke98fZv; Thu, 7 May 2015 01:48:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E25D1ACD0D; Thu, 7 May 2015 01:48:22 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id A330B324563; Thu, 7 May 2015 10:48:20 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 838324C056; Thu, 7 May 2015 10:48:20 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0235.001; Thu, 7 May 2015 10:48:17 +0200 From: To: MORAND Lionel IMT/OLN , "dime@ietf.org" Thread-Topic: Start of WGLC for draft-ietf-dime-4over6-provisioning-00 Thread-Index: AdBtKy1XVNGa27alSqquHaQEoRv65wbdpW+w Date: Thu, 7 May 2015 08:48:16 +0000 Message-ID: <10543_1430988500_554B26D4_10543_477_1_417b420d-d78f-40e0-a1d6-a790092b32ec@PEXCVZYH01.corporate.adroot.infra.ftgroup> References: <10824_1427968607_551D125F_10824_867_1_6B7134B31289DC4FAF731D844122B36EF26487@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <10824_1427968607_551D125F_10824_867_1_6B7134B31289DC4FAF731D844122B36EF26487@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.4.13.120621 Archived-At: Cc: "dime-chairs@ietf.org" Subject: Re: [Dime] Start of WGLC for draft-ietf-dime-4over6-provisioning-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 08:48:25 -0000 Hi, Except from the chairs and authors, we would need additional reviews to ass= ess that there is a WG consensus on its content and be able to move it forw= ard. The document is short and a feedback like "I read it and I support this doc= ument" would be enough. So please, review the document. For info, a minor updated version is available: http://tools.ietf.org/html/= draft-ietf-dime-4over6-provisioning-01 Regards, Lionel=20 -----Message d'origine----- De=A0: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Envoy=E9=A0: jeudi 2 avril 2015 11:57 =C0=A0: dime@ietf.org Cc=A0: dime-chairs@ietf.org Objet=A0: Start of WGLC for draft-ietf-dime-4over6-provisioning-00=20 During the Dime session at IETF92, it was conclude that the draft-ietf-dime= -4over6-provisioning-00 was stable enough to launch a Working Group Last Ca= ll. This email officially starts a Working Group Last Call for the following do= cument: http://tools.ietf.org/html/draft-ietf-dime-4over6-provisioning-00 Please respond to this email to support the document and/or send comments b= y 2015-04-16. In addition, following the strategy for promoting compliance with the IPR d= isclosure rules (RFC6702), the chairs would like to check whether there ar= e claims of Intellectual Property Rights (IPR) on the document that need to= be disclosed. Therefore, the following questions are addressed to the WG a= nd Especially Authors and Contributors of the draft: * Are you personally aware of any IPR that applies to draft-ietf-dime-4over= 6-provisioning-00? If so, has this IPR been disclosed in compliance with IE= TF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) * If you are a document author or listed contributor on this document, plea= se reply to this email message regardless of whether or not you are persona= lly aware of any relevant IPR. We might not be able to advance this docume= nt to the next stage until we have received a reply from each author and li= sted contributor. * If you are on the DIME WG email list but are not an author or listed cont= ributor for this document, you are reminded of your opportunity for a volun= tary IPR disclosure under BCP 79. Please do not reply unless you want to = make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . Regards, Lionel & Jouni ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. ___________________________________________________________________________= ______________________________________________ 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 nobody Thu May 7 01:52:29 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82471A1AA7 for ; Thu, 7 May 2015 01:52:27 -0700 (PDT) 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 N0iIsQdZYUHY for ; Thu, 7 May 2015 01:52:25 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 516A11A88D8 for ; Thu, 7 May 2015 01:52:25 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so7451381igb.0 for ; Thu, 07 May 2015 01:52:24 -0700 (PDT) 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:to :cc:content-type; bh=afv9mTKJZBOkfgdoyKJgsNfIfwgAerckKQvOVhYI9tM=; b=aUD1lpIdeZRO+pGV3i7pMOnDOKlT88S7wJ3zLZq/j7c2DhZa3IRi9ix7iNuVMIlSu8 Z467aRSD+CMBmVNvYizfH+YMh5OPUzbFFbAgs2wW+kGA8e8D2/TlDPtmEWZaGE3A9/rl JP4aKUvpWuvvkdjsyi6B+qijKqOHFbdG5awmACiO8/BJ9/O8jxXTq7FR5itb9y4YBgo5 weQvFmRRinEsX3BbyCh6XB6jWg99Cqy5Por3uuOtdmGYBgnAANU7P6JgKIc5QvEVNxUQ +3LOuWYFVi3Eb7HRt6c89pgeS2GdBOMaPUEc5hpwTMD0J+Im3YMKjf3hHIA2GHvSvSCB PAIw== MIME-Version: 1.0 X-Received: by 10.50.77.13 with SMTP id o13mr13204080igw.39.1430988743939; Thu, 07 May 2015 01:52:23 -0700 (PDT) Received: by 10.107.24.69 with HTTP; Thu, 7 May 2015 01:52:23 -0700 (PDT) In-Reply-To: <3095_1430986707_554B1FD3_3095_5616_1_6B7134B31289DC4FAF731D844122B36E0115B8B6@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <3095_1430986707_554B1FD3_3095_5616_1_6B7134B31289DC4FAF731D844122B36E0115B8B6@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Thu, 7 May 2015 10:52:23 +0200 Message-ID: From: Matt Holdrege To: lionel.morand@orange.com Content-Type: multipart/alternative; boundary=047d7bdc110ac29c0305157a07af Archived-At: Cc: "dime@ietf.org" Subject: Re: [Dime] Start of WGLC for draft-ietf-dime-e2e-sec-req-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 08:52:27 -0000 --047d7bdc110ac29c0305157a07af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Lionel, 802.3 is not wireless nor an "air" interface. Maybe you meant 802.11? And my point was that we are not just protecting air interfaces, but any IP interface. But again, it's a tiny nit. Not a big deal. -Matt On Thu, May 7, 2015 at 10:18 AM, wrote: > Hi Matt, > > > > Thank you for the review. > > > > About the minor comment, the current text is: > > > > As an example, consider the Diameter EAP > > application [4 ] that allows keying material for the protection of > > air interface > > > > and it refers to the use of Diameter EAP to perform EAP authentications > (e.g. EAP-AKA) for the generation of cryptographic keys that could be > further used for protecting the wireless interface (e.g. 802.3). > > The text might be clarified but I think it is correct as it is. I will le= t > Jouni see if any update is required on this part. > > > > Regards, > > > Lionel > > > > > > *De :* Matt Holdrege [mailto:holdrege@gmail.com] > *Envoy=C3=A9 :* mardi 7 avril 2015 11:51 > *=C3=80 :* dime@ietf.org > *Cc :* MORAND Lionel IMT/OLN > *Objet :* Re: [Dime] Start of WGLC for draft-ietf-dime-e2e-sec-req-02 > > > > I just gave it a fresh read and I see just one tiny nit. In section 3 > under Eavesdropping it mentions protecting the *air* interface. I don't > recall in any of the DIME RFC's where we mention the physical media, righ= t? > Because of course the protocol runs over any type of media which carries > IP. > > > > Not a big deal to me and if the authors want to leave it in, I'll trust > them to it and give my approval to the document. > > > > Regards, > > -Matt Holdrege > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --047d7bdc110ac29c0305157a07af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lionel,

802.3 is not wireless nor an &q= uot;air" interface. Maybe you meant 802.11? And my point was that we a= re not just protecting air interfaces, but any IP interface. But again, it&= #39;s a tiny nit. Not a big deal.

-Matt

On Thu, May 7, 2= 015 at 10:18 AM, <lionel.morand@orange.com> wrote:

Hi Matt,

=C2= =A0

Thank you = for the review.

=C2= =A0

About the = minor comment, the current text is:

=C2= =A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 As an example, con=
sider the Diameter EAP
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 application [4] that allows keying material for the protection of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 air interfa=
ce

=C2= =A0

and it ref= ers to the use of Diameter EAP to perform EAP authentications (e.g. EAP-AKA= ) for the generation of cryptographic keys that =C2=A0could be further used for protecting the wireless interface (e.g. 802.3).=

The text m= ight be clarified but I think it is correct as it is. I will let Jouni see = if any update is required on this part.

=C2= =A0

Regards,


Lionel

=C2=A0

=C2=A0

De=C2=A0: Matt= Holdrege [mailto:h= oldrege@gmail.com]
Envoy=C3=A9=C2=A0: mardi 7 avril 2015 11:51
=C3=80=C2=A0: dim= e@ietf.org
Cc=C2=A0: MORAND Lionel IMT/OLN
Objet=C2=A0: Re: [Dime] Start of WGLC for draft-ietf-dime-e2e-sec-re= q-02

=C2=A0

I just gave it a fresh read and I see just one tiny = nit. In section 3 under Eavesdropping it mentions protecting the air interface. I don't recall in any of the DIME RFC's where= we mention the physical media, right? Because of course the protocol runs = over any type of media which carries IP.=C2=A0

=C2=A0

Not a big deal to me and if the authors want to leav= e it in, I'll trust them to it and give my approval to the document.=C2= =A0

=C2=A0

Regards,

-Matt Holdrege

=C2=A0

______________________________________________________________________=
___________________________________________________

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 message=
s electroniques 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.

--047d7bdc110ac29c0305157a07af-- From nobody Thu May 7 08:09:35 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A654F1A90E9 for ; Thu, 7 May 2015 08:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 qQXYhCDSGUAh for ; Thu, 7 May 2015 08:09:30 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C201A0021 for ; Thu, 7 May 2015 08:08:08 -0700 (PDT) Received: by pdea3 with SMTP id a3so43741143pde.3 for ; Thu, 07 May 2015 08:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YjQ13W12QaOqbJtCJ9N3ojO6fb9Mh7w4uWu/J4kTjE8=; b=Cup5C/LFI4BT5z9qAzEgYmaKyc813NTaAuCxqAcfCd/u9aBlikE+HTLIirxZRndEzx vWfUvVBM+dfJUqJINz34QhVMZP/ESiWXV0gyRoVjUwfcAgMNFBnCt72TXsAhn8FNChOU 0hJysQUdV1ql+JCIzNw1w00c6YXXQMnJrmrkPfr5Cklt3esuP/e7zi3bPinEUtn/bzjr OHwQ8IqCVmYjVNQZGd35zDQNdxt8mByOcLSdH9TlU4CK5tv7p+AxtJruuHf6yc74PCUi 8E3sejVQfRDRiZV/akr0nczJUrc6VSNAkJlhDLfm2OMpKvtpWNwFvnT+4LWwaVX2mvPA Uoxg== X-Received: by 10.70.133.170 with SMTP id pd10mr7678287pdb.127.1431011288487; Thu, 07 May 2015 08:08:08 -0700 (PDT) Received: from [10.183.140.29] ([166.170.36.13]) by mx.google.com with ESMTPSA id bz11sm2465396pdb.34.2015.05.07.08.08.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 May 2015 08:08:07 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-81A8A677-F073-4F47-A227-3FEC518CCA0C Mime-Version: 1.0 (1.0) From: "Jouni.nosmap" X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Thu, 7 May 2015 08:08:06 -0700 Content-Transfer-Encoding: 7bit Message-Id: <615891AF-91C5-4F47-896C-684172288317@gmail.com> References: <3095_1430986707_554B1FD3_3095_5616_1_6B7134B31289DC4FAF731D844122B36E0115B8B6@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: Matt Holdrege Archived-At: Cc: "dime@ietf.org" Subject: Re: [Dime] Start of WGLC for draft-ietf-dime-e2e-sec-req-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 15:09:32 -0000 --Apple-Mail-81A8A677-F073-4F47-A227-3FEC518CCA0C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks. I'll take care of this.=20 Jouni Sent from a smart phone.. Mind the typos.. > Matt Holdrege kirjoitti 7.5.2015 kello 1.52: >=20 > Lionel, >=20 > 802.3 is not wireless nor an "air" interface. Maybe you meant 802.11? And m= y point was that we are not just protecting air interfaces, but any IP inter= face. But again, it's a tiny nit. Not a big deal. >=20 > -Matt >=20 >> On Thu, May 7, 2015 at 10:18 AM, wrote: >> Hi Matt, >>=20 >> =20 >>=20 >> Thank you for the review. >>=20 >> =20 >>=20 >> About the minor comment, the current text is: >>=20 >> =20 >>=20 >> As an example, consider the Diameter EAP >> application [4] that allows keying material for the protection of >> air interface >> =20 >>=20 >> and it refers to the use of Diameter EAP to perform EAP authentications (= e.g. EAP-AKA) for the generation of cryptographic keys that could be furthe= r used for protecting the wireless interface (e.g. 802.3). >>=20 >> The text might be clarified but I think it is correct as it is. I will le= t Jouni see if any update is required on this part. >>=20 >> =20 >>=20 >> Regards, >>=20 >>=20 >> Lionel >>=20 >> =20 >>=20 >> =20 >>=20 >> De : Matt Holdrege [mailto:holdrege@gmail.com]=20 >> Envoy=C3=A9 : mardi 7 avril 2015 11:51 >> =C3=80 : dime@ietf.org >> Cc : MORAND Lionel IMT/OLN >> Objet : Re: [Dime] Start of WGLC for draft-ietf-dime-e2e-sec-req-02 >>=20 >> =20 >>=20 >> I just gave it a fresh read and I see just one tiny nit. In section 3 und= er Eavesdropping it mentions protecting the air interface. I don't recall in= any of the DIME RFC's where we mention the physical media, right? Because o= f course the protocol runs over any type of media which carries IP.=20 >>=20 >> =20 >>=20 >> Not a big deal to me and if the authors want to leave it in, I'll trust t= hem to it and give my approval to the document.=20 >>=20 >> =20 >>=20 >> Regards, >>=20 >> -Matt Holdrege >>=20 >> =20 >>=20 >> _________________________________________________________________________= ________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages e= lectroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. >> Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail-81A8A677-F073-4F47-A227-3FEC518CCA0C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks. I'll take care of this. <= /div>

Jouni

Sent from a smart phone.. Mind the typ= os..

Matt Holdrege <h= oldrege@gmail.com> kirjoitti 7.5.2015 kello 1.52:

Lionel,

802.3 i= s not wireless nor an "air" interface. Maybe you meant 802.11? And my point w= as that we are not just protecting air interfaces, but any IP interface. But= again, it's a tiny nit. Not a big deal.

-Matt

On Thu, May= 7, 2015 at 10:18 AM, <lionel.morand@orange.com> wrote= :

Hi Matt,<= /u>

 = ;

Thank you fo= r the review.

 = ;

About the mi= nor comment, the current text is:

 = ;

      As an example, cons=
ider the Diameter EAP
      application [4] that allows keying material for the protection of
      air interfac=
e

 = ;

and it refer= s to the use of Diameter EAP to perform EAP authentications (e.g. EAP-AKA) f= or the generation of cryptographic keys that  could be further used for protecting the wireless interface (e.g. 802.3).<= /u>

The text mig= ht be clarified but I think it is correct as it is. I will let Jouni see if a= ny update is required on this part.

 = ;

Regards,


Lionel

 =

 =

De : Matt Ho= ldrege [mailto:holdr= ege@gmail.com]
Envoy=C3=A9 : mardi 7 avril 2015 11:51
=C3=80 : dime= @ietf.org
Cc : MORAND Lionel IMT/OLN
Objet : Re: [Dime] Start of WGLC for draft-ietf-dime-e2e-sec-req= -02

 

I just gave it a fresh read and I see just one tiny n= it. In section 3 under Eavesdropping it mentions protecting the air interface. I don't recall in any of the DIME RFC's where we menti= on the physical media, right? Because of course the protocol runs over any t= ype of media which carries IP. 

 

Not a big deal to me and if the authors want to leave= it in, I'll trust them to it and give my approval to the document. =

 

Regards,

-Matt Holdrege

 

_______________________________________________________________________=
__________________________________________________

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

This message and its attachments may contain confidential or privileged info=
rmation 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 delet=
e this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
Thank you.

____________________= ___________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman= /listinfo/dime
= --Apple-Mail-81A8A677-F073-4F47-A227-3FEC518CCA0C-- From nobody Sat May 9 08:50:55 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554D91A1B17 for ; Sat, 9 May 2015 08:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 qC2N6Xh5GtJC for ; Sat, 9 May 2015 08:50:50 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5254F1A1AB8 for ; Sat, 9 May 2015 08:50:50 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so109688519pdb.1 for ; Sat, 09 May 2015 08:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:to:from:reply-to:subject:message-id:mime-version :content-transfer-encoding:content-type; bh=+pE25DtIuFVPUtT/ps3/Z8x4gVteptQ8Lx7LDmoEdoA=; b=obaCIxgkAAC302Ss1OfU4mqhFhnTYp14pq2Nurv6Ld72Fttf3OrcK1E6PRcl7TvUKD 1PtUGumoW9MkpLrEIJZ4/+Bf584W63UndxC4SklPsDwLy0RmTP7HDclzAQ0yz1pmB62U gt3VtMosVmROj2oB0QQHui0qrMIc2bHjRaGelSn45cgpT7jYpgLemdto8vqqzZ2+2ztG ibBvvunU7x1kwNPzSzi8/Zq4Az38Nwpe7oCWs/o4TEgOrAMkcaYZryBD4P/eDH3fniE6 VYjutfESe+Zvi+L6rGFG2KMcQs7/Y5NL5bKyElyXFegKD/zFheq0usQlL/IGkE0vzTyr +jOw== X-Received: by 10.66.141.143 with SMTP id ro15mr5686883pab.4.1431186650007; Sat, 09 May 2015 08:50:50 -0700 (PDT) Received: from www.queryhome.com (ec2-54-214-12-95.us-west-2.compute.amazonaws.com. [54.214.12.95]) by mx.google.com with ESMTPSA id yn5sm8388191pac.48.2015.05.09.08.50.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 May 2015 08:50:48 -0700 (PDT) Date: Sat, 9 May 2015 15:50:47 +0000 To: dime@ietf.org From: Kevin Peterson Message-ID: X-Priority: 3 X-Mailer: CatPHPMailer 5.1 (phpmailer.sourceforge.net) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Archived-At: Subject: [Dime] Test bed for Freediameter Authentication testing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Kevin Peterson List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 15:50:54 -0000 Hi, I'm very new to freediameter. But I'm having some knowledge in freeradius. I believe that diameter is also similar like radius with some additional behaviors. I have downloaded freediameter and installed properly. But I stuck after that. In radius we can have radtest option to test the basic authentication. But here I don't know how to test the basic authentications to authenticate the user. When I surf on that, I have found like we need to include DiamEAP extensions also to verify the authentication And came to know we need to configure mysql since it doesn't have flat file support like radius. So I start to install mysql also. I have seen the testbed for EAP in TBEAP link. Again I confused with the setup. Is there any simple technique to test the AAA in freediameter. I'll explain my project needs below. Kindly help me how can I proceed with that. * I need to implement the authenticate the port MAC (during state change) using freeDiameter protocol. * I'll use SDN setup for that, using opendaylight controller. Once i get the port notification from the switch i'll send the username , password info to freediameter client. with that user name and password diameter client needs to send the Access-request packet to freediameter server. The server should validate those info's and return back with Access-Accept/Access-reject messages. Using that info i'll take decision to enable the swicth port or not. (I explained the terms in radius, sorry not sure with corresponding terms in freediameter). For this what conf file I need to edit? What information it should have. How to test the client and server with users information. Please give some clear picture about the setup for my need. My setup details. diamEAP - 1.0.0 freediameter - 1.1.4 Ubuntu - 12.04 Thanks, Kevin Peterson From nobody Tue May 12 00:05:40 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA691A1AE3 for ; Tue, 12 May 2015 00:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRwTZnKyO9yG for ; Tue, 12 May 2015 00:05:35 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3CD1A1AD0 for ; Tue, 12 May 2015 00:05:35 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 9B5A6DC3727F1; Tue, 12 May 2015 07:05:31 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t4C75GKv018807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 May 2015 09:05:32 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.211]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 12 May 2015 09:05:20 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" , "srdonovan@usdonovans.com" Thread-Topic: [Dime] Load Use Case justifying endpoint load reports Thread-Index: AQHQg3d5m1t1LcLgzkilR8rHOTKOgZ1uzuMAgABblACAANDjAIAHEirA Date: Tue, 12 May 2015 07:05:20 +0000 Message-ID: References: <55427AF7.6090002@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E847@DEMUMBX014.nsn-intra.net> <554A5BA6.8020703@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E970@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006682288E970@DEMUMBX014.nsn-intra.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] Load Use Case justifying endpoint load reports X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 07:05:39 -0000 Hi Steve and all This topic of the load control solution scope is not easy and I hereafter = give my views on the basis of the offline discussion on this topic and the = use cases to address, in particular the partition use case that Steve prese= nted.=20 =20 In the offline discussion we had, several use cases, including if I remembe= r well partition use cases (in 3GPP a main partition case is the HSS one) w= ere addressed.=20 A) The important question in fact is the scope of a Load control standardiz= ation,=20 - RFC 6733 specifies a basic set of routing rules that I hereafter summari= zed: a) if the destination Host when present in the request is in the peer = table, the request is sent to this peer.=20 b) In other cases (destination host present or not in the request), the= routing table gives the possible peers for a given realm /application entr= y =20 =20 - RFC 6733 allows to have additional routing criteria as Steve indicated i= n 6.1.6, but they are not described and so out of the RFC 6733 scope. - when considering load control, Lionel's position is that the load contro= l to be standardized is the one useful/needed for the above basic set of ro= uting rules. Additional load control mechanisms that would be useful when = coupled to routing criteria out of 6733 scope are outside of the load contr= ol standardization scope. The reason is because we cannot define all the po= ssible routing cases outside RFC6733 to see which load control would be nee= ded; we can only specify a load control mechanism applicable to the basic = set of routing rules. - when considering the load control for the basic set of routing rules - for a), there is no need to consider load information as the peer is = selected from the peer table - for b), as there can be several peers, load info of the different pee= rs is used to select the peer and achieve load balancing. The load of end = points (servers) which are not peers cannot be used for this peer selectio= n. In conclusion, with the basic set of routing rules, only load info from the= peers is needed for peer selection, no need for end point load info. = =20 Lionel, please check if I have well summarized your position. =20 B) The above perimeter brings strong restrictions for the possible use case= s to be in the scope. In particular the partition use cases as the one des= cribed by Steve requires an additional routing criteria (cf step 4) in Ste= ve's mail) which makes this case out of the scope of the basic set of RFC 6= 733 routing rules, so also out of the scope of a standardized load control = mechanis, although this partition use case is frequent in deployed networks= (for HSS in 3GPP). Does Dime do an exception to also include this use case in the scope of loa= d control mechanism?=20 =20 C) In draft-campbell-dime-load-considerations-01, use cases (which are not= partition use cases) are described in 10.1 to 10.7 sections. Which ones ar= e compliant with the basic set of RFC 6733 basic rules without requiring ad= ditional specific routing criteria=20 - 10.1 No agent: compliant - 10.2 Single agent: compliant - 10.3 Multiple Agents: not compliant (for a request from C with a destin= ation host) - 10.4 Linked agent: partially compliant ( A1 has a routing table for the r= ealm/application containing S1 , S3 ... and A2), this may drives to non opt= imal routing, especially when several agents). - 10.5 Shared server pools: compliant - 10.6 Agent chain: not compliant (as for 10.3 if A3 has not A2 in its rout= ing table) or partially compliant (as for 10.4 if A3 has A2 in its routing = table)=20 - 10.7 Fully meshed layers: compliant.=20 Note: for partially compliant cases, improvement can be done by giving a hi= gher priority to peers that are servers (eg S1 , S3 in 10.4 for A1 routing = table) than to the peers that are agents(eg A2 in 10.4 for A1 routing tabl= e). Such a priority is a specific additional routing criteria which is pos= sible but out of the scope of the basic set of routing rules. =20 =20 In fact only the fully meshed cases allow a routing only based on the basic= set of rules. Other cases imply additional specific rules not described in= RFC 6733. If we now consider the load control solution, the fully meshed cases (10.1,= 10.2, 10.5, 10.7) only need peer load info to achieve a right load balanc= ing between servers and also between agents, as described in A).=20 But existing deployments, especially large networks, are not in a fully mes= hed configuration, so they enter other use cases (10.3, 10.4, 10.6) for whi= ch the peer load info is not sufficient. I am not sure that the end-point l= oad info (cf B)) is a good answer for these cases which are different from= the partition cases. Again, the question raises to do an exception to also= include some of these use cases in the scope of load control solution?=20 D) There are also the use cases with Redirect Agents. Here according to my = understanding of RFC 6733, the Redirect Hosts returned to the node having r= equested the Redirect agent are peers (direct connection) of the node doing= the redirect request (cf RFC 6733 2.8.3 and 6.1.8), and if several Redirec= t hosts are returned this enters the peer selection case achievable with th= e peer load info (cf A)), so not requiring e.g. an end-point load info. = =20 E) I would like you to check if I have not some errors/misunderstanding in= my above analysis, and then to have your position on the following: - solution with peer load information allows load control for routing case= s using the basic set of RFC 6733 routing rules, as described in A). I thin= k we all agree on A) and we can now start the writing of this solution in t= he draft. - Redirect use cases also rely on the this peer load information solution = =20 - we have then to decide if we support some additional use cases outside th= e basic set of RFC 6733 routing rules, because they are important in existi= ng deployments. The one to consider first would be the partition case with= end point load info which Steve presented and which corresponds to the 3GP= P important HSS use case. Other presented use cases (cf C))can be left for = possible future extension. Thank you Best regards JJacques=20 =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (Nok= ia - DE/Munich) Envoy=E9=A0: jeudi 7 mai 2015 08:49 =C0=A0: ext Steve Donovan; dime@ietf.org Objet=A0: Re: [Dime] Load Use Case justifying endpoint load reports Hi Steve, thank you for the clarification. As I said, I'm not against. I rather support your proposal. Ulrich -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Wednesday, May 06, 2015 8:21 PM To: Wiehe, Ulrich (Nokia - DE/Munich); dime@ietf.org Subject: Re: [Dime] Load Use Case justifying endpoint load reports Ulrich, Thanks for pointing out the argument against this use case. I understand that the default set of information used for request routing i= s the Destination-Realm and application-id. There is nothing, however, tha= t says this is the only set of information that can be used. In fact, the = following from section 6.1.6. in RFC6733 affirms that there are cases when = additional information will be used: " Realm names and Application Ids are the minimum supported routing criteria, additional information may be needed to support redirect semantics." The case below suggests the use of Destination-Host. There are scenarios w= here session-ID, for session based applications, can be used. There is no = reason that an agent couldn't use any AVP to make routing decisions. In addition, Diameter is being used in ways that were not anticipated by th= e original authors. That is a good thing. I know of many Diameter networks that fit into this use case. We need to t= ake them into account when designing the load mechanism. Regards, Steve On 5/6/15 7:53 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote: > Hi Steve, > I'm not against your proposal, however, it has been argued that=20 > (according to established routing principles) in step 4)=20 > Destination-Host is not part of the information used to determine the=20 > route. > Any reaction to this? >=20 > Best regards > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 > Donovan > Sent: Thursday, April 30, 2015 8:57 PM > To: dime@ietf.org > Subject: [Dime] Load Use Case justifying endpoint load reports > > All, > > There has been some offline discussion about whether or not the=20 > Diameter Load mechanism should include two types of Load reports. I=20 > believe there is consensus that there is the need for a peer load=20 > report to support load balancing when routing requests to the next hop. > > The question is whether or not we should also support an "endpoint"=20 > load report. This load report would be the load of a server (or a=20 > client) and would be carried end-to-end. > > The case for an endpoint load report can be supported by the following=20 > use case. > > Assume a Diameter network for a Diameter application where the servers=20 > are partitioned across the user space. For simplicity, assume that=20 > user identities starting with the numbers 0 through 4 are handled by=20 > partition 1 and that user identities starting with the numbers 5=20 > through > 9 are handled by partition 2. > > Also assume that each partition has three servers -- P1S1, P1S2 and=20 > P1S2 in partition 1 and P2S1, P2S2 AND P2S3 in partition 2. > > Next assume that there is a database that maps user identities to=20 > partitions. This scenario assumes that the database is a standalone=20 > device that has some query mechanism for accessing the mapping. > Different implementations are possible. The query has the user=20 > identity as the key and a set of Diameter servers as the response. =20 > This query does NOT return anything but the set of servers able to=20 > handle requests for the user id presented. Specifically, the query=20 > does not return the load of the servers. > > Now, assume the following network topology: > > P1S1 P1S2 P1S3 P2S1 P2S2 P2S3 > \ | / \ | / > ------- ------- > / \ / \ > P1A1 P1A2 P2A1 P2A2 > | | | | > ------------------------------------- > | | > DB---- AA1 AA2-----DB > \ / > C > > The lines are for convenience, they are not meant to imply anything=20 > physical, just that AA1 has connections to P1A1, P1A2, P2A1 and P2A2,=20 > for instance. > > AA1 and AA2 are "access agents" and have access to the database that=20 > map user identities to sets of servers. > > The flow of a request would be as follows: > > 1) C - Does realm routing using received peer load reports to load=20 > balance between AA1 and AA2. Assume C routes to AA1. > > 2) AA1 queries the DB. Assume the user identity starts with the=20 > number 1. The DB returns the set of servers including P1S1, P1S2 and P1S= 3. > > 3) AA1 then selects the server that is to handle the request from the=20 > set of servers returned. AA1 uses endpoint load reports received from=20 > P1S1, P1S2 and P1S3 to makes its selection. Assume in this case that > AA1 selection P1S2. As a result AA1 inserts the Destination-Host AVP=20 > into the request with a value of P1S2. > > 4) AA1 then determines the route for the request. In this case the=20 > route would need to be determines based on the combination of the=20 > Destination-Realm, Application-ID and the Destination-Host in the=20 > request. The routing tables would indicate that P1A1 and P1A2 are the=20 > candidate next hop servers for the request. This requires AA1 to have=20 > a route defined for each of the servers. AA1 then uses peer load=20 > information received from P1A1 and P1A2 to select the next hop. =20 > Assume > AA1 selects P1A1. > > 5) P1A1 determines that the request is targeted for P1S2 based on the=20 > Destination-Host AVP. As a result it routes the request directly to=20 > P1S2. P1A1 cannot use a peer report to load balance in this case as=20 > the request includes the destination in the Destination-Host AVP. > > The endpoint load report is used in step 3 to select the server that=20 > will handle the request. Peer load reports are used to select the=20 > next hop. > > Regards, > > Steve > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue May 12 06:29:35 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94A71B2C2F for ; Tue, 12 May 2015 06:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, 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 4z_VEVnRqJ_5 for ; Tue, 12 May 2015 06:29:29 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669981A86F4 for ; Tue, 12 May 2015 06:29:29 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:49410 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YsAFR-0009Gu-6W; Tue, 12 May 2015 06:29:28 -0700 Message-ID: <55520035.2010701@usdonovans.com> Date: Tue, 12 May 2015 08:29:25 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" References: <55427AF7.6090002@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E847@DEMUMBX014.nsn-intra.net> <554A5BA6.8020703@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E970@DEMUMBX014.nsn-intra.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Dime] Load Use Case justifying endpoint load reports X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 13:29:32 -0000 Jean-Jacques, This was a good analysis, thanks. It comes down to the question - Do we limit the solution to the routing rules defined twelve years ago or do we design a solution that addresses how Diameter is currently being used? The use case I outlined is a common occurrence in today's Diameter networks. We should design a solution that addresses the needs of all Diameter networks, including those that require routing on more than just Destination-Realm and Application-ID. Regards, Steve On 5/12/15 2:05 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: > Hi Steve and all > > > This topic of the load control solution scope is not easy and I hereafter give my views on the basis of the offline discussion on this topic and the use cases to address, in particular the partition use case that Steve presented. > > In the offline discussion we had, several use cases, including if I remember well partition use cases (in 3GPP a main partition case is the HSS one) were addressed. > > A) The important question in fact is the scope of a Load control standardization, > - RFC 6733 specifies a basic set of routing rules that I hereafter summarized: > a) if the destination Host when present in the request is in the peer table, the request is sent to this peer. > b) In other cases (destination host present or not in the request), the routing table gives the possible peers for a given realm /application entry > > - RFC 6733 allows to have additional routing criteria as Steve indicated in 6.1.6, but they are not described and so out of the RFC 6733 scope. > - when considering load control, Lionel's position is that the load control to be standardized is the one useful/needed for the above basic set of routing rules. Additional load control mechanisms that would be useful when coupled to routing criteria out of 6733 scope are outside of the load control standardization scope. The reason is because we cannot define all the possible routing cases outside RFC6733 to see which load control would be needed; we can only specify a load control mechanism applicable to the basic set of routing rules. > > - when considering the load control for the basic set of routing rules > - for a), there is no need to consider load information as the peer is selected from the peer table > - for b), as there can be several peers, load info of the different peers is used to select the peer and achieve load balancing. The load of end points (servers) which are not peers cannot be used for this peer selection. > > In conclusion, with the basic set of routing rules, only load info from the peers is needed for peer selection, no need for end point load info. > > Lionel, please check if I have well summarized your position. > > > B) The above perimeter brings strong restrictions for the possible use cases to be in the scope. In particular the partition use cases as the one described by Steve requires an additional routing criteria (cf step 4) in Steve's mail) which makes this case out of the scope of the basic set of RFC 6733 routing rules, so also out of the scope of a standardized load control mechanis, although this partition use case is frequent in deployed networks (for HSS in 3GPP). > Does Dime do an exception to also include this use case in the scope of load control mechanism? > > > C) In draft-campbell-dime-load-considerations-01, use cases (which are not partition use cases) are described in 10.1 to 10.7 sections. Which ones are compliant with the basic set of RFC 6733 basic rules without requiring additional specific routing criteria > - 10.1 No agent: compliant > - 10.2 Single agent: compliant > - 10.3 Multiple Agents: not compliant (for a request from C with a destination host) > - 10.4 Linked agent: partially compliant ( A1 has a routing table for the realm/application containing S1 , S3 ... and A2), this may drives to non optimal routing, especially when several agents). > - 10.5 Shared server pools: compliant > - 10.6 Agent chain: not compliant (as for 10.3 if A3 has not A2 in its routing table) or partially compliant (as for 10.4 if A3 has A2 in its routing table) > - 10.7 Fully meshed layers: compliant. > > > Note: for partially compliant cases, improvement can be done by giving a higher priority to peers that are servers (eg S1 , S3 in 10.4 for A1 routing table) than to the peers that are agents(eg A2 in 10.4 for A1 routing table). Such a priority is a specific additional routing criteria which is possible but out of the scope of the basic set of routing rules. > > In fact only the fully meshed cases allow a routing only based on the basic set of rules. Other cases imply additional specific rules not described in RFC 6733. > > If we now consider the load control solution, the fully meshed cases (10.1, 10.2, 10.5, 10.7) only need peer load info to achieve a right load balancing between servers and also between agents, as described in A). > But existing deployments, especially large networks, are not in a fully meshed configuration, so they enter other use cases (10.3, 10.4, 10.6) for which the peer load info is not sufficient. I am not sure that the end-point load info (cf B)) is a good answer for these cases which are different from the partition cases. Again, the question raises to do an exception to also include some of these use cases in the scope of load control solution? > > > D) There are also the use cases with Redirect Agents. Here according to my understanding of RFC 6733, the Redirect Hosts returned to the node having requested the Redirect agent are peers (direct connection) of the node doing the redirect request (cf RFC 6733 2.8.3 and 6.1.8), and if several Redirect hosts are returned this enters the peer selection case achievable with the peer load info (cf A)), so not requiring e.g. an end-point load info. > > > E) I would like you to check if I have not some errors/misunderstanding in my above analysis, and then to have your position on the following: > - solution with peer load information allows load control for routing cases using the basic set of RFC 6733 routing rules, as described in A). I think we all agree on A) and we can now start the writing of this solution in the draft. > - Redirect use cases also rely on the this peer load information solution > - we have then to decide if we support some additional use cases outside the basic set of RFC 6733 routing rules, because they are important in existing deployments. The one to consider first would be the partition case with end point load info which Steve presented and which corresponds to the 3GPP important HSS use case. Other presented use cases (cf C))can be left for possible future extension. > > Thank you > > Best regards > > JJacques > > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (Nokia - DE/Munich) > Envoyé : jeudi 7 mai 2015 08:49 > À : ext Steve Donovan; dime@ietf.org > Objet : Re: [Dime] Load Use Case justifying endpoint load reports > > Hi Steve, > > thank you for the clarification. > As I said, I'm not against. I rather support your proposal. > > Ulrich > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, May 06, 2015 8:21 PM > To: Wiehe, Ulrich (Nokia - DE/Munich); dime@ietf.org > Subject: Re: [Dime] Load Use Case justifying endpoint load reports > > Ulrich, > > Thanks for pointing out the argument against this use case. > > I understand that the default set of information used for request routing is the Destination-Realm and application-id. There is nothing, however, that says this is the only set of information that can be used. In fact, the following from section 6.1.6. in RFC6733 affirms that there are cases when additional information will be used: > > " Realm names and Application Ids are the minimum supported routing > criteria, additional information may be needed to support redirect > semantics." > > The case below suggests the use of Destination-Host. There are scenarios where session-ID, for session based applications, can be used. There is no reason that an agent couldn't use any AVP to make routing decisions. > > In addition, Diameter is being used in ways that were not anticipated by the original authors. That is a good thing. > > I know of many Diameter networks that fit into this use case. We need to take them into account when designing the load mechanism. > > Regards, > > Steve > > On 5/6/15 7:53 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote: >> Hi Steve, >> I'm not against your proposal, however, it has been argued that >> (according to established routing principles) in step 4) >> Destination-Host is not part of the information used to determine the >> route. >> Any reaction to this? >> >> Best regards >> Ulrich >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >> Donovan >> Sent: Thursday, April 30, 2015 8:57 PM >> To: dime@ietf.org >> Subject: [Dime] Load Use Case justifying endpoint load reports >> >> All, >> >> There has been some offline discussion about whether or not the >> Diameter Load mechanism should include two types of Load reports. I >> believe there is consensus that there is the need for a peer load >> report to support load balancing when routing requests to the next hop. >> >> The question is whether or not we should also support an "endpoint" >> load report. This load report would be the load of a server (or a >> client) and would be carried end-to-end. >> >> The case for an endpoint load report can be supported by the following >> use case. >> >> Assume a Diameter network for a Diameter application where the servers >> are partitioned across the user space. For simplicity, assume that >> user identities starting with the numbers 0 through 4 are handled by >> partition 1 and that user identities starting with the numbers 5 >> through >> 9 are handled by partition 2. >> >> Also assume that each partition has three servers -- P1S1, P1S2 and >> P1S2 in partition 1 and P2S1, P2S2 AND P2S3 in partition 2. >> >> Next assume that there is a database that maps user identities to >> partitions. This scenario assumes that the database is a standalone >> device that has some query mechanism for accessing the mapping. >> Different implementations are possible. The query has the user >> identity as the key and a set of Diameter servers as the response. >> This query does NOT return anything but the set of servers able to >> handle requests for the user id presented. Specifically, the query >> does not return the load of the servers. >> >> Now, assume the following network topology: >> >> P1S1 P1S2 P1S3 P2S1 P2S2 P2S3 >> \ | / \ | / >> ------- ------- >> / \ / \ >> P1A1 P1A2 P2A1 P2A2 >> | | | | >> ------------------------------------- >> | | >> DB---- AA1 AA2-----DB >> \ / >> C >> >> The lines are for convenience, they are not meant to imply anything >> physical, just that AA1 has connections to P1A1, P1A2, P2A1 and P2A2, >> for instance. >> >> AA1 and AA2 are "access agents" and have access to the database that >> map user identities to sets of servers. >> >> The flow of a request would be as follows: >> >> 1) C - Does realm routing using received peer load reports to load >> balance between AA1 and AA2. Assume C routes to AA1. >> >> 2) AA1 queries the DB. Assume the user identity starts with the >> number 1. The DB returns the set of servers including P1S1, P1S2 and P1S3. >> >> 3) AA1 then selects the server that is to handle the request from the >> set of servers returned. AA1 uses endpoint load reports received from >> P1S1, P1S2 and P1S3 to makes its selection. Assume in this case that >> AA1 selection P1S2. As a result AA1 inserts the Destination-Host AVP >> into the request with a value of P1S2. >> >> 4) AA1 then determines the route for the request. In this case the >> route would need to be determines based on the combination of the >> Destination-Realm, Application-ID and the Destination-Host in the >> request. The routing tables would indicate that P1A1 and P1A2 are the >> candidate next hop servers for the request. This requires AA1 to have >> a route defined for each of the servers. AA1 then uses peer load >> information received from P1A1 and P1A2 to select the next hop. >> Assume >> AA1 selects P1A1. >> >> 5) P1A1 determines that the request is targeted for P1S2 based on the >> Destination-Host AVP. As a result it routes the request directly to >> P1S2. P1A1 cannot use a peer report to load balance in this case as >> the request includes the destination in the Destination-Host AVP. >> >> The endpoint load report is used in step 3 to select the server that >> will handle the request. Peer load reports are used to select the >> next hop. >> >> Regards, >> >> Steve >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed May 13 15:16:29 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6FE1B3163; Wed, 13 May 2015 15:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApQQEC5jJPhx; Wed, 13 May 2015 15:16:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4FBD1B2DA0; Wed, 13 May 2015 15:16:24 -0700 (PDT) Received: from mutabilis-2.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4DMGNUu090100 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2015 17:16:24 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be mutabilis-2.local Message-ID: <5553CD32.4020402@nostrum.com> Date: Wed, 13 May 2015 17:16:18 -0500 From: "A. Jean Mahoney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "dime@ietf.org" References: <10824_1427968607_551D125F_10824_867_1_6B7134B31289DC4FAF731D844122B36EF26487@PEXCVZYM13.corporate.adroot.infra.ftgroup> <10543_1430988500_554B26D4_10543_477_1_417b420d-d78f-40e0-a1d6-a790092b32ec@PEXCVZYH01.corporate.adroot.infra.ftgroup> In-Reply-To: <10543_1430988500_554B26D4_10543_477_1_417b420d-d78f-40e0-a1d6-a790092b32ec@PEXCVZYH01.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "dime-chairs@ietf.org" Subject: Re: [Dime] Start of WGLC for draft-ietf-dime-4over6-provisioning-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 22:16:27 -0000 Hi all, I've reviewed the -01 draft and I'm ok with it. I have a few comments: Introduction: I suggest adding a line or two that the draft doesn't specify any new commands or Application-Ids and that the AVPs could be used for any Diameter application suitable for provisioning. Unless there was a specific application in mind, then that should be called out. References: draft-fsc-softwire-dhcp4o6-saddr-opt-01 has expired. Although it's only informative, it's referenced three times. I gather from the softwires mail archive that the draft expired quietly, so it may come back. However the authors want to handle it is fine with me. idnits complains about not finding [I-D.softwire-dslite-multicast]. Should be constructed [I-D.ietf-softwire-dslite-multicast]. Thanks! Jean On 5/7/15 3:48 AM, lionel.morand@orange.com wrote: > Hi, > > Except from the chairs and authors, we would need additional reviews to assess that there is a WG consensus on its content and be able to move it forward. > The document is short and a feedback like "I read it and I support this document" would be enough. > So please, review the document. > > For info, a minor updated version is available: http://tools.ietf.org/html/draft-ietf-dime-4over6-provisioning-01 > > Regards, > > Lionel > > -----Message d'origine----- > De : lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Envoyé : jeudi 2 avril 2015 11:57 > À : dime@ietf.org > Cc : dime-chairs@ietf.org > Objet : Start of WGLC for draft-ietf-dime-4over6-provisioning-00 > > During the Dime session at IETF92, it was conclude that the draft-ietf-dime-4over6-provisioning-00 was stable enough to launch a Working Group Last Call. > > This email officially starts a Working Group Last Call for the following document: > > http://tools.ietf.org/html/draft-ietf-dime-4over6-provisioning-00 > > Please respond to this email to support the document and/or send comments by 2015-04-16. > > In addition, following the strategy for promoting compliance with the IPR disclosure rules (RFC6702), the chairs would like to check whether there are claims of Intellectual Property Rights (IPR) on the document that need to be disclosed. Therefore, the following questions are addressed to the WG and Especially Authors and Contributors of the draft: > > * Are you personally aware of any IPR that applies to draft-ietf-dime-4over6-provisioning-00? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > * If you are a document author or listed contributor on this document, please reply to this email message regardless of whether or not you are personally aware of any relevant IPR. We might not be able to advance this document to the next stage until we have received a reply from each author and listed contributor. > > * If you are on the DIME WG email list but are not an author or listed contributor for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP 79. Please do not reply unless you want to make such a voluntary disclosure. > > Online tools for filing IPR disclosures can be found at . > > Regards, > > Lionel & Jouni > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 information 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 delete 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. > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 information 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 delete 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. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed May 13 17:20:19 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A42B1A1B12; Wed, 13 May 2015 17:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, 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 YDKUH4-3Hy_I; Wed, 13 May 2015 17:20:13 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1357A1A1AC9; Wed, 13 May 2015 17:20:13 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so59992246igb.1; Wed, 13 May 2015 17:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cW0RUKVuJiixWRjn6+L99eGlggXw5gyo8fxcW0YL+d4=; b=x6MnLm0auOHp21BQ4bbjvD4eokjGef2G6zNuDB4LHEcpoCAGRxMs1c/Pq75MpVj5ac ss0g12kXAe7L05yPpnkYByFS3zEtLNzpNvo6st9y/Z54TNRN3bSDHxVzR9RnjlnhiYl3 LS9MYL5hFg0R+VmLzVx8m+3bYco88A0JQoVh5vOUaPpkQAWJGQcPgbsnATHJcuKS7ebX brlgbd2YY1bSFZ/mWrFacpwgq2zrT1PA8gNi3c2IdFm+dHKizbmk2I2CKz5SvGGw70kl LV37ANq9mcNzlzyO7SWsRipi9XxxPWDr/JgvJA4AXYMm4bVStfOPT1y2FPyb35xMES3U nHgg== X-Received: by 10.43.151.83 with SMTP id kr19mr11798004icc.3.1431562812497; Wed, 13 May 2015 17:20:12 -0700 (PDT) Received: from [192.168.1.135] (dsl-173-206-48-122.tor.primus.ca. [173.206.48.122]) by mx.google.com with ESMTPSA id r4sm4736195igw.12.2015.05.13.17.20.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2015 17:20:12 -0700 (PDT) Message-ID: <5553EA3B.2050004@gmail.com> Date: Wed, 13 May 2015 20:20:11 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "A. Jean Mahoney" , lionel.morand@orange.com, "dime@ietf.org" References: <10824_1427968607_551D125F_10824_867_1_6B7134B31289DC4FAF731D844122B36EF26487@PEXCVZYM13.corporate.adroot.infra.ftgroup> <10543_1430988500_554B26D4_10543_477_1_417b420d-d78f-40e0-a1d6-a790092b32ec@PEXCVZYH01.corporate.adroot.infra.ftgroup> <5553CD32.4020402@nostrum.com> In-Reply-To: <5553CD32.4020402@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "dime-chairs@ietf.org" Subject: Re: [Dime] Start of WGLC for draft-ietf-dime-4over6-provisioning-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 00:20:17 -0000 Thanks, Jean. I already have an action on the multicast document, and I'll check with the authors on draft-fsc-softwire-saddr-opt. Tom On 13/05/2015 6:16 PM, A. Jean Mahoney wrote: > Hi all, > > I've reviewed the -01 draft and I'm ok with it. I have a few comments: > > Introduction: > > I suggest adding a line or two that the draft doesn't specify any new > commands or Application-Ids and that the AVPs could be used for any > Diameter application suitable for provisioning. Unless there was a > specific application in mind, then that should be called out. > > References: > > draft-fsc-softwire-dhcp4o6-saddr-opt-01 has expired. Although it's only > informative, it's referenced three times. I gather from the softwires > mail archive that the draft expired quietly, so it may come back. > However the authors want to handle it is fine with me. > > idnits complains about not finding [I-D.softwire-dslite-multicast]. > Should be constructed [I-D.ietf-softwire-dslite-multicast]. > > Thanks! > > Jean > > > On 5/7/15 3:48 AM, lionel.morand@orange.com wrote: >> Hi, >> >> Except from the chairs and authors, we would need additional reviews >> to assess that there is a WG consensus on its content and be able to >> move it forward. >> The document is short and a feedback like "I read it and I support >> this document" would be enough. >> So please, review the document. >> >> For info, a minor updated version is available: >> http://tools.ietf.org/html/draft-ietf-dime-4over6-provisioning-01 >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : lionel.morand@orange.com [mailto:lionel.morand@orange.com] >> Envoyé : jeudi 2 avril 2015 11:57 >> À : dime@ietf.org >> Cc : dime-chairs@ietf.org >> Objet : Start of WGLC for draft-ietf-dime-4over6-provisioning-00 >> >> During the Dime session at IETF92, it was conclude that the >> draft-ietf-dime-4over6-provisioning-00 was stable enough to launch a >> Working Group Last Call. >> >> This email officially starts a Working Group Last Call for the >> following document: >> >> http://tools.ietf.org/html/draft-ietf-dime-4over6-provisioning-00 >> >> Please respond to this email to support the document and/or send >> comments by 2015-04-16. >> >> In addition, following the strategy for promoting compliance with the >> IPR disclosure rules (RFC6702), the chairs would like to check >> whether there are claims of Intellectual Property Rights (IPR) on the >> document that need to be disclosed. Therefore, the following questions >> are addressed to the WG and Especially Authors and Contributors of the >> draft: >> >> * Are you personally aware of any IPR that applies to >> draft-ietf-dime-4over6-provisioning-00? If so, has this IPR been >> disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, >> 3669, and 5378 for more details.) >> >> * If you are a document author or listed contributor on this document, >> please reply to this email message regardless of whether or not you >> are personally aware of any relevant IPR. We might not be able to >> advance this document to the next stage until we have received a reply >> from each author and listed contributor. >> >> * If you are on the DIME WG email list but are not an author or listed >> contributor for this document, you are reminded of your opportunity >> for a voluntary IPR disclosure under BCP 79. Please do not reply >> unless you want to make such a voluntary disclosure. >> >> Online tools for filing IPR disclosures can be found at >> . >> >> Regards, >> >> Lionel & Jouni >> >> >> _________________________________________________________________________________________________________________________ >> >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles 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 electroniques 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 information 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 >> delete 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. >> >> >> _________________________________________________________________________________________________________________________ >> >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles 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 electroniques 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 information 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 >> delete 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. >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Fri May 15 02:02:13 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEF41A1B53 for ; Fri, 15 May 2015 02:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 vhMTJTzmsAXG for ; Fri, 15 May 2015 02:02:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66FD41A90A8 for ; Fri, 15 May 2015 02:01:54 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 6B3673240D3; Fri, 15 May 2015 11:01:52 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 4C5F9238081; Fri, 15 May 2015 11:01:52 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0235.001; Fri, 15 May 2015 11:01:52 +0200 From: To: "Wiehe, Ulrich (Nokia - DE/Munich)" , "ext Steve Donovan" , "dime@ietf.org" Thread-Topic: [Dime] Load Use Case justifying endpoint load reports Thread-Index: AQHQg3dy6ns84AqFpU6e3lgsucwgEp1uzuMAgABblACAANDjAIAM1Ksw Date: Fri, 15 May 2015 09:01:51 +0000 Message-ID: <31978_1431680512_5555B600_31978_2122_1_6B7134B31289DC4FAF731D844122B36E011EA917@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <55427AF7.6090002@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E847@DEMUMBX014.nsn-intra.net> <554A5BA6.8020703@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E970@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006682288E970@DEMUMBX014.nsn-intra.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.5.15.84516 Archived-At: Subject: Re: [Dime] Load Use Case justifying endpoint load reports X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 09:02:12 -0000 Hi Steve, The step 4 is simply against the routing rules defined in RFC6733. For exam= ple, you can refer to the following statement to understand that using the = Destination-Host AVP for routing when the host Id is not part of the peer t= able is not so "standard": Note that an agent can only forward a request to a host described in the Destination-Host AVP if the host in question is included in its peer table (see Section 2.6). Otherwise, the request is routed based on the Destination-Realm only (see Section 6.1.6). It does not mean that additional routing criteria cannot be used for reques= t routing purposes but there are considered as out of the base protocol and= therefore application-specific. For instance, the Cx interface defined a function performing user id to ser= ver id resolution but it is defined as a specific extension of the base pro= tocol and therefore defined as part of a specific diameter application. It is not preclude to work on a solution that could be used by application.= However, I think that the basic solution defined as part of the standard p= rocess should only comply with the base protocol routing principle. Otherwi= se, there is no way to limit the type of information that could be part of = the load information exchanged between Diameter nodes. Obviously, the basel= ine solution can be defined in a way that it could be possible to extend it= for specific purposes. But I am against putting vendor-specific requiremen= ts in a solution defined as part of the standard stream (i.e. based on the = RFC6733). Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (Nok= ia - DE/Munich) Envoy=E9=A0: jeudi 7 mai 2015 08:49 =C0=A0: ext Steve Donovan; dime@ietf.org Objet=A0: Re: [Dime] Load Use Case justifying endpoint load reports Hi Steve, thank you for the clarification. As I said, I'm not against. I rather support your proposal. Ulrich -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Wednesday, May 06, 2015 8:21 PM To: Wiehe, Ulrich (Nokia - DE/Munich); dime@ietf.org Subject: Re: [Dime] Load Use Case justifying endpoint load reports Ulrich, Thanks for pointing out the argument against this use case. I understand that the default set of information used for request routing i= s the Destination-Realm and application-id. There is nothing, however, tha= t says this is the only set of information that can be used. In fact, the = following from section 6.1.6. in RFC6733 affirms that there are cases when = additional information will be used: " Realm names and Application Ids are the minimum supported routing criteria, additional information may be needed to support redirect semantics." The case below suggests the use of Destination-Host. There are scenarios w= here session-ID, for session based applications, can be used. There is no = reason that an agent couldn't use any AVP to make routing decisions. In addition, Diameter is being used in ways that were not anticipated by th= e original authors. That is a good thing. I know of many Diameter networks that fit into this use case. We need to t= ake them into account when designing the load mechanism. Regards, Steve On 5/6/15 7:53 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote: > Hi Steve, > I'm not against your proposal, however, it has been argued that=20 > (according to established routing principles) in step 4)=20 > Destination-Host is not part of the information used to determine the=20 > route. > Any reaction to this? > > Best regards > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 > Donovan > Sent: Thursday, April 30, 2015 8:57 PM > To: dime@ietf.org > Subject: [Dime] Load Use Case justifying endpoint load reports > > All, > > There has been some offline discussion about whether or not the=20 > Diameter Load mechanism should include two types of Load reports. I=20 > believe there is consensus that there is the need for a peer load=20 > report to support load balancing when routing requests to the next hop. > > The question is whether or not we should also support an "endpoint"=20 > load report. This load report would be the load of a server (or a=20 > client) and would be carried end-to-end. > > The case for an endpoint load report can be supported by the following=20 > use case. > > Assume a Diameter network for a Diameter application where the servers=20 > are partitioned across the user space. For simplicity, assume that=20 > user identities starting with the numbers 0 through 4 are handled by=20 > partition 1 and that user identities starting with the numbers 5=20 > through > 9 are handled by partition 2. > > Also assume that each partition has three servers -- P1S1, P1S2 and=20 > P1S2 in partition 1 and P2S1, P2S2 AND P2S3 in partition 2. > > Next assume that there is a database that maps user identities to=20 > partitions. This scenario assumes that the database is a standalone=20 > device that has some query mechanism for accessing the mapping. > Different implementations are possible. The query has the user=20 > identity as the key and a set of Diameter servers as the response.=20=20 > This query does NOT return anything but the set of servers able to=20 > handle requests for the user id presented. Specifically, the query=20 > does not return the load of the servers. > > Now, assume the following network topology: > > P1S1 P1S2 P1S3 P2S1 P2S2 P2S3 > \ | / \ | / > ------- ------- > / \ / \ > P1A1 P1A2 P2A1 P2A2 > | | | | > ------------------------------------- > | | > DB---- AA1 AA2-----DB > \ / > C > > The lines are for convenience, they are not meant to imply anything=20 > physical, just that AA1 has connections to P1A1, P1A2, P2A1 and P2A2,=20 > for instance. > > AA1 and AA2 are "access agents" and have access to the database that=20 > map user identities to sets of servers. > > The flow of a request would be as follows: > > 1) C - Does realm routing using received peer load reports to load=20 > balance between AA1 and AA2. Assume C routes to AA1. > > 2) AA1 queries the DB. Assume the user identity starts with the=20 > number 1. The DB returns the set of servers including P1S1, P1S2 and P1S= 3. > > 3) AA1 then selects the server that is to handle the request from the=20 > set of servers returned. AA1 uses endpoint load reports received from=20 > P1S1, P1S2 and P1S3 to makes its selection. Assume in this case that > AA1 selection P1S2. As a result AA1 inserts the Destination-Host AVP=20 > into the request with a value of P1S2. > > 4) AA1 then determines the route for the request. In this case the=20 > route would need to be determines based on the combination of the=20 > Destination-Realm, Application-ID and the Destination-Host in the=20 > request. The routing tables would indicate that P1A1 and P1A2 are the=20 > candidate next hop servers for the request. This requires AA1 to have=20 > a route defined for each of the servers. AA1 then uses peer load=20 > information received from P1A1 and P1A2 to select the next hop.=20=20 > Assume > AA1 selects P1A1. > > 5) P1A1 determines that the request is targeted for P1S2 based on the=20 > Destination-Host AVP. As a result it routes the request directly to=20 > P1S2. P1A1 cannot use a peer report to load balance in this case as=20 > the request includes the destination in the Destination-Host AVP. > > The endpoint load report is used in step 3 to select the server that=20 > will handle the request. Peer load reports are used to select the=20 > next hop. > > Regards, > > Steve > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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 nobody Fri May 15 09:18:13 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59611A1B40 for ; Fri, 15 May 2015 09:18:12 -0700 (PDT) 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, FREEMAIL_FROM=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 pVOHpDkonkUO for ; Fri, 15 May 2015 09:18:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5D51A1B2E for ; Fri, 15 May 2015 09:18:08 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 35B17374232; Fri, 15 May 2015 18:18:06 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 1A20BC8075; Fri, 15 May 2015 18:18:06 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0235.001; Fri, 15 May 2015 18:18:05 +0200 From: To: Steve Donovan , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" Thread-Topic: [Dime] Load Use Case justifying endpoint load reports Thread-Index: AQHQg3d5m1t1LcLgzkilR8rHOTKOgZ1uzuMAgABblACAANDjAIAHEirAgAE5WYCABQYiwA== Date: Fri, 15 May 2015 16:18:04 +0000 Message-ID: <12414_1431706686_55561C3E_12414_6637_1_6B7134B31289DC4FAF731D844122B36E011F19AA@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <55427AF7.6090002@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E847@DEMUMBX014.nsn-intra.net> <554A5BA6.8020703@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E970@DEMUMBX014.nsn-intra.net> <55520035.2010701@usdonovans.com> In-Reply-To: <55520035.2010701@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.5.15.154515 Archived-At: Subject: Re: [Dime] Load Use Case justifying endpoint load reports X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 16:18:12 -0000 Hi Steve, JJ, Please see below. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9=A0: mardi 12 mai 2015 15:29 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Objet=A0: Re: [Dime] Load Use Case justifying endpoint load reports Jean-Jacques, This was a good analysis, thanks. It comes down to the question - Do we limit the solution to the routing rul= es defined twelve years ago or do we design a solution that addresses how D= iameter is currently being used? [LM] RFC6733 has been published in October 2012. Only 3 years ago after lon= g, very long discussions. At this time, I didn't hear about any requirement= for changing the routing principles given in the base protocol. The use case I outlined is a common occurrence in today's Diameter networks= . We should design a solution that addresses the needs of all Diameter net= works, including those that require routing on more than just Destination-R= ealm and Application-ID. [LM] Designing a simple solution that can be enhanced to support any specif= ic requirement without standard action is also a good solution from my poin= t of view. Regards, Steve On 5/12/15 2:05 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: > Hi Steve and all > > > This topic of the load control solution scope is not easy and I hereafter= give my views on the basis of the offline discussion on this topic and th= e use cases to address, in particular the partition use case that Steve pre= sented. >=20=20=20 > In the offline discussion we had, several use cases, including if I remem= ber well partition use cases (in 3GPP a main partition case is the HSS one)= were addressed. > > A) The important question in fact is the scope of a Load control=20 > standardization, > - RFC 6733 specifies a basic set of routing rules that I hereafter summa= rized: > a) if the destination Host when present in the request is in the pe= er table, the request is sent to this peer. > b) In other cases (destination host present or not in the=20 > request), the routing table gives the possible peers for a given realm=20 > /application entry >=20=20=20 > - RFC 6733 allows to have additional routing criteria as Steve indicated= in 6.1.6, but they are not described and so out of the RFC 6733 scope. > - when considering load control, Lionel's position is that the load cont= rol to be standardized is the one useful/needed for the above basic set of = routing rules. Additional load control mechanisms that would be useful whe= n coupled to routing criteria out of 6733 scope are outside of the load con= trol standardization scope. The reason is because we cannot define all the = possible routing cases outside RFC6733 to see which load control would be n= eeded; we can only specify a load control mechanism applicable to the basi= c set of routing rules. > > - when considering the load control for the basic set of routing rules > - for a), there is no need to consider load information as the peer = is selected from the peer table > - for b), as there can be several peers, load info of the different = peers is used to select the peer and achieve load balancing. The load of e= nd points (servers) which are not peers cannot be used for this peer selec= tion. > > In conclusion, with the basic set of routing rules, only load info from t= he peers is needed for peer selection, no need for end point load info. > > Lionel, please check if I have well summarized your position. > >=20=20=20 > B) The above perimeter brings strong restrictions for the possible use ca= ses to be in the scope. In particular the partition use cases as the one d= escribed by Steve requires an additional routing criteria (cf step 4) in S= teve's mail) which makes this case out of the scope of the basic set of RFC= 6733 routing rules, so also out of the scope of a standardized load contro= l mechanis, although this partition use case is frequent in deployed networ= ks (for HSS in 3GPP). > Does Dime do an exception to also include this use case in the scope of l= oad control mechanism? > >=20=20=20=20 > C) In draft-campbell-dime-load-considerations-01, use cases (which=20 > are not partition use cases) are described in 10.1 to 10.7 sections.=20 > Which ones are compliant with the basic set of RFC 6733 basic rules=20 > without requiring additional specific routing criteria > - 10.1 No agent: compliant > - 10.2 Single agent: compliant > - 10.3 Multiple Agents: not compliant (for a request from C with a=20 > destination host) > - 10.4 Linked agent: partially compliant ( A1 has a routing table for the= realm/application containing S1 , S3 ... and A2), this may drives to non o= ptimal routing, especially when several agents). > - 10.5 Shared server pools: compliant > - 10.6 Agent chain: not compliant (as for 10.3 if A3 has not A2 in its=20 > routing table) or partially compliant (as for 10.4 if A3 has A2 in its=20 > routing table) > - 10.7 Fully meshed layers: compliant. > > > Note: for partially compliant cases, improvement can be done by giving a = higher priority to peers that are servers (eg S1 , S3 in 10.4 for A1 routin= g table) than to the peers that are agents(eg A2 in 10.4 for A1 routing ta= ble). Such a priority is a specific additional routing criteria which is p= ossible but out of the scope of the basic set of routing rules. >=20=20=20=20 > In fact only the fully meshed cases allow a routing only based on the bas= ic set of rules. Other cases imply additional specific rules not described = in RFC 6733. > > If we now consider the load control solution, the fully meshed cases (10.= 1, 10.2, 10.5, 10.7) only need peer load info to achieve a right load bala= ncing between servers and also between agents, as described in A). > But existing deployments, especially large networks, are not in a fully m= eshed configuration, so they enter other use cases (10.3, 10.4, 10.6) for w= hich the peer load info is not sufficient. I am not sure that the end-point= load info (cf B)) is a good answer for these cases which are different fr= om the partition cases. Again, the question raises to do an exception to al= so include some of these use cases in the scope of load control solution? > > > D) There are also the use cases with Redirect Agents. Here according to m= y understanding of RFC 6733, the Redirect Hosts returned to the node having= requested the Redirect agent are peers (direct connection) of the node doi= ng the redirect request (cf RFC 6733 2.8.3 and 6.1.8), and if several Redir= ect hosts are returned this enters the peer selection case achievable with = the peer load info (cf A)), so not requiring e.g. an end-point load info. > > > E) I would like you to check if I have not some errors/misunderstanding = in my above analysis, and then to have your position on the following: > - solution with peer load information allows load control for routing ca= ses using the basic set of RFC 6733 routing rules, as described in A). I th= ink we all agree on A) and we can now start the writing of this solution in= the draft. > - Redirect use cases also rely on the this peer load information=20 > solution > - we have then to decide if we support some additional use cases outside = the basic set of RFC 6733 routing rules, because they are important in exis= ting deployments. The one to consider first would be the partition case wi= th end point load info which Steve presented and which corresponds to the 3= GPP important HSS use case. Other presented use cases (cf C))can be left fo= r possible future extension. > > Thank you > > Best regards > > JJacques >=20=20=20=20 > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (Nokia - DE/Munich) Envoy=E9 : jeudi 7 mai 2015 08:49 =C0 : ext Steve=20 > Donovan; dime@ietf.org Objet : Re: [Dime] Load Use Case justifying=20 > endpoint load reports > > Hi Steve, > > thank you for the clarification. > As I said, I'm not against. I rather support your proposal. > > Ulrich > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, May 06, 2015 8:21 PM > To: Wiehe, Ulrich (Nokia - DE/Munich); dime@ietf.org > Subject: Re: [Dime] Load Use Case justifying endpoint load reports > > Ulrich, > > Thanks for pointing out the argument against this use case. > > I understand that the default set of information used for request routing= is the Destination-Realm and application-id. There is nothing, however, t= hat says this is the only set of information that can be used. In fact, th= e following from section 6.1.6. in RFC6733 affirms that there are cases whe= n additional information will be used: > > " Realm names and Application Ids are the minimum supported routing > criteria, additional information may be needed to support redirect > semantics." > > The case below suggests the use of Destination-Host. There are scenarios= where session-ID, for session based applications, can be used. There is n= o reason that an agent couldn't use any AVP to make routing decisions. > > In addition, Diameter is being used in ways that were not anticipated by = the original authors. That is a good thing. > > I know of many Diameter networks that fit into this use case. We need to= take them into account when designing the load mechanism. > > Regards, > > Steve > > On 5/6/15 7:53 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote: >> Hi Steve, >> I'm not against your proposal, however, it has been argued that=20 >> (according to established routing principles) in step 4)=20 >> Destination-Host is not part of the information used to determine the=20 >> route. >> Any reaction to this? >> >> Best regards >> Ulrich >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 >> Donovan >> Sent: Thursday, April 30, 2015 8:57 PM >> To: dime@ietf.org >> Subject: [Dime] Load Use Case justifying endpoint load reports >> >> All, >> >> There has been some offline discussion about whether or not the=20 >> Diameter Load mechanism should include two types of Load reports. I=20 >> believe there is consensus that there is the need for a peer load=20 >> report to support load balancing when routing requests to the next hop. >> >> The question is whether or not we should also support an "endpoint" >> load report. This load report would be the load of a server (or a >> client) and would be carried end-to-end. >> >> The case for an endpoint load report can be supported by the=20 >> following use case. >> >> Assume a Diameter network for a Diameter application where the=20 >> servers are partitioned across the user space. For simplicity,=20 >> assume that user identities starting with the numbers 0 through 4 are=20 >> handled by partition 1 and that user identities starting with the=20 >> numbers 5 through >> 9 are handled by partition 2. >> >> Also assume that each partition has three servers -- P1S1, P1S2 and >> P1S2 in partition 1 and P2S1, P2S2 AND P2S3 in partition 2. >> >> Next assume that there is a database that maps user identities to=20 >> partitions. This scenario assumes that the database is a standalone=20 >> device that has some query mechanism for accessing the mapping. >> Different implementations are possible. The query has the user=20 >> identity as the key and a set of Diameter servers as the response. >> This query does NOT return anything but the set of servers able to=20 >> handle requests for the user id presented. Specifically, the query=20 >> does not return the load of the servers. >> >> Now, assume the following network topology: >> >> P1S1 P1S2 P1S3 P2S1 P2S2 P2S3 >> \ | / \ | / >> ------- ------- >> / \ / \ >> P1A1 P1A2 P2A1 P2A2 >> | | | | >> ------------------------------------- >> | | >> DB---- AA1 AA2-----DB >> \ / >> C >> >> The lines are for convenience, they are not meant to imply anything=20 >> physical, just that AA1 has connections to P1A1, P1A2, P2A1 and P2A2,=20 >> for instance. >> >> AA1 and AA2 are "access agents" and have access to the database that=20 >> map user identities to sets of servers. >> >> The flow of a request would be as follows: >> >> 1) C - Does realm routing using received peer load reports to load=20 >> balance between AA1 and AA2. Assume C routes to AA1. >> >> 2) AA1 queries the DB. Assume the user identity starts with the=20 >> number 1. The DB returns the set of servers including P1S1, P1S2 and P1= S3. >> >> 3) AA1 then selects the server that is to handle the request from the=20 >> set of servers returned. AA1 uses endpoint load reports received=20 >> from P1S1, P1S2 and P1S3 to makes its selection. Assume in this case=20 >> that >> AA1 selection P1S2. As a result AA1 inserts the Destination-Host AVP=20 >> into the request with a value of P1S2. >> >> 4) AA1 then determines the route for the request. In this case the=20 >> route would need to be determines based on the combination of the=20 >> Destination-Realm, Application-ID and the Destination-Host in the=20 >> request. The routing tables would indicate that P1A1 and P1A2 are=20 >> the candidate next hop servers for the request. This requires AA1 to=20 >> have a route defined for each of the servers. AA1 then uses peer=20 >> load information received from P1A1 and P1A2 to select the next hop. >> Assume >> AA1 selects P1A1. >> >> 5) P1A1 determines that the request is targeted for P1S2 based on the=20 >> Destination-Host AVP. As a result it routes the request directly to=20 >> P1S2. P1A1 cannot use a peer report to load balance in this case as=20 >> the request includes the destination in the Destination-Host AVP. >> >> The endpoint load report is used in step 3 to select the server that=20 >> will handle the request. Peer load reports are used to select the=20 >> next hop. >> >> Regards, >> >> Steve >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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 nobody Mon May 18 08:10:49 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34421A9154; Mon, 18 May 2015 08:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZK0FFQLxVYXd; Mon, 18 May 2015 08:10:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8A11A9147; Mon, 18 May 2015 08:10:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150518151047.17954.81737.idtracker@ietfa.amsl.com> Date: Mon, 18 May 2015 08:10:47 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] Last Call: (Diameter Congestion and Filter Attributes) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 15:10:49 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Congestion and Filter Attributes' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-06-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines optional ECN and filter related attributes that can be used for improved traffic identification, support of ECN and minimized filter administration within Diameter. RFC 5777 defines a Filter-Rule AVP that accommodates extensions for classification, conditions and actions. It does not support traffic identification for packets using Explicit Congestion Notification as defined in RFC 3168 and does not provide specific actions when the flow(s) described by the Filter-Rule are congested. A Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g. packets) is not captured in Accounting applications, leaving administrators without useful information regarding the effectiveness or understanding of the filter definition. These optional attributes are forward and backwards compatible with RFC 5777. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed May 20 19:41:50 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AB61ACE88; Wed, 20 May 2015 19:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFU4tPwshMlo; Wed, 20 May 2015 19:41:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30771ACE87; Wed, 20 May 2015 19:41:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSU08140; Thu, 21 May 2015 02:41:45 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 May 2015 03:41:44 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.126]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Thu, 21 May 2015 10:41:34 +0800 From: "Huangjing (A)" To: "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [Dime] Start of WGLC for draft-ietf-dime-4over6-provisioning-00 Thread-Index: AdBtKy1XVNGa27alSqquHaQEoRv65wbdpW+wArNrItA= Date: Thu, 21 May 2015 02:41:34 +0000 Message-ID: <774B240D54DAB844B37EE80C2DD8E8BC673EBAE3@SZXEMA501-MBS.china.huawei.com> References: <10824_1427968607_551D125F_10824_867_1_6B7134B31289DC4FAF731D844122B36EF26487@PEXCVZYM13.corporate.adroot.infra.ftgroup> <10543_1430988500_554B26D4_10543_477_1_417b420d-d78f-40e0-a1d6-a790092b32ec@PEXCVZYH01.corporate.adroot.infra.ftgroup> In-Reply-To: <10543_1430988500_554B26D4_10543_477_1_417b420d-d78f-40e0-a1d6-a790092b32ec@PEXCVZYH01.corporate.adroot.infra.ftgroup> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.116.136] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dime-chairs@ietf.org" Subject: Re: [Dime] Start of WGLC for draft-ietf-dime-4over6-provisioning-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 02:41:49 -0000 Hi, Folks,=20 I support this document, which will provide one more option for 4over6 prov= isioning. James > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of > lionel.morand@orange.com > Sent: Thursday, May 07, 2015 4:48 PM > To: MORAND Lionel IMT/OLN; dime@ietf.org > Cc: dime-chairs@ietf.org > Subject: Re: [Dime] Start of WGLC for draft-ietf-dime-4over6-provisioning= -00 >=20 > Hi, >=20 > Except from the chairs and authors, we would need additional reviews to > assess that there is a WG consensus on its content and be able to move it > forward. > The document is short and a feedback like "I read it and I support this > document" would be enough. > So please, review the document. >=20 > For info, a minor updated version is available: > http://tools.ietf.org/html/draft-ietf-dime-4over6-provisioning-01 >=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De=A0: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Envoy=E9=A0: jeudi 2 avril 2015 11:57 =C0=A0: dime@ietf.org Cc=A0: dime-c= hairs@ietf.org > Objet=A0: Start of WGLC for draft-ietf-dime-4over6-provisioning-00 >=20 > During the Dime session at IETF92, it was conclude that the > draft-ietf-dime-4over6-provisioning-00 was stable enough to launch a Work= ing > Group Last Call. >=20 > This email officially starts a Working Group Last Call for the following > document: >=20 > http://tools.ietf.org/html/draft-ietf-dime-4over6-provisioning-00 >=20 > Please respond to this email to support the document and/or send comments > by 2015-04-16. >=20 > In addition, following the strategy for promoting compliance with the IPR > disclosure rules (RFC6702), the chairs would like to check whether there= are > claims of Intellectual Property Rights (IPR) on the document that need to= be > disclosed. Therefore, the following questions are addressed to the WG and > Especially Authors and Contributors of the draft: >=20 > * Are you personally aware of any IPR that applies to > draft-ietf-dime-4over6-provisioning-00? If so, has this IPR been disclose= d in > compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 fo= r > more details.) >=20 > * If you are a document author or listed contributor on this document, pl= ease > reply to this email message regardless of whether or not you are personal= ly > aware of any relevant IPR. We might not be able to advance this document= to > the next stage until we have received a reply from each author and listed > contributor. >=20 > * If you are on the DIME WG email list but are not an author or listed > contributor for this document, you are reminded of your opportunity for a > voluntary IPR disclosure under BCP 79. Please do not reply unless you w= ant > to make such a voluntary disclosure. >=20 > Online tools for filing IPR disclosures can be found at > . >=20 > Regards, >=20 > Lionel & Jouni >=20 >=20 > ________________________________________________________________ > _________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information 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 de= lete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. >=20 >=20 > ________________________________________________________________ > _________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information 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 de= lete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Tue May 26 09:55:14 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CD31B2C5E for ; Tue, 26 May 2015 09:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 yE9rcFWZiCHz for ; Tue, 26 May 2015 09:55:10 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50A6F1AC422 for ; Tue, 26 May 2015 09:55:10 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:55209 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YxI8A-000CNd-9W for dime@ietf.org; Tue, 26 May 2015 09:55:09 -0700 Message-ID: <5564A568.90709@usdonovans.com> Date: Tue, 26 May 2015 11:55:04 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dime@ietf.org" References: <20150526165308.32327.33326.idtracker@ietfa.amsl.com> In-Reply-To: <20150526165308.32327.33326.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150526165308.32327.33326.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080804080702060608000901" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [Dime] Fwd: New Version Notification for draft-donovan-dime-drmp-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 16:55:12 -0000 This is a multi-part message in MIME format. --------------080804080702060608000901 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I have posted an updated version of the Diameter Routing Message Priority draft. The goal is for this draft to become a working group draft to address routing message priorities as input to Diameter overload abatement decisions. Regards, Steve -------- Forwarded Message -------- Subject: New Version Notification for draft-donovan-dime-drmp-01.txt Date: Tue, 26 May 2015 09:53:08 -0700 From: internet-drafts@ietf.org To: Steve Donovan , Steve Donovan A new version of I-D, draft-donovan-dime-drmp-01.txt has been successfully submitted by Steve Donovan and posted to the IETF repository. Name: draft-donovan-dime-drmp Revision: 01 Title: Diameter Routing Message Priority Document date: 2015-05-26 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-donovan-dime-drmp-01.txt Status: https://datatracker.ietf.org/doc/draft-donovan-dime-drmp/ Htmlized: https://tools.ietf.org/html/draft-donovan-dime-drmp-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-donovan-dime-drmp-01 Abstract: When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document defines a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information Diameter nodes can factor that priority into routing, resource allocation and overload abatement decisions. 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. The IETF Secretariat --------------080804080702060608000901 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I have posted an updated version of the Diameter Routing Message Priority draft.  The goal is for this draft to become a working group draft to address routing message priorities as input to Diameter overload abatement decisions.

Regards,

Steve

-------- Forwarded Message --------
Subject: New Version Notification for draft-donovan-dime-drmp-01.txt
Date: Tue, 26 May 2015 09:53:08 -0700
From: internet-drafts@ietf.org
To: Steve Donovan <srdonovan@usdonovans.com>, Steve Donovan <srdonovan@usdonovans.com> 


A new version of I-D, draft-donovan-dime-drmp-01.txt
has been successfully submitted by Steve Donovan and posted to the
IETF repository.

Name:		draft-donovan-dime-drmp
Revision:	01
Title:		Diameter Routing Message Priority
Document date:	2015-05-26
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/internet-drafts/draft-donovan-dime-drmp-01.txt
Status:         https://datatracker.ietf.org/doc/draft-donovan-dime-drmp/
Htmlized:       https://tools.ietf.org/html/draft-donovan-dime-drmp-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-donovan-dime-drmp-01

Abstract:
   When making routing and resource allocation decisions, Diameter nodes
   currently have no generic mechanism to determine the relative
   priority of Diameter messages.  This document defines a mechanism to
   allow Diameter endpoints to indicate the relative priority of
   Diameter transactions.  With this information Diameter nodes can
   factor that priority into routing, resource allocation and overload
   abatement decisions.

                                                                                  


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.

The IETF Secretariat


--------------080804080702060608000901-- From nobody Tue May 26 09:58:42 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459521A1B9A for ; Tue, 26 May 2015 09:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, 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 1GtRt2sIcKG5 for ; Tue, 26 May 2015 09:58:38 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771391A1AC1 for ; Tue, 26 May 2015 09:58:38 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:55224 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YxIBX-0002bY-0y; Tue, 26 May 2015 09:58:38 -0700 Message-ID: <5564A639.7000406@usdonovans.com> Date: Tue, 26 May 2015 11:58:33 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" References: <55427AF7.6090002@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E847@DEMUMBX014.nsn-intra.net> <554A5BA6.8020703@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E970@DEMUMBX014.nsn-intra.net> <55520035.2010701@usdonovans.com> <12414_1431706686_55561C3E_12414_6637_1_6B7134B31289DC4FAF731D844122B36E011F19AA@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <12414_1431706686_55561C3E_12414_6637_1_6B7134B31289DC4FAF731D844122B36E011F19AA@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Dime] Load Use Case justifying endpoint load reports X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 16:58:41 -0000 On 5/15/15 11:18 AM, lionel.morand@orange.com wrote: > Hi Steve, JJ, > > Please see below. > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoyé : mardi 12 mai 2015 15:29 > À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org > Objet : Re: [Dime] Load Use Case justifying endpoint load reports > > Jean-Jacques, > > This was a good analysis, thanks. > > It comes down to the question - Do we limit the solution to the routing rules defined twelve years ago or do we design a solution that addresses how Diameter is currently being used? > [LM] RFC6733 has been published in October 2012. Only 3 years ago after long, very long discussions. At this time, I didn't hear about any requirement for changing the routing principles given in the base protocol. SRD> Ok, it was reviewed three years ago. My point is still relevant. Things have changed since, or, more likely, were in the process of changing when 6733 was being worked on. > > The use case I outlined is a common occurrence in today's Diameter networks. We should design a solution that addresses the needs of all Diameter networks, including those that require routing on more than just Destination-Realm and Application-ID. > [LM] Designing a simple solution that can be enhanced to support any specific requirement without standard action is also a good solution from my point of view. SRD> I don't understand how it can be enhanced without standards action if multiple implementations are expected to interoperate. > > > Regards, > > Steve > > On 5/12/15 2:05 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: >> Hi Steve and all >> >> >> This topic of the load control solution scope is not easy and I hereafter give my views on the basis of the offline discussion on this topic and the use cases to address, in particular the partition use case that Steve presented. >> >> In the offline discussion we had, several use cases, including if I remember well partition use cases (in 3GPP a main partition case is the HSS one) were addressed. >> >> A) The important question in fact is the scope of a Load control >> standardization, >> - RFC 6733 specifies a basic set of routing rules that I hereafter summarized: >> a) if the destination Host when present in the request is in the peer table, the request is sent to this peer. >> b) In other cases (destination host present or not in the >> request), the routing table gives the possible peers for a given realm >> /application entry >> >> - RFC 6733 allows to have additional routing criteria as Steve indicated in 6.1.6, but they are not described and so out of the RFC 6733 scope. >> - when considering load control, Lionel's position is that the load control to be standardized is the one useful/needed for the above basic set of routing rules. Additional load control mechanisms that would be useful when coupled to routing criteria out of 6733 scope are outside of the load control standardization scope. The reason is because we cannot define all the possible routing cases outside RFC6733 to see which load control would be needed; we can only specify a load control mechanism applicable to the basic set of routing rules. >> >> - when considering the load control for the basic set of routing rules >> - for a), there is no need to consider load information as the peer is selected from the peer table >> - for b), as there can be several peers, load info of the different peers is used to select the peer and achieve load balancing. The load of end points (servers) which are not peers cannot be used for this peer selection. >> >> In conclusion, with the basic set of routing rules, only load info from the peers is needed for peer selection, no need for end point load info. >> >> Lionel, please check if I have well summarized your position. >> >> >> B) The above perimeter brings strong restrictions for the possible use cases to be in the scope. In particular the partition use cases as the one described by Steve requires an additional routing criteria (cf step 4) in Steve's mail) which makes this case out of the scope of the basic set of RFC 6733 routing rules, so also out of the scope of a standardized load control mechanis, although this partition use case is frequent in deployed networks (for HSS in 3GPP). >> Does Dime do an exception to also include this use case in the scope of load control mechanism? >> >> >> C) In draft-campbell-dime-load-considerations-01, use cases (which >> are not partition use cases) are described in 10.1 to 10.7 sections. >> Which ones are compliant with the basic set of RFC 6733 basic rules >> without requiring additional specific routing criteria >> - 10.1 No agent: compliant >> - 10.2 Single agent: compliant >> - 10.3 Multiple Agents: not compliant (for a request from C with a >> destination host) >> - 10.4 Linked agent: partially compliant ( A1 has a routing table for the realm/application containing S1 , S3 ... and A2), this may drives to non optimal routing, especially when several agents). >> - 10.5 Shared server pools: compliant >> - 10.6 Agent chain: not compliant (as for 10.3 if A3 has not A2 in its >> routing table) or partially compliant (as for 10.4 if A3 has A2 in its >> routing table) >> - 10.7 Fully meshed layers: compliant. >> >> >> Note: for partially compliant cases, improvement can be done by giving a higher priority to peers that are servers (eg S1 , S3 in 10.4 for A1 routing table) than to the peers that are agents(eg A2 in 10.4 for A1 routing table). Such a priority is a specific additional routing criteria which is possible but out of the scope of the basic set of routing rules. >> >> In fact only the fully meshed cases allow a routing only based on the basic set of rules. Other cases imply additional specific rules not described in RFC 6733. >> >> If we now consider the load control solution, the fully meshed cases (10.1, 10.2, 10.5, 10.7) only need peer load info to achieve a right load balancing between servers and also between agents, as described in A). >> But existing deployments, especially large networks, are not in a fully meshed configuration, so they enter other use cases (10.3, 10.4, 10.6) for which the peer load info is not sufficient. I am not sure that the end-point load info (cf B)) is a good answer for these cases which are different from the partition cases. Again, the question raises to do an exception to also include some of these use cases in the scope of load control solution? >> >> >> D) There are also the use cases with Redirect Agents. Here according to my understanding of RFC 6733, the Redirect Hosts returned to the node having requested the Redirect agent are peers (direct connection) of the node doing the redirect request (cf RFC 6733 2.8.3 and 6.1.8), and if several Redirect hosts are returned this enters the peer selection case achievable with the peer load info (cf A)), so not requiring e.g. an end-point load info. >> >> >> E) I would like you to check if I have not some errors/misunderstanding in my above analysis, and then to have your position on the following: >> - solution with peer load information allows load control for routing cases using the basic set of RFC 6733 routing rules, as described in A). I think we all agree on A) and we can now start the writing of this solution in the draft. >> - Redirect use cases also rely on the this peer load information >> solution >> - we have then to decide if we support some additional use cases outside the basic set of RFC 6733 routing rules, because they are important in existing deployments. The one to consider first would be the partition case with end point load info which Steve presented and which corresponds to the 3GPP important HSS use case. Other presented use cases (cf C))can be left for possible future extension. >> >> Thank you >> >> Best regards >> >> JJacques >> >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich >> (Nokia - DE/Munich) Envoyé : jeudi 7 mai 2015 08:49 À : ext Steve >> Donovan; dime@ietf.org Objet : Re: [Dime] Load Use Case justifying >> endpoint load reports >> >> Hi Steve, >> >> thank you for the clarification. >> As I said, I'm not against. I rather support your proposal. >> >> Ulrich >> >> -----Original Message----- >> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Wednesday, May 06, 2015 8:21 PM >> To: Wiehe, Ulrich (Nokia - DE/Munich); dime@ietf.org >> Subject: Re: [Dime] Load Use Case justifying endpoint load reports >> >> Ulrich, >> >> Thanks for pointing out the argument against this use case. >> >> I understand that the default set of information used for request routing is the Destination-Realm and application-id. There is nothing, however, that says this is the only set of information that can be used. In fact, the following from section 6.1.6. in RFC6733 affirms that there are cases when additional information will be used: >> >> " Realm names and Application Ids are the minimum supported routing >> criteria, additional information may be needed to support redirect >> semantics." >> >> The case below suggests the use of Destination-Host. There are scenarios where session-ID, for session based applications, can be used. There is no reason that an agent couldn't use any AVP to make routing decisions. >> >> In addition, Diameter is being used in ways that were not anticipated by the original authors. That is a good thing. >> >> I know of many Diameter networks that fit into this use case. We need to take them into account when designing the load mechanism. >> >> Regards, >> >> Steve >> >> On 5/6/15 7:53 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote: >>> Hi Steve, >>> I'm not against your proposal, however, it has been argued that >>> (according to established routing principles) in step 4) >>> Destination-Host is not part of the information used to determine the >>> route. >>> Any reaction to this? >>> >>> Best regards >>> Ulrich >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>> Donovan >>> Sent: Thursday, April 30, 2015 8:57 PM >>> To: dime@ietf.org >>> Subject: [Dime] Load Use Case justifying endpoint load reports >>> >>> All, >>> >>> There has been some offline discussion about whether or not the >>> Diameter Load mechanism should include two types of Load reports. I >>> believe there is consensus that there is the need for a peer load >>> report to support load balancing when routing requests to the next hop. >>> >>> The question is whether or not we should also support an "endpoint" >>> load report. This load report would be the load of a server (or a >>> client) and would be carried end-to-end. >>> >>> The case for an endpoint load report can be supported by the >>> following use case. >>> >>> Assume a Diameter network for a Diameter application where the >>> servers are partitioned across the user space. For simplicity, >>> assume that user identities starting with the numbers 0 through 4 are >>> handled by partition 1 and that user identities starting with the >>> numbers 5 through >>> 9 are handled by partition 2. >>> >>> Also assume that each partition has three servers -- P1S1, P1S2 and >>> P1S2 in partition 1 and P2S1, P2S2 AND P2S3 in partition 2. >>> >>> Next assume that there is a database that maps user identities to >>> partitions. This scenario assumes that the database is a standalone >>> device that has some query mechanism for accessing the mapping. >>> Different implementations are possible. The query has the user >>> identity as the key and a set of Diameter servers as the response. >>> This query does NOT return anything but the set of servers able to >>> handle requests for the user id presented. Specifically, the query >>> does not return the load of the servers. >>> >>> Now, assume the following network topology: >>> >>> P1S1 P1S2 P1S3 P2S1 P2S2 P2S3 >>> \ | / \ | / >>> ------- ------- >>> / \ / \ >>> P1A1 P1A2 P2A1 P2A2 >>> | | | | >>> ------------------------------------- >>> | | >>> DB---- AA1 AA2-----DB >>> \ / >>> C >>> >>> The lines are for convenience, they are not meant to imply anything >>> physical, just that AA1 has connections to P1A1, P1A2, P2A1 and P2A2, >>> for instance. >>> >>> AA1 and AA2 are "access agents" and have access to the database that >>> map user identities to sets of servers. >>> >>> The flow of a request would be as follows: >>> >>> 1) C - Does realm routing using received peer load reports to load >>> balance between AA1 and AA2. Assume C routes to AA1. >>> >>> 2) AA1 queries the DB. Assume the user identity starts with the >>> number 1. The DB returns the set of servers including P1S1, P1S2 and P1S3. >>> >>> 3) AA1 then selects the server that is to handle the request from the >>> set of servers returned. AA1 uses endpoint load reports received >>> from P1S1, P1S2 and P1S3 to makes its selection. Assume in this case >>> that >>> AA1 selection P1S2. As a result AA1 inserts the Destination-Host AVP >>> into the request with a value of P1S2. >>> >>> 4) AA1 then determines the route for the request. In this case the >>> route would need to be determines based on the combination of the >>> Destination-Realm, Application-ID and the Destination-Host in the >>> request. The routing tables would indicate that P1A1 and P1A2 are >>> the candidate next hop servers for the request. This requires AA1 to >>> have a route defined for each of the servers. AA1 then uses peer >>> load information received from P1A1 and P1A2 to select the next hop. >>> Assume >>> AA1 selects P1A1. >>> >>> 5) P1A1 determines that the request is targeted for P1S2 based on the >>> Destination-Host AVP. As a result it routes the request directly to >>> P1S2. P1A1 cannot use a peer report to load balance in this case as >>> the request includes the destination in the Destination-Host AVP. >>> >>> The endpoint load report is used in step 3 to select the server that >>> will handle the request. Peer load reports are used to select the >>> next hop. >>> >>> Regards, >>> >>> Steve >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 information 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 delete 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 nobody Tue May 26 10:05:54 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B670E1A8F3B for ; Tue, 26 May 2015 10:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tJkXrAA6NJbc for ; Tue, 26 May 2015 10:05:51 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9B11A1BB1 for ; Tue, 26 May 2015 10:05:51 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:55264 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YxIIR-0008OM-34; Tue, 26 May 2015 10:05:50 -0700 Message-ID: <5564A7E5.4020802@usdonovans.com> Date: Tue, 26 May 2015 12:05:41 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "Wiehe, Ulrich (Nokia - DE/Munich)" , "dime@ietf.org" References: <55427AF7.6090002@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E847@DEMUMBX014.nsn-intra.net> <554A5BA6.8020703@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E970@DEMUMBX014.nsn-intra.net> <31978_1431680512_5555B600_31978_2122_1_6B7134B31289DC4FAF731D844122B36E011EA917@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <31978_1431680512_5555B600_31978_2122_1_6B7134B31289DC4FAF731D844122B36E011EA917@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Dime] Load Use Case justifying endpoint load reports X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 17:05:53 -0000 On 5/15/15 4:01 AM, lionel.morand@orange.com wrote: > Hi Steve, > > The step 4 is simply against the routing rules defined in RFC6733. For example, you can refer to the following statement to understand that using the Destination-Host AVP for routing when the host Id is not part of the peer table is not so "standard": > > Note that an agent can only forward a request to a host described in > the Destination-Host AVP if the host in question is included in its > peer table (see Section 2.6). Otherwise, the request is routed based > on the Destination-Realm only (see Section 6.1.6). SRD> Then I would assert that RFC6733 is on consistent. See my reference below. > > It does not mean that additional routing criteria cannot be used for request routing purposes but there are considered as out of the base protocol and therefore application-specific. > For instance, the Cx interface defined a function performing user id to server id resolution but it is defined as a specific extension of the base protocol and therefore defined as part of a specific diameter application. > > It is not preclude to work on a solution that could be used by application. However, I think that the basic solution defined as part of the standard process should only comply with the base protocol routing principle. Otherwise, there is no way to limit the type of information that could be part of the load information exchanged between Diameter nodes. SRD> I don't understand your point. The proposal is to have the solution support two very specific load reports, one for endpoint load and one for peer load. Each load report would contain very specific information, with the ability to extend the contents as is typical with Diameter solutions. > Obviously, the baseline solution can be defined in a way that it could be possible to extend it for specific purposes. But I am against putting vendor-specific requirements in a solution defined as part of the standard stream (i.e. based on the RFC6733). SRD> This is not a vendor specific requirement or solution. There have been multiple vendors supporting the inclusion of end-point load reports as part of this solution. This is a proposal that addresses real world needs of existing Diameter networks in a way that lets Diameter nodes implemented by multiple vendors interoperate. This is the reason standards exist. > > Regards, > > Lionel > > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (Nokia - DE/Munich) > Envoyé : jeudi 7 mai 2015 08:49 > À : ext Steve Donovan; dime@ietf.org > Objet : Re: [Dime] Load Use Case justifying endpoint load reports > > Hi Steve, > > thank you for the clarification. > As I said, I'm not against. I rather support your proposal. > > Ulrich > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, May 06, 2015 8:21 PM > To: Wiehe, Ulrich (Nokia - DE/Munich); dime@ietf.org > Subject: Re: [Dime] Load Use Case justifying endpoint load reports > > Ulrich, > > Thanks for pointing out the argument against this use case. > > I understand that the default set of information used for request routing is the Destination-Realm and application-id. There is nothing, however, that says this is the only set of information that can be used. In fact, the following from section 6.1.6. in RFC6733 affirms that there are cases when additional information will be used: > > " Realm names and Application Ids are the minimum supported routing > criteria, additional information may be needed to support redirect > semantics." > > The case below suggests the use of Destination-Host. There are scenarios where session-ID, for session based applications, can be used. There is no reason that an agent couldn't use any AVP to make routing decisions. > > In addition, Diameter is being used in ways that were not anticipated by the original authors. That is a good thing. > > I know of many Diameter networks that fit into this use case. We need to take them into account when designing the load mechanism. > > Regards, > > Steve > > On 5/6/15 7:53 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote: >> Hi Steve, >> I'm not against your proposal, however, it has been argued that >> (according to established routing principles) in step 4) >> Destination-Host is not part of the information used to determine the >> route. >> Any reaction to this? >> >> Best regards >> Ulrich >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >> Donovan >> Sent: Thursday, April 30, 2015 8:57 PM >> To: dime@ietf.org >> Subject: [Dime] Load Use Case justifying endpoint load reports >> >> All, >> >> There has been some offline discussion about whether or not the >> Diameter Load mechanism should include two types of Load reports. I >> believe there is consensus that there is the need for a peer load >> report to support load balancing when routing requests to the next hop. >> >> The question is whether or not we should also support an "endpoint" >> load report. This load report would be the load of a server (or a >> client) and would be carried end-to-end. >> >> The case for an endpoint load report can be supported by the following >> use case. >> >> Assume a Diameter network for a Diameter application where the servers >> are partitioned across the user space. For simplicity, assume that >> user identities starting with the numbers 0 through 4 are handled by >> partition 1 and that user identities starting with the numbers 5 >> through >> 9 are handled by partition 2. >> >> Also assume that each partition has three servers -- P1S1, P1S2 and >> P1S2 in partition 1 and P2S1, P2S2 AND P2S3 in partition 2. >> >> Next assume that there is a database that maps user identities to >> partitions. This scenario assumes that the database is a standalone >> device that has some query mechanism for accessing the mapping. >> Different implementations are possible. The query has the user >> identity as the key and a set of Diameter servers as the response. >> This query does NOT return anything but the set of servers able to >> handle requests for the user id presented. Specifically, the query >> does not return the load of the servers. >> >> Now, assume the following network topology: >> >> P1S1 P1S2 P1S3 P2S1 P2S2 P2S3 >> \ | / \ | / >> ------- ------- >> / \ / \ >> P1A1 P1A2 P2A1 P2A2 >> | | | | >> ------------------------------------- >> | | >> DB---- AA1 AA2-----DB >> \ / >> C >> >> The lines are for convenience, they are not meant to imply anything >> physical, just that AA1 has connections to P1A1, P1A2, P2A1 and P2A2, >> for instance. >> >> AA1 and AA2 are "access agents" and have access to the database that >> map user identities to sets of servers. >> >> The flow of a request would be as follows: >> >> 1) C - Does realm routing using received peer load reports to load >> balance between AA1 and AA2. Assume C routes to AA1. >> >> 2) AA1 queries the DB. Assume the user identity starts with the >> number 1. The DB returns the set of servers including P1S1, P1S2 and P1S3. >> >> 3) AA1 then selects the server that is to handle the request from the >> set of servers returned. AA1 uses endpoint load reports received from >> P1S1, P1S2 and P1S3 to makes its selection. Assume in this case that >> AA1 selection P1S2. As a result AA1 inserts the Destination-Host AVP >> into the request with a value of P1S2. >> >> 4) AA1 then determines the route for the request. In this case the >> route would need to be determines based on the combination of the >> Destination-Realm, Application-ID and the Destination-Host in the >> request. The routing tables would indicate that P1A1 and P1A2 are the >> candidate next hop servers for the request. This requires AA1 to have >> a route defined for each of the servers. AA1 then uses peer load >> information received from P1A1 and P1A2 to select the next hop. >> Assume >> AA1 selects P1A1. >> >> 5) P1A1 determines that the request is targeted for P1S2 based on the >> Destination-Host AVP. As a result it routes the request directly to >> P1S2. P1A1 cannot use a peer report to load balance in this case as >> the request includes the destination in the Destination-Host AVP. >> >> The endpoint load report is used in step 3 to select the server that >> will handle the request. Peer load reports are used to select the >> next hop. >> >> Regards, >> >> Steve >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 information 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 delete 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 nobody Tue May 26 15:28:32 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C021A9024 for ; Tue, 26 May 2015 15:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4uySeYi3xeX for ; Tue, 26 May 2015 15:28:29 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60CF71B3279 for ; Tue, 26 May 2015 15:28:20 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 383f4655.0.4948745.00-2259.13299084.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 26 May 2015 22:28:20 +0000 (UTC) X-MXL-Hash: 5564f38450fe3158-b3c32fc3b6c5ab49cd84b03fe39034edba20baa8 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4QMSJcA009475; Tue, 26 May 2015 18:28:19 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4QMSAlf009399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 May 2015 18:28:14 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 26 May 2015 22:27:58 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.183]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0224.002; Tue, 26 May 2015 18:27:57 -0400 From: "DOLLY, MARTIN C" To: Steve Donovan , "lionel.morand@orange.com" , "Wiehe, Ulrich (Nokia - DE/Munich)" , "dime@ietf.org" Thread-Topic: [Dime] Load Use Case justifying endpoint load reports Thread-Index: AQHQl9Yxs9MxCc2c3E2GLCZYutSPIZ2Ozk/Q Date: Tue, 26 May 2015 22:27:57 +0000 Message-ID: References: <55427AF7.6090002@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E847@DEMUMBX014.nsn-intra.net> <554A5BA6.8020703@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006682288E970@DEMUMBX014.nsn-intra.net> <31978_1431680512_5555B600_31978_2122_1_6B7134B31289DC4FAF731D844122B36E011EA917@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5564A7E5.4020802@usdonovans.com> In-Reply-To: <5564A7E5.4020802@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.161.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=b/AFFK6x c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=34ieAM8GreUA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=h1PgugrvaO0A:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=z9tbli-vAAAA:8 a=yakATiurAAAA:8 a=wB5peYzf4zWn3uxI] X-AnalysisOut: [Ac0A:9 a=wPNLvfGTeEIA:10 a=4vApVfVdRh4YkQVw:21 a=xCkuJyx3k] X-AnalysisOut: [oItPjI3:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: Re: [Dime] Load Use Case justifying endpoint load reports X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 22:28:32 -0000 We support what Steve's proposal. Lionel, what is the "real" issue? -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Tuesday, May 26, 2015 1:06 PM To: lionel.morand@orange.com; Wiehe, Ulrich (Nokia - DE/Munich); dime@ietf.= org Subject: Re: [Dime] Load Use Case justifying endpoint load reports On 5/15/15 4:01 AM, lionel.morand@orange.com wrote: > Hi Steve, > > The step 4 is simply against the routing rules defined in RFC6733. For ex= ample, you can refer to the following statement to understand that using th= e Destination-Host AVP for routing when the host Id is not part of the peer= table is not so "standard": > > Note that an agent can only forward a request to a host described in > the Destination-Host AVP if the host in question is included in its > peer table (see Section 2.6). Otherwise, the request is routed based > on the Destination-Realm only (see Section 6.1.6). SRD> Then I would assert that RFC6733 is on consistent. See my reference below. > > It does not mean that additional routing criteria cannot be used for requ= est routing purposes but there are considered as out of the base protocol a= nd therefore application-specific. > For instance, the Cx interface defined a function performing user id to s= erver id resolution but it is defined as a specific extension of the base p= rotocol and therefore defined as part of a specific diameter application. > > It is not preclude to work on a solution that could be used by applicatio= n. However, I think that the basic solution defined as part of the standard= process should only comply with the base protocol routing principle. Other= wise, there is no way to limit the type of information that could be part o= f the load information exchanged between Diameter nodes. SRD> I don't understand your point. The proposal is to have the solution support two very specific load reports, one for endpoint load and = one for peer load. Each load report would contain very specific informatio= n, with the ability to extend the contents as is typical with Diameter solu= tions. > Obviously, the baseline solution can be defined in a way that it could be= possible to extend it for specific purposes. But I am against putting vend= or-specific requirements in a solution defined as part of the standard stre= am (i.e. based on the RFC6733). SRD> This is not a vendor specific requirement or solution. There have been multiple vendors supporting the inclusion of end-point load reports as= part of this solution. This is a proposal that addresses real world needs= of existing Diameter networks in a way that lets Diameter nodes implemente= d by multiple vendors interoperate. This is the reason standards exist. > > Regards, > > Lionel > > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (Nokia - DE/Munich) Envoy=E9 : jeudi 7 mai 2015 08:49 =C0 : ext Steve=20 > Donovan; dime@ietf.org Objet : Re: [Dime] Load Use Case justifying=20 > endpoint load reports > > Hi Steve, > > thank you for the clarification. > As I said, I'm not against. I rather support your proposal. > > Ulrich > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, May 06, 2015 8:21 PM > To: Wiehe, Ulrich (Nokia - DE/Munich); dime@ietf.org > Subject: Re: [Dime] Load Use Case justifying endpoint load reports > > Ulrich, > > Thanks for pointing out the argument against this use case. > > I understand that the default set of information used for request routing= is the Destination-Realm and application-id. There is nothing, however, t= hat says this is the only set of information that can be used. In fact, th= e following from section 6.1.6. in RFC6733 affirms that there are cases whe= n additional information will be used: > > " Realm names and Application Ids are the minimum supported routing > criteria, additional information may be needed to support redirect > semantics." > > The case below suggests the use of Destination-Host. There are scenarios= where session-ID, for session based applications, can be used. There is n= o reason that an agent couldn't use any AVP to make routing decisions. > > In addition, Diameter is being used in ways that were not anticipated by = the original authors. That is a good thing. > > I know of many Diameter networks that fit into this use case. We need to= take them into account when designing the load mechanism. > > Regards, > > Steve > > On 5/6/15 7:53 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote: >> Hi Steve, >> I'm not against your proposal, however, it has been argued that=20 >> (according to established routing principles) in step 4)=20 >> Destination-Host is not part of the information used to determine the=20 >> route. >> Any reaction to this? >> >> Best regards >> Ulrich >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 >> Donovan >> Sent: Thursday, April 30, 2015 8:57 PM >> To: dime@ietf.org >> Subject: [Dime] Load Use Case justifying endpoint load reports >> >> All, >> >> There has been some offline discussion about whether or not the=20 >> Diameter Load mechanism should include two types of Load reports. I=20 >> believe there is consensus that there is the need for a peer load=20 >> report to support load balancing when routing requests to the next hop. >> >> The question is whether or not we should also support an "endpoint" >> load report. This load report would be the load of a server (or a >> client) and would be carried end-to-end. >> >> The case for an endpoint load report can be supported by the=20 >> following use case. >> >> Assume a Diameter network for a Diameter application where the=20 >> servers are partitioned across the user space. For simplicity,=20 >> assume that user identities starting with the numbers 0 through 4 are=20 >> handled by partition 1 and that user identities starting with the=20 >> numbers 5 through >> 9 are handled by partition 2. >> >> Also assume that each partition has three servers -- P1S1, P1S2 and >> P1S2 in partition 1 and P2S1, P2S2 AND P2S3 in partition 2. >> >> Next assume that there is a database that maps user identities to=20 >> partitions. This scenario assumes that the database is a standalone=20 >> device that has some query mechanism for accessing the mapping. >> Different implementations are possible. The query has the user=20 >> identity as the key and a set of Diameter servers as the response. >> This query does NOT return anything but the set of servers able to=20 >> handle requests for the user id presented. Specifically, the query=20 >> does not return the load of the servers. >> >> Now, assume the following network topology: >> >> P1S1 P1S2 P1S3 P2S1 P2S2 P2S3 >> \ | / \ | / >> ------- ------- >> / \ / \ >> P1A1 P1A2 P2A1 P2A2 >> | | | | >> ------------------------------------- >> | | >> DB---- AA1 AA2-----DB >> \ / >> C >> >> The lines are for convenience, they are not meant to imply anything=20 >> physical, just that AA1 has connections to P1A1, P1A2, P2A1 and P2A2,=20 >> for instance. >> >> AA1 and AA2 are "access agents" and have access to the database that=20 >> map user identities to sets of servers. >> >> The flow of a request would be as follows: >> >> 1) C - Does realm routing using received peer load reports to load=20 >> balance between AA1 and AA2. Assume C routes to AA1. >> >> 2) AA1 queries the DB. Assume the user identity starts with the=20 >> number 1. The DB returns the set of servers including P1S1, P1S2 and P1= S3. >> >> 3) AA1 then selects the server that is to handle the request from the=20 >> set of servers returned. AA1 uses endpoint load reports received=20 >> from P1S1, P1S2 and P1S3 to makes its selection. Assume in this case=20 >> that >> AA1 selection P1S2. As a result AA1 inserts the Destination-Host AVP=20 >> into the request with a value of P1S2. >> >> 4) AA1 then determines the route for the request. In this case the=20 >> route would need to be determines based on the combination of the=20 >> Destination-Realm, Application-ID and the Destination-Host in the=20 >> request. The routing tables would indicate that P1A1 and P1A2 are=20 >> the candidate next hop servers for the request. This requires AA1 to=20 >> have a route defined for each of the servers. AA1 then uses peer=20 >> load information received from P1A1 and P1A2 to select the next hop. >> Assume >> AA1 selects P1A1. >> >> 5) P1A1 determines that the request is targeted for P1S2 based on the=20 >> Destination-Host AVP. As a result it routes the request directly to=20 >> P1S2. P1A1 cannot use a peer report to load balance in this case as=20 >> the request includes the destination in the Destination-Host AVP. >> >> The endpoint load report is used in step 3 to select the server that=20 >> will handle the request. Peer load reports are used to select the=20 >> next hop. >> >> Regards, >> >> Steve >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue May 26 16:49:45 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA631A1BFA for ; Tue, 26 May 2015 16:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, 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 Y9CvGV5M9-dq for ; Tue, 26 May 2015 16:49:42 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605A61A1BEF for ; Tue, 26 May 2015 16:49:42 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t4QNndoB001937 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 May 2015 23:49:40 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t4QNndSh003644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 27 May 2015 01:49:39 +0200 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 27 May 2015 01:49:39 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.187]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0235.001; Wed, 27 May 2015 01:49:38 +0200 From: "Wiehe, Ulrich (Nokia - DE/Munich)" To: "dime@ietf.org" Thread-Topic: draft-ietf-dime-ovli-08 Thread-Index: AdCS/04/LnvBNll7TbWAQdOnvL3vRwEzamIAABAz8NAAAA9T4A== Date: Tue, 26 May 2015 23:49:38 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006682289733D@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2142 X-purgate-ID: 151667::1432684180-00004750-A2EA62D8/0/0 Archived-At: Subject: [Dime] FW: draft-ietf-dime-ovli-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 23:49:44 -0000 Dear all, please see below. Is there any objection to allow reporting nodes (while in overload) to unco= nditionally include OC specific AVPs with M-bit cleared to answer messages = even when the corresponding request did not indicate support of DOIC? Best regards Ulrich -----Original Message----- From: Wiehe, Ulrich (Nokia - DE/Munich)=20 Sent: Wednesday, May 27, 2015 1:45 AM To: 'ext Steve Donovan' Subject: RE: draft-ietf-dime-ovli-08 Thank you Steve, I shall forward the question to the DIME list to see whether there are obje= ctions. Regards Ulrich -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Tuesday, May 26, 2015 8:00 PM To: Wiehe, Ulrich (Nokia - DE/Munich) Subject: Re: draft-ietf-dime-ovli-08 Ulrich, If I remember correctly the MUST NOT was inserted based on your input. =20 I think it was related to constraining the number of OC-S-F AVPs=20 received by reacting nodes. I don't have any objection to changing it if the rest of the DIME list=20 agrees. Steve On 5/20/15 8:17 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote: > Hi Steve, > > > draft-ietf-dime-ovli-08.txt says in clause 5.1.2: > > A reporting node MUST NOT include the OC-Supported-Features AVP, OC- > OLR AVP or any other overload control AVPs defined in extension > drafts in response messages for transactions where the request > message does not include the OC-Supported-Features AVP. > > This requirement seems to be too strict. > Would it not be enough to demand not including OC-specific AVPs with M-bi= t set and allow including OC-specific AVPs with M-bit cleared? > > The reporting node, when in overload, may want to check only application = ID and Command Code before deciding that a negative response is returned. I= n this case parsing the complete message to detect presence of the OC-Suppo= rted-Features AVP unnecessarily consumes resources and an unconditional inc= lusion of OC-OLR and OC-Supported-Features AVPs with M-bit cleared may be a= cceptable. > > What do you think? > > Regards > Ulrich >