From junbi@cernet.edu.cn Wed Mar 3 04:18:43 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F373A8DA6 for ; Wed, 3 Mar 2010 04:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPwMMEimNFdm for ; Wed, 3 Mar 2010 04:18:35 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 1BC8A3A87F4 for ; Wed, 3 Mar 2010 04:18:30 -0800 (PST) Received: from junbiVAIO([59.66.53.201]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm84b8e5975; Wed, 03 Mar 2010 20:18:27 +0800 Message-ID: From: "Bi Jun" To: "SAVI Mailing List" Date: Wed, 3 Mar 2010 20:18:04 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_043A_01CABB0E.A11A6BC0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: SeB7nmXB Subject: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 12:18:43 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_043A_01CABB0E.A11A6BC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_043B_01CABB0E.A11A6BC0" ------=_NextPart_001_043B_01CABB0E.A11A6BC0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear WG members, This is the 01 version of savi-dhcp solution. Comments please. Thank you very much! Jun Bi ------=_NextPart_001_043B_01CABB0E.A11A6BC0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear WG members,
 
This is the 01 version of savi-dhcp=20 solution.
Comments please.
 
Thank you very much!
Jun Bi
------=_NextPart_001_043B_01CABB0E.A11A6BC0-- ------=_NextPart_000_043A_01CABB0E.A11A6BC0 Content-Type: text/plain; name="draft-ietf-savi-dhcp-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-savi-dhcp-01.txt" SAVI J. Bi, J. Wu, G. Yao Internet Draft CERNET Intended status: Standard Tracks F. Baker Expires: September 2010 Cisco March 3, 2010 SAVI Solution for DHCP draft-ietf-savi-dhcp-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November = 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as = Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 3, 2010. Bi Expires September 3, 2010 [Page 1] =0C Internet-Draft savi-dhcp March 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document specifies the procedure for creating bindings between a DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and an anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets generated on the local link with forged IP addresses. Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document............................ 4 3. Mechanism Overview .......................................... 4 4. Background and Related Protocols............................. 4 5. Terminology ................................................. 5 6. Conceptual Data Structures................................... 5 6.1. Binding State Table (BST)............................... 5 6.2. Filtering Table (FT).................................... 5 7. Binding States Description................................... 6 8. DHCP Scenario ............................................... 6 9. Anchor Attributes ........................................... 7 9.1. SAVI-Validation Attribute............................... 7 9.2. SAVI-DHCP-Trust Attribute............................... 7 9.3. SAVI-SAVI Attribute..................................... 8 10. Prefix Configuration........................................ 8 11. Binding Set Up ............................................. 9 11.1. Process of DHCP Snooping............................... 9 11.1.1. Initialization.................................... 9 11.1.1.1. Trigger Event................................ 9 11.1.1.2. Event Validation............................. 9 11.1.1.3. Following Actions........................... 10 11.1.2. From START to LIVE............................... 10 11.1.2.1. Trigger Event............................... 10 11.1.2.2. Event Validation............................ 10 11.1.2.3. Following Actions........................... 10 Bi Expires September 3, 2010 [Page 2] =0C Internet-Draft savi-dhcp March 2010 11.1.3. From LIVE to DETECTION........................... 12 11.1.3.2. Event Validation............................ 12 11.1.3.3. Following Actions........................... 12 11.1.4. From DETECTION to BOUND.......................... 13 11.1.4.1. Trigger Event............................... 13 11.1.4.2. Following Actions........................... 13 11.1.5. After BOUND...................................... 13 11.2. State Machine of DHCP Snooping........................ 14 12. Filtering Specification.................................... 15 12.1. Data Packet Filtering................................. 16 12.2. Control Packet Filtering.............................. 16 13. Format and Delivery of Probe Messages...................... 17 13.1. Duplicate detection................................... 17 14. Binding Remove ............................................ 17 15. Handle Anchor Off-link event............................... 18 16. About Collision in Detection............................... 18 16.1. Whether to notify the DHCP server..................... 18 16.2. The result of detection without host aware............ 18 17. Filtering during detection................................. 18 18. Binding Number Limitation.................................. 19 19. Movement without DHCP Procedure............................ 19 20. MLD Consideration ......................................... 19 21. Constants ................................................. 19 22. Security Considerations.................................... 20 23. IANA Considerations........................................ 20 24. References ................................................ 20 24.1. Normative References.................................. 20 24.2. Informative References................................ 20 25. Acknowledgments ........................................... 20 1. Introduction This document describes the procedure for creating bindings between DHCP assigned addresses and an anchor (refer to [savi-framework]). Other related details about this procedure are also specified in this document. These bindings can be used to filter packets with forged IP = addresses. How to use these bindings is specified in [savi-framework], depending on the environment and configuration. The definition and examples of anchor is also specified in [savi-framework]. The binding process is inspired by the work of IP Source Guard. This specification differs from IP Source Guard in the specification for collision detection, which is essential in environments with multiple address assignment methods. Bi Expires September 3, 2010 [Page 3] =0C Internet-Draft savi-dhcp March 2010 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Mechanism Overview The mechanism specified in this document is designed to provide a host level source IP address validation granularity, as a supplement to BCP38 [BCP38]. This mechanism is deployed on the access device (including access switch, wireless access point/controller, etc), and performs mainly DHCP snooping to set up bindings between DHCP assigned IP addresses and corresponding anchors. The bindings can be used to validate the source address in the packets. 4. Background and Related Protocols This mechanism is an instance of a SAVI [savi-framework] solution, specialized for addresses assigned using the DHCP protocol. Dynamic Host Configuration Protocol version 4 [RFC2131] and Dynamic Host Configuration Protocol version 6 [RFC3315] specify the procedures for providing a client with assigned address and other configuration information from a DHCP server. If a client gets an address through the DHCP protocol, the address should be regarded as a potential "authorized" or "registered" address of the client. In IPv6, IPv6 Stateless Autoconfiguration [RFC4862] is used as another address assignment mechanism. A node can use this mechanism to auto-configure an IPv6 address. A DHCPv6 client may use a stateless address to send message to DHCP server. Even in a DHCPv6- only environment, a node must assign its link-local address through this mechanism. [RFC4862] clearly requires that duplicated address detection must be performed on any IPv6 address, including DHCPv6 address. [RFC4861] specifies the Neighbor Discovery protocol, which is an essential part of IPv6 address assignment. [RFC5227] specifies the procedure to detect IPv4 address collision. It is not required currently. However, this feature is useful to determine the uniqueness of an IPv4 address on the link. Considering not all the operating systems support [RFC5227], this solution is designed to be compatible with operating systems not complying with [RFC5227]. Bi Expires September 3, 2010 [Page 4] =0C Internet-Draft savi-dhcp March 2010 5. Terminology Main terms used in this document are described in [savi-framework], [RFC2131] and [RFC3315]. 6. Conceptual Data Structures This section describes the possible conceptual data structures used in this mechanism. Two main data structures are used to record bindings and their states respectively. There is redundancy between the two structures, for the consideration of separation of data plane and control plane. 6.1. Binding State Table (BST) This table contains the state of binding between source address and anchor. Entries are keyed on the anchor and source IP address. Each entry has a lifetime field recording the remaining lifetime of the entry, a state field recording the state of the binding and a field recording other information. +---------+----------+-------+-----------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-------+-----------+-------+ | A | IP_1 | Bound | 65535 | | +---------+----------+-------+-----------+-------+ | A | IP_2 | Bound | 10000 | | +---------+----------+-------+-----------+-------+ | B | IP_3 |_Start | 1 | | +---------+----------+-------+-----------+-------+ Figure 1 Instance of BST 6.2. Filtering Table (FT) This table contains the bindings between anchor and address, keyed on anchor. This table doesn't contain any state of the binding. This table is only used to filter packets. An Access Control List can be regarded as a practical instance of this table. Bi Expires September 3, 2010 [Page 5] =0C Internet-Draft savi-dhcp March 2010 +---------+----------+ |Anchor |Address | +---------+----------+ |A |IP_1 | +---------+----------+ |A |IP_2 | +---------+----------+ Figure 2 Instance of FT 7. Binding States Description This section describes the binding states of this mechanism. START A DHCP request (or a DHCPv6 Confirm, or a DHCPv6 Solicitation with Rapid Commit option) has been received from host, and it may trigger a new binding. LIVE A DHCP address has been acknowledged by a DHCP server. DETECTION A gratuitous ARP or Duplicate Address Detection NSOL has been sent by the host (or the SAVI device). BOUND The address has passed duplicate detection and it is bound with the anchor. 8. DHCP Scenario Figure 3 shows the main elements in a DHCP enabled network. At least one DHCP server MUST be deployed in the network, and DHCP relay MAY be used to relay message between client and server. Other address assignment mechanisms may be also used in such network. Bi Expires September 3, 2010 [Page 6] =0C Internet-Draft savi-dhcp March 2010 +--------+ | DHCP | | Server | +-------,+ | | | +----'-----+ | SAVI | | Device | +-/------/-+ | | +----\-+ +\-----+ |DHCP | |Client| |Relay | | | +------+ +------+ Figure 3 DHCP Scenario 9. Anchor Attributes This section specifies the anchor attributes involved in this mechanism. Anchor is defined in the [savi-framework]. Attribute of each anchor is configurable. In default, anchor has no attribute. An anchor MAY be configured to have one or more compatible attributes. However, an anchor MAY have no attribute. If an anchor has no attribute, server type DHCP message from this anchor MUST be dropped. However, other packets SHOULD NOT be dropped. 9.1. SAVI-Validation Attribute If and only if source address validation must be performed on the traffic from an anchor, this anchor MUST be set to have SAVI- Validation attribute. The filtering process on anchor with such attribute is described in section 12. 9.2. SAVI-DHCP-Trust Attribute If and only if an anchor is associated with a trustable DHCP server/relay, it SHOULD be set to have this attribute. If DHCP is used to assign address in the network, there MUST be at least one anchor with this attribute. DHCP Reply message not coming from such ports MUST be dropped. Bi Expires September 3, 2010 [Page 7] =0C Internet-Draft savi-dhcp March 2010 9.3. SAVI-SAVI Attribute If and only if an anchor is associated with another SAVI device, it SHOULD be set to have this attribute. All traffic from anchor with this attribute will be forwarded without check. This attribute is mutually exclusive with SAVI-Validation. 10. Prefix Configuration In DHCP scenario, address advertised by DHCP server should be believed in. However, in this solution, a node shares the same anchor as the DHCP server can disguise as the DHCP server and offer the client incorrect configuration information. Without fully deployment of SAVI, this problem is difficult to solve. Thus, it is SUGGESTED that correct address prefix should be configured, and DHCP server message which assigns address out of the scope should be dropped. This mechanism can ensure the client can at least get an address with proper prefix. This document suggests set 3 prefix scopes: IPv4 Prefix: The allowed scope of any kind of IPv4 addresses. It can be set manually. IPv6 SLAAC Prefixes: The allowed scope of SLAAC and manually configured IPv6 addresses. It can be set through snooping RA message from port with SAVI-RA-Trust attribute, DHCP-PD or manual configuration. FE80::/64 MUST be set to a feasible prefix. IPv6 DHCPv6 Prefixes: The allowed scope of DHCPv6 addresses. It can be set through RA snooping, DHCP-PD protocol, or manual configuration. There is no need to explicitly present these prefix scopes. But these restrictions SHOULD be used as premier check in binding set up. Refer to security consideration for other discussions. Bi Expires September 3, 2010 [Page 8] =0C Internet-Draft savi-dhcp March 2010 11. Binding Set Up This section specifies the procedure of setting up bindings based on control packet snooping. All binding entries are set up on anchor with SAVI-Validation attribute. 11.1. Process of DHCP Snooping 11.1.1. Initialization A binding entry is initialized in this step. This step MAY NOT be performed if: 1. Option 82 is used to keep anchor in DHCP Request and Reply, or 2. Unspoofable MAC is used as anchor(802.11i,802.1ae/af), or 3. The mapping table from MAC to anchor is secure. If none of these three requirements are satisfied, this step SHOULD be performed. If this step is not performed, then binding entry will be initialized in the next step. This step is performed for the consideration that anchor and DHCP assigned address can be bound with security in the next step. Otherwise the security of binding setup is based on the mapping mechanism from MAC to anchor on SAVI device, which may be vulnerable. This step can also help limit the request rate of client to prevent Denial of Services attack against DHCP server. 11.1.1.1. Trigger Event A DHCPv4/v6 Request or a DHCPv6 Confirm or a DHCPv6 Solicitation with Rapid Commit option is received. 11.1.1.2. Event Validation The SAVI device checks current BST as follows: 1. Whether the limitation on binding entry number of this anchor will be exceeded if a new entry is triggered. Bi Expires September 3, 2010 [Page 9] =0C Internet-Draft savi-dhcp March 2010 11.1.1.3. Following Actions If the check is passed: The SAVI device MUST forward the message. The SAVI device MUST generate an entry for the anchor in the Binding State Table (BST) and set the state field to START. The lifetime of this entry MUST set to be MAX_DHCP_RESPONSE_TIME. The Transaction ID (Refer to Section 2 in [RFC2131] and Section 4.2 in [RFC3315]) field of the request packet SHOULD be recorded in the entry. +---------+----------+-------+-----------------------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-------+-----------------------+-------+ | A | | START |MAX_DHCP_RESPONSE_TIME | TID | +---------+----------+-------+-----------------------+-------+ Figure 4 Binding entry in BST on initialization The TID is kept for assurance that the assigned address can be bound with anchor securely. It is suggested to keep TID in entry. However, TID MAY NOT be contained in the entry. 11.1.2. From START to LIVE 11.1.2.1. Trigger Event A DHCPv4 DHCPACK or DHCPv6 REPLY message is received. 11.1.2.2. Event Validation The SAVI device checks the message and BST as follows: 1. Whether the message is received from an anchor which has the SAVI- DHCP-Trust attribute; 2. Whether the entry in the BST with corresponding TID is in the START state. Or if the prior step is not performed, check whether the binding number limitation will be exceeded. 11.1.2.3. Following Actions If the check is passed: The SAVI device MUST deliver the message to the destination. Bi Expires September 3, 2010 [Page 10] =0C Internet-Draft savi-dhcp March 2010 The SAVI device MUST set the state of the corresponding entry to be LIVE. If prior step is not performed, a new entry MUST be generated in the BST. The lifetime of the entry MUST be set to be MAX_ARP_PREPARE_DELAY or MAX_DAD_PREPARE_DELAY respectively. The lease time MUST be recorded in the entry. +---------+----------+-------+------------------------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-------+------------------------+-------+ | A | Addr | LIVE |MAX_ARP_PREPARE_DELAY or| Lease | | | | |MAX_DAD_PREPARE_DELAY | Time | +---------+----------+-------+------------------------+-------+ Figure 5 Binding entry in BST on assignment Then, the SAVI device MAY set the state of the corresponding entry to be DETECTION, and send two or more ARP Request or NSOL for the assigned address. If the SAVI device sends detection packet directly, the next step MUST be omitted. +---------+----------+-----------+-----------------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-----------+-----------------+-------+ | A | Addr | DETECTION |MAX_ARP_DELAY or | Lease | | | | |MAX_DAD_DELAY | Time | +---------+----------+-----------+-----------------+-------+ Figure 6 Binding entry in BST on assignment: another case The SAVI device MUST insert an entry into the Filtering Table if the assigned address is not bound with another anchor in current BST. If the address has been bound with another anchor in current BST, the SAVI device MUST check if the node associated with that anchor is off-line. If yes, bind the address with the new entry and delete the original binding; if no, keep the original entry and delete the new entry in BST. This mechanism can handle local link movement, and avoid attacker grabbing assigned bindings from other nodes. However, if several hosts share the same anchor, and one of them moves to another anchor, this mechanism may cause problem. +---------+----------+ |Anchor |Address | +---------+----------+ |A |Addr | +---------+----------+ Figure 7 Binding entry in FT on assignment The following steps after this step MAY NOT be performed. It is SUGGESTED to perform following steps unless in some specified Bi Expires September 3, 2010 [Page 11] =0C Internet-Draft savi-dhcp March 2010 scenario, e.g., a DHCP-only scenario. If the following steps are not performed because of implementation or configuration, the state of the corresponding entry MUST be changed to BOUND, and the lifetime is set to lease time. 11.1.3. From LIVE to DETECTION 11.1.3.1. Trigger Event A gratuitous ARP Request or Duplicate Address Detection Neighbor Solicitation is received from anchor. Or a timeout event of an entry with state LIVE happens. 11.1.3.2. Event Validation The SAVI device checks the message and BST as follows: 1. Whether the Target IP Address field of the ARP Request or Neighbor Solicitation has been bound with the corresponding anchor in BST or FT. 11.1.3.3. Following Actions If the check is passed: If timeout event of an entry with state LIVE happens, the SAVI device MAY send one or more ARP Request or a DAD NSOL, with Target Address set to the recorded address in the entry. If detection packets are sent, the SAVI device MUST set the state of the entry to be = DETECTION. The lifetime of the entry MUST be set to be MAX_ARP_DELAY or MAX_DAD_DELAY respectively. If no detection packet is sent, the entry MUST be removed from BST and FT. If the SAVI device chooses not to send detection packet, valid packets may get dropped because a number of operating systems don't fully support [RFC4862] and [RFC5227] and don't send detection packets themselves. Thus, it is SUGGESTED the SAVI device SHOULD send detection packet in case the client doesn't send that itself. +---------+----------+-----------+-----------------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-----------+-----------------+-------+ | A | Addr | DETECTION |MAX_ARP_DELAY or| Lease | | | | |MAX_DAD_DELAY | Time | +---------+----------+-----------+-----------------+-------+ Figure 8 Binding entry in BST on detection Bi Expires September 3, 2010 [Page 12] =0C Internet-Draft savi-dhcp March 2010 11.1.4. From DETECTION to BOUND 11.1.4.1. Trigger Event A timeout event of an entry with state DETECTION occurs or an ARP Response or NA for an address in BST with state DETECTION is = received. 11.1.4.2. Following Actions If a timeout event of an entry with state DETECTION occurs, set the state of the entry to be BOUND. The lifetime of the entry is set to be the Lease time acknowledged by DHCP server. +---------+----------+-----------+----------------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-----------+----------------+-------+ | A | Addr | BOUND | Lease time | | +---------+----------+-----------+----------------+-------+ Figure 9 Binding entry in BST on finalization If an ARP Response or NA for an address in BST with state DETECTION is received, remove the corresponding entry in BST and FT. The ARP Response or NA MUST be delivered to the client. 11.1.5. After BOUND Once a binding entry is set up for an anchor, the binding will be used to filter packet with the anchor, as specified in section 12. On the other hand, DHCP messages with the anchor will affect the = binding. The binding is also affected by DHCP server message toward the = anchor. Before a DHCP message is found that it may change the corresponding binding, its validity MUST be checked as described in section 12.2. Whenever a DHCP Decline is received, delete the corresponding entry in BST and FT. Whenever a DHCP Release is received, if the state of the entry is BOUND, delete the entry in BST and FT. If a DHCPv4 Acknowledgement or DHCPv6 Reply with Renew/Rebind sign is received from the server, set lifetime of the entry in BST to be the new lease time. If the lifetime of an entry with state BOUND expires, delete the entry in BST and Filter Table. Bi Expires September 3, 2010 [Page 13] =0C Internet-Draft savi-dhcp March 2010 The binding may also be affected by control messages with or toward another anchor. The binding MAY be move to another anchor to handle local link movement, as described in section 11.1.2.3. In this situation, the node assigned a DCHP address changes to associate with another anchor, thus the address should be bound with the anchor which the node migrates to. Other than this situation, the binding will not be changed, for the consideration of simplicity. Even if an attached node becomes inactive and doesn't reply to any NS or ARP Request, the associated bindings will not be removed. Switch port down event (or more general, anchor turns off-link) will change the corresponding entry, as described in section 15. 11.2. State Machine of DHCP Snooping The main state transits are listed as follows. Note that the anchor migration of binding entry is not included. State Message/Event Action Next State - REQ/CFM/SOL+RC Generate entry START *- ACK/RPL Generate entry with lease LIVE *- ACK/RPL Generate entry with lease BOUND **- ACK/RPL Generate entry with lease DETECTION , send probe START ACK/RPL Record lease time LIVE **START ACK/RPL Send probe DETECTION START Timeout Remove entry - LIVE Gra ARP REQ/DAD NS - DETECTION LIVE DECLINE Remove entry - LIVE Timeout Send probe DETECTION *LIVE Timeout Remove entry - DETECTION Timeout - BOUND DETECTION ARP RES/DAD NA Remove entry - Bi Expires September 3, 2010 [Page 14] =0C Internet-Draft savi-dhcp March 2010 DETECTION DECLINE Remove entry - BOUND RELEASE/DECLINE Remove entry - BOUND Timeout Remove entry - BOUND RENEW/REBOUND Set new lifetime BOUND *: optional but NOT SUGGESTED. **: optional and MAY conflict other transits REQ: DHCP REQUEST CFM: DHCP CONFIRM SOL: DHCP SOLICITATION RC: Rapid Commit option ACK: DHCP ACKNOWLEDGEMENT RPL: DHCP REPLY Probe: Gratuitous ARP REQUEST or Duplicate Address Detection=20 Neighbor Solicitation, described in section 13.1 Gra ARP REQ: Gratuitous ARP REQUEST ARP RES: ARP RESPONSE DAD NS: Duplicate Address Detection Neighbor Solicitation DAD NA: Neighbor Advertisement targeting at a tentative address DECLINE: DHCP DECLINE RELEASE: DHCP RELEASE RENEW: DHCP RENEW REBOUND: DHCP REBOUND 12. Filtering Specification This section specifies how to use bindings to filter packets. Because the Filtering Table is an allow-table, packet with source address not Bi Expires September 3, 2010 [Page 15] =0C Internet-Draft savi-dhcp March 2010 in the table will be filtered. Considering DHCP may coexist with other address assignment methods, e.g., Stateless Auto-configuration, the specification made here is based on the assumption that other SAVI solutions will also use BST and FT to keep bindings and filter packets. Otherwise this solution will conflict with other SAVI solutions. Filtering policies are different for data packet and control packet. DHCP and ND messages that may cause state transit are classified into control packet. Neighbor Advertisement and ARP Response are also included in control packet, because the Target Address of NA and ARP Response should be checked to prevent spoofing. All other packets are considered to be data packets. 12.1. Data Packet Filtering Data packets with an anchor which has attribute SAVI-Validation MUST be checked. If the source of a packet associated with its anchor is in the FT, this packet SHOULD be forwarded; or else the packet MUST be = discarded. 12.2. Control Packet Filtering For anchors with SAVI-Validation attribute: The source address of DHCPv4 Discovery SHOULD be set to all zeros. The source address of DHCPv4 Request SHOULD be set to all zeros or a bound address in FT. The source address of DHCPv6 Request MUST be an address associated with the corresponding anchor in FT. The source address of DHCPv6 Confirm MUST be a link local address associated with the corresponding anchor in FT. The source address of DHCPv6 Solicit MUST be a link layer address bound with corresponding anchor. The link layer address MAY be bound based on SAVI-SLAAC solution or other solutions. The source address of other types of DHCP messages MUST be a address bound with the corresponding anchor. The source address of IPv6 NS and IPv4 gratuitous ARP MUST pass the check on FT. The target address and source address in all the Neighbor Advertisement packets and ARP replies MUST also pass the checks on = FT. Bi Expires September 3, 2010 [Page 16] =0C Internet-Draft savi-dhcp March 2010 For other anchors: All DHCP Reply/Ack packets MUST be from anchor with the SAVI-DHCP- Trust attribute. 13. Format and Delivery of Probe Messages As described in section 11.1.2.3 and 11.1.3.3, the SAVI device MAY send detection probes on behavior of client to determine whether the assigned address is duplicated. Currently no other probes are designed in this solution. 13.1. Duplicate detection Message Type: DAD NS, Gratuitous ARP Request Format: Link layer source - link layer address of host; Link layer destination - For IPv6, use multicast address specified in [RFC3307]; For IPv4, use broadcast address; IP source - Unspecified address for IPv6; The tentative address for IPv4; IP destination - For IPv6, multicast address specified in section 5.4.2 of [RFC4861]; For IPv4, the tentative address; Delivery: MUST NOT be delivered to the host which the SAVI device is performing DAD on behavior of. 14. Binding Remove If the lifetime of an entry with state BOUND expires, the entry MUST be removed. When the SAVI device receives a DAD NS/Gra ARP request target at an address bound and there is no replies from the anchor, if the anchor is a SAVI-Validation anchor, hold the binding entry through sending NA/ARP Reply, or remove the binding. Bi Expires September 3, 2010 [Page 17] =0C Internet-Draft savi-dhcp March 2010 15. Handle Anchor Off-link event Port DOWN event MUST be handled if switch port is used as anchor. In more general case, if an anchor turns off-link, this event MUST be handled. Whenever an anchor with attribute SAVI-Validation turns down, the bindings with the anchor MUST be kept for a short time. To handle movement, if receiving DAD NS/Gra ARP request targeting at the address during the period, remove the entry. If the anchor turns on-link during the period, recover bindings. It may result in some security problem, e.g., a malicious node immediately associates with the anchor got off by a previous node, then it can use the address assigned to the previous node. However, this situation is very rare in reality. Authors decide not to handle this situation. 16. About Collision in Detection The SAVI device may receive a response in detection. Some related details are specified here. 16.1. Whether to notify the DHCP server It is unnecessary for the SAVI device to notify the DHCP server, because the host will send a DECLINE message to it once it finds the advertised address is conflict. 16.2. The result of detection without host aware In case the SAVI device send detection packet instead of the host, the host will not be aware of the detection result. If the detection succeeds, there is no problem. However, if the detection fails, the packets from the host with the assigned address will be filtered out. This result can be regarded as a reasonable punishment for not performing duplicate detection and using a collision address. The SAVI device MAY choose to notice the client that the assigned address has been used, through a NA message. This mechanism is not required in this solution. 17. Filtering during detection In this mechanism, whenever the DHCP server replies an address, this address will be allowed immediately even before duplicate detection is completed. This design is in consideration of a host may start to Bi Expires September 3, 2010 [Page 18] =0C Internet-Draft savi-dhcp March 2010 send packets straightway without detection. Also this design is to be compatible with optimistic DAD [RFC4429]. However, this feature may allow an attacker to send quantities of packets with source addresses already assigned to other nodes. A practical solution for this vulnerability is configuring the address pool and allocation algorithm of the DHCP server carefully. 18. Binding Number Limitation It is suggested to configure some mechanism in order to prevent a single node from exhausting the binding table entries on the SAVI device. Either of the following mechanism is sufficient to prevent such attack. 1. Set the upper bound of binding number for each anchor with SAVI- Validation. 2. Reserve a number of binding entries for each anchor with SAVI- Validation attribute and all anchors share a pool of the other binding entries. 3. Limit DHCP Request rate per anchor, using the bound entry number of each anchor as reverse indicator. 19. Movement without DHCP Procedure This mechanism currently doesn't handle any movement without DHCP procedure, which means the change of anchor without triggering any DHCP procedure. The scenario includes several hosts are attached a SAVI-Validation port through a hub, and the hub changes from its attaching port to another SAVI-Validation port. For handling this situation will necessarily lead to a data packet triggering procedure on SAVI device, and may violate the semantic of DHCP protocol, this situation is not handled in this solution. 20. MLD Consideration The SAVI device MUST join the tentative address multicast group whenever perform duplicate detection on behavior of host. 21. Constants MAX_DHCP_RESPONSE_TIME 120s MAX_ARP_PREPARE_DELAY Default 1s but configurable Bi Expires September 3, 2010 [Page 19] =0C Internet-Draft savi-dhcp March 2010 MAX_ARP_DELAY Default 1s but configurable MAX_DAD_PREPARE_DELAY Default 1s but configurable MAX_DAD_DELAY Default 1s but configurable 22. Security Considerations For prefix level granularity filtering is the basis of host level granularity filtering, to learn and configure correct prefix is of great importance to this mechanism. Thus, it's important to keep RA and DHCP-PD secure. [draft-ietf-v6ops-ra-guard-03] describes a mechanism to improve the security of RA message. 23. IANA Considerations There is no IANA consideration currently. 24. References 24.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless Autoconfiguration", RFC4862, September, 2007. [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, July 2008. 24.2. Informative References 25. Acknowledgments Thanks to Christian Vogt, Eric Levy-Abegnoli, Mark Williams, Erik Nordmark, Marcelo Bagnulo Braun, Alberto Garcia, Jari Arkko, David Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert Raszuk, Greg Daley, Joel M. Halpern and Tao Lin for their valuable contributions. Bi Expires September 3, 2010 [Page 20] =0C Internet-Draft savi-dhcp March 2010 Authors' Addresses Jun Bi CERNET Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@cernet.edu.cn Jianping Wu CERNET Computer Science, Tsinghua University Beijing 100084 China Email: jianping@cernet.edu.cn Guang Yao CERNET Network Research Center, Tsinghua University Beijing 100084 China Email: yaog@netarchlab.tsinghua.edu.cn Fred Baker Cisco Systems Email: fred@cisco.com Bi Expires September 3, 2010 [Page 21] =0C ------=_NextPart_000_043A_01CABB0E.A11A6BC0-- From jeanmichel.combes@gmail.com Thu Mar 4 06:50:40 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF48B28C120 for ; Thu, 4 Mar 2010 06:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWKHVACs90Tg for ; Thu, 4 Mar 2010 06:50:40 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id C41B828C0DE for ; Thu, 4 Mar 2010 06:50:36 -0800 (PST) Received: by wyb40 with SMTP id 40so1468252wyb.31 for ; Thu, 04 Mar 2010 06:50:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=4iuvlTbA3jhW9cByC/hxoUtaqHvNoikM7+xM+w66gVU=; b=Mu0MJeGATSdb3LQBty5rDs1DFcXCPNZkkE4k7F4E7NJw9bf6Po1Ryifq5d+2s3nObB T0ObhwrmhZBnmtPEn5FYp8a+yqv4WnLyhtoVkILMtJZbs5pf6aDy32SkuG0vDU3nRH8S e1mHlMjSSl32dW7yZ+mwC3HPoASQp2WqZL6E8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=YVVZNBAJRqTnVmDkine0ei550pB23dcnRN+Ec5oOKCMO/StbRoGZvOBroKyoiuUY5f U4SZDhOTI0v1l3+6/9iB76BfO5xgRjHAAF04GD79QUWLjontAfHIFrkM58BU9qpO8URq TzKDot8vTKYhQj5VeWhJuvxdIs8g6u7KvD6Ns= MIME-Version: 1.0 Received: by 10.216.165.67 with SMTP id d45mr1843806wel.28.1267714235649; Thu, 04 Mar 2010 06:50:35 -0800 (PST) In-Reply-To: <20100303153619.1C185530773@newdev.eecs.harvard.edu> References: <20100303153619.1C185530773@newdev.eecs.harvard.edu> Date: Thu, 4 Mar 2010 15:50:35 +0100 Message-ID: <729b68be1003040650o71a67788o5a1ce6fef997a9c9@mail.gmail.com> From: Jean-Michel Combes To: SAVI Mailing List Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [savi] Fwd: request for help in developing a tool that may be helpful to WG chairs X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 14:50:41 -0000 FYI. Best regards. JMC. ---------- Forwarded message ---------- From: Scott O. Bradner Date: 2010/3/3 Subject: request for help in developing a tool that may be helpful to WG ch= airs To: wgchairs@ietf.org IETF working group chairs; We are developing an open-source tool for monitoring the status and progress of conflicts in on-line working groups (WG). =A0The tool works by analyzing the WG mailing list. =A0When developed, this tool should be helpful to WG chairs trying to understand the status of WG discussions (how close to consensus is the WG, what is the distribution of participation, etc). As part of the development process we have been using a prototype tool to analyze IETF WG mailing list archives to determine the amount of conflict and how effective this conflict is being (has been) resolved. As the first step, we need to understand the relationship between the conflicts in a working group and the structure of the communication network in that group. While having conflicts is not necessarily a bad thing for a working group effort, some conflicts can escalate into disasters. We are interested in finding the communication patterns related to the evolution of group conflicts. Results from this study will provide the base for the development of the tool that helps working group chairs to decide when to intervene with an internal conflict before it becomes irreversibly negative as well as being a tool that may help determine where there is consensus on a particular topic. We would like your help in understanding the level of conflicts within your working groups and how the conflicts affect productivity and group members=92 perception on the working group. It will be greatly appreciated if you could ask your WG members to anonymously fill a short survey at https://spreadsheets.google.com/viewform?hl=3Den&formkey=3DdExTbEU5QmRncnhF= bjhQUVR4bzBGMEE6MA Thank you! Best Regards, Bin Zhu, Mark Gaynor, Scott Bradner, and Jialun Qin From marcelo@it.uc3m.es Mon Mar 8 00:33:34 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CF9A3A67A3 for ; Mon, 8 Mar 2010 00:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oxIMRw1JDbk for ; Mon, 8 Mar 2010 00:33:33 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 62BB33A635F for ; Mon, 8 Mar 2010 00:33:33 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (63.31.18.95.dynamic.jazztel.es [95.18.31.63]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 4EA35BA68EA for ; Mon, 8 Mar 2010 09:33:35 +0100 (CET) Message-ID: <4B94B660.8070105@it.uc3m.es> Date: Mon, 08 Mar 2010 09:33:36 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: savi@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 08:33:34 -0000 Hi, I have a question that it was not apparent to me from the draft Suppose the following configuration: +------+ +-------------+ +-----------+ +---------------+ | Host |------|Legacy device|-------|SAVI device|-------|rest of the net| +------+ +-------------+ +-----------+ +---------------+ Suppose the host connects, does the DHCP exchange and the SAVI device creates the binding. Suppose now that the SAVI device loose the state (e.g. it reboots or crashes) What happens next? Is the SAVI device able to recover the binding information? I guess some of the info is stored in the dhcp server, but probably not all of it (i.e. the lower layer anchor info may not be present) Regards, marcelo El 03/03/10 13:18, Bi Jun escribi¨®: > Dear WG members, > This is the 01 version of savi-dhcp solution. > Comments please. > Thank you very much! > Jun Bi > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@tsinghua.edu.cn Mon Mar 8 01:09:04 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD793A67B1 for ; Mon, 8 Mar 2010 01:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.103 X-Spam-Level: X-Spam-Status: No, score=-1.103 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27BVWIhIUKke for ; Mon, 8 Mar 2010 01:09:03 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 58F2C3A67A1 for ; Mon, 8 Mar 2010 01:09:03 -0800 (PST) Received: from th024139.ip.tsinghua.edu.cn ([59.66.24.139] helo=junbiVAIO) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NoYxR-0002gx-FL; Mon, 08 Mar 2010 17:09:01 +0800 Message-ID: <8890D59864D7412A9DDD6B3CD7AAEFEA@junbiVAIO> From: "Jun Bi" To: "marcelo bagnulo braun" , References: <4B94B660.8070105@it.uc3m.es> In-Reply-To: <4B94B660.8070105@it.uc3m.es> Date: Mon, 8 Mar 2010 17:09:02 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 09:09:04 -0000 Hi Marcelo, During my presentation at IETF76, some people commented that it took much effort for SAVI-device to send probe packets to handle the special case. Then in this dhcp-01 version, we make the solution for the most recommended use case: the host directly attached to savi device. We hope we could reach consus on this part then we could go further to discuss the situation of le thanks, Jun Bi -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Monday, March 08, 2010 4:33 PM To: Subject: Re: [savi] call for comments: savi-dhcp-01 > Hi, > > I have a question that it was not apparent to me from the draft > > Suppose the following configuration: > > +------+ +-------------+ +-----------+ +---------------+ > | Host |------|Legacy device|-------|SAVI device|-------|rest of the net| > +------+ +-------------+ +-----------+ +---------------+ > > Suppose the host connects, does the DHCP exchange and the SAVI device > creates the binding. > Suppose now that the SAVI device loose the state (e.g. it reboots or > crashes) > > What happens next? Is the SAVI device able to recover the binding > information? > > I guess some of the info is stored in the dhcp server, but probably not > all of it (i.e. > the lower layer anchor info may not be present) > > Regards, marcelo > > > > > El 03/03/10 13:18, Bi Jun escribi¨®: >> Dear WG members, >> This is the 01 version of savi-dhcp solution. >> Comments please. >> Thank you very much! >> Jun Bi >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@tsinghua.edu.cn Mon Mar 8 01:14:48 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64FD3A67A5 for ; Mon, 8 Mar 2010 01:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.103 X-Spam-Level: X-Spam-Status: No, score=-1.103 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsFQ1IUIRlym for ; Mon, 8 Mar 2010 01:14:48 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 6EFB53A67A1 for ; Mon, 8 Mar 2010 01:14:47 -0800 (PST) Received: from th024139.ip.tsinghua.edu.cn ([59.66.24.139] helo=junbiVAIO) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NoZ30-0004os-VR; Mon, 08 Mar 2010 17:14:47 +0800 Message-ID: From: "Jun Bi" To: "marcelo bagnulo braun" , Date: Mon, 8 Mar 2010 17:14:48 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 09:14:48 -0000 Hi Marcelo, During my presentation at IETF76, some people commented that it took much effort for SAVI-device to send probe packets to handle the special case. Then in this dhcp-01 version, we make the solution for the most recommended use case: the host directly attached to savi device. We hope we could reach consensus on this part then we could go further to discuss the situation when legacy switch involved (does the cost matches the benefit?). It also needs the savi-framework to state the user's scenarios. thanks, Jun Bi > > > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Monday, March 08, 2010 4:33 PM > To: > Subject: Re: [savi] call for comments: savi-dhcp-01 > >> Hi, >> >> I have a question that it was not apparent to me from the draft >> >> Suppose the following configuration: >> >> +------+ +-------------+ +-----------+ +---------------+ >> | Host |------|Legacy device|-------|SAVI device|-------|rest of the net| >> +------+ +-------------+ +-----------+ +---------------+ >> >> Suppose the host connects, does the DHCP exchange and the SAVI device >> creates the binding. >> Suppose now that the SAVI device loose the state (e.g. it reboots or >> crashes) >> >> What happens next? Is the SAVI device able to recover the binding >> information? >> >> I guess some of the info is stored in the dhcp server, but probably not >> all of it (i.e. >> the lower layer anchor info may not be present) >> >> Regards, marcelo >> >> >> >> >> El 03/03/10 13:18, Bi Jun escribi¨®: >>> Dear WG members, >>> This is the 01 version of savi-dhcp solution. >>> Comments please. >>> Thank you very much! >>> Jun Bi >>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> From marcelo@it.uc3m.es Mon Mar 8 01:29:28 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1424C3A6808 for ; Mon, 8 Mar 2010 01:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJud5yzZQmsu for ; Mon, 8 Mar 2010 01:29:27 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id CF19B3A6803 for ; Mon, 8 Mar 2010 01:29:26 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (63.31.18.95.dynamic.jazztel.es [95.18.31.63]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id C13677F443E; Mon, 8 Mar 2010 10:29:26 +0100 (CET) Message-ID: <4B94C376.40502@it.uc3m.es> Date: Mon, 08 Mar 2010 10:29:26 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Jun Bi References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 09:29:28 -0000 Hi Jun, Thanks for the answer. So, your proposal is to simply rule out this scenario and make dhcp based savi to require that all hosts are directly connected tot he SAVI device? I think this would significantly limit the solution applicabillity and the chances of its deployment (it basically will require to upgrade most of the switches in the network in order to run SAVI). I don't believe this is a good approach. I think we need to define a SAVI solution that allows for incremental deployment in the network, if we want this to happen. So commenting on you reply below... El 08/03/10 10:14, Jun Bi escribi¨®: > Hi Marcelo, > > During my presentation at IETF76, some people commented that > it took much effort for SAVI-device to send probe packets to > handle the special case. I don't recall that disucssion, probably i missed that one So, could you explain to me how would you deal with that case by probing? I mean, it is not obvious to me how the SAVI device knows who to probe, since it has lost its state > Then in this dhcp-01 version, > we make the solution for the most recommended use case: the host > directly attached to savi device. I don't think we cna limit ourselves to this specific case, as i mentioned before > We hope we could reach > consensus on this part then we could go further to discuss the > situation when legacy switch involved not sure what do you mean here... I agree we need to discuss this and get consensus to move forward. > (does the cost matches the benefit?). > It also needs the savi-framework to state the user's scenarios. > I also agree this should be part of the framework document. Regards, marcelo > thanks, > Jun Bi > >> >> >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Monday, March 08, 2010 4:33 PM >> To: >> Subject: Re: [savi] call for comments: savi-dhcp-01 >> >>> Hi, >>> >>> I have a question that it was not apparent to me from the draft >>> >>> Suppose the following configuration: >>> >>> +------+ +-------------+ +-----------+ +---------------+ >>> | Host |------|Legacy device|-------|SAVI device|-------|rest of the >>> net| >>> +------+ +-------------+ +-----------+ +---------------+ >>> >>> Suppose the host connects, does the DHCP exchange and the SAVI >>> device creates the binding. >>> Suppose now that the SAVI device loose the state (e.g. it reboots or >>> crashes) >>> >>> What happens next? Is the SAVI device able to recover the binding >>> information? >>> >>> I guess some of the info is stored in the dhcp server, but probably >>> not all of it (i.e. >>> the lower layer anchor info may not be present) >>> >>> Regards, marcelo >>> >>> >>> >>> >>> El 03/03/10 13:18, Bi Jun escribi¨®: >>>> Dear WG members, >>>> This is the 01 version of savi-dhcp solution. >>>> Comments please. >>>> Thank you very much! >>>> Jun Bi >>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> > From junbi@cernet.edu.cn Mon Mar 8 02:16:28 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FC343A6881 for ; Mon, 8 Mar 2010 02:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnkVDRYWb-jL for ; Mon, 8 Mar 2010 02:16:27 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id D3CF03A67A4 for ; Mon, 8 Mar 2010 02:16:25 -0800 (PST) Received: from junbiVAIO([59.66.24.139]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54b950506; Mon, 08 Mar 2010 18:16:26 +0800 Message-ID: From: "Bi Jun" To: "marcelo bagnulo braun" References: <4B94C376.40502@it.uc3m.es> In-Reply-To: <4B94C376.40502@it.uc3m.es> Date: Mon, 8 Mar 2010 18:16:26 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: OHgAaoXB Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 10:16:28 -0000 Hi Marcelo, You actually bring two questions. One question is on deployment: can we deploy a solution on legacy switch. Another is on the user's scenario: do we need to support the case when latency switch is involved. For question 1, my point is: if the solution is very simple and just need to upgrade a software version, doesn't need to change hardware, then it will be yes. The current savi-dhcp-01 is very easy to be implemented by software-only (it has been proved by several switch vendors by real products, which I will report at IETF77), Then it will be very easy for users to deploy it on his current (legacy) switch, where CERNET is deploying it. Moreover, if the legacy switch is too old to upgrade the software, because the life time of access switch hardware is about 3 years, then when the user purchase a new switch, the switch will be upgraded. If the answer of question 1 is yes, then the in the most cases, then scenario of question 2 is less important. So my point is that we need to evaluate if the cost (brought to switch) matches the benefit. My proposal is to have one RFC for one scenario that we have consensus(e.g. the host directly attached to the savi switch), then if it is really needed, having another RFC for more complicated cases (maybe because the cost to switch, not many vendors really implement in the real world in recent years). Certainly, the scenarios will be presented in savi-framework. By the way, the probe in my previous email meant that the savi-device send out packets (dad-ns, confirm, etc) to host/or might to dhcp server, triggered by data packets or timers. It was used to handle the case when host moving (and other cases) under legacy switch in my last presentation at IETF, it seemed that people think triggering those probes make the switch too complex (Joe, etc.) and the vendors also don't like the data-packet triggered actions based on the feedbacks when we work with vendors in the past months (H3C, ZTE, Ruijie, DC, etc..). thanks, Jun Bi -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Monday, March 08, 2010 5:29 PM To: "Jun Bi" Cc: Subject: Re: [savi] call for comments: savi-dhcp-01 > Hi Jun, > > Thanks for the answer. > > So, your proposal is to simply rule out this scenario and make dhcp > based savi to require that all hosts are directly connected tot he SAVI > device? > > I think this would significantly limit the solution applicabillity and > the chances of its deployment (it basically will require to upgrade most > of the switches in the network in order to run SAVI). > > I don't believe this is a good approach. I think we need to define a > SAVI solution that allows for incremental deployment in the network, if > we want this to happen. > > So commenting on you reply below... > > El 08/03/10 10:14, Jun Bi escribi¨®: >> Hi Marcelo, >> >> During my presentation at IETF76, some people commented that >> it took much effort for SAVI-device to send probe packets to >> handle the special case. > I don't recall that disucssion, probably i missed that one > > So, could you explain to me how would you deal with that case by probing? > Please read my ppt in IETF76 meeting. > I mean, it is not obvious to me how the SAVI device knows who to probe, > since it has lost its state > >> Then in this dhcp-01 version, >> we make the solution for the most recommended use case: the host >> directly attached to savi device. > I don't think we cna limit ourselves to this specific case, as i > mentioned before >> We hope we could reach >> consensus on this part then we could go further to discuss the >> situation when legacy switch involved > not sure what do you mean here... > I agree we need to discuss this and get consensus to move forward. > > >> (does the cost matches the benefit?). >> It also needs the savi-framework to state the user's scenarios. >> > I also agree this should be part of the framework document. > > Regards, marcelo > > >> thanks, >> Jun Bi >> >>> >>> >>> -------------------------------------------------- >>> From: "marcelo bagnulo braun" >>> Sent: Monday, March 08, 2010 4:33 PM >>> To: >>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>> >>>> Hi, >>>> >>>> I have a question that it was not apparent to me from the draft >>>> >>>> Suppose the following configuration: >>>> >>>> +------+ +-------------+ +-----------+ +---------------+ >>>> | Host |------|Legacy device|-------|SAVI device|-------|rest of the >>>> net| >>>> +------+ +-------------+ +-----------+ +---------------+ >>>> >>>> Suppose the host connects, does the DHCP exchange and the SAVI >>>> device creates the binding. >>>> Suppose now that the SAVI device loose the state (e.g. it reboots or >>>> crashes) >>>> >>>> What happens next? Is the SAVI device able to recover the binding >>>> information? >>>> >>>> I guess some of the info is stored in the dhcp server, but probably >>>> not all of it (i.e. >>>> the lower layer anchor info may not be present) >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> >>>> El 03/03/10 13:18, Bi Jun escribi¨®: >>>>> Dear WG members, >>>>> This is the 01 version of savi-dhcp solution. >>>>> Comments please. >>>>> Thank you very much! >>>>> Jun Bi >>>>> >>>>> >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Mon Mar 8 02:33:47 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9DA43A6824 for ; Mon, 8 Mar 2010 02:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C64z0saWylAQ for ; Mon, 8 Mar 2010 02:33:46 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 662503A67ED for ; Mon, 8 Mar 2010 02:33:46 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 90AA26C6757; Mon, 8 Mar 2010 11:33:48 +0100 (CET) Message-ID: <4B94D28C.3000205@it.uc3m.es> Date: Mon, 08 Mar 2010 11:33:48 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Bi Jun References: <4B94C376.40502@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 10:33:47 -0000 below... El 08/03/10 11:16, Bi Jun escribi¨®: > Hi Marcelo, > > You actually bring two questions. > > > One question is on deployment: can we deploy a solution on legacy switch. > Another is on the user's scenario: do we need to support the case when > latency switch is involved. > > For question 1, my point is: if the solution is very simple and just need > to upgrade a software version, doesn't need to change hardware, then > it will be yes. In any case, this approahc would impose an upgrade of most of the switches in the network. I argue that this may be feasible in some scenarios and not in others. A couple of examples. Suppose you are providing serv ice for a cmapus network and everybody has these small hub switches in their offices, and that is perfeclty ok with the security policy (this is the case of my university for instance) We have a variety of small hubs, some of them are fairly old. Moreover, some people are running virtual machines in their computers, do the hubs is actually virtual. In this scenario, which i would argue is fairly common, it is not trvial to update all the switches. A second case may be the one of the dsl forum. their goal is to run savi in the CPE. Now, many ISPs have no problem allowing the user to connect a switch to their CPE. The thing here is that the ISP wants to deploy SAVI, but it can certainly not mandate their cusotmers to update their home switches. So, i still don't think we can simply dismiss this scenario > The current savi-dhcp-01 is very easy to be implemented by > software-only (it has been > proved by several switch vendors by real products, which I will report > at IETF77), Then it will be very easy for users to deploy it on his > current (legacy) switch, > where CERNET is deploying it. Moreover, if the legacy switch is too > old to upgrade > the software, because the life time of access switch hardware is about > 3 years, then > when the user purchase a new switch, the switch will be upgraded. > well, where i come from we don't upgrade office hubs every 3 years, i can tell you that for sure. > If the answer of question 1 is yes, then the in the most cases, then > scenario of question 2 is less important. So my point is that we need > to evaluate if the cost (brought to switch) matches the benefit. My > proposal is to have one RFC for one scenario that we have consensus i am not sure what do you mean we have consensus. I agree we need to support this scenario, but we certainly do not have consensus on having a solution that only supports this particular scenario second, i am so far only talking about the dhcp based savi, in the case of ND based savi the issues are far more severa and the soltion is likely to support any scenario in any case. So, i don't agree with your proposed way froward > (e.g. the host directly attached to the savi switch), then if it is > really needed, having another RFC for more complicated cases (maybe > because the cost to switch, not many vendors really implement in the > real world in recent years). Certainly, the scenarios will be > presented in savi-framework. > > By the way, the probe in my previous email meant that the savi-device > send out packets (dad-ns, confirm, etc) to host/or might to dhcp > server, triggered by data packets or timers. mm, so you mean that if the SAVI device receives a data packet for which it does not have a binding, it sends the DHCP CONFIRM to the dhcp server to see if the server validates it, it that what you meant? that seems reasonable to me > It was used to handle the case when host moving (and other cases) > under legacy switch in my last presentation at IETF, it seemed that > people think triggering those probes make the switch too complex (Joe, > etc.) and the vendors also don't like the data-packet triggered > actions based on the feedbacks when we work with vendors in the past > months (H3C, ZTE, Ruijie, DC, etc..). > i can see that, but the question is what the overall robustness and deployability of the alternative solution. that is imho what we need to duscuss and understand. Regards, marcelo > thanks, > Jun Bi > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Monday, March 08, 2010 5:29 PM > To: "Jun Bi" > Cc: > Subject: Re: [savi] call for comments: savi-dhcp-01 > >> Hi Jun, >> >> Thanks for the answer. >> >> So, your proposal is to simply rule out this scenario and make dhcp >> based savi to require that all hosts are directly connected tot he SAVI >> device? >> >> I think this would significantly limit the solution applicabillity and >> the chances of its deployment (it basically will require to upgrade most >> of the switches in the network in order to run SAVI). >> >> I don't believe this is a good approach. I think we need to define a >> SAVI solution that allows for incremental deployment in the network, if >> we want this to happen. >> >> So commenting on you reply below... >> >> El 08/03/10 10:14, Jun Bi escribi¨®: >>> Hi Marcelo, >>> >>> During my presentation at IETF76, some people commented that >>> it took much effort for SAVI-device to send probe packets to >>> handle the special case. >> I don't recall that disucssion, probably i missed that one >> >> So, could you explain to me how would you deal with that case by >> probing? >> > > Please read my ppt in IETF76 meeting. > > > >> I mean, it is not obvious to me how the SAVI device knows who to probe, >> since it has lost its state >> >>> Then in this dhcp-01 version, >>> we make the solution for the most recommended use case: the host >>> directly attached to savi device. >> I don't think we cna limit ourselves to this specific case, as i >> mentioned before >>> We hope we could reach >>> consensus on this part then we could go further to discuss the >>> situation when legacy switch involved >> not sure what do you mean here... >> I agree we need to discuss this and get consensus to move forward. >> >> >>> (does the cost matches the benefit?). >>> It also needs the savi-framework to state the user's scenarios. >>> >> I also agree this should be part of the framework document. >> >> Regards, marcelo >> >> >>> thanks, >>> Jun Bi >>> >>>> >>>> >>>> -------------------------------------------------- >>>> From: "marcelo bagnulo braun" >>>> Sent: Monday, March 08, 2010 4:33 PM >>>> To: >>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>> >>>>> Hi, >>>>> >>>>> I have a question that it was not apparent to me from the draft >>>>> >>>>> Suppose the following configuration: >>>>> >>>>> +------+ +-------------+ +-----------+ +---------------+ >>>>> | Host |------|Legacy device|-------|SAVI device|-------|rest of the >>>>> net| >>>>> +------+ +-------------+ +-----------+ +---------------+ >>>>> >>>>> Suppose the host connects, does the DHCP exchange and the SAVI >>>>> device creates the binding. >>>>> Suppose now that the SAVI device loose the state (e.g. it reboots or >>>>> crashes) >>>>> >>>>> What happens next? Is the SAVI device able to recover the binding >>>>> information? >>>>> >>>>> I guess some of the info is stored in the dhcp server, but probably >>>>> not all of it (i.e. >>>>> the lower layer anchor info may not be present) >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>> >>>>> >>>>> El 03/03/10 13:18, Bi Jun escribi¨®: >>>>>> Dear WG members, >>>>>> This is the 01 version of savi-dhcp solution. >>>>>> Comments please. >>>>>> Thank you very much! >>>>>> Jun Bi >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> >>>>> >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > From swmike@swm.pp.se Mon Mar 8 03:17:00 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31343A697F for ; Mon, 8 Mar 2010 03:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAPhGVxJ4y18 for ; Mon, 8 Mar 2010 03:16:56 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id 495AB3A6974 for ; Mon, 8 Mar 2010 03:16:54 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 46950A1; Mon, 8 Mar 2010 12:16:50 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 45E479F for ; Mon, 8 Mar 2010 12:16:50 +0100 (CET) Date: Mon, 8 Mar 2010 12:16:50 +0100 (CET) From: Mikael Abrahamsson To: savi@ietf.org In-Reply-To: <4B94D28C.3000205@it.uc3m.es> Message-ID: References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 11:17:00 -0000 On Mon, 8 Mar 2010, marcelo bagnulo braun wrote: > A second case may be the one of the dsl forum. their goal is to run savi > in the CPE. Now, many ISPs have no problem allowing the user to connect > a switch to their CPE. The thing here is that the ISP wants to deploy > SAVI, but it can certainly not mandate their cusotmers to update their > home switches. Requiring home equipment to be rebooted or at least their dhcp lease renewed after an upgrade of the home gateway I think is no major problem. If I understood the problem correctly you're worried about the end user outage occuring from the SAVI device is rebooted until all clients have renewed their DHCP bindings so the SAVI device can filter correctly? What about recommending the SAVI device to save its state regularily (and before each reboot) to non volatile storage so it properly can keep SAVI state across reboots/power outage? Guess this might be hard to implement as only storage regularily used in these devices are flash drives and one doesn't really want to write to them all the time? -- Mikael Abrahamsson email: swmike@swm.pp.se From junbi@cernet.edu.cn Mon Mar 8 03:24:21 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635C43A6938 for ; Mon, 8 Mar 2010 03:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4mmTFSw4not for ; Mon, 8 Mar 2010 03:24:20 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id EEFF83A6917 for ; Mon, 8 Mar 2010 03:24:16 -0800 (PST) Received: from junbiVAIO([59.66.24.139]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54b9514eb; Mon, 08 Mar 2010 19:24:15 +0800 Message-ID: <10F327EA71564228A016D2641E12121A@junbiVAIO> From: "Bi Jun" To: "marcelo bagnulo braun" References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> In-Reply-To: <4B94D28C.3000205@it.uc3m.es> Date: Mon, 8 Mar 2010 19:24:09 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: OCTEboXB Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 11:24:21 -0000 -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Monday, March 08, 2010 6:33 PM To: "Bi Jun" Cc: Subject: Re: [savi] call for comments: savi-dhcp-01 > below... > > El 08/03/10 11:16, Bi Jun escribi¨®: >> Hi Marcelo, >> >> You actually bring two questions. >> >> >> One question is on deployment: can we deploy a solution on legacy switch. >> Another is on the user's scenario: do we need to support the case when >> latency switch is involved. >> >> For question 1, my point is: if the solution is very simple and just need >> to upgrade a software version, doesn't need to change hardware, then >> it will be yes. > In any case, this approahc would impose an upgrade of most of the > switches in the network. > I argue that this may be feasible in some scenarios and not in others. > A couple of examples. Actually, the savi-switches are independent. Deployment on one switch doesn't rely on the deployment of other switches. So you don't need to change most switches, you upgrade one, then get one benefit, it's incremental deployment. > > Suppose you are providing serv ice for a cmapus network and everybody > has these small hub switches in their offices, and that is perfeclty ok > with the security policy (this is the case of my university for instance) > We have a variety of small hubs, some of them are fairly old. Moreover, > some people are running virtual machines in their computers, do the hubs > is actually virtual. In this scenario, which i would argue is fairly > common, it is not trvial to update all the switches. Please note that the savi-dhcp-01 could handle the hub connection in normal cases. You are actually taking about how to handle special cases. If you are the administrator (like us), if you enforce SAVI, then you can ask the users directly attached hosts to savi-switch. If some users still want the flexibility with a hub, then in the MOST cases there will be no problem (the reboot of savi-switch in your example will be very low frequent event), then if you found the network has the problem, you just need to reboot your hub, you want the flexibility then you pay it by rebooting your own hub. We didn't see any problem in our real deployment. It's the user's normal behavior in today's internet, if you meet a problem, you plug off you cable and plug in again. Remember the "end-end argument" of system design: "If the application can do it, don¡¯t do it at a lower layer -- anyway the application knows the best what it need", that's the successful philosophy of Internet. So don't make the system too complex to handle special cases. That's why I said we need to evaluate the cost and benefit. BTW, I agree that for high-end switch, we can ask them to do more with a bigger solution to handle all special cases (even the special cases are low frequency events), that's why I said maybe we might need two RFCs (one simple/low cost solution for most cases, another ideal but high cost solution for all cases). > > A second case may be the one of the dsl forum. their goal is to run savi > in the CPE. Now, many ISPs have no problem allowing the user to connect > a switch to their CPE. The thing here is that the ISP wants to deploy > SAVI, but it can certainly not mandate their cusotmers to update their > home switches. Currently, DSL is a separate scope. > > So, i still don't think we can simply dismiss this scenario > >> The current savi-dhcp-01 is very easy to be implemented by >> software-only (it has been >> proved by several switch vendors by real products, which I will report >> at IETF77), Then it will be very easy for users to deploy it on his >> current (legacy) switch, >> where CERNET is deploying it. Moreover, if the legacy switch is too >> old to upgrade >> the software, because the life time of access switch hardware is about >> 3 years, then >> when the user purchase a new switch, the switch will be upgraded. >> > > well, where i come from we don't upgrade office hubs every 3 years, i > can tell you that for sure. > >> If the answer of question 1 is yes, then the in the most cases, then >> scenario of question 2 is less important. So my point is that we need >> to evaluate if the cost (brought to switch) matches the benefit. My >> proposal is to have one RFC for one scenario that we have consensus > i am not sure what do you mean we have consensus. I agree we need to > support this scenario, but we certainly do not have consensus on having > a solution that only supports this particular scenario > > second, i am so far only talking about the dhcp based savi, in the case > of ND based savi the issues are far more severa and the soltion is > likely to support any scenario in any case. I really doubt on a big solution trying to resolve any problems in any scenarios, sometimes might means impossible in engineering/practice (too complex to be implemented at least in most devices). > > So, i don't agree with your proposed way froward > >> (e.g. the host directly attached to the savi switch), then if it is >> really needed, having another RFC for more complicated cases (maybe >> because the cost to switch, not many vendors really implement in the >> real world in recent years). Certainly, the scenarios will be >> presented in savi-framework. >> >> By the way, the probe in my previous email meant that the savi-device >> send out packets (dad-ns, confirm, etc) to host/or might to dhcp >> server, triggered by data packets or timers. > mm, so you mean that if the SAVI device receives a data packet for which > it does not have a binding, it sends the DHCP CONFIRM to the dhcp server > to see if the server validates it, it that what you meant? > > that seems reasonable to me > Yes, we can have some way to handle it. In my last PPT in IETF76, I presented lots of similar solutions. But I still think it's not good to bring too much cost to the savi-device which are low-end access switch in most cases, just for some very special event (which can be simply fixed by users). > >> It was used to handle the case when host moving (and other cases) >> under legacy switch in my last presentation at IETF, it seemed that >> people think triggering those probes make the switch too complex (Joe, >> etc.) and the vendors also don't like the data-packet triggered >> actions based on the feedbacks when we work with vendors in the past >> months (H3C, ZTE, Ruijie, DC, etc..). >> > i can see that, but the question is what the overall robustness and > deployability of the alternative solution. that is imho what we need to > duscuss and understand. > > Regards, marcelo > > >> thanks, >> Jun Bi >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Monday, March 08, 2010 5:29 PM >> To: "Jun Bi" >> Cc: >> Subject: Re: [savi] call for comments: savi-dhcp-01 >> >>> Hi Jun, >>> >>> Thanks for the answer. >>> >>> So, your proposal is to simply rule out this scenario and make dhcp >>> based savi to require that all hosts are directly connected tot he SAVI >>> device? >>> >>> I think this would significantly limit the solution applicabillity and >>> the chances of its deployment (it basically will require to upgrade most >>> of the switches in the network in order to run SAVI). >>> >>> I don't believe this is a good approach. I think we need to define a >>> SAVI solution that allows for incremental deployment in the network, if >>> we want this to happen. >>> >>> So commenting on you reply below... >>> >>> El 08/03/10 10:14, Jun Bi escribi¨®: >>>> Hi Marcelo, >>>> >>>> During my presentation at IETF76, some people commented that >>>> it took much effort for SAVI-device to send probe packets to >>>> handle the special case. >>> I don't recall that disucssion, probably i missed that one >>> >>> So, could you explain to me how would you deal with that case by >>> probing? >>> >> >> Please read my ppt in IETF76 meeting. >> >> >> >>> I mean, it is not obvious to me how the SAVI device knows who to probe, >>> since it has lost its state >>> >>>> Then in this dhcp-01 version, >>>> we make the solution for the most recommended use case: the host >>>> directly attached to savi device. >>> I don't think we cna limit ourselves to this specific case, as i >>> mentioned before >>>> We hope we could reach >>>> consensus on this part then we could go further to discuss the >>>> situation when legacy switch involved >>> not sure what do you mean here... >>> I agree we need to discuss this and get consensus to move forward. >>> >>> >>>> (does the cost matches the benefit?). >>>> It also needs the savi-framework to state the user's scenarios. >>>> >>> I also agree this should be part of the framework document. >>> >>> Regards, marcelo >>> >>> >>>> thanks, >>>> Jun Bi >>>> >>>>> >>>>> >>>>> -------------------------------------------------- >>>>> From: "marcelo bagnulo braun" >>>>> Sent: Monday, March 08, 2010 4:33 PM >>>>> To: >>>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>>> >>>>>> Hi, >>>>>> >>>>>> I have a question that it was not apparent to me from the draft >>>>>> >>>>>> Suppose the following configuration: >>>>>> >>>>>> +------+ +-------------+ +-----------+ +---------------+ >>>>>> | Host |------|Legacy device|-------|SAVI device|-------|rest of the >>>>>> net| >>>>>> +------+ +-------------+ +-----------+ +---------------+ >>>>>> >>>>>> Suppose the host connects, does the DHCP exchange and the SAVI >>>>>> device creates the binding. >>>>>> Suppose now that the SAVI device loose the state (e.g. it reboots or >>>>>> crashes) >>>>>> >>>>>> What happens next? Is the SAVI device able to recover the binding >>>>>> information? >>>>>> >>>>>> I guess some of the info is stored in the dhcp server, but probably >>>>>> not all of it (i.e. >>>>>> the lower layer anchor info may not be present) >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> El 03/03/10 13:18, Bi Jun escribi¨®: >>>>>>> Dear WG members, >>>>>>> This is the 01 version of savi-dhcp solution. >>>>>>> Comments please. >>>>>>> Thank you very much! >>>>>>> Jun Bi >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> savi mailing list >>>>>>> savi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> >>>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> > From junbi@tsinghua.edu.cn Mon Mar 8 03:54:17 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431133A683D for ; Mon, 8 Mar 2010 03:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8-FljtZut7P for ; Mon, 8 Mar 2010 03:54:16 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 0F4133A683B for ; Mon, 8 Mar 2010 03:54:07 -0800 (PST) Received: from th024139.ip.tsinghua.edu.cn ([59.66.24.139] helo=junbiVAIO) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NobWp-0008VQ-9P; Mon, 08 Mar 2010 19:53:43 +0800 Message-ID: <63BC8D9E168143EAB483725F9EF98621@junbiVAIO> From: "Jun Bi" To: "Mikael Abrahamsson" , References: <4B94C376.40502@it.uc3m.es><4B94D28C.3000205@it.uc3m.es> In-Reply-To: Date: Mon, 8 Mar 2010 19:53:44 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 11:54:17 -0000 Hi Mikael, Thank you very much for you advice, we will add this (saving savi state) in to savi-dhcp-01 as one option. Best Regards, Jun Bi -------------------------------------------------- From: "Mikael Abrahamsson" Sent: Monday, March 08, 2010 7:16 PM To: Subject: Re: [savi] call for comments: savi-dhcp-01 > On Mon, 8 Mar 2010, marcelo bagnulo braun wrote: > >> A second case may be the one of the dsl forum. their goal is to run savi >> in the CPE. Now, many ISPs have no problem allowing the user to connect a >> switch to their CPE. The thing here is that the ISP wants to deploy SAVI, >> but it can certainly not mandate their cusotmers to update their home >> switches. > > Requiring home equipment to be rebooted or at least their dhcp lease > renewed after an upgrade of the home gateway I think is no major problem. > > If I understood the problem correctly you're worried about the end user > outage occuring from the SAVI device is rebooted until all clients have > renewed their DHCP bindings so the SAVI device can filter correctly? > > What about recommending the SAVI device to save its state regularily (and > before each reboot) to non volatile storage so it properly can keep SAVI > state across reboots/power outage? Guess this might be hard to implement > as only storage regularily used in these devices are flash drives and one > doesn't really want to write to them all the time? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Mon Mar 8 05:47:08 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F883A6995 for ; Mon, 8 Mar 2010 05:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCrYvPaF480h for ; Mon, 8 Mar 2010 05:47:07 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 913AE3A6957 for ; Mon, 8 Mar 2010 05:47:07 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 454F86C3144 for ; Mon, 8 Mar 2010 14:47:10 +0100 (CET) Message-ID: <4B94FFDD.6000004@it.uc3m.es> Date: Mon, 08 Mar 2010 14:47:09 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: savi@ietf.org References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 13:47:08 -0000 El 08/03/10 12:16, Mikael Abrahamsson escribió: > On Mon, 8 Mar 2010, marcelo bagnulo braun wrote: > >> A second case may be the one of the dsl forum. their goal is to run >> savi in the CPE. Now, many ISPs have no problem allowing the user to >> connect a switch to their CPE. The thing here is that the ISP wants >> to deploy SAVI, but it can certainly not mandate their cusotmers to >> update their home switches. > > Requiring home equipment to be rebooted or at least their dhcp lease > renewed after an upgrade of the home gateway I think is no major problem. > mmm, not sure this is what we are talking about. we are talking about two things: - one,is that host would need to renw their dhcp lease after the savi device is rebooted. the problem here is that the host may not know hwne the AVI device is rebooted, so it will loose connectivity after a reboot and not clear how to trouble shoot that - the other thing is that switches connected to the device that is implementing SAVI will need to be upgraded, in order to be SAVI capable. So, it is either updating equiement (posible that belong to the end user) or rebooting the hosts of the client when the SAVI device reboots (which is not clearly how to realize when that is needed) > If I understood the problem correctly you're worried about the end > user outage occuring from the SAVI device is rebooted until all > clients have renewed their DHCP bindings so the SAVI device can filter > correctly? > right > What about recommending the SAVI device to save its state regularily > (and before each reboot) to non volatile storage so it properly can > keep SAVI state across reboots/power outage? Guess this might be hard > to implement as only storage regularily used in these devices are > flash drives and one doesn't really want to write to them all the time? > that would be my guess... i expect that the SAIV binding information may be quite dynamic and storing it in non volatile memory would be challenging. I mean, if problems of loosing state could be solved by sotring it in non volatile memory, life would be much easeir, we wouldn't need RST in TCP, ongoing communications woudl be able to survive reboots of nat boxes and firewalls and so on... Regards, marcelo From marcelo@it.uc3m.es Mon Mar 8 06:03:16 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F43C3A69A9 for ; Mon, 8 Mar 2010 06:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzyeOfGVgnlc for ; Mon, 8 Mar 2010 06:03:14 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 291F63A69B6 for ; Mon, 8 Mar 2010 06:03:10 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 24ADA6C6D6E; Mon, 8 Mar 2010 15:03:12 +0100 (CET) Message-ID: <4B95039F.7030908@it.uc3m.es> Date: Mon, 08 Mar 2010 15:03:11 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Bi Jun References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> In-Reply-To: <10F327EA71564228A016D2641E12121A@junbiVAIO> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 14:03:16 -0000 El 08/03/10 12:24, Bi Jun escribi¨®: > > > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Monday, March 08, 2010 6:33 PM > To: "Bi Jun" > Cc: > Subject: Re: [savi] call for comments: savi-dhcp-01 > >> below... >> >> El 08/03/10 11:16, Bi Jun escribi¨®: >>> Hi Marcelo, >>> >>> You actually bring two questions. >>> >>> >>> One question is on deployment: can we deploy a solution on legacy >>> switch. >>> Another is on the user's scenario: do we need to support the case when >>> latency switch is involved. >>> >>> For question 1, my point is: if the solution is very simple and just >>> need >>> to upgrade a software version, doesn't need to change hardware, then >>> it will be yes. >> In any case, this approahc would impose an upgrade of most of the >> switches in the network. >> I argue that this may be feasible in some scenarios and not in others. >> A couple of examples. > > Actually, the savi-switches are independent. Deployment on one switch > doesn't rely on > the deployment of other switches. So you don't need to change most > switches, you upgrade one, then get one benefit, it's incremental > deployment. > > not really If SAVI switches reboots imply that the communication will be interrupted unless all switches are upgraded to support SAVI, then if you only replace one switch, then you are breaking your netwokr. So in order to work properly, you need to upgrade all the network. So, this is not incrementally deployable > >> >> Suppose you are providing serv ice for a cmapus network and everybody >> has these small hub switches in their offices, and that is perfeclty ok >> with the security policy (this is the case of my university for >> instance) >> We have a variety of small hubs, some of them are fairly old. Moreover, >> some people are running virtual machines in their computers, do the hubs >> is actually virtual. In this scenario, which i would argue is fairly >> common, it is not trvial to update all the switches. > > Please note that the savi-dhcp-01 could handle the hub connection in > normal cases. what do you mean normal and special cases? I am talking about a case where the savi switch reboots, there is nothing special about it. My CPE at home is rebooted several times a week, while my laptop none. > You are actually taking about how to handle special cases. > > If you are the administrator (like us), if you enforce SAVI, then you > can ask > the users directly attached hosts to savi-switch. sure, but i guess we want to define a solution that can be used by a wider client base that can include other needs, right? > If some users still want the flexibility with a hub, then in the MOST > cases there will be no problem (the reboot > of savi-switch in your example will be very low frequent event), what do you mean that a reboot of a device is not a frequent event? What is being argued here is that after a reboot in a switch all hosts will be disconnected from the network. What is the reliability of the resulting network? > then if you found the network has the problem, you just need to reboot > your hub, you want the flexibility then you pay it by rebooting your > own hub. No, if we want reliability, we design a protocol properly, in order to make reliable. I find hardly aceptbale to say that if you want reliability, you must manually reboot all the hubs in my office in random moments. what about if you are using a remote sessiona dn you are not physically on your office to reboot it? > We didn't see any problem > in our real deployment. It's the user's normal behavior in today's > internet, if you meet a problem, you plug off you cable and plug in > again. > I guess we simply disagree here. I believe in the end to end principle and all the other deisgn architectural principles that aim to provide reliable end to end communications. "manually reboot you hub" is not the way i think we should design a protocol, sorry. > Remember the "end-end argument" of system design: "If the application > can do it, don¡¯t do it at a lower layer ???? the end to end principle has a simple corolary that is the fate sharing corolary, which reccomend not to include state in the network that is require for the end to end cmmunication, so that the fate of the end host does not depends on the date of the soft state stored in the network. Following an approach where there is some state (i.e. the SAVI binding) that is stored in the network and that cannot be recovered automatically and requires manual intervention, clearly breaks the fate sharing principle and hence the end to end argument. > -- anyway the application knows the best what it need", that's the > successful philosophy of Internet. So don't make the system too > complex to handle special cases. That's why I said we need to evaluate > the cost and benefit. > > BTW, I agree that for high-end switch, we can ask them to do more with > a bigger solution to handle all special cases (even the special cases > are low frequency events), that's why I said maybe we might need two > RFCs (one simple/low cost solution for most cases, another ideal but > high cost solution for all cases). > again, i disagree, i don't think the ietf shoudl have a stnadrad track rfc that relies on users manually rebooting their hubs in order to recover >> >> A second case may be the one of the dsl forum. their goal is to run savi >> in the CPE. Now, many ISPs have no problem allowing the user to connect >> a switch to their CPE. The thing here is that the ISP wants to deploy >> SAVI, but it can certainly not mandate their cusotmers to update their >> home switches. > > > Currently, DSL is a separate scope. > how come? i understood the the dsl forum was planing to use the SAVI specs > > >> >> So, i still don't think we can simply dismiss this scenario >> >>> The current savi-dhcp-01 is very easy to be implemented by >>> software-only (it has been >>> proved by several switch vendors by real products, which I will report >>> at IETF77), Then it will be very easy for users to deploy it on his >>> current (legacy) switch, >>> where CERNET is deploying it. Moreover, if the legacy switch is too >>> old to upgrade >>> the software, because the life time of access switch hardware is about >>> 3 years, then >>> when the user purchase a new switch, the switch will be upgraded. >>> >> >> well, where i come from we don't upgrade office hubs every 3 years, i >> can tell you that for sure. >> >>> If the answer of question 1 is yes, then the in the most cases, then >>> scenario of question 2 is less important. So my point is that we need >>> to evaluate if the cost (brought to switch) matches the benefit. My >>> proposal is to have one RFC for one scenario that we have consensus >> i am not sure what do you mean we have consensus. I agree we need to >> support this scenario, but we certainly do not have consensus on having >> a solution that only supports this particular scenario >> >> second, i am so far only talking about the dhcp based savi, in the case >> of ND based savi the issues are far more severa and the soltion is >> likely to support any scenario in any case. > > I really doubt on a big solution trying to resolve any problems in any > scenarios, sometimes might means impossible in engineering/practice > (too complex to be implemented at least in most devices). > i eprsonally doubt of a soluton that significantly reduces the reliability of the netowkr architecture that we have > > >> >> So, i don't agree with your proposed way froward >> >>> (e.g. the host directly attached to the savi switch), then if it is >>> really needed, having another RFC for more complicated cases (maybe >>> because the cost to switch, not many vendors really implement in the >>> real world in recent years). Certainly, the scenarios will be >>> presented in savi-framework. >>> >>> By the way, the probe in my previous email meant that the savi-device >>> send out packets (dad-ns, confirm, etc) to host/or might to dhcp >>> server, triggered by data packets or timers. >> mm, so you mean that if the SAVI device receives a data packet for which >> it does not have a binding, it sends the DHCP CONFIRM to the dhcp server >> to see if the server validates it, it that what you meant? >> >> that seems reasonable to me >> > > > > Yes, we can have some way to handle it. In my last PPT in IETF76, I > presented lots > of similar solutions. > But I still think it's not good to bring too much cost to the > savi-device which are low-end access switch in most cases, just for > some very special event (which can be simply fixed by users). > > but, what is the cost of a solution that is non relibale? how much is the cost of dowtime of the internet access? how much is the cost of having to update or upgrade all the legacy equipment? I mean, it makes no sense to say that one solution is expensive, we need to compare the different costs. IMHO, high reliability and backward compatibility are much better options. Regards, marcelo > > > > >> >>> It was used to handle the case when host moving (and other cases) >>> under legacy switch in my last presentation at IETF, it seemed that >>> people think triggering those probes make the switch too complex (Joe, >>> etc.) and the vendors also don't like the data-packet triggered >>> actions based on the feedbacks when we work with vendors in the past >>> months (H3C, ZTE, Ruijie, DC, etc..). >>> >> i can see that, but the question is what the overall robustness and >> deployability of the alternative solution. that is imho what we need to >> duscuss and understand. >> >> Regards, marcelo >> >> >>> thanks, >>> Jun Bi >>> -------------------------------------------------- >>> From: "marcelo bagnulo braun" >>> Sent: Monday, March 08, 2010 5:29 PM >>> To: "Jun Bi" >>> Cc: >>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>> >>>> Hi Jun, >>>> >>>> Thanks for the answer. >>>> >>>> So, your proposal is to simply rule out this scenario and make dhcp >>>> based savi to require that all hosts are directly connected tot he >>>> SAVI >>>> device? >>>> >>>> I think this would significantly limit the solution applicabillity and >>>> the chances of its deployment (it basically will require to upgrade >>>> most >>>> of the switches in the network in order to run SAVI). >>>> >>>> I don't believe this is a good approach. I think we need to define a >>>> SAVI solution that allows for incremental deployment in the >>>> network, if >>>> we want this to happen. >>>> >>>> So commenting on you reply below... >>>> >>>> El 08/03/10 10:14, Jun Bi escribi¨®: >>>>> Hi Marcelo, >>>>> >>>>> During my presentation at IETF76, some people commented that >>>>> it took much effort for SAVI-device to send probe packets to >>>>> handle the special case. >>>> I don't recall that disucssion, probably i missed that one >>>> >>>> So, could you explain to me how would you deal with that case by >>>> probing? >>>> >>> >>> Please read my ppt in IETF76 meeting. >>> >>> >>> >>>> I mean, it is not obvious to me how the SAVI device knows who to >>>> probe, >>>> since it has lost its state >>>> >>>>> Then in this dhcp-01 version, >>>>> we make the solution for the most recommended use case: the host >>>>> directly attached to savi device. >>>> I don't think we cna limit ourselves to this specific case, as i >>>> mentioned before >>>>> We hope we could reach >>>>> consensus on this part then we could go further to discuss the >>>>> situation when legacy switch involved >>>> not sure what do you mean here... >>>> I agree we need to discuss this and get consensus to move forward. >>>> >>>> >>>>> (does the cost matches the benefit?). >>>>> It also needs the savi-framework to state the user's scenarios. >>>>> >>>> I also agree this should be part of the framework document. >>>> >>>> Regards, marcelo >>>> >>>> >>>>> thanks, >>>>> Jun Bi >>>>> >>>>>> >>>>>> >>>>>> -------------------------------------------------- >>>>>> From: "marcelo bagnulo braun" >>>>>> Sent: Monday, March 08, 2010 4:33 PM >>>>>> To: >>>>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have a question that it was not apparent to me from the draft >>>>>>> >>>>>>> Suppose the following configuration: >>>>>>> >>>>>>> +------+ +-------------+ +-----------+ +---------------+ >>>>>>> | Host |------|Legacy device|-------|SAVI device|-------|rest of >>>>>>> the >>>>>>> net| >>>>>>> +------+ +-------------+ +-----------+ +---------------+ >>>>>>> >>>>>>> Suppose the host connects, does the DHCP exchange and the SAVI >>>>>>> device creates the binding. >>>>>>> Suppose now that the SAVI device loose the state (e.g. it >>>>>>> reboots or >>>>>>> crashes) >>>>>>> >>>>>>> What happens next? Is the SAVI device able to recover the binding >>>>>>> information? >>>>>>> >>>>>>> I guess some of the info is stored in the dhcp server, but probably >>>>>>> not all of it (i.e. >>>>>>> the lower layer anchor info may not be present) >>>>>>> >>>>>>> Regards, marcelo >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> El 03/03/10 13:18, Bi Jun escribi¨®: >>>>>>>> Dear WG members, >>>>>>>> This is the 01 version of savi-dhcp solution. >>>>>>>> Comments please. >>>>>>>> Thank you very much! >>>>>>>> Jun Bi >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> savi mailing list >>>>>>>> savi@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> savi mailing list >>>>>>> savi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>> >> > From junbi@tsinghua.edu.cn Mon Mar 8 06:42:19 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C561D3A6904 for ; Mon, 8 Mar 2010 06:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.103 X-Spam-Level: X-Spam-Status: No, score=-1.103 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HNbhGOYu9p1 for ; Mon, 8 Mar 2010 06:42:18 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id EC26D3A68FF for ; Mon, 8 Mar 2010 06:42:16 -0800 (PST) Received: from th024139.ip.tsinghua.edu.cn ([59.66.24.139] helo=junbiVAIO) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1Noe9t-0001Yq-I3; Mon, 08 Mar 2010 22:42:13 +0800 Message-ID: <6CA49CF9A8CE4F32A3CC30D09365C9A6@junbiVAIO> From: "Jun Bi" To: "marcelo bagnulo braun" , "Bi Jun" References: <4B94C376.40502@it.uc3m.es><4B94D28C.3000205@it.uc3m.es><10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> In-Reply-To: <4B95039F.7030908@it.uc3m.es> Date: Mon, 8 Mar 2010 22:42:14 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 14:42:19 -0000 -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Monday, March 08, 2010 10:03 PM To: "Bi Jun" Cc: Subject: Re: [savi] call for comments: savi-dhcp-01 > El 08/03/10 12:24, Bi Jun escribi¨®: >> >> >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Monday, March 08, 2010 6:33 PM >> To: "Bi Jun" >> Cc: >> Subject: Re: [savi] call for comments: savi-dhcp-01 >> >>> below... >>> >>> El 08/03/10 11:16, Bi Jun escribi¨®: >>>> Hi Marcelo, >>>> >>>> You actually bring two questions. >>>> >>>> >>>> One question is on deployment: can we deploy a solution on legacy >>>> switch. >>>> Another is on the user's scenario: do we need to support the case when >>>> latency switch is involved. >>>> >>>> For question 1, my point is: if the solution is very simple and just >>>> need >>>> to upgrade a software version, doesn't need to change hardware, then >>>> it will be yes. >>> In any case, this approahc would impose an upgrade of most of the >>> switches in the network. >>> I argue that this may be feasible in some scenarios and not in others. >>> A couple of examples. >> >> Actually, the savi-switches are independent. Deployment on one switch >> doesn't rely on >> the deployment of other switches. So you don't need to change most >> switches, you upgrade one, then get one benefit, it's incremental >> deployment. >> >> > > not really > > If SAVI switches reboots imply that the communication will be > interrupted unless all switches are upgraded to support SAVI, then if > you only replace one switch, then you are breaking your netwokr. So in > order to work properly, you need to upgrade all the network. > So, this is not incrementally deployable I can't agree your statement I upgrade one access switch, enable the savi at ports that directly attach a host. For other ports, I can decide to enable savi or not, how the this switch affects other switches and how it breaking my network? >> >>> >>> Suppose you are providing serv ice for a cmapus network and everybody >>> has these small hub switches in their offices, and that is perfeclty ok >>> with the security policy (this is the case of my university for >>> instance) >>> We have a variety of small hubs, some of them are fairly old. Moreover, >>> some people are running virtual machines in their computers, do the hubs >>> is actually virtual. In this scenario, which i would argue is fairly >>> common, it is not trvial to update all the switches. >> >> Please note that the savi-dhcp-01 could handle the hub connection in >> normal cases. > what do you mean normal and special cases? > I am talking about a case where the savi switch reboots, there is > nothing special about it. My CPE at home is rebooted several times a > week, while my laptop none. > Certainly in an operational enterprise network or a campus network, the reboot of the switch will not frequent. >> You are actually taking about how to handle special cases. >> >> If you are the administrator (like us), if you enforce SAVI, then you >> can ask >> the users directly attached hosts to savi-switch. > > sure, but i guess we want to define a solution that can be used by a > wider client base that can include other needs, right? > >> If some users still want the flexibility with a hub, then in the MOST >> cases there will be no problem (the reboot >> of savi-switch in your example will be very low frequent event), > > what do you mean that a reboot of a device is not a frequent event? > What is being argued here is that after a reboot in a switch all hosts > will be disconnected from the network. What is the reliability of the > resulting network? > >> then if you found the network has the problem, you just need to reboot >> your hub, you want the flexibility then you pay it by rebooting your >> own hub. > No, if we want reliability, we design a protocol properly, in order to > make reliable. > I find hardly aceptbale to say that if you want reliability, you must > manually reboot all the hubs in my office in random moments. > > what about if you are using a remote sessiona dn you are not physically > on your office to reboot it? > > > >> We didn't see any problem >> in our real deployment. It's the user's normal behavior in today's >> internet, if you meet a problem, you plug off you cable and plug in >> again. >> > I guess we simply disagree here. > I believe in the end to end principle and all the other deisgn > architectural principles that aim to provide reliable end to end > communications. "manually reboot you hub" is not the way i think we > should design a protocol, sorry. > I said the most recommended use case is for host directly attached to savi switch in savi-dhcp-01. In this case, it's reliable. If you want the flexibility, you can still plug in your hub, we can mentioned this risk in the draft, but we don't recommend. A separate RFC might be considered if need to cover more use case with higher cost if the users really need (although I really doubt if it could be really implemented in the real work). This is also my answer to your most similar questions below. >> Remember the "end-end argument" of system design: "If the application >> can do it, don¡¯t do it at a lower layer > > ???? > > the end to end principle has a simple corolary that is the fate sharing > corolary, which reccomend not to include state in the network that is > require for the end to end cmmunication, so that the fate of the end > host does not depends on the date of the soft state stored in the network. > > Following an approach where there is some state (i.e. the SAVI binding) > that is stored in the network and that cannot be recovered automatically > and requires manual intervention, clearly breaks the fate sharing > principle and hence the end to end argument. > > >> -- anyway the application knows the best what it need", that's the >> successful philosophy of Internet. So don't make the system too >> complex to handle special cases. That's why I said we need to evaluate >> the cost and benefit. >> >> BTW, I agree that for high-end switch, we can ask them to do more with >> a bigger solution to handle all special cases (even the special cases >> are low frequency events), that's why I said maybe we might need two >> RFCs (one simple/low cost solution for most cases, another ideal but >> high cost solution for all cases). >> > again, i disagree, i don't think the ietf shoudl have a stnadrad track > rfc that relies on users manually rebooting their hubs in order to recover > >>> >>> A second case may be the one of the dsl forum. their goal is to run savi >>> in the CPE. Now, many ISPs have no problem allowing the user to connect >>> a switch to their CPE. The thing here is that the ISP wants to deploy >>> SAVI, but it can certainly not mandate their cusotmers to update their >>> home switches. >> >> >> Currently, DSL is a separate scope. >> > > how come? > i understood the the dsl forum was planing to use the SAVI specs For DSL, it was just discussed by Mikael. And I just sent email saying that we agree to adopt the advice from Mikael by storing the state if the device before savi reboot. Thanks to Mikael. >> >> >>> >>> So, i still don't think we can simply dismiss this scenario >>> >>>> The current savi-dhcp-01 is very easy to be implemented by >>>> software-only (it has been >>>> proved by several switch vendors by real products, which I will report >>>> at IETF77), Then it will be very easy for users to deploy it on his >>>> current (legacy) switch, >>>> where CERNET is deploying it. Moreover, if the legacy switch is too >>>> old to upgrade >>>> the software, because the life time of access switch hardware is about >>>> 3 years, then >>>> when the user purchase a new switch, the switch will be upgraded. >>>> >>> >>> well, where i come from we don't upgrade office hubs every 3 years, i >>> can tell you that for sure. >>> >>>> If the answer of question 1 is yes, then the in the most cases, then >>>> scenario of question 2 is less important. So my point is that we need >>>> to evaluate if the cost (brought to switch) matches the benefit. My >>>> proposal is to have one RFC for one scenario that we have consensus >>> i am not sure what do you mean we have consensus. I agree we need to >>> support this scenario, but we certainly do not have consensus on having >>> a solution that only supports this particular scenario >>> >>> second, i am so far only talking about the dhcp based savi, in the case >>> of ND based savi the issues are far more severa and the soltion is >>> likely to support any scenario in any case. >> >> I really doubt on a big solution trying to resolve any problems in any >> scenarios, sometimes might means impossible in engineering/practice >> (too complex to be implemented at least in most devices). >> > i eprsonally doubt of a soluton that significantly reduces the > reliability of the netowkr architecture that we have > >> >> >>> >>> So, i don't agree with your proposed way froward >>> >>>> (e.g. the host directly attached to the savi switch), then if it is >>>> really needed, having another RFC for more complicated cases (maybe >>>> because the cost to switch, not many vendors really implement in the >>>> real world in recent years). Certainly, the scenarios will be >>>> presented in savi-framework. >>>> >>>> By the way, the probe in my previous email meant that the savi-device >>>> send out packets (dad-ns, confirm, etc) to host/or might to dhcp >>>> server, triggered by data packets or timers. >>> mm, so you mean that if the SAVI device receives a data packet for which >>> it does not have a binding, it sends the DHCP CONFIRM to the dhcp server >>> to see if the server validates it, it that what you meant? >>> >>> that seems reasonable to me >>> >> >> >> >> Yes, we can have some way to handle it. In my last PPT in IETF76, I >> presented lots >> of similar solutions. >> But I still think it's not good to bring too much cost to the >> savi-device which are low-end access switch in most cases, just for >> some very special event (which can be simply fixed by users). >> >> > > but, what is the cost of a solution that is non relibale? how much is > the cost of dowtime of the internet access? how much is the cost of > having to update or upgrade all the legacy equipment? > > I mean, it makes no sense to say that one solution is expensive, we need > to compare the different costs. > IMHO, high reliability and backward compatibility are much better options. > > Regards, marcelo > >> >> >> >> >>> >>>> It was used to handle the case when host moving (and other cases) >>>> under legacy switch in my last presentation at IETF, it seemed that >>>> people think triggering those probes make the switch too complex (Joe, >>>> etc.) and the vendors also don't like the data-packet triggered >>>> actions based on the feedbacks when we work with vendors in the past >>>> months (H3C, ZTE, Ruijie, DC, etc..). >>>> >>> i can see that, but the question is what the overall robustness and >>> deployability of the alternative solution. that is imho what we need to >>> duscuss and understand. >>> >>> Regards, marcelo >>> >>> >>>> thanks, >>>> Jun Bi >>>> -------------------------------------------------- >>>> From: "marcelo bagnulo braun" >>>> Sent: Monday, March 08, 2010 5:29 PM >>>> To: "Jun Bi" >>>> Cc: >>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>> >>>>> Hi Jun, >>>>> >>>>> Thanks for the answer. >>>>> >>>>> So, your proposal is to simply rule out this scenario and make dhcp >>>>> based savi to require that all hosts are directly connected tot he >>>>> SAVI >>>>> device? >>>>> >>>>> I think this would significantly limit the solution applicabillity and >>>>> the chances of its deployment (it basically will require to upgrade >>>>> most >>>>> of the switches in the network in order to run SAVI). >>>>> >>>>> I don't believe this is a good approach. I think we need to define a >>>>> SAVI solution that allows for incremental deployment in the >>>>> network, if >>>>> we want this to happen. >>>>> >>>>> So commenting on you reply below... >>>>> >>>>> El 08/03/10 10:14, Jun Bi escribi¨®: >>>>>> Hi Marcelo, >>>>>> >>>>>> During my presentation at IETF76, some people commented that >>>>>> it took much effort for SAVI-device to send probe packets to >>>>>> handle the special case. >>>>> I don't recall that disucssion, probably i missed that one >>>>> >>>>> So, could you explain to me how would you deal with that case by >>>>> probing? >>>>> >>>> >>>> Please read my ppt in IETF76 meeting. >>>> >>>> >>>> >>>>> I mean, it is not obvious to me how the SAVI device knows who to >>>>> probe, >>>>> since it has lost its state >>>>> >>>>>> Then in this dhcp-01 version, >>>>>> we make the solution for the most recommended use case: the host >>>>>> directly attached to savi device. >>>>> I don't think we cna limit ourselves to this specific case, as i >>>>> mentioned before >>>>>> We hope we could reach >>>>>> consensus on this part then we could go further to discuss the >>>>>> situation when legacy switch involved >>>>> not sure what do you mean here... >>>>> I agree we need to discuss this and get consensus to move forward. >>>>> >>>>> >>>>>> (does the cost matches the benefit?). >>>>>> It also needs the savi-framework to state the user's scenarios. >>>>>> >>>>> I also agree this should be part of the framework document. >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>>> thanks, >>>>>> Jun Bi >>>>>> >>>>>>> >>>>>>> >>>>>>> -------------------------------------------------- >>>>>>> From: "marcelo bagnulo braun" >>>>>>> Sent: Monday, March 08, 2010 4:33 PM >>>>>>> To: >>>>>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have a question that it was not apparent to me from the draft >>>>>>>> >>>>>>>> Suppose the following configuration: >>>>>>>> >>>>>>>> +------+ +-------------+ +-----------+ +---------------+ >>>>>>>> | Host |------|Legacy device|-------|SAVI device|-------|rest of >>>>>>>> the >>>>>>>> net| >>>>>>>> +------+ +-------------+ +-----------+ +---------------+ >>>>>>>> >>>>>>>> Suppose the host connects, does the DHCP exchange and the SAVI >>>>>>>> device creates the binding. >>>>>>>> Suppose now that the SAVI device loose the state (e.g. it >>>>>>>> reboots or >>>>>>>> crashes) >>>>>>>> >>>>>>>> What happens next? Is the SAVI device able to recover the binding >>>>>>>> information? >>>>>>>> >>>>>>>> I guess some of the info is stored in the dhcp server, but probably >>>>>>>> not all of it (i.e. >>>>>>>> the lower layer anchor info may not be present) >>>>>>>> >>>>>>>> Regards, marcelo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> El 03/03/10 13:18, Bi Jun escribi¨®: >>>>>>>>> Dear WG members, >>>>>>>>> This is the 01 version of savi-dhcp solution. >>>>>>>>> Comments please. >>>>>>>>> Thank you very much! >>>>>>>>> Jun Bi >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> savi mailing list >>>>>>>>> savi@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> savi mailing list >>>>>>>> savi@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>> >>> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@tsinghua.edu.cn Mon Mar 8 07:11:11 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3623A69C8 for ; Mon, 8 Mar 2010 07:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.103 X-Spam-Level: X-Spam-Status: No, score=-1.103 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-F1ybljVYz7 for ; Mon, 8 Mar 2010 07:11:09 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 323523A698B for ; Mon, 8 Mar 2010 07:11:08 -0800 (PST) Received: from th024139.ip.tsinghua.edu.cn ([59.66.24.139] helo=junbiVAIO) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1Noebs-0003lC-Ua; Mon, 08 Mar 2010 23:11:09 +0800 Message-ID: <236523D9F9984C198687B319D96A3C70@junbiVAIO> From: "Jun Bi" To: "marcelo bagnulo braun" References: <4B94C376.40502@it.uc3m.es><4B94D28C.3000205@it.uc3m.es><10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> In-Reply-To: <4B95039F.7030908@it.uc3m.es> Date: Mon, 8 Mar 2010 23:11:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 15:11:11 -0000 Hi Marcelo, The storing states before savi device rebooting is adopted at the latest version of savi-dhcp-01 to be submitted to ietf, to make it reliable to handle your example. I remember Eirc had a similar suggestion. Thanks to Mikael and Eric. Best Regards, Jun Bi -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Monday, March 08, 2010 10:03 PM To: "Bi Jun" Cc: Subject: Re: [savi] call for comments: savi-dhcp-01 > El 08/03/10 12:24, Bi Jun escribi¨®: >> >> >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Monday, March 08, 2010 6:33 PM >> To: "Bi Jun" >> Cc: >> Subject: Re: [savi] call for comments: savi-dhcp-01 >> >>> below... >>> >>> El 08/03/10 11:16, Bi Jun escribi¨®: >>>> Hi Marcelo, >>>> >>>> You actually bring two questions. >>>> >>>> >>>> One question is on deployment: can we deploy a solution on legacy >>>> switch. >>>> Another is on the user's scenario: do we need to support the case when >>>> latency switch is involved. >>>> >>>> For question 1, my point is: if the solution is very simple and just >>>> need >>>> to upgrade a software version, doesn't need to change hardware, then >>>> it will be yes. >>> In any case, this approahc would impose an upgrade of most of the >>> switches in the network. >>> I argue that this may be feasible in some scenarios and not in others. >>> A couple of examples. >> >> Actually, the savi-switches are independent. Deployment on one switch >> doesn't rely on >> the deployment of other switches. So you don't need to change most >> switches, you upgrade one, then get one benefit, it's incremental >> deployment. >> >> > > not really > > If SAVI switches reboots imply that the communication will be > interrupted unless all switches are upgraded to support SAVI, then if > you only replace one switch, then you are breaking your netwokr. So in > order to work properly, you need to upgrade all the network. > So, this is not incrementally deployable >> >>> >>> Suppose you are providing serv ice for a cmapus network and everybody >>> has these small hub switches in their offices, and that is perfeclty ok >>> with the security policy (this is the case of my university for >>> instance) >>> We have a variety of small hubs, some of them are fairly old. Moreover, >>> some people are running virtual machines in their computers, do the hubs >>> is actually virtual. In this scenario, which i would argue is fairly >>> common, it is not trvial to update all the switches. >> >> Please note that the savi-dhcp-01 could handle the hub connection in >> normal cases. > what do you mean normal and special cases? > I am talking about a case where the savi switch reboots, there is > nothing special about it. My CPE at home is rebooted several times a > week, while my laptop none. > >> You are actually taking about how to handle special cases. >> >> If you are the administrator (like us), if you enforce SAVI, then you >> can ask >> the users directly attached hosts to savi-switch. > > sure, but i guess we want to define a solution that can be used by a > wider client base that can include other needs, right? > >> If some users still want the flexibility with a hub, then in the MOST >> cases there will be no problem (the reboot >> of savi-switch in your example will be very low frequent event), > > what do you mean that a reboot of a device is not a frequent event? > What is being argued here is that after a reboot in a switch all hosts > will be disconnected from the network. What is the reliability of the > resulting network? > >> then if you found the network has the problem, you just need to reboot >> your hub, you want the flexibility then you pay it by rebooting your >> own hub. > No, if we want reliability, we design a protocol properly, in order to > make reliable. > I find hardly aceptbale to say that if you want reliability, you must > manually reboot all the hubs in my office in random moments. > > what about if you are using a remote sessiona dn you are not physically > on your office to reboot it? > > > >> We didn't see any problem >> in our real deployment. It's the user's normal behavior in today's >> internet, if you meet a problem, you plug off you cable and plug in >> again. >> > I guess we simply disagree here. > I believe in the end to end principle and all the other deisgn > architectural principles that aim to provide reliable end to end > communications. "manually reboot you hub" is not the way i think we > should design a protocol, sorry. > >> Remember the "end-end argument" of system design: "If the application >> can do it, don¡¯t do it at a lower layer > > ???? > > the end to end principle has a simple corolary that is the fate sharing > corolary, which reccomend not to include state in the network that is > require for the end to end cmmunication, so that the fate of the end > host does not depends on the date of the soft state stored in the network. > > Following an approach where there is some state (i.e. the SAVI binding) > that is stored in the network and that cannot be recovered automatically > and requires manual intervention, clearly breaks the fate sharing > principle and hence the end to end argument. > > >> -- anyway the application knows the best what it need", that's the >> successful philosophy of Internet. So don't make the system too >> complex to handle special cases. That's why I said we need to evaluate >> the cost and benefit. >> >> BTW, I agree that for high-end switch, we can ask them to do more with >> a bigger solution to handle all special cases (even the special cases >> are low frequency events), that's why I said maybe we might need two >> RFCs (one simple/low cost solution for most cases, another ideal but >> high cost solution for all cases). >> > again, i disagree, i don't think the ietf shoudl have a stnadrad track > rfc that relies on users manually rebooting their hubs in order to recover > >>> >>> A second case may be the one of the dsl forum. their goal is to run savi >>> in the CPE. Now, many ISPs have no problem allowing the user to connect >>> a switch to their CPE. The thing here is that the ISP wants to deploy >>> SAVI, but it can certainly not mandate their cusotmers to update their >>> home switches. >> >> >> Currently, DSL is a separate scope. >> > > how come? > i understood the the dsl forum was planing to use the SAVI specs >> >> >>> >>> So, i still don't think we can simply dismiss this scenario >>> >>>> The current savi-dhcp-01 is very easy to be implemented by >>>> software-only (it has been >>>> proved by several switch vendors by real products, which I will report >>>> at IETF77), Then it will be very easy for users to deploy it on his >>>> current (legacy) switch, >>>> where CERNET is deploying it. Moreover, if the legacy switch is too >>>> old to upgrade >>>> the software, because the life time of access switch hardware is about >>>> 3 years, then >>>> when the user purchase a new switch, the switch will be upgraded. >>>> >>> >>> well, where i come from we don't upgrade office hubs every 3 years, i >>> can tell you that for sure. >>> >>>> If the answer of question 1 is yes, then the in the most cases, then >>>> scenario of question 2 is less important. So my point is that we need >>>> to evaluate if the cost (brought to switch) matches the benefit. My >>>> proposal is to have one RFC for one scenario that we have consensus >>> i am not sure what do you mean we have consensus. I agree we need to >>> support this scenario, but we certainly do not have consensus on having >>> a solution that only supports this particular scenario >>> >>> second, i am so far only talking about the dhcp based savi, in the case >>> of ND based savi the issues are far more severa and the soltion is >>> likely to support any scenario in any case. >> >> I really doubt on a big solution trying to resolve any problems in any >> scenarios, sometimes might means impossible in engineering/practice >> (too complex to be implemented at least in most devices). >> > i eprsonally doubt of a soluton that significantly reduces the > reliability of the netowkr architecture that we have > >> >> >>> >>> So, i don't agree with your proposed way froward >>> >>>> (e.g. the host directly attached to the savi switch), then if it is >>>> really needed, having another RFC for more complicated cases (maybe >>>> because the cost to switch, not many vendors really implement in the >>>> real world in recent years). Certainly, the scenarios will be >>>> presented in savi-framework. >>>> >>>> By the way, the probe in my previous email meant that the savi-device >>>> send out packets (dad-ns, confirm, etc) to host/or might to dhcp >>>> server, triggered by data packets or timers. >>> mm, so you mean that if the SAVI device receives a data packet for which >>> it does not have a binding, it sends the DHCP CONFIRM to the dhcp server >>> to see if the server validates it, it that what you meant? >>> >>> that seems reasonable to me >>> >> >> >> >> Yes, we can have some way to handle it. In my last PPT in IETF76, I >> presented lots >> of similar solutions. >> But I still think it's not good to bring too much cost to the >> savi-device which are low-end access switch in most cases, just for >> some very special event (which can be simply fixed by users). >> >> > > but, what is the cost of a solution that is non relibale? how much is > the cost of dowtime of the internet access? how much is the cost of > having to update or upgrade all the legacy equipment? > > I mean, it makes no sense to say that one solution is expensive, we need > to compare the different costs. > IMHO, high reliability and backward compatibility are much better options. > > Regards, marcelo > >> >> >> >> >>> >>>> It was used to handle the case when host moving (and other cases) >>>> under legacy switch in my last presentation at IETF, it seemed that >>>> people think triggering those probes make the switch too complex (Joe, >>>> etc.) and the vendors also don't like the data-packet triggered >>>> actions based on the feedbacks when we work with vendors in the past >>>> months (H3C, ZTE, Ruijie, DC, etc..). >>>> >>> i can see that, but the question is what the overall robustness and >>> deployability of the alternative solution. that is imho what we need to >>> duscuss and understand. >>> >>> Regards, marcelo >>> >>> >>>> thanks, >>>> Jun Bi >>>> -------------------------------------------------- >>>> From: "marcelo bagnulo braun" >>>> Sent: Monday, March 08, 2010 5:29 PM >>>> To: "Jun Bi" >>>> Cc: >>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>> >>>>> Hi Jun, >>>>> >>>>> Thanks for the answer. >>>>> >>>>> So, your proposal is to simply rule out this scenario and make dhcp >>>>> based savi to require that all hosts are directly connected tot he >>>>> SAVI >>>>> device? >>>>> >>>>> I think this would significantly limit the solution applicabillity and >>>>> the chances of its deployment (it basically will require to upgrade >>>>> most >>>>> of the switches in the network in order to run SAVI). >>>>> >>>>> I don't believe this is a good approach. I think we need to define a >>>>> SAVI solution that allows for incremental deployment in the >>>>> network, if >>>>> we want this to happen. >>>>> >>>>> So commenting on you reply below... >>>>> >>>>> El 08/03/10 10:14, Jun Bi escribi¨®: >>>>>> Hi Marcelo, >>>>>> >>>>>> During my presentation at IETF76, some people commented that >>>>>> it took much effort for SAVI-device to send probe packets to >>>>>> handle the special case. >>>>> I don't recall that disucssion, probably i missed that one >>>>> >>>>> So, could you explain to me how would you deal with that case by >>>>> probing? >>>>> >>>> >>>> Please read my ppt in IETF76 meeting. >>>> >>>> >>>> >>>>> I mean, it is not obvious to me how the SAVI device knows who to >>>>> probe, >>>>> since it has lost its state >>>>> >>>>>> Then in this dhcp-01 version, >>>>>> we make the solution for the most recommended use case: the host >>>>>> directly attached to savi device. >>>>> I don't think we cna limit ourselves to this specific case, as i >>>>> mentioned before >>>>>> We hope we could reach >>>>>> consensus on this part then we could go further to discuss the >>>>>> situation when legacy switch involved >>>>> not sure what do you mean here... >>>>> I agree we need to discuss this and get consensus to move forward. >>>>> >>>>> >>>>>> (does the cost matches the benefit?). >>>>>> It also needs the savi-framework to state the user's scenarios. >>>>>> >>>>> I also agree this should be part of the framework document. >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>>> thanks, >>>>>> Jun Bi >>>>>> >>>>>>> >>>>>>> >>>>>>> -------------------------------------------------- >>>>>>> From: "marcelo bagnulo braun" >>>>>>> Sent: Monday, March 08, 2010 4:33 PM >>>>>>> To: >>>>>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have a question that it was not apparent to me from the draft >>>>>>>> >>>>>>>> Suppose the following configuration: >>>>>>>> >>>>>>>> +------+ +-------------+ +-----------+ +---------------+ >>>>>>>> | Host |------|Legacy device|-------|SAVI device|-------|rest of >>>>>>>> the >>>>>>>> net| >>>>>>>> +------+ +-------------+ +-----------+ +---------------+ >>>>>>>> >>>>>>>> Suppose the host connects, does the DHCP exchange and the SAVI >>>>>>>> device creates the binding. >>>>>>>> Suppose now that the SAVI device loose the state (e.g. it >>>>>>>> reboots or >>>>>>>> crashes) >>>>>>>> >>>>>>>> What happens next? Is the SAVI device able to recover the binding >>>>>>>> information? >>>>>>>> >>>>>>>> I guess some of the info is stored in the dhcp server, but probably >>>>>>>> not all of it (i.e. >>>>>>>> the lower layer anchor info may not be present) >>>>>>>> >>>>>>>> Regards, marcelo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> El 03/03/10 13:18, Bi Jun escribi¨®: >>>>>>>>> Dear WG members, >>>>>>>>> This is the 01 version of savi-dhcp solution. >>>>>>>>> Comments please. >>>>>>>>> Thank you very much! >>>>>>>>> Jun Bi >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> savi mailing list >>>>>>>>> savi@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> savi mailing list >>>>>>>> savi@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>> >>> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From root@core3.amsl.com Mon Mar 8 08:00:01 2010 Return-Path: X-Original-To: savi@ietf.org Delivered-To: savi@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A95673A69B4; Mon, 8 Mar 2010 08:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308160001.A95673A69B4@core3.amsl.com> Date: Mon, 8 Mar 2010 08:00:01 -0800 (PST) Cc: savi@ietf.org Subject: [savi] I-D Action:draft-ietf-savi-dhcp-01.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 16:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Address Validation Improvements Working Group of the IETF. Title : SAVI Solution for DHCP Author(s) : J. Bi, et al. Filename : draft-ietf-savi-dhcp-01.txt Pages : 22 Date : 2010-03-08 This document specifies the procedure for creating bindings between a DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and an anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets generated on the local link with forged IP addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-savi-dhcp-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-savi-dhcp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-08075204.I-D@ietf.org> --NextPart-- From elevyabe@cisco.com Mon Mar 8 09:55:43 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA323A6AFC for ; Mon, 8 Mar 2010 09:55:43 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LHmBkGMSKmG for ; Mon, 8 Mar 2010 09:55:42 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 96CA73A6A5F for ; Mon, 8 Mar 2010 09:55:42 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: New Version Notification for draft-levy-abegnoli-savi-plbt-02.eml : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADrJlEutJV2c/2dsb2JhbACDC5ggc6MLiCWPdYQOagQ X-IronPort-AV: E=Sophos;i="4.49,603,1262563200"; d="eml'208?scan'208,208";a="493442001" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-6.cisco.com with ESMTP; 08 Mar 2010 17:55:46 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o28Ht8La031852 for ; Mon, 8 Mar 2010 17:55:45 GMT Received: from xmb-ams-105.cisco.com ([144.254.74.80]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 18:55:03 +0100 Received: from [144.254.53.100] ([144.254.53.100]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 18:55:03 +0100 Message-ID: <4B9539F6.1080105@cisco.com> Date: Mon, 08 Mar 2010 18:55:02 +0100 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SAVI Mailing List Content-Type: multipart/mixed; boundary="------------020603030807090600090804" X-OriginalArrivalTime: 08 Mar 2010 17:55:03.0050 (UTC) FILETIME=[7A81D6A0:01CABEE8] Subject: [savi] [Fwd: New Version Notification for draft-levy-abegnoli-savi-plbt-02] X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 17:55:43 -0000 This is a multi-part message in MIME format. --------------020603030807090600090804 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit --------------020603030807090600090804 Content-Type: message/rfc822; name="New Version Notification for draft-levy-abegnoli-savi-plbt-02.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-levy-abegnoli-savi-plbt-0"; filename*1="2.eml" X-Account-Key: account2 X-Mozilla-Keys: Received: from xbh-ams-201.cisco.com ([144.254.75.7]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 18:48:26 +0100 Received: from xbh-rcd-201.cisco.com ([72.163.62.200]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 18:48:26 +0100 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 11:48:25 -0600 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2010 17:48:24 +0000 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o28HmDqs022308 for ; Mon, 8 Mar 2010 17:48:24 GMT X-from-outside-Cisco: 64.170.98.32 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYBAB/HlEtAqmIgjmdsb2JhbACDC4wwAYtuFQEBAQEJCwgJEQcdoweIJY92gTKCXGoEgxc X-IronPort-AV: E=Sophos;i="4.49,603,1262563200"; d="scan'208";a="142198663" Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-e.cisco.com with ESMTP; 08 Mar 2010 17:48:24 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id 260523A6B15; Mon, 8 Mar 2010 09:48:17 -0800 (PST) From: IETF I-D Submission Tool To: elevyabe@cisco.com Subject: New Version Notification for draft-levy-abegnoli-savi-plbt-02 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100308174818.260523A6B15@core3.amsl.com> Date: Mon, 8 Mar 2010 09:48:18 -0800 (PST) Return-Path: wwwrun@core3.amsl.com X-OriginalArrivalTime: 08 Mar 2010 17:48:25.0566 (UTC) FILETIME=[8D9697E0:01CABEE7] A new version of I-D, draft-levy-abegnoli-savi-plbt-02.txt has been successfuly submitted by Eric Levy-Abegnoli and posted to the IETF repository. Filename: draft-levy-abegnoli-savi-plbt Revision: 02 Title: Preference Level based Binding Table Creation_date: 2010-03-08 WG ID: Independent Submission Number_of_pages: 6 Abstract: Different documents [savi-fcfs] [savi-dhcp] [savi-send] propose different preference schemes to resolve binding entry collisions (same L3 address, different binding anchors) based of the address- assignment method that they cover. For instance [fcfs] keeps the first entry and rejects others. However, in heterogeneous deployments, all address-assignment methods co-exist, and there is a need for defining an algorithm that compare colliding entries across these different methods (and any other method not covered) to pick up a preferred one. This document describes one such algorithum. The IETF Secretariat. --------------020603030807090600090804-- From yaoa02@mails.tsinghua.edu.cn Mon Mar 8 22:24:13 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4728A3A6884 for ; Mon, 8 Mar 2010 22:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+69IvJWhZPi for ; Mon, 8 Mar 2010 22:24:09 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 1953E3A68A0 for ; Mon, 8 Mar 2010 22:20:24 -0800 (PST) Received: from th024014.ip.tsinghua.edu.cn ([59.66.24.14] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1Nosn8-0001Ml-HH for savi@ietf.org; Tue, 09 Mar 2010 14:19:42 +0800 From: "Guang Yao" To: References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> In-Reply-To: Date: Tue, 9 Mar 2010 14:19:34 +0800 Message-ID: <006201cabf50$7d010c30$77032490$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq+sL+CiMCC4XNGTcOYJSZ1TTOEpQAnSH0w Content-Language: zh-cn Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 06:24:14 -0000 IMO, if a savi device wants to restore state of not directly attached clients from reboot, which means no control packet can be used to restore binding, only two mechanisms can be chosen: 1. Use data packet to trigger binding set up. Then the additional overhead is mainly cpu cost. The cost is not only resulted from the added complexity, but also a possible data packet burst that may cause denial of service on cpu, and the complexity logic of filtering a single packet(you can't filter any packet until assured by server or probe in slaac scenario). 2. Store state into non violate storage manually or regularly. Then the additional overhead is mainly storage cost. If I can't avoid choosing one from them, I'd rather choose the second mechanism, as suggested by Mikael Abrahamsson and Eric Levy-Abegnoli. In general, storage chip is cheaper than processing chip. > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of > Mikael Abrahamsson > Sent: Monday, March 08, 2010 7:17 PM > To: savi@ietf.org > Subject: Re: [savi] call for comments: savi-dhcp-01 > > On Mon, 8 Mar 2010, marcelo bagnulo braun wrote: > > > A second case may be the one of the dsl forum. their goal is to run savi > > in the CPE. Now, many ISPs have no problem allowing the user to connect > > a switch to their CPE. The thing here is that the ISP wants to deploy > > SAVI, but it can certainly not mandate their cusotmers to update their > > home switches. > > Requiring home equipment to be rebooted or at least their dhcp lease > renewed after an upgrade of the home gateway I think is no major problem. > > If I understood the problem correctly you're worried about the end user > outage occuring from the SAVI device is rebooted until all clients have > renewed their DHCP bindings so the SAVI device can filter correctly? > > What about recommending the SAVI device to save its state regularily (and > before each reboot) to non volatile storage so it properly can keep SAVI > state across reboots/power outage? Guess this might be hard to implement > as only storage regularily used in these devices are flash drives and one > doesn't really want to write to them all the time? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From swmike@swm.pp.se Mon Mar 8 22:54:52 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59ED43A67B5 for ; Mon, 8 Mar 2010 22:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEbfk0w1Y8je for ; Mon, 8 Mar 2010 22:54:50 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id BEFB23A6765 for ; Mon, 8 Mar 2010 22:54:50 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1101EA1; Tue, 9 Mar 2010 07:54:50 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0FED79F; Tue, 9 Mar 2010 07:54:50 +0100 (CET) Date: Tue, 9 Mar 2010 07:54:50 +0100 (CET) From: Mikael Abrahamsson To: marcelo bagnulo braun In-Reply-To: <4B95039F.7030908@it.uc3m.es> Message-ID: References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 06:54:52 -0000 On Mon, 8 Mar 2010, marcelo bagnulo braun wrote: > If SAVI switches reboots imply that the communication will be > interrupted unless all switches are upgraded to support SAVI, then if > you only replace one switch, then you are breaking your netwokr. So in > order to work properly, you need to upgrade all the network. So, this is > not incrementally deployable Hi Marcelo. I very quickly read draft-bagnulo-savi-analysis-02.txt as you recommended, and as far as I can see, everything in it is correct. I guess we just see differently on the implications on network maintenance and stability. I come from an ISP background and have that point of view, I don't trust my customers and they have no certificate or other to verify that I am who I am, and my customers definitely can't trust each other. Therefore I try to make sure that traffic between customers does a route hop thru my equipment, so basically there is no L2 connectivity between customers. I also need to know what customer/port has what IP at any given time, which for me means I have to use stateful DHCP so I can store this binding. SLAAC is just not acceptable in this scenario (because of TCAM limitations in my equipment I don't want my equipment connected to a customer /64 without limitations on IPs used). We today have this problem with the bindings, especially if the customer has a switch in their apartment. If we reboot the basement switch, the computers won't know that via link-down, and the DHCPv4/IP bindings are lost. I guess most people would solve this using "repair connection" in their Windows machine, or just plain restart it, upon which everything starts again. If the customer is running their machine unattended then it'll be unreachable until a DHCP request/discover is seen again. So I do think we can agree that partially deploying SAVI framework on just some devices has its disadvantages, but I still think they can be managed by the network staff knowing about this downside and working around it, perhaps by lowering lease times on DHCP when they know they're going to reboot, lowering the outage time. Also, it might be an option to have a optional learning-only mode in SAVI for the first X minutes after startup, where packets are not dropped but instead allowed. When the X minutes have passed (perhaps X could be deducted by seeing lease times in DHCP), then we go into "secure mode" and start dropping packets according to the states we've learned. Right now I'm inclined to think that there is no really good way to handle this, and any handling of it should be optional for vendors to implement because of the added complexity. -- Mikael Abrahamsson email: swmike@swm.pp.se From marcelo@it.uc3m.es Mon Mar 8 23:21:34 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B1F3A6894 for ; Mon, 8 Mar 2010 23:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jzzphaVZzKY for ; Mon, 8 Mar 2010 23:21:32 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 2A2BF3A6897 for ; Mon, 8 Mar 2010 23:21:31 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (138.30.18.95.dynamic.jazztel.es [95.18.30.138]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 1A149BA6A7E; Tue, 9 Mar 2010 08:21:34 +0100 (CET) Message-ID: <4B95F6EA.8080800@it.uc3m.es> Date: Tue, 09 Mar 2010 08:21:14 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Mikael Abrahamsson References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 07:21:34 -0000 El 09/03/10 7:54, Mikael Abrahamsson escribió: > On Mon, 8 Mar 2010, marcelo bagnulo braun wrote: > >> If SAVI switches reboots imply that the communication will be >> interrupted unless all switches are upgraded to support SAVI, then if >> you only replace one switch, then you are breaking your netwokr. So >> in order to work properly, you need to upgrade all the network. So, >> this is not incrementally deployable > > Hi Marcelo. > > I very quickly read draft-bagnulo-savi-analysis-02.txt as you > recommended, and as far as I can see, everything in it is correct. I > guess we just see differently on the implications on network > maintenance and stability. > > I come from an ISP background and have that point of view, I don't > trust my customers and they have no certificate or other to verify > that I am who I am, and my customers definitely can't trust each > other. Therefore I try to make sure that traffic between customers > does a route hop thru my equipment, so basically there is no L2 > connectivity between customers. I also need to know what customer/port > has what IP at any given time, which for me means I have to use > stateful DHCP so I can store this binding. SLAAC is just not > acceptable in this scenario (because of TCAM limitations in my > equipment I don't want my equipment connected to a customer /64 > without limitations on IPs used). right, i wasn't suggesting we drop dhcp based savi, i do agree dhcp based savi is needed. The issues that i am raising are related to specifically what shall we do when a dhcp savi device receives a packet for which there is no binding. It can either drop the packet or trigger the binding creation procedure. I am pointing out that simply discarding the packet would result in reduced robustness of the overall network > > We today have this problem with the bindings, especially if the > customer has a switch in their apartment. If we reboot the basement > switch, the computers won't know that via link-down, and the DHCPv4/IP > bindings are lost. I am not sure i understnad this example what dhcp bindings are lost? the host still have their addresses right? > I guess most people would solve this using "repair connection" in > their Windows machine, or just plain restart it, upon which everything > starts again. If the customer is running their machine unattended then > it'll be unreachable until a DHCP request/discover is seen again. > > So I do think we can agree that partially deploying SAVI framework on > just some devices has its disadvantages, but I still think they can be > managed by the network staff knowing about this downside and working > around it, perhaps by lowering lease times on DHCP when they know > they're going to reboot, lowering the outage time. sure, that could work, as long as the reboot is planned. So one possibility as you said is to have a ordered reboot option in dhcp savi, that reduces the times in the dhcp lease, in order to make sure that the hosts will redo their dhcp lease once they boot again. The issue that i see here is that many siwtches mostly are rebooted by power them down, which does not allows for an ordered shut down > Also, it might be an option to have a optional learning-only mode in > SAVI for the first X minutes after startup, where packets are not > dropped but instead allowed. When the X minutes have passed (perhaps X > could be deducted by seeing lease times in DHCP), then we go into > "secure mode" and start dropping packets according to the states we've > learned. > well, the other option would be to trigger the learning procedure when a data packet for which no binding exists is recieved. That bsaically requires the dhcp savi device to issue a dhcp confirm message to the dhcp server in order to veryfy that a binding exists, for instance. That would solve all the problems for all topologies afaict. > Right now I'm inclined to think that there is no really good way to > handle this, see above regards, marcelo > and any handling of it should be optional for vendors to implement > because of the added complexity. > From junbi@cernet.edu.cn Mon Mar 8 23:42:34 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385593A6878 for ; Mon, 8 Mar 2010 23:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bllE4zyk9oGt for ; Mon, 8 Mar 2010 23:42:33 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 953543A67AE for ; Mon, 8 Mar 2010 23:42:29 -0800 (PST) Received: from junbiVAIO([59.66.24.139]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54b9667e7; Tue, 09 Mar 2010 15:42:31 +0800 Message-ID: <796760F1E00D46888F6E71E6F4132F06@junbiVAIO> From: "Bi Jun" To: "marcelo bagnulo braun" , "Mikael Abrahamsson" References: <4B94C376.40502@it.uc3m.es><4B94D28C.3000205@it.uc3m.es><10F327EA71564228A016D2641E12121A@junbiVAIO><4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> In-Reply-To: <4B95F6EA.8080800@it.uc3m.es> Date: Tue, 9 Mar 2010 15:42:05 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: wpRFuoXB Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 07:42:34 -0000 Thank you very much for the discussion. Did you read Guang Yao's message on savi-dhcp-01? I also prefer to trying to avoid using data-triggered actions (the vendors really complained the CPU cost for those actions), if savi-device has to resolve this issue. Best Regards, Jun Bi -------------------------------------------------- From: "Guang Yao" Sent: Tuesday, March 09, 2010 2:19 PM To: Subject: Re: [savi] call for comments: savi-dhcp-01 > IMO, if a savi device wants to restore state of not directly attached > clients from reboot, which means no control packet can be used to restore > binding, only two mechanisms can be chosen: > 1. Use data packet to trigger binding set up. Then the additional overhead > is mainly cpu cost. The cost is not only resulted from the added > complexity, > but also a possible data packet burst that may cause denial of service on > cpu, and the complexity logic of filtering a single packet(you can't > filter > any packet until assured by server or probe in slaac scenario). > 2. Store state into non violate storage manually or regularly. Then the > additional overhead is mainly storage cost. > > If I can't avoid choosing one from them, I'd rather choose the second > mechanism, as suggested by Mikael Abrahamsson and Eric Levy-Abegnoli. In > general, storage chip is cheaper than processing chip. -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Tuesday, March 09, 2010 3:21 PM To: "Mikael Abrahamsson" Cc: Subject: Re: [savi] call for comments: savi-dhcp-01 > El 09/03/10 7:54, Mikael Abrahamsson escribió: >> On Mon, 8 Mar 2010, marcelo bagnulo braun wrote: >> >>> If SAVI switches reboots imply that the communication will be >>> interrupted unless all switches are upgraded to support SAVI, then if >>> you only replace one switch, then you are breaking your netwokr. So in >>> order to work properly, you need to upgrade all the network. So, this is >>> not incrementally deployable >> >> Hi Marcelo. >> >> I very quickly read draft-bagnulo-savi-analysis-02.txt as you >> recommended, and as far as I can see, everything in it is correct. I >> guess we just see differently on the implications on network maintenance >> and stability. >> >> I come from an ISP background and have that point of view, I don't trust >> my customers and they have no certificate or other to verify that I am >> who I am, and my customers definitely can't trust each other. Therefore I >> try to make sure that traffic between customers does a route hop thru my >> equipment, so basically there is no L2 connectivity between customers. I >> also need to know what customer/port has what IP at any given time, which >> for me means I have to use stateful DHCP so I can store this binding. >> SLAAC is just not acceptable in this scenario (because of TCAM >> limitations in my equipment I don't want my equipment connected to a >> customer /64 without limitations on IPs used). > > right, i wasn't suggesting we drop dhcp based savi, i do agree dhcp based > savi is needed. The issues that i am raising are related to specifically > what shall we do when a dhcp savi device receives a packet for which there > is no binding. > It can either drop the packet or trigger the binding creation procedure. I > am pointing out that simply discarding the packet would result in reduced > robustness of the overall network >> >> We today have this problem with the bindings, especially if the customer >> has a switch in their apartment. If we reboot the basement switch, the >> computers won't know that via link-down, and the DHCPv4/IP bindings are >> lost. > I am not sure i understnad this example what dhcp bindings are lost? the > host still have their addresses right? > >> I guess most people would solve this using "repair connection" in their >> Windows machine, or just plain restart it, upon which everything starts >> again. If the customer is running their machine unattended then it'll be >> unreachable until a DHCP request/discover is seen again. >> >> So I do think we can agree that partially deploying SAVI framework on >> just some devices has its disadvantages, but I still think they can be >> managed by the network staff knowing about this downside and working >> around it, perhaps by lowering lease times on DHCP when they know they're >> going to reboot, lowering the outage time. > sure, that could work, as long as the reboot is planned. > So one possibility as you said is to have a ordered reboot option in dhcp > savi, that reduces the times in the dhcp lease, in order to make sure that > the hosts will redo their dhcp lease once they boot again. The issue that > i see here is that many siwtches mostly are rebooted by power them down, > which does not allows for an ordered shut down > > >> Also, it might be an option to have a optional learning-only mode in SAVI >> for the first X minutes after startup, where packets are not dropped but >> instead allowed. When the X minutes have passed (perhaps X could be >> deducted by seeing lease times in DHCP), then we go into "secure mode" >> and start dropping packets according to the states we've learned. >> > > well, the other option would be to trigger the learning procedure when a > data packet for which no binding exists is recieved. That bsaically > requires the dhcp savi device to issue a dhcp confirm message to the dhcp > server in order to veryfy that a binding exists, for instance. That would > solve all the problems for all topologies afaict. >> Right now I'm inclined to think that there is no really good way to >> handle this, > > see above > > regards, marcelo > > >> and any handling of it should be optional for vendors to implement >> because of the added complexity. >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Mon Mar 8 23:43:30 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18FC3A67DA for ; Mon, 8 Mar 2010 23:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhRpuubAAyZK for ; Mon, 8 Mar 2010 23:43:29 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 9FCE53A67AE for ; Mon, 8 Mar 2010 23:43:28 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (138.30.18.95.dynamic.jazztel.es [95.18.30.138]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 2F619BA6A23; Tue, 9 Mar 2010 08:43:31 +0100 (CET) Message-ID: <4B95FC24.7050709@it.uc3m.es> Date: Tue, 09 Mar 2010 08:43:32 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Jun Bi References: <4B94C376.40502@it.uc3m.es><4B94D28C.3000205@it.uc3m.es><10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <236523D9F9984C198687B319D96A3C70@junbiVAIO> In-Reply-To: <236523D9F9984C198687B319D96A3C70@junbiVAIO> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 07:43:31 -0000 El 08/03/10 16:11, Jun Bi escribi¨®: > Hi Marcelo, > > The storing states before savi device rebooting > is adopted at the latest version of savi-dhcp-01 to be submitted to ietf, > to make it reliable to handle your example. > have you check with people implementing switches whether using non volatile memory for storing dynamic information, that requires periodic writing is doable? Besides, you would still have problems, (different ones) if you use non volatile memory, especially cause you may end up filtering based on stalled state consider the follwoing case: Consider the following case: +------+ +--------+ +---------------+ +------|SAVI I|-------------|SWITCH I|-------|rest of the net| | +------+ +--------+ +---------------+ | | | +---------+ | +--------+ |SWITCHIII| | | SAVI II| +---------+ | +--------+ | | +----------+ | +------+ +---|SWITCH II |-----+ |Host 1| +----------+ +------+ Consider the case where we have SAVI I and SAVI II storing the SAVI state in non volatile memory. Suppose that Host I connects to the network and gets IP address IP1 from the DHCP server. Suppose that now the power of SAVI I goes down and stays down for a few hours. Suppose that Host I leaves the network and Host II attaches to the network in SWITCH II as depicted below. The spanning tree goes SWITCH I-SAVI II-SWITCH II. +------+ +--------+ +---------------+ +------|SAVI I|-------------|SWITCH I|-------|rest of the net| | +------+ +--------+ +---------------+ | | | +---------+ | +--------+ |SWITCHIII| | | SAVI II| +---------+ | +--------+ | +----------+ | +---|SWITCH II |-----+ +----------+ | +-------+ |Host II| +-------+ Suppose that SAVI I boots and now the spanning tree changes and goes SWITCH I- SAVI I- SWITCH II. Now packets of Host II will be forwarded through SAVI I. But Host II has IP1 as IP address, but SAVI I still holds the state referring to Host I through the port through which SWITCH III is connected. The result is that SAVI I will drop the packets coming from Host II. > I remember Eirc had a similar suggestion. > Thanks to Mikael and Eric. > > Best Regards, > Jun Bi > > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Monday, March 08, 2010 10:03 PM > To: "Bi Jun" > Cc: > Subject: Re: [savi] call for comments: savi-dhcp-01 > >> El 08/03/10 12:24, Bi Jun escribi¨®: >>> >>> >>> -------------------------------------------------- >>> From: "marcelo bagnulo braun" >>> Sent: Monday, March 08, 2010 6:33 PM >>> To: "Bi Jun" >>> Cc: >>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>> >>>> below... >>>> >>>> El 08/03/10 11:16, Bi Jun escribi¨®: >>>>> Hi Marcelo, >>>>> >>>>> You actually bring two questions. >>>>> >>>>> >>>>> One question is on deployment: can we deploy a solution on legacy >>>>> switch. >>>>> Another is on the user's scenario: do we need to support the case >>>>> when >>>>> latency switch is involved. >>>>> >>>>> For question 1, my point is: if the solution is very simple and just >>>>> need >>>>> to upgrade a software version, doesn't need to change hardware, then >>>>> it will be yes. >>>> In any case, this approahc would impose an upgrade of most of the >>>> switches in the network. >>>> I argue that this may be feasible in some scenarios and not in others. >>>> A couple of examples. >>> >>> Actually, the savi-switches are independent. Deployment on one switch >>> doesn't rely on >>> the deployment of other switches. So you don't need to change most >>> switches, you upgrade one, then get one benefit, it's incremental >>> deployment. >>> >>> >> >> not really >> >> If SAVI switches reboots imply that the communication will be >> interrupted unless all switches are upgraded to support SAVI, then if >> you only replace one switch, then you are breaking your netwokr. So in >> order to work properly, you need to upgrade all the network. >> So, this is not incrementally deployable >>> >>>> >>>> Suppose you are providing serv ice for a cmapus network and everybody >>>> has these small hub switches in their offices, and that is >>>> perfeclty ok >>>> with the security policy (this is the case of my university for >>>> instance) >>>> We have a variety of small hubs, some of them are fairly old. >>>> Moreover, >>>> some people are running virtual machines in their computers, do the >>>> hubs >>>> is actually virtual. In this scenario, which i would argue is fairly >>>> common, it is not trvial to update all the switches. >>> >>> Please note that the savi-dhcp-01 could handle the hub connection in >>> normal cases. >> what do you mean normal and special cases? >> I am talking about a case where the savi switch reboots, there is >> nothing special about it. My CPE at home is rebooted several times a >> week, while my laptop none. >> >>> You are actually taking about how to handle special cases. >>> >>> If you are the administrator (like us), if you enforce SAVI, then you >>> can ask >>> the users directly attached hosts to savi-switch. >> >> sure, but i guess we want to define a solution that can be used by a >> wider client base that can include other needs, right? >> >>> If some users still want the flexibility with a hub, then in the MOST >>> cases there will be no problem (the reboot >>> of savi-switch in your example will be very low frequent event), >> >> what do you mean that a reboot of a device is not a frequent event? >> What is being argued here is that after a reboot in a switch all hosts >> will be disconnected from the network. What is the reliability of the >> resulting network? >> >>> then if you found the network has the problem, you just need to reboot >>> your hub, you want the flexibility then you pay it by rebooting your >>> own hub. >> No, if we want reliability, we design a protocol properly, in order to >> make reliable. >> I find hardly aceptbale to say that if you want reliability, you must >> manually reboot all the hubs in my office in random moments. >> >> what about if you are using a remote sessiona dn you are not physically >> on your office to reboot it? >> >> >> >>> We didn't see any problem >>> in our real deployment. It's the user's normal behavior in today's >>> internet, if you meet a problem, you plug off you cable and plug in >>> again. >>> >> I guess we simply disagree here. >> I believe in the end to end principle and all the other deisgn >> architectural principles that aim to provide reliable end to end >> communications. "manually reboot you hub" is not the way i think we >> should design a protocol, sorry. >> >>> Remember the "end-end argument" of system design: "If the application >>> can do it, don¡¯t do it at a lower layer >> >> ???? >> >> the end to end principle has a simple corolary that is the fate sharing >> corolary, which reccomend not to include state in the network that is >> require for the end to end cmmunication, so that the fate of the end >> host does not depends on the date of the soft state stored in the >> network. >> >> Following an approach where there is some state (i.e. the SAVI binding) >> that is stored in the network and that cannot be recovered automatically >> and requires manual intervention, clearly breaks the fate sharing >> principle and hence the end to end argument. >> >> >>> -- anyway the application knows the best what it need", that's the >>> successful philosophy of Internet. So don't make the system too >>> complex to handle special cases. That's why I said we need to evaluate >>> the cost and benefit. >>> >>> BTW, I agree that for high-end switch, we can ask them to do more with >>> a bigger solution to handle all special cases (even the special cases >>> are low frequency events), that's why I said maybe we might need two >>> RFCs (one simple/low cost solution for most cases, another ideal but >>> high cost solution for all cases). >>> >> again, i disagree, i don't think the ietf shoudl have a stnadrad track >> rfc that relies on users manually rebooting their hubs in order to >> recover >> >>>> >>>> A second case may be the one of the dsl forum. their goal is to run >>>> savi >>>> in the CPE. Now, many ISPs have no problem allowing the user to >>>> connect >>>> a switch to their CPE. The thing here is that the ISP wants to deploy >>>> SAVI, but it can certainly not mandate their cusotmers to update their >>>> home switches. >>> >>> >>> Currently, DSL is a separate scope. >>> >> >> how come? >> i understood the the dsl forum was planing to use the SAVI specs >>> >>> >>>> >>>> So, i still don't think we can simply dismiss this scenario >>>> >>>>> The current savi-dhcp-01 is very easy to be implemented by >>>>> software-only (it has been >>>>> proved by several switch vendors by real products, which I will >>>>> report >>>>> at IETF77), Then it will be very easy for users to deploy it on his >>>>> current (legacy) switch, >>>>> where CERNET is deploying it. Moreover, if the legacy switch is too >>>>> old to upgrade >>>>> the software, because the life time of access switch hardware is >>>>> about >>>>> 3 years, then >>>>> when the user purchase a new switch, the switch will be upgraded. >>>>> >>>> >>>> well, where i come from we don't upgrade office hubs every 3 years, i >>>> can tell you that for sure. >>>> >>>>> If the answer of question 1 is yes, then the in the most cases, then >>>>> scenario of question 2 is less important. So my point is that we need >>>>> to evaluate if the cost (brought to switch) matches the benefit. My >>>>> proposal is to have one RFC for one scenario that we have consensus >>>> i am not sure what do you mean we have consensus. I agree we need to >>>> support this scenario, but we certainly do not have consensus on >>>> having >>>> a solution that only supports this particular scenario >>>> >>>> second, i am so far only talking about the dhcp based savi, in the >>>> case >>>> of ND based savi the issues are far more severa and the soltion is >>>> likely to support any scenario in any case. >>> >>> I really doubt on a big solution trying to resolve any problems in any >>> scenarios, sometimes might means impossible in engineering/practice >>> (too complex to be implemented at least in most devices). >>> >> i eprsonally doubt of a soluton that significantly reduces the >> reliability of the netowkr architecture that we have >> >>> >>> >>>> >>>> So, i don't agree with your proposed way froward >>>> >>>>> (e.g. the host directly attached to the savi switch), then if it is >>>>> really needed, having another RFC for more complicated cases (maybe >>>>> because the cost to switch, not many vendors really implement in the >>>>> real world in recent years). Certainly, the scenarios will be >>>>> presented in savi-framework. >>>>> >>>>> By the way, the probe in my previous email meant that the savi-device >>>>> send out packets (dad-ns, confirm, etc) to host/or might to dhcp >>>>> server, triggered by data packets or timers. >>>> mm, so you mean that if the SAVI device receives a data packet for >>>> which >>>> it does not have a binding, it sends the DHCP CONFIRM to the dhcp >>>> server >>>> to see if the server validates it, it that what you meant? >>>> >>>> that seems reasonable to me >>>> >>> >>> >>> >>> Yes, we can have some way to handle it. In my last PPT in IETF76, I >>> presented lots >>> of similar solutions. >>> But I still think it's not good to bring too much cost to the >>> savi-device which are low-end access switch in most cases, just for >>> some very special event (which can be simply fixed by users). >>> >>> >> >> but, what is the cost of a solution that is non relibale? how much is >> the cost of dowtime of the internet access? how much is the cost of >> having to update or upgrade all the legacy equipment? >> >> I mean, it makes no sense to say that one solution is expensive, we need >> to compare the different costs. >> IMHO, high reliability and backward compatibility are much better >> options. >> >> Regards, marcelo >> >>> >>> >>> >>> >>>> >>>>> It was used to handle the case when host moving (and other cases) >>>>> under legacy switch in my last presentation at IETF, it seemed that >>>>> people think triggering those probes make the switch too complex >>>>> (Joe, >>>>> etc.) and the vendors also don't like the data-packet triggered >>>>> actions based on the feedbacks when we work with vendors in the past >>>>> months (H3C, ZTE, Ruijie, DC, etc..). >>>>> >>>> i can see that, but the question is what the overall robustness and >>>> deployability of the alternative solution. that is imho what we >>>> need to >>>> duscuss and understand. >>>> >>>> Regards, marcelo >>>> >>>> >>>>> thanks, >>>>> Jun Bi >>>>> -------------------------------------------------- >>>>> From: "marcelo bagnulo braun" >>>>> Sent: Monday, March 08, 2010 5:29 PM >>>>> To: "Jun Bi" >>>>> Cc: >>>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>>> >>>>>> Hi Jun, >>>>>> >>>>>> Thanks for the answer. >>>>>> >>>>>> So, your proposal is to simply rule out this scenario and make dhcp >>>>>> based savi to require that all hosts are directly connected tot he >>>>>> SAVI >>>>>> device? >>>>>> >>>>>> I think this would significantly limit the solution >>>>>> applicabillity and >>>>>> the chances of its deployment (it basically will require to upgrade >>>>>> most >>>>>> of the switches in the network in order to run SAVI). >>>>>> >>>>>> I don't believe this is a good approach. I think we need to define a >>>>>> SAVI solution that allows for incremental deployment in the >>>>>> network, if >>>>>> we want this to happen. >>>>>> >>>>>> So commenting on you reply below... >>>>>> >>>>>> El 08/03/10 10:14, Jun Bi escribi¨®: >>>>>>> Hi Marcelo, >>>>>>> >>>>>>> During my presentation at IETF76, some people commented that >>>>>>> it took much effort for SAVI-device to send probe packets to >>>>>>> handle the special case. >>>>>> I don't recall that disucssion, probably i missed that one >>>>>> >>>>>> So, could you explain to me how would you deal with that case by >>>>>> probing? >>>>>> >>>>> >>>>> Please read my ppt in IETF76 meeting. >>>>> >>>>> >>>>> >>>>>> I mean, it is not obvious to me how the SAVI device knows who to >>>>>> probe, >>>>>> since it has lost its state >>>>>> >>>>>>> Then in this dhcp-01 version, >>>>>>> we make the solution for the most recommended use case: the host >>>>>>> directly attached to savi device. >>>>>> I don't think we cna limit ourselves to this specific case, as i >>>>>> mentioned before >>>>>>> We hope we could reach >>>>>>> consensus on this part then we could go further to discuss the >>>>>>> situation when legacy switch involved >>>>>> not sure what do you mean here... >>>>>> I agree we need to discuss this and get consensus to move forward. >>>>>> >>>>>> >>>>>>> (does the cost matches the benefit?). >>>>>>> It also needs the savi-framework to state the user's scenarios. >>>>>>> >>>>>> I also agree this should be part of the framework document. >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>>> thanks, >>>>>>> Jun Bi >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -------------------------------------------------- >>>>>>>> From: "marcelo bagnulo braun" >>>>>>>> Sent: Monday, March 08, 2010 4:33 PM >>>>>>>> To: >>>>>>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I have a question that it was not apparent to me from the draft >>>>>>>>> >>>>>>>>> Suppose the following configuration: >>>>>>>>> >>>>>>>>> +------+ +-------------+ +-----------+ +---------------+ >>>>>>>>> | Host |------|Legacy device|-------|SAVI device|-------|rest of >>>>>>>>> the >>>>>>>>> net| >>>>>>>>> +------+ +-------------+ +-----------+ +---------------+ >>>>>>>>> >>>>>>>>> Suppose the host connects, does the DHCP exchange and the SAVI >>>>>>>>> device creates the binding. >>>>>>>>> Suppose now that the SAVI device loose the state (e.g. it >>>>>>>>> reboots or >>>>>>>>> crashes) >>>>>>>>> >>>>>>>>> What happens next? Is the SAVI device able to recover the binding >>>>>>>>> information? >>>>>>>>> >>>>>>>>> I guess some of the info is stored in the dhcp server, but >>>>>>>>> probably >>>>>>>>> not all of it (i.e. >>>>>>>>> the lower layer anchor info may not be present) >>>>>>>>> >>>>>>>>> Regards, marcelo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> El 03/03/10 13:18, Bi Jun escribi¨®: >>>>>>>>>> Dear WG members, >>>>>>>>>> This is the 01 version of savi-dhcp solution. >>>>>>>>>> Comments please. >>>>>>>>>> Thank you very much! >>>>>>>>>> Jun Bi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> savi mailing list >>>>>>>>>> savi@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> savi mailing list >>>>>>>>> savi@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > From swmike@swm.pp.se Mon Mar 8 23:44:08 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8831E3A67DA for ; Mon, 8 Mar 2010 23:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFEkPcABTte2 for ; Mon, 8 Mar 2010 23:44:07 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id 99B263A67AE for ; Mon, 8 Mar 2010 23:44:07 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B10B9A0; Tue, 9 Mar 2010 08:44:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AEC739F; Tue, 9 Mar 2010 08:44:08 +0100 (CET) Date: Tue, 9 Mar 2010 08:44:08 +0100 (CET) From: Mikael Abrahamsson To: marcelo bagnulo braun In-Reply-To: <4B95F6EA.8080800@it.uc3m.es> Message-ID: References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 07:44:08 -0000 On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: > right, i wasn't suggesting we drop dhcp based savi, i do agree dhcp based > savi is needed. The issues that i am raising are related to specifically what > shall we do when a dhcp savi device receives a packet for which there is no > binding. > It can either drop the packet or trigger the binding creation procedure. I am > pointing out that simply discarding the packet would result in reduced > robustness of the overall network For me it's absolutely essential that packets that do not have DHCP initated bindings are dropped, so this needs to be configurable. But yes, having the switch punt (for example) 1 pps of packets (per port) for which there are no SAVI bindings and issue a DHCP confirm request for each of these might very well be a possibility. > I am not sure i understnad this example what dhcp bindings are lost? the host > still have their addresses right? Yes, but the SAVI device has lost its SAVI security bindings during the reboot. > well, the other option would be to trigger the learning procedure when a data > packet for which no binding exists is recieved. That bsaically requires the > dhcp savi device to issue a dhcp confirm message to the dhcp server in order > to veryfy that a binding exists, for instance. That would solve all the > problems for all topologies afaict. Yes, that is also a possibility (and sounds like a good idea), but it needs to be heavily ratelimited to protect against DoS attacks. I also think it should be an optional feature, not a must. -- Mikael Abrahamsson email: swmike@swm.pp.se From yaoa02@mails.tsinghua.edu.cn Mon Mar 8 23:48:00 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637473A6830 for ; Mon, 8 Mar 2010 23:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NM+BTruiD+wa for ; Mon, 8 Mar 2010 23:47:59 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 458413A67AE for ; Mon, 8 Mar 2010 23:47:59 -0800 (PST) Received: from tu132201.ip.tsinghua.edu.cn ([166.111.132.201] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NouAV-0003hK-PE for savi@ietf.org; Tue, 09 Mar 2010 15:47:55 +0800 From: "Guang Yao" To: References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> In-Reply-To: <4B95F6EA.8080800@it.uc3m.es> Date: Tue, 9 Mar 2010 15:47:47 +0800 Message-ID: <006801cabf5c$cfc633d0$6f529b70$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq/WO7s2Nf3OBZhSFOumZCeqYB+GgAAJGBA Content-Language: zh-cn Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 07:48:00 -0000 > > right, i wasn't suggesting we drop dhcp based savi, i do agree dhcp > based savi is needed. The issues that i am raising are related to > specifically what shall we do when a dhcp savi device receives a packet > for which there is no binding. > It can either drop the packet or trigger the binding creation procedure. > I am pointing out that simply discarding the packet would result in > reduced robustness of the overall network [Guang Yao] There is no perfect solution. Profit goes with risk and cost. Here is a trade-off: 1. Discard the packet: low cost but may result in false positive 2. Trigger binding creation: robust but high cost(as far as I know, no product is designed like this, thus it is hard to estimate the real performance) I don't think we do have to make the final choice. Clients, ISPs, and vendors should(or must) have the right to choose themselves. They are supposed to make different choices. At least for vendors and ISPs, 1 is better. > > > well, the other option would be to trigger the learning procedure when a > data packet for which no binding exists is recieved. That bsaically > requires the dhcp savi device to issue a dhcp confirm message to the > dhcp server in order to veryfy that a binding exists, for instance. That > would solve all the problems for all topologies afaict. > > s [Guang Yao] Using confirm actually has a problem here: the semanteme of confirm is not check whether the address has been assigned, but check whether the address can be used on the link. This means any host can confirm the address of another node. BR, Guang From marcelo@it.uc3m.es Mon Mar 8 23:51:02 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028E23A6830 for ; Mon, 8 Mar 2010 23:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE-kKlGYP+zQ for ; Mon, 8 Mar 2010 23:51:01 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 1F20E3A67DA for ; Mon, 8 Mar 2010 23:51:00 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (138.30.18.95.dynamic.jazztel.es [95.18.30.138]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 2043C6C327A for ; Tue, 9 Mar 2010 08:51:03 +0100 (CET) Message-ID: <4B95FDE7.8070100@it.uc3m.es> Date: Tue, 09 Mar 2010 08:51:03 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Subject: [savi] dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 07:51:02 -0000 Hi, I have another question about dhcp save How do you handle the following situation? In the case SAVI is being deployed in a switched Ethernet network, topology changes may result in a SAVI device receiving packets from a legitimate user for which the SAVI device does not have a binding for. Consider the following example: +------+ +--------+ +---------------+ |SAVI I|-------------|SWITCH I|-------|rest of the net| +------+ +--------+ +---------------+ | | | +--------+ | | SAVI II| | +--------+ | +----------+ | +---|SWITCH II |-----+ +----------+ | +-----+ | Host| +-----+ The DHCP server is located in the part called rest of the network. Suppose that after bootstrapping all the elements are working properly and the spanning tree is rooted in the router and it includes one branch that goes SWITCH I-SAVI I- SWITCH II and another branch that goes SWITCH I-SAVI II. Suppose that the Host boots at this moment and perfomrs the DHCP sxchange. The message is propagated through the spanning tree and it received by SAVI I but not by SAVI II. Same happens with the reply. SAVI I creates the binding. Suppose that SAVI I fails and the spanning tree reconverges to SWITCH I- SAVI II- SWITCH II. Now data packets coming from the Host will be coursed through SAVI II which does not have binding state and will drop the packets. Regards, marcelo From marcelo@it.uc3m.es Tue Mar 9 00:52:06 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A709A3A68EB for ; Tue, 9 Mar 2010 00:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNLkf2TV4ceq for ; Tue, 9 Mar 2010 00:52:05 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7A48F3A68E0 for ; Tue, 9 Mar 2010 00:52:05 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (138.30.18.95.dynamic.jazztel.es [95.18.30.138]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 248216C33A9; Tue, 9 Mar 2010 09:52:07 +0100 (CET) Message-ID: <4B960C36.8080306@it.uc3m.es> Date: Tue, 09 Mar 2010 09:52:06 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Mikael Abrahamsson References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 08:52:06 -0000 El 09/03/10 8:44, Mikael Abrahamsson escribió: > On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: > >> right, i wasn't suggesting we drop dhcp based savi, i do agree dhcp >> based savi is needed. The issues that i am raising are related to >> specifically what shall we do when a dhcp savi device receives a >> packet for which there is no binding. >> It can either drop the packet or trigger the binding creation >> procedure. I am pointing out that simply discarding the packet would >> result in reduced robustness of the overall network > > For me it's absolutely essential that packets that do not have DHCP > initated bindings are dropped, i fully agree with that. I wasn't suggesting that we should let unverified packet through. The question is what to do with packet for which we don't have a binding. One option is to drop them till the end of times (or until the host reboots). To me this would significantly reduce the reliability of the network. The other option is to trigger the binding creation procedure. We may even drop the particular packet that trigger the procedure, but at least, folowing packet will not be dropped if they came from a legitimate user. This basicaly implies for the SAVI device to issue a dhcp message > so this needs to be configurable. But yes, having the switch punt (for > example) 1 pps of packets (per port) for which there are no SAVI > bindings and issue a DHCP confirm request for each of these might very > well be a possibility. > right, this raises another interesting issue that is about rate limiting. If we do this, both dhcp control packets and data packets may require processing by the SAVI device, so both of them need to be rate limited. So, normally, the amount of data packets that require processing would be very low, since, as people has alreayd been stating, the usual case is that we see a dhcp message first. So only a few data packet require processing, so we can severly rate limit it. So, i agree with this Please note that the impact of not processing a data packet is simply loose that particular packet, but we always have the oportunity to process the next one from the sam source. >> I am not sure i understnad this example what dhcp bindings are lost? >> the host still have their addresses right? > > Yes, but the SAVI device has lost its SAVI security bindings during > the reboot. > right, this is what i am presenting as one argument of the reduced reliability of the network if we simply drop the data packets for which the savi device does not have a binding for >> well, the other option would be to trigger the learning procedure >> when a data packet for which no binding exists is recieved. That >> bsaically requires the dhcp savi device to issue a dhcp confirm >> message to the dhcp server in order to veryfy that a binding exists, >> for instance. That would solve all the problems for all topologies >> afaict. > > Yes, that is also a possibility (and sounds like a good idea), but it > needs to be heavily ratelimited to protect against DoS attacks. agree > I also think it should be an optional feature, not a must. > but this is what we qualify as a must in the ietf terminology. If you don't do this, the network breaks in different ways, right? Regards, marcelo From junbi@cernet.edu.cn Tue Mar 9 00:52:43 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702F23A68D2 for ; Tue, 9 Mar 2010 00:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.172 X-Spam-Level: X-Spam-Status: No, score=0.172 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlnigDBOlNyw for ; Tue, 9 Mar 2010 00:52:42 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 5A9BC3A68E0 for ; Tue, 9 Mar 2010 00:52:40 -0800 (PST) Received: from junbiVAIO([59.66.24.139]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm1b4b967859; Tue, 09 Mar 2010 16:52:41 +0800 Message-ID: From: "Bi Jun" To: "Mikael Abrahamsson" , "marcelo bagnulo braun" References: <4B94C376.40502@it.uc3m.es><4B94D28C.3000205@it.uc3m.es><10F327EA71564228A016D2641E12121A@junbiVAIO><4B95039F.7030908@it.uc3m.es><4B95F6EA.8080800@it.uc3m.es> In-Reply-To: Date: Tue, 9 Mar 2010 16:52:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: weLLvoXB Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 08:52:43 -0000 -------------------------------------------------- From: "Mikael Abrahamsson" Sent: Tuesday, March 09, 2010 3:44 PM To: "marcelo bagnulo braun" Cc: Subject: Re: [savi] call for comments: savi-dhcp-01 > On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: > >> right, i wasn't suggesting we drop dhcp based savi, i do agree dhcp based >> savi is needed. The issues that i am raising are related to specifically >> what shall we do when a dhcp savi device receives a packet for which >> there is no binding. >> It can either drop the packet or trigger the binding creation procedure. >> I am pointing out that simply discarding the packet would result in >> reduced robustness of the overall network > > For me it's absolutely essential that packets that do not have DHCP > initated bindings are dropped, so this needs to be configurable. But yes, > having the switch punt (for example) 1 pps of packets (per port) for which > there are no SAVI bindings and issue a DHCP confirm request for each of > these might very well be a possibility. > >> I am not sure i understnad this example what dhcp bindings are lost? the >> host still have their addresses right? > > Yes, but the SAVI device has lost its SAVI security bindings during the > reboot. > >> well, the other option would be to trigger the learning procedure when a >> data packet for which no binding exists is recieved. That bsaically >> requires the dhcp savi device to issue a dhcp confirm message to the dhcp >> server in order to veryfy that a binding exists, for instance. That would >> solve all the problems for all topologies afaict. > > Yes, that is also a possibility (and sounds like a good idea), but it > needs to be heavily ratelimited to protect against DoS attacks. I also > think it should be an optional feature, not a must. Hi Mikael and Marcelo, If consider it as an optional feature (data triggered actions) not a must, I think it's OK for me. Thanks, Jun Bi > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Tue Mar 9 00:53:01 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959963A68F9 for ; Tue, 9 Mar 2010 00:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1XrtSiuZtQV for ; Tue, 9 Mar 2010 00:53:00 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 047F23A68EF for ; Tue, 9 Mar 2010 00:53:00 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (138.30.18.95.dynamic.jazztel.es [95.18.30.138]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 88C55BA65DB; Tue, 9 Mar 2010 09:53:02 +0100 (CET) Message-ID: <4B960C6D.6070905@it.uc3m.es> Date: Tue, 09 Mar 2010 09:53:01 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Bi Jun References: <4B94C376.40502@it.uc3m.es><4B94D28C.3000205@it.uc3m.es><10F327EA71564228A016D2641E12121A@junbiVAIO><4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <796760F1E00D46888F6E71E6F4132F06@junbiVAIO> In-Reply-To: <796760F1E00D46888F6E71E6F4132F06@junbiVAIO> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: savi@ietf.org, Mikael Abrahamsson Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 08:53:01 -0000 El 09/03/10 8:42, Bi Jun escribió: > Thank you very much for the discussion. > > Did you read Guang Yao's message on savi-dhcp-01? yes, please read my reply to Mikael, that addresses the same issues Regards, marcelo > > I also prefer to trying to avoid using data-triggered actions (the > vendors really complained the CPU cost for those actions), if > savi-device has to resolve this issue. > > Best Regards, > Jun Bi > > -------------------------------------------------- > From: "Guang Yao" > Sent: Tuesday, March 09, 2010 2:19 PM > To: > Subject: Re: [savi] call for comments: savi-dhcp-01 > >> IMO, if a savi device wants to restore state of not directly attached >> clients from reboot, which means no control packet can be used to >> restore >> binding, only two mechanisms can be chosen: >> 1. Use data packet to trigger binding set up. Then the additional >> overhead >> is mainly cpu cost. The cost is not only resulted from the added >> complexity, >> but also a possible data packet burst that may cause denial of >> service on >> cpu, and the complexity logic of filtering a single packet(you can't >> filter >> any packet until assured by server or probe in slaac scenario). >> 2. Store state into non violate storage manually or regularly. Then the >> additional overhead is mainly storage cost. >> >> If I can't avoid choosing one from them, I'd rather choose the second >> mechanism, as suggested by Mikael Abrahamsson and Eric Levy-Abegnoli. In >> general, storage chip is cheaper than processing chip. > > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Tuesday, March 09, 2010 3:21 PM > To: "Mikael Abrahamsson" > Cc: > Subject: Re: [savi] call for comments: savi-dhcp-01 > >> El 09/03/10 7:54, Mikael Abrahamsson escribió: >>> On Mon, 8 Mar 2010, marcelo bagnulo braun wrote: >>> >>>> If SAVI switches reboots imply that the communication will be >>>> interrupted unless all switches are upgraded to support SAVI, then >>>> if you only replace one switch, then you are breaking your netwokr. >>>> So in order to work properly, you need to upgrade all the network. >>>> So, this is not incrementally deployable >>> >>> Hi Marcelo. >>> >>> I very quickly read draft-bagnulo-savi-analysis-02.txt as you >>> recommended, and as far as I can see, everything in it is correct. I >>> guess we just see differently on the implications on network >>> maintenance and stability. >>> >>> I come from an ISP background and have that point of view, I don't >>> trust my customers and they have no certificate or other to verify >>> that I am who I am, and my customers definitely can't trust each >>> other. Therefore I try to make sure that traffic between customers >>> does a route hop thru my equipment, so basically there is no L2 >>> connectivity between customers. I also need to know what >>> customer/port has what IP at any given time, which for me means I >>> have to use stateful DHCP so I can store this binding. SLAAC is just >>> not acceptable in this scenario (because of TCAM limitations in my >>> equipment I don't want my equipment connected to a customer /64 >>> without limitations on IPs used). >> >> right, i wasn't suggesting we drop dhcp based savi, i do agree dhcp >> based savi is needed. The issues that i am raising are related to >> specifically what shall we do when a dhcp savi device receives a >> packet for which there is no binding. >> It can either drop the packet or trigger the binding creation >> procedure. I am pointing out that simply discarding the packet would >> result in reduced robustness of the overall network >>> >>> We today have this problem with the bindings, especially if the >>> customer has a switch in their apartment. If we reboot the basement >>> switch, the computers won't know that via link-down, and the >>> DHCPv4/IP bindings are lost. >> I am not sure i understnad this example what dhcp bindings are lost? >> the host still have their addresses right? >> >>> I guess most people would solve this using "repair connection" in >>> their Windows machine, or just plain restart it, upon which >>> everything starts again. If the customer is running their machine >>> unattended then it'll be unreachable until a DHCP request/discover >>> is seen again. >>> >>> So I do think we can agree that partially deploying SAVI framework >>> on just some devices has its disadvantages, but I still think they >>> can be managed by the network staff knowing about this downside and >>> working around it, perhaps by lowering lease times on DHCP when they >>> know they're going to reboot, lowering the outage time. >> sure, that could work, as long as the reboot is planned. >> So one possibility as you said is to have a ordered reboot option in >> dhcp savi, that reduces the times in the dhcp lease, in order to make >> sure that the hosts will redo their dhcp lease once they boot again. >> The issue that i see here is that many siwtches mostly are rebooted >> by power them down, which does not allows for an ordered shut down >> >> >>> Also, it might be an option to have a optional learning-only mode in >>> SAVI for the first X minutes after startup, where packets are not >>> dropped but instead allowed. When the X minutes have passed (perhaps >>> X could be deducted by seeing lease times in DHCP), then we go into >>> "secure mode" and start dropping packets according to the states >>> we've learned. >>> >> >> well, the other option would be to trigger the learning procedure >> when a data packet for which no binding exists is recieved. That >> bsaically requires the dhcp savi device to issue a dhcp confirm >> message to the dhcp server in order to veryfy that a binding exists, >> for instance. That would solve all the problems for all topologies >> afaict. >>> Right now I'm inclined to think that there is no really good way to >>> handle this, >> >> see above >> >> regards, marcelo >> >> >>> and any handling of it should be optional for vendors to implement >>> because of the added complexity. >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > From swmike@swm.pp.se Tue Mar 9 01:46:48 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3FA23A67EA for ; Tue, 9 Mar 2010 01:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fODt1DcNOtmm for ; Tue, 9 Mar 2010 01:46:42 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id E120F3A67CF for ; Tue, 9 Mar 2010 01:46:41 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6946BA0; Tue, 9 Mar 2010 10:46:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 668959F for ; Tue, 9 Mar 2010 10:46:42 +0100 (CET) Date: Tue, 9 Mar 2010 10:46:42 +0100 (CET) From: Mikael Abrahamsson To: savi@ietf.org In-Reply-To: <4B960C36.8080306@it.uc3m.es> Message-ID: References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 09:46:48 -0000 On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: > but this is what we qualify as a must in the ietf terminology. If you > don't do this, the network breaks in different ways, right? I don't agree that this is a must. This breakage is limited to certain operational concerns, it's not a fundamental problem that makes it not work at all. One can make the argument that this is a risk taken by the entity that chooses to deploy SAVI partially and that SAVI mandates things that are needed for a totally SAVI enabled network where all devices have this, and in the case not all of them have SAVI functionality, then things will break unless a MAY or SHOULD clause is implemented? I don't like the situation where some vendors might not offer SAVI at all, to handle the problem you're describing. -- Mikael Abrahamsson email: swmike@swm.pp.se From junbi@tsinghua.edu.cn Tue Mar 9 02:22:44 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069A23A67FB for ; Tue, 9 Mar 2010 02:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM6u8+pUPMoC for ; Tue, 9 Mar 2010 02:22:41 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 936B83A6767 for ; Tue, 9 Mar 2010 02:22:35 -0800 (PST) Received: from th024139.ip.tsinghua.edu.cn ([59.66.24.139] helo=junbiVAIO) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NowZz-0002Zi-8K; Tue, 09 Mar 2010 18:22:23 +0800 Message-ID: <33F367E846844630B6A7B238177254F9@junbiVAIO> From: "Jun Bi" To: "Mikael Abrahamsson" , References: <4B94C376.40502@it.uc3m.es><4B94D28C.3000205@it.uc3m.es><10F327EA71564228A016D2641E12121A@junbiVAIO><4B95039F.7030908@it.uc3m.es><4B95F6EA.8080800@it.uc3m.es><4B960C36.8080306@it.uc3m.es> In-Reply-To: Date: Tue, 9 Mar 2010 18:22:23 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 10:22:44 -0000 -------------------------------------------------- From: "Mikael Abrahamsson" Sent: Tuesday, March 09, 2010 5:46 PM To: Subject: Re: [savi] call for comments: savi-dhcp-01 > On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: > >> but this is what we qualify as a must in the ietf terminology. If you >> don't do this, the network breaks in different ways, right? > > I don't agree that this is a must. This breakage is limited to certain > operational concerns, it's not a fundamental problem that makes it not > work at all. > I really agree with Mikael. I think both Mikael and I have the service provider background (we are with CERNET running campus networks). I don't see this is an uncovered severe problem. The current operational experience is that if the user found a problem, he will try to repair his network connection first by himself, if he still had the problem again, then he will call the help desk. Again, as I stated in my past emails, the power-down of a switch is really low frequent event in any operational network (if the reboot is because a planed topology change, then the service provide has enough reason to let his user renew his connection) . We don't let users repair his connection very often. So I don't see it is a severe problem, we service providers had more severe problem such as users could not access network due to the spoofing a ARP or DHCP server in today's network, SAVI will help to resolve this problem. So my opinion is if we need to do it, just add it as option, not must. (remember when I present savi-dhcp at IETF76, I used those probes sending from switch to handle those special cases, I did see some people didn't like it). I really doubt if it is a good approach to bring the complexity as a MUST to the device to fix some very special case (e.g. the power-down of a switch). If we keep the rfc simplified, then more vendors will implement it. Then if the service provider really needs, and if the vendor also wants, they can still implement it as optional features (maybe in higher-end savi-switches with better hardware). > One can make the argument that this is a risk taken by the entity that > chooses to deploy SAVI partially and that SAVI mandates things that are > needed for a totally SAVI enabled network where all devices have this, and > in the case not all of them have SAVI functionality, then things will > break unless a MAY or SHOULD clause is implemented? > > I don't like the situation where some vendors might not offer SAVI at all, > to handle the problem you're describing. As one form service provider, I love this statement. I do hope more vendors to support SAVI, even in very low-end switch, then it will be very cheap for us to upgrade all switches (fully deployment at access level) with SAVI-functions in a short time. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@cernet.edu.cn Tue Mar 9 02:48:04 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E4D3A6880 for ; Tue, 9 Mar 2010 02:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.157 X-Spam-Level: X-Spam-Status: No, score=0.157 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYxQu8mSj2Te for ; Tue, 9 Mar 2010 02:47:59 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 9972D3A6817 for ; Tue, 9 Mar 2010 02:47:57 -0800 (PST) Received: from junbiVAIO([59.66.24.139]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54b96935f; Tue, 09 Mar 2010 18:47:59 +0800 Message-ID: From: "Bi Jun" To: "marcelo bagnulo braun" , "SAVI Mailing List" References: <4B95FDE7.8070100@it.uc3m.es> In-Reply-To: <4B95FDE7.8070100@it.uc3m.es> Date: Tue, 9 Mar 2010 18:47:45 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: wnlywoXB Subject: Re: [savi] dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 10:48:04 -0000 Hi Marcelo, Since you are entitled "topology change", I want to say sth. Based on our operational experience, if we do a planed topology change, then we have to plan we will have more serious problem than this. So topology change in an operational network is usually carefully planed. We don't do it very often, and once we do it, we will let users understand us. So I don't see a problem of planed topology change. The only thing is the power-down of a switch, which is really a low frequency event in an operational network. If we found the power down, we will also inform users (only users under that switch will be affected, not all users will be affect) that if you had any problem thank you please renew your connection. thanks, Jun Bi -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Tuesday, March 09, 2010 3:51 PM To: "SAVI Mailing List" Subject: [savi] dealing with topology changes in dhcp savi > Hi, > > I have another question about dhcp save > > How do you handle the following situation? > > In the case SAVI is being deployed in a switched Ethernet network, > topology changes may result in a SAVI device receiving packets from a > legitimate user for which the SAVI device does not have a binding > for. Consider the following example: > > > > +------+ +--------+ +---------------+ > |SAVI I|-------------|SWITCH I|-------|rest of the net| > +------+ +--------+ +---------------+ > | | > | +--------+ > | | SAVI II| > | +--------+ > | +----------+ | > +---|SWITCH II |-----+ > +----------+ > | > +-----+ > | Host| > +-----+ > > > The DHCP server is located in the part called rest of the network. > Suppose that after bootstrapping all the elements are working > properly and the spanning tree is rooted in the router and it > includes one branch that goes SWITCH I-SAVI I- SWITCH II and another > branch that goes SWITCH I-SAVI II. > > Suppose that the Host boots at this moment and perfomrs the DHCP > sxchange. > The message is propagated through the spanning tree and it received > by SAVI I but not by SAVI II. Same happens with the reply. > SAVI I creates the binding. > > Suppose that SAVI I fails and the spanning tree reconverges to SWITCH > I- SAVI II- SWITCH II. Now data packets coming from the Host will be > coursed through SAVI II which does not have binding state and will > drop the packets. > > Regards, marcelo > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@cernet.edu.cn Tue Mar 9 02:50:44 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96AF63A681B for ; Tue, 9 Mar 2010 02:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.147 X-Spam-Level: X-Spam-Status: No, score=0.147 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxEdGMBtXiNn for ; Tue, 9 Mar 2010 02:50:37 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 756923A67F9 for ; Tue, 9 Mar 2010 02:50:36 -0800 (PST) Received: from junbiVAIO([59.66.24.139]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54b9693fd; Tue, 09 Mar 2010 18:50:37 +0800 Message-ID: <78FA08CAE70B4EE087E32970CFEFC870@junbiVAIO> From: "Bi Jun" To: "Bi Jun" , "marcelo bagnulo braun" , "SAVI Mailing List" Date: Tue, 9 Mar 2010 18:50:22 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: wJTBxoXB Subject: Re: [savi] dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 10:50:44 -0000 by the way, if this is a planed reboot of SAVI-I, then the approach of saving state before rebooting will work. thanks, Jun -------------------------------------------------- From: "Bi Jun" Sent: Tuesday, March 09, 2010 6:47 PM To: "marcelo bagnulo braun" ; "SAVI Mailing List" Subject: Re: [savi] dealing with topology changes in dhcp savi > Hi Marcelo, > > Since you are entitled "topology change", I want to say sth. > Based on our operational experience, if we do a planed topology change, > then we have to plan we will have more serious problem than this. > So topology change in an operational network is usually carefully planed. > We don't do it very often, and once we do it, we will let users understand > us. > > So I don't see a problem of planed topology change. The only thing is the > power-down > of a switch, which is really a low frequency event in an operational > network. If we found the power down, we will also inform users (only users > under that switch will be affected, not all users will be affect) that if > you had any problem thank you please renew your connection. > > thanks, > Jun Bi > > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Tuesday, March 09, 2010 3:51 PM > To: "SAVI Mailing List" > Subject: [savi] dealing with topology changes in dhcp savi > >> Hi, >> >> I have another question about dhcp save >> >> How do you handle the following situation? >> >> In the case SAVI is being deployed in a switched Ethernet network, >> topology changes may result in a SAVI device receiving packets from a >> legitimate user for which the SAVI device does not have a binding >> for. Consider the following example: >> >> >> >> +------+ +--------+ +---------------+ >> |SAVI I|-------------|SWITCH I|-------|rest of the net| >> +------+ +--------+ +---------------+ >> | | >> | +--------+ >> | | SAVI II| >> | +--------+ >> | +----------+ | >> +---|SWITCH II |-----+ >> +----------+ >> | >> +-----+ >> | Host| >> +-----+ >> >> >> The DHCP server is located in the part called rest of the network. >> Suppose that after bootstrapping all the elements are working >> properly and the spanning tree is rooted in the router and it >> includes one branch that goes SWITCH I-SAVI I- SWITCH II and another >> branch that goes SWITCH I-SAVI II. >> >> Suppose that the Host boots at this moment and perfomrs the DHCP >> sxchange. >> The message is propagated through the spanning tree and it received >> by SAVI I but not by SAVI II. Same happens with the reply. >> SAVI I creates the binding. >> >> Suppose that SAVI I fails and the spanning tree reconverges to SWITCH >> I- SAVI II- SWITCH II. Now data packets coming from the Host will be >> coursed through SAVI II which does not have binding state and will >> drop the packets. >> >> Regards, marcelo >> >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> From christian.vogt@ericsson.com Sat Mar 13 11:14:36 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446063A6813 for ; Sat, 13 Mar 2010 11:14:36 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOZcpBWoEph7 for ; Sat, 13 Mar 2010 11:14:35 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id F28AA3A67BD for ; Sat, 13 Mar 2010 11:14:33 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o2DJHUkA017015; Sat, 13 Mar 2010 13:17:31 -0600 Received: from client-vpn-078.edd.ericsson.se (147.117.20.213) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.1.375.2; Sat, 13 Mar 2010 14:14:37 -0500 From: Christian Vogt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Sat, 13 Mar 2010 20:14:35 +0100 Message-ID: <32796F04-5D28-49D0-8A77-9225AFBB06EC@ericsson.com> To: SAVI Mailing List MIME-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Cc: Jean-Michel Combes Subject: [savi] SAVI Meeting Agenda for IETF 77 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2010 19:14:36 -0000 Folks - Our upcoming working group meeting at IETF 77 in Anaheim will be on Tuesday, March 23, 17:40 - 19:40, in the California B room of the IETF hotel. You find the meeting agenda at: http://www.ietf.org/proceedings/10mar/agenda/savi.txt Note that the meeting agenda is still subject to changes. Below is a current snapshot. Looking forward to seeing you soon! - Christian ---------------------------------------------------------------------- Agenda of the SAVI working group meeting at IETF 77 Tuesday, March 23, 17:40 - 19:40, California B room ---------------------------------------------------------------------- 17:40 Introduction and administrativa ........................ 10 min Christian Vogt, Jean-Michel Combes 17:50 Analysis of Open Issues in SAVI for SLAAC and SEND ..... 40 min Marcelo Bagnulo (draft-ietf-savi-fcfs, draft-ietf-savi-send) 18:30 SAVI for DHCP .......................................... 20 min Jun Bi (draft-bi-savi-cps) 18:50 Coexistence of Address Assignment Methods .............. 20 min Eric Levy-Abegnoli (draft-levy-abegnoli-savi-plbt) 19:10 CNGI-CERNET2 SAVI deployment update .................... 20 min Jun Bi 19:30 SAVI for Delegated IPv6 Prefixes ....................... 10 min John Kaippallimalil (draft-kaippallimalil-savi-dhcp-pd) 19:40 End of working group meeting From marcelo@it.uc3m.es Mon Mar 15 05:03:56 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2DA3A6B7E for ; Mon, 15 Mar 2010 05:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.569 X-Spam-Level: X-Spam-Status: No, score=-105.569 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTaONw5Opous for ; Mon, 15 Mar 2010 05:03:55 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 0DA843A6B84 for ; Mon, 15 Mar 2010 04:37:19 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id EB4737F3DCA for ; Mon, 15 Mar 2010 12:37:23 +0100 (CET) Message-ID: <4B9E1BF3.9080709@it.uc3m.es> Date: Mon, 15 Mar 2010 12:37:23 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: savi@ietf.org References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 12:03:56 -0000 Hi Mikael, sorry for the delay, been away for a few days below... El 09/03/10 10:46, Mikael Abrahamsson escribió: > On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: > >> but this is what we qualify as a must in the ietf terminology. If you >> don't do this, the network breaks in different ways, right? > > I don't agree that this is a must. This breakage is limited to certain > operational concerns, it's not a fundamental problem that makes it not > work at all. > Let's go back to RFC 2119 where the usage of these terms is defines: RFC2119 reads: * * 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. So, the situation is that if the triggering of the binding creation by data packet si not implemented, a legitimate user will be disconnected from the network in case the state is loss or in case a failure results in a change in the topology. So this actually affects interoperability. The alternative would be a SHOULD properly qualified. I think that for the SLAAC/ND case, it is much more likely that the situation occurs (due to packet loss and the non reliable nature of the DAD procedure), so i really think that the triggering of the SAVI binding creation process upon the recpetion of data packets should be a MUST. For the dhcp case, the cases in whcih this fails are reduced because of the reliable nature of the dhcp exchange, so while i would rather go for a MUST, i think i can live with a SHOULD. > One can make the argument that this is a risk taken by the entity that > chooses to deploy SAVI partially and that SAVI mandates things that > are needed for a totally SAVI enabled network where all devices have > this, and in the case not all of them have SAVI functionality, then > things will break unless a MAY or SHOULD clause is implemented? > No, a MAY is something that is completelly optional and would not affect interop in any way. As i said above, in the case of dhcp, if the SHOULD is properly qualified, i could live with that. > I don't like the situation where some vendors might not offer SAVI at > all, to handle the problem you're describing. > Right, i do have this concern as well, but i am very worried about the impact to the overall robustness fo the network. Regards, marcelo From marcelo@it.uc3m.es Mon Mar 15 05:35:50 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD5CC3A6BCB for ; Mon, 15 Mar 2010 05:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.38 X-Spam-Level: X-Spam-Status: No, score=-106.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8CDnnZyAwzU for ; Mon, 15 Mar 2010 05:35:49 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id A91543A699E for ; Mon, 15 Mar 2010 05:09:33 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 008E1BAAC49; Mon, 15 Mar 2010 13:09:38 +0100 (CET) Message-ID: <4B9E2382.8000304@it.uc3m.es> Date: Mon, 15 Mar 2010 13:09:38 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Bi Jun References: <4B95FDE7.8070100@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: SAVI Mailing List Subject: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 12:35:51 -0000 Hi Jun, sorry for the delay, i was away for a few days. Ok, let me rephrase my question then. Suppose that you have the topology that is depicted below, with multiple redundant switches to benefit from robustness. My point is that the introduction of SAVI that is unable to cope with data packets for which there is no binding will reduce the robustness of the network, even if network has been designed to be redundant. In the case SAVI is being deployed in a switched Ethernet network, failures in a single device changes may result in a SAVI device receiving packets from a legitimate user for which the SAVI device does not have a binding for. Consider the following example: +------+ +--------+ +---------------+ |SAVI I|-------------|SWITCH I|-------|rest of the net| +------+ +--------+ +---------------+ | | | +--------+ | | SAVI II| | +--------+ | +----------+ | +---|SWITCH II |-----+ +----------+ | +-----+ | Host| +-----+ The DHCP server is located in the part called rest of the network. Suppose that after bootstrapping all the elements are working properly and the spanning tree is rooted in the router and it includes one branch that goes SWITCH I-SAVI I- SWITCH II and another branch that goes SWITCH I-SAVI II. Suppose that the Host boots at this moment and perfomrs the DHCP sxchange. The message is propagated through the spanning tree and it received by SAVI I but not by SAVI II. Same happens with the reply. SAVI I creates the binding. Suppose that SAVI I fails and the spanning tree reconverges to SWITCH I- SAVI II- SWITCH II. Now data packets coming from the Host will be coursed through SAVI II which does not have binding state and will drop the packets. Comments? Regards, marcelo El 09/03/10 11:47, Bi Jun escribió: > Hi Marcelo, > > Since you are entitled "topology change", I want to say sth. > Based on our operational experience, if we do a planed topology change, > then we have to plan we will have more serious problem than this. > So topology change in an operational network is usually carefully planed. > We don't do it very often, and once we do it, we will let users > understand us. > > So I don't see a problem of planed topology change. The only thing is > the power-down > of a switch, which is really a low frequency event in an operational > network. If we found the power down, we will also inform users (only > users under that switch will be affected, not all users will be > affect) that if you had any problem thank you please renew your > connection. > > thanks, > Jun Bi > > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Tuesday, March 09, 2010 3:51 PM > To: "SAVI Mailing List" > Subject: [savi] dealing with topology changes in dhcp savi > >> Hi, >> >> I have another question about dhcp save >> >> How do you handle the following situation? >> >> In the case SAVI is being deployed in a switched Ethernet network, >> topology changes may result in a SAVI device receiving packets from a >> legitimate user for which the SAVI device does not have a binding >> for. Consider the following example: >> >> >> >> +------+ +--------+ +---------------+ >> |SAVI I|-------------|SWITCH I|-------|rest of the net| >> +------+ +--------+ +---------------+ >> | | >> | +--------+ >> | | SAVI II| >> | +--------+ >> | +----------+ | >> +---|SWITCH II |-----+ >> +----------+ >> | >> +-----+ >> | Host| >> +-----+ >> >> >> The DHCP server is located in the part called rest of the network. >> Suppose that after bootstrapping all the elements are working >> properly and the spanning tree is rooted in the router and it >> includes one branch that goes SWITCH I-SAVI I- SWITCH II and another >> branch that goes SWITCH I-SAVI II. >> >> Suppose that the Host boots at this moment and perfomrs the DHCP >> sxchange. >> The message is propagated through the spanning tree and it received >> by SAVI I but not by SAVI II. Same happens with the reply. >> SAVI I creates the binding. >> >> Suppose that SAVI I fails and the spanning tree reconverges to SWITCH >> I- SAVI II- SWITCH II. Now data packets coming from the Host will be >> coursed through SAVI II which does not have binding state and will >> drop the packets. >> >> Regards, marcelo >> >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > From marcelo@it.uc3m.es Mon Mar 15 05:36:17 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA2F3A6BD7 for ; Mon, 15 Mar 2010 05:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.408 X-Spam-Level: X-Spam-Status: No, score=-106.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFlBxq+5Du2a for ; Mon, 15 Mar 2010 05:36:16 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 01D2C3A6CF5 for ; Mon, 15 Mar 2010 05:10:13 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 73D006C3034; Mon, 15 Mar 2010 13:10:18 +0100 (CET) Message-ID: <4B9E23AA.3010408@it.uc3m.es> Date: Mon, 15 Mar 2010 13:10:18 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Bi Jun References: <78FA08CAE70B4EE087E32970CFEFC870@junbiVAIO> In-Reply-To: <78FA08CAE70B4EE087E32970CFEFC870@junbiVAIO> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: SAVI Mailing List Subject: Re: [savi] dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 12:36:17 -0000 As i mention in the other email, suppose it is not a planned event, but just a failure El 09/03/10 11:50, Bi Jun escribió: > by the way, if this is a planed reboot of SAVI-I, then the approach of > saving state before rebooting will work. > > thanks, > Jun > > -------------------------------------------------- > From: "Bi Jun" > Sent: Tuesday, March 09, 2010 6:47 PM > To: "marcelo bagnulo braun" ; "SAVI Mailing List" > > Subject: Re: [savi] dealing with topology changes in dhcp savi > >> Hi Marcelo, >> >> Since you are entitled "topology change", I want to say sth. >> Based on our operational experience, if we do a planed topology change, >> then we have to plan we will have more serious problem than this. >> So topology change in an operational network is usually carefully >> planed. >> We don't do it very often, and once we do it, we will let users >> understand us. >> >> So I don't see a problem of planed topology change. The only thing is >> the power-down >> of a switch, which is really a low frequency event in an operational >> network. If we found the power down, we will also inform users (only >> users under that switch will be affected, not all users will be >> affect) that if you had any problem thank you please renew your >> connection. >> >> thanks, >> Jun Bi >> >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Tuesday, March 09, 2010 3:51 PM >> To: "SAVI Mailing List" >> Subject: [savi] dealing with topology changes in dhcp savi >> >>> Hi, >>> >>> I have another question about dhcp save >>> >>> How do you handle the following situation? >>> >>> In the case SAVI is being deployed in a switched Ethernet network, >>> topology changes may result in a SAVI device receiving packets >>> from a >>> legitimate user for which the SAVI device does not have a binding >>> for. Consider the following example: >>> >>> >>> >>> +------+ +--------+ +---------------+ >>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>> +------+ +--------+ +---------------+ >>> | | >>> | +--------+ >>> | | SAVI II| >>> | +--------+ >>> | +----------+ | >>> +---|SWITCH II |-----+ >>> +----------+ >>> | >>> +-----+ >>> | Host| >>> +-----+ >>> >>> >>> The DHCP server is located in the part called rest of the network. >>> Suppose that after bootstrapping all the elements are working >>> properly and the spanning tree is rooted in the router and it >>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and another >>> branch that goes SWITCH I-SAVI II. >>> >>> Suppose that the Host boots at this moment and perfomrs the DHCP >>> sxchange. >>> The message is propagated through the spanning tree and it received >>> by SAVI I but not by SAVI II. Same happens with the reply. >>> SAVI I creates the binding. >>> >>> Suppose that SAVI I fails and the spanning tree reconverges to >>> SWITCH >>> I- SAVI II- SWITCH II. Now data packets coming from the Host >>> will be >>> coursed through SAVI II which does not have binding state and will >>> drop the packets. >>> >>> Regards, marcelo >>> >>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> > From junbi@cernet.edu.cn Mon Mar 15 05:38:26 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7833A6BEB for ; Mon, 15 Mar 2010 05:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.44 X-Spam-Level: * X-Spam-Status: No, score=1.44 tagged_above=-999 required=5 tests=[AWL=-1.257, BAYES_50=0.001, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtympMMvQk59 for ; Mon, 15 Mar 2010 05:38:23 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 8D9D93A6D94 for ; Mon, 15 Mar 2010 05:12:43 -0700 (PDT) Received: from junbiVAIO([59.66.24.139]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54b9e9720; Mon, 15 Mar 2010 20:12:48 +0800 Message-ID: <09741A6EA86846049A114B745EE24C37@junbiVAIO> From: "Bi Jun" To: "SAVI Mailing List" Date: Mon, 15 Mar 2010 20:12:36 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0543_01CAC47B.DB0B8FF0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: URIKJrXB Subject: [savi] savi-dhcp-02 draft X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 12:38:26 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0543_01CAC47B.DB0B8FF0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi all, This is a revised version of savi-dhcp (revised based on the discussion of dhcp-01 on the mailing-list in the past week), basically, make the control packet-triggered functions as MUST (low cost to be implemented in every switch), and have the data-triggered functions (more complex to be implemented) as optional for higher-end switches (to enable more flexible use of savi device). We are consulting the vendors on the cost for those options. please give us your comments. thanks, Jun Bi ------=_NextPart_000_0543_01CAC47B.DB0B8FF0 Content-Type: text/plain; format=flowed; name="draft-ietf-savi-dhcp-02.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-savi-dhcp-02.txt" SAVI J. Bi, J. Wu Internet Draft CERNET Intended status: Standard Tracks G. Yao Expires: September 2010 Tsinghua Univ. F. Baker Cisco March 15, 2010 SAVI Solution for DHCP draft-ietf-savi-dhcp-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November = 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as = Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Bi Expires September 15, 2010 [Page 1] =0C Internet-Draft savi-dhcp March 2010 This Internet-Draft will expire on September 15, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document specifies the procedure for creating bindings between a DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and an anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets generated on the local link with forged IP addresses. Table of Contents Copyright Notice ............................................... 2 Abstract ....................................................... 2 1. Introduction ................................................ 4 2. Conventions used in this document............................ 4 3. Mechanism Overview .......................................... 4 4. Background and Related Protocols............................. 4 5. Terminology ................................................. 5 6. Conceptual Data Structures................................... 5 6.1. Binding State Table (BST)............................... 5 6.2. Filtering Table (FT).................................... 6 7. Binding States Description................................... 6 8. DHCP Scenario ............................................... 7 Figure 3 DHCP Scenario ....................................... 7 9. Anchor Attributes ........................................... 7 9.1. SAVI-Validation Attribute............................... 7 9.2. SAVI-DHCP-Trust Attribute............................... 8 9.3. SAVI-SAVI Attribute..................................... 8 9.4. Optional Attributes..................................... 8 9.4.1. SAVI-LocalGroup Attribute.......................... 8 Bi Expires September 15, 2010 [Page 2] =0C Internet-Draft savi-dhcp March 2010 9.4.2. SAVI-DataTrigger Attribute......................... 9 10. Prefix Configuration........................................ 9 11. Binding Set Up ............................................ 10 11.1. Process of DHCP Snooping.............................. 10 11.1.1. Initialization................................... 10 11.1.1.1. Trigger Event............................... 11 11.1.1.2. Event Validation............................ 11 11.1.1.3. Following Actions........................... 11 11.1.2. From START to LIVE............................... 11 11.1.2.1. Trigger Event............................... 11 11.1.2.2. Event Validation............................ 12 11.1.2.3. Following Actions........................... 12 11.1.3. From LIVE to DETECTION........................... 13 11.1.3.2. Event Validation............................ 13 11.1.3.3. Following Actions........................... 13 11.1.4. From DETECTION to BOUND.......................... 14 11.1.4.1. Trigger Event............................... 14 11.1.4.2. Following Actions........................... 14 11.1.5. After BOUND...................................... 14 11.2. State Machine of DHCP Snooping........................ 15 12. Filtering Specification.................................... 17 12.1. Data Packet Filtering................................. 17 12.2. Control Packet Filtering.............................. 17 13. Format and Delivery of Probe Messages...................... 18 13.1. Duplicate detection................................... 18 14. Binding Remove ............................................ 19 15. Handle Anchor Off-link event............................... 19 16. About Collision in Detection............................... 19 16.1. Whether to Notify the DHCP Server..................... 19 16.2. The Result of Detection without Host Aware............ 20 17. Filtering during Detection................................. 20 18. Binding Number Limitation.................................. 20 19. Movement without DHCP Procedure............................ 20 20. MLD Consideration ......................................... 21 21. State Restoration ......................................... 21 22. Data Triggered Process..................................... 21 23. Stateless DHCP ............................................ 22 24. Confirm Triggered Binding.................................. 22 25. Constants ................................................. 22 26. Security Considerations.................................... 22 27. IANA Considerations........................................ 23 28. References ................................................ 23 28.1. Normative References.................................. 23 28.2. Informative References................................ 23 29. Acknowledgments ........................................... 23 Bi Expires September 15, 2010 [Page 3] =0C Internet-Draft savi-dhcp March 2010 1. Introduction This document describes the procedure for creating bindings between DHCP assigned addresses and an anchor (refer to [savi-framework]). Other related details about this procedure are also specified in this document. These bindings can be used to filter packets with forged IP = addresses. How to use these bindings is specified in [savi-framework], depending on the environment and configuration. The definition and examples of anchor is also specified in [savi-framework]. The binding process is inspired by the work of IP Source Guard. This specification differs from IP Source Guard in the specification for collision detection, which is essential in environments with multiple address assignment methods. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Mechanism Overview The mechanism specified in this document is designed to provide a host level source IP address validation granularity, as a supplement to BCP38 [BCP38]. This mechanism is deployed on the access device (including access switch, wireless access point/controller, etc), and performs mainly DHCP snooping to set up bindings between DHCP assigned IP addresses and corresponding anchors. The bindings can be used to validate the source address in the packets. 4. Background and Related Protocols This mechanism is an instance of a SAVI [savi-framework] solution, specialized for addresses assigned using the DHCP protocol. Dynamic Host Configuration Protocol version 4 [RFC2131] and Dynamic Host Configuration Protocol version 6 [RFC3315] specify the procedures for providing a client with assigned address and other configuration information from a DHCP server. If a client gets an address through the DHCP protocol, the address should be regarded as a potential "authorized" or "registered" address of the client. In IPv6, IPv6 Stateless Autoconfiguration [RFC4862] is used as another address assignment mechanism. A node can use this mechanism Bi Expires September 15, 2010 [Page 4] =0C Internet-Draft savi-dhcp March 2010 to auto-configure an IPv6 address. A DHCPv6 client may use a stateless address to send message to DHCP server. Even in a DHCPv6- only environment, a node must assign its link-local address through this mechanism. [RFC4862] clearly requires that duplicated address detection must be performed on any IPv6 address, including DHCPv6 address. [RFC4861] specifies the Neighbor Discovery protocol, which is an essential part of IPv6 address assignment. [RFC5227] specifies the procedure to detect IPv4 address collision. It is not required currently. However, this feature is useful to determine the uniqueness of an IPv4 address on the link. Considering not all the operating systems support [RFC5227], this solution is designed to be compatible with operating systems not complying with [RFC5227]. 5. Terminology Main terms used in this document are described in [savi-framework], [RFC2131] and [RFC3315]. 6. Conceptual Data Structures This section describes the possible conceptual data structures used in this mechanism. Two main data structures are used to record bindings and their states respectively. There is redundancy between the two structures, for the consideration of separation of data plane and control plane. 6.1. Binding State Table (BST) This table contains the state of binding between source address and anchor. Entries are keyed on the anchor and source IP address. Each entry has a lifetime field recording the remaining lifetime of the entry, a state field recording the state of the binding and a field recording other information. Bi Expires September 15, 2010 [Page 5] =0C Internet-Draft savi-dhcp March 2010 +---------+----------+-------+-----------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-------+-----------+-------+ | A | IP_1 | Bound | 65535 | | +---------+----------+-------+-----------+-------+ | A | IP_2 | Bound | 10000 | | +---------+----------+-------+-----------+-------+ | B | IP_3 |_Start | 1 | | +---------+----------+-------+-----------+-------+ Figure 1 Instance of BST 6.2. Filtering Table (FT) This table contains the bindings between anchor and address, keyed on anchor. This table doesn't contain any state of the binding. This table is only used to filter packets. An Access Control List can be regarded as a practical instance of this table. +---------+----------+ |Anchor |Address | +---------+----------+ |A |IP_1 | +---------+----------+ |A |IP_2 | +---------+----------+ Figure 2 Instance of FT 7. Binding States Description This section describes the binding states of this mechanism. START A DHCP request (or a DHCPv6 Confirm, or a DHCPv6 Solicitation with Rapid Commit option) has been received from host, and it may trigger a new binding. LIVE A DHCP address has been acknowledged by a DHCP server. DETECTION A gratuitous ARP or Duplicate Address Detection NSOL has been sent by the host (or the SAVI device). BOUND The address has passed duplicate detection and it is bound with the anchor. Bi Expires September 15, 2010 [Page 6] =0C Internet-Draft savi-dhcp March 2010 8. DHCP Scenario Figure 3 shows the main elements in a DHCP enabled network. At least one DHCP server MUST be deployed in the network, and DHCP relay MAY be used to relay message between client and server. Other address assignment mechanisms may be also used in such network. +--------+ | DHCP | | Server | +-------,+ | | | +----'-----+ | SAVI | | Device | +-/------/-+ | | +----\-+ +\-----+ |DHCP | |Client| |Relay | | | +------+ +------+ Figure 3 DHCP Scenario 9. Anchor Attributes This section specifies the anchor attributes involved in this mechanism. Anchor is defined in the [savi-framework]. Attribute of each anchor is configurable. In default, anchor has no attribute. An anchor MAY be configured to have one or more compatible attributes. However, an anchor MAY have no attribute. If an anchor has no attribute, server type DHCP message from this anchor MUST be dropped. However, other packets SHOULD NOT be dropped. 9.1. SAVI-Validation Attribute If and only if source address validation must be performed on the traffic from an anchor, this anchor MUST be set to have SAVI- Validation attribute. The filtering process on anchor with such attribute is described in section 12. Bi Expires September 15, 2010 [Page 7] =0C Internet-Draft savi-dhcp March 2010 9.2. SAVI-DHCP-Trust Attribute If and only if an anchor is associated with a trustable DHCP server/relay, it SHOULD be set to have this attribute. If DHCP is used to assign address in the network, there MUST be at least one anchor with this attribute. DHCP Reply message not coming from such ports MUST be dropped. 9.3. SAVI-SAVI Attribute If and only if an anchor is associated with another SAVI device, it SHOULD be set to have this attribute. All traffic from anchor with this attribute will be forwarded without check. This attribute can also be set on other anchors if the administrator decides not to validate the traffic from the anchor. Note that DHCP server message and router message will also be trusted. This attribute is mutually exclusive with SAVI-Validation. 9.4. Optional Attributes This section specifies the attributes optional for the implementation of this solution. The usage of these attributes may be suboptimal compared with manual configuration, because of the additional complexity. However, in scenarios that manual configuration is hardly to be taken timely or even impossible, these attributes can be = useful. The implementation and configuration of these attributes are left to be determined by vendors, network administrators and clients. 9.4.1. SAVI-LocalGroup Attribute If a group of anchors on a SAVI device are associated with the same group of clients, these anchors can be set to have SAVI-LocalGroup attribute. SAVI-LocalGroup Attribute is set with the index or name of the group. The bindings set up on an anchor with this attribute MUST be replicated to other anchors in the same group. If a binding entry is removed, the replicated entries on other anchors MUST be deleted, unless the entry is removed because the associated anchor is = off-link. This attribute is designed to handle the scenario that a group of clients (including a single client) posses multiple anchors, but Bi Expires September 15, 2010 [Page 8] =0C Internet-Draft savi-dhcp March 2010 control packets are only transmitted with one of the anchors. After address assignment, the assigned address may be used with other anchors. This attribute is mutually exclusive with SAVI-SAVI. 9.4.2. SAVI-DataTrigger Attribute If on an anchor, data packet (non-DHCP message and non-NDP message) is required to trigger binding set up, this anchor should be set to have this attribute. The process of data triggered binding is specified in section 22. This attribute is designed to handle some special cases that control packet will not be received by SAVI device, including: 1. Local Link Move without Re-configuration Process 2. Multiple Attachments to Different Devices Note that, both scenarios can be handled if client chooses to repair its network manually. But this attribute can be set to improve user experience and network robustness; meanwhile it brings additional complexity and possible security risk. This attribute is mutually exclusive with SAVI-SAVI and SAVI- Validation. 10. Prefix Configuration In DHCP scenario, address advertised by DHCP server should be believed in. However, in this solution, a node shares the same anchor as the DHCP server can disguise as the DHCP server and offer the client incorrect configuration information. Without fully deployment of SAVI, this problem is difficult to solve. Thus, it is SUGGESTED that correct address prefix should be configured, and DHCP server message which assigns address out of the scope should be dropped. This mechanism can ensure the client can at least get an address with proper prefix. This document suggests set 3 prefix scopes: IPv4 Prefix: The allowed scope of any kind of IPv4 addresses. It can be set manually. Bi Expires September 15, 2010 [Page 9] =0C Internet-Draft savi-dhcp March 2010 IPv6 SLAAC Prefixes: The allowed scope of SLAAC and manually configured IPv6 addresses. It can be set through snooping RA message from port with SAVI-RA-Trust attribute, DHCP-PD or manual configuration. FE80::/64 MUST be set to a feasible prefix. IPv6 DHCPv6 Prefixes: The allowed scope of DHCPv6 addresses. It can be set through RA snooping, DHCP-PD protocol, or manual configuration. There is no need to explicitly present these prefix scopes. But these restrictions SHOULD be used as premier check in binding set up. Refer to security consideration for other discussions. 11. Binding Set Up This section specifies the procedure of setting up bindings based on control packet snooping. All binding entries are set up on anchor with SAVI-Validation attribute. 11.1. Process of DHCP Snooping 11.1.1. Initialization A binding entry is initialized in this step. This step MAY NOT be performed if: 1. Option 82 is used to keep anchor in DHCP Request and Reply, or 2. Unspoofable MAC is used as anchor(802.11i,802.1ae/af), or 3. The mapping table from MAC to anchor is secure. If none of these three requirements are satisfied, this step SHOULD be performed. If this step is not performed, then binding entry will be initialized in the next step. This step is performed for the consideration that anchor and DHCP assigned address can be bound with security in the next step. Bi Expires September 15, 2010 [Page 10] =0C Internet-Draft savi-dhcp March 2010 Otherwise the security of binding setup is based on the mapping mechanism from MAC to anchor on SAVI device, which may be vulnerable. This step can also help limit the request rate of client to prevent Denial of Services attack against DHCP server. 11.1.1.1. Trigger Event A DHCPv4/v6 Request or a DHCPv6 Confirm or a DHCPv6 Solicitation with Rapid Commit option is received. 11.1.1.2. Event Validation The SAVI device checks current BST as follows: 1. Whether the limitation on binding entry number of this anchor will be exceeded if a new entry is triggered. 11.1.1.3. Following Actions If the check is passed: The SAVI device MUST forward the message. The SAVI device MUST generate an entry for the anchor in the Binding State Table (BST) and set the state field to START. The lifetime of this entry MUST set to be MAX_DHCP_RESPONSE_TIME. The Transaction ID (Refer to Section 2 in [RFC2131] and Section 4.2 in [RFC3315]) field of the request packet SHOULD be recorded in the entry. +---------+----------+-------+-----------------------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-------+-----------------------+-------+ | A | | START |MAX_DHCP_RESPONSE_TIME | TID | +---------+----------+-------+-----------------------+-------+ Figure 4 Binding entry in BST on initialization The TID is kept for assurance that the assigned address can be bound with anchor securely. It is suggested to keep TID in entry. However, TID MAY NOT be contained in the entry. 11.1.2. From START to LIVE 11.1.2.1. Trigger Event A DHCPv4 DHCPACK or DHCPv6 REPLY message is received. Bi Expires September 15, 2010 [Page 11] =0C Internet-Draft savi-dhcp March 2010 11.1.2.2. Event Validation The SAVI device checks the message and BST as follows: 1. Whether the message is received from an anchor which has the SAVI- DHCP-Trust attribute; 2. Whether the entry in the BST with corresponding TID is in the START state. Or if the prior step is not performed, check whether the binding number limitation will be exceeded. 11.1.2.3. Following Actions If the check is passed: The SAVI device MUST deliver the message to the destination. The SAVI device MUST set the state of the corresponding entry to be LIVE. If prior step is not performed, a new entry MUST be generated in the BST. The lifetime of the entry MUST be set to be MAX_ARP_PREPARE_DELAY or MAX_DAD_PREPARE_DELAY respectively. The lease time MUST be recorded in the entry. +---------+----------+-------+------------------------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-------+------------------------+-------+ | A | Addr | LIVE |MAX_ARP_PREPARE_DELAY or| Lease | | | | |MAX_DAD_PREPARE_DELAY | Time | +---------+----------+-------+------------------------+-------+ Figure 5 Binding entry in BST on assignment Then, the SAVI device MAY set the state of the corresponding entry to be DETECTION, and send two or more ARP Request or NSOL for the assigned address. If the SAVI device sends detection packet directly, the next step MUST be omitted. +---------+----------+-----------+-----------------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-----------+-----------------+-------+ | A | Addr | DETECTION |MAX_ARP_DELAY or | Lease | | | | |MAX_DAD_DELAY | Time | +---------+----------+-----------+-----------------+-------+ Figure 6 Binding entry in BST on assignment: another case The SAVI device MUST insert an entry into the Filtering Table if the assigned address is not bound with another anchor in current BST. If the address has been bound with another anchor in current BST, the Bi Expires September 15, 2010 [Page 12] =0C Internet-Draft savi-dhcp March 2010 SAVI device MUST check if the node associated with that anchor is off-line. If yes, bind the address with the new entry and delete the original binding; if no, keep the original entry and delete the new entry in BST. This mechanism can handle local link movement, and avoid attacker grabbing assigned bindings from other nodes. However, if several hosts share the same anchor, and one of them moves to another anchor, this mechanism may cause problem. +---------+----------+ |Anchor |Address | +---------+----------+ |A |Addr | +---------+----------+ Figure 7 Binding entry in FT on assignment The following steps after this step MAY NOT be performed. It is SUGGESTED to perform following steps unless in some specified scenario, e.g., a DHCP-only scenario. If the following steps are not performed because of implementation or configuration, the state of the corresponding entry MUST be changed to BOUND, and the lifetime is set to lease time. 11.1.3. From LIVE to DETECTION 11.1.3.1. Trigger Event A gratuitous ARP Request or Duplicate Address Detection Neighbor Solicitation is received from anchor. Or a timeout event of an entry with state LIVE happens. 11.1.3.2. Event Validation The SAVI device checks the message and BST as follows: 1. Whether the Target IP Address field of the ARP Request or Neighbor Solicitation has been bound with the corresponding anchor in BST or FT. 11.1.3.3. Following Actions If the check is passed: If timeout event of an entry with state LIVE happens, the SAVI device MAY send one or more ARP Request or a DAD NSOL, with Target Address set to the recorded address in the entry. If detection packets are sent, the SAVI device MUST set the state of the entry to be = DETECTION. The lifetime of the entry MUST be set to be MAX_ARP_DELAY or Bi Expires September 15, 2010 [Page 13] =0C Internet-Draft savi-dhcp March 2010 MAX_DAD_DELAY respectively. If no detection packet is sent, the entry MUST be removed from BST and FT. If the SAVI device chooses not to send detection packet, valid packets may get dropped because a number of operating systems don't fully support [RFC4862] and [RFC5227] and don't send detection packets themselves. Thus, it is SUGGESTED the SAVI device SHOULD send detection packet in case the client doesn't send that itself. +---------+----------+-----------+-----------------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-----------+-----------------+-------+ | A | Addr | DETECTION |MAX_ARP_DELAY or| Lease | | | | |MAX_DAD_DELAY | Time | +---------+----------+-----------+-----------------+-------+ Figure 8 Binding entry in BST on detection 11.1.4. From DETECTION to BOUND 11.1.4.1. Trigger Event A timeout event of an entry with state DETECTION occurs or an ARP Response or NA for an address in BST with state DETECTION is = received. 11.1.4.2. Following Actions If a timeout event of an entry with state DETECTION occurs, set the state of the entry to be BOUND. The lifetime of the entry is set to be the Lease time acknowledged by DHCP server. +---------+----------+-----------+----------------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-----------+----------------+-------+ | A | Addr | BOUND | Lease time | | +---------+----------+-----------+----------------+-------+ Figure 9 Binding entry in BST on finalization If an ARP Response or NA for an address in BST with state DETECTION is received, remove the corresponding entry in BST and FT. The ARP Response or NA MUST be delivered to the client. 11.1.5. After BOUND Once a binding entry is set up for an anchor, the binding will be used to filter packet with the anchor, as specified in section 12. On the other hand, DHCP messages with the anchor will affect the = binding. The binding is also affected by DHCP server message toward the = anchor. Bi Expires September 15, 2010 [Page 14] =0C Internet-Draft savi-dhcp March 2010 Before a DHCP message is found that it may change the corresponding binding, its validity MUST be checked as described in section 12.2. Whenever a DHCP Decline is received, delete the corresponding entry in BST and FT. Whenever a DHCP Release is received, if the state of the entry is BOUND, delete the entry in BST and FT. If a DHCPv4 Acknowledgement or DHCPv6 Reply with Renew/Rebind sign is received from the server, set lifetime of the entry in BST to be the new lease time. If the lifetime of an entry with state BOUND expires, delete the entry in BST and Filter Table. The binding may also be affected by control messages with or toward another anchor. The binding MAY be move to another anchor to handle local link movement, as described in section 11.1.2.3. In this situation, the node assigned a DCHP address changes to associate with another anchor, thus the address should be bound with the anchor which the node migrates to. Other than this situation, the binding will not be changed, for the consideration of simplicity. Even if an attached node becomes inactive and doesn't reply to any NS or ARP Request, the associated bindings will not be removed. Switch port down event (or more general, anchor turns off-link) will change the corresponding entry, as described in section 15. 11.2. State Machine of DHCP Snooping The main state transits are listed as follows. Note that the anchor migration of binding entry is not included. State Message/Event Action Next State - REQ/CFM/SOL+RC Generate entry START *- ACK/RPL Generate entry with lease LIVE *- ACK/RPL Generate entry with lease BOUND **- ACK/RPL Generate entry with lease DETECTION , send probe START ACK/RPL Record lease time LIVE Bi Expires September 15, 2010 [Page 15] =0C Internet-Draft savi-dhcp March 2010 **START ACK/RPL Send probe DETECTION START Timeout Remove entry - LIVE Gra ARP REQ/DAD NS - DETECTION LIVE DECLINE Remove entry - LIVE Timeout Send probe DETECTION *LIVE Timeout Remove entry - DETECTION Timeout - BOUND DETECTION ARP RES/DAD NA Remove entry - DETECTION DECLINE Remove entry - BOUND RELEASE/DECLINE Remove entry - BOUND Timeout Remove entry - BOUND RENEW/REBOUND Set new lifetime BOUND *: optional but NOT SUGGESTED. **: optional and MAY conflict other transits REQ: DHCP REQUEST CFM: DHCP CONFIRM SOL: DHCP SOLICITATION RC: Rapid Commit option ACK: DHCP ACKNOWLEDGEMENT RPL: DHCP REPLY Probe Gratuitous ARP REQUEST or Duplicate Address Detection Neighbor Solicitation, described in section 13.1 Gra ARP REQ: Gratuitous ARP REQUEST ARP RES: ARP RESPONSE Bi Expires September 15, 2010 [Page 16] =0C Internet-Draft savi-dhcp March 2010 DAD NS: Duplicate Address Detection Neighbor Solicitation DAD NA: Neighbor Advertisement targeting at a tentative address DECLINE: DHCP DECLINE RELEASE: DHCP RELEASE RENEW: DHCP RENEW REBOUND: DHCP REBOUND 12. Filtering Specification This section specifies how to use bindings to filter packets. Because the Filtering Table is an allow-table, packet with source address not in the table will be filtered. Considering DHCP may coexist with other address assignment methods, e.g., Stateless Auto-configuration, the specification made here is based on the assumption that other SAVI solutions will also use BST and FT to keep bindings and filter packets. Otherwise this solution will conflict with other SAVI solutions. Filtering policies are different for data packet and control packet. DHCP and ND messages that may cause state transit are classified into control packet. Neighbor Advertisement and ARP Response are also included in control packet, because the Target Address of NA and ARP Response should be checked to prevent spoofing. All other packets are considered to be data packets. 12.1. Data Packet Filtering Data packets with an anchor which has attribute SAVI-Validation MUST be checked. If the source of a packet associated with its anchor is in the FT, this packet SHOULD be forwarded; or else the packet MUST be = discarded. 12.2. Control Packet Filtering For anchors with SAVI-Validation attribute: The source address of DHCPv4 Discovery SHOULD be set to all zeros. The source address of DHCPv4 Request SHOULD be set to all zeros or a bound address in FT. Bi Expires September 15, 2010 [Page 17] =0C Internet-Draft savi-dhcp March 2010 The source address of DHCPv6 Request MUST be an address associated with the corresponding anchor in FT. The source address of DHCPv6 Confirm MUST be a link local address associated with the corresponding anchor in FT. The source address of DHCPv6 Solicit MUST be a link layer address bound with corresponding anchor. The link layer address MAY be bound based on SAVI-SLAAC solution or other solutions. The source address of other types of DHCP messages MUST be a address bound with the corresponding anchor. The source address of IPv6 NS and IPv4 gratuitous ARP MUST pass the check on FT. The target address and source address in all the Neighbor Advertisement packets and ARP replies MUST also pass the checks on = FT. For other anchors: All DHCP Reply/Ack packets MUST be from anchor with the SAVI-DHCP- Trust attribute. 13. Format and Delivery of Probe Messages As described in section 11.1.2.3 and 11.1.3.3, the SAVI device MAY send detection probes on behavior of client to determine whether the assigned address is duplicated. Currently no other probes are designed in this solution. 13.1. Duplicate detection Message Type: DAD NS, Gratuitous ARP Request Format: Link layer source - link layer address of host; Link layer destination - For IPv6, use multicast = address specified in [RFC3307]; For IPv4, use broadcast address; IP source - Unspecified address for IPv6; The = tentative address for IPv4; IP destination - For IPv6, multicast address = specified in section 5.4.2 of [RFC4861]; For IPv4, the tentative address; Bi Expires September 15, 2010 [Page 18] =0C Internet-Draft savi-dhcp March 2010 Delivery: MUST not be delivered to the host which the SAVI device is performing DAD on behavior of. 14. Binding Remove If the lifetime of an entry with state BOUND expires, the entry MUST be removed. When the SAVI device receives a DAD NS/Gra ARP request target at an address bound and there is no replies from the anchor, if the anchor is a SAVI-Validation anchor, hold the binding entry through sending NA/ARP Reply, or remove the binding. 15. Handle Anchor Off-link event Port DOWN event MUST be handled if switch port is used as anchor. In more general case, if an anchor turns off-link, this event MUST be handled. Whenever an anchor with attribute SAVI-Validation turns down, the bindings with the anchor MUST be kept for a short time. To handle movement, if receiving DAD NS/Gra ARP request targeting at the address during the period, remove the entry. If the anchor turns on-link during the period, recover bindings. It may result in some security problem, e.g., a malicious node immediately associates with the anchor got off by a previous node, then it can use the address assigned to the previous node. However, this situation is very rare in reality. Authors decide not to handle this situation. 16. About Collision in Detection The SAVI device may receive a response in detection. Some related details are specified here. 16.1. Whether to Notify the DHCP Server It is unnecessary for the SAVI device to notify the DHCP server, because the host will send a DECLINE message to it once it finds the advertised address is conflict. Bi Expires September 15, 2010 [Page 19] =0C Internet-Draft savi-dhcp March 2010 16.2. The Result of Detection without Host Aware In case the SAVI device send detection packet instead of the host, the host will not be aware of the detection result. If the detection succeeds, there is no problem. However, if the detection fails, the packets from the host with the assigned address will be filtered out. This result can be regarded as a reasonable punishment for not performing duplicate detection and using a collision address. The SAVI device MAY choose to notice the client that the assigned address has been used, through a NA message. This mechanism is not required in this solution. 17. Filtering during Detection In this mechanism, whenever the DHCP server replies an address, this address will be allowed immediately even before duplicate detection is completed. This design is in consideration of a host may start to send packets straightway without detection. Also this design is to be compatible with optimistic DAD [RFC4429]. However, this feature may allow an attacker to send quantities of packets with source addresses already assigned to other nodes. A practical solution for this vulnerability is configuring the address pool and allocation algorithm of the DHCP server carefully. 18. Binding Number Limitation It is suggested to configure some mechanism in order to prevent a single node from exhausting the binding table entries on the SAVI device. Either of the following mechanism is sufficient to prevent such attack. 1. Set the upper bound of binding number for each anchor with SAVI- Validation. 2. Reserve a number of binding entries for each anchor with SAVI- Validation attribute and all anchors share a pool of the other binding entries. 3. Limit DHCP Request rate per anchor, using the bound entry number of each anchor as reverse indicator. 19. Movement without DHCP Procedure This mechanism currently doesn't handle any movement without DHCP procedure, which means the change of anchor without triggering any DHCP procedure. The scenario includes several hosts are attached a Bi Expires September 15, 2010 [Page 20] =0C Internet-Draft savi-dhcp March 2010 SAVI-Validation port through a hub, and the hub changes from its attaching port to another SAVI-Validation port. For handling this situation will necessarily lead to a data packet triggering procedure on SAVI device, and may violate the semantic of DHCP protocol, this situation is not handled in this solution. 20. MLD Consideration The SAVI device MUST join the tentative address multicast group whenever perform duplicate detection on behavior of host. 21. State Restoration If a SAVI device reboots accidentally or designedly, the states kept in volatile memory will get lost. This may cause hosts indirectly attached to the SAVI device to be broken away from the network, because they can't recover bindings on the SAVI device of themselves. Thus, it is SUGGESTED that binding entries can be saved into non- volatile storage manually or regularly. Immediately after reboot, the SAVI device can restore binding states from the non-volatile storage. 22. Data Triggered Process If an anchor is set to have SAVI-DataTrigger attribute, data packet, including DHCP, ARP and NDP messages whose source address is not bound with the anchor, is not filtered directly; instead, the SAVI device will check whether the address can be used by the client on the local link: 1. If the address has a local conflict, meaning the address is currently bound with another anchor on the device, the packet SHOULD be discarded. If not choosing to discard the packet, the device MUST check the address is being used by the previous client through sending a detection probe (ARP request or NS) to the client. If the address is not being used, go to the next step; otherwise discard the packet. 2. IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying by IP address to all DHCPv4 servers for IPv4 address or a configured server = address. The server addresses may be discovered through DHCPv4 Discovery. If no DHCPLEASEACTIVE message is received, discard the packet; otherwise generate a new binding entry for the address. IPv6 address: Bi Expires September 15, 2010 [Page 21] =0C Internet-Draft savi-dhcp March 2010 Send a LEASEQUERY [RFC5007] message querying by IP address to All_DHCP_Relay_Agents_and_Servers multicast address or a configured server address. If no successful LEASEQUERY-REPLY is received, discard the packet; otherwise generate a new binding entry for the address. The SAVI device may repeat this process if a LEASEQUERY-REPLY with OPTION_CLIENT_LINK is received, in order to set up binding entries for all the address of the client. The data triggered process MUST be rate limited to avoid Denial of Services attack against the SAVI device itself. Data triggered process will fail if no DHCP server supports LEASEQUERY. 23. Stateless DHCP In a stateless DHCP scenario [RFC3736], DHCP is used to configure other parameters but rather IP address. The address of the client SHOULD be bound based on other SAVI solutions, but rather this solution designed for stateful DHCP. 24. Confirm Triggered Binding If a binding entry is triggered by a CONFIRM message from the client, no lease time will be contained in the REPLY from DHCP server. The SAVI device MUST send LEASEQUERY message to get the lease time of the address to complete the binding entry. If no successful LEASEQUERY- REPLY is received, the binding entry SHOULD be removed. In this scenario, the address is not regarded as assigned by DHCP, and it may be bound through other SAVI solution. 25. Constants MAX_DHCP_RESPONSE_TIME 120s MAX_ARP_PREPARE_DELAY Default 1s but configurable MAX_ARP_DELAY Default 1s but configurable MAX_DAD_PREPARE_DELAY Default 1s but configurable MAX_DAD_DELAY Default 1s but configurable 26. Security Considerations For prefix level granularity filtering is the basis of host level granularity filtering, to learn and configure correct prefix is of Bi Expires September 15, 2010 [Page 22] =0C Internet-Draft savi-dhcp March 2010 great importance to this mechanism. Thus, it's important to keep RA and DHCP-PD secure. [draft-ietf-v6ops-ra-guard-03] describes a mechanism to improve the security of RA message. 27. IANA Considerations There is no IANA consideration currently. 28. References 28.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 28.2. Informative References [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131, March 1997. [RFC3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast Addresses", RFC3307, August 2002. [RFC3315] R. Droms, Ed. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC3315, July 2003. [RFC4388] R. Woundy and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC4388, February 2006. [RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC4861, September = 2007. [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless Autoconfiguration", RFC4862, September, 2007. [RFC5007] J. Brzozowski, K. Kinnear, B. Volz, S. Zeng, "DHCPv6 Leasequery", RFC5007, September 2007. [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, July 2008. 29. Acknowledgments Thanks to Christian Vogt, Eric Levy-Abegnoli, Mark Williams, Erik Nordmark, Marcelo Bagnulo Braun, Alberto Garcia, Jari Arkko, David Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert Raszuk, Greg Daley, Joel M. Halpern, Mikael Abrahamsson and Tao Lin for their Bi Expires September 15, 2010 [Page 23] =0C Internet-Draft savi-dhcp March 2010 valuable contributions. Bi Expires September 15, 2010 [Page 24] =0C Internet-Draft savi-dhcp March 2010 Authors' Addresses Jun Bi CERNET Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@cernet.edu.cn Jianping Wu CERNET Computer Science, Tsinghua University Beijing 100084 China Email: jianping@cernet.edu.cn Guang Yao CERNET Network Research Center, Tsinghua University Beijing 100084 China Email: yaog@netarchlab.tsinghua.edu.cn Fred Baker Cisco Systems Email: fred@cisco.com Bi Expires September 15, 2010 [Page 25] =0C ------=_NextPart_000_0543_01CAC47B.DB0B8FF0-- From junbi@cernet.edu.cn Mon Mar 15 05:41:24 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BBDE3A6940 for ; Mon, 15 Mar 2010 05:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmUyL4XOX2Rt for ; Mon, 15 Mar 2010 05:41:22 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id B7CBE3A677D for ; Mon, 15 Mar 2010 05:19:40 -0700 (PDT) Received: from junbiVAIO([59.66.24.139]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm2d4b9e98be; Mon, 15 Mar 2010 20:19:42 +0800 Message-ID: <231D9821F3704A09BCB0B166137AA034@junbiVAIO> From: "Bi Jun" To: "marcelo bagnulo braun" , References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es> <4B9E1BF3.9080709@it.uc3m.es> In-Reply-To: <4B9E1BF3.9080709@it.uc3m.es> Date: Mon, 15 Mar 2010 20:19:45 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: UCoQJrXB Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 12:41:24 -0000 Hi Marcelo, The sentence is misleading. "So, the situation is that if the triggering of the binding creation by data packet si not implemented, a legitimate user will be disconnected " It only happens for some situations. If the "MUST" only handles some situation but bring *much more* cost to the device (it's really because the data-triggered solution is not a low cost action), then I think the right ways: 1 "MUST" for all cases, and list some limitation and guide the users. 2 "Options" for some special cases, users has the guide to buy the higher-end device if they want more flexible use of savi device, (certainly, by paying higher price for the device.). That's my answer to all your similar questions. thanks, Jun Bi -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Monday, March 15, 2010 7:37 PM To: Subject: Re: [savi] call for comments: savi-dhcp-01 > Hi Mikael, > > sorry for the delay, been away for a few days > > below... > > El 09/03/10 10:46, Mikael Abrahamsson escribió: >> On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: >> >>> but this is what we qualify as a must in the ietf terminology. If you >>> don't do this, the network breaks in different ways, right? >> >> I don't agree that this is a must. This breakage is limited to certain >> operational concerns, it's not a fundamental problem that makes it not >> work at all. >> > Let's go back to RFC 2119 where the usage of these terms is defines: > RFC2119 reads: > > * * > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > > So, the situation is that if the triggering of the binding creation by > data packet si not implemented, a legitimate user will be disconnected > from the network in case the state is loss or in case a failure results in > a change in the topology. So this actually affects interoperability. > > The alternative would be a SHOULD properly qualified. > > I think that for the SLAAC/ND case, it is much more likely that the > situation occurs (due to packet loss and the non reliable nature of the > DAD procedure), so i really think that the triggering of the SAVI binding > creation process upon the recpetion of data packets should be a MUST. > > For the dhcp case, the cases in whcih this fails are reduced because of > the reliable nature of the dhcp exchange, so while i would rather go for a > MUST, i think i can live with a SHOULD. >> One can make the argument that this is a risk taken by the entity that >> chooses to deploy SAVI partially and that SAVI mandates things that are >> needed for a totally SAVI enabled network where all devices have this, >> and in the case not all of them have SAVI functionality, then things will >> break unless a MAY or SHOULD clause is implemented? >> > No, a MAY is something that is completelly optional and would not affect > interop in any way. > > As i said above, in the case of dhcp, if the SHOULD is properly qualified, > i could live with that. > > >> I don't like the situation where some vendors might not offer SAVI at >> all, to handle the problem you're describing. >> > Right, i do have this concern as well, but i am very worried about the > impact to the overall robustness fo the network. > > Regards, marcelo > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@cernet.edu.cn Mon Mar 15 05:46:37 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C21E3A6C2C for ; Mon, 15 Mar 2010 05:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_05=-1.11, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqJ3Mwm9rMew for ; Mon, 15 Mar 2010 05:46:35 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 6B4E23A6CB1 for ; Mon, 15 Mar 2010 05:26:49 -0700 (PDT) Received: from junbiVAIO([59.66.24.139]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm124b9e9a6e; Mon, 15 Mar 2010 20:26:54 +0800 Message-ID: <019C6F3B5F9C4B9F816588E35A440555@junbiVAIO> From: "Bi Jun" To: "marcelo bagnulo braun" References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> In-Reply-To: <4B9E2382.8000304@it.uc3m.es> Date: Mon, 15 Mar 2010 20:26:56 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: U9mXJrXB Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 12:46:37 -0000 Hi Marcelo, We can guide the users in this document or in framework, if you want to put a hub between savi-device or your host, please buy an more expensive savi-device that implemented the xxx options functions (e.g the data triggered functions listed in savi-dhcp-02, or another solution document). thanks, Jun -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Monday, March 15, 2010 8:09 PM To: "Bi Jun" Cc: "SAVI Mailing List" Subject: the impact of SAVI in the overall network robustness (was Re: [savi] dealing with topology changes in dhcp savi > Hi Jun, > > sorry for the delay, i was away for a few days. > > Ok, let me rephrase my question then. > > Suppose that you have the topology that is depicted below, > with multiple redundant switches to benefit from robustness. > My point is that the introduction of SAVI that is unable to > cope with data packets for which there is no binding will > reduce the robustness of the network, even if network > has been designed to be redundant. > > In the case SAVI is being deployed in a switched Ethernet network, > failures in a single device changes may result in a SAVI device > receiving packets from a > legitimate user for which the SAVI device does not have a binding > for. Consider the following example: > > > > +------+ +--------+ +---------------+ > |SAVI I|-------------|SWITCH I|-------|rest of the net| > +------+ +--------+ +---------------+ > | | > | +--------+ > | | SAVI II| > | +--------+ > | +----------+ | > +---|SWITCH II |-----+ > +----------+ > | > +-----+ > | Host| > +-----+ > > > The DHCP server is located in the part called rest of the network. > Suppose that after bootstrapping all the elements are working > properly and the spanning tree is rooted in the router and it > includes one branch that goes SWITCH I-SAVI I- SWITCH II and another > branch that goes SWITCH I-SAVI II. > > Suppose that the Host boots at this moment and perfomrs the DHCP > sxchange. > The message is propagated through the spanning tree and it received > by SAVI I but not by SAVI II. Same happens with the reply. > SAVI I creates the binding. > > Suppose that SAVI I fails and the spanning tree reconverges to SWITCH > I- SAVI II- SWITCH II. Now data packets coming from the Host will be > coursed through SAVI II which does not have binding state and will > drop the packets. > > Comments? > > Regards, marcelo > > > > El 09/03/10 11:47, Bi Jun escribió: >> Hi Marcelo, >> >> Since you are entitled "topology change", I want to say sth. >> Based on our operational experience, if we do a planed topology change, >> then we have to plan we will have more serious problem than this. >> So topology change in an operational network is usually carefully planed. >> We don't do it very often, and once we do it, we will let users >> understand us. >> >> So I don't see a problem of planed topology change. The only thing is the >> power-down >> of a switch, which is really a low frequency event in an operational >> network. If we found the power down, we will also inform users (only >> users under that switch will be affected, not all users will be affect) >> that if you had any problem thank you please renew your connection. >> >> thanks, >> Jun Bi >> >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Tuesday, March 09, 2010 3:51 PM >> To: "SAVI Mailing List" >> Subject: [savi] dealing with topology changes in dhcp savi >> >>> Hi, >>> >>> I have another question about dhcp save >>> >>> How do you handle the following situation? >>> >>> In the case SAVI is being deployed in a switched Ethernet network, >>> topology changes may result in a SAVI device receiving packets from a >>> legitimate user for which the SAVI device does not have a binding >>> for. Consider the following example: >>> >>> >>> >>> +------+ +--------+ +---------------+ >>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>> +------+ +--------+ +---------------+ >>> | | >>> | +--------+ >>> | | SAVI II| >>> | +--------+ >>> | +----------+ | >>> +---|SWITCH II |-----+ >>> +----------+ >>> | >>> +-----+ >>> | Host| >>> +-----+ >>> >>> >>> The DHCP server is located in the part called rest of the network. >>> Suppose that after bootstrapping all the elements are working >>> properly and the spanning tree is rooted in the router and it >>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and another >>> branch that goes SWITCH I-SAVI II. >>> >>> Suppose that the Host boots at this moment and perfomrs the DHCP >>> sxchange. >>> The message is propagated through the spanning tree and it received >>> by SAVI I but not by SAVI II. Same happens with the reply. >>> SAVI I creates the binding. >>> >>> Suppose that SAVI I fails and the spanning tree reconverges to SWITCH >>> I- SAVI II- SWITCH II. Now data packets coming from the Host will be >>> coursed through SAVI II which does not have binding state and will >>> drop the packets. >>> >>> Regards, marcelo >>> >>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> > From elevyabe@cisco.com Mon Mar 15 06:04:29 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6B2E3A69BE for ; Mon, 15 Mar 2010 06:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDHhr2AeXyMF for ; Mon, 15 Mar 2010 06:04:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 551C03A6B99 for ; Mon, 15 Mar 2010 05:57:46 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALfLnUurR7Hu/2dsb2JhbACacXOfCpdYhHsEjkQ X-IronPort-AV: E=Sophos;i="4.49,643,1262563200"; d="scan'208";a="496755358" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 15 Mar 2010 12:57:54 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2FCvk8D024052; Mon, 15 Mar 2010 12:57:53 GMT Received: from xmb-ams-105.cisco.com ([144.254.74.80]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 13:57:50 +0100 Received: from [144.254.53.100] ([144.254.53.100]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 13:57:50 +0100 Message-ID: <4B9E2ECD.7080504@cisco.com> Date: Mon, 15 Mar 2010 13:57:49 +0100 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bi Jun References: <09741A6EA86846049A114B745EE24C37@junbiVAIO> In-Reply-To: <09741A6EA86846049A114B745EE24C37@junbiVAIO> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Mar 2010 12:57:50.0142 (UTC) FILETIME=[1E2845E0:01CAC43F] Cc: SAVI Mailing List Subject: Re: [savi] savi-dhcp-02 draft X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 13:04:29 -0000 Bi Jun a écrit : > > Hi all, > > This is a revised version of savi-dhcp (revised based on the > discussion of dhcp-01 on the mailing-list in the past week), > basically, make the control packet-triggered functions as MUST (low > cost to be implemented in every switch), and have the data-triggered > functions (more complex to be implemented) as optional for higher-end > switches (to enable more flexible use of savi device). > > We are consulting the vendors on the cost for those options. > > please give us your comments. > > thanks, > Jun Bi SAVI J. > Bi, J. Wu Hi Jun bi, Reading the below: "IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP address to All_DHCP_Relay_Agents_and_Servers multicast address or a configured server address. If no successful LEASEQUERY-REPLY is received, discard the packet; otherwise generate a new binding entry for the address. The SAVI device may repeat this process if a LEASEQUERY-REPLY with OPTION_CLIENT_LINK is received, in order to set up binding entries for all the address of the client." I don't think the below proposal to discover IPv6 address from the savi device works. DHCP messages must be sourced with an IPv6 address (can't be UNSPEC, must be a link-local) and in most cases, the switch does not have any. That would take the switch to have a L3 interface that participate in the link operations (for each of its vlans), and that is a huge constrain. I have real deployment examples of pure L2 switch devices with thousands of vlans configured (hundreds of ports in each vlan). Getting a L3 address in each vlan would have a huge impact on the switch operations and performances.That does not seem acceptable. I think the only option is to discover the binding by probing with a NDP DAD NS. This one is sourced with UNSPEC and hence is accpetable for a L2 device. Then install the binding as learnt from NDP. And later, "prefer" the DHCP binding when/if it shows up. Eric From yaoa02@mails.tsinghua.edu.cn Mon Mar 15 06:25:25 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6993A67A3 for ; Mon, 15 Mar 2010 06:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ezp-mgSix-LW for ; Mon, 15 Mar 2010 06:25:24 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 57D9C3A69A1 for ; Mon, 15 Mar 2010 06:24:35 -0700 (PDT) Received: from th211043.ip.tsinghua.edu.cn ([59.66.211.43] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NrAHd-00031F-12 for savi@ietf.org; Mon, 15 Mar 2010 21:24:37 +0800 From: "Guang Yao" To: References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es> <4B9E1BF3.9080709@it.uc3m.es> In-Reply-To: <4B9E1BF3.9080709@it.uc3m.es> Date: Mon, 15 Mar 2010 21:24:29 +0800 Message-ID: <000901cac442$d7967d50$86c377f0$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrEN2MyrM5DDe2CQviC+qL9Q9bYrgACE90g Content-Language: zh-cn Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 13:25:25 -0000 Hi Marcelo, Venture to say, it is impossible to persuade everyone, because neither choices take absolute advantage. This problem is obviously just a = tradeoff. Someone value robustness and some others values performance. I sincerely suggest, leave the choice to be made by the vendors and = network administrators. The solution doesn't have to restrict every = implementation and deployment to be exactly the same. "One man's meat is another man's poison". Please just make out the outcome of what if it is done, and the outcome of what if it is not done. Please just end this endless debate and move forward in the savi-slaac. = 2012 is near :). BR, Guang > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf = Of > marcelo bagnulo braun > Sent: Monday, March 15, 2010 7:37 PM > To: savi@ietf.org > Subject: Re: [savi] call for comments: savi-dhcp-01 >=20 > Hi Mikael, >=20 > sorry for the delay, been away for a few days >=20 > below... >=20 > El 09/03/10 10:46, Mikael Abrahamsson escribi=F3: > > On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: > > > >> but this is what we qualify as a must in the ietf terminology. If = you > >> don't do this, the network breaks in different ways, right? > > > > I don't agree that this is a must. This breakage is limited to = certain > > operational concerns, it's not a fundamental problem that makes it = not > > work at all. > > > Let's go back to RFC 2119 where the usage of these terms is defines: > RFC2119 reads: >=20 > * * >=20 > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. >=20 > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. >=20 >=20 > So, the situation is that if the triggering of the binding creation by > data packet si not implemented, a legitimate user will be disconnected > from the network in case the state is loss or in case a failure = results > in a change in the topology. So this actually affects = interoperability. >=20 > The alternative would be a SHOULD properly qualified. >=20 > I think that for the SLAAC/ND case, it is much more likely that the > situation occurs (due to packet loss and the non reliable nature of = the > DAD procedure), so i really think that the triggering of the SAVI > binding creation process upon the recpetion of data packets should be = a > MUST. >=20 > For the dhcp case, the cases in whcih this fails are reduced because = of > the reliable nature of the dhcp exchange, so while i would rather go = for > a MUST, i think i can live with a SHOULD. > > One can make the argument that this is a risk taken by the entity = that > > chooses to deploy SAVI partially and that SAVI mandates things that > > are needed for a totally SAVI enabled network where all devices have > > this, and in the case not all of them have SAVI functionality, then > > things will break unless a MAY or SHOULD clause is implemented? > > > No, a MAY is something that is completelly optional and would not = affect > interop in any way. >=20 > As i said above, in the case of dhcp, if the SHOULD is properly > qualified, i could live with that. >=20 >=20 > > I don't like the situation where some vendors might not offer SAVI = at > > all, to handle the problem you're describing. > > > Right, i do have this concern as well, but i am very worried about the > impact to the overall robustness fo the network. >=20 > Regards, marcelo >=20 > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From yaoa02@mails.tsinghua.edu.cn Mon Mar 15 06:42:43 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFDE33A6976 for ; Mon, 15 Mar 2010 06:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91kH5PkNHWtX for ; Mon, 15 Mar 2010 06:42:39 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 09EDB3A6954 for ; Mon, 15 Mar 2010 06:42:35 -0700 (PDT) Received: from th211043.ip.tsinghua.edu.cn ([59.66.211.43] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NrAZ2-0003LF-P1; Mon, 15 Mar 2010 21:42:36 +0800 From: "Guang Yao" To: "'Eric Levy-Abegnoli'" , "'Bi Jun'" References: <09741A6EA86846049A114B745EE24C37@junbiVAIO> <4B9E2ECD.7080504@cisco.com> In-Reply-To: <4B9E2ECD.7080504@cisco.com> Date: Mon, 15 Mar 2010 21:42:29 +0800 Message-ID: <000a01cac445$5b2465e0$116d31a0$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrEP9IUboWZUyQQRUCt0ribcSsrnwABAo1w Content-Language: zh-cn Cc: 'SAVI Mailing List' Subject: Re: [savi] savi-dhcp-02 draft X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 13:42:43 -0000 Hi Eric, Thanks for your suggestion. Your experience is very valuable. In this solution, sending DHCP lease query is optional, just to handle = some special cases (in general, data triggered but rather control packet). It = is not required to be enabled. Vendors may choose to implement it on layer = 3 device but not pure layer 2 device. And network administrators may not enable this function if they find the device may be overloaded. If binding is learnt from NDP, IMO it should be bound in savi-slaac, but = not in this solution for DHCP. And the which to prefer in case of = co-existing of NDP and DHCP, I think should be specified in the framework doc. Am I = right? BR, Guang > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf = Of Eric > Levy-Abegnoli > Sent: Monday, March 15, 2010 8:58 PM > To: Bi Jun > Cc: SAVI Mailing List > Subject: Re: [savi] savi-dhcp-02 draft >=20 > Bi Jun a =E9crit : > > > > Hi all, > > > > This is a revised version of savi-dhcp (revised based on the > > discussion of dhcp-01 on the mailing-list in the past week), > > basically, make the control packet-triggered functions as MUST (low > > cost to be implemented in every switch), and have the data-triggered > > functions (more complex to be implemented) as optional for = higher-end > > switches (to enable more flexible use of savi device). > > > > We are consulting the vendors on the cost for those options. > > > > please give us your comments. > > > > thanks, > > Jun Bi SAVI > J. > > Bi, J. Wu >=20 > Hi Jun bi, > Reading the below: >=20 > "IPv6 address: > Send a LEASEQUERY [RFC5007] message querying by IP address to > All_DHCP_Relay_Agents_and_Servers multicast address or a > configured server address. If no successful LEASEQUERY-REPLY is > received, discard the packet; otherwise generate a new binding > entry for the address. The SAVI device may repeat this process = if > a LEASEQUERY-REPLY with OPTION_CLIENT_LINK is received, in order > to set up binding entries for all the address of the client." >=20 > I don't think the below proposal to discover IPv6 address from the = savi > device works. DHCP messages must be sourced with an IPv6 address = (can't > be UNSPEC, must be a link-local) and in most cases, the switch does = not > have any. That would take the switch to have a L3 interface that > participate in the link operations (for each of its vlans), and that = is > a huge constrain. > I have real deployment examples of pure L2 switch devices with = thousands > of vlans configured (hundreds of ports in each vlan). Getting a L3 > address in each vlan would have a huge impact on the switch operations > and performances.That does not seem acceptable. > I think the only option is to discover the binding by probing with a = NDP > DAD NS. This one is sourced with UNSPEC and hence is accpetable for a = L2 > device. Then install the binding as learnt from NDP. And later, > "prefer" the DHCP binding when/if it shows up. > Eric >=20 >=20 > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From marcelo@it.uc3m.es Mon Mar 15 06:54:44 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69BEA3A695F for ; Mon, 15 Mar 2010 06:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.429 X-Spam-Level: X-Spam-Status: No, score=-106.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnKPCdedGKsu for ; Mon, 15 Mar 2010 06:54:43 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 612103A65A6 for ; Mon, 15 Mar 2010 06:54:38 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id B2EB66C6A21; Mon, 15 Mar 2010 14:54:44 +0100 (CET) Message-ID: <4B9E3C24.5060504@it.uc3m.es> Date: Mon, 15 Mar 2010 14:54:44 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Bi Jun References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> <019C6F3B5F9C4B9F816588E35A440555@junbiVAIO> In-Reply-To: <019C6F3B5F9C4B9F816588E35A440555@junbiVAIO> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 13:54:44 -0000 So, if you do discard the packets for which there is no binding, the overall network robustness is worse, in particular settings where a redundant topology has been set. This seems quite severe to me. Regards, marcelo El 15/03/10 13:26, Bi Jun escribió: > Hi Marcelo, > > We can guide the users in this document or in framework, > if you want to put a hub between savi-device or your host, please buy > an more expensive savi-device that implemented the xxx options > functions (e.g the data triggered functions listed in savi-dhcp-02, or > another solution document). > > thanks, > Jun > > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Monday, March 15, 2010 8:09 PM > To: "Bi Jun" > Cc: "SAVI Mailing List" > Subject: the impact of SAVI in the overall network robustness (was Re: > [savi] dealing with topology changes in dhcp savi > >> Hi Jun, >> >> sorry for the delay, i was away for a few days. >> >> Ok, let me rephrase my question then. >> >> Suppose that you have the topology that is depicted below, >> with multiple redundant switches to benefit from robustness. >> My point is that the introduction of SAVI that is unable to >> cope with data packets for which there is no binding will >> reduce the robustness of the network, even if network >> has been designed to be redundant. >> >> In the case SAVI is being deployed in a switched Ethernet network, >> failures in a single device changes may result in a SAVI device >> receiving packets from a >> legitimate user for which the SAVI device does not have a binding >> for. Consider the following example: >> >> >> >> +------+ +--------+ +---------------+ >> |SAVI I|-------------|SWITCH I|-------|rest of the net| >> +------+ +--------+ +---------------+ >> | | >> | +--------+ >> | | SAVI II| >> | +--------+ >> | +----------+ | >> +---|SWITCH II |-----+ >> +----------+ >> | >> +-----+ >> | Host| >> +-----+ >> >> >> The DHCP server is located in the part called rest of the network. >> Suppose that after bootstrapping all the elements are working >> properly and the spanning tree is rooted in the router and it >> includes one branch that goes SWITCH I-SAVI I- SWITCH II and another >> branch that goes SWITCH I-SAVI II. >> >> Suppose that the Host boots at this moment and perfomrs the DHCP >> sxchange. >> The message is propagated through the spanning tree and it received >> by SAVI I but not by SAVI II. Same happens with the reply. >> SAVI I creates the binding. >> >> Suppose that SAVI I fails and the spanning tree reconverges to SWITCH >> I- SAVI II- SWITCH II. Now data packets coming from the Host will be >> coursed through SAVI II which does not have binding state and will >> drop the packets. >> >> Comments? >> >> Regards, marcelo >> >> >> >> El 09/03/10 11:47, Bi Jun escribió: >>> Hi Marcelo, >>> >>> Since you are entitled "topology change", I want to say sth. >>> Based on our operational experience, if we do a planed topology change, >>> then we have to plan we will have more serious problem than this. >>> So topology change in an operational network is usually carefully >>> planed. >>> We don't do it very often, and once we do it, we will let users >>> understand us. >>> >>> So I don't see a problem of planed topology change. The only thing >>> is the power-down >>> of a switch, which is really a low frequency event in an operational >>> network. If we found the power down, we will also inform users (only >>> users under that switch will be affected, not all users will be >>> affect) that if you had any problem thank you please renew your >>> connection. >>> >>> thanks, >>> Jun Bi >>> >>> -------------------------------------------------- >>> From: "marcelo bagnulo braun" >>> Sent: Tuesday, March 09, 2010 3:51 PM >>> To: "SAVI Mailing List" >>> Subject: [savi] dealing with topology changes in dhcp savi >>> >>>> Hi, >>>> >>>> I have another question about dhcp save >>>> >>>> How do you handle the following situation? >>>> >>>> In the case SAVI is being deployed in a switched Ethernet network, >>>> topology changes may result in a SAVI device receiving packets >>>> from a >>>> legitimate user for which the SAVI device does not have a binding >>>> for. Consider the following example: >>>> >>>> >>>> >>>> +------+ +--------+ +---------------+ >>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>> +------+ +--------+ +---------------+ >>>> | | >>>> | +--------+ >>>> | | SAVI II| >>>> | +--------+ >>>> | +----------+ | >>>> +---|SWITCH II |-----+ >>>> +----------+ >>>> | >>>> +-----+ >>>> | Host| >>>> +-----+ >>>> >>>> >>>> The DHCP server is located in the part called rest of the network. >>>> Suppose that after bootstrapping all the elements are working >>>> properly and the spanning tree is rooted in the router and it >>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and >>>> another >>>> branch that goes SWITCH I-SAVI II. >>>> >>>> Suppose that the Host boots at this moment and perfomrs the DHCP >>>> sxchange. >>>> The message is propagated through the spanning tree and it received >>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>> SAVI I creates the binding. >>>> >>>> Suppose that SAVI I fails and the spanning tree reconverges to >>>> SWITCH >>>> I- SAVI II- SWITCH II. Now data packets coming from the Host >>>> will be >>>> coursed through SAVI II which does not have binding state and will >>>> drop the packets. >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>> >> > From marcelo@it.uc3m.es Mon Mar 15 06:59:52 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAE9E3A67EE for ; Mon, 15 Mar 2010 06:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.446 X-Spam-Level: X-Spam-Status: No, score=-106.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7emFJWae6mFD for ; Mon, 15 Mar 2010 06:59:51 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 28AE63A6768 for ; Mon, 15 Mar 2010 06:59:50 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id BECC57F42D9; Mon, 15 Mar 2010 14:59:56 +0100 (CET) Message-ID: <4B9E3D5C.6040600@it.uc3m.es> Date: Mon, 15 Mar 2010 14:59:56 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Bi Jun References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es> <4B9E1BF3.9080709@it.uc3m.es> <231D9821F3704A09BCB0B166137AA034@junbiVAIO> In-Reply-To: <231D9821F3704A09BCB0B166137AA034@junbiVAIO> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 13:59:52 -0000 El 15/03/10 13:19, Bi Jun escribió: > Hi Marcelo, > > The sentence is misleading. > "So, the situation is that if the triggering of the binding creation by > data packet si not implemented, a legitimate user will be disconnected " > > It only happens for some situations. Right, it only happen in some situation, but that is what robustness is about, right? I mean, this affects interoperability, becuase it may happen that the communication of a legitimate host is interrupted due to this. > If the "MUST" only handles some situation but bring *much more* cost > to the device (it's really because the data-triggered solution is not > a low cost action), > then I think the right ways: > > 1 "MUST" for all cases, and list some limitation and guide the users. > 2 "Options" for some special cases, users has the guide to buy the > higher-end device > if they want more flexible use of savi device, (certainly, by paying > higher price for the device.). > As i said, i don't think in any case this is optional. IMHO, this is a MUST becuase it affect interoperability. If there is no consensus to go for a MUST, i can live with, for the dhcp case and only for the dhcp case, since the subset of problematic cases is more limited than the ND case, we could use a qualified SHOULD, which means that the implementation SHOULD do that and we explian what happens if they don't. How about that? Regards, marcelo > That's my answer to all your similar questions. > > thanks, > Jun Bi > > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Monday, March 15, 2010 7:37 PM > To: > Subject: Re: [savi] call for comments: savi-dhcp-01 > >> Hi Mikael, >> >> sorry for the delay, been away for a few days >> >> below... >> >> El 09/03/10 10:46, Mikael Abrahamsson escribió: >>> On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: >>> >>>> but this is what we qualify as a must in the ietf terminology. If >>>> you don't do this, the network breaks in different ways, right? >>> >>> I don't agree that this is a must. This breakage is limited to >>> certain operational concerns, it's not a fundamental problem that >>> makes it not work at all. >>> >> Let's go back to RFC 2119 where the usage of these terms is defines: >> RFC2119 reads: >> >> * * >> >> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the >> definition is an absolute requirement of the specification. >> >> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there >> may exist valid reasons in particular circumstances to ignore a >> particular item, but the full implications must be understood and >> carefully weighed before choosing a different course. >> >> >> So, the situation is that if the triggering of the binding creation >> by data packet si not implemented, a legitimate user will be >> disconnected from the network in case the state is loss or in case a >> failure results in a change in the topology. So this actually affects >> interoperability. >> >> The alternative would be a SHOULD properly qualified. >> >> I think that for the SLAAC/ND case, it is much more likely that the >> situation occurs (due to packet loss and the non reliable nature of >> the DAD procedure), so i really think that the triggering of the SAVI >> binding creation process upon the recpetion of data packets should be >> a MUST. >> >> For the dhcp case, the cases in whcih this fails are reduced because >> of the reliable nature of the dhcp exchange, so while i would rather >> go for a MUST, i think i can live with a SHOULD. >>> One can make the argument that this is a risk taken by the entity >>> that chooses to deploy SAVI partially and that SAVI mandates things >>> that are needed for a totally SAVI enabled network where all devices >>> have this, and in the case not all of them have SAVI functionality, >>> then things will break unless a MAY or SHOULD clause is implemented? >>> >> No, a MAY is something that is completelly optional and would not >> affect interop in any way. >> >> As i said above, in the case of dhcp, if the SHOULD is properly >> qualified, i could live with that. >> >> >>> I don't like the situation where some vendors might not offer SAVI >>> at all, to handle the problem you're describing. >>> >> Right, i do have this concern as well, but i am very worried about >> the impact to the overall robustness fo the network. >> >> Regards, marcelo >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > From marcelo@it.uc3m.es Mon Mar 15 07:03:09 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9B23A6990 for ; Mon, 15 Mar 2010 07:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.46 X-Spam-Level: X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiCZsVNKuxJL for ; Mon, 15 Mar 2010 07:03:04 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 18F1E3A65A6 for ; Mon, 15 Mar 2010 07:02:51 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 029D87F7529 for ; Mon, 15 Mar 2010 15:02:58 +0100 (CET) Message-ID: <4B9E3E11.8080403@it.uc3m.es> Date: Mon, 15 Mar 2010 15:02:57 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: savi@ietf.org References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es> <4B9E1BF3.9080709@it.uc3m.es> <000901cac442$d7967d50$86c377f0$@tsinghua.edu.cn> In-Reply-To: <000901cac442$d7967d50$86c377f0$@tsinghua.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 14:03:09 -0000 I beg to differ. My concern is that if we simply drop the packets for which there is no binding, the overall network robustness will be affected. And our duty as IETF is to properly design protocols to make the Internet work in a reliable manner. If vendors want to implement solutions that break the internet they can do it, but they don't get to do that using an IETF RFC number (or at least they shouldn't) Regards, marcelo El 15/03/10 14:24, Guang Yao escribió: > Hi Marcelo, > > Venture to say, it is impossible to persuade everyone, because neither > choices take absolute advantage. This problem is obviously just a tradeoff. > Someone value robustness and some others values performance. > > I sincerely suggest, leave the choice to be made by the vendors and network > administrators. The solution doesn't have to restrict every implementation > and deployment to be exactly the same. "One man's meat is another man's > poison". Please just make out the outcome of what if it is done, and the > outcome of what if it is not done. > > Please just end this endless debate and move forward in the savi-slaac. 2012 > is near :). > > BR, > Guang > > >> -----Original Message----- >> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of >> marcelo bagnulo braun >> Sent: Monday, March 15, 2010 7:37 PM >> To: savi@ietf.org >> Subject: Re: [savi] call for comments: savi-dhcp-01 >> >> Hi Mikael, >> >> sorry for the delay, been away for a few days >> >> below... >> >> El 09/03/10 10:46, Mikael Abrahamsson escribió: >> >>> On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: >>> >>> >>>> but this is what we qualify as a must in the ietf terminology. If you >>>> don't do this, the network breaks in different ways, right? >>>> >>> I don't agree that this is a must. This breakage is limited to certain >>> operational concerns, it's not a fundamental problem that makes it not >>> work at all. >>> >>> >> Let's go back to RFC 2119 where the usage of these terms is defines: >> RFC2119 reads: >> >> * * >> >> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the >> definition is an absolute requirement of the specification. >> >> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there >> may exist valid reasons in particular circumstances to ignore a >> particular item, but the full implications must be understood and >> carefully weighed before choosing a different course. >> >> >> So, the situation is that if the triggering of the binding creation by >> data packet si not implemented, a legitimate user will be disconnected >> from the network in case the state is loss or in case a failure results >> in a change in the topology. So this actually affects interoperability. >> >> The alternative would be a SHOULD properly qualified. >> >> I think that for the SLAAC/ND case, it is much more likely that the >> situation occurs (due to packet loss and the non reliable nature of the >> DAD procedure), so i really think that the triggering of the SAVI >> binding creation process upon the recpetion of data packets should be a >> MUST. >> >> For the dhcp case, the cases in whcih this fails are reduced because of >> the reliable nature of the dhcp exchange, so while i would rather go for >> a MUST, i think i can live with a SHOULD. >> >>> One can make the argument that this is a risk taken by the entity that >>> chooses to deploy SAVI partially and that SAVI mandates things that >>> are needed for a totally SAVI enabled network where all devices have >>> this, and in the case not all of them have SAVI functionality, then >>> things will break unless a MAY or SHOULD clause is implemented? >>> >>> >> No, a MAY is something that is completelly optional and would not affect >> interop in any way. >> >> As i said above, in the case of dhcp, if the SHOULD is properly >> qualified, i could live with that. >> >> >> >>> I don't like the situation where some vendors might not offer SAVI at >>> all, to handle the problem you're describing. >>> >>> >> Right, i do have this concern as well, but i am very worried about the >> impact to the overall robustness fo the network. >> >> Regards, marcelo >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > From elevyabe@cisco.com Mon Mar 15 07:15:35 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91343A69BD for ; Mon, 15 Mar 2010 07:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=-3.535, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdQPOuPR6nMd for ; Mon, 15 Mar 2010 07:15:34 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 7100B3A6B5B for ; Mon, 15 Mar 2010 07:13:12 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsBANLcnUuQ/uCWe2dsb2JhbACacRUBAQsLJAYcoB6XZIR7BI5E X-IronPort-AV: E=Sophos;i="4.49,643,1262563200"; d="scan'208";a="4350390" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 15 Mar 2010 13:39:44 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2FEDIBp009623; Mon, 15 Mar 2010 14:13:18 GMT Received: from xmb-ams-105.cisco.com ([144.254.74.80]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 15:13:18 +0100 Received: from [144.254.53.100] ([144.254.53.100]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 15:13:17 +0100 Message-ID: <4B9E407C.8000303@cisco.com> Date: Mon, 15 Mar 2010 15:13:16 +0100 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Guang Yao References: <09741A6EA86846049A114B745EE24C37@junbiVAIO> <4B9E2ECD.7080504@cisco.com> <000a01cac445$5b2465e0$116d31a0$@tsinghua.edu.cn> In-Reply-To: <000a01cac445$5b2465e0$116d31a0$@tsinghua.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Mar 2010 14:13:17.0780 (UTC) FILETIME=[A8D70140:01CAC449] Cc: 'SAVI Mailing List' Subject: Re: [savi] savi-dhcp-02 draft X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 14:15:35 -0000 Hi Guang, Guang Yao a écrit : > Hi Eric, > > Thanks for your suggestion. Your experience is very valuable. > > In this solution, sending DHCP lease query is optional, just to handle some > special cases (in general, data triggered but rather control packet). It is > not required to be enabled. Vendors may choose to implement it on layer 3 > device but not pure layer 2 device. And network administrators may not > enable this function if they find the device may be overloaded. > > If binding is learnt from NDP, IMO it should be bound in savi-slaac, but not > in this solution for DHCP. And the which to prefer in case of co-existing of > NDP and DHCP, I think should be specified in the framework doc. Am I right? > > BR, > Guang > What I meant is that the proposed method (sending a leasequery to re-discover a binding lost in case of the switch reboot) cannot be used as a "general" response to the problem raised. A switch, L2-only device, that looses its binding table and has no non-volatile memory has just no way to recover it thru DHCP. It's is unfortunate since DHCP is considered as the only authoritative method for discovering bindings. I would consider that at the stage, when DHCP is used, non-volatile memory is the only option. Eric > >> -----Original Message----- >> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of >> > Eric > >> Levy-Abegnoli >> Sent: Monday, March 15, 2010 8:58 PM >> To: Bi Jun >> Cc: SAVI Mailing List >> Subject: Re: [savi] savi-dhcp-02 draft >> >> Bi Jun a écrit : >> >>> Hi all, >>> >>> This is a revised version of savi-dhcp (revised based on the >>> discussion of dhcp-01 on the mailing-list in the past week), >>> basically, make the control packet-triggered functions as MUST (low >>> cost to be implemented in every switch), and have the data-triggered >>> functions (more complex to be implemented) as optional for higher-end >>> switches (to enable more flexible use of savi device). >>> >>> We are consulting the vendors on the cost for those options. >>> >>> please give us your comments. >>> >>> thanks, >>> Jun Bi SAVI >>> >> J. >> >>> Bi, J. Wu >>> >> Hi Jun bi, >> Reading the below: >> >> "IPv6 address: >> Send a LEASEQUERY [RFC5007] message querying by IP address to >> All_DHCP_Relay_Agents_and_Servers multicast address or a >> configured server address. If no successful LEASEQUERY-REPLY is >> received, discard the packet; otherwise generate a new binding >> entry for the address. The SAVI device may repeat this process if >> a LEASEQUERY-REPLY with OPTION_CLIENT_LINK is received, in order >> to set up binding entries for all the address of the client." >> >> I don't think the below proposal to discover IPv6 address from the savi >> device works. DHCP messages must be sourced with an IPv6 address (can't >> be UNSPEC, must be a link-local) and in most cases, the switch does not >> have any. That would take the switch to have a L3 interface that >> participate in the link operations (for each of its vlans), and that is >> a huge constrain. >> I have real deployment examples of pure L2 switch devices with thousands >> of vlans configured (hundreds of ports in each vlan). Getting a L3 >> address in each vlan would have a huge impact on the switch operations >> and performances.That does not seem acceptable. >> I think the only option is to discover the binding by probing with a NDP >> DAD NS. This one is sourced with UNSPEC and hence is accpetable for a L2 >> device. Then install the binding as learnt from NDP. And later, >> "prefer" the DHCP binding when/if it shows up. >> Eric >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > > From junbi@cernet.edu.cn Mon Mar 15 07:28:30 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A9D3A6840 for ; Mon, 15 Mar 2010 07:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbP6rKrNlrJe for ; Mon, 15 Mar 2010 07:28:29 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 5E6903A6891 for ; Mon, 15 Mar 2010 07:28:06 -0700 (PDT) Received: from junbiVAIO([59.66.24.139]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54b9eb6dc; Mon, 15 Mar 2010 22:28:12 +0800 Message-ID: From: "Bi Jun" To: "marcelo bagnulo braun" References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> <019C6F3B5F9C4B9F816588E35A440555@junbiVAIO> <4B9E3C24.5060504@it.uc3m.es> In-Reply-To: <4B9E3C24.5060504@it.uc3m.es> Date: Mon, 15 Mar 2010 22:28:07 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: UtKRLrXB Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 14:28:31 -0000 I meant please in the guideline, says that your host SHOULD be directly plug to the savi-device. If not, please purchase an higher-end savi-device that implemented the options. thanks, Jun -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Monday, March 15, 2010 9:54 PM To: "Bi Jun" Cc: "SAVI Mailing List" Subject: Re: the impact of SAVI in the overall network robustness (was Re: [savi] dealing with topology changes in dhcp savi > So, if you do discard the packets for which there is no binding, the > overall network robustness is worse, in particular settings where a > redundant topology has been set. > > This seems quite severe to me. > > Regards, marcelo > > > El 15/03/10 13:26, Bi Jun escribió: >> Hi Marcelo, >> >> We can guide the users in this document or in framework, >> if you want to put a hub between savi-device or your host, please buy an >> more expensive savi-device that implemented the xxx options functions >> (e.g the data triggered functions listed in savi-dhcp-02, or another >> solution document). >> >> thanks, >> Jun >> >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Monday, March 15, 2010 8:09 PM >> To: "Bi Jun" >> Cc: "SAVI Mailing List" >> Subject: the impact of SAVI in the overall network robustness (was Re: >> [savi] dealing with topology changes in dhcp savi >> >>> Hi Jun, >>> >>> sorry for the delay, i was away for a few days. >>> >>> Ok, let me rephrase my question then. >>> >>> Suppose that you have the topology that is depicted below, >>> with multiple redundant switches to benefit from robustness. >>> My point is that the introduction of SAVI that is unable to >>> cope with data packets for which there is no binding will >>> reduce the robustness of the network, even if network >>> has been designed to be redundant. >>> >>> In the case SAVI is being deployed in a switched Ethernet network, >>> failures in a single device changes may result in a SAVI device >>> receiving packets from a >>> legitimate user for which the SAVI device does not have a binding >>> for. Consider the following example: >>> >>> >>> >>> +------+ +--------+ +---------------+ >>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>> +------+ +--------+ +---------------+ >>> | | >>> | +--------+ >>> | | SAVI II| >>> | +--------+ >>> | +----------+ | >>> +---|SWITCH II |-----+ >>> +----------+ >>> | >>> +-----+ >>> | Host| >>> +-----+ >>> >>> >>> The DHCP server is located in the part called rest of the network. >>> Suppose that after bootstrapping all the elements are working >>> properly and the spanning tree is rooted in the router and it >>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and another >>> branch that goes SWITCH I-SAVI II. >>> >>> Suppose that the Host boots at this moment and perfomrs the DHCP >>> sxchange. >>> The message is propagated through the spanning tree and it received >>> by SAVI I but not by SAVI II. Same happens with the reply. >>> SAVI I creates the binding. >>> >>> Suppose that SAVI I fails and the spanning tree reconverges to SWITCH >>> I- SAVI II- SWITCH II. Now data packets coming from the Host will be >>> coursed through SAVI II which does not have binding state and will >>> drop the packets. >>> >>> Comments? >>> >>> Regards, marcelo >>> >>> >>> >>> El 09/03/10 11:47, Bi Jun escribió: >>>> Hi Marcelo, >>>> >>>> Since you are entitled "topology change", I want to say sth. >>>> Based on our operational experience, if we do a planed topology change, >>>> then we have to plan we will have more serious problem than this. >>>> So topology change in an operational network is usually carefully >>>> planed. >>>> We don't do it very often, and once we do it, we will let users >>>> understand us. >>>> >>>> So I don't see a problem of planed topology change. The only thing is >>>> the power-down >>>> of a switch, which is really a low frequency event in an operational >>>> network. If we found the power down, we will also inform users (only >>>> users under that switch will be affected, not all users will be affect) >>>> that if you had any problem thank you please renew your connection. >>>> >>>> thanks, >>>> Jun Bi >>>> >>>> -------------------------------------------------- >>>> From: "marcelo bagnulo braun" >>>> Sent: Tuesday, March 09, 2010 3:51 PM >>>> To: "SAVI Mailing List" >>>> Subject: [savi] dealing with topology changes in dhcp savi >>>> >>>>> Hi, >>>>> >>>>> I have another question about dhcp save >>>>> >>>>> How do you handle the following situation? >>>>> >>>>> In the case SAVI is being deployed in a switched Ethernet network, >>>>> topology changes may result in a SAVI device receiving packets from >>>>> a >>>>> legitimate user for which the SAVI device does not have a binding >>>>> for. Consider the following example: >>>>> >>>>> >>>>> >>>>> +------+ +--------+ +---------------+ >>>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>>> +------+ +--------+ +---------------+ >>>>> | | >>>>> | +--------+ >>>>> | | SAVI II| >>>>> | +--------+ >>>>> | +----------+ | >>>>> +---|SWITCH II |-----+ >>>>> +----------+ >>>>> | >>>>> +-----+ >>>>> | Host| >>>>> +-----+ >>>>> >>>>> >>>>> The DHCP server is located in the part called rest of the network. >>>>> Suppose that after bootstrapping all the elements are working >>>>> properly and the spanning tree is rooted in the router and it >>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and >>>>> another >>>>> branch that goes SWITCH I-SAVI II. >>>>> >>>>> Suppose that the Host boots at this moment and perfomrs the DHCP >>>>> sxchange. >>>>> The message is propagated through the spanning tree and it received >>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>> SAVI I creates the binding. >>>>> >>>>> Suppose that SAVI I fails and the spanning tree reconverges to >>>>> SWITCH >>>>> I- SAVI II- SWITCH II. Now data packets coming from the Host will >>>>> be >>>>> coursed through SAVI II which does not have binding state and will >>>>> drop the packets. >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>> >>> >> > From yaoa02@mails.tsinghua.edu.cn Mon Mar 15 07:34:49 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D18AE3A6879 for ; Mon, 15 Mar 2010 07:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEcd9I0EjED4 for ; Mon, 15 Mar 2010 07:34:47 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 18E963A65A6 for ; Mon, 15 Mar 2010 07:34:47 -0700 (PDT) Received: from th211043.ip.tsinghua.edu.cn ([59.66.211.43] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NrBNZ-0004Cl-IB for savi@ietf.org; Mon, 15 Mar 2010 22:34:49 +0800 From: "Guang Yao" To: "'SAVI Mailing List'" References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es> <4B9E1BF3.9080709@it.uc3m.es> <000901cac442$d7967d50$86c377f0$@tsinghua.edu.cn> <4B9E3E11.8080403@it.uc3m.es> In-Reply-To: <4B9E3E11.8080403@it.uc3m.es> Date: Mon, 15 Mar 2010 22:34:41 +0800 Message-ID: <001601cac44c$a64f64a0$f2ee2de0$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrESAckXnEkQHFjQlim4RxDH68TUAABI1gQ Content-Language: zh-cn Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 14:34:49 -0000 OK, I make a step backwards. What if requiring vendors to implement = both, but at least giving the right of choosing to network administrators? And I want to mention that, ingress filtering(RFC2827, RFC3704, BCP38, BCP84) is not a mechanism that wouldn't discard any " legitimate" = packet. It may also "break the internet". Why it has RFC numbers? BR, Guang > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf = Of > marcelo bagnulo braun > Sent: Monday, March 15, 2010 10:03 PM > To: savi@ietf.org > Subject: Re: [savi] call for comments: savi-dhcp-01 >=20 > I beg to differ. My concern is that if we simply drop the packets for > which there is no binding, the overall network robustness will be > affected. And our duty as IETF is to properly design protocols to make > the Internet work in a reliable manner. If vendors want to implement > solutions that break the internet they can do it, but they don't get = to > do that using an IETF RFC number (or at least they shouldn't) >=20 > Regards, marcelo >=20 > El 15/03/10 14:24, Guang Yao escribi=F3: > > Hi Marcelo, > > > > Venture to say, it is impossible to persuade everyone, because = neither > > choices take absolute advantage. This problem is obviously just a tradeoff. > > Someone value robustness and some others values performance. > > > > I sincerely suggest, leave the choice to be made by the vendors and network > > administrators. The solution doesn't have to restrict every implementation > > and deployment to be exactly the same. "One man's meat is another = man's > > poison". Please just make out the outcome of what if it is done, and = the > > outcome of what if it is not done. > > > > Please just end this endless debate and move forward in the = savi-slaac. 2012 > > is near :). > > > > BR, > > Guang > > > > > >> -----Original Message----- > >> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On = Behalf Of > >> marcelo bagnulo braun > >> Sent: Monday, March 15, 2010 7:37 PM > >> To: savi@ietf.org > >> Subject: Re: [savi] call for comments: savi-dhcp-01 > >> > >> Hi Mikael, > >> > >> sorry for the delay, been away for a few days > >> > >> below... > >> > >> El 09/03/10 10:46, Mikael Abrahamsson escribi=F3: > >> > >>> On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: > >>> > >>> > >>>> but this is what we qualify as a must in the ietf terminology. If = you > >>>> don't do this, the network breaks in different ways, right? > >>>> > >>> I don't agree that this is a must. This breakage is limited to = certain > >>> operational concerns, it's not a fundamental problem that makes it = not > >>> work at all. > >>> > >>> > >> Let's go back to RFC 2119 where the usage of these terms is = defines: > >> RFC2119 reads: > >> > >> * * > >> > >> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that = the > >> definition is an absolute requirement of the specification. > >> > >> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that > there > >> may exist valid reasons in particular circumstances to ignore = a > >> particular item, but the full implications must be understood = and > >> carefully weighed before choosing a different course. > >> > >> > >> So, the situation is that if the triggering of the binding creation = by > >> data packet si not implemented, a legitimate user will be = disconnected > >> from the network in case the state is loss or in case a failure = results > >> in a change in the topology. So this actually affects = interoperability. > >> > >> The alternative would be a SHOULD properly qualified. > >> > >> I think that for the SLAAC/ND case, it is much more likely that the > >> situation occurs (due to packet loss and the non reliable nature of = the > >> DAD procedure), so i really think that the triggering of the SAVI > >> binding creation process upon the recpetion of data packets should = be a > >> MUST. > >> > >> For the dhcp case, the cases in whcih this fails are reduced = because of > >> the reliable nature of the dhcp exchange, so while i would rather = go for > >> a MUST, i think i can live with a SHOULD. > >> > >>> One can make the argument that this is a risk taken by the entity = that > >>> chooses to deploy SAVI partially and that SAVI mandates things = that > >>> are needed for a totally SAVI enabled network where all devices = have > >>> this, and in the case not all of them have SAVI functionality, = then > >>> things will break unless a MAY or SHOULD clause is implemented? > >>> > >>> > >> No, a MAY is something that is completelly optional and would not affect > >> interop in any way. > >> > >> As i said above, in the case of dhcp, if the SHOULD is properly > >> qualified, i could live with that. > >> > >> > >> > >>> I don't like the situation where some vendors might not offer SAVI = at > >>> all, to handle the problem you're describing. > >>> > >>> > >> Right, i do have this concern as well, but i am very worried about = the > >> impact to the overall robustness fo the network. > >> > >> Regards, marcelo > >> > >> _______________________________________________ > >> savi mailing list > >> savi@ietf.org > >> https://www.ietf.org/mailman/listinfo/savi > >> > > _______________________________________________ > > savi mailing list > > savi@ietf.org > > https://www.ietf.org/mailman/listinfo/savi > > > > >=20 > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From yaoa02@mails.tsinghua.edu.cn Mon Mar 15 07:35:43 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05EBE3A6B51 for ; Mon, 15 Mar 2010 07:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76Mf+vHVSVi1 for ; Mon, 15 Mar 2010 07:35:42 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 965FC3A6A16 for ; Mon, 15 Mar 2010 07:35:28 -0700 (PDT) Received: from th211043.ip.tsinghua.edu.cn ([59.66.211.43] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NrBOC-0004DI-4w for savi@ietf.org; Mon, 15 Mar 2010 22:35:28 +0800 From: "Guang Yao" To: "'SAVI Mailing List'" References: <09741A6EA86846049A114B745EE24C37@junbiVAIO> <4B9E2ECD.7080504@cisco.com> <000a01cac445$5b2465e0$116d31a0$@tsinghua.edu.cn> <4B9E407C.8000303@cisco.com> In-Reply-To: <4B9E407C.8000303@cisco.com> Date: Mon, 15 Mar 2010 22:35:20 +0800 Message-ID: <001701cac44c$bd4e14d0$37ea3e70$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrESc1UUCcABtzeRDWW3n6Rjwl92QAAunhQ Content-Language: zh-cn Subject: Re: [savi] savi-dhcp-02 draft X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 14:35:43 -0000 Hi Eric, The method that save bindings in non volatile memory is described in = section 21. Thanks for your previous suggestion. The data triggered dhcp lease query is not used to restore previous bindings, but to set up bindings the device _never_ gets known. The scenarios include movement on local link, and layer 2 topo changes, as discussed recently. BR, Guang > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf = Of Eric > Levy-Abegnoli > Sent: Monday, March 15, 2010 10:13 PM > To: Guang Yao > Cc: 'SAVI Mailing List' > Subject: Re: [savi] savi-dhcp-02 draft >=20 > Hi Guang, >=20 > Guang Yao a =E9crit : > > Hi Eric, > > > > Thanks for your suggestion. Your experience is very valuable. > > > > In this solution, sending DHCP lease query is optional, just to = handle some > > special cases (in general, data triggered but rather control = packet). It is > > not required to be enabled. Vendors may choose to implement it on = layer 3 > > device but not pure layer 2 device. And network administrators may = not > > enable this function if they find the device may be overloaded. > > > > If binding is learnt from NDP, IMO it should be bound in savi-slaac, = but not > > in this solution for DHCP. And the which to prefer in case of co-existing of > > NDP and DHCP, I think should be specified in the framework doc. Am I right? > > > > BR, > > Guang > > > What I meant is that the proposed method (sending a leasequery to > re-discover a binding lost in case of the switch reboot) cannot be = used > as a "general" response to the problem raised. A switch, L2-only = device, > that looses its binding table and has no non-volatile memory has just = no > way to recover it thru DHCP. It's is unfortunate since DHCP is > considered as the only authoritative method for discovering bindings. > I would consider that at the stage, when DHCP is used, non-volatile > memory is the only option. > Eric > > > >> -----Original Message----- > >> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On = Behalf Of > >> > > Eric > > > >> Levy-Abegnoli > >> Sent: Monday, March 15, 2010 8:58 PM > >> To: Bi Jun > >> Cc: SAVI Mailing List > >> Subject: Re: [savi] savi-dhcp-02 draft > >> > >> Bi Jun a =E9crit : > >> > >>> Hi all, > >>> > >>> This is a revised version of savi-dhcp (revised based on the > >>> discussion of dhcp-01 on the mailing-list in the past week), > >>> basically, make the control packet-triggered functions as MUST = (low > >>> cost to be implemented in every switch), and have the = data-triggered > >>> functions (more complex to be implemented) as optional for = higher-end > >>> switches (to enable more flexible use of savi device). > >>> > >>> We are consulting the vendors on the cost for those options. > >>> > >>> please give us your comments. > >>> > >>> thanks, > >>> Jun Bi SAVI > >>> > >> J. > >> > >>> Bi, J. Wu > >>> > >> Hi Jun bi, > >> Reading the below: > >> > >> "IPv6 address: > >> Send a LEASEQUERY [RFC5007] message querying by IP address to > >> All_DHCP_Relay_Agents_and_Servers multicast address or a > >> configured server address. If no successful LEASEQUERY-REPLY = is > >> received, discard the packet; otherwise generate a new = binding > >> entry for the address. The SAVI device may repeat this = process if > >> a LEASEQUERY-REPLY with OPTION_CLIENT_LINK is received, in > order > >> to set up binding entries for all the address of the client." > >> > >> I don't think the below proposal to discover IPv6 address from the = savi > >> device works. DHCP messages must be sourced with an IPv6 address > (can't > >> be UNSPEC, must be a link-local) and in most cases, the switch does = not > >> have any. That would take the switch to have a L3 interface that > >> participate in the link operations (for each of its vlans), and = that is > >> a huge constrain. > >> I have real deployment examples of pure L2 switch devices with thousands > >> of vlans configured (hundreds of ports in each vlan). Getting a L3 > >> address in each vlan would have a huge impact on the switch = operations > >> and performances.That does not seem acceptable. > >> I think the only option is to discover the binding by probing with = a NDP > >> DAD NS. This one is sourced with UNSPEC and hence is accpetable for = a L2 > >> device. Then install the binding as learnt from NDP. And later, > >> "prefer" the DHCP binding when/if it shows up. > >> Eric > >> > >> > >> _______________________________________________ > >> savi mailing list > >> savi@ietf.org > >> https://www.ietf.org/mailman/listinfo/savi > >> > > > > > > >=20 > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From junbi@cernet.edu.cn Mon Mar 15 07:48:07 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4A003A68C6 for ; Mon, 15 Mar 2010 07:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.31 X-Spam-Level: X-Spam-Status: No, score=0.31 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKJ4A-VQXZHM for ; Mon, 15 Mar 2010 07:48:06 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id C5D893A67AC for ; Mon, 15 Mar 2010 07:48:03 -0700 (PDT) Received: from junbiVAIO([59.66.24.139]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm284b9ebb88; Mon, 15 Mar 2010 22:48:08 +0800 Message-ID: <876F7DBECC2348C695021E77315654F0@junbiVAIO> From: "Bi Jun" To: "marcelo bagnulo braun" References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es> <4B9E1BF3.9080709@it.uc3m.es> <231D9821F3704A09BCB0B166137AA034@junbiVAIO> <4B9E3D5C.6040600@it.uc3m.es> In-Reply-To: <4B9E3D5C.6040600@it.uc3m.es> Date: Mon, 15 Mar 2010 22:48:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: UN2aLrXB Cc: savi@ietf.org Subject: [savi] savi-dhcp-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 14:48:07 -0000 Hi Marcelo, Hi, Marcelo, Here we are actually talking about the trade-off between cost and the benefits (forgive me that I explained this option many times). If the solution is just a couple of lines of code, whey not we make it MUST? But the truth is that the data-triggered actions are heavy burden to device especially low end access switch. If you make them MUST, then you forbid those access switches implementing SAVI (those access switch could be more than 90% of potential savi-switches). So my idea is: 1 make two RFCs, one for each catalog of functions used for different scenarios. 2 make one RFC, but make MUST for basic functions, make other functions as options. And provide a guideline to users: (1) If the users want to plus a host directly a savi-device, deploy cheap switch only implement MUST (2) If users want to connect host to a old hub, then connect the hub savi-device (like the pictures you drown), then if you think best-effort is OK for you (if you have problem, reboot your hub or repaired the host-connection, deploy the cheap switch only implement MUST (3) in the above case, if you want 100% service quality, then buy a higher-end savi-device that implement options in this RFC. thanks, Jun -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Monday, March 15, 2010 9:59 PM To: "Bi Jun" Cc: Subject: Re: [savi] call for comments: savi-dhcp-01 > El 15/03/10 13:19, Bi Jun escribió: >> Hi Marcelo, >> >> The sentence is misleading. >> "So, the situation is that if the triggering of the binding creation by >> data packet si not implemented, a legitimate user will be disconnected " >> >> It only happens for some situations. > > Right, it only happen in some situation, but that is what robustness is > about, right? > I mean, this affects interoperability, becuase it may happen that the > communication of a legitimate host is interrupted due to this. >> If the "MUST" only handles some situation but bring *much more* cost to >> the device (it's really because the data-triggered solution is not a low >> cost action), >> then I think the right ways: >> >> 1 "MUST" for all cases, and list some limitation and guide the users. >> 2 "Options" for some special cases, users has the guide to buy the >> higher-end device >> if they want more flexible use of savi device, (certainly, by paying >> higher price for the device.). >> > As i said, i don't think in any case this is optional. > > IMHO, this is a MUST becuase it affect interoperability. > If there is no consensus to go for a MUST, i can live with, for the dhcp > case and only for the dhcp case, since the subset of problematic cases is > more limited than the ND case, we could use a qualified SHOULD, which > means that the implementation SHOULD do that and we explian what happens > if they don't. How about that? > > Regards, marcelo > > > >> That's my answer to all your similar questions. >> >> thanks, >> Jun Bi >> >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Monday, March 15, 2010 7:37 PM >> To: >> Subject: Re: [savi] call for comments: savi-dhcp-01 >> >>> Hi Mikael, >>> >>> sorry for the delay, been away for a few days >>> >>> below... >>> >>> El 09/03/10 10:46, Mikael Abrahamsson escribió: >>>> On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: >>>> >>>>> but this is what we qualify as a must in the ietf terminology. If you >>>>> don't do this, the network breaks in different ways, right? >>>> >>>> I don't agree that this is a must. This breakage is limited to certain >>>> operational concerns, it's not a fundamental problem that makes it not >>>> work at all. >>>> >>> Let's go back to RFC 2119 where the usage of these terms is defines: >>> RFC2119 reads: >>> >>> * * >>> >>> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the >>> definition is an absolute requirement of the specification. >>> >>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there >>> may exist valid reasons in particular circumstances to ignore a >>> particular item, but the full implications must be understood and >>> carefully weighed before choosing a different course. >>> >>> >>> So, the situation is that if the triggering of the binding creation by >>> data packet si not implemented, a legitimate user will be disconnected >>> from the network in case the state is loss or in case a failure results >>> in a change in the topology. So this actually affects interoperability. >>> >>> The alternative would be a SHOULD properly qualified. >>> >>> I think that for the SLAAC/ND case, it is much more likely that the >>> situation occurs (due to packet loss and the non reliable nature of the >>> DAD procedure), so i really think that the triggering of the SAVI >>> binding creation process upon the recpetion of data packets should be a >>> MUST. >>> >>> For the dhcp case, the cases in whcih this fails are reduced because of >>> the reliable nature of the dhcp exchange, so while i would rather go for >>> a MUST, i think i can live with a SHOULD. >>>> One can make the argument that this is a risk taken by the entity that >>>> chooses to deploy SAVI partially and that SAVI mandates things that are >>>> needed for a totally SAVI enabled network where all devices have this, >>>> and in the case not all of them have SAVI functionality, then things >>>> will break unless a MAY or SHOULD clause is implemented? >>>> >>> No, a MAY is something that is completelly optional and would not affect >>> interop in any way. >>> >>> As i said above, in the case of dhcp, if the SHOULD is properly >>> qualified, i could live with that. >>> >>> >>>> I don't like the situation where some vendors might not offer SAVI at >>>> all, to handle the problem you're describing. >>>> >>> Right, i do have this concern as well, but i am very worried about the >>> impact to the overall robustness fo the network. >>> >>> Regards, marcelo >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> > From marcelo@it.uc3m.es Mon Mar 15 07:55:47 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACCFA3A6A60 for ; Mon, 15 Mar 2010 07:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.472 X-Spam-Level: X-Spam-Status: No, score=-106.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZ-vgvU30cby for ; Mon, 15 Mar 2010 07:55:42 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 05F853A67B3 for ; Mon, 15 Mar 2010 07:55:41 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 0FAB67F752A; Mon, 15 Mar 2010 15:55:47 +0100 (CET) Message-ID: <4B9E4A72.2040808@it.uc3m.es> Date: Mon, 15 Mar 2010 15:55:46 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Bi Jun References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> <019C6F3B5F9C4B9F816588E35A440555@junbiVAIO> <4B9E3C24.5060504@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 14:55:47 -0000 El 15/03/10 15:28, Bi Jun escribió: > I meant please in the guideline, says that your host SHOULD be > directly plug to the savi-device. this is not how the SHOULD work for the specification since this is not somehting the protocol MUST/SHOULD implement. The MUST/SHOULD affects the protocol extensions and not the configurations where you use it The configurations where you use safely or not are the qualification of the SHOULD Regards, marcelo > If not, please purchase an higher-end savi-device that implemented the > options. > > thanks, > Jun > > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Monday, March 15, 2010 9:54 PM > To: "Bi Jun" > Cc: "SAVI Mailing List" > Subject: Re: the impact of SAVI in the overall network robustness (was > Re: [savi] dealing with topology changes in dhcp savi > >> So, if you do discard the packets for which there is no binding, the >> overall network robustness is worse, in particular settings where a >> redundant topology has been set. >> >> This seems quite severe to me. >> >> Regards, marcelo >> >> >> El 15/03/10 13:26, Bi Jun escribió: >>> Hi Marcelo, >>> >>> We can guide the users in this document or in framework, >>> if you want to put a hub between savi-device or your host, please >>> buy an more expensive savi-device that implemented the xxx options >>> functions (e.g the data triggered functions listed in savi-dhcp-02, >>> or another solution document). >>> >>> thanks, >>> Jun >>> >>> -------------------------------------------------- >>> From: "marcelo bagnulo braun" >>> Sent: Monday, March 15, 2010 8:09 PM >>> To: "Bi Jun" >>> Cc: "SAVI Mailing List" >>> Subject: the impact of SAVI in the overall network robustness (was >>> Re: [savi] dealing with topology changes in dhcp savi >>> >>>> Hi Jun, >>>> >>>> sorry for the delay, i was away for a few days. >>>> >>>> Ok, let me rephrase my question then. >>>> >>>> Suppose that you have the topology that is depicted below, >>>> with multiple redundant switches to benefit from robustness. >>>> My point is that the introduction of SAVI that is unable to >>>> cope with data packets for which there is no binding will >>>> reduce the robustness of the network, even if network >>>> has been designed to be redundant. >>>> >>>> In the case SAVI is being deployed in a switched Ethernet network, >>>> failures in a single device changes may result in a SAVI device >>>> receiving packets from a >>>> legitimate user for which the SAVI device does not have a binding >>>> for. Consider the following example: >>>> >>>> >>>> >>>> +------+ +--------+ +---------------+ >>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>> +------+ +--------+ +---------------+ >>>> | | >>>> | +--------+ >>>> | | SAVI II| >>>> | +--------+ >>>> | +----------+ | >>>> +---|SWITCH II |-----+ >>>> +----------+ >>>> | >>>> +-----+ >>>> | Host| >>>> +-----+ >>>> >>>> >>>> The DHCP server is located in the part called rest of the network. >>>> Suppose that after bootstrapping all the elements are working >>>> properly and the spanning tree is rooted in the router and it >>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and >>>> another >>>> branch that goes SWITCH I-SAVI II. >>>> >>>> Suppose that the Host boots at this moment and perfomrs the DHCP >>>> sxchange. >>>> The message is propagated through the spanning tree and it received >>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>> SAVI I creates the binding. >>>> >>>> Suppose that SAVI I fails and the spanning tree reconverges to >>>> SWITCH >>>> I- SAVI II- SWITCH II. Now data packets coming from the Host >>>> will be >>>> coursed through SAVI II which does not have binding state and will >>>> drop the packets. >>>> >>>> Comments? >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> El 09/03/10 11:47, Bi Jun escribió: >>>>> Hi Marcelo, >>>>> >>>>> Since you are entitled "topology change", I want to say sth. >>>>> Based on our operational experience, if we do a planed topology >>>>> change, >>>>> then we have to plan we will have more serious problem than this. >>>>> So topology change in an operational network is usually carefully >>>>> planed. >>>>> We don't do it very often, and once we do it, we will let users >>>>> understand us. >>>>> >>>>> So I don't see a problem of planed topology change. The only thing >>>>> is the power-down >>>>> of a switch, which is really a low frequency event in an >>>>> operational network. If we found the power down, we will also >>>>> inform users (only users under that switch will be affected, not >>>>> all users will be affect) that if you had any problem thank you >>>>> please renew your connection. >>>>> >>>>> thanks, >>>>> Jun Bi >>>>> >>>>> -------------------------------------------------- >>>>> From: "marcelo bagnulo braun" >>>>> Sent: Tuesday, March 09, 2010 3:51 PM >>>>> To: "SAVI Mailing List" >>>>> Subject: [savi] dealing with topology changes in dhcp savi >>>>> >>>>>> Hi, >>>>>> >>>>>> I have another question about dhcp save >>>>>> >>>>>> How do you handle the following situation? >>>>>> >>>>>> In the case SAVI is being deployed in a switched Ethernet >>>>>> network, >>>>>> topology changes may result in a SAVI device receiving packets >>>>>> from a >>>>>> legitimate user for which the SAVI device does not have a binding >>>>>> for. Consider the following example: >>>>>> >>>>>> >>>>>> >>>>>> +------+ +--------+ +---------------+ >>>>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>>>> +------+ +--------+ +---------------+ >>>>>> | | >>>>>> | +--------+ >>>>>> | | SAVI II| >>>>>> | +--------+ >>>>>> | +----------+ | >>>>>> +---|SWITCH II |-----+ >>>>>> +----------+ >>>>>> | >>>>>> +-----+ >>>>>> | Host| >>>>>> +-----+ >>>>>> >>>>>> >>>>>> The DHCP server is located in the part called rest of the >>>>>> network. >>>>>> Suppose that after bootstrapping all the elements are working >>>>>> properly and the spanning tree is rooted in the router and it >>>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and >>>>>> another >>>>>> branch that goes SWITCH I-SAVI II. >>>>>> >>>>>> Suppose that the Host boots at this moment and perfomrs the >>>>>> DHCP sxchange. >>>>>> The message is propagated through the spanning tree and it >>>>>> received >>>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>>> SAVI I creates the binding. >>>>>> >>>>>> Suppose that SAVI I fails and the spanning tree reconverges to >>>>>> SWITCH >>>>>> I- SAVI II- SWITCH II. Now data packets coming from the Host >>>>>> will be >>>>>> coursed through SAVI II which does not have binding state and >>>>>> will >>>>>> drop the packets. >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> >>>>> >>>> >>> >> > From marcelo@it.uc3m.es Mon Mar 15 07:57:33 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A241F3A67D9 for ; Mon, 15 Mar 2010 07:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P79KfoJrZm-8 for ; Mon, 15 Mar 2010 07:57:32 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 1453E3A67B3 for ; Mon, 15 Mar 2010 07:57:32 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 70B746C69E4 for ; Mon, 15 Mar 2010 15:57:38 +0100 (CET) Message-ID: <4B9E4AE2.2090407@it.uc3m.es> Date: Mon, 15 Mar 2010 15:57:38 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: savi@ietf.org References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es> <4B9E1BF3.9080709@it.uc3m.es> <000901cac442$d7967d50$86c377f0$@tsinghua.edu.cn> <4B9E3E11.8080403@it.uc3m.es> <001601cac44c$a64f64a0$f2ee2de0$@tsinghua.edu.cn> In-Reply-To: <001601cac44c$a64f64a0$f2ee2de0$@tsinghua.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 14:57:33 -0000 El 15/03/10 15:34, Guang Yao escribió: > OK, I make a step backwards. What if requiring vendors to implement both, > but at least giving the right of choosing to network administrators? > mmm, that is an interesting proposal MUST implement this but MUST be configurable to turn it on/off... I think i can also live with that for the dhcp case Regards, marcelo > And I want to mention that, ingress filtering(RFC2827, RFC3704, BCP38, > BCP84) is not a mechanism that wouldn't discard any " legitimate" packet. It > may also "break the internet". Why it has RFC numbers? > > BR, > Guang > > >> -----Original Message----- >> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of >> marcelo bagnulo braun >> Sent: Monday, March 15, 2010 10:03 PM >> To: savi@ietf.org >> Subject: Re: [savi] call for comments: savi-dhcp-01 >> >> I beg to differ. My concern is that if we simply drop the packets for >> which there is no binding, the overall network robustness will be >> affected. And our duty as IETF is to properly design protocols to make >> the Internet work in a reliable manner. If vendors want to implement >> solutions that break the internet they can do it, but they don't get to >> do that using an IETF RFC number (or at least they shouldn't) >> >> Regards, marcelo >> >> El 15/03/10 14:24, Guang Yao escribió: >> >>> Hi Marcelo, >>> >>> Venture to say, it is impossible to persuade everyone, because neither >>> choices take absolute advantage. This problem is obviously just a >>> > tradeoff. > >>> Someone value robustness and some others values performance. >>> >>> I sincerely suggest, leave the choice to be made by the vendors and >>> > network > >>> administrators. The solution doesn't have to restrict every >>> > implementation > >>> and deployment to be exactly the same. "One man's meat is another man's >>> poison". Please just make out the outcome of what if it is done, and the >>> outcome of what if it is not done. >>> >>> Please just end this endless debate and move forward in the savi-slaac. >>> > 2012 > >>> is near :). >>> >>> BR, >>> Guang >>> >>> >>> >>>> -----Original Message----- >>>> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of >>>> marcelo bagnulo braun >>>> Sent: Monday, March 15, 2010 7:37 PM >>>> To: savi@ietf.org >>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>> >>>> Hi Mikael, >>>> >>>> sorry for the delay, been away for a few days >>>> >>>> below... >>>> >>>> El 09/03/10 10:46, Mikael Abrahamsson escribió: >>>> >>>> >>>>> On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: >>>>> >>>>> >>>>> >>>>>> but this is what we qualify as a must in the ietf terminology. If you >>>>>> don't do this, the network breaks in different ways, right? >>>>>> >>>>>> >>>>> I don't agree that this is a must. This breakage is limited to certain >>>>> operational concerns, it's not a fundamental problem that makes it not >>>>> work at all. >>>>> >>>>> >>>>> >>>> Let's go back to RFC 2119 where the usage of these terms is defines: >>>> RFC2119 reads: >>>> >>>> * * >>>> >>>> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the >>>> definition is an absolute requirement of the specification. >>>> >>>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that >>>> >> there >> >>>> may exist valid reasons in particular circumstances to ignore a >>>> particular item, but the full implications must be understood and >>>> carefully weighed before choosing a different course. >>>> >>>> >>>> So, the situation is that if the triggering of the binding creation by >>>> data packet si not implemented, a legitimate user will be disconnected >>>> from the network in case the state is loss or in case a failure results >>>> in a change in the topology. So this actually affects interoperability. >>>> >>>> The alternative would be a SHOULD properly qualified. >>>> >>>> I think that for the SLAAC/ND case, it is much more likely that the >>>> situation occurs (due to packet loss and the non reliable nature of the >>>> DAD procedure), so i really think that the triggering of the SAVI >>>> binding creation process upon the recpetion of data packets should be a >>>> MUST. >>>> >>>> For the dhcp case, the cases in whcih this fails are reduced because of >>>> the reliable nature of the dhcp exchange, so while i would rather go >>>> > for > >>>> a MUST, i think i can live with a SHOULD. >>>> >>>> >>>>> One can make the argument that this is a risk taken by the entity that >>>>> chooses to deploy SAVI partially and that SAVI mandates things that >>>>> are needed for a totally SAVI enabled network where all devices have >>>>> this, and in the case not all of them have SAVI functionality, then >>>>> things will break unless a MAY or SHOULD clause is implemented? >>>>> >>>>> >>>>> >>>> No, a MAY is something that is completelly optional and would not >>>> > affect > >>>> interop in any way. >>>> >>>> As i said above, in the case of dhcp, if the SHOULD is properly >>>> qualified, i could live with that. >>>> >>>> >>>> >>>> >>>>> I don't like the situation where some vendors might not offer SAVI at >>>>> all, to handle the problem you're describing. >>>>> >>>>> >>>>> >>>> Right, i do have this concern as well, but i am very worried about the >>>> impact to the overall robustness fo the network. >>>> >>>> Regards, marcelo >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >>> >>> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > From junbi@cernet.edu.cn Mon Mar 15 08:00:02 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B0B3A67B3 for ; Mon, 15 Mar 2010 08:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.292 X-Spam-Level: X-Spam-Status: No, score=0.292 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YphvgbRqx97S for ; Mon, 15 Mar 2010 08:00:01 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 513E73A6B74 for ; Mon, 15 Mar 2010 07:59:58 -0700 (PDT) Received: from junbiVAIO([59.66.24.139]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm04b9ebe53; Mon, 15 Mar 2010 23:00:03 +0800 Message-ID: <63495C88CB4141118DCF796A35192F22@junbiVAIO> From: "Bi Jun" To: "marcelo bagnulo braun" References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> <019C6F3B5F9C4B9F816588E35A440555@junbiVAIO> <4B9E3C24.5060504@it.uc3m.es> <4B9E4A72.2040808@it.uc3m.es> In-Reply-To: <4B9E4A72.2040808@it.uc3m.es> Date: Mon, 15 Mar 2010 22:59:56 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: UFzlLrXB Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 15:00:02 -0000 I think everything has it's working condition. The guideline is part of the RFC to discuss the condition. For more discussion, please see my another replied email. thanks, Jun -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Monday, March 15, 2010 10:55 PM To: "Bi Jun" Cc: "SAVI Mailing List" Subject: Re: the impact of SAVI in the overall network robustness (was Re: [savi] dealing with topology changes in dhcp savi > El 15/03/10 15:28, Bi Jun escribió: >> I meant please in the guideline, says that your host SHOULD be directly >> plug to the savi-device. > > this is not how the SHOULD work for the specification since this is not > somehting the protocol MUST/SHOULD implement. > > The MUST/SHOULD affects the protocol extensions and not the configurations > where you use it > The configurations where you use safely or not are the qualification of > the SHOULD > > Regards, marcelo > >> If not, please purchase an higher-end savi-device that implemented the >> options. >> >> thanks, >> Jun >> >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Monday, March 15, 2010 9:54 PM >> To: "Bi Jun" >> Cc: "SAVI Mailing List" >> Subject: Re: the impact of SAVI in the overall network robustness (was >> Re: [savi] dealing with topology changes in dhcp savi >> >>> So, if you do discard the packets for which there is no binding, the >>> overall network robustness is worse, in particular settings where a >>> redundant topology has been set. >>> >>> This seems quite severe to me. >>> >>> Regards, marcelo >>> >>> >>> El 15/03/10 13:26, Bi Jun escribió: >>>> Hi Marcelo, >>>> >>>> We can guide the users in this document or in framework, >>>> if you want to put a hub between savi-device or your host, please buy >>>> an more expensive savi-device that implemented the xxx options >>>> functions (e.g the data triggered functions listed in savi-dhcp-02, or >>>> another solution document). >>>> >>>> thanks, >>>> Jun >>>> >>>> -------------------------------------------------- >>>> From: "marcelo bagnulo braun" >>>> Sent: Monday, March 15, 2010 8:09 PM >>>> To: "Bi Jun" >>>> Cc: "SAVI Mailing List" >>>> Subject: the impact of SAVI in the overall network robustness (was Re: >>>> [savi] dealing with topology changes in dhcp savi >>>> >>>>> Hi Jun, >>>>> >>>>> sorry for the delay, i was away for a few days. >>>>> >>>>> Ok, let me rephrase my question then. >>>>> >>>>> Suppose that you have the topology that is depicted below, >>>>> with multiple redundant switches to benefit from robustness. >>>>> My point is that the introduction of SAVI that is unable to >>>>> cope with data packets for which there is no binding will >>>>> reduce the robustness of the network, even if network >>>>> has been designed to be redundant. >>>>> >>>>> In the case SAVI is being deployed in a switched Ethernet network, >>>>> failures in a single device changes may result in a SAVI device >>>>> receiving packets from a >>>>> legitimate user for which the SAVI device does not have a binding >>>>> for. Consider the following example: >>>>> >>>>> >>>>> >>>>> +------+ +--------+ +---------------+ >>>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>>> +------+ +--------+ +---------------+ >>>>> | | >>>>> | +--------+ >>>>> | | SAVI II| >>>>> | +--------+ >>>>> | +----------+ | >>>>> +---|SWITCH II |-----+ >>>>> +----------+ >>>>> | >>>>> +-----+ >>>>> | Host| >>>>> +-----+ >>>>> >>>>> >>>>> The DHCP server is located in the part called rest of the network. >>>>> Suppose that after bootstrapping all the elements are working >>>>> properly and the spanning tree is rooted in the router and it >>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and >>>>> another >>>>> branch that goes SWITCH I-SAVI II. >>>>> >>>>> Suppose that the Host boots at this moment and perfomrs the DHCP >>>>> sxchange. >>>>> The message is propagated through the spanning tree and it received >>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>> SAVI I creates the binding. >>>>> >>>>> Suppose that SAVI I fails and the spanning tree reconverges to >>>>> SWITCH >>>>> I- SAVI II- SWITCH II. Now data packets coming from the Host will >>>>> be >>>>> coursed through SAVI II which does not have binding state and will >>>>> drop the packets. >>>>> >>>>> Comments? >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>> >>>>> El 09/03/10 11:47, Bi Jun escribió: >>>>>> Hi Marcelo, >>>>>> >>>>>> Since you are entitled "topology change", I want to say sth. >>>>>> Based on our operational experience, if we do a planed topology >>>>>> change, >>>>>> then we have to plan we will have more serious problem than this. >>>>>> So topology change in an operational network is usually carefully >>>>>> planed. >>>>>> We don't do it very often, and once we do it, we will let users >>>>>> understand us. >>>>>> >>>>>> So I don't see a problem of planed topology change. The only thing is >>>>>> the power-down >>>>>> of a switch, which is really a low frequency event in an operational >>>>>> network. If we found the power down, we will also inform users (only >>>>>> users under that switch will be affected, not all users will be >>>>>> affect) that if you had any problem thank you please renew your >>>>>> connection. >>>>>> >>>>>> thanks, >>>>>> Jun Bi >>>>>> >>>>>> -------------------------------------------------- >>>>>> From: "marcelo bagnulo braun" >>>>>> Sent: Tuesday, March 09, 2010 3:51 PM >>>>>> To: "SAVI Mailing List" >>>>>> Subject: [savi] dealing with topology changes in dhcp savi >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have another question about dhcp save >>>>>>> >>>>>>> How do you handle the following situation? >>>>>>> >>>>>>> In the case SAVI is being deployed in a switched Ethernet >>>>>>> network, >>>>>>> topology changes may result in a SAVI device receiving packets >>>>>>> from a >>>>>>> legitimate user for which the SAVI device does not have a binding >>>>>>> for. Consider the following example: >>>>>>> >>>>>>> >>>>>>> >>>>>>> +------+ +--------+ +---------------+ >>>>>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>>>>> +------+ +--------+ +---------------+ >>>>>>> | | >>>>>>> | +--------+ >>>>>>> | | SAVI II| >>>>>>> | +--------+ >>>>>>> | +----------+ | >>>>>>> +---|SWITCH II |-----+ >>>>>>> +----------+ >>>>>>> | >>>>>>> +-----+ >>>>>>> | Host| >>>>>>> +-----+ >>>>>>> >>>>>>> >>>>>>> The DHCP server is located in the part called rest of the >>>>>>> network. >>>>>>> Suppose that after bootstrapping all the elements are working >>>>>>> properly and the spanning tree is rooted in the router and it >>>>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and >>>>>>> another >>>>>>> branch that goes SWITCH I-SAVI II. >>>>>>> >>>>>>> Suppose that the Host boots at this moment and perfomrs the DHCP >>>>>>> sxchange. >>>>>>> The message is propagated through the spanning tree and it >>>>>>> received >>>>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>>>> SAVI I creates the binding. >>>>>>> >>>>>>> Suppose that SAVI I fails and the spanning tree reconverges to >>>>>>> SWITCH >>>>>>> I- SAVI II- SWITCH II. Now data packets coming from the Host >>>>>>> will be >>>>>>> coursed through SAVI II which does not have binding state and >>>>>>> will >>>>>>> drop the packets. >>>>>>> >>>>>>> Regards, marcelo >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> savi mailing list >>>>>>> savi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>> >>>>>> >>>>> >>>> >>> >> > From jmh@joelhalpern.com Mon Mar 15 08:11:36 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CACF3A67F2 for ; Mon, 15 Mar 2010 08:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.939 X-Spam-Level: X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qg99K6PvPU0 for ; Mon, 15 Mar 2010 08:11:34 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id B31C73A6884 for ; Mon, 15 Mar 2010 08:11:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 7592F322837D; Mon, 15 Mar 2010 08:11:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-51-231.clppva.btas.verizon.net [71.161.51.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 5766932329FE; Mon, 15 Mar 2010 08:11:33 -0700 (PDT) Message-ID: <4B9E4E25.8020807@joelhalpern.com> Date: Mon, 15 Mar 2010 11:11:33 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> <019C6F3B5F9C4B9F816588E35A440555@junbiVAIO> <4B9E3C24.5060504@it.uc3m.es> <4B9E4A72.2040808@it.uc3m.es> In-Reply-To: <4B9E4A72.2040808@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 15:11:36 -0000 We can write an applicability statement that captures some of this. But, for this problem, I don't think it will help. Given that the protocol needs to cover all cases, and the protocol machinery can not tell which case it is in, then you can't write a SHOULD about it. (That is one of the interesting properties of the spanning tree case Marcelo raised. it is detectable. The device can complain about inappropriate usage if it actually sees spanning tree coming from a place it is not prepared to cope with.) Yours, Joel marcelo bagnulo braun wrote: > El 15/03/10 15:28, Bi Jun escribió: >> I meant please in the guideline, says that your host SHOULD be >> directly plug to the savi-device. > > this is not how the SHOULD work for the specification since this is not > somehting the protocol MUST/SHOULD implement. > > The MUST/SHOULD affects the protocol extensions and not the > configurations where you use it > The configurations where you use safely or not are the qualification of > the SHOULD > > Regards, marcelo > >> If not, please purchase an higher-end savi-device that implemented the >> options. >> >> thanks, >> Jun >> >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Monday, March 15, 2010 9:54 PM >> To: "Bi Jun" >> Cc: "SAVI Mailing List" >> Subject: Re: the impact of SAVI in the overall network robustness (was >> Re: [savi] dealing with topology changes in dhcp savi >> >>> So, if you do discard the packets for which there is no binding, the >>> overall network robustness is worse, in particular settings where a >>> redundant topology has been set. >>> >>> This seems quite severe to me. >>> >>> Regards, marcelo >>> >>> >>> El 15/03/10 13:26, Bi Jun escribió: >>>> Hi Marcelo, >>>> >>>> We can guide the users in this document or in framework, >>>> if you want to put a hub between savi-device or your host, please >>>> buy an more expensive savi-device that implemented the xxx options >>>> functions (e.g the data triggered functions listed in savi-dhcp-02, >>>> or another solution document). >>>> >>>> thanks, >>>> Jun >>>> >>>> -------------------------------------------------- >>>> From: "marcelo bagnulo braun" >>>> Sent: Monday, March 15, 2010 8:09 PM >>>> To: "Bi Jun" >>>> Cc: "SAVI Mailing List" >>>> Subject: the impact of SAVI in the overall network robustness (was >>>> Re: [savi] dealing with topology changes in dhcp savi >>>> >>>>> Hi Jun, >>>>> >>>>> sorry for the delay, i was away for a few days. >>>>> >>>>> Ok, let me rephrase my question then. >>>>> >>>>> Suppose that you have the topology that is depicted below, >>>>> with multiple redundant switches to benefit from robustness. >>>>> My point is that the introduction of SAVI that is unable to >>>>> cope with data packets for which there is no binding will >>>>> reduce the robustness of the network, even if network >>>>> has been designed to be redundant. >>>>> >>>>> In the case SAVI is being deployed in a switched Ethernet network, >>>>> failures in a single device changes may result in a SAVI device >>>>> receiving packets from a >>>>> legitimate user for which the SAVI device does not have a binding >>>>> for. Consider the following example: >>>>> >>>>> >>>>> >>>>> +------+ +--------+ +---------------+ >>>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>>> +------+ +--------+ +---------------+ >>>>> | | >>>>> | +--------+ >>>>> | | SAVI II| >>>>> | +--------+ >>>>> | +----------+ | >>>>> +---|SWITCH II |-----+ >>>>> +----------+ >>>>> | >>>>> +-----+ >>>>> | Host| >>>>> +-----+ >>>>> >>>>> >>>>> The DHCP server is located in the part called rest of the network. >>>>> Suppose that after bootstrapping all the elements are working >>>>> properly and the spanning tree is rooted in the router and it >>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and >>>>> another >>>>> branch that goes SWITCH I-SAVI II. >>>>> >>>>> Suppose that the Host boots at this moment and perfomrs the DHCP >>>>> sxchange. >>>>> The message is propagated through the spanning tree and it received >>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>> SAVI I creates the binding. >>>>> >>>>> Suppose that SAVI I fails and the spanning tree reconverges to >>>>> SWITCH >>>>> I- SAVI II- SWITCH II. Now data packets coming from the Host >>>>> will be >>>>> coursed through SAVI II which does not have binding state and will >>>>> drop the packets. >>>>> >>>>> Comments? >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>> >>>>> El 09/03/10 11:47, Bi Jun escribió: >>>>>> Hi Marcelo, >>>>>> >>>>>> Since you are entitled "topology change", I want to say sth. >>>>>> Based on our operational experience, if we do a planed topology >>>>>> change, >>>>>> then we have to plan we will have more serious problem than this. >>>>>> So topology change in an operational network is usually carefully >>>>>> planed. >>>>>> We don't do it very often, and once we do it, we will let users >>>>>> understand us. >>>>>> >>>>>> So I don't see a problem of planed topology change. The only thing >>>>>> is the power-down >>>>>> of a switch, which is really a low frequency event in an >>>>>> operational network. If we found the power down, we will also >>>>>> inform users (only users under that switch will be affected, not >>>>>> all users will be affect) that if you had any problem thank you >>>>>> please renew your connection. >>>>>> >>>>>> thanks, >>>>>> Jun Bi >>>>>> >>>>>> -------------------------------------------------- >>>>>> From: "marcelo bagnulo braun" >>>>>> Sent: Tuesday, March 09, 2010 3:51 PM >>>>>> To: "SAVI Mailing List" >>>>>> Subject: [savi] dealing with topology changes in dhcp savi >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have another question about dhcp save >>>>>>> >>>>>>> How do you handle the following situation? >>>>>>> >>>>>>> In the case SAVI is being deployed in a switched Ethernet >>>>>>> network, >>>>>>> topology changes may result in a SAVI device receiving packets >>>>>>> from a >>>>>>> legitimate user for which the SAVI device does not have a binding >>>>>>> for. Consider the following example: >>>>>>> >>>>>>> >>>>>>> >>>>>>> +------+ +--------+ +---------------+ >>>>>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>>>>> +------+ +--------+ +---------------+ >>>>>>> | | >>>>>>> | +--------+ >>>>>>> | | SAVI II| >>>>>>> | +--------+ >>>>>>> | +----------+ | >>>>>>> +---|SWITCH II |-----+ >>>>>>> +----------+ >>>>>>> | >>>>>>> +-----+ >>>>>>> | Host| >>>>>>> +-----+ >>>>>>> >>>>>>> >>>>>>> The DHCP server is located in the part called rest of the >>>>>>> network. >>>>>>> Suppose that after bootstrapping all the elements are working >>>>>>> properly and the spanning tree is rooted in the router and it >>>>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and >>>>>>> another >>>>>>> branch that goes SWITCH I-SAVI II. >>>>>>> >>>>>>> Suppose that the Host boots at this moment and perfomrs the >>>>>>> DHCP sxchange. >>>>>>> The message is propagated through the spanning tree and it >>>>>>> received >>>>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>>>> SAVI I creates the binding. >>>>>>> >>>>>>> Suppose that SAVI I fails and the spanning tree reconverges to >>>>>>> SWITCH >>>>>>> I- SAVI II- SWITCH II. Now data packets coming from the Host >>>>>>> will be >>>>>>> coursed through SAVI II which does not have binding state and >>>>>>> will >>>>>>> drop the packets. >>>>>>> >>>>>>> Regards, marcelo >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> savi mailing list >>>>>>> savi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>> >>>>>> >>>>> >>>> >>> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Mon Mar 15 08:13:16 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75CCD3A6B64 for ; Mon, 15 Mar 2010 08:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.49 X-Spam-Level: X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG4+IprB87Tc for ; Mon, 15 Mar 2010 08:13:07 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 650833A67F2 for ; Mon, 15 Mar 2010 08:13:02 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 777C26C697C; Mon, 15 Mar 2010 16:13:08 +0100 (CET) Message-ID: <4B9E4E84.1090003@it.uc3m.es> Date: Mon, 15 Mar 2010 16:13:08 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Bi Jun References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es> <4B9E1BF3.9080709@it.uc3m.es> <231D9821F3704A09BCB0B166137AA034@junbiVAIO> <4B9E3D5C.6040600@it.uc3m.es> <876F7DBECC2348C695021E77315654F0@junbiVAIO> In-Reply-To: <876F7DBECC2348C695021E77315654F0@junbiVAIO> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 15:13:16 -0000 Hi Jun, What i am talking about is how the deployment of the different SAVI solution will affect the overall robustness and performance of the Internet architecture. One of the tasks of the IETF and of the IAB is to preserve the overall Internet architecture and to keep its fundamental design principles that have granted a robust Internet. My concern is that a SAVI solution that blindly drops data packets for which it has no binding for woudl deter the reliability of the network as a whole and we shouldn't allow that. So, that being said, let me comment on som particular comments you make. Below... El 15/03/10 15:48, Bi Jun escribió: > Hi Marcelo, > > Hi, Marcelo, > > Here we are actually talking about the trade-off between cost and the > benefits (forgive me that I explained this option many times). If the > solution is just a couple of lines of code, whey not we make it MUST? > But the truth is that the data-triggered actions are heavy burden to > device especially low end access switch. If you make them MUST, then > you forbid those access switches implementing SAVI (those access > switch could be more than 90% of potential savi-switches). > Where did you get this figure from? The feedback that i have got form vendors is that they would be able to implement it as long as it is rate limited. > So my idea is: > 1 make two RFCs, one for each catalog of functions used for different > scenarios. > 2 make one RFC, but make MUST for basic functions, make other > functions as options. And provide a guideline to users: > (1) If the users want to plus a host directly a savi-device, deploy > cheap switch only implement MUST > (2) If users want to connect host to a old hub, then connect the hub > savi-device (like the pictures you drown), then if you think > best-effort is OK for you (if you have problem, reboot your hub or > repaired the host-connection, deploy the cheap switch only implement MUST > (3) in the above case, if you want 100% service quality, then buy a > higher-end savi-device that implement options in this RFC. > Actually, i don't agree with this approach. I think we have the normative language as specified in RFC 2116 exactly to deal with this type of situations. I don't want to have all the SAVI funcionality spread over more RFCs, we already have split the SAVI spec in more than we should and i don't think it would make sense to divide it even more. I think we need to have one RFC for dhcp savi and one for SLAAC savi We need to agree on what features are MUST and which ones are SHOULD. As i suggested already,. imho the triggering of the binding creation mechanisms upon the reception of a data packet for whcih there is no binding should be a MUST for both cases. I could live with a qualified SHOULD for the DHCP case and a MUST for the SLAAC case, based on the faact that the DHCP exchange is reliable and hence the problem of packet loss is not an issue for the DHCP case while it is so for the SLAAC case I think i could also live with Guang's suggestion of having A MUST for both cases and also require as a MUST that the feature MUST be configurable on/off Regards, marcelo > thanks, > Jun > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Monday, March 15, 2010 9:59 PM > To: "Bi Jun" > Cc: > Subject: Re: [savi] call for comments: savi-dhcp-01 > >> El 15/03/10 13:19, Bi Jun escribió: >>> Hi Marcelo, >>> >>> The sentence is misleading. >>> "So, the situation is that if the triggering of the binding creation by >>> data packet si not implemented, a legitimate user will be >>> disconnected " >>> >>> It only happens for some situations. >> >> Right, it only happen in some situation, but that is what robustness >> is about, right? >> I mean, this affects interoperability, becuase it may happen that the >> communication of a legitimate host is interrupted due to this. >>> If the "MUST" only handles some situation but bring *much more* cost >>> to the device (it's really because the data-triggered solution is >>> not a low cost action), >>> then I think the right ways: >>> >>> 1 "MUST" for all cases, and list some limitation and guide the users. >>> 2 "Options" for some special cases, users has the guide to buy the >>> higher-end device >>> if they want more flexible use of savi device, (certainly, by paying >>> higher price for the device.). >>> >> As i said, i don't think in any case this is optional. >> >> IMHO, this is a MUST becuase it affect interoperability. >> If there is no consensus to go for a MUST, i can live with, for the >> dhcp case and only for the dhcp case, since the subset of problematic >> cases is more limited than the ND case, we could use a qualified >> SHOULD, which means that the implementation SHOULD do that and we >> explian what happens if they don't. How about that? >> >> Regards, marcelo >> >> >> >>> That's my answer to all your similar questions. >>> >>> thanks, >>> Jun Bi >>> >>> -------------------------------------------------- >>> From: "marcelo bagnulo braun" >>> Sent: Monday, March 15, 2010 7:37 PM >>> To: >>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>> >>>> Hi Mikael, >>>> >>>> sorry for the delay, been away for a few days >>>> >>>> below... >>>> >>>> El 09/03/10 10:46, Mikael Abrahamsson escribió: >>>>> On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: >>>>> >>>>>> but this is what we qualify as a must in the ietf terminology. If >>>>>> you don't do this, the network breaks in different ways, right? >>>>> >>>>> I don't agree that this is a must. This breakage is limited to >>>>> certain operational concerns, it's not a fundamental problem that >>>>> makes it not work at all. >>>>> >>>> Let's go back to RFC 2119 where the usage of these terms is defines: >>>> RFC2119 reads: >>>> >>>> * * >>>> >>>> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the >>>> definition is an absolute requirement of the specification. >>>> >>>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there >>>> may exist valid reasons in particular circumstances to ignore a >>>> particular item, but the full implications must be understood and >>>> carefully weighed before choosing a different course. >>>> >>>> >>>> So, the situation is that if the triggering of the binding creation >>>> by data packet si not implemented, a legitimate user will be >>>> disconnected from the network in case the state is loss or in case >>>> a failure results in a change in the topology. So this actually >>>> affects interoperability. >>>> >>>> The alternative would be a SHOULD properly qualified. >>>> >>>> I think that for the SLAAC/ND case, it is much more likely that the >>>> situation occurs (due to packet loss and the non reliable nature of >>>> the DAD procedure), so i really think that the triggering of the >>>> SAVI binding creation process upon the recpetion of data packets >>>> should be a MUST. >>>> >>>> For the dhcp case, the cases in whcih this fails are reduced >>>> because of the reliable nature of the dhcp exchange, so while i >>>> would rather go for a MUST, i think i can live with a SHOULD. >>>>> One can make the argument that this is a risk taken by the entity >>>>> that chooses to deploy SAVI partially and that SAVI mandates >>>>> things that are needed for a totally SAVI enabled network where >>>>> all devices have this, and in the case not all of them have SAVI >>>>> functionality, then things will break unless a MAY or SHOULD >>>>> clause is implemented? >>>>> >>>> No, a MAY is something that is completelly optional and would not >>>> affect interop in any way. >>>> >>>> As i said above, in the case of dhcp, if the SHOULD is properly >>>> qualified, i could live with that. >>>> >>>> >>>>> I don't like the situation where some vendors might not offer SAVI >>>>> at all, to handle the problem you're describing. >>>>> >>>> Right, i do have this concern as well, but i am very worried about >>>> the impact to the overall robustness fo the network. >>>> >>>> Regards, marcelo >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>> >> > From jmh@joelhalpern.com Mon Mar 15 08:14:31 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418863A6B63 for ; Mon, 15 Mar 2010 08:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYSVYPgkCVmO for ; Mon, 15 Mar 2010 08:14:29 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 8BB5B3A6B6A for ; Mon, 15 Mar 2010 08:14:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 7B9CB32329FF; Mon, 15 Mar 2010 08:14:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-51-231.clppva.btas.verizon.net [71.161.51.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 6E0BD3232823; Mon, 15 Mar 2010 08:14:23 -0700 (PDT) Message-ID: <4B9E4ECF.1050108@joelhalpern.com> Date: Mon, 15 Mar 2010 11:14:23 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> <019C6F3B5F9C4B9F816588E35A440555@junbiVAIO> <4B9E3C24.5060504@it.uc3m.es> <4B9E4A72.2040808@it.uc3m.es> <4B9E4E25.8020807@joelhalpern.com> In-Reply-To: <4B9E4E25.8020807@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 15:14:31 -0000 I realized after sending this that it was not as clear as I would like. One can write SHOULD statements that are not protocol detectable. If they are at least controllable by the implementor. Marcelo has argued cogently that not even the deployer can reliably know if this condition is actually being met. (Which, for the DHCP case, makes storing state in NVRAM a very sensible behavior.) Yours, Joel Joel M. Halpern wrote: > We can write an applicability statement that captures some of this. But, > for this problem, I don't think it will help. Given that the protocol > needs to cover all cases, and the protocol machinery can not tell which > case it is in, then you can't write a SHOULD about it. > > (That is one of the interesting properties of the spanning tree case > Marcelo raised. it is detectable. The device can complain about > inappropriate usage if it actually sees spanning tree coming from a > place it is not prepared to cope with.) > > Yours, > Joel > > marcelo bagnulo braun wrote: >> El 15/03/10 15:28, Bi Jun escribió: >>> I meant please in the guideline, says that your host SHOULD be >>> directly plug to the savi-device. >> >> this is not how the SHOULD work for the specification since this is >> not somehting the protocol MUST/SHOULD implement. >> >> The MUST/SHOULD affects the protocol extensions and not the >> configurations where you use it >> The configurations where you use safely or not are the qualification >> of the SHOULD >> >> Regards, marcelo >> >>> If not, please purchase an higher-end savi-device that implemented >>> the options. >>> >>> thanks, >>> Jun >>> >>> -------------------------------------------------- >>> From: "marcelo bagnulo braun" >>> Sent: Monday, March 15, 2010 9:54 PM >>> To: "Bi Jun" >>> Cc: "SAVI Mailing List" >>> Subject: Re: the impact of SAVI in the overall network robustness >>> (was Re: [savi] dealing with topology changes in dhcp savi >>> >>>> So, if you do discard the packets for which there is no binding, the >>>> overall network robustness is worse, in particular settings where a >>>> redundant topology has been set. >>>> >>>> This seems quite severe to me. >>>> >>>> Regards, marcelo >>>> >>>> >>>> El 15/03/10 13:26, Bi Jun escribió: >>>>> Hi Marcelo, >>>>> >>>>> We can guide the users in this document or in framework, >>>>> if you want to put a hub between savi-device or your host, please >>>>> buy an more expensive savi-device that implemented the xxx options >>>>> functions (e.g the data triggered functions listed in savi-dhcp-02, >>>>> or another solution document). >>>>> >>>>> thanks, >>>>> Jun >>>>> >>>>> -------------------------------------------------- >>>>> From: "marcelo bagnulo braun" >>>>> Sent: Monday, March 15, 2010 8:09 PM >>>>> To: "Bi Jun" >>>>> Cc: "SAVI Mailing List" >>>>> Subject: the impact of SAVI in the overall network robustness (was >>>>> Re: [savi] dealing with topology changes in dhcp savi >>>>> >>>>>> Hi Jun, >>>>>> >>>>>> sorry for the delay, i was away for a few days. >>>>>> >>>>>> Ok, let me rephrase my question then. >>>>>> >>>>>> Suppose that you have the topology that is depicted below, >>>>>> with multiple redundant switches to benefit from robustness. >>>>>> My point is that the introduction of SAVI that is unable to >>>>>> cope with data packets for which there is no binding will >>>>>> reduce the robustness of the network, even if network >>>>>> has been designed to be redundant. >>>>>> >>>>>> In the case SAVI is being deployed in a switched Ethernet network, >>>>>> failures in a single device changes may result in a SAVI device >>>>>> receiving packets from a >>>>>> legitimate user for which the SAVI device does not have a binding >>>>>> for. Consider the following example: >>>>>> >>>>>> >>>>>> >>>>>> +------+ +--------+ +---------------+ >>>>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>>>> +------+ +--------+ +---------------+ >>>>>> | | >>>>>> | +--------+ >>>>>> | | SAVI II| >>>>>> | +--------+ >>>>>> | +----------+ | >>>>>> +---|SWITCH II |-----+ >>>>>> +----------+ >>>>>> | >>>>>> +-----+ >>>>>> | Host| >>>>>> +-----+ >>>>>> >>>>>> >>>>>> The DHCP server is located in the part called rest of the network. >>>>>> Suppose that after bootstrapping all the elements are working >>>>>> properly and the spanning tree is rooted in the router and it >>>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and >>>>>> another >>>>>> branch that goes SWITCH I-SAVI II. >>>>>> >>>>>> Suppose that the Host boots at this moment and perfomrs the >>>>>> DHCP sxchange. >>>>>> The message is propagated through the spanning tree and it >>>>>> received >>>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>>> SAVI I creates the binding. >>>>>> >>>>>> Suppose that SAVI I fails and the spanning tree reconverges to >>>>>> SWITCH >>>>>> I- SAVI II- SWITCH II. Now data packets coming from the Host >>>>>> will be >>>>>> coursed through SAVI II which does not have binding state and will >>>>>> drop the packets. >>>>>> >>>>>> Comments? >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>> >>>>>> El 09/03/10 11:47, Bi Jun escribió: >>>>>>> Hi Marcelo, >>>>>>> >>>>>>> Since you are entitled "topology change", I want to say sth. >>>>>>> Based on our operational experience, if we do a planed topology >>>>>>> change, >>>>>>> then we have to plan we will have more serious problem than this. >>>>>>> So topology change in an operational network is usually carefully >>>>>>> planed. >>>>>>> We don't do it very often, and once we do it, we will let users >>>>>>> understand us. >>>>>>> >>>>>>> So I don't see a problem of planed topology change. The only >>>>>>> thing is the power-down >>>>>>> of a switch, which is really a low frequency event in an >>>>>>> operational network. If we found the power down, we will also >>>>>>> inform users (only users under that switch will be affected, not >>>>>>> all users will be affect) that if you had any problem thank you >>>>>>> please renew your connection. >>>>>>> >>>>>>> thanks, >>>>>>> Jun Bi >>>>>>> >>>>>>> -------------------------------------------------- >>>>>>> From: "marcelo bagnulo braun" >>>>>>> Sent: Tuesday, March 09, 2010 3:51 PM >>>>>>> To: "SAVI Mailing List" >>>>>>> Subject: [savi] dealing with topology changes in dhcp savi >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have another question about dhcp save >>>>>>>> >>>>>>>> How do you handle the following situation? >>>>>>>> >>>>>>>> In the case SAVI is being deployed in a switched Ethernet >>>>>>>> network, >>>>>>>> topology changes may result in a SAVI device receiving >>>>>>>> packets from a >>>>>>>> legitimate user for which the SAVI device does not have a >>>>>>>> binding >>>>>>>> for. Consider the following example: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> +------+ +--------+ +---------------+ >>>>>>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>>>>>> +------+ +--------+ +---------------+ >>>>>>>> | | >>>>>>>> | +--------+ >>>>>>>> | | SAVI II| >>>>>>>> | +--------+ >>>>>>>> | +----------+ | >>>>>>>> +---|SWITCH II |-----+ >>>>>>>> +----------+ >>>>>>>> | >>>>>>>> +-----+ >>>>>>>> | Host| >>>>>>>> +-----+ >>>>>>>> >>>>>>>> >>>>>>>> The DHCP server is located in the part called rest of the >>>>>>>> network. >>>>>>>> Suppose that after bootstrapping all the elements are working >>>>>>>> properly and the spanning tree is rooted in the router and it >>>>>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and >>>>>>>> another >>>>>>>> branch that goes SWITCH I-SAVI II. >>>>>>>> >>>>>>>> Suppose that the Host boots at this moment and perfomrs the >>>>>>>> DHCP sxchange. >>>>>>>> The message is propagated through the spanning tree and it >>>>>>>> received >>>>>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>>>>> SAVI I creates the binding. >>>>>>>> >>>>>>>> Suppose that SAVI I fails and the spanning tree reconverges >>>>>>>> to SWITCH >>>>>>>> I- SAVI II- SWITCH II. Now data packets coming from the Host >>>>>>>> will be >>>>>>>> coursed through SAVI II which does not have binding state and >>>>>>>> will >>>>>>>> drop the packets. >>>>>>>> >>>>>>>> Regards, marcelo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> savi mailing list >>>>>>>> savi@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Mon Mar 15 08:14:33 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C913A6B8B for ; Mon, 15 Mar 2010 08:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.497 X-Spam-Level: X-Spam-Status: No, score=-106.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtzoGW6uYj9E for ; Mon, 15 Mar 2010 08:14:31 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id A1C193A6B6E for ; Mon, 15 Mar 2010 08:14:19 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 2ABAF6C6E26; Mon, 15 Mar 2010 16:14:25 +0100 (CET) Message-ID: <4B9E4ED0.7090508@it.uc3m.es> Date: Mon, 15 Mar 2010 16:14:24 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Bi Jun References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> <019C6F3B5F9C4B9F816588E35A440555@junbiVAIO> <4B9E3C24.5060504@it.uc3m.es> <4B9E4A72.2040808@it.uc3m.es> <63495C88CB4141118DCF796A35192F22@junbiVAIO> In-Reply-To: <63495C88CB4141118DCF796A35192F22@junbiVAIO> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 15:14:33 -0000 Right, this is the applicability of the protocol and does not affect the normative language of the spec. El 15/03/10 15:59, Bi Jun escribió: > > I think everything has it's working condition. > The guideline is part of the RFC to discuss the condition. > For more discussion, please see my another replied email. > > thanks, > Jun > > > > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Monday, March 15, 2010 10:55 PM > To: "Bi Jun" > Cc: "SAVI Mailing List" > Subject: Re: the impact of SAVI in the overall network robustness (was > Re: [savi] dealing with topology changes in dhcp savi > >> El 15/03/10 15:28, Bi Jun escribió: >>> I meant please in the guideline, says that your host SHOULD be >>> directly plug to the savi-device. >> >> this is not how the SHOULD work for the specification since this is >> not somehting the protocol MUST/SHOULD implement. >> >> The MUST/SHOULD affects the protocol extensions and not the >> configurations where you use it >> The configurations where you use safely or not are the qualification >> of the SHOULD >> >> Regards, marcelo >> >>> If not, please purchase an higher-end savi-device that implemented >>> the options. >>> >>> thanks, >>> Jun >>> >>> -------------------------------------------------- >>> From: "marcelo bagnulo braun" >>> Sent: Monday, March 15, 2010 9:54 PM >>> To: "Bi Jun" >>> Cc: "SAVI Mailing List" >>> Subject: Re: the impact of SAVI in the overall network robustness >>> (was Re: [savi] dealing with topology changes in dhcp savi >>> >>>> So, if you do discard the packets for which there is no binding, >>>> the overall network robustness is worse, in particular settings >>>> where a redundant topology has been set. >>>> >>>> This seems quite severe to me. >>>> >>>> Regards, marcelo >>>> >>>> >>>> El 15/03/10 13:26, Bi Jun escribió: >>>>> Hi Marcelo, >>>>> >>>>> We can guide the users in this document or in framework, >>>>> if you want to put a hub between savi-device or your host, please >>>>> buy an more expensive savi-device that implemented the xxx options >>>>> functions (e.g the data triggered functions listed in >>>>> savi-dhcp-02, or another solution document). >>>>> >>>>> thanks, >>>>> Jun >>>>> >>>>> -------------------------------------------------- >>>>> From: "marcelo bagnulo braun" >>>>> Sent: Monday, March 15, 2010 8:09 PM >>>>> To: "Bi Jun" >>>>> Cc: "SAVI Mailing List" >>>>> Subject: the impact of SAVI in the overall network robustness (was >>>>> Re: [savi] dealing with topology changes in dhcp savi >>>>> >>>>>> Hi Jun, >>>>>> >>>>>> sorry for the delay, i was away for a few days. >>>>>> >>>>>> Ok, let me rephrase my question then. >>>>>> >>>>>> Suppose that you have the topology that is depicted below, >>>>>> with multiple redundant switches to benefit from robustness. >>>>>> My point is that the introduction of SAVI that is unable to >>>>>> cope with data packets for which there is no binding will >>>>>> reduce the robustness of the network, even if network >>>>>> has been designed to be redundant. >>>>>> >>>>>> In the case SAVI is being deployed in a switched Ethernet >>>>>> network, >>>>>> failures in a single device changes may result in a SAVI device >>>>>> receiving packets from a >>>>>> legitimate user for which the SAVI device does not have a binding >>>>>> for. Consider the following example: >>>>>> >>>>>> >>>>>> >>>>>> +------+ +--------+ +---------------+ >>>>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>>>> +------+ +--------+ +---------------+ >>>>>> | | >>>>>> | +--------+ >>>>>> | | SAVI II| >>>>>> | +--------+ >>>>>> | +----------+ | >>>>>> +---|SWITCH II |-----+ >>>>>> +----------+ >>>>>> | >>>>>> +-----+ >>>>>> | Host| >>>>>> +-----+ >>>>>> >>>>>> >>>>>> The DHCP server is located in the part called rest of the >>>>>> network. >>>>>> Suppose that after bootstrapping all the elements are working >>>>>> properly and the spanning tree is rooted in the router and it >>>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and >>>>>> another >>>>>> branch that goes SWITCH I-SAVI II. >>>>>> >>>>>> Suppose that the Host boots at this moment and perfomrs the >>>>>> DHCP sxchange. >>>>>> The message is propagated through the spanning tree and it >>>>>> received >>>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>>> SAVI I creates the binding. >>>>>> >>>>>> Suppose that SAVI I fails and the spanning tree reconverges to >>>>>> SWITCH >>>>>> I- SAVI II- SWITCH II. Now data packets coming from the Host >>>>>> will be >>>>>> coursed through SAVI II which does not have binding state and >>>>>> will >>>>>> drop the packets. >>>>>> >>>>>> Comments? >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>> >>>>>> El 09/03/10 11:47, Bi Jun escribió: >>>>>>> Hi Marcelo, >>>>>>> >>>>>>> Since you are entitled "topology change", I want to say sth. >>>>>>> Based on our operational experience, if we do a planed topology >>>>>>> change, >>>>>>> then we have to plan we will have more serious problem than this. >>>>>>> So topology change in an operational network is usually >>>>>>> carefully planed. >>>>>>> We don't do it very often, and once we do it, we will let users >>>>>>> understand us. >>>>>>> >>>>>>> So I don't see a problem of planed topology change. The only >>>>>>> thing is the power-down >>>>>>> of a switch, which is really a low frequency event in an >>>>>>> operational network. If we found the power down, we will also >>>>>>> inform users (only users under that switch will be affected, not >>>>>>> all users will be affect) that if you had any problem thank you >>>>>>> please renew your connection. >>>>>>> >>>>>>> thanks, >>>>>>> Jun Bi >>>>>>> >>>>>>> -------------------------------------------------- >>>>>>> From: "marcelo bagnulo braun" >>>>>>> Sent: Tuesday, March 09, 2010 3:51 PM >>>>>>> To: "SAVI Mailing List" >>>>>>> Subject: [savi] dealing with topology changes in dhcp savi >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have another question about dhcp save >>>>>>>> >>>>>>>> How do you handle the following situation? >>>>>>>> >>>>>>>> In the case SAVI is being deployed in a switched Ethernet >>>>>>>> network, >>>>>>>> topology changes may result in a SAVI device receiving >>>>>>>> packets from a >>>>>>>> legitimate user for which the SAVI device does not have a >>>>>>>> binding >>>>>>>> for. Consider the following example: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> +------+ +--------+ +---------------+ >>>>>>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>>>>>> +------+ +--------+ +---------------+ >>>>>>>> | | >>>>>>>> | +--------+ >>>>>>>> | | SAVI II| >>>>>>>> | +--------+ >>>>>>>> | +----------+ | >>>>>>>> +---|SWITCH II |-----+ >>>>>>>> +----------+ >>>>>>>> | >>>>>>>> +-----+ >>>>>>>> | Host| >>>>>>>> +-----+ >>>>>>>> >>>>>>>> >>>>>>>> The DHCP server is located in the part called rest of the >>>>>>>> network. >>>>>>>> Suppose that after bootstrapping all the elements are working >>>>>>>> properly and the spanning tree is rooted in the router and it >>>>>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and >>>>>>>> another >>>>>>>> branch that goes SWITCH I-SAVI II. >>>>>>>> >>>>>>>> Suppose that the Host boots at this moment and perfomrs the >>>>>>>> DHCP sxchange. >>>>>>>> The message is propagated through the spanning tree and it >>>>>>>> received >>>>>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>>>>> SAVI I creates the binding. >>>>>>>> >>>>>>>> Suppose that SAVI I fails and the spanning tree reconverges >>>>>>>> to SWITCH >>>>>>>> I- SAVI II- SWITCH II. Now data packets coming from the >>>>>>>> Host will be >>>>>>>> coursed through SAVI II which does not have binding state >>>>>>>> and will >>>>>>>> drop the packets. >>>>>>>> >>>>>>>> Regards, marcelo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> savi mailing list >>>>>>>> savi@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From yaoa02@mails.tsinghua.edu.cn Mon Mar 15 08:18:17 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED89C3A683C for ; Mon, 15 Mar 2010 08:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVPQ-cVkK1KL for ; Mon, 15 Mar 2010 08:18:15 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id E55D73A67A8 for ; Mon, 15 Mar 2010 08:18:14 -0700 (PDT) Received: from th211043.ip.tsinghua.edu.cn ([59.66.211.43] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NrC3f-0004sV-CZ; Mon, 15 Mar 2010 23:18:19 +0800 From: "Guang Yao" To: "'Bi Jun'" , "'marcelo bagnulo braun'" References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es> <4B9E1BF3.9080709@it.uc3m.es> <231D9821F3704A09BCB0B166137AA034@junbiVAIO> <4B9E3D5C.6040600@it.uc3m.es> <876F7DBECC2348C695021E77315654F0@junbiVAIO> In-Reply-To: <876F7DBECC2348C695021E77315654F0@junbiVAIO> Date: Mon, 15 Mar 2010 23:18:11 +0800 Message-ID: <001801cac452$b9c52d70$2d4f8850$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrETkxL+CWThC9fSWW0NyMwrYwfVQAAOjEA Content-Language: zh-cn Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 15:18:18 -0000 I'm in favor of two RFCs. Then we can respect the opinion of each other, = at the same time reserve our own options. IMHO, vendors have their market requirements, and they choose carefully between RFCs. Implementing a new RFC may be valueless unless it is = strongly required by market. And on the other hand, if there is requirement for a feature, even there is no RFC doc, it will still be implemented. Thus, I think people should design RFC for real requirements. It's unhonored = that a RFC is rarely implemented, but rather a product supplies some function = not standardized as RFC. BR, Guang > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf = Of Bi > Jun > Sent: Monday, March 15, 2010 10:48 PM > To: marcelo bagnulo braun > Cc: savi@ietf.org > Subject: [savi] savi-dhcp-02 >=20 > Hi Marcelo, >=20 > Hi, Marcelo, >=20 > Here we are actually talking about the trade-off between cost and the > benefits (forgive me that I explained this option many times). If the > solution is just a couple of lines of code, whey not we make it MUST? = But > the truth is that the data-triggered actions are heavy burden to = device > especially low end access switch. If you make them MUST, then you = forbid > those access switches implementing SAVI (those access switch could be = more > than 90% of potential savi-switches). >=20 > So my idea is: > 1 make two RFCs, one for each catalog of functions used for different > scenarios > 2 make one RFC, but make MUST for basic functions, make other = functions as > options. And provide a guideline to users: > (1) If the users want to plus a host directly a savi-device, deploy = cheap > switch only implement MUST > (2) If users want to connect host to a old hub, then connect the hub > savi-device (like the pictures you drown), then if you think = best-effort is > OK for you (if you have problem, reboot your hub or repaired the > host-connection, deploy the cheap switch only implement MUST > (3) in the above case, if you want 100% service quality, then buy a > higher-end savi-device that implement options in this RFC. >=20 > thanks, > Jun > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Monday, March 15, 2010 9:59 PM > To: "Bi Jun" > Cc: > Subject: Re: [savi] call for comments: savi-dhcp-01 >=20 > > El 15/03/10 13:19, Bi Jun escribi=F3: > >> Hi Marcelo, > >> > >> The sentence is misleading. > >> "So, the situation is that if the triggering of the binding = creation by > >> data packet si not implemented, a legitimate user will be = disconnected " > >> > >> It only happens for some situations. > > > > Right, it only happen in some situation, but that is what robustness = is > > about, right? > > I mean, this affects interoperability, becuase it may happen that = the > > communication of a legitimate host is interrupted due to this. > >> If the "MUST" only handles some situation but bring *much more* = cost to > >> the device (it's really because the data-triggered solution is not = a low > >> cost action), > >> then I think the right ways: > >> > >> 1 "MUST" for all cases, and list some limitation and guide the = users. > >> 2 "Options" for some special cases, users has the guide to buy the > >> higher-end device > >> if they want more flexible use of savi device, (certainly, by = paying > >> higher price for the device.). > >> > > As i said, i don't think in any case this is optional. > > > > IMHO, this is a MUST becuase it affect interoperability. > > If there is no consensus to go for a MUST, i can live with, for the = dhcp > > case and only for the dhcp case, since the subset of problematic = cases is > > more limited than the ND case, we could use a qualified SHOULD, = which > > means that the implementation SHOULD do that and we explian what > happens > > if they don't. How about that? > > > > Regards, marcelo > > > > > > > >> That's my answer to all your similar questions. > >> > >> thanks, > >> Jun Bi > >> > >> -------------------------------------------------- > >> From: "marcelo bagnulo braun" > >> Sent: Monday, March 15, 2010 7:37 PM > >> To: > >> Subject: Re: [savi] call for comments: savi-dhcp-01 > >> > >>> Hi Mikael, > >>> > >>> sorry for the delay, been away for a few days > >>> > >>> below... > >>> > >>> El 09/03/10 10:46, Mikael Abrahamsson escribi=F3: > >>>> On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: > >>>> > >>>>> but this is what we qualify as a must in the ietf terminology. = If you > >>>>> don't do this, the network breaks in different ways, right? > >>>> > >>>> I don't agree that this is a must. This breakage is limited to certain > >>>> operational concerns, it's not a fundamental problem that makes = it not > >>>> work at all. > >>>> > >>> Let's go back to RFC 2119 where the usage of these terms is = defines: > >>> RFC2119 reads: > >>> > >>> * * > >>> > >>> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that > the > >>> definition is an absolute requirement of the specification. > >>> > >>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that > there > >>> may exist valid reasons in particular circumstances to ignore a > >>> particular item, but the full implications must be understood = and > >>> carefully weighed before choosing a different course. > >>> > >>> > >>> So, the situation is that if the triggering of the binding = creation by > >>> data packet si not implemented, a legitimate user will be = disconnected > >>> from the network in case the state is loss or in case a failure results > >>> in a change in the topology. So this actually affects interoperability. > >>> > >>> The alternative would be a SHOULD properly qualified. > >>> > >>> I think that for the SLAAC/ND case, it is much more likely that = the > >>> situation occurs (due to packet loss and the non reliable nature = of the > >>> DAD procedure), so i really think that the triggering of the SAVI > >>> binding creation process upon the recpetion of data packets should = be a > >>> MUST. > >>> > >>> For the dhcp case, the cases in whcih this fails are reduced = because of > >>> the reliable nature of the dhcp exchange, so while i would rather = go for > >>> a MUST, i think i can live with a SHOULD. > >>>> One can make the argument that this is a risk taken by the entity that > >>>> chooses to deploy SAVI partially and that SAVI mandates things = that are > >>>> needed for a totally SAVI enabled network where all devices have this, > >>>> and in the case not all of them have SAVI functionality, then = things > >>>> will break unless a MAY or SHOULD clause is implemented? > >>>> > >>> No, a MAY is something that is completelly optional and would not affect > >>> interop in any way. > >>> > >>> As i said above, in the case of dhcp, if the SHOULD is properly > >>> qualified, i could live with that. > >>> > >>> > >>>> I don't like the situation where some vendors might not offer = SAVI at > >>>> all, to handle the problem you're describing. > >>>> > >>> Right, i do have this concern as well, but i am very worried about = the > >>> impact to the overall robustness fo the network. > >>> > >>> Regards, marcelo > >>> > >>> _______________________________________________ > >>> savi mailing list > >>> savi@ietf.org > >>> https://www.ietf.org/mailman/listinfo/savi > >>> > >> > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From junbi@tsinghua.edu.cn Mon Mar 15 08:19:13 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D21B3A67A8 for ; Mon, 15 Mar 2010 08:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo-8rWxrGiiO for ; Mon, 15 Mar 2010 08:19:11 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 1B2503A683C for ; Mon, 15 Mar 2010 08:19:05 -0700 (PDT) Received: from th024139.ip.tsinghua.edu.cn ([59.66.24.139] helo=junbiVAIO) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NrC4U-0004st-Au; Mon, 15 Mar 2010 23:19:10 +0800 Message-ID: From: "Jun Bi" To: "marcelo bagnulo braun" , "Bi Jun" References: <4B95FDE7.8070100@it.uc3m.es><4B9E2382.8000304@it.uc3m.es><019C6F3B5F9C4B9F816588E35A440555@junbiVAIO><4B9E3C24.5060504@it.uc3m.es><4B9E4A72.2040808@it.uc3m.es><63495C88CB4141118DCF796A35192F22@junbiVAIO> <4B9E4ED0.7090508@it.uc3m.es> In-Reply-To: <4B9E4ED0.7090508@it.uc3m.es> Date: Mon, 15 Mar 2010 23:19:12 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 15:19:13 -0000 then you meant all of those functions will be "SHOULD", then state in the applicability section in this rfc? thanks, Jun Bi -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Monday, March 15, 2010 11:14 PM To: "Bi Jun" Cc: "SAVI Mailing List" Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi > Right, this is the applicability of the protocol and does not affect the > normative language of the spec. > > > > El 15/03/10 15:59, Bi Jun escribió: >> >> I think everything has it's working condition. >> The guideline is part of the RFC to discuss the condition. >> For more discussion, please see my another replied email. >> >> thanks, >> Jun >> >> >> >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Monday, March 15, 2010 10:55 PM >> To: "Bi Jun" >> Cc: "SAVI Mailing List" >> Subject: Re: the impact of SAVI in the overall network robustness (was >> Re: [savi] dealing with topology changes in dhcp savi >> >>> El 15/03/10 15:28, Bi Jun escribió: >>>> I meant please in the guideline, says that your host SHOULD be directly >>>> plug to the savi-device. >>> >>> this is not how the SHOULD work for the specification since this is not >>> somehting the protocol MUST/SHOULD implement. >>> >>> The MUST/SHOULD affects the protocol extensions and not the >>> configurations where you use it >>> The configurations where you use safely or not are the qualification of >>> the SHOULD >>> >>> Regards, marcelo >>> >>>> If not, please purchase an higher-end savi-device that implemented the >>>> options. >>>> >>>> thanks, >>>> Jun >>>> >>>> -------------------------------------------------- >>>> From: "marcelo bagnulo braun" >>>> Sent: Monday, March 15, 2010 9:54 PM >>>> To: "Bi Jun" >>>> Cc: "SAVI Mailing List" >>>> Subject: Re: the impact of SAVI in the overall network robustness (was >>>> Re: [savi] dealing with topology changes in dhcp savi >>>> >>>>> So, if you do discard the packets for which there is no binding, the >>>>> overall network robustness is worse, in particular settings where a >>>>> redundant topology has been set. >>>>> >>>>> This seems quite severe to me. >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>> El 15/03/10 13:26, Bi Jun escribió: >>>>>> Hi Marcelo, >>>>>> >>>>>> We can guide the users in this document or in framework, >>>>>> if you want to put a hub between savi-device or your host, please buy >>>>>> an more expensive savi-device that implemented the xxx options >>>>>> functions (e.g the data triggered functions listed in savi-dhcp-02, >>>>>> or another solution document). >>>>>> >>>>>> thanks, >>>>>> Jun >>>>>> >>>>>> -------------------------------------------------- >>>>>> From: "marcelo bagnulo braun" >>>>>> Sent: Monday, March 15, 2010 8:09 PM >>>>>> To: "Bi Jun" >>>>>> Cc: "SAVI Mailing List" >>>>>> Subject: the impact of SAVI in the overall network robustness (was >>>>>> Re: [savi] dealing with topology changes in dhcp savi >>>>>> >>>>>>> Hi Jun, >>>>>>> >>>>>>> sorry for the delay, i was away for a few days. >>>>>>> >>>>>>> Ok, let me rephrase my question then. >>>>>>> >>>>>>> Suppose that you have the topology that is depicted below, >>>>>>> with multiple redundant switches to benefit from robustness. >>>>>>> My point is that the introduction of SAVI that is unable to >>>>>>> cope with data packets for which there is no binding will >>>>>>> reduce the robustness of the network, even if network >>>>>>> has been designed to be redundant. >>>>>>> >>>>>>> In the case SAVI is being deployed in a switched Ethernet >>>>>>> network, >>>>>>> failures in a single device changes may result in a SAVI device >>>>>>> receiving packets from a >>>>>>> legitimate user for which the SAVI device does not have a binding >>>>>>> for. Consider the following example: >>>>>>> >>>>>>> >>>>>>> >>>>>>> +------+ +--------+ +---------------+ >>>>>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>>>>> +------+ +--------+ +---------------+ >>>>>>> | | >>>>>>> | +--------+ >>>>>>> | | SAVI II| >>>>>>> | +--------+ >>>>>>> | +----------+ | >>>>>>> +---|SWITCH II |-----+ >>>>>>> +----------+ >>>>>>> | >>>>>>> +-----+ >>>>>>> | Host| >>>>>>> +-----+ >>>>>>> >>>>>>> >>>>>>> The DHCP server is located in the part called rest of the >>>>>>> network. >>>>>>> Suppose that after bootstrapping all the elements are working >>>>>>> properly and the spanning tree is rooted in the router and it >>>>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and >>>>>>> another >>>>>>> branch that goes SWITCH I-SAVI II. >>>>>>> >>>>>>> Suppose that the Host boots at this moment and perfomrs the DHCP >>>>>>> sxchange. >>>>>>> The message is propagated through the spanning tree and it >>>>>>> received >>>>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>>>> SAVI I creates the binding. >>>>>>> >>>>>>> Suppose that SAVI I fails and the spanning tree reconverges to >>>>>>> SWITCH >>>>>>> I- SAVI II- SWITCH II. Now data packets coming from the Host >>>>>>> will be >>>>>>> coursed through SAVI II which does not have binding state and >>>>>>> will >>>>>>> drop the packets. >>>>>>> >>>>>>> Comments? >>>>>>> >>>>>>> Regards, marcelo >>>>>>> >>>>>>> >>>>>>> >>>>>>> El 09/03/10 11:47, Bi Jun escribió: >>>>>>>> Hi Marcelo, >>>>>>>> >>>>>>>> Since you are entitled "topology change", I want to say sth. >>>>>>>> Based on our operational experience, if we do a planed topology >>>>>>>> change, >>>>>>>> then we have to plan we will have more serious problem than this. >>>>>>>> So topology change in an operational network is usually carefully >>>>>>>> planed. >>>>>>>> We don't do it very often, and once we do it, we will let users >>>>>>>> understand us. >>>>>>>> >>>>>>>> So I don't see a problem of planed topology change. The only thing >>>>>>>> is the power-down >>>>>>>> of a switch, which is really a low frequency event in an >>>>>>>> operational network. If we found the power down, we will also >>>>>>>> inform users (only users under that switch will be affected, not >>>>>>>> all users will be affect) that if you had any problem thank you >>>>>>>> please renew your connection. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Jun Bi >>>>>>>> >>>>>>>> -------------------------------------------------- >>>>>>>> From: "marcelo bagnulo braun" >>>>>>>> Sent: Tuesday, March 09, 2010 3:51 PM >>>>>>>> To: "SAVI Mailing List" >>>>>>>> Subject: [savi] dealing with topology changes in dhcp savi >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I have another question about dhcp save >>>>>>>>> >>>>>>>>> How do you handle the following situation? >>>>>>>>> >>>>>>>>> In the case SAVI is being deployed in a switched Ethernet >>>>>>>>> network, >>>>>>>>> topology changes may result in a SAVI device receiving packets >>>>>>>>> from a >>>>>>>>> legitimate user for which the SAVI device does not have a >>>>>>>>> binding >>>>>>>>> for. Consider the following example: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> +------+ +--------+ +---------------+ >>>>>>>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>>>>>>> +------+ +--------+ +---------------+ >>>>>>>>> | | >>>>>>>>> | +--------+ >>>>>>>>> | | SAVI II| >>>>>>>>> | +--------+ >>>>>>>>> | +----------+ | >>>>>>>>> +---|SWITCH II |-----+ >>>>>>>>> +----------+ >>>>>>>>> | >>>>>>>>> +-----+ >>>>>>>>> | Host| >>>>>>>>> +-----+ >>>>>>>>> >>>>>>>>> >>>>>>>>> The DHCP server is located in the part called rest of the >>>>>>>>> network. >>>>>>>>> Suppose that after bootstrapping all the elements are working >>>>>>>>> properly and the spanning tree is rooted in the router and it >>>>>>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and >>>>>>>>> another >>>>>>>>> branch that goes SWITCH I-SAVI II. >>>>>>>>> >>>>>>>>> Suppose that the Host boots at this moment and perfomrs the >>>>>>>>> DHCP sxchange. >>>>>>>>> The message is propagated through the spanning tree and it >>>>>>>>> received >>>>>>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>>>>>> SAVI I creates the binding. >>>>>>>>> >>>>>>>>> Suppose that SAVI I fails and the spanning tree reconverges to >>>>>>>>> SWITCH >>>>>>>>> I- SAVI II- SWITCH II. Now data packets coming from the Host >>>>>>>>> will be >>>>>>>>> coursed through SAVI II which does not have binding state and >>>>>>>>> will >>>>>>>>> drop the packets. >>>>>>>>> >>>>>>>>> Regards, marcelo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> savi mailing list >>>>>>>>> savi@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@tsinghua.edu.cn Mon Mar 15 08:27:01 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91FB73A6B75 for ; Mon, 15 Mar 2010 08:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwcNZgc55IX7 for ; Mon, 15 Mar 2010 08:27:00 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id A699F3A698F for ; Mon, 15 Mar 2010 08:26:58 -0700 (PDT) Received: from th024139.ip.tsinghua.edu.cn ([59.66.24.139] helo=junbiVAIO) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NrCC7-0006lq-1M; Mon, 15 Mar 2010 23:27:03 +0800 Message-ID: <0F84A919BFA04A5CB05C6010251A11B3@junbiVAIO> From: "Jun Bi" To: "marcelo bagnulo braun" , "Bi Jun" References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es><4B9E1BF3.9080709@it.uc3m.es><231D9821F3704A09BCB0B166137AA034@junbiVAIO><4B9E3D5C.6040600@it.uc3m.es><876F7DBECC2348C695021E77315654F0@junbiVAIO> <4B9E4E84.1090003@it.uc3m.es> In-Reply-To: <4B9E4E84.1090003@it.uc3m.es> Date: Mon, 15 Mar 2010 23:27:04 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 15:27:01 -0000 -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Monday, March 15, 2010 11:13 PM To: "Bi Jun" Cc: Subject: Re: [savi] savi-dhcp-02 > Hi Jun, > > What i am talking about is how the deployment of the different SAVI > solution will affect the overall robustness and performance of the > Internet architecture. One of the tasks of the IETF and of the IAB is to > preserve the overall Internet architecture and to keep its fundamental > design principles that have granted a robust Internet. > > My concern is that a SAVI solution that blindly drops data packets for > which it has no binding for woudl deter the reliability of the network as > a whole and we shouldn't allow that. > > So, that being said, let me comment on som particular comments you make. > > Below... > > El 15/03/10 15:48, Bi Jun escribió: >> Hi Marcelo, >> >> Hi, Marcelo, >> >> Here we are actually talking about the trade-off between cost and the >> benefits (forgive me that I explained this option many times). If the >> solution is just a couple of lines of code, whey not we make it MUST? But >> the truth is that the data-triggered actions are heavy burden to device >> especially low end access switch. If you make them MUST, then you forbid >> those access switches implementing SAVI (those access switch could be >> more than 90% of potential savi-switches). >> > Where did you get this figure from? > The feedback that i have got form vendors is that they would be able to > implement it as long as it is rate limited. Oh really? Please provide me who said that. You know CNGI-CERNET2 is deploying savi in large scale in 100 universities. If any vendor implements data-triggered functions in low-end access switch (we use those switch to directly connect hosts) with the same price as the savi access switch that implemented control-packet triggered functions (we purchased about 50000 savi-switches), we'd like to buy more from this new vendor. thanks! Jun >> So my idea is: >> 1 make two RFCs, one for each catalog of functions used for different >> scenarios. >> 2 make one RFC, but make MUST for basic functions, make other functions >> as options. And provide a guideline to users: >> (1) If the users want to plus a host directly a savi-device, deploy cheap >> switch only implement MUST >> (2) If users want to connect host to a old hub, then connect the hub >> savi-device (like the pictures you drown), then if you think best-effort >> is OK for you (if you have problem, reboot your hub or repaired the >> host-connection, deploy the cheap switch only implement MUST >> (3) in the above case, if you want 100% service quality, then buy a >> higher-end savi-device that implement options in this RFC. >> > Actually, i don't agree with this approach. I think we have the normative > language as specified in RFC 2116 exactly to deal with this type of > situations. > I don't want to have all the SAVI funcionality spread over more RFCs, we > already have split the SAVI spec in more than we should and i don't think > it would make sense to divide it even more. > > I think we need to have one RFC for dhcp savi and one for SLAAC savi > > We need to agree on what features are MUST and which ones are SHOULD. > > As i suggested already,. imho the triggering of the binding creation > mechanisms upon the reception of a data packet for whcih there is no > binding should be a MUST for both cases. > > I could live with a qualified SHOULD for the DHCP case and a MUST for the > SLAAC case, based on the faact that the DHCP exchange is reliable and > hence the problem of packet loss is not an issue for the DHCP case while > it is so for the SLAAC case > > I think i could also live with Guang's suggestion of having A MUST for > both cases and also require as a MUST that the feature MUST be > configurable on/off > > Regards, marcelo > >> thanks, >> Jun >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Monday, March 15, 2010 9:59 PM >> To: "Bi Jun" >> Cc: >> Subject: Re: [savi] call for comments: savi-dhcp-01 >> >>> El 15/03/10 13:19, Bi Jun escribió: >>>> Hi Marcelo, >>>> >>>> The sentence is misleading. >>>> "So, the situation is that if the triggering of the binding creation by >>>> data packet si not implemented, a legitimate user will be disconnected >>>> " >>>> >>>> It only happens for some situations. >>> >>> Right, it only happen in some situation, but that is what robustness is >>> about, right? >>> I mean, this affects interoperability, becuase it may happen that the >>> communication of a legitimate host is interrupted due to this. >>>> If the "MUST" only handles some situation but bring *much more* cost to >>>> the device (it's really because the data-triggered solution is not a >>>> low cost action), >>>> then I think the right ways: >>>> >>>> 1 "MUST" for all cases, and list some limitation and guide the users. >>>> 2 "Options" for some special cases, users has the guide to buy the >>>> higher-end device >>>> if they want more flexible use of savi device, (certainly, by paying >>>> higher price for the device.). >>>> >>> As i said, i don't think in any case this is optional. >>> >>> IMHO, this is a MUST becuase it affect interoperability. >>> If there is no consensus to go for a MUST, i can live with, for the dhcp >>> case and only for the dhcp case, since the subset of problematic cases >>> is more limited than the ND case, we could use a qualified SHOULD, which >>> means that the implementation SHOULD do that and we explian what happens >>> if they don't. How about that? >>> >>> Regards, marcelo >>> >>> >>> >>>> That's my answer to all your similar questions. >>>> >>>> thanks, >>>> Jun Bi >>>> >>>> -------------------------------------------------- >>>> From: "marcelo bagnulo braun" >>>> Sent: Monday, March 15, 2010 7:37 PM >>>> To: >>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>> >>>>> Hi Mikael, >>>>> >>>>> sorry for the delay, been away for a few days >>>>> >>>>> below... >>>>> >>>>> El 09/03/10 10:46, Mikael Abrahamsson escribió: >>>>>> On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: >>>>>> >>>>>>> but this is what we qualify as a must in the ietf terminology. If >>>>>>> you don't do this, the network breaks in different ways, right? >>>>>> >>>>>> I don't agree that this is a must. This breakage is limited to >>>>>> certain operational concerns, it's not a fundamental problem that >>>>>> makes it not work at all. >>>>>> >>>>> Let's go back to RFC 2119 where the usage of these terms is defines: >>>>> RFC2119 reads: >>>>> >>>>> * * >>>>> >>>>> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the >>>>> definition is an absolute requirement of the specification. >>>>> >>>>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there >>>>> may exist valid reasons in particular circumstances to ignore a >>>>> particular item, but the full implications must be understood and >>>>> carefully weighed before choosing a different course. >>>>> >>>>> >>>>> So, the situation is that if the triggering of the binding creation by >>>>> data packet si not implemented, a legitimate user will be disconnected >>>>> from the network in case the state is loss or in case a failure >>>>> results in a change in the topology. So this actually affects >>>>> interoperability. >>>>> >>>>> The alternative would be a SHOULD properly qualified. >>>>> >>>>> I think that for the SLAAC/ND case, it is much more likely that the >>>>> situation occurs (due to packet loss and the non reliable nature of >>>>> the DAD procedure), so i really think that the triggering of the SAVI >>>>> binding creation process upon the recpetion of data packets should be >>>>> a MUST. >>>>> >>>>> For the dhcp case, the cases in whcih this fails are reduced because >>>>> of the reliable nature of the dhcp exchange, so while i would rather >>>>> go for a MUST, i think i can live with a SHOULD. >>>>>> One can make the argument that this is a risk taken by the entity >>>>>> that chooses to deploy SAVI partially and that SAVI mandates things >>>>>> that are needed for a totally SAVI enabled network where all devices >>>>>> have this, and in the case not all of them have SAVI functionality, >>>>>> then things will break unless a MAY or SHOULD clause is implemented? >>>>>> >>>>> No, a MAY is something that is completelly optional and would not >>>>> affect interop in any way. >>>>> >>>>> As i said above, in the case of dhcp, if the SHOULD is properly >>>>> qualified, i could live with that. >>>>> >>>>> >>>>>> I don't like the situation where some vendors might not offer SAVI at >>>>>> all, to handle the problem you're describing. >>>>>> >>>>> Right, i do have this concern as well, but i am very worried about the >>>>> impact to the overall robustness fo the network. >>>>> >>>>> Regards, marcelo >>>>> >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>> >>> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@cernet.edu.cn Mon Mar 15 08:33:30 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5EB3A68EC for ; Mon, 15 Mar 2010 08:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.277 X-Spam-Level: X-Spam-Status: No, score=0.277 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1BkElqXOzXz for ; Mon, 15 Mar 2010 08:33:29 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id F10633A6856 for ; Mon, 15 Mar 2010 08:33:27 -0700 (PDT) Received: from junbiVAIO([59.66.24.139]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmf4b9ec62c; Mon, 15 Mar 2010 23:33:32 +0800 Message-ID: <532B9E07F0DD426FBABA96E6FF6E97AF@junbiVAIO> From: "Bi Jun" To: "Jun Bi" , "marcelo bagnulo braun" References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es><4B9E1BF3.9080709@it.uc3m.es><231D9821F3704A09BCB0B166137AA034@junbiVAIO><4B9E3D5C.6040600@it.uc3m.es><876F7DBECC2348C695021E77315654F0@junbiVAIO> <4B9E4E84.1090003@it.uc3m.es> <0F84A919BFA04A5CB05C6010251A11B3@junbiVAIO> In-Reply-To: <0F84A919BFA04A5CB05C6010251A11B3@junbiVAIO> Date: Mon, 15 Mar 2010 23:33:25 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: UrYSMrXB Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 15:33:30 -0000 By the way, the 50000 savi-switch we purchased cost 200-400USD each, with 24 10/100M + 2 GE uplink ports. thanks, Jun Bi -------------------------------------------------- From: "Jun Bi" Sent: Monday, March 15, 2010 11:27 PM To: "marcelo bagnulo braun" ; "Bi Jun" Cc: Subject: Re: [savi] savi-dhcp-02 > > > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Monday, March 15, 2010 11:13 PM > To: "Bi Jun" > Cc: > Subject: Re: [savi] savi-dhcp-02 > >> Hi Jun, >> >> What i am talking about is how the deployment of the different SAVI >> solution will affect the overall robustness and performance of the >> Internet architecture. One of the tasks of the IETF and of the IAB is to >> preserve the overall Internet architecture and to keep its fundamental >> design principles that have granted a robust Internet. >> >> My concern is that a SAVI solution that blindly drops data packets for >> which it has no binding for woudl deter the reliability of the network as >> a whole and we shouldn't allow that. >> >> So, that being said, let me comment on som particular comments you make. >> >> Below... >> >> El 15/03/10 15:48, Bi Jun escribió: >>> Hi Marcelo, >>> >>> Hi, Marcelo, >>> >>> Here we are actually talking about the trade-off between cost and the >>> benefits (forgive me that I explained this option many times). If the >>> solution is just a couple of lines of code, whey not we make it MUST? >>> But the truth is that the data-triggered actions are heavy burden to >>> device especially low end access switch. If you make them MUST, then you >>> forbid those access switches implementing SAVI (those access switch >>> could be more than 90% of potential savi-switches). >>> >> Where did you get this figure from? >> The feedback that i have got form vendors is that they would be able to >> implement it as long as it is rate limited. > > > > Oh really? Please provide me who said that. You know CNGI-CERNET2 is > deploying savi > in large scale in 100 universities. If any vendor implements > data-triggered > functions in low-end access switch (we use those switch to directly > connect hosts) > with the same price as the savi access switch that implemented > control-packet triggered functions (we purchased about 50000 > savi-switches), we'd like to buy more from this new vendor. > > thanks! > Jun > > > > >>> So my idea is: >>> 1 make two RFCs, one for each catalog of functions used for different >>> scenarios. >>> 2 make one RFC, but make MUST for basic functions, make other functions >>> as options. And provide a guideline to users: >>> (1) If the users want to plus a host directly a savi-device, deploy >>> cheap switch only implement MUST >>> (2) If users want to connect host to a old hub, then connect the hub >>> savi-device (like the pictures you drown), then if you think best-effort >>> is OK for you (if you have problem, reboot your hub or repaired the >>> host-connection, deploy the cheap switch only implement MUST >>> (3) in the above case, if you want 100% service quality, then buy a >>> higher-end savi-device that implement options in this RFC. >>> >> Actually, i don't agree with this approach. I think we have the normative >> language as specified in RFC 2116 exactly to deal with this type of >> situations. >> I don't want to have all the SAVI funcionality spread over more RFCs, we >> already have split the SAVI spec in more than we should and i don't think >> it would make sense to divide it even more. >> >> I think we need to have one RFC for dhcp savi and one for SLAAC savi >> >> We need to agree on what features are MUST and which ones are SHOULD. >> >> As i suggested already,. imho the triggering of the binding creation >> mechanisms upon the reception of a data packet for whcih there is no >> binding should be a MUST for both cases. >> >> I could live with a qualified SHOULD for the DHCP case and a MUST for the >> SLAAC case, based on the faact that the DHCP exchange is reliable and >> hence the problem of packet loss is not an issue for the DHCP case while >> it is so for the SLAAC case >> >> I think i could also live with Guang's suggestion of having A MUST for >> both cases and also require as a MUST that the feature MUST be >> configurable on/off >> >> Regards, marcelo >> >>> thanks, >>> Jun >>> -------------------------------------------------- >>> From: "marcelo bagnulo braun" >>> Sent: Monday, March 15, 2010 9:59 PM >>> To: "Bi Jun" >>> Cc: >>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>> >>>> El 15/03/10 13:19, Bi Jun escribió: >>>>> Hi Marcelo, >>>>> >>>>> The sentence is misleading. >>>>> "So, the situation is that if the triggering of the binding creation >>>>> by >>>>> data packet si not implemented, a legitimate user will be disconnected >>>>> " >>>>> >>>>> It only happens for some situations. >>>> >>>> Right, it only happen in some situation, but that is what robustness is >>>> about, right? >>>> I mean, this affects interoperability, becuase it may happen that the >>>> communication of a legitimate host is interrupted due to this. >>>>> If the "MUST" only handles some situation but bring *much more* cost >>>>> to the device (it's really because the data-triggered solution is not >>>>> a low cost action), >>>>> then I think the right ways: >>>>> >>>>> 1 "MUST" for all cases, and list some limitation and guide the users. >>>>> 2 "Options" for some special cases, users has the guide to buy the >>>>> higher-end device >>>>> if they want more flexible use of savi device, (certainly, by paying >>>>> higher price for the device.). >>>>> >>>> As i said, i don't think in any case this is optional. >>>> >>>> IMHO, this is a MUST becuase it affect interoperability. >>>> If there is no consensus to go for a MUST, i can live with, for the >>>> dhcp case and only for the dhcp case, since the subset of problematic >>>> cases is more limited than the ND case, we could use a qualified >>>> SHOULD, which means that the implementation SHOULD do that and we >>>> explian what happens if they don't. How about that? >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>>> That's my answer to all your similar questions. >>>>> >>>>> thanks, >>>>> Jun Bi >>>>> >>>>> -------------------------------------------------- >>>>> From: "marcelo bagnulo braun" >>>>> Sent: Monday, March 15, 2010 7:37 PM >>>>> To: >>>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>>> >>>>>> Hi Mikael, >>>>>> >>>>>> sorry for the delay, been away for a few days >>>>>> >>>>>> below... >>>>>> >>>>>> El 09/03/10 10:46, Mikael Abrahamsson escribió: >>>>>>> On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: >>>>>>> >>>>>>>> but this is what we qualify as a must in the ietf terminology. If >>>>>>>> you don't do this, the network breaks in different ways, right? >>>>>>> >>>>>>> I don't agree that this is a must. This breakage is limited to >>>>>>> certain operational concerns, it's not a fundamental problem that >>>>>>> makes it not work at all. >>>>>>> >>>>>> Let's go back to RFC 2119 where the usage of these terms is defines: >>>>>> RFC2119 reads: >>>>>> >>>>>> * * >>>>>> >>>>>> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that >>>>>> the >>>>>> definition is an absolute requirement of the specification. >>>>>> >>>>>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that >>>>>> there >>>>>> may exist valid reasons in particular circumstances to ignore a >>>>>> particular item, but the full implications must be understood and >>>>>> carefully weighed before choosing a different course. >>>>>> >>>>>> >>>>>> So, the situation is that if the triggering of the binding creation >>>>>> by data packet si not implemented, a legitimate user will be >>>>>> disconnected from the network in case the state is loss or in case a >>>>>> failure results in a change in the topology. So this actually affects >>>>>> interoperability. >>>>>> >>>>>> The alternative would be a SHOULD properly qualified. >>>>>> >>>>>> I think that for the SLAAC/ND case, it is much more likely that the >>>>>> situation occurs (due to packet loss and the non reliable nature of >>>>>> the DAD procedure), so i really think that the triggering of the SAVI >>>>>> binding creation process upon the recpetion of data packets should be >>>>>> a MUST. >>>>>> >>>>>> For the dhcp case, the cases in whcih this fails are reduced because >>>>>> of the reliable nature of the dhcp exchange, so while i would rather >>>>>> go for a MUST, i think i can live with a SHOULD. >>>>>>> One can make the argument that this is a risk taken by the entity >>>>>>> that chooses to deploy SAVI partially and that SAVI mandates things >>>>>>> that are needed for a totally SAVI enabled network where all devices >>>>>>> have this, and in the case not all of them have SAVI functionality, >>>>>>> then things will break unless a MAY or SHOULD clause is implemented? >>>>>>> >>>>>> No, a MAY is something that is completelly optional and would not >>>>>> affect interop in any way. >>>>>> >>>>>> As i said above, in the case of dhcp, if the SHOULD is properly >>>>>> qualified, i could live with that. >>>>>> >>>>>> >>>>>>> I don't like the situation where some vendors might not offer SAVI >>>>>>> at all, to handle the problem you're describing. >>>>>>> >>>>>> Right, i do have this concern as well, but i am very worried about >>>>>> the impact to the overall robustness fo the network. >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > From marcelo@it.uc3m.es Mon Mar 15 08:52:45 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B54193A6856 for ; Mon, 15 Mar 2010 08:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pih1c0TDbJhO for ; Mon, 15 Mar 2010 08:52:44 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 5E1AB3A63D3 for ; Mon, 15 Mar 2010 08:52:40 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id A683B6563A5; Mon, 15 Mar 2010 16:52:46 +0100 (CET) Message-ID: <4B9E57CE.5010901@it.uc3m.es> Date: Mon, 15 Mar 2010 16:52:46 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Jun Bi References: <4B95FDE7.8070100@it.uc3m.es><4B9E2382.8000304@it.uc3m.es><019C6F3B5F9C4B9F816588E35A440555@junbiVAIO><4B9E3C24.5060504@it.uc3m.es><4B9E4A72.2040808@it.uc3m.es><63495C88CB4141118DCF796A35192F22@junbiVAIO> <4B9E4ED0.7090508@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 15:52:45 -0000 mmm, not sure if i understand exactly what you mean, but i think yes We need to decide which features are MUST and which ones are should. then we need to qualify the SHOULDs, which can be complemented by an applicability statement. So, for the dhcp savi case, i can live with including the feature of triggering the binding creation process upon the reception of data packets as a should and then qualify it by describing what it would break if this is not implemented and what configurations would have suffer less problems regards, marcelo El 15/03/10 16:19, Jun Bi escribió: > then you meant all of those functions will be "SHOULD", then state in > the applicability section in this rfc? > > thanks, > Jun Bi > > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Monday, March 15, 2010 11:14 PM > To: "Bi Jun" > Cc: "SAVI Mailing List" > Subject: Re: [savi] the impact of SAVI in the overall network > robustness (was Re: dealing with topology changes in dhcp savi > >> Right, this is the applicability of the protocol and does not affect >> the normative language of the spec. >> >> >> >> El 15/03/10 15:59, Bi Jun escribió: >>> >>> I think everything has it's working condition. >>> The guideline is part of the RFC to discuss the condition. >>> For more discussion, please see my another replied email. >>> >>> thanks, >>> Jun >>> >>> >>> >>> -------------------------------------------------- >>> From: "marcelo bagnulo braun" >>> Sent: Monday, March 15, 2010 10:55 PM >>> To: "Bi Jun" >>> Cc: "SAVI Mailing List" >>> Subject: Re: the impact of SAVI in the overall network robustness >>> (was Re: [savi] dealing with topology changes in dhcp savi >>> >>>> El 15/03/10 15:28, Bi Jun escribió: >>>>> I meant please in the guideline, says that your host SHOULD be >>>>> directly plug to the savi-device. >>>> >>>> this is not how the SHOULD work for the specification since this is >>>> not somehting the protocol MUST/SHOULD implement. >>>> >>>> The MUST/SHOULD affects the protocol extensions and not the >>>> configurations where you use it >>>> The configurations where you use safely or not are the >>>> qualification of the SHOULD >>>> >>>> Regards, marcelo >>>> >>>>> If not, please purchase an higher-end savi-device that implemented >>>>> the options. >>>>> >>>>> thanks, >>>>> Jun >>>>> >>>>> -------------------------------------------------- >>>>> From: "marcelo bagnulo braun" >>>>> Sent: Monday, March 15, 2010 9:54 PM >>>>> To: "Bi Jun" >>>>> Cc: "SAVI Mailing List" >>>>> Subject: Re: the impact of SAVI in the overall network robustness >>>>> (was Re: [savi] dealing with topology changes in dhcp savi >>>>> >>>>>> So, if you do discard the packets for which there is no binding, >>>>>> the overall network robustness is worse, in particular settings >>>>>> where a redundant topology has been set. >>>>>> >>>>>> This seems quite severe to me. >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>> El 15/03/10 13:26, Bi Jun escribió: >>>>>>> Hi Marcelo, >>>>>>> >>>>>>> We can guide the users in this document or in framework, >>>>>>> if you want to put a hub between savi-device or your host, >>>>>>> please buy an more expensive savi-device that implemented the >>>>>>> xxx options functions (e.g the data triggered functions listed >>>>>>> in savi-dhcp-02, or another solution document). >>>>>>> >>>>>>> thanks, >>>>>>> Jun >>>>>>> >>>>>>> -------------------------------------------------- >>>>>>> From: "marcelo bagnulo braun" >>>>>>> Sent: Monday, March 15, 2010 8:09 PM >>>>>>> To: "Bi Jun" >>>>>>> Cc: "SAVI Mailing List" >>>>>>> Subject: the impact of SAVI in the overall network robustness >>>>>>> (was Re: [savi] dealing with topology changes in dhcp savi >>>>>>> >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> sorry for the delay, i was away for a few days. >>>>>>>> >>>>>>>> Ok, let me rephrase my question then. >>>>>>>> >>>>>>>> Suppose that you have the topology that is depicted below, >>>>>>>> with multiple redundant switches to benefit from robustness. >>>>>>>> My point is that the introduction of SAVI that is unable to >>>>>>>> cope with data packets for which there is no binding will >>>>>>>> reduce the robustness of the network, even if network >>>>>>>> has been designed to be redundant. >>>>>>>> >>>>>>>> In the case SAVI is being deployed in a switched Ethernet >>>>>>>> network, >>>>>>>> failures in a single device changes may result in a SAVI device >>>>>>>> receiving packets from a >>>>>>>> legitimate user for which the SAVI device does not have a >>>>>>>> binding >>>>>>>> for. Consider the following example: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> +------+ +--------+ +---------------+ >>>>>>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>>>>>> +------+ +--------+ +---------------+ >>>>>>>> | | >>>>>>>> | +--------+ >>>>>>>> | | SAVI II| >>>>>>>> | +--------+ >>>>>>>> | +----------+ | >>>>>>>> +---|SWITCH II |-----+ >>>>>>>> +----------+ >>>>>>>> | >>>>>>>> +-----+ >>>>>>>> | Host| >>>>>>>> +-----+ >>>>>>>> >>>>>>>> >>>>>>>> The DHCP server is located in the part called rest of the >>>>>>>> network. >>>>>>>> Suppose that after bootstrapping all the elements are working >>>>>>>> properly and the spanning tree is rooted in the router and it >>>>>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and >>>>>>>> another >>>>>>>> branch that goes SWITCH I-SAVI II. >>>>>>>> >>>>>>>> Suppose that the Host boots at this moment and perfomrs the >>>>>>>> DHCP sxchange. >>>>>>>> The message is propagated through the spanning tree and it >>>>>>>> received >>>>>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>>>>> SAVI I creates the binding. >>>>>>>> >>>>>>>> Suppose that SAVI I fails and the spanning tree reconverges >>>>>>>> to SWITCH >>>>>>>> I- SAVI II- SWITCH II. Now data packets coming from the >>>>>>>> Host will be >>>>>>>> coursed through SAVI II which does not have binding state >>>>>>>> and will >>>>>>>> drop the packets. >>>>>>>> >>>>>>>> Comments? >>>>>>>> >>>>>>>> Regards, marcelo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> El 09/03/10 11:47, Bi Jun escribió: >>>>>>>>> Hi Marcelo, >>>>>>>>> >>>>>>>>> Since you are entitled "topology change", I want to say sth. >>>>>>>>> Based on our operational experience, if we do a planed >>>>>>>>> topology change, >>>>>>>>> then we have to plan we will have more serious problem than this. >>>>>>>>> So topology change in an operational network is usually >>>>>>>>> carefully planed. >>>>>>>>> We don't do it very often, and once we do it, we will let >>>>>>>>> users understand us. >>>>>>>>> >>>>>>>>> So I don't see a problem of planed topology change. The only >>>>>>>>> thing is the power-down >>>>>>>>> of a switch, which is really a low frequency event in an >>>>>>>>> operational network. If we found the power down, we will also >>>>>>>>> inform users (only users under that switch will be affected, >>>>>>>>> not all users will be affect) that if you had any problem >>>>>>>>> thank you please renew your connection. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Jun Bi >>>>>>>>> >>>>>>>>> -------------------------------------------------- >>>>>>>>> From: "marcelo bagnulo braun" >>>>>>>>> Sent: Tuesday, March 09, 2010 3:51 PM >>>>>>>>> To: "SAVI Mailing List" >>>>>>>>> Subject: [savi] dealing with topology changes in dhcp savi >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I have another question about dhcp save >>>>>>>>>> >>>>>>>>>> How do you handle the following situation? >>>>>>>>>> >>>>>>>>>> In the case SAVI is being deployed in a switched Ethernet >>>>>>>>>> network, >>>>>>>>>> topology changes may result in a SAVI device receiving >>>>>>>>>> packets from a >>>>>>>>>> legitimate user for which the SAVI device does not have a >>>>>>>>>> binding >>>>>>>>>> for. Consider the following example: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> +------+ +--------+ >>>>>>>>>> +---------------+ >>>>>>>>>> |SAVI I|-------------|SWITCH I|-------|rest of the >>>>>>>>>> net| >>>>>>>>>> +------+ +--------+ >>>>>>>>>> +---------------+ >>>>>>>>>> | | >>>>>>>>>> | +--------+ >>>>>>>>>> | | SAVI II| >>>>>>>>>> | +--------+ >>>>>>>>>> | +----------+ | >>>>>>>>>> +---|SWITCH II |-----+ >>>>>>>>>> +----------+ >>>>>>>>>> | >>>>>>>>>> +-----+ >>>>>>>>>> | Host| >>>>>>>>>> +-----+ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The DHCP server is located in the part called rest of the >>>>>>>>>> network. >>>>>>>>>> Suppose that after bootstrapping all the elements are working >>>>>>>>>> properly and the spanning tree is rooted in the router and it >>>>>>>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II >>>>>>>>>> and another >>>>>>>>>> branch that goes SWITCH I-SAVI II. >>>>>>>>>> >>>>>>>>>> Suppose that the Host boots at this moment and perfomrs >>>>>>>>>> the DHCP sxchange. >>>>>>>>>> The message is propagated through the spanning tree and it >>>>>>>>>> received >>>>>>>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>>>>>>> SAVI I creates the binding. >>>>>>>>>> >>>>>>>>>> Suppose that SAVI I fails and the spanning tree >>>>>>>>>> reconverges to SWITCH >>>>>>>>>> I- SAVI II- SWITCH II. Now data packets coming from the >>>>>>>>>> Host will be >>>>>>>>>> coursed through SAVI II which does not have binding state >>>>>>>>>> and will >>>>>>>>>> drop the packets. >>>>>>>>>> >>>>>>>>>> Regards, marcelo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> savi mailing list >>>>>>>>>> savi@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > From yaoa02@mails.tsinghua.edu.cn Mon Mar 15 08:53:46 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3DC83A6888 for ; Mon, 15 Mar 2010 08:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsRFsX1AfwwY for ; Mon, 15 Mar 2010 08:53:45 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 8AC7E3A6869 for ; Mon, 15 Mar 2010 08:53:44 -0700 (PDT) Received: from th211043.ip.tsinghua.edu.cn ([59.66.211.43] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NrCbz-00078C-8P for savi@ietf.org; Mon, 15 Mar 2010 23:53:47 +0800 From: "Guang Yao" To: References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es> <4B9E1BF3.9080709@it.uc3m.es> <000901cac442$d7967d50$86c377f0$@tsinghua.edu.cn> <4B9E3E11.8080403@it.uc3m.es> <001601cac44c$a64f64a0$f2ee2de0$@tsinghua.edu.cn> <4B9E4AE2.2090407@it.uc3m.es> In-Reply-To: <4B9E4AE2.2090407@it.uc3m.es> Date: Mon, 15 Mar 2010 23:53:39 +0800 Message-ID: <002301cac457$adfabcd0$09f03670$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrET50P/AAEKKyzQDy+XNg8Q2wjagAB9fcQ Content-Language: zh-cn Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 15:53:46 -0000 I'm happy that we can agree with this proposal. It's a good step, = anyway. BR, Guang > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf = Of > marcelo bagnulo braun > Sent: Monday, March 15, 2010 10:58 PM > To: savi@ietf.org > Subject: Re: [savi] call for comments: savi-dhcp-01 >=20 > El 15/03/10 15:34, Guang Yao escribi=F3: > > OK, I make a step backwards. What if requiring vendors to implement both, > > but at least giving the right of choosing to network administrators? > > > mmm, that is an interesting proposal > MUST implement this but MUST be configurable to turn it on/off... > I think i can also live with that for the dhcp case >=20 > Regards, marcelo >=20 > > And I want to mention that, ingress filtering(RFC2827, RFC3704, = BCP38, > > BCP84) is not a mechanism that wouldn't discard any " legitimate" packet. It > > may also "break the internet". Why it has RFC numbers? > > > > BR, > > Guang > > > > > >> -----Original Message----- > >> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On = Behalf Of > >> marcelo bagnulo braun > >> Sent: Monday, March 15, 2010 10:03 PM > >> To: savi@ietf.org > >> Subject: Re: [savi] call for comments: savi-dhcp-01 > >> > >> I beg to differ. My concern is that if we simply drop the packets = for > >> which there is no binding, the overall network robustness will be > >> affected. And our duty as IETF is to properly design protocols to = make > >> the Internet work in a reliable manner. If vendors want to = implement > >> solutions that break the internet they can do it, but they don't = get to > >> do that using an IETF RFC number (or at least they shouldn't) > >> > >> Regards, marcelo > >> > >> El 15/03/10 14:24, Guang Yao escribi=F3: > >> > >>> Hi Marcelo, > >>> > >>> Venture to say, it is impossible to persuade everyone, because = neither > >>> choices take absolute advantage. This problem is obviously just a > >>> > > tradeoff. > > > >>> Someone value robustness and some others values performance. > >>> > >>> I sincerely suggest, leave the choice to be made by the vendors = and > >>> > > network > > > >>> administrators. The solution doesn't have to restrict every > >>> > > implementation > > > >>> and deployment to be exactly the same. "One man's meat is another man's > >>> poison". Please just make out the outcome of what if it is done, = and the > >>> outcome of what if it is not done. > >>> > >>> Please just end this endless debate and move forward in the savi-slaac. > >>> > > 2012 > > > >>> is near :). > >>> > >>> BR, > >>> Guang > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On = Behalf Of > >>>> marcelo bagnulo braun > >>>> Sent: Monday, March 15, 2010 7:37 PM > >>>> To: savi@ietf.org > >>>> Subject: Re: [savi] call for comments: savi-dhcp-01 > >>>> > >>>> Hi Mikael, > >>>> > >>>> sorry for the delay, been away for a few days > >>>> > >>>> below... > >>>> > >>>> El 09/03/10 10:46, Mikael Abrahamsson escribi=F3: > >>>> > >>>> > >>>>> On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: > >>>>> > >>>>> > >>>>> > >>>>>> but this is what we qualify as a must in the ietf terminology. = If you > >>>>>> don't do this, the network breaks in different ways, right? > >>>>>> > >>>>>> > >>>>> I don't agree that this is a must. This breakage is limited to certain > >>>>> operational concerns, it's not a fundamental problem that makes = it not > >>>>> work at all. > >>>>> > >>>>> > >>>>> > >>>> Let's go back to RFC 2119 where the usage of these terms is = defines: > >>>> RFC2119 reads: > >>>> > >>>> * * > >>>> > >>>> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean = that > the > >>>> definition is an absolute requirement of the specification. > >>>> > >>>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that > >>>> > >> there > >> > >>>> may exist valid reasons in particular circumstances to = ignore a > >>>> particular item, but the full implications must be = understood and > >>>> carefully weighed before choosing a different course. > >>>> > >>>> > >>>> So, the situation is that if the triggering of the binding = creation by > >>>> data packet si not implemented, a legitimate user will be disconnected > >>>> from the network in case the state is loss or in case a failure results > >>>> in a change in the topology. So this actually affects interoperability. > >>>> > >>>> The alternative would be a SHOULD properly qualified. > >>>> > >>>> I think that for the SLAAC/ND case, it is much more likely that = the > >>>> situation occurs (due to packet loss and the non reliable nature = of the > >>>> DAD procedure), so i really think that the triggering of the SAVI > >>>> binding creation process upon the recpetion of data packets = should be a > >>>> MUST. > >>>> > >>>> For the dhcp case, the cases in whcih this fails are reduced = because of > >>>> the reliable nature of the dhcp exchange, so while i would rather = go > >>>> > > for > > > >>>> a MUST, i think i can live with a SHOULD. > >>>> > >>>> > >>>>> One can make the argument that this is a risk taken by the = entity that > >>>>> chooses to deploy SAVI partially and that SAVI mandates things = that > >>>>> are needed for a totally SAVI enabled network where all devices = have > >>>>> this, and in the case not all of them have SAVI functionality, = then > >>>>> things will break unless a MAY or SHOULD clause is implemented? > >>>>> > >>>>> > >>>>> > >>>> No, a MAY is something that is completelly optional and would not > >>>> > > affect > > > >>>> interop in any way. > >>>> > >>>> As i said above, in the case of dhcp, if the SHOULD is properly > >>>> qualified, i could live with that. > >>>> > >>>> > >>>> > >>>> > >>>>> I don't like the situation where some vendors might not offer = SAVI at > >>>>> all, to handle the problem you're describing. > >>>>> > >>>>> > >>>>> > >>>> Right, i do have this concern as well, but i am very worried = about the > >>>> impact to the overall robustness fo the network. > >>>> > >>>> Regards, marcelo > >>>> > >>>> _______________________________________________ > >>>> savi mailing list > >>>> savi@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/savi > >>>> > >>>> > >>> _______________________________________________ > >>> savi mailing list > >>> savi@ietf.org > >>> https://www.ietf.org/mailman/listinfo/savi > >>> > >>> > >>> > >> _______________________________________________ > >> savi mailing list > >> savi@ietf.org > >> https://www.ietf.org/mailman/listinfo/savi > >> > > _______________________________________________ > > savi mailing list > > savi@ietf.org > > https://www.ietf.org/mailman/listinfo/savi > > > > >=20 > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From marcelo@it.uc3m.es Mon Mar 15 08:55:21 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E25DA3A6888 for ; Mon, 15 Mar 2010 08:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.509 X-Spam-Level: X-Spam-Status: No, score=-106.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhefqUuGl4B1 for ; Mon, 15 Mar 2010 08:55:20 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 4B5553A6869 for ; Mon, 15 Mar 2010 08:55:19 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id BB86C655E35; Mon, 15 Mar 2010 16:55:25 +0100 (CET) Message-ID: <4B9E586D.9070800@it.uc3m.es> Date: Mon, 15 Mar 2010 16:55:25 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Jun Bi References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es><4B9E1BF3.9080709@it.uc3m.es><231D9821F3704A09BCB0B166137AA034@junbiVAIO><4B9E3D5C.6040600@it.uc3m.es><876F7DBECC2348C695021E77315654F0@junbiVAIO> <4B9E4E84.1090003@it.uc3m.es> <0F84A919BFA04A5CB05C6010251A11B3@junbiVAIO> In-Reply-To: <0F84A919BFA04A5CB05C6010251A11B3@junbiVAIO> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 15:55:22 -0000 El 15/03/10 16:27, Jun Bi escribió: > > > -------------------------------------------------- > From: "marcelo bagnulo braun" > Sent: Monday, March 15, 2010 11:13 PM > To: "Bi Jun" > Cc: > Subject: Re: [savi] savi-dhcp-02 > >> Hi Jun, >> >> What i am talking about is how the deployment of the different SAVI >> solution will affect the overall robustness and performance of the >> Internet architecture. One of the tasks of the IETF and of the IAB is >> to preserve the overall Internet architecture and to keep its >> fundamental design principles that have granted a robust Internet. >> >> My concern is that a SAVI solution that blindly drops data packets >> for which it has no binding for woudl deter the reliability of the >> network as a whole and we shouldn't allow that. >> >> So, that being said, let me comment on som particular comments you make. >> >> Below... >> >> El 15/03/10 15:48, Bi Jun escribió: >>> Hi Marcelo, >>> >>> Hi, Marcelo, >>> >>> Here we are actually talking about the trade-off between cost and >>> the benefits (forgive me that I explained this option many times). >>> If the solution is just a couple of lines of code, whey not we make >>> it MUST? But the truth is that the data-triggered actions are heavy >>> burden to device especially low end access switch. If you make them >>> MUST, then you forbid those access switches implementing SAVI (those >>> access switch could be more than 90% of potential savi-switches). >>> >> Where did you get this figure from? >> The feedback that i have got form vendors is that they would be able >> to implement it as long as it is rate limited. > > > > Oh really? Please provide me who said that. could you please tell the vendors who are not able to implement the triggering of the binding creation upon the reception of data packets to tell so in the ml, as you stated earlier? once that happens, i will talk to the vendors who did told me that to speak up in the ml as well. Regards, marcelo > You know CNGI-CERNET2 is deploying savi > in large scale in 100 universities. If any vendor implements > data-triggered > functions in low-end access switch (we use those switch to directly > connect hosts) > with the same price as the savi access switch that implemented > control-packet triggered functions (we purchased about 50000 > savi-switches), we'd like to buy more from this new vendor. > > thanks! > Jun > > > > >>> So my idea is: >>> 1 make two RFCs, one for each catalog of functions used for >>> different scenarios. >>> 2 make one RFC, but make MUST for basic functions, make other >>> functions as options. And provide a guideline to users: >>> (1) If the users want to plus a host directly a savi-device, deploy >>> cheap switch only implement MUST >>> (2) If users want to connect host to a old hub, then connect the hub >>> savi-device (like the pictures you drown), then if you think >>> best-effort is OK for you (if you have problem, reboot your hub or >>> repaired the host-connection, deploy the cheap switch only implement >>> MUST >>> (3) in the above case, if you want 100% service quality, then buy a >>> higher-end savi-device that implement options in this RFC. >>> >> Actually, i don't agree with this approach. I think we have the >> normative language as specified in RFC 2116 exactly to deal with this >> type of situations. >> I don't want to have all the SAVI funcionality spread over more RFCs, >> we already have split the SAVI spec in more than we should and i >> don't think it would make sense to divide it even more. >> >> I think we need to have one RFC for dhcp savi and one for SLAAC savi >> >> We need to agree on what features are MUST and which ones are SHOULD. >> >> As i suggested already,. imho the triggering of the binding creation >> mechanisms upon the reception of a data packet for whcih there is no >> binding should be a MUST for both cases. >> >> I could live with a qualified SHOULD for the DHCP case and a MUST for >> the SLAAC case, based on the faact that the DHCP exchange is reliable >> and hence the problem of packet loss is not an issue for the DHCP >> case while it is so for the SLAAC case >> >> I think i could also live with Guang's suggestion of having A MUST >> for both cases and also require as a MUST that the feature MUST be >> configurable on/off >> >> Regards, marcelo >> >>> thanks, >>> Jun >>> -------------------------------------------------- >>> From: "marcelo bagnulo braun" >>> Sent: Monday, March 15, 2010 9:59 PM >>> To: "Bi Jun" >>> Cc: >>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>> >>>> El 15/03/10 13:19, Bi Jun escribió: >>>>> Hi Marcelo, >>>>> >>>>> The sentence is misleading. >>>>> "So, the situation is that if the triggering of the binding >>>>> creation by >>>>> data packet si not implemented, a legitimate user will be >>>>> disconnected " >>>>> >>>>> It only happens for some situations. >>>> >>>> Right, it only happen in some situation, but that is what >>>> robustness is about, right? >>>> I mean, this affects interoperability, becuase it may happen that >>>> the communication of a legitimate host is interrupted due to this. >>>>> If the "MUST" only handles some situation but bring *much more* >>>>> cost to the device (it's really because the data-triggered >>>>> solution is not a low cost action), >>>>> then I think the right ways: >>>>> >>>>> 1 "MUST" for all cases, and list some limitation and guide the users. >>>>> 2 "Options" for some special cases, users has the guide to buy the >>>>> higher-end device >>>>> if they want more flexible use of savi device, (certainly, by >>>>> paying higher price for the device.). >>>>> >>>> As i said, i don't think in any case this is optional. >>>> >>>> IMHO, this is a MUST becuase it affect interoperability. >>>> If there is no consensus to go for a MUST, i can live with, for the >>>> dhcp case and only for the dhcp case, since the subset of >>>> problematic cases is more limited than the ND case, we could use a >>>> qualified SHOULD, which means that the implementation SHOULD do >>>> that and we explian what happens if they don't. How about that? >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>>> That's my answer to all your similar questions. >>>>> >>>>> thanks, >>>>> Jun Bi >>>>> >>>>> -------------------------------------------------- >>>>> From: "marcelo bagnulo braun" >>>>> Sent: Monday, March 15, 2010 7:37 PM >>>>> To: >>>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>>> >>>>>> Hi Mikael, >>>>>> >>>>>> sorry for the delay, been away for a few days >>>>>> >>>>>> below... >>>>>> >>>>>> El 09/03/10 10:46, Mikael Abrahamsson escribió: >>>>>>> On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: >>>>>>> >>>>>>>> but this is what we qualify as a must in the ietf terminology. >>>>>>>> If you don't do this, the network breaks in different ways, right? >>>>>>> >>>>>>> I don't agree that this is a must. This breakage is limited to >>>>>>> certain operational concerns, it's not a fundamental problem >>>>>>> that makes it not work at all. >>>>>>> >>>>>> Let's go back to RFC 2119 where the usage of these terms is defines: >>>>>> RFC2119 reads: >>>>>> >>>>>> * * >>>>>> >>>>>> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean >>>>>> that the >>>>>> definition is an absolute requirement of the specification. >>>>>> >>>>>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that >>>>>> there >>>>>> may exist valid reasons in particular circumstances to ignore a >>>>>> particular item, but the full implications must be understood and >>>>>> carefully weighed before choosing a different course. >>>>>> >>>>>> >>>>>> So, the situation is that if the triggering of the binding >>>>>> creation by data packet si not implemented, a legitimate user >>>>>> will be disconnected from the network in case the state is loss >>>>>> or in case a failure results in a change in the topology. So this >>>>>> actually affects interoperability. >>>>>> >>>>>> The alternative would be a SHOULD properly qualified. >>>>>> >>>>>> I think that for the SLAAC/ND case, it is much more likely that >>>>>> the situation occurs (due to packet loss and the non reliable >>>>>> nature of the DAD procedure), so i really think that the >>>>>> triggering of the SAVI binding creation process upon the >>>>>> recpetion of data packets should be a MUST. >>>>>> >>>>>> For the dhcp case, the cases in whcih this fails are reduced >>>>>> because of the reliable nature of the dhcp exchange, so while i >>>>>> would rather go for a MUST, i think i can live with a SHOULD. >>>>>>> One can make the argument that this is a risk taken by the >>>>>>> entity that chooses to deploy SAVI partially and that SAVI >>>>>>> mandates things that are needed for a totally SAVI enabled >>>>>>> network where all devices have this, and in the case not all of >>>>>>> them have SAVI functionality, then things will break unless a >>>>>>> MAY or SHOULD clause is implemented? >>>>>>> >>>>>> No, a MAY is something that is completelly optional and would not >>>>>> affect interop in any way. >>>>>> >>>>>> As i said above, in the case of dhcp, if the SHOULD is properly >>>>>> qualified, i could live with that. >>>>>> >>>>>> >>>>>>> I don't like the situation where some vendors might not offer >>>>>>> SAVI at all, to handle the problem you're describing. >>>>>>> >>>>>> Right, i do have this concern as well, but i am very worried >>>>>> about the impact to the overall robustness fo the network. >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > From elevyabe@cisco.com Mon Mar 15 09:08:39 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A27473A697E for ; Mon, 15 Mar 2010 09:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.956 X-Spam-Level: X-Spam-Status: No, score=-4.956 tagged_above=-999 required=5 tests=[AWL=-2.357, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYPe-VSZ2D5K for ; Mon, 15 Mar 2010 09:08:36 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3BAD23A685F for ; Mon, 15 Mar 2010 09:08:32 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsBALf4nUuQ/uCWe2dsb2JhbACacRUBAQsLJAYcoWGXbIR7BA X-IronPort-AV: E=Sophos;i="4.49,644,1262563200"; d="scan'208";a="4357274" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 15 Mar 2010 15:34:51 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2FG8QrO013249; Mon, 15 Mar 2010 16:08:26 GMT Received: from xmb-ams-105.cisco.com ([144.254.74.80]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 17:08:26 +0100 Received: from [144.254.53.100] ([144.254.53.100]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 17:08:25 +0100 Message-ID: <4B9E5B78.6080306@cisco.com> Date: Mon, 15 Mar 2010 17:08:24 +0100 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4B95FDE7.8070100@it.uc3m.es><4B9E2382.8000304@it.uc3m.es><019C6F3B5F9C4B9F816588E35A440555@junbiVAIO><4B9E3C24.5060504@it.uc3m.es><4B9E4A72.2040808@it.uc3m.es><63495C88CB4141118DCF796A35192F22@junbiVAIO> <4B9E4ED0.7090508@it.uc3m.es> <4B9E57CE.5010901@it.uc3m.es> In-Reply-To: <4B9E57CE.5010901@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Mar 2010 16:08:25.0840 (UTC) FILETIME=[BE5D4F00:01CAC459] Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 16:08:39 -0000 marcelo bagnulo braun a écrit : > mmm, not sure if i understand exactly what you mean, but i think yes > > We need to decide which features are MUST and which ones are should. > then we need to qualify the SHOULDs, which can be complemented by an > applicability statement. > > So, for the dhcp savi case, i can live with including the feature of > triggering the binding creation process upon the reception of data > packets as a should and then qualify it by describing what it would > break if this is not implemented and what configurations would have > suffer less problems I would strongly oppose to a SHOULD if the technique implies the switch to be a L3 device (see my point on sourcing DHCP messages). That would not be constraining the device capabilities (which to me would be more acceptable) but rather the deployment model. And that is bogus. Eric > > regards, marcelo > > > El 15/03/10 16:19, Jun Bi escribió: >> then you meant all of those functions will be "SHOULD", then state in >> the applicability section in this rfc? >> >> thanks, >> Jun Bi >> >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Monday, March 15, 2010 11:14 PM >> To: "Bi Jun" >> Cc: "SAVI Mailing List" >> Subject: Re: [savi] the impact of SAVI in the overall network >> robustness (was Re: dealing with topology changes in dhcp savi >> >>> Right, this is the applicability of the protocol and does not affect >>> the normative language of the spec. >>> >>> >>> >>> El 15/03/10 15:59, Bi Jun escribió: >>>> >>>> I think everything has it's working condition. >>>> The guideline is part of the RFC to discuss the condition. >>>> For more discussion, please see my another replied email. >>>> >>>> thanks, >>>> Jun >>>> >>>> >>>> >>>> -------------------------------------------------- >>>> From: "marcelo bagnulo braun" >>>> Sent: Monday, March 15, 2010 10:55 PM >>>> To: "Bi Jun" >>>> Cc: "SAVI Mailing List" >>>> Subject: Re: the impact of SAVI in the overall network robustness >>>> (was Re: [savi] dealing with topology changes in dhcp savi >>>> >>>>> El 15/03/10 15:28, Bi Jun escribió: >>>>>> I meant please in the guideline, says that your host SHOULD be >>>>>> directly plug to the savi-device. >>>>> >>>>> this is not how the SHOULD work for the specification since this >>>>> is not somehting the protocol MUST/SHOULD implement. >>>>> >>>>> The MUST/SHOULD affects the protocol extensions and not the >>>>> configurations where you use it >>>>> The configurations where you use safely or not are the >>>>> qualification of the SHOULD >>>>> >>>>> Regards, marcelo >>>>> >>>>>> If not, please purchase an higher-end savi-device that >>>>>> implemented the options. >>>>>> >>>>>> thanks, >>>>>> Jun >>>>>> >>>>>> -------------------------------------------------- >>>>>> From: "marcelo bagnulo braun" >>>>>> Sent: Monday, March 15, 2010 9:54 PM >>>>>> To: "Bi Jun" >>>>>> Cc: "SAVI Mailing List" >>>>>> Subject: Re: the impact of SAVI in the overall network robustness >>>>>> (was Re: [savi] dealing with topology changes in dhcp savi >>>>>> >>>>>>> So, if you do discard the packets for which there is no binding, >>>>>>> the overall network robustness is worse, in particular settings >>>>>>> where a redundant topology has been set. >>>>>>> >>>>>>> This seems quite severe to me. >>>>>>> >>>>>>> Regards, marcelo >>>>>>> >>>>>>> >>>>>>> El 15/03/10 13:26, Bi Jun escribió: >>>>>>>> Hi Marcelo, >>>>>>>> >>>>>>>> We can guide the users in this document or in framework, >>>>>>>> if you want to put a hub between savi-device or your host, >>>>>>>> please buy an more expensive savi-device that implemented the >>>>>>>> xxx options functions (e.g the data triggered functions listed >>>>>>>> in savi-dhcp-02, or another solution document). >>>>>>>> >>>>>>>> thanks, >>>>>>>> Jun >>>>>>>> >>>>>>>> -------------------------------------------------- >>>>>>>> From: "marcelo bagnulo braun" >>>>>>>> Sent: Monday, March 15, 2010 8:09 PM >>>>>>>> To: "Bi Jun" >>>>>>>> Cc: "SAVI Mailing List" >>>>>>>> Subject: the impact of SAVI in the overall network robustness >>>>>>>> (was Re: [savi] dealing with topology changes in dhcp savi >>>>>>>> >>>>>>>>> Hi Jun, >>>>>>>>> >>>>>>>>> sorry for the delay, i was away for a few days. >>>>>>>>> >>>>>>>>> Ok, let me rephrase my question then. >>>>>>>>> >>>>>>>>> Suppose that you have the topology that is depicted below, >>>>>>>>> with multiple redundant switches to benefit from robustness. >>>>>>>>> My point is that the introduction of SAVI that is unable to >>>>>>>>> cope with data packets for which there is no binding will >>>>>>>>> reduce the robustness of the network, even if network >>>>>>>>> has been designed to be redundant. >>>>>>>>> >>>>>>>>> In the case SAVI is being deployed in a switched Ethernet >>>>>>>>> network, >>>>>>>>> failures in a single device changes may result in a SAVI >>>>>>>>> device >>>>>>>>> receiving packets from a >>>>>>>>> legitimate user for which the SAVI device does not have a >>>>>>>>> binding >>>>>>>>> for. Consider the following example: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> +------+ +--------+ +---------------+ >>>>>>>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>>>>>>> +------+ +--------+ +---------------+ >>>>>>>>> | | >>>>>>>>> | +--------+ >>>>>>>>> | | SAVI II| >>>>>>>>> | +--------+ >>>>>>>>> | +----------+ | >>>>>>>>> +---|SWITCH II |-----+ >>>>>>>>> +----------+ >>>>>>>>> | >>>>>>>>> +-----+ >>>>>>>>> | Host| >>>>>>>>> +-----+ >>>>>>>>> >>>>>>>>> >>>>>>>>> The DHCP server is located in the part called rest of the >>>>>>>>> network. >>>>>>>>> Suppose that after bootstrapping all the elements are working >>>>>>>>> properly and the spanning tree is rooted in the router and it >>>>>>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II >>>>>>>>> and another >>>>>>>>> branch that goes SWITCH I-SAVI II. >>>>>>>>> >>>>>>>>> Suppose that the Host boots at this moment and perfomrs the >>>>>>>>> DHCP sxchange. >>>>>>>>> The message is propagated through the spanning tree and it >>>>>>>>> received >>>>>>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>>>>>> SAVI I creates the binding. >>>>>>>>> >>>>>>>>> Suppose that SAVI I fails and the spanning tree reconverges >>>>>>>>> to SWITCH >>>>>>>>> I- SAVI II- SWITCH II. Now data packets coming from the >>>>>>>>> Host will be >>>>>>>>> coursed through SAVI II which does not have binding state >>>>>>>>> and will >>>>>>>>> drop the packets. >>>>>>>>> >>>>>>>>> Comments? >>>>>>>>> >>>>>>>>> Regards, marcelo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> El 09/03/10 11:47, Bi Jun escribió: >>>>>>>>>> Hi Marcelo, >>>>>>>>>> >>>>>>>>>> Since you are entitled "topology change", I want to say sth. >>>>>>>>>> Based on our operational experience, if we do a planed >>>>>>>>>> topology change, >>>>>>>>>> then we have to plan we will have more serious problem than >>>>>>>>>> this. >>>>>>>>>> So topology change in an operational network is usually >>>>>>>>>> carefully planed. >>>>>>>>>> We don't do it very often, and once we do it, we will let >>>>>>>>>> users understand us. >>>>>>>>>> >>>>>>>>>> So I don't see a problem of planed topology change. The only >>>>>>>>>> thing is the power-down >>>>>>>>>> of a switch, which is really a low frequency event in an >>>>>>>>>> operational network. If we found the power down, we will also >>>>>>>>>> inform users (only users under that switch will be affected, >>>>>>>>>> not all users will be affect) that if you had any problem >>>>>>>>>> thank you please renew your connection. >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> Jun Bi >>>>>>>>>> >>>>>>>>>> -------------------------------------------------- >>>>>>>>>> From: "marcelo bagnulo braun" >>>>>>>>>> Sent: Tuesday, March 09, 2010 3:51 PM >>>>>>>>>> To: "SAVI Mailing List" >>>>>>>>>> Subject: [savi] dealing with topology changes in dhcp savi >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I have another question about dhcp save >>>>>>>>>>> >>>>>>>>>>> How do you handle the following situation? >>>>>>>>>>> >>>>>>>>>>> In the case SAVI is being deployed in a switched Ethernet >>>>>>>>>>> network, >>>>>>>>>>> topology changes may result in a SAVI device receiving >>>>>>>>>>> packets from a >>>>>>>>>>> legitimate user for which the SAVI device does not have a >>>>>>>>>>> binding >>>>>>>>>>> for. Consider the following example: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> +------+ +--------+ >>>>>>>>>>> +---------------+ >>>>>>>>>>> |SAVI I|-------------|SWITCH I|-------|rest of the >>>>>>>>>>> net| >>>>>>>>>>> +------+ +--------+ >>>>>>>>>>> +---------------+ >>>>>>>>>>> | | >>>>>>>>>>> | +--------+ >>>>>>>>>>> | | SAVI II| >>>>>>>>>>> | +--------+ >>>>>>>>>>> | +----------+ | >>>>>>>>>>> +---|SWITCH II |-----+ >>>>>>>>>>> +----------+ >>>>>>>>>>> | >>>>>>>>>>> +-----+ >>>>>>>>>>> | Host| >>>>>>>>>>> +-----+ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The DHCP server is located in the part called rest of the >>>>>>>>>>> network. >>>>>>>>>>> Suppose that after bootstrapping all the elements are >>>>>>>>>>> working >>>>>>>>>>> properly and the spanning tree is rooted in the router >>>>>>>>>>> and it >>>>>>>>>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II >>>>>>>>>>> and another >>>>>>>>>>> branch that goes SWITCH I-SAVI II. >>>>>>>>>>> >>>>>>>>>>> Suppose that the Host boots at this moment and perfomrs >>>>>>>>>>> the DHCP sxchange. >>>>>>>>>>> The message is propagated through the spanning tree and >>>>>>>>>>> it received >>>>>>>>>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>>>>>>>>> SAVI I creates the binding. >>>>>>>>>>> >>>>>>>>>>> Suppose that SAVI I fails and the spanning tree >>>>>>>>>>> reconverges to SWITCH >>>>>>>>>>> I- SAVI II- SWITCH II. Now data packets coming from the >>>>>>>>>>> Host will be >>>>>>>>>>> coursed through SAVI II which does not have binding state >>>>>>>>>>> and will >>>>>>>>>>> drop the packets. >>>>>>>>>>> >>>>>>>>>>> Regards, marcelo >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> savi mailing list >>>>>>>>>>> savi@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@tsinghua.edu.cn Mon Mar 15 09:12:03 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716C63A692C for ; Mon, 15 Mar 2010 09:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdfrVSmjDQ2l for ; Mon, 15 Mar 2010 09:12:01 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 0C3183A67E6 for ; Mon, 15 Mar 2010 09:12:01 -0700 (PDT) Received: from th053201.ip.tsinghua.edu.cn ([59.66.53.201] helo=junbiVAIO) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NrCtg-0007Mz-JQ; Tue, 16 Mar 2010 00:12:04 +0800 Message-ID: From: "Jun Bi" To: "marcelo bagnulo braun" References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es><4B9E1BF3.9080709@it.uc3m.es><231D9821F3704A09BCB0B166137AA034@junbiVAIO><4B9E3D5C.6040600@it.uc3m.es><876F7DBECC2348C695021E77315654F0@junbiVAIO> <4B9E4E84.1090003@it.uc3m.es> <0F84A919BFA04A5CB05C6010251A11B3@junbiVAIO> <4B9E586D.9070800@it.uc3m.es> In-Reply-To: <4B9E586D.9070800@it.uc3m.es> Date: Tue, 16 Mar 2010 00:12:07 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 16:12:03 -0000 -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Monday, March 15, 2010 11:55 PM To: "Jun Bi" Cc: "Bi Jun" ; Subject: Re: [savi] savi-dhcp-02 > El 15/03/10 16:27, Jun Bi escribió: >> >> >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Monday, March 15, 2010 11:13 PM >> To: "Bi Jun" >> Cc: >> Subject: Re: [savi] savi-dhcp-02 >> >>> Hi Jun, >>> >>> What i am talking about is how the deployment of the different SAVI >>> solution will affect the overall robustness and performance of the >>> Internet architecture. One of the tasks of the IETF and of the IAB is to >>> preserve the overall Internet architecture and to keep its fundamental >>> design principles that have granted a robust Internet. >>> >>> My concern is that a SAVI solution that blindly drops data packets for >>> which it has no binding for woudl deter the reliability of the network >>> as a whole and we shouldn't allow that. >>> >>> So, that being said, let me comment on som particular comments you make. >>> >>> Below... >>> >>> El 15/03/10 15:48, Bi Jun escribió: >>>> Hi Marcelo, >>>> >>>> Hi, Marcelo, >>>> >>>> Here we are actually talking about the trade-off between cost and the >>>> benefits (forgive me that I explained this option many times). If the >>>> solution is just a couple of lines of code, whey not we make it MUST? >>>> But the truth is that the data-triggered actions are heavy burden to >>>> device especially low end access switch. If you make them MUST, then >>>> you forbid those access switches implementing SAVI (those access switch >>>> could be more than 90% of potential savi-switches). >>>> >>> Where did you get this figure from? >>> The feedback that i have got form vendors is that they would be able to >>> implement it as long as it is rate limited. >> >> >> > > > >> Oh really? Please provide me who said that. > > could you please tell the vendors who are not able to implement the > triggering of the binding creation upon the reception of data packets to > tell so in the ml, as you stated earlier? > > once that happens, i will talk to the vendors who did told me that to > speak up in the ml as well. The access-level switch products of H3C(3Com), ZTE, Ruijie, Digital China(spinned from from Lenovo). Please pay attention to: access level switches, not higher-end switches. > > Regards, marcelo >> You know CNGI-CERNET2 is deploying savi >> in large scale in 100 universities. If any vendor implements >> data-triggered >> functions in low-end access switch (we use those switch to directly >> connect hosts) >> with the same price as the savi access switch that implemented >> control-packet triggered functions (we purchased about 50000 >> savi-switches), we'd like to buy more from this new vendor. >> >> thanks! >> Jun >> >> >> >> >>>> So my idea is: >>>> 1 make two RFCs, one for each catalog of functions used for different >>>> scenarios. >>>> 2 make one RFC, but make MUST for basic functions, make other functions >>>> as options. And provide a guideline to users: >>>> (1) If the users want to plus a host directly a savi-device, deploy >>>> cheap switch only implement MUST >>>> (2) If users want to connect host to a old hub, then connect the hub >>>> savi-device (like the pictures you drown), then if you think >>>> best-effort is OK for you (if you have problem, reboot your hub or >>>> repaired the host-connection, deploy the cheap switch only implement >>>> MUST >>>> (3) in the above case, if you want 100% service quality, then buy a >>>> higher-end savi-device that implement options in this RFC. >>>> >>> Actually, i don't agree with this approach. I think we have the >>> normative language as specified in RFC 2116 exactly to deal with this >>> type of situations. >>> I don't want to have all the SAVI funcionality spread over more RFCs, we >>> already have split the SAVI spec in more than we should and i don't >>> think it would make sense to divide it even more. >>> >>> I think we need to have one RFC for dhcp savi and one for SLAAC savi >>> >>> We need to agree on what features are MUST and which ones are SHOULD. >>> >>> As i suggested already,. imho the triggering of the binding creation >>> mechanisms upon the reception of a data packet for whcih there is no >>> binding should be a MUST for both cases. >>> >>> I could live with a qualified SHOULD for the DHCP case and a MUST for >>> the SLAAC case, based on the faact that the DHCP exchange is reliable >>> and hence the problem of packet loss is not an issue for the DHCP case >>> while it is so for the SLAAC case >>> >>> I think i could also live with Guang's suggestion of having A MUST for >>> both cases and also require as a MUST that the feature MUST be >>> configurable on/off >>> >>> Regards, marcelo >>> >>>> thanks, >>>> Jun >>>> -------------------------------------------------- >>>> From: "marcelo bagnulo braun" >>>> Sent: Monday, March 15, 2010 9:59 PM >>>> To: "Bi Jun" >>>> Cc: >>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>> >>>>> El 15/03/10 13:19, Bi Jun escribió: >>>>>> Hi Marcelo, >>>>>> >>>>>> The sentence is misleading. >>>>>> "So, the situation is that if the triggering of the binding creation >>>>>> by >>>>>> data packet si not implemented, a legitimate user will be >>>>>> disconnected " >>>>>> >>>>>> It only happens for some situations. >>>>> >>>>> Right, it only happen in some situation, but that is what robustness >>>>> is about, right? >>>>> I mean, this affects interoperability, becuase it may happen that the >>>>> communication of a legitimate host is interrupted due to this. >>>>>> If the "MUST" only handles some situation but bring *much more* cost >>>>>> to the device (it's really because the data-triggered solution is not >>>>>> a low cost action), >>>>>> then I think the right ways: >>>>>> >>>>>> 1 "MUST" for all cases, and list some limitation and guide the users. >>>>>> 2 "Options" for some special cases, users has the guide to buy the >>>>>> higher-end device >>>>>> if they want more flexible use of savi device, (certainly, by paying >>>>>> higher price for the device.). >>>>>> >>>>> As i said, i don't think in any case this is optional. >>>>> >>>>> IMHO, this is a MUST becuase it affect interoperability. >>>>> If there is no consensus to go for a MUST, i can live with, for the >>>>> dhcp case and only for the dhcp case, since the subset of problematic >>>>> cases is more limited than the ND case, we could use a qualified >>>>> SHOULD, which means that the implementation SHOULD do that and we >>>>> explian what happens if they don't. How about that? >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>> >>>>>> That's my answer to all your similar questions. >>>>>> >>>>>> thanks, >>>>>> Jun Bi >>>>>> >>>>>> -------------------------------------------------- >>>>>> From: "marcelo bagnulo braun" >>>>>> Sent: Monday, March 15, 2010 7:37 PM >>>>>> To: >>>>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>>>> >>>>>>> Hi Mikael, >>>>>>> >>>>>>> sorry for the delay, been away for a few days >>>>>>> >>>>>>> below... >>>>>>> >>>>>>> El 09/03/10 10:46, Mikael Abrahamsson escribió: >>>>>>>> On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: >>>>>>>> >>>>>>>>> but this is what we qualify as a must in the ietf terminology. If >>>>>>>>> you don't do this, the network breaks in different ways, right? >>>>>>>> >>>>>>>> I don't agree that this is a must. This breakage is limited to >>>>>>>> certain operational concerns, it's not a fundamental problem that >>>>>>>> makes it not work at all. >>>>>>>> >>>>>>> Let's go back to RFC 2119 where the usage of these terms is defines: >>>>>>> RFC2119 reads: >>>>>>> >>>>>>> * * >>>>>>> >>>>>>> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that >>>>>>> the >>>>>>> definition is an absolute requirement of the specification. >>>>>>> >>>>>>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that >>>>>>> there >>>>>>> may exist valid reasons in particular circumstances to ignore a >>>>>>> particular item, but the full implications must be understood and >>>>>>> carefully weighed before choosing a different course. >>>>>>> >>>>>>> >>>>>>> So, the situation is that if the triggering of the binding creation >>>>>>> by data packet si not implemented, a legitimate user will be >>>>>>> disconnected from the network in case the state is loss or in case a >>>>>>> failure results in a change in the topology. So this actually >>>>>>> affects interoperability. >>>>>>> >>>>>>> The alternative would be a SHOULD properly qualified. >>>>>>> >>>>>>> I think that for the SLAAC/ND case, it is much more likely that the >>>>>>> situation occurs (due to packet loss and the non reliable nature of >>>>>>> the DAD procedure), so i really think that the triggering of the >>>>>>> SAVI binding creation process upon the recpetion of data packets >>>>>>> should be a MUST. >>>>>>> >>>>>>> For the dhcp case, the cases in whcih this fails are reduced because >>>>>>> of the reliable nature of the dhcp exchange, so while i would rather >>>>>>> go for a MUST, i think i can live with a SHOULD. >>>>>>>> One can make the argument that this is a risk taken by the entity >>>>>>>> that chooses to deploy SAVI partially and that SAVI mandates things >>>>>>>> that are needed for a totally SAVI enabled network where all >>>>>>>> devices have this, and in the case not all of them have SAVI >>>>>>>> functionality, then things will break unless a MAY or SHOULD clause >>>>>>>> is implemented? >>>>>>>> >>>>>>> No, a MAY is something that is completelly optional and would not >>>>>>> affect interop in any way. >>>>>>> >>>>>>> As i said above, in the case of dhcp, if the SHOULD is properly >>>>>>> qualified, i could live with that. >>>>>>> >>>>>>> >>>>>>>> I don't like the situation where some vendors might not offer SAVI >>>>>>>> at all, to handle the problem you're describing. >>>>>>>> >>>>>>> Right, i do have this concern as well, but i am very worried about >>>>>>> the impact to the overall robustness fo the network. >>>>>>> >>>>>>> Regards, marcelo >>>>>>> >>>>>>> _______________________________________________ >>>>>>> savi mailing list >>>>>>> savi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> > > From marcelo@it.uc3m.es Mon Mar 15 09:41:50 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D40273A6A10 for ; Mon, 15 Mar 2010 09:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.214 X-Spam-Level: X-Spam-Status: No, score=-106.214 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7-LkzwSlbsN for ; Mon, 15 Mar 2010 09:41:46 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 0FDD53A6AA9 for ; Mon, 15 Mar 2010 09:41:41 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 647767F74FF; Mon, 15 Mar 2010 17:41:47 +0100 (CET) Message-ID: <4B9E634B.80606@it.uc3m.es> Date: Mon, 15 Mar 2010 17:41:47 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Jun Bi References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es><4B9E1BF3.9080709@it.uc3m.es><231D9821F3704A09BCB0B166137AA034@junbiVAIO><4B9E3D5C.6040600@it.uc3m.es><876F7DBECC2348C695021E77315654F0@junbiVAIO> <4B9E4E84.1090003@it.uc3m.es> <0F84A919BFA04A5CB05C6010251A11B3@junbiVAIO> <4B9E586D.9070800@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 16:41:50 -0000 El 15/03/10 17:12, Jun Bi escribió: > The access-level switch products of H3C(3Com), ZTE, Ruijie, Digital > China(spinned from from Lenovo). Please pay attention to: access level > switches, not higher-end switches. > So, basically you are saying that all these vendors are able to trigger the binding creation process upon the reception of a data packet, but only in their high end devices, is that correct? But that they cannot provide it in the access level, correct? Please note that is fully compatible with the deployment model of SAVI with legacy devices, where you can deploy a core of SAVI devices and then connect a bunch of access devices that don't implement SAVI. Another question is would these vendors be able to store the SAVI binding information in non volatile memory for the access devices or only for the high end devices? Regards, marcelo PS: I will ask the vendor that provided me the info to contact you either in the ml or privately. > > >> >> Regards, marcelo >>> You know CNGI-CERNET2 is deploying savi >>> in large scale in 100 universities. If any vendor implements >>> data-triggered >>> functions in low-end access switch (we use those switch to directly >>> connect hosts) >>> with the same price as the savi access switch that implemented >>> control-packet triggered functions (we purchased about 50000 >>> savi-switches), we'd like to buy more from this new vendor. >>> >>> thanks! >>> Jun >>> >>> >>> >>> >>>>> So my idea is: >>>>> 1 make two RFCs, one for each catalog of functions used for >>>>> different scenarios. >>>>> 2 make one RFC, but make MUST for basic functions, make other >>>>> functions as options. And provide a guideline to users: >>>>> (1) If the users want to plus a host directly a savi-device, >>>>> deploy cheap switch only implement MUST >>>>> (2) If users want to connect host to a old hub, then connect the >>>>> hub savi-device (like the pictures you drown), then if you think >>>>> best-effort is OK for you (if you have problem, reboot your hub or >>>>> repaired the host-connection, deploy the cheap switch only >>>>> implement MUST >>>>> (3) in the above case, if you want 100% service quality, then buy >>>>> a higher-end savi-device that implement options in this RFC. >>>>> >>>> Actually, i don't agree with this approach. I think we have the >>>> normative language as specified in RFC 2116 exactly to deal with >>>> this type of situations. >>>> I don't want to have all the SAVI funcionality spread over more >>>> RFCs, we already have split the SAVI spec in more than we should >>>> and i don't think it would make sense to divide it even more. >>>> >>>> I think we need to have one RFC for dhcp savi and one for SLAAC savi >>>> >>>> We need to agree on what features are MUST and which ones are SHOULD. >>>> >>>> As i suggested already,. imho the triggering of the binding >>>> creation mechanisms upon the reception of a data packet for whcih >>>> there is no binding should be a MUST for both cases. >>>> >>>> I could live with a qualified SHOULD for the DHCP case and a MUST >>>> for the SLAAC case, based on the faact that the DHCP exchange is >>>> reliable and hence the problem of packet loss is not an issue for >>>> the DHCP case while it is so for the SLAAC case >>>> >>>> I think i could also live with Guang's suggestion of having A MUST >>>> for both cases and also require as a MUST that the feature MUST be >>>> configurable on/off >>>> >>>> Regards, marcelo >>>> >>>>> thanks, >>>>> Jun >>>>> -------------------------------------------------- >>>>> From: "marcelo bagnulo braun" >>>>> Sent: Monday, March 15, 2010 9:59 PM >>>>> To: "Bi Jun" >>>>> Cc: >>>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>>> >>>>>> El 15/03/10 13:19, Bi Jun escribió: >>>>>>> Hi Marcelo, >>>>>>> >>>>>>> The sentence is misleading. >>>>>>> "So, the situation is that if the triggering of the binding >>>>>>> creation by >>>>>>> data packet si not implemented, a legitimate user will be >>>>>>> disconnected " >>>>>>> >>>>>>> It only happens for some situations. >>>>>> >>>>>> Right, it only happen in some situation, but that is what >>>>>> robustness is about, right? >>>>>> I mean, this affects interoperability, becuase it may happen that >>>>>> the communication of a legitimate host is interrupted due to this. >>>>>>> If the "MUST" only handles some situation but bring *much more* >>>>>>> cost to the device (it's really because the data-triggered >>>>>>> solution is not a low cost action), >>>>>>> then I think the right ways: >>>>>>> >>>>>>> 1 "MUST" for all cases, and list some limitation and guide the >>>>>>> users. >>>>>>> 2 "Options" for some special cases, users has the guide to buy >>>>>>> the higher-end device >>>>>>> if they want more flexible use of savi device, (certainly, by >>>>>>> paying higher price for the device.). >>>>>>> >>>>>> As i said, i don't think in any case this is optional. >>>>>> >>>>>> IMHO, this is a MUST becuase it affect interoperability. >>>>>> If there is no consensus to go for a MUST, i can live with, for >>>>>> the dhcp case and only for the dhcp case, since the subset of >>>>>> problematic cases is more limited than the ND case, we could use >>>>>> a qualified SHOULD, which means that the implementation SHOULD do >>>>>> that and we explian what happens if they don't. How about that? >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>> >>>>>>> That's my answer to all your similar questions. >>>>>>> >>>>>>> thanks, >>>>>>> Jun Bi >>>>>>> >>>>>>> -------------------------------------------------- >>>>>>> From: "marcelo bagnulo braun" >>>>>>> Sent: Monday, March 15, 2010 7:37 PM >>>>>>> To: >>>>>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>>>>> >>>>>>>> Hi Mikael, >>>>>>>> >>>>>>>> sorry for the delay, been away for a few days >>>>>>>> >>>>>>>> below... >>>>>>>> >>>>>>>> El 09/03/10 10:46, Mikael Abrahamsson escribió: >>>>>>>>> On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: >>>>>>>>> >>>>>>>>>> but this is what we qualify as a must in the ietf >>>>>>>>>> terminology. If you don't do this, the network breaks in >>>>>>>>>> different ways, right? >>>>>>>>> >>>>>>>>> I don't agree that this is a must. This breakage is limited to >>>>>>>>> certain operational concerns, it's not a fundamental problem >>>>>>>>> that makes it not work at all. >>>>>>>>> >>>>>>>> Let's go back to RFC 2119 where the usage of these terms is >>>>>>>> defines: >>>>>>>> RFC2119 reads: >>>>>>>> >>>>>>>> * * >>>>>>>> >>>>>>>> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean >>>>>>>> that the >>>>>>>> definition is an absolute requirement of the specification. >>>>>>>> >>>>>>>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean >>>>>>>> that there >>>>>>>> may exist valid reasons in particular circumstances to ignore a >>>>>>>> particular item, but the full implications must be >>>>>>>> understood and >>>>>>>> carefully weighed before choosing a different course. >>>>>>>> >>>>>>>> >>>>>>>> So, the situation is that if the triggering of the binding >>>>>>>> creation by data packet si not implemented, a legitimate user >>>>>>>> will be disconnected from the network in case the state is loss >>>>>>>> or in case a failure results in a change in the topology. So >>>>>>>> this actually affects interoperability. >>>>>>>> >>>>>>>> The alternative would be a SHOULD properly qualified. >>>>>>>> >>>>>>>> I think that for the SLAAC/ND case, it is much more likely that >>>>>>>> the situation occurs (due to packet loss and the non reliable >>>>>>>> nature of the DAD procedure), so i really think that the >>>>>>>> triggering of the SAVI binding creation process upon the >>>>>>>> recpetion of data packets should be a MUST. >>>>>>>> >>>>>>>> For the dhcp case, the cases in whcih this fails are reduced >>>>>>>> because of the reliable nature of the dhcp exchange, so while i >>>>>>>> would rather go for a MUST, i think i can live with a SHOULD. >>>>>>>>> One can make the argument that this is a risk taken by the >>>>>>>>> entity that chooses to deploy SAVI partially and that SAVI >>>>>>>>> mandates things that are needed for a totally SAVI enabled >>>>>>>>> network where all devices have this, and in the case not all >>>>>>>>> of them have SAVI functionality, then things will break unless >>>>>>>>> a MAY or SHOULD clause is implemented? >>>>>>>>> >>>>>>>> No, a MAY is something that is completelly optional and would >>>>>>>> not affect interop in any way. >>>>>>>> >>>>>>>> As i said above, in the case of dhcp, if the SHOULD is properly >>>>>>>> qualified, i could live with that. >>>>>>>> >>>>>>>> >>>>>>>>> I don't like the situation where some vendors might not offer >>>>>>>>> SAVI at all, to handle the problem you're describing. >>>>>>>>> >>>>>>>> Right, i do have this concern as well, but i am very worried >>>>>>>> about the impact to the overall robustness fo the network. >>>>>>>> >>>>>>>> Regards, marcelo >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> savi mailing list >>>>>>>> savi@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>> >> >> > From marcelo@it.uc3m.es Mon Mar 15 09:47:11 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998383A697E for ; Mon, 15 Mar 2010 09:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qB9OYUMDG7IK for ; Mon, 15 Mar 2010 09:47:10 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 30AB03A6884 for ; Mon, 15 Mar 2010 09:47:10 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 58F036C68A3 for ; Mon, 15 Mar 2010 17:47:16 +0100 (CET) Message-ID: <4B9E6494.4000807@it.uc3m.es> Date: Mon, 15 Mar 2010 17:47:16 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: savi@ietf.org References: <09741A6EA86846049A114B745EE24C37@junbiVAIO> <4B9E2ECD.7080504@cisco.com> <000a01cac445$5b2465e0$116d31a0$@tsinghua.edu.cn> <4B9E407C.8000303@cisco.com> In-Reply-To: <4B9E407C.8000303@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Subject: Re: [savi] savi-dhcp-02 draft X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 16:47:11 -0000 El 15/03/10 15:13, Eric Levy-Abegnoli escribió: > Hi Guang, > > Guang Yao a écrit : >> Hi Eric, >> >> Thanks for your suggestion. Your experience is very valuable. >> >> In this solution, sending DHCP lease query is optional, just to >> handle some >> special cases (in general, data triggered but rather control packet). >> It is >> not required to be enabled. Vendors may choose to implement it on >> layer 3 >> device but not pure layer 2 device. And network administrators may not >> enable this function if they find the device may be overloaded. >> >> If binding is learnt from NDP, IMO it should be bound in savi-slaac, >> but not >> in this solution for DHCP. And the which to prefer in case of >> co-existing of >> NDP and DHCP, I think should be specified in the framework doc. Am I >> right? >> >> BR, >> Guang > What I meant is that the proposed method (sending a leasequery to > re-discover a binding lost in case of the switch reboot) cannot be > used as a "general" response to the problem raised. A switch, L2-only > device, that looses its binding table and has no non-volatile memory > has just no way to recover it thru DHCP. It's is unfortunate since > DHCP is considered as the only authoritative method for discovering > bindings. > I would consider that at the stage, when DHCP is used, non-volatile > memory is the only option. How do you deal with the SAVI device not having state due to a change in the topology due to an outage? See the thread called " the impact of SAVI in the overall network robustness" for the details Regards, marcelo > Eric >>> -----Original Message----- >>> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of >> Eric >>> Levy-Abegnoli >>> Sent: Monday, March 15, 2010 8:58 PM >>> To: Bi Jun >>> Cc: SAVI Mailing List >>> Subject: Re: [savi] savi-dhcp-02 draft >>> >>> Bi Jun a écrit : >>>> Hi all, >>>> >>>> This is a revised version of savi-dhcp (revised based on the >>>> discussion of dhcp-01 on the mailing-list in the past week), >>>> basically, make the control packet-triggered functions as MUST (low >>>> cost to be implemented in every switch), and have the data-triggered >>>> functions (more complex to be implemented) as optional for higher-end >>>> switches (to enable more flexible use of savi device). >>>> >>>> We are consulting the vendors on the cost for those options. >>>> >>>> please give us your comments. >>>> >>>> thanks, >>>> Jun Bi SAVI >>> J. >>>> Bi, J. Wu >>> Hi Jun bi, >>> Reading the below: >>> >>> "IPv6 address: >>> Send a LEASEQUERY [RFC5007] message querying by IP address to >>> All_DHCP_Relay_Agents_and_Servers multicast address or a >>> configured server address. If no successful LEASEQUERY-REPLY is >>> received, discard the packet; otherwise generate a new binding >>> entry for the address. The SAVI device may repeat this process if >>> a LEASEQUERY-REPLY with OPTION_CLIENT_LINK is received, in order >>> to set up binding entries for all the address of the client." >>> >>> I don't think the below proposal to discover IPv6 address from the savi >>> device works. DHCP messages must be sourced with an IPv6 address >>> (can't >>> be UNSPEC, must be a link-local) and in most cases, the switch does not >>> have any. That would take the switch to have a L3 interface that >>> participate in the link operations (for each of its vlans), and that is >>> a huge constrain. >>> I have real deployment examples of pure L2 switch devices with >>> thousands >>> of vlans configured (hundreds of ports in each vlan). Getting a L3 >>> address in each vlan would have a huge impact on the switch operations >>> and performances.That does not seem acceptable. >>> I think the only option is to discover the binding by probing with a >>> NDP >>> DAD NS. This one is sourced with UNSPEC and hence is accpetable for >>> a L2 >>> device. Then install the binding as learnt from NDP. And later, >>> "prefer" the DHCP binding when/if it shows up. >>> Eric >>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@tsinghua.edu.cn Mon Mar 15 09:56:40 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1859F3A6972 for ; Mon, 15 Mar 2010 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCZbJfd53uW0 for ; Mon, 15 Mar 2010 09:56:35 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 6A9833A68F6 for ; Mon, 15 Mar 2010 09:56:33 -0700 (PDT) Received: from th053201.ip.tsinghua.edu.cn ([59.66.53.201] helo=junbiVAIO) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NrDao-0006ER-1c; Tue, 16 Mar 2010 00:56:38 +0800 Message-ID: <9B138362EB264233BF068B2C804A8F0E@junbiVAIO> From: "Jun Bi" To: "marcelo bagnulo braun" References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es><4B9E1BF3.9080709@it.uc3m.es><231D9821F3704A09BCB0B166137AA034@junbiVAIO><4B9E3D5C.6040600@it.uc3m.es><876F7DBECC2348C695021E77315654F0@junbiVAIO> <4B9E4E84.1090003@it.uc3m.es> <0F84A919BFA04A5CB05C6010251A11B3@junbiVAIO> <4B9E586D.9070800@it.uc3m.es> <4B9E634B.80606@it.uc3m.es> In-Reply-To: <4B9E634B.80606@it.uc3m.es> Date: Tue, 16 Mar 2010 00:56:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 16:56:40 -0000 -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Tuesday, March 16, 2010 12:41 AM To: "Jun Bi" Cc: "Bi Jun" ; Subject: Re: [savi] savi-dhcp-02 > El 15/03/10 17:12, Jun Bi escribió: >> The access-level switch products of H3C(3Com), ZTE, Ruijie, Digital >> China(spinned from from Lenovo). Please pay attention to: access level >> switches, not higher-end switches. >> > > So, basically you are saying that all these vendors are able to trigger > the binding creation process upon the reception of a data packet, but only > in their high end devices, is that correct? But that they cannot provide > it in the access level, correct? > > Please note that is fully compatible with the deployment model of SAVI > with legacy devices, where you can deploy a core of SAVI devices and then > connect a bunch of access devices that don't implement SAVI. I don't understand you. In my opinion, MUST functions for all switches including low-end, optional functions for higher-end switches will fully compatible with both the implementation and deployment reality. > > Another question is would these vendors be able to store the SAVI binding > information in non volatile memory for the access devices or only for the > high end devices? We are asking, seems OK for them. Every access switch in the catalog of low-end has the flash. We save the configuration of the IP management address configuration, MIB and other data in the flash. > > Regards, marcelo > > PS: I will ask the vendor that provided me the info to contact you either > in the ml or privately. > > >> >> >>> >>> Regards, marcelo >>>> You know CNGI-CERNET2 is deploying savi >>>> in large scale in 100 universities. If any vendor implements >>>> data-triggered >>>> functions in low-end access switch (we use those switch to directly >>>> connect hosts) >>>> with the same price as the savi access switch that implemented >>>> control-packet triggered functions (we purchased about 50000 >>>> savi-switches), we'd like to buy more from this new vendor. >>>> >>>> thanks! >>>> Jun >>>> >>>> >>>> >>>> >>>>>> So my idea is: >>>>>> 1 make two RFCs, one for each catalog of functions used for different >>>>>> scenarios. >>>>>> 2 make one RFC, but make MUST for basic functions, make other >>>>>> functions as options. And provide a guideline to users: >>>>>> (1) If the users want to plus a host directly a savi-device, deploy >>>>>> cheap switch only implement MUST >>>>>> (2) If users want to connect host to a old hub, then connect the hub >>>>>> savi-device (like the pictures you drown), then if you think >>>>>> best-effort is OK for you (if you have problem, reboot your hub or >>>>>> repaired the host-connection, deploy the cheap switch only implement >>>>>> MUST >>>>>> (3) in the above case, if you want 100% service quality, then buy a >>>>>> higher-end savi-device that implement options in this RFC. >>>>>> >>>>> Actually, i don't agree with this approach. I think we have the >>>>> normative language as specified in RFC 2116 exactly to deal with this >>>>> type of situations. >>>>> I don't want to have all the SAVI funcionality spread over more RFCs, >>>>> we already have split the SAVI spec in more than we should and i don't >>>>> think it would make sense to divide it even more. >>>>> >>>>> I think we need to have one RFC for dhcp savi and one for SLAAC savi >>>>> >>>>> We need to agree on what features are MUST and which ones are SHOULD. >>>>> >>>>> As i suggested already,. imho the triggering of the binding creation >>>>> mechanisms upon the reception of a data packet for whcih there is no >>>>> binding should be a MUST for both cases. >>>>> >>>>> I could live with a qualified SHOULD for the DHCP case and a MUST for >>>>> the SLAAC case, based on the faact that the DHCP exchange is reliable >>>>> and hence the problem of packet loss is not an issue for the DHCP case >>>>> while it is so for the SLAAC case >>>>> >>>>> I think i could also live with Guang's suggestion of having A MUST for >>>>> both cases and also require as a MUST that the feature MUST be >>>>> configurable on/off >>>>> >>>>> Regards, marcelo >>>>> >>>>>> thanks, >>>>>> Jun >>>>>> -------------------------------------------------- >>>>>> From: "marcelo bagnulo braun" >>>>>> Sent: Monday, March 15, 2010 9:59 PM >>>>>> To: "Bi Jun" >>>>>> Cc: >>>>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>>>> >>>>>>> El 15/03/10 13:19, Bi Jun escribió: >>>>>>>> Hi Marcelo, >>>>>>>> >>>>>>>> The sentence is misleading. >>>>>>>> "So, the situation is that if the triggering of the binding >>>>>>>> creation by >>>>>>>> data packet si not implemented, a legitimate user will be >>>>>>>> disconnected " >>>>>>>> >>>>>>>> It only happens for some situations. >>>>>>> >>>>>>> Right, it only happen in some situation, but that is what robustness >>>>>>> is about, right? >>>>>>> I mean, this affects interoperability, becuase it may happen that >>>>>>> the communication of a legitimate host is interrupted due to this. >>>>>>>> If the "MUST" only handles some situation but bring *much more* >>>>>>>> cost to the device (it's really because the data-triggered solution >>>>>>>> is not a low cost action), >>>>>>>> then I think the right ways: >>>>>>>> >>>>>>>> 1 "MUST" for all cases, and list some limitation and guide the >>>>>>>> users. >>>>>>>> 2 "Options" for some special cases, users has the guide to buy the >>>>>>>> higher-end device >>>>>>>> if they want more flexible use of savi device, (certainly, by >>>>>>>> paying higher price for the device.). >>>>>>>> >>>>>>> As i said, i don't think in any case this is optional. >>>>>>> >>>>>>> IMHO, this is a MUST becuase it affect interoperability. >>>>>>> If there is no consensus to go for a MUST, i can live with, for the >>>>>>> dhcp case and only for the dhcp case, since the subset of >>>>>>> problematic cases is more limited than the ND case, we could use a >>>>>>> qualified SHOULD, which means that the implementation SHOULD do that >>>>>>> and we explian what happens if they don't. How about that? >>>>>>> >>>>>>> Regards, marcelo >>>>>>> >>>>>>> >>>>>>> >>>>>>>> That's my answer to all your similar questions. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Jun Bi >>>>>>>> >>>>>>>> -------------------------------------------------- >>>>>>>> From: "marcelo bagnulo braun" >>>>>>>> Sent: Monday, March 15, 2010 7:37 PM >>>>>>>> To: >>>>>>>> Subject: Re: [savi] call for comments: savi-dhcp-01 >>>>>>>> >>>>>>>>> Hi Mikael, >>>>>>>>> >>>>>>>>> sorry for the delay, been away for a few days >>>>>>>>> >>>>>>>>> below... >>>>>>>>> >>>>>>>>> El 09/03/10 10:46, Mikael Abrahamsson escribió: >>>>>>>>>> On Tue, 9 Mar 2010, marcelo bagnulo braun wrote: >>>>>>>>>> >>>>>>>>>>> but this is what we qualify as a must in the ietf terminology. >>>>>>>>>>> If you don't do this, the network breaks in different ways, >>>>>>>>>>> right? >>>>>>>>>> >>>>>>>>>> I don't agree that this is a must. This breakage is limited to >>>>>>>>>> certain operational concerns, it's not a fundamental problem that >>>>>>>>>> makes it not work at all. >>>>>>>>>> >>>>>>>>> Let's go back to RFC 2119 where the usage of these terms is >>>>>>>>> defines: >>>>>>>>> RFC2119 reads: >>>>>>>>> >>>>>>>>> * * >>>>>>>>> >>>>>>>>> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that >>>>>>>>> the >>>>>>>>> definition is an absolute requirement of the specification. >>>>>>>>> >>>>>>>>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that >>>>>>>>> there >>>>>>>>> may exist valid reasons in particular circumstances to ignore a >>>>>>>>> particular item, but the full implications must be understood >>>>>>>>> and >>>>>>>>> carefully weighed before choosing a different course. >>>>>>>>> >>>>>>>>> >>>>>>>>> So, the situation is that if the triggering of the binding >>>>>>>>> creation by data packet si not implemented, a legitimate user will >>>>>>>>> be disconnected from the network in case the state is loss or in >>>>>>>>> case a failure results in a change in the topology. So this >>>>>>>>> actually affects interoperability. >>>>>>>>> >>>>>>>>> The alternative would be a SHOULD properly qualified. >>>>>>>>> >>>>>>>>> I think that for the SLAAC/ND case, it is much more likely that >>>>>>>>> the situation occurs (due to packet loss and the non reliable >>>>>>>>> nature of the DAD procedure), so i really think that the >>>>>>>>> triggering of the SAVI binding creation process upon the recpetion >>>>>>>>> of data packets should be a MUST. >>>>>>>>> >>>>>>>>> For the dhcp case, the cases in whcih this fails are reduced >>>>>>>>> because of the reliable nature of the dhcp exchange, so while i >>>>>>>>> would rather go for a MUST, i think i can live with a SHOULD. >>>>>>>>>> One can make the argument that this is a risk taken by the entity >>>>>>>>>> that chooses to deploy SAVI partially and that SAVI mandates >>>>>>>>>> things that are needed for a totally SAVI enabled network where >>>>>>>>>> all devices have this, and in the case not all of them have SAVI >>>>>>>>>> functionality, then things will break unless a MAY or SHOULD >>>>>>>>>> clause is implemented? >>>>>>>>>> >>>>>>>>> No, a MAY is something that is completelly optional and would not >>>>>>>>> affect interop in any way. >>>>>>>>> >>>>>>>>> As i said above, in the case of dhcp, if the SHOULD is properly >>>>>>>>> qualified, i could live with that. >>>>>>>>> >>>>>>>>> >>>>>>>>>> I don't like the situation where some vendors might not offer >>>>>>>>>> SAVI at all, to handle the problem you're describing. >>>>>>>>>> >>>>>>>>> Right, i do have this concern as well, but i am very worried about >>>>>>>>> the impact to the overall robustness fo the network. >>>>>>>>> >>>>>>>>> Regards, marcelo >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> savi mailing list >>>>>>>>> savi@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>> >>> >>> >> > > From elevyabe@cisco.com Mon Mar 15 10:33:52 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15A493A6A7D for ; Mon, 15 Mar 2010 10:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.367 X-Spam-Level: X-Spam-Status: No, score=-4.367 tagged_above=-999 required=5 tests=[AWL=-1.768, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9-+Oudkvuff for ; Mon, 15 Mar 2010 10:33:51 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 8D0923A698C for ; Mon, 15 Mar 2010 10:32:09 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsBALILnkuQ/uCWe2dsb2JhbACacRUBAQsLJAYcoX+XdIR7BA X-IronPort-AV: E=Sophos;i="4.49,644,1262563200"; d="scan'208";a="4361474" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 15 Mar 2010 16:58:41 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2FHWGub003297; Mon, 15 Mar 2010 17:32:16 GMT Received: from xmb-ams-105.cisco.com ([144.254.74.80]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 18:32:15 +0100 Received: from [144.254.53.100] ([144.254.53.100]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 18:32:15 +0100 Message-ID: <4B9E6F1E.7010901@cisco.com> Date: Mon, 15 Mar 2010 18:32:14 +0100 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: marcelo bagnulo braun References: <09741A6EA86846049A114B745EE24C37@junbiVAIO> <4B9E2ECD.7080504@cisco.com> <000a01cac445$5b2465e0$116d31a0$@tsinghua.edu.cn> <4B9E407C.8000303@cisco.com> <4B9E6494.4000807@it.uc3m.es> In-Reply-To: <4B9E6494.4000807@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Mar 2010 17:32:15.0450 (UTC) FILETIME=[743EE3A0:01CAC465] Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02 draft X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 17:33:52 -0000 marcelo bagnulo braun a écrit : > El 15/03/10 15:13, Eric Levy-Abegnoli escribió: >> Hi Guang, >> >> Guang Yao a écrit : >>> Hi Eric, >>> >>> Thanks for your suggestion. Your experience is very valuable. >>> >>> In this solution, sending DHCP lease query is optional, just to >>> handle some >>> special cases (in general, data triggered but rather control >>> packet). It is >>> not required to be enabled. Vendors may choose to implement it on >>> layer 3 >>> device but not pure layer 2 device. And network administrators may not >>> enable this function if they find the device may be overloaded. >>> >>> If binding is learnt from NDP, IMO it should be bound in savi-slaac, >>> but not >>> in this solution for DHCP. And the which to prefer in case of >>> co-existing of >>> NDP and DHCP, I think should be specified in the framework doc. Am I >>> right? >>> >>> BR, >>> Guang >> What I meant is that the proposed method (sending a leasequery to >> re-discover a binding lost in case of the switch reboot) cannot be >> used as a "general" response to the problem raised. A switch, L2-only >> device, that looses its binding table and has no non-volatile memory >> has just no way to recover it thru DHCP. It's is unfortunate since >> DHCP is considered as the only authoritative method for discovering >> bindings. >> I would consider that at the stage, when DHCP is used, non-volatile >> memory is the only option. > > How do you deal with the SAVI device not having state due to a change > in the topology due to an outage? You are describing a problem, not a solution. Sounds like we have a problem without a solution then. Because discovering addresses from the switch by sourcing DHCP messages is not a viable solution. Might work in some cases. Will not in most. Eric > > See the thread called " the impact of SAVI in the overall network > robustness" for the details > > Regards, marcelo > > > > >> Eric >>>> -----Original Message----- >>>> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On >>>> Behalf Of >>> Eric >>>> Levy-Abegnoli >>>> Sent: Monday, March 15, 2010 8:58 PM >>>> To: Bi Jun >>>> Cc: SAVI Mailing List >>>> Subject: Re: [savi] savi-dhcp-02 draft >>>> >>>> Bi Jun a écrit : >>>>> Hi all, >>>>> >>>>> This is a revised version of savi-dhcp (revised based on the >>>>> discussion of dhcp-01 on the mailing-list in the past week), >>>>> basically, make the control packet-triggered functions as MUST (low >>>>> cost to be implemented in every switch), and have the data-triggered >>>>> functions (more complex to be implemented) as optional for higher-end >>>>> switches (to enable more flexible use of savi device). >>>>> >>>>> We are consulting the vendors on the cost for those options. >>>>> >>>>> please give us your comments. >>>>> >>>>> thanks, >>>>> Jun Bi SAVI >>>> J. >>>>> Bi, J. Wu >>>> Hi Jun bi, >>>> Reading the below: >>>> >>>> "IPv6 address: >>>> Send a LEASEQUERY [RFC5007] message querying by IP address to >>>> All_DHCP_Relay_Agents_and_Servers multicast address or a >>>> configured server address. If no successful LEASEQUERY-REPLY is >>>> received, discard the packet; otherwise generate a new binding >>>> entry for the address. The SAVI device may repeat this >>>> process if >>>> a LEASEQUERY-REPLY with OPTION_CLIENT_LINK is received, in order >>>> to set up binding entries for all the address of the client." >>>> >>>> I don't think the below proposal to discover IPv6 address from the >>>> savi >>>> device works. DHCP messages must be sourced with an IPv6 address >>>> (can't >>>> be UNSPEC, must be a link-local) and in most cases, the switch does >>>> not >>>> have any. That would take the switch to have a L3 interface that >>>> participate in the link operations (for each of its vlans), and >>>> that is >>>> a huge constrain. >>>> I have real deployment examples of pure L2 switch devices with >>>> thousands >>>> of vlans configured (hundreds of ports in each vlan). Getting a L3 >>>> address in each vlan would have a huge impact on the switch operations >>>> and performances.That does not seem acceptable. >>>> I think the only option is to discover the binding by probing with >>>> a NDP >>>> DAD NS. This one is sourced with UNSPEC and hence is accpetable for >>>> a L2 >>>> device. Then install the binding as learnt from NDP. And later, >>>> "prefer" the DHCP binding when/if it shows up. >>>> Eric >>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>> >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Mon Mar 15 10:36:21 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23A13A6805 for ; Mon, 15 Mar 2010 10:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.508 X-Spam-Level: X-Spam-Status: No, score=-106.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGyZqeXPtGNp for ; Mon, 15 Mar 2010 10:36:19 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id B51083A6A09 for ; Mon, 15 Mar 2010 10:35:26 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 257C96C6E37; Mon, 15 Mar 2010 18:35:33 +0100 (CET) Message-ID: <4B9E6FE4.6080402@it.uc3m.es> Date: Mon, 15 Mar 2010 18:35:32 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Eric Levy-Abegnoli References: <09741A6EA86846049A114B745EE24C37@junbiVAIO> <4B9E2ECD.7080504@cisco.com> <000a01cac445$5b2465e0$116d31a0$@tsinghua.edu.cn> <4B9E407C.8000303@cisco.com> <4B9E6494.4000807@it.uc3m.es> <4B9E6F1E.7010901@cisco.com> In-Reply-To: <4B9E6F1E.7010901@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02 draft X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 17:36:21 -0000 El 15/03/10 18:32, Eric Levy-Abegnoli escribió: > marcelo bagnulo braun a écrit : >> El 15/03/10 15:13, Eric Levy-Abegnoli escribió: >>> Hi Guang, >>> >>> Guang Yao a écrit : >>>> Hi Eric, >>>> >>>> Thanks for your suggestion. Your experience is very valuable. >>>> >>>> In this solution, sending DHCP lease query is optional, just to >>>> handle some >>>> special cases (in general, data triggered but rather control >>>> packet). It is >>>> not required to be enabled. Vendors may choose to implement it on >>>> layer 3 >>>> device but not pure layer 2 device. And network administrators may not >>>> enable this function if they find the device may be overloaded. >>>> >>>> If binding is learnt from NDP, IMO it should be bound in >>>> savi-slaac, but not >>>> in this solution for DHCP. And the which to prefer in case of >>>> co-existing of >>>> NDP and DHCP, I think should be specified in the framework doc. Am >>>> I right? >>>> >>>> BR, >>>> Guang >>> What I meant is that the proposed method (sending a leasequery to >>> re-discover a binding lost in case of the switch reboot) cannot be >>> used as a "general" response to the problem raised. A switch, >>> L2-only device, that looses its binding table and has no >>> non-volatile memory has just no way to recover it thru DHCP. It's is >>> unfortunate since DHCP is considered as the only authoritative >>> method for discovering bindings. >>> I would consider that at the stage, when DHCP is used, non-volatile >>> memory is the only option. >> >> How do you deal with the SAVI device not having state due to a change >> in the topology due to an outage? > You are describing a problem, not a solution. right > Sounds like we have a problem without a solution then. Because > discovering addresses from the switch by sourcing DHCP messages is > not a viable solution. Might work in some cases. Will not in most. could you expand on why it will not work? I am not sure i have understood it from your previous emails. Regards, marcelo > > Eric >> >> See the thread called " the impact of SAVI in the overall network >> robustness" for the details >> >> Regards, marcelo >> >> >> >> >>> Eric >>>>> -----Original Message----- >>>>> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On >>>>> Behalf Of >>>> Eric >>>>> Levy-Abegnoli >>>>> Sent: Monday, March 15, 2010 8:58 PM >>>>> To: Bi Jun >>>>> Cc: SAVI Mailing List >>>>> Subject: Re: [savi] savi-dhcp-02 draft >>>>> >>>>> Bi Jun a écrit : >>>>>> Hi all, >>>>>> >>>>>> This is a revised version of savi-dhcp (revised based on the >>>>>> discussion of dhcp-01 on the mailing-list in the past week), >>>>>> basically, make the control packet-triggered functions as MUST (low >>>>>> cost to be implemented in every switch), and have the data-triggered >>>>>> functions (more complex to be implemented) as optional for >>>>>> higher-end >>>>>> switches (to enable more flexible use of savi device). >>>>>> >>>>>> We are consulting the vendors on the cost for those options. >>>>>> >>>>>> please give us your comments. >>>>>> >>>>>> thanks, >>>>>> Jun Bi SAVI >>>>> J. >>>>>> Bi, J. Wu >>>>> Hi Jun bi, >>>>> Reading the below: >>>>> >>>>> "IPv6 address: >>>>> Send a LEASEQUERY [RFC5007] message querying by IP address to >>>>> All_DHCP_Relay_Agents_and_Servers multicast address or a >>>>> configured server address. If no successful LEASEQUERY-REPLY is >>>>> received, discard the packet; otherwise generate a new binding >>>>> entry for the address. The SAVI device may repeat this >>>>> process if >>>>> a LEASEQUERY-REPLY with OPTION_CLIENT_LINK is received, in >>>>> order >>>>> to set up binding entries for all the address of the client." >>>>> >>>>> I don't think the below proposal to discover IPv6 address from the >>>>> savi >>>>> device works. DHCP messages must be sourced with an IPv6 address >>>>> (can't >>>>> be UNSPEC, must be a link-local) and in most cases, the switch >>>>> does not >>>>> have any. That would take the switch to have a L3 interface that >>>>> participate in the link operations (for each of its vlans), and >>>>> that is >>>>> a huge constrain. >>>>> I have real deployment examples of pure L2 switch devices with >>>>> thousands >>>>> of vlans configured (hundreds of ports in each vlan). Getting a L3 >>>>> address in each vlan would have a huge impact on the switch >>>>> operations >>>>> and performances.That does not seem acceptable. >>>>> I think the only option is to discover the binding by probing with >>>>> a NDP >>>>> DAD NS. This one is sourced with UNSPEC and hence is accpetable >>>>> for a L2 >>>>> device. Then install the binding as learnt from NDP. And later, >>>>> "prefer" the DHCP binding when/if it shows up. >>>>> Eric >>>>> >>>>> >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > From fred@cisco.com Mon Mar 15 15:39:51 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D1A3A67E4 for ; Mon, 15 Mar 2010 15:39:51 -0700 (PDT) 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.451, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPkwLxh8W7SV for ; Mon, 15 Mar 2010 15:39:50 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2C2CE3A6BF7 for ; Mon, 15 Mar 2010 15:39:38 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFtUnktAZnwM/2dsb2JhbACacHOgVJgmhHsE X-IronPort-AV: E=Sophos;i="4.49,645,1262563200"; d="scan'208";a="93044358" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2010 22:39:45 +0000 Received: from [10.149.3.196] (rtp-vpn3-207.cisco.com [10.82.216.207]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2FMdj73026699; Mon, 15 Mar 2010 22:39:45 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4B9E3E11.8080403@it.uc3m.es> Date: Mon, 15 Mar 2010 18:39:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <80FEFC68-4A49-4123-8AF6-8253DF759A6E@cisco.com> References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es> <4B9E1BF3.9080709@it.uc3m.es> <000901cac442$d7967d50$86c377f0$@tsinghua.edu.cn> <4B9E3E11.8080403@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1077) Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 22:39:51 -0000 I'm confused. Cisco, as has been noted way back when, has essentially = the SAVI/SHCP draft implemented for IPv4 and has had it in live networks = for a number of years. We see no such issue. Why would there be one with = IPv6 if there is none with IPv4? In networks that use the feature, hosts and routers are attached to = switch ports, as are inter-switch trunk groups. There is no protection = on routers or inter-switch trunks, for the simple reason that datagrams = can cross those ports with any source address, routers can be configured = with reverse lookup, and hosts have already been tested at their ingress = ports. We can also turn off checking on any other system that we want to = configure a static address on, or statically configure its port filter. = Those that remain get their addresses via DHCP, and there is no reason = for them to use any address that has not been assigned to them, by = policy. So dropping traffic that doesn't use the DHCP-assigned address = (in IPv6, dropping traffic that doesn't use *a* DHCP-assigned address), = is not a reduction of robustness. It is the correct application of = policy and kind of the point of this whole exercise. What reduction in robustness do you see? In what way is that reduction = in robustness not the correct application of policy? On Mar 15, 2010, at 10:02 AM, marcelo bagnulo braun wrote: > I beg to differ. My concern is that if we simply drop the packets for = which there is no binding, the overall network robustness will be = affected. http://www.ipinc.net/IPv4.GIF From pekkas@netcore.fi Tue Mar 16 00:42:33 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557CB3A68E4 for ; Tue, 16 Mar 2010 00:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6UyZPQutgZU for ; Tue, 16 Mar 2010 00:42:32 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 24CB63A63C9 for ; Tue, 16 Mar 2010 00:42:31 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id o2G7g0sf029081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Mar 2010 09:42:00 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id o2G7fxbE029078; Tue, 16 Mar 2010 09:42:00 +0200 Date: Tue, 16 Mar 2010 09:41:59 +0200 (EET) From: Pekka Savola To: "Joel M. Halpern" In-Reply-To: <4B9E4ECF.1050108@joelhalpern.com> Message-ID: References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> <019C6F3B5F9C4B9F816588E35A440555@junbiVAIO> <4B9E3C24.5060504@it.uc3m.es> <4B9E4A72.2040808@it.uc3m.es> <4B9E4E25.8020807@joelhalpern.com> <4B9E4ECF.1050108@joelhalpern.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: X-Virus-Scanned: clamav-milter 0.95.3 at otso.netcore.fi X-Virus-Status: Clean Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 07:42:33 -0000 On Mon, 15 Mar 2010, Joel M. Halpern wrote: > I realized after sending this that it was not as clear as I would like. One > can write SHOULD statements that are not protocol detectable. If they are at > least controllable by the implementor. Marcelo has argued cogently that not > even the deployer can reliably know if this condition is actually being met. > (Which, for the DHCP case, makes storing state in NVRAM a very sensible > behavior.) FWIW, I agree with Marcelo's and Joel's point here. As an operator, I would not be very comfortable deploying a solution that described lack of robustness in the scenario Marcelo described. As a user, I would be strongly opposed if e.g. an ISP would deploy such network robustness degrading mechanism. As a participant in telecom regulation, I would be pushing for regulations which disallow ISPs from deploying mechanisms like these in the customer front. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From junbi@tsinghua.edu.cn Tue Mar 16 01:11:47 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1D83A6874 for ; Tue, 16 Mar 2010 01:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9dp5yN7YBxt for ; Tue, 16 Mar 2010 01:11:46 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id E6D3A3A6805 for ; Tue, 16 Mar 2010 01:11:39 -0700 (PDT) Received: from th024139.ip.tsinghua.edu.cn ([59.66.24.139] helo=junbiVAIO) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NrRsC-00066Z-0g; Tue, 16 Mar 2010 16:11:32 +0800 Message-ID: <8D1B9698A2664BEAAA1906C906A42627@junbiVAIO> From: "Jun Bi" To: "Pekka Savola" , "Joel M. Halpern" References: <4B95FDE7.8070100@it.uc3m.es><4B9E2382.8000304@it.uc3m.es><019C6F3B5F9C4B9F816588E35A440555@junbiVAIO><4B9E3C24.5060504@it.uc3m.es><4B9E4A72.2040808@it.uc3m.es><4B9E4E25.8020807@joelhalpern.com> <4B9E4ECF.1050108@joelhalpern.com> In-Reply-To: Date: Tue, 16 Mar 2010 16:11:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 08:11:47 -0000 Hi Pekka, Thank you for your comment. Did you see Fred Baker's comment? By the way, maybe, you might misunderstood Joel's opinion. thanks, Jun Bi -------------------------------------------------- From: "Pekka Savola" Sent: Tuesday, March 16, 2010 3:41 PM To: "Joel M. Halpern" Cc: "SAVI Mailing List" Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi > On Mon, 15 Mar 2010, Joel M. Halpern wrote: >> I realized after sending this that it was not as clear as I would like. >> One can write SHOULD statements that are not protocol detectable. If >> they are at least controllable by the implementor. Marcelo has argued >> cogently that not even the deployer can reliably know if this condition >> is actually being met. (Which, for the DHCP case, makes storing state in >> NVRAM a very sensible behavior.) > > FWIW, I agree with Marcelo's and Joel's point here. As an operator, I > would not be very comfortable deploying a solution that described lack of > robustness in the scenario Marcelo described. As a user, I would be > strongly opposed if e.g. an ISP would deploy such network robustness > degrading mechanism. As a participant in telecom regulation, I would be > pushing for regulations which disallow ISPs from deploying mechanisms like > these in the customer front. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From fred@cisco.com Tue Mar 16 03:50:54 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C61A53A69B4 for ; Tue, 16 Mar 2010 03:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.832 X-Spam-Level: X-Spam-Status: No, score=-110.832 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4zh1OCuUTqj for ; Tue, 16 Mar 2010 03:50:53 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B8F403A67E1 for ; Tue, 16 Mar 2010 03:50:53 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADf/nkurR7Ht/2dsb2JhbACafnOfA5hihHwE X-IronPort-AV: E=Sophos;i="4.49,649,1262563200"; d="scan'208";a="100766697" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 16 Mar 2010 10:48:27 +0000 Received: from [10.149.3.196] (rtp-vpn3-207.cisco.com [10.82.216.207]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2GAmQ0L004527; Tue, 16 Mar 2010 10:48:26 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4B95039F.7030908@it.uc3m.es> Date: Tue, 16 Mar 2010 06:48:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1077) Cc: savi@ietf.org Subject: Re: [savi] call for comments: savi-dhcp-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 10:50:54 -0000 On Mar 8, 2010, at 9:03 AM, marcelo bagnulo braun wrote: > If SAVI switches reboots imply that the communication will be = interrupted unless all switches are upgraded to support SAVI, then if = you only replace one switch, then you are breaking your netwokr. So in = order to work properly, you need to upgrade all the network. So, this is = not incrementally deployable Marcelo: Is this the loss of robustness that you are asserting? If so, you're discussing something different than Jun Bi is talking = about. In the DHCP case, a switch looks only at traffic that enters the = switching network on one of its ports. Since it is only protecting its = own ports, there is no question of it having to have memory to represent = addresses on other switches. An un-upgraded switch represents a = vulnerability in the switching network - that switch doesn't prevent = spoofed packets in its network - but it does not prevent other switches = from protecting their ports.=20 On Cisco switches, we implement SAVI using what we call the "port = filter". Switches that have that capability (not all do) require a = software change to provide the programming. This is the upgrade that Jun = Bi mentions. For IPv4 that is pretty simple; for IPv6 is is less simple = due to the number of terms available in the port filter. One may need a = hardware upgrade if the port filter isn't adequate; that is a question = of the specific hardware involved. I can only speak from the perspective of deployed equipment, but in our = experience DHCP-based SAVI is quite robust. I'm finding this whole = thread pretty confusing as a result. http://www.ipinc.net/IPv4.GIF From fred@cisco.com Tue Mar 16 03:57:46 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03C63A67E1 for ; Tue, 16 Mar 2010 03:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.799 X-Spam-Level: X-Spam-Status: No, score=-110.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vnf-1YH657uT for ; Tue, 16 Mar 2010 03:57:45 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 77A033A683A for ; Tue, 16 Mar 2010 03:57:45 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABcBn0urR7Hu/2dsb2JhbACafnOfSphkhHwE X-IronPort-AV: E=Sophos;i="4.49,649,1262563200"; d="scan'208";a="497326705" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 16 Mar 2010 10:57:54 +0000 Received: from [10.149.3.196] (rtp-vpn3-207.cisco.com [10.82.216.207]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2GAvq3f003508; Tue, 16 Mar 2010 10:57:52 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Fred Baker In-Reply-To: <4B9E2382.8000304@it.uc3m.es> Date: Tue, 16 Mar 2010 06:57:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6F4B5FA5-2EAE-4435-A06B-4B5A8E083DF6@cisco.com> References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1077) Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 10:57:46 -0000 If this is the lack of robustness you're talking about, then I would = have to agree with Jun that having the switch re-check the DHCP binding = with the DHCP server gets it the information it needs. It drops packets = for a period measured in hundreds to thousands of milliseconds while the = situation is sorted out, but I doubt you would see a TCP session loss = from this alone. I'm afraid we don't see your concerns in the field. On Mar 15, 2010, at 8:09 AM, marcelo bagnulo braun wrote: > Hi Jun, >=20 > sorry for the delay, i was away for a few days. >=20 > Ok, let me rephrase my question then. >=20 > Suppose that you have the topology that is depicted below, > with multiple redundant switches to benefit from robustness. > My point is that the introduction of SAVI that is unable to > cope with data packets for which there is no binding will > reduce the robustness of the network, even if network > has been designed to be redundant. >=20 > In the case SAVI is being deployed in a switched Ethernet network, > failures in a single device changes may result in a SAVI device > receiving packets from a > legitimate user for which the SAVI device does not have a binding > for. Consider the following example: >=20 >=20 >=20 > +------+ +--------+ +---------------+ > |SAVI I|-------------|SWITCH I|-------|rest of the net| > +------+ +--------+ +---------------+ > | | > | +--------+ > | | SAVI II| > | +--------+ > | +----------+ | > +---|SWITCH II |-----+ > +----------+ > | > +-----+ > | Host| > +-----+ >=20 >=20 > The DHCP server is located in the part called rest of the network. > Suppose that after bootstrapping all the elements are working > properly and the spanning tree is rooted in the router and it > includes one branch that goes SWITCH I-SAVI I- SWITCH II and another > branch that goes SWITCH I-SAVI II. >=20 > Suppose that the Host boots at this moment and perfomrs the DHCP = sxchange. > The message is propagated through the spanning tree and it received > by SAVI I but not by SAVI II. Same happens with the reply. > SAVI I creates the binding. >=20 > Suppose that SAVI I fails and the spanning tree reconverges to = SWITCH > I- SAVI II- SWITCH II. Now data packets coming from the Host will = be > coursed through SAVI II which does not have binding state and will > drop the packets. >=20 > Comments? >=20 > Regards, marcelo >=20 >=20 >=20 > El 09/03/10 11:47, Bi Jun escribi=F3: >> Hi Marcelo, >>=20 >> Since you are entitled "topology change", I want to say sth. >> Based on our operational experience, if we do a planed topology = change, >> then we have to plan we will have more serious problem than this. >> So topology change in an operational network is usually carefully = planed. >> We don't do it very often, and once we do it, we will let users = understand us. >>=20 >> So I don't see a problem of planed topology change. The only thing is = the power-down >> of a switch, which is really a low frequency event in an operational = network. If we found the power down, we will also inform users (only = users under that switch will be affected, not all users will be affect) = that if you had any problem thank you please renew your connection. >>=20 >> thanks, >> Jun Bi >>=20 >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Tuesday, March 09, 2010 3:51 PM >> To: "SAVI Mailing List" >> Subject: [savi] dealing with topology changes in dhcp savi >>=20 >>> Hi, >>>=20 >>> I have another question about dhcp save >>>=20 >>> How do you handle the following situation? >>>=20 >>> In the case SAVI is being deployed in a switched Ethernet network, >>> topology changes may result in a SAVI device receiving packets = from a >>> legitimate user for which the SAVI device does not have a binding >>> for. Consider the following example: >>>=20 >>>=20 >>>=20 >>> +------+ +--------+ +---------------+ >>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>> +------+ +--------+ +---------------+ >>> | | >>> | +--------+ >>> | | SAVI II| >>> | +--------+ >>> | +----------+ | >>> +---|SWITCH II |-----+ >>> +----------+ >>> | >>> +-----+ >>> | Host| >>> +-----+ >>>=20 >>>=20 >>> The DHCP server is located in the part called rest of the network. >>> Suppose that after bootstrapping all the elements are working >>> properly and the spanning tree is rooted in the router and it >>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and = another >>> branch that goes SWITCH I-SAVI II. >>>=20 >>> Suppose that the Host boots at this moment and perfomrs the DHCP = sxchange. >>> The message is propagated through the spanning tree and it = received >>> by SAVI I but not by SAVI II. Same happens with the reply. >>> SAVI I creates the binding. >>>=20 >>> Suppose that SAVI I fails and the spanning tree reconverges to = SWITCH >>> I- SAVI II- SWITCH II. Now data packets coming from the Host will = be >>> coursed through SAVI II which does not have binding state and will >>> drop the packets. >>>=20 >>> Regards, marcelo >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>>=20 >>=20 >=20 > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi http://www.ipinc.net/IPv4.GIF From elevyabe@cisco.com Tue Mar 16 05:28:27 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAAF33A6A47 for ; Tue, 16 Mar 2010 05:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.013 X-Spam-Level: X-Spam-Status: No, score=-8.013 tagged_above=-999 required=5 tests=[AWL=2.586, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEA11Kg4O7+1 for ; Tue, 16 Mar 2010 05:28:26 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1A1C83A6907 for ; Tue, 16 Mar 2010 05:28:25 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4BAPIVn0uQ/uCWe2dsb2JhbACafhUBAQsLJAYcoBeYbYR8BA X-IronPort-AV: E=Sophos;i="4.49,650,1262563200"; d="scan'208";a="58121369" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 16 Mar 2010 12:28:33 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2GCSXPm023840; Tue, 16 Mar 2010 12:28:33 GMT Received: from xmb-ams-105.cisco.com ([144.254.74.80]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 13:28:33 +0100 Received: from [144.254.53.100] ([144.254.53.100]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 13:28:32 +0100 Message-ID: <4B9F7970.5060808@cisco.com> Date: Tue, 16 Mar 2010 13:28:32 +0100 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: marcelo bagnulo braun References: <09741A6EA86846049A114B745EE24C37@junbiVAIO> <4B9E2ECD.7080504@cisco.com> <000a01cac445$5b2465e0$116d31a0$@tsinghua.edu.cn> <4B9E407C.8000303@cisco.com> <4B9E6494.4000807@it.uc3m.es> <4B9E6F1E.7010901@cisco.com> <4B9E6FE4.6080402@it.uc3m.es> In-Reply-To: <4B9E6FE4.6080402@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Mar 2010 12:28:32.0899 (UTC) FILETIME=[312C0530:01CAC504] Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02 draft X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 12:28:27 -0000 marcelo bagnulo braun a écrit : > El 15/03/10 18:32, Eric Levy-Abegnoli escribió: >> marcelo bagnulo braun a écrit : >>> El 15/03/10 15:13, Eric Levy-Abegnoli escribió: >>>> Hi Guang, >>>> >>>> Guang Yao a écrit : >>>>> Hi Eric, >>>>> >>>>> Thanks for your suggestion. Your experience is very valuable. >>>>> >>>>> In this solution, sending DHCP lease query is optional, just to >>>>> handle some >>>>> special cases (in general, data triggered but rather control >>>>> packet). It is >>>>> not required to be enabled. Vendors may choose to implement it on >>>>> layer 3 >>>>> device but not pure layer 2 device. And network administrators may >>>>> not >>>>> enable this function if they find the device may be overloaded. >>>>> >>>>> If binding is learnt from NDP, IMO it should be bound in >>>>> savi-slaac, but not >>>>> in this solution for DHCP. And the which to prefer in case of >>>>> co-existing of >>>>> NDP and DHCP, I think should be specified in the framework doc. Am >>>>> I right? >>>>> >>>>> BR, >>>>> Guang >>>> What I meant is that the proposed method (sending a leasequery to >>>> re-discover a binding lost in case of the switch reboot) cannot be >>>> used as a "general" response to the problem raised. A switch, >>>> L2-only device, that looses its binding table and has no >>>> non-volatile memory has just no way to recover it thru DHCP. It's >>>> is unfortunate since DHCP is considered as the only authoritative >>>> method for discovering bindings. >>>> I would consider that at the stage, when DHCP is used, non-volatile >>>> memory is the only option. >>> >>> How do you deal with the SAVI device not having state due to a >>> change in the topology due to an outage? >> You are describing a problem, not a solution. > right > >> Sounds like we have a problem without a solution then. Because >> discovering addresses from the switch by sourcing DHCP messages is >> not a viable solution. Might work in some cases. Will not in most. > could you expand on why it will not work? > > I am not sure i have understood it from your previous emails. Here is my concern. If "the" solution to the problem raised with (dhcp) savi-switch loosing its relies on generating a LEASEQUERY per rfc5007, then this solution requires: - the switch to act as a DHCP relay (and run a DHCP stack) - the switch to be configured with a L3 (IPv6) address on each of its vlan (need to source the DHCP messages) There are huge deployments out there where this is a showstopper. Many switches are pure L2, whether they don't have the L3 capability, or the operator don't want to pay the operation price overhead of enabling IP on each of the vlans (large switches can have thousands of vlans and enabling L3 have significant operation cost). I view this constrain on switches as a lot worse than constraining the topologie so that the backup switch sees (or is copied) the same traffic as the active and/or mandating non-volatile memory, depending on the cases. Eric > > Regards, marcelo > > >> >> Eric >>> >>> See the thread called " the impact of SAVI in the overall network >>> robustness" for the details >>> >>> Regards, marcelo >>> >>> >>> >>> >>>> Eric >>>>>> -----Original Message----- >>>>>> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On >>>>>> Behalf Of >>>>> Eric >>>>>> Levy-Abegnoli >>>>>> Sent: Monday, March 15, 2010 8:58 PM >>>>>> To: Bi Jun >>>>>> Cc: SAVI Mailing List >>>>>> Subject: Re: [savi] savi-dhcp-02 draft >>>>>> >>>>>> Bi Jun a écrit : >>>>>>> Hi all, >>>>>>> >>>>>>> This is a revised version of savi-dhcp (revised based on the >>>>>>> discussion of dhcp-01 on the mailing-list in the past week), >>>>>>> basically, make the control packet-triggered functions as MUST (low >>>>>>> cost to be implemented in every switch), and have the >>>>>>> data-triggered >>>>>>> functions (more complex to be implemented) as optional for >>>>>>> higher-end >>>>>>> switches (to enable more flexible use of savi device). >>>>>>> >>>>>>> We are consulting the vendors on the cost for those options. >>>>>>> >>>>>>> please give us your comments. >>>>>>> >>>>>>> thanks, >>>>>>> Jun Bi SAVI >>>>>> J. >>>>>>> Bi, J. Wu >>>>>> Hi Jun bi, >>>>>> Reading the below: >>>>>> >>>>>> "IPv6 address: >>>>>> Send a LEASEQUERY [RFC5007] message querying by IP address to >>>>>> All_DHCP_Relay_Agents_and_Servers multicast address or a >>>>>> configured server address. If no successful >>>>>> LEASEQUERY-REPLY is >>>>>> received, discard the packet; otherwise generate a new binding >>>>>> entry for the address. The SAVI device may repeat this >>>>>> process if >>>>>> a LEASEQUERY-REPLY with OPTION_CLIENT_LINK is received, in >>>>>> order >>>>>> to set up binding entries for all the address of the client." >>>>>> >>>>>> I don't think the below proposal to discover IPv6 address from >>>>>> the savi >>>>>> device works. DHCP messages must be sourced with an IPv6 address >>>>>> (can't >>>>>> be UNSPEC, must be a link-local) and in most cases, the switch >>>>>> does not >>>>>> have any. That would take the switch to have a L3 interface that >>>>>> participate in the link operations (for each of its vlans), and >>>>>> that is >>>>>> a huge constrain. >>>>>> I have real deployment examples of pure L2 switch devices with >>>>>> thousands >>>>>> of vlans configured (hundreds of ports in each vlan). Getting a L3 >>>>>> address in each vlan would have a huge impact on the switch >>>>>> operations >>>>>> and performances.That does not seem acceptable. >>>>>> I think the only option is to discover the binding by probing >>>>>> with a NDP >>>>>> DAD NS. This one is sourced with UNSPEC and hence is accpetable >>>>>> for a L2 >>>>>> device. Then install the binding as learnt from NDP. And later, >>>>>> "prefer" the DHCP binding when/if it shows up. >>>>>> Eric >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> >> > > From elevyabe@cisco.com Tue Mar 16 06:03:17 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C761D3A6907 for ; Tue, 16 Mar 2010 06:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.444 X-Spam-Level: X-Spam-Status: No, score=-4.444 tagged_above=-999 required=5 tests=[AWL=-1.845, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dF3Iv2+tKrP0 for ; Tue, 16 Mar 2010 06:03:16 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id A62D43A69AD for ; Tue, 16 Mar 2010 06:03:10 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4BAPUdn0uQ/uCWe2dsb2JhbACafhUBAQsLJAYcoEmYb4R8BA X-IronPort-AV: E=Sophos;i="4.49,650,1262563200"; d="scan'208";a="4398195" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 16 Mar 2010 12:29:39 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2GD3HES006590; Tue, 16 Mar 2010 13:03:18 GMT Received: from xmb-ams-105.cisco.com ([144.254.74.80]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 14:03:17 +0100 Received: from [144.254.53.100] ([144.254.53.100]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 14:03:17 +0100 Message-ID: <4B9F8194.4070105@cisco.com> Date: Tue, 16 Mar 2010 14:03:16 +0100 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es><4B9E1BF3.9080709@it.uc3m.es><231D9821F3704A09BCB0B166137AA034@junbiVAIO><4B9E3D5C.6040600@it.uc3m.es><876F7DBECC2348C695021E77315654F0@junbiVAIO> <4B9E4E84.1090003@it.uc3m.es> <0F84A919BFA04A5CB05C6010251A11B3@junbiVAIO> <4B9E586D.9070800@it.uc3m.es> In-Reply-To: <4B9E586D.9070800@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Mar 2010 13:03:17.0475 (UTC) FILETIME=[0BAD1330:01CAC509] Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 13:03:17 -0000 Hi Marcelo, marcelo bagnulo braun a écrit : > El 15/03/10 16:27, Jun Bi escribió: >> >> >> -------------------------------------------------- >> From: "marcelo bagnulo braun" >> Sent: Monday, March 15, 2010 11:13 PM >> To: "Bi Jun" >> Cc: >> Subject: Re: [savi] savi-dhcp-02 >> >>> Hi Jun, >>> >>> What i am talking about is how the deployment of the different SAVI >>> solution will affect the overall robustness and performance of the >>> Internet architecture. One of the tasks of the IETF and of the IAB >>> is to preserve the overall Internet architecture and to keep its >>> fundamental design principles that have granted a robust Internet. >>> >>> My concern is that a SAVI solution that blindly drops data packets >>> for which it has no binding for woudl deter the reliability of the >>> network as a whole and we shouldn't allow that. >>> >>> So, that being said, let me comment on som particular comments you >>> make. >>> >>> Below... >>> >>> El 15/03/10 15:48, Bi Jun escribió: >>>> Hi Marcelo, >>>> >>>> Hi, Marcelo, >>>> >>>> Here we are actually talking about the trade-off between cost and >>>> the benefits (forgive me that I explained this option many times). >>>> If the solution is just a couple of lines of code, whey not we make >>>> it MUST? But the truth is that the data-triggered actions are heavy >>>> burden to device especially low end access switch. If you make them >>>> MUST, then you forbid those access switches implementing SAVI >>>> (those access switch could be more than 90% of potential >>>> savi-switches). >>>> >>> Where did you get this figure from? >>> The feedback that i have got form vendors is that they would be able >>> to implement it as long as it is rate limited. >> >> >> > > > >> Oh really? Please provide me who said that. > > could you please tell the vendors who are not able to implement the > triggering of the binding creation upon the reception of data packets > to tell so in the ml, as you stated earlier? > > once that happens, i will talk to the vendors who did told me that to > speak up in the ml as well. As a vendor, I'll tell one issue that we have with "triggering of the binding creation upon the reception of data packets" which I would translate into "punting" data packets to software. On bigger switches, data traffic is hardware bridged. The binding table is pushed to the hardware (to avoid slowing down the switch). The rate-limiting must happen close to the hardware to drop quickly enough in case of attack. In order to be efficient (simple & fast) and generic, the rate-limiters classify the traffic and rate limit based on this classification. For instance ICMP traffic can be classified as "ICMP" and rate-limited accordingly. However, the data traffic we are talking about cannot be classified (could be anything). There are two issues with that. 1) We need to add specific logic to rate limit cache misses before punting to software. Can't use generic rate-limiters. This is an additional logic (on top of generic rate-limiters) which is going to have a performance hit 2) This might require some hardware change, which takes time, energy and money. BTW, please I am not asking for somebody to invent whatever design to resolve my problem. I know exactly what to do. But as a vendor, I am saying this is **not** a couple of lines of code. It might be un-avoidable, I am not arguying. I wish we could come up with a different solution. Right now the charter constrain us to keep not invent a new protocol, and this is turning into changing the hardware ... Eric > > Regards, marcelo From marcelo@it.uc3m.es Tue Mar 16 06:57:11 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72913A6929 for ; Tue, 16 Mar 2010 06:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epY6mNvWX5IB for ; Tue, 16 Mar 2010 06:57:10 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 398983A67A4 for ; Tue, 16 Mar 2010 06:57:08 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id B6D347F70DA; Tue, 16 Mar 2010 14:57:13 +0100 (CET) Message-ID: <4B9F8E39.2070605@it.uc3m.es> Date: Tue, 16 Mar 2010 14:57:13 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Eric Levy-Abegnoli References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es><4B9E1BF3.9080709@it.uc3m.es><231D9821F3704A09BCB0B166137AA034@junbiVAIO><4B9E3D5C.6040600@it.uc3m.es><876F7DBECC2348C695021E77315654F0@junbiVAIO> <4B9E4E84.1090003@it.uc3m.es> <0F84A919BFA04A5CB05C6010251A11B3@junbiVAIO> <4B9E586D.9070800@it.uc3m.es> <4B9F8194.4070105@cisco.com> In-Reply-To: <4B9F8194.4070105@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 13:57:11 -0000 El 16/03/10 14:03, Eric Levy-Abegnoli escribió: > > It might be un-avoidable, I am not arguying. I wish we could come up > with a different solution. > Right now the charter constrain us to keep not invent a new protocol, How would a new protocol solve the problem? Regards, marcelo > and this is turning into changing the hardware ... > Eric > >> >> Regards, marcelo > > From elevyabe@cisco.com Tue Mar 16 08:04:12 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CFB83A6879 for ; Tue, 16 Mar 2010 08:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.181 X-Spam-Level: X-Spam-Status: No, score=-8.181 tagged_above=-999 required=5 tests=[AWL=2.418, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJ4cEjmnOACZ for ; Tue, 16 Mar 2010 08:04:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B7D793A687F for ; Tue, 16 Mar 2010 08:04:01 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugAAFU6n0uQ/uCWe2dsb2JhbACbBBUBAQsLJAYcoVOYeIR4BA X-IronPort-AV: E=Sophos;i="4.49,650,1262563200"; d="scan'208";a="58130907" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 16 Mar 2010 15:04:09 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2GF49PU012816; Tue, 16 Mar 2010 15:04:09 GMT Received: from xmb-ams-105.cisco.com ([144.254.74.80]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 16:04:09 +0100 Received: from [144.254.53.100] ([144.254.53.100]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 16:04:08 +0100 Message-ID: <4B9F9DE7.1030104@cisco.com> Date: Tue, 16 Mar 2010 16:04:07 +0100 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es><4B9E1BF3.9080709@it.uc3m.es><231D9821F3704A09BCB0B166137AA034@junbiVAIO><4B9E3D5C.6040600@it.uc3m.es><876F7DBECC2348C695021E77315654F0@junbiVAIO> <4B9E4E84.1090003@it.uc3m.es> <0F84A919BFA04A5CB05C6010251A11B3@junbiVAIO> <4B9E586D.9070800@it.uc3m.es> <4B9F8194.4070105@cisco.com> <4B9F8E39.2070605@it.uc3m.es> In-Reply-To: <4B9F8E39.2070605@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Mar 2010 15:04:08.0851 (UTC) FILETIME=[EDD53E30:01CAC519] Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 15:04:12 -0000 marcelo bagnulo braun a écrit : > El 16/03/10 14:03, Eric Levy-Abegnoli escribió: >> >> It might be un-avoidable, I am not arguying. I wish we could come up >> with a different solution. >> Right now the charter constrain us to keep not invent a new protocol, > > How would a new protocol solve the problem? A protocol that would allow nodes to "register" their address and the switch to query them. Something like RFC3122 (applied to ethernet links, see draft-thubert-3122bis-01 ) or like Erik N. draft (see draft-nordmark-6lowpan-reg-00 ). If we had a reliable mechanism by which the switch could discover bindings, then we would not have to snoop, and would not be exposed to snoop failures. This is excluded by the charter, so I am not arguying about considering these. However, on the longer term, I'd be interrested in exploring more robust solutions ... Eric > > Regards, marcelo > > > >> and this is turning into changing the hardware ... >> Eric >> >>> >>> Regards, marcelo >> >> > > From elevyabe@cisco.com Tue Mar 16 08:18:19 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91493A695F for ; Tue, 16 Mar 2010 08:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.483 X-Spam-Level: X-Spam-Status: No, score=-8.483 tagged_above=-999 required=5 tests=[AWL=2.116, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkG9E-Q63LP8 for ; Tue, 16 Mar 2010 08:18:18 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B3AC63A6B50 for ; Tue, 16 Mar 2010 08:18:18 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJQ9n0urR7Hu/2dsb2JhbACbBHOhVJh6hHgEjkU X-IronPort-AV: E=Sophos;i="4.49,650,1262563200"; d="scan'208";a="167022238" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 16 Mar 2010 15:18:27 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2GFILqh023022; Tue, 16 Mar 2010 15:18:27 GMT Received: from xmb-ams-105.cisco.com ([144.254.74.80]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 16:18:23 +0100 Received: from [144.254.53.100] ([144.254.53.100]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 16:18:22 +0100 Message-ID: <4B9FA13E.3050801@cisco.com> Date: Tue, 16 Mar 2010 16:18:22 +0100 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Guang Yao References: <09741A6EA86846049A114B745EE24C37@junbiVAIO> <4B9E2ECD.7080504@cisco.com> <000a01cac445$5b2465e0$116d31a0$@tsinghua.edu.cn> <4B9E407C.8000303@cisco.com> <001701cac44c$bd4e14d0$37ea3e70$@tsinghua.edu.cn> In-Reply-To: <001701cac44c$bd4e14d0$37ea3e70$@tsinghua.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Mar 2010 15:18:22.0997 (UTC) FILETIME=[EAF19450:01CAC51B] Cc: 'SAVI Mailing List' Subject: Re: [savi] savi-dhcp-02 draft X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 15:18:19 -0000 Hi Guang, I have a questions regarding both the current draft and this discussion. 1) When you learn a binding by snooping DHCP REQUEST/REPLY, you read the client IP address out of the IADDR option, right? Where do you get the MAC address from in case it is the anchor? Is it the SMAC of the request? The DMAC of the server response? Or is it the DUID in the clientID option? 2)When a switch is trying to retrieve bindings that it _never_ knew, per the topo changes discussion, it goes to the server with a LEASEQUERY. Get back an Address and a ClientID (carrying a DUID). No port, right? So in case the anchor is the port, where is it learning the port from in this scenario? 3) The DUID carried in the ClientID is _not_ always the SMAC that the client will use to source packets for the IP address requested. If you disagree with that, I can develop ... So whether in 1) or 2) this cannot be used. For 1) we can always use the SMAC of the request (of DMAC of the response). For 2), what else do we have? Thanks for clarifying all these points. Eric Guang Yao a écrit : > Hi Eric, > > The method that save bindings in non volatile memory is described in section > 21. Thanks for your previous suggestion. > > The data triggered dhcp lease query is not used to restore previous > bindings, but to set up bindings the device _never_ gets known. The > scenarios include movement on local link, and layer 2 topo changes, as > discussed recently. > > BR, > Guang > > >> -----Original Message----- >> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of >> > Eric > >> Levy-Abegnoli >> Sent: Monday, March 15, 2010 10:13 PM >> To: Guang Yao >> Cc: 'SAVI Mailing List' >> Subject: Re: [savi] savi-dhcp-02 draft >> >> Hi Guang, >> >> Guang Yao a écrit : >> >>> Hi Eric, >>> >>> Thanks for your suggestion. Your experience is very valuable. >>> >>> In this solution, sending DHCP lease query is optional, just to handle >>> > some > >>> special cases (in general, data triggered but rather control packet). It >>> > is > >>> not required to be enabled. Vendors may choose to implement it on layer >>> > 3 > >>> device but not pure layer 2 device. And network administrators may not >>> enable this function if they find the device may be overloaded. >>> >>> If binding is learnt from NDP, IMO it should be bound in savi-slaac, but >>> > not > >>> in this solution for DHCP. And the which to prefer in case of >>> > co-existing of > >>> NDP and DHCP, I think should be specified in the framework doc. Am I >>> > right? > >>> BR, >>> Guang >>> >>> >> What I meant is that the proposed method (sending a leasequery to >> re-discover a binding lost in case of the switch reboot) cannot be used >> as a "general" response to the problem raised. A switch, L2-only device, >> that looses its binding table and has no non-volatile memory has just no >> way to recover it thru DHCP. It's is unfortunate since DHCP is >> considered as the only authoritative method for discovering bindings. >> I would consider that at the stage, when DHCP is used, non-volatile >> memory is the only option. >> Eric >> >>>> -----Original Message----- >>>> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of >>>> >>>> >>> Eric >>> >>> >>>> Levy-Abegnoli >>>> Sent: Monday, March 15, 2010 8:58 PM >>>> To: Bi Jun >>>> Cc: SAVI Mailing List >>>> Subject: Re: [savi] savi-dhcp-02 draft >>>> >>>> Bi Jun a écrit : >>>> >>>> >>>>> Hi all, >>>>> >>>>> This is a revised version of savi-dhcp (revised based on the >>>>> discussion of dhcp-01 on the mailing-list in the past week), >>>>> basically, make the control packet-triggered functions as MUST (low >>>>> cost to be implemented in every switch), and have the data-triggered >>>>> functions (more complex to be implemented) as optional for higher-end >>>>> switches (to enable more flexible use of savi device). >>>>> >>>>> We are consulting the vendors on the cost for those options. >>>>> >>>>> please give us your comments. >>>>> >>>>> thanks, >>>>> Jun Bi SAVI >>>>> >>>>> >>>> J. >>>> >>>> >>>>> Bi, J. Wu >>>>> >>>>> >>>> Hi Jun bi, >>>> Reading the below: >>>> >>>> "IPv6 address: >>>> Send a LEASEQUERY [RFC5007] message querying by IP address to >>>> All_DHCP_Relay_Agents_and_Servers multicast address or a >>>> configured server address. If no successful LEASEQUERY-REPLY is >>>> received, discard the packet; otherwise generate a new binding >>>> entry for the address. The SAVI device may repeat this process if >>>> a LEASEQUERY-REPLY with OPTION_CLIENT_LINK is received, in >>>> >> order >> >>>> to set up binding entries for all the address of the client." >>>> >>>> I don't think the below proposal to discover IPv6 address from the savi >>>> device works. DHCP messages must be sourced with an IPv6 address >>>> >> (can't >> >>>> be UNSPEC, must be a link-local) and in most cases, the switch does not >>>> have any. That would take the switch to have a L3 interface that >>>> participate in the link operations (for each of its vlans), and that is >>>> a huge constrain. >>>> I have real deployment examples of pure L2 switch devices with >>>> > thousands > >>>> of vlans configured (hundreds of ports in each vlan). Getting a L3 >>>> address in each vlan would have a huge impact on the switch operations >>>> and performances.That does not seem acceptable. >>>> I think the only option is to discover the binding by probing with a >>>> > NDP > >>>> DAD NS. This one is sourced with UNSPEC and hence is accpetable for a >>>> > L2 > >>>> device. Then install the binding as learnt from NDP. And later, >>>> "prefer" the DHCP binding when/if it shows up. >>>> Eric >>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>>> >>> >>> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > From marcelo@it.uc3m.es Tue Mar 16 09:28:26 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24053A6BC1 for ; Tue, 16 Mar 2010 09:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qvab6YQbFNji for ; Tue, 16 Mar 2010 09:28:24 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id A2DC93A6B95 for ; Tue, 16 Mar 2010 09:28:22 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 9F5657F814F; Tue, 16 Mar 2010 17:28:29 +0100 (CET) Message-ID: <4B9FB1AD.7050906@it.uc3m.es> Date: Tue, 16 Mar 2010 17:28:29 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Fred Baker References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> <6F4B5FA5-2EAE-4435-A06B-4B5A8E083DF6@cisco.com> In-Reply-To: <6F4B5FA5-2EAE-4435-A06B-4B5A8E083DF6@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 16:28:26 -0000 Hi Fred, El 16/03/10 11:57, Fred Baker escribió: > If this is the lack of robustness you're talking about, This is one of the cases of reduced robustness, the other is the usage of stalled information (but can be dealt with the same approach as this one that you mention below) > then I would have to agree with Jun that having the switch re-check the DHCP binding with the DHCP server gets it the information it needs. So, you mean that upon the reception of a packet for which the dhcp SAVI device has no binding, the dhcp savi device must retrieve the binding information from the dhcp server (in case there is one)? I agree that that would address the issue and would imply a lost of packets that is negligible. regards, marcelo > It drops packets for a period measured in hundreds to thousands of milliseconds while the situation is sorted out, but I doubt you would see a TCP session loss from this alone. > > I'm afraid we don't see your concerns in the field. > > On Mar 15, 2010, at 8:09 AM, marcelo bagnulo braun wrote: > > >> Hi Jun, >> >> sorry for the delay, i was away for a few days. >> >> Ok, let me rephrase my question then. >> >> Suppose that you have the topology that is depicted below, >> with multiple redundant switches to benefit from robustness. >> My point is that the introduction of SAVI that is unable to >> cope with data packets for which there is no binding will >> reduce the robustness of the network, even if network >> has been designed to be redundant. >> >> In the case SAVI is being deployed in a switched Ethernet network, >> failures in a single device changes may result in a SAVI device >> receiving packets from a >> legitimate user for which the SAVI device does not have a binding >> for. Consider the following example: >> >> >> >> +------+ +--------+ +---------------+ >> |SAVI I|-------------|SWITCH I|-------|rest of the net| >> +------+ +--------+ +---------------+ >> | | >> | +--------+ >> | | SAVI II| >> | +--------+ >> | +----------+ | >> +---|SWITCH II |-----+ >> +----------+ >> | >> +-----+ >> | Host| >> +-----+ >> >> >> The DHCP server is located in the part called rest of the network. >> Suppose that after bootstrapping all the elements are working >> properly and the spanning tree is rooted in the router and it >> includes one branch that goes SWITCH I-SAVI I- SWITCH II and another >> branch that goes SWITCH I-SAVI II. >> >> Suppose that the Host boots at this moment and perfomrs the DHCP sxchange. >> The message is propagated through the spanning tree and it received >> by SAVI I but not by SAVI II. Same happens with the reply. >> SAVI I creates the binding. >> >> Suppose that SAVI I fails and the spanning tree reconverges to SWITCH >> I- SAVI II- SWITCH II. Now data packets coming from the Host will be >> coursed through SAVI II which does not have binding state and will >> drop the packets. >> >> Comments? >> >> Regards, marcelo >> >> >> >> El 09/03/10 11:47, Bi Jun escribió: >> >>> Hi Marcelo, >>> >>> Since you are entitled "topology change", I want to say sth. >>> Based on our operational experience, if we do a planed topology change, >>> then we have to plan we will have more serious problem than this. >>> So topology change in an operational network is usually carefully planed. >>> We don't do it very often, and once we do it, we will let users understand us. >>> >>> So I don't see a problem of planed topology change. The only thing is the power-down >>> of a switch, which is really a low frequency event in an operational network. If we found the power down, we will also inform users (only users under that switch will be affected, not all users will be affect) that if you had any problem thank you please renew your connection. >>> >>> thanks, >>> Jun Bi >>> >>> -------------------------------------------------- >>> From: "marcelo bagnulo braun" >>> Sent: Tuesday, March 09, 2010 3:51 PM >>> To: "SAVI Mailing List" >>> Subject: [savi] dealing with topology changes in dhcp savi >>> >>> >>>> Hi, >>>> >>>> I have another question about dhcp save >>>> >>>> How do you handle the following situation? >>>> >>>> In the case SAVI is being deployed in a switched Ethernet network, >>>> topology changes may result in a SAVI device receiving packets from a >>>> legitimate user for which the SAVI device does not have a binding >>>> for. Consider the following example: >>>> >>>> >>>> >>>> +------+ +--------+ +---------------+ >>>> |SAVI I|-------------|SWITCH I|-------|rest of the net| >>>> +------+ +--------+ +---------------+ >>>> | | >>>> | +--------+ >>>> | | SAVI II| >>>> | +--------+ >>>> | +----------+ | >>>> +---|SWITCH II |-----+ >>>> +----------+ >>>> | >>>> +-----+ >>>> | Host| >>>> +-----+ >>>> >>>> >>>> The DHCP server is located in the part called rest of the network. >>>> Suppose that after bootstrapping all the elements are working >>>> properly and the spanning tree is rooted in the router and it >>>> includes one branch that goes SWITCH I-SAVI I- SWITCH II and another >>>> branch that goes SWITCH I-SAVI II. >>>> >>>> Suppose that the Host boots at this moment and perfomrs the DHCP sxchange. >>>> The message is propagated through the spanning tree and it received >>>> by SAVI I but not by SAVI II. Same happens with the reply. >>>> SAVI I creates the binding. >>>> >>>> Suppose that SAVI I fails and the spanning tree reconverges to SWITCH >>>> I- SAVI II- SWITCH II. Now data packets coming from the Host will be >>>> coursed through SAVI II which does not have binding state and will >>>> drop the packets. >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>>> >>> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > http://www.ipinc.net/IPv4.GIF > > > From fred@cisco.com Tue Mar 16 10:29:51 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C58D3A67A8 for ; Tue, 16 Mar 2010 10:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.329 X-Spam-Level: X-Spam-Status: No, score=-110.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad-x554EjEuk for ; Tue, 16 Mar 2010 10:29:50 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0C96D3A684A for ; Tue, 16 Mar 2010 10:29:38 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADJdn0tAZnwN/2dsb2JhbACbBnOgfZh9hHgEgxo X-IronPort-AV: E=Sophos;i="4.49,651,1262563200"; d="scan'208";a="93413518" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Mar 2010 17:29:47 +0000 Received: from [10.149.3.205] (rtp-vpn2-1660.cisco.com [10.82.246.126]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2GHTlV5008130; Tue, 16 Mar 2010 17:29:47 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4B9FB1AD.7050906@it.uc3m.es> Date: Tue, 16 Mar 2010 12:29:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <135C8103-7FF2-45EB-837E-FAEA84FC0308@cisco.com> References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> <6F4B5FA5-2EAE-4435-A06B-4B5A8E083DF6@cisco.com> <4B9FB1AD.7050906@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1077) Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 17:29:51 -0000 On Mar 16, 2010, at 11:28 AM, marcelo bagnulo braun wrote: > So, you mean that upon the reception of a packet for which the dhcp = SAVI device has no binding, the dhcp savi device must retrieve the = binding information from the dhcp server (in case there is one)? If we're talking about a switch in a transit configuration - a switch = that the host in question is not directly connected to - I see no reason = to assume that the switch is protecting that host. It could be = configured to (eg the case of a major switch connected to a non-SAVI = desktop switch), but even there it would be preferable for the desktop = switch to protect its own ports.=20 If we're talking about a switch protecting its own ports, yes, it needs = to somehow get the information restored. One way to do so would be to = send a DHCP request to the server as if from the host in question.= From marcelo@it.uc3m.es Tue Mar 16 12:17:05 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F9473A69CD for ; Tue, 16 Mar 2010 12:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfeEIKqH9rmM for ; Tue, 16 Mar 2010 12:17:04 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id A4F253A69A5 for ; Tue, 16 Mar 2010 12:16:56 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (154.31.18.95.dynamic.jazztel.es [95.18.31.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 34A037F814F; Tue, 16 Mar 2010 20:17:03 +0100 (CET) Message-ID: <4B9FD92E.50707@it.uc3m.es> Date: Tue, 16 Mar 2010 20:17:02 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Fred Baker References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> <6F4B5FA5-2EAE-4435-A06B-4B5A8E083DF6@cisco.com> <4B9FB1AD.7050906@it.uc3m.es> <135C8103-7FF2-45EB-837E-FAEA84FC0308@cisco.com> In-Reply-To: <135C8103-7FF2-45EB-837E-FAEA84FC0308@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 19:17:05 -0000 El 16/03/10 18:29, Fred Baker escribió: > On Mar 16, 2010, at 11:28 AM, marcelo bagnulo braun wrote: > > >> So, you mean that upon the reception of a packet for which the dhcp SAVI device has no binding, the dhcp savi device must retrieve the binding information from the dhcp server (in case there is one)? >> > If we're talking about a switch in a transit configuration - a switch that the host in question is not directly connected to - I see no reason to assume that the switch is protecting that host. It could be configured to (eg the case of a major switch connected to a non-SAVI desktop switch), but even there it would be preferable for the desktop switch to protect its own ports. > > I am not sure i understand the terminology. So, as they say, one picture... I am talking about this configuration +---------------+ |Rest of the net| +---------------+ | +------+ |SAVI | +------+ | +-------------+ |Legacy switch| +-------------+ | +------+ |host | +------+ In this case, the SAVI is enforcing that the addresses used by the host come from the port through which the legacy switch is connected to. The problem is when the savi switch looses its state and start discarding the packets from the host after that The solution i understand you describe (making the SAVI device to query the dhcp server upon the reception of a data packet for which it has no binding) would address this problem and solve the robustness concerns Are we talking about the same thing? Regards, marcelo > If we're talking about a switch protecting its own ports, yes, it needs to somehow get the information restored. One way to do so would be to send a DHCP request to the server as if from the host in question. > From fred@cisco.com Tue Mar 16 13:01:06 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76EF83A69AE for ; Tue, 16 Mar 2010 13:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.406 X-Spam-Level: X-Spam-Status: No, score=-110.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOs3RWKk6-3u for ; Tue, 16 Mar 2010 13:01:05 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E021B3A699F for ; Tue, 16 Mar 2010 13:01:04 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFqAn0tAZnwN/2dsb2JhbACbBHOgJZh5hHgE X-IronPort-AV: E=Sophos;i="4.49,652,1262563200"; d="scan'208";a="93460656" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Mar 2010 20:01:09 +0000 Received: from [10.149.3.175] (rtp-vpn2-1455.cisco.com [10.82.245.176]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2GK18AK025047; Tue, 16 Mar 2010 20:01:08 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Fred Baker In-Reply-To: <4B9FD92E.50707@it.uc3m.es> Date: Tue, 16 Mar 2010 16:01:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <16F79ABE-AEEB-4328-B354-EFD821090352@cisco.com> References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> <6F4B5FA5-2EAE-4435-A06B-4B5A8E083DF6@cisco.com> <4B9FB1AD.7050906@it.uc3m.es> <135C8103-7FF2-45EB-837E-FAEA84FC0308@cisco.com> <4B9FD92E.50707@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1077) Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 20:01:06 -0000 On Mar 16, 2010, at 3:17 PM, marcelo bagnulo braun wrote: > El 16/03/10 18:29, Fred Baker escribi=F3: >> On Mar 16, 2010, at 11:28 AM, marcelo bagnulo braun wrote: >>=20 >> =20 >>> So, you mean that upon the reception of a packet for which the dhcp = SAVI device has no binding, the dhcp savi device must retrieve the = binding information from the dhcp server (in case there is one)? >>> =20 >> If we're talking about a switch in a transit configuration - a switch = that the host in question is not directly connected to - I see no reason = to assume that the switch is protecting that host. It could be = configured to (eg the case of a major switch connected to a non-SAVI = desktop switch), but even there it would be preferable for the desktop = switch to protect its own ports. >>=20 >> =20 > I am not sure i understand the terminology. >=20 > So, as they say, one picture... >=20 > I am talking about this configuration >=20 > +---------------+ > |Rest of the net| > +---------------+ > | > +------+ > |SAVI | > +------+ > | > +-------------+ > |Legacy switch| > +-------------+ > | > +------+ > |host | > +------+ >=20 > In this case, the SAVI is enforcing that the addresses used by the = host come from the port through which the legacy switch is connected to. > The problem is when the savi switch looses its state and start = discarding the packets from the host after that >=20 > The solution i understand you describe (making the SAVI device to = query the dhcp server upon the reception of a data packet for which it = has no binding) would address this problem and solve the robustness = concerns >=20 > Are we talking about the same thing? I imagine so. The legacy switch in this case is one of two things - a = desktop four or 8 port "port extension", which doesn't worry me much, or = a bazillion-port monster. In the latter case, I wouldn't automatically = assume that the SAVI switch had enough memory to protect its ports. As a = vendor, I would tell my customer that rather than adding an inter-switch = protocol and a ton of memory to the SAVI switch, they would do better if = they upgraded the legacy switch. > Regards, marcelo >=20 >> If we're talking about a switch protecting its own ports, yes, it = needs to somehow get the information restored. One way to do so would be = to send a DHCP request to the server as if from the host in question. >> =20 >=20 http://www.ipinc.net/IPv4.GIF From marcelo@it.uc3m.es Tue Mar 16 13:20:52 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5273A69EE for ; Tue, 16 Mar 2010 13:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZVWImxDBEA7 for ; Tue, 16 Mar 2010 13:20:47 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 8EAF33A6A43 for ; Tue, 16 Mar 2010 13:20:19 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (154.31.18.95.dynamic.jazztel.es [95.18.31.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 4A798BAB228; Tue, 16 Mar 2010 21:20:22 +0100 (CET) Message-ID: <4B9FE7F1.8090908@it.uc3m.es> Date: Tue, 16 Mar 2010 21:20:01 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Fred Baker References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> <6F4B5FA5-2EAE-4435-A06B-4B5A8E083DF6@cisco.com> <4B9FB1AD.7050906@it.uc3m.es> <135C8103-7FF2-45EB-837E-FAEA84FC0308@cisco.com> <4B9FD92E.50707@it.uc3m.es> <16F79ABE-AEEB-4328-B354-EFD821090352@cisco.com> In-Reply-To: <16F79ABE-AEEB-4328-B354-EFD821090352@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: SAVI Mailing List Subject: Re: [savi] the impact of SAVI in the overall network robustness (was Re: dealing with topology changes in dhcp savi X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 20:20:52 -0000 El 16/03/10 21:01, Fred Baker escribió: > On Mar 16, 2010, at 3:17 PM, marcelo bagnulo braun wrote: > > >> El 16/03/10 18:29, Fred Baker escribió: >> >>> On Mar 16, 2010, at 11:28 AM, marcelo bagnulo braun wrote: >>> >>> >>> >>>> So, you mean that upon the reception of a packet for which the dhcp SAVI device has no binding, the dhcp savi device must retrieve the binding information from the dhcp server (in case there is one)? >>>> >>>> >>> If we're talking about a switch in a transit configuration - a switch that the host in question is not directly connected to - I see no reason to assume that the switch is protecting that host. It could be configured to (eg the case of a major switch connected to a non-SAVI desktop switch), but even there it would be preferable for the desktop switch to protect its own ports. >>> >>> >>> >> I am not sure i understand the terminology. >> >> So, as they say, one picture... >> >> I am talking about this configuration >> >> +---------------+ >> |Rest of the net| >> +---------------+ >> | >> +------+ >> |SAVI | >> +------+ >> | >> +-------------+ >> |Legacy switch| >> +-------------+ >> | >> +------+ >> |host | >> +------+ >> >> In this case, the SAVI is enforcing that the addresses used by the host come from the port through which the legacy switch is connected to. >> The problem is when the savi switch looses its state and start discarding the packets from the host after that >> >> The solution i understand you describe (making the SAVI device to query the dhcp server upon the reception of a data packet for which it has no binding) would address this problem and solve the robustness concerns >> >> Are we talking about the same thing? >> > I imagine so. The legacy switch in this case is one of two things - a desktop four or 8 port "port extension", which doesn't worry me much, or a bazillion-port monster. In the latter case, I wouldn't automatically assume that the SAVI switch had enough memory to protect its ports. As a vendor, I would tell my customer that rather than adding an inter-switch protocol and a ton of memory to the SAVI switch, they would do better if they upgraded the legacy switch. > > makes perfect sense to me i do agree that the deployment considerations should make some referecne about the amount of devices that can be hanging from a SAVI device, as you mention (i am not very sure how to write that down, but i guess we will give it a try and see what happens) Regards, marcelo >> Regards, marcelo >> >> >>> If we're talking about a switch protecting its own ports, yes, it needs to somehow get the information restored. One way to do so would be to send a DHCP request to the server as if from the host in question. >>> >>> >> > http://www.ipinc.net/IPv4.GIF > > > From yaoa02@mails.tsinghua.edu.cn Wed Mar 17 01:56:01 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FA923A6919 for ; Wed, 17 Mar 2010 01:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.671 X-Spam-Level: * X-Spam-Status: No, score=1.671 tagged_above=-999 required=5 tests=[AWL=-1.581, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MIME_QP_LONG_LINE=1.396, SARE_SUB_PERFECT=0.725] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hczoAIP+BLkd for ; Wed, 17 Mar 2010 01:55:58 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 747E13A6849 for ; Wed, 17 Mar 2010 01:55:56 -0700 (PDT) Received: from tu132201.ip.tsinghua.edu.cn ([166.111.132.201] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1Nrp2i-0002GD-JV for savi@ietf.org; Wed, 17 Mar 2010 16:55:56 +0800 From: "Guang Yao" To: References: <4B95FDE7.8070100@it.uc3m.es> <4B9E2382.8000304@it.uc3m.es> <6F4B5FA5-2EAE-4435-A06B-4B5A8E083DF6@cisco.com> <4B9FB1AD.7050906@it.uc3m.es> <135C8103-7FF2-45EB-837E-FAEA84FC0308@cisco.com> <4B9FD92E.50707@it.uc3m.es> <16F79ABE-AEEB-4328-B354-EFD821090352@cisco.com> <4B9FE7F1.8090908@it.uc3m.es> In-Reply-To: <4B9FE7F1.8090908@it.uc3m.es> Date: Wed, 17 Mar 2010 16:55:46 +0800 Message-ID: <000b01cac5af$a23fcf80$e6bf6e80$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000C_01CAC5F2.B0630F80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrFRfLGsZYz95gUTOKdqRQE/piqJwAaPL4g Content-Language: zh-cn Subject: [savi] no perfect solution for stateless without reliable DAD? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 08:56:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01CAC5F2.B0630F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi folks, In stateless scenario, nodes can "assign" address to themselves, and perform unreliable duplicate detection to check whether the address is being used. For IPv6 address, collision happens with very little probability because of large address space, thus the unreliable nature of DAD is not serious in reality. However, the unreliability of DAD troubles source address validation. It is very hard, if not impossible, for a SAVI device to determine which node can use one address when conflict happens. A wise principle, "First Come First Served" is currently used by SAVI-FCFS to determine ownership of address. This principle is correct, however, the problem is, how to determine which node is the first to use an address. Because the unreliable nature of DAD, the first one assigned itself an address, may not be the one first using the address to send traffic sniffed by the SAVI device. SAVI-FCFS requires device to send detection probes to determine whether an address is being used by another node. However, this effort may be vain, because malicious node can reply any probe, and the probe is still unreliable to reach the possible target node. After a long time attempt, we finally find that because of the unreliability of DAD and ND, there is no perfect arbitration policy. In another word, if a arbitration policy is perfect, it must rely on a reliable DAD. We can prove this through a simple deduction: Perfect arbitrate=> The one having assigned itself an address first gets the ownership of the address=> The one having performed DAD first gets the address=> The arbitrator must know who is the first to perform DAD=> The DAD must be reliable to be sniffed by the SAVI device. And the deduction can be reversed. In the end, we found we were building tower on the quick sand. It concerns nothing about whether choosing data trigger or control packet trigger. Unless stateless assignment changes to be reliable, no solution can be secure. In the attached document, we decide to follow RFC4862, which is the only stand track on stateless address assignment. This means, if a node finishes a successful DAD, including the DAD is performed by SAVI device in case of data trigger, the address MUST be bound with it. Then the ownership conflict is actually handled through allowing one address to be bound with multiple anchors. The bindings are only removed when the lifetime expires, which equals prefix life time learned from RA. Then we achieve a simple solution, whose security is based on the reliability of RFC4862. (The doc in the attachment is not used to challenge current solution, but used to help discuss on this topic.) Thanks to any comment. BR, Guang ------=_NextPart_000_000C_01CAC5F2.B0630F80 Content-Type: text/plain; name="draft-bi-savi-stateless-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-bi-savi-stateless-00.txt" SAVI J. Bi=0A= Internet Draft CERNET=0A= Intended status: Standard Tracks G. Yao=0A= Expires: September 2010 Tsinghua Univ.=0A= J. Wu=0A= CERNET=0A= March 17, 2010=0A= =0A= =0A= =0A= SAVI Solution for Stateless Address=0A= draft-bi-savi-stateless-00.txt=0A= =0A= =0A= Status of this Memo=0A= =0A= This Internet-Draft is submitted to IETF in full conformance with the=0A= provisions of BCP 78 and BCP 79. This document may not be modified,=0A= and derivative works of it may not be created, except to publish it=0A= as an RFC and to translate it into languages other than English.=0A= =0A= This document may contain material from IETF Documents or IETF=0A= Contributions published or made publicly available before November 10,=0A= 2008. The person(s) controlling the copyright in some of this=0A= material may not have granted the IETF Trust the right to allow=0A= modifications of such material outside the IETF Standards Process.=0A= Without obtaining an adequate license from the person(s) controlling=0A= the copyright in such materials, this document may not be modified=0A= outside the IETF Standards Process, and derivative works of it may=0A= not be created outside the IETF Standards Process, except to format=0A= it for publication as an RFC or to translate it into languages other=0A= than English.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html=0A= =0A= =0A= =0A= =0A= Bi Expires September 17, 2010 [Page 1]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= This Internet-Draft will expire on September 17, 2010.=0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2010 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (http://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.=0A= =0A= Abstract=0A= =0A= This document specifies the procedure for creating bindings between a=0A= stateless address (including Stateless Autoconfiguration Address,=0A= manually configured non-static address, etc) and an anchor (refer to=0A= [SAVI-framework]) on SAVI (Source Address Validation Improvements)=0A= device. The bindings can be used to filter packets generated on the=0A= local link with forged IP addresses. Different from other proposed=0A= solution for stateless address (e.g., SAVI-FCFS), this solution=0A= follows RFC4862 to arbitrate the ownership of address. Data triggered=0A= procedure is designed, in which SAVI device performs Duplicate=0A= Address Detection instead of hosts and the ownership of address is=0A= also arbitrated based on RFC4862.=0A= =0A= Table of Contents=0A= =0A= =0A= Copyright Notice ............................................... 2=0A= Abstract ....................................................... 2=0A= 1. Introduction ................................................ 3=0A= 2. Conventions used in this document............................ 4=0A= 3. Mechanism Overview .......................................... 4=0A= 4. Basic Principle of Address Ownership Arbitration............. 4=0A= 5. Background and Related Protocols............................. 5=0A= 6. Terminology ................................................. 6=0A= 7. Conceptual Data Structures................................... 6=0A= 7.1. Binding State Table (BST)............................... 6=0A= 7.2. Filtering Table (FT).................................... 7=0A= 8. Binding States Description................................... 7=0A= 9. Stateless Scenario .......................................... 7=0A= =0A= =0A= Bi Expires September 17, 2010 [Page 2]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= 10. Anchor Attributes .......................................... 8=0A= 10.1. SAVI-Validation Attribute.............................. 8=0A= 10.2. SAVI-RA-Trust Attribute................................ 8=0A= 10.3. SAVI-SAVI Attribute.................................... 9=0A= 10.4. Optional Attributes.................................... 9=0A= 10.4.1. SAVI-LocalGroup Attribute......................... 9=0A= 10.4.2. SAVI-DataTrigger Attribute........................ 9=0A= 11. Prefix Configuration....................................... 10=0A= 12. Binding Set Up ............................................ 11=0A= 12.1. Process of Control Packet Snooping.................... 11=0A= 12.1.1. Initialization................................... 11=0A= 12.1.1.1. Trigger Event............................... 11=0A= 12.1.1.2. Event Validation............................ 11=0A= 12.1.1.3. Following Actions........................... 11=0A= 12.1.2. State Transit from DETECTION..................... 11=0A= 12.1.2.1. Trigger Event............................... 11=0A= 12.1.2.2. Following Actions........................... 12=0A= 12.1.3. After BOUND...................................... 12=0A= 12.2. State Machine of DHCP Snooping........................ 12=0A= 13. Filtering Specification.................................... 13=0A= 13.1. Data Packet Filtering................................. 13=0A= 13.2. Control Packet Filtering.............................. 13=0A= 14. Format and Delivery of Probe Messages...................... 13=0A= 14.1. Duplicate detection................................... 14=0A= 15. Binding Remove ............................................ 14=0A= 16. Handle Anchor Off-link event............................... 14=0A= 17. About Collision in Detection............................... 15=0A= 17.1. The Result of Detection without Host Aware............ 15=0A= 18. Filtering during Detection................................. 15=0A= 19. Binding Number Limitation.................................. 15=0A= 20. MLD Consideration ......................................... 16=0A= 21. Data Triggered Process..................................... 16=0A= 22. Constants ................................................. 16=0A= 23. Security Considerations.................................... 16=0A= 24. IANA Considerations........................................ 16=0A= 25. References ................................................ 17=0A= 25.1. Normative References.................................. 17=0A= 25.2. Informative References................................ 17=0A= 26. Acknowledgments ........................................... 17=0A= =0A= 1. Introduction=0A= =0A= This document describes the procedure for creating bindings between=0A= stateless address and anchor (refer to [savi-framework]). Other=0A= related details about this procedure are also specified in this=0A= document.=0A= =0A= =0A= =0A= Bi Expires September 17, 2010 [Page 3]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= These bindings can be used to filter packets with forged IP addresses.=0A= How to use these bindings is specified in [savi-framework], depending=0A= on the environment and configuration. The definition and examples of=0A= anchor is also specified in [savi-framework].=0A= =0A= The binding process is inspired by the work of SAVI-FCFS. Different=0A= from a data trigger based procedure in SAVI-FCFS, this specification=0A= mainly focuses on control panel triggered process. Data triggered=0A= process is designed as a supplement but rather regular process.=0A= =0A= 2. Conventions used in this document=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= 3. Mechanism Overview=0A= =0A= The mechanism specified in this document is designed to provide a=0A= host level source IP address validation granularity, as a supplement=0A= to BCP38 [BCP38]. This mechanism is deployed on the access device=0A= (including access switch, wireless access point/controller, etc), and=0A= performs mainly NDP/ARP snooping to set up bindings between stateless=0A= IP addresses and corresponding anchors. The bindings can be used to=0A= validate the source address in the packets.=0A= =0A= 4. Basic Principle of Address Ownership Arbitration=0A= =0A= In stateless scenario, nodes can "assign" address to themselves, and=0A= perform unreliable duplicate detection to check whether the address=0A= is being used. For IPv6 address, collision happens with very little=0A= probability because of large address space, thus the unreliable=0A= nature of DAD is not serious in reality. However, the unreliability=0A= of DAD troubles source address validation. It is very hard, if not=0A= impossible, for a SAVI device to determine which node can use one=0A= address when conflict happens.=0A= =0A= A wise principle, "First Come First Served" is currently used by=0A= SAVI-FCFS to determine ownership of address. This principle is=0A= correct, however, the problem is, how to determine which node is the=0A= first to use an address. Because the unreliable nature of DAD, the=0A= first one assigned itself an address, may not be the one first using=0A= the address to send traffic sniffed by the SAVI device. SAVI-FCFS=0A= requires device to send detection probes to determine whether an=0A= address is being used by another node. However, this effort may be=0A= vain, because malicious node can reply any probe, and the probe is=0A= still unreliable to reach the possible target node.=0A= =0A= =0A= Bi Expires September 17, 2010 [Page 4]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= After a long time attempt, we finally find that because of the=0A= unreliability of DAD and ND, there is no perfect arbitration policy.=0A= In another word, if a arbitration policy is perfect, it must rely on=0A= a reliable DAD. We can prove this through a simple deduction:=0A= =0A= Perfect arbitrate=3D>=0A= =0A= The one having assigned itself an address first gets the ownership of=0A= the address=3D>=0A= =0A= The one having performed DAD first gets the address=3D>=0A= =0A= The arbitrator must know who is the first to perform DAD=3D>=0A= =0A= The DAD must be reliable to be sniffed by the SAVI device.=0A= =0A= And the deduction can be reversed.=0A= =0A= In the end, we found we were building tower on the quick sand. It=0A= concerns nothing about whether choosing data trigger or control=0A= packet trigger. Unless stateless assignment changes to be reliable,=0A= no solution can be secure.=0A= =0A= In this document, we decide to follow RFC4862, which is the only=0A= stand track on stateless address assignment. This means, if a node=0A= finishes a successful DAD, including the DAD is performed by SAVI=0A= device in case of data trigger, the address MUST be bound with it.=0A= Then the ownership conflict is actually handled through allowing one=0A= address to be bound with multiple anchors. The bindings are only=0A= removed when the lifetime expires, which equals prefix life time=0A= learned from RA. Then we achieve a simple solution, whose security is=0A= based on the reliability of RFC4862.=0A= =0A= 5. Background and Related Protocols=0A= =0A= This mechanism is an instance of a SAVI [savi-framework] solution,=0A= specialized for stateless addresses, including IPv6 Stateless=0A= Autoconfiguration address, manually configured non-static IPv6 and=0A= IPv4 address.=0A= =0A= In IPv6, IPv6 Stateless Autoconfiguration [RFC4862] is a widely=0A= deployed address assignment mechanism. A node can generate an address=0A= autonomously, and use Duplicate Address Detection described in=0A= [RFC4862] to auto-configure this address. [RFC4862] clearly requires=0A= that duplicated address detection must be performed on any IPv6=0A= address, including DHCPv6 address. This is the basis of this control=0A= packet snooping based SAVI solution.=0A= =0A= =0A= Bi Expires September 17, 2010 [Page 5]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= [RFC4861] specifies the Neighbor Discovery protocol, which is an=0A= essential part of IPv6 address assignment.=0A= =0A= IPv4 doesn't have stateless auto-configuration mechanism, because of=0A= the high collision probability of auto-generated address. However, in=0A= some scenarios, interfaces are allowed to be configured addresses=0A= with a specified prefix, instead of assigning each interface a static=0A= address. In such scenarios, the address assignment method is regarded=0A= as stateless in this document.=0A= =0A= [RFC5227] specifies the procedure to detect IPv4 address collision.=0A= It is not required currently. However, this feature is useful to=0A= determine the uniqueness of an IPv4 address on the link. Considering=0A= not all the operating systems support [RFC5227], this solution is=0A= designed to be compatible with operating systems not complying with=0A= [RFC5227].=0A= =0A= 6. Terminology=0A= =0A= Main terms used in this document are described in [savi-framework],=0A= [RFC4862], [RFC826] and [RFC5227].=0A= =0A= 7. Conceptual Data Structures=0A= =0A= This section describes the possible conceptual data structures used=0A= in this mechanism.=0A= =0A= Two main data structures are used to record bindings and their states=0A= respectively. There is redundancy between the two structures, for the=0A= consideration of separation of data plane and control plane.=0A= =0A= 7.1. Binding State Table (BST)=0A= =0A= This table contains the state of binding between source address and=0A= anchor. Entries are keyed on the anchor and source IP address. Each=0A= entry has a lifetime field recording the remaining lifetime of the=0A= entry, a state field recording the state of the binding and a field=0A= recording other information.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires September 17, 2010 [Page 6]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= +---------+----------+-------+-----------+-------+=0A= | Anchor | Address | State | Lifetime |Other |=0A= +---------+----------+-------+-----------+-------+=0A= | A | IP_1 | Bound | 65535 | |=0A= +---------+----------+-------+-----------+-------+=0A= | A | IP_2 | Bound | 10000 | |=0A= +---------+----------+-------+-----------+-------+=0A= | B | IP_1 |_Bound | 1 | |=0A= +---------+----------+-------+-----------+-------+=0A= Figure 1 Instance of BST=0A= =0A= =0A= 7.2. Filtering Table (FT)=0A= =0A= This table contains the bindings between anchor and address, keyed on=0A= anchor. This table doesn't contain any state of the binding. This=0A= table is only used to filter packets. An Access Control List can be=0A= regarded as a practical instance of this table.=0A= =0A= +---------+----------+=0A= |Anchor |Address |=0A= +---------+----------+=0A= |A |IP_1 |=0A= +---------+----------+=0A= |A |IP_2 |=0A= +---------+----------+=0A= Figure 2 Instance of FT=0A= =0A= 8. Binding States Description=0A= =0A= This section describes the binding states of this mechanism.=0A= =0A= DETECTION A gratuitous ARP or Duplicate Address Detection=0A= Neighbor Solicitation has been sent by the host (or=0A= the SAVI device).=0A= =0A= BOUND The address has passed duplicate detection and=0A= it is bound with the anchor.=0A= =0A= 9. Stateless Scenario=0A= =0A= Figure 3 shows the main elements in a stateless address allowed=0A= network. Nodes generate address themselves without the assistance of=0A= any other server. Other address assignment mechanisms may be also=0A= used in such network.=0A= =0A= =0A= =0A= =0A= Bi Expires September 17, 2010 [Page 7]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= +----------+=0A= | SAVI |=0A= | Device |=0A= +-/------/-+=0A= | |=0A= +----\-+ +\-----+=0A= |Node 1| |Node 2|=0A= | | | |=0A= +------+ +------+=0A= Figure 3 Stateless Scenario=0A= =0A= 10. Anchor Attributes=0A= =0A= This section specifies the anchor attributes involved in this=0A= mechanism.=0A= =0A= Anchor is defined in the [savi-framework]. Attribute of each anchor=0A= is configurable. In default, anchor has no attribute. An anchor MAY=0A= be configured to have one or more compatible attributes. However, an=0A= anchor MAY have no attribute.=0A= =0A= If an anchor has no attribute, in this solution, Router Advertisement=0A= message from this anchor MUST be dropped. However, other packets=0A= SHOULD NOT be dropped.=0A= =0A= 10.1. SAVI-Validation Attribute=0A= =0A= If and only if source address validation must be performed on the=0A= traffic from an anchor, this anchor MUST be set to have SAVI-=0A= Validation attribute. The filtering process on anchor with such=0A= attribute is described in section 12.=0A= =0A= 10.2. SAVI-RA-Trust Attribute=0A= =0A= If and only if an anchor is associated with a trustable router, it=0A= SHOULD be set to have this attribute.=0A= =0A= On a SAVI device enabled this solution, there may be no anchor with=0A= this attribute. This implies only link-local address is allowed, or=0A= prefix validation is not enabled, or only manually configured prefix=0A= is allowed. Router Advertisement message not coming from such anchors=0A= MUST be dropped.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires September 17, 2010 [Page 8]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= 10.3. SAVI-SAVI Attribute=0A= =0A= If and only if an anchor is associated with another SAVI device, it=0A= SHOULD be set to have this attribute. All traffic from anchor with=0A= this attribute will be forwarded without check.=0A= =0A= This attribute can also be set on other anchors if the administrator=0A= decides not to validate the traffic from the anchor. Note that DHCP=0A= server message and Router Advertisement will also be trusted.=0A= =0A= This attribute is mutually exclusive with SAVI-Validation.=0A= =0A= 10.4. Optional Attributes=0A= =0A= This section specifies the attributes optional for the implementation=0A= of this solution. The usage of these attributes may be suboptimal=0A= compared with manual configuration, because of the additional=0A= complexity. However, in scenarios that manual configuration is hardly=0A= to be taken timely or even impossible, these attributes can be useful.=0A= =0A= The implementation and configuration of these attributes are left to=0A= be determined by vendors, network administrators and clients.=0A= =0A= 10.4.1. SAVI-LocalGroup Attribute=0A= =0A= If a group of anchors on a SAVI device are associated with the same=0A= group of clients, these anchors can be set to have SAVI-LocalGroup=0A= attribute.=0A= =0A= SAVI-LocalGroup Attribute is set with the index or name of the group.=0A= =0A= The bindings set up on an anchor with this attribute MUST be=0A= replicated to other anchors in the same group. If a binding entry is=0A= removed, the replicated entries on other anchors MUST be deleted,=0A= unless the entry is removed because the associated anchor is off-link.=0A= =0A= This attribute is designed to handle the scenario that a group of=0A= nodes (including a single node) poss multiple anchors, but control=0A= packets are only transmitted with one of the anchors. After address=0A= assignment, the assigned address may be used with other anchors.=0A= =0A= This attribute is mutually exclusive with SAVI-SAVI.=0A= =0A= 10.4.2. SAVI-DataTrigger Attribute=0A= =0A= If on an anchor, data packet (non-DAD message) is required to trigger=0A= binding set up, this anchor should be set to have this attribute.=0A= =0A= =0A= Bi Expires September 17, 2010 [Page 9]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= The process of data triggered binding is specified in section 22.=0A= =0A= This attribute is designed to handle some special cases that control=0A= packet will not be received by SAVI device, including:=0A= =0A= 1. Local Link Move without Re-configuration Process=0A= =0A= 2. Multiple Attachments to Different Devices=0A= =0A= Note that, both scenarios can be handled if client chooses to repair=0A= its network manually. But this attribute can be set to improve user=0A= experience and network robustness; meanwhile it brings additional=0A= complexity and possible security risk.=0A= =0A= This attribute is mutually exclusive with SAVI-SAVI and SAVI-=0A= Validation.=0A= =0A= 11. Prefix Configuration=0A= =0A= Because Duplicate Address Detection doesn't have the function of=0A= checking the validity of the prefix of address, in this solution, it=0A= is SUGGESTED that correct address prefix SHOULD be configured. If the=0A= correct prefix is not configured, the SAVI device may bind anchors=0A= with addresses using bogus prefixes. Although a prefix level=0A= filtering mechanism, e.g., ingress filtering may be deployed on the=0A= layer 3 device of the network, it cannot prevent spoofing in the=0A= local link.=0A= =0A= This document suggests set 3 prefix scopes:=0A= =0A= IPv4 Prefix:=0A= =0A= The allowed scope of any kind of IPv4 addresses. It can be set=0A= manually.=0A= =0A= IPv6 Prefixes:=0A= =0A= The allowed scope of SLAAC and manually configured IPv6=0A= addresses. It can be set through snooping RA message from port=0A= with SAVI-RA-Trust attribute, DHCP-PD or manual configuration.=0A= =0A= FE80::/64 MUST be set to a feasible prefix.=0A= =0A= There is no need to explicitly present these prefix scopes. But these=0A= restrictions SHOULD be used as premier check in binding set up.=0A= =0A= Refer to security consideration for other discussions.=0A= =0A= =0A= Bi Expires September 17, 2010 [Page 10]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= 12. Binding Set Up=0A= =0A= This section specifies the procedure of setting up bindings based on=0A= control packet snooping. The binding procedure specified here is=0A= exclusively designed for anchor with SAVI-Validation attribute.=0A= =0A= 12.1. Process of Control Packet Snooping=0A= =0A= 12.1.1. Initialization=0A= =0A= 12.1.1.1. Trigger Event=0A= =0A= A gratuitous ARP Request or Duplicate Address Detection Neighbor=0A= Solicitation is received from anchor.=0A= =0A= 12.1.1.2. Event Validation=0A= =0A= The SAVI device checks the BST as follows:=0A= =0A= 1. Whether binding number limitation will be exceeded if a new=0A= binding entry is set up.=0A= =0A= 12.1.1.3. Following Actions=0A= =0A= If the check is passed:=0A= =0A= The packet MUST be forwarded.=0A= =0A= An new entry MUST be generated, with state set to be DETECTION, and=0A= lifetime set to be MAX_ARP_DELAY or MAX_DAD_DELAY respectively.=0A= =0A= +---------+----------+-----------+-----------------+-------+=0A= | Anchor | Address | State | Lifetime |Other |=0A= +---------+----------+-----------+-----------------+-------+=0A= | A | Addr | DETECTION |MAX_ARP_DELAY | |=0A= | | | |MAX_DAD_DELAY | |=0A= +---------+----------+-----------+-----------------+-------+=0A= Figure 4 Binding entry in BST on detection=0A= =0A= A new entry MUST be inserted into the FT.=0A= =0A= 12.1.2. State Transit from DETECTION=0A= =0A= 12.1.2.1. Trigger Event=0A= =0A= A timeout event of an entry with state DETECTION occurs or an ARP=0A= Response or NA for an address in BST with state DETECTION is received.=0A= =0A= =0A= Bi Expires September 17, 2010 [Page 11]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= 12.1.2.2. Following Actions=0A= =0A= If a timeout event of an entry with state DETECTION occurs, set the=0A= state of the entry to be BOUND. The lifetime of the entry is set to=0A= be the lifetime of corresponding prefix, which is learn from RA. If=0A= the address is link local address, the lifetime of the binding SHOULD=0A= be set to INFINITE.=0A= =0A= +---------+----------+-----------+------------------------+------+=0A= | Anchor | Address | State | Lifetime |Other |=0A= +---------+----------+-----------+------------------------+------+=0A= | A | Addr | BOUND | prefix lifetime | |=0A= +---------+----------+-----------+------------------------+------+=0A= Figure 5 Binding entry in BST on finalization=0A= =0A= If an ARP Response or NA for an address in BST with state DETECTION=0A= is received, remove the corresponding entry in BST and FT. The ARP=0A= Response or NA MUST be delivered to the client.=0A= =0A= 12.1.3. After BOUND=0A= =0A= Once a binding entry is set up for an anchor, the binding will be=0A= used to filter packet with the anchor, as specified in section 13.=0A= The state of the binding entry will not be affected by any message.=0A= =0A= If the lifetime of an entry with state BOUND expires, delete the=0A= entry in BST and Filter Table.=0A= =0A= Switch port down event (or more general, anchor turns off-link) will=0A= change the corresponding entry, as described in section 15.=0A= =0A= 12.2. State Machine of DHCP Snooping=0A= =0A= The main state transits are listed as follows. Note that the anchor=0A= migration of binding entry is not included.=0A= =0A= State Message/Event Action Next State=0A= =0A= - Gra ARP/DAD NS Generate entry DETECTION=0A= =0A= DETECTION ARP RES/DAD NA Remove entry -=0A= =0A= DETECTION Timeout Finish binding BOUND=0A= =0A= BOUND Timeout Remove entry -=0A= =0A= Gra ARP REQ: Gratuitous ARP REQUEST=0A= =0A= =0A= Bi Expires September 17, 2010 [Page 12]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= ARP RES: ARP RESPONSE=0A= =0A= DAD NS: Duplicate Address Detection Neighbor Solicitation=0A= =0A= DAD NA: Neighbor Advertisement targeting at a tentative address=0A= =0A= 13. Filtering Specification=0A= =0A= This section specifies how to use bindings to filter packets. Because=0A= the Filtering Table is an allow-table, packet with source address not=0A= in the table will be filtered.=0A= =0A= Filtering policies are different for data packet and control packet.=0A= ND messages that may cause state transit are classified into control=0A= packet. Neighbor Advertisement and ARP Response are also included in=0A= control packet, because the Target Address of NA and ARP Response=0A= should be checked to prevent spoofing. All other packets are=0A= considered to be data packets.=0A= =0A= 13.1. Data Packet Filtering=0A= =0A= Data packets with an anchor which has attribute SAVI-Validation MUST=0A= be checked.=0A= =0A= If the source of a packet associated with its anchor is in the FT,=0A= this packet SHOULD be forwarded; or else the packet MUST be discarded.=0A= =0A= 13.2. Control Packet Filtering=0A= =0A= For anchors with SAVI-Validation attribute:=0A= =0A= The source address of IPv6 NS and IPv4 gratuitous ARP MUST pass the=0A= check on FT.=0A= =0A= The target address and source address in all the Neighbor=0A= Advertisement packets and ARP replies MUST also pass the checks on FT.=0A= =0A= For other anchors:=0A= =0A= All RA packets MUST be from anchor with the SAVI-RA-Trust attribute.=0A= =0A= 14. Format and Delivery of Probe Messages=0A= =0A= The SAVI device MAY send detection probes on behavior of node to=0A= determine whether the assigned address is duplicated in case of data=0A= trigger is enabled. Currently no other probes are designed in this=0A= solution.=0A= =0A= =0A= Bi Expires September 17, 2010 [Page 13]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= 14.1. Duplicate detection=0A= =0A= Message Type: DAD NS, Gratuitous ARP Request=0A= =0A= Format:=0A= =0A= Link layer source - link layer address of host;=0A= =0A= Link layer destination - For IPv6, use multicast = address=0A= specified in [RFC3307]; For IPv4, use broadcast address;=0A= =0A= IP source - Unspecified address for IPv6; The = tentative=0A= =0A= address for IPv4;=0A= =0A= IP destination - For IPv6, multicast address = specified in=0A= section 5.4.2 of [RFC4861]; For IPv4, the tentative address;=0A= =0A= Delivery:=0A= =0A= MUST not be delivered to the host which the SAVI device is=0A= performing DAD on behavior of.=0A= =0A= 15. Binding Remove=0A= =0A= If the lifetime of an entry with state BOUND expires, the entry MUST=0A= be removed.=0A= =0A= 16. Handle Anchor Off-link event=0A= =0A= Port DOWN event MUST be handled if switch port is used as anchor. In=0A= more general case, if an anchor turns off-link, this event MUST be=0A= handled.=0A= =0A= Whenever an anchor with attribute SAVI-Validation turns down, the=0A= bindings with the anchor MUST be kept for a short time.=0A= =0A= To handle movement, if receiving DAD NS/Gra ARP request targeting at=0A= the address during the period, remove the entry.=0A= =0A= If the anchor turns on-link during the period, recover bindings. It=0A= may result in some security problem, e.g., a malicious node=0A= immediately associates with the anchor got off by a previous node,=0A= then it can use the address assigned to the previous node. However,=0A= this situation is very rare in reality. Authors decide not to handle=0A= this situation.=0A= =0A= =0A= =0A= Bi Expires September 17, 2010 [Page 14]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= 17. About Collision in Detection=0A= =0A= The SAVI device may receive a response in detection. Some related=0A= details are specified here.=0A= =0A= 17.1. The Result of Detection without Host Aware=0A= =0A= In case the SAVI device send detection packet instead of the host,=0A= the host will not be aware of the detection result. If the detection=0A= succeeds, there is no problem. However, if the detection fails, the=0A= packets from the host with the assigned address will be filtered out.=0A= This result can be regarded as a reasonable punishment for not=0A= performing duplicate detection and using a collision address. The=0A= SAVI device MAY choose to notice the client that the assigned address=0A= has been used, through a NA message. This mechanism is not required=0A= in this solution.=0A= =0A= 18. Filtering during Detection=0A= =0A= In this mechanism, whenever a DAD NSOL is received, this address will=0A= be allowed immediately even before duplicate detection is completed.=0A= This design is in consideration of a host may start to send packets=0A= straightway without detection. Also this design is to be compatible=0A= with optimistic DAD [RFC4429].=0A= =0A= However, this feature may allow an attacker to send quantities of=0A= packets with source addresses already assigned to other nodes.=0A= =0A= 19. Binding Number Limitation=0A= =0A= It is suggested to configure some mechanism in order to prevent a=0A= single node from exhausting the binding table entries on the SAVI=0A= device. Either of the following mechanism is sufficient to prevent=0A= such attack.=0A= =0A= 1. Set the upper bound of binding number for each anchor with SAVI-=0A= Validation.=0A= =0A= 2. Reserve a number of binding entries for each anchor with SAVI-=0A= Validation attribute and all anchors share a pool of the other=0A= binding entries.=0A= =0A= 3. Limit DAD NSOL rate per anchor, using the bound entry number of=0A= each anchor as reverse indicator.=0A= =0A= =0A= =0A= =0A= =0A= Bi Expires September 17, 2010 [Page 15]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= 20. MLD Consideration=0A= =0A= The SAVI device MUST join the tentative address multicast group=0A= whenever perform duplicate detection on behavior of host.=0A= =0A= 21. Data Triggered Process=0A= =0A= If an anchor is set to have SAVI-DataTrigger attribute, data packet,=0A= including ARP and NDP messages whose source address is not bound with=0A= the anchor, is not filtered directly; instead, the SAVI device will=0A= check whether the address can be used by the client on the local link:=0A= =0A= IPv4 address:=0A= =0A= Send a Gratuitous ARP message on the link whose format is=0A= described in section 14. If no ARP response message is received,=0A= set up a new binding for the anchor; otherwise discard the packet.=0A= =0A= IPv6 address:=0A= =0A= Send a DAD NSOL message whose format is described in section 14.=0A= If any DAD NA is received, discard the packet; otherwise generate=0A= a new binding entry for the address.=0A= =0A= The data triggered process MUST be rate limited to avoid Denial of=0A= Services attack against the SAVI device itself.=0A= =0A= 22. Constants=0A= =0A= MAX_ARP_DELAY Default 1s but configurable=0A= =0A= MAX_DAD_DELAY Default 1s but configurable=0A= =0A= 23. Security Considerations=0A= =0A= For prefix level granularity filtering is the basis of host level=0A= granularity filtering, to learn and configure correct prefix is of=0A= great importance to this mechanism. Thus, it's important to keep RA=0A= and DHCP-PD secure. [draft-ietf-v6ops-ra-guard-03] describes a=0A= mechanism to improve the security of RA message.=0A= =0A= 24. IANA Considerations=0A= =0A= There is no IANA consideration currently.=0A= =0A= =0A= =0A= =0A= =0A= Bi Expires September 17, 2010 [Page 16]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= 25. References=0A= =0A= 25.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= 25.2. Informative References=0A= =0A= [RFC3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast=0A= Addresses", RFC3307, August 2002.=0A= =0A= [RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman,=0A= "Neighbor Discovery for IP version 6 (IPv6)", RFC4861, September 2007.=0A= =0A= [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless=0A= Autoconfiguration", RFC4862, September, 2007.=0A= =0A= [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227,=0A= July 2008.=0A= =0A= 26. Acknowledgments=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires September 17, 2010 [Page 17]=0A= =0C=0A= Internet-Draft savi-dhcp March 2010=0A= =0A= =0A= Authors' Addresses=0A= =0A= Jun Bi=0A= CERNET=0A= Network Research Center, Tsinghua University=0A= Beijing 100084=0A= China=0A= Email: junbi@cernet.edu.cn=0A= =0A= Jianping Wu=0A= CERNET=0A= Computer Science, Tsinghua University=0A= Beijing 100084=0A= China=0A= Email: jianping@cernet.edu.cn=0A= =0A= Guang Yao=0A= CERNET=0A= Network Research Center, Tsinghua University=0A= Beijing 100084=0A= China=0A= Email: yaog@netarchlab.tsinghua.edu.cn=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires September 17, 2010 [Page 18]=0A= =0C=0A= ------=_NextPart_000_000C_01CAC5F2.B0630F80-- From yaoa02@mails.tsinghua.edu.cn Wed Mar 17 02:46:32 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8DC3A6A04 for ; Wed, 17 Mar 2010 02:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[AWL=1.570, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsqXZW19jul4 for ; Wed, 17 Mar 2010 02:46:31 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 306EA3A6861 for ; Wed, 17 Mar 2010 02:46:31 -0700 (PDT) Received: from tu132201.ip.tsinghua.edu.cn ([166.111.132.201] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1Nrppk-0005jo-1O for savi@ietf.org; Wed, 17 Mar 2010 17:46:36 +0800 From: "Guang Yao" To: References: <4B94C376.40502@it.uc3m.es> <4B94D28C.3000205@it.uc3m.es> <10F327EA71564228A016D2641E12121A@junbiVAIO> <4B95039F.7030908@it.uc3m.es> <4B95F6EA.8080800@it.uc3m.es> <4B960C36.8080306@it.uc3m.es><4B9E1BF3.9080709@it.uc3m.es><231D9821F3704A09BCB0B166137AA034@junbiVAIO><4B9E3D5C.6040600@it.uc3m.es><876F7DBECC2348C695021E77315654F0@junbiVAIO> <4B9E4E84.1090003@it.uc3m.es> <0F84A919BFA04A5CB05C6010251A11B3@junbiVAIO> <4B9E586D.9070800@it.uc3m.es> <4B9F8194.4070105@cisco.com> <4B9F8E39.2070605@it.uc3m.es> <4B9F9DE7.1030104@cisco.com> In-Reply-To: <4B9F9DE7.1030104@cisco.com> Date: Wed, 17 Mar 2010 17:46:25 +0800 Message-ID: <003301cac5b6$b5c1fef0$2145fcd0$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrFGbSzsJ2EqHctTfa4B5VlqJjQlwAnJ5sw Content-Language: zh-cn Subject: Re: [savi] savi-dhcp-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 09:46:32 -0000 However, on the longer term, I'd be interrested in exploring more > robust solutions ... > Eric I entirely agree with this point. Building security protocol on = unreliable protocol(especially, slaac) seems awkward. Guang > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf = Of Eric > Levy-Abegnoli > Sent: Tuesday, March 16, 2010 11:04 PM > To: marcelo bagnulo braun > Cc: savi@ietf.org > Subject: Re: [savi] savi-dhcp-02 >=20 > marcelo bagnulo braun a =E9crit : > > El 16/03/10 14:03, Eric Levy-Abegnoli escribi=F3: > >> > >> It might be un-avoidable, I am not arguying. I wish we could come = up > >> with a different solution. > >> Right now the charter constrain us to keep not invent a new = protocol, > > > > How would a new protocol solve the problem? > A protocol that would allow nodes to "register" their address and the > switch to query them. Something like RFC3122 (applied to ethernet = links, > see draft-thubert-3122bis-01 > ) or like = Erik > N. draft (see draft-nordmark-6lowpan-reg-00 > ). > If we had a reliable mechanism by which the switch could discover > bindings, then we would not have to snoop, and would not be exposed to > snoop failures. > This is excluded by the charter, so I am not arguying about = considering > these. However, on the longer term, I'd be interrested in exploring = more > robust solutions ... > Eric >=20 > > > > Regards, marcelo > > > > > > > >> and this is turning into changing the hardware ... > >> Eric > >> > >>> > >>> Regards, marcelo > >> > >> > > > > >=20 > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From yaoa02@mails.tsinghua.edu.cn Wed Mar 17 04:59:41 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8E43A68B4 for ; Wed, 17 Mar 2010 04:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.422 X-Spam-Level: X-Spam-Status: No, score=-0.422 tagged_above=-999 required=5 tests=[AWL=1.047, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqUDtM3tpc2Z for ; Wed, 17 Mar 2010 04:59:40 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 1C8E33A685A for ; Wed, 17 Mar 2010 04:59:39 -0700 (PDT) Received: from tu132201.ip.tsinghua.edu.cn ([166.111.132.201] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NrruX-0005eC-Pa; Wed, 17 Mar 2010 19:59:41 +0800 From: "Guang Yao" To: "'Eric Levy-Abegnoli'" References: <09741A6EA86846049A114B745EE24C37@junbiVAIO> <4B9E2ECD.7080504@cisco.com> <000a01cac445$5b2465e0$116d31a0$@tsinghua.edu.cn> <4B9E407C.8000303@cisco.com> <001701cac44c$bd4e14d0$37ea3e70$@tsinghua.edu.cn> <4B9FA13E.3050801@cisco.com> <003501cac5ba$73f7a980$5be6fc80$@tsinghua.edu.cn> <4BA0AEA2.1050202@cisco.com> In-Reply-To: <4BA0AEA2.1050202@cisco.com> Date: Wed, 17 Mar 2010 19:59:31 +0800 Message-ID: <000901cac5c9$4dee4640$e9cad2c0$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrFvIWiB01KLTPOSEGxAJwliDS5ngACUEQw Content-Language: zh-cn Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02 draft X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 11:59:41 -0000 Hi Eric, > > > Agreed. For me it's clear that the SMAC is the only option (even when > the link-layer address is present in the DUID), it may not be the one > used to source packets with the IP address listed in the IPADDR. > For nodes with multiple interfaces, they typically have multple SMAC, > but one DUID. > I would suggest that you clarify this in the draft. [Guang Yao]=20 Thanks for your suggestion. We will add this specification in the 03 = edition and the presentation of this meeting. > > > That clarifies. I guess my only concern with this mechanism is the = fact > that it requires the switch to operate at layer3. > _If_ this is a pure layer2 switch (whether it does not have L3 > capability, or the network operator does not want to pay the operation > price of enabling the layer3, which for me is a real use case, then we > can't use DHCP LEASEQUERY to resolve the problem of missing bindings. >=20 [Guang Yao]=20 For a pure layer2 device, the savi-datatrigger attribute will not be implemented. In current draft, it is a "optional" attribute. As suggested by Joel, in this situation, client should recover binding itself, e.g., repairing the network connection. > I would like to know what is the fallback plan then? (the question is > not just to you but to the WG). > Personnally, I'd suggest that we do a NDP discovery (NS DAD), and > eventually, if we snoop a RENEW or REBIND later, replace the entry > installed thru DAD by the DHCP one (if they are different). [Guang Yao]=20 A problem here is that, if only DHCP address is allowed, this mechanism = will let pass an address not assigned by DHCP. And the SAVI device may have = to wait a RENEW or REBIND for a long time. Maybe we can suggest set a short DHCP lifetime? Is there any other proposal? But, at least, in scenarios that DHCP and Slaac both are allowed, it is = a good idea. > Thanks > Eric > > > >> Thanks for clarifying all these points. > >> Eric > >> > >> Guang Yao a =E9crit : > >> > >>> Hi Eric, > >>> > >>> The method that save bindings in non volatile memory is described = in > >>> > > section > > > >>> 21. Thanks for your previous suggestion. > >>> > >>> The data triggered dhcp lease query is not used to restore = previous > >>> bindings, but to set up bindings the device _never_ gets known. = The > >>> scenarios include movement on local link, and layer 2 topo = changes, as > >>> discussed recently. > >>> > >>> BR, > >>> Guang > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On = Behalf Of > >>>> > >>>> > >>> Eric > >>> > >>> > >>>> Levy-Abegnoli > >>>> Sent: Monday, March 15, 2010 10:13 PM > >>>> To: Guang Yao > >>>> Cc: 'SAVI Mailing List' > >>>> Subject: Re: [savi] savi-dhcp-02 draft > >>>> > >>>> Hi Guang, > >>>> > >>>> Guang Yao a =E9crit : > >>>> > >>>> > >>>>> Hi Eric, > >>>>> > >>>>> Thanks for your suggestion. Your experience is very valuable. > >>>>> > >>>>> In this solution, sending DHCP lease query is optional, just to handle > >>>>> > >>>>> > >>> some > >>> > >>> > >>>>> special cases (in general, data triggered but rather control packet). > >>>>> > > It > > > >>> is > >>> > >>> > >>>>> not required to be enabled. Vendors may choose to implement it = on > >>>>> > > layer > > > >>> 3 > >>> > >>> > >>>>> device but not pure layer 2 device. And network administrators = may not > >>>>> enable this function if they find the device may be overloaded. > >>>>> > >>>>> If binding is learnt from NDP, IMO it should be bound in = savi-slaac, > >>>>> > > but > > > >>> not > >>> > >>> > >>>>> in this solution for DHCP. And the which to prefer in case of > >>>>> > >>>>> > >>> co-existing of > >>> > >>> > >>>>> NDP and DHCP, I think should be specified in the framework doc. = Am I > >>>>> > >>>>> > >>> right? > >>> > >>> > >>>>> BR, > >>>>> Guang > >>>>> > >>>>> > >>>>> > >>>> What I meant is that the proposed method (sending a leasequery to > >>>> re-discover a binding lost in case of the switch reboot) cannot = be used > >>>> as a "general" response to the problem raised. A switch, L2-only > >>>> > > device, > > > >>>> that looses its binding table and has no non-volatile memory has = just > >>>> > > no > > > >>>> way to recover it thru DHCP. It's is unfortunate since DHCP is > >>>> considered as the only authoritative method for discovering = bindings. > >>>> I would consider that at the stage, when DHCP is used, = non-volatile > >>>> memory is the only option. > >>>> Eric > >>>> > >>>> > >>>>>> -----Original Message----- > >>>>>> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf > >>>>>> > > Of > > > >>>>>> > >>>>> Eric > >>>>> > >>>>> > >>>>> > >>>>>> Levy-Abegnoli > >>>>>> Sent: Monday, March 15, 2010 8:58 PM > >>>>>> To: Bi Jun > >>>>>> Cc: SAVI Mailing List > >>>>>> Subject: Re: [savi] savi-dhcp-02 draft > >>>>>> > >>>>>> Bi Jun a =E9crit : > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Hi all, > >>>>>>> > >>>>>>> This is a revised version of savi-dhcp (revised based on the > >>>>>>> discussion of dhcp-01 on the mailing-list in the past week), > >>>>>>> basically, make the control packet-triggered functions as MUST (low > >>>>>>> cost to be implemented in every switch), and have the data-triggered > >>>>>>> functions (more complex to be implemented) as optional for > >>>>>>> > > higher-end > > > >>>>>>> switches (to enable more flexible use of savi device). > >>>>>>> > >>>>>>> We are consulting the vendors on the cost for those options. > >>>>>>> > >>>>>>> please give us your comments. > >>>>>>> > >>>>>>> thanks, > >>>>>>> Jun Bi SAVI > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> J. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Bi, J. Wu > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> Hi Jun bi, > >>>>>> Reading the below: > >>>>>> > >>>>>> "IPv6 address: > >>>>>> Send a LEASEQUERY [RFC5007] message querying by IP > address > >>>>>> > >> to > >> > >>>>>> All_DHCP_Relay_Agents_and_Servers multicast address or a > >>>>>> configured server address. If no successful = LEASEQUERY-REPLY > is > >>>>>> received, discard the packet; otherwise generate a new > binding > >>>>>> entry for the address. The SAVI device may repeat this process > >>>>>> > > if > > > >>>>>> a LEASEQUERY-REPLY with OPTION_CLIENT_LINK is received, > in > >>>>>> > >>>>>> > >>>> order > >>>> > >>>> > >>>>>> to set up binding entries for all the address of the = client." > >>>>>> > >>>>>> I don't think the below proposal to discover IPv6 address from = the > >>>>>> > > savi > > > >>>>>> device works. DHCP messages must be sourced with an IPv6 = address > >>>>>> > >>>>>> > >>>> (can't > >>>> > >>>> > >>>>>> be UNSPEC, must be a link-local) and in most cases, the switch = does > >>>>>> > > not > > > >>>>>> have any. That would take the switch to have a L3 interface = that > >>>>>> participate in the link operations (for each of its vlans), and that > >>>>>> > > is > > > >>>>>> a huge constrain. > >>>>>> I have real deployment examples of pure L2 switch devices with > >>>>>> > >>>>>> > >>> thousands > >>> > >>> > >>>>>> of vlans configured (hundreds of ports in each vlan). Getting a = L3 > >>>>>> address in each vlan would have a huge impact on the switch > >>>>>> > > operations > > > >>>>>> and performances.That does not seem acceptable. > >>>>>> I think the only option is to discover the binding by probing = with a > >>>>>> > >>>>>> > >>> NDP > >>> > >>> > >>>>>> DAD NS. This one is sourced with UNSPEC and hence is accpetable = for a > >>>>>> > >>>>>> > >>> L2 > >>> > >>> > >>>>>> device. Then install the binding as learnt from NDP. And = later, > >>>>>> "prefer" the DHCP binding when/if it shows up. > >>>>>> Eric > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> savi mailing list > >>>>>> savi@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/savi > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> _______________________________________________ > >>>> savi mailing list > >>>> savi@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/savi > >>>> > >>>> > >>> _______________________________________________ > >>> savi mailing list > >>> savi@ietf.org > >>> https://www.ietf.org/mailman/listinfo/savi > >>> > >>> > >>> > > > > > > > > From yaoa02@mails.tsinghua.edu.cn Wed Mar 17 05:00:52 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09AC93A6A28 for ; Wed, 17 Mar 2010 05:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.084 X-Spam-Level: X-Spam-Status: No, score=-0.084 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_72=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFTWyCRegEtq for ; Wed, 17 Mar 2010 05:00:51 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 27E893A6931 for ; Wed, 17 Mar 2010 05:00:50 -0700 (PDT) Received: from tu132201.ip.tsinghua.edu.cn ([166.111.132.201] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1Nrrvi-00083a-Oa for savi@ietf.org; Wed, 17 Mar 2010 20:00:54 +0800 From: "Guang Yao" To: Date: Wed, 17 Mar 2010 20:00:44 +0800 Message-ID: <000a01cac5c9$796b3d50$6c41b7f0$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrFG/DnFKIM/0WPQhuJ2PJCHb5bgwAmz10AAASPG1A= Content-Language: zh-cn Subject: [savi] FW: savi-dhcp-02 draft X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 12:00:52 -0000 Hi Eric, Please see replies inline. > -----Original Message----- > From: Eric Levy-Abegnoli [mailto:elevyabe@cisco.com] > Sent: Tuesday, March 16, 2010 11:18 PM > To: Guang Yao > Cc: 'SAVI Mailing List' > Subject: Re: [savi] savi-dhcp-02 draft >=20 > Hi Guang, > I have a questions regarding both the current draft and this = discussion. >=20 > 1) When you learn a binding by snooping DHCP REQUEST/REPLY, you read = the > client IP address out of the IADDR option, right? > Where do you get the MAC address from in case it is the anchor? Is it > the SMAC of the request? The DMAC of the server response? Or is it the > DUID in the clientID option? [Guang Yao]=20 Because anchor should be learn from request message(or with request message), and DUID may not contain the link layer address, I prefer SMAC = in the request. >=20 > 2)When a switch is trying to retrieve bindings that it _never_ knew, = per > the topo changes discussion, it goes to the server with a LEASEQUERY. > Get back an Address and a ClientID (carrying a DUID). No port, right? = So > in case the anchor is the port, where is it learning the port from in > this scenario? [Guang Yao]=20 This procedure is triggered by data packet received from a port, and = then the port can be learned with the data packet. I know it may be not quite secure. Malicious node can send packet with address of another node. Because leasequery just ensures the address is assigned, the savi will bind the address with the malicious node. Thus = this function (savi-datatrigger attribute), must only be configured on = selected port in very specified scenario( as described by Marcelo). >=20 > 3) The DUID carried in the ClientID is _not_ always the SMAC that the > client will use to source packets for the IP address requested. If you > disagree with that, I can develop ... So whether in 1) or 2) this = cannot > be used. For 1) we can always use the SMAC of the request (of DMAC of > the response). For 2), what else do we have? >=20 [Guang Yao]=20 Maybe the above explanations are not clear. Data triggered lease query = is not used to bind anchor and SIP with absolute security(and impossible), = but just to avoid packet loss in very specified scenarios. The binding is = loose but not dangerous to other node. And this is not a MUST function. It can be turned off to achieve strict security. > Thanks for clarifying all these points. > Eric >=20 > Guang Yao a =E9crit : > > Hi Eric, > > > > The method that save bindings in non volatile memory is described in section > > 21. Thanks for your previous suggestion. > > > > The data triggered dhcp lease query is not used to restore previous > > bindings, but to set up bindings the device _never_ gets known. The > > scenarios include movement on local link, and layer 2 topo changes, = as > > discussed recently. > > > > BR, > > Guang > > > > > >> -----Original Message----- > >> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On = Behalf Of > >> > > Eric > > > >> Levy-Abegnoli > >> Sent: Monday, March 15, 2010 10:13 PM > >> To: Guang Yao > >> Cc: 'SAVI Mailing List' > >> Subject: Re: [savi] savi-dhcp-02 draft > >> > >> Hi Guang, > >> > >> Guang Yao a =E9crit : > >> > >>> Hi Eric, > >>> > >>> Thanks for your suggestion. Your experience is very valuable. > >>> > >>> In this solution, sending DHCP lease query is optional, just to = handle > >>> > > some > > > >>> special cases (in general, data triggered but rather control = packet). It > >>> > > is > > > >>> not required to be enabled. Vendors may choose to implement it on layer > >>> > > 3 > > > >>> device but not pure layer 2 device. And network administrators may = not > >>> enable this function if they find the device may be overloaded. > >>> > >>> If binding is learnt from NDP, IMO it should be bound in = savi-slaac, but > >>> > > not > > > >>> in this solution for DHCP. And the which to prefer in case of > >>> > > co-existing of > > > >>> NDP and DHCP, I think should be specified in the framework doc. Am = I > >>> > > right? > > > >>> BR, > >>> Guang > >>> > >>> > >> What I meant is that the proposed method (sending a leasequery to > >> re-discover a binding lost in case of the switch reboot) cannot be = used > >> as a "general" response to the problem raised. A switch, L2-only device, > >> that looses its binding table and has no non-volatile memory has = just no > >> way to recover it thru DHCP. It's is unfortunate since DHCP is > >> considered as the only authoritative method for discovering = bindings. > >> I would consider that at the stage, when DHCP is used, non-volatile > >> memory is the only option. > >> Eric > >> > >>>> -----Original Message----- > >>>> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On = Behalf Of > >>>> > >>>> > >>> Eric > >>> > >>> > >>>> Levy-Abegnoli > >>>> Sent: Monday, March 15, 2010 8:58 PM > >>>> To: Bi Jun > >>>> Cc: SAVI Mailing List > >>>> Subject: Re: [savi] savi-dhcp-02 draft > >>>> > >>>> Bi Jun a =E9crit : > >>>> > >>>> > >>>>> Hi all, > >>>>> > >>>>> This is a revised version of savi-dhcp (revised based on the > >>>>> discussion of dhcp-01 on the mailing-list in the past week), > >>>>> basically, make the control packet-triggered functions as MUST = (low > >>>>> cost to be implemented in every switch), and have the = data-triggered > >>>>> functions (more complex to be implemented) as optional for higher-end > >>>>> switches (to enable more flexible use of savi device). > >>>>> > >>>>> We are consulting the vendors on the cost for those options. > >>>>> > >>>>> please give us your comments. > >>>>> > >>>>> thanks, > >>>>> Jun Bi SAVI > >>>>> > >>>>> > >>>> J. > >>>> > >>>> > >>>>> Bi, J. Wu > >>>>> > >>>>> > >>>> Hi Jun bi, > >>>> Reading the below: > >>>> > >>>> "IPv6 address: > >>>> Send a LEASEQUERY [RFC5007] message querying by IP address > to > >>>> All_DHCP_Relay_Agents_and_Servers multicast address or a > >>>> configured server address. If no successful = LEASEQUERY-REPLY is > >>>> received, discard the packet; otherwise generate a new = binding > >>>> entry for the address. The SAVI device may repeat this = process if > >>>> a LEASEQUERY-REPLY with OPTION_CLIENT_LINK is received, in > >>>> > >> order > >> > >>>> to set up binding entries for all the address of the = client." > >>>> > >>>> I don't think the below proposal to discover IPv6 address from = the savi > >>>> device works. DHCP messages must be sourced with an IPv6 address > >>>> > >> (can't > >> > >>>> be UNSPEC, must be a link-local) and in most cases, the switch = does not > >>>> have any. That would take the switch to have a L3 interface that > >>>> participate in the link operations (for each of its vlans), and = that is > >>>> a huge constrain. > >>>> I have real deployment examples of pure L2 switch devices with > >>>> > > thousands > > > >>>> of vlans configured (hundreds of ports in each vlan). Getting a = L3 > >>>> address in each vlan would have a huge impact on the switch operations > >>>> and performances.That does not seem acceptable. > >>>> I think the only option is to discover the binding by probing = with a > >>>> > > NDP > > > >>>> DAD NS. This one is sourced with UNSPEC and hence is accpetable = for a > >>>> > > L2 > > > >>>> device. Then install the binding as learnt from NDP. And later, > >>>> "prefer" the DHCP binding when/if it shows up. > >>>> Eric > >>>> > >>>> > >>>> _______________________________________________ > >>>> savi mailing list > >>>> savi@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/savi > >>>> > >>>> > >>> > >>> > >> _______________________________________________ > >> savi mailing list > >> savi@ietf.org > >> https://www.ietf.org/mailman/listinfo/savi > >> > > > > _______________________________________________ > > savi mailing list > > savi@ietf.org > > https://www.ietf.org/mailman/listinfo/savi > > > > From jkaippal@huawei.com Mon Mar 22 10:40:38 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1CB28C18E for ; Mon, 22 Mar 2010 10:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEdjc6yUaIRf for ; Mon, 22 Mar 2010 10:40:35 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 4FE993A6902 for ; Mon, 22 Mar 2010 10:40:35 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZP008I22G4W8@usaga01-in.huawei.com> for savi@ietf.org; Mon, 22 Mar 2010 10:40:53 -0700 (PDT) Received: from k7364702 (dhcp-wireless-open-abg-24-72.meeting.ietf.org [130.129.24.72]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZP007JT2G46A@usaga01-in.huawei.com> for savi@ietf.org; Mon, 22 Mar 2010 10:40:52 -0700 (PDT) Date: Mon, 22 Mar 2010 12:40:46 -0500 From: John Kaippallimalil To: 'Bi Jun' , savi@ietf.org Message-id: <6412E96588564673837A92CF0927BB64@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_QoyuAPL5GfTxDd2AAdFaMw)" Thread-index: AcrJ5s3uztxcbTXEQ7Wjy/ByXSD8Nw== Subject: [savi] savi-dhcp-02, state restoration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 17:40:38 -0000 This is a multi-part message in MIME format. --Boundary_(ID_QoyuAPL5GfTxDd2AAdFaMw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Jun, In savi-dhcp-02 section 21 (State Restoration), the suggestion is to store state bindings in non volatile memory. One concern is that non-volatile memory is not typically write efficient. Two alternative solutions: Alternative 1: Use the DHCPLEASEQUERY mechanism to rebuild state. Some details for IPv6 below: - when switch recovers, it has lost all session state (could stop filtering till SAVi state is rebuilt) - Switch sends bulk DHCPLEASEQUERY (query by relay id) - RFC5460. - DHCP server replies with DHCP entries related to that relay - used to rebuild binding state. However, this alternative requires that the SAVI switch to be a DHCP Relay, and also support TCP (bulk query transport). Alternative 2: - Upstream router detects SAVi switch failure (and recovery). Example 802.1ag messages. - Upon switch recovery, the router sends Neighbor Solicitation, replied by host with NA. (similar to NUD?) - This is used to rebuild binding state in SAVI switch. This method does not require the switch to be a DHCP relay. However it requires 802.1ag support in the network. Regards, John --Boundary_(ID_QoyuAPL5GfTxDd2AAdFaMw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = Jun,

In savi-dhcp-02 section 21 (State = Restoration), the suggestion is to store state bindings in non volatile memory. One = concern is that non-volatile memory is not typically write efficient. =

 

Two alternative = solutions:

Alternative 1:

Use the DHCPLEASEQUERY mechanism to rebuild = state. Some details for IPv6 below:

-      = when switch recovers, it has lost all session state (could stop filtering = till SAVi state is rebuilt)

-      = Switch sends bulk DHCPLEASEQUERY (query by relay id) – RFC5460. =

-      = DHCP server replies with DHCP entries related to that relay – used to = rebuild binding state.

However, this alternative requires that the = SAVI switch to be a DHCP Relay, and also support TCP (bulk query transport). =

 

Alternative 2:
- Upstream router detects SAVi switch failure (and recovery). Example = 802.1ag messages.

-      = Upon switch recovery, the router sends Neighbor Solicitation, replied by host = with NA. (similar to NUD?)

-      = This is used to rebuild binding state in SAVI = switch.

This method does not require the switch to be = a DHCP relay. However it requires 802.1ag support in the = network.

 

Regards,

John

 

--Boundary_(ID_QoyuAPL5GfTxDd2AAdFaMw)-- From christian.vogt@ericsson.com Mon Mar 22 14:07:15 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4C3328C1B8 for ; Mon, 22 Mar 2010 14:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukjXxpEjrlAa for ; Mon, 22 Mar 2010 14:07:15 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id DE1F93A6B91 for ; Mon, 22 Mar 2010 14:01:23 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o2ML50n9021208 for ; Mon, 22 Mar 2010 16:05:00 -0500 Received: from client-vpn-075.edd.ericsson.se (147.117.20.213) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.1.375.2; Mon, 22 Mar 2010 17:01:39 -0400 From: Christian Vogt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Mon, 22 Mar 2010 14:01:36 -0700 Message-ID: To: SAVI Mailing List MIME-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [savi] Reminder: Presenters, please send slides X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 21:07:16 -0000 Those of you who will present at tomorrow's SAVI meeting: Please send me your slides if you haven't done so yet. We would like to make all slides available online well before the meeting, so that folks can take a look in advance. Thank you, - Christian From jeanmichel.combes@gmail.com Mon Mar 22 14:35:17 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B0C28C13A for ; Mon, 22 Mar 2010 14:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.105 X-Spam-Level: X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[AWL=-1.495, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE+H0OjhlfOR for ; Mon, 22 Mar 2010 14:35:17 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id A9BB828C139 for ; Mon, 22 Mar 2010 14:35:16 -0700 (PDT) Received: by wyb29 with SMTP id 29so2724411wyb.31 for ; Mon, 22 Mar 2010 14:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=C48VPOyvZlvFVZ3OWYHUm2Fhqvj7NYvyterZhrkuz7M=; b=as9EfYKhfH41WTp6MTFdX+Gsu9SpoeOIe42jhCB4XLu6mEMRBxeGVxeoaF0vi6BHag Aoy1d+2MBUq6Z17qg5q5YdFb7W4ybFhw5cF7tdk3dGkN9US38VKzqb3Y+rRisXFQKj2q sp4jKWmv5ejEiIQVitNRii1ZMpIB0wKtMZ2Do= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=c2kihlMgX3QcWIwmRWueYqmPFG9Uvi5pMqN3wdJGA8OTX+bTddNkYz6sb75bXeK5ym atBn9J9h+lk5ztrL+gTWyBtC0kJx2WlUDrr208roRmRMWpuubbsaFBmKoKdqQdo5NRGS 6Hc55xOAFljpSEsman8cCJd0oZCmOKSMcLtag= MIME-Version: 1.0 Received: by 10.216.88.212 with SMTP id a62mr256921wef.72.1269293730499; Mon, 22 Mar 2010 14:35:30 -0700 (PDT) Date: Mon, 22 Mar 2010 22:35:30 +0100 Message-ID: <729b68be1003221435r71f1de4dx989374951f5d3223@mail.gmail.com> From: Jean-Michel Combes To: SAVI Mailing List , Christian Vogt Content-Type: text/plain; charset=ISO-8859-1 Subject: [savi] Minutes taker & Jabber scribe needed X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 21:35:17 -0000 Hi, for the tomorrow session, we will need one (or more) jabber scribe and one (or more) minutes takers. Thanks a lot in advance for the volunteers! Christian & Jean-Michel. From junbi@cernet.edu.cn Tue Mar 23 10:26:40 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C285D3A6CD9 for ; Tue, 23 Mar 2010 10:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6pg8GMJDzUC for ; Tue, 23 Mar 2010 10:26:39 -0700 (PDT) Received: from hiltoncluster2.worldspice.net (hiltoncluster2.worldspice.net [216.37.94.62]) by core3.amsl.com (Postfix) with ESMTP id 918363A6CCE for ; Tue, 23 Mar 2010 10:26:36 -0700 (PDT) Received: (qmail 4463 invoked by uid 0); 23 Mar 2010 17:26:52 -0000 Received: by simscan 1.4.0 ppid: 3730, pid: 4128, t: 8.4575s scanners: clamav: 0.95.3/m:51/d:10354 spam: 3.3.0 Received: from unknown (HELO junbiVAIO) (junbi@207.88.181.2) by hiltoncluster02.worldspice.net with ESMTPA; 23 Mar 2010 17:26:43 -0000 Message-ID: <114BC39FA8E1409CB4EEB720D3739925@junbiVAIO> From: "Bi Jun" To: "John Kaippallimalil" , References: <6412E96588564673837A92CF0927BB64@china.huawei.com> In-Reply-To: <6412E96588564673837A92CF0927BB64@china.huawei.com> Date: Tue, 23 Mar 2010 10:26:45 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0951_01CACA73.56548570" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Subject: Re: [savi] savi-dhcp-02, state restoration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:26:40 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0951_01CACA73.56548570 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi John, Thank you very much for your suggestion. For alternative 1, it is already added into the section 22 of = savi-dhcp-02. However, based on the suggestion from Eric and others,=20 it's an optional function, because it will be a heavy cost to = savi-switches, especially low end access switches. For alternative 2, it needs the upstream router to know the host's = address bound at the rebooted switches so that the router can send the = NS, right? thanks, Jun Bi From: John Kaippallimalil=20 Sent: Monday, March 22, 2010 10:40 AM To: 'Bi Jun' ; savi@ietf.org=20 Subject: savi-dhcp-02, state restoration Hi Jun, In savi-dhcp-02 section 21 (State Restoration), the suggestion is to = store state bindings in non volatile memory. One concern is that = non-volatile memory is not typically write efficient.=20 =20 Two alternative solutions: Alternative 1:=20 Use the DHCPLEASEQUERY mechanism to rebuild state. Some details for IPv6 = below: - when switch recovers, it has lost all session state (could stop = filtering till SAVi state is rebuilt) - Switch sends bulk DHCPLEASEQUERY (query by relay id) - RFC5460.=20 - DHCP server replies with DHCP entries related to that relay - = used to rebuild binding state. However, this alternative requires that the SAVI switch to be a DHCP = Relay, and also support TCP (bulk query transport).=20 =20 Alternative 2: - Upstream router detects SAVi switch failure (and recovery). Example = 802.1ag messages. - Upon switch recovery, the router sends Neighbor Solicitation, = replied by host with NA. (similar to NUD?) - This is used to rebuild binding state in SAVI switch. This method does not require the switch to be a DHCP relay. However it = requires 802.1ag support in the network. =20 Regards, John =20 ------=_NextPart_000_0951_01CACA73.56548570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi John,
 
Thank you very much for your = suggestion.
 
For alternative 1, it is already added into = the section=20 22 of savi-dhcp-02. However, based on the suggestion from Eric and = others,=20
it's an optional function, because it will be = a heavy=20 cost to savi-switches, especially low end access switches.
 
For alternative 2,  it needs the upstream = router to=20 know the host's address bound at the rebooted switches so that the = router can=20 send the NS, right?
 
thanks,
Jun Bi

From: John Kaippallimalil
Sent: Monday, March 22, 2010 10:40 AM
To: 'Bi Jun' ; savi@ietf.org
Subject: savi-dhcp-02, state restoration

Hi=20 Jun,

In savi-dhcp-02 = section 21=20 (State Restoration), the suggestion is to store state bindings in non = volatile=20 memory. One concern is that non-volatile memory is not typically write=20 efficient.

 

Two alternative=20 solutions:

Alternative 1:=20

Use the = DHCPLEASEQUERY=20 mechanism to rebuild state. Some details for IPv6=20 below:

-     =20 when switch = recovers, it has=20 lost all session state (could stop filtering till SAVi state is=20 rebuilt)

-     =20 Switch sends bulk=20 DHCPLEASEQUERY (query by relay id) =96 RFC5460. =

-     =20 DHCP server = replies with=20 DHCP entries related to that relay =96 used to rebuild binding=20 state.

However, this = alternative=20 requires that the SAVI switch to be a DHCP Relay, and also support TCP = (bulk=20 query transport).

 

Alternative = 2:
- Upstream=20 router detects SAVi switch failure (and recovery). Example 802.1ag=20 messages.

-     =20 Upon switch = recovery, the=20 router sends Neighbor Solicitation, replied by host with NA. (similar to = NUD?)

-     =20 This is used to = rebuild=20 binding state in SAVI switch.

This method does = not require=20 the switch to be a DHCP relay. However it requires 802.1ag support in = the=20 network.

 

Regards,

John

 

------=_NextPart_000_0951_01CACA73.56548570-- From junbi@cernet.edu.cn Tue Mar 23 10:52:09 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21AA73A6D3C for ; Tue, 23 Mar 2010 10:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQw6IDb9cyHU for ; Tue, 23 Mar 2010 10:52:04 -0700 (PDT) Received: from hiltonsmtp.worldspice.net (hiltonsmtp.worldspice.net [216.37.94.58]) by core3.amsl.com (Postfix) with ESMTP id 766A43A6D40 for ; Tue, 23 Mar 2010 10:52:04 -0700 (PDT) Received: (qmail 9024 invoked by uid 0); 23 Mar 2010 17:52:22 -0000 Received: by simscan 1.4.0 ppid: 8308, pid: 8737, t: 5.1800s scanners: clamav: 0.94.1/m:50/d:9101 spam: 3.2.5 Received: from unknown (HELO junbiVAIO) (junbi@207.88.181.2) by hiltoncluster01.worldspice.net with ESMTPA; 23 Mar 2010 17:52:17 -0000 Message-ID: From: "Bi Jun" To: "Frank Xia" , "'John Kaippallimalil'" , References: <6412E96588564673837A92CF0927BB64@china.huawei.com> <114BC39FA8E1409CB4EEB720D3739925@junbiVAIO> <00b401cacab0$1b408af0$a6188182@china.huawei.com> In-Reply-To: <00b401cacab0$1b408af0$a6188182@china.huawei.com> Date: Tue, 23 Mar 2010 10:52:16 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A53_01CACA76.E74E71F0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Subject: Re: [savi] savi-dhcp-02, state restoration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:52:09 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0A53_01CACA76.E74E71F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You meant, by the Neighbor table/ARP table of that router (then the = router should be the first layer 3 hop in the subnet). Right. One concern is that the host could spoof the NA and reply. From: Frank Xia=20 Sent: Tuesday, March 23, 2010 10:41 AM To: 'Bi Jun' ; 'John Kaippallimalil' ; savi@ietf.org=20 Subject: RE: [savi] savi-dhcp-02, state restoration Hi Bi =20 Sorry for my jumping in.=20 =20 Please see my quick response. =20 BR Frank =20 -------------------------------------------------------------------------= ------- From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of = Bi Jun Sent: Tuesday, March 23, 2010 12:27 PM To: John Kaippallimalil; savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration =20 Hi John, =20 Thank you very much for your suggestion. =20 For alternative 1, it is already added into the section 22 of = savi-dhcp-02. However, based on the suggestion from Eric and others,=20 it's an optional function, because it will be a heavy cost to = savi-switches, especially low end access switches. =20 For alternative 2, it needs the upstream router to know the host's = address bound at the rebooted switches so that the router can send the = NS, right? Frank=3D>Yes. The router already has full information about L2&L3=20 information of the host, and the interface(port) that the host is = connected. =20 =20 thanks, Jun Bi =20 From: John Kaippallimalil=20 Sent: Monday, March 22, 2010 10:40 AM To: 'Bi Jun' ; savi@ietf.org=20 Subject: savi-dhcp-02, state restoration =20 Hi Jun, In savi-dhcp-02 section 21 (State Restoration), the suggestion is to = store state bindings in non volatile memory. One concern is that = non-volatile memory is not typically write efficient.=20 =20 Two alternative solutions: Alternative 1:=20 Use the DHCPLEASEQUERY mechanism to rebuild state. Some details for IPv6 = below: - when switch recovers, it has lost all session state (could stop = filtering till SAVi state is rebuilt) - Switch sends bulk DHCPLEASEQUERY (query by relay id) - RFC5460.=20 - DHCP server replies with DHCP entries related to that relay - = used to rebuild binding state. However, this alternative requires that the SAVI switch to be a DHCP = Relay, and also support TCP (bulk query transport).=20 =20 Alternative 2: - Upstream router detects SAVi switch failure (and recovery). Example = 802.1ag messages. - Upon switch recovery, the router sends Neighbor Solicitation, = replied by host with NA. (similar to NUD?) - This is used to rebuild binding state in SAVI switch. This method does not require the switch to be a DHCP relay. However it = requires 802.1ag support in the network. =20 Regards, John =20 ------=_NextPart_000_0A53_01CACA76.E74E71F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You meant, by the Neighbor table/ARP table of = that=20 router (then the router should be the first layer 3 hop in the=20 subnet).
 
Right. One concern is that the host could = spoof the NA=20 and reply.
 
 

From: Frank Xia
Sent: Tuesday, March 23, 2010 10:41 AM
To: 'Bi Jun' ; 'John Kaippallimalil' ; savi@ietf.org =
Subject: RE: [savi] savi-dhcp-02, state=20 restoration

Hi=20 Bi

 

Sorry for my=20 jumping in.

 

Please see my=20 quick response.

 

BR

Frank

 

From: savi-bounces@ietf.org=20 [mailto:savi-bounces@ietf.org] On = Behalf Of=20 Bi Jun
Sent:=20 Tuesday, March 23, 2010 12:27 PM
To: John Kaippallimalil; savi@ietf.org
Subject: Re: [savi] savi-dhcp-02, = state=20 restoration

 

Hi John,

 

Thank you = very much for=20 your suggestion.

 

For = alternative 1, it=20 is already added into the section 22 of savi-dhcp-02. However, based on = the=20 suggestion from Eric and others,

it's an = optional=20 function, because it will be a heavy cost to savi-switches, especially = low end=20 access switches.

 

For = alternative=20 2,  it needs the upstream router to know the host's address bound = at the=20 rebooted switches so that the router can send the NS, = right?

Frank=3D>Yes. The = router=20 already has full information about L2&L3 =

information of the = host, and the=20 interface(port) that the host is connected. =20

 

thanks,

Jun=20 Bi

 

From: John Kaippallimalil=20

Sent: Monday, = March 22, 2010=20 10:40 AM

To: 'Bi = Jun' ; savi@ietf.org=20

Subject: = savi-dhcp-02, state=20 restoration

 

Hi=20 Jun,

In = savi-dhcp-02=20 section 21 (State Restoration), the suggestion is to store state = bindings in non=20 volatile memory. One concern is that non-volatile memory is not = typically write=20 efficient.

 

Two = alternative=20 solutions:

Alternative 1:=20

Use = the=20 DHCPLEASEQUERY mechanism to rebuild state. Some details for IPv6=20 below:

-      =20 when = switch=20 recovers, it has lost all session state (could stop filtering till SAVi = state is=20 rebuilt)

-      =20 Switch sends bulk=20 DHCPLEASEQUERY (query by relay id) =96 RFC5460. =

-      =20 DHCP = server=20 replies with DHCP entries related to that relay =96 used to rebuild = binding=20 state.

However, this=20 alternative requires that the SAVI switch to be a DHCP Relay, and also = support=20 TCP (bulk query transport).

 

Alternative=20 2:
- Upstream router detects SAVi switch failure (and recovery). = Example=20 802.1ag messages.

-      =20 Upon = switch=20 recovery, the router sends Neighbor Solicitation, replied by host with = NA.=20 (similar to NUD?)

-      =20 This = is used to=20 rebuild binding state in SAVI switch.

This = method does=20 not require the switch to be a DHCP relay. However it requires 802.1ag = support=20 in the network.

 

Regards,

John

 

------=_NextPart_000_0A53_01CACA76.E74E71F0-- From jkaippal@huawei.com Tue Mar 23 10:55:12 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4451D3A6BFD for ; Tue, 23 Mar 2010 10:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw3IWqU-h3yB for ; Tue, 23 Mar 2010 10:55:07 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 71E0F3A686C for ; Tue, 23 Mar 2010 10:55:07 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZQ00BC3XSEDN@usaga03-in.huawei.com> for savi@ietf.org; Tue, 23 Mar 2010 12:55:26 -0500 (CDT) Received: from k7364702 (dhcp-wireless-open-abg-24-72.meeting.ietf.org [130.129.24.72]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZQ0015UXSDVU@usaga03-in.huawei.com> for savi@ietf.org; Tue, 23 Mar 2010 12:55:26 -0500 (CDT) Date: Tue, 23 Mar 2010 12:55:20 -0500 From: John Kaippallimalil In-reply-to: <114BC39FA8E1409CB4EEB720D3739925@junbiVAIO> To: 'Bi Jun' , savi@ietf.org Message-id: <8876324F47E045949D7A9F5EE8CFA10A@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_esJfEEbDw40ZrrplG/d/Nw)" Thread-index: AcrKrhw3B+0LuvqjQPadPA5u2j5a8QAATUuQ Subject: Re: [savi] savi-dhcp-02, state restoration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:55:12 -0000 This is a multi-part message in MIME format. --Boundary_(ID_esJfEEbDw40ZrrplG/d/Nw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Jun, That is correct: the upstream router would need to know the host's address bound at the rebooted switch. Regarding alternative 1, the suggestion is about 'bulk' DHCPLEASEQUERY using TCP. But I agree that it would require the switch to be a DHCP Relay (and TCP connections) - a heavy cost to low end switches. Regards, John _____ From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Bi Jun Sent: Tuesday, March 23, 2010 12:27 PM To: John Kaippallimalil; savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration Hi John, Thank you very much for your suggestion. For alternative 1, it is already added into the section 22 of savi-dhcp-02. However, based on the suggestion from Eric and others, it's an optional function, because it will be a heavy cost to savi-switches, especially low end access switches. For alternative 2, it needs the upstream router to know the host's address bound at the rebooted switches so that the router can send the NS, right? thanks, Jun Bi From: John Kaippallimalil Sent: Monday, March 22, 2010 10:40 AM To: 'Bi Jun' ; savi@ietf.org Subject: savi-dhcp-02, state restoration Hi Jun, In savi-dhcp-02 section 21 (State Restoration), the suggestion is to store state bindings in non volatile memory. One concern is that non-volatile memory is not typically write efficient. Two alternative solutions: Alternative 1: Use the DHCPLEASEQUERY mechanism to rebuild state. Some details for IPv6 below: - when switch recovers, it has lost all session state (could stop filtering till SAVi state is rebuilt) - Switch sends bulk DHCPLEASEQUERY (query by relay id) - RFC5460. - DHCP server replies with DHCP entries related to that relay - used to rebuild binding state. However, this alternative requires that the SAVI switch to be a DHCP Relay, and also support TCP (bulk query transport). Alternative 2: - Upstream router detects SAVi switch failure (and recovery). Example 802.1ag messages. - Upon switch recovery, the router sends Neighbor Solicitation, replied by host with NA. (similar to NUD?) - This is used to rebuild binding state in SAVI switch. This method does not require the switch to be a DHCP relay. However it requires 802.1ag support in the network. Regards, John --Boundary_(ID_esJfEEbDw40ZrrplG/d/Nw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = Jun,

That is = correct: the upstream router would need to know the host’s address bound at = the rebooted switch.

 

Regarding alternative 1, the suggestion is about ‘bulk’ DHCPLEASEQUERY = using TCP. But I agree that it would require the switch to be a DHCP Relay = (and TCP connections) – a heavy cost to low end = switches.

 

Regards,

John

 

 

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Bi Jun
Sent: Tuesday, March 23, = 2010 12:27 PM
To: John Kaippallimalil; = savi@ietf.org
Subject: Re: [savi] = savi-dhcp-02, state restoration

 

Hi John,

 

Thank you very much for your = suggestion.

 

For alternative 1, it is already added into the = section 22 of savi-dhcp-02. However, based on the suggestion from Eric and others, =

it's an optional function, because it will be a = heavy cost to savi-switches, especially low end access = switches.

 

For alternative 2,  it needs the upstream = router to know the host's address bound at the rebooted switches so that the = router can send the NS, right?

 

thanks,

Jun Bi

 

Sent: Monday, March 22, 2010 10:40 AM

Subject: savi-dhcp-02, state restoration

 

Hi Jun,

In savi-dhcp-02 section 21 (State = Restoration), the suggestion is to store state bindings in non volatile memory. One = concern is that non-volatile memory is not typically write efficient. =

 

Two alternative = solutions:

Alternative 1:

Use the DHCPLEASEQUERY mechanism to rebuild = state. Some details for IPv6 below:

-      = when switch recovers, it has lost all session state (could stop filtering = till SAVi state is rebuilt)

-      = Switch sends bulk DHCPLEASEQUERY (query by relay id) – RFC5460. =

-      = DHCP server replies with DHCP entries related to that relay – used to = rebuild binding state.

However, this alternative requires that the = SAVI switch to be a DHCP Relay, and also support TCP (bulk query transport). =

 

Alternative 2:
- Upstream router detects SAVi switch failure (and recovery). Example = 802.1ag messages.

-      = Upon switch recovery, the router sends Neighbor Solicitation, replied by host = with NA. (similar to NUD?)

-      = This is used to rebuild binding state in SAVI = switch.

This method does not require the switch to be = a DHCP relay. However it requires 802.1ag support in the = network.

 

Regards,

John

 

--Boundary_(ID_esJfEEbDw40ZrrplG/d/Nw)-- From xiayangsong@huawei.com Tue Mar 23 11:10:09 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD833A6C9D for ; Tue, 23 Mar 2010 11:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.121 X-Spam-Level: *** X-Spam-Status: No, score=3.121 tagged_above=-999 required=5 tests=[AWL=1.989, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRZEfn7KhQcq for ; Tue, 23 Mar 2010 11:10:03 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 6C6D93A6C41 for ; Tue, 23 Mar 2010 11:09:58 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZQ00GZQYH35H@szxga02-in.huawei.com> for savi@ietf.org; Wed, 24 Mar 2010 02:10:16 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZQ00I4TYH3CH@szxga02-in.huawei.com> for savi@ietf.org; Wed, 24 Mar 2010 02:10:15 +0800 (CST) Received: from X24512z (dhcp-wireless-open-abg-24-166.meeting.ietf.org [130.129.24.166]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZQ00EYFYGUDQ@szxml01-in.huawei.com>; Wed, 24 Mar 2010 02:10:15 +0800 (CST) Date: Tue, 23 Mar 2010 13:10:03 -0500 From: Frank Xia In-reply-to: To: 'Bi Jun' , 'John Kaippallimalil' , savi@ietf.org Message-id: <00e001cacab4$11195f80$a6188182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_ndBDWfY2oU1KjYDwgXDWOA)" Thread-index: AcrKsaFwPq6jsWmdTJekyVL/zWNVwAAAaXGg References: <6412E96588564673837A92CF0927BB64@china.huawei.com> <114BC39FA8E1409CB4EEB720D3739925@junbiVAIO> <00b401cacab0$1b408af0$a6188182@china.huawei.com> Subject: Re: [savi] savi-dhcp-02, state restoration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:10:09 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ndBDWfY2oU1KjYDwgXDWOA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Bi I am not sure what "spoof the NA" exactly means. ND messages always exchange between the host and the router. Switch failure is only a trigger for the router to send a NS message. IMHO, there is no any extra security issue introduced. BR Frank _____ From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Bi Jun Sent: Tuesday, March 23, 2010 12:52 PM To: Frank Xia; 'John Kaippallimalil'; savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration You meant, by the Neighbor table/ARP table of that router (then the router should be the first layer 3 hop in the subnet). Right. One concern is that the host could spoof the NA and reply. From: Frank Xia Sent: Tuesday, March 23, 2010 10:41 AM To: 'Bi Jun' ; 'John Kaippallimalil' ; savi@ietf.org Subject: RE: [savi] savi-dhcp-02, state restoration Hi Bi Sorry for my jumping in. Please see my quick response. BR Frank _____ From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Bi Jun Sent: Tuesday, March 23, 2010 12:27 PM To: John Kaippallimalil; savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration Hi John, Thank you very much for your suggestion. For alternative 1, it is already added into the section 22 of savi-dhcp-02. However, based on the suggestion from Eric and others, it's an optional function, because it will be a heavy cost to savi-switches, especially low end access switches. For alternative 2, it needs the upstream router to know the host's address bound at the rebooted switches so that the router can send the NS, right? Frank=>Yes. The router already has full information about L2&L3 information of the host, and the interface(port) that the host is connected. thanks, Jun Bi From: John Kaippallimalil Sent: Monday, March 22, 2010 10:40 AM To: 'Bi Jun' ; savi@ietf.org Subject: savi-dhcp-02, state restoration Hi Jun, In savi-dhcp-02 section 21 (State Restoration), the suggestion is to store state bindings in non volatile memory. One concern is that non-volatile memory is not typically write efficient. Two alternative solutions: Alternative 1: Use the DHCPLEASEQUERY mechanism to rebuild state. Some details for IPv6 below: - when switch recovers, it has lost all session state (could stop filtering till SAVi state is rebuilt) - Switch sends bulk DHCPLEASEQUERY (query by relay id) - RFC5460. - DHCP server replies with DHCP entries related to that relay - used to rebuild binding state. However, this alternative requires that the SAVI switch to be a DHCP Relay, and also support TCP (bulk query transport). Alternative 2: - Upstream router detects SAVi switch failure (and recovery). Example 802.1ag messages. - Upon switch recovery, the router sends Neighbor Solicitation, replied by host with NA. (similar to NUD?) - This is used to rebuild binding state in SAVI switch. This method does not require the switch to be a DHCP relay. However it requires 802.1ag support in the network. Regards, John --Boundary_(ID_ndBDWfY2oU1KjYDwgXDWOA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = Bi

 <= /span>

I am not sure = what  “spoof the NA” exactly means.

 <= /span>

ND messages = always exchange between the host and the router.

Switch failure is = only a trigger for the router to send a NS = message.

IMHO, there is no = any extra security issue introduced.

 <= /span>

BR

Frank

 <= /span>

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Bi Jun
Sent: Tuesday, March 23, = 2010 12:52 PM
To: Frank Xia; 'John Kaippallimalil'; savi@ietf.org
Subject: Re: [savi] = savi-dhcp-02, state restoration

 

You meant, by the Neighbor table/ARP table = of that router (then the router should be the first layer 3 hop in the = subnet).

 

Right. One concern is that the host could = spoof the NA and reply.

 

 

 

From: Frank Xia

Sent: Tuesday, March 23, 2010 10:41 AM

Subject: RE: [savi] savi-dhcp-02, state restoration

 

Hi = Bi

 <= /span>

Sorry for my = jumping in.

 <= /span>

Please see my = quick response.

 <= /span>

BR

Frank

 <= /span>

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On = Behalf Of Bi Jun
Sent: Tuesday, March 23, = 2010 12:27 PM
To: John Kaippallimalil; = savi@ietf.org
Subject: Re: [savi] = savi-dhcp-02, state restoration

 

Hi John,

 

Thank you very much for your = suggestion.

 

For alternative 1, it is already added into = the section 22 of savi-dhcp-02. However, based on the suggestion from Eric = and others,

it's an optional function, because it will = be a heavy cost to savi-switches, especially low end access = switches.

 

For alternative 2,  it needs the = upstream router to know the host's address bound at the rebooted switches so that = the router can send the NS, right?

Frank=3D>Yes. The = router already has full information about L2&L3 =

information of the = host, and the interface(port) that the host is connected.  =

 <= /span>

thanks,

Jun Bi

 

Sent: Monday, March 22, 2010 10:40 AM

Subject: savi-dhcp-02, state restoration

 

Hi = Jun,

In savi-dhcp-02 = section 21 (State Restoration), the suggestion is to store state bindings in non = volatile memory. One concern is that non-volatile memory is not typically write efficient.

 

Two alternative = solutions:

Alternative 1: =

Use the = DHCPLEASEQUERY mechanism to rebuild state. Some details for IPv6 = below:

-       when = switch recovers, it has lost all session state (could stop filtering till SAVi = state is rebuilt)

-       Switch = sends bulk DHCPLEASEQUERY (query by relay id) – RFC5460. =

-       DHCP = server replies with DHCP entries related to that relay – used to rebuild = binding state.

However, this = alternative requires that the SAVI switch to be a DHCP Relay, and also support TCP = (bulk query transport).

 

Alternative 2:
- Upstream router detects SAVi switch failure (and recovery). Example = 802.1ag messages.

-       Upon = switch recovery, the router sends Neighbor Solicitation, replied by host with = NA. (similar to NUD?)

-       This = is used to rebuild binding state in SAVI switch.

This method does = not require the switch to be a DHCP relay. However it requires 802.1ag support in = the network.

 

Regards,

John

 

--Boundary_(ID_ndBDWfY2oU1KjYDwgXDWOA)-- From jkaippal@huawei.com Tue Mar 23 11:12:18 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8431C3A6D19 for ; Tue, 23 Mar 2010 11:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j3+fxfmbetQ for ; Tue, 23 Mar 2010 11:12:15 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id C98D83A6D17 for ; Tue, 23 Mar 2010 11:12:14 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZQ00BX2YKYDN@usaga03-in.huawei.com> for savi@ietf.org; Tue, 23 Mar 2010 13:12:34 -0500 (CDT) Received: from k7364702 (dhcp-wireless-open-abg-24-72.meeting.ietf.org [130.129.24.72]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZQ001J0YKWVU@usaga03-in.huawei.com> for savi@ietf.org; Tue, 23 Mar 2010 13:12:33 -0500 (CDT) Date: Tue, 23 Mar 2010 13:12:26 -0500 From: John Kaippallimalil In-reply-to: To: 'Bi Jun' , 'Frank Xia' , savi@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_OlssK7At0yKmsFckEgxqZA)" Thread-index: AcrKscgu9WqlPVu6RZmWvCi39NcO6wAAdekg Subject: Re: [savi] savi-dhcp-02, state restoration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:12:18 -0000 This is a multi-part message in MIME format. --Boundary_(ID_OlssK7At0yKmsFckEgxqZA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Please see inline >> _____ From: Bi Jun [mailto:junbi@cernet.edu.cn] Sent: Tuesday, March 23, 2010 12:52 PM To: Frank Xia; 'John Kaippallimalil'; savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration You meant, by the Neighbor table/ARP table of that router (then the router should be the first layer 3 hop in the subnet). Right. One concern is that the host could spoof the NA and reply. >> The NS message from router --> host is unicast. Host replies with NS, and both these messages are forwarded by the switch (and used to update the binding table). Spoofing by the host would probably not be an issue in that case? From: Frank Xia Sent: Tuesday, March 23, 2010 10:41 AM To: 'Bi Jun' ; 'John Kaippallimalil' ; savi@ietf.org Subject: RE: [savi] savi-dhcp-02, state restoration Hi Bi Sorry for my jumping in. Please see my quick response. BR Frank _____ From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Bi Jun Sent: Tuesday, March 23, 2010 12:27 PM To: John Kaippallimalil; savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration Hi John, Thank you very much for your suggestion. For alternative 1, it is already added into the section 22 of savi-dhcp-02. However, based on the suggestion from Eric and others, it's an optional function, because it will be a heavy cost to savi-switches, especially low end access switches. For alternative 2, it needs the upstream router to know the host's address bound at the rebooted switches so that the router can send the NS, right? Frank=>Yes. The router already has full information about L2&L3 information of the host, and the interface(port) that the host is connected. thanks, Jun Bi From: John Kaippallimalil Sent: Monday, March 22, 2010 10:40 AM To: 'Bi Jun' ; savi@ietf.org Subject: savi-dhcp-02, state restoration Hi Jun, In savi-dhcp-02 section 21 (State Restoration), the suggestion is to store state bindings in non volatile memory. One concern is that non-volatile memory is not typically write efficient. Two alternative solutions: Alternative 1: Use the DHCPLEASEQUERY mechanism to rebuild state. Some details for IPv6 below: - when switch recovers, it has lost all session state (could stop filtering till SAVi state is rebuilt) - Switch sends bulk DHCPLEASEQUERY (query by relay id) - RFC5460. - DHCP server replies with DHCP entries related to that relay - used to rebuild binding state. However, this alternative requires that the SAVI switch to be a DHCP Relay, and also support TCP (bulk query transport). Alternative 2: - Upstream router detects SAVi switch failure (and recovery). Example 802.1ag messages. - Upon switch recovery, the router sends Neighbor Solicitation, replied by host with NA. (similar to NUD?) - This is used to rebuild binding state in SAVI switch. This method does not require the switch to be a DHCP relay. However it requires 802.1ag support in the network. Regards, John --Boundary_(ID_OlssK7At0yKmsFckEgxqZA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Please = see inline >>

 

From: Bi = Jun [mailto:junbi@cernet.edu.cn]
Sent: Tuesday, March 23, = 2010 12:52 PM
To: Frank Xia; 'John Kaippallimalil'; savi@ietf.org
Subject: Re: [savi] = savi-dhcp-02, state restoration

 

You meant, by the Neighbor table/ARP table of that router (then = the router should be the first layer 3 hop in the = subnet).

 

Right. One concern is that the host could spoof the = NA and reply.

 

>> = The NS message from router à host is unicast. Host replies with NS, and = both these messages are forwarded by the switch (and used to update the = binding table).

Spoofing = by the host would probably not be an issue in that = case?

 

 

 

From: Frank Xia

Sent: Tuesday, March 23, 2010 10:41 AM

Subject: RE: [savi] savi-dhcp-02, state restoration

 

Hi Bi

 

Sorry for my jumping in. =

 

Please see my quick = response.

 

BR

Frank

 

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On = Behalf Of Bi Jun
Sent: Tuesday, March 23, = 2010 12:27 PM
To: John Kaippallimalil; = savi@ietf.org
Subject: Re: [savi] = savi-dhcp-02, state restoration

 

Hi John,

 

Thank you very much for your = suggestion.

 

For alternative 1, it is already added into the = section 22 of savi-dhcp-02. However, based on the suggestion from Eric and others, =

it's an optional function, because it will be a = heavy cost to savi-switches, especially low end access = switches.

 

For alternative 2,  it needs the upstream = router to know the host's address bound at the rebooted switches so that the = router can send the NS, right?

Frank=3D>Yes. The router = already has full information about L2&L3

information of the host, and the interface(port) that the host is connected. 

 

thanks,

Jun Bi

 

Sent: Monday, March 22, 2010 10:40 AM

Subject: savi-dhcp-02, state restoration

 

Hi Jun,

In savi-dhcp-02 section 21 (State = Restoration), the suggestion is to store state bindings in non volatile memory. One = concern is that non-volatile memory is not typically write efficient. =

 

Two alternative = solutions:

Alternative 1:

Use the DHCPLEASEQUERY mechanism to rebuild = state. Some details for IPv6 below:

-      = when switch recovers, it has lost all session state (could stop filtering = till SAVi state is rebuilt)

-      = Switch sends bulk DHCPLEASEQUERY (query by relay id) – RFC5460. =

-      = DHCP server replies with DHCP entries related to that relay – used to = rebuild binding state.

However, this alternative requires that the = SAVI switch to be a DHCP Relay, and also support TCP (bulk query transport). =

 

Alternative 2:
- Upstream router detects SAVi switch failure (and recovery). Example = 802.1ag messages.

-      = Upon switch recovery, the router sends Neighbor Solicitation, replied by host = with NA. (similar to NUD?)

-      = This is used to rebuild binding state in SAVI = switch.

This method does not require the switch to be = a DHCP relay. However it requires 802.1ag support in the = network.

 

Regards,

John

 

--Boundary_(ID_OlssK7At0yKmsFckEgxqZA)-- From junbi@cernet.edu.cn Tue Mar 23 11:22:14 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621293A6942 for ; Tue, 23 Mar 2010 11:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.828 X-Spam-Level: *** X-Spam-Status: No, score=3.828 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_HAS_XAIMC=2.696, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cDRBcvP6d56 for ; Tue, 23 Mar 2010 11:22:10 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 2DB963A6C56 for ; Tue, 23 Mar 2010 11:21:44 -0700 (PDT) Received: from junbiVAIO([130.129.30.129]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm04ba9096a; Wed, 24 Mar 2010 02:22:02 +0800 Message-ID: <9DB30C6F422C4C12ADAF960D1C28BC97@junbiVAIO> From: "Bi Jun" To: "John Kaippallimalil" , "'Frank Xia'" , References: In-Reply-To: Date: Tue, 23 Mar 2010 11:21:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B90_01CACA7B.07795220" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: sAqjIuXB Subject: Re: [savi] savi-dhcp-02, state restoration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:22:14 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0B90_01CACA7B.07795220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi John and Frank, read both of your replied emails. I plan to put it into the document. I think it's a light weight solution = because it is triggered by control message (802.1ag). For alternative 1, we understand it is different than section 22, will = consider it as another optional function. Thank you very much for your constructive suggestions. Best Regards, Jun Bi From: John Kaippallimalil=20 Sent: Tuesday, March 23, 2010 11:12 AM To: 'Bi Jun' ; 'Frank Xia' ; savi@ietf.org=20 Subject: Re: [savi] savi-dhcp-02, state restoration Please see inline >> =20 -------------------------------------------------------------------------= ------- From: Bi Jun [mailto:junbi@cernet.edu.cn]=20 Sent: Tuesday, March 23, 2010 12:52 PM To: Frank Xia; 'John Kaippallimalil'; savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration =20 You meant, by the Neighbor table/ARP table of that router (then the = router should be the first layer 3 hop in the subnet). =20 Right. One concern is that the host could spoof the NA and reply. =20 >> The NS message from router =E0 host is unicast. Host replies with NS, = and both these messages are forwarded by the switch (and used to update = the binding table). Spoofing by the host would probably not be an issue in that case? =20 =20 =20 From: Frank Xia=20 Sent: Tuesday, March 23, 2010 10:41 AM To: 'Bi Jun' ; 'John Kaippallimalil' ; savi@ietf.org=20 Subject: RE: [savi] savi-dhcp-02, state restoration =20 Hi Bi =20 Sorry for my jumping in.=20 =20 Please see my quick response. =20 BR Frank =20 -------------------------------------------------------------------------= ------- From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of = Bi Jun Sent: Tuesday, March 23, 2010 12:27 PM To: John Kaippallimalil; savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration =20 Hi John, =20 Thank you very much for your suggestion. =20 For alternative 1, it is already added into the section 22 of = savi-dhcp-02. However, based on the suggestion from Eric and others,=20 it's an optional function, because it will be a heavy cost to = savi-switches, especially low end access switches. =20 For alternative 2, it needs the upstream router to know the host's = address bound at the rebooted switches so that the router can send the = NS, right? Frank=3D>Yes. The router already has full information about L2&L3=20 information of the host, and the interface(port) that the host is = connected. =20 =20 thanks, Jun Bi =20 From: John Kaippallimalil=20 Sent: Monday, March 22, 2010 10:40 AM To: 'Bi Jun' ; savi@ietf.org=20 Subject: savi-dhcp-02, state restoration =20 Hi Jun, In savi-dhcp-02 section 21 (State Restoration), the suggestion is to = store state bindings in non volatile memory. One concern is that = non-volatile memory is not typically write efficient.=20 =20 Two alternative solutions: Alternative 1:=20 Use the DHCPLEASEQUERY mechanism to rebuild state. Some details for IPv6 = below: - when switch recovers, it has lost all session state (could stop = filtering till SAVi state is rebuilt) - Switch sends bulk DHCPLEASEQUERY (query by relay id) - RFC5460.=20 - DHCP server replies with DHCP entries related to that relay - = used to rebuild binding state. However, this alternative requires that the SAVI switch to be a DHCP = Relay, and also support TCP (bulk query transport).=20 =20 Alternative 2: - Upstream router detects SAVi switch failure (and recovery). Example = 802.1ag messages. - Upon switch recovery, the router sends Neighbor Solicitation, = replied by host with NA. (similar to NUD?) - This is used to rebuild binding state in SAVI switch. This method does not require the switch to be a DHCP relay. However it = requires 802.1ag support in the network. =20 Regards, John =20 -------------------------------------------------------------------------= ------- _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi ------=_NextPart_000_0B90_01CACA7B.07795220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi John and Frank,
 
read both of your replied emails.
I plan to put it into the document. I think = it's a light=20 weight solution because it is triggered by control message=20 (802.1ag).
 
For alternative 1, we understand it is = different than=20 section 22, will consider it as another optional function.
 
Thank you very much for your constructive=20 suggestions.
 
Best Regards,
Jun Bi

Sent: Tuesday, March 23, 2010 11:12 AM
Subject: Re: [savi] savi-dhcp-02, state=20 restoration

Please see=20 inline >>

 

From: Bi Jun=20 [mailto:junbi@cernet.edu.cn]
Sent: Tuesday, March 23, 2010 = 12:52=20 PM
To: Frank Xia; = 'John=20 Kaippallimalil'; savi@ietf.org
Subject: Re: [savi] savi-dhcp-02, = state=20 restoration

 

You meant, by the Neighbor table/ARP = table of that=20 router (then the router should be the first layer 3 hop in the=20 subnet).

 

Right. One concern is = that the=20 host could spoof the NA and reply.

 

>> The NS=20 message from router =E0 host = is=20 unicast. Host replies with NS, and both these messages are forwarded by = the=20 switch (and used to update the binding = table).

Spoofing by the=20 host would probably not be an issue in that=20 case?

 

 

 

From: Frank Xia=20

Sent: Tuesday,=20 March 23, 2010 10:41 AM

To: 'Bi = Jun' ; 'John=20 Kaippallimalil' ; savi@ietf.org=20

Subject: RE:=20 [savi] savi-dhcp-02, state=20 restoration

 

Hi=20 Bi

 

Sorry for my = jumping in.=20

 

Please see my = quick=20 response.

 

BR

Frank

 

From: savi-bounces@ietf.org=20 [mailto:savi-bounces@ietf.org] On = Behalf Of=20 Bi Jun
Sent:=20 Tuesday, March 23, 2010 12:27 PM
To: John Kaippallimalil; savi@ietf.org
Subject: Re: [savi] savi-dhcp-02, = state=20 restoration

 

Hi=20 John,

 

Thank you very much for = your=20 suggestion.

 

For alternative 1, it is = already=20 added into the section 22 of savi-dhcp-02. However, based on the = suggestion from=20 Eric and others,

it's an optional = function, because=20 it will be a heavy cost to savi-switches, especially low end access=20 switches.

 

For alternative 2,  = it needs=20 the upstream router to know the host's address bound at the rebooted = switches so=20 that the router can send the NS, = right?

Frank=3D>Yes. The router = already has full=20 information about L2&L3

information of the host, and the=20 interface(port) that the host is connected. 

 

thanks,

Jun=20 Bi

 

From: John Kaippallimalil=20

Sent: Monday,=20 March 22, 2010 10:40 AM

To: 'Bi = Jun' ; savi@ietf.org=20

Subject:=20 savi-dhcp-02, state = restoration

 

Hi=20 Jun,

In savi-dhcp-02 = section 21=20 (State Restoration), the suggestion is to store state bindings in non = volatile=20 memory. One concern is that non-volatile memory is not typically write=20 efficient.

 

Two alternative=20 solutions:

Alternative 1:=20

Use the = DHCPLEASEQUERY=20 mechanism to rebuild state. Some details for IPv6=20 below:

-     =20 when switch = recovers, it has=20 lost all session state (could stop filtering till SAVi state is=20 rebuilt)

-     =20 Switch sends bulk=20 DHCPLEASEQUERY (query by relay id) =96 RFC5460. =

-     =20 DHCP server = replies with=20 DHCP entries related to that relay =96 used to rebuild binding=20 state.

However, this = alternative=20 requires that the SAVI switch to be a DHCP Relay, and also support TCP = (bulk=20 query transport).

 

Alternative = 2:
- Upstream=20 router detects SAVi switch failure (and recovery). Example 802.1ag=20 messages.

-     =20 Upon switch = recovery, the=20 router sends Neighbor Solicitation, replied by host with NA. (similar to = NUD?)

-     =20 This is used to = rebuild=20 binding state in SAVI switch.

This method does = not require=20 the switch to be a DHCP relay. However it requires 802.1ag support in = the=20 network.

 

Regards,

John

 

_______________________________________________
savi mailing=20 list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi
------=_NextPart_000_0B90_01CACA7B.07795220-- From yaoa02@mails.tsinghua.edu.cn Tue Mar 23 11:36:46 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8973A6D33 for ; Tue, 23 Mar 2010 11:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.732 X-Spam-Level: * X-Spam-Status: No, score=1.732 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuSACO2zefWg for ; Tue, 23 Mar 2010 11:36:40 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 284953A6D21 for ; Tue, 23 Mar 2010 11:36:39 -0700 (PDT) Received: from dhcp-wireless-open-abg-27-91.meeting.ietf.org ([130.129.27.91] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1Nu8yD-0005rh-Hg; Wed, 24 Mar 2010 02:36:55 +0800 From: "Guang Yao" To: "'John Kaippallimalil'" References: In-Reply-To: Date: Wed, 24 Mar 2010 02:36:42 +0800 Message-ID: <00c301cacab7$cafa2ee0$60ee8ca0$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C4_01CACAFA.D91D6EE0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrKscgu9WqlPVu6RZmWvCi39NcO6wAAdekgAABEQaA= Content-Language: zh-cn Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:36:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C4_01CACAFA.D91D6EE0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable A possible vulnerability is that a malicious node may try to pollute the = ND table of the router through spoofed IP before(or during) this process. =20 Maybe the ND table should be locked until this process is finished. =20 And it seems the SAVI device loses independence? =20 From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of = John Kaippallimalil Sent: Wednesday, March 24, 2010 2:12 AM To: 'Bi Jun'; 'Frank Xia'; savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration =20 Please see inline >> =20 _____ =20 From: Bi Jun [mailto:junbi@cernet.edu.cn]=20 Sent: Tuesday, March 23, 2010 12:52 PM To: Frank Xia; 'John Kaippallimalil'; savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration =20 You meant, by the Neighbor table/ARP table of that router (then the = router should be the first layer 3 hop in the subnet). =20 Right. One concern is that the host could spoof the NA and reply. =20 >> The NS message from router =E0 host is unicast. Host replies with NS, = and both these messages are forwarded by the switch (and used to update the binding table). Spoofing by the host would probably not be an issue in that case? =20 =20 =20 From: Frank Xia =20 Sent: Tuesday, March 23, 2010 10:41 AM To: 'Bi Jun' ; 'John Kaippallimalil' ; savi@ietf.org=20 Subject: RE: [savi] savi-dhcp-02, state restoration =20 Hi Bi =20 Sorry for my jumping in.=20 =20 Please see my quick response. =20 BR Frank =20 _____ =20 From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of = Bi Jun Sent: Tuesday, March 23, 2010 12:27 PM To: John Kaippallimalil; savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration =20 Hi John, =20 Thank you very much for your suggestion. =20 For alternative 1, it is already added into the section 22 of = savi-dhcp-02. However, based on the suggestion from Eric and others,=20 it's an optional function, because it will be a heavy cost to = savi-switches, especially low end access switches. =20 For alternative 2, it needs the upstream router to know the host's = address bound at the rebooted switches so that the router can send the NS, = right? Frank=3D>Yes. The router already has full information about L2&L3=20 information of the host, and the interface(port) that the host is = connected. =20 thanks, Jun Bi =20 From: John Kaippallimalil=20 Sent: Monday, March 22, 2010 10:40 AM To: 'Bi Jun' ; savi@ietf.org=20 Subject: savi-dhcp-02, state restoration =20 Hi Jun, In savi-dhcp-02 section 21 (State Restoration), the suggestion is to = store state bindings in non volatile memory. One concern is that non-volatile memory is not typically write efficient.=20 =20 Two alternative solutions: Alternative 1:=20 Use the DHCPLEASEQUERY mechanism to rebuild state. Some details for IPv6 below: - when switch recovers, it has lost all session state (could stop = filtering till SAVi state is rebuilt) - Switch sends bulk DHCPLEASEQUERY (query by relay id) =96 RFC5460.=20 - DHCP server replies with DHCP entries related to that relay =96 used = to rebuild binding state. However, this alternative requires that the SAVI switch to be a DHCP = Relay, and also support TCP (bulk query transport).=20 =20 Alternative 2: - Upstream router detects SAVi switch failure (and recovery). Example 802.1ag messages. - Upon switch recovery, the router sends Neighbor Solicitation, replied = by host with NA. (similar to NUD?) - This is used to rebuild binding state in SAVI switch. This method does not require the switch to be a DHCP relay. However it requires 802.1ag support in the network. =20 Regards, John =20 ------=_NextPart_000_00C4_01CACAFA.D91D6EE0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

A possible vulnerability is that a malicious node may try = to pollute the ND table of the router through spoofed IP before(or during) this = process.

 

Maybe the ND table should be locked until this process is finished.

 

And it seems the SAVI device loses = independence?

 

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of John = Kaippallimalil
Sent: Wednesday, March 24, 2010 2:12 AM
To: 'Bi Jun'; 'Frank Xia'; savi@ietf.org
Subject: Re: [savi] savi-dhcp-02, state = restoration

 

Please see inline >>

 

From: Bi Jun [mailto:junbi@cernet.edu.cn] =
Sent: Tuesday, March 23, 2010 12:52 PM
To: Frank Xia; 'John Kaippallimalil'; savi@ietf.org
Subject: Re: [savi] savi-dhcp-02, state restoration

 

You meant, by the Neighbor table/ARP table of that router (then the router = should be the first layer 3 hop in the subnet).

 

Right. One concern is that the host could spoof the NA and = reply.

 

>> The NS message from router =E0 host is unicast. Host replies with NS, and both these messages are forwarded = by the switch (and used to update the binding table).

Spoofing by the host would probably not be an issue in that = case?

 

 

 <= /o:p>

From:= Frank Xia

Sent:= Tuesday, March 23, 2010 10:41 AM

Subject: RE: [savi] savi-dhcp-02, state restoration

 

Hi Bi

 

Sorry for my jumping in.

 

Please see my quick response.

 

BR

Frank

 

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Bi Jun
Sent: Tuesday, March 23, 2010 12:27 PM
To: John Kaippallimalil; savi@ietf.org
Subject: Re: [savi] savi-dhcp-02, state restoration

 

Hi John,

 

Thank you very much for your suggestion.

 

For alternative 1, it is already added into the section 22 of savi-dhcp-02. However, based on the suggestion from Eric and others,

it's an optional function, because it will be a heavy cost to savi-switches, especially low end access switches.

 

For alternative 2,  it needs the upstream router to know the host's = address bound at the rebooted switches so that the router can send the NS, = right?

Frank=3D>Yes. The router already has full information about L2&L3 =

information = of the host, and the interface(port) that the host is connected. 

 

thanks,

Jun Bi

 <= /o:p>

Sent:= Monday, March 22, 2010 10:40 AM

Subject: savi-dhcp-02, state restoration

 

Hi Jun,

In savi-dhcp-02 section 21 (State Restoration), the suggestion is to store = state bindings in non volatile memory. One concern is that non-volatile memory = is not typically write efficient.

 

Two alternative solutions:

Alternative 1:

Use the DHCPLEASEQUERY mechanism to rebuild state. Some details for IPv6 = below:

-  when = switch recovers, it has lost all session state (could stop filtering till SAVi state is = rebuilt)

-  Switch = sends bulk DHCPLEASEQUERY (query by relay id) – RFC5460. =

-  DHCP = server replies with DHCP entries related to that relay – used to rebuild = binding state.

However, this alternative requires that the SAVI switch to be a DHCP Relay, and = also support TCP (bulk query transport).

 

Alternative 2:
- Upstream router detects SAVi switch failure (and recovery). Example = 802.1ag messages.

-  Upon = switch recovery, the router sends Neighbor Solicitation, replied by host with = NA. (similar to NUD?)

-  This = is used to rebuild binding state in SAVI switch.

This method does not require the switch to be a DHCP relay. However it = requires 802.1ag support in the network.

 

Regards,

John

 

------=_NextPart_000_00C4_01CACAFA.D91D6EE0-- From elevyabe@cisco.com Tue Mar 23 13:38:16 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065FF3A6946 for ; Tue, 23 Mar 2010 13:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.869 X-Spam-Level: X-Spam-Status: No, score=-6.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgKGN-DpLXbW for ; Tue, 23 Mar 2010 13:38:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A0E9D3A6803 for ; Tue, 23 Mar 2010 13:38:14 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgBAIfDqEuQ/uCWe2dsb2JhbACbHxUBAQsLJAYcpWWZG4R9BA X-IronPort-AV: E=Sophos;i="4.51,296,1267401600"; d="scan'208";a="58454592" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Mar 2010 20:38:32 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2NKcWNW000369; Tue, 23 Mar 2010 20:38:33 GMT Received: from xmb-ams-105.cisco.com ([144.254.74.80]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 21:38:32 +0100 Received: from [10.61.82.199] ([10.61.82.199]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 21:38:32 +0100 Message-ID: <4BA926C3.9010008@cisco.com> Date: Tue, 23 Mar 2010 21:38:27 +0100 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: John Kaippallimalil References: <8876324F47E045949D7A9F5EE8CFA10A@china.huawei.com> In-Reply-To: <8876324F47E045949D7A9F5EE8CFA10A@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 23 Mar 2010 20:38:32.0480 (UTC) FILETIME=[CD945200:01CACAC8] Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 20:38:16 -0000 John Kaippallimalil a écrit : > > Hi Jun, > > That is correct: the upstream router would need to know the host’s > address bound at the rebooted switch. > > Regarding alternative 1, the suggestion is about ‘bulk’ DHCPLEASEQUERY > using TCP. But I agree that it would require the switch to be a DHCP > Relay (and TCP connections) – a heavy cost to low end switches. > And for the high ends as well. Not much in terms of capability, but in terms of operation costs. Lots of vlans would have to terminate the layer3 on the box. Eric > > Regards, > > John > > * From: * savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] *On > Behalf Of *Bi Jun > *Sent:* Tuesday, March 23, 2010 12:27 PM > *To:* John Kaippallimalil; savi@ietf.org > *Subject:* Re: [savi] savi-dhcp-02, state restoration > > Hi John, > > Thank you very much for your suggestion. > > For alternative 1, it is already added into the section 22 of > savi-dhcp-02. However, based on the suggestion from Eric and others, > > it's an optional function, because it will be a heavy cost to > savi-switches, especially low end access switches. > > For alternative 2, it needs the upstream router to know the host's > address bound at the rebooted switches so that the router can send the > NS, right? > > thanks, > > Jun Bi > > * From: * John Kaippallimalil > > * Sent: * Monday, March 22, 2010 10:40 AM > > * To: * 'Bi Jun' ; savi@ietf.org > > > * Subject: * savi-dhcp-02, state restoration > > Hi Jun, > > In savi-dhcp-02 section 21 (State Restoration), the suggestion is to > store state bindings in non volatile memory. One concern is that > non-volatile memory is not typically write efficient. > > Two alternative solutions: > > Alternative 1: > > Use the DHCPLEASEQUERY mechanism to rebuild state. Some details for > IPv6 below: > > - when switch recovers, it has lost all session state (could stop > filtering till SAVi state is rebuilt) > > - Switch sends bulk DHCPLEASEQUERY (query by relay id) – RFC5460. > > - DHCP server replies with DHCP entries related to that relay – used > to rebuild binding state. > > However, this alternative requires that the SAVI switch to be a DHCP > Relay, and also support TCP (bulk query transport). > > Alternative 2: > - Upstream router detects SAVi switch failure (and recovery). Example > 802.1ag messages. > > - Upon switch recovery, the router sends Neighbor Solicitation, > replied by host with NA. (similar to NUD?) > > - This is used to rebuild binding state in SAVI switch. > > This method does not require the switch to be a DHCP relay. However it > requires 802.1ag support in the network. > > Regards, > > John > > ------------------------------------------------------------------------ > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jkaippal@huawei.com Tue Mar 23 14:04:28 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F273A695D for ; Tue, 23 Mar 2010 14:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.038 X-Spam-Level: * X-Spam-Status: No, score=1.038 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggEQAZC7m9Zn for ; Tue, 23 Mar 2010 14:04:27 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 020FB3A67F9 for ; Tue, 23 Mar 2010 14:04:27 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZR0047E6JY4Q@usaga01-in.huawei.com> for savi@ietf.org; Tue, 23 Mar 2010 14:04:46 -0700 (PDT) Received: from k7364702 (dhcp-wireless-open-abg-24-72.meeting.ietf.org [130.129.24.72]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZR008SX6JXGD@usaga01-in.huawei.com> for savi@ietf.org; Tue, 23 Mar 2010 14:04:45 -0700 (PDT) Date: Tue, 23 Mar 2010 16:04:39 -0500 From: John Kaippallimalil In-reply-to: <4BA926C3.9010008@cisco.com> To: 'Eric Levy-Abegnoli' Message-id: <8E0B012AE16D4CC0A901AC7A495BB176@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcrKyOi2YqZPSfPNS62/Vb9wXW4M3wAAhyLg Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:04:28 -0000 Hi Eric, Agree about the costs of DHCPLEASEQUERY: DHCP Relay function at switch, = etc. Not clear why the VLANs would be a problem. If VLAN forwarding is used, = it could be stacked, with an S-VLAN between switch and router. Regards, John -----Original Message----- From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of = Eric Levy-Abegnoli Sent: Tuesday, March 23, 2010 3:38 PM To: John Kaippallimalil Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration John Kaippallimalil a =E9crit : > > Hi Jun, > > That is correct: the upstream router would need to know the host=92s=20 > address bound at the rebooted switch. > > Regarding alternative 1, the suggestion is about =91bulk=92 = DHCPLEASEQUERY=20 > using TCP. But I agree that it would require the switch to be a DHCP=20 > Relay (and TCP connections) =96 a heavy cost to low end switches. > And for the high ends as well. Not much in terms of capability, but in=20 terms of operation costs. Lots of vlans would have to terminate the=20 layer3 on the box. Eric > > Regards, > > John > > * From: * savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] *On=20 > Behalf Of *Bi Jun > *Sent:* Tuesday, March 23, 2010 12:27 PM > *To:* John Kaippallimalil; savi@ietf.org > *Subject:* Re: [savi] savi-dhcp-02, state restoration > > Hi John, > > Thank you very much for your suggestion. > > For alternative 1, it is already added into the section 22 of=20 > savi-dhcp-02. However, based on the suggestion from Eric and others, > > it's an optional function, because it will be a heavy cost to=20 > savi-switches, especially low end access switches. > > For alternative 2, it needs the upstream router to know the host's=20 > address bound at the rebooted switches so that the router can send the = > NS, right? > > thanks, > > Jun Bi > > * From: * John Kaippallimalil > > * Sent: * Monday, March 22, 2010 10:40 AM > > * To: * 'Bi Jun' ; savi@ietf.org=20 > > > * Subject: * savi-dhcp-02, state restoration > > Hi Jun, > > In savi-dhcp-02 section 21 (State Restoration), the suggestion is to=20 > store state bindings in non volatile memory. One concern is that=20 > non-volatile memory is not typically write efficient. > > Two alternative solutions: > > Alternative 1: > > Use the DHCPLEASEQUERY mechanism to rebuild state. Some details for=20 > IPv6 below: > > - when switch recovers, it has lost all session state (could stop=20 > filtering till SAVi state is rebuilt) > > - Switch sends bulk DHCPLEASEQUERY (query by relay id) =96 RFC5460. > > - DHCP server replies with DHCP entries related to that relay =96 used = > to rebuild binding state. > > However, this alternative requires that the SAVI switch to be a DHCP=20 > Relay, and also support TCP (bulk query transport). > > Alternative 2: > - Upstream router detects SAVi switch failure (and recovery). Example=20 > 802.1ag messages. > > - Upon switch recovery, the router sends Neighbor Solicitation,=20 > replied by host with NA. (similar to NUD?) > > - This is used to rebuild binding state in SAVI switch. > > This method does not require the switch to be a DHCP relay. However it = > requires 802.1ag support in the network. > > Regards, > > John > > = ------------------------------------------------------------------------ > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > =20 _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From jkaippal@huawei.com Tue Mar 23 14:46:35 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20DAD3A6CE5 for ; Tue, 23 Mar 2010 14:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.401 X-Spam-Level: * X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snY0A1BpR4yB for ; Tue, 23 Mar 2010 14:46:28 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id EEF5D3A6C45 for ; Tue, 23 Mar 2010 14:46:25 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZR004T58HX4Q@usaga01-in.huawei.com> for savi@ietf.org; Tue, 23 Mar 2010 14:46:45 -0700 (PDT) Received: from k7364702 (dhcp-wireless-open-abg-24-72.meeting.ietf.org [130.129.24.72]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZR008W28HVGD@usaga01-in.huawei.com> for savi@ietf.org; Tue, 23 Mar 2010 14:46:45 -0700 (PDT) Date: Tue, 23 Mar 2010 16:46:37 -0500 From: John Kaippallimalil In-reply-to: <00c301cacab7$cafa2ee0$60ee8ca0$@tsinghua.edu.cn> To: 'Guang Yao' Message-id: <3D680C29E02F445284945ACAA2F8D96A@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_wNtejN2GFcYuDqsi57rkYw)" Thread-index: AcrKscgu9WqlPVu6RZmWvCi39NcO6wAAdekgAABEQaAABrylcA== Cc: savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:46:35 -0000 This is a multi-part message in MIME format. --Boundary_(ID_wNtejN2GFcYuDqsi57rkYw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Good point. Especially if we cannot make the assumption that a DHCP relay (or server) is located at the router. Regards, John _____ From: Guang Yao [mailto:yaoa02@mails.tsinghua.edu.cn] Sent: Tuesday, March 23, 2010 1:37 PM To: 'John Kaippallimalil' Cc: savi@ietf.org Subject: RE: [savi] savi-dhcp-02, state restoration A possible vulnerability is that a malicious node may try to pollute the ND table of the router through spoofed IP before(or during) this process. Maybe the ND table should be locked until this process is finished. And it seems the SAVI device loses independence? From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, March 24, 2010 2:12 AM To: 'Bi Jun'; 'Frank Xia'; savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration Please see inline >> _____ From: Bi Jun [mailto:junbi@cernet.edu.cn] Sent: Tuesday, March 23, 2010 12:52 PM To: Frank Xia; 'John Kaippallimalil'; savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration You meant, by the Neighbor table/ARP table of that router (then the router should be the first layer 3 hop in the subnet). Right. One concern is that the host could spoof the NA and reply. >> The NS message from router --> host is unicast. Host replies with NS, and both these messages are forwarded by the switch (and used to update the binding table). Spoofing by the host would probably not be an issue in that case? From: Frank Xia Sent: Tuesday, March 23, 2010 10:41 AM To: 'Bi Jun' ; 'John Kaippallimalil' ; savi@ietf.org Subject: RE: [savi] savi-dhcp-02, state restoration Hi Bi Sorry for my jumping in. Please see my quick response. BR Frank _____ From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Bi Jun Sent: Tuesday, March 23, 2010 12:27 PM To: John Kaippallimalil; savi@ietf.org Subject: Re: [savi] savi-dhcp-02, state restoration Hi John, Thank you very much for your suggestion. For alternative 1, it is already added into the section 22 of savi-dhcp-02. However, based on the suggestion from Eric and others, it's an optional function, because it will be a heavy cost to savi-switches, especially low end access switches. For alternative 2, it needs the upstream router to know the host's address bound at the rebooted switches so that the router can send the NS, right? Frank=>Yes. The router already has full information about L2&L3 information of the host, and the interface(port) that the host is connected. thanks, Jun Bi From: John Kaippallimalil Sent: Monday, March 22, 2010 10:40 AM To: 'Bi Jun' ; savi@ietf.org Subject: savi-dhcp-02, state restoration Hi Jun, In savi-dhcp-02 section 21 (State Restoration), the suggestion is to store state bindings in non volatile memory. One concern is that non-volatile memory is not typically write efficient. Two alternative solutions: Alternative 1: Use the DHCPLEASEQUERY mechanism to rebuild state. Some details for IPv6 below: - when switch recovers, it has lost all session state (could stop filtering till SAVi state is rebuilt) - Switch sends bulk DHCPLEASEQUERY (query by relay id) - RFC5460. - DHCP server replies with DHCP entries related to that relay - used to rebuild binding state. However, this alternative requires that the SAVI switch to be a DHCP Relay, and also support TCP (bulk query transport). Alternative 2: - Upstream router detects SAVi switch failure (and recovery). Example 802.1ag messages. - Upon switch recovery, the router sends Neighbor Solicitation, replied by host with NA. (similar to NUD?) - This is used to rebuild binding state in SAVI switch. This method does not require the switch to be a DHCP relay. However it requires 802.1ag support in the network. Regards, John --Boundary_(ID_wNtejN2GFcYuDqsi57rkYw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Good = point.

Especially if we cannot make the assumption that a DHCP relay (or server) is located at = the router.

 

Regards,

John

 

From: Guang = Yao [mailto:yaoa02@mails.tsinghua.edu.cn]
Sent: Tuesday, March 23, = 2010 1:37 PM
To: 'John = Kaippallimalil'
Cc: savi@ietf.org
Subject: RE: [savi] = savi-dhcp-02, state restoration

 

A possible vulnerability is that a malicious node may try to pollute the ND table = of the router through spoofed IP before(or during) this = process.

 <= /o:p>

Maybe the = ND table should be locked until this process is = finished.

 <= /o:p>

And it = seems the SAVI device loses independence?

 <= /o:p>

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, March = 24, 2010 2:12 AM
To: 'Bi Jun'; 'Frank = Xia'; savi@ietf.org
Subject: Re: [savi] = savi-dhcp-02, state restoration

 

Please = see inline >>

 

From: Bi = Jun [mailto:junbi@cernet.edu.cn]
Sent: Tuesday, March 23, = 2010 12:52 PM
To: Frank Xia; 'John Kaippallimalil'; savi@ietf.org
Subject: Re: [savi] = savi-dhcp-02, state restoration

 

You meant, by the Neighbor table/ARP table of that router (then = the router should be the first layer 3 hop in the = subnet).

 

Right. One concern is that the host could spoof the = NA and reply.

 

>> = The NS message from router à host is unicast. Host replies with NS, and = both these messages are forwarded by the switch (and used to update the = binding table).

Spoofing = by the host would probably not be an issue in that = case?

 

 

 

From: Frank Xia

Sent: Tuesday, March 23, 2010 10:41 AM

Subject: RE: [savi] savi-dhcp-02, state restoration

 

Hi Bi

 

Sorry for my jumping in. =

 

Please see my quick = response.

 

BR

Frank

 

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On = Behalf Of Bi Jun
Sent: Tuesday, March 23, = 2010 12:27 PM
To: John Kaippallimalil; = savi@ietf.org
Subject: Re: [savi] = savi-dhcp-02, state restoration

 

Hi John,

 

Thank you very much for your = suggestion.

 

For alternative 1, it is already added into the = section 22 of savi-dhcp-02. However, based on the suggestion from Eric and others, =

it's an optional function, because it will be a = heavy cost to savi-switches, especially low end access = switches.

 

For alternative 2,  it needs the upstream = router to know the host's address bound at the rebooted switches so that the = router can send the NS, right?

Frank=3D>Yes. The router = already has full information about L2&L3

information of the host, and the interface(port) that the host is connected. 

 

thanks,

Jun Bi

 

Sent: Monday, March 22, 2010 10:40 AM

Subject: savi-dhcp-02, state restoration

 

Hi Jun,

In savi-dhcp-02 section 21 (State = Restoration), the suggestion is to store state bindings in non volatile memory. One = concern is that non-volatile memory is not typically write efficient. =

 

Two alternative = solutions:

Alternative 1:

Use the DHCPLEASEQUERY mechanism to rebuild = state. Some details for IPv6 below:

-    = when switch recovers, it has lost all session state (could stop filtering = till SAVi state is rebuilt)

-    = Switch sends bulk DHCPLEASEQUERY (query by relay id) – RFC5460. =

-    = DHCP server replies with DHCP entries related to that relay – used to = rebuild binding state.

However, this alternative requires that the = SAVI switch to be a DHCP Relay, and also support TCP (bulk query transport). =

 

Alternative 2:
- Upstream router detects SAVi switch failure (and recovery). Example = 802.1ag messages.

-    = Upon switch recovery, the router sends Neighbor Solicitation, replied by host = with NA. (similar to NUD?)

-    = This is used to rebuild binding state in SAVI = switch.

This method does not require the switch to be = a DHCP relay. However it requires 802.1ag support in the = network.

 

Regards,

John

 

--Boundary_(ID_wNtejN2GFcYuDqsi57rkYw)-- From jeanmichel.combes@gmail.com Tue Mar 23 16:38:29 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B8C3A68AF for ; Tue, 23 Mar 2010 16:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPVtHKLb8IMW for ; Tue, 23 Mar 2010 16:38:29 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B068C3A6903 for ; Tue, 23 Mar 2010 16:38:28 -0700 (PDT) Received: by wwg30 with SMTP id 30so3488262wwg.31 for ; Tue, 23 Mar 2010 16:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Npi5rN8iqSVtNGFERqyIMUtd2NjBi80jHHgy+/Zzp68=; b=NGPJku/K5uLDunWc2Y3/Tr+anj1CzHxKR3FrREChp1ri1fKBH1dQq8kw1jxwYSQYvS FlxBPQMwuCQmjRd4khxZBTIoBv2pIMcytVtYFADYciVq1Q4W6MFaGAI4z6DuSHEFgK94 c5wFXUcqeVsMfaRNmFqzjieoLr5W4pTFC/bV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=xCnlHCvli8zz0uXBOFjWkfCF9B0vom0TYkFsv16Fb0thXpBiZXNrfErsr1qpAaqGPZ 4jn/q8/ZZOcdrRCQmqOlXfJVqImQMlkywLOg3dp6QWHZtmP/hw8CSecynXgnerUI0hP2 DrxPZPxIu8wjrTURYkkflAUJ78RlHsh3itPV8= MIME-Version: 1.0 Received: by 10.216.85.65 with SMTP id t43mr3915216wee.60.1269387524380; Tue, 23 Mar 2010 16:38:44 -0700 (PDT) In-Reply-To: <729b68be1003221435r71f1de4dx989374951f5d3223@mail.gmail.com> References: <729b68be1003221435r71f1de4dx989374951f5d3223@mail.gmail.com> Date: Wed, 24 Mar 2010 00:38:44 +0100 Message-ID: <729b68be1003231638u5eb79980o60b0a982e40b1ac8@mail.gmail.com> From: Jean-Michel Combes To: SAVI Mailing List , Christian Vogt Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [savi] Minutes taker & Jabber scribe needed X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 23:38:29 -0000 Folks, AFAIK, we have neither a minute taker nor a jabber scribe for the moment. Please, we need volunteers. Thanks in advance. Christian & Jean-Michel 2010/3/22 Jean-Michel Combes : > Hi, > > for the tomorrow session, we will need one (or more) jabber scribe and > one (or more) minutes takers. > > Thanks a lot in advance for the volunteers! > > Christian & Jean-Michel. > From christian.vogt@ericsson.com Tue Mar 23 16:58:30 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35EE13A688C for ; Tue, 23 Mar 2010 16:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.734 X-Spam-Level: X-Spam-Status: No, score=-4.734 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+SxsamOqYXe for ; Tue, 23 Mar 2010 16:58:29 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 5CA883A67AE for ; Tue, 23 Mar 2010 16:58:29 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o2O027tN008092 for ; Tue, 23 Mar 2010 19:02:07 -0500 Received: from client-vpn-075.edd.ericsson.se (147.117.20.213) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.1.375.2; Tue, 23 Mar 2010 19:58:47 -0400 From: Christian Vogt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Tue, 23 Mar 2010 16:58:40 -0700 Message-ID: To: SAVI Mailing List MIME-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [savi] SAVI meeting proceedings online X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 23:58:30 -0000 Folks, All presentation slides for the upcoming SAVI meeting in Anaheim are now available online: https://datatracker.ietf.org/meeting/77/materials.html#wg-savi - Christian From jmh@joelhalpern.com Tue Mar 23 18:32:08 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AB473A68D0 for ; Tue, 23 Mar 2010 18:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtoItWEkXkw4 for ; Tue, 23 Mar 2010 18:32:07 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id A75153A684D for ; Tue, 23 Mar 2010 18:32:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 4CBE43228B9B for ; Tue, 23 Mar 2010 18:32:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [130.129.26.67] (dhcp-wireless-open-abg-26-67.meeting.ietf.org [130.129.26.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 2F4F73228088 for ; Tue, 23 Mar 2010 18:32:27 -0700 (PDT) Message-ID: <4BA96BAA.5020507@joelhalpern.com> Date: Tue, 23 Mar 2010 21:32:26 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 01:32:08 -0000 The large question I raised was whether it was reasonable to treat as knowable the question of whether the host is directly connected to the SAVI switch. Regarding the specifics of the presentation, I commented that I consider expecting the user to repair his network connection to be unacceptable. Many naive users simply do not even understand that question. Regarding the suggestion of using short DHCP lease times, this would require that we ALWAYS use very short lifetimes, since the lease that needs to be short is the one that was sent before the failure. This seems to be a very bad idea. Yours, Joel M. Halpern From yaoa02@mails.tsinghua.edu.cn Tue Mar 23 20:04:52 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 259353A6B66 for ; Tue, 23 Mar 2010 20:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.431 X-Spam-Level: * X-Spam-Status: No, score=1.431 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ck+8XuhikMF for ; Tue, 23 Mar 2010 20:04:51 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 03AA53A67BD for ; Tue, 23 Mar 2010 20:04:51 -0700 (PDT) Received: from dhcp-wireless-open-abg-27-91.meeting.ietf.org ([130.129.27.91] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NuGtu-0000Bz-1Z; Wed, 24 Mar 2010 11:04:59 +0800 From: "Guang Yao" To: "'Joel M. Halpern'" References: <4BA96BAA.5020507@joelhalpern.com> In-Reply-To: <4BA96BAA.5020507@joelhalpern.com> Date: Wed, 24 Mar 2010 11:04:35 +0800 Message-ID: <000e01cacafe$c5103c80$4f30b580$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrK8ZdurigdQ9usTomqqlT9kgsYFQACuC1Q Content-Language: zh-cn Cc: savi@ietf.org Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 03:04:52 -0000 Hi Joel, Data-trigger is only used when topo changes or a hub attached with hosts moves to another link in DHCP case. The first seldom happens. Or users would have sufficient experience from bad network condition. And the later one, I think a user that can configure a hub and change the link is not a naive one. However, if a pre-knowledge that users are naive is sure, and the layer 2 topo changes frequently, just configure data-trigger on all the possible anchors. The second problem, the lease time doesn't have to be very short. It just requires to be short than the time that all the users learn how to repair their network connections. BR, Guang > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Joel > M. Halpern > Sent: Wednesday, March 24, 2010 9:32 AM > To: SAVI Mailing List > Subject: [savi] Points raised regarding DHCP solution > > The large question I raised was whether it was reasonable to treat as > knowable the question of whether the host is directly connected to the > SAVI switch. > > Regarding the specifics of the presentation, I commented that I consider > expecting the user to repair his network connection to be unacceptable. > Many naive users simply do not even understand that question. > > Regarding the suggestion of using short DHCP lease times, this would > require that we ALWAYS use very short lifetimes, since the lease that > needs to be short is the one that was sent before the failure. This > seems to be a very bad idea. > > Yours, > Joel M. Halpern > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From yaoa02@mails.tsinghua.edu.cn Tue Mar 23 20:27:49 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A413A6859 for ; Tue, 23 Mar 2010 20:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.281 X-Spam-Level: * X-Spam-Status: No, score=1.281 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCdVq-SbSA3V for ; Tue, 23 Mar 2010 20:27:48 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 800003A6B99 for ; Tue, 23 Mar 2010 20:27:46 -0700 (PDT) Received: from dhcp-wireless-open-abg-27-91.meeting.ietf.org ([130.129.27.91] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NuHGC-0006Bu-9m for savi@ietf.org; Wed, 24 Mar 2010 11:28:01 +0800 From: "Guang Yao" To: Date: Wed, 24 Mar 2010 11:27:47 +0800 Message-ID: <001701cacb01$fce5e0d0$f6b1a270$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrLAfmFqLyo3RQ6QJCQjm3uRHf6cg== Content-Language: zh-cn Subject: [savi] One minor comments on "Analysis of Open Issues in SAVI " X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 03:27:49 -0000 On "Additional causes for DAD NSOL packets loss. DAD NSOL is the first packet a host sends Initial packets can potentially suffer a higher loss rate" It's not true for all the DAD messages. Only DAD for link local address is the first packet. DAD for global address will not be performed until a RA is received. And it may be handled through snooping MLD message. BR, Guang From junbi@tsinghua.edu.cn Tue Mar 23 21:59:38 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2F03A6C83 for ; Tue, 23 Mar 2010 21:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.626 X-Spam-Level: ** X-Spam-Status: No, score=2.626 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkf40oEpI3d9 for ; Tue, 23 Mar 2010 21:59:37 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 63B913A6C81 for ; Tue, 23 Mar 2010 21:59:35 -0700 (PDT) Received: from dhcp-wireless-open-abg-30-129.meeting.ietf.org ([130.129.30.129] helo=junbiVAIO) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NuIgu-0002Yc-E5; Wed, 24 Mar 2010 12:59:42 +0800 Message-ID: <112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO> From: "Jun Bi" To: "Joel M. Halpern" , "SAVI Mailing List" References: <4BA96BAA.5020507@joelhalpern.com> In-Reply-To: <4BA96BAA.5020507@joelhalpern.com> Date: Tue, 23 Mar 2010 21:57:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 04:59:38 -0000 -------------------------------------------------- From: "Joel M. Halpern" Sent: Tuesday, March 23, 2010 6:32 PM To: "SAVI Mailing List" Subject: [savi] Points raised regarding DHCP solution > The large question I raised was whether it was reasonable to treat as > knowable the question of whether the host is directly connected to the > SAVI switch. May I make my point more clearly? Switch-host connection is just one easy case to understand that Marcelo's case is not the normal case in real deployment. I meant, as an administrator, we do know the topology I manage. In Marcelo's case are very special from deployment view point, because it needs the dual-uplinks to SAVI switches. There are 3 situation I can image if I met this case as an administrator. If Switch II is a normal switch owned by the administrator, then because enabling the data-triggered functions will cost the administer too much money (to buy a higher-end switch), then I will actually upgrade savi-software at that normal switch (if only implement control based binding, it's very light-weight just like ABC for a switch to upgrade to savi, based on our REAL deployment experience), or I can even buy a new low cost savi-switch to replace Switch II. If Switch II is a normal switch but owned by user, then if he do dual uplinks, he has to report to me the administrator because it will change the topology I am managing. If I permit, then I know which ports I need to configure to enable the data-triggered functions. If he doesn't report to me, then he will be responsible for his possible broken (one possible way is he repairs his network connection). (In reality, I will kindly suggest him to upgrade to savi-software.) If switch II is a hub which is not upgradable. Then the packets are boardcasting. Then SAVI-1 and SAVI-2 can know ALL control packets, then setup equal binding table for this hub. Then we actually don't need to enable data-triggered functions. So my conclusion is, in reality, most of Marcelo's consideration won't actually happen (I think Fred Baker has the same points when he replied Marcelo in the mailing-list). In the worst case, if I have to enable data-trigger functions for some cases, I know where to configure it, I don't need to enable it at any port of any switch. Therefore, it should not be a MUST function in SAVI (both for dhcp and slaac). Thank you very much ! Jun Bi > > Regarding the specifics of the presentation, I commented that I consider > expecting the user to repair his network connection to be unacceptable. > Many naive users simply do not even understand that question. > > Regarding the suggestion of using short DHCP lease times, this would > require that we ALWAYS use very short lifetimes, since the lease that > needs to be short is the one that was sent before the failure. This seems > to be a very bad idea. > > Yours, > Joel M. Halpern > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jmh@joelhalpern.com Tue Mar 23 23:08:38 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABCEA3A6901 for ; Tue, 23 Mar 2010 23:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.781 X-Spam-Level: X-Spam-Status: No, score=0.781 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYcwkxIzGvo3 for ; Tue, 23 Mar 2010 23:08:37 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id CBF933A6888 for ; Tue, 23 Mar 2010 23:08:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 29F0A32356A0; Tue, 23 Mar 2010 23:08:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [130.129.26.67] (dhcp-wireless-open-abg-26-67.meeting.ietf.org [130.129.26.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id B6CB8323566E; Tue, 23 Mar 2010 23:08:57 -0700 (PDT) Message-ID: <4BA9AC7A.2010407@joelhalpern.com> Date: Wed, 24 Mar 2010 02:08:58 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Jun Bi References: <4BA96BAA.5020507@joelhalpern.com> <112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO> In-Reply-To: <112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SAVI Mailing List Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 06:08:38 -0000 Jun, I think I follow part of your comment, and then get lost. For the topology change argument,it is the case that the SAVI switch would have to be receiving STP (or RSTP, or TRILL, or ...) packets on the interface on which it is applying SAVI controls. This is clearly detectable, and the SAVI device can complain to management if it is not prepared to code with that combination. Workable. However, my question is how the SAVI device would determine that there is a hub between it and the end user machines. Should it try to guess that the presence of multiple MAC addresses means a hub? What if only one port in the hub is in use? There are still probably for the system caused by the presence of the hub. Yours, Joel Jun Bi wrote: > > > -------------------------------------------------- > From: "Joel M. Halpern" > Sent: Tuesday, March 23, 2010 6:32 PM > To: "SAVI Mailing List" > Subject: [savi] Points raised regarding DHCP solution > >> The large question I raised was whether it was reasonable to treat as >> knowable the question of whether the host is directly connected to the >> SAVI switch. > > May I make my point more clearly? > Switch-host connection is just one easy case to understand that > Marcelo's case > is not the normal case in real deployment. > > I meant, as an administrator, we do know the topology I manage. > In Marcelo's case are very special from deployment view point, because > it needs > the dual-uplinks to SAVI switches. There are 3 situation I can image if > I met this > case as an administrator. > > If Switch II is a normal switch owned by the administrator, then because > enabling the data-triggered functions will cost the administer too much > money (to buy a higher-end switch), then I will actually upgrade > savi-software at that normal switch (if only implement control based > binding, it's very light-weight just like ABC for a switch to upgrade to > savi, based on our REAL deployment experience), or I can even buy a new > low cost savi-switch to replace Switch II. > > If Switch II is a normal switch but owned by user, then if he do dual > uplinks, he > has to report to me the administrator because it will change the > topology I am managing. If I permit, then I know which ports I need to > configure to enable the > data-triggered functions. If he doesn't report to me, then he will be > responsible > for his possible broken (one possible way is he repairs his network > connection). (In reality, I will kindly suggest him to upgrade to > savi-software.) > > If switch II is a hub which is not upgradable. Then the packets are > boardcasting. > Then SAVI-1 and SAVI-2 can know ALL control packets, then setup equal > binding table for this hub. Then we actually don't need to enable > data-triggered functions. > > So my conclusion is, in reality, most of Marcelo's consideration won't > actually happen (I think Fred Baker has the same points when he replied > Marcelo in the mailing-list). In the worst case, if I have to enable > data-trigger functions for some cases, I know where to configure it, I > don't need to enable it at any port of any switch. Therefore, it should > not be a MUST function in SAVI (both for dhcp and slaac). > > Thank you very much ! > Jun Bi > >> >> Regarding the specifics of the presentation, I commented that I >> consider expecting the user to repair his network connection to be >> unacceptable. Many naive users simply do not even understand that >> question. >> >> Regarding the suggestion of using short DHCP lease times, this would >> require that we ALWAYS use very short lifetimes, since the lease that >> needs to be short is the one that was sent before the failure. This >> seems to be a very bad idea. >> >> Yours, >> Joel M. Halpern >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > From junbi@tsinghua.edu.cn Tue Mar 23 23:30:03 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B593A6452 for ; Tue, 23 Mar 2010 23:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.926 X-Spam-Level: ** X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, DNS_FROM_RFC_DSN=1.495, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MP7yPmuIZOz for ; Tue, 23 Mar 2010 23:30:01 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 167A53A67B6 for ; Tue, 23 Mar 2010 23:30:01 -0700 (PDT) Received: from [130.129.30.129] (helo=junbiVAIO) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NuK6U-0002XN-7k; Wed, 24 Mar 2010 14:30:14 +0800 Message-ID: From: "Jun Bi" To: "Joel M. Halpern" References: <4BA96BAA.5020507@joelhalpern.com> <112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO> <4BA9AC7A.2010407@joelhalpern.com> In-Reply-To: <4BA9AC7A.2010407@joelhalpern.com> Date: Tue, 23 Mar 2010 23:29:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Cc: SAVI Mailing List Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 06:30:03 -0000 > However, my question is how the SAVI device would determine that there > is a hub between it and the end user machines. Should it try to guess > that the presence of multiple MAC addresses means a hub? What if only one > port in the hub is in use? There are still probably for the system caused > by the presence of the hub. Dear Jole, Thank you very much for your reply. In my last email, I said if in Marcelo's case SWITCH-II is only a hub, then because hub will boardcast the packets (duplicate packets to both SAVI1 and SAVI2), then both SAVI1 and SAVI2 will know the equal binding by control packet based binding, then it will no the problem Marcelo mentioned. thanks, Jun Bi -------------------------------------------------- From: "Joel M. Halpern" Sent: Tuesday, March 23, 2010 11:08 PM To: "Jun Bi" Cc: "SAVI Mailing List" Subject: Re: [savi] Points raised regarding DHCP solution > Jun, I think I follow part of your comment, and then get lost. > > For the topology change argument,it is the case that the SAVI switch would > have to be receiving STP (or RSTP, or TRILL, or ...) packets on the > interface on which it is applying SAVI controls. This is clearly > detectable, and the SAVI device can complain to management if it is not > prepared to code with that combination. Workable. > > However, my question is how the SAVI device would determine that there is > a hub between it and the end user machines. Should it try to guess that > the presence of multiple MAC addresses means a hub? What if only one port > in the hub is in use? There are still probably for the system caused by > the presence of the hub. > > Yours, > Joel > > Jun Bi wrote: >> >> >> -------------------------------------------------- >> From: "Joel M. Halpern" >> Sent: Tuesday, March 23, 2010 6:32 PM >> To: "SAVI Mailing List" >> Subject: [savi] Points raised regarding DHCP solution >> >>> The large question I raised was whether it was reasonable to treat as >>> knowable the question of whether the host is directly connected to the >>> SAVI switch. >> >> May I make my point more clearly? >> Switch-host connection is just one easy case to understand that Marcelo's >> case >> is not the normal case in real deployment. >> >> I meant, as an administrator, we do know the topology I manage. >> In Marcelo's case are very special from deployment view point, because it >> needs >> the dual-uplinks to SAVI switches. There are 3 situation I can image if I >> met this >> case as an administrator. >> >> If Switch II is a normal switch owned by the administrator, then because >> enabling the data-triggered functions will cost the administer too much >> money (to buy a higher-end switch), then I will actually upgrade >> savi-software at that normal switch (if only implement control based >> binding, it's very light-weight just like ABC for a switch to upgrade to >> savi, based on our REAL deployment experience), or I can even buy a new >> low cost savi-switch to replace Switch II. >> >> If Switch II is a normal switch but owned by user, then if he do dual >> uplinks, he >> has to report to me the administrator because it will change the topology >> I am managing. If I permit, then I know which ports I need to configure >> to enable the >> data-triggered functions. If he doesn't report to me, then he will be >> responsible >> for his possible broken (one possible way is he repairs his network >> connection). (In reality, I will kindly suggest him to upgrade to >> savi-software.) >> >> If switch II is a hub which is not upgradable. Then the packets are >> boardcasting. >> Then SAVI-1 and SAVI-2 can know ALL control packets, then setup equal >> binding table for this hub. Then we actually don't need to enable >> data-triggered functions. >> >> So my conclusion is, in reality, most of Marcelo's consideration won't >> actually happen (I think Fred Baker has the same points when he replied >> Marcelo in the mailing-list). In the worst case, if I have to enable >> data-trigger functions for some cases, I know where to configure it, I >> don't need to enable it at any port of any switch. Therefore, it should >> not be a MUST function in SAVI (both for dhcp and slaac). >> >> Thank you very much ! >> Jun Bi >> >>> >>> Regarding the specifics of the presentation, I commented that I consider >>> expecting the user to repair his network connection to be unacceptable. >>> Many naive users simply do not even understand that question. >>> >>> Regarding the suggestion of using short DHCP lease times, this would >>> require that we ALWAYS use very short lifetimes, since the lease that >>> needs to be short is the one that was sent before the failure. This >>> seems to be a very bad idea. >>> >>> Yours, >>> Joel M. Halpern >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> > From jmh@joelhalpern.com Tue Mar 23 23:49:25 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934F13A6810 for ; Tue, 23 Mar 2010 23:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.098 X-Spam-Level: * X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+It8sCIKWi0 for ; Tue, 23 Mar 2010 23:49:24 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id A092F3A67B0 for ; Tue, 23 Mar 2010 23:49:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 0A79E32284CE; Tue, 23 Mar 2010 23:49:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [130.129.26.67] (dhcp-wireless-open-abg-26-67.meeting.ietf.org [130.129.26.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id AB212322800B; Tue, 23 Mar 2010 23:49:44 -0700 (PDT) Message-ID: <4BA9B60A.3050404@joelhalpern.com> Date: Wed, 24 Mar 2010 02:49:46 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Jun Bi References: <4BA96BAA.5020507@joelhalpern.com> <112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO> <4BA9AC7A.2010407@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SAVI Mailing List Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 06:49:25 -0000 My final comment, which you quoted, was not concerned with the specialized two-switch case. There are many subtle arguments we can have over what the right handling is for the two-switch case. I am still trying to figure out how the SAVI switch will know if a single hub has been placed between it and the client. Yours, Joel Jun Bi wrote: > >> However, my question is how the SAVI device would determine that there >> is a hub between it and the end user machines. Should it try to guess >> that the presence of multiple MAC addresses means a hub? What if only >> one port in the hub is in use? There are still probably for the >> system caused by the presence of the hub. > > Dear Jole, > > Thank you very much for your reply. > > In my last email, I said if in Marcelo's case SWITCH-II is only a hub, > then because hub will boardcast the packets (duplicate packets to both > SAVI1 and SAVI2), then both SAVI1 and SAVI2 will know the equal binding > by control packet based binding, then it will no the problem Marcelo > mentioned. > > thanks, > Jun Bi > > > -------------------------------------------------- > From: "Joel M. Halpern" > Sent: Tuesday, March 23, 2010 11:08 PM > To: "Jun Bi" > Cc: "SAVI Mailing List" > Subject: Re: [savi] Points raised regarding DHCP solution > >> Jun, I think I follow part of your comment, and then get lost. >> >> For the topology change argument,it is the case that the SAVI switch >> would have to be receiving STP (or RSTP, or TRILL, or ...) packets on >> the interface on which it is applying SAVI controls. This is clearly >> detectable, and the SAVI device can complain to management if it is >> not prepared to code with that combination. Workable. >> >> However, my question is how the SAVI device would determine that there >> is a hub between it and the end user machines. Should it try to guess >> that the presence of multiple MAC addresses means a hub? What if only >> one port in the hub is in use? There are still probably for the >> system caused by the presence of the hub. >> >> Yours, >> Joel >> >> Jun Bi wrote: >>> >>> >>> -------------------------------------------------- >>> From: "Joel M. Halpern" >>> Sent: Tuesday, March 23, 2010 6:32 PM >>> To: "SAVI Mailing List" >>> Subject: [savi] Points raised regarding DHCP solution >>> >>>> The large question I raised was whether it was reasonable to treat >>>> as knowable the question of whether the host is directly connected >>>> to the SAVI switch. >>> >>> May I make my point more clearly? >>> Switch-host connection is just one easy case to understand that >>> Marcelo's case >>> is not the normal case in real deployment. >>> >>> I meant, as an administrator, we do know the topology I manage. >>> In Marcelo's case are very special from deployment view point, >>> because it needs >>> the dual-uplinks to SAVI switches. There are 3 situation I can image >>> if I met this >>> case as an administrator. >>> >>> If Switch II is a normal switch owned by the administrator, then >>> because enabling the data-triggered functions will cost the >>> administer too much money (to buy a higher-end switch), then I will >>> actually upgrade savi-software at that normal switch (if only >>> implement control based binding, it's very light-weight just like ABC >>> for a switch to upgrade to savi, based on our REAL deployment >>> experience), or I can even buy a new low cost savi-switch to replace >>> Switch II. >>> >>> If Switch II is a normal switch but owned by user, then if he do dual >>> uplinks, he >>> has to report to me the administrator because it will change the >>> topology I am managing. If I permit, then I know which ports I need >>> to configure to enable the >>> data-triggered functions. If he doesn't report to me, then he will be >>> responsible >>> for his possible broken (one possible way is he repairs his network >>> connection). (In reality, I will kindly suggest him to upgrade to >>> savi-software.) >>> >>> If switch II is a hub which is not upgradable. Then the packets are >>> boardcasting. >>> Then SAVI-1 and SAVI-2 can know ALL control packets, then setup equal >>> binding table for this hub. Then we actually don't need to enable >>> data-triggered functions. >>> >>> So my conclusion is, in reality, most of Marcelo's consideration >>> won't actually happen (I think Fred Baker has the same points when he >>> replied Marcelo in the mailing-list). In the worst case, if I have to >>> enable data-trigger functions for some cases, I know where to >>> configure it, I don't need to enable it at any port of any switch. >>> Therefore, it should not be a MUST function in SAVI (both for dhcp >>> and slaac). >>> >>> Thank you very much ! >>> Jun Bi >>> >>>> >>>> Regarding the specifics of the presentation, I commented that I >>>> consider expecting the user to repair his network connection to be >>>> unacceptable. Many naive users simply do not even understand that >>>> question. >>>> >>>> Regarding the suggestion of using short DHCP lease times, this would >>>> require that we ALWAYS use very short lifetimes, since the lease >>>> that needs to be short is the one that was sent before the failure. >>>> This seems to be a very bad idea. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>> >> > From junbi@tsinghua.edu.cn Wed Mar 24 00:29:35 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2123A696B for ; Wed, 24 Mar 2010 00:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.776 X-Spam-Level: ** X-Spam-Status: No, score=2.776 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, DNS_FROM_RFC_DSN=1.495, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjOrbg7WMkID for ; Wed, 24 Mar 2010 00:29:34 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id ACAA73A6808 for ; Wed, 24 Mar 2010 00:29:33 -0700 (PDT) Received: from dhcp-wireless-open-abg-30-129.meeting.ietf.org ([130.129.30.129] helo=junbiVAIO) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NuL2C-0007N5-BM; Wed, 24 Mar 2010 15:29:49 +0800 Message-ID: From: "Jun Bi" To: "Guang Yao" , References: <001701cacb01$fce5e0d0$f6b1a270$@tsinghua.edu.cn> In-Reply-To: <001701cacb01$fce5e0d0$f6b1a270$@tsinghua.edu.cn> Date: Wed, 24 Mar 2010 00:29:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Subject: Re: [savi] One minor comments on "Analysis of Open Issues in SAVI " X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 07:29:35 -0000 Yes, that's a good point. Jun -------------------------------------------------- From: "Guang Yao" Sent: Tuesday, March 23, 2010 8:27 PM To: Subject: [savi] One minor comments on "Analysis of Open Issues in SAVI " > On "Additional causes for DAD NSOL packets loss. > DAD NSOL is the first packet a host sends > Initial packets can potentially suffer a higher loss rate" > > It's not true for all the DAD messages. Only DAD for link local address is > the first packet. DAD for global address will not be performed until a RA > is > received. And it may be handled through snooping MLD message. > > BR, > Guang > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@cernet.edu.cn Wed Mar 24 01:09:26 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC553A6D0B for ; Wed, 24 Mar 2010 01:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.127 X-Spam-Level: **** X-Spam-Status: No, score=4.127 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_HAS_XAIMC=2.696, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-3s9has-sGY for ; Wed, 24 Mar 2010 01:09:25 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id D900E3A6D0D for ; Wed, 24 Mar 2010 01:08:19 -0700 (PDT) Received: from junbiVAIO([130.129.30.129]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm04baa0377; Wed, 24 Mar 2010 16:08:35 +0800 Message-ID: <16A243CC6D724738A1FC22DC792FDB24@junbiVAIO> From: "Bi Jun" To: "Joel M. Halpern" , "Jun Bi" References: <4BA96BAA.5020507@joelhalpern.com><112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO><4BA9AC7A.2010407@joelhalpern.com> <4BA9B60A.3050404@joelhalpern.com> In-Reply-To: <4BA9B60A.3050404@joelhalpern.com> Date: Wed, 24 Mar 2010 01:08:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: 1ijdVuXB Cc: SAVI Mailing List Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 08:09:26 -0000 sorry for my misunderstanding. Why you think automatically detecting a hub by a savi switch is so important after I have explained in Marcelo's case the hub is no problem ? thanks, Jun Bi -------------------------------------------------- From: "Joel M. Halpern" Sent: Tuesday, March 23, 2010 11:49 PM To: "Jun Bi" Cc: "SAVI Mailing List" Subject: Re: [savi] Points raised regarding DHCP solution > My final comment, which you quoted, was not concerned with the specialized > two-switch case. There are many subtle arguments we can have over what > the right handling is for the two-switch case. > > I am still trying to figure out how the SAVI switch will know if a single > hub has been placed between it and the client. > > Yours, > Joel > > Jun Bi wrote: >> >>> However, my question is how the SAVI device would determine that there >>> is a hub between it and the end user machines. Should it try to guess >>> that the presence of multiple MAC addresses means a hub? What if only >>> one port in the hub is in use? There are still probably for the system >>> caused by the presence of the hub. >> >> Dear Jole, >> >> Thank you very much for your reply. >> >> In my last email, I said if in Marcelo's case SWITCH-II is only a hub, >> then because hub will boardcast the packets (duplicate packets to both >> SAVI1 and SAVI2), then both SAVI1 and SAVI2 will know the equal binding >> by control packet based binding, then it will no the problem Marcelo >> mentioned. >> >> thanks, >> Jun Bi >> >> >> -------------------------------------------------- >> From: "Joel M. Halpern" >> Sent: Tuesday, March 23, 2010 11:08 PM >> To: "Jun Bi" >> Cc: "SAVI Mailing List" >> Subject: Re: [savi] Points raised regarding DHCP solution >> >>> Jun, I think I follow part of your comment, and then get lost. >>> >>> For the topology change argument,it is the case that the SAVI switch >>> would have to be receiving STP (or RSTP, or TRILL, or ...) packets on >>> the interface on which it is applying SAVI controls. This is clearly >>> detectable, and the SAVI device can complain to management if it is not >>> prepared to code with that combination. Workable. >>> >>> However, my question is how the SAVI device would determine that there >>> is a hub between it and the end user machines. Should it try to guess >>> that the presence of multiple MAC addresses means a hub? What if only >>> one port in the hub is in use? There are still probably for the system >>> caused by the presence of the hub. >>> >>> Yours, >>> Joel >>> >>> Jun Bi wrote: >>>> >>>> >>>> -------------------------------------------------- >>>> From: "Joel M. Halpern" >>>> Sent: Tuesday, March 23, 2010 6:32 PM >>>> To: "SAVI Mailing List" >>>> Subject: [savi] Points raised regarding DHCP solution >>>> >>>>> The large question I raised was whether it was reasonable to treat as >>>>> knowable the question of whether the host is directly connected to the >>>>> SAVI switch. >>>> >>>> May I make my point more clearly? >>>> Switch-host connection is just one easy case to understand that >>>> Marcelo's case >>>> is not the normal case in real deployment. >>>> >>>> I meant, as an administrator, we do know the topology I manage. >>>> In Marcelo's case are very special from deployment view point, because >>>> it needs >>>> the dual-uplinks to SAVI switches. There are 3 situation I can image if >>>> I met this >>>> case as an administrator. >>>> >>>> If Switch II is a normal switch owned by the administrator, then >>>> because enabling the data-triggered functions will cost the administer >>>> too much money (to buy a higher-end switch), then I will actually >>>> upgrade savi-software at that normal switch (if only implement control >>>> based binding, it's very light-weight just like ABC for a switch to >>>> upgrade to savi, based on our REAL deployment experience), or I can >>>> even buy a new low cost savi-switch to replace Switch II. >>>> >>>> If Switch II is a normal switch but owned by user, then if he do dual >>>> uplinks, he >>>> has to report to me the administrator because it will change the >>>> topology I am managing. If I permit, then I know which ports I need to >>>> configure to enable the >>>> data-triggered functions. If he doesn't report to me, then he will be >>>> responsible >>>> for his possible broken (one possible way is he repairs his network >>>> connection). (In reality, I will kindly suggest him to upgrade to >>>> savi-software.) >>>> >>>> If switch II is a hub which is not upgradable. Then the packets are >>>> boardcasting. >>>> Then SAVI-1 and SAVI-2 can know ALL control packets, then setup equal >>>> binding table for this hub. Then we actually don't need to enable >>>> data-triggered functions. >>>> >>>> So my conclusion is, in reality, most of Marcelo's consideration won't >>>> actually happen (I think Fred Baker has the same points when he replied >>>> Marcelo in the mailing-list). In the worst case, if I have to enable >>>> data-trigger functions for some cases, I know where to configure it, I >>>> don't need to enable it at any port of any switch. Therefore, it should >>>> not be a MUST function in SAVI (both for dhcp and slaac). >>>> >>>> Thank you very much ! >>>> Jun Bi >>>> >>>>> >>>>> Regarding the specifics of the presentation, I commented that I >>>>> consider expecting the user to repair his network connection to be >>>>> unacceptable. Many naive users simply do not even understand that >>>>> question. >>>>> >>>>> Regarding the suggestion of using short DHCP lease times, this would >>>>> require that we ALWAYS use very short lifetimes, since the lease that >>>>> needs to be short is the one that was sent before the failure. This >>>>> seems to be a very bad idea. >>>>> >>>>> Yours, >>>>> Joel M. Halpern >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>> >>> >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jmh@joelhalpern.com Wed Mar 24 08:06:26 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D51A3A6778 for ; Wed, 24 Mar 2010 08:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnqbJoB0QTh8 for ; Wed, 24 Mar 2010 08:06:25 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 81FCF3A684C for ; Wed, 24 Mar 2010 08:06:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 6A8C132359BE; Wed, 24 Mar 2010 08:06:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [130.129.26.67] (dhcp-wireless-open-abg-26-67.meeting.ietf.org [130.129.26.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 42B9332359BB; Wed, 24 Mar 2010 08:06:46 -0700 (PDT) Message-ID: <4BAA2A88.3080009@joelhalpern.com> Date: Wed, 24 Mar 2010 11:06:48 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Jun Bi References: <001701cacb01$fce5e0d0$f6b1a270$@tsinghua.edu.cn> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: savi@ietf.org, Guang Yao Subject: Re: [savi] One minor comments on "Analysis of Open Issues in SAVI " X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 15:06:26 -0000 I had presumed, since we are doing this enforcement on bridges, that we were resposnible for controlling the allocation of link-local addresses as well as global addresses. If link-local addresses are out of scope, that simplifies many things. Yours, Joel Jun Bi wrote: > Yes, that's a good point. > > Jun > > -------------------------------------------------- > From: "Guang Yao" > Sent: Tuesday, March 23, 2010 8:27 PM > To: > Subject: [savi] One minor comments on "Analysis of Open Issues in SAVI " > >> On "Additional causes for DAD NSOL packets loss. >> DAD NSOL is the first packet a host sends >> Initial packets can potentially suffer a higher loss rate" >> >> It's not true for all the DAD messages. Only DAD for link local >> address is >> the first packet. DAD for global address will not be performed until a >> RA is >> received. And it may be handled through snooping MLD message. >> >> BR, >> Guang >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jmh@joelhalpern.com Wed Mar 24 08:17:18 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F7DF3A6B00 for ; Wed, 24 Mar 2010 08:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.937 X-Spam-Level: * X-Spam-Status: No, score=1.937 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_82=0.6, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv1BQMep9yiJ for ; Wed, 24 Mar 2010 08:17:17 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 60F833A68DA for ; Wed, 24 Mar 2010 08:17:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 554943228036 for ; Wed, 24 Mar 2010 08:17:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [130.129.26.67] (dhcp-wireless-open-abg-26-67.meeting.ietf.org [130.129.26.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 37881323593B for ; Wed, 24 Mar 2010 08:17:38 -0700 (PDT) Message-ID: <4BAA2D12.6070903@joelhalpern.com> Date: Wed, 24 Mar 2010 11:17:38 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: SAVI Mailing List References: <4BA96BAA.5020507@joelhalpern.com><112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO><4BA9AC7A.2010407@joelhalpern.com> <4BA9B60A.3050404@joelhalpern.com> <16A243CC6D724738A1FC22DC792FDB24@junbiVAIO> In-Reply-To: <16A243CC6D724738A1FC22DC792FDB24@junbiVAIO> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 15:17:18 -0000 The current proposals on the table call for different behaviors (or at least different requirements on capabilities) for directly connected and indirectly connected SAVI devices. Thus, the device needs to be able to verify that it is using the right capabilities, or is unable to perform its job. But doing so requires being able to detect the configuration. Yours, Joel Bi Jun wrote: > sorry for my misunderstanding. > Why you think automatically detecting a hub by a savi switch is so > important after I have explained in Marcelo's case the hub is no problem ? > > thanks, > Jun Bi > > -------------------------------------------------- > From: "Joel M. Halpern" > Sent: Tuesday, March 23, 2010 11:49 PM > To: "Jun Bi" > Cc: "SAVI Mailing List" > Subject: Re: [savi] Points raised regarding DHCP solution > >> My final comment, which you quoted, was not concerned with the >> specialized two-switch case. There are many subtle arguments we can >> have over what the right handling is for the two-switch case. >> >> I am still trying to figure out how the SAVI switch will know if a >> single hub has been placed between it and the client. >> >> Yours, >> Joel >> >> Jun Bi wrote: >>> >>>> However, my question is how the SAVI device would determine that there >>>> is a hub between it and the end user machines. Should it try to >>>> guess that the presence of multiple MAC addresses means a hub? What >>>> if only one port in the hub is in use? There are still probably for >>>> the system caused by the presence of the hub. >>> >>> Dear Jole, >>> >>> Thank you very much for your reply. >>> >>> In my last email, I said if in Marcelo's case SWITCH-II is only a >>> hub, then because hub will boardcast the packets (duplicate packets >>> to both SAVI1 and SAVI2), then both SAVI1 and SAVI2 will know the >>> equal binding by control packet based binding, then it will no the >>> problem Marcelo mentioned. >>> >>> thanks, >>> Jun Bi >>> >>> >>> -------------------------------------------------- >>> From: "Joel M. Halpern" >>> Sent: Tuesday, March 23, 2010 11:08 PM >>> To: "Jun Bi" >>> Cc: "SAVI Mailing List" >>> Subject: Re: [savi] Points raised regarding DHCP solution >>> >>>> Jun, I think I follow part of your comment, and then get lost. >>>> >>>> For the topology change argument,it is the case that the SAVI switch >>>> would have to be receiving STP (or RSTP, or TRILL, or ...) packets >>>> on the interface on which it is applying SAVI controls. This is >>>> clearly detectable, and the SAVI device can complain to management >>>> if it is not prepared to code with that combination. Workable. >>>> >>>> However, my question is how the SAVI device would determine that >>>> there is a hub between it and the end user machines. Should it try >>>> to guess that the presence of multiple MAC addresses means a hub? >>>> What if only one port in the hub is in use? There are still >>>> probably for the system caused by the presence of the hub. >>>> >>>> Yours, >>>> Joel >>>> >>>> Jun Bi wrote: >>>>> >>>>> >>>>> -------------------------------------------------- >>>>> From: "Joel M. Halpern" >>>>> Sent: Tuesday, March 23, 2010 6:32 PM >>>>> To: "SAVI Mailing List" >>>>> Subject: [savi] Points raised regarding DHCP solution >>>>> >>>>>> The large question I raised was whether it was reasonable to treat >>>>>> as knowable the question of whether the host is directly connected >>>>>> to the SAVI switch. >>>>> >>>>> May I make my point more clearly? >>>>> Switch-host connection is just one easy case to understand that >>>>> Marcelo's case >>>>> is not the normal case in real deployment. >>>>> >>>>> I meant, as an administrator, we do know the topology I manage. >>>>> In Marcelo's case are very special from deployment view point, >>>>> because it needs >>>>> the dual-uplinks to SAVI switches. There are 3 situation I can >>>>> image if I met this >>>>> case as an administrator. >>>>> >>>>> If Switch II is a normal switch owned by the administrator, then >>>>> because enabling the data-triggered functions will cost the >>>>> administer too much money (to buy a higher-end switch), then I will >>>>> actually upgrade savi-software at that normal switch (if only >>>>> implement control based binding, it's very light-weight just like >>>>> ABC for a switch to upgrade to savi, based on our REAL deployment >>>>> experience), or I can even buy a new low cost savi-switch to >>>>> replace Switch II. >>>>> >>>>> If Switch II is a normal switch but owned by user, then if he do >>>>> dual uplinks, he >>>>> has to report to me the administrator because it will change the >>>>> topology I am managing. If I permit, then I know which ports I need >>>>> to configure to enable the >>>>> data-triggered functions. If he doesn't report to me, then he will >>>>> be responsible >>>>> for his possible broken (one possible way is he repairs his network >>>>> connection). (In reality, I will kindly suggest him to upgrade to >>>>> savi-software.) >>>>> >>>>> If switch II is a hub which is not upgradable. Then the packets are >>>>> boardcasting. >>>>> Then SAVI-1 and SAVI-2 can know ALL control packets, then setup >>>>> equal binding table for this hub. Then we actually don't need to >>>>> enable data-triggered functions. >>>>> >>>>> So my conclusion is, in reality, most of Marcelo's consideration >>>>> won't actually happen (I think Fred Baker has the same points when >>>>> he replied Marcelo in the mailing-list). In the worst case, if I >>>>> have to enable data-trigger functions for some cases, I know where >>>>> to configure it, I don't need to enable it at any port of any >>>>> switch. Therefore, it should not be a MUST function in SAVI (both >>>>> for dhcp and slaac). >>>>> >>>>> Thank you very much ! >>>>> Jun Bi >>>>> >>>>>> >>>>>> Regarding the specifics of the presentation, I commented that I >>>>>> consider expecting the user to repair his network connection to be >>>>>> unacceptable. Many naive users simply do not even understand that >>>>>> question. >>>>>> >>>>>> Regarding the suggestion of using short DHCP lease times, this >>>>>> would require that we ALWAYS use very short lifetimes, since the >>>>>> lease that needs to be short is the one that was sent before the >>>>>> failure. This seems to be a very bad idea. >>>>>> >>>>>> Yours, >>>>>> Joel M. Halpern >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> >>>>> >>>> >>> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > From junbi@cernet.edu.cn Wed Mar 24 11:16:38 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631593A6D4B for ; Wed, 24 Mar 2010 11:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.277 X-Spam-Level: **** X-Spam-Status: No, score=4.277 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_HAS_XAIMC=2.696, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 083L6KlY47Fy for ; Wed, 24 Mar 2010 11:16:37 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id EE9563A6C36 for ; Wed, 24 Mar 2010 11:16:35 -0700 (PDT) Received: from junbiVAIO([130.129.30.129]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmb4baa920b; Thu, 25 Mar 2010 02:16:55 +0800 Message-ID: From: "Bi Jun" To: "Joel M. Halpern" References: <4BA96BAA.5020507@joelhalpern.com><112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO><4BA9AC7A.2010407@joelhalpern.com><4BA9B60A.3050404@joelhalpern.com><16A243CC6D724738A1FC22DC792FDB24@junbiVAIO> <4BAA2D12.6070903@joelhalpern.com> In-Reply-To: <4BAA2D12.6070903@joelhalpern.com> Date: Wed, 24 Mar 2010 11:16:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: 1n1I5uXB Cc: SAVI Mailing List Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 18:16:38 -0000 Hi Jole, thanks for the explanation. But if the host is connected with a hub, then (1) as I said in my last email, if it is dual uplinks in marcelo's ppt, it will be no problem. (2) if it is single uplink hub, then under nv-memory storage at savi-switch, do we still need data-triggered. thanks, Jun Bi -------------------------------------------------- From: "Joel M. Halpern" Sent: Wednesday, March 24, 2010 8:17 AM Cc: "SAVI Mailing List" Subject: Re: [savi] Points raised regarding DHCP solution > The current proposals on the table call for different behaviors (or at > least different requirements on capabilities) for directly connected and > indirectly connected SAVI devices. > Thus, the device needs to be able to verify that it is using the right > capabilities, or is unable to perform its job. > But doing so requires being able to detect the configuration. > > Yours, > Joel > > Bi Jun wrote: >> sorry for my misunderstanding. >> Why you think automatically detecting a hub by a savi switch is so >> important after I have explained in Marcelo's case the hub is no problem >> ? >> >> thanks, >> Jun Bi >> >> -------------------------------------------------- >> From: "Joel M. Halpern" >> Sent: Tuesday, March 23, 2010 11:49 PM >> To: "Jun Bi" >> Cc: "SAVI Mailing List" >> Subject: Re: [savi] Points raised regarding DHCP solution >> >>> My final comment, which you quoted, was not concerned with the >>> specialized two-switch case. There are many subtle arguments we can >>> have over what the right handling is for the two-switch case. >>> >>> I am still trying to figure out how the SAVI switch will know if a >>> single hub has been placed between it and the client. >>> >>> Yours, >>> Joel >>> >>> Jun Bi wrote: >>>> >>>>> However, my question is how the SAVI device would determine that there >>>>> is a hub between it and the end user machines. Should it try to guess >>>>> that the presence of multiple MAC addresses means a hub? What if only >>>>> one port in the hub is in use? There are still probably for the >>>>> system caused by the presence of the hub. >>>> >>>> Dear Jole, >>>> >>>> Thank you very much for your reply. >>>> >>>> In my last email, I said if in Marcelo's case SWITCH-II is only a hub, >>>> then because hub will boardcast the packets (duplicate packets to both >>>> SAVI1 and SAVI2), then both SAVI1 and SAVI2 will know the equal binding >>>> by control packet based binding, then it will no the problem Marcelo >>>> mentioned. >>>> >>>> thanks, >>>> Jun Bi >>>> >>>> >>>> -------------------------------------------------- >>>> From: "Joel M. Halpern" >>>> Sent: Tuesday, March 23, 2010 11:08 PM >>>> To: "Jun Bi" >>>> Cc: "SAVI Mailing List" >>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>> >>>>> Jun, I think I follow part of your comment, and then get lost. >>>>> >>>>> For the topology change argument,it is the case that the SAVI switch >>>>> would have to be receiving STP (or RSTP, or TRILL, or ...) packets on >>>>> the interface on which it is applying SAVI controls. This is clearly >>>>> detectable, and the SAVI device can complain to management if it is >>>>> not prepared to code with that combination. Workable. >>>>> >>>>> However, my question is how the SAVI device would determine that there >>>>> is a hub between it and the end user machines. Should it try to guess >>>>> that the presence of multiple MAC addresses means a hub? What if only >>>>> one port in the hub is in use? There are still probably for the >>>>> system caused by the presence of the hub. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> Jun Bi wrote: >>>>>> >>>>>> >>>>>> -------------------------------------------------- >>>>>> From: "Joel M. Halpern" >>>>>> Sent: Tuesday, March 23, 2010 6:32 PM >>>>>> To: "SAVI Mailing List" >>>>>> Subject: [savi] Points raised regarding DHCP solution >>>>>> >>>>>>> The large question I raised was whether it was reasonable to treat >>>>>>> as knowable the question of whether the host is directly connected >>>>>>> to the SAVI switch. >>>>>> >>>>>> May I make my point more clearly? >>>>>> Switch-host connection is just one easy case to understand that >>>>>> Marcelo's case >>>>>> is not the normal case in real deployment. >>>>>> >>>>>> I meant, as an administrator, we do know the topology I manage. >>>>>> In Marcelo's case are very special from deployment view point, >>>>>> because it needs >>>>>> the dual-uplinks to SAVI switches. There are 3 situation I can image >>>>>> if I met this >>>>>> case as an administrator. >>>>>> >>>>>> If Switch II is a normal switch owned by the administrator, then >>>>>> because enabling the data-triggered functions will cost the >>>>>> administer too much money (to buy a higher-end switch), then I will >>>>>> actually upgrade savi-software at that normal switch (if only >>>>>> implement control based binding, it's very light-weight just like ABC >>>>>> for a switch to upgrade to savi, based on our REAL deployment >>>>>> experience), or I can even buy a new low cost savi-switch to replace >>>>>> Switch II. >>>>>> >>>>>> If Switch II is a normal switch but owned by user, then if he do dual >>>>>> uplinks, he >>>>>> has to report to me the administrator because it will change the >>>>>> topology I am managing. If I permit, then I know which ports I need >>>>>> to configure to enable the >>>>>> data-triggered functions. If he doesn't report to me, then he will be >>>>>> responsible >>>>>> for his possible broken (one possible way is he repairs his network >>>>>> connection). (In reality, I will kindly suggest him to upgrade to >>>>>> savi-software.) >>>>>> >>>>>> If switch II is a hub which is not upgradable. Then the packets are >>>>>> boardcasting. >>>>>> Then SAVI-1 and SAVI-2 can know ALL control packets, then setup equal >>>>>> binding table for this hub. Then we actually don't need to enable >>>>>> data-triggered functions. >>>>>> >>>>>> So my conclusion is, in reality, most of Marcelo's consideration >>>>>> won't actually happen (I think Fred Baker has the same points when he >>>>>> replied Marcelo in the mailing-list). In the worst case, if I have to >>>>>> enable data-trigger functions for some cases, I know where to >>>>>> configure it, I don't need to enable it at any port of any switch. >>>>>> Therefore, it should not be a MUST function in SAVI (both for dhcp >>>>>> and slaac). >>>>>> >>>>>> Thank you very much ! >>>>>> Jun Bi >>>>>> >>>>>>> >>>>>>> Regarding the specifics of the presentation, I commented that I >>>>>>> consider expecting the user to repair his network connection to be >>>>>>> unacceptable. Many naive users simply do not even understand that >>>>>>> question. >>>>>>> >>>>>>> Regarding the suggestion of using short DHCP lease times, this would >>>>>>> require that we ALWAYS use very short lifetimes, since the lease >>>>>>> that needs to be short is the one that was sent before the failure. >>>>>>> This seems to be a very bad idea. >>>>>>> >>>>>>> Yours, >>>>>>> Joel M. Halpern >>>>>>> _______________________________________________ >>>>>>> savi mailing list >>>>>>> savi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>> >>>>>> >>>>> >>>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jmh@joelhalpern.com Wed Mar 24 12:19:59 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8F6C3A686C for ; Wed, 24 Mar 2010 12:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.472 X-Spam-Level: * X-Spam-Status: No, score=1.472 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abfOjcZ7C5nL for ; Wed, 24 Mar 2010 12:19:58 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 9FE483A682E for ; Wed, 24 Mar 2010 12:19:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id CD1DD3235955; Wed, 24 Mar 2010 12:20:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [130.129.26.67] (dhcp-wireless-open-abg-26-67.meeting.ietf.org [130.129.26.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id A66203235949; Wed, 24 Mar 2010 12:20:18 -0700 (PDT) Message-ID: <4BAA65F2.6020300@joelhalpern.com> Date: Wed, 24 Mar 2010 15:20:18 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Bi Jun References: <4BA96BAA.5020507@joelhalpern.com><112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO><4BA9AC7A.2010407@joelhalpern.com><4BA9B60A.3050404@joelhalpern.com><16A243CC6D724738A1FC22DC792FDB24@junbiVAIO> <4BAA2D12.6070903@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SAVI Mailing List Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 19:20:00 -0000 We are almost at the crux of my concern. Looking at point 2, we end up saying something along the lines of A SAVI-DHCP device SHOULD us non-volatile storage for state information unless it can know that it is directly connected to the client. Now, presume that an implementor is trying to comply. And he builds a SAVI-DHCP device that does not have non-volatile storage, because his primary market is cases where clients are directly attached. And it gets sold to someone whose network is primarily used with clients directly attached to the SAVI device. So far so good. Now suppose that someone, possibly without authority but without prohibition, slaps a hub between their station and the SAVI device. The SAVI device is now technically not behaving right. It can not function properly. If the SAVI device could detect this, I would say "okay, generate an alert. Things happen." But the SAVI device can't tell. (With the dual uplink case, the SAVI device can tell because it gets STP over its SAVI enforced ports.) It is at least somewhat unusual to write a SHOULD where the exception is undetectable. Yours, Joel Bi Jun wrote: > Hi Jole, > > thanks for the explanation. > > But if the host is connected with a hub, then > > (1) as I said in my last email, if it is dual uplinks in marcelo's ppt, > it will be no problem. > > (2) if it is single uplink hub, then under nv-memory storage at > savi-switch, do we still need data-triggered. > > thanks, > Jun Bi > > -------------------------------------------------- > From: "Joel M. Halpern" > Sent: Wednesday, March 24, 2010 8:17 AM > Cc: "SAVI Mailing List" > Subject: Re: [savi] Points raised regarding DHCP solution > >> The current proposals on the table call for different behaviors (or at >> least different requirements on capabilities) for directly connected >> and indirectly connected SAVI devices. >> Thus, the device needs to be able to verify that it is using the right >> capabilities, or is unable to perform its job. >> But doing so requires being able to detect the configuration. >> >> Yours, >> Joel >> >> Bi Jun wrote: >>> sorry for my misunderstanding. >>> Why you think automatically detecting a hub by a savi switch is so >>> important after I have explained in Marcelo's case the hub is no >>> problem ? >>> >>> thanks, >>> Jun Bi >>> >>> -------------------------------------------------- >>> From: "Joel M. Halpern" >>> Sent: Tuesday, March 23, 2010 11:49 PM >>> To: "Jun Bi" >>> Cc: "SAVI Mailing List" >>> Subject: Re: [savi] Points raised regarding DHCP solution >>> >>>> My final comment, which you quoted, was not concerned with the >>>> specialized two-switch case. There are many subtle arguments we can >>>> have over what the right handling is for the two-switch case. >>>> >>>> I am still trying to figure out how the SAVI switch will know if a >>>> single hub has been placed between it and the client. >>>> >>>> Yours, >>>> Joel >>>> >>>> Jun Bi wrote: >>>>> >>>>>> However, my question is how the SAVI device would determine that >>>>>> there >>>>>> is a hub between it and the end user machines. Should it try to >>>>>> guess that the presence of multiple MAC addresses means a hub? >>>>>> What if only one port in the hub is in use? There are still >>>>>> probably for the system caused by the presence of the hub. >>>>> >>>>> Dear Jole, >>>>> >>>>> Thank you very much for your reply. >>>>> >>>>> In my last email, I said if in Marcelo's case SWITCH-II is only a >>>>> hub, then because hub will boardcast the packets (duplicate packets >>>>> to both SAVI1 and SAVI2), then both SAVI1 and SAVI2 will know the >>>>> equal binding by control packet based binding, then it will no the >>>>> problem Marcelo mentioned. >>>>> >>>>> thanks, >>>>> Jun Bi >>>>> >>>>> >>>>> -------------------------------------------------- >>>>> From: "Joel M. Halpern" >>>>> Sent: Tuesday, March 23, 2010 11:08 PM >>>>> To: "Jun Bi" >>>>> Cc: "SAVI Mailing List" >>>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>> >>>>>> Jun, I think I follow part of your comment, and then get lost. >>>>>> >>>>>> For the topology change argument,it is the case that the SAVI >>>>>> switch would have to be receiving STP (or RSTP, or TRILL, or ...) >>>>>> packets on the interface on which it is applying SAVI controls. >>>>>> This is clearly detectable, and the SAVI device can complain to >>>>>> management if it is not prepared to code with that combination. >>>>>> Workable. >>>>>> >>>>>> However, my question is how the SAVI device would determine that >>>>>> there is a hub between it and the end user machines. Should it >>>>>> try to guess that the presence of multiple MAC addresses means a >>>>>> hub? What if only one port in the hub is in use? There are still >>>>>> probably for the system caused by the presence of the hub. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> Jun Bi wrote: >>>>>>> >>>>>>> >>>>>>> -------------------------------------------------- >>>>>>> From: "Joel M. Halpern" >>>>>>> Sent: Tuesday, March 23, 2010 6:32 PM >>>>>>> To: "SAVI Mailing List" >>>>>>> Subject: [savi] Points raised regarding DHCP solution >>>>>>> >>>>>>>> The large question I raised was whether it was reasonable to >>>>>>>> treat as knowable the question of whether the host is directly >>>>>>>> connected to the SAVI switch. >>>>>>> >>>>>>> May I make my point more clearly? >>>>>>> Switch-host connection is just one easy case to understand that >>>>>>> Marcelo's case >>>>>>> is not the normal case in real deployment. >>>>>>> >>>>>>> I meant, as an administrator, we do know the topology I manage. >>>>>>> In Marcelo's case are very special from deployment view point, >>>>>>> because it needs >>>>>>> the dual-uplinks to SAVI switches. There are 3 situation I can >>>>>>> image if I met this >>>>>>> case as an administrator. >>>>>>> >>>>>>> If Switch II is a normal switch owned by the administrator, then >>>>>>> because enabling the data-triggered functions will cost the >>>>>>> administer too much money (to buy a higher-end switch), then I >>>>>>> will actually upgrade savi-software at that normal switch (if >>>>>>> only implement control based binding, it's very light-weight just >>>>>>> like ABC for a switch to upgrade to savi, based on our REAL >>>>>>> deployment experience), or I can even buy a new low cost >>>>>>> savi-switch to replace Switch II. >>>>>>> >>>>>>> If Switch II is a normal switch but owned by user, then if he do >>>>>>> dual uplinks, he >>>>>>> has to report to me the administrator because it will change the >>>>>>> topology I am managing. If I permit, then I know which ports I >>>>>>> need to configure to enable the >>>>>>> data-triggered functions. If he doesn't report to me, then he >>>>>>> will be responsible >>>>>>> for his possible broken (one possible way is he repairs his >>>>>>> network connection). (In reality, I will kindly suggest him to >>>>>>> upgrade to savi-software.) >>>>>>> >>>>>>> If switch II is a hub which is not upgradable. Then the packets >>>>>>> are boardcasting. >>>>>>> Then SAVI-1 and SAVI-2 can know ALL control packets, then setup >>>>>>> equal binding table for this hub. Then we actually don't need to >>>>>>> enable data-triggered functions. >>>>>>> >>>>>>> So my conclusion is, in reality, most of Marcelo's consideration >>>>>>> won't actually happen (I think Fred Baker has the same points >>>>>>> when he replied Marcelo in the mailing-list). In the worst case, >>>>>>> if I have to enable data-trigger functions for some cases, I know >>>>>>> where to configure it, I don't need to enable it at any port of >>>>>>> any switch. Therefore, it should not be a MUST function in SAVI >>>>>>> (both for dhcp and slaac). >>>>>>> >>>>>>> Thank you very much ! >>>>>>> Jun Bi >>>>>>> >>>>>>>> >>>>>>>> Regarding the specifics of the presentation, I commented that I >>>>>>>> consider expecting the user to repair his network connection to >>>>>>>> be unacceptable. Many naive users simply do not even understand >>>>>>>> that question. >>>>>>>> >>>>>>>> Regarding the suggestion of using short DHCP lease times, this >>>>>>>> would require that we ALWAYS use very short lifetimes, since the >>>>>>>> lease that needs to be short is the one that was sent before the >>>>>>>> failure. This seems to be a very bad idea. >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel M. Halpern >>>>>>>> _______________________________________________ >>>>>>>> savi mailing list >>>>>>>> savi@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > From fred@cisco.com Wed Mar 24 12:37:14 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C84F3A6822 for ; Wed, 24 Mar 2010 12:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.318 X-Spam-Level: X-Spam-Status: No, score=-106.318 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Apg9bvlA-uY9 for ; Wed, 24 Mar 2010 12:37:12 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C055F3A686C for ; Wed, 24 Mar 2010 12:37:11 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH8GqkurRN+J/2dsb2JhbACbG3OnSJkQgluCIwSDHg X-IronPort-AV: E=Sophos;i="4.51,302,1267401600"; d="scan'208";a="105230188" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 24 Mar 2010 19:37:32 +0000 Received: from dhcp-wireless-open-a-41-116.meeting.ietf.org (sjc-vpn4-1205.cisco.com [10.21.84.180]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2OJbWIG027646; Wed, 24 Mar 2010 19:37:32 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4BAA65F2.6020300@joelhalpern.com> Date: Wed, 24 Mar 2010 12:37:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5B679E2B-CEF3-4231-A899-267435243422@cisco.com> References: <4BA96BAA.5020507@joelhalpern.com><112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO><4BA9AC7A.2010407@joelhalpern.com><4BA9B60A.3050404@joelhalpern.com><16A243CC6D724738A1FC22DC792FDB24@junbiVAIO> <4BAA2D12.6070903@joelhalpern.com> <4BAA65F2.6020300@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1077) Cc: SAVI Mailing List Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 19:37:14 -0000 As we discussed in private email last week, I'm very concerned at the = mention of using non-volatile RAM to store data that is ephemeral in = nature. I would far rather find a way to discover the current state of = the network, which may be the same or different than the state before = the switch restarted, than remember something in non-volatile memory = that may or may not be valid at the point it is needed or used. Let me give you one potential implementation. Consider a switch that for = whatever reason is discarding datagrams from a given port because they = use an IPv6 source address that is not in its tables. For various = reasons, it very likely has a counter, on the switch or VLAN if not on = the port itself. It could also maintain a register or FIFO to capture = the source IPv6 and MAC addresses this happened on. Without putting the = logic for generating the request into the data path, it becomes quite = possible for a control plane process to monitor that register and = initiate DHCP queries to verify the address and obtain the state from = DHCP server. This could be done at a controlled rate per port, to = prevent what amounts to a DOS multiplier in which a source address = "scan" results in a DHCP query assault on the server. In the event that a switch restarts, that logic obviously happens across = the board. It can result in a burst comparable in size to the number of = ports on the switch in a short interval, but that is not a continuing = behavior. On Mar 24, 2010, at 12:20 PM, Joel M. Halpern wrote: > We are almost at the crux of my concern. > Looking at point 2, we end up saying something along the lines of >=20 > A SAVI-DHCP device SHOULD us non-volatile storage for state = information unless it can know that it is directly connected to the = client. >=20 > Now, presume that an implementor is trying to comply. And he builds a = SAVI-DHCP device that does not have non-volatile storage, because his = primary market is cases where clients are directly attached. > And it gets sold to someone whose network is primarily used with = clients directly attached to the SAVI device. So far so good. >=20 > Now suppose that someone, possibly without authority but without = prohibition, slaps a hub between their station and the SAVI device. The = SAVI device is now technically not behaving right. It can not function = properly. If the SAVI device could detect this, I would say "okay, = generate an alert. Things happen." But the SAVI device can't tell. = (With the dual uplink case, the SAVI device can tell because it gets STP = over its SAVI enforced ports.) >=20 > It is at least somewhat unusual to write a SHOULD where the exception = is undetectable. >=20 > Yours, > Joel >=20 > Bi Jun wrote: >> Hi Jole, >> thanks for the explanation. >> But if the host is connected with a hub, then >> (1) as I said in my last email, if it is dual uplinks in marcelo's = ppt, it will be no problem. >> (2) if it is single uplink hub, then under nv-memory storage at = savi-switch, do we still need data-triggered. >> thanks, >> Jun Bi >> -------------------------------------------------- >> From: "Joel M. Halpern" >> Sent: Wednesday, March 24, 2010 8:17 AM >> Cc: "SAVI Mailing List" >> Subject: Re: [savi] Points raised regarding DHCP solution >>> The current proposals on the table call for different behaviors (or = at least different requirements on capabilities) for directly connected = and indirectly connected SAVI devices. >>> Thus, the device needs to be able to verify that it is using the = right capabilities, or is unable to perform its job. >>> But doing so requires being able to detect the configuration. >>>=20 >>> Yours, >>> Joel >>>=20 >>> Bi Jun wrote: >>>> sorry for my misunderstanding. >>>> Why you think automatically detecting a hub by a savi switch is so = important after I have explained in Marcelo's case the hub is no problem = ? >>>>=20 >>>> thanks, >>>> Jun Bi >>>>=20 >>>> -------------------------------------------------- >>>> From: "Joel M. Halpern" >>>> Sent: Tuesday, March 23, 2010 11:49 PM >>>> To: "Jun Bi" >>>> Cc: "SAVI Mailing List" >>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>=20 >>>>> My final comment, which you quoted, was not concerned with the = specialized two-switch case. There are many subtle arguments we can = have over what the right handling is for the two-switch case. >>>>>=20 >>>>> I am still trying to figure out how the SAVI switch will know if a = single hub has been placed between it and the client. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> Jun Bi wrote: >>>>>>=20 >>>>>>> However, my question is how the SAVI device would determine that = there >>>>>>> is a hub between it and the end user machines. Should it try to = guess that the presence of multiple MAC addresses means a hub? What if = only one port in the hub is in use? There are still probably for the = system caused by the presence of the hub. >>>>>>=20 >>>>>> Dear Jole, >>>>>>=20 >>>>>> Thank you very much for your reply. >>>>>>=20 >>>>>> In my last email, I said if in Marcelo's case SWITCH-II is only a = hub, then because hub will boardcast the packets (duplicate packets to = both SAVI1 and SAVI2), then both SAVI1 and SAVI2 will know the equal = binding by control packet based binding, then it will no the problem = Marcelo mentioned. >>>>>>=20 >>>>>> thanks, >>>>>> Jun Bi >>>>>>=20 >>>>>>=20 >>>>>> -------------------------------------------------- >>>>>> From: "Joel M. Halpern" >>>>>> Sent: Tuesday, March 23, 2010 11:08 PM >>>>>> To: "Jun Bi" >>>>>> Cc: "SAVI Mailing List" >>>>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>>>=20 >>>>>>> Jun, I think I follow part of your comment, and then get lost. >>>>>>>=20 >>>>>>> For the topology change argument,it is the case that the SAVI = switch would have to be receiving STP (or RSTP, or TRILL, or ...) = packets on the interface on which it is applying SAVI controls. This is = clearly detectable, and the SAVI device can complain to management if it = is not prepared to code with that combination. Workable. >>>>>>>=20 >>>>>>> However, my question is how the SAVI device would determine that = there is a hub between it and the end user machines. Should it try to = guess that the presence of multiple MAC addresses means a hub? What if = only one port in the hub is in use? There are still probably for the = system caused by the presence of the hub. >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>> Jun Bi wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -------------------------------------------------- >>>>>>>> From: "Joel M. Halpern" >>>>>>>> Sent: Tuesday, March 23, 2010 6:32 PM >>>>>>>> To: "SAVI Mailing List" >>>>>>>> Subject: [savi] Points raised regarding DHCP solution >>>>>>>>=20 >>>>>>>>> The large question I raised was whether it was reasonable to = treat as knowable the question of whether the host is directly connected = to the SAVI switch. >>>>>>>>=20 >>>>>>>> May I make my point more clearly? >>>>>>>> Switch-host connection is just one easy case to understand that = Marcelo's case >>>>>>>> is not the normal case in real deployment. >>>>>>>>=20 >>>>>>>> I meant, as an administrator, we do know the topology I manage. >>>>>>>> In Marcelo's case are very special from deployment view point, = because it needs >>>>>>>> the dual-uplinks to SAVI switches. There are 3 situation I can = image if I met this >>>>>>>> case as an administrator. >>>>>>>>=20 >>>>>>>> If Switch II is a normal switch owned by the administrator, = then because enabling the data-triggered functions will cost the = administer too much money (to buy a higher-end switch), then I will = actually upgrade savi-software at that normal switch (if only implement = control based binding, it's very light-weight just like ABC for a switch = to upgrade to savi, based on our REAL deployment experience), or I can = even buy a new low cost savi-switch to replace Switch II. >>>>>>>>=20 >>>>>>>> If Switch II is a normal switch but owned by user, then if he = do dual uplinks, he >>>>>>>> has to report to me the administrator because it will change = the topology I am managing. If I permit, then I know which ports I need = to configure to enable the >>>>>>>> data-triggered functions. If he doesn't report to me, then he = will be responsible >>>>>>>> for his possible broken (one possible way is he repairs his = network connection). (In reality, I will kindly suggest him to upgrade = to savi-software.) >>>>>>>>=20 >>>>>>>> If switch II is a hub which is not upgradable. Then the packets = are boardcasting. >>>>>>>> Then SAVI-1 and SAVI-2 can know ALL control packets, then setup = equal binding table for this hub. Then we actually don't need to enable = data-triggered functions. >>>>>>>>=20 >>>>>>>> So my conclusion is, in reality, most of Marcelo's = consideration won't actually happen (I think Fred Baker has the same = points when he replied Marcelo in the mailing-list). In the worst case, = if I have to enable data-trigger functions for some cases, I know where = to configure it, I don't need to enable it at any port of any switch. = Therefore, it should not be a MUST function in SAVI (both for dhcp and = slaac). >>>>>>>>=20 >>>>>>>> Thank you very much ! >>>>>>>> Jun Bi >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regarding the specifics of the presentation, I commented that = I consider expecting the user to repair his network connection to be = unacceptable. Many naive users simply do not even understand that = question. >>>>>>>>>=20 >>>>>>>>> Regarding the suggestion of using short DHCP lease times, this = would require that we ALWAYS use very short lifetimes, since the lease = that needs to be short is the one that was sent before the failure. This = seems to be a very bad idea. >>>>>>>>>=20 >>>>>>>>> Yours, >>>>>>>>> Joel M. Halpern >>>>>>>>> _______________________________________________ >>>>>>>>> savi mailing list >>>>>>>>> savi@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>=20 >>>>=20 >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>>=20 > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi http://www.ipinc.net/IPv4.GIF From junbi@cernet.edu.cn Wed Mar 24 13:07:18 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A393A6D32 for ; Wed, 24 Mar 2010 13:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.028 X-Spam-Level: *** X-Spam-Status: No, score=3.028 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_HAS_XAIMC=2.696, J_CHICKENPOX_82=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iw0GhhJJql9k for ; Wed, 24 Mar 2010 13:07:16 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id B14F33A6918 for ; Wed, 24 Mar 2010 13:07:15 -0700 (PDT) Received: from junbiVAIO([130.129.30.129]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54baaabfb; Thu, 25 Mar 2010 04:07:35 +0800 Message-ID: <7CF1745F217E41799193D2546C8FCCE4@junbiVAIO> From: "Bi Jun" To: "Fred Baker" , "Joel M. Halpern" References: <4BA96BAA.5020507@joelhalpern.com><112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO><4BA9AC7A.2010407@joelhalpern.com><4BA9B60A.3050404@joelhalpern.com><16A243CC6D724738A1FC22DC792FDB24@junbiVAIO> <4BAA2D12.6070903@joelhalpern.com> <4BAA65F2.6020300@joelhalpern.com> <5B679E2B-CEF3-4231-A899-267435243422@cisco.com> In-Reply-To: <5B679E2B-CEF3-4231-A899-267435243422@cisco.com> Date: Wed, 24 Mar 2010 13:07:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: 1b7r6uXB Cc: SAVI Mailing List Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 20:07:19 -0000 Hi Fred and Joel, I think Fred is proposing to have a counter/statistics triggered alert or probe (instead of data-triggered).I do think it's doable. As I presented in my CERNET2 SAVI deployment report, I reported the SAVI CLI or MIBs the vendors implemented, there is a statistics info on the number of packet dropped at a specific port (we are showing in the SAVI management system' user interface). So the savi-switch can get that counter then do a CPU action (rate controllable) by a SNMP trap to manager system or a probe (LEASEQUARY or DAD-NS for dhcp; DAD-NS for slaac). It's not data plan triggered, so the cost to switch is not too much, and by our experience, the vendors will accept to implement it. thanks, Jun thanks, Jun Bi -------------------------------------------------- From: "Fred Baker" Sent: Wednesday, March 24, 2010 12:37 PM To: "Joel M. Halpern" Cc: "Bi Jun" ; "SAVI Mailing List" Subject: Re: [savi] Points raised regarding DHCP solution > As we discussed in private email last week, I'm very concerned at the > mention of using non-volatile RAM to store data that is ephemeral in > nature. I would far rather find a way to discover the current state of the > network, which may be the same or different than the state before the > switch restarted, than remember something in non-volatile memory that may > or may not be valid at the point it is needed or used. > > Let me give you one potential implementation. Consider a switch that for > whatever reason is discarding datagrams from a given port because they use > an IPv6 source address that is not in its tables. For various reasons, it > very likely has a counter, on the switch or VLAN if not on the port > itself. It could also maintain a register or FIFO to capture the source > IPv6 and MAC addresses this happened on. Without putting the logic for > generating the request into the data path, it becomes quite possible for a > control plane process to monitor that register and initiate DHCP queries > to verify the address and obtain the state from DHCP server. This could be > done at a controlled rate per port, to prevent what amounts to a DOS > multiplier in which a source address "scan" results in a DHCP query > assault on the server. > > In the event that a switch restarts, that logic obviously happens across > the board. It can result in a burst comparable in size to the number of > ports on the switch in a short interval, but that is not a continuing > behavior. > > On Mar 24, 2010, at 12:20 PM, Joel M. Halpern wrote: > >> We are almost at the crux of my concern. >> Looking at point 2, we end up saying something along the lines of >> >> A SAVI-DHCP device SHOULD us non-volatile storage for state information >> unless it can know that it is directly connected to the client. >> >> Now, presume that an implementor is trying to comply. And he builds a >> SAVI-DHCP device that does not have non-volatile storage, because his >> primary market is cases where clients are directly attached. >> And it gets sold to someone whose network is primarily used with clients >> directly attached to the SAVI device. So far so good. >> >> Now suppose that someone, possibly without authority but without >> prohibition, slaps a hub between their station and the SAVI device. The >> SAVI device is now technically not behaving right. It can not function >> properly. If the SAVI device could detect this, I would say "okay, >> generate an alert. Things happen." But the SAVI device can't tell. >> (With the dual uplink case, the SAVI device can tell because it gets STP >> over its SAVI enforced ports.) >> >> It is at least somewhat unusual to write a SHOULD where the exception is >> undetectable. >> >> Yours, >> Joel >> >> Bi Jun wrote: >>> Hi Jole, >>> thanks for the explanation. >>> But if the host is connected with a hub, then >>> (1) as I said in my last email, if it is dual uplinks in marcelo's ppt, >>> it will be no problem. >>> (2) if it is single uplink hub, then under nv-memory storage at >>> savi-switch, do we still need data-triggered. >>> thanks, >>> Jun Bi >>> -------------------------------------------------- >>> From: "Joel M. Halpern" >>> Sent: Wednesday, March 24, 2010 8:17 AM >>> Cc: "SAVI Mailing List" >>> Subject: Re: [savi] Points raised regarding DHCP solution >>>> The current proposals on the table call for different behaviors (or at >>>> least different requirements on capabilities) for directly connected >>>> and indirectly connected SAVI devices. >>>> Thus, the device needs to be able to verify that it is using the right >>>> capabilities, or is unable to perform its job. >>>> But doing so requires being able to detect the configuration. >>>> >>>> Yours, >>>> Joel >>>> >>>> Bi Jun wrote: >>>>> sorry for my misunderstanding. >>>>> Why you think automatically detecting a hub by a savi switch is so >>>>> important after I have explained in Marcelo's case the hub is no >>>>> problem ? >>>>> >>>>> thanks, >>>>> Jun Bi >>>>> >>>>> -------------------------------------------------- >>>>> From: "Joel M. Halpern" >>>>> Sent: Tuesday, March 23, 2010 11:49 PM >>>>> To: "Jun Bi" >>>>> Cc: "SAVI Mailing List" >>>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>> >>>>>> My final comment, which you quoted, was not concerned with the >>>>>> specialized two-switch case. There are many subtle arguments we can >>>>>> have over what the right handling is for the two-switch case. >>>>>> >>>>>> I am still trying to figure out how the SAVI switch will know if a >>>>>> single hub has been placed between it and the client. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> Jun Bi wrote: >>>>>>> >>>>>>>> However, my question is how the SAVI device would determine that >>>>>>>> there >>>>>>>> is a hub between it and the end user machines. Should it try to >>>>>>>> guess that the presence of multiple MAC addresses means a hub? >>>>>>>> What if only one port in the hub is in use? There are still >>>>>>>> probably for the system caused by the presence of the hub. >>>>>>> >>>>>>> Dear Jole, >>>>>>> >>>>>>> Thank you very much for your reply. >>>>>>> >>>>>>> In my last email, I said if in Marcelo's case SWITCH-II is only a >>>>>>> hub, then because hub will boardcast the packets (duplicate packets >>>>>>> to both SAVI1 and SAVI2), then both SAVI1 and SAVI2 will know the >>>>>>> equal binding by control packet based binding, then it will no the >>>>>>> problem Marcelo mentioned. >>>>>>> >>>>>>> thanks, >>>>>>> Jun Bi >>>>>>> >>>>>>> >>>>>>> -------------------------------------------------- >>>>>>> From: "Joel M. Halpern" >>>>>>> Sent: Tuesday, March 23, 2010 11:08 PM >>>>>>> To: "Jun Bi" >>>>>>> Cc: "SAVI Mailing List" >>>>>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>>>> >>>>>>>> Jun, I think I follow part of your comment, and then get lost. >>>>>>>> >>>>>>>> For the topology change argument,it is the case that the SAVI >>>>>>>> switch would have to be receiving STP (or RSTP, or TRILL, or ...) >>>>>>>> packets on the interface on which it is applying SAVI controls. >>>>>>>> This is clearly detectable, and the SAVI device can complain to >>>>>>>> management if it is not prepared to code with that combination. >>>>>>>> Workable. >>>>>>>> >>>>>>>> However, my question is how the SAVI device would determine that >>>>>>>> there is a hub between it and the end user machines. Should it try >>>>>>>> to guess that the presence of multiple MAC addresses means a hub? >>>>>>>> What if only one port in the hub is in use? There are still >>>>>>>> probably for the system caused by the presence of the hub. >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> Jun Bi wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> -------------------------------------------------- >>>>>>>>> From: "Joel M. Halpern" >>>>>>>>> Sent: Tuesday, March 23, 2010 6:32 PM >>>>>>>>> To: "SAVI Mailing List" >>>>>>>>> Subject: [savi] Points raised regarding DHCP solution >>>>>>>>> >>>>>>>>>> The large question I raised was whether it was reasonable to >>>>>>>>>> treat as knowable the question of whether the host is directly >>>>>>>>>> connected to the SAVI switch. >>>>>>>>> >>>>>>>>> May I make my point more clearly? >>>>>>>>> Switch-host connection is just one easy case to understand that >>>>>>>>> Marcelo's case >>>>>>>>> is not the normal case in real deployment. >>>>>>>>> >>>>>>>>> I meant, as an administrator, we do know the topology I manage. >>>>>>>>> In Marcelo's case are very special from deployment view point, >>>>>>>>> because it needs >>>>>>>>> the dual-uplinks to SAVI switches. There are 3 situation I can >>>>>>>>> image if I met this >>>>>>>>> case as an administrator. >>>>>>>>> >>>>>>>>> If Switch II is a normal switch owned by the administrator, then >>>>>>>>> because enabling the data-triggered functions will cost the >>>>>>>>> administer too much money (to buy a higher-end switch), then I >>>>>>>>> will actually upgrade savi-software at that normal switch (if only >>>>>>>>> implement control based binding, it's very light-weight just like >>>>>>>>> ABC for a switch to upgrade to savi, based on our REAL deployment >>>>>>>>> experience), or I can even buy a new low cost savi-switch to >>>>>>>>> replace Switch II. >>>>>>>>> >>>>>>>>> If Switch II is a normal switch but owned by user, then if he do >>>>>>>>> dual uplinks, he >>>>>>>>> has to report to me the administrator because it will change the >>>>>>>>> topology I am managing. If I permit, then I know which ports I >>>>>>>>> need to configure to enable the >>>>>>>>> data-triggered functions. If he doesn't report to me, then he will >>>>>>>>> be responsible >>>>>>>>> for his possible broken (one possible way is he repairs his >>>>>>>>> network connection). (In reality, I will kindly suggest him to >>>>>>>>> upgrade to savi-software.) >>>>>>>>> >>>>>>>>> If switch II is a hub which is not upgradable. Then the packets >>>>>>>>> are boardcasting. >>>>>>>>> Then SAVI-1 and SAVI-2 can know ALL control packets, then setup >>>>>>>>> equal binding table for this hub. Then we actually don't need to >>>>>>>>> enable data-triggered functions. >>>>>>>>> >>>>>>>>> So my conclusion is, in reality, most of Marcelo's consideration >>>>>>>>> won't actually happen (I think Fred Baker has the same points when >>>>>>>>> he replied Marcelo in the mailing-list). In the worst case, if I >>>>>>>>> have to enable data-trigger functions for some cases, I know where >>>>>>>>> to configure it, I don't need to enable it at any port of any >>>>>>>>> switch. Therefore, it should not be a MUST function in SAVI (both >>>>>>>>> for dhcp and slaac). >>>>>>>>> >>>>>>>>> Thank you very much ! >>>>>>>>> Jun Bi >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regarding the specifics of the presentation, I commented that I >>>>>>>>>> consider expecting the user to repair his network connection to >>>>>>>>>> be unacceptable. Many naive users simply do not even understand >>>>>>>>>> that question. >>>>>>>>>> >>>>>>>>>> Regarding the suggestion of using short DHCP lease times, this >>>>>>>>>> would require that we ALWAYS use very short lifetimes, since the >>>>>>>>>> lease that needs to be short is the one that was sent before the >>>>>>>>>> failure. This seems to be a very bad idea. >>>>>>>>>> >>>>>>>>>> Yours, >>>>>>>>>> Joel M. Halpern >>>>>>>>>> _______________________________________________ >>>>>>>>>> savi mailing list >>>>>>>>>> savi@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> >>>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > http://www.ipinc.net/IPv4.GIF > From fred@cisco.com Wed Mar 24 13:14:31 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F87A3A6BAF for ; Wed, 24 Mar 2010 13:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.307 X-Spam-Level: X-Spam-Status: No, score=-108.307 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2CHeHkCF0ua for ; Wed, 24 Mar 2010 13:14:28 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 639CA3A6950 for ; Wed, 24 Mar 2010 13:14:01 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACsPqkurR7Hu/2dsb2JhbACbG3OnRpkLgluCIwSDHosq X-IronPort-AV: E=Sophos;i="4.51,302,1267401600"; d="scan'208";a="171779133" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 24 Mar 2010 20:14:22 +0000 Received: from dhcp-wireless-open-abg-27-51.meeting.ietf.org (sjc-vpn5-1077.cisco.com [10.21.92.53]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2OKEMlu017700; Wed, 24 Mar 2010 20:14:22 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker X-Priority: 3 In-Reply-To: <7CF1745F217E41799193D2546C8FCCE4@junbiVAIO> Date: Wed, 24 Mar 2010 13:14:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA96BAA.5020507@joelhalpern.com><112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO><4BA9AC7A.2010407@joelhalpern.com><4BA9B60A.3050404@joelhalpern.com><16A243CC6D724738A1FC22DC792FDB24@junbiVAIO> <4BAA2D12.6070903@joelhalpern.com> <4BAA65F2.6020300@joelhalpern.com> <5B679E2B-CEF3-4231-A899-267435243422@cisco.com> <7CF1745F217E41799193D2546C8FCCE4@junbiVAIO> To: "Bi Jun" X-Mailer: Apple Mail (2.1077) Cc: SAVI Mailing List Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 20:14:31 -0000 On Mar 24, 2010, at 1:07 PM, Bi Jun wrote: > Hi Fred and Joel, >=20 > I think Fred is proposing to have a counter/statistics triggered alert = or probe (instead of data-triggered).I do think it's doable. I suggest it is possible. I can tell you that I once implemented an = ethernet switch that used that mechanism in managing its address table - = the FIFO (a circular queue in which I logged the source address and port = from messages I received) was used as an input to a process that = searched for every such address, added them if needed, and by the way = aged out addresses that were not used over time. Implementation = experience, although dated, says that such an approach is feasible and = has the effect of rate-limiting high rate changes. I would not recommend that the working group specify the implementation. = The point of giving a sample implementation is clarity, not requirement. > As I presented in my CERNET2 SAVI deployment report, I reported the = SAVI CLI or MIBs the vendors implemented, there is a statistics info on = the number of packet dropped at a specific port (we are showing in the = SAVI management system' user interface). So the savi-switch can get that = counter then do a CPU action (rate controllable) by a SNMP trap to = manager system or a probe (LEASEQUARY or DAD-NS for dhcp; DAD-NS for = slaac). It's not data plan triggered, so the cost to switch is not too = much, and by our experience, the vendors will accept to implement it. yes > thanks, > Jun >=20 > thanks, > Jun Bi >=20 > -------------------------------------------------- > From: "Fred Baker" > Sent: Wednesday, March 24, 2010 12:37 PM > To: "Joel M. Halpern" > Cc: "Bi Jun" ; "SAVI Mailing List" = > Subject: Re: [savi] Points raised regarding DHCP solution >=20 >> As we discussed in private email last week, I'm very concerned at the = mention of using non-volatile RAM to store data that is ephemeral in = nature. I would far rather find a way to discover the current state of = the network, which may be the same or different than the state before = the switch restarted, than remember something in non-volatile memory = that may or may not be valid at the point it is needed or used. >>=20 >> Let me give you one potential implementation. Consider a switch that = for whatever reason is discarding datagrams from a given port because = they use an IPv6 source address that is not in its tables. For various = reasons, it very likely has a counter, on the switch or VLAN if not on = the port itself. It could also maintain a register or FIFO to capture = the source IPv6 and MAC addresses this happened on. Without putting the = logic for generating the request into the data path, it becomes quite = possible for a control plane process to monitor that register and = initiate DHCP queries to verify the address and obtain the state from = DHCP server. This could be done at a controlled rate per port, to = prevent what amounts to a DOS multiplier in which a source address = "scan" results in a DHCP query assault on the server. >>=20 >> In the event that a switch restarts, that logic obviously happens = across the board. It can result in a burst comparable in size to the = number of ports on the switch in a short interval, but that is not a = continuing behavior. >>=20 >> On Mar 24, 2010, at 12:20 PM, Joel M. Halpern wrote: >>=20 >>> We are almost at the crux of my concern. >>> Looking at point 2, we end up saying something along the lines of >>>=20 >>> A SAVI-DHCP device SHOULD us non-volatile storage for state = information unless it can know that it is directly connected to the = client. >>>=20 >>> Now, presume that an implementor is trying to comply. And he builds = a SAVI-DHCP device that does not have non-volatile storage, because his = primary market is cases where clients are directly attached. >>> And it gets sold to someone whose network is primarily used with = clients directly attached to the SAVI device. So far so good. >>>=20 >>> Now suppose that someone, possibly without authority but without = prohibition, slaps a hub between their station and the SAVI device. The = SAVI device is now technically not behaving right. It can not function = properly. If the SAVI device could detect this, I would say "okay, = generate an alert. Things happen." But the SAVI device can't tell. = (With the dual uplink case, the SAVI device can tell because it gets STP = over its SAVI enforced ports.) >>>=20 >>> It is at least somewhat unusual to write a SHOULD where the = exception is undetectable. >>>=20 >>> Yours, >>> Joel >>>=20 >>> Bi Jun wrote: >>>> Hi Jole, >>>> thanks for the explanation. >>>> But if the host is connected with a hub, then >>>> (1) as I said in my last email, if it is dual uplinks in marcelo's = ppt, it will be no problem. >>>> (2) if it is single uplink hub, then under nv-memory storage at = savi-switch, do we still need data-triggered. >>>> thanks, >>>> Jun Bi >>>> -------------------------------------------------- >>>> From: "Joel M. Halpern" >>>> Sent: Wednesday, March 24, 2010 8:17 AM >>>> Cc: "SAVI Mailing List" >>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>> The current proposals on the table call for different behaviors = (or at least different requirements on capabilities) for directly = connected and indirectly connected SAVI devices. >>>>> Thus, the device needs to be able to verify that it is using the = right capabilities, or is unable to perform its job. >>>>> But doing so requires being able to detect the configuration. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> Bi Jun wrote: >>>>>> sorry for my misunderstanding. >>>>>> Why you think automatically detecting a hub by a savi switch is = so important after I have explained in Marcelo's case the hub is no = problem ? >>>>>>=20 >>>>>> thanks, >>>>>> Jun Bi >>>>>>=20 >>>>>> -------------------------------------------------- >>>>>> From: "Joel M. Halpern" >>>>>> Sent: Tuesday, March 23, 2010 11:49 PM >>>>>> To: "Jun Bi" >>>>>> Cc: "SAVI Mailing List" >>>>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>>>=20 >>>>>>> My final comment, which you quoted, was not concerned with the = specialized two-switch case. There are many subtle arguments we can = have over what the right handling is for the two-switch case. >>>>>>>=20 >>>>>>> I am still trying to figure out how the SAVI switch will know if = a single hub has been placed between it and the client. >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>> Jun Bi wrote: >>>>>>>>=20 >>>>>>>>> However, my question is how the SAVI device would determine = that there >>>>>>>>> is a hub between it and the end user machines. Should it try = to guess that the presence of multiple MAC addresses means a hub? What = if only one port in the hub is in use? There are still probably for the = system caused by the presence of the hub. >>>>>>>>=20 >>>>>>>> Dear Jole, >>>>>>>>=20 >>>>>>>> Thank you very much for your reply. >>>>>>>>=20 >>>>>>>> In my last email, I said if in Marcelo's case SWITCH-II is only = a hub, then because hub will boardcast the packets (duplicate packets to = both SAVI1 and SAVI2), then both SAVI1 and SAVI2 will know the equal = binding by control packet based binding, then it will no the problem = Marcelo mentioned. >>>>>>>>=20 >>>>>>>> thanks, >>>>>>>> Jun Bi >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -------------------------------------------------- >>>>>>>> From: "Joel M. Halpern" >>>>>>>> Sent: Tuesday, March 23, 2010 11:08 PM >>>>>>>> To: "Jun Bi" >>>>>>>> Cc: "SAVI Mailing List" >>>>>>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>>>>>=20 >>>>>>>>> Jun, I think I follow part of your comment, and then get lost. >>>>>>>>>=20 >>>>>>>>> For the topology change argument,it is the case that the SAVI = switch would have to be receiving STP (or RSTP, or TRILL, or ...) = packets on the interface on which it is applying SAVI controls. This is = clearly detectable, and the SAVI device can complain to management if it = is not prepared to code with that combination. Workable. >>>>>>>>>=20 >>>>>>>>> However, my question is how the SAVI device would determine = that there is a hub between it and the end user machines. Should it try = to guess that the presence of multiple MAC addresses means a hub? What = if only one port in the hub is in use? There are still probably for the = system caused by the presence of the hub. >>>>>>>>>=20 >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>>=20 >>>>>>>>> Jun Bi wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -------------------------------------------------- >>>>>>>>>> From: "Joel M. Halpern" >>>>>>>>>> Sent: Tuesday, March 23, 2010 6:32 PM >>>>>>>>>> To: "SAVI Mailing List" >>>>>>>>>> Subject: [savi] Points raised regarding DHCP solution >>>>>>>>>>=20 >>>>>>>>>>> The large question I raised was whether it was reasonable to = treat as knowable the question of whether the host is directly connected = to the SAVI switch. >>>>>>>>>>=20 >>>>>>>>>> May I make my point more clearly? >>>>>>>>>> Switch-host connection is just one easy case to understand = that Marcelo's case >>>>>>>>>> is not the normal case in real deployment. >>>>>>>>>>=20 >>>>>>>>>> I meant, as an administrator, we do know the topology I = manage. >>>>>>>>>> In Marcelo's case are very special from deployment view = point, because it needs >>>>>>>>>> the dual-uplinks to SAVI switches. There are 3 situation I = can image if I met this >>>>>>>>>> case as an administrator. >>>>>>>>>>=20 >>>>>>>>>> If Switch II is a normal switch owned by the administrator, = then because enabling the data-triggered functions will cost the = administer too much money (to buy a higher-end switch), then I will = actually upgrade savi-software at that normal switch (if only implement = control based binding, it's very light-weight just like ABC for a switch = to upgrade to savi, based on our REAL deployment experience), or I can = even buy a new low cost savi-switch to replace Switch II. >>>>>>>>>>=20 >>>>>>>>>> If Switch II is a normal switch but owned by user, then if he = do dual uplinks, he >>>>>>>>>> has to report to me the administrator because it will change = the topology I am managing. If I permit, then I know which ports I need = to configure to enable the >>>>>>>>>> data-triggered functions. If he doesn't report to me, then he = will be responsible >>>>>>>>>> for his possible broken (one possible way is he repairs his = network connection). (In reality, I will kindly suggest him to upgrade = to savi-software.) >>>>>>>>>>=20 >>>>>>>>>> If switch II is a hub which is not upgradable. Then the = packets are boardcasting. >>>>>>>>>> Then SAVI-1 and SAVI-2 can know ALL control packets, then = setup equal binding table for this hub. Then we actually don't need to = enable data-triggered functions. >>>>>>>>>>=20 >>>>>>>>>> So my conclusion is, in reality, most of Marcelo's = consideration won't actually happen (I think Fred Baker has the same = points when he replied Marcelo in the mailing-list). In the worst case, = if I have to enable data-trigger functions for some cases, I know where = to configure it, I don't need to enable it at any port of any switch. = Therefore, it should not be a MUST function in SAVI (both for dhcp and = slaac). >>>>>>>>>>=20 >>>>>>>>>> Thank you very much ! >>>>>>>>>> Jun Bi >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Regarding the specifics of the presentation, I commented = that I consider expecting the user to repair his network connection to = be unacceptable. Many naive users simply do not even understand that = question. >>>>>>>>>>>=20 >>>>>>>>>>> Regarding the suggestion of using short DHCP lease times, = this would require that we ALWAYS use very short lifetimes, since the = lease that needs to be short is the one that was sent before the = failure. This seems to be a very bad idea. >>>>>>>>>>>=20 >>>>>>>>>>> Yours, >>>>>>>>>>> Joel M. Halpern >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> savi mailing list >>>>>>>>>>> savi@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> savi mailing list >>>>>>> savi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>=20 >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>=20 >> http://www.ipinc.net/IPv4.GIF http://www.ipinc.net/IPv4.GIF From junbi@cernet.edu.cn Wed Mar 24 13:22:51 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BCC23A6BC2 for ; Wed, 24 Mar 2010 13:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.728 X-Spam-Level: ** X-Spam-Status: No, score=2.728 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_HAS_XAIMC=2.696, J_CHICKENPOX_82=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-jH-rk4uUUz for ; Wed, 24 Mar 2010 13:22:49 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 9BAA23A68F8 for ; Wed, 24 Mar 2010 13:22:46 -0700 (PDT) Received: from junbiVAIO([130.129.30.129]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm164baaaf9d; Thu, 25 Mar 2010 04:23:05 +0800 Message-ID: From: "Bi Jun" To: "Fred Baker" References: <4BA96BAA.5020507@joelhalpern.com><112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO><4BA9AC7A.2010407@joelhalpern.com><4BA9B60A.3050404@joelhalpern.com><16A243CC6D724738A1FC22DC792FDB24@junbiVAIO> <4BAA2D12.6070903@joelhalpern.com> <4BAA65F2.6020300@joelhalpern.com> <5B679E2B-CEF3-4231-A899-267435243422@cisco.com> <7CF1745F217E41799193D2546C8FCCE4@junbiVAIO> In-Reply-To: Date: Wed, 24 Mar 2010 13:23:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: 1U7G7uXB Cc: SAVI Mailing List Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 20:22:51 -0000 Yes, I do agree with Fred. It's not only good for savi-dhcp, but also resolve the problem of savi-slaac. (we do see the problem of data-triggered actions). Then can we move forward with Fred's proposal? thanks, Jun -------------------------------------------------- From: "Fred Baker" Sent: Wednesday, March 24, 2010 1:14 PM To: "Bi Jun" Cc: "Joel M. Halpern" ; "SAVI Mailing List" Subject: Re: [savi] Points raised regarding DHCP solution > > On Mar 24, 2010, at 1:07 PM, Bi Jun wrote: > >> Hi Fred and Joel, >> >> I think Fred is proposing to have a counter/statistics triggered alert or >> probe (instead of data-triggered).I do think it's doable. > > I suggest it is possible. I can tell you that I once implemented an > ethernet switch that used that mechanism in managing its address table - > the FIFO (a circular queue in which I logged the source address and port > from messages I received) was used as an input to a process that searched > for every such address, added them if needed, and by the way aged out > addresses that were not used over time. Implementation experience, > although dated, says that such an approach is feasible and has the effect > of rate-limiting high rate changes. > > I would not recommend that the working group specify the implementation. > The point of giving a sample implementation is clarity, not requirement. > >> As I presented in my CERNET2 SAVI deployment report, I reported the SAVI >> CLI or MIBs the vendors implemented, there is a statistics info on the >> number of packet dropped at a specific port (we are showing in the SAVI >> management system' user interface). So the savi-switch can get that >> counter then do a CPU action (rate controllable) by a SNMP trap to >> manager system or a probe (LEASEQUARY or DAD-NS for dhcp; DAD-NS for >> slaac). It's not data plan triggered, so the cost to switch is not too >> much, and by our experience, the vendors will accept to implement it. > > yes > >> thanks, >> Jun >> >> thanks, >> Jun Bi >> >> -------------------------------------------------- >> From: "Fred Baker" >> Sent: Wednesday, March 24, 2010 12:37 PM >> To: "Joel M. Halpern" >> Cc: "Bi Jun" ; "SAVI Mailing List" >> Subject: Re: [savi] Points raised regarding DHCP solution >> >>> As we discussed in private email last week, I'm very concerned at the >>> mention of using non-volatile RAM to store data that is ephemeral in >>> nature. I would far rather find a way to discover the current state of >>> the network, which may be the same or different than the state before >>> the switch restarted, than remember something in non-volatile memory >>> that may or may not be valid at the point it is needed or used. >>> >>> Let me give you one potential implementation. Consider a switch that for >>> whatever reason is discarding datagrams from a given port because they >>> use an IPv6 source address that is not in its tables. For various >>> reasons, it very likely has a counter, on the switch or VLAN if not on >>> the port itself. It could also maintain a register or FIFO to capture >>> the source IPv6 and MAC addresses this happened on. Without putting the >>> logic for generating the request into the data path, it becomes quite >>> possible for a control plane process to monitor that register and >>> initiate DHCP queries to verify the address and obtain the state from >>> DHCP server. This could be done at a controlled rate per port, to >>> prevent what amounts to a DOS multiplier in which a source address >>> "scan" results in a DHCP query assault on the server. >>> >>> In the event that a switch restarts, that logic obviously happens across >>> the board. It can result in a burst comparable in size to the number of >>> ports on the switch in a short interval, but that is not a continuing >>> behavior. >>> >>> On Mar 24, 2010, at 12:20 PM, Joel M. Halpern wrote: >>> >>>> We are almost at the crux of my concern. >>>> Looking at point 2, we end up saying something along the lines of >>>> >>>> A SAVI-DHCP device SHOULD us non-volatile storage for state information >>>> unless it can know that it is directly connected to the client. >>>> >>>> Now, presume that an implementor is trying to comply. And he builds a >>>> SAVI-DHCP device that does not have non-volatile storage, because his >>>> primary market is cases where clients are directly attached. >>>> And it gets sold to someone whose network is primarily used with >>>> clients directly attached to the SAVI device. So far so good. >>>> >>>> Now suppose that someone, possibly without authority but without >>>> prohibition, slaps a hub between their station and the SAVI device. >>>> The SAVI device is now technically not behaving right. It can not >>>> function properly. If the SAVI device could detect this, I would say >>>> "okay, generate an alert. Things happen." But the SAVI device can't >>>> tell. (With the dual uplink case, the SAVI device can tell because it >>>> gets STP over its SAVI enforced ports.) >>>> >>>> It is at least somewhat unusual to write a SHOULD where the exception >>>> is undetectable. >>>> >>>> Yours, >>>> Joel >>>> >>>> Bi Jun wrote: >>>>> Hi Jole, >>>>> thanks for the explanation. >>>>> But if the host is connected with a hub, then >>>>> (1) as I said in my last email, if it is dual uplinks in marcelo's >>>>> ppt, it will be no problem. >>>>> (2) if it is single uplink hub, then under nv-memory storage at >>>>> savi-switch, do we still need data-triggered. >>>>> thanks, >>>>> Jun Bi >>>>> -------------------------------------------------- >>>>> From: "Joel M. Halpern" >>>>> Sent: Wednesday, March 24, 2010 8:17 AM >>>>> Cc: "SAVI Mailing List" >>>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>>> The current proposals on the table call for different behaviors (or >>>>>> at least different requirements on capabilities) for directly >>>>>> connected and indirectly connected SAVI devices. >>>>>> Thus, the device needs to be able to verify that it is using the >>>>>> right capabilities, or is unable to perform its job. >>>>>> But doing so requires being able to detect the configuration. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> Bi Jun wrote: >>>>>>> sorry for my misunderstanding. >>>>>>> Why you think automatically detecting a hub by a savi switch is so >>>>>>> important after I have explained in Marcelo's case the hub is no >>>>>>> problem ? >>>>>>> >>>>>>> thanks, >>>>>>> Jun Bi >>>>>>> >>>>>>> -------------------------------------------------- >>>>>>> From: "Joel M. Halpern" >>>>>>> Sent: Tuesday, March 23, 2010 11:49 PM >>>>>>> To: "Jun Bi" >>>>>>> Cc: "SAVI Mailing List" >>>>>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>>>> >>>>>>>> My final comment, which you quoted, was not concerned with the >>>>>>>> specialized two-switch case. There are many subtle arguments we >>>>>>>> can have over what the right handling is for the two-switch case. >>>>>>>> >>>>>>>> I am still trying to figure out how the SAVI switch will know if a >>>>>>>> single hub has been placed between it and the client. >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> Jun Bi wrote: >>>>>>>>> >>>>>>>>>> However, my question is how the SAVI device would determine that >>>>>>>>>> there >>>>>>>>>> is a hub between it and the end user machines. Should it try to >>>>>>>>>> guess that the presence of multiple MAC addresses means a hub? >>>>>>>>>> What if only one port in the hub is in use? There are still >>>>>>>>>> probably for the system caused by the presence of the hub. >>>>>>>>> >>>>>>>>> Dear Jole, >>>>>>>>> >>>>>>>>> Thank you very much for your reply. >>>>>>>>> >>>>>>>>> In my last email, I said if in Marcelo's case SWITCH-II is only a >>>>>>>>> hub, then because hub will boardcast the packets (duplicate >>>>>>>>> packets to both SAVI1 and SAVI2), then both SAVI1 and SAVI2 will >>>>>>>>> know the equal binding by control packet based binding, then it >>>>>>>>> will no the problem Marcelo mentioned. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Jun Bi >>>>>>>>> >>>>>>>>> >>>>>>>>> -------------------------------------------------- >>>>>>>>> From: "Joel M. Halpern" >>>>>>>>> Sent: Tuesday, March 23, 2010 11:08 PM >>>>>>>>> To: "Jun Bi" >>>>>>>>> Cc: "SAVI Mailing List" >>>>>>>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>>>>>> >>>>>>>>>> Jun, I think I follow part of your comment, and then get lost. >>>>>>>>>> >>>>>>>>>> For the topology change argument,it is the case that the SAVI >>>>>>>>>> switch would have to be receiving STP (or RSTP, or TRILL, or ...) >>>>>>>>>> packets on the interface on which it is applying SAVI controls. >>>>>>>>>> This is clearly detectable, and the SAVI device can complain to >>>>>>>>>> management if it is not prepared to code with that combination. >>>>>>>>>> Workable. >>>>>>>>>> >>>>>>>>>> However, my question is how the SAVI device would determine that >>>>>>>>>> there is a hub between it and the end user machines. Should it >>>>>>>>>> try to guess that the presence of multiple MAC addresses means a >>>>>>>>>> hub? What if only one port in the hub is in use? There are still >>>>>>>>>> probably for the system caused by the presence of the hub. >>>>>>>>>> >>>>>>>>>> Yours, >>>>>>>>>> Joel >>>>>>>>>> >>>>>>>>>> Jun Bi wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -------------------------------------------------- >>>>>>>>>>> From: "Joel M. Halpern" >>>>>>>>>>> Sent: Tuesday, March 23, 2010 6:32 PM >>>>>>>>>>> To: "SAVI Mailing List" >>>>>>>>>>> Subject: [savi] Points raised regarding DHCP solution >>>>>>>>>>> >>>>>>>>>>>> The large question I raised was whether it was reasonable to >>>>>>>>>>>> treat as knowable the question of whether the host is directly >>>>>>>>>>>> connected to the SAVI switch. >>>>>>>>>>> >>>>>>>>>>> May I make my point more clearly? >>>>>>>>>>> Switch-host connection is just one easy case to understand that >>>>>>>>>>> Marcelo's case >>>>>>>>>>> is not the normal case in real deployment. >>>>>>>>>>> >>>>>>>>>>> I meant, as an administrator, we do know the topology I manage. >>>>>>>>>>> In Marcelo's case are very special from deployment view point, >>>>>>>>>>> because it needs >>>>>>>>>>> the dual-uplinks to SAVI switches. There are 3 situation I can >>>>>>>>>>> image if I met this >>>>>>>>>>> case as an administrator. >>>>>>>>>>> >>>>>>>>>>> If Switch II is a normal switch owned by the administrator, then >>>>>>>>>>> because enabling the data-triggered functions will cost the >>>>>>>>>>> administer too much money (to buy a higher-end switch), then I >>>>>>>>>>> will actually upgrade savi-software at that normal switch (if >>>>>>>>>>> only implement control based binding, it's very light-weight >>>>>>>>>>> just like ABC for a switch to upgrade to savi, based on our REAL >>>>>>>>>>> deployment experience), or I can even buy a new low cost >>>>>>>>>>> savi-switch to replace Switch II. >>>>>>>>>>> >>>>>>>>>>> If Switch II is a normal switch but owned by user, then if he do >>>>>>>>>>> dual uplinks, he >>>>>>>>>>> has to report to me the administrator because it will change the >>>>>>>>>>> topology I am managing. If I permit, then I know which ports I >>>>>>>>>>> need to configure to enable the >>>>>>>>>>> data-triggered functions. If he doesn't report to me, then he >>>>>>>>>>> will be responsible >>>>>>>>>>> for his possible broken (one possible way is he repairs his >>>>>>>>>>> network connection). (In reality, I will kindly suggest him to >>>>>>>>>>> upgrade to savi-software.) >>>>>>>>>>> >>>>>>>>>>> If switch II is a hub which is not upgradable. Then the packets >>>>>>>>>>> are boardcasting. >>>>>>>>>>> Then SAVI-1 and SAVI-2 can know ALL control packets, then setup >>>>>>>>>>> equal binding table for this hub. Then we actually don't need to >>>>>>>>>>> enable data-triggered functions. >>>>>>>>>>> >>>>>>>>>>> So my conclusion is, in reality, most of Marcelo's consideration >>>>>>>>>>> won't actually happen (I think Fred Baker has the same points >>>>>>>>>>> when he replied Marcelo in the mailing-list). In the worst case, >>>>>>>>>>> if I have to enable data-trigger functions for some cases, I >>>>>>>>>>> know where to configure it, I don't need to enable it at any >>>>>>>>>>> port of any switch. Therefore, it should not be a MUST function >>>>>>>>>>> in SAVI (both for dhcp and slaac). >>>>>>>>>>> >>>>>>>>>>> Thank you very much ! >>>>>>>>>>> Jun Bi >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regarding the specifics of the presentation, I commented that I >>>>>>>>>>>> consider expecting the user to repair his network connection to >>>>>>>>>>>> be unacceptable. Many naive users simply do not even understand >>>>>>>>>>>> that question. >>>>>>>>>>>> >>>>>>>>>>>> Regarding the suggestion of using short DHCP lease times, this >>>>>>>>>>>> would require that we ALWAYS use very short lifetimes, since >>>>>>>>>>>> the lease that needs to be short is the one that was sent >>>>>>>>>>>> before the failure. This seems to be a very bad idea. >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel M. Halpern >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> savi mailing list >>>>>>>>>>>> savi@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> savi mailing list >>>>>>>> savi@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>> >>> http://www.ipinc.net/IPv4.GIF > > http://www.ipinc.net/IPv4.GIF > From junbi@cernet.edu.cn Wed Mar 24 15:12:04 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14D13A6D99 for ; Wed, 24 Mar 2010 15:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.477 X-Spam-Level: *** X-Spam-Status: No, score=3.477 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, FH_HAS_XAIMC=2.696, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQv+faCg5ByM for ; Wed, 24 Mar 2010 15:12:03 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 1E7363A6A41 for ; Wed, 24 Mar 2010 15:12:01 -0700 (PDT) Received: from junbiVAIO([130.129.30.129]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54baaf2f4; Thu, 25 Mar 2010 06:12:21 +0800 Message-ID: <641E6FDA1016431AB7B61CF4178318BC@junbiVAIO> From: "Bi Jun" To: "Joel M. Halpern" References: <4BA96BAA.5020507@joelhalpern.com><112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO><4BA9AC7A.2010407@joelhalpern.com><4BA9B60A.3050404@joelhalpern.com><16A243CC6D724738A1FC22DC792FDB24@junbiVAIO> <4BAA2D12.6070903@joelhalpern.com> <4BAA65F2.6020300@joelhalpern.com> In-Reply-To: <4BAA65F2.6020300@joelhalpern.com> Date: Wed, 24 Mar 2010 15:12:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: kNRo8uXB Cc: SAVI Mailing List Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 22:12:04 -0000 -------------------------------------------------- From: "Joel M. Halpern" Sent: Wednesday, March 24, 2010 12:20 PM To: "Bi Jun" Cc: "SAVI Mailing List" Subject: Re: [savi] Points raised regarding DHCP solution > We are almost at the crux of my concern. > Looking at point 2, we end up saying something along the lines of > > A SAVI-DHCP device SHOULD us non-volatile storage for state information > unless it can know that it is directly connected to the client. > > Now, presume that an implementor is trying to comply. And he builds a > SAVI-DHCP device that does not have non-volatile storage, because his > primary market is cases where clients are directly attached. > And it gets sold to someone whose network is primarily used with clients > directly attached to the SAVI device. So far so good. After the SAVI meeting, we consult the vendors about the implementation of savi switch we bought and are deploying, the good news is that the vendors actual already save the binding table in NV-storage immediately after the binding set-up, even in a very low-end access switch (e.g 3com E026), without our requirement. So there will be no objection from vendors. So we could consider to make the NV-storage as MUST in the draft, then I think it will satisfy your question. thanks, Jun > > Now suppose that someone, possibly without authority but without > prohibition, slaps a hub between their station and the SAVI device. The > SAVI device is now technically not behaving right. It can not function > properly. If the SAVI device could detect this, I would say "okay, > generate an alert. Things happen." But the SAVI device can't tell. (With > the dual uplink case, the SAVI device can tell because it gets STP over > its SAVI enforced ports.) > > It is at least somewhat unusual to write a SHOULD where the exception is > undetectable. > > Yours, > Joel > > Bi Jun wrote: >> Hi Jole, >> >> thanks for the explanation. >> >> But if the host is connected with a hub, then >> >> (1) as I said in my last email, if it is dual uplinks in marcelo's ppt, >> it will be no problem. >> >> (2) if it is single uplink hub, then under nv-memory storage at >> savi-switch, do we still need data-triggered. >> >> thanks, >> Jun Bi >> >> -------------------------------------------------- >> From: "Joel M. Halpern" >> Sent: Wednesday, March 24, 2010 8:17 AM >> Cc: "SAVI Mailing List" >> Subject: Re: [savi] Points raised regarding DHCP solution >> >>> The current proposals on the table call for different behaviors (or at >>> least different requirements on capabilities) for directly connected and >>> indirectly connected SAVI devices. >>> Thus, the device needs to be able to verify that it is using the right >>> capabilities, or is unable to perform its job. >>> But doing so requires being able to detect the configuration. >>> >>> Yours, >>> Joel >>> >>> Bi Jun wrote: >>>> sorry for my misunderstanding. >>>> Why you think automatically detecting a hub by a savi switch is so >>>> important after I have explained in Marcelo's case the hub is no >>>> problem ? >>>> >>>> thanks, >>>> Jun Bi >>>> >>>> -------------------------------------------------- >>>> From: "Joel M. Halpern" >>>> Sent: Tuesday, March 23, 2010 11:49 PM >>>> To: "Jun Bi" >>>> Cc: "SAVI Mailing List" >>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>> >>>>> My final comment, which you quoted, was not concerned with the >>>>> specialized two-switch case. There are many subtle arguments we can >>>>> have over what the right handling is for the two-switch case. >>>>> >>>>> I am still trying to figure out how the SAVI switch will know if a >>>>> single hub has been placed between it and the client. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> Jun Bi wrote: >>>>>> >>>>>>> However, my question is how the SAVI device would determine that >>>>>>> there >>>>>>> is a hub between it and the end user machines. Should it try to >>>>>>> guess that the presence of multiple MAC addresses means a hub? What >>>>>>> if only one port in the hub is in use? There are still probably for >>>>>>> the system caused by the presence of the hub. >>>>>> >>>>>> Dear Jole, >>>>>> >>>>>> Thank you very much for your reply. >>>>>> >>>>>> In my last email, I said if in Marcelo's case SWITCH-II is only a >>>>>> hub, then because hub will boardcast the packets (duplicate packets >>>>>> to both SAVI1 and SAVI2), then both SAVI1 and SAVI2 will know the >>>>>> equal binding by control packet based binding, then it will no the >>>>>> problem Marcelo mentioned. >>>>>> >>>>>> thanks, >>>>>> Jun Bi >>>>>> >>>>>> >>>>>> -------------------------------------------------- >>>>>> From: "Joel M. Halpern" >>>>>> Sent: Tuesday, March 23, 2010 11:08 PM >>>>>> To: "Jun Bi" >>>>>> Cc: "SAVI Mailing List" >>>>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>>> >>>>>>> Jun, I think I follow part of your comment, and then get lost. >>>>>>> >>>>>>> For the topology change argument,it is the case that the SAVI switch >>>>>>> would have to be receiving STP (or RSTP, or TRILL, or ...) packets >>>>>>> on the interface on which it is applying SAVI controls. This is >>>>>>> clearly detectable, and the SAVI device can complain to management >>>>>>> if it is not prepared to code with that combination. Workable. >>>>>>> >>>>>>> However, my question is how the SAVI device would determine that >>>>>>> there is a hub between it and the end user machines. Should it try >>>>>>> to guess that the presence of multiple MAC addresses means a hub? >>>>>>> What if only one port in the hub is in use? There are still >>>>>>> probably for the system caused by the presence of the hub. >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> Jun Bi wrote: >>>>>>>> >>>>>>>> >>>>>>>> -------------------------------------------------- >>>>>>>> From: "Joel M. Halpern" >>>>>>>> Sent: Tuesday, March 23, 2010 6:32 PM >>>>>>>> To: "SAVI Mailing List" >>>>>>>> Subject: [savi] Points raised regarding DHCP solution >>>>>>>> >>>>>>>>> The large question I raised was whether it was reasonable to treat >>>>>>>>> as knowable the question of whether the host is directly connected >>>>>>>>> to the SAVI switch. >>>>>>>> >>>>>>>> May I make my point more clearly? >>>>>>>> Switch-host connection is just one easy case to understand that >>>>>>>> Marcelo's case >>>>>>>> is not the normal case in real deployment. >>>>>>>> >>>>>>>> I meant, as an administrator, we do know the topology I manage. >>>>>>>> In Marcelo's case are very special from deployment view point, >>>>>>>> because it needs >>>>>>>> the dual-uplinks to SAVI switches. There are 3 situation I can >>>>>>>> image if I met this >>>>>>>> case as an administrator. >>>>>>>> >>>>>>>> If Switch II is a normal switch owned by the administrator, then >>>>>>>> because enabling the data-triggered functions will cost the >>>>>>>> administer too much money (to buy a higher-end switch), then I will >>>>>>>> actually upgrade savi-software at that normal switch (if only >>>>>>>> implement control based binding, it's very light-weight just like >>>>>>>> ABC for a switch to upgrade to savi, based on our REAL deployment >>>>>>>> experience), or I can even buy a new low cost savi-switch to >>>>>>>> replace Switch II. >>>>>>>> >>>>>>>> If Switch II is a normal switch but owned by user, then if he do >>>>>>>> dual uplinks, he >>>>>>>> has to report to me the administrator because it will change the >>>>>>>> topology I am managing. If I permit, then I know which ports I need >>>>>>>> to configure to enable the >>>>>>>> data-triggered functions. If he doesn't report to me, then he will >>>>>>>> be responsible >>>>>>>> for his possible broken (one possible way is he repairs his network >>>>>>>> connection). (In reality, I will kindly suggest him to upgrade to >>>>>>>> savi-software.) >>>>>>>> >>>>>>>> If switch II is a hub which is not upgradable. Then the packets are >>>>>>>> boardcasting. >>>>>>>> Then SAVI-1 and SAVI-2 can know ALL control packets, then setup >>>>>>>> equal binding table for this hub. Then we actually don't need to >>>>>>>> enable data-triggered functions. >>>>>>>> >>>>>>>> So my conclusion is, in reality, most of Marcelo's consideration >>>>>>>> won't actually happen (I think Fred Baker has the same points when >>>>>>>> he replied Marcelo in the mailing-list). In the worst case, if I >>>>>>>> have to enable data-trigger functions for some cases, I know where >>>>>>>> to configure it, I don't need to enable it at any port of any >>>>>>>> switch. Therefore, it should not be a MUST function in SAVI (both >>>>>>>> for dhcp and slaac). >>>>>>>> >>>>>>>> Thank you very much ! >>>>>>>> Jun Bi >>>>>>>> >>>>>>>>> >>>>>>>>> Regarding the specifics of the presentation, I commented that I >>>>>>>>> consider expecting the user to repair his network connection to be >>>>>>>>> unacceptable. Many naive users simply do not even understand that >>>>>>>>> question. >>>>>>>>> >>>>>>>>> Regarding the suggestion of using short DHCP lease times, this >>>>>>>>> would require that we ALWAYS use very short lifetimes, since the >>>>>>>>> lease that needs to be short is the one that was sent before the >>>>>>>>> failure. This seems to be a very bad idea. >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> Joel M. Halpern >>>>>>>>> _______________________________________________ >>>>>>>>> savi mailing list >>>>>>>>> savi@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> > From marcelo@it.uc3m.es Mon Mar 29 08:44:23 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31ED73A696E for ; Mon, 29 Mar 2010 08:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.869 X-Spam-Level: X-Spam-Status: No, score=-103.869 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6y8HGiesvusx for ; Mon, 29 Mar 2010 08:44:21 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id D4CDE3A6405 for ; Mon, 29 Mar 2010 08:44:20 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 3F364BAF20C; Mon, 29 Mar 2010 17:44:47 +0200 (CEST) Message-ID: <4BB0CAEF.4060405@it.uc3m.es> Date: Mon, 29 Mar 2010 17:44:47 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Fred Baker References: <4BA96BAA.5020507@joelhalpern.com><112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO><4BA9AC7A.2010407@joelhalpern.com><4BA9B60A.3050404@joelhalpern.com><16A243CC6D724738A1FC22DC792FDB24@junbiVAIO> <4BAA2D12.6070903@joelhalpern.com> <4BAA65F2.6020300@joelhalpern.com> <5B679E2B-CEF3-4231-A899-267435243422@cisco.com> In-Reply-To: <5B679E2B-CEF3-4231-A899-267435243422@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: SAVI Mailing List Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 15:44:23 -0000 El 24/03/10 20:37, Fred Baker escribió: > As we discussed in private email last week, I'm very concerned at the mention of using non-volatile RAM to store data that is ephemeral in nature. I would far rather find a way to discover the current state of the network, which may be the same or different than the state before the switch restarted, than remember something in non-volatile memory that may or may not be valid at the point it is needed or used. > > Let me give you one potential implementation. Consider a switch that for whatever reason is discarding datagrams from a given port because they use an IPv6 source address that is not in its tables. For various reasons, it very likely has a counter, on the switch or VLAN if not on the port itself. It could also maintain a register or FIFO to capture the source IPv6 and MAC addresses this happened on. Without putting the logic for generating the request into the data path, it becomes quite possible for a control plane process to monitor that register and initiate DHCP queries to verify the address and obtain the state from DHCP server. This could be done at a controlled rate per port, to prevent what amounts to a DOS multiplier in which a source address "scan" results in a DHCP query assault on the server. > let me see if i understand this idea. The SAVI device will have a counter that will count the number of data packets filtered and it will also store the info about the IP address that the filtered packets contained. In addition, it is possible to trigger an action, when the counter reaches to a certain threshold. So, let me see if this works, according to your proposal. The threshold is set to 1 and the action is to trigger the binding creation procedure (either a dhcp query or a DAD NSOL, for the address of the packet that was filtered). So, suppose that a SAVI swithc receives a data packet for which it has no binding. It discards the packet and it increments the counter to 1. As the counter has reached the threshold, the SAVI will trigger the binding creation procedure (either a dhcp query for that address or a DAD NSOL for that address). If succesful, it will create a binding and following data packets will be forwarded prperly. Is that compliant with your description above? Regards, marcelo > In the event that a switch restarts, that logic obviously happens across the board. It can result in a burst comparable in size to the number of ports on the switch in a short interval, but that is not a continuing behavior. > > On Mar 24, 2010, at 12:20 PM, Joel M. Halpern wrote: > > >> We are almost at the crux of my concern. >> Looking at point 2, we end up saying something along the lines of >> >> A SAVI-DHCP device SHOULD us non-volatile storage for state information unless it can know that it is directly connected to the client. >> >> Now, presume that an implementor is trying to comply. And he builds a SAVI-DHCP device that does not have non-volatile storage, because his primary market is cases where clients are directly attached. >> And it gets sold to someone whose network is primarily used with clients directly attached to the SAVI device. So far so good. >> >> Now suppose that someone, possibly without authority but without prohibition, slaps a hub between their station and the SAVI device. The SAVI device is now technically not behaving right. It can not function properly. If the SAVI device could detect this, I would say "okay, generate an alert. Things happen." But the SAVI device can't tell. (With the dual uplink case, the SAVI device can tell because it gets STP over its SAVI enforced ports.) >> >> It is at least somewhat unusual to write a SHOULD where the exception is undetectable. >> >> Yours, >> Joel >> >> Bi Jun wrote: >> >>> Hi Jole, >>> thanks for the explanation. >>> But if the host is connected with a hub, then >>> (1) as I said in my last email, if it is dual uplinks in marcelo's ppt, it will be no problem. >>> (2) if it is single uplink hub, then under nv-memory storage at savi-switch, do we still need data-triggered. >>> thanks, >>> Jun Bi >>> -------------------------------------------------- >>> From: "Joel M. Halpern" >>> Sent: Wednesday, March 24, 2010 8:17 AM >>> Cc: "SAVI Mailing List" >>> Subject: Re: [savi] Points raised regarding DHCP solution >>> >>>> The current proposals on the table call for different behaviors (or at least different requirements on capabilities) for directly connected and indirectly connected SAVI devices. >>>> Thus, the device needs to be able to verify that it is using the right capabilities, or is unable to perform its job. >>>> But doing so requires being able to detect the configuration. >>>> >>>> Yours, >>>> Joel >>>> >>>> Bi Jun wrote: >>>> >>>>> sorry for my misunderstanding. >>>>> Why you think automatically detecting a hub by a savi switch is so important after I have explained in Marcelo's case the hub is no problem ? >>>>> >>>>> thanks, >>>>> Jun Bi >>>>> >>>>> -------------------------------------------------- >>>>> From: "Joel M. Halpern" >>>>> Sent: Tuesday, March 23, 2010 11:49 PM >>>>> To: "Jun Bi" >>>>> Cc: "SAVI Mailing List" >>>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>> >>>>> >>>>>> My final comment, which you quoted, was not concerned with the specialized two-switch case. There are many subtle arguments we can have over what the right handling is for the two-switch case. >>>>>> >>>>>> I am still trying to figure out how the SAVI switch will know if a single hub has been placed between it and the client. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> Jun Bi wrote: >>>>>> >>>>>>> >>>>>>>> However, my question is how the SAVI device would determine that there >>>>>>>> is a hub between it and the end user machines. Should it try to guess that the presence of multiple MAC addresses means a hub? What if only one port in the hub is in use? There are still probably for the system caused by the presence of the hub. >>>>>>>> >>>>>>> Dear Jole, >>>>>>> >>>>>>> Thank you very much for your reply. >>>>>>> >>>>>>> In my last email, I said if in Marcelo's case SWITCH-II is only a hub, then because hub will boardcast the packets (duplicate packets to both SAVI1 and SAVI2), then both SAVI1 and SAVI2 will know the equal binding by control packet based binding, then it will no the problem Marcelo mentioned. >>>>>>> >>>>>>> thanks, >>>>>>> Jun Bi >>>>>>> >>>>>>> >>>>>>> -------------------------------------------------- >>>>>>> From: "Joel M. Halpern" >>>>>>> Sent: Tuesday, March 23, 2010 11:08 PM >>>>>>> To: "Jun Bi" >>>>>>> Cc: "SAVI Mailing List" >>>>>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>>>> >>>>>>> >>>>>>>> Jun, I think I follow part of your comment, and then get lost. >>>>>>>> >>>>>>>> For the topology change argument,it is the case that the SAVI switch would have to be receiving STP (or RSTP, or TRILL, or ...) packets on the interface on which it is applying SAVI controls. This is clearly detectable, and the SAVI device can complain to management if it is not prepared to code with that combination. Workable. >>>>>>>> >>>>>>>> However, my question is how the SAVI device would determine that there is a hub between it and the end user machines. Should it try to guess that the presence of multiple MAC addresses means a hub? What if only one port in the hub is in use? There are still probably for the system caused by the presence of the hub. >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> Jun Bi wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> -------------------------------------------------- >>>>>>>>> From: "Joel M. Halpern" >>>>>>>>> Sent: Tuesday, March 23, 2010 6:32 PM >>>>>>>>> To: "SAVI Mailing List" >>>>>>>>> Subject: [savi] Points raised regarding DHCP solution >>>>>>>>> >>>>>>>>> >>>>>>>>>> The large question I raised was whether it was reasonable to treat as knowable the question of whether the host is directly connected to the SAVI switch. >>>>>>>>>> >>>>>>>>> May I make my point more clearly? >>>>>>>>> Switch-host connection is just one easy case to understand that Marcelo's case >>>>>>>>> is not the normal case in real deployment. >>>>>>>>> >>>>>>>>> I meant, as an administrator, we do know the topology I manage. >>>>>>>>> In Marcelo's case are very special from deployment view point, because it needs >>>>>>>>> the dual-uplinks to SAVI switches. There are 3 situation I can image if I met this >>>>>>>>> case as an administrator. >>>>>>>>> >>>>>>>>> If Switch II is a normal switch owned by the administrator, then because enabling the data-triggered functions will cost the administer too much money (to buy a higher-end switch), then I will actually upgrade savi-software at that normal switch (if only implement control based binding, it's very light-weight just like ABC for a switch to upgrade to savi, based on our REAL deployment experience), or I can even buy a new low cost savi-switch to replace Switch II. >>>>>>>>> >>>>>>>>> If Switch II is a normal switch but owned by user, then if he do dual uplinks, he >>>>>>>>> has to report to me the administrator because it will change the topology I am managing. If I permit, then I know which ports I need to configure to enable the >>>>>>>>> data-triggered functions. If he doesn't report to me, then he will be responsible >>>>>>>>> for his possible broken (one possible way is he repairs his network connection). (In reality, I will kindly suggest him to upgrade to savi-software.) >>>>>>>>> >>>>>>>>> If switch II is a hub which is not upgradable. Then the packets are boardcasting. >>>>>>>>> Then SAVI-1 and SAVI-2 can know ALL control packets, then setup equal binding table for this hub. Then we actually don't need to enable data-triggered functions. >>>>>>>>> >>>>>>>>> So my conclusion is, in reality, most of Marcelo's consideration won't actually happen (I think Fred Baker has the same points when he replied Marcelo in the mailing-list). In the worst case, if I have to enable data-trigger functions for some cases, I know where to configure it, I don't need to enable it at any port of any switch. Therefore, it should not be a MUST function in SAVI (both for dhcp and slaac). >>>>>>>>> >>>>>>>>> Thank you very much ! >>>>>>>>> Jun Bi >>>>>>>>> >>>>>>>>> >>>>>>>>>> Regarding the specifics of the presentation, I commented that I consider expecting the user to repair his network connection to be unacceptable. Many naive users simply do not even understand that question. >>>>>>>>>> >>>>>>>>>> Regarding the suggestion of using short DHCP lease times, this would require that we ALWAYS use very short lifetimes, since the lease that needs to be short is the one that was sent before the failure. This seems to be a very bad idea. >>>>>>>>>> >>>>>>>>>> Yours, >>>>>>>>>> Joel M. Halpern >>>>>>>>>> _______________________________________________ >>>>>>>>>> savi mailing list >>>>>>>>>> savi@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>>> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > http://www.ipinc.net/IPv4.GIF > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > From junbi@cernet.edu.cn Mon Mar 29 19:55:46 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698013A6920 for ; Mon, 29 Mar 2010 19:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.828 X-Spam-Level: * X-Spam-Status: No, score=1.828 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_HAS_XAIMC=2.696, J_CHICKENPOX_82=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNwwj1SAXGoE for ; Mon, 29 Mar 2010 19:55:43 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 129223A6908 for ; Mon, 29 Mar 2010 19:55:34 -0700 (PDT) Received: from junbiVAIO([59.66.24.182]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54bb1b242; Tue, 30 Mar 2010 10:56:01 +0800 Message-ID: <71A31E2A1252438488FB754224F45C79@junbiVAIO> From: "Bi Jun" To: "marcelo bagnulo braun" , "Fred Baker" References: <4BA96BAA.5020507@joelhalpern.com><112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO><4BA9AC7A.2010407@joelhalpern.com><4BA9B60A.3050404@joelhalpern.com><16A243CC6D724738A1FC22DC792FDB24@junbiVAIO> <4BAA2D12.6070903@joelhalpern.com> <4BAA65F2.6020300@joelhalpern.com><5B679E2B-CEF3-4231-A899-267435243422@cisco.com> <4BB0CAEF.4060405@it.uc3m.es> In-Reply-To: <4BB0CAEF.4060405@it.uc3m.es> Date: Tue, 30 Mar 2010 10:55:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: 9z7c1wXB Cc: SAVI Mailing List Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 02:55:46 -0000 -------------------------------------------------- From: "marcelo bagnulo braun" Sent: Monday, March 29, 2010 11:44 PM To: "Fred Baker" Cc: "SAVI Mailing List" Subject: Re: [savi] Points raised regarding DHCP solution > El 24/03/10 20:37, Fred Baker escribió: >> As we discussed in private email last week, I'm very concerned at the >> mention of using non-volatile RAM to store data that is ephemeral in >> nature. I would far rather find a way to discover the current state of >> the network, which may be the same or different than the state before the >> switch restarted, than remember something in non-volatile memory that may >> or may not be valid at the point it is needed or used. >> >> Let me give you one potential implementation. Consider a switch that for >> whatever reason is discarding datagrams from a given port because they >> use an IPv6 source address that is not in its tables. For various >> reasons, it very likely has a counter, on the switch or VLAN if not on >> the port itself. It could also maintain a register or FIFO to capture the >> source IPv6 and MAC addresses this happened on. Without putting the logic >> for generating the request into the data path, it becomes quite possible >> for a control plane process to monitor that register and initiate DHCP >> queries to verify the address and obtain the state from DHCP server. This >> could be done at a controlled rate per port, to prevent what amounts to a >> DOS multiplier in which a source address "scan" results in a DHCP query >> assault on the server. >> > > let me see if i understand this idea. > The SAVI device will have a counter that will count the number of data > packets filtered and it will also store the info about the IP address that > the filtered packets contained. > > In addition, it is possible to trigger an action, when the counter reaches > to a certain threshold. > > So, let me see if this works, according to your proposal. > The threshold is set to 1 and the action is to trigger the binding > creation procedure (either a dhcp query or a DAD NSOL, for the address of > the packet that was filtered). > Hi Marcelo, In my option, the threshold value will be set by the network admin. If I am the network admin, I won't set it to 1, because it's too sensitive. I may set it as 100, but I think we will provide some experimental value at our deployment. As I said in previous emails, I think the threshold triggered CPU action will be better than data-packet triggered. Because it will easy for CPU to control the rate limit. I propose to have the CPU actions triggered by the threshold event as follows: (1) A alert (trap message) to be sent by savi-switch as MUST. (2) A DAD-NS probe to be sent by L3 savi-switch as MUST (or SHOULD) (3) A DAD-NS probe to be sent by L2 switch as optional function (but alert MUST be sent so that the admin can know it). In addition, I propose to have the NV-storage as MUST when a new binding entry is created for both L3 or L2 savi-switch (to handle the savi-switch reboot case). Based on our investigation, because savi-switch needs the L3 knowledge, if the switch is the grade of L3 knowledge-able, then it's not hard for it to save the binding entry (this grade of switch actually already save all the tables in NV-storage). thanks, Jun Bi > So, suppose that a SAVI swithc receives a data packet for which it has no > binding. > It discards the packet and it increments the counter to 1. > As the counter has reached the threshold, the SAVI will trigger the > binding creation procedure (either a dhcp query for that address or a DAD > NSOL for that address). > If succesful, it will create a binding and following data packets will be > forwarded prperly. > > Is that compliant with your description above? > > Regards, marcelo > > > >> In the event that a switch restarts, that logic obviously happens across >> the board. It can result in a burst comparable in size to the number of >> ports on the switch in a short interval, but that is not a continuing >> behavior. >> >> On Mar 24, 2010, at 12:20 PM, Joel M. Halpern wrote: >> >> >>> We are almost at the crux of my concern. >>> Looking at point 2, we end up saying something along the lines of >>> >>> A SAVI-DHCP device SHOULD us non-volatile storage for state information >>> unless it can know that it is directly connected to the client. >>> >>> Now, presume that an implementor is trying to comply. And he builds a >>> SAVI-DHCP device that does not have non-volatile storage, because his >>> primary market is cases where clients are directly attached. >>> And it gets sold to someone whose network is primarily used with clients >>> directly attached to the SAVI device. So far so good. >>> >>> Now suppose that someone, possibly without authority but without >>> prohibition, slaps a hub between their station and the SAVI device. The >>> SAVI device is now technically not behaving right. It can not function >>> properly. If the SAVI device could detect this, I would say "okay, >>> generate an alert. Things happen." But the SAVI device can't tell. >>> (With the dual uplink case, the SAVI device can tell because it gets STP >>> over its SAVI enforced ports.) >>> >>> It is at least somewhat unusual to write a SHOULD where the exception is >>> undetectable. >>> >>> Yours, >>> Joel >>> >>> Bi Jun wrote: >>> >>>> Hi Jole, >>>> thanks for the explanation. >>>> But if the host is connected with a hub, then >>>> (1) as I said in my last email, if it is dual uplinks in marcelo's ppt, >>>> it will be no problem. >>>> (2) if it is single uplink hub, then under nv-memory storage at >>>> savi-switch, do we still need data-triggered. >>>> thanks, >>>> Jun Bi >>>> -------------------------------------------------- >>>> From: "Joel M. Halpern" >>>> Sent: Wednesday, March 24, 2010 8:17 AM >>>> Cc: "SAVI Mailing List" >>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>> >>>>> The current proposals on the table call for different behaviors (or at >>>>> least different requirements on capabilities) for directly connected >>>>> and indirectly connected SAVI devices. >>>>> Thus, the device needs to be able to verify that it is using the right >>>>> capabilities, or is unable to perform its job. >>>>> But doing so requires being able to detect the configuration. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> Bi Jun wrote: >>>>> >>>>>> sorry for my misunderstanding. >>>>>> Why you think automatically detecting a hub by a savi switch is so >>>>>> important after I have explained in Marcelo's case the hub is no >>>>>> problem ? >>>>>> >>>>>> thanks, >>>>>> Jun Bi >>>>>> >>>>>> -------------------------------------------------- >>>>>> From: "Joel M. Halpern" >>>>>> Sent: Tuesday, March 23, 2010 11:49 PM >>>>>> To: "Jun Bi" >>>>>> Cc: "SAVI Mailing List" >>>>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>>> >>>>>> >>>>>>> My final comment, which you quoted, was not concerned with the >>>>>>> specialized two-switch case. There are many subtle arguments we can >>>>>>> have over what the right handling is for the two-switch case. >>>>>>> >>>>>>> I am still trying to figure out how the SAVI switch will know if a >>>>>>> single hub has been placed between it and the client. >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> Jun Bi wrote: >>>>>>> >>>>>>>> >>>>>>>>> However, my question is how the SAVI device would determine that >>>>>>>>> there >>>>>>>>> is a hub between it and the end user machines. Should it try to >>>>>>>>> guess that the presence of multiple MAC addresses means a hub? >>>>>>>>> What if only one port in the hub is in use? There are still >>>>>>>>> probably for the system caused by the presence of the hub. >>>>>>>>> >>>>>>>> Dear Jole, >>>>>>>> >>>>>>>> Thank you very much for your reply. >>>>>>>> >>>>>>>> In my last email, I said if in Marcelo's case SWITCH-II is only a >>>>>>>> hub, then because hub will boardcast the packets (duplicate packets >>>>>>>> to both SAVI1 and SAVI2), then both SAVI1 and SAVI2 will know the >>>>>>>> equal binding by control packet based binding, then it will no the >>>>>>>> problem Marcelo mentioned. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Jun Bi >>>>>>>> >>>>>>>> >>>>>>>> -------------------------------------------------- >>>>>>>> From: "Joel M. Halpern" >>>>>>>> Sent: Tuesday, March 23, 2010 11:08 PM >>>>>>>> To: "Jun Bi" >>>>>>>> Cc: "SAVI Mailing List" >>>>>>>> Subject: Re: [savi] Points raised regarding DHCP solution >>>>>>>> >>>>>>>> >>>>>>>>> Jun, I think I follow part of your comment, and then get lost. >>>>>>>>> >>>>>>>>> For the topology change argument,it is the case that the SAVI >>>>>>>>> switch would have to be receiving STP (or RSTP, or TRILL, or ...) >>>>>>>>> packets on the interface on which it is applying SAVI controls. >>>>>>>>> This is clearly detectable, and the SAVI device can complain to >>>>>>>>> management if it is not prepared to code with that combination. >>>>>>>>> Workable. >>>>>>>>> >>>>>>>>> However, my question is how the SAVI device would determine that >>>>>>>>> there is a hub between it and the end user machines. Should it >>>>>>>>> try to guess that the presence of multiple MAC addresses means a >>>>>>>>> hub? What if only one port in the hub is in use? There are still >>>>>>>>> probably for the system caused by the presence of the hub. >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>> >>>>>>>>> Jun Bi wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -------------------------------------------------- >>>>>>>>>> From: "Joel M. Halpern" >>>>>>>>>> Sent: Tuesday, March 23, 2010 6:32 PM >>>>>>>>>> To: "SAVI Mailing List" >>>>>>>>>> Subject: [savi] Points raised regarding DHCP solution >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> The large question I raised was whether it was reasonable to >>>>>>>>>>> treat as knowable the question of whether the host is directly >>>>>>>>>>> connected to the SAVI switch. >>>>>>>>>>> >>>>>>>>>> May I make my point more clearly? >>>>>>>>>> Switch-host connection is just one easy case to understand that >>>>>>>>>> Marcelo's case >>>>>>>>>> is not the normal case in real deployment. >>>>>>>>>> >>>>>>>>>> I meant, as an administrator, we do know the topology I manage. >>>>>>>>>> In Marcelo's case are very special from deployment view point, >>>>>>>>>> because it needs >>>>>>>>>> the dual-uplinks to SAVI switches. There are 3 situation I can >>>>>>>>>> image if I met this >>>>>>>>>> case as an administrator. >>>>>>>>>> >>>>>>>>>> If Switch II is a normal switch owned by the administrator, then >>>>>>>>>> because enabling the data-triggered functions will cost the >>>>>>>>>> administer too much money (to buy a higher-end switch), then I >>>>>>>>>> will actually upgrade savi-software at that normal switch (if >>>>>>>>>> only implement control based binding, it's very light-weight just >>>>>>>>>> like ABC for a switch to upgrade to savi, based on our REAL >>>>>>>>>> deployment experience), or I can even buy a new low cost >>>>>>>>>> savi-switch to replace Switch II. >>>>>>>>>> >>>>>>>>>> If Switch II is a normal switch but owned by user, then if he do >>>>>>>>>> dual uplinks, he >>>>>>>>>> has to report to me the administrator because it will change the >>>>>>>>>> topology I am managing. If I permit, then I know which ports I >>>>>>>>>> need to configure to enable the >>>>>>>>>> data-triggered functions. If he doesn't report to me, then he >>>>>>>>>> will be responsible >>>>>>>>>> for his possible broken (one possible way is he repairs his >>>>>>>>>> network connection). (In reality, I will kindly suggest him to >>>>>>>>>> upgrade to savi-software.) >>>>>>>>>> >>>>>>>>>> If switch II is a hub which is not upgradable. Then the packets >>>>>>>>>> are boardcasting. >>>>>>>>>> Then SAVI-1 and SAVI-2 can know ALL control packets, then setup >>>>>>>>>> equal binding table for this hub. Then we actually don't need to >>>>>>>>>> enable data-triggered functions. >>>>>>>>>> >>>>>>>>>> So my conclusion is, in reality, most of Marcelo's consideration >>>>>>>>>> won't actually happen (I think Fred Baker has the same points >>>>>>>>>> when he replied Marcelo in the mailing-list). In the worst case, >>>>>>>>>> if I have to enable data-trigger functions for some cases, I know >>>>>>>>>> where to configure it, I don't need to enable it at any port of >>>>>>>>>> any switch. Therefore, it should not be a MUST function in SAVI >>>>>>>>>> (both for dhcp and slaac). >>>>>>>>>> >>>>>>>>>> Thank you very much ! >>>>>>>>>> Jun Bi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Regarding the specifics of the presentation, I commented that I >>>>>>>>>>> consider expecting the user to repair his network connection to >>>>>>>>>>> be unacceptable. Many naive users simply do not even understand >>>>>>>>>>> that question. >>>>>>>>>>> >>>>>>>>>>> Regarding the suggestion of using short DHCP lease times, this >>>>>>>>>>> would require that we ALWAYS use very short lifetimes, since the >>>>>>>>>>> lease that needs to be short is the one that was sent before the >>>>>>>>>>> failure. This seems to be a very bad idea. >>>>>>>>>>> >>>>>>>>>>> Yours, >>>>>>>>>>> Joel M. Halpern >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> savi mailing list >>>>>>>>>>> savi@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> savi mailing list >>>>>>> savi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> http://www.ipinc.net/IPv4.GIF >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From swmike@swm.pp.se Mon Mar 29 20:32:22 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299C43A6813 for ; Mon, 29 Mar 2010 20:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdeD7YezJ+tV for ; Mon, 29 Mar 2010 20:32:21 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id 28C193A67B5 for ; Mon, 29 Mar 2010 20:32:21 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 013EA9E; Tue, 30 Mar 2010 05:32:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 006AE9C; Tue, 30 Mar 2010 05:32:40 +0200 (CEST) Date: Tue, 30 Mar 2010 05:32:40 +0200 (CEST) From: Mikael Abrahamsson To: "Joel M. Halpern" In-Reply-To: <4BAA65F2.6020300@joelhalpern.com> Message-ID: References: <4BA96BAA.5020507@joelhalpern.com><112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO><4BA9AC7A.2010407@joelhalpern.com><4BA9B60A.3050404@joelhalpern.com><16A243CC6D724738A1FC22DC792FDB24@junbiVAIO> <4BAA2D12.6070903@joelhalpern.com> <4BAA65F2.6020300@joelhalpern.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: SAVI Mailing List Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 03:32:22 -0000 On Wed, 24 Mar 2010, Joel M. Halpern wrote: > Now suppose that someone, possibly without authority but without prohibition, > slaps a hub between their station and the SAVI device. The SAVI device is > now technically not behaving right. It can not function properly. If the > SAVI device could detect this, I would say "okay, generate an alert. Things > happen." But the SAVI device can't tell. (With the dual uplink case, the > SAVI device can tell because it gets STP over its SAVI enforced ports.) > > It is at least somewhat unusual to write a SHOULD where the exception is > undetectable. I'd imagine there are a lot of these in standards everywhere. I don't see it as a problem, the user did the wrong thing and when the SAVI device is rebooted the user will have to renew their DHCP lease or whatever needs to be done to get things working again (rebooting their computer seems to be the standard remedy for all problems nowadays :P ). I don't see the case of not detecting the problem as a reason to make this a MUST (if I understood you correctly that you wanted this change?). SAVI-like functionality for IPv4 has been deployed for 10 years, it works exactly like this, people know about it, it's not a major concern, I definitely don't see it needing a MUST to solve this specific problem. -- Mikael Abrahamsson email: swmike@swm.pp.se From jmh@joelhalpern.com Tue Mar 30 04:54:14 2010 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6461A3A676A for ; Tue, 30 Mar 2010 04:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.075 X-Spam-Level: X-Spam-Status: No, score=0.075 tagged_above=-999 required=5 tests=[AWL=1.055, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jsd1EV5MP2yp for ; Tue, 30 Mar 2010 04:54:13 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7D39D3A6B4A for ; Tue, 30 Mar 2010 04:53:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1724C4300AA; Tue, 30 Mar 2010 04:53:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.102] (pool-71-161-51-231.clppva.btas.verizon.net [71.161.51.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 53A0E430013; Tue, 30 Mar 2010 04:53:57 -0700 (PDT) Message-ID: <4BB1E654.80100@joelhalpern.com> Date: Tue, 30 Mar 2010 07:53:56 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mikael Abrahamsson References: <4BA96BAA.5020507@joelhalpern.com><112AC8BBEF9F4375A5F2B08D59832AC3@junbiVAIO><4BA9AC7A.2010407@joelhalpern.com><4BA9B60A.3050404@joelhalpern.com><16A243CC6D724738A1FC22DC792FDB24@junbiVAIO> <4BAA2D12.6070903@joelhalpern.com> <4BAA65F2.6020300@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SAVI Mailing List Subject: Re: [savi] Points raised regarding DHCP solution X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 11:54:14 -0000 While such things do happen, they are neither common nor desirable. When the user action to repair is obvious and simple, we tend to shrug and say "ok". However, in this case the user action required to effect repair is not particularly obvious nor well known to most users. That gap is what causes me concern. It may be that there is no good answer to this issue. But at the very least we need to recognize in the document what class of problem we are producing. And we should be aware that I am not the only person likely to consider this problematic. Yours, Joel M. Halpern Mikael Abrahamsson wrote: > On Wed, 24 Mar 2010, Joel M. Halpern wrote: > >> Now suppose that someone, possibly without authority but without >> prohibition, slaps a hub between their station and the SAVI device. >> The SAVI device is now technically not behaving right. It can not >> function properly. If the SAVI device could detect this, I would say >> "okay, generate an alert. Things happen." But the SAVI device can't >> tell. (With the dual uplink case, the SAVI device can tell because it >> gets STP over its SAVI enforced ports.) >> >> It is at least somewhat unusual to write a SHOULD where the exception >> is undetectable. > > I'd imagine there are a lot of these in standards everywhere. I don't > see it as a problem, the user did the wrong thing and when the SAVI > device is rebooted the user will have to renew their DHCP lease or > whatever needs to be done to get things working again (rebooting their > computer seems to be the standard remedy for all problems nowadays :P ). > > I don't see the case of not detecting the problem as a reason to make > this a MUST (if I understood you correctly that you wanted this change?). > > SAVI-like functionality for IPv4 has been deployed for 10 years, it > works exactly like this, people know about it, it's not a major concern, > I definitely don't see it needing a MUST to solve this specific problem. >