[lisp] Deadline for proposed changes to draft-ietf-lisp-04.txt is Friday Sep 4th
Dino Farinacci <dino@cisco.com> Mon, 31 August 2009 18:02 UTC
Return-Path: <dino@cisco.com>
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C85D28C45A for <lisp@core3.amsl.com>; Mon, 31 Aug 2009 11:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.549
X-Spam-Level:
X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=-1.917, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4, SARE_HTML_SINGLETS=1.666]
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 1I6FAUKGcDwp for <lisp@core3.amsl.com>; Mon, 31 Aug 2009 11:02:16 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D563F28C444 for <lisp@ietf.org>; Mon, 31 Aug 2009 11:01:26 -0700 (PDT)
X-Files: rfcdiff-lisp-03-to-04.html : 155807
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4GAPesm0qrR7MV/2dsb2JhbACCJTG/KIhBASqOVAWCMgEECIFbgVqJJg
X-IronPort-AV: E=Sophos; i="4.44,306,1249257600"; d="html'217?scan'217,208,217"; a="186659377"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 31 Aug 2009 18:01:34 +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 n7VI1YiB003197 for <lisp@ietf.org>; Mon, 31 Aug 2009 11:01:34 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7VI1YKN026634 for <lisp@ietf.org>; Mon, 31 Aug 2009 18:01:34 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 11:01:34 -0700
Received: from [192.168.1.4] ([10.21.85.224]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 11:01:34 -0700
Message-Id: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com>
From: Dino Farinacci <dino@cisco.com>
To: lisp@ietf.org
Content-Type: multipart/mixed; boundary="Apple-Mail-99-704070638"
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Mon, 31 Aug 2009 11:01:33 -0700
X-Mailer: Apple Mail (2.935.3)
X-OriginalArrivalTime: 31 Aug 2009 18:01:34.0284 (UTC) FILETIME=[13A0A8C0:01CA2A65]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=163447; t=1251741694; x=1252605694; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20<dino@cisco.com> |Subject:=20Deadline=20for=20proposed=20changes=20to=20draf t-ietf-lisp-04.txt=20is=20Friday=20Sep=204th |Sender:=20; bh=yoPmJ0USwOFEBwFsoJe76VBRsS9KadB5oWEnssHWGz4=; b=WxMGzDJSzy0BNr/qIl1EvOZYvtF5yrDl3EZ0IyJ0J7HQhLfrjltGIzmt79 SOJ6CMNh+6CtyfesSFDBBOPmLDWXs8kColRZ6tbgL1PiTzJ4We11L1gieR4a gmlP186Vq2jTs8BjwjotjU0JfqxPm5MJSp0REUaN1hTk/IvhCZDmg=;
Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
Subject: [lisp] Deadline for proposed changes to draft-ietf-lisp-04.txt is Friday Sep 4th
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 18:02:26 -0000
Just a friendly reminder that the proposed changes to draft-ietf- lisp-04.txt is this Friday September 4th. Thank you to all who have sent us comments last week. For those of you who have not reviewed the diffs yet, you can look at the updated html diff file enclosed. The change-log of the proposed changes is also enclosed. Please note there are 6 additional change-log entries at the end reflecting comments we received last week. Thanks a lot, Dino/Dave/Darrel/Vince ------------------------------------------------------------------------------- Changes planned for draft-ietf-lisp-04.txt: * How do deal with record count greater than 1 for a Map-Request. Damien and Joel comment. Joel suggests: 1) Specify that senders compliant with the current document will always set the count to 1, and note that the count is included for future extensibility. 2) Specify what a receiver compliant with the draft should do if it receives a request with a count greater than 1. Presumably, it should send some error back? * Add Fred Templin in ack section. * Add Margaret and Sam to the ack section for their great comments. * Say more about LAGs in the UDP section per Sam Hartman's comment. * Sam wants to use MAY instead of SHOULD for ignoring checkums on ETR. From the mailing list: You'd need to word it as an ITR MAY send a zero checksum, an ETR MUST accept a 0 checksum and MAY ignore the checksum completely. And of course we'd need to confirm that can actually be implemented. In particular, hardware that verifies UDP checksums on receive needs to be checked to make sure it permits 0 checksums. * Margaret wants a reference to http://www.ietf.org/id/draft-eubanks- chimento-6man-00.txt. * Fix description in Map-Request section. Where we describe Map-Reply Record, change "R-bit" to "M-bit". * Add the mobility bit to Map-Replies. So PTRs don't probe so often for MNs but often enough to get mapping updates. * Indicate SHA1 can be used as well for Map-Registers. * More Fred comments on MTU handling. * Isidor comment about specing better periodic Map-Registers. Will be fixed in draft-ietf-lisp-ms-02.txt. * Margaret's comment on gleaning: The current specification does not make it clear how long gleaned map entries should be retained in the cache, nor does it make it clear how/ when they will be validated. The LISP spec should, at the very least, include a (short) default lifetime for gleaned entries, require that they be validated within a short period of time, and state that a new gleaned entry should never overwrite an entry that was obtained from the mapping system. The security implications of storing "gleaned" entries should also be explored in detail. * Add section on RLOC-probing per working group feedback. * Change "loc-reach-bits" to "loc-status-bits" per comment from Noel. * Remove SMR-bit from data-plane. Dino prefers to have it in the control plane only. * Change LISP header to allow a "Research Bit" so the Nonce and LSB fields can be turned off and used for another future purpose. For Luigi et al versioning convergence. * Add a N-bit to the data header suggested by Noel. Then the nonce field could be used when N is not 1. * Clarify that when E-bit is 0, the nonce field can be an echoed nonce or a random nonce. Comment from Jesper. * Indicate when doing data-gleaning that a verifying Map-Request is sent to the source-EID of the gleaned data packet so we can avoid map- cache corruption by a 3rd party. Comment from Pedro. * Indicate that a verifying Map-Request, for accepting mapping data, should be sent over the the ALT (or to the EID). * Reference IPsec RFC 4302. Comment from Sam and Brian Weis. * Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- noncing. Comment by Pedro and Dino. * Jesper made a comment to loosen the language about requiring the copy of inner TTL to outer TTL since the text to get mixed-AF traceroute to work would violate the "MUST" clause. Changed from MUST to SHOULD in section 5.3. -------------------------------------------------------------------------------
- Re: [lisp] Meanign of R bit Joel M. Halpern
- Re: [lisp] Map-Reply M bit? Joel M. Halpern
- [lisp] Deadline for proposed changes to draft-iet… Dino Farinacci
- Re: [lisp] Deadline for proposed changes to draft… Sam Hartman
- Re: [lisp] Deadline for proposed changes to draft… Dino Farinacci
- Re: [lisp] Suggested UDP checksum text Joel M. Halpern
- Re: [lisp] Suggested UDP checksum text Dino Farinacci
- Re: [lisp] Meanign of R bit Dino Farinacci
- Re: [lisp] Meanign of R bit Joel M. Halpern
- Re: [lisp] Meanign of R bit Dino Farinacci
- Re: [lisp] Map-Reply M bit? David Meyer
- Re: [lisp] Map-Reply M bit? Joel M. Halpern
- Re: [lisp] Map-Reply M bit? Dino Farinacci
- Re: [lisp] Map-Reply M bit? David Meyer
- Re: [lisp] Map-Reply M bit? Joel M. Halpern
- Re: [lisp] Map-Reply M bit? Dino Farinacci
- Re: [lisp] Map-Reply M bit? Joel M. Halpern
- Re: [lisp] Map-Reply M bit? Dino Farinacci
- Re: [lisp] Map-Reply M bit? Joel M. Halpern
- Re: [lisp] Map-Reply M bit? Dino Farinacci
- Re: [lisp] Map-Reply M bit? Joel M. Halpern
- Re: [lisp] Suggested UDP checksum text Margaret Wasserman
- Re: [lisp] Suggested UDP checksum text Margaret Wasserman
- Re: [lisp] Meanign of R bit Margaret Wasserman
- Re: [lisp] Map-Reply M bit? Margaret Wasserman
- Re: [lisp] Map-Reply M bit? Margaret Wasserman
- Re: [lisp] Suggested UDP checksum text Sam Hartman
- Re: [lisp] Deadline for proposed changes to draft… Michael Höfling
- Re: [lisp] Suggested UDP checksum text Margaret Wasserman
- Re: [lisp] Deadline for proposed changes to draft… Dino Farinacci
- Re: [lisp] Suggested UDP checksum text Dino Farinacci
- Re: [lisp] Suggested UDP checksum text Dino Farinacci
- Re: [lisp] Deadline for proposed changes to draft… Sam Hartman
- Re: [lisp] Suggested UDP checksum text Sam Hartman
- [lisp] Changes proposed in 04 that have not yet d… Sam Hartman
- [lisp] Changes that have demonstrated sufficient … Sam Hartman
- Re: [lisp] Changes proposed in 04 that have not y… Dino Farinacci
- Re: [lisp] Changes that have demonstrated suffici… Dino Farinacci
- Re: [lisp] Suggested UDP checksum text Margaret Wasserman
- Re: [lisp] Changes proposed in 04 that have not y… Sam Hartman
- Re: [lisp] Suggested UDP checksum text Dino Farinacci
- Re: [lisp] Suggested UDP checksum text Joel M. Halpern
- Re: [lisp] Suggested UDP checksum text Margaret Wasserman
- Re: [lisp] Suggested UDP checksum text Margaret Wasserman
- Re: [lisp] Changes proposed in 04 that have not y… Dino Farinacci
- Re: [lisp] Suggested UDP checksum text Marshall Eubanks
- Re: [lisp] Suggested UDP checksum text Marshall Eubanks
- Re: [lisp] Suggested UDP checksum text Dino Farinacci
- [lisp] #2: IPsec or just IPsec headers; sha-1 size Sam Hartman
- Re: [lisp] Suggested UDP checksum text Margaret Wasserman
- Re: [lisp] #2: IPsec or just IPsec headers; sha-1… Dino Farinacci
- Re: [lisp] Suggested UDP checksum text Dino Farinacci
- Re: [lisp] Suggested UDP checksum text Margaret Wasserman
- Re: [lisp] Suggested UDP checksum text Dino Farinacci
- Re: [lisp] Suggested UDP checksum text Marshall Eubanks
- Re: [lisp] Suggested UDP checksum text Marshall Eubanks
- Re: [lisp] #2: IPsec or just IPsec headers; sha-1… Laganier, Julien