From nobody Wed Apr 3 10:38:07 2019 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A7D120150 for ; Wed, 3 Apr 2019 10:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 G_nULxh2B-ND for ; Wed, 3 Apr 2019 10:38:03 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40102.outbound.protection.outlook.com [40.107.4.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94870120143 for ; Wed, 3 Apr 2019 10:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P9DvMQyrjEzAi9spbN238b1kXV9zt/agcMNwAJs2nYM=; b=Sp4ucjXRBJriVQNLsv2OyQddM7RN+FfRbs6Gpcn3GORPxWPvmSSn8hplaN5cQ8zZqZvmJTyC/RO1Jau2zWr+Q1aYBd45yuso0AAexjaH7mbBIxpLpHx5w9rM/qQsmx3Z1QlF8nauN2LvLva93NgNSW5LmlTAHUYcSkGZPR5sPJQ= Received: from AM6PR07MB5493.eurprd07.prod.outlook.com (20.178.89.86) by AM6PR07MB5462.eurprd07.prod.outlook.com (20.178.88.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Wed, 3 Apr 2019 17:37:58 +0000 Received: from AM6PR07MB5493.eurprd07.prod.outlook.com ([fe80::21b1:c7ad:ab85:b8a5]) by AM6PR07MB5493.eurprd07.prod.outlook.com ([fe80::21b1:c7ad:ab85:b8a5%3]) with mapi id 15.20.1771.006; Wed, 3 Apr 2019 17:37:58 +0000 From: "Poscic, Kristian (Nokia - US/Mountain View)" To: "dime@ietf.org" Thread-Topic: clearing of the Destination-Host AVP in the retransmitted request Thread-Index: AdTmh7TwzN1E6HnzRjKZFmd70UeSTADu888w Date: Wed, 3 Apr 2019 17:37:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kristian.poscic@nokia.com; x-originating-ip: [135.245.20.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b37a354c-9240-4ce8-f14e-08d6b85b1d14 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR07MB5462; x-ms-traffictypediagnostic: AM6PR07MB5462: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(366004)(136003)(39860400002)(189003)(199004)(478600001)(6246003)(7736002)(53936002)(9686003)(6306002)(74316002)(6506007)(55016002)(236005)(54896002)(5640700003)(14454004)(186003)(26005)(71200400001)(71190400001)(102836004)(76176011)(52536014)(476003)(2906002)(86362001)(11346002)(6916009)(446003)(486006)(81166006)(81156014)(1730700003)(8936002)(8676002)(68736007)(105586002)(25786009)(5660300002)(229853002)(2351001)(106356001)(99286004)(7696005)(6436002)(316002)(53546011)(97736004)(33656002)(14444005)(256004)(4743002)(66066001)(2501003)(3846002)(6116002)(790700001)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5462; H:AM6PR07MB5493.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 59NJoKdfcJKcw0VhBTUthYh8QK6mLj4tFcmmLFqzzFr5UYQdMjAMR0jgFZSnhLFvHLzA2IiLbmXJjjWOqrURmLUCJPeJ8Z+8m0KcfodykkM+c4OyXfJgRSuaYYKIi9O4wmrAnKap2iWMRyPn70pvQMi8Nh3NyP02blNXiF9uVIzcQZbWViMVd9Zw0a4fM8TrA53zvmAWSJrq3P53p8O+yTNbGNaHaw6CUjI40/4mJbyHOmUFfu9QmN+LYo1YkFljIsu/U2wejQp0/hIycYeFNBKfleEM7/m+KC19ANaxQTxQEocr+XCZuBd5mCBxQaNEAPuQk/QVX1xv5VEOJquYulVCkPLR11nKMMBu2UH3435nhBSBKC4DYioDqKbZ9Dm20fBpuU5z4+RnyCmrytbjEbzK11vWbLmsf882Z2JGRrE= Content-Type: multipart/alternative; boundary="_000_AM6PR07MB5493F12A2AE745CA60268D8DED570AM6PR07MB5493eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: b37a354c-9240-4ce8-f14e-08d6b85b1d14 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 17:37:58.8419 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5462 Archived-At: Subject: Re: [Dime] clearing of the Destination-Host AVP in the retransmitted request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 17:38:05 -0000 --_000_AM6PR07MB5493F12A2AE745CA60268D8DED570AM6PR07MB5493eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok, I'll take it that crickets on this thread are related to the following = text in section 5.2 of RFC 7068. The issues with error responses described in [RFC6733] extend beyond the particular issues for overload control and have been addressed in an ad hoc fashion by various implementations. Addressing these in a standard way would be a useful exercise, but it is beyond the scope of this document. From: Poscic, Kristian (Nokia - US/Mountain View) Sent: Saturday, March 30, 2019 7:55 AM To: dime@ietf.org Subject: clearing of the Destination-Host AVP in the retransmitted request Can someone clarify in which case should a Diameter client (DC) clear the D= estination-Host AVP in the *retransmitted* request message: 1) When the peer failover occurs - say the connection to node 1 fails = and DC retransmit the request in the pending queue to node 2? Section 5.5.= 4 in RFC 6733 is not specific about this, and it may even imply that the de= stination-host should not be cleared. Even though the clearing it may be be= neficial. 2) When the client receives Diameter_Unable_to_Deliver (with E-bit set= ) error message, which indicates that the node to which the request is sent= is unable to deliver the message to the destination-host (or realm). In th= is case it would be beneficial to blacklist this peer for this particular D= iameter session. The application (Gx/Gy/NASREQ) could then retransmit, but = it clearly does not make sense for Diam Base to send the message to the sam= e peer. Should the destination-host be cleared in this retransmit? Some of = this is mentioned in RFC 4006, sec 6.5, but again, it is not clear. I assume that when the original request message times out (due to no answer= received) and it is retransmitted after Tx timer expires, the destination-= host is not cleared in the retransmit. Also, should the CC-Req-Num be the same on retransmit, or should the client= use a new one? +---------+ |Diameter | +---------------------| | +---------+ | | Node 1 | |Diameter |--+ +---------+ | | | Client |--+ +---------+ +---------+ | |Diameter | +---------------------| | | Node 2 | +---------+ Note: Diameter Node 1 and Node 2 could be relay agents OR the home servers = (say redundant PCRFs, each with it's own unique peer name). I assume that DC should not make a decision on how to react based on the kn= owledge whether it has peering connection with the RA or the server. This is in the context on plain Base, without any overload functionality (o= verload reports). Thanks, Kris --_000_AM6PR07MB5493F12A2AE745CA60268D8DED570AM6PR07MB5493eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok, I’ll take it that crickets on this thread = are related to the following text in section 5.2 of RFC 7068.

 

The issues with error responses described =
in [RFC6733] extend beyond
   the particular issues for ove=
rload control and have been addressed in
   an ad hoc fashion by various =
implementations.  Addressing these in a
   standard way would be a usefu=
l exercise, but it is beyond the scope
   of this document.<=
/span>

 

 

From: Poscic, Kris= tian (Nokia - US/Mountain View)
Sent: Saturday, March 30, 2019 7:55 AM
To: dime@ietf.org
Subject: clearing of the Destination-Host AVP in the retransmitted r= equest

 

Can someone clarify in wh= ich case should a Diameter client (DC) clear the Destination-Host AVP in th= e *retransmitted* request message:

 

1)      When the peer failover occurs - say the connection = to node 1 fails  and DC retransmit the request in the pending queue to= node 2? Section 5.5.4 in RFC 6733 is not specific about this, and it may e= ven imply that the destination-host should not be cleared. Even though the clearing it may be beneficial.<= /p>

 =

2)      When the client receives Diameter_Unable_to_Deliver= (with E-bit set) error message, which indicates that the node to which the= request is sent is unable to deliver the message to the destination-host (= or realm). In this case it would be beneficial to blacklist this peer for this particular Diameter session.= The application (Gx/Gy/NASREQ) could then retransmit, but it clearly does = not make sense for Diam Base to send the message to the same peer. Should t= he destination-host be cleared in this retransmit? Some of this is mentioned in RFC 4006, sec 6.5, but again= , it is not clear.

 =

I assume that when the or= iginal request message times out (due to no answer received) and it is retr= ansmitted after Tx timer expires, the destination-host is not cleared in th= e retransmit.   

 

Also, should the CC-Req-N= um be the same on retransmit, or should the client use a new one?

 

        =             &nb= sp;            =            +---------= +

        =             &nb= sp;            =            |Diameter= |

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

        =  +---------+  |       =              &n= bsp;| Node 1  |    

        =  |Diameter |--+        &nb= sp;            += ---------+   

        =  |         |   =             &nb= sp;            =           

        =  | Client  |--+       &nbs= p;             = +---------+  

        =  +---------+  |       =             &nb= sp; |Diameter |   

        =             &nb= sp; +---------------------|      &nb= sp;  |          &nbs= p;

        =             &nb= sp;            =            | Node 2&= nbsp; |

        =             &nb= sp;            =            +---------= +

 

 

Note: Diameter Node 1 and= Node 2 could be relay agents OR the home servers (say redundant PCRFs, eac= h with it’s own unique peer name).

I assume that DC should n= ot make a decision on how to react based on the knowledge whether it has pe= ering connection with the RA or the server.

 

This is in the context on= plain Base, without any overload functionality (overload reports).

Thanks,

Kris

--_000_AM6PR07MB5493F12A2AE745CA60268D8DED570AM6PR07MB5493eurp_-- From nobody Wed Apr 3 11:24:44 2019 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2102112010C for ; Wed, 3 Apr 2019 11:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=f5.com 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 TRhs2C0jEA1N for ; Wed, 3 Apr 2019 11:24:39 -0700 (PDT) Received: from mail15.f5.com (mail15.f5.com [104.219.107.14]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B96012006B for ; Wed, 3 Apr 2019 11:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=f5; t=1554315879; x=1585851879; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=7h60qAcCpbSqBgNMrMaPX+IxisLAKIDJXJcCawFMGak=; b=PV+F4qm0QjSHSG86nTqH5TGDmIgr3OrUnKNwa4VRwjLSKbaknq5mdna1 YL0FRbeHTQwsxARzIxojj/E30N+6YcBUGe96hVz8xAtpADENE2H4S18Zr DoLCZG85sRAXyhdRhjjKWqbUQxpptMzwSME9VjluA7o5oJiGNf0ewVaUD o+U7RbhLPqxnUo/2Z5elnYnpX4/L8/zodeA1BjGsqDq6ZA7sv2LmpRNFd qMN3luH5GClGVTYUX95nEpkumaCmFEoZyOA6eEqjFw8jyzetctaB6HFU3 /EKBJV4SlOzjakkgvj2xUTS1pAg/IbWtH7vQGMbgVH6EwfW3U+MHJwty1 A==; X-IronPort-AV: E=McAfee;i="5900,7806,9216"; a="72819220" X-IronPort-AV: E=Sophos;i="5.60,305,1549958400"; d="scan'208";a="72819220" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from seadev21.olympus.f5net.com ([192.168.180.71]) by mail.f5net.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Apr 2019 11:24:39 -0700 Received: from seadev21.olympus.f5net.com (localhost [127.0.0.1]) by seadev21.olympus.f5net.com (8.14.4/8.12.11) with ESMTP id x33IOcIT038868; Wed, 3 Apr 2019 11:24:38 -0700 Received: (from aesmith@localhost) by seadev21.olympus.f5net.com (8.14.4/8.14.4/Submit) id x33IOcsn038791; Wed, 3 Apr 2019 11:24:38 -0700 X-Authentication-Warning: seadev21.olympus.f5net.com: aesmith set sender to AE.Smith@f5.com using -f Date: Wed, 3 Apr 2019 11:24:33 -0700 From: =?iso-8859-1?Q?=C6strid?= Smith To: "Poscic, Kristian (Nokia - US/Mountain View)" Cc: "dime@ietf.org" Message-ID: <20190403182433.GY11770@seadev21.f5.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Dime] clearing of the Destination-Host AVP in the retransmitted request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 18:24:41 -0000 Hi Kris, Your second scenario, an Unable_To_Deliver reply, can be generated on predictive loop avoidance (6733 section 6.1.7) also. Blacklisting the peer for that destination-host is a good choice in that scenario. But I wouldn't think that clearing the destination-host is necessary, because if the message could be retransmitted on a different path it may eventually succeed. If you're out of paths, though, as an ultimate fallback that seems reasonable. But then, I work almost exclusively with the base protocol in context of a relay agent :) We don't touch the destination-host on any message, unless configured otherwise. From my reading of rfc6733 section 6.1, there isn't much latitude to include or omit a destination-host on any particular message. -- ęstrid smith ------------------- --<[ c y b e r | s o f t w a r e | e n g i n e e r ]>-- ------------ ------------------ On Sat, Mar 30, 2019 at 12:55:00PM +0000, Poscic, Kristian wrote: > EXTERNAL MAIL: dime-bounces@ietf.org > > Can someone clarify in which case should a Diameter client (DC) > clear the Destination-Host AVP in the *retransmitted* request > message: > > 1. When the peer failover occurs - say the connection to node 1 > fails and DC retransmit the request in the pending queue to node > 2? Section 5.5.4 in RFC 6733 is not specific about this, and it > may even imply that the destination-host should not be > cleared. Even though the clearing it may be beneficial. > > 1. When the client receives Diameter_Unable_to_Deliver (with E-bit > set) error message, which indicates that the node to which the > request is sent is unable to deliver the message to the > destination-host (or realm). In this case it would be beneficial > to blacklist this peer for this particular Diameter session. The > application (Gx/Gy/NASREQ) could then retransmit, but it clearly > does not make sense for Diam Base to send the message to the same > peer. Should the destination-host be cleared in this retransmit? > Some of this is mentioned in RFC 4006, sec 6.5, but again, it is > not clear. > > I assume that when the original request message times out (due to no > answer received) and it is retransmitted after Tx timer expires, the > destination-host is not cleared in the retransmit. > > Also, should the CC-Req-Num be the same on retransmit, or should the > client use a new one? > > +---------+ > |Diameter | > +---------------------| | > +---------+ | | Node 1 | > |Diameter |--+ +---------+ > | | > | Client |--+ +---------+ > +---------+ | |Diameter | > +---------------------| | > | Node 2 | > +---------+ > > Note: Diameter Node 1 and Node 2 could be relay agents OR the home > servers (say redundant PCRFs, each with it's own unique peer name). > I assume that DC should not make a decision on how to react based on > the knowledge whether it has peering connection with the RA or the > server. > > This is in the context on plain Base, without any overload > functionality (overload reports). > > Thanks, > Kris > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Apr 3 11:53:00 2019 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3661B120166 for ; Wed, 3 Apr 2019 11:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 C2QzC-2o0rLW for ; Wed, 3 Apr 2019 11:52:55 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60139.outbound.protection.outlook.com [40.107.6.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B8412013F for ; Wed, 3 Apr 2019 11:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sfF0TCydB/T1rxILhxuvvqdJj6uVzogGQ/jYjxJejCw=; b=CNhgB7X2jYZtahoOkGksuyIO1UhfKOdVnGcP1a0ToJL1C4G2Vnj9xuDV+h57pA0Sb6XGJYsx+hkcHLcXtzr2/bSzab0EsLO1OVlNOPeGMwxNqTcIcQbUwUq1GuG9RFeQkgeDbMPySp68sMmmqwcl2mopFp9cdNcK3bjI+XbJ3SQ= Received: from AM0PR07MB5490.eurprd07.prod.outlook.com (20.178.23.91) by AM0PR07MB6065.eurprd07.prod.outlook.com (20.178.113.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.9; Wed, 3 Apr 2019 18:52:52 +0000 Received: from AM0PR07MB5490.eurprd07.prod.outlook.com ([fe80::6ce1:d83d:e1b2:da05]) by AM0PR07MB5490.eurprd07.prod.outlook.com ([fe80::6ce1:d83d:e1b2:da05%7]) with mapi id 15.20.1771.011; Wed, 3 Apr 2019 18:52:52 +0000 From: "Poscic, Kristian (Nokia - US/Mountain View)" To: =?iso-8859-1?Q?=C6strid_Smith?= CC: "dime@ietf.org" Thread-Topic: [Dime] clearing of the Destination-Host AVP in the retransmitted request Thread-Index: AdTmh7TwzN1E6HnzRjKZFmd70UeSTADwscaAAABa1eA= Date: Wed, 3 Apr 2019 18:52:52 +0000 Message-ID: References: <20190403182433.GY11770@seadev21.f5.com> In-Reply-To: <20190403182433.GY11770@seadev21.f5.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kristian.poscic@nokia.com; x-originating-ip: [135.245.20.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: be2034ba-9bb8-450e-89d3-08d6b865938e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM0PR07MB6065; x-ms-traffictypediagnostic: AM0PR07MB6065: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(366004)(136003)(396003)(13464003)(199004)(189003)(446003)(6306002)(105586002)(106356001)(966005)(486006)(76176011)(97736004)(6916009)(229853002)(316002)(8936002)(5660300002)(4326008)(6436002)(52536014)(25786009)(86362001)(6246003)(53936002)(7736002)(66066001)(7696005)(476003)(99286004)(55016002)(74316002)(71190400001)(478600001)(9686003)(71200400001)(14454004)(3846002)(6116002)(256004)(2906002)(81156014)(81166006)(33656002)(53546011)(8676002)(6506007)(102836004)(26005)(186003)(11346002)(305945005)(14444005)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB6065; H:AM0PR07MB5490.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: XHbgyyRK+NuENu8nn7EoH/s3bD6D0xajclJoXM/QrG3AUTBeT/BiV+701SYYaJKPLTuzDFXq+gyWgrQ8YAhMWzkT83FZP3brGeJ89J3mdcYvpcuOEXNaO9/IO+7vtbpK6//68KQ9bqlFS3LiSCpv/YPCXuX5qoUGu93W/HgOPOm7LBlOVfnRfaZzmsqD8lbzpNdi1QQ9xnXh6lg6ZX0+arySFiLf5M0lLxmRf3qsjTz68NCRSnRq2gUqTFxTqE26sVl3SjXqrWuBvuDeD0kINo36IG6Id6dxr2tEUtwAcCw9pRwrPSq+Sgg5ozT5bFXAnAJTavuwrANio48LIAV5/lA9OKQ3hTWloB4R6qQ9D1AWYyaJwTVL9MO5AZnh1yIBER9g2Yh5yQ9kdhRDdAwtd8HEXNtIwoHmFYeT3CGjKU0= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: be2034ba-9bb8-450e-89d3-08d6b865938e X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 18:52:52.5414 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6065 Archived-At: Subject: Re: [Dime] clearing of the Destination-Host AVP in the retransmitted request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 18:52:58 -0000 Thanks Astrid (sorry for butchering the spelling of your name but I don't h= ave an 'ae' character on my keyboard).=20 On receipt of UNABLE_TO_DELIVER, diameter client would still retransmit on= a different next-hop peer (if available), just that the dest-host is remov= ed so that the peer can make the decision where to deliver this message (ba= sed on the realm routing). The assumption is that the servers (for example PCRFs) are all synchronized= (georedundancy), and then any can respond for the session in the retransmi= tted request.=20 If the application servers are not synched, then this would be a problem in= deed. But then, the problem would be if we leave the dest-host intact in th= e retransmit while the dest-host is truly down. RFC 4006 6.5 allows for backup destinations. There, it is alluded that the= client may have two destination hosts configured, and use one until 3002 i= s received. When 3002 is received (and some other config conditions are met= ), the second dest-host can be used.=20 What I'm saying is that one can just remove the dest-host from the retransm= it and the message will be naturally delivered via realm routing to some de= st host (assuming georedundancy is supported). It looks like that if vendors implement one behavior for this, it will addr= ess some scenarios, but it will break some other. Really no uniform solutio= n. =20 Kris -----Original Message----- From: =C6strid Smith =20 Sent: Wednesday, April 3, 2019 1:25 PM To: Poscic, Kristian (Nokia - US/Mountain View) Cc: dime@ietf.org Subject: Re: [Dime] clearing of the Destination-Host AVP in the retransmitt= ed request Hi Kris, Your second scenario, an Unable_To_Deliver reply, can be generated on predi= ctive loop avoidance (6733 section 6.1.7) also. Blacklisting the peer for = that destination-host is a good choice in that scenario. But I wouldn't th= ink that clearing the destination-host is necessary, because if the message= could be retransmitted on a different path it may eventually succeed. If you're out of paths, though, as an ultimate fallback that seems reasonab= le. But then, I work almost exclusively with the base protocol in context of a = relay agent :) We don't touch the destination-host on any message, unless c= onfigured otherwise. From my reading of rfc6733 section 6.1, there isn't m= uch latitude to include or omit a destination-host on any particular messag= e. --=20 =E6strid smith ------------------- --<[ c y b e r | s o f t w a r e | e n g i n e e r ]>-- ------------ ------------------ On Sat, Mar 30, 2019 at 12:55:00PM +0000, Poscic, Kristian wrote: > EXTERNAL MAIL: dime-bounces@ietf.org >=20 > Can someone clarify in which case should a Diameter client (DC) clear=20 > the Destination-Host AVP in the *retransmitted* request > message: >=20 > 1. When the peer failover occurs - say the connection to node 1 > fails and DC retransmit the request in the pending queue to node > 2? Section 5.5.4 in RFC 6733 is not specific about this, and it > may even imply that the destination-host should not be > cleared. Even though the clearing it may be beneficial. >=20 > 1. When the client receives Diameter_Unable_to_Deliver (with E-bit > set) error message, which indicates that the node to which the > request is sent is unable to deliver the message to the > destination-host (or realm). In this case it would be beneficial > to blacklist this peer for this particular Diameter session. The > application (Gx/Gy/NASREQ) could then retransmit, but it clearly > does not make sense for Diam Base to send the message to the same > peer. Should the destination-host be cleared in this retransmit? > Some of this is mentioned in RFC 4006, sec 6.5, but again, it is > not clear. >=20 > I assume that when the original request message times out (due to no=20 > answer received) and it is retransmitted after Tx timer expires, the=20 > destination-host is not cleared in the retransmit. >=20 > Also, should the CC-Req-Num be the same on retransmit, or should the=20 > client use a new one? >=20 > +---------+ > |Diameter | > +---------------------| | > +---------+ | | Node 1 | > |Diameter |--+ +---------+ > | | > | Client |--+ +---------+ > +---------+ | |Diameter | > +---------------------| | > | Node 2 | > +---------+ >=20 > Note: Diameter Node 1 and Node 2 could be relay agents OR the home=20 > servers (say redundant PCRFs, each with it's own unique peer name). > I assume that DC should not make a decision on how to react based on=20 > the knowledge whether it has peering connection with the RA or the=20 > server. >=20 > This is in the context on plain Base, without any overload=20 > functionality (overload reports). > > Thanks, > Kris > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime