From Tina.Tsou.Zouting@huawei.com Fri Feb 1 09:50:25 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C843F21E80D2 for ; Fri, 1 Feb 2013 09:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VC0Fz4POmw4S for ; Fri, 1 Feb 2013 09:50:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A8D8121E80D1 for ; Fri, 1 Feb 2013 09:50:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id API54750; Fri, 01 Feb 2013 17:50:22 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 1 Feb 2013 17:49:41 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 1 Feb 2013 17:50:21 +0000 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.4]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.007; Fri, 1 Feb 2013 09:50:14 -0800 From: Tina TSOU To: "Softwires@Ietf. Org" Thread-Topic: New Version Notification for draft-tsou-softwire-bfd-ds-lite-04.txt Thread-Index: AQHOAKRy3mJquKIRiE+oZ/IoDBy9gZhlR+TY Date: Fri, 1 Feb 2013 17:50:14 +0000 Message-ID: <2ACBDE7E-42B4-43DA-ACBC-C17EE65445BC@huawei.com> References: <20130201174904.9314.39378.idtracker@ietfa.amsl.com> In-Reply-To: <20130201174904.9314.39378.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_2ACBDE7E42B443DAACBCC17EE65445BChuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Softwires] Fwd: New Version Notification for draft-tsou-softwire-bfd-ds-lite-04.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 17:50:25 -0000 --_000_2ACBDE7E42B443DAACBCC17EE65445BChuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, For your comments. Thank you, Tina Begin forwarded message: From: > Date: February 1, 2013 9:49:04 AM PST To: > Cc: >, >, >, >, > Subject: New Version Notification for draft-tsou-softwire-bfd-ds-lite-04.tx= t A new version of I-D, draft-tsou-softwire-bfd-ds-lite-04.txt has been successfully submitted by Tina Tsou and posted to the IETF repository. Filename: draft-tsou-softwire-bfd-ds-lite Revision: 04 Title: DS-Lite Failure Detection and Failover Creation date: 2013-02-01 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-tsou-softwire-bf= d-ds-lite-04.txt Status: http://datatracker.ietf.org/doc/draft-tsou-softwire-bfd-ds= -lite Htmlized: http://tools.ietf.org/html/draft-tsou-softwire-bfd-ds-lite= -04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-tsou-softwire-bfd= -ds-lite-04 Abstract: In DS-Lite, the tunnel is stateless, not associated with any state information, and no failure detection and failover mechanism is available. This makes it difficult to manage and diagnose if there is a problem. This draft analyzes the applicability of some of the possible solutions. The IETF Secretariat --_000_2ACBDE7E42B443DAACBCC17EE65445BChuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,
For your comments.

Thank you,
Tina

Begin forwarded message:

From: <internet-= drafts@ietf.org>
Date: February 1, 2013 9:49:04 AM PST
To: <tina.tsou.zo= uting@huawei.com>
Cc: <brandon.lijian@= huawei.com>, <repenno@cisco.= com>, <cathy.zhou@huawei= .com>, <mohamed.b= oucadair@orange.com>, <j.schoenwaelde= r@jacobs-university.de>
Subject: New Version Notification for draft-tsou-softwire-bfd-ds-= lite-04.txt


A new version of I-D, draft-tsou-softwire-bfd-ds-lite-04.txt has been successfully submitted by Tina Tsou and posted to the=
IETF repository.

Filename:     draft-tsou-softwire-bfd-ds-lite
Revision:     04
Title:         DS-Lite Failure Detection and Fail= over
Creation date:     2013-02-01
WG ID:         Individual Submission
Number of pages: 10
URL:           &nbs= p; http://www.ietf.org/internet-drafts/draft-tsou-softwire= -bfd-ds-lite-04.txt
Status:          http:/= /datatracker.ietf.org/doc/draft-tsou-softwire-bfd-ds-lite
Htmlized:        http://tools.ietf.= org/html/draft-tsou-softwire-bfd-ds-lite-04
Diff:           &nb= sp;http://www.ietf.org/rfcdiff?url2=3Ddraft-tsou-softwire-bfd-ds-lit= e-04

Abstract:
  In DS-Lite, the tunnel is stateless, not associated with = any state
  information, and no failure detection and failover mechan= ism is
  available.  This makes it difficult to manage and di= agnose if there
  is a problem.  This draft analyzes the applicability= of some of the
  possible solutions.




The IETF Secretariat

--_000_2ACBDE7E42B443DAACBCC17EE65445BChuaweicom_-- From suresh.krishnan@ericsson.com Mon Feb 4 21:31:43 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CC721F894C for ; Mon, 4 Feb 2013 21:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.79 X-Spam-Level: X-Spam-Status: No, score=-101.79 tagged_above=-999 required=5 tests=[AWL=0.809, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgT-dIicq+Fs for ; Mon, 4 Feb 2013 21:31:42 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id C560021F8938 for ; Mon, 4 Feb 2013 21:31:42 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-87-5110993e4ccb Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id AC.BC.03705.E3990115; Tue, 5 Feb 2013 06:31:42 +0100 (CET) Received: from eusaamw0707.eamcs.ericsson.se (147.117.20.32) by EUSAAHC008.ericsson.se (147.117.188.96) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 5 Feb 2013 00:31:41 -0500 Received: from [164.48.125.54] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 5 Feb 2013 00:31:40 -0500 Message-ID: <511098A3.7030406@ericsson.com> Date: Tue, 5 Feb 2013 00:29:07 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires WG X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZXLonQddupkCgQf88BYsfW5It3iydw25x eNlWJgdmjym/N7J6LFnyk8nj+Oe3zAHMUVw2Kak5mWWpRfp2CVwZX6dPZi64yFKxY9MOxgbG u8xdjBwcEgImEpOfZHcxcgKZYhIX7q1n62Lk4hASOMIocXLXFnYIZxejRPefE8wQzmZGieWN U5lBWngFtCVa5q0Hm8QioCKx/k08SJgNaOiGnZ+ZQGxRgTCJ3tfnGCHKBSVOznzCAmKLCKhK PNn5gA3EZhZwk7g5axI7iC0s4CCxb8IVNojjxCXWvOGAKNGTmHK1hRHClpfY/nYO2AVCApoS W9d8Z53AKDgLyYZZSFpmIWlZwMi8ipGjtDi1LDfdyHATIzBIj0mwOe5gXPDJ8hCjNAeLkjhv qOuFACGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MW9k4L8f//2F/UufSfI2t/2QsVtz4VSuT 1bnz+z+xhkiXjIDcpf1T5rttlrifGWc/68mkPPcErfklie6tgVVMRzLM3/1Zqrb6plpZzLY4 l79BOjLp5qtvpbEYOkgU35RoqZ7/2fAFw5MpsVtOHzY5nWyWuqijwibz7L3nkaKW02bnOT7y DV+rxFKckWioxVxUnAgAbrWO+yACAAA= Cc: Yong Cui , Ralph Droms Subject: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 05:31:43 -0000 Hi all, This draft was a result of the discussion initiated at the softwire meeting in Atlanta to attempt to come up with a unified CPE specification that can work with both MAP and lw4o6. This call is being initiated to determine whether there is WG consensus towards adoption of draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2013-02-18. Regards Suresh & Yong From fibrib@gmail.com Mon Feb 4 21:54:44 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E93C21F8972 for ; Mon, 4 Feb 2013 21:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s48KYKbJYSLe for ; Mon, 4 Feb 2013 21:54:43 -0800 (PST) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1596921F8971 for ; Mon, 4 Feb 2013 21:54:43 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id wd20so7092186obb.23 for ; Mon, 04 Feb 2013 21:54:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=n/3w8WbS6/H8IchbLXETNjr+cQKYmxOc6pRBaSeE3g4=; b=hjaBPwXjjlYEJn2ocDJ2bdXiqToLk0HbfUFumCkKBrHp9nycf6k3Hb8VuJdqRYguI4 UViiz3JSqWBk8X7cgmQWEui6aE5SWJvlVrGe5RxcnPwznFb15Ktgm1SLPCfoZZqpsTbh lQIWNCK/bMf54lIcp+nvYXJE6S3kyHkv4tMhKPfzXlEBOQulpz4HbpdR2U/2LX5Qqy4x nptR1woJFPUk21uYxMHC8gGYCA6SenMPhdENr6Mc42uDF3OrmvAa6xHDJ1aL9lfptHdh aGk0BxoqTUaL+W99RzXFDPQt9X5pbYG1m9TqV6egDR655zf0gOWDqZiGHvo1K4NK2P3S w6SA== MIME-Version: 1.0 X-Received: by 10.60.7.167 with SMTP id k7mr19151401oea.20.1360043682501; Mon, 04 Feb 2013 21:54:42 -0800 (PST) Received: by 10.76.154.8 with HTTP; Mon, 4 Feb 2013 21:54:42 -0800 (PST) In-Reply-To: <511098A3.7030406@ericsson.com> References: <511098A3.7030406@ericsson.com> Date: Tue, 5 Feb 2013 14:54:42 +0900 Message-ID: From: Maoke To: Suresh Krishnan Content-Type: multipart/alternative; boundary=e89a8ff1c6869313cb04d4f3d89f Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 05:54:44 -0000 --e89a8ff1c6869313cb04d4f3d89f Content-Type: text/plain; charset=ISO-8859-1 hi Suresh and all, personally i think this work is still premature for the WG adoption. reasons are below: 1. current draft makes a logic for the CPE to decide its mode according to what information it received from DHCP options. however, DHCP options are not the only available provision mean. what if my CPE get MAP information through DHCP, while lw4over6 information from PCP, while another MAP domain's provision through manually configuration? when such kind of basic questions not yet fully discussed, i doubt it is suitable to adopt this work at so early stage. 2. some important issues are not yet comprehensively discussed, or almost missing, in the current draft. e.g. (but not limited to), - what is the correct NAPT source port overlapping behaviour for the unified CPE? - what is the correct fragment/reassemble behaviour for the unified CPE? as currently there is no MAP members joins this draft, i am worrying that the draft has fully reflected the concern from the MAP side. thanks and regards, maoke 2013/2/5 Suresh Krishnan > Hi all, > This draft was a result of the discussion initiated at the softwire > meeting in Atlanta to attempt to come up with a unified CPE > specification that can work with both MAP and lw4o6. This call is being > initiated to determine whether there is WG consensus towards adoption of > draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state > whether or not you're in favor of the adoption by replying to this > email. If you are not in favor, please also state your objections in > your response. This adoption call will complete on 2013-02-18. > > Regards > Suresh & Yong > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --e89a8ff1c6869313cb04d4f3d89f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Suresh and all,

personally i think this work is still premat= ure for the WG adoption. reasons are below:

1. current draft makes a= logic for the CPE to decide its mode according to what information it rece= ived from DHCP options. however, DHCP options are not the only available pr= ovision mean. what if my CPE get MAP information through DHCP, while lw4ove= r6 information from PCP, while another MAP domain's provision through m= anually configuration? when such kind of basic questions not yet fully disc= ussed, i doubt it is suitable to adopt this work at so early stage.

2. some important issues are not yet comprehensively discussed, or almo= st missing, in the current draft. e.g. (but not limited to),
=A0=A0=A0 = - what is the correct NAPT source port overlapping behaviour for the unifie= d CPE?
=A0=A0=A0 - what is the correct fragment/reassemble behaviour for the unifi= ed CPE?

as currently there is no MAP members joins this draft, i am= worrying that the draft has fully reflected the concern from the MAP side.=

thanks and regards,
maoke

2013/2/5= Suresh Krishnan <suresh.krishnan@ericsson.com>
Hi all,
=A0 This draft was a result of the discussion initiated at the softwire
meeting in Atlanta to attempt to come up with a unified CPE
specification that can work with both MAP and lw4o6. This call is being
initiated to determine whether there is WG consensus towards adoption of draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state
whether or not you're in favor of the adoption by replying to this
email. If you are not in favor, please also state your objections in
your response. This adoption call will complete on 2013-02-18.

Regards
Suresh & Yong


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--e89a8ff1c6869313cb04d4f3d89f-- From Olaf.Bonness@telekom.de Tue Feb 5 00:56:10 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD6121F89CE for ; Tue, 5 Feb 2013 00:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUMf5MdisAP0 for ; Tue, 5 Feb 2013 00:56:09 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8F921F853D for ; Tue, 5 Feb 2013 00:56:08 -0800 (PST) Received: from he111528.emea1.cds.t-internal.com ([10.125.90.87]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 05 Feb 2013 09:55:44 +0100 Received: from HE113605.emea1.cds.t-internal.com ([169.254.1.119]) by HE111528.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a57::7cd:5a57]) with mapi; Tue, 5 Feb 2013 09:55:44 +0100 From: To: , Date: Tue, 5 Feb 2013 09:55:43 +0100 Thread-Topic: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 Thread-Index: Ac4DYhp7ruJH6pfuQMqlf6WRrfbQ6AAHCyXw Message-ID: References: <511098A3.7030406@ericsson.com> In-Reply-To: <511098A3.7030406@ericsson.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: cuiyong@tsinghua.edu.cn, rdroms@cisco.com Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 08:56:10 -0000 I see a useful work here that brings together the different Softwire approa= ches under a unified CPE and would that's why vote for an adoption as WG wo= rking item. Kind regards Olaf=20 -----Urspr=FCngliche Nachricht----- Von: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] Im Auft= rag von Suresh Krishnan Gesendet: Dienstag, 5. Februar 2013 06:29 An: Softwires WG Cc: Yong Cui; Ralph Droms Betreff: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-0= 2 Hi all, This draft was a result of the discussion initiated at the softwire meeti= ng in Atlanta to attempt to come up with a unified CPE specification that c= an work with both MAP and lw4o6. This call is being initiated to determine = whether there is WG consensus towards adoption of draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state whe= ther or not you're in favor of the adoption by replying to this email. If y= ou are not in favor, please also state your objections in your response. Th= is adoption call will complete on 2013-02-18. Regards Suresh & Yong _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From ian.farrer@telekom.de Tue Feb 5 00:57:22 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DE621F855F for ; Tue, 5 Feb 2013 00:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOtMEkqLIfN1 for ; Tue, 5 Feb 2013 00:57:21 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id E185E21F854B for ; Tue, 5 Feb 2013 00:57:20 -0800 (PST) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 05 Feb 2013 09:57:19 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 5 Feb 2013 09:57:18 +0100 From: To: , Date: Tue, 5 Feb 2013 09:57:38 +0100 Thread-Topic: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 Thread-Index: Ac4Dfs1+75ML6u4mSKaePuUpFSffxA== Message-ID: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CD367EF64FD2Eianfarrertelekomde_" MIME-Version: 1.0 Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, rdroms@cisco.com Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 08:57:22 -0000 --_000_CD367EF64FD2Eianfarrertelekomde_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Maoke, Thanks for your response. Comments inline. Cheers, Ian From: Maoke > Date: Tuesday, 5 February 2013 06:54 To: Suresh Krishnan > Cc: Softwires WG >, Yong Cui = >, Ralph Droms > Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-c= pe-02 hi Suresh and all, personally i think this work is still premature for the WG adoption. reason= s are below: 1. current draft makes a logic for the CPE to decide its mode according to = what information it received from DHCP options. however, DHCP options are n= ot the only available provision mean. what if my CPE get MAP information th= rough DHCP, while lw4over6 information from PCP, while another MAP domain's= provision through manually configuration? when such kind of basic question= s not yet fully discussed, i doubt it is suitable to adopt this work at so = early stage. [ian] The intention for the draft is to describe using the presence (or abs= ence) of configuration parameters so that a CPE can work out which mode to = configure. The DHCP section is there to show how this would work if you wer= e using DHCP as the config mechanism, but it doesn't 2. some important issues are not yet comprehensively discussed, or almost m= issing, in the current draft. e.g. (but not limited to), - what is the correct NAPT source port overlapping behaviour for the un= ified CPE? - what is the correct fragment/reassemble behaviour for the unified CPE= ? [ian] I agree that these are problems that need to be addressed across both= MAP and LW, but both of these problems need solutions that are aligned at = both ends of the softwire, not just the CPE. [ian] For the fragmentation question, Ole proposed this as being a suitable= task to tackle as it is common to all solutions. I would propose that this= is how it is tackled, and then any affected drafts are updated based on th= e outcome. as currently there is no MAP members joins this draft, i am worrying that t= he draft has fully reflected the concern from the MAP side. [ian] As there haven't been any comments on the draft for some time from an= yone involved in the WG, I'm hoping that this means that everyone is happy = with the content! thanks and regards, maoke 2013/2/5 Suresh Krishnan > Hi all, This draft was a result of the discussion initiated at the softwire meeting in Atlanta to attempt to come up with a unified CPE specification that can work with both MAP and lw4o6. This call is being initiated to determine whether there is WG consensus towards adoption of draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2013-02-18. Regards Suresh & Yong _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_CD367EF64FD2Eianfarrertelekomde_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Maoke,

Thanks for your response. Comments inline.

Cheers,
Ian

From: Maoke <fibrib@gmail.com>
Date: <= /span> Tuesday, 5 February 2013 06:54
T= o: Suresh Krishnan <suresh.krishnan@ericsson.com>
Cc: Softwires WG <softwi= res@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>, Ralph Droms <rdroms@cisco.com>
S= ubject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-un= ified-cpe-02


hi Suresh and all,

personally i think this work is still premature for the WG adoption. reason= s are below:

1. current draft makes a logic for the CPE to decide its mode according to = what information it received from DHCP options. however, DHCP options are n= ot the only available provision mean. what if my CPE get MAP information th= rough DHCP, while lw4over6 information from PCP, while another MAP domain's provision through manually configurat= ion? when such kind of basic questions not yet fully discussed, i doubt it = is suitable to adopt this work at so early stage.

[ian] The intention for the draft is= to describe using the presence (or absence) of configuration parameters so= that a CPE can work out which mode to configure. The DHCP section is there= to show how this would work if you were using DHCP as the config mechanism= , but it doesn't

2. some important issues are not yet comprehensively discussed, or al= most missing, in the current draft. e.g. (but not limited to),
    - what is the correct NAPT source port overlapping behav= iour for the unified CPE?
    - what is the correct fragment/reassemble behaviour for = the unified CPE?

[ian] I agree t= hat these are problems that need to be addressed across both MAP and LW, bu= t both of these problems need solutions that are aligned at both ends of th= e softwire, not just the CPE.

[ian] For the fragme= ntation question, Ole proposed this as being a suitable task to tackle as i= t is common to all solutions. I would propose that this is how it is tackle= d, and then any affected drafts are updated based on the outcome.

as currently there is no MAP members joins this draft, i am worrying that t= he draft has fully reflected the concern from the MAP side.

[ian] As there haven't been any = comments on the draft for some time from anyone involved in the WG, I'm hop= ing that this means that everyone is happy with the content!

thanks and regards,
maoke

2013/2/5 Suresh Krishnan <suresh.krishnan@ericsson.com>
Hi all,
  This draft was a result of the discussion initiated at the softwire<= br> meeting in Atlanta to attempt to come up with a unified CPE
specification that can work with both MAP and lw4o6. This call is being
initiated to determine whether there is WG consensus towards adoption of draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state
whether or not you're in favor of the adoption by replying to this
email. If you are not in favor, please also state your objections in
your response. This adoption call will complete on 2013-02-18.

Regards
Suresh & Yong


_______________________________________________
Softwires mailing list
Softwires@i= etf.org
https://www.ietf.org/mailman/listinfo/softwires

 --_000_CD367EF64FD2Eianfarrertelekomde_-- From simon.perreault@viagenie.ca Tue Feb 5 01:44:11 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC17E21F8753 for ; Tue, 5 Feb 2013 01:44:11 -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.038, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUefdzq69jhm for ; Tue, 5 Feb 2013 01:44:11 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 53E4F21F873D for ; Tue, 5 Feb 2013 01:44:11 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:245a:a34b:600:fe8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AFC784040E for ; Tue, 5 Feb 2013 04:44:10 -0500 (EST) Message-ID: <5110D49D.8010103@viagenie.ca> Date: Tue, 05 Feb 2013 10:45:01 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <511098A3.7030406@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 09:44:11 -0000 Le 2013-02-05 09:55, Olaf.Bonness@telekom.de a écrit : > I see a useful work here that brings together the different Softwire > approaches under a unified CPE and would that's why vote for an > adoption as WG working item. +1 Simon From ot@cisco.com Tue Feb 5 01:50:04 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C210C21F880B for ; Tue, 5 Feb 2013 01:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKxdHpiWm4lp for ; Tue, 5 Feb 2013 01:50:03 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB4721F879D for ; Tue, 5 Feb 2013 01:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1573; q=dns/txt; s=iport; t=1360057803; x=1361267403; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=26VP8BOSQ5ZLxtsTyA9OwFN4ZY5Uxt1hgbArQxALWh0=; b=Kw43LCJid4hHVrByNZqQN/toTuRsYZ70qdPQhHsqBFXbKUtvUfnFFUCe YkslpRmDjCR79TMI4HWJoA4DOjzq61Xjm7Zydy/aZ1YVUlg04Y+3VByxo Uk4sQ3wy7c1RYffsUmJOp78E0yfEKNhPJjKzEYBiJmEeFMOvwkZ6YSYN8 Q=; X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; d="scan'208";a="80256902" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 05 Feb 2013 09:50:01 +0000 Received: from dhcp-10-61-108-114.cisco.com (dhcp-10-61-108-114.cisco.com [10.61.108.114]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r159nwG0005745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Feb 2013 09:49:59 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: Date: Tue, 5 Feb 2013 10:49:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <511098A3.7030406@ericsson.com> To: Olaf.Bonness@telekom.de X-Mailer: Apple Mail (2.1499) Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, rdroms@cisco.com Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 09:50:04 -0000 > I see a useful work here that brings together the different Softwire = approaches under a unified CPE and would that's why vote for an adoption = as WG working item. yes, I agree with that. while I think the document needs some more = polishing, I do think it is something we should work on. cheers, Ole > -----Urspr=FCngliche Nachricht----- > Von: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] Im = Auftrag von Suresh Krishnan > Gesendet: Dienstag, 5. Februar 2013 06:29 > An: Softwires WG > Cc: Yong Cui; Ralph Droms > Betreff: [Softwires] Call for adoption of = draft-bfmk-softwire-unified-cpe-02 >=20 > Hi all, > This draft was a result of the discussion initiated at the softwire = meeting in Atlanta to attempt to come up with a unified CPE = specification that can work with both MAP and lw4o6. This call is being = initiated to determine whether there is WG consensus towards adoption of > draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please = state whether or not you're in favor of the adoption by replying to this = email. If you are not in favor, please also state your objections in = your response. This adoption call will complete on 2013-02-18. >=20 > Regards > Suresh & Yong >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ales.vizdal@t-mobile.cz Tue Feb 5 04:08:47 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A0A21F87CC for ; Tue, 5 Feb 2013 04:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qu+AiTKTyIjO for ; Tue, 5 Feb 2013 04:08:46 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5898221F8778 for ; Tue, 5 Feb 2013 04:08:46 -0800 (PST) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 2E24A285828 for ; Tue, 5 Feb 2013 13:08:45 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Tue, 5 Feb 2013 13:08:44 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "softwires@ietf.org" Date: Tue, 5 Feb 2013 13:09:52 +0100 Thread-Topic: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 Thread-Index: Ac4DhV1vjidt58cXT4yijT+7COYjYAAFE9sA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFA8735E@SRVHKE02.rdm.cz> References: <511098A3.7030406@ericsson.com> <5110D49D.8010103@viagenie.ca> In-Reply-To: <5110D49D.8010103@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 12:08:47 -0000 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of > Simon Perreault > Sent: Tuesday, February 05, 2013 10:45 AM > To: softwires@ietf.org > Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified= -cpe-02 >=20 > Le 2013-02-05 09:55, Olaf.Bonness@telekom.de a =E9crit : > > I see a useful work here that brings together the different Softwire > > approaches under a unified CPE and would that's why vote for an > > adoption as WG working item. >=20 > +1 >=20 > Simon +1 Ales From tjc@ecs.soton.ac.uk Tue Feb 5 04:46:03 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718A121F87C4 for ; Tue, 5 Feb 2013 04:46:03 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YC59iAFraQXg for ; Tue, 5 Feb 2013 04:46:02 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id C091721F87B3 for ; Tue, 5 Feb 2013 04:46:00 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r15Cjs52013205 for ; Tue, 5 Feb 2013 12:45:54 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r15Cjs52013205 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1360068354; bh=DfXwTSHu2gqLBHk0rgWTASDj7Jw=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=VvKbYTb2A6YaZK5jNkJM9VPSsd7dC0BS6rPUJ7kAuDOnJ7zhAI0wcaEOFUC4DItBI TZ3eXrVoMk6DBDWZSUNqVMhhO0qWc8OFTQjM9h8mNnpCK34xebiMQ7v62RqG//K+LB Wq+f18Vm9T+P1OaR2cps5aSewg2Q2cfnTHnyuVFs= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p14Cjs0430651685gQ ret-id none; Tue, 05 Feb 2013 12:45:54 +0000 Received: from ip-161-090.eduroam.soton.ac.uk (ip-161-090.eduroam.soton.ac.uk [152.78.161.90]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r15CjnUV003180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 5 Feb 2013 12:45:49 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <5110D49D.8010103@viagenie.ca> Date: Tue, 5 Feb 2013 12:45:48 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <511098A3.7030406@ericsson.com> <5110D49D.8010103@viagenie.ca> <54745BCD-4380-44C5-B1BF-44EE65990155@ecs.soton.ac.uk> To: softwires@ietf.org X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p14Cjs043065168500; tid=p14Cjs0430651685gQ; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r15Cjs52013205 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 12:46:03 -0000 On 5 Feb 2013, at 09:45, Simon Perreault = wrote: > Le 2013-02-05 09:55, Olaf.Bonness@telekom.de a =E9crit : >> I see a useful work here that brings together the different Softwire >> approaches under a unified CPE and would that's why vote for an >> adoption as WG working item. >=20 > +1 Agree to adoption.= From ot@cisco.com Tue Feb 5 05:38:29 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDEF21F8862 for ; Tue, 5 Feb 2013 05:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMkluxrF+yxV for ; Tue, 5 Feb 2013 05:38:29 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E0BAF21F881D for ; Tue, 5 Feb 2013 05:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=781; q=dns/txt; s=iport; t=1360071509; x=1361281109; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=obKm+25nlaHQlkU+mFoNF0rp84oH/mfDF50tfI4bDyU=; b=anh8IQ5hrfKRGmhnZOL42D9Z6cTrOp9Tv7A7ujytv7tyI3o6hh/k1mt+ CUaRx7YUXlm/Kl6pixx0Zqcg9kFPfFZHO5ZuxX+53WiIv9DcOLS8BbZuI XSaxNbmYZZsnHVwUtZBOfJZ6DTF2dBN/1es741szMgGzYQmDxxPpCEjjq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4KAGEKEVGQ/khR/2dsb2JhbABFvVx5BASBARZzgh8BAQEDAXkFCwtGVwaIHgaqFJAqkHphA5YhkFKCfw X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; d="scan'208";a="150158683" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 05 Feb 2013 13:38:27 +0000 Received: from dhcp-10-61-106-228.cisco.com (dhcp-10-61-106-228.cisco.com [10.61.106.228]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r15DcQOk009010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Feb 2013 13:38:27 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <87FB8635-1894-4689-BADE-40EAEEAF0CB3@laposte.net> Date: Tue, 5 Feb 2013 14:38:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <05E6DBF1-1908-45E7-A0B9-0877DACA3ABA@cisco.com> References: <5106AE69.80705@gmail.com> <51086E17.10603@gmail.com> <510914DC.3090507@gmail.com> <2BE59159-2F6D-4D6A-98F9-F0E7775322E9@cisco.com> <510941A5.7090108@gmail.com> <87FB8635-1894-4689-BADE-40EAEEAF0CB3@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1499) Cc: Softwires WG Subject: Re: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 13:38:29 -0000 > But there has been a firm requirement in the WG that, even for shared = addresses, one of the CE could have the well-known ports.=20 > The WKPs-authorized option has been added to 4rd to satisfy this = requirement.=20 > I don't think this requirement has disappeared. does anyone in the working group have an opinion on the well-known ports = and shared IPv4 addresses? the options we have are: a) if well-known ports are required then a full IPv4 address must be = assigned b) allow that one user gets the well-known addresses, but then the port block must at least be > 1024 ports. do we know that end users only need ports 0-1023 or 0-4095? or are the ports the require to be opened inbound across the range? I'm leaning towards a. cheers, Ole= From tom.taylor.stds@gmail.com Tue Feb 5 05:48:09 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4FE21F85FD for ; Tue, 5 Feb 2013 05:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.285 X-Spam-Level: X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7N890Ca40WB for ; Tue, 5 Feb 2013 05:48:08 -0800 (PST) Received: from mail-ia0-x22e.google.com (ia-in-x022e.1e100.net [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF3621F85EE for ; Tue, 5 Feb 2013 05:48:08 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id o25so160801iad.5 for ; Tue, 05 Feb 2013 05:48:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=kkS29M2lNwgBGAUMPIqDxfekCRJ1nTmvh7A5j9BoSh8=; b=Uf60PmI9sCZ5/KB1mp6KSHjP+5AWxIG8Q2Jc0TwkQ/7CG/jKjGyxDPgSsjTQAZvgjd NpiMoiWGkQkg1UWKQiV5B4SVS4guIGvFYOptocXNIMYq97N7tGm+/xzdLyI1UFNKkxcG tiYp2/wOeIacXGFphLXybk/IsBQ5pBOs7Sf2RwX/Qb2ukMuME8yr+3KuamlByWstbZ+K ZtzASEGbbOuHLbcTAPpgtghx7+xWjWoi8ZU84O7b8kNX3OuTCxQakMLa4f7Y0OBLXYFv BLkdlxT9gmZTOZ0MjkvFn7a9GerPsZAohY2Iv1hXuiNeB/m/bNx/qWkXpCH7gxGe4kW9 HhhA== X-Received: by 10.42.75.6 with SMTP id y6mr22073683icj.30.1360072086625; Tue, 05 Feb 2013 05:48:06 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id j11sm22645777igc.5.2013.02.05.05.48.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Feb 2013 05:48:06 -0800 (PST) Message-ID: <51110D94.6010309@gmail.com> Date: Tue, 05 Feb 2013 08:48:04 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan References: <5106AE69.80705@gmail.com> <51086E17.10603@gmail.com> <510914DC.3090507@gmail.com> <2BE59159-2F6D-4D6A-98F9-F0E7775322E9@cisco.com> <510941A5.7090108@gmail.com> <87FB8635-1894-4689-BADE-40EAEEAF0CB3@laposte.net> <05E6DBF1-1908-45E7-A0B9-0877DACA3ABA@cisco.com> In-Reply-To: <05E6DBF1-1908-45E7-A0B9-0877DACA3ABA@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130205-0, 05/02/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires WG Subject: Re: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 13:48:09 -0000 I support (a). On 05/02/2013 8:38 AM, Ole Troan wrote: >> But there has been a firm requirement in the WG that, even for shared addresses, one of the CE could have the well-known ports. >> The WKPs-authorized option has been added to 4rd to satisfy this requirement. >> I don't think this requirement has disappeared. > > does anyone in the working group have an opinion on the well-known ports and shared IPv4 addresses? > the options we have are: > > a) if well-known ports are required then a full IPv4 address must be assigned > b) allow that one user gets the well-known addresses, > but then the port block must at least be > 1024 ports. > > do we know that end users only need ports 0-1023 or 0-4095? > or are the ports the require to be opened inbound across the range? > > I'm leaning towards a. > > cheers, > Ole > From ot@cisco.com Tue Feb 5 05:49:18 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAFD21F8778 for ; Tue, 5 Feb 2013 05:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hZzQVVhqL5X for ; Tue, 5 Feb 2013 05:49:18 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id A930721F8625 for ; Tue, 5 Feb 2013 05:49:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3772; q=dns/txt; s=iport; t=1360072157; x=1361281757; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=bzHUgGb4gDonH9wVv9xTrkysa85ujXC48jGjMCtf93A=; b=miDApqMIN+QcGduFxBKZ8E9e32L7Kx8nwCKP3I/9qy6fqDGLXCbqbi2l xNHLW0FLd91q2BXLb9VgoA0pMaQXyGLFA9XO4gYUA/ROam3TPMYikEjnS OoiEB7e/yF12o3dLDG1QGXa8IMhpDHUVAy+IuDxuvnl12fQvmMjntWY4s k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD8MEVGQ/khL/2dsb2JhbAA7Cr9fFnOCHwEBAQMBAQEBNzQLBQsLEjQhBiIOBhOHfwMJBgyqDIZIDYlSBIwWgQODYWEDlEmBWIs/hROCfw X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; d="scan'208";a="11599098" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 05 Feb 2013 13:49:16 +0000 Received: from dhcp-10-61-106-228.cisco.com (dhcp-10-61-106-228.cisco.com [10.61.106.228]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r15DnFZD031530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Feb 2013 13:49:15 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <51048FE0.8070507@gmail.com> Date: Tue, 5 Feb 2013 14:49:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <53D408F8-C336-4651-B343-89A86D992F7B@cisco.com> References: <51048FE0.8070507@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] Suggested modifications to Section 4 of draft-ietf-softwire-map-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 13:49:18 -0000 Tom, thanks, apologies for the delay, I've incorporated your suggested = changes. Best, Ole On Jan 27, 2013, at 3:24 , Tom Taylor wrote: > Here is my suggested change. Most of the text is the same as now, just = rearranged. >=20 > 4. Architecture >=20 > In accordance with the requirements stated above, the MAP mechanism = can operate with shared IPv4 addresses, but also with full IPv4 = addresses and IPv4 prefixes. Operation with shared IPv4 addresses is = described now, and the differences for full IPv4 addresses and prefixes = are described below. >=20 > The MAP mechanism uses existing standard building blocks. The > existing NAPT on the CE is used with additional support for > restricting transport protocol ports, ICMP identifiers and fragment > identifiers to the configured port set. For packets outbound from = the private IPv4 network, the CE NAPT MUST > translate transport identifiers (e.g. TCP and UDP port numbers) so > that they fall within the CE's assigned port-range. >=20 > The NAPT MUST in turn be connected > to a MAP aware forwarding function, that does encapsulation/ > decapsulation of IPv4 packets in IPv6. MAP supports the > encapsulation mode specified in [RFC2473]. In addition MAP = specifies > an algorithm to do "address resolution" from an IPv4 address and = port > to an IPv6 address. This algorithmic mapping is specified in = Section > 5. >=20 > The MAP architecture described here, restricts the use of the shared > IPv4 address to only be used as the global address (outside) of the > NAPT [RFC2663] running on the CE. A shared IPv4 address MUST NOT be = used to identify an interface. While it > is theoretically possible to make host stacks and applications port- > aware, that is considered too drastic a change to the IP model > [RFC6250]. >=20 > For full IPv4 addresses and IPv4 prefixes, the architecture just = described applies with two differences. First, a full IPv4 address or = IPv4 prefix can be used as it is today, e.g., for > identifying an interface or as a DHCP pool, respectively. Secondly, = the NAPT is not required to restrict the ports used on outgoing packets. >=20 > This architecture is illustrated in Figure 1. >=20 >=20 > User N > Private IPv4 > | Network > | > O--+---------------O > | | MAP CE | > | +-----+--------+ | > | NAPT44| MAP | | > | +-----+ | |\ ,-------. .------. > | +--------+ | \ ,-' `-. ,-' `-. > O------------------O / \ O---------O / Public \ > / IPv6 only \ | MAP | / IPv4 = \ > ( Network --+ Border +- Network = ) > \ (MAP Domain) / | Relay | \ = / > O------------------O \ / O---------O \ = / > | MAP CE | /". ,-' `-. ,-' > | +-----+--------+ | / `----+--' ------' > | NAPT44| MAP | |/ > | +-----+ | | > | | +--------+ | > O---.--------------O > | > User M > Private IPv4 > Network >=20 >=20 > Figure 1: Network Topology >=20 >=20 >=20 > Just to complete the description of Figure 1: the MAP BR is = responsible for connecting external IPv4 networks to > the IPv4 nodes in one or more MAP domains. >=20 > Tom Taylor > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From satoru.matsushima@gmail.com Tue Feb 5 06:23:35 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0EC21F863C for ; Tue, 5 Feb 2013 06:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RT6RefaO5Tlo for ; Tue, 5 Feb 2013 06:23:35 -0800 (PST) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id 54DF321F85BC for ; Tue, 5 Feb 2013 06:23:35 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id kl14so167206pab.32 for ; Tue, 05 Feb 2013 06:23:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=juRmGn1Ehp78YcuouqMh36VPyhfvA9jkNYLJsHfZbw8=; b=U8dAfOsIViQ98osCB2Ex/1yGs4NY8JIDT8kuTb/n6FJX8Ut+PrAL96h/+5xbC9dZZM cwa42S8Rbe10uov98arn11ZwlwJmeCOqL2JGB+ZYc2lTDx3DjwwuAAzg8UMCkxkg0+Uy XT4JDoiWWMlw0irZERpdYdPvqMPQWmKO8gbU/Ky8lR7YRWKlXlXPx1RI24XPF99ZeBV/ 4m5UJ00dLqsOKLMQwAoKsWDBlv80NccZqazmGlawUZu+T9rHLRq8KAhvH2eqEdoTVfPg ZA1TGsxb236TOBpc9VfPY9D4AlpqBwUZYxxg81IbJqjk6bzjd/m4n3+mF1fuaxJO+EH2 OOEw== X-Received: by 10.66.83.232 with SMTP id t8mr64434985pay.73.1360074214638; Tue, 05 Feb 2013 06:23:34 -0800 (PST) Received: from [192.168.3.3] (softbank126044192158.bbtec.net. [126.44.192.158]) by mx.google.com with ESMTPS id f9sm29796839paz.12.2013.02.05.06.23.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Feb 2013 06:23:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Satoru Matsushima In-Reply-To: <05E6DBF1-1908-45E7-A0B9-0877DACA3ABA@cisco.com> Date: Tue, 5 Feb 2013 23:23:29 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <70F997D8-7466-4DD1-954D-FB6320CBF31E@gmail.com> References: <5106AE69.80705@gmail.com> <51086E17.10603@gmail.com> <510914DC.3090507@gmail.com> <2BE59159-2F6D-4D6A-98F9-F0E7775322E9@cisco.com> <510941A5.7090108@gmail.com> <87FB8635-1894-4689-BADE-40EAEEAF0CB3@laposte.net> <05E6DBF1-1908-45E7-A0B9-0877DACA3ABA@cisco.com> To: Ole Troan X-Mailer: Apple Mail (2.1499) Cc: Softwires WG Subject: Re: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 14:23:35 -0000 On 2013/02/05, at 22:38, Ole Troan wrote: >> But there has been a firm requirement in the WG that, even for shared = addresses, one of the CE could have the well-known ports.=20 >> The WKPs-authorized option has been added to 4rd to satisfy this = requirement.=20 >> I don't think this requirement has disappeared. >=20 > does anyone in the working group have an opinion on the well-known = ports and shared IPv4 addresses? > the options we have are: >=20 > a) if well-known ports are required then a full IPv4 address must be = assigned > b) allow that one user gets the well-known addresses, > but then the port block must at least be > 1024 ports. >=20 It is not clear to me is that whether a full IPv4 address is required or = not even when a user just want a well-known port. > do we know that end users only need ports 0-1023 or 0-4095? need 22, but don't need 25, but need 53 and also need 80, etc., etc., of = course it is not MAP use case at all. > or are the ports the require to be opened inbound across the range? >=20 As far as I know, that kind of port is used to open inbound session. > I'm leaning towards a. >=20 Is this as an item of out of scope of MAP? cheers, --satoru= From rajiva@cisco.com Tue Feb 5 07:16:22 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E6E21F8911 for ; Tue, 5 Feb 2013 07:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCaM9syZgD7t for ; Tue, 5 Feb 2013 07:16:22 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6578D21F853E for ; Tue, 5 Feb 2013 07:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1398; q=dns/txt; s=iport; t=1360077379; x=1361286979; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CAtJ6GUGiVN76QDarGerIdO1VyYQehOJ79JeDWAqR2U=; b=ICJBlGsjCWCiUmiDm5SRbi/S5hbhP9ZxGtcLRJlhLi4lrzcUiL8CXWwv 8j8eab6GId9PPWes0LyZP1KwYnKY47p6hZFY2wiHNZRk1oD2p6IjO6cno zjd3DmO8xSNwiTx+wdy35xhPGbJ1gHjzZLPFZfZMbMaK9wx5FhMM59J10 8=; X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; d="scan'208";a="173338150" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 05 Feb 2013 15:16:19 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r15FGJY5017680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 15:16:19 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 09:16:18 -0600 From: "Rajiv Asati (rajiva)" To: Ole Troan , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [Softwires] Section 5.1 of the MAP draft Thread-Index: AQHN/XjYv9wq2cejVkW+XX9bA5tmxJhgM9WAgAE9HYCAAKVSgIAAIXwAgAABxoCAACQdAIAAD4GAgAAPZgCACTk/AP//x38A Date: Tue, 5 Feb 2013 15:16:17 +0000 Message-ID: In-Reply-To: <05E6DBF1-1908-45E7-A0B9-0877DACA3ABA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.150.42.52] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG Subject: Re: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 15:16:22 -0000 I support (a).=20 Not allowing the usage of the reserved port range 0-1023 is one less thing for an operator to worry about. 0-1023 range is good enough to be blocked. Cheers, Rajiv -----Original Message----- From: Ole Troan Date: Tuesday, February 5, 2013 8:38 AM To: "despres.remi@laposte.net" Cc: Softwires-wg list Subject: Re: [Softwires] Section 5.1 of the MAP draft >> But there has been a firm requirement in the WG that, even for shared >>addresses, one of the CE could have the well-known ports. >> The WKPs-authorized option has been added to 4rd to satisfy this >>requirement.=20 >> I don't think this requirement has disappeared. > >does anyone in the working group have an opinion on the well-known ports >and shared IPv4 addresses? >the options we have are: > >a) if well-known ports are required then a full IPv4 address must be >assigned >b) allow that one user gets the well-known addresses, > but then the port block must at least be > 1024 ports. > >do we know that end users only need ports 0-1023 or 0-4095? >or are the ports the require to be opened inbound across the range? > >I'm leaning towards a. > >cheers, >Ole >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From tom.taylor.stds@gmail.com Tue Feb 5 07:50:21 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AF821F8881 for ; Tue, 5 Feb 2013 07:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.27 X-Spam-Level: X-Spam-Status: No, score=-0.27 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXtt+E7Me774 for ; Tue, 5 Feb 2013 07:50:21 -0800 (PST) Received: from mail-ie0-x22e.google.com (ie-in-x022e.1e100.net [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 31E7721F853A for ; Tue, 5 Feb 2013 07:50:21 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id k10so381706iea.19 for ; Tue, 05 Feb 2013 07:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=UphXr2GnlBcHUWp0YDMqUSgdOWrvaR8/OUr0Lw2QigM=; b=G2n1GsIjOqWCeaQ7v7RmlZMJFs+nfbnwD+j9T6iGchru20QAwtRKPveggF2UtpbJjD 1BLPEYcOWQ1zn8Gzqq0fcKvr0a1D6y1J3shPtLfJ84pWIFmYknLajY4AVkQJ43AQh9Kx PsiX38Gdd8zUKjt4Sy28RVx1NJrTIqBKrB6Uh7VaofQqa//SrfFRavpKwv5aXZASfuXD ef32zIDVn7cB7HWQ65mgDufH5C1gVeEVzjC2wJB7VQ+yDAmFXcjr/08pA11sdQuz6VP/ LjuvQ2Vtbv+aXG4SHCNPIwOS8jPzkpoiuI13nb6EqrOvMcUKmTU/GJ43w6VXdkW52DY/ lGjg== X-Received: by 10.50.5.239 with SMTP id v15mr13923193igv.41.1360079420655; Tue, 05 Feb 2013 07:50:20 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id ig8sm23136026igc.10.2013.02.05.07.50.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Feb 2013 07:50:19 -0800 (PST) Message-ID: <51112A3A.80400@gmail.com> Date: Tue, 05 Feb 2013 10:50:18 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Suresh Krishnan References: <511098A3.7030406@ericsson.com> In-Reply-To: <511098A3.7030406@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130205-0, 05/02/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 15:50:21 -0000 Support. On 05/02/2013 12:29 AM, Suresh Krishnan wrote: > Hi all, > This draft was a result of the discussion initiated at the softwire > meeting in Atlanta to attempt to come up with a unified CPE > specification that can work with both MAP and lw4o6. This call is being > initiated to determine whether there is WG consensus towards adoption of > draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state > whether or not you're in favor of the adoption by replying to this > email. If you are not in favor, please also state your objections in > your response. This adoption call will complete on 2013-02-18. > > Regards > Suresh & Yong > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From ssenthil@cisco.com Tue Feb 5 09:45:00 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5445F21F8688 for ; Tue, 5 Feb 2013 09:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnLKYmbyTCLT for ; Tue, 5 Feb 2013 09:44:59 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9F48E21F8684 for ; Tue, 5 Feb 2013 09:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=844; q=dns/txt; s=iport; t=1360086299; x=1361295899; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=KcVUQawPfSJWjIlt+GZ4cgKaM1PByf5G2LEUWIrmuXY=; b=V1Jgd98hPkb7Ci6e3Fy6Jap70jT2p0os6p/ku2JtlpMfecfWB2+hYl+M +EuIuUwJLg5XCQVmErrZUGLlCcdbKIQhIg5zsP83ohmEHVuORm/oRVgWp fipW0llYYQTC5neWqGuKkPC8NoH0lI1mA8AmPa8ojDDaii5x++LoPJOfH A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAAtEEVGtJXHA/2dsb2JhbABFhgG5YBZzgiEBBAEBARodNAsSAQgiFDcLJQIEAQ0FCIgJDKo5kCcEjRODZ2EDpnOCfoFvNQ X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; d="scan'208";a="173629802" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 05 Feb 2013 17:44:59 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r15Hix6q009170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 17:44:59 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.248]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 11:44:58 -0600 From: "Senthil Sivakumar (ssenthil)" To: Suresh Krishnan , Softwires WG Thread-Topic: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 Thread-Index: AQHOA2IYgT0m/Eicc0WUqaY0/j1M+ZhrmwQA Date: Tue, 5 Feb 2013 17:44:58 +0000 Message-ID: In-Reply-To: <511098A3.7030406@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [64.102.83.131] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Yong Cui , "Ralph Droms \(rdroms\)" Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 17:45:00 -0000 Support. On 2/5/13 12:29 AM, "Suresh Krishnan" wrote: >Hi all, > This draft was a result of the discussion initiated at the softwire >meeting in Atlanta to attempt to come up with a unified CPE >specification that can work with both MAP and lw4o6. This call is being >initiated to determine whether there is WG consensus towards adoption of >draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state >whether or not you're in favor of the adoption by replying to this >email. If you are not in favor, please also state your objections in >your response. This adoption call will complete on 2013-02-18. > >Regards >Suresh & Yong > > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From Tina.Tsou.Zouting@huawei.com Tue Feb 5 11:43:25 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0449F21F8802 for ; Tue, 5 Feb 2013 11:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[AWL=-2.136, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10cOcnEU7nOD for ; Tue, 5 Feb 2013 11:43:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BCBC221F87E0 for ; Tue, 5 Feb 2013 11:43:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOE68435; Tue, 05 Feb 2013 19:43:22 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 5 Feb 2013 19:42:29 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 6 Feb 2013 03:43:21 +0800 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.165]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.007; Tue, 5 Feb 2013 11:43:18 -0800 From: Tina TSOU To: "Senthil Sivakumar (ssenthil)" , Suresh Krishnan , Softwires WG Thread-Topic: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 Thread-Index: AQHOA2IcRojuj5ZQvUiz/MFp7v/LGphsEF8A//+azAA= Date: Tue, 5 Feb 2013 19:43:18 +0000 Message-ID: References: <511098A3.7030406@ericsson.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.91] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Yong Cui , "Ralph Droms \(rdroms\)" Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 19:43:25 -0000 RGVhciBhbGwsDQpJJ20gaW4gZmF2b3Igb2YgdGhlIGFkb3B0aW9uLg0KDQpUaGFuayB5b3UsDQpU aW5hDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzb2Z0d2lyZXMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnXSBPbg0K PiBCZWhhbGYgT2YgU2VudGhpbCBTaXZha3VtYXIgKHNzZW50aGlsKQ0KPiBTZW50OiAyMDEzxOoy 1MI1yNUgOTo0NQ0KPiBUbzogU3VyZXNoIEtyaXNobmFuOyBTb2Z0d2lyZXMgV0cNCj4gQ2M6IFlv bmcgQ3VpOyBSYWxwaCBEcm9tcyAocmRyb21zKQ0KPiBTdWJqZWN0OiBSZTogW1NvZnR3aXJlc10g Q2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtYmZtay1zb2Z0d2lyZS11bmlmaWVkLQ0KPiBjcGUt MDINCj4gDQo+IFN1cHBvcnQuDQo+IA0KPiBPbiAyLzUvMTMgMTI6MjkgQU0sICJTdXJlc2ggS3Jp c2huYW4iIDxzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+ID5IaSBh bGwsDQo+ID4gIFRoaXMgZHJhZnQgd2FzIGEgcmVzdWx0IG9mIHRoZSBkaXNjdXNzaW9uIGluaXRp YXRlZCBhdCB0aGUgc29mdHdpcmUNCj4gPm1lZXRpbmcgaW4gQXRsYW50YSB0byBhdHRlbXB0IHRv IGNvbWUgdXAgd2l0aCBhIHVuaWZpZWQgQ1BFDQo+ID5zcGVjaWZpY2F0aW9uIHRoYXQgY2FuIHdv cmsgd2l0aCBib3RoIE1BUCBhbmQgbHc0bzYuIFRoaXMgY2FsbCBpcyBiZWluZw0KPiA+aW5pdGlh dGVkIHRvIGRldGVybWluZSB3aGV0aGVyIHRoZXJlIGlzIFdHIGNvbnNlbnN1cyB0b3dhcmRzIGFk b3B0aW9uDQo+ID5vZg0KPiA+ZHJhZnQtYmZtay1zb2Z0d2lyZS11bmlmaWVkLWNwZS0wMiBhcyBh IHNvZnR3aXJlIFdHIGRyYWZ0LiBQbGVhc2Ugc3RhdGUNCj4gPndoZXRoZXIgb3Igbm90IHlvdSdy ZSBpbiBmYXZvciBvZiB0aGUgYWRvcHRpb24gYnkgcmVwbHlpbmcgdG8gdGhpcw0KPiA+ZW1haWwu IElmIHlvdSBhcmUgbm90IGluIGZhdm9yLCBwbGVhc2UgYWxzbyBzdGF0ZSB5b3VyIG9iamVjdGlv bnMgaW4NCj4gPnlvdXIgcmVzcG9uc2UuIFRoaXMgYWRvcHRpb24gY2FsbCB3aWxsIGNvbXBsZXRl IG9uIDIwMTMtMDItMTguDQo+ID4NCj4gPlJlZ2FyZHMNCj4gPlN1cmVzaCAmIFlvbmcNCj4gPg0K PiA+DQo+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+U29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPiA+U29mdHdpcmVzQGlldGYub3JnDQo+ID5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU29mdHdpcmVzIG1h aWxpbmcgbGlzdA0KPiBTb2Z0d2lyZXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCg== From fibrib@gmail.com Tue Feb 5 17:59:00 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7591D21F899F for ; Tue, 5 Feb 2013 17:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.836 X-Spam-Level: X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EV43diQ+EbCg for ; Tue, 5 Feb 2013 17:58:59 -0800 (PST) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by ietfa.amsl.com (Postfix) with ESMTP id 2A94421F8996 for ; Tue, 5 Feb 2013 17:58:59 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id ef5so908709obb.25 for ; Tue, 05 Feb 2013 17:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cNg/z0PwlVwBz/ohYLjuOnAFZcCzjfvxBvmrHfQOGDA=; b=QOvS0hSRV7f0FOAXb8XgQrgPOuBKfEFj4o+cQdAre3YW7g7ogoDfk5KRa9TtPVdKHo k9eEkDI0KpljDJSKh67Kt6bmv5udG0TxfTzJTY9mgTTSG09aVUFHxI39NkzVV2wT14lt s3SYr4RZuu/8j5TFxCpSjYH3hIeGlzouEBO3igpP9rcQoF8MPYTGG4pdgPrZa6XpcMaS jQps06suG+wIyTwgmF9TWMkFqhjpB+NG8DSN9BjYGLqTq1kDfSF3d/j5eB+ti4Q3kFAH yelCz434uW5m8yM/1F3LV4l/E++nbtA+YCrof2T114NyI2N0Hr3ID8SJyxiCD7BcpfHt FcMA== MIME-Version: 1.0 X-Received: by 10.182.54.46 with SMTP id g14mr19094682obp.55.1360115938585; Tue, 05 Feb 2013 17:58:58 -0800 (PST) Received: by 10.76.154.8 with HTTP; Tue, 5 Feb 2013 17:58:58 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Feb 2013 10:58:58 +0900 Message-ID: From: Maoke To: ian.farrer@telekom.de Content-Type: multipart/alternative; boundary=14dae93b57be5f6b4604d504ab87 Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, rdroms@cisco.com Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 01:59:00 -0000 --14dae93b57be5f6b4604d504ab87 Content-Type: text/plain; charset=ISO-8859-1 2013/2/5 > Hi Maoke, > > Thanks for your response. Comments inline. > > Cheers, > Ian > > From: Maoke > Date: Tuesday, 5 February 2013 06:54 > To: Suresh Krishnan > Cc: Softwires WG , Yong Cui , > Ralph Droms > Subject: Re: [Softwires] Call for adoption of > draft-bfmk-softwire-unified-cpe-02 > > > hi Suresh and all, > > personally i think this work is still premature for the WG adoption. > reasons are below: > > 1. current draft makes a logic for the CPE to decide its mode according to > what information it received from DHCP options. however, DHCP options are > not the only available provision mean. what if my CPE get MAP information > through DHCP, while lw4over6 information from PCP, while another MAP > domain's provision through manually configuration? when such kind of basic > questions not yet fully discussed, i doubt it is suitable to adopt this > work at so early stage. > > [ian] The intention for the draft is to describe using the presence (or > absence) of configuration parameters so that a CPE can work out which mode > to configure. The DHCP section is there to show how this would work if you > were using DHCP as the config mechanism, but it doesn't > > [maoke] the draft states "e.g." for the DHCP configuration firstly but later the total discussion is based on only DHCP. i doubt this can be a good direction for the further approach. > 2. some important issues are not yet comprehensively discussed, or almost > missing, in the current draft. e.g. (but not limited to), > - what is the correct NAPT source port overlapping behaviour for the > unified CPE? > - what is the correct fragment/reassemble behaviour for the unified > CPE? > > [ian] I agree that these are problems that need to be addressed across > both MAP and LW, but both of these problems need solutions that are aligned > at both ends of the softwire, not just the CPE. > [maoke] NAPT issue is totally CPE issue. i don't agree it is a problem for the *both* ends. fragmentation issue involves both sides, but CPE behaviour impacting the anycast BR/AFTR performance is a well-known issue in the community. even BR/AFTR has any change, the CPE must contain a work on this issue. > [ian] For the fragmentation question, Ole proposed this as being a > suitable task to tackle as it is common to all solutions. I would propose > that this is how it is tackled, and then any affected drafts are updated > based on the outcome. > > as currently there is no MAP members joins this draft, i am worrying that > the draft has fully reflected the concern from the MAP side. > > > [ian] As there haven't been any comments on the draft for some time from > anyone involved in the WG, I'm hoping that this means that everyone is > happy with the content! > [maoke] happy with the content at current stage = acknowledge to the authors' effort != happy with the content at the level of WG adoption. ;-) for the time being... - maoke > > thanks and regards, > maoke > > 2013/2/5 Suresh Krishnan > >> Hi all, >> This draft was a result of the discussion initiated at the softwire >> meeting in Atlanta to attempt to come up with a unified CPE >> specification that can work with both MAP and lw4o6. This call is being >> initiated to determine whether there is WG consensus towards adoption of >> draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state >> whether or not you're in favor of the adoption by replying to this >> email. If you are not in favor, please also state your objections in >> your response. This adoption call will complete on 2013-02-18. >> >> Regards >> Suresh & Yong >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > --14dae93b57be5f6b4604d504ab87 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2013/2/5 <ian.farrer@telekom.de>
Hi Maoke,

Thanks for your respons= e. Comments inline.

Cheers,
Ian

From: Maoke <fibrib@gmail.com>
Date: Tuesday, 5 February 2013 06:54
To: Suresh Krishnan <suresh.krishnan@ericsson= .com>
Cc: Softwires WG <softwires@ietf.org>, Yong= Cui <cuiyo= ng@tsinghua.edu.cn>, Ralph Droms <rdroms@cisco.com>
Subject: Re: [Softwires] Call for = adoption of draft-bfmk-softwire-unified-cpe-02
<= div>

hi Suresh and all,

personally i think this work is still premature for the WG adoption. reason= s are below:

1. current draft makes a logic for the CPE to decide its mode according to = what information it received from DHCP options. however, DHCP options are n= ot the only available provision mean. what if my CPE get MAP information th= rough DHCP, while lw4over6 information from PCP, while another MAP domain's provision through manually config= uration? when such kind of basic questions not yet fully discussed, i doubt= it is suitable to adopt this work at so early stage.

[ian] The intention for the dr= aft is to describe using the presence (or absence) of configuration paramet= ers so that a CPE can work out which mode to configure. The DHCP section is= there to show how this would work if you were using DHCP as the config mec= hanism, but it doesn't


[maoke] = the draft states "e.g." for the DHCP configuration firstly but la= ter the total discussion is based on only DHCP. i doubt this can be a good = direction for the further approach.
=A0
2. some important issues are not yet comprehensi= vely discussed, or almost missing, in the current draft. e.g. (but not limi= ted to),
=A0=A0=A0 - what is the correct NAPT source port overlapping behaviour for = the unified CPE?
=A0=A0=A0 - what is the correct fragment/reassemble behaviour for the unifi= ed CPE?

[ian] I agree that= these are problems that need to be addressed across both MAP and LW, but b= oth of these problems need solutions that are aligned at both ends of the s= oftwire, not just the CPE.

[maoke] NAPT issue is totally CPE issue. i don&= #39;t agree it is a problem for the *both* ends. fragmentation issue involv= es both sides, but CPE behaviour impacting the anycast BR/AFTR performance = is a well-known issue in the community. even BR/AFTR has any change, the CP= E must contain a work on this issue.

[ian] For the fragmentation question, Ole proposed this as being a sui= table task to tackle as it is common to all solutions. I would propose that= this is how it is tackled, and then any affected drafts are updated based = on the outcome.

as currently there is no MAP members joins this draft, i am worrying that t= he draft has fully reflected the concern from the MAP side.=A0


<= div>[ian] As there haven't been any comments on the draft for some time= from anyone involved in the WG, I'm hoping that this means that everyo= ne is happy with the content!

[maoke] happy with the content at current stage= =3D acknowledge to the authors' effort !=3D happy with the content at = the level of WG adoption. ;-) for the time being...

- maoke
=A0<= /div>
=

thanks and regards,
maoke

2013/2/5 Suresh Krishnan <suresh.krishnan@ericsson.com>
Hi all,
=A0 This draft was a result of the discussion initiated at the softwire
meeting in Atlanta to attempt to come up with a unified CPE
specification that can work with both MAP and lw4o6. This call is being
initiated to determine whether there is WG consensus towards adoption of draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state
whether or not you're in favor of the adoption by replying to this
email. If you are not in favor, please also state your objections in
your response. This adoption call will complete on 2013-02-18.

Regards
Suresh & Yong


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/s= oftwires


--14dae93b57be5f6b4604d504ab87-- From fibrib@gmail.com Tue Feb 5 18:17:23 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0468D21F8645 for ; Tue, 5 Feb 2013 18:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=0.610, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujGY-ymfDMC1 for ; Tue, 5 Feb 2013 18:17:22 -0800 (PST) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 44B2D21F8630 for ; Tue, 5 Feb 2013 18:17:22 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id m1so974994oag.40 for ; Tue, 05 Feb 2013 18:17:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bRqvT+7manopGP3TUdyhjj+daM7oLqrjqSHt+kCjztk=; b=u36/AFoRN1sAeGNh3TLFKepqKVCj8k/g4Fw9GHJRhepTztLgTqbrSyDpsAXuKR7raY JPJw2prqPocMlWGK1x0yqoGcBzZHFyp8KXRZJ2/1czK/x4X5QXeyvPg8vn/L+JhHbQVe 19XSS9Pg+TGWWi/oFZzI+VH3iWtE8e1A6GOYvy802ENLkVKK4EI3e9/3yFqlkUFmKQzd gGsvlmhvvudpCW+d1nowut3vmIIatyDW224X6dx5WBR4624VA4z3Y2zwKQmnyEcGOH34 1zNxgvxOBLsmZ4F5ClWyMPwNgASdc1RE525O154B/jOf9kG0KW47gKVtT9fxCNtMWygp DR8g== MIME-Version: 1.0 X-Received: by 10.182.54.46 with SMTP id g14mr19122710obp.55.1360117041897; Tue, 05 Feb 2013 18:17:21 -0800 (PST) Received: by 10.76.154.8 with HTTP; Tue, 5 Feb 2013 18:17:21 -0800 (PST) In-Reply-To: <05E6DBF1-1908-45E7-A0B9-0877DACA3ABA@cisco.com> References: <5106AE69.80705@gmail.com> <51086E17.10603@gmail.com> <510914DC.3090507@gmail.com> <2BE59159-2F6D-4D6A-98F9-F0E7775322E9@cisco.com> <510941A5.7090108@gmail.com> <87FB8635-1894-4689-BADE-40EAEEAF0CB3@laposte.net> <05E6DBF1-1908-45E7-A0B9-0877DACA3ABA@cisco.com> Date: Wed, 6 Feb 2013 11:17:21 +0900 Message-ID: From: Maoke To: Ole Troan Content-Type: multipart/alternative; boundary=14dae93b57be22a08b04d504ed8f Cc: Softwires WG Subject: Re: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 02:17:23 -0000 --14dae93b57be22a08b04d504ed8f Content-Type: text/plain; charset=ISO-8859-1 2013/2/5 Ole Troan > > But there has been a firm requirement in the WG that, even for shared > addresses, one of the CE could have the well-known ports. > > The WKPs-authorized option has been added to 4rd to satisfy this > requirement. > > I don't think this requirement has disappeared. > > does anyone in the working group have an opinion on the well-known ports > and shared IPv4 addresses? > the options we have are: > > a) if well-known ports are required then a full IPv4 address must be > assigned > b) allow that one user gets the well-known addresses, > but then the port block must at least be > 1024 ports. > (a) is comfortable. i do think that, when MAP is used for non-shared IPv4 addresses, either public or private, well-known ports are surely available with the exclusively used IPv4 addresses to enable server-side applications. such a demand exists. the idea is as the same as (a). (b) is acceptable with the condition that the port set size > 1024. well-known port usage for the shared IPv4 address is somehow tricky as it, philosophically, doesn't fit some considerations when we design the MAP architecture. e.g., well-known ports are well-known while the A+P framework incline to assign non-contiguous port numbers for a host for some reasons like privacy/security. on the other hand, the port set size > 1024 condition may restrict the operation so that PSID length, offset, ea-bit length cannot be selected arbitrarily according to the regular MAP deployment logic. - maoke > do we know that end users only need ports 0-1023 or 0-4095? > or are the ports the require to be opened inbound across the range? > > I'm leaning towards a. > > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --14dae93b57be22a08b04d504ed8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2013/2/5 Ole Troan <ot@cisco.com><= br>
> But there has been a firm requirement in the WG that= , even for shared addresses, one of the CE could have the well-known ports.=
> The WKPs-authorized option has been added to 4rd to satisfy this requi= rement.
> I don't think this requirement has disappeared.

does anyone in the working group have an opinion on the well-known po= rts and shared IPv4 addresses?
the options we have are:

a) if well-known ports are required then a full IPv4 address must be assign= ed
b) allow that one user gets the well-known addresses,
=A0 =A0 but then the port block must at least be > 1024 ports.

(a) is comfortable. i do think that, when MAP is used for n= on-shared IPv4 addresses, either public or private, well-known ports are surely=20 available with the exclusively used IPv4 addresses to enable server-side applications. such a demand exists. the idea is as the same as (a).
(b) is acceptable with the condition that the port=20 set size > 1024. well-known port usage for the shared IPv4 address is somehow tricky as it, philosophically, doesn't fit some considerations= =20 when we design the MAP architecture. e.g., well-known ports are well-known while the A+P framework incline to assign=20 non-contiguous port numbers for a host for some reasons like=20 privacy/security. on the other hand, the port set size > 1024 condition = may restrict the operation so that PSID length, offset, ea-bit length canno= t be selected arbitrarily according to the regular MAP deployment logic.
- maoke


do we know that end users only need ports 0-1023 or 0-4095?
or are the ports the require to be opened inbound across the range?

I'm leaning towards a.

cheers,
Ole
___________________________________= ____________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--14dae93b57be22a08b04d504ed8f-- From bingxuere@gmail.com Tue Feb 5 21:41:25 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC1021F89A4 for ; Tue, 5 Feb 2013 21:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7alvBtjOF6d for ; Tue, 5 Feb 2013 21:41:24 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7561621F899E for ; Tue, 5 Feb 2013 21:41:24 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id o17so1118541oag.6 for ; Tue, 05 Feb 2013 21:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=lgWRxR4N4UZrqMgtqSxZfur5RM3qlQjiM71PzmGrwtI=; b=ziKLgrjEqwEyVqX74yLtcpgUw3lmvHdrViGcpZzcRKiv29HXFWWdGRTefM+D9RQbYR QGgmvp20ExHCKBzLdGVx+WUKPPO50PHBa9pO0QeEL+V8dHTTt7ttrOSIWdMymU6vvqBB mHZ5q3sAI8eNFFd8TL54k3bNNIDrrELDhFmp3cVjcAAA3HuoTrrJtnnudMgtYY7y+tQy q3KlYSYVbD/wDVtpo80l5+POmoS2lhbx2bH0tOIc+Fqoez9/fhIQXfXLV+DQ5j/gwEBo jN3X1WxtByrinaAt7FNOb8KJbyklFtRCPoU3QAsvSFnWP4iVAS7J0uFJgIY+kfCIeEmX LKYA== X-Received: by 10.182.216.38 with SMTP id on6mr20503830obc.65.1360129284063; Tue, 05 Feb 2013 21:41:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.80.133 with HTTP; Tue, 5 Feb 2013 21:40:43 -0800 (PST) In-Reply-To: <511098A3.7030406@ericsson.com> References: <511098A3.7030406@ericsson.com> From: Qiong Date: Wed, 6 Feb 2013 13:40:43 +0800 Message-ID: To: Suresh Krishnan Content-Type: multipart/alternative; boundary=f46d04478a89d342db04d507c608 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 05:41:25 -0000 --f46d04478a89d342db04d507c608 Content-Type: text/plain; charset=UTF-8 Dear all, Support to adopt. This is a good starting point to work with both MAP and LW4O6. Best wishes Qiong On Tue, Feb 5, 2013 at 1:29 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Hi all, > This draft was a result of the discussion initiated at the softwire > meeting in Atlanta to attempt to come up with a unified CPE > specification that can work with both MAP and lw4o6. This call is being > initiated to determine whether there is WG consensus towards adoption of > draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state > whether or not you're in favor of the adoption by replying to this > email. If you are not in favor, please also state your objections in > your response. This adoption call will complete on 2013-02-18. > > Regards > Suresh & Yong > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --f46d04478a89d342db04d507c608 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

Support to adopt. This = is a good starting point to work with both MAP and LW4O6.
<= br>
Best wishes
Qiong


On Tue, Feb 5, 2013 at 1:29 PM, Suresh K= rishnan <suresh.krishnan@ericsson.com> wrote:
=
Hi all,
=C2=A0 This draft was a result of the discussion initiated at the softwire<= br> meeting in Atlanta to attempt to come up with a unified CPE
specification that can work with both MAP and lw4o6. This call is being
initiated to determine whether there is WG consensus towards adoption of draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state
whether or not you're in favor of the adoption by replying to this
email. If you are not in favor, please also state your objections in
your response. This adoption call will complete on 2013-02-18.

Regards
Suresh & Yong


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires



--
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China T= elecom Beijing Research Institude


Open source code:
lightweig= ht 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f46d04478a89d342db04d507c608-- From internet-drafts@ietf.org Wed Feb 6 01:39:49 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B639521F84F6; Wed, 6 Feb 2013 01:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZrqNpt8u-aM; Wed, 6 Feb 2013 01:39:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531B021F8808; Wed, 6 Feb 2013 01:39:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130206093949.4851.76943.idtracker@ietfa.amsl.com> Date: Wed, 06 Feb 2013 01:39:49 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-04.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 09:39:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Mapping of Address and Port with Encapsulation (MAP) Author(s) : Ole Troan Wojciech Dec Xing Li Congxiao Bao Satoru Matsushima Tetsuya Murakami Filename : draft-ietf-softwire-map-04.txt Pages : 29 Date : 2013-02-06 Abstract: This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation, and a generic mechanism for mapping between IPv6 addresses and IPv4 addresses and transport layer ports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ot@cisco.com Wed Feb 6 01:48:59 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5C621F8715 for ; Wed, 6 Feb 2013 01:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOvi9LcZnAgS for ; Wed, 6 Feb 2013 01:48:58 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 56D3821F8756 for ; Wed, 6 Feb 2013 01:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2021; q=dns/txt; s=iport; t=1360144138; x=1361353738; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=PK0XlQEREkZMuAeKDY6P0hdGxAPMu456b/pwaxTdMLI=; b=A1azMra0d/O1nIQmIH4sZea2hUnnkmLs6gTbGLpiVAY+oOwFIZncGDcy F0HO5Fnmsk1g6OUjxTT2quyzNuN9zOlMQV4cFo02gi0FuOzliu4RLljGK SGzA9obBr2/sdlA7Crx6yD02zw5aNpcDG/Vy2UR2rm30xQfdLNDfTcXHd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAOEjElGQ/khN/2dsb2JhbABFg3e8ThZzgh8BAQEDAQEBATc0GwsSNCciDhkJiAIGBwW7J44ygkhhA5YhgR2PNYJ/ X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; d="scan'208";a="11621163" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 06 Feb 2013 09:48:57 +0000 Received: from dhcp-10-61-109-116.cisco.com (dhcp-10-61-109-116.cisco.com [10.61.109.116]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r169muHM000667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 6 Feb 2013 09:48:57 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <20130206093949.4851.76943.idtracker@ietfa.amsl.com> Date: Wed, 6 Feb 2013 10:48:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130206093949.4851.76943.idtracker@ietfa.amsl.com> To: softwires@ietf.org X-Mailer: Apple Mail (2.1499) Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-04.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 09:48:59 -0000 with this update to the MAP-E revision: - reorganized the architecture section to make it cleared what applies = to shared addresses vs full ipv4 / prefix - fixed port offset to 4 (removed port parameters from the base spec) - simplified the interface-id text, removed 6052 reference greatly appreciate Tom's help in reviewing the document and proposing = changes for this revision. this document is in my view now ready for a WGLC. Best regards, Ole On Feb 6, 2013, at 10:39 , internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Softwires Working Group of the IETF. >=20 > Title : Mapping of Address and Port with Encapsulation = (MAP) > Author(s) : Ole Troan > Wojciech Dec > Xing Li > Congxiao Bao > Satoru Matsushima > Tetsuya Murakami > Filename : draft-ietf-softwire-map-04.txt > Pages : 29 > Date : 2013-02-06 >=20 > Abstract: > This document describes a mechanism for transporting IPv4 packets > across an IPv6 network using IP encapsulation, and a generic > mechanism for mapping between IPv6 addresses and IPv4 addresses and > transport layer ports. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-map >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-softwire-map-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-04 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From tom.taylor.stds@gmail.com Wed Feb 6 05:42:43 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E92B21F868D for ; Wed, 6 Feb 2013 05:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.256 X-Spam-Level: X-Spam-Status: No, score=-0.256 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3YJ6izQaE1y for ; Wed, 6 Feb 2013 05:42:43 -0800 (PST) Received: from mail-ie0-x22a.google.com (ie-in-x022a.1e100.net [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 18DAF21F84D0 for ; Wed, 6 Feb 2013 05:42:42 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id c11so1925284ieb.15 for ; Wed, 06 Feb 2013 05:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=8FcT4Ds5OH68c2YwA/r9P9l5dMeLZYNZqUo9GhuC4Ms=; b=FtLYF3ks4YLprCb7QR1qovxqOjsCKaxF5rYlCgmN/iRDDgnyyCHqfnRjevVKX3N3UB D7x/odRSm1G7Z9V2CzbGrnmc6bcTil0PzekdNB1TATkkD8z1ZAhQQhKnC/+peDPziZxe USYwT/UCkwsLKWKHMTXXU6uGbKGxd2t15m7Ssq05jvDmxO6Pzp2dMg0NYle3smzGJh8g M0wWa/1wgdexhE3/KgarsoU3Lhm3NLEYPEIxthK56T4aNsTRjIJ3PMTe6VvLSqRO837i TJwibbnIXg6xgXlXtBMvz8YUIhoI8alSAEP46I0/6LtRxIMaV9g5PAZ236/7CR+qagD0 BNMA== X-Received: by 10.50.170.36 with SMTP id aj4mr6087669igc.92.1360158162610; Wed, 06 Feb 2013 05:42:42 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id kf2sm3591912igc.0.2013.02.06.05.42.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Feb 2013 05:42:42 -0800 (PST) Message-ID: <51125DD1.4070405@gmail.com> Date: Wed, 06 Feb 2013 08:42:41 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130206-0, 06/02/2013), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 13:42:43 -0000 Section 5 of the latest version of MAP has the following: 1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 prefix, address or port set assignment. There can only be one Basic Mapping Rule per End-user IPv6 prefix. The Basic Mapping Rule is used to configure the MAP IPv6 address or prefix. 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. The Basic Mapping Rule is also a Forwarding Mapping Rule. Each Forwarding Mapping Rule will result in an entry in the Rules table for the Rule IPv4 prefix. Question: there will always be a BMR. In the absence of additional rules, how does a CE know whether it can use the BMR for forwarding or must always use the default rule? Remark: I'm not sure these two bullets tell the full story as they stand. I propose to modify them as follows: 1. Basic Mapping Rule (BMR) - mandatory. There can only be one Basic Mapping Rule per End-user IPv6 prefix. In combination with the End-user IPv6 prefix, the Basic Mapping Rule is used to derive the IPv4 prefix, address, or shared address and the PSID assigned to the CE. 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. The Basic Mapping Rule is also a Forwarding Mapping Rule. Each Forwarding Mapping Rule will result in an entry in the Rules table for the Rule IPv4 prefix. Given a destination IPv4 address and port within the MAP domain, a MAP node can use the matching FMR to derive the MAP IPv6 address of the interface through which that destination address-port combination can be reached. Tom Taylor From leo.liubing@huawei.com Thu Feb 7 04:39:49 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558B821F8585 for ; Thu, 7 Feb 2013 04:39:49 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deljNN48RpMa for ; Thu, 7 Feb 2013 04:39:48 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0E19C21F857C for ; Thu, 7 Feb 2013 04:39:40 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APN10831; Thu, 07 Feb 2013 12:39:40 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 12:39:37 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 12:39:39 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Thu, 7 Feb 2013 20:39:32 +0800 From: "Liubing (Leo)" To: Softwires WG Thread-Topic: MAP-MIB request for comments Thread-Index: AQHOBTAtcJOhmhsaCEqJm/2ZvK5A3g== Date: Thu, 7 Feb 2013 12:39:32 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6D882D@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "townsley@cisco.com" , Yong Cui Subject: [Softwires] MAP-MIB request for comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 12:39:49 -0000 SGksIEFsbA0KDQpUaGUgTUFQLU1JQiBkcmFmdCBoYXMgYmVlbiB1cGRhdGVkIGFzIC0wMyB2ZXJz aW9uLg0KDQpJbiBJRVRGODVAQXRsYW50YSwgd2UgaGFkIGEgYnJpZWYgZGlzY3Vzc2lvbiwgYW5k IHRoZSBtYWluIGNvbW1lbnQgd2FzIGZyb20gTWFyayBUb3duc2xleS4gSGUgcG9pbnRlZCBvdXQg dGhhdCB0aGUgdHVubmVsIHRhYmxlIGRlZmluZWQgaW4gdGhlIGRyYWZ0IHdvdWxkIG1ha2UgdGhl IEJSIHJlY29yZGluZyBldmVyeSBDRXMnIGFkZHJlc3NlcyBjb25uZWN0ZWQgdG8gaXQuIFRoaXMg b3BlcmF0aW9uIHdvdWxkIHNvbWV3aGF0IGNvdW50ZXJiYWxhbmNlIHRoZSBiZW5lZml0IG9mIHN0 YXRlbGVzcyBkZXNpZ24uIA0KQmFzaWNhbGx5LCBNYXJrJ3MgY29tbWVudCBpcyBhIHJlYWwgaXNz dWUsIGJ1dCBub3QgdGhhdCBzZXJpb3VzLiBUaGUgdHVubmVsIHRhYmxlIG5lZWRzIHRoZSB0cmFu c2xhdGlvbi9lbmNhcHN1bGF0aW9uIGFwcGxpY2F0aW9uIHRvIHByb3ZpZGUgQ0UgYWRkcmVzcyB0 byB0aGUgTUlCIGFnZW50LCB0aGF0IG1pZ2h0IHNsaWdodGx5IGltcGFjdCB0aGUgZm9yd2FyZGlu ZyBwZXJmb3JtYW5jZSwgYnV0IGl0IGlzIGZhciBmcm9tIHRoZSB3ZWlnaHQgb2YgInN0YXRlZnVs IiwgYmVjYXVzZSB0aGUgdGhlIEJSIHR1bm5lbCB0YWJsZSBpcyBub3QgZm9yIHJlYWwtdGltZSBs b29rIHVwLCBpdCBpcyBqdXN0IGEga2luZCBvZiBsb2dnaW5nLiBJbiB0aGUgd29yc3Qgc2l0dWF0 aW9uLCBldmVuIHRoZSBNSUIgY3Jhc2gsIHRoZSBwYWNrZXQgZm9yd2FyZGluZyB3b24ndCBiZSBi b3RoZXJlZC4NCg0KVGhlIHB1cnBvc2Ugd2UgZGVmaW5lZCBhIHR1bm5lbCB0YWJsZSBpcyB0byBh ZGQgc29tZSBzdGF0aXN0aWNzIG9mIENFIGNvbm5lY3RpbmcgQlIuIEZvciBleGFtcGxlLCB0aGUg SVNQIG1pZ2h0IHdhbnQgdG8ga25vdyBob3cgbWFueS93aGF0IENFcyBoYWQgYmVlbiBjb25uZWN0 ZWQgdG8gYSBjZXJ0YWluIEJSLiAgVGhpcyBtaWdodCBiZSB1c2VmdWwgZm9yIHNlcnZpY2UgYW5h bHlzaXMgYW5kIG1hbmFnZW1lbnQsIGUuZy4gdG8gc3RhdGljIHBlcmNlbnRhZ2Ugb2YgTUFQIGVu YWJsZWQgYW5kIHRoZSB0cmFmZmljLCBzbyB0aGF0IHRoZSBJU1AgY291bGQgbGVhcm4gdGhlIHN0 YXR1cyBvZiBNQVAgZGVwbG95bWVudC91c2FnZSwgdGhlbiBtaWdodCBtYWtlIHNvbWUgcG9saWNp ZXMuIA0KQ29uc2lkZXJpbmcgdGhlIHR1bm5lbCB0YWJsZSBtaWdodCBzdGlsbCBtb3JlIG9yIGxl c3MgYnJpbmcgc29tZSBhZGRpdGlvbmFsIGNvbXBsZXhpdHksIHdlIGRlZmluZWQgaXQgYXMgYW4g b3B0aW9uYWwgb2JqZWN0IGluIHRoZSBNSUIuIFdlIGRlZmluZWQgdHdvIG1hcC1NSUItQ29tcGxp YW5jZSwgb25lIGlzIGJhc2ljIGNvbXBsaWFuY2Ugb25seSBjb250YWluaW5nIHRoZSBydWxlIHRh YmxlLCB0aGUgb3RoZXIgaXMgZnVsbCBjb21wbGlhbmNlIGNvbnRhaW5pbmcgcnVsZSB0YWJsZSBh bmQgdHVubmVsIHRhYmxlLiANCg0KV2UgZXhwZWN0IHlvdXIgY29tbWVudHMuIFRoYW5rcyBhIGxv dCENCg0KQWxsIHRoZSBiZXN0LA0KQmluZw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDcsIDIwMTMgODowMSBQTQ0K VG86IExpdWJpbmcgKExlbykNCkNjOiB3ZWFwb25AY3NuZXQxLmNzLnRzaW5naHVhLmVkdS5jbjsg ZG9uZ2ppYW5nQGNzbmV0MS5jcy50c2luZ2h1YS5lZHUuY247IEZ1eXUgKEVsZXZlbik7IFNoZW5n IEppYW5nDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZ1LXNv ZnR3aXJlLW1hcC1taWItMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWZ1 LXNvZnR3aXJlLW1hcC1taWItMDMudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IEJpbmcgTGl1IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVu YW1lOgkgZHJhZnQtZnUtc29mdHdpcmUtbWFwLW1pYg0KUmV2aXNpb246CSAwMw0KVGl0bGU6CQkg RGVmaW5pdGlvbnMgb2YgTWFuYWdlZCBPYmplY3RzIGZvciBNQVAtRQ0KQ3JlYXRpb24gZGF0ZToJ IDIwMTMtMDItMDcNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBh Z2VzOiAxMw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1mdS1zb2Z0d2lyZS1tYXAtbWliLTAzLnR4dA0KU3RhdHVzOiAgICAgICAgICBo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZ1LXNvZnR3aXJlLW1hcC1taWIN Ckh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZnUtc29m dHdpcmUtbWFwLW1pYi0wMw0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1mdS1zb2Z0d2lyZS1tYXAtbWliLTAzDQoNCkFic3RyYWN0Og0KICAg VGhpcyBtZW1vIGRlZmluZXMgYSBwb3J0aW9uIG9mIHRoZSBNYW5hZ2VtZW50IEluZm9ybWF0aW9u IEJhc2UgKE1JQikNCiAgIGZvciB1c2luZyB3aXRoIG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2Nv bHMgaW4gdGhlIEludGVybmV0DQogICBjb21tdW5pdHkuIEluIHBhcnRpY3VsYXIsIGl0IGRlZmlu ZXMgbWFuYWdlZCBvYmplY3RzIGZvciBNQVANCiAgIGVuY2Fwc3VsYXRpb24gbW9kZS4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From ot@cisco.com Thu Feb 7 04:48:59 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E2621F852B for ; Thu, 7 Feb 2013 04:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.579 X-Spam-Level: X-Spam-Status: No, score=-10.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nM+d+3RiLwM for ; Thu, 7 Feb 2013 04:48:58 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8264F21F854C for ; Thu, 7 Feb 2013 04:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1641; q=dns/txt; s=iport; t=1360241338; x=1361450938; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=bcRDitdM6SHRKHkD46YgeITxjxuxQbhZvs45732NEsg=; b=gWR/vlDR2mxqLgGkSJvXeI96vzAVKyWhxgdhje1m3QeEiPI5W5K1QVzt UgfX1LNYfDeLvIRltYqu3s8czuyVqNswMN69ngj9ubUBTv3qVTN5qwdoi C7T0oQMH/kN6Ja/MxsWGqRrF23f0Cz/kAGn9cfij/qj/ISJeXRr81C8qM Q=; X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; d="scan'208";a="11651410" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 07 Feb 2013 12:48:57 +0000 Received: from dhcp-lys02-vla252-10-147-116-49.cisco.com (dhcp-lys02-vla252-10-147-116-49.cisco.com [10.147.116.49]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r17CmvP9003749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 12:48:57 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6D882D@nkgeml506-mbx.china.huawei.com> Date: Thu, 7 Feb 2013 13:48:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <87C876FC-6B2D-4570-8B7E-CC6D5FC73C8C@cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6D882D@nkgeml506-mbx.china.huawei.com> To: Liubing (Leo) X-Mailer: Apple Mail (2.1499) Cc: Softwires WG , "townsley@cisco.com" , Yong Cui Subject: Re: [Softwires] MAP-MIB request for comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 12:48:59 -0000 > The MAP-MIB draft has been updated as -03 version. >=20 > In IETF85@Atlanta, we had a brief discussion, and the main comment was = from Mark Townsley. He pointed out that the tunnel table defined in the = draft would make the BR recording every CEs' addresses connected to it. = This operation would somewhat counterbalance the benefit of stateless = design.=20 > Basically, Mark's comment is a real issue, but not that serious. The = tunnel table needs the translation/encapsulation application to provide = CE address to the MIB agent, that might slightly impact the forwarding = performance, but it is far from the weight of "stateful", because the = the BR tunnel table is not for real-time look up, it is just a kind of = logging. In the worst situation, even the MIB crash, the packet = forwarding won't be bothered. >=20 > The purpose we defined a tunnel table is to add some statistics of CE = connecting BR. For example, the ISP might want to know how many/what CEs = had been connected to a certain BR. This might be useful for service = analysis and management, e.g. to static percentage of MAP enabled and = the traffic, so that the ISP could learn the status of MAP = deployment/usage, then might make some policies.=20 > Considering the tunnel table might still more or less bring some = additional complexity, we defined it as an optional object in the MIB. = We defined two map-MIB-Compliance, one is basic compliance only = containing the rule table, the other is full compliance containing rule = table and tunnel table.=20 how is the BR supposed to learn the CE addresses? cheers, Ole= From Branimir.Rajtar@t.ht.hr Thu Feb 7 13:50:52 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FFC21F8481 for ; Thu, 7 Feb 2013 13:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vR2uWYQk5kG for ; Thu, 7 Feb 2013 13:50:50 -0800 (PST) Received: from mx02.t.ht.hr (mx02.t.ht.hr [195.29.161.89]) by ietfa.amsl.com (Postfix) with SMTP id D024F21F8921 for ; Thu, 7 Feb 2013 13:50:35 -0800 (PST) Received: from no.name.available by mx02.t.ht.hr via smtpd (for mail.ietf.org [64.170.98.30]) with ESMTP; Thu, 7 Feb 2013 22:18:32 +0100 Received: from (unknown [172.17.66.76]) by scmg2.t.ht.hr with smtp id 55df_6e4d_660eedaa_7170_11e2_b7d8_00219b931f47; Thu, 07 Feb 2013 22:50:33 +0100 Received: (private information removed) Thu, 7 Feb 2013 22:50:33 +0100 Received: (private information removed) S2010EXCHCA1.ad.local ([::1]) with mapi id 14.02.0328.009; Thu, 7 Feb 2013 22:50:33 +0100 From: Branimir Rajtar To: Qiong , Suresh Krishnan Thread-Topic: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 Thread-Index: AQHOBCyh5Lnmqh52Jk270m7C8ma+FZhu8TpQ Date: Thu, 7 Feb 2013 21:50:32 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB05A549@S2010EXCH1.ad.local> References: <511098A3.7030406@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.13] Content-Type: multipart/alternative; boundary="_000_786F13AA11E69F4DB2CCA23F7400C2FB05A549S2010EXCH1adlocal_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Feb 2013 21:50:33.0432 (UTC) FILETIME=[27A24580:01CE057D] Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 21:50:53 -0000 --_000_786F13AA11E69F4DB2CCA23F7400C2FB05A549S2010EXCH1adlocal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 SGkgYWxsLA0KDQpJIGFncmVlIHdpdGggdGhlIHJlc3BvbnNlIGJlbG93IGFuZCBJIHN1cHBvcnQg YWRvcHRpb24uDQoNCihBbHNvLCBJJ20gbmV3IHRvIHRoaXMgd29ya2dyb3VwLCBidXQgSeKAmXZl IGhhZCBhIGJpdCBvZiBleHBlcmllbmNlIHdpdGggc29mdHdpcmVzIHNvIEkgaG9wZSB0byBjb250 cmlidXRlIGluIHRoZSBmdXR1cmUuKQ0KDQpCUiwNCkJyYW5pbWlyIFJhanRhcg0KQ3JvYXRpYW4g VGVsZWNvbQ0KDQpGcm9tOiBzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNvZnR3 aXJlcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUWlvbmcNClNlbnQ6IFdlZG5lc2Rh eSwgRmVicnVhcnkgMDYsIDIwMTMgNjo0MSBBTQ0KVG86IFN1cmVzaCBLcmlzaG5hbg0KQ2M6IFNv ZnR3aXJlcyBXRzsgWW9uZyBDdWk7IFJhbHBoIERyb21zDQpTdWJqZWN0OiBSZTogW1NvZnR3aXJl c10gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtYmZtay1zb2Z0d2lyZS11bmlmaWVkLWNwZS0w Mg0KDQpEZWFyIGFsbCwNCg0KU3VwcG9ydCB0byBhZG9wdC4gVGhpcyBpcyBhIGdvb2Qgc3RhcnRp bmcgcG9pbnQgdG8gd29yayB3aXRoIGJvdGggTUFQIGFuZCBMVzRPNi4NCg0KQmVzdCB3aXNoZXMN ClFpb25nDQoNCk9uIFR1ZSwgRmViIDUsIDIwMTMgYXQgMToyOSBQTSwgU3VyZXNoIEtyaXNobmFu IDxzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tPG1haWx0bzpzdXJlc2gua3Jpc2huYW5AZXJp Y3Nzb24uY29tPj4gd3JvdGU6DQpIaSBhbGwsDQogIFRoaXMgZHJhZnQgd2FzIGEgcmVzdWx0IG9m IHRoZSBkaXNjdXNzaW9uIGluaXRpYXRlZCBhdCB0aGUgc29mdHdpcmUNCm1lZXRpbmcgaW4gQXRs YW50YSB0byBhdHRlbXB0IHRvIGNvbWUgdXAgd2l0aCBhIHVuaWZpZWQgQ1BFDQpzcGVjaWZpY2F0 aW9uIHRoYXQgY2FuIHdvcmsgd2l0aCBib3RoIE1BUCBhbmQgbHc0bzYuIFRoaXMgY2FsbCBpcyBi ZWluZw0KaW5pdGlhdGVkIHRvIGRldGVybWluZSB3aGV0aGVyIHRoZXJlIGlzIFdHIGNvbnNlbnN1 cyB0b3dhcmRzIGFkb3B0aW9uIG9mDQpkcmFmdC1iZm1rLXNvZnR3aXJlLXVuaWZpZWQtY3BlLTAy IGFzIGEgc29mdHdpcmUgV0cgZHJhZnQuIFBsZWFzZSBzdGF0ZQ0Kd2hldGhlciBvciBub3QgeW91 J3JlIGluIGZhdm9yIG9mIHRoZSBhZG9wdGlvbiBieSByZXBseWluZyB0byB0aGlzDQplbWFpbC4g SWYgeW91IGFyZSBub3QgaW4gZmF2b3IsIHBsZWFzZSBhbHNvIHN0YXRlIHlvdXIgb2JqZWN0aW9u cyBpbg0KeW91ciByZXNwb25zZS4gVGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgY29tcGxldGUgb24g MjAxMy0wMi0xOC4NCg0KUmVnYXJkcw0KU3VyZXNoICYgWW9uZw0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0 DQpTb2Z0d2lyZXNAaWV0Zi5vcmc8bWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQoNCg0KDQotLQ0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUWlvbmcgU3VuDQpDaGlu YSBUZWxlY29tIEJlaWppbmcgUmVzZWFyY2ggSW5zdGl0dWRlDQoNCg0KT3BlbiBzb3VyY2UgY29k ZToNCmxpZ2h0d2VpZ2h0IDRvdmVyNjogaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9s YWZ0Ni8NClBDUC1uYXRjb29yZDogaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9wY3Bw b3J0c2V0ZGVtby8NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQoKCjxIVE1MPjxQPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Izk5OTk5OSBzaXplPTE+DQoN CklaSkFWQSBPIE9EUklDQU5KVSBPREdPVk9STk9TVEk6IFNhZHLFvmFqIG92ZSBwb3J1a2UgaSBl dmVudHVhbG5vIHByaWxvxb5lbmloIGRhdG90ZWthIGplIHBvdmplcmxqaXYgaSBuYW1pamVuamVu IGplIHNhbW8gb3NvYmFtYSBpbGkgc3ViamVrdGltYSBrb2ppIHN1IG5hdmVkZW5pIHUgYWRyZXNp LiBVa29saWtvIHN0ZSBwcmltaWxpIG92dSBwb3J1a3UgZ3JlxaFrb20sIG1vbGltbyBWYXMsIG9i YXZpamVzdGl0ZSBwb8WhaWxqYXRlbGphLCBhIHBvcnVrdSBpIHN2ZSBuamVuZSBwcml2aXRrZSBv ZG1haCwgYmV6IMSNaXRhbmphLCB0cmFqbm8gdWtsb25pdGUgcyByYcSNdW5hbGEuIEJpbG8ga2Fr dm8gcHJlbm/FoWVuamUsIGtvcGlyYW5qZSBpbGkgZGlzdHJpYnVjaWphIGluZm9ybWFjaWphIHNh ZHLFvmFuaWggdSBwb3J1Y2kgdHJlxIdpbSBvc29iYW1hIGplIHphYnJhbmplbm8gaSBtb8W+ZSBi aXRpIHpha29uc2tpIGthxb5uaml2by4gU2FkcsW+YWosIHN0YXZvdmkgaSBtacWhbGplbmphIGl6 bmVzZW5pIHUgcG9ydWNpIHN1IGF1dG9yb3ZpIGkgbmUgcHJlZHN0YXZsamFqdSBudcW+bm8gc3Rh dm92ZSBIVCAtIEhydmF0c2tpaCB0ZWxla29tdW5pa2FjaWphIGQuZC4gSFQgbmUgcHJpaHZhxIdh IG5pa2FrdnUgb2Rnb3Zvcm5vc3QgemEgZXZlbnR1YWxudSDFoXRldHUgbmFzdGFsdSBwcmltaXRr b20gb3ZlIHBvcnVrZSBpIHByaWxvZ2Egc2FkcsW+YW5paCB1IHBvcnVjaS4NCg0KPC9GT05UPjwv UD48UD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM5OTk5OTkgc2l6ZT0xPg0KDQogRElTQ0xBSU1F UjpUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhcyB3ZWxsIGFzIGFueSBmaWxlcyBhdHRhY2hl ZCB0byBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIGluZGl2aWR1 YWxzIG9yIGVudGl0aWVzIHdoaWNoIHRoZXkgYXJlIGFkZHJlc3NlZCB0by4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIHBlcm1hbmVudGx5IHJlbW92ZSB0aGUgbWVzc2FnZSBhbmQgYWxsIGF0dGFjaGVk IGZpbGVzIGZyb20gdGhlIGNvbXB1dGVyLiBBbnkgZGlzY2xvc3VyZSwgY29weWluZyBvciBkaXN0 cmlidXRpb24gb2YgYWxsIG9yIGEgcGFydCBvZiBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWlu IHRvIG9yIGJ5IHRoaXJkIHBhcnRpZXMgaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVs LiBQbGVhc2Ugbm90ZSB0aGF0IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVzZW50ZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSBzb2xlbHkgdGhvc2Ugb2YgdGhlIGF1dGhvciBhbmQgZG8gbm90IG5lY2Vz c2FyaWx5IHJlcHJlc2VudCB0aGUgdmlld3MgYW5kIG9waW5pb25zIG9mIENyb2F0aWFuIFRlbGVj b20gSW5jLiBDcm9hdGlhbiBUZWxlY29tIEluYy4gYWNjZXB0cyBubyBsaWFiaWxpdHkgZm9yIGFu eSBwb3RlbnRpYWwgZGFtYWdlIGNhdXNlZCBieSB0aGlzIG1lc3NhZ2UgYW5kIGZpbGVzIGF0dGFj aGVkIHRvIGl0Lg0KDQo8L0ZPTlQ+PC9QPjwvSFRNTD4K --_000_786F13AA11E69F4DB2CCA23F7400C2FB05A549S2010EXCH1adlocal_ Content-Type: text/HTML; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2Ut MToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0 IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkhSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIGFs bCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIHRoZSBy ZXNwb25zZSBiZWxvdyBhbmQgSSBzdXBwb3J0IGFkb3B0aW9uLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPihBbHNvLCBJJ20gbmV3IHRvIHRoaXMgd29ya2dyb3VwLCBidXQg SeKAmXZlIGhhZCBhIGJpdCBvZiBleHBlcmllbmNlIHdpdGggc29mdHdpcmVzIHNvIEkgaG9wZSB0 byBjb250cmlidXRlIGluIHRoZSBmdXR1cmUuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5CUiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJy YW5pbWlyIFJhanRhcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Q3JvYXRpYW4gVGVsZWNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gc29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzb2Z0d2lyZXMt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UWlvbmc8YnI+DQo8Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAwNiwgMjAxMyA2OjQxIEFNPGJyPg0KPGI+VG86PC9i PiBTdXJlc2ggS3Jpc2huYW48YnI+DQo8Yj5DYzo8L2I+IFNvZnR3aXJlcyBXRzsgWW9uZyBDdWk7 IFJhbHBoIERyb21zPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU29mdHdpcmVzXSBDYWxsIGZv ciBhZG9wdGlvbiBvZiBkcmFmdC1iZm1rLXNvZnR3aXJlLXVuaWZpZWQtY3BlLTAyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5EZWFyIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5TdXBwb3J0IHRvIGFkb3B0LiBUaGlzIGlzIGEgZ29vZCBzdGFy dGluZyBwb2ludCB0byB3b3JrIHdpdGggYm90aCBNQVAgYW5kIExXNE82LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCB3aXNoZXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+UWlvbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBGZWIgNSwgMjAx MyBhdCAxOjI5IFBNLCBTdXJlc2ggS3Jpc2huYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpzdXJlc2gu a3Jpc2huYW5AZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+c3VyZXNoLmtyaXNobmFuQGVy aWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBhbGwsPGJyPg0KJm5ic3A7IFRoaXMg ZHJhZnQgd2FzIGEgcmVzdWx0IG9mIHRoZSBkaXNjdXNzaW9uIGluaXRpYXRlZCBhdCB0aGUgc29m dHdpcmU8YnI+DQptZWV0aW5nIGluIEF0bGFudGEgdG8gYXR0ZW1wdCB0byBjb21lIHVwIHdpdGgg YSB1bmlmaWVkIENQRTxicj4NCnNwZWNpZmljYXRpb24gdGhhdCBjYW4gd29yayB3aXRoIGJvdGgg TUFQIGFuZCBsdzRvNi4gVGhpcyBjYWxsIGlzIGJlaW5nPGJyPg0KaW5pdGlhdGVkIHRvIGRldGVy bWluZSB3aGV0aGVyIHRoZXJlIGlzIFdHIGNvbnNlbnN1cyB0b3dhcmRzIGFkb3B0aW9uIG9mPGJy Pg0KZHJhZnQtYmZtay1zb2Z0d2lyZS11bmlmaWVkLWNwZS0wMiBhcyBhIHNvZnR3aXJlIFdHIGRy YWZ0LiBQbGVhc2Ugc3RhdGU8YnI+DQp3aGV0aGVyIG9yIG5vdCB5b3UncmUgaW4gZmF2b3Igb2Yg dGhlIGFkb3B0aW9uIGJ5IHJlcGx5aW5nIHRvIHRoaXM8YnI+DQplbWFpbC4gSWYgeW91IGFyZSBu b3QgaW4gZmF2b3IsIHBsZWFzZSBhbHNvIHN0YXRlIHlvdXIgb2JqZWN0aW9ucyBpbjxicj4NCnlv dXIgcmVzcG9uc2UuIFRoaXMgYWRvcHRpb24gY2FsbCB3aWxsIGNvbXBsZXRlIG9uIDIwMTMtMDIt MTguPGJyPg0KPGJyPg0KUmVnYXJkczxicj4NClN1cmVzaCAmYW1wOyBZb25nPGJyPg0KPGJyPg0K PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlNvZnR3aXJlc0Bp ZXRmLm9yZyI+U29mdHdpcmVzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXM8L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tIDxicj4NCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQpRaW9uZyBTdW48YnI+DQpD aGluYSBUZWxlY29tIEJlaWppbmcgUmVzZWFyY2ggSW5zdGl0dWRlPGJyPg0KPGJyPg0KPGJyPg0K T3BlbiBzb3VyY2UgY29kZTo8YnI+DQpsaWdodHdlaWdodCA0b3ZlcjY6IDxpPjxhIGhyZWY9Imh0 dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvbGFmdDYvIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9sYWZ0Ni88L2E+PC9pPjxicj4NClBDUC1uYXRj b29yZDo8aT4gPGEgaHJlZj0iaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9wY3Bwb3J0 c2V0ZGVtby8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVj dHMvcGNwcG9ydHNldGRlbW8vPC9hPiA8L2k+PGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KCjxESVY+PFA+PEhSPgo8UD48Rk9OVCBjb2xvcj0jOTk5OTk5IHNpemU9MSBmYWNlPUFy aWFsPklaSkFWQSBPIE9EUklDQU5KVSBPREdPVk9STk9TVEk6IFNhZHImIzM4MjthaiBvdmUgcG9y dWtlIGkgZXZlbnR1YWxubyBwcmlsbyYjMzgyO2VuaWggZGF0b3Rla2EgamUgcG92amVybGppdiBp IG5hbWlqZW5qZW4gamUgc2FtbyBvc29iYW1hIGlsaSBzdWJqZWt0aW1hIGtvamkgc3UgbmF2ZWRl bmkgdSBhZHJlc2kuIFVrb2xpa28gc3RlIHByaW1pbGkgb3Z1IHBvcnVrdSBncmUmIzM1Mztrb20s IG1vbGltbyBWYXMsIG9iYXZpamVzdGl0ZSBwbyYjMzUzO2lsamF0ZWxqYSwgYSBwb3J1a3UgaSBz dmUgbmplbmUgcHJpdml0a2Ugb2RtYWgsIGJleiAmIzI2OTtpdGFuamEsIHRyYWpubyB1a2xvbml0 ZSBzIHJhJiMyNjk7dW5hbGEuIEJpbG8ga2Frdm8gcHJlbm8mIzM1MztlbmplLCBrb3BpcmFuamUg aWxpIGRpc3RyaWJ1Y2lqYSBpbmZvcm1hY2lqYSBzYWRyJiMzODI7YW5paCB1IHBvcnVjaSB0cmUm IzI2MztpbSBvc29iYW1hIGplIHphYnJhbmplbm8gaSBtbyYjMzgyO2UgYml0aSB6YWtvbnNraSBr YSYjMzgyO25qaXZvLiBTYWRyJiMzODI7YWosIHN0YXZvdmkgaSBtaSYjMzUzO2xqZW5qYSBpem5l c2VuaSB1IHBvcnVjaSBzdSBhdXRvcm92aSBpIG5lIHByZWRzdGF2bGphanUgbnUmIzM4MjtubyBz dGF2b3ZlIEhUIC0gSHJ2YXRza29nIFRlbGVrb21hIGQuZC4gSFQgbmUgcHJpaHZhJiMyNjM7YSBu aWtha3Z1IG9kZ292b3Jub3N0IHphIGV2ZW50dWFsbnUgJiMzNTM7dGV0dSBuYXN0YWx1IHByaW1p dGtvbSBvdmUgcG9ydWtlIGkgcHJpbG9nYSBzYWRyJiMzODI7YW5paCB1IHBvcnVjaS4gPC9GT05U PjwvUD4NCjxQPjxGT05UIGNvbG9yPSM5OTk5OTkgc2l6ZT0xIGZhY2U9QXJpYWw+RElTQ0xBSU1F UjpUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhcyB3ZWxsIGFzIGFueSBmaWxlcyBhdHRhY2hl ZCB0byBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIGluZGl2aWR1 YWxzIG9yIGVudGl0aWVzIHdoaWNoIHRoZXkgYXJlIGFkZHJlc3NlZCB0by4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIHBlcm1hbmVudGx5IHJlbW92ZSB0aGUgbWVzc2FnZSBhbmQgYWxsIGF0dGFjaGVk IGZpbGVzIGZyb20gdGhlIGNvbXB1dGVyLiBBbnkgZGlzY2xvc3VyZSwgY29weWluZyBvciBkaXN0 cmlidXRpb24gb2YgYWxsIG9yIGEgcGFydCBvZiBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWlu IHRvIG9yIGJ5IHRoaXJkIHBhcnRpZXMgaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVs LiBQbGVhc2Ugbm90ZSB0aGF0IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVzZW50ZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSBzb2xlbHkgdGhvc2Ugb2YgdGhlIGF1dGhvciBhbmQgZG8gbm90IG5lY2Vz c2FyaWx5IHJlcHJlc2VudCB0aGUgdmlld3MgYW5kIG9waW5pb25zIG9mIENyb2F0aWFuIFRlbGVj b20gSW5jLiBDcm9hdGlhbiBUZWxlY29tIEluYy4gYWNjZXB0cyBubyBsaWFiaWxpdHkgZm9yIGFu eSBwb3RlbnRpYWwgZGFtYWdlIGNhdXNlZCBieSB0aGlzIG1lc3NhZ2UgYW5kIGZpbGVzIGF0dGFj aGVkIHRvIGl0LiA8L0ZPTlQ+PC9QPgo8L1A+PC9ESVY+CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_786F13AA11E69F4DB2CCA23F7400C2FB05A549S2010EXCH1adlocal_-- From leo.liubing@huawei.com Thu Feb 7 22:56:42 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44BB21F8A18 for ; Thu, 7 Feb 2013 22:56:42 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLiCJBtVDMKB for ; Thu, 7 Feb 2013 22:56:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D236321F89DC for ; Thu, 7 Feb 2013 22:56:40 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOG77562; Fri, 08 Feb 2013 06:56:39 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 8 Feb 2013 06:55:39 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 8 Feb 2013 14:56:38 +0800 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Fri, 8 Feb 2013 14:56:34 +0800 From: "Liubing (Leo)" To: Ole Troan Thread-Topic: [Softwires] MAP-MIB request for comments Thread-Index: AQHOBTAtcJOhmhsaCEqJm/2ZvK5A3pht0n+AgAGyB7A= Date: Fri, 8 Feb 2013 06:56:33 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6D8A7F@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6D882D@nkgeml506-mbx.china.huawei.com> <87C876FC-6B2D-4570-8B7E-CC6D5FC73C8C@cisco.com> In-Reply-To: <87C876FC-6B2D-4570-8B7E-CC6D5FC73C8C@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires WG , "townsley@cisco.com" , Yong Cui , "leo.liubing@gmail.com" Subject: Re: [Softwires] MAP-MIB request for comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 06:56:42 -0000 Hi, Ole Thanks for your quick reply. In order to do the statistics, the BR need a bit more codes to extract the = CE IPv6 addresses when doing de-encapsulation. That is what we said in the last mail the operation might slightly impact t= he performance, so we defined this MIB function as optional. =20 All the best, Bing > -----Original Message----- > From: Ole Troan [mailto:ot@cisco.com] > Sent: Thursday, February 07, 2013 8:49 PM > To: Liubing (Leo) > Cc: Softwires WG; townsley@cisco.com; Yong Cui > Subject: Re: [Softwires] MAP-MIB request for comments >=20 > > The MAP-MIB draft has been updated as -03 version. > > > > In IETF85@Atlanta, we had a brief discussion, and the main comment was > from Mark Townsley. He pointed out that the tunnel table defined in the > draft would make the BR recording every CEs' addresses connected to it. T= his > operation would somewhat counterbalance the benefit of stateless design. > > Basically, Mark's comment is a real issue, but not that serious. The tu= nnel > table needs the translation/encapsulation application to provide CE addre= ss > to the MIB agent, that might slightly impact the forwarding performance, > but it is far from the weight of "stateful", because the the BR tunnel ta= ble is > not for real-time look up, it is just a kind of logging. In the worst sit= uation, > even the MIB crash, the packet forwarding won't be bothered. > > > > The purpose we defined a tunnel table is to add some statistics of CE > connecting BR. For example, the ISP might want to know how many/what > CEs had been connected to a certain BR. This might be useful for service > analysis and management, e.g. to static percentage of MAP enabled and the > traffic, so that the ISP could learn the status of MAP deployment/usage, = then > might make some policies. > > Considering the tunnel table might still more or less bring some additi= onal > complexity, we defined it as an optional object in the MIB. We defined tw= o > map-MIB-Compliance, one is basic compliance only containing the rule tabl= e, > the other is full compliance containing rule table and tunnel table. >=20 > how is the BR supposed to learn the CE addresses? >=20 > cheers, > Ole From ian.farrer@telekom.de Fri Feb 8 00:44:37 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E32921F871C for ; Fri, 8 Feb 2013 00:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tT+XIlA2ww0x for ; Fri, 8 Feb 2013 00:44:35 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 83FA821F888E for ; Fri, 8 Feb 2013 00:44:33 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 08 Feb 2013 09:44:31 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by he110890 ([10.134.92.131]) with mapi; Fri, 8 Feb 2013 09:44:31 +0100 From: To: Date: Fri, 8 Feb 2013 09:44:32 +0100 Thread-Topic: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 Thread-Index: Ac4F2IM5dMGQ8prZSquMhRwAvVdljQ== Message-ID: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CD37C3EA5026Fianfarrertelekomde_" MIME-Version: 1.0 Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, rdroms@cisco.com Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 08:44:37 -0000 --_000_CD37C3EA5026Fianfarrertelekomde_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable HI Maoke, Comments in line. Cheers, Ian Deutsche Telekom AG Group Technology Ian Farrer IP Engineering Landgrabenweg 151, 53227 Bonn, Germany +49 228 93638046 (Phone) +49 170 4557418 (Mobile) E-Mail: ian.farrer@telekom.dewww.telekom.com<= http://www.telekom.com/> Life is for sharing. Deutsche Telekom AG Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) Board of Management: Ren=E9 Obermann (Chairman), Reinhard Clemens, Niek Jan van Damme, Timotheus H=F6ttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick Commercial register: Amtsgericht Bonn HRB 6794 Registered office: Bonn VAT identification no. DE 123475223 Big changes start small =96 conserve resources by not printing every e-mail= . From: Maoke > Date: Wednesday, 6 February 2013 02:58 To: Ian Farrer > Cc: "suresh.krishnan@ericsson.com" >, "softwire= s@ietf.org" >, "cuiyong@tsinghua.edu.cn" >, "rdroms@cisco.com" > Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-c= pe-02 2013/2/5 > Hi Maoke, Thanks for your response. Comments inline. Cheers, Ian From: Maoke > Date: Tuesday, 5 February 2013 06:54 To: Suresh Krishnan > Cc: Softwires WG >, Yong Cui = >, Ralph Droms > Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-c= pe-02 hi Suresh and all, personally i think this work is still premature for the WG adoption. reason= s are below: 1. current draft makes a logic for the CPE to decide its mode according to = what information it received from DHCP options. however, DHCP options are n= ot the only available provision mean. what if my CPE get MAP information th= rough DHCP, while lw4over6 information from PCP, while another MAP domain's= provision through manually configuration? when such kind of basic question= s not yet fully discussed, i doubt it is suitable to adopt this work at so = early stage. [ian] The intention for the draft is to describe using the presence (or abs= ence) of configuration parameters so that a CPE can work out which mode to = configure. The DHCP section is there to show how this would work if you wer= e using DHCP as the config mechanism, but it doesn't [maoke] the draft states "e.g." for the DHCP configuration firstly but late= r the total discussion is based on only DHCP. i doubt this can be a good di= rection for the further approach. [ian] That's not the intention. Only section 3.3 discusses DHCP in depth to= show how this works. The implementation is given as a should req. to be in= line with the DHCP provisioning should requirements in both MAP and lw4o6.= Point taken however =96 I'll try and make the rest of the document (e.g. E= xcept sec 3.3) less DHCP focused. 2. some important issues are not yet comprehensively discussed, or almost m= issing, in the current draft. e.g. (but not limited to), - what is the correct NAPT source port overlapping behaviour for the un= ified CPE? - what is the correct fragment/reassemble behaviour for the unified CPE= ? [ian] I agree that these are problems that need to be addressed across both= MAP and LW, but both of these problems need solutions that are aligned at = both ends of the softwire, not just the CPE. [maoke] NAPT issue is totally CPE issue. i don't agree it is a problem for = the *both* ends. fragmentation issue involves both sides, but CPE behaviour= impacting the anycast BR/AFTR performance is a well-known issue in the com= munity. even BR/AFTR has any change, the CPE must contain a work on this is= sue. [ian] If there are overlapping source ports, then this is also a problem fo= r the concentrator. If multiple initiators share the same v4 destination ad= dress / source ports, on what basis can the initiator forward ingress traff= ic? [ian] For the fragmentation question, Ole proposed this as being a suitable= task to tackle as it is common to all solutions. I would propose that this= is how it is tackled, and then any affected drafts are updated based on th= e outcome. as currently there is no MAP members joins this draft, i am worrying that t= he draft has fully reflected the concern from the MAP side. [ian] As there haven't been any comments on the draft for some time from an= yone involved in the WG, I'm hoping that this means that everyone is happy = with the content! [maoke] happy with the content at current stage =3D acknowledge to the auth= ors' effort !=3D happy with the content at the level of WG adoption. ;-) fo= r the time being... [ian] Let's see what the outcome of the adoption call is then. - maoke thanks and regards, maoke 2013/2/5 Suresh Krishnan > Hi all, This draft was a result of the discussion initiated at the softwire meeting in Atlanta to attempt to come up with a unified CPE specification that can work with both MAP and lw4o6. This call is being initiated to determine whether there is WG consensus towards adoption of draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2013-02-18. Regards Suresh & Yong _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_CD37C3EA5026Fianfarrertelekomde_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
HI Maoke,
<= br>
Comments in line.

Cheers,
= Ian

=
Deutsche Telekom AG
Group Technology=
Ian Farrer
IP Engineering
Landgrabenweg 151, 53227 Bonn= , Germany
+49 228 93638046 (Phone)
+49 170 4557418 (Mob= ile)
E-M= ail: ian.farrer@telekom.dewww.telekom.com
 
Life is for sharing.
&n= bsp;
Deutsche Telekom A= G
Supervisory Board: Pr= of. Dr. Ulrich Lehner (Chairman)
Board of Management: Ren=E9 Obermann (Chairman),
Reinhard Clem= ens, Niek Jan van Damme, Timotheus H=F6ttges,
Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion= Schick
Commercial regi= ster: Amtsgericht Bonn HRB 6794
Registered office: Bonn
VAT identification no. DE 123475223
 
Big ch= anges start small =96 conserve resources by not printing every e-mail.

From: Maoke <fibri= b@gmail.com>
Date: Wedne= sday, 6 February 2013 02:58
To: = Ian Farrer <ian.farrer@telekom= .de>
Cc: "suresh.krishnan@ericsson.com&q= uot; <suresh.krishnan@er= icsson.com>, "softwires@i= etf.org" <softwires@ietf.= org>, "cuiyong@tsing= hua.edu.cn" <cuiyong= @tsinghua.edu.cn>, "rdroms@= cisco.com" <rdroms@cisco.co= m>
Subject: Re: [Softwir= es] Call for adoption of draft-bfmk-softwire-unified-cpe-02
<= br>


2013/2/5 <ian.fa= rrer@telekom.de>
<= div>
Hi Maoke,

Thanks for your response. Comme= nts inline.

Cheers,
Ian
=
From: Maoke <fibrib@gm= ail.com>
Date: Tuesday, 5= February 2013 06:54
To: Suresh = Krishnan <suresh.krishnan@ericsson.com>
Cc: Softwires WG <softwires@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>, Ral= ph Droms <rdroms@c= isco.com>
Subject: Re: [S= oftwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02
=


hi Suresh and all,

personally i think this work is still premature for the WG adoption. reason= s are below:

1. current draft makes a logic for the CPE to decide its mode according to = what information it received from DHCP options. however, DHCP options are n= ot the only available provision mean. what if my CPE get MAP information th= rough DHCP, while lw4over6 information from PCP, while another MAP domain's provision through manually configurat= ion? when such kind of basic questions not yet fully discussed, i doubt it = is suitable to adopt this work at so early stage.

[ian] The intention for the dr= aft is to describe using the presence (or absence) of configuration paramet= ers so that a CPE can work out which mode to configure. The DHCP section is= there to show how this would work if you were using DHCP as the config mechanism, but it doesn't


[maoke] the draft states "e.g." for the DHCP configuration firstl= y but later the total discussion is based on only DHCP. i doubt this can be= a good direction for the further approach.

[ian] That's not the int= ention. Only section 3.3 discusses DHCP in depth to show how this works. Th= e implementation is given as a should req. to be in line with the DHCP prov= isioning should requirements in both MAP and lw4o6. Point taken however =96= I'll try and make the rest of the document (e.g. Except sec 3.3) less DHCP= focused.
 
2. some important issues are not yet= comprehensively discussed, or almost missing, in the current draft. e.g. (= but not limited to),
    - what is the correct NAPT source port overlapping behav= iour for the unified CPE?
    - what is the correct fragment/reassemble behaviour for = the unified CPE?

[ian] I a= gree that these are problems that need to be addressed across both MAP and = LW, but both of these problems need solutions that are aligned at both ends= of the softwire, not just the CPE.

[maoke] NAPT issue is totally CPE issue. i don't agree it is a problem for = the *both* ends. fragmentation issue involves both sides, but CPE behaviour= impacting the anycast BR/AFTR performance is a well-known issue in the com= munity. even BR/AFTR has any change, the CPE must contain a work on this issue.
=

[ian] If there are overlapping source ports, then this = is also a problem for the concentrator. If multiple initiators share the sa= me v4 destination address / source ports, on what basis can the initiator f= orward ingress traffic?


[ian] For the fragmentation quest= ion, Ole proposed this as being a suitable task to tackle as it is common t= o all solutions. I would propose that this is how it is tackled, and then a= ny affected drafts are updated based on the outcome.

as currently there is no MAP members joins this draft, i am worrying that t= he draft has fully reflected the concern from the MAP side. 

<= /div>

[ian] As there haven't been any comme= nts on the draft for some time from anyone involved in the WG, I'm hoping t= hat this means that everyone is happy with the content!

[maoke] happy with the content at current stage =3D acknowledge to the auth= ors' effort !=3D happy with the content at the level of WG adoption. ;-) fo= r the time being...

[ian] Let's see what the= outcome of the adoption call is then.


- maoke
 

thanks and regards,
maoke

2013/2/5 Suresh Krishnan <suresh.krishnan@ericsson.com>
Hi all,
  This draft was a result of the discussion initiated at the softwire<= br> meeting in Atlanta to attempt to come up with a unified CPE
specification that can work with both MAP and lw4o6. This call is being
initiated to determine whether there is WG consensus towards adoption of draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state
whether or not you're in favor of the adoption by replying to this
email. If you are not in favor, please also state your objections in
your response. This adoption call will complete on 2013-02-18.

Regards
Suresh & Yong


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/s= oftwires


 --_000_CD37C3EA5026Fianfarrertelekomde_-- From fibrib@gmail.com Fri Feb 8 01:30:01 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D767E21F8733 for ; Fri, 8 Feb 2013 01:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIDa1AJmJFWC for ; Fri, 8 Feb 2013 01:30:00 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1722C21F874F for ; Fri, 8 Feb 2013 01:29:59 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id h1so3843688oag.3 for ; Fri, 08 Feb 2013 01:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ul37uPn/RiK7tlnxwoZ5FKrHoZahzX+uQP8uyEEAQ2w=; b=S5C0euceuqJgwWwOzWMcCKIFWrEXjWXC41wLYdYVeMELCVKfM34uRVGmaXDeLzWCeL Qwjq8adbM/ro5FTjuprVqKs0jY8HKCAWOzTOlPfJDHrAYQ/vr41h+INlJnwyJPihqjnw EATfeF5CWsPA2HeASuIPwwupXVtDbQeIfa8V40xgc2+pLKr1K4Zggkm2ggSf/eTquK3P AJ5y5wDb9ZTdwcBVVJq0hxvNy4q1MwtxXFuaa7N4i59XCcr5d9WU3ctb55mJRJsNfp8e h3u65l/8ndby+oC28OqP06ak3uKm/R/E8NX1fDU08IbiQJd77OEARYcGvbuFkoVEwEJM 4Y1A== MIME-Version: 1.0 X-Received: by 10.182.54.46 with SMTP id g14mr3509765obp.55.1360315798598; Fri, 08 Feb 2013 01:29:58 -0800 (PST) Received: by 10.76.154.8 with HTTP; Fri, 8 Feb 2013 01:29:58 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Feb 2013 18:29:58 +0900 Message-ID: From: Maoke To: ian.farrer@telekom.de Content-Type: multipart/alternative; boundary=14dae93b57bef534ef04d53333b9 Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, rdroms@cisco.com Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 09:30:02 -0000 --14dae93b57bef534ef04d53333b9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable hi Ian, 2013/2/8 > HI Maoke, > > Comments in line. > > Cheers, > Ian > > > Deutsche Telekom AG > Group Technology > Ian Farrer > IP Engineering > Landgrabenweg 151, 53227 Bonn, Germany > +49 228 93638046 (Phone) > +49 170 4557418 (Mobile) > E-Mail: ian.farrer@telekom.dewww.telekom.com > > Life is for sharing. > > Deutsche Telekom AG > Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) > Board of Management: Ren=E9 Obermann (Chairman), > Reinhard Clemens, Niek Jan van Damme, Timotheus H=F6ttges, > Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick > Commercial register: Amtsgericht Bonn HRB 6794 > Registered office: Bonn > VAT identification no. DE 123475223 > > *Big changes start small **=96** conserve resources by not printing every > e-mail.* > > From: Maoke > Date: Wednesday, 6 February 2013 02:58 > To: Ian Farrer > Cc: "suresh.krishnan@ericsson.com" , " > softwires@ietf.org" , "cuiyong@tsinghua.edu.cn" < > cuiyong@tsinghua.edu.cn>, "rdroms@cisco.com" > > Subject: Re: [Softwires] Call for adoption of > draft-bfmk-softwire-unified-cpe-02 > > > > 2013/2/5 > >> Hi Maoke, >> >> Thanks for your response. Comments inline. >> >> Cheers, >> Ian >> >> From: Maoke >> Date: Tuesday, 5 February 2013 06:54 >> To: Suresh Krishnan >> Cc: Softwires WG , Yong Cui , >> Ralph Droms >> Subject: Re: [Softwires] Call for adoption of >> draft-bfmk-softwire-unified-cpe-02 >> >> >> hi Suresh and all, >> >> personally i think this work is still premature for the WG adoption. >> reasons are below: >> >> 1. current draft makes a logic for the CPE to decide its mode according >> to what information it received from DHCP options. however, DHCP options >> are not the only available provision mean. what if my CPE get MAP >> information through DHCP, while lw4over6 information from PCP, while >> another MAP domain's provision through manually configuration? when such >> kind of basic questions not yet fully discussed, i doubt it is suitable = to >> adopt this work at so early stage. >> >> [ian] The intention for the draft is to describe using the presence (or >> absence) of configuration parameters so that a CPE can work out which mo= de >> to configure. The DHCP section is there to show how this would work if y= ou >> were using DHCP as the config mechanism, but it doesn't >> >> > [maoke] the draft states "e.g." for the DHCP configuration firstly but > later the total discussion is based on only DHCP. i doubt this can be a > good direction for the further approach. > > [ian] That's not the intention. Only section 3.3 discusses DHCP in depth > to show how this works. The implementation is given as a should req. to b= e > in line with the DHCP provisioning should requirements in both MAP and > lw4o6. Point taken however =96 I'll try and make the rest of the document > (e.g. Except sec 3.3) less DHCP focused. > [maoke] in contrast, i don't think DHCP MUST be the only way for provisioning. i'd prefer the "e.g." rather than limiting the further mechanisms DHCP-focused. > > >> 2. some important issues are not yet comprehensively discussed, or almos= t >> missing, in the current draft. e.g. (but not limited to), >> - what is the correct NAPT source port overlapping behaviour for the >> unified CPE? >> - what is the correct fragment/reassemble behaviour for the unified >> CPE? >> >> [ian] I agree that these are problems that need to be addressed across >> both MAP and LW, but both of these problems need solutions that are alig= ned >> at both ends of the softwire, not just the CPE. >> > > [maoke] NAPT issue is totally CPE issue. i don't agree it is a problem fo= r > the *both* ends. fragmentation issue involves both sides, but CPE behavio= ur > impacting the anycast BR/AFTR performance is a well-known issue in the > community. even BR/AFTR has any change, the CPE must contain a work on th= is > issue. > > [ian] If there are overlapping source ports, then this is also a problem > for the concentrator. If multiple initiators share the same v4 destinatio= n > address / source ports, on what basis can the initiator forward ingress > traffic? > [maoke] we have had at least 3 alternative strategies regarding source port overlapping and are comparing their pros/cons. practical usage has proved the availability to some extent. > > >> [ian] For the fragmentation question, Ole proposed this as being a >> suitable task to tackle as it is common to all solutions. I would propos= e >> that this is how it is tackled, and then any affected drafts are updated >> based on the outcome. >> >> as currently there is no MAP members joins this draft, i am worrying tha= t >> the draft has fully reflected the concern from the MAP side. >> >> >> [ian] As there haven't been any comments on the draft for some time from >> anyone involved in the WG, I'm hoping that this means that everyone is >> happy with the content! >> > > [maoke] happy with the content at current stage =3D acknowledge to the > authors' effort !=3D happy with the content at the level of WG adoption. = ;-) > for the time being... > > [ian] Let's see what the outcome of the adoption call is then. > [maoke] i insist to propose considering the problems: 1) if DHCP is the only way that the unified CPE can do with? 2) if participating multiple domain is/cannot definitely be supported? 3) how the CPE support source port overlapping and fragmentation with multiple domain exits? i contributed these concerns to the community -- it is enough for me. if the draft is less qualified with my criteria, i just do not use it. as to the adoption, i have expressed my comments. the result is not in my concern. thanks and regards, maoke > > > - maoke > > >> >> thanks and regards, >> maoke >> >> 2013/2/5 Suresh Krishnan >> >>> Hi all, >>> This draft was a result of the discussion initiated at the softwire >>> meeting in Atlanta to attempt to come up with a unified CPE >>> specification that can work with both MAP and lw4o6. This call is being >>> initiated to determine whether there is WG consensus towards adoption o= f >>> draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state >>> whether or not you're in favor of the adoption by replying to this >>> email. If you are not in favor, please also state your objections in >>> your response. This adoption call will complete on 2013-02-18. >>> >>> Regards >>> Suresh & Yong >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> >> > --14dae93b57bef534ef04d53333b9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable hi Ian,=A0

2013/2/8 &l= t;ian.farrer@tel= ekom.de>
HI Maoke,

Comments in line.<= /div>

Cheers,
Ian


Deutsche Telekom AG
Group Technology<= /font>
Ian Farrer
=
IP Engineering
Landgrabenweg 151, 532= 27 Bonn, Germany
E-Mail:=A0ian.farrer@telekom.dewww.telekom.com
=A0
Life is for sharing.
=A0
Deuts= che Telekom AG
Supervisory Board: Prof. Dr. Ulrich= Lehner (Chairman)
Boar= d of Management: Ren=E9 Obermann (Chairman),
Reinhard Clemens, Niek Jan = van Damme, Timotheus H=F6ttges,
Dr. Thomas Kremer, Claudia Nemat, P= rof. Dr. Marion Schick
= Commercial register: Amtsgericht Bonn HRB 6794
Registered office: Bonn
VAT identification no. DE 123475223=
=A0
Big changes start small=A0=96=A0conserve resources by not printing every e-ma= il.

From: Maoke <fibrib@gmail.com>
Date: Wednesday, 6 February 2013 02:58
To: Ian Farrer <ian.farrer@telekom.de>
Cc: "suresh.krishnan@ericsson.com&= quot; <suresh.krishnan@ericsson.com>, "softwires@ietf.org" <softwires@ietf.org>, "<= a href=3D"mailto:cuiyong@tsinghua.edu.cn" target=3D"_blank">cuiyong@tsinghu= a.edu.cn" <cuiyong@tsinghua.edu.cn>, "rdroms@cisco.com" <rdroms@cisco.com>

Subject: Re: [Softwires] Call = for adoption of draft-bfmk-softwire-unified-cpe-02



2013/2= /5 <ian.farrer@telekom.de>
Hi Maoke,

Thanks for your response. Comments inline.

Ch= eers,
Ian

From: Maoke <fibrib@gmail.com>
Date: Tuesday, 5 February 2013 06:54
To: Suresh Krishnan <suresh.krishnan@ericsson.c= om>
Cc: Softwires WG <softwires@ietf.org>, Yong = Cui <cuiyon= g@tsinghua.edu.cn>, Ralph Droms <rdroms@cisco.com>
Subject: Re: [Softwires] Call for a= doption of draft-bfmk-softwire-unified-cpe-02

=

hi Suresh and all,

personally i think this work is still premature for the WG adoption. reason= s are below:

1. current draft makes a logic for the CPE to decide its mode according to = what information it received from DHCP options. however, DHCP options are n= ot the only available provision mean. what if my CPE get MAP information th= rough DHCP, while lw4over6 information from PCP, while another MAP domain's provision through manually config= uration? when such kind of basic questions not yet fully discussed, i doubt= it is suitable to adopt this work at so early stage.

[ian] The intention for the dr= aft is to describe using the presence (or absence) of configuration paramet= ers so that a CPE can work out which mode to configure. The DHCP section is= there to show how this would work if you were using DHCP as the config mechanism, but it doesn't


[maoke] the draft states "e.g." for the DHCP configuration firstl= y but later the total discussion is based on only DHCP. i doubt this can be= a good direction for the further approach.

[ian] That's n= ot the intention. Only section 3.3 discusses DHCP in depth to show how this= works. The implementation is given as a should req. to be in line with the= DHCP provisioning should requirements in both MAP and lw4o6. Point taken h= owever =96 I'll try and make the rest of the document (e.g. Except sec = 3.3) less DHCP focused.

[maoke] in contrast, i don't thi= nk DHCP MUST be the only way for provisioning. i'd prefer the "e.g= ." rather than limiting the further mechanisms DHCP-focused.=A0
=A0
=A0
2. some important issues are not yet comprehensively discussed, or alm= ost missing, in the current draft. e.g. (but not limited to),
=A0=A0=A0 - what is the correct NAPT source port overlapping behaviour for = the unified CPE?
=A0=A0=A0 - what is the correct fragment/reassemble behaviour for the unifi= ed CPE?

[ian] I agree that= these are problems that need to be addressed across both MAP and LW, but b= oth of these problems need solutions that are aligned at both ends of the s= oftwire, not just the CPE.

[maoke] NAPT issue is totally CPE issue. i don't agree it is a problem = for the *both* ends. fragmentation issue involves both sides, but CPE behav= iour impacting the anycast BR/AFTR performance is a well-known issue in the= community. even BR/AFTR has any change, the CPE must contain a work on this issue.
=

[ian] If there are overlapping source ports, then= this is also a problem for the concentrator. If multiple initiators share = the same v4 destination address / source ports, on what basis can the initi= ator forward ingress traffic?

[maoke] we have had at least 3 alter= native strategies regarding source port overlapping and are comparing their= pros/cons. practical usage has proved the availability to some extent.=A0<= /div>
=A0


[ian] For the fragmentation question, Ole proposed this= as being a suitable task to tackle as it is common to all solutions. I wou= ld propose that this is how it is tackled, and then any affected drafts are= updated based on the outcome.

as currently there is no MAP members joins this draft, i am worrying that t= he draft has fully reflected the concern from the MAP side.=A0


[ian] As there haven't been any comments= on the draft for some time from anyone involved in the WG, I'm hoping = that this means that everyone is happy with the content!

[maoke] happy with the content at current stage =3D acknowledge to the auth= ors' effort !=3D happy with the content at the level of WG adoption. ;-= ) for the time being...

[ian] Let's se= e what the outcome of the adoption call is then.

[maoke] i insist to propose considering the problems: 1) = if DHCP is the only way that the unified CPE can do with? 2) if participati= ng multiple domain is/cannot definitely be supported? 3) how the CPE suppor= t source port overlapping and fragmentation with multiple domain exits? i c= ontributed these concerns to the community -- it is enough for me. if the d= raft is less qualified with my criteria, i just do not use it.

as to the adoption, i have expressed my comments. the r= esult is not in my concern. =A0

thanks and regards= ,
maoke
=A0

- maoke
=A0

thanks and regards,
maoke

2013/2/5 Suresh Krishnan <suresh.krishnan@ericsson.com>
Hi all,
=A0 This draft was a result of the discussion initiated at the softwire
meeting in Atlanta to attempt to come up with a unified CPE
specification that can work with both MAP and lw4o6. This call is being
initiated to determine whether there is WG consensus towards adoption of draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state
whether or not you're in favor of the adoption by replying to this
email. If you are not in favor, please also state your objections in
your response. This adoption call will complete on 2013-02-18.

Regards
Suresh & Yong


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/s= oftwires


--14dae93b57bef534ef04d53333b9-- From tom.taylor.stds@gmail.com Mon Feb 11 18:43:49 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12D921F879A for ; Mon, 11 Feb 2013 18:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.243 X-Spam-Level: X-Spam-Status: No, score=-0.243 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0X4QN2I4MxL for ; Mon, 11 Feb 2013 18:43:49 -0800 (PST) Received: from mail-ia0-x22a.google.com (ia-in-x022a.1e100.net [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1540F21F8793 for ; Mon, 11 Feb 2013 18:43:48 -0800 (PST) Received: by mail-ia0-f170.google.com with SMTP id k20so7223583iak.29 for ; Mon, 11 Feb 2013 18:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=KA1fatT0p+ewa1fBRFAC/Rf23QZZlnpXuwBj0LOyscE=; b=E2CiHoLdCjlG0922tleYyoJnIO1VdQ7BeVJm8evGcvR5SxHIUR+a4cny+2j/0/SRxD JUAjm4G4HLgF7dhYbv+JRoUBKI+rQH+DLcvrSAMezo3E+44jjMvwOjsv9IsiEwVYv/sh cTIY1a0AlBVEhtg0XKobY1Db1df575tonYsonDea1hIkfXkOwAEoOidN1T5wKb7gL8SQ i7BPCgEz623OF1lbKHbd76FYy9yO7lczxshHdwuKFo/LR8zvRtKgqIqbdePESAa2iNlH Gd2zddnC0zh/EXNBNtVd4ifhgtrbUijDJUxhq80n3rdPYnPc07DaADUoqxIFH4A/8d26 wSEA== X-Received: by 10.50.11.229 with SMTP id t5mr142772igb.65.1360637028586; Mon, 11 Feb 2013 18:43:48 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-108-120.tor.primus.ca. [173.206.108.120]) by mx.google.com with ESMTPS id ww6sm29260844igb.2.2013.02.11.18.43.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 18:43:47 -0800 (PST) Message-ID: <5119AC61.7090806@gmail.com> Date: Mon, 11 Feb 2013 21:43:45 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires References: <51125DD1.4070405@gmail.com> In-Reply-To: <51125DD1.4070405@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130211-1, 11/02/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 02:43:49 -0000 I'm still hoping to see a response to this. On 06/02/2013 8:42 AM, Tom Taylor wrote: > Section 5 of the latest version of MAP has the following: > > 1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 prefix, > address or port set assignment. There can only be one Basic > Mapping Rule per End-user IPv6 prefix. The Basic Mapping Rule is > used to configure the MAP IPv6 address or prefix. > > 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. > The Basic Mapping Rule is also a Forwarding Mapping Rule. Each > Forwarding Mapping Rule will result in an entry in the Rules > table for the Rule IPv4 prefix. > > Question: there will always be a BMR. In the absence of additional > rules, how does a CE know whether it can use the BMR for forwarding or > must always use the default rule? > > Remark: I'm not sure these two bullets tell the full story as they > stand. I propose to modify them as follows: > > 1. Basic Mapping Rule (BMR) - mandatory. There can only be one > Basic Mapping Rule per End-user IPv6 prefix. In combination > with the End-user IPv6 prefix, the Basic Mapping Rule is used > to derive the IPv4 prefix, address, or shared address and > the PSID assigned to the CE. > > 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. > The Basic Mapping Rule is also a Forwarding Mapping Rule. Each > Forwarding Mapping Rule will result in an entry in the Rules > table for the Rule IPv4 prefix. Given a destination IPv4 address > and port within the MAP domain, a MAP node can use the matching > FMR to derive the MAP IPv6 address of the interface through > which that destination address-port combination can be reached. > > Tom Taylor From ot@cisco.com Tue Feb 12 00:27:49 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786DF21F87B1 for ; Tue, 12 Feb 2013 00:27:49 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJwqq3oPRg5j for ; Tue, 12 Feb 2013 00:27:48 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id ABFDD21F8706 for ; Tue, 12 Feb 2013 00:27:48 -0800 (PST) Received: from dhcp-lys02-vla252-10-147-116-66.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id E568C5F2E; Tue, 12 Feb 2013 00:27:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <5119AC61.7090806@gmail.com> Date: Tue, 12 Feb 2013 09:27:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 08:27:49 -0000 Tom, > I'm still hoping to see a response to this. >=20 > On 06/02/2013 8:42 AM, Tom Taylor wrote: >> Section 5 of the latest version of MAP has the following: >>=20 >> 1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 prefix, >> address or port set assignment. There can only be one Basic >> Mapping Rule per End-user IPv6 prefix. The Basic Mapping Rule = is >> used to configure the MAP IPv6 address or prefix. >>=20 >> 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. >> The Basic Mapping Rule is also a Forwarding Mapping Rule. = Each >> Forwarding Mapping Rule will result in an entry in the Rules >> table for the Rule IPv4 prefix. >>=20 >> Question: there will always be a BMR. In the absence of additional >> rules, how does a CE know whether it can use the BMR for forwarding = or >> must always use the default rule? the answer to that is in section 7, last bullet. that is, the MAP CE must be configured to be in hub and spoke mode or = mesh mode. which mode it is in decided if the BMR is used for forwarding or not. cheers, Ole From tom.taylor.stds@gmail.com Tue Feb 12 06:17:44 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AE221F8D0A for ; Tue, 12 Feb 2013 06:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.232 X-Spam-Level: X-Spam-Status: No, score=-0.232 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly857G3kKm2M for ; Tue, 12 Feb 2013 06:17:43 -0800 (PST) Received: from mail-ia0-x233.google.com (ia-in-x0233.1e100.net [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id BDF2321F8D09 for ; Tue, 12 Feb 2013 06:17:43 -0800 (PST) Received: by mail-ia0-f179.google.com with SMTP id x24so106962iak.24 for ; Tue, 12 Feb 2013 06:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=QJHeIk7CSqGuEII8Use8DP3pUAjCsK7X/xUbVDExdmE=; b=OxEhFJ8KpusN10Xnc6TWbGpX/bfWGZzVc2GvWKHUTG1TuqmRXjdxKoBJo8FOcT1iB6 gEMlLFcixYK+Z7LmweOANH7v0s1Lgud9CODxngT6RM5OkTSsydXrNe8byJWndxH1E5ul 5TLMzTofWAQ3mE9a4EqqCDPelp8WPkPj8N/8W6L3V5LjPgaBOrMgewr1NJ0hqzdXvbzK hPWNl+uVVXguhgqljVgBglyGzIQOZVOifyNgjwzwP6fIG6HOPXewtiDSAdARFeyHxAc0 9xlCRQS6IMh8f7olIXXUQn4zjzIUWZzRJ7/TmOk9yzViLP1d6042rG3FxCmYlroBxfrq Kt5A== X-Received: by 10.50.36.134 with SMTP id q6mr3446161igj.98.1360678663129; Tue, 12 Feb 2013 06:17:43 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-108-120.tor.primus.ca. [173.206.108.120]) by mx.google.com with ESMTPS id u4sm34262841igw.6.2013.02.12.06.17.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 06:17:42 -0800 (PST) Message-ID: <511A4F05.3060400@gmail.com> Date: Tue, 12 Feb 2013 09:17:41 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> In-Reply-To: <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130212-0, 12/02/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 14:17:44 -0000 Thanks. What about the assertions in the bullets? On 12/02/2013 3:27 AM, Ole Troan wrote: > Tom, > >> I'm still hoping to see a response to this. >> >> On 06/02/2013 8:42 AM, Tom Taylor wrote: >>> Section 5 of the latest version of MAP has the following: >>> >>> 1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 prefix, >>> address or port set assignment. There can only be one Basic >>> Mapping Rule per End-user IPv6 prefix. The Basic Mapping Rule is >>> used to configure the MAP IPv6 address or prefix. >>> >>> 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. >>> The Basic Mapping Rule is also a Forwarding Mapping Rule. Each >>> Forwarding Mapping Rule will result in an entry in the Rules >>> table for the Rule IPv4 prefix. >>> >>> Question: there will always be a BMR. In the absence of additional >>> rules, how does a CE know whether it can use the BMR for forwarding or >>> must always use the default rule? > > the answer to that is in section 7, last bullet. > > that is, the MAP CE must be configured to be in hub and spoke mode or mesh mode. > which mode it is in decided if the BMR is used for forwarding or not. > > cheers, > Ole > > From ot@cisco.com Tue Feb 12 06:22:25 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E97E21F8D77 for ; Tue, 12 Feb 2013 06:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.946 X-Spam-Level: X-Spam-Status: No, score=-9.946 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thL4YLsMujMy for ; Tue, 12 Feb 2013 06:22:18 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 72B2F21F8AA6 for ; Tue, 12 Feb 2013 06:22:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1432; q=dns/txt; s=iport; t=1360678938; x=1361888538; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=h5OlS+QWu/2N6DrSs3jUz0v9hLp1vNaSDg2EZID7VwU=; b=Xt1m1XA6/FohT2PXh30ng76fIcXvCOcJGAPuJC8YR1iAvQuRuqpOXpIE TpVSUME95HoViNmj5L7fIAUNl8U8pXq6vBltwFS0jAwPnoowX25JMQGLq BdJgrigOhwavo7yr2hNi+uaKoQUKqNUlYbhUDudXsZ3Ynt+WNHKaEF4LM Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADtPGlGQ/khM/2dsb2JhbABEvVWDZRZzgh8BAQEDAXkFCwsYLlcGiB8GrwmQFZEkYQOWJJBTgwc X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; d="scan'208";a="150399734" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 12 Feb 2013 14:22:17 +0000 Received: from dhcp-lys01-vla250-10-147-112-54.cisco.com (dhcp-lys01-vla250-10-147-112-54.cisco.com [10.147.112.54]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1CEMG6s024930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Feb 2013 14:22:17 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <511A4F05.3060400@gmail.com> Date: Tue, 12 Feb 2013 15:22:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 14:22:25 -0000 Tom, > Thanks. What about the assertions in the bullets? sorry, may be my short term memory... what do you mean? cheers, Ole >=20 > On 12/02/2013 3:27 AM, Ole Troan wrote: >> Tom, >>=20 >>> I'm still hoping to see a response to this. >>>=20 >>> On 06/02/2013 8:42 AM, Tom Taylor wrote: >>>> Section 5 of the latest version of MAP has the following: >>>>=20 >>>> 1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 prefix, >>>> address or port set assignment. There can only be one Basic >>>> Mapping Rule per End-user IPv6 prefix. The Basic Mapping = Rule is >>>> used to configure the MAP IPv6 address or prefix. >>>>=20 >>>> 2. Forwarding Mapping Rule (FMR) - optional, used for = forwarding. >>>> The Basic Mapping Rule is also a Forwarding Mapping Rule. = Each >>>> Forwarding Mapping Rule will result in an entry in the Rules >>>> table for the Rule IPv4 prefix. >>>>=20 >>>> Question: there will always be a BMR. In the absence of additional >>>> rules, how does a CE know whether it can use the BMR for forwarding = or >>>> must always use the default rule? >>=20 >> the answer to that is in section 7, last bullet. >>=20 >> that is, the MAP CE must be configured to be in hub and spoke mode or = mesh mode. >> which mode it is in decided if the BMR is used for forwarding or not. >>=20 >> cheers, >> Ole >>=20 >>=20 From wdec.ietf@gmail.com Tue Feb 12 09:05:37 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4AD21F8F90 for ; Tue, 12 Feb 2013 09:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.928 X-Spam-Level: X-Spam-Status: No, score=-2.928 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWbjZbbYZT+X for ; Tue, 12 Feb 2013 09:05:37 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3202421F8F84 for ; Tue, 12 Feb 2013 09:05:37 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id bv4so1757130qab.17 for ; Tue, 12 Feb 2013 09:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PUf6i5/uceoO3fLisRzU9TnbRT3o0ClFxgRGgarD35U=; b=D6OnOBsPdDER2X9DRHOH/5ocgbVny44Mr+kjsd1aobZe5bHkvxDcc49i4cHRMSL6SY uJ+N5Vi92tj/wg0UijreZn5wWc72FUHU+s+t3wqQssIQpGXLN+TyYvVeJPz2x/M6mX3i GVjLGvYzf2Vmh1TuwijZIZNvTqNuqk2UsFwD58oPa/iMb3D32YUkha3MRMVFjgi/3vr0 3BD0y9pPBITWa6FUcOmBlSdfflMdSsdp3VCDn7uFoUBo0vNG6m1NpwcNlMhOWuo2v2+t 4fCCpYFx+1r4vHP4f5PX8liP+oMx8KjDit4A4XM0HrNWP3FzV2R0loh60AscoYHcgvmT kCuA== MIME-Version: 1.0 X-Received: by 10.49.130.167 with SMTP id of7mr8341822qeb.22.1360688736393; Tue, 12 Feb 2013 09:05:36 -0800 (PST) Received: by 10.49.75.33 with HTTP; Tue, 12 Feb 2013 09:05:36 -0800 (PST) In-Reply-To: References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> Date: Tue, 12 Feb 2013 18:05:36 +0100 Message-ID: From: Wojciech Dec To: Ole Troan Content-Type: multipart/alternative; boundary=047d7bdc1a86c85bd604d58a08d4 Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 17:05:38 -0000 --047d7bdc1a86c85bd604d58a08d4 Content-Type: text/plain; charset=ISO-8859-1 Well, actually on this topic I think it may make sense at least from a terminology consistency perspective to go back to calling out the Default Mapping Rule (DMR) and, just like the BMR, marking it as mandatory. That's what actually is already in the DHCP draft. Regards, Woj. On 12 February 2013 15:22, Ole Troan wrote: > Tom, > > > Thanks. What about the assertions in the bullets? > > sorry, may be my short term memory... what do you mean? > > cheers, > Ole > > > > > > On 12/02/2013 3:27 AM, Ole Troan wrote: > >> Tom, > >> > >>> I'm still hoping to see a response to this. > >>> > >>> On 06/02/2013 8:42 AM, Tom Taylor wrote: > >>>> Section 5 of the latest version of MAP has the following: > >>>> > >>>> 1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 prefix, > >>>> address or port set assignment. There can only be one Basic > >>>> Mapping Rule per End-user IPv6 prefix. The Basic Mapping Rule > is > >>>> used to configure the MAP IPv6 address or prefix. > >>>> > >>>> 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. > >>>> The Basic Mapping Rule is also a Forwarding Mapping Rule. Each > >>>> Forwarding Mapping Rule will result in an entry in the Rules > >>>> table for the Rule IPv4 prefix. > >>>> > >>>> Question: there will always be a BMR. In the absence of additional > >>>> rules, how does a CE know whether it can use the BMR for forwarding or > >>>> must always use the default rule? > >> > >> the answer to that is in section 7, last bullet. > >> > >> that is, the MAP CE must be configured to be in hub and spoke mode or > mesh mode. > >> which mode it is in decided if the BMR is used for forwarding or not. > >> > >> cheers, > >> Ole > >> > >> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --047d7bdc1a86c85bd604d58a08d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, actually on this topic I think it may make sense at least from a term= inology consistency perspective to go back to calling out the Default Mappi= ng Rule (DMR) and, just like the BMR, marking it as mandatory. That's w= hat actually is already in the DHCP draft.

Regards,
Woj.



On 12 Februa= ry 2013 15:22, Ole Troan <ot@cisco.com> wrote:
Tom,

> Thanks. What about the assertions in the bullets?

sorry, may be my short term memory... what do you mean?

cheers,
Ole


>
> On 12/02/2013 3:27 AM, Ole Troan wrote:
>> Tom,
>>
>>> I'm still hoping to see a response to this.
>>>
>>> On 06/02/2013 8:42 AM, Tom Taylor wrote:
>>>> Section 5 of the latest version of MAP has the following:<= br> >>>>
>>>> =A0 =A01. =A0Basic Mapping Rule (BMR) - mandatory, used fo= r IPv4 prefix,
>>>> =A0 =A0 =A0 =A0address or port set assignment. =A0There ca= n only be one Basic
>>>> =A0 =A0 =A0 =A0Mapping Rule per End-user IPv6 prefix. =A0T= he Basic Mapping Rule is
>>>> =A0 =A0 =A0 =A0used to configure the MAP IPv6 address or p= refix.
>>>>
>>>> =A0 =A02. =A0Forwarding Mapping Rule (FMR) - optional, use= d for forwarding.
>>>> =A0 =A0 =A0 =A0The Basic Mapping Rule is also a Forwarding= Mapping Rule. =A0Each
>>>> =A0 =A0 =A0 =A0Forwarding Mapping Rule will result in an e= ntry in the Rules
>>>> =A0 =A0 =A0 =A0table for the Rule IPv4 prefix.
>>>>
>>>> Question: there will always be a BMR. In the absence of ad= ditional
>>>> rules, how does a CE know whether it can use the BMR for f= orwarding or
>>>> must always use the default rule?
>>
>> the answer to that is in section 7, last bullet.
>>
>> that is, the MAP CE must be configured to be in hub and spoke mode= or mesh mode.
>> which mode it is in decided if the BMR is used for forwarding or n= ot.
>>
>> cheers,
>> Ole
>>
>>

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--047d7bdc1a86c85bd604d58a08d4-- From tom.taylor.stds@gmail.com Tue Feb 12 17:14:23 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795AE21F8A66 for ; Tue, 12 Feb 2013 17:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.288 X-Spam-Level: * X-Spam-Status: No, score=1.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzjXagGy6pO8 for ; Tue, 12 Feb 2013 17:14:23 -0800 (PST) Received: from mail-ia0-x22e.google.com (ia-in-x022e.1e100.net [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DAC4521F8A64 for ; Tue, 12 Feb 2013 17:14:22 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id o25so678097iad.19 for ; Tue, 12 Feb 2013 17:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=A4J3P5CjmsixsgLUYLroN2AQVgFTKE7xWZbCMS57IjM=; b=GUahPhUUosdD9JJlDkYt4Mm2uTKTMwGGfHxZC6HA0iU/hDT9+zhRRsHgPpbCYzmmWw wQ+TfeZIXd3uisINp9kqKT1h+hPQR3eaVar0/ufqDwpbQPmZqiQPClzhKBzE9QSCgurs v/wwuuDV1/hcEV1UXG0tQPy/ZpDqjPIJKJR20WPR9c/D+hPnjBWUN2avDq4Isiwi11lC 7n0KCVCKBTLcPAz0kde3WEgSseqffchuXzsNB5JW9YStKhN2isJ+jSZbjoF85gZ4t42Q +D0pTq5k1sYUBkNdXn1tsODwVpDFyipTuydP1PK1B1wIdHfYYhHQmrGswdNctljQzHx8 0wig== X-Received: by 10.43.7.7 with SMTP id om7mr27179905icb.25.1360718062388; Tue, 12 Feb 2013 17:14:22 -0800 (PST) Received: from [127.0.0.1] (dsl-207-112-82-191.tor.primus.ca. [207.112.82.191]) by mx.google.com with ESMTPS id j11sm37198215igc.5.2013.02.12.17.14.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 17:14:21 -0800 (PST) Message-ID: <511AE8E9.1080805@gmail.com> Date: Tue, 12 Feb 2013 20:14:17 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130212-1, 12/02/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 01:14:23 -0000 Remark: I'm not sure the two bullets (quoted further down) tell the full story as they stand. I propose to modify them as follows: 1. Basic Mapping Rule (BMR) - mandatory. There can only be one Basic Mapping Rule per End-user IPv6 prefix. In combination with the End-user IPv6 prefix, the Basic Mapping Rule is used to derive the IPv4 prefix, address, or shared address and the PSID assigned to the CE. 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. The Basic Mapping Rule is also a Forwarding Mapping Rule. Each Forwarding Mapping Rule will result in an entry in the Rules table for the Rule IPv4 prefix. Given a destination IPv4 address and port within the MAP domain, a MAP node can use the matching FMR to derive the End-user IPv6 address of the interface through which that destination address-port combination can be reached. On 12/02/2013 9:22 AM, Ole Troan wrote: > Tom, > >> Thanks. What about the assertions in the bullets? > > sorry, may be my short term memory... what do you mean? > > cheers, > Ole > > >> >> On 12/02/2013 3:27 AM, Ole Troan wrote: >>> Tom, >>> >>>> I'm still hoping to see a response to this. >>>> >>>> On 06/02/2013 8:42 AM, Tom Taylor wrote: >>>>> Section 5 of the latest version of MAP has the following: >>>>> >>>>> 1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 prefix, >>>>> address or port set assignment. There can only be one Basic >>>>> Mapping Rule per End-user IPv6 prefix. The Basic Mapping Rule is >>>>> used to configure the MAP IPv6 address or prefix. >>>>> >>>>> 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. >>>>> The Basic Mapping Rule is also a Forwarding Mapping Rule. Each >>>>> Forwarding Mapping Rule will result in an entry in the Rules >>>>> table for the Rule IPv4 prefix. >>>>> >>>>> Question: there will always be a BMR. In the absence of additional >>>>> rules, how does a CE know whether it can use the BMR for forwarding or >>>>> must always use the default rule? >>> >>> the answer to that is in section 7, last bullet. >>> >>> that is, the MAP CE must be configured to be in hub and spoke mode or mesh mode. >>> which mode it is in decided if the BMR is used for forwarding or not. >>> >>> cheers, >>> Ole >>> >>> > > From cuiyong@tsinghua.edu.cn Tue Feb 12 23:20:13 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6755721F891C for ; Tue, 12 Feb 2013 23:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cibvf1n-8Mv for ; Tue, 12 Feb 2013 23:20:12 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp01.tsinghua.edu.cn [166.111.8.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6478921F8920 for ; Tue, 12 Feb 2013 23:20:11 -0800 (PST) Received: from [124.126.164.68] (helo=[192.168.0.100]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1U5WdV-0003L2-Cp; Wed, 13 Feb 2013 15:20:09 +0800 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 13 Feb 2013 15:20:06 +0800 From: Yong Cui Sender: Yong Cui To: Softwires WG Message-ID: Thread-Topic: Call for agenda in IETF 86 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Yong Cui Subject: [Softwires] Call for agenda in IETF 86 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 07:20:13 -0000 Hi folks, We will have two sessions in the coming IETF meeting in Orlando according to the preliminary agenda: 1) Morning Session on March 11, Monday (2.5h); 2) Morning Session on March 13, Wednesday (2.5h). If you would like to have a time slot, please reply this email and send your request to Suresh and me in the following format by Feb. 21: (name, title, link to IETF datatracker, minutes requested). Thanks, Yong & Suresh From ot@cisco.com Wed Feb 13 00:07:22 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DF821F8A5F for ; Wed, 13 Feb 2013 00:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.915 X-Spam-Level: X-Spam-Status: No, score=-9.915 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG7z5ogGMsn2 for ; Wed, 13 Feb 2013 00:07:21 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCF921F8A69 for ; Wed, 13 Feb 2013 00:07:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2916; q=dns/txt; s=iport; t=1360742841; x=1361952441; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/E0cLJzpomG51QhiekXZL7uegf9SVDKuWHm7+IA1TqQ=; b=ShYE0O5xbknaJZxXU5VTD9qdeQ9Yg3MgIMXccDAgY6cGkQdm8KHSwGHI lrZiSPaT51/b047yEF4D4KKl6dOJne/gcOSXZWhG6tiQvR6f/t3Z+JDbP w0j8c5yznuGKG7lXfzzQ+xkLwBY6ifRnJ/9LoSRVi0aD3eKS+EgP/+UE+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAABIG1GQ/khL/2dsb2JhbABEwG8Wc4IfAQEBAwEBAQE3NAsFCwsYLicwBhOIDAYMv0sEkSJhA5YkkFODBw X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; d="scan'208";a="150431763" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2013 08:07:20 +0000 Received: from dhcp-lys02-vla252-10-147-116-66.cisco.com (dhcp-lys02-vla252-10-147-116-66.cisco.com [10.147.116.66]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1D87JiU024737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2013 08:07:20 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <511AE8E9.1080805@gmail.com> Date: Wed, 13 Feb 2013 09:07:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> <511AE8E9.1080805@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 08:07:22 -0000 I agree with Tom's proposed changes. I'll put them in a upcoming revision 05, if no-one objects. (I still think we can do a WGLC on revision 04). cheers, Ole > Remark: I'm not sure the two bullets (quoted further down) tell the = full story as they stand. I propose to modify them as follows: >=20 > 1. Basic Mapping Rule (BMR) - mandatory. There can only be one > Basic Mapping Rule per End-user IPv6 prefix. In combination > with the End-user IPv6 prefix, the Basic Mapping Rule is used > to derive the IPv4 prefix, address, or shared address and > the PSID assigned to the CE. >=20 > 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. > The Basic Mapping Rule is also a Forwarding Mapping Rule. Each > Forwarding Mapping Rule will result in an entry in the Rules > table for the Rule IPv4 prefix. Given a destination IPv4 = address > and port within the MAP domain, a MAP node can use the matching > FMR to derive the End-user IPv6 address of the interface through > which that destination address-port combination can be reached. >=20 >=20 > On 12/02/2013 9:22 AM, Ole Troan wrote: >> Tom, >>=20 >>> Thanks. What about the assertions in the bullets? >>=20 >> sorry, may be my short term memory... what do you mean? >>=20 >> cheers, >> Ole >>=20 >>=20 >>>=20 >>> On 12/02/2013 3:27 AM, Ole Troan wrote: >>>> Tom, >>>>=20 >>>>> I'm still hoping to see a response to this. >>>>>=20 >>>>> On 06/02/2013 8:42 AM, Tom Taylor wrote: >>>>>> Section 5 of the latest version of MAP has the following: >>>>>>=20 >>>>>> 1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 = prefix, >>>>>> address or port set assignment. There can only be one = Basic >>>>>> Mapping Rule per End-user IPv6 prefix. The Basic Mapping = Rule is >>>>>> used to configure the MAP IPv6 address or prefix. >>>>>>=20 >>>>>> 2. Forwarding Mapping Rule (FMR) - optional, used for = forwarding. >>>>>> The Basic Mapping Rule is also a Forwarding Mapping Rule. = Each >>>>>> Forwarding Mapping Rule will result in an entry in the = Rules >>>>>> table for the Rule IPv4 prefix. >>>>>>=20 >>>>>> Question: there will always be a BMR. In the absence of = additional >>>>>> rules, how does a CE know whether it can use the BMR for = forwarding or >>>>>> must always use the default rule? >>>>=20 >>>> the answer to that is in section 7, last bullet. >>>>=20 >>>> that is, the MAP CE must be configured to be in hub and spoke mode = or mesh mode. >>>> which mode it is in decided if the BMR is used for forwarding or = not. >>>>=20 >>>> cheers, >>>> Ole >>>>=20 >>>>=20 >>=20 >>=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From wdec.ietf@gmail.com Wed Feb 13 02:13:50 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3135D21F8838 for ; Wed, 13 Feb 2013 02:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHjwQY+rQKzb for ; Wed, 13 Feb 2013 02:13:49 -0800 (PST) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3C15921F8820 for ; Wed, 13 Feb 2013 02:13:49 -0800 (PST) Received: by mail-qe0-f41.google.com with SMTP id 7so457367qeb.28 for ; Wed, 13 Feb 2013 02:13:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=eR/aNLLcyzHLwSNwI/wZOQ4ouF0GCLVJxXVW9GEwCyA=; b=da9gOGNN1p3NX6KN9jvybpu/iSgPJk7+CVFy8vzGQLkkriKiDbp2NJgByOsEPTLf9e lCKbAPmbbt1lA5Pf4vjOFouYZq0v3F55TRuVWKkJa9/2EfHSD5dQQSSlhV0tKg/SX0ym JuZUmZvzmEuT1fNjsnaYFwSO/2ifttz5L5Ep3/DCugHN2obP3Fo8yawBD9xbyMBb1q99 d4pwfnxu7ahLE6J5BIqRPt5tym/ReHROp0n9QiRyDZG4XJ3nZgp8MpXoqfvs+K7BZ259 bgJGMMfHmETLHNza4m7ZINerg89VUCvHYRz1J6ZF0rQhpDlX2rFZVLtXvKqf/7gXBW6z wL8g== MIME-Version: 1.0 X-Received: by 10.224.186.83 with SMTP id cr19mr7881912qab.51.1360750428679; Wed, 13 Feb 2013 02:13:48 -0800 (PST) Received: by 10.49.75.33 with HTTP; Wed, 13 Feb 2013 02:13:48 -0800 (PST) In-Reply-To: References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> <511AE8E9.1080805@gmail.com> Date: Wed, 13 Feb 2013 11:13:48 +0100 Message-ID: From: Wojciech Dec To: Ole Troan Content-Type: multipart/alternative; boundary=20cf30363f75edeeea04d598658e Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 10:13:50 -0000 --20cf30363f75edeeea04d598658e Content-Type: text/plain; charset=ISO-8859-1 Fine with that, but can we also go back to calling out the DMR which gives consistency in terms along with BMR and FMR? Thanks, Woj. On 13 February 2013 09:07, Ole Troan wrote: > I agree with Tom's proposed changes. > I'll put them in a upcoming revision 05, if no-one objects. > (I still think we can do a WGLC on revision 04). > > cheers, > Ole > > > > Remark: I'm not sure the two bullets (quoted further down) tell the full > story as they stand. I propose to modify them as follows: > > > > 1. Basic Mapping Rule (BMR) - mandatory. There can only be one > > Basic Mapping Rule per End-user IPv6 prefix. In combination > > with the End-user IPv6 prefix, the Basic Mapping Rule is used > > to derive the IPv4 prefix, address, or shared address and > > the PSID assigned to the CE. > > > > 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. > > The Basic Mapping Rule is also a Forwarding Mapping Rule. Each > > Forwarding Mapping Rule will result in an entry in the Rules > > table for the Rule IPv4 prefix. Given a destination IPv4 address > > and port within the MAP domain, a MAP node can use the matching > > FMR to derive the End-user IPv6 address of the interface through > > which that destination address-port combination can be reached. > > > > > > On 12/02/2013 9:22 AM, Ole Troan wrote: > >> Tom, > >> > >>> Thanks. What about the assertions in the bullets? > >> > >> sorry, may be my short term memory... what do you mean? > >> > >> cheers, > >> Ole > >> > >> > >>> > >>> On 12/02/2013 3:27 AM, Ole Troan wrote: > >>>> Tom, > >>>> > >>>>> I'm still hoping to see a response to this. > >>>>> > >>>>> On 06/02/2013 8:42 AM, Tom Taylor wrote: > >>>>>> Section 5 of the latest version of MAP has the following: > >>>>>> > >>>>>> 1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 prefix, > >>>>>> address or port set assignment. There can only be one Basic > >>>>>> Mapping Rule per End-user IPv6 prefix. The Basic Mapping > Rule is > >>>>>> used to configure the MAP IPv6 address or prefix. > >>>>>> > >>>>>> 2. Forwarding Mapping Rule (FMR) - optional, used for > forwarding. > >>>>>> The Basic Mapping Rule is also a Forwarding Mapping Rule. > Each > >>>>>> Forwarding Mapping Rule will result in an entry in the Rules > >>>>>> table for the Rule IPv4 prefix. > >>>>>> > >>>>>> Question: there will always be a BMR. In the absence of additional > >>>>>> rules, how does a CE know whether it can use the BMR for forwarding > or > >>>>>> must always use the default rule? > >>>> > >>>> the answer to that is in section 7, last bullet. > >>>> > >>>> that is, the MAP CE must be configured to be in hub and spoke mode or > mesh mode. > >>>> which mode it is in decided if the BMR is used for forwarding or not. > >>>> > >>>> cheers, > >>>> Ole > >>>> > >>>> > >> > >> > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf30363f75edeeea04d598658e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fine with that, but can we also go back to calling out the DMR which gives = consistency in terms along with BMR and FMR?

Thanks,
Woj.

=
On 13 February 2013 09:07, Ole Troan <ot@cisco.c= om> wrote:
I agree with Tom's proposed changes.
I'll put them in a upcoming revision 05, if no-one objects.
(I still think we can do a WGLC on revision 04).

cheers,
Ole


> Remark: I'm not sure the two bullets (quoted further down) tell th= e full story as they stand. I propose to modify them as follows:
>
> =A0 1. =A0Basic Mapping Rule (BMR) - mandatory. =A0There can only be o= ne
> =A0 =A0 =A0 Basic Mapping Rule per End-user IPv6 prefix. =A0In combina= tion
> =A0 =A0 =A0 with the End-user IPv6 prefix, the Basic Mapping Rule is u= sed
> =A0 =A0 =A0 to derive the IPv4 prefix, address, or shared address and<= br> > =A0 =A0 =A0 the PSID assigned to the CE.
>
> =A0 2. =A0Forwarding Mapping Rule (FMR) - optional, used for forwardin= g.
> =A0 =A0 =A0 The Basic Mapping Rule is also a Forwarding Mapping Rule. = =A0Each
> =A0 =A0 =A0 Forwarding Mapping Rule will result in an entry in the Rul= es
> =A0 =A0 =A0 table for the Rule IPv4 prefix. =A0Given a destination IPv= 4 address
> =A0 =A0 =A0 and port within the MAP domain, a MAP node can use the mat= ching
> =A0 =A0 =A0 FMR to derive the End-user IPv6 address of the interface t= hrough
> =A0 =A0 =A0 which that destination address-port combination can be rea= ched.
>
>
> On 12/02/2013 9:22 AM, Ole Troan wrote:
>> Tom,
>>
>>> Thanks. What about the assertions in the bullets?
>>
>> sorry, may be my short term memory... what do you mean?
>>
>> cheers,
>> Ole
>>
>>
>>>
>>> On 12/02/2013 3:27 AM, Ole Troan wrote:
>>>> Tom,
>>>>
>>>>> I'm still hoping to see a response to this.
>>>>>
>>>>> On 06/02/2013 8:42 AM, Tom Taylor wrote:
>>>>>> Section 5 of the latest version of MAP has the fol= lowing:
>>>>>>
>>>>>> =A0 =A01. =A0Basic Mapping Rule (BMR) - mandatory,= used for IPv4 prefix,
>>>>>> =A0 =A0 =A0 =A0address or port set assignment. =A0= There can only be one Basic
>>>>>> =A0 =A0 =A0 =A0Mapping Rule per End-user IPv6 pref= ix. =A0The Basic Mapping Rule is
>>>>>> =A0 =A0 =A0 =A0used to configure the MAP IPv6 addr= ess or prefix.
>>>>>>
>>>>>> =A0 =A02. =A0Forwarding Mapping Rule (FMR) - optio= nal, used for forwarding.
>>>>>> =A0 =A0 =A0 =A0The Basic Mapping Rule is also a Fo= rwarding Mapping Rule. =A0Each
>>>>>> =A0 =A0 =A0 =A0Forwarding Mapping Rule will result= in an entry in the Rules
>>>>>> =A0 =A0 =A0 =A0table for the Rule IPv4 prefix.
>>>>>>
>>>>>> Question: there will always be a BMR. In the absen= ce of additional
>>>>>> rules, how does a CE know whether it can use the B= MR for forwarding or
>>>>>> must always use the default rule?
>>>>
>>>> the answer to that is in section 7, last bullet.
>>>>
>>>> that is, the MAP CE must be configured to be in hub and sp= oke mode or mesh mode.
>>>> which mode it is in decided if the BMR is used for forward= ing or not.
>>>>
>>>> cheers,
>>>> Ole
>>>>
>>>>
>>
>>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf30363f75edeeea04d598658e-- From suresh.krishnan@ericsson.com Wed Feb 13 07:20:50 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2AC21F87C3 for ; Wed, 13 Feb 2013 07:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOwIAStaXx+X for ; Wed, 13 Feb 2013 07:20:49 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id C28B921F87C6 for ; Wed, 13 Feb 2013 07:20:47 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-e1-511baf4e6cc5 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 17.40.03705.E4FAB115; Wed, 13 Feb 2013 16:20:47 +0100 (CET) Received: from eusaamw0711.eamcs.ericsson.se (147.117.20.178) by EUSAAHC003.ericsson.se (147.117.188.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 13 Feb 2013 10:20:46 -0500 Received: from [142.133.112.63] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 13 Feb 2013 10:20:46 -0500 Message-ID: <511BAEBB.5050408@ericsson.com> Date: Wed, 13 Feb 2013 10:18:19 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires WG References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyuXRPoK7/eulAg7ebeS0OL9vK5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGsndQqOCVWcbDrB3MDYx9/FyMkhIWAiseTxWxYIW0ziwr31 bF2MXBxCAkcYJRre/WCCcPYwSkz9+J4FwtnGKHF74TawFl4BbYn3nY8ZQWwWAVWJrb0/mUBs NqCxG3Z+BrNFBcIkel+fY4SoF5Q4OfMJWK8IUP2TnQ/YQGxhgQyJ1pm7weqFBHwlHk+4zg5i cwr4STx9/geolwPoPHGJNW84IC6NlPiz8BsziM0soCcx5WoLI4QtL7H97RxmiDGaElvXfGed wCg8C8nmWUhaZiFpWcDIvIqRo7Q4tSw33chwEyMwYI9JsDnuYFzwyfIQozQHi5I4b6jrhQAh gfTEktTs1NSC1KL4otKc1OJDjEwcnFINjDOXdHWXqTHJbrx6Uj84u4upPI5tGstDoSuub9bW 2a/5kWYtedK6L/mX0S4jrzTtpX/mHm17yeT0/S9TxGUjSY3Jtz3fvv/0/AfPHl8fhwuJtjVT ry7/wZpsorq9R+nx4093zG2ZdnIs916w82xlvuVXGZEspbyQiWXs+9QMHy+fKPc1xailVIml OCPRUIu5qDgRAPpO8MkmAgAA Subject: [Softwires] Draft of interest in dhc (Was Fwd: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 15:20:50 -0000 Hi all, I would like to draw your attention to this draft that has been submitted to the dhc working group and has relevance to softwire. Please take a look at the draft and chime in on the dhc mailing list if you have any comments. The draft can be found here http://tools.ietf.org/html/draft-rajtar-dhc-v4configuration-00 Thanks Suresh -------- Original Message -------- Subject: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration Date: Tue, 12 Feb 2013 00:24:13 +0000 From: Ted Lemon To: dhcwg@ietf.org WG At the IETF meeting in Atlanta, we ended the session with a long discussion about how to solve the problem of configuring MAP-E and lw4over6 IPv4 stacks; several possibilities were presented, and we decided that we would write a draft summarizing these possibilities so that the working group could state a preference. Time went on, and none of the people who volunteered actually did anything, so a couple of weeks ago Branimir Rajtar and Ian Farrer offered to write it up based on the notes from the last meeting. They have done so, and submitted a -00 draft: https://datatracker.ietf.org/doc/draft-rajtar-dhc-v4configuration/ The purpose of this draft is to enumerate all the potential solutions to this problem, describe their pros and cons, and make a recommendation. The current state of the draft is the recommendation that most people seemed to be leaning toward at the end of the meeting in Atlanta, but it's not binding; if during discussion the working group decides to recommend something else, the document will be updated to reflect that. If you think the working group should in fact produce this document, please say so on the mailing list. If you think we shouldn't produce such a document, please also say so. If you have comments on the content of the document, please hold off on that until it's been adopted, or not adopted. If it's not adopted, the comments are moot; if it is adopted, the job of the working group will be to finish it according to the input of working group participants, which is where your comments would come in. We will evaluate consensus on February 25. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From mohamed.boucadair@orange.com Wed Feb 13 08:52:05 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E281721F8A89 for ; Wed, 13 Feb 2013 08:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.531 X-Spam-Level: X-Spam-Status: No, score=-1.531 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_LWSHORTT=1.24, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhF-f+pPPRcm for ; Wed, 13 Feb 2013 08:52:05 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2099F21F8A77 for ; Wed, 13 Feb 2013 08:52:02 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id A5BEE22CDA1; Wed, 13 Feb 2013 17:51:58 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8304727C066; Wed, 13 Feb 2013 17:51:58 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 13 Feb 2013 17:51:58 +0100 From: To: Ole Troan , Tom Taylor Date: Wed, 13 Feb 2013 17:51:57 +0100 Thread-Topic: [Softwires] MAP-04: BMR and forwarding rules Thread-Index: Ac4JwSl6CpehxdfWRGiClP6+11pPjgASNDTg Message-ID: <94C682931C08B048B7A8645303FDC9F36EAFB56439@PUEXCB1B.nanterre.francetelecom.fr> References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> <511AE8E9.1080805@gmail.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:52:06 -0000 Hi Ole, all, Before initiating a WGLC for this document, I guess there is a pending disc= ussion point: what to do with MAP1:1 mode.=20 Cheers, Med >-----Message d'origine----- >De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la part de Ole Troan >Envoy=E9 : mercredi 13 f=E9vrier 2013 09:07 >=C0 : Tom Taylor >Cc : Softwires >Objet : Re: [Softwires] MAP-04: BMR and forwarding rules > >I agree with Tom's proposed changes. >I'll put them in a upcoming revision 05, if no-one objects. >(I still think we can do a WGLC on revision 04). > >cheers, >Ole > > >> Remark: I'm not sure the two bullets (quoted further down)=20 >tell the full story as they stand. I propose to modify them as follows: >>=20 >> 1. Basic Mapping Rule (BMR) - mandatory. There can only be one >> Basic Mapping Rule per End-user IPv6 prefix. In combination >> with the End-user IPv6 prefix, the Basic Mapping Rule is used >> to derive the IPv4 prefix, address, or shared address and >> the PSID assigned to the CE. >>=20 >> 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. >> The Basic Mapping Rule is also a Forwarding Mapping Rule. Each >> Forwarding Mapping Rule will result in an entry in the Rules >> table for the Rule IPv4 prefix. Given a destination=20 >IPv4 address >> and port within the MAP domain, a MAP node can use the matching >> FMR to derive the End-user IPv6 address of the=20 >interface through >> which that destination address-port combination can be reached. >>=20 >>=20 >> On 12/02/2013 9:22 AM, Ole Troan wrote: >>> Tom, >>>=20 >>>> Thanks. What about the assertions in the bullets? >>>=20 >>> sorry, may be my short term memory... what do you mean? >>>=20 >>> cheers, >>> Ole >>>=20 >>>=20 >>>>=20 >>>> On 12/02/2013 3:27 AM, Ole Troan wrote: >>>>> Tom, >>>>>=20 >>>>>> I'm still hoping to see a response to this. >>>>>>=20 >>>>>> On 06/02/2013 8:42 AM, Tom Taylor wrote: >>>>>>> Section 5 of the latest version of MAP has the following: >>>>>>>=20 >>>>>>> 1. Basic Mapping Rule (BMR) - mandatory, used for=20 >IPv4 prefix, >>>>>>> address or port set assignment. There can only=20 >be one Basic >>>>>>> Mapping Rule per End-user IPv6 prefix. The=20 >Basic Mapping Rule is >>>>>>> used to configure the MAP IPv6 address or prefix. >>>>>>>=20 >>>>>>> 2. Forwarding Mapping Rule (FMR) - optional, used=20 >for forwarding. >>>>>>> The Basic Mapping Rule is also a Forwarding=20 >Mapping Rule. Each >>>>>>> Forwarding Mapping Rule will result in an entry=20 >in the Rules >>>>>>> table for the Rule IPv4 prefix. >>>>>>>=20 >>>>>>> Question: there will always be a BMR. In the absence of=20 >additional >>>>>>> rules, how does a CE know whether it can use the BMR=20 >for forwarding or >>>>>>> must always use the default rule? >>>>>=20 >>>>> the answer to that is in section 7, last bullet. >>>>>=20 >>>>> that is, the MAP CE must be configured to be in hub and=20 >spoke mode or mesh mode. >>>>> which mode it is in decided if the BMR is used for=20 >forwarding or not. >>>>>=20 >>>>> cheers, >>>>> Ole >>>>>=20 >>>>>=20 >>>=20 >>>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires >= From tom.taylor.stds@gmail.com Wed Feb 13 09:20:49 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9662D21F8941 for ; Wed, 13 Feb 2013 09:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.358 X-Spam-Level: X-Spam-Status: No, score=0.358 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0pe0OAFjuNr for ; Wed, 13 Feb 2013 09:20:48 -0800 (PST) Received: from mail-ie0-x22f.google.com (ie-in-x022f.1e100.net [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC0321F8939 for ; Wed, 13 Feb 2013 09:20:34 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id c12so2032636ieb.34 for ; Wed, 13 Feb 2013 09:20:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=LlEX4LIg5pIXZTzuUhzWpevDdJhcIZU2Gkb+86YXZ1I=; b=vAy2+7e47fxmUq4ytTz15pb4CohHiqignlcmyE8TIM5/C+WCsV0QILOdOzpe/TYyFC XAN3gxmvt2GopyyvKs0EX6Y5UDpFz/uEXDY80O8uZQOlq10YFWBd1Gj7hEIVpuBrNXy3 tYJbJ7RlAVPzSnAjjCuNw+eoL6Yl9NS62XoEo5i8TMCmPF6yEuS3ynuscGZpCKNPJl5f L5R3PJY0XI4yLLS7/z3Hfh+X1aAdDHazxHx2r+ynEQEFrsJPMekc16Pg4QNu6bEIKkfy rb9PmAcVmxZqXuAfTBb2DjqLOH3SkB5KIleX3lr/J9ZEK+2fyL/WpqxJLvpj8fMhSVTy cuKw== X-Received: by 10.50.178.10 with SMTP id cu10mr12520833igc.75.1360776033750; Wed, 13 Feb 2013 09:20:33 -0800 (PST) Received: from [127.0.0.1] (dsl-207-112-82-191.tor.primus.ca. [207.112.82.191]) by mx.google.com with ESMTPS id px5sm38168840igc.0.2013.02.13.09.20.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 09:20:33 -0800 (PST) Message-ID: <511BCB5F.9070005@gmail.com> Date: Wed, 13 Feb 2013 12:20:31 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan References: <20130206093949.4851.76943.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130213-0, 13/02/2013), Outbound message X-Antivirus-Status: Clean Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-04.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:20:50 -0000 Fixing port offset to 4 rather than 6 means that an operator needs about 6% more public IPv4 addresses to serve the same population. I'm not sure of the cost tradeoff, but what % of BR capacity is likely to be lost if the PSID does not sit on a nibble boundary? Tom On 06/02/2013 4:48 AM, Ole Troan wrote: > with this update to the MAP-E revision: > - reorganized the architecture section to make it cleared what applies to shared addresses vs full ipv4 / prefix > - fixed port offset to 4 (removed port parameters from the base spec) > - simplified the interface-id text, removed 6052 reference > ... From ot@cisco.com Wed Feb 13 10:23:15 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1318021F865D for ; Wed, 13 Feb 2013 10:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.895 X-Spam-Level: X-Spam-Status: No, score=-9.895 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4x1gV6a4ZrSu for ; Wed, 13 Feb 2013 10:23:14 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id A2D5121F8644 for ; Wed, 13 Feb 2013 10:23:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3973; q=dns/txt; s=iport; t=1360779793; x=1361989393; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=917DQtoKX0atrqjFGAyj4FoOjQkJ2k8OYO6r2DQgE28=; b=OIEh5Vgq8ktcGs/vnZf8Qb1nt16UkXO5VMsNV+nOXZ+sy8LdDu0CxthU LLhhgd8lbZ3GkAquH3uNZF0RhhwY7wOxi2r9odr5/EqhDZn6DhZmjjXEr GEzgL153Jhhbg9qGh+ou5tJmxGk1/LG9kVNZOQ2uu60sZQLCnNuCk4Evx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIDZG1GQ/khM/2dsb2JhbABFwG4Wc4IfAQEBAwEBAQFrCwULCxgnBycfEQYTiAwGDL8cBJEjYQOWJJBTgwc X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; d="scan'208";a="11773356" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 13 Feb 2013 18:23:12 +0000 Received: from dhcp-10-61-102-175.cisco.com (dhcp-10-61-102-175.cisco.com [10.61.102.175]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1DINBQS011796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2013 18:23:12 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EAFB56439@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 13 Feb 2013 19:23:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> <511AE8E9.1080805@gmail.com> <94C682931C08B048B7A8645303FDC9F36EAFB56439@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 18:23:15 -0000 Med, > Before initiating a WGLC for this document, I guess there is a pending = discussion point: what to do with MAP1:1 mode.=20 do we really...? :-) if you have changes to propose to the document, can you suggest text? cheers, Ole >> -----Message d'origine----- >> De : softwires-bounces@ietf.org=20 >> [mailto:softwires-bounces@ietf.org] De la part de Ole Troan >> Envoy=E9 : mercredi 13 f=E9vrier 2013 09:07 >> =C0 : Tom Taylor >> Cc : Softwires >> Objet : Re: [Softwires] MAP-04: BMR and forwarding rules >>=20 >> I agree with Tom's proposed changes. >> I'll put them in a upcoming revision 05, if no-one objects. >> (I still think we can do a WGLC on revision 04). >>=20 >> cheers, >> Ole >>=20 >>=20 >>> Remark: I'm not sure the two bullets (quoted further down)=20 >> tell the full story as they stand. I propose to modify them as = follows: >>>=20 >>> 1. Basic Mapping Rule (BMR) - mandatory. There can only be one >>> Basic Mapping Rule per End-user IPv6 prefix. In combination >>> with the End-user IPv6 prefix, the Basic Mapping Rule is used >>> to derive the IPv4 prefix, address, or shared address and >>> the PSID assigned to the CE. >>>=20 >>> 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. >>> The Basic Mapping Rule is also a Forwarding Mapping Rule. Each >>> Forwarding Mapping Rule will result in an entry in the Rules >>> table for the Rule IPv4 prefix. Given a destination=20 >> IPv4 address >>> and port within the MAP domain, a MAP node can use the matching >>> FMR to derive the End-user IPv6 address of the=20 >> interface through >>> which that destination address-port combination can be reached. >>>=20 >>>=20 >>> On 12/02/2013 9:22 AM, Ole Troan wrote: >>>> Tom, >>>>=20 >>>>> Thanks. What about the assertions in the bullets? >>>>=20 >>>> sorry, may be my short term memory... what do you mean? >>>>=20 >>>> cheers, >>>> Ole >>>>=20 >>>>=20 >>>>>=20 >>>>> On 12/02/2013 3:27 AM, Ole Troan wrote: >>>>>> Tom, >>>>>>=20 >>>>>>> I'm still hoping to see a response to this. >>>>>>>=20 >>>>>>> On 06/02/2013 8:42 AM, Tom Taylor wrote: >>>>>>>> Section 5 of the latest version of MAP has the following: >>>>>>>>=20 >>>>>>>> 1. Basic Mapping Rule (BMR) - mandatory, used for=20 >> IPv4 prefix, >>>>>>>> address or port set assignment. There can only=20 >> be one Basic >>>>>>>> Mapping Rule per End-user IPv6 prefix. The=20 >> Basic Mapping Rule is >>>>>>>> used to configure the MAP IPv6 address or prefix. >>>>>>>>=20 >>>>>>>> 2. Forwarding Mapping Rule (FMR) - optional, used=20 >> for forwarding. >>>>>>>> The Basic Mapping Rule is also a Forwarding=20 >> Mapping Rule. Each >>>>>>>> Forwarding Mapping Rule will result in an entry=20 >> in the Rules >>>>>>>> table for the Rule IPv4 prefix. >>>>>>>>=20 >>>>>>>> Question: there will always be a BMR. In the absence of=20 >> additional >>>>>>>> rules, how does a CE know whether it can use the BMR=20 >> for forwarding or >>>>>>>> must always use the default rule? >>>>>>=20 >>>>>> the answer to that is in section 7, last bullet. >>>>>>=20 >>>>>> that is, the MAP CE must be configured to be in hub and=20 >> spoke mode or mesh mode. >>>>>> which mode it is in decided if the BMR is used for=20 >> forwarding or not. >>>>>>=20 >>>>>> cheers, >>>>>> Ole >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From suresh.krishnan@ericsson.com Wed Feb 13 13:40:37 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA8D21F874C for ; Wed, 13 Feb 2013 13:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.231 X-Spam-Level: X-Spam-Status: No, score=-102.231 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHKofI+iUqzO for ; Wed, 13 Feb 2013 13:40:36 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 69A2921F857C for ; Wed, 13 Feb 2013 13:40:36 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-b8-511c085395d3 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 40.76.03705.3580C115; Wed, 13 Feb 2013 22:40:36 +0100 (CET) Received: from eusaamw0711.eamcs.ericsson.se (147.117.20.178) by EUSAAHC003.ericsson.se (147.117.188.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 13 Feb 2013 16:40:34 -0500 Received: from [142.133.112.63] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 13 Feb 2013 16:40:33 -0500 Message-ID: <511C07BE.9030204@ericsson.com> Date: Wed, 13 Feb 2013 16:38:06 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> <511AE8E9.1080805@gmail.com> <94C682931C08B048B7A8645303FDC9F36EAFB56439@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EAFB56439@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyuXRPoG4Ih0ygQeNXRovDb5+yW6zYtZ7V 4vCyrUwWF9b/YnFg8ZjyeyOrx85Zd9k9liz5yeTR8uwkWwBLFJdNSmpOZllqkb5dAlfGrAOb 2ApmMVfcu9XF2MC4l6mLkZNDQsBEYvqMJmYIW0ziwr31bF2MXBxCAkcYJf7MOwxWJCSwh1Fi 0iENiMQ2RolNl2aAJXgFtCU+9F1mBLFZBFQlmvbMZgOx2YCmbtj5GaxGVCBMovf1OUaIekGJ kzOfsIDYIgJKEhv2PmIHsZkF0iQev9kH1MvBISxgKbHgujjErkdMEouXnAGr4RSIkZjyso0V pEZCQFxizRsOiFY9iSlXWxghbHmJ7W/nMEPcrCmxdc131gmMwrOQbJ6FpGUWkpYFjMyrGDlK i1PLctONDDcxAoP9mASb4w7GBZ8sDzFKc7AoifOGul4IEBJITyxJzU5NLUgtii8qzUktPsTI xMEp1cA4deX3CXXuBn1TVNy+Je8sY1gj7vcsX9SnaXqbTIre/9yJf07Nt9XM/B7MvT3heFX5 Rc7txVF5betW63txsVa+b1/3nFVB60KNzGKtbfrHZT9Pqw2QP+H6+PIam9+StUtsym9YNS1b 9nH/1EObtMq0Bc4IMXwxmGAz/4uu9gy2TRduvFrwfuZ8JZbijERDLeai4kQArNgGDEQCAAA= Cc: Softwires , Ole Troan Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 21:40:37 -0000 Med, On 02/13/2013 11:51 AM, mohamed.boucadair@orange.com wrote: > Hi Ole, all, > > Before initiating a WGLC for this document, I guess there is a pending discussion point: what to do with MAP1:1 mode. Can you open an issue in the tracker for this please. We can try to discuss this on the list to converge on a decision, failing which we can take it up during the meeting. Thanks Suresh From ot@cisco.com Wed Feb 13 13:48:19 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC2A11E80A3 for ; Wed, 13 Feb 2013 13:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.492 X-Spam-Level: X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hl0zQqhLSVjl for ; Wed, 13 Feb 2013 13:48:19 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C030F21F8484 for ; Wed, 13 Feb 2013 13:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=491; q=dns/txt; s=iport; t=1360792099; x=1362001699; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zOLIVI/iHT6SI8JPIHuuTTWEzD6tKrMcoX5QW30qIyU=; b=ksuTef4L36h3b28OnWS7SUlv1bvoimT3997VU2Qi30efRn9USegIDv2b YQbOvkSEXq7R+f81dNfiQ/O0/4pTNiwKHleo9yBzWgRSkN3Od1uqxYFPE X0vOwO5mVFySwVgW9gWrF0vjx6cNzj7z4RyjvVQgVztDbJkI+tsptgFzS 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAF0IHFGQ/khM/2dsb2JhbABFwG8Wc4IfAQEBAwE6PxALRlcGiB8Gv1WRI2EDliSQU4MH X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; d="scan'208";a="150456748" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2013 21:48:17 +0000 Received: from dhcp-10-61-110-156.cisco.com (dhcp-10-61-110-156.cisco.com [10.61.110.156]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1DLmHZW009275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2013 21:48:17 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <511C07BE.9030204@ericsson.com> Date: Wed, 13 Feb 2013 22:48:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> <511AE8E9.1080805@gmail.com> <94C682931C08B048B7A8645303FDC9F36EAFB56439@PUEXCB1B.nanterre.francetelecom.fr> <511C07BE.9030204@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 21:48:19 -0000 >> Before initiating a WGLC for this document, I guess there is a = pending discussion point: what to do with MAP1:1 mode.=20 >=20 > Can you open an issue in the tracker for this please. We can try to > discuss this on the list to converge on a decision, failing which we = can > take it up during the meeting. in the context of the MAP-E draft I have to admit that I don't = understand what the issue is, nor what there is to discuss. could someone fill me in? cheers, Ole= From tom.taylor.stds@gmail.com Wed Feb 13 14:57:37 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE9B21E809B for ; Wed, 13 Feb 2013 14:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=2.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPkV3dMwL0Gp for ; Wed, 13 Feb 2013 14:57:37 -0800 (PST) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2E121E8045 for ; Wed, 13 Feb 2013 14:57:37 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id 6so796830qea.24 for ; Wed, 13 Feb 2013 14:57:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=bLFuSwi0JP6PwnNKPJa3lTHx5Rmt9Mdqw8KLVGjXPSE=; b=gggFfp1SWLTLmVmWOc/HgA78oMlYQ5z2aMvhghQA9ekq5pcpqSjeLgsd1iyCu0n2nQ JGkauK1Oa2RWNOLmgGhFQALYHMIhXzgHNbYrLXlLWT5EaCxGceqynXyqpMhu8TdA0mdy wiu7/SrgiM7ZGfRpsLIjRJPfBfTOhlWlFv51emxgPkuqM43nBB3KwsxLYR1U+0SqTIKG 3dAK7BEOL9tiqmJw68LK0F5QM407FWWnOw0LNLm1QI7A7Kao1+AQL+9+6Mn+m2UBxlmw +p9H8Y+yt4wgWPs9E8XwN3ytIIyyPWJ8ANzXp0VIyAf8oKvQHGtog0ADXegDAZX/mkW0 82xg== X-Received: by 10.224.18.205 with SMTP id x13mr9314783qaa.9.1360796245501; Wed, 13 Feb 2013 14:57:25 -0800 (PST) Received: from [127.0.0.1] (dsl-207-112-82-191.tor.primus.ca. [207.112.82.191]) by mx.google.com with ESMTPS id bp7sm17014104igb.4.2013.02.13.14.57.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 14:57:24 -0800 (PST) Message-ID: <511C1A52.9050103@gmail.com> Date: Wed, 13 Feb 2013 17:57:22 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> <511AE8E9.1080805@gmail.com> <94C682931C08B048B7A8645303FDC9F36EAFB56439@PUEXCB1B.nanterre.francetelecom.fr> <511C07BE.9030204@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130213-2, 13/02/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 22:57:38 -0000 I know that my own feeling is that MAP-E as currently described has a split personality. On the one hand, there are those algorithms in support of address sharing. On the other hand, there is provision for doing without the algorithms (especially when o=0), in which case ordinary provisioning processes would be sufficient. I think we can all agree that during IPv6 transition operators need both address sharing and the ability to provide full IPv4 addresses. The question is whether it is necessary to combine both in this specification. The one justification I could see would be to provide the associated forwarding rules to CEs with shared addresses in the full mesh case. Is there another justification? Tom On 13/02/2013 4:48 PM, Ole Troan wrote: >>> Before initiating a WGLC for this document, I guess there is a pending discussion point: what to do with MAP1:1 mode. >> >> Can you open an issue in the tracker for this please. We can try to >> discuss this on the list to converge on a decision, failing which we can >> take it up during the meeting. > > in the context of the MAP-E draft I have to admit that I don't understand what the issue is, nor what there is to discuss. > could someone fill me in? > > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From ot@cisco.com Thu Feb 14 00:27:20 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61ABD21F8415 for ; Thu, 14 Feb 2013 00:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.962 X-Spam-Level: X-Spam-Status: No, score=-9.962 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaqaKVpi3EW5 for ; Thu, 14 Feb 2013 00:27:19 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7E94521F8433 for ; Thu, 14 Feb 2013 00:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=866; q=dns/txt; s=iport; t=1360830439; x=1362040039; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=PBZUv8UfURU3aL2Wf/zodEdJ/uGaxCh4EAZW/K0P5/8=; b=l7JkykCL4DD1v3JnscL5CyOZdrgZ+JDbgBxRNMedZyQGgmoEMYv9A04I in5A2P/B8YLAveOMGGaPgh79mlUrQQFQVbDHYzxupwQUD3x3UEvKrw17c XlWQcL1XrbNpB3GanbIRcnBoYltSvYwPGiY/tbQYBErFwLjJoZ8H7TNbs c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEKAGCfHFGQ/khR/2dsb2JhbABEJ8BHFnOCHwEBAQMBOj8FCwtGVwaIHwbAP5EjYQOWJJBTgwc X-IronPort-AV: E=Sophos;i="4.84,662,1355097600"; d="scan'208";a="150470788" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2013 08:27:18 +0000 Received: from dhcp-lys01-vla250-10-147-112-170.cisco.com (dhcp-lys01-vla250-10-147-112-170.cisco.com [10.147.112.170]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1E8RHmX000746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Feb 2013 08:27:18 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <511C1A52.9050103@gmail.com> Date: Thu, 14 Feb 2013 00:17:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9381104A-259C-47DC-9B3B-F3401D1CA309@cisco.com> References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> <511AE8E9.1080805@gmail.com> <94C682931C08B048B7A8645303FDC9F36EAFB56439@PUEXCB1B.nanterre.francetelecom.fr> <511C07BE.9030204@ericsson.com> <511C1A52.9050103@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 08:27:20 -0000 > I know that my own feeling is that MAP-E as currently described has a = split personality. On the one hand, there are those algorithms in = support of address sharing. On the other hand, there is provision for = doing without the algorithms (especially when o=3D0), in which case = ordinary provisioning processes would be sufficient. >=20 > I think we can all agree that during IPv6 transition operators need = both address sharing and the ability to provide full IPv4 addresses. The = question is whether it is necessary to combine both in this = specification. The one justification I could see would be to provide the = associated forwarding rules to CEs with shared addresses in the full = mesh case. Is there another justification? MAP-E is a generic tool. how an operator choose to use mapping rules is a deployment choice. cheers, Ole= From ot@cisco.com Thu Feb 14 02:14:42 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834AC21F845F for ; Thu, 14 Feb 2013 02:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEzZ5Ti9KCTJ for ; Thu, 14 Feb 2013 02:14:42 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B65AC21F8481 for ; Thu, 14 Feb 2013 02:14:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1597; q=dns/txt; s=iport; t=1360836881; x=1362046481; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=uN/2J9mqigtWC+AncPThh6h36WuO8HrDvdLzP6vs1fo=; b=GJIMUW7P3jkpd7g7twzy25EhUfOd2bRDFnz7AeE3gdPnlk01XhgnKMxT dEa2nusBd/f9Sey6r/ZmqQu9in99I95msce+IObkbkTE25OeN4BsvLNk4 cB5WQHZqYjh9W4b/BvHd2xZSK0JX3G1AjnahUj+6CZIv3msqEFhr4/9Tu I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKa4HFGQ/khN/2dsb2JhbABEwGkWc4IfAQEBAwE6NAsQC0ZXGYgMBgzAOo1UgQaCSWEDliSBHYomhRCDCA X-IronPort-AV: E=Sophos;i="4.84,664,1355097600"; d="scan'208";a="80451709" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 14 Feb 2013 10:14:26 +0000 Received: from dhcp-lys01-vla250-10-147-112-170.cisco.com (dhcp-lys01-vla250-10-147-112-170.cisco.com [10.147.112.170]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1EAEQIN024299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Feb 2013 10:14:26 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <071.e0df54c8f0f2d697ebf7688240481b71@tools.ietf.org> Date: Thu, 14 Feb 2013 11:14:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4BF4806A-D597-43E7-8A60-11FC4EE0F909@cisco.com> References: <071.e0df54c8f0f2d697ebf7688240481b71@tools.ietf.org> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1499) Cc: softwires@ietf.org, draft-ietf-softwire-map@tools.ietf.org Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 10:14:42 -0000 > #25: Maintain or remove MAP1:1 Mode? OK, so here is a task for whomever thinks MAP 1:1 mode should be = removed. - what does "remove MAP 1:1 mode mean"? - please suggest text changes to the mechanism that removes 1:1 mode. given that my opinion is that 1:1 mode is an unremovable part of MAP, = the question just doesn't make sense to me. I don't want this issue to be an excuse to block a last call, can we = quickly resolve this, and can we agree to drop it if there are no = significant contributions within the next week? cheers, Ole >=20 > The WG discussed several times this point (refer to the mailing list > archives). >=20 > MAP1:1 mode is a particular mode which may re-use some of the = provisioning > methods defined for MAP. >=20 > MAP1:1 vs. Lw4o6: > * MAP1:1 is not fully stateless. > * Lw4o6 is a standalone specification which provides the same service = as > MAP1:1. >=20 > --=20 > = -------------------------------------+------------------------------------= - > Reporter: | Owner: = draft-ietf-softwire- > mohamed.boucadair@orange.com | map@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: map-e | Version: > Severity: - | Keywords: > = -------------------------------------+------------------------------------= - >=20 > Ticket URL: > softwire >=20 From mohamed.boucadair@orange.com Thu Feb 14 02:55:34 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC90521F85E0 for ; Thu, 14 Feb 2013 02:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYcoRfI-DuY4 for ; Thu, 14 Feb 2013 02:55:33 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA3121F8522 for ; Thu, 14 Feb 2013 02:55:33 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id AD6632DC33D; Thu, 14 Feb 2013 11:55:32 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 8FA6A4C017; Thu, 14 Feb 2013 11:55:32 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 14 Feb 2013 11:55:32 +0100 From: To: Ole Troan Date: Thu, 14 Feb 2013 11:55:31 +0100 Thread-Topic: [softwire] #25: Maintain or remove MAP1:1 Mode? Thread-Index: Ac4KnBpZLZNduhhNRmy/PblQzXVkZAAAUhxg Message-ID: <94C682931C08B048B7A8645303FDC9F36EAFB566A7@PUEXCB1B.nanterre.francetelecom.fr> References: <071.e0df54c8f0f2d697ebf7688240481b71@tools.ietf.org> <4BF4806A-D597-43E7-8A60-11FC4EE0F909@cisco.com> In-Reply-To: <4BF4806A-D597-43E7-8A60-11FC4EE0F909@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "softwires@ietf.org" , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 10:55:34 -0000 Hi Ole, To start with, there was no consensus to include MAP1:1 in the MAP spec. Un= less I'm mistaken, objection to include that mode in the base MAP spec was = raised several times in the mailing list. It was mainly raised by authors o= f Lw4o6 but they are also contributors to softwire. As an editor of this document, with all due respect, you should ask the opi= nion of the WG before recording the consensus into the document. The WG own= s this document and it can decide what to put on it. I'm personally in favour of removing MAP1:1 section from this document as t= his mode can not be packaged as stateless. But, this is only my opinion.=20 Cheers, Med >-----Message d'origine----- >De : Ole Troan [mailto:ot@cisco.com]=20 >Envoy=E9 : jeudi 14 f=E9vrier 2013 11:14 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : draft-ietf-softwire-map@tools.ietf.org; softwires@ietf.org >Objet : Re: [softwire] #25: Maintain or remove MAP1:1 Mode? > >> #25: Maintain or remove MAP1:1 Mode? > >OK, so here is a task for whomever thinks MAP 1:1 mode should=20 >be removed. > >- what does "remove MAP 1:1 mode mean"? >- please suggest text changes to the mechanism that removes 1:1 mode. > >given that my opinion is that 1:1 mode is an unremovable part=20 >of MAP, the question just doesn't make sense to me. > >I don't want this issue to be an excuse to block a last call,=20 >can we quickly resolve this, and can we agree to drop it if=20 >there are no significant contributions within the next week? > >cheers, >Ole > > >>=20 >> The WG discussed several times this point (refer to the mailing list >> archives). >>=20 >> MAP1:1 mode is a particular mode which may re-use some of=20 >the provisioning >> methods defined for MAP. >>=20 >> MAP1:1 vs. Lw4o6: >> * MAP1:1 is not fully stateless. >> * Lw4o6 is a standalone specification which provides the=20 >same service as >> MAP1:1. >>=20 >> --=20 >>=20 >-------------------------------------+------------------------- >------------ >> Reporter: | Owner: =20 >draft-ietf-softwire- >> mohamed.boucadair@orange.com | map@tools.ietf.org >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: map-e | Version: >> Severity: - | Keywords: >>=20 >-------------------------------------+------------------------- >------------ >>=20 >> Ticket URL: >> softwire >>=20 > >= From ot@cisco.com Thu Feb 14 03:12:20 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968C521F85A2 for ; Thu, 14 Feb 2013 03:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyUVtYdOhcns for ; Thu, 14 Feb 2013 03:12:19 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 95BB721F8518 for ; Thu, 14 Feb 2013 03:12:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2987; q=dns/txt; s=iport; t=1360840340; x=1362049940; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6w41H0JUG3bPhgWVKLcV3OPLInsaykxa9OHIKONXyGc=; b=WoVTESugMtgpribdsKccxRCjOKrMf95Rp6+IjsGaKYpiEDRLT6mxWHCn 9gKOraxRxQ1+0OJf5jt5ydxe8sURvjsNEsCQNzu1ZWttcyTgG+28VzLxZ LZFBn8TM0FxUrz+u6NymW5kMffYeGNCVe0S9LZEYqpingk7AO90uJYiPj k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALTFHFGQ/khR/2dsb2JhbABEwGoWc4IfAQEBAwFuCwULCz8HRhEGE4gMBgy/ZY1UgQaCSWEDliSBHYomhRCDCA X-IronPort-AV: E=Sophos;i="4.84,664,1355097600"; d="scan'208";a="150477671" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2013 11:12:18 +0000 Received: from dhcp-lys01-vla250-10-147-112-170.cisco.com (dhcp-lys01-vla250-10-147-112-170.cisco.com [10.147.112.170]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1EBCHiY032410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Feb 2013 11:12:18 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EAFB566A7@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 14 Feb 2013 12:12:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <071.e0df54c8f0f2d697ebf7688240481b71@tools.ietf.org> <4BF4806A-D597-43E7-8A60-11FC4EE0F909@cisco.com> <94C682931C08B048B7A8645303FDC9F36EAFB566A7@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org" , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 11:12:20 -0000 Med, > To start with, there was no consensus to include MAP1:1 in the MAP = spec. Unless I'm mistaken, objection to include that mode in the base = MAP spec was raised several times in the mailing list. It was mainly = raised by authors of Lw4o6 but they are also contributors to softwire. >=20 > As an editor of this document, with all due respect, you should ask = the opinion of the WG before recording the consensus into the document. = The WG owns this document and it can decide what to put on it. >=20 > I'm personally in favour of removing MAP1:1 section from this document = as this mode can not be packaged as stateless. But, this is only my = opinion.=20 you didn't answer my question. 1:1 mode has always been part of MAP. are we arguing over whether we = should explicitly mention that fact in the MAP draft. or are we arguing over making it technically impossible to do MAP 1:1 = mode? cheers, Ole >> -----Message d'origine----- >> De : Ole Troan [mailto:ot@cisco.com]=20 >> Envoy=E9 : jeudi 14 f=E9vrier 2013 11:14 >> =C0 : BOUCADAIR Mohamed OLNC/OLN >> Cc : draft-ietf-softwire-map@tools.ietf.org; softwires@ietf.org >> Objet : Re: [softwire] #25: Maintain or remove MAP1:1 Mode? >>=20 >>> #25: Maintain or remove MAP1:1 Mode? >>=20 >> OK, so here is a task for whomever thinks MAP 1:1 mode should=20 >> be removed. >>=20 >> - what does "remove MAP 1:1 mode mean"? >> - please suggest text changes to the mechanism that removes 1:1 mode. >>=20 >> given that my opinion is that 1:1 mode is an unremovable part=20 >> of MAP, the question just doesn't make sense to me. >>=20 >> I don't want this issue to be an excuse to block a last call,=20 >> can we quickly resolve this, and can we agree to drop it if=20 >> there are no significant contributions within the next week? >>=20 >> cheers, >> Ole >>=20 >>=20 >>>=20 >>> The WG discussed several times this point (refer to the mailing list >>> archives). >>>=20 >>> MAP1:1 mode is a particular mode which may re-use some of=20 >> the provisioning >>> methods defined for MAP. >>>=20 >>> MAP1:1 vs. Lw4o6: >>> * MAP1:1 is not fully stateless. >>> * Lw4o6 is a standalone specification which provides the=20 >> same service as >>> MAP1:1. >>>=20 >>> --=20 >>>=20 >> -------------------------------------+------------------------- >> ------------ >>> Reporter: | Owner: =20 >> draft-ietf-softwire- >>> mohamed.boucadair@orange.com | map@tools.ietf.org >>> Type: defect | Status: new >>> Priority: major | Milestone: >>> Component: map-e | Version: >>> Severity: - | Keywords: >>>=20 >> -------------------------------------+------------------------- >> ------------ >>>=20 >>> Ticket URL: >>> softwire >>>=20 >>=20 From despres.remi@laposte.net Thu Feb 14 07:15:51 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A45221F870A for ; Thu, 14 Feb 2013 07:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuO0XGk56fAT for ; Thu, 14 Feb 2013 07:15:51 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id EC05A21F868D for ; Thu, 14 Feb 2013 07:15:48 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2306.sfr.fr (SMTP Server) with ESMTP id D9B9E700014D; Thu, 14 Feb 2013 16:15:42 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2306.sfr.fr (SMTP Server) with ESMTP id 56E2B7000074; Thu, 14 Feb 2013 16:15:42 +0100 (CET) X-SFR-UUID: 20130214151542355.56E2B7000074@msfrf2306.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 14 Feb 2013 16:15:41 +0100 Message-Id: References: <071.e0df54c8f0f2d697ebf7688240481b71@tools.ietf.org> <4BF4806A-D597-43E7-8A60-11FC4EE0F909@cisco.com> <94C682931C08B048B7A8645303FDC9F36EAFB566A7@PUEXCB1B.nanterre.francetelecom.fr> To: Ole Troan X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 15:15:51 -0000 2013-02-14 12:12, Ole Troan : > Med, >=20 >> To start with, there was no consensus to include MAP1:1 in the MAP = spec. Unless I'm mistaken, objection to include that mode in the base = MAP spec was raised several times in the mailing list. It was mainly = raised by authors of Lw4o6 but they are also contributors to softwire. >>=20 >> As an editor of this document, with all due respect, you should ask = the opinion of the WG before recording the consensus into the document. = The WG owns this document and it can decide what to put on it. >>=20 >> I'm personally in favour of removing MAP1:1 section from this = document as this mode can not be packaged as stateless. But, this is = only my opinion.=20 >=20 > you didn't answer my question. > 1:1 mode has always been part of MAP. Untrue: - Initially, the MAP draft was limited to stateless, WITHOUT any = reference to 1:1 (October 2011 to January 2012, ref = http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-00 = to -03) - It is only when the MAP draft had to be re-issued a WG document that, = without previous discussion in the WG, applicability to 1:1 was added by = its editor(s) (June 2012). - When MAP became restricted to MAP-E, as per WG decision, applicability = to 1:1 has been kept despite the lack of WG consensus (September 2012). > are we arguing over whether we should explicitly mention that fact in = the MAP draft. > or are we arguing over making it technically impossible to do MAP 1:1 = mode? Suggested way to solve the problem:=20 - Delete section 7.4 (whose ONLY purpose is to introduce 1:1 = applicability). - In Appendix A, delete examples 4 and 5 (ONLY devoted to 1:1 mappings). = =20 RD >=20 > cheers, > Ole >=20 >>> -----Message d'origine----- >>> De : Ole Troan [mailto:ot@cisco.com]=20 >>> Envoy=E9 : jeudi 14 f=E9vrier 2013 11:14 >>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>> Cc : draft-ietf-softwire-map@tools.ietf.org; softwires@ietf.org >>> Objet : Re: [softwire] #25: Maintain or remove MAP1:1 Mode? >>>=20 >>>> #25: Maintain or remove MAP1:1 Mode? >>>=20 >>> OK, so here is a task for whomever thinks MAP 1:1 mode should=20 >>> be removed. >>>=20 >>> - what does "remove MAP 1:1 mode mean"? >>> - please suggest text changes to the mechanism that removes 1:1 = mode. >>>=20 >>> given that my opinion is that 1:1 mode is an unremovable part=20 >>> of MAP, the question just doesn't make sense to me. >>>=20 >>> I don't want this issue to be an excuse to block a last call,=20 >>> can we quickly resolve this, and can we agree to drop it if=20 >>> there are no significant contributions within the next week? >>>=20 >>> cheers, >>> Ole >>>=20 >>>=20 >>>>=20 >>>> The WG discussed several times this point (refer to the mailing = list >>>> archives). >>>>=20 >>>> MAP1:1 mode is a particular mode which may re-use some of=20 >>> the provisioning >>>> methods defined for MAP. >>>>=20 >>>> MAP1:1 vs. Lw4o6: >>>> * MAP1:1 is not fully stateless. >>>> * Lw4o6 is a standalone specification which provides the=20 >>> same service as >>>> MAP1:1. >>>>=20 >>>> --=20 >>>>=20 >>> -------------------------------------+------------------------- >>> ------------ >>>> Reporter: | Owner: =20 >>> draft-ietf-softwire- >>>> mohamed.boucadair@orange.com | map@tools.ietf.org >>>> Type: defect | Status: new >>>> Priority: major | Milestone: >>>> Component: map-e | Version: >>>> Severity: - | Keywords: >>>>=20 >>> -------------------------------------+------------------------- >>> ------------ >>>>=20 >>>> Ticket URL: >>>> softwire >>>>=20 >>>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From rajiva@cisco.com Thu Feb 14 07:23:02 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD69A21F888B for ; Thu, 14 Feb 2013 07:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.483 X-Spam-Level: X-Spam-Status: No, score=-10.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpUviPh9VS47 for ; Thu, 14 Feb 2013 07:22:58 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A638921F886F for ; Thu, 14 Feb 2013 07:22:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1398; q=dns/txt; s=iport; t=1360855378; x=1362064978; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LXBgvkn8s/zwaxziDfzGPUbwdZGdI0uUml1VF0zUKnM=; b=J687LFhaEE1Vk0WCf6vJscv+kTvIPIkMCa6dHFICIREIuiczhyNu0d6V cGZielpSo+beG2MDXjNwrp9yT70EqW76zsal3VCO4W81khdmV3qkr/7gk goEoV/I5vF1WIvQBl75OHQCVhwcpFQoxxVGbSXa7Dr9JsbMoF4sLs4lph U=; X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; d="scan'208";a="177125495" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 14 Feb 2013 15:22:58 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1EFMwG4000585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Feb 2013 15:22:58 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.72]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 14 Feb 2013 09:22:58 -0600 From: "Rajiv Asati (rajiva)" To: Ole Troan , Tom Taylor Thread-Topic: [Softwires] MAP-04: BMR and forwarding rules Thread-Index: AQHOBG/auvA8aD2s70GUi5vz2H5Dpph18UKAgABgHgCAAGHEgIAAAUeAgAC2LYCAAHNmgIAAkpWAgABP8wCAAALXAIAAE08AgAAFwQCAALnCgA== Date: Thu, 14 Feb 2013 15:22:57 +0000 Message-ID: In-Reply-To: <9381104A-259C-47DC-9B3B-F3401D1CA309@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.82.255.136] Content-Type: text/plain; charset="us-ascii" Content-ID: <46DFF7AA3CCD5844BE43BC641A4DFF1A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 15:23:02 -0000 I thought we had closed this optic after the extensive discussion on the mailing list few months back. Cheers, Rajiv -----Original Message----- From: Ole Troan Date: Wednesday, February 13, 2013 6:17 PM To: Tom Taylor Cc: Softwires-wg list Subject: Re: [Softwires] MAP-04: BMR and forwarding rules >> I know that my own feeling is that MAP-E as currently described has a >>split personality. On the one hand, there are those algorithms in >>support of address sharing. On the other hand, there is provision for >>doing without the algorithms (especially when o=3D0), in which case >>ordinary provisioning processes would be sufficient. >>=20 >> I think we can all agree that during IPv6 transition operators need >>both address sharing and the ability to provide full IPv4 addresses. The >>question is whether it is necessary to combine both in this >>specification. The one justification I could see would be to provide the >>associated forwarding rules to CEs with shared addresses in the full >>mesh case. Is there another justification? > >MAP-E is a generic tool. >how an operator choose to use mapping rules is a deployment choice. > >cheers, >Ole >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From rajiva@cisco.com Thu Feb 14 07:30:50 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70E221F8625 for ; Thu, 14 Feb 2013 07:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.491 X-Spam-Level: X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0BDBhhtstbZ for ; Thu, 14 Feb 2013 07:30:50 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3189821F8623 for ; Thu, 14 Feb 2013 07:30:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3384; q=dns/txt; s=iport; t=1360855844; x=1362065444; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+bUimhbZUP2N0zek90gUc0EarrOKLa14LBaRwPURGh8=; b=IIrVDiV/ssihaKGfRswiVAMvcf9z+4YtHCEILF6EJvr8CtTu9QSIcVei iOkDkBo0GERDucWB3ghD0MsbIQPq9sO1JfeYyQQDbCaNCtDTCvQSTpDHJ 6wZmnuldlHUd59/7VvxhKcQsBxlSPwjAECEJEA0MEoT7QE4ULppoTiRfx M=; X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; d="scan'208";a="177128608" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 14 Feb 2013 15:30:44 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1EFUhkI008787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Feb 2013 15:30:43 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.72]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 14 Feb 2013 09:30:43 -0600 From: "Rajiv Asati (rajiva)" To: "mohamed.boucadair@orange.com" , Ole Troan Thread-Topic: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? Thread-Index: AQHOCqHVT9b+xXLIpU6SXC46oF/ZG5h5i/0A Date: Thu, 14 Feb 2013 15:30:43 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EAFB566A7@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.82.255.136] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 15:30:51 -0000 My vote is to keep 1:1 mode in MAP. Removing it just doesn't make sense (else, we might as well remove supporting host routing (/32 or /128) from dynamic routing protocols). Cheers, Rajiv -----Original Message----- From: "mohamed.boucadair@orange.com" Date: Thursday, February 14, 2013 5:55 AM To: Ole Troan Cc: Softwires-wg list , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? >Hi Ole, > >To start with, there was no consensus to include MAP1:1 in the MAP spec. >Unless I'm mistaken, objection to include that mode in the base MAP spec >was raised several times in the mailing list. It was mainly raised by >authors of Lw4o6 but they are also contributors to softwire. > >As an editor of this document, with all due respect, you should ask the >opinion of the WG before recording the consensus into the document. The >WG owns this document and it can decide what to put on it. > >I'm personally in favour of removing MAP1:1 section from this document as >this mode can not be packaged as stateless. But, this is only my opinion. > >Cheers, >Med > >>-----Message d'origine----- >>De : Ole Troan [mailto:ot@cisco.com] >>Envoy=E9 : jeudi 14 f=E9vrier 2013 11:14 >>=C0 : BOUCADAIR Mohamed OLNC/OLN >>Cc : draft-ietf-softwire-map@tools.ietf.org; softwires@ietf.org >>Objet : Re: [softwire] #25: Maintain or remove MAP1:1 Mode? >> >>> #25: Maintain or remove MAP1:1 Mode? >> >>OK, so here is a task for whomever thinks MAP 1:1 mode should >>be removed. >> >>- what does "remove MAP 1:1 mode mean"? >>- please suggest text changes to the mechanism that removes 1:1 mode. >> >>given that my opinion is that 1:1 mode is an unremovable part >>of MAP, the question just doesn't make sense to me. >> >>I don't want this issue to be an excuse to block a last call, >>can we quickly resolve this, and can we agree to drop it if >>there are no significant contributions within the next week? >> >>cheers, >>Ole >> >> >>>=20 >>> The WG discussed several times this point (refer to the mailing list >>> archives). >>>=20 >>> MAP1:1 mode is a particular mode which may re-use some of >>the provisioning >>> methods defined for MAP. >>>=20 >>> MAP1:1 vs. Lw4o6: >>> * MAP1:1 is not fully stateless. >>> * Lw4o6 is a standalone specification which provides the >>same service as >>> MAP1:1. >>>=20 >>> --=20 >>>=20 >>-------------------------------------+------------------------- >>------------ >>> Reporter: | Owner: >>draft-ietf-softwire- >>> mohamed.boucadair@orange.com | map@tools.ietf.org >>> Type: defect | Status: new >>> Priority: major | Milestone: >>> Component: map-e | Version: >>> Severity: - | Keywords: >>>=20 >>-------------------------------------+------------------------- >>------------ >>>=20 >>> Ticket URL: >>> softwire >>>=20 >> >> >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From ian.farrer@telekom.de Fri Feb 15 00:29:19 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF44321F86DC for ; Fri, 15 Feb 2013 00:29:19 -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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpabLhDqZKwS for ; Fri, 15 Feb 2013 00:29:19 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 03D1D21F8681 for ; Fri, 15 Feb 2013 00:29:18 -0800 (PST) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 15 Feb 2013 09:29:17 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 15 Feb 2013 09:29:16 +0100 From: To: , Date: Fri, 15 Feb 2013 09:29:20 +0100 Thread-Topic: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? Thread-Index: Ac4LVorJrh74b+f4TjCuqRbcuIOUdw== Message-ID: In-Reply-To: <4BF4806A-D597-43E7-8A60-11FC4EE0F909@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires@ietf.org, draft-ietf-softwire-map@tools.ietf.org Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 08:29:20 -0000 Hi Ole, Assuming that the Unified CPE draft gets adopted by the workgroup, then there needs to be alignment of the different drafts reflecting this. The unified CPE draft describes how a CPE interprets the presence (or lack of) configuration parameters to understand which softwire mode to configure. If a MAP CE implemented this (to be a 'unified MAP CE'), then it would have two ways of configuring 1:1 mode - via the presence of the tunnel endpoint address, an IPv4 address (and optionally a restricted port range) and also through a BMR with EA=3D0. Two ways of configuring the same function doesn't seem like a good idea, even if the underlying mechanism that this function is implemented with is different. So, what I would propose is that EA=3D0 for MAP is not included as a provisioning option in the MAP draft. If the parameters described in the unified CPE draft required for 1:1 mode are configured on the unified MAP CE, then it should interpret these to mean EA=3D0 and configure itself accordingly. I also think that it would be cleaner if this 1:1 functionality was described in a separate document to the current MAP draft. As the 1:1 mode functionality of MAP is a big architectural change to the mesh mode function, it really needs a lot more than 2 paragraphs in order to describe what it is and how it is used. Best regards, Ian On 14/02/2013 11:14, "Ole Troan" wrote: >> #25: Maintain or remove MAP1:1 Mode? > >OK, so here is a task for whomever thinks MAP 1:1 mode should be removed. > >- what does "remove MAP 1:1 mode mean"? >- please suggest text changes to the mechanism that removes 1:1 mode. > >given that my opinion is that 1:1 mode is an unremovable part of MAP, the >question just doesn't make sense to me. > >I don't want this issue to be an excuse to block a last call, can we >quickly resolve this, and can we agree to drop it if there are no >significant contributions within the next week? > >cheers, >Ole > > >>=20 >> The WG discussed several times this point (refer to the mailing list >> archives). >>=20 >> MAP1:1 mode is a particular mode which may re-use some of the >>provisioning >> methods defined for MAP. >>=20 >> MAP1:1 vs. Lw4o6: >> * MAP1:1 is not fully stateless. >> * Lw4o6 is a standalone specification which provides the same service as >> MAP1:1. >>=20 >> --=20 >>=20 >>-------------------------------------+----------------------------------- >>-- >> Reporter: | Owner: draft-ietf-softwire- >> mohamed.boucadair@orange.com | map@tools.ietf.org >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: map-e | Version: >> Severity: - | Keywords: >>=20 >>-------------------------------------+----------------------------------- >>-- >>=20 >> Ticket URL: >> softwire >>=20 > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Fri Feb 15 00:48:35 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB6A21F8976 for ; Fri, 15 Feb 2013 00:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.026 X-Spam-Level: X-Spam-Status: No, score=-3.026 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYtzRWG+8F7d for ; Fri, 15 Feb 2013 00:48:34 -0800 (PST) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by ietfa.amsl.com (Postfix) with ESMTP id C282821F8972 for ; Fri, 15 Feb 2013 00:48:34 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id uz6so3387235obc.34 for ; Fri, 15 Feb 2013 00:48:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=IhCOjTagwtGy3EQfFZJOw4iluxMQYeKqnZDrwmYNXzs=; b=rbdz2m3xztNK9/WQw9sqTsjEn5YOfEReHTh+OuKPErJ9yicmDGpr+6TRCCP6oPAwVT cH/c3mm0uyWcX7sVZSHaViYKfHvo5/X/t1p4KLEVTZsyKa5hPo7YmWf3OOclXYhw6cgc wPGeay7f5PaWuIc5Lcm7c3BS+yHSDkc3XDhXx3vVuKJOWc+OZrg67gl8Up6bZ2yXQTWi voU4fq8pY7HIWEKCUVLixC7fxL1giwEbnshMVWiqZhbyjDMjj8lYWz0XXsM6btLCUn1p acQY/L/Cy+jXH1mj0hFsPY9cGJeOuZzUYKC+jt6clnjzsXU4+ZIdfVdxUOw8ZStVWAOu Vr5A== MIME-Version: 1.0 X-Received: by 10.182.54.46 with SMTP id g14mr1165849obp.55.1360918114396; Fri, 15 Feb 2013 00:48:34 -0800 (PST) Received: by 10.76.154.8 with HTTP; Fri, 15 Feb 2013 00:48:34 -0800 (PST) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36EAFB566A7@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 15 Feb 2013 17:48:34 +0900 Message-ID: From: Maoke To: "Rajiv Asati (rajiva)" Content-Type: multipart/alternative; boundary=14dae93b57bec6ec7d04d5bf7070 Cc: "softwires@ietf.org" , Ole Troan , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 08:48:36 -0000 --14dae93b57bec6ec7d04d5bf7070 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2013/2/15 Rajiv Asati (rajiva) > > My vote is to keep 1:1 mode in MAP. Removing it just doesn't make sense > (else, we might as well remove supporting host routing (/32 or /128) from > dynamic routing protocols). > +1 i prefer to say that the early version did not include the 1:1 mode because of lack of understanding at that moment, on both the demands and what we can do with MAP. the 1:1 mode may enable MAP domain totally independent of the AS administration so that a MAP domain crossing over multiple regular routing domains is enabled. of course, we need more tools to deploy such an MAP overlay but the MAP supporting 1:1 mode is anyway a needed building block. - maoke > > Cheers, > Rajiv > > -----Original Message----- > From: "mohamed.boucadair@orange.com" > Date: Thursday, February 14, 2013 5:55 AM > To: Ole Troan > Cc: Softwires-wg list , > "draft-ietf-softwire-map@tools.ietf.org" > > Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? > > >Hi Ole, > > > >To start with, there was no consensus to include MAP1:1 in the MAP spec. > >Unless I'm mistaken, objection to include that mode in the base MAP spec > >was raised several times in the mailing list. It was mainly raised by > >authors of Lw4o6 but they are also contributors to softwire. > > > >As an editor of this document, with all due respect, you should ask the > >opinion of the WG before recording the consensus into the document. The > >WG owns this document and it can decide what to put on it. > > > >I'm personally in favour of removing MAP1:1 section from this document a= s > >this mode can not be packaged as stateless. But, this is only my opinion= . > > > >Cheers, > >Med > > > >>-----Message d'origine----- > >>De : Ole Troan [mailto:ot@cisco.com] > >>Envoy=E9 : jeudi 14 f=E9vrier 2013 11:14 > >>=C0 : BOUCADAIR Mohamed OLNC/OLN > >>Cc : draft-ietf-softwire-map@tools.ietf.org; softwires@ietf.org > >>Objet : Re: [softwire] #25: Maintain or remove MAP1:1 Mode? > >> > >>> #25: Maintain or remove MAP1:1 Mode? > >> > >>OK, so here is a task for whomever thinks MAP 1:1 mode should > >>be removed. > >> > >>- what does "remove MAP 1:1 mode mean"? > >>- please suggest text changes to the mechanism that removes 1:1 mode. > >> > >>given that my opinion is that 1:1 mode is an unremovable part > >>of MAP, the question just doesn't make sense to me. > >> > >>I don't want this issue to be an excuse to block a last call, > >>can we quickly resolve this, and can we agree to drop it if > >>there are no significant contributions within the next week? > >> > >>cheers, > >>Ole > >> > >> > >>> > >>> The WG discussed several times this point (refer to the mailing list > >>> archives). > >>> > >>> MAP1:1 mode is a particular mode which may re-use some of > >>the provisioning > >>> methods defined for MAP. > >>> > >>> MAP1:1 vs. Lw4o6: > >>> * MAP1:1 is not fully stateless. > >>> * Lw4o6 is a standalone specification which provides the > >>same service as > >>> MAP1:1. > >>> > >>> -- > >>> > >>-------------------------------------+------------------------- > >>------------ > >>> Reporter: | Owner: > >>draft-ietf-softwire- > >>> mohamed.boucadair@orange.com | map@tools.ietf.org > >>> Type: defect | Status: new > >>> Priority: major | Milestone: > >>> Component: map-e | Version: > >>> Severity: - | Keywords: > >>> > >>-------------------------------------+------------------------- > >>------------ > >>> > >>> Ticket URL: > >>> softwire > >>> > >> > >> > >_______________________________________________ > >Softwires mailing list > >Softwires@ietf.org > >https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --14dae93b57bec6ec7d04d5bf7070 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2013/2/15 Rajiv Asati (rajiva) <rajiva@c= isco.com>

My vote is to keep 1:1 mode in MAP. Removing it just doesn't make sense=
(else, we might as well remove supporting host routing (/32 or /128) from dynamic routing protocols).

+1=A0
=

i prefer to say =A0that the early version did not inclu= de the 1:1 mode because of lack of understanding at that moment, on both th= e demands and what we can do with MAP.

the 1:1 mode may enable MAP domain totally independent = of the AS administration so that a MAP domain crossing over multiple regula= r routing domains is enabled. of course, we need more tools to deploy such = an MAP overlay but the MAP supporting 1:1 mode is anyway a needed building = block.=A0

- maoke
=A0

Cheers,
Rajiv

-----Original Message-----
From: "mohamed.boucada= ir@orange.com" <mohamed.boucadair@orange.com>
Date: Thursday, February 14, 2013 5:55 AM
To: Ole Troan <ot@cisco.com>
Cc: Softwires-wg list <softwires@i= etf.org>,
"draft-ietf-= softwire-map@tools.ietf.org"
<draft-ietf-so= ftwire-map@tools.ietf.org>
Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode?
>Hi Ole,
>
>To start with, there was no consensus to include MAP1:1 in the MAP spec= .
>Unless I'm mistaken, objection to include that mode in the base MAP= spec
>was raised several times in the mailing list. It was mainly raised by >authors of Lw4o6 but they are also contributors to softwire.
>
>As an editor of this document, with all due respect, you should ask the=
>opinion of the WG before recording the consensus into the document. The=
>WG owns this document and it can decide what to put on it.
>
>I'm personally in favour of removing MAP1:1 section from this docum= ent as
>this mode can not be packaged as stateless. But, this is only my opinio= n.
>
>Cheers,
>Med
>
>>-----Message d'origine-----
>>De : Ole Troan [mailto:ot@cisco.com= ]
>>Envoy=E9 : jeudi 14 f=E9vrier 2013 11:14
>>=C0 : BOUCADAIR Mohamed OLNC/OLN
>>Cc : draf= t-ietf-softwire-map@tools.ietf.org; softwires@ietf.org
>>Objet : Re: [softwire] #25: Maintain or remove MAP1:1 Mode?
>>
>>> #25: Maintain or remove MAP1:1 Mode?
>>
>>OK, so here is a task for whomever thinks MAP 1:1 mode should
>>be removed.
>>
>>- what does "remove MAP 1:1 mode mean"?
>>- please suggest text changes to the mechanism that removes 1:1 mod= e.
>>
>>given that my opinion is that 1:1 mode is an unremovable part
>>of MAP, the question just doesn't make sense to me.
>>
>>I don't want this issue to be an excuse to block a last call, >>can we quickly resolve this, and can we agree to drop it if
>>there are no significant contributions within the next week?
>>
>>cheers,
>>Ole
>>
>>
>>>
>>> The WG discussed several times this point (refer to the mailin= g list
>>> archives).
>>>
>>> MAP1:1 mode is a particular mode which may re-use some of
>>the provisioning
>>> methods defined for MAP.
>>>
>>> MAP1:1 vs. Lw4o6:
>>> * MAP1:1 is not fully stateless.
>>> * Lw4o6 is a standalone specification which provides the
>>same service as
>>> MAP1:1.
>>>
>>> --
>>>
>>-------------------------------------+-------------------------
>>------------
>>> Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = | =A0 =A0 =A0Owner:
>>draft-ietf-softwire-
>>> =A0mohamed.bou= cadair@orange.com =A0 =A0 =A0 | =A0map@tools.ietf.org
>>> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | = =A0 =A0 Status: =A0new
>>> Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0Milestone:
>>> Component: =A0map-e =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0Version:
>>> Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 Keywords:
>>>
>>-------------------------------------+-------------------------
>>------------
>>>
>>> Ticket URL: <http://trac.tools.ietf.org/wg/softwir= e/trac/ticket/25>
>>> softwire <http://tools.ietf.org/softwire/>
>>>
>>
>>
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--14dae93b57bec6ec7d04d5bf7070-- From satoru.matsushima@gmail.com Fri Feb 15 01:00:27 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E5C21F892C for ; Fri, 15 Feb 2013 01:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW5cMlFr3qVp for ; Fri, 15 Feb 2013 01:00:26 -0800 (PST) Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id EDC2D21F88FC for ; Fri, 15 Feb 2013 01:00:21 -0800 (PST) Received: by mail-da0-f42.google.com with SMTP id z17so1425573dal.15 for ; Fri, 15 Feb 2013 01:00:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=HzwBmdjgKX1waN49CRntNS2ps1RUl09eseea50iofcQ=; b=e0KhMe1urrQBgpHlK3sbsfz4NJ8Jql7nXk64HNQs3FgXkwR3cdj4R6IOapK+8wvSYE gJR0gwu3+hcYwaOfHz0UFl9ullsvnAdcDxi7XvM4nvCJwOu4BErAujOX3JDD7XJSVfnC i3rD+gPzxaysqITAoS4L0hyX8sbNNLC+6DWyYOmnHmyLFyEKOVmUiEAPwNvZhSJCFAsv GiNA4sprpWf9XM8HYohonwklihKW8KeiU7L2dNbpvDSK/o3ACswI3DhP7kBNUC3esNY1 Xz2BXGW7J42ADC2Wr2lvFf2pLVMRtx13vfXyt4cox1Lzz0DrOrislJ8suqVSwmhtBlRi pn3w== X-Received: by 10.66.83.6 with SMTP id m6mr11179094pay.52.1360918821690; Fri, 15 Feb 2013 01:00:21 -0800 (PST) Received: from [10.201.80.76] ([202.45.12.141]) by mx.google.com with ESMTPS id a4sm4125819pbw.34.2013.02.15.01.00.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 01:00:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Satoru Matsushima In-Reply-To: Date: Fri, 15 Feb 2013 18:00:25 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: X-Mailer: Apple Mail (2.1499) Cc: ot@cisco.com, softwires@ietf.org, draft-ietf-softwire-map@tools.ietf.org Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 09:00:27 -0000 Hi Ian, On 2013/02/15, at 17:29, wrote: > Hi Ole, >=20 > Assuming that the Unified CPE draft gets adopted by the workgroup, = then > there needs to be alignment of the different drafts reflecting this. >=20 > The unified CPE draft describes how a CPE interprets the presence (or = lack > of) configuration parameters to understand which softwire mode to > configure. If a MAP CE implemented this (to be a 'unified MAP CE'), = then > it would have two ways of configuring 1:1 mode - via the presence of = the > tunnel endpoint address, an IPv4 address (and optionally a restricted = port > range) and also through a BMR with EA=3D0. >=20 > Two ways of configuring the same function doesn't seem like a good = idea, > even if the underlying mechanism that this function is implemented = with is > different. I believe that supporting bunch of provision ways is most significant = role of your 'unified CPE' work. I also think that there are another = work for unified-cpe to support not only encap solution but also = translation such as MAP-T, 4rd and 464XLAT. While hesitate to do that, I = recommend wg to postpone the adoption of unified-CPE draft. I suppose = you would argue that these aren't scope of softwire, but what does mean = 'unified' for? >=20 > So, what I would propose is that EA=3D0 for MAP is not included as a > provisioning option in the MAP draft. If the parameters described in = the > unified CPE draft required for 1:1 mode are configured on the unified = MAP > CE, then it should interpret these to mean EA=3D0 and configure itself > accordingly. >=20 In my opinion, it is quite unreasonable.=20 >=20 > I also think that it would be cleaner if this 1:1 functionality was > described in a separate document to the current MAP draft. As the 1:1 = mode > functionality of MAP is a big architectural change to the mesh mode > function, it really needs a lot more than 2 paragraphs in order to > describe what it is and how it is used. >=20 I agree that the document has to be concise but MAP document should be = consistent so let us make clear for a case when EA-len configured to = zero in the document. cheers, --satoru From wdec@cisco.com Fri Feb 15 01:03:31 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325BC21F88FC for ; Fri, 15 Feb 2013 01:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs1pj8oK0bvm for ; Fri, 15 Feb 2013 01:03:30 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1864121F87D9 for ; Fri, 15 Feb 2013 01:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5124; q=dns/txt; s=iport; t=1360919010; x=1362128610; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=S8UQrHawda5IlwuAYadzYIUPGTpaaiLqVLi61G+rI84=; b=PYFu3yyYYOgmZM7fhFGiRNJAQne8Sp3gQOgBUqqUjsSU9wKp7LnjloNf Prctw+kkj5is3UOiFQarw2nfn9wmqes84itNGwccIMLHRG/okSmHcMr9j XF4rrDeWEp1tYHewdEgntxBc264Q+gaB+p/G+v4JBxluUMnUown5Vw31V 8=; X-IronPort-AV: E=Sophos;i="4.84,671,1355097600"; d="scan'208";a="177489985" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 15 Feb 2013 09:03:30 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1F93TDg006129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Feb 2013 09:03:29 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 03:03:29 -0600 From: "Wojciech Dec (wdec)" To: "ian.farrer@telekom.de" , "ot@cisco.com" , "mohamed.boucadair@orange.com" Thread-Topic: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? Thread-Index: AQHOCpfuJkmp5jEBbkOX+ZrIkXbXoph5h4aAgAF0+QCAAAmIgA== Date: Fri, 15 Feb 2013 09:03:29 +0000 Message-ID: <19F346EB777BEE4CB77DA1A2C56F20B3222763@xmb-aln-x05.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.61.82.7] Content-Type: text/plain; charset="us-ascii" Content-ID: <81716044401E7440A7E503DC0E49C5C0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 09:03:31 -0000 Hi Ian, On 15/02/2013 09:29, "ian.farrer@telekom.de" wrote: >Hi Ole, > >Assuming that the Unified CPE draft gets adopted by the workgroup, then >there needs to be alignment of the different drafts reflecting this. > >The unified CPE draft describes how a CPE interprets the presence (or lack >of) configuration parameters to understand which softwire mode to >configure. If a MAP CE implemented this (to be a 'unified MAP CE'), then >it would have two ways of configuring 1:1 mode - via the presence of the >tunnel endpoint address, an IPv4 address (and optionally a restricted port >range) and also through a BMR with EA=3D0. The unified CPE draft, at this stage, still does not reflect some of the main feedback provided in : http://www.ietf.org/mail-archive/web/softwires/current/msg04960.html Namely: Functional decomposition... > >Two ways of configuring the same function doesn't seem like a good idea, >even if the underlying mechanism that this function is implemented with is >different. ...And this is the essence of the problem in the "unified CPE" draft. The underlying implementation MUST not be different, otherwise we're not unifying anything here. I will assert that it is possible to have a single implementation that delivers both MAP and Lw46 characteristics. The proof point of that can also be found in the existing MAP implementations. > >So, what I would propose is that EA=3D0 for MAP is not included as a >provisioning option in the MAP draft. If the parameters described in the >unified CPE draft required for 1:1 mode are configured on the unified MAP >CE, then it should interpret these to mean EA=3D0 and configure itself >accordingly. > > >I also think that it would be cleaner if this 1:1 functionality was >described in a separate document to the current MAP draft. As the 1:1 mode >functionality of MAP is a big architectural change to the mesh mode >function, it really needs a lot more than 2 paragraphs in order to >describe what it is and how it is used. It's quite the opposite. A hub&spoke topology is a subset of a mesh, and MAP covers both. Changing from one mode to the other is actually nothing more than installing a IPv4 route on the CPE. In example terms: Each MAP CE is configured with a BMR and a default route. The BMR conveys the CPE the info about it's port-set to use. Just with this information the CE can happily operate in hub&spoke mode. When the BMR is marked with a "use for forwarding" flag, the CE is able to communicate in mesh mode. Changing from one mode to the other is nothing but setting a flag in the same BMR. It is my opinion that we've discussed this 1:1 mode many many times before, and at each time concluded that a) it is a natural characteristic of MAP ii) it would actually require *more text* (and complexity) to remove it. That said, the biggest take away for me of this thread so far is that the unified CPE draft seems to be going with the assumption of two implementations for what is essentially the same functionality. This is a show-stopper IMO for the unified-cpe draft. Regards, Woj.. > > >Best regards, >Ian > >On 14/02/2013 11:14, "Ole Troan" wrote: > >>> #25: Maintain or remove MAP1:1 Mode? >> >>OK, so here is a task for whomever thinks MAP 1:1 mode should be removed. >> >>- what does "remove MAP 1:1 mode mean"? >>- please suggest text changes to the mechanism that removes 1:1 mode. >> >>given that my opinion is that 1:1 mode is an unremovable part of MAP, the >>question just doesn't make sense to me. >> >>I don't want this issue to be an excuse to block a last call, can we >>quickly resolve this, and can we agree to drop it if there are no >>significant contributions within the next week? >> >>cheers, >>Ole >> >> >>>=20 >>> The WG discussed several times this point (refer to the mailing list >>> archives). >>>=20 >>> MAP1:1 mode is a particular mode which may re-use some of the >>>provisioning >>> methods defined for MAP. >>>=20 >>> MAP1:1 vs. Lw4o6: >>> * MAP1:1 is not fully stateless. >>> * Lw4o6 is a standalone specification which provides the same service >>>as >>> MAP1:1. >>>=20 >>> --=20 >>>=20 >>>-------------------------------------+---------------------------------- >>>- >>>-- >>> Reporter: | Owner: draft-ietf-softwire- >>> mohamed.boucadair@orange.com | map@tools.ietf.org >>> Type: defect | Status: new >>> Priority: major | Milestone: >>> Component: map-e | Version: >>> Severity: - | Keywords: >>>=20 >>>-------------------------------------+---------------------------------- >>>- >>>-- >>>=20 >>> Ticket URL: >>> softwire >>>=20 >> >>_______________________________________________ >>Softwires mailing list >>Softwires@ietf.org >>https://www.ietf.org/mailman/listinfo/softwires > From despres.remi@laposte.net Fri Feb 15 01:06:32 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5E721F8976 for ; Fri, 15 Feb 2013 01:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5ROWFFgWCWh for ; Fri, 15 Feb 2013 01:06:31 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 16ACA21F8970 for ; Fri, 15 Feb 2013 01:06:31 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2303.sfr.fr (SMTP Server) with ESMTP id C870270000F8; Fri, 15 Feb 2013 10:06:29 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2303.sfr.fr (SMTP Server) with ESMTP id 4BBE17000068; Fri, 15 Feb 2013 10:06:29 +0100 (CET) X-SFR-UUID: 20130215090629310.4BBE17000068@msfrf2303.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 15 Feb 2013 10:06:28 +0100 Message-Id: <490E4C72-5186-43B4-8D94-68D6D27F05B4@laposte.net> References: To: Rajiv Asati X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Ole Troan , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 09:06:32 -0000 2013-02-14 16:30, Rajiv Asati (rajiva) : >=20 > My vote is to keep 1:1 mode in MAP. Removing it just doesn't make = sense Your point, similar to that of Ole, is that 1:1 is intrinsic to the = design. Even if not explicitly stated, it therefore cannot be removed from it. To put an end to this time-wasting controversy, it is then easy to just = delete explicit references to 1:1 (section 7.4 and examples 4 and 5).=20 > (else, we might as well remove supporting host routing (/32 or /128) = from > dynamic routing protocols). Of course you aren't serious here ;-). Regards, RD >=20 > Cheers, > Rajiv >=20 > -----Original Message----- > From: "mohamed.boucadair@orange.com" > Date: Thursday, February 14, 2013 5:55 AM > To: Ole Troan > Cc: Softwires-wg list , > "draft-ietf-softwire-map@tools.ietf.org" > > Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 = Mode? >=20 >> Hi Ole, >>=20 >> To start with, there was no consensus to include MAP1:1 in the MAP = spec. >> Unless I'm mistaken, objection to include that mode in the base MAP = spec >> was raised several times in the mailing list. It was mainly raised by >> authors of Lw4o6 but they are also contributors to softwire. >>=20 >> As an editor of this document, with all due respect, you should ask = the >> opinion of the WG before recording the consensus into the document. = The >> WG owns this document and it can decide what to put on it. >>=20 >> I'm personally in favour of removing MAP1:1 section from this = document as >> this mode can not be packaged as stateless. But, this is only my = opinion. >>=20 >> Cheers, >> Med >>=20 >>> -----Message d'origine----- >>> De : Ole Troan [mailto:ot@cisco.com] >>> Envoy=E9 : jeudi 14 f=E9vrier 2013 11:14 >>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>> Cc : draft-ietf-softwire-map@tools.ietf.org; softwires@ietf.org >>> Objet : Re: [softwire] #25: Maintain or remove MAP1:1 Mode? >>>=20 >>>> #25: Maintain or remove MAP1:1 Mode? >>>=20 >>> OK, so here is a task for whomever thinks MAP 1:1 mode should >>> be removed. >>>=20 >>> - what does "remove MAP 1:1 mode mean"? >>> - please suggest text changes to the mechanism that removes 1:1 = mode. >>>=20 >>> given that my opinion is that 1:1 mode is an unremovable part >>> of MAP, the question just doesn't make sense to me. >>>=20 >>> I don't want this issue to be an excuse to block a last call, >>> can we quickly resolve this, and can we agree to drop it if >>> there are no significant contributions within the next week? >>>=20 >>> cheers, >>> Ole >>>=20 >>>=20 >>>>=20 >>>> The WG discussed several times this point (refer to the mailing = list >>>> archives). >>>>=20 >>>> MAP1:1 mode is a particular mode which may re-use some of >>> the provisioning >>>> methods defined for MAP. >>>>=20 >>>> MAP1:1 vs. Lw4o6: >>>> * MAP1:1 is not fully stateless. >>>> * Lw4o6 is a standalone specification which provides the >>> same service as >>>> MAP1:1. >>>>=20 >>>> --=20 >>>>=20 >>> -------------------------------------+------------------------- >>> ------------ >>>> Reporter: | Owner: >>> draft-ietf-softwire- >>>> mohamed.boucadair@orange.com | map@tools.ietf.org >>>> Type: defect | Status: new >>>> Priority: major | Milestone: >>>> Component: map-e | Version: >>>> Severity: - | Keywords: >>>>=20 >>> -------------------------------------+------------------------- >>> ------------ >>>>=20 >>>> Ticket URL: >>>> softwire >>>>=20 >>>=20 >>>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Fri Feb 15 01:11:44 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E710521F8606 for ; Fri, 15 Feb 2013 01:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90u7tIdOGdc5 for ; Fri, 15 Feb 2013 01:11:38 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id EF73921F8611 for ; Fri, 15 Feb 2013 01:11:37 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2411.sfr.fr (SMTP Server) with ESMTP id A096170000BE; Fri, 15 Feb 2013 10:11:36 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2411.sfr.fr (SMTP Server) with ESMTP id 7106870000B9; Fri, 15 Feb 2013 10:11:32 +0100 (CET) X-SFR-UUID: 20130215091132463.7106870000B9@msfrf2411.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <19F346EB777BEE4CB77DA1A2C56F20B3222763@xmb-aln-x05.cisco.com> Date: Fri, 15 Feb 2013 10:11:31 +0100 Message-Id: <7EAC9C43-2B96-4132-ADE4-DF65C6ECE9E5@laposte.net> References: <19F346EB777BEE4CB77DA1A2C56F20B3222763@xmb-aln-x05.cisco.com> To: Wojciech Dec X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , "ot@cisco.com" , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 09:11:44 -0000 2013-02-15 10:03, Wojciech Dec (wdec) : ... > It is my opinion that we've discussed this 1:1 mode many many times > before, and at each time concluded that a) it is a natural = characteristic > of MAP ii) it would actually require *more text* (and complexity) to > remove it. Would you see anything needing to be reworded if section 7.4 and = examples 4 an 5 are simply deleted (the only texts AFAIK that explicitly = refer to 1:1 as being an objective)? RD From xing@cernet.edu.cn Fri Feb 15 01:35:02 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD71021F8495 for ; Fri, 15 Feb 2013 01:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTvHQgNpTnTX for ; Fri, 15 Feb 2013 01:35:01 -0800 (PST) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8586121F846B for ; Fri, 15 Feb 2013 01:35:00 -0800 (PST) Received: from [127.0.0.1] (unknown [221.11.179.1]) by centos (Coremail) with SMTP id AQAAf3CrVgUOAR5RjywKAA--.34555S5; Fri, 15 Feb 2013 17:34:08 +0800 (CST) Message-ID: <511E013B.2000801@cernet.edu.cn> Date: Fri, 15 Feb 2013 17:34:51 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ian.farrer@telekom.de References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3CrVgUOAR5RjywKAA--.34555S5 X-Coremail-Antispam: 1UD129KBjvJXoWxZFy5KF43Xr43try7Ar1fJFb_yoW5tF1rpF y3JFnFkr1DJF18Jw4Igr48G340yrWFqr43Xr15Gr18Z390yF18Ar10qw4ruryDWr98JF4j qrW8Wa43Wan8AFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUDC14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14 v26r4j6ryUM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAF wI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52 x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC2z280aVAFwI0_Jr0_Gr1l Ox8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxw CY02Avz4vE14v_GFWl42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s02 6x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0x vE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE 42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87 Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x0JUdEfOUUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: softwires@ietf.org, ot@cisco.com, draft-ietf-softwire-map@tools.ietf.org Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 09:35:02 -0000 Hi, Ian, The 1:1 mode is a natural characteristic of MAP and removing it from the draft will cause more confusion. Please also see https://datatracker.ietf.org/doc/draft-xli-softwire-map-testing/ which shows that a MAP CPE can naturally support 1:1 mode. Regards, xing ian.farrer@telekom.de 写é“: > Hi Ole, > > Assuming that the Unified CPE draft gets adopted by the workgroup, then > there needs to be alignment of the different drafts reflecting this. > > The unified CPE draft describes how a CPE interprets the presence (or lack > of) configuration parameters to understand which softwire mode to > configure. If a MAP CE implemented this (to be a 'unified MAP CE'), then > it would have two ways of configuring 1:1 mode - via the presence of the > tunnel endpoint address, an IPv4 address (and optionally a restricted port > range) and also through a BMR with EA=0. > > Two ways of configuring the same function doesn't seem like a good idea, > even if the underlying mechanism that this function is implemented with is > different. > > So, what I would propose is that EA=0 for MAP is not included as a > provisioning option in the MAP draft. If the parameters described in the > unified CPE draft required for 1:1 mode are configured on the unified MAP > CE, then it should interpret these to mean EA=0 and configure itself > accordingly. > > > I also think that it would be cleaner if this 1:1 functionality was > described in a separate document to the current MAP draft. As the 1:1 mode > functionality of MAP is a big architectural change to the mesh mode > function, it really needs a lot more than 2 paragraphs in order to > describe what it is and how it is used. > > > Best regards, > Ian > > On 14/02/2013 11:14, "Ole Troan" wrote: > > >>> #25: Maintain or remove MAP1:1 Mode? >>> >> OK, so here is a task for whomever thinks MAP 1:1 mode should be removed. >> >> - what does "remove MAP 1:1 mode mean"? >> - please suggest text changes to the mechanism that removes 1:1 mode. >> >> given that my opinion is that 1:1 mode is an unremovable part of MAP, the >> question just doesn't make sense to me. >> >> I don't want this issue to be an excuse to block a last call, can we >> quickly resolve this, and can we agree to drop it if there are no >> significant contributions within the next week? >> >> cheers, >> Ole >> >> >> >>> The WG discussed several times this point (refer to the mailing list >>> archives). >>> >>> MAP1:1 mode is a particular mode which may re-use some of the >>> provisioning >>> methods defined for MAP. >>> >>> MAP1:1 vs. Lw4o6: >>> * MAP1:1 is not fully stateless. >>> * Lw4o6 is a standalone specification which provides the same service as >>> MAP1:1. >>> >>> -- >>> >>> -------------------------------------+----------------------------------- >>> -- >>> Reporter: | Owner: draft-ietf-softwire- >>> mohamed.boucadair@orange.com | map@tools.ietf.org >>> Type: defect | Status: new >>> Priority: major | Milestone: >>> Component: map-e | Version: >>> Severity: - | Keywords: >>> >>> -------------------------------------+----------------------------------- >>> -- >>> >>> Ticket URL: >>> softwire >>> >>> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > > From satoru.matsushima@gmail.com Fri Feb 15 01:46:16 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BC321F8629 for ; Fri, 15 Feb 2013 01:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzR2QGJ-FVRZ for ; Fri, 15 Feb 2013 01:46:15 -0800 (PST) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id A22E721F861B for ; Fri, 15 Feb 2013 01:46:15 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id wy12so560293pbc.7 for ; Fri, 15 Feb 2013 01:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=djxrxcFMTEiyR9DUGa0qmxcrXNjopm1J84FHA/In82E=; b=ncyCKhP54QDt2JYjEyMVFHouKIkl5ZSrHOrlL0eL40fW8GkQFBTNx6gyMVQgWKyyjO 7bsNj973t2Qcu2KPdwqSuXexgL3f2xoj5hRxOgi1g7np6TG1Rl0hZ6GdFm9NT9zXqgcw Opa6QSy0p8JdVMRPSexvRzgFHVehIc5oMmCCetiWn69o+C1MXzw0WnhnbvTKLW0RjHri Ivl4hJApb0uaDC8Eu5gGrv0MLJfoq4OadXp6DWyfgenM3bXbP1vNsrJAAmMbA6hLpol4 LqFALm0zmqUagkMj6mhgCEfA9DK9n4QHDusFe/uXZK/datY9+Y9VMlg+Rg/kix1U7QbK Ah8A== X-Received: by 10.66.89.199 with SMTP id bq7mr11552860pab.26.1360921575391; Fri, 15 Feb 2013 01:46:15 -0800 (PST) Received: from [10.201.80.76] ([202.45.12.141]) by mx.google.com with ESMTPS id bi2sm93132372pab.18.2013.02.15.01.46.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 01:46:10 -0800 (PST) Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Satoru Matsushima In-Reply-To: <511E013B.2000801@cernet.edu.cn> Date: Fri, 15 Feb 2013 18:46:14 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <77C95E94-4906-41B8-9B85-37236B3842C6@gmail.com> References: <511E013B.2000801@cernet.edu.cn> To: Xing Li X-Mailer: Apple Mail (2.1499) Cc: softwires@ietf.org, ot@cisco.com, draft-ietf-softwire-map@tools.ietf.org Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 09:46:16 -0000 On 2013/02/15, at 18:34, Xing Li wrote: > Hi, Ian, >=20 > The 1:1 mode is a natural characteristic of MAP and removing it from = the draft will cause more confusion. Please also see = https://datatracker.ietf.org/doc/draft-xli-softwire-map-testing/ > which shows that a MAP CPE can naturally support 1:1 mode. >=20 > Regards, >=20 > xing >=20 ASAMAP too. cheers, --satoru >=20 > ian.farrer@telekom.de =1B$B> Hi Ole, >>=20 >> Assuming that the Unified CPE draft gets adopted by the workgroup, = then >> there needs to be alignment of the different drafts reflecting this. >>=20 >> The unified CPE draft describes how a CPE interprets the presence (or = lack >> of) configuration parameters to understand which softwire mode to >> configure. If a MAP CE implemented this (to be a 'unified MAP CE'), = then >> it would have two ways of configuring 1:1 mode - via the presence of = the >> tunnel endpoint address, an IPv4 address (and optionally a restricted = port >> range) and also through a BMR with EA=3D0. >>=20 >> Two ways of configuring the same function doesn't seem like a good = idea, >> even if the underlying mechanism that this function is implemented = with is >> different. >>=20 >> So, what I would propose is that EA=3D0 for MAP is not included as a >> provisioning option in the MAP draft. If the parameters described in = the >> unified CPE draft required for 1:1 mode are configured on the unified = MAP >> CE, then it should interpret these to mean EA=3D0 and configure = itself >> accordingly. >>=20 >>=20 >> I also think that it would be cleaner if this 1:1 functionality was >> described in a separate document to the current MAP draft. As the 1:1 = mode >> functionality of MAP is a big architectural change to the mesh mode >> function, it really needs a lot more than 2 paragraphs in order to >> describe what it is and how it is used. >>=20 >>=20 >> Best regards, >> Ian >>=20 >> On 14/02/2013 11:14, "Ole Troan" wrote: >>=20 >> =20 >>>> #25: Maintain or remove MAP1:1 Mode? >>>> =20 >>> OK, so here is a task for whomever thinks MAP 1:1 mode should be = removed. >>>=20 >>> - what does "remove MAP 1:1 mode mean"? >>> - please suggest text changes to the mechanism that removes 1:1 = mode. >>>=20 >>> given that my opinion is that 1:1 mode is an unremovable part of = MAP, the >>> question just doesn't make sense to me. >>>=20 >>> I don't want this issue to be an excuse to block a last call, can we >>> quickly resolve this, and can we agree to drop it if there are no >>> significant contributions within the next week? >>>=20 >>> cheers, >>> Ole >>>=20 >>>=20 >>> =20 >>>> The WG discussed several times this point (refer to the mailing = list >>>> archives). >>>>=20 >>>> MAP1:1 mode is a particular mode which may re-use some of the >>>> provisioning >>>> methods defined for MAP. >>>>=20 >>>> MAP1:1 vs. Lw4o6: >>>> * MAP1:1 is not fully stateless. >>>> * Lw4o6 is a standalone specification which provides the same = service as >>>> MAP1:1. >>>>=20 >>>> --=20 >>>>=20 >>>> = -------------------------------------+----------------------------------- >>>> -- >>>> Reporter: | Owner: = draft-ietf-softwire- >>>> mohamed.boucadair@orange.com | map@tools.ietf.org >>>> Type: defect | Status: new >>>> Priority: major | Milestone: >>>> Component: map-e | Version: >>>> Severity: - | Keywords: >>>>=20 >>>> = -------------------------------------+----------------------------------- >>>> -- >>>>=20 >>>> Ticket URL: >>>> softwire >>>>=20 >>>> =20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> =20 >>=20 >>=20 >>=20 >> =20 >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From sunqi.csnet.thu@gmail.com Fri Feb 15 01:52:41 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3544F21F8953 for ; Fri, 15 Feb 2013 01:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21rUl2m6fnxH for ; Fri, 15 Feb 2013 01:52:40 -0800 (PST) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9C66421F861C for ; Fri, 15 Feb 2013 01:52:40 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id uo15so557052pbc.5 for ; Fri, 15 Feb 2013 01:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=35W8LM91bZtS9gHShzHQqsT41AU1PAigRNEKPExNzr4=; b=RpcK/D3knyIxy6ldtbuVyxYSMEjNuF/7rMmasNhygBlG6j8xi9fmup0mZBMj/0rTEm PcHCIP2qGVjZc1wC17/qnRmCGFjwePkhtBH5MIfTIgKgz47ML3mzRnfGnjaqoEBSrY4h 4P7yCCwMsZXShUJhVCSavfkrQoh2DS5gwziGTLL2zbw3lHbCN81HDKDq1Z1V/0h5M6Ds KwnfTnES9qhx/90uddaVuStJQS9HBkPhFBw6KYxTuEQfvR4ugk7HeZPe9AwpuhB2bD5X wNvfh4E7y0YY2Jgtvjq6Hbqd5g5nQobAF5Fhlz1i7NY6p4KyUAEW+fGJ720VAwVSYAuf 9L5A== X-Received: by 10.66.81.199 with SMTP id c7mr11521664pay.39.1360921960357; Fri, 15 Feb 2013 01:52:40 -0800 (PST) Received: from [192.168.0.102] ([27.194.229.3]) by mx.google.com with ESMTPS id in5sm4252464pbc.20.2013.02.15.01.52.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 01:52:39 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-18-362663237 From: Qi Sun In-Reply-To: Date: Fri, 15 Feb 2013 17:52:32 +0800 Message-Id: <5BA2BDB6-5A2B-470D-B42D-567701AB3178@gmail.com> References: <511098A3.7030406@ericsson.com> To: Qiong X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 09:52:41 -0000 --Apple-Mail-18-362663237 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, Support. This work should be helpful for moving forward with both lw4o6 = and MAP. Best Regards, Qi Sun On 2013-2-6, at =E4=B8=8B=E5=8D=881:40, Qiong wrote: > Dear all, >=20 > Support to adopt. This is a good starting point to work with both MAP = and LW4O6. >=20 > Best wishes > Qiong >=20 >=20 > On Tue, Feb 5, 2013 at 1:29 PM, Suresh Krishnan = wrote: > Hi all, > This draft was a result of the discussion initiated at the softwire > meeting in Atlanta to attempt to come up with a unified CPE > specification that can work with both MAP and lw4o6. This call is = being > initiated to determine whether there is WG consensus towards adoption = of > draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please = state > whether or not you're in favor of the adoption by replying to this > email. If you are not in favor, please also state your objections in > your response. This adoption call will complete on 2013-02-18. >=20 > Regards > Suresh & Yong >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Qiong Sun > China Telecom Beijing Research Institude >=20 >=20 > Open source code: > lightweight 4over6: http://sourceforge.net/projects/laft6/ > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-18-362663237 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear = all,

Support. This work should be helpful for = moving forward with both lw4o6 and = MAP.


Best Regards,
Qi = Sun

On 2013-2-6, at =E4=B8=8B=E5=8D=881:40, Qiong = wrote:

Dear all,

Support to adopt. This is a good starting point to work with = both MAP and LW4O6.

Best = wishes
Qiong


On Tue, Feb 5, 2013 at 1:29 PM, = Suresh Krishnan <suresh.krishnan@ericsson.com> = wrote:
Hi all,
  This draft was a result of the discussion initiated at the = softwire
meeting in Atlanta to attempt to come up with a unified CPE
specification that can work with both MAP and lw4o6. This call is = being
initiated to determine whether there is WG consensus towards adoption = of
draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please = state
whether or not you're in favor of the adoption by replying to this
email. If you are not in favor, please also state your objections in
your response. This adoption call will complete on 2013-02-18.

Regards
Suresh & Yong


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires



-- =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qion= g Sun
China Telecom Beijing Research Institude


Open source = code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= --Apple-Mail-18-362663237-- From wdec@cisco.com Fri Feb 15 02:16:18 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB2F21F89DC for ; Fri, 15 Feb 2013 02:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVm8XtNnkX1R for ; Fri, 15 Feb 2013 02:16:17 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5837821F8A0C for ; Fri, 15 Feb 2013 02:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1297; q=dns/txt; s=iport; t=1360923377; x=1362132977; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=M84mTiOmn6anCJdGoPkWW0ThFejl2qfT8fwzlcPzu/Y=; b=fC6QCCLynD6lMihKuGo34SG1IvNxnytF8OFD/aL24qE6ynkdWQJSgS7k eoBRSsKHNRMUAzeW8svY76sgYQAfewgxNazLzoZQLe6dekXwIkrsYe9eJ UDw1L0g1IRuzXvbZAoFuc/ApWUUkMC8unnjGaLKQd5T80ToEi4jWNCTn3 o=; X-IronPort-AV: E=Sophos;i="4.84,672,1355097600"; d="scan'208";a="177482636" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 15 Feb 2013 10:16:09 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1FAG9dr009395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Feb 2013 10:16:09 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 04:16:09 -0600 From: "Wojciech Dec (wdec)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? Thread-Index: AQHOCpfuJkmp5jEBbkOX+ZrIkXbXoph5h4aAgAF0+QCAAAmIgIAAAkGAgAAizoA= Date: Fri, 15 Feb 2013 10:16:08 +0000 Message-ID: <19F346EB777BEE4CB77DA1A2C56F20B3222AD6@xmb-aln-x05.cisco.com> In-Reply-To: <7EAC9C43-2B96-4132-ADE4-DF65C6ECE9E5@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.55.95.33] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <46DDCCDC2F526146B2A70C6BECFB0F39@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "ot@cisco.com" , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 10:16:18 -0000 On 15/02/2013 10:11, "R=E9mi Despr=E9s" wrote: > > 2013-02-15 10:03, Wojciech Dec (wdec) : >... >> It is my opinion that we've discussed this 1:1 mode many many times >> before, and at each time concluded that a) it is a natural >>characteristic >> of MAP ii) it would actually require *more text* (and complexity) to >> remove it. > >Would you see anything needing to be reworded if section 7.4 and examples >4 an 5 are simply deleted (the only texts AFAIK that explicitly refer to >1:1 as being an objective)? Let's take a step back: Long long time ago, in an era of many ills with the softwire WG, a pseudo WG-draft was set-up whose primary reason for existence was the supposed lack of 1:1 mode in MAP... The text you reference was included to provide examples of how the 1:1 is realized. Removing such text will thus take us back to answering "how does MAP do 1:1?", not doing anyone a favor really (noting that existing implementations support the 1:1 mode, as a natural part of the implementation and that at least the developers involved I know didn't find the implementation to be an issue.) Of course we can always write N drafts, but that's not the point of why we're here (IMO). -Woj.. > >RD > > > From sunqi.csnet.thu@gmail.com Fri Feb 15 02:30:15 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0394A21F8550 for ; Fri, 15 Feb 2013 02:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N88A8v0qjULH for ; Fri, 15 Feb 2013 02:30:14 -0800 (PST) Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3891721F8528 for ; Fri, 15 Feb 2013 02:30:14 -0800 (PST) Received: by mail-da0-f42.google.com with SMTP id z17so1412949dal.1 for ; Fri, 15 Feb 2013 02:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=7w7YzrTtizmxo3UVcAIC8egvP2eX02e+/7MbehCV5d0=; b=w8GZqd9JZU8YPcwFofMzjP/B/wYTfQ2hMy+KWSuQZIhdkt3GpoIy6eIkOJdGFEGhvA 7pW0/PHoRCcWjHN7CYQllKkSEI4G62I6PJTgpI2QUAWSyBAeb4Yw0S6Sl5zNNmzykyKM QiY+IGHJqOKMJ2b0okLsy/lUCt6eAw9nGZjQTjLe1UMHuKyRf9TbzcT6gdxMbTTyE2Gk Fc2PuT1odHldttpIi5DdREwOTfB0Lf+Pm/wudY3/gaPE1UmnwJLLEt1AV3RHgBsKrFJO +J1NFWoLjED/2l1E4nhAWk9csWJpiMf134OHz2Xdhlw1SfTWCAJTf+C9V723ZhzXEHyt DcFg== X-Received: by 10.68.197.231 with SMTP id ix7mr4674163pbc.123.1360924214001; Fri, 15 Feb 2013 02:30:14 -0800 (PST) Received: from [192.168.0.102] ([27.194.229.3]) by mx.google.com with ESMTPS id k7sm79899444paz.13.2013.02.15.02.30.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 02:30:13 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <4BF4806A-D597-43E7-8A60-11FC4EE0F909@cisco.com> Date: Fri, 15 Feb 2013 18:30:06 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6E05CDA8-2A0D-42C3-A8FD-18E9C2076CAC@gmail.com> References: <071.e0df54c8f0f2d697ebf7688240481b71@tools.ietf.org> <4BF4806A-D597-43E7-8A60-11FC4EE0F909@cisco.com> To: Ole Troan X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org, draft-ietf-softwire-map@tools.ietf.org Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 10:30:15 -0000 Hi Ole, There are 2 ways to achieve address sharing in MAP-E-04, one is = algorithmic mapping IPv4 address and PSID into IPv6 prefix, the other is = non-algorithmic binding of IPv4 address, port-set and IPv6 address. The = former is advocating the designed algorithm to achieve stateless, while = the latter achieves IPv4/IPv6 address independence by abandoning the = algorithm. It conflicts with itself. Now that the algorithm is still there when EA =3D 0 (even though not = used), MAP-E still requires the implementation of the algorithm and = planning IPv4 and IPv6 address together. This increases the cost for = operators. Removing MAP 1:1 mode helps MAP be cleaner as a stateless solution for = operators. My vote is to remove MAP 1:1 mode. Best Regards, Qi Sun On 2013-2-14, at =E4=B8=8B=E5=8D=886:14, Ole Troan wrote: >> #25: Maintain or remove MAP1:1 Mode? >=20 > OK, so here is a task for whomever thinks MAP 1:1 mode should be = removed. >=20 > - what does "remove MAP 1:1 mode mean"? > - please suggest text changes to the mechanism that removes 1:1 mode. >=20 > given that my opinion is that 1:1 mode is an unremovable part of MAP, = the question just doesn't make sense to me. >=20 > I don't want this issue to be an excuse to block a last call, can we = quickly resolve this, and can we agree to drop it if there are no = significant contributions within the next week? >=20 > cheers, > Ole >=20 >=20 >>=20 >> The WG discussed several times this point (refer to the mailing list >> archives). >>=20 >> MAP1:1 mode is a particular mode which may re-use some of the = provisioning >> methods defined for MAP. >>=20 >> MAP1:1 vs. Lw4o6: >> * MAP1:1 is not fully stateless. >> * Lw4o6 is a standalone specification which provides the same service = as >> MAP1:1. >>=20 >> --=20 >> = -------------------------------------+------------------------------------= - >> Reporter: | Owner: = draft-ietf-softwire- >> mohamed.boucadair@orange.com | map@tools.ietf.org >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: map-e | Version: >> Severity: - | Keywords: >> = -------------------------------------+------------------------------------= - >>=20 >> Ticket URL: >> softwire >>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Fri Feb 15 03:06:15 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB2821F8A1D for ; Fri, 15 Feb 2013 03:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBw0QRQwREHC for ; Fri, 15 Feb 2013 03:06:13 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id 07BEE21F89C5 for ; Fri, 15 Feb 2013 03:06:12 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2402.sfr.fr (SMTP Server) with ESMTP id 731A87000106; Fri, 15 Feb 2013 12:06:08 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2402.sfr.fr (SMTP Server) with ESMTP id EF3B47000103; Fri, 15 Feb 2013 12:06:07 +0100 (CET) X-SFR-UUID: 20130215110607980.EF3B47000103@msfrf2402.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <19F346EB777BEE4CB77DA1A2C56F20B3222AD6@xmb-aln-x05.cisco.com> Date: Fri, 15 Feb 2013 12:06:07 +0100 Message-Id: References: <19F346EB777BEE4CB77DA1A2C56F20B3222AD6@xmb-aln-x05.cisco.com> To: Wojciech Dec X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , "ot@cisco.com" , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 11:06:15 -0000 Le 2013-02-15 =E0 11:16, Wojciech Dec (wdec) a =E9crit = : >=20 >=20 > On 15/02/2013 10:11, "R=E9mi Despr=E9s" = wrote: >=20 >>=20 >> 2013-02-15 10:03, Wojciech Dec (wdec) : >> ... >>> It is my opinion that we've discussed this 1:1 mode many many times >>> before, and at each time concluded that a) it is a natural >>> characteristic >>> of MAP ii) it would actually require *more text* (and complexity) to >>> remove it. >>=20 >> Would you see anything needing to be reworded if section 7.4 and = examples >> 4 an 5 are simply deleted (the only texts AFAIK that explicitly refer = to >> 1:1 as being an objective)? >=20 > Let's take a step back: Long long time ago, in an era of many ills = with > the softwire WG, a pseudo WG-draft was set-up whose primary reason for > existence was the supposed lack of 1:1 mode in MAP... > The text you reference was included to provide examples of how the 1:1 = is > realized. Removing such text will thus take us back to answering "how = does > MAP do 1:1?", not doing anyone a favor really (noting that existing > implementations support the 1:1 mode, as a natural part of the > implementation and that at least the developers involved I know didn't > find the implementation to be an issue.) > Of course we can always write N drafts, but that's not the point of = why > we're here (IMO). It is thus clear that, if section 7.4 and examples 4 and 5 are deleted = from the MAP draft, *no more text* is NEEDED in the draft itself. Applicability of MAP and of other solutions to 1:1 can be clarified in = some other document(s) when consensus is reached. Thanks, RD =20 >=20 > -Woj.. >=20 >>=20 >> RD >>=20 >>=20 >>=20 >=20 From wdec@cisco.com Fri Feb 15 03:16:05 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE54721F865D for ; Fri, 15 Feb 2013 03:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNA-PAys6WGn for ; Fri, 15 Feb 2013 03:16:04 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B590821F8654 for ; Fri, 15 Feb 2013 03:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2453; q=dns/txt; s=iport; t=1360926964; x=1362136564; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=33KcLQxFBaavhYPm1i24jeT9aJCyDwr6sr6FeyiYqnI=; b=JSrCzWfaXUzxI5rPjKNH7pP3LOrX/zlR32m6ispt+3IodR99uPiDTaNF 75kkvUE619vIBx2TBTAkEL7P4/RveEbY01iA19wVXfDrR1NRQg8hDYSUO 1h4D1ZQ3Iv8ojIk5lvbBIh4gVz/qGb6dg1//8bW+UoM8Gi/tZ9FodxSHn k=; X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; d="scan'208";a="177497085" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 15 Feb 2013 11:16:03 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1FBG3np004891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Feb 2013 11:16:03 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 05:16:02 -0600 From: "Wojciech Dec (wdec)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? Thread-Index: AQHOCpfuJkmp5jEBbkOX+ZrIkXbXoph5h4aAgAF0+QCAAAmIgIAAAkGAgAAizoD///03gIAAE4YA Date: Fri, 15 Feb 2013 11:16:02 +0000 Message-ID: <19F346EB777BEE4CB77DA1A2C56F20B3222BBB@xmb-aln-x05.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.55.95.33] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "ot@cisco.com" , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 11:16:06 -0000 Remi, The question Ole posed still stands: - what does "remove MAP 1:1 mode mean"? As evidenced by some of the emails (evidence being phrases like [sic] "Removing MAP 1:1 mode helps MAP be cleaner as a stateless solution for operators.", etc) on this thread, some folks appear to mean that MAP is *technically* specified as being prevented from realizing the 1:1 mode. This would require extra text and is radically different to moving a description of how MAP is used in 1:1 mode (to some informative draft). Rgds, Woj.. On 15/02/2013 12:06, "R=E9mi Despr=E9s" wrote: > >Le 2013-02-15 =E0 11:16, Wojciech Dec (wdec) a =E9crit : > >>=20 >>=20 >> On 15/02/2013 10:11, "R=E9mi Despr=E9s" wrote= : >>=20 >>>=20 >>> 2013-02-15 10:03, Wojciech Dec (wdec) : >>> ... >>>> It is my opinion that we've discussed this 1:1 mode many many times >>>> before, and at each time concluded that a) it is a natural >>>> characteristic >>>> of MAP ii) it would actually require *more text* (and complexity) to >>>> remove it. >>>=20 >>> Would you see anything needing to be reworded if section 7.4 and >>>examples >>> 4 an 5 are simply deleted (the only texts AFAIK that explicitly refer >>>to >>> 1:1 as being an objective)? >>=20 >> Let's take a step back: Long long time ago, in an era of many ills with >> the softwire WG, a pseudo WG-draft was set-up whose primary reason for >> existence was the supposed lack of 1:1 mode in MAP... >> The text you reference was included to provide examples of how the 1:1 >>is >> realized. Removing such text will thus take us back to answering "how >>does >> MAP do 1:1?", not doing anyone a favor really (noting that existing >> implementations support the 1:1 mode, as a natural part of the >> implementation and that at least the developers involved I know didn't >> find the implementation to be an issue.) >> Of course we can always write N drafts, but that's not the point of why >> we're here (IMO). > >It is thus clear that, if section 7.4 and examples 4 and 5 are deleted >from the MAP draft, *no more text* is NEEDED in the draft itself. > >Applicability of MAP and of other solutions to 1:1 can be clarified in >some other document(s) when consensus is reached. > >Thanks, >RD > > =20 > >>=20 >> -Woj.. >>=20 >>>=20 >>> RD >>>=20 >>>=20 >>>=20 >>=20 From despres.remi@laposte.net Fri Feb 15 05:30:39 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E10D21F8658 for ; Fri, 15 Feb 2013 05:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPKGDmwBLLDz for ; Fri, 15 Feb 2013 05:30:38 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 27E3421F862B for ; Fri, 15 Feb 2013 05:30:37 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2207.sfr.fr (SMTP Server) with ESMTP id 292247000057; Fri, 15 Feb 2013 14:30:34 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2207.sfr.fr (SMTP Server) with ESMTP id 36A6A700008D; Fri, 15 Feb 2013 14:30:33 +0100 (CET) X-SFR-UUID: 20130215133033223.36A6A700008D@msfrf2207.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <19F346EB777BEE4CB77DA1A2C56F20B3222BBB@xmb-aln-x05.cisco.com> Date: Fri, 15 Feb 2013 14:30:32 +0100 Message-Id: <82547F67-DA59-4A89-B065-6B2F67833ABC@laposte.net> References: <19F346EB777BEE4CB77DA1A2C56F20B3222BBB@xmb-aln-x05.cisco.com> To: "Wojciech Dec (wdec)" X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG , Ole Troan , Yong Cui Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 13:30:39 -0000 2013-02-15 12:16, "Wojciech Dec (wdec)" : > Remi, >=20 > The question Ole posed still stands: > - what does "remove MAP 1:1 mode mean"? This question was in Ole's answer to Med saying he is "in favour of = removing MAP1:1 section" (ref. = http://www.ietf.org/mail-archive/web/softwires/current/msg05182). But Med's request was already perfectly clear. (I just noted that, for consistency, removal of examples 4 and 5 of = Appendix A goes with that of section 7.4.) Since consensus to have this section never exited, the editor should = remove it *before WGLC*. (Editors must AFAIK remain neutral.) Regards, RD > On 15/02/2013 12:06, "R=E9mi Despr=E9s" = wrote: ... >> It is thus clear that, if section 7.4 and examples 4 and 5 are = deleted >> from the MAP draft, *no more text* is NEEDED in the draft itself. >>=20 >> Applicability of MAP and of other solutions to 1:1 can be clarified = in >> some other document(s) when consensus is reached. >>=20 >> Thanks, >> RD >>=20 From wdec@cisco.com Fri Feb 15 05:40:24 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18F621F8717 for ; Fri, 15 Feb 2013 05:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGrpY27bo-iM for ; Fri, 15 Feb 2013 05:40:23 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DA01521F8716 for ; Fri, 15 Feb 2013 05:40:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1579; q=dns/txt; s=iport; t=1360935623; x=1362145223; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9Y9/lpVO19qXzKTqryz7xuFOKJ2050xaVawJ4z2c5XY=; b=NPW+FsuRTpxUo3FWCQWN2RoUDn7pmrKTfsAf9s+rMDtVT4+fkLoHmGP+ PEhcCT3VEHrZzeD1YgftmYcd6c9LDQniDwnhfndDFEs4kCanFZ2TOPV5a +2dSWF64Y/YOBR48tizqj2a0W4Y3A88/1NfIeGnskZueJ+NltZutLhnm2 U=; X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; d="scan'208";a="177529115" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 15 Feb 2013 13:40:22 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1FDeMFd005192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Feb 2013 13:40:22 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 07:40:22 -0600 From: "Wojciech Dec (wdec)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? Thread-Index: AQHOCpfuJkmp5jEBbkOX+ZrIkXbXoph5h4aAgAF0+QCAAAmIgIAAAkGAgAAizoD///03gIAAE4YAgAAU0wCAABN+AA== Date: Fri, 15 Feb 2013 13:40:20 +0000 Message-ID: <19F346EB777BEE4CB77DA1A2C56F20B3222C97@xmb-aln-x05.cisco.com> In-Reply-To: <82547F67-DA59-4A89-B065-6B2F67833ABC@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.55.95.33] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG , Ole Troan , Yong Cui Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 13:40:24 -0000 On 15/02/2013 14:30, "R=E9mi Despr=E9s" wrote: > >2013-02-15 12:16, "Wojciech Dec (wdec)" : > >> Remi, >>=20 >> The question Ole posed still stands: >> - what does "remove MAP 1:1 mode mean"? > >This question was in Ole's answer to Med saying he is "in favour of >removing MAP1:1 section" (ref. >http://www.ietf.org/mail-archive/web/softwires/current/msg05182). > >But Med's request was already perfectly clear. Likely a truism but, if it was perfectly clear, then Ole wouldn't have asked the question. The e-mails that ensued (eg from Qi) make it clear that at least for some the removal request is a technical one not an editorial. >(I just noted that, for consistency, removal of examples 4 and 5 of >Appendix A goes with that of section 7.4.) > >Since consensus to have this section never exited, the editor should >remove it *before WGLC*. >(Editors must AFAIK remain neutral.) We've previously established consensus that MAP supports 1:1 mode (it likely happened at the meeting after you bid farewell to the group). Suresh can confirm. -Woj.. > >Regards, >RD > > >> On 15/02/2013 12:06, "R=E9mi Despr=E9s" wrote= : >... >>> It is thus clear that, if section 7.4 and examples 4 and 5 are deleted >>> from the MAP draft, *no more text* is NEEDED in the draft itself. >>>=20 >>> Applicability of MAP and of other solutions to 1:1 can be clarified in >>> some other document(s) when consensus is reached. >>>=20 >>> Thanks, >>> RD >>>=20 From despres.remi@laposte.net Fri Feb 15 05:51:29 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E722C21F8B13 for ; Fri, 15 Feb 2013 05:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2s0iTlSPYp9 for ; Fri, 15 Feb 2013 05:51:29 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 1243321F8B0C for ; Fri, 15 Feb 2013 05:51:28 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id 8C0E670007FD; Fri, 15 Feb 2013 14:51:27 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id E24BF70007D7; Fri, 15 Feb 2013 14:51:26 +0100 (CET) X-SFR-UUID: 20130215135126927.E24BF70007D7@msfrf2416.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <19F346EB777BEE4CB77DA1A2C56F20B3222C97@xmb-aln-x05.cisco.com> Date: Fri, 15 Feb 2013 14:51:26 +0100 Message-Id: <5EFF550E-3BC1-47B9-849E-B66E1ED2A143@laposte.net> References: <19F346EB777BEE4CB77DA1A2C56F20B3222C97@xmb-aln-x05.cisco.com> To: "Wojciech Dec (wdec)" X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG , Ole Troan , Yong Cui Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 13:51:30 -0000 Le 2013-02-15 =E0 14:40, "Wojciech Dec (wdec)" a =E9crit = : >=20 >=20 > On 15/02/2013 14:30, "R=E9mi Despr=E9s" = wrote: >=20 >>=20 >> 2013-02-15 12:16, "Wojciech Dec (wdec)" : >>=20 >>> Remi, >>>=20 >>> The question Ole posed still stands: >>> - what does "remove MAP 1:1 mode mean"? >>=20 >> This question was in Ole's answer to Med saying he is "in favour of >> removing MAP1:1 section" (ref. >> http://www.ietf.org/mail-archive/web/softwires/current/msg05182). >>=20 >> But Med's request was already perfectly clear. >=20 > Likely a truism but, if it was perfectly clear, then Ole wouldn't have > asked the question. "Removing MAP1:1 section" isn't "removing MAP1:1"=20 > The e-mails that ensued (eg from Qi) make it clear that at least for = some > the removal request is a technical one not an editorial. Different subject. >=20 >> (I just noted that, for consistency, removal of examples 4 and 5 of >> Appendix A goes with that of section 7.4.) >>=20 >> Since consensus to have this section never exited, the editor should >> remove it *before WGLC*. >> (Editors must AFAIK remain neutral.) >=20 > We've previously established consensus that MAP supports 1:1 mode (it > likely happened at the meeting after you bid farewell to the group). > Suresh can confirm. Please understand that "Removing MAP1:1 section" isn't against this (as = I suppose Med and Suresh can confirm too). RD >=20 > -Woj.. >=20 >=20 >=20 >=20 >>=20 >> Regards, >> RD >>=20 >>=20 >>> On 15/02/2013 12:06, "R=E9mi Despr=E9s" = wrote: >> ... >>>> It is thus clear that, if section 7.4 and examples 4 and 5 are = deleted >>>> from the MAP draft, *no more text* is NEEDED in the draft itself. >>>>=20 >>>> Applicability of MAP and of other solutions to 1:1 can be clarified = in >>>> some other document(s) when consensus is reached. >>>>=20 >>>> Thanks, >>>> RD >>>>=20 >=20 From wdec@cisco.com Fri Feb 15 07:14:38 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC2021F8AE0 for ; Fri, 15 Feb 2013 07:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2C4+NjTXU3mB for ; Fri, 15 Feb 2013 07:14:38 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E38A921F8ADF for ; Fri, 15 Feb 2013 07:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=530; q=dns/txt; s=iport; t=1360941278; x=1362150878; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ZgrmZIc+y6kTZf/ToSGYM8Phj6maCSlM4z8zMO3QD8o=; b=E7gf11IPj0iNvja1L94LyEhND4It+13WtZk+lwWTVDquT2rNraRJUVXE yZ671QW3B7ELeYnnBPHSKoKaCz3ifVJJBfYC+3f9cwYlEZvAzapKizT8f BrN4jVrONsEBrRV2w4RQm715ErPeF7eUaguN3m3DWcNVSw9sBstmzw7Rq U=; X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; d="scan'208";a="177568484" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 15 Feb 2013 15:14:37 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1FFEbF1009780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Feb 2013 15:14:37 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 09:14:37 -0600 From: "Wojciech Dec (wdec)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? Thread-Index: AQHOCpfuJkmp5jEBbkOX+ZrIkXbXoph5h4aAgAF0+QCAAAmIgIAAAkGAgAAizoD///03gIAAE4YAgAAU0wCAABN+AP//8lkAgAAn/gA= Date: Fri, 15 Feb 2013 15:14:36 +0000 Message-ID: <19F346EB777BEE4CB77DA1A2C56F20B3222D4C@xmb-aln-x05.cisco.com> In-Reply-To: <5EFF550E-3BC1-47B9-849E-B66E1ED2A143@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.55.95.33] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG , Ole Troan , Yong Cui Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 15:14:38 -0000 On 15/02/2013 14:51, "R=E9mi Despr=E9s" wrote: >>We've previously established consensus that MAP supports 1:1 mode (it >>likely happened at the meeting after you bid farewell to the group). >>Suresh can confirm. > >Please understand that "Removing MAP1:1 section" isn't against this (as I >suppose Med and Suresh can confirm too). If the current text is technically flawed, which appears not to be the case, let's fix it (eg propose text). In all other cases, what is the request for? From despres.remi@laposte.net Fri Feb 15 07:17:29 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8831C21F8AB0 for ; Fri, 15 Feb 2013 07:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfzjQ438viu6 for ; Fri, 15 Feb 2013 07:17:29 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 36A6021F8B26 for ; Fri, 15 Feb 2013 07:17:06 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id 07FE87000F7A; Fri, 15 Feb 2013 16:17:06 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id CE7387000F7D; Fri, 15 Feb 2013 16:17:04 +0100 (CET) X-SFR-UUID: 20130215151704845.CE7387000F7D@msfrf2416.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <19F346EB777BEE4CB77DA1A2C56F20B3222D4C@xmb-aln-x05.cisco.com> Date: Fri, 15 Feb 2013 16:17:03 +0100 Message-Id: <663777AD-087B-47B1-90F4-2137C9AA10D6@laposte.net> References: <19F346EB777BEE4CB77DA1A2C56F20B3222D4C@xmb-aln-x05.cisco.com> To: "Wojciech Dec (wdec)" X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG , Ole Troan , Yong Cui Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 15:17:29 -0000 Le 2013-02-15 =E0 16:14, "Wojciech Dec (wdec)" a =E9crit = : >=20 >=20 > On 15/02/2013 14:51, "R=E9mi Despr=E9s" = wrote: >=20 >>> We've previously established consensus that MAP supports 1:1 mode = (it >>> likely happened at the meeting after you bid farewell to the group). >>> Suresh can confirm. >>=20 >> Please understand that "Removing MAP1:1 section" isn't against this = (as I >> suppose Med and Suresh can confirm too). >=20 > If the current text is technically flawed, which appears not to be the > case, let's fix it (eg propose text). > In all other cases, what is the request for? Already explained. End of this thread for me. RD= From iesg-secretary@ietf.org Fri Feb 15 09:33:38 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C92521F8650; Fri, 15 Feb 2013 09:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxP2skCjAass; Fri, 15 Feb 2013 09:33:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062E721F869A; Fri, 15 Feb 2013 09:33:37 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130215173337.16293.74929.idtracker@ietfa.amsl.com> Date: Fri, 15 Feb 2013 09:33:37 -0800 Cc: softwire mailing list , softwire chair , RFC Editor Subject: [Softwires] Document Action: 'Deployment Considerations for Dual-Stack Lite' to Informational RFC (draft-ietf-softwire-dslite-deployment-08.txt) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 17:33:38 -0000 The IESG has approved the following document: - 'Deployment Considerations for Dual-Stack Lite' (draft-ietf-softwire-dslite-deployment-08.txt) as Informational RFC This document is the product of the Softwires Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-deployment/ Technical Summary Dual-stack Lite (DS-Lite) [RFC6333] is a transition technique that enable operators to multiplex public IPv4 addresses while provisioning only IPv6 to users. This document discusses the deployment issues and describes requirements for the deployment and operation of Dual-Stack Lite. Working Group Summary This document was discussed in depth and well-reviewed. WG consensus is strong to publish this document. Document Quality This is deployment discussion rather than a protocol definition, while DS-Lite has been deployed/tested in some production networks. Personnel Softwire co-chair, Yong Cui, is the Document Shepherd. Ralph Droms is the Responsible AD. RFC Editor Note Please make the following changes when this document is published: Section 2.6: OLD: Alternatively, AFTR may perform accounting for IPv4 traffic. However, operators must be aware that this will introduce some challenges especially in DSL deployment. In DSL deployment, the AAA transaction normally happens between the edge router (i.e., Broadband Network Gateway) and AAA server. [RFC6333] does not require the AFTR to interact with the AAA server or edge router. Thus, AFTR may not have the AAA parameters (e.g., Account Session ID) associated to users to generate IPv4 accounting record. The accounting process at the AFTR is only necessary if the operator requires separating per user accounting records for IPv4 and IPv6 traffic. If the per user IPv6 accounting records, collected by the edge router, are sufficient, and the additional complexity of enabling IPv4 accounting at the ATFR is not required. It is important to notice that, since the IPv4 traffic is encapsulated in IPv6 packets, the data collected by the edge router for IPv6 traffic already contain the total amount of traffic (i.e. IPv4 and IPv6). NEW: Alternatively, AFTR may perform accounting for IPv4 traffic. However, operators must be aware that this will introduce some challenges especially in DSL deployment. In DSL deployment, the AAA transaction normally happens between the edge router (i.e., Broadband Network Gateway) and AAA server. [RFC6333] does not require the AFTR to interact with the AAA server or edge router. Thus, AFTR may not have the AAA parameters (e.g., Account Session ID) associated to users to generate IPv4 accounting record. IPv4 traffic accounting at the AFTR is not recommended when the AAA parameters necessary to generate complete IPv4 accounting records are not available. The accounting process at the AFTR is only necessary if the operator requires separating per user accounting records for IPv4 and IPv6 traffic. If the per user IPv6 accounting records, collected by the edge router, are sufficient, and the additional complexity of enabling IPv4 accounting at the ATFR is not required. It is important to notice that, since the IPv4 traffic is encapsulated in IPv6 packets, the data collected by the edge router for IPv6 traffic already contain the total amount of traffic (i.e. IPv4 and IPv6). END In section 3.2.2: OLD: Operators should assign the same IPv4 address (i.e., 192.0.0.2/32) to all AFTRs. IANA allocates 192.0.0.0/29 [RFC6333] Section 5.7 that can be used for this purpose. NEW: Operators should assign the same IPv4 address (e.g., 192.0.0.2/32 [RFC6333]) to all AFTRs. IANA has allocated the 192.0.0.0/29 network prefix to provide IPv4 addresses for this purpose [RFC 6333]. END Section 2.4: OLD: AFTR is a NAT device. It enables multiple users to share a single public IPv4 address. [RFC6269] discusses some considerations when sharing an IPv4 address. When a public IPv4 address is blacklisted by a remote peer, this may affect multiple B4 elements sharing the same IPv4 address. Operators deploying DS-Lite should be aware that Internet hosts may rely solely on source IP address to identify an abusive household and may not be aware that a given single IPv4 address is actually shared by multiple households. A content provider may block services for a shared IPv4 address and this will impact all households sharing this particular IPv4 address. The operator may receive calls of service outage and will need to take appropriate actions. Such corrective actions include but not limited to notifying the content provider to combine the IPv4 address with transport (e.g., TCP) and application protocol (e.g., HTTP) to identify abusive household. [RFC6302]. [I-D.ietf-intarea-nat-reveal-analysis] analyzes different approaches to identify a user in a shared address environment. NEW: AFTR is a NAT device. It enables multiple users and/or hosts to share a single public IPv4 address. [RFC6269] discusses some considerations when sharing an IPv4 address. When a public IPv4 address is blacklisted by a remote peer, this may affect multiple users or hosts. Operators deploying DS-Lite should be aware that Internet hosts may not be aware that a given single IPv4 address is actually shared by multiple users or hosts. A content provider might block services for a shared IPv4 address and this would then impact all users and hosts sharing this particular IPv4 address. The operator would be likely to receive calls related to service outage and would then need to take appropriate corrective actions re-establishing connectivity. END From iesg-secretary@ietf.org Fri Feb 15 09:33:38 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABF621F868D for ; Fri, 15 Feb 2013 09:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3KaqYQL720k; Fri, 15 Feb 2013 09:33:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EC221F86A6; Fri, 15 Feb 2013 09:33:37 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.40 X-IETF-Draft-string: draft-ietf-softwire-dslite-deployment X-IETF-Draft-revision: 08 Message-ID: <20130215173337.16293.38575.idtracker@ietfa.amsl.com> Date: Fri, 15 Feb 2013 09:33:37 -0800 Cc: softwire mailing list , softwire chair , RFC Editor Subject: [Softwires] Document Action: 'Deployment Considerations for Dual-Stack Lite' to Informational RFC (draft-ietf-softwire-dslite-deployment-08.txt) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 17:33:38 -0000 The IESG has approved the following document: - 'Deployment Considerations for Dual-Stack Lite' (draft-ietf-softwire-dslite-deployment-08.txt) as Informational RFC This document is the product of the Softwires Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-deployment/ Technical Summary Dual-stack Lite (DS-Lite) [RFC6333] is a transition technique that enable operators to multiplex public IPv4 addresses while provisioning only IPv6 to users. This document discusses the deployment issues and describes requirements for the deployment and operation of Dual-Stack Lite. Working Group Summary This document was discussed in depth and well-reviewed. WG consensus is strong to publish this document. Document Quality This is deployment discussion rather than a protocol definition, while DS-Lite has been deployed/tested in some production networks. Personnel Softwire co-chair, Yong Cui, is the Document Shepherd. Ralph Droms is the Responsible AD. RFC Editor Note Please make the following changes when this document is published: Section 2.6: OLD: Alternatively, AFTR may perform accounting for IPv4 traffic. However, operators must be aware that this will introduce some challenges especially in DSL deployment. In DSL deployment, the AAA transaction normally happens between the edge router (i.e., Broadband Network Gateway) and AAA server. [RFC6333] does not require the AFTR to interact with the AAA server or edge router. Thus, AFTR may not have the AAA parameters (e.g., Account Session ID) associated to users to generate IPv4 accounting record. The accounting process at the AFTR is only necessary if the operator requires separating per user accounting records for IPv4 and IPv6 traffic. If the per user IPv6 accounting records, collected by the edge router, are sufficient, and the additional complexity of enabling IPv4 accounting at the ATFR is not required. It is important to notice that, since the IPv4 traffic is encapsulated in IPv6 packets, the data collected by the edge router for IPv6 traffic already contain the total amount of traffic (i.e. IPv4 and IPv6). NEW: Alternatively, AFTR may perform accounting for IPv4 traffic. However, operators must be aware that this will introduce some challenges especially in DSL deployment. In DSL deployment, the AAA transaction normally happens between the edge router (i.e., Broadband Network Gateway) and AAA server. [RFC6333] does not require the AFTR to interact with the AAA server or edge router. Thus, AFTR may not have the AAA parameters (e.g., Account Session ID) associated to users to generate IPv4 accounting record. IPv4 traffic accounting at the AFTR is not recommended when the AAA parameters necessary to generate complete IPv4 accounting records are not available. The accounting process at the AFTR is only necessary if the operator requires separating per user accounting records for IPv4 and IPv6 traffic. If the per user IPv6 accounting records, collected by the edge router, are sufficient, and the additional complexity of enabling IPv4 accounting at the ATFR is not required. It is important to notice that, since the IPv4 traffic is encapsulated in IPv6 packets, the data collected by the edge router for IPv6 traffic already contain the total amount of traffic (i.e. IPv4 and IPv6). END In section 3.2.2: OLD: Operators should assign the same IPv4 address (i.e., 192.0.0.2/32) to all AFTRs. IANA allocates 192.0.0.0/29 [RFC6333] Section 5.7 that can be used for this purpose. NEW: Operators should assign the same IPv4 address (e.g., 192.0.0.2/32 [RFC6333]) to all AFTRs. IANA has allocated the 192.0.0.0/29 network prefix to provide IPv4 addresses for this purpose [RFC 6333]. END Section 2.4: OLD: AFTR is a NAT device. It enables multiple users to share a single public IPv4 address. [RFC6269] discusses some considerations when sharing an IPv4 address. When a public IPv4 address is blacklisted by a remote peer, this may affect multiple B4 elements sharing the same IPv4 address. Operators deploying DS-Lite should be aware that Internet hosts may rely solely on source IP address to identify an abusive household and may not be aware that a given single IPv4 address is actually shared by multiple households. A content provider may block services for a shared IPv4 address and this will impact all households sharing this particular IPv4 address. The operator may receive calls of service outage and will need to take appropriate actions. Such corrective actions include but not limited to notifying the content provider to combine the IPv4 address with transport (e.g., TCP) and application protocol (e.g., HTTP) to identify abusive household. [RFC6302]. [I-D.ietf-intarea-nat-reveal-analysis] analyzes different approaches to identify a user in a shared address environment. NEW: AFTR is a NAT device. It enables multiple users and/or hosts to share a single public IPv4 address. [RFC6269] discusses some considerations when sharing an IPv4 address. When a public IPv4 address is blacklisted by a remote peer, this may affect multiple users or hosts. Operators deploying DS-Lite should be aware that Internet hosts may not be aware that a given single IPv4 address is actually shared by multiple users or hosts. A content provider might block services for a shared IPv4 address and this would then impact all users and hosts sharing this particular IPv4 address. The operator would be likely to receive calls related to service outage and would then need to take appropriate corrective actions re-establishing connectivity. END From yiu_lee@cable.comcast.com Fri Feb 15 22:35:06 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35AD21F8671 for ; Fri, 15 Feb 2013 22:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.834 X-Spam-Level: X-Spam-Status: No, score=-103.834 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw04ERgRArp5 for ; Fri, 15 Feb 2013 22:35:06 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id E13ED21F8648 for ; Fri, 15 Feb 2013 22:35:05 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.56527096; Fri, 15 Feb 2013 23:05:04 -0700 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.236]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Sat, 16 Feb 2013 01:35:01 -0500 From: "Lee, Yiu" To: "softwires@ietf.org" Thread-Topic: #21: Fragmentation must not be handled according to RFC 2473 Thread-Index: AQHODA++O8dkewfeOUKlj9Jv8Hv/SA== Date: Sat, 16 Feb 2013 06:35:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [24.40.55.73] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3443823291_1931580" MIME-Version: 1.0 Subject: [Softwires] #21: Fragmentation must not be handled according to RFC 2473 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 06:35:07 -0000 --B_3443823291_1931580 Content-type: multipart/alternative; boundary="B_3443823290_1891268" --B_3443823290_1891268 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I was tasked in IETF-85 to find out why mss rewrite was removed before publishing RFC6333. Here is my finding: Back in 2009-4-7, people in ML reported rewriting MSS would break TCP-AO if TCP option flag set to 0. In IETF-75, Dave Thaler suggested to delete mss rewrite from the draft. The argument was MTU is a generic issue for all tunneling techniques, a separate draft should be written to address it rather than including mss rewrite in a particular draft. Alain asked the WG the question "Whether to remove fragmentation/mss discussion from the document or to keep it". Dave Ward suggested to remove it. Discussion could be found in IETF-75 minute: http://ietf.10.n7.nabble.com/Softwires-WG-meeting-Notes-td112138.html --B_3443823290_1891268 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
I was tasked in IETF-85 to f= ind out why mss rewrite was removed before publishing RFC6333. Here is my fi= nding:

Back in 2009-4-7, people in ML reported rewr= iting MSS would break TCP-AO if TCP option flag set to 0. In IETF-75, Dave T= haler suggested to delete mss rewrite from the draft. The argument was MTU i= s a generic issue for all tunneling techniques, a separate draft should be w= ritten to address it rather than including mss rewrite in a particular draft= . Alain asked the WG the question "Whether to remove fragmentation/mss discu= ssion from the document or to keep it". Dave Ward suggested to remove it.

Discussion could be found in IETF-75 minute:
http://ietf.10.n7.nabble.com/Softwires-WG-meeting-Notes-td112138.html<= /a>



--B_3443823290_1891268-- --B_3443823291_1931580 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVrQYJKoZIhvcNAQcCoIIVnjCCFZoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghMxMIIFNDCCBBygAwIBAgIRAM7oSEiIMzsEorX23NizeFgwDQYJKoZIhvcNAQEFBQAw gZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTIwODI4MDAw MDAwWhcNMTMwODI4MjM1OTU5WjAqMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNv bWNhc3QuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHDnrufxKGEXY2tY 2+i+MaNEyHr3pXNezbD7kR369s9wRlDG37CWNadLlzvfopwUKAV8G9O2nN0mzowP+hH9zZTD yLVnU0RnhS+nv7DI7vUYFciVERZxYKe7XNrX35zzrqZymXnkXoV3hBY7p+vhgurXm9ZEjLvl jDGgmg+/10ivkPhdFHXNgL9P4FApBn0w6TZ2MLrX3LRDEZ5XuhGFKpiTDeAtHKxH6L5mHTBR YCSyrFmuQnXPp2haCKs1vAHGQevtV1A08xW4I6oFGxRWRT81WajcSwxTcuLZ/FZUUqdowYYM EB7ZNWQPrKRRDWnlLnm6eLXM49CBxuvNxYYVowIDAQABo4IB6TCCAeUwHwYDVR0jBBgwFoAU ehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFM9N3LJewpo8EGPrKV/VVnhm+bFUMA4G A1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEE AbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEw KzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAw TjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAC hkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJAYDVR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTANBgkqhkiG9w0BAQUF AAOCAQEARuyzkbVnJsw5cNDfw+QMH7Ei3vd3rLAKihYSfp7e0pjFQbMRsxZ0rGRkBzGEOFF7 YlavQDY7T5NNBdwwt0BsXuJsXcBfS83mB6RzKQh08zcopUopimaJSzQTvjDv1NLu/a3Rdlvn TgMJAXc66FgcSvsjIYoyZ9gwhP9aYMagc/nPc2wLSWD1aYG3hjb73yKeggPyWLLqUDaj1+PW uDHSdy/cly04noEhPLj1JQgd7B2XJUDlwLbbjHsKXCg6CAuMGYBESkKkR+tT0DtdNBiylDvl a06vn8TZIzgKgPnYoekDuQ42796nDEwnAAoSUGCvAUu473nfF4BFWtCIc+6FijCCBRowggQC oAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYw NAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWww HhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09N T0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJKE hFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFAGpDMJ1Zi fxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq1GdvIBOP XDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg7SQfOq9x XwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWSD//gsWD9 Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUswggFHMB8G A1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvGeGNkJ8Ev 4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAECjAI MAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUH AQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1 c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29t MA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF 0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6 L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODu DcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWb CG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+ 83X5f27nMIIEnTCCA4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBv MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBS b290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeuzcFgdbw5ZflKGkei ucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5okHsceqSSqBfy mBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5nNYt54R5p iOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD/BZa rx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO9 4CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAP BgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYI KwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0G CSqGSIb3DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+ eDMPdBa5kYeR9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72s av3xwtHMiV+xfPA+UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUx XsuauZ2UxrmUN3Vy3ET7Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwt P9JgcWDuwnGCDOmINuPaILSjoGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/G HogVMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIG A1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgz OFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFC MSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRk VHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALf3GjPm8gAELTngTlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymU WoCwSXrbLpX9uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6Fq UNzXmk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tk x63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl +mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAd BgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNV BAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJu YWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEw DQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7us QWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw56wwC URQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvCNr4TDea9Y355 e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0cQ+azcgO no4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghdae9C8 x49OhgQxggJAMIICPAIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQQIRAM7oSEiIMzsEorX23NizeFgwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0B CQQxIgQg9VyU1h5cK2VqtUohp1kPyaM1w+C4BIWtG4fY01fay1owGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE2MDYzNDUwWjANBgkqhkiG9w0BAQEF AASCAQAvzJHEju2wSwb7uxc7yhZgVhxN31dgEs4D/vw6uDgdtVppMTMGhAwFlJ5b08xK+NS5 07TckZd7awsWR3cnl0RymOrZKO7UvRZRpy176ggpDkkmZs8AYduDQjX3fcE8GgqM1IVr+/xk 09HYntfwsU4tRQO21WIaaowSmIXpH47LjfwebA8e3lyOFfH7SP2YJ04kzBZ5IrGKuv6DraIk MjUwcRk0KEW5kvhkCVWZ1L+ttLkP5hYTsKqUEKP0Rz9YPIO7Q5txIlMOH0I23XELaqkMk71B WYtb/NubsUBm1iNYHeNYtZzb3kXpCbV9bynasWGvwC+PJm0u5jJSpJFyvrnW --B_3443823291_1931580-- From rajiva@cisco.com Sat Feb 16 14:14:22 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4014E21F8A3D for ; Sat, 16 Feb 2013 14:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAGefBCETVVB for ; Sat, 16 Feb 2013 14:14:17 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 38BCF21F8A35 for ; Sat, 16 Feb 2013 14:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1628; q=dns/txt; s=iport; t=1361052857; x=1362262457; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ojylAaflx+VzM4xLRFjk5enCQtjvdbPsTLKsD9lPshk=; b=hKxMXKP3+rS5QYozTJN+1FrUaGbCunPxOJhWxtxQ24bkzqUysSYqfiWN 1mQG44xZH/KRiKp7kD9HeINxHUV9GEUMdlgPqbBBlBSc4HjYv6s5Dr/gp F3v4iuWOzGMcpV0pLt8OukMxItI1mYdFbAPuNKzYU5AVvy5Y/Ku4hoGpk E=; X-IronPort-AV: E=Sophos;i="4.84,680,1355097600"; d="scan'208";a="177965090" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 16 Feb 2013 22:14:17 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1GMEGGk014955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Feb 2013 22:14:16 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.72]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Sat, 16 Feb 2013 16:14:16 -0600 From: "Rajiv Asati (rajiva)" To: Tom Taylor , Ole Troan Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-map-04.txt Thread-Index: AQHOBE3s5xcpKL9M+EqQH+PScwqof5hs+lcAgAt+e4CABEz4AA== Date: Sat, 16 Feb 2013 22:14:15 +0000 Message-ID: In-Reply-To: <511BCB5F.9070005@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.82.214.29] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8311F34919C1F64C8DBD770FF97EE87E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-04.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 22:14:22 -0000 Ole, Tom,=20 I would suggest fixing port offset to 6 rather than 4, since 0-1023 are the system/reserved ports that should be avoided by default. This also allows increasing the IP address sharing efficiency, suffice to say, as Tom already noted.=20 Pls see RFC6335. Of course, the default value can be changed per deployment needs. > of the cost tradeoff, but what % of BR capacity is likely to be lost if > the PSID does not sit on a nibble boundary? Hmmm=8Anot sure I follow the Q. Why would BR capacity (performance?) be los= t? Cheers, Rajiv -----Original Message----- From: Tom Taylor Date: Wednesday, February 13, 2013 12:20 PM To: Ole Troan Cc: Softwires-wg list Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-04.txt >Fixing port offset to 4 rather than 6 means that an operator needs about >6% more public IPv4 addresses to serve the same population. I'm not sure >of the cost tradeoff, but what % of BR capacity is likely to be lost if >the PSID does not sit on a nibble boundary? > >Tom > >On 06/02/2013 4:48 AM, Ole Troan wrote: >> with this update to the MAP-E revision: >> - reorganized the architecture section to make it cleared what >>applies to shared addresses vs full ipv4 / prefix >> - fixed port offset to 4 (removed port parameters from the base spec) >> - simplified the interface-id text, removed 6052 reference >> >... >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From bingxuere@gmail.com Sat Feb 16 18:04:28 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF56F21F84FF for ; Sat, 16 Feb 2013 18:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.02 X-Spam-Level: X-Spam-Status: No, score=-3.02 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGkM3TxJJYAr for ; Sat, 16 Feb 2013 18:04:28 -0800 (PST) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3BA21F84FB for ; Sat, 16 Feb 2013 18:04:27 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id k14so4981942oag.11 for ; Sat, 16 Feb 2013 18:04:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=USrnBCFbTsYCMV4ENPLOIAXNOyyORHSUiSGLg9F2rO8=; b=dSRCtcRyKuUdXueFS42TcM/gfmYG76hXb1vJhX6AaqtKe1ZTWAUUuJoh0BZgy4ZPLx 9xCL9uIj9WiOWUWPmmi5fVd3Gl36lGQtPQ5dpGCL/gcntedI12xI0NmdUdiVMx41fvmB Xh0l2R4IX2ZZ2c0DEAU5ROklBJltOlmfuBntLLZRHvX189rrckOR8Hwa7UD51SxNjS56 saVcmk3wkUqZD/cpURN2ZrtZ//YBNCOTW1KL3OEL6pqfbSo5RRHRzp5uUjY7YzlrB9yf sPDWqFUtBfZnFQaltjHrXCJWAI2/JnqOLdnTIr0KfYwstI7NDoxJCVvliyT7AfxcTNBo EPIg== X-Received: by 10.60.32.193 with SMTP id l1mr4100265oei.114.1361066667606; Sat, 16 Feb 2013 18:04:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.80.133 with HTTP; Sat, 16 Feb 2013 18:03:47 -0800 (PST) In-Reply-To: <19F346EB777BEE4CB77DA1A2C56F20B3222763@xmb-aln-x05.cisco.com> References: <19F346EB777BEE4CB77DA1A2C56F20B3222763@xmb-aln-x05.cisco.com> From: Qiong Date: Sun, 17 Feb 2013 10:03:47 +0800 Message-ID: To: "Wojciech Dec (wdec)" Content-Type: multipart/alternative; boundary=e89a8fb1f6ca3d01c104d5e2070e Cc: "softwires@ietf.org" , "ot@cisco.com" , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 02:04:28 -0000 --e89a8fb1f6ca3d01c104d5e2070e Content-Type: text/plain; charset=UTF-8 Hi Woj, Please see inline. On Fri, Feb 15, 2013 at 5:03 PM, Wojciech Dec (wdec) wrote: > > It is my opinion that we've discussed this 1:1 mode many many times > before, and at each time concluded that a) it is a natural characteristic > of MAP ii) it would actually require *more text* (and complexity) to > remove it. > Sorry I can hardly find such conclusion. 1) In the current text, the PSID option is only used in this 1:1 mode which will have impact on both DHCPv6 server and CPE. 2) From the testing draft, there is a dedicated parameter "-X" to indicate no embedding EA-bits in IPv6 prefix which is not used in normal MAP-E/MAP-T. So for me, it is hard to say this 1:1 mode is a natural characteristic of MAP. Long long time ago, we spent two days in Beijing Interim meeting to discuss what need to be covered in MAP, what's the motivation and requirement of each functional element, including Encapsulation, Translation, Hub&Sope and Mesh. That comes to be the draft-ietf-softwire-map-00. But now, 1:1 mode was just simply added without any discussion about the motivation, requirement in the working group, and not covered in stateless motivation draft either. It did raise confusion of why this is needed in MAP (two address sharing mechanisms in one solution), and how it should be used. So I suggest to reach consensus on motivation and requirement text first before processing 1:1 mode in MAP. For MAP-base draft, I do think removing 1:1 mode would help MAP to be a more cleaner stateless solution and easy understanding. Best wishes Qiong --e89a8fb1f6ca3d01c104d5e2070e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Woj,

Please se= e inline.

On Fri, Feb 15, 2013 at 5:03 PM= , Wojciech Dec (wdec) <wdec@cisco.com> wrote:

It is my opinion that we've discussed this 1:1 mode many many times
before, and at each time concluded that a) it is a natural characteristic of MAP ii) it would actually require *more text* (and complexity) to
remove it.

Sorry I can hardly fin= d such conclusion.
1) In the current text, the PSID option = is only used in this 1:1 mode which will have impact on both DHCPv6 server = and CPE.
2) From the testing draft, there is a dedicated parameter "= -X" to indicate no embedding EA-bits in IPv6 prefix which is not used = in normal MAP-E/MAP-T.=C2=A0
So for me, it is hard to say t= his 1:1 mode is a natural characteristic of MAP.

Long long time ago, we spent two days in Be= ijing Interim meeting to discuss what need to be covered in MAP, what's= the motivation and requirement of each functional element, including Encap= sulation, Translation, Hub&Sope and Mesh. That comes to be the draft-ie= tf-softwire-map-00.=C2=A0But now, 1:1 mode was just simply added without an= y discussion about the motivation, requirement in the working group, and no= t covered in stateless motivation draft either. It did raise confusion of w= hy this is needed in MAP (two address sharing mechanisms in one solution), = and how it should be used.=C2=A0So I suggest to reach consensus on motivati= on and requirement text first before processing 1:1 mode in MAP.=C2=A0

For MAP-base draft, I do think removing 1:1= mode would help MAP to be a more cleaner stateless solution and easy under= standing.

Best wishes
Qiong

--e89a8fb1f6ca3d01c104d5e2070e-- From fibrib@gmail.com Sun Feb 17 17:07:50 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB14E21F886F for ; Sun, 17 Feb 2013 17:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.09 X-Spam-Level: X-Spam-Status: No, score=-3.09 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlWDsjTus3D0 for ; Sun, 17 Feb 2013 17:07:49 -0800 (PST) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 036C321F87FD for ; Sun, 17 Feb 2013 17:07:48 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id m1so5269382oag.40 for ; Sun, 17 Feb 2013 17:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=U2ahKoemXEcoyIRoa6rzsygl5Fcjmtscz45iV/ejG+k=; b=dcVNnGnqeXWb+uXrMg4clMs7RAaclnlr6V1HmzoFmzBWmFVaXjmkS6CKAJkhjqfDsF 6vYFFHJ7729CsBjN+eMRxbd/n1Hu2+/6/t6a6lnx6gDXMWO3aMsYYk1AWysmchTwTJ85 iaAkjGYfmlE6CU3l7O0tAULu4wfNOMB7dQ+2iqSQX8tap7pbwpuS7YfR7I6YqKauq3N7 c11hbQjRw83Wag06aN7RC4THGDva1fwHjxZdRn7hhkhORMJ4K5obWQlHw0Spn7APPiff koOKu7A+Pcoo81ewfE456YlsFIFj76kGoDA4PIYRgs6N4+H5/s+mzNL51JXxTsqQPGNj KGKw== MIME-Version: 1.0 X-Received: by 10.60.27.228 with SMTP id w4mr5188652oeg.104.1361149668490; Sun, 17 Feb 2013 17:07:48 -0800 (PST) Received: by 10.76.154.8 with HTTP; Sun, 17 Feb 2013 17:07:48 -0800 (PST) In-Reply-To: References: Date: Mon, 18 Feb 2013 10:07:48 +0900 Message-ID: From: Maoke To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=e89a8fb1ea6479fd6804d5f55adf Cc: "softwires@ietf.org" Subject: Re: [Softwires] #21: Fragmentation must not be handled according to RFC 2473 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 01:07:50 -0000 --e89a8fb1ea6479fd6804d5f55adf Content-Type: text/plain; charset=ISO-8859-1 dear Yiu, i support your view on not including mss rewriting as a standard/mandatory way to solve the tunneling MTU issue. however, i have 2 observations: 1. mss rewriting could be an optional workaround for some operators in some circumstances. therefore it is worth implementing, IMHO. 2. regarding the issue of #21, fragmenting in IPv4 stack before entering the MAP module is not equal to the issue of "mss rewriting". MTU discovery can still work and help this functionality. on the other hand, as the fragment happens before the encapsulation, RFC2473 is not involved yet. it is equivalent to having a fragmenting box before the CE. as RFC2473 was written when the stateless mapping was not happening, it is reasonable that we make a new building block for the new demand of supporting anycast BR even when the datagram is to be fragmented. (is this as the same as Remi's proposal?) thanks and regards, maoke 2013/2/16 Lee, Yiu > I was tasked in IETF-85 to find out why mss rewrite was removed before > publishing RFC6333. Here is my finding: > > Back in 2009-4-7, people in ML reported rewriting MSS would break TCP-AO > if TCP option flag set to 0. In IETF-75, Dave Thaler suggested to delete > mss rewrite from the draft. The argument was MTU is a generic issue for all > tunneling techniques, a separate draft should be written to address it > rather than including mss rewrite in a particular draft. Alain asked the WG > the question "Whether to remove fragmentation/mss discussion from the > document or to keep it". Dave Ward suggested to remove it. > > Discussion could be found in IETF-75 minute: > http://ietf.10.n7.nabble.com/Softwires-WG-meeting-Notes-td112138.html > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --e89a8fb1ea6479fd6804d5f55adf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Yiu,

i support your view on not including mss rewriting as a s= tandard/mandatory way to solve the tunneling MTU issue. however, i have 2 o= bservations:

1. mss rewriting could be an optional workaround for so= me operators in some circumstances. therefore it is worth implementing, IMH= O.
2. regarding the issue of #21, fragmenting in IPv4 stack before entering th= e MAP module is not equal to the issue of "mss rewriting". MTU di= scovery can still work and help this functionality. on the other hand, as t= he fragment happens before the encapsulation, RFC2473 is not involved yet. = it is equivalent to having a fragmenting box before the CE. as RFC2473 was = written when the stateless mapping was not happening, it is reasonable that= we make a new building block for the new demand of supporting anycast BR e= ven when the datagram is to be fragmented. (is this as the same as Remi'= ;s proposal?)

thanks and regards,
maoke

2013/2/1= 6 Lee, Yiu <Yiu_Lee@cable.comcast.com>
I was tasked in IETF-85 to find out why mss rewrite was removed= before publishing RFC6333. Here is my finding:

Back in 2009-4-7, people in ML reported rewriting MSS would break TCP-AO if= TCP option flag set to 0. In IETF-75, Dave Thaler suggested to delete mss = rewrite from the draft. The argument was MTU is a generic issue for all tun= neling techniques, a separate draft should be written to address it rather = than including mss rewrite in a particular draft. Alain asked the WG the qu= estion "Whether to remove fragmentation/mss discussion from the docume= nt or to keep it". Dave Ward suggested to remove it.

Discussion could be found in IETF-75 minute:




_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--e89a8fb1ea6479fd6804d5f55adf-- From ot@cisco.com Sun Feb 17 23:32:14 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804C821F8B46 for ; Sun, 17 Feb 2013 23:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.954 X-Spam-Level: X-Spam-Status: No, score=-9.954 tagged_above=-999 required=5 tests=[AWL=-0.424, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zniuyEyuzzk5 for ; Sun, 17 Feb 2013 23:32:13 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id A4C5421F8AD0 for ; Sun, 17 Feb 2013 23:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1888; q=dns/txt; s=iport; t=1361172733; x=1362382333; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Zxs8mucp+/svsjF5YNZHXGZp4aK4ODJgykc4fNxBroo=; b=LOhI5Lke4GVcQtubjK2Yy3C3lPaafY5xcJZLOM1yMoGcUZzjHUyBOFwh 5q3vs7t+CtFrSm2kWQEOKJZp70Hf2rBmTdeEOnOCkenaUt5S1r7GCSZFn iOx9RsEchnQoNXmZQ5k2XByv2A9sEnMlARS/p4n+LrTKTFe78kM4jbaZK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0KAP7XIVGQ/khR/2dsb2JhbABEJ796gQQWc4IfAQEBAwE6PwULC0ZXiCUGvnaPBDMHFoJJYQOSbYM/kFiDCA X-IronPort-AV: E=Sophos;i="4.84,684,1355097600"; d="scan'208";a="11851413" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 18 Feb 2013 07:32:10 +0000 Received: from dhcp-10-61-111-163.cisco.com (dhcp-10-61-111-163.cisco.com [10.61.111.163]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1I7W9J7020649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Feb 2013 07:32:10 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: Date: Sun, 17 Feb 2013 22:06:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <212ED847-153C-491E-BDBE-DDB1D5DE3505@cisco.com> References: To: ian.farrer@telekom.de X-Mailer: Apple Mail (2.1499) Cc: softwires@ietf.org, draft-ietf-softwire-map@tools.ietf.org Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 07:32:14 -0000 Ian, > Assuming that the Unified CPE draft gets adopted by the workgroup, = then > there needs to be alignment of the different drafts reflecting this. >=20 > The unified CPE draft describes how a CPE interprets the presence (or = lack > of) configuration parameters to understand which softwire mode to > configure. If a MAP CE implemented this (to be a 'unified MAP CE'), = then > it would have two ways of configuring 1:1 mode - via the presence of = the > tunnel endpoint address, an IPv4 address (and optionally a restricted = port > range) and also through a BMR with EA=3D0. a MAP CE has only one way of configuring 1:1 mode. > Two ways of configuring the same function doesn't seem like a good = idea, > even if the underlying mechanism that this function is implemented = with is > different. indeed. > So, what I would propose is that EA=3D0 for MAP is not included as a > provisioning option in the MAP draft. If the parameters described in = the > unified CPE draft required for 1:1 mode are configured on the unified = MAP > CE, then it should interpret these to mean EA=3D0 and configure itself > accordingly. a MAP CE will always configure itself with the BMR. that consists of the Rule IPv6 prefix, the Rule IPv4 prefix and the EA = length. from a MAP perspective there is not two ways of doing 1:1 mode. > I also think that it would be cleaner if this 1:1 functionality was > described in a separate document to the current MAP draft. As the 1:1 = mode > functionality of MAP is a big architectural change to the mesh mode > function, it really needs a lot more than 2 paragraphs in order to > describe what it is and how it is used. 1:1 is a configured tunnel with provisioning support. as others have said, that's a simple subset of the mesh functionality. hardly a big architectural change. cheers, Ole= From wdec@cisco.com Mon Feb 18 03:01:48 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9147A21F8859 for ; Mon, 18 Feb 2013 03:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.148 X-Spam-Level: X-Spam-Status: No, score=-110.148 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrYazPRTAM2a for ; Mon, 18 Feb 2013 03:01:47 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC3621F881F for ; Mon, 18 Feb 2013 03:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12713; q=dns/txt; s=iport; t=1361185307; x=1362394907; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=xErn8eVLJ6MdCGEboDdGNwjE2XUI9s7rypRvQ7+l7K4=; b=Zg26fvXbAQH4OXtJOretkhTK+N783FpDhsRdyhy42O5k5RUhv+zSx5Z4 SHbJQomRJecUzYxWMObSZmY0bfdw8WLvrkjvbQ4xzq2kbvt572vyM9KUw yBz8TJttZwKVINAXh5o+/weXKiO14Q3UHDhSzkOSP2yYs9vem2pNKzrMB s=; X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; d="scan'208,217";a="178246637" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 18 Feb 2013 11:01:42 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1IB1gKU030554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Feb 2013 11:01:42 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 05:01:42 -0600 From: "Wojciech Dec (wdec)" To: Qiong , Suresh Krishnan Thread-Topic: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? Thread-Index: AQHOCpfuJkmp5jEBbkOX+ZrIkXbXoph5h4aAgAF0+QCAAAmIgIACr2mAgAI5XgA= Date: Mon, 18 Feb 2013 11:01:41 +0000 Message-ID: <19F346EB777BEE4CB77DA1A2C56F20B3223757@xmb-aln-x05.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.61.86.81] Content-Type: multipart/alternative; boundary="_000_19F346EB777BEE4CB77DA1A2C56F20B3223757xmbalnx05ciscocom_" MIME-Version: 1.0 Cc: "softwires@ietf.org" , "ot@cisco.com" , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 11:01:48 -0000 --_000_19F346EB777BEE4CB77DA1A2C56F20B3223757xmbalnx05ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Qiong, From: Qiong > Date: Sunday, 17 February 2013 03:03 To: Wojciech Dec > Cc: "ian.farrer@telekom.de" >, "ot@cisco.com" <= ot@cisco.com>, "mohamed.boucadair@orange.com" >, "softwires@ietf.org" >, "draft-ietf-softwire-map@tools= .ietf.org" > Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? Hi Woj, Please see inline. On Fri, Feb 15, 2013 at 5:03 PM, Wojciech Dec (wdec) > wrote: It is my opinion that we've discussed this 1:1 mode many many times before, and at each time concluded that a) it is a natural characteristic of MAP ii) it would actually require *more text* (and complexity) to remove it. Sorry I can hardly find such conclusion. 1) In the current text, the PSID option is only used in this 1:1 mode which= will have impact on both DHCPv6 server and CPE. And so? In any scheme where a port assignment is to be made a configuration= component will be involved. 2) From the testing draft, there is a dedicated parameter "-X" to indicate = no embedding EA-bits in IPv6 prefix which is not used in normal MAP-E/MAP-T= . So for me, it is hard to say this 1:1 mode is a natural characteristic of M= AP. The is an artifact of the implementation AFAIK. In fact we have successfull= y used a software version without =96X to test the 1:1 mode. It's also wort= hwhile adding that other implementations never had a =96X parameter, etc, a= nd that in general implementers are free to design and write software as th= ey wish. Long long time ago, we spent two days in Beijing Interim meeting to discuss= what need to be covered in MAP, what's the motivation and requirement of e= ach functional element, including Encapsulation, Translation, Hub&Sope and = Mesh. That comes to be the draft-ietf-softwire-map-00. But now, 1:1 mode wa= s just simply added without any discussion about the motivation, requiremen= t in the working group, and not covered in stateless motivation draft eithe= r. It did raise confusion of why this is needed in MAP (two address sharing= mechanisms in one solution), and how it should be used. So I suggest to re= ach consensus on motivation and requirement text first before processing 1:= 1 mode in MAP. Update: in Atlanta we discussed the technology (the chairs were present too= ). It was rather clear that 1:1 mode is inherent in MAP and the Lw46 solut= ion. We also had a all-parties meeting in Ottawa on that topic, where a sim= ilar conclusion was reached. Thus, I'll continue to assert that 1:1 was po= ssible in MAP all along (although not exemplified to start with). We come to the IETF to create standards that solve more than just point pro= blems, and to discuss how we can do so in a manner that minimizes the numbe= r of solutions - I appreciate that you have a problem with that because you= r stance appears to indicate that you need a totally separate solution for = a point problem. With all due respect, but taking on such a purely rhetori= cal point as justification is not really how to get a technical standard do= ne IMO. For MAP-base draft, I do think removing 1:1 mode would help MAP to be a mor= e cleaner stateless solution and easy understanding. We've been there before: Stateless doesn't exist. All solutions need config= uration. But thanks anyway. It is now clear that what you are proposing is = that MAP be technically described as not handling 1:1 mode. There appears to be 0 technical merit to that argument as far as I can tell= . The only argument appears to be that you don't care about the problem, bu= t rather about having prefer to a standalone solution draft. Regards, Woj.. Best wishes Qiong --_000_19F346EB777BEE4CB77DA1A2C56F20B3223757xmbalnx05ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9AF94A78A667F844BF21B8672CCA8A7C@cisco.com> Content-Transfer-Encoding: quoted-printable
Hello Qiong,

From: Qiong <bingxuere@gmail.com>
Date: Sunday, 17 February 2013 03:0= 3
To: Wojciech Dec <wdec@cisco.com>
Cc: "ian.farrer@telekom.de" <ian.farrer@telekom.de>, "ot@cisco.com" <ot@c= isco.com>, "mohamed.boucadair@or= ange.com" <moha= med.boucadair@orange.com>, "softwires@ietf.org" <s= oftwires@ietf.org>, "draft-ietf= -softwire-map@tools.ietf.org" <draft-ietf-softwire-map@tools.ietf.org> Subject: Re: [Softwires] [softwire]= #25: Maintain or remove MAP1:1 Mode?

Hi Woj,

Please see inline.

On Fri, Feb 15, 2013 at 5:03 PM, Wojciech Dec (w= dec) <wdec@cisco.com&= gt; wrote:

It is my opinion that we've discussed this 1:1 mode many many times
before, and at each time concluded that a) it is a natural characteristic of MAP ii) it would actually require *more text* (and complexity) to
remove it.

Sorry I can hardly find such conclusion.
1) In the current text, the PSID option is only used in thi= s 1:1 mode which will have impact on both DHCPv6 server and CPE.

And so? In any scheme where a port assignment is to be made a configur= ation component will be involved.

2) From the testing draft, there is a dedicated parameter &= quot;-X" to indicate no embedding EA-bits in IPv6 prefix which is not = used in normal MAP-E/MAP-T. 
So for me, it is hard to say this 1:1 mode is a natural cha= racteristic of MAP.

The is an artifact of the implementation AFAIK. In fact we have succes= sfully used a software version without =96X to test the 1:1 mode. It's also= worthwhile adding that other implementations never had a =96X parameter, e= tc, and that in general implementers are free to design and write software as they wish.


Long long time ago, we spent two days in Beijing Interim me= eting to discuss what need to be covered in MAP, what's the motivation and = requirement of each functional element, including Encapsulation, Translatio= n, Hub&Sope and Mesh. That comes to be the draft-ietf-softwire-map-00. But now, 1:1 mode was just simply = added without any discussion about the motivation, requirement in the worki= ng group, and not covered in stateless motivation draft either. It did rais= e confusion of why this is needed in MAP (two address sharing mechanisms in one solution), and how it should be= used. So I suggest to reach consensus on motivation and requirement t= ext first before processing 1:1 mode in MAP. 

Update: in Atlanta we discussed the technology (the chairs were presen= t too). It was  rather clear that 1:1 mode is inherent in MAP and the = Lw46 solution. We also had a all-parties meeting in Ottawa on that topic, w= here a similar conclusion was reached. Thus,  I'll continue to assert that 1:1 was possible in MAP all along= (although not exemplified to start with).

We come to the IETF to create standards that solve more than just poin= t problems, and to discuss how we can do so in a manner that minimizes the = number of solutions - I appreciate that you have a problem with that becaus= e your stance appears to indicate that you need a totally separate solution for a point problem.  With = all due respect, but taking on such a purely rhetorical point as justificat= ion is not really how to get a technical standard done IMO.


For MAP-base draft, I do think removing 1:1 mode would help= MAP to be a more cleaner stateless solution and easy understanding.

We've been there before: Stateless doesn't exist. All solutions need c= onfiguration. But thanks anyway. It is now clear that what you are pro= posing is that MAP be technically described as not handling 1:1 mode.
There appears to be 0 technical merit to that argument as far as I can= tell. The only argument appears to be that you don't care about the proble= m, but rather about having prefer to a standalone solution draft. 

Regards,
Woj..


Best wishes
Qiong

 --_000_19F346EB777BEE4CB77DA1A2C56F20B3223757xmbalnx05ciscocom_-- From tom.taylor.stds@gmail.com Mon Feb 18 05:48:12 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D72621F88D8 for ; Mon, 18 Feb 2013 05:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4ucQzyItreH for ; Mon, 18 Feb 2013 05:48:12 -0800 (PST) Received: from mail-ia0-x231.google.com (ia-in-x0231.1e100.net [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id EF5CC21F8800 for ; Mon, 18 Feb 2013 05:48:11 -0800 (PST) Received: by mail-ia0-f177.google.com with SMTP id o25so397313iad.22 for ; Mon, 18 Feb 2013 05:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=MghGKP4nPEyiH3HCiWphwtajNT6NyPhTUoGbdBmeuBY=; b=IvH4AJF7jDI4TtrtQs++mdYFoiZok7/JX3Z1aZQajTag4K7Mo7HtqquOmjPvuJAST9 8VyRaJWLqUO5eGNcjyZ/hhaOQFKfJmEiJYxujFPScIGRYK/sa8Z7B7o9M34zcXAWjp2v qrsGKgZiJS/jR5rxau+ZixkogiSdmmm8BKIqw0JyO1DAzEMtI+ahqxIwbjRUxFcd0p2F 2BE8PO3/FMvy9ID4kNzyKDUDbmP3RwECLDquSmiNq6sioZk3WiRN8dwy5vvmsldPDTBd zsa5j54YefS6aDQ9pegAuA86V2nDLUwU3xZXfoPJ8Vr8GqfbZpe3y92rSGpXiqx2lRwZ +ngg== X-Received: by 10.50.33.203 with SMTP id t11mr6516433igi.97.1361195291650; Mon, 18 Feb 2013 05:48:11 -0800 (PST) Received: from [127.0.0.1] (dsl-207-112-82-191.tor.primus.ca. [207.112.82.191]) by mx.google.com with ESMTPS id 3sm2794915igp.9.2013.02.18.05.48.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Feb 2013 05:48:10 -0800 (PST) Message-ID: <51223119.3030101@gmail.com> Date: Mon, 18 Feb 2013 08:48:09 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130218-0, 18/02/2013), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Clarification of a point in Public-4over6-04 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 13:48:12 -0000 The current version of the public 4over6 draft says that the first step in provisioning is to provide an IPv6 address to the 4over6 CE. Do you truly mean *address*, or do you mean IPv6 prefix. Correct me if I'm wrong, but I could see either as feasible. Tom Taylor From despres.remi@laposte.net Mon Feb 18 06:04:30 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B6521F886B for ; Mon, 18 Feb 2013 06:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-I2+7M3HIvl for ; Mon, 18 Feb 2013 06:04:29 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 741A121F8810 for ; Mon, 18 Feb 2013 06:04:28 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id 7EA2B7000156; Mon, 18 Feb 2013 15:04:27 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id 977497000142; Mon, 18 Feb 2013 15:04:25 +0100 (CET) X-SFR-UUID: 20130218140425620.977497000142@msfrf2319.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 18 Feb 2013 15:04:25 +0100 Message-Id: References: <19F346EB777BEE4CB77DA1A2C56F20B3222763@xmb-aln-x05.cisco.com> To: Suresh Krishnan , Yong Cui X-Mailer: Apple Mail (2.1499) Content-Type: multipart/alternative; boundary="Apple-Mail=_6847DA51-69B0-469C-A0C9-8387719F2761" Cc: Softwires WG , Ole Troan Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 14:04:30 -0000 --Apple-Mail=_6847DA51-69B0-469C-A0C9-8387719F2761 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 2013-02-17 03:03, Qiong : ... > It is my opinion that we've discussed this 1:1 mode many many times > before, and at each time concluded that a) it is a natural = characteristic > of MAP ii) it would actually require *more text* (and complexity) to > remove it. >=20 > Sorry I can hardly find such conclusion. +1 > 1) In the current text, the PSID option is only used in this 1:1 mode = which will have impact on both DHCPv6 server and CPE. Existence in MAP of a DHCPv6 option whose only purpose is 1:1 is a PROOF = that, contrary to a superficial belief, 1:1 isn't a "natural = characteristic" of MAP. =20 > 2) =46rom the testing draft, there is a dedicated parameter "-X" to = indicate no embedding EA-bits in IPv6 prefix which is not used in normal = MAP-E/MAP-T.=20 > So for me, it is hard to say this 1:1 mode is a natural characteristic = of MAP. > Long long time ago, we spent two days in Beijing Interim meeting to = discuss what need to be covered in MAP, what's the motivation and = requirement of each functional element, including Encapsulation, = Translation, Hub&Sope and Mesh. That comes to be the = draft-ietf-softwire-map-00. But now, 1:1 mode was just simply added = without any discussion about the motivation, requirement in the working = group, and not covered in stateless motivation draft either. Accurate summary of what happened. I hope the editor will accept to remain neutral, and have in the draft = intended for WG last call nothing more than conclusions reached in the = WG s a whole. Regards, RD > It did raise confusion of why this is needed in MAP (two address = sharing mechanisms in one solution), and how it should be used. So I = suggest to reach consensus on motivation and requirement text first = before processing 1:1 mode in MAP.=20 >=20 > For MAP-base draft, I do think removing 1:1 mode would help MAP to be = a more cleaner stateless solution and easy understanding. >=20 > Best wishes > Qiong >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail=_6847DA51-69B0-469C-A0C9-8387719F2761 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii bingxuere@gmail.com> = :
...
It is my opinion that we've discussed this 1:1 mode many many times
before, and at each time concluded that a) it is a natural = characteristic
of MAP ii) it would actually require *more text* (and complexity) to
remove it.

Sorry I can = hardly find such = conclusion.

+1

1) In = the current text, the PSID option is only used in this 1:1 mode which = will have impact on both DHCPv6 server and = CPE.

Existen= ce in MAP of a DHCPv6 option whose only purpose is 1:1 is a PROOF that, = contrary to a superficial belief, 1:1 isn't a "natural characteristic" = of MAP.

 
2) =46rom the testing draft, there is a dedicated = parameter "-X" to indicate no embedding EA-bits in IPv6 prefix which is = not used in normal MAP-E/MAP-T. 
So for me, it = is hard to say this 1:1 mode is a natural characteristic of = MAP.

Long long time ago, we spent two = days in Beijing Interim meeting to discuss what need to be covered in = MAP, what's the motivation and requirement of each functional element, = including Encapsulation, Translation, Hub&Sope and Mesh. That comes = to be the draft-ietf-softwire-map-00. But now, 1:1 mode was just = simply added without any discussion about the motivation, requirement in = the working group, and not covered in stateless motivation draft either. =

Accurate summary of = what happened.

I hope the editor will = accept to remain neutral, and have in the draft intended for WG last = call nothing more than conclusions reached in the WG s a = whole.

Regards,
RD


It did raise confusion of why this = is needed in MAP (two address sharing mechanisms in one solution), and = how it should be used. So I suggest to reach consensus on = motivation and requirement text first before processing 1:1 mode in = MAP. 

For MAP-base draft, I do think = removing 1:1 mode would help MAP to be a more cleaner stateless solution = and easy understanding.

Best wishes
Qiong

_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= --Apple-Mail=_6847DA51-69B0-469C-A0C9-8387719F2761-- From yong@csnet1.cs.tsinghua.edu.cn Mon Feb 18 07:06:33 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CBF21F8BD7 for ; Mon, 18 Feb 2013 07:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kytZdc8SQ-iJ for ; Mon, 18 Feb 2013 07:06:31 -0800 (PST) Received: from mail.csnet1.cs.tsinghua.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF9D21F8BBB for ; Mon, 18 Feb 2013 07:05:39 -0800 (PST) Received: from [192.168.0.100] (unknown [124.126.164.156]) by mail.csnet1.cs.tsinghua.edu.cn (Tsinghua University (Postfix)) with ESMTPA id A266114A8020; Mon, 18 Feb 2013 22:53:45 +0800 (CST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 18 Feb 2013 23:05:22 +0800 From: Yong Cui To: Tom Taylor , Softwires Message-ID: Thread-Topic: [Softwires] Clarification of a point in Public-4over6-04 In-Reply-To: <51223119.3030101@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Softwires] Clarification of a point in Public-4over6-04 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 15:06:33 -0000 Hi Tom, Public 4over6 employs DHCPv6 to get/produce an IPv6 address as the first step. Because the CE's IPv4 address is independent to IPv6, so Public 4over6 does not care the ipv6 address allocation process in DHCPv6. In other words, it should support both IPv6 prefix and an exact address. Yong -----Original Message----- From: Tom Taylor Date: Mon, 18 Feb 2013 08:48:09 -0500 To: Softwires Subject: [Softwires] Clarification of a point in Public-4over6-04 >The current version of the public 4over6 draft says that the first step >in provisioning is to provide an IPv6 address to the 4over6 CE. > >Do you truly mean *address*, or do you mean IPv6 prefix. Correct me if >I'm wrong, but I could see either as feasible. > >Tom Taylor >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires > From tom.taylor.stds@gmail.com Mon Feb 18 08:40:32 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCED21F8C2F for ; Mon, 18 Feb 2013 08:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK2iU1ga74kG for ; Mon, 18 Feb 2013 08:40:31 -0800 (PST) Received: from mail-ia0-x229.google.com (ia-in-x0229.1e100.net [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9202721F8AD6 for ; Mon, 18 Feb 2013 08:40:31 -0800 (PST) Received: by mail-ia0-f169.google.com with SMTP id j5so5418048iaf.0 for ; Mon, 18 Feb 2013 08:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=FPhnFvYsE9odb1f6oxwk64Bkml/zcg9+5odE8Hucr7I=; b=xYtQB25xuMFDz0bAeF13g0a6DwFA4+MgHuxSM2xyjgMBhTrUNNR/pRQR6GB34Gg+aB FJ62W2Cx3tzL+JKTqVrtBWyvMKk9vT+UfW0WJMAKJrXm7U1UVo3dQViIIWOroZt4Ty7a gRBMK/vhy1bjGZ8Sf1PKUe0RRFrRXYt1563l4eM10Gm7VdvsD9AapJg9j8cF3SX/cppC S8MFlH8YdOpHQnl1+O/ESgKeZmBkS0KRgcOFrcm1U+SW36AyoPtMn5TjbYqZbplVV+LL rASct9U1hBRTlTfAoJcnWj6uhFGoi14XMpLpvIZKGSQABlPbFUm2+xU26qmVGPjnDVSX lmYA== X-Received: by 10.42.81.148 with SMTP id z20mr6226107ick.5.1361205631120; Mon, 18 Feb 2013 08:40:31 -0800 (PST) Received: from [127.0.0.1] (dsl-207-112-82-191.tor.primus.ca. [207.112.82.191]) by mx.google.com with ESMTPS id a3sm9284365igq.5.2013.02.18.08.40.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Feb 2013 08:40:30 -0800 (PST) Message-ID: <5122597C.8080004@gmail.com> Date: Mon, 18 Feb 2013 11:40:28 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130218-0, 18/02/2013), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Port set algorithm for LW4o6 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 16:40:32 -0000 Would it be possible to specify the same port set algorithm in LW4o6 as in MAP-E? This would simplify the description of the unified CPE. The effect on security of using a deterministic algorithm for the complete set (but not precluding random assignment within that set) would probably be minimal. Tom Taylor From internet-drafts@ietf.org Mon Feb 18 11:38:04 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCD821F8A85; Mon, 18 Feb 2013 11:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2n7LfzXXHIH; Mon, 18 Feb 2013 11:38:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D42B21F8A89; Mon, 18 Feb 2013 11:38:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130218193804.1311.37799.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 11:38:04 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-dhcp-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 19:38:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : DHCPv6 Options for Mapping of Address and Port Author(s) : Tomasz Mrugalski Ole Troan Congxiao Bao Wojciech Dec Leaf Y. Yeh Xiaohong Deng Filename : draft-ietf-softwire-map-dhcp-02.txt Pages : 22 Date : 2013-02-18 Abstract: This document specifies DHCPv6 options for the provisioning of Mapping of Address and Port (MAP) Customer Edge (CE) devices, based on the MAP paramaters defined in [I-D.ietf-softwire-map]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-dhcp-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Feb 18 11:38:30 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BB921F8B61; Mon, 18 Feb 2013 11:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dwDIoa5FeoO; Mon, 18 Feb 2013 11:38:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC7F21F8BEB; Mon, 18 Feb 2013 11:38:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130218193826.6349.65053.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 11:38:26 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-t-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 19:38:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Mapping of Address and Port using Translation (MAP-T) Author(s) : Xing Li Congxiao Bao Wojciech Dec Ole Troan Satoru Matsushima Tetsuya Murakami Filename : draft-ietf-softwire-map-t-01.txt Pages : 33 Date : 2013-02-18 Abstract: This document specifies the "Mapping of Address and Port" double stateless NAT64 translation based solution (MAP-T) for providing shared or uniquely addressed IPv4 device connectivity to and across an IPv6 domain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-t There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-t-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-t-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ted.Lemon@nominum.com Mon Feb 18 11:57:17 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C2121F8C7E for ; Mon, 18 Feb 2013 11:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.583 X-Spam-Level: X-Spam-Status: No, score=-106.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUzDV5DW1bZT for ; Mon, 18 Feb 2013 11:57:16 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 7B09621F8C68 for ; Mon, 18 Feb 2013 11:57:15 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUSKHlwd/3ON8Sl0O58sQm7+PLi+ZIBrW@postini.com; Mon, 18 Feb 2013 11:57:15 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 39376F805D for ; Mon, 18 Feb 2013 11:57:11 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2F97F190043; Mon, 18 Feb 2013 11:57:11 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 11:57:11 -0800 From: Ted Lemon To: Tom Taylor Thread-Topic: [Softwires] Port set algorithm for LW4o6 Thread-Index: AQHODfatdkJR6vPVOEuXgVBEZdFI+piAjnIA Date: Mon, 18 Feb 2013 19:57:10 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074749363E@mbx-01.win.nominum.com> References: <5122597C.8080004@gmail.com> In-Reply-To: <5122597C.8080004@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] Port set algorithm for LW4o6 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 19:57:17 -0000 On Feb 18, 2013, at 11:40 AM, Tom Taylor wrote: > The effect on security of using a deterministic algorithm for the complet= e set (but not precluding random assignment within that set) would probably= be minimal. As close to zero as to not matter, I think. From mohamed.boucadair@orange.com Tue Feb 19 06:06:12 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623C021F8CF2 for ; Tue, 19 Feb 2013 06:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtIOm0shJkuw for ; Tue, 19 Feb 2013 06:06:11 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 69FBB21F8CED for ; Tue, 19 Feb 2013 06:06:11 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 7C2A22648EC; Tue, 19 Feb 2013 15:06:10 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6303327C078; Tue, 19 Feb 2013 15:06:10 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 19 Feb 2013 15:06:10 +0100 From: To: Tom Taylor , Softwires Date: Tue, 19 Feb 2013 15:06:09 +0100 Thread-Topic: [Softwires] Port set algorithm for LW4o6 Thread-Index: Ac4N9q2SBbDwlFQ9Qpm6f07dzqijoQAs5PZg Message-ID: <94C682931C08B048B7A8645303FDC9F36EB29BACB0@PUEXCB1B.nanterre.francetelecom.fr> References: <5122597C.8080004@gmail.com> In-Reply-To: <5122597C.8080004@gmail.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.19.135417 Subject: Re: [Softwires] Port set algorithm for LW4o6 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 14:06:12 -0000 Hi Tom, You may be interested in reading this document: http://tools.ietf.org/html/= draft-bsd-softwire-stateless-port-index-analysis-00, in particular: In each analyzed port derivation algorithm, an attacker may implement a redirection loop to detect a significant amount of allowed ports. For all monotonously scattered schemes, the whole Port-Set may be deduced by extrapolation while this is not applicable for contiguous port ranges (because no information about port bounds is leaked in the IPv4-translatable IPv6 address). Cheers, Med=20 >-----Message d'origine----- >De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la part de Tom Taylor >Envoy=E9 : lundi 18 f=E9vrier 2013 17:40 >=C0 : Softwires >Objet : [Softwires] Port set algorithm for LW4o6 > >Would it be possible to specify the same port set algorithm in=20 >LW4o6 as=20 >in MAP-E? This would simplify the description of the unified CPE. The=20 >effect on security of using a deterministic algorithm for the complete=20 >set (but not precluding random assignment within that set) would=20 >probably be minimal. > >Tom Taylor >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires >= From Ted.Lemon@nominum.com Tue Feb 19 06:23:48 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB0721F8DC3 for ; Tue, 19 Feb 2013 06:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.583 X-Spam-Level: X-Spam-Status: No, score=-106.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5M8zkUoMKP0 for ; Tue, 19 Feb 2013 06:23:46 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 79DE721F8D09 for ; Tue, 19 Feb 2013 06:23:44 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUSOK8EKEUB4hh7yS35ccH4DqnahUo2X4@postini.com; Tue, 19 Feb 2013 06:23:45 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 97A64F8073 for ; Tue, 19 Feb 2013 06:23:44 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 88BEF190043; Tue, 19 Feb 2013 06:23:44 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 06:23:44 -0800 From: Ted Lemon To: " " Thread-Topic: [Softwires] Port set algorithm for LW4o6 Thread-Index: AQHODfatdkJR6vPVOEuXgVBEZdFI+piBvreAgAAE6IA= Date: Tue, 19 Feb 2013 14:23:43 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747494A85@mbx-01.win.nominum.com> References: <5122597C.8080004@gmail.com> <94C682931C08B048B7A8645303FDC9F36EB29BACB0@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB29BACB0@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0672D2292351B94A880BA789FDD7E139@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] Port set algorithm for LW4o6 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 14:23:48 -0000 On Feb 19, 2013, at 9:06 AM, wrote: > In each analyzed port derivation algorithm, an attacker may implement > a redirection loop to detect a significant amount of allowed ports. > For all monotonously scattered schemes, the whole Port-Set may be > deduced by extrapolation while this is not applicable for contiguous > port ranges (because no information about port bounds is leaked in > the IPv4-translatable IPv6 address). This seems like massive overkill. The attacker can just ask someone who's= connected to the network what port set algorithm is in use. Then, given = one known port, all other ports for that host are known. Keeping the loca= l port set allocation algorithm secret would be impossible for an ISP, and = pretty difficult even for an enterprise, since some machine at the enterpri= se is probably 0wned by a botnet. From sunqi.csnet.thu@gmail.com Tue Feb 19 07:26:03 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C6521F8C96 for ; Tue, 19 Feb 2013 07:26:03 -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=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o87uBWJdfRBK for ; Tue, 19 Feb 2013 07:26:02 -0800 (PST) Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA2121F8C22 for ; Tue, 19 Feb 2013 07:26:01 -0800 (PST) Received: by mail-da0-f43.google.com with SMTP id u36so3070447dak.16 for ; Tue, 19 Feb 2013 07:26:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=NGSuXWmnJsLdUB24DBA9JRp/vPHpeUzlx2OrMybNd/0=; b=FbLDfF5JDmxmdUJmx2Neg7VBDQlsRNViRq14Jwugcc/el21chI38PY3n/yCZsZPr1i hERP/vEwgH3COU+9MRyFFAFQ0hnxzQ2vRmM/XanvG8rH8ECcQnLWmuyPKLTglvFJVdx+ mgBpewsFmgvL2oySoMc84RS9CJEDizLTYyk1gsInaFlRwr6acc9VAGh/4sjINyfJePig wjX0Sr2zxB9hOtXJ7tEscd9FPxOsyrBL4VEz1QaVznabsYu1M2xmK6WgF7cFWRPNDsFk iI84kFLGN6JJM/aOhIWp4Tsl+OT4Q0HYiB94zep7zcpP7EDn38i3Rph6T19J44Q7Bl1e XVYQ== X-Received: by 10.66.81.231 with SMTP id d7mr46403333pay.27.1361287561695; Tue, 19 Feb 2013 07:26:01 -0800 (PST) Received: from [192.168.0.102] ([27.194.229.3]) by mx.google.com with ESMTPS id d8sm107805668pax.23.2013.02.19.07.25.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 07:26:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-728254118 From: Qi Sun In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB29BACB0@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 19 Feb 2013 23:25:43 +0800 Message-Id: References: <5122597C.8080004@gmail.com> <94C682931C08B048B7A8645303FDC9F36EB29BACB0@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: Softwires Subject: Re: [Softwires] Port set algorithm for LW4o6 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 15:26:03 -0000 --Apple-Mail-1-728254118 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Med, Embedding IPv4 address and port set in IPv6 address is a kind of port = set algorithm as well. The attacker can also deduce the port set once = the embedding algorithm is learned. IMHO, this may not increase security = comparing to other port set allocation algorithms. Now that the effect = on security would be minimal (at lease in my opinion), more attention = can be paid to the simplicity and less modification to the current = Internet elements.=20 Please correct me if my understanding is wrong :) Best Regards, Qi Sun On 2013-2-19, at =E4=B8=8B=E5=8D=8810:06, = wrote: > Hi Tom, >=20 > You may be interested in reading this document: = http://tools.ietf.org/html/draft-bsd-softwire-stateless-port-index-analysi= s-00, in particular: >=20 > In each analyzed port derivation algorithm, an attacker may = implement > a redirection loop to detect a significant amount of allowed ports. > For all monotonously scattered schemes, the whole Port-Set may be > deduced by extrapolation while this is not applicable for contiguous > port ranges (because no information about port bounds is leaked in > the IPv4-translatable IPv6 address). >=20 > Cheers, > Med=20 >=20 >> -----Message d'origine----- >> De : softwires-bounces@ietf.org=20 >> [mailto:softwires-bounces@ietf.org] De la part de Tom Taylor >> Envoy=C3=A9 : lundi 18 f=C3=A9vrier 2013 17:40 >> =C3=80 : Softwires >> Objet : [Softwires] Port set algorithm for LW4o6 >>=20 >> Would it be possible to specify the same port set algorithm in=20 >> LW4o6 as=20 >> in MAP-E? This would simplify the description of the unified CPE. The=20= >> effect on security of using a deterministic algorithm for the = complete=20 >> set (but not precluding random assignment within that set) would=20 >> probably be minimal. >>=20 >> Tom Taylor >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-1-728254118 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear = Med,

Embedding IPv4 address and = port set in IPv6 address is a kind of port set algorithm as well. The = attacker can also deduce the port set once the embedding algorithm is = learned. IMHO, this may not increase security comparing to other port = set allocation algorithms. Now that the effect on security would be = minimal (at lease in my opinion), more attention can be paid to the = simplicity and less modification to the current Internet = elements. 

Please correct me if my = understanding is wrong :)

Best Regards,
Qi = Sun

Hi Tom,

You may be interested in reading this = document: http://tools.ietf.org/html/draft-bsd-softwire-stateless-port= -index-analysis-00,  in particular:

  In each = analyzed port derivation algorithm, an attacker may implement
=   a redirection loop to detect a significant amount of allowed = ports.
  For all monotonously scattered schemes, the whole = Port-Set may be
  deduced by extrapolation while this is = not applicable for contiguous
  port ranges (because no = information about port bounds is leaked in
  the = IPv4-translatable IPv6 address).

Cheers,
Med =

-----Message = d'origine-----
De : softwires-bounces@ietf.org =
[mailto:softwires-bounces@ietf.org] De la part de Tom = Taylor
Envoy=C3=A9 : lundi 18 = f=C3=A9vrier 2013 17:40
=C3=80 = : Softwires
Objet : = [Softwires] Port set algorithm for LW4o6

Would it be = possible to specify the same port set algorithm in =
LW4o6 as =
in MAP-E? This would simplify = the description of the unified CPE. The
effect on security of using a deterministic algorithm for = the complete
set (but not = precluding random assignment within that set) would =
probably be = minimal.

Tom = Taylor
_______________________________________________
Softwires mailing = list
Softwires@ietf.org
=
https://www.ietf.= org/mailman/listinfo/softwires

___________________________________________= ____
Softwires mailing list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= = --Apple-Mail-1-728254118-- From suresh.krishnan@ericsson.com Tue Feb 19 20:42:06 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3108D21F886A for ; Tue, 19 Feb 2013 20:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Myj1ZgoKkUkw for ; Tue, 19 Feb 2013 20:42:05 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B2B7321F8855 for ; Tue, 19 Feb 2013 20:42:05 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-a7-5124541cb04c Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 17.B2.31450.C1454215; Wed, 20 Feb 2013 05:42:05 +0100 (CET) Received: from eusaamw0707.eamcs.ericsson.se (147.117.20.32) by EUSAAHC006.ericsson.se (147.117.188.90) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 19 Feb 2013 23:42:04 -0500 Received: from [164.48.125.9] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 19 Feb 2013 23:42:03 -0500 Message-ID: <51245381.3070205@ericsson.com> Date: Tue, 19 Feb 2013 23:39:29 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires WG X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyuXRPlK5siEqgQed3PosfW5It3iydw25x eNlWJout3bEOLB5Tfm9k9Viy5CeTx+sD81k9jn9+yxzAEsVlk5Kak1mWWqRvl8CVseSJesFN xoqP356yNzCuY+xi5OCQEDCR+L8vqouRE8gUk7hwbz1bFyMXh5DAEUaJaX/vMkI4uxklXu1a xwLhbGaUmLCpnxGkhVdAW+La2pfsIDaLgKrEo7/PwGw2oKkbdn5mArFFBcIkel+fg6oXlDg5 8wkLiC0CVP9k5wM2EJtZIFei8esMsLiwgLPEiwNNzBDXiUusecMBUaInMeVqCyOELS+x/e0c ZhBbSEBTYuua76wTGAVnIdkwC0nLLCQtCxiZVzFylBanluWmGxlsYgSG7TEJNt0djHteWh5i lOZgURLnDXK9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMdJugkj0v7gHRtwzwm//OD7n jNUTw/avR+Siat57XXs7t4D34M1zpcU+Lnverb1cX9jv1PX1fgc/j25m4V3F7tdt7h8LLTSX 7Ei4/IT7878jFZdMrd0efWD//lsnQ+2dTtjk0xbHXLdkfY1rPHymT5Nj0y4tiX3rVgtquXv5 BZ2af1TnbvPKLUosxRmJhlrMRcWJAHM2xAgpAgAA Cc: Yong Cui , Ralph Droms Subject: [Softwires] Adoption of draft-bfmk-softwire-unified-cpe-02 as wg draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 04:42:06 -0000 Hi all, The adoption call on the mailing list has demonstrated consensus to adopt this draft as a wg draft. Authors, please resubmit this draft as draft-ietf-softwire-unified-cpe-00. Regards Suresh & Yong From mohamed.boucadair@orange.com Tue Feb 19 22:42:28 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B533421F8949 for ; Tue, 19 Feb 2013 22:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-QAU4LNgKsN for ; Tue, 19 Feb 2013 22:42:28 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 04B4321F8947 for ; Tue, 19 Feb 2013 22:42:27 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id EEB1A264981 for ; Wed, 20 Feb 2013 07:42:25 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D675623808F for ; Wed, 20 Feb 2013 07:42:25 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 20 Feb 2013 07:42:25 +0100 From: To: Softwires Date: Wed, 20 Feb 2013 07:42:25 +0100 Thread-Topic: draft-ietf-softwire-dslite-multicast Thread-Index: Ac4PNXFdrpncihmOTIueINS6pNG94A== Message-ID: <94C682931C08B048B7A8645303FDC9F36EB29BAE81@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EB29BAE81PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.19.124517 Subject: [Softwires] draft-ietf-softwire-dslite-multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 06:42:28 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EB29BAE81PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear chairs, During the last IETF meeting, it was agreed to send this document to IESG a= s it passed the WGLC and all issues are resolved. Could you please let me know if any further action is needed from my side t= o move this document? Thanks for your help. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36EB29BAE81PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 chairs,
 
D= uring the=20 last IETF meeting, it was agreed to send this document to IESG as it passed= the=20 WGLC and all issues are resolved.
 
C= ould you=20 please let me know if any further action is needed from my side to move thi= s=20 document?
 
T= hanks for=20 your help.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F36EB29BAE81PUEXCB1Bnante_-- From leo.liubing@huawei.com Tue Feb 19 23:05:30 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A34321F8A6F for ; Tue, 19 Feb 2013 23:05:30 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyjikpdgDiwk for ; Tue, 19 Feb 2013 23:05:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3583821F8A6D for ; Tue, 19 Feb 2013 23:05:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOP82676; Wed, 20 Feb 2013 07:05:28 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 20 Feb 2013 07:04:41 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 20 Feb 2013 07:05:25 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Wed, 20 Feb 2013 15:05:18 +0800 From: "Liubing (Leo)" To: Softwires WG Thread-Topic: New Version Notification for draft-jiang-softwire-map-radius-03.txt Thread-Index: AQHODzcxksLtGOe60UmNxBHkah5IMJiCUC4g Date: Wed, 20 Feb 2013 07:05:18 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DA116@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Softwires] FW: New Version Notification for draft-jiang-softwire-map-radius-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 07:05:30 -0000 SGksIGFsbA0KDQpUaGUgTUFQIFJhZGl1cyBkcmFmdCBoYXMgYmVlbiB1cGRhdGVkLg0KVGhlIGF0 dHJpYnV0ZSBkZWZpbml0aW9ucyBoYXZlIG5vIGNoYW5nZS4gVGhlIG1haW4gcmV2aXNpb24gaXMg cmVnYXJkaW5nIHdpdGggdGhlIFJBRElVUyBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uIGJl aGF2aW9yLCB3aGljaCBtYWlubHkgcmVmbGVjdGVkIGJ5IGZpZ3VyZSAxLzIgYW5kIHJlbGV2YW50 IGRlc2NyaXB0aW9uLg0KDQpDb21tZW50cyBhcmUgd2VsY29tZWQuIE1hbnkgdGhhbmtzIQ0KDQpC ZXN0IHJlZ2FyZHMsDQpCaW5nDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmdd IA0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyMCwgMjAxMyAyOjU1IFBNDQpUbzogTGl1Ymlu ZyAoTGVvKQ0KQ2M6IHBldGVyZEBpZWEtc29mdHdhcmUuY29tOyBGdXl1IChFbGV2ZW4pOyBTaGVu ZyBKaWFuZw0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1qaWFu Zy1zb2Z0d2lyZS1tYXAtcmFkaXVzLTAzLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1qaWFuZy1zb2Z0d2lyZS1tYXAtcmFkaXVzLTAzLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBCaW5nIExpdSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0 b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWppYW5nLXNvZnR3aXJlLW1hcC1yYWRpdXMNClJldmlz aW9uOgkgMDMNClRpdGxlOgkJIFJBRElVUyBBdHRyaWJ1dGUgZm9yIE1BUA0KQ3JlYXRpb24gZGF0 ZToJIDIwMTMtMDItMjANCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9m IHBhZ2VzOiAxNA0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1qaWFuZy1zb2Z0d2lyZS1tYXAtcmFkaXVzLTAzLnR4dA0KU3RhdHVzOiAg ICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWppYW5nLXNvZnR3 aXJlLW1hcC1yYWRpdXMNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtamlhbmctc29mdHdpcmUtbWFwLXJhZGl1cy0wMw0KRGlmZjogICAgICAgICAgICBo dHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1qaWFuZy1zb2Z0d2lyZS1tYXAt cmFkaXVzLTAzDQoNCkFic3RyYWN0Og0KICAgTWFwcGluZyBvZiBBZGRyZXNzIGFuZCBQb3J0IChN QVApIGlzIGEgc3RhdGVsZXNzIG1lY2hhbmlzbSBmb3INCiAgIHJ1bm5pbmcgSVB2NCBvdmVyIElQ djYtb25seSBpbmZyYXN0cnVjdHVyZS4gSXQgcHJvdmlkZXMgYm90aCBJUHY0IGFuZA0KICAgSVB2 NiBjb25uZWN0aXZpdHkgc2VydmljZXMgc2ltdWx0YW5lb3VzbHkgZHVyaW5nIHRoZSBJUHY0L0lQ djYgY28tDQogICBleGlzdGluZyBwZXJpb2QuIFRoZSBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlv biBQcm90b2NvbCBmb3IgSVB2Ng0KICAgKERIQ1B2NikgTUFQIG9wdGlvbnMgaGFzIGJlZW4gZGVm aW5lZCB0byBjb25maWd1cmUgTUFQIEN1c3RvbWVyIEVkZ2UNCiAgIChDRSkuIEhvd2V2ZXIsIGlu IG1hbnkgbmV0d29ya3MsIHRoZSBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIG1heSBiZQ0KICAg c3RvcmVkIGluIEF1dGhlbnRpY2F0aW9uIEF1dGhvcml6YXRpb24gYW5kIEFjY291bnRpbmcgKEFB QSkgc2VydmVycw0KICAgd2hpbGUgdXNlciBjb25maWd1cmF0aW9uIGlzIG1haW5seSBmcm9tIEJy b2FkYmFuZCBOZXR3b3JrIEdhdGV3YXkNCiAgIChCTkcpIHRocm91Z2ggREhDUHY2IHByb3RvY29s LiBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBSZW1vdGUNCiAgIEF1dGhlbnRpY2F0aW9uIERpYWwg SW4gVXNlciBTZXJ2aWNlIChSQURJVVMpIGF0dHJpYnV0ZSB0aGF0IGNhcnJpZXMNCiAgIE1BUCBj b25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGZyb20gQUFBIHNlcnZlciB0byBCTkcuIFRoZSBNQVAg UkFESVVTDQogICBhdHRyaWJ1dGUgYXJlIGRlc2lnbmVkIGZvbGxvd2luZyB0aGUgc2ltcGxpZnkg cHJpbmNpcGxlLiBJdCBwcm92aWRlcw0KICAganVzdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gZm9y bSB0aGUgY29ycmVzcG9uZGVudCBESENQdjYgTUFQIG9wdGlvbi4NCg0KDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From ian.farrer@telekom.de Wed Feb 20 03:55:40 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C200021F87A4 for ; Wed, 20 Feb 2013 03:55: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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xmjJ6F9nyCp for ; Wed, 20 Feb 2013 03:55:39 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9503D21F8798 for ; Wed, 20 Feb 2013 03:55:39 -0800 (PST) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 20 Feb 2013 12:55:31 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 20 Feb 2013 12:55:31 +0100 From: To: Date: Wed, 20 Feb 2013 12:55:31 +0100 Thread-Topic: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? Thread-Index: Ac4PYS8CrXUKwXzBQ3uSroac3fMozA== Message-ID: In-Reply-To: <212ED847-153C-491E-BDBE-DDB1D5DE3505@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires@ietf.org, draft-ietf-softwire-map@tools.ietf.org Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 11:55:40 -0000 Hi Ole, So, are we in agreement on the following points? * A MAP-CE only has one way of configuring 1:1 mode. * There should only be a single way of provisioning 1:1 mode. If so, then the unified CPE draft describes a single method for provisioning 1:1 mode irrespective of the underlying implementation method (MAP-E & lw4o6). MAP-E should then use this method for provisioning its 1:1 mode and EA=3D0 as the way that it is implemented. Cheers, Ian On 17/02/2013 22:06, "Ole Troan" wrote: >Ian, > >> Assuming that the Unified CPE draft gets adopted by the workgroup, then >> there needs to be alignment of the different drafts reflecting this. >>=20 >> The unified CPE draft describes how a CPE interprets the presence (or >>lack >> of) configuration parameters to understand which softwire mode to >> configure. If a MAP CE implemented this (to be a 'unified MAP CE'), then >> it would have two ways of configuring 1:1 mode - via the presence of the >> tunnel endpoint address, an IPv4 address (and optionally a restricted >>port >> range) and also through a BMR with EA=3D0. > >a MAP CE has only one way of configuring 1:1 mode. > >> Two ways of configuring the same function doesn't seem like a good idea, >> even if the underlying mechanism that this function is implemented with >>is >> different. > >indeed. > >> So, what I would propose is that EA=3D0 for MAP is not included as a >> provisioning option in the MAP draft. If the parameters described in the >> unified CPE draft required for 1:1 mode are configured on the unified >>MAP >> CE, then it should interpret these to mean EA=3D0 and configure itself >> accordingly. > >a MAP CE will always configure itself with the BMR. >that consists of the Rule IPv6 prefix, the Rule IPv4 prefix and the EA >length. > >from a MAP perspective there is not two ways of doing 1:1 mode. > >> I also think that it would be cleaner if this 1:1 functionality was >> described in a separate document to the current MAP draft. As the 1:1 >>mode >> functionality of MAP is a big architectural change to the mesh mode >> function, it really needs a lot more than 2 paragraphs in order to >> describe what it is and how it is used. > >1:1 is a configured tunnel with provisioning support. >as others have said, that's a simple subset of the mesh functionality. >hardly a big architectural change. > >cheers, >Ole From ot@cisco.com Wed Feb 20 04:07:47 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF0A21F87CD for ; Wed, 20 Feb 2013 04:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.477 X-Spam-Level: X-Spam-Status: No, score=-10.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYLCIqxBIV2b for ; Wed, 20 Feb 2013 04:07:46 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7849221F87CC for ; Wed, 20 Feb 2013 04:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=668; q=dns/txt; s=iport; t=1361362066; x=1362571666; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/lHNo2sx9YW28wmDfHb0YrwUuGhBhU4VeoF/rRAR3yA=; b=IIOFLFT6mpXE57Obn1dGHPei0byFlk8op29BorkazGm9i0Ac9kZFmrwb fEhM2HHdu3tqKRt5RKrZhPS81e/wOcZRrjywKKD3ckZOcQwJS73Ti8ukC fyoyBsVLfmPXQmkbJTbwCBeV1laCSpsFCqeWh395xf3x4lM/9DNPdr0xu g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADG8JFGQ/khR/2dsb2JhbABEwFd+FnOCHwEBAQMBOj8FCwtGVwaIHwbAAY5bMwcWgklhA5YskFuDCA X-IronPort-AV: E=Sophos;i="4.84,701,1355097600"; d="scan'208";a="80572183" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 20 Feb 2013 12:07:45 +0000 Received: from dhcp-lys02-vla252-10-147-116-40.cisco.com (dhcp-lys02-vla252-10-147-116-40.cisco.com [10.147.116.40]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1KC7iQ4004250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2013 12:07:45 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: Date: Wed, 20 Feb 2013 13:07:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <79F8E801-3574-482A-BACC-48D77B140A87@cisco.com> References: To: X-Mailer: Apple Mail (2.1499) Cc: softwires@ietf.org, draft-ietf-softwire-map@tools.ietf.org Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 12:07:47 -0000 Ian, > So, are we in agreement on the following points? >=20 > * A MAP-CE only has one way of configuring 1:1 mode. > * There should only be a single way of provisioning 1:1 mode. >=20 > If so, then the unified CPE draft describes a single method for > provisioning 1:1 mode irrespective of the underlying implementation = method > (MAP-E & lw4o6). MAP-E should then use this method for provisioning = its > 1:1 mode and EA=3D0 as the way that it is implemented. yes, I think so. while the MAP mode is configured with the BMR/Rule IPv4 = prefix. that doesn't force how the bits are represented in the provisioning = option of course. Best, Ole From sarikaya2012@gmail.com Wed Feb 20 08:51:17 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1ABC21F8945 for ; Wed, 20 Feb 2013 08:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1DiQkyOvKj8 for ; Wed, 20 Feb 2013 08:51:16 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id EE15C21F8931 for ; Wed, 20 Feb 2013 08:51:15 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id gm6so5997950lbb.26 for ; Wed, 20 Feb 2013 08:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=RFG2y8/Tyd0TrdTg/ovbZrU/SzpVnc1S+JFFg3Rd1jY=; b=jP8w5sNpT+P35gXNOA3RSQpGeXwlrbI37RUTjAg/QWieMvXflZbfHdbNRLJH49OeZU Gi+JI5T+iRMW/+a16dDYWf9OMt9OJNwPnqaGSCDnWH0ajTXj/CcmK9VVFDGyW9y4c+5C wtdh6L5/mwyq9EXEwlG86Ynjb4qak4jXks4A0nGFa31/nia7kD+3ZnEQ/5SiPVGkpdec pipSbQrvHEaxkOzU9R13r02Vg02FoC0IndIADxwqK6q/qhgJ235oZ8UPxrQK1arN2Ps6 U+xDSQl3km5QYLR8giY5PWyQOFgdAfpHxvLkBptu5KSA51AsF8WDQJ9R0bSt+hcR/PX5 FzzQ== MIME-Version: 1.0 X-Received: by 10.112.87.66 with SMTP id v2mr9195129lbz.130.1361379074570; Wed, 20 Feb 2013 08:51:14 -0800 (PST) Received: by 10.114.28.168 with HTTP; Wed, 20 Feb 2013 08:51:14 -0800 (PST) In-Reply-To: <20130219174010.3840.84625.idtracker@ietfa.amsl.com> References: <20130219174010.3840.84625.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2013 10:51:14 -0600 Message-ID: From: Behcet Sarikaya To: Softwires-wg Content-Type: multipart/alternative; boundary=f46d040169ff24fa9304d62ac4a3 Subject: [Softwires] New Version Notification for draft-sarikaya-softwire-4rdmulticast-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 16:51:18 -0000 --f46d040169ff24fa9304d62ac4a3 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I have submitted a revised version of my draft on MAP-E multicast support as follows below. Please send your mail on support/reviews to the list. Regards, Behcet A new version of I-D, draft-sarikaya-softwire-4rdmulticast-06.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: draft-sarikaya-softwire-4rdmulticast Revision: 06 Title: Multicast Support for MAP-E Creation date: 2013-02-19 Group: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-softwire-4rdmulticast-06.txt Status: http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast Htmlized: http://tools.ietf.org/html/draft-sarikaya-softwire-4rdmulticast-06 Diff: http://www.ietf.org/rfcdiff?url2=draft-sarikaya-softwire-4rdmulticast-06 Abstract: This memo specifies MAP-E (together with MAP-T and 4rd)'s multicast component so that IPv4 hosts can receive multicast data from IPv4 servers over an IPv6 network. In the encapsulation solution for encapsulation variant of Mapping of Address and Port (MAP), MAP-E, IGMP Proxy at the MAP-E Customer Edge router uses IPv4-in-IPv6 tunnel established by MAP-E to exchange IGMP messages to establish multicast state at MAP-E Border Relay so that MAP-E Border Relay can tunnel IPv4 multicast data to IPv4 hosts connected to MAP-E Customer Edge device. In the Translation Multicast solution for the translation variant of MAP, MAP-T and 4rd, IGMP messages are translated into MLD messages at the CE router which is IGMP/MLD Proxy and sent to the network in IPv6. MAP-T/4rd Border Relay does the reverse translation and joins IPv4 multicast group for MAP-T/4rd hosts. Border Relay as multicast router receives IPv4 multicast data and translates the packet into IPv6 multicast data and sends downstream on the multicast tree. Member CEs receive multicast data, translate it back to IPv4 and transmit to the hosts. The IETF Secretariat --f46d040169ff24fa9304d62ac4a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I have submitted a revised version of my draft on MAP-E mult= icast support as follows below.

Please send your mail on support/rev= iews to the list.

Regards,

Behcet



A new version of I-D, draft-sarikaya-softwire-4rdmulticast-06.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-sarikaya-softwire-4rdmulticast
Revision: =A0 =A0 =A0 =A006
Title: =A0 =A0 =A0 =A0 =A0 Multicast Support for MAP-E
Creation date: =A0 2013-02-19
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 20
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.= ietf.org/internet-drafts/draft-sarikaya-softwire-4rdmulticast-06.txt Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.= org/doc/draft-sarikaya-softwire-4rdmulticast
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/d= raft-sarikaya-softwire-4rdmulticast-06
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.= org/rfcdiff?url2=3Ddraft-sarikaya-softwire-4rdmulticast-06

Abstract:
=A0 =A0This memo specifies MAP-E (together with MAP-T and 4rd)'s multic= ast
=A0 =A0component so that IPv4 hosts can receive multicast data from IPv4 =A0 =A0servers over an IPv6 network. =A0In the encapsulation solution for =A0 =A0encapsulation variant of Mapping of Address and Port (MAP), MAP-E, =A0 =A0IGMP Proxy at the MAP-E Customer Edge router uses IPv4-in-IPv6 tunne= l
=A0 =A0established by MAP-E to exchange IGMP messages to establish multicas= t
=A0 =A0state at MAP-E Border Relay so that MAP-E Border Relay can tunnel =A0 =A0IPv4 multicast data to IPv4 hosts connected to MAP-E Customer Edge =A0 =A0device. =A0In the Translation Multicast solution for the translation=
=A0 =A0variant of MAP, MAP-T and 4rd, IGMP messages are translated into MLD=
=A0 =A0messages at the CE router which is IGMP/MLD Proxy and sent to the =A0 =A0network in IPv6. =A0MAP-T/4rd Border Relay does the reverse translat= ion
=A0 =A0and joins IPv4 multicast group for MAP-T/4rd hosts. =A0Border Relay = as
=A0 =A0multicast router receives IPv4 multicast data and translates the
=A0 =A0packet into IPv6 multicast data and sends downstream on the multicas= t
=A0 =A0tree. =A0Member CEs receive multicast data, translate it back to IPv= 4
=A0 =A0and transmit to the hosts.




The IETF Secretariat


--f46d040169ff24fa9304d62ac4a3-- From tom.taylor.stds@gmail.com Thu Feb 21 07:43:51 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4359421F8703 for ; Thu, 21 Feb 2013 07:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udpSYt8JCGf1 for ; Thu, 21 Feb 2013 07:43:50 -0800 (PST) Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA7B21F843C for ; Thu, 21 Feb 2013 07:43:50 -0800 (PST) Received: by mail-ia0-f173.google.com with SMTP id h37so8324518iak.18 for ; Thu, 21 Feb 2013 07:43:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=PmgT0JXmXNxeBCDstQI6AAASVXG4Qner3YmFC56GMgU=; b=ReM+tUCBbbKEN2ovWYFOm7kpM6QoNyddvMTGGhLRnZYwhqaIGDTmp+xBVLyZR2GL1k 88Y6X1a9FpPX+CCx4K+9djTGlJ0AY+s/mpLrP/yVyJ9K4L6JSUf54PCuDj50TAAEDeJA FCDOvLaw8rBhBEMbMIpsZ+k7xY9QIDC6nj8DmyeS45zx09UizB4VjTviNgBMtm2BT0qU Bf7KOM6O3Vm5lC66l/jV0MGWVKRkgpNER/Wb0yZeJUFhC1zodAMBr9HeAOCN6aVE/58k RaKIs12fCbJ/dos4IcCR9lpYsB2heW6CWPI9YIEa+/TNk03ADkzW0xnJrBuwxzIbRBUt GO4g== X-Received: by 10.50.173.105 with SMTP id bj9mr11475824igc.44.1361461419625; Thu, 21 Feb 2013 07:43:39 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-101-174.tor.primus.ca. [173.206.101.174]) by mx.google.com with ESMTPS id ee5sm10353692igc.0.2013.02.21.07.43.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 07:43:38 -0800 (PST) Message-ID: <512640A8.6040407@gmail.com> Date: Thu, 21 Feb 2013 10:43:36 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Ole Troan References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> <511AE8E9.1080805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130221-1, 21/02/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:43:51 -0000 The two bullets below were actually a "Trojan Horse" of sorts. They set the agenda for Sections 5.2 and 5.3 respectively. I think those two sections should have different titles to start with: 5.2 Provisioning the MAP IPv4 Address, MAP IPv6 Address, and Port Set Identifier (PSID) At a CE 5.2.1 Deriving the IPv4 Address and PSID From the End-User IPv6 Prefix and the Basic Mapping Rule 5.2.2 Deriving the IPv6 Address To Use On the MAP Interface 5.3 Deriving the MAP IPv6 Address From the IPv4 Address and Port and the Matching Forwarding Mapping Rule (Mesh Mode Only) The procedure described in each section should then match the title. I'll sketch the flow here, but I can supply detailed text if desired. 5.2.1 Deriving the IPv4 Address and PSID From the End-User IPv6 Prefix and the Basic Mapping Rule - distinguishing the Basic Mapping Rule (BMR) from other mapping rules that are provisioned - locating the Extended Address (EA) bits in the End-User IPv6 Prefix - Case 1: Port set identifier (PSID) is explicitly provisioned separately from the BMR -- IPv4 address is shared -- IPv4 address is the concatenation of the IPv4 prefix provided in the BMR and the IPv4 suffix provided by the EA bits -- if the result is not a /32, error - Case 2: PSID is embedded in the EA bits -- true if the sum (o + r) is greater than 32, where o is the number of EA bits as indicated by the BMR, and r is the length of the IPv4 prefix supplied by the BMR -- shared IPv4 address is the concatenation of the IPv4 prefix supplied by the BMR and as many of the high-order bits within the EA bit field as required to make up a /32 -- PSID is given by the remaining lower-order bits in the EA bit field - Case 3: non-shared IPv4 address or prefix -- true if the sum (o + r) as defined above is less than or equal to 32 -- IPv4 address or prefix is equal to the concatenation of the IPv4 prefix as supplied by the BMR with the entire contents of the EA bit field. 5.2.2 Deriving the IPv6 Address To Use On the MAP Interface - MAP IPv6 address is given by the concatenation of the provisioned End-User IPv6 Prefix with an interface identifier derived as described in Section 6. - this applies for both hub-and-spoke and mesh mode 5.3 Deriving the MAP IPv6 Address From the Destination IPv4 Address and Port and the Matching Forwarding Mapping Rule (Mesh Mode Only) - locate the applicable Mapping Rule by longest match on rule IPv4 address/prefix - Derive the target End-User IPv6 prefix less the subnet identifier as follows: -- Case 1: length of the EA field as given by the selected Mapping Rule is 0 --- target End-User IPv6 prefix (less the subnet identifier) is equal to the IPv6 prefix provided by the selected Mapping Rule -- Case 2: sum (o + r) is less than or equal to 32, where o and r are as defined in Section 5.2 --- implies destination IPv4 address/prefix is dedicated to destination CE --- EA bit field is equal to the highest-order o bits of the destination IPv4 address not contained in the IPv4 address/prefix provided by the selected Mapping Rule --- target End-User IPv6 prefix (less the subnet identifier) is equal to the IPv6 prefix provided by the selected Mapping Rule followed in concatenation with the derived EA bit field -- Case 3: sum (o + r) as defined above is greater than 32 --- implies destination IPv4 address/prefix is shared --- set the high-order portion of the EA bit field equal to the low-order (32 - r) bits of the destination IPv4 address --- the remaining o - (32 - r) bits of the EA bit field are equal to the high-order bits of the destination port number, beginning with the bit after the offset given by the selected Mapping Rule (default = 6) --- target End-User IPv6 prefix (less the subnet identifier) is equal to the IPv6 prefix provided by the selected Mapping Rule followed in concatenation with the derived EA bit field - subnet identifier portion of the End-User IPv6 prefix is all zeroes - End-User MAP Address is equal to the End-User IPv6 prefix concatenated with an interface identifier (IID) derived as described in Section 6. Tom Taylor On 13/02/2013 3:07 AM, Ole Troan wrote: > I agree with Tom's proposed changes. > I'll put them in a upcoming revision 05, if no-one objects. > (I still think we can do a WGLC on revision 04). > > cheers, > Ole > > >> Remark: I'm not sure the two bullets (quoted further down) tell the full story as they stand. I propose to modify them as follows: >> >> 1. Basic Mapping Rule (BMR) - mandatory. There can only be one >> Basic Mapping Rule per End-user IPv6 prefix. In combination >> with the End-user IPv6 prefix, the Basic Mapping Rule is used >> to derive the IPv4 prefix, address, or shared address and >> the PSID assigned to the CE. >> >> 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. >> The Basic Mapping Rule is also a Forwarding Mapping Rule. Each >> Forwarding Mapping Rule will result in an entry in the Rules >> table for the Rule IPv4 prefix. Given a destination IPv4 address >> and port within the MAP domain, a MAP node can use the matching >> FMR to derive the End-user IPv6 address of the interface through >> which that destination address-port combination can be reached. >> >> >> On 12/02/2013 9:22 AM, Ole Troan wrote: >>> Tom, >>> >>>> Thanks. What about the assertions in the bullets? >>> >>> sorry, may be my short term memory... what do you mean? >>> >>> cheers, >>> Ole >>> >>> >>>> >>>> On 12/02/2013 3:27 AM, Ole Troan wrote: >>>>> Tom, >>>>> >>>>>> I'm still hoping to see a response to this. >>>>>> >>>>>> On 06/02/2013 8:42 AM, Tom Taylor wrote: >>>>>>> Section 5 of the latest version of MAP has the following: >>>>>>> >>>>>>> 1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 prefix, >>>>>>> address or port set assignment. There can only be one Basic >>>>>>> Mapping Rule per End-user IPv6 prefix. The Basic Mapping Rule is >>>>>>> used to configure the MAP IPv6 address or prefix. >>>>>>> >>>>>>> 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. >>>>>>> The Basic Mapping Rule is also a Forwarding Mapping Rule. Each >>>>>>> Forwarding Mapping Rule will result in an entry in the Rules >>>>>>> table for the Rule IPv4 prefix. >>>>>>> >>>>>>> Question: there will always be a BMR. In the absence of additional >>>>>>> rules, how does a CE know whether it can use the BMR for forwarding or >>>>>>> must always use the default rule? >>>>> >>>>> the answer to that is in section 7, last bullet. >>>>> >>>>> that is, the MAP CE must be configured to be in hub and spoke mode or mesh mode. >>>>> which mode it is in decided if the BMR is used for forwarding or not. >>>>> >>>>> cheers, >>>>> Ole >>>>> >>>>> >>> >>> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > > From tom.taylor.stds@gmail.com Thu Feb 21 19:37:35 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B6121E804B for ; Thu, 21 Feb 2013 19:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.432 X-Spam-Level: X-Spam-Status: No, score=0.432 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJTjBfsyZYLF for ; Thu, 21 Feb 2013 19:37:34 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4B37821E803D for ; Thu, 21 Feb 2013 19:37:33 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id c12so250397ieb.34 for ; Thu, 21 Feb 2013 19:37:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=TshZUPvT9RApcPaa/fdcEUqCXLuq47jG0EJOCZms75k=; b=xpvm5fwNojyl1HczQyslqURFscDDI44GGyAn1i85rdIe8/29h+L4HOnrXuL9c773lS 1wZX6QvU7Qf2Y0OC96+yBHHbzRtnHUofKMfhyANDcPuV9R2/+7lifFbkr/oMO8BUPDjb KHG+KBiv0gB8c3ijV9SRcYOmOI4fO8Wt428azmE4oVmBFnsvzgaedvuLIYXH4+WihF0c GSxGm0J7PxV20S2noRCUq0xIgD9qt9s5yZrkoW9VOMMYV6aqzWbzZo2a3Rb1q8o43xuu +35A6E4FSn+iP+mwVkRjdVk5RxN72tmu8WwL6EmrPr8scoFluEV2TBsJBzQdu/wP6LBR txEg== X-Received: by 10.50.202.6 with SMTP id ke6mr206010igc.30.1361504253321; Thu, 21 Feb 2013 19:37:33 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-101-174.tor.primus.ca. [173.206.101.174]) by mx.google.com with ESMTPS id uq1sm1285746igc.5.2013.02.21.19.37.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 19:37:32 -0800 (PST) Message-ID: <5126E7F9.6050805@gmail.com> Date: Thu, 21 Feb 2013 22:37:29 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Ole Troan References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> <511AE8E9.1080805@gmail.com> <512640A8.6040407@gmail.com> In-Reply-To: <512640A8.6040407@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130221-3, 21/02/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:37:35 -0000 I forgot that the border router has to use the procedure of section 5.3 in both mesh and hub-and-spoke mode. So "(Mesh Mode Only)" should be removed from the title of the section, but introductory text should say that the procedure is used by CEs in mesh mode only, but by the border router in all cases. On 21/02/2013 10:43 AM, Tom Taylor wrote: > The two bullets below were actually a "Trojan Horse" of sorts. They set > the agenda for Sections 5.2 and 5.3 respectively. I think those two > sections should have different titles to start with: > > 5.2 Provisioning the MAP IPv4 Address, MAP IPv6 Address, and Port Set > Identifier (PSID) At a CE > > 5.2.1 Deriving the IPv4 Address and PSID From the End-User IPv6 Prefix > and the Basic Mapping Rule > > 5.2.2 Deriving the IPv6 Address To Use On the MAP Interface > > 5.3 Deriving the MAP IPv6 Address From the IPv4 Address and Port and > the Matching Forwarding Mapping Rule (Mesh Mode Only) > > The procedure described in each section should then match the title. > I'll sketch the flow here, but I can supply detailed text if desired. > > > 5.2.1 Deriving the IPv4 Address and PSID From the End-User IPv6 Prefix > and the Basic Mapping Rule > > - distinguishing the Basic Mapping Rule (BMR) from other mapping rules > that are provisioned > > - locating the Extended Address (EA) bits in the End-User IPv6 Prefix > > - Case 1: Port set identifier (PSID) is explicitly provisioned > separately from the BMR > -- IPv4 address is shared > -- IPv4 address is the concatenation of the IPv4 prefix provided in the > BMR and the IPv4 suffix provided by the EA bits > -- if the result is not a /32, error > > - Case 2: PSID is embedded in the EA bits > -- true if the sum (o + r) is greater than 32, where o is the number of > EA bits as indicated by the BMR, and r is the length of the IPv4 prefix > supplied by the BMR > -- shared IPv4 address is the concatenation of the IPv4 prefix supplied > by the BMR and as many of the high-order bits within the EA bit field as > required to make up a /32 > -- PSID is given by the remaining lower-order bits in the EA bit field > > - Case 3: non-shared IPv4 address or prefix > -- true if the sum (o + r) as defined above is less than or equal to 32 > -- IPv4 address or prefix is equal to the concatenation of the IPv4 > prefix as supplied by the BMR with the entire contents of the EA bit field. > > 5.2.2 Deriving the IPv6 Address To Use On the MAP Interface > > - MAP IPv6 address is given by the concatenation of the provisioned > End-User IPv6 Prefix with an interface identifier derived as described > in Section 6. > > - this applies for both hub-and-spoke and mesh mode > > 5.3 Deriving the MAP IPv6 Address From the Destination IPv4 Address and > Port and the Matching Forwarding Mapping Rule (Mesh Mode Only) > > - locate the applicable Mapping Rule by longest match on rule IPv4 > address/prefix > > - Derive the target End-User IPv6 prefix less the subnet identifier as > follows: > > -- Case 1: length of the EA field as given by the selected Mapping Rule > is 0 > --- target End-User IPv6 prefix (less the subnet identifier) is equal to > the IPv6 prefix provided by the selected Mapping Rule > > -- Case 2: sum (o + r) is less than or equal to 32, where o and r are as > defined in Section 5.2 > --- implies destination IPv4 address/prefix is dedicated to destination CE > --- EA bit field is equal to the highest-order o bits of the destination > IPv4 address not contained in the IPv4 address/prefix provided by the > selected Mapping Rule > --- target End-User IPv6 prefix (less the subnet identifier) is equal to > the IPv6 prefix provided by the selected Mapping Rule followed in > concatenation with the derived EA bit field > > -- Case 3: sum (o + r) as defined above is greater than 32 > --- implies destination IPv4 address/prefix is shared > --- set the high-order portion of the EA bit field equal to the > low-order (32 - r) bits of the destination IPv4 address > --- the remaining o - (32 - r) bits of the EA bit field are equal to the > high-order bits of the destination port number, beginning with the bit > after the offset given by the selected Mapping Rule (default = 6) > --- target End-User IPv6 prefix (less the subnet identifier) is equal to > the IPv6 prefix provided by the selected Mapping Rule followed in > concatenation with the derived EA bit field > > - subnet identifier portion of the End-User IPv6 prefix is all zeroes > > - End-User MAP Address is equal to the End-User IPv6 prefix concatenated > with an interface identifier (IID) derived as described in Section 6. > > Tom Taylor > > > On 13/02/2013 3:07 AM, Ole Troan wrote: >> I agree with Tom's proposed changes. >> I'll put them in a upcoming revision 05, if no-one objects. >> (I still think we can do a WGLC on revision 04). >> >> cheers, >> Ole >> >> >>> Remark: I'm not sure the two bullets (quoted further down) tell the >>> full story as they stand. I propose to modify them as follows: >>> >>> 1. Basic Mapping Rule (BMR) - mandatory. There can only be one >>> Basic Mapping Rule per End-user IPv6 prefix. In combination >>> with the End-user IPv6 prefix, the Basic Mapping Rule is used >>> to derive the IPv4 prefix, address, or shared address and >>> the PSID assigned to the CE. >>> >>> 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. >>> The Basic Mapping Rule is also a Forwarding Mapping Rule. Each >>> Forwarding Mapping Rule will result in an entry in the Rules >>> table for the Rule IPv4 prefix. Given a destination IPv4 address >>> and port within the MAP domain, a MAP node can use the matching >>> FMR to derive the End-user IPv6 address of the interface through >>> which that destination address-port combination can be reached. >>> >>> >>> On 12/02/2013 9:22 AM, Ole Troan wrote: >>>> Tom, >>>> >>>>> Thanks. What about the assertions in the bullets? >>>> >>>> sorry, may be my short term memory... what do you mean? >>>> >>>> cheers, >>>> Ole >>>> >>>> >>>>> >>>>> On 12/02/2013 3:27 AM, Ole Troan wrote: >>>>>> Tom, >>>>>> >>>>>>> I'm still hoping to see a response to this. >>>>>>> >>>>>>> On 06/02/2013 8:42 AM, Tom Taylor wrote: >>>>>>>> Section 5 of the latest version of MAP has the following: >>>>>>>> >>>>>>>> 1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 prefix, >>>>>>>> address or port set assignment. There can only be one >>>>>>>> Basic >>>>>>>> Mapping Rule per End-user IPv6 prefix. The Basic >>>>>>>> Mapping Rule is >>>>>>>> used to configure the MAP IPv6 address or prefix. >>>>>>>> >>>>>>>> 2. Forwarding Mapping Rule (FMR) - optional, used for >>>>>>>> forwarding. >>>>>>>> The Basic Mapping Rule is also a Forwarding Mapping >>>>>>>> Rule. Each >>>>>>>> Forwarding Mapping Rule will result in an entry in the >>>>>>>> Rules >>>>>>>> table for the Rule IPv4 prefix. >>>>>>>> >>>>>>>> Question: there will always be a BMR. In the absence of additional >>>>>>>> rules, how does a CE know whether it can use the BMR for >>>>>>>> forwarding or >>>>>>>> must always use the default rule? >>>>>> >>>>>> the answer to that is in section 7, last bullet. >>>>>> >>>>>> that is, the MAP CE must be configured to be in hub and spoke mode >>>>>> or mesh mode. >>>>>> which mode it is in decided if the BMR is used for forwarding or not. >>>>>> >>>>>> cheers, >>>>>> Ole >>>>>> >>>>>> >>>> >>>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >> >> From internet-drafts@ietf.org Sat Feb 23 19:07:33 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DB521F8E21; Sat, 23 Feb 2013 19:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QV+MpxtkWr2k; Sat, 23 Feb 2013 19:07:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA26921F8E7B; Sat, 23 Feb 2013 19:07:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130224030732.25967.42170.idtracker@ietfa.amsl.com> Date: Sat, 23 Feb 2013 19:07:32 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-mesh-mib-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 03:07:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Softwire Mesh Management Information Base (MIB) Author(s) : Yong Cui Jiang Dong Peng Wu Mingwei Xu Filename : draft-ietf-softwire-mesh-mib-02.txt Pages : 14 Date : 2013-02-23 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular it defines objects for managing softwire mesh [RFC5565]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-mesh-mib-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-mesh-mib-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pengwu.thu@gmail.com Sat Feb 23 19:12:57 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BAF21F84B1 for ; Sat, 23 Feb 2013 19:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qnflnbdEVR3 for ; Sat, 23 Feb 2013 19:12:56 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4A44221F84AF for ; Sat, 23 Feb 2013 19:12:56 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id j6so1840776oag.36 for ; Sat, 23 Feb 2013 19:12:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=pEI9qR3fdwGxxUCTywnWzatXw5yrS+hvSeTPjApx4nM=; b=SFKFtBRZJBDpU7K4mb/TeU2VWfsXQ1NL/QEB4VCyRJu3D3WoxCIgytglYhz4zpleBX 3xX3CMp0/h+szJqvYjgsbCRuB7NopdCG5rKKV9FLtpUZhoAarqfDw+yqMirySi+gyNcR KRALoIm2/QS57iHaIbpsnvRwHAv4T9vw8MeT4ma5WS6yni64URVcZNW/ceN+ONUpQNl0 N3US+IcizhXoJADRU2ElpP26Bqyy5vvVlWQ9nfsr8IkaFPY1ry9w/ZfVg7MIbJUZgPSh K6y8M20XiTsHodOkApQrMXOr379WWHUVFtSj3HktOp+1kpbVH7N0OL3fH5es5zd9owbC eVtQ== MIME-Version: 1.0 X-Received: by 10.60.14.71 with SMTP id n7mr3462640oec.135.1361675575940; Sat, 23 Feb 2013 19:12:55 -0800 (PST) Received: by 10.60.146.170 with HTTP; Sat, 23 Feb 2013 19:12:55 -0800 (PST) In-Reply-To: <20130224030732.25967.42170.idtracker@ietfa.amsl.com> References: <20130224030732.25967.42170.idtracker@ietfa.amsl.com> Date: Sun, 24 Feb 2013 11:12:55 +0800 Message-ID: From: Peng Wu To: Softwires WG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Yong Cui Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-mesh-mib-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 03:12:57 -0000 Hi all, Here is a new version of Softwire Mesh MIB. Based on the Chairs' comments on DS-Lite MIB draft, we've revised the Softwire Mesh MIB document using a MIB validator. There are some editorial updates as well. Major changes are: In section 7: 1. Reorganize the =92 IMPORTS=92 part, deleted some redundant IMPORT= S; 2. Add the OBJECT IDENTIFIER =91swmMIBObjects=92 to make the structure more clear; 3. Correct a couple of typos. Please review on the draft. Comments are always welcome. If it is ready, we hope this work could move forward. On Sun, Feb 24, 2013 at 11:07 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Softwires Working Group of the IETF. > > Title : Softwire Mesh Management Information Base (MIB) > Author(s) : Yong Cui > Jiang Dong > Peng Wu > Mingwei Xu > Filename : draft-ietf-softwire-mesh-mib-02.txt > Pages : 14 > Date : 2013-02-23 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular it defines objects for managing softwire mesh > [RFC5565]. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-mib > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-softwire-mesh-mib-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-mesh-mib-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From internet-drafts@ietf.org Mon Feb 25 01:49:46 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0D121F8EC2; Mon, 25 Feb 2013 01:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSxR+wKWoErM; Mon, 25 Feb 2013 01:49:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467E621F927D; Mon, 25 Feb 2013 01:49:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225094945.6208.61702.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 01:49:45 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-mib-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 09:49:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : DS-Lite Management Information Base (MIB) Author(s) : Yu Fu Sheng Jiang Jiang Dong Yuchi Chen Filename : draft-ietf-softwire-dslite-mib-02.txt Pages : 27 Date : 2013-02-25 Abstract: This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for DS-Lite. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-dslite-mib-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-dslite-mib-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ot@cisco.com Mon Feb 25 01:51:11 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0008421F9289 for ; Mon, 25 Feb 2013 01:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.869 X-Spam-Level: X-Spam-Status: No, score=-9.869 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9b59n6hMDyF for ; Mon, 25 Feb 2013 01:51:10 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 282A221F9280 for ; Mon, 25 Feb 2013 01:51:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8049; q=dns/txt; s=iport; t=1361785869; x=1362995469; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RxfFw0xyUm0ypiQwg2ncvp1zK6VCd0YFnow8enyx1qg=; b=iA5BjI+GeG2T2fw5E22LpcgqpmaXbq8DyxrLydznu+M1U6w6p2iXlKpD XcqhhZImtviVQQ0f13poH/slO7P1ALAyHALhYfle72PdMmylm9aDsuNkK oiBFaPTs8K5HB69utAxKiT3f+eXJJI1r43IxJgEtlkMdWYsJuzNtVPvs1 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOYyK1GQ/khL/2dsb2JhbABFwVOBBBZzgh8BAQEDAQEBAWsLBQsLGC4hBjAGE4gBAwkGDLQdDYkhBIw3giQzB4JfYQOSfIFkgV2LToUXgwg X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; d="scan'208";a="150890049" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 25 Feb 2013 09:51:08 +0000 Received: from dhcp-lys02-vla252-10-147-116-80.cisco.com (dhcp-lys02-vla252-10-147-116-80.cisco.com [10.147.116.80]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1P9p7fX031526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Feb 2013 09:51:07 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <512640A8.6040407@gmail.com> Date: Mon, 25 Feb 2013 10:51:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <675E9657-7AE4-455D-8EF8-A759378A65E9@cisco.com> References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> <511AE8E9.1080805@gmail.com> <512640A8.6040407@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 09:51:11 -0000 Tom, et, al, thanks for the suggestion. I would lean towards pushing back on = rewriting section 5, on the grounds that this is a set of generic tools and that specific use cases rather = could go in a deployment document. does anyone else have strong opinions on current text versus Tom's = proposed changes? cheers, Ole On Feb 21, 2013, at 16:43 , Tom Taylor = wrote: > The two bullets below were actually a "Trojan Horse" of sorts. They = set the agenda for Sections 5.2 and 5.3 respectively. I think those two = sections should have different titles to start with: >=20 > 5.2 Provisioning the MAP IPv4 Address, MAP IPv6 Address, and Port Set = Identifier (PSID) At a CE >=20 > 5.2.1 Deriving the IPv4 Address and PSID =46rom the End-User IPv6 = Prefix and the Basic Mapping Rule >=20 > 5.2.2 Deriving the IPv6 Address To Use On the MAP Interface >=20 > 5.3 Deriving the MAP IPv6 Address =46rom the IPv4 Address and Port = and the Matching Forwarding Mapping Rule (Mesh Mode Only) >=20 > The procedure described in each section should then match the title. = I'll sketch the flow here, but I can supply detailed text if desired. >=20 >=20 > 5.2.1 Deriving the IPv4 Address and PSID =46rom the End-User IPv6 = Prefix and the Basic Mapping Rule >=20 > - distinguishing the Basic Mapping Rule (BMR) from other mapping rules = that are provisioned >=20 > - locating the Extended Address (EA) bits in the End-User IPv6 Prefix >=20 > - Case 1: Port set identifier (PSID) is explicitly provisioned = separately from the BMR > -- IPv4 address is shared > -- IPv4 address is the concatenation of the IPv4 prefix provided in = the BMR and the IPv4 suffix provided by the EA bits > -- if the result is not a /32, error >=20 > - Case 2: PSID is embedded in the EA bits > -- true if the sum (o + r) is greater than 32, where o is the number = of EA bits as indicated by the BMR, and r is the length of the IPv4 = prefix supplied by the BMR > -- shared IPv4 address is the concatenation of the IPv4 prefix = supplied by the BMR and as many of the high-order bits within the EA bit = field as required to make up a /32 > -- PSID is given by the remaining lower-order bits in the EA bit field >=20 > - Case 3: non-shared IPv4 address or prefix > -- true if the sum (o + r) as defined above is less than or equal to = 32 > -- IPv4 address or prefix is equal to the concatenation of the IPv4 = prefix as supplied by the BMR with the entire contents of the EA bit = field. >=20 > 5.2.2 Deriving the IPv6 Address To Use On the MAP Interface >=20 > - MAP IPv6 address is given by the concatenation of the provisioned = End-User IPv6 Prefix with an interface identifier derived as described = in Section 6. >=20 > - this applies for both hub-and-spoke and mesh mode >=20 > 5.3 Deriving the MAP IPv6 Address =46rom the Destination IPv4 Address = and Port and the Matching Forwarding Mapping Rule (Mesh Mode Only) >=20 > - locate the applicable Mapping Rule by longest match on rule IPv4 = address/prefix >=20 > - Derive the target End-User IPv6 prefix less the subnet identifier as = follows: >=20 > -- Case 1: length of the EA field as given by the selected Mapping = Rule is 0 > --- target End-User IPv6 prefix (less the subnet identifier) is equal = to the IPv6 prefix provided by the selected Mapping Rule >=20 > -- Case 2: sum (o + r) is less than or equal to 32, where o and r are = as defined in Section 5.2 > --- implies destination IPv4 address/prefix is dedicated to = destination CE > --- EA bit field is equal to the highest-order o bits of the = destination IPv4 address not contained in the IPv4 address/prefix = provided by the selected Mapping Rule > --- target End-User IPv6 prefix (less the subnet identifier) is equal = to the IPv6 prefix provided by the selected Mapping Rule followed in = concatenation with the derived EA bit field >=20 > -- Case 3: sum (o + r) as defined above is greater than 32 > --- implies destination IPv4 address/prefix is shared > --- set the high-order portion of the EA bit field equal to the = low-order (32 - r) bits of the destination IPv4 address > --- the remaining o - (32 - r) bits of the EA bit field are equal to = the high-order bits of the destination port number, beginning with the = bit after the offset given by the selected Mapping Rule (default =3D 6) > --- target End-User IPv6 prefix (less the subnet identifier) is equal = to the IPv6 prefix provided by the selected Mapping Rule followed in = concatenation with the derived EA bit field >=20 > - subnet identifier portion of the End-User IPv6 prefix is all zeroes >=20 > - End-User MAP Address is equal to the End-User IPv6 prefix = concatenated with an interface identifier (IID) derived as described in = Section 6. >=20 > Tom Taylor >=20 >=20 > On 13/02/2013 3:07 AM, Ole Troan wrote: >> I agree with Tom's proposed changes. >> I'll put them in a upcoming revision 05, if no-one objects. >> (I still think we can do a WGLC on revision 04). >>=20 >> cheers, >> Ole >>=20 >>=20 >>> Remark: I'm not sure the two bullets (quoted further down) tell the = full story as they stand. I propose to modify them as follows: >>>=20 >>> 1. Basic Mapping Rule (BMR) - mandatory. There can only be one >>> Basic Mapping Rule per End-user IPv6 prefix. In combination >>> with the End-user IPv6 prefix, the Basic Mapping Rule is used >>> to derive the IPv4 prefix, address, or shared address and >>> the PSID assigned to the CE. >>>=20 >>> 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. >>> The Basic Mapping Rule is also a Forwarding Mapping Rule. = Each >>> Forwarding Mapping Rule will result in an entry in the Rules >>> table for the Rule IPv4 prefix. Given a destination IPv4 = address >>> and port within the MAP domain, a MAP node can use the = matching >>> FMR to derive the End-user IPv6 address of the interface = through >>> which that destination address-port combination can be = reached. >>>=20 >>>=20 >>> On 12/02/2013 9:22 AM, Ole Troan wrote: >>>> Tom, >>>>=20 >>>>> Thanks. What about the assertions in the bullets? >>>>=20 >>>> sorry, may be my short term memory... what do you mean? >>>>=20 >>>> cheers, >>>> Ole >>>>=20 >>>>=20 >>>>>=20 >>>>> On 12/02/2013 3:27 AM, Ole Troan wrote: >>>>>> Tom, >>>>>>=20 >>>>>>> I'm still hoping to see a response to this. >>>>>>>=20 >>>>>>> On 06/02/2013 8:42 AM, Tom Taylor wrote: >>>>>>>> Section 5 of the latest version of MAP has the following: >>>>>>>>=20 >>>>>>>> 1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 = prefix, >>>>>>>> address or port set assignment. There can only be one = Basic >>>>>>>> Mapping Rule per End-user IPv6 prefix. The Basic = Mapping Rule is >>>>>>>> used to configure the MAP IPv6 address or prefix. >>>>>>>>=20 >>>>>>>> 2. Forwarding Mapping Rule (FMR) - optional, used for = forwarding. >>>>>>>> The Basic Mapping Rule is also a Forwarding Mapping = Rule. Each >>>>>>>> Forwarding Mapping Rule will result in an entry in the = Rules >>>>>>>> table for the Rule IPv4 prefix. >>>>>>>>=20 >>>>>>>> Question: there will always be a BMR. In the absence of = additional >>>>>>>> rules, how does a CE know whether it can use the BMR for = forwarding or >>>>>>>> must always use the default rule? >>>>>>=20 >>>>>> the answer to that is in section 7, last bullet. >>>>>>=20 >>>>>> that is, the MAP CE must be configured to be in hub and spoke = mode or mesh mode. >>>>>> which mode it is in decided if the BMR is used for forwarding or = not. >>>>>>=20 >>>>>> cheers, >>>>>> Ole >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >>=20 From eleven.fuyu@huawei.com Mon Feb 25 02:07:40 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE0421F8FA1; Mon, 25 Feb 2013 02:07:40 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuLThY4SHETl; Mon, 25 Feb 2013 02:07:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B937121F9292; Mon, 25 Feb 2013 02:07:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOT64458; Mon, 25 Feb 2013 10:07:38 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Feb 2013 10:06:43 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Feb 2013 10:07:32 +0000 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.31]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Mon, 25 Feb 2013 18:07:25 +0800 From: "Fuyu (Eleven)" To: "i-d-announce@ietf.org" Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-dslite-mib-02.txt Thread-Index: AQHOEz110azbnJ4lBEymkuJL1605Y5iKVKNg Date: Mon, 25 Feb 2013 10:07:25 +0000 Message-ID: References: <20130225094945.6208.61702.idtracker@ietfa.amsl.com> In-Reply-To: <20130225094945.6208.61702.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-mib-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 10:07:41 -0000 Dear All, We have updated a new version of DS-Lite MIB based on Chair's comments.= The main changes are: 1) Correct some errors by using a MIB validator. 2) Redefine some objects which can't be imported from NAT MIB. 3) The top level division of DS-Lite MIB are separated into objects, no= tification, and conformance to follow the recommended style. Reviews and comments are appreciated. Thank you. =20 Cheers Yu -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of internet-drafts@ietf.org Sent: Monday, February 25, 2013 5:50 PM To: i-d-announce@ietf.org Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-mib-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : DS-Lite Management Information Base (MIB) Author(s) : Yu Fu Sheng Jiang Jiang Dong Yuchi Chen Filename : draft-ietf-softwire-dslite-mib-02.txt Pages : 27 Date : 2013-02-25 Abstract: This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for DS-Lite. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-dslite-mib-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-dslite-mib-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From internet-drafts@ietf.org Mon Feb 25 02:17:06 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E52B21F92A3; Mon, 25 Feb 2013 02:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFVYsoKIU7Uu; Mon, 25 Feb 2013 02:17:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722AE21F929D; Mon, 25 Feb 2013 02:17:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225101705.6197.25350.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 02:17:05 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-dhcp-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 10:17:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : DHCPv6 Options for Mapping of Address and Port Author(s) : Tomasz Mrugalski Ole Troan Wojciech Dec Congxiao Bao Leaf Y. Yeh Xiaohong Deng Filename : draft-ietf-softwire-map-dhcp-03.txt Pages : 20 Date : 2013-02-25 Abstract: This document specifies DHCPv6 options for the provisioning of Mapping of Address and Port (MAP) Customer Edge (CE) devices, based on the MAP paramaters defined in [I-D.ietf-softwire-map]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-dhcp-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tomasz.mrugalski@gmail.com Mon Feb 25 02:36:47 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7780B21F9112 for ; Mon, 25 Feb 2013 02:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2V+D6VH9lHS for ; Mon, 25 Feb 2013 02:36:47 -0800 (PST) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by ietfa.amsl.com (Postfix) with ESMTP id AA5A121F90F4 for ; Mon, 25 Feb 2013 02:36:46 -0800 (PST) Received: by mail-ea0-f182.google.com with SMTP id a12so1166627eaa.41 for ; Mon, 25 Feb 2013 02:36:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=YI2xYjocC2czg/x8sp7pzvYqFOnYtxiTTTsqtZUtpt0=; b=LVICbqJFFoPrD7V9yJrwE0Rx5G+0KxQ0Au/8ZTKMO/vsp4lf9qZKqqSqiIa/py5Pb7 vMUfenB1keuEVnIY4f900aHY6icFZjP1jCmyD0EWVly2b3lqYZMvM5T6bHBfZ9GOF/cl aE8qFuFScbOQyBozFwL29I1ZD5fvi3oH4zWLz5JDaMg+bKlrRg07nEmKmUAJD9TH6BBA aw+P0HUCVDB0MpG3eTrKK4kahPBX5oUSy7cpw4BzzMhCS0X2M55ciJimTRiwOUIq8wau zqmwk10NTJqYVUDMhGb3H11iqHJnuGyxpCrcdb4i4fNAz3NwxQaYfxYrkN0F36E4TzYf Gj4w== X-Received: by 10.14.179.5 with SMTP id g5mr37667527eem.41.1361788605790; Mon, 25 Feb 2013 02:36:45 -0800 (PST) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id s3sm17592969eem.4.2013.02.25.02.36.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 02:36:44 -0800 (PST) Message-ID: <512B3EB7.2070103@gmail.com> Date: Mon, 25 Feb 2013 11:36:39 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <20130225101705.6197.25350.idtracker@ietfa.amsl.com> In-Reply-To: <20130225101705.6197.25350.idtracker@ietfa.amsl.com> X-TagToolbar-Keys: D20130225113639004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-dhcp-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 10:36:47 -0000 On 25.02.2013 11:17, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Softwires Working Group of the IETF. > > Title : DHCPv6 Options for Mapping of Address and Port > Author(s) : Tomasz Mrugalski > Ole Troan > Wojciech Dec > Congxiao Bao > Leaf Y. Yeh > Xiaohong Deng > Filename : draft-ietf-softwire-map-dhcp-03.txt > Pages : 20 > Date : 2013-02-25 > > Abstract: > This document specifies DHCPv6 options for the provisioning of > Mapping of Address and Port (MAP) Customer Edge (CE) devices, based > on the MAP paramaters defined in [I-D.ietf-softwire-map]. > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp Dear group, This is an minor update to the map-dhcp draft. This time we made couple small editorial changes in examples (we hope the examples are now easier to read), updated authors affiliations, cleaned up references and fixed issues reported by idnits. Cheers, Tomek From despres.remi@laposte.net Mon Feb 25 03:22:13 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C7021F92BB for ; Mon, 25 Feb 2013 03:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt+-dnE2YjY0 for ; Mon, 25 Feb 2013 03:22:12 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878B221F92AF for ; Mon, 25 Feb 2013 03:22:12 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id A4D5B7000135; Mon, 25 Feb 2013 12:22:10 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id D7F087000133; Mon, 25 Feb 2013 12:22:09 +0100 (CET) X-SFR-UUID: 20130225112209884.D7F087000133@msfrf2118.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <512B3EB7.2070103@gmail.com> Date: Mon, 25 Feb 2013 12:22:07 +0100 Message-Id: <8406D993-69B6-4CBE-86F9-41FBF32F4C70@laposte.net> References: <20130225101705.6197.25350.idtracker@ietfa.amsl.com> <512B3EB7.2070103@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-dhcp-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 11:22:13 -0000 Hello, Tomek, Two comments related to recent discussions: 1. The PSID-len parameter of section 4.5 MUST NOT be used in BMRs that = apply to several CEs (the general case in stateless use of MAP). If 1:1 = mapping must be covered by MAP (next point), this should be noted in = the text. 2. Whether MAP must include specific parameters to support 1:1 mappings = (namely PSID-len and PSID) doesn't seem to have reached consensus. As a = minimum this justifies at this stage an editor's note (IMHO). Regards, RD =20 Le 2013-02-25 =E0 11:36, Tomek Mrugalski a = =E9crit : > On 25.02.2013 11:17, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Softwires Working Group of the IETF. >>=20 >> Title : DHCPv6 Options for Mapping of Address and Port >> Author(s) : Tomasz Mrugalski >> Ole Troan >> Wojciech Dec >> Congxiao Bao >> Leaf Y. Yeh >> Xiaohong Deng >> Filename : draft-ietf-softwire-map-dhcp-03.txt >> Pages : 20 >> Date : 2013-02-25 >>=20 >> Abstract: >> This document specifies DHCPv6 options for the provisioning of >> Mapping of Address and Port (MAP) Customer Edge (CE) devices, based >> on the MAP paramaters defined in [I-D.ietf-softwire-map]. >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp > Dear group, >=20 > This is an minor update to the map-dhcp draft. This time we made = couple > small editorial changes in examples (we hope the examples are now = easier > to read), updated authors affiliations, cleaned up references and = fixed > issues reported by idnits. >=20 > Cheers, > Tomek >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From internet-drafts@ietf.org Mon Feb 25 04:08:15 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96E221F8FD9; Mon, 25 Feb 2013 04:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAuKx37Q6rI7; Mon, 25 Feb 2013 04:08:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84B921F8FA4; Mon, 25 Feb 2013 04:08:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225120814.5403.6554.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 04:08:14 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-deployment-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 12:08:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Mapping of Address and Port (MAP) - Deployment Considera= tions Author(s) : Qiong Sun Maoke Chen Gang Chen Tina Tsou Simon Perreault Filename : draft-ietf-softwire-map-deployment-01.txt Pages : 32 Date : 2013-02-25 Abstract: This document describes when and how an operator uses the technique of Mapping of Address and Port (MAP) for the IPv4 residual deployment in the IPv6-dominant domain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-deployment There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-deployment-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-deployment-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tom.taylor.stds@gmail.com Mon Feb 25 04:56:25 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D4821F92ED for ; Mon, 25 Feb 2013 04:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j37T07RWwWK for ; Mon, 25 Feb 2013 04:56:24 -0800 (PST) Received: from mail-ia0-x22b.google.com (ia-in-x022b.1e100.net [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 737B721F92E5 for ; Mon, 25 Feb 2013 04:56:24 -0800 (PST) Received: by mail-ia0-f171.google.com with SMTP id z13so2408592iaz.16 for ; Mon, 25 Feb 2013 04:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=issyooSJLCotNM/5IqDkcqlgu19wurvDGhAxGR0xt/w=; b=aCgUZ1IJwDotV5WOCq+04FojUZ+JD3IkM0X9y4a3VHdPw27PaBGuxEuFEjETRoQVCv pTo7/LvizjzxZrgO4oI2UxWfuNW8IDuc2MyZkzbfe1Yk3fAxfqlTgckkMdVaOSEnvZTq f+3bKUjXN8UvwMtuzs/cQOcCu1lX16ApZOqPV/3v9PmwcZdhIQY5a/z3C7vdAn1B5RE0 sUNLuIkP0yr9JzxzTUhTq+WBBajqlNaPzQZLHw76GrIm17FfqaBxPI+au3jVmnkZJJMT EzHz/NAWYcQRXQaRFrog9eyx2dSTTTZbJ7A1Kb7O8RxFz+9Fnqtoe5/JT3r6+5THc7vm tDJw== X-Received: by 10.50.135.74 with SMTP id pq10mr3275235igb.46.1361796984082; Mon, 25 Feb 2013 04:56:24 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-101-174.tor.primus.ca. [173.206.101.174]) by mx.google.com with ESMTPS id xe9sm3843631igb.7.2013.02.25.04.56.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 04:56:23 -0800 (PST) Message-ID: <512B5F76.2040106@gmail.com> Date: Mon, 25 Feb 2013 07:56:22 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Ole Troan References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> <511AE8E9.1080805@gmail.com> <512640A8.6040407@gmail.com> <675E9657-7AE4-455D-8EF8-A759378A65E9@cisco.com> In-Reply-To: <675E9657-7AE4-455D-8EF8-A759378A65E9@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130225-0, 25/02/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 12:56:25 -0000 I really didn't expect this argument. These are not use cases; they are the procedures necessary to calculate the bits that go on the wire due to the complexity of the MAP formulation. Take a look at the code being implemented in your routers and you will see similar branches in logic or variations on them. What would go into a deployment document would be how to apply these different formulations to particular network situations. Tom On 25/02/2013 4:51 AM, Ole Troan wrote: > Tom, et, al, > > thanks for the suggestion. I would lean towards pushing back on rewriting section 5, on the grounds > that this is a set of generic tools and that specific use cases rather could go in a deployment document. > > does anyone else have strong opinions on current text versus Tom's proposed changes? > > cheers, > Ole > > On Feb 21, 2013, at 16:43 , Tom Taylor wrote: > >> The two bullets below were actually a "Trojan Horse" of sorts. They set the agenda for Sections 5.2 and 5.3 respectively. I think those two sections should have different titles to start with: >> >> 5.2 Provisioning the MAP IPv4 Address, MAP IPv6 Address, and Port Set Identifier (PSID) At a CE >> >> 5.2.1 Deriving the IPv4 Address and PSID From the End-User IPv6 Prefix and the Basic Mapping Rule >> >> 5.2.2 Deriving the IPv6 Address To Use On the MAP Interface >> >> 5.3 Deriving the MAP IPv6 Address From the IPv4 Address and Port and the Matching Forwarding Mapping Rule (Mesh Mode Only) >> >> The procedure described in each section should then match the title. I'll sketch the flow here, but I can supply detailed text if desired. >> >> >> 5.2.1 Deriving the IPv4 Address and PSID From the End-User IPv6 Prefix and the Basic Mapping Rule >> >> - distinguishing the Basic Mapping Rule (BMR) from other mapping rules that are provisioned >> >> - locating the Extended Address (EA) bits in the End-User IPv6 Prefix >> >> - Case 1: Port set identifier (PSID) is explicitly provisioned separately from the BMR >> -- IPv4 address is shared >> -- IPv4 address is the concatenation of the IPv4 prefix provided in the BMR and the IPv4 suffix provided by the EA bits >> -- if the result is not a /32, error >> >> - Case 2: PSID is embedded in the EA bits >> -- true if the sum (o + r) is greater than 32, where o is the number of EA bits as indicated by the BMR, and r is the length of the IPv4 prefix supplied by the BMR >> -- shared IPv4 address is the concatenation of the IPv4 prefix supplied by the BMR and as many of the high-order bits within the EA bit field as required to make up a /32 >> -- PSID is given by the remaining lower-order bits in the EA bit field >> >> - Case 3: non-shared IPv4 address or prefix >> -- true if the sum (o + r) as defined above is less than or equal to 32 >> -- IPv4 address or prefix is equal to the concatenation of the IPv4 prefix as supplied by the BMR with the entire contents of the EA bit field. >> >> 5.2.2 Deriving the IPv6 Address To Use On the MAP Interface >> >> - MAP IPv6 address is given by the concatenation of the provisioned End-User IPv6 Prefix with an interface identifier derived as described in Section 6. >> >> - this applies for both hub-and-spoke and mesh mode >> >> 5.3 Deriving the MAP IPv6 Address From the Destination IPv4 Address and Port and the Matching Forwarding Mapping Rule (Mesh Mode Only) >> >> - locate the applicable Mapping Rule by longest match on rule IPv4 address/prefix >> >> - Derive the target End-User IPv6 prefix less the subnet identifier as follows: >> >> -- Case 1: length of the EA field as given by the selected Mapping Rule is 0 >> --- target End-User IPv6 prefix (less the subnet identifier) is equal to the IPv6 prefix provided by the selected Mapping Rule >> >> -- Case 2: sum (o + r) is less than or equal to 32, where o and r are as defined in Section 5.2 >> --- implies destination IPv4 address/prefix is dedicated to destination CE >> --- EA bit field is equal to the highest-order o bits of the destination IPv4 address not contained in the IPv4 address/prefix provided by the selected Mapping Rule >> --- target End-User IPv6 prefix (less the subnet identifier) is equal to the IPv6 prefix provided by the selected Mapping Rule followed in concatenation with the derived EA bit field >> >> -- Case 3: sum (o + r) as defined above is greater than 32 >> --- implies destination IPv4 address/prefix is shared >> --- set the high-order portion of the EA bit field equal to the low-order (32 - r) bits of the destination IPv4 address >> --- the remaining o - (32 - r) bits of the EA bit field are equal to the high-order bits of the destination port number, beginning with the bit after the offset given by the selected Mapping Rule (default = 6) >> --- target End-User IPv6 prefix (less the subnet identifier) is equal to the IPv6 prefix provided by the selected Mapping Rule followed in concatenation with the derived EA bit field >> >> - subnet identifier portion of the End-User IPv6 prefix is all zeroes >> >> - End-User MAP Address is equal to the End-User IPv6 prefix concatenated with an interface identifier (IID) derived as described in Section 6. >> >> Tom Taylor >> >> >> On 13/02/2013 3:07 AM, Ole Troan wrote: >>> I agree with Tom's proposed changes. >>> I'll put them in a upcoming revision 05, if no-one objects. >>> (I still think we can do a WGLC on revision 04). >>> >>> cheers, >>> Ole >>> >>> >>>> Remark: I'm not sure the two bullets (quoted further down) tell the full story as they stand. I propose to modify them as follows: >>>> >>>> 1. Basic Mapping Rule (BMR) - mandatory. There can only be one >>>> Basic Mapping Rule per End-user IPv6 prefix. In combination >>>> with the End-user IPv6 prefix, the Basic Mapping Rule is used >>>> to derive the IPv4 prefix, address, or shared address and >>>> the PSID assigned to the CE. >>>> >>>> 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. >>>> The Basic Mapping Rule is also a Forwarding Mapping Rule. Each >>>> Forwarding Mapping Rule will result in an entry in the Rules >>>> table for the Rule IPv4 prefix. Given a destination IPv4 address >>>> and port within the MAP domain, a MAP node can use the matching >>>> FMR to derive the End-user IPv6 address of the interface through >>>> which that destination address-port combination can be reached. >>>> >>>> >>>> On 12/02/2013 9:22 AM, Ole Troan wrote: >>>>> Tom, >>>>> >>>>>> Thanks. What about the assertions in the bullets? >>>>> >>>>> sorry, may be my short term memory... what do you mean? >>>>> >>>>> cheers, >>>>> Ole >>>>> >>>>> >>>>>> >>>>>> On 12/02/2013 3:27 AM, Ole Troan wrote: >>>>>>> Tom, >>>>>>> >>>>>>>> I'm still hoping to see a response to this. >>>>>>>> >>>>>>>> On 06/02/2013 8:42 AM, Tom Taylor wrote: >>>>>>>>> Section 5 of the latest version of MAP has the following: >>>>>>>>> >>>>>>>>> 1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 prefix, >>>>>>>>> address or port set assignment. There can only be one Basic >>>>>>>>> Mapping Rule per End-user IPv6 prefix. The Basic Mapping Rule is >>>>>>>>> used to configure the MAP IPv6 address or prefix. >>>>>>>>> >>>>>>>>> 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. >>>>>>>>> The Basic Mapping Rule is also a Forwarding Mapping Rule. Each >>>>>>>>> Forwarding Mapping Rule will result in an entry in the Rules >>>>>>>>> table for the Rule IPv4 prefix. >>>>>>>>> >>>>>>>>> Question: there will always be a BMR. In the absence of additional >>>>>>>>> rules, how does a CE know whether it can use the BMR for forwarding or >>>>>>>>> must always use the default rule? >>>>>>> >>>>>>> the answer to that is in section 7, last bullet. >>>>>>> >>>>>>> that is, the MAP CE must be configured to be in hub and spoke mode or mesh mode. >>>>>>> which mode it is in decided if the BMR is used for forwarding or not. >>>>>>> >>>>>>> cheers, >>>>>>> Ole >>>>>>> >>>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> > > From ot@cisco.com Mon Feb 25 05:17:27 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A96321F9325 for ; Mon, 25 Feb 2013 05:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.853 X-Spam-Level: X-Spam-Status: No, score=-9.853 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKzdbJAnFm8i for ; Mon, 25 Feb 2013 05:17:25 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 391ED21F9328 for ; Mon, 25 Feb 2013 05:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9449; q=dns/txt; s=iport; t=1361798245; x=1363007845; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/K/FztwkoNVY0Bs7VX2wZ0SfDkEwy8btFeWnbarx1Yg=; b=ES5eI6M84vB0/p2BO66FbkM5hrAvTN7eo4/eRBVK0RS0ylEZgwnwJCcT 3T9s/T+u2bRMxNrqv7lg8h0TDFpDeJZ8HvDWJP61qFEUsiZULpSgnmJD7 2xoi2+WyvQRyMRq3eWr8sViTTpVqu+NYOak2Dyw+yq3n49q98Qo3l+7tQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKtjK1GQ/khR/2dsb2JhbABFwVOBBBZzgh8BAQEDAQEBATc0CwULCxguIQYwBhOIAQMJBgy1JQ2JIQSMN4IkMweCX2EDknyBZIFdi06FF4MI X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; d="scan'208";a="12047588" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 25 Feb 2013 13:17:23 +0000 Received: from dhcp-lys02-vla252-10-147-116-80.cisco.com (dhcp-lys02-vla252-10-147-116-80.cisco.com [10.147.116.80]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1PDHN3D002095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Feb 2013 13:17:23 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <512B5F76.2040106@gmail.com> Date: Mon, 25 Feb 2013 14:17:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8B888D24-C8AF-413A-ACB9-1FA307E5A148@cisco.com> References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> <511AE8E9.1080805@gmail.com> <512640A8.6040407@gmail.com> <675E9657-7AE4-455D-8EF8-A759378A65E9@cisco.com> <512B5F76.2040106@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 13:17:27 -0000 Tom, to state it another way. I don't want rewrite section 5, unless there is = a clear benefit in doing so. I'm not against better text of course, and if you want to propose an = alternative section 5, then the working group can decide which version they want. cheers, Ole On Feb 25, 2013, at 13:56 , Tom Taylor = wrote: > I really didn't expect this argument. These are not use cases; they = are the procedures necessary to calculate the bits that go on the wire = due to the complexity of the MAP formulation. Take a look at the code = being implemented in your routers and you will see similar branches in = logic or variations on them. What would go into a deployment document = would be how to apply these different formulations to particular network = situations. >=20 > Tom >=20 > On 25/02/2013 4:51 AM, Ole Troan wrote: >> Tom, et, al, >>=20 >> thanks for the suggestion. I would lean towards pushing back on = rewriting section 5, on the grounds >> that this is a set of generic tools and that specific use cases = rather could go in a deployment document. >>=20 >> does anyone else have strong opinions on current text versus Tom's = proposed changes? >>=20 >> cheers, >> Ole >>=20 >> On Feb 21, 2013, at 16:43 , Tom Taylor = wrote: >>=20 >>> The two bullets below were actually a "Trojan Horse" of sorts. They = set the agenda for Sections 5.2 and 5.3 respectively. I think those two = sections should have different titles to start with: >>>=20 >>> 5.2 Provisioning the MAP IPv4 Address, MAP IPv6 Address, and Port = Set Identifier (PSID) At a CE >>>=20 >>> 5.2.1 Deriving the IPv4 Address and PSID =46rom the End-User IPv6 = Prefix and the Basic Mapping Rule >>>=20 >>> 5.2.2 Deriving the IPv6 Address To Use On the MAP Interface >>>=20 >>> 5.3 Deriving the MAP IPv6 Address =46rom the IPv4 Address and Port = and the Matching Forwarding Mapping Rule (Mesh Mode Only) >>>=20 >>> The procedure described in each section should then match the title. = I'll sketch the flow here, but I can supply detailed text if desired. >>>=20 >>>=20 >>> 5.2.1 Deriving the IPv4 Address and PSID =46rom the End-User IPv6 = Prefix and the Basic Mapping Rule >>>=20 >>> - distinguishing the Basic Mapping Rule (BMR) from other mapping = rules that are provisioned >>>=20 >>> - locating the Extended Address (EA) bits in the End-User IPv6 = Prefix >>>=20 >>> - Case 1: Port set identifier (PSID) is explicitly provisioned = separately from the BMR >>> -- IPv4 address is shared >>> -- IPv4 address is the concatenation of the IPv4 prefix provided in = the BMR and the IPv4 suffix provided by the EA bits >>> -- if the result is not a /32, error >>>=20 >>> - Case 2: PSID is embedded in the EA bits >>> -- true if the sum (o + r) is greater than 32, where o is the number = of EA bits as indicated by the BMR, and r is the length of the IPv4 = prefix supplied by the BMR >>> -- shared IPv4 address is the concatenation of the IPv4 prefix = supplied by the BMR and as many of the high-order bits within the EA bit = field as required to make up a /32 >>> -- PSID is given by the remaining lower-order bits in the EA bit = field >>>=20 >>> - Case 3: non-shared IPv4 address or prefix >>> -- true if the sum (o + r) as defined above is less than or equal to = 32 >>> -- IPv4 address or prefix is equal to the concatenation of the IPv4 = prefix as supplied by the BMR with the entire contents of the EA bit = field. >>>=20 >>> 5.2.2 Deriving the IPv6 Address To Use On the MAP Interface >>>=20 >>> - MAP IPv6 address is given by the concatenation of the provisioned = End-User IPv6 Prefix with an interface identifier derived as described = in Section 6. >>>=20 >>> - this applies for both hub-and-spoke and mesh mode >>>=20 >>> 5.3 Deriving the MAP IPv6 Address =46rom the Destination IPv4 = Address and Port and the Matching Forwarding Mapping Rule (Mesh Mode = Only) >>>=20 >>> - locate the applicable Mapping Rule by longest match on rule IPv4 = address/prefix >>>=20 >>> - Derive the target End-User IPv6 prefix less the subnet identifier = as follows: >>>=20 >>> -- Case 1: length of the EA field as given by the selected Mapping = Rule is 0 >>> --- target End-User IPv6 prefix (less the subnet identifier) is = equal to the IPv6 prefix provided by the selected Mapping Rule >>>=20 >>> -- Case 2: sum (o + r) is less than or equal to 32, where o and r = are as defined in Section 5.2 >>> --- implies destination IPv4 address/prefix is dedicated to = destination CE >>> --- EA bit field is equal to the highest-order o bits of the = destination IPv4 address not contained in the IPv4 address/prefix = provided by the selected Mapping Rule >>> --- target End-User IPv6 prefix (less the subnet identifier) is = equal to the IPv6 prefix provided by the selected Mapping Rule followed = in concatenation with the derived EA bit field >>>=20 >>> -- Case 3: sum (o + r) as defined above is greater than 32 >>> --- implies destination IPv4 address/prefix is shared >>> --- set the high-order portion of the EA bit field equal to the = low-order (32 - r) bits of the destination IPv4 address >>> --- the remaining o - (32 - r) bits of the EA bit field are equal to = the high-order bits of the destination port number, beginning with the = bit after the offset given by the selected Mapping Rule (default =3D 6) >>> --- target End-User IPv6 prefix (less the subnet identifier) is = equal to the IPv6 prefix provided by the selected Mapping Rule followed = in concatenation with the derived EA bit field >>>=20 >>> - subnet identifier portion of the End-User IPv6 prefix is all = zeroes >>>=20 >>> - End-User MAP Address is equal to the End-User IPv6 prefix = concatenated with an interface identifier (IID) derived as described in = Section 6. >>>=20 >>> Tom Taylor >>>=20 >>>=20 >>> On 13/02/2013 3:07 AM, Ole Troan wrote: >>>> I agree with Tom's proposed changes. >>>> I'll put them in a upcoming revision 05, if no-one objects. >>>> (I still think we can do a WGLC on revision 04). >>>>=20 >>>> cheers, >>>> Ole >>>>=20 >>>>=20 >>>>> Remark: I'm not sure the two bullets (quoted further down) tell = the full story as they stand. I propose to modify them as follows: >>>>>=20 >>>>> 1. Basic Mapping Rule (BMR) - mandatory. There can only be one >>>>> Basic Mapping Rule per End-user IPv6 prefix. In combination >>>>> with the End-user IPv6 prefix, the Basic Mapping Rule is = used >>>>> to derive the IPv4 prefix, address, or shared address and >>>>> the PSID assigned to the CE. >>>>>=20 >>>>> 2. Forwarding Mapping Rule (FMR) - optional, used for = forwarding. >>>>> The Basic Mapping Rule is also a Forwarding Mapping Rule. = Each >>>>> Forwarding Mapping Rule will result in an entry in the Rules >>>>> table for the Rule IPv4 prefix. Given a destination IPv4 = address >>>>> and port within the MAP domain, a MAP node can use the = matching >>>>> FMR to derive the End-user IPv6 address of the interface = through >>>>> which that destination address-port combination can be = reached. >>>>>=20 >>>>>=20 >>>>> On 12/02/2013 9:22 AM, Ole Troan wrote: >>>>>> Tom, >>>>>>=20 >>>>>>> Thanks. What about the assertions in the bullets? >>>>>>=20 >>>>>> sorry, may be my short term memory... what do you mean? >>>>>>=20 >>>>>> cheers, >>>>>> Ole >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> On 12/02/2013 3:27 AM, Ole Troan wrote: >>>>>>>> Tom, >>>>>>>>=20 >>>>>>>>> I'm still hoping to see a response to this. >>>>>>>>>=20 >>>>>>>>> On 06/02/2013 8:42 AM, Tom Taylor wrote: >>>>>>>>>> Section 5 of the latest version of MAP has the following: >>>>>>>>>>=20 >>>>>>>>>> 1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 = prefix, >>>>>>>>>> address or port set assignment. There can only be one = Basic >>>>>>>>>> Mapping Rule per End-user IPv6 prefix. The Basic = Mapping Rule is >>>>>>>>>> used to configure the MAP IPv6 address or prefix. >>>>>>>>>>=20 >>>>>>>>>> 2. Forwarding Mapping Rule (FMR) - optional, used for = forwarding. >>>>>>>>>> The Basic Mapping Rule is also a Forwarding Mapping = Rule. Each >>>>>>>>>> Forwarding Mapping Rule will result in an entry in the = Rules >>>>>>>>>> table for the Rule IPv4 prefix. >>>>>>>>>>=20 >>>>>>>>>> Question: there will always be a BMR. In the absence of = additional >>>>>>>>>> rules, how does a CE know whether it can use the BMR for = forwarding or >>>>>>>>>> must always use the default rule? >>>>>>>>=20 >>>>>>>> the answer to that is in section 7, last bullet. >>>>>>>>=20 >>>>>>>> that is, the MAP CE must be configured to be in hub and spoke = mode or mesh mode. >>>>>>>> which mode it is in decided if the BMR is used for forwarding = or not. >>>>>>>>=20 >>>>>>>> cheers, >>>>>>>> Ole >>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>>>=20 >>=20 >>=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From tom.taylor.stds@gmail.com Mon Feb 25 07:05:48 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0EF21F932A for ; Mon, 25 Feb 2013 07:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5qvcokZP2x5 for ; Mon, 25 Feb 2013 07:05:48 -0800 (PST) Received: from mail-ie0-x22b.google.com (ie-in-x022b.1e100.net [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE6821F9325 for ; Mon, 25 Feb 2013 07:05:46 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id 10so3196199ied.30 for ; Mon, 25 Feb 2013 07:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=m+QOp8OQnEKOGHvT11XJQa/7Q4oyrjcrVLA4+XbaHtU=; b=MrFVNN4MpZF+LZ8PYmjHHJMjd1fhqx93++EX3qyWB0xwCWuN0N04Av6NL8equ2wy8u JGwHgnDByYg0NtNY/2pOp6oB+gimeTPm/rIZTJU+tnVdcXQpM/YD/qgk3f2gwUQRXuuG xr0o8yXqWB/QHPHQ/R+1p0NiNQkYmFdNPey3c1X43oLxhh4J7kJMnWWTBjY96FPpVa+j GnBdJ5mktsPAEPgbuHO6HSIJchFLRtmLsdbgcjLOcUS3RfXN11iDDgVoKQLBBbhOLvsw BaCdBU6YtNxDd85QrVI3btHJw63PY3bNSHXCITCXTaD0H+EEm9u5R2NH0k5e0MBr1Ysr KEIA== X-Received: by 10.43.18.3 with SMTP id qe3mr3633411icb.12.1361804746040; Mon, 25 Feb 2013 07:05:46 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-101-174.tor.primus.ca. [173.206.101.174]) by mx.google.com with ESMTPS id vb15sm5465862igb.9.2013.02.25.07.05.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 07:05:44 -0800 (PST) Message-ID: <512B7DC7.8040307@gmail.com> Date: Mon, 25 Feb 2013 10:05:43 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Ole Troan References: <51125DD1.4070405@gmail.com> <5119AC61.7090806@gmail.com> <996C1B2E-D4FC-4176-B468-39D60D1F3BE6@cisco.com> <511A4F05.3060400@gmail.com> <511AE8E9.1080805@gmail.com> <512640A8.6040407@gmail.com> <675E9657-7AE4-455D-8EF8-A759378A65E9@cisco.com> <512B5F76.2040106@gmail.com> <8B888D24-C8AF-413A-ACB9-1FA307E5A148@cisco.com> In-Reply-To: <8B888D24-C8AF-413A-ACB9-1FA307E5A148@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130225-0, 25/02/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires Subject: Re: [Softwires] MAP-04: BMR and forwarding rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:05:48 -0000 OK, I await the WG's verdict. On 25/02/2013 8:17 AM, Ole Troan wrote: > Tom, > > to state it another way. I don't want rewrite section 5, unless there is a clear benefit in doing so. > I'm not against better text of course, and if you want to propose an alternative section 5, then the working group > can decide which version they want. > > cheers, > Ole > ... From internet-drafts@ietf.org Mon Feb 25 07:10:57 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8724821F946B; Mon, 25 Feb 2013 07:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWknamQef06Z; Mon, 25 Feb 2013 07:10:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CD621F9478; Mon, 25 Feb 2013 07:10:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225151056.15219.61584.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 07:10:56 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-public-4over6-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:10:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Public IPv4 over IPv6 Access Network Author(s) : Yong Cui Jianping Wu Peng Wu Olivier Vautrin Yiu L. Lee Filename : draft-ietf-softwire-public-4over6-05.txt Pages : 13 Date : 2013-02-25 Abstract: When the service provider networks are upgraded to IPv6, end users will continue to demand IPv4 connectivity. This document proposes a mechanism for hosts or customer networks in IPv6 access network to build bidirectional IPv4 communication with the IPv4 Internet. The mechanism follows the hub and spokes softwire model, and uses IPv4- over-IPv6 tunnel as basic method to traverse IPv6 network. The bi- directionality of this IPv4 communication is achieved by explicitly allocating public IPv4 addresses to end users, as well as maintaining IPv4-IPv6 address binding on the border relay. This mechanism features the allocation of full IPv4 address over IPv6 network, and has been used in production for high-end IPv4 users, IPv6 transition of ICPs, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-public-4over6-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-public-4over6-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From naikumar@cisco.com Mon Feb 25 18:15:00 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C31A21E8127 for ; Mon, 25 Feb 2013 18:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OnTA31tzsyb for ; Mon, 25 Feb 2013 18:15:00 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 589F021E80E7 for ; Mon, 25 Feb 2013 18:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1767; q=dns/txt; s=iport; t=1361844900; x=1363054500; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=VHLhQltD9o4vyJULJJ1b5Kti3fYIcB8GEQNcKuPkvMI=; b=hm3QHGGjZq4cJzYxGbr1P16A5WebXFAA9W7OtUVV6XXnkWxzez/7y79F Cm7e2/WvzE5VMPP6JbvbVruMO1OkV7lGnfdFDVCGl+aRmwv9GPaLb9glw 93krQ4xDoUeXvsYCrRIqy92tadWCzODdiox0FOhdOcJawfD5sZ7pcuHmb 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACIZLFGtJXHA/2dsb2JhbABFwVyBBhZzgh8BAQEEAQEBNzQLDAQCAQgRBAEBCxQJBycLFAkIAgQOBQgBiAoMsAaQCo5dJgsCC4JZYQOSfIReijSFFIJ6DYIn X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; d="scan'208";a="181067198" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 26 Feb 2013 02:14:59 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1Q2ExiN011494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Feb 2013 02:14:59 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.17]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 20:14:59 -0600 From: "Nagendra Kumar (naikumar)" To: "softwires@ietf.org" Thread-Topic: I-D Action: draft-kumar-softwire-uet-00.txt Thread-Index: AQHODfiS/gGMspfw10KbVygILG1VZJiLcMiQgAABUaA= Date: Tue, 26 Feb 2013 02:14:59 +0000 Message-ID: <47E76F08F1BCF5458111C1939C7B9C46100760F9@xmb-rcd-x03.cisco.com> References: <20130218165352.13391.10964.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.70.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Carlos Pignataro \(cpignata\)" , "Clarence Filsfils \(cfilsfil\)" Subject: Re: [Softwires] I-D Action: draft-kumar-softwire-uet-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 02:15:00 -0000 Hi All, Below is a new draft proposed on UDP based softwire load balancing. Please = have a look and share your comments. Thanks, Nagendra -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Monday, February 18, 2013 10:24 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-kumar-softwire-uet-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : UDP Entropy Tunnel for Softwire Author(s) : Carlos Pignataro Nagendra Kumar Pradosh Mohapatra Clarence Filsfils Filename : draft-kumar-softwire-uet-00.txt Pages : 8 Date : 2013-02-18 Abstract: This document describes a method for encapsulatation of tunneled packets within UDP in order to provide per-flow entropy for load- balancing. The method is targeted for use with softwire mesh deployments that include routers which have support for load- balancing based on UDP ports and not fields in L2TPv3 or GRE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kumar-softwire-uet There's also a htmlized version available at: http://tools.ietf.org/html/draft-kumar-softwire-uet-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt From fibrib@gmail.com Tue Feb 26 19:17:59 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE2021F870C for ; Tue, 26 Feb 2013 19:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.141 X-Spam-Level: X-Spam-Status: No, score=-3.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH6C3-56GCyF for ; Tue, 26 Feb 2013 19:17:59 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D55921F870A for ; Tue, 26 Feb 2013 19:17:59 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id h1so226325oag.17 for ; Tue, 26 Feb 2013 19:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wPsJCRUvYoEg15aqySXUb+pGHtQDG8QqkZUJ9UPCo8o=; b=Zq3/GUJWePHdcrizLG0iktrW2mjqyECpYvr4Xh3qnd5FeMywcBKeGN9ixii13eegaf O7hfXquH3A3fZumNy2et6OfWYbE4idjSneDBsk8JIt1cb9a4VOa5m6KIopXWLfi5YQAy B5V6tnUmWffN2waDos/yG6Qu4m1XQ1KlmyTbgHoW8OKWKckakN9xTWaHwMffTUFLfHvU uMtKYbCBuXw4l3wBQjcpn8A8F0UdwBzuC1wk1aaNAUcHpZtGCFp28tXIqFwM8hVMnO1U irxCEMf5d7A/rcB3vqxxGRsC8YuIp25pcxygSU2cuYcJ7DsO1Mor/45qUwoWe81Hhc/g Dj3g== MIME-Version: 1.0 X-Received: by 10.182.59.20 with SMTP id v20mr575351obq.80.1361935078697; Tue, 26 Feb 2013 19:17:58 -0800 (PST) Received: by 10.76.81.129 with HTTP; Tue, 26 Feb 2013 19:17:58 -0800 (PST) In-Reply-To: <20130225120814.5403.6554.idtracker@ietfa.amsl.com> References: <20130225120814.5403.6554.idtracker@ietfa.amsl.com> Date: Wed, 27 Feb 2013 12:17:58 +0900 Message-ID: From: Maoke To: sunqiong , chengang , Tina Tsou , Simon Perreault Content-Type: multipart/alternative; boundary=14dae93a0db192af5604d6ac38ca Cc: softwires@ietf.org, Masakazu Asama Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-deployment-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 03:18:00 -0000 --14dae93a0db192af5604d6ac38ca Content-Type: text/plain; charset=ISO-8859-1 hi all, a text mistake is discovered (by Masakazu Asama-san, the developer of ASAMAP MAP implementation, thanks a lot to Asama-san!). the erratum must be included in the next revision: 4.2.5 PSID Consideration ... (para 2 reads) The default PSID offset is chosen as 4 in [I-D.ietf-softwire-map] and full-zero PSID is not permitted to use, which excludes the use of port range 0~4096. Operator may adjust the value based on actual usage, policy, and service model. ... where the *full-zero PSID is not permitted to use* is incorrect. the fact is, port range 0~4096 doesn't corresponds to the PSID = 0x000, but the offset-bits = 0x0. i.e., no matter how much the PSID value is, the full-zero offset-bits (the first 4 bits of port number, as default) is excluded from using. full-zero PSID is NO problem here. please the co-authors, and others too, do the double-check on the understanding. cheers, maoke 2013/2/25 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Softwires Working Group of the IETF. > > Title : Mapping of Address and Port (MAP) - Deployment > Considerations > Author(s) : Qiong Sun > Maoke Chen > Gang Chen > Tina Tsou > Simon Perreault > Filename : draft-ietf-softwire-map-deployment-01.txt > Pages : 32 > Date : 2013-02-25 > > Abstract: > This document describes when and how an operator uses the technique > of Mapping of Address and Port (MAP) for the IPv4 residual deployment > in the IPv6-dominant domain. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-map-deployment > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-softwire-map-deployment-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-deployment-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --14dae93a0db192af5604d6ac38ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi all,=A0

a text mistake is discovered (= by Masakazu Asama-san, the developer of ASAMAP MAP implementation, thanks a= lot to Asama-san!). the erratum must be included in the next revision:

=A04.2.5 PSID Consideration=A0
=A0 =A0...
=A0 =A0(para 2 reads)
=A0 =A0The default PSID offset is ch= osen as 4 in [I-D.ietf-softwire-map] and
=A0 =A0full-zero PSID is not p= ermitted to use, which excludes the use of
=A0 =A0port range 0~4096. Operator may adjust the value based on actual=A0 =A0usage, policy, and service model.
=A0 =A0...
=
where the *full-zero PSID is not permitted to use* is incorr= ect. the fact is, port range 0~4096 doesn't corresponds to the PSID =3D= 0x000, but the offset-bits =3D 0x0. i.e., no matter how much the PSID valu= e is, the full-zero offset-bits (the first 4 bits of port number, as defaul= t) is excluded from using. full-zero PSID is NO problem here.=A0

please the co-authors, and others too, do the double-ch= eck on the understanding.=A0

cheers,
mao= ke

2013/2/25 <internet-drafts@= ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Softwires Working Group of the IETF.
=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Mapping of Address and Port (MA= P) - Deployment Considerations
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Qiong Sun
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Maoke Chen
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gang Chen
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tina Tsou
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Simon Perreault
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-softwire-map-deploymen= t-01.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 32
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-02-25

Abstract:
=A0 =A0This document describes when and how an operator uses the technique<= br> =A0 =A0of Mapping of Address and Port (MAP) for the IPv4 residual deploymen= t
=A0 =A0in the IPv6-dominant domain.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-softwire= -map-deployment

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-softwire-map-depl= oyment-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-s= oftwire-map-deployment-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--14dae93a0db192af5604d6ac38ca-- From ssenthil@cisco.com Wed Feb 27 01:30:58 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D99021F85BB for ; Wed, 27 Feb 2013 01:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjNXaM2fzojn for ; Wed, 27 Feb 2013 01:30:58 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E782E21F8576 for ; Wed, 27 Feb 2013 01:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2680; q=dns/txt; s=iport; t=1361957458; x=1363167058; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Iy6Ui3uPrUgUYMbQpdjROGXk+wkJ6I3b4k/W40a7TTU=; b=i7q3inCwknhh+A88NIDwiVvXqtIPE3yrDi8TGTkj+0vZVbZzdQAXyfUL TnOslOBRlw9fR2VEMtjlUHiXsBRoFX3r9Zc32D2al9tVxakEROx14AgoG K9l97ersNxurZa/MFFd930d1SliT2YQi/7tIOO77hGB3bD97/a7qTIiEY c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAPSLVGtJV2a/2dsb2JhbABEwhV8FnOCIQEEgQsBGhBWFw4CBBsTh3idKKEbjmM4gl9hA4g0nneDCIIn X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; d="scan'208";a="181676098" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 27 Feb 2013 09:30:57 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1R9Uvq8026517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 27 Feb 2013 09:30:57 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.42]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 03:30:56 -0600 From: "Senthil Sivakumar (ssenthil)" To: "softwires@ietf.org" Thread-Topic: Comments on mapt-01 Thread-Index: AQHOFM0lSI/latNqnU+VZO2XMyGIFw== Date: Wed, 27 Feb 2013 09:30:56 +0000 Message-ID: In-Reply-To: <20130225151056.15219.61584.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.65.70.103] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9C7C0330C4D59346890C7E1291DE801E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Softwires] Comments on mapt-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 09:30:58 -0000 Introduction - the first paragraph needs some revision. "Experiences from initial IPv6 deployments indicate that transitioning a network providers' domain fully to IPv6 requires not only the continued support of legacy IPv4 users connected to the boundary of that domain, allowing IPv4 address sharing, but also the need for carrying out IPv6-only operational practices in that domain [, also <<<<<< Fragmented & doesn=B9t make sense. for traffic from IPv4 users. " The below sentence needs revision, I don=B9t really understand what the sentence is trying to convey. Is it saying IP encapsulation overhead is unacceptable or causes issues or what? "The translation mode is required for environments where the IP encapsulation overhead or IPv6 traffic interaction & processing (eg use of IPv6 only servers) requirements, or both, make the use of the encapsulation solution not attractive." Section 4 - Architecture would be required if the said IPv6 devices are expected to themselves to initiate s/expected to themselves to initiate/expected to initiate A standard stateless NAT64 function [RFC6145] is extended to allow stateless mapping of IPv4 and transport layer port ranges to IPv6 address space s/mapping of ipv4 and /mapping of IPv4 address and Section 6.2 "layer destination port number is in the range configured by MAP for the CE and the CE SHOULD drop any non conforming packet" Why is this drop a SHOULD instead of a MUST? It doesn=B9t seem to make any sense to process a packet that is not destined to its port range, does it? "The resulting IPv4 packet is then forwarded to the CE's NAPT function, when this is enabled," In section 6.1, the NAPT function is referred to as NAT44 function, in section 6.2 it is referred to as NAPT function. Can you make the terminology consistent - use either one or the other. Section 6.2 " When the NAPT function is not enabled". A similar sentence is needed in section 6.1, on how to handle the ipv4 packets when NAPT is not enabled Section 7 "ICMP preserving the ID field on its way to an IPv4 destination." s/on its way to/on its way back to "In all other cases, the MAP-T BR MUST derive the destination IPv6 address by simply mapping the destination IPv4 address without additional port info." What are the other cases ? How can you derive the destination IPv6 address without the port information? I assume you are talking about the ICMP errors as it is addressed separately later in the section. I would suggest clarifying what the other cases are here. Thanks Senthil From bingxuere@gmail.com Thu Feb 28 06:35:02 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7749921F855C for ; Thu, 28 Feb 2013 06:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.259 X-Spam-Level: X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW+r+M-osqJD for ; Thu, 28 Feb 2013 06:35:01 -0800 (PST) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id C5EC521F8201 for ; Thu, 28 Feb 2013 06:34:47 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id n12so3637104oag.41 for ; Thu, 28 Feb 2013 06:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=aP3bO7m5NqXZHcC4eNv5nIi8T7YkJVADhRX9QN7a9o4=; b=lilLclFoNZw5I39iQb5doQKv3K7MdZ6mYY7wuPxny7CQu8qVQjM7DLh/HruLYZl0rW my4KRQ/nrIW8MIpPXO7NXFWifc1Q9/wytwHYEfvc5x6lD3XU0CdrvOqEcfYDhQ+Ra5Pn zOyo+/dauraK6bxoP0MY11LmUITuGjrK7epLaQgfQoHpF5j+rJyjKHTvViOhMqxDe/gx I/zrHgmAtoZCTWUA8oFBKNVCMmX1l0ZicRdNDXl9N45F2MMjCfUAPFCqFjeQiN0zJSHn IrSkSOswVLQEfYZV4RLixCN3oQTyOZjbWhfeWSS+gSQeUE2JxMDDVGrUuTEuOFmoKC8F T99Q== X-Received: by 10.182.245.33 with SMTP id xl1mr5591820obc.91.1362062087331; Thu, 28 Feb 2013 06:34:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.143.162 with HTTP; Thu, 28 Feb 2013 06:34:07 -0800 (PST) In-Reply-To: References: <20130225120814.5403.6554.idtracker@ietfa.amsl.com> From: Qiong Date: Thu, 28 Feb 2013 22:34:07 +0800 Message-ID: To: Maoke Content-Type: multipart/alternative; boundary=14dae93a19a3e19b5804d6c9caa2 Cc: chengang , Masakazu Asama , sunqiong , "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-deployment-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 14:35:02 -0000 --14dae93a19a3e19b5804d6c9caa2 Content-Type: text/plain; charset=UTF-8 Hi Maoke, Masakazu Asama-san, Thanks a lot for your comment! Right, we must correct it in the next version. To WG: This new version is updated to reflect the discussion result in the last IETF meeting, covering MAP-E, MAP-T and 4rd-u. The major changes are as follows: 1) Move the difference between MAP-E, MAP-T and 4rd into one section, so hopefully the rest of the draft can be applied to these three. 2) Split references to Normative and Informative, as requested by Mark last time 3) Change the PSID consideration, as raised in the mailing list (still needs to be updated) 4) Update some references which have become RFC or WG item 5) Lots of editorial changes and cleaning Currently, the title of this draft is still MAP only, as we have not found a good term to call MAP-E, MAP-T and 4rd-u. So we would like to get advice from the working group to address this problem. Your review and comments are more than welcome. Thanks in advance ! Best wishes Qiong On Wed, Feb 27, 2013 at 11:17 AM, Maoke wrote: > hi all, > > a text mistake is discovered (by Masakazu Asama-san, the developer of > ASAMAP MAP implementation, thanks a lot to Asama-san!). the erratum must be > included in the next revision: > > 4.2.5 PSID Consideration > ... > (para 2 reads) > The default PSID offset is chosen as 4 in [I-D.ietf-softwire-map] and > full-zero PSID is not permitted to use, which excludes the use of > port range 0~4096. Operator may adjust the value based on actual > usage, policy, and service model. > ... > > where the *full-zero PSID is not permitted to use* is incorrect. the fact > is, port range 0~4096 doesn't corresponds to the PSID = 0x000, but the > offset-bits = 0x0. i.e., no matter how much the PSID value is, the > full-zero offset-bits (the first 4 bits of port number, as default) is > excluded from using. full-zero PSID is NO problem here. > > please the co-authors, and others too, do the double-check on the > understanding. > > cheers, > maoke > > 2013/2/25 > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Softwires Working Group of the IETF. >> >> Title : Mapping of Address and Port (MAP) - Deployment >> Considerations >> Author(s) : Qiong Sun >> Maoke Chen >> Gang Chen >> Tina Tsou >> Simon Perreault >> Filename : draft-ietf-softwire-map-deployment-01.txt >> Pages : 32 >> Date : 2013-02-25 >> >> Abstract: >> This document describes when and how an operator uses the technique >> of Mapping of Address and Port (MAP) for the IPv4 residual deployment >> in the IPv6-dominant domain. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-softwire-map-deployment >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-softwire-map-deployment-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-deployment-01 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --14dae93a19a3e19b5804d6c9caa2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Maoke, Masakazu Asama-san,

Thanks a = lot for your comment! Right, we must correct it in the next version.
<= div>
To WG:

This new version is upda= ted to reflect the discussion result in the last IETF meeting, covering=C2= =A0MAP-E, MAP-T and 4rd-u.=C2=A0

The major changes are as follows:
1) Move the difference between MAP-E, MAP-T and 4rd into one section, = so hopefully the rest of the draft can be applied to these three.
2) Split references to Normative and Informative, as requested by Mark= last=20 time
3) Change the PSID consideration, as raised in the mailing=20 list (still needs to be updated)
4) Update some references which have become RFC or WG item
5) Lots of editorial changes and cleaning

Currently, the title of this draft is still MAP only, as we have not fou= nd a good term to call=C2=A0MAP-E, MAP-T and 4rd-u. So we would like to get= advice from the working group to address this problem.

Your review and comments are more than welc= ome. Thanks in advance !

Best wishes
Qiong

On Wed, Feb 27, 2013 at 11:17 AM, Maoke <fibrib@gmail.com> wr= ote:
hi all,=C2=A0

a text mistake is discovere= d (by Masakazu Asama-san, the developer of ASAMAP MAP implementation, thank= s a lot to Asama-san!). the erratum must be included in the next revision:<= /div>

=C2=A04.2.5 PSID Consideration=C2=A0
=C2=A0 = =C2=A0...
=C2=A0 =C2=A0(para 2 reads)
=C2=A0 =C2=A0The = default PSID offset is chosen as 4 in [I-D.ietf-softwire-map] and
=C2=A0= =C2=A0full-zero PSID is not permitted to use, which excludes the use of =C2=A0 =C2=A0port range 0~4096. Operator may adjust the value based on ac= tual
=C2=A0 =C2=A0usage, policy, and service model.
=C2=A0 = =C2=A0...

where the *full-zero PSID is not permitt= ed to use* is incorrect. the fact is, port range 0~4096 doesn't corresp= onds to the PSID =3D 0x000, but the offset-bits =3D 0x0. i.e., no matter ho= w much the PSID value is, the full-zero offset-bits (the first 4 bits of po= rt number, as default) is excluded from using. full-zero PSID is NO problem= here.=C2=A0

please the co-authors, and others too, do the double-ch= eck on the understanding.=C2=A0

cheers,
= maoke

2013/2/25 <= internet-draf= ts@ietf.org>


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Softwires Working Group of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Mapp= ing of Address and Port (MAP) - Deployment Considerations
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Qiong Sun
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Maoke Chen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Gang Chen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Tina Tsou
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Simon Perreault
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-softwire-map-deployment-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 32 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2013-02-25

Abstract:
=C2=A0 =C2=A0This document describes when and how an operator uses the tech= nique
=C2=A0 =C2=A0of Mapping of Address and Port (MAP) for the IPv4 residual dep= loyment
=C2=A0 =C2=A0in the IPv6-dominant domain.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-softwire= -map-deployment

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-softwire-map-depl= oyment-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-s= oftwire-map-deployment-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires




--
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
C= hina Telecom Beijing Research Institude


Open source code:
lig= htweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--14dae93a19a3e19b5804d6c9caa2--