From dime-bounces@ietf.org Tue Apr 04 17:19:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsvh-0005MZ-4e; Tue, 04 Apr 2006 17:19:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsvf-0005Li-Ln for dime@ietf.org; Tue, 04 Apr 2006 17:19:11 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQsvf-0001ZD-7g for dime@ietf.org; Tue, 04 Apr 2006 17:19:11 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k34LJ4ob029418; Tue, 4 Apr 2006 17:19:05 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4432E2CA.5020408@tari.toshiba.com> Date: Tue, 04 Apr 2006 17:19:06 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] CER/CEA on an open connection References: <1AA39B75171A7144A73216AED1D7478D0186A034@esebe100.NOE.Nokia.com> <441CD0C0.5050701@tari.toshiba.com> <441D860F.1060404@cisco.com> In-Reply-To: <441D860F.1060404@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org After some offline discussion regarding CER/CEA exchange in the open connection state, a few of us have come up with the following application-id renegotiation proposal. It attempts to replicate existing CER/CEA exchanges as much as possible in order to minimize changes. The text is in its own section: "5.3.8 Application Support Re-Negotiation A Diameter node wishing to change application support MUST send a Capabilities-Exchange-Req (CER) to all its peers for which it shares an established connection. A change in application support constitutes addition or termination of one or more application in a Diameter node. In such a case, the Diameter node is expected to advertise the most recent set of supported applications in a CER message while it is in the open state as specified by the peer statemachine (see Sec 5.6). The receiver of the CER MUST send a CEA with Result-Code AVP set to DIAMETER_SUCCESS if it is able comply with the request. Note that peers which successfully renegotiated the set of supported applications SHOULD also update thier routing tables to reflect the change. If the receiver of the CER is unable to comply with the request, it SHOULD send a CEA with the Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY and retain its pre-existing state with its peer. The receiver of the CEA can decide wether to terminate or maintain the connection at the receipt of this result code. If it decides to maintain the connection then it MUST retain its pre-existing connection state with its peer prior sending the CER. A Diameter node SHOULD also determine wether changes in application support results in having no common applications with one or more peers prior to sending a CER. In such a case, it should send a Disconnect-Peer-Request (DPR) to terminate the connection instead. The Disconnect-Cause AVP of the DPR message MUST be set to DO_NOT_WANT_TO_TALK_TO_YOU. A Diameter node that receives a CER from a peer from which it has sent its own pending CER MUST be able serialize the simultaneous renegotiation. If the Diameter node is acting as a responder (see Sec 5.6) then it MUST give precedence to the renegotiation initiated by its peer and send a CEA accordingly. If the Diameter node is acting as an initiator (see Sec 5.6) then it MUST delay the renegotiation initiated by its peer (the responder) and send a CEA with Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY in order to retain the the current state between them. The receiver of this CEA (the responder) SHOULD retain its current state and proceed with the ongoing renegotiation initiated by its peer. It SHOULD retransmit its own CER to initiate another renegotiation after the current renegotiation completes. Both renegotiations SHOULD be treated as separate and sequential. Diameter nodes that implement application renegotiation SHOULD check the version information advertised by its peer in the diameter header of initial CER/CEA exchange to determine if the peer supports renegotiation. The diameter node MUST not attempt renegotiation if it is determined that peer has no support for such scheme. Capabilities exchange performed while in the open state SHOULD be limited to modification of application support. Information added to the CER/CEA messages by diameter extensions MAY be renegotiable though the extensions themselves have to specify such schemes." Hope this is helpful. Regards, victor > A simple alternative to renegotiation would be for nodes to terminate > and reestablish connections. Not desirable but given that this is > probably a rarely needed feature perhaps it could be acceptable. > > OTOH, if renegotiation is limited to changing supported applications > as proposed by Victor and Timothy, then that seems manageable. > > More inline... > > Victor Fajardo wrote: >>> >> >> >> Comments inline: >> >>> Hmm, it seems to me that if we have to fix the state machine, that >>> might be a significant change as it would affect people >>> implementations. Would specifying the renegotiation be something >>> that people are interested in? >> >> >> It seems renegotiation has a valid point. To minimize the change in >> current implementations maybe we can add text that describes >> optional(??) functionality: >> >> 1. limiting scope of renegotiation to app id support >> 2. sender of the cer wishes to add or remove app support with peer. >> if removal of an app results in no common app, the connection should >> be closed. This event need not be represented in the fsm since 2nd >> paragraph in sec 5.3 already describes the behavior. > > I think that in this case the guy removing support for the one shared > app should not send the CER but instead just terminate the connection. > (Possibly sending new Disconnect-Cause, say NO_SHARED_APP.) > >> 3. current stateful session affected by a removable will remain >> active until the session or the application itself ends. also applies >> to proxies. does not apply to stateless sessions, proxies or relays. > > We might want to specify a new non-2xxx result-code that the recipient > of an invalid "subsequent" CER can respond with. Invalid here meaning > that the CER differs from the CER/CEA originally sent by the peer in > aspects other than supported applications, e.g. different security or > different Origin-Host/Origin-Realm values. Of course the CER can be > rejected for other reasons, e.g. missing or illegal AVPs etc. > > We'll have to determine what happens with the connection in the case > where the CER is rejected. One option is to say that it stays open in > the state it was in prior to the failed CER. Both parties are then > free to terminate it themselves if they feel like it. > > Anders > >> >> hope this is helpful. regards, >> victor >> >> >>> >>> John >>> >>> >>> Hi Anders, >>> >>> I think there is a valid need for re-advertising capabilities. >>> Applications may come and go over time. So this gives a means >>> for an application to join an existing connection without having >>> to bring it down and disrupt other applications that might already >>> be using that connection. But I think the questions you raised >>> are valid with regard to the definition of this renegotiation. >>> >>> It is subtle, but renegotiation is really defining an additional >>> state in the state machine. If a CER is sent on an already >>> negotiated connection, you have entered a new >>> "Open-but-waiting_CEA" state. The questions that you raise should >>> be addressed in that new state. >>> >>> I think it is a good function, but agree that it needs to be >>> better defined. >>> >>> Best Regards, >>> Timothy Smith >>> >>> tjsmith@us.ibm.com >>> (919) 254-4723 >>> >>> >>> >>> *Anders Kristensen * >>> >>> 03/13/2006 09:49 AM >>> >>> To >>> dime@ietf.org >>> cc >>> Subject >>> [Dime] CER/CEA on an open connection >>> >>> >>> >>> >>> >>> >>> >>> >>> In its description of the peer state machine RFC 3588 goes out >>> of its >>> way to allow CER requests on an already open connection (section >>> 5.6). >>> Is the intention that either party can re-advertise its set of >>> capabilities at any time? This raises some questions. For >>> example, if >>> TLS was not listed as supported in the first CER/CEA but is now, >>> is it >>> possible to carry out a TLS handshake after the exchange of >>> non-CER/CEA >>> traffic? What if no response is received for a "non-initial" CER >>> (but >>> other traffic, including DWR/DEA, continues to be exchanged), >>> should the >>> connection be reset? >>> >>> I wonder if the ability to exchange capabilities on an open >>> connection >>> is widely supported and whether it is really useful enough to >>> warrant it >>> being part of the spec. Should probably be part of the base >>> protocol >>> test suite if it is. >>> >>> Anders >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Apr 04 18:18:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtrS-0001BR-5a; Tue, 04 Apr 2006 18:18:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtrR-0001BM-Kv for dime@ietf.org; Tue, 04 Apr 2006 18:18:53 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQtrQ-0003la-7H for dime@ietf.org; Tue, 04 Apr 2006 18:18:53 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 00:18:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Apr 2006 00:18:43 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03BFB223@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-tschofenig-dime-mip6-integrated-00.txt Thread-Index: AcZSScxptvMv7au6SPC3/NbtUwoqXwF6JLng From: To: X-OriginalArrivalTime: 04 Apr 2006 22:18:50.0458 (UTC) FILETIME=[C00323A0:01C65835] X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: charles.perkins@nokia.com Subject: [Dime] draft-tschofenig-dime-mip6-integrated-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, In Dallas meeting during the Diameter MIPv6 presentation=20 few questions were raised/asked: Integrated scenario solution uses Diameter application. Questions: o Application vs. attributes o Interworking with NASREQ and EAP=20 o MIPv4 interaction (dual stacked hosts) I looks like reusing NASREQ & EAP rather than defining new commands would be the way to go. However, the question still remains whether new applications are needed or would just a set of AVPs be sufficient? The MIPv4 support for dual stack cases (as worked in MIP6 WG) would require transporting MIPv4 HA address along with the MIPv6 stuff. MIP6 WG comment on this was that "...if you are using DHCP (integrated scenario) to deliver the IPv4 address of the HA, you would need some AAA work." Any thoughts & comments? Cheers, Jouni > Hi all, >=20 > we should work on a draft update for > <>. We have discussed > a number of issues already but we haven't reached a=20 > conclusion about the > application vs. attribute question. >=20 > Another important aspect: I do not want to be the editor nor the main=20 > author of the document. It would be great if someone could=20 > volunteer to=20 > take this position, if the person really has time. >=20 > Ciao > Hannes >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Apr 04 19:06:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQubB-0003iU-DM; Tue, 04 Apr 2006 19:06:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQubA-0003X3-Af for dime@ietf.org; Tue, 04 Apr 2006 19:06:08 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQub8-0006Sg-OE for dime@ietf.org; Tue, 04 Apr 2006 19:06:08 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id A8AFA87A76 for ; Tue, 4 Apr 2006 19:06:06 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k34N5lic003303 for ; Tue, 4 Apr 2006 19:05:52 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] CER/CEA on an open connection Date: Tue, 4 Apr 2006 18:44:45 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <4432E2CA.5020408@tari.toshiba.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, Overall, the idea of declaring unavailability of an application is really a useful functionality. OTOH I believe being able to distinguish between immediate and gracefull shutdowns is also important. As immediate shutdown, I refer to cases like an application crash etc... Gracefull shutdown is putting an application down in a controlled way for reasons like maintanence. Considering its controlled behavior, it is important to minimize message/state loss in that type of scenarios. I believe, accepting messages for existing sessions till they finish but not accepting messages for new sessions is a reasonable semantic for graceful shutdown case. This type of operation probably will require knowledge about session life cycle hence better be handled end-to-end rather than hop-by-hop. To support gracefull failover, I suggest to introduce a new error code -maybe a transient failure code?-. Something like: DIAMETER_APPLICATION_SHUTTING_DOWN. This will be returned back when a message initiating a new session is received, while the application is gracefully shutting down. When requester receives an answer with this error code, it shouldn't send any messages for new sessions, but it can continue to send messages for existing sessions. When all existing sessions finish, the application can be shut down and a CER declaring the unavailability of the application can be sent to immediate neighbors. If this sounds reasonable to people, I can provide text. IMO, for immediate shutdown, the mechanism described below is a good way of handling things. If there are intermediaries between client and server, the immediate neigbor of the node, which declared unavailability of the application, will reply with DIAMETER_UNABLE_TO_DELIVER for incoming requests, maybe a clarification about this may be added. Please see below for a few more questions as well. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Tuesday, April 04, 2006 5:19 PM > To: dime@ietf.org > Subject: Re: [Dime] CER/CEA on an open connection > > > After some offline discussion regarding CER/CEA exchange in the open > connection state, a few of us have come up with the following > application-id renegotiation proposal. It attempts to replicate existing > CER/CEA exchanges as much as possible in order to minimize changes. The > text is in its own section: > > "5.3.8 Application Support Re-Negotiation > > A Diameter node wishing to change application support MUST send a > Capabilities-Exchange-Req (CER) to all its peers for which it shares > an established connection. A change in application support constitutes > addition or termination of one or more application in a Diameter node. > In such a case, the Diameter node is expected to advertise the most > recent set of supported applications in a CER message while it is in > the open state as specified by the peer statemachine (see Sec 5.6). > The receiver of the CER MUST send a CEA with Result-Code AVP set to > DIAMETER_SUCCESS if it is able comply with the request. Note that peers > which successfully renegotiated the set of supported applications SHOULD > also update thier routing tables to reflect the change. > > If the receiver of the CER is unable to comply with the request, it SHOULD > send a CEA with the Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY and > retain its pre-existing state with its peer. The receiver of the CEA can > decide wether to terminate or maintain the connection at the receipt of > this result code. If it decides to maintain the connection then it MUST > retain its pre-existing connection state with its peer prior sending the > CER. [TOLGA]What do you mean with "pre-existing connection state"? Does this imply the set of supported applications or only peer state as defined in 5.6? Furthermore, when would a node reply with DIAMETER_UNABLE_TO_COMPLY? What type of scenario do we foresee for that, only the one described below, i.e. crossing CERs, or is this supposed to be a more generic rejection mechanism? > > A Diameter node SHOULD also determine wether changes in application > support results in having no common applications with one or more peers > prior to sending a CER. In such a case, it should send a > Disconnect-Peer-Request > (DPR) to terminate the connection instead. The Disconnect-Cause AVP of the > DPR message MUST be set to DO_NOT_WANT_TO_TALK_TO_YOU. > > A Diameter node that receives a CER from a peer from which it has sent its > own pending CER MUST be able serialize the simultaneous renegotiation. If > the Diameter node is acting as a responder (see Sec 5.6) then it MUST give > precedence to the renegotiation initiated by its peer and send a CEA > accordingly. > If the Diameter node is acting as an initiator (see Sec 5.6) then it > MUST delay > the renegotiation initiated by its peer (the responder) and send > a CEA with > Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY in order to retain the > the current state between them. The receiver of this CEA (the responder) > SHOULD retain its current state and proceed with the ongoing renegotiation > initiated by its peer. It SHOULD retransmit its own CER to > initiate another > renegotiation after the current renegotiation completes. Both > renegotiations > SHOULD be treated as separate and sequential. > > Diameter nodes that implement application renegotiation SHOULD check the > version information advertised by its peer in the diameter header > of initial > CER/CEA exchange to determine if the peer supports renegotiation. The > diameter > node MUST not attempt renegotiation if it is determined that peer has no > support > for such scheme. [TOLGA] > > Capabilities exchange performed while in the open state SHOULD be limited > to modification of application support. Information added to the CER/CEA > messages by diameter extensions MAY be renegotiable though the extensions > themselves have to specify such schemes." > > Hope this is helpful. Regards, > victor > > > A simple alternative to renegotiation would be for nodes to terminate > > and reestablish connections. Not desirable but given that this is > > probably a rarely needed feature perhaps it could be acceptable. > > > > OTOH, if renegotiation is limited to changing supported applications > > as proposed by Victor and Timothy, then that seems manageable. > > > > More inline... > > > > Victor Fajardo wrote: > >>> > >> > >> > >> Comments inline: > >> > >>> Hmm, it seems to me that if we have to fix the state machine, that > >>> might be a significant change as it would affect people > >>> implementations. Would specifying the renegotiation be something > >>> that people are interested in? > >> > >> > >> It seems renegotiation has a valid point. To minimize the change in > >> current implementations maybe we can add text that describes > >> optional(??) functionality: > >> > >> 1. limiting scope of renegotiation to app id support > >> 2. sender of the cer wishes to add or remove app support with peer. > >> if removal of an app results in no common app, the connection should > >> be closed. This event need not be represented in the fsm since 2nd > >> paragraph in sec 5.3 already describes the behavior. > > > > I think that in this case the guy removing support for the one shared > > app should not send the CER but instead just terminate the connection. > > (Possibly sending new Disconnect-Cause, say NO_SHARED_APP.) > > > >> 3. current stateful session affected by a removable will remain > >> active until the session or the application itself ends. also applies > >> to proxies. does not apply to stateless sessions, proxies or relays. > > > > We might want to specify a new non-2xxx result-code that the recipient > > of an invalid "subsequent" CER can respond with. Invalid here meaning > > that the CER differs from the CER/CEA originally sent by the peer in > > aspects other than supported applications, e.g. different security or > > different Origin-Host/Origin-Realm values. Of course the CER can be > > rejected for other reasons, e.g. missing or illegal AVPs etc. > > > > We'll have to determine what happens with the connection in the case > > where the CER is rejected. One option is to say that it stays open in > > the state it was in prior to the failed CER. Both parties are then > > free to terminate it themselves if they feel like it. > > > > Anders > > > >> > >> hope this is helpful. regards, > >> victor > >> > >> > >>> > >>> John > >>> > >>> > >>> Hi Anders, > >>> > >>> I think there is a valid need for re-advertising capabilities. > >>> Applications may come and go over time. So this gives a means > >>> for an application to join an existing connection without having > >>> to bring it down and disrupt other applications that might already > >>> be using that connection. But I think the questions you raised > >>> are valid with regard to the definition of this renegotiation. > >>> > >>> It is subtle, but renegotiation is really defining an additional > >>> state in the state machine. If a CER is sent on an already > >>> negotiated connection, you have entered a new > >>> "Open-but-waiting_CEA" state. The questions that you raise should > >>> be addressed in that new state. > >>> > >>> I think it is a good function, but agree that it needs to be > >>> better defined. > >>> > >>> Best Regards, > >>> Timothy Smith > >>> > >>> tjsmith@us.ibm.com > >>> (919) 254-4723 > >>> > >>> > >>> > >>> *Anders Kristensen * > >>> > >>> 03/13/2006 09:49 AM > >>> > >>> To > >>> dime@ietf.org > >>> cc > >>> Subject > >>> [Dime] CER/CEA on an open connection > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> In its description of the peer state machine RFC 3588 goes out > >>> of its > >>> way to allow CER requests on an already open connection (section > >>> 5.6). > >>> Is the intention that either party can re-advertise its set of > >>> capabilities at any time? This raises some questions. For > >>> example, if > >>> TLS was not listed as supported in the first CER/CEA but is now, > >>> is it > >>> possible to carry out a TLS handshake after the exchange of > >>> non-CER/CEA > >>> traffic? What if no response is received for a "non-initial" CER > >>> (but > >>> other traffic, including DWR/DEA, continues to be exchanged), > >>> should the > >>> connection be reset? > >>> > >>> I wonder if the ability to exchange capabilities on an open > >>> connection > >>> is widely supported and whether it is really useful enough to > >>> warrant it > >>> being part of the spec. Should probably be part of the base > >>> protocol > >>> test suite if it is. > >>> > >>> Anders > >>> > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/dime > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/dime > >>> > >>> > >> > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Apr 04 21:02:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQwPR-0007tD-Qz; Tue, 04 Apr 2006 21:02:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQwPQ-0007t8-Oo for dime@ietf.org; Tue, 04 Apr 2006 21:02:08 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQwPP-0002lI-H2 for dime@ietf.org; Tue, 04 Apr 2006 21:02:08 -0400 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k35123KR030065; Tue, 4 Apr 2006 21:02:04 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4433170D.4060704@tari.toshiba.com> Date: Tue, 04 Apr 2006 21:02:05 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] CER/CEA on an open connection References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, Thanks for your comments. Comments below: >> "5.3.8 Application Support Re-Negotiation >> >> A Diameter node wishing to change application support MUST send a >> Capabilities-Exchange-Req (CER) to all its peers for which it shares >> an established connection. A change in application support constitutes >> addition or termination of one or more application in a Diameter node. >> In such a case, the Diameter node is expected to advertise the most >> recent set of supported applications in a CER message while it is in >> the open state as specified by the peer statemachine (see Sec 5.6). >> The receiver of the CER MUST send a CEA with Result-Code AVP set to >> DIAMETER_SUCCESS if it is able comply with the request. Note that peers >> which successfully renegotiated the set of supported applications SHOULD >> also update thier routing tables to reflect the change. >> >> If the receiver of the CER is unable to comply with the request, it SHOULD >> send a CEA with the Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY and >> retain its pre-existing state with its peer. The receiver of the CEA can >> decide wether to terminate or maintain the connection at the receipt of >> this result code. If it decides to maintain the connection then it MUST >> retain its pre-existing connection state with its peer prior sending the >> CER. >> > [TOLGA]What do you mean with "pre-existing connection state"? Does this > imply the set of supported applications or only peer state as defined in > 5.6? > it means both supported application and peer state. > Furthermore, when would a node reply with DIAMETER_UNABLE_TO_COMPLY? What > type of scenario do we foresee for that, only the one described below, i.e. > crossing CERs, or is this supposed to be a more generic rejection mechanism? > its a generic rejection mechanism as stated above. it can be any scenario where a peer does not / cannot comply with the change request (probably based on some policy) and the renegotiation should not continue. I'll try to review your graceful shutdown proposal. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 04:58:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR3q3-0004hm-30; Wed, 05 Apr 2006 04:58:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR3q0-0004he-WD for dime@ietf.org; Wed, 05 Apr 2006 04:58:05 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR3q0-0003vx-K7 for dime@ietf.org; Wed, 05 Apr 2006 04:58:04 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 2D31180E5; Wed, 5 Apr 2006 10:58:02 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FR3m5-00009g-VB; Wed, 05 Apr 2006 10:54:01 +0200 Date: Wed, 5 Apr 2006 10:54:01 +0200 From: Julien Bournelle To: jouni.korhonen@teliasonera.com Message-ID: <20060405085401.GA592@ipv6-3.int-evry.fr> References: <5D25AEFB114D034FBDC8B156FCA78E03BFB223@SEHAN021MB.tcad.telia.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E03BFB223@SEHAN021MB.tcad.telia.se> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: charles.perkins@nokia.com, dime@ietf.org Subject: [Dime] Re: draft-tschofenig-dime-mip6-integrated-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi jouni, all, thanks for bringing this up. On Wed, Apr 05, 2006 at 12:18:43AM +0200, jouni.korhonen@teliasonera.com wrote: > Hi, > > In Dallas meeting during the Diameter MIPv6 presentation > few questions were raised/asked: > > Integrated scenario solution uses Diameter application. > Questions: > o Application vs. attributes > o Interworking with NASREQ and EAP > o MIPv4 interaction (dual stacked hosts) > > I looks like reusing NASREQ & EAP rather than defining > new commands would be the way to go. However, the question > still remains whether new applications are needed or > would just a set of AVPs be sufficient? Personnally, I tend to think that we don't need new messages and thus new Command-Code. Thus, only AVPs are sufficient and explain where to put them in the flow of messages for NASREQ/EAP. However, if we want that the AAA server knows that the NAS support the "mip6-integrated" scenario, the NAS may advertise this (in CER/CEA) and thus we also need to request an Application-ID for mip6-integrated. > The MIPv4 support for dual stack cases (as worked in > MIP6 WG) would require transporting MIPv4 HA address > along with the MIPv6 stuff. MIP6 WG comment on this > was that "...if you are using DHCP (integrated scenario) > to deliver the IPv4 address of the HA, you would need > some AAA work." I have some doubts about including this at this point. The reason is that delivering IPv4 HA address to the MN is not described in the Integrated scenario draft. I would prefer that this feature be added in this draft (mip6) and then include it in the DiME draft. what do you think ? Julien B. > > Any thoughts & comments? > > Cheers, > Jouni > > > > > Hi all, > > > > we should work on a draft update for > > <>. We have discussed > > a number of issues already but we haven't reached a > > conclusion about the > > application vs. attribute question. > > > > Another important aspect: I do not want to be the editor nor the main > > author of the document. It would be great if someone could > > volunteer to > > take this position, if the person really has time. > > > > Ciao > > Hannes > > > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 05:27:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4IW-0002sR-6U; Wed, 05 Apr 2006 05:27:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4IV-0002o5-2W for dime@ietf.org; Wed, 05 Apr 2006 05:27:31 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR4IT-0005Q8-Kn for dime@ietf.org; Wed, 05 Apr 2006 05:27:31 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 11:27:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Apr 2006 11:27:21 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03BFB265@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-tschofenig-dime-mip6-integrated-00.txt Thread-Index: AcZYjw31S4gpnFgOSKOPoyXi1PjiegAAidoA From: To: X-OriginalArrivalTime: 05 Apr 2006 09:27:28.0185 (UTC) FILETIME=[280A7A90:01C65893] X-Spam-Score: 0.2 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: charles.perkins@nokia.com, dime@ietf.org Subject: [Dime] RE: draft-tschofenig-dime-mip6-integrated-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien,=20 See my comments inline. > Hi jouni, all, >=20 > thanks for bringing this up. >=20 > On Wed, Apr 05, 2006 at 12:18:43AM +0200,=20 > jouni.korhonen@teliasonera.com wrote: > > Hi, > >=20 > > In Dallas meeting during the Diameter MIPv6 presentation=20 > > few questions were raised/asked: > >=20 > > Integrated scenario solution uses Diameter application. > > Questions: > > o Application vs. attributes > > o Interworking with NASREQ and EAP=20 > > o MIPv4 interaction (dual stacked hosts) > >=20 > > I looks like reusing NASREQ & EAP rather than defining > > new commands would be the way to go. However, the question > > still remains whether new applications are needed or > > would just a set of AVPs be sufficient? >=20 > Personnally, I tend to think that we don't need new messages and thus > new Command-Code. Thus, only AVPs are sufficient and explain where to > put them in the flow of messages for NASREQ/EAP. I agree that new commands codes should not be needed. > However, if we want that the AAA server knows that the NAS=20 > support the > "mip6-integrated" scenario, the NAS may advertise this (in CER/CEA) > and thus we also need to request an Application-ID for=20 > mip6-integrated. I believe that the ability for the AAA server to know whether the NAS supports integrated scenario is valuable information. Thus requesting a new Application-ID would be justifiable. > > The MIPv4 support for dual stack cases (as worked in > > MIP6 WG) would require transporting MIPv4 HA address > > along with the MIPv6 stuff. MIP6 WG comment on this > > was that "...if you are using DHCP (integrated scenario) > > to deliver the IPv4 address of the HA, you would need > > some AAA work." >=20 > I have some doubts about including this at this point. The reason is > that delivering IPv4 HA address to the MN is not described in the > Integrated scenario draft. I would prefer that this feature=20 > be added in > this draft (mip6) and then include it in the DiME draft. Hmmm.. fair enough.. (even though I think reserving one extra AVP for likely deployment issue does no harm ;) > what do you think ? >=20 > Julien B. Cheers, Jouni >=20 > >=20 > > Any thoughts & comments? > >=20 > > Cheers, > > Jouni > >=20 > >=20 > >=20 > > > Hi all, > > >=20 > > > we should work on a draft update for > > > <>. We have discussed > > > a number of issues already but we haven't reached a=20 > > > conclusion about the > > > application vs. attribute question. > > >=20 > > > Another important aspect: I do not want to be the editor=20 > nor the main=20 > > > author of the document. It would be great if someone could=20 > > > volunteer to=20 > > > take this position, if the person really has time. > > >=20 > > > Ciao > > > Hannes > > >=20 > > >=20 >=20 > --=20 > julien.bournelle at int-evry.fr >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 05:44:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4ZF-0008Ia-Iz; Wed, 05 Apr 2006 05:44:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4ZD-0008IV-O2 for dime@ietf.org; Wed, 05 Apr 2006 05:44:47 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FR4ZC-000668-9l for dime@ietf.org; Wed, 05 Apr 2006 05:44:47 -0400 Received: (qmail invoked by alias); 05 Apr 2006 09:44:44 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp017) with SMTP; 05 Apr 2006 11:44:44 +0200 X-Authenticated: #29516787 Message-ID: <44339185.9080904@gmx.net> Date: Wed, 05 Apr 2006 11:44:37 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org, rafa@dif.um.es, julien.bournelle@int-evry.fr, ivano.guardini@tilab.com, gerardo.giaretta@tilab.com, elena.demaria@tilab.com, basavaraj.patil@nokia.com, gdommety@cisco.com References: <5D25AEFB114D034FBDC8B156FCA78E03BFB265@SEHAN021MB.tcad.telia.se> In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E03BFB265@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Dime] Diameter MIPv6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, the MIP6 bootstrapping design team has worked on two solutions for bootstrapping of MIPv6: the integrated and the split scenario These two solutions are documented in two separate drafts: MIP6-bootstrapping via DHCPv6 for the Integrated Scenario http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt Mobile IPv6 bootstrapping in split scenario http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-02.txt As such, there is the question whether the work in DIME should also produce two separate documents referring to these two bootstrapping deployment scenarios or whether it would be useful to captures both scenarios in a single document. Thoughts? Ciao Hannes & John PS: John and myself would also like to know when the MIP6-AAA Goals draft http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-01.txt is going to be finalized since the Diameter MIPv6 work depends on this document. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 06:06:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4u8-0003RZ-BZ; Wed, 05 Apr 2006 06:06:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4u6-0003RU-Ka for dime@ietf.org; Wed, 05 Apr 2006 06:06:22 -0400 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR4u4-0006Vv-AK for dime@ietf.org; Wed, 05 Apr 2006 06:06:22 -0400 Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 12:06:17 +0200 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.228]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Apr 2006 12:06:16 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Importance: normal Priority: normal Date: Wed, 5 Apr 2006 12:01:29 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter MIPv6 thread-index: AcZYlZRfKQPjyIbZSV6hsB7nRC6nbgAAlSEL References: <5D25AEFB114D034FBDC8B156FCA78E03BFB265@SEHAN021MB.tcad.telia.se> <44339185.9080904@gmx.net> From: "Giaretta Gerardo" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 05 Apr 2006 10:06:16.0609 (UTC) FILETIME=[93E3C910:01C65898] X-Spam-Score: 0.5 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: Demaria Elena , basavaraj.patil@nokia.com, gdommety@cisco.com, Guardini Ivano Subject: [Dime] RE: Diameter MIPv6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0909465260==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0909465260== Content-Type: multipart/alternative; boundary="----=_NextPart_000_1B5B0B_01C658A9.5851F000" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_1B5B0B_01C658A9.5851F000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Hannes and John, I'm working on a new version of the draft based on comments I received = in Dallas. If you can review the document and have additional comments, = please provide them. I think the draft may be in a good shape by next = IETF if there will be good reviews from MIP6 WG. As a side note, the draft will encompass all AAA requirements for MIPv6, = both for AAA-HA and AAA-NAS interface, and both for integrated and split = scenario. Therefore I think we may have one document in DIME WG, since = many components of integrated and split solutions are common. Regards, --Gerardo -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Wed 4/5/2006 11:44 AM To: dime@ietf.org; rafa@dif.um.es; julien.bournelle@int-evry.fr; = Guardini Ivano; Giaretta Gerardo; Demaria Elena; = basavaraj.patil@nokia.com; gdommety@cisco.com Subject: Diameter MIPv6 =20 Hi all, the MIP6 bootstrapping design team has worked on two solutions for=20 bootstrapping of MIPv6: the integrated and the split scenario These two solutions are documented in two separate drafts: MIP6-bootstrapping via DHCPv6 for the Integrated Scenario http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integra= ted-dhc-00.txt Mobile IPv6 bootstrapping in split scenario http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-0= 2.txt As such, there is the question whether the work in DIME should also=20 produce two separate documents referring to these two bootstrapping=20 deployment scenarios or whether it would be useful to captures both=20 scenarios in a single document. Thoughts? Ciao Hannes & John PS: John and myself would also like to know when the MIP6-AAA Goals = draft http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-01.txt is going to be finalized since the Diameter MIPv6 work depends on this=20 document. -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_1B5B0B_01C658A9.5851F000 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
 
Hi Hannes and = John,

I'm working on a new version of the draft based on comments = I received in Dallas. If you can review the document and have additional = comments, please provide them. I think the draft may be in a good shape = by next IETF if there will be good reviews from MIP6 WG.

As a = side note, the draft will encompass all AAA requirements for MIPv6, both = for AAA-HA and AAA-NAS interface, and both for integrated and split = scenario. Therefore I think we may have one document in DIME WG, since = many components of integrated and split solutions are = common.

Regards,
--Gerardo


-----Original = Message-----
From: Hannes Tschofenig = [mailto:Hannes.Tschofenig@gmx.net]
Sent: Wed 4/5/2006 11:44 AM
To: = dime@ietf.org; rafa@dif.um.es; julien.bournelle@int-evry.fr; Guardini = Ivano; Giaretta Gerardo; Demaria Elena; basavaraj.patil@nokia.com; = gdommety@cisco.com
Subject: Diameter MIPv6

Hi all,

the = MIP6 bootstrapping design team has worked on two solutions for =
bootstrapping of MIPv6: the integrated and the split = scenario

These two solutions are documented in two separate = drafts:

MIP6-bootstrapping via DHCPv6 for the Integrated = Scenario
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap= ping-integrated-dhc-00.txt

Mobile IPv6 bootstrapping in split = scenario
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap= ping-split-02.txt

As such, there is the question whether the work = in DIME should also
produce two separate documents referring to = these two bootstrapping
deployment scenarios or whether it would be = useful to captures both
scenarios in a single = document.

Thoughts?

Ciao
Hannes & John

PS: John = and myself would also like to know when the MIP6-AAA Goals = draft
http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals= -01.txt
is going to be finalized since the Diameter MIPv6 work = depends on this
document.







--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_1B5B0B_01C658A9.5851F000-- --===============0909465260== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0909465260==-- From dime-bounces@ietf.org Wed Apr 05 06:17:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR54v-0001hL-MV; Wed, 05 Apr 2006 06:17:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR54v-0001gA-2A for dime@ietf.org; Wed, 05 Apr 2006 06:17:33 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR54u-00074g-Ac for dime@ietf.org; Wed, 05 Apr 2006 06:17:33 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k35AGjh1013059; Wed, 5 Apr 2006 13:16:47 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 13:16:48 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 13:16:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] RE: Diameter MIPv6 Date: Wed, 5 Apr 2006 13:16:47 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB0C9234@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter MIPv6 Thread-Index: AcZYlZRfKQPjyIbZSV6hsB7nRC6nbgAAlSELAACEZoA= From: To: , , X-OriginalArrivalTime: 05 Apr 2006 10:16:48.0256 (UTC) FILETIME=[0C617800:01C6589A] X-Spam-Score: 0.3 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: elena.demaria@telecomitalia.it, gdommety@cisco.com, ivano.guardini@telecomitalia.it, Basavaraj.Patil@nokia.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1688547384==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1688547384== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6589A.0BF29A5B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6589A.0BF29A5B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gerardo, I think this seems like a reasonable approach. When you have a version for review, let me know. =20 John ________________________________ From: ext Giaretta Gerardo [mailto:gerardo.giaretta@telecomitalia.it]=20 Sent: 05 April, 2006 13:01 To: Hannes Tschofenig; dime@ietf.org Cc: Demaria Elena; Patil Basavaraj (Nokia-NET/Dallas); gdommety@cisco.com; Guardini Ivano Subject: [Dime] RE: Diameter MIPv6 =09 =09 =20 Hi Hannes and John, =09 I'm working on a new version of the draft based on comments I received in Dallas. If you can review the document and have additional comments, please provide them. I think the draft may be in a good shape by next IETF if there will be good reviews from MIP6 WG. =09 As a side note, the draft will encompass all AAA requirements for MIPv6, both for AAA-HA and AAA-NAS interface, and both for integrated and split scenario. Therefore I think we may have one document in DIME WG, since many components of integrated and split solutions are common. =09 Regards, --Gerardo =09 =09 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Wed 4/5/2006 11:44 AM To: dime@ietf.org; rafa@dif.um.es; julien.bournelle@int-evry.fr; Guardini Ivano; Giaretta Gerardo; Demaria Elena; basavaraj.patil@nokia.com; gdommety@cisco.com Subject: Diameter MIPv6 =09 Hi all, =09 the MIP6 bootstrapping design team has worked on two solutions for=20 bootstrapping of MIPv6: the integrated and the split scenario =09 These two solutions are documented in two separate drafts: =09 MIP6-bootstrapping via DHCPv6 for the Integrated Scenario =09 http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integr ated-dhc-00.txt =09 Mobile IPv6 bootstrapping in split scenario =09 http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- 02.txt =09 As such, there is the question whether the work in DIME should also=20 produce two separate documents referring to these two bootstrapping=20 deployment scenarios or whether it would be useful to captures both=20 scenarios in a single document. =09 Thoughts? =09 Ciao Hannes & John =09 PS: John and myself would also like to know when the MIP6-AAA Goals draft =09 http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-01.txt is going to be finalized since the Diameter MIPv6 work depends on this=20 document. =09 =09 =09 =09 =09 =09 =09 =09 =09 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it . Thank you www.telecomitalia.it =20 =09 -------------------------------------------------------------------- ------_=_NextPart_001_01C6589A.0BF29A5B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Gerardo,

I think this=20 seems like a reasonable approach.  When you have a version for = review, let=20 me know.
 
John

From: ext Giaretta Gerardo=20 [mailto:gerardo.giaretta@telecomitalia.it]
Sent: 05 April, = 2006=20 13:01
To: Hannes Tschofenig; dime@ietf.org
Cc: = Demaria=20 Elena; Patil Basavaraj (Nokia-NET/Dallas); gdommety@cisco.com; = Guardini=20 Ivano
Subject: [Dime] RE: Diameter = MIPv6

 
Hi Hannes and John,

I'm working on a new = version of=20 the draft based on comments I received in Dallas. If you can review = the=20 document and have additional comments, please provide them. I think = the draft=20 may be in a good shape by next IETF if there will be good reviews from = MIP6=20 WG.

As a side note, the draft will encompass all AAA = requirements for=20 MIPv6, both for AAA-HA and AAA-NAS interface, and both for integrated = and=20 split scenario. Therefore I think we may have one document in DIME WG, = since=20 many components of integrated and split solutions are=20 common.

Regards,
--Gerardo


-----Original=20 Message-----
From: Hannes Tschofenig=20 [mailto:Hannes.Tschofenig@gmx.net]
Sent: Wed 4/5/2006 11:44 = AM
To:=20 dime@ietf.org; rafa@dif.um.es; julien.bournelle@int-evry.fr; Guardini = Ivano;=20 Giaretta Gerardo; Demaria Elena; basavaraj.patil@nokia.com;=20 gdommety@cisco.com
Subject: Diameter MIPv6

Hi = all,

the MIP6=20 bootstrapping design team has worked on two solutions for =
bootstrapping of=20 MIPv6: the integrated and the split scenario

These two = solutions are=20 documented in two separate drafts:

MIP6-bootstrapping via = DHCPv6 for=20 the Integrated=20 = Scenario
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap= ping-integrated-dhc-00.txt

Mobile=20 IPv6 bootstrapping in split=20 = scenario
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap= ping-split-02.txt

As=20 such, there is the question whether the work in DIME should also =
produce=20 two separate documents referring to these two bootstrapping =
deployment=20 scenarios or whether it would be useful to captures both
scenarios = in a=20 single document.

Thoughts?

Ciao
Hannes & = John

PS:=20 John and myself would also like to know when the MIP6-AAA Goals=20 = draft
http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals= -01.txt
is=20 going to be finalized since the Diameter MIPv6 work depends on this=20
document.







--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the = persons
above and may contain confidential information. If you have = received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender = and=20 delete
the message. Should you have any questions, please contact = us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 = you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------_=_NextPart_001_01C6589A.0BF29A5B-- --===============1688547384== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1688547384==-- From dime-bounces@ietf.org Wed Apr 05 06:18:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR561-0002iR-EZ; Wed, 05 Apr 2006 06:18:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR55z-0002dQ-8R for dime@ietf.org; Wed, 05 Apr 2006 06:18:39 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR55y-00078H-Ms for dime@ietf.org; Wed, 05 Apr 2006 06:18:39 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k35AHtaj013556; Wed, 5 Apr 2006 13:17:56 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 13:18:37 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 13:18:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re: draft-tschofenig-dime-mip6-integrated-00.txt Date: Wed, 5 Apr 2006 13:18:36 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB0C9235@esebe100.NOE.Nokia.com> In-Reply-To: <20060405085401.GA592@ipv6-3.int-evry.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: draft-tschofenig-dime-mip6-integrated-00.txt Thread-Index: AcZYjyuI6BlD67TrT4ip46RY8PYH+wACu10Q From: To: , X-OriginalArrivalTime: 05 Apr 2006 10:18:37.0784 (UTC) FILETIME=[4DAA1D80:01C6589A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Charles.Perkins@nokia.com, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Julien, >> I looks like reusing NASREQ & EAP rather than defining new commands=20 >> would be the way to go. However, the question still remains whether=20 >> new applications are needed or would just a set of AVPs be=20 >sufficient? > > Personnally, I tend to think that we don't need new messages=20 >and thus new Command-Code. Thus, only AVPs are sufficient and=20 >explain where to put them in the flow of messages for NASREQ/EAP. > > However, if we want that the AAA server knows that the NAS=20 >support the "mip6-integrated" scenario, the NAS may advertise=20 >this (in CER/CEA) and thus we also need to request an=20 >Application-ID for mip6-integrated. I strongly suggest having an application ID for this. >> The MIPv4 support for dual stack cases (as worked in >> MIP6 WG) would require transporting MIPv4 HA address along with the=20 >> MIPv6 stuff. MIP6 WG comment on this was that "...if you are using=20 >> DHCP (integrated scenario) to deliver the IPv4 address of the HA, you >> would need some AAA work." > > I have some doubts about including this at this point. The=20 >reason is that delivering IPv4 HA address to the MN is not=20 >described in the Integrated scenario draft. I would prefer=20 >that this feature be added in this draft (mip6) and then=20 >include it in the DiME draft. > > what do you think ? As a high-level comment, it might be interesting to have a solution that works with dual-stack MIP, but I'd like to see if others are interested in it as well. John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 06:19:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR56i-0003Pg-O1; Wed, 05 Apr 2006 06:19:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR56h-0003PR-Oz for dime@ietf.org; Wed, 05 Apr 2006 06:19:23 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR56g-0007CO-U0 for dime@ietf.org; Wed, 05 Apr 2006 06:19:23 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k35AJKVn032512; Wed, 5 Apr 2006 12:19:20 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k35AJJBT027203; Wed, 5 Apr 2006 12:19:20 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 12:19:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [Dime] RE: Diameter MIPv6 Date: Wed, 5 Apr 2006 12:19:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter MIPv6 Thread-Index: AcZYlZRfKQPjyIbZSV6hsB7nRC6nbgAAlSELAACEZoAAABWyMA== From: "Tschofenig, Hannes" To: , , , X-OriginalArrivalTime: 05 Apr 2006 10:19:19.0601 (UTC) FILETIME=[6696E210:01C6589A] X-Spam-Score: 0.1 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: elena.demaria@telecomitalia.it, gdommety@cisco.com, ivano.guardini@telecomitalia.it, Basavaraj.Patil@nokia.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1687131779==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1687131779== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6589A.6634AC30" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6589A.6634AC30 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Gerardo, maybe you also want to change the title of the draft and the serious formatting problem. =20 Ciao Hannes =20 ________________________________ Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Mittwoch, 5. April 2006 12:17 An: gerardo.giaretta@telecomitalia.it; Hannes.Tschofenig@gmx.net; dime@ietf.org Cc: elena.demaria@telecomitalia.it; gdommety@cisco.com; ivano.guardini@telecomitalia.it; Basavaraj.Patil@nokia.com Betreff: RE: [Dime] RE: Diameter MIPv6 =09 =09 Gerardo, =09 I think this seems like a reasonable approach. When you have a version for review, let me know. =20 John ________________________________ From: ext Giaretta Gerardo [mailto:gerardo.giaretta@telecomitalia.it]=20 Sent: 05 April, 2006 13:01 To: Hannes Tschofenig; dime@ietf.org Cc: Demaria Elena; Patil Basavaraj (Nokia-NET/Dallas); gdommety@cisco.com; Guardini Ivano Subject: [Dime] RE: Diameter MIPv6 =09 =09 =20 Hi Hannes and John, =09 I'm working on a new version of the draft based on comments I received in Dallas. If you can review the document and have additional comments, please provide them. I think the draft may be in a good shape by next IETF if there will be good reviews from MIP6 WG. =09 As a side note, the draft will encompass all AAA requirements for MIPv6, both for AAA-HA and AAA-NAS interface, and both for integrated and split scenario. Therefore I think we may have one document in DIME WG, since many components of integrated and split solutions are common. =09 Regards, --Gerardo =09 =09 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Wed 4/5/2006 11:44 AM To: dime@ietf.org; rafa@dif.um.es; julien.bournelle@int-evry.fr; Guardini Ivano; Giaretta Gerardo; Demaria Elena; basavaraj.patil@nokia.com; gdommety@cisco.com Subject: Diameter MIPv6 =09 Hi all, =09 the MIP6 bootstrapping design team has worked on two solutions for=20 bootstrapping of MIPv6: the integrated and the split scenario =09 These two solutions are documented in two separate drafts: =09 MIP6-bootstrapping via DHCPv6 for the Integrated Scenario =09 http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integr ated-dhc-00.txt =09 Mobile IPv6 bootstrapping in split scenario =09 http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- 02.txt =09 As such, there is the question whether the work in DIME should also=20 produce two separate documents referring to these two bootstrapping=20 deployment scenarios or whether it would be useful to captures both=20 scenarios in a single document. =09 Thoughts? =09 Ciao Hannes & John =09 PS: John and myself would also like to know when the MIP6-AAA Goals draft =09 http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-01.txt is going to be finalized since the Diameter MIPv6 work depends on this=20 document. =09 =09 =09 =09 =09 =09 =09 =09 =09 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it . Thank you =09 www.telecomitalia.it =20 =09 -------------------------------------------------------------------- ------_=_NextPart_001_01C6589A.6634AC30 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Gerardo, maybe you also want to change the = title of the=20 draft and the serious formatting problem.
 
Ciao
Hannes
 

Von: john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Gesendet: Mittwoch, 5. = April 2006=20 12:17
An: gerardo.giaretta@telecomitalia.it;=20 Hannes.Tschofenig@gmx.net; dime@ietf.org
Cc:=20 elena.demaria@telecomitalia.it; gdommety@cisco.com;=20 ivano.guardini@telecomitalia.it; = Basavaraj.Patil@nokia.com
Betreff:=20 RE: [Dime] RE: Diameter MIPv6

Gerardo,

I think this=20 seems like a reasonable approach.  When you have a version for = review,=20 let me know.
 
John

From: ext Giaretta Gerardo=20 [mailto:gerardo.giaretta@telecomitalia.it]
Sent: 05 = April, 2006=20 13:01
To: Hannes Tschofenig; dime@ietf.org
Cc: = Demaria=20 Elena; Patil Basavaraj (Nokia-NET/Dallas); gdommety@cisco.com; = Guardini=20 Ivano
Subject: [Dime] RE: Diameter = MIPv6

 
Hi Hannes and John,

I'm working on a new = version of=20 the draft based on comments I received in Dallas. If you can review = the=20 document and have additional comments, please provide them. I think = the=20 draft may be in a good shape by next IETF if there will be good = reviews from=20 MIP6 WG.

As a side note, the draft will encompass all AAA=20 requirements for MIPv6, both for AAA-HA and AAA-NAS interface, and = both for=20 integrated and split scenario. Therefore I think we may have one = document in=20 DIME WG, since many components of integrated and split solutions are = common.

Regards,
--Gerardo


-----Original=20 Message-----
From: Hannes Tschofenig=20 [mailto:Hannes.Tschofenig@gmx.net]
Sent: Wed 4/5/2006 11:44 = AM
To:=20 dime@ietf.org; rafa@dif.um.es; julien.bournelle@int-evry.fr; = Guardini Ivano;=20 Giaretta Gerardo; Demaria Elena; basavaraj.patil@nokia.com;=20 gdommety@cisco.com
Subject: Diameter MIPv6

Hi = all,

the MIP6=20 bootstrapping design team has worked on two solutions for =
bootstrapping=20 of MIPv6: the integrated and the split scenario

These two = solutions=20 are documented in two separate drafts:

MIP6-bootstrapping via = DHCPv6=20 for the Integrated=20 = Scenario
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap= ping-integrated-dhc-00.txt

Mobile=20 IPv6 bootstrapping in split=20 = scenario
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap= ping-split-02.txt

As=20 such, there is the question whether the work in DIME should also =
produce=20 two separate documents referring to these two bootstrapping =
deployment=20 scenarios or whether it would be useful to captures both =
scenarios in a=20 single document.

Thoughts?

Ciao
Hannes &=20 John

PS: John and myself would also like to know when the = MIP6-AAA=20 Goals=20 = draft
http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals= -01.txt
is=20 going to be finalized since the Diameter MIPv6 work depends on this=20
document.







--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to = the=20 persons
above and may contain confidential information. If you = have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender = and=20 delete
the message. Should you have any questions, please contact = us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 = you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------_=_NextPart_001_01C6589A.6634AC30-- --===============1687131779== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1687131779==-- From dime-bounces@ietf.org Wed Apr 05 06:46:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR5Wx-0004vK-Gv; Wed, 05 Apr 2006 06:46:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR5Ww-0004n9-25 for dime@ietf.org; Wed, 05 Apr 2006 06:46:30 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR5Wv-0007zx-OV for dime@ietf.org; Wed, 05 Apr 2006 06:46:30 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 79A8A809F; Wed, 5 Apr 2006 12:46:26 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FR5T0-0000Cz-5t; Wed, 05 Apr 2006 12:42:26 +0200 Date: Wed, 5 Apr 2006 12:42:26 +0200 From: Julien Bournelle To: Hannes Tschofenig Message-ID: <20060405104226.GA797@ipv6-3.int-evry.fr> References: <5D25AEFB114D034FBDC8B156FCA78E03BFB265@SEHAN021MB.tcad.telia.se> <44339185.9080904@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44339185.9080904@gmx.net> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: gdommety@cisco.com, elena.demaria@tilab.com, basavaraj.patil@nokia.com, gerardo.giaretta@tilab.com, dime@ietf.org, ivano.guardini@tilab.com Subject: [Dime] Re: Diameter MIPv6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, On Wed, Apr 05, 2006 at 11:44:37AM +0200, Hannes Tschofenig wrote: > Hi all, > > the MIP6 bootstrapping design team has worked on two solutions for > bootstrapping of MIPv6: the integrated and the split scenario > > These two solutions are documented in two separate drafts: > > MIP6-bootstrapping via DHCPv6 for the Integrated Scenario > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt > > Mobile IPv6 bootstrapping in split scenario > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-02.txt > > As such, there is the question whether the work in DIME should also > produce two separate documents referring to these two bootstrapping > deployment scenarios or whether it would be useful to captures both > scenarios in a single document. > > Thoughts? I would prefer two documents. I have two reasons for this: 1/ In the integrated scenario, the AAA is used between NAS and AAA. The HA address is delivered from the AAA to the NAS and thus NASREQ or EAP may be in used. In the split scenario, Diameter is used between HA and the AAA. And the AAA does not deliver the HA to the HA... 2/ From an implementation perspective, it would be easier to have a specific document for each case. Julien B. > > Ciao > Hannes & John > > PS: John and myself would also like to know when the MIP6-AAA Goals draft > http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-01.txt > is going to be finalized since the Diameter MIPv6 work depends on this > document. -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 14:02:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCKl-00050H-Aq; Wed, 05 Apr 2006 14:02:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCKk-000508-EW for dime@ietf.org; Wed, 05 Apr 2006 14:02:22 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRCKi-0001ik-5c for dime@ietf.org; Wed, 05 Apr 2006 14:02:22 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id C8BEBA9487 for ; Wed, 5 Apr 2006 14:02:19 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k35I2Hfs021426 for ; Wed, 5 Apr 2006 14:02:18 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] CER/CEA on an open connection Date: Wed, 5 Apr 2006 13:41:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <4433170D.4060704@tari.toshiba.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, [.. snip ..] > > [TOLGA]What do you mean with "pre-existing connection state"? Does this > > imply the set of supported applications or only peer state as defined in > > 5.6? > > > it means both supported application and peer state. > > Furthermore, when would a node reply with > DIAMETER_UNABLE_TO_COMPLY? What > > type of scenario do we foresee for that, only the one described > below, i.e. > > crossing CERs, or is this supposed to be a more generic > rejection mechanism? > > > its a generic rejection mechanism as stated above. it can be any > scenario where a peer does not / cannot comply with the change request > (probably based on some policy) and the renegotiation should not continue. [TOLGA]Isn't it a bit odd to keep the supported application set unmodifed at the node, where application is no more existing? Even if the other side does not agree -for whatever reason- for the new advertised application set, this won't bring the application back and I think received requests for this application will(should) be replied with DIAMETER_APPLICATION_UNSUPPORTED. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 14:55:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRD9y-0006Ec-1q; Wed, 05 Apr 2006 14:55:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRD9w-0006EX-Uf for dime@ietf.org; Wed, 05 Apr 2006 14:55:16 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRD9w-0004Mc-LT for dime@ietf.org; Wed, 05 Apr 2006 14:55:16 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k35ItCeA033459; Wed, 5 Apr 2006 14:55:13 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <443412B6.3050202@tari.toshiba.com> Date: Wed, 05 Apr 2006 14:55:50 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] CER/CEA on an open connection References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, > Hi Victor, > > [.. snip ..] > >>> [TOLGA]What do you mean with "pre-existing connection state"? Does this >>> imply the set of supported applications or only peer state as defined in >>> 5.6? >>> >>> >> it means both supported application and peer state. >> >>> Furthermore, when would a node reply with >>> >> DIAMETER_UNABLE_TO_COMPLY? What >> >>> type of scenario do we foresee for that, only the one described >>> >> below, i.e. >> >>> crossing CERs, or is this supposed to be a more generic >>> >> rejection mechanism? >> >> its a generic rejection mechanism as stated above. it can be any >> scenario where a peer does not / cannot comply with the change request >> (probably based on some policy) and the renegotiation should not continue. >> > [TOLGA]Isn't it a bit odd to keep the supported application set unmodifed at > the node, where application is no more existing? Even if the other side does > not agree -for whatever reason- for the new advertised application set, this > won't bring the application back and I think received requests for this > application will(should) be replied with DIAMETER_APPLICATION_UNSUPPORTED. > What is proposed is that a node initiating the change request should not terminate the supported application until the corresponding peer agrees. If the peer does not agree, the node initiating the change request has an alternative to gracefully terminate of the connection with the peer if it chooses to. Otherwise, it must honor its commitment to keep the application support. regards, victor > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 16:14:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREOg-0006Q7-8c; Wed, 05 Apr 2006 16:14:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREOe-0006PZ-LQ for dime@ietf.org; Wed, 05 Apr 2006 16:14:32 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FREOd-0002c6-Cl for dime@ietf.org; Wed, 05 Apr 2006 16:14:32 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 284E967AD7 for ; Wed, 5 Apr 2006 16:14:31 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k35KEOh6003078 for ; Wed, 5 Apr 2006 16:14:29 -0400 (EDT) From: "Tolga Asveren" To: Date: Wed, 5 Apr 2006 15:53:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Dime] congestion of intermediaries X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org RFC3588 7.1.3 states: DIAMETER_TOO_BUSY 3004 When returned, a Diameter node SHOULD attempt to send the message to an alternate peer. This error MUST only be used when a specific server is requested, and it cannot provide the requested service. Based on that description, I have the impression that this error code is to be returned only by a server. Diameter intermediary nodes, e.g. relay agents, may get congested as well and it could be a good idea to convey that information back to the clients so that they pick another relay agent if possible, when routing requests. With the current mechanisms, we probably need to rely on the congestion getting propogated back to the client through TCP/SCTP or on watchdog failure. IMO, this is not a very nice way of dealing with this situation, because it may take a long time till the sender of request is aware of the congestion and during that time a lot of requests may be already sent to the congested node. It could be an idea to convey congestion of intermediaries with a new error code, something like DIAM_CONGESTED. DIAMETER_TOO_BUSY still can be used for server congestions, where a change on Destination-Host AVP is necessary, i.e. it should be consumed by the client, whereas DIAMETER_CONGESTED is to be consumed hop-by-hop, i.e. by the immediate neighbor. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 16:47:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREup-00036k-3t; Wed, 05 Apr 2006 16:47:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREun-00035n-SK for dime@ietf.org; Wed, 05 Apr 2006 16:47:45 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FREun-0003yz-II for dime@ietf.org; Wed, 05 Apr 2006 16:47:45 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id A9D7C16B9E for ; Wed, 5 Apr 2006 16:47:45 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k35KliUv006005 for ; Wed, 5 Apr 2006 16:47:44 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] CER/CEA on an open connection Date: Wed, 5 Apr 2006 16:26:55 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <443412B6.3050202@tari.toshiba.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, [..snip..] > >> its a generic rejection mechanism as stated above. it can be any > >> scenario where a peer does not / cannot comply with the change request > >> (probably based on some policy) and the renegotiation should > not continue. > >> > > [TOLGA]Isn't it a bit odd to keep the supported application set > unmodifed at > > the node, where application is no more existing? Even if the > other side does > > not agree -for whatever reason- for the new advertised > application set, this > > won't bring the application back and I think received requests for this > > application will(should) be replied with > DIAMETER_APPLICATION_UNSUPPORTED. > > > What is proposed is that a node initiating the change request should not > terminate the supported application until the corresponding peer agrees. > If the peer does not agree, the node initiating the change request has > an alternative to gracefully terminate of the connection with the peer > if it chooses to. Otherwise, it must honor its commitment to keep the > application support. [TOLGA]AFAICS, the moment you introduce some intelligence to that procedure, e.g. receiver of CER aggreing with the application getting down, you need to be sure that you are communicating with your application level peer. CER/CEA is hop-to-hop, it probably won't do it for a generic solution, where we have relay agents etc.. between the endpoints. OTOH, the proposed solution is usefull for the cases, where a node is just declaring the unavailability of a certian application to its immediate neighbors, where there is no confirmation necessary from them. In any case, it still can be used as a generic solution, just one needs to be aware that CEA(Success) does not necessarily mean that the actual application layer peer has agreed for the application going down. Just to prevent a confusion, what I call as graceful shutdown is different than the semantics you described, i.e. shutting down an application only after receiving an acknowledgement from the peer. In graceful shutdown, the application node is still in full control of when shutting down the application, it is just indicating to the peer that it will accept messages for existing sessions. This can be indicated just with an error code, because it doesn't require a confirmation. I believe, the semantics you described would require an end-to-end request/response transaction between two application layer peers, which can be achieved with CER/CEA if client/server are direct neighbors but can't be achieved with CEA/CER, if there are relay agents between. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 17:23:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFTF-0007a9-Ls; Wed, 05 Apr 2006 17:23:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFTE-0007Zz-LY for dime@ietf.org; Wed, 05 Apr 2006 17:23:20 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFTD-0005va-DC for dime@ietf.org; Wed, 05 Apr 2006 17:23:20 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k35LNF3L034317; Wed, 5 Apr 2006 17:23:15 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44343545.3090403@tari.toshiba.com> Date: Wed, 05 Apr 2006 17:23:17 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] CER/CEA on an open connection References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, >>> ill(should) be replied with >>> >> DIAMETER_APPLICATION_UNSUPPORTED. >> >> What is proposed is that a node initiating the change request should not >> terminate the supported application until the corresponding peer agrees. >> If the peer does not agree, the node initiating the change request has >> an alternative to gracefully terminate of the connection with the peer >> if it chooses to. Otherwise, it must honor its commitment to keep the >> application support. >> > [TOLGA]AFAICS, the moment you introduce some intelligence to that procedure, > e.g. receiver of CER aggreing with the application getting down, you need to > be sure that you are communicating with your application level peer. CER/CEA > is hop-to-hop, it probably won't do it for a generic solution, where we have > relay agents etc.. between the endpoints. > renegotiation is done between peers (one hope) not between end-points and the decision on wether to continue support for an application is local to a node. how a node will deal with not supporting an application anymore is up to the application itself. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 17:45:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFp5-0001jd-G4; Wed, 05 Apr 2006 17:45:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFp4-0001jH-4T for dime@ietf.org; Wed, 05 Apr 2006 17:45:54 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFp2-00074p-Qa for dime@ietf.org; Wed, 05 Apr 2006 17:45:54 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 8495FF0D7C for ; Wed, 5 Apr 2006 17:45:52 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k35LjpkM010635 for ; Wed, 5 Apr 2006 17:45:51 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] CER/CEA on an open connection Date: Wed, 5 Apr 2006 17:25:02 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44343545.3090403@tari.toshiba.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Wednesday, April 05, 2006 5:23 PM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] CER/CEA on an open connection > > > Hi Tolga, > >>> ill(should) be replied with > >>> > >> DIAMETER_APPLICATION_UNSUPPORTED. > >> > >> What is proposed is that a node initiating the change request > should not > >> terminate the supported application until the corresponding > peer agrees. > >> If the peer does not agree, the node initiating the change request has > >> an alternative to gracefully terminate of the connection with the peer > >> if it chooses to. Otherwise, it must honor its commitment to keep the > >> application support. > >> > > [TOLGA]AFAICS, the moment you introduce some intelligence to > that procedure, > > e.g. receiver of CER aggreing with the application getting > down, you need to > > be sure that you are communicating with your application level > peer. CER/CEA > > is hop-to-hop, it probably won't do it for a generic solution, > where we have > > relay agents etc.. between the endpoints. > > > renegotiation is done between peers (one hope) not between end-points > and the decision on wether to continue support for an application is > local to a node. how a node will deal with not supporting an application > anymore is up to the application itself. [TOLGA]Yes, this is also what I think, but I think thelast sentence of the following passage from the proposed text is contradicting with this: "If the receiver of the CER is unable to comply with the request, it SHOULD send a CEA with the Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY and retain its pre-existing state with its peer. The receiver of the CEA can decide wether to terminate or maintain the connection at the receipt of this result code. If it decides to maintain the connection then it MUST retain its pre-existing connection state with its peer prior sending the CER." _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 17:51:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFuH-0004GI-RS; Wed, 05 Apr 2006 17:51:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFuG-0004G8-Lq for dime@ietf.org; Wed, 05 Apr 2006 17:51:16 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFuF-0007Kr-Cv for dime@ietf.org; Wed, 05 Apr 2006 17:51:16 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k35LpBMs034479; Wed, 5 Apr 2006 17:51:11 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44343BD1.5060503@tari.toshiba.com> Date: Wed, 05 Apr 2006 17:51:13 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] CER/CEA on an open connection References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Comments inline: >>> >> renegotiation is done between peers (one hope) not between end-points >> and the decision on wether to continue support for an application is >> local to a node. how a node will deal with not supporting an application >> anymore is up to the application itself. >> > [TOLGA]Yes, this is also what I think, but I think thelast sentence of the > following passage from the proposed text is contradicting with this: > > "If the receiver of the CER is unable to comply with the request, it SHOULD > send a CEA with the Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY and > retain its pre-existing state with its peer. The receiver of the CEA can > decide wether to terminate or maintain the connection at the receipt of > this result code. If it decides to maintain the connection then it MUST > retain its pre-existing connection state with its peer prior sending the > CER." > how is it contradicting ? CER/CEA are exchanged by peers and application support is decided locally. regards, victor > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 17:59:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRG2B-00088d-5Z; Wed, 05 Apr 2006 17:59:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRG2A-00088Y-AH for dime@ietf.org; Wed, 05 Apr 2006 17:59:26 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRG29-00087n-0q for dime@ietf.org; Wed, 05 Apr 2006 17:59:26 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 249C465815 for ; Wed, 5 Apr 2006 17:59:24 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k35LxM8k011723 for ; Wed, 5 Apr 2006 17:59:22 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] CER/CEA on an open connection Date: Wed, 5 Apr 2006 17:38:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44343BD1.5060503@tari.toshiba.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: unknown X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org "If it decides to maintain the connection then it MUST retain its pre-existing connection state with its peer prior sending the CER." According to the above sentence -or better said based on what I understand from it-, if I support two applications, want to shutdown one, sent corresponding CER and received a negative CEA, I MUST keep pre-existing connection state, i.e. I can't shut down the application. > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Wednesday, April 05, 2006 5:51 PM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] CER/CEA on an open connection > > > Comments inline: > >>> > >> renegotiation is done between peers (one hope) not between end-points > >> and the decision on wether to continue support for an application is > >> local to a node. how a node will deal with not supporting an > application > >> anymore is up to the application itself. > >> > > [TOLGA]Yes, this is also what I think, but I think thelast > sentence of the > > following passage from the proposed text is contradicting with this: > > > > "If the receiver of the CER is unable to comply with the > request, it SHOULD > > send a CEA with the Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY and > > retain its pre-existing state with its peer. The receiver of the CEA can > > decide wether to terminate or maintain the connection at the receipt of > > this result code. If it decides to maintain the connection then it MUST > > retain its pre-existing connection state with its peer prior sending the > > CER." > > > how is it contradicting ? CER/CEA are exchanged by peers and application > support is decided locally. > > regards, > victor > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 18:04:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRG79-000357-PQ; Wed, 05 Apr 2006 18:04:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRG77-00032U-Sd for dime@ietf.org; Wed, 05 Apr 2006 18:04:33 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRG77-0008Js-KO for dime@ietf.org; Wed, 05 Apr 2006 18:04:33 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k35M4UIT034586; Wed, 5 Apr 2006 18:04:30 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44343EF0.5020508@tari.toshiba.com> Date: Wed, 05 Apr 2006 18:04:32 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] CER/CEA on an open connection References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org You understand correctly but I'm trying to understand what is your objection to this sentence if any ... regards, victor > "If it decides to maintain the connection then it MUST retain its > pre-existing connection state with its peer prior sending the CER." > > According to the above sentence -or better said based on what I understand > from it-, if I support two applications, want to shutdown one, sent > corresponding CER and received a negative CEA, I MUST keep pre-existing > connection state, i.e. I can't shut down the application. > > >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: Wednesday, April 05, 2006 5:51 PM >> To: Tolga Asveren >> Cc: dime@ietf.org >> Subject: Re: [Dime] CER/CEA on an open connection >> >> >> Comments inline: >> >>>> renegotiation is done between peers (one hope) not between end-points >>>> and the decision on wether to continue support for an application is >>>> local to a node. how a node will deal with not supporting an >>>> >> application >> >>>> anymore is up to the application itself. >>>> >>>> >>> [TOLGA]Yes, this is also what I think, but I think thelast >>> >> sentence of the >> >>> following passage from the proposed text is contradicting with this: >>> >>> "If the receiver of the CER is unable to comply with the >>> >> request, it SHOULD >> >>> send a CEA with the Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY and >>> retain its pre-existing state with its peer. The receiver of the CEA can >>> decide wether to terminate or maintain the connection at the receipt of >>> this result code. If it decides to maintain the connection then it MUST >>> retain its pre-existing connection state with its peer prior sending the >>> CER." >>> >>> >> how is it contradicting ? CER/CEA are exchanged by peers and application >> support is decided locally. >> >> regards, >> victor >> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> >>> >>> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 22:35:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRKLO-0006Yq-NN; Wed, 05 Apr 2006 22:35:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRKLN-0006Yi-Jn for dime@ietf.org; Wed, 05 Apr 2006 22:35:33 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRKLL-0001wd-Qo for dime@ietf.org; Wed, 05 Apr 2006 22:35:33 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXA00FR14BY55@szxga01-in.huawei.com> for dime@ietf.org; Thu, 06 Apr 2006 10:31:10 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXA00ET84BXMX@szxga01-in.huawei.com> for dime@ietf.org; Thu, 06 Apr 2006 10:31:10 +0800 (CST) Received: from z52447 ([10.164.5.16]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXA00DNS54SMB@szxml01-in.huawei.com> for dime@ietf.org; Thu, 06 Apr 2006 10:48:36 +0800 (CST) Date: Thu, 06 Apr 2006 10:31:08 +0800 From: zou rong To: dime@ietf.org Message-id: <000101c65922$2c9e4d90$1005a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.4 (+) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [Dime] hello,everyone!just a test,please ignore it X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 05 23:12:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRKvI-0005Zh-KQ; Wed, 05 Apr 2006 23:12:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRKvH-0005YC-B4 for dime@ietf.org; Wed, 05 Apr 2006 23:12:39 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRKvF-0003Hc-Tp for dime@ietf.org; Wed, 05 Apr 2006 23:12:39 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k363Bnsx009649; Thu, 6 Apr 2006 06:11:50 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 06:11:54 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 06:11:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] CER/CEA on an open connection Date: Thu, 6 Apr 2006 06:11:54 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB0C9244@esebe100.NOE.Nokia.com> In-Reply-To: <44343545.3090403@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] CER/CEA on an open connection Thread-Index: AcZY9zFMFT+93touTiqyTchkU2SUIAAMJVng From: To: , X-OriginalArrivalTime: 06 Apr 2006 03:11:54.0817 (UTC) FILETIME=[DB852310:01C65927] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, >>> DIAMETER_APPLICATION_UNSUPPORTED. >>> =20 >>> What is proposed is that a node initiating the change=20 >request should=20 >>> not terminate the supported application until the=20 >corresponding peer agrees. >>> If the peer does not agree, the node initiating the change request=20 >>> has an alternative to gracefully terminate of the=20 >connection with the=20 >>> peer if it chooses to. Otherwise, it must honor its commitment to=20 >>> keep the application support. >>> =20 >> [TOLGA]AFAICS, the moment you introduce some intelligence to that=20 >> procedure, e.g. receiver of CER aggreing with the=20 >application getting=20 >> down, you need to be sure that you are communicating with your=20 >> application level peer. CER/CEA is hop-to-hop, it probably=20 >won't do it=20 >> for a generic solution, where we have relay agents etc..=20 >between the endpoints. >> =20 >renegotiation is done between peers (one hope) not between=20 >end-points and the decision on wether to continue support for=20 >an application is local to a node. how a node will deal with=20 >not supporting an application anymore is up to the application itself. I agree with Victor. John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 06 08:07:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTGh-0003VU-Pp; Thu, 06 Apr 2006 08:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9jc-0005HQ-6c for dime@ietf.org; Wed, 05 Apr 2006 11:15:52 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR9ja-0002sm-Fa for dime@ietf.org; Wed, 05 Apr 2006 11:15:52 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k35FEOU1030243; Wed, 5 Apr 2006 18:14:25 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 18:15:42 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 10:15:36 -0500 Received: from 10.241.32.10 ([10.241.32.10]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 5 Apr 2006 15:15:37 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 05 Apr 2006 10:16:27 -0500 From: Basavaraj Patil To: Giaretta Gerardo , Hannes Tschofenig , Message-ID: Thread-Topic: Diameter MIPv6 Thread-Index: AcZYlZRfKQPjyIbZSV6hsB7nRC6nbgAAlSELAAr/6vY= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 05 Apr 2006 15:15:36.0933 (UTC) FILETIME=[CAB47950:01C658C3] X-Spam-Score: 0.1 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 X-Mailman-Approved-At: Thu, 06 Apr 2006 08:07:18 -0400 Cc: Demaria Elena , Gopal Dommety , Guardini Ivano Subject: [Dime] Re: Diameter MIPv6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1108350336==" Errors-To: dime-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1108350336== Content-type: multipart/alternative; boundary="B_3227076987_12542875" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3227076987_12542875 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I agree with Gerardo. We need a single document in DIME. -Raj On 4/5/06 5:01 AM, "ext Giaretta Gerardo" wrote: > > Hi Hannes and John, > > I'm working on a new version of the draft based on comments I received in > Dallas. If you can review the document and have additional comments, please > provide them. I think the draft may be in a good shape by next IETF if there > will be good reviews from MIP6 WG. > > As a side note, the draft will encompass all AAA requirements for MIPv6, both > for AAA-HA and AAA-NAS interface, and both for integrated and split scenario. > Therefore I think we may have one document in DIME WG, since many components > of integrated and split solutions are common. > > Regards, > --Gerardo > > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wed 4/5/2006 11:44 AM > To: dime@ietf.org; rafa@dif.um.es; julien.bournelle@int-evry.fr; Guardini > Ivano; Giaretta Gerardo; Demaria Elena; basavaraj.patil@nokia.com; > gdommety@cisco.com > Subject: Diameter MIPv6 > > Hi all, > > the MIP6 bootstrapping design team has worked on two solutions for > bootstrapping of MIPv6: the integrated and the split scenario > > These two solutions are documented in two separate drafts: > > MIP6-bootstrapping via DHCPv6 for the Integrated Scenario > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated-d > hc-00.txt > > Mobile IPv6 bootstrapping in split scenario > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-02.txt > > As such, there is the question whether the work in DIME should also > produce two separate documents referring to these two bootstrapping > deployment scenarios or whether it would be useful to captures both > scenarios in a single document. > > Thoughts? > > Ciao > Hannes John > > PS: John and myself would also like to know when the MIP6-AAA Goals draft > http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-01.txt > is going to be finalized since the Diameter MIPv6 work depends on this > document. > > > > > > > > -------------------------------------------------------------------- > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please contact us by > replying to webmaster@telecomitalia.it . > Thank you > www.telecomitalia.it > > -------------------------------------------------------------------- > --B_3227076987_12542875 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: Diameter MIPv6
I agree with Gerardo. We need a single document in DIME.

-Raj


On 4/5/06 5:01 AM, "ext Giaretta Gerardo" <gerardo.giaretta@te= lecomitalia.it> wrote:


Hi Hannes and John,

I'm working on a new version of the draft based on comments I received in D= allas. If you can review the document and have additional comments, please p= rovide them. I think the draft may be in a good shape by next IETF if there = will be good reviews from MIP6 WG.

As a side note, the draft will encompass all AAA requirements for MIPv6, bo= th for AAA-HA and AAA-NAS interface, and both for integrated and split scena= rio. Therefore I think we may have one document in DIME WG, since many compo= nents of integrated and split solutions are common.

Regards,
--Gerardo


-----Original Message-----
From: Hannes Tschofenig [mailto= :Hannes.Tschofenig@gmx.net]
Sent: Wed 4/5/2006 11:44 AM
To: dime@ietf.org; rafa@dif.um.es; julien.bournelle@int-evry.fr; Guardini I= vano; Giaretta Gerardo; Demaria Elena; basavaraj.patil@nokia.com; gdommety@c= isco.com
Subject: Diameter MIPv6
 
Hi all,

the MIP6 bootstrapping design team has worked on two solutions for
bootstrapping of MIPv6: the integrated and the split scenario

These two solutions are documented in two separate drafts:

MIP6-bootstrapping via DHCPv6 for the Integrated Scenario
http://www.ietf.org/internet-drafts/draft-ietf-mip6-b= ootstrapping-integrated-dhc-00.txt

Mobile IPv6 bootstrapping in split scenario
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp= ing-split-02.txt

As such, there is the question whether the work in DIME should also
produce two separate documents referring to these two bootstrapping
deployment scenarios or whether it would be useful to captures both
scenarios in a single document.

Thoughts?

Ciao
Hannes  John

PS: John and myself would also like to know when the MIP6-AAA Goals draft http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-01.t= xt
is going to be finalized since the Diameter MIPv6 work depends on this
document.







-----= ---------------------------------------------------------------
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by
replying to webmaster@telecomitalia.it <mailto:webmaster@t= elecomitalia.it> .
        Thank you
            &nb= sp;            &= nbsp;            = ;  www.telecomitalia.it <http://www.telecomitalia.it>= ;
-------------------------------------------= -------------------------


 --B_3227076987_12542875-- --===============1108350336== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1108350336==-- From dime-bounces@ietf.org Thu Apr 06 08:07:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTGh-0003Vu-Tc; Thu, 06 Apr 2006 08:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDBW-0006Jo-58 for dime@ietf.org; Wed, 05 Apr 2006 14:56:54 -0400 Received: from test-iport-2.cisco.com ([171.71.176.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRDA1-0004N6-96 for dime@ietf.org; Wed, 05 Apr 2006 14:55:24 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-2.cisco.com with ESMTP; 05 Apr 2006 11:55:20 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k35ItJw3014190; Wed, 5 Apr 2006 11:55:19 -0700 (PDT) Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Apr 2006 11:55:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Apr 2006 11:55:18 -0700 Message-ID: <28CEA477BE98ED48AF08A0B637A74BF401833303@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter MIPv6 Thread-Index: AcZYlZRfKQPjyIbZSV6hsB7nRC6nbgAAlSELAAr/6vYAB6B8kA== From: "Gopal Dommety \(gdommety\)" To: "Basavaraj Patil" , "Giaretta Gerardo" , "Hannes Tschofenig" , X-OriginalArrivalTime: 05 Apr 2006 18:55:19.0447 (UTC) FILETIME=[7C187A70:01C658E2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 X-Mailman-Approved-At: Thu, 06 Apr 2006 08:07:18 -0400 Cc: Demaria Elena , Guardini Ivano Subject: [Dime] RE: Diameter MIPv6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1730699268==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1730699268== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C658E2.7BE77915" This is a multi-part message in MIME format. ------_=_NextPart_001_01C658E2.7BE77915 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable single document makes sense. Unless there is compelling reason to do otherwise. =20 Thank You, Gopal -------------------------------------------------------- Judgement hinders imagination ---------------------------------------------------------- =20 ________________________________ From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]=20 Sent: Wednesday, April 05, 2006 8:16 AM To: Giaretta Gerardo; Hannes Tschofenig; dime@ietf.org Cc: rafa@dif.um.es; julien.bournelle@int-evry.fr; Guardini Ivano; Demaria Elena; Gopal Dommety (gdommety) Subject: Re: Diameter MIPv6 =09 =09 =09 I agree with Gerardo. We need a single document in DIME. =09 -Raj =09 =09 On 4/5/06 5:01 AM, "ext Giaretta Gerardo" wrote: =09 =09 =09 Hi Hannes and John, =09 I'm working on a new version of the draft based on comments I received in Dallas. If you can review the document and have additional comments, please provide them. I think the draft may be in a good shape by next IETF if there will be good reviews from MIP6 WG. =09 As a side note, the draft will encompass all AAA requirements for MIPv6, both for AAA-HA and AAA-NAS interface, and both for integrated and split scenario. Therefore I think we may have one document in DIME WG, since many components of integrated and split solutions are common. =09 Regards, --Gerardo =09 =09 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Wed 4/5/2006 11:44 AM To: dime@ietf.org; rafa@dif.um.es; julien.bournelle@int-evry.fr; Guardini Ivano; Giaretta Gerardo; Demaria Elena; basavaraj.patil@nokia.com; gdommety@cisco.com Subject: Diameter MIPv6 =20 Hi all, =09 the MIP6 bootstrapping design team has worked on two solutions for=20 bootstrapping of MIPv6: the integrated and the split scenario =09 These two solutions are documented in two separate drafts: =09 MIP6-bootstrapping via DHCPv6 for the Integrated Scenario =09 http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integr ated-dhc-00.txt =09 Mobile IPv6 bootstrapping in split scenario =09 http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- 02.txt =09 As such, there is the question whether the work in DIME should also=20 produce two separate documents referring to these two bootstrapping=20 deployment scenarios or whether it would be useful to captures both=20 scenarios in a single document. =09 Thoughts? =09 Ciao Hannes John =09 PS: John and myself would also like to know when the MIP6-AAA Goals draft =09 http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-01.txt is going to be finalized since the Diameter MIPv6 work depends on this=20 document. =09 =09 =09 =09 =09 =09 =09 =09 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it . Thank you =09 www.telecomitalia.it =20 =09 -------------------------------------------------------------------- =09 =09 =09 =09 ------_=_NextPart_001_01C658E2.7BE77915 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: Diameter MIPv6
single document makes sense. Unless there is compelling = reason to=20 do otherwise.
 
Thank You,
Gopal
--------------------------------------------------------
       Judgement hinders = imagination
---------------------------------------------------= -------
 

From: Basavaraj Patil=20 [mailto:basavaraj.patil@nokia.com]
Sent: Wednesday, April = 05, 2006=20 8:16 AM
To: Giaretta Gerardo; Hannes Tschofenig;=20 dime@ietf.org
Cc: rafa@dif.um.es; = julien.bournelle@int-evry.fr;=20 Guardini Ivano; Demaria Elena; Gopal Dommety = (gdommety)
Subject: Re:=20 Diameter MIPv6


I agree with Gerardo. We need a single = document in=20 DIME.

-Raj


On 4/5/06 5:01 AM, "ext Giaretta Gerardo" = <gerardo.giaretta@telecomitalia.it> wrote:

Hi Hannes and John,

I'm working = on a new=20 version of the draft based on comments I received in Dallas. If you = can=20 review the document and have additional comments, please provide = them. I=20 think the draft may be in a good shape by next IETF if there will be = good=20 reviews from MIP6 WG.

As a side note, the draft will = encompass all=20 AAA requirements for MIPv6, both for AAA-HA and AAA-NAS interface, = and both=20 for integrated and split scenario. Therefore I think we may have one = document in DIME WG, since many components of integrated and split = solutions=20 are common.

Regards,
--Gerardo


-----Original=20 Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.n= et]
Sent:=20 Wed 4/5/2006 11:44 AM
To: dime@ietf.org; rafa@dif.um.es;=20 julien.bournelle@int-evry.fr; Guardini Ivano; Giaretta Gerardo; = Demaria=20 Elena; basavaraj.patil@nokia.com; gdommety@cisco.com
Subject: = Diameter=20 MIPv6
 
Hi all,

the MIP6 bootstrapping design team = has=20 worked on two solutions for
bootstrapping of MIPv6: the = integrated and=20 the split scenario

These two solutions are documented in two = separate=20 drafts:

MIP6-bootstrapping via DHCPv6 for the Integrated=20 Scenario
http://www.ietf.org/internet-drafts/draft-ietf-mi= p6-bootstrapping-integrated-dhc-00.txt

Mobile=20 IPv6 bootstrapping in split scenario
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootst= rapping-split-02.txt

As=20 such, there is the question whether the work in DIME should also =
produce=20 two separate documents referring to these two bootstrapping =
deployment=20 scenarios or whether it would be useful to captures both =
scenarios in a=20 single document.

Thoughts?

Ciao
Hannes=20  John

PS: John and myself would also like to know when = the=20 MIP6-AAA Goals draft
http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-= 01.txt
is=20 going to be finalized since the Diameter MIPv6 work depends on this=20
document.







--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to = the=20 persons
above and may contain confidential information. If you = have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender = and=20 delete
the message. Should you have any questions, please contact = us=20 by
replying to webmaster@telecomitalia.it <mailto:webmaster@telecomit= alia.it>=20 .
        Thank=20 = you
           =             &= nbsp;           &n= bsp;    www.telecomitalia.it <http://www.telecomitalia.it><= /A>=20
--------------------------------------------------------------------=


------_=_NextPart_001_01C658E2.7BE77915-- --===============1730699268== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1730699268==-- From dime-bounces@ietf.org Thu Apr 06 08:36:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTj5-0007rh-2L; Thu, 06 Apr 2006 08:36:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTj3-0007rc-RM for dime@ietf.org; Thu, 06 Apr 2006 08:36:37 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRTj3-0006xf-GU for dime@ietf.org; Thu, 06 Apr 2006 08:36:37 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 631BDE5862 for ; Thu, 6 Apr 2006 08:36:37 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k36CaZfL004267 for ; Thu, 6 Apr 2006 08:36:36 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] CER/CEA on an open connection Date: Thu, 6 Apr 2006 08:15:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44343EF0.5020508@tari.toshiba.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This sentence I quoted does not allow the owner of the application to shut it down, if the CEA result code is DIAMETER_UNABLE_TO_COMPLY. I asked you whether this error code will be used for a generic purpose, and your reply was yes, which means it does not necessarily mean that both sides issued CER simultaneously. I furthermore asked whether "pre-existing connection state" includes set of supported applications, your reply was again yes. OTOH, we want to decide for application support locally, but according to the above statements rather than being a local decision it requires more an agreement between two nodes, e.g. if CEA has result code=DIAMETER_UNABLE_TO_COMPLY *for some reason*, issuer of CER shouldn't shutdown the application. And one idea for the simultaneous CER case: Is this serialization really necessary or is it enough to kill one of the negotiations? The CER/CEA for the first completed renegotiation transaction will contain anyhow the supported application sets for both sides. Why do we need the second one? > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Wednesday, April 05, 2006 6:05 PM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] CER/CEA on an open connection > > > You understand correctly but I'm trying to understand what is your > objection to this sentence if any ... > regards, > victor > > "If it decides to maintain the connection then it MUST retain its > > pre-existing connection state with its peer prior sending the CER." > > > > According to the above sentence -or better said based on what I > understand > > from it-, if I support two applications, want to shutdown one, sent > > corresponding CER and received a negative CEA, I MUST keep pre-existing > > connection state, i.e. I can't shut down the application. > > > > > >> -----Original Message----- > >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > >> Sent: Wednesday, April 05, 2006 5:51 PM > >> To: Tolga Asveren > >> Cc: dime@ietf.org > >> Subject: Re: [Dime] CER/CEA on an open connection > >> > >> > >> Comments inline: > >> > >>>> renegotiation is done between peers (one hope) not between end-points > >>>> and the decision on wether to continue support for an application is > >>>> local to a node. how a node will deal with not supporting an > >>>> > >> application > >> > >>>> anymore is up to the application itself. > >>>> > >>>> > >>> [TOLGA]Yes, this is also what I think, but I think thelast > >>> > >> sentence of the > >> > >>> following passage from the proposed text is contradicting with this: > >>> > >>> "If the receiver of the CER is unable to comply with the > >>> > >> request, it SHOULD > >> > >>> send a CEA with the Result-Code AVP set to > DIAMETER_UNABLE_TO_COMPLY and > >>> retain its pre-existing state with its peer. The receiver of > the CEA can > >>> decide wether to terminate or maintain the connection at the > receipt of > >>> this result code. If it decides to maintain the connection > then it MUST > >>> retain its pre-existing connection state with its peer prior > sending the > >>> CER." > >>> > >>> > >> how is it contradicting ? CER/CEA are exchanged by peers and > application > >> support is decided locally. > >> > >> regards, > >> victor > >> > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/dime > >>> > >>> > >>> > >>> > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 06 08:45:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTrX-00014H-Li; Thu, 06 Apr 2006 08:45:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTrW-00014C-JB for dime@ietf.org; Thu, 06 Apr 2006 08:45:22 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRTrV-00073Q-67 for dime@ietf.org; Thu, 06 Apr 2006 08:45:22 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 08C498147; Thu, 6 Apr 2006 14:45:18 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FRTnY-0000fc-BH; Thu, 06 Apr 2006 14:41:16 +0200 Date: Thu, 6 Apr 2006 14:41:16 +0200 From: Julien Bournelle To: Julien Bournelle Message-ID: <20060406124116.GA2571@ipv6-3.int-evry.fr> References: <5D25AEFB114D034FBDC8B156FCA78E03BFB265@SEHAN021MB.tcad.telia.se> <44339185.9080904@gmx.net> <20060405104226.GA797@ipv6-3.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060405104226.GA797@ipv6-3.int-evry.fr> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: gdommety@cisco.com, elena.demaria@tilab.com, basavaraj.patil@nokia.com, gerardo.giaretta@tilab.com, dime@ietf.org, ivano.guardini@tilab.com Subject: [Dime] Re: Diameter MIPv6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, For the Integrated scenario we need to: - define AVPs (HA) - explain where to put it in the Diameter EAP/NASREQ exchanges (between NAS and the AAA) - probably require a Application-ID for that the NAS announces to the AAA that it support the Integrated case. For the split scenario, we need to: - explain how the HA uses Diameter EAP. (HA uses IKEv2 with MN) - maybe some issues may raised after investigation (do the HA need to tell to the AAA that it is a HA and not a NAS ? this sort of things). So at this point of time, I think it would be better to investigate this separately and see later if it makes sense to merge the documents. I don't really see the advantage of having one document for the moment. Regards, Julien B. On Wed, Apr 05, 2006 at 12:42:26PM +0200, Julien Bournelle wrote: > Hi all, > > On Wed, Apr 05, 2006 at 11:44:37AM +0200, Hannes Tschofenig wrote: > > Hi all, > > > > the MIP6 bootstrapping design team has worked on two solutions for > > bootstrapping of MIPv6: the integrated and the split scenario > > > > These two solutions are documented in two separate drafts: > > > > MIP6-bootstrapping via DHCPv6 for the Integrated Scenario > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt > > > > Mobile IPv6 bootstrapping in split scenario > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-02.txt > > > > As such, there is the question whether the work in DIME should also > > produce two separate documents referring to these two bootstrapping > > deployment scenarios or whether it would be useful to captures both > > scenarios in a single document. > > > > Thoughts? > > I would prefer two documents. I have two reasons for this: > > 1/ In the integrated scenario, the AAA is used between NAS and AAA. The > HA address is delivered from the AAA to the NAS and thus NASREQ or EAP > may be in used. > > In the split scenario, Diameter is used between HA and the AAA. And > the AAA does not deliver the HA to the HA... > > > 2/ From an implementation perspective, it would be easier to have a > specific document for each case. > > Julien B. > > > > > Ciao > > Hannes & John > > > > PS: John and myself would also like to know when the MIP6-AAA Goals draft > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-01.txt > > is going to be finalized since the Diameter MIPv6 work depends on this > > document. > > -- > julien.bournelle at int-evry.fr -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 06 08:54:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRU0Q-0006a9-Uf; Thu, 06 Apr 2006 08:54:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRU0P-0006Ti-7V for dime@ietf.org; Thu, 06 Apr 2006 08:54:33 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRU0O-0007Ap-Ir for dime@ietf.org; Thu, 06 Apr 2006 08:54:33 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k36CsTxP004100; Thu, 6 Apr 2006 14:54:29 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k36CsSlM011509; Thu, 6 Apr 2006 14:54:28 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 14:54:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Dime] Re: Diameter MIPv6 Date: Thu, 6 Apr 2006 14:52:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: Diameter MIPv6 Thread-Index: AcZZd/2eMuITu6okTAaMHZFX5wX8JAAAOr0A From: "Tschofenig, Hannes" To: "Julien Bournelle" X-OriginalArrivalTime: 06 Apr 2006 12:54:28.0273 (UTC) FILETIME=[3D674210:01C65979] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: gdommety@cisco.com, elena.demaria@tilab.com, basavaraj.patil@nokia.com, gerardo.giaretta@tilab.com, dime@ietf.org, ivano.guardini@tilab.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien,=20 this is my impression was well. Working on the document I got the = impression that they are sufficiently different in order to deal with = the bootstrapping solutions in a separate document.=20 Ciao Hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 > Gesendet: Donnerstag, 6. April 2006 14:41 > An: Julien Bournelle > Cc: gdommety@cisco.com; elena.demaria@tilab.com;=20 > basavaraj.patil@nokia.com; gerardo.giaretta@tilab.com;=20 > dime@ietf.org; ivano.guardini@tilab.com > Betreff: [Dime] Re: Diameter MIPv6 >=20 > Hi all, >=20 > For the Integrated scenario we need to: > - define AVPs (HA) > - explain where to put it in the Diameter EAP/NASREQ=20 > exchanges (between > NAS and the AAA) > - probably require a Application-ID for that the NAS announces to the > AAA that it support the Integrated case. >=20 > For the split scenario, we need to: > - explain how the HA uses Diameter EAP. (HA uses IKEv2 with MN)=20 > - maybe some issues may raised after investigation (do the HA need to > tell to the AAA that it is a HA and not a NAS ? this sort=20 > of things). >=20 > So at this point of time, I think it would be better to investigate > this separately and see later if it makes sense to merge the=20 > documents. > I don't really see the advantage of having one document for=20 > the moment. >=20 > Regards, >=20 > Julien B. >=20 > On Wed, Apr 05, 2006 at 12:42:26PM +0200, Julien Bournelle wrote: > > Hi all, > >=20 > > On Wed, Apr 05, 2006 at 11:44:37AM +0200, Hannes Tschofenig wrote: > > > Hi all, > > >=20 > > > the MIP6 bootstrapping design team has worked on two=20 > solutions for=20 > > > bootstrapping of MIPv6: the integrated and the split scenario > > >=20 > > > These two solutions are documented in two separate drafts: > > >=20 > > > MIP6-bootstrapping via DHCPv6 for the Integrated Scenario > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > ing-integrated-dhc-00.txt > > >=20 > > > Mobile IPv6 bootstrapping in split scenario > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > ing-split-02.txt > > >=20 > > > As such, there is the question whether the work in DIME=20 > should also=20 > > > produce two separate documents referring to these two=20 > bootstrapping=20 > > > deployment scenarios or whether it would be useful to=20 > captures both=20 > > > scenarios in a single document. > > >=20 > > > Thoughts? > >=20 > > I would prefer two documents. I have two reasons for this: > >=20 > > 1/ In the integrated scenario, the AAA is used between NAS=20 > and AAA. The > > HA address is delivered from the AAA to the NAS and thus=20 > NASREQ or EAP > > may be in used. > >=20 > > In the split scenario, Diameter is used between HA and=20 > the AAA. And > > the AAA does not deliver the HA to the HA... > >=20 > >=20 > > 2/ From an implementation perspective, it would be easier to have a > > specific document for each case. > >=20 > > Julien B. > >=20 > > >=20 > > > Ciao > > > Hannes & John > > >=20 > > > PS: John and myself would also like to know when the=20 > MIP6-AAA Goals draft > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goa > ls-01.txt > > > is going to be finalized since the Diameter MIPv6 work=20 > depends on this=20 > > > document. > >=20 > > --=20 > > julien.bournelle at int-evry.fr >=20 > --=20 > julien.bournelle at int-evry.fr >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 06 08:59:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRU4i-0000Ox-UE; Thu, 06 Apr 2006 08:59:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRU4h-0000Os-Hz for dime@ietf.org; Thu, 06 Apr 2006 08:58:59 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRU4h-0007N5-2T for dime@ietf.org; Thu, 06 Apr 2006 08:58:59 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 14:58:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re: Diameter MIPv6 Date: Thu, 6 Apr 2006 14:58:50 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03BFB31E@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: Diameter MIPv6 Thread-Index: AcZZd/2eMuITu6okTAaMHZFX5wX8JAAAOr0AAAAhmAA= From: To: , X-OriginalArrivalTime: 06 Apr 2006 12:58:57.0677 (UTC) FILETIME=[DDFB0BD0:01C65979] X-Spam-Score: 0.2 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: gdommety@cisco.com, elena.demaria@tilab.com, basavaraj.patil@nokia.com, gerardo.giaretta@tilab.com, dime@ietf.org, ivano.guardini@tilab.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I would also go for two different documents because of the differences in solution approaches and for the general clarity. Cheers, Jouni > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > Sent: 6. huhtikuuta 2006 15:53 > To: Julien Bournelle > Cc: gdommety@cisco.com; elena.demaria@tilab.com;=20 > basavaraj.patil@nokia.com; gerardo.giaretta@tilab.com;=20 > dime@ietf.org; ivano.guardini@tilab.com > Subject: AW: [Dime] Re: Diameter MIPv6 >=20 > Hi Julien,=20 >=20 > this is my impression was well. Working on the document I got=20 > the impression that they are sufficiently different in order=20 > to deal with the bootstrapping solutions in a separate document.=20 >=20 > Ciao > Hannes > =20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 > > Gesendet: Donnerstag, 6. April 2006 14:41 > > An: Julien Bournelle > > Cc: gdommety@cisco.com; elena.demaria@tilab.com;=20 > > basavaraj.patil@nokia.com; gerardo.giaretta@tilab.com;=20 > > dime@ietf.org; ivano.guardini@tilab.com > > Betreff: [Dime] Re: Diameter MIPv6 > >=20 > > Hi all, > >=20 > > For the Integrated scenario we need to: > > - define AVPs (HA) > > - explain where to put it in the Diameter EAP/NASREQ=20 > > exchanges (between > > NAS and the AAA) > > - probably require a Application-ID for that the NAS=20 > announces to the > > AAA that it support the Integrated case. > >=20 > > For the split scenario, we need to: > > - explain how the HA uses Diameter EAP. (HA uses IKEv2 with MN)=20 > > - maybe some issues may raised after investigation (do the=20 > HA need to > > tell to the AAA that it is a HA and not a NAS ? this sort=20 > > of things). > >=20 > > So at this point of time, I think it would be better to investigate > > this separately and see later if it makes sense to merge the=20 > > documents. > > I don't really see the advantage of having one document for=20 > > the moment. > >=20 > > Regards, > >=20 > > Julien B. > >=20 > > On Wed, Apr 05, 2006 at 12:42:26PM +0200, Julien Bournelle wrote: > > > Hi all, > > >=20 > > > On Wed, Apr 05, 2006 at 11:44:37AM +0200, Hannes Tschofenig wrote: > > > > Hi all, > > > >=20 > > > > the MIP6 bootstrapping design team has worked on two=20 > > solutions for=20 > > > > bootstrapping of MIPv6: the integrated and the split scenario > > > >=20 > > > > These two solutions are documented in two separate drafts: > > > >=20 > > > > MIP6-bootstrapping via DHCPv6 for the Integrated Scenario > > > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > > ing-integrated-dhc-00.txt > > > >=20 > > > > Mobile IPv6 bootstrapping in split scenario > > > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > > ing-split-02.txt > > > >=20 > > > > As such, there is the question whether the work in DIME=20 > > should also=20 > > > > produce two separate documents referring to these two=20 > > bootstrapping=20 > > > > deployment scenarios or whether it would be useful to=20 > > captures both=20 > > > > scenarios in a single document. > > > >=20 > > > > Thoughts? > > >=20 > > > I would prefer two documents. I have two reasons for this: > > >=20 > > > 1/ In the integrated scenario, the AAA is used between NAS=20 > > and AAA. The > > > HA address is delivered from the AAA to the NAS and thus=20 > > NASREQ or EAP > > > may be in used. > > >=20 > > > In the split scenario, Diameter is used between HA and=20 > > the AAA. And > > > the AAA does not deliver the HA to the HA... > > >=20 > > >=20 > > > 2/ From an implementation perspective, it would be=20 > easier to have a > > > specific document for each case. > > >=20 > > > Julien B. > > >=20 > > > >=20 > > > > Ciao > > > > Hannes & John > > > >=20 > > > > PS: John and myself would also like to know when the=20 > > MIP6-AAA Goals draft > > > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goa > > ls-01.txt > > > > is going to be finalized since the Diameter MIPv6 work=20 > > depends on this=20 > > > > document. > > >=20 > > > --=20 > > > julien.bournelle at int-evry.fr > >=20 > > --=20 > > julien.bournelle at int-evry.fr > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 06 09:13:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRUIM-0003fd-NH; Thu, 06 Apr 2006 09:13:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRUIL-0003fY-TI for dime@ietf.org; Thu, 06 Apr 2006 09:13:05 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRUIK-0007z4-Kc for dime@ietf.org; Thu, 06 Apr 2006 09:13:05 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 9436BA85BF for ; Thu, 6 Apr 2006 09:13:04 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k36DD3SG007234 for ; Thu, 6 Apr 2006 09:13:03 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] CER/CEA on an open connection Date: Thu, 6 Apr 2006 08:52:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org > And one idea for the simultaneous CER case: > Is this serialization really necessary or is it enough to kill one of the > negotiations? The CER/CEA for the first completed renegotiation > transaction > will contain anyhow the supported application sets for both > sides. Why do we > need the second one? [TOLGA]A further idea for this one: Considering that application support decision is local, why do we care about simultaneous CERs at all? Each of them will advertise the supported application set for both sides at that moment. What is wrong with that? _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 06 19:54:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FReJ2-0002zA-0i; Thu, 06 Apr 2006 19:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FReJ0-0002z4-VZ for dime@ietf.org; Thu, 06 Apr 2006 19:54:26 -0400 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FReIy-0004A6-18 for dime@ietf.org; Thu, 06 Apr 2006 19:54:26 -0400 Received: from FLY ([129.254.1.8]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 08:57:03 +0900 Message-ID: <001001c659d5$719082c0$0201a8c0@FLY> From: "Junghoon Jee" To: , , References: <5D25AEFB114D034FBDC8B156FCA78E03BFB31E@SEHAN021MB.tcad.telia.se> Subject: Re: [Dime] Re: Diameter MIPv6 Date: Fri, 7 Apr 2006 08:54:22 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-OriginalArrivalTime: 06 Apr 2006 23:57:03.0831 (UTC) FILETIME=[CD8FFE70:01C659D5] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: gdommety@cisco.com, elena.demaria@tilab.com, basavaraj.patil@nokia.com, gerardo.giaretta@tilab.com, dime@ietf.org, ivano.guardini@tilab.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1614049262==" Errors-To: dime-bounces@ietf.org --===============1614049262== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJJ2Qgc3VnZ2VzdCB0byBoYXZpbmcgX3R3b18gRElNRSBkcmFmdHMgZm9yIGlu dGVncmF0ZWQgYW5kIHNwbGl0IGNhc2UNCmJlY2F1c2UgdGhlIG92ZXJhbGwgYm9vdHN0cmFwcGlu ZyBwcm9jZWR1cmVzIGFyZSBkaWZmZXJlbnQgaW4gZWFjaCBjYXNlLg0KUGxlYXNlIHRha2UgYSBs b29rIGF0IHRoZSBjdXJyZW50IHN1Z2dlc3RlZCBkcmFmdHMgZnJvbSBIYW5uZXMsDQp0aGVuIG1p Z2h0IGJlIGluIHRoZSBzYW1lIGxpbmUgd2l0aCBtZS4gICA6LSkNCg0KQXMgYSBzaWRlIG5vdGU6 IA0KTGlzdGluZyB1cCBBQUEgcmVxdWlyZW1lbnRzIHRocm91Z2ggX3NpbmdsZV8gZG9jdW1lbnQg aXMgc3RpbGwgdmFsaWQNCmFzIEkgbWVudGlvbmVkIGluIHRoZSBwcmV2aW91cyBNSVA2IFdHIG1l ZXRpbmcuDQoNClRoYW5rcywNCi1KdW5naG9vbg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tIA0KRnJvbTogPGpvdW5pLmtvcmhvbmVuQHRlbGlhc29uZXJhLmNvbT4NClRvOiA8aGFubmVz LnRzY2hvZmVuaWdAc2llbWVucy5jb20+OyA8anVsaWVuLmJvdXJuZWxsZUBpbnQtZXZyeS5mcj4N CkNjOiA8Z2RvbW1ldHlAY2lzY28uY29tPjsgPGVsZW5hLmRlbWFyaWFAdGlsYWIuY29tPjsgPGJh c2F2YXJhai5wYXRpbEBub2tpYS5jb20+OyA8Z2VyYXJkby5naWFyZXR0YUB0aWxhYi5jb20+OyA8 ZGltZUBpZXRmLm9yZz47IDxpdmFuby5ndWFyZGluaUB0aWxhYi5jb20+DQpTZW50OiBUaHVyc2Rh eSwgQXByaWwgMDYsIDIwMDYgOTo1OCBQTQ0KU3ViamVjdDogUkU6IFtEaW1lXSBSZTogRGlhbWV0 ZXIgTUlQdjYNCg0KDQoNCkkgd291bGQgYWxzbyBnbyBmb3IgdHdvIGRpZmZlcmVudCBkb2N1bWVu dHMgYmVjYXVzZSBvZiB0aGUNCmRpZmZlcmVuY2VzIGluIHNvbHV0aW9uIGFwcHJvYWNoZXMgYW5k IGZvciB0aGUgZ2VuZXJhbA0KY2xhcml0eS4NCg0KQ2hlZXJzLA0KSm91bmkNCg0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRzY2hvZmVuaWcsIEhhbm5lcyBbbWFpbHRv Omhhbm5lcy50c2Nob2ZlbmlnQHNpZW1lbnMuY29tXSANCj4gU2VudDogNi4gaHVodGlrdXV0YSAy MDA2IDE1OjUzDQo+IFRvOiBKdWxpZW4gQm91cm5lbGxlDQo+IENjOiBnZG9tbWV0eUBjaXNjby5j b207IGVsZW5hLmRlbWFyaWFAdGlsYWIuY29tOyANCj4gYmFzYXZhcmFqLnBhdGlsQG5va2lhLmNv bTsgZ2VyYXJkby5naWFyZXR0YUB0aWxhYi5jb207IA0KPiBkaW1lQGlldGYub3JnOyBpdmFuby5n dWFyZGluaUB0aWxhYi5jb20NCj4gU3ViamVjdDogQVc6IFtEaW1lXSBSZTogRGlhbWV0ZXIgTUlQ djYNCj4gDQo+IEhpIEp1bGllbiwgDQo+IA0KPiB0aGlzIGlzIG15IGltcHJlc3Npb24gd2FzIHdl bGwuIFdvcmtpbmcgb24gdGhlIGRvY3VtZW50IEkgZ290IA0KPiB0aGUgaW1wcmVzc2lvbiB0aGF0 IHRoZXkgYXJlIHN1ZmZpY2llbnRseSBkaWZmZXJlbnQgaW4gb3JkZXIgDQo+IHRvIGRlYWwgd2l0 aCB0aGUgYm9vdHN0cmFwcGluZyBzb2x1dGlvbnMgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudC4gDQo+ IA0KPiBDaWFvDQo+IEhhbm5lcw0KPiAgDQo+IA0KPiA+IC0tLS0tVXJzcHL8bmdsaWNoZSBOYWNo cmljaHQtLS0tLQ0KPiA+IFZvbjogSnVsaWVuIEJvdXJuZWxsZSBbbWFpbHRvOmp1bGllbi5ib3Vy bmVsbGVAaW50LWV2cnkuZnJdIA0KPiA+IEdlc2VuZGV0OiBEb25uZXJzdGFnLCA2LiBBcHJpbCAy MDA2IDE0OjQxDQo+ID4gQW46IEp1bGllbiBCb3VybmVsbGUNCj4gPiBDYzogZ2RvbW1ldHlAY2lz Y28uY29tOyBlbGVuYS5kZW1hcmlhQHRpbGFiLmNvbTsgDQo+ID4gYmFzYXZhcmFqLnBhdGlsQG5v a2lhLmNvbTsgZ2VyYXJkby5naWFyZXR0YUB0aWxhYi5jb207IA0KPiA+IGRpbWVAaWV0Zi5vcmc7 IGl2YW5vLmd1YXJkaW5pQHRpbGFiLmNvbQ0KPiA+IEJldHJlZmY6IFtEaW1lXSBSZTogRGlhbWV0 ZXIgTUlQdjYNCj4gPiANCj4gPiBIaSBhbGwsDQo+ID4gDQo+ID4gIEZvciB0aGUgSW50ZWdyYXRl ZCBzY2VuYXJpbyB3ZSBuZWVkIHRvOg0KPiA+ICAtIGRlZmluZSBBVlBzIChIQSkNCj4gPiAgLSBl eHBsYWluIHdoZXJlIHRvIHB1dCBpdCBpbiB0aGUgRGlhbWV0ZXIgRUFQL05BU1JFUSANCj4gPiBl eGNoYW5nZXMgKGJldHdlZW4NCj4gPiAgICBOQVMgYW5kIHRoZSBBQUEpDQo+ID4gIC0gcHJvYmFi bHkgcmVxdWlyZSBhIEFwcGxpY2F0aW9uLUlEIGZvciB0aGF0IHRoZSBOQVMgDQo+IGFubm91bmNl cyB0byB0aGUNCj4gPiAgICBBQUEgdGhhdCBpdCBzdXBwb3J0IHRoZSBJbnRlZ3JhdGVkIGNhc2Uu DQo+ID4gDQo+ID4gIEZvciB0aGUgc3BsaXQgc2NlbmFyaW8sIHdlIG5lZWQgdG86DQo+ID4gIC0g ZXhwbGFpbiBob3cgdGhlIEhBIHVzZXMgRGlhbWV0ZXIgRUFQLiAoSEEgdXNlcyBJS0V2MiB3aXRo IE1OKSANCj4gPiAgLSBtYXliZSBzb21lIGlzc3VlcyBtYXkgcmFpc2VkIGFmdGVyIGludmVzdGln YXRpb24gKGRvIHRoZSANCj4gSEEgbmVlZCB0bw0KPiA+ICAgIHRlbGwgdG8gdGhlIEFBQSB0aGF0 IGl0IGlzIGEgSEEgYW5kIG5vdCBhIE5BUyA/IHRoaXMgc29ydCANCj4gPiBvZiB0aGluZ3MpLg0K PiA+IA0KPiA+ICBTbyBhdCB0aGlzIHBvaW50IG9mIHRpbWUsIEkgdGhpbmsgaXQgd291bGQgYmUg YmV0dGVyIHRvIGludmVzdGlnYXRlDQo+ID4gIHRoaXMgc2VwYXJhdGVseSBhbmQgc2VlIGxhdGVy IGlmIGl0IG1ha2VzIHNlbnNlIHRvIG1lcmdlIHRoZSANCj4gPiBkb2N1bWVudHMuDQo+ID4gIEkg ZG9uJ3QgcmVhbGx5IHNlZSB0aGUgYWR2YW50YWdlIG9mIGhhdmluZyBvbmUgZG9jdW1lbnQgZm9y IA0KPiA+IHRoZSBtb21lbnQuDQo+ID4gDQo+ID4gIFJlZ2FyZHMsDQo+ID4gDQo+ID4gIEp1bGll biBCLg0KPiA+IA0KPiA+IE9uIFdlZCwgQXByIDA1LCAyMDA2IGF0IDEyOjQyOjI2UE0gKzAyMDAs IEp1bGllbiBCb3VybmVsbGUgd3JvdGU6DQo+ID4gPiBIaSBhbGwsDQo+ID4gPiANCj4gPiA+IE9u IFdlZCwgQXByIDA1LCAyMDA2IGF0IDExOjQ0OjM3QU0gKzAyMDAsIEhhbm5lcyBUc2Nob2Zlbmln IHdyb3RlOg0KPiA+ID4gPiBIaSBhbGwsDQo+ID4gPiA+IA0KPiA+ID4gPiB0aGUgTUlQNiBib290 c3RyYXBwaW5nIGRlc2lnbiB0ZWFtIGhhcyB3b3JrZWQgb24gdHdvIA0KPiA+IHNvbHV0aW9ucyBm b3IgDQo+ID4gPiA+IGJvb3RzdHJhcHBpbmcgb2YgTUlQdjY6IHRoZSBpbnRlZ3JhdGVkIGFuZCB0 aGUgc3BsaXQgc2NlbmFyaW8NCj4gPiA+ID4gDQo+ID4gPiA+IFRoZXNlIHR3byBzb2x1dGlvbnMg YXJlIGRvY3VtZW50ZWQgaW4gdHdvIHNlcGFyYXRlIGRyYWZ0czoNCj4gPiA+ID4gDQo+ID4gPiA+ IE1JUDYtYm9vdHN0cmFwcGluZyB2aWEgREhDUHY2IGZvciB0aGUgSW50ZWdyYXRlZCBTY2VuYXJp bw0KPiA+ID4gPiANCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1pZXRmLW1pcDYtYm9vdHN0cmFwcA0KPiA+IGluZy1pbnRlZ3JhdGVkLWRoYy0wMC50eHQNCj4g PiA+ID4gDQo+ID4gPiA+IE1vYmlsZSBJUHY2IGJvb3RzdHJhcHBpbmcgaW4gc3BsaXQgc2NlbmFy aW8NCj4gPiA+ID4gDQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtaWV0Zi1taXA2LWJvb3RzdHJhcHANCj4gPiBpbmctc3BsaXQtMDIudHh0DQo+ID4gPiA+IA0K PiA+ID4gPiBBcyBzdWNoLCB0aGVyZSBpcyB0aGUgcXVlc3Rpb24gd2hldGhlciB0aGUgd29yayBp biBESU1FIA0KPiA+IHNob3VsZCBhbHNvIA0KPiA+ID4gPiBwcm9kdWNlIHR3byBzZXBhcmF0ZSBk b2N1bWVudHMgcmVmZXJyaW5nIHRvIHRoZXNlIHR3byANCj4gPiBib290c3RyYXBwaW5nIA0KPiA+ ID4gPiBkZXBsb3ltZW50IHNjZW5hcmlvcyBvciB3aGV0aGVyIGl0IHdvdWxkIGJlIHVzZWZ1bCB0 byANCj4gPiBjYXB0dXJlcyBib3RoIA0KPiA+ID4gPiBzY2VuYXJpb3MgaW4gYSBzaW5nbGUgZG9j dW1lbnQuDQo+ID4gPiA+IA0KPiA+ID4gPiBUaG91Z2h0cz8NCj4gPiA+IA0KPiA+ID4gIEkgd291 bGQgcHJlZmVyIHR3byBkb2N1bWVudHMuIEkgaGF2ZSB0d28gcmVhc29ucyBmb3IgdGhpczoNCj4g PiA+IA0KPiA+ID4gIDEvIEluIHRoZSBpbnRlZ3JhdGVkIHNjZW5hcmlvLCB0aGUgQUFBIGlzIHVz ZWQgYmV0d2VlbiBOQVMgDQo+ID4gYW5kIEFBQS4gVGhlDQo+ID4gPiAgSEEgYWRkcmVzcyBpcyBk ZWxpdmVyZWQgZnJvbSB0aGUgQUFBIHRvIHRoZSBOQVMgYW5kIHRodXMgDQo+ID4gTkFTUkVRIG9y IEVBUA0KPiA+ID4gIG1heSBiZSBpbiB1c2VkLg0KPiA+ID4gDQo+ID4gPiAgIEluIHRoZSBzcGxp dCBzY2VuYXJpbywgRGlhbWV0ZXIgaXMgdXNlZCBiZXR3ZWVuIEhBIGFuZCANCj4gPiB0aGUgQUFB LiBBbmQNCj4gPiA+ICAgdGhlIEFBQSBkb2VzIG5vdCBkZWxpdmVyIHRoZSBIQSB0byB0aGUgSEEu Li4NCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiAgMi8gRnJvbSBhbiBpbXBsZW1lbnRhdGlvbiBwZXJz cGVjdGl2ZSwgaXQgd291bGQgYmUgDQo+IGVhc2llciB0byBoYXZlIGENCj4gPiA+ICBzcGVjaWZp YyBkb2N1bWVudCBmb3IgZWFjaCBjYXNlLg0KPiA+ID4gDQo+ID4gPiAgSnVsaWVuIEIuDQo+ID4g PiANCj4gPiA+ID4gDQo+ID4gPiA+IENpYW8NCj4gPiA+ID4gSGFubmVzICYgSm9obg0KPiA+ID4g PiANCj4gPiA+ID4gUFM6IEpvaG4gYW5kIG15c2VsZiB3b3VsZCBhbHNvIGxpa2UgdG8ga25vdyB3 aGVuIHRoZSANCj4gPiBNSVA2LUFBQSBHb2FscyBkcmFmdA0KPiA+ID4gPiANCj4gPiBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1pcDYtYWFhLWhhLWdvYQ0K PiA+IGxzLTAxLnR4dA0KPiA+ID4gPiBpcyBnb2luZyB0byBiZSBmaW5hbGl6ZWQgc2luY2UgdGhl IERpYW1ldGVyIE1JUHY2IHdvcmsgDQo+ID4gZGVwZW5kcyBvbiB0aGlzIA0KPiA+ID4gPiBkb2N1 bWVudC4NCj4gPiA+IA0KPiA+ID4gLS0gDQo+ID4gPiBqdWxpZW4uYm91cm5lbGxlIGF0IGludC1l dnJ5LmZyDQo+ID4gDQo+ID4gLS0gDQo+ID4ganVsaWVuLmJvdXJuZWxsZSBhdCBpbnQtZXZyeS5m cg0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gPiBEaU1FQGlldGYub3JnDQo+ID4gaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KPiA+IA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRGlNRSBtYWlsaW5n IGxpc3QNCj4gRGlNRUBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kaW1lDQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU= --===============1614049262== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1614049262==-- From dime-bounces@ietf.org Fri Apr 07 05:21:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnA3-0005wl-93; Fri, 07 Apr 2006 05:21:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnA1-0005wb-86 for dime@ietf.org; Fri, 07 Apr 2006 05:21:45 -0400 Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRn9y-0005gB-Vq for dime@ietf.org; Fri, 07 Apr 2006 05:21:45 -0400 Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 11:21:41 +0200 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.228]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Apr 2006 11:21:40 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Re: Diameter MIPv6 Date: Fri, 7 Apr 2006 11:21:23 +0200 Message-ID: Importance: normal Priority: normal X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: Diameter MIPv6 thread-index: AcZZ1XDirK/7jFmTTj++yS6+a1KIcQATleeQ From: "Giaretta Gerardo" To: "Junghoon Jee" , , , X-OriginalArrivalTime: 07 Apr 2006 09:21:40.0634 (UTC) FILETIME=[ADB5E7A0:01C65A24] X-Spam-Score: 0.5 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 Cc: gdommety@cisco.com, Demaria Elena , dime@ietf.org, Guardini Ivano , basavaraj.patil@nokia.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1686640949==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1686640949== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----=_NextPart_000_16000_01C65A35.7189CA60" This is a multi-part message in MIME format. ------=_NextPart_000_16000_01C65A35.7189CA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The only difference between the two MIP6 bootstrapping solutions is the = Home Agent assignment via DHCP, that requires new capability in NAS-AAA = interface. All other requirements and functionality are common to split = and integrated solutions. And what we specify for split needs to be = implemented also for integrated (AAA-HA interface). There are moreover = other common requirements that may be not related to bootstrapping (e.g. = session termination) and that are in common to both scenarios, too. I still think one draft is better. --Gerardo =20 > -----Original Message----- > From: Junghoon Jee [mailto:jhjee@etri.re.kr]=20 > Sent: venerd=EC 7 aprile 2006 1.54 > To: jouni.korhonen@teliasonera.com;=20 > hannes.tschofenig@siemens.com; julien.bournelle@int-evry.fr > Cc: gdommety@cisco.com; Demaria Elena;=20 > basavaraj.patil@nokia.com; Giaretta Gerardo; dime@ietf.org;=20 > Guardini Ivano > Subject: Re: [Dime] Re: Diameter MIPv6 >=20 > Hi all, >=20 > I'd suggest to having _two_ DIME drafts for integrated and split case > because the overall bootstrapping procedures are different in=20 > each case. > Please take a look at the current suggested drafts from Hannes, > then might be in the same line with me. :-) >=20 > As a side note:=20 > Listing up AAA requirements through _single_ document is still valid > as I mentioned in the previous MIP6 WG meeting. >=20 > Thanks, > -Junghoon >=20 > ----- Original Message -----=20 > From: > To: ; > Cc: ; ;=20 > ; ;=20 > ; > Sent: Thursday, April 06, 2006 9:58 PM > Subject: RE: [Dime] Re: Diameter MIPv6 >=20 >=20 >=20 > I would also go for two different documents because of the > differences in solution approaches and for the general > clarity. >=20 > Cheers, > Jouni >=20 >=20 > > -----Original Message----- > > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > > Sent: 6. huhtikuuta 2006 15:53 > > To: Julien Bournelle > > Cc: gdommety@cisco.com; elena.demaria@tilab.com;=20 > > basavaraj.patil@nokia.com; gerardo.giaretta@tilab.com;=20 > > dime@ietf.org; ivano.guardini@tilab.com > > Subject: AW: [Dime] Re: Diameter MIPv6 > >=20 > > Hi Julien,=20 > >=20 > > this is my impression was well. Working on the document I got=20 > > the impression that they are sufficiently different in order=20 > > to deal with the bootstrapping solutions in a separate document.=20 > >=20 > > Ciao > > Hannes > > =20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 > > > Gesendet: Donnerstag, 6. April 2006 14:41 > > > An: Julien Bournelle > > > Cc: gdommety@cisco.com; elena.demaria@tilab.com;=20 > > > basavaraj.patil@nokia.com; gerardo.giaretta@tilab.com;=20 > > > dime@ietf.org; ivano.guardini@tilab.com > > > Betreff: [Dime] Re: Diameter MIPv6 > > >=20 > > > Hi all, > > >=20 > > > For the Integrated scenario we need to: > > > - define AVPs (HA) > > > - explain where to put it in the Diameter EAP/NASREQ=20 > > > exchanges (between > > > NAS and the AAA) > > > - probably require a Application-ID for that the NAS=20 > > announces to the > > > AAA that it support the Integrated case. > > >=20 > > > For the split scenario, we need to: > > > - explain how the HA uses Diameter EAP. (HA uses IKEv2 with MN)=20 > > > - maybe some issues may raised after investigation (do the=20 > > HA need to > > > tell to the AAA that it is a HA and not a NAS ? this sort=20 > > > of things). > > >=20 > > > So at this point of time, I think it would be better to=20 > investigate > > > this separately and see later if it makes sense to merge the=20 > > > documents. > > > I don't really see the advantage of having one document for=20 > > > the moment. > > >=20 > > > Regards, > > >=20 > > > Julien B. > > >=20 > > > On Wed, Apr 05, 2006 at 12:42:26PM +0200, Julien Bournelle wrote: > > > > Hi all, > > > >=20 > > > > On Wed, Apr 05, 2006 at 11:44:37AM +0200, Hannes=20 > Tschofenig wrote: > > > > > Hi all, > > > > >=20 > > > > > the MIP6 bootstrapping design team has worked on two=20 > > > solutions for=20 > > > > > bootstrapping of MIPv6: the integrated and the split scenario > > > > >=20 > > > > > These two solutions are documented in two separate drafts: > > > > >=20 > > > > > MIP6-bootstrapping via DHCPv6 for the Integrated Scenario > > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > > > ing-integrated-dhc-00.txt > > > > >=20 > > > > > Mobile IPv6 bootstrapping in split scenario > > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > > > ing-split-02.txt > > > > >=20 > > > > > As such, there is the question whether the work in DIME=20 > > > should also=20 > > > > > produce two separate documents referring to these two=20 > > > bootstrapping=20 > > > > > deployment scenarios or whether it would be useful to=20 > > > captures both=20 > > > > > scenarios in a single document. > > > > >=20 > > > > > Thoughts? > > > >=20 > > > > I would prefer two documents. I have two reasons for this: > > > >=20 > > > > 1/ In the integrated scenario, the AAA is used between NAS=20 > > > and AAA. The > > > > HA address is delivered from the AAA to the NAS and thus=20 > > > NASREQ or EAP > > > > may be in used. > > > >=20 > > > > In the split scenario, Diameter is used between HA and=20 > > > the AAA. And > > > > the AAA does not deliver the HA to the HA... > > > >=20 > > > >=20 > > > > 2/ From an implementation perspective, it would be=20 > > easier to have a > > > > specific document for each case. > > > >=20 > > > > Julien B. > > > >=20 > > > > >=20 > > > > > Ciao > > > > > Hannes & John > > > > >=20 > > > > > PS: John and myself would also like to know when the=20 > > > MIP6-AAA Goals draft > > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goa > > > ls-01.txt > > > > > is going to be finalized since the Diameter MIPv6 work=20 > > > depends on this=20 > > > > > document. > > > >=20 > > > > --=20 > > > > julien.bournelle at int-evry.fr > > >=20 > > > --=20 > > > julien.bournelle at int-evry.fr > > >=20 > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_16000_01C65A35.7189CA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
The only difference = between the two MIP6 bootstrapping solutions is the Home Agent = assignment via DHCP, that requires new capability in NAS-AAA interface. = All other requirements and functionality are common to split and = integrated solutions. And what we specify for split needs to be = implemented also for integrated (AAA-HA interface). There are moreover = other common requirements that may be not related to bootstrapping (e.g. = session termination) and that are in common to both scenarios, = too.

I still think one draft is better.

--Gerardo =

> -----Original Message-----
> From: Junghoon Jee = [mailto:jhjee@etri.re.kr]
> Sent: venerd=EC 7 aprile 2006 1.54
> = To: jouni.korhonen@teliasonera.com;
> hannes.tschofenig@siemens.com; = julien.bournelle@int-evry.fr
> Cc: gdommety@cisco.com; Demaria Elena; =
> basavaraj.patil@nokia.com; Giaretta Gerardo; dime@ietf.org;
> = Guardini Ivano
> Subject: Re: [Dime] Re: Diameter MIPv6
>
> Hi = all,
>
> I'd suggest to having _two_ DIME drafts for integrated = and split case
> because the overall bootstrapping procedures are = different in
> each case.
> Please take a look at the current = suggested drafts from Hannes,
> then might be in the same line with = me. :-)
>
> As a side note:
> Listing up AAA requirements = through _single_ document is still valid
> as I mentioned in the = previous MIP6 WG meeting.
>
> Thanks,
> -Junghoon
>
> = ----- Original Message -----
> From: =
> To: = ;
> Cc: = ; ;
> = ; ;
> = ;
> Sent: Thursday, April = 06, 2006 9:58 PM
> Subject: RE: [Dime] Re: Diameter MIPv6
>
> =
>
> I would also go for two different documents because of = the
> differences in solution approaches and for the general
> = clarity.
>
> Cheers,
> Jouni
>
>
> > -----Original = Message-----
> > From: Tschofenig, Hannes = [mailto:hannes.tschofenig@siemens.com]
> > Sent: 6. huhtikuuta 2006 = 15:53
> > To: Julien Bournelle
> > Cc: gdommety@cisco.com; = elena.demaria@tilab.com;
> > basavaraj.patil@nokia.com; = gerardo.giaretta@tilab.com;
> > dime@ietf.org; = ivano.guardini@tilab.com
> > Subject: AW: [Dime] Re: Diameter = MIPv6
> >
> > Hi Julien,
> >
> > this is my impression = was well. Working on the document I got
> > the impression that they = are sufficiently different in order
> > to deal with the = bootstrapping solutions in a separate document.
> >
> > = Ciao
> > Hannes
> >
> >
> > > -----Urspr=FCngliche = Nachricht-----
> > > Von: Julien Bournelle = [mailto:julien.bournelle@int-evry.fr]
> > > Gesendet: Donnerstag, 6. = April 2006 14:41
> > > An: Julien Bournelle
> > > Cc: = gdommety@cisco.com; elena.demaria@tilab.com;
> > > = basavaraj.patil@nokia.com; gerardo.giaretta@tilab.com;
> > > = dime@ietf.org; ivano.guardini@tilab.com
> > > Betreff: [Dime] Re: = Diameter MIPv6
> > >
> > > Hi all,
> > >
> > > For the = Integrated scenario we need to:
> > > - define AVPs (HA)
> > > - = explain where to put it in the Diameter EAP/NASREQ
> > > exchanges = (between
> > > NAS and the AAA)
> > > - probably require a = Application-ID for that the NAS
> > announces to the
> > > AAA = that it support the Integrated case.
> > >
> > > For the split = scenario, we need to:
> > > - explain how the HA uses Diameter EAP. = (HA uses IKEv2 with MN)
> > > - maybe some issues may raised after = investigation (do the
> > HA need to
> > > tell to the AAA = that it is a HA and not a NAS ? this sort
> > > of things).
> > > =
> > > So at this point of time, I think it would be better to
> = investigate
> > > this separately and see later if it makes sense to = merge the
> > > documents.
> > > I don't really see the = advantage of having one document for
> > > the moment.
> > > =
> > > Regards,
> > >
> > > Julien B.
> > >
> > > On = Wed, Apr 05, 2006 at 12:42:26PM +0200, Julien Bournelle wrote:
> > > = > Hi all,
> > > >
> > > > On Wed, Apr 05, 2006 at 11:44:37AM = +0200, Hannes
> Tschofenig wrote:
> > > > > Hi all,
> > > > > =
> > > > > the MIP6 bootstrapping design team has worked on two
> = > > solutions for
> > > > > bootstrapping of MIPv6: the integrated = and the split scenario
> > > > >
> > > > > These two solutions = are documented in two separate drafts:
> > > > >
> > > > > = MIP6-bootstrapping via DHCPv6 for the Integrated Scenario
> > > > > =
> > > = http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp
> > > = ing-integrated-dhc-00.txt
> > > > >
> > > > > Mobile IPv6 = bootstrapping in split scenario
> > > > >
> > > = http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp
> > > = ing-split-02.txt
> > > > >
> > > > > As such, there is the = question whether the work in DIME
> > > should also
> > > > > = produce two separate documents referring to these two
> > > = bootstrapping
> > > > > deployment scenarios or whether it would be = useful to
> > > captures both
> > > > > scenarios in a single = document.
> > > > >
> > > > > Thoughts?
> > > >
> > > > I = would prefer two documents. I have two reasons for this:
> > > > =
> > > > 1/ In the integrated scenario, the AAA is used between NAS =
> > > and AAA. The
> > > > HA address is delivered from the AAA = to the NAS and thus
> > > NASREQ or EAP
> > > > may be in = used.
> > > >
> > > > In the split scenario, Diameter is used = between HA and
> > > the AAA. And
> > > > the AAA does not = deliver the HA to the HA...
> > > >
> > > >
> > > > 2/ From = an implementation perspective, it would be
> > easier to have a
> = > > > specific document for each case.
> > > >
> > > > Julien = B.
> > > >
> > > > >
> > > > > Ciao
> > > > > Hannes & = John
> > > > >
> > > > > PS: John and myself would also like to = know when the
> > > MIP6-AAA Goals draft
> > > > >
> > > = http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goa
> > > = ls-01.txt
> > > > > is going to be finalized since the Diameter MIPv6 = work
> > > depends on this
> > > > > document.
> > > >
> = > > > --
> > > > julien.bournelle at int-evry.fr
> > >
> > > = --
> > > julien.bournelle at int-evry.fr
> > >
> > > = _______________________________________________
> > > DiME mailing = list
> > > DiME@ietf.org
> > > = https://www1.ietf.org/mailman/listinfo/dime
> > >
> >
> > = _______________________________________________
> > DiME mailing = list
> > DiME@ietf.org
> > = https://www1.ietf.org/mailman/listinfo/dime
> >
>
> = _______________________________________________
> DiME mailing = list
> DiME@ietf.org
> = https://www1.ietf.org/mailman/listinfo/dime
>
--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_16000_01C65A35.7189CA60-- --===============1686640949== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1686640949==-- From dime-bounces@ietf.org Fri Apr 07 05:55:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnh8-0007P6-Jm; Fri, 07 Apr 2006 05:55:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnh7-0007Hh-1L for dime@ietf.org; Fri, 07 Apr 2006 05:55:57 -0400 Received: from lhrga01-in.huawei.com ([57.66.76.5] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRnh6-000672-C1 for dime@ietf.org; Fri, 07 Apr 2006 05:55:57 -0400 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXC008EAIWJPR@lhrga01-in.huawei.com> for dime@ietf.org; Fri, 07 Apr 2006 10:41:08 +0100 (BST) Received: from IBM4307EA0CEF3 ([217.167.116.208]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXC000L8IWJNU@lhrga01-in.huawei.com> for dime@ietf.org; Fri, 07 Apr 2006 10:41:07 +0100 (BST) Date: Fri, 07 Apr 2006 17:55:48 +0800 From: Tina TSOU Subject: Re: [Dime] CER/CEA on an open connection To: asveren@ulticom.com, vfajardo@tari.toshiba.com, john.loughney@nokia.com Message-id: <006801c65a29$72b4d350$d074a7d9@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <615BD9B54CB01B41838C323DB9E91AAB0C9244@esebe100.NOE.Nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, I think the schema is ok but for simultaneous renegotiation serialization - "A Diameter node that receives a CER from a peer from which it has sent its own pending CER MUST be able serialize the simultaneous renegotiation. If the Diameter node is acting as a responder (see Sec 5.6) then it MUST give precedence to the renegotiation initiated by its peer and send a CEA accordingly. If the Diameter node is acting as an initiator (see Sec 5.6) then it MUST delay the renegotiation initiated by its peer (the responder) and send a CEA with Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY in order to retain the current state between them. The receiver of this CEA (the responder) SHOULD retain its current state and proceed with the ongoing renegotiation initiated by its peer. It SHOULD retransmit its own CER to initiate another renegotiation after the current renegotiation completes. Both renegotiations SHOULD be treated as separate and sequential." Does any one understand why this spl. handling is needed in the event of a renegotiation cross over? Even without this, I think each CER will be treated atomically by the receiver. Tina ----- Original Message ----- From: To: ; Cc: Sent: Thursday, April 06, 2006 11:11 AM Subject: RE: [Dime] CER/CEA on an open connection Hi all, >>> DIAMETER_APPLICATION_UNSUPPORTED. >>> >>> What is proposed is that a node initiating the change >request should >>> not terminate the supported application until the >corresponding peer agrees. >>> If the peer does not agree, the node initiating the change request >>> has an alternative to gracefully terminate of the >connection with the >>> peer if it chooses to. Otherwise, it must honor its commitment to >>> keep the application support. >>> >> [TOLGA]AFAICS, the moment you introduce some intelligence to that >> procedure, e.g. receiver of CER aggreing with the >application getting >> down, you need to be sure that you are communicating with your >> application level peer. CER/CEA is hop-to-hop, it probably >won't do it >> for a generic solution, where we have relay agents etc.. >between the endpoints. >> >renegotiation is done between peers (one hope) not between >end-points and the decision on wether to continue support for >an application is local to a node. how a node will deal with >not supporting an application anymore is up to the application itself. I agree with Victor. John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Apr 07 09:24:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqxP-0005wu-Di; Fri, 07 Apr 2006 09:24:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqxO-0005wp-GD for dime@ietf.org; Fri, 07 Apr 2006 09:24:58 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRqxN-0004NY-6N for dime@ietf.org; Fri, 07 Apr 2006 09:24:58 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k37DOTi0041444; Fri, 7 Apr 2006 09:24:29 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4436680F.2050001@tari.toshiba.com> Date: Fri, 07 Apr 2006 09:24:31 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Tina TSOU Subject: Re: [Dime] CER/CEA on an open connection References: <615BD9B54CB01B41838C323DB9E91AAB0C9244@esebe100.NOE.Nokia.com> <006801c65a29$72b4d350$d074a7d9@IBM4307EA0CEF3> In-Reply-To: <006801c65a29$72b4d350$d074a7d9@IBM4307EA0CEF3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tina, Comments inline: > Hi, > I think the schema is ok but for simultaneous renegotiation > serialization - > "A Diameter node that receives a CER from a peer from which it has sent > its own pending CER MUST be able serialize the simultaneous > renegotiation. If the Diameter node is acting as a responder (see Sec > 5.6) then it MUST give precedence to the renegotiation initiated by its > peer and send a CEA accordingly. > If the Diameter node is acting as an initiator (see Sec 5.6) then it > MUST delay the renegotiation initiated by its peer (the responder) and > send a CEA > with Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY in order to retain > the current state between them. The receiver of this CEA (the > responder) SHOULD retain its current state and proceed with the ongoing > renegotiation initiated by its peer. It SHOULD retransmit its own CER to > initiate another renegotiation after the current renegotiation > completes. Both renegotiations SHOULD be treated as separate and > sequential." > > Does any one understand why this spl. handling is needed in the event of > a renegotiation cross over? Even without this, I think each CER will be > treated atomically by the receiver. Maybe I'm wrong but I'm not clear on how multiple pending transactions can be resolved automatically without serialization or extra logic (i.e., election process in the rfc). Anyway, the basic idea of the text was to "assist" a diameter node in making sure serialization does occur. "Assistance" here implies that a diameter node need not be burdened with extra state/logic of handling simultaneous renegotiation since such renegotiation will be serialized. I don't have a strong opinion on this but if we get a consensus that we do not need to specify this behavior and let the implementations deal with it in their own way then we can make this text optional. hope this helps, victor > > Tina > > ----- Original Message ----- From: > To: ; > Cc: > Sent: Thursday, April 06, 2006 11:11 AM > Subject: RE: [Dime] CER/CEA on an open connection > > > Hi all, > > >>>> DIAMETER_APPLICATION_UNSUPPORTED. >>>> >>>> What is proposed is that a node initiating the change >> request should >>>> not terminate the supported application until the >> corresponding peer agrees. >>>> If the peer does not agree, the node initiating the change request >>>> has an alternative to gracefully terminate of the >> connection with the >>>> peer if it chooses to. Otherwise, it must honor its commitment to >>>> keep the application support. >>>> >>> [TOLGA]AFAICS, the moment you introduce some intelligence to that >>> procedure, e.g. receiver of CER aggreing with the >> application getting >>> down, you need to be sure that you are communicating with your >>> application level peer. CER/CEA is hop-to-hop, it probably >> won't do it >>> for a generic solution, where we have relay agents etc.. >> between the endpoints. >>> >> renegotiation is done between peers (one hope) not between >> end-points and the decision on wether to continue support for >> an application is local to a node. how a node will deal with >> not supporting an application anymore is up to the application itself. > > I agree with Victor. > > John > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Apr 07 09:34:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRr6w-0002ae-Qc; Fri, 07 Apr 2006 09:34:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRr6w-0002Zk-4Z for dime@ietf.org; Fri, 07 Apr 2006 09:34:50 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRr6v-0004t5-Og for dime@ietf.org; Fri, 07 Apr 2006 09:34:50 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 4758117A81 for ; Fri, 7 Apr 2006 09:34:49 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k37DYmWE022784 for ; Fri, 7 Apr 2006 09:34:48 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] CER/CEA on an open connection Date: Fri, 7 Apr 2006 09:13:47 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4436680F.2050001@tari.toshiba.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: unknown X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, Once there is the assumption that shutting down applications is completely decided in a local way -which as far as I understand everybody agrees(?)-, I don't see a need for any type of serialization. If you see a problem scenario, could you provide message flow for it, otherwise IMHO there is no need to complicate things. Furthermore, there is also no need to do something special based on the result code of CEA, if we want to honor "complete local decision for application shutdown" principle. Regardless of CEA result, application will be shut down -actually even wothout waiting for CEA-. Probably what we need to say is just that renegotiations are limited to advertise new set of supported applications. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Friday, April 07, 2006 9:25 AM > To: Tina TSOU > Cc: asveren@ulticom.com; john.loughney@nokia.com; dime@ietf.org > Subject: Re: [Dime] CER/CEA on an open connection > > > Hi Tina, > > Comments inline: > > Hi, > > I think the schema is ok but for simultaneous renegotiation > > serialization - > > "A Diameter node that receives a CER from a peer from which it has sent > > its own pending CER MUST be able serialize the simultaneous > > renegotiation. If the Diameter node is acting as a responder (see Sec > > 5.6) then it MUST give precedence to the renegotiation initiated by its > > peer and send a CEA accordingly. > > If the Diameter node is acting as an initiator (see Sec 5.6) then it > > MUST delay the renegotiation initiated by its peer (the responder) and > > send a CEA > > with Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY in order to retain > > the current state between them. The receiver of this CEA (the > > responder) SHOULD retain its current state and proceed with the ongoing > > renegotiation initiated by its peer. It SHOULD retransmit its own CER to > > initiate another renegotiation after the current renegotiation > > completes. Both renegotiations SHOULD be treated as separate and > > sequential." > > > > Does any one understand why this spl. handling is needed in the event of > > a renegotiation cross over? Even without this, I think each CER will be > > treated atomically by the receiver. > Maybe I'm wrong but I'm not clear on how multiple pending transactions > can be resolved automatically without serialization or extra logic > (i.e., election process in the rfc). Anyway, the basic idea of the text > was to "assist" a diameter node in making sure serialization does occur. > "Assistance" here implies that a diameter node need not be burdened with > extra state/logic of handling simultaneous renegotiation since such > renegotiation will be serialized. I don't have a strong opinion on this > but if we get a consensus that we do not need to specify this behavior > and let the implementations deal with it in their own way then we can > make this text optional. > > hope this helps, > victor > > > > Tina > > > > ----- Original Message ----- From: > > To: ; > > Cc: > > Sent: Thursday, April 06, 2006 11:11 AM > > Subject: RE: [Dime] CER/CEA on an open connection > > > > > > Hi all, > > > > > >>>> DIAMETER_APPLICATION_UNSUPPORTED. > >>>> > >>>> What is proposed is that a node initiating the change > >> request should > >>>> not terminate the supported application until the > >> corresponding peer agrees. > >>>> If the peer does not agree, the node initiating the change request > >>>> has an alternative to gracefully terminate of the > >> connection with the > >>>> peer if it chooses to. Otherwise, it must honor its commitment to > >>>> keep the application support. > >>>> > >>> [TOLGA]AFAICS, the moment you introduce some intelligence to that > >>> procedure, e.g. receiver of CER aggreing with the > >> application getting > >>> down, you need to be sure that you are communicating with your > >>> application level peer. CER/CEA is hop-to-hop, it probably > >> won't do it > >>> for a generic solution, where we have relay agents etc.. > >> between the endpoints. > >>> > >> renegotiation is done between peers (one hope) not between > >> end-points and the decision on wether to continue support for > >> an application is local to a node. how a node will deal with > >> not supporting an application anymore is up to the application itself. > > > > I agree with Victor. > > > > John > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Apr 08 00:56:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS5Uh-0007rD-2Z; Sat, 08 Apr 2006 00:56:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS5Uf-0007r8-AO for dime@ietf.org; Sat, 08 Apr 2006 00:56:17 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS5Ue-0003yb-UV for dime@ietf.org; Sat, 08 Apr 2006 00:56:17 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k385CZub009940 for ; Fri, 7 Apr 2006 22:12:35 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3859c3f011193 for ; Sat, 8 Apr 2006 00:09:39 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] CER/CEA on an open connection Date: Sat, 8 Apr 2006 12:56:14 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] CER/CEA on an open connection Thread-Index: AcZaSB4o+fpnI7kVQaGBBwX4/G7lXAAgAMIw From: "Ram O V Vishnu-A14676" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: Nakhjiri Madjid-MNAKHJI1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Some clarifications and comments on the discussion on this thread: We would like to clarify the following practical scenarios of this happenning: 1. there are a list of published applications which the box support and these are installed in the box. Now, some of them go down/up. This would get translated into change in peer capabilities. 2. there is a new application which is getting installed/removed from the box. We think that (1) is the most probable scenario. so, there is value in giving a simple solution assuming that this change (in capabilities) is most probably temporary. If this is not the case, we are talking about (2), which is=20 a major change in the box anyways. So in (2), we assume it is ok to assume that the connections to be reestablished. We would like to say that our design goals are: 3. solution should be simple & as backward compatible as possible. 4. minimize the FSM changes. We suggest: 5. Updating peer capabilities done only using a CER/CEA in the open state.=20 Sender of CER/CEA updates the local capabilities before sending the message and hence is a local decision. 6. The rest of the processing of the CER/CEA will be as per the current RFC.=20 Say for example, if there are no common applications left with that peer, DIAMETER_NO_COMMON_APPLICATION is sent in the CEA and the connection is closed. Problems in the email thread under discussion & some comments: 7. Cross over and sequencing of CER/CEA exchange. We dont think there is a problem here. Cant find any race condition. 8. Mutual agreement to bring down applications will not work due to possible relays=20 in between as Tolga has pointed out in the mailing list. 9. The DPR solution in the suggested text is not a good idea. Because DPR cannot advertise the latest local applications to the peer. This may cause the race condition=20 and sequencing problem. This problem can be avoided by using the approach which=20 we suggested in (5). Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: Friday, April 07, 2006 6:44 PM To: dime@ietf.org Subject: RE: [Dime] CER/CEA on an open connection Hi Victor, Once there is the assumption that shutting down applications is completely decided in a local way -which as far as I understand everybody agrees(?)-, I don't see a need for any type of serialization. If you see a problem scenario, could you provide message flow for it, otherwise IMHO there is no need to complicate things. Furthermore, there is also no need to do something special based on the result code of CEA, if we want to honor "complete local decision for application shutdown" principle. Regardless of CEA result, application will be shut down -actually even wothout waiting for CEA-. Probably what we need to say is just that renegotiations are limited to advertise new set of supported applications. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Friday, April 07, 2006 9:25 AM > To: Tina TSOU > Cc: asveren@ulticom.com; john.loughney@nokia.com; dime@ietf.org > Subject: Re: [Dime] CER/CEA on an open connection > > > Hi Tina, > > Comments inline: > > Hi, > > I think the schema is ok but for simultaneous renegotiation=20 > > serialization - "A Diameter node that receives a CER from a peer=20 > > from which it has sent its own pending CER MUST be able serialize=20 > > the simultaneous renegotiation. If the Diameter node is acting as a=20 > > responder (see Sec > > 5.6) then it MUST give precedence to the renegotiation initiated by=20 > > its peer and send a CEA accordingly. If the Diameter node is acting=20 > > as an initiator (see Sec 5.6) then it MUST delay the renegotiation=20 > > initiated by its peer (the responder) and send a CEA > > with Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY in order to retain > > the current state between them. The receiver of this CEA (the > > responder) SHOULD retain its current state and proceed with the ongoing > > renegotiation initiated by its peer. It SHOULD retransmit its own CER to > > initiate another renegotiation after the current renegotiation > > completes. Both renegotiations SHOULD be treated as separate and > > sequential." > > > > Does any one understand why this spl. handling is needed in the=20 > > event of a renegotiation cross over? Even without this, I think each > > CER will be treated atomically by the receiver. > Maybe I'm wrong but I'm not clear on how multiple pending transactions > can be resolved automatically without serialization or extra logic=20 > (i.e., election process in the rfc). Anyway, the basic idea of the=20 > text was to "assist" a diameter node in making sure serialization does > occur. "Assistance" here implies that a diameter node need not be=20 > burdened with extra state/logic of handling simultaneous renegotiation > since such renegotiation will be serialized. I don't have a strong=20 > opinion on this but if we get a consensus that we do not need to=20 > specify this behavior and let the implementations deal with it in=20 > their own way then we can make this text optional. > > hope this helps, > victor > > > > Tina > > > > ----- Original Message ----- From: > > To: ; > > Cc: > > Sent: Thursday, April 06, 2006 11:11 AM > > Subject: RE: [Dime] CER/CEA on an open connection > > > > > > Hi all, > > > > > >>>> DIAMETER_APPLICATION_UNSUPPORTED. > >>>> > >>>> What is proposed is that a node initiating the change > >> request should > >>>> not terminate the supported application until the > >> corresponding peer agrees. > >>>> If the peer does not agree, the node initiating the change=20 > >>>> request has an alternative to gracefully terminate of the > >> connection with the > >>>> peer if it chooses to. Otherwise, it must honor its commitment to > >>>> keep the application support. > >>>> > >>> [TOLGA]AFAICS, the moment you introduce some intelligence to that=20 > >>> procedure, e.g. receiver of CER aggreing with the > >> application getting > >>> down, you need to be sure that you are communicating with your=20 > >>> application level peer. CER/CEA is hop-to-hop, it probably > >> won't do it > >>> for a generic solution, where we have relay agents etc.. > >> between the endpoints. > >>> > >> renegotiation is done between peers (one hope) not between=20 > >> end-points and the decision on wether to continue support for an=20 > >> application is local to a node. how a node will deal with not=20 > >> supporting an application anymore is up to the application itself. > > > > I agree with Victor. > > > > John > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Apr 08 12:37:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSGR2-0003Ta-5H; Sat, 08 Apr 2006 12:37:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSGR1-0003TV-3U for dime@ietf.org; Sat, 08 Apr 2006 12:37:15 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSGR0-0002Ei-7G for dime@ietf.org; Sat, 08 Apr 2006 12:37:15 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k38GbBl8007517 for ; Sat, 8 Apr 2006 12:37:11 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k38GeQn5164022 for ; Sat, 8 Apr 2006 10:40:26 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k38GbBrj000337 for ; Sat, 8 Apr 2006 10:37:11 -0600 Received: from d03nm114.boulder.ibm.com (d03nm114.boulder.ibm.com [9.17.195.140]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k38GbAAg000333; Sat, 8 Apr 2006 10:37:11 -0600 In-Reply-To: To: "Ram O V Vishnu-A14676" MIME-Version: 1.0 Subject: RE: [Dime] CER/CEA on an open connection X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Timothy Smith Date: Sat, 8 Apr 2006 12:40:17 -0400 X-MIMETrack: Serialize by Router on D03NM114/03/M/IBM(Release 7.0.1HF43 | March 10, 2006) at 04/08/2006 10:40:18, Serialize complete at 04/08/2006 10:40:18 X-Spam-Score: 0.5 (/) X-Scan-Signature: 5d99cba2a085c3987933aa34e30e85ab Cc: Nakhjiri Madjid-MNAKHJI1 , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2022999411==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============2022999411== Content-Type: multipart/alternative; boundary="=_alternative 005B4BB18525714A_=" This is a multipart message in MIME format. --=_alternative 005B4BB18525714A_= Content-Type: text/plain; charset="US-ASCII" Hi Vishnu, Good summary! I agree with most of your points. I'm not sure, however, that I distinguish between (1) and (2). I think whether temporary or not, we should handle CER/CEA exchanges in the same manner. I agree with your design goals (3) ,(4), and suggestions (5) , (6) , (8), and (9). Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont think there is a problem here. Cant find any race condition." I thought that there was a subtle problem here, but I think you are right. Given that the connection insures sequencing, the latest CER or CEA that you receive is what you should use as the list of negotiated App Ids. Should there be some discussion on the retry mechanism? You send a CER, and no response is received. Does this mean that the peer just doesn't know how to renegotiate? Should we ignore and retry every n seconds? Bring down the connection? Or do we just continue to use the apps from the initial negotiation? My preference on this is that we should require a CEA response to the CER. If the CEA is not received, we shutdown the connection and start over. This would address compatibility issues with existing implementations. It would also be consistent with the processing of the initial CER/CEA. Best Regards, Timothy Smith tjsmith@us.ibm.com (919) 254-4723 "Ram O V Vishnu-A14676" 04/08/2006 12:56 AM To cc Nakhjiri Madjid-MNAKHJI1 Subject RE: [Dime] CER/CEA on an open connection Hi, Some clarifications and comments on the discussion on this thread: We would like to clarify the following practical scenarios of this happenning: 1. there are a list of published applications which the box support and these are installed in the box. Now, some of them go down/up. This would get translated into change in peer capabilities. 2. there is a new application which is getting installed/removed from the box. We think that (1) is the most probable scenario. so, there is value in giving a simple solution assuming that this change (in capabilities) is most probably temporary. If this is not the case, we are talking about (2), which is a major change in the box anyways. So in (2), we assume it is ok to assume that the connections to be reestablished. We would like to say that our design goals are: 3. solution should be simple & as backward compatible as possible. 4. minimize the FSM changes. We suggest: 5. Updating peer capabilities done only using a CER/CEA in the open state. Sender of CER/CEA updates the local capabilities before sending the message and hence is a local decision. 6. The rest of the processing of the CER/CEA will be as per the current RFC. Say for example, if there are no common applications left with that peer, DIAMETER_NO_COMMON_APPLICATION is sent in the CEA and the connection is closed. Problems in the email thread under discussion & some comments: 7. Cross over and sequencing of CER/CEA exchange. We dont think there is a problem here. Cant find any race condition. 8. Mutual agreement to bring down applications will not work due to possible relays in between as Tolga has pointed out in the mailing list. 9. The DPR solution in the suggested text is not a good idea. Because DPR cannot advertise the latest local applications to the peer. This may cause the race condition and sequencing problem. This problem can be avoided by using the approach which we suggested in (5). Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com] Sent: Friday, April 07, 2006 6:44 PM To: dime@ietf.org Subject: RE: [Dime] CER/CEA on an open connection Hi Victor, Once there is the assumption that shutting down applications is completely decided in a local way -which as far as I understand everybody agrees(?)-, I don't see a need for any type of serialization. If you see a problem scenario, could you provide message flow for it, otherwise IMHO there is no need to complicate things. Furthermore, there is also no need to do something special based on the result code of CEA, if we want to honor "complete local decision for application shutdown" principle. Regardless of CEA result, application will be shut down -actually even wothout waiting for CEA-. Probably what we need to say is just that renegotiations are limited to advertise new set of supported applications. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Friday, April 07, 2006 9:25 AM > To: Tina TSOU > Cc: asveren@ulticom.com; john.loughney@nokia.com; dime@ietf.org > Subject: Re: [Dime] CER/CEA on an open connection > > > Hi Tina, > > Comments inline: > > Hi, > > I think the schema is ok but for simultaneous renegotiation > > serialization - "A Diameter node that receives a CER from a peer > > from which it has sent its own pending CER MUST be able serialize > > the simultaneous renegotiation. If the Diameter node is acting as a > > responder (see Sec > > 5.6) then it MUST give precedence to the renegotiation initiated by > > its peer and send a CEA accordingly. If the Diameter node is acting > > as an initiator (see Sec 5.6) then it MUST delay the renegotiation > > initiated by its peer (the responder) and send a CEA > > with Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY in order to retain > > the current state between them. The receiver of this CEA (the > > responder) SHOULD retain its current state and proceed with the ongoing > > renegotiation initiated by its peer. It SHOULD retransmit its own CER to > > initiate another renegotiation after the current renegotiation > > completes. Both renegotiations SHOULD be treated as separate and > > sequential." > > > > Does any one understand why this spl. handling is needed in the > > event of a renegotiation cross over? Even without this, I think each > > CER will be treated atomically by the receiver. > Maybe I'm wrong but I'm not clear on how multiple pending transactions > can be resolved automatically without serialization or extra logic > (i.e., election process in the rfc). Anyway, the basic idea of the > text was to "assist" a diameter node in making sure serialization does > occur. "Assistance" here implies that a diameter node need not be > burdened with extra state/logic of handling simultaneous renegotiation > since such renegotiation will be serialized. I don't have a strong > opinion on this but if we get a consensus that we do not need to > specify this behavior and let the implementations deal with it in > their own way then we can make this text optional. > > hope this helps, > victor > > > > Tina > > > > ----- Original Message ----- From: > > To: ; > > Cc: > > Sent: Thursday, April 06, 2006 11:11 AM > > Subject: RE: [Dime] CER/CEA on an open connection > > > > > > Hi all, > > > > > >>>> DIAMETER_APPLICATION_UNSUPPORTED. > >>>> > >>>> What is proposed is that a node initiating the change > >> request should > >>>> not terminate the supported application until the > >> corresponding peer agrees. > >>>> If the peer does not agree, the node initiating the change > >>>> request has an alternative to gracefully terminate of the > >> connection with the > >>>> peer if it chooses to. Otherwise, it must honor its commitment to > >>>> keep the application support. > >>>> > >>> [TOLGA]AFAICS, the moment you introduce some intelligence to that > >>> procedure, e.g. receiver of CER aggreing with the > >> application getting > >>> down, you need to be sure that you are communicating with your > >>> application level peer. CER/CEA is hop-to-hop, it probably > >> won't do it > >>> for a generic solution, where we have relay agents etc.. > >> between the endpoints. > >>> > >> renegotiation is done between peers (one hope) not between > >> end-points and the decision on wether to continue support for an > >> application is local to a node. how a node will deal with not > >> supporting an application anymore is up to the application itself. > > > > I agree with Victor. > > > > John > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --=_alternative 005B4BB18525714A_= Content-Type: text/html; charset="US-ASCII"
Hi Vishnu,

Good summary!  I agree with most of your points.  I'm not sure, however, that I distinguish between (1) and (2).  I think whether temporary or not, we should handle CER/CEA exchanges in the same manner.

I agree with your design goals (3) ,(4), and suggestions (5) , (6) , (8), and (9).

Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont think there is a problem here. Cant find any race condition."  I thought that there was a subtle problem here, but I think you are right.  Given that the connection insures sequencing, the latest CER or CEA that you receive is what you should use as the list of negotiated App Ids.

Should there be some discussion on the retry mechanism?  You send a CER, and no response is received.  Does this mean that the peer just doesn't know how to renegotiate?  Should we ignore and retry every n seconds?  Bring down the connection?  Or do we just continue to use the apps from the initial negotiation? My preference on this is that we should require a CEA response to the CER.  If the CEA is not received, we shutdown the connection and start over.  This would address compatibility issues with existing implementations.  It would also be consistent with the processing of the initial CER/CEA.

Best Regards,
Timothy Smith

tjsmith@us.ibm.com
(919) 254-4723


"Ram O V Vishnu-A14676" <vishnu@motorola.com>

04/08/2006 12:56 AM

To
<dime@ietf.org>
cc
Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
Subject
RE: [Dime] CER/CEA on an open connection





Hi,

Some clarifications and comments on the discussion on this thread:

We would like to clarify the following practical scenarios of this
happenning:
1. there are a list of published applications which the box support
and these are installed in the box. Now, some of them go down/up. This
would
get translated into change in peer capabilities.
2. there is a new application which is getting installed/removed from
the box.

We think that (1) is the most probable scenario. so,
there is value in giving a simple solution assuming that this change (in
capabilities)
is most probably temporary. If this is not the case, we are talking
about (2), which is
a major change in the box anyways. So in (2), we assume it is ok to
assume that
the connections to be reestablished.

We would like to say that our design goals are:
3. solution should be simple & as backward compatible as possible.
4. minimize the FSM changes.

We suggest:
5. Updating peer capabilities done only using a CER/CEA in the open
state.
Sender of CER/CEA updates the local capabilities before sending the
message and
hence is a local decision.

6. The rest of the processing of the CER/CEA will be as per the current
RFC.
Say for example, if there are no
common applications left with that peer, DIAMETER_NO_COMMON_APPLICATION
is sent in the
CEA and the connection is closed.

Problems in the email thread under discussion & some comments:
7. Cross over and sequencing of CER/CEA exchange. We dont think there is
a problem
here. Cant find any race condition.

8. Mutual agreement to bring down applications will not work due to
possible relays
in between as Tolga has pointed out in the mailing list.

9. The DPR solution in the suggested text is not a good idea. Because
DPR cannot
advertise the latest local applications to the peer. This may cause the
race condition
and sequencing problem. This problem can be avoided by using the
approach which
we suggested in (5).

Regards,
Vishnu.

Motorola India Electronics Pvt Ltd
+91 9844178052
[*] Motorola Internal Use Only



-----Original Message-----
From: Tolga Asveren [mailto:asveren@ulticom.com]
Sent: Friday, April 07, 2006 6:44 PM
To: dime@ietf.org
Subject: RE: [Dime] CER/CEA on an open connection


Hi Victor,

Once there is the assumption that shutting down applications is
completely decided in a local way -which as far as I understand
everybody agrees(?)-, I don't see a need for any type of serialization.
If you see a problem scenario, could you provide message flow for it,
otherwise IMHO there is no need to complicate things.

Furthermore, there is also no need to do something special based on the
result code of CEA, if we want to honor "complete local decision for
application shutdown" principle. Regardless of CEA result, application
will be shut down -actually even wothout waiting for CEA-.

Probably what we need to say is just that renegotiations are limited to
advertise new set of supported applications.

   Thanks,
   Tolga

> -----Original Message-----
> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]
> Sent: Friday, April 07, 2006 9:25 AM
> To: Tina TSOU
> Cc: asveren@ulticom.com; john.loughney@nokia.com; dime@ietf.org
> Subject: Re: [Dime] CER/CEA on an open connection
>
>
> Hi Tina,
>
> Comments inline:
> > Hi,
> > I think the schema is ok but for simultaneous renegotiation
> > serialization - "A Diameter node that receives a CER from a peer
> > from which it has sent its own pending CER MUST be able serialize
> > the simultaneous renegotiation. If the Diameter node is acting as a
> > responder (see Sec
> > 5.6) then it MUST give precedence to the renegotiation initiated by
> > its peer and send a CEA accordingly. If the Diameter node is acting
> > as an initiator (see Sec 5.6) then it MUST delay the renegotiation
> > initiated by its peer (the responder) and send a CEA
> > with Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY in order to
retain
> > the current state between them. The receiver of this CEA (the
> > responder) SHOULD retain its current state and proceed with the
ongoing
> > renegotiation initiated by its peer. It SHOULD retransmit its own
CER to
> > initiate another renegotiation after the current renegotiation
> > completes. Both renegotiations SHOULD be treated as separate and
> > sequential."
> >
> > Does any one understand why this spl. handling is needed in the
> > event of a renegotiation cross over? Even without this, I think each

> > CER will be treated atomically by the receiver.
> Maybe I'm wrong but I'm not clear on how multiple pending transactions

> can be resolved automatically without serialization or extra logic
> (i.e., election process in the rfc). Anyway, the basic idea of the
> text was to "assist" a diameter node in making sure serialization does

> occur. "Assistance" here implies that a diameter node need not be
> burdened with extra state/logic of handling simultaneous renegotiation

> since such renegotiation will be serialized. I don't have a strong
> opinion on this but if we get a consensus that we do not need to
> specify this behavior and let the implementations deal with it in
> their own way then we can make this text optional.
>
> hope this helps,
> victor
> >
> > Tina
> >
> > ----- Original Message ----- From: <john.loughney@nokia.com>
> > To: <vfajardo@tari.toshiba.com>; <asveren@ulticom.com>
> > Cc: <dime@ietf.org>
> > Sent: Thursday, April 06, 2006 11:11 AM
> > Subject: RE: [Dime] CER/CEA on an open connection
> >
> >
> > Hi all,
> >
> >
> >>>> DIAMETER_APPLICATION_UNSUPPORTED.
> >>>>
> >>>> What is proposed is that a node initiating the change
> >> request should
> >>>> not terminate the supported application until the
> >> corresponding peer agrees.
> >>>> If the peer does not agree, the node initiating the change
> >>>> request has an alternative to gracefully terminate of the
> >> connection with the
> >>>> peer if it chooses to. Otherwise, it must honor its commitment to

> >>>> keep the application support.
> >>>>
> >>> [TOLGA]AFAICS, the moment you introduce some intelligence to that
> >>> procedure, e.g. receiver of CER aggreing with the
> >> application getting
> >>> down, you need to be sure that you are communicating with your
> >>> application level peer. CER/CEA is hop-to-hop, it probably
> >> won't do it
> >>> for a generic solution, where we have relay agents etc..
> >> between the endpoints.
> >>>
> >> renegotiation is done between peers (one hope) not between
> >> end-points and the decision on wether to continue support for an
> >> application is local to a node. how a node will deal with not
> >> supporting an application anymore is up to the application itself.
> >
> > I agree with Victor.
> >
> > John
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> >
> >


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
--=_alternative 005B4BB18525714A_=-- --===============2022999411== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============2022999411==-- From dime-bounces@ietf.org Sat Apr 08 18:12:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSLez-0000R7-0i; Sat, 08 Apr 2006 18:12:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSLey-0000R2-Lo for dime@ietf.org; Sat, 08 Apr 2006 18:12:00 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSLey-0004Mh-6S for dime@ietf.org; Sat, 08 Apr 2006 18:12:00 -0400 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k38MBsEJ045826; Sat, 8 Apr 2006 18:11:55 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <443715B8.8080408@tari.toshiba.com> Date: Fri, 07 Apr 2006 21:45:28 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Ram O V Vishnu-A14676 Subject: Re: [Dime] CER/CEA on an open connection References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: Nakhjiri Madjid-MNAKHJI1 , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Thanks for the review. Comments inline: > Some clarifications and comments on the discussion on this thread: > > We would like to clarify the following practical scenarios of this > happenning: > 1. there are a list of published applications which the box support > and these are installed in the box. Now, some of them go down/up. This > would > get translated into change in peer capabilities. > 2. there is a new application which is getting installed/removed from > the box. > > We think that (1) is the most probable scenario. so, > there is value in giving a simple solution assuming that this change (in > capabilities) > is most probably temporary. If this is not the case, we are talking > about (2), which is > a major change in the box anyways. So in (2), we assume it is ok to > assume that > the connections to be reestablished. > Scenario (1) you mentioned above is what we are targeting. If scenario (2) means your going to reboot the box so renegotiation does not apply. > We would like to say that our design goals are: > 3. solution should be simple & as backward compatible as possible. > 4. minimize the FSM changes. > I agree. > We suggest: > 5. Updating peer capabilities done only using a CER/CEA in the open > state. > ok. > Sender of CER/CEA updates the local capabilities before sending the > message and > hence is a local decision. > This certainly simplifies things but it also implies that the sender of the CER mandates a change and the receiver has no choice but to accept it. In some sense, the scheme is no longer a re-negotiation but merely notifying the peer of a change. The proposed text was considering the case where the receiver of the CER cannot comply with the change for whatever reason. > 6. The rest of the processing of the CER/CEA will be as per the current > RFC. > Say for example, if there are no > common applications left with that peer, DIAMETER_NO_COMMON_APPLICATION > is sent in the > CEA and the connection is closed. > Perhaps regardless of whether scheme (5) is in use, a diameter node already knows prior to sending a CER that it will have no common application with a peer. To that end, CER/CEA exchange can be skipped in favor of formal connection termination. > Problems in the email thread under discussion & some comments: > 7. Cross over and sequencing of CER/CEA exchange. We dont think there is > a problem > here. Cant find any race condition. > Ok :) I guess we have more people favoring to strike this text. > 8. Mutual agreement to bring down applications will not work due to > possible relays > in between as Tolga has pointed out in the mailing list. > I guess there some confusion in the ml exchange regarding this issue :). I think we should really decouple end-to-end application signaling with peer-to-peer signaling since (as you say) there maybe intermediary nodes. As an example, a peer shutting down an application and notifying its immediate peer that it will no longer accept request for that application does not necessarily mean that the end-point application generating the request which is a few hops away should shutdown. With regards to application re-negotiation, the proposed text is commenting on the state/pre-existing state of the next hop peer whether it is a relay or the actual generator of the request. If the proposed text has is not clear on this the pls let me know and we can attempt to clarify. > 9. The DPR solution in the suggested text is not a good idea. Because > DPR cannot > advertise the latest local applications to the peer. This may cause the > race condition > and sequencing problem. This problem can be avoided by using the > approach which > we suggested in (5). > Hmmm ... DPR/DPA in the proposed text is not used to advertise the latest locally supported app. As I mentioned above, a diameter node can already determine whether it will not have a common application with a peer so there maybe no need to renegotiate. Also, I'm not clear on how this will cause a race condition. Hope this helps, victor > Regards, > Vishnu. > > Motorola India Electronics Pvt Ltd > +91 9844178052 > [*] Motorola Internal Use Only > > > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: Friday, April 07, 2006 6:44 PM > To: dime@ietf.org > Subject: RE: [Dime] CER/CEA on an open connection > > > Hi Victor, > > Once there is the assumption that shutting down applications is > completely decided in a local way -which as far as I understand > everybody agrees(?)-, I don't see a need for any type of serialization. > If you see a problem scenario, could you provide message flow for it, > otherwise IMHO there is no need to complicate things. > > Furthermore, there is also no need to do something special based on the > result code of CEA, if we want to honor "complete local decision for > application shutdown" principle. Regardless of CEA result, application > will be shut down -actually even wothout waiting for CEA-. > > Probably what we need to say is just that renegotiations are limited to > advertise new set of supported applications. > > Thanks, > Tolga > > >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: Friday, April 07, 2006 9:25 AM >> To: Tina TSOU >> Cc: asveren@ulticom.com; john.loughney@nokia.com; dime@ietf.org >> Subject: Re: [Dime] CER/CEA on an open connection >> >> >> Hi Tina, >> >> Comments inline: >> >>> Hi, >>> I think the schema is ok but for simultaneous renegotiation >>> serialization - "A Diameter node that receives a CER from a peer >>> from which it has sent its own pending CER MUST be able serialize >>> the simultaneous renegotiation. If the Diameter node is acting as a >>> responder (see Sec >>> 5.6) then it MUST give precedence to the renegotiation initiated by >>> its peer and send a CEA accordingly. If the Diameter node is acting >>> as an initiator (see Sec 5.6) then it MUST delay the renegotiation >>> initiated by its peer (the responder) and send a CEA >>> with Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY in order to >>> > retain > >>> the current state between them. The receiver of this CEA (the >>> responder) SHOULD retain its current state and proceed with the >>> > ongoing > >>> renegotiation initiated by its peer. It SHOULD retransmit its own >>> > CER to > >>> initiate another renegotiation after the current renegotiation >>> completes. Both renegotiations SHOULD be treated as separate and >>> sequential." >>> >>> Does any one understand why this spl. handling is needed in the >>> event of a renegotiation cross over? Even without this, I think each >>> > > >>> CER will be treated atomically by the receiver. >>> >> Maybe I'm wrong but I'm not clear on how multiple pending transactions >> > > >> can be resolved automatically without serialization or extra logic >> (i.e., election process in the rfc). Anyway, the basic idea of the >> text was to "assist" a diameter node in making sure serialization does >> > > >> occur. "Assistance" here implies that a diameter node need not be >> burdened with extra state/logic of handling simultaneous renegotiation >> > > >> since such renegotiation will be serialized. I don't have a strong >> opinion on this but if we get a consensus that we do not need to >> specify this behavior and let the implementations deal with it in >> their own way then we can make this text optional. >> >> hope this helps, >> victor >> >>> Tina >>> >>> ----- Original Message ----- From: >>> To: ; >>> Cc: >>> Sent: Thursday, April 06, 2006 11:11 AM >>> Subject: RE: [Dime] CER/CEA on an open connection >>> >>> >>> Hi all, >>> >>> >>> >>>>>> DIAMETER_APPLICATION_UNSUPPORTED. >>>>>> >>>>>> What is proposed is that a node initiating the change >>>>>> >>>> request should >>>> >>>>>> not terminate the supported application until the >>>>>> >>>> corresponding peer agrees. >>>> >>>>>> If the peer does not agree, the node initiating the change >>>>>> request has an alternative to gracefully terminate of the >>>>>> >>>> connection with the >>>> >>>>>> peer if it chooses to. Otherwise, it must honor its commitment to >>>>>> > > >>>>>> keep the application support. >>>>>> >>>>>> >>>>> [TOLGA]AFAICS, the moment you introduce some intelligence to that >>>>> procedure, e.g. receiver of CER aggreing with the >>>>> >>>> application getting >>>> >>>>> down, you need to be sure that you are communicating with your >>>>> application level peer. CER/CEA is hop-to-hop, it probably >>>>> >>>> won't do it >>>> >>>>> for a generic solution, where we have relay agents etc.. >>>>> >>>> between the endpoints. >>>> >>>> renegotiation is done between peers (one hope) not between >>>> end-points and the decision on wether to continue support for an >>>> application is local to a node. how a node will deal with not >>>> supporting an application anymore is up to the application itself. >>>> >>> I agree with Victor. >>> >>> John >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> >>> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Apr 08 18:43:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSM9U-0005WK-Os; Sat, 08 Apr 2006 18:43:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSM9T-0005WF-UF for dime@ietf.org; Sat, 08 Apr 2006 18:43:31 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSM9T-0005Hz-Di for dime@ietf.org; Sat, 08 Apr 2006 18:43:31 -0400 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k38MhPVL045878; Sat, 8 Apr 2006 18:43:26 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44371D1B.9000308@tari.toshiba.com> Date: Fri, 07 Apr 2006 22:16:59 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Timothy Smith Subject: Re: [Dime] CER/CEA on an open connection References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: Nakhjiri Madjid-MNAKHJI1 , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Timothy, Thanks for the good discussion, this is really helpful. > > Good summary! I agree with most of your points. I'm not sure, > however, that I distinguish between (1) and (2). I think whether > temporary or not, we should handle CER/CEA exchanges in the same manner. I'm just speculating but I think (2) refers to application change requiring a reboot. > > I agree with your design goals (3) ,(4), and suggestions (5) , (6) , > (8), and (9). If some are more in favor of scheme (5) , maybe we need more opinion on whether the receiver of the CEA can always comply with the change request regardless of any scenario. I think (6) and (9) can be avoided regardless of which scheme we decide to use (see my previous reply). > > Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont > think there is a problem here. Cant find any race condition." I > thought that there was a subtle problem here, but I think you are > right. Given that the connection insures sequencing, the latest CER > or CEA that you receive is what you should use as the list of > negotiated App Ids. > Mmmm... i'm not sure that the connection itself ensures sequencing. Anyway, majority rule favors removing this text. > Should there be some discussion on the retry mechanism? You send a > CER, and no response is received. Does this mean that the peer just > doesn't know how to renegotiate? Should we ignore and retry every n > seconds? Bring down the connection? Or do we just continue to use > the apps from the initial negotiation? My preference on this is that > we should require a CEA response to the CER. If the CEA is not > received, we shutdown the connection and start over. This would > address compatibility issues with existing implementations. It would > also be consistent with the processing of the initial CER/CEA. > The current proposal has text mentioning the use of version number of initial CER/CEA exchange to determine whether a peer is capable of renegotiating. If a node knows that its peer is not capable of re-negotiating then the node should not initiate re-negotiation. In this scheme, existing implementations will be spared of any change. regards, victor > Best Regards, > Timothy Smith > > tjsmith@us.ibm.com > (919) 254-4723 > > > > *"Ram O V Vishnu-A14676" * > > 04/08/2006 12:56 AM > > > To > > cc > Nakhjiri Madjid-MNAKHJI1 > Subject > RE: [Dime] CER/CEA on an open connection > > > > > > > > > > Hi, > > Some clarifications and comments on the discussion on this thread: > > We would like to clarify the following practical scenarios of this > happenning: > 1. there are a list of published applications which the box support > and these are installed in the box. Now, some of them go down/up. This > would > get translated into change in peer capabilities. > 2. there is a new application which is getting installed/removed from > the box. > > We think that (1) is the most probable scenario. so, > there is value in giving a simple solution assuming that this change (in > capabilities) > is most probably temporary. If this is not the case, we are talking > about (2), which is > a major change in the box anyways. So in (2), we assume it is ok to > assume that > the connections to be reestablished. > > We would like to say that our design goals are: > 3. solution should be simple & as backward compatible as possible. > 4. minimize the FSM changes. > > We suggest: > 5. Updating peer capabilities done only using a CER/CEA in the open > state. > Sender of CER/CEA updates the local capabilities before sending the > message and > hence is a local decision. > > 6. The rest of the processing of the CER/CEA will be as per the current > RFC. > Say for example, if there are no > common applications left with that peer, DIAMETER_NO_COMMON_APPLICATION > is sent in the > CEA and the connection is closed. > > Problems in the email thread under discussion & some comments: > 7. Cross over and sequencing of CER/CEA exchange. We dont think there is > a problem > here. Cant find any race condition. > > 8. Mutual agreement to bring down applications will not work due to > possible relays > in between as Tolga has pointed out in the mailing list. > > 9. The DPR solution in the suggested text is not a good idea. Because > DPR cannot > advertise the latest local applications to the peer. This may cause the > race condition > and sequencing problem. This problem can be avoided by using the > approach which > we suggested in (5). > > Regards, > Vishnu. > > Motorola India Electronics Pvt Ltd > +91 9844178052 > [*] Motorola Internal Use Only > > > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: Friday, April 07, 2006 6:44 PM > To: dime@ietf.org > Subject: RE: [Dime] CER/CEA on an open connection > > > Hi Victor, > > Once there is the assumption that shutting down applications is > completely decided in a local way -which as far as I understand > everybody agrees(?)-, I don't see a need for any type of serialization. > If you see a problem scenario, could you provide message flow for it, > otherwise IMHO there is no need to complicate things. > > Furthermore, there is also no need to do something special based on the > result code of CEA, if we want to honor "complete local decision for > application shutdown" principle. Regardless of CEA result, application > will be shut down -actually even wothout waiting for CEA-. > > Probably what we need to say is just that renegotiations are limited to > advertise new set of supported applications. > > Thanks, > Tolga > > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: Friday, April 07, 2006 9:25 AM > > To: Tina TSOU > > Cc: asveren@ulticom.com; john.loughney@nokia.com; dime@ietf.org > > Subject: Re: [Dime] CER/CEA on an open connection > > > > > > Hi Tina, > > > > Comments inline: > > > Hi, > > > I think the schema is ok but for simultaneous renegotiation > > > serialization - "A Diameter node that receives a CER from a peer > > > from which it has sent its own pending CER MUST be able serialize > > > the simultaneous renegotiation. If the Diameter node is acting as a > > > responder (see Sec > > > 5.6) then it MUST give precedence to the renegotiation initiated by > > > its peer and send a CEA accordingly. If the Diameter node is acting > > > as an initiator (see Sec 5.6) then it MUST delay the renegotiation > > > initiated by its peer (the responder) and send a CEA > > > with Result-Code AVP set to DIAMETER_UNABLE_TO_COMPLY in order to > retain > > > the current state between them. The receiver of this CEA (the > > > responder) SHOULD retain its current state and proceed with the > ongoing > > > renegotiation initiated by its peer. It SHOULD retransmit its own > CER to > > > initiate another renegotiation after the current renegotiation > > > completes. Both renegotiations SHOULD be treated as separate and > > > sequential." > > > > > > Does any one understand why this spl. handling is needed in the > > > event of a renegotiation cross over? Even without this, I think each > > > > CER will be treated atomically by the receiver. > > Maybe I'm wrong but I'm not clear on how multiple pending transactions > > > can be resolved automatically without serialization or extra logic > > (i.e., election process in the rfc). Anyway, the basic idea of the > > text was to "assist" a diameter node in making sure serialization does > > > occur. "Assistance" here implies that a diameter node need not be > > burdened with extra state/logic of handling simultaneous renegotiation > > > since such renegotiation will be serialized. I don't have a strong > > opinion on this but if we get a consensus that we do not need to > > specify this behavior and let the implementations deal with it in > > their own way then we can make this text optional. > > > > hope this helps, > > victor > > > > > > Tina > > > > > > ----- Original Message ----- From: > > > To: ; > > > Cc: > > > Sent: Thursday, April 06, 2006 11:11 AM > > > Subject: RE: [Dime] CER/CEA on an open connection > > > > > > > > > Hi all, > > > > > > > > >>>> DIAMETER_APPLICATION_UNSUPPORTED. > > >>>> > > >>>> What is proposed is that a node initiating the change > > >> request should > > >>>> not terminate the supported application until the > > >> corresponding peer agrees. > > >>>> If the peer does not agree, the node initiating the change > > >>>> request has an alternative to gracefully terminate of the > > >> connection with the > > >>>> peer if it chooses to. Otherwise, it must honor its commitment to > > > >>>> keep the application support. > > >>>> > > >>> [TOLGA]AFAICS, the moment you introduce some intelligence to that > > >>> procedure, e.g. receiver of CER aggreing with the > > >> application getting > > >>> down, you need to be sure that you are communicating with your > > >>> application level peer. CER/CEA is hop-to-hop, it probably > > >> won't do it > > >>> for a generic solution, where we have relay agents etc.. > > >> between the endpoints. > > >>> > > >> renegotiation is done between peers (one hope) not between > > >> end-points and the decision on wether to continue support for an > > >> application is local to a node. how a node will deal with not > > >> supporting an application anymore is up to the application itself. > > > > > > I agree with Victor. > > > > > > John > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Apr 09 06:04:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSWmK-0007aG-3f; Sun, 09 Apr 2006 06:04:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSWmI-0007aB-M3 for dime@ietf.org; Sun, 09 Apr 2006 06:04:18 -0400 Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSWmH-00063J-Rc for dime@ietf.org; Sun, 09 Apr 2006 06:04:18 -0400 Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Apr 2006 12:04:16 +0200 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.228]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Sun, 9 Apr 2006 12:04:16 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Importance: normal Priority: normal Subject: RE: [Dime] Re: draft-tschofenig-dime-mip6-integrated-00.txt Date: Sun, 9 Apr 2006 12:03:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: draft-tschofenig-dime-mip6-integrated-00.txt thread-index: AcZYjyuI6BlD67TrT4ip46RY8PYH+wACu10QAMiFODA= From: "Giaretta Gerardo" To: X-OriginalArrivalTime: 09 Apr 2006 10:04:16.0035 (UTC) FILETIME=[F5ACA730:01C65BBC] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: Charles.Perkins@nokia.com, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0272792989==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0272792989== Content-Type: multipart/alternative; boundary="----=_NextPart_000_51E43_01C65BCD.B9D81FD0" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_51E43_01C65BCD.B9D81FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, one comment below..=20 > > I have some doubts about including this at this point. The=20 > >reason is that delivering IPv4 HA address to the MN is not=20 > >described in the Integrated scenario draft. I would prefer=20 > >that this feature be added in this draft (mip6) and then=20 > >include it in the DiME draft. > > > > what do you think ? >=20 > As a high-level comment, it might be interesting to have a=20 > solution that > works with dual-stack MIP, but I'd like to see if others are=20 > interested > in it as well. >=20 The current MIP6 DS draft already describes a mechanism to assign an IPv4 HoA, that is based on BU/BA messages. I asked some folks if there was interest to include this choice also in the current MIPv6 bootstrapping drafts (i.e. in a DHCP or IKEv2) but they seem OK with the current solution. The rational is that the MN is bootstrapping MIPv6 and therefore is assigned an IPv6 HoA; if it wants an IPv4 HoA, it can ask for it in the subsequent BUs. Therefore, based on current solution drafts, there is no requirement to have a AAA-based IPv4 HoA assignment. But I'm OK with defining it if there is interest. --Gerardo=20 > John >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_51E43_01C65BCD.B9D81FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi John,

one = comment below..

> > I have some doubts about including this at = this point. The
> >reason is that delivering IPv4 HA address to the = MN is not
> >described in the Integrated scenario draft. I would = prefer
> >that this feature be added in this draft (mip6) and then =
> >include it in the DiME draft.
> >
> > what do you think = ?
>
> As a high-level comment, it might be interesting to have a =
> solution that
> works with dual-stack MIP, but I'd like to see = if others are
> interested
> in it as well.
>

The = current MIP6 DS draft already describes a mechanism to assign an
IPv4 = HoA, that is based on BU/BA messages.
I asked some folks if there was = interest to include this choice also in
the current MIPv6 = bootstrapping drafts (i.e. in a DHCP or IKEv2) but
they seem OK with = the current solution. The rational is that the MN is
bootstrapping = MIPv6 and therefore is assigned an IPv6 HoA; if it wants
an IPv4 HoA, = it can ask for it in the subsequent BUs.

Therefore, based on = current solution drafts, there is no requirement to
have a AAA-based = IPv4 HoA assignment. But I'm OK with defining it if
there is = interest.

--Gerardo

> John
>
> = _______________________________________________
> DiME mailing = list
> DiME@ietf.org
> = https://www1.ietf.org/mailman/listinfo/dime
>
--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_51E43_01C65BCD.B9D81FD0-- --===============0272792989== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0272792989==-- From dime-bounces@ietf.org Sun Apr 09 21:37:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSlLT-00048p-O7; Sun, 09 Apr 2006 21:37:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSlLT-00045J-0j for dime@ietf.org; Sun, 09 Apr 2006 21:37:35 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSlLS-0008LJ-AO for dime@ietf.org; Sun, 09 Apr 2006 21:37:34 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k3A1bXeE016557 for ; Sun, 9 Apr 2006 21:37:33 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k3A1elKM067908 for ; Sun, 9 Apr 2006 19:40:49 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k3A1bUQC015197 for ; Sun, 9 Apr 2006 19:37:30 -0600 Received: from d03nm114.boulder.ibm.com (d03nm114.boulder.ibm.com [9.17.195.140]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k3A1bUuV015194; Sun, 9 Apr 2006 19:37:30 -0600 In-Reply-To: <44371D1B.9000308@tari.toshiba.com> To: Victor Fajardo MIME-Version: 1.0 Subject: Re: [Dime] CER/CEA on an open connection X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Timothy Smith Date: Sun, 9 Apr 2006 21:40:37 -0400 X-MIMETrack: Serialize by Router on D03NM114/03/M/IBM(Release 7.0.1HF43 | March 10, 2006) at 04/09/2006 19:40:38, Serialize complete at 04/09/2006 19:40:38 X-Spam-Score: 0.5 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: Nakhjiri Madjid-MNAKHJI1 , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1389497451==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1389497451== Content-Type: multipart/alternative; boundary="=_alternative 0008EDDB8525714C_=" This is a multipart message in MIME format. --=_alternative 0008EDDB8525714C_= Content-Type: text/plain; charset="US-ASCII" Hi Victor, Thanks for your response. Comments below" >> >> Good summary! I agree with most of your points. I'm not sure, >> however, that I distinguish between (1) and (2). I think whether >> temporary or not, we should handle CER/CEA exchanges in the same manner. >I'm just speculating but I think (2) refers to application change >requiring a reboot. >> >> I agree with your design goals (3) ,(4), and suggestions (5) , (6) , >> (8), and (9). >If some are more in favor of scheme (5) , maybe we need more opinion on >whether the receiver of the CEA can always comply with the change >request regardless of any scenario. I think (6) and (9) can be avoided >regardless of which scheme we decide to use (see my previous reply). > Here is the text from your previous reply: "This certainly simplifies things but it also implies that the sender of the CER mandates a change and the receiver has no choice but to accept it. In some sense, the scheme is no longer a re-negotiation but merely notifying the peer of a change. The proposed text was considering the case where the receiver of the CER cannot comply with the change for whatever reason." I tend to agree with the notion that the sender of the CER is mandating a change. The receiver does have a choice just as it has a choice in the original CER/CEA exchange. The receiver should respond with the list of App Ids that is the intersection of what was listed in the CER and of what App Ids it wishes to support. It is a renegotiation which may add or remove App Ids. But either way, it is telling the other side about its intentions. I don't thing the receiving side has any choice but to participate in the renegotiation. For example, if an app Id is being removed, the side where it is being removed renegotiates with a CER that does not include that App ID. It doesn't do the receiving side any good to decline this as the App will be shut down regardless. >> Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont >> think there is a problem here. Cant find any race condition." I >> thought that there was a subtle problem here, but I think you are >> right. Given that the connection insures sequencing, the latest CER >> or CEA that you receive is what you should use as the list of >> negotiated App Ids. >> >Mmmm... i'm not sure that the connection itself ensures sequencing. >Anyway, majority rule favors removing this text. >> Should there be some discussion on the retry mechanism? You send a >> CER, and no response is received. Does this mean that the peer just >> doesn't know how to renegotiate? Should we ignore and retry every n >> seconds? Bring down the connection? Or do we just continue to use >> the apps from the initial negotiation? My preference on this is that >> we should require a CEA response to the CER. If the CEA is not >> received, we shutdown the connection and start over. This would >> address compatibility issues with existing implementations. It would >> also be consistent with the processing of the initial CER/CEA. >> >The current proposal has text mentioning the use of version number of >initial CER/CEA exchange to determine whether a peer is capable of >renegotiating. If a node knows that its peer is not capable of >re-negotiating then the node should not initiate re-negotiation. In this >scheme, existing implementations will be spared of any change. I'm not sure I picked up the version number. I don't see a reason to do something special. I would simply like to renegotiate. If the other side does not respond to the CER, you shut down the connection and restart it after some period of time. This is what you would do if your initial CER did not get a response. How is this different? Best Regards, Timothy Smith Vishnu wrote: > Hi, > > Some clarifications and comments on the discussion on this thread: > > We would like to clarify the following practical scenarios of this > happenning: > 1. there are a list of published applications which the box support > and these are installed in the box. Now, some of them go down/up. This > would > get translated into change in peer capabilities. > 2. there is a new application which is getting installed/removed from > the box. > > We think that (1) is the most probable scenario. so, > there is value in giving a simple solution assuming that this change (in > capabilities) > is most probably temporary. If this is not the case, we are talking > about (2), which is > a major change in the box anyways. So in (2), we assume it is ok to > assume that > the connections to be reestablished. > > We would like to say that our design goals are: > 3. solution should be simple & as backward compatible as possible. > 4. minimize the FSM changes. > > We suggest: > 5. Updating peer capabilities done only using a CER/CEA in the open > state. > Sender of CER/CEA updates the local capabilities before sending the > message and > hence is a local decision. > > 6. The rest of the processing of the CER/CEA will be as per the current > RFC. > Say for example, if there are no > common applications left with that peer, DIAMETER_NO_COMMON_APPLICATION > is sent in the > CEA and the connection is closed. > > Problems in the email thread under discussion & some comments: > 7. Cross over and sequencing of CER/CEA exchange. We dont think there is > a problem > here. Cant find any race condition. > > 8. Mutual agreement to bring down applications will not work due to > possible relays > in between as Tolga has pointed out in the mailing list. > > 9. The DPR solution in the suggested text is not a good idea. Because > DPR cannot > advertise the latest local applications to the peer. This may cause the > race condition > and sequencing problem. This problem can be avoided by using the > approach which > we suggested in (5). > > Regards, > Vishnu. tjsmith@us.ibm.com (919) 254-4723 --=_alternative 0008EDDB8525714C_= Content-Type: text/html; charset="US-ASCII"
Hi Victor,

Thanks for your response.  Comments below"
>>
>> Good summary!  I agree with most of your points.  I'm not sure,
>> however, that I distinguish between (1) and (2).  I think whether
>> temporary or not, we should handle CER/CEA exchanges in the same manner.
>I'm just speculating but I think (2) refers to application change
>requiring a reboot.
>>
>> I agree with your design goals (3) ,(4), and suggestions (5) , (6) ,
>> (8), and (9).
>If some are more in favor of scheme (5) ,  maybe we need more opinion on
>whether the receiver of the CEA can always comply with the change
>request regardless of any scenario. I think (6) and (9) can be avoided
>regardless of which scheme we decide to use (see my previous reply).
>

Here is the text from your previous reply:
"This certainly simplifies things but it also implies that the sender of
the CER mandates a change and the receiver has no choice but to accept
it. In some sense, the scheme is no longer a re-negotiation but merely
notifying the peer of a change. The proposed text was considering the
case where the receiver of the CER cannot comply with the change for
whatever reason."

I tend to agree with the notion that the sender of the CER is mandating
a change.  The receiver does have a choice just as it has a choice in the
original CER/CEA exchange.  The receiver should respond with the list of
App Ids that is the intersection of what was listed in the CER and of what
App Ids it wishes to support.  It is a renegotiation which may add or
remove App Ids.  But either way, it is telling the other side about its
intentions.  I don't thing the receiving side has any choice but to participate
in the renegotiation.  For example, if an app Id is being removed, the side
where it is being removed renegotiates with a CER that does not include that
App ID.  It doesn't do the receiving side any good to decline this as the App
will be shut down regardless.  


>> Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont
>> think there is a problem here. Cant find any race condition."  I
>> thought that there was a subtle problem here, but I think you are
>> right.  Given that the connection insures sequencing, the latest CER
>> or CEA that you receive is what you should use as the list of
>> negotiated App Ids.
>>
>Mmmm... i'm not sure that the connection itself ensures sequencing.
>Anyway, majority rule favors removing this text.
>> Should there be some discussion on the retry mechanism?  You send a
>> CER, and no response is received.  Does this mean that the peer just
>> doesn't know how to renegotiate?  Should we ignore and retry every n
>> seconds?  Bring down the connection?  Or do we just continue to use
>> the apps from the initial negotiation? My preference on this is that
>> we should require a CEA response to the CER.  If the CEA is not
>> received, we shutdown the connection and start over.  This would
>> address compatibility issues with existing implementations.  It would
>> also be consistent with the processing of the initial CER/CEA.
>>
>The current proposal has text mentioning the use of version number of
>initial CER/CEA exchange to determine whether a peer is capable of
>renegotiating. If a node knows that its  peer is not capable of
>re-negotiating then the node should not initiate re-negotiation. In this
>scheme, existing implementations will be spared of any change.
I'm not sure I picked up the version number.  I don't see a reason to do
something special.  I would simply like to renegotiate.  If the other side
does not respond to the CER, you shut down the connection and restart it
after some period of time.  This is what you would do if your initial CER
did not get a response.  How is this different?


Best Regards,
Timothy Smith

Vishnu wrote:
> Hi,
>
> Some clarifications and comments on the discussion on this thread:
>
> We would like to clarify the following practical scenarios of this
> happenning:
> 1. there are a list of published applications which the box support
> and these are installed in the box. Now, some of them go down/up. This
> would
> get translated into change in peer capabilities.
> 2. there is a new application which is getting installed/removed from
> the box.
>
> We think that (1) is the most probable scenario. so,
> there is value in giving a simple solution assuming that this change (in
> capabilities)
> is most probably temporary. If this is not the case, we are talking
> about (2), which is
> a major change in the box anyways. So in (2), we assume it is ok to
> assume that
> the connections to be reestablished.
>
> We would like to say that our design goals are:
> 3. solution should be simple & as backward compatible as possible.
> 4. minimize the FSM changes.
>
> We suggest:
> 5. Updating peer capabilities done only using a CER/CEA in the open
> state.
> Sender of CER/CEA updates the local capabilities before sending the
> message and
> hence is a local decision.
>
> 6. The rest of the processing of the CER/CEA will be as per the current
> RFC.
> Say for example, if there are no
> common applications left with that peer, DIAMETER_NO_COMMON_APPLICATION
> is sent in the
> CEA and the connection is closed.
>
> Problems in the email thread under discussion & some comments:
> 7. Cross over and sequencing of CER/CEA exchange. We dont think there is
> a problem
> here. Cant find any race condition.
>
> 8. Mutual agreement to bring down applications will not work due to
> possible relays
> in between as Tolga has pointed out in the mailing list.
>
> 9. The DPR solution in the suggested text is not a good idea. Because
> DPR cannot
> advertise the latest local applications to the peer. This may cause the
> race condition
> and sequencing problem. This problem can be avoided by using the
> approach which
> we suggested in (5).
>
> Regards,
> Vishnu.

tjsmith@us.ibm.com
(919) 254-4723
 --=_alternative 0008EDDB8525714C_=-- --===============1389497451== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1389497451==-- From dime-bounces@ietf.org Mon Apr 10 02:38:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSq2S-0001y9-2n; Mon, 10 Apr 2006 02:38:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSq2Q-0001xv-K3 for dime@ietf.org; Mon, 10 Apr 2006 02:38:14 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSq2Q-0002M3-3E for dime@ietf.org; Mon, 10 Apr 2006 02:38:14 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k3A6nlg3007605 for ; Sun, 9 Apr 2006 23:49:47 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3A6nVlf010687 for ; Mon, 10 Apr 2006 01:49:32 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] CER/CEA on an open connection Date: Mon, 10 Apr 2006 14:38:10 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] CER/CEA on an open connection Thread-Index: AcZcP1ysMufhOrnARD6KhYTwLu8YeQAKFqqg From: "Ram O V Vishnu-A14676" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: Nakhjiri Madjid-MNAKHJI1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor/Timothy, 1. Comments on Retry mechanism : To summarize, we are sending CER in open state because our capabilities (supported apps) are changing=20 and we would like to update the peer about it. We will maintain open state.=20 we may not receive a CEA due to the following possible reasons:=20 1.1) The peer does not support CER in open state. In such a case, peer might still originate unsupported app messages towards us which will result in "DIAMETER_APPLICATION_UNSUPPORTED" error from us. We can leave it to the peer implementation to "correct this error" as mentioned in sec 7.1.3 of RFC 3588. This will take care of the case where there is relay/proxy in between.=20 1.2) Connection is lost with the peer, in which case the DWR/DWA mechanism should step in. The solution suggested by Timothy (to wait for for CEA & timer) will need changes to FSM, even though we agree that this is consistent with the initial CER/CEA scenario. Ofcourse the use of "DIAMETER_APPLICATION_UNSUPPORTED" will result in added (unecessary traffic) incase the peer/proxy is not clever enough to correct its behaviour. This can be avoided by using the version number exchange as Victor pointed out. So, we will not attempt the CER in open state to such a peer which doesnt support CERs in open state, and can go for a reconnection.=20 2. Comments on "re-negotiation" We think that what we need is an advertisement mechanism and not a negotiation mechanism. The CER/CEA in open state allows us to do that. We are proposing that the receiver of the CER takes the decision on the disconnection. Thus we are able to delay the disconnection (assuming that the point mentioned in my email before that the app changes are temporary). Since CER allows us to convey the latest set of supported apps to the peer, we favour the CER to the DPR. Following is a scenario where sending CER/CEA is better than the DPR mechanism.=20 (Apologies if the figure is mangled due to tab settings). =20 Initial exchanged app list:=20 A: 1,2,3 B:2 2 went down 3 came up just when 2 went down on A ________ ________ |A |----DPR---> |B | | | | | | |<---CER---- | | |______| [3] |______| <---DPA---- this in our understanding will result in reconnection even thou there=20 is 3 in common. Initial exchanged app list:=20 A: 1,2,3 B:2 2 went down 3 came up just when 2 went down on A ________ ________ |A |----CER---> |B | | | [1,3] | | | |<---CER---- | | |_______| [2,3] |_______| ----CEA----> [1,3] <---CEA----- [2,3] This will avoid a reconnection, because 3 is in common. Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only -----Original Message----- From: Timothy Smith [mailto:tjsmith@us.ibm.com]=20 Sent: Monday, April 10, 2006 7:11 AM To: Victor Fajardo Cc: dime@ietf.org; Nakhjiri Madjid-MNAKHJI1; Ram O V Vishnu-A14676 Subject: Re: [Dime] CER/CEA on an open connection Hi Victor,=20 Thanks for your response. Comments below"=20 >> >> Good summary! I agree with most of your points. I'm not sure,=20 >> however, that I distinguish between (1) and (2). I think whether=20 >> temporary or not, we should handle CER/CEA exchanges in the same manner. >I'm just speculating but I think (2) refers to application change=20 >requiring a reboot. >> >> I agree with your design goals (3) ,(4), and suggestions (5) , (6) ,=20 >> (8), and (9). >If some are more in favor of scheme (5) , maybe we need more opinion on=20 >whether the receiver of the CEA can always comply with the change=20 >request regardless of any scenario. I think (6) and (9) can be avoided=20 >regardless of which scheme we decide to use (see my previous reply). >=20 Here is the text from your previous reply:=20 "This certainly simplifies things but it also implies that the sender of the CER mandates a change and the receiver has no choice but to accept=20 it. In some sense, the scheme is no longer a re-negotiation but merely=20 notifying the peer of a change. The proposed text was considering the=20 case where the receiver of the CER cannot comply with the change for=20 whatever reason."=20 I tend to agree with the notion that the sender of the CER is mandating=20 a change. The receiver does have a choice just as it has a choice in the=20 original CER/CEA exchange. The receiver should respond with the list of App Ids that is the intersection of what was listed in the CER and of what=20 App Ids it wishes to support. It is a renegotiation which may add or=20 remove App Ids. But either way, it is telling the other side about its=20 intentions. I don't thing the receiving side has any choice but to participate=20 in the renegotiation. For example, if an app Id is being removed, the side=20 where it is being removed renegotiates with a CER that does not include that=20 App ID. It doesn't do the receiving side any good to decline this as the App=20 will be shut down regardless. =20 >> Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont=20 >> think there is a problem here. Cant find any race condition." I=20 >> thought that there was a subtle problem here, but I think you are=20 >> right. Given that the connection insures sequencing, the latest CER=20 >> or CEA that you receive is what you should use as the list of=20 >> negotiated App Ids. >> >Mmmm... i'm not sure that the connection itself ensures sequencing.=20 >Anyway, majority rule favors removing this text. >> Should there be some discussion on the retry mechanism? You send a=20 >> CER, and no response is received. Does this mean that the peer just=20 >> doesn't know how to renegotiate? Should we ignore and retry every n=20 >> seconds? Bring down the connection? Or do we just continue to use=20 >> the apps from the initial negotiation? My preference on this is that=20 >> we should require a CEA response to the CER. If the CEA is not=20 >> received, we shutdown the connection and start over. This would=20 >> address compatibility issues with existing implementations. It would >> also be consistent with the processing of the initial CER/CEA. >> >The current proposal has text mentioning the use of version number of=20 >initial CER/CEA exchange to determine whether a peer is capable of=20 >renegotiating. If a node knows that its peer is not capable of=20 >re-negotiating then the node should not initiate re-negotiation. In this=20 >scheme, existing implementations will be spared of any change. I'm not sure I picked up the version number. I don't see a reason to do something special. I would simply like to renegotiate. If the other side=20 does not respond to the CER, you shut down the connection and restart it after some period of time. This is what you would do if your initial CER=20 did not get a response. How is this different?=20 Best Regards,=20 Timothy Smith=20 Vishnu wrote:=20 > Hi, > > Some clarifications and comments on the discussion on this thread: > > We would like to clarify the following practical scenarios of this > happenning: > 1. there are a list of published applications which the box support > and these are installed in the box. Now, some of them go down/up. This > would > get translated into change in peer capabilities. > 2. there is a new application which is getting installed/removed from > the box. > > We think that (1) is the most probable scenario. so, > there is value in giving a simple solution assuming that this change (in > capabilities) > is most probably temporary. If this is not the case, we are talking > about (2), which is > a major change in the box anyways. So in (2), we assume it is ok to > assume that > the connections to be reestablished. > > We would like to say that our design goals are: > 3. solution should be simple & as backward compatible as possible. > 4. minimize the FSM changes. > > We suggest: > 5. Updating peer capabilities done only using a CER/CEA in the open > state. > Sender of CER/CEA updates the local capabilities before sending the > message and > hence is a local decision. > > 6. The rest of the processing of the CER/CEA will be as per the current > RFC. > Say for example, if there are no > common applications left with that peer, DIAMETER_NO_COMMON_APPLICATION > is sent in the > CEA and the connection is closed. > > Problems in the email thread under discussion & some comments: > 7. Cross over and sequencing of CER/CEA exchange. We dont think there is > a problem > here. Cant find any race condition. > > 8. Mutual agreement to bring down applications will not work due to > possible relays > in between as Tolga has pointed out in the mailing list. > > 9. The DPR solution in the suggested text is not a good idea. Because > DPR cannot > advertise the latest local applications to the peer. This may cause the > race condition > and sequencing problem. This problem can be avoided by using the > approach which > we suggested in (5). > > Regards, > Vishnu.=20 tjsmith@us.ibm.com (919) 254-4723 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Apr 10 04:43:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSrzr-0004CR-MP; Mon, 10 Apr 2006 04:43:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSrzh-00049D-Fy for dime@ietf.org; Mon, 10 Apr 2006 04:43:33 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSrrB-0006w2-K7 for dime@ietf.org; Mon, 10 Apr 2006 04:34:47 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 10:34:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re: draft-tschofenig-dime-mip6-integrated-00.txt Date: Mon, 10 Apr 2006 10:34:41 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03BFB3BA@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: draft-tschofenig-dime-mip6-integrated-00.txt Thread-Index: AcZYjyuI6BlD67TrT4ip46RY8PYH+wACu10QAMiFODAALs07kA== From: To: , X-OriginalArrivalTime: 10 Apr 2006 08:34:43.0989 (UTC) FILETIME=[9E193C50:01C65C79] X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Charles.Perkins@nokia.com, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Gerardo,=20 > Hi John, >=20 > one comment below..=20 >=20 > > > I have some doubts about including this at this point. The=20 > > >reason is that delivering IPv4 HA address to the MN is not=20 > > >described in the Integrated scenario draft. I would prefer=20 > > >that this feature be added in this draft (mip6) and then=20 > > >include it in the DiME draft. > > > > > > what do you think ? > >=20 > > As a high-level comment, it might be interesting to have a=20 > > solution that > > works with dual-stack MIP, but I'd like to see if others are=20 > > interested > > in it as well. > >=20 >=20 > The current MIP6 DS draft already describes a mechanism to assign an > IPv4 HoA, that is based on BU/BA messages. > I asked some folks if there was interest to include this=20 > choice also in > the current MIPv6 bootstrapping drafts (i.e. in a DHCP or IKEv2) but > they seem OK with the current solution. The rational is that the MN is > bootstrapping MIPv6 and therefore is assigned an IPv6 HoA; if it wants > an IPv4 HoA, it can ask for it in the subsequent BUs. >=20 > Therefore, based on current solution drafts, there is no=20 > requirement to > have a AAA-based IPv4 HoA assignment. But I'm OK with defining it if > there is interest. My original question was whether AAA-based IPv4 HA assignment should be supported -- in addition to the DNS based mechanism currently described in the MIP6 DS draft. What do you think about that? Imo the current IPv4 HoA assignment based on BU/BA messages seems to be sufficient. Cheers, Jouni >=20 > --Gerardo=20 >=20 > > John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Apr 10 05:27:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsgh-0007lc-4N; Mon, 10 Apr 2006 05:27:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsgf-0007lW-MN for dime@ietf.org; Mon, 10 Apr 2006 05:27:57 -0400 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSsgd-0000PL-5w for dime@ietf.org; Mon, 10 Apr 2006 05:27:57 -0400 Received: from etri04q4sqc7zc ([129.254.12.66]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 18:30:35 +0900 From: "Junghoon Jee" To: "'Giaretta Gerardo'" , , , Subject: RE: [Dime] Re: Diameter MIPv6 Date: Mon, 10 Apr 2006 18:27:48 +0900 Message-ID: <051801c65c81$07f8f2d0$420cfe81@etri04q4sqc7zc> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZZ1XDirK/7jFmTTj++yS6+a1KIcQATleeQAJcm7iA= In-Reply-To: X-OriginalArrivalTime: 10 Apr 2006 09:30:36.0020 (UTC) FILETIME=[6C109340:01C65C81] X-Spam-Score: 0.1 (/) X-Scan-Signature: 07d4bcb4600b627a0786c2557bc62e06 Cc: gdommety@cisco.com, 'Demaria Elena' , dime@ietf.org, 'Guardini Ivano' , basavaraj.patil@nokia.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1861171811==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1861171811== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0519_01C65CCC.77E09AD0" This is a multi-part message in MIME format. ------=_NextPart_000_0519_01C65CCC.77E09AD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, only viewing from the solution components like HA, HoA, security keying material. However, seeing from the overall procedure through the AAA involvement, there exists marginal distinction between two scenarios.=20 Therefore, separate drafts are better in moving forward, IMO. =20 -Junghoon _____ =20 From: Giaretta Gerardo [mailto:gerardo.giaretta@telecomitalia.it]=20 Sent: Friday, April 07, 2006 6:21 PM To: Junghoon Jee; jouni.korhonen@teliasonera.com; hannes.tschofenig@siemens.com; julien.bournelle@int-evry.fr Cc: gdommety@cisco.com; Demaria Elena; basavaraj.patil@nokia.com; dime@ietf.org; Guardini Ivano Subject: RE: [Dime] Re: Diameter MIPv6 =20 The only difference between the two MIP6 bootstrapping solutions is the Home Agent assignment via DHCP, that requires new capability in NAS-AAA interface. All other requirements and functionality are common to split and integrated solutions. And what we specify for split needs to be implemented also for integrated (AAA-HA interface). There are moreover other common requirements that may be not related to bootstrapping (e.g. session termination) and that are in common to both scenarios, too. I still think one draft is better. --Gerardo=20 > -----Original Message----- > From: Junghoon Jee [mailto:jhjee@etri.re.kr]=20 > Sent: venerd=EC 7 aprile 2006 1.54 > To: jouni.korhonen@teliasonera.com;=20 > hannes.tschofenig@siemens.com; julien.bournelle@int-evry.fr > Cc: gdommety@cisco.com; Demaria Elena;=20 > basavaraj.patil@nokia.com; Giaretta Gerardo; dime@ietf.org;=20 > Guardini Ivano > Subject: Re: [Dime] Re: Diameter MIPv6 >=20 > Hi all, >=20 > I'd suggest to having _two_ DIME drafts for integrated and split case > because the overall bootstrapping procedures are different in=20 > each case. > Please take a look at the current suggested drafts from Hannes, > then might be in the same line with me. :-) >=20 > As a side note:=20 > Listing up AAA requirements through _single_ document is still valid > as I mentioned in the previous MIP6 WG meeting. >=20 > Thanks, > -Junghoon >=20 > ----- Original Message -----=20 > From:=20 > To: ;=20 > Cc: ; ;=20 > ; ;=20 > ;=20 > Sent: Thursday, April 06, 2006 9:58 PM > Subject: RE: [Dime] Re: Diameter MIPv6 >=20 >=20 >=20 > I would also go for two different documents because of the > differences in solution approaches and for the general > clarity. >=20 > Cheers, > Jouni >=20 >=20 > > -----Original Message----- > > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > > Sent: 6. huhtikuuta 2006 15:53 > > To: Julien Bournelle > > Cc: gdommety@cisco.com; elena.demaria@tilab.com;=20 > > basavaraj.patil@nokia.com; gerardo.giaretta@tilab.com;=20 > > dime@ietf.org; ivano.guardini@tilab.com > > Subject: AW: [Dime] Re: Diameter MIPv6 > >=20 > > Hi Julien,=20 > >=20 > > this is my impression was well. Working on the document I got=20 > > the impression that they are sufficiently different in order=20 > > to deal with the bootstrapping solutions in a separate document.=20 > >=20 > > Ciao > > Hannes > >=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 > > > Gesendet: Donnerstag, 6. April 2006 14:41 > > > An: Julien Bournelle > > > Cc: gdommety@cisco.com; elena.demaria@tilab.com;=20 > > > basavaraj.patil@nokia.com; gerardo.giaretta@tilab.com;=20 > > > dime@ietf.org; ivano.guardini@tilab.com > > > Betreff: [Dime] Re: Diameter MIPv6 > > >=20 > > > Hi all, > > >=20 > > > For the Integrated scenario we need to: > > > - define AVPs (HA) > > > - explain where to put it in the Diameter EAP/NASREQ=20 > > > exchanges (between > > > NAS and the AAA) > > > - probably require a Application-ID for that the NAS=20 > > announces to the > > > AAA that it support the Integrated case. > > >=20 > > > For the split scenario, we need to: > > > - explain how the HA uses Diameter EAP. (HA uses IKEv2 with MN)=20 > > > - maybe some issues may raised after investigation (do the=20 > > HA need to > > > tell to the AAA that it is a HA and not a NAS ? this sort=20 > > > of things). > > >=20 > > > So at this point of time, I think it would be better to=20 > investigate > > > this separately and see later if it makes sense to merge the=20 > > > documents. > > > I don't really see the advantage of having one document for=20 > > > the moment. > > >=20 > > > Regards, > > >=20 > > > Julien B. > > >=20 > > > On Wed, Apr 05, 2006 at 12:42:26PM +0200, Julien Bournelle wrote: > > > > Hi all, > > > >=20 > > > > On Wed, Apr 05, 2006 at 11:44:37AM +0200, Hannes=20 > Tschofenig wrote: > > > > > Hi all, > > > > >=20 > > > > > the MIP6 bootstrapping design team has worked on two=20 > > > solutions for=20 > > > > > bootstrapping of MIPv6: the integrated and the split scenario > > > > >=20 > > > > > These two solutions are documented in two separate drafts: > > > > >=20 > > > > > MIP6-bootstrapping via DHCPv6 for the Integrated Scenario > > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > > > ing-integrated-dhc-00.txt > > > > >=20 > > > > > Mobile IPv6 bootstrapping in split scenario > > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > > > ing-split-02.txt > > > > >=20 > > > > > As such, there is the question whether the work in DIME=20 > > > should also=20 > > > > > produce two separate documents referring to these two=20 > > > bootstrapping=20 > > > > > deployment scenarios or whether it would be useful to=20 > > > captures both=20 > > > > > scenarios in a single document. > > > > >=20 > > > > > Thoughts? > > > >=20 > > > > I would prefer two documents. I have two reasons for this: > > > >=20 > > > > 1/ In the integrated scenario, the AAA is used between NAS=20 > > > and AAA. The > > > > HA address is delivered from the AAA to the NAS and thus=20 > > > NASREQ or EAP > > > > may be in used. > > > >=20 > > > > In the split scenario, Diameter is used between HA and=20 > > > the AAA. And > > > > the AAA does not deliver the HA to the HA... > > > >=20 > > > >=20 > > > > 2/ From an implementation perspective, it would be=20 > > easier to have a > > > > specific document for each case. > > > >=20 > > > > Julien B. > > > >=20 > > > > >=20 > > > > > Ciao > > > > > Hannes & John > > > > >=20 > > > > > PS: John and myself would also like to know when the=20 > > > MIP6-AAA Goals draft > > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goa > > > ls-01.txt > > > > > is going to be finalized since the Diameter MIPv6 work=20 > > > depends on this=20 > > > > > document. > > > >=20 > > > > --=20 > > > > julien.bournelle at int-evry.fr > > >=20 > > > --=20 > > > julien.bournelle at int-evry.fr > > >=20 > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_0519_01C65CCC.77E09AD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes,=20 only viewing from the solution components like HA, HoA, security keying=20 material.
However, seeing from the overall procedure through the AAA=20 involvement,
there exists marginal distinction between two scenarios.=20
Therefore, separate drafts are better in moving forward,=20 IMO.
 
-Junghoon
From: Giaretta Gerardo=20 [mailto:gerardo.giaretta@telecomitalia.it]
Sent: Friday, = April 07,=20 2006 6:21 PM
To: Junghoon Jee; = jouni.korhonen@teliasonera.com;=20 hannes.tschofenig@siemens.com; = julien.bournelle@int-evry.fr
Cc:=20 gdommety@cisco.com; Demaria Elena; basavaraj.patil@nokia.com; = dime@ietf.org;=20 Guardini Ivano
Subject: RE: [Dime] Re: Diameter=20 MIPv6

 
The only difference between the two MIP6 = bootstrapping=20 solutions is the Home Agent assignment via DHCP, that requires new = capability=20 in NAS-AAA interface. All other requirements and functionality are = common to=20 split and integrated solutions. And what we specify for split needs to = be=20 implemented also for integrated (AAA-HA interface). There are moreover = other=20 common requirements that may be not related to bootstrapping (e.g. = session=20 termination) and that are in common to both scenarios, too.

I = still=20 think one draft is better.

--Gerardo

> -----Original = Message-----
> From: Junghoon Jee [mailto:jhjee@etri.re.kr] =
>=20 Sent: venerd=EC 7 aprile 2006 1.54
> To: = jouni.korhonen@teliasonera.com;=20
> hannes.tschofenig@siemens.com; = julien.bournelle@int-evry.fr
>=20 Cc: gdommety@cisco.com; Demaria Elena;
> = basavaraj.patil@nokia.com;=20 Giaretta Gerardo; dime@ietf.org;
> Guardini Ivano
> = Subject: Re:=20 [Dime] Re: Diameter MIPv6
>
> Hi all,
>
> = I'd=20 suggest to having _two_ DIME drafts for integrated and split = case
>=20 because the overall bootstrapping procedures are different in
> = each=20 case.
> Please take a look at the current suggested drafts from=20 Hannes,
> then might be in the same line with me. :-)
> =
>=20 As a side note:
> Listing up AAA requirements through _single_ = document=20 is still valid
> as I mentioned in the previous MIP6 WG = meeting.
>=20
> Thanks,
> -Junghoon
>
> ----- Original = Message=20 -----
> From:
> To:=20 ; =
> Cc:=20 ; ;
>=20 ; ;
>=20 ;
> Sent: Thursday, = April 06,=20 2006 9:58 PM
> Subject: RE: [Dime] Re: Diameter MIPv6
> =
>=20
>
> I would also go for two different documents because = of=20 the
> differences in solution approaches and for the = general
>=20 clarity.
>
> Cheers,
> Jouni
>
> =
> >=20 -----Original Message-----
> > From: Tschofenig, Hannes=20 [mailto:hannes.tschofenig@siemens.com]
> > Sent: 6. = huhtikuuta 2006=20 15:53
> > To: Julien Bournelle
> > Cc: = gdommety@cisco.com;=20 elena.demaria@tilab.com;
> > basavaraj.patil@nokia.com;=20 gerardo.giaretta@tilab.com;
> > dime@ietf.org;=20 ivano.guardini@tilab.com
> > Subject: AW: [Dime] Re: Diameter = MIPv6
> >
> > Hi Julien,
> >
> = > this=20 is my impression was well. Working on the document I got
> > = the=20 impression that they are sufficiently different in order
> > = to deal=20 with the bootstrapping solutions in a separate document.
> > =
> > Ciao
> > Hannes
> >
> > =
>=20 > > -----Urspr=FCngliche Nachricht-----
> > > Von: = Julien=20 Bournelle [mailto:julien.bournelle@int-evry.fr]
> > > = Gesendet:=20 Donnerstag, 6. April 2006 14:41
> > > An: Julien = Bournelle
>=20 > > Cc: gdommety@cisco.com; elena.demaria@tilab.com;
> = > >=20 basavaraj.patil@nokia.com; gerardo.giaretta@tilab.com;
> > = >=20 dime@ietf.org; ivano.guardini@tilab.com
> > > Betreff: = [Dime] Re:=20 Diameter MIPv6
> > >
> > > Hi all,
> = > >=20
> > > For the Integrated scenario we need to:
> = > > -=20 define AVPs (HA)
> > > - explain where to put it in the = Diameter=20 EAP/NASREQ
> > > exchanges (between
> > > NAS = and the=20 AAA)
> > > - probably require a Application-ID for that = the NAS=20
> > announces to the
> > > AAA that it support = the=20 Integrated case.
> > >
> > > For the split = scenario,=20 we need to:
> > > - explain how the HA uses Diameter EAP. = (HA uses=20 IKEv2 with MN)
> > > - maybe some issues may raised after = investigation (do the
> > HA need to
> > > tell = to the=20 AAA that it is a HA and not a NAS ? this sort
> > > of=20 things).
> > >
> > > So at this point of = time, I=20 think it would be better to
> investigate
> > > = this=20 separately and see later if it makes sense to merge the
> > = >=20 documents.
> > > I don't really see the advantage of = having one=20 document for
> > > the moment.
> > >
> = >=20 > Regards,
> > >
> > > Julien B.
> = > >=20
> > > On Wed, Apr 05, 2006 at 12:42:26PM +0200, Julien = Bournelle=20 wrote:
> > > > Hi all,
> > > >
> = >=20 > > On Wed, Apr 05, 2006 at 11:44:37AM +0200, Hannes
> = Tschofenig=20 wrote:
> > > > > Hi all,
> > > > > =
> > > > > the MIP6 bootstrapping design team has = worked on=20 two
> > > solutions for
> > > > >=20 bootstrapping of MIPv6: the integrated and the split scenario
> = >=20 > > >
> > > > > These two solutions are = documented=20 in two separate drafts:
> > > > >
> > > = >=20 > MIP6-bootstrapping via DHCPv6 for the Integrated Scenario
> = >=20 > > >
> > >=20 http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp
> = >=20 > ing-integrated-dhc-00.txt
> > > > >
> = > >=20 > > Mobile IPv6 bootstrapping in split scenario
> > = > >=20 >
> > >=20 http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp
> = >=20 > ing-split-02.txt
> > > > >
> > > = > >=20 As such, there is the question whether the work in DIME
> > = >=20 should also
> > > > > produce two separate = documents=20 referring to these two
> > > bootstrapping
> > = >=20 > > deployment scenarios or whether it would be useful to =
> >=20 > captures both
> > > > > scenarios in a single=20 document.
> > > > >
> > > > >=20 Thoughts?
> > > >
> > > > I would = prefer two=20 documents. I have two reasons for this:
> > > > =
> >=20 > > 1/ In the integrated scenario, the AAA is used between NAS =
>=20 > > and AAA. The
> > > > HA address is delivered = from the=20 AAA to the NAS and thus
> > > NASREQ or EAP
> > = >=20 > may be in used.
> > > >
> > > > In = the=20 split scenario, Diameter is used between HA and
> > > the = AAA.=20 And
> > > > the AAA does not deliver the HA to the=20 HA...
> > > >
> > > >
> > = > >=20 2/ From an implementation perspective, it would be
> > = easier to=20 have a
> > > > specific document for each case.
> = >=20 > >
> > > > Julien B.
> > > > =
>=20 > > > >
> > > > > Ciao
> > = > >=20 > Hannes & John
> > > > >
> > > = >=20 > PS: John and myself would also like to know when the
> = > >=20 MIP6-AAA Goals draft
> > > > >
> > >=20 http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goa
> = >=20 > ls-01.txt
> > > > > is going to be finalized = since the=20 Diameter MIPv6 work
> > > depends on this
> > = > >=20 > document.
> > > >
> > > > -- =
> >=20 > > julien.bournelle at int-evry.fr
> > >
> = > >=20 --
> > > julien.bournelle at int-evry.fr
> > = >=20
> > > = _______________________________________________
>=20 > > DiME mailing list
> > > DiME@ietf.org
> = > >=20 https://www1.ietf.org/mailman/listinfo/dime
> > >
> = >=20
> > _______________________________________________
> = >=20 DiME mailing list
> > DiME@ietf.org
> >=20 https://www1.ietf.org/mailman/listinfo/dime
> >
> =
>=20 _______________________________________________
> DiME mailing=20 list
> DiME@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/dime
>
--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the = persons
above and may contain confidential information. If you have = received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender = and=20 delete
the message. Should you have any questions, please contact = us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 = you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_0519_01C65CCC.77E09AD0-- --===============1861171811== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1861171811==-- From dime-bounces@ietf.org Mon Apr 10 05:36:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSspB-0003VO-QZ; Mon, 10 Apr 2006 05:36:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSspA-0003VJ-9z for dime@ietf.org; Mon, 10 Apr 2006 05:36:44 -0400 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSsp9-0000m7-0O for dime@ietf.org; Mon, 10 Apr 2006 05:36:44 -0400 Received: from etri04q4sqc7zc ([129.254.12.66]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 18:39:24 +0900 From: "Junghoon Jee" To: Subject: RE: [Dime] Re: Diameter MIPv6 Date: Mon, 10 Apr 2006 18:36:36 +0900 Message-ID: <052b01c65c82$43078cf0$420cfe81@etri04q4sqc7zc> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZZ1XDirK/7jFmTTj++yS6+a1KIcQATleeQAJcm7iAAAHAp4A== In-Reply-To: <051801c65c81$07f8f2d0$420cfe81@etri04q4sqc7zc> X-OriginalArrivalTime: 10 Apr 2006 09:39:24.0633 (UTC) FILETIME=[A7248490:01C65C82] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3bef755d9f4ba0b7ac474570b36ffadb X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0486104836==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0486104836== Content-Type: multipart/alternative; boundary="----=_NextPart_000_052C_01C65CCD.B2EF34F0" This is a multi-part message in MIME format. ------=_NextPart_000_052C_01C65CCD.B2EF34F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > there exists marginal distinction between two scenarios. =20 =20 Needs to be correctly interpreted by changing from marginal to **major**. =20 - Junghoon=20 _____ =20 From: Junghoon Jee [mailto:jhjee@etri.re.kr]=20 Sent: Monday, April 10, 2006 6:28 PM To: 'Giaretta Gerardo'; jouni.korhonen@teliasonera.com; hannes.tschofenig@siemens.com; julien.bournelle@int-evry.fr Cc: gdommety@cisco.com; 'Demaria Elena'; dime@ietf.org; 'Guardini Ivano'; basavaraj.patil@nokia.com Subject: RE: [Dime] Re: Diameter MIPv6 Yes, only viewing from the solution components like HA, HoA, security keying material. However, seeing from the overall procedure through the AAA involvement, there exists marginal distinction between two scenarios.=20 Therefore, separate drafts are better in moving forward, IMO. =20 -Junghoon _____ =20 From: Giaretta Gerardo [mailto:gerardo.giaretta@telecomitalia.it]=20 Sent: Friday, April 07, 2006 6:21 PM To: Junghoon Jee; jouni.korhonen@teliasonera.com; hannes.tschofenig@siemens.com; julien.bournelle@int-evry.fr Cc: gdommety@cisco.com; Demaria Elena; basavaraj.patil@nokia.com; dime@ietf.org; Guardini Ivano Subject: RE: [Dime] Re: Diameter MIPv6 =20 The only difference between the two MIP6 bootstrapping solutions is the Home Agent assignment via DHCP, that requires new capability in NAS-AAA interface. All other requirements and functionality are common to split and integrated solutions. And what we specify for split needs to be implemented also for integrated (AAA-HA interface). There are moreover other common requirements that may be not related to bootstrapping (e.g. session termination) and that are in common to both scenarios, too. I still think one draft is better. --Gerardo=20 > -----Original Message----- > From: Junghoon Jee [mailto:jhjee@etri.re.kr]=20 > Sent: venerd=EC 7 aprile 2006 1.54 > To: jouni.korhonen@teliasonera.com;=20 > hannes.tschofenig@siemens.com; julien.bournelle@int-evry.fr > Cc: gdommety@cisco.com; Demaria Elena;=20 > basavaraj.patil@nokia.com; Giaretta Gerardo; dime@ietf.org;=20 > Guardini Ivano > Subject: Re: [Dime] Re: Diameter MIPv6 >=20 > Hi all, >=20 > I'd suggest to having _two_ DIME drafts for integrated and split case > because the overall bootstrapping procedures are different in=20 > each case. > Please take a look at the current suggested drafts from Hannes, > then might be in the same line with me. :-) >=20 > As a side note:=20 > Listing up AAA requirements through _single_ document is still valid > as I mentioned in the previous MIP6 WG meeting. >=20 > Thanks, > -Junghoon >=20 > ----- Original Message -----=20 > From:=20 > To: ;=20 > Cc: ; ;=20 > ; ;=20 > ;=20 > Sent: Thursday, April 06, 2006 9:58 PM > Subject: RE: [Dime] Re: Diameter MIPv6 >=20 >=20 >=20 > I would also go for two different documents because of the > differences in solution approaches and for the general > clarity. >=20 > Cheers, > Jouni >=20 >=20 > > -----Original Message----- > > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > > Sent: 6. huhtikuuta 2006 15:53 > > To: Julien Bournelle > > Cc: gdommety@cisco.com; elena.demaria@tilab.com;=20 > > basavaraj.patil@nokia.com; gerardo.giaretta@tilab.com;=20 > > dime@ietf.org; ivano.guardini@tilab.com > > Subject: AW: [Dime] Re: Diameter MIPv6 > >=20 > > Hi Julien,=20 > >=20 > > this is my impression was well. Working on the document I got=20 > > the impression that they are sufficiently different in order=20 > > to deal with the bootstrapping solutions in a separate document.=20 > >=20 > > Ciao > > Hannes > >=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 > > > Gesendet: Donnerstag, 6. April 2006 14:41 > > > An: Julien Bournelle > > > Cc: gdommety@cisco.com; elena.demaria@tilab.com;=20 > > > basavaraj.patil@nokia.com; gerardo.giaretta@tilab.com;=20 > > > dime@ietf.org; ivano.guardini@tilab.com > > > Betreff: [Dime] Re: Diameter MIPv6 > > >=20 > > > Hi all, > > >=20 > > > For the Integrated scenario we need to: > > > - define AVPs (HA) > > > - explain where to put it in the Diameter EAP/NASREQ=20 > > > exchanges (between > > > NAS and the AAA) > > > - probably require a Application-ID for that the NAS=20 > > announces to the > > > AAA that it support the Integrated case. > > >=20 > > > For the split scenario, we need to: > > > - explain how the HA uses Diameter EAP. (HA uses IKEv2 with MN)=20 > > > - maybe some issues may raised after investigation (do the=20 > > HA need to > > > tell to the AAA that it is a HA and not a NAS ? this sort=20 > > > of things). > > >=20 > > > So at this point of time, I think it would be better to=20 > investigate > > > this separately and see later if it makes sense to merge the=20 > > > documents. > > > I don't really see the advantage of having one document for=20 > > > the moment. > > >=20 > > > Regards, > > >=20 > > > Julien B. > > >=20 > > > On Wed, Apr 05, 2006 at 12:42:26PM +0200, Julien Bournelle wrote: > > > > Hi all, > > > >=20 > > > > On Wed, Apr 05, 2006 at 11:44:37AM +0200, Hannes=20 > Tschofenig wrote: > > > > > Hi all, > > > > >=20 > > > > > the MIP6 bootstrapping design team has worked on two=20 > > > solutions for=20 > > > > > bootstrapping of MIPv6: the integrated and the split scenario > > > > >=20 > > > > > These two solutions are documented in two separate drafts: > > > > >=20 > > > > > MIP6-bootstrapping via DHCPv6 for the Integrated Scenario > > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > > > ing-integrated-dhc-00.txt > > > > >=20 > > > > > Mobile IPv6 bootstrapping in split scenario > > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > > > ing-split-02.txt > > > > >=20 > > > > > As such, there is the question whether the work in DIME=20 > > > should also=20 > > > > > produce two separate documents referring to these two=20 > > > bootstrapping=20 > > > > > deployment scenarios or whether it would be useful to=20 > > > captures both=20 > > > > > scenarios in a single document. > > > > >=20 > > > > > Thoughts? > > > >=20 > > > > I would prefer two documents. I have two reasons for this: > > > >=20 > > > > 1/ In the integrated scenario, the AAA is used between NAS=20 > > > and AAA. The > > > > HA address is delivered from the AAA to the NAS and thus=20 > > > NASREQ or EAP > > > > may be in used. > > > >=20 > > > > In the split scenario, Diameter is used between HA and=20 > > > the AAA. And > > > > the AAA does not deliver the HA to the HA... > > > >=20 > > > >=20 > > > > 2/ From an implementation perspective, it would be=20 > > easier to have a > > > > specific document for each case. > > > >=20 > > > > Julien B. > > > >=20 > > > > >=20 > > > > > Ciao > > > > > Hannes & John > > > > >=20 > > > > > PS: John and myself would also like to know when the=20 > > > MIP6-AAA Goals draft > > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goa > > > ls-01.txt > > > > > is going to be finalized since the Diameter MIPv6 work=20 > > > depends on this=20 > > > > > document. > > > >=20 > > > > --=20 > > > > julien.bournelle at int-evry.fr > > >=20 > > > --=20 > > > julien.bournelle at int-evry.fr > > >=20 > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_052C_01C65CCD.B2EF34F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 > =  there exists=20 marginal distinction between two scenarios.  
 
Needs to be = correctly=20 interpreted by changing from marginal to = **major**.
 
- Junghoon 

From: Junghoon Jee = [mailto:jhjee@etri.re.kr]=20
Sent: Monday, April 10, 2006 6:28 PM
To: = 'Giaretta=20 Gerardo'; jouni.korhonen@teliasonera.com; = hannes.tschofenig@siemens.com;=20 julien.bournelle@int-evry.fr
Cc: gdommety@cisco.com; = 'Demaria=20 Elena'; dime@ietf.org; 'Guardini Ivano';=20 basavaraj.patil@nokia.com
Subject: RE: [Dime] Re: Diameter=20 MIPv6

Yes, only viewing from the solution components like HA, HoA, = security=20 keying material.
However, seeing from the overall procedure through the AAA=20 involvement,
there exists marginal distinction between two scenarios.=20
Therefore, separate drafts are better in moving forward,=20 IMO.
 
-Junghoon
From: Giaretta Gerardo=20 [mailto:gerardo.giaretta@telecomitalia.it]
Sent: Friday, = April=20 07, 2006 6:21 PM
To: Junghoon Jee; = jouni.korhonen@teliasonera.com;=20 hannes.tschofenig@siemens.com; = julien.bournelle@int-evry.fr
Cc:=20 gdommety@cisco.com; Demaria Elena; basavaraj.patil@nokia.com; = dime@ietf.org;=20 Guardini Ivano
Subject: RE: [Dime] Re: Diameter=20 MIPv6

 
The only difference between the two MIP6 = bootstrapping=20 solutions is the Home Agent assignment via DHCP, that requires new=20 capability in NAS-AAA interface. All other requirements and = functionality=20 are common to split and integrated solutions. And what we specify = for split=20 needs to be implemented also for integrated (AAA-HA interface). = There are=20 moreover other common requirements that may be not related to = bootstrapping=20 (e.g. session termination) and that are in common to both scenarios, = too.

I still think one draft is better.

--Gerardo =

>=20 -----Original Message-----
> From: Junghoon Jee=20 [mailto:jhjee@etri.re.kr]
> Sent: venerd=EC 7 aprile 2006 = 1.54
>=20 To: jouni.korhonen@teliasonera.com;
> = hannes.tschofenig@siemens.com;=20 julien.bournelle@int-evry.fr
> Cc: gdommety@cisco.com; Demaria = Elena;=20
> basavaraj.patil@nokia.com; Giaretta Gerardo; dime@ietf.org; =
> Guardini Ivano
> Subject: Re: [Dime] Re: Diameter=20 MIPv6
>
> Hi all,
>
> I'd suggest to = having _two_=20 DIME drafts for integrated and split case
> because the = overall=20 bootstrapping procedures are different in
> each = case.
> Please=20 take a look at the current suggested drafts from Hannes,
> = then might=20 be in the same line with me. :-)
>
> As a side note: =
>=20 Listing up AAA requirements through _single_ document is still = valid
>=20 as I mentioned in the previous MIP6 WG meeting.
>
>=20 Thanks,
> -Junghoon
>
> ----- Original Message = -----=20
> From:
> To:=20 ; =
> Cc:=20 ; ;
>=20 ; ;
>=20 ;
> Sent: Thursday, = April=20 06, 2006 9:58 PM
> Subject: RE: [Dime] Re: Diameter = MIPv6
>=20
>
>
> I would also go for two different = documents=20 because of the
> differences in solution approaches and for = the=20 general
> clarity.
>
> Cheers,
> = Jouni
>=20
>
> > -----Original Message-----
> > From: = Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]
> = >=20 Sent: 6. huhtikuuta 2006 15:53
> > To: Julien = Bournelle
>=20 > Cc: gdommety@cisco.com; elena.demaria@tilab.com;
> >=20 basavaraj.patil@nokia.com; gerardo.giaretta@tilab.com;
> > = dime@ietf.org; ivano.guardini@tilab.com
> > Subject: AW: = [Dime] Re:=20 Diameter MIPv6
> >
> > Hi Julien,
> > =
>=20 > this is my impression was well. Working on the document I got =
>=20 > the impression that they are sufficiently different in order =
>=20 > to deal with the bootstrapping solutions in a separate = document.=20
> >
> > Ciao
> > Hannes
> > =
>=20 >
> > > -----Urspr=FCngliche Nachricht-----
> = > >=20 Von: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> = >=20 > Gesendet: Donnerstag, 6. April 2006 14:41
> > > An: = Julien=20 Bournelle
> > > Cc: gdommety@cisco.com; = elena.demaria@tilab.com;=20
> > > basavaraj.patil@nokia.com; = gerardo.giaretta@tilab.com;=20
> > > dime@ietf.org; ivano.guardini@tilab.com
> = > >=20 Betreff: [Dime] Re: Diameter MIPv6
> > >
> > = > Hi=20 all,
> > >
> > > For the Integrated = scenario we=20 need to:
> > > - define AVPs (HA)
> > > - = explain=20 where to put it in the Diameter EAP/NASREQ
> > > = exchanges=20 (between
> > > NAS and the AAA)
> > > - = probably=20 require a Application-ID for that the NAS
> > announces to = the
> > > AAA that it support the Integrated = case.
> >=20 >
> > > For the split scenario, we need to:
> = >=20 > - explain how the HA uses Diameter EAP. (HA uses IKEv2 with MN) =
> > > - maybe some issues may raised after = investigation (do=20 the
> > HA need to
> > > tell to the AAA that = it is a=20 HA and not a NAS ? this sort
> > > of things).
> = >=20 >
> > > So at this point of time, I think it would = be better=20 to
> investigate
> > > this separately and see = later if=20 it makes sense to merge the
> > > documents.
> = > >=20 I don't really see the advantage of having one document for
> = >=20 > the moment.
> > >
> > > = Regards,
> >=20 >
> > > Julien B.
> > >
> > = > On=20 Wed, Apr 05, 2006 at 12:42:26PM +0200, Julien Bournelle = wrote:
> >=20 > > Hi all,
> > > >
> > > > On = Wed, Apr=20 05, 2006 at 11:44:37AM +0200, Hannes
> Tschofenig = wrote:
> >=20 > > > Hi all,
> > > > >
> > = > >=20 > the MIP6 bootstrapping design team has worked on two
> = > >=20 solutions for
> > > > > bootstrapping of MIPv6: = the=20 integrated and the split scenario
> > > > > =
> >=20 > > > These two solutions are documented in two separate=20 drafts:
> > > > >
> > > > >=20 MIP6-bootstrapping via DHCPv6 for the Integrated Scenario
> = > >=20 > >
> > >=20 = http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp
> = >=20 > ing-integrated-dhc-00.txt
> > > > >
> = >=20 > > > Mobile IPv6 bootstrapping in split scenario
> = > >=20 > >
> > >=20 = http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp
> = >=20 > ing-split-02.txt
> > > > >
> > > = >=20 > As such, there is the question whether the work in DIME =
> >=20 > should also
> > > > > produce two separate = documents=20 referring to these two
> > > bootstrapping
> = > >=20 > > deployment scenarios or whether it would be useful to =
>=20 > > captures both
> > > > > scenarios in a = single=20 document.
> > > > >
> > > > >=20 Thoughts?
> > > >
> > > > I would = prefer two=20 documents. I have two reasons for this:
> > > > =
> >=20 > > 1/ In the integrated scenario, the AAA is used between NAS =
> > > and AAA. The
> > > > HA address is = delivered from the AAA to the NAS and thus
> > > NASREQ = or=20 EAP
> > > > may be in used.
> > > > =
>=20 > > > In the split scenario, Diameter is used between HA = and=20
> > > the AAA. And
> > > > the AAA does = not=20 deliver the HA to the HA...
> > > >
> > = > >=20
> > > > 2/ From an implementation perspective, it = would be=20
> > easier to have a
> > > > specific = document for=20 each case.
> > > >
> > > > Julien = B.
>=20 > > >
> > > > >
> > > > = >=20 Ciao
> > > > > Hannes & John
> > > = >=20 >
> > > > > PS: John and myself would also = like to=20 know when the
> > > MIP6-AAA Goals draft
> > = > >=20 >
> > >=20 = http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goa
> = >=20 > ls-01.txt
> > > > > is going to be finalized = since=20 the Diameter MIPv6 work
> > > depends on this
> = >=20 > > > document.
> > > >
> > > = > --=20
> > > > julien.bournelle at int-evry.fr
> > = >=20
> > > --
> > > julien.bournelle at=20 int-evry.fr
> > >
> > >=20 _______________________________________________
> > > = DiME=20 mailing list
> > > DiME@ietf.org
> > >=20 https://www1.ietf.org/mailman/listinfo/dime
> > > =
> >=20
> > = _______________________________________________
> >=20 DiME mailing list
> > DiME@ietf.org
> >=20 https://www1.ietf.org/mailman/listinfo/dime
> >
> =
>=20 _______________________________________________
> DiME mailing = list
> DiME@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/dime
>
--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to = the=20 persons
above and may contain confidential information. If you = have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender = and=20 delete
the message. Should you have any questions, please contact = us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 = you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_052C_01C65CCD.B2EF34F0-- --===============0486104836== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0486104836==-- From dime-bounces@ietf.org Mon Apr 10 09:36:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwZ9-0004g2-SE; Mon, 10 Apr 2006 09:36:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwZ8-0004dk-PQ for dime@ietf.org; Mon, 10 Apr 2006 09:36:26 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSwZ8-0001hj-Cw for dime@ietf.org; Mon, 10 Apr 2006 09:36:26 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k3ADaGkh049832; Mon, 10 Apr 2006 09:36:21 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <443A5F53.2070601@tari.toshiba.com> Date: Mon, 10 Apr 2006 09:36:19 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Timothy Smith Subject: Re: [Dime] CER/CEA on an open connection References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: Nakhjiri Madjid-MNAKHJI1 , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Timothy Smith wrote: > > Hi Victor, > > Thanks for your response. Comments below" > >> > >> Good summary! I agree with most of your points. I'm not sure, > >> however, that I distinguish between (1) and (2). I think whether > >> temporary or not, we should handle CER/CEA exchanges in the same > manner. > >I'm just speculating but I think (2) refers to application change > >requiring a reboot. > >> > >> I agree with your design goals (3) ,(4), and suggestions (5) , (6) , > >> (8), and (9). > >If some are more in favor of scheme (5) , maybe we need more opinion on > >whether the receiver of the CEA can always comply with the change > >request regardless of any scenario. I think (6) and (9) can be avoided > >regardless of which scheme we decide to use (see my previous reply). > > > > Here is the text from your previous reply: > "This certainly simplifies things but it also implies that the sender of > the CER mandates a change and the receiver has no choice but to accept > it. In some sense, the scheme is no longer a re-negotiation but merely > notifying the peer of a change. The proposed text was considering the > case where the receiver of the CER cannot comply with the change for > whatever reason." > > I tend to agree with the notion that the sender of the CER is mandating > a change. The receiver does have a choice just as it has a choice in the > original CER/CEA exchange. The receiver should respond with the list of > App Ids that is the intersection of what was listed in the CER and of > what > App Ids it wishes to support. It is a renegotiation which may add or > remove App Ids. But either way, it is telling the other side about its > intentions. In the case where apps are being removed, the receiver seems to have no choice. This is ok with me as long as we clarify that we are more in favor of notification instead of re-negotiation. I hope more people can comment on this so we get some notion of consensus. > I don't thing the receiving side has any choice but to participate > in the renegotiation. For example, if an app Id is being removed, the > side > where it is being removed renegotiates with a CER that does not > include that > App ID. It doesn't do the receiving side any good to decline this as > the App > will be shut down regardless. ok. On a side-note, we may also need to say that route table updates maybe required due to "mandated" change. > > > >> Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont > >> think there is a problem here. Cant find any race condition." I > >> thought that there was a subtle problem here, but I think you are > >> right. Given that the connection insures sequencing, the latest CER > >> or CEA that you receive is what you should use as the list of > >> negotiated App Ids. > >> > >Mmmm... i'm not sure that the connection itself ensures sequencing. > >Anyway, majority rule favors removing this text. > >> Should there be some discussion on the retry mechanism? You send a > >> CER, and no response is received. Does this mean that the peer just > >> doesn't know how to renegotiate? Should we ignore and retry every n > >> seconds? Bring down the connection? Or do we just continue to use > >> the apps from the initial negotiation? My preference on this is that > >> we should require a CEA response to the CER. If the CEA is not > >> received, we shutdown the connection and start over. This would > >> address compatibility issues with existing implementations. It would > >> also be consistent with the processing of the initial CER/CEA. > >> > >The current proposal has text mentioning the use of version number of > >initial CER/CEA exchange to determine whether a peer is capable of > >renegotiating. If a node knows that its peer is not capable of > >re-negotiating then the node should not initiate re-negotiation. In this > >scheme, existing implementations will be spared of any change. > > I'm not sure I picked up the version number. I don't see a reason to do > something special. I would simply like to renegotiate. If the other > side > does not respond to the CER, you shut down the connection and restart it > after some period of time. This is what you would do if your initial CER > did not get a response. How is this different? > > Apologies if my response seems to dis-regard one scheme over the another. I was thinking more in the case that this (and other) proposed text is an addendum to the existing specification. It maybe useful to use the version number so that the specification does not seem like a moving target. This may apply to changes that entails some behavior not present in the existing specification (i.e. re-negotiation as opposed to using the CER as a notification or other proposals specifying changes to the statemachine). Its not to say that retry will not work as a general practice but it is probably best to also use versioning so there's a clear demarcation between existing behavior and new behavior. Hope this helps, victor > Best Regards, > Timothy Smith > > Vishnu wrote: > > Hi, > > > > Some clarifications and comments on the discussion on this thread: > > > > We would like to clarify the following practical scenarios of this > > happenning: > > 1. there are a list of published applications which the box support > > and these are installed in the box. Now, some of them go down/up. This > > would > > get translated into change in peer capabilities. > > 2. there is a new application which is getting installed/removed from > > the box. > > > > We think that (1) is the most probable scenario. so, > > there is value in giving a simple solution assuming that this change (in > > capabilities) > > is most probably temporary. If this is not the case, we are talking > > about (2), which is > > a major change in the box anyways. So in (2), we assume it is ok to > > assume that > > the connections to be reestablished. > > > > We would like to say that our design goals are: > > 3. solution should be simple & as backward compatible as possible. > > 4. minimize the FSM changes. > > > > We suggest: > > 5. Updating peer capabilities done only using a CER/CEA in the open > > state. > > Sender of CER/CEA updates the local capabilities before sending the > > message and > > hence is a local decision. > > > > 6. The rest of the processing of the CER/CEA will be as per the current > > RFC. > > Say for example, if there are no > > common applications left with that peer, DIAMETER_NO_COMMON_APPLICATION > > is sent in the > > CEA and the connection is closed. > > > > Problems in the email thread under discussion & some comments: > > 7. Cross over and sequencing of CER/CEA exchange. We dont think there is > > a problem > > here. Cant find any race condition. > > > > 8. Mutual agreement to bring down applications will not work due to > > possible relays > > in between as Tolga has pointed out in the mailing list. > > > > 9. The DPR solution in the suggested text is not a good idea. Because > > DPR cannot > > advertise the latest local applications to the peer. This may cause the > > race condition > > and sequencing problem. This problem can be avoided by using the > > approach which > > we suggested in (5). > > > > Regards, > > Vishnu. > > tjsmith@us.ibm.com > (919) 254-4723 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Apr 10 10:19:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxEj-00060H-Qq; Mon, 10 Apr 2006 10:19:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxEi-000609-AE for dime@ietf.org; Mon, 10 Apr 2006 10:19:24 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSxEh-0003Go-Qv for dime@ietf.org; Mon, 10 Apr 2006 10:19:24 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k3AEJKFC049987; Mon, 10 Apr 2006 10:19:20 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <443A696B.4060908@tari.toshiba.com> Date: Mon, 10 Apr 2006 10:19:23 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Ram O V Vishnu-A14676 Subject: Re: [Dime] CER/CEA on an open connection References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Cc: Nakhjiri Madjid-MNAKHJI1 , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi All, > Hi Victor/Timothy, > > 1. Comments on Retry mechanism : > To summarize, we are sending CER in open state because our capabilities > (supported apps) are changing > and we would like to update the peer about it. We will maintain open > state. > ok. > we may not receive a CEA due to the following possible reasons: > 1.1) The peer does not support CER in open state. In such a case, peer > might still originate unsupported app messages towards us which will > result in "DIAMETER_APPLICATION_UNSUPPORTED" error from us. We can leave > it to the peer implementation to "correct this error" as mentioned in > sec 7.1.3 of RFC 3588. This will take care of the case where there is > relay/proxy in between. > Good point. > 1.2) Connection is lost with the peer, in which case the DWR/DWA > mechanism should step in. > > The solution suggested by Timothy (to wait for for CEA & timer) will > need changes to FSM, even though we agree that this is consistent with > the initial CER/CEA scenario. > > Ofcourse the use of "DIAMETER_APPLICATION_UNSUPPORTED" will result in > added (unecessary traffic) incase the peer/proxy is not clever enough to > correct its behaviour. This can be avoided by using the version number > exchange as Victor pointed out. So, we will not > attempt the CER in open state to such a peer which doesnt support CERs > in open state, and can go for a reconnection. > > 2. Comments on "re-negotiation" > We think that what we need is an advertisement mechanism and not a > negotiation mechanism. The CER/CEA in open state allows us to do that. > This is was was reading from your proposal :). > We are proposing that the receiver of the CER takes the decision on the > disconnection. Thus we are able to delay the disconnection (assuming > that the point mentioned in my email before that the app changes are > temporary). > Since CER allows us to convey the latest set of supported apps to the > peer, we favour the CER to the DPR. > > Following is a scenario where sending CER/CEA is better than the DPR > mechanism. > (Apologies if the figure is mangled due to tab settings). > > Initial exchanged app list: > A: 1,2,3 B:2 > 2 went down 3 came up just when 2 went down on A > ________ ________ > |A |----DPR---> |B | > | | | | > | |<---CER---- | | > |______| [3] |______| > <---DPA---- > > this in our understanding will result in reconnection even thou there > is 3 in common. > Good point. > Initial exchanged app list: > A: 1,2,3 B:2 > 2 went down 3 came up just when 2 went down on A > ________ ________ > |A |----CER---> |B | > | | [1,3] | | > | |<---CER---- | | > |_______| [2,3] |_______| > ----CEA----> > [1,3] > <---CEA----- > [2,3] > This will avoid a reconnection, because 3 is in common. > > I see. This seems like a better idea. Let see if other people have comments on this scheme. best regards, victor > Regards, > Vishnu. > > Motorola India Electronics Pvt Ltd > +91 9844178052 > [*] Motorola Internal Use Only > > > -----Original Message----- > From: Timothy Smith [mailto:tjsmith@us.ibm.com] > Sent: Monday, April 10, 2006 7:11 AM > To: Victor Fajardo > Cc: dime@ietf.org; Nakhjiri Madjid-MNAKHJI1; Ram O V Vishnu-A14676 > Subject: Re: [Dime] CER/CEA on an open connection > > > > Hi Victor, > > Thanks for your response. Comments below" > >>> Good summary! I agree with most of your points. I'm not sure, >>> however, that I distinguish between (1) and (2). I think whether >>> temporary or not, we should handle CER/CEA exchanges in the same >>> > manner. > >> I'm just speculating but I think (2) refers to application change >> requiring a reboot. >> >>> I agree with your design goals (3) ,(4), and suggestions (5) , (6) , >>> (8), and (9). >>> >> If some are more in favor of scheme (5) , maybe we need more opinion >> > on > >> whether the receiver of the CEA can always comply with the change >> request regardless of any scenario. I think (6) and (9) can be avoided >> regardless of which scheme we decide to use (see my previous reply). >> >> > > Here is the text from your previous reply: > "This certainly simplifies things but it also implies that the sender of > > the CER mandates a change and the receiver has no choice but to accept > it. In some sense, the scheme is no longer a re-negotiation but merely > notifying the peer of a change. The proposed text was considering the > case where the receiver of the CER cannot comply with the change for > whatever reason." > > I tend to agree with the notion that the sender of the CER is mandating > a change. The receiver does have a choice just as it has a choice in > the > original CER/CEA exchange. The receiver should respond with the list of > > App Ids that is the intersection of what was listed in the CER and of > what > App Ids it wishes to support. It is a renegotiation which may add or > remove App Ids. But either way, it is telling the other side about its > intentions. I don't thing the receiving side has any choice but to > participate > in the renegotiation. For example, if an app Id is being removed, the > side > where it is being removed renegotiates with a CER that does not include > that > App ID. It doesn't do the receiving side any good to decline this as > the App > will be shut down regardless. > > > >>> Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont >>> think there is a problem here. Cant find any race condition." I >>> thought that there was a subtle problem here, but I think you are >>> right. Given that the connection insures sequencing, the latest CER >>> or CEA that you receive is what you should use as the list of >>> negotiated App Ids. >>> >>> >> Mmmm... i'm not sure that the connection itself ensures sequencing. >> Anyway, majority rule favors removing this text. >> >>> Should there be some discussion on the retry mechanism? You send a >>> CER, and no response is received. Does this mean that the peer just >>> doesn't know how to renegotiate? Should we ignore and retry every n >>> seconds? Bring down the connection? Or do we just continue to use >>> the apps from the initial negotiation? My preference on this is that >>> we should require a CEA response to the CER. If the CEA is not >>> received, we shutdown the connection and start over. This would >>> address compatibility issues with existing implementations. It would >>> > > >>> also be consistent with the processing of the initial CER/CEA. >>> >>> >> The current proposal has text mentioning the use of version number of >> initial CER/CEA exchange to determine whether a peer is capable of >> renegotiating. If a node knows that its peer is not capable of >> re-negotiating then the node should not initiate re-negotiation. In >> > this > >> scheme, existing implementations will be spared of any change. >> > > I'm not sure I picked up the version number. I don't see a reason to do > > something special. I would simply like to renegotiate. If the other > side > does not respond to the CER, you shut down the connection and restart it > > after some period of time. This is what you would do if your initial > CER > did not get a response. How is this different? > > > Best Regards, > Timothy Smith > > Vishnu wrote: > >> Hi, >> >> Some clarifications and comments on the discussion on this thread: >> >> We would like to clarify the following practical scenarios of this >> happenning: >> 1. there are a list of published applications which the box support >> and these are installed in the box. Now, some of them go down/up. This >> would >> get translated into change in peer capabilities. >> 2. there is a new application which is getting installed/removed from >> the box. >> >> We think that (1) is the most probable scenario. so, >> there is value in giving a simple solution assuming that this change >> > (in > >> capabilities) >> is most probably temporary. If this is not the case, we are talking >> about (2), which is >> a major change in the box anyways. So in (2), we assume it is ok to >> assume that >> the connections to be reestablished. >> >> We would like to say that our design goals are: >> 3. solution should be simple & as backward compatible as possible. >> 4. minimize the FSM changes. >> >> We suggest: >> 5. Updating peer capabilities done only using a CER/CEA in the open >> state. >> Sender of CER/CEA updates the local capabilities before sending the >> message and >> hence is a local decision. >> >> 6. The rest of the processing of the CER/CEA will be as per the >> > current > >> RFC. >> Say for example, if there are no >> common applications left with that peer, >> > DIAMETER_NO_COMMON_APPLICATION > >> is sent in the >> CEA and the connection is closed. >> >> Problems in the email thread under discussion & some comments: >> 7. Cross over and sequencing of CER/CEA exchange. We dont think there >> > is > >> a problem >> here. Cant find any race condition. >> >> 8. Mutual agreement to bring down applications will not work due to >> possible relays >> in between as Tolga has pointed out in the mailing list. >> >> 9. The DPR solution in the suggested text is not a good idea. Because >> DPR cannot >> advertise the latest local applications to the peer. This may cause >> > the > >> race condition >> and sequencing problem. This problem can be avoided by using the >> approach which >> we suggested in (5). >> >> Regards, >> Vishnu. >> > > tjsmith@us.ibm.com > (919) 254-4723 > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Apr 10 10:24:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxJh-0000EA-Gq; Mon, 10 Apr 2006 10:24:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxJg-0000E5-C0 for dime@ietf.org; Mon, 10 Apr 2006 10:24:32 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSxJf-0003Ue-P4 for dime@ietf.org; Mon, 10 Apr 2006 10:24:32 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id CA57D2490E for ; Mon, 10 Apr 2006 10:24:31 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k3AEOT87015620 for ; Mon, 10 Apr 2006 10:24:30 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] CER/CEA on an open connection Date: Mon, 10 Apr 2006 10:03:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I believe in general now we all have a good understanding about what the issues are for renegotiation. It could be an idea to have a new iteration of the proposed text, and to continue the discussions on the new version. A few more comments/questions below. Thanks, Tolga > -----Original Message----- > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > Sent: Monday, April 10, 2006 2:38 AM > To: dime@ietf.org > Cc: Nakhjiri Madjid-MNAKHJI1 > Subject: RE: [Dime] CER/CEA on an open connection > > > Hi Victor/Timothy, > > 1. Comments on Retry mechanism : > To summarize, we are sending CER in open state because our capabilities > (supported apps) are changing > and we would like to update the peer about it. We will maintain open > state. > > we may not receive a CEA due to the following possible reasons: > 1.1) The peer does not support CER in open state. In such a case, peer > might still originate unsupported app messages towards us which will > result in "DIAMETER_APPLICATION_UNSUPPORTED" error from us. We can leave > it to the peer implementation to "correct this error" as mentioned in > sec 7.1.3 of RFC 3588. This will take care of the case where there is > relay/proxy in between. > 1.2) Connection is lost with the peer, in which case the DWR/DWA > mechanism should step in. > > The solution suggested by Timothy (to wait for for CEA & timer) will > need changes to FSM, even though we agree that this is consistent with > the initial CER/CEA scenario. > > Ofcourse the use of "DIAMETER_APPLICATION_UNSUPPORTED" will result in > added (unecessary traffic) incase the peer/proxy is not clever enough to > correct its behaviour. This can be avoided by using the version number > exchange as Victor pointed out. So, we will not > attempt the CER in open state to such a peer which doesnt support CERs > in open state, and can go for a reconnection. [TOLGA]The problem case of a node not being clever enough to take action based on "DIAMETER_APPLICATION_UNSUPPORTED" is not limited to renegotiations. This could happen in existing systems developed according to RFC3588 as well. I would expect a node, whose DIAMETER_APPLICATION_UNSUPPORTED replies are not honored by its neighbor to drop the connection, but as said this is not limited to renegotiation case. For cases, where the neighbor does not support renegotiation, what would be the result code in CEA? DIAMETER_UNABLE_TO_COMPLY? We can say that such a result code in CEA should indicate that the neighbor does not support renegotiations and sender of CER should/may drop/reestablish the connection. Please note that with a properly behaving neighbor, dropping connection is probably not necessary because the first DIAMETER_APPLICATION_UNSUPPORTED should update its tables properly. I don't know whether we need to standardize how a node determines whether a neighbor honors DIAMETER_APPLICATION_UNSUPPORTED result code. > > 2. Comments on "re-negotiation" > We think that what we need is an advertisement mechanism and not a > negotiation mechanism. The CER/CEA in open state allows us to do that. > We are proposing that the receiver of the CER takes the decision on the > disconnection. Thus we are able to delay the disconnection (assuming > that the point mentioned in my email before that the app changes are > temporary). > Since CER allows us to convey the latest set of supported apps to the > peer, we favour the CER to the DPR. > > Following is a scenario where sending CER/CEA is better than the DPR > mechanism. > (Apologies if the figure is mangled due to tab settings). [TOLGA]Although the example case below is a race condition which probably won't happen very often -it relies on changing supported application set on two nodes more or less simultaneously-, I also prefer relying on CER in such a situation, so that there is a single way of handling renegotiations in terms of advertising changes to the neighbors. > > Initial exchanged app list: > A: 1,2,3 B:2 > 2 went down 3 came up just when 2 went down on A > ________ ________ > |A |----DPR---> |B | > | | | | > | |<---CER---- | | > |______| [3] |______| > <---DPA---- > > this in our understanding will result in reconnection even thou there > is 3 in common. > > Initial exchanged app list: > A: 1,2,3 B:2 > 2 went down 3 came up just when 2 went down on A > ________ ________ > |A |----CER---> |B | > | | [1,3] | | > | |<---CER---- | | > |_______| [2,3] |_______| > ----CEA----> > [1,3] > <---CEA----- > [2,3] > This will avoid a reconnection, because 3 is in common. > > Regards, > Vishnu. > > Motorola India Electronics Pvt Ltd > +91 9844178052 > [*] Motorola Internal Use Only > > > -----Original Message----- > From: Timothy Smith [mailto:tjsmith@us.ibm.com] > Sent: Monday, April 10, 2006 7:11 AM > To: Victor Fajardo > Cc: dime@ietf.org; Nakhjiri Madjid-MNAKHJI1; Ram O V Vishnu-A14676 > Subject: Re: [Dime] CER/CEA on an open connection > > > > Hi Victor, > > Thanks for your response. Comments below" > >> > >> Good summary! I agree with most of your points. I'm not sure, > >> however, that I distinguish between (1) and (2). I think whether > >> temporary or not, we should handle CER/CEA exchanges in the same > manner. > >I'm just speculating but I think (2) refers to application change > >requiring a reboot. > >> > >> I agree with your design goals (3) ,(4), and suggestions (5) , (6) , > >> (8), and (9). > >If some are more in favor of scheme (5) , maybe we need more opinion > on > >whether the receiver of the CEA can always comply with the change > >request regardless of any scenario. I think (6) and (9) can be avoided > >regardless of which scheme we decide to use (see my previous reply). > > > > Here is the text from your previous reply: > "This certainly simplifies things but it also implies that the sender of > > the CER mandates a change and the receiver has no choice but to accept > it. In some sense, the scheme is no longer a re-negotiation but merely > notifying the peer of a change. The proposed text was considering the > case where the receiver of the CER cannot comply with the change for > whatever reason." > > I tend to agree with the notion that the sender of the CER is mandating > a change. The receiver does have a choice just as it has a choice in > the > original CER/CEA exchange. The receiver should respond with the list of > > App Ids that is the intersection of what was listed in the CER and of > what > App Ids it wishes to support. It is a renegotiation which may add or > remove App Ids. But either way, it is telling the other side about its > intentions. I don't thing the receiving side has any choice but to > participate > in the renegotiation. For example, if an app Id is being removed, the > side > where it is being removed renegotiates with a CER that does not include > that > App ID. It doesn't do the receiving side any good to decline this as > the App > will be shut down regardless. > > > >> Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont > >> think there is a problem here. Cant find any race condition." I > >> thought that there was a subtle problem here, but I think you are > >> right. Given that the connection insures sequencing, the latest CER > >> or CEA that you receive is what you should use as the list of > >> negotiated App Ids. > >> > >Mmmm... i'm not sure that the connection itself ensures sequencing. > >Anyway, majority rule favors removing this text. > >> Should there be some discussion on the retry mechanism? You send a > >> CER, and no response is received. Does this mean that the peer just > >> doesn't know how to renegotiate? Should we ignore and retry every n > >> seconds? Bring down the connection? Or do we just continue to use > >> the apps from the initial negotiation? My preference on this is that > >> we should require a CEA response to the CER. If the CEA is not > >> received, we shutdown the connection and start over. This would > >> address compatibility issues with existing implementations. It would > > >> also be consistent with the processing of the initial CER/CEA. > >> > >The current proposal has text mentioning the use of version number of > >initial CER/CEA exchange to determine whether a peer is capable of > >renegotiating. If a node knows that its peer is not capable of > >re-negotiating then the node should not initiate re-negotiation. In > this > >scheme, existing implementations will be spared of any change. > > I'm not sure I picked up the version number. I don't see a reason to do > > something special. I would simply like to renegotiate. If the other > side > does not respond to the CER, you shut down the connection and restart it > > after some period of time. This is what you would do if your initial > CER > did not get a response. How is this different? > > > Best Regards, > Timothy Smith > > Vishnu wrote: > > Hi, > > > > Some clarifications and comments on the discussion on this thread: > > > > We would like to clarify the following practical scenarios of this > > happenning: > > 1. there are a list of published applications which the box support > > and these are installed in the box. Now, some of them go down/up. This > > would > > get translated into change in peer capabilities. > > 2. there is a new application which is getting installed/removed from > > the box. > > > > We think that (1) is the most probable scenario. so, > > there is value in giving a simple solution assuming that this change > (in > > capabilities) > > is most probably temporary. If this is not the case, we are talking > > about (2), which is > > a major change in the box anyways. So in (2), we assume it is ok to > > assume that > > the connections to be reestablished. > > > > We would like to say that our design goals are: > > 3. solution should be simple & as backward compatible as possible. > > 4. minimize the FSM changes. > > > > We suggest: > > 5. Updating peer capabilities done only using a CER/CEA in the open > > state. > > Sender of CER/CEA updates the local capabilities before sending the > > message and > > hence is a local decision. > > > > 6. The rest of the processing of the CER/CEA will be as per the > current > > RFC. > > Say for example, if there are no > > common applications left with that peer, > DIAMETER_NO_COMMON_APPLICATION > > is sent in the > > CEA and the connection is closed. > > > > Problems in the email thread under discussion & some comments: > > 7. Cross over and sequencing of CER/CEA exchange. We dont think there > is > > a problem > > here. Cant find any race condition. > > > > 8. Mutual agreement to bring down applications will not work due to > > possible relays > > in between as Tolga has pointed out in the mailing list. > > > > 9. The DPR solution in the suggested text is not a good idea. Because > > DPR cannot > > advertise the latest local applications to the peer. This may cause > the > > race condition > > and sequencing problem. This problem can be avoided by using the > > approach which > > we suggested in (5). > > > > Regards, > > Vishnu. > > tjsmith@us.ibm.com > (919) 254-4723 > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Apr 10 10:43:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxbi-0001oj-1j; Mon, 10 Apr 2006 10:43:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxbg-0001oe-A6 for dime@ietf.org; Mon, 10 Apr 2006 10:43:08 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSxbf-0004Ed-2j for dime@ietf.org; Mon, 10 Apr 2006 10:43:08 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k3AEh3FN050100; Mon, 10 Apr 2006 10:43:04 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <443A6EF9.8010305@tari.toshiba.com> Date: Mon, 10 Apr 2006 10:43:05 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] CER/CEA on an open connection References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi All, > I believe in general now we all have a good understanding about what the > issues are for renegotiation. It could be an idea to have a new iteration of > the proposed text, and to continue the discussions on the new version. > To that end, I'll plan on generating a new set of text maybe next week as we let people digest and hopefully comment on the latest round of discussion for the next couple of days. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 12 03:05:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTZPU-00066K-BM; Wed, 12 Apr 2006 03:05:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTZPT-00066F-Dy for DiME@ietf.org; Wed, 12 Apr 2006 03:05:03 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTZPN-0001Em-IT for DiME@ietf.org; Wed, 12 Apr 2006 03:05:03 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXL004HDL4YGO@szxga03-in.huawei.com> for DiME@ietf.org; Wed, 12 Apr 2006 15:07:46 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXL00HZQL4X0P@szxga03-in.huawei.com> for DiME@ietf.org; Wed, 12 Apr 2006 15:07:46 +0800 (CST) Received: from CMTEST6 ([10.70.149.165]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXL00AXDLEO86@szxml02-in.huawei.com> for DiME@ietf.org; Wed, 12 Apr 2006 15:13:36 +0800 (CST) Date: Wed, 12 Apr 2006 14:59:49 +0800 From: Tina TSOU Subject: [Dime] assure proxies can remain in the path of all requests in a session? To: DiME@ietf.org Message-id: <023b01c65dfe$b0c9a840$a595460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <443A6EF9.8010305@tari.toshiba.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, Consider the WLAN 3GPP IP access [23.234]. The WLAN Access Network (WLAN AN) uses EAP over RADIUS/DIAMETER with the 3GPP AAA server (or proxy) for authentication & authorization. In the roaming case, the WLAN AN is communicating with a 3GPP AAA Proxy in the visited network over the Wa reference point. The 3GPP AAA proxy is connected to the 3GPP Server in the home network over the Wd reference point. The 3GPP AAA Proxy among its many functions will enforce local policies on access based on agreement with the 3GPP Home Network and with the WLAN operator. It will also send per user charging information for the session to the Offline Charging system. This necessitates the proxy to maintain the session state information and hence remain in-path for the entire session. How to assure proxies can remain in the path of all requests in a session? B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 12 03:43:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTa0a-0003vb-Uv; Wed, 12 Apr 2006 03:43:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTa0a-0003vW-6F for DiME@ietf.org; Wed, 12 Apr 2006 03:43:24 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTa0X-0002EC-LV for DiME@ietf.org; Wed, 12 Apr 2006 03:43:24 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXL0049WNF68F@szxga02-in.huawei.com> for DiME@ietf.org; Wed, 12 Apr 2006 15:57:06 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXL005HONF5M6@szxga02-in.huawei.com> for DiME@ietf.org; Wed, 12 Apr 2006 15:57:05 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXL00BHUNEU9G@szxml02-in.huawei.com> for DiME@ietf.org; Wed, 12 Apr 2006 15:56:54 +0800 (CST) Date: Wed, 12 Apr 2006 15:43:07 +0800 From: zhangtao Subject: Re: [Dime] assure proxies can remain in the path of all requests in asession? To: Tina TSOU Message-id: <000d01c65e04$bd729100$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: DiME@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org References: <443A6EF9.8010305@tari.toshiba.com> <023b01c65dfe$b0c9a840$a595460a@china.huawei.com> In my Idea,now Diameter Message routing base on Destination Realm and Destination Host.if one route entry have two peer entry,it cannot assure start session use first Peer,the stop session will use first peer also. if one route table have only one peer entry,then no problem,this means all message will route same nodes. I think this will restrict operator contruct his network.also can not meet the network reliability requirment. I suggest extend Diameter route policy,maybe reference sip or IP protocol ----- Original Message ----- From: "Tina TSOU" To: Sent: Wednesday, April 12, 2006 2:59 PM Subject: [Dime] assure proxies can remain in the path of all requests in asession? > Hi all, > Consider the WLAN 3GPP IP access [23.234]. The WLAN Access Network (WLAN AN) uses EAP over RADIUS/DIAMETER with the 3GPP AAA server (or proxy) for authentication & authorization. > In the roaming case, the WLAN AN is communicating with a 3GPP AAA Proxy in the visited network over the Wa reference point. The 3GPP AAA proxy is connected to the 3GPP Server in the home network over the Wd reference point. The 3GPP AAA Proxy among its many functions will enforce local policies on access based on agreement with the 3GPP Home Network and with the WLAN operator. It will also send per user charging information for the session to the Offline Charging system. This necessitates the proxy to maintain the session state information and hence remain in-path for the entire session. > How to assure proxies can remain in the path of all requests in a session? > > B. R. > Tina > Messengers: > MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 12 08:20:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeKV-00075E-Ui; Wed, 12 Apr 2006 08:20:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeKV-000759-I4 for dime@ietf.org; Wed, 12 Apr 2006 08:20:15 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTeKU-0003pu-Bu for dime@ietf.org; Wed, 12 Apr 2006 08:20:15 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 053D51E384 for ; Wed, 12 Apr 2006 08:20:14 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k3CCKDGp024128 for ; Wed, 12 Apr 2006 08:20:13 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] assure proxies can remain in the path of all requests inasession? Date: Wed, 12 Apr 2006 07:58:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000d01c65e04$bd729100$3791460a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org > In my Idea,now Diameter Message routing base on Destination > Realm and Destination Host.if one route entry have two peer > entry,it cannot assure start session use first Peer,the stop > session will use first peer also. [TOLGA]The behavior you described is achieved by populating Destination-Host AVP for the non-first messages of a session. this assures that all of them land on the same node. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 12 09:43:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfdP-00037Q-Q4; Wed, 12 Apr 2006 09:43:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfdO-00037L-CC for dime@ietf.org; Wed, 12 Apr 2006 09:43:50 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTfdN-00064c-3d for dime@ietf.org; Wed, 12 Apr 2006 09:43:50 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id D9FF808576 for ; Wed, 12 Apr 2006 09:43:48 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k3CDhmme002349 for ; Wed, 12 Apr 2006 09:43:48 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] assure proxies can remain in the path of all requests in asession? Date: Wed, 12 Apr 2006 09:22:12 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <023b01c65dfe$b0c9a840$a595460a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org > Consider the WLAN 3GPP IP access [23.234]. The WLAN Access > Network (WLAN AN) uses EAP over RADIUS/DIAMETER with the 3GPP AAA > server (or proxy) for authentication & authorization. > In the roaming case, the WLAN AN is communicating with a 3GPP AAA > Proxy in the visited network over the Wa reference point. The > 3GPP AAA proxy is connected to the 3GPP Server in the home > network over the Wd reference point. The 3GPP AAA Proxy among > its many functions will enforce local policies on access based on > agreement with the 3GPP Home Network and with the WLAN operator. > It will also send per user charging information for the session > to the Offline Charging system. This necessitates the proxy to > maintain the session state information and hence remain in-path > for the entire session. > How to assure proxies can remain in the path of all requests in a session? [TOLGA]By proper configuration of the routing tables in the nodes + proper routing logic to select the same next hop for messages of the same session (?). I believe the key point is not to establish a transport connection between endpoints after the first transaction of a session. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 12 20:19:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTpYA-0007wl-KI; Wed, 12 Apr 2006 20:19:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTpY9-0007tE-Kl for DiME@ietf.org; Wed, 12 Apr 2006 20:19:05 -0400 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTpY9-0006k9-9o for DiME@ietf.org; Wed, 12 Apr 2006 20:19:05 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 12 Apr 2006 17:19:04 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3D0J3h2009845; Wed, 12 Apr 2006 17:19:04 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Apr 2006 17:19:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] assure proxies can remain in the path of all requests in asession? Date: Wed, 12 Apr 2006 17:19:02 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501DA4FE4@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] assure proxies can remain in the path of all requests in asession? Thread-Index: AcZd/7NdQ43//7E0SAyQpRajrntT0wAj7JfQ From: "Glen Zorn \(gwz\)" To: "Tina TSOU" , X-OriginalArrivalTime: 13 Apr 2006 00:19:04.0403 (UTC) FILETIME=[DF29CA30:01C65E8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tina TSOU supposedly scribbled: > Hi all, > Consider the WLAN 3GPP IP access [23.234]. The WLAN Access Network > (WLAN AN) uses EAP over RADIUS/DIAMETER with the 3GPP AAA server (or > proxy) for authentication & authorization. =20 > In the roaming case, the WLAN AN is communicating with a 3GPP AAA > Proxy in the visited network over the Wa reference point. The 3GPP > AAA proxy is connected to the 3GPP Server in the home network over > the Wd reference point. The 3GPP AAA Proxy among its many functions > will enforce local policies on access based on agreement with the > 3GPP Home Network and with the WLAN operator. It will also send per > user charging information for the session to the Offline Charging > system. This necessitates the proxy to maintain the session state > information and hence remain in-path for the entire session. How to > assure proxies can remain in the path of all requests in a session? =20 Use a modem to connect the two; i.e., if you want a circuit-switched = network, use a circuit-switched network. Note the absence of emoticons. >=20 > B. R. > Tina > Messengers: > MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU =20 > Jabber: tina@jabber.org > _______________________________________________=20 >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 12 20:20:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTpZt-0000Xd-V7; Wed, 12 Apr 2006 20:20:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTpZt-0000XY-LV for DiME@ietf.org; Wed, 12 Apr 2006 20:20:53 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTpZt-0006lY-Aj for DiME@ietf.org; Wed, 12 Apr 2006 20:20:53 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2006 17:20:54 -0700 X-IronPort-AV: i="4.04,116,1144047600"; d="scan'208"; a="423622271:sNHT28103384" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k3D0KnRX000729; Wed, 12 Apr 2006 17:20:52 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Apr 2006 17:20:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] assure proxies can remain in the path of all requests inasession? Date: Wed, 12 Apr 2006 17:20:49 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501DA4FE6@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] assure proxies can remain in the path of all requests inasession? Thread-Index: AcZeBO6vK3usLwEbRMi27ueXVmIvDgAiwTgw From: "Glen Zorn \(gwz\)" To: "zhangtao" , "Tina TSOU" X-OriginalArrivalTime: 13 Apr 2006 00:20:50.0933 (UTC) FILETIME=[1EA8FA50:01C65E90] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: DiME@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org zhangtao supposedly scribbled: > References: > <443A6EF9.8010305@tari.toshiba.com> > <023b01c65dfe$b0c9a840$a595460a@china.huawei.com> >=20 > In my Idea,now Diameter Message routing base on Destination Realm > and Destination Host.if one route entry have two peer entry,it > cannot assure start session use first Peer,the stop session will use > first peer also. =20 >=20 > if one route table have only one peer entry,then no problem,this > means all message will route same nodes.=20 >=20 > I think this will restrict operator contruct his network.also can not > meet the network reliability requirment.=20 >=20 > I suggest extend Diameter route policy,maybe reference sip or IP > protocol=20 Possibly the problem here is that you appear to believe that IP is a = circuit-switched protocol. >=20 > ----- Original Message ----- > From: "Tina TSOU" > To: > Sent: Wednesday, April 12, 2006 2:59 PM > Subject: [Dime] assure proxies can remain in the path of all requests > in asession?=20 >=20 >=20 >> Hi all, >> Consider the WLAN 3GPP IP access [23.234]. The WLAN Access Network >> (WLAN AN) uses EAP over RADIUS/DIAMETER with the 3GPP AAA server (or >> proxy) for authentication & authorization. =20 >> In the roaming case, the WLAN AN is communicating with a 3GPP AAA >> Proxy in the visited network over the Wa reference point. The 3GPP >> AAA proxy is connected to the 3GPP Server in the home network over >> the Wd reference point. The 3GPP AAA Proxy among its many functions >> will enforce local policies on access based on agreement with the >> 3GPP Home Network and with the WLAN operator. It will also send per >> user charging information for the session to the Offline Charging >> system. This necessitates the proxy to maintain the session state >> information and hence remain in-path for the entire session. How to >> assure proxies can remain in the path of all requests in a session?=20 >>=20 >> B. R. >> Tina >> Messengers: >> MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU =20 >> Jabber: tina@jabber.org >> _______________________________________________=20 >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 12 20:28:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTph4-0004Ww-Up; Wed, 12 Apr 2006 20:28:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTph3-0004Ql-HC for dime@ietf.org; Wed, 12 Apr 2006 20:28:17 -0400 Received: from test-iport-2.cisco.com ([171.71.176.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTph1-0006uE-1f for dime@ietf.org; Wed, 12 Apr 2006 20:28:17 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-2.cisco.com with ESMTP; 12 Apr 2006 17:28:14 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3D0SCh2016661; Wed, 12 Apr 2006 17:28:12 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Apr 2006 17:28:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] assure proxies can remain in the path of all requestsinasession? Date: Wed, 12 Apr 2006 17:28:08 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501DA4FF2@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] assure proxies can remain in the path of all requestsinasession? Thread-Index: AcZeK4/d5tUjWhL2Ta+lP+Lgc85kKAAZV+hQ From: "Glen Zorn \(gwz\)" To: "Tolga Asveren" X-OriginalArrivalTime: 13 Apr 2006 00:28:09.0877 (UTC) FILETIME=[244A8450:01C65E91] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tolga Asveren supposedly scribbled: >> In my Idea,now Diameter Message routing base on Destination Realm >> and Destination Host.if one route entry have two peer entry,it >> cannot assure start session use first Peer,the stop session will use >> first peer also. > [TOLGA]The behavior you described is achieved by populating > Destination-Host AVP for the non-first messages of a session. this > assures that all of them land on the same node. =20 It assures that the messages will attain the same _final destination_, = not that all the messages will traverse the same set of agents en route = to that destination. >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 12 21:11:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTqMZ-0000ZI-2s; Wed, 12 Apr 2006 21:11:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTqMY-0000ZD-Gn for dime@ietf.org; Wed, 12 Apr 2006 21:11:10 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTqMW-0007mQ-O7 for dime@ietf.org; Wed, 12 Apr 2006 21:11:10 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXM0071IZ8ZQW@szxga01-in.huawei.com> for dime@ietf.org; Thu, 13 Apr 2006 09:10:11 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXM00C9KZ8YTO@szxga01-in.huawei.com> for dime@ietf.org; Thu, 13 Apr 2006 09:10:11 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXM00810ZVWNO@szxml02-in.huawei.com>; Thu, 13 Apr 2006 09:23:56 +0800 (CST) Date: Thu, 13 Apr 2006 09:10:07 +0800 From: zhangtao Subject: Re: [Dime] assure proxies can remain in the path of all requestsinasession? To: Tolga Asveren , dime@ietf.org Message-id: <000e01c65e97$011824f0$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Think about below situation: Client - Relay Agent - Proxy Agent1 - Server - Proxy Agent2 client directly connection to realy agent.realy agent connection two proxy agent(Prxoy agent1 and Proxy agent2),both proxy agent can route to server. Non -First Message is base on Destion-Host,only can assure Go to the same server,but cannot assure route to same prxoy agent(maybe all agent).when client send message ,in peer table cannot find server,then will use Destion Realm,if have two peer entry in the route entry,it can select any one.maybe we can think about client record his first message of a session.then he use same Next Hop. but if have relay agent,how to do,we cannot requirment,realy agent record any information about session. so the message it can select proxy agent1 or proxy agent2. assume first session message route by proxy agent1. non first session message route by prxoy agent2,then proxy agent1 maintain session state will bring problem. ----- Original Message ----- From: "Tolga Asveren" To: Sent: Wednesday, April 12, 2006 7:58 PM Subject: RE: [Dime] assure proxies can remain in the path of all requestsinasession? > > In my Idea,now Diameter Message routing base on Destination > > Realm and Destination Host.if one route entry have two peer > > entry,it cannot assure start session use first Peer,the stop > > session will use first peer also. > [TOLGA]The behavior you described is achieved by populating Destination-Host > AVP for the non-first messages of a session. this assures that all of them > land on the same node. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 12 21:34:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTqjO-0004hd-QU; Wed, 12 Apr 2006 21:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTqjN-0004hY-Nl for DiME@ietf.org; Wed, 12 Apr 2006 21:34:45 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTqjM-00008F-Cz for DiME@ietf.org; Wed, 12 Apr 2006 21:34:45 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXN0073B0CFQW@szxga01-in.huawei.com> for DiME@ietf.org; Thu, 13 Apr 2006 09:33:51 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXN003ZK0CE03@szxga01-in.huawei.com> for DiME@ietf.org; Thu, 13 Apr 2006 09:33:50 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXN0045G15IUY@szxml01-in.huawei.com>; Thu, 13 Apr 2006 09:51:19 +0800 (CST) Date: Thu, 13 Apr 2006 09:33:47 +0800 From: zhangtao Subject: Re: [Dime] assure proxies can remain in the path of all requests inasession? To: "Glen Zorn (gwz)" , Tina TSOU Message-id: <002901c65e9a$4f3621c0$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4C0FAAC489C8B74F96BEAD85EAEB262501DA4FE6@xmb-sjc-215.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: DiME@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org if the proxy agent is just relay agent, i agree with you.Because he no need maintain session state,he need credit authorization.he no need bill etc.the visited network is free service,inter-operator no need hide network topology. In my knowledge, ipv6 protocol have Routing Header.Sip protocl have Route Header, Both use for force route to some hop.Both is Ip-switched protocol. ----- Original Message ----- From: "Glen Zorn (gwz)" To: "zhangtao" ; "Tina TSOU" Cc: Sent: Thursday, April 13, 2006 8:20 AM Subject: RE: [Dime] assure proxies can remain in the path of all requests inasession? zhangtao supposedly scribbled: > References: > <443A6EF9.8010305@tari.toshiba.com> > <023b01c65dfe$b0c9a840$a595460a@china.huawei.com> > > In my Idea,now Diameter Message routing base on Destination Realm > and Destination Host.if one route entry have two peer entry,it > cannot assure start session use first Peer,the stop session will use > first peer also. > > if one route table have only one peer entry,then no problem,this > means all message will route same nodes. > > I think this will restrict operator contruct his network.also can not > meet the network reliability requirment. > > I suggest extend Diameter route policy,maybe reference sip or IP > protocol Possibly the problem here is that you appear to believe that IP is a circuit-switched protocol. > > ----- Original Message ----- > From: "Tina TSOU" > To: > Sent: Wednesday, April 12, 2006 2:59 PM > Subject: [Dime] assure proxies can remain in the path of all requests > in asession? > > >> Hi all, >> Consider the WLAN 3GPP IP access [23.234]. The WLAN Access Network >> (WLAN AN) uses EAP over RADIUS/DIAMETER with the 3GPP AAA server (or >> proxy) for authentication & authorization. >> In the roaming case, the WLAN AN is communicating with a 3GPP AAA >> Proxy in the visited network over the Wa reference point. The 3GPP >> AAA proxy is connected to the 3GPP Server in the home network over >> the Wd reference point. The 3GPP AAA Proxy among its many functions >> will enforce local policies on access based on agreement with the >> 3GPP Home Network and with the WLAN operator. It will also send per >> user charging information for the session to the Offline Charging >> system. This necessitates the proxy to maintain the session state >> information and hence remain in-path for the entire session. How to >> assure proxies can remain in the path of all requests in a session? >> >> B. R. >> Tina >> Messengers: >> MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU >> Jabber: tina@jabber.org >> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 12 22:25:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTrW9-0006vX-87; Wed, 12 Apr 2006 22:25:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTrW7-0006vK-S1 for DiME@ietf.org; Wed, 12 Apr 2006 22:25:07 -0400 Received: from test-iport-2.cisco.com ([171.71.176.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTrW5-0001Ra-9v for DiME@ietf.org; Wed, 12 Apr 2006 22:25:07 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-2.cisco.com with ESMTP; 12 Apr 2006 19:25:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3D2P4h0015316; Wed, 12 Apr 2006 19:25:04 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Apr 2006 19:25:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] assure proxies can remain in the path of all requests inasession? Date: Wed, 12 Apr 2006 19:25:00 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501DA5030@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] assure proxies can remain in the path of all requests inasession? Thread-Index: AcZemlGf22Dns/mASxKyNKootaiNUgABvDZQ From: "Glen Zorn \(gwz\)" To: "zhangtao" , "Tina TSOU" X-OriginalArrivalTime: 13 Apr 2006 02:25:04.0631 (UTC) FILETIME=[79690870:01C65EA1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: DiME@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org zhangtao supposedly scribbled: > if the proxy agent is just relay agent, i agree with you.Because he > no need maintain session state,he need credit authorization.he no > need bill etc.the visited network is free service,inter-operator no > need hide network topology. =20 >=20 > In my knowledge, ipv6 protocol have Routing Header.Sip protocl have > Route Header, Both use for force route to some hop.Both is > Ip-switched protocol. So you want to source-route Diameter messages. Excellent. Please carry = on. =20 ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 12 23:22:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTsPc-0002qP-9J; Wed, 12 Apr 2006 23:22:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTsPb-0002lc-Ht for DiME@ietf.org; Wed, 12 Apr 2006 23:22:27 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTsPZ-00037b-OQ for DiME@ietf.org; Wed, 12 Apr 2006 23:22:27 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXN003L25RRDI@szxga02-in.huawei.com> for DiME@ietf.org; Thu, 13 Apr 2006 11:31:03 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXN008WJ5RJ34@szxga02-in.huawei.com> for DiME@ietf.org; Thu, 13 Apr 2006 11:31:03 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXN0096I5XNIN@szxml01-in.huawei.com>; Thu, 13 Apr 2006 11:34:35 +0800 (CST) Date: Thu, 13 Apr 2006 11:17:03 +0800 From: zhangtao Subject: Re: [Dime] assure proxies can remain in the path of all requests inasession? To: "Glen Zorn (gwz)" , Tina TSOU Message-id: <001901c65ea8$bcb60540$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4C0FAAC489C8B74F96BEAD85EAEB262501DA5030@xmb-sjc-215.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: DiME@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org First we should discuss about the requirment,non-first message of session should force routing some proxy agents. if the requirment is required, non-first message of session should specify these proxy agents address,othewise use destion-host and destion realm cannot assure routing these proxy agents. we can reference the sip protocol implement.the first message of session.collect proxy agent address information. ,when send non-first message of session.should give all proxy agent address informaiton also. ----- Original Message ----- From: "Glen Zorn (gwz)" To: "zhangtao" ; "Tina TSOU" Cc: Sent: Thursday, April 13, 2006 10:25 AM Subject: RE: [Dime] assure proxies can remain in the path of all requests inasession? zhangtao supposedly scribbled: > if the proxy agent is just relay agent, i agree with you.Because he > no need maintain session state,he need credit authorization.he no > need bill etc.the visited network is free service,inter-operator no > need hide network topology. > > In my knowledge, ipv6 protocol have Routing Header.Sip protocl have > Route Header, Both use for force route to some hop.Both is > Ip-switched protocol. So you want to source-route Diameter messages. Excellent. Please carry on. ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 13 06:06:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTyiN-0000g2-1x; Thu, 13 Apr 2006 06:06:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTyiL-0000fx-5O for DiME@ietf.org; Thu, 13 Apr 2006 06:06:13 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTyiJ-0006f5-Gr for DiME@ietf.org; Thu, 13 Apr 2006 06:06:12 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3DAMc7h015608 for ; Thu, 13 Apr 2006 03:22:38 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3DAJhpF025160 for ; Thu, 13 Apr 2006 05:19:44 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] assure proxies can remain in the path of all requests in asession? Date: Thu, 13 Apr 2006 18:06:08 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] assure proxies can remain in the path of all requests in asession? Thread-Index: AcZd/4KceicLmkqfSuWDOXH+2ktJ8gA4gOvQ From: "Ram O V Vishnu-A14676" To: "Tina TSOU" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tina, When the WLAN AN (in the visited network) sends the EAP over Diameter message, what does it have in the message as destination host?=20 The 3GPP AAA Server (Proxy) in the visited network? Or the 3GPP AAA Server in the home network (Server)? Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: Wednesday, April 12, 2006 12:30 PM To: DiME@ietf.org Subject: [Dime] assure proxies can remain in the path of all requests in asession? Hi all, Consider the WLAN 3GPP IP access [23.234]. The WLAN Access Network (WLAN AN) uses EAP over RADIUS/DIAMETER with the 3GPP AAA server (or proxy) for authentication & authorization.=20 In the roaming case, the WLAN AN is communicating with a 3GPP AAA Proxy in the visited network over the Wa reference point. The 3GPP AAA proxy is connected to the 3GPP Server in the home network over the Wd reference point. The 3GPP AAA Proxy among its many functions will enforce local policies on access based on agreement with the 3GPP Home Network and with the WLAN operator. It will also send per user charging information for the session to the Offline Charging system. This necessitates the proxy to maintain the session state information and hence remain in-path for the entire session.=20 How to assure proxies can remain in the path of all requests in a session? B. R. Tina Messengers:=20 MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 13 06:15:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTyrX-0005ny-Sx; Thu, 13 Apr 2006 06:15:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTyrW-0005nt-CJ for dime@ietf.org; Thu, 13 Apr 2006 06:15:42 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTyrS-0006vl-1n for dime@ietf.org; Thu, 13 Apr 2006 06:15:42 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3DAW5sp017160 for ; Thu, 13 Apr 2006 03:32:05 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3DAToBb001175 for ; Thu, 13 Apr 2006 05:29:50 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] assure proxies can remain in the path of allrequestsinasession? Date: Thu, 13 Apr 2006 18:15:35 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] assure proxies can remain in the path of allrequestsinasession? Thread-Index: AcZelypAMKuaTD7KQtaZSw+kb2h2PwAS2QOg From: "Ram O V Vishnu-A14676" To: "zhangtao" , "Tolga Asveren" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I think in this case, if you are particular that the message should pass through the specific proxy, you should have the proxy as the destination host of the (non-first) message.=20 Anyways (since you are saying that) the proxy is stateful & keeps per session state, it can also keep the consistent routing info? (as Tolga pointed out earlier). This will make sure that the proxy is able to route to the next hop as well consistently. Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only -----Original Message----- From: zhangtao [mailto:zhangtao_hw@huawei.com]=20 Sent: Thursday, April 13, 2006 6:40 AM To: Tolga Asveren; dime@ietf.org Subject: Re: [Dime] assure proxies can remain in the path of allrequestsinasession? Think about below situation: Client - Relay Agent - Proxy Agent1 - Server - Proxy Agent2=20 client directly connection to realy agent.realy agent connection two proxy agent(Prxoy agent1 and Proxy agent2),both proxy agent can route to server. Non -First Message is base on Destion-Host,only can assure Go to the same server,but cannot assure route to same prxoy agent(maybe all agent).when client send message ,in peer table cannot find server,then will use Destion Realm,if have two peer entry in the route entry,it can select any one.maybe we can think about client record his first message of a session.then he use same Next Hop. but if have relay agent,how to do,we cannot requirment,realy agent record any information about session. so the message it can select proxy agent1 or proxy agent2. assume first session message route by proxy agent1. non first session message route by prxoy agent2,then proxy agent1 maintain session state will bring problem. ----- Original Message -----=20 From: "Tolga Asveren" To: Sent: Wednesday, April 12, 2006 7:58 PM Subject: RE: [Dime] assure proxies can remain in the path of all requestsinasession? > > In my Idea,now Diameter Message routing base on Destination Realm=20 > > and Destination Host.if one route entry have two peer entry,it=20 > > cannot assure start session use first Peer,the stop session will use > > first peer also. > [TOLGA]The behavior you described is achieved by populating=20 > Destination-Host AVP for the non-first messages of a session. this=20 > assures that all of them land on the same node. >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 13 09:01:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1SQ-0000vE-EZ; Thu, 13 Apr 2006 09:01:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1SP-0000v6-MC for DiME@ietf.org; Thu, 13 Apr 2006 09:01:57 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU1SM-0003Xl-DH for DiME@ietf.org; Thu, 13 Apr 2006 09:01:55 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k3DD1aKf066698; Thu, 13 Apr 2006 09:01:37 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <443D7715.3000203@tari.toshiba.com> Date: Wed, 12 Apr 2006 17:54:29 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "Glen Zorn (gwz)" Subject: Re: [Dime] assure proxies can remain in the path of all requests inasession? References: <4C0FAAC489C8B74F96BEAD85EAEB262501DA5030@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262501DA5030@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: DiME@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org if you can relay route-record avp (generated in first request) from final destination back to the originator in the answer messages, your proxies can pick those records and maybe able to determine possible next hops for subsequent request ... a poor man's source routing. regards, victor >> if the proxy agent is just relay agent, i agree with you.Because he >> no need maintain session state,he need credit authorization.he no >> need bill etc.the visited network is free service,inter-operator no >> need hide network topology. >> >> In my knowledge, ipv6 protocol have Routing Header.Sip protocl have >> Route Header, Both use for force route to some hop.Both is >> Ip-switched protocol. >> > > So you want to source-route Diameter messages. Excellent. Please carry on. > > ~gwz > > Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 13 09:14:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1ex-0003a3-HI; Thu, 13 Apr 2006 09:14:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1ew-0003Zy-Ch for dime@ietf.org; Thu, 13 Apr 2006 09:14:54 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU1ew-0004Id-3Y for dime@ietf.org; Thu, 13 Apr 2006 09:14:54 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k3DDEjDd066735; Thu, 13 Apr 2006 09:14:45 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <443D7A2B.1050603@tari.toshiba.com> Date: Wed, 12 Apr 2006 18:07:39 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Ram O V Vishnu-A14676 Subject: Re: [Dime] assure proxies can remain in the path of allrequestsinasession? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, > I think in this case, if you are particular that the message should pass > through the specific proxy, you should have the proxy as the destination > host of the (non-first) message. > > Anyways (since you are saying that) the proxy is stateful & keeps per > session state, it can also keep the consistent routing info? (as Tolga > pointed out earlier). This will make sure that the proxy is able to > route to the next hop as well consistently. > In the sip case, strict routing is not always possible because operators normally deploy multiple agents for load balancing/redundancy. hence, subsequent request are not guaranteed to go through the same routing path as previous request. One contradiction is that load balancing is less effective if strict routing is allowed. regards, victor > Regards, > Vishnu. > > Motorola India Electronics Pvt Ltd > +91 9844178052 > [*] Motorola Internal Use Only > > > > -----Original Message----- > From: zhangtao [mailto:zhangtao_hw@huawei.com] > Sent: Thursday, April 13, 2006 6:40 AM > To: Tolga Asveren; dime@ietf.org > Subject: Re: [Dime] assure proxies can remain in the path of > allrequestsinasession? > > > Think about below situation: > Client - Relay Agent - Proxy Agent1 - Server > - Proxy Agent2 > client directly connection to realy agent.realy agent connection two > proxy agent(Prxoy agent1 and Proxy agent2),both proxy agent can route to > server. > > Non -First Message is base on Destion-Host,only can assure Go to the > same server,but cannot assure route to same prxoy agent(maybe all > agent).when client send message ,in peer table cannot find server,then > will use Destion Realm,if have two peer entry in the route entry,it can > select any one.maybe we can think about client record his first message > of a session.then he use same Next Hop. but if have relay agent,how to > do,we cannot requirment,realy agent record any information about > session. so the message it can select proxy agent1 or proxy agent2. > assume first session message route by proxy agent1. non first session > message route by prxoy agent2,then proxy agent1 maintain session state > will bring problem. > > ----- Original Message ----- > From: "Tolga Asveren" > To: > Sent: Wednesday, April 12, 2006 7:58 PM > Subject: RE: [Dime] assure proxies can remain in the path of all > requestsinasession? > > > >>> In my Idea,now Diameter Message routing base on Destination Realm >>> and Destination Host.if one route entry have two peer entry,it >>> cannot assure start session use first Peer,the stop session will use >>> > > >>> first peer also. >>> >> [TOLGA]The behavior you described is achieved by populating >> Destination-Host AVP for the non-first messages of a session. this >> assures that all of them land on the same node. >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 13 09:16:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1gx-0004VO-GW; Thu, 13 Apr 2006 09:16:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1gw-0004VJ-TT for dime@ietf.org; Thu, 13 Apr 2006 09:16:58 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU1gw-0004YC-Id for dime@ietf.org; Thu, 13 Apr 2006 09:16:58 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id E25572496C for ; Thu, 13 Apr 2006 09:16:58 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k3DDGvV9029877 for ; Thu, 13 Apr 2006 09:16:57 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] assure proxies can remain in the path of all requestsinasession? Date: Thu, 13 Apr 2006 08:55:14 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000e01c65e97$011824f0$3791460a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org > Think about below situation: > Client - Relay Agent - Proxy Agent1 - Server > - Proxy Agent2 > client directly connection to realy agent.realy agent connection > two proxy agent(Prxoy agent1 and Proxy agent2),both proxy agent > can route to server. > > Non -First Message is base on Destion-Host,only can assure Go to > the same server,but cannot assure route to same prxoy agent(maybe > all agent).when client send message ,in peer table cannot find > server,then will use Destion Realm,if have two peer entry in the > route entry,it can select any one.maybe we can think about client > record his first message of a session.then he use same Next Hop. > but if have relay agent,how to do,we cannot requirment,realy > agent record any information about session. so the message it can > select proxy agent1 or proxy agent2. assume first session message > route by proxy agent1. non first session message route by prxoy > agent2,then proxy agent1 maintain session state will bring problem. [TOLGA}Yes, you are right, but by keeping next-hop per session info, you can guarantee the delivery to the same Proxy Agent. Now, you can argue, whether such a node should be called Relay Agent or something else but I believe naming won't cause interoprability problems. Alternatively -mentioned by Vishnu already- you can actually proxy the service you are providing, where Proxy1/Proxy2 populate Origin-Host AVP with their thir identities for the answer of the first request in the session. This would require Proxy1/Proxy2 to keep states and modify the content of the messages but if they are built for that purpose, there probably wouldn't be a problem. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 13 09:30:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1uE-00014S-Rs; Thu, 13 Apr 2006 09:30:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1uD-00014N-Fb for dime@ietf.org; Thu, 13 Apr 2006 09:30:41 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU1uD-00050i-7j for dime@ietf.org; Thu, 13 Apr 2006 09:30:41 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 7C7A4AF2D3 for ; Thu, 13 Apr 2006 09:30:40 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k3DDUdcg001158 for ; Thu, 13 Apr 2006 09:30:39 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] assure proxies can remain in the path of allrequestsinasession? Date: Thu, 13 Apr 2006 09:08:56 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <443D7A2B.1050603@tari.toshiba.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Wednesday, April 12, 2006 6:08 PM > To: Ram O V Vishnu-A14676 > Cc: zhangtao; Tolga Asveren; dime@ietf.org > Subject: Re: [Dime] assure proxies can remain in the path of > allrequestsinasession? > > > Hi, > > I think in this case, if you are particular that the message should pass > > through the specific proxy, you should have the proxy as the destination > > host of the (non-first) message. > > > > Anyways (since you are saying that) the proxy is stateful & keeps per > > session state, it can also keep the consistent routing info? (as Tolga > > pointed out earlier). This will make sure that the proxy is able to > > route to the next hop as well consistently. > > > In the sip case, strict routing is not always possible because operators > normally deploy multiple agents for load balancing/redundancy. hence, > subsequent request are not guaranteed to go through the same routing > path as previous request. One contradiction is that load balancing is > less effective if strict routing is allowed. [TOLGA]I couldn't get the exact scenario here. By saying "sip case" and "agents" are you referring to SIP entities or Diameter entities? -a simple diagram would be appreciated :-) - _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 13 09:35:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1ym-0003Wx-Ho; Thu, 13 Apr 2006 09:35:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1yl-0003Uf-OE for dime@ietf.org; Thu, 13 Apr 2006 09:35:23 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU1yl-00057P-GZ for dime@ietf.org; Thu, 13 Apr 2006 09:35:23 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k3DDZJZm066793; Thu, 13 Apr 2006 09:35:19 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <443E539B.90507@tari.toshiba.com> Date: Thu, 13 Apr 2006 09:35:23 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] assure proxies can remain in the path of allrequestsinasession? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, >>> >> In the sip case, strict routing is not always possible because operators >> normally deploy multiple agents for load balancing/redundancy. hence, >> subsequent request are not guaranteed to go through the same routing >> path as previous request. One contradiction is that load balancing is >> less effective if strict routing is allowed. >> > [TOLGA]I couldn't get the exact scenario here. By saying "sip case" and > "agents" are you referring to SIP entities or Diameter entities? -a simple > diagram would be appreciated :-) - > Since I'm not good a drawing diagrams you can take a look at draft-ietf-aaa-diameter-sip-app-11.txt :) ... they have excellent diagrams :) regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 13 09:51:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2Em-0005dD-31; Thu, 13 Apr 2006 09:51:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2Ek-0005d8-HN for dime@ietf.org; Thu, 13 Apr 2006 09:51:54 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU2Ek-0005OQ-7d for dime@ietf.org; Thu, 13 Apr 2006 09:51:54 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id A57FB5E326 for ; Thu, 13 Apr 2006 09:51:53 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k3DDpqkN003224 for ; Thu, 13 Apr 2006 09:51:53 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] assure proxies can remain in the path of allrequestsinasession? Date: Thu, 13 Apr 2006 09:30:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <443E539B.90507@tari.toshiba.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, > >> In the sip case, strict routing is not always possible because > operators > >> normally deploy multiple agents for load balancing/redundancy. hence, > >> subsequent request are not guaranteed to go through the same routing > >> path as previous request. One contradiction is that load balancing is > >> less effective if strict routing is allowed. > >> > > [TOLGA]I couldn't get the exact scenario here. By saying "sip case" and > > "agents" are you referring to SIP entities or Diameter > entities? -a simple > > diagram would be appreciated :-) - > > > > Since I'm not good a drawing diagrams you can take a look at > draft-ietf-aaa-diameter-sip-app-11.txt :) ... they have excellent > diagrams :) [TOLGA]Considering Figure1 in that document, load balancing/redundancy for which entity (Proxy1, Proxy2, Diameter Server) would cause a problem and for whaht type of scenario/message flow? _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 13 11:26:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU3iV-0006Gb-NB; Thu, 13 Apr 2006 11:26:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU3iV-0006GW-1j for dime@ietf.org; Thu, 13 Apr 2006 11:26:43 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU3iU-0000KW-Px for dime@ietf.org; Thu, 13 Apr 2006 11:26:43 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k3DFQc6X067423; Thu, 13 Apr 2006 11:26:39 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <443E6B2A.3060809@tari.toshiba.com> Date: Thu, 13 Apr 2006 11:15:54 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] assure proxies can remain in the path of allrequestsinasession? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, >>>> In the sip case, strict routing is not always possible because >>>> >> operators >> >>>> normally deploy multiple agents for load balancing/redundancy. hence, >>>> subsequent request are not guaranteed to go through the same routing >>>> path as previous request. One contradiction is that load balancing is >>>> less effective if strict routing is allowed. >>>> >>>> >>> [TOLGA]I couldn't get the exact scenario here. By saying "sip case" and >>> "agents" are you referring to SIP entities or Diameter >>> >> entities? -a simple >> >>> diagram would be appreciated :-) - >>> >>> >> Since I'm not good a drawing diagrams you can take a look at >> draft-ietf-aaa-diameter-sip-app-11.txt :) ... they have excellent >> diagrams :) >> > [TOLGA]Considering Figure1 in that document, load balancing/redundancy for > which entity (Proxy1, Proxy2, Diameter Server) would cause a problem and for > whaht type of scenario/message flow? > Good question. Apologies for my terse explanations :) From what I've read on certain sip deployments (maybe i'm wrong), SIP server1 in figure 1 can actually be represented by an AAA routing cloud that could contain the diagram described by zhaotao, a client->relay->(proxy1,2,3). the AAA client of the SIP server can send request to the relay which passes can pass the request to any available proxies based on some redundancy or load-balancing schemes. But it can break things since the proxy also needs to maintain state as mentioned previously. In a more extended case, SIP server1 in figure 1 may also represent AAA routing across domains and each domain may have a combination of relays and proxies that want to account for SIP transactions going through them. This maybe in the case that the SIP clients is roaming and some intermediate domain between visited and home domains wants to keep accounting records. Anyway, it maybe a matter of setting up topologies strictly and correctly but that normally puts a damper on load-balancing. my 2 cents, victor > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 13 22:07:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUDiv-0001vs-U4; Thu, 13 Apr 2006 22:07:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUDiv-0001vj-0c for dime@ietf.org; Thu, 13 Apr 2006 22:07:49 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUDit-0005N1-3U for dime@ietf.org; Thu, 13 Apr 2006 22:07:48 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXO00N98WWB3S@szxga03-in.huawei.com> for dime@ietf.org; Fri, 14 Apr 2006 10:14:35 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXO00F0KWW9OF@szxga03-in.huawei.com> for dime@ietf.org; Fri, 14 Apr 2006 10:14:35 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXO00FDVXCAWD@szxml01-in.huawei.com>; Fri, 14 Apr 2006 10:24:10 +0800 (CST) Date: Fri, 14 Apr 2006 10:06:37 +0800 From: zhangtao Subject: Re: [Dime] assure proxies can remain in the path of allrequestsinasession? To: Ram O V Vishnu-A14676 , Tolga Asveren , dime@ietf.org Message-id: <002001c65f68$10367640$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I also think this is one solution. but if the first message of session already give Destination-Host(Maybe this information get from SIM or others,but it can happen) and Destination Realm.this message route by many Proxy agents.then non-first message use first proxy agent's host as Destination-Host(i am not assure should change Destination Realm or not). then in one session,have two different Destination Host.the other question is :when routeing on proxy agent,the proxy agent should change the message's original host or not,because the server maybe initiate reqeust message. ----- Original Message ----- From: "Ram O V Vishnu-A14676" To: "zhangtao" ; "Tolga Asveren" ; Sent: Thursday, April 13, 2006 6:15 PM Subject: RE: [Dime] assure proxies can remain in the path of allrequestsinasession? I think in this case, if you are particular that the message should pass through the specific proxy, you should have the proxy as the destination host of the (non-first) message. Anyways (since you are saying that) the proxy is stateful & keeps per session state, it can also keep the consistent routing info? (as Tolga pointed out earlier). This will make sure that the proxy is able to route to the next hop as well consistently. Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only -----Original Message----- From: zhangtao [mailto:zhangtao_hw@huawei.com] Sent: Thursday, April 13, 2006 6:40 AM To: Tolga Asveren; dime@ietf.org Subject: Re: [Dime] assure proxies can remain in the path of allrequestsinasession? Think about below situation: Client - Relay Agent - Proxy Agent1 - Server - Proxy Agent2 client directly connection to realy agent.realy agent connection two proxy agent(Prxoy agent1 and Proxy agent2),both proxy agent can route to server. Non -First Message is base on Destion-Host,only can assure Go to the same server,but cannot assure route to same prxoy agent(maybe all agent).when client send message ,in peer table cannot find server,then will use Destion Realm,if have two peer entry in the route entry,it can select any one.maybe we can think about client record his first message of a session.then he use same Next Hop. but if have relay agent,how to do,we cannot requirment,realy agent record any information about session. so the message it can select proxy agent1 or proxy agent2. assume first session message route by proxy agent1. non first session message route by prxoy agent2,then proxy agent1 maintain session state will bring problem. ----- Original Message ----- From: "Tolga Asveren" To: Sent: Wednesday, April 12, 2006 7:58 PM Subject: RE: [Dime] assure proxies can remain in the path of all requestsinasession? > > In my Idea,now Diameter Message routing base on Destination Realm > > and Destination Host.if one route entry have two peer entry,it > > cannot assure start session use first Peer,the stop session will use > > first peer also. > [TOLGA]The behavior you described is achieved by populating > Destination-Host AVP for the non-first messages of a session. this > assures that all of them land on the same node. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Apr 14 01:02:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUGSN-0000Ny-IR; Fri, 14 Apr 2006 01:02:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUGSM-0000Ns-UX for DiME@ietf.org; Fri, 14 Apr 2006 01:02:54 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUGSI-000305-6m for DiME@ietf.org; Fri, 14 Apr 2006 01:02:54 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXP00DCY4NFRN@szxga01-in.huawei.com> for DiME@ietf.org; Fri, 14 Apr 2006 13:02:03 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXP00BHK4NE8A@szxga01-in.huawei.com> for DiME@ietf.org; Fri, 14 Apr 2006 13:02:03 +0800 (CST) Received: from CMTEST6 ([10.70.149.165]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXP000H95AAOM@szxml02-in.huawei.com>; Fri, 14 Apr 2006 13:15:47 +0800 (CST) Date: Fri, 14 Apr 2006 13:01:55 +0800 From: Tina TSOU Subject: Re: [Dime] assure proxies can remain in the path of all requests in asession? To: DiME@ietf.org, Ram O V Vishnu-A14676 Message-id: <019401c65f80$8d7b2bb0$a595460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Vishnu, In line B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org ----- Original Message ----- From: "Ram O V Vishnu-A14676" To: "Tina TSOU" ; Sent: Thursday, April 13, 2006 6:06 PM Subject: RE: [Dime] assure proxies can remain in the path of all requests in asession? Tina, When the WLAN AN (in the visited network) sends the EAP over Diameter message, what does it have in the message as destination host? [Tina: First message in session only have destination realm (From EAP message get relative information). non-first message in session destination host is come from first message response.] The 3GPP AAA Server (Proxy) in the visited network? [Tina: 3GPP AAA Proxy in visited network.] Or the 3GPP AAA Server in the home network (Server)? [Tina: 3GPP AAA Server in home network.] Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com] Sent: Wednesday, April 12, 2006 12:30 PM To: DiME@ietf.org Subject: [Dime] assure proxies can remain in the path of all requests in asession? Hi all, Consider the WLAN 3GPP IP access [23.234]. The WLAN Access Network (WLAN AN) uses EAP over RADIUS/DIAMETER with the 3GPP AAA server (or proxy) for authentication & authorization. In the roaming case, the WLAN AN is communicating with a 3GPP AAA Proxy in the visited network over the Wa reference point. The 3GPP AAA proxy is connected to the 3GPP Server in the home network over the Wd reference point. The 3GPP AAA Proxy among its many functions will enforce local policies on access based on agreement with the 3GPP Home Network and with the WLAN operator. It will also send per user charging information for the session to the Offline Charging system. This necessitates the proxy to maintain the session state information and hence remain in-path for the entire session. How to assure proxies can remain in the path of all requests in a session? B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Apr 14 02:22:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUHhi-000713-QY; Fri, 14 Apr 2006 02:22:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUHdg-0006Yy-5z for DiME@ietf.org; Fri, 14 Apr 2006 02:18:40 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUHTq-0004Xg-FT for DiME@ietf.org; Fri, 14 Apr 2006 02:08:36 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXP00G3O8BSXU@szxga02-in.huawei.com> for DiME@ietf.org; Fri, 14 Apr 2006 14:21:28 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXP001LP8BP3Y@szxga02-in.huawei.com> for DiME@ietf.org; Fri, 14 Apr 2006 14:21:28 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXP0039R8BGZ5@szxml02-in.huawei.com>; Fri, 14 Apr 2006 14:21:16 +0800 (CST) Date: Fri, 14 Apr 2006 14:07:25 +0800 From: zhangtao Subject: Re: [Dime] assure proxies can remain in the path of all requests inasession? To: Victor Fajardo , "Glen Zorn (gwz)" Message-id: <004101c65f89$b3a7e180$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4C0FAAC489C8B74F96BEAD85EAEB262501DA5030@xmb-sjc-215.amer.cisco.com> <443D7715.3000203@tari.toshiba.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: DiME@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org if destination give route record back,because route record maybe have relay agent information,then should strictly route all same hop,but this path maybe not reliable,if only have stateful proxy agent information back,it is wonderful.then can select any relay agent. ----- Original Message ----- From: "Victor Fajardo" To: "Glen Zorn (gwz)" Cc: "zhangtao" ; "Tina TSOU" ; Sent: Thursday, April 13, 2006 5:54 AM Subject: Re: [Dime] assure proxies can remain in the path of all requests inasession? > if you can relay route-record avp (generated in first request) from > final destination back to the originator in the answer messages, your > proxies can pick those records and maybe able to determine possible next > hops for subsequent request ... a poor man's source routing. > regards, > victor > >> if the proxy agent is just relay agent, i agree with you.Because he > >> no need maintain session state,he need credit authorization.he no > >> need bill etc.the visited network is free service,inter-operator no > >> need hide network topology. > >> > >> In my knowledge, ipv6 protocol have Routing Header.Sip protocl have > >> Route Header, Both use for force route to some hop.Both is > >> Ip-switched protocol. > >> > > > > So you want to source-route Diameter messages. Excellent. Please carry on. > > > > ~gwz > > > > Why is it that most of the world's problems can't be solved by simply > > listening to John Coltrane? -- Henry Gabriel > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Apr 14 05:06:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUKG8-0003Nb-87; Fri, 14 Apr 2006 05:06:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUKG7-0003N8-7P for dime@ietf.org; Fri, 14 Apr 2006 05:06:31 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUKG5-0001vu-Ot for dime@ietf.org; Fri, 14 Apr 2006 05:06:31 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXP003I7GAIGW@szxga02-in.huawei.com> for dime@ietf.org; Fri, 14 Apr 2006 17:13:30 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXP0066MGAH1D@szxga02-in.huawei.com> for dime@ietf.org; Fri, 14 Apr 2006 17:13:29 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXP003UZGGE1H@szxml01-in.huawei.com>; Fri, 14 Apr 2006 17:17:02 +0800 (CST) Date: Fri, 14 Apr 2006 16:59:28 +0800 From: zhangtao Subject: Re: [Dime] assure proxies can remain in the path of allrequestsinasession? To: Tolga Asveren , dime@ietf.org Message-id: <001901c65fa1$bc9c96b0$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Please Sess Inline ----- Original Message ----- From: "Tolga Asveren" To: Sent: Thursday, April 13, 2006 8:55 PM Subject: RE: [Dime] assure proxies can remain in the path of allrequestsinasession? > > Think about below situation: > > Client - Relay Agent - Proxy Agent1 - Server > > - Proxy Agent2 > > client directly connection to realy agent.realy agent connection > > two proxy agent(Prxoy agent1 and Proxy agent2),both proxy agent > > can route to server. > > > > Non -First Message is base on Destion-Host,only can assure Go to > > the same server,but cannot assure route to same prxoy agent(maybe > > all agent).when client send message ,in peer table cannot find > > server,then will use Destion Realm,if have two peer entry in the > > route entry,it can select any one.maybe we can think about client > > record his first message of a session.then he use same Next Hop. > > but if have relay agent,how to do,we cannot requirment,realy > > agent record any information about session. so the message it can > > select proxy agent1 or proxy agent2. assume first session message > > route by proxy agent1. non first session message route by prxoy > > agent2,then proxy agent1 maintain session state will bring problem. > [TOLGA}Yes, you are right, but by keeping next-hop per session info, you can > guarantee the delivery to the same Proxy Agent. Now, you can argue, whether > such a node should be called Relay Agent or something else but I believe > naming won't cause interoprability problems. [Zhangtao]It require each Diameter node maintain session state. this means routing should base on session ID. every session message should routing same path hop by hop. > Alternatively -mentioned by Vishnu already- you can actually proxy the > service you are providing, where Proxy1/Proxy2 populate Origin-Host AVP with > their thir identities for the answer of the first request in the session. > This would require Proxy1/Proxy2 to keep states and modify the content of > the messages but if they are built for that purpose, there probably wouldn't > be a problem. [zhangtao]Please See me former mail. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Apr 14 08:20:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUNI3-0001LV-K9; Fri, 14 Apr 2006 08:20:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUNI2-0001LN-Fq for dime@ietf.org; Fri, 14 Apr 2006 08:20:42 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUNHz-0007yd-5R for dime@ietf.org; Fri, 14 Apr 2006 08:20:40 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 01434C585A for ; Fri, 14 Apr 2006 08:20:34 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k3ECKXFZ019231 for ; Fri, 14 Apr 2006 08:20:34 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] assure proxies can remain in the path of allrequestsinasession? Date: Fri, 14 Apr 2006 07:58:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <001901c65fa1$bc9c96b0$3791460a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Zhangtao, > > > > Think about below situation: > > > Client - Relay Agent - Proxy Agent1 - Server > > > - Proxy Agent2 > > > client directly connection to realy agent.realy agent connection > > > two proxy agent(Prxoy agent1 and Proxy agent2),both proxy agent > > > can route to server. > > > > > > Non -First Message is base on Destion-Host,only can assure Go to > > > the same server,but cannot assure route to same prxoy agent(maybe > > > all agent).when client send message ,in peer table cannot find > > > server,then will use Destion Realm,if have two peer entry in the > > > route entry,it can select any one.maybe we can think about client > > > record his first message of a session.then he use same Next Hop. > > > but if have relay agent,how to do,we cannot requirment,realy > > > agent record any information about session. so the message it can > > > select proxy agent1 or proxy agent2. assume first session message > > > route by proxy agent1. non first session message route by prxoy > > > agent2,then proxy agent1 maintain session state will bring problem. > > [TOLGA}Yes, you are right, but by keeping next-hop per session > info, you can > > guarantee the delivery to the same Proxy Agent. Now, you can > argue, whether > > such a node should be called Relay Agent or something else but I believe > > naming won't cause interoprability problems. > > [Zhangtao]It require each Diameter node maintain session state. > this means routing should base on session ID. > every session message should routing same path hop by hop. [TOLGA]Yes, but you anyhow will keep some per-session state in those nodes for certain application specific processing -otherwise you wouldn't require to visit them for each request of the same session-, so I don't think this is a showstopper. As said before, whether the functionality of such a node overlaps exactly with Relay Agent functionality defined in RFC3588 is a different issue but not an interesting one from interoperability point of view. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Apr 17 02:32:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVNHP-0004w0-Ns; Mon, 17 Apr 2006 02:32:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVNHO-0004vv-T7 for dime@ietf.org; Mon, 17 Apr 2006 02:32:10 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVNHN-0003gw-2D for dime@ietf.org; Mon, 17 Apr 2006 02:32:10 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXU005CQTFFRV@szxga02-in.huawei.com> for dime@ietf.org; Mon, 17 Apr 2006 14:45:16 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXU00EDTTFF5S@szxga02-in.huawei.com> for dime@ietf.org; Mon, 17 Apr 2006 14:45:15 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXU00005TLCMG@szxml01-in.huawei.com>; Mon, 17 Apr 2006 14:48:48 +0800 (CST) Date: Mon, 17 Apr 2006 14:31:09 +0800 From: zhangtao Subject: Re: [Dime] assure proxies can remain in the path ofallrequestsinasession? To: Tolga Asveren , dime@ietf.org Message-id: <001201c661e8$83bd0e30$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga: I agree with you.if each node maintain session state,can solution the problem. But some node should stateless.just message routing,not care about message content(he donnot which command start session or end session).if this node maintian the session state,then should support every Diameter application.so it is bring interoperability problem,if one node upgrade,maybe should every node upgrade. Assume below situation: When First Message routing to Home network,The first Access node maybe should qurey HSS,then routing the message to one server.the none-first message no need routing to the Access node again,can directly routing to server.if realize use aforementioned solution,the first access node should maintain session state , all message should routing to him,then routing to server, maybe not so good. Actual in Diameter base protocol only few comments about Diameter Proxy agent. when i read 3GPP application like:GBA,I-WLAN.not clear how to realize it when routing. Regard! ----- Original Message ----- From: "Tolga Asveren" To: Sent: Friday, April 14, 2006 7:58 PM Subject: RE: [Dime] assure proxies can remain in the path ofallrequestsinasession? > Zhangtao, > > > > > > > Think about below situation: > > > > Client - Relay Agent - Proxy Agent1 - Server > > > > - Proxy Agent2 > > > > client directly connection to realy agent.realy agent connection > > > > two proxy agent(Prxoy agent1 and Proxy agent2),both proxy agent > > > > can route to server. > > > > > > > > Non -First Message is base on Destion-Host,only can assure Go to > > > > the same server,but cannot assure route to same prxoy agent(maybe > > > > all agent).when client send message ,in peer table cannot find > > > > server,then will use Destion Realm,if have two peer entry in the > > > > route entry,it can select any one.maybe we can think about client > > > > record his first message of a session.then he use same Next Hop. > > > > but if have relay agent,how to do,we cannot requirment,realy > > > > agent record any information about session. so the message it can > > > > select proxy agent1 or proxy agent2. assume first session message > > > > route by proxy agent1. non first session message route by prxoy > > > > agent2,then proxy agent1 maintain session state will bring problem. > > > [TOLGA}Yes, you are right, but by keeping next-hop per session > > info, you can > > > guarantee the delivery to the same Proxy Agent. Now, you can > > argue, whether > > > such a node should be called Relay Agent or something else but I believe > > > naming won't cause interoprability problems. > > > > [Zhangtao]It require each Diameter node maintain session state. > > this means routing should base on session ID. > > every session message should routing same path hop by hop. > [TOLGA]Yes, but you anyhow will keep some per-session state in those nodes > for certain application specific processing -otherwise you wouldn't require > to visit them for each request of the same session-, so I don't think this > is a showstopper. As said before, whether the functionality of such a node > overlaps exactly with Relay Agent functionality defined in RFC3588 is a > different issue but not an interesting one from interoperability point of > view. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Apr 18 07:48:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVohI-0008Cc-V0; Tue, 18 Apr 2006 07:48:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVohH-0008CX-RB for dime@ietf.org; Tue, 18 Apr 2006 07:48:43 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVohH-0001Fp-BF for dime@ietf.org; Tue, 18 Apr 2006 07:48:43 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3IBk79N001168 for ; Tue, 18 Apr 2006 14:46:08 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 14:48:18 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 14:48:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Apr 2006 14:48:17 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB407510@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DiME minutes Thread-Index: AcZMWxB325D+G90ZTA61DuQZfz3VZQAsK+IwABSN7aAFX+8HsA== From: To: X-OriginalArrivalTime: 18 Apr 2006 11:48:19.0068 (UTC) FILETIME=[FC87A3C0:01C662DD] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Subject: [Dime] DiME minutes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, Here are the minutes from the last IETF. Send comments, I will shortly send some topics for=20 mailing list approval. John IETF-65, DiME WG, 3/21 minutes: Greg, Jabber: Hannes http://www3.ietf.org/proceedings/06mar/agenda/dime.txt overview of milestones=20 Ideally we want 3588 to go to Draft Standard Bert: MIB probably not required We can't change functionality, if going for DS We're not wed to DS, can also recycle as Proposed Std 4/24-28 DiME interop event in NJ hosted by Ulticom NDA vs. gentleman's agreement discussed final report is vendor blind anyway, e.g. Vendor A, B, C concern: also need to include some security testing =20 desired apps: Base DCCA SIP Cx/Sh/Rf(Ro) EAP NASREQ MIP -- Interop Test plans - Victor Fajardo - 10 mintues=20 http://tools.ietf.org/wg/dime/draft-fajardo-dime-interop-test-suite-00.t xt Doc provides test cases and topologies for apps people interested in. Attempted to cover most common functions. =20 Some things left up to the testers, e.g. particular EAP methods for EAP app. Only one review by non-authors. =20 Chair: everyone attending should read the doc. -- Discussion of IPFilterRule and RadExt efforts - Mauricio Sanchez - 10 minutes=20 http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-00.tx t RADEXT has taken Diameter IPFilterRule and extended it. Q: How does IPFilterRule apply to IPsec protected topic?=20 A: This would need to be separate work. RADEXT attr called NAS-Traffic-Rule Today, RADEXT draft does not have a Diameter compatibility section. Current proposal is to converge the RAD/Diam dialects. Some RADEXT people felt that the RADEXT charter precludes adding functionality that are not in Diameter. 3GPP may be requesting IPFilter in RADEXT support from IETF. One potential solution: IPFilterRule removed from NASREQ, Diameter inherits the new attr from RADEXT, then the extra function added to Diameter. -- Diameter MIPv6 - Hannes Tschoffening - 10 minutes=20 http://tools.ietf.org/wg/dime/draft-tschofenig-dime-mip6-integrated-00.t xt http://tools.ietf.org/wg/dime/draft-tschofenig-dime-mip6-split-01.txt Background: MIPv6 working on AAA goals draft (ietf-mip6-aaa-ha-goals-01.txt). 'integrated' & 'split' scenario for bootstrapping. Split scenario: EAP in IKEv2 between MN & HA Diam between AAA-MSA & HA Integrated solution more complicated: Diam between DHCP relay & AAAV, and between AAAV & AAAH Scenario drafts: draft-tschofenig-dime-mip6-integrated/split-00/1.txt Open issues: new attributes vs. new application EU funded project (Enable): possibly could fund a prototype. MIPv6 WG not done: Chair: anyone interested? Handraise: about nine people interested in the work. -- Diameter QoS - Hannes Tschoffening - 10 minutes=20 http://tools.ietf.org/wg/dime/draft-tschofenig-dime-diameter-qos-00.txt http://tools.ietf.org/wg/radext/draft-tschofenig-radext-qos-02.txt Work started in NSIS (requirements work more than a couple yrs back). Separates the QoS reservation transport (RSVP/NSIS/etc) from the AAA authorization protocol (Diam/RAD/etc). TISPAN/3gpp/2 haven't finalized requirements yet; this may be useful. Handraise: dozen people interested in QoS authorization via diameter. -- Diameter API - TBD - 10 minutes http://tools.ietf.org/wg/dime/draft-ietf-dime-diameter-api-00.txt Have been some questions about why this is a charter item. Chair: we inherited this from AAA WG. API design is callback based. C++ IETF APIs are Informational. Take to list: some previous commenters not present. Glen: we're not ready for WGLC yet. -- Diameter-RADIUS interworking - TBD - 10 minutes http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-01 .txt Goal: provide bi-directional communication via translation. VSA translation not currently described in 4005. Need to get RADEXT buy-in for two-way. suggestion: why not encapulate all of diameter? Q: anyone trying to translate?=20 A: a couple hands. =20 Q: anyone translating VSAs? =20 A: radio silence It may not be a problem to open NASREQ & changes Kicked-out by next WG (5 mins over) -- RFC3588 updating discussion - all - remaining time. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Apr 18 11:54:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVsWg-0000Jj-Mb; Tue, 18 Apr 2006 11:54:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVsWg-0000Je-GV for dime@ietf.org; Tue, 18 Apr 2006 11:54:02 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVsWf-0006N8-2x for dime@ietf.org; Tue, 18 Apr 2006 11:54:02 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3IFqPN2001008 for ; Tue, 18 Apr 2006 18:52:25 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 18:53:55 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 18:53:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Apr 2006 18:53:56 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB40751A@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG consensus on: Diameter Quality of Service Application Thread-Index: AcZjAE2TJAfgn0KWS9aH3HJQ13Qd3Q== From: To: X-OriginalArrivalTime: 18 Apr 2006 15:53:55.0974 (UTC) FILETIME=[4C690A60:01C66300] X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Dime] WG consensus on: Diameter Quality of Service Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org At IETF 65, there was strong consensus (and interest) in working on the Diameter Quality of Service=20 Application, based upon this draft. http://tools.ietf.org/wg/dime/draft-tschofenig-dime-diameter-qos-00.txt This is a consensus call on the mailing list. Please comment on this draft, and based upon list discussions, Hannes and I will make a determination if this draft can be added as a working group document. As Hannes is co-chairing the working group, we'll consult with the other draft authors about finding someone to replace Hannes as the main editor. thanks, John & Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Apr 18 14:13:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVui2-0005uf-Ji; Tue, 18 Apr 2006 14:13:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVui1-0005uW-9M for dime@ietf.org; Tue, 18 Apr 2006 14:13:53 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVuhz-0006em-RI for dime@ietf.org; Tue, 18 Apr 2006 14:13:53 -0400 Received: (qmail invoked by alias); 18 Apr 2006 18:13:50 -0000 Received: from p549879CF.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.121.207] by mail.gmx.net (mp002) with SMTP; 18 Apr 2006 20:13:50 +0200 X-Authenticated: #29516787 Message-ID: <44452C5E.5010802@gmx.net> Date: Tue, 18 Apr 2006 20:13:50 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [Dime] WG consensus on: Diameter Quality of Service Application References: <615BD9B54CB01B41838C323DB9E91AAB40751A@esebe100.NOE.Nokia.com> In-Reply-To: <615BD9B54CB01B41838C323DB9E91AAB40751A@esebe100.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi John, Hi all, please note that we plan to go through the individual design decisions during the next few weeks. For example, we will discuss whether it is better to build the Diameter QoS application on top of NASEQ or DCC, which QoS parameter need to be exchanged, what scenarios we plan to support, etc. Thereby we can ensure that (a) we meet the groups expectation and (b) the design is sound. I also plan to discuss what other organizations did in the Diameter QoS context. It would be good to learn something from their work. Ciao Hannes john.loughney@nokia.com wrote: > At IETF 65, there was strong consensus (and interest) in working on the > Diameter Quality of Service > Application, based upon this draft. > http://tools.ietf.org/wg/dime/draft-tschofenig-dime-diameter-qos-00.txt > > This is a consensus call on the mailing list. Please comment on this > draft, and based upon list > discussions, Hannes and I will make a determination if this draft can be > added as a working group > document. As Hannes is co-chairing the working group, we'll consult > with the other draft > authors about finding someone to replace Hannes as the main editor. > > thanks, > John & Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Apr 18 15:42:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVw5M-00031m-3p; Tue, 18 Apr 2006 15:42:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVw5K-0002xP-Ln for dime@ietf.org; Tue, 18 Apr 2006 15:42:02 -0400 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVw5J-0002R9-BG for dime@ietf.org; Tue, 18 Apr 2006 15:42:02 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 18 Apr 2006 12:42:00 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3IJg0w1016073; Tue, 18 Apr 2006 12:42:00 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Apr 2006 12:42:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] WG consensus on: Diameter Quality of Service Application Date: Tue, 18 Apr 2006 12:41:59 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501E06AA8@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WG consensus on: Diameter Quality of Service Application Thread-Index: AcZjAE2TJAfgn0KWS9aH3HJQ13Qd3QAH4d0w From: "Glen Zorn \(gwz\)" To: X-OriginalArrivalTime: 18 Apr 2006 19:42:00.0642 (UTC) FILETIME=[291BAA20:01C66320] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org john.loughney@nokia.com supposedly = scribbled: > At IETF 65, there was strong consensus (and interest) in working on > the Diameter Quality of Service Application, based upon this draft.=20 > = http://tools.ietf.org/wg/dime/draft-tschofenig-dime-diameter-qos-00.txt >=20 > This is a consensus call on the mailing list. Please comment on this > draft, and based upon list discussions, Hannes and I will make a > determination if this draft can be added as a working group document. IIRC, the consensus was to work on the problem, not on this draft. If = you want to use this draft as a starting point, that's fine w/me. > As Hannes is co-chairing the working group, we'll consult with the > other draft authors about finding someone to replace Hannes as the > main editor. =20 >=20 > thanks, > John & Hannes >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Apr 18 16:06:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVwSj-0001HQ-Kn; Tue, 18 Apr 2006 16:06:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVwSh-0001HL-Ky for dime@ietf.org; Tue, 18 Apr 2006 16:06:11 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVwSh-0003VG-8E for dime@ietf.org; Tue, 18 Apr 2006 16:06:11 -0400 Received: (qmail invoked by alias); 18 Apr 2006 20:06:09 -0000 Received: from p549879CF.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.121.207] by mail.gmx.net (mp035) with SMTP; 18 Apr 2006 22:06:09 +0200 X-Authenticated: #29516787 Message-ID: <444546B1.1080905@gmx.net> Date: Tue, 18 Apr 2006 22:06:09 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Glen Zorn (gwz)" Subject: Re: [Dime] WG consensus on: Diameter Quality of Service Application References: <4C0FAAC489C8B74F96BEAD85EAEB262501E06AA8@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262501E06AA8@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Glen, ~snip~ > IIRC, the consensus was to work on the problem, not on this draft. If you want to use this draft as a starting point, that's fine w/me. Yes, that was the reason for me to send a separate mail to indicate the fact that we should speak about the design decisions. Obviously a few design decisions were made with regard to the work on draft-alfano-nsis-diameter-qos/draft-tschofenig-dime-diameter-qos and we discussed them in the NSIS working group. However, a number of folks in the DIME WG might not like some of these decisions. There are certainly a number of interesting discussions ahead of us. When we think about the work done in the 3GPP, 3GPP2 and TISPAN about this suspect then things will get really interesting. I think we have three high-level goals: a) Support for QoS signaling protocols and QoS models developed within the IETF b) Use Diameter as developed in the AAA WG c) Keep the solution simple Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 20 09:20:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWZ5H-0006E9-UA; Thu, 20 Apr 2006 09:20:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWZ5B-00068j-6U for dime@ietf.org; Thu, 20 Apr 2006 09:20:29 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWZ5A-0007PY-Nd for dime@ietf.org; Thu, 20 Apr 2006 09:20:29 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3KDIg2K025121 for ; Thu, 20 Apr 2006 16:18:45 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 16:20:17 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 16:20:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Apr 2006 16:20:17 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB40758F@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: pre-version -12: Diameter SIP application Thread-Index: AcZkfQrv7d2JTk5mQeWJilyJMkN2ZwAABT+Q From: To: X-OriginalArrivalTime: 20 Apr 2006 13:20:17.0766 (UTC) FILETIME=[2AC1A060:01C6647D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Miguel.An.Garcia@nokia.com Subject: [Dime] FW: [AAA-WG]: pre-version -12: Diameter SIP application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org FYI. John >Here we go again. I have been updating the Diameter SIP=20 >application with the latest comments from the IESG, including=20 >the removal of the nonce generation in the Diameter client. > >Before submitting this to the I-D Administrator, I would like=20 >people to take a look at the changes, and feel that we are=20 >happy with them. I will do one more pass to verify that I have=20 >addressed all the IESG comments. > >The preliminary version of the draft: > >http://people.nokia.net/~miguel/drafts/pre/pre-draft-ietf-aaa-d >iameter-sip-app-12.txt >http://people.nokia.net/~miguel/drafts/pre/pre-draft-ietf-aaa-d >iameter-sip-app-12.html > >Track changes with respect version -11: >http://people.nokia.net/~miguel/drafts/pre/draft-ietf-aaa-diame >ter-sip-app-11-to-12.html > >And the list of changes: >- Addressing an IESG comment: >https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview >_comment&id=3D46495 > >- The term SIP server is well defined in RFC 3261 as a network > entity (proxy, redirect, registrar, etc.) Although this is clear to > the editor, a bit of strength has been added to the introduction > section to stress that point. > >- Added some discusion about the intention of the > SIP-Server-Capabilities AVP and its relation to RFC 3263. > >- Removed the generation of nonces in the Diameter client. This turned > out to remove sections and quite a few paragraphs. Also, some > Grouped AVPs (SIP-Authenticate, SIP-Authorization, and > SIP-Authentication-Info) have change: some of the inner AVPs now are > again mandatory (used to be optional due to the possibility of > nonces generated in the Diameter client). > >- Added a clarification on the usage of quotes and expanded characters > inside HTTP Directives. > >Please, comment if you are happy or not, but comment. > >BR, > > Miguel > >--=20 >Miguel A. Garcia tel:+358-50-4804586 >sip:miguel.an.garcia@openlaboratory.net >Nokia Research Center Helsinki, Finland > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 26 18:35:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsbO-0003EH-Jf; Wed, 26 Apr 2006 18:35:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsbN-0003Dz-4s for dime@ietf.org; Wed, 26 Apr 2006 18:35:17 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYsbL-0003lp-Rj for dime@ietf.org; Wed, 26 Apr 2006 18:35:17 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 26 Apr 2006 15:35:15 -0700 X-IronPort-AV: i="4.04,159,1144047600"; d="scan'208"; a="1799005171:sNHT39828560" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k3QMZDYu023561 for ; Wed, 26 Apr 2006 15:35:15 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Apr 2006 15:35:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Apr 2006 15:34:35 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262551CCF6@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problems w/definition of Origin-Realm & Destination-Realm AVPs Thread-Index: AcZpgZh5HhZHhncFSu+sY1uwCiKQhQ== From: "Glen Zorn \(gwz\)" To: X-OriginalArrivalTime: 26 Apr 2006 22:35:14.0918 (UTC) FILETIME=[AFE25060:01C66981] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "Glen Zorn \(gwz\)" Subject: [Dime] Problems w/definition of Origin-Realm & Destination-Realm AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org RFC 3588 states that both the Destination-Realm & Origin-Realm AVPs are "of type DiameterIdentity" (sections 6.6 & 6.4). However, DiameterIdentity is defined in section 4.3 as "DiameterIdentity =3D = FQDN"; further, the same section says the 'the contents of the string [portion of the AVP] MUST be the FQDN of the Diameter node'. Virtually all of the examples in the RFC contradict this definition, showing the contents of the string as the FQDN minus everything to the left of the first '.', and the '.' itself. AFAIK, this is not an FQDN. I think that this really needs to be fixed, possibly by introducing a new derived string type (DiameterRealm?), possibly based upon the ABNF for the NAI realm (RFC 2486). OTOH, IIRC the reason why there are separate AVPs for Origin-Host and Origin-Realm was to decouple the DNS domain and Diameter realm, so that the realm can be different from the domain, so we may wish to define a less restrictive format. ~gwz _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 27 05:10:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ2WU-0008PQ-0e; Thu, 27 Apr 2006 05:10:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ2WT-0008PL-9H for dime@ietf.org; Thu, 27 Apr 2006 05:10:53 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ2WR-0006Ri-RH for dime@ietf.org; Thu, 27 Apr 2006 05:10:53 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3R98r7s018893 for ; Thu, 27 Apr 2006 12:08:54 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 12:10:48 +0300 Received: from esebe107.NOE.Nokia.com ([172.21.143.89]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 12:10:47 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Problems w/definition of Origin-Realm & Destination-RealmAVPs Date: Thu, 27 Apr 2006 12:10:46 +0300 Message-ID: <165947868C470B4889510CCB51416F6DC32DD5@esebe107.NOE.Nokia.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262551CCF6@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Problems w/definition of Origin-Realm & Destination-RealmAVPs Thread-Index: AcZpgZh5HhZHhncFSu+sY1uwCiKQhQAVxwJw From: To: X-OriginalArrivalTime: 27 Apr 2006 09:10:47.0974 (UTC) FILETIME=[78F4E460:01C669DA] X-Spam-Score: 1.3 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, > I think that this really needs to be fixed I agree. In draft-ietf-aaa-diameter-12.txt the type of Origin-Realm and Destination-Realm was UTF8String. I think that was correct. Then in draft-ietf-aaa-diameter-13.txt it was still UTF8String in the AVP-table, but in the text the type was changed to DiameterIdentity. I'm not really sure why this change was made, but the conflict seems to be there also in draft-ietf-aaa-diameter-17.txt. Unfortunately for the final RFC version the type in the AVP-table was updated to DiameterIdentity instead of updating the type in the text to UTF8String. BR, Mikko Aittola > -----Original Message----- > From: ext Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 > Sent: 27 April, 2006 01:35 > To: dime@ietf.org > Cc: Glen Zorn (gwz) > Subject: [Dime] Problems w/definition of Origin-Realm &=20 > Destination-RealmAVPs >=20 > RFC 3588 states that both the Destination-Realm &=20 > Origin-Realm AVPs are > "of type DiameterIdentity" (sections 6.6 & 6.4). However, > DiameterIdentity is defined in section 4.3 as=20 > "DiameterIdentity =3D FQDN"; > further, the same section says the 'the contents of the=20 > string [portion > of the AVP] MUST be the FQDN of the Diameter node'. Virtually all of > the examples in the RFC contradict this definition, showing=20 > the contents > of the string as the FQDN minus everything to the left of the=20 > first '.', > and the '.' itself. AFAIK, this is not an FQDN. I think that this > really needs to be fixed, possibly by introducing a new derived string > type (DiameterRealm?), possibly based upon the ABNF for the NAI realm > (RFC 2486). OTOH, IIRC the reason why there are separate AVPs for > Origin-Host and Origin-Realm was to decouple the DNS domain=20 > and Diameter > realm, so that the realm can be different from the domain, so we may > wish to define a less restrictive format. >=20 > ~gwz _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime