From mext-bounces@ietf.org Mon Jan 5 12:59:23 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9933A6A25; Mon, 5 Jan 2009 12:59:23 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0E33A6A25 for ; Mon, 5 Jan 2009 12:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.282 X-Spam-Level: X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRhuOxgBxQ8K for ; Mon, 5 Jan 2009 12:59:21 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 239153A6A22 for ; Mon, 5 Jan 2009 12:59:18 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n05KwxZZ026523; Mon, 5 Jan 2009 14:59:01 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 14:58:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jan 2009 15:58:56 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Missing fields in BCE and BULE - DSMIPv6-07 Thread-Index: AclhTfzKP7yghB2oSfa4cZ2d39mpbgOKhK5g From: "Desire Oulai" To: "Hesham Soliman" X-OriginalArrivalTime: 05 Jan 2009 20:58:59.0361 (UTC) FILETIME=[6E460110:01C96F78] Cc: mext@ietf.org Subject: [MEXT] Missing fields in BCE and BULE - DSMIPv6-07 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1568055343==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1568055343== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C96F78.6CEFAE2E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C96F78.6CEFAE2E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Hi Hesham, >=20 > In DSMIPv6, flags in BU/BA messages and NAT detection option have > been defined to require UDP encapsulation. Also a T flag for TLV is > defined. As UDP encapsulation and TLV usage may differ from a MN to > another, we need some new fields in the BCEs and BULEs. The missing > fields are:=20 > - A 1 bit UDP field to indicate that UDP encapsulation is required > - A UDP port number > - A TLV type field (when it is all zero, no TLV required) >=20 > BR >=20 > Desire ------_=_NextPart_001_01C96F78.6CEFAE2E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Missing fields in BCE and BULE - DSMIPv6-07

    Hi = Hesham,

      In DSMIPv6, = flags in BU/BA messages and NAT detection option have been defined to = require UDP encapsulation. Also a T flag for TLV is defined. As UDP = encapsulation and TLV usage may differ from a MN to another, we need = some new fields in the BCEs and BULEs. The missing fields are: =

    - A 1 bit UDP = field to indicate that UDP encapsulation is required
    - A UDP port = number
    - A TLV type = field (when it is all zero, no TLV required)

    BR

    Desire

------_=_NextPart_001_01C96F78.6CEFAE2E-- --===============1568055343== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1568055343==-- From mext-bounces@ietf.org Mon Jan 5 13:00:50 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC923A6A99; Mon, 5 Jan 2009 13:00:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5038F28C104 for ; Mon, 5 Jan 2009 13:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXMZSepnjZtJ for ; Mon, 5 Jan 2009 13:00:47 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 6A3D928C0F3 for ; Mon, 5 Jan 2009 13:00:47 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n05L5BjP003024; Mon, 5 Jan 2009 15:05:11 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 15:00:30 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jan 2009 16:00:22 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments on DSMIPv6-07 Thread-Index: AclveJ+Tc6sBkxv1SymCNIQsZgOhMw== From: "Desire Oulai" To: "Hesham Soliman" X-OriginalArrivalTime: 05 Jan 2009 21:00:30.0125 (UTC) FILETIME=[A45F7DD0:01C96F78] Cc: mext@ietf.org Subject: [MEXT] Some comments on DSMIPv6-07 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0160948499==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0160948499== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C96F78.9FB3DB0D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C96F78.9FB3DB0D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hesham, In the text, it is said in section 5.1: " The following value is assigned to the Type field, other values may be assigned in the future: 1 GRE [RFC2784] " In the text before, it is said that you can use just 0 and 1 for the type field. Does this mean we can just add one more value? Why not set the GRE value to 0 rather than 1?=20 Also, still in section 5.1 : " 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: TLV-header format Type This field indicates the type of the payload following this header. Length This field indicates the length of the payload following the header, excluding the TLV-header itself. The use of this flag is described in Section 5 " the sentence "The use of this flag is described in Section 5" should be removed as the length field is not a flag. BR Desire ------_=_NextPart_001_01C96F78.9FB3DB0D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some comments on DSMIPv6-07

    Hi = Hesham,

    In the text, it is = said in section 5.1:
    " The = following value is assigned to the Type field, other values = may
       be = assigned in the future:

          1 GRE = [RFC2784]
     "
    In the text = before, it is said  that you can use just 0 and 1 for the type = field. Does this mean we can just add one more value? Why not set the = GRE value to 0 rather than 1?

    Also, still in = section 5.1 :

    "
        = 0            =        = 1            =        = 2            =        3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1
       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /SPAN>
       | = Type  |    = Length           &= nbsp;         = |        = Reserved       |
       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /SPAN>


             &nbs= p;            = ;  Figure 7: TLV-header format

       = Type

          This field indicates the = type of the payload following this
          header.

       = Length

          This field indicates the = length of the payload following the
          header, excluding the = TLV-header itself.  The use of this flag is
          described in Section = 5

    "
      the = sentence "The use of this flag is described in Section 5" = should be removed as the length field is not a flag.

    BR

    Desire

------_=_NextPart_001_01C96F78.9FB3DB0D-- --===============0160948499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0160948499==-- From mext-bounces@ietf.org Tue Jan 6 07:24:33 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794CC3A68A1; Tue, 6 Jan 2009 07:24:33 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2057E3A68A1 for ; Tue, 6 Jan 2009 07:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.295 X-Spam-Level: X-Spam-Status: No, score=-6.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdHOmBkrp74x for ; Tue, 6 Jan 2009 07:24:30 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 6F5663A687D for ; Tue, 6 Jan 2009 07:24:30 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n06FNx021771; Tue, 6 Jan 2009 15:23:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jan 2009 09:23:24 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-mext-binding-revocation-02 Thread-Index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQArrD7gALKdDZAEWRBysA== References: From: "Ahmad Muhanna" To: "Stupar, Patrick" Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Patrick, It seems that I never responded to your responses. Please see responses inline. Regards, Ahmad > > > > > -----Original Message----- > > > From: Stupar, Patrick [mailto:pstupar@qualcomm.com] > > > Sent: Wednesday, December 10, 2008 7:19 PM > > > To: Muhanna, Ahmad (RICH1:2H10) > > > Cc: mext@ietf.org > > > Subject: Comments on draft-ietf-mext-binding-revocation-02 > > > > > > Hi Ahmad, > > > > > > I have reviewed binding revocation draft and have the following > > > comments/questions. > > > > > > - In MIPv6, Binding Update and Binding Ack have two different MH > > > type values. Why isn't the same approach taken for BRI > and BRA and > > > only one value is used? > > > > [Ahmad] > > This was discussed on the mailing list for a long time and > agreed that > > using one MH type will help in preserving the MH type > space. I believe > > the "Heartbeat Mechanism for PMIPv6" is a wg doc in Netlmm > and use one > > MH type for the Request and Response. On the other hand, do see an > > issue or problem in having a single MH type for both messages? > > [Patrick] If the WG is worried about MH type space then I am > fine with the proposed message format. > > > > > > > > > - BRI has a revocation trigger field which is used for two main > > > usages. > > > One is the provisioning of the reason why the revocation was sent > > > (e.g. > > > inter-MAG handoff) and the other is related to specific binding > > > revocation procedures (e.g. IPV4 HoA Binding only, > Per-Peer Policy). > > > I think it would be cleaner if the two concepts remain > separated in > > > the messages, for instance defining additional flags for Per-peer > > > policy or > > > IPv4 HoA Binding only. > > > > [Ahmad] > > I see what you are saying. However, as you said, the Revocation > Trigger > > field is defined to give the reason which caused the > revoking node to > > send the BRI message. Thus far, I believe all of the defined values > are > > inline with that definition or reasoning. For example: When the LMA > > sets the R. Trigger value to "IPv4 HoA Binding Only" it > means that the > > reason behind sending this BRI message is to revoke the IPv4 HoA > > address in the case that the MN is assigned two proxy > HoA(v4 & v6) for > > the same pCoA. > > I > > do not see this as a policy decision, because it is no > difference from > > the MAG sending a BRI with R. Trigger value is set to for example, > > "Access Network Session Termination" > > > > As for the R. Trigger value of "Per-Peer Policy", This is only > > restricted to Global Revocation when the (G) bit is set. I still > > believe that "Per-Peer policy" also indicate the reason > that allowed > > the LMA > to > > send this Global BRI. Do you have a different name for this > R. Trigger > > value that would fit better? > > > > [Patrick]IMHO "IPv4 HoA Binding Only" is not the reason that > triggered the BRI, it's the action that the MN is requested > to perform. Anyhow, my concerns were not related to the list > of reasons in the revocation trigger, but to the fact that > some values of the field imply some actions and other values > don't. My suggestion is that the actions are taken by MN and > HA based on flags (e.g. Global Revocation) and not on the > revocation trigger. Only the case of "IPv4 HoA Binding Only" > lacks of a proper flag. [Ahmad] After pondering on this, it seems to me that makes sense. Will introduce a flag for "IPv4 HoA Revocation Only" and update the draft accordingly. This will cause some text changes to capture all cases which relates to Client MIP6 and PMIPv6; will take care of it in the new revision, hopefully in the next week. > > > > > > > > - In the draft you refer to MAG identity, where is this term > > > defined? I wasn't able to find it in RFC 5213. > > > > [Ahmad] > > Actually, under section 4.1. "Peer Authorization Database (PAD) > Example > > Entries", you can find the MAG-ID is defined there as > mag_identity_1. > > It > > is the same concept here. However, I agree that we do not have a > > mobility option which is specific for carrying MAG-ID but > the draft is > > using the MN-ID in a very specific scenario. How the LMA would check > if > > this MAG is authorized for Global revocation is out of scope. > > > > [Patrick] what I meant here is that in section 2 of RFC5213 > there is the definition of MN identity and that I would > expect something similar for the MAG in BRI draft. For MN > identity, RFC5213 claims that MAC address or NAI can be used. > Are there similar guidelines for MAG identity? [Ahmad] I see what you are saying. I assumed that this is in the form of NAI. we can add some text to clarify that, would that address your concern or you have in mind a possible different format? > > > > > > > > > > > Some other comments related to specific sections: > > > > > > - page 21: in the first section after the bullet list, > there is the > > > following sentence: > > > "As described in Section 7.3, the LMA SHOULD retransmit > this BRI to > > > the MAG before deleting the mobile node IP tunnel to the mobile > > > access gateway until it receives a matching Binding Revocation > > > Acknowledgement or the BRIMaxRetransmitNumber is reached. " > > > But this doesn't always apply, e.g. in case of inter-mag > handoffs. > > > What am I missing? > > > > [Ahmad] > > Yes, I see what you are saying here. It seems that the text > needs some > > tweaking. > > Do you have any suggestion? > [Patrick] How about referring to the BCE? > Proposed text: > "As described in Section 7.3, the LMA SHOULD retransmit this > BRI to the MAG before deleting BCE until it receives a > matching Binding Revocation Acknowledgement or the > BRIMaxRetransmitNumber is reached. " > Though I am not sure this text is helpful as it is already > captured later in the draft. [Ahmad] When talking about deleting the BCE, it may conflict with the case of inter-MAG handoff. I believe leaving the term deleting the tunnel is more generic. In other words, LMA may delete the IP tunnel but NOT the BCE in some cases. However, in other cases which does not involve inter-MAG handoff, when deleting the IP tunnel, consequently, the BCE will be deleted. > > > > > > > > > > - why is the A bit setting mandatory in case of IPv4 HoA binding > > > only revocation? > > > > [Ahmad] > > May be if you tell me why not, we could change it? > > [Patrick] I have nothing against it. But that "MUST" implies > that a BRI with the "IPv4 HoA Binding Only" value in the > revocation trigger field and A bit not set is not properly > formatted. What does the MAG do in this case? [Ahmad] I believe that "MUST" is needed because revoking the IPv4 HoA address only does not mean deleting the BCE, In other words, the MAG should maintain the IPv6 HoA Binding and a PBA is needed to confirm to the LMA that the MAG will continue maintaining the IPv6 binding. However, the case you mentioned is an error scenario and we may have two ways to do it: 1. The MAG to ignore the BRI 2. The MAG MUST treat this as if the 'A' bit is set and MUST send a PBA. After introducing the "IPv4 HoA Revocation Only" flag, I believe the proper behavior is No. 2 above. > > > > > > > > > - section 10.1.1: > > > "BRI MUST be formatted as in Section 6.1 and if the (P) > bit is set, > > > the mobile access gateway must validate that the impacted > > > binding > > > have the proxy binding flag set." > > > MAG is not supposed to have any proxy binding flag or is it? > > > How can it validate this flag? > > > > [Ahmad] > > Good catch. There is another incident below it too. > > What about the following text for both bullets: > > " > > o BRI MUST be formatted as in Section 6.1 and the (P) > bit is set. > > > > o If the Global (G) bit is set and the Revocation > Trigger field is > > set to "Per-Peer policy", the mobile access gateway > identify all > > bindings that are registered at the LMA and hosted at the MAG. > > This Binding Revocation Indication does not include any other > > mobility options. In this case, the MAG MUST send a > BRA with the > > appropriate status code to the LMA. > > " > > > > [Patrick] fine with me, thanks > > > > > > > > > > -section 11.1 > > > " If the Acknowledgement (A) bit is set in the Binding Revocation > > > Indication and the MN has the BCE in registered state, the > > > mobile > > > node MUST send a Binding Revocation Acknowledgement." > > > > > > MN has no BCE, it has a binding update list. > > [Ahmad] > > Right. Thx. What about the following: > > > > o If the Acknowledgement (A) bit is set in the Binding > Revocation > > Indication and the MN has a Binding Update List entry for the > > source > > of the BRI message, the mobile node MUST send a Binding > > Revocation > > > > Acknowledgement. However, in all other cases when the > (A) bit is > > set > > in the BRI, the mobile node SHOULD send a Binding Revocation > > Acknowledgement. > > In all cases, the mobile node MUST follow Section > 11.2 when send > > a BRA using the appropriate status code. > > > [Patrick] I would perform the check based on the HoA and CoA > contained in the BRI. > Proposed text: > > o If the Acknowledgement (A) bit is set in the Binding Revocation > Indication and the MN has a Binding Update List entry > for the Care of address and the Home Address > Contained in the BRI message, the mobile node MUST send > a Binding Revocation > > Acknowledgement. However, in all other cases when the > (A) bit is set > in the BRI, the mobile node SHOULD send a Binding > Revocation Acknowledgement. > In all cases, the mobile node MUST follow Section 11.2 > when send > a BRA using the appropriate status code. > [Ahmad] Currently, neither the HoA nor the CoA is included in the BRI message. Are you suggesting that we add those options as valid ones in the BRI? > > > > > > > -section 11.1 > > > "If the Revocation Trigger field value is "Administrative Reason", > > > the mobile node MUST NOT try to re-register with the home > agent > > > before contacting its home operator." > > > > > > I don't think that BRI specs have to mandate the MN to > contact the > > > home operator, the text at the end of section > > > 11.1 is enough IMO. > > > > > [Ahmad] > > I see your point, It seems a very strong requirement and for a well > > behaved MN implementation, it may not be a problem to > remove the whole > > bullet. However, for a non-well behaved MN, it may be necessary to > keep > > something. What about if we demote MUST NOT to SHOULD NOT. > Would that > > work? > > > > > [Patrick] I was not worried about the "MUST" or "SHOULD", but > by the fact that IMO the action to be taken after receiving a > BRI with that value in the trigger field is implementation > dependant as already described later in the draft [Ahmad] Sure, we can remove this bullet. Thanks for all of your comments and sorry for the late reply. > > > NEW TEXT: > > o If the Revocation Trigger field value is "Administrative > Reason", > > the mobile node SHOULD NOT try to re-register with the home > agent > > before contacting its home operator. > > > > TEXT at end of 11.1 that Patrick is referring to: > > > > The Revocation Trigger field value in the received Binding > > Revocation > > Indication could be used by the mobile node to define > what action > > the > > mobile node could do to be able to register again and receive its > IP > > mobility service, e.g. contacting its home operator. > > > > > I have some typos and editorial corrections as well, I will send > > > them off-list. > > > > [Ahmad] > > Please send them. Thanks for your review and good comments! > > > > > > > > Regards, > > > > > > Patrick > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jan 6 07:37:57 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138D33A687D; Tue, 6 Jan 2009 07:37:57 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477D63A687D for ; Tue, 6 Jan 2009 07:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.318 X-Spam-Level: X-Spam-Status: No, score=-6.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAa9yAF0Bt8q for ; Tue, 6 Jan 2009 07:37:54 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 4863A3A6807 for ; Tue, 6 Jan 2009 07:37:54 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n06FbSg25804; Tue, 6 Jan 2009 15:37:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jan 2009 09:36:46 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Comments on draft-ietf-mext-binding-revocation-02 Thread-Index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQArrD7gALKdDZAEWRBysAACEXzA References: From: "Ahmad Muhanna" To: "Stupar, Patrick" Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Minor typo correction. Regards, Ahmad > > [Ahmad] > I believe that "MUST" is needed because revoking the IPv4 HoA > address only does not mean deleting the BCE, In other words, > the MAG should maintain the IPv6 HoA Binding and a PBA is > needed to confirm to the LMA that the MAG will continue > maintaining the IPv6 binding. However, the case you mentioned > is an error scenario and we may have two ways to do > it: > > 1. The MAG to ignore the BRI > 2. The MAG MUST treat this as if the 'A' bit is set and MUST > send a PBA. > [Ahmad] Couple of instances refer to PBA, I meant to say BRA. > After introducing the "IPv4 HoA Revocation Only" flag, I > believe the proper behavior is No. 2 above. > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jan 6 08:17:52 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D723A69DE; Tue, 6 Jan 2009 08:17:52 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CE403A6774 for ; Tue, 6 Jan 2009 08:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.355 X-Spam-Level: X-Spam-Status: No, score=-6.355 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlKOU9PSg-2U for ; Tue, 6 Jan 2009 08:17:49 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 731AE3A69DE for ; Tue, 6 Jan 2009 08:17:49 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n06GDpi16596; Tue, 6 Jan 2009 16:13:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jan 2009 10:17:26 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02 Thread-Index: Aclkz5T+MCiOMnGCSx+jtd7Ub+QMQwLSmFNwAAAJXIA= References: <00cc01c964cf$82134a80$150ca40a@china.huawei.com> From: "Ahmad Muhanna" To: "Yungui Wang" , "Arnaud Ebalard" Cc: mext@ietf.org Subject: Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0936664950==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0936664950== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9701A.44932C79" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9701A.44932C79 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable noticed that mext wg ml was never copied. Regards,=20 Ahmad=20 =20 ________________________________ From: Muhanna, Ahmad (RICH1:2H10)=20 Sent: Tuesday, January 06, 2009 10:17 AM To: 'Yungui Wang'; 'Arnaud Ebalard' Subject: RE: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02 =09 =09 Hi Yungui, It also seems that I never replied to your email.=20 This suggestion makes sense and we can incorporate that too. Regards,=20 Ahmad=20 =20 ________________________________ From: Yungui Wang [mailto:w52006@huawei.com]=20 Sent: Tuesday, December 23, 2008 1:25 AM To: Muhanna, Ahmad (RICH1:2H10); Arnaud Ebalard Subject: Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02 =09 =09 Hi Ahmad, =20 =09 Just a nit. Following common usage, maybe the failed status code can be defined over 127. =20 B.R. Yungui =20 ----- Original Message -----=20 From: Ahmad Muhanna To: Arnaud Ebalard =20 Cc: Julien Laganier ; IETF MEXT WG ML =20 Sent: Tuesday, December 23, 2008 9:56 AM Subject: Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02 Hi Arnaud, =09 > Subject: Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02 >=20 > Hi, >=20 > "Ahmad Muhanna" writes: >=20 >=20 > >> > administrative reason. This mechanism enables the=20 > home domain to > >> > dynamically allow the user to act upon the revocation=20 > message in > >> > order to not have an unexpectedly interrupted mobile > >> IPv6 services. > >>=20 > >> Well, when it receives the information, it's already too=20 > late, isn't=20 > >> it? > > > > [Ahmad] > > What is meant here, the MN will have an instant but graceful=20 > > indication that its mobility service is being revoked. At=20 > that time,=20 > > the MN will be able to make an out of scope communication to=20 > > check/enable/etc. the service with its provider, for example. This=20 > > case is meant to replace/"be compared" the case when the HA deletes=20 > > the binding and the tunnel without informing the MN. >=20 > What about that instead of the last sentence: >=20 > "This mechanism enables the home domain to dynamically allow=20 > the user to act upon the revocation message in order to=20 > recover its interrupted mobile IPv6 services." =09 [Ahmad] Ok. =09 >=20 >=20 > >> Last question on that paragraph: The last sentence start with > >> "If". Why? I mean, this is mandated by 3775. Is it for PMIPv6? > >>=20 > >> > 6. Binding Revocation Message > >> >=20 > >> > This section defines a Binding Revocation Message that > >> use a MH type > >> > with a Binding Revocation type field that > >> follow the MH > >> > format described in section 6.1. [RFC3775]. The value in the > >>=20 > >> ^^^^^^^^^^^^^^^^ > >> 6.1 of [RFC3775] or just 6.1? > >>=20 > > [Ahmad] > > Sure we can reference [RFC3775]. >=20 > it's not what I meant. I meant that "[RFC3775]" sits there in=20 > the middle of the sentence. Is it expected? =09 [Ahmad] I see what you meant. =09 What about the following: =09 This section defines the Binding Revocation Message format using a MH Type=20 as illustrated in Figure 4. The value in the Binding Revocation Type=20 field defines whether the Binding Revocation message is a BRI or BRA. If the=20 Binding Revocation type field is set to 1, the Binding Revocation Message is=20 a Binding Revocation Indication message as in Section 6.1. However, if the=20 value is 2, it is a Binding Revocation Acknowledgement message as in Section 6.2. =09 >=20 >=20 > >> > Figure 6: Binding Revocation Acknowledgement Message > >> >=20 > >> >=20 > >> > Status > >> >=20 > >> > 8-bit unsigned integer indicating the result of=20 > processing the > >> > Binding Revocation Indication message by the > >> receiving mobility > >> > entity. The following status values are currently defined. > >> >=20 > >> > 0 success. > >> > 1 partial success. > >> > 2 Binding Does NOT Exist. > >> > 3 IPv4 HoA Binding Does NOT Exist. > >> > 4 Global Revocation NOT Authorized. > >> > 5 CAN NOT Identify Binding. > >> > 6 Revocation Failed, MN is Attached. > >>=20 > >> The Binding Revocation Trigger values in Section 6.1 look more=20 > >> self-explanatory. They are also mainly informational, right? > > > > [Ahmad] > > Yes, it is mainly informational. However, whenever any R. Trigger=20 > > value means a specific action is needed on the side of the=20 > receiving=20 > > mobility node, IMO, it needs to be documented. If we missed any of=20 > > these, we can go back and do it. > > > >>=20 > >> Here, it is not clear what "partial success" (1) or "Revocation=20 > >> failed, MN is attached" mean, and what both entities should expect=20 > >> when those are sent. Maybe the rationale that were associated with=20 > >> those values when the list was first created should be included in=20 > >> the document, along with the expected behaviors (Are those status=20 > >> value just > >> informational?) > >> =20 > >> Or did I missed some other section that provides that in the draft? > > > > [Ahmad] > > I agree it is mainly informational but some of these status is=20 > > appropriate with certain scenarios. I believe those status values=20 > > meanings and use are mentioned when these specific scenario are=20 > > discussed later on. >=20 > I may have missed them but "partial success" and "Revocation=20 > failed, MN is attached" (at least) are not. =09 [Ahmad] Sure. We will make sure that all of these values are described and documented in the new revision. =09 In the meantime, in bthe case of "Partial success", it is the case when the MAG for example, receives a BRI that impact multiple bindings while some of them have been released already, for example. The MAG may set the status to success or partial success.=20 =09 In the case of "Revocation failed, MN is attached", in the case of inter-MAG HO, the LMA may send a BRI message with a Revocation Trigger value of "Inter-MAG HO". In this case, the MAG may need to ensure that the MN is no longer attached. If the MN is still attached, then the MAG could send a BRA with this status value. =09 For example, one of the bullets under section 10.1.1. says: =09 If the Revocation Trigger field value in the received Binding Revocation Indication message indicates an inter-MAG handover and the (A) bit is set, the MAG use the mobility option(s) included in the BRI message to identify the mobile node binding. The mobile access gateway MAY validate that the mobile node is no longer attached to the mobile access gateway before sending a successful Binding Revocation Acknowledgement message to the LMA. However, if the Revocation Trigger field is set to "Inter-MAG - Unknown Handoff", the MAG MUST validate that the mobile node is no longer attached to the MAG before sending a successful BRA message and deleting the resources associated with the mobile node binding.=20 =09 We could add some text to the above to read as follows: =09 =09 ..................................................... However, if the Revocation Trigger field is set to "Inter-MAG - Unknown Handoff" and the (A) bit is set, the MAG MUST validate that the=20 mobile node is no longer attached to the MAG before sending a=20 successful BRA message and deleting the resources associated=20 with the mobile node binding. Otherwise, if the MAG verified that=20 the MN is still attached, the MAG MUST set the status field in the =09 BRA to "Revocation failed - MN is attached" =09 Regards, Ahmad =09 >=20 > >> General comment: in the draft, the few times "Type 2 Header"=20 > >> is used, it should probably be replaced by "Type 2 Routing Header"=20 > >> for consistency. > > > > [Ahmad] > > Sure. >=20 > ack. thanks >=20 > Cheers, >=20 > a+ >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext =09 ------_=_NextPart_001_01C9701A.44932C79 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
noticed that mext wg ml was never=20 copied.

Regards, =
Ahmad

 

From: Muhanna, Ahmad (RICH1:2H10)=20
Sent: Tuesday, January 06, 2009 10:17 AM
To: = 'Yungui=20 Wang'; 'Arnaud Ebalard'
Subject: RE: [MEXT] Reviews of=20 draft-ietf-mext-binding-revocation-02

Hi=20 Yungui,
It=20 also seems that I never replied to your email.
This=20 suggestion makes sense and we can incorporate that = too.

Regards,
Ahmad

 

From: Yungui Wang = [mailto:w52006@huawei.com]=20
Sent: Tuesday, December 23, 2008 1:25 AM
To: = Muhanna,=20 Ahmad (RICH1:2H10); Arnaud Ebalard
Subject: Re: [MEXT] = Reviews of=20 draft-ietf-mext-binding-revocation-02

Hi Ahmad,
 
Just a nit. Following common = usage, maybe=20 the failed status code can be defined over = 127.
 
B.R.
Yungui
 
----- Original Message ----- =
From:=20 Ahmad=20 Muhanna
Cc: Julien = Laganier ; IETF MEXT WG = ML
Sent: Tuesday, December 23, = 2008 9:56=20 AM
Subject: Re: [MEXT] Reviews = of=20 draft-ietf-mext-binding-revocation-02

Hi Arnaud,

> Subject: Re: [MEXT] Reviews = of=20 draft-ietf-mext-binding-revocation-02
>
> Hi,
> =
> "Ahmad Muhanna" <amuhanna@nortel.com>=20 writes:
>
>
> >> >   =20 administrative reason.  This mechanism enables the
> = home=20 domain to
> >> >    dynamically = allow the=20 user to act upon the revocation
> message in
> = >>=20 >    order to not have an unexpectedly = interrupted=20 mobile
> >> IPv6 services.
> >>
> = >>=20 Well, when it receives the information, it's already too
> = late,=20 isn't
> >> it?
> >
> > = [Ahmad]
> >=20 What is meant here, the MN will have an instant but graceful =
> >=20 indication that its mobility service is being revoked. At
> = that=20 time,
> > the MN will be able to make an out of scope=20 communication to
> > check/enable/etc. the service with = its=20 provider, for example. This
> > case is meant to = replace/"be=20 compared" the case when the HA deletes
> > the binding = and the=20 tunnel without informing the MN.
>
> What about that = instead=20 of the last sentence:
>
> "This mechanism enables the = home=20 domain to dynamically allow
> the user to  act upon = the=20 revocation message in order to
> recover its = interrupted =20 mobile IPv6 services."

[Ahmad]
Ok.

>
> =
>=20 >>      Last question on that = paragraph:=20 The last sentence start with
>=20 >>      "If". Why? I mean, this is = mandated=20 by 3775. Is it for PMIPv6?
> >>
> >> > = 6.  Binding Revocation Message
> >> >
> = >> >    This section defines a Binding = Revocation=20 Message that
> >> use a MH type
> >>=20 >    <IANA-TBD> with a Binding Revocation = type=20 field that
> >> follow the MH
> >>=20 >    format described in section 6.1. =20 [RFC3775].  The value in the
> >>
>=20 = >>           = ;            =           =20 ^^^^^^^^^^^^^^^^
>=20 = >>           = ;            =    =20 6.1 of [RFC3775] or just 6.1?
> >>
> >=20 [Ahmad]
> > Sure we can reference [RFC3775].
> =
>=20 it's not what I meant. I meant that "[RFC3775]" sits there in =
> the=20 middle of the sentence. Is it expected?

[Ahmad]
I see = what you=20 meant.

What about the following:

   This = section=20 defines the Binding Revocation Message format using a MH
Type=20
   <IANA-TBD> as illustrated in Figure 4. The = value in=20 the Binding
Revocation Type
   field defines = whether the=20 Binding Revocation message is a BRI or BRA.
If the =
  =20 Binding Revocation type field is set to 1, the Binding=20 Revocation
Message is
   a Binding Revocation = Indication=20 message as in Section 6.1. However,
if the
   = value is 2,=20 it is a Binding Revocation Acknowledgement message as = in
Section=20 6.2.

>
>
> >>=20 = >           =20 Figure 6: Binding Revocation Acknowledgement Message
> = >> >=20
> >> >
> >> >   =20 Status
> >> >
> >>=20 >       8-bit unsigned integer = indicating=20 the result of
> processing the
> >>=20 >       Binding Revocation = Indication=20 message by the
> >> receiving mobility
> = >>=20 >       entity.  The = following=20 status values are currently defined.
> >> > =
>=20 >> = >          =20 0  success.
> >>=20 >           = 1 =20 partial success.
> >>=20 >           = 2 =20 Binding Does NOT Exist.
> >>=20 >           = 3 =20 IPv4 HoA Binding Does NOT Exist.
> >>=20 >           = 4 =20 Global Revocation NOT Authorized.
> >>=20 >           = 5 =20 CAN NOT Identify Binding.
> >>=20 >           = 6 =20 Revocation Failed, MN is Attached.
> >>
> = >> The=20 Binding Revocation Trigger values in Section 6.1 look more =
>=20 >> self-explanatory. They are also mainly informational,=20 right?
> >
> > [Ahmad]
> > Yes, it is = mainly=20 informational. However, whenever any R. Trigger
> > = value means=20 a specific action is needed on the side of the
> receiving =
>=20 > mobility node, IMO, it needs to be documented. If we missed = any of=20
> > these, we can go back and do it.
> = >
>=20 >>
> >> Here, it is not clear what "partial = success"=20 (1) or "Revocation
> >> failed, MN is attached" mean, = and=20 what both entities should expect
> >> when those are = sent.=20 Maybe the rationale that were associated with
> >> = those=20 values when the list was first created should be included in =
>=20 >> the document, along with the expected behaviors (Are = those status=20
> >> value just
> >> = informational?)
>=20 >> 
> >> Or did I missed some other = section that=20 provides that in the draft?
> >
> > = [Ahmad]
> >=20 I agree it is mainly informational but some of these status is =
>=20 > appropriate with certain scenarios. I believe those status = values=20
> > meanings and use are mentioned when these specific = scenario=20 are
> > discussed later on.
>
> I may have = missed=20 them but "partial success" and "Revocation
> failed, MN is=20 attached" (at least) are not.

[Ahmad]
Sure. We will make = sure=20 that all of these values are described and
documented in the = new=20 revision.

In the meantime, in bthe case of "Partial = success", it is=20 the case when
the MAG for example, receives a BRI that impact = multiple=20 bindings while
some of them have been released already, for = example.=20 The MAG may set
the status to success or partial success. =

In=20 the case of "Revocation failed, MN is attached", in the case=20 of
inter-MAG HO, the LMA may send a BRI message with a = Revocation=20 Trigger
value of "Inter-MAG HO". In this case, the MAG may need = to=20 ensure that
the MN is no longer attached. If the MN is still = attached,=20 then the MAG
could send a BRA with this status = value.

For=20 example, one of the bullets under section 10.1.1.=20 says:

      If the Revocation = Trigger=20 field value in the received = Binding
     =20 Revocation Indication message indicates an inter-MAG handover=20 and
      the (A) bit is set, the MAG = use the=20 mobility option(s) included in
      = the BRI=20 message to identify the mobile node binding.  The=20 mobile
      access gateway MAY = validate that=20 the mobile node is no longer
      = attached to=20 the mobile access gateway before sending a=20 successful
      Binding Revocation=20 Acknowledgement message to the LMA. =20 However,
      if the Revocation = Trigger field=20 is set to "Inter-MAG - Unknown
      = Handoff",=20 the MAG MUST validate that the mobile node is no=20 longer
      attached to the MAG = before=20 sending a successful BRA message = and
     =20 deleting the resources associated with the mobile node binding. =

We=20 could add some text to the above to read as=20 follows:

     =20 ..................................................... =20 However,
      if the Revocation = Trigger field=20 is set to "Inter-MAG - Unknown
      = Handoff"=20 and the (A) bit is set, the MAG MUST validate that the=20
      mobile node is no longer = attached to=20 the MAG before sending a
      = successful BRA=20 message and deleting the resources associated=20
      with the mobile node binding.=20 Otherwise, if the MAG verified that =
      the=20 MN is still attached, the MAG MUST set the status field in=20 the

      BRA to "Revocation = failed - MN=20 is attached"

Regards,
Ahmad

>
> = >>=20 General comment: in the draft, the few times "Type 2 Header" =
>=20 >> is used, it should probably be replaced by "Type 2 = Routing=20 Header"
> >> for consistency.
> >
> = >=20 [Ahmad]
> > Sure.
>
> ack. thanks
> =
>=20 Cheers,
>
> a+
>
>=20
_______________________________________________
MEXT = mailing=20 list
MEXT@ietf.org
https://www.ietf.org/= mailman/listinfo/mext
------_=_NextPart_001_01C9701A.44932C79-- --===============0936664950== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0936664950==-- From mext-bounces@ietf.org Mon Jan 12 08:30:03 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 237383A6902; Mon, 12 Jan 2009 08:30:03 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 980463A6A03; Mon, 12 Jan 2009 08:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090112163001.980463A6A03@core3.amsl.com> Date: Mon, 12 Jan 2009 08:30:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-11.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Multiple Care-of Addresses Registration Author(s) : R. Wakikawa, et al. Filename : draft-ietf-monami6-multiplecoa-11.txt Pages : 44 Date : 2009-01-12 According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, called the primary care-of address, that can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by Mobile Routers using the NEMO (Network Mobility) Basic Support protocol as well. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-monami6-multiplecoa-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-12082944.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Mon Jan 12 23:15:02 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44BB3A68E3; Mon, 12 Jan 2009 23:15:02 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2902A3A6886; Mon, 12 Jan 2009 23:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090113071501.2902A3A6886@core3.amsl.com> Date: Mon, 12 Jan 2009 23:15:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-mib-04.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : NEMO Management Information Base Author(s) : S. Gundavelli, et al. Filename : draft-ietf-mext-nemo-mib-04.txt Pages : 44 Date : 2009-01-12 This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a Mobile IPv6 node with NEMO functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-nemo-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-12230235.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Tue Jan 13 08:11:49 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7683A6AA5; Tue, 13 Jan 2009 08:11:49 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4F49A3A6981; Tue, 13 Jan 2009 08:11:47 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090113161148.4F49A3A6981@core3.amsl.com> Date: Tue, 13 Jan 2009 08:11:48 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] Last Call: draft-ietf-mext-nemo-mib (NEMO Management Information Base) to Proposed Standard X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org The IESG has received a request from the Mobility EXTensions for IPv6 WG (mext) to consider the following document: - 'NEMO Management Information Base ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-01-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16994&rfc_flag=0 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jan 13 13:08:30 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D43A3A6B19; Tue, 13 Jan 2009 13:08:30 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D71393A6B19 for ; Tue, 13 Jan 2009 13:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr11230S08mZ for ; Tue, 13 Jan 2009 13:08:28 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 1342F3A69C9 for ; Tue, 13 Jan 2009 13:08:28 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 001ED19871D; Tue, 13 Jan 2009 23:08:11 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id A913B198670; Tue, 13 Jan 2009 23:08:11 +0200 (EET) Message-ID: <496D0284.7070000@piuha.net> Date: Tue, 13 Jan 2009 23:07:16 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: draft-ietf-mext-nemo-mib@tools.ietf.org, "mext@ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [MEXT] One question on draft-ietf-mext-nemo-mib X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org There was one question on this draft when I re-reviewed it: Why is the mode needed twice below: nemoMrRegistrationGroup OBJECT-GROUP OBJECTS { nemoMrBLMode, ... nemoMrPrefixRegMode, ... Is this a mistake, or am I missing something? In any case, I have sent the draft forward to IETF Last Call. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jan 13 13:37:17 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30FB328C178; Tue, 13 Jan 2009 13:37:17 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9705D28C178 for ; Tue, 13 Jan 2009 13:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGlVnLYJCN2U for ; Tue, 13 Jan 2009 13:37:14 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B7F6A28C144 for ; Tue, 13 Jan 2009 13:37:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,261,1231113600"; d="scan'208";a="122244738" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 13 Jan 2009 21:37:00 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n0DLb0Lk010419; Tue, 13 Jan 2009 13:37:00 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n0DLb0Dp008114; Tue, 13 Jan 2009 21:37:00 GMT Date: Tue, 13 Jan 2009 13:37:00 -0800 (PST) From: Sri Gundavelli To: Jari Arkko In-Reply-To: <496D0284.7070000@piuha.net> Message-ID: References: <496D0284.7070000@piuha.net> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=805; t=1231882620; x=1232746620; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20One=20question=20on=20draft-ie tf-mext-nemo-mib |Sender:=20; bh=HeE5up9cMfwumZ96nJmNBPH+CBkt8EAa2TRpAnB/Y10=; b=Gf+VwJKMxTyA2St4Li9+rg3Bsxjm0jivbcD0mktYgpP/X7XefZOFs485Mu ennwNJmQMhsEZV8c5yXzG4DMgHUGJqCGn6F54PMOxQevpWjsmC96nmUcXLgq UHsVls8y26; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: draft-ietf-mext-nemo-mib@tools.ietf.org, "mext@ietf.org" Subject: Re: [MEXT] One question on draft-ietf-mext-nemo-mib X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jari, nemoMrPrefixRegMode is a RW object, for controlling the registration mode. The other object is in the BUL entry, reflecting the requested mode in a given registration. Thanks Sri On Tue, 13 Jan 2009, Jari Arkko wrote: > There was one question on this draft when I re-reviewed it: > > Why is the mode needed twice below: > > nemoMrRegistrationGroup OBJECT-GROUP > OBJECTS { > nemoMrBLMode, > ... > nemoMrPrefixRegMode, > ... > > Is this a mistake, or am I missing something? > > In any case, I have sent the draft forward to IETF Last Call. > > Jari > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jan 13 13:43:36 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F10528C190; Tue, 13 Jan 2009 13:43:36 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8527728C190 for ; Tue, 13 Jan 2009 13:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uSI8HYR9BP8 for ; Tue, 13 Jan 2009 13:43:26 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AE18B28C181 for ; Tue, 13 Jan 2009 13:43:26 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id A4E3A19871D; Tue, 13 Jan 2009 23:43:11 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 4EB5B198670; Tue, 13 Jan 2009 23:43:11 +0200 (EET) Message-ID: <496D0AB8.2080006@piuha.net> Date: Tue, 13 Jan 2009 23:42:16 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Sri Gundavelli References: <496D0284.7070000@piuha.net> In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: draft-ietf-mext-nemo-mib@tools.ietf.org, "mext@ietf.org" Subject: Re: [MEXT] One question on draft-ietf-mext-nemo-mib X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ok. Maybe this could be made clearer in the next revision. Jari Sri Gundavelli wrote: > Hi Jari, > > nemoMrPrefixRegMode is a RW object, for controlling the > registration mode. The other object is in the BUL entry, > reflecting the requested mode in a given registration. > > > Thanks > Sri > > > > On Tue, 13 Jan 2009, Jari Arkko wrote: > >> There was one question on this draft when I re-reviewed it: >> >> Why is the mode needed twice below: >> >> nemoMrRegistrationGroup OBJECT-GROUP >> OBJECTS { >> nemoMrBLMode, >> ... >> nemoMrPrefixRegMode, >> ... >> >> Is this a mistake, or am I missing something? >> >> In any case, I have sent the draft forward to IETF Last Call. >> >> Jari >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jan 13 13:46:39 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 523923A6B24; Tue, 13 Jan 2009 13:46:39 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF65228C19A for ; Tue, 13 Jan 2009 13:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cE2dN7xmyWWw for ; Tue, 13 Jan 2009 13:46:37 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E7DB928C155 for ; Tue, 13 Jan 2009 13:46:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,261,1231113600"; d="scan'208";a="122248361" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 13 Jan 2009 21:46:22 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0DLkMEw016645; Tue, 13 Jan 2009 13:46:22 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n0DLkMoY005051; Tue, 13 Jan 2009 21:46:22 GMT Date: Tue, 13 Jan 2009 13:46:22 -0800 (PST) From: Sri Gundavelli To: Jari Arkko In-Reply-To: <496D0AB8.2080006@piuha.net> Message-ID: References: <496D0284.7070000@piuha.net> <496D0AB8.2080006@piuha.net> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1166; t=1231883182; x=1232747182; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20One=20question=20on=20draft-ie tf-mext-nemo-mib |Sender:=20; bh=j9MfAMZPFRdtoD8I+s8pA2NkFs/Hjyz0VeLfRMcsfEg=; b=mmXW4qw33Z0rypTIVIFRGTF4Uhz4I9M6bzhiWUx8E+s2RuGhomn8IyyCOF n4TwoLtKF0W5qoUHFy/UZXLrivTNOWW+JUiSX5ITI9B/vUg+0HbUKEcQTjhe +87jmsoE7+; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: draft-ietf-mext-nemo-mib@tools.ietf.org, "mext@ietf.org" Subject: Re: [MEXT] One question on draft-ietf-mext-nemo-mib X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jari, Sure. Will update the description. Thanks Sri On Tue, 13 Jan 2009, Jari Arkko wrote: > Ok. Maybe this could be made clearer in the next revision. > > Jari > > Sri Gundavelli wrote: >> Hi Jari, >> >> nemoMrPrefixRegMode is a RW object, for controlling the >> registration mode. The other object is in the BUL entry, >> reflecting the requested mode in a given registration. >> >> >> Thanks >> Sri >> >> >> >> On Tue, 13 Jan 2009, Jari Arkko wrote: >> >> > There was one question on this draft when I re-reviewed it: >> > >> > Why is the mode needed twice below: >> > >> > nemoMrRegistrationGroup OBJECT-GROUP >> > OBJECTS { >> > nemoMrBLMode, >> > ... >> > nemoMrPrefixRegMode, >> > ... >> > >> > Is this a mistake, or am I missing something? >> > >> > In any case, I have sent the draft forward to IETF Last Call. >> > >> > Jari >> > >>> _______________________________________________ >> > MEXT mailing list >> > MEXT@ietf.org >> > https://www.ietf.org/mailman/listinfo/mext >> > >> >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jan 14 04:23:37 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456B83A67B0; Wed, 14 Jan 2009 04:23:37 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D3B3A68DF for ; Wed, 14 Jan 2009 04:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dJ1+6x9PnUG for ; Wed, 14 Jan 2009 04:23:35 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id B689A3A63EC for ; Wed, 14 Jan 2009 04:23:34 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LN4mC-0006om-LU; Wed, 14 Jan 2009 23:23:16 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 14 Jan 2009 23:23:10 +1100 From: Hesham Soliman To: "mext@ietf.org" Message-ID: Thread-Topic: GRE support in DSMIPv6 - AD review Thread-Index: Acl2Qty8AAnKSyLlR0eCYUg0kSOoIQ== Mime-version: 1.0 Cc: Pasi Eronen Subject: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, Part of Pasi's review for DSMIPv6 was a comment on the lack of specification for GRE support in the spec. He said it was vastly under-specified, no details on the tunnelling, setting of different parts of the GRE header ...etc. I suggested that we don't explicitly mention GRE in the spec but we keep the TLV tunnelling format and reserve the numbers for NETLMM to specify exactly how it will be used in a separate document. I think you would agree that this is largely driven by NETLMM needs and we shouldn't specify the details in MEXT. Pasi was ok with that. Please express your opinion on this soon because Pasi's comments are the last comments for the draft and I want to handle them by Monday at the latest. Please avoid discussing the merits of GRE....etc, the question is: Are there any objections to removing explicit references to GRE while reserving the numbers in the TLV header for it to be specified clearly in NETLMM? Thanks, Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jan 14 10:20:02 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A151E3A6A33; Wed, 14 Jan 2009 10:20:02 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3393B3A6A24 for ; Wed, 14 Jan 2009 10:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.68 X-Spam-Level: X-Spam-Status: No, score=-105.68 tagged_above=-999 required=5 tests=[AWL=0.919, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41FMQtxfs0zd for ; Wed, 14 Jan 2009 10:20:01 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 3A3063A6A15 for ; Wed, 14 Jan 2009 10:20:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1231957186; x=1263493186; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Hesham=20Soliman=20,=20" mext@ietf.org"=20|CC:=20Pasi=20Eronen=20

|Date:=20Wed,=2014=20Jan=202009=2010 :19:17=20-0800|Subject:=20RE:=20GRE=20support=20in=20DSMI Pv6=20-=20AD=20review|Thread-Topic:=20GRE=20support=20in =20DSMIPv6=20-=20AD=20review|Thread-Index:=20Acl2Qty8AAnK SyLlR0eCYUg0kSOoIQAMb/rB|Message-ID:=20<057632CE4CE10D45A 1A3D6D19206C3A3D9AA781B@NASANEXMB08.na.qualcomm.com> |References:=20 |In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5495"=3B=20a=3D"14650247"; bh=N2PRpElpH5iBZSbDnKbSAfpoRHZs649xOZVigOa6Lfo=; b=nbBBlC5D1UMgDlGvJBF7NOrO/TTMi8i/IPfJ/s1xj5TAgpz1rd9WZapv 4ZA6bKoXLCTyCVLLezTLMT1rKzhpouVrpNlVPGIcCRrkyceREekSrjXCq 0ZIvyvnw9P8Aud2AqupHXVRaXZoT+Fwp45KeiSIAaH/uMd8lYD3dfn8PS E=; X-IronPort-AV: E=McAfee;i="5300,2777,5495"; a="14650247" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jan 2009 10:19:46 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0EIJkt2029645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Jan 2009 10:19:46 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0EIJRQF013411 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Jan 2009 10:19:45 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Wed, 14 Jan 2009 10:19:38 -0800 From: "Giaretta, Gerardo" To: Hesham Soliman , "mext@ietf.org" Date: Wed, 14 Jan 2009 10:19:17 -0800 Thread-Topic: GRE support in DSMIPv6 - AD review Thread-Index: Acl2Qty8AAnKSyLlR0eCYUg0kSOoIQAMb/rB Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D9AA781B@NASANEXMB08.na.qualcomm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Pasi Eronen Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, I am fine with your proposal. Gerardo ________________________________________ From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf Of Hesham Soliman [hesham@elevatemobile.com] Sent: Wednesday, January 14, 2009 4:23 AM To: mext@ietf.org Cc: Pasi Eronen Subject: [MEXT] GRE support in DSMIPv6 - AD review Folks, Part of Pasi's review for DSMIPv6 was a comment on the lack of specification for GRE support in the spec. He said it was vastly under-specified, no details on the tunnelling, setting of different parts of the GRE header ...etc. I suggested that we don't explicitly mention GRE in the spec but we keep the TLV tunnelling format and reserve the numbers for NETLMM to specify exactly how it will be used in a separate document. I think you would agree that this is largely driven by NETLMM needs and we shouldn't specify the details in MEXT. Pasi was ok with that. Please express your opinion on this soon because Pasi's comments are the last comments for the draft and I want to handle them by Monday at the latest. Please avoid discussing the merits of GRE....etc, the question is: Are there any objections to removing explicit references to GRE while reserving the numbers in the TLV header for it to be specified clearly in NETLMM? Thanks, Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jan 14 10:28:12 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7E53A69C2; Wed, 14 Jan 2009 10:28:12 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83BCA3A69C2 for ; Wed, 14 Jan 2009 10:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ke+ZBQlLxpSE for ; Wed, 14 Jan 2009 10:28:10 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A6D313A69A9 for ; Wed, 14 Jan 2009 10:28:10 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0EIRS2Z026060; Wed, 14 Jan 2009 12:27:50 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 20:27:45 +0200 Received: from vaebe112.NOE.Nokia.com ([10.160.244.81]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 20:27:45 +0200 Received: from 172.19.60.134 ([172.19.60.134]) by vaebe112.NOE.Nokia.com ([10.160.244.81]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Jan 2009 18:27:45 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 14 Jan 2009 12:27:55 -0600 From: Basavaraj Patil To: ext Hesham Soliman , "mext@ietf.org" Message-ID: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl2Qty8AAnKSyLlR0eCYUg0kSOoIQAMvR4x In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 14 Jan 2009 18:27:45.0420 (UTC) FILETIME=[CB803CC0:01C97675] X-Nokia-AV: Clean Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, I don't see a need for specifying GRE tunnelling in the current spec. But I am at a loss to understand what Netlmm is expected to do to specify GRE tunnelling for DSMIP6. It is best to simply say that the use of GRE tunnelling in the context of DSMIP6 may be specified separately and leave it at that. I am fine with your proposed recommendation with the caveat that you do not even mention which WG or document specifies the details of GRE tunnelling. -Raj On 1/14/09 6:23 AM, "ext Hesham Soliman" wrote: > Folks, > > Part of Pasi's review for DSMIPv6 was a comment on the lack of specification > for GRE support in the spec. He said it was vastly under-specified, no > details on the tunnelling, setting of different parts of the GRE header > ...etc. > > I suggested that we don't explicitly mention GRE in the spec but we keep the > TLV tunnelling format and reserve the numbers for NETLMM to specify exactly > how it will be used in a separate document. I think you would agree that > this is largely driven by NETLMM needs and we shouldn't specify the details > in MEXT. Pasi was ok with that. > > Please express your opinion on this soon because Pasi's comments are the > last comments for the draft and I want to handle them by Monday at the > latest. > > Please avoid discussing the merits of GRE....etc, the question is: > > Are there any objections to removing explicit references to GRE while > reserving the numbers in the TLV header for it to be specified clearly in > NETLMM? > > Thanks, > > Hesham > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 03:54:33 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF9828C11D; Thu, 15 Jan 2009 03:54:33 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9539128C11D for ; Thu, 15 Jan 2009 03:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES+H5AcgCM-t for ; Thu, 15 Jan 2009 03:54:30 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 89F8C28C10D for ; Thu, 15 Jan 2009 03:54:30 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0FBs61i017546; Thu, 15 Jan 2009 13:54:09 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 13:53:59 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 13:53:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jan 2009 13:53:58 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB7202E5DEBA@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GRE support in DSMIPv6 - AD review Thread-Index: Acl2Qty8AAnKSyLlR0eCYUg0kSOoIQAxLqsA References: From: To: , X-OriginalArrivalTime: 15 Jan 2009 11:53:59.0424 (UTC) FILETIME=[F3B91800:01C97707] X-Nokia-AV: Clean Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hesham, I would strongly suggest moving the whole TLV header text to the separate GRE document. In particular, if you assign a number for GRE in this document, you either need to describe how it works here, or have a normative reference to the NETLMM spec. Best regards, Pasi > -----Original Message----- > From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: 14 January, 2009 14:23 > To: mext@ietf.org > Cc: Eronen Pasi (Nokia-NRC/Helsinki) > Subject: GRE support in DSMIPv6 - AD review > > Folks, > > Part of Pasi's review for DSMIPv6 was a comment on the lack of > specification for GRE support in the spec. He said it was vastly > under-specified, no details on the tunnelling, setting of different > parts of the GRE header ...etc. > > I suggested that we don't explicitly mention GRE in the spec but we > keep the TLV tunnelling format and reserve the numbers for NETLMM to > specify exactly how it will be used in a separate document. I think > you would agree that this is largely driven by NETLMM needs and we > shouldn't specify the details in MEXT. Pasi was ok with that. > > Please express your opinion on this soon because Pasi's comments are > the last comments for the draft and I want to handle them by Monday > at the latest. > > Please avoid discussing the merits of GRE....etc, the question is: > > Are there any objections to removing explicit references to GRE > while reserving the numbers in the TLV header for it to be specified > clearly in NETLMM? > > Thanks, > > Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 05:25:30 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500D528C216; Thu, 15 Jan 2009 05:25:30 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24B228C22F for ; Thu, 15 Jan 2009 05:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovGNZjMVz8H2 for ; Thu, 15 Jan 2009 05:25:20 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 9C08828C210 for ; Thu, 15 Jan 2009 05:25:15 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LNSDR-0008HC-SE; Fri, 16 Jan 2009 00:24:58 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 16 Jan 2009 00:24:53 +1100 From: Hesham Soliman To: , Message-ID: Thread-Topic: GRE support in DSMIPv6 - AD review Thread-Index: Acl2Qty8AAnKSyLlR0eCYUg0kSOoIQAxLqsAAANDudY= In-Reply-To: <1696498986EFEC4D9153717DA325CB7202E5DEBA@vaebe104.NOE.Nokia.com> Mime-version: 1.0 Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > I would strongly suggest moving the whole TLV header text to the > separate GRE document. => Personally, as everyone on the list knows, I was always against including this in the draft, I think it's a really bad idea, but obviously it's not my decision. So let's see what people say. I do agree with this suggestion. > > In particular, if you assign a number for GRE in this document, > you either need to describe how it works here, or have a normative > reference to the NETLMM spec. => My suggestion below was not to assign any numbers in the draft. It was simply to have the TLV header unassigned and let someone else request the assignment and describe how it's used. My ideal preference is the one above (remove it completely) but the suggestion below was a compromise to speed things up. Hesham > > Best regards, > Pasi > >> -----Original Message----- >> From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: 14 January, 2009 14:23 >> To: mext@ietf.org >> Cc: Eronen Pasi (Nokia-NRC/Helsinki) >> Subject: GRE support in DSMIPv6 - AD review >> >> Folks, >> >> Part of Pasi's review for DSMIPv6 was a comment on the lack of >> specification for GRE support in the spec. He said it was vastly >> under-specified, no details on the tunnelling, setting of different >> parts of the GRE header ...etc. >> >> I suggested that we don't explicitly mention GRE in the spec but we >> keep the TLV tunnelling format and reserve the numbers for NETLMM to >> specify exactly how it will be used in a separate document. I think >> you would agree that this is largely driven by NETLMM needs and we >> shouldn't specify the details in MEXT. Pasi was ok with that. >> >> Please express your opinion on this soon because Pasi's comments are >> the last comments for the draft and I want to handle them by Monday >> at the latest. >> >> Please avoid discussing the merits of GRE....etc, the question is: >> >> Are there any objections to removing explicit references to GRE >> while reserving the numbers in the TLV header for it to be specified >> clearly in NETLMM? >> >> Thanks, >> >> Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 05:37:58 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6075828C200; Thu, 15 Jan 2009 05:37:58 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B08428C133 for ; Thu, 15 Jan 2009 05:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHKBRpKZMpyX for ; Thu, 15 Jan 2009 05:37:55 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 5B5573A690B for ; Thu, 15 Jan 2009 05:37:55 -0800 (PST) Received: by bwz14 with SMTP id 14so3379201bwz.13 for ; Thu, 15 Jan 2009 05:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WJN4jJDCG0VjNrP5giwD6YMsFd4fcSR4i7cLHGIDzd8=; b=lg8org+q+B9UPL5HhKSSBHBht8Xou2QtrGwJLp5ikQbyVIcpyJuQPf6ggD6gq1bs06 TJLmUH+vvghrVcge8DrZ0lapPBXV06YR/KCJ2brr24IdSghCTEwCN9dE0MPPgYyKxYTx CJWvcD8HNlXYzOetQ8wxUF9JTNMLwS8W9cglc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hqrOy5/Lox9fuJDUjWgRGZ01V0KqeRHEROs2CMLs7vXhsDYrjwCGl2HMKv0E8X9lyu AoZedNmMEmKm+J9VRE0Sr2g8Gx+me7xrgldWg6p75KdtI+WXy4sJYwTzSvrNa33adPDr 7dBhMltCfehDLGkpYiIWfoWtprVgqb2Kiq6OE= MIME-Version: 1.0 Received: by 10.223.111.211 with SMTP id t19mr1605480fap.64.1232026659471; Thu, 15 Jan 2009 05:37:39 -0800 (PST) In-Reply-To: References: <1696498986EFEC4D9153717DA325CB7202E5DEBA@vaebe104.NOE.Nokia.com> Date: Thu, 15 Jan 2009 13:37:39 +0000 Message-ID: From: George Tsirtsis To: Hesham Soliman Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I think what Pasi suggests makes sense and will make things easier for whoever defines GRE support. Not assigning a number for the TLV essentially means that the TLV header for GRE is undefined and thus nothing needs to be said about it. The whole thing can then be defined in a different spec as needed. Regards George On Thu, Jan 15, 2009 at 1:24 PM, Hesham Soliman wrote: > > >> I would strongly suggest moving the whole TLV header text to the >> separate GRE document. > > => Personally, as everyone on the list knows, I was always against including > this in the draft, I think it's a really bad idea, but obviously it's not my > decision. So let's see what people say. I do agree with this suggestion. > >> >> In particular, if you assign a number for GRE in this document, >> you either need to describe how it works here, or have a normative >> reference to the NETLMM spec. > > => My suggestion below was not to assign any numbers in the draft. It was > simply to have the TLV header unassigned and let someone else request the > assignment and describe how it's used. My ideal preference is the one above > (remove it completely) but the suggestion below was a compromise to speed > things up. > > Hesham > >> >> Best regards, >> Pasi >> >>> -----Original Message----- >>> From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: 14 January, 2009 14:23 >>> To: mext@ietf.org >>> Cc: Eronen Pasi (Nokia-NRC/Helsinki) >>> Subject: GRE support in DSMIPv6 - AD review >>> >>> Folks, >>> >>> Part of Pasi's review for DSMIPv6 was a comment on the lack of >>> specification for GRE support in the spec. He said it was vastly >>> under-specified, no details on the tunnelling, setting of different >>> parts of the GRE header ...etc. >>> >>> I suggested that we don't explicitly mention GRE in the spec but we >>> keep the TLV tunnelling format and reserve the numbers for NETLMM to >>> specify exactly how it will be used in a separate document. I think >>> you would agree that this is largely driven by NETLMM needs and we >>> shouldn't specify the details in MEXT. Pasi was ok with that. >>> >>> Please express your opinion on this soon because Pasi's comments are >>> the last comments for the draft and I want to handle them by Monday >>> at the latest. >>> >>> Please avoid discussing the merits of GRE....etc, the question is: >>> >>> Are there any objections to removing explicit references to GRE >>> while reserving the numbers in the TLV header for it to be specified >>> clearly in NETLMM? >>> >>> Thanks, >>> >>> Hesham > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 05:51:42 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD653A68F3; Thu, 15 Jan 2009 05:51:42 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4D23A68F3 for ; Thu, 15 Jan 2009 05:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IIlBEN+Dy9i for ; Thu, 15 Jan 2009 05:51:40 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id F2F443A6849 for ; Thu, 15 Jan 2009 05:51:39 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LNScw-0000nQ-Az; Fri, 16 Jan 2009 00:51:18 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 16 Jan 2009 00:51:12 +1100 From: Hesham Soliman To: George Tsirtsis Message-ID: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl3GFN3P6Lg78/I2UaaKwg3JxPX8Q== In-Reply-To: Mime-version: 1.0 Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > I think what Pasi suggests makes sense and will make things easier for > whoever defines GRE support. => So are you agreeing with removing the TLV completely or with simply removing the assignment of the GRE? They're two different things. Hesham > > Not assigning a number for the TLV essentially means that the TLV > header for GRE is undefined and thus nothing needs to be said about > it. The whole thing can then be defined in a different spec as needed. > > Regards > George > > On Thu, Jan 15, 2009 at 1:24 PM, Hesham Soliman > wrote: >> >> >>> I would strongly suggest moving the whole TLV header text to the >>> separate GRE document. >> >> => Personally, as everyone on the list knows, I was always against including >> this in the draft, I think it's a really bad idea, but obviously it's not my >> decision. So let's see what people say. I do agree with this suggestion. >> >>> >>> In particular, if you assign a number for GRE in this document, >>> you either need to describe how it works here, or have a normative >>> reference to the NETLMM spec. >> >> => My suggestion below was not to assign any numbers in the draft. It was >> simply to have the TLV header unassigned and let someone else request the >> assignment and describe how it's used. My ideal preference is the one above >> (remove it completely) but the suggestion below was a compromise to speed >> things up. >> >> Hesham >> >>> >>> Best regards, >>> Pasi >>> >>>> -----Original Message----- >>>> From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: 14 January, 2009 14:23 >>>> To: mext@ietf.org >>>> Cc: Eronen Pasi (Nokia-NRC/Helsinki) >>>> Subject: GRE support in DSMIPv6 - AD review >>>> >>>> Folks, >>>> >>>> Part of Pasi's review for DSMIPv6 was a comment on the lack of >>>> specification for GRE support in the spec. He said it was vastly >>>> under-specified, no details on the tunnelling, setting of different >>>> parts of the GRE header ...etc. >>>> >>>> I suggested that we don't explicitly mention GRE in the spec but we >>>> keep the TLV tunnelling format and reserve the numbers for NETLMM to >>>> specify exactly how it will be used in a separate document. I think >>>> you would agree that this is largely driven by NETLMM needs and we >>>> shouldn't specify the details in MEXT. Pasi was ok with that. >>>> >>>> Please express your opinion on this soon because Pasi's comments are >>>> the last comments for the draft and I want to handle them by Monday >>>> at the latest. >>>> >>>> Please avoid discussing the merits of GRE....etc, the question is: >>>> >>>> Are there any objections to removing explicit references to GRE >>>> while reserving the numbers in the TLV header for it to be specified >>>> clearly in NETLMM? >>>> >>>> Thanks, >>>> >>>> Hesham >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 06:02:47 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 203803A695F; Thu, 15 Jan 2009 06:02:47 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA5B3A695F for ; Thu, 15 Jan 2009 06:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APbCYh78p+PP for ; Thu, 15 Jan 2009 06:02:45 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 053143A68C1 for ; Thu, 15 Jan 2009 06:02:44 -0800 (PST) Received: by bwz14 with SMTP id 14so3413797bwz.13 for ; Thu, 15 Jan 2009 06:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aQ4Dzp//LoPJI9H+e0JNbl0o+HDnuvdPp/PGnlsksGM=; b=uJfXygAx2J+ixRcB5Js+Ha+WQr/OOdsSGeWfFy5iQ3+BzVr3wGjNdeZJ+kaRg7C1ih Rzl70LnGUjNqc6yN6/qfchyhEUouc7ws0BihaAlJPXFpWtsBr6bRf/c5RQisN6crDbgs FQX6fB01I+Gc5GCqbTyEOy+MNWTrnNV4Y/Co0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rRURlO3eAX72t+R2JtPjnEPfLSmBBE91htHG7x+Qomf6RuTTjlMAT3tKHGfK3a3IOC 0F2Txyw8X9oI01MsSqNldSwda5HhwN3V1PpkOKmPPItuCj/2bFPPLxZSn8mMzbavJxpt c2NNBMtRd7JO1qZh2ezdSOc9Co6ReKcZ2hz7Q= MIME-Version: 1.0 Received: by 10.223.114.74 with SMTP id d10mr1633061faq.87.1232028147799; Thu, 15 Jan 2009 06:02:27 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Jan 2009 14:02:27 +0000 Message-ID: From: George Tsirtsis To: Hesham Soliman Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org How are they different? Maybe I am missing something. The only type value defined currently on the TLV is for GRE. If you remove the GRE value, what is the TLV for? George On Thu, Jan 15, 2009 at 1:51 PM, Hesham Soliman wrote: > > > > >> I think what Pasi suggests makes sense and will make things easier for >> whoever defines GRE support. > > => So are you agreeing with removing the TLV completely or with simply > removing the assignment of the GRE? They're two different things. > > Hesham > >> >> Not assigning a number for the TLV essentially means that the TLV >> header for GRE is undefined and thus nothing needs to be said about >> it. The whole thing can then be defined in a different spec as needed. >> >> Regards >> George >> >> On Thu, Jan 15, 2009 at 1:24 PM, Hesham Soliman >> wrote: >>> >>> >>>> I would strongly suggest moving the whole TLV header text to the >>>> separate GRE document. >>> >>> => Personally, as everyone on the list knows, I was always against including >>> this in the draft, I think it's a really bad idea, but obviously it's not my >>> decision. So let's see what people say. I do agree with this suggestion. >>> >>>> >>>> In particular, if you assign a number for GRE in this document, >>>> you either need to describe how it works here, or have a normative >>>> reference to the NETLMM spec. >>> >>> => My suggestion below was not to assign any numbers in the draft. It was >>> simply to have the TLV header unassigned and let someone else request the >>> assignment and describe how it's used. My ideal preference is the one above >>> (remove it completely) but the suggestion below was a compromise to speed >>> things up. >>> >>> Hesham >>> >>>> >>>> Best regards, >>>> Pasi >>>> >>>>> -----Original Message----- >>>>> From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: 14 January, 2009 14:23 >>>>> To: mext@ietf.org >>>>> Cc: Eronen Pasi (Nokia-NRC/Helsinki) >>>>> Subject: GRE support in DSMIPv6 - AD review >>>>> >>>>> Folks, >>>>> >>>>> Part of Pasi's review for DSMIPv6 was a comment on the lack of >>>>> specification for GRE support in the spec. He said it was vastly >>>>> under-specified, no details on the tunnelling, setting of different >>>>> parts of the GRE header ...etc. >>>>> >>>>> I suggested that we don't explicitly mention GRE in the spec but we >>>>> keep the TLV tunnelling format and reserve the numbers for NETLMM to >>>>> specify exactly how it will be used in a separate document. I think >>>>> you would agree that this is largely driven by NETLMM needs and we >>>>> shouldn't specify the details in MEXT. Pasi was ok with that. >>>>> >>>>> Please express your opinion on this soon because Pasi's comments are >>>>> the last comments for the draft and I want to handle them by Monday >>>>> at the latest. >>>>> >>>>> Please avoid discussing the merits of GRE....etc, the question is: >>>>> >>>>> Are there any objections to removing explicit references to GRE >>>>> while reserving the numbers in the TLV header for it to be specified >>>>> clearly in NETLMM? >>>>> >>>>> Thanks, >>>>> >>>>> Hesham >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 06:07:06 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F3D3A6925; Thu, 15 Jan 2009 06:07:06 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3D83A6925 for ; Thu, 15 Jan 2009 06:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gLQBOZhEoQj for ; Thu, 15 Jan 2009 06:07:04 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 4FB193A6803 for ; Thu, 15 Jan 2009 06:06:59 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LNSrl-00010a-09; Fri, 16 Jan 2009 01:06:37 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 16 Jan 2009 01:06:30 +1100 From: Hesham Soliman To: George Tsirtsis Message-ID: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl3GnaicWevlZ8G0kuvB+gkn/eC6w== In-Reply-To: Mime-version: 1.0 Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Pasi mentioned in the first paragraph that he " would strongly suggest moving the whole TLV header text to the separate GRE document." This is different from keeping the TLV header and removing the assignment of GRE values. Two very different approaches. It's not clear to me which one you are asking for. Hesham On 16/01/09 1:02 AM, "George Tsirtsis" wrote: > How are they different? Maybe I am missing something. The only type > value defined currently on the TLV is for GRE. If you remove the GRE > value, what is the TLV for? > > George > > On Thu, Jan 15, 2009 at 1:51 PM, Hesham Soliman > wrote: >> >> >> >> >>> I think what Pasi suggests makes sense and will make things easier for >>> whoever defines GRE support. >> >> => So are you agreeing with removing the TLV completely or with simply >> removing the assignment of the GRE? They're two different things. >> >> Hesham >> >>> >>> Not assigning a number for the TLV essentially means that the TLV >>> header for GRE is undefined and thus nothing needs to be said about >>> it. The whole thing can then be defined in a different spec as needed. >>> >>> Regards >>> George >>> >>> On Thu, Jan 15, 2009 at 1:24 PM, Hesham Soliman >>> wrote: >>>> >>>> >>>>> I would strongly suggest moving the whole TLV header text to the >>>>> separate GRE document. >>>> >>>> => Personally, as everyone on the list knows, I was always against >>>> including >>>> this in the draft, I think it's a really bad idea, but obviously it's not >>>> my >>>> decision. So let's see what people say. I do agree with this suggestion. >>>> >>>>> >>>>> In particular, if you assign a number for GRE in this document, >>>>> you either need to describe how it works here, or have a normative >>>>> reference to the NETLMM spec. >>>> >>>> => My suggestion below was not to assign any numbers in the draft. It was >>>> simply to have the TLV header unassigned and let someone else request the >>>> assignment and describe how it's used. My ideal preference is the one above >>>> (remove it completely) but the suggestion below was a compromise to speed >>>> things up. >>>> >>>> Hesham >>>> >>>>> >>>>> Best regards, >>>>> Pasi >>>>> >>>>>> -----Original Message----- >>>>>> From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: 14 January, 2009 14:23 >>>>>> To: mext@ietf.org >>>>>> Cc: Eronen Pasi (Nokia-NRC/Helsinki) >>>>>> Subject: GRE support in DSMIPv6 - AD review >>>>>> >>>>>> Folks, >>>>>> >>>>>> Part of Pasi's review for DSMIPv6 was a comment on the lack of >>>>>> specification for GRE support in the spec. He said it was vastly >>>>>> under-specified, no details on the tunnelling, setting of different >>>>>> parts of the GRE header ...etc. >>>>>> >>>>>> I suggested that we don't explicitly mention GRE in the spec but we >>>>>> keep the TLV tunnelling format and reserve the numbers for NETLMM to >>>>>> specify exactly how it will be used in a separate document. I think >>>>>> you would agree that this is largely driven by NETLMM needs and we >>>>>> shouldn't specify the details in MEXT. Pasi was ok with that. >>>>>> >>>>>> Please express your opinion on this soon because Pasi's comments are >>>>>> the last comments for the draft and I want to handle them by Monday >>>>>> at the latest. >>>>>> >>>>>> Please avoid discussing the merits of GRE....etc, the question is: >>>>>> >>>>>> Are there any objections to removing explicit references to GRE >>>>>> while reserving the numbers in the TLV header for it to be specified >>>>>> clearly in NETLMM? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Hesham >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >> >> >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 06:13:24 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F653A696B; Thu, 15 Jan 2009 06:13:24 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98DF3A696B for ; Thu, 15 Jan 2009 06:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ud+6OrlWZm1R for ; Thu, 15 Jan 2009 06:13:23 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 8F3AF3A692F for ; Thu, 15 Jan 2009 06:13:22 -0800 (PST) Received: by bwz14 with SMTP id 14so3429391bwz.13 for ; Thu, 15 Jan 2009 06:13:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GFyXntkSJuU+BF7h2xyo7d3R1MGPuHE/e8Y+/rjN0j0=; b=MhIQNPEPqy3cfgoNlGoitIzH0H6x5EnnqrfdlI+5oCv7CIYvf83yP7HD1eoiejcQlp iJ0Xa/LKQag7EJVMQRd2vzJ8Oz6UTDVcppT0ZKv9wO0tHiHHkeIodPH6QKQSav0CLpht DC/earNPaC49ApT+f4YHd6SIn4nZphU76InoM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eigMhODjI/N+yuvs/IMSVzK9LmL8VmdfxXJ/F5uOqtx6h7cKVtpfpu83oLfWqqTyrR MNPp1/BPBLtC0FfEka4bJBfRHXWtPvY7T8TjtzGzFPxBzB789h5LONFe7TeIC6MgsoN5 zvHq0uX4/GJU7Z541rIHp7yoCKLolWZHZw4LM= MIME-Version: 1.0 Received: by 10.223.113.193 with SMTP id b1mr1657236faq.78.1232028786490; Thu, 15 Jan 2009 06:13:06 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Jan 2009 14:13:06 +0000 Message-ID: From: George Tsirtsis To: Hesham Soliman Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Thu, Jan 15, 2009 at 2:06 PM, Hesham Soliman wrote: > Pasi mentioned in the first paragraph that he " would strongly suggest > moving the whole TLV header text to the separate GRE document." > GT> This makes sense to me. > This is different from keeping the TLV header and removing the assignment of > GRE values. GT> I am still trying to understand what this means in practice. If you keep the TLV header and remove the GRE assigned value then the draft will NOT have any valid Type values for the TLV header. What is an implementation supposed to do with that? > Two very different approaches. It's not clear to me which one > you are asking for. > GT> If you can clarify the above I will tell you :-) > Hesham > > > On 16/01/09 1:02 AM, "George Tsirtsis" wrote: > >> How are they different? Maybe I am missing something. The only type >> value defined currently on the TLV is for GRE. If you remove the GRE >> value, what is the TLV for? >> >> George >> >> On Thu, Jan 15, 2009 at 1:51 PM, Hesham Soliman >> wrote: >>> >>> >>> >>> >>>> I think what Pasi suggests makes sense and will make things easier for >>>> whoever defines GRE support. >>> >>> => So are you agreeing with removing the TLV completely or with simply >>> removing the assignment of the GRE? They're two different things. >>> >>> Hesham >>> >>>> >>>> Not assigning a number for the TLV essentially means that the TLV >>>> header for GRE is undefined and thus nothing needs to be said about >>>> it. The whole thing can then be defined in a different spec as needed. >>>> >>>> Regards >>>> George >>>> >>>> On Thu, Jan 15, 2009 at 1:24 PM, Hesham Soliman >>>> wrote: >>>>> >>>>> >>>>>> I would strongly suggest moving the whole TLV header text to the >>>>>> separate GRE document. >>>>> >>>>> => Personally, as everyone on the list knows, I was always against >>>>> including >>>>> this in the draft, I think it's a really bad idea, but obviously it's not >>>>> my >>>>> decision. So let's see what people say. I do agree with this suggestion. >>>>> >>>>>> >>>>>> In particular, if you assign a number for GRE in this document, >>>>>> you either need to describe how it works here, or have a normative >>>>>> reference to the NETLMM spec. >>>>> >>>>> => My suggestion below was not to assign any numbers in the draft. It was >>>>> simply to have the TLV header unassigned and let someone else request the >>>>> assignment and describe how it's used. My ideal preference is the one above >>>>> (remove it completely) but the suggestion below was a compromise to speed >>>>> things up. >>>>> >>>>> Hesham >>>>> >>>>>> >>>>>> Best regards, >>>>>> Pasi >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>> Sent: 14 January, 2009 14:23 >>>>>>> To: mext@ietf.org >>>>>>> Cc: Eronen Pasi (Nokia-NRC/Helsinki) >>>>>>> Subject: GRE support in DSMIPv6 - AD review >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> Part of Pasi's review for DSMIPv6 was a comment on the lack of >>>>>>> specification for GRE support in the spec. He said it was vastly >>>>>>> under-specified, no details on the tunnelling, setting of different >>>>>>> parts of the GRE header ...etc. >>>>>>> >>>>>>> I suggested that we don't explicitly mention GRE in the spec but we >>>>>>> keep the TLV tunnelling format and reserve the numbers for NETLMM to >>>>>>> specify exactly how it will be used in a separate document. I think >>>>>>> you would agree that this is largely driven by NETLMM needs and we >>>>>>> shouldn't specify the details in MEXT. Pasi was ok with that. >>>>>>> >>>>>>> Please express your opinion on this soon because Pasi's comments are >>>>>>> the last comments for the draft and I want to handle them by Monday >>>>>>> at the latest. >>>>>>> >>>>>>> Please avoid discussing the merits of GRE....etc, the question is: >>>>>>> >>>>>>> Are there any objections to removing explicit references to GRE >>>>>>> while reserving the numbers in the TLV header for it to be specified >>>>>>> clearly in NETLMM? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Hesham >>>>> >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>> >>> >>> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 06:16:34 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED993A692F; Thu, 15 Jan 2009 06:16:34 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9504B3A692F for ; Thu, 15 Jan 2009 06:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgJu5ZYFsk+B for ; Thu, 15 Jan 2009 06:16:32 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 57ECE3A67FA for ; Thu, 15 Jan 2009 06:16:31 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LNT0z-0001Ai-VD; Fri, 16 Jan 2009 01:16:11 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 16 Jan 2009 01:16:07 +1100 From: Hesham Soliman To: George Tsirtsis Message-ID: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl3G86N/ejpj2zpQU+cBpdI8AipgQ== In-Reply-To: Mime-version: 1.0 Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 16/01/09 1:13 AM, "George Tsirtsis" wrote: > On Thu, Jan 15, 2009 at 2:06 PM, Hesham Soliman > wrote: >> Pasi mentioned in the first paragraph that he " would strongly suggest >> moving the whole TLV header text to the separate GRE document." >> > > GT> This makes sense to me. > >> This is different from keeping the TLV header and removing the assignment of >> GRE values. > > GT> I am still trying to understand what this means in practice. If > you keep the TLV header and remove the GRE assigned value then the > draft will NOT have any valid Type values for the TLV header. What is > an implementation supposed to do with that? => Absolutely nothing until a number is assigned in another spec. > >> Two very different approaches. It's not clear to me which one >> you are asking for. >> > > GT> If you can clarify the above I will tell you :-) => Hope this helps :) Hesham > >> Hesham >> >> >> On 16/01/09 1:02 AM, "George Tsirtsis" wrote: >> >>> How are they different? Maybe I am missing something. The only type >>> value defined currently on the TLV is for GRE. If you remove the GRE >>> value, what is the TLV for? >>> >>> George >>> >>> On Thu, Jan 15, 2009 at 1:51 PM, Hesham Soliman >>> wrote: >>>> >>>> >>>> >>>> >>>>> I think what Pasi suggests makes sense and will make things easier for >>>>> whoever defines GRE support. >>>> >>>> => So are you agreeing with removing the TLV completely or with simply >>>> removing the assignment of the GRE? They're two different things. >>>> >>>> Hesham >>>> >>>>> >>>>> Not assigning a number for the TLV essentially means that the TLV >>>>> header for GRE is undefined and thus nothing needs to be said about >>>>> it. The whole thing can then be defined in a different spec as needed. >>>>> >>>>> Regards >>>>> George >>>>> >>>>> On Thu, Jan 15, 2009 at 1:24 PM, Hesham Soliman >>>>> wrote: >>>>>> >>>>>> >>>>>>> I would strongly suggest moving the whole TLV header text to the >>>>>>> separate GRE document. >>>>>> >>>>>> => Personally, as everyone on the list knows, I was always against >>>>>> including >>>>>> this in the draft, I think it's a really bad idea, but obviously it's not >>>>>> my >>>>>> decision. So let's see what people say. I do agree with this suggestion. >>>>>> >>>>>>> >>>>>>> In particular, if you assign a number for GRE in this document, >>>>>>> you either need to describe how it works here, or have a normative >>>>>>> reference to the NETLMM spec. >>>>>> >>>>>> => My suggestion below was not to assign any numbers in the draft. It was >>>>>> simply to have the TLV header unassigned and let someone else request the >>>>>> assignment and describe how it's used. My ideal preference is the one >>>>>> above >>>>>> (remove it completely) but the suggestion below was a compromise to speed >>>>>> things up. >>>>>> >>>>>> Hesham >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Pasi >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>> Sent: 14 January, 2009 14:23 >>>>>>>> To: mext@ietf.org >>>>>>>> Cc: Eronen Pasi (Nokia-NRC/Helsinki) >>>>>>>> Subject: GRE support in DSMIPv6 - AD review >>>>>>>> >>>>>>>> Folks, >>>>>>>> >>>>>>>> Part of Pasi's review for DSMIPv6 was a comment on the lack of >>>>>>>> specification for GRE support in the spec. He said it was vastly >>>>>>>> under-specified, no details on the tunnelling, setting of different >>>>>>>> parts of the GRE header ...etc. >>>>>>>> >>>>>>>> I suggested that we don't explicitly mention GRE in the spec but we >>>>>>>> keep the TLV tunnelling format and reserve the numbers for NETLMM to >>>>>>>> specify exactly how it will be used in a separate document. I think >>>>>>>> you would agree that this is largely driven by NETLMM needs and we >>>>>>>> shouldn't specify the details in MEXT. Pasi was ok with that. >>>>>>>> >>>>>>>> Please express your opinion on this soon because Pasi's comments are >>>>>>>> the last comments for the draft and I want to handle them by Monday >>>>>>>> at the latest. >>>>>>>> >>>>>>>> Please avoid discussing the merits of GRE....etc, the question is: >>>>>>>> >>>>>>>> Are there any objections to removing explicit references to GRE >>>>>>>> while reserving the numbers in the TLV header for it to be specified >>>>>>>> clearly in NETLMM? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Hesham >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>> >>>> >>>> >> >> >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 08:12:59 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2253A6969; Thu, 15 Jan 2009 08:12:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596173A67AF for ; Thu, 15 Jan 2009 08:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF+QSSv8EZHK for ; Thu, 15 Jan 2009 08:12:53 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id B46C23A6969 for ; Thu, 15 Jan 2009 08:12:52 -0800 (PST) Received: by bwz14 with SMTP id 14so3615970bwz.13 for ; Thu, 15 Jan 2009 08:12:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dnk2nllk2oahqapKc3OMq3Vr5aibWXXpxak9riGT49c=; b=GNi0vf8wDt1XIpPLgOQG4au/spq35h/pONul9ogJm3Yu69PISTCcK0SplmdOYsGUoX dEY/+FS9JIPTVHrZ7K5PCF+QMTFy83RWXkChz4y5sBRRtJwhZopjDXS8dMH53gXTmKU5 t915PmfmxOwQ69C/BC2nc0b+wqSQ5DxqkWEGM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FZz1nPFQ9XugeWxudi+bOfnH059E3z4gdHYU00cs+SSPbi5z83uystAT+Bh7ANTgDl 1SS/rj7uDMnL2E6bsr6MlApagkYt0xdFbegp2qBJI6BOWfeeKNe9UGUcZa2+WH2eE2eY Sm+tHbAndtGYznJNOM8nkE2JY9y2H/j8ra5CE= MIME-Version: 1.0 Received: by 10.103.172.9 with SMTP id z9mr727498muo.109.1232035955619; Thu, 15 Jan 2009 08:12:35 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Jan 2009 16:12:35 +0000 Message-ID: From: George Tsirtsis To: Hesham Soliman Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I would remove the TLV completely. George On Thu, Jan 15, 2009 at 2:16 PM, Hesham Soliman wrote: > > > > On 16/01/09 1:13 AM, "George Tsirtsis" wrote: > >> On Thu, Jan 15, 2009 at 2:06 PM, Hesham Soliman >> wrote: >>> Pasi mentioned in the first paragraph that he " would strongly suggest >>> moving the whole TLV header text to the separate GRE document." >>> >> >> GT> This makes sense to me. >> >>> This is different from keeping the TLV header and removing the assignment of >>> GRE values. >> >> GT> I am still trying to understand what this means in practice. If >> you keep the TLV header and remove the GRE assigned value then the >> draft will NOT have any valid Type values for the TLV header. What is >> an implementation supposed to do with that? > > => Absolutely nothing until a number is assigned in another spec. > >> >>> Two very different approaches. It's not clear to me which one >>> you are asking for. >>> >> >> GT> If you can clarify the above I will tell you :-) > > => Hope this helps :) > > Hesham > >> >>> Hesham >>> >>> >>> On 16/01/09 1:02 AM, "George Tsirtsis" wrote: >>> >>>> How are they different? Maybe I am missing something. The only type >>>> value defined currently on the TLV is for GRE. If you remove the GRE >>>> value, what is the TLV for? >>>> >>>> George >>>> >>>> On Thu, Jan 15, 2009 at 1:51 PM, Hesham Soliman >>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> I think what Pasi suggests makes sense and will make things easier for >>>>>> whoever defines GRE support. >>>>> >>>>> => So are you agreeing with removing the TLV completely or with simply >>>>> removing the assignment of the GRE? They're two different things. >>>>> >>>>> Hesham >>>>> >>>>>> >>>>>> Not assigning a number for the TLV essentially means that the TLV >>>>>> header for GRE is undefined and thus nothing needs to be said about >>>>>> it. The whole thing can then be defined in a different spec as needed. >>>>>> >>>>>> Regards >>>>>> George >>>>>> >>>>>> On Thu, Jan 15, 2009 at 1:24 PM, Hesham Soliman >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> I would strongly suggest moving the whole TLV header text to the >>>>>>>> separate GRE document. >>>>>>> >>>>>>> => Personally, as everyone on the list knows, I was always against >>>>>>> including >>>>>>> this in the draft, I think it's a really bad idea, but obviously it's not >>>>>>> my >>>>>>> decision. So let's see what people say. I do agree with this suggestion. >>>>>>> >>>>>>>> >>>>>>>> In particular, if you assign a number for GRE in this document, >>>>>>>> you either need to describe how it works here, or have a normative >>>>>>>> reference to the NETLMM spec. >>>>>>> >>>>>>> => My suggestion below was not to assign any numbers in the draft. It was >>>>>>> simply to have the TLV header unassigned and let someone else request the >>>>>>> assignment and describe how it's used. My ideal preference is the one >>>>>>> above >>>>>>> (remove it completely) but the suggestion below was a compromise to speed >>>>>>> things up. >>>>>>> >>>>>>> Hesham >>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Pasi >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>> Sent: 14 January, 2009 14:23 >>>>>>>>> To: mext@ietf.org >>>>>>>>> Cc: Eronen Pasi (Nokia-NRC/Helsinki) >>>>>>>>> Subject: GRE support in DSMIPv6 - AD review >>>>>>>>> >>>>>>>>> Folks, >>>>>>>>> >>>>>>>>> Part of Pasi's review for DSMIPv6 was a comment on the lack of >>>>>>>>> specification for GRE support in the spec. He said it was vastly >>>>>>>>> under-specified, no details on the tunnelling, setting of different >>>>>>>>> parts of the GRE header ...etc. >>>>>>>>> >>>>>>>>> I suggested that we don't explicitly mention GRE in the spec but we >>>>>>>>> keep the TLV tunnelling format and reserve the numbers for NETLMM to >>>>>>>>> specify exactly how it will be used in a separate document. I think >>>>>>>>> you would agree that this is largely driven by NETLMM needs and we >>>>>>>>> shouldn't specify the details in MEXT. Pasi was ok with that. >>>>>>>>> >>>>>>>>> Please express your opinion on this soon because Pasi's comments are >>>>>>>>> the last comments for the draft and I want to handle them by Monday >>>>>>>>> at the latest. >>>>>>>>> >>>>>>>>> Please avoid discussing the merits of GRE....etc, the question is: >>>>>>>>> >>>>>>>>> Are there any objections to removing explicit references to GRE >>>>>>>>> while reserving the numbers in the TLV header for it to be specified >>>>>>>>> clearly in NETLMM? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Hesham >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 08:56:54 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC38728C250; Thu, 15 Jan 2009 08:56:54 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0900228C262 for ; Thu, 15 Jan 2009 08:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zb1pZu+n3sK5 for ; Thu, 15 Jan 2009 08:56:52 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 17E8128C250 for ; Thu, 15 Jan 2009 08:56:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,270,1231113600"; d="scan'208";a="230534512" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Jan 2009 16:56:37 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0FGubFC014344; Thu, 15 Jan 2009 08:56:37 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0FGubrA027620; Thu, 15 Jan 2009 16:56:37 GMT Date: Thu, 15 Jan 2009 08:56:37 -0800 (PST) From: Sri Gundavelli To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB7202E5DEBA@vaebe104.NOE.Nokia.com> Message-ID: References: <1696498986EFEC4D9153717DA325CB7202E5DEBA@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2603; t=1232038597; x=1232902597; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20GRE=20support=20in=20DSMIPv6=2 0-=20AD=20review |Sender:=20; bh=qcFogZ3x69SqR/Chhu9+Gv06qwxI7zzWQW+iy6A/3yg=; b=re4oHtmfDwUBYFh0M/MvdAFp+rmdDZu6E5r+TJ57NIoroV89TnZG0CeTsf vw/gvtM9WTbuUHWO079QVj7OCFXBVJ+MYUZeO8MkCWtTUSBpIpE2uIBhpxUA p+VXzllpc1zbb0ZF8tm3PRSce3wYd7Acxh/x3drDfr4qAWrRdLTFg=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Pasi, The specified GRE type value in the TLV header identifies the payload that follows. Wondering, what more needs to be specified. As the GRE format is specified in the respective specification, here the purpose of TLV is only payload classification, with a reference to that spec. Will a clarification help ? The GRE key exchange draft in NETLMM is about defining an option for GRE key exchange. It does not focus on the transport. Its only deals with the key negotiation. The IPv4 support document in NETLMM also does not focus on GRE transport, it falls back to the DSMIP spec with normative reference. So, if this is about a simple clarification, probably it can be fixed here ? Also, there were long discussion threads on this topic a year back. Regards Sri On Thu, 15 Jan 2009, Pasi.Eronen@nokia.com wrote: > Hesham, > > I would strongly suggest moving the whole TLV header text to the > separate GRE document. > > In particular, if you assign a number for GRE in this document, > you either need to describe how it works here, or have a normative > reference to the NETLMM spec. > > Best regards, > Pasi > >> -----Original Message----- >> From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: 14 January, 2009 14:23 >> To: mext@ietf.org >> Cc: Eronen Pasi (Nokia-NRC/Helsinki) >> Subject: GRE support in DSMIPv6 - AD review >> >> Folks, >> >> Part of Pasi's review for DSMIPv6 was a comment on the lack of >> specification for GRE support in the spec. He said it was vastly >> under-specified, no details on the tunnelling, setting of different >> parts of the GRE header ...etc. >> >> I suggested that we don't explicitly mention GRE in the spec but we >> keep the TLV tunnelling format and reserve the numbers for NETLMM to >> specify exactly how it will be used in a separate document. I think >> you would agree that this is largely driven by NETLMM needs and we >> shouldn't specify the details in MEXT. Pasi was ok with that. >> >> Please express your opinion on this soon because Pasi's comments are >> the last comments for the draft and I want to handle them by Monday >> at the latest. >> >> Please avoid discussing the merits of GRE....etc, the question is: >> >> Are there any objections to removing explicit references to GRE >> while reserving the numbers in the TLV header for it to be specified >> clearly in NETLMM? >> >> Thanks, >> >> Hesham > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 09:13:59 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DA7428C272; Thu, 15 Jan 2009 09:13:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94CF728C273 for ; Thu, 15 Jan 2009 09:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRkwaRCrRmGk for ; Thu, 15 Jan 2009 09:13:57 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7342D28C26A for ; Thu, 15 Jan 2009 09:13:57 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0FHDA5i017969; Thu, 15 Jan 2009 19:13:34 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 19:13:26 +0200 Received: from vaebe112.NOE.Nokia.com ([10.160.244.81]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 19:13:26 +0200 Received: from 172.19.60.146 ([172.19.60.146]) by vaebe112.NOE.Nokia.com ([10.160.244.81]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Jan 2009 17:13:25 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 15 Jan 2009 11:13:36 -0600 From: Basavaraj Patil To: ext Hesham Soliman , Pasi Eronen , Message-ID: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl2Qty8AAnKSyLlR0eCYUg0kSOoIQAxLqsAAANDudYAB/zjfg== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 15 Jan 2009 17:13:26.0026 (UTC) FILETIME=[93E876A0:01C97734] X-Nokia-AV: Clean Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I agree with the recommendation to moving the TLV header to a separate document (if somene feels there is a need for it at all). This spec is unneccesarily encumbered with the TLV header details and is better off without it. -Raj On 1/15/09 7:24 AM, "ext Hesham Soliman" wrote: > > >> I would strongly suggest moving the whole TLV header text to the >> separate GRE document. > > => Personally, as everyone on the list knows, I was always against including > this in the draft, I think it's a really bad idea, but obviously it's not my > decision. So let's see what people say. I do agree with this suggestion. > >> >> In particular, if you assign a number for GRE in this document, >> you either need to describe how it works here, or have a normative >> reference to the NETLMM spec. > > => My suggestion below was not to assign any numbers in the draft. It was > simply to have the TLV header unassigned and let someone else request the > assignment and describe how it's used. My ideal preference is the one above > (remove it completely) but the suggestion below was a compromise to speed > things up. > > Hesham > >> >> Best regards, >> Pasi >> >>> -----Original Message----- >>> From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: 14 January, 2009 14:23 >>> To: mext@ietf.org >>> Cc: Eronen Pasi (Nokia-NRC/Helsinki) >>> Subject: GRE support in DSMIPv6 - AD review >>> >>> Folks, >>> >>> Part of Pasi's review for DSMIPv6 was a comment on the lack of >>> specification for GRE support in the spec. He said it was vastly >>> under-specified, no details on the tunnelling, setting of different >>> parts of the GRE header ...etc. >>> >>> I suggested that we don't explicitly mention GRE in the spec but we >>> keep the TLV tunnelling format and reserve the numbers for NETLMM to >>> specify exactly how it will be used in a separate document. I think >>> you would agree that this is largely driven by NETLMM needs and we >>> shouldn't specify the details in MEXT. Pasi was ok with that. >>> >>> Please express your opinion on this soon because Pasi's comments are >>> the last comments for the draft and I want to handle them by Monday >>> at the latest. >>> >>> Please avoid discussing the merits of GRE....etc, the question is: >>> >>> Are there any objections to removing explicit references to GRE >>> while reserving the numbers in the TLV header for it to be specified >>> clearly in NETLMM? >>> >>> Thanks, >>> >>> Hesham > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 09:44:50 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6170E3A6A14; Thu, 15 Jan 2009 09:44:50 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D62E63A6A14 for ; Thu, 15 Jan 2009 09:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFZM0wR3BqNM for ; Thu, 15 Jan 2009 09:44:49 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A74A13A69C7 for ; Thu, 15 Jan 2009 09:44:48 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0FHiJml004139; Thu, 15 Jan 2009 19:44:24 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 19:44:24 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 19:44:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jan 2009 19:44:29 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB7202E5E262@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl3MkTHOIzGVF5pTa2UNugknfYVTwABTZ5w References: <1696498986EFEC4D9153717DA325CB7202E5DEBA@vaebe104.NOE.Nokia.com> From: To: X-OriginalArrivalTime: 15 Jan 2009 17:44:23.0092 (UTC) FILETIME=[E6CE3F40:01C97738] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Sri, Adding GRE support to Mobile IPv6 needs a bit more than a pointer to the GRE spec. Quoting from the IESG ballot: - There's no text describing how GRE tunneling is actually done; for example, how the various parts of GRE header are set/used in the context of Mobile IPv6, how that interacts with RFC 4877, etc. Also, the whole 'T' bit is problematic; from the IESG ballot: - Apparently the 'T' bit does means only that MN supports the general TLV format; it may not support any of the specific TLV types, such as GRE (and new ones may be defined in the future). How this is supposed to work? Best regards, Pasi > -----Original Message----- > From: ext Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: 15 January, 2009 18:57 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: hesham@elevatemobile.com; mext@ietf.org > Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review > > Hi Pasi, > > The specified GRE type value in the TLV header identifies the > payload that follows. Wondering, what more needs to be specified. > As the GRE format is specified in the respective specification, > here the purpose of TLV is only payload classification, with a > reference to that spec. Will a clarification help ? > > The GRE key exchange draft in NETLMM is about defining an option > for GRE key exchange. It does not focus on the transport. Its only > deals with the key negotiation. The IPv4 support document in NETLMM > also does not focus on GRE transport, it falls back to the DSMIP spec > with normative reference. > > So, if this is about a simple clarification, probably it can be fixed > here ? Also, there were long discussion threads on this topic a year > back. > > > Regards > Sri > > > On Thu, 15 Jan 2009, Pasi.Eronen@nokia.com wrote: > > > Hesham, > > > > I would strongly suggest moving the whole TLV header text to the > > separate GRE document. > > > > In particular, if you assign a number for GRE in this document, > > you either need to describe how it works here, or have a normative > > reference to the NETLMM spec. > > > > Best regards, > > Pasi > > > >> -----Original Message----- > >> From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] > >> Sent: 14 January, 2009 14:23 > >> To: mext@ietf.org > >> Cc: Eronen Pasi (Nokia-NRC/Helsinki) > >> Subject: GRE support in DSMIPv6 - AD review > >> > >> Folks, > >> > >> Part of Pasi's review for DSMIPv6 was a comment on the lack of > >> specification for GRE support in the spec. He said it was vastly > >> under-specified, no details on the tunnelling, setting of different > >> parts of the GRE header ...etc. > >> > >> I suggested that we don't explicitly mention GRE in the spec but we > >> keep the TLV tunnelling format and reserve the numbers for > NETLMM to > >> specify exactly how it will be used in a separate document. I think > >> you would agree that this is largely driven by NETLMM needs and we > >> shouldn't specify the details in MEXT. Pasi was ok with that. > >> > >> Please express your opinion on this soon because Pasi's > comments are > >> the last comments for the draft and I want to handle them by Monday > >> at the latest. > >> > >> Please avoid discussing the merits of GRE....etc, the question is: > >> > >> Are there any objections to removing explicit references to GRE > >> while reserving the numbers in the TLV header for it to be > specified > >> clearly in NETLMM? > >> > >> Thanks, > >> > >> Hesham > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 10:32:43 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B99BD28C266; Thu, 15 Jan 2009 10:32:43 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC4AF28C266 for ; Thu, 15 Jan 2009 10:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrXRZzT+ICmL for ; Thu, 15 Jan 2009 10:32:41 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 94D6228C1D9 for ; Thu, 15 Jan 2009 10:32:41 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jan 2009 13:32:17 -0500 Message-ID: In-Reply-To: <1696498986EFEC4D9153717DA325CB7202E5DEBA@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl2Qty8AAnKSyLlR0eCYUg0kSOoIQAxLqsAAA1z7DA= References: <1696498986EFEC4D9153717DA325CB7202E5DEBA@vaebe104.NOE.Nokia.com> From: "Vijay Devarapalli" To: , , Cc: Jari Arkko Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Pasi, Hesham, The TLV header was specified in the DS-MIPv6 document after rather a long and acrimonious debate on the former MIP6 mailing list. There were atleast two consensus calls that were run at that time. Anytime you have a UDP header with IPv4/IPv6/GRE header following it, you need the TLV header. At that time, there were folks arguing for using GRE encapsulation with MIPv6 also. PMIPv6 IPv4 support was not the only scenario for the TLV header. We are overturning that consensus now. Maybe folks who were arguing for the TLV header with DS-MIPv6, are either busy/not looked at this thread yet/or not on the MEXT mailing list/etc.. :) Moving the TLV header into a separate document at this point would impact draft-ietf-netlmm-pmip6-ipv4-support. I don't think the TLV header document can be standardized fast enough for draft-ietf-netlmm-pmip6-ipv4-support to advance. One option would be to move the TLV header and the text that describes how to negotiate it, to either draft-ietf-netlmm-pmip6-ipv4-support or draft-ietf-netlmm-grekey-option. My suggestion would be to leave the TLV header in the DS-MIPv6 document. Have some text that says the following. If UDP encapsulation is used with DS-MIPv6 port, there could be IPv4, IPv6, GRE or some other header that might follow the UDP header. If there is anything other than the IPv4 or IPv6 header, the TLV header would be required. The use of GRE or some other protocol after the TLV header is not specified and is out of scope in the DS-MIPv6 document. Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Pasi.Eronen@nokia.com > Sent: Thursday, January 15, 2009 3:54 AM > To: hesham@elevatemobile.com; mext@ietf.org > Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review > > Hesham, > > I would strongly suggest moving the whole TLV header text to the > separate GRE document. > > In particular, if you assign a number for GRE in this document, > you either need to describe how it works here, or have a normative > reference to the NETLMM spec. > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] > > Sent: 14 January, 2009 14:23 > > To: mext@ietf.org > > Cc: Eronen Pasi (Nokia-NRC/Helsinki) > > Subject: GRE support in DSMIPv6 - AD review > > > > Folks, > > > > Part of Pasi's review for DSMIPv6 was a comment on the lack of > > specification for GRE support in the spec. He said it was vastly > > under-specified, no details on the tunnelling, setting of different > > parts of the GRE header ...etc. > > > > I suggested that we don't explicitly mention GRE in the spec but we > > keep the TLV tunnelling format and reserve the numbers for NETLMM to > > specify exactly how it will be used in a separate document. I think > > you would agree that this is largely driven by NETLMM needs and we > > shouldn't specify the details in MEXT. Pasi was ok with that. > > > > Please express your opinion on this soon because Pasi's comments are > > the last comments for the draft and I want to handle them by Monday > > at the latest. > > > > Please avoid discussing the merits of GRE....etc, the question is: > > > > Are there any objections to removing explicit references to GRE > > while reserving the numbers in the TLV header for it to be specified > > clearly in NETLMM? > > > > Thanks, > > > > Hesham > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 10:37:49 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62DAB3A68A1; Thu, 15 Jan 2009 10:37:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14B03A68A1 for ; Thu, 15 Jan 2009 10:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inX67M5-TJVn for ; Thu, 15 Jan 2009 10:37:47 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id D97FE3A6881 for ; Thu, 15 Jan 2009 10:37:46 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jan 2009 13:37:26 -0500 Message-ID: In-Reply-To: <1696498986EFEC4D9153717DA325CB7202E5E262@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl3MkTHOIzGVF5pTa2UNugknfYVTwABTZ5wAAIa5oA= References: <1696498986EFEC4D9153717DA325CB7202E5DEBA@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB7202E5E262@vaebe104.NOE.Nokia.com> From: "Vijay Devarapalli" To: , Cc: mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Pasi, > Also, the whole 'T' bit is problematic; from the IESG ballot: > > - Apparently the 'T' bit does means only that MN supports the > general TLV format; it may not support any of the specific TLV > types, such as GRE (and new ones may be defined in the future). > How this is supposed to work? I don't see an issue. Today we have three types. IPv4, IPv6 and GRE. IPv4 and IPv6 can be used without having to negotiate anything or figure out if the other end has support for IPv4 and IPv6. For GRE, I expect a separate document that adds some sort of GRE encapsulation option to the binding update (similar to what is specified in draft-ietf-netlmm-grekey-option-02). For other types we might define in the future, there would be some sort of mobility option in the binding update that tells the HA what the mobile node wants to use when negotiating the TLV header. Vijay > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: 15 January, 2009 18:57 > > To: Eronen Pasi (Nokia-NRC/Helsinki) > > Cc: hesham@elevatemobile.com; mext@ietf.org > > Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review > > > > Hi Pasi, > > > > The specified GRE type value in the TLV header identifies the > > payload that follows. Wondering, what more needs to be specified. > > As the GRE format is specified in the respective specification, > > here the purpose of TLV is only payload classification, with a > > reference to that spec. Will a clarification help ? > > > > The GRE key exchange draft in NETLMM is about defining an option > > for GRE key exchange. It does not focus on the transport. Its only > > deals with the key negotiation. The IPv4 support document in NETLMM > > also does not focus on GRE transport, it falls back to the > DSMIP spec > > with normative reference. > > > > So, if this is about a simple clarification, probably it > can be fixed > > here ? Also, there were long discussion threads on this topic a year > > back. > > > > > > Regards > > Sri > > > > > > On Thu, 15 Jan 2009, Pasi.Eronen@nokia.com wrote: > > > > > Hesham, > > > > > > I would strongly suggest moving the whole TLV header text to the > > > separate GRE document. > > > > > > In particular, if you assign a number for GRE in this document, > > > you either need to describe how it works here, or have a normative > > > reference to the NETLMM spec. > > > > > > Best regards, > > > Pasi > > > > > >> -----Original Message----- > > >> From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] > > >> Sent: 14 January, 2009 14:23 > > >> To: mext@ietf.org > > >> Cc: Eronen Pasi (Nokia-NRC/Helsinki) > > >> Subject: GRE support in DSMIPv6 - AD review > > >> > > >> Folks, > > >> > > >> Part of Pasi's review for DSMIPv6 was a comment on the lack of > > >> specification for GRE support in the spec. He said it was vastly > > >> under-specified, no details on the tunnelling, setting > of different > > >> parts of the GRE header ...etc. > > >> > > >> I suggested that we don't explicitly mention GRE in the > spec but we > > >> keep the TLV tunnelling format and reserve the numbers for > > NETLMM to > > >> specify exactly how it will be used in a separate > document. I think > > >> you would agree that this is largely driven by NETLMM > needs and we > > >> shouldn't specify the details in MEXT. Pasi was ok with that. > > >> > > >> Please express your opinion on this soon because Pasi's > > comments are > > >> the last comments for the draft and I want to handle > them by Monday > > >> at the latest. > > >> > > >> Please avoid discussing the merits of GRE....etc, the > question is: > > >> > > >> Are there any objections to removing explicit references to GRE > > >> while reserving the numbers in the TLV header for it to be > > specified > > >> clearly in NETLMM? > > >> > > >> Thanks, > > >> > > >> Hesham > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 11:58:18 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D24B3A69F6; Thu, 15 Jan 2009 11:58:18 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327F83A69F6 for ; Thu, 15 Jan 2009 11:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGDYRR8q245m for ; Thu, 15 Jan 2009 11:58:16 -0800 (PST) Received: from web111406.mail.gq1.yahoo.com (web111406.mail.gq1.yahoo.com [67.195.15.162]) by core3.amsl.com (Postfix) with SMTP id F3D203A6891 for ; Thu, 15 Jan 2009 11:58:15 -0800 (PST) Received: (qmail 77591 invoked by uid 60001); 15 Jan 2009 19:58:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=0RX5hCqZp0Na+WTjMhvHX29nRmGxLIO0/t4bfXJlb7RZCh423FiM40SwiU888Hg9Cu+pKEIZoDxHOyXMPcaQt6lQ3US4RRdsq1gvUvCMunKmGL8s1aLwgojx/oFF+Qe20vUsHYDSysl/pdET7Cl3LXKbj0inym7AnQPkgy071gQ=; X-YMail-OSG: fuaT1CgVM1n1KBRkkdSuAA9ChxVb.1LGl767DwxdZPxZLcLaLGPtCJ9gDTPz8deW_dCBkBFMlGsrMafw7TuBCQdjE4zY755ZP_u_OvahQEnTL.lobz2ZwGPSuxaaa3DUX0EkK2jEJcMb8e9EfExXycS.pGOAONS6Eamy9X7sZcBYIwtsx263liZJDESbG1m3qtkQuRhoIUWhjLM- Received: from [206.16.17.212] by web111406.mail.gq1.yahoo.com via HTTP; Thu, 15 Jan 2009 11:58:00 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <1696498986EFEC4D9153717DA325CB7202E5DEBA@vaebe104.NOE.Nokia.com> Date: Thu, 15 Jan 2009 11:58:00 -0800 (PST) From: Behcet Sarikaya To: Vijay Devarapalli , Pasi.Eronen@nokia.com, hesham@elevatemobile.com, mext@ietf.org MIME-Version: 1.0 Message-ID: <18921.76715.qm@web111406.mail.gq1.yahoo.com> Cc: Jari Arkko Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0561298679==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0561298679== Content-Type: multipart/alternative; boundary="0-1774728339-1232049480=:76715" --0-1774728339-1232049480=:76715 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Vijay,=0A=A0 I am sure you are right on this historic note. My concern i= s that in the draft GRE occurs only once as a possible value in the type fi= eld. If we are going to keep it maybe some more text is needed.=0A=0ARegard= s,=0A=0ABehcet=0A=0A=0A=0A=0A________________________________=0AFrom: Vijay= Devarapalli =0ATo: Pasi.Eronen@nokia.com; hesham@eleva= temobile.com; mext@ietf.org=0ACc: Jari Arkko =0ASent:= Thursday, January 15, 2009 12:32:17 PM=0ASubject: Re: [MEXT] GRE support i= n DSMIPv6 - AD review=0A=0AHi Pasi, Hesham,=0A=0AThe TLV header was specifi= ed in the DS-MIPv6 document after rather a=0Along and acrimonious debate on= the former MIP6 mailing list. There were=0Aatleast two consensus calls tha= t were run at that time. Anytime you have=0Aa UDP header with IPv4/IPv6/GRE= header following it, you need the TLV=0Aheader. At that time, there were f= olks arguing for using GRE=0Aencapsulation with MIPv6 also. PMIPv6 IPv4 sup= port was not the only=0Ascenario for the TLV header. We are overturning tha= t consensus now.=0AMaybe folks who were arguing for the TLV header with DS-= MIPv6, are=0Aeither busy/not looked at this thread yet/or not on the MEXT m= ailing=0Alist/etc.. :)=0A=0AMoving the TLV header into a separate document = at this point would=0Aimpact draft-ietf-netlmm-pmip6-ipv4-support. I don't = think the TLV=0Aheader document can be standardized fast enough for=0Adraft= -ietf-netlmm-pmip6-ipv4-support to advance. One option would be to=0Amove t= he TLV header and the text that describes how to negotiate it, to=0Aeither = draft-ietf-netlmm-pmip6-ipv4-support or=0Adraft-ietf-netlmm-grekey-option. = =0A=0AMy suggestion would be to leave the TLV header in the DS-MIPv6 docume= nt.=0AHave some text that says the following. If UDP encapsulation is used= =0Awith DS-MIPv6 port, there could be IPv4, IPv6, GRE or some other header= =0Athat might follow the UDP header. If there is anything other than the=0A= IPv4 or IPv6 header, the TLV header would be required. The use of GRE or=0A= some other protocol after the TLV header is not specified and is out of=0As= cope in the DS-MIPv6 document.=0A=0AVijay =0A=0A=0A> -----Original Message-= ----=0A> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On =0A>= Behalf Of Pasi.Eronen@nokia.com=0A> Sent: Thursday, January 15, 2009 3:54 = AM=0A> To: hesham@elevatemobile.com; mext@ietf.org=0A> Subject: Re: [MEXT] = GRE support in DSMIPv6 - AD review=0A> =0A> Hesham,=0A> =0A> I would strong= ly suggest moving the whole TLV header text to the=0A> separate GRE documen= t.=0A> =0A> In particular, if you assign a number for GRE in this document,= =0A> you either need to describe how it works here, or have a normative=0A>= reference to the NETLMM spec.=0A> =0A> Best regards,=0A> Pasi=0A> =0A> > -= ----Original Message-----=0A> > From: ext Hesham Soliman [mailto:hesham@ele= vatemobile.com] =0A> > Sent: 14 January, 2009 14:23=0A> > To: mext@ietf.org= =0A> > Cc: Eronen Pasi (Nokia-NRC/Helsinki)=0A> > Subject: GRE support in D= SMIPv6 - AD review=0A> > =0A> > Folks, =0A> > =0A> > Part of Pasi's review = for DSMIPv6 was a comment on the lack of=0A> > specification for GRE suppor= t in the spec. He said it was vastly=0A> > under-specified, no details on t= he tunnelling, setting of different=0A> > parts of the GRE header ...etc.= =0A> > =0A> > I suggested that we don't explicitly mention GRE in the spec = but we=0A> > keep the TLV tunnelling format and reserve the numbers for NET= LMM to=0A> > specify exactly how it will be used in a separate document. I = think=0A> > you would agree that this is largely driven by NETLMM needs and= we=0A> > shouldn't specify the details in MEXT. Pasi was ok with that.=0A>= > =0A> > Please express your opinion on this soon because Pasi's comments = are=0A> > the last comments for the draft and I want to handle them by Mond= ay=0A> > at the latest.=0A> > =0A> > Please avoid discussing the merits of = GRE....etc, the question is:=0A> > =0A> > Are there any objections to remov= ing explicit references to GRE=0A> > while reserving the numbers in the TLV= header for it to be specified=0A> > clearly in NETLMM?=0A> > =0A> > Thanks= ,=0A> > =0A> > Hesham=0A> _______________________________________________= =0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.ietf.org/mailman/l= istinfo/mext=0A> =0A_______________________________________________=0AMEXT = mailing list=0AMEXT@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/mext= =0A=0A=0A=0A --0-1774728339-1232049480=:76715 Content-Type: text/html; charset=us-ascii

Hi Vijay,
  I am sure you are right on this historic note. My concern is that in the draft GRE occurs only once as a possible value in the type field. If we are going to keep it maybe some more text is needed.
 
Regards,
 
Behcet

From: Vijay Devarapalli <vijay@wichorus.com>
To: Pasi.Eronen@nokia.com; hesham@elevatemobile.com; mext@ietf.org
Cc: Jari Arkko <jari.arkko@piuha.net>
Sent: Thursday, January 15, 2009 12:32:17 PM
Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review

Hi Pasi, Hesham,

The TLV header was specified in the DS-MIPv6 document after rather a
long and acrimonious debate on the former MIP6 mailing list. There were
atleast two consensus calls that were run at that time. Anytime you have
a UDP header with IPv4/IPv6/GRE header following it, you need the TLV
header. At that time, there were folks arguing for using GRE
encapsulation with MIPv6 also. PMIPv6 IPv4 support was not the only
scenario for the TLV header. We are overturning that consensus now.
Maybe folks who were arguing for the TLV header with DS-MIPv6, are
either busy/not looked at this thread yet/or not on the MEXT mailing
list/etc.. :)

Moving the TLV header into a separate document at this point would
impact draft-ietf-netlmm-pmip6-ipv4-support. I don't think the TLV
header document can be standardized fast enough for
draft-ietf-netlmm-pmip6-ipv4-support to advance. One option would be to
move the TLV header and the text that describes how to negotiate it, to
either draft-ietf-netlmm-pmip6-ipv4-support or
draft-ietf-netlmm-grekey-option.

My suggestion would be to leave the TLV header in the DS-MIPv6 document.
Have some text that says the following. If UDP encapsulation is used
with DS-MIPv6 port, there could be IPv4, IPv6, GRE or some other header
that might follow the UDP header. If there is anything other than the
IPv4 or IPv6 header, the TLV header would be required. The use of GRE or
some other protocol after the TLV header is not specified and is out of
scope in the DS-MIPv6 document.

Vijay


> -----Original Message-----
> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On
> Behalf Of Pasi.Eronen@nokia.com
> Sent: Thursday, January 15, 2009 3:54 AM
> To: hesham@elevatemobile.com; mext@ietf.org
> Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review
>
> Hesham,
>
> I would strongly suggest moving the whole TLV header text to the
> separate GRE document.
>
> In particular, if you assign a number for GRE in this document,
> you either need to describe how it works here, or have a normative
> reference to the NETLMM spec.
>
> Best regards,
> Pasi
>
> > -----Original Message-----
> > From: ext Hesham Soliman [mailto:hesham@elevatemobile.com]
> > Sent: 14 January, 2009 14:23
> > To: mext@ietf.org
> > Cc: Eronen Pasi (Nokia-NRC/Helsinki)
> > Subject: GRE support in DSMIPv6 - AD review
> >
> > Folks,
> >
> > Part of Pasi's review for DSMIPv6 was a comment on the lack of
> > specification for GRE support in the spec. He said it was vastly
> > under-specified, no details on the tunnelling, setting of different
> > parts of the GRE header ...etc.
> >
> > I suggested that we don't explicitly mention GRE in the spec but we
> > keep the TLV tunnelling format and reserve the numbers for NETLMM to
> > specify exactly how it will be used in a separate document. I think
> > you would agree that this is largely driven by NETLMM needs and we
> > shouldn't specify the details in MEXT. Pasi was ok with that.
> >
> > Please express your opinion on this soon because Pasi's comments are
> > the last comments for the draft and I want to handle them by Monday
> > at the latest.
> >
> > Please avoid discussing the merits of GRE....etc, the question is:
> >
> > Are there any objections to removing explicit references to GRE
> > while reserving the numbers in the TLV header for it to be specified
> > clearly in NETLMM?
> >
> > Thanks,
> >
> > Hesham
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

--0-1774728339-1232049480=:76715-- --===============0561298679== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0561298679==-- From mext-bounces@ietf.org Thu Jan 15 12:12:48 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A14A3A68C7; Thu, 15 Jan 2009 12:12:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7053A68C7 for ; Thu, 15 Jan 2009 12:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUGCKf0HkfPo for ; Thu, 15 Jan 2009 12:12:45 -0800 (PST) Received: from av12-1-sn2.hy.skanova.net (av12-1-sn2.hy.skanova.net [81.228.8.185]) by core3.amsl.com (Postfix) with ESMTP id 83BF13A68B6 for ; Thu, 15 Jan 2009 12:12:45 -0800 (PST) Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id 8AA7D3801F; Thu, 15 Jan 2009 21:12:29 +0100 (CET) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id 7038337FF5; Thu, 15 Jan 2009 21:12:29 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 4C6EA37E49; Thu, 15 Jan 2009 21:12:28 +0100 (CET) Received: from localhost ([127.0.0.1]:42656 helo=chardonnay.local) by shiraz.levkowetz.com with esmtp (Exim 4.69) (envelope-from ) id 1LNYZn-0008L7-J6; Thu, 15 Jan 2009 21:12:27 +0100 Message-ID: <496F98AA.7030601@levkowetz.com> Date: Thu, 15 Jan 2009 21:12:26 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Vijay Devarapalli References: <1696498986EFEC4D9153717DA325CB7202E5DEBA@vaebe104.NOE.Nokia.com> In-Reply-To: X-Enigmail-Version: 0.95.7 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: vijay@wichorus.com, Pasi.Eronen@nokia.com, hesham@elevatemobile.com, mext@ietf.org, jari.arkko@piuha.net, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false Cc: Jari Arkko , mext@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, On 2009-01-15 19:32 Vijay Devarapalli said the following: > Hi Pasi, Hesham, > > The TLV header was specified in the DS-MIPv6 document after rather a > long and acrimonious debate on the former MIP6 mailing list. There were > atleast two consensus calls that were run at that time. Anytime you have > a UDP header with IPv4/IPv6/GRE header following it, you need the TLV > header. At that time, there were folks arguing for using GRE > encapsulation with MIPv6 also. PMIPv6 IPv4 support was not the only > scenario for the TLV header. We are overturning that consensus now. > Maybe folks who were arguing for the TLV header with DS-MIPv6, are > either busy/not looked at this thread yet/or not on the MEXT mailing > list/etc.. :) > > Moving the TLV header into a separate document at this point would > impact draft-ietf-netlmm-pmip6-ipv4-support. I don't think the TLV > header document can be standardized fast enough for > draft-ietf-netlmm-pmip6-ipv4-support to advance. One option would be to > move the TLV header and the text that describes how to negotiate it, to > either draft-ietf-netlmm-pmip6-ipv4-support or > draft-ietf-netlmm-grekey-option. > > My suggestion would be to leave the TLV header in the DS-MIPv6 document. > Have some text that says the following. If UDP encapsulation is used > with DS-MIPv6 port, there could be IPv4, IPv6, GRE or some other header > that might follow the UDP header. If there is anything other than the > IPv4 or IPv6 header, the TLV header would be required. The use of GRE or > some other protocol after the TLV header is not specified and is out of > scope in the DS-MIPv6 document. That would work for me. I'd very much like to see the TLV header itself kept; the reason is that if something else (GRE or whatever) than an IP header follows the UDP header, there isn't a clear and obvious way of dynamically distinguishing *what* that something else is, unless the TLV header is there. Ripping it out completely would leave the specification less ready for extension than otherwise, which would be unfortunate if we already know that there are needs for extension. One thing in the -05 and -06 drafts which surprised me when looking at them now was the value assignments for the TLV type field -- I'd expected the use of already-defined protocol numbers here, in a similar manner to what's in Section 3.3 of RFC 3519, rather than a new registry. But there are maybe things I've forgotten from our earlier discussion which makes a new type number space necessary. Henrik > > Vijay > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Pasi.Eronen@nokia.com >> Sent: Thursday, January 15, 2009 3:54 AM >> To: hesham@elevatemobile.com; mext@ietf.org >> Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review >> >> Hesham, >> >> I would strongly suggest moving the whole TLV header text to the >> separate GRE document. >> >> In particular, if you assign a number for GRE in this document, >> you either need to describe how it works here, or have a normative >> reference to the NETLMM spec. >> >> Best regards, >> Pasi >> >>> -----Original Message----- >>> From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: 14 January, 2009 14:23 >>> To: mext@ietf.org >>> Cc: Eronen Pasi (Nokia-NRC/Helsinki) >>> Subject: GRE support in DSMIPv6 - AD review >>> >>> Folks, >>> >>> Part of Pasi's review for DSMIPv6 was a comment on the lack of >>> specification for GRE support in the spec. He said it was vastly >>> under-specified, no details on the tunnelling, setting of different >>> parts of the GRE header ...etc. >>> >>> I suggested that we don't explicitly mention GRE in the spec but we >>> keep the TLV tunnelling format and reserve the numbers for NETLMM to >>> specify exactly how it will be used in a separate document. I think >>> you would agree that this is largely driven by NETLMM needs and we >>> shouldn't specify the details in MEXT. Pasi was ok with that. >>> >>> Please express your opinion on this soon because Pasi's comments are >>> the last comments for the draft and I want to handle them by Monday >>> at the latest. >>> >>> Please avoid discussing the merits of GRE....etc, the question is: >>> >>> Are there any objections to removing explicit references to GRE >>> while reserving the numbers in the TLV header for it to be specified >>> clearly in NETLMM? >>> >>> Thanks, >>> >>> Hesham >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 13:00:01 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92EC03A68E4; Thu, 15 Jan 2009 13:00:01 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EBED3A68E4 for ; Thu, 15 Jan 2009 13:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbuve6Q7YvcD for ; Thu, 15 Jan 2009 12:59:59 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 7904F3A6842 for ; Thu, 15 Jan 2009 12:59:59 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0FKxCqB029932; Thu, 15 Jan 2009 22:59:36 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 22:59:16 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 22:59:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jan 2009 22:59:13 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB7202E5E2CE@vaebe104.NOE.Nokia.com> In-Reply-To: <496F98AA.7030601@levkowetz.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl3TZpE9S1yJzu3ROWnl2KCleJ9egABLkUA References: <1696498986EFEC4D9153717DA325CB7202E5DEBA@vaebe104.NOE.Nokia.com> <496F98AA.7030601@levkowetz.com> From: To: , X-OriginalArrivalTime: 15 Jan 2009 20:59:15.0563 (UTC) FILETIME=[200FBBB0:01C97754] X-Nokia-AV: Clean Cc: mext@ietf.org, jari.arkko@piuha.net Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Henrik Levkowetz wrote: > That would work for me. I'd very much like to see the TLV header > itself kept; the reason is that if something else (GRE or whatever) > than an IP header follows the UDP header, there isn't a clear and > obvious way of dynamically distinguishing *what* that something else > is, unless the TLV header is there. Ripping it out completely would > leave the specification less ready for extension than otherwise, > which would be unfortunate if we already know that there are needs > for extension. Right.. however, since the future extensions will include a negotiation mechanism (some bit somewhere) to say "I support this extension FOOBAR (which implies using TLV header)", do we need a separate "I support TLV header" bit in this spec? (Since if you don't support any of the extensions, sending normal IPv4/IPv6 using the TLV format seems a bit strange.) BTW -- currently, the spec says that the packet has a *single* TLV header (not a sequence of them), so the length field isn't actually used for anything -- so it's really TV header :) > One thing in the -05 and -06 drafts which surprised me when looking > at them now was the value assignments for the TLV type field -- I'd > expected the use of already-defined protocol numbers here, in a > similar manner to what's in Section 3.3 of RFC 3519, rather than a > new registry. But there are maybe things I've forgotten from our > earlier discussion which makes a new type number space necessary. Even when TLV header is negotiated, some packets (at least BUs) are sent without the TLV header (the IP header starts immediately after UDP header). Currently, the TLV Type field is just 4 bits (to align it with the IP version number field), and obviously values 4 and 6 won't work (for some reason, the current spec also forbids values 2, 3, 5, and 7..15 -- I can't see why that couldn't be relaxed...). If it was 8 bits, at least TLV types 0x40..0x4f and 0x60..0x6f would need to be reserved (and that would complicate using already-defined protocol numbers). Best regards, Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 15 13:51:00 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008713A6783; Thu, 15 Jan 2009 13:51:00 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 378EE28C0F8 for ; Thu, 15 Jan 2009 13:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-nxODlms3JR for ; Thu, 15 Jan 2009 13:50:57 -0800 (PST) Received: from av9-2-sn2.hy.skanova.net (av9-2-sn2.hy.skanova.net [81.228.8.180]) by core3.amsl.com (Postfix) with ESMTP id F3F8F3A6405 for ; Thu, 15 Jan 2009 13:50:56 -0800 (PST) Received: by av9-2-sn2.hy.skanova.net (Postfix, from userid 502) id 4E684381EF; Thu, 15 Jan 2009 22:50:41 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-2-sn2.hy.skanova.net (Postfix) with ESMTP id 31BB937FB5; Thu, 15 Jan 2009 22:50:41 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id B011937E44; Thu, 15 Jan 2009 22:50:39 +0100 (CET) Received: from localhost ([127.0.0.1]:47233 helo=chardonnay.local) by shiraz.levkowetz.com with esmtp (Exim 4.69) (envelope-from ) id 1LNa6p-0004Mc-92; Thu, 15 Jan 2009 22:50:39 +0100 Message-ID: <496FAFA7.2000706@levkowetz.com> Date: Thu, 15 Jan 2009 22:50:31 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <1696498986EFEC4D9153717DA325CB7202E5DEBA@vaebe104.NOE.Nokia.com> <496F98AA.7030601@levkowetz.com> <1696498986EFEC4D9153717DA325CB7202E5E2CE@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB7202E5E2CE@vaebe104.NOE.Nokia.com> X-Enigmail-Version: 0.95.7 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Pasi.Eronen@nokia.com, vijay@wichorus.com, hesham@elevatemobile.com, mext@ietf.org, jari.arkko@piuha.net, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false Cc: mext@ietf.org, jari.arkko@piuha.net Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0531178598==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0531178598== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFB0B0E8C9903BFBEF7F6BB5E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFB0B0E8C9903BFBEF7F6BB5E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Pasi, On 2009-01-15 21:59 Pasi.Eronen@nokia.com said the following: > Henrik Levkowetz wrote: >=20 >> That would work for me. I'd very much like to see the TLV header >> itself kept; the reason is that if something else (GRE or whatever) >> than an IP header follows the UDP header, there isn't a clear and >> obvious way of dynamically distinguishing *what* that something else >> is, unless the TLV header is there. Ripping it out completely would >> leave the specification less ready for extension than otherwise, >> which would be unfortunate if we already know that there are needs >> for extension. >=20 > Right.. however, since the future extensions will include a > negotiation mechanism (some bit somewhere) to say "I support this > extension FOOBAR (which implies using TLV header)", do we need=20 > a separate "I support TLV header" bit in this spec? >=20 > (Since if you don't support any of the extensions, sending normal > IPv4/IPv6 using the TLV format seems a bit strange.) Agreed on not needing the TLV for normal IPv4/IPv6. Not sure if that means that it's a good idea to remove the TLV support bit, if we keep the TLV. > BTW -- currently, the spec says that the packet has a *single* TLV > header (not a sequence of them), so the length field isn't > actually used for anything -- so it's really TV header :) Agreed. In 3519, the extra header has a different layout and no length field, which is anyway needed if one wants to use it as a 'next header' header. More below. >> One thing in the -05 and -06 drafts which surprised me when looking >> at them now was the value assignments for the TLV type field -- I'd >> expected the use of already-defined protocol numbers here, in a >> similar manner to what's in Section 3.3 of RFC 3519, rather than a >> new registry. But there are maybe things I've forgotten from our >> earlier discussion which makes a new type number space necessary. >=20 > Even when TLV header is negotiated, some packets (at least BUs) are > sent without the TLV header (the IP header starts immediately after > UDP header). Agreed. > Currently, the TLV Type field is just 4 bits (to align it with the IP > version number field), and obviously values 4 and 6 won't work > (for some reason, the current spec also forbids values 2, 3, 5, > and 7..15 -- I can't see why that couldn't be relaxed...). Ah. I see the TLV header layout has changed. In order to do something similar to 3519, I imagine it looking something like the following (which seems to be somewhat in alignment with what you suggest below): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Res. | Next Header | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type This field is always 0 (zero) and distinguishes the TLV header from the IPv4 and IPv6 headers. > If it was 8 bits, at least TLV types 0x40..0x4f and 0x60..0x6f would=20 > need to be reserved (and that would complicate using already-defined=20 > protocol numbers). Or we separate out the type and value ('next header', above) parts, which removes the need to reserve some ranges). But maybe I'm off in the woods here -- I haven't followed any recent discussions on the TLV format, so I'm not aware of the background for the layout in the current spec. Best, Henrik --------------enigFB0B0E8C9903BFBEF7F6BB5E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAklvr64ACgkQeVhrtTJkXCOUUgCg3LJDLoypD3e0KJFdKJoDh0g/ 0F4AoLYZrdLgw38COScNfDsWO2obUtTB =Y77H -----END PGP SIGNATURE----- --------------enigFB0B0E8C9903BFBEF7F6BB5E-- --===============0531178598== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0531178598==-- From mext-bounces@ietf.org Thu Jan 15 17:00:49 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31703A6842; Thu, 15 Jan 2009 17:00:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628013A6842 for ; Thu, 15 Jan 2009 17:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yqUNZHU6Lq0 for ; Thu, 15 Jan 2009 17:00:47 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 2D6E93A63EC for ; Thu, 15 Jan 2009 17:00:46 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LNd4P-0005sn-57; Fri, 16 Jan 2009 12:00:21 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 16 Jan 2009 12:00:13 +1100 From: Hesham Soliman To: Vijay Devarapalli , , Message-ID: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl2Qty8AAnKSyLlR0eCYUg0kSOoIQAxLqsAAA1z7DAADhiRqQ== In-Reply-To: Mime-version: 1.0 Cc: Jari Arkko Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > Hi Pasi, Hesham, > > The TLV header was specified in the DS-MIPv6 document after rather a > long and acrimonious debate on the former MIP6 mailing list. There were > atleast two consensus calls that were run at that time. => I don't realy want to get into that, we all know there was no concensus and we had to teleconference to come up with the existing method Anytime you have > a UDP header with IPv4/IPv6/GRE header following it, you need the TLV > header. At that time, there were folks arguing for using GRE > encapsulation with MIPv6 also. PMIPv6 IPv4 support was not the only > scenario for the TLV header. We are overturning that consensus now. > Maybe folks who were arguing for the TLV header with DS-MIPv6, are > either busy/not looked at this thread yet/or not on the MEXT mailing > list/etc.. :) > > Moving the TLV header into a separate document at this point would > impact draft-ietf-netlmm-pmip6-ipv4-support. I don't think the TLV > header document can be standardized fast enough => Can't this be copied and pasted into the netlmm draft and of course elaborated upon to add Pasi's request? for > draft-ietf-netlmm-pmip6-ipv4-support to advance. One option would be to > move the TLV header and the text that describes how to negotiate it, to > either draft-ietf-netlmm-pmip6-ipv4-support or > draft-ietf-netlmm-grekey-option. > > My suggestion would be to leave the TLV header in the DS-MIPv6 document. > Have some text that says the following. If UDP encapsulation is used > with DS-MIPv6 port, there could be IPv4, IPv6, GRE or some other header > that might follow the UDP header. If there is anything other than the > IPv4 or IPv6 header, the TLV header would be required. The use of GRE or > some other protocol after the TLV header is not specified and is out of > scope in the DS-MIPv6 document. => This is what Pasi is objecting to. Hesham > > Vijay > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Pasi.Eronen@nokia.com >> Sent: Thursday, January 15, 2009 3:54 AM >> To: hesham@elevatemobile.com; mext@ietf.org >> Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review >> >> Hesham, >> >> I would strongly suggest moving the whole TLV header text to the >> separate GRE document. >> >> In particular, if you assign a number for GRE in this document, >> you either need to describe how it works here, or have a normative >> reference to the NETLMM spec. >> >> Best regards, >> Pasi >> >>> -----Original Message----- >>> From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: 14 January, 2009 14:23 >>> To: mext@ietf.org >>> Cc: Eronen Pasi (Nokia-NRC/Helsinki) >>> Subject: GRE support in DSMIPv6 - AD review >>> >>> Folks, >>> >>> Part of Pasi's review for DSMIPv6 was a comment on the lack of >>> specification for GRE support in the spec. He said it was vastly >>> under-specified, no details on the tunnelling, setting of different >>> parts of the GRE header ...etc. >>> >>> I suggested that we don't explicitly mention GRE in the spec but we >>> keep the TLV tunnelling format and reserve the numbers for NETLMM to >>> specify exactly how it will be used in a separate document. I think >>> you would agree that this is largely driven by NETLMM needs and we >>> shouldn't specify the details in MEXT. Pasi was ok with that. >>> >>> Please express your opinion on this soon because Pasi's comments are >>> the last comments for the draft and I want to handle them by Monday >>> at the latest. >>> >>> Please avoid discussing the merits of GRE....etc, the question is: >>> >>> Are there any objections to removing explicit references to GRE >>> while reserving the numbers in the TLV header for it to be specified >>> clearly in NETLMM? >>> >>> Thanks, >>> >>> Hesham >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jan 16 07:06:41 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE78828C248; Fri, 16 Jan 2009 07:06:41 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B56A28C248 for ; Fri, 16 Jan 2009 07:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2BWNEhcncga for ; Fri, 16 Jan 2009 07:06:39 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 93C0728C246 for ; Fri, 16 Jan 2009 07:06:38 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 16:06:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Jan 2009 16:06:19 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl2Qty8AAnKSyLlR0eCYUg0kSOoIQAxLqsAAA1z7DAADhiRqQAdiIsw References: From: To: , , , X-OriginalArrivalTime: 16 Jan 2009 15:06:20.0587 (UTC) FILETIME=[FD348FB0:01C977EB] Cc: jari.arkko@piuha.net Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi all, Just a naive question: during re-chartering discussion, it was proposed a w= ork item for the use of GRE tunnelling mechanism in Mobile IPv6. But this i= tem has not been included in the charter. So, I'm wondering if there is sti= ll some plan to work on (except draft-ietf-netlmm-grekey-option in NetLMM W= G)? If yes, maybe it could solve the issue. Regards, Pierrick > -----Message d'origine----- > De=A0: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de > Hesham Soliman > Envoy=E9=A0: vendredi 16 janvier 2009 02:00 > =C0=A0: Vijay Devarapalli; Pasi.Eronen@nokia.com; mext@ietf.org > Cc=A0: Jari Arkko > Objet=A0: Re: [MEXT] GRE support in DSMIPv6 - AD review > = > = > > Hi Pasi, Hesham, > > > > The TLV header was specified in the DS-MIPv6 document after rather a > > long and acrimonious debate on the former MIP6 mailing list. There were > > atleast two consensus calls that were run at that time. > = > =3D> I don't realy want to get into that, we all know there was no concen= sus > and we had to teleconference to come up with the existing method > = > Anytime you have > > a UDP header with IPv4/IPv6/GRE header following it, you need the TLV > > header. At that time, there were folks arguing for using GRE > > encapsulation with MIPv6 also. PMIPv6 IPv4 support was not the only > > scenario for the TLV header. We are overturning that consensus now. > > Maybe folks who were arguing for the TLV header with DS-MIPv6, are > > either busy/not looked at this thread yet/or not on the MEXT mailing > > list/etc.. :) > > > > Moving the TLV header into a separate document at this point would > > impact draft-ietf-netlmm-pmip6-ipv4-support. I don't think the TLV > > header document can be standardized fast enough > = > =3D> Can't this be copied and pasted into the netlmm draft and of course > elaborated upon to add Pasi's request? > = > = > for > > draft-ietf-netlmm-pmip6-ipv4-support to advance. One option would be to > > move the TLV header and the text that describes how to negotiate it, to > > either draft-ietf-netlmm-pmip6-ipv4-support or > > draft-ietf-netlmm-grekey-option. > > > > My suggestion would be to leave the TLV header in the DS-MIPv6 document. > > Have some text that says the following. If UDP encapsulation is used > > with DS-MIPv6 port, there could be IPv4, IPv6, GRE or some other header > > that might follow the UDP header. If there is anything other than the > > IPv4 or IPv6 header, the TLV header would be required. The use of GRE or > > some other protocol after the TLV header is not specified and is out of > > scope in the DS-MIPv6 document. > = > =3D> This is what Pasi is objecting to. > = > Hesham > = > > > > Vijay > > > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >> Behalf Of Pasi.Eronen@nokia.com > >> Sent: Thursday, January 15, 2009 3:54 AM > >> To: hesham@elevatemobile.com; mext@ietf.org > >> Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review > >> > >> Hesham, > >> > >> I would strongly suggest moving the whole TLV header text to the > >> separate GRE document. > >> > >> In particular, if you assign a number for GRE in this document, > >> you either need to describe how it works here, or have a normative > >> reference to the NETLMM spec. > >> > >> Best regards, > >> Pasi > >> > >>> -----Original Message----- > >>> From: ext Hesham Soliman [mailto:hesham@elevatemobile.com] > >>> Sent: 14 January, 2009 14:23 > >>> To: mext@ietf.org > >>> Cc: Eronen Pasi (Nokia-NRC/Helsinki) > >>> Subject: GRE support in DSMIPv6 - AD review > >>> > >>> Folks, > >>> > >>> Part of Pasi's review for DSMIPv6 was a comment on the lack of > >>> specification for GRE support in the spec. He said it was vastly > >>> under-specified, no details on the tunnelling, setting of different > >>> parts of the GRE header ...etc. > >>> > >>> I suggested that we don't explicitly mention GRE in the spec but we > >>> keep the TLV tunnelling format and reserve the numbers for NETLMM to > >>> specify exactly how it will be used in a separate document. I think > >>> you would agree that this is largely driven by NETLMM needs and we > >>> shouldn't specify the details in MEXT. Pasi was ok with that. > >>> > >>> Please express your opinion on this soon because Pasi's comments are > >>> the last comments for the draft and I want to handle them by Monday > >>> at the latest. > >>> > >>> Please avoid discussing the merits of GRE....etc, the question is: > >>> > >>> Are there any objections to removing explicit references to GRE > >>> while reserving the numbers in the TLV header for it to be specified > >>> clearly in NETLMM? > >>> > >>> Thanks, > >>> > >>> Hesham > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > = > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jan 16 09:19:04 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A3828C294; Fri, 16 Jan 2009 09:19:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B83928C277 for ; Fri, 16 Jan 2009 09:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-5pGi7xNxMP for ; Fri, 16 Jan 2009 09:19:01 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 4911A28C290 for ; Fri, 16 Jan 2009 09:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=pstupar@qualcomm.com; q=dns/txt; s=qcdkim; t=1232126326; x=1263662326; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20Comments=20on=20draft-ietf- mext-binding-revocation-02|Date:=20Fri,=2016=20Jan=202009 =2017:17:31=20-0000|Message-ID:=20|In-Reply-To:=20< C5A96676FCD00745B64AE42D5FCC9B6E1C7307B3@zrc2hxm0.corp.no rtel.com>|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20Comments=20on=20draft-ietf-mext-binding- revocation-02|Thread-Index:=20AclbLn3taqHuU6TUSgeN3dxQhl2 ykQArrD7gALKdDZAEWRBysAGXgEdQ|References:=20=20=20=20|From:=20"Stupar,=20Patrick" =20|To:=20"Ahmad=20Muhanna"=20|Cc:=20 |X-OriginalArrivalTime:=2016=20Jan=202009=2017:18:44.0805 =20(UTC)=20FILETIME=3D[7C540750:01C977FE]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5100,188,5497"=3B=20a=3D"14701916"; bh=MXGKfQt7+vZmkWwWcUWnbea0ih33vXTx5XqOeBrShWk=; b=NG8FaJ/Z4pPQziXRaHGov2UGj+PTpXfkRvhS4mtYYKuzvfGXUApK5wwN hSY6gj9oP8wbOzhp62jEa6zi/x6oAL1ZBad6J7Z/drsvlIejCCEZr31JL zVdh+IcHyc9As/0RKFN2VEF+9JID/yhhtsraQCYLnXWJNGfdNH4SiLC7T 4=; X-IronPort-AV: E=McAfee;i="5100,188,5497"; a="14701916" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jan 2009 09:18:46 -0800 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0GHIjOe020196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jan 2009 09:18:46 -0800 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0GHIjO2024114; Fri, 16 Jan 2009 09:18:45 -0800 Received: from EUEX02.eu.qualcomm.com ([10.222.228.33]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 09:18:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Jan 2009 17:17:31 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-mext-binding-revocation-02 Thread-Index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQArrD7gALKdDZAEWRBysAGXgEdQ References: From: "Stupar, Patrick" To: "Ahmad Muhanna" X-OriginalArrivalTime: 16 Jan 2009 17:18:44.0805 (UTC) FILETIME=[7C540750:01C977FE] Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad I think most of the discussion we had is solved. Please find one last comment below. Best Regards, Patrick > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Tuesday, January 06, 2009 4:23 PM > To: Stupar, Patrick > Cc: mext@ietf.org > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > Hi Patrick, > It seems that I never responded to your responses. > Please see responses inline. > > Regards, > Ahmad > > > > > > > > -----Original Message----- > > > > From: Stupar, Patrick [mailto:pstupar@qualcomm.com] > > > > Sent: Wednesday, December 10, 2008 7:19 PM > > > > To: Muhanna, Ahmad (RICH1:2H10) > > > > Cc: mext@ietf.org > > > > Subject: Comments on draft-ietf-mext-binding-revocation-02 > > > > > > > > Hi Ahmad, > > > > > > > > I have reviewed binding revocation draft and have the following > > > > comments/questions. > > > > > > > > - In MIPv6, Binding Update and Binding Ack have two different MH > > > > type values. Why isn't the same approach taken for BRI > > and BRA and > > > > only one value is used? > > > > > > [Ahmad] > > > This was discussed on the mailing list for a long time and > > agreed that > > > using one MH type will help in preserving the MH type > > space. I believe > > > the "Heartbeat Mechanism for PMIPv6" is a wg doc in Netlmm > > and use one > > > MH type for the Request and Response. On the other hand, do see an > > > issue or problem in having a single MH type for both messages? > > > > [Patrick] If the WG is worried about MH type space then I am > > fine with the proposed message format. > > > > > > > > > > > > > - BRI has a revocation trigger field which is used for two main > > > > usages. > > > > One is the provisioning of the reason why the revocation was sent > > > > (e.g. > > > > inter-MAG handoff) and the other is related to specific binding > > > > revocation procedures (e.g. IPV4 HoA Binding only, > > Per-Peer Policy). > > > > I think it would be cleaner if the two concepts remain > > separated in > > > > the messages, for instance defining additional flags for Per-peer > > > > policy or > > > > IPv4 HoA Binding only. > > > > > > [Ahmad] > > > I see what you are saying. However, as you said, the Revocation > > Trigger > > > field is defined to give the reason which caused the > > revoking node to > > > send the BRI message. Thus far, I believe all of the defined values > > are > > > inline with that definition or reasoning. For example: When the LMA > > > sets the R. Trigger value to "IPv4 HoA Binding Only" it > > means that the > > > reason behind sending this BRI message is to revoke the IPv4 HoA > > > address in the case that the MN is assigned two proxy > > HoA(v4 & v6) for > > > the same pCoA. > > > I > > > do not see this as a policy decision, because it is no > > difference from > > > the MAG sending a BRI with R. Trigger value is set to for example, > > > "Access Network Session Termination" > > > > > > As for the R. Trigger value of "Per-Peer Policy", This is only > > > restricted to Global Revocation when the (G) bit is set. I still > > > believe that "Per-Peer policy" also indicate the reason > > that allowed > > > the LMA > > to > > > send this Global BRI. Do you have a different name for this > > R. Trigger > > > value that would fit better? > > > > > > > [Patrick]IMHO "IPv4 HoA Binding Only" is not the reason that > > triggered the BRI, it's the action that the MN is requested > > to perform. Anyhow, my concerns were not related to the list > > of reasons in the revocation trigger, but to the fact that > > some values of the field imply some actions and other values > > don't. My suggestion is that the actions are taken by MN and > > HA based on flags (e.g. Global Revocation) and not on the > > revocation trigger. Only the case of "IPv4 HoA Binding Only" > > lacks of a proper flag. > > [Ahmad] > After pondering on this, it seems to me that makes sense. Will > introduce > a flag for "IPv4 HoA Revocation Only" and update the draft accordingly. > This will cause some text changes to capture all cases which relates to > Client MIP6 and PMIPv6; will take care of it in the new revision, > hopefully in the next week. > > > > > > > > > > > > > - In the draft you refer to MAG identity, where is this term > > > > defined? I wasn't able to find it in RFC 5213. > > > > > > [Ahmad] > > > Actually, under section 4.1. "Peer Authorization Database (PAD) > > Example > > > Entries", you can find the MAG-ID is defined there as > > mag_identity_1. > > > It > > > is the same concept here. However, I agree that we do not have a > > > mobility option which is specific for carrying MAG-ID but > > the draft is > > > using the MN-ID in a very specific scenario. How the LMA would > check > > if > > > this MAG is authorized for Global revocation is out of scope. > > > > > > > [Patrick] what I meant here is that in section 2 of RFC5213 > > there is the definition of MN identity and that I would > > expect something similar for the MAG in BRI draft. For MN > > identity, RFC5213 claims that MAC address or NAI can be used. > > Are there similar guidelines for MAG identity? > > [Ahmad] > I see what you are saying. I assumed that this is in the form of NAI. > we > can add some text to clarify that, would that address your concern or > you have in mind a possible different format? I think this would be good. Either a definition in section 2.2 or a clarification in the text would be fine with me. > > > > > > > > > > > > > > > > > Some other comments related to specific sections: > > > > > > > > - page 21: in the first section after the bullet list, > > there is the > > > > following sentence: > > > > "As described in Section 7.3, the LMA SHOULD retransmit > > this BRI to > > > > the MAG before deleting the mobile node IP tunnel to the > mobile > > > > access gateway until it receives a matching Binding Revocation > > > > Acknowledgement or the BRIMaxRetransmitNumber is reached. " > > > > But this doesn't always apply, e.g. in case of inter-mag > > handoffs. > > > > What am I missing? > > > > > > [Ahmad] > > > Yes, I see what you are saying here. It seems that the text > > needs some > > > tweaking. > > > Do you have any suggestion? > > [Patrick] How about referring to the BCE? > > Proposed text: > > "As described in Section 7.3, the LMA SHOULD retransmit this > > BRI to the MAG before deleting BCE until it receives a > > matching Binding Revocation Acknowledgement or the > > BRIMaxRetransmitNumber is reached. " > > Though I am not sure this text is helpful as it is already > > captured later in the draft. > > [Ahmad] > When talking about deleting the BCE, it may conflict with the case of > inter-MAG handoff. I believe leaving the term deleting the tunnel is > more generic. In other words, LMA may delete the IP tunnel but NOT the > BCE in some cases. However, in other cases which does not involve > inter-MAG handoff, when deleting the IP tunnel, consequently, the BCE > will be deleted. Fine with me. > > > > > > > > > > > > > > > > - why is the A bit setting mandatory in case of IPv4 HoA binding > > > > only revocation? > > > > > > [Ahmad] > > > May be if you tell me why not, we could change it? > > > > [Patrick] I have nothing against it. But that "MUST" implies > > that a BRI with the "IPv4 HoA Binding Only" value in the > > revocation trigger field and A bit not set is not properly > > formatted. What does the MAG do in this case? > > [Ahmad] > I believe that "MUST" is needed because revoking the IPv4 HoA address > only does not mean deleting the BCE, In other words, the MAG should > maintain the IPv6 HoA Binding and a PBA is needed to confirm to the LMA > that the MAG will continue maintaining the IPv6 binding. However, the > case you mentioned is an error scenario and we may have two ways to do > it: > > 1. The MAG to ignore the BRI > 2. The MAG MUST treat this as if the 'A' bit is set and MUST send a > PBA. > > After introducing the "IPv4 HoA Revocation Only" flag, I believe the > proper behavior is No. 2 above. > Behavior 2 implies that PBA is mandatory, not the setting of the ACK, but I can live with that :-) > > > > > > > > > > > > > > - section 10.1.1: > > > > "BRI MUST be formatted as in Section 6.1 and if the (P) > > bit is set, > > > > the mobile access gateway must validate that the impacted > > > > binding > > > > have the proxy binding flag set." > > > > MAG is not supposed to have any proxy binding flag or is it? > > > > How can it validate this flag? > > > > > > [Ahmad] > > > Good catch. There is another incident below it too. > > > What about the following text for both bullets: > > > " > > > o BRI MUST be formatted as in Section 6.1 and the (P) > > bit is set. > > > > > > o If the Global (G) bit is set and the Revocation > > Trigger field is > > > set to "Per-Peer policy", the mobile access gateway > > identify all > > > bindings that are registered at the LMA and hosted at the > MAG. > > > This Binding Revocation Indication does not include any other > > > mobility options. In this case, the MAG MUST send a > > BRA with the > > > appropriate status code to the LMA. > > > " > > > > > > > [Patrick] fine with me, thanks > > > > > > > > > > > > > > -section 11.1 > > > > " If the Acknowledgement (A) bit is set in the Binding Revocation > > > > Indication and the MN has the BCE in registered state, the > > > > mobile > > > > node MUST send a Binding Revocation Acknowledgement." > > > > > > > > MN has no BCE, it has a binding update list. > > > [Ahmad] > > > Right. Thx. What about the following: > > > > > > o If the Acknowledgement (A) bit is set in the Binding > > Revocation > > > Indication and the MN has a Binding Update List entry for the > > > source > > > of the BRI message, the mobile node MUST send a Binding > > > Revocation > > > > > > Acknowledgement. However, in all other cases when the > > (A) bit is > > > set > > > in the BRI, the mobile node SHOULD send a Binding Revocation > > > Acknowledgement. > > > In all cases, the mobile node MUST follow Section > > 11.2 when send > > > a BRA using the appropriate status code. > > > > > [Patrick] I would perform the check based on the HoA and CoA > > contained in the BRI. > > Proposed text: > > > > o If the Acknowledgement (A) bit is set in the Binding Revocation > > Indication and the MN has a Binding Update List entry > > for the Care of address and the Home Address > > Contained in the BRI message, the mobile node MUST send > > a Binding Revocation > > > > Acknowledgement. However, in all other cases when the > > (A) bit is set > > in the BRI, the mobile node SHOULD send a Binding > > Revocation Acknowledgement. > > In all cases, the mobile node MUST follow Section 11.2 > > when send > > a BRA using the appropriate status code. > > > > [Ahmad] > Currently, neither the HoA nor the CoA is included in the BRI message. > Are you suggesting that we add those options as valid ones in the BRI? No I am not. What I meant here is that HoA is in the routing header of the packet containing the BRI. Checking of HoA would be enough IMO. It could be moved to the previous bullet of the list as in the following proposed text: OLD TEXT: " o The mobile node MUST verify that the IP address in the type 2 routing header is its Home Address. o If the Acknowledgement (A) bit is set in the Binding Revocation Indication and the MN has the BCE in registered state, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the (A) bit is set in the BRI, the mobile node SHOULD send a Binding Revocation Acknowledgement. In all cases, the mobile node MUST follow Section 11.2 when send a BRA using the appropriate status code. " NEW TEXT " o The mobile node MUST verify that the IP address in the type 2 routing header is its Home Address and that its Binding Update List contains an entry for that Home Address. If one of the tests fails, the mobile node SHOULD silently discard the received BRI message. o If the Acknowledgement (A) bit is set in the Binding Revocation Indication, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the (A) bit is set in the BRI, the mobile node SHOULD send a Binding Revocation Acknowledgement. In all cases, the mobile node MUST follow Section 11.2 when send a BRA using the appropriate status code. " Please note that the proposed text overlaps with the last bullet listed in section 11.2. I would remove that as in the following: Old text: "11.2. Sending Binding Revocation Acknowledgement When the mobile node receive a valid Binding Revocation Indication with the (A) bit is set from its home agent and while having this BCE in registered state, the mobile node MUST send a packet to its home agent containing a Binding Revocation Acknowledgement according to the procedure in Section 7.1 and the following: o The mobile node MUST set the status field to successful to reflect that it has received the Binding Revocation Indication and acknowledge that its IP connectivity with its home agent has been revoked. o The destination IP address of the IPv6 packet of the Binding Revocation Acknowledgement is set to the source IP address of the received IPv6 packet of the Binding Revocation Indication. The Mobile Node MUST include its home address in the Home Address option in the Destination Option. o If the mobile node receives a Binding Revocation Indication from a home agent which the mobile node does not have a registered binding with, the mobile node SHOULD silently discard the BRI message. The mobile node should continue to use its assigned HoA to access its IP mobility service." New text: "11.2. Sending Binding Revocation Acknowledgement When the mobile node receive a valid Binding Revocation Indication with the (A) bit is set from its home agent and while having this BCE in registered state, the mobile node MUST send a packet to its home agent containing a Binding Revocation Acknowledgement according to the procedure in Section 7.1 and the following: o The mobile node MUST set the status field to successful to reflect that it has received the Binding Revocation Indication and acknowledge that its IP connectivity with its home agent has been revoked. o The destination IP address of the IPv6 packet of the Binding Revocation Acknowledgement is set to the source IP address of the received IPv6 packet of the Binding Revocation Indication. The Mobile Node MUST include its home address in the Home Address option in the Destination Option." > > > > > > > > > > > -section 11.1 > > > > "If the Revocation Trigger field value is "Administrative > Reason", > > > > the mobile node MUST NOT try to re-register with the home > > agent > > > > before contacting its home operator." > > > > > > > > I don't think that BRI specs have to mandate the MN to > > contact the > > > > home operator, the text at the end of section > > > > 11.1 is enough IMO. > > > > > > > [Ahmad] > > > I see your point, It seems a very strong requirement and for a well > > > behaved MN implementation, it may not be a problem to > > remove the whole > > > bullet. However, for a non-well behaved MN, it may be necessary to > > keep > > > something. What about if we demote MUST NOT to SHOULD NOT. > > Would that > > > work? > > > > > > > > [Patrick] I was not worried about the "MUST" or "SHOULD", but > > by the fact that IMO the action to be taken after receiving a > > BRI with that value in the trigger field is implementation > > dependant as already described later in the draft > > [Ahmad] > Sure, we can remove this bullet. > > Thanks for all of your comments and sorry for the late reply. > > > > > > NEW TEXT: > > > o If the Revocation Trigger field value is "Administrative > > Reason", > > > the mobile node SHOULD NOT try to re-register with the home > > agent > > > before contacting its home operator. > > > > > > TEXT at end of 11.1 that Patrick is referring to: > > > > > > The Revocation Trigger field value in the received Binding > > > Revocation > > > Indication could be used by the mobile node to define > > what action > > > the > > > mobile node could do to be able to register again and receive > its > > IP > > > mobility service, e.g. contacting its home operator. > > > > > > > I have some typos and editorial corrections as well, I will send > > > > them off-list. > > > > > > [Ahmad] > > > Please send them. Thanks for your review and good comments! > > > > > > > > > > > Regards, > > > > > > > > Patrick > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jan 16 09:27:28 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F064E28C257; Fri, 16 Jan 2009 09:27:27 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC3C3A6A2D for ; Fri, 16 Jan 2009 09:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxB6owrLcaWH for ; Fri, 16 Jan 2009 09:27:25 -0800 (PST) Received: from web111408.mail.gq1.yahoo.com (web111408.mail.gq1.yahoo.com [67.195.15.174]) by core3.amsl.com (Postfix) with SMTP id E0C763A69E4 for ; Fri, 16 Jan 2009 09:27:25 -0800 (PST) Received: (qmail 5493 invoked by uid 60001); 16 Jan 2009 17:27:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=Gr5id1h1iirBA5k1Nge8Pv1DGtVtvjtkfjuxjT1jtspDHUG9+fP5dQkAGnRjYDUVzwq6spGbpHZJTEEwqKZrYz0AJvk4ILXMMKyagypM6C7NBO9llwS3BJqaSGDYaZxboVymQADJ8nQQLGGo+S4JPwHRwi0vka/HZUHUcImeqr4=; X-YMail-OSG: a7258cAVM1kNlJjWveC1VM2ZRU5I7UeKCGYHWl9ob4SExt9hOAWt1cIuHWnZoRuR9Cafafovjarslksv.1AJKuJcg.cNXWfhYHEgrnDt3TLlSdquLP4xLe_li5sgOnJH_Q5gslYE6tErmpesAK2mvBir9KLdQvmK.ovy2fZRV_mB.ugPbk00o_kQt.h5.bUwHhYpJaJc_CmISwY- Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Fri, 16 Jan 2009 09:27:09 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: Date: Fri, 16 Jan 2009 09:27:09 -0800 (PST) From: Behcet Sarikaya To: Hesham Soliman , Vijay Devarapalli , Pasi.Eronen@nokia.com, mext@ietf.org MIME-Version: 1.0 Message-ID: <703169.3551.qm@web111408.mail.gq1.yahoo.com> Cc: Jari Arkko Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0147456840==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0147456840== Content-Type: multipart/alternative; boundary="0-1428319434-1232126829=:3551" --0-1428319434-1232126829=:3551 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A________________________________=0A=0AFrom: Hesham Soliman =0ATo: Vijay Devarapalli ; Pasi.E= ronen@nokia.com; mext@ietf.org=0ACc: Jari Arkko =0ASe= nt: Thursday, January 15, 2009 7:00:13 PM=0ASubject: Re: [MEXT] GRE support= in DSMIPv6 - AD review=0A=0A=0AAt that time, there were folks arguing for = using GRE=0A> encapsulation with MIPv6 also. =0A[behcet] I couldn't underst= and why MN would need to support GRE. Can someone explain the use case?=0A= =A0=0AThanks,=0A=A0=0ABehcet=0A=0A=0A> Hi Pasi, Hesham,=0A> =0A> The TLV he= ader was specified in the DS-MIPv6 document after rather a=0A> long and acr= imonious debate on the former MIP6 mailing list. There were=0A> atleast two= consensus calls that were run at that time.=0A=0A=3D> I don't realy want t= o get into that, we all know there was no concensus=0Aand we had to telecon= ference to come up with the existing method=0A=0AAnytime you have=0A> a UDP= header with IPv4/IPv6/GRE header following it, you need the TLV=0A> header= . =0A=0A=0A --0-1428319434-1232126829=:3551 Content-Type: text/html; charset=us-ascii


From: Hesham Soliman <hesham@elevatemobile.com>
To: Vijay Devarapalli <vijay@wichorus.com>; Pasi.Eronen@nokia.com; mext@ietf.org
Cc: Jari Arkko <jari.arkko@piuha.net>
Sent: Thursday, January 15, 2009 7:00:13 PM
Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review


> Hi Pasi, Hesham,
>
> The TLV header was specified in the DS-MIPv6 document after rather a
> long and acrimonious debate on the former MIP6 mailing list. There were
> atleast two consensus calls that were run at that time.

=> I don't realy want to get into that, we all know there was no concensus
and we had to teleconference to come up with the existing method

Anytime you have
> a UDP header with IPv4/IPv6/GRE header following it, you need the TLV
> header.
 
At that time, there were folks arguing for using GRE
> encapsulation with MIPv6 also.
[behcet] I couldn't understand why MN would need to support GRE. Can someone explain the use case?
 
Thanks,
 
Behcet
 

--0-1428319434-1232126829=:3551-- --===============0147456840== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0147456840==-- From mext-bounces@ietf.org Fri Jan 16 10:52:21 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27A1B3A6A2D; Fri, 16 Jan 2009 10:52:21 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B633A6A2D for ; Fri, 16 Jan 2009 10:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekbEZHexrQYs for ; Fri, 16 Jan 2009 10:52:18 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 4BDE83A6906 for ; Fri, 16 Jan 2009 10:52:18 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0GIpwd26236; Fri, 16 Jan 2009 18:51:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Jan 2009 12:50:50 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-mext-binding-revocation-02 Thread-Index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQArrD7gALKdDZAEWRBysAGXgEdQAGd43wA= References: From: "Ahmad Muhanna" To: "Stupar, Patrick" Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Patrick, Thanks. One slight modification below. Regards, Ahmad > -----Original Message----- > From: Stupar, Patrick [mailto:pstupar@qualcomm.com] > Sent: Friday, January 16, 2009 11:18 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext@ietf.org > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > > > [Ahmad] > > I see what you are saying. I assumed that this is in the > form of NAI. > > we > > can add some text to clarify that, would that address your > concern or > > you have in mind a possible different format? > > I think this would be good. Either a definition in section > 2.2 or a clarification in the text would be fine with me. [Ahmad] Sure. > > > > [Ahmad] > > Currently, neither the HoA nor the CoA is included in the > BRI message. > > Are you suggesting that we add those options as valid ones > in the BRI? > > No I am not. What I meant here is that HoA is in the routing > header of the packet containing the BRI. Checking of HoA > would be enough IMO. It could be moved to the previous bullet > of the list as in the following proposed text: > OLD TEXT: > " > o The mobile node MUST verify that the IP address in the type 2 > routing header is its Home Address. > > o If the Acknowledgement (A) bit is set in the Binding Revocation > Indication and the MN has the BCE in registered state, > the mobile > node MUST send a Binding Revocation Acknowledgement. > However, in > all other cases when the (A) bit is set in the BRI, the mobile > node SHOULD send a Binding Revocation Acknowledgement. In all > cases, the mobile node MUST follow Section 11.2 when send a BRA > using the appropriate status code. > " > NEW TEXT > " > o The mobile node MUST verify that the IP address in the type 2 > routing header is its Home Address and that its Binding Update > List contains an entry for that Home Address. If one of > the tests fails, > the mobile node SHOULD silently discard the received BRI > message. > > o If the Acknowledgement (A) bit is set in the Binding Revocation > Indication, the mobile > node MUST send a Binding Revocation Acknowledgement. > However, in > all other cases when the (A) bit is set in the BRI, the mobile > node SHOULD send a Binding Revocation Acknowledgement. In all > cases, the mobile node MUST follow Section 11.2 when send a BRA > using the appropriate status code. > " [Ahmad] I am not sure I follow the second bullet of the "NEW TEXT". What about the following modified text: "MODIFIED TEXT" o The mobile node MUST verify that the IP address in the type 2 routing header is its Home Address and that its Binding Update List contains an entry for that Home Address. If one of the tests, fails the mobile node SHOULD silently discard the received BRI message. o If the Acknowledgement (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the (A) bit is set in the BRI, the mobile node SHOULD send a Binding Revocation Acknowledgement. In all cases, the mobile node MUST follow Section 11.2 when send a BRA using the appropriate status code. > > Please note that the proposed text overlaps with the last > bullet listed in section 11.2. I would remove that as in the > following: > > Old text: > "11.2. Sending Binding Revocation Acknowledgement > > When the mobile node receive a valid Binding Revocation Indication > with the (A) bit is set from its home agent and while > having this BCE > in registered state, the mobile node MUST send a packet to its home > agent containing a Binding Revocation Acknowledgement according to > the procedure in Section 7.1 and the following: > > o The mobile node MUST set the status field to successful > to reflect > that it has received the Binding Revocation Indication and > acknowledge that its IP connectivity with its home > agent has been > revoked. > > o The destination IP address of the IPv6 packet of the Binding > Revocation Acknowledgement is set to the source IP > address of the > received IPv6 packet of the Binding Revocation Indication. The > Mobile Node MUST include its home address in the Home Address > option in the Destination Option. > > o If the mobile node receives a Binding Revocation > Indication from a > home agent which the mobile node does not have a registered > binding with, the mobile node SHOULD silently discard the BRI > message. The mobile node should continue to use its > assigned HoA > to access its IP mobility service." > > New text: > "11.2. Sending Binding Revocation Acknowledgement > > When the mobile node receive a valid Binding Revocation Indication > with the (A) bit is set from its home agent and while > having this BCE > in registered state, the mobile node MUST send a packet to its home > agent containing a Binding Revocation Acknowledgement according to > the procedure in Section 7.1 and the following: > > o The mobile node MUST set the status field to successful > to reflect > that it has received the Binding Revocation Indication and > acknowledge that its IP connectivity with its home > agent has been > revoked. > > o The destination IP address of the IPv6 packet of the Binding > Revocation Acknowledgement is set to the source IP > address of the > received IPv6 packet of the Binding Revocation Indication. The > Mobile Node MUST include its home address in the Home Address > option in the Destination Option." [Ahmad] Sure. That is fair and good. Best Regards, Ahmad _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jan 16 15:57:07 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C3C3A689D; Fri, 16 Jan 2009 15:57:07 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C0E63A689D for ; Fri, 16 Jan 2009 15:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v1TkZFH-Ej1 for ; Fri, 16 Jan 2009 15:57:05 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 936F03A6768 for ; Fri, 16 Jan 2009 15:57:04 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LNyYI-0007AZ-Fs; Sat, 17 Jan 2009 10:56:38 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Sat, 17 Jan 2009 10:56:30 +1100 From: Hesham Soliman To: Behcet Sarikaya , Vijay Devarapalli , , Message-ID: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl4Ng0X3joRG3lYgEOmRZ1GAGCiYg== In-Reply-To: <703169.3551.qm@web111408.mail.gq1.yahoo.com> Mime-version: 1.0 Cc: Jari Arkko Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > At that time, there were folks arguing for using GRE >> encapsulation with MIPv6 also. > [behcet] I couldn't understand why MN would need to support GRE. Can some= one > explain the use case? =3D> It was done for NETLMM. Technically and practically speaking it will never be used by the MN. And there is no reason for doing so. Whenever GRE is used it's used within the network not from the host. Hesham > =A0 > Thanks, > =A0 > Behcet > = > = >> Hi Pasi, Hesham, >> = >> The TLV header was specified in the DS-MIPv6 document after rather a >> long and acrimonious debate on the former MIP6 mailing list. There were >> atleast two consensus calls that were run at that time. > = > =3D> I don't realy want to get into that, we all know there was no concen= sus > and we had to teleconference to come up with the existing method > = > Anytime you have >> a UDP header with IPv4/IPv6/GRE header following it, you need the TLV >> header. = > = > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jan 17 00:17:28 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B437C28C10E; Sat, 17 Jan 2009 00:17:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5E428C10E for ; Sat, 17 Jan 2009 00:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYQdylPxbq5Z for ; Sat, 17 Jan 2009 00:17:27 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id C593428C0DC for ; Sat, 17 Jan 2009 00:17:26 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDL004S4WCLB7@szxga01-in.huawei.com> for mext@ietf.org; Sat, 17 Jan 2009 16:17:09 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDL005YVWCL5R@szxga01-in.huawei.com> for mext@ietf.org; Sat, 17 Jan 2009 16:17:09 +0800 (CST) Received: from s68128b ([10.111.148.189]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDL0004SWCK3T@szxml05-in.huawei.com> for mext@ietf.org; Sat, 17 Jan 2009 16:17:09 +0800 (CST) Date: Sat, 17 Jan 2009 16:17:08 +0800 From: Shi Xiaoyan To: 'Hesham Soliman' Message-id: <006001c9787b$fdd0cd40$bd946f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acl4e/1gnce/8wg+TyC7IjHZuRMuKQ== Cc: mext@ietf.org Subject: [MEXT] IPv4 home address option in DSMIP X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1594126813==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1594126813== Content-type: multipart/alternative; boundary="Boundary_(ID_2mXXcE8AkyqlX8Es1sf4bw)" This is a multi-part message in MIME format. --Boundary_(ID_2mXXcE8AkyqlX8Es1sf4bw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Hesham, Section 5.4.2 When sending a binding update from a visited network that supports IPv6, the mobile node MUST follow the rules specified in [RFC3775]. In addition, if the mobile node has an IPv4 home address or needs one, it MUST include the IPv4 home address option in the mobility header. Does the IPv4 home address option must be include in Binding Update even if BU is send for extend binding lifetime? I think it is redundant since only IPv6 HoA is the key for BCE lookup. In maillist, I find some disscussion mails about this quesion, but I can't find the reason why all BU must include IPv4 home address option. Regards, Xiaoyan --Boundary_(ID_2mXXcE8AkyqlX8Es1sf4bw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi Hesham,
 
Section 5.4.2
 
   When sending a binding update from a visited network that supports
   IPv6, the mobile node MUST follow the rules specified in [RFC3775].
   In addition, if the mobile node has an IPv4 home address or needs
   one, it MUST include the IPv4 home address option in the mobility
   header. 
 
Does the IPv4 home address option must be include in Binding Update even if BU is send for extend binding lifetime?
I think it is redundant since only IPv6 HoA is the key for BCE lookup. In maillist, I find some disscussion mails about this quesion, but I can't find the reason why all BU must include IPv4 home address option.
 

Regards,
Xiaoyan
--Boundary_(ID_2mXXcE8AkyqlX8Es1sf4bw)-- --===============1594126813== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1594126813==-- From mext-bounces@ietf.org Sat Jan 17 00:33:16 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E8903A6807; Sat, 17 Jan 2009 00:33:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAB5C3A6807 for ; Sat, 17 Jan 2009 00:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89PqPZKpb302 for ; Sat, 17 Jan 2009 00:33:14 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id E2F333A6800 for ; Sat, 17 Jan 2009 00:33:13 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDL007J4X2NZ8@szxga02-in.huawei.com> for mext@ietf.org; Sat, 17 Jan 2009 16:32:48 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDL00HYSX2N2R@szxga02-in.huawei.com> for mext@ietf.org; Sat, 17 Jan 2009 16:32:47 +0800 (CST) Received: from s68128b ([10.111.148.189]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDL008KLX2NE5@szxml06-in.huawei.com> for mext@ietf.org; Sat, 17 Jan 2009 16:32:47 +0800 (CST) Date: Sat, 17 Jan 2009 16:32:47 +0800 From: Shi Xiaoyan To: 'Hesham Soliman' Message-id: <007701c9787e$2d339f20$bd946f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acl4e/1gnce/8wg+TyC7IjHZuRMuKQ== Cc: mext@ietf.org Subject: [MEXT] IPv4 home address option in DSMIP X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1802406267==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1802406267== Content-type: multipart/alternative; boundary="Boundary_(ID_mGOXU9nnP8f6KUeQQjr9/Q)" This is a multi-part message in MIME format. --Boundary_(ID_mGOXU9nnP8f6KUeQQjr9/Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Hesham, Section 5.4.2 When sending a binding update from a visited network that supports IPv6, the mobile node MUST follow the rules specified in [RFC3775]. In addition, if the mobile node has an IPv4 home address or needs one, it MUST include the IPv4 home address option in the mobility header. Does the IPv4 home address option must be include in Binding Update even if BU is send for extend binding lifetime? I think it is redundant since only IPv6 HoA is the key for BCE lookup. In maillist, I find some disscussion mails about this quesion, but I can't find the reason why all BU must include IPv4 home address option. Regards, Xiaoyan --Boundary_(ID_mGOXU9nnP8f6KUeQQjr9/Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi Hesham,
 
Section 5.4.2
 
   When sending a binding update from a visited network that supports
   IPv6, the mobile node MUST follow the rules specified in [RFC3775].
   In addition, if the mobile node has an IPv4 home address or needs
   one, it MUST include the IPv4 home address option in the mobility
   header. 
 
Does the IPv4 home address option must be include in Binding Update even if BU is send for extend binding lifetime?
I think it is redundant since only IPv6 HoA is the key for BCE lookup. In maillist, I find some disscussion mails about this quesion, but I can't find the reason why all BU must include IPv4 home address option.
 

Regards,
Xiaoyan
--Boundary_(ID_mGOXU9nnP8f6KUeQQjr9/Q)-- --===============1802406267== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1802406267==-- From mext-bounces@ietf.org Sat Jan 17 06:40:58 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 430203A69D9; Sat, 17 Jan 2009 06:40:58 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475E93A69D9 for ; Sat, 17 Jan 2009 06:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khcLDQD5n6j5 for ; Sat, 17 Jan 2009 06:40:56 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 6E5243A6947 for ; Sat, 17 Jan 2009 06:40:55 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LOCLl-0002PA-Ea; Sun, 18 Jan 2009 01:40:37 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Sun, 18 Jan 2009 01:40:33 +1100 From: Hesham Soliman To: Shi Xiaoyan Message-ID: Thread-Topic: IPv4 home address option in DSMIP Thread-Index: Acl4e/1gnce/8wg+TyC7IjHZuRMuKQANY/Ok In-Reply-To: <006001c9787b$fdd0cd40$bd946f0a@china.huawei.com> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] IPv4 home address option in DSMIP X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 17/01/09 7:17 PM, "Shi Xiaoyan" wrote: > Hi Hesham, > > Section 5.4.2 > > When sending a binding update from a visited network that supports > IPv6, the mobile node MUST follow the rules specified in [RFC3775]. > In addition, if the mobile node has an IPv4 home address or needs > one, it MUST include the IPv4 home address option in the mobility > header. > > Does the IPv4 home address option must be include in Binding Update even if > BU is send for extend binding lifetime? => Yes. > I think it is redundant since only IPv6 HoA is the key for BCE lookup. In > maillist, I find some disscussion mails about this quesion, but I can't find > the reason why all BU must include IPv4 home address option. => Two reasons: 1. This is how a BU works, all options need to be included in order for a binding to be refreshed 2. The only way the MN can delete the IPv4 binding is to not include it in the BU. Hesham > > > Regards, > Xiaoyan _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Jan 18 17:49:11 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3AEC3A691C; Sun, 18 Jan 2009 17:49:11 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DA9F3A691B for ; Sun, 18 Jan 2009 17:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.166 X-Spam-Level: X-Spam-Status: No, score=0.166 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N688US8Cf5OS for ; Sun, 18 Jan 2009 17:49:09 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 232F93A67D6 for ; Sun, 18 Jan 2009 17:49:09 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDP002RA3P3MK@szxga04-in.huawei.com> for mext@ietf.org; Mon, 19 Jan 2009 09:48:39 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDP0086I3P31Y@szxga04-in.huawei.com> for mext@ietf.org; Mon, 19 Jan 2009 09:48:39 +0800 (CST) Received: from s68128b ([10.111.148.189]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDP003MQ3P27G@szxml04-in.huawei.com> for mext@ietf.org; Mon, 19 Jan 2009 09:48:39 +0800 (CST) Date: Mon, 19 Jan 2009 09:48:38 +0800 From: Shi Xiaoyan In-reply-to: To: 'Hesham Soliman' Message-id: <002901c979d8$0cc8c1b0$bd946f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acl4e/1gnce/8wg+TyC7IjHZuRMuKQANY/OkAEesPfA= Cc: mext@ietf.org Subject: Re: [MEXT] IPv4 home address option in DSMIP X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Saturday, January 17, 2009 10:41 PM > To: Shi Xiaoyan > Cc: mext@ietf.org > Subject: Re: IPv4 home address option in DSMIP > > > On 17/01/09 7:17 PM, "Shi Xiaoyan" wrote: > > > > I think it is redundant since only IPv6 HoA is the key for > BCE lookup. > > In maillist, I find some disscussion mails about this > quesion, but I > > can't find the reason why all BU must include IPv4 home > address option. > > => Two reasons: > 1. This is how a BU works, all options need to be included in > order for a binding to be refreshed 2. The only way the MN > can delete the IPv4 binding is to not include it in the BU. 1. BU without IPv4 home address option works well for extending lifetime. I can't understand what you said "how a BU works". Is there any Specification to require that BU for exending lifetime must be consistent with BU for first register? Is there any special effect? In fact, with more and more extension for BU in future, the requirement that BU for exending lifetime must be consistent with BU for first register will cause unnecessary load. 2. We can find many other ways to delete the IPv4 binding if it is consensus that re-registration BU does not have to include the IPv4 HAO. It could not be a resason for re-registration BU must including IPv4 HAO. > > Hesham > > > > > > > Regards, > > Xiaoyan > Regards, Xiaoyan _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jan 19 02:22:36 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76D63A6A30; Mon, 19 Jan 2009 02:22:36 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86843A677C for ; Mon, 19 Jan 2009 02:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPZTUMeI9bZ2 for ; Mon, 19 Jan 2009 02:22:34 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id AE9823A6A30 for ; Mon, 19 Jan 2009 02:22:33 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 11:22:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jan 2009 11:22:05 +0100 Message-ID: In-Reply-To: <703169.3551.qm@web111408.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl3/77zu7VjWC1CTb+8rnGTNkg+XQCHLB9A References: <703169.3551.qm@web111408.mail.gq1.yahoo.com> From: To: , , , , X-OriginalArrivalTime: 19 Jan 2009 10:22:06.0618 (UTC) FILETIME=[C77CA7A0:01C97A1F] Cc: jari.arkko@piuha.net Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Behcet, If relevant in MIP context: there is a proposal to use GRE key as a tunnel = identifier to solve the tunnel loop issue (IETF73/ intarea open meeting/pre= sentation of draft-ng-intarea-tunnel-loop-00). Regards, Pierrick ________________________________________ De=A0: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de B= ehcet Sarikaya Envoy=E9=A0: vendredi 16 janvier 2009 18:27 =C0=A0: Hesham Soliman; Vijay Devarapalli; Pasi.Eronen@nokia.com; mext@ietf= .org Cc=A0: Jari Arkko Objet=A0: Re: [MEXT] GRE support in DSMIPv6 - AD review ________________________________________ From: Hesham Soliman To: Vijay Devarapalli ; Pasi.Eronen@nokia.com; mext@iet= f.org Cc: Jari Arkko Sent: Thursday, January 15, 2009 7:00:13 PM Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review > Hi Pasi, Hesham, > = > The TLV header was specified in the DS-MIPv6 document after rather a > long and acrimonious debate on the former MIP6 mailing list. There were > atleast two consensus calls that were run at that time. =3D> I don't realy want to get into that, we all know there was no concensus and we had to teleconference to come up with the existing method Anytime you have > a UDP header with IPv4/IPv6/GRE header following it, you need the TLV > header. = =A0 At that time, there were folks arguing for using GRE > encapsulation with MIPv6 also. = [behcet] I couldn't understand why MN would need to support GRE. Can someon= e explain the use case? =A0 Thanks, =A0 Behcet =A0 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jan 19 04:25:09 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A303A6911; Mon, 19 Jan 2009 04:25:08 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D833A695B; Mon, 19 Jan 2009 04:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.085 X-Spam-Level: ** X-Spam-Status: No, score=2.085 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P75R+hzWI9Vg; Mon, 19 Jan 2009 04:25:05 -0800 (PST) Received: from ricky.india.internal.net (unknown [59.145.147.70]) by core3.amsl.com (Postfix) with ESMTP id 273F33A6821; Mon, 19 Jan 2009 04:25:03 -0800 (PST) Received: from Magesh (magesh.india.internal.net.16.172.in-addr.arpa [172.16.8.41] (may be forged)) by ricky.india.internal.net (8.12.10/8.12.10) with ESMTP id n0JCCdxA016217; Mon, 19 Jan 2009 17:42:39 +0530 Message-Id: <200901191212.n0JCCdxA016217@ricky.india.internal.net> From: "Magesh Shanmugam" To: "'Ahmad Muhanna'" Date: Mon, 19 Jan 2009 18:00:27 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acl6MbWiLAZ2wPBbRNyWgrShkUmdqQ== X-Cyberoam-Version: 9.5.4.86 X-Cyberoam-smtpxy-version: 0.0.4.2 X-Cyberoam-AV-Status: Clean X-Cyberoam-Proto: SMTP X-Cyberoam-AV-Policy: None X-Cyberoam-AS-Policy: Global Spam Policy Cc: netlmm@ietf.org, mext@ietf.org Subject: [MEXT] Processing of BRI (Binding Revocation) by MAG X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1312599354==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1312599354== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01C97A5F.DE527F00" This is a multi-part message in MIME format. ------=_NextPart_000_0081_01C97A5F.DE527F00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ahmad I have a query regarding the handling of Binding Revocation by MAG for individual binding session. Following is the scenario: Scenario: 1. Proxy Mobile Initial Registration, MAG sends PBU to LMA with HNP option set to ALL_ZERO for MN 1. 2. LMA in turn sends back PBA with 3 HNP(s) assigned to MN 1 and updates Binding Cache Entry. 3. MAG updates Binding Update List entry and sends Router Advertisement to the MN with all the prefixes and prefix lifetime. Note: MAG considers the prefix lifetime as binding lifetime and starts Binding Lifetime timer. 4. Bi-directional tunnel is established between MAG and LMA. 5. Prefix Route(s) are created for all the prefixes at MAG. 6. MN 1 gets one IP Address from the alloted 3 HNP(s). 7. LMA sends BRI message with one HNP (out of the alloted 3 HNPs) with revoke trigger as "ADMINISTRATIVE REASON". After step 7, when MAG receives BRI message with only one HNP and MN-ID: Queries: 1. Will MAG stop the binding lifetime timer (started after binding session establishment), due to the received BRI message? 2. Will MAG delete the complete Binding Update List maintained for the MN (MN 1) or will it delete only the corresponding HNP entry from the BUL and send RA message to MN 1 (eventhough the IP Address used by MN is not from the HNP received in BRI message)? If it deletes only the corresponding HNP entry, what will happen to the Binding Lifetime timer? Thanks S Magesh ------=_NextPart_000_0081_01C97A5F.DE527F00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ahmad
 
I have = a query=20 regarding the handling of Binding Revocation by MAG for individual = binding=20 session. 
Following is the=20 scenario:
 
Scenario:
 
1. = Proxy Mobile=20 Initial Registration, MAG sends PBU to LMA with HNP option set to = ALL_ZERO for=20 MN 1.
2. LMA = in turn sends=20 back PBA with 3 HNP(s) assigned to MN 1 and updates Binding Cache=20 Entry.
3. MAG = updates=20 Binding Update List entry and sends Router Advertisement to the MN with = all the=20
   =20 prefixes and prefix lifetime.
   =20 Note: MAG considers the prefix lifetime as binding lifetime and starts = Binding=20 Lifetime timer.
4. = Bi-directional=20 tunnel is established between MAG and LMA. 
5. = Prefix Route(s)=20 are created for all the prefixes at MAG.
6. MN = 1 gets one IP=20 Address from the alloted 3 HNP(s).
7. LMA = sends BRI=20 message with one HNP (out of the alloted 3 HNPs) with revoke trigger as=20
  =20 "ADMINISTRATIVE REASON".
 
After = step 7, when=20 MAG receives BRI message with only one HNP and = MN-ID:
 
Queries:
 
1. = Will MAG stop the=20 binding lifetime timer (started after binding session establishment), = due to=20 the
   =20 received BRI message?
2. = Will MAG delete=20 the complete Binding Update List maintained for the MN (MN 1) or will it = delete
   =20 only the corresponding HNP entry from the BUL and send RA message to MN = 1=20 (eventhough
   =20 the IP Address used by MN is not from the HNP received in BRI = message)?  If=20 it deletes only the
   =20 corresponding HNP entry, what will happen to the Binding Lifetime=20 timer?
 
Thanks
S=20 Magesh
------=_NextPart_000_0081_01C97A5F.DE527F00-- --===============1312599354== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1312599354==-- From mext-bounces@ietf.org Mon Jan 19 04:42:03 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5A93A68B3; Mon, 19 Jan 2009 04:42:03 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39DA228C113 for ; Mon, 19 Jan 2009 04:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqP91pp2Q0SV for ; Mon, 19 Jan 2009 04:41:56 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 05E3B3A67E5 for ; Mon, 19 Jan 2009 04:41:55 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LOsr1-0003fA-Vd; Mon, 19 Jan 2009 23:03:44 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 19 Jan 2009 23:03:40 +1100 From: Hesham Soliman To: Shi Xiaoyan Message-ID: Thread-Topic: IPv4 home address option in DSMIP Thread-Index: Acl4e/1gnce/8wg+TyC7IjHZuRMuKQANY/OkAEesPfAAF25TZw== In-Reply-To: <002901c979d8$0cc8c1b0$bd946f0a@china.huawei.com> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] IPv4 home address option in DSMIP X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org >> => Two reasons: >> 1. This is how a BU works, all options need to be included in >> order for a binding to be refreshed 2. The only way the MN >> can delete the IPv4 binding is to not include it in the BU. > > 1. BU without IPv4 home address option works well for extending lifetime. I > can't understand what you said "how a BU works". Is there any Specification > to require that BU for exending lifetime must be consistent with BU for > first register? Is there any special effect? In fact, with more and more > extension for BU in future, the requirement that BU for exending lifetime > must be consistent with BU for first register will cause unnecessary load. => Yes I know that will use more bandwidth but I don't understand what you're objecting to. Implementations copy the contents of the new BU into the BC to replace the old entry, as specified in 3775. So a new BU overwrites the old one unless you desgin a new option per extension that tells the receiver to only refresh. > > 2. We can find many other ways to delete the IPv4 binding if it is consensus > that re-registration BU does not have to include the IPv4 HAO. It could not > be a resason for re-registration BU must including IPv4 HAO. => Well, that's the reason now, if you have better ideas, other than designing a new option per extension please send them to the list. This is already a bit late given that I'm making the last update for IESG comments. Hesham > >> >> Hesham >> >>> >>> >>> Regards, >>> Xiaoyan >> > > Regards, > Xiaoyan > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jan 19 05:32:57 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39E23A6A48; Mon, 19 Jan 2009 05:32:57 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F084E28C137 for ; Mon, 19 Jan 2009 05:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsUFKRghPBez for ; Mon, 19 Jan 2009 05:32:55 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id EF0403A695B for ; Mon, 19 Jan 2009 05:32:54 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0JDWDQs028425; Mon, 19 Jan 2009 15:32:25 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 15:32:18 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 15:32:08 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 15:32:03 +0200 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 19 Jan 2009 14:32:02 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Mon, 19 Jan 2009 14:32:02 +0100 From: To: , , , Date: Mon, 19 Jan 2009 14:32:05 +0100 Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl4Ng0X3joRG3lYgEOmRZ1GAGCiYgCA8M4A Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E7640960@NOK-EUMSG-01.mgdnok.nokia.com> References: <703169.3551.qm@web111408.mail.gq1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2009 13:32:03.0424 (UTC) FILETIME=[50833E00:01C97A3A] X-Nokia-AV: Clean Cc: jari.arkko@piuha.net Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hesham Soliman wrote: > >> At that time, there were folks arguing for using GRE > >> encapsulation with MIPv6 also. > > [behcet] I couldn't understand why MN would need to support > > GRE. Can someone explain the use case? > > => It was done for NETLMM. Technically and practically speaking it > will never be used by the MN. And there is no reason for doing so. > Whenever GRE is used it's used within the network not from the host. If that's the case, why not specify it for PMIPv6 only? (That would potentially simplify the specs -- you don't e.g. need to think how "client MIPv6" IPsec (a messy area already) would work with GRE. PMIPv6+IPsec is much simpler case, and might not need any new text for GRE.) Best regards, Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jan 19 05:45:59 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56AC28C1C9; Mon, 19 Jan 2009 05:45:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0152128C1C9 for ; Mon, 19 Jan 2009 05:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRSuZU8rc3B4 for ; Mon, 19 Jan 2009 05:45:57 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 231983A67E5 for ; Mon, 19 Jan 2009 05:45:56 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LOuRW-0005C3-C8; Tue, 20 Jan 2009 00:45:30 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 20 Jan 2009 00:45:22 +1100 From: Hesham Soliman To: , , , Message-ID: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl4Ng0X3joRG3lYgEOmRZ1GAGCiYgCA8M4AAACXDLY= In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E7640960@NOK-EUMSG-01.mgdnok.nokia.com> Mime-version: 1.0 Cc: jari.arkko@piuha.net Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > Hesham Soliman wrote: > >>>> At that time, there were folks arguing for using GRE >>>> encapsulation with MIPv6 also. >>> [behcet] I couldn't understand why MN would need to support >>> GRE. Can someone explain the use case? >> >> => It was done for NETLMM. Technically and practically speaking it >> will never be used by the MN. And there is no reason for doing so. >> Whenever GRE is used it's used within the network not from the host. > > If that's the case, why not specify it for PMIPv6 only? => You're asking the wrong person :) I never wanted this. I fully support moving this out of the draft. Hesham > > (That would potentially simplify the specs -- you don't e.g. need to > think how "client MIPv6" IPsec (a messy area already) would work with > GRE. PMIPv6+IPsec is much simpler case, and might not need any new > text for GRE.) > > Best regards, > Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jan 19 06:11:03 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB883A6B54; Mon, 19 Jan 2009 06:11:03 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321F428C113; Mon, 19 Jan 2009 06:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.452 X-Spam-Level: X-Spam-Status: No, score=-6.452 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaJthwaI0Atc; Mon, 19 Jan 2009 06:11:00 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id DFF253A67E5; Mon, 19 Jan 2009 06:10:59 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n0JE6p907463; Mon, 19 Jan 2009 14:06:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jan 2009 08:10:27 -0600 Message-ID: In-Reply-To: <200901191212.n0JCCdxA016217@ricky.india.internal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Processing of BRI (Binding Revocation) by MAG Thread-Index: Acl6MbWiLAZ2wPBbRNyWgrShkUmdqQADGOwA References: <200901191212.n0JCCdxA016217@ricky.india.internal.net> From: "Ahmad Muhanna" To: "Magesh Shanmugam" Cc: netlmm@ietf.org, mext@ietf.org Subject: Re: [MEXT] Processing of BRI (Binding Revocation) by MAG X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1684729884==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1684729884== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97A3F.B520E0AE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97A3F.B520E0AE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Ahmad =20 I have a query regarding the handling of Binding Revocation by MAG for individual binding session. =20 Following is the scenario: =20 Scenario: =20 1. Proxy Mobile Initial Registration, MAG sends PBU to LMA with HNP option set to ALL_ZERO for MN 1. 2. LMA in turn sends back PBA with 3 HNP(s) assigned to MN 1 and updates Binding Cache Entry. 3. MAG updates Binding Update List entry and sends Router Advertisement to the MN with all the=20 prefixes and prefix lifetime.=20 Note: MAG considers the prefix lifetime as binding lifetime and starts Binding Lifetime timer. 4. Bi-directional tunnel is established between MAG and LMA. =20 5. Prefix Route(s) are created for all the prefixes at MAG. 6. MN 1 gets one IP Address from the alloted 3 HNP(s). 7. LMA sends BRI message with one HNP (out of the alloted 3 HNPs) with revoke trigger as=20 "ADMINISTRATIVE REASON". =20 After step 7, when MAG receives BRI message with only one HNP and MN-ID: =20 Queries: =20 1. Will MAG stop the binding lifetime timer (started after binding session establishment), due to the received BRI message? 2. Will MAG delete the complete Binding Update List maintained for the MN (MN 1) or will it delete only the corresponding HNP entry from the BUL and send RA message to MN 1 (eventhough the IP Address used by MN is not from the HNP received in BRI message)? If it deletes only the corresponding HNP entry, what will happen to the Binding Lifetime timer?=20 =20 [Ahmad] If the LMA assigned 3 HNP for MN1, then if the LMA would like to revoke all of the HNPs, the LMA have one of the following options: =20 1. Send BRI with MN-ID option ONLY. This means that all HNPs are revoked, or 2. Send a BRI with MN-ID and all HNPs. =20 Although, the draft recommend Number 1 BUT does not prevent No. 2. =20 On the other hand, if the LMA sends a BRI with MN-ID and a single HNP, then the MAG MUST consider the revocation of that single HNP and MUST NOT remove the MN1 from the BUL. =20 Hope this help. =20 Regards, Ahmad=20 =20 Thanks S Magesh ------_=_NextPart_001_01C97A3F.B520E0AE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Ahmad
 
I = have a query=20 regarding the handling of Binding Revocation by MAG for individual = binding=20 session. 
Following is the=20 scenario:
 
Scenario:
 
1. = Proxy Mobile=20 Initial Registration, MAG sends PBU to LMA with HNP option set to = ALL_ZERO for=20 MN 1.
2. = LMA in turn=20 sends back PBA with 3 HNP(s) assigned to MN 1 and updates Binding = Cache=20 Entry.
3. = MAG updates=20 Binding Update List entry and sends Router Advertisement to the MN = with all=20 the
   =20 prefixes and prefix lifetime.
   =20 Note: MAG considers the prefix lifetime as binding lifetime and starts = Binding=20 Lifetime timer.
4. = Bi-directional=20 tunnel is established between MAG and LMA. 
5. = Prefix Route(s)=20 are created for all the prefixes at MAG.
6. = MN 1 gets one=20 IP Address from the alloted 3 HNP(s).
7. = LMA sends BRI=20 message with one HNP (out of the alloted 3 HNPs) with revoke trigger = as=20
  =20 "ADMINISTRATIVE REASON".
 
After step 7, when=20 MAG receives BRI message with only one HNP and = MN-ID:
 
Queries:
 
1. = Will MAG stop=20 the binding lifetime timer (started after binding session = establishment), due=20 to the
   =20 received BRI message?
2. = Will MAG delete=20 the complete Binding Update List maintained for the MN (MN 1) or will = it=20 delete
   =20 only the corresponding HNP entry from the BUL and send RA message to = MN 1=20 (eventhough
   =20 the IP Address used by MN is not from the HNP received in BRI = message)? =20 If it deletes only the
    corresponding HNP entry, what will happen = to the=20 Binding Lifetime timer? 
 
[Ahmad]
If the LMA assigned 3 = HNP=20 for MN1, then if the LMA would like to revoke all of the HNPs, = the=20 LMA have one of the following=20 options:
 
1. Send BRI with = MN-ID option=20 ONLY. This means that all HNPs are revoked,=20 or
2. Send a BRI with = MN-ID and all=20 HNPs.
 
Although, the draft = recommend=20 Number 1 BUT does not prevent No. = 2.
 
On the other hand, if = the LMA=20 sends a BRI with MN-ID and a single HNP, then the MAG MUST = consider the=20 revocation of that single HNP and MUST NOT remove the MN1 from the=20 BUL.
 
Hope this=20 help.
 
Regards,
Ahmad 
 
Thanks
S=20 Magesh
------_=_NextPart_001_01C97A3F.B520E0AE-- --===============1684729884== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1684729884==-- From mext-bounces@ietf.org Mon Jan 19 10:09:43 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC583A69CE; Mon, 19 Jan 2009 10:09:43 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4176D3A67D7 for ; Mon, 19 Jan 2009 10:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUwy029WwbCG for ; Mon, 19 Jan 2009 10:09:41 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 757553A69CE for ; Mon, 19 Jan 2009 10:09:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,290,1231113600"; d="scan'208";a="130785693" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 19 Jan 2009 18:09:25 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n0JI9Pmj029185; Mon, 19 Jan 2009 10:09:25 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0JI9Pbh002031; Mon, 19 Jan 2009 18:09:25 GMT Date: Mon, 19 Jan 2009 10:09:25 -0800 (PST) From: Sri Gundavelli To: Behcet Sarikaya In-Reply-To: <703169.3551.qm@web111408.mail.gq1.yahoo.com> Message-ID: References: <703169.3551.qm@web111408.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-342241519-1232388565=:17388" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2184; t=1232388565; x=1233252565; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20GRE=20support=20in=20DSMIPv6=2 0-=20AD=20review |Sender:=20; bh=nx/biQ2rkJkOhyo/yRB7U77ACxZPmo+jfX+MtIScysg=; b=bjDI4MPZ/R2kvmyfBLSm6gck1FEVpvSA+QCrcFgRp9q0N4gzMD6Opb97IX jqc0be9oSyAepBjFy0BuGnalcfgycbsOs41nC8EDjUGPfAAvAzTDpTezTmRn STzNPDUU6O; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Jari Arkko , mext@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-342241519-1232388565=:17388 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 16 Jan 2009, Behcet Sarikaya wrote: > [behcet] I couldn't understand why MN would need to support GRE. Can some= one explain the use case? > =A0 This issue was discussed at length. Many reasons were cited as why the GRE encapsulation mode may be needed in client-based mobility and why it should not be restricted to network elements alone. The LMA element in Proxy Mobile IPv6 is a feature extension to the Mobile IPv6 home agent. They have a strong relation. If some one implements home agent function, implements the data plane with all the hardware support for GRE and it cant be leveraged when supporting client-based mobile nodes ? Its the same home agent that serves both types of nodes. The options that we are standardizing NETLMM or MEXT, each should not take a different path. Its not that we have one revocation option for PMIP, one for NEMO and the other for MIP6. Keeping them together will save implementors to leverage all these features and resources across. GRE is another enapsulation mode, it exists with much richer semantics than IPv6-in-IPv6. The ability to carry non IP traffic, I'm not saying I support this for carrying IPX/AT traffic, but the point that its a useful encapsation mode that exists in MIP4 and cant be ignored for good reasons. Sri > Thanks, > =A0 > Behcet > > >> Hi Pasi, Hesham, >> >> The TLV header was specified in the DS-MIPv6 document after rather a >> long and acrimonious debate on the former MIP6 mailing list. There were >> atleast two consensus calls that were run at that time. > > =3D> I don't realy want to get into that, we all know there was no concen= sus > and we had to teleconference to come up with the existing method > > Anytime you have >> a UDP header with IPv4/IPv6/GRE header following it, you need the TLV >> header. > > > ---559023410-342241519-1232388565=:17388 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ---559023410-342241519-1232388565=:17388-- From mext-bounces@ietf.org Mon Jan 19 10:44:27 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 971CA3A6907; Mon, 19 Jan 2009 10:44:27 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2785C3A6907 for ; Mon, 19 Jan 2009 10:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.823 X-Spam-Level: X-Spam-Status: No, score=-5.823 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVi6D5iJEUsl for ; Mon, 19 Jan 2009 10:44:25 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id F3D8D3A67E2 for ; Mon, 19 Jan 2009 10:44:24 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0JIhM9q021252; Mon, 19 Jan 2009 20:43:32 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 20:42:36 +0200 Received: from vaebe112.NOE.Nokia.com ([10.160.244.81]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 20:42:36 +0200 Received: from 10.241.58.170 ([10.241.58.170]) by vaebe112.NOE.Nokia.com ([10.160.244.81]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Jan 2009 18:42:35 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 19 Jan 2009 12:42:46 -0600 From: Basavaraj Patil To: Sri Gundavelli , Behcet Sarikaya Message-ID: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl6Zbha7heYZ5S2oUms4ImlZglioQ== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 19 Jan 2009 18:42:36.0328 (UTC) FILETIME=[B296C280:01C97A65] X-Nokia-AV: Clean Cc: Jari Arkko , mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I still fail to really understand why GRE encapsulation is needed for host based mobility (DSMIP6). The only argument below is that it provides "richer semantics than IPv6-in-IPv6". Can you provide an explicit example of how the richer semantics are useful vs the IP-in-IP encapsulation for DSMIP6? Cheers, -Raj On 1/19/09 12:09 PM, "Sri Gundavelli" wrote: > = > = > On Fri, 16 Jan 2009, Behcet Sarikaya wrote: > = >> [behcet] I couldn't understand why MN would need to support GRE. Can som= eone >> explain the use case? >> =A0 > = > This issue was discussed at length. Many reasons were cited as why the > GRE encapsulation mode may be needed in client-based mobility and why > it should not be restricted to network elements alone. > = > The LMA element in Proxy Mobile IPv6 is a feature extension to the > Mobile IPv6 home agent. They have a strong relation. If some one > implements home agent function, implements the data plane with all > the hardware support for GRE and it cant be leveraged when supporting > client-based mobile nodes ? Its the same home agent that serves both > types of nodes. > = > The options that we are standardizing NETLMM or MEXT, each should not > take a different path. Its not that we have one revocation option for > PMIP, one for NEMO and the other for MIP6. Keeping them together will > save implementors to leverage all these features and resources across. > = > GRE is another enapsulation mode, it exists with much richer semantics > than IPv6-in-IPv6. The ability to carry non IP traffic, I'm not saying > I support this for carrying IPX/AT traffic, but the point that its a > useful encapsation mode that exists in MIP4 and cant be ignored for > good reasons. > = > Sri > = > = > = > = > = > = > = > = > = > = >> Thanks, >> =A0 >> Behcet >> = >> = >>> Hi Pasi, Hesham, >>> = >>> The TLV header was specified in the DS-MIPv6 document after rather a >>> long and acrimonious debate on the former MIP6 mailing list. There were >>> atleast two consensus calls that were run at that time. >> = >> =3D> I don't realy want to get into that, we all know there was no conce= nsus >> and we had to teleconference to come up with the existing method >> = >> Anytime you have >>> a UDP header with IPv4/IPv6/GRE header following it, you need the TLV >>> header. >> = >> = >> = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jan 19 11:01:23 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC8028C178; Mon, 19 Jan 2009 11:01:23 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D701D28C113 for ; Mon, 19 Jan 2009 11:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GG3lkaUCsqX2 for ; Mon, 19 Jan 2009 11:01:20 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 633F928C157 for ; Mon, 19 Jan 2009 11:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=pstupar@qualcomm.com; q=dns/txt; s=qcdkim; t=1232391664; x=1263927664; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20Comments=20on=20draft-ietf- mext-binding-revocation-02|Date:=20Mon,=2019=20Jan=202009 =2018:59:40=20-0000|Message-ID:=20|In-Reply-To:=20< C5A96676FCD00745B64AE42D5FCC9B6E1CA46D5F@zrc2hxm0.corp.no rtel.com>|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20Comments=20on=20draft-ietf-mext-binding- revocation-02|Thread-Index:=20AclbLn3taqHuU6TUSgeN3dxQhl2 ykQArrD7gALKdDZAEWRBysAGXgEdQAGd43wAAl3PFsA=3D=3D |References:=20=20=20=20 =20=20|From:=20"Stupar,=20Patrick"=20|To:=20"Ahmad=20Muhanna"=20|Cc:=20|X-OriginalArrivalTime:=20 19=20Jan=202009=2019:01:00.0725=20(UTC)=20FILETIME=3D[44D C5E50:01C97A68]|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2 777,5500"=3B=20a=3D"14777523"; bh=Eq/Jzeg2lETRZmDmvHbWJrboKdGbWVP7tu1jO5OLxIE=; b=bSJKpPwTAKqm7BYJD7hVfT7pVxi8v+ehVwWCJ4RhEpKwGWZRNscQog4c suU+bJ4bV90ZuMotFV3BbuNsIO4EUkhaWt1Ir9bpXhMH+HFF/GHLfZiYP Xa7wNRs+ZIfAf5mRh9ngYFRADp05cWJDvFWaJFDW4qqSAR+3UfTzW7B59 M=; X-IronPort-AV: E=McAfee;i="5300,2777,5500"; a="14777523" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jan 2009 11:01:04 -0800 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0JJ14Sj016527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Jan 2009 11:01:04 -0800 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0JJ12Wv021114; Mon, 19 Jan 2009 11:01:03 -0800 Received: from EUEX02.eu.qualcomm.com ([10.222.228.33]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 11:01:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jan 2009 18:59:40 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-mext-binding-revocation-02 Thread-Index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQArrD7gALKdDZAEWRBysAGXgEdQAGd43wAAl3PFsA== References: From: "Stupar, Patrick" To: "Ahmad Muhanna" X-OriginalArrivalTime: 19 Jan 2009 19:01:00.0725 (UTC) FILETIME=[44DC5E50:01C97A68] Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, Please see below. Best Regards, Patrick > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Friday, January 16, 2009 7:51 PM > To: Stupar, Patrick > Cc: mext@ietf.org > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > Hi Patrick, > Thanks. One slight modification below. > > Regards, > Ahmad > > > > -----Original Message----- > > From: Stupar, Patrick [mailto:pstupar@qualcomm.com] > > Sent: Friday, January 16, 2009 11:18 AM > > To: Muhanna, Ahmad (RICH1:2H10) > > Cc: mext@ietf.org > > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > > > > > [Ahmad] > > > I see what you are saying. I assumed that this is in the > > form of NAI. > > > we > > > can add some text to clarify that, would that address your > > concern or > > > you have in mind a possible different format? > > > > I think this would be good. Either a definition in section > > 2.2 or a clarification in the text would be fine with me. > > [Ahmad] > Sure. > > > > > > > > [Ahmad] > > > Currently, neither the HoA nor the CoA is included in the > > BRI message. > > > Are you suggesting that we add those options as valid ones > > in the BRI? > > > > No I am not. What I meant here is that HoA is in the routing > > header of the packet containing the BRI. Checking of HoA > > would be enough IMO. It could be moved to the previous bullet > > of the list as in the following proposed text: > > OLD TEXT: > > " > > o The mobile node MUST verify that the IP address in the type 2 > > routing header is its Home Address. > > > > o If the Acknowledgement (A) bit is set in the Binding Revocation > > Indication and the MN has the BCE in registered state, > > the mobile > > node MUST send a Binding Revocation Acknowledgement. > > However, in > > all other cases when the (A) bit is set in the BRI, the mobile > > node SHOULD send a Binding Revocation Acknowledgement. In all > > cases, the mobile node MUST follow Section 11.2 when send a BRA > > using the appropriate status code. > > " > > NEW TEXT > > " > > o The mobile node MUST verify that the IP address in the type 2 > > routing header is its Home Address and that its Binding Update > > List contains an entry for that Home Address. If one of > > the tests fails, > > the mobile node SHOULD silently discard the received BRI > > message. > > > > o If the Acknowledgement (A) bit is set in the Binding Revocation > > Indication, the mobile > > node MUST send a Binding Revocation Acknowledgement. > > However, in > > all other cases when the (A) bit is set in the BRI, the mobile > > node SHOULD send a Binding Revocation Acknowledgement. In all > > cases, the mobile node MUST follow Section 11.2 when send a BRA > > using the appropriate status code. > > " > > [Ahmad] > I am not sure I follow the second bullet of the "NEW TEXT". What about > the following modified text: > > "MODIFIED TEXT" > > o The mobile node MUST verify that the IP address in the type 2 > routing header is its Home Address and that its Binding Update > List contains an entry for that Home Address. If one of the > tests, > fails the mobile node SHOULD silently discard the received BRI > message. > > o If the Acknowledgement (A) bit is set in the Binding Revocation > Indication and its Binding Update List contains an entry for the > IP address in the type 2 routing header, the mobile node MUST > send a Binding Revocation Acknowledgement. However, in > all other cases when the (A) bit is set in the BRI, the mobile > node SHOULD send a Binding Revocation Acknowledgement. In all > cases, the mobile node MUST follow Section 11.2 when send a BRA > using the appropriate status code. > [Patrick] The actions in the first bullet apply to any received BRI (also to those with the A bit set). Having said that, in the second bullet it is only required to specify the additional operation (i.e. sending a BRA) the MN has to perform when the A bit is set. IMO the text you added is redundant and not required. Do you have some particular scenario I am missing? > > > > Please note that the proposed text overlaps with the last > > bullet listed in section 11.2. I would remove that as in the > > following: > > > > Old text: > > "11.2. Sending Binding Revocation Acknowledgement > > > > When the mobile node receive a valid Binding Revocation Indication > > with the (A) bit is set from its home agent and while > > having this BCE > > in registered state, the mobile node MUST send a packet to its > home > > agent containing a Binding Revocation Acknowledgement according to > > the procedure in Section 7.1 and the following: > > > > o The mobile node MUST set the status field to successful > > to reflect > > that it has received the Binding Revocation Indication and > > acknowledge that its IP connectivity with its home > > agent has been > > revoked. > > > > o The destination IP address of the IPv6 packet of the Binding > > Revocation Acknowledgement is set to the source IP > > address of the > > received IPv6 packet of the Binding Revocation Indication. The > > Mobile Node MUST include its home address in the Home Address > > option in the Destination Option. > > > > o If the mobile node receives a Binding Revocation > > Indication from a > > home agent which the mobile node does not have a registered > > binding with, the mobile node SHOULD silently discard the BRI > > message. The mobile node should continue to use its > > assigned HoA > > to access its IP mobility service." > > > > New text: > > "11.2. Sending Binding Revocation Acknowledgement > > > > When the mobile node receive a valid Binding Revocation Indication > > with the (A) bit is set from its home agent and while > > having this BCE > > in registered state, the mobile node MUST send a packet to its > home > > agent containing a Binding Revocation Acknowledgement according to > > the procedure in Section 7.1 and the following: > > > > o The mobile node MUST set the status field to successful > > to reflect > > that it has received the Binding Revocation Indication and > > acknowledge that its IP connectivity with its home > > agent has been > > revoked. > > > > o The destination IP address of the IPv6 packet of the Binding > > Revocation Acknowledgement is set to the source IP > > address of the > > received IPv6 packet of the Binding Revocation Indication. The > > Mobile Node MUST include its home address in the Home Address > > option in the Destination Option." > > [Ahmad] > Sure. That is fair and good. > > Best Regards, > Ahmad _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jan 19 11:01:40 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93F2428C198; Mon, 19 Jan 2009 11:01:40 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B411528C190 for ; Mon, 19 Jan 2009 11:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csxOBRJsMg7y for ; Mon, 19 Jan 2009 11:01:38 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B357E28C157 for ; Mon, 19 Jan 2009 11:01:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,290,1231113600"; d="scan'208";a="130801400" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 19 Jan 2009 19:01:23 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0JJ1MUH006180; Mon, 19 Jan 2009 11:01:22 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0JJ1MTu013028; Mon, 19 Jan 2009 19:01:22 GMT Date: Mon, 19 Jan 2009 11:01:22 -0800 (PST) From: Sri Gundavelli To: Basavaraj Patil In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-351212254-1232391682=:17388" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4017; t=1232391682; x=1233255682; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20GRE=20support=20in=20DSMIPv6=2 0-=20AD=20review |Sender:=20; bh=4btztBoWFKcb5IJ6RffuJJrAjPVhVEaWbpWf2ZVkmkE=; b=nPft4Emz2ZQ858v8qx0kpjMLMwgkI5Cm5nXx4RXEAu8hiJMXwI/6cf7k9r 8sdKRERC1iShRIBnWhRuYX7LoEjIklAVr49DBl47gUrnFH7rl6ppBzqePIiq an3x6OYVX8; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Jari Arkko , mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-351212254-1232391682=:17388 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Raj, We went over all this list year back. You asked the same question, you got the same answers. There are no new arguments. If you want to ignore the use of GRE key in NEMO use, for marking different MNP flows for differential treatment on the HA, or the point of carrying legacy payload traffic, or about a single integrated HA/LMA serving mobile nodes and leveraging a common encap mode, you may so, but the fact reamins. Its useful in PMIP, it may be useful in NEMO, or may not be so useful in client-MIP, fine, lets not apply restrictions. If we have a home agent that can perform GRE switching in the hardware, its a good reason for me to leverage for all mobile flows and not build one more mode. We really should not be re-opening converged cases. There is a AD comment on lack of specification on the tunneling mode, we can easily fix that, rather dug open the whole mountain. Hesham spent lots of time on adding all the TLV and the related support, we dont have to waste all that, if there is some thing minor missing. Regards Sri On Mon, 19 Jan 2009, Basavaraj Patil wrote: > > I still fail to really understand why GRE encapsulation is needed for hos= t > based mobility (DSMIP6). > The only argument below is that it provides "richer semantics than > IPv6-in-IPv6". Can you provide an explicit example of how the richer > semantics are useful vs the IP-in-IP encapsulation for DSMIP6? > > Cheers, > -Raj > > > On 1/19/09 12:09 PM, "Sri Gundavelli" wrote: > >> >> >> On Fri, 16 Jan 2009, Behcet Sarikaya wrote: >> >>> [behcet] I couldn't understand why MN would need to support GRE. Can so= meone >>> explain the use case? >>> =A0 >> >> This issue was discussed at length. Many reasons were cited as why the >> GRE encapsulation mode may be needed in client-based mobility and why >> it should not be restricted to network elements alone. >> >> The LMA element in Proxy Mobile IPv6 is a feature extension to the >> Mobile IPv6 home agent. They have a strong relation. If some one >> implements home agent function, implements the data plane with all >> the hardware support for GRE and it cant be leveraged when supporting >> client-based mobile nodes ? Its the same home agent that serves both >> types of nodes. >> >> The options that we are standardizing NETLMM or MEXT, each should not >> take a different path. Its not that we have one revocation option for >> PMIP, one for NEMO and the other for MIP6. Keeping them together will >> save implementors to leverage all these features and resources across. >> >> GRE is another enapsulation mode, it exists with much richer semantics >> than IPv6-in-IPv6. The ability to carry non IP traffic, I'm not saying >> I support this for carrying IPX/AT traffic, but the point that its a >> useful encapsation mode that exists in MIP4 and cant be ignored for >> good reasons. >> >> Sri >> >> >> >> >> >> >> >> >> >> >>> Thanks, >>> =A0 >>> Behcet >>> >>> >>>> Hi Pasi, Hesham, >>>> >>>> The TLV header was specified in the DS-MIPv6 document after rather a >>>> long and acrimonious debate on the former MIP6 mailing list. There wer= e >>>> atleast two consensus calls that were run at that time. >>> >>> =3D> I don't realy want to get into that, we all know there was no conc= ensus >>> and we had to teleconference to come up with the existing method >>> >>> Anytime you have >>>> a UDP header with IPv4/IPv6/GRE header following it, you need the TLV >>>> header. >>> >>> >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > ---559023410-351212254-1232391682=:17388 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ---559023410-351212254-1232391682=:17388-- From mext-bounces@ietf.org Mon Jan 19 11:41:44 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A513A6944; Mon, 19 Jan 2009 11:41:44 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751123A6944 for ; Mon, 19 Jan 2009 11:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.761 X-Spam-Level: X-Spam-Status: No, score=-5.761 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbbTQ7jpBzMN for ; Mon, 19 Jan 2009 11:41:41 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 62FD13A6906 for ; Mon, 19 Jan 2009 11:41:41 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0JJeoaD006034; Mon, 19 Jan 2009 13:41:04 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 21:40:59 +0200 Received: from vaebe112.NOE.Nokia.com ([10.160.244.81]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 21:40:59 +0200 Received: from 10.241.58.170 ([10.241.58.170]) by vaebe112.NOE.Nokia.com ([10.160.244.81]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Jan 2009 19:40:59 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 19 Jan 2009 13:41:11 -0600 From: Basavaraj Patil To: Sri Gundavelli Message-ID: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl6beF/dmYtsob6u0KmntNXL++I/A== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 19 Jan 2009 19:40:59.0877 (UTC) FILETIME=[DADDE950:01C97A6D] X-Nokia-AV: Clean Cc: Jari Arkko , mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Sri, For the resolution of the IESG comments regarding the TLV header, I have said that this spec should get rid of it and if someone feels the need for it to be specified, they can do so (potential docs suggested being the IPv4 support I-D or the GRE Keys I-D in Netlmm WG). My comment was based on the reopening of the discussion regarding the need for GRE encapsulation in the context of DSMIP6. I agree that nothing has changed since we had this discussion a while ago and as you can tell neither has my opinion regarding the need for GRE for host based mobility. But I am fine with whatever is deemed as the consensus regarding the TLV header and/or GRE encapsulation support in the DSMIP6 I-D. -Raj On 1/19/09 1:01 PM, "Sri Gundavelli" wrote: > Raj, > = > We went over all this list year back. You asked the same question, > you got the same answers. There are no new arguments. If you want > to ignore the use of GRE key in NEMO use, for marking different MNP > flows for differential treatment on the HA, or the point of carrying > legacy payload traffic, or about a single integrated HA/LMA serving > mobile nodes and leveraging a common encap mode, you may so, but the > fact reamins. Its useful in PMIP, it may be useful in NEMO, or may not > be so useful in client-MIP, fine, lets not apply restrictions. If we > have a home agent that can perform GRE switching in the hardware, its > a good reason for me to leverage for all mobile flows and not build one > more mode. > = > We really should not be re-opening converged cases. There is a AD > comment on lack of specification on the tunneling mode, we can > easily fix that, rather dug open the whole mountain. Hesham spent > lots of time on adding all the TLV and the related support, we > dont have to waste all that, if there is some thing minor missing. > = > Regards > Sri > = > = > On Mon, 19 Jan 2009, Basavaraj Patil wrote: > = >> = >> I still fail to really understand why GRE encapsulation is needed for ho= st >> based mobility (DSMIP6). >> The only argument below is that it provides "richer semantics than >> IPv6-in-IPv6". Can you provide an explicit example of how the richer >> semantics are useful vs the IP-in-IP encapsulation for DSMIP6? >> = >> Cheers, >> -Raj >> = >> = >> On 1/19/09 12:09 PM, "Sri Gundavelli" wrote: >> = >>> = >>> = >>> On Fri, 16 Jan 2009, Behcet Sarikaya wrote: >>> = >>>> [behcet] I couldn't understand why MN would need to support GRE. Can >>>> someone >>>> explain the use case? >>>> =A0 >>> = >>> This issue was discussed at length. Many reasons were cited as why the >>> GRE encapsulation mode may be needed in client-based mobility and why >>> it should not be restricted to network elements alone. >>> = >>> The LMA element in Proxy Mobile IPv6 is a feature extension to the >>> Mobile IPv6 home agent. They have a strong relation. If some one >>> implements home agent function, implements the data plane with all >>> the hardware support for GRE and it cant be leveraged when supporting >>> client-based mobile nodes ? Its the same home agent that serves both >>> types of nodes. >>> = >>> The options that we are standardizing NETLMM or MEXT, each should not >>> take a different path. Its not that we have one revocation option for >>> PMIP, one for NEMO and the other for MIP6. Keeping them together will >>> save implementors to leverage all these features and resources across. >>> = >>> GRE is another enapsulation mode, it exists with much richer semantics >>> than IPv6-in-IPv6. The ability to carry non IP traffic, I'm not saying >>> I support this for carrying IPX/AT traffic, but the point that its a >>> useful encapsation mode that exists in MIP4 and cant be ignored for >>> good reasons. >>> = >>> Sri >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>>> Thanks, >>>> =A0 >>>> Behcet >>>> = >>>> = >>>>> Hi Pasi, Hesham, >>>>> = >>>>> The TLV header was specified in the DS-MIPv6 document after rather a >>>>> long and acrimonious debate on the former MIP6 mailing list. There we= re >>>>> atleast two consensus calls that were run at that time. >>>> = >>>> =3D> I don't realy want to get into that, we all know there was no con= census >>>> and we had to teleconference to come up with the existing method >>>> = >>>> Anytime you have >>>>> a UDP header with IPv4/IPv6/GRE header following it, you need the TLV >>>>> header. >>>> = >>>> = >>>> = >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> = >> = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jan 19 12:09:07 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DFA3A690D; Mon, 19 Jan 2009 12:09:07 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DD003A6827 for ; Mon, 19 Jan 2009 12:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucBsbUzx1zf8 for ; Mon, 19 Jan 2009 12:09:04 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 62F9F3A6874 for ; Mon, 19 Jan 2009 12:09:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,290,1231113600"; d="scan'208";a="232687102" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 19 Jan 2009 20:06:34 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0JK6YMI028984; Mon, 19 Jan 2009 12:06:34 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0JK6YwC000230; Mon, 19 Jan 2009 20:06:34 GMT Date: Mon, 19 Jan 2009 12:06:33 -0800 (PST) From: Sri Gundavelli To: Basavaraj Patil In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1594243340-1232395593=:17388" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5634; t=1232395594; x=1233259594; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20GRE=20support=20in=20DSMIPv6=2 0-=20AD=20review |Sender:=20; bh=pZZYYOGXQZeoJXbaWlOguGYtkcVEgJvoOZ19wBasdS0=; b=RzgSMWJjnmiPrc+39ljqS1HuwiLysu372PsCW4rlWI7kC5BAo2oGTPViFN fpRTuNovfv78CMwqhEehTRRvEurATt6KhigcnHjvsfytTfM+bZfTtXsJRXz6 p0Lb/1+v5XL1+1Bk07IwH1q6qv3xHEbAV6YxpSfRxrwV4/7gMHZeE=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Jari Arkko , mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1594243340-1232395593=:17388 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Ok. Thanks Raj. However we do, fixing it in this doc as planned initially, in a new doc, the mode should be available to both network-based and client-based mobility, that will keep the initally agreed upon consensus as reflected when the doc was sent to IESG by the WG. We still need to adress the comment on the lack of text and IMHO this doc is the right place as the mode is common to all. Hope this one last comment gets resolved the right way. Regards Sri On Mon, 19 Jan 2009, Basavaraj Patil wrote: > > Sri, > > For the resolution of the IESG comments regarding the TLV header, I have > said that this spec should get rid of it and if someone feels the need fo= r > it to be specified, they can do so (potential docs suggested being the IP= v4 > support I-D or the GRE Keys I-D in Netlmm WG). > > My comment was based on the reopening of the discussion regarding the nee= d > for GRE encapsulation in the context of DSMIP6. I agree that nothing has > changed since we had this discussion a while ago and as you can tell neit= her > has my opinion regarding the need for GRE for host based mobility. > But I am fine with whatever is deemed as the consensus regarding the TLV > header and/or GRE encapsulation support in the DSMIP6 I-D. > > -Raj > > > On 1/19/09 1:01 PM, "Sri Gundavelli" wrote: > >> Raj, >> >> We went over all this list year back. You asked the same question, >> you got the same answers. There are no new arguments. If you want >> to ignore the use of GRE key in NEMO use, for marking different MNP >> flows for differential treatment on the HA, or the point of carrying >> legacy payload traffic, or about a single integrated HA/LMA serving >> mobile nodes and leveraging a common encap mode, you may so, but the >> fact reamins. Its useful in PMIP, it may be useful in NEMO, or may not >> be so useful in client-MIP, fine, lets not apply restrictions. If we >> have a home agent that can perform GRE switching in the hardware, its >> a good reason for me to leverage for all mobile flows and not build one >> more mode. >> >> We really should not be re-opening converged cases. There is a AD >> comment on lack of specification on the tunneling mode, we can >> easily fix that, rather dug open the whole mountain. Hesham spent >> lots of time on adding all the TLV and the related support, we >> dont have to waste all that, if there is some thing minor missing. >> >> Regards >> Sri >> >> >> On Mon, 19 Jan 2009, Basavaraj Patil wrote: >> >>> >>> I still fail to really understand why GRE encapsulation is needed for h= ost >>> based mobility (DSMIP6). >>> The only argument below is that it provides "richer semantics than >>> IPv6-in-IPv6". Can you provide an explicit example of how the richer >>> semantics are useful vs the IP-in-IP encapsulation for DSMIP6? >>> >>> Cheers, >>> -Raj >>> >>> >>> On 1/19/09 12:09 PM, "Sri Gundavelli" wrote: >>> >>>> >>>> >>>> On Fri, 16 Jan 2009, Behcet Sarikaya wrote: >>>> >>>>> [behcet] I couldn't understand why MN would need to support GRE. Can >>>>> someone >>>>> explain the use case? >>>>> =A0 >>>> >>>> This issue was discussed at length. Many reasons were cited as why the >>>> GRE encapsulation mode may be needed in client-based mobility and why >>>> it should not be restricted to network elements alone. >>>> >>>> The LMA element in Proxy Mobile IPv6 is a feature extension to the >>>> Mobile IPv6 home agent. They have a strong relation. If some one >>>> implements home agent function, implements the data plane with all >>>> the hardware support for GRE and it cant be leveraged when supporting >>>> client-based mobile nodes ? Its the same home agent that serves both >>>> types of nodes. >>>> >>>> The options that we are standardizing NETLMM or MEXT, each should not >>>> take a different path. Its not that we have one revocation option for >>>> PMIP, one for NEMO and the other for MIP6. Keeping them together will >>>> save implementors to leverage all these features and resources across. >>>> >>>> GRE is another enapsulation mode, it exists with much richer semantics >>>> than IPv6-in-IPv6. The ability to carry non IP traffic, I'm not saying >>>> I support this for carrying IPX/AT traffic, but the point that its a >>>> useful encapsation mode that exists in MIP4 and cant be ignored for >>>> good reasons. >>>> >>>> Sri >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Thanks, >>>>> =A0 >>>>> Behcet >>>>> >>>>> >>>>>> Hi Pasi, Hesham, >>>>>> >>>>>> The TLV header was specified in the DS-MIPv6 document after rather a >>>>>> long and acrimonious debate on the former MIP6 mailing list. There w= ere >>>>>> atleast two consensus calls that were run at that time. >>>>> >>>>> =3D> I don't realy want to get into that, we all know there was no co= ncensus >>>>> and we had to teleconference to come up with the existing method >>>>> >>>>> Anytime you have >>>>>> a UDP header with IPv4/IPv6/GRE header following it, you need the TL= V >>>>>> header. >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> > > ---559023410-1594243340-1232395593=:17388 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ---559023410-1594243340-1232395593=:17388-- From mext-bounces@ietf.org Mon Jan 19 13:07:46 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05CCD3A6864; Mon, 19 Jan 2009 13:07:46 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E893A6864 for ; Mon, 19 Jan 2009 13:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZu-YlkeGawu for ; Mon, 19 Jan 2009 13:07:43 -0800 (PST) Received: from web111403.mail.gq1.yahoo.com (web111403.mail.gq1.yahoo.com [67.195.15.144]) by core3.amsl.com (Postfix) with SMTP id 0393F3A6808 for ; Mon, 19 Jan 2009 13:07:42 -0800 (PST) Received: (qmail 40237 invoked by uid 60001); 19 Jan 2009 21:07:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=Vw4UYQ7szQqokUcyaLjjlE0gUYwwjODS8ETYDcoTwzdRdspyHLYm6qjcVV6nNOx2RC7i2K42rxpev5E4tFMf5n8sIOx4ghH+c85pSPHLJiD7n4+lnppAWVsGuFeKBmti02dzcVhsYgi7A2w5uaI70ZSEOjndbUKP9BnntzWU3Mc=; X-YMail-OSG: HgXNz0EVM1lcncBb_Ai651TX73UVKmnNUfhCfoIqatazrYFRRmwl0C54LevKNRSXBthRX_jHLYVgjglU5CA0mHajHFVOM30bu3JwDCEDGDZWeIWml_GmPZdLqUCWPKsHfthQKge7za64P1CTBa9VdLqw528XA7cZgjE_P0uoKTVWPq2nPpUWwFe0_SWTZhB6n56NX6qWfiLWi2E- Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Mon, 19 Jan 2009 13:07:26 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: Date: Mon, 19 Jan 2009 13:07:26 -0800 (PST) From: Behcet Sarikaya To: Sri Gundavelli MIME-Version: 1.0 Message-ID: <544186.40211.qm@web111403.mail.gq1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1893542607==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1893542607== Content-Type: multipart/alternative; boundary="0-1785089876-1232399246=:40211" --0-1785089876-1232399246=:40211 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Sri,=0A=A0 You are right, it exists in MIP4. For some reason it doesn't = in MIP6. GRE key draft proposes to use it mainly for IPv4 traffic. =0A=A0 M= y suggestion is to move TLV text to the netlmm GRE key draft. This way we h= ave everything related to GRE in one document. As you said that document do= es not disallow using it in (DS)-MIPv6. So a win-win case .=0A=0ARegards,= =0A=0ABehcet=0A=0A=0A=0A=0A________________________________=0AFrom: Sri Gun= davelli =0ATo: Basavaraj Patil =0ACc: Behcet Sarikaya ; Jari Arkko ; mext@ietf.org; Pasi Eronen =0ASent: Monday, J= anuary 19, 2009 2:06:33 PM=0ASubject: Re: [MEXT] GRE support in DSMIPv6 - A= D review=0A=0AOk. Thanks Raj.=0A=0AHowever we do, fixing it in this doc as = planned initially,=0Ain a new doc, the mode should be available to both net= work-based=0Aand client-based mobility, that will keep the initally agreed = upon=0Aconsensus as reflected when the doc was sent to IESG by the WG. We= =0Astill need to adress the comment on the lack of text and IMHO this=0Adoc= is the right place as the mode is common to all.=0A=0AHope this one last c= omment gets resolved the right way.=0A=0ARegards=0ASri=0A=0A=0AOn Mon, 19 J= an 2009, Basavaraj Patil wrote:=0A=0A>=0A> Sri,=0A>=0A> For the resolution = of the IESG comments regarding the TLV header, I have=0A> said that this sp= ec should get rid of it and if someone feels the need for=0A> it to be spec= ified, they can do so (potential docs suggested being the IPv4=0A> support = I-D or the GRE Keys I-D in Netlmm WG).=0A>=0A> My comment was based on the = reopening of the discussion regarding the need=0A> for GRE encapsulation in= the context of DSMIP6. I agree that nothing has=0A> changed since we had t= his discussion a while ago and as you can tell neither=0A> has my opinion r= egarding the need for GRE for host based mobility.=0A> But I am fine with w= hatever is deemed as the consensus regarding the TLV=0A> header and/or GRE = encapsulation support in the DSMIP6 I-D.=0A>=0A> -Raj=0A>=0A>=0A> On 1/19/0= 9 1:01 PM, "Sri Gundavelli" wrote:=0A>=0A>> Raj,=0A>>= =0A>> We went over all this list year back. You asked the same question,=0A= >> you got the same answers. There are no new arguments. If you want=0A>> t= o ignore the use of GRE key in NEMO use, for marking different MNP=0A>> flo= ws for differential treatment on the HA, or the point of carrying=0A>> lega= cy payload traffic, or about a single integrated HA/LMA serving=0A>> mobile= nodes and leveraging a common encap mode, you may so, but the=0A>> fact re= amins. Its useful in PMIP, it may be useful in NEMO, or may not=0A>> be so = useful in client-MIP, fine, lets not apply restrictions.=A0 If we=0A>> have= a home agent that can perform GRE switching in the hardware, its=0A>> a go= od reason for me to leverage for all mobile flows and not build one=0A>> mo= re mode.=0A>>=0A>> We really should not be re-opening converged cases. Ther= e is a AD=0A>> comment on lack of specification on the tunneling mode, we c= an=0A>> easily fix that, rather dug open the whole mountain. Hesham spent= =0A>> lots of time on adding all the TLV and the related support, we=0A>> d= ont have to waste all that, if there is some thing minor missing.=0A>>=0A>>= Regards=0A>> Sri=0A>>=0A>>=0A>> On Mon, 19 Jan 2009, Basavaraj Patil wrote= :=0A>>=0A>>>=0A>>> I still fail to really understand why GRE encapsulation = is needed for host=0A>>> based mobility (DSMIP6).=0A>>> The only argument b= elow is that it provides "richer semantics than=0A>>> IPv6-in-IPv6". Can yo= u provide an explicit example of how the richer=0A>>> semantics are useful = vs the IP-in-IP encapsulation for DSMIP6?=0A>>>=0A>>> Cheers,=0A>>> -Raj=0A= >>>=0A>>>=0A>>> On 1/19/09 12:09 PM, "Sri Gundavelli" = wrote:=0A>>>=0A>>>>=0A>>>>=0A>>>> On Fri, 16 Jan 2009, Behcet Sarikaya wrot= e:=0A>>>>=0A>>>>> [behcet] I couldn't understand why MN would need to suppo= rt GRE. Can=0A>>>>> someone=0A>>>>> explain the use case?=0A>>>>> =A0=0A>>>= >=0A>>>> This issue was discussed at length. Many reasons were cited as why= the=0A>>>> GRE encapsulation mode may be needed in client-based mobility a= nd why=0A>>>> it should not be restricted to network elements alone.=0A>>>>= =0A>>>> The LMA element in Proxy Mobile IPv6 is a feature extension to the= =0A>>>> Mobile IPv6 home agent. They have a strong relation. If some one=0A= >>>> implements home agent function, implements the data plane with all=0A>= >>> the hardware support for GRE and it cant be leveraged when supporting= =0A>>>> client-based mobile nodes ? Its the same home agent that serves bot= h=0A>>>> types of nodes.=0A>>>>=0A>>>> The options that we are standardizin= g NETLMM or MEXT, each should not=0A>>>> take a different path. Its not tha= t we have one revocation option for=0A>>>> PMIP, one for NEMO and the other= for MIP6. Keeping them together will=0A>>>> save implementors to leverage = all these features and resources across.=0A>>>>=0A>>>> GRE is another enaps= ulation mode, it exists with much richer semantics=0A>>>> than IPv6-in-IPv6= . The ability to carry non IP traffic, I'm not saying=0A>>>> I support this= for carrying IPX/AT traffic, but the point that its a=0A>>>> useful encaps= ation mode that exists in MIP4 and cant be ignored for=0A>>>> good reasons.= =0A>>>>=0A>>>> Sri=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>= =0A>>>>=0A>>>>=0A>>>>> Thanks,=0A>>>>> =A0=0A>>>>> Behcet=0A>>>>>=0A>>>>>= =0A>>>>>> Hi Pasi, Hesham,=0A>>>>>>=0A>>>>>> The TLV header was specified i= n the DS-MIPv6 document after rather a=0A>>>>>> long and acrimonious debate= on the former MIP6 mailing list. There were=0A>>>>>> atleast two consensus= calls that were run at that time.=0A>>>>>=0A>>>>> =3D> I don't realy want = to get into that, we all know there was no concensus=0A>>>>> and we had to = teleconference to come up with the existing method=0A>>>>>=0A>>>>> Anytime = you have=0A>>>>>> a UDP header with IPv4/IPv6/GRE header following it, you = need the TLV=0A>>>>>> header.=0A>>>>>=0A>>>>>=0A>>>>>=0A>>>> ______________= _________________________________=0A>>>> MEXT mailing list=0A>>>> MEXT@ietf= .org=0A>>>> https://www.ietf.org/mailman/listinfo/mext=0A>>>=0A>>>=0A>=0A>= =0A=0A=0A --0-1785089876-1232399246=:40211 Content-Type: text/html; charset=us-ascii
Hi Sri,
  You are right, it exists in MIP4. For some reason it doesn't in MIP6. GRE key draft proposes to use it mainly for IPv4 traffic.
  My suggestion is to move TLV text to the netlmm GRE key draft. This way we have everything related to GRE in one document. As you said that document does not disallow using it in (DS)-MIPv6. So a win-win case .
 
Regards,
 
Behcet

From: Sri Gundavelli <sgundave@cisco.com>
To: Basavaraj Patil <basavaraj.patil@nokia.com>
Cc: Behcet Sarikaya <sarikaya@ieee.org>; Jari Arkko <jari.arkko@piuha.net>; mext@ietf.org; Pasi Eronen <pasi.eronen@nokia.com>
Sent: Monday, January 19, 2009 2:06:33 PM
Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review

Ok. Thanks Raj.

However we do, fixing it in this doc as planned initially,
in a new doc, the mode should be available to both network-based
and client-based mobility, that will keep the initally agreed upon
consensus as reflected when the doc was sent to IESG by the WG. We
still need to adress the comment on the lack of text and IMHO this
doc is the right place as the mode is common to all.

Hope this one last comment gets resolved the right way.

Regards
Sri


On Mon, 19 Jan 2009, Basavaraj Patil wrote:

>
> Sri,
>
> For the resolution of the IESG comments regarding the TLV header, I have
> said that this spec should get rid of it and if someone feels the need for
> it to be specified, they can do so (potential docs suggested being the IPv4
> support I-D or the GRE Keys I-D in Netlmm WG).
>
> My comment was based on the reopening of the discussion regarding the need
> for GRE encapsulation in the context of DSMIP6. I agree that nothing has
> changed since we had this discussion a while ago and as you can tell neither
> has my opinion regarding the need for GRE for host based mobility.
> But I am fine with whatever is deemed as the consensus regarding the TLV
> header and/or GRE encapsulation support in the DSMIP6 I-D.
>
> -Raj
>
>
> On 1/19/09 1:01 PM, "Sri Gundavelli" <sgundave@cisco.com> wrote:
>
>> Raj,
>>
>> We went over all this list year back. You asked the same question,
>> you got the same answers. There are no new arguments. If you want
>> to ignore the use of GRE key in NEMO use, for marking different MNP
>> flows for differential treatment on the HA, or the point of carrying
>> legacy payload traffic, or about a single integrated HA/LMA serving
>> mobile nodes and leveraging a common encap mode, you may so, but the
>> fact reamins. Its useful in PMIP, it may be useful in NEMO, or may not
>> be so useful in client-MIP, fine, lets not apply restrictions.  If we
>> have a home agent that can perform GRE switching in the hardware, its
>> a good reason for me to leverage for all mobile flows and not build one
>> more mode.
>>
>> We really should not be re-opening converged cases. There is a AD
>> comment on lack of specification on the tunneling mode, we can
>> easily fix that, rather dug open the whole mountain. Hesham spent
>> lots of time on adding all the TLV and the related support, we
>> dont have to waste all that, if there is some thing minor missing.
>>
>> Regards
>> Sri
>>
>>
>> On Mon, 19 Jan 2009, Basavaraj Patil wrote:
>>
>>>
>>> I still fail to really understand why GRE encapsulation is needed for host
>>> based mobility (DSMIP6).
>>> The only argument below is that it provides "richer semantics than
>>> IPv6-in-IPv6". Can you provide an explicit example of how the richer
>>> semantics are useful vs the IP-in-IP encapsulation for DSMIP6?
>>>
>>> Cheers,
>>> -Raj
>>>
>>>
>>> On 1/19/09 12:09 PM, "Sri Gundavelli" <sgundave@cisco.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, 16 Jan 2009, Behcet Sarikaya wrote:
>>>>
>>>>> [behcet] I couldn't understand why MN would need to support GRE. Can
>>>>> someone
>>>>> explain the use case?
>>>>>  
>>>>
>>>> This issue was discussed at length. Many reasons were cited as why the
>>>> GRE encapsulation mode may be needed in client-based mobility and why
>>>> it should not be restricted to network elements alone.
>>>>
>>>> The LMA element in Proxy Mobile IPv6 is a feature extension to the
>>>> Mobile IPv6 home agent. They have a strong relation. If some one
>>>> implements home agent function, implements the data plane with all
>>>> the hardware support for GRE and it cant be leveraged when supporting
>>>> client-based mobile nodes ? Its the same home agent that serves both
>>>> types of nodes.
>>>>
>>>> The options that we are standardizing NETLMM or MEXT, each should not
>>>> take a different path. Its not that we have one revocation option for
>>>> PMIP, one for NEMO and the other for MIP6. Keeping them together will
>>>> save implementors to leverage all these features and resources across.
>>>>
>>>> GRE is another enapsulation mode, it exists with much richer semantics
>>>> than IPv6-in-IPv6. The ability to carry non IP traffic, I'm not saying
>>>> I support this for carrying IPX/AT traffic, but the point that its a
>>>> useful encapsation mode that exists in MIP4 and cant be ignored for
>>>> good reasons.
>>>>
>>>> Sri
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Thanks,
>>>>>  
>>>>> Behcet
>>>>>
>>>>>
>>>>>> Hi Pasi, Hesham,
>>>>>>
>>>>>> The TLV header was specified in the DS-MIPv6 document after rather a
>>>>>> long and acrimonious debate on the former MIP6 mailing list. There were
>>>>>> atleast two consensus calls that were run at that time.
>>>>>
>>>>> => I don't realy want to get into that, we all know there was no concensus
>>>>> and we had to teleconference to come up with the existing method
>>>>>
>>>>> Anytime you have
>>>>>> a UDP header with IPv4/IPv6/GRE header following it, you need the TLV
>>>>>> header.
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> MEXT mailing list
>>>> MEXT@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mext
>>>
>>>
>
>

--0-1785089876-1232399246=:40211-- --===============1893542607== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1893542607==-- From mext-bounces@ietf.org Mon Jan 19 13:31:10 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FBF33A691E; Mon, 19 Jan 2009 13:31:10 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A282D3A691E for ; Mon, 19 Jan 2009 13:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo--34oX92M5 for ; Mon, 19 Jan 2009 13:31:07 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5DEDA3A68AF for ; Mon, 19 Jan 2009 13:31:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,290,1231113600"; d="scan'208";a="130839006" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 19 Jan 2009 21:30:51 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n0JLUpvn016281; Mon, 19 Jan 2009 13:30:51 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0JLUpoT010984; Mon, 19 Jan 2009 21:30:51 GMT Date: Mon, 19 Jan 2009 13:30:50 -0800 (PST) From: Sri Gundavelli To: Behcet Sarikaya In-Reply-To: <544186.40211.qm@web111403.mail.gq1.yahoo.com> Message-ID: References: <544186.40211.qm@web111403.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1232400650=:8306" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7234; t=1232400651; x=1233264651; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20GRE=20support=20in=20DSMIPv6=2 0-=20AD=20review |Sender:=20; bh=1Fk3r70mGynz3xecvtzgSAtlAzXnyyto5NP5E9qVu8s=; b=RiZ4CUEtYZA9xEYZfXU3GWvzIgmpHmQwHvN7gLlZp5EmikxSXKewjDeXtM oexp03WNbwS6DWOdNkGgEaCV9lQi0jBpjuXgO0GgmmkYRWRmUpsL1gKpi8tc BFk7EuqxDE; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-851401618-1232400650=:8306 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Behcet, The issue would be that this spec needs to understand the payload=20 qualifier, else we cant add themm later. Its the same DSMIP UDP flow, one with the flows carried natively and the other with some format that we will define some where else. As pointed out earlier and also as a matter convention set by RFC-3519, we cant carry payloads with out a proper header. All protocols have always provided some form of thin header, which identifies the type of payload it carries. Ignoring the GRE discussion, we need this TLV header even for that reason. Sri On Mon, 19 Jan 2009, Behcet Sarikaya wrote: > Hi Sri, > =A0 You are right, it exists in MIP4. For some reason it doesn't in MIP6.= GRE key draft proposes to use it mainly for IPv4 traffic. > =A0 My suggestion is to move TLV text to the netlmm GRE key draft. This w= ay we have everything related to GRE in one document. As you said that docu= ment does not disallow using it in (DS)-MIPv6. So a win-win case . > > Regards, > > Behcet > > > > > ________________________________ > From: Sri Gundavelli > To: Basavaraj Patil > Cc: Behcet Sarikaya ; Jari Arkko ; mext@ietf.org; Pasi Eronen > Sent: Monday, January 19, 2009 2:06:33 PM > Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review > > Ok. Thanks Raj. > > However we do, fixing it in this doc as planned initially, > in a new doc, the mode should be available to both network-based > and client-based mobility, that will keep the initally agreed upon > consensus as reflected when the doc was sent to IESG by the WG. We > still need to adress the comment on the lack of text and IMHO this > doc is the right place as the mode is common to all. > > Hope this one last comment gets resolved the right way. > > Regards > Sri > > > On Mon, 19 Jan 2009, Basavaraj Patil wrote: > >> >> Sri, >> >> For the resolution of the IESG comments regarding the TLV header, I have >> said that this spec should get rid of it and if someone feels the need f= or >> it to be specified, they can do so (potential docs suggested being the I= Pv4 >> support I-D or the GRE Keys I-D in Netlmm WG). >> >> My comment was based on the reopening of the discussion regarding the ne= ed >> for GRE encapsulation in the context of DSMIP6. I agree that nothing has >> changed since we had this discussion a while ago and as you can tell nei= ther >> has my opinion regarding the need for GRE for host based mobility. >> But I am fine with whatever is deemed as the consensus regarding the TLV >> header and/or GRE encapsulation support in the DSMIP6 I-D. >> >> -Raj >> >> >> On 1/19/09 1:01 PM, "Sri Gundavelli" wrote: >> >>> Raj, >>> >>> We went over all this list year back. You asked the same question, >>> you got the same answers. There are no new arguments. If you want >>> to ignore the use of GRE key in NEMO use, for marking different MNP >>> flows for differential treatment on the HA, or the point of carrying >>> legacy payload traffic, or about a single integrated HA/LMA serving >>> mobile nodes and leveraging a common encap mode, you may so, but the >>> fact reamins. Its useful in PMIP, it may be useful in NEMO, or may not >>> be so useful in client-MIP, fine, lets not apply restrictions.=A0 If we >>> have a home agent that can perform GRE switching in the hardware, its >>> a good reason for me to leverage for all mobile flows and not build one >>> more mode. >>> >>> We really should not be re-opening converged cases. There is a AD >>> comment on lack of specification on the tunneling mode, we can >>> easily fix that, rather dug open the whole mountain. Hesham spent >>> lots of time on adding all the TLV and the related support, we >>> dont have to waste all that, if there is some thing minor missing. >>> >>> Regards >>> Sri >>> >>> >>> On Mon, 19 Jan 2009, Basavaraj Patil wrote: >>> >>>> >>>> I still fail to really understand why GRE encapsulation is needed for = host >>>> based mobility (DSMIP6). >>>> The only argument below is that it provides "richer semantics than >>>> IPv6-in-IPv6". Can you provide an explicit example of how the richer >>>> semantics are useful vs the IP-in-IP encapsulation for DSMIP6? >>>> >>>> Cheers, >>>> -Raj >>>> >>>> >>>> On 1/19/09 12:09 PM, "Sri Gundavelli" wrote: >>>> >>>>> >>>>> >>>>> On Fri, 16 Jan 2009, Behcet Sarikaya wrote: >>>>> >>>>>> [behcet] I couldn't understand why MN would need to support GRE. Can >>>>>> someone >>>>>> explain the use case? >>>>>> =A0 >>>>> >>>>> This issue was discussed at length. Many reasons were cited as why th= e >>>>> GRE encapsulation mode may be needed in client-based mobility and why >>>>> it should not be restricted to network elements alone. >>>>> >>>>> The LMA element in Proxy Mobile IPv6 is a feature extension to the >>>>> Mobile IPv6 home agent. They have a strong relation. If some one >>>>> implements home agent function, implements the data plane with all >>>>> the hardware support for GRE and it cant be leveraged when supporting >>>>> client-based mobile nodes ? Its the same home agent that serves both >>>>> types of nodes. >>>>> >>>>> The options that we are standardizing NETLMM or MEXT, each should not >>>>> take a different path. Its not that we have one revocation option for >>>>> PMIP, one for NEMO and the other for MIP6. Keeping them together will >>>>> save implementors to leverage all these features and resources across= =2E >>>>> >>>>> GRE is another enapsulation mode, it exists with much richer semantic= s >>>>> than IPv6-in-IPv6. The ability to carry non IP traffic, I'm not sayin= g >>>>> I support this for carrying IPX/AT traffic, but the point that its a >>>>> useful encapsation mode that exists in MIP4 and cant be ignored for >>>>> good reasons. >>>>> >>>>> Sri >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Thanks, >>>>>> =A0 >>>>>> Behcet >>>>>> >>>>>> >>>>>>> Hi Pasi, Hesham, >>>>>>> >>>>>>> The TLV header was specified in the DS-MIPv6 document after rather = a >>>>>>> long and acrimonious debate on the former MIP6 mailing list. There = were >>>>>>> atleast two consensus calls that were run at that time. >>>>>> >>>>>> =3D> I don't realy want to get into that, we all know there was no c= oncensus >>>>>> and we had to teleconference to come up with the existing method >>>>>> >>>>>> Anytime you have >>>>>>> a UDP header with IPv4/IPv6/GRE header following it, you need the T= LV >>>>>>> header. >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >> >> > > > ---559023410-851401618-1232400650=:8306 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ---559023410-851401618-1232400650=:8306-- From mext-bounces@ietf.org Mon Jan 19 15:23:49 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D503A6A45; Mon, 19 Jan 2009 15:23:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93F243A6A4F for ; Mon, 19 Jan 2009 15:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkBAzsHOOFU9 for ; Mon, 19 Jan 2009 15:23:47 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 3738E3A6A16 for ; Mon, 19 Jan 2009 15:23:46 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0JNNQZ07142; Mon, 19 Jan 2009 23:23:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jan 2009 17:23:21 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-mext-binding-revocation-02 Thread-Index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQArrD7gALKdDZAEWRBysAGXgEdQAGd43wAAl3PFsAADWf9w References: From: "Ahmad Muhanna" To: "Stupar, Patrick" Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Patrick, As I said, your proposed text for the second bullet was not clear to me. On the other hand, the first bullet specify what happened if any of the two checks fail, i.e. if the received BRI does not have an entry in its BUL. The second bullet specify what happened if these two checks were successful. There is nothing wrong in being explicit and clear without any ambiguity. Finally, how come your question is valid against the clarified text and NOT against yours? Can I say that you have a problem with the following text: Can you specify what is wrong in it? o If the Acknowledgement (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. Regards, Ahmad > -----Original Message----- > From: Stupar, Patrick [mailto:pstupar@qualcomm.com] > Sent: Monday, January 19, 2009 8:00 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext@ietf.org > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > Hi Ahmad, > > Please see below. > > Best Regards, > > Patrick > > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Friday, January 16, 2009 7:51 PM > > To: Stupar, Patrick > > Cc: mext@ietf.org > > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > > > Hi Patrick, > > Thanks. One slight modification below. > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Stupar, Patrick [mailto:pstupar@qualcomm.com] > > > Sent: Friday, January 16, 2009 11:18 AM > > > To: Muhanna, Ahmad (RICH1:2H10) > > > Cc: mext@ietf.org > > > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > > > > > > > [Ahmad] > > > > I see what you are saying. I assumed that this is in the > > > form of NAI. > > > > we > > > > can add some text to clarify that, would that address your > > > concern or > > > > you have in mind a possible different format? > > > > > > I think this would be good. Either a definition in section > > > 2.2 or a clarification in the text would be fine with me. > > > > [Ahmad] > > Sure. > > > > > > > > > > > > [Ahmad] > > > > Currently, neither the HoA nor the CoA is included in the > > > BRI message. > > > > Are you suggesting that we add those options as valid ones > > > in the BRI? > > > > > > No I am not. What I meant here is that HoA is in the > routing header > > > of the packet containing the BRI. Checking of HoA would be enough > > > IMO. It could be moved to the previous bullet of the list > as in the > > > following proposed text: > > > OLD TEXT: > > > " > > > o The mobile node MUST verify that the IP address in > the type 2 > > > routing header is its Home Address. > > > > > > o If the Acknowledgement (A) bit is set in the Binding > Revocation > > > Indication and the MN has the BCE in registered state, the > > > mobile > > > node MUST send a Binding Revocation Acknowledgement. > > > However, in > > > all other cases when the (A) bit is set in the BRI, > the mobile > > > node SHOULD send a Binding Revocation > Acknowledgement. In all > > > cases, the mobile node MUST follow Section 11.2 when send a > BRA > > > using the appropriate status code. > > > " > > > NEW TEXT > > > " > > > o The mobile node MUST verify that the IP address in > the type 2 > > > routing header is its Home Address and that its > Binding Update > > > List contains an entry for that Home Address. If one of > the tests > > > fails, > > > the mobile node SHOULD silently discard the received BRI > > > message. > > > > > > o If the Acknowledgement (A) bit is set in the Binding > Revocation > > > Indication, the mobile > > > node MUST send a Binding Revocation Acknowledgement. > > > However, in > > > all other cases when the (A) bit is set in the BRI, > the mobile > > > node SHOULD send a Binding Revocation > Acknowledgement. In all > > > cases, the mobile node MUST follow Section 11.2 when send a > BRA > > > using the appropriate status code. > > > " > > > > [Ahmad] > > I am not sure I follow the second bullet of the "NEW TEXT". > What about > > the following modified text: > > > > "MODIFIED TEXT" > > > > o The mobile node MUST verify that the IP address in the type 2 > > routing header is its Home Address and that its Binding Update > > List contains an entry for that Home Address. If one of > the tests, > > fails the mobile node SHOULD silently discard the received BRI > > message. > > > > o If the Acknowledgement (A) bit is set in the Binding > Revocation > > Indication and its Binding Update List contains an > entry for the > > IP address in the type 2 routing header, the mobile node MUST > > send a Binding Revocation Acknowledgement. However, in > > all other cases when the (A) bit is set in the BRI, the mobile > > node SHOULD send a Binding Revocation Acknowledgement. In all > > cases, the mobile node MUST follow Section 11.2 when > send a BRA > > using the appropriate status code. > > > [Patrick] > The actions in the first bullet apply to any received BRI > (also to those with the A bit set). Having said that, in the > second bullet it is only required to specify the additional > operation (i.e. sending a BRA) the MN has to perform when the > A bit is set. IMO the text you added is redundant and not > required. Do you have some particular scenario I am missing? > > > > > > > > > Please note that the proposed text overlaps with the last bullet > > > listed in section 11.2. I would remove that as in the > > > following: > > > > > > Old text: > > > "11.2. Sending Binding Revocation Acknowledgement > > > > > > When the mobile node receive a valid Binding Revocation > Indication > > > with the (A) bit is set from its home agent and while > having this > > > BCE > > > in registered state, the mobile node MUST send a packet to its > > home > > > agent containing a Binding Revocation Acknowledgement according > to > > > the procedure in Section 7.1 and the following: > > > > > > o The mobile node MUST set the status field to successful to > > > reflect > > > that it has received the Binding Revocation Indication and > > > acknowledge that its IP connectivity with its home > agent has > > > been > > > revoked. > > > > > > o The destination IP address of the IPv6 packet of the Binding > > > Revocation Acknowledgement is set to the source IP > address of > > > the > > > received IPv6 packet of the Binding Revocation Indication. > The > > > Mobile Node MUST include its home address in the > Home Address > > > option in the Destination Option. > > > > > > o If the mobile node receives a Binding Revocation Indication > > > from a > > > home agent which the mobile node does not have a registered > > > binding with, the mobile node SHOULD silently > discard the BRI > > > message. The mobile node should continue to use > its assigned > > > HoA > > > to access its IP mobility service." > > > > > > New text: > > > "11.2. Sending Binding Revocation Acknowledgement > > > > > > When the mobile node receive a valid Binding Revocation > Indication > > > with the (A) bit is set from its home agent and while > having this > > > BCE > > > in registered state, the mobile node MUST send a packet to its > > home > > > agent containing a Binding Revocation Acknowledgement according > to > > > the procedure in Section 7.1 and the following: > > > > > > o The mobile node MUST set the status field to successful to > > > reflect > > > that it has received the Binding Revocation Indication and > > > acknowledge that its IP connectivity with its home > agent has > > > been > > > revoked. > > > > > > o The destination IP address of the IPv6 packet of the Binding > > > Revocation Acknowledgement is set to the source IP > address of > > > the > > > received IPv6 packet of the Binding Revocation Indication. > The > > > Mobile Node MUST include its home address in the > Home Address > > > option in the Destination Option." > > > > [Ahmad] > > Sure. That is fair and good. > > > > Best Regards, > > Ahmad > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jan 19 18:29:15 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45CCB3A6A0F; Mon, 19 Jan 2009 18:29:15 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1736328C1EC for ; Mon, 19 Jan 2009 18:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6eycjQNFj9S for ; Mon, 19 Jan 2009 18:29:13 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id B66CB3A698E for ; Mon, 19 Jan 2009 18:29:11 -0800 (PST) Received: from [211.27.108.142] (helo=[10.0.0.21]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LP6ME-000331-5T; Tue, 20 Jan 2009 13:28:51 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 20 Jan 2009 13:28:40 +1100 From: Hesham Soliman To: Sri Gundavelli , Behcet Sarikaya Message-ID: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl6ps48L7LshWl0NEKV+WZP5omCRw== In-Reply-To: Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > = > The issue would be that this spec needs to understand the payload > qualifier, else we cant add themm later. =3D> It's not true though. You can add the exact same thing that we have in the draft now but specify it in a more complete manner and it will be backward compatible and interoperable. The negotiation bit in the BU would have to be included in the new draft of course. Hesham Its the same DSMIP UDP flow, > one with the flows carried natively and the other with some format > that we will define some where else. As pointed out earlier and > also as a matter convention set by RFC-3519, we cant carry payloads > with out a proper header. All protocols have always provided some > form of thin header, which identifies the type of payload it carries. > Ignoring the GRE discussion, we need this TLV header even for that > reason. > = > Sri > = > On Mon, 19 Jan 2009, Behcet Sarikaya wrote: > = >> Hi Sri, >> =A0 You are right, it exists in MIP4. For some reason it doesn't in MIP6= . GRE >> key draft proposes to use it mainly for IPv4 traffic. >> =A0 My suggestion is to move TLV text to the netlmm GRE key draft. This = way we >> have everything related to GRE in one document. As you said that document >> does not disallow using it in (DS)-MIPv6. So a win-win case . > = > = > = >> = >> Regards, >> = >> Behcet >> = >> = >> = >> = >> ________________________________ >> From: Sri Gundavelli >> To: Basavaraj Patil >> Cc: Behcet Sarikaya ; Jari Arkko ; >> mext@ietf.org; Pasi Eronen >> Sent: Monday, January 19, 2009 2:06:33 PM >> Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review >> = >> Ok. Thanks Raj. >> = >> However we do, fixing it in this doc as planned initially, >> in a new doc, the mode should be available to both network-based >> and client-based mobility, that will keep the initally agreed upon >> consensus as reflected when the doc was sent to IESG by the WG. We >> still need to adress the comment on the lack of text and IMHO this >> doc is the right place as the mode is common to all. >> = >> Hope this one last comment gets resolved the right way. >> = >> Regards >> Sri >> = >> = >> On Mon, 19 Jan 2009, Basavaraj Patil wrote: >> = >>> = >>> Sri, >>> = >>> For the resolution of the IESG comments regarding the TLV header, I have >>> said that this spec should get rid of it and if someone feels the need = for >>> it to be specified, they can do so (potential docs suggested being the = IPv4 >>> support I-D or the GRE Keys I-D in Netlmm WG). >>> = >>> My comment was based on the reopening of the discussion regarding the n= eed >>> for GRE encapsulation in the context of DSMIP6. I agree that nothing has >>> changed since we had this discussion a while ago and as you can tell ne= ither >>> has my opinion regarding the need for GRE for host based mobility. >>> But I am fine with whatever is deemed as the consensus regarding the TLV >>> header and/or GRE encapsulation support in the DSMIP6 I-D. >>> = >>> -Raj >>> = >>> = >>> On 1/19/09 1:01 PM, "Sri Gundavelli" wrote: >>> = >>>> Raj, >>>> = >>>> We went over all this list year back. You asked the same question, >>>> you got the same answers. There are no new arguments. If you want >>>> to ignore the use of GRE key in NEMO use, for marking different MNP >>>> flows for differential treatment on the HA, or the point of carrying >>>> legacy payload traffic, or about a single integrated HA/LMA serving >>>> mobile nodes and leveraging a common encap mode, you may so, but the >>>> fact reamins. Its useful in PMIP, it may be useful in NEMO, or may not >>>> be so useful in client-MIP, fine, lets not apply restrictions.=A0 If we >>>> have a home agent that can perform GRE switching in the hardware, its >>>> a good reason for me to leverage for all mobile flows and not build one >>>> more mode. >>>> = >>>> We really should not be re-opening converged cases. There is a AD >>>> comment on lack of specification on the tunneling mode, we can >>>> easily fix that, rather dug open the whole mountain. Hesham spent >>>> lots of time on adding all the TLV and the related support, we >>>> dont have to waste all that, if there is some thing minor missing. >>>> = >>>> Regards >>>> Sri >>>> = >>>> = >>>> On Mon, 19 Jan 2009, Basavaraj Patil wrote: >>>> = >>>>> = >>>>> I still fail to really understand why GRE encapsulation is needed for= host >>>>> based mobility (DSMIP6). >>>>> The only argument below is that it provides "richer semantics than >>>>> IPv6-in-IPv6". Can you provide an explicit example of how the richer >>>>> semantics are useful vs the IP-in-IP encapsulation for DSMIP6? >>>>> = >>>>> Cheers, >>>>> -Raj >>>>> = >>>>> = >>>>> On 1/19/09 12:09 PM, "Sri Gundavelli" wrote: >>>>> = >>>>>> = >>>>>> = >>>>>> On Fri, 16 Jan 2009, Behcet Sarikaya wrote: >>>>>> = >>>>>>> [behcet] I couldn't understand why MN would need to support GRE. Can >>>>>>> someone >>>>>>> explain the use case? >>>>>>> =A0 >>>>>> = >>>>>> This issue was discussed at length. Many reasons were cited as why t= he >>>>>> GRE encapsulation mode may be needed in client-based mobility and why >>>>>> it should not be restricted to network elements alone. >>>>>> = >>>>>> The LMA element in Proxy Mobile IPv6 is a feature extension to the >>>>>> Mobile IPv6 home agent. They have a strong relation. If some one >>>>>> implements home agent function, implements the data plane with all >>>>>> the hardware support for GRE and it cant be leveraged when supporting >>>>>> client-based mobile nodes ? Its the same home agent that serves both >>>>>> types of nodes. >>>>>> = >>>>>> The options that we are standardizing NETLMM or MEXT, each should not >>>>>> take a different path. Its not that we have one revocation option for >>>>>> PMIP, one for NEMO and the other for MIP6. Keeping them together will >>>>>> save implementors to leverage all these features and resources acros= s. >>>>>> = >>>>>> GRE is another enapsulation mode, it exists with much richer semanti= cs >>>>>> than IPv6-in-IPv6. The ability to carry non IP traffic, I'm not sayi= ng >>>>>> I support this for carrying IPX/AT traffic, but the point that its a >>>>>> useful encapsation mode that exists in MIP4 and cant be ignored for >>>>>> good reasons. >>>>>> = >>>>>> Sri >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>>> Thanks, >>>>>>> =A0 >>>>>>> Behcet >>>>>>> = >>>>>>> = >>>>>>>> Hi Pasi, Hesham, >>>>>>>> = >>>>>>>> The TLV header was specified in the DS-MIPv6 document after rather= a >>>>>>>> long and acrimonious debate on the former MIP6 mailing list. There= were >>>>>>>> atleast two consensus calls that were run at that time. >>>>>>> = >>>>>>> =3D> I don't realy want to get into that, we all know there was no >>>>>>> concensus >>>>>>> and we had to teleconference to come up with the existing method >>>>>>> = >>>>>>> Anytime you have >>>>>>>> a UDP header with IPv4/IPv6/GRE header following it, you need the = TLV >>>>>>>> header. >>>>>>> = >>>>>>> = >>>>>>> = >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> = >>>>> = >>> = >>> = >> = >> = >> = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jan 19 22:47:43 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5C93A6B6A; Mon, 19 Jan 2009 22:47:43 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960403A67FB; Mon, 19 Jan 2009 22:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[AWL=1.234, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylYYH7NHaGLM; Mon, 19 Jan 2009 22:47:40 -0800 (PST) Received: from ricky.india.internal.net (unknown [59.145.147.70]) by core3.amsl.com (Postfix) with ESMTP id 0332A3A6929; Mon, 19 Jan 2009 22:47:38 -0800 (PST) Received: from Magesh (magesh.india.internal.net.16.172.in-addr.arpa [172.16.8.41] (may be forged)) by ricky.india.internal.net (8.12.10/8.12.10) with ESMTP id n0K6ZFxA016051; Tue, 20 Jan 2009 12:05:15 +0530 Message-Id: <200901200635.n0K6ZFxA016051@ricky.india.internal.net> From: "Magesh Shanmugam" To: "'Ahmad Muhanna'" Date: Tue, 20 Jan 2009 12:23:08 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: Thread-Index: Acl6MbWiLAZ2wPBbRNyWgrShkUmdqQADGOwAACLlBcA= X-Cyberoam-Version: 9.5.4.86 X-Cyberoam-smtpxy-version: 0.0.4.2 X-Cyberoam-AV-Status: Clean X-Cyberoam-Proto: SMTP X-Cyberoam-AV-Policy: None X-Cyberoam-AS-Policy: Global Spam Policy Cc: netlmm@ietf.org, mext@ietf.org Subject: Re: [MEXT] Processing of BRI (Binding Revocation) by MAG X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2013046354==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============2013046354== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01C97AF9.E6E5B930" This is a multi-part message in MIME format. ------=_NextPart_000_00D9_01C97AF9.E6E5B930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ahmad My comments inline... Thanks S Magesh _____ From: Ahmad Muhanna [mailto:amuhanna@nortel.com] Sent: Monday, January 19, 2009 7:40 PM To: Magesh Shanmugam Cc: mext@ietf.org; netlmm@ietf.org Subject: RE: Processing of BRI (Binding Revocation) by MAG Ahmad I have a query regarding the handling of Binding Revocation by MAG for individual binding session. Following is the scenario: Scenario: 1. Proxy Mobile Initial Registration, MAG sends PBU to LMA with HNP option set to ALL_ZERO for MN 1. 2. LMA in turn sends back PBA with 3 HNP(s) assigned to MN 1 and updates Binding Cache Entry. 3. MAG updates Binding Update List entry and sends Router Advertisement to the MN with all the prefixes and prefix lifetime. Note: MAG considers the prefix lifetime as binding lifetime and starts Binding Lifetime timer. 4. Bi-directional tunnel is established between MAG and LMA. 5. Prefix Route(s) are created for all the prefixes at MAG. 6. MN 1 gets one IP Address from the alloted 3 HNP(s). 7. LMA sends BRI message with one HNP (out of the alloted 3 HNPs) with revoke trigger as "ADMINISTRATIVE REASON". After step 7, when MAG receives BRI message with only one HNP and MN-ID: Queries: 1. Will MAG stop the binding lifetime timer (started after binding session establishment), due to the received BRI message? 2. Will MAG delete the complete Binding Update List maintained for the MN (MN 1) or will it delete only the corresponding HNP entry from the BUL and send RA message to MN 1 (eventhough the IP Address used by MN is not from the HNP received in BRI message)? If it deletes only the corresponding HNP entry, what will happen to the Binding Lifetime timer? [Ahmad] If the LMA assigned 3 HNP for MN1, then if the LMA would like to revoke all of the HNPs, the LMA have one of the following options: 1. Send BRI with MN-ID option ONLY. This means that all HNPs are revoked, or [Magesh] If there are multiple interfaces (multi-homed) for the same MN, will MAG remove the Binding Update List maintained for all the interfaces, as there is no Link Layer Identifier Option in the BRI message? 2. Send a BRI with MN-ID and all HNPs. Although, the draft recommend Number 1 BUT does not prevent No. 2. On the other hand, if the LMA sends a BRI with MN-ID and a single HNP, then the MAG MUST consider the revocation of that single HNP and MUST NOT remove the MN1 from the BUL. [Magesh] What will be the status of binding lifetime timer? Will the timer be running even though the single HNP is removed from BUL entry (or will the timer be stopped). IMO, if LMA tries to revoke a particular mobility session (Binding Cache Entry), it has to send the MN-ID and all the HNP(s) allocated for the particular session. Sending of one HNP out of the allocated n HNP(s) should be treated as Invalid Case. The behavior should be same as PBU received from MAG for De-Registration (where all the HNP(s) allocated are present in the PBU message). Hope this help. Regards, Ahmad Thanks S Magesh ------=_NextPart_000_00D9_01C97AF9.E6E5B930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ahmad
 
My comments inline...
 
Thanks
S Magesh

From: Ahmad Muhanna = [mailto:amuhanna@nortel.com]=20
Sent: Monday, January 19, 2009 7:40 PM
To: Magesh=20 Shanmugam
Cc: mext@ietf.org; = netlmm@ietf.org
Subject: RE:=20 Processing of BRI (Binding Revocation) by MAG

 
Ahmad
 
I = have a query=20 regarding the handling of Binding Revocation by MAG for individual = binding=20 session. 
Following is the=20 scenario:
 
Scenario:
 
1. = Proxy Mobile=20 Initial Registration, MAG sends PBU to LMA with HNP option set to = ALL_ZERO for=20 MN 1.
2. = LMA in turn=20 sends back PBA with 3 HNP(s) assigned to MN 1 and updates Binding = Cache=20 Entry.
3. = MAG updates=20 Binding Update List entry and sends Router Advertisement to the MN = with all=20 the
   =20 prefixes and prefix lifetime.
   =20 Note: MAG considers the prefix lifetime as binding lifetime and starts = Binding=20 Lifetime timer.
4. = Bi-directional=20 tunnel is established between MAG and LMA. 
5. = Prefix Route(s)=20 are created for all the prefixes at MAG.
6. = MN 1 gets one=20 IP Address from the alloted 3 HNP(s).
7. = LMA sends BRI=20 message with one HNP (out of the alloted 3 HNPs) with revoke trigger = as=20
  =20 "ADMINISTRATIVE REASON".
 
After step 7, when=20 MAG receives BRI message with only one HNP and = MN-ID:
 
Queries:
 
1. = Will MAG stop=20 the binding lifetime timer (started after binding session = establishment), due=20 to the
   =20 received BRI message?
2. = Will MAG delete=20 the complete Binding Update List maintained for the MN (MN 1) or will = it=20 delete
   =20 only the corresponding HNP entry from the BUL and send RA message to = MN 1=20 (eventhough
   =20 the IP Address used by MN is not from the HNP received in BRI = message)? =20 If it deletes only the
    corresponding HNP entry, what will happen = to the=20 Binding Lifetime timer? 
 
[Ahmad]
If the LMA assigned 3 = HNP=20 for MN1, then if the LMA would like to revoke all of the HNPs, = the=20 LMA have one of the following=20 options:
 
1. Send BRI with = MN-ID option=20 ONLY. This means that all HNPs are revoked, or 
&nbs= p;
[Magesh] If there=20 are multiple interfaces (multi-homed) for the same MN, will = MAG=20 remove the Binding Update List maintained for all the interfaces, =
as = there is no=20 Link Layer Identifier Option in the BRI=20 message?
 
2. Send a BRI with = MN-ID and all=20 HNPs.
 
Although, the draft = recommend=20 Number 1 BUT does not prevent No. = 2.
 
On the other hand, if = the LMA=20 sends a BRI with MN-ID and a single HNP, then the MAG MUST = consider the=20 revocation of that single HNP and MUST NOT remove the MN1 from the=20 BUL.
 
[Magesh]
What will = be the=20 status of binding lifetime timer?  =
Will the = timer be=20 running even though the single HNP is removed from BUL entry (or will = the=20 timer be stopped).
 
IMO, if = LMA tries to=20 revoke a particular mobility session (Binding Cache Entry), it has to = send the=20 MN-ID and all the
HNP(s) = allocated for=20 the particular session.  Sending of = one HNP=20 out of=20 the allocated n HNP(s) should be =
treated as = Invalid=20 Case. The behavior should be same as PBU received from MAG for = De-Registration=20 (where all the
HNP(s) = allocated are=20 present in the PBU message).
 
Hope this=20 help.
 
Regards,
Ahmad 
 
Thanks
S=20 Magesh
------=_NextPart_000_00D9_01C97AF9.E6E5B930-- --===============2013046354== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============2013046354==-- From mext-bounces@ietf.org Tue Jan 20 01:55:48 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921E228C0EE; Tue, 20 Jan 2009 01:55:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F394F3A6A36; Tue, 20 Jan 2009 01:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm6fCXbk16BL; Tue, 20 Jan 2009 01:55:45 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3BC5E3A69B3; Tue, 20 Jan 2009 01:55:45 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0K9tPL27973; Tue, 20 Jan 2009 09:55:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jan 2009 03:55:14 -0600 Message-ID: In-Reply-To: <200901200635.n0K6ZFxA016051@ricky.india.internal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Processing of BRI (Binding Revocation) by MAG Thread-Index: Acl6MbWiLAZ2wPBbRNyWgrShkUmdqQADGOwAACLlBcAABe3McA== References: <200901200635.n0K6ZFxA016051@ricky.india.internal.net> From: "Ahmad Muhanna" To: "Magesh Shanmugam" Cc: netlmm@ietf.org, mext@ietf.org Subject: Re: [MEXT] Processing of BRI (Binding Revocation) by MAG X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0814517156==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0814517156== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97AE5.370664B8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97AE5.370664B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ahmad =20 I have a query regarding the handling of Binding Revocation by MAG for individual binding session. =20 Following is the scenario: =20 Scenario: =20 1. Proxy Mobile Initial Registration, MAG sends PBU to LMA with HNP option set to ALL_ZERO for MN 1. 2. LMA in turn sends back PBA with 3 HNP(s) assigned to MN 1 and updates Binding Cache Entry. 3. MAG updates Binding Update List entry and sends Router Advertisement to the MN with all the=20 prefixes and prefix lifetime.=20 Note: MAG considers the prefix lifetime as binding lifetime and starts Binding Lifetime timer. 4. Bi-directional tunnel is established between MAG and LMA. =20 5. Prefix Route(s) are created for all the prefixes at MAG. 6. MN 1 gets one IP Address from the alloted 3 HNP(s). 7. LMA sends BRI message with one HNP (out of the alloted 3 HNPs) with revoke trigger as=20 "ADMINISTRATIVE REASON". =20 After step 7, when MAG receives BRI message with only one HNP and MN-ID: =20 Queries: =20 1. Will MAG stop the binding lifetime timer (started after binding session establishment), due to the received BRI message? 2. Will MAG delete the complete Binding Update List maintained for the MN (MN 1) or will it delete only the corresponding HNP entry from the BUL and send RA message to MN 1 (eventhough the IP Address used by MN is not from the HNP received in BRI message)? If it deletes only the corresponding HNP entry, what will happen to the Binding Lifetime timer?=20 =20 [Ahmad] If the LMA assigned 3 HNP for MN1, then if the LMA would like to revoke all of the HNPs, the LMA have one of the following options: =20 1. Send BRI with MN-ID option ONLY. This means that all HNPs are revoked, or=20 =20 [Magesh] If there are multiple interfaces (multi-homed) for the same MN, will MAG remove the Binding Update List maintained for all the interfaces,=20 as there is no Link Layer Identifier Option in the BRI message?=20 =20 [Ahmad] The intention is to have this work sort of a mini global revocation. In other words, if the LMA would like to revoke all of the MN bindings, then including the MN-ID alone will suffice. I do not see any problem in that and should be applicable to multihomed too. If the LMA would like to revoke a single HNP, then LMA need to include the one that needs to be revoked.=20 =20 2. Send a BRI with MN-ID and all HNPs. =20 Although, the draft recommend Number 1 BUT does not prevent No. 2. =20 On the other hand, if the LMA sends a BRI with MN-ID and a single HNP, then the MAG MUST consider the revocation of that single HNP and MUST NOT remove the MN1 from the BUL. =20 [Magesh] What will be the status of binding lifetime timer? =20 Will the timer be running even though the single HNP is removed from BUL entry (or will the timer be stopped).=20 =20 [Ahmad] I probably need to clarify this one. If each HNP maps to a separate binding, then that binding timer which is defined by the included HNP should be cancelled. please see more below. =20 =20 [Magesh] IMO, if LMA tries to revoke a particular mobility session (Binding Cache Entry), it has to send the MN-ID and all the=20 HNP(s) allocated for the particular session. Sending of one HNP out of the allocated n HNP(s) should be treated as Invalid Case. The behavior should be same as PBU received from MAG for De-Registration (where all the HNP(s) allocated are present in the PBU message).=20 =20 [Ahmad] I guess we have two cases here. If the BCE is allocated more than one HNP in the same PBU/PBA, then the LMA should send BRI with MN-ID and no HNP(s) included to revoke the MN BCE. In this specific case, if the LMA chooses to include the HNP option, the LMA SHOULD include all of the allocated HNP(s). IMO, the LMA should include the MN-ID ONLY and should suffice. =20 The other usecase, if the MN with multihoming has multiple BCE(s) with different HNPs for each BCE. In this case, the LMA MAY send a BRI to revoke a single BCE, e.g. with HNP=3DHNP1. In case the LMA sends a BRI with MN-ID ONLY, i.e. without any HNP(s), the MAG should handle this as if all of the MN BCE(s) have been revoked. In other words, if the MN-ID has multiple BCE with different HNP(s), then the inclusion of the HNP in the BRI is crucial for defining the MN BCE that is being revoked. =20 I will make sure that the text in the draft is clear on this. =20 Regards, Ahmad =20 Hope this help. =20 Regards, Ahmad=20 =20 Thanks S Magesh ------_=_NextPart_001_01C97AE5.370664B8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ahmad
 
I = have a query=20 regarding the handling of Binding Revocation by MAG for individual = binding=20 session. 
Following is the=20 scenario:
 
Scenario:
 
1. = Proxy Mobile=20 Initial Registration, MAG sends PBU to LMA with HNP option set to = ALL_ZERO=20 for MN 1.
2. = LMA in turn=20 sends back PBA with 3 HNP(s) assigned to MN 1 and updates Binding = Cache=20 Entry.
3. = MAG updates=20 Binding Update List entry and sends Router Advertisement to the MN = with all=20 the
    prefixes and prefix lifetime. =
    Note: MAG considers the prefix lifetime = as binding=20 lifetime and starts Binding Lifetime timer.
4. = Bi-directional tunnel is established between MAG and LMA. =20
5. = Prefix=20 Route(s) are created for all the prefixes at = MAG.
6. = MN 1 gets one=20 IP Address from the alloted 3 HNP(s).
7. = LMA sends BRI=20 message with one HNP (out of the alloted 3 HNPs) with revoke trigger = as=20
  =20 "ADMINISTRATIVE REASON".
 
After step 7,=20 when MAG receives BRI message with only one HNP and=20 MN-ID:
 
Queries:
 
1. = Will MAG stop=20 the binding lifetime timer (started after binding session = establishment),=20 due to the
    received BRI = message?
2. = Will MAG=20 delete the complete Binding Update List maintained for the MN (MN 1) = or will=20 it delete
    only the corresponding HNP entry from = the BUL and=20 send RA message to MN 1 (eventhough
    the IP Address used by MN is not from = the HNP=20 received in BRI message)?  If it deletes only = the
    corresponding HNP entry, what will = happen to the=20 Binding Lifetime timer? 
 
[Ahmad]
If the LMA assigned = 3 HNP=20 for MN1, then if the LMA would like to revoke all of the HNPs, = the=20 LMA have one of the following=20 options:
 
1. Send BRI with = MN-ID option=20 ONLY. This means that all HNPs are revoked, or 
&nbs= p;
[Magesh] If there are multiple interfaces = (multi-homed) for the same MN, will MAG remove the = Binding=20 Update List maintained for all the interfaces,=20
as there is no=20 Link=20 Layer Identifier Option in the BRI message? 
&nbs= p;
[Ahmad]
The intention is to have this = work sort of a=20 mini global revocation. In other words, if the LMA would like to = revoke all=20 of the MN bindings, then including the MN-ID alone will suffice. I = do not=20 see any problem in that and should be applicable to multihomed too. = If the=20 LMA would like to revoke a single HNP, then LMA need to include = the one=20 that needs to be=20 revoked. 
&nbs= p;
2. Send a BRI with = MN-ID and=20 all HNPs.
 
Although, the draft = recommend=20 Number 1 BUT does not prevent No.=20 2.
 
On the other hand, = if the LMA=20 sends a BRI with MN-ID and a single HNP, then the MAG MUST = consider the=20 revocation of that single HNP and MUST NOT remove the MN1 from the=20 BUL.
 
[Magesh]
What = will be the=20 status of binding lifetime timer?  =
Will = the timer be=20 running even though the single HNP is removed from BUL entry (or = will the=20 timer be stopped). 
&nbs= p;
[Ahmad]
I probably need to clarify this one. = If each=20 HNP maps to a separate binding, then that binding timer which = is=20 defined by the included HNP should be cancelled. please see more=20 = below.   
 
[Magesh]
IMO, if = LMA tries to=20 revoke a particular mobility session (Binding Cache Entry), it has = to send=20 the MN-ID and all the
HNP(s) = allocated for=20 the particular session. Sending of one HNP = out of the allocated n HNP(s) should = be=20 treated as Invalid Case.  
 The behavior should be same = as PBU=20 received from MAG for De-Registration (where all=20 the
HNP(s) = allocated are=20 present in the PBU message). 
&nbs= p;
[Ahmad]
I guess we have two cases here. = If the=20 BCE is allocated more than one HNP in the same PBU/PBA, then the LMA = should=20 send BRI with MN-ID and no HNP(s) included to revoke the MN BCE. In = this=20 specific case, if the LMA chooses to include the HNP option, the LMA = SHOULD=20 include all of the allocated HNP(s). IMO, the LMA should include the = MN-ID=20 ONLY and should = suffice.
&nbs= p;
The other usecase, if the MN with = multihoming=20 has multiple BCE(s) with different HNPs for each BCE. In this = case, the=20 LMA MAY send a BRI to revoke a single BCE, e.g. with HNP=3DHNP1. In = case the=20 LMA sends a BRI with MN-ID ONLY, i.e. without any HNP(s), the MAG = should=20 handle this as if all of the MN BCE(s) have been revoked. In other = words, if=20 the MN-ID has multiple BCE with different HNP(s), then the inclusion = of the=20 HNP in the BRI is crucial for defining the MN BCE that is being=20 revoked.
&nbs= p;
I will make sure that the text in the = draft is=20 clear on this.
&nbs= p;
Regards,
Ahmad
 
Hope this=20 help.
 
Regards,
Ahmad 
 
Thanks
S=20 Magesh
------_=_NextPart_001_01C97AE5.370664B8-- --===============0814517156== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0814517156==-- From mext-bounces@ietf.org Tue Jan 20 02:01:13 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA8E3A6A7A; Tue, 20 Jan 2009 02:01:13 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69BF3A6A7A for ; Tue, 20 Jan 2009 02:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXy37HO6M8Ae for ; Tue, 20 Jan 2009 02:01:10 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 5C53A3A69B3 for ; Tue, 20 Jan 2009 02:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=pstupar@qualcomm.com; q=dns/txt; s=qcdkim; t=1232445654; x=1263981654; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20Comments=20on=20draft-ietf- mext-binding-revocation-02|Date:=20Tue,=2020=20Jan=202009 =2009:59:35=20-0000|Message-ID:=20|In-Reply-To:=20< C5A96676FCD00745B64AE42D5FCC9B6E1CAF5FAF@zrc2hxm0.corp.no rtel.com>|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20Comments=20on=20draft-ietf-mext-binding- revocation-02|Thread-Index:=20AclbLn3taqHuU6TUSgeN3dxQhl2 ykQArrD7gALKdDZAEWRBysAGXgEdQAGd43wAAl3PFsAADWf9wABxFuoA =3D|References:=20=20=20=20=20=20=20=20|From:=20"S tupar,=20Patrick"=20|To:=20"Ahmad =20Muhanna"=20|Cc:=20 |X-OriginalArrivalTime:=2020=20Jan=202009=2010:00:53.0563 =20(UTC)=20FILETIME=3D[FB19A0B0:01C97AE5]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5500"=3B=20a=3D"14797602"; bh=SjKoWhJAXLqzKQ9zgy37nfpDTyxJeifnJAJfky6v9dw=; b=wXV1pDS9s7/azMi+XftZQgqibN5tnbX8usd+QG+RpEg6TMIo4XJXX8Z3 bTbCPFY9jY/3+Wyix/TOGKgORIgVKUJvWXllU09AeAfAhNodGOSWT6m3T MaN2NY1eknGwL/3YBb7RrA0hOuL9ib+Rp5xo5j7SLHBJu787RT0ajjs9t c=; X-IronPort-AV: E=McAfee;i="5300,2777,5500"; a="14797602" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jan 2009 02:00:54 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0KA0suw018280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Jan 2009 02:00:54 -0800 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0KA0rJu012802; Tue, 20 Jan 2009 02:00:53 -0800 Received: from EUEX02.eu.qualcomm.com ([10.222.228.33]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 02:00:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jan 2009 09:59:35 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-mext-binding-revocation-02 Thread-Index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQArrD7gALKdDZAEWRBysAGXgEdQAGd43wAAl3PFsAADWf9wABxFuoA= References: From: "Stupar, Patrick" To: "Ahmad Muhanna" X-OriginalArrivalTime: 20 Jan 2009 10:00:53.0563 (UTC) FILETIME=[FB19A0B0:01C97AE5] Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, I don't think that the "MODIFIED" text you proposed is wrong, I think that part of it is redundant and already covered. If you think that your proposal is more suitable I can live with that. Some additional comments below. Regards, Patrick > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Tuesday, January 20, 2009 12:23 AM > To: Stupar, Patrick > Cc: mext@ietf.org > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > Hi Patrick, > > As I said, your proposed text for the second bullet was not clear to > me. > On the other hand, the first bullet specify what happened if any of the > two checks fail, i.e. if the received BRI does not have an entry in its > BUL. > > The second bullet specify what happened if these two checks were > successful. There is nothing wrong in being explicit and clear without > any ambiguity. Finally, how come your question is valid against the > clarified text and NOT against yours? > > Can I say that you have a problem with the following text: Can you > specify what is wrong in it? > > o If the Acknowledgement (A) bit is set in the Binding Revocation > Indication and its Binding Update List contains an entry for the > IP address in the type 2 routing header, the mobile node MUST > send a Binding Revocation Acknowledgement. You added the sentence "and its Binding Update List contains an entry for the IP address in the type 2 routing header": this is already described in the previous bullet, that's why I had the comment against your modified text and not mine. But as I said before, it's not wrong but only redundant. > > > Regards, > Ahmad > > > > -----Original Message----- > > From: Stupar, Patrick [mailto:pstupar@qualcomm.com] > > Sent: Monday, January 19, 2009 8:00 PM > > To: Muhanna, Ahmad (RICH1:2H10) > > Cc: mext@ietf.org > > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > > > Hi Ahmad, > > > > Please see below. > > > > Best Regards, > > > > Patrick > > > > > -----Original Message----- > > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > Sent: Friday, January 16, 2009 7:51 PM > > > To: Stupar, Patrick > > > Cc: mext@ietf.org > > > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > > > > > Hi Patrick, > > > Thanks. One slight modification below. > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Stupar, Patrick [mailto:pstupar@qualcomm.com] > > > > Sent: Friday, January 16, 2009 11:18 AM > > > > To: Muhanna, Ahmad (RICH1:2H10) > > > > Cc: mext@ietf.org > > > > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > > > > > > > > > [Ahmad] > > > > > I see what you are saying. I assumed that this is in the > > > > form of NAI. > > > > > we > > > > > can add some text to clarify that, would that address your > > > > concern or > > > > > you have in mind a possible different format? > > > > > > > > I think this would be good. Either a definition in section > > > > 2.2 or a clarification in the text would be fine with me. > > > > > > [Ahmad] > > > Sure. > > > > > > > > > > > > > > > > [Ahmad] > > > > > Currently, neither the HoA nor the CoA is included in the > > > > BRI message. > > > > > Are you suggesting that we add those options as valid ones > > > > in the BRI? > > > > > > > > No I am not. What I meant here is that HoA is in the > > routing header > > > > of the packet containing the BRI. Checking of HoA would be enough > > > > IMO. It could be moved to the previous bullet of the list > > as in the > > > > following proposed text: > > > > OLD TEXT: > > > > " > > > > o The mobile node MUST verify that the IP address in > > the type 2 > > > > routing header is its Home Address. > > > > > > > > o If the Acknowledgement (A) bit is set in the Binding > > Revocation > > > > Indication and the MN has the BCE in registered state, the > > > > mobile > > > > node MUST send a Binding Revocation Acknowledgement. > > > > However, in > > > > all other cases when the (A) bit is set in the BRI, > > the mobile > > > > node SHOULD send a Binding Revocation > > Acknowledgement. In all > > > > cases, the mobile node MUST follow Section 11.2 when send a > > BRA > > > > using the appropriate status code. > > > > " > > > > NEW TEXT > > > > " > > > > o The mobile node MUST verify that the IP address in > > the type 2 > > > > routing header is its Home Address and that its > > Binding Update > > > > List contains an entry for that Home Address. If one of > > the tests > > > > fails, > > > > the mobile node SHOULD silently discard the received BRI > > > > message. > > > > > > > > o If the Acknowledgement (A) bit is set in the Binding > > Revocation > > > > Indication, the mobile > > > > node MUST send a Binding Revocation Acknowledgement. > > > > However, in > > > > all other cases when the (A) bit is set in the BRI, > > the mobile > > > > node SHOULD send a Binding Revocation > > Acknowledgement. In all > > > > cases, the mobile node MUST follow Section 11.2 when send a > > BRA > > > > using the appropriate status code. > > > > " > > > > > > [Ahmad] > > > I am not sure I follow the second bullet of the "NEW TEXT". > > What about > > > the following modified text: > > > > > > "MODIFIED TEXT" > > > > > > o The mobile node MUST verify that the IP address in the type 2 > > > routing header is its Home Address and that its Binding > Update > > > List contains an entry for that Home Address. If one of > > the tests, > > > fails the mobile node SHOULD silently discard the received BRI > > > message. > > > > > > o If the Acknowledgement (A) bit is set in the Binding > > Revocation > > > Indication and its Binding Update List contains an > > entry for the > > > IP address in the type 2 routing header, the mobile node MUST > > > send a Binding Revocation Acknowledgement. However, in > > > all other cases when the (A) bit is set in the BRI, the > mobile > > > node SHOULD send a Binding Revocation Acknowledgement. In > all > > > cases, the mobile node MUST follow Section 11.2 when > > send a BRA > > > using the appropriate status code. > > > > > [Patrick] > > The actions in the first bullet apply to any received BRI > > (also to those with the A bit set). Having said that, in the > > second bullet it is only required to specify the additional > > operation (i.e. sending a BRA) the MN has to perform when the > > A bit is set. IMO the text you added is redundant and not > > required. Do you have some particular scenario I am missing? > > > > > > > > > > > > > > Please note that the proposed text overlaps with the last bullet > > > > listed in section 11.2. I would remove that as in the > > > > following: > > > > > > > > Old text: > > > > "11.2. Sending Binding Revocation Acknowledgement > > > > > > > > When the mobile node receive a valid Binding Revocation > > Indication > > > > with the (A) bit is set from its home agent and while > > having this > > > > BCE > > > > in registered state, the mobile node MUST send a packet to its > > > home > > > > agent containing a Binding Revocation Acknowledgement > according > > to > > > > the procedure in Section 7.1 and the following: > > > > > > > > o The mobile node MUST set the status field to successful to > > > > reflect > > > > that it has received the Binding Revocation Indication and > > > > acknowledge that its IP connectivity with its home > > agent has > > > > been > > > > revoked. > > > > > > > > o The destination IP address of the IPv6 packet of the > Binding > > > > Revocation Acknowledgement is set to the source IP > > address of > > > > the > > > > received IPv6 packet of the Binding Revocation Indication. > > The > > > > Mobile Node MUST include its home address in the > > Home Address > > > > option in the Destination Option. > > > > > > > > o If the mobile node receives a Binding Revocation Indication > > > > from a > > > > home agent which the mobile node does not have a registered > > > > binding with, the mobile node SHOULD silently > > discard the BRI > > > > message. The mobile node should continue to use > > its assigned > > > > HoA > > > > to access its IP mobility service." > > > > > > > > New text: > > > > "11.2. Sending Binding Revocation Acknowledgement > > > > > > > > When the mobile node receive a valid Binding Revocation > > Indication > > > > with the (A) bit is set from its home agent and while > > having this > > > > BCE > > > > in registered state, the mobile node MUST send a packet to its > > > home > > > > agent containing a Binding Revocation Acknowledgement > according > > to > > > > the procedure in Section 7.1 and the following: > > > > > > > > o The mobile node MUST set the status field to successful to > > > > reflect > > > > that it has received the Binding Revocation Indication and > > > > acknowledge that its IP connectivity with its home > > agent has > > > > been > > > > revoked. > > > > > > > > o The destination IP address of the IPv6 packet of the > Binding > > > > Revocation Acknowledgement is set to the source IP > > address of > > > > the > > > > received IPv6 packet of the Binding Revocation Indication. > > The > > > > Mobile Node MUST include its home address in the > > Home Address > > > > option in the Destination Option." > > > > > > [Ahmad] > > > Sure. That is fair and good. > > > > > > Best Regards, > > > Ahmad > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jan 20 02:06:20 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87BD3A6A36; Tue, 20 Jan 2009 02:06:19 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0E83A6A11 for ; Tue, 20 Jan 2009 02:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=1.245, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wj9XYCdi7eV for ; Tue, 20 Jan 2009 02:06:16 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 6E7243A67A7 for ; Tue, 20 Jan 2009 02:06:16 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDR00DLKLDY8E@szxga01-in.huawei.com> for mext@ietf.org; Tue, 20 Jan 2009 18:05:58 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDR00KYVLDYC4@szxga01-in.huawei.com> for mext@ietf.org; Tue, 20 Jan 2009 18:05:58 +0800 (CST) Received: from s68128b ([10.111.148.189]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDR006TXLDW6H@szxml04-in.huawei.com> for mext@ietf.org; Tue, 20 Jan 2009 18:05:58 +0800 (CST) Date: Tue, 20 Jan 2009 18:05:56 +0800 From: Shi Xiaoyan In-reply-to: To: 'Hesham Soliman' Message-id: <010801c97ae6$b0affc80$bd946f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acl4e/1gnce/8wg+TyC7IjHZuRMuKQANY/OkAEesPfAAF25TZwArr7WQ Cc: mext@ietf.org Subject: Re: [MEXT] IPv4 home address option in DSMIP X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Monday, January 19, 2009 8:04 PM > To: Shi Xiaoyan > Cc: mext@ietf.org > Subject: Re: IPv4 home address option in DSMIP > > 1. BU without IPv4 home address option works well for extending > > lifetime. I can't understand what you said "how a BU > works". Is there > > any Specification to require that BU for exending lifetime must be > > consistent with BU for first register? Is there any special > effect? In > > fact, with more and more extension for BU in future, the > requirement > > that BU for exending lifetime must be consistent with BU > for first register will cause unnecessary load. > > => Yes I know that will use more bandwidth but I don't > understand what you're objecting to. Implementations copy the > contents of the new BU into the BC to replace the old entry, > as specified in 3775. So a new BU overwrites the old one > unless you desgin a new option per extension that tells the > receiver to only refresh. > In my opinion, re-registration BU should not include the IPv4 HAO. Because re-registration BU with IPv4 HAO 1. Need more bandwidth. 2. Cause extra load on HA. Because HA must verify if the address in IPv4 HAO match that in BCE in order to avoid MN use a unauthorized IPv4 address. In fact, since "the home agent MUST be able to find the IPv4 home address of a mobile node when given the IPv6 home address", section 5.5, why IPv4 HAO must be include in re-registration BU? I can't find any benefit. I didn't find the description in 3775 for "a new BU overwrites the old one". It should be implementation issue. It also could be done as that attributes in BCE also include in re-registration BU should be overwriten and other attribute not included in re-registration BU should remain valid. De-registration for IPv4 HoA can be done by adding a bit in IPv4 HAO option for indicating de-registration, or any other ways. It is all ok. I just think it is unnecessary that re-registration BU include the IPv4 HAO. :-) > > > > 2. We can find many other ways to delete the IPv4 binding if it is > > consensus that re-registration BU does not have to include the IPv4 > > HAO. It could not be a resason for re-registration BU must > including IPv4 HAO. > > => Well, that's the reason now, if you have better ideas, > other than designing a new option per extension please send > them to the list. This is already a bit late given that I'm > making the last update for IESG comments. > > Hesham > > > > >> > >> Hesham > >> > >>> > >>> > >>> Regards, > >>> Xiaoyan > >> > > > > Regards, > > Xiaoyan > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jan 20 07:00:02 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19B0428C0DF; Tue, 20 Jan 2009 07:00:02 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6FA2B3A6991; Tue, 20 Jan 2009 07:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090120150001.6FA2B3A6991@core3.amsl.com> Date: Tue, 20 Jan 2009 07:00:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-aero-reqs-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks Author(s) : W. Eddy, et al. Filename : draft-ietf-mext-aero-reqs-03.txt Pages : 29 Date : 2009-01-20 This document describes the requirements and desired properties of NEMO Route Optimization techniques for use in global networked communications systems for aeronautics and space exploration. This version has been reviewed by members of the International Civil Aviation Orgnanization (ICAO) and other aeronautical communications standards bodies, and contributed to by a number of aeronautical communications experts outside the normal IETF process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-aero-reqs-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-aero-reqs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-20065716.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Tue Jan 20 19:06:05 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5263A6991; Tue, 20 Jan 2009 19:06:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E78E3A6991 for ; Tue, 20 Jan 2009 19:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsbD9-ISFuwh for ; Tue, 20 Jan 2009 19:06:02 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 317AA3A6863 for ; Tue, 20 Jan 2009 19:06:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,297,1231113600"; d="scan'208";a="233585046" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 21 Jan 2009 03:05:46 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0L35kjr014306; Tue, 20 Jan 2009 19:05:46 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0L35kvn021717; Wed, 21 Jan 2009 03:05:46 GMT Date: Tue, 20 Jan 2009 19:05:45 -0800 (PST) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=849; t=1232507146; x=1233371146; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20GRE=20support=20in=20DSMIPv6=2 0-=20AD=20review |Sender:=20; bh=n6lGarDETwbonYD4Vr7XGfWMKP4Xtrz0eCcUj1hMvCE=; b=mB3rbrwtd9trALxersLxs+RP2UqH53oHJ+lzkRHe9Lpg1G4skGtihZaxrI 7AWCY96kMX3hwrqWLzHOSgHmk7XtObYA9xtZHYID/m/O3/uXsy6eb6P4i74W Owk6DsFxKBVZa5l5hNeXE3n8jsZuz+aPtfs4LOVJDZ7ICrYhY4OhU=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Tue, 20 Jan 2009, Hesham Soliman wrote: >> >> The issue would be that this spec needs to understand the payload >> qualifier, else we cant add themm later. > > => It's not true though. You can add the exact same thing that we have in > the draft now but specify it in a more complete manner and it will be > backward compatible and interoperable. The negotiation bit in the BU would > have to be included in the new draft of course. > Leaving the TLV header alone in this draft will provide the necessary frame work. Else, defining outside and mapping the pre-allocated v4/v6 types, will appear more like a hack. Since, Pasi's comment was more specific to GRE, not sure if it was about the TLV alone, as there is much text required for TLV nego, or for describing the TLV format, thats already there in the draft. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jan 20 20:04:39 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C49B3A6A33; Tue, 20 Jan 2009 20:04:39 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2436C3A6A33 for ; Tue, 20 Jan 2009 20:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qp5cXW5WYVls for ; Tue, 20 Jan 2009 20:04:37 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 319E53A6A1C for ; Tue, 20 Jan 2009 20:04:36 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LPUK0-0002fS-A6; Wed, 21 Jan 2009 15:04:08 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 21 Jan 2009 15:04:01 +1100 From: Hesham Soliman To: Sri Gundavelli Message-ID: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl7fUqhKt2xTxPoYUe0GEBr6YBGbw== In-Reply-To: Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 21/01/09 2:05 PM, "Sri Gundavelli" wrote: > > > On Tue, 20 Jan 2009, Hesham Soliman wrote: > >>> >>> The issue would be that this spec needs to understand the payload >>> qualifier, else we cant add themm later. >> >> => It's not true though. You can add the exact same thing that we have in >> the draft now but specify it in a more complete manner and it will be >> backward compatible and interoperable. The negotiation bit in the BU would >> have to be included in the new draft of course. >> > > Leaving the TLV header alone in this draft will provide the > necessary frame work. => You're not answering the comment I mentioned above Sri. Else, defining outside and mapping the > pre-allocated v4/v6 types, will appear more like a hack. Since, > Pasi's comment was more specific to GRE, not sure if it was > about the TLV alone, => Let's not talk about hacks....Pasi strongly suggested that we remove the TLV completely and do it for PMIPv6. I think there is enough people who already agree with that and I don't see a reason for us to debate this endlessly. This draft is long overdue. So, it's best to include this in a specific PMIP draft. as there is much text required for TLV > nego, or for describing the TLV format, thats already there in > the draft. => Right, you can easily copy and paste it. Hesham > > Sri > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jan 20 23:02:02 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F5163A6A1A; Tue, 20 Jan 2009 23:02:02 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00E803A6A1A for ; Tue, 20 Jan 2009 23:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvFkK5blOQ+w for ; Tue, 20 Jan 2009 23:02:00 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8B5973A6800 for ; Tue, 20 Jan 2009 23:02:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,299,1231113600"; d="scan'208";a="233689616" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 21 Jan 2009 07:01:44 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0L71iqV004069; Tue, 20 Jan 2009 23:01:44 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0L71iWY025304; Wed, 21 Jan 2009 07:01:44 GMT Date: Tue, 20 Jan 2009 23:01:44 -0800 (PST) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2022; t=1232521304; x=1233385304; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20GRE=20support=20in=20DSMIPv6=2 0-=20AD=20review |Sender:=20; bh=zBXKhYMpz6uP0AIPGzT1zY+leL4golMldZyDCYt7jK4=; b=YPi+K0CeDGACSJjucoVOu/bczUkFz/OankRa85d4iNuvcw5eiQFmLP9cyE rng6U4yMDD7iZCX+q12mEk7b2K8kmZbVtkOoOZTgUdX58tuvfrsB3i3ih+cJ JMxRpb4av6; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, On Wed, 21 Jan 2009, Hesham Soliman wrote: >> >> Leaving the TLV header alone in this draft will provide the >> necessary frame work. > > => You're not answering the comment I mentioned above Sri. > First, I really feel the pain you had to deal with this draft, if that makes you feel any better. Its incredible, how many issues hit this draft at each level. Totally understand your efforts and that this needs to move. On this specific issue, my point is that if GRE is underspecified, lets not define the GRE type. But, I dont know why its any issue to have to that TLV, just as 3519, CAPWAP or any tunnel have headers, its just payload qualifier, for which you already have the text. But, we dont have argue on this, I go with the consensus. I'm only afraid, we take this out from here, this will never see the day of the light. If there are some thoughts, on where it will go and that there will be no issues moving it to the other draft, that will help and will also not affect the long reached earlier consensus, phone calls ..etc. Again, please reconsider keeping the TLV, I dont see any reason how that will help moving it out, moving GRE, I can understand, but TLV, not sure. My 2c. Regards Sri > Else, defining outside and mapping the >> pre-allocated v4/v6 types, will appear more like a hack. Since, >> Pasi's comment was more specific to GRE, not sure if it was >> about the TLV alone, > > => Let's not talk about hacks....Pasi strongly suggested that we remove the > TLV completely and do it for PMIPv6. I think there is enough people who > already agree with that and I don't see a reason for us to debate this > endlessly. This draft is long overdue. So, it's best to include this in a > specific PMIP draft. > > > as there is much text required for TLV >> nego, or for describing the TLV format, thats already there in >> the draft. > > => Right, you can easily copy and paste it. > > Hesham > >> >> Sri >> >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jan 20 23:08:16 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AA343A6A1A; Tue, 20 Jan 2009 23:08:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348C53A6A1A for ; Tue, 20 Jan 2009 23:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbRQfhLk84Zs for ; Tue, 20 Jan 2009 23:08:14 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 4DC5E3A67CC for ; Tue, 20 Jan 2009 23:08:13 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LPXBo-0000Uu-RN; Wed, 21 Jan 2009 18:07:53 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 21 Jan 2009 18:07:48 +1100 From: Hesham Soliman To: Sri Gundavelli Message-ID: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl7lvc8NBlF3S1gP0uYg4OO+2MeqA== In-Reply-To: Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org >>> Leaving the TLV header alone in this draft will provide the >>> necessary frame work. >> >> => You're not answering the comment I mentioned above Sri. >> > > First, I really feel the pain you had to deal with this draft, > if that makes you feel any better. Its incredible, how many > issues hit this draft at each level. Totally understand your > efforts and that this needs to move. => Thanks. I just have to highlight two points: - I'm expressing my opinion as a member of the WG. In this case I happened to agree with the IESG review. - It's not up to me to reconsider, you've seen the comments from Pasi in the IESG review and you've seen other people's responses agreeing to remove this. Again, I happen to agree with them, but it's not my decision to "reconsider" even if I didn't agree. Also as you noted time is not on our side. > I'm only afraid, we take this out from here, this will never see > the day of the light. If there are some thoughts, on where it will > go and that there will be no issues moving it to the other draft, > that will help and will also not affect the long reached earlier > consensus, phone calls ..etc. => I think it will be fine in NETLMM, you can add it to the IPv4 support work if you like as an extension to DSMIPv6. I can't see why it will be blocked in NETLMM, everyone there seems to be happy with it for PMIPv6. Hesham Again, please reconsider keeping > the TLV, I dont see any reason how that will help moving it out, > moving GRE, I can understand, but TLV, not sure. My 2c. > > > Regards > Sri > > > > >> Else, defining outside and mapping the >>> pre-allocated v4/v6 types, will appear more like a hack. Since, >>> Pasi's comment was more specific to GRE, not sure if it was >>> about the TLV alone, >> >> => Let's not talk about hacks....Pasi strongly suggested that we remove the >> TLV completely and do it for PMIPv6. I think there is enough people who >> already agree with that and I don't see a reason for us to debate this >> endlessly. This draft is long overdue. So, it's best to include this in a >> specific PMIP draft. >> >> >> as there is much text required for TLV >>> nego, or for describing the TLV format, thats already there in >>> the draft. >> >> => Right, you can easily copy and paste it. >> >> Hesham >> >>> >>> Sri >>> >>> >> >> >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jan 20 23:17:27 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B187E3A6A7E; Tue, 20 Jan 2009 23:17:27 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29163A6A7E for ; Tue, 20 Jan 2009 23:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRRSZb9ERPFV for ; Tue, 20 Jan 2009 23:17:26 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 255DD3A6A4D for ; Tue, 20 Jan 2009 23:17:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,299,1231113600"; d="scan'208";a="131518259" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 21 Jan 2009 07:17:10 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n0L7HApZ007603; Tue, 20 Jan 2009 23:17:10 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0L7H9BC023840; Wed, 21 Jan 2009 07:17:09 GMT Date: Tue, 20 Jan 2009 23:17:09 -0800 (PST) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=605; t=1232522230; x=1233386230; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20GRE=20support=20in=20DSMIPv6=2 0-=20AD=20review |Sender:=20; bh=2A5k5sMRIuxOAy5JSv2IzwlAoA9VftBNl8s7PhV1mI8=; b=UZbMMkaCA23lqjUOPvDIEHYdU7LSB1670IuP6xwpsnUGdsaeXteRHT8TTF lQH/JnvqbvVWoUbJorajoKGzP4+GC3WtYa8E/+DnSAFPbdKyj6C51mSISXYN Xpny3gHm6I; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Wed, 21 Jan 2009, Hesham Soliman wrote: > => Thanks. I just have to highlight two points: > - I'm expressing my opinion as a member of the WG. In this case I happened > to agree with the IESG review. > - It's not up to me to reconsider, you've seen the comments from Pasi in the > IESG review and you've seen other people's responses agreeing to remove > this. May be Pasi/IESG can clarify on this. As I understood, he was more concerned on the lack of specification on the GRE tunneling mechanism and not specific to TLV related header, there is not much to specify there. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jan 21 06:33:31 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C747528C0F3; Wed, 21 Jan 2009 06:33:31 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6ED3A6B49 for ; Wed, 21 Jan 2009 06:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.295 X-Spam-Level: X-Spam-Status: No, score=-5.295 tagged_above=-999 required=5 tests=[AWL=1.304, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haGtrNQxdQRd for ; Wed, 21 Jan 2009 06:33:29 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5D5293A694F for ; Wed, 21 Jan 2009 06:33:28 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.138.213]) by smtp01.uc3m.es (Postfix) with ESMTP id 571E7B4CFC4 for ; Wed, 21 Jan 2009 15:33:08 +0100 (CET) Message-ID: <49773224.3080309@it.uc3m.es> Date: Wed, 21 Jan 2009 15:33:08 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: mext X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16414.005 Subject: [MEXT] [Fwd: RE: Last Call: draft-ietf-mext-nemo-mib (NEMO Management Information Base) to Proposed Standard] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org forwarding on behalf of Dan... -------- Mensaje original -------- Asunto: RE: Last Call: draft-ietf-mext-nemo-mib (NEMO Management Information Base) to Proposed Standard Fecha: Wed, 21 Jan 2009 14:53:10 +0100 De: Romascanu, Dan (Dan) Para: CC: mext@ietf.org Referencias: <20090113161148.4F49A3A6981@core3.amsl.com> This review is a super-set of the MIB Doctor review by Bert Wijnen. This document is not completely ready for being taken into discussion by the IESG. Although there is no major issue with the current version of the document the issues described at #3, #7, #8 and #10 must be fixed. Correcting the other issues raised in the comments is recommended. 1. Section 2.2 (implementation guidance) is incomplete. It should mention the need to support ifTable from IF-MIB as InterfaceIndex is IMPORTed. Also better rename it 'Relationship to other MIB modules'. 2. Compilation is OK - running SMICng (strict checking) results in: W: f(nemo.mi2), (221,5) Row "nemoMrBLEntry" has indexing that may create variables with more than 128 sub-ids W: f(nemo.mi2), (404,5) Row "nemoHaMobileNetworkPrefixEntry" has indexing that may create variables w ith more than 128 sub-ids W: f(nemo.mi2), (540,5) Row "nemoBindingCacheEntry" has indexing that may create variables with more than 128 sub-ids W: f(nemo.mi2), (1092,5) Row "nemoHaCounterEntry" has indexing that may create variables with more th an 128 sub-ids Two are AUGEMENTS, the other two do have a warning in the DESCIRPITON clauses, so OK. 3. The Object nemoMrPrefixRegMode is writable but there is no description of the expected persistency behavior. For read-write object nemoStatus: The value of this object SHOULD remain unchanged across reboots of the managed entity. A SHOULD does not really help a management station as it cannot count for sure on persistency. 4. nemoNotifications OBJECT IDENTIFIER ::= { nemoMIB 0 } nemoObjects OBJECT IDENTIFIER ::= { nemoMIB 1 } nemoConformance OBJECT IDENTIFIER ::= { nemoMIB 3 } Why the Conformance is not under { nemoMIB 2 } as recommended by RFC4181? 5. I see a few times: SYNTAX INTEGER { implicitMode (1), explicitMode (2) } Candidate for a TC. But not a fatal flaw of course 6. I think that according the guidelines in RFC4181, this one nemoHaMobileNetworkPrefixSeqNo OBJECT-TYPE SYNTAX Integer32 (1..1024) would better be an Unsigned32. Again, not a fatal flaw. 7. nemoBindingMrFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "true(1) indicates that the binding cache entry is from an entity acting as a mobile router. false(0) implies that the binding cache entry is from an entity acting as a mobile node. " But the TC in RFC2579 says: TruthValue ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents a boolean value." SYNTAX INTEGER { true(1), false(2) } So it should be false(2) and not false(0) in the DESCRIPTION clause. 8. The document must have normative references to RFC 2863 and RFC 4001 as the MIB module defined in this document IMPORTs objects from the MIB modules defined in these RFCs. 9. No need to carry commented objects in the IMPORTS section. 10. The REVISION date is in the future - points to November 12 and not to January 12. 11. It would be useful to add UNITS clauses to the Counter objects. Dan > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG > Sent: Tuesday, January 13, 2009 6:12 PM > To: IETF-Announce > Cc: mext@ietf.org > Subject: Last Call: draft-ietf-mext-nemo-mib (NEMO Management > Information Base) to Proposed Standard > > The IESG has received a request from the Mobility EXTensions > for IPv6 WG > (mext) to consider the following document: > > - 'NEMO Management Information Base ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send > substantive comments to the ietf@ietf.org mailing lists by > 2009-01-27. Exceptionally, comments may be sent to > iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-04.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > w_id&dTag=16994&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 22 08:03:19 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8EB3A69C6; Thu, 22 Jan 2009 08:03:19 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1643A6A72; Wed, 21 Jan 2009 05:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9OVgFbaj7Wx; Wed, 21 Jan 2009 05:53:49 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 247183A694F; Wed, 21 Jan 2009 05:53:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,300,1231131600"; d="scan'208";a="158522905" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 21 Jan 2009 08:53:32 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Jan 2009 08:53:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jan 2009 14:53:10 +0100 Message-ID: In-Reply-To: <20090113161148.4F49A3A6981@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-mext-nemo-mib (NEMO Management Information Base) to Proposed Standard Thread-Index: Acl1mcGYVQrzZ93SSNmlYlUPVHzOrgBeppXg References: <20090113161148.4F49A3A6981@core3.amsl.com> From: "Romascanu, Dan (Dan)" To: X-Mailman-Approved-At: Thu, 22 Jan 2009 08:03:18 -0800 Cc: mext@ietf.org Subject: Re: [MEXT] Last Call: draft-ietf-mext-nemo-mib (NEMO Management Information Base) to Proposed Standard X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This review is a super-set of the MIB Doctor review by Bert Wijnen. This document is not completely ready for being taken into discussion by the IESG. Although there is no major issue with the current version of the document the issues described at #3, #7, #8 and #10 must be fixed. Correcting the other issues raised in the comments is recommended. 1. Section 2.2 (implementation guidance) is incomplete. It should mention the need to support ifTable from IF-MIB as InterfaceIndex is IMPORTed. Also better rename it 'Relationship to other MIB modules'. 2. Compilation is OK - running SMICng (strict checking) results in: W: f(nemo.mi2), (221,5) Row "nemoMrBLEntry" has indexing that may create variables with more than 128 sub-ids W: f(nemo.mi2), (404,5) Row "nemoHaMobileNetworkPrefixEntry" has indexing that may create variables w ith more than 128 sub-ids W: f(nemo.mi2), (540,5) Row "nemoBindingCacheEntry" has indexing that may create variables with more than 128 sub-ids W: f(nemo.mi2), (1092,5) Row "nemoHaCounterEntry" has indexing that may create variables with more th an 128 sub-ids Two are AUGEMENTS, the other two do have a warning in the DESCIRPITON clauses, so OK. 3. The Object nemoMrPrefixRegMode is writable but there is no description of the expected persistency behavior. For read-write object nemoStatus: The value of this object SHOULD remain unchanged across reboots of the managed entity. A SHOULD does not really help a management station as it cannot count for sure on persistency. 4. nemoNotifications OBJECT IDENTIFIER ::= { nemoMIB 0 } nemoObjects OBJECT IDENTIFIER ::= { nemoMIB 1 } nemoConformance OBJECT IDENTIFIER ::= { nemoMIB 3 } Why the Conformance is not under { nemoMIB 2 } as recommended by RFC4181? 5. I see a few times: SYNTAX INTEGER { implicitMode (1), explicitMode (2) } Candidate for a TC. But not a fatal flaw of course 6. I think that according the guidelines in RFC4181, this one nemoHaMobileNetworkPrefixSeqNo OBJECT-TYPE SYNTAX Integer32 (1..1024) would better be an Unsigned32. Again, not a fatal flaw. 7. nemoBindingMrFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "true(1) indicates that the binding cache entry is from an entity acting as a mobile router. false(0) implies that the binding cache entry is from an entity acting as a mobile node. " But the TC in RFC2579 says: TruthValue ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents a boolean value." SYNTAX INTEGER { true(1), false(2) } So it should be false(2) and not false(0) in the DESCRIPTION clause. 8. The document must have normative references to RFC 2863 and RFC 4001 as the MIB module defined in this document IMPORTs objects from the MIB modules defined in these RFCs. 9. No need to carry commented objects in the IMPORTS section. 10. The REVISION date is in the future - points to November 12 and not to January 12. 11. It would be useful to add UNITS clauses to the Counter objects. Dan > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG > Sent: Tuesday, January 13, 2009 6:12 PM > To: IETF-Announce > Cc: mext@ietf.org > Subject: Last Call: draft-ietf-mext-nemo-mib (NEMO Management > Information Base) to Proposed Standard > > The IESG has received a request from the Mobility EXTensions > for IPv6 WG > (mext) to consider the following document: > > - 'NEMO Management Information Base ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send > substantive comments to the ietf@ietf.org mailing lists by > 2009-01-27. Exceptionally, comments may be sent to > iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-04.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > w_id&dTag=16994&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 22 19:36:17 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2BBE3A694C; Thu, 22 Jan 2009 19:36:17 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37E23A694C for ; Thu, 22 Jan 2009 19:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04kWIVW6S4af for ; Thu, 22 Jan 2009 19:36:15 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B347B3A68FE for ; Thu, 22 Jan 2009 19:36:15 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDW005KGNBX0L@szxga04-in.huawei.com> for mext@ietf.org; Fri, 23 Jan 2009 11:35:57 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDW004EMNBX4F@szxga04-in.huawei.com> for mext@ietf.org; Fri, 23 Jan 2009 11:35:57 +0800 (CST) Received: from s68128b ([10.111.148.189]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDW00LI0NBXSE@szxml04-in.huawei.com> for mext@ietf.org; Fri, 23 Jan 2009 11:35:57 +0800 (CST) Date: Fri, 23 Jan 2009 11:35:56 +0800 From: Shi Xiaoyan In-reply-to: <010801c97ae6$b0affc80$bd946f0a@china.huawei.com> To: 'Hesham Soliman' Message-id: <00d801c97d0b$b3f61150$bd946f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acl4e/1gnce/8wg+TyC7IjHZuRMuKQANY/OkAEesPfAAF25TZwArr7WQAIoxv7A= Cc: mext@ietf.org Subject: Re: [MEXT] IPv4 home address option in DSMIP X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, HA doesn't replace the BCE such as remove the old BCE and creat a new one when recieved BU. HA just update the option in BCE also included in BU and others option in BCE remain valid. Such as draft-ietf-monami6-multiplecoa-11, When multiple Binding Identifier mobility options are present in the Binding Update, it is treated as bulk registration. But not all BCE should be removed. Only when 'O' flag is set, HA remove all old BCE. Regards, Xiaoyan > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Shi Xiaoyan > Sent: Tuesday, January 20, 2009 6:06 PM > To: 'Hesham Soliman' > Cc: mext@ietf.org > Subject: Re: [MEXT] IPv4 home address option in DSMIP > > > > > -----Original Message----- > > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > > Sent: Monday, January 19, 2009 8:04 PM > > To: Shi Xiaoyan > > Cc: mext@ietf.org > > Subject: Re: IPv4 home address option in DSMIP > > > > 1. BU without IPv4 home address option works well for extending > > > lifetime. I can't understand what you said "how a BU > > works". Is there > > > any Specification to require that BU for exending > lifetime must be > > > consistent with BU for first register? Is there any special > > effect? In > > > fact, with more and more extension for BU in future, the > > requirement > > > that BU for exending lifetime must be consistent with BU > > for first register will cause unnecessary load. > > > > => Yes I know that will use more bandwidth but I don't > understand what > > you're objecting to. Implementations copy the contents of > the new BU > > into the BC to replace the old entry, as specified in 3775. > So a new > > BU overwrites the old one unless you desgin a new option > per extension > > that tells the receiver to only refresh. > > > > In my opinion, re-registration BU should not include the IPv4 > HAO. Because re-registration BU with IPv4 HAO 1. Need more bandwidth. > 2. Cause extra load on HA. Because HA must verify if the > address in IPv4 HAO match that in BCE in order to avoid MN > use a unauthorized IPv4 address. > > In fact, since "the home agent MUST be able to find the IPv4 > home address of a mobile node when given the IPv6 home > address", section 5.5, why IPv4 HAO must be include in > re-registration BU? I can't find any benefit. > > I didn't find the description in 3775 for "a new BU > overwrites the old one". > It should be implementation issue. > It also could be done as that attributes in BCE also include > in re-registration BU should be overwriten and other > attribute not included in re-registration BU should remain valid. > > De-registration for IPv4 HoA can be done by adding a bit in > IPv4 HAO option for indicating de-registration, or any other > ways. It is all ok. > I just think it is unnecessary that re-registration BU > include the IPv4 HAO. > :-) > > > > > > > > > 2. We can find many other ways to delete the IPv4 binding > if it is > > > consensus that re-registration BU does not have to > include the IPv4 > > > HAO. It could not be a resason for re-registration BU must > > including IPv4 HAO. > > > > => Well, that's the reason now, if you have better ideas, > other than > > designing a new option per extension please send them to the list. > > This is already a bit late given that I'm making the last > update for > > IESG comments. > > > > Hesham > > > > > > > >> > > >> Hesham > > >> > > >>> > > >>> > > >>> Regards, > > >>> Xiaoyan > > >> > > > > > > Regards, > > > Xiaoyan > > > > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 22 20:18:12 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B633A6914; Thu, 22 Jan 2009 20:18:12 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989153A67F7 for ; Thu, 22 Jan 2009 20:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTYa-YPz3mDn for ; Thu, 22 Jan 2009 20:18:10 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 5D4733A6914 for ; Thu, 22 Jan 2009 20:18:09 -0800 (PST) Received: from [60.224.64.52] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LQDUM-0005vm-10; Fri, 23 Jan 2009 15:17:50 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 23 Jan 2009 15:17:43 +1100 From: Hesham Soliman To: Shi Xiaoyan Message-ID: Thread-Topic: [MEXT] IPv4 home address option in DSMIP Thread-Index: Acl4e/1gnce/8wg+TyC7IjHZuRMuKQANY/OkAEesPfAAF25TZwArr7WQAIoxv7AAAwMLJQ== In-Reply-To: <00d801c97d0b$b3f61150$bd946f0a@china.huawei.com> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] IPv4 home address option in DSMIP X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 23/01/09 2:35 PM, "Shi Xiaoyan" wrote: > Hi Hesham, > > HA doesn't replace the BCE such as remove the old BCE and creat a new one > when recieved BU. > HA just update the option in BCE also included in BU and others option in > BCE remain valid. > > Such as draft-ietf-monami6-multiplecoa-11, When multiple Binding Identifier > mobility options are present in the Binding Update, it is treated as bulk > registration. But not all BCE should be removed. Only when 'O' flag is set, > HA remove all old BCE. => We've discussed this specific point for the MCoA draft and for flow binding. Ryuji explicitly stated that they did modify the semantics of the BU for that draft. Please review those exchanges to see the details. I don't see the need for doing what you suggested below because it adds ambiguity and the benfits are minimal. Given this late stage I'm not in favour of making further optimisations. No one else seems to express opinions on this so my preference is to leave it as it is. Hesham > > Regards, > Xiaoyan > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Shi Xiaoyan >> Sent: Tuesday, January 20, 2009 6:06 PM >> To: 'Hesham Soliman' >> Cc: mext@ietf.org >> Subject: Re: [MEXT] IPv4 home address option in DSMIP >> >> >> >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Monday, January 19, 2009 8:04 PM >>> To: Shi Xiaoyan >>> Cc: mext@ietf.org >>> Subject: Re: IPv4 home address option in DSMIP >> >>>> 1. BU without IPv4 home address option works well for extending >>>> lifetime. I can't understand what you said "how a BU >>> works". Is there >>>> any Specification to require that BU for exending >> lifetime must be >>>> consistent with BU for first register? Is there any special >>> effect? In >>>> fact, with more and more extension for BU in future, the >>> requirement >>>> that BU for exending lifetime must be consistent with BU >>> for first register will cause unnecessary load. >>> >>> => Yes I know that will use more bandwidth but I don't >> understand what >>> you're objecting to. Implementations copy the contents of >> the new BU >>> into the BC to replace the old entry, as specified in 3775. >> So a new >>> BU overwrites the old one unless you desgin a new option >> per extension >>> that tells the receiver to only refresh. >>> >> >> In my opinion, re-registration BU should not include the IPv4 >> HAO. Because re-registration BU with IPv4 HAO 1. Need more bandwidth. >> 2. Cause extra load on HA. Because HA must verify if the >> address in IPv4 HAO match that in BCE in order to avoid MN >> use a unauthorized IPv4 address. >> >> In fact, since "the home agent MUST be able to find the IPv4 >> home address of a mobile node when given the IPv6 home >> address", section 5.5, why IPv4 HAO must be include in >> re-registration BU? I can't find any benefit. >> >> I didn't find the description in 3775 for "a new BU >> overwrites the old one". >> It should be implementation issue. >> It also could be done as that attributes in BCE also include >> in re-registration BU should be overwriten and other >> attribute not included in re-registration BU should remain valid. >> >> De-registration for IPv4 HoA can be done by adding a bit in >> IPv4 HAO option for indicating de-registration, or any other >> ways. It is all ok. >> I just think it is unnecessary that re-registration BU >> include the IPv4 HAO. >> :-) >> >> >> >>>> >>>> 2. We can find many other ways to delete the IPv4 binding >> if it is >>>> consensus that re-registration BU does not have to >> include the IPv4 >>>> HAO. It could not be a resason for re-registration BU must >>> including IPv4 HAO. >>> >>> => Well, that's the reason now, if you have better ideas, >> other than >>> designing a new option per extension please send them to the list. >>> This is already a bit late given that I'm making the last >> update for >>> IESG comments. >>> >>> Hesham >>> >>>> >>>>> >>>>> Hesham >>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> Xiaoyan >>>>> >>>> >>>> Regards, >>>> Xiaoyan >>>> >>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jan 23 08:28:04 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73BD93A6ABF; Fri, 23 Jan 2009 08:28:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A52A3A68E1 for ; Fri, 23 Jan 2009 08:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.673 X-Spam-Level: X-Spam-Status: No, score=-105.673 tagged_above=-999 required=5 tests=[AWL=0.926, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AakvIkDmYOQx for ; Fri, 23 Jan 2009 08:27:55 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B34063A6AC5 for ; Fri, 23 Jan 2009 08:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1232728059; x=1264264059; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Hesham=20Soliman=20,=0D =0A=20=20=20=20=20=20=20=20Shi=20Xiaoyan=0D=0A=09|CC:=20"mext@ietf.org"=20 |Date:=20Fri,=2023=20Jan=202009=2008:27:34=20-0800 |Subject:=20RE:=20[MEXT]=20IPv4=20home=20address=20option =20in=20DSMIP|Thread-Topic:=20[MEXT]=20IPv4=20home=20addr ess=20option=20in=20DSMIP|Thread-Index:=20Acl4e/1gnce/8wg +TyC7IjHZuRMuKQANY/OkAEesPfAAF25TZwArr7WQAIoxv7AAAwMLJQAZ evyQ|Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3DBE30 037@NASANEXMB08.na.qualcomm.com>|References:=20<00d801c97 d0b$b3f61150$bd946f0a@china.huawei.com>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5503"=3B=20a=3D"14913559"; bh=3JFMU1mlYvOnQDFGL5ndQSAgjjhgLWByhyzATALsfKQ=; b=F42zWrQ3TPxQbPTBHJwHel9KuAlTWPTpU2ccG0DsBFEatdATNvW6/fWa uMlh1WCEnId2BEJAqzjMnJW5OUmqDru/x2wDbCVlprojXzulWDOcEvSOO 8D4RchRPElwqg6O11geG89z3HxVxuO+ZjD0hxSOCem+2c3lbARCuREfmk Q=; X-IronPort-AV: E=McAfee;i="5300,2777,5503"; a="14913559" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jan 2009 08:27:39 -0800 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0NGRcBA006357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 23 Jan 2009 08:27:38 -0800 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0NGRZtA010188 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 23 Jan 2009 08:27:38 -0800 (PST) Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Fri, 23 Jan 2009 08:27:35 -0800 From: "Giaretta, Gerardo" To: Hesham Soliman , Shi Xiaoyan Date: Fri, 23 Jan 2009 08:27:34 -0800 Thread-Topic: [MEXT] IPv4 home address option in DSMIP Thread-Index: Acl4e/1gnce/8wg+TyC7IjHZuRMuKQANY/OkAEesPfAAF25TZwArr7WQAIoxv7AAAwMLJQAZevyQ Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3DBE30037@NASANEXMB08.na.qualcomm.com> References: <00d801c97d0b$b3f61150$bd946f0a@china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] IPv4 home address option in DSMIP X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I agree with Hesham on this. Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Hesham > Soliman > Sent: Thursday, January 22, 2009 8:18 PM > To: Shi Xiaoyan > Cc: mext@ietf.org > Subject: Re: [MEXT] IPv4 home address option in DSMIP > > > > > On 23/01/09 2:35 PM, "Shi Xiaoyan" wrote: > > > Hi Hesham, > > > > HA doesn't replace the BCE such as remove the old BCE and creat a new one > > when recieved BU. > > HA just update the option in BCE also included in BU and others option in > > BCE remain valid. > > > > Such as draft-ietf-monami6-multiplecoa-11, When multiple Binding Identifier > > mobility options are present in the Binding Update, it is treated as bulk > > registration. But not all BCE should be removed. Only when 'O' flag is set, > > HA remove all old BCE. > > => We've discussed this specific point for the MCoA draft and for flow > binding. Ryuji explicitly stated that they did modify the semantics of the > BU for that draft. Please review those exchanges to see the details. > > I don't see the need for doing what you suggested below because it adds > ambiguity and the benfits are minimal. Given this late stage I'm not in > favour of making further optimisations. No one else seems to express > opinions on this so my preference is to leave it as it is. > > > Hesham > > > > > Regards, > > Xiaoyan > > > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >> Behalf Of Shi Xiaoyan > >> Sent: Tuesday, January 20, 2009 6:06 PM > >> To: 'Hesham Soliman' > >> Cc: mext@ietf.org > >> Subject: Re: [MEXT] IPv4 home address option in DSMIP > >> > >> > >> > >>> -----Original Message----- > >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] > >>> Sent: Monday, January 19, 2009 8:04 PM > >>> To: Shi Xiaoyan > >>> Cc: mext@ietf.org > >>> Subject: Re: IPv4 home address option in DSMIP > >> > >>>> 1. BU without IPv4 home address option works well for extending > >>>> lifetime. I can't understand what you said "how a BU > >>> works". Is there > >>>> any Specification to require that BU for exending > >> lifetime must be > >>>> consistent with BU for first register? Is there any special > >>> effect? In > >>>> fact, with more and more extension for BU in future, the > >>> requirement > >>>> that BU for exending lifetime must be consistent with BU > >>> for first register will cause unnecessary load. > >>> > >>> => Yes I know that will use more bandwidth but I don't > >> understand what > >>> you're objecting to. Implementations copy the contents of > >> the new BU > >>> into the BC to replace the old entry, as specified in 3775. > >> So a new > >>> BU overwrites the old one unless you desgin a new option > >> per extension > >>> that tells the receiver to only refresh. > >>> > >> > >> In my opinion, re-registration BU should not include the IPv4 > >> HAO. Because re-registration BU with IPv4 HAO 1. Need more bandwidth. > >> 2. Cause extra load on HA. Because HA must verify if the > >> address in IPv4 HAO match that in BCE in order to avoid MN > >> use a unauthorized IPv4 address. > >> > >> In fact, since "the home agent MUST be able to find the IPv4 > >> home address of a mobile node when given the IPv6 home > >> address", section 5.5, why IPv4 HAO must be include in > >> re-registration BU? I can't find any benefit. > >> > >> I didn't find the description in 3775 for "a new BU > >> overwrites the old one". > >> It should be implementation issue. > >> It also could be done as that attributes in BCE also include > >> in re-registration BU should be overwriten and other > >> attribute not included in re-registration BU should remain valid. > >> > >> De-registration for IPv4 HoA can be done by adding a bit in > >> IPv4 HAO option for indicating de-registration, or any other > >> ways. It is all ok. > >> I just think it is unnecessary that re-registration BU > >> include the IPv4 HAO. > >> :-) > >> > >> > >> > >>>> > >>>> 2. We can find many other ways to delete the IPv4 binding > >> if it is > >>>> consensus that re-registration BU does not have to > >> include the IPv4 > >>>> HAO. It could not be a resason for re-registration BU must > >>> including IPv4 HAO. > >>> > >>> => Well, that's the reason now, if you have better ideas, > >> other than > >>> designing a new option per extension please send them to the list. > >>> This is already a bit late given that I'm making the last > >> update for > >>> IESG comments. > >>> > >>> Hesham > >>> > >>>> > >>>>> > >>>>> Hesham > >>>>> > >>>>>> > >>>>>> > >>>>>> Regards, > >>>>>> Xiaoyan > >>>>> > >>>> > >>>> Regards, > >>>> Xiaoyan > >>>> > >>> > >>> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jan 23 17:02:18 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB953A691B; Fri, 23 Jan 2009 17:02:18 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17C83A691B for ; Fri, 23 Jan 2009 17:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[AWL=1.302, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lf+msMft3wI3 for ; Fri, 23 Jan 2009 17:02:15 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2099C3A67F3 for ; Fri, 23 Jan 2009 17:02:09 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDY006ZYAV277@szxga03-in.huawei.com> for mext@ietf.org; Sat, 24 Jan 2009 09:01:50 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDY00DQGAV2GJ@szxga03-in.huawei.com> for mext@ietf.org; Sat, 24 Jan 2009 09:01:50 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDY00E24AUY5P@szxml06-in.huawei.com> for mext@ietf.org; Sat, 24 Jan 2009 09:01:50 +0800 (CST) Date: Sat, 24 Jan 2009 09:01:46 +0800 From: Yungui Wang To: "Giaretta, Gerardo" , Hesham Soliman , Shi Xiaoyan Message-id: <003e01c97dbf$566847b0$150ca40a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <00d801c97d0b$b3f61150$bd946f0a@china.huawei.com> <057632CE4CE10D45A1A3D6D19206C3A3DBE30037@NASANEXMB08.na.qualcomm.com> Cc: mext@ietf.org Subject: Re: [MEXT] IPv4 home address option in DSMIP X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1233154669==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1233154669== Content-type: multipart/alternative; boundary="Boundary_(ID_4VrtcZpdnQs+oXXM4wjmNA)" This is a multi-part message in MIME format. --Boundary_(ID_4VrtcZpdnQs+oXXM4wjmNA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Maybe rfc3775bisxxx need state the explicit action of HA 'how to do when a mobility option is (not) carried within the lifetime extension re-registration (BU)'. Then, new MO in the subsequent draft could make consistent. B.R. Yungui ----- Original Message ----- From: Giaretta, Gerardo To: Hesham Soliman ; Shi Xiaoyan Cc: mext@ietf.org Sent: Saturday, January 24, 2009 12:27 AM Subject: Re: [MEXT] IPv4 home address option in DSMIP I agree with Hesham on this. Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Hesham > Soliman > Sent: Thursday, January 22, 2009 8:18 PM > To: Shi Xiaoyan > Cc: mext@ietf.org > Subject: Re: [MEXT] IPv4 home address option in DSMIP > > > > > On 23/01/09 2:35 PM, "Shi Xiaoyan" wrote: > > > Hi Hesham, > > > > HA doesn't replace the BCE such as remove the old BCE and creat a new one > > when recieved BU. > > HA just update the option in BCE also included in BU and others option in > > BCE remain valid. > > > > Such as draft-ietf-monami6-multiplecoa-11, When multiple Binding Identifier > > mobility options are present in the Binding Update, it is treated as bulk > > registration. But not all BCE should be removed. Only when 'O' flag is set, > > HA remove all old BCE. > > => We've discussed this specific point for the MCoA draft and for flow > binding. Ryuji explicitly stated that they did modify the semantics of the > BU for that draft. Please review those exchanges to see the details. > > I don't see the need for doing what you suggested below because it adds > ambiguity and the benfits are minimal. Given this late stage I'm not in > favour of making further optimisations. No one else seems to express > opinions on this so my preference is to leave it as it is. > > > Hesham > > > > > Regards, > > Xiaoyan > > > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >> Behalf Of Shi Xiaoyan > >> Sent: Tuesday, January 20, 2009 6:06 PM > >> To: 'Hesham Soliman' > >> Cc: mext@ietf.org > >> Subject: Re: [MEXT] IPv4 home address option in DSMIP > >> > >> > >> > >>> -----Original Message----- > >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] > >>> Sent: Monday, January 19, 2009 8:04 PM > >>> To: Shi Xiaoyan > >>> Cc: mext@ietf.org > >>> Subject: Re: IPv4 home address option in DSMIP > >> > >>>> 1. BU without IPv4 home address option works well for extending > >>>> lifetime. I can't understand what you said "how a BU > >>> works". Is there > >>>> any Specification to require that BU for exending > >> lifetime must be > >>>> consistent with BU for first register? Is there any special > >>> effect? In > >>>> fact, with more and more extension for BU in future, the > >>> requirement > >>>> that BU for exending lifetime must be consistent with BU > >>> for first register will cause unnecessary load. > >>> > >>> => Yes I know that will use more bandwidth but I don't > >> understand what > >>> you're objecting to. Implementations copy the contents of > >> the new BU > >>> into the BC to replace the old entry, as specified in 3775. > >> So a new > >>> BU overwrites the old one unless you desgin a new option > >> per extension > >>> that tells the receiver to only refresh. > >>> > >> > >> In my opinion, re-registration BU should not include the IPv4 > >> HAO. Because re-registration BU with IPv4 HAO 1. Need more bandwidth. > >> 2. Cause extra load on HA. Because HA must verify if the > >> address in IPv4 HAO match that in BCE in order to avoid MN > >> use a unauthorized IPv4 address. > >> > >> In fact, since "the home agent MUST be able to find the IPv4 > >> home address of a mobile node when given the IPv6 home > >> address", section 5.5, why IPv4 HAO must be include in > >> re-registration BU? I can't find any benefit. > >> > >> I didn't find the description in 3775 for "a new BU > >> overwrites the old one". > >> It should be implementation issue. > >> It also could be done as that attributes in BCE also include > >> in re-registration BU should be overwriten and other > >> attribute not included in re-registration BU should remain valid. > >> > >> De-registration for IPv4 HoA can be done by adding a bit in > >> IPv4 HAO option for indicating de-registration, or any other > >> ways. It is all ok. > >> I just think it is unnecessary that re-registration BU > >> include the IPv4 HAO. > >> :-) > >> > >> > >> > >>>> > >>>> 2. We can find many other ways to delete the IPv4 binding > >> if it is > >>>> consensus that re-registration BU does not have to > >> include the IPv4 > >>>> HAO. It could not be a resason for re-registration BU must > >>> including IPv4 HAO. > >>> > >>> => Well, that's the reason now, if you have better ideas, > >> other than > >>> designing a new option per extension please send them to the list. > >>> This is already a bit late given that I'm making the last > >> update for > >>> IESG comments. > >>> > >>> Hesham > >>> > >>>> > >>>>> > >>>>> Hesham > >>>>> > >>>>>> > >>>>>> > >>>>>> Regards, > >>>>>> Xiaoyan > >>>>> > >>>> > >>>> Regards, > >>>> Xiaoyan > >>>> > >>> > >>> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --Boundary_(ID_4VrtcZpdnQs+oXXM4wjmNA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Maybe rfc3775bisxxx need state the explicit action of HA 'how to do when a mobility option is (not) carried within the lifetime extension re-registration (BU)'. Then, new MO in the subsequent draft could make consistent.
 
B.R.
Yungui
 
----- Original Message -----
Sent: Saturday, January 24, 2009 12:27 AM
Subject: Re: [MEXT] IPv4 home address option in DSMIP

I agree with Hesham on this.

Gerardo

> -----Original Message-----
> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Hesham
> Soliman
> Sent: Thursday, January 22, 2009 8:18 PM
> To: Shi Xiaoyan
> Cc: mext@ietf.org
> Subject: Re: [MEXT] IPv4 home address option in DSMIP
>
>
>
>
> On 23/01/09 2:35 PM, "Shi Xiaoyan" <shi_xyan@huawei.com> wrote:
>
> > Hi Hesham,
> >
> > HA doesn't replace the BCE such as remove the old BCE and creat a new one
> > when recieved BU.
> > HA just update the option in BCE also included in BU and others option in
> > BCE remain valid.
> >
> > Such as draft-ietf-monami6-multiplecoa-11,  When multiple Binding Identifier
> > mobility options are present in the Binding Update, it is treated as bulk
> > registration. But not all BCE should be removed. Only when 'O' flag is set,
> > HA remove all old BCE.
>
> => We've discussed this specific point for the MCoA draft and for flow
> binding. Ryuji explicitly stated that they did modify the semantics of the
> BU for that draft. Please review those exchanges to see the details.
>
> I don't see the need for doing what you suggested below because it adds
> ambiguity and the benfits are minimal. Given this late stage I'm not in
> favour of making further optimisations. No one else seems to express
> opinions on this so my preference is to leave it as it is.
>
>
> Hesham
>
> >
> > Regards,
> > Xiaoyan
> >
> >
> >> -----Original Message-----
> >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On
> >> Behalf Of Shi Xiaoyan
> >> Sent: Tuesday, January 20, 2009 6:06 PM
> >> To: 'Hesham Soliman'
> >> Cc: mext@ietf.org
> >> Subject: Re: [MEXT] IPv4 home address option in DSMIP
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com]
> >>> Sent: Monday, January 19, 2009 8:04 PM
> >>> To: Shi Xiaoyan
> >>> Cc: mext@ietf.org
> >>> Subject: Re: IPv4 home address option in DSMIP
> >>
> >>>> 1. BU without IPv4 home address option works well for extending
> >>>> lifetime. I can't understand what you said "how a BU
> >>> works". Is there
> >>>> any Specification to require that BU for exending
> >> lifetime  must be
> >>>> consistent with BU for first register? Is there any special
> >>> effect? In
> >>>> fact, with more and more extension for BU in future, the
> >>> requirement
> >>>> that BU for exending lifetime must be consistent with BU
> >>> for first register will cause unnecessary load.
> >>>
> >>> => Yes I know that will use more bandwidth but I don't
> >> understand what
> >>> you're objecting to. Implementations copy the contents of
> >> the new BU
> >>> into the BC to replace the old entry, as specified in 3775.
> >> So a new
> >>> BU overwrites the old one unless you desgin a new option
> >> per extension
> >>> that tells the receiver to only refresh.
> >>>
> >>
> >> In my opinion, re-registration BU should not include the IPv4
> >> HAO. Because re-registration BU with IPv4 HAO 1. Need more bandwidth.
> >> 2. Cause extra load on HA. Because HA must verify if  the
> >> address in IPv4 HAO match that in BCE in order to avoid MN
> >> use a unauthorized IPv4 address.
> >>
> >> In fact, since "the home agent MUST be able to find the IPv4
> >> home address of a mobile node when given the IPv6 home
> >> address", section 5.5, why IPv4 HAO must be include in
> >> re-registration BU? I can't find any benefit.
> >>
> >> I didn't find the description in 3775 for "a new BU
> >> overwrites the old one".
> >> It should be implementation issue.
> >> It also could be done as that attributes in BCE also include
> >> in re-registration BU should be overwriten and other
> >> attribute not included in re-registration BU should remain valid.
> >>
> >> De-registration for IPv4 HoA can be done by adding a bit in
> >> IPv4 HAO option for indicating de-registration, or any other
> >> ways. It is all ok.
> >> I just think it is unnecessary that re-registration BU
> >> include the IPv4 HAO.
> >> :-)
> >>
> >>
> >>
> >>>>
> >>>> 2. We can find many other ways to delete the IPv4 binding
> >> if it is
> >>>> consensus that re-registration BU does not have to
> >> include the IPv4
> >>>> HAO. It could not be a resason for re-registration BU must
> >>> including IPv4 HAO.
> >>>
> >>> => Well, that's the reason now, if you have better ideas,
> >> other than
> >>> designing a new option per extension please send them to the list.
> >>> This is already a bit late given that I'm making the last
> >> update for
> >>> IESG comments.
> >>>
> >>> Hesham
> >>>
> >>>>
> >>>>>
> >>>>> Hesham
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> Regards,
> >>>>>> Xiaoyan
> >>>>>
> >>>>
> >>>> Regards,
> >>>> Xiaoyan
> >>>>
> >>>
> >>>
> >>
> >> _______________________________________________
> >> MEXT mailing list
> >> MEXT@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mext
> >
>
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--Boundary_(ID_4VrtcZpdnQs+oXXM4wjmNA)-- --===============1233154669== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1233154669==-- From mext-bounces@ietf.org Tue Jan 27 05:45:01 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4BE93A6B64; Tue, 27 Jan 2009 05:45:01 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 64F4E3A6B64; Tue, 27 Jan 2009 05:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090127134501.64F4E3A6B64@core3.amsl.com> Date: Tue, 27 Jan 2009 05:45:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-mib-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : NEMO Management Information Base Author(s) : S. Gundavelli, et al. Filename : draft-ietf-mext-nemo-mib-05.txt Pages : 44 Date : 2009-01-27 This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a Mobile IPv6 node with NEMO functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-nemo-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-27053745.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Tue Jan 27 08:26:02 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D75413A6986; Tue, 27 Jan 2009 08:26:02 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2ACB3A68D2 for ; Tue, 27 Jan 2009 08:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.667 X-Spam-Level: X-Spam-Status: No, score=-6.667 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDqjvj+0v1SQ for ; Tue, 27 Jan 2009 08:26:00 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A0CB83A6A6F for ; Tue, 27 Jan 2009 08:25:58 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0RGP7cN004669; Tue, 27 Jan 2009 18:25:30 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jan 2009 18:25:25 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jan 2009 18:25:25 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 27 Jan 2009 17:25:24 +0100 From: To: , Date: Tue, 27 Jan 2009 17:25:20 +0100 Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl7mE19JXO/cThEQ4aahXGrrIMCUgFAmgwg Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E77FFF67@NOK-EUMSG-01.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2009 16:25:25.0020 (UTC) FILETIME=[DBA6D5C0:01C9809B] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Sri Gundavelli wrote: > May be Pasi/IESG can clarify on this. As I understood, he was more > concerned on the lack of specification on the GRE tunneling > mechanism and not specific to TLV related header, there is not much > to specify there. I believe moving all TLV header text to some other document would get draft-ietf-mext-nemo-v4traversal published much faster. This discussion thread has already revealed that the TLV format probably isn't quite right. (For example, according to the current text, the "Type" field has only two possible values (0 and 1 -- not much room for future extensibility!), and the length field isn't actually used for anything.) Also, the 'T' bit in BU seems redundant, since neither MN nor HA actually uses the value for anything in this specification. I'm not objecting to keeping the TLV format in this document if the issues are fixed, but would recommend taking small steps: get nemo-v4traversal spec published first, and figure out TLV format details when they're actually needed (in current nemo-v4traversal spec, neither MN nor HA actually ever sends any TLV format packets). Best regards, Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jan 27 23:13:24 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E32F3A69DC; Tue, 27 Jan 2009 23:13:24 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE09B28C0D8 for ; Tue, 27 Jan 2009 23:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.656 X-Spam-Level: ** X-Spam-Status: No, score=2.656 tagged_above=-999 required=5 tests=[AWL=-2.374, BAYES_20=-0.74, FRT_MEETING=2.697, HELO_MISMATCH_INFO=1.448, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMg1gadH+fAJ for ; Tue, 27 Jan 2009 23:13:22 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id E8D3D3A677D for ; Tue, 27 Jan 2009 23:13:21 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Wed, 28 Jan 2009 16:13:04 +0900 X-ReadCheckName: mext%40ietf.org X-ReadCheckMessageID: <690babcf-ce71-4949-a2af-e87125372036@etri.re.kr> From: "Hong Yong-Geun" To: , Date: Wed, 28 Jan 2009 16:13:04 +0900 Priority: normal Comment: ??, u-??, thread-index: AcmBF9xvrP3fCPyJS+i9Y9I2UeUbzQAAAA5B Message-ID: <931c01c98117$dcadd320$8310fe81@etri.info> X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple interfaces problems in MEXT and mif X-OriginalArrivalTime: 28 Jan 2009 07:13:04.0541 (UTC) FILETIME=[DCCCCCD0:01C98117] Cc: julien.laganier.IETF@googlemail.com Subject: [MEXT] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1654058890==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1654058890== Content-Class: urn:content-classes:message Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98114.CAF6F100" This is a multi-part message in MIME format. ------_=_NextPart_001_01C98114.CAF6F100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ------_=_NextPart_001_01C98114.CAF6F100 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj4NCjxESVY+DQo8UCBkaXI9bHRyIGFsaWduPWp1c3RpZnk+PFNQQU4gbGFuZz1l bi11cz48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+SGksIGFsbCBpbjwvRk9OVD48 L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0y Pk1FWFQ8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPiBhbmQgbWlmLjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgZGlyPWx0ciBhbGln bj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PC9G T05UPjwvU1BBTj4mbmJzcDs8L1A+DQo8UCBkaXI9bHRyIGFsaWduPWp1c3RpZnk+PFNQQU4gbGFu Zz1lbi11cz48L1NQQU4+PC9QPg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9 ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPkluIElFVEYgbWlmPC9GT05U PjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9 Mj4gKE11bHRpcGxlIEludGVyZmFjZSk8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZP TlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1l bi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPm1haWxpbmc8L0ZPTlQ+PC9T UEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPjwv Rk9OVD4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmxpc3Q8L0ZPTlQ+PC9TUEFO PjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPiAoPC9G T05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48QSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZiIgdGFyZ2V0PV9ibGFuaz48U1BBTiBsYW5nPWVu LXVzPjxVPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYTwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SV IiBjb2xvcj0jMDAwMGZmIHNpemU9Mj5uL2xpc3RpbmZvL21pZjwvRk9OVD48L1U+PC9TUEFOPjxT UEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjwvQT48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9Iuun keydgCDqs6DrlJUiIHNpemU9Mj4pLCA8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIgYWxp Z249anVzdGlmeT48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNp emU9Mj53PC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5lPC9GT05UPiA8 Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+bm93PC9GT05UPiA8Rk9OVCBmYWNlPSLr p5HsnYAg6rOg65SVIiBzaXplPTI+ZDwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBz aXplPTI+aXNjdXNzIHRoZSBob3N0IHdoaWNoPC9GT05UPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg 65SVIiBzaXplPTI+d291bGQgbGlrZSB0byB1c2UgbXVsdGlwbGUgaW50ZXJmYWNlczwvRk9OVD48 L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBzaXplPTI+LjwvRk9OVD48L1NQQU4+PC9QPg0K PFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR 7J2AIOqzoOuUlSIgc2l6ZT0yPkkgdW5kZXJzdGFuZCB0aGF0PC9GT05UPjwvU1BBTj48U1BBTiBs YW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+TUVYVDwvRk9OVD48 L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ IFdHIGlzIGFsc28gcmVsYXRlZCB0bzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZP TlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPnRoZSB1c2Ugb2Y8L0ZPTlQ+PC9TUEFOPjxT UEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5tdWx0aXBs ZSBpbnRlcmZhY2VzPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9Iuun keydgCDqs6DrlJUiIHNpemU9Mj4gb2YgYSBob3N0PC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVu LXVzPjxCUj48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+dXNpbmcgTW9iaWxlIElQ djYgb3IgYSBtb2JpbGUgcm91dGVyIHVzaW5nIE5FTU88L0ZPTlQ+IDxGT05UIGZhY2U9Iuunkeyd gCDqs6DrlJUiIHNpemU9Mj5CYXNpYyBTdXBwb3J0IGFuZCB0aGVpciB2YXJpYW50czwvRk9OVD48 L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PC9QPg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0 aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9a28ta3I+PC9TUEFOPjxBIHRh cmdldD1fYmxhbmsgbmFtZT0iIj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDq s6DrlJUiIHNpemU9Mj5NRVhUPC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9 Mj4gV0cgaXMgZm9jdWluZyBvbiBtb25hbWk2PC9GT05UPjwvU1BBTj48L0E+PFNQQU4gbGFuZz1l bi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBz aXplPTI+IHJlbGF0ZWQgdG9waWM8L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6 ZT0yPiAobXVsdGlwbGUgQ29BLCBNdWx0aXBsZSBIb0EsIGFuZCBNdWx0cGxlIEhBLCBldGMuLDwv Rk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+KTwvRk9OVD48L1NQQU4+PFNQ QU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNlPSLrp5HsnYAg 6rOg65SVIiBzaXplPTI+PC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BB TiBsYW5nPWtvLWtyPjxCUj48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFu Zz1rby1rcj48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+YW5kIGV4dGVkbmluZyBN b2JpbGUgSVB2NiBhbmQgTkVNTzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+ PFNQQU4gbGFuZz1rby1rcj4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmZvciB0 aGVzZSw8L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPjwvRk9OVD48L1NQ QU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj4gPEZPTlQgZmFjZT0i 66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmJ1dDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48 L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ PC9GT05UPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+bWlmIGlzPC9GT05UPjwv U1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPiA8Rk9OVCBmYWNl PSLrp5HsnYAg6rOg65SVIiBzaXplPTI+bm90IHJlbGF0ZWQgdG8gdGhpcyBkaXJlY3Q8L0ZPTlQ+ PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmlvbi48L0ZPTlQ+PC9TUEFOPjxTUEFO IGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9a28ta3I+PEJSPjwvU1BBTj48U1BBTiBsYW5n PWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUi IHNpemU9Mj5JbiBtaWY8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFO IGxhbmc9a28ta3I+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPiwgc291cmNlIGFk ZHJlc3Mgc2VsZWN0aW9uLDwvRk9OVD4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0y PnI8L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPm91dGluZzwvRk9OVD4g PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmFuZCBETlMgY29udHJvbCBwcm90b2Nv bDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48 Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05UPiA8Rk9OVCBmYWNlPSLrp5Hs nYAg6rOg65SVIiBzaXplPTI+YXJlPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BB Tj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj48L0ZP TlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9a28ta3I+IDxGT05U IGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5jb25zaWRlcmF0aW9uIGl0ZW1zPC9GT05UPjwv U1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxCUj48L1NQQU4+ PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNlPSLrp5Hs nYAg6rOg65SVIiBzaXplPTI+ZHVlIHRvIG11bHRpcGxlIGludGVyZmFjZXMgb2YgYSBob3N0LiA8 L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBsYW5nPWtv LWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9QPg0K PFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxh bmc9a28ta3I+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBsYW5n PWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUi IHNpemU9Mj5Gb3I8L0ZPTlQ+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5taWY8 L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9a28ta3I+PEZP TlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPuKAmTwvRk9OVD48L1NQQU4+PFNQQU4gbGFu Zz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SV IiBzaXplPTI+cyBzY29wZSwgSmFyaSBBcmtrbzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11 cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6 ZT0yPm1hZGU8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9 a28ta3I+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5zb21lIGNvbW1lbnRzIGFu ZCBjbGFzc2k8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9 a28ta3I+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmZpY2F0aW9uIG9mIHByb2Js ZW1zLiA8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBs YW5nPWVuLXVzPjwvU1BBTj48QSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbWlmL2N1cnJlbnQvbXNnMDAwNTAuaHRtbCIgdGFyZ2V0PV9ibGFuaz48U1BBTiBsYW5n PWVuLXVzPjxVPjwvVT48L1NQQU4+PFU+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNlPSLrp5Hs nYAg6rOg65SVIiBjb2xvcj0jMDAwMGZmIHNpemU9Mj5odHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvbWlmL2N1cnJlbnQvbXNnMDAwNTAuaHRtbDwvRk9OVD48L1NQQU4+PC9VPjxT UEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjwvQT48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBs YW5nPWtvLWtyPjwvU1BBTj48L1A+DQo8UCBkaXI9bHRyIGFsaWduPWp1c3RpZnk+PFNQQU4gbGFu Zz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SV IiBzaXplPTI+QW1vbmcgdGhlc2UgY2xhc3NpZmljYXRpb24gd2hpY2ggaW5jbHVkZXM8L0ZPTlQ+ IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5hY2Nlc3Mgc2VsZWN0aW9uLCBzcGxp dCBETlMsPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtv LWtyPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+Y29uZmlndXJhdGlvbiByZWNv bmNpbGlhdGlvbiw8QlI+PC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5y b3V0aW5nLCBhZGRyZXNzIHNlbGVjdGlvbiwgdHVubmVsIG11bHRpaG9taW5nLDwvRk9OVD48L1NQ QU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj4gPEZPTlQgZmFjZT0i 66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmFuZCB0aGU8L0ZPTlQ+IDxGT05UIGZhY2U9IuunkeydgCDq s6DrlJUiIHNpemU9Mj5jb21tdW5pY2F0aW9uIHdheSBiZXR3ZWVuIHRoZSBob3N0IGFuZDxCUj48 L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPnRoZSBuZXR3b3JrIGFib3V0 IHRoZWlyIHBvbGljaWVzIHJlZ2FyZGluZyBhbGwgb2YgdGhlIGFib3ZlPC9GT05UPjwvU1BBTj48 U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9Iuunkeyd gCDqs6DrlJUiIHNpemU9Mj4sPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48 U1BBTiBsYW5nPWtvLWtyPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+SmFyaSBz YWlkIHRoYXQ8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9 a28ta3I+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5hY2Nlc3Mgc2VsZWN0aW9u IGlzIGFscmVhZHk8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxh bmc9a28ta3I+PEJSPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtv LWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5jb3ZlcmQgaW4gUkZDIDUxMTM8 L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9a28ta3I+PEZP TlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1l bi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIg c2l6ZT0yPmFuZDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFu Zz1rby1rcj4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPnR1bm5lbCBtdWx0aWhv bWluZzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1r cj4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmlzIGFscmVhZHkgY292ZXJlZCBp bjwvRk9OVD4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPk1FWFQgV0cgd29yayBp dGVtcy48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBs YW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiPjwvRk9OVD48L1NQQU4+PFNQQU4g bGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48L1NQQU4+Jm5ic3A7PC9QPg0KPFAg ZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9 a28ta3I+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBsYW5nPWVu LXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNp emU9Mj5BdCBtb25hbWk2IFdHIGluIDY8L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIg c2l6ZT0yPjR0aDwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05U PiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+SUVURiBtZWV0aW5uZywgSSBzdWJt aXR0ZWQgYW5kIHByZXNlbnRlZCB0d28gSW50ZXJuZXQgRHJhZnRzLjwvRk9OVD48L1NQQU4+PC9Q Pg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFO IGxhbmc9a28ta3I+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPi0gQW5hbHlzaXMg b2YgbXVsdGlwbGUgaW50ZXJmYWNlcyBpbiBhIE1vYmlsZSBOb2RlPC9GT05UPjwvU1BBTj48U1BB TiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDq s6DrlJUiIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFO IGxhbmc9a28ta3I+IDwvU1BBTj48L1A+DQo8UCBkaXI9bHRyIGFsaWduPWp1c3RpZnk+PFNQQU4g bGFuZz1lbi11cz48L1NQQU4+PEEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0 LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1zdGF0ZW1lbnQtMDAudHh0IiB0YXJnZXQ9X2JsYW5rPjxT UEFOIGxhbmc9ZW4tdXM+PFU+PC9VPjwvU1BBTj48VT48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZh Y2U9IuunkeydgCDqs6DrlJUiIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9pZC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAwLnR4dDwvRk9O VD48L1NQQU4+PC9VPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjwvQT48U1BBTiBsYW5nPWVuLXVz PjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjwvU1BBTj48L1A+DQo8UCBkaXI9bHRyIGFsaWduPWp1 c3RpZnk+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNl PSLrp5HsnYAg6rOg65SVIiBzaXplPTI+LSBWaXJ0dWFsIG5ldHdvcmsgaW50ZXJmYWNlIGZvciBt dWx0aXBsZSBpbnRlcmZhY2VzIGluIGEgTW9iaWxlIG5vZGUgdXNpbmcgTW9iaWxlIElQdjY8L0ZP TlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9a28ta3I+PC9TUEFO PjwvUD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48 QSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy12aXJ0dWFsaWYtbW4t bWlwdjYtMDAudHh0IiB0YXJnZXQ9X2JsYW5rPjxTUEFOIGxhbmc9ZW4tdXM+PFU+PC9VPjwvU1BB Tj48VT48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIGNvbG9yPSMw MDAwZmYgc2l6ZT0yPmh0dHA6Ly90b29scy5pZXRmPC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDq s6DrlJUiIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPi5vcmcvaWQvZHJhZnQtaG9uZy12aXJ0dWFsaWYt bW4tbWlwdjYtMDAudHh0PC9GT05UPjwvU1BBTj48L1U+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+ PC9BPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9a28ta3I+PC9TUEFOPjwvUD4N CjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBs YW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5CZWNhdXNlIHRoZXNl IHR3byBkcmFmdHM8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxh bmc9a28ta3I+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj53PC9GT05UPjwvU1BB Tj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9Iuun keydgCDqs6DrlJUiIHNpemU9Mj5lcmU8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9T UEFOPjxTUEFOIGxhbmc9a28ta3I+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPiBu b3Q8L0ZPTlQ+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5pbiB0aGUgbW9uYW1p NiBXRzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1r cj48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+4oCZPC9GT05UPjwvU1BBTj48U1BB TiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDq s6DrlJUiIHNpemU9Mj5zIHNjb3BlIGFuZDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48 L1NQQU4+PFNQQU4gbGFuZz1rby1rcj4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0y PnZpcnR1YWwgbmV0PC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj53PC9G T05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5vcmsgaW50ZXJmYWNlIGRyYWZ0 IHdhczwvRk9OVD48L1NQQU4+PC9QPg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxh bmc9a28ta3I+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmk8L0ZPTlQ+PEZPTlQg ZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPm1wbGVtZW50YXRpb248L0ZPTlQ+IDxGT05UIGZh Y2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5zcGVjaWZpYzwvRk9OVD48Rk9OVCBmYWNlPSLrp5Hs nYAg6rOg65SVIiBzaXplPTI+LCB0aDwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBz aXplPTI+ZXJlIHdlcmUgbm90PC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48 U1BBTiBsYW5nPWtvLWtyPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+YWRvcGVk IGluIG1vbmFtaTYgV0c8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFO IGxhbmc9a28ta3I+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPuKAmTwvRk9OVD48 L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNl PSLrp5HsnYAg6rOg65SVIiBzaXplPTI+cyB3b3JrIGl0ZW1zLjwvRk9OVD48L1NQQU4+PFNQQU4g bGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj4gPEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPlRoZSBpbnRlbnRpb25zIG9mIHR3PC9GT05UPjwvU1BBTj48U1BBTiBsYW5n PWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUi IHNpemU9Mj5vPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5n PWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj4gZHJhZnRzPEJSPjwvRk9O VD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+YXJlPC9GT05UPjwvU1BBTj48U1BB TiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPiA8Rk9OVCBmYWNlPSLrp5HsnYAg 6rOg65SVIiBzaXplPTI+c3VwcG9ydGluZyBtdWx0aXBsZSBpbnRlcmZhY2VzIG9mPC9GT05UPiA8 Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+YSBob3N0IHdpdGhvdXQgZXh0ZW5kaW5n IE1vYmlsZSBJUHY2L05FTU8uPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48 U1BBTiBsYW5nPWtvLWtyPjwvU1BBTj48L1A+DQo8UCBkaXI9bHRyIGFsaWduPWp1c3RpZnk+PFNQ QU4gbGFuZz1lbi11cz48L1NQQU4+PC9QPg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFO IGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPjwvRk9OVD48L1NQ QU4+Jm5ic3A7PC9QPg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+ PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPkkgdGhpbmsgdGhhdDwvRk9OVD48L1NQ QU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPm11 bHRpcGxlIGludGVyZmFjZTwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ czwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuU lSIgc2l6ZT0yPnByb2JsZW1zPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZh Y2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj48L0ZPTlQ+IDxGT05UIGZhY2U9IuunkeydgCDqs6Dr lJUiIHNpemU9Mj5vZiBhIGhvc3Q8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05U IGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5hcmUgcmVsYXRlZCB0byBib3RoPC9GT05UPjwv U1BBTj48U1BBTiBsYW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ TW9iaWxlIElQL05FTU88L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i 66eR7J2AIOqzoOuUlSIgc2l6ZT0yPiBzcGVjaWZpYzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1l bi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmlzc3VlczwvRk9OVD48L1NQ QU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmFu ZDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48QlI+PEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPmdlbmVyYWw8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05U IGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5uZXR3b3JrIGlzc3VlczwvRk9OVD48Rk9OVCBm YWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+LjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11 cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPk1vYmlsZSBJUC9ORU1PPC9GT05U PjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9 Mj4gczwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+cGVjaWZpYyBpc3N1 ZXM8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6Dr lJUiIHNpemU9Mj5hPC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5yPC9G T05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5lPC9GT05UPjxGT05UIGZhY2U9 IuunkeydgCDqs6DrlJUiIHNpemU9Mj48L0ZPTlQ+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUi IHNpemU9Mj5yZWxhdGVkIHRvPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPiA8Rk9OVCBm YWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ZXh0ZW5kaW5nIG9mPC9GT05UPjwvU1BBTj48U1BB TiBsYW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+TW9iaWxlIElQ PC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj4vTkVNTzwvRk9OVD48L1NQ QU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+IGFu ZDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48QlI+PEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPnRoZXNlIGFyZTwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9O VCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVu LXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+YWxyZWFkeTwvRk9OVD4gPEZP TlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPnN0dWRpZWQgaW4gTUVYVCBXRyBhbmQ8L0ZP TlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6 ZT0yPjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPmdlbmVyYWwgbmV0d29yayBpc3N1ZXMgd2hpY2ggd2VyZSBub3QgcmVsYXRl ZCB0bzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48QlI+PEZPTlQgZmFjZT0i66eR7J2A IOqzoOuUlSIgc2l6ZT0yPk1vYmlsZSBJUDwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SV IiBzaXplPTI+L05FTU88L0ZPTlQ+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5j b3VsZDwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+IGJlIHN0dWRpZWQg aW4gbWlmLjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5HsnYAg 6rOg65SVIiBzaXplPTI+IEFzPC9GT05UPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXpl PTI+c2FtZSBtYTwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5Hs nYAg6rOg65SVIiBzaXplPTI+bm5lciw8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxG T05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5JIHRoaW5rIHRoYXQ8L0ZPTlQ+PC9TUEFO PjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5teTwv Rk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05UPiA8Rk9OVCBmYWNl PSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ZHJhZnRzPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVu LXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+YzwvRk9OVD48Rk9OVCBmYWNl PSLrp5HsnYAg6rOg65SVIiBzaXplPTI+b3VsZCBiZSBkaXNjdXNzZWQ8L0ZPTlQ+PC9TUEFOPjxT UEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5hbmQ8QlI+ PC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5kZXZlPC9GT05UPjwvU1BB Tj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5sPC9G T05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNp emU9Mj5vcDwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ZWQ8L0ZPTlQ+ PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9 Mj5pbiBtaWYuPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9Iuunkeyd gCDqs6DrlJUiIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZh Y2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5JPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVz PjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5uPC9GT05UPiA8Rk9OVCBmYWNlPSLr p5HsnYAg6rOg65SVIiBzaXplPTI+dDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9O VCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+aGUgZmlyc3QgZHJhZnQ8L0ZPTlQ+PEZPTlQg ZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPiAoPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVu LXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5BbmFseXNpcyBkb2N1PC9GT05U PjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5tZW50PC9GT05UPjwvU1BBTj48U1BB TiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj4pLDwvRk9OVD48 L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0y Pkk8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6Dr lJUiIHNpemU9Mj5jbGFzc2lmaWU8L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6 ZT0yPmQ8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDq s6DrlJUiIHNpemU9Mj5tdWx0aXBsZTwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9O VCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05UPiA8Rk9OVCBmYWNlPSLrp5HsnYAg 6rOg65SVIiBzaXplPTI+aW48L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0y PnRlcmZhY2U8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9Iuunkeyd gCDqs6DrlJUiIHNpemU9Mj5wcm9ibGVtczwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48 Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05UPiA8Rk9OVCBmYWNlPSLrp5Hs nYAg6rOg65SVIiBzaXplPTI+aW50bzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48QlI+ PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPk1vYmlsZSBJUHY2LXNlcGNpZmljIGlz c3Vlcyw8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i 66eR7J2AIOqzoOuUlSIgc2l6ZT0yPkdlbmVyYWwgbmV0d29yazwvRk9OVD48L1NQQU4+PFNQQU4g bGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmlzc3VlczwvRk9O VD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBzaXplPTI+LDwvRk9OVD48Rk9OVCBmYWNl PSLrp5HsnYAg6rOg65SVIiBzaXplPTI+IGFuZCBoZXRlcm9nZW5lb3VzIGVudmlyb25tZW50PC9G T05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj4gaXNzdWVzPC9GT05UPjxGT05U IGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj4uPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVu LXVzPiA8L1NQQU4+PC9QPg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4t dXM+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBsYW5nPWVuLXVz PjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwv UD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9 IuunkeydgCDqs6DrlJUiIHNpemU9Mj5JbmNsdWRpbmcgSHVpPC9GT05UPiA8Rk9OVCBmYWNlPSLr p5HsnYAg6rOg65SVIiBzaXplPTI+RGVuZzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48 Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+IGluIG1pZjwvRk9OVD48L1NQQU4+PFNQ QU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+LDwvRk9OVD48 L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0y PndpdGg8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDq s6DrlJUiIHNpemU9Mj5yZWdhcmRpbmcgdG88L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+ IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj50aGVzZSBkcmFmdHMsPC9GT05UPjwv U1BBTj48U1BBTiBsYW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ dGhleSB3YW50IHRvPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLr p5HsnYAg6rOg65SVIiBzaXplPTI+aGVhciBjb21tZW50czwvRk9OVD48L1NQQU4+PFNQQU4gbGFu Zz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmY8L0ZPTlQ+PC9TUEFO PjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPnJvbTwv Rk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIg c2l6ZT0yPk1FWDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5Hs nYAg6rOg65SVIiBzaXplPTI+VCBXRzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9O VCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+4oCZPC9GT05UPjwvU1BBTj48U1BBTiBsYW5n PWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5zPC9GT05UPjwvU1BBTj48 U1BBTiBsYW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+cG9pbnQ8 L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIg c2l6ZT0yPjwvRk9OVD4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPm9mIHZpZXc8 L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgc2l6ZT0yPiw8L0ZPTlQ+PC9TUEFO PjxTUEFOIGxhbmc9ZW4tdXM+PEJSPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5i ZWNhdXNlPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg 6rOg65SVIiBzaXplPTI+aXQgc2U8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQg ZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmVtczwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1l bi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPnRoYXQ8L0ZPTlQ+PC9TUEFO PjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPjwvRk9O VD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6 ZT0yPnRoZXNlPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9Iuunkeyd gCDqs6DrlJUiIHNpemU9Mj4gZHI8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQg ZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmFmdHMgYXJlIHF1aXRlIHJlbGF0ZWQgdG8gbW9u YW1pNi9NRVhUIFdHLjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLr p5HsnYAg6rOg65SVIiBzaXplPTI+IFNvLCBJIGFzayBNRVhUPC9GT05UPjwvU1BBTj48U1BBTiBs YW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+dG88L0ZPTlQ+PC9T UEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5y ZXZpZXc8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPiB3aGV0aGVyIHRoZXJlIGFyZTwvRk9OVD48L1NQQU4+PC9QPg0KPFAgZGly PWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPnM8L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPm9t ZTwvRk9OVD4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPm92ZXJsYXA8L0ZPTlQ+ PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9 Mj5iZXR3ZWVuPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9Iuunkeyd gCDqs6DrlJUiIHNpemU9Mj48L0ZPTlQ+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9 Mj5NRVhUPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg 6rOg65SVIiBzaXplPTI+d29yazwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBm YWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+czwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11 cz48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05UPjwvU1BBTj48U1BBTiBs YW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+YW5kIG15IGRyYWZ0 czwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SV IiBzaXplPTI+IG9yIG5vdDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBzaXpl PTI+LjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PC9QPg0KPFAgZGlyPWx0 ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIg YWxpZ249anVzdGlmeT48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUi IHNpemU9Mj5JdCBpczwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i 66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmFwcHJlY2lhdGU8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9 ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPjwvRk9OVD4gPEZPTlQgZmFj ZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPnRvIGdpdmUgY29tbWVudHMuPC9GT05UPjwvU1BBTj48 L1A+DQo8UCBkaXI9bHRyIGFsaWduPWp1c3RpZnk+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNl PSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L1A+DQo8UCBkaXI9 bHRyIGFsaWduPWp1c3RpZnk+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg 65SVIiBzaXplPTI+QmVzdCByZWdhcmRzLjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48 L1NQQU4+PC9QPg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PEZP TlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPllvbmctR2V1bi48L0ZPTlQ+PC9TUEFOPjwv UD48L0RJVj48L0RJVj48L0RJVj48aW1nIHN0eWxlPSJkaXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVp Z2h0PTAgc3JjPSJodHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNw eD9lbWFpbD1tZXh0QGlldGYub3JnJm5hbWU9bWV4dCU0MGlldGYub3JnJmZyb21lbWFpbD15Z2hv bmdAZXRyaS5yZS5rciZtZXNzYWdlaWQ9JTNDNjkwYmFiY2YtY2U3MS00OTQ5LWEyYWYtZTg3MTI1 MzcyMDM2QGV0cmkucmUua3IlM0UiPg== ------_=_NextPart_001_01C98114.CAF6F100-- --===============1654058890== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1654058890==-- From mext-bounces@ietf.org Wed Jan 28 01:40:32 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 926EA28C246; Wed, 28 Jan 2009 01:40:32 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033D428C246; Wed, 28 Jan 2009 01:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, FRT_MEETING=2.697, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9Je3XbLgIDS; Wed, 28 Jan 2009 01:40:31 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id B360D28C120; Wed, 28 Jan 2009 01:40:29 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.145.150]) by smtp01.uc3m.es (Postfix) with ESMTP id 03FE4B4D453; Wed, 28 Jan 2009 10:40:09 +0100 (CET) Message-ID: <498027F9.8050604@it.uc3m.es> Date: Wed, 28 Jan 2009 10:40:09 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Hong Yong-Geun References: <932b01c98117$dcb28e10$8310fe81@etri.info> In-Reply-To: <932b01c98117$dcb28e10$8310fe81@etri.info> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16428.005 Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [MEXT] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org SGksCgpJbiB0aGUgY3VycmVudCBNRVhUIGNoYXJ0ZXIgdGhlcmUgYXJlIHNldmVyYWwgaXRlbXMg YWJvdXQgc3VwcG9ydGluZyAKbXVsdGlwbGUgaW50ZXJmYWNlcywgaW5jbHVkaW5nIHRoZSBmb2xs b3dpbmcgdHdvOgoKLSBBIGRvY3VtZW50IGV4cGxhaW5pbmcgdGhlIG1vdGl2YXRpb25zIGZvciBh IG5vZGUgdXNpbmcgbXVsdGlwbGUKaW50ZXJmYWNlcyBhbmQgdGhlIHNjZW5hcmlvcyB3aGVyZSBp dCBtYXkgZW5kIHVwIHdpdGggbXVsdGlwbGUKZ2xvYmFsIGFkZHJlc3NlcyBvbiBpdHMgaW50ZXJm YWNlcyBbSW5mb3JtYXRpb25hbF0KCi0gQW4gYW5hbHlzaXMgZG9jdW1lbnQgZXhwbGFpbmluZyB3 aGF0IGFyZSB0aGUgbGltaXRhdGlvbnMgZm9yCm1vYmlsZSBob3N0cyB1c2luZyBtdWx0aXBsZSBz aW11bHRhbmVvdXMgQ2FyZS1vZiBBZGRyZXNzZXMgYW5kIEhvbWUKQWdlbnQgYWRkcmVzc2VzIHVz aW5nIE1vYmlsZSBJUHY2LCB3aGV0aGVyIGlzc3VlcyBhcmUgc3BlY2lmaWMgdG8KTW9iaWxlIElQ djYgb3Igbm90IFtJbmZvcm1hdGlvbmFsXS4KCkkgdGhpbmsgdGhpcyBpcyB2ZXJ5IHNpbWlsYXIg dG8gdGhlIHNjb3BlIG9mIG9uZSBvZiB5b3UgZG9jdW1lbnRzIGF0IApsZWFzdCwgc28gaSB3b3Vs ZCBmaW5kIHZlcnkgc3RyYW5nZSB0aGF0IHRoZSBzYW1lIHdvcmsgaXMgY2hhcnRlcmVkIGluIAp0 d28gZGlmZmVyZW50IHdvcmtpbmcgZ3JvdXBzLgoKTW9yZW92ZXIsIHdlIGRvIGhhdmUgd2cgZG9j dW1lbnRzIGZvciB0aGVzZSB0d28sIGJ1dCB3ZSBmaW5kIHZlcnkgaGFyZCAKdG8gZmluZCByZXZp ZXdlcnMgZm9yIHRob3NlLCB3aGljaCBtYWtlcyBtZSB0aGluayB0aGF0IHRoZXJlIGlzIG5vdCBt dWNoIAppbnRlcmVzdCBvbiB0aGVzZS4gU28sIGlmIHlvdSBmaW5kIGEgbW9yZSBtb3RpdmF0ZWQg Y3JldyB0byBkbyB0aGUgd29yaywgCnRoYXQgd291bGQgYmUgZ3JlYXQsIHdlIGNhbiBlaXRoZXIg ZG8gaXQgaW4gbWV4dCBvciBzb2Vtd2hlcmUgZWxzZSwgaWYgCnBlb3BsZSBmZWVscyB0aGF0IG5l ZWRzIHRvIGJlIGRvbmUsIGJ1dCB0aGF0IGlzIGNlcnRhaW5seSBub3QgdGhlIApmZWVsaW5nIGkg YW0gZ2V0dGluZyBmcm9tIHRoZSBpbnB1dCBpbiBtZXh0CgpSZWdhcmRzLCBtYXJjZWxvCgoKCkhv bmcgWW9uZy1HZXVuIGVzY3JpYmnDszoKPgo+IEhpLCBhbGwgaW4gTUVYVCBhbmQgbWlmLgo+Cj4g IAo+Cj4gSW4gSUVURiBtaWYgKE11bHRpcGxlIEludGVyZmFjZSkgbWFpbGluZyBsaXN0IAo+IChf aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWZfIAo+IDxodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZj4pLAo+Cj4gd2Ugbm93IGRpc2N1c3MgdGhl IGhvc3Qgd2hpY2ggd291bGQgbGlrZSB0byB1c2UgbXVsdGlwbGUgaW50ZXJmYWNlcy4KPgo+IEkg dW5kZXJzdGFuZCB0aGF0IE1FWFQgV0cgaXMgYWxzbyByZWxhdGVkIHRvIHRoZSB1c2Ugb2YgbXVs dGlwbGUgCj4gaW50ZXJmYWNlcyBvZiBhIGhvc3QKPiB1c2luZyBNb2JpbGUgSVB2NiBvciBhIG1v YmlsZSByb3V0ZXIgdXNpbmcgTkVNTyBCYXNpYyBTdXBwb3J0IGFuZCAKPiB0aGVpciB2YXJpYW50 cwo+Cj4gTUVYVCBXRyBpcyBmb2N1aW5nIG9uIG1vbmFtaTYgcmVsYXRlZCB0b3BpYyAobXVsdGlw bGUgQ29BLCBNdWx0aXBsZSAKPiBIb0EsIGFuZCBNdWx0cGxlIEhBLCBldGMuLCkKPiBhbmQgZXh0 ZWRuaW5nIE1vYmlsZSBJUHY2IGFuZCBORU1PIGZvciB0aGVzZSwgYnV0IG1pZiBpcyBub3QgcmVs YXRlZCAKPiB0byB0aGlzIGRpcmVjdGlvbi4KPiBJbiBtaWYsIHNvdXJjZSBhZGRyZXNzIHNlbGVj dGlvbiwgcm91dGluZyBhbmQgRE5TIGNvbnRyb2wgcHJvdG9jb2wgYXJlIAo+IGNvbnNpZGVyYXRp b24gaXRlbXMKPiBkdWUgdG8gbXVsdGlwbGUgaW50ZXJmYWNlcyBvZiBhIGhvc3QuCj4KPiAgCj4K PiBGb3IgbWlm4oCZcyBzY29wZSwgSmFyaSBBcmtrbyBtYWRlIHNvbWUgY29tbWVudHMgYW5kIGNs YXNzaWZpY2F0aW9uIG9mIAo+IHByb2JsZW1zLgo+Cj4gX2h0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9taWYvY3VycmVudC9tc2cwMDA1MC5odG1sXwo+Cj4gQW1vbmcgdGhlc2Ug Y2xhc3NpZmljYXRpb24gd2hpY2ggaW5jbHVkZXMgYWNjZXNzIHNlbGVjdGlvbiwgc3BsaXQgRE5T LCAKPiBjb25maWd1cmF0aW9uIHJlY29uY2lsaWF0aW9uLAo+IHJvdXRpbmcsIGFkZHJlc3Mgc2Vs ZWN0aW9uLCB0dW5uZWwgbXVsdGlob21pbmcsIGFuZCB0aGUgY29tbXVuaWNhdGlvbiAKPiB3YXkg YmV0d2VlbiB0aGUgaG9zdCBhbmQKPiB0aGUgbmV0d29yayBhYm91dCB0aGVpciBwb2xpY2llcyBy ZWdhcmRpbmcgYWxsIG9mIHRoZSBhYm92ZSwgSmFyaSBzYWlkIAo+IHRoYXQgYWNjZXNzIHNlbGVj dGlvbiBpcyBhbHJlYWR5Cj4gY292ZXJkIGluIFJGQyA1MTEzIGFuZCB0dW5uZWwgbXVsdGlob21p bmcgaXMgYWxyZWFkeSBjb3ZlcmVkIGluIE1FWFQgCj4gV0cgd29yayBpdGVtcy4KPgo+ICAKPgo+ IEF0IG1vbmFtaTYgV0cgaW4gNjR0aCBJRVRGIG1lZXRpbm5nLCBJIHN1Ym1pdHRlZCBhbmQgcHJl c2VudGVkIHR3byAKPiBJbnRlcm5ldCBEcmFmdHMuCj4KPiAtIEFuYWx5c2lzIG9mIG11bHRpcGxl IGludGVyZmFjZXMgaW4gYSBNb2JpbGUgTm9kZQo+Cj4gX2h0dHA6Ly90b29scy5pZXRmLm9yZy9p ZC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAwLnR4dF8KPgo+IC0gVmly dHVhbCBuZXR3b3JrIGludGVyZmFjZSBmb3IgbXVsdGlwbGUgaW50ZXJmYWNlcyBpbiBhIE1vYmls ZSBub2RlIAo+IHVzaW5nIE1vYmlsZSBJUHY2Cj4KPiBfaHR0cDovL3Rvb2xzLmlldGYub3JnL2lk L2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dF8gCj4gPGh0dHA6Ly90b29scy5p ZXRmLm9yZy9pZC9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni0wMC50eHQ+Cj4KPiBCZWNh dXNlIHRoZXNlIHR3byBkcmFmdHMgd2VyZSBub3QgaW4gdGhlIG1vbmFtaTYgV0figJlzIHNjb3Bl IGFuZCAKPiB2aXJ0dWFsIG5ldHdvcmsgaW50ZXJmYWNlIGRyYWZ0IHdhcwo+Cj4gaW1wbGVtZW50 YXRpb24gc3BlY2lmaWMsIHRoZXJlIHdlcmUgbm90IGFkb3BlZCBpbiBtb25hbWk2IFdH4oCZcyB3 b3JrIAo+IGl0ZW1zLiBUaGUgaW50ZW50aW9ucyBvZiB0d28gZHJhZnRzCj4gYXJlIHN1cHBvcnRp bmcgbXVsdGlwbGUgaW50ZXJmYWNlcyBvZiBhIGhvc3Qgd2l0aG91dCBleHRlbmRpbmcgTW9iaWxl IAo+IElQdjYvTkVNTy4KPgo+ICAKPgo+IEkgdGhpbmsgdGhhdCBtdWx0aXBsZSBpbnRlcmZhY2Vz IHByb2JsZW1zIG9mIGEgaG9zdCBhcmUgcmVsYXRlZCB0byAKPiBib3RoIE1vYmlsZSBJUC9ORU1P IHNwZWNpZmljIGlzc3VlcyBhbmQKPiBnZW5lcmFsIG5ldHdvcmsgaXNzdWVzLiBNb2JpbGUgSVAv TkVNTyBzcGVjaWZpYyBpc3N1ZXMgYXJlIHJlbGF0ZWQgdG8gCj4gZXh0ZW5kaW5nIG9mIE1vYmls ZSBJUC9ORU1PIGFuZAo+IHRoZXNlIGFyZSBhbHJlYWR5IHN0dWRpZWQgaW4gTUVYVCBXRyBhbmQg Z2VuZXJhbCBuZXR3b3JrIGlzc3VlcyB3aGljaCAKPiB3ZXJlIG5vdCByZWxhdGVkIHRvCj4gTW9i aWxlIElQL05FTU8gY291bGQgYmUgc3R1ZGllZCBpbiBtaWYuIEFzIHNhbWUgbWFubmVyLCBJIHRo aW5rIHRoYXQgCj4gbXkgZHJhZnRzIGNvdWxkIGJlIGRpc2N1c3NlZCBhbmQKPiBkZXZlbG9wZWQg aW4gbWlmLiBJbiB0aGUgZmlyc3QgZHJhZnQgKEFuYWx5c2lzIGRvY3VtZW50KSwgSSBjbGFzc2lm aWVkIAo+IG11bHRpcGxlIGludGVyZmFjZSBwcm9ibGVtcyBpbnRvCj4gTW9iaWxlIElQdjYtc2Vw Y2lmaWMgaXNzdWVzLCBHZW5lcmFsIG5ldHdvcmsgaXNzdWVzLCBhbmQgaGV0ZXJvZ2VuZW91cyAK PiBlbnZpcm9ubWVudCBpc3N1ZXMuCj4KPiAgCj4KPiBJbmNsdWRpbmcgSHVpIERlbmcgaW4gbWlm LCB3aXRoIHJlZ2FyZGluZyB0byB0aGVzZSBkcmFmdHMsIHRoZXkgd2FudCAKPiB0byBoZWFyIGNv bW1lbnRzIGZyb20gTUVYVCBXR+KAmXMgcG9pbnQgb2YgdmlldywKPiBiZWNhdXNlIGl0IHNlZW1z IHRoYXQgdGhlc2UgZHJhZnRzIGFyZSBxdWl0ZSByZWxhdGVkIHRvIG1vbmFtaTYvTUVYVCAKPiBX Ry4gU28sIEkgYXNrIE1FWFQgdG8gcmV2aWV3IHdoZXRoZXIgdGhlcmUgYXJlCj4KPiBzb21lIG92 ZXJsYXAgYmV0d2VlbiBNRVhUIHdvcmtzIGFuZCBteSBkcmFmdHMgb3Igbm90Lgo+Cj4gSXQgaXMg YXBwcmVjaWF0ZSB0byBnaXZlIGNvbW1lbnRzLgo+Cj4gIAo+Cj4gQmVzdCByZWdhcmRzLgo+Cj4g WW9uZy1HZXVuLgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpNRVhUIG1haWxpbmcgbGlzdApNRVhUQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbWV4dAo= From mext-bounces@ietf.org Wed Jan 28 02:08:02 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A8328C264; Wed, 28 Jan 2009 02:08:02 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A871128C25E; Wed, 28 Jan 2009 02:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FRT_MEETING=2.697, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gfc3zJKpoqFM; Wed, 28 Jan 2009 02:07:56 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id CBA9728C25D; Wed, 28 Jan 2009 02:07:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,337,1231110000"; d="vcf'?scan'208";a="23182761" Received: from guest-rocq-135129.inria.fr ([128.93.135.129]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jan 2009 11:07:36 +0100 Message-ID: <49802E59.7030407@inria.fr> Date: Wed, 28 Jan 2009 11:07:21 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: marcelo bagnulo braun References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> In-Reply-To: <498027F9.8050604@it.uc3m.es> Content-Type: multipart/mixed; boundary="------------070403020101030809060408" Cc: mif@ietf.org, julien.laganier.IETF@googlemail.com, mext@ietf.org Subject: Re: [MEXT] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------070403020101030809060408 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, The work on mobile edge multihoming (multiple interface support) started in the NEMO WG where we published RFC 4980 “Analysis of Multihoming in Network Mobility Support”. This document expresses the problem statement for multihomed mobile routers and mobile networks with multiple mobile routers. A similar document "Analysis of Multihoming in Mobile IPv6" http://tools.ietf.org/html/draft-ietf-monami6-mipv6-analysis-05 has been started under the framework of the MonAmi6 WG and is now a work item in MeXT, as pointed out by Marcelo. In addition, another draft explaining the motivations also exists http://tools.ietf.org/html/draft-ietf-monami6-multihoming-motivation-scenario-03 These two drafts correspond to the 2 MeXT WG items as reminded by Marcelo (we need to republish them, though - the lack of progress on these documents is due to a number of reasons and the recent activity on this topic is pleading for a quick update - and I'm will willing to do it ASAP given this interest). So, I think MIF shall be referring to these 3 documents (RFC 4980 and the 2 above mentioned drafts) since the purpose of these documents is to document the issues for mobile hosts and routers. Regards, Thierry marcelo bagnulo braun wrote: > Hi, > > In the current MEXT charter there are several items about supporting > multiple interfaces, including the following two: > > - A document explaining the motivations for a node using multiple > interfaces and the scenarios where it may end up with multiple > global addresses on its interfaces [Informational] > > - An analysis document explaining what are the limitations for > mobile hosts using multiple simultaneous Care-of Addresses and Home > Agent addresses using Mobile IPv6, whether issues are specific to > Mobile IPv6 or not [Informational]. > > I think this is very similar to the scope of one of you documents at > least, so i would find very strange that the same work is chartered in > two different working groups. > > Moreover, we do have wg documents for these two, but we find very hard > to find reviewers for those, which makes me think that there is not > much interest on these. So, if you find a more motivated crew to do > the work, that would be great, we can either do it in mext or > soemwhere else, if people feels that needs to be done, but that is > certainly not the feeling i am getting from the input in mext > > Regards, marcelo > > > > Hong Yong-Geun escribió: >> >> Hi, all in MEXT and mif. >> >> >> >> In IETF mif (Multiple Interface) mailing list >> (_https://www.ietf.org/mailman/listinfo/mif_ >> ), >> >> we now discuss the host which would like to use multiple interfaces. >> >> I understand that MEXT WG is also related to the use of multiple >> interfaces of a host >> using Mobile IPv6 or a mobile router using NEMO Basic Support and >> their variants >> >> MEXT WG is focuing on monami6 related topic (multiple CoA, Multiple >> HoA, and Multple HA, etc.,) >> and extedning Mobile IPv6 and NEMO for these, but mif is not related >> to this direction. >> In mif, source address selection, routing and DNS control protocol >> are consideration items >> due to multiple interfaces of a host. >> >> >> >> For mif’s scope, Jari Arkko made some comments and classification of >> problems. >> >> _http://www.ietf.org/mail-archive/web/mif/current/msg00050.html_ >> >> Among these classification which includes access selection, split >> DNS, configuration reconciliation, >> routing, address selection, tunnel multihoming, and the communication >> way between the host and >> the network about their policies regarding all of the above, Jari >> said that access selection is already >> coverd in RFC 5113 and tunnel multihoming is already covered in MEXT >> WG work items. >> >> >> >> At monami6 WG in 64th IETF meetinng, I submitted and presented two >> Internet Drafts. >> >> - Analysis of multiple interfaces in a Mobile Node >> >> _http://tools.ietf.org/id/draft-hong-multipleif-mn-pb-statement-00.txt_ >> >> - Virtual network interface for multiple interfaces in a Mobile node >> using Mobile IPv6 >> >> _http://tools.ietf.org/id/draft-hong-virtualif-mn-mipv6-00.txt_ >> >> >> Because these two drafts were not in the monami6 WG’s scope and >> virtual network interface draft was >> >> implementation specific, there were not adoped in monami6 WG’s work >> items. The intentions of two drafts >> are supporting multiple interfaces of a host without extending Mobile >> IPv6/NEMO. >> >> >> >> I think that multiple interfaces problems of a host are related to >> both Mobile IP/NEMO specific issues and >> general network issues. Mobile IP/NEMO specific issues are related to >> extending of Mobile IP/NEMO and >> these are already studied in MEXT WG and general network issues which >> were not related to >> Mobile IP/NEMO could be studied in mif. As same manner, I think that >> my drafts could be discussed and >> developed in mif. In the first draft (Analysis document), I >> classified multiple interface problems into >> Mobile IPv6-sepcific issues, General network issues, and >> heterogeneous environment issues. >> >> >> >> Including Hui Deng in mif, with regarding to these drafts, they want >> to hear comments from MEXT WG’s point of view, >> because it seems that these drafts are quite related to monami6/MEXT >> WG. So, I ask MEXT to review whether there are >> >> some overlap between MEXT works and my drafts or not. >> >> It is appreciate to give comments. >> >> >> >> Best regards. >> >> Yong-Geun. >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --------------070403020101030809060408 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="thierry_ernst.vcf" YmVnaW46dmNhcmQNCmZuOlRoaWVycnkgRXJuc3QNCm46RXJuc3Q7VGhpZXJyeQ0Kb3JnOklO UklBIFJvY3F1ZW5jb3VydDtJTUFSQSAtIExBUkENCmFkcjo7Ozs7OztGcmFuY2UNCnRlbDt3 b3JrOiszMyAxIDM5IDYzIDU5IDMwDQp0ZWw7ZmF4OiszMyAxIDM5IDYzIDU0IDkxDQp0ZWw7 Y2VsbDorMzMgNiA3NiA1NiAyNSA5Ng0KdXJsOmh0dHA6Ly93d3cubGFyYS5wcmQuZnINCnZl cnNpb246Mi4xDQplbmQ6dmNhcmQNCg0K --------------070403020101030809060408 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --------------070403020101030809060408-- From mext-bounces@ietf.org Wed Jan 28 18:37:38 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DF93A693B; Wed, 28 Jan 2009 18:37:38 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A2328C180 for ; Wed, 28 Jan 2009 18:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.878 X-Spam-Level: * X-Spam-Status: No, score=1.878 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, FRT_MEETING=2.697, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ro2uVE8at-b6 for ; Wed, 28 Jan 2009 18:37:36 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id 785943A693B for ; Wed, 28 Jan 2009 18:37:35 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Thu, 29 Jan 2009 11:37:19 +0900 Priority: normal X-ReadCheckName: mext%40ietf.org Thread-Topic: Re: Multiple interfaces problems in MEXT and mif X-ReadCheckMessageID: <577f229e-2bf2-4c5e-9b97-e2d3891e2cb5@etri.re.kr> thread-index: AcmBuoFMCJH4RGXFThWZcJo161OlJg== From: "Hong Yong-Geun" To: "marcelo bagnulo braun" Date: Thu, 29 Jan 2009 11:37:19 +0900 Comment: ??, u-??, Message-ID: <545001c981ba$81537400$8310fe81@etri.info> MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 X-OriginalArrivalTime: 29 Jan 2009 02:37:19.0243 (UTC) FILETIME=[81726DB0:01C981BA] Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [MEXT] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0231155109==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0231155109== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----=_NextPart_000_544B_01C98205.F138D210" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_544B_01C98205.F138D210 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ------=_NextPart_000_544B_01C98205.F138D210 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SGksIE1hcmNlbG8uPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMuPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj5JIGFncmVlIHRoYXQmbmJzcDsgdGhlIGN1cnJlbnQgTUVYVCBXRyBj aGFydGVyIGFscmVhZHkgaGFzIHNldmVyYWwgaXRlbXMgYWJvdXQgc3VwcG9ydGluZyBtdWx0aXBs ZSBpbnRlcmZhY2VzLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+TXkgZG9jdW1lbnRz IGFyZSBvbGQgdmVyc2lvbiB3aGljaCB3ZXJlIHN1Ym1pdHRlZCB0byBtb25hbWk2IFdHIGF0IDY0 dGggSUVURiBtZWV0aW5nIGFuZCB0aGV5IHdlcmU8QlI+bm90IHVwZGF0ZWQgcHJvcGVybHkuIFNv LCBpdCBzZWVtcyB0aGF0IHNvbWUgY29udGVudHMgYXJlIHNpbWlsYXIgdG8gdGhlIHdvcmtzIGlu IE1FWFQgV0cuIDwvRElWPg0KPERJVj5JIHdpbGwgdXBkYXRlIG15IGRvY3VtZW50cyB0byBmb2N1 cyBvbiBtaWYncyBzY29wZS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkl0IGlzIGFw cHJlY2lhdGUgdG8gdW5kZXJzdGFuZCB0aGF0IChldmVuIHRob3VnaCB0aGUgc2NvcGUgb2YgbWlm IGlzIG5vdCBmaXhlZCkgbWlmIGhhcyBkaWZmZXJlbnQgZGlyZWN0aW9ucyB0bzxCUj5NRVhULiA8 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkJlc3QgcmVnYXJkcy48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPllvbmctR2V1bi48L0RJVj4NCjxESVY+PEJSPi0tLS0t7JuQ67O4 IOuplOyLnOyngC0tLS0tPEJSPjxCPkZyb206PC9CPiAibWFyY2VsbyBiYWdudWxvIGJyYXVuIiAm bHQ7bWFyY2Vsb0BpdC51YzNtLmVzJmd0OzxCUj48Qj5Gcm9tIERhdGU6PC9CPiAyMDA5LTAxLTI4 IOyYpO2bhCA2OjQwOjA5PEJSPjxCPlRvOjwvQj4gIkhvbmcgWW9uZy1HZXVuIiAmbHQ7eWdob25n QGV0cmkucmUua3ImZ3Q7PEJSPjxCPkNjOjwvQj4gIm1leHRAaWV0Zi5vcmciICZsdDttZXh0QGll dGYub3JnJmd0OywgIm1pZkBpZXRmLm9yZyIgJmx0O21pZkBpZXRmLm9yZyZndDssICJqdWxpZW4u bGFnYW5pZXIuSUVURkBnb29nbGVtYWlsLmNvbSIgJmx0O2p1bGllbi5sYWdhbmllci5JRVRGQGdv b2dsZW1haWwuY29tJmd0OywgImRlbmdodWkwMkBnbWFpbC5jb20iICZsdDtkZW5naHVpMDJAZ21h aWwuY29tJmd0OzxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IE11bHRpcGxlIGludGVyZmFjZXMgcHJv YmxlbXMgaW4gTUVYVCBhbmQgbWlmPEJSPjxCUj4NCjxESVY+PCEtLSBDb252ZXJ0ZWQgZnJvbSB0 ZXh0L3BsYWluIGZvcm1hdCAtLT48QlI+DQo8UD48Rk9OVCBzaXplPTI+SGksPEJSPjxCUj5JbiB0 aGUgY3VycmVudCBNRVhUIGNoYXJ0ZXIgdGhlcmUgYXJlIHNldmVyYWwgaXRlbXMgYWJvdXQgc3Vw cG9ydGluZzxCUj5tdWx0aXBsZSBpbnRlcmZhY2VzLCBpbmNsdWRpbmcgdGhlIGZvbGxvd2luZyB0 d286PEJSPjxCUj4tIEEgZG9jdW1lbnQgZXhwbGFpbmluZyB0aGUgbW90aXZhdGlvbnMgZm9yIGEg bm9kZSB1c2luZyBtdWx0aXBsZTxCUj5pbnRlcmZhY2VzIGFuZCB0aGUgc2NlbmFyaW9zIHdoZXJl IGl0IG1heSBlbmQgdXAgd2l0aCBtdWx0aXBsZTxCUj5nbG9iYWwgYWRkcmVzc2VzIG9uIGl0cyBp bnRlcmZhY2VzIFtJbmZvcm1hdGlvbmFsXTxCUj48QlI+LSBBbiBhbmFseXNpcyBkb2N1bWVudCBl eHBsYWluaW5nIHdoYXQgYXJlIHRoZSBsaW1pdGF0aW9ucyBmb3I8QlI+bW9iaWxlIGhvc3RzIHVz aW5nIG11bHRpcGxlIHNpbXVsdGFuZW91cyBDYXJlLW9mIEFkZHJlc3NlcyBhbmQgSG9tZTxCUj5B Z2VudCBhZGRyZXNzZXMgdXNpbmcgTW9iaWxlIElQdjYsIHdoZXRoZXIgaXNzdWVzIGFyZSBzcGVj aWZpYyB0bzxCUj5Nb2JpbGUgSVB2NiBvciBub3QgW0luZm9ybWF0aW9uYWxdLjxCUj48QlI+SSB0 aGluayB0aGlzIGlzIHZlcnkgc2ltaWxhciB0byB0aGUgc2NvcGUgb2Ygb25lIG9mIHlvdSBkb2N1 bWVudHMgYXQ8QlI+bGVhc3QsIHNvIGkgd291bGQgZmluZCB2ZXJ5IHN0cmFuZ2UgdGhhdCB0aGUg c2FtZSB3b3JrIGlzIGNoYXJ0ZXJlZCBpbjxCUj50d28gZGlmZmVyZW50IHdvcmtpbmcgZ3JvdXBz LjxCUj48QlI+TW9yZW92ZXIsIHdlIGRvIGhhdmUgd2cgZG9jdW1lbnRzIGZvciB0aGVzZSB0d28s IGJ1dCB3ZSBmaW5kIHZlcnkgaGFyZDxCUj50byBmaW5kIHJldmlld2VycyBmb3IgdGhvc2UsIHdo aWNoIG1ha2VzIG1lIHRoaW5rIHRoYXQgdGhlcmUgaXMgbm90IG11Y2g8QlI+aW50ZXJlc3Qgb24g dGhlc2UuIFNvLCBpZiB5b3UgZmluZCBhIG1vcmUgbW90aXZhdGVkIGNyZXcgdG8gZG8gdGhlIHdv cmssPEJSPnRoYXQgd291bGQgYmUgZ3JlYXQsIHdlIGNhbiBlaXRoZXIgZG8gaXQgaW4gbWV4dCBv ciBzb2Vtd2hlcmUgZWxzZSwgaWY8QlI+cGVvcGxlIGZlZWxzIHRoYXQgbmVlZHMgdG8gYmUgZG9u ZSwgYnV0IHRoYXQgaXMgY2VydGFpbmx5IG5vdCB0aGU8QlI+ZmVlbGluZyBpIGFtIGdldHRpbmcg ZnJvbSB0aGUgaW5wdXQgaW4gbWV4dDxCUj48QlI+UmVnYXJkcywgbWFyY2VsbzxCUj48QlI+PEJS PjxCUj5Ib25nIFlvbmctR2V1biBlc2NyaWJpPzo8QlI+Jmd0OzxCUj4mZ3Q7IEhpLCBhbGwgaW4g TUVYVCBhbmQgbWlmLjxCUj4mZ3Q7PEJSPiZndDsmbmJzcDs8QlI+Jmd0OzxCUj4mZ3Q7IEluIElF VEYgbWlmIChNdWx0aXBsZSBJbnRlcmZhY2UpIG1haWxpbmcgbGlzdDxCUj4mZ3Q7IChfPEEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWZfIiB0YXJnZXQ9X2Js YW5rPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlmXzwvQT48QlI+Jmd0 OyAmbHQ7PEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWYi IHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWY8 L0E+Jmd0OyksPEJSPiZndDs8QlI+Jmd0OyB3ZSBub3cgZGlzY3VzcyB0aGUgaG9zdCB3aGljaCB3 b3VsZCBsaWtlIHRvIHVzZSBtdWx0aXBsZSBpbnRlcmZhY2VzLjxCUj4mZ3Q7PEJSPiZndDsgSSB1 bmRlcnN0YW5kIHRoYXQgTUVYVCBXRyBpcyBhbHNvIHJlbGF0ZWQgdG8gdGhlIHVzZSBvZiBtdWx0 aXBsZTxCUj4mZ3Q7IGludGVyZmFjZXMgb2YgYSBob3N0PEJSPiZndDsgdXNpbmcgTW9iaWxlIElQ djYgb3IgYSBtb2JpbGUgcm91dGVyIHVzaW5nIE5FTU8gQmFzaWMgU3VwcG9ydCBhbmQ8QlI+Jmd0 OyB0aGVpciB2YXJpYW50czxCUj4mZ3Q7PEJSPiZndDsgTUVYVCBXRyBpcyBmb2N1aW5nIG9uIG1v bmFtaTYgcmVsYXRlZCB0b3BpYyAobXVsdGlwbGUgQ29BLCBNdWx0aXBsZTxCUj4mZ3Q7IEhvQSwg YW5kIE11bHRwbGUgSEEsIGV0Yy4sKTxCUj4mZ3Q7IGFuZCBleHRlZG5pbmcgTW9iaWxlIElQdjYg YW5kIE5FTU8gZm9yIHRoZXNlLCBidXQgbWlmIGlzIG5vdCByZWxhdGVkPEJSPiZndDsgdG8gdGhp cyBkaXJlY3Rpb24uPEJSPiZndDsgSW4gbWlmLCBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24sIHJv dXRpbmcgYW5kIEROUyBjb250cm9sIHByb3RvY29sIGFyZTxCUj4mZ3Q7IGNvbnNpZGVyYXRpb24g aXRlbXM8QlI+Jmd0OyBkdWUgdG8gbXVsdGlwbGUgaW50ZXJmYWNlcyBvZiBhIGhvc3QuPEJSPiZn dDs8QlI+Jmd0OyZuYnNwOzxCUj4mZ3Q7PEJSPiZndDsgRm9yIG1pZuKAmXMgc2NvcGUsIEphcmkg QXJra28gbWFkZSBzb21lIGNvbW1lbnRzIGFuZCBjbGFzc2lmaWNhdGlvbiBvZjxCUj4mZ3Q7IHBy b2JsZW1zLjxCUj4mZ3Q7PEJSPiZndDsgXzxBIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9taWYvY3VycmVudC9tc2cwMDA1MC5odG1sXyIgdGFyZ2V0PV9ibGFuaz5o dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWlmL2N1cnJlbnQvbXNnMDAwNTAu aHRtbF88L0E+PEJSPiZndDs8QlI+Jmd0OyBBbW9uZyB0aGVzZSBjbGFzc2lmaWNhdGlvbiB3aGlj aCBpbmNsdWRlcyBhY2Nlc3Mgc2VsZWN0aW9uLCBzcGxpdCBETlMsPEJSPiZndDsgY29uZmlndXJh dGlvbiByZWNvbmNpbGlhdGlvbiw8QlI+Jmd0OyByb3V0aW5nLCBhZGRyZXNzIHNlbGVjdGlvbiwg dHVubmVsIG11bHRpaG9taW5nLCBhbmQgdGhlIGNvbW11bmljYXRpb248QlI+Jmd0OyB3YXkgYmV0 d2VlbiB0aGUgaG9zdCBhbmQ8QlI+Jmd0OyB0aGUgbmV0d29yayBhYm91dCB0aGVpciBwb2xpY2ll cyByZWdhcmRpbmcgYWxsIG9mIHRoZSBhYm92ZSwgSmFyaSBzYWlkPEJSPiZndDsgdGhhdCBhY2Nl c3Mgc2VsZWN0aW9uIGlzIGFscmVhZHk8QlI+Jmd0OyBjb3ZlcmQgaW4gUkZDIDUxMTMgYW5kIHR1 bm5lbCBtdWx0aWhvbWluZyBpcyBhbHJlYWR5IGNvdmVyZWQgaW4gTUVYVDxCUj4mZ3Q7IFdHIHdv cmsgaXRlbXMuPEJSPiZndDs8QlI+Jmd0OyZuYnNwOzxCUj4mZ3Q7PEJSPiZndDsgQXQgbW9uYW1p NiBXRyBpbiA2NHRoIElFVEYgbWVldGlubmcsIEkgc3VibWl0dGVkIGFuZCBwcmVzZW50ZWQgdHdv PEJSPiZndDsgSW50ZXJuZXQgRHJhZnRzLjxCUj4mZ3Q7PEJSPiZndDsgLSBBbmFseXNpcyBvZiBt dWx0aXBsZSBpbnRlcmZhY2VzIGluIGEgTW9iaWxlIE5vZGU8QlI+Jmd0OzxCUj4mZ3Q7IF88QSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy1tdWx0aXBsZWlmLW1uLXBi LXN0YXRlbWVudC0wMC50eHRfIiB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly90b29scy5pZXRmLm9yZy9p ZC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAwLnR4dF88L0E+PEJSPiZn dDs8QlI+Jmd0OyAtIFZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgZm9yIG11bHRpcGxlIGludGVy ZmFjZXMgaW4gYSBNb2JpbGUgbm9kZTxCUj4mZ3Q7IHVzaW5nIE1vYmlsZSBJUHY2PEJSPiZndDs8 QlI+Jmd0OyBfPEEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWhvbmctdmly dHVhbGlmLW1uLW1pcHY2LTAwLnR4dF8iIHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dF88L0E+PEJSPiZndDsg Jmx0OzxBIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ob25nLXZpcnR1YWxp Zi1tbi1taXB2Ni0wMC50eHQiIHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lk L2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dDwvQT4mZ3Q7PEJSPiZndDs8QlI+ Jmd0OyBCZWNhdXNlIHRoZXNlIHR3byBkcmFmdHMgd2VyZSBub3QgaW4gdGhlIG1vbmFtaTYgV0fi gJlzIHNjb3BlIGFuZDxCUj4mZ3Q7IHZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgZHJhZnQgd2Fz PEJSPiZndDs8QlI+Jmd0OyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYywgdGhlcmUgd2VyZSBub3Qg YWRvcGVkIGluIG1vbmFtaTYgV0figJlzIHdvcms8QlI+Jmd0OyBpdGVtcy4gVGhlIGludGVudGlv bnMgb2YgdHdvIGRyYWZ0czxCUj4mZ3Q7IGFyZSBzdXBwb3J0aW5nIG11bHRpcGxlIGludGVyZmFj ZXMgb2YgYSBob3N0IHdpdGhvdXQgZXh0ZW5kaW5nIE1vYmlsZTxCUj4mZ3Q7IElQdjYvTkVNTy48 QlI+Jmd0OzxCUj4mZ3Q7Jm5ic3A7PEJSPiZndDs8QlI+Jmd0OyBJIHRoaW5rIHRoYXQgbXVsdGlw bGUgaW50ZXJmYWNlcyBwcm9ibGVtcyBvZiBhIGhvc3QgYXJlIHJlbGF0ZWQgdG88QlI+Jmd0OyBi b3RoIE1vYmlsZSBJUC9ORU1PIHNwZWNpZmljIGlzc3VlcyBhbmQ8QlI+Jmd0OyBnZW5lcmFsIG5l dHdvcmsgaXNzdWVzLiBNb2JpbGUgSVAvTkVNTyBzcGVjaWZpYyBpc3N1ZXMgYXJlIHJlbGF0ZWQg dG88QlI+Jmd0OyBleHRlbmRpbmcgb2YgTW9iaWxlIElQL05FTU8gYW5kPEJSPiZndDsgdGhlc2Ug YXJlIGFscmVhZHkgc3R1ZGllZCBpbiBNRVhUIFdHIGFuZCBnZW5lcmFsIG5ldHdvcmsgaXNzdWVz IHdoaWNoPEJSPiZndDsgd2VyZSBub3QgcmVsYXRlZCB0bzxCUj4mZ3Q7IE1vYmlsZSBJUC9ORU1P IGNvdWxkIGJlIHN0dWRpZWQgaW4gbWlmLiBBcyBzYW1lIG1hbm5lciwgSSB0aGluayB0aGF0PEJS PiZndDsgbXkgZHJhZnRzIGNvdWxkIGJlIGRpc2N1c3NlZCBhbmQ8QlI+Jmd0OyBkZXZlbG9wZWQg aW4gbWlmLiBJbiB0aGUgZmlyc3QgZHJhZnQgKEFuYWx5c2lzIGRvY3VtZW50KSwgSSBjbGFzc2lm aWVkPEJSPiZndDsgbXVsdGlwbGUgaW50ZXJmYWNlIHByb2JsZW1zIGludG88QlI+Jmd0OyBNb2Jp bGUgSVB2Ni1zZXBjaWZpYyBpc3N1ZXMsIEdlbmVyYWwgbmV0d29yayBpc3N1ZXMsIGFuZCBoZXRl cm9nZW5lb3VzPEJSPiZndDsgZW52aXJvbm1lbnQgaXNzdWVzLjxCUj4mZ3Q7PEJSPiZndDsmbmJz cDs8QlI+Jmd0OzxCUj4mZ3Q7IEluY2x1ZGluZyBIdWkgRGVuZyBpbiBtaWYsIHdpdGggcmVnYXJk aW5nIHRvIHRoZXNlIGRyYWZ0cywgdGhleSB3YW50PEJSPiZndDsgdG8gaGVhciBjb21tZW50cyBm cm9tIE1FWFQgV0figJlzIHBvaW50IG9mIHZpZXcsPEJSPiZndDsgYmVjYXVzZSBpdCBzZWVtcyB0 aGF0IHRoZXNlIGRyYWZ0cyBhcmUgcXVpdGUgcmVsYXRlZCB0byBtb25hbWk2L01FWFQ8QlI+Jmd0 OyBXRy4gU28sIEkgYXNrIE1FWFQgdG8gcmV2aWV3IHdoZXRoZXIgdGhlcmUgYXJlPEJSPiZndDs8 QlI+Jmd0OyBzb21lIG92ZXJsYXAgYmV0d2VlbiBNRVhUIHdvcmtzIGFuZCBteSBkcmFmdHMgb3Ig bm90LjxCUj4mZ3Q7PEJSPiZndDsgSXQgaXMgYXBwcmVjaWF0ZSB0byBnaXZlIGNvbW1lbnRzLjxC Uj4mZ3Q7PEJSPiZndDsmbmJzcDs8QlI+Jmd0OzxCUj4mZ3Q7IEJlc3QgcmVnYXJkcy48QlI+Jmd0 OzxCUj4mZ3Q7IFlvbmctR2V1bi48QlI+Jmd0OzxCUj48QlI+PC9GT05UPjwvUD48L0RJVj48L0RJ Vj48L0RJVj48aW1nIHN0eWxlPSJkaXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVpZ2h0PTAgc3JjPSJo dHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNweD9lbWFpbD1tZXh0 QGlldGYub3JnJm5hbWU9bWV4dCU0MGlldGYub3JnJmZyb21lbWFpbD15Z2hvbmdAZXRyaS5yZS5r ciZtZXNzYWdlaWQ9JTNDNTc3ZjIyOWUtMmJmMi00YzVlLTliOTctZTJkMzg5MWUyY2I1QGV0cmku cmUua3IlM0UiPg== ------=_NextPart_000_544B_01C98205.F138D210-- --===============0231155109== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0231155109==-- From mext-bounces@ietf.org Wed Jan 28 18:45:59 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 807D83A697F; Wed, 28 Jan 2009 18:45:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0650E3A6B56 for ; Wed, 28 Jan 2009 18:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.96 X-Spam-Level: * X-Spam-Status: No, score=1.96 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, FRT_MEETING=2.697, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh88UMtq-huX for ; Wed, 28 Jan 2009 18:45:57 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id 59EC83A6872 for ; Wed, 28 Jan 2009 18:45:56 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Thu, 29 Jan 2009 11:45:39 +0900 Priority: normal X-ReadCheckName: mext%40ietf.org Thread-Topic: [MEXT] Multiple interfaces problems in MEXT and mif X-ReadCheckMessageID: <62702911-2d45-4b38-9064-1326df8044fa@etri.re.kr> thread-index: AcmBu6vE3drNFl6kSdSQrFtmofgKHg== From: "Hong Yong-Geun" To: "Thierry Ernst" , "marcelo bagnulo braun" Date: Thu, 29 Jan 2009 11:45:39 +0900 Comment: ??, u-??, Message-ID: <583101c981bb$abce47e0$8310fe81@etri.info> MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 X-OriginalArrivalTime: 29 Jan 2009 02:45:39.0993 (UTC) FILETIME=[ABEAD090:01C981BB] Cc: mif@ietf.org, julien.laganier.IETF@googlemail.com, mext@ietf.org Subject: Re: [MEXT] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1369434789==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1369434789== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----=_NextPart_000_581D_01C98207.1BAEC3F0" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_581D_01C98207.1BAEC3F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ------=_NextPart_000_581D_01C98207.1BAEC3F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SGksJm5ic3A7VGhpZXJyeS48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRoYW5rcyBmb3IgeW91ciBjb21tZW50cy48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkgYWdyZWUgdGhhdCB0aGUgMyBkb2N1bWVudHMgd2hpY2gg eW91IG1lbnRpb24gc2hvdWxkIGJlIHJlZmVycmVkIGluIG1pZjxCUj53aGVuIHdlIHRhbGsgdG8g bW9iaWxlIGhvc3RzIGFuZCByb3V0ZXJzIHdpdGggdXNpbmcgTW9iaWxlIElQdjYvTkVNTy48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkJlc3QgcmVnYXJkcy48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPllvbmctR2V1bi48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjxCUj4tLS0tLeybkOuzuCDrqZTsi5zsp4AtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gIlRoaWVycnkg RXJuc3QiICZsdDt0aGllcnJ5LmVybnN0QGlucmlhLmZyJmd0OzxCUj48Qj5Gcm9tIERhdGU6PC9C PiAyMDA5LTAxLTI4IOyYpO2bhCA3OjA3OjIxPEJSPjxCPlRvOjwvQj4gIm1hcmNlbG8gYmFnbnVs byBicmF1biIgJmx0O21hcmNlbG9AaXQudWMzbS5lcyZndDs8QlI+PEI+Q2M6PC9CPiAiSG9uZyBZ b25nLUdldW4iICZsdDt5Z2hvbmdAZXRyaS5yZS5rciZndDssICJqdWxpZW4ubGFnYW5pZXIuSUVU RkBnb29nbGVtYWlsLmNvbSIgJmx0O2p1bGllbi5sYWdhbmllci5JRVRGQGdvb2dsZW1haWwuY29t Jmd0OywgIm1pZkBpZXRmLm9yZyIgJmx0O21pZkBpZXRmLm9yZyZndDssICJtZXh0QGlldGYub3Jn IiAmbHQ7bWV4dEBpZXRmLm9yZyZndDs8QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBbTUVYVF0gTXVs dGlwbGUgaW50ZXJmYWNlcyBwcm9ibGVtcyBpbiBNRVhUIGFuZCBtaWY8QlI+PEJSPg0KPERJVj48 IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9ybWF0IC0tPjxCUj48QlI+DQo8UD48Rk9O VCBzaXplPTI+RGVhciBhbGwsPEJSPjxCUj5UaGUgd29yayBvbiBtb2JpbGUgZWRnZSBtdWx0aWhv bWluZyAobXVsdGlwbGUgaW50ZXJmYWNlIHN1cHBvcnQpIHN0YXJ0ZWQ8QlI+aW4gdGhlIE5FTU8g V0cgd2hlcmUgd2UgcHVibGlzaGVkIFJGQyA0OTgwIOKAnEFuYWx5c2lzIG9mIE11bHRpaG9taW5n IGluPEJSPk5ldHdvcmsgTW9iaWxpdHkgU3VwcG9ydOKAnS4mbmJzcDsgVGhpcyBkb2N1bWVudCBl eHByZXNzZXMgdGhlIHByb2JsZW08QlI+c3RhdGVtZW50IGZvciBtdWx0aWhvbWVkIG1vYmlsZSBy b3V0ZXJzIGFuZCBtb2JpbGUgbmV0d29ya3Mgd2l0aDxCUj5tdWx0aXBsZSBtb2JpbGUgcm91dGVy cy48QlI+PEJSPkEgc2ltaWxhciBkb2N1bWVudCAiQW5hbHlzaXMgb2YgTXVsdGlob21pbmcgaW4g TW9iaWxlIElQdjYiPEJSPjxBIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtbW9uYW1pNi1taXB2Ni1hbmFseXNpcy0wNSIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1vbmFtaTYtbWlwdjYtYW5hbHlzaXMtMDU8L0E+ PEJSPmhhcyBiZWVuIHN0YXJ0ZWQgdW5kZXIgdGhlIGZyYW1ld29yayBvZiB0aGUgTW9uQW1pNiBX RyBhbmQgaXMgbm93IGEgd29yazxCUj5pdGVtIGluIE1lWFQsIGFzIHBvaW50ZWQgb3V0IGJ5IE1h cmNlbG8uPEJSPjxCUj5JbiBhZGRpdGlvbiwgYW5vdGhlciBkcmFmdCBleHBsYWluaW5nIHRoZSBt b3RpdmF0aW9ucyBhbHNvIGV4aXN0czxCUj48QSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW1vbmFtaTYtbXVsdGlob21pbmctbW90aXZhdGlvbi1zY2VuYXJpby0w MyIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1v bmFtaTYtbXVsdGlob21pbmctbW90aXZhdGlvbi1zY2VuYXJpby0wMzwvQT48QlI+PEJSPlRoZXNl IHR3byBkcmFmdHMgY29ycmVzcG9uZCB0byB0aGUgMiBNZVhUIFdHIGl0ZW1zIGFzIHJlbWluZGVk IGJ5PEJSPk1hcmNlbG8gKHdlIG5lZWQgdG8gcmVwdWJsaXNoIHRoZW0sIHRob3VnaCAtIHRoZSBs YWNrIG9mIHByb2dyZXNzIG9uPEJSPnRoZXNlIGRvY3VtZW50cyBpcyBkdWUgdG8gYSBudW1iZXIg b2YgcmVhc29ucyBhbmQgdGhlIHJlY2VudCBhY3Rpdml0eSBvbjxCUj50aGlzIHRvcGljIGlzIHBs ZWFkaW5nIGZvciBhIHF1aWNrIHVwZGF0ZSAtIGFuZCBJJ20gd2lsbCB3aWxsaW5nIHRvIGRvPEJS Pml0IEFTQVAgZ2l2ZW4gdGhpcyBpbnRlcmVzdCkuPEJSPjxCUj5TbywgSSB0aGluayBNSUYgc2hh bGwgYmUgcmVmZXJyaW5nIHRvIHRoZXNlIDMgZG9jdW1lbnRzIChSRkMgNDk4MCBhbmQ8QlI+dGhl IDIgYWJvdmUgbWVudGlvbmVkIGRyYWZ0cykgc2luY2UgdGhlIHB1cnBvc2Ugb2YgdGhlc2UgZG9j dW1lbnRzIGlzIHRvPEJSPmRvY3VtZW50IHRoZSBpc3N1ZXMgZm9yIG1vYmlsZSBob3N0cyBhbmQg cm91dGVycy48QlI+PEJSPlJlZ2FyZHMsPEJSPlRoaWVycnk8QlI+PEJSPjxCUj48QlI+PEJSPjxC Uj5tYXJjZWxvIGJhZ251bG8gYnJhdW4gd3JvdGU6PEJSPiZndDsgSGksPEJSPiZndDs8QlI+Jmd0 OyBJbiB0aGUgY3VycmVudCBNRVhUIGNoYXJ0ZXIgdGhlcmUgYXJlIHNldmVyYWwgaXRlbXMgYWJv dXQgc3VwcG9ydGluZzxCUj4mZ3Q7IG11bHRpcGxlIGludGVyZmFjZXMsIGluY2x1ZGluZyB0aGUg Zm9sbG93aW5nIHR3bzo8QlI+Jmd0OzxCUj4mZ3Q7IC0gQSBkb2N1bWVudCBleHBsYWluaW5nIHRo ZSBtb3RpdmF0aW9ucyBmb3IgYSBub2RlIHVzaW5nIG11bHRpcGxlPEJSPiZndDsgaW50ZXJmYWNl cyBhbmQgdGhlIHNjZW5hcmlvcyB3aGVyZSBpdCBtYXkgZW5kIHVwIHdpdGggbXVsdGlwbGU8QlI+ Jmd0OyBnbG9iYWwgYWRkcmVzc2VzIG9uIGl0cyBpbnRlcmZhY2VzIFtJbmZvcm1hdGlvbmFsXTxC Uj4mZ3Q7PEJSPiZndDsgLSBBbiBhbmFseXNpcyBkb2N1bWVudCBleHBsYWluaW5nIHdoYXQgYXJl IHRoZSBsaW1pdGF0aW9ucyBmb3I8QlI+Jmd0OyBtb2JpbGUgaG9zdHMgdXNpbmcgbXVsdGlwbGUg c2ltdWx0YW5lb3VzIENhcmUtb2YgQWRkcmVzc2VzIGFuZCBIb21lPEJSPiZndDsgQWdlbnQgYWRk cmVzc2VzIHVzaW5nIE1vYmlsZSBJUHY2LCB3aGV0aGVyIGlzc3VlcyBhcmUgc3BlY2lmaWMgdG88 QlI+Jmd0OyBNb2JpbGUgSVB2NiBvciBub3QgW0luZm9ybWF0aW9uYWxdLjxCUj4mZ3Q7PEJSPiZn dDsgSSB0aGluayB0aGlzIGlzIHZlcnkgc2ltaWxhciB0byB0aGUgc2NvcGUgb2Ygb25lIG9mIHlv dSBkb2N1bWVudHMgYXQ8QlI+Jmd0OyBsZWFzdCwgc28gaSB3b3VsZCBmaW5kIHZlcnkgc3RyYW5n ZSB0aGF0IHRoZSBzYW1lIHdvcmsgaXMgY2hhcnRlcmVkIGluPEJSPiZndDsgdHdvIGRpZmZlcmVu dCB3b3JraW5nIGdyb3Vwcy48QlI+Jmd0OzxCUj4mZ3Q7IE1vcmVvdmVyLCB3ZSBkbyBoYXZlIHdn IGRvY3VtZW50cyBmb3IgdGhlc2UgdHdvLCBidXQgd2UgZmluZCB2ZXJ5IGhhcmQ8QlI+Jmd0OyB0 byBmaW5kIHJldmlld2VycyBmb3IgdGhvc2UsIHdoaWNoIG1ha2VzIG1lIHRoaW5rIHRoYXQgdGhl cmUgaXMgbm90PEJSPiZndDsgbXVjaCBpbnRlcmVzdCBvbiB0aGVzZS4gU28sIGlmIHlvdSBmaW5k IGEgbW9yZSBtb3RpdmF0ZWQgY3JldyB0byBkbzxCUj4mZ3Q7IHRoZSB3b3JrLCB0aGF0IHdvdWxk IGJlIGdyZWF0LCB3ZSBjYW4gZWl0aGVyIGRvIGl0IGluIG1leHQgb3I8QlI+Jmd0OyBzb2Vtd2hl cmUgZWxzZSwgaWYgcGVvcGxlIGZlZWxzIHRoYXQgbmVlZHMgdG8gYmUgZG9uZSwgYnV0IHRoYXQg aXM8QlI+Jmd0OyBjZXJ0YWlubHkgbm90IHRoZSBmZWVsaW5nIGkgYW0gZ2V0dGluZyBmcm9tIHRo ZSBpbnB1dCBpbiBtZXh0PEJSPiZndDs8QlI+Jmd0OyBSZWdhcmRzLCBtYXJjZWxvPEJSPiZndDs8 QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgSG9uZyBZb25nLUdldW4gZXNjcmliaT86PEJSPiZndDsm Z3Q7PEJSPiZndDsmZ3Q7IEhpLCBhbGwgaW4gTUVYVCBhbmQgbWlmLjxCUj4mZ3Q7Jmd0OzxCUj4m Z3Q7Jmd0OyZuYnNwOzxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBJbiBJRVRGIG1pZiAoTXVsdGlw bGUgSW50ZXJmYWNlKSBtYWlsaW5nIGxpc3Q8QlI+Jmd0OyZndDsgKF88QSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZl8iIHRhcmdldD1fYmxhbms+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWZfPC9BPjxCUj4mZ3Q7Jmd0OyAmbHQ7 PEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWYiIHRhcmdl dD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWY8L0E+Jmd0 OyksPEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IHdlIG5vdyBkaXNjdXNzIHRoZSBob3N0IHdoaWNo IHdvdWxkIGxpa2UgdG8gdXNlIG11bHRpcGxlIGludGVyZmFjZXMuPEJSPiZndDsmZ3Q7PEJSPiZn dDsmZ3Q7IEkgdW5kZXJzdGFuZCB0aGF0IE1FWFQgV0cgaXMgYWxzbyByZWxhdGVkIHRvIHRoZSB1 c2Ugb2YgbXVsdGlwbGU8QlI+Jmd0OyZndDsgaW50ZXJmYWNlcyBvZiBhIGhvc3Q8QlI+Jmd0OyZn dDsgdXNpbmcgTW9iaWxlIElQdjYgb3IgYSBtb2JpbGUgcm91dGVyIHVzaW5nIE5FTU8gQmFzaWMg U3VwcG9ydCBhbmQ8QlI+Jmd0OyZndDsgdGhlaXIgdmFyaWFudHM8QlI+Jmd0OyZndDs8QlI+Jmd0 OyZndDsgTUVYVCBXRyBpcyBmb2N1aW5nIG9uIG1vbmFtaTYgcmVsYXRlZCB0b3BpYyAobXVsdGlw bGUgQ29BLCBNdWx0aXBsZTxCUj4mZ3Q7Jmd0OyBIb0EsIGFuZCBNdWx0cGxlIEhBLCBldGMuLCk8 QlI+Jmd0OyZndDsgYW5kIGV4dGVkbmluZyBNb2JpbGUgSVB2NiBhbmQgTkVNTyBmb3IgdGhlc2Us IGJ1dCBtaWYgaXMgbm90IHJlbGF0ZWQ8QlI+Jmd0OyZndDsgdG8gdGhpcyBkaXJlY3Rpb24uPEJS PiZndDsmZ3Q7IEluIG1pZiwgc291cmNlIGFkZHJlc3Mgc2VsZWN0aW9uLCByb3V0aW5nIGFuZCBE TlMgY29udHJvbCBwcm90b2NvbDxCUj4mZ3Q7Jmd0OyBhcmUgY29uc2lkZXJhdGlvbiBpdGVtczxC Uj4mZ3Q7Jmd0OyBkdWUgdG8gbXVsdGlwbGUgaW50ZXJmYWNlcyBvZiBhIGhvc3QuPEJSPiZndDsm Z3Q7PEJSPiZndDsmZ3Q7Jm5ic3A7PEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IEZvciBtaWbigJlz IHNjb3BlLCBKYXJpIEFya2tvIG1hZGUgc29tZSBjb21tZW50cyBhbmQgY2xhc3NpZmljYXRpb24g b2Y8QlI+Jmd0OyZndDsgcHJvYmxlbXMuPEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IF88QSBocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWlmL2N1cnJlbnQvbXNnMDAw NTAuaHRtbF8iIHRhcmdldD1fYmxhbms+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL21pZi9jdXJyZW50L21zZzAwMDUwLmh0bWxfPC9BPjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0 OyBBbW9uZyB0aGVzZSBjbGFzc2lmaWNhdGlvbiB3aGljaCBpbmNsdWRlcyBhY2Nlc3Mgc2VsZWN0 aW9uLCBzcGxpdDxCUj4mZ3Q7Jmd0OyBETlMsIGNvbmZpZ3VyYXRpb24gcmVjb25jaWxpYXRpb24s PEJSPiZndDsmZ3Q7IHJvdXRpbmcsIGFkZHJlc3Mgc2VsZWN0aW9uLCB0dW5uZWwgbXVsdGlob21p bmcsIGFuZCB0aGUgY29tbXVuaWNhdGlvbjxCUj4mZ3Q7Jmd0OyB3YXkgYmV0d2VlbiB0aGUgaG9z dCBhbmQ8QlI+Jmd0OyZndDsgdGhlIG5ldHdvcmsgYWJvdXQgdGhlaXIgcG9saWNpZXMgcmVnYXJk aW5nIGFsbCBvZiB0aGUgYWJvdmUsIEphcmk8QlI+Jmd0OyZndDsgc2FpZCB0aGF0IGFjY2VzcyBz ZWxlY3Rpb24gaXMgYWxyZWFkeTxCUj4mZ3Q7Jmd0OyBjb3ZlcmQgaW4gUkZDIDUxMTMgYW5kIHR1 bm5lbCBtdWx0aWhvbWluZyBpcyBhbHJlYWR5IGNvdmVyZWQgaW4gTUVYVDxCUj4mZ3Q7Jmd0OyBX RyB3b3JrIGl0ZW1zLjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZuYnNwOzxCUj4mZ3Q7Jmd0OzxC Uj4mZ3Q7Jmd0OyBBdCBtb25hbWk2IFdHIGluIDY0dGggSUVURiBtZWV0aW5uZywgSSBzdWJtaXR0 ZWQgYW5kIHByZXNlbnRlZCB0d288QlI+Jmd0OyZndDsgSW50ZXJuZXQgRHJhZnRzLjxCUj4mZ3Q7 Jmd0OzxCUj4mZ3Q7Jmd0OyAtIEFuYWx5c2lzIG9mIG11bHRpcGxlIGludGVyZmFjZXMgaW4gYSBN b2JpbGUgTm9kZTxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBfPEEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2lkL2RyYWZ0LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1zdGF0ZW1lbnQtMDAudHh0 XyIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy1tdWx0 aXBsZWlmLW1uLXBiLXN0YXRlbWVudC0wMC50eHRfPC9BPjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0 OyAtIFZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgZm9yIG11bHRpcGxlIGludGVyZmFjZXMgaW4g YSBNb2JpbGUgbm9kZTxCUj4mZ3Q7Jmd0OyB1c2luZyBNb2JpbGUgSVB2NjxCUj4mZ3Q7Jmd0OzxC Uj4mZ3Q7Jmd0OyBfPEEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWhvbmct dmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dF8iIHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmll dGYub3JnL2lkL2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dF88L0E+PEJSPiZn dDsmZ3Q7ICZsdDs8QSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy12 aXJ0dWFsaWYtbW4tbWlwdjYtMDAudHh0IiB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9pZC9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni0wMC50eHQ8L0E+Jmd0OzxCUj4m Z3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBCZWNhdXNlIHRoZXNlIHR3byBkcmFmdHMgd2VyZSBub3QgaW4g dGhlIG1vbmFtaTYgV0figJlzIHNjb3BlIGFuZDxCUj4mZ3Q7Jmd0OyB2aXJ0dWFsIG5ldHdvcmsg aW50ZXJmYWNlIGRyYWZ0IHdhczxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBpbXBsZW1lbnRhdGlv biBzcGVjaWZpYywgdGhlcmUgd2VyZSBub3QgYWRvcGVkIGluIG1vbmFtaTYgV0figJlzIHdvcms8 QlI+Jmd0OyZndDsgaXRlbXMuIFRoZSBpbnRlbnRpb25zIG9mIHR3byBkcmFmdHM8QlI+Jmd0OyZn dDsgYXJlIHN1cHBvcnRpbmcgbXVsdGlwbGUgaW50ZXJmYWNlcyBvZiBhIGhvc3Qgd2l0aG91dCBl eHRlbmRpbmcgTW9iaWxlPEJSPiZndDsmZ3Q7IElQdjYvTkVNTy48QlI+Jmd0OyZndDs8QlI+Jmd0 OyZndDsmbmJzcDs8QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsgSSB0aGluayB0aGF0IG11bHRpcGxl IGludGVyZmFjZXMgcHJvYmxlbXMgb2YgYSBob3N0IGFyZSByZWxhdGVkIHRvPEJSPiZndDsmZ3Q7 IGJvdGggTW9iaWxlIElQL05FTU8gc3BlY2lmaWMgaXNzdWVzIGFuZDxCUj4mZ3Q7Jmd0OyBnZW5l cmFsIG5ldHdvcmsgaXNzdWVzLiBNb2JpbGUgSVAvTkVNTyBzcGVjaWZpYyBpc3N1ZXMgYXJlIHJl bGF0ZWQgdG88QlI+Jmd0OyZndDsgZXh0ZW5kaW5nIG9mIE1vYmlsZSBJUC9ORU1PIGFuZDxCUj4m Z3Q7Jmd0OyB0aGVzZSBhcmUgYWxyZWFkeSBzdHVkaWVkIGluIE1FWFQgV0cgYW5kIGdlbmVyYWwg bmV0d29yayBpc3N1ZXMgd2hpY2g8QlI+Jmd0OyZndDsgd2VyZSBub3QgcmVsYXRlZCB0bzxCUj4m Z3Q7Jmd0OyBNb2JpbGUgSVAvTkVNTyBjb3VsZCBiZSBzdHVkaWVkIGluIG1pZi4gQXMgc2FtZSBt YW5uZXIsIEkgdGhpbmsgdGhhdDxCUj4mZ3Q7Jmd0OyBteSBkcmFmdHMgY291bGQgYmUgZGlzY3Vz c2VkIGFuZDxCUj4mZ3Q7Jmd0OyBkZXZlbG9wZWQgaW4gbWlmLiBJbiB0aGUgZmlyc3QgZHJhZnQg KEFuYWx5c2lzIGRvY3VtZW50KSwgSTxCUj4mZ3Q7Jmd0OyBjbGFzc2lmaWVkIG11bHRpcGxlIGlu dGVyZmFjZSBwcm9ibGVtcyBpbnRvPEJSPiZndDsmZ3Q7IE1vYmlsZSBJUHY2LXNlcGNpZmljIGlz c3VlcywgR2VuZXJhbCBuZXR3b3JrIGlzc3VlcywgYW5kPEJSPiZndDsmZ3Q7IGhldGVyb2dlbmVv dXMgZW52aXJvbm1lbnQgaXNzdWVzLjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZuYnNwOzxCUj4m Z3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBJbmNsdWRpbmcgSHVpIERlbmcgaW4gbWlmLCB3aXRoIHJlZ2Fy ZGluZyB0byB0aGVzZSBkcmFmdHMsIHRoZXkgd2FudDxCUj4mZ3Q7Jmd0OyB0byBoZWFyIGNvbW1l bnRzIGZyb20gTUVYVCBXR+KAmXMgcG9pbnQgb2Ygdmlldyw8QlI+Jmd0OyZndDsgYmVjYXVzZSBp dCBzZWVtcyB0aGF0IHRoZXNlIGRyYWZ0cyBhcmUgcXVpdGUgcmVsYXRlZCB0byBtb25hbWk2L01F WFQ8QlI+Jmd0OyZndDsgV0cuIFNvLCBJIGFzayBNRVhUIHRvIHJldmlldyB3aGV0aGVyIHRoZXJl IGFyZTxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBzb21lIG92ZXJsYXAgYmV0d2VlbiBNRVhUIHdv cmtzIGFuZCBteSBkcmFmdHMgb3Igbm90LjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBJdCBpcyBh cHByZWNpYXRlIHRvIGdpdmUgY29tbWVudHMuPEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jm5ic3A7 PEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IEJlc3QgcmVnYXJkcy48QlI+Jmd0OyZndDs8QlI+Jmd0 OyZndDsgWW9uZy1HZXVuLjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyBNRVhUIG1haWxpbmcg bGlzdDxCUj4mZ3Q7IE1FWFRAaWV0Zi5vcmc8QlI+Jmd0OyA8QSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21leHQiIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0PC9BPjxCUj48QlI+PC9GT05UPjwvUD48L0RJ Vj48L0RJVj48L0RJVj48aW1nIHN0eWxlPSJkaXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVpZ2h0PTAg c3JjPSJodHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNweD9lbWFp bD1tZXh0QGlldGYub3JnJm5hbWU9bWV4dCU0MGlldGYub3JnJmZyb21lbWFpbD15Z2hvbmdAZXRy aS5yZS5rciZtZXNzYWdlaWQ9JTNDNjI3MDI5MTEtMmQ0NS00YjM4LTkwNjQtMTMyNmRmODA0NGZh QGV0cmkucmUua3IlM0UiPg== ------=_NextPart_000_581D_01C98207.1BAEC3F0-- --===============1369434789== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1369434789==-- From mext-bounces@ietf.org Wed Jan 28 23:58:20 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A6B3A6905; Wed, 28 Jan 2009 23:58:19 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A41153A6905; Wed, 28 Jan 2009 23:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, FRT_MEETING=2.697, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49b0vF5ry-yf; Wed, 28 Jan 2009 23:58:17 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id DA5053A682E; Wed, 28 Jan 2009 23:58:16 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.142.187]) by smtp01.uc3m.es (Postfix) with ESMTP id 0246BB4D439; Thu, 29 Jan 2009 08:57:55 +0100 (CET) Message-ID: <49816184.1080502@it.uc3m.es> Date: Thu, 29 Jan 2009 08:57:56 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Hong Yong-Geun References: <544a01c981ba$81512a10$8310fe81@etri.info> In-Reply-To: <544a01c981ba$81512a10$8310fe81@etri.info> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16430.005 Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [MEXT] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org SGkgSG9uZywKCndoYXQgaXMgdGhlIHNjb3BlIG9mIE1JRj8KSSBtZWFuLCBpbiB0aGUgYm9mIHdp a2kgcGFnZSB0aGVyZSBpcyBubyBjaGFydGVyIHByb3Bvc2VkLCBpcyB0aGVyZSBhIApjaGFydGVy IHNvbWV3aGVyZT8KSW4gcGFydGljdWxhciwgaXMgTUlGIGdvaW5nIHRvIHdvcmsgaW4gTUlQdjYv TkVNTyByZWxhdGVkIGlzc3Vlcz8KClJlZ2FyZHMsIG1hcmNlbG8KCgpIb25nIFlvbmctR2V1biBl c2NyaWJpw7M6Cj4gIAo+IEhpLCBNYXJjZWxvLgo+ICAKPiBUaGFua3MgZm9yIHlvdXIgY29tbWVu dHMuCj4gIAo+IEkgYWdyZWUgdGhhdCAgdGhlIGN1cnJlbnQgTUVYVCBXRyBjaGFydGVyIGFscmVh ZHkgaGFzIHNldmVyYWwgaXRlbXMgCj4gYWJvdXQgc3VwcG9ydGluZyBtdWx0aXBsZSBpbnRlcmZh Y2VzLgo+ICAKPiBNeSBkb2N1bWVudHMgYXJlIG9sZCB2ZXJzaW9uIHdoaWNoIHdlcmUgc3VibWl0 dGVkIHRvIG1vbmFtaTYgV0cgYXQgCj4gNjR0aCBJRVRGIG1lZXRpbmcgYW5kIHRoZXkgd2VyZQo+ IG5vdCB1cGRhdGVkIHByb3Blcmx5LiBTbywgaXQgc2VlbXMgdGhhdCBzb21lIGNvbnRlbnRzIGFy ZSBzaW1pbGFyIHRvIAo+IHRoZSB3b3JrcyBpbiBNRVhUIFdHLgo+IEkgd2lsbCB1cGRhdGUgbXkg ZG9jdW1lbnRzIHRvIGZvY3VzIG9uIG1pZidzIHNjb3BlLgo+ICAKPiBJdCBpcyBhcHByZWNpYXRl IHRvIHVuZGVyc3RhbmQgdGhhdCAoZXZlbiB0aG91Z2ggdGhlIHNjb3BlIG9mIG1pZiBpcyAKPiBu b3QgZml4ZWQpIG1pZiBoYXMgZGlmZmVyZW50IGRpcmVjdGlvbnMgdG8KPiBNRVhULgo+ICAKPiBC ZXN0IHJlZ2FyZHMuCj4gIAo+IFlvbmctR2V1bi4KPgo+IC0tLS0t7JuQ67O4IOuplOyLnOyngC0t LS0tCj4gKkZyb206KiAibWFyY2VsbyBiYWdudWxvIGJyYXVuIiA8bWFyY2Vsb0BpdC51YzNtLmVz Pgo+ICpGcm9tIERhdGU6KiAyMDA5LTAxLTI4IOyYpO2bhCA2OjQwOjA5Cj4gKlRvOiogIkhvbmcg WW9uZy1HZXVuIiA8eWdob25nQGV0cmkucmUua3I+Cj4gKkNjOiogIm1leHRAaWV0Zi5vcmciIDxt ZXh0QGlldGYub3JnPiwgIm1pZkBpZXRmLm9yZyIgPG1pZkBpZXRmLm9yZz4sIAo+ICJqdWxpZW4u bGFnYW5pZXIuSUVURkBnb29nbGVtYWlsLmNvbSIgCj4gPGp1bGllbi5sYWdhbmllci5JRVRGQGdv b2dsZW1haWwuY29tPiwgImRlbmdodWkwMkBnbWFpbC5jb20iIAo+IDxkZW5naHVpMDJAZ21haWwu Y29tPgo+ICpTdWJqZWN0OiogUmU6IE11bHRpcGxlIGludGVyZmFjZXMgcHJvYmxlbXMgaW4gTUVY VCBhbmQgbWlmCj4KPgo+IEhpLAo+Cj4gSW4gdGhlIGN1cnJlbnQgTUVYVCBjaGFydGVyIHRoZXJl IGFyZSBzZXZlcmFsIGl0ZW1zIGFib3V0IHN1cHBvcnRpbmcKPiBtdWx0aXBsZSBpbnRlcmZhY2Vz LCBpbmNsdWRpbmcgdGhlIGZvbGxvd2luZyB0d286Cj4KPiAtIEEgZG9jdW1lbnQgZXhwbGFpbmlu ZyB0aGUgbW90aXZhdGlvbnMgZm9yIGEgbm9kZSB1c2luZyBtdWx0aXBsZQo+IGludGVyZmFjZXMg YW5kIHRoZSBzY2VuYXJpb3Mgd2hlcmUgaXQgbWF5IGVuZCB1cCB3aXRoIG11bHRpcGxlCj4gZ2xv YmFsIGFkZHJlc3NlcyBvbiBpdHMgaW50ZXJmYWNlcyBbSW5mb3JtYXRpb25hbF0KPgo+IC0gQW4g YW5hbHlzaXMgZG9jdW1lbnQgZXhwbGFpbmluZyB3aGF0IGFyZSB0aGUgbGltaXRhdGlvbnMgZm9y Cj4gbW9iaWxlIGhvc3RzIHVzaW5nIG11bHRpcGxlIHNpbXVsdGFuZW91cyBDYXJlLW9mIEFkZHJl c3NlcyBhbmQgSG9tZQo+IEFnZW50IGFkZHJlc3NlcyB1c2luZyBNb2JpbGUgSVB2Niwgd2hldGhl ciBpc3N1ZXMgYXJlIHNwZWNpZmljIHRvCj4gTW9iaWxlIElQdjYgb3Igbm90IFtJbmZvcm1hdGlv bmFsXS4KPgo+IEkgdGhpbmsgdGhpcyBpcyB2ZXJ5IHNpbWlsYXIgdG8gdGhlIHNjb3BlIG9mIG9u ZSBvZiB5b3UgZG9jdW1lbnRzIGF0Cj4gbGVhc3QsIHNvIGkgd291bGQgZmluZCB2ZXJ5IHN0cmFu Z2UgdGhhdCB0aGUgc2FtZSB3b3JrIGlzIGNoYXJ0ZXJlZCBpbgo+IHR3byBkaWZmZXJlbnQgd29y a2luZyBncm91cHMuCj4KPiBNb3Jlb3Zlciwgd2UgZG8gaGF2ZSB3ZyBkb2N1bWVudHMgZm9yIHRo ZXNlIHR3bywgYnV0IHdlIGZpbmQgdmVyeSBoYXJkCj4gdG8gZmluZCByZXZpZXdlcnMgZm9yIHRo b3NlLCB3aGljaCBtYWtlcyBtZSB0aGluayB0aGF0IHRoZXJlIGlzIG5vdCBtdWNoCj4gaW50ZXJl c3Qgb24gdGhlc2UuIFNvLCBpZiB5b3UgZmluZCBhIG1vcmUgbW90aXZhdGVkIGNyZXcgdG8gZG8g dGhlIHdvcmssCj4gdGhhdCB3b3VsZCBiZSBncmVhdCwgd2UgY2FuIGVpdGhlciBkbyBpdCBpbiBt ZXh0IG9yIHNvZW13aGVyZSBlbHNlLCBpZgo+IHBlb3BsZSBmZWVscyB0aGF0IG5lZWRzIHRvIGJl IGRvbmUsIGJ1dCB0aGF0IGlzIGNlcnRhaW5seSBub3QgdGhlCj4gZmVlbGluZyBpIGFtIGdldHRp bmcgZnJvbSB0aGUgaW5wdXQgaW4gbWV4dAo+Cj4gUmVnYXJkcywgbWFyY2Vsbwo+Cj4KPgo+IEhv bmcgWW9uZy1HZXVuIGVzY3JpYmk/Ogo+ID4KPiA+IEhpLCBhbGwgaW4gTUVYVCBhbmQgbWlmLgo+ ID4KPiA+IAo+ID4KPiA+IEluIElFVEYgbWlmIChNdWx0aXBsZSBJbnRlcmZhY2UpIG1haWxpbmcg bGlzdAo+ID4gKF9odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZl8KPiA+ IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZj4pLAo+ID4KPiA+IHdl IG5vdyBkaXNjdXNzIHRoZSBob3N0IHdoaWNoIHdvdWxkIGxpa2UgdG8gdXNlIG11bHRpcGxlIGlu dGVyZmFjZXMuCj4gPgo+ID4gSSB1bmRlcnN0YW5kIHRoYXQgTUVYVCBXRyBpcyBhbHNvIHJlbGF0 ZWQgdG8gdGhlIHVzZSBvZiBtdWx0aXBsZQo+ID4gaW50ZXJmYWNlcyBvZiBhIGhvc3QKPiA+IHVz aW5nIE1vYmlsZSBJUHY2IG9yIGEgbW9iaWxlIHJvdXRlciB1c2luZyBORU1PIEJhc2ljIFN1cHBv cnQgYW5kCj4gPiB0aGVpciB2YXJpYW50cwo+ID4KPiA+IE1FWFQgV0cgaXMgZm9jdWluZyBvbiBt b25hbWk2IHJlbGF0ZWQgdG9waWMgKG11bHRpcGxlIENvQSwgTXVsdGlwbGUKPiA+IEhvQSwgYW5k IE11bHRwbGUgSEEsIGV0Yy4sKQo+ID4gYW5kIGV4dGVkbmluZyBNb2JpbGUgSVB2NiBhbmQgTkVN TyBmb3IgdGhlc2UsIGJ1dCBtaWYgaXMgbm90IHJlbGF0ZWQKPiA+IHRvIHRoaXMgZGlyZWN0aW9u Lgo+ID4gSW4gbWlmLCBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24sIHJvdXRpbmcgYW5kIEROUyBj b250cm9sIHByb3RvY29sIGFyZQo+ID4gY29uc2lkZXJhdGlvbiBpdGVtcwo+ID4gZHVlIHRvIG11 bHRpcGxlIGludGVyZmFjZXMgb2YgYSBob3N0Lgo+ID4KPiA+IAo+ID4KPiA+IEZvciBtaWbigJlz IHNjb3BlLCBKYXJpIEFya2tvIG1hZGUgc29tZSBjb21tZW50cyBhbmQgY2xhc3NpZmljYXRpb24g b2YKPiA+IHByb2JsZW1zLgo+ID4KPiA+IF9odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbWlmL2N1cnJlbnQvbXNnMDAwNTAuaHRtbF8KPiA+Cj4gPiBBbW9uZyB0aGVzZSBjbGFz c2lmaWNhdGlvbiB3aGljaCBpbmNsdWRlcyBhY2Nlc3Mgc2VsZWN0aW9uLCBzcGxpdCBETlMsCj4g PiBjb25maWd1cmF0aW9uIHJlY29uY2lsaWF0aW9uLAo+ID4gcm91dGluZywgYWRkcmVzcyBzZWxl Y3Rpb24sIHR1bm5lbCBtdWx0aWhvbWluZywgYW5kIHRoZSBjb21tdW5pY2F0aW9uCj4gPiB3YXkg YmV0d2VlbiB0aGUgaG9zdCBhbmQKPiA+IHRoZSBuZXR3b3JrIGFib3V0IHRoZWlyIHBvbGljaWVz IHJlZ2FyZGluZyBhbGwgb2YgdGhlIGFib3ZlLCBKYXJpIHNhaWQKPiA+IHRoYXQgYWNjZXNzIHNl bGVjdGlvbiBpcyBhbHJlYWR5Cj4gPiBjb3ZlcmQgaW4gUkZDIDUxMTMgYW5kIHR1bm5lbCBtdWx0 aWhvbWluZyBpcyBhbHJlYWR5IGNvdmVyZWQgaW4gTUVYVAo+ID4gV0cgd29yayBpdGVtcy4KPiA+ Cj4gPiAKPiA+Cj4gPiBBdCBtb25hbWk2IFdHIGluIDY0dGggSUVURiBtZWV0aW5uZywgSSBzdWJt aXR0ZWQgYW5kIHByZXNlbnRlZCB0d28KPiA+IEludGVybmV0IERyYWZ0cy4KPiA+Cj4gPiAtIEFu YWx5c2lzIG9mIG11bHRpcGxlIGludGVyZmFjZXMgaW4gYSBNb2JpbGUgTm9kZQo+ID4KPiA+IF9o dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy1tdWx0aXBsZWlmLW1uLXBiLXN0YXRl bWVudC0wMC50eHRfCj4gPgo+ID4gLSBWaXJ0dWFsIG5ldHdvcmsgaW50ZXJmYWNlIGZvciBtdWx0 aXBsZSBpbnRlcmZhY2VzIGluIGEgTW9iaWxlIG5vZGUKPiA+IHVzaW5nIE1vYmlsZSBJUHY2Cj4g Pgo+ID4gX2h0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1t aXB2Ni0wMC50eHRfCj4gPiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWhvbmctdmly dHVhbGlmLW1uLW1pcHY2LTAwLnR4dD4KPiA+Cj4gPiBCZWNhdXNlIHRoZXNlIHR3byBkcmFmdHMg d2VyZSBub3QgaW4gdGhlIG1vbmFtaTYgV0figJlzIHNjb3BlIGFuZAo+ID4gdmlydHVhbCBuZXR3 b3JrIGludGVyZmFjZSBkcmFmdCB3YXMKPiA+Cj4gPiBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYywg dGhlcmUgd2VyZSBub3QgYWRvcGVkIGluIG1vbmFtaTYgV0figJlzIHdvcmsKPiA+IGl0ZW1zLiBU aGUgaW50ZW50aW9ucyBvZiB0d28gZHJhZnRzCj4gPiBhcmUgc3VwcG9ydGluZyBtdWx0aXBsZSBp bnRlcmZhY2VzIG9mIGEgaG9zdCB3aXRob3V0IGV4dGVuZGluZyBNb2JpbGUKPiA+IElQdjYvTkVN Ty4KPiA+Cj4gPiAKPiA+Cj4gPiBJIHRoaW5rIHRoYXQgbXVsdGlwbGUgaW50ZXJmYWNlcyBwcm9i bGVtcyBvZiBhIGhvc3QgYXJlIHJlbGF0ZWQgdG8KPiA+IGJvdGggTW9iaWxlIElQL05FTU8gc3Bl Y2lmaWMgaXNzdWVzIGFuZAo+ID4gZ2VuZXJhbCBuZXR3b3JrIGlzc3Vlcy4gTW9iaWxlIElQL05F TU8gc3BlY2lmaWMgaXNzdWVzIGFyZSByZWxhdGVkIHRvCj4gPiBleHRlbmRpbmcgb2YgTW9iaWxl IElQL05FTU8gYW5kCj4gPiB0aGVzZSBhcmUgYWxyZWFkeSBzdHVkaWVkIGluIE1FWFQgV0cgYW5k IGdlbmVyYWwgbmV0d29yayBpc3N1ZXMgd2hpY2gKPiA+IHdlcmUgbm90IHJlbGF0ZWQgdG8KPiA+ IE1vYmlsZSBJUC9ORU1PIGNvdWxkIGJlIHN0dWRpZWQgaW4gbWlmLiBBcyBzYW1lIG1hbm5lciwg SSB0aGluayB0aGF0Cj4gPiBteSBkcmFmdHMgY291bGQgYmUgZGlzY3Vzc2VkIGFuZAo+ID4gZGV2 ZWxvcGVkIGluIG1pZi4gSW4gdGhlIGZpcnN0IGRyYWZ0IChBbmFseXNpcyBkb2N1bWVudCksIEkg Y2xhc3NpZmllZAo+ID4gbXVsdGlwbGUgaW50ZXJmYWNlIHByb2JsZW1zIGludG8KPiA+IE1vYmls ZSBJUHY2LXNlcGNpZmljIGlzc3VlcywgR2VuZXJhbCBuZXR3b3JrIGlzc3VlcywgYW5kIGhldGVy b2dlbmVvdXMKPiA+IGVudmlyb25tZW50IGlzc3Vlcy4KPiA+Cj4gPiAKPiA+Cj4gPiBJbmNsdWRp bmcgSHVpIERlbmcgaW4gbWlmLCB3aXRoIHJlZ2FyZGluZyB0byB0aGVzZSBkcmFmdHMsIHRoZXkg d2FudAo+ID4gdG8gaGVhciBjb21tZW50cyBmcm9tIE1FWFQgV0figJlzIHBvaW50IG9mIHZpZXcs Cj4gPiBiZWNhdXNlIGl0IHNlZW1zIHRoYXQgdGhlc2UgZHJhZnRzIGFyZSBxdWl0ZSByZWxhdGVk IHRvIG1vbmFtaTYvTUVYVAo+ID4gV0cuIFNvLCBJIGFzayBNRVhUIHRvIHJldmlldyB3aGV0aGVy IHRoZXJlIGFyZQo+ID4KPiA+IHNvbWUgb3ZlcmxhcCBiZXR3ZWVuIE1FWFQgd29ya3MgYW5kIG15 IGRyYWZ0cyBvciBub3QuCj4gPgo+ID4gSXQgaXMgYXBwcmVjaWF0ZSB0byBnaXZlIGNvbW1lbnRz Lgo+ID4KPiA+IAo+ID4KPiA+IEJlc3QgcmVnYXJkcy4KPiA+Cj4gPiBZb25nLUdldW4uCj4gPgo+ CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNRVhUIG1h aWxpbmcgbGlzdApNRVhUQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWV4dAo= From mext-bounces@ietf.org Thu Jan 29 02:11:25 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF1303A6A22; Thu, 29 Jan 2009 02:11:25 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E873A6A22; Thu, 29 Jan 2009 02:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, FRT_MEETING=2.697, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id If0GXzCC5Z3Z; Thu, 29 Jan 2009 02:11:23 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id A8C2D3A6359; Thu, 29 Jan 2009 02:11:22 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so8386746wfd.31 for ; Thu, 29 Jan 2009 02:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=iGEjR7U2tbWUOKmSCwLrBPxGKLhut87v9UDvg5mfLd0=; b=Yd4l+o6+nM70N9dlk5M3DSf9PB+vcqDAZIHx7HIR006oEYmtjZb4+9Wb5oQOL3VDRx OlpcUrLVcv91pclp9/vYdkPUKikk70EjhsKQLa75+Tj3O7mc5/uGKTUQP03luCc5Mzml 0jyG6uiT15UXSJMsz7BszTPIlRdLXts7ZjtjI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pCJw6PSM84vmMrSVB9YZt5F5GafM6JqRkxLEMFPHpqJmEY1JPjHtOEcT/7SduPr3bg TNxN80ZvFwmYXnsVBOT/zi4Fudvh16AfJVZ6roUWCvIjd3EJwgwLLZgkRhDAYp1DmIVe fuN3S/FAlTaO4NAT4iZ/U6zcfF4CKIxi9ddAg= MIME-Version: 1.0 Received: by 10.142.191.5 with SMTP id o5mr572268wff.326.1233223864590; Thu, 29 Jan 2009 02:11:04 -0800 (PST) In-Reply-To: <49816184.1080502@it.uc3m.es> References: <544a01c981ba$81512a10$8310fe81@etri.info> <49816184.1080502@it.uc3m.es> Date: Thu, 29 Jan 2009 18:11:04 +0800 Message-ID: <1d38a3350901290211g2bab9cfdhaa760405151bb3bc@mail.gmail.com> From: Hui Deng To: marcelo bagnulo braun Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [MEXT] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1045685914==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1045685914== Content-Type: multipart/alternative; boundary=000e0cd28df260a2d204619c4e9a --000e0cd28df260a2d204619c4e9a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Marcelo For yoru question about what mif's scope at the moment, Jari already made the comments on http://www.ietf.org/mail-archive/web/mif/current/msg00050.html There are also several PS drafts you could refer to: http://tools.ietf.org/id/draft-blanchet-mif-problem-statement-00.txt http://tools.ietf.org/id/draft-hui-ip-multiple-connections-ps-01.txt http://tools.ietf.org/id/draft-hong-multipleif-mn-pb-statement-00.txt thanks -Hui 2009/1/29 marcelo bagnulo braun > Hi Hong, > > what is the scope of MIF? > I mean, in the bof wiki page there is no charter proposed, is there a > charter somewhere? > In particular, is MIF going to work in MIPv6/NEMO related issues? > > Regards, marcelo > > > Hong Yong-Geun escribi=C3=B3: > >> Hi, Marcelo. >> Thanks for your comments. >> I agree that the current MEXT WG charter already has several items abo= ut >> supporting multiple interfaces. >> My documents are old version which were submitted to monami6 WG at 64th >> IETF meeting and they were >> not updated properly. So, it seems that some contents are similar to the >> works in MEXT WG. >> I will update my documents to focus on mif's scope. >> It is appreciate to understand that (even though the scope of mif is no= t >> fixed) mif has different directions to >> MEXT. >> Best regards. >> Yong-Geun. >> >> -----=EC=9B=90=EB=B3=B8 =EB=A9=94=EC=8B=9C=EC=A7=80----- >> *From:* "marcelo bagnulo braun" >> *From Date:* 2009-01-28 =EC=98=A4=ED=9B=84 6:40:09 >> *To:* "Hong Yong-Geun" >> *Cc:* "mext@ietf.org" , "mif@ietf.org" , " >> julien.laganier.IETF@googlemail.com" , >> "denghui02@gmail.com" >> *Subject:* Re: Multiple interfaces problems in MEXT and mif >> >> >> >> Hi, >> >> In the current MEXT charter there are several items about supporting >> multiple interfaces, including the following two: >> >> - A document explaining the motivations for a node using multiple >> interfaces and the scenarios where it may end up with multiple >> global addresses on its interfaces [Informational] >> >> - An analysis document explaining what are the limitations for >> mobile hosts using multiple simultaneous Care-of Addresses and Home >> Agent addresses using Mobile IPv6, whether issues are specific to >> Mobile IPv6 or not [Informational]. >> >> I think this is very similar to the scope of one of you documents at >> least, so i would find very strange that the same work is chartered in >> two different working groups. >> >> Moreover, we do have wg documents for these two, but we find very hard >> to find reviewers for those, which makes me think that there is not much >> interest on these. So, if you find a more motivated crew to do the work, >> that would be great, we can either do it in mext or soemwhere else, if >> people feels that needs to be done, but that is certainly not the >> feeling i am getting from the input in mext >> >> Regards, marcelo >> >> >> >> Hong Yong-Geun escribi?: >> > >> > Hi, all in MEXT and mif. >> > >> > > >> > In IETF mif (Multiple Interface) mailing list >> > (_https://www.ietf.org/mailman/listinfo/mif_ >> > ), >> > >> > we now discuss the host which would like to use multiple interfaces. >> > >> > I understand that MEXT WG is also related to the use of multiple >> > interfaces of a host >> > using Mobile IPv6 or a mobile router using NEMO Basic Support and >> > their variants >> > >> > MEXT WG is focuing on monami6 related topic (multiple CoA, Multiple >> > HoA, and Multple HA, etc.,) >> > and extedning Mobile IPv6 and NEMO for these, but mif is not related >> > to this direction. >> > In mif, source address selection, routing and DNS control protocol are >> > consideration items >> > due to multiple interfaces of a host. >> > >> > > >> > For mif's scope, Jari Arkko made some comments and classification of >> > problems. >> > >> > _http://www.ietf.org/mail-archive/web/mif/current/msg00050.html_ >> > >> > Among these classification which includes access selection, split DNS, >> > configuration reconciliation, >> > routing, address selection, tunnel multihoming, and the communication >> > way between the host and >> > the network about their policies regarding all of the above, Jari said >> > that access selection is already >> > coverd in RFC 5113 and tunnel multihoming is already covered in MEXT >> > WG work items. >> > >> > > >> > At monami6 WG in 64th IETF meetinng, I submitted and presented two >> > Internet Drafts. >> > >> > - Analysis of multiple interfaces in a Mobile Node >> > >> > _http://tools.ietf.org/id/draft-hong-multipleif-mn-pb-statement-00.txt= _ >> > >> > - Virtual network interface for multiple interfaces in a Mobile node >> > using Mobile IPv6 >> > >> > _http://tools.ietf.org/id/draft-hong-virtualif-mn-mipv6-00.txt_ >> > >> > >> > Because these two drafts were not in the monami6 WG's scope and >> > virtual network interface draft was >> > >> > implementation specific, there were not adoped in monami6 WG's work >> > items. The intentions of two drafts >> > are supporting multiple interfaces of a host without extending Mobile >> > IPv6/NEMO. >> > >> > > >> > I think that multiple interfaces problems of a host are related to >> > both Mobile IP/NEMO specific issues and >> > general network issues. Mobile IP/NEMO specific issues are related to >> > extending of Mobile IP/NEMO and >> > these are already studied in MEXT WG and general network issues which >> > were not related to >> > Mobile IP/NEMO could be studied in mif. As same manner, I think that >> > my drafts could be discussed and >> > developed in mif. In the first draft (Analysis document), I classified >> > multiple interface problems into >> > Mobile IPv6-sepcific issues, General network issues, and heterogeneous >> > environment issues. >> > >> > > >> > Including Hui Deng in mif, with regarding to these drafts, they want >> > to hear comments from MEXT WG's point of view, >> > because it seems that these drafts are quite related to monami6/MEXT >> > WG. So, I ask MEXT to review whether there are >> > >> > some overlap between MEXT works and my drafts or not. >> > >> > It is appreciate to give comments. >> > >> > > >> > Best regards. >> > >> > Yong-Geun. >> > >> >> > --000e0cd28df260a2d204619c4e9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi, Marcelo

For yoru question about what mif's scope at the moment, Jari already= made the comments on
http://www.ietf.org/mail-archive/web/mif/current/m= sg00050.html

There are also several PS drafts you could refer to:
http://too= ls.ietf.org/id/draft-blanchet-mif-problem-statement-00.txt
h= ttp://tools.ietf.org/id/draft-hui-ip-multiple-connections-ps-01.txt
http://tools.ietf.org/id/draft-hong-multipleif-mn-pb-statement-00.tx= t

thanks

-Hui

2009/1/29 marcelo bagnulo braun <marcelo@it.uc3m.es>
Hi Hong,

what is the scop= e of MIF?
I mean, in the bof wiki page there is no charter proposed, is = there a charter somewhere?
In particular, is MIF going to work in MIPv6/NEMO related issues?

Re= gards, marcelo


Hong Yong-Geun escribi=C3=B3:
 Hi, Marcelo.
 Than= ks for your comments.
 I agree that  the current MEXT WG chart= er already has several items about supporting multiple interfaces.=20

 My documents are old version which were sub= mitted to monami6 WG at 64th IETF meeting and they were
not updated prop= erly. So, it seems that some contents are similar to the works in MEXT WG.<= br> I will update my documents to focus on mif's scope.
 It is appr= eciate to understand that (even though the scope of mif is not fixed) mif h= as different directions to
MEXT.
 Best regards.
 Yong-Geun.

-----= =EC=9B=90=EB=B3=B8 =EB=A9=94=EC=8B=9C=EC=A7=80-----
*From:* "= marcelo bagnulo braun" <marcelo@it.uc3m.es>
*From Date:* 2009-01-28 =EC=98= =A4=ED=9B=84 6:40:09
*To:* "Hong Yong-Geun" <yghong@etri.re.kr>
*Cc:* "mext@ietf.org" <mext@ietf.org>, "mif@ietf.org" <mif@ietf.org>, "juli= en.laganier.IETF@googlemail.com" <julien.laganier.IETF@googlemail= .com>, "denghui02@gmail.com" <denghui02@gmail.com>
*Subject:* Re: Multiple interfaces problems in MEXT and mif=20



Hi,

In the current MEXT charter th= ere are several items about supporting
multiple interfaces, including th= e following two:

- A document explaining the motivations for a node = using multiple
interfaces and the scenarios where it may end up with multiple
global ad= dresses on its interfaces [Informational]

- An analysis document exp= laining what are the limitations for
mobile hosts using multiple simulta= neous Care-of Addresses and Home
Agent addresses using Mobile IPv6, whether issues are specific to
Mobile= IPv6 or not [Informational].

I think this is very similar to the sc= ope of one of you documents at
least, so i would find very strange that = the same work is chartered in
two different working groups.

Moreover, we do have wg documents for = these two, but we find very hard
to find reviewers for those, which make= s me think that there is not much
interest on these. So, if you find a m= ore motivated crew to do the work,
that would be great, we can either do it in mext or soemwhere else, if
p= eople feels that needs to be done, but that is certainly not the
feeling= i am getting from the input in mext

Regards, marcelo



Hong Yong-Geun escribi?:
>
> Hi, all in MEXT and mif.
&g= t;
> >
> In IETF mif (Multiple Interface) mailing list
&g= t; (_https://www.ietf.org/mailman/listinfo/mif_
> <https://www.ietf.org/mailman/listinfo/mif>),
>
> w= e now discuss the host which would like to use multiple interfaces.
>=
> I understand that MEXT WG is also related to the use of multiple
&g= t; interfaces of a host
> using Mobile IPv6 or a mobile router using = NEMO Basic Support and
> their variants
>
> MEXT WG is fo= cuing on monami6 related topic (multiple CoA, Multiple
> HoA, and Multple HA, etc.,)
> and extedning Mobile IPv6 and NEMO= for these, but mif is not related
> to this direction.
> In mi= f, source address selection, routing and DNS control protocol are
> c= onsideration items
> due to multiple interfaces of a host.
>
> >
> For= mif's scope, Jari Arkko made some comments and classification of
> p= roblems.
>
> _http://www.ietf.org/mail-archi= ve/web/mif/current/msg00050.html_
>
> Among these classification which includes access selection, sp= lit DNS,
> configuration reconciliation,
> routing, address sel= ection, tunnel multihoming, and the communication
> way between the h= ost and
> the network about their policies regarding all of the above, Jari said=
> that access selection is already
> coverd in RFC 5113 and tu= nnel multihoming is already covered in MEXT
> WG work items.
><= br> > >
> At monami6 WG in 64th IETF meetinng, I submitted and pres= ented two
> Internet Drafts.
>
> - Analysis of multiple i= nterfaces in a Mobile Node
>
> _http:= //tools.ietf.org/id/draft-hong-multipleif-mn-pb-statement-00.txt_
>
> - Virtual network interface for multiple interfaces in a Mobil= e node
> using Mobile IPv6
>
> _http://= tools.ietf.org/id/draft-hong-virtualif-mn-mipv6-00.txt_
> <http://tools.ietf.org/id/draft-hong-virtualif-mn-= mipv6-00.txt>
>
> Because these two drafts were not in t= he monami6 WG's scope and
> virtual network interface draft was
>
> implementation spe= cific, there were not adoped in monami6 WG's work
> items. The intent= ions of two drafts
> are supporting multiple interfaces of a host wit= hout extending Mobile
> IPv6/NEMO.
>
> >
> I think that multiple interfac= es problems of a host are related to
> both Mobile IP/NEMO specific i= ssues and
> general network issues. Mobile IP/NEMO specific issues ar= e related to
> extending of Mobile IP/NEMO and
> these are already studied in M= EXT WG and general network issues which
> were not related to
>= Mobile IP/NEMO could be studied in mif. As same manner, I think that
> my drafts could be discussed and
> developed in mif. In the firs= t draft (Analysis document), I classified
> multiple interface proble= ms into
> Mobile IPv6-sepcific issues, General network issues, and he= terogeneous
> environment issues.
>
> >
> Including Hui Deng in= mif, with regarding to these drafts, they want
> to hear comments fr= om MEXT WG's point of view,
> because it seems that these drafts are = quite related to monami6/MEXT
> WG. So, I ask MEXT to review whether there are
>
> some ov= erlap between MEXT works and my drafts or not.
>
> It is apprec= iate to give comments.
>
> >
> Best regards.
> > Yong-Geun.
>



--000e0cd28df260a2d204619c4e9a-- --===============1045685914== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1045685914==-- From mext-bounces@ietf.org Thu Jan 29 02:17:32 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934DC3A6B54; Thu, 29 Jan 2009 02:17:32 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542073A69C3; Thu, 29 Jan 2009 02:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[AWL=-1.303, BAYES_00=-2.599, FRT_MEETING=2.697, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2m2VstPhhHN; Thu, 29 Jan 2009 02:17:30 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id B3DC63A6359; Thu, 29 Jan 2009 02:17:29 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n0TAH1K9001986; Thu, 29 Jan 2009 11:17:01 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n0TAH1fg019122; Thu, 29 Jan 2009 11:17:01 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n0TAH05J015880; Thu, 29 Jan 2009 11:17:00 +0100 Message-ID: <4981821C.1030808@gmail.com> Date: Thu, 29 Jan 2009 11:17:00 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Hong Yong-Geun References: <545501c981ba$8155e500$8310fe81@etri.info> In-Reply-To: <545501c981ba$8155e500$8310fe81@etri.info> Cc: mif@ietf.org, julien.laganier.IETF@googlemail.com, mext@ietf.org Subject: Re: [MEXT] [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org SG9uZyBZb25nLUdldW4gYSDDqWNyaXQgOgpbLi4uXQo+IEl0IGlzIGFwcHJlY2lhdGUgdG8gdW5k ZXJzdGFuZCB0aGF0IChldmVuIHRob3VnaCB0aGUgc2NvcGUgb2YgbWlmIGlzIAo+IG5vdCBmaXhl ZCkgbWlmIGhhcyBkaWZmZXJlbnQgZGlyZWN0aW9ucyB0byBNRVhULgoKRG8gdGhlICdETlMgY29u dHJvbCBwcm90b2NvbCcgZGlyZWN0aW9ucyBtZW50aW9uZWQgaW4gTUlGIGRpZmZlciBzb21laG93 CmZyb20gdGhlIGV4aXN0aW5nIE1FWFQgbW9uYW1pNi1pbmhlcml0ZWQgZGlyZWN0aW9ucz8gIERv ZXMgTUVYVCBhZGRyZXNzCidETlMgY29udHJvbCBwcm90b2NvbCcgd2hlbiBtdWx0aXBsZS1pbnRl cmZhY2VzLWluLWEtaG9zdCBhcmUgaW52b2x2ZWQ/CgpBbGV4Cgo+IAo+IEJlc3QgcmVnYXJkcy4K PiAKPiBZb25nLUdldW4uCj4gCj4gLS0tLS3sm5Drs7gg66mU7Iuc7KeALS0tLS0gKkZyb206KiAi bWFyY2VsbyBiYWdudWxvIGJyYXVuIiA8bWFyY2Vsb0BpdC51YzNtLmVzPgo+ICAqRnJvbSBEYXRl OiogMjAwOS0wMS0yOCDsmKTtm4QgNjo0MDowOSAqVG86KiAiSG9uZyBZb25nLUdldW4iIAo+IDx5 Z2hvbmdAZXRyaS5yZS5rcj4gKkNjOiogIm1leHRAaWV0Zi5vcmciIDxtZXh0QGlldGYub3JnPiwg Cj4gIm1pZkBpZXRmLm9yZyIgPG1pZkBpZXRmLm9yZz4sICJqdWxpZW4ubGFnYW5pZXIuSUVURkBn b29nbGVtYWlsLmNvbSIgCj4gPGp1bGllbi5sYWdhbmllci5JRVRGQGdvb2dsZW1haWwuY29tPiwg ImRlbmdodWkwMkBnbWFpbC5jb20iIAo+IDxkZW5naHVpMDJAZ21haWwuY29tPiAqU3ViamVjdDoq IFJlOiBNdWx0aXBsZSBpbnRlcmZhY2VzIHByb2JsZW1zIGluIAo+IE1FWFQgYW5kIG1pZgo+IAo+ IAo+IEhpLAo+IAo+IEluIHRoZSBjdXJyZW50IE1FWFQgY2hhcnRlciB0aGVyZSBhcmUgc2V2ZXJh bCBpdGVtcyBhYm91dCBzdXBwb3J0aW5nCj4gIG11bHRpcGxlIGludGVyZmFjZXMsIGluY2x1ZGlu ZyB0aGUgZm9sbG93aW5nIHR3bzoKPiAKPiAtIEEgZG9jdW1lbnQgZXhwbGFpbmluZyB0aGUgbW90 aXZhdGlvbnMgZm9yIGEgbm9kZSB1c2luZyBtdWx0aXBsZSAKPiBpbnRlcmZhY2VzIGFuZCB0aGUg c2NlbmFyaW9zIHdoZXJlIGl0IG1heSBlbmQgdXAgd2l0aCBtdWx0aXBsZSBnbG9iYWwKPiAgYWRk cmVzc2VzIG9uIGl0cyBpbnRlcmZhY2VzIFtJbmZvcm1hdGlvbmFsXQo+IAo+IC0gQW4gYW5hbHlz aXMgZG9jdW1lbnQgZXhwbGFpbmluZyB3aGF0IGFyZSB0aGUgbGltaXRhdGlvbnMgZm9yIG1vYmls ZQo+ICBob3N0cyB1c2luZyBtdWx0aXBsZSBzaW11bHRhbmVvdXMgQ2FyZS1vZiBBZGRyZXNzZXMg YW5kIEhvbWUgQWdlbnQgCj4gYWRkcmVzc2VzIHVzaW5nIE1vYmlsZSBJUHY2LCB3aGV0aGVyIGlz c3VlcyBhcmUgc3BlY2lmaWMgdG8gTW9iaWxlIAo+IElQdjYgb3Igbm90IFtJbmZvcm1hdGlvbmFs XS4KPiAKPiBJIHRoaW5rIHRoaXMgaXMgdmVyeSBzaW1pbGFyIHRvIHRoZSBzY29wZSBvZiBvbmUg b2YgeW91IGRvY3VtZW50cyBhdAo+ICBsZWFzdCwgc28gaSB3b3VsZCBmaW5kIHZlcnkgc3RyYW5n ZSB0aGF0IHRoZSBzYW1lIHdvcmsgaXMgY2hhcnRlcmVkIAo+IGluIHR3byBkaWZmZXJlbnQgd29y a2luZyBncm91cHMuCj4gCj4gTW9yZW92ZXIsIHdlIGRvIGhhdmUgd2cgZG9jdW1lbnRzIGZvciB0 aGVzZSB0d28sIGJ1dCB3ZSBmaW5kIHZlcnkgCj4gaGFyZCB0byBmaW5kIHJldmlld2VycyBmb3Ig dGhvc2UsIHdoaWNoIG1ha2VzIG1lIHRoaW5rIHRoYXQgdGhlcmUgaXMgCj4gbm90IG11Y2ggaW50 ZXJlc3Qgb24gdGhlc2UuIFNvLCBpZiB5b3UgZmluZCBhIG1vcmUgbW90aXZhdGVkIGNyZXcgdG8g Cj4gZG8gdGhlIHdvcmssIHRoYXQgd291bGQgYmUgZ3JlYXQsIHdlIGNhbiBlaXRoZXIgZG8gaXQg aW4gbWV4dCBvciAKPiBzb2Vtd2hlcmUgZWxzZSwgaWYgcGVvcGxlIGZlZWxzIHRoYXQgbmVlZHMg dG8gYmUgZG9uZSwgYnV0IHRoYXQgaXMgCj4gY2VydGFpbmx5IG5vdCB0aGUgZmVlbGluZyBpIGFt IGdldHRpbmcgZnJvbSB0aGUgaW5wdXQgaW4gbWV4dAo+IAo+IFJlZ2FyZHMsIG1hcmNlbG8KPiAK PiAKPiAKPiBIb25nIFlvbmctR2V1biBlc2NyaWJpPzoKPj4gCj4+IEhpLCBhbGwgaW4gTUVYVCBh bmQgbWlmLgo+PiAKPj4gCj4+IAo+PiBJbiBJRVRGIG1pZiAoTXVsdGlwbGUgSW50ZXJmYWNlKSBt YWlsaW5nIGxpc3QgCj4+IChfaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t aWZfIAo+PiA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWY+KSwKPj4g Cj4+IHdlIG5vdyBkaXNjdXNzIHRoZSBob3N0IHdoaWNoIHdvdWxkIGxpa2UgdG8gdXNlIG11bHRp cGxlIAo+PiBpbnRlcmZhY2VzLgo+PiAKPj4gSSB1bmRlcnN0YW5kIHRoYXQgTUVYVCBXRyBpcyBh bHNvIHJlbGF0ZWQgdG8gdGhlIHVzZSBvZiBtdWx0aXBsZSAKPj4gaW50ZXJmYWNlcyBvZiBhIGhv c3QgdXNpbmcgTW9iaWxlIElQdjYgb3IgYSBtb2JpbGUgcm91dGVyIHVzaW5nIAo+PiBORU1PIEJh c2ljIFN1cHBvcnQgYW5kIHRoZWlyIHZhcmlhbnRzCj4+IAo+PiBNRVhUIFdHIGlzIGZvY3Vpbmcg b24gbW9uYW1pNiByZWxhdGVkIHRvcGljIChtdWx0aXBsZSBDb0EsIE11bHRpcGxlCj4+ICBIb0Es IGFuZCBNdWx0cGxlIEhBLCBldGMuLCkgYW5kIGV4dGVkbmluZyBNb2JpbGUgSVB2NiBhbmQgTkVN TyBmb3IKPj4gIHRoZXNlLCBidXQgbWlmIGlzIG5vdCByZWxhdGVkIHRvIHRoaXMgZGlyZWN0aW9u LiBJbiBtaWYsIHNvdXJjZSAKPj4gYWRkcmVzcyBzZWxlY3Rpb24sIHJvdXRpbmcgYW5kIEROUyBj b250cm9sIHByb3RvY29sIGFyZSAKPj4gY29uc2lkZXJhdGlvbiBpdGVtcyBkdWUgdG8gbXVsdGlw bGUgaW50ZXJmYWNlcyBvZiBhIGhvc3QuCj4+IAo+PiAKPj4gCj4+IEZvciBtaWbigJlzIHNjb3Bl LCBKYXJpIEFya2tvIG1hZGUgc29tZSBjb21tZW50cyBhbmQgY2xhc3NpZmljYXRpb24gCj4+IG9m IHByb2JsZW1zLgo+PiAKPj4gX2h0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9t aWYvY3VycmVudC9tc2cwMDA1MC5odG1sXwo+PiAKPj4gQW1vbmcgdGhlc2UgY2xhc3NpZmljYXRp b24gd2hpY2ggaW5jbHVkZXMgYWNjZXNzIHNlbGVjdGlvbiwgc3BsaXQgCj4+IEROUywgY29uZmln dXJhdGlvbiByZWNvbmNpbGlhdGlvbiwgcm91dGluZywgYWRkcmVzcyBzZWxlY3Rpb24sIAo+PiB0 dW5uZWwgbXVsdGlob21pbmcsIGFuZCB0aGUgY29tbXVuaWNhdGlvbiB3YXkgYmV0d2VlbiB0aGUg aG9zdCBhbmQKPj4gIHRoZSBuZXR3b3JrIGFib3V0IHRoZWlyIHBvbGljaWVzIHJlZ2FyZGluZyBh bGwgb2YgdGhlIGFib3ZlLCBKYXJpIAo+PiBzYWlkIHRoYXQgYWNjZXNzIHNlbGVjdGlvbiBpcyBh bHJlYWR5IGNvdmVyZCBpbiBSRkMgNTExMyBhbmQgdHVubmVsCj4+ICBtdWx0aWhvbWluZyBpcyBh bHJlYWR5IGNvdmVyZWQgaW4gTUVYVCBXRyB3b3JrIGl0ZW1zLgo+PiAKPj4gCj4+IAo+PiBBdCBt b25hbWk2IFdHIGluIDY0dGggSUVURiBtZWV0aW5uZywgSSBzdWJtaXR0ZWQgYW5kIHByZXNlbnRl ZCB0d28KPj4gIEludGVybmV0IERyYWZ0cy4KPj4gCj4+IC0gQW5hbHlzaXMgb2YgbXVsdGlwbGUg aW50ZXJmYWNlcyBpbiBhIE1vYmlsZSBOb2RlCj4+IAo+PiBfaHR0cDovL3Rvb2xzLmlldGYub3Jn L2lkL2RyYWZ0LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1zdGF0ZW1lbnQtMDAudHh0Xwo+PiAKPj4g Cj4+IAo+PiAtIFZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgZm9yIG11bHRpcGxlIGludGVyZmFj ZXMgaW4gYSBNb2JpbGUgCj4+IG5vZGUgdXNpbmcgTW9iaWxlIElQdjYKPj4gCj4+IF9odHRwOi8v dG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy12aXJ0dWFsaWYtbW4tbWlwdjYtMDAudHh0XyAK Pj4gPGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2 Ni0wMC50eHQ+Cj4+IAo+PiBCZWNhdXNlIHRoZXNlIHR3byBkcmFmdHMgd2VyZSBub3QgaW4gdGhl IG1vbmFtaTYgV0figJlzIHNjb3BlIGFuZCAKPj4gdmlydHVhbCBuZXR3b3JrIGludGVyZmFjZSBk cmFmdCB3YXMKPj4gCj4+IGltcGxlbWVudGF0aW9uIHNwZWNpZmljLCB0aGVyZSB3ZXJlIG5vdCBh ZG9wZWQgaW4gbW9uYW1pNiBXR+KAmXMgd29yawo+PiAgaXRlbXMuIFRoZSBpbnRlbnRpb25zIG9m IHR3byBkcmFmdHMgYXJlIHN1cHBvcnRpbmcgbXVsdGlwbGUgCj4+IGludGVyZmFjZXMgb2YgYSBo b3N0IHdpdGhvdXQgZXh0ZW5kaW5nIE1vYmlsZSBJUHY2L05FTU8uCj4+IAo+PiAKPj4gCj4+IEkg dGhpbmsgdGhhdCBtdWx0aXBsZSBpbnRlcmZhY2VzIHByb2JsZW1zIG9mIGEgaG9zdCBhcmUgcmVs YXRlZCB0bwo+PiAgYm90aCBNb2JpbGUgSVAvTkVNTyBzcGVjaWZpYyBpc3N1ZXMgYW5kIGdlbmVy YWwgbmV0d29yayBpc3N1ZXMuIAo+PiBNb2JpbGUgSVAvTkVNTyBzcGVjaWZpYyBpc3N1ZXMgYXJl IHJlbGF0ZWQgdG8gZXh0ZW5kaW5nIG9mIE1vYmlsZSAKPj4gSVAvTkVNTyBhbmQgdGhlc2UgYXJl IGFscmVhZHkgc3R1ZGllZCBpbiBNRVhUIFdHIGFuZCBnZW5lcmFsIAo+PiBuZXR3b3JrIGlzc3Vl cyB3aGljaCB3ZXJlIG5vdCByZWxhdGVkIHRvIE1vYmlsZSBJUC9ORU1PIGNvdWxkIGJlIAo+PiBz dHVkaWVkIGluIG1pZi4gQXMgc2FtZSBtYW5uZXIsIEkgdGhpbmsgdGhhdCBteSBkcmFmdHMgY291 bGQgYmUgCj4+IGRpc2N1c3NlZCBhbmQgZGV2ZWxvcGVkIGluIG1pZi4gSW4gdGhlIGZpcnN0IGRy YWZ0IChBbmFseXNpcyAKPj4gZG9jdW1lbnQpLCBJIGNsYXNzaWZpZWQgbXVsdGlwbGUgaW50ZXJm YWNlIHByb2JsZW1zIGludG8gTW9iaWxlIAo+PiBJUHY2LXNlcGNpZmljIGlzc3VlcywgR2VuZXJh bCBuZXR3b3JrIGlzc3VlcywgYW5kIGhldGVyb2dlbmVvdXMgCj4+IGVudmlyb25tZW50IGlzc3Vl cy4KPj4gCj4+IAo+PiAKPj4gSW5jbHVkaW5nIEh1aSBEZW5nIGluIG1pZiwgd2l0aCByZWdhcmRp bmcgdG8gdGhlc2UgZHJhZnRzLCB0aGV5IAo+PiB3YW50IHRvIGhlYXIgY29tbWVudHMgZnJvbSBN RVhUIFdH4oCZcyBwb2ludCBvZiB2aWV3LCBiZWNhdXNlIGl0IAo+PiBzZWVtcyB0aGF0IHRoZXNl IGRyYWZ0cyBhcmUgcXVpdGUgcmVsYXRlZCB0byBtb25hbWk2L01FWFQgV0cuIFNvLCBJCj4+ICBh c2sgTUVYVCB0byByZXZpZXcgd2hldGhlciB0aGVyZSBhcmUKPj4gCj4+IHNvbWUgb3ZlcmxhcCBi ZXR3ZWVuIE1FWFQgd29ya3MgYW5kIG15IGRyYWZ0cyBvciBub3QuCj4+IAo+PiBJdCBpcyBhcHBy ZWNpYXRlIHRvIGdpdmUgY29tbWVudHMuCj4+IAo+PiAKPj4gCj4+IEJlc3QgcmVnYXJkcy4KPj4g Cj4+IFlvbmctR2V1bi4KPj4gCj4gCj4gCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gCj4gCj4gCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gbWlmIG1haWxpbmcg bGlzdCAKPiBtaWZAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9taWYKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpN RVhUIG1haWxpbmcgbGlzdApNRVhUQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWV4dAo= From mext-bounces@ietf.org Thu Jan 29 12:10:18 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C83493A6AB3; Thu, 29 Jan 2009 12:10:18 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CEAD3A6AA2; Thu, 29 Jan 2009 12:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.192 X-Spam-Level: X-Spam-Status: No, score=-4.192 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, FRT_MEETING=2.697, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycou0oT3IT4C; Thu, 29 Jan 2009 12:10:15 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 895C33A6A64; Thu, 29 Jan 2009 12:10:14 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (187.pool85-53-142.dynamic.orange.es [85.53.142.187]) by smtp02.uc3m.es (Postfix) with ESMTP id EBB1A65A1FD; Thu, 29 Jan 2009 21:09:54 +0100 (CET) Message-ID: <49820D13.2060601@it.uc3m.es> Date: Thu, 29 Jan 2009 21:09:55 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Marc Blanchet References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> <49820BB6.9070405@viagenie.ca> In-Reply-To: <49820BB6.9070405@viagenie.ca> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16432.001 Cc: mif@ietf.org, julien.laganier.IETF@googlemail.com, mext@ietf.org Subject: Re: [MEXT] [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org bWFrZXMgc2Vuc2UgdG8gbWUKCgoKTWFyYyBCbGFuY2hldCBlc2NyaWJpw7M6Cj4gbWFyY2VsbyBi YWdudWxvIGJyYXVuIGEgw6ljcml0IDoKPiAgIAo+PiBIaSwKPj4KPj4gSW4gdGhlIGN1cnJlbnQg TUVYVCBjaGFydGVyIHRoZXJlIGFyZSBzZXZlcmFsIGl0ZW1zIGFib3V0IHN1cHBvcnRpbmcKPj4g bXVsdGlwbGUgaW50ZXJmYWNlcywgaW5jbHVkaW5nIHRoZSBmb2xsb3dpbmcgdHdvOgo+Pgo+PiAt IEEgZG9jdW1lbnQgZXhwbGFpbmluZyB0aGUgbW90aXZhdGlvbnMgZm9yIGEgbm9kZSB1c2luZyBt dWx0aXBsZQo+PiBpbnRlcmZhY2VzIGFuZCB0aGUgc2NlbmFyaW9zIHdoZXJlIGl0IG1heSBlbmQg dXAgd2l0aCBtdWx0aXBsZQo+PiBnbG9iYWwgYWRkcmVzc2VzIG9uIGl0cyBpbnRlcmZhY2VzIFtJ bmZvcm1hdGlvbmFsXQo+Pgo+PiAtIEFuIGFuYWx5c2lzIGRvY3VtZW50IGV4cGxhaW5pbmcgd2hh dCBhcmUgdGhlIGxpbWl0YXRpb25zIGZvcgo+PiBtb2JpbGUgaG9zdHMgdXNpbmcgbXVsdGlwbGUg c2ltdWx0YW5lb3VzIENhcmUtb2YgQWRkcmVzc2VzIGFuZCBIb21lCj4+IEFnZW50IGFkZHJlc3Nl cyB1c2luZyBNb2JpbGUgSVB2Niwgd2hldGhlciBpc3N1ZXMgYXJlIHNwZWNpZmljIHRvCj4+IE1v YmlsZSBJUHY2IG9yIG5vdCBbSW5mb3JtYXRpb25hbF0uCj4+Cj4+IEkgdGhpbmsgdGhpcyBpcyB2 ZXJ5IHNpbWlsYXIgdG8gdGhlIHNjb3BlIG9mIG9uZSBvZiB5b3UgZG9jdW1lbnRzIGF0Cj4+IGxl YXN0LCBzbyBpIHdvdWxkIGZpbmQgdmVyeSBzdHJhbmdlIHRoYXQgdGhlIHNhbWUgd29yayBpcyBj aGFydGVyZWQgaW4KPj4gdHdvIGRpZmZlcmVudCB3b3JraW5nIGdyb3Vwcy4KPj4KPj4gTW9yZW92 ZXIsIHdlIGRvIGhhdmUgd2cgZG9jdW1lbnRzIGZvciB0aGVzZSB0d28sIGJ1dCB3ZSBmaW5kIHZl cnkgaGFyZAo+PiB0byBmaW5kIHJldmlld2VycyBmb3IgdGhvc2UsIHdoaWNoIG1ha2VzIG1lIHRo aW5rIHRoYXQgdGhlcmUgaXMgbm90IG11Y2gKPj4gaW50ZXJlc3Qgb24gdGhlc2UuIFNvLCBpZiB5 b3UgZmluZCBhIG1vcmUgbW90aXZhdGVkIGNyZXcgdG8gZG8gdGhlIHdvcmssCj4+IHRoYXQgd291 bGQgYmUgZ3JlYXQsIHdlIGNhbiBlaXRoZXIgZG8gaXQgaW4gbWV4dCBvciBzb2Vtd2hlcmUgZWxz ZSwgaWYKPj4gcGVvcGxlIGZlZWxzIHRoYXQgbmVlZHMgdG8gYmUgZG9uZSwgYnV0IHRoYXQgaXMg Y2VydGFpbmx5IG5vdCB0aGUKPj4gZmVlbGluZyBpIGFtIGdldHRpbmcgZnJvbSB0aGUgaW5wdXQg aW4gbWV4dAo+PiAgICAgCj4KPiB0byBtZSwgdGhlIG1haW4gZGlmZmVyZW5jZSBpcyB0aGF0IHRo ZSAnbXVsdGlwbGUgaW50ZXJmYWNlJyBpc3N1ZSBpcyBub3QKPiBib3VuZCB0byBtb2JpbGl0eSwg YW5kIG1vcmUgc3BlY2lmaWNhbGx5IHRvIG1vYmlsaXR5IHByb3RvY29scwo+IChtb2JpbGVJUHY0 LCBtb2JpbGVpcHY2LCBuZW1vLCAuLi4pLgo+Cj4gVGhlcmVmb3JlLCB0aGUgTUlGIHdvcmsgaXMg bm90IHNjb3BpbmcgYWJvdXQgbW9iaWxpdHkgcHJvdG9jb2xzIGFuZAo+IHNoYWxsIG5vdCByZXF1 aXJlIG1vYmlsaXR5IHByb3RvY29scy4KPgo+IEkgd291bGQgc2VlIHRoYXQgaWYgc29tZSBwYXJ0 IG9mIHRoZSBNSUYgd29yayBpcyBsb29raW5nIGF0IHRoZSBtb2JpbGl0eQo+IHByb3RvY29scywg dGhlbiB0aGVzZSBzaG91bGQgYmUgdGhlbiAidHJhbnNmZXJlZCIgdG8gTUVYVC4KPgo+IE1hcmMu Cj4KPiAgIAo+PiBSZWdhcmRzLCBtYXJjZWxvCj4+Cj4+Cj4+Cj4+IEhvbmcgWW9uZy1HZXVuIGVz Y3JpYmnDszoKPj4gICAgIAo+Pj4gSGksIGFsbCBpbiBNRVhUIGFuZCBtaWYuCj4+Pgo+Pj4gIAo+ Pj4KPj4+IEluIElFVEYgbWlmIChNdWx0aXBsZSBJbnRlcmZhY2UpIG1haWxpbmcgbGlzdAo+Pj4g KF9odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZl8KPj4+IDxodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZj4pLAo+Pj4KPj4+IHdlIG5vdyBkaXNj dXNzIHRoZSBob3N0IHdoaWNoIHdvdWxkIGxpa2UgdG8gdXNlIG11bHRpcGxlIGludGVyZmFjZXMu Cj4+Pgo+Pj4gSSB1bmRlcnN0YW5kIHRoYXQgTUVYVCBXRyBpcyBhbHNvIHJlbGF0ZWQgdG8gdGhl IHVzZSBvZiBtdWx0aXBsZQo+Pj4gaW50ZXJmYWNlcyBvZiBhIGhvc3QKPj4+IHVzaW5nIE1vYmls ZSBJUHY2IG9yIGEgbW9iaWxlIHJvdXRlciB1c2luZyBORU1PIEJhc2ljIFN1cHBvcnQgYW5kCj4+ PiB0aGVpciB2YXJpYW50cwo+Pj4KPj4+IE1FWFQgV0cgaXMgZm9jdWluZyBvbiBtb25hbWk2IHJl bGF0ZWQgdG9waWMgKG11bHRpcGxlIENvQSwgTXVsdGlwbGUKPj4+IEhvQSwgYW5kIE11bHRwbGUg SEEsIGV0Yy4sKQo+Pj4gYW5kIGV4dGVkbmluZyBNb2JpbGUgSVB2NiBhbmQgTkVNTyBmb3IgdGhl c2UsIGJ1dCBtaWYgaXMgbm90IHJlbGF0ZWQKPj4+IHRvIHRoaXMgZGlyZWN0aW9uLgo+Pj4gSW4g bWlmLCBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24sIHJvdXRpbmcgYW5kIEROUyBjb250cm9sIHBy b3RvY29sIGFyZQo+Pj4gY29uc2lkZXJhdGlvbiBpdGVtcwo+Pj4gZHVlIHRvIG11bHRpcGxlIGlu dGVyZmFjZXMgb2YgYSBob3N0Lgo+Pj4KPj4+ICAKPj4+Cj4+PiBGb3IgbWlm4oCZcyBzY29wZSwg SmFyaSBBcmtrbyBtYWRlIHNvbWUgY29tbWVudHMgYW5kIGNsYXNzaWZpY2F0aW9uIG9mCj4+PiBw cm9ibGVtcy4KPj4+Cj4+PiBfaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21p Zi9jdXJyZW50L21zZzAwMDUwLmh0bWxfCj4+Pgo+Pj4gQW1vbmcgdGhlc2UgY2xhc3NpZmljYXRp b24gd2hpY2ggaW5jbHVkZXMgYWNjZXNzIHNlbGVjdGlvbiwgc3BsaXQgRE5TLAo+Pj4gY29uZmln dXJhdGlvbiByZWNvbmNpbGlhdGlvbiwKPj4+IHJvdXRpbmcsIGFkZHJlc3Mgc2VsZWN0aW9uLCB0 dW5uZWwgbXVsdGlob21pbmcsIGFuZCB0aGUgY29tbXVuaWNhdGlvbgo+Pj4gd2F5IGJldHdlZW4g dGhlIGhvc3QgYW5kCj4+PiB0aGUgbmV0d29yayBhYm91dCB0aGVpciBwb2xpY2llcyByZWdhcmRp bmcgYWxsIG9mIHRoZSBhYm92ZSwgSmFyaSBzYWlkCj4+PiB0aGF0IGFjY2VzcyBzZWxlY3Rpb24g aXMgYWxyZWFkeQo+Pj4gY292ZXJkIGluIFJGQyA1MTEzIGFuZCB0dW5uZWwgbXVsdGlob21pbmcg aXMgYWxyZWFkeSBjb3ZlcmVkIGluIE1FWFQKPj4+IFdHIHdvcmsgaXRlbXMuCj4+Pgo+Pj4gIAo+ Pj4KPj4+IEF0IG1vbmFtaTYgV0cgaW4gNjR0aCBJRVRGIG1lZXRpbm5nLCBJIHN1Ym1pdHRlZCBh bmQgcHJlc2VudGVkIHR3bwo+Pj4gSW50ZXJuZXQgRHJhZnRzLgo+Pj4KPj4+IC0gQW5hbHlzaXMg b2YgbXVsdGlwbGUgaW50ZXJmYWNlcyBpbiBhIE1vYmlsZSBOb2RlCj4+Pgo+Pj4gX2h0dHA6Ly90 b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAw LnR4dF8KPj4+Cj4+PiAtIFZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgZm9yIG11bHRpcGxlIGlu dGVyZmFjZXMgaW4gYSBNb2JpbGUgbm9kZQo+Pj4gdXNpbmcgTW9iaWxlIElQdjYKPj4+Cj4+PiBf aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAw LnR4dF8KPj4+IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy12aXJ0dWFsaWYt bW4tbWlwdjYtMDAudHh0Pgo+Pj4KPj4+IEJlY2F1c2UgdGhlc2UgdHdvIGRyYWZ0cyB3ZXJlIG5v dCBpbiB0aGUgbW9uYW1pNiBXR+KAmXMgc2NvcGUgYW5kCj4+PiB2aXJ0dWFsIG5ldHdvcmsgaW50 ZXJmYWNlIGRyYWZ0IHdhcwo+Pj4KPj4+IGltcGxlbWVudGF0aW9uIHNwZWNpZmljLCB0aGVyZSB3 ZXJlIG5vdCBhZG9wZWQgaW4gbW9uYW1pNiBXR+KAmXMgd29yawo+Pj4gaXRlbXMuIFRoZSBpbnRl bnRpb25zIG9mIHR3byBkcmFmdHMKPj4+IGFyZSBzdXBwb3J0aW5nIG11bHRpcGxlIGludGVyZmFj ZXMgb2YgYSBob3N0IHdpdGhvdXQgZXh0ZW5kaW5nIE1vYmlsZQo+Pj4gSVB2Ni9ORU1PLgo+Pj4K Pj4+ICAKPj4+Cj4+PiBJIHRoaW5rIHRoYXQgbXVsdGlwbGUgaW50ZXJmYWNlcyBwcm9ibGVtcyBv ZiBhIGhvc3QgYXJlIHJlbGF0ZWQgdG8KPj4+IGJvdGggTW9iaWxlIElQL05FTU8gc3BlY2lmaWMg aXNzdWVzIGFuZAo+Pj4gZ2VuZXJhbCBuZXR3b3JrIGlzc3Vlcy4gTW9iaWxlIElQL05FTU8gc3Bl Y2lmaWMgaXNzdWVzIGFyZSByZWxhdGVkIHRvCj4+PiBleHRlbmRpbmcgb2YgTW9iaWxlIElQL05F TU8gYW5kCj4+PiB0aGVzZSBhcmUgYWxyZWFkeSBzdHVkaWVkIGluIE1FWFQgV0cgYW5kIGdlbmVy YWwgbmV0d29yayBpc3N1ZXMgd2hpY2gKPj4+IHdlcmUgbm90IHJlbGF0ZWQgdG8KPj4+IE1vYmls ZSBJUC9ORU1PIGNvdWxkIGJlIHN0dWRpZWQgaW4gbWlmLiBBcyBzYW1lIG1hbm5lciwgSSB0aGlu ayB0aGF0Cj4+PiBteSBkcmFmdHMgY291bGQgYmUgZGlzY3Vzc2VkIGFuZAo+Pj4gZGV2ZWxvcGVk IGluIG1pZi4gSW4gdGhlIGZpcnN0IGRyYWZ0IChBbmFseXNpcyBkb2N1bWVudCksIEkgY2xhc3Np ZmllZAo+Pj4gbXVsdGlwbGUgaW50ZXJmYWNlIHByb2JsZW1zIGludG8KPj4+IE1vYmlsZSBJUHY2 LXNlcGNpZmljIGlzc3VlcywgR2VuZXJhbCBuZXR3b3JrIGlzc3VlcywgYW5kIGhldGVyb2dlbmVv dXMKPj4+IGVudmlyb25tZW50IGlzc3Vlcy4KPj4+Cj4+PiAgCj4+Pgo+Pj4gSW5jbHVkaW5nIEh1 aSBEZW5nIGluIG1pZiwgd2l0aCByZWdhcmRpbmcgdG8gdGhlc2UgZHJhZnRzLCB0aGV5IHdhbnQK Pj4+IHRvIGhlYXIgY29tbWVudHMgZnJvbSBNRVhUIFdH4oCZcyBwb2ludCBvZiB2aWV3LAo+Pj4g YmVjYXVzZSBpdCBzZWVtcyB0aGF0IHRoZXNlIGRyYWZ0cyBhcmUgcXVpdGUgcmVsYXRlZCB0byBt b25hbWk2L01FWFQKPj4+IFdHLiBTbywgSSBhc2sgTUVYVCB0byByZXZpZXcgd2hldGhlciB0aGVy ZSBhcmUKPj4+Cj4+PiBzb21lIG92ZXJsYXAgYmV0d2VlbiBNRVhUIHdvcmtzIGFuZCBteSBkcmFm dHMgb3Igbm90Lgo+Pj4KPj4+IEl0IGlzIGFwcHJlY2lhdGUgdG8gZ2l2ZSBjb21tZW50cy4KPj4+ Cj4+PiAgCj4+Pgo+Pj4gQmVzdCByZWdhcmRzLgo+Pj4KPj4+IFlvbmctR2V1bi4KPj4+Cj4+PiAg ICAgICAKPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K Pj4gbWlmIG1haWxpbmcgbGlzdAo+PiBtaWZAaWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9taWYKPj4gICAgIAo+Cj4KPiAgIAoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTUVYVCBtYWlsaW5nIGxpc3QKTUVYVEBp ZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21leHQK From mext-bounces@ietf.org Thu Jan 29 12:33:55 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090E428C185; Thu, 29 Jan 2009 12:33:55 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA5C3A687E; Thu, 29 Jan 2009 12:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.532 X-Spam-Level: X-Spam-Status: No, score=-5.532 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9Acs4jnBCFm; Thu, 29 Jan 2009 12:33:53 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7CFEC3A6A20; Thu, 29 Jan 2009 12:33:53 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (187.pool85-53-142.dynamic.orange.es [85.53.142.187]) by smtp02.uc3m.es (Postfix) with ESMTP id 78B48659C89; Thu, 29 Jan 2009 21:33:32 +0100 (CET) Message-ID: <4982129D.3060503@it.uc3m.es> Date: Thu, 29 Jan 2009 21:33:33 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Scott Brim References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> <49820BB6.9070405@viagenie.ca> <49820D13.2060601@it.uc3m.es> <20090129202644.GZ34382@cisco.com> In-Reply-To: <20090129202644.GZ34382@cisco.com> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16432.002 Cc: Marc Blanchet , julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [MEXT] [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Scott Brim escribi=F3: > Excerpts from marcelo bagnulo braun on Thu, Jan 29, 2009 09:09:55PM > +0100: > = >> makes sense to me >> >> Marc Blanchet escribi=F3: >> = >>> to me, the main difference is that the 'multiple interface' issue >>> is not bound to mobility, and more specifically to mobility >>> protocols (mobileIPv4, mobileipv6, nemo, ...). >>> >>> Therefore, the MIF work is not scoping about mobility protocols and >>> shall not require mobility protocols. >>> >>> I would see that if some part of the MIF work is looking at the >>> mobility protocols, then these should be then "transfered" to MEXT. >>> = > > Even without mobility considerations, the issue of how to handle > multiple interfaces overlaps with IntArea, RRG, and Behave (those are > the ones I can think of offhand). Have you seen the arguments, for > example, about session initialization when multiple addresses can be > in play simultaneously at both ends? I apologize but I still don't > understand the MIF boundaries. > > = I wrote a draft a long time ago about the problems for selecting the = source address in multiaddressed hosts, not sure if this is related to = what you asking about... you can check it at http://www.watersprings.org/pub/id/draft-bagnulo-6man-rfc3484-update-00.txt regards, marcelo > Thanks ... Scott > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 29 12:44:28 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCBE28C185; Thu, 29 Jan 2009 12:44:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2C83A6A83; Thu, 29 Jan 2009 12:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.561 X-Spam-Level: X-Spam-Status: No, score=-5.561 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUI+Jxc+cIWG; Thu, 29 Jan 2009 12:44:27 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 875FF3A6A64; Thu, 29 Jan 2009 12:44:25 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (134.pool85-53-135.dynamic.orange.es [85.53.135.134]) by smtp01.uc3m.es (Postfix) with ESMTP id 2AA59B4D496; Thu, 29 Jan 2009 21:44:04 +0100 (CET) Message-ID: <49821513.8060307@it.uc3m.es> Date: Thu, 29 Jan 2009 21:44:03 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Marc Blanchet References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> <49820BB6.9070405@viagenie.ca> <49820D13.2060601@it.uc3m.es> <20090129202644.GZ34382@cisco.com> <4982129D.3060503@it.uc3m.es> <49821348.3000904@viagenie.ca> In-Reply-To: <49821348.3000904@viagenie.ca> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16432.002 Cc: julien.laganier.IETF@googlemail.com, Scott Brim , mif@ietf.org, mext@ietf.org Subject: Re: [MEXT] [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Marc Blanchet escribi=F3: > marcelo bagnulo braun a =E9crit : > = >> Scott Brim escribi=F3: >> = >>> Excerpts from marcelo bagnulo braun on Thu, Jan 29, 2009 09:09:55PM >>> +0100: >>> = >>> = >>>> makes sense to me >>>> >>>> Marc Blanchet escribi=F3: >>>> = >>>> = >>>>> to me, the main difference is that the 'multiple interface' issue >>>>> is not bound to mobility, and more specifically to mobility >>>>> protocols (mobileIPv4, mobileipv6, nemo, ...). >>>>> >>>>> Therefore, the MIF work is not scoping about mobility protocols and >>>>> shall not require mobility protocols. >>>>> >>>>> I would see that if some part of the MIF work is looking at the >>>>> mobility protocols, then these should be then "transfered" to MEXT. >>>>> = >>>>> = >>> Even without mobility considerations, the issue of how to handle >>> multiple interfaces overlaps with IntArea, RRG, and Behave (those are >>> the ones I can think of offhand). Have you seen the arguments, for >>> example, about session initialization when multiple addresses can be >>> in play simultaneously at both ends? I apologize but I still don't >>> understand the MIF boundaries. >>> >>> = >>> = >> I wrote a draft a long time ago about the problems for selecting the >> source address in multiaddressed hosts, not sure if this is related to >> what you asking about... >> >> you can check it at >> >> http://www.watersprings.org/pub/id/draft-bagnulo-6man-rfc3484-update-00.= txt >> = > > there is an address selection design team that is looking at this current= ly. > = mmm, not really maybe i missing somehting, but i understnad that the scope of the design = team is limited to the automatic update of the rfc3484 policy table, and = they are not dealing with the issue of how the properly select the = source address, for instance, in the case that you need to retry due to = ingress filtering and the like regards, marcelo > Marc. > > = >> regards, marcelo >> >> = >>> Thanks ... Scott >>> >>> = >>> = > > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 29 12:56:36 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1963A6A97; Thu, 29 Jan 2009 12:56:36 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71EB3A68BC; Thu, 29 Jan 2009 12:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[AWL=1.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5p1uo3eLOP2f; Thu, 29 Jan 2009 12:56:35 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id AC9243A68D7; Thu, 29 Jan 2009 12:56:34 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (134.pool85-53-135.dynamic.orange.es [85.53.135.134]) by smtp02.uc3m.es (Postfix) with ESMTP id 5D1BA65A16D; Thu, 29 Jan 2009 21:56:14 +0100 (CET) Message-ID: <498217EF.50709@it.uc3m.es> Date: Thu, 29 Jan 2009 21:56:15 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Marc Blanchet References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> <49820BB6.9070405@viagenie.ca> <49820D13.2060601@it.uc3m.es> <20090129202644.GZ34382@cisco.com> <4982148C.9080608@viagenie.ca> In-Reply-To: <4982148C.9080608@viagenie.ca> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16432.002 Cc: julien.laganier.IETF@googlemail.com, Scott Brim , mif@ietf.org, mext@ietf.org Subject: Re: [MEXT] [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Marc Blanchet escribi=F3: > Scott Brim a =E9crit : > = >> Excerpts from marcelo bagnulo braun on Thu, Jan 29, 2009 09:09:55PM >> +0100: >> = >>> makes sense to me >>> >>> Marc Blanchet escribi=F3: >>> = >>>> to me, the main difference is that the 'multiple interface' issue >>>> is not bound to mobility, and more specifically to mobility >>>> protocols (mobileIPv4, mobileipv6, nemo, ...). >>>> >>>> Therefore, the MIF work is not scoping about mobility protocols and >>>> shall not require mobility protocols. >>>> >>>> I would see that if some part of the MIF work is looking at the >>>> mobility protocols, then these should be then "transfered" to MEXT. >>>> = >> Even without mobility considerations, the issue of how to handle >> multiple interfaces overlaps with IntArea, RRG, and Behave (those are >> the ones I can think of offhand). Have you seen the arguments, for >> example, about session initialization when multiple addresses can be >> in play simultaneously at both ends? I apologize but I still don't >> understand the MIF boundaries. >> = > > of course, there is overlap, as most IETF issues and work span over > multiple groups. > > to me, the question in hand is the following: > a) do we think this is a "real" problem > b) if yes, then what should we do with it. > c) if what =3D possible wg, then write charter, ... > > to me, a) and b) are clearly subject of the BOF. c) depends on the > outcome of the BOF. > > Looking at the various comments over the past weeks, it might be good > that we (the initial proposers or anyone I shall say) should write a > possible wg charter based on the discussions. We might then define the > scope and the out of scope... > = that would be perfect imho now it is a bit confusing what is the scope of this effort at least for me thanks, marcelo > Marc. > = >> Thanks ... Scott >> = > > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jan 29 13:00:03 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 700613A6A55; Thu, 29 Jan 2009 13:00:03 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C0AC83A6A64; Thu, 29 Jan 2009 13:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090129210001.C0AC83A6A64@core3.amsl.com> Date: Thu, 29 Jan 2009 13:00:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-03.txt Pages : 35 Date : 2009-01-29 This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These semantics are generic enough and can be used by mobility entities in the case of Client Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-binding-revocation-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-29125137.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Thu Jan 29 13:21:09 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31533A68A5; Thu, 29 Jan 2009 13:21:09 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7A43A6889; Thu, 29 Jan 2009 13:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl8-8capGFyo; Thu, 29 Jan 2009 13:21:07 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 73BF53A687B; Thu, 29 Jan 2009 13:21:07 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0TLKUv23395; Thu, 29 Jan 2009 21:20:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C98257.673E7C1E" Date: Thu, 29 Jan 2009 15:20:21 -0600 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: UPDATE based on WGLC [MEXT] I-D Action:draft-ietf-mext-binding-revocation-03.txt Thread-Index: AcmCVI6YWnYtF5aLR1GBVQpjiRPurAAAi21Q From: "Ahmad Muhanna" To: Cc: netlmm-chairs@tools.ietf.org, "Stupar, Patrick" , netlmm@ietf.org, Jari Arkko , julien.laganier.IETF@googlemail.com Subject: [MEXT] UPDATE based on WGLC I-D Action:draft-ietf-mext-binding-revocation-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C98257.673E7C1E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hello All, A new revision (03) of the Binding Revocation for IPv6 Mobility draft has been published. This revision addresses all comments that were received during the MEXT wg Last Call. The main changes are: 1. Add IPv4 HoA Binding Only (V) bit, which is set when ONLY the IPv4 HoA is being revoked while the IPv6 HoA or HNP binding to the current CoA continues. The logic is the same as in the previous revision which uses a Revocation Trigger value instead. 2. Made sure that consistence across the draft when revoking a BCE with multiple HNP(s) or multiple BCE with different HNP while using the same MN NAI. 3. Status values to follow common scheme where failure is > 127. 4. Added another new R. Trigger and Status value "IPv4 address lease expires" and "IPv4 HoA Option Required", respectively. 5. Addressed all clarification and editorial comments. Please take a look and make sure that your comments have been addressed correctly.=20 Regards, Ahmad -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, January 29, 2009 3:00 PM To: i-d-announce@ietf.org Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-03.txt Pages : 35 Date : 2009-01-29 This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These semantics are generic enough and can be used by mobility entities in the case of Client Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-0 3.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C98257.673E7C1E Content-Type: application/octet-stream; name="draft-ietf-mext-binding-revocation-03.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-mext-binding-revocation-03.URL Content-Disposition: attachment; filename="draft-ietf-mext-binding-revocation-03.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW1leHQtYmluZGluZy1yZXZvY2F0aW9uLTAzLnR4dA0K ------_=_NextPart_001_01C98257.673E7C1E Content-Type: text/plain; name="ATT2586820.txt" Content-Transfer-Encoding: base64 Content-Description: ATT2586820.txt Content-Disposition: attachment; filename="ATT2586820.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1FWFQgbWFp bGluZyBsaXN0DQpNRVhUQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21leHQNCg== ------_=_NextPart_001_01C98257.673E7C1E Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ------_=_NextPart_001_01C98257.673E7C1E-- From mext-bounces@ietf.org Thu Jan 29 17:32:25 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F64A3A6ACD; Thu, 29 Jan 2009 17:32:25 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6EE628C1F5 for ; Thu, 29 Jan 2009 17:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.014 X-Spam-Level: ** X-Spam-Status: No, score=2.014 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, FRT_MEETING=2.697, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZP2f3yFLWa6 for ; Thu, 29 Jan 2009 17:32:22 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id 598983A6A63 for ; Thu, 29 Jan 2009 17:32:21 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Fri, 30 Jan 2009 10:32:02 +0900 Priority: normal X-ReadCheckName: mext%40ietf.org Thread-Topic: Re: Multiple interfaces problems in MEXT and mif X-ReadCheckMessageID: <06a0ab2a-498a-4b86-8e3e-93337d1f1a4a@etri.re.kr> thread-index: AcmCeozR41kqgY52QEWeQnaYgETsEw== From: "Hong Yong-Geun" To: "Hui Deng" , "marcelo bagnulo braun" Date: Fri, 30 Jan 2009 10:32:01 +0900 Comment: ??, u-??, Message-ID: <29bc01c9827a$8cd85aa0$8310fe81@etri.info> MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 Content-class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 X-OriginalArrivalTime: 30 Jan 2009 01:32:02.0145 (UTC) FILETIME=[8D167510:01C9827A] Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [MEXT] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1637277638==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1637277638== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----=_NextPart_000_29B2_01C982C5.FCBB47B0" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_29B2_01C982C5.FCBB47B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 ------=_NextPart_000_29B2_01C982C5.FCBB47B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj5IaS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRoYW5rcyBIdWkg Zm9yIHlvdXIgZXhwbGFuYXRpb24gb2YgbWlmJyBzY29wZS48L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPkkgYmVsaWV2ZSB0aGF0IHNvb24gdGhlIGNoYXJ0ZXIgcHJvcG9zZWQgb2YgbWlm IHdpbGwgYmUgc2hvd24uPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5BcyBJIGtub3cs Jm5ic3A7bWlmIGlzIG5vdCBnb2luZyB0byB3b3JrIGluIE1JUHY2L05FTU8gcmVsYXRlZCBpc3N1 ZXMuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5CZXN0IFJlZ2FyZHMuPC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj5Zb25nLUdldW4uPC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj48QlI+LS0tLS3sm5Drs7gg66mU7Iuc7KeALS0tLS08QlI+PEI+RnJvbTo8L0I+ICJI dWkgRGVuZyIgJmx0O2RlbmdodWkwMkBnbWFpbC5jb20mZ3Q7PEJSPjxCPkZyb20gRGF0ZTo8L0I+ IDIwMDktMDEtMjkg7Jik7ZuEIDc6MTE6MDQ8QlI+PEI+VG86PC9CPiAibWFyY2VsbyBiYWdudWxv IGJyYXVuIiAmbHQ7bWFyY2Vsb0BpdC51YzNtLmVzJmd0OzxCUj48Qj5DYzo8L0I+IO2Zjeyaqeq3 vCAmbHQ7eWdob25nQGV0cmkucmUua3ImZ3Q7LCAibWV4dEBpZXRmLm9yZyIgJmx0O21leHRAaWV0 Zi5vcmcmZ3Q7LCAibWlmQGlldGYub3JnIiAmbHQ7bWlmQGlldGYub3JnJmd0OywgImp1bGllbi5s YWdhbmllci5JRVRGQGdvb2dsZW1haWwuY29tIiAmbHQ7anVsaWVuLmxhZ2FuaWVyLklFVEZAZ29v Z2xlbWFpbC5jb20mZ3Q7PEJSPjxCPlN1YmplY3Q6PC9CPiBSZTogTXVsdGlwbGUgaW50ZXJmYWNl cyBwcm9ibGVtcyBpbiBNRVhUIGFuZCBtaWY8QlI+PEJSPjwvRElWPg0KPERJVj4NCjxQPkhpLCBN YXJjZWxvPC9QPg0KPFA+Rm9yIHlvcnUgcXVlc3Rpb24gYWJvdXQgd2hhdCBtaWYncyBzY29wZSBh dCB0aGUgbW9tZW50LCBKYXJpIGFscmVhZHkgbWFkZSB0aGUgY29tbWVudHMgb248QlI+PEEgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21pZi9jdXJyZW50L21zZzAw MDUwLmh0bWwiIHRhcmdldD1fYmxhbms+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL21pZi9jdXJyZW50L21zZzAwMDUwLmh0bWw8L0E+PC9QPg0KPFA+VGhlcmUgYXJlIGFsc28g c2V2ZXJhbCBQUyBkcmFmdHMgeW91IGNvdWxkIHJlZmVyIHRvOjxCUj48QSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtYmxhbmNoZXQtbWlmLXByb2JsZW0tc3RhdGVtZW50LTAw LnR4dCIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtYmxhbmNo ZXQtbWlmLXByb2JsZW0tc3RhdGVtZW50LTAwLnR4dDwvQT48QlI+PEEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2lkL2RyYWZ0LWh1aS1pcC1tdWx0aXBsZS1jb25uZWN0aW9ucy1wcy0wMS50 eHQiIHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWh1aS1pcC1t dWx0aXBsZS1jb25uZWN0aW9ucy1wcy0wMS50eHQ8L0E+PEJSPjxBIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9pZC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAwLnR4 dCIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy1tdWx0 aXBsZWlmLW1uLXBiLXN0YXRlbWVudC0wMC50eHQ8L0E+PC9QPg0KPFA+dGhhbmtzPC9QPg0KPFA+ LUh1aTxCUj48QlI+PC9QPg0KPERJViBjbGFzcz1nbWFpbF9xdW90ZT4yMDA5LzEvMjkgbWFyY2Vs byBiYWdudWxvIGJyYXVuIDxTUEFOIGRpcj1sdHI+Jmx0OzxBIGhyZWY9Im1haWx0bzptYXJjZWxv QGl0LnVjM20uZXMiIHRhcmdldD1fYmxhbms+bWFyY2Vsb0BpdC51YzNtLmVzPC9BPiZndDs8L1NQ QU4+PEJSPg0KPEJMT0NLUVVPVEUgY2xhc3M9Z21haWxfcXVvdGUgc3R5bGU9IlBBRERJTkctTEVG VDogMWV4OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAxcHgg c29saWQiPkhpIEhvbmcsPEJSPjxCUj53aGF0IGlzIHRoZSBzY29wZSBvZiBNSUY/PEJSPkkgbWVh biwgaW4gdGhlIGJvZiB3aWtpIHBhZ2UgdGhlcmUgaXMgbm8gY2hhcnRlciBwcm9wb3NlZCwgaXMg dGhlcmUgYSBjaGFydGVyIHNvbWV3aGVyZT88QlI+SW4gcGFydGljdWxhciwgaXMgTUlGIGdvaW5n IHRvIHdvcmsgaW4gTUlQdjYvTkVNTyByZWxhdGVkIGlzc3Vlcz88QlI+PEJSPlJlZ2FyZHMsIG1h cmNlbG88QlI+PEJSPjxCUj5Ib25nIFlvbmctR2V1biBlc2NyaWJpPzo8QlI+DQo8QkxPQ0tRVU9U RSBjbGFzcz1nbWFpbF9xdW90ZSBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4 IDBweCAwcHggMC44ZXg7IEJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZCI+Jm5ic3A7SGksIE1h cmNlbG8uPEJSPiZuYnNwO1RoYW5rcyBmb3IgeW91ciBjb21tZW50cy48QlI+Jm5ic3A7SSBhZ3Jl ZSB0aGF0ICZuYnNwO3RoZSBjdXJyZW50IE1FWFQgV0cgY2hhcnRlciBhbHJlYWR5IGhhcyBzZXZl cmFsIGl0ZW1zIGFib3V0IHN1cHBvcnRpbmcgbXVsdGlwbGUgaW50ZXJmYWNlcy4gDQo8RElWIGNs YXNzPUloMkUzZD48QlI+Jm5ic3A7TXkgZG9jdW1lbnRzIGFyZSBvbGQgdmVyc2lvbiB3aGljaCB3 ZXJlIHN1Ym1pdHRlZCB0byBtb25hbWk2IFdHIGF0IDY0dGggSUVURiBtZWV0aW5nIGFuZCB0aGV5 IHdlcmU8QlI+bm90IHVwZGF0ZWQgcHJvcGVybHkuIFNvLCBpdCBzZWVtcyB0aGF0IHNvbWUgY29u dGVudHMgYXJlIHNpbWlsYXIgdG8gdGhlIHdvcmtzIGluIE1FWFQgV0cuPEJSPkkgd2lsbCB1cGRh dGUgbXkgZG9jdW1lbnRzIHRvIGZvY3VzIG9uIG1pZidzIHNjb3BlLjxCUj4mbmJzcDtJdCBpcyBh cHByZWNpYXRlIHRvIHVuZGVyc3RhbmQgdGhhdCAoZXZlbiB0aG91Z2ggdGhlIHNjb3BlIG9mIG1p ZiBpcyBub3QgZml4ZWQpIG1pZiBoYXMgZGlmZmVyZW50IGRpcmVjdGlvbnMgdG88QlI+TUVYVC48 QlI+PC9ESVY+DQo8RElWIGNsYXNzPUloMkUzZD4mbmJzcDtCZXN0IHJlZ2FyZHMuPEJSPiZuYnNw O1lvbmctR2V1bi48QlI+PEJSPi0tLS0t7JuQ67O4IOuplOyLnOyngC0tLS0tPEJSPjwvRElWPipG cm9tOiogIm1hcmNlbG8gYmFnbnVsbyBicmF1biIgJmx0OzxBIGhyZWY9Im1haWx0bzptYXJjZWxv QGl0LnVjM20uZXMiIHRhcmdldD1fYmxhbms+bWFyY2Vsb0BpdC51YzNtLmVzPC9BPiZndDs8QlI+ KkZyb20gRGF0ZToqIDIwMDktMDEtMjgg7Jik7ZuEIDY6NDA6MDk8QlI+KlRvOiogIkhvbmcgWW9u Zy1HZXVuIiAmbHQ7PEEgaHJlZj0ibWFpbHRvOnlnaG9uZ0BldHJpLnJlLmtyIiB0YXJnZXQ9X2Js YW5rPnlnaG9uZ0BldHJpLnJlLmtyPC9BPiZndDs8QlI+KkNjOiogIjxBIGhyZWY9Im1haWx0bzpt ZXh0QGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPm1leHRAaWV0Zi5vcmc8L0E+IiAmbHQ7PEEgaHJl Zj0ibWFpbHRvOm1leHRAaWV0Zi5vcmciIHRhcmdldD1fYmxhbms+bWV4dEBpZXRmLm9yZzwvQT4m Z3Q7LCAiPEEgaHJlZj0ibWFpbHRvOm1pZkBpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz5taWZAaWV0 Zi5vcmc8L0E+IiAmbHQ7PEEgaHJlZj0ibWFpbHRvOm1pZkBpZXRmLm9yZyIgdGFyZ2V0PV9ibGFu az5taWZAaWV0Zi5vcmc8L0E+Jmd0OywgIjxBIGhyZWY9Im1haWx0bzpqdWxpZW4ubGFnYW5pZXIu SUVURkBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PV9ibGFuaz5qdWxpZW4ubGFnYW5pZXIuSUVURkBn b29nbGVtYWlsLmNvbTwvQT4iICZsdDs8QSBocmVmPSJtYWlsdG86anVsaWVuLmxhZ2FuaWVyLklF VEZAZ29vZ2xlbWFpbC5jb20iIHRhcmdldD1fYmxhbms+anVsaWVuLmxhZ2FuaWVyLklFVEZAZ29v Z2xlbWFpbC5jb208L0E+Jmd0OywgIjxBIGhyZWY9Im1haWx0bzpkZW5naHVpMDJAZ21haWwuY29t IiB0YXJnZXQ9X2JsYW5rPmRlbmdodWkwMkBnbWFpbC5jb208L0E+IiAmbHQ7PEEgaHJlZj0ibWFp bHRvOmRlbmdodWkwMkBnbWFpbC5jb20iIHRhcmdldD1fYmxhbms+ZGVuZ2h1aTAyQGdtYWlsLmNv bTwvQT4mZ3Q7PEJSPipTdWJqZWN0OiogUmU6IE11bHRpcGxlIGludGVyZmFjZXMgcHJvYmxlbXMg aW4gTUVYVCBhbmQgbWlmIA0KPERJVj4NCjxESVY+PC9ESVY+DQo8RElWIGNsYXNzPVdqM0M3Yz48 QlI+PEJSPjxCUj5IaSw8QlI+PEJSPkluIHRoZSBjdXJyZW50IE1FWFQgY2hhcnRlciB0aGVyZSBh cmUgc2V2ZXJhbCBpdGVtcyBhYm91dCBzdXBwb3J0aW5nPEJSPm11bHRpcGxlIGludGVyZmFjZXMs IGluY2x1ZGluZyB0aGUgZm9sbG93aW5nIHR3bzo8QlI+PEJSPi0gQSBkb2N1bWVudCBleHBsYWlu aW5nIHRoZSBtb3RpdmF0aW9ucyBmb3IgYSBub2RlIHVzaW5nIG11bHRpcGxlPEJSPmludGVyZmFj ZXMgYW5kIHRoZSBzY2VuYXJpb3Mgd2hlcmUgaXQgbWF5IGVuZCB1cCB3aXRoIG11bHRpcGxlPEJS Pmdsb2JhbCBhZGRyZXNzZXMgb24gaXRzIGludGVyZmFjZXMgW0luZm9ybWF0aW9uYWxdPEJSPjxC Uj4tIEFuIGFuYWx5c2lzIGRvY3VtZW50IGV4cGxhaW5pbmcgd2hhdCBhcmUgdGhlIGxpbWl0YXRp b25zIGZvcjxCUj5tb2JpbGUgaG9zdHMgdXNpbmcgbXVsdGlwbGUgc2ltdWx0YW5lb3VzIENhcmUt b2YgQWRkcmVzc2VzIGFuZCBIb21lPEJSPkFnZW50IGFkZHJlc3NlcyB1c2luZyBNb2JpbGUgSVB2 Niwgd2hldGhlciBpc3N1ZXMgYXJlIHNwZWNpZmljIHRvPEJSPk1vYmlsZSBJUHY2IG9yIG5vdCBb SW5mb3JtYXRpb25hbF0uPEJSPjxCUj5JIHRoaW5rIHRoaXMgaXMgdmVyeSBzaW1pbGFyIHRvIHRo ZSBzY29wZSBvZiBvbmUgb2YgeW91IGRvY3VtZW50cyBhdDxCUj5sZWFzdCwgc28gaSB3b3VsZCBm aW5kIHZlcnkgc3RyYW5nZSB0aGF0IHRoZSBzYW1lIHdvcmsgaXMgY2hhcnRlcmVkIGluPEJSPnR3 byBkaWZmZXJlbnQgd29ya2luZyBncm91cHMuPEJSPjxCUj5Nb3Jlb3Zlciwgd2UgZG8gaGF2ZSB3 ZyBkb2N1bWVudHMgZm9yIHRoZXNlIHR3bywgYnV0IHdlIGZpbmQgdmVyeSBoYXJkPEJSPnRvIGZp bmQgcmV2aWV3ZXJzIGZvciB0aG9zZSwgd2hpY2ggbWFrZXMgbWUgdGhpbmsgdGhhdCB0aGVyZSBp cyBub3QgbXVjaDxCUj5pbnRlcmVzdCBvbiB0aGVzZS4gU28sIGlmIHlvdSBmaW5kIGEgbW9yZSBt b3RpdmF0ZWQgY3JldyB0byBkbyB0aGUgd29yayw8QlI+dGhhdCB3b3VsZCBiZSBncmVhdCwgd2Ug Y2FuIGVpdGhlciBkbyBpdCBpbiBtZXh0IG9yIHNvZW13aGVyZSBlbHNlLCBpZjxCUj5wZW9wbGUg ZmVlbHMgdGhhdCBuZWVkcyB0byBiZSBkb25lLCBidXQgdGhhdCBpcyBjZXJ0YWlubHkgbm90IHRo ZTxCUj5mZWVsaW5nIGkgYW0gZ2V0dGluZyBmcm9tIHRoZSBpbnB1dCBpbiBtZXh0PEJSPjxCUj5S ZWdhcmRzLCBtYXJjZWxvPEJSPjxCUj48QlI+PEJSPkhvbmcgWW9uZy1HZXVuIGVzY3JpYmk/OjxC Uj4mZ3Q7PEJSPiZndDsgSGksIGFsbCBpbiBNRVhUIGFuZCBtaWYuPEJSPiZndDs8QlI+Jmd0OyAm Z3Q7PEJSPiZndDsgSW4gSUVURiBtaWYgKE11bHRpcGxlIEludGVyZmFjZSkgbWFpbGluZyBsaXN0 PEJSPiZndDsgKF88QSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21pZl8iIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9taWZfPC9BPjxCUj4mZ3Q7ICZsdDs8QSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21pZiIgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21pZjwvQT4mZ3Q7KSw8QlI+Jmd0OzxCUj4mZ3Q7IHdlIG5vdyBkaXNjdXNz IHRoZSBob3N0IHdoaWNoIHdvdWxkIGxpa2UgdG8gdXNlIG11bHRpcGxlIGludGVyZmFjZXMuPEJS PiZndDs8QlI+Jmd0OyBJIHVuZGVyc3RhbmQgdGhhdCBNRVhUIFdHIGlzIGFsc28gcmVsYXRlZCB0 byB0aGUgdXNlIG9mIG11bHRpcGxlPEJSPiZndDsgaW50ZXJmYWNlcyBvZiBhIGhvc3Q8QlI+Jmd0 OyB1c2luZyBNb2JpbGUgSVB2NiBvciBhIG1vYmlsZSByb3V0ZXIgdXNpbmcgTkVNTyBCYXNpYyBT dXBwb3J0IGFuZDxCUj4mZ3Q7IHRoZWlyIHZhcmlhbnRzPEJSPiZndDs8QlI+Jmd0OyBNRVhUIFdH IGlzIGZvY3Vpbmcgb24gbW9uYW1pNiByZWxhdGVkIHRvcGljIChtdWx0aXBsZSBDb0EsIE11bHRp cGxlPEJSPiZndDsgSG9BLCBhbmQgTXVsdHBsZSBIQSwgZXRjLiwpPEJSPiZndDsgYW5kIGV4dGVk bmluZyBNb2JpbGUgSVB2NiBhbmQgTkVNTyBmb3IgdGhlc2UsIGJ1dCBtaWYgaXMgbm90IHJlbGF0 ZWQ8QlI+Jmd0OyB0byB0aGlzIGRpcmVjdGlvbi48QlI+Jmd0OyBJbiBtaWYsIHNvdXJjZSBhZGRy ZXNzIHNlbGVjdGlvbiwgcm91dGluZyBhbmQgRE5TIGNvbnRyb2wgcHJvdG9jb2wgYXJlPEJSPiZn dDsgY29uc2lkZXJhdGlvbiBpdGVtczxCUj4mZ3Q7IGR1ZSB0byBtdWx0aXBsZSBpbnRlcmZhY2Vz IG9mIGEgaG9zdC48QlI+Jmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyBGb3IgbWlmJ3Mgc2NvcGUs IEphcmkgQXJra28gbWFkZSBzb21lIGNvbW1lbnRzIGFuZCBjbGFzc2lmaWNhdGlvbiBvZjxCUj4m Z3Q7IHByb2JsZW1zLjxCUj4mZ3Q7PEJSPiZndDsgXzxBIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9taWYvY3VycmVudC9tc2cwMDA1MC5odG1sXyIgdGFyZ2V0PV9i bGFuaz5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWlmL2N1cnJlbnQvbXNn MDAwNTAuaHRtbF88L0E+PEJSPiZndDs8QlI+Jmd0OyBBbW9uZyB0aGVzZSBjbGFzc2lmaWNhdGlv biB3aGljaCBpbmNsdWRlcyBhY2Nlc3Mgc2VsZWN0aW9uLCBzcGxpdCBETlMsPEJSPiZndDsgY29u ZmlndXJhdGlvbiByZWNvbmNpbGlhdGlvbiw8QlI+Jmd0OyByb3V0aW5nLCBhZGRyZXNzIHNlbGVj dGlvbiwgdHVubmVsIG11bHRpaG9taW5nLCBhbmQgdGhlIGNvbW11bmljYXRpb248QlI+Jmd0OyB3 YXkgYmV0d2VlbiB0aGUgaG9zdCBhbmQ8QlI+Jmd0OyB0aGUgbmV0d29yayBhYm91dCB0aGVpciBw b2xpY2llcyByZWdhcmRpbmcgYWxsIG9mIHRoZSBhYm92ZSwgSmFyaSBzYWlkPEJSPiZndDsgdGhh dCBhY2Nlc3Mgc2VsZWN0aW9uIGlzIGFscmVhZHk8QlI+Jmd0OyBjb3ZlcmQgaW4gUkZDIDUxMTMg YW5kIHR1bm5lbCBtdWx0aWhvbWluZyBpcyBhbHJlYWR5IGNvdmVyZWQgaW4gTUVYVDxCUj4mZ3Q7 IFdHIHdvcmsgaXRlbXMuPEJSPiZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgQXQgbW9uYW1pNiBX RyBpbiA2NHRoIElFVEYgbWVldGlubmcsIEkgc3VibWl0dGVkIGFuZCBwcmVzZW50ZWQgdHdvPEJS PiZndDsgSW50ZXJuZXQgRHJhZnRzLjxCUj4mZ3Q7PEJSPiZndDsgLSBBbmFseXNpcyBvZiBtdWx0 aXBsZSBpbnRlcmZhY2VzIGluIGEgTW9iaWxlIE5vZGU8QlI+Jmd0OzxCUj4mZ3Q7IF88QSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy1tdWx0aXBsZWlmLW1uLXBiLXN0 YXRlbWVudC0wMC50eHRfIiB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9k cmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAwLnR4dF88L0E+PEJSPiZndDs8 QlI+Jmd0OyAtIFZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgZm9yIG11bHRpcGxlIGludGVyZmFj ZXMgaW4gYSBNb2JpbGUgbm9kZTxCUj4mZ3Q7IHVzaW5nIE1vYmlsZSBJUHY2PEJSPiZndDs8QlI+ Jmd0OyBfPEEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWhvbmctdmlydHVh bGlmLW1uLW1pcHY2LTAwLnR4dF8iIHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmlldGYub3Jn L2lkL2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dF88L0E+PEJSPiZndDsgJmx0 OzxBIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ob25nLXZpcnR1YWxpZi1t bi1taXB2Ni0wMC50eHQiIHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2Ry YWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dDwvQT4mZ3Q7PEJSPiZndDs8QlI+Jmd0 OyBCZWNhdXNlIHRoZXNlIHR3byBkcmFmdHMgd2VyZSBub3QgaW4gdGhlIG1vbmFtaTYgV0cncyBz Y29wZSBhbmQ8QlI+Jmd0OyB2aXJ0dWFsIG5ldHdvcmsgaW50ZXJmYWNlIGRyYWZ0IHdhczxCUj4m Z3Q7PEJSPiZndDsgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMsIHRoZXJlIHdlcmUgbm90IGFkb3Bl ZCBpbiBtb25hbWk2IFdHJ3Mgd29yazxCUj4mZ3Q7IGl0ZW1zLiBUaGUgaW50ZW50aW9ucyBvZiB0 d28gZHJhZnRzPEJSPiZndDsgYXJlIHN1cHBvcnRpbmcgbXVsdGlwbGUgaW50ZXJmYWNlcyBvZiBh IGhvc3Qgd2l0aG91dCBleHRlbmRpbmcgTW9iaWxlPEJSPiZndDsgSVB2Ni9ORU1PLjxCUj4mZ3Q7 PEJSPiZndDsgJmd0OzxCUj4mZ3Q7IEkgdGhpbmsgdGhhdCBtdWx0aXBsZSBpbnRlcmZhY2VzIHBy b2JsZW1zIG9mIGEgaG9zdCBhcmUgcmVsYXRlZCB0bzxCUj4mZ3Q7IGJvdGggTW9iaWxlIElQL05F TU8gc3BlY2lmaWMgaXNzdWVzIGFuZDxCUj4mZ3Q7IGdlbmVyYWwgbmV0d29yayBpc3N1ZXMuIE1v YmlsZSBJUC9ORU1PIHNwZWNpZmljIGlzc3VlcyBhcmUgcmVsYXRlZCB0bzxCUj4mZ3Q7IGV4dGVu ZGluZyBvZiBNb2JpbGUgSVAvTkVNTyBhbmQ8QlI+Jmd0OyB0aGVzZSBhcmUgYWxyZWFkeSBzdHVk aWVkIGluIE1FWFQgV0cgYW5kIGdlbmVyYWwgbmV0d29yayBpc3N1ZXMgd2hpY2g8QlI+Jmd0OyB3 ZXJlIG5vdCByZWxhdGVkIHRvPEJSPiZndDsgTW9iaWxlIElQL05FTU8gY291bGQgYmUgc3R1ZGll ZCBpbiBtaWYuIEFzIHNhbWUgbWFubmVyLCBJIHRoaW5rIHRoYXQ8QlI+Jmd0OyBteSBkcmFmdHMg Y291bGQgYmUgZGlzY3Vzc2VkIGFuZDxCUj4mZ3Q7IGRldmVsb3BlZCBpbiBtaWYuIEluIHRoZSBm aXJzdCBkcmFmdCAoQW5hbHlzaXMgZG9jdW1lbnQpLCBJIGNsYXNzaWZpZWQ8QlI+Jmd0OyBtdWx0 aXBsZSBpbnRlcmZhY2UgcHJvYmxlbXMgaW50bzxCUj4mZ3Q7IE1vYmlsZSBJUHY2LXNlcGNpZmlj IGlzc3VlcywgR2VuZXJhbCBuZXR3b3JrIGlzc3VlcywgYW5kIGhldGVyb2dlbmVvdXM8QlI+Jmd0 OyBlbnZpcm9ubWVudCBpc3N1ZXMuPEJSPiZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgSW5jbHVk aW5nIEh1aSBEZW5nIGluIG1pZiwgd2l0aCByZWdhcmRpbmcgdG8gdGhlc2UgZHJhZnRzLCB0aGV5 IHdhbnQ8QlI+Jmd0OyB0byBoZWFyIGNvbW1lbnRzIGZyb20gTUVYVCBXRydzIHBvaW50IG9mIHZp ZXcsPEJSPiZndDsgYmVjYXVzZSBpdCBzZWVtcyB0aGF0IHRoZXNlIGRyYWZ0cyBhcmUgcXVpdGUg cmVsYXRlZCB0byBtb25hbWk2L01FWFQ8QlI+Jmd0OyBXRy4gU28sIEkgYXNrIE1FWFQgdG8gcmV2 aWV3IHdoZXRoZXIgdGhlcmUgYXJlPEJSPiZndDs8QlI+Jmd0OyBzb21lIG92ZXJsYXAgYmV0d2Vl biBNRVhUIHdvcmtzIGFuZCBteSBkcmFmdHMgb3Igbm90LjxCUj4mZ3Q7PEJSPiZndDsgSXQgaXMg YXBwcmVjaWF0ZSB0byBnaXZlIGNvbW1lbnRzLjxCUj4mZ3Q7PEJSPiZndDsgJmd0OzxCUj4mZ3Q7 IEJlc3QgcmVnYXJkcy48QlI+Jmd0OzxCUj4mZ3Q7IFlvbmctR2V1bi48QlI+Jmd0OzxCUj48QlI+ PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjxCUj48L0JMT0NLUVVPVEU+PC9ESVY+PEJSPjwvRElW PjwvRElWPjxpbWcgc3R5bGU9ImRpc3BsYXk6bm9uZSIgd2lkdGg9MCBoZWlnaHQ9MCBzcmM9Imh0 dHA6Ly91bWFpbC5ldHJpLnJlLmtyL0V4dGVybmFsX1JlYWRDaGVjay5hc3B4P2VtYWlsPW1leHRA aWV0Zi5vcmcmbmFtZT1tZXh0JTQwaWV0Zi5vcmcmZnJvbWVtYWlsPXlnaG9uZ0BldHJpLnJlLmty Jm1lc3NhZ2VpZD0lM0MwNmEwYWIyYS00OThhLTRiODYtOGUzZS05MzMzN2QxZjFhNGFAZXRyaS5y ZS5rciUzRSI+ ------=_NextPart_000_29B2_01C982C5.FCBB47B0-- --===============1637277638== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1637277638==-- From mext-bounces@ietf.org Thu Jan 29 17:52:02 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E290528C219; Thu, 29 Jan 2009 17:52:02 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367F43A6403 for ; Thu, 29 Jan 2009 17:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.63 X-Spam-Level: X-Spam-Status: No, score=0.63 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEchhfKySqF7 for ; Thu, 29 Jan 2009 17:52:00 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id 21BE33A66B4 for ; Thu, 29 Jan 2009 17:51:59 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Fri, 30 Jan 2009 10:51:40 +0900 Priority: normal X-ReadCheckName: mext%40ietf.org Thread-Topic: Re: [mif] Multiple interfaces problems in MEXT and mif X-ReadCheckMessageID: thread-index: AcmCfUtx9ESXBeVCSgmwzQJc5IY4rg== From: "Hong Yong-Geun" To: "Marc Blanchet" , "Scott Brim" Date: Fri, 30 Jan 2009 10:51:40 +0900 Comment: ??, u-??, Message-ID: <327401c9827d$4b7b3b60$8310fe81@etri.info> MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 Content-class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 X-OriginalArrivalTime: 30 Jan 2009 01:51:40.0754 (UTC) FILETIME=[4B97EB20:01C9827D] Cc: mif@ietf.org, julien.laganier.IETF@googlemail.com, mext@ietf.org Subject: Re: [MEXT] [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0671012294==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0671012294== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----=_NextPart_000_3260_01C982C8.BB5BDE80" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_3260_01C982C8.BB5BDE80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 ------=_NextPart_000_3260_01C982C8.BB5BDE80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj5JIGFncmVlIHRvIE1hcmMuPEJSPjxCUj5JdCBpcyBiZXR0ZXIgdG8gZGlzY3Vz cyBtaWYncyBzY29wZSB3aXRoIGEgcG9zc2libGUgY2hhcnRlci48QlI+PEJSPkJlc3QgcmVnYXJk cy48QlI+PEJSPllvbmctR2V1bi48L0RJVj4NCjxESVY+PEJSPi0tLS0t7JuQ67O4IOuplOyLnOyn gC0tLS0tPEJSPjxCPkZyb206PC9CPiAiTWFyYyBCbGFuY2hldCIgJmx0O21hcmMuYmxhbmNoZXRA dmlhZ2VuaWUuY2EmZ3Q7PEJSPjxCPkZyb20gRGF0ZTo8L0I+IDIwMDktMDEtMzAg7Jik7KCEIDU6 NDE6NDg8QlI+PEI+VG86PC9CPiAiU2NvdHQgQnJpbSIgJmx0O3N3YkBlbXBsb3llZXMub3JnJmd0 OzxCUj48Qj5DYzo8L0I+ICJqdWxpZW4ubGFnYW5pZXIuSUVURkBnb29nbGVtYWlsLmNvbSIgJmx0 O2p1bGllbi5sYWdhbmllci5JRVRGQGdvb2dsZW1haWwuY29tJmd0OywgIm1pZkBpZXRmLm9yZyIg Jmx0O21pZkBpZXRmLm9yZyZndDssICJtZXh0QGlldGYub3JnIiAmbHQ7bWV4dEBpZXRmLm9yZyZn dDs8QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBbbWlmXSBNdWx0aXBsZSBpbnRlcmZhY2VzIHByb2Js ZW1zIGluIE1FWFQgYW5kIG1pZjxCUj48QlI+DQo8RElWPjwhLS0gQ29udmVydGVkIGZyb20gdGV4 dC9wbGFpbiBmb3JtYXQgLS0+PEJSPg0KPFA+PEZPTlQgc2l6ZT0yPlNjb3R0IEJyaW0gYSA/Y3Jp dCA6PEJSPiZndDsgRXhjZXJwdHMgZnJvbSBtYXJjZWxvIGJhZ251bG8gYnJhdW4gb24gVGh1LCBK YW4gMjksIDIwMDkgMDk6MDk6NTVQTTxCUj4mZ3Q7ICswMTAwOjxCUj4mZ3Q7Jmd0OyBtYWtlcyBz ZW5zZSB0byBtZTxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBNYXJjIEJsYW5jaGV0IGVzY3JpYmk/ OjxCUj4mZ3Q7Jmd0OyZndDsgdG8gbWUsIHRoZSBtYWluIGRpZmZlcmVuY2UgaXMgdGhhdCB0aGUg J211bHRpcGxlIGludGVyZmFjZScgaXNzdWU8QlI+Jmd0OyZndDsmZ3Q7IGlzIG5vdCBib3VuZCB0 byBtb2JpbGl0eSwgYW5kIG1vcmUgc3BlY2lmaWNhbGx5IHRvIG1vYmlsaXR5PEJSPiZndDsmZ3Q7 Jmd0OyBwcm90b2NvbHMgKG1vYmlsZUlQdjQsIG1vYmlsZWlwdjYsIG5lbW8sIC4uLikuPEJSPiZn dDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDsgVGhlcmVmb3JlLCB0aGUgTUlGIHdvcmsgaXMgbm90 IHNjb3BpbmcgYWJvdXQgbW9iaWxpdHkgcHJvdG9jb2xzIGFuZDxCUj4mZ3Q7Jmd0OyZndDsgc2hh bGwgbm90IHJlcXVpcmUgbW9iaWxpdHkgcHJvdG9jb2xzLjxCUj4mZ3Q7Jmd0OyZndDs8QlI+Jmd0 OyZndDsmZ3Q7IEkgd291bGQgc2VlIHRoYXQgaWYgc29tZSBwYXJ0IG9mIHRoZSBNSUYgd29yayBp cyBsb29raW5nIGF0IHRoZTxCUj4mZ3Q7Jmd0OyZndDsgbW9iaWxpdHkgcHJvdG9jb2xzLCB0aGVu IHRoZXNlIHNob3VsZCBiZSB0aGVuICJ0cmFuc2ZlcmVkIiB0byBNRVhULjxCUj4mZ3Q7PEJSPiZn dDsgRXZlbiB3aXRob3V0IG1vYmlsaXR5IGNvbnNpZGVyYXRpb25zLCB0aGUgaXNzdWUgb2YgaG93 IHRvIGhhbmRsZTxCUj4mZ3Q7IG11bHRpcGxlIGludGVyZmFjZXMgb3ZlcmxhcHMgd2l0aCBJbnRB cmVhLCBSUkcsIGFuZCBCZWhhdmUgKHRob3NlIGFyZTxCUj4mZ3Q7IHRoZSBvbmVzIEkgY2FuIHRo aW5rIG9mIG9mZmhhbmQpLiZuYnNwOyBIYXZlIHlvdSBzZWVuIHRoZSBhcmd1bWVudHMsIGZvcjxC Uj4mZ3Q7IGV4YW1wbGUsIGFib3V0IHNlc3Npb24gaW5pdGlhbGl6YXRpb24gd2hlbiBtdWx0aXBs ZSBhZGRyZXNzZXMgY2FuIGJlPEJSPiZndDsgaW4gcGxheSBzaW11bHRhbmVvdXNseSBhdCBib3Ro IGVuZHM/Jm5ic3A7IEkgYXBvbG9naXplIGJ1dCBJIHN0aWxsIGRvbid0PEJSPiZndDsgdW5kZXJz dGFuZCB0aGUgTUlGIGJvdW5kYXJpZXMuPEJSPjxCUj5vZiBjb3Vyc2UsIHRoZXJlIGlzIG92ZXJs YXAsIGFzIG1vc3QgSUVURiBpc3N1ZXMgYW5kIHdvcmsgc3BhbiBvdmVyPEJSPm11bHRpcGxlIGdy b3Vwcy48QlI+PEJSPnRvIG1lLCB0aGUgcXVlc3Rpb24gaW4gaGFuZCBpcyB0aGUgZm9sbG93aW5n OjxCUj5hKSBkbyB3ZSB0aGluayB0aGlzIGlzIGEgInJlYWwiIHByb2JsZW08QlI+YikgaWYgeWVz LCB0aGVuIHdoYXQgc2hvdWxkIHdlIGRvIHdpdGggaXQuPEJSPmMpIGlmIHdoYXQgPSBwb3NzaWJs ZSB3ZywgdGhlbiB3cml0ZSBjaGFydGVyLCAuLi48QlI+PEJSPnRvIG1lLCBhKSBhbmQgYikgYXJl IGNsZWFybHkgc3ViamVjdCBvZiB0aGUgQk9GLiBjKSBkZXBlbmRzIG9uIHRoZTxCUj5vdXRjb21l IG9mIHRoZSBCT0YuPEJSPjxCUj5Mb29raW5nIGF0IHRoZSB2YXJpb3VzIGNvbW1lbnRzIG92ZXIg dGhlIHBhc3Qgd2Vla3MsIGl0IG1pZ2h0IGJlIGdvb2Q8QlI+dGhhdCB3ZSAodGhlIGluaXRpYWwg cHJvcG9zZXJzIG9yIGFueW9uZSBJIHNoYWxsIHNheSkgc2hvdWxkIHdyaXRlIGE8QlI+cG9zc2li bGUgd2cgY2hhcnRlciBiYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbnMuIFdlIG1pZ2h0IHRoZW4gZGVm aW5lIHRoZTxCUj5zY29wZSBhbmQgdGhlIG91dCBvZiBzY29wZS4uLjxCUj48QlI+TWFyYy48QlI+ Jmd0OzxCUj4mZ3Q7IFRoYW5rcyAuLi4gU2NvdHQ8QlI+PEJSPjxCUj4tLTxCUj49PT09PT09PT08 QlI+SVB2NiBib29rOiBNaWdyYXRpbmcgdG8gSVB2NiwgV2lsZXkuIDxBIGhyZWY9Imh0dHA6Ly93 d3cuaXB2NmJvb2suY2EvIiB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly93d3cuaXB2NmJvb2suY2E8L0E+ PEJSPlN0dW4vVHVybiBzZXJ2ZXIgZm9yIFZvSVAgTkFULUZXIHRyYXZlcnNhbDogPEEgaHJlZj0i aHR0cDovL251bWIudmlhZ2VuaWUuY2EvIiB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly9udW1iLnZpYWdl bmllLmNhPC9BPjxCUj5EVE4gbmV3cyBzZXJ2aWNlOiA8QSBocmVmPSJodHRwOi8vcmVldmVzLnZp YWdlbmllLmNhLyIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vcmVldmVzLnZpYWdlbmllLmNhPC9BPjxC Uj48QlI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+ bWlmIG1haWxpbmcgbGlzdDxCUj5taWZAaWV0Zi5vcmc8QlI+PEEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWYiIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWY8L0E+PEJSPjwvRk9OVD48L1A+PC9ESVY+PC9E SVY+PC9ESVY+PGltZyBzdHlsZT0iZGlzcGxheTpub25lIiB3aWR0aD0wIGhlaWdodD0wIHNyYz0i aHR0cDovL3VtYWlsLmV0cmkucmUua3IvRXh0ZXJuYWxfUmVhZENoZWNrLmFzcHg/ZW1haWw9bWV4 dEBpZXRmLm9yZyZuYW1lPW1leHQlNDBpZXRmLm9yZyZmcm9tZW1haWw9eWdob25nQGV0cmkucmUu a3ImbWVzc2FnZWlkPSUzQ2ExMTQ1NDdlLWFmYWUtNGI1OS04ZmQyLTI4ZWUwYjRkYTEyYkBldHJp LnJlLmtyJTNFIj4= ------=_NextPart_000_3260_01C982C8.BB5BDE80-- --===============0671012294== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0671012294==-- From mext-bounces@ietf.org Thu Jan 29 20:21:54 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6773A6928; Thu, 29 Jan 2009 20:21:54 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBE773A6851 for ; Thu, 29 Jan 2009 20:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjQwOZ3MjiUQ for ; Thu, 29 Jan 2009 20:21:52 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BA4173A6928 for ; Thu, 29 Jan 2009 20:21:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,348,1231113600"; d="scan'208,217";a="135506764" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 30 Jan 2009 04:21:34 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n0U4LY1P020327 for ; Thu, 29 Jan 2009 20:21:34 -0800 Received: from sj-webmail-3.cisco.com (sj-webmail-3.cisco.com [171.70.156.8]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0U4LYXK015345 for ; Fri, 30 Jan 2009 04:21:34 GMT Received: from sj-webmail-3.cisco.com (localhost.localdomain [127.0.0.1]) by sj-webmail-3.cisco.com (8.13.1/8.13.1) with ESMTP id n0U4LY0d009170 for ; Thu, 29 Jan 2009 20:21:34 -0800 Received: from sj-webmail-3 (root@localhost) by sj-webmail-3.cisco.com (8.13.1/8.13.1/Submit) with ESMTP id n0U4LYak009169 for ; Thu, 29 Jan 2009 20:21:34 -0800 Received: from kowsalyawxp ( [10.77.139.58]) by sj-webmail-3 (Scalix SMTP Relay 10.0.5.3) via ESMTP; Thu, 29 Jan 2009 20:21:33 -0800 (PST) Date: Fri, 30 Jan 2009 09:51:31 +0530 From: Kowsalya Subramanian To: Message-ID: <006801c98292$3ba47700$3a8b4d0a@cisco.com> x-scalix-Hops: 1 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmCkjqnQIi09wzwReueGggZwiVXxw== MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3469; t=1233289294; x=1234153294; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kowsalya@cisco.com; z=From:=20Kowsalya=20Subramanian=20 |Subject:=20Clarifications=20required=20on=20BRI=20sequence =20number=20[draft-muhanna-mext-binding-revocation-02] |Sender:=20; bh=D4dB6mOujVbLaXuBadVNBdHY0ZmJ/ivASNXL5mdXe60=; b=KsIgupnUwHnvUa55A9ZRGddKbl+fi+3v7QcOg66d3PaIlrXdrEvwwx9mhP Rq+RYDOppr0vUmopO1XdFEOE6jFNFDvF8xDL7AaHWZRMaXzVxIjNqsCHiDhx XWSd32tYa3; Authentication-Results: sj-dkim-4; header.From=kowsalya@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [MEXT] Clarifications required on BRI sequence number [draft-muhanna-mext-binding-revocation-02] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1297549792==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1297549792== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01C982C0.555CB300" ------=_NextPart_000_0069_01C982C0.555CB300 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Hi, In the draft, there is text mentioning that the initiator of the BRI message MUST choose a monotonically increasing sequence number. Lets consider a case where the BCE has 3 HNPs bound to it. If the LMA sends a BRI with seq number 5 for {MN-ID, HNP1} and then wants to send a BRI for {MN-ID, HNP2}. Should it wait till it gets a BRA for the previous BRI that it sent? If LMA need not wait for the BRA, then it is possible that MAG receives BRI 5, 6 out of order. In which case, what should the MAG do, should it ignore BRI 5 as it has already got BRI 6. In other words, is the sequence number in BRI indicates some form of versioning for the deletion or is it just to match only BRA and identify BRI re-transmissions. If it is the latter, why should it be monotonically increasing, it can just be unique. Am I missing something here? Thanks Kowsalya ------=_NextPart_000_0069_01C982C0.555CB300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi,
 
In the d= raft, there=20 is text mentioning that the initiator of the BRI message MUST choose= a=20 monotonically increasing sequence number.
 
Lets consider a case where the BCE has 3 HNPs bound= to it. If=20 the LMA sends a BRI with seq number 5 for {MN-ID, HNP1} and then wants to= send a=20 BRI for {MN-ID, HNP2}. Should it wait till it gets a BRA for the previous= BRI=20 that it sent? If LMA need not wait for the BRA, then it is possible that M= AG=20 receives BRI 5, 6 out of order. In which case, what should the MAG do, sh= ould it=20 ignore BRI 5 as it has already got BRI 6.
 
In othe= r words, is=20 the sequence number in BRI indicates some form of versioning for the dele= tion or=20 is it just to match only BRA and identify BRI re-transmissions. If it is t= he=20 latter, why should it be monotonically increasing, it can just be=20 unique.
 
Am I mi= ssing=20 something here?
 
Thanks
Kowsalya
------=_NextPart_000_0069_01C982C0.555CB300-- --===============1297549792== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1297549792==-- From mext-bounces@ietf.org Thu Jan 29 23:35:49 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A470C3A6A93; Thu, 29 Jan 2009 23:35:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698E93A6A64 for ; Thu, 29 Jan 2009 23:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twOpnwBB7-QC for ; Thu, 29 Jan 2009 23:35:47 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 56CC93A68CF for ; Thu, 29 Jan 2009 23:35:47 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n0U7V7D27390; Fri, 30 Jan 2009 07:31:08 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 Jan 2009 01:33:21 -0600 Message-ID: In-Reply-To: <006801c98292$3ba47700$3a8b4d0a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Clarifications required on BRI sequence number[draft-muhanna-mext-binding-revocation-02] Thread-Index: AcmCkjqnQIi09wzwReueGggZwiVXxwAGlFxg References: <006801c98292$3ba47700$3a8b4d0a@cisco.com> From: "Ahmad Muhanna" To: "Kowsalya Subramanian" , Subject: Re: [MEXT] Clarifications required on BRI sequence number[draft-muhanna-mext-binding-revocation-02] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1051829577==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1051829577== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C982AD.0A86FF22" This is a multi-part message in MIME format. ------_=_NextPart_001_01C982AD.0A86FF22 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Kowsalya Subramanian Sent: Thursday, January 29, 2009 10:22 PM To: mext@ietf.org Subject: [MEXT] Clarifications required on BRI sequence number[draft-muhanna-mext-binding-revocation-02] =09 =09 Hi, =20 In the draft, there is text mentioning that the initiator of the BRI message MUST choose a monotonically increasing sequence number. =20 =20 [Ahmad] Where are you reading from. Please refer to the latest MEXT wg draft at the below link: =09 http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-0 3.txt=20 =20 =20 =20 Lets consider a case where the BCE has 3 HNPs bound to it. If the LMA sends a BRI with seq number 5 for {MN-ID, HNP1} and then wants to send a BRI for {MN-ID, HNP2}. Should it wait till it gets a BRA for the previous BRI that it sent? If LMA need not wait for the BRA, then it is possible that MAG receives BRI 5, 6 out of order. In which case, what should the MAG do, should it ignore BRI 5 as it has already got BRI 6. =20 In other words, is the sequence number in BRI indicates some form of versioning for the deletion or is it just to match only BRA and identify BRI re-transmissions. If it is the latter, why should it be monotonically increasing, it can just be unique. =20 Am I missing something here? =20 Thanks Kowsalya ------_=_NextPart_001_01C982AD.0A86FF22 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
From: mext-bounces@ietf.org=20 [mailto:mext-bounces@ietf.org] On Behalf Of Kowsalya=20 Subramanian
Sent: Thursday, January 29, 2009 10:22 = PM
To:=20 mext@ietf.org
Subject: [MEXT] Clarifications required on BRI = sequence = number[draft-muhanna-mext-binding-revocation-02]

Hi,
 
In the=20 draft, there is text mentioning that the initiator of the BRI = message=20 MUST choose a monotonically increasing sequence number.  
 
[Ahmad]
Where are you reading = from.=20 Please refer to the latest MEXT wg draft at the below=20 link:
http://www.ietf.org/internet-drafts/draft-ietf-mext-binding= -revocation-03.txt 
 
 
 
Lets consider a = case where=20 the BCE has 3 HNPs bound to it. If the LMA sends a BRI with seq number = 5 for=20 {MN-ID, HNP1} and then wants to send a BRI for {MN-ID, HNP2}. Should = it wait=20 till it gets a BRA for the previous BRI that it sent? If LMA need not = wait for=20 the BRA, then it is possible that MAG receives BRI 5, 6 out of order. = In which=20 case, what should the MAG do, should it ignore BRI 5 as it has already = got BRI=20 6.
 
In = other words, is=20 the sequence number in BRI indicates some form of versioning for the = deletion=20 or is it just to match only BRA and identify BRI re-transmissions. If = it is=20 the latter, why should it be monotonically increasing, it can just be=20 unique.
 
Am I = missing=20 something here?
 
Thanks
Kowsalya
------_=_NextPart_001_01C982AD.0A86FF22-- --===============1051829577== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1051829577==--