From fred@cisco.com Sat Oct 1 06:57:03 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3155721F96C7; Sat, 1 Oct 2011 06:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.803 X-Spam-Level: X-Spam-Status: No, score=-105.803 tagged_above=-999 required=5 tests=[AWL=-4.196, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+740cQaDAPl; Sat, 1 Oct 2011 06:57:02 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6A50321F93AE; Sat, 1 Oct 2011 06:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=9687; q=dns/txt; s=iport; t=1317477599; x=1318687199; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=uRTGQKM5xa30QoPmn5dHgF8SnCs6Lgg0844OqGPKLVw=; b=fB2Vj75qYRdXqluRVtGz0J1EmEd7BZWzsTpLOGWPBJ9NYUj2xiP6V4zF 3fNPgb9k8uAG+HmZ1QjIjlt4T1aSRL7S12b8oRlu4VwZ2ThfLFSVcwLsA 9GNanGMo7H2o4Ytw31n3YZavMvCAECh+9r53Wy+ZAcJ9is/DF3t3Tc19Y k=; X-IronPort-AV: E=Sophos;i="4.68,473,1312156800"; d="scan'208";a="122440" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-3.cisco.com with ESMTP; 01 Oct 2011 13:59:52 +0000 Received: from Freds-Computer.local (sin-vpn-client-16-42.cisco.com [10.68.16.42]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p91Dxlbj007535; Sat, 1 Oct 2011 13:59:47 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sat, 01 Oct 2011 21:59:52 +0800 X-PGP-Universal: processed; by Freds-Computer.local on Sat, 01 Oct 2011 21:59:52 +0800 Subject: Re: [homenet] Question for you Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Fri, 30 Sep 2011 21:26:04 +0300 Message-Id: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <44783019-1016-4D06-BACA-6130617F099A@ericsson.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: C Chauvenet , MANET IETF , Mark Townsley , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 13:57:03 -0000 As I understand it, we have made the case that there is a place for = routing in at least some homes and in SOHO networks, and we should say = what protocols manufacturers should consider implementing in equipment = they sell. Two significant parts of the issue there, as you know, are = operational expense and cost of goods. Margins in residential routers = are thin enough that manufacturers (one of which you know from the = inside) essentially lose their entire profit margin if they pick up the = phone for a trouble call, and in addition the memory to store the code = and data, and the code itself, cost money on a COGS basis. Manufacturers = want to be able to buy trouble-free code for a predictable price, put it = in the system, and forget the system. Which argues for proven specifications and implementations that have = been field proven to interoperate when used in anger. To my knowledge, this doesn't automatically imply "give me that old time = religion". It does call for proven (and preferably documented) = interoperability between numerous independent complete implementations, = or proven interoperability of a common profile of a protocol, an = exercise I have suggested to some proponents of your favorite protocol = is good for the soul. RFC 1246 comes to mind. By the way, let me clarify a point that you may be confused on. There = are detailed interoperability reports for RIPv2, OSPFv2, BGP[1234], and = I think IPv4/IS-IS. To my knowledge, there has been interoperability = testing of RIPng, OSPFv3, BGP-for-IPv6, and IPv6/IS-IS, all of which are = in use in production networks, but the test documentation is a trifle = thin. So I'm not asking of your favorite protocol or a dozen others that = one could discuss something I think should let slide for the traditional = ones. I am simply asking that the claims for the protocols be backed = with interoperability testing, RFCs, Security Directorate reviews, and = so on. On Sep 30, 2011, at 11:18 AM, Pascal Thubert (pthubert) wrote: > Hello Cedric: >=20 > I have the same questions. Furthermore, I'd wish to understand better: >=20 > *** whether the goal is limited to provide a best practice based on = "established" ICT technologies=20 >=20 > There are other "established" technologies. For instance there is = extensive networking experience in industrial networks, solving = different problems under different constraints. Same goes in AMI/AMR = networks, and to a lesser extent in Home, commercial and building = automation. Some groups in the IETF have finally started to pay = attention and build on that experience. Even if the resulting = technologies (e.g. ZigbeeIP and ISA100.11a) are fairly recent, the scale = is such that over a few years we have seen unprecedented amounts of = implementations, interop and compliance tests (e.g. under IPSO and WCI). >=20 > Also, if we map home use cases with the routing technologies that = applied today, we see that at the moment the traditional IGPs do not = play much role, at least from the home standpoint: > - Internet to Home (Content consumption) is not a Home problem > - Home to Internet (metering, P2P) is a default route > - Home to Home (Content and Access sharing) is dominated by OLSR. > - Inside Home (Content and Device sharing) is single subnet, solved = reactively by ARP or ND. > - Inside Home (Command & Control, Automation) meshing is proprietary = though going 6LoWPAN and RPL. >=20 > In any fashion, we can solve an additional problem of our own making = that would require our beloved ICT IGPs to be injected in the Home = network with always-on routers in each room or we can start producing = best practices on how the above can to be done with the technologies = that are already in place. Or both? >=20 > *** whether we have an assumption of a plethora of power >=20 > Year over year, we've seen the simplest devices migrate from a = totally-switched-off mode to some more and more power greedy sleeping = and always-on modes. > Always-on displays and LEDs appears fancy to the consumer but are of = consequence on the family budget and at the scale of a city, result in = measurable pollution.=20 > And we've been connecting more and more devices to the home power = distribution, devices that would not exist 10-20 years ago. > We know how power-greedy traditional ICT technologies are; people do = not want a new heating system that they cannot even stop in summer. > My take is that whatever this group produces has to be justified in = terms of power budget as it has to be justified in other terms like = usability and security. >=20 >=20 > *** if HOMENET is targeting home gateways and large home cinema gear = only, and whether we have an assumption of cat 5/6 cabling >=20 > This case is probably the low hanging fruit and that there is an = immediate need to solve a number of problems there. If that's what the = group is pursuing for the time being, well, that's fine as long as it's = very clear to everybody. But the rest of the world is low power and = lossy. Apart from certain ecological niches (that's datacenter mostly) = about all Internet-connected devices have evolved the wireless trait, = even if the most traditional devices can still use wires. The new trait = has lowered dramatically the cost and complexity of accessing the = Internet, which in turn allowed the introduction of new species of = internet-connected devices that now thrive under the name of Things. At = some point we'll have to address that too. >=20 > I do not know how that converts into cents at the current rate... >=20 > Pascal >=20 > -----Original Message----- > From: C Chauvenet [mailto:c.chauvenet@watteco.com]=20 > Sent: jeudi 29 septembre 2011 17:23 > To: Acee Lindem; Fred Baker (fred) > Cc: Mark Townsley; Pascal Thubert (pthubert); MANET IETF; = homenet@ietf.org; rtgwg@ietf.org > Subject: RE: [homenet] Question for you >=20 > Hi,=20 >=20 > " I don't think my wife would want a lossy network in our house ;^)" :=20= >=20 > Nobody wants a lossy network, but the technology you are using may = create lossy links... >=20 > I may have miss something in the Homenet scope. >=20 > In the scope of Homenet, is every device in the house runing over a = *robust* link (Bit Error Rate below 1 % at the PHY level) ? >=20 > Furthermore do these devices could have some high = Power/Computation/Size/Cost constraints ? >=20 > I fail to see the kind of technologies and devices that are targeting. >=20 > Thanks for the clarification. >=20 > C=E9dric . >=20 > -----Message d'origine----- > De : Acee Lindem [mailto:acee.lindem@ericsson.com] Envoy=E9 : jeudi 29 = septembre 2011 16:44 =C0 : Fred Baker Cc : Mark Townsley; C Chauvenet; = Pascal Thubert (pthubert); MANET IETF; homenet@ietf.org; rtgwg@ietf.org = Objet : Re: [homenet] Question for you >=20 > I'm in complete agreement with Fred. The areas where the existing = link-state protocols may need to be extended are auto-configuration and, = potentially, inter-area policies. =20 > I don't think my wife would want a lossy network in our house ;^) = Thanks, Acee On Sep 28, 2011, at 11:43 AM, Fred Baker wrote: >=20 >>=20 >> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: >>=20 >>> Since you asked, *I* think that a homenet has functional overlap = (what I called "at least a smaller and slightly different subset" in my = email) in terms of requirements to LLNs. At first blush, it looks like = RPL has lots of functionality - perhaps more than we really need for = homenet, and by your own admission more than you need for LLN's - but = will hold reservation on what I think best fits the bill until we see = Fred's analysis, hear from others, etc.=20 >>=20 >> My two yen, which may be all it's worth... >>=20 >> If I were a Linksys/D-Link/NetGear/* product manager asking about = what protocols to put in, I wouldn't be asking about what still exists = in Internet Drafts and is thought by the engineers designing it to be = better than sliced bread, but about what was inexpensive to implement, = likely to be close to bug-free, and definitively accomplished the goal. = I note that most routers for the IPv4 residential routing marketplace = implement RIPv2; I know of one that implements no routing protocol, one = that implements RIPv2 and RIPv1 (!), and one that implements RIPv2 and = OSPF (don't ask which they are, I don't remember). This is from a google = search of residential routers a few months ago and covered perhaps 20 = products from half as many vendors. So my first inclination is to say = that for a residential IPv6 network, RIPng is probably an image match = for those vendors. >>=20 >> I have a personal bias in the direction of OSPF or IS-IS; I think = that once the code is debugged, SPF-based protocols are more stable (no = count-to-infinity), given a reasonable set of defaults generate far more = stable networks, and definitively know when there is more than one = router on a LAN, which can be important in subnet distribution.=20 >>=20 >> My first choice would NOT be something that isn't proven in the field = in multiple interoperable implementations.=20 >>=20 >> As a person thinking about making a recommendation, I'd suggest that = folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask = themselves why that level of interoperability isn't mandatory. >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 >=20 >=20 From d.sturek@att.net Sat Oct 1 07:36:37 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A70C21F97C5 for ; Sat, 1 Oct 2011 07:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[AWL=0.959, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYmaiWs1uOH2 for ; Sat, 1 Oct 2011 07:36:36 -0700 (PDT) Received: from nm14.access.bullet.mail.mud.yahoo.com (nm14.access.bullet.mail.mud.yahoo.com [66.94.237.215]) by ietfa.amsl.com (Postfix) with SMTP id ED48B21F97BF for ; Sat, 1 Oct 2011 07:36:35 -0700 (PDT) Received: from [66.94.237.201] by nm14.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Oct 2011 14:39:30 -0000 Received: from [66.94.237.104] by tm12.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Oct 2011 14:39:30 -0000 Received: from [127.0.0.1] by omp1009.access.mail.mud.yahoo.com with NNFMP; 01 Oct 2011 14:39:30 -0000 X-Yahoo-Newman-Id: 340720.22433.bm@omp1009.access.mail.mud.yahoo.com Received: (qmail 67845 invoked from network); 1 Oct 2011 14:39:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1317479970; bh=3SSRNpPl/XFRrI+n8fHpuMxC6/SRMNmgIB9nbskpYVg=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=Or9o9hYkkhaBMnmhmxlykf6IJUDdziral3aCd3QsdENCSWLBpXsL014PYnrV07whc2fumk/lN+Hfu+/tN7hRaJ9z7+HV7RnTJBTGncweuWvqOjHo5YEwcZ0jUmfNdT3BbLdJESBLdS3sBQuhrUTAH/L0IeJkqLmUORgFWkyfqb8= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 0KPssaoVM1kUE_pJYgtsmd6i._3WAVc.iSvwEUWrDBBAm1M F.mOUuA_TjOg2HITBCiVqfFoRaThc6r3PW28y.IwCLZ1eyPq_PULrCS7lsGE P6ZZNWTTAEL0IWWGSj1y6YfCc0HH3bf_.FAw7tEmVMQzbWZEOOqMiNaOeULY cH4jkowR4tbIAUDT5tjpEths5CNMV_OUMbXsi69SQUAuVED86CMyQ7eeuQYF _OABtNqXM9RDTo4TDOMFmGalsXJbPMYaLVnzlGQoSrYap4CWrbDBCpBOQhDt Zr6Z3R8Qzy_E0h5wA5MhffQOOaBjh6gdAoByBLPKXEIgP_96nJ94hCKWBefH DB0ZMRMvkDoc67DmSfvHEdzWjLOiLl4gCW7I20X_7KmV6BbLxds59GpkCFFV 69wXcBmM.fgWn345bOg9x X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.196] (d.sturek@69.108.51.206 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 01 Oct 2011 07:39:29 -0700 PDT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Sat, 01 Oct 2011 07:38:12 -0700 Subject: Re: [manet] [homenet] Question for you From: Don Sturek To: Fred Baker , "Pascal Thubert \(pthubert\)" Message-ID: Thread-Topic: [manet] [homenet] Question for you In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Mailman-Approved-At: Sat, 01 Oct 2011 08:17:37 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 14:36:37 -0000 To add one more point to Fred's note: I think it is important to get a commercial group like Wi-Fi to participate in Homenet, adopt some or all of the drafts/RFCs then sponsor interoperability testing. I agree with Fred that having individual CPE vendors cobbling together RFCs will not yield a bullet proof home networking solution and that will kill the work in Homenet if customer support is needed. Don On 9/30/11 11:26 AM, "Fred Baker" wrote: >As I understand it, we have made the case that there is a place for >routing in at least some homes and in SOHO networks, and we should say >what protocols manufacturers should consider implementing in equipment >they sell. Two significant parts of the issue there, as you know, are >operational expense and cost of goods. Margins in residential routers are >thin enough that manufacturers (one of which you know from the inside) >essentially lose their entire profit margin if they pick up the phone for >a trouble call, and in addition the memory to store the code and data, >and the code itself, cost money on a COGS basis. Manufacturers want to be >able to buy trouble-free code for a predictable price, put it in the >system, and forget the system. > >Which argues for proven specifications and implementations that have been >field proven to interoperate when used in anger. > >To my knowledge, this doesn't automatically imply "give me that old time >religion". It does call for proven (and preferably documented) >interoperability between numerous independent complete implementations, >or proven interoperability of a common profile of a protocol, an exercise >I have suggested to some proponents of your favorite protocol is good for >the soul. RFC 1246 comes to mind. > >By the way, let me clarify a point that you may be confused on. There are >detailed interoperability reports for RIPv2, OSPFv2, BGP[1234], and I >think IPv4/IS-IS. To my knowledge, there has been interoperability >testing of RIPng, OSPFv3, BGP-for-IPv6, and IPv6/IS-IS, all of which are >in use in production networks, but the test documentation is a trifle >thin. So I'm not asking of your favorite protocol or a dozen others that >one could discuss something I think should let slide for the traditional >ones. I am simply asking that the claims for the protocols be backed with >interoperability testing, RFCs, Security Directorate reviews, and so on. > >On Sep 30, 2011, at 11:18 AM, Pascal Thubert (pthubert) wrote: > >> Hello Cedric: >>=20 >> I have the same questions. Furthermore, I'd wish to understand better: >>=20 >> *** whether the goal is limited to provide a best practice based on >>"established" ICT technologies >>=20 >> There are other "established" technologies. For instance there is >>extensive networking experience in industrial networks, solving >>different problems under different constraints. Same goes in AMI/AMR >>networks, and to a lesser extent in Home, commercial and building >>automation. Some groups in the IETF have finally started to pay >>attention and build on that experience. Even if the resulting >>technologies (e.g. ZigbeeIP and ISA100.11a) are fairly recent, the scale >>is such that over a few years we have seen unprecedented amounts of >>implementations, interop and compliance tests (e.g. under IPSO and WCI). >>=20 >> Also, if we map home use cases with the routing technologies that >>applied today, we see that at the moment the traditional IGPs do not >>play much role, at least from the home standpoint: >> - Internet to Home (Content consumption) is not a Home problem >> - Home to Internet (metering, P2P) is a default route >> - Home to Home (Content and Access sharing) is dominated by OLSR. >> - Inside Home (Content and Device sharing) is single subnet, solved >>reactively by ARP or ND. >> - Inside Home (Command & Control, Automation) meshing is proprietary >>though going 6LoWPAN and RPL. >>=20 >> In any fashion, we can solve an additional problem of our own making >>that would require our beloved ICT IGPs to be injected in the Home >>network with always-on routers in each room or we can start producing >>best practices on how the above can to be done with the technologies >>that are already in place. Or both? >>=20 >> *** whether we have an assumption of a plethora of power >>=20 >> Year over year, we've seen the simplest devices migrate from a >>totally-switched-off mode to some more and more power greedy sleeping >>and always-on modes. >> Always-on displays and LEDs appears fancy to the consumer but are of >>consequence on the family budget and at the scale of a city, result in >>measurable pollution. >> And we've been connecting more and more devices to the home power >>distribution, devices that would not exist 10-20 years ago. >> We know how power-greedy traditional ICT technologies are; people do >>not want a new heating system that they cannot even stop in summer. >> My take is that whatever this group produces has to be justified in >>terms of power budget as it has to be justified in other terms like >>usability and security. >>=20 >>=20 >> *** if HOMENET is targeting home gateways and large home cinema gear >>only, and whether we have an assumption of cat 5/6 cabling >>=20 >> This case is probably the low hanging fruit and that there is an >>immediate need to solve a number of problems there. If that's what the >>group is pursuing for the time being, well, that's fine as long as it's >>very clear to everybody. But the rest of the world is low power and >>lossy. Apart from certain ecological niches (that's datacenter mostly) >>about all Internet-connected devices have evolved the wireless trait, >>even if the most traditional devices can still use wires. The new trait >>has lowered dramatically the cost and complexity of accessing the >>Internet, which in turn allowed the introduction of new species of >>internet-connected devices that now thrive under the name of Things. At >>some point we'll have to address that too. >>=20 >> I do not know how that converts into cents at the current rate... >>=20 >> Pascal >>=20 >> -----Original Message----- >> From: C Chauvenet [mailto:c.chauvenet@watteco.com] >> Sent: jeudi 29 septembre 2011 17:23 >> To: Acee Lindem; Fred Baker (fred) >> Cc: Mark Townsley; Pascal Thubert (pthubert); MANET IETF; >>homenet@ietf.org; rtgwg@ietf.org >> Subject: RE: [homenet] Question for you >>=20 >> Hi,=20 >>=20 >> " I don't think my wife would want a lossy network in our house ;^)" : >>=20 >> Nobody wants a lossy network, but the technology you are using may >>create lossy links... >>=20 >> I may have miss something in the Homenet scope. >>=20 >> In the scope of Homenet, is every device in the house runing over a >>*robust* link (Bit Error Rate below 1 % at the PHY level) ? >>=20 >> Furthermore do these devices could have some high >>Power/Computation/Size/Cost constraints ? >>=20 >> I fail to see the kind of technologies and devices that are targeting. >>=20 >> Thanks for the clarification. >>=20 >> C=E9dric . >>=20 >> -----Message d'origine----- >> De : Acee Lindem [mailto:acee.lindem@ericsson.com] Envoy=E9 : jeudi 29 >>septembre 2011 16:44 =C0 : Fred Baker Cc : Mark Townsley; C Chauvenet; >>Pascal Thubert (pthubert); MANET IETF; homenet@ietf.org; rtgwg@ietf.org >>Objet : Re: [homenet] Question for you >>=20 >> I'm in complete agreement with Fred. The areas where the existing >>link-state protocols may need to be extended are auto-configuration and, >>potentially, inter-area policies. >> I don't think my wife would want a lossy network in our house ;^) >>Thanks, Acee On Sep 28, 2011, at 11:43 AM, Fred Baker wrote: >>=20 >>>=20 >>> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: >>>=20 >>>> Since you asked, *I* think that a homenet has functional overlap >>>>(what I called "at least a smaller and slightly different subset" in >>>>my email) in terms of requirements to LLNs. At first blush, it looks >>>>like RPL has lots of functionality - perhaps more than we really need >>>>for homenet, and by your own admission more than you need for LLN's - >>>>but will hold reservation on what I think best fits the bill until we >>>>see Fred's analysis, hear from others, etc. >>>=20 >>> My two yen, which may be all it's worth... >>>=20 >>> If I were a Linksys/D-Link/NetGear/* product manager asking about what >>>protocols to put in, I wouldn't be asking about what still exists in >>>Internet Drafts and is thought by the engineers designing it to be >>>better than sliced bread, but about what was inexpensive to implement, >>>likely to be close to bug-free, and definitively accomplished the goal. >>>I note that most routers for the IPv4 residential routing marketplace >>>implement RIPv2; I know of one that implements no routing protocol, one >>>that implements RIPv2 and RIPv1 (!), and one that implements RIPv2 and >>>OSPF (don't ask which they are, I don't remember). This is from a >>>google search of residential routers a few months ago and covered >>>perhaps 20 products from half as many vendors. So my first inclination >>>is to say that for a residential IPv6 network, RIPng is probably an >>>image match for those vendors. >>>=20 >>> I have a personal bias in the direction of OSPF or IS-IS; I think that >>>once the code is debugged, SPF-based protocols are more stable (no >>>count-to-infinity), given a reasonable set of defaults generate far >>>more stable networks, and definitively know when there is more than one >>>router on a LAN, which can be important in subnet distribution. >>>=20 >>> My first choice would NOT be something that isn't proven in the field >>>in multiple interoperable implementations. >>>=20 >>> As a person thinking about making a recommendation, I'd suggest that >>>folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask >>>themselves why that level of interoperability isn't mandatory. >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >>=20 >>=20 > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet From fred@cisco.com Sat Oct 1 17:17:51 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9F521F8DB0; Sat, 1 Oct 2011 17:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.575 X-Spam-Level: X-Spam-Status: No, score=-108.575 tagged_above=-999 required=5 tests=[AWL=2.024, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVNZbpm65dXV; Sat, 1 Oct 2011 17:17:50 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 58DF021F8DAB; Sat, 1 Oct 2011 17:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=299; q=dns/txt; s=iport; t=1317514849; x=1318724449; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=kfNAU+9GpEMuTtXQQZ1VkbIzn/xG9TEuYDzmLr+WTLI=; b=Iam20l1fV7Uf4hIXWh/CqWv2t9rAjeuIiZeGdAO/LIpjYTHx5ZayfyMV 5mfUrGps3ddfdpKMR+gmdRD9VLyr1FYnI8WLSJLF44NipI/OhJyTXfM35 OuUALUizaVcZVeT/7juxV5JS5+RNqngQJW4AsyicQVU7InhGlgr+SEdMr Q=; X-IronPort-AV: E=Sophos;i="4.68,475,1312156800"; d="scan'208";a="56909404" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 02 Oct 2011 00:20:45 +0000 Received: from Freds-Computer.local (sin-vpn-client-16-42.cisco.com [10.68.16.42]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p920KiRd000383; Sun, 2 Oct 2011 00:20:44 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sun, 02 Oct 2011 08:20:45 +0800 X-PGP-Universal: processed; by Freds-Computer.local on Sun, 02 Oct 2011 08:20:45 +0800 Subject: Re: [manet] [homenet] Question for you Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sun, 2 Oct 2011 08:20:32 +0800 Message-Id: <1C39033D-FBB9-4CAF-8C8C-E21AB4A1E9CE@cisco.com> References: To: Don Sturek X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: C Chauvenet , MANET IETF , Mark Townsley , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 00:17:51 -0000 On Oct 1, 2011, at 10:38 PM, Don Sturek wrote: > To add one more point to Fred's note: I think it is important to get a > commercial group like Wi-Fi to participate in Homenet, adopt some or all > of the drafts/RFCs then sponsor interoperability testing. That would be very interesting. From mark@townsley.net Sun Oct 2 19:08:52 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B6B21F84DA; Sun, 2 Oct 2011 19:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.176 X-Spam-Level: X-Spam-Status: No, score=-3.176 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BupKovd6xzg2; Sun, 2 Oct 2011 19:08:47 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D61FD21F849A; Sun, 2 Oct 2011 19:08:46 -0700 (PDT) Received: by wwf22 with SMTP id 22so3478515wwf.13 for ; Sun, 02 Oct 2011 19:11:47 -0700 (PDT) Received: by 10.227.197.207 with SMTP id el15mr2318636wbb.31.1317607906979; Sun, 02 Oct 2011 19:11:46 -0700 (PDT) Received: from [192.168.0.109] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fy13sm20938640wbb.18.2011.10.02.19.11.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Oct 2011 19:11:44 -0700 (PDT) Subject: Re: [homenet] [manet] Question for you Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: Date: Mon, 3 Oct 2011 04:11:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <225C6EB3-9659-41D6-8B39-90C7DC0F016D@townsley.net> References: To: Don Sturek X-Mailer: Apple Mail (2.1084) Cc: C Chauvenet , MANET IETF , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 02:08:52 -0000 On Oct 1, 2011, at 4:38 PM, Don Sturek wrote: > To add one more point to Fred's note: I think it is important to get = a > commercial group like Wi-Fi to participate in Homenet, adopt some or = all > of the drafts/RFCs then sponsor interoperability testing. I am constantly amazed at the plethora of consumer-oriented standards = groups/forums/logos/associations/etc... We've had decent uptake of RFC 6204 and other products of v6ops = targeting the consumer space. I hope that continues.=20 Of course, anyone with specific ties into any of the organizations that = might want to use our work, please feel free to help make that happen. - Mark >=20 > I agree with Fred that having individual CPE vendors cobbling together > RFCs will not yield a bullet proof home networking solution and that = will > kill the work in Homenet if customer support is needed. >=20 > Don >=20 >=20 >=20 > On 9/30/11 11:26 AM, "Fred Baker" wrote: >=20 >> As I understand it, we have made the case that there is a place for >> routing in at least some homes and in SOHO networks, and we should = say >> what protocols manufacturers should consider implementing in = equipment >> they sell. Two significant parts of the issue there, as you know, are >> operational expense and cost of goods. Margins in residential routers = are >> thin enough that manufacturers (one of which you know from the = inside) >> essentially lose their entire profit margin if they pick up the phone = for >> a trouble call, and in addition the memory to store the code and = data, >> and the code itself, cost money on a COGS basis. Manufacturers want = to be >> able to buy trouble-free code for a predictable price, put it in the >> system, and forget the system. >>=20 >> Which argues for proven specifications and implementations that have = been >> field proven to interoperate when used in anger. >>=20 >> To my knowledge, this doesn't automatically imply "give me that old = time >> religion". It does call for proven (and preferably documented) >> interoperability between numerous independent complete = implementations, >> or proven interoperability of a common profile of a protocol, an = exercise >> I have suggested to some proponents of your favorite protocol is good = for >> the soul. RFC 1246 comes to mind. >>=20 >> By the way, let me clarify a point that you may be confused on. There = are >> detailed interoperability reports for RIPv2, OSPFv2, BGP[1234], and I >> think IPv4/IS-IS. To my knowledge, there has been interoperability >> testing of RIPng, OSPFv3, BGP-for-IPv6, and IPv6/IS-IS, all of which = are >> in use in production networks, but the test documentation is a trifle >> thin. So I'm not asking of your favorite protocol or a dozen others = that >> one could discuss something I think should let slide for the = traditional >> ones. I am simply asking that the claims for the protocols be backed = with >> interoperability testing, RFCs, Security Directorate reviews, and so = on. >>=20 >> On Sep 30, 2011, at 11:18 AM, Pascal Thubert (pthubert) wrote: >>=20 >>> Hello Cedric: >>>=20 >>> I have the same questions. Furthermore, I'd wish to understand = better: >>>=20 >>> *** whether the goal is limited to provide a best practice based on >>> "established" ICT technologies >>>=20 >>> There are other "established" technologies. For instance there is >>> extensive networking experience in industrial networks, solving >>> different problems under different constraints. Same goes in AMI/AMR >>> networks, and to a lesser extent in Home, commercial and building >>> automation. Some groups in the IETF have finally started to pay >>> attention and build on that experience. Even if the resulting >>> technologies (e.g. ZigbeeIP and ISA100.11a) are fairly recent, the = scale >>> is such that over a few years we have seen unprecedented amounts of >>> implementations, interop and compliance tests (e.g. under IPSO and = WCI). >>>=20 >>> Also, if we map home use cases with the routing technologies that >>> applied today, we see that at the moment the traditional IGPs do not >>> play much role, at least from the home standpoint: >>> - Internet to Home (Content consumption) is not a Home problem >>> - Home to Internet (metering, P2P) is a default route >>> - Home to Home (Content and Access sharing) is dominated by OLSR. >>> - Inside Home (Content and Device sharing) is single subnet, solved >>> reactively by ARP or ND. >>> - Inside Home (Command & Control, Automation) meshing is proprietary >>> though going 6LoWPAN and RPL. >>>=20 >>> In any fashion, we can solve an additional problem of our own making >>> that would require our beloved ICT IGPs to be injected in the Home >>> network with always-on routers in each room or we can start = producing >>> best practices on how the above can to be done with the technologies >>> that are already in place. Or both? >>>=20 >>> *** whether we have an assumption of a plethora of power >>>=20 >>> Year over year, we've seen the simplest devices migrate from a >>> totally-switched-off mode to some more and more power greedy = sleeping >>> and always-on modes. >>> Always-on displays and LEDs appears fancy to the consumer but are of >>> consequence on the family budget and at the scale of a city, result = in >>> measurable pollution. >>> And we've been connecting more and more devices to the home power >>> distribution, devices that would not exist 10-20 years ago. >>> We know how power-greedy traditional ICT technologies are; people do >>> not want a new heating system that they cannot even stop in summer. >>> My take is that whatever this group produces has to be justified in >>> terms of power budget as it has to be justified in other terms like >>> usability and security. >>>=20 >>>=20 >>> *** if HOMENET is targeting home gateways and large home cinema gear >>> only, and whether we have an assumption of cat 5/6 cabling >>>=20 >>> This case is probably the low hanging fruit and that there is an >>> immediate need to solve a number of problems there. If that's what = the >>> group is pursuing for the time being, well, that's fine as long as = it's >>> very clear to everybody. But the rest of the world is low power and >>> lossy. Apart from certain ecological niches (that's datacenter = mostly) >>> about all Internet-connected devices have evolved the wireless = trait, >>> even if the most traditional devices can still use wires. The new = trait >>> has lowered dramatically the cost and complexity of accessing the >>> Internet, which in turn allowed the introduction of new species of >>> internet-connected devices that now thrive under the name of Things. = At >>> some point we'll have to address that too. >>>=20 >>> I do not know how that converts into cents at the current rate... >>>=20 >>> Pascal >>>=20 >>> -----Original Message----- >>> From: C Chauvenet [mailto:c.chauvenet@watteco.com] >>> Sent: jeudi 29 septembre 2011 17:23 >>> To: Acee Lindem; Fred Baker (fred) >>> Cc: Mark Townsley; Pascal Thubert (pthubert); MANET IETF; >>> homenet@ietf.org; rtgwg@ietf.org >>> Subject: RE: [homenet] Question for you >>>=20 >>> Hi,=20 >>>=20 >>> " I don't think my wife would want a lossy network in our house ;^)" = : >>>=20 >>> Nobody wants a lossy network, but the technology you are using may >>> create lossy links... >>>=20 >>> I may have miss something in the Homenet scope. >>>=20 >>> In the scope of Homenet, is every device in the house runing over a >>> *robust* link (Bit Error Rate below 1 % at the PHY level) ? >>>=20 >>> Furthermore do these devices could have some high >>> Power/Computation/Size/Cost constraints ? >>>=20 >>> I fail to see the kind of technologies and devices that are = targeting. >>>=20 >>> Thanks for the clarification. >>>=20 >>> C=E9dric . >>>=20 >>> -----Message d'origine----- >>> De : Acee Lindem [mailto:acee.lindem@ericsson.com] Envoy=E9 : jeudi = 29 >>> septembre 2011 16:44 =C0 : Fred Baker Cc : Mark Townsley; C = Chauvenet; >>> Pascal Thubert (pthubert); MANET IETF; homenet@ietf.org; = rtgwg@ietf.org >>> Objet : Re: [homenet] Question for you >>>=20 >>> I'm in complete agreement with Fred. The areas where the existing >>> link-state protocols may need to be extended are auto-configuration = and, >>> potentially, inter-area policies. >>> I don't think my wife would want a lossy network in our house ;^) >>> Thanks, Acee On Sep 28, 2011, at 11:43 AM, Fred Baker wrote: >>>=20 >>>>=20 >>>> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: >>>>=20 >>>>> Since you asked, *I* think that a homenet has functional overlap >>>>> (what I called "at least a smaller and slightly different subset" = in >>>>> my email) in terms of requirements to LLNs. At first blush, it = looks >>>>> like RPL has lots of functionality - perhaps more than we really = need >>>>> for homenet, and by your own admission more than you need for = LLN's - >>>>> but will hold reservation on what I think best fits the bill until = we >>>>> see Fred's analysis, hear from others, etc. >>>>=20 >>>> My two yen, which may be all it's worth... >>>>=20 >>>> If I were a Linksys/D-Link/NetGear/* product manager asking about = what >>>> protocols to put in, I wouldn't be asking about what still exists = in >>>> Internet Drafts and is thought by the engineers designing it to be >>>> better than sliced bread, but about what was inexpensive to = implement, >>>> likely to be close to bug-free, and definitively accomplished the = goal. >>>> I note that most routers for the IPv4 residential routing = marketplace >>>> implement RIPv2; I know of one that implements no routing protocol, = one >>>> that implements RIPv2 and RIPv1 (!), and one that implements RIPv2 = and >>>> OSPF (don't ask which they are, I don't remember). This is from a >>>> google search of residential routers a few months ago and covered >>>> perhaps 20 products from half as many vendors. So my first = inclination >>>> is to say that for a residential IPv6 network, RIPng is probably an >>>> image match for those vendors. >>>>=20 >>>> I have a personal bias in the direction of OSPF or IS-IS; I think = that >>>> once the code is debugged, SPF-based protocols are more stable (no >>>> count-to-infinity), given a reasonable set of defaults generate far >>>> more stable networks, and definitively know when there is more than = one >>>> router on a LAN, which can be important in subnet distribution. >>>>=20 >>>> My first choice would NOT be something that isn't proven in the = field >>>> in multiple interoperable implementations. >>>>=20 >>>> As a person thinking about making a recommendation, I'd suggest = that >>>> folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and = ask >>>> themselves why that level of interoperability isn't mandatory. >>>> _______________________________________________ >>>> homenet mailing list >>>> homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From jpv@cisco.com Mon Oct 3 06:59:17 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12ED921F8B28; Mon, 3 Oct 2011 06:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=-3.925, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsT4IcJlLIIM; Mon, 3 Oct 2011 06:59:16 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id B5FD321F8B12; Mon, 3 Oct 2011 06:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=3221; q=dns/txt; s=iport; t=1317650538; x=1318860138; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=yJXjgXbvFieq6gtR53/Gyg4zROJLH7oFW/LhTliunic=; b=QC9TwznMXKcaCu1osaWHZpmnspxMKD6f157RP7Eci0cIhKLvft7AKlCK X9AA+WBLlvLUTv96drLzMCc3/tQsn1x/bZXemahLaNBvaupN52Y5XnsVD hO7xsCWdewD2ZGbH36o1/9Pe2kOd1cd9zWQXHPjJMxacVNnaF930GL0yG k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABbAiU5Io8US/2dsb2JhbABBqACBBYFTAQEBAwEBAQEPAVsLEAsYFRknMAYTIodZBpsZAZ03A4QIgjhhBJNghSUJjBI X-IronPort-AV: E=Sophos;i="4.68,479,1312156800"; d="scan'208";a="209701" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-3.cisco.com with ESMTP; 03 Oct 2011 14:01:56 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p93E1tN5015015; Mon, 3 Oct 2011 14:01:56 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 22:01:55 +0800 Received: from [10.60.114.231] ([10.60.114.231]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 22:01:55 +0800 Subject: Re: [homenet] Question for you Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: JP Vasseur In-Reply-To: <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> Date: Mon, 3 Oct 2011 16:01:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 03 Oct 2011 14:01:55.0377 (UTC) FILETIME=[0250D210:01CC81D5] X-Mailman-Approved-At: Mon, 03 Oct 2011 07:01:01 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , homenet@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 13:59:17 -0000 On Sep 28, 2011, at 5:43 PM, Fred Baker wrote: >=20 > On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: >=20 >> Since you asked, *I* think that a homenet has functional overlap = (what I called "at least a smaller and slightly different subset" in my = email) in terms of requirements to LLNs. At first blush, it looks like = RPL has lots of functionality - perhaps more than we really need for = homenet, and by your own admission more than you need for LLN's - but = will hold reservation on what I think best fits the bill until we see = Fred's analysis, hear from others, etc.=20 >=20 > My two yen, which may be all it's worth... >=20 > If I were a Linksys/D-Link/NetGear/* product manager asking about what = protocols to put in, I wouldn't be asking about what still exists in = Internet Drafts and is thought by the engineers designing it to be = better than sliced bread, but about what was inexpensive to implement, = likely to be close to bug-free, and definitively accomplished the goal. = I note that most routers for the IPv4 residential routing marketplace = implement RIPv2; I know of one that implements no routing protocol, one = that implements RIPv2 and RIPv1 (!), and one that implements RIPv2 and = OSPF (don't ask which they are, I don't remember). This is from a google = search of residential routers a few months ago and covered perhaps 20 = products from half as many vendors. So my first inclination is to say = that for a residential IPv6 network, RIPng is probably an image match = for those vendors. >=20 > I have a personal bias in the direction of OSPF or IS-IS; I think that = once the code is debugged, SPF-based protocols are more stable (no = count-to-infinity), given a reasonable set of defaults generate far more = stable networks, and definitively know when there is more than one = router on a LAN, which can be important in subnet distribution.=20 I spent enough years on OSPF and ISIS to agree with you that these = protocols are well proven, widely deployed with the number of=20 recent improvements (MTR, fast convergence, =85) to name a few are = particularly appealing. But before choosing a routing protocol the first step consists of listing the requirements. In LLN, as you = rightly pointed out, "smart objects" have a set of constraints in terms of resources =85 far from where we are on traditional routers =85 Thus I = would strongly encourage to list the set of requirements for this type of devices before making any sort of selection on the routing = protocol of choice, taking into account where we will be in a few years when the number of these objects will not be limited to a few dozens, = the LSDB *will* grow =85=20 >=20 > My first choice would NOT be something that isn't proven in the field = in multiple interoperable implementations.=20 >=20 > As a person thinking about making a recommendation, I'd suggest that = folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask = themselves why that level of interoperability isn't mandatory. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From jpv@cisco.com Mon Oct 3 07:06:22 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4333321F8B65; Mon, 3 Oct 2011 07:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwhsWpEnLtkT; Mon, 3 Oct 2011 07:06:20 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1774421F8B67; Mon, 3 Oct 2011 07:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=25663; q=dns/txt; s=iport; t=1317650962; x=1318860562; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=RtK+j3xpaY94bbYVNqKb98mWHEf7rjwsKTXqwCKWi5c=; b=nGYez50rU1nr1f0bQufjvqDicdSyMpSe8Ho3iD6gI3iISxG9v2igG3jP YhGQvcHHO6FsI6r95SMHEGh3gH18OsJPeR2HHzF+ioFSwIOZ4N6GYtTw/ HUE2PnEhaCRx2rjE18CUa/byfiTiFMavspyREBoQo02jWRPzneV/pJteb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACTBiU6rRDoI/2dsb2JhbABBqACBBYFTAQEBAwEBAQEPAQcDEEELBQcECw4DBAEBAScHJx8JCAYTGweHWQabJwGdNwOGQGEEk2CFJQmMEg X-IronPort-AV: E=Sophos;i="4.68,479,1312156800"; d="scan'208,217";a="5616848" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 03 Oct 2011 14:09:22 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p93E9Lbc017226; Mon, 3 Oct 2011 14:09:21 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 07:09:21 -0700 Received: from [10.60.114.231] ([10.60.114.231]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 07:09:20 -0700 Subject: Re: [manet] [homenet] Question for you Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_524F1856-FAC7-4746-8A42-E35165549907" From: JP Vasseur In-Reply-To: Date: Mon, 3 Oct 2011 16:09:17 +0200 Message-Id: References: To: Don Sturek X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 03 Oct 2011 14:09:20.0655 (UTC) FILETIME=[0BB8D9F0:01CC81D6] Cc: C Chauvenet , MANET IETF , Mark Townsley , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 14:06:22 -0000 --Apple-Mail=_524F1856-FAC7-4746-8A42-E35165549907 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 100% agreeing with you Don. On Oct 1, 2011, at 4:38 PM, Don Sturek wrote: > To add one more point to Fred's note: I think it is important to get = a > commercial group like Wi-Fi to participate in Homenet, adopt some or = all > of the drafts/RFCs then sponsor interoperability testing. >=20 > I agree with Fred that having individual CPE vendors cobbling together > RFCs will not yield a bullet proof home networking solution and that = will > kill the work in Homenet if customer support is needed. >=20 > Don >=20 >=20 >=20 > On 9/30/11 11:26 AM, "Fred Baker" wrote: >=20 > >As I understand it, we have made the case that there is a place for > >routing in at least some homes and in SOHO networks, and we should = say > >what protocols manufacturers should consider implementing in = equipment > >they sell. Two significant parts of the issue there, as you know, are > >operational expense and cost of goods. Margins in residential routers = are > >thin enough that manufacturers (one of which you know from the = inside) > >essentially lose their entire profit margin if they pick up the phone = for > >a trouble call, and in addition the memory to store the code and = data, > >and the code itself, cost money on a COGS basis. Manufacturers want = to be > >able to buy trouble-free code for a predictable price, put it in the > >system, and forget the system. > > > >Which argues for proven specifications and implementations that have = been > >field proven to interoperate when used in anger. > > > >To my knowledge, this doesn't automatically imply "give me that old = time > >religion". It does call for proven (and preferably documented) > >interoperability between numerous independent complete = implementations, > >or proven interoperability of a common profile of a protocol, an = exercise > >I have suggested to some proponents of your favorite protocol is good = for > >the soul. RFC 1246 comes to mind. > > > >By the way, let me clarify a point that you may be confused on. There = are > >detailed interoperability reports for RIPv2, OSPFv2, BGP[1234], and I > >think IPv4/IS-IS. To my knowledge, there has been interoperability > >testing of RIPng, OSPFv3, BGP-for-IPv6, and IPv6/IS-IS, all of which = are > >in use in production networks, but the test documentation is a trifle > >thin. So I'm not asking of your favorite protocol or a dozen others = that > >one could discuss something I think should let slide for the = traditional > >ones. I am simply asking that the claims for the protocols be backed = with > >interoperability testing, RFCs, Security Directorate reviews, and so = on. > > > >On Sep 30, 2011, at 11:18 AM, Pascal Thubert (pthubert) wrote: > > > >> Hello Cedric: > >> > >> I have the same questions. Furthermore, I'd wish to understand = better: > >> > >> *** whether the goal is limited to provide a best practice based on > >>"established" ICT technologies > >> > >> There are other "established" technologies. For instance there is > >>extensive networking experience in industrial networks, solving > >>different problems under different constraints. Same goes in AMI/AMR > >>networks, and to a lesser extent in Home, commercial and building > >>automation. Some groups in the IETF have finally started to pay > >>attention and build on that experience. Even if the resulting > >>technologies (e.g. ZigbeeIP and ISA100.11a) are fairly recent, the = scale > >>is such that over a few years we have seen unprecedented amounts of > >>implementations, interop and compliance tests (e.g. under IPSO and = WCI). > >> > >> Also, if we map home use cases with the routing technologies that > >>applied today, we see that at the moment the traditional IGPs do not > >>play much role, at least from the home standpoint: > >> - Internet to Home (Content consumption) is not a Home problem > >> - Home to Internet (metering, P2P) is a default route > >> - Home to Home (Content and Access sharing) is dominated by OLSR. > >> - Inside Home (Content and Device sharing) is single subnet, solved > >>reactively by ARP or ND. > >> - Inside Home (Command & Control, Automation) meshing is = proprietary > >>though going 6LoWPAN and RPL. > >> > >> In any fashion, we can solve an additional problem of our own = making > >>that would require our beloved ICT IGPs to be injected in the Home > >>network with always-on routers in each room or we can start = producing > >>best practices on how the above can to be done with the technologies > >>that are already in place. Or both? > >> > >> *** whether we have an assumption of a plethora of power > >> > >> Year over year, we've seen the simplest devices migrate from a > >>totally-switched-off mode to some more and more power greedy = sleeping > >>and always-on modes. > >> Always-on displays and LEDs appears fancy to the consumer but are = of > >>consequence on the family budget and at the scale of a city, result = in > >>measurable pollution. > >> And we've been connecting more and more devices to the home power > >>distribution, devices that would not exist 10-20 years ago. > >> We know how power-greedy traditional ICT technologies are; people = do > >>not want a new heating system that they cannot even stop in summer. > >> My take is that whatever this group produces has to be justified in > >>terms of power budget as it has to be justified in other terms like > >>usability and security. > >> > >> > >> *** if HOMENET is targeting home gateways and large home cinema = gear > >>only, and whether we have an assumption of cat 5/6 cabling > >> > >> This case is probably the low hanging fruit and that there is an > >>immediate need to solve a number of problems there. If that's what = the > >>group is pursuing for the time being, well, that's fine as long as = it's > >>very clear to everybody. But the rest of the world is low power and > >>lossy. Apart from certain ecological niches (that's datacenter = mostly) > >>about all Internet-connected devices have evolved the wireless = trait, > >>even if the most traditional devices can still use wires. The new = trait > >>has lowered dramatically the cost and complexity of accessing the > >>Internet, which in turn allowed the introduction of new species of > >>internet-connected devices that now thrive under the name of Things. = At > >>some point we'll have to address that too. > >> > >> I do not know how that converts into cents at the current rate... > >> > >> Pascal > >> > >> -----Original Message----- > >> From: C Chauvenet [mailto:c.chauvenet@watteco.com] > >> Sent: jeudi 29 septembre 2011 17:23 > >> To: Acee Lindem; Fred Baker (fred) > >> Cc: Mark Townsley; Pascal Thubert (pthubert); MANET IETF; > >>homenet@ietf.org; rtgwg@ietf.org > >> Subject: RE: [homenet] Question for you > >> > >> Hi, > >> > >> " I don't think my wife would want a lossy network in our house = ;^)" : > >> > >> Nobody wants a lossy network, but the technology you are using may > >>create lossy links... > >> > >> I may have miss something in the Homenet scope. > >> > >> In the scope of Homenet, is every device in the house runing over a > >>*robust* link (Bit Error Rate below 1 % at the PHY level) ? > >> > >> Furthermore do these devices could have some high > >>Power/Computation/Size/Cost constraints ? > >> > >> I fail to see the kind of technologies and devices that are = targeting. > >> > >> Thanks for the clarification. > >> > >> C=E9dric . > >> > >> -----Message d'origine----- > >> De : Acee Lindem [mailto:acee.lindem@ericsson.com] Envoy=E9 : jeudi = 29 > >>septembre 2011 16:44 =C0 : Fred Baker Cc : Mark Townsley; C = Chauvenet; > >>Pascal Thubert (pthubert); MANET IETF; homenet@ietf.org; = rtgwg@ietf.org > >>Objet : Re: [homenet] Question for you > >> > >> I'm in complete agreement with Fred. The areas where the existing > >>link-state protocols may need to be extended are auto-configuration = and, > >>potentially, inter-area policies. > >> I don't think my wife would want a lossy network in our house ;^) > >>Thanks, Acee On Sep 28, 2011, at 11:43 AM, Fred Baker wrote: > >> > >>> > >>> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: > >>> > >>>> Since you asked, *I* think that a homenet has functional overlap > >>>>(what I called "at least a smaller and slightly different subset" = in > >>>>my email) in terms of requirements to LLNs. At first blush, it = looks > >>>>like RPL has lots of functionality - perhaps more than we really = need > >>>>for homenet, and by your own admission more than you need for = LLN's - > >>>>but will hold reservation on what I think best fits the bill until = we > >>>>see Fred's analysis, hear from others, etc. > >>> > >>> My two yen, which may be all it's worth... > >>> > >>> If I were a Linksys/D-Link/NetGear/* product manager asking about = what > >>>protocols to put in, I wouldn't be asking about what still exists = in > >>>Internet Drafts and is thought by the engineers designing it to be > >>>better than sliced bread, but about what was inexpensive to = implement, > >>>likely to be close to bug-free, and definitively accomplished the = goal. > >>>I note that most routers for the IPv4 residential routing = marketplace > >>>implement RIPv2; I know of one that implements no routing protocol, = one > >>>that implements RIPv2 and RIPv1 (!), and one that implements RIPv2 = and > >>>OSPF (don't ask which they are, I don't remember). This is from a > >>>google search of residential routers a few months ago and covered > >>>perhaps 20 products from half as many vendors. So my first = inclination > >>>is to say that for a residential IPv6 network, RIPng is probably an > >>>image match for those vendors. > >>> > >>> I have a personal bias in the direction of OSPF or IS-IS; I think = that > >>>once the code is debugged, SPF-based protocols are more stable (no > >>>count-to-infinity), given a reasonable set of defaults generate far > >>>more stable networks, and definitively know when there is more than = one > >>>router on a LAN, which can be important in subnet distribution. > >>> > >>> My first choice would NOT be something that isn't proven in the = field > >>>in multiple interoperable implementations. > >>> > >>> As a person thinking about making a recommendation, I'd suggest = that > >>>folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and = ask > >>>themselves why that level of interoperability isn't mandatory. > >>> _______________________________________________ > >>> homenet mailing list > >>> homenet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/homenet > >> > >> > >> > > > >_______________________________________________ > >manet mailing list > >manet@ietf.org > >https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_524F1856-FAC7-4746-8A42-E35165549907 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 100% = agreeing with you Don.

On Oct 1, 2011, at 4:38 PM, Don = Sturek wrote:

Re: [manet] [homenet] Question for you
To add = one more point to Fred's note:  I think it is important to get = a
commercial group like Wi-Fi to participate in Homenet, adopt some or = all
of the drafts/RFCs then sponsor interoperability testing.

I agree with Fred that having individual CPE vendors cobbling = together
RFCs will not yield a bullet proof home networking solution and that = will
kill the work in Homenet if customer support is needed.

Don



On 9/30/11 11:26 AM, "Fred Baker" <fred@cisco.com> wrote:

>As I understand it, we have made the case that there is a place = for
>routing in at least some homes and in SOHO networks, and we should = say
>what protocols manufacturers should consider implementing in = equipment
>they sell. Two significant parts of the issue there, as you know, = are
>operational expense and cost of goods. Margins in residential = routers are
>thin enough that manufacturers (one of which you know from the = inside)
>essentially lose their entire profit margin if they pick up the = phone for
>a trouble call, and in addition the memory to store the code and = data,
>and the code itself, cost money on a COGS basis. Manufacturers want = to be
>able to buy trouble-free code for a predictable price, put it in = the
>system, and forget the system.
>
>Which argues for proven specifications and implementations that have = been
>field proven to interoperate when used in anger.
>
>To my knowledge, this doesn't automatically imply "give me that old = time
>religion". It does call for proven (and preferably documented)
>interoperability between numerous independent complete = implementations,
>or proven interoperability of a common profile of a protocol, an = exercise
>I have suggested to some proponents of your favorite protocol is = good for
>the soul. RFC 1246 comes to mind.
>
>By the way, let me clarify a point that you may be confused on. = There are
>detailed interoperability reports for RIPv2, OSPFv2, BGP[1234], and = I
>think IPv4/IS-IS. To my knowledge, there has been = interoperability
>testing of RIPng, OSPFv3, BGP-for-IPv6, and IPv6/IS-IS, all of which = are
>in use in production networks, but the test documentation is a = trifle
>thin. So I'm not asking of your favorite protocol or a dozen others = that
>one could discuss something I think should let slide for the = traditional
>ones. I am simply asking that the claims for the protocols be backed = with
>interoperability testing, RFCs, Security Directorate reviews, and so = on.
>
>On Sep 30, 2011, at 11:18 AM, Pascal Thubert (pthubert) wrote:
>
>> Hello Cedric:
>>
>> I have the same questions. Furthermore, I'd wish to understand = better:
>>
>> *** whether the goal is limited to provide a best practice = based on
>>"established" ICT technologies
>>
>> There are other "established" technologies. For instance there = is
>>extensive networking experience in industrial networks, = solving
>>different problems under different constraints. Same goes in = AMI/AMR
>>networks, and to a lesser extent in Home, commercial and = building
>>automation. Some groups in the IETF have finally started to = pay
>>attention and build on that experience. Even if the = resulting
>>technologies (e.g. ZigbeeIP and ISA100.11a) are fairly recent, = the scale
>>is such that over a few years we have seen unprecedented amounts = of
>>implementations, interop and compliance tests (e.g. under IPSO = and WCI).
>>
>> Also, if we map home use cases with the routing technologies = that
>>applied today, we see that at the moment the traditional IGPs do = not
>>play much role, at least from the home standpoint:
>> - Internet to Home (Content consumption) is not a Home = problem
>> - Home to Internet (metering, P2P)  is a default route
>> - Home to Home (Content and Access sharing) is dominated by = OLSR.
>> - Inside Home (Content and Device sharing) is single subnet, = solved
>>reactively by ARP or ND.
>> - Inside Home (Command & Control, Automation) meshing is = proprietary
>>though going 6LoWPAN and RPL.
>>
>> In any fashion, we can solve an additional problem of our own = making
>>that would require our beloved ICT IGPs to be injected in the = Home
>>network with always-on routers in each room or we can start = producing
>>best practices on how the above can to be done with the = technologies
>>that are already in place. Or both?
>>
>> *** whether we have an assumption of a plethora of power
>>
>> Year over year, we've seen the simplest devices migrate from = a
>>totally-switched-off mode to some more and more power greedy = sleeping
>>and always-on modes.
>> Always-on displays and LEDs appears fancy to the consumer but = are of
>>consequence on the family budget and at the scale of a city, = result in
>>measurable pollution.
>> And we've been connecting more and more devices to the home = power
>>distribution, devices that would not exist 10-20 years ago.
>> We know how power-greedy traditional ICT technologies are; = people do
>>not want a new heating system that they cannot even stop in = summer.
>> My take is that whatever this group produces has to be = justified in
>>terms of power budget as it has to be justified in other terms = like
>>usability and security.
>>
>>
>> *** if HOMENET is targeting home gateways and large home cinema = gear
>>only, and whether we have an assumption of cat 5/6 cabling
>>
>> This case is probably the low hanging fruit and that there is = an
>>immediate need to solve a number of problems there. If that's = what the
>>group is pursuing for the time being, well, that's fine as long = as it's
>>very clear to everybody. But the rest of the world is low power = and
>>lossy. Apart from certain ecological niches (that's datacenter = mostly)
>>about all Internet-connected devices have evolved the wireless = trait,
>>even if the most traditional devices can still use wires. The = new trait
>>has lowered dramatically the cost and complexity of accessing = the
>>Internet, which in turn allowed the introduction of new species = of
>>internet-connected devices that now thrive under the name of = Things. At
>>some point we'll have to address that too.
>>
>> I do not know how that converts into cents at the current = rate...
>>
>> Pascal
>>
>> -----Original Message-----
>> From: C Chauvenet [mailto:c.chauvenet@watteco.com= ]
>> Sent: jeudi 29 septembre 2011 17:23
>> To: Acee Lindem; Fred Baker (fred)
>> Cc: Mark Townsley; Pascal Thubert (pthubert); MANET IETF;
>>homenet@ietf.org; rtgwg@ietf.org
>> Subject: RE: [homenet] Question for you
>>
>> Hi,
>>
>> " I don't think my wife would want a lossy network in our house = ;^)" :
>>
>> Nobody wants a lossy network, but the technology you are using = may
>>create lossy links...
>>
>> I may have miss something in the Homenet scope.
>>
>> In the scope of Homenet, is every device in the house runing = over a
>>*robust* link (Bit Error Rate below 1 % at the PHY level) ?
>>
>> Furthermore do these devices could have some high
>>Power/Computation/Size/Cost constraints ?
>>
>> I fail to see the kind of technologies and devices that are = targeting.
>>
>> Thanks for the clarification.
>>
>> C=E9dric .
>>
>> -----Message d'origine-----
>> De : Acee Lindem [mailto:acee.lindem@ericsson.com] Envoy=E9 : jeudi 29
>>septembre 2011 16:44 =C0 : Fred Baker Cc : Mark Townsley; C = Chauvenet;
>>Pascal Thubert (pthubert); MANET IETF; homenet@ietf.org; rtgwg@ietf.org
>>Objet : Re: [homenet] Question for you
>>
>> I'm in complete agreement with Fred. The areas where the = existing
>>link-state protocols may need to be extended are = auto-configuration and,
>>potentially, inter-area policies.
>> I don't think my wife would want a lossy network in our house = ;^)
>>Thanks, Acee On Sep 28, 2011, at 11:43 AM, Fred Baker wrote:
>>
>>>
>>> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote:
>>>
>>>> Since you asked, *I* think that a homenet has = functional overlap
>>>>(what I called "at least a smaller and slightly = different subset" in
>>>>my email) in terms of requirements to LLNs. At first = blush, it looks
>>>>like RPL has lots of functionality - perhaps more than = we really need
>>>>for homenet, and by your own admission more than you = need for LLN's -
>>>>but will hold reservation on what I think best fits the = bill until we
>>>>see Fred's analysis, hear from others, etc.
>>>
>>> My two yen, which may be all it's worth...
>>>
>>> If I were a Linksys/D-Link/NetGear/* product manager asking = about what
>>>protocols to put in, I wouldn't be asking about what still = exists in
>>>Internet Drafts and is thought by the engineers designing it = to be
>>>better than sliced bread, but about what was inexpensive to = implement,
>>>likely to be close to bug-free, and definitively = accomplished the goal.
>>>I note that most routers for the IPv4 residential routing = marketplace
>>>implement RIPv2; I know of one that implements no routing = protocol, one
>>>that implements RIPv2 and RIPv1 (!), and one that implements = RIPv2 and
>>>OSPF (don't ask which they are, I don't remember). This is = from a
>>>google search of residential routers a few months ago and = covered
>>>perhaps 20 products from half as many vendors. So my first = inclination
>>>is to say that for a residential IPv6 network, RIPng is = probably an
>>>image match for those vendors.
>>>
>>> I have a personal bias in the direction of OSPF or IS-IS; I = think that
>>>once the code is debugged, SPF-based protocols are more = stable (no
>>>count-to-infinity), given a reasonable set of defaults = generate far
>>>more stable networks, and definitively know when there is = more than one
>>>router on a LAN, which can be important in subnet = distribution.
>>>
>>> My first choice would NOT be something that isn't proven in = the field
>>>in multiple interoperable implementations.
>>>
>>> As a person thinking about making a recommendation, I'd = suggest that
>>>folks read https://tools.i= etf.org/html/rfc2026#section-4.1.2 and ask
>>>themselves why that level of interoperability isn't = mandatory.
>>> _______________________________________________
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.or= g/mailman/listinfo/homenet
>>
>>
>>
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www.ietf.org/= mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail=_524F1856-FAC7-4746-8A42-E35165549907-- From acee.lindem@ericsson.com Mon Oct 3 07:21:56 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3E121F8B42; Mon, 3 Oct 2011 07:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNSUcI4YtZBJ; Mon, 3 Oct 2011 07:21:45 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id BC92A21F8B4A; Mon, 3 Oct 2011 07:21:44 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p93EOVnB016847; Mon, 3 Oct 2011 09:24:32 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 3 Oct 2011 10:24:26 -0400 From: Acee Lindem To: JP Vasseur Date: Mon, 3 Oct 2011 10:24:26 -0400 Subject: Re: [homenet] Question for you Thread-Topic: [homenet] Question for you Thread-Index: AcyB2Ceq6pwYuC1ATY2JzWbYuLz6Zw== Message-ID: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> In-Reply-To: <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: C Chauvenet , MANET IETF , Mark Townsley , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 14:21:57 -0000 Hey JP, On Oct 3, 2011, at 10:01 AM, JP Vasseur wrote: >=20 > On Sep 28, 2011, at 5:43 PM, Fred Baker wrote: >=20 >>=20 >> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: >>=20 >>> Since you asked, *I* think that a homenet has functional overlap (what = I called "at least a smaller and slightly different subset" in my email) in= terms of requirements to LLNs. At first blush, it looks like RPL has lots = of functionality - perhaps more than we really need for homenet, and by you= r own admission more than you need for LLN's - but will hold reservation on= what I think best fits the bill until we see Fred's analysis, hear from ot= hers, etc.=20 >>=20 >> My two yen, which may be all it's worth... >>=20 >> If I were a Linksys/D-Link/NetGear/* product manager asking about what p= rotocols to put in, I wouldn't be asking about what still exists in Interne= t Drafts and is thought by the engineers designing it to be better than sli= ced bread, but about what was inexpensive to implement, likely to be close = to bug-free, and definitively accomplished the goal. I note that most route= rs for the IPv4 residential routing marketplace implement RIPv2; I know of = one that implements no routing protocol, one that implements RIPv2 and RIPv= 1 (!), and one that implements RIPv2 and OSPF (don't ask which they are, I = don't remember). This is from a google search of residential routers a few = months ago and covered perhaps 20 products from half as many vendors. So my= first inclination is to say that for a residential IPv6 network, RIPng is = probably an image match for those vendors. >>=20 >> I have a personal bias in the direction of OSPF or IS-IS; I think that o= nce the code is debugged, SPF-based protocols are more stable (no count-to-= infinity), given a reasonable set of defaults generate far more stable netw= orks, and definitively know when there is more than one router on a LAN, wh= ich can be important in subnet distribution.=20 >=20 > I spent enough years on OSPF and ISIS to agree with you that these protoc= ols are well proven, widely deployed with the number of=20 > recent improvements (MTR, fast convergence, =85) to name a few are partic= ularly appealing. But before choosing a routing protocol > the first step consists of listing the requirements. In LLN, as you right= ly pointed out, "smart objects" have a set of constraints in terms > of resources =85 far from where we are on traditional routers =85 Thus I = would strongly encourage to list the set of requirements for this > type of devices before making any sort of selection on the routing protoc= ol of choice, taking into account where we will be in a few years > when the number of these objects will not be limited to a few dozens, the= LSDB *will* grow =85=20 I think a viable option for 2012 is that if the LLN networks with their sma= rt objects have to connect to the traditional HOMENET fixed and wireless ne= tworks, they will need to do so through a border router supporting both env= ironments. IMHO, we don't need one protocol that meets all requirements for= every possible device in the home.=20 Thanks, Acee=20 >=20 >>=20 >> My first choice would NOT be something that isn't proven in the field in= multiple interoperable implementations.=20 >>=20 >> As a person thinking about making a recommendation, I'd suggest that fol= ks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask themselve= s why that level of interoperability isn't mandatory. >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From jpv@cisco.com Mon Oct 3 07:24:12 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048D421F8B42; Mon, 3 Oct 2011 07:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.088 X-Spam-Level: X-Spam-Status: No, score=-106.088 tagged_above=-999 required=5 tests=[AWL=-3.489, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxHlbduny7LV; Mon, 3 Oct 2011 07:24:08 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7A77421F8B44; Mon, 3 Oct 2011 07:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4147; q=dns/txt; s=iport; t=1317652030; x=1318861630; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=w1iDIrttuR9AFBLxAcxaHhhxb0QdgMPYXINpyQRQV0I=; b=jSMais6RnStApBVpLVJKeibE4fVvXIzVvlfFLMI2lePmm/omY9Ot9R5E YJj1V2DY22OwWlcX00RVj2roF2y7SodGDlzsWSQqM96pxemfVUGdX6p0r uq011kbxdKubjaIiGI7LKgH2KDX1AA2cE6RvS/4q7q2Aji3BofUiqrMgU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAN/FiU5Io8UQ/2dsb2JhbABBqAGBBYFTAQEBAwEBAQEPAVsLBQsLGBUZJzAGEyKHWQabPwGdPwOECII4YQSTYIUlCYwS X-IronPort-AV: E=Sophos;i="4.68,479,1312156800"; d="scan'208";a="211220" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-4.cisco.com with ESMTP; 03 Oct 2011 14:27:07 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p93ER6Mf007422; Mon, 3 Oct 2011 14:27:06 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 22:27:06 +0800 Received: from [10.60.114.231] ([10.60.114.231]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 22:27:05 +0800 Subject: Re: [homenet] Question for you Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: JP Vasseur In-Reply-To: Date: Mon, 3 Oct 2011 16:27:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <667EF281-69A7-4F24-B426-DBD524F2CFC1@cisco.com> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> To: Acee Lindem X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 03 Oct 2011 14:27:05.0899 (UTC) FILETIME=[86A82FB0:01CC81D8] Cc: C Chauvenet , MANET IETF , Mark Townsley , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 14:24:12 -0000 Hey Acee, On Oct 3, 2011, at 4:24 PM, Acee Lindem wrote: > Hey JP, >=20 > On Oct 3, 2011, at 10:01 AM, JP Vasseur wrote: >=20 >>=20 >> On Sep 28, 2011, at 5:43 PM, Fred Baker wrote: >>=20 >>>=20 >>> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: >>>=20 >>>> Since you asked, *I* think that a homenet has functional overlap = (what I called "at least a smaller and slightly different subset" in my = email) in terms of requirements to LLNs. At first blush, it looks like = RPL has lots of functionality - perhaps more than we really need for = homenet, and by your own admission more than you need for LLN's - but = will hold reservation on what I think best fits the bill until we see = Fred's analysis, hear from others, etc.=20 >>>=20 >>> My two yen, which may be all it's worth... >>>=20 >>> If I were a Linksys/D-Link/NetGear/* product manager asking about = what protocols to put in, I wouldn't be asking about what still exists = in Internet Drafts and is thought by the engineers designing it to be = better than sliced bread, but about what was inexpensive to implement, = likely to be close to bug-free, and definitively accomplished the goal. = I note that most routers for the IPv4 residential routing marketplace = implement RIPv2; I know of one that implements no routing protocol, one = that implements RIPv2 and RIPv1 (!), and one that implements RIPv2 and = OSPF (don't ask which they are, I don't remember). This is from a google = search of residential routers a few months ago and covered perhaps 20 = products from half as many vendors. So my first inclination is to say = that for a residential IPv6 network, RIPng is probably an image match = for those vendors. >>>=20 >>> I have a personal bias in the direction of OSPF or IS-IS; I think = that once the code is debugged, SPF-based protocols are more stable (no = count-to-infinity), given a reasonable set of defaults generate far more = stable networks, and definitively know when there is more than one = router on a LAN, which can be important in subnet distribution.=20 >>=20 >> I spent enough years on OSPF and ISIS to agree with you that these = protocols are well proven, widely deployed with the number of=20 >> recent improvements (MTR, fast convergence, =85) to name a few are = particularly appealing. But before choosing a routing protocol >> the first step consists of listing the requirements. In LLN, as you = rightly pointed out, "smart objects" have a set of constraints in terms >> of resources =85 far from where we are on traditional routers =85 = Thus I would strongly encourage to list the set of requirements for this >> type of devices before making any sort of selection on the routing = protocol of choice, taking into account where we will be in a few years >> when the number of these objects will not be limited to a few dozens, = the LSDB *will* grow =85=20 >=20 > I think a viable option for 2012 is that if the LLN networks with = their smart objects have to connect to the traditional HOMENET fixed and = wireless networks, they will need to do so through a border router = supporting both environments. IMHO, we don't need one protocol that = meets all requirements for every possible device in the home.=20 >=20 100% agreeing with you !! This is why I was limiting my comments to = "constrained objects" - Very much in line with you. Cheers. JP. > Thanks, > Acee=20 >=20 >=20 >=20 >>=20 >>>=20 >>> My first choice would NOT be something that isn't proven in the = field in multiple interoperable implementations.=20 >>>=20 >>> As a person thinking about making a recommendation, I'd suggest that = folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask = themselves why that level of interoperability isn't mandatory. >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 From bingxuere@gmail.com Mon Oct 3 08:30:25 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBC821F8B6F; Mon, 3 Oct 2011 08:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJqY3MNbw7qq; Mon, 3 Oct 2011 08:30:25 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6CBB21F8B6B; Mon, 3 Oct 2011 08:30:24 -0700 (PDT) Received: by iaby26 with SMTP id y26so6525242iab.31 for ; Mon, 03 Oct 2011 08:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xbstRIVnA5yg8Y10cKeOIzLdtKBFo8pidW1/bVximlQ=; b=jRj1FRHe8ID7J/RJVIKSLZbsboTDszu/VzA+EfAlY6va3ifFNe0MAD3ykARg0lrqIK slTKVlO8JT/vSRQrG4yVFrXt7/t+OIfxSrW3lcrWIOzMsGfTucoK797ytFsfFFMvsRAC pQei1GYN4wI5LjnHjqzDsGamOgICHhGqaoMyM= Received: by 10.43.46.9 with SMTP id um9mr65671icb.178.1317656007280; Mon, 03 Oct 2011 08:33:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.219.194 with HTTP; Mon, 3 Oct 2011 08:33:06 -0700 (PDT) In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> From: Qiong Date: Mon, 3 Oct 2011 23:33:06 +0800 Message-ID: Subject: Re: [homenet] Question for you To: Acee Lindem Content-Type: multipart/alternative; boundary=bcaec52997434008ab04ae66b286 X-Mailman-Approved-At: Mon, 03 Oct 2011 08:32:41 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 15:30:25 -0000 --bcaec52997434008ab04ae66b286 Content-Type: text/plain; charset=UTF-8 Hi, Acee, Agree. I think the HOMENET requirements should be derived from major devices in the home network scenario. Maybe currently we should firstly focus on multiple router scenario for traditional fixed and wireless network for multiple services (especially WiFi) , and then introduce LLN network as well for smart objects in the same environment, together with the homenet architecture and new model in the future. Best wishes Qiong > > I think a viable option for 2012 is that if the LLN networks with their > smart objects have to connect to the traditional HOMENET fixed and wireless > networks, they will need to do so through a border router supporting both > environments. IMHO, we don't need one protocol that meets all requirements > for every possible device in the home. > > Thanks, > Acee > > > > > > >> > >> My first choice would NOT be something that isn't proven in the field in > multiple interoperable implementations. > >> > >> As a person thinking about making a recommendation, I'd suggest that > folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask > themselves why that level of interoperability isn't mandatory. > >> _______________________________________________ > >> homenet mailing list > >> homenet@ietf.org > >> https://www.ietf.org/mailman/listinfo/homenet > > > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --bcaec52997434008ab04ae66b286 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Acee,

Agree.=C2=A0I think the HOMENET requirements s= hould be derived from major devices in the home network scenario. Maybe cur= rently we should firstly focus on multiple router=C2=A0scenario for=C2=A0tr= aditional=C2=A0fixed and wireless network for multiple services (especially= WiFi) , and then introduce LLN network as well for smart objects in the sa= me environment, together with the homenet architecture and new model in the= future.=C2=A0

Best wishes=C2=A0

Qiong=C2=A0
=




I think a viable option for 2012 is that if the LLN networks with the= ir smart objects have to connect to the traditional HOMENET fixed and wirel= ess networks, they will need to do so through a border router supporting bo= th environments. IMHO, we don't need one protocol that meets all requir= ements for every possible device in the home.

Thanks,
Acee



>
>>
>> My first choice would NOT be something that isn't proven in th= e field in multiple interoperable implementations.
>>
>> As a person thinking about making a recommendation, I'd sugges= t that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask themselves why that level of interoperability isn't mandatory= .
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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

--bcaec52997434008ab04ae66b286-- From rturner@amalfisystems.com Mon Oct 3 08:55:39 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E43F21F8BDC; Mon, 3 Oct 2011 08:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7G2kXP5S88N; Mon, 3 Oct 2011 08:55:38 -0700 (PDT) Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8A521F8B70; Mon, 3 Oct 2011 08:55:38 -0700 (PDT) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p93FwdUJ011335; Mon, 3 Oct 2011 11:58:39 -0400 X-Authenticated-IP: 98.151.18.158 Received: from [98.151.18.158] ([98.151.18.158:62741] helo=[192.168.1.105]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id 85/D8-03335-DABD98E4; Mon, 03 Oct 2011 11:58:39 -0400 Subject: Re: [homenet] Question for you Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-47901164 From: Randy Turner In-Reply-To: Date: Mon, 3 Oct 2011 08:58:37 -0700 Message-Id: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> To: Qiong X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 03 Oct 2011 08:59:47 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 15:55:39 -0000 --Apple-Mail-1-47901164 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would hope that we would NOT be seriously considering OSPF or IS-IS in = the home...this seems like using a sledgehammer to kill an ant. How = many routes are we talking about for a home network? I don't believe = any enterprise routing protocol was designed for a "zeroconf" or = "zeroadmin" type of environment. Our customers won't even know what an = IP address is. Seems like a "RIP-like" (around the same scope of complexity) would be = enough for a homenet. I'm curious to see what comes out of the LLN = discussion. The "filter" for any of these decisions should probably always be a = "zeroconf" or "zeroadmin" scenario -- if a proposed approach to a = problem can't exist in a "zeroconf/admin" environment, then I would = think it would not be the right choice. Also, as a "first cut" = solution, we I think we should be focused on the 80% use-case, not the = fringe. The participants of this working group, and their respective = home networking setups, are probably not our "typical" customer.=20 Randy On Oct 3, 2011, at 8:33 AM, Qiong wrote: > Hi, Acee, >=20 > Agree. I think the HOMENET requirements should be derived from major = devices in the home network scenario. Maybe currently we should firstly = focus on multiple router scenario for traditional fixed and wireless = network for multiple services (especially WiFi) , and then introduce LLN = network as well for smart objects in the same environment, together with = the homenet architecture and new model in the future.=20 >=20 > Best wishes=20 >=20 > Qiong=20 >=20 >=20 >=20 >=20 > I think a viable option for 2012 is that if the LLN networks with = their smart objects have to connect to the traditional HOMENET fixed and = wireless networks, they will need to do so through a border router = supporting both environments. IMHO, we don't need one protocol that = meets all requirements for every possible device in the home. >=20 > Thanks, > Acee >=20 >=20 >=20 > > > >> > >> My first choice would NOT be something that isn't proven in the = field in multiple interoperable implementations. > >> > >> As a person thinking about making a recommendation, I'd suggest = that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and = ask themselves why that level of interoperability isn't mandatory. > >> _______________________________________________ > >> homenet mailing list > >> homenet@ietf.org > >> https://www.ietf.org/mailman/listinfo/homenet > > > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail-1-47901164 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Seems like a = "RIP-like" (around the same scope of complexity) would be enough for a = homenet.  I'm curious to see what comes out of the LLN = discussion.

The "filter" for any of these = decisions should probably always be a "zeroconf" or "zeroadmin" scenario = -- if a proposed approach to a problem can't exist in a "zeroconf/admin" = environment, then I would think it would not be the right choice. =  Also, as a "first cut" solution, we I think we should be focused = on the 80% use-case, not the fringe.  The participants of this = working group, and their respective home networking setups, are probably = not our "typical" = customer. 

Randy

On Oct 3, 2011, at 8:33 AM, Qiong wrote:

Hi, = Acee,

Agree. I think the HOMENET requirements = should be derived from major devices in the home network scenario. Maybe = currently we should firstly focus on multiple router scenario = for traditional fixed and wireless network for multiple = services (especially WiFi) , and then introduce LLN network as well for = smart objects in the same environment, together with the homenet = architecture and new model in the future. 

Best = wishes 

Qiong 




I think a viable option for 2012 is that if the LLN networks with = their smart objects have to connect to the traditional HOMENET fixed and = wireless networks, they will need to do so through a border router = supporting both environments. IMHO, we don't need one protocol that = meets all requirements for every possible device in the home.

Thanks,
Acee



>
>>
>> My first choice would NOT be something that isn't proven in the = field in multiple interoperable implementations.
>>
>> As a person thinking about making a recommendation, I'd suggest = that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 = and ask themselves why that level of interoperability isn't = mandatory.
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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

_______________________________________________
homenet mailing = list
homenet@ietf.org
https://www.ietf.= org/mailman/listinfo/homenet

= --Apple-Mail-1-47901164-- From tony.li@tony.li Mon Oct 3 09:13:22 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146E621F8BEE for ; Mon, 3 Oct 2011 09:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c04vlP81j0oJ for ; Mon, 3 Oct 2011 09:13:21 -0700 (PDT) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2B721F8BE9 for ; Mon, 3 Oct 2011 09:13:21 -0700 (PDT) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta14.emeryville.ca.mail.comcast.net with comcast id gFC61h0021ZMdJ4AEGGJeh; Mon, 03 Oct 2011 16:16:18 +0000 Received: from [10.21.78.187] ([128.107.239.233]) by omta16.emeryville.ca.mail.comcast.net with comcast id gGEU1h01252qHCY8cGEXS8; Mon, 03 Oct 2011 16:14:52 +0000 Subject: Re: [homenet] Question for you Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Mon, 3 Oct 2011 09:15:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> To: Randy Turner X-Mailer: Apple Mail (2.1084) Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 16:13:22 -0000 The problem with a RIP like protocol is that it will have RIP like = convergence properties. IMHO, that's no longer acceptable. Doing a subset of a LS protocol with a trivial default configuration = should not be unreasonable. Tony On Oct 3, 2011, at 8:58 AM, Randy Turner wrote: >=20 > I would hope that we would NOT be seriously considering OSPF or IS-IS = in the home...this seems like using a sledgehammer to kill an ant. How = many routes are we talking about for a home network? I don't believe = any enterprise routing protocol was designed for a "zeroconf" or = "zeroadmin" type of environment. Our customers won't even know what an = IP address is. >=20 > Seems like a "RIP-like" (around the same scope of complexity) would be = enough for a homenet. I'm curious to see what comes out of the LLN = discussion. >=20 > The "filter" for any of these decisions should probably always be a = "zeroconf" or "zeroadmin" scenario -- if a proposed approach to a = problem can't exist in a "zeroconf/admin" environment, then I would = think it would not be the right choice. Also, as a "first cut" = solution, we I think we should be focused on the 80% use-case, not the = fringe. The participants of this working group, and their respective = home networking setups, are probably not our "typical" customer.=20 >=20 > Randy >=20 >=20 > On Oct 3, 2011, at 8:33 AM, Qiong wrote: >=20 >> Hi, Acee, >>=20 >> Agree. I think the HOMENET requirements should be derived from major = devices in the home network scenario. Maybe currently we should firstly = focus on multiple router scenario for traditional fixed and wireless = network for multiple services (especially WiFi) , and then introduce LLN = network as well for smart objects in the same environment, together with = the homenet architecture and new model in the future.=20 >>=20 >> Best wishes=20 >>=20 >> Qiong=20 >>=20 >>=20 >>=20 >>=20 >> I think a viable option for 2012 is that if the LLN networks with = their smart objects have to connect to the traditional HOMENET fixed and = wireless networks, they will need to do so through a border router = supporting both environments. IMHO, we don't need one protocol that = meets all requirements for every possible device in the home. >>=20 >> Thanks, >> Acee >>=20 >>=20 >>=20 >> > >> >> >> >> My first choice would NOT be something that isn't proven in the = field in multiple interoperable implementations. >> >> >> >> As a person thinking about making a recommendation, I'd suggest = that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and = ask themselves why that level of interoperability isn't mandatory. >> >> _______________________________________________ >> >> homenet mailing list >> >> homenet@ietf.org >> >> https://www.ietf.org/mailman/listinfo/homenet >> > >> > _______________________________________________ >> > homenet mailing list >> > homenet@ietf.org >> > https://www.ietf.org/mailman/listinfo/homenet >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From lorenzo@google.com Mon Oct 3 09:35:41 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3378F21F8BB0 for ; Mon, 3 Oct 2011 09:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.923 X-Spam-Level: X-Spam-Status: No, score=-105.923 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaXefv4BqneP for ; Mon, 3 Oct 2011 09:35:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC9521F8BAA for ; Mon, 3 Oct 2011 09:35:40 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p93GcfRk024562 for ; Mon, 3 Oct 2011 09:38:42 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317659922; bh=hgmZYd9uaKbS3jRn9ZKM7N9/1Ro=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=WerfIXWu3IwdP7HKOKaGJxb2KfVpAsP7B1U6OOu8cmC3vHUKTFnS/VcSFg+vbcjTj 4JGLpJU1Iii9NpXjvfSIA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=W0RJ2XHiiA6Eng42zRBoN6PYM2anXL7PwzPltdF9qrD4TmLjuouZo9Y+X4hlIMCCt AI2sHruKHOw/scwPXb35A== Received: from gyg10 (gyg10.prod.google.com [10.243.50.138]) by wpaz9.hot.corp.google.com with ESMTP id p93GceQf029585 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 3 Oct 2011 09:38:40 -0700 Received: by gyg10 with SMTP id 10so4601388gyg.33 for ; Mon, 03 Oct 2011 09:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vpVbhExkA2TIR1vbeIKb4J4VjFrzh1gD8jiY3i+VXJw=; b=QnS6jaqjGBbbsHrAgLaV5VctvJohIlIe15QHTJXPazVVaasePYXX9u4Iq3SCvv3EFs Zdup/jkZLg3sZecVJsmQ== Received: by 10.150.141.21 with SMTP id o21mr333222ybd.57.1317659920478; Mon, 03 Oct 2011 09:38:40 -0700 (PDT) Received: by 10.150.141.21 with SMTP id o21mr333205ybd.57.1317659920190; Mon, 03 Oct 2011 09:38:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Mon, 3 Oct 2011 09:38:20 -0700 (PDT) In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> From: Lorenzo Colitti Date: Mon, 3 Oct 2011 09:38:20 -0700 Message-ID: Subject: Re: [homenet] Question for you To: Qiong Content-Type: multipart/alternative; boundary=000e0cd75f907a4bcc04ae679b14 X-System-Of-Record: true X-Mailman-Approved-At: Mon, 03 Oct 2011 09:55:19 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 16:35:41 -0000 --000e0cd75f907a4bcc04ae679b14 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 3, 2011 at 08:33, Qiong wrote: > Agree. I think the HOMENET requirements should be derived from major > devices in the home network scenario. Maybe currently we should firstly > focus on multiple router scenario for traditional fixed and wireless network > for multiple services (especially WiFi) > Agreed. While it's nice to think about abstract requirements and go off and pick a protocol that meets all of them, the truth is that if it doesn't get implemented, there's no point in doing so. If any of this is to be exist in the real world, then we need to start from the capabilities of devices that are currently common in home networking environments, because it's in those devices that this technology will be implemented first, if at all. --000e0cd75f907a4bcc04ae679b14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 3, 2011 at 08:33, Qiong <bingxuere@gmail.com>= ; wrote:
Agree.=A0I think the HOMENET requirements should be derived from major= devices in the home network scenario. Maybe currently we should firstly fo= cus on multiple router=A0scenario for=A0traditional=A0fixed and wireless ne= twork for multiple services (especially WiFi)
=A0
Agreed. While it's nice to think about = abstract requirements and go off and pick a protocol that meets all of them= , the truth is that if it doesn't get implemented, there's no point= in doing so. If any of this is to be exist in the real world, then we need= to start from the capabilities of devices that are currently common in hom= e networking environments, because it's in those devices that this tech= nology will be implemented first, if at all.
--000e0cd75f907a4bcc04ae679b14-- From lorenzo@google.com Mon Oct 3 09:47:50 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6D521F8C5B for ; Mon, 3 Oct 2011 09:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.929 X-Spam-Level: X-Spam-Status: No, score=-105.929 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dR4aS95hFylm for ; Mon, 3 Oct 2011 09:47:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 30A4221F8C4B for ; Mon, 3 Oct 2011 09:47:50 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p93GonSH027242 for ; Mon, 3 Oct 2011 09:50:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317660652; bh=H9csBGolB77SmudUcR8LDxa6e3A=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=kGyqqNYzGfazC+Ry3Wt4VYhO6RWa4Tw3Gk6xvYOPR1IlwUCAtcBfGoZ6iGm/RoqUu 9P1/ZNxadzIBetbyYPFiw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=mcy+MZLlQIEnBuk5NdA17TOnOBATr6EkWZPRVb13b5iRMZ2jeVTAPYqDhS7Oij0V8 XSa2v0BhhjjevzeuNB/4w== Received: from ywn1 (ywn1.prod.google.com [10.192.14.1]) by wpaz9.hot.corp.google.com with ESMTP id p93GoJk0016451 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 3 Oct 2011 09:50:48 -0700 Received: by ywn1 with SMTP id 1so4142965ywn.38 for ; Mon, 03 Oct 2011 09:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W6nPTfiW7Sr3M9Z37R+fr5qeilxW67EGeiOX8HSCLac=; b=b9fPYPHjRk3g4bZkp5qsZdVAXp+p4Z8McVS/MvnOp4MJRzIp75HeYkatNlJIyUoYOO Y5FMIPrLV/0ef/9O1vBg== Received: by 10.150.137.5 with SMTP id k5mr341925ybd.114.1317660648319; Mon, 03 Oct 2011 09:50:48 -0700 (PDT) Received: by 10.150.137.5 with SMTP id k5mr341907ybd.114.1317660648143; Mon, 03 Oct 2011 09:50:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Mon, 3 Oct 2011 09:50:27 -0700 (PDT) In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> From: Lorenzo Colitti Date: Mon, 3 Oct 2011 09:50:27 -0700 Message-ID: Subject: Re: [homenet] Question for you To: Randy Turner Content-Type: multipart/alternative; boundary=000e0cd3107addfacb04ae67c6c8 X-System-Of-Record: true X-Mailman-Approved-At: Mon, 03 Oct 2011 09:55:19 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 16:47:50 -0000 --000e0cd3107addfacb04ae67c6c8 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 3, 2011 at 08:58, Randy Turner wrote: > I would hope that we would NOT be seriously considering OSPF or IS-IS in > the home...this seems like using a sledgehammer to kill an ant. > If the devices we're talking about have enough resources to run them, and they have desirable properties that are useful in home networks, then what's the problem with either of these? Home gateways these days are capable of 1Gbps hardware forwarding and have pretty fast CPUs. For example, if there were a robust open-source version of IS-IS that didn't take up too much RAM and flash, you could define TLVs to implement zeroconf and you could get to something that works relatively quickly. --000e0cd3107addfacb04ae67c6c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 3, 2011 at 08:58, Randy Turner <rturner@amalf= isystems.com> wrote:
I would hope that we would NOT be = seriously considering OSPF or IS-IS in the home...this seems like using a s= ledgehammer to kill an ant.

If the devices we're talking about have enough resources to run them, a= nd they have desirable properties that are useful in home networks, then wh= at's the problem with either of these?=A0Home gateways these days are c= apable of 1Gbps hardware forwarding and have pretty fast CPUs.

For example, if there were a robust open-source version= of IS-IS that didn't take up too much RAM and flash, you could define = TLVs to implement zeroconf and you could get to something that works relati= vely quickly.
--000e0cd3107addfacb04ae67c6c8-- From robert.cragie@gmail.com Mon Oct 3 10:21:05 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCD721F8C87; Mon, 3 Oct 2011 10:21:05 -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.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xctrKU1n5w+Q; Mon, 3 Oct 2011 10:21:04 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86F9521F8C89; Mon, 3 Oct 2011 10:21:03 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4627204vcb.31 for ; Mon, 03 Oct 2011 10:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=r+zpYmZwiEmmmjUR3mLNzqqrNUapL2RYtWyW/RfV2Xk=; b=IPDPH7uF3iDcizx9S1PfKuyOFrSvj21cwAoum0MSLDE2F88yPih1P/zNXWd9Fx91lM KNF1F/7MRIuYtl5Oi4oXWgiZ8HNnfd9bhsboxZVwxM08rNFq/D3ldsCCflgWA97q/qt0 Ei3bDd6SsWv7Vpr2qZnBN/ChJTmOOz53+8wZ8= MIME-Version: 1.0 Received: by 10.52.89.107 with SMTP id bn11mr200215vdb.146.1317662646110; Mon, 03 Oct 2011 10:24:06 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.220.179.10 with HTTP; Mon, 3 Oct 2011 10:24:06 -0700 (PDT) In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> Date: Mon, 3 Oct 2011 18:24:06 +0100 X-Google-Sender-Auth: dcCDAGeSBE8YFLyKck1EMnF_3kc Message-ID: Subject: Re: [homenet] Question for you From: Robert Cragie To: Acee Lindem Content-Type: multipart/alternative; boundary=20cf307d033ef48a8004ae683d6d X-Mailman-Approved-At: Mon, 03 Oct 2011 10:38:48 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 17:21:06 -0000 --20cf307d033ef48a8004ae683d6d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 Robert On Mon, Oct 3, 2011 at 3:24 PM, Acee Lindem wrote= : > Hey JP, > > On Oct 3, 2011, at 10:01 AM, JP Vasseur wrote: > > > > > On Sep 28, 2011, at 5:43 PM, Fred Baker wrote: > > > >> > >> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: > >> > >>> Since you asked, *I* think that a homenet has functional overlap (wha= t > I called "at least a smaller and slightly different subset" in my email) = in > terms of requirements to LLNs. At first blush, it looks like RPL has lots= of > functionality - perhaps more than we really need for homenet, and by your > own admission more than you need for LLN's - but will hold reservation on > what I think best fits the bill until we see Fred's analysis, hear from > others, etc. > >> > >> My two yen, which may be all it's worth... > >> > >> If I were a Linksys/D-Link/NetGear/* product manager asking about what > protocols to put in, I wouldn't be asking about what still exists in > Internet Drafts and is thought by the engineers designing it to be better > than sliced bread, but about what was inexpensive to implement, likely to= be > close to bug-free, and definitively accomplished the goal. I note that mo= st > routers for the IPv4 residential routing marketplace implement RIPv2; I k= now > of one that implements no routing protocol, one that implements RIPv2 and > RIPv1 (!), and one that implements RIPv2 and OSPF (don't ask which they a= re, > I don't remember). This is from a google search of residential routers a = few > months ago and covered perhaps 20 products from half as many vendors. So = my > first inclination is to say that for a residential IPv6 network, RIPng is > probably an image match for those vendors. > >> > >> I have a personal bias in the direction of OSPF or IS-IS; I think that > once the code is debugged, SPF-based protocols are more stable (no > count-to-infinity), given a reasonable set of defaults generate far more > stable networks, and definitively know when there is more than one router= on > a LAN, which can be important in subnet distribution. > > > > I spent enough years on OSPF and ISIS to agree with you that these > protocols are well proven, widely deployed with the number of > > recent improvements (MTR, fast convergence, =85) to name a few are > particularly appealing. But before choosing a routing protocol > > the first step consists of listing the requirements. In LLN, as you > rightly pointed out, "smart objects" have a set of constraints in terms > > of resources =85 far from where we are on traditional routers =85 Thus = I > would strongly encourage to list the set of requirements for this > > type of devices before making any sort of selection on the routing > protocol of choice, taking into account where we will be in a few years > > when the number of these objects will not be limited to a few dozens, t= he > LSDB *will* grow =85 > > I think a viable option for 2012 is that if the LLN networks with their > smart objects have to connect to the traditional HOMENET fixed and wirele= ss > networks, they will need to do so through a border router supporting both > environments. IMHO, we don't need one protocol that meets all requirement= s > for every possible device in the home. > > Thanks, > Acee > > > > > > >> > >> My first choice would NOT be something that isn't proven in the field = in > multiple interoperable implementations. > >> > >> As a person thinking about making a recommendation, I'd suggest that > folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask > themselves why that level of interoperability isn't mandatory. > >> _______________________________________________ > >> homenet mailing list > >> homenet@ietf.org > >> https://www.ietf.org/mailman/listinfo/homenet > > > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --=20 Robert Cragie Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com --20cf307d033ef48a8004ae683d6d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1

Robert

On Mon, Oct = 3, 2011 at 3:24 PM, Acee Lindem <acee.lindem@ericsson.com> wrote:
Hey JP,

On Oct 3, 2011, at 10:01 AM, JP Vasseur wrote:

>
> On Sep 28, 2011, at 5:43 PM, Fred Baker wrote:
>
>>
>> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote:
>>
>>> Since you asked, *I* think that a homenet has functional overl= ap (what I called "at least a smaller and slightly different subset&qu= ot; in my email) in terms of requirements to LLNs. At first blush, it looks= like RPL has lots of functionality - perhaps more than we really need for = homenet, and by your own admission more than you need for LLN's - but w= ill hold reservation on what I think best fits the bill until we see Fred&#= 39;s analysis, hear from others, etc.
>>
>> My two yen, which may be all it's worth...
>>
>> If I were a Linksys/D-Link/NetGear/* product manager asking about = what protocols to put in, I wouldn't be asking about what still exists = in Internet Drafts and is thought by the engineers designing it to be bette= r than sliced bread, but about what was inexpensive to implement, likely to= be close to bug-free, and definitively accomplished the goal. I note that = most routers for the IPv4 residential routing marketplace implement RIPv2; = I know of one that implements no routing protocol, one that implements RIPv= 2 and RIPv1 (!), and one that implements RIPv2 and OSPF (don't ask whic= h they are, I don't remember). This is from a google search of resident= ial routers a few months ago and covered perhaps 20 products from half as m= any vendors. So my first inclination is to say that for a residential IPv6 = network, RIPng is probably an image match for those vendors.
>>
>> I have a personal bias in the direction of OSPF or IS-IS; I think = that once the code is debugged, SPF-based protocols are more stable (no cou= nt-to-infinity), given a reasonable set of defaults generate far more stabl= e networks, and definitively know when there is more than one router on a L= AN, which can be important in subnet distribution.
>
> I spent enough years on OSPF and ISIS to agree with you that these pro= tocols are well proven, widely deployed with the number of
> recent improvements (MTR, fast convergence, =85) to name a few are par= ticularly appealing. But before choosing a routing protocol
> the first step consists of listing the requirements. In LLN, as you ri= ghtly pointed out, "smart objects" have a set of constraints in t= erms
> of resources =85 far from where we are on traditional routers =85 Thus= I would strongly encourage to list the set of requirements for this
> type of devices before making any sort of selection on the routing pro= tocol of choice, taking into account where we will be in a few years
> when the number of these objects will not be limited to a few dozens, = the LSDB *will* grow =85

I think a viable option for 2012 is that if the LLN networks with the= ir smart objects have to connect to the traditional HOMENET fixed and wirel= ess networks, they will need to do so through a border router supporting bo= th environments. IMHO, we don't need one protocol that meets all requir= ements for every possible device in the home.

Thanks,
Acee



>
>>
>> My first choice would NOT be something that isn't proven in th= e field in multiple interoperable implementations.
>>
>> As a person thinking about making a recommendation, I'd sugges= t that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask themselves why that level of interoperability isn't mandatory= .
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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



--
=

= Robert Cragie

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
 http://www.gridmerge.com


--20cf307d033ef48a8004ae683d6d-- From jeff.tantsura@ericsson.com Mon Oct 3 11:08:03 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A165521F8CDB; Mon, 3 Oct 2011 11:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.863 X-Spam-Level: X-Spam-Status: No, score=-5.863 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8a7wriR35Lu; Mon, 3 Oct 2011 11:08:02 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 987EC21F8CD0; Mon, 3 Oct 2011 11:08:02 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p93IB0SA004308; Mon, 3 Oct 2011 13:11:03 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.14]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 3 Oct 2011 14:10:59 -0400 From: Jeff Tantsura Date: Mon, 3 Oct 2011 14:10:58 -0400 Subject: Re: [homenet] Question for you Thread-Topic: [homenet] Question for you Thread-Index: AcyB983JGlE+vn1VT2W9QAMzXWRwvw== Message-ID: In-Reply-To: <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 18:08:03 -0000 +1 - we know LS protocols rather well to not to use them Today's in-home devices have more CPU horsepower/memory than an OSPF router 10 years ago, there's also no reason to reinvent the wheel, perhaps we should separate 2012 goals from long term ones. Having "dumb" end nodes + border router in-between in the beginning and e2e native communication as the end model worked rather well over the years. Cheers, Jeff=20 On 10/3/11 9:15 AM, "Tony Li" wrote: > >The problem with a RIP like protocol is that it will have RIP like >convergence properties. IMHO, that's no longer acceptable. > >Doing a subset of a LS protocol with a trivial default configuration >should not be unreasonable. > >Tony > > >On Oct 3, 2011, at 8:58 AM, Randy Turner wrote: > >>=20 >> I would hope that we would NOT be seriously considering OSPF or IS-IS >>in the home...this seems like using a sledgehammer to kill an ant. How >>many routes are we talking about for a home network? I don't believe >>any enterprise routing protocol was designed for a "zeroconf" or >>"zeroadmin" type of environment. Our customers won't even know what an >>IP address is. >>=20 >> Seems like a "RIP-like" (around the same scope of complexity) would be >>enough for a homenet. I'm curious to see what comes out of the LLN >>discussion. >>=20 >> The "filter" for any of these decisions should probably always be a >>"zeroconf" or "zeroadmin" scenario -- if a proposed approach to a >>problem can't exist in a "zeroconf/admin" environment, then I would >>think it would not be the right choice. Also, as a "first cut" >>solution, we I think we should be focused on the 80% use-case, not the >>fringe. The participants of this working group, and their respective >>home networking setups, are probably not our "typical" customer. >>=20 >> Randy >>=20 >>=20 >> On Oct 3, 2011, at 8:33 AM, Qiong wrote: >>=20 >>> Hi, Acee, >>>=20 >>> Agree. I think the HOMENET requirements should be derived from major >>>devices in the home network scenario. Maybe currently we should firstly >>>focus on multiple router scenario for traditional fixed and wireless >>>network for multiple services (especially WiFi) , and then introduce >>>LLN network as well for smart objects in the same environment, together >>>with the homenet architecture and new model in the future. >>>=20 >>> Best wishes=20 >>>=20 >>> Qiong=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> I think a viable option for 2012 is that if the LLN networks with >>>their smart objects have to connect to the traditional HOMENET fixed >>>and wireless networks, they will need to do so through a border router >>>supporting both environments. IMHO, we don't need one protocol that >>>meets all requirements for every possible device in the home. >>>=20 >>> Thanks, >>> Acee >>>=20 >>>=20 >>>=20 >>> > >>> >> >>> >> My first choice would NOT be something that isn't proven in the >>>field in multiple interoperable implementations. >>> >> >>> >> As a person thinking about making a recommendation, I'd suggest >>>that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and >>>ask themselves why that level of interoperability isn't mandatory. >>> >> _______________________________________________ >>> >> homenet mailing list >>> >> homenet@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/homenet >>> > >>> > _______________________________________________ >>> > homenet mailing list >>> > homenet@ietf.org >>> > https://www.ietf.org/mailman/listinfo/homenet >>>=20 >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>>=20 >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg > >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg From tony.li@tony.li Mon Oct 3 11:23:27 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F3621F8C87 for ; Mon, 3 Oct 2011 11:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9L5T9hDSNKpv for ; Mon, 3 Oct 2011 11:23:24 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 05F7E21F8C12 for ; Mon, 3 Oct 2011 11:23:23 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta09.westchester.pa.mail.comcast.net with comcast id gAfk1h0021YDfWL59JSToE; Mon, 03 Oct 2011 18:26:27 +0000 Received: from [10.155.34.172] ([128.107.239.233]) by omta20.westchester.pa.mail.comcast.net with comcast id gJRw1h00W52qHCY3gJS0ff; Mon, 03 Oct 2011 18:26:25 +0000 Subject: Re: [manet] [homenet] Question for you Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Mon, 3 Oct 2011 11:25:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> To: Ulrich Herberg X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 03 Oct 2011 11:24:25 -0700 Cc: C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 18:23:27 -0000 What's the rationale for not subsetting OSPF or IS-IS? Tony On Oct 3, 2011, at 11:22 AM, Ulrich Herberg wrote: > Hi Tony, >=20 > I agree. I would like to mention that we are specifying an extensible, = flexible (using TLVs) LS protocol in the MANET WG: OLSRv2. I think that = we are not far from submitting it to the IESG. OLSRv2 could well operate = on home devices with limited resources, and does not have the issues of = RIP. >=20 > Regards > Ulrich=20 >=20 > On Mon, Oct 3, 2011 at 9:15 AM, Tony Li wrote: >=20 > The problem with a RIP like protocol is that it will have RIP like = convergence properties. IMHO, that's no longer acceptable. >=20 > Doing a subset of a LS protocol with a trivial default configuration = should not be unreasonable. >=20 > Tony >=20 >=20 > On Oct 3, 2011, at 8:58 AM, Randy Turner wrote: >=20 > > > > I would hope that we would NOT be seriously considering OSPF or = IS-IS in the home...this seems like using a sledgehammer to kill an ant. = How many routes are we talking about for a home network? I don't = believe any enterprise routing protocol was designed for a "zeroconf" or = "zeroadmin" type of environment. Our customers won't even know what an = IP address is. > > > > Seems like a "RIP-like" (around the same scope of complexity) would = be enough for a homenet. I'm curious to see what comes out of the LLN = discussion. > > > > The "filter" for any of these decisions should probably always be a = "zeroconf" or "zeroadmin" scenario -- if a proposed approach to a = problem can't exist in a "zeroconf/admin" environment, then I would = think it would not be the right choice. Also, as a "first cut" = solution, we I think we should be focused on the 80% use-case, not the = fringe. The participants of this working group, and their respective = home networking setups, are probably not our "typical" customer. > > > > Randy > > > > > > On Oct 3, 2011, at 8:33 AM, Qiong wrote: > > > >> Hi, Acee, > >> > >> Agree. I think the HOMENET requirements should be derived from = major devices in the home network scenario. Maybe currently we should = firstly focus on multiple router scenario for traditional fixed and = wireless network for multiple services (especially WiFi) , and then = introduce LLN network as well for smart objects in the same environment, = together with the homenet architecture and new model in the future. > >> > >> Best wishes > >> > >> Qiong > >> > >> > >> > >> > >> I think a viable option for 2012 is that if the LLN networks with = their smart objects have to connect to the traditional HOMENET fixed and = wireless networks, they will need to do so through a border router = supporting both environments. IMHO, we don't need one protocol that = meets all requirements for every possible device in the home. > >> > >> Thanks, > >> Acee > >> > >> > >> > >> > > >> >> > >> >> My first choice would NOT be something that isn't proven in the = field in multiple interoperable implementations. > >> >> > >> >> As a person thinking about making a recommendation, I'd suggest = that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and = ask themselves why that level of interoperability isn't mandatory. > >> >> _______________________________________________ > >> >> homenet mailing list > >> >> homenet@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/homenet > >> > > >> > _______________________________________________ > >> > homenet mailing list > >> > homenet@ietf.org > >> > https://www.ietf.org/mailman/listinfo/homenet > >> > >> _______________________________________________ > >> homenet mailing list > >> homenet@ietf.org > >> https://www.ietf.org/mailman/listinfo/homenet > >> > >> _______________________________________________ > >> homenet mailing list > >> homenet@ietf.org > >> https://www.ietf.org/mailman/listinfo/homenet > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From ulrich@herberg.name Mon Oct 3 11:19:30 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B349D21F8CF8; Mon, 3 Oct 2011 11:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPQo6f+VZz-U; Mon, 3 Oct 2011 11:19:29 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A439B21F8CF7; Mon, 3 Oct 2011 11:19:28 -0700 (PDT) Received: by wwf22 with SMTP id 22so4294283wwf.13 for ; Mon, 03 Oct 2011 11:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7NF6mEhyAWQdSYTjeb6T2ijt1G1bTbSxrQYK89uy3j4=; b=o6R9IyhFptxpO4ivemN9n/JnBYd1FB1dn+PijgvenHjbh1ouUYSdKZwqSwcfXYInrS gUrhtjQXsjDzjLa/xH4UiPXmYq3HTYz2Uiuw785TNGsrQM6E66/ZQeHxz0Ag8M1yuLcI FAj81UlEE8WuWt82PnHnP/lhEomCot6u00iMo= MIME-Version: 1.0 Received: by 10.227.30.154 with SMTP id u26mr265578wbc.73.1317666150824; Mon, 03 Oct 2011 11:22:30 -0700 (PDT) Received: by 10.227.7.68 with HTTP; Mon, 3 Oct 2011 11:22:30 -0700 (PDT) In-Reply-To: <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> Date: Mon, 3 Oct 2011 11:22:30 -0700 Message-ID: Subject: Re: [manet] [homenet] Question for you From: Ulrich Herberg To: Tony Li Content-Type: multipart/alternative; boundary=002215974902da3d1004ae690e61 X-Mailman-Approved-At: Mon, 03 Oct 2011 11:24:33 -0700 Cc: C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 18:19:30 -0000 --002215974902da3d1004ae690e61 Content-Type: text/plain; charset=ISO-8859-1 Hi Tony, I agree. I would like to mention that we are specifying an extensible, flexible (using TLVs) LS protocol in the MANET WG: OLSRv2. I think that we are not far from submitting it to the IESG. OLSRv2 could well operate on home devices with limited resources, and does not have the issues of RIP. Regards Ulrich On Mon, Oct 3, 2011 at 9:15 AM, Tony Li wrote: > > The problem with a RIP like protocol is that it will have RIP like > convergence properties. IMHO, that's no longer acceptable. > > Doing a subset of a LS protocol with a trivial default configuration should > not be unreasonable. > > Tony > > > On Oct 3, 2011, at 8:58 AM, Randy Turner wrote: > > > > > I would hope that we would NOT be seriously considering OSPF or IS-IS in > the home...this seems like using a sledgehammer to kill an ant. How many > routes are we talking about for a home network? I don't believe any > enterprise routing protocol was designed for a "zeroconf" or "zeroadmin" > type of environment. Our customers won't even know what an IP address is. > > > > Seems like a "RIP-like" (around the same scope of complexity) would be > enough for a homenet. I'm curious to see what comes out of the LLN > discussion. > > > > The "filter" for any of these decisions should probably always be a > "zeroconf" or "zeroadmin" scenario -- if a proposed approach to a problem > can't exist in a "zeroconf/admin" environment, then I would think it would > not be the right choice. Also, as a "first cut" solution, we I think we > should be focused on the 80% use-case, not the fringe. The participants of > this working group, and their respective home networking setups, are > probably not our "typical" customer. > > > > Randy > > > > > > On Oct 3, 2011, at 8:33 AM, Qiong wrote: > > > >> Hi, Acee, > >> > >> Agree. I think the HOMENET requirements should be derived from major > devices in the home network scenario. Maybe currently we should firstly > focus on multiple router scenario for traditional fixed and wireless network > for multiple services (especially WiFi) , and then introduce LLN network as > well for smart objects in the same environment, together with the homenet > architecture and new model in the future. > >> > >> Best wishes > >> > >> Qiong > >> > >> > >> > >> > >> I think a viable option for 2012 is that if the LLN networks with their > smart objects have to connect to the traditional HOMENET fixed and wireless > networks, they will need to do so through a border router supporting both > environments. IMHO, we don't need one protocol that meets all requirements > for every possible device in the home. > >> > >> Thanks, > >> Acee > >> > >> > >> > >> > > >> >> > >> >> My first choice would NOT be something that isn't proven in the field > in multiple interoperable implementations. > >> >> > >> >> As a person thinking about making a recommendation, I'd suggest that > folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask > themselves why that level of interoperability isn't mandatory. > >> >> _______________________________________________ > >> >> homenet mailing list > >> >> homenet@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/homenet > >> > > >> > _______________________________________________ > >> > homenet mailing list > >> > homenet@ietf.org > >> > https://www.ietf.org/mailman/listinfo/homenet > >> > >> _______________________________________________ > >> homenet mailing list > >> homenet@ietf.org > >> https://www.ietf.org/mailman/listinfo/homenet > >> > >> _______________________________________________ > >> homenet mailing list > >> homenet@ietf.org > >> https://www.ietf.org/mailman/listinfo/homenet > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --002215974902da3d1004ae690e61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tony,

I agree. I would like to mention that we are specifying an = extensible, flexible (using TLVs) LS protocol in the MANET WG: OLSRv2. I th= ink that we are not far from submitting it to the IESG. OLSRv2 could well o= perate on home devices with limited resources, and does not have the issues= of RIP.

Regards
Ulrich

On Mon, Oct 3, 201= 1 at 9:15 AM, Tony Li <tony.li@tony.li> wrote:


On Oct 3, 2011, at 8:58 AM, Randy Turner wrote:

>
> I would hope that we would NOT be seriously considering OSPF or IS-IS = in the home...this seems like using a sledgehammer to kill an ant. =A0How m= any routes are we talking about for a home network? =A0I don't believe = any enterprise routing protocol was designed for a "zeroconf" or = "zeroadmin" type of environment. =A0Our customers won't even = know what an IP address is.
>
> Seems like a "RIP-like" (around the same scope of complexity= ) would be enough for a homenet. =A0I'm curious to see what comes out o= f the LLN discussion.
>
> The "filter" for any of these decisions should probably alwa= ys be a "zeroconf" or "zeroadmin" scenario -- if a prop= osed approach to a problem can't exist in a "zeroconf/admin" = environment, then I would think it would not be the right choice. =A0Also, = as a "first cut" solution, we I think we should be focused on the= 80% use-case, not the fringe. =A0The participants of this working group, a= nd their respective home networking setups, are probably not our "typi= cal" customer.
>
> Randy
>
>
> On Oct 3, 2011, at 8:33 AM, Qiong wrote:
>
>> Hi, Acee,
>>
>> Agree. I think the HOMENET requirements should be derived from maj= or devices in the home network scenario. Maybe currently we should firstly = focus on multiple router scenario for traditional fixed and wireless networ= k for multiple services (especially WiFi) , and then introduce LLN network = as well for smart objects in the same environment, together with the homene= t architecture and new model in the future.
>>
>> Best wishes
>>
>> Qiong
>>
>>
>>
>>
>> I think a viable option for 2012 is that if the LLN networks with = their smart objects have to connect to the traditional HOMENET fixed and wi= reless networks, they will need to do so through a border router supporting= both environments. IMHO, we don't need one protocol that meets all req= uirements for every possible device in the home.
>>
>> Thanks,
>> Acee
>>
>>
>>
>> >
>> >>
>> >> My first choice would NOT be something that isn't pro= ven in the field in multiple interoperable implementations.
>> >>
>> >> As a person thinking about making a recommendation, I'= ;d suggest that folks read https://tools.ietf.org/html/rfc2026#section= -4.1.2 and ask themselves why that level of interoperability isn't = mandatory.
>> >> _______________________________________________
>> >> homenet mailing list
>> >> homenet@ietf.org<= br> >> >> https://www.ietf.org/mailman/listinfo/homenet
>> >
>> > _______________________________________________
>> > homenet mailing list
>> > homenet@ietf.org
>> > https://www.ietf.org/mailman/listinfo/homenet
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--002215974902da3d1004ae690e61-- From gettysjim@gmail.com Mon Oct 3 11:25:08 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0327421F8B8B; Mon, 3 Oct 2011 11:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjkxujNfHG6C; Mon, 3 Oct 2011 11:25:07 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF99D21F8C98; Mon, 3 Oct 2011 11:25:06 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4702708vcb.31 for ; Mon, 03 Oct 2011 11:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+ePcMY+M3WAkB++jeChui9fwWYxCcUZnOtIW4kX3ULU=; b=GOBnn2Sto4V+8MeyLwwheXs52u/1s2QuxumbwbDulx1oCsYp9p6BFNGkJBkk5+XH0G Dfhq1Y+7rjQV4RMSMXDb6Zo7xqCfBhPr9PRCJY/FpFW2gxssLsYM2+u9NYo9GJQRg4e7 0HWNygPm6f90CCaGPFPn+61sbv6imhtgQvjVU= Received: by 10.52.89.239 with SMTP id br15mr246497vdb.428.1317666489517; Mon, 03 Oct 2011 11:28:09 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id ja7sm14708026vdb.16.2011.10.03.11.28.07 (version=SSLv3 cipher=OTHER); Mon, 03 Oct 2011 11:28:08 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E89FEB6.3040904@freedesktop.org> Date: Mon, 03 Oct 2011 14:28:06 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Lorenzo Colitti Subject: Re: [homenet] Question for you References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 03 Oct 2011 11:28:12 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 18:25:08 -0000 I think there is another set of routing issues that most have not thought about unless they have had experience with wireless networking; that is the possible need for diversity aware routing. See: http://www.pps.jussieu.fr/~jch/software/babel/wbmv4.pdf For an introduction to the topic, and some work in the area (e.g. babelz). In my house, for example, I have great trouble getting wires where all I need them, and I need multiple access points. I'd like to put one out in the pool shed, and I really can't get wires out there (without digging). This may or may not be orthogonal to the routing requirements to support multi-homing and multiple providers, but is something that many/most routing protocols have not dealt with in the past. - Jim From tony.li@tony.li Mon Oct 3 11:33:02 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8512C21F8C5C for ; Mon, 3 Oct 2011 11:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPUlLAsQZArp for ; Mon, 3 Oct 2011 11:33:02 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by ietfa.amsl.com (Postfix) with ESMTP id 02DFE21F8CB5 for ; Mon, 3 Oct 2011 11:33:02 -0700 (PDT) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta10.emeryville.ca.mail.comcast.net with comcast id gJbC1h0030b6N64AAJbzBv; Mon, 03 Oct 2011 18:35:59 +0000 Received: from [10.155.34.172] ([128.107.239.233]) by omta03.emeryville.ca.mail.comcast.net with comcast id gJbk1h00N52qHCY8PJbnF5; Mon, 03 Oct 2011 18:36:11 +0000 Subject: Re: [homenet] Question for you Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <4E89FEB6.3040904@freedesktop.org> Date: Mon, 3 Oct 2011 11:35:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E89FEB6.3040904@freedesktop.org> To: Jim Gettys X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 03 Oct 2011 11:39:20 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" , Lorenzo Colitti X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 18:33:02 -0000 LS protocols give every router a full picture of the topology, so the = diversity is apparent to all nodes. Tony On Oct 3, 2011, at 11:28 AM, Jim Gettys wrote: > I think there is another set of routing issues that most have not > thought about unless they have had experience with wireless = networking; > that is the possible need for diversity aware routing. >=20 > See: >=20 > http://www.pps.jussieu.fr/~jch/software/babel/wbmv4.pdf > >=20 > For an introduction to the topic, and some work in the area (e.g. = babelz). >=20 > In my house, for example, I have great trouble getting wires where all = I > need them, and I need multiple access points. I'd like to put one out > in the pool shed, and I really can't get wires out there (without = digging). >=20 > This may or may not be orthogonal to the routing requirements to = support > multi-homing and multiple providers, but is something that many/most > routing protocols have not dealt with in the past. > - Jim >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From ulrich@herberg.name Mon Oct 3 11:39:41 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B6321F8D5C; Mon, 3 Oct 2011 11:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTJOX96C4KMl; Mon, 3 Oct 2011 11:39:39 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 721AB21F8D5A; Mon, 3 Oct 2011 11:39:38 -0700 (PDT) Received: by wyh21 with SMTP id 21so4012470wyh.31 for ; Mon, 03 Oct 2011 11:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V2l3enkK5NGNLPc8qIkwLl+mSlNRfDpB/iLAuk/waIs=; b=oU1d4AYf7+j2rf45E+3jjLJufcnFKxmzrp7xd5XaRIdSpBhAIB6qfxihRpDjTa35qR EWHtnm7LNzBfOJK8cThlxJAoog3Hzg/5N1vOa08O70F1BbMml6atbaNIQtVUS8YFFq8r IG9MzicMUiquYTZhDu9moC+J9KVIwAhrlj5pQ= MIME-Version: 1.0 Received: by 10.227.157.77 with SMTP id a13mr297130wbx.73.1317667359068; Mon, 03 Oct 2011 11:42:39 -0700 (PDT) Received: by 10.227.7.68 with HTTP; Mon, 3 Oct 2011 11:42:38 -0700 (PDT) In-Reply-To: <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> Date: Mon, 3 Oct 2011 11:42:38 -0700 Message-ID: Subject: Re: [manet] [homenet] Question for you From: Ulrich Herberg To: Tony Li Content-Type: multipart/alternative; boundary=0016e65503a8de969e04ae6956fe X-Mailman-Approved-At: Mon, 03 Oct 2011 11:42:05 -0700 Cc: C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 18:39:41 -0000 --0016e65503a8de969e04ae6956fe Content-Type: text/plain; charset=ISO-8859-1 Hi Tony, One reason for using OLSRv2 instead of OSPF is that it is optimized for wireless radio (fewer transmissions, optimized flooding, link bidirectionality check, compressed packet format, IPv6 support). Its TLV structure allows for extending the protocol easily (and for encapsulating other, arbitrary, data into control traffic messages). I assume that not all routers are required to be connected by cable in HOMENET, but some could be wireless (please correct me if I am wrong here...). I am not saying that OSPF is not (or less) suitable for these cases, but it may be worth considering the work done in MANET for HOMENET. Regards Ulrich On Mon, Oct 3, 2011 at 11:25 AM, Tony Li wrote: > > > What's the rationale for not subsetting OSPF or IS-IS? > > Tony > > > On Oct 3, 2011, at 11:22 AM, Ulrich Herberg wrote: > > > Hi Tony, > > > > I agree. I would like to mention that we are specifying an extensible, > flexible (using TLVs) LS protocol in the MANET WG: OLSRv2. I think that we > are not far from submitting it to the IESG. OLSRv2 could well operate on > home devices with limited resources, and does not have the issues of RIP. > > > > Regards > > Ulrich > > > > On Mon, Oct 3, 2011 at 9:15 AM, Tony Li wrote: > > > > The problem with a RIP like protocol is that it will have RIP like > convergence properties. IMHO, that's no longer acceptable. > > > > Doing a subset of a LS protocol with a trivial default configuration > should not be unreasonable. > > > > Tony > > > > > > On Oct 3, 2011, at 8:58 AM, Randy Turner wrote: > > > > > > > > I would hope that we would NOT be seriously considering OSPF or IS-IS > in the home...this seems like using a sledgehammer to kill an ant. How many > routes are we talking about for a home network? I don't believe any > enterprise routing protocol was designed for a "zeroconf" or "zeroadmin" > type of environment. Our customers won't even know what an IP address is. > > > > > > Seems like a "RIP-like" (around the same scope of complexity) would be > enough for a homenet. I'm curious to see what comes out of the LLN > discussion. > > > > > > The "filter" for any of these decisions should probably always be a > "zeroconf" or "zeroadmin" scenario -- if a proposed approach to a problem > can't exist in a "zeroconf/admin" environment, then I would think it would > not be the right choice. Also, as a "first cut" solution, we I think we > should be focused on the 80% use-case, not the fringe. The participants of > this working group, and their respective home networking setups, are > probably not our "typical" customer. > > > > > > Randy > > > > > > > > > On Oct 3, 2011, at 8:33 AM, Qiong wrote: > > > > > >> Hi, Acee, > > >> > > >> Agree. I think the HOMENET requirements should be derived from major > devices in the home network scenario. Maybe currently we should firstly > focus on multiple router scenario for traditional fixed and wireless network > for multiple services (especially WiFi) , and then introduce LLN network as > well for smart objects in the same environment, together with the homenet > architecture and new model in the future. > > >> > > >> Best wishes > > >> > > >> Qiong > > >> > > >> > > >> > > >> > > >> I think a viable option for 2012 is that if the LLN networks with > their smart objects have to connect to the traditional HOMENET fixed and > wireless networks, they will need to do so through a border router > supporting both environments. IMHO, we don't need one protocol that meets > all requirements for every possible device in the home. > > >> > > >> Thanks, > > >> Acee > > >> > > >> > > >> > > >> > > > >> >> > > >> >> My first choice would NOT be something that isn't proven in the > field in multiple interoperable implementations. > > >> >> > > >> >> As a person thinking about making a recommendation, I'd suggest > that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask > themselves why that level of interoperability isn't mandatory. > > >> >> _______________________________________________ > > >> >> homenet mailing list > > >> >> homenet@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/homenet > > >> > > > >> > _______________________________________________ > > >> > homenet mailing list > > >> > homenet@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/homenet > > >> > > >> _______________________________________________ > > >> homenet mailing list > > >> homenet@ietf.org > > >> https://www.ietf.org/mailman/listinfo/homenet > > >> > > >> _______________________________________________ > > >> homenet mailing list > > >> homenet@ietf.org > > >> https://www.ietf.org/mailman/listinfo/homenet > > > > > > _______________________________________________ > > > rtgwg mailing list > > > rtgwg@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > --0016e65503a8de969e04ae6956fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tony,

One reason for using OLSRv2 instead of OSPF is that it is o= ptimized for wireless radio (fewer transmissions, optimized flooding, link = bidirectionality check, compressed packet format, IPv6 support). Its TLV st= ructure allows for extending the protocol easily (and for encapsulating oth= er, arbitrary, data into control traffic messages). I assume that not all r= outers are required to be connected by cable in HOMENET, but some could be = wireless (please correct me if I am wrong here...).

I am not saying that OSPF is not (or less) suitable for these cases, bu= t it may be worth considering the work done in MANET for HOMENET.

R= egards
Ulrich

On Mon, Oct 3, 2011 at 1= 1:25 AM, Tony Li <t= ony.li@tony.li> wrote:


What's the rationale for not subsetting OSPF or IS-IS?

Tony


On Oct 3, 2011, at 11:22 AM, Ulrich Herberg wrote:

> Hi Tony,
>
> I agree. I would like to mention that we are specifying an extensible,= flexible (using TLVs) LS protocol in the MANET WG: OLSRv2. I think that we= are not far from submitting it to the IESG. OLSRv2 could well operate on h= ome devices with limited resources, and does not have the issues of RIP. >
> Regards
> Ulrich
>
> On Mon, Oct 3, 2011 at 9:15 AM, Tony Li <tony.li@tony.li> wrote:
>
> The problem with a RIP like protocol is that it will have RIP like con= vergence properties. =A0IMHO, that's no longer acceptable.
>
> Doing a subset of a LS protocol with a trivial default configuration s= hould not be unreasonable.
>
> Tony
>
>
> On Oct 3, 2011, at 8:58 AM, Randy Turner wrote:
>
> >
> > I would hope that we would NOT be seriously considering OSPF or I= S-IS in the home...this seems like using a sledgehammer to kill an ant. =A0= How many routes are we talking about for a home network? =A0I don't bel= ieve any enterprise routing protocol was designed for a "zeroconf"= ; or "zeroadmin" type of environment. =A0Our customers won't = even know what an IP address is.
> >
> > Seems like a "RIP-like" (around the same scope of compl= exity) would be enough for a homenet. =A0I'm curious to see what comes = out of the LLN discussion.
> >
> > The "filter" for any of these decisions should probably= always be a "zeroconf" or "zeroadmin" scenario -- if a= proposed approach to a problem can't exist in a "zeroconf/admin&q= uot; environment, then I would think it would not be the right choice. =A0A= lso, as a "first cut" solution, we I think we should be focused o= n the 80% use-case, not the fringe. =A0The participants of this working gro= up, and their respective home networking setups, are probably not our "= ;typical" customer.
> >
> > Randy
> >
> >
> > On Oct 3, 2011, at 8:33 AM, Qiong wrote:
> >
> >> Hi, Acee,
> >>
> >> Agree. I think the HOMENET requirements should be derived fro= m major devices in the home network scenario. Maybe currently we should fir= stly focus on multiple router scenario for traditional fixed and wireless n= etwork for multiple services (especially WiFi) , and then introduce LLN net= work as well for smart objects in the same environment, together with the h= omenet architecture and new model in the future.
> >>
> >> Best wishes
> >>
> >> Qiong
> >>
> >>
> >>
> >>
> >> I think a viable option for 2012 is that if the LLN networks = with their smart objects have to connect to the traditional HOMENET fixed a= nd wireless networks, they will need to do so through a border router suppo= rting both environments. IMHO, we don't need one protocol that meets al= l requirements for every possible device in the home.
> >>
> >> Thanks,
> >> Acee
> >>
> >>
> >>
> >> >
> >> >>
> >> >> My first choice would NOT be something that isn'= t proven in the field in multiple interoperable implementations.
> >> >>
> >> >> As a person thinking about making a recommendation, = I'd suggest that folks read https://tools.ietf.org/html/rfc2026#se= ction-4.1.2 and ask themselves why that level of interoperability isn&#= 39;t mandatory.
> >> >> _______________________________________________
> >> >> homenet mailing list
> >> >> homenet@ietf.org=
> >> >> https://www.ietf.org/mailman/listinfo/homenet > >> >
> >> > _______________________________________________
> >> > homenet mailing list
> >> > homenet@ietf.org=
> >> > https://www.ietf.org/mailman/listinfo/homenet
> >>
> >> _______________________________________________
> >> homenet mailing list
> >> homenet@ietf.org
> >> https://www.ietf.org/mailman/listinfo/homenet
> >>
> >> _______________________________________________
> >> homenet mailing list
> >> homenet@ietf.org
> >> https://www.ietf.org/mailman/listinfo/homenet
> >
> > _______________________________________________
> > rtgwg mailing list
> > rtgwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtgwg
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>


--0016e65503a8de969e04ae6956fe-- From robert@raszuk.net Mon Oct 3 11:46:11 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2385321F8D6E for ; Mon, 3 Oct 2011 11:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZNlAKBO-yRH for ; Mon, 3 Oct 2011 11:46:10 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 5B6B321F8CFC for ; Mon, 3 Oct 2011 11:46:10 -0700 (PDT) Received: (qmail 26014 invoked by uid 399); 3 Oct 2011 18:49:10 -0000 Received: from unknown (HELO ?192.168.1.57?) (178.42.87.122) by mail37.opentransfer.com with SMTP; 3 Oct 2011 18:49:10 -0000 Message-ID: <4E8A03A5.5080601@raszuk.net> Date: Mon, 03 Oct 2011 20:49:09 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ulrich Herberg Subject: Re: [manet] [homenet] Question for you References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 03 Oct 2011 12:19:09 -0700 Cc: C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Qiong , Acee Lindem , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 18:46:11 -0000 One thing I am perhaps missing in this thread ... Why a wireless access point at the pool has to also be a router ? Isn't it sufficient to extend one or more layer 2 to it ? Thx, R. > Hi Tony, > > One reason for using OLSRv2 instead of OSPF is that it is optimized for > wireless radio (fewer transmissions, optimized flooding, link > bidirectionality check, compressed packet format, IPv6 support). Its TLV > structure allows for extending the protocol easily (and for encapsulating > other, arbitrary, data into control traffic messages). I assume that not all > routers are required to be connected by cable in HOMENET, but some could be > wireless (please correct me if I am wrong here...). > > I am not saying that OSPF is not (or less) suitable for these cases, but it > may be worth considering the work done in MANET for HOMENET. > > Regards > Ulrich From gettysjim@gmail.com Mon Oct 3 12:07:30 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BC421F8C45; Mon, 3 Oct 2011 12:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCFW4RnGOOAL; Mon, 3 Oct 2011 12:07:30 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 28F4621F8C3A; Mon, 3 Oct 2011 12:07:26 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4752328vcb.31 for ; Mon, 03 Oct 2011 12:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RT953tceKRy9VbH/a2FkElpZtaDnmhwb56qJ1McT2b8=; b=YRKM/puxiTDinfOTrEs+rg2Ntp6VgfQgdR12YDlG5+Lzjl+PmLvMdMDKMxzCVOwlsH IKVnzvot+yT61rzxh/Z1nifsmzTu1tdoxRZuao37egwZnFVQDzfwSpOaHh/iEAyEm1on TOLINl5oZxzPOoKZY4FBekWqfb3GV9Ag1pJls= Received: by 10.52.98.3 with SMTP id ee3mr298227vdb.351.1317669028516; Mon, 03 Oct 2011 12:10:28 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id c20sm14833554vdt.6.2011.10.03.12.10.26 (version=SSLv3 cipher=OTHER); Mon, 03 Oct 2011 12:10:27 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E8A08A1.7000106@freedesktop.org> Date: Mon, 03 Oct 2011 15:10:25 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Tony Li Subject: Re: [homenet] Question for you References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E89FEB6.3040904@freedesktop.org> <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> In-Reply-To: <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 03 Oct 2011 12:19:09 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" , Lorenzo Colitti X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 19:07:31 -0000 On 10/03/2011 02:35 PM, Tony Li wrote: > LS protocols give every router a full picture of the topology, so the diversity is apparent to all nodes. My point was just that wireless has a set of challenges that all may not be familiar with; knowing that may help point the discussion in fruitful ways. Routing isn't my area of expertise (though I have scars on my back from it in wireless...). - Jim > > Tony > > > On Oct 3, 2011, at 11:28 AM, Jim Gettys wrote: > >> I think there is another set of routing issues that most have not >> thought about unless they have had experience with wireless networking; >> that is the possible need for diversity aware routing. >> >> See: >> >> http://www.pps.jussieu.fr/~jch/software/babel/wbmv4.pdf >> >> >> For an introduction to the topic, and some work in the area (e.g. babelz). >> >> In my house, for example, I have great trouble getting wires where all I >> need them, and I need multiple access points. I'd like to put one out >> in the pool shed, and I really can't get wires out there (without digging). >> >> This may or may not be orthogonal to the routing requirements to support >> multi-homing and multiple providers, but is something that many/most >> routing protocols have not dealt with in the past. >> - Jim >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg From tony.li@tony.li Mon Oct 3 12:29:46 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7750321F8E09 for ; Mon, 3 Oct 2011 12:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Gpi9BjAfq7V for ; Mon, 3 Oct 2011 12:29:46 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by ietfa.amsl.com (Postfix) with ESMTP id A23DB21F8DF3 for ; Mon, 3 Oct 2011 12:29:45 -0700 (PDT) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta12.emeryville.ca.mail.comcast.net with comcast id gJoc1h0031afHeLACKYjh3; Mon, 03 Oct 2011 19:32:43 +0000 Received: from [10.155.34.172] ([128.107.239.233]) by omta17.emeryville.ca.mail.comcast.net with comcast id gKSL1h01i52qHCY8dKSPrX; Mon, 03 Oct 2011 19:26:47 +0000 Subject: Re: [homenet] Question for you Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <4E8A08A1.7000106@freedesktop.org> Date: Mon, 3 Oct 2011 12:32:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <64AA82AA-80B9-43AD-8F2B-9DC2F866887A@tony.li> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E89FEB6.3040904@freedesktop.org> <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> <4E8A08A1.7000106@freedesktop.org> To: Jim Gettys X-Mailer: Apple Mail (2.1084) Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" , Lorenzo Colitti X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 19:29:46 -0000 On Oct 3, 2011, at 12:10 PM, Jim Gettys wrote: > My point was just that wireless has a set of challenges that all may = not > be familiar with; knowing that may help point the discussion in = fruitful > ways. Routing isn't my area of expertise (though I have scars on my > back from it in wireless...). Understood. Yes, wireless has some challenges and I've spent some time in that area. = Certainly our standard protocols are not optimal for a purely wireless = environment. =20 However, for the generic, heterogenous networks that I would expect in = the home, I would expect that the generic protocols would be the better = overall approach. Tony From gettysjim@gmail.com Mon Oct 3 12:42:39 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7422321F8D82; Mon, 3 Oct 2011 12:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vhhx64pwJ+ro; Mon, 3 Oct 2011 12:42:39 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 600A521F8D28; Mon, 3 Oct 2011 12:42:22 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4791739vcb.31 for ; Mon, 03 Oct 2011 12:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8g47aNweAibSgBLteuUo/RRZdPkIPHoxqZxkRHAtFq8=; b=Bvft+HMygzjKlAPJMDKaVag0/u9Lp7C1CMEPRhMdBxH5rMFwrNIsVjuUmWT6PuJMGN 90UWvT+Porh1NDj8RMwPdLWPxtmorLG38FnFIMet8nGKMiMwEF8Pa6vyG2qp4rrYxSOU i5ex4qbYTsWLACDn2ZpMUPfdoSbD44NvaA2O4= Received: by 10.220.5.210 with SMTP id 18mr104058vcw.83.1317671125138; Mon, 03 Oct 2011 12:45:25 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id o20sm14930893vdj.3.2011.10.03.12.45.23 (version=SSLv3 cipher=OTHER); Mon, 03 Oct 2011 12:45:24 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E8A10D2.1030105@freedesktop.org> Date: Mon, 03 Oct 2011 15:45:22 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Tony Li Subject: Re: [homenet] Question for you References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E89FEB6.3040904@freedesktop.org> <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> <4E8A08A1.7000106@freedesktop.org> <64AA82AA-80B9-43AD-8F2B-9DC2F866887A@tony.li> In-Reply-To: <64AA82AA-80B9-43AD-8F2B-9DC2F866887A@tony.li> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" , Lorenzo Colitti X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 19:42:39 -0000 On 10/03/2011 03:32 PM, Tony Li wrote: > On Oct 3, 2011, at 12:10 PM, Jim Gettys wrote: > >> My point was just that wireless has a set of challenges that all may not >> be familiar with; knowing that may help point the discussion in fruitful >> ways. Routing isn't my area of expertise (though I have scars on my >> back from it in wireless...). > > Understood. > > Yes, wireless has some challenges and I've spent some time in that area. Certainly our standard protocols are not optimal for a purely wireless environment. > > However, for the generic, heterogenous networks that I would expect in the home, I would expect that the generic protocols would be the better overall approach. Having been seriously scarred by presuming that wireless was similar to wired, I'm a believer in careful testing, rather than "expecting" that something should work. Without "running code", demonstrably working, I'll take nothing on faith in this area. Wireless != wired, is what I took away from that (painful) experience. - Jim > > Tony > From ulrich@herberg.name Mon Oct 3 13:00:24 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADB521F8E4A; Mon, 3 Oct 2011 13:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACXaotQLm9ax; Mon, 3 Oct 2011 13:00:23 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7E321F8E4B; Mon, 3 Oct 2011 13:00:22 -0700 (PDT) Received: by wyh21 with SMTP id 21so4097261wyh.31 for ; Mon, 03 Oct 2011 13:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=V/0/Xc29qo64CV689BadzRkO1E3mZo7dnjARW6XUbjU=; b=qcyA5KMcBSC9xtnn1OGsZOpFcisxn1hx1WS/+uyvRB2Kw2kbB82iPV3HvPhWV5qaM3 ZfDRZTTzi05egVzl8kxLLGUC71k6n7IC1Xs8JxfCf8itjALvchUYeyovEiFeafzUGK3L VTu6Bhn0QMHZQ4DZBUrrr9uSjZU5LUJH0mA2E= MIME-Version: 1.0 Received: by 10.227.7.25 with SMTP id b25mr357912wbb.103.1317672205030; Mon, 03 Oct 2011 13:03:25 -0700 (PDT) Received: by 10.227.7.68 with HTTP; Mon, 3 Oct 2011 13:03:24 -0700 (PDT) In-Reply-To: <4E8A10D2.1030105@freedesktop.org> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E89FEB6.3040904@freedesktop.org> <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> <4E8A08A1.7000106@freedesktop.org> <64AA82AA-80B9-43AD-8F2B-9DC2F866887A@tony.li> <4E8A10D2.1030105@freedesktop.org> Date: Mon, 3 Oct 2011 13:03:24 -0700 Message-ID: Subject: Re: [manet] [homenet] Question for you From: Ulrich Herberg To: Jim Gettys Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Qiong , Acee Lindem , "homenet@ietf.org" , Lorenzo Colitti , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 20:00:24 -0000 I agree with Jim. The reason why we developed OLSR and the its successor OLSRv2 was precisely that wireless environments are very different from wired. There are plenty of deployments of OLSR and several of OLSRv2, with up to several hundreds of wireless routers, so it is demonstrably working. Regards Ulrich On Mon, Oct 3, 2011 at 12:45 PM, Jim Gettys wrote: > > On 10/03/2011 03:32 PM, Tony Li wrote: > > On Oct 3, 2011, at 12:10 PM, Jim Gettys wrote: > > > >> My point was just that wireless has a set of challenges that all may n= ot > >> be familiar with; knowing that may help point the discussion in fruitf= ul > >> ways. =A0Routing isn't my area of expertise (though I have scars on my > >> back from it in wireless...). > > > > Understood. > > > > Yes, wireless has some challenges and I've spent some time in that area= . =A0Certainly our standard protocols are not optimal for a purely wireless= environment. > > > > However, for the generic, heterogenous networks that I would expect in = the home, I would expect that the generic protocols would be the better ove= rall approach. > > Having been seriously scarred by presuming that wireless was similar to > wired, I'm a believer in careful testing, rather than "expecting" that > something should work. =A0Without "running code", demonstrably working, > I'll take nothing on faith in this area. > > Wireless !=3D wired, is what I took away from that (painful) experience. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Jim > > > > > Tony > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From mcr@sandelman.ca Mon Oct 3 18:22:15 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC20521F8494; Mon, 3 Oct 2011 18:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hajmjTkZ9iYM; Mon, 3 Oct 2011 18:22:15 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id F26D921F848A; Mon, 3 Oct 2011 18:22:14 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 76A7F343AE; Mon, 3 Oct 2011 21:24:14 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 40DC29817F; Mon, 3 Oct 2011 21:26:02 -0400 (EDT) From: Michael Richardson To: Ulrich Herberg Subject: Re: [homenet] [manet] Question for you In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 03 Oct 2011 21:26:02 -0400 Message-ID: <12605.1317691562@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Mon, 03 Oct 2011 18:40:42 -0700 Cc: C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Qiong , Acee Lindem , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 01:22:15 -0000 >>>>> "Ulrich" == Ulrich Herberg writes: Ulrich> arbitrary, data into control traffic messages). I assume Ulrich> that not all routers are required to be connected by cable Ulrich> in HOMENET, but some could be wireless (please correct me if Ulrich> I am wrong here...). You should assume that essentially all devices with more than one possible interface are possible routers. So my HTC G2 has four interfaces: wifi, 3G, Bluetooth PAN, and USB-ethernet. Note that just because my 3G is up and alive, and can be used by my phone, doesn't mean that the purpose of it participating in the routing is to provide *Internet* to the rest of the house. It might only be talking to my house network to get across it so that it can turn activate a light switch... -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Mon Oct 3 18:23:57 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2357721F8B94; Mon, 3 Oct 2011 18:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYupk0YzMl9h; Mon, 3 Oct 2011 18:23:56 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id AF64721F8B74; Mon, 3 Oct 2011 18:23:56 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 218F0343A4; Mon, 3 Oct 2011 21:26:01 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 0FC849817F; Mon, 3 Oct 2011 21:27:49 -0400 (EDT) From: Michael Richardson To: robert@raszuk.net Subject: Re: [homenet] [manet] Question for you In-Reply-To: <4E8A03A5.5080601@raszuk.net> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <4E8A03A5.5080601@raszuk.net> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 03 Oct 2011 21:27:49 -0400 Message-ID: <12856.1317691669@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Mon, 03 Oct 2011 18:40:47 -0700 Cc: C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Ulrich Herberg , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 01:23:57 -0000 >>>>> "Robert" == Robert Raszuk writes: Robert> Why a wireless access point at the pool has to also be a Robert> router ? Isn't it sufficient to extend one or more layer 2 Robert> to it ? It's not much of an access point if it doesn't have a second interface, is it? If it's out at the pool, and it has no wired layer2, then it might well have a second radio (or a second ESSID), to relay. But, it might also be connected to the wired network in the pool house. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From fred@cisco.com Tue Oct 4 06:48:05 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CF521F8672; Tue, 4 Oct 2011 06:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.583 X-Spam-Level: X-Spam-Status: No, score=-104.583 tagged_above=-999 required=5 tests=[AWL=-1.984, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdY5NC5ayDim; Tue, 4 Oct 2011 06:48:05 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7F56521F8669; Tue, 4 Oct 2011 06:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1090; q=dns/txt; s=iport; t=1317736270; x=1318945870; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=vQ83kY8GgRcQFzfIt7WTzUTlxZXTCB3Z0gqj6+UsCQg=; b=iv6/W+53L4vBLSpDFwi0+wju2zFGLU8MOGb6FG0BkFIxDObcxfMg1r0k 2ub12289HzPVe+812GQqAdo0aoyxsw+ZFh8lUtG0A+sAfMQ/31zs9Uiiv mS5R0zvzY0cdKTs/MhpioiPNv7/KX3g06/q2SN74+QUpXGr/kuAwrAB+/ w=; X-IronPort-AV: E=Sophos;i="4.68,485,1312156800"; d="scan'208";a="290063" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-3.cisco.com with ESMTP; 04 Oct 2011 13:51:07 +0000 Received: from Freds-Computer.local (sin-vpn-client-16-76.cisco.com [10.68.16.76]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p94Dp51w004888; Tue, 4 Oct 2011 13:51:05 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 04 Oct 2011 21:51:06 +0800 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 04 Oct 2011 21:51:06 +0800 Subject: Re: [homenet] Question for you Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Tue, 4 Oct 2011 21:50:29 +0800 Message-Id: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 13:48:05 -0000 On Oct 4, 2011, at 12:50 AM, Lorenzo Colitti wrote: > For example, if there were a robust open-source version of IS-IS that = didn't take up too much RAM and flash, you could define TLVs to = implement zeroconf and you could get to something that works relatively = quickly. RFC 1453 specified a default OSPF configuration that my (ACC) Router = came up with by default. The only configuration necessary was to supply = IPv4 prefixes/addresses to the interfaces and to turn OSPF on. In the = context of a home, I suspect it would be pretty close. Fundamentals: = default values for most attributes are as specified in the OSPF RFC, the = metric is the duration of a bit in 10 ns units (which in LAN networks = becomes a hop count), and all interfaces are in area zero. Change things = to your heart's content, but the default configuration is one that = actually works for most purposes in a small network. I'll entertain = arguments that this doesn't address every possible configuration, but = for the networks we're discussing, I'll argue that its "close enough".= From radhika.r.roy.civ@mail.mil Tue Oct 4 08:04:10 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F56421F8C0D; Tue, 4 Oct 2011 08:04:10 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXHA-zBdfEAM; Tue, 4 Oct 2011 08:04:09 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7D421F8BBD; Tue, 4 Oct 2011 08:04:08 -0700 (PDT) Received: from UCOLHP3B.easf.csd.disa.mil (131.64.100.151) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Oct 2011 10:07:07 -0500 Received: from UCOLHP4H.easf.csd.disa.mil ([169.254.6.67]) by UCOLHP3B.easf.csd.disa.mil ([131.64.100.151]) with mapi id 14.01.0323.003; Tue, 4 Oct 2011 10:07:05 -0500 From: "Roy, Radhika R USA CIV (US)" To: Fred Baker , Lorenzo Colitti Subject: RE: [homenet] Question for you Thread-Topic: [homenet] Question for you Thread-Index: AQHMgp1Epg4erVaUIEald7KjKxFOT5VsSKHw Date: Tue, 4 Oct 2011 15:07:05 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF3AF3DD09@ucolhp4h.easf.csd.disa.mil> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.77.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 04 Oct 2011 08:37:48 -0700 Cc: C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 15:04:10 -0000 Agreed. Another idea is this: Do we also need any features like mobile ad hoc netwo= rking (e.g. OLSR) in homenet? RRR=20 -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Fred Baker Sent: Tuesday, October 04, 2011 9:50 AM To: Lorenzo Colitti Cc: Pascal Thubert (pthubert); C Chauvenet; Randy Turner; MANET IETF; Mark = Townsley; JP Vasseur; Acee Lindem; Qiong; homenet@ietf.org; rtgwg@ietf.org Subject: Re: [homenet] Question for you On Oct 4, 2011, at 12:50 AM, Lorenzo Colitti wrote: > For example, if there were a robust open-source version of IS-IS that did= n't take up too much RAM and flash, you could define TLVs to implement zero= conf and you could get to something that works relatively quickly. RFC 1453 specified a default OSPF configuration that my (ACC) Router came u= p with by default. The only configuration necessary was to supply IPv4 pref= ixes/addresses to the interfaces and to turn OSPF on. In the context of a h= ome, I suspect it would be pretty close. Fundamentals: default values for m= ost attributes are as specified in the OSPF RFC, the metric is the duration= of a bit in 10 ns units (which in LAN networks becomes a hop count), and a= ll interfaces are in area zero. Change things to your heart's content, but = the default configuration is one that actually works for most purposes in a= small network. I'll entertain arguments that this doesn't address every po= ssible configuration, but for the networks we're discussing, I'll argue tha= t its "close enough". _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From chelliot@gmail.com Tue Oct 4 09:02:25 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C2221F8AF5; Tue, 4 Oct 2011 09:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA7CZfMebOXR; Tue, 4 Oct 2011 09:02:24 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 982C221F8AF3; Tue, 4 Oct 2011 09:02:24 -0700 (PDT) Received: by gyd12 with SMTP id 12so776015gyd.31 for ; Tue, 04 Oct 2011 09:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=TdL/cCA51NYy0S/CMH8eR5GOlMHev5YnmPGSL7wJNHA=; b=jcaWCwjXwJlm0Z0lpBfl2ngq/VcU5YXhSQqBO7wRKEFIfiuS062BFsMA62u1hTFdBy SDZBaioPKdhhznnNa+UTbrZdfhst7L3t8rHsZw0H2ZACVavxTtiCvoOks1qoZLrEfYY8 UW/Q+qLy/Kue7iWcib/+Wc25sPM3gSW+Ir8QA= Received: by 10.236.181.196 with SMTP id l44mr7704235yhm.37.1317744329961; Tue, 04 Oct 2011 09:05:29 -0700 (PDT) Received: from [10.43.72.188] ([166.137.15.196]) by mx.google.com with ESMTPS id u66sm20061696yhu.13.2011.10.04.09.05.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 09:05:28 -0700 (PDT) Sender: Chris Elliott References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <4E8A03A5.5080601@raszuk.net> <12856.1317691669@marajade.sandelman.ca> In-Reply-To: <12856.1317691669@marajade.sandelman.ca> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Type: multipart/alternative; boundary=Apple-Mail-3-134710160 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (8L1) From: Chris Elliott Subject: Re: [homenet] [manet] Question for you Date: Tue, 4 Oct 2011 12:05:20 -0400 To: Michael Richardson X-Mailman-Approved-At: Tue, 04 Oct 2011 10:29:21 -0700 Cc: "homenet@ietf.org" , MANET IETF , "robert@raszuk.net" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 16:02:25 -0000 --Apple-Mail-3-134710160 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 3, 2011, at 9:27 PM, Michael Richardson wrote: >=20 >>>>>> "Robert" =3D=3D Robert Raszuk writes: > Robert> Why a wireless access point at the pool has to also be a > Robert> router ? Isn't it sufficient to extend one or more layer 2 > Robert> to it ? >=20 > It's not much of an access point if it doesn't have a second interface, > is it? If it's out at the pool, and it has no wired layer2, then it > might well have a second radio (or a second ESSID), to relay. But, it > might also be connected to the wired network in the pool house. Bridging works fine between 802.11 and 802.1--or another 802.11 link. No rou= ting required. It works for the IETF meeting networks and pretty much how all Enterprise ge= ar is setup. Let's keep it simple and only route when we have to. Chris. -- Chris Elliott CCIE # 2013 R&S --Apple-Mail-3-134710160 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 3, 2011, at 9:27 PM, Micha= el Richardson <mcr@sandelman.ca&g= t; wrote:

=
"Robert" =3D=3D Robert Raszuk <robert@raszuk.net> writes:
<= /blockquote>
  Robert> Why a wireless access point at th= e pool has to also be a
  Robert> router ? Isn't it sufficient to extend one or mor= e layer 2
 &nbs= p;Robert> to it ?
=
It's not much of an a= ccess point if it doesn't have a second interface,
is it?  If it's out at the pool, and it h= as no wired layer2, then it
might well have a second radio (or a second ESSID), to relay.  B= ut, it
might also be c= onnected to the wired network in the pool house.

Bridging works fine between 802.11 and 802.1--or another 8= 02.11 link. No routing required.

It works for the IETF meeting networks and pretty much how all Enterprise g= ear is setup.

Let's keep it simple and only route w= hen we have to.

Chris.

--<= /div>
Chris Elliott
CCIE # 2013 R&S

= --Apple-Mail-3-134710160-- From albert.e.manfredi@boeing.com Tue Oct 4 12:12:58 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE1B21F8F2A; Tue, 4 Oct 2011 12:12:58 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59IE4Eyy81K2; Tue, 4 Oct 2011 12:12:58 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 14D9121F8F29; Tue, 4 Oct 2011 12:12:58 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p94JFuqY013390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Oct 2011 12:16:01 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p94JFuBk009215; Tue, 4 Oct 2011 12:15:56 -0700 (PDT) Received: from XCH-MWHT-05.mw.nos.boeing.com (xch-mwht-05.mw.nos.boeing.com [134.57.119.160]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p94JFlL9008835 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 4 Oct 2011 12:15:55 -0700 (PDT) Received: from XCH-MWPFX-01.mw.nos.boeing.com (132.173.24.10) by XCH-MWHT-05.mw.nos.boeing.com (134.57.119.160) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 4 Oct 2011 14:15:47 -0500 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.118.180]) by XCH-MWPFX-01.mw.nos.boeing.com ([132.173.24.10]) with mapi; Tue, 4 Oct 2011 14:15:47 -0500 From: "Manfredi, Albert E" To: Michael Richardson , "robert@raszuk.net" Date: Tue, 4 Oct 2011 14:15:44 -0500 Subject: RE: [homenet] [manet] Question for you Thread-Topic: [homenet] [manet] Question for you Thread-Index: AcyCNxgRBuUVaon0Tb6zv65PHfvi/wAkiNgQ Message-ID: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <4E8A03A5.5080601@raszuk.net> <12856.1317691669@marajade.sandelman.ca> In-Reply-To: <12856.1317691669@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18426.000 x-tm-as-result: No--49.732200-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" , MANET IETF , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 19:12:58 -0000 > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of Michael Richardson > Sent: Monday, October 03, 2011 9:28 PM > To: robert@raszuk.net > Cc: C Chauvenet; Randy Turner; MANET IETF; Mark Townsley; JP Vasseur; > Ulrich Herberg; Acee Lindem; Qiong; homenet@ietf.org; rtgwg@ietf.org > Subject: Re: [homenet] [manet] Question for you >=20 >=20 > >>>>> "Robert" =3D=3D Robert Raszuk writes: > Robert> Why a wireless access point at the pool has to also be a > Robert> router ? Isn't it sufficient to extend one or more layer 2 > Robert> to it ? >=20 > It's not much of an access point if it doesn't have a second interface, > is it? If it's out at the pool, and it has no wired layer2, then it > might well have a second radio (or a second ESSID), to relay. But, it > might also be connected to the wired network in the pool house. I don't think that's the answer. It would be perfectly plausible to connect= more the 802.11 access point on the same IP subnet as the wired network, o= r even more than one access point, all tied together at layer 2. For whatever reason, the 802.11 access points you can actually buy on the m= arket seem to incorporate a router. Seems really silly, when most homes con= nect one of these to a cable or DSL modem, both of which are also routers, = but there you have it. You end up with a stack of private IP address subnet= s. Bert From chelliot@gmail.com Tue Oct 4 15:07:07 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E7B21F8D76; Tue, 4 Oct 2011 15:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlGsC55IH8Pg; Tue, 4 Oct 2011 15:07:06 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id BD9E021F8D7F; Tue, 4 Oct 2011 15:07:05 -0700 (PDT) Received: by eye4 with SMTP id 4so1068002eye.31 for ; Tue, 04 Oct 2011 15:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=DlKTZc4LxgLDUNfML/tAzte5fxeekVt14Lh5qHff3vA=; b=FGUDzDroCzqOQ6cMAQTFW0maSz+pzC3a4loojHZPsJ8QZ0v/L3mNjAIGopn4bqv/4v D206gyYsm3yKGSB2Rl0MEvoO1nTrPSeViXwC5Ltdynhp7jZCkJlUGpaqL4vL/tnxHoQT aI9EvdhPGdoT/qlkESvT74isLRll5yF8IUCA0= Received: by 10.213.2.74 with SMTP id 10mr1007495ebi.57.1317766211356; Tue, 04 Oct 2011 15:10:11 -0700 (PDT) MIME-Version: 1.0 Sender: chelliot@gmail.com Received: by 10.213.29.207 with HTTP; Tue, 4 Oct 2011 15:09:50 -0700 (PDT) In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <4E8A03A5.5080601@raszuk.net> <12856.1317691669@marajade.sandelman.ca> From: Chris Elliott Date: Wed, 5 Oct 2011 06:09:50 +0800 X-Google-Sender-Auth: 6n6KW6p5C_OQCV4i-TpVgYcZb4A Message-ID: Subject: Re: [homenet] [manet] Question for you To: "Manfredi, Albert E" Content-Type: multipart/alternative; boundary=0015174478f2ecc75904ae805a15 X-Mailman-Approved-At: Tue, 04 Oct 2011 16:30:47 -0700 Cc: "homenet@ietf.org" , MANET IETF , Michael Richardson , "robert@raszuk.net" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chelliot@pobox.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 22:07:07 -0000 --0015174478f2ecc75904ae805a15 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 5, 2011 at 3:15 AM, Manfredi, Albert E < albert.e.manfredi@boeing.com> wrote: > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > > Of Michael Richardson > > It's not much of an access point if it doesn't have a second interface, > > is it? If it's out at the pool, and it has no wired layer2, then it > > might well have a second radio (or a second ESSID), to relay. But, it > > might also be connected to the wired network in the pool house. > > I don't think that's the answer. It would be perfectly plausible to connect > more the 802.11 access point on the same IP subnet as the wired network, or > even more than one access point, all tied together at layer 2. > > For whatever reason, the 802.11 access points you can actually buy on the > market seem to incorporate a router. Seems really silly, when most homes > connect one of these to a cable or DSL modem, both of which are also > routers, but there you have it. You end up with a stack of private IP > address subnets. > Often you can buy an access point or a wireless router. Many wireless routers have several switched Ethernet ports and a single "WAN" Ethernet port. Just don't use the "WAN" port and you're bridged. And some wireless routers (the Apple Airport series, for example) allow you to choose the mode they run in. They will bridge just fine, if you configure them that way. Of course, for a home network, routing and bridging and trunks and multiple SSIDs etc. all need to be configured automatically to a sane state. Two switches or a router and a switch can automatically trunk if they use a L2 discovery protocol, as can and AP. That same AP can then expose the VLANs on that trunk as separate SSIDs. All of this does not seem to be covered by the existing drafts. Are we assuming someone else will do this work or are we just interested in IPv6 and up? Chris. > Bert > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Chris Elliott chelliot@pobox.com CCIE # 2013 R&S --0015174478f2ecc75904ae805a15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 5, 2011 at 3:15 AM, Manfredi, Albert E <albert.e.manfredi@boeing.com<= /a>> wrote:
> From: rtgwg-bounces@ietf.org= [mailto:rtgwg-bounces@ietf.o= rg] On Behalf
> Of Michael Richardson
> It's not much of an access point if it doesn't have a second i= nterface,
> is it? =A0If it's out at the pool, and it has no wired layer2, the= n it
> might well have a second radio (or a second ESSID), to relay. =A0But, = it
> might also be connected to the wired network in the pool house.

I don't think that's the answer. It would be perfectly plausi= ble to connect more the 802.11 access point on the same IP subnet as the wi= red network, or even more than one access point, all tied together at layer= 2.

For whatever reason, the 802.11 access points you can actually buy on the m= arket seem to incorporate a router. Seems really silly, when most homes con= nect one of these to a cable or DSL modem, both of which are also routers, = but there you have it. You end up with a stack of private IP address subnet= s.

Often you can buy an access point or a wir= eless router. Many wireless routers have several switched Ethernet ports an= d a single "WAN" Ethernet port. Just don't use the "WAN&= quot; port and you're bridged. And some wireless routers (the Apple Air= port series, for example) allow you to choose the mode they run in. They wi= ll bridge just fine, if you configure them that way.

Of course, for a home network, routing and bridging and= trunks and multiple SSIDs etc. all need to be configured automatically to = a sane state. Two switches or a router and a switch can automatically trunk= if they use a L2 discovery protocol, as can and AP. That same AP can then = expose the VLANs on that trunk as separate SSIDs.

All of this does not seem to be covered by the existing= drafts. Are we assuming someone else will do this work or are we just inte= rested in IPv6 and up?

Chris.
=A0
Bert

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



--
= Chris Elliott
chelliot@pobox.com
CCIE # 2013 R&S --0015174478f2ecc75904ae805a15-- From jpv@cisco.com Tue Oct 4 23:28:00 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F50921F8A57; Tue, 4 Oct 2011 23:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.739 X-Spam-Level: X-Spam-Status: No, score=-109.739 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpOtfk2ClUeu; Tue, 4 Oct 2011 23:27:59 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1E18021F899F; Tue, 4 Oct 2011 23:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=2050; q=dns/txt; s=iport; t=1317796266; x=1319005866; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=LM/9IamnG9nsWgB8SnAJAEViCE23IvbXtJ/QHiBZhhs=; b=WocKTU+YSyfslArBhmyR5+mWEyV/CE/06rDhHGDg8JQW5rgNd+kUBWHg Q48hkRcwDUT+HDkq8pCmfee/LCDFIZ19scldEOE/RLqc5YKGEFuPK6Lzi otuWeADMl4p+DsNrYUBmAmYMj45nZPyGd9EBuMzuCOhVRLrOsdULSTUEz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKH4i05Io8UQ/2dsb2JhbABCqA+BBYFTAQEBAQIBEgF2CxguVwYBNIdbmR0BngiGQmEEk2eFJwmMFg X-IronPort-AV: E=Sophos;i="4.68,490,1312156800"; d="scan'208";a="57117333" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 05 Oct 2011 06:31:00 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p956UxEU028001; Wed, 5 Oct 2011 06:31:00 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 14:30:59 +0800 Received: from [10.60.114.231] ([10.60.114.231]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 14:30:59 +0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1244.3) Subject: Re: [homenet] Question for you // Do we need three routing protocol ? From: JP Vasseur In-Reply-To: Date: Wed, 5 Oct 2011 08:30:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> To: Lorenzo Colitti , Randy Turner , Qiong , "Pascal Thubert (pthubert)" , C Chauvenet , MANET IETF , Mark Townsley , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org, Fred Baker X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 05 Oct 2011 06:30:59.0257 (UTC) FILETIME=[58700A90:01CC8328] X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 06:28:01 -0000 Sharing some thoughts =85 as already pointed on this list, we will more = likely need two routing protocols, one of constraint objects (e.g. sensors, actuators, ..), one for the = other devices, this is perfectly fine (and we know that some devices will not need routing at all, fine too). With = regards to Smart objects, since the IETF has already specified a routing protocol (RPL in the ROLL WG), do = we now want to "Tweak"/"change" /Add yet a third one (a simplified LS or routing protocol such as OLSR) = ? Since it was mentioned that we=20 should select a well established and stabilized routing protocol, it is = worth pointing out that although RPL=20 is fairly new, in the world of smart objects, this is the protocol that = will rapidly get the largest adoption and experience in the field, see the number of alliances that adopted it = (Zigbee/IP, Wave2M, =85)=20 On Oct 4, 2011, at 3:50 PM, Fred Baker wrote: >=20 > On Oct 4, 2011, at 12:50 AM, Lorenzo Colitti wrote: >=20 >> For example, if there were a robust open-source version of IS-IS that = didn't take up too much RAM and flash, you could define TLVs to = implement zeroconf and you could get to something that works relatively = quickly. >=20 > RFC 1453 specified a default OSPF configuration that my (ACC) Router = came up with by default. The only configuration necessary was to supply = IPv4 prefixes/addresses to the interfaces and to turn OSPF on. In the = context of a home, I suspect it would be pretty close. Fundamentals: = default values for most attributes are as specified in the OSPF RFC, the = metric is the duration of a bit in 10 ns units (which in LAN networks = becomes a hop count), and all interfaces are in area zero. Change things = to your heart's content, but the default configuration is one that = actually works for most purposes in a small network. I'll entertain = arguments that this doesn't address every possible configuration, but = for the networks we're discussing, I'll argue that its "close enough". From pthubert@cisco.com Tue Oct 4 23:43:14 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8D421F8B35; Tue, 4 Oct 2011 23:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.288 X-Spam-Level: X-Spam-Status: No, score=-10.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcLir3Ess4sh; Tue, 4 Oct 2011 23:43:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBFF21F8B33; Tue, 4 Oct 2011 23:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2312; q=dns/txt; s=iport; t=1317797181; x=1319006781; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=rp5JBIbZkMpgn4dIN/4TB50PLlgaGmztjF4IgLtSKlI=; b=cp4KX/mRW7D1WZgf3Thm41vA/m0dlpuwGOr9T2qHtetvxzTCOfuE07Tw /+GvrTZoLc5+CDrlYJ79ZFEmn5xdnFi7ud9xrw8vQqFuSvNwyiTfHEaE1 kaDNastDfjVk7NmUx0CHdB0VKL5qcHU0WVtfPHNRXijOUA6n9jyur4eaw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANz8i06Q/khM/2dsb2JhbABChG2iK3eBBYFTAQEBAQIBEgEQDQRFBQsCAQgODAIGBhgCAgIBAVUBAQQBGhMHh1uZPgGMQZFHgS2EYzJhBJkXjBY X-IronPort-AV: E=Sophos;i="4.68,490,1312156800"; d="scan'208";a="118297957" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 05 Oct 2011 06:46:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p956kJoU019614; Wed, 5 Oct 2011 06:46:19 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 08:46:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [homenet] [manet] Question for you Date: Wed, 5 Oct 2011 08:46:17 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] [manet] Question for you Thread-Index: AcyCr3QOWtZIKFJKQVy/sD0bkANUyAAdxFIw References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com><1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net><47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com><48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com><3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li><2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li><4E8A03A5.5080601@raszuk.net><12856.1317691669@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Chris Elliott" , "Michael Richardson" X-OriginalArrivalTime: 05 Oct 2011 06:46:19.0063 (UTC) FILETIME=[7CAF4C70:01CC832A] Cc: homenet@ietf.org, MANET IETF , robert@raszuk.net, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 06:43:14 -0000 Q2hyaXM7DQoNCj4gQnJpZGdpbmcgd29ya3MgZmluZSBiZXR3ZWVuIDgwMi4xMSBhbmQgODAyLjEt LW9yIGFub3RoZXIgODAyLjExIGxpbmsuIE5vIHJvdXRpbmcgcmVxdWlyZWQuDQo+IEl0IHdvcmtz IGZvciB0aGUgSUVURiBtZWV0aW5nIG5ldHdvcmtzIGFuZCBwcmV0dHkgbXVjaCBob3cgYWxsIEVu dGVycHJpc2UgZ2VhciBpcyBzZXR1cC4NCj4gTGV0J3Mga2VlcCBpdCBzaW1wbGUgYW5kIG9ubHkg cm91dGUgd2hlbiB3ZSBoYXZlIHRvLg0KDQpDZXJ0YWlubHksIGJ1dCB0aGF0J3Mgbm90IHRoZSBw b2ludC4gQXMgbG9uZyBhcyB5b3UgaGF2ZSBhIG5hdGl2ZWx5IGxvb3BsZXNzIHRvcG9sb2d5LCBm b3Igd2hpY2ggYSBXaUZpIEVTUyBpcyBhIHNpbXBsZSBleGFtcGxlLCB5b3UgY2FuIGJyaWRnZSBh bmQgcHJveHkvcmVsYXkvcmVwZWF0IGFsbCB5b3Ugd2FudC4gWW91J2xsIG5vdGUgdGhhdCB0aGUg RVNTIG1vZGVsIGlzIHJlcHJvZHVjZWQgYXQgTDMgd2hlbiB0aGUgNkxvV1BBTiBiYWNrYm9uZSBy b3V0ZXIgcHJveGllcyBORCBmcm9tIGEgYmFja2JvbmUgbGluayBvbnRvIGEgTExOLg0KDQpUaGUg cHJvYmxlbSBpcyB0aGF0IHNvb24gZW5vdWdoIHlvdSdsbCBuZWVkIG1vcmUgdGhhbiAxIHJlbGF5 IEFQIGJldHdlZW4gdGhlIHBvb2wgYW5kIHRoZSBsb3VuZ2UuIFlvdSdsbCBuZWVkIGl0IHRvIGlt cHJvdmUgdGhyb3VnaHB1dCB0aHJvdWdoIHNwYXRpYWwgZGl2ZXJzaXR5LiBZb3UnbGwgbmVlZCBp dCBzbyBzYXZlIHBvd2VyIGFuZCByZWR1Y2UgaW50ZXJmZXJlbmNlcy4gWW91J2xsIG5lZWQgaXQg dG8gaW1wcm92ZSB5b3VyIGRlbGl2ZXJ5IHJhdGlvcy4NCg0KQXMgc29vbiBhcyB5b3UgaGF2ZSBt b3JlIHRoYW4gb25lIHJlbGF5IGFuZCB0aGUgY29ubmVjdGl2aXR5IGlzIHdoYXRldmVyIG1lc2hp bmcgb2YgbGlua3MsIGxvb3BzIGNhbiBmb3JtIGFuZCB5b3UgbmVlZCByb3V0aW5nLiBUaGlzIGlz IHdoeSB3ZSBjYW1lIHVwIHdpdGggc3Bhbm5pbmcgdHJlZSBhbmQgaXRzIGV2b2x1dGlvbnMgaW4g TDIgc3dpdGNoIG5ldHdvcmtzLiBBbmQgYWxsIHNvcnRzIG9mIEwyIG1lc2ggdGVjaG5vbG9naWVz IGluIHdpcmVsZXNzLCBzdGlsbCBMMiBzcGVjaWZpYyBhbmQgcHJvcHJpZXRhcnkgd2hlcmV2ZXIg eW91IGxvb2sgYXQuIFRoZW4gYWdhaW4sIHRoZSBJRVRGIGFkZHJlc3NlZCB0aGUgcHJvYmxlbSBh dCBMMywgYW5kIGNhbWUgdXAgd2l0aCB0aGUgUlBMIHByb3RvY29sIHRoYXQgZHJhd3Mgb25lIChv ciBtb3JlKSBsb29wbGVzcyB0b3BvbG9neShpZXMpIHVwb24gYW4gYXJiaXRyYXJ5IG1lc2ggdG8g cmVhY2ggdGhlIGdhdGV3YXlzLg0KDQpXZSBjYW4gZ28gKGFnYWluKSB0aHJvdWdoIGxlbmd0aHkg ZGlzY3Vzc2lvbnMgYnV0IGluIHNob3J0IEkgYWdyZWUgd2l0aCBvdGhlciB2b2ljZXMgKFJ1c3Mp IHRoYXQgaW5kaWNhdGUgdGhhdCB3ZSBuZWVkIGEgTDMgcm91dGluZyBzb2x1dGlvbi4gSSBhbHNv IGZ1bGx5IGFncmVlIHdpdGggdGhlIHZvaWNlcyAoUm9iZXJ0KSB0aGF0IGluZGljYXRlZCB0aGF0 IHRoZSBiYWNrYm9uZSBkaXN0cmlidXRpb24gbmV0d29yayBhbmQgdGhlIG1lc2hlZCBmcmluZ2Ug YXQgdGhlIGVkZ2UgYXJlIGRpZmZlcmVudCBiZXN0cyBhbmQgbWlnaHQgbmVlZCBkaWZmZXJlbnQg dHJlYXRtZW50cy4NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg== From pthubert@cisco.com Wed Oct 5 00:14:22 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4622421F8B3F; Wed, 5 Oct 2011 00:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.293 X-Spam-Level: X-Spam-Status: No, score=-10.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jedz5fe-yeli; Wed, 5 Oct 2011 00:14:21 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A383021F8B0F; Wed, 5 Oct 2011 00:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2463; q=dns/txt; s=iport; t=1317799046; x=1319008646; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=yZRnH6gd8WCvrB92aaKukWZaXpcxFBmS1BMpV1iB2bA=; b=TmFuWaXu6ATFi7IPq3JrKCZpvrdgyWjxUTtmNOd/oFm3ZO1CYvjP5lUw AI0PBBMuJ22WhGsI5DVx7L0cp807RMLFvwOW4FajDDzdpMAnz6r/RODZR sbgbW56zD585ELAActpeoEsvLQNg8TTvhb0oUemGhO7k93G4S6uOcKR/z A=; X-IronPort-AV: E=Sophos;i="4.68,490,1312156800"; d="scan'208";a="118301009" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 05 Oct 2011 07:17:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p957HJIi026029; Wed, 5 Oct 2011 07:17:19 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 09:17:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [homenet] [manet] Question for you Date: Wed, 5 Oct 2011 09:17:18 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] [manet] Question for you Thread-Index: AcyCE6NqLjYtBFYkSiamqT4FTMaEnwBGn70Q References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com><1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net><47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com><48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com><4E89FEB6.3040904@freedesktop.org><61E0CF30-12F1-4218-90AD-102A635775E6@tony.li><4E8A08A1.7000106@freedesktop.org><64AA82AA-80B9-43AD-8F2B-9DC2F866887A@tony.li><4E8A10D2.1030105@freedesktop.org> From: "Pascal Thubert (pthubert)" To: "Ulrich Herberg" , "Jim Gettys" X-OriginalArrivalTime: 05 Oct 2011 07:17:19.0505 (UTC) FILETIME=[D1983810:01CC832E] Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , homenet@ietf.org, rtgwg@ietf.org, Lorenzo Colitti X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 07:14:22 -0000 Interestingly,=20 Those deployments are not limited to intra-home but include = between-homes, as I indicated earlier, for content and access sharing. Is that scenario in scope for this group? Pascal -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On = Behalf Of Ulrich Herberg Sent: lundi 3 octobre 2011 22:03 To: Jim Gettys Cc: C Chauvenet; MANET IETF; Mark Townsley; JP Vasseur; Qiong; Acee = Lindem; Tony Li; homenet@ietf.org; Lorenzo Colitti; rtgwg@ietf.org Subject: Re: [homenet] [manet] Question for you I agree with Jim. The reason why we developed OLSR and the its successor = OLSRv2 was precisely that wireless environments are very different from = wired. There are plenty of deployments of OLSR and several of OLSRv2, = with up to several hundreds of wireless routers, so it is demonstrably = working. Regards Ulrich On Mon, Oct 3, 2011 at 12:45 PM, Jim Gettys wrote: > > On 10/03/2011 03:32 PM, Tony Li wrote: > > On Oct 3, 2011, at 12:10 PM, Jim Gettys wrote: > > > >> My point was just that wireless has a set of challenges that all=20 > >> may not be familiar with; knowing that may help point the=20 > >> discussion in fruitful ways. =A0Routing isn't my area of expertise=20 > >> (though I have scars on my back from it in wireless...). > > > > Understood. > > > > Yes, wireless has some challenges and I've spent some time in that = area. =A0Certainly our standard protocols are not optimal for a purely = wireless environment. > > > > However, for the generic, heterogenous networks that I would expect = in the home, I would expect that the generic protocols would be the = better overall approach. > > Having been seriously scarred by presuming that wireless was similar=20 > to wired, I'm a believer in careful testing, rather than "expecting"=20 > that something should work. =A0Without "running code", demonstrably=20 > working, I'll take nothing on faith in this area. > > Wireless !=3D wired, is what I took away from that (painful) = experience. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Jim > > > > > Tony > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From touch@isi.edu Wed Oct 5 08:22:10 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6BD21F8A6C; Wed, 5 Oct 2011 08:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKQp4kiIQRCW; Wed, 5 Oct 2011 08:22:09 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id EEB0521F8A58; Wed, 5 Oct 2011 08:22:00 -0700 (PDT) Received: from [192.168.1.94] (pool-71-105-93-161.lsanca.dsl-w.verizon.net [71.105.93.161]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p95FOVRb013892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 5 Oct 2011 08:24:34 -0700 (PDT) Subject: Re: [homenet] [manet] Question for you Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <1C39033D-FBB9-4CAF-8C8C-E21AB4A1E9CE@cisco.com> Date: Wed, 5 Oct 2011 08:24:31 -0700 Content-Transfer-Encoding: 7bit Message-Id: <5D15F60D-1922-49CD-9B3C-469FC23B663B@isi.edu> References: <1C39033D-FBB9-4CAF-8C8C-E21AB4A1E9CE@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1244.3) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Wed, 05 Oct 2011 08:40:12 -0700 Cc: Don Sturek , C Chauvenet , MANET IETF , Mark Townsley , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 15:22:10 -0000 -1 The charter already allows for interface to external groups: --- The working group will also liason with external standards bodies where it is expected that there are normative dependencies between the specifications of the two bodies. --- I.e., this can be handled via liaisons (better, IMO). Joe On Oct 1, 2011, at 5:20 PM, Fred Baker wrote: > > On Oct 1, 2011, at 10:38 PM, Don Sturek wrote: > >> To add one more point to Fred's note: I think it is important to get a >> commercial group like Wi-Fi to participate in Homenet, adopt some or all >> of the drafts/RFCs then sponsor interoperability testing. > > That would be very interesting. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From fred@cisco.com Thu Oct 6 07:57:45 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B0B21F8B5C; Thu, 6 Oct 2011 07:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.397 X-Spam-Level: X-Spam-Status: No, score=-104.397 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsSdsfvHo2mA; Thu, 6 Oct 2011 07:57:45 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 406C921F8801; Thu, 6 Oct 2011 07:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1066; q=dns/txt; s=iport; t=1317913256; x=1319122856; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=RCKuhW2BLF/c0qBYEREJOZboPMw/rGD4YLTmLEc/QcY=; b=l8wFHk1GO9Li/DQZMwhoZZ2QIzC4AkdGeXq2NqEHzADnVJnkmp0QZHEX ydj1DMSLi+1VOLTCQXzKNOV/ypEZnJ9RuTE84KAqVLiw5o1r0wDhcZRDC 8Y5DqQsB/7tHR8W8YwWefeQdFNeni/abR0UPvyEZxVX5Iw/d+N9sKx3jX A=; X-IronPort-AV: E=Sophos;i="4.68,496,1312156800"; d="scan'208";a="26512271" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 06 Oct 2011 15:00:56 +0000 Received: from Freds-Computer.local (rtp-vpn4-1292.cisco.com [10.82.213.12]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p96F04Gn000863; Thu, 6 Oct 2011 15:00:55 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 06 Oct 2011 11:00:57 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 06 Oct 2011 11:00:57 -0400 Subject: Re: [homenet] [manet] Question for you Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <5D15F60D-1922-49CD-9B3C-469FC23B663B@isi.edu> Date: Thu, 6 Oct 2011 11:00:56 -0400 Message-Id: <96082B87-D6F6-4DCF-AEA6-789C99D5A720@cisco.com> References: <1C39033D-FBB9-4CAF-8C8C-E21AB4A1E9CE@cisco.com> <5D15F60D-1922-49CD-9B3C-469FC23B663B@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Don Sturek , C Chauvenet , MANET IETF , Mark Townsley , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 14:57:46 -0000 Not sure that's the same thing. WiFi is an industry organization, not an = SDO. Yes, we could send them a letter. On Oct 5, 2011, at 11:24 AM, Joe Touch wrote: > -1 >=20 > The charter already allows for interface to external groups: >=20 > --- > The working group will also liason with external > standards bodies where it is expected that there are normative > dependencies between the specifications of the two bodies. > --- >=20 > I.e., this can be handled via liaisons (better, IMO). >=20 > Joe >=20 >=20 > On Oct 1, 2011, at 5:20 PM, Fred Baker wrote: >>=20 >> On Oct 1, 2011, at 10:38 PM, Don Sturek wrote: >>=20 >>> To add one more point to Fred's note: I think it is important to = get a >>> commercial group like Wi-Fi to participate in Homenet, adopt some or = all >>> of the drafts/RFCs then sponsor interoperability testing. >>=20 >> That would be very interesting. >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 From curtis@occnc.com Thu Oct 6 11:37:50 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9059A21F87D6; Thu, 6 Oct 2011 11:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=2.019, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynXznUs1Gs7w; Thu, 6 Oct 2011 11:37:50 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id DBCE121F87D3; Thu, 6 Oct 2011 11:37:49 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p96IepoB039229; Thu, 6 Oct 2011 11:40:51 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p96IepoB039229 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1317926453; bh=ztJLFxO+Wff6PdKkJ84UqALjaimFABIuMikd+y/slKU=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=B7t1VOzD7eW/G+dox6R4BtmqeGTVb/u+F+CbecToAZXwtc0X92YEhJp9TCAGXv9ya h2VliTuPkECBeZIjwt+jnjMsbG/wcspNw0PF6OQCD6wg9jcQ7VHvFM2bC7oJgODmtM uX8sMWE1hJP7jmFd8zlh0YWsT4OpZ27NhS6Qhfc4= Message-Id: <201110061840.p96IepoB039229@gateway.ipv6.occnc.com> To: Fred Baker From: Curtis Villamizar Subject: liasons and cross posting (was Re: Question for you) In-reply-to: Your message of "Thu, 06 Oct 2011 11:00:56 EDT." <96082B87-D6F6-4DCF-AEA6-789C99D5A720@cisco.com> Date: Thu, 06 Oct 2011 11:40:51 -0700 Cc: Don Sturek , Joe Touch , C Chauvenet , MANET IETF , Mark Townsley , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 18:37:50 -0000 In message <96082B87-D6F6-4DCF-AEA6-789C99D5A720@cisco.com> Fred Baker writes: > Not sure that's the same thing. WiFi is an industry organization, not > an SDO. Yes, we could send them a letter. IEEE would be the relevant standards organization, if we had any relevant input into what is done at layer-2. IEEE usually sticks to layer-2 and IETF to layer-3 and up (layer-2.5 if that is what you want to call MPLS). We would contact WiFi if we had as idea for logo artwork for an IETF homenet/manet/roll/rtgwg blessed profile. This is not typically what IETF does. IMHO - neither is a good candidate for a liason relationship. btw - this message is cross posted to three lists: homenet, manet, rtgwg. I suggest we drop the cc to homenet only and anyone on rtgwg and manet can join homenet and continue the discussion. In Fred's defense, when he started this thread he asked that responses be sent to him only and not to the lists. [I'm not subscribed to manet, so this email may not get there.] Curtis > On Oct 5, 2011, at 11:24 AM, Joe Touch wrote: > > > -1 > > > > The charter already allows for interface to external groups: > > > > --- > > The working group will also liason with external > > standards bodies where it is expected that there are normative > > dependencies between the specifications of the two bodies. > > --- > > > > I.e., this can be handled via liaisons (better, IMO). > > > > Joe > > > > > > On Oct 1, 2011, at 5:20 PM, Fred Baker wrote: > >> > >> On Oct 1, 2011, at 10:38 PM, Don Sturek wrote: > >> > >>> To add one more point to Fred's note: I think it is important to get a > >>> commercial group like Wi-Fi to participate in Homenet, adopt some or all > >>> of the drafts/RFCs then sponsor interoperability testing. > >> > >> That would be very interesting. From ulrich@herberg.name Thu Oct 6 11:47:43 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609BA21F8CE6; Thu, 6 Oct 2011 11:47:43 -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.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxvrOF98xfeq; Thu, 6 Oct 2011 11:47:42 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id ACFFE21F8CE0; Thu, 6 Oct 2011 11:47:41 -0700 (PDT) Received: by wyg24 with SMTP id 24so29376wyg.31 for ; Thu, 06 Oct 2011 11:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0QgxndHEZJWYe+jdW7aNlHKlR7gzivxLvtaemBGs+2Q=; b=l8kTPfxqft6L6/nH6APdmnbV0SKkRpsVEp9h96UAj4ITM45CnJClN6RdHp+w4MKTyX K6p6fYiffsr4/x4fE12tRpGj+zG2m+9QVa44swKT52R/8NcnPxXJxtME5X/FrSHO7K8p Qt5+t3MDZu/tix0ebnV74sxBWwPc8saDkWIE4= MIME-Version: 1.0 Received: by 10.227.30.154 with SMTP id u26mr1367816wbc.73.1317927052304; Thu, 06 Oct 2011 11:50:52 -0700 (PDT) Received: by 10.227.7.68 with HTTP; Thu, 6 Oct 2011 11:50:52 -0700 (PDT) In-Reply-To: <201110061840.p96IepoB039229@gateway.ipv6.occnc.com> References: <96082B87-D6F6-4DCF-AEA6-789C99D5A720@cisco.com> <201110061840.p96IepoB039229@gateway.ipv6.occnc.com> Date: Thu, 6 Oct 2011 11:50:52 -0700 Message-ID: Subject: Re: [homenet] liasons and cross posting (was Re: Question for you) From: Ulrich Herberg To: curtis@occnc.com Content-Type: multipart/alternative; boundary=002215974902cae35c04aea5cdc3 Cc: homenet@ietf.org, MANET IETF , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 18:47:43 -0000 --002215974902cae35c04aea5cdc3 Content-Type: text/plain; charset=ISO-8859-1 Hi Curtis, Sorry for my off-topic email: On Thu, Oct 6, 2011 at 11:40 AM, Curtis Villamizar wrote: > [...] > btw - this message is cross posted to three lists: homenet, manet, > rtgwg. I suggest we drop the cc to homenet only and anyone on rtgwg > and manet can join homenet and continue the discussion. > Actually, I would prefer to limit it to one mailing list (e.g. homenet). As many, like you, are not subscribed to MANET, the MANET chairs or I have to accept each reply manually because of the mailing list filters (and currently, there are several emails per day). I have sent an email to the MANET list that the thread is continued on homenet only, so everyone interested in the topic may follow the thread there. Best regards Ulrich > > > On Oct 5, 2011, at 11:24 AM, Joe Touch wrote: > > > > > -1 > > > > > > The charter already allows for interface to external groups: > > > > > > --- > > > The working group will also liason with external > > > standards bodies where it is expected that there are normative > > > dependencies between the specifications of the two bodies. > > > --- > > > > > > I.e., this can be handled via liaisons (better, IMO). > > > > > > Joe > > > > > > > > > On Oct 1, 2011, at 5:20 PM, Fred Baker wrote: > > >> > > >> On Oct 1, 2011, at 10:38 PM, Don Sturek wrote: > > >> > > >>> To add one more point to Fred's note: I think it is important to get > a > > >>> commercial group like Wi-Fi to participate in Homenet, adopt some or > all > > >>> of the drafts/RFCs then sponsor interoperability testing. > > >> > > >> That would be very interesting. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --002215974902cae35c04aea5cdc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Curtis,

Sorry for my off-topic email:

On Thu, Oct 6, 2011 at 11:40 AM, Curtis Villamizar <curtis@occnc.com> wr= ote:
[...]
btw - this message is cross posted to three lists: homenet, manet,
rtgwg. =A0I suggest we drop the cc to homenet only and anyone on rtgwg
and manet can join homenet and continue the discussion.

Actually, I would prefer to limit it to one mailing list (e.g. homene= t). As many, like you, are not subscribed to MANET, the MANET chairs or I h= ave to accept each reply manually because of the mailing list filters (and = currently, there are several emails per day). I have sent an email to the M= ANET list that the thread is continued on homenet only, so everyone interes= ted in the topic may follow the thread there.

Best regards
Ulrich
=A0

> On Oct 5, 2011, at 11:24 AM, Joe Touch wrote:
>
> > -1
> >
> > The charter already allows for interface to external groups:
> >
> > ---
> > The working group will also liason with external
> > standards bodies where it is expected that there are normative > > dependencies between the specifications of the two bodies.
> > ---
> >
> > I.e., this can be handled via liaisons (better, IMO).
> >
> > Joe
> >
> >
> > On Oct 1, 2011, at 5:20 PM, Fred Baker wrote:
> >>
> >> On Oct 1, 2011, at 10:38 PM, Don Sturek wrote:
> >>
> >>> To add one more point to Fred's note: =A0I think it i= s important to get a
> >>> commercial group like Wi-Fi to participate in Homenet, ad= opt some or all
> >>> of the drafts/RFCs then sponsor interoperability testing.=
> >>
> >> That would be very interesting.
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

--002215974902cae35c04aea5cdc3-- From iesg-secretary@ietf.org Fri Oct 7 04:51:29 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E51C21F8B5A; Fri, 7 Oct 2011 04:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmPq81GoyFuU; Fri, 7 Oct 2011 04:51:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBBD21F8AE1; Fri, 7 Oct 2011 04:51:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (LFA applicability in SP networks) to Informational RFC X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111007115129.19122.93928.idtracker@ietfa.amsl.com> Date: Fri, 07 Oct 2011 04:51:29 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 11:51:29 -0000 The IESG has received a request from the Routing Area Working Group WG (rtgwg) to consider the following document: - 'LFA applicability in SP networks' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In this draft, we analyze the applicability of LoopFree Alternates in both core and access parts of Service Provider networks. We provide design guides to favor their applicability where relevant, typically in the access part of the network. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-applicability/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-applicability/ No IPR declarations have been submitted directly on this I-D. From palm@broadcom.com Thu Oct 6 18:57:39 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3356421F8A58; Thu, 6 Oct 2011 18:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=3.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2eMZlQXQpdJ; Thu, 6 Oct 2011 18:57:37 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8392621F85BB; Thu, 6 Oct 2011 18:57:37 -0700 (PDT) Received: from [10.9.200.133] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 06 Oct 2011 19:07:14 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Thu, 6 Oct 2011 19:00:16 -0700 From: "Stephen [kiwin] Palm" To: "'curtis@occnc.com'" Date: Thu, 6 Oct 2011 19:00:40 -0700 Subject: Re: [homenet] liasons and cross posting (was Re: Question for you) Thread-Topic: [homenet] liasons and cross posting (was Re: Question for you) Thread-Index: AcyEV4fZDkVhhX0XRT6UsR1YWzbbiQAPWI4u Message-ID: In-Reply-To: <201110061840.p96IepoB039229@gateway.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 629081585IS16255453-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 07 Oct 2011 07:41:17 -0700 Cc: "'homenet@ietf.org'" , "'manet@ietf.org'" , "Stephen \[kiwin\] Palm" , "'rtgwg@ietf.org'" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 01:57:39 -0000 Wi-Fi Alliance (WFA) is also a standards setting organization in addition t= o its marketing role. Relevent work should be liaised to WFA.=20 I can help arrange a liaision application.=20 Regards, kiwin ------- Stephen [kiwin] Palm Ph.D. W: http://www.kiwin.com Senior Technical Director T: +1-949-926-PALM Broadcom - Broadband Communications Group=20 ----- Original Message ----- From: Curtis Villamizar [mailto:curtis@occnc.com] Sent: Thursday, October 06, 2011 11:40 AM=0A= To: Fred Baker Cc: Don Sturek ; Joe Touch ; C Chauvenet <= c.chauvenet@watteco.com>; MANET IETF ; Mark Townsley ; Acee Lindem ; homenet@ietf.org ; rtgwg@ietf.org Subject: [homenet] liasons and cross posting (was Re: Question for you) In message <96082B87-D6F6-4DCF-AEA6-789C99D5A720@cisco.com> Fred Baker writes: =20 > Not sure that's the same thing. WiFi is an industry organization, not > an SDO. Yes, we could send them a letter. IEEE would be the relevant standards organization, if we had any relevant input into what is done at layer-2. IEEE usually sticks to layer-2 and IETF to layer-3 and up (layer-2.5 if that is what you want to call MPLS). We would contact WiFi if we had as idea for logo artwork for an IETF homenet/manet/roll/rtgwg blessed profile. This is not typically what IETF does. IMHO - neither is a good candidate for a liason relationship. btw - this message is cross posted to three lists: homenet, manet, rtgwg. I suggest we drop the cc to homenet only and anyone on rtgwg and manet can join homenet and continue the discussion. In Fred's defense, when he started this thread he asked that responses be sent to him only and not to the lists. [I'm not subscribed to manet, so this email may not get there.] Curtis > On Oct 5, 2011, at 11:24 AM, Joe Touch wrote: > =20 > > -1 > >=20 > > The charter already allows for interface to external groups: > >=20 > > --- > > The working group will also liason with external > > standards bodies where it is expected that there are normative > > dependencies between the specifications of the two bodies. > > --- > >=20 > > I.e., this can be handled via liaisons (better, IMO). > >=20 > > Joe > >=20 > >=20 > > On Oct 1, 2011, at 5:20 PM, Fred Baker wrote: > >>=20 > >> On Oct 1, 2011, at 10:38 PM, Don Sturek wrote: > >>=20 > >>> To add one more point to Fred's note: I think it is important to get= a > >>> commercial group like Wi-Fi to participate in Homenet, adopt some or = all > >>> of the drafts/RFCs then sponsor interoperability testing. > >>=20 > >> That would be very interesting. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From mcr@sandelman.ca Fri Oct 7 17:17:23 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394AA21F87FC; Fri, 7 Oct 2011 17:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.46 X-Spam-Level: X-Spam-Status: No, score=0.46 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpeQ2xSKn1cD; Fri, 7 Oct 2011 17:17:22 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 592BC21F87C9; Fri, 7 Oct 2011 17:17:21 -0700 (PDT) Received: from marajade.sandelman.ca (173-101-76-84.pools.spcsdns.net [173.101.76.84]) by relay.sandelman.ca (Postfix) with ESMTPS id 76986343A4; Fri, 7 Oct 2011 20:19:30 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 96E4598CB4; Fri, 7 Oct 2011 18:44:13 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 921F398CB3; Fri, 7 Oct 2011 18:44:13 -0400 (EDT) From: Michael Richardson To: Rex Buddenberg Subject: Re: [homenet] [manet] Question for you In-Reply-To: <1317232463.2243.406.camel@localhost.localdomain> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <1317232463.2243.406.camel@localhost.localdomain> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 07 Oct 2011 18:44:13 -0400 Message-ID: <12459.1318027453@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Sat, 08 Oct 2011 09:15:51 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , homenet@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 00:17:23 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Rex" =3D=3D Rex Buddenberg writes: Rex> Scenario for orientation. Instead of the EMT in the ambulance Rex> having a cellphone to call the emergency room, the EMT will be Rex> armed with several diagnostic gadgets attached to a LAN (either Rex> ethernet or WiFi). And a router. The router will, in turn be Rex> linked to the rest of internet with a radio-WAN. Rex> Scenario implications. Right now, emergency services tend to Rex> rely on a set of high sites -- Monterey County where I live, Rex> has eleven. But the broadband technologies all look better Rex> with an order of magnitude more sites (think schoolhouse roofs) Rex> and consequently more handoffs (aka routing table volatility). Great, but unless you are saying that the EMT is going to use my home network to get more bits through, I don't think this is at all in scope. The EMT have the organization and manpower and mandate to have a managed network. The home network has no manpower, and is seldom organized. (The more geekier the network, the less organized :-)) =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATo+AvYCLcPvd0N1lAQKDxgf/S4/yiS0mpPJ0KoqyJJNiNVlUgU1G16YT r/8thGM0vZwOsL/MRwHbnoQORpQwUyQ0f4XtnKGl4i6y7U8yk3b8rA4np4RqNcQh MyBC+W3zmhwNQq6uFlu8fy6Yql8Gvz1opDmCBzGDtXSGQ6cA8nBaaMteSLX4f9wX baEi0VOXzxFI+V5vBx3Pji6iNj18TiZQ1+10s1/ZPKxbuRDf/fVyzz5BVXDy6yGS QpMH6VE/AGz+M63+s6uX8/sx3seT3WWtXG8+Vk6GZ946Qa5R4Ro7upe7226BMHqh 4ofMyjJFdYe+e0K/HuF6C36aUwXmDSs9WVqCN6qs+K9CYqadfg6GUQ== =EQd1 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Sun Oct 9 10:43:11 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB3721F867F; Sun, 9 Oct 2011 10:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.355 X-Spam-Level: X-Spam-Status: No, score=0.355 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1Tia8vNhmMw; Sun, 9 Oct 2011 10:43:08 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id EADA621F8672; Sun, 9 Oct 2011 10:43:07 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id A31B2343B0; Sun, 9 Oct 2011 13:42:03 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 7EBAD98CAD; Sun, 9 Oct 2011 13:43:55 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 7B50C98C90; Sun, 9 Oct 2011 13:43:55 -0400 (EDT) From: Michael Richardson To: Chris Elliott , "homenet@ietf.org" Subject: Re: [homenet] [manet] Question for you In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <4E8A03A5.5080601@raszuk.net> <12856.1317691669@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Sun, 09 Oct 2011 13:43:55 -0400 Message-ID: <13281.1318182235@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Sun, 09 Oct 2011 14:32:24 -0700 Cc: MANET IETF , "robert@raszuk.net" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 17:43:11 -0000 >>>>> "Chris" == Chris Elliott writes: Robert> Why a wireless access point at the pool has to also be a Robert> router ? Isn't it sufficient to extend one or more layer 2 Robert> to it ? >> It's not much of an access point if it doesn't have a second >> interface, is it? If it's out at the pool, and it has no wired >> layer2, then it might well have a second radio (or a second >> ESSID), to relay. But, it might also be connected to the wired >> network in the pool house. Chris> Bridging works fine between 802.11 and 802.1--or another Chris> 802.11 link. No routing required. Chris> It works for the IETF meeting networks and pretty much how Chris> all Enterprise gear is setup. Chris, I've helped out at the IETF NOC a number of years ago. I know lots about the things you do to make the IETF network just work, mostly when I encounter other networks/conferences where things rarely work. Do you think that the average home user knows how to turn off multicast, or even why they should? And, once they do that, do they know why their service discovery protocols now fail? Jim Gettys has repeated many times that multicast on wireless occurs at much lower data rates (1Mb/s on links that otherwise do 100Mb/s). Others have said that some access points turn multicast into unicast frames, but I've not experienced this. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Sun Oct 9 10:45:27 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8B221F8495; Sun, 9 Oct 2011 10:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.463 X-Spam-Level: X-Spam-Status: No, score=0.463 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncLmxV5hkShw; Sun, 9 Oct 2011 10:45:26 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id BF22821F8491; Sun, 9 Oct 2011 10:45:26 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 199E0343B2; Sun, 9 Oct 2011 13:44:23 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 07C6498CAD; Sun, 9 Oct 2011 13:46:14 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id EA26C98C90; Sun, 9 Oct 2011 13:46:14 -0400 (EDT) From: Michael Richardson To: chelliot@pobox.com Subject: Re: [homenet] [manet] Question for you In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <4E8A03A5.5080601@raszuk.net> <12856.1317691669@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Sun, 09 Oct 2011 13:46:14 -0400 Message-ID: <13605.1318182374@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Sun, 09 Oct 2011 14:32:24 -0700 Cc: "Manfredi, Albert E" , "homenet@ietf.org" , MANET IETF , "robert@raszuk.net" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 17:45:27 -0000 >>>>> "Chris" == Chris Elliott writes: Chris> Often you can buy an access point or a wireless router. Many Chris> wireless routers have several switched Ethernet ports and a Chris> single "WAN" Ethernet port. Just don't use the "WAN" port and Chris> you're bridged. And some wireless routers (the Apple Airport yes, and now you have two DHCP servers. IPv4 gives us no clues that we should turn off one of them. From cfilsfil@cisco.com Tue Oct 11 09:08:51 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3DB21F8E89 for ; Tue, 11 Oct 2011 09:08:51 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E9BgYOn1lJD for ; Tue, 11 Oct 2011 09:08:50 -0700 (PDT) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id D1B0D21F8E7B for ; Tue, 11 Oct 2011 09:08:50 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from bonfire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9BG8mhs019262 for ; Tue, 11 Oct 2011 09:08:49 -0700 (PDT) Received: from [10.55.57.5] (ams-cfilsfil-8914.cisco.com [10.55.57.5]) by bonfire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9BG8dYs025643; Tue, 11 Oct 2011 09:08:40 -0700 (PDT) Message-ID: <4E946A07.80403@cisco.com> Date: Tue, 11 Oct 2011 18:08:39 +0200 From: Clarence Filsfils User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtgwg@ietf.org, "Stewart Bryant (stbryant)" , "So, Ning" , imc.shand@googlemail.com Subject: Remote LFA Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:08:51 -0000 Please find the following submission complementing the LFA technology: http://www.ietf.org/id/draft-shand-remote-lfa-00.txt It drastically extends the coverage of LFA while keeping its simplicity. Cheers, Clarence From wim.henderickx@alcatel-lucent.com Tue Oct 11 09:11:03 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D30221F8E11 for ; Tue, 11 Oct 2011 09:11:03 -0700 (PDT) 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_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgpbaRLvPQVg for ; Tue, 11 Oct 2011 09:11:02 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 63A3A21F85EF for ; Tue, 11 Oct 2011 09:10:54 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9BGAmcf001387 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 11 Oct 2011 18:10:49 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 11 Oct 2011 18:10:48 +0200 From: "Henderickx, Wim (Wim)" To: Clarence Filsfils , "rtgwg@ietf.org" , "Stewart Bryant (stbryant)" , "So, Ning" , "imc.shand@googlemail.com" Date: Tue, 11 Oct 2011 18:10:44 +0200 Subject: RE: Remote LFA Thread-Topic: Remote LFA Thread-Index: AcyIMBVmzorv02cgS964C2Bj5mypmwAADFoA Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D671ADD9B44@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <4E946A07.80403@cisco.com> In-Reply-To: <4E946A07.80403@cisco.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:11:03 -0000 Clarence yes I saw this in the last IETF and i believe this has a lot of va= lue=20 -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of C= larence Filsfils Sent: dinsdag 11 oktober 2011 18:09 To: rtgwg@ietf.org; Stewart Bryant (stbryant); So, Ning; imc.shand@googlema= il.com Subject: Remote LFA Please find the following submission complementing the LFA technology: http://www.ietf.org/id/draft-shand-remote-lfa-00.txt It drastically extends the coverage of LFA while keeping its simplicity. Cheers, Clarence _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From gabor.sandor.enyedi@ericsson.com Tue Oct 11 09:25:10 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5098621F8E1F for ; Tue, 11 Oct 2011 09:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsLOmI87pak0 for ; Tue, 11 Oct 2011 09:25:09 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD0221F8E05 for ; Tue, 11 Oct 2011 09:25:09 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-15-4e946de4caf2 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 51.68.13753.4ED649E4; Tue, 11 Oct 2011 18:25:08 +0200 (CEST) Received: from ESESSCMS0359.eemea.ericsson.se ([153.88.115.176]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 11 Oct 2011 18:25:08 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: Clarence Filsfils , "rtgwg@ietf.org" , "Stewart Bryant (stbryant)" , "So, Ning" , "imc.shand@googlemail.com" Date: Tue, 11 Oct 2011 18:25:06 +0200 Subject: RE: Remote LFA Thread-Topic: Remote LFA Thread-Index: AcyIMBLWjBD2uUgRTgGPsEA5LqSIRAAACi1A Message-ID: References: <4E946A07.80403@cisco.com> In-Reply-To: <4E946A07.80403@cisco.com> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:25:10 -0000 Wow... I will read it as soon as I can, I'm curious what is the difference = between this and http://tools.ietf.org/html/draft-hokelek-rlfap-01 - first = I thought that you're speaking about this one, since the title is very simi= lar. At the last IETF we proposed this http://tools.ietf.org/html/draft-csa= szar-ipfrr-fn-01, but it seemed that everybody was strongly against giving = up local protection (like it was a religious dogma). It's good to see that = I'm not alone anymore! BR, Gabor -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of C= larence Filsfils Sent: Tuesday, October 11, 2011 6:09 PM To: rtgwg@ietf.org; Stewart Bryant (stbryant); So, Ning; imc.shand@googlema= il.com Subject: Remote LFA Please find the following submission complementing the LFA technology: http://www.ietf.org/id/draft-shand-remote-lfa-00.txt It drastically extends the coverage of LFA while keeping its simplicity. Cheers, Clarence _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From cfilsfil@cisco.com Tue Oct 11 09:35:21 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BCE21F8E34 for ; Tue, 11 Oct 2011 09:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cONeb71uCMyY for ; Tue, 11 Oct 2011 09:35:21 -0700 (PDT) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id 077EC21F8E28 for ; Tue, 11 Oct 2011 09:35:21 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from bonfire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9BGZKfw028067 for ; Tue, 11 Oct 2011 09:35:20 -0700 (PDT) Received: from [10.55.57.5] (ams-cfilsfil-8914.cisco.com [10.55.57.5]) by bonfire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9BGZICR021780; Tue, 11 Oct 2011 09:35:18 -0700 (PDT) Message-ID: <4E947045.909@cisco.com> Date: Tue, 11 Oct 2011 18:35:17 +0200 From: Clarence Filsfils User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= Subject: Re: Remote LFA References: <4E946A07.80403@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "imc.shand@googlemail.com" , "Stewart Bryant \(stbryant\)" , "So, Ning" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:35:21 -0000 Gabor, It is independent. See the draft: " 6. Historical Note The basic concepts behind Remote LFA were invented in 2002 and were later included in draft-bryant-ipfrr-tunnels, submitted in 2004. draft-bryant-ipfrr-tunnels targetted a 100% protection coverage and hence included additional mechanims on top of the Remote LFA concept. The addition of these mechanisms made the proposal very complex and computationally intensive and it was therefore not pursued as a working group item. As explained in [I-D.filsfils-rtgwg-lfa-applicability], the purpose of the LFA FRR technology is not to provide coverage at any cost. A solution for this already exists with MPLS TE FRR. MPLS TE FRR is a mature technology which is able to provide protection in any topology thanks to the explicit routing capability of MPLS TE. The purpose of LFA FRR technology is to provide for a simple FRR solution when such a solution is possible. The first step along this simplicity approach was "local" LFA [RFC5286]. We propose "Remote LFA" as a natural second step. The following section motivates its benefits in terms of simplicity, incremental deployment and significant coverage increase. " Cheers, Clarence From sucecj@telcordia.com Tue Oct 11 10:07:44 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFF821F8ED3 for ; Tue, 11 Oct 2011 10:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74hqojjn8DP3 for ; Tue, 11 Oct 2011 10:07:41 -0700 (PDT) Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.23]) by ietfa.amsl.com (Postfix) with ESMTP id AC9C621F8EDA for ; Tue, 11 Oct 2011 10:07:41 -0700 (PDT) Received: from rrc-dte-bms01.telcordia.com (rrc-dte-bms01.cc.telcordia.com [128.96.150.38]) by dnsmx2pya.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id p9BH7aJw024913; Tue, 11 Oct 2011 13:07:36 -0400 (EDT) X-AuditID: 80609626-b7c76ae0000009ec-50-4e9477d6ca3a Received: from pya-dte-exhb1.dte.telcordia.com (pya-dte-exhb1.cc.telcordia.com [128.96.20.11]) by rrc-dte-bms01.telcordia.com (Symantec Brightmail Gateway) with SMTP id ED.FD.02540.6D7749E4; Tue, 11 Oct 2011 13:07:34 -0400 (EDT) Received: from rrc-dte-exmb1.dte.telcordia.com ([128.96.180.10]) by pya-dte-exhb1.dte.telcordia.com ([128.96.20.11]) with mapi; Tue, 11 Oct 2011 13:07:35 -0400 From: "Sucec, John M" To: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= , Clarence Filsfils , "rtgwg@ietf.org" , "Stewart Bryant (stbryant)" , "So, Ning" , "imc.shand@googlemail.com" Date: Tue, 11 Oct 2011 13:07:35 -0400 Subject: RE: Remote LFA Thread-Topic: Remote LFA Thread-Index: AcyIMBLWjBD2uUgRTgGPsEA5LqSIRAAACi1AAAEY6BQ= Message-ID: <563593148DD9A040B93397F642B3C1255999FCB95E@rrc-dte-exmb1.dte.telcordia.com> References: <4E946A07.80403@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 17:07:44 -0000 Gabor, thank you for recalling the http://tools.ietf.org/html/draft-hokelek= -rlfap-01 Internet Draft that Telcordia submitted earlier. All: While that earlier Internet Draft did not gain much traction within th= e Routing Area WG at the time of its submission, we continued to experiment= with its methods and have published some proof-of-concept results. I am glad to see that there is renewed interest in the general topic of exp= anding/formalizing protection against link failures beyond the basic LFA pa= th mechanism (RFC 5286). I will review the latest drafts on LFA technologies and look forward to col= laborating where possible. Thanks. John ________________________________________ From: rtgwg-bounces@ietf.org [rtgwg-bounces@ietf.org] On Behalf Of G=E1bor = S=E1ndor Enyedi [gabor.sandor.enyedi@ericsson.com] Sent: Tuesday, October 11, 2011 12:25 PM To: Clarence Filsfils; rtgwg@ietf.org; Stewart Bryant (stbryant); So, Ning;= imc.shand@googlemail.com Subject: RE: Remote LFA Wow... I will read it as soon as I can, I'm curious what is the difference = between this and http://tools.ietf.org/html/draft-hokelek-rlfap-01 - first = I thought that you're speaking about this one, since the title is very simi= lar. At the last IETF we proposed this http://tools.ietf.org/html/draft-csa= szar-ipfrr-fn-01, but it seemed that everybody was strongly against giving = up local protection (like it was a religious dogma). It's good to see that = I'm not alone anymore! BR, Gabor -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of C= larence Filsfils Sent: Tuesday, October 11, 2011 6:09 PM To: rtgwg@ietf.org; Stewart Bryant (stbryant); So, Ning; imc.shand@googlema= il.com Subject: Remote LFA Please find the following submission complementing the LFA technology: http://www.ietf.org/id/draft-shand-remote-lfa-00.txt It drastically extends the coverage of LFA while keeping its simplicity. Cheers, Clarence _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From sriganeshkini@gmail.com Tue Oct 11 13:21:37 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5999F21F8C0F for ; Tue, 11 Oct 2011 13:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlMMT-2Vum7U for ; Tue, 11 Oct 2011 13:21:36 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAC321F8C09 for ; Tue, 11 Oct 2011 13:21:36 -0700 (PDT) Received: by wyg24 with SMTP id 24so5141314wyg.31 for ; Tue, 11 Oct 2011 13:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=1rGtWDAhjF2LP79ey/fEoq0cPzcOnDM6R5udCfTiazU=; b=rFUboryG0PN+JRqR99by1yFpQsCMbw+mXUOXpDaXRK09NxGIRSHoYBGW1jeI3D5J99 wABocW9fNzwp6bK80UOeo1dunl/OhpBcWk/RRTZZ/Uo3sb6xU5vc/GwammV10OFTF8F+ N/2YCflA+WVA4a2lAa18LeEXrjtOM0z8xgrtw= Received: by 10.216.24.2 with SMTP id w2mr6808682wew.49.1318364492109; Tue, 11 Oct 2011 13:21:32 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.216.187.19 with HTTP; Tue, 11 Oct 2011 13:21:02 -0700 (PDT) In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D671ADD9B44@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <4E946A07.80403@cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671ADD9B44@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> From: Sriganesh Kini Date: Tue, 11 Oct 2011 13:21:02 -0700 X-Google-Sender-Auth: ptYJicSO8DPM9qwFC7DmWfFXPi0 Message-ID: Subject: Re: Remote LFA To: "Henderickx, Wim (Wim)" Content-Type: multipart/alternative; boundary=0016e642db943c977a04af0ba7d7 Cc: "imc.shand@googlemail.com" , "Stewart Bryant \(stbryant\)" , "So, Ning" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 20:21:37 -0000 --0016e642db943c977a04af0ba7d7 Content-Type: text/plain; charset=UTF-8 About related work - At the last IETF we presented draft-kini-mpls-frr-ldp that addresses additional cases where besides using a primary LSP to a remote LSR such that traffic does not loop back, it handles SRLG as well. On Tue, Oct 11, 2011 at 9:10 AM, Henderickx, Wim (Wim) < wim.henderickx@alcatel-lucent.com> wrote: > Clarence yes I saw this in the last IETF and i believe this has a lot of > value > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Clarence Filsfils > Sent: dinsdag 11 oktober 2011 18:09 > To: rtgwg@ietf.org; Stewart Bryant (stbryant); So, Ning; > imc.shand@googlemail.com > Subject: Remote LFA > > Please find the following submission complementing the LFA technology: > > http://www.ietf.org/id/draft-shand-remote-lfa-00.txt > > It drastically extends the coverage of LFA while keeping its simplicity. > > Cheers, > Clarence > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > -- - Sri --0016e642db943c977a04af0ba7d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable About related work -

At the last IETF we presented draft= -kini-mpls-frr-ldp that addresses=C2=A0additional cases where besides using= a primary LSP to a remote LSR such that traffic does not loop back, it han= dles SRLG as well.

On Tue, Oct 11, 2011 at 9:10 AM, Hender= ickx, Wim (Wim) <wim.henderickx@alcatel-lucent.com> wrote:
=
Clarence yes I saw this in the last IETF and i believe this has a lot of va= lue

-----Original Message-----
From: rtgwg-bounces@ietf.org = [mailto:rtgwg-bounces@ietf.org] On Behalf Of Clarence Filsfils
Sent: dinsdag 11 oktober 2011 18:09
To: rtgwg@ietf.org; Stewart Bryant (s= tbryant); So, Ning; imc.shand@g= ooglemail.com
Subject: Remote LFA

Please find the following submission complementing the LFA technology:

http://www.ietf.org/id/draft-shand-remote-lfa-00.txt

It drastically extends the coverage of LFA while keeping its simplicity.
Cheers,
Clarence
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg



--
= - Sri
--0016e642db943c977a04af0ba7d7-- From wim.henderickx@alcatel-lucent.com Tue Oct 11 22:30:54 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF8C21F8AFE for ; Tue, 11 Oct 2011 22:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhEIy4Vtqc7J for ; Tue, 11 Oct 2011 22:30:53 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5378E21F8A56 for ; Tue, 11 Oct 2011 22:30:52 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9C5UkvV021244 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 Oct 2011 07:30:46 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 12 Oct 2011 07:30:46 +0200 From: "Henderickx, Wim (Wim)" To: Sriganesh Kini Date: Wed, 12 Oct 2011 07:30:44 +0200 Subject: RE: Remote LFA Thread-Topic: Remote LFA Thread-Index: AcyIU2GOdYvxL8FWQvyAgk4Sr2aIogATFrmg Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D671ADD9BC8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <4E946A07.80403@cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671ADD9B44@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: multipart/alternative; boundary="_000_14C7F4F06DB5814AB0DE29716C4F6D671ADD9BC8FRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "imc.shand@googlemail.com" , "Stewart Bryant \(stbryant\)" , "So, Ning" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 05:30:54 -0000 --_000_14C7F4F06DB5814AB0DE29716C4F6D671ADD9BC8FRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdGlsbCBiZWxpZXZlIHJlbW90ZSBMRkEgaGFzIG1vcmUgbWVyaXRzIGZvciB0aGUgc2Vydmlj ZSBwcm92aWRlcnMgd2hvIGRlcGxveSBMRkEgYW5kIHdhbnQgdG8gaW5jcmVhc2UgdGhlIGNvdmVy YWdlLiBJdCBpcyBub3QgYWJvdXQgU1JMRyBvciBub3QuIEl0IGlzIGFib3V0IGNvdmVyYWdlIGFu ZCByZW1vdGUgTEZBIGhhcyB0aGUgYmVuZWZpdHMgdGhhdCBpcyByZS11c2VzIG9wZXJhdGlvbmFs IHByb2NlZHVyZXMgd2hpY2ggYXJlIGluIHBsYWNlIGluIHNlcnZpY2UgcHJvdmlkZXJzIG5ldHdv cmtzIHRvZGF5LiBTbyBleHRlbmRpbmcgdGhlbSBpcyBiZXR0ZXIgdGhhbiBpbnRyb2R1Y2luZyBh IGNvbXBsZXRlIG5ldyBzY2hlbWUuDQoNCkZyb206IHNyaWdhbmVzaGtpbmlAZ21haWwuY29tIFtt YWlsdG86c3JpZ2FuZXNoa2luaUBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBTcmlnYW5lc2ggS2lu aQ0KU2VudDogZGluc2RhZyAxMSBva3RvYmVyIDIwMTEgMjI6MjENClRvOiBIZW5kZXJpY2t4LCBX aW0gKFdpbSkNCkNjOiBDbGFyZW5jZSBGaWxzZmlsczsgcnRnd2dAaWV0Zi5vcmc7IFN0ZXdhcnQg QnJ5YW50IChzdGJyeWFudCk7IFNvLCBOaW5nOyBpbWMuc2hhbmRAZ29vZ2xlbWFpbC5jb20NClN1 YmplY3Q6IFJlOiBSZW1vdGUgTEZBDQoNCkFib3V0IHJlbGF0ZWQgd29yayAtDQoNCkF0IHRoZSBs YXN0IElFVEYgd2UgcHJlc2VudGVkIGRyYWZ0LWtpbmktbXBscy1mcnItbGRwIHRoYXQgYWRkcmVz c2VzIGFkZGl0aW9uYWwgY2FzZXMgd2hlcmUgYmVzaWRlcyB1c2luZyBhIHByaW1hcnkgTFNQIHRv IGEgcmVtb3RlIExTUiBzdWNoIHRoYXQgdHJhZmZpYyBkb2VzIG5vdCBsb29wIGJhY2ssIGl0IGhh bmRsZXMgU1JMRyBhcyB3ZWxsLg0KDQpPbiBUdWUsIE9jdCAxMSwgMjAxMSBhdCA5OjEwIEFNLCBI ZW5kZXJpY2t4LCBXaW0gKFdpbSkgPHdpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbTxt YWlsdG86d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tPj4gd3JvdGU6DQpDbGFyZW5j ZSB5ZXMgSSBzYXcgdGhpcyBpbiB0aGUgbGFzdCBJRVRGIGFuZCBpIGJlbGlldmUgdGhpcyBoYXMg YSBsb3Qgb2YgdmFsdWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Z3dn LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86 cnRnd2ctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZz5dIE9u IEJlaGFsZiBPZiBDbGFyZW5jZSBGaWxzZmlscw0KU2VudDogZGluc2RhZyAxMSBva3RvYmVyIDIw MTEgMTg6MDkNClRvOiBydGd3Z0BpZXRmLm9yZzxtYWlsdG86cnRnd2dAaWV0Zi5vcmc+OyBTdGV3 YXJ0IEJyeWFudCAoc3RicnlhbnQpOyBTbywgTmluZzsgaW1jLnNoYW5kQGdvb2dsZW1haWwuY29t PG1haWx0bzppbWMuc2hhbmRAZ29vZ2xlbWFpbC5jb20+DQpTdWJqZWN0OiBSZW1vdGUgTEZBDQoN ClBsZWFzZSBmaW5kIHRoZSBmb2xsb3dpbmcgc3VibWlzc2lvbiBjb21wbGVtZW50aW5nIHRoZSBM RkEgdGVjaG5vbG9neToNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1zaGFuZC1yZW1v dGUtbGZhLTAwLnR4dA0KDQpJdCBkcmFzdGljYWxseSBleHRlbmRzIHRoZSBjb3ZlcmFnZSBvZiBM RkEgd2hpbGUga2VlcGluZyBpdHMgc2ltcGxpY2l0eS4NCg0KQ2hlZXJzLA0KQ2xhcmVuY2UNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGd3ZyBtYWls aW5nIGxpc3QNCnJ0Z3dnQGlldGYub3JnPG1haWx0bzpydGd3Z0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2cNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGd3ZyBtYWlsaW5nIGxpc3QNCnJ0Z3dnQGll dGYub3JnPG1haWx0bzpydGd3Z0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRnd2cNCg0KDQoNCi0tDQotIFNyaQ0K --_000_14C7F4F06DB5814AB0DE29716C4F6D671ADD9BC8FRMRSSXCHMBSB1d_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1i bHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIHN0aWxsIGJlbGlldmUgcmVtb3RlIExGQSBoYXMg bW9yZSBtZXJpdHMgZm9yIHRoZSBzZXJ2aWNlIHByb3ZpZGVycyB3aG8gZGVwbG95IExGQSBhbmQg d2FudCB0byBpbmNyZWFzZSB0aGUgY292ZXJhZ2UuIEl0IGlzIG5vdCBhYm91dCBTUkxHIG9yIG5v dC4gSXQgaXMgYWJvdXQgY292ZXJhZ2UgYW5kIHJlbW90ZSBMRkEgaGFzIHRoZSBiZW5lZml0cyB0 aGF0IGlzIHJlLXVzZXMgb3BlcmF0aW9uYWwgcHJvY2VkdXJlcyB3aGljaCBhcmUgaW4gcGxhY2Ug aW4gc2VydmljZSBwcm92aWRlcnMgbmV0d29ya3MgdG9kYXkuIFNvIGV4dGVuZGluZyB0aGVtIGlz IGJldHRlciB0aGFuIGludHJvZHVjaW5nIGEgY29tcGxldGUgbmV3IHNjaGVtZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFz cz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gc3JpZ2FuZXNo a2luaUBnbWFpbC5jb20gW21haWx0bzpzcmlnYW5lc2hraW5pQGdtYWlsLmNvbV0gPGI+T24gQmVo YWxmIE9mIDwvYj5TcmlnYW5lc2ggS2luaTxicj48Yj5TZW50OjwvYj4gZGluc2RhZyAxMSBva3Rv YmVyIDIwMTEgMjI6MjE8YnI+PGI+VG86PC9iPiBIZW5kZXJpY2t4LCBXaW0gKFdpbSk8YnI+PGI+ Q2M6PC9iPiBDbGFyZW5jZSBGaWxzZmlsczsgcnRnd2dAaWV0Zi5vcmc7IFN0ZXdhcnQgQnJ5YW50 IChzdGJyeWFudCk7IFNvLCBOaW5nOyBpbWMuc2hhbmRAZ29vZ2xlbWFpbC5jb208YnI+PGI+U3Vi amVjdDo8L2I+IFJlOiBSZW1vdGUgTEZBPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+QWJv dXQgcmVsYXRlZCB3b3JrIC08bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5BdCB0aGUg bGFzdCBJRVRGIHdlIHByZXNlbnRlZCBkcmFmdC1raW5pLW1wbHMtZnJyLWxkcCB0aGF0IGFkZHJl c3NlcyZuYnNwO2FkZGl0aW9uYWwgY2FzZXMgd2hlcmUgYmVzaWRlcyB1c2luZyBhIHByaW1hcnkg TFNQIHRvIGEgcmVtb3RlIExTUiBzdWNoIHRoYXQgdHJhZmZpYyBkb2VzIG5vdCBsb29wIGJhY2ss IGl0IGhhbmRsZXMgU1JMRyBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ T24gVHVlLCBPY3QgMTEsIDIwMTEgYXQgOToxMCBBTSwgSGVuZGVyaWNreCwgV2ltIChXaW0pICZs dDs8YSBocmVmPSJtYWlsdG86d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tIj53aW0u aGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+Q2xhcmVuY2UgeWVzIEkgc2F3IHRoaXMgaW4gdGhlIGxhc3Qg SUVURiBhbmQgaSBiZWxpZXZlIHRoaXMgaGFzIGEgbG90IG9mIHZhbHVlPG86cD48L286cD48L3A+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+RnJvbTogPGEgaHJlZj0ibWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmciPnJ0Z3dn LWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnJ0Z3dnLWJvdW5j ZXNAaWV0Zi5vcmciPnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgQ2xh cmVuY2UgRmlsc2ZpbHM8YnI+U2VudDogZGluc2RhZyAxMSBva3RvYmVyIDIwMTEgMTg6MDk8YnI+ VG86IDxhIGhyZWY9Im1haWx0bzpydGd3Z0BpZXRmLm9yZyI+cnRnd2dAaWV0Zi5vcmc8L2E+OyBT dGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpOyBTbywgTmluZzsgPGEgaHJlZj0ibWFpbHRvOmltYy5z aGFuZEBnb29nbGVtYWlsLmNvbSI+aW1jLnNoYW5kQGdvb2dsZW1haWwuY29tPC9hPjxicj5TdWJq ZWN0OiBSZW1vdGUgTEZBPGJyPjxicj5QbGVhc2UgZmluZCB0aGUgZm9sbG93aW5nIHN1Ym1pc3Np b24gY29tcGxlbWVudGluZyB0aGUgTEZBIHRlY2hub2xvZ3k6PGJyPjxicj48YSBocmVmPSJodHRw Oi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXNoYW5kLXJlbW90ZS1sZmEtMDAudHh0IiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1zaGFuZC1yZW1vdGUtbGZhLTAw LnR4dDwvYT48YnI+PGJyPkl0IGRyYXN0aWNhbGx5IGV4dGVuZHMgdGhlIGNvdmVyYWdlIG9mIExG QSB3aGlsZSBrZWVwaW5nIGl0cyBzaW1wbGljaXR5Ljxicj48YnI+Q2hlZXJzLDxicj5DbGFyZW5j ZTxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5y dGd3ZyBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOnJ0Z3dnQGlldGYub3JnIj5ydGd3 Z0BpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGd3ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRnd2c8L2E+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPnJ0Z3dnIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86 cnRnd2dAaWV0Zi5vcmciPnJ0Z3dnQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3ZzwvYT48bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxiciBjbGVhcj1hbGw+PG86 cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0tIDxicj4tIFNyaTxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_14C7F4F06DB5814AB0DE29716C4F6D671ADD9BC8FRMRSSXCHMBSB1d_-- From sriganeshkini@gmail.com Tue Oct 11 22:52:26 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE19B21F8B0E for ; Tue, 11 Oct 2011 22:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0X+-ol2CEAhK for ; Tue, 11 Oct 2011 22:52:26 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9606A21F8A91 for ; Tue, 11 Oct 2011 22:52:25 -0700 (PDT) Received: by wwn22 with SMTP id 22so6189699wwn.1 for ; Tue, 11 Oct 2011 22:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=WaRhG9YKzymmdD8dXUQYp97dTbruonUvjq0isx9OTPI=; b=Z/XzewcYEn4iWsu04q+0oVivt9WFrMLlubS5NYWkyYtaVq0jQl/PnIU+sJ0KfNo3F5 CuCbWrigWF4u7N/ZtyvhEKIjk+356ecxCfdRYQRFQLMye1EcEn7we+oRL0BNbmI6I0Mj Jlo86f9NFWuF1rURx8bC/5mq6i+NvvJNTszoE= Received: by 10.216.139.5 with SMTP id b5mr2944471wej.19.1318398743121; Tue, 11 Oct 2011 22:52:23 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.216.187.19 with HTTP; Tue, 11 Oct 2011 22:51:53 -0700 (PDT) In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D671ADD9BC8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <4E946A07.80403@cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671ADD9B44@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D671ADD9BC8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> From: Sriganesh Kini Date: Tue, 11 Oct 2011 22:51:53 -0700 X-Google-Sender-Auth: 2bEy31zj3u6n66D6-qPVWITxJKU Message-ID: Subject: Re: Remote LFA To: "Henderickx, Wim (Wim)" Content-Type: multipart/alternative; boundary=0016e6da2e52c18ed004af13a0fd Cc: "imc.shand@googlemail.com" , "rtgwg@ietf.org" , "So, Ning" , "Stewart Bryant \(stbryant\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 05:52:26 -0000 --0016e6da2e52c18ed004af13a0fd Content-Type: text/plain; charset=UTF-8 Of course when such a LSP exists that can function as backup it should be used. The point was that sometimes such an LSP may not exist especially with SRLG failures thereby reducing coverage. The technique can be extended to handle such cases as well thus further increasing coverage. On Tue, Oct 11, 2011 at 10:30 PM, Henderickx, Wim (Wim) < wim.henderickx@alcatel-lucent.com> wrote: > I still believe remote LFA has more merits for the service providers who > deploy LFA and want to increase the coverage. It is not about SRLG or not. > It is about coverage and remote LFA has the benefits that is re-uses > operational procedures which are in place in service providers networks > today. So extending them is better than introducing a complete new scheme. > **** > > ** ** > > *From:* sriganeshkini@gmail.com [mailto:sriganeshkini@gmail.com] *On > Behalf Of *Sriganesh Kini > *Sent:* dinsdag 11 oktober 2011 22:21 > *To:* Henderickx, Wim (Wim) > *Cc:* Clarence Filsfils; rtgwg@ietf.org; Stewart Bryant (stbryant); So, > Ning; imc.shand@googlemail.com > *Subject:* Re: Remote LFA**** > > ** ** > > About related work -**** > > ** ** > > At the last IETF we presented draft-kini-mpls-frr-ldp that > addresses additional cases where besides using a primary LSP to a remote LSR > such that traffic does not loop back, it handles SRLG as well.**** > > ** ** > > On Tue, Oct 11, 2011 at 9:10 AM, Henderickx, Wim (Wim) < > wim.henderickx@alcatel-lucent.com> wrote:**** > > Clarence yes I saw this in the last IETF and i believe this has a lot of > value**** > > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Clarence Filsfils > Sent: dinsdag 11 oktober 2011 18:09 > To: rtgwg@ietf.org; Stewart Bryant (stbryant); So, Ning; > imc.shand@googlemail.com > Subject: Remote LFA > > Please find the following submission complementing the LFA technology: > > http://www.ietf.org/id/draft-shand-remote-lfa-00.txt > > It drastically extends the coverage of LFA while keeping its simplicity. > > Cheers, > Clarence > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg**** > > > > **** > > ** ** > > -- > - Sri**** > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > -- - Sri --0016e6da2e52c18ed004af13a0fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Of course when such a LSP exists that can function as backup it should be u= sed. The point was that sometimes such an LSP may not exist especially with= SRLG failures thereby reducing coverage. The technique can be extended to = handle such cases as well thus further increasing coverage.

On Tue, Oct 11, 2011 at 10:30 PM, Henderickx= , Wim (Wim) <wim.henderickx@alcatel-lucent.com> wrote:

I still believe remote L= FA has more merits for the service providers who deploy LFA and want to inc= rease the coverage. It is not about SRLG or not. It is about coverage and r= emote LFA has the benefits that is re-uses operational procedures which are= in place in service providers networks today. So extending them is better = than introducing a complete new scheme.

=C2=A0

From: sriganeshkini@gmail.= com [mailto:sriganeshkini@gmail.com] On Behalf Of Sriganesh Kini
Sent: dinsdag 11 oktober 2011 22:21
To: Henderickx, Wim (W= im)
Cc: Clarence Filsfils; rtgwg@ietf.org; Stewart Bryant (stbryant); So, Ning; imc.shand@googlem= ail.com
Subject: Re: Remote LFA

=C2=A0

About related work -

=C2=A0

At the last IETF we presented draft-kini-= mpls-frr-ldp that addresses=C2=A0additional cases where besides using a pri= mary LSP to a remote LSR such that traffic does not loop back, it handles S= RLG as well.

=C2=A0

On Tue, Oct 11, 2011 at 9:10 AM, Henderickx, Wim (Wim) <wim.hender= ickx@alcatel-lucent.com> wrote:

Clarence yes I saw this in the last IETF and i belie= ve this has a lot of value


-----Original Message-----
From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] = On Behalf Of Clarence Filsfils
Sent: dinsdag 11 oktober 2011 18:09
To: rtgwg@ietf.org; Stewart Bryant (stbryant); So, Ning= ; imc.shand@g= ooglemail.com
Subject: Remote LFA

Please find the following submission complementi= ng the LFA technology:

http://www.ietf.org/id/draft-shand-re= mote-lfa-00.txt

It drastically extends the coverage of LFA while keeping its simplicity= .

Cheers,
Clarence
___________________________________________= ____
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg
_________________________= ______________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg



=

=C2=A0

--
- Sri=


_____________________= __________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg




--
- Sri --0016e6da2e52c18ed004af13a0fd-- From Andras.Csaszar@ericsson.com Wed Oct 12 06:53:49 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC5421F8B9A for ; Wed, 12 Oct 2011 06:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yjoURgt3C6O for ; Wed, 12 Oct 2011 06:53:49 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id BE77021F8B75 for ; Wed, 12 Oct 2011 06:53:48 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-3b-4e959beb9d2e Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 03.80.13753.BEB959E4; Wed, 12 Oct 2011 15:53:47 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([153.88.115.184]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 12 Oct 2011 15:53:47 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: "Sucec, John M" , "rtgwg@ietf.org" Date: Wed, 12 Oct 2011 15:53:46 +0200 Subject: RE: Remote LFA Thread-Topic: Remote LFA Thread-Index: AcyIMBLWjBD2uUgRTgGPsEA5LqSIRAAACi1AAAEY6BQALEn+oA== Message-ID: <8DCD771BDA4A394E9BCBA8932E839297403C933D32@ESESSCMS0363.eemea.ericsson.se> References: <4E946A07.80403@cisco.com>, <563593148DD9A040B93397F642B3C1255999FCB95E@rrc-dte-exmb1.dte.telcordia.com> In-Reply-To: <563593148DD9A040B93397F642B3C1255999FCB95E@rrc-dte-exmb1.dte.telcordia.com> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 13:53:49 -0000 Hi John! http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-01 also follows the princ= iples of RLFAPs, but adds the dataplane notification protocol that we think= was needed to make it real quick. We are planning to show performance results from our IPFRR-FN prototype at = the RTGWG meeting in Taiwan. Are you coming? Maybe we should combine the re= sults if you have related experimentation results. Thanks, Andr=E1s > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org]=20 > On Behalf Of Sucec, John M > Sent: 2011. okt=F3ber 11. 19:08 > To: G=E1bor S=E1ndor Enyedi; Clarence Filsfils; rtgwg@ietf.org;=20 > Stewart Bryant (stbryant); So, Ning; imc.shand@googlemail.com > Subject: RE: Remote LFA >=20 > Gabor, thank you for recalling the=20 > http://tools.ietf.org/html/draft-hokelek-rlfap-01 Internet=20 > Draft that Telcordia submitted earlier. >=20 > All: While that earlier Internet Draft did not gain much=20 > traction within the Routing Area WG at the time of its=20 > submission, we continued to experiment with its methods and=20 > have published some proof-of-concept results. >=20 > I am glad to see that there is renewed interest in the=20 > general topic of expanding/formalizing protection against=20 > link failures beyond the basic LFA path mechanism (RFC 5286). >=20 > I will review the latest drafts on LFA technologies and look=20 > forward to collaborating where possible. >=20 > Thanks. >=20 > John > ________________________________________ > From: rtgwg-bounces@ietf.org [rtgwg-bounces@ietf.org] On=20 > Behalf Of G=E1bor S=E1ndor Enyedi [gabor.sandor.enyedi@ericsson.com] > Sent: Tuesday, October 11, 2011 12:25 PM > To: Clarence Filsfils; rtgwg@ietf.org; Stewart Bryant=20 > (stbryant); So, Ning; imc.shand@googlemail.com > Subject: RE: Remote LFA >=20 > Wow... I will read it as soon as I can, I'm curious what is=20 > the difference between this and=20 > http://tools.ietf.org/html/draft-hokelek-rlfap-01 - first I=20 > thought that you're speaking about this one, since the title=20 > is very similar. At the last IETF we proposed this=20 > http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-01, but it=20 > seemed that everybody was strongly against giving up local=20 > protection (like it was a religious dogma). It's good to see=20 > that I'm not alone anymore! > BR, >=20 > Gabor >=20 > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org]=20 > On Behalf Of Clarence Filsfils > Sent: Tuesday, October 11, 2011 6:09 PM > To: rtgwg@ietf.org; Stewart Bryant (stbryant); So, Ning;=20 > imc.shand@googlemail.com > Subject: Remote LFA >=20 > Please find the following submission complementing the LFA technology: >=20 > http://www.ietf.org/id/draft-shand-remote-lfa-00.txt >=20 > It drastically extends the coverage of LFA while keeping its=20 > simplicity. >=20 > Cheers, > Clarence > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > = From ning.so@verizon.com Wed Oct 12 07:38:58 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A9221F8BE7 for ; Wed, 12 Oct 2011 07:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3cEA07Go-yA for ; Wed, 12 Oct 2011 07:38:58 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6608E21F8BBF for ; Wed, 12 Oct 2011 07:38:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe03.verizon.com with ESMTP; 12 Oct 2011 14:38:54 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.69,334,1315180800"; d="scan'208,217";a="157152784" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi03.verizon.com with ESMTP; 12 Oct 2011 14:38:40 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.133]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Wed, 12 Oct 2011 10:38:40 -0400 To: "Henderickx, Wim (Wim)" , Sriganesh Kini Date: Wed, 12 Oct 2011 10:38:39 -0400 Subject: RE: Remote LFA Thread-Topic: Remote LFA Thread-Index: AcyIU2GOdYvxL8FWQvyAgk4Sr2aIogATFrmgABMOH8A= Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC08F27A3DB@FHDP1LUMXC7V41.us.one.verizon.com> References: <4E946A07.80403@cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671ADD9B44@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D671ADD9BC8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D671ADD9BC8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6665BC1FEA04AB47B1F75FA641C43BC08F27A3DBFHDP1LUMXC7V41u_" MIME-Version: 1.0 Cc: "imc.shand@googlemail.com" , "Stewart Bryant \(stbryant\)" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 14:38:58 -0000 --_000_6665BC1FEA04AB47B1F75FA641C43BC08F27A3DBFHDP1LUMXC7V41u_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZS4gIE9wZXJhdG9ycyBoYXZlIGJlZW4gaG9sZGluZyBiYWNrIHRoZSBkZXBsb3ltZW50 IG9mIExGQSBiZWNhdXNlIG9mIHRob3NlIHJlYXNvbnMgV2ltIHN0YXRlZC4gICBSZW1vdGUgTEZB IHNvbHZlcyB0aG9zZSBwcm9ibGVtcy4gIEl0IHNob3VsZCBoZWxwIHRvIHNwZWVkIHVwIHRoZSBM RkEgZGVwbG95bWVudCBpbiB0aGUgZmllbGQuDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpOaW5nIFNv DQpWZXJpem9uIENvcnBvcmF0ZSBUZWNobm9sb2d5DQoob2ZmaWNlKSA5NzItNzI5LTc5MDUNCihD ZWxsKSA5NzItOTU1LTA5MTQNCg0KDQpGcm9tOiBIZW5kZXJpY2t4LCBXaW0gKFdpbSkgW21haWx0 bzp3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb21dDQpTZW50OiBXZWRuZXNkYXksIE9j dG9iZXIgMTIsIDIwMTEgMTI6MzEgQU0NClRvOiBTcmlnYW5lc2ggS2luaQ0KQ2M6IENsYXJlbmNl IEZpbHNmaWxzOyBydGd3Z0BpZXRmLm9yZzsgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KTsgU28s IE5pbmc7IGltYy5zaGFuZEBnb29nbGVtYWlsLmNvbQ0KU3ViamVjdDogUkU6IFJlbW90ZSBMRkEN Cg0KSSBzdGlsbCBiZWxpZXZlIHJlbW90ZSBMRkEgaGFzIG1vcmUgbWVyaXRzIGZvciB0aGUgc2Vy dmljZSBwcm92aWRlcnMgd2hvIGRlcGxveSBMRkEgYW5kIHdhbnQgdG8gaW5jcmVhc2UgdGhlIGNv dmVyYWdlLiBJdCBpcyBub3QgYWJvdXQgU1JMRyBvciBub3QuIEl0IGlzIGFib3V0IGNvdmVyYWdl IGFuZCByZW1vdGUgTEZBIGhhcyB0aGUgYmVuZWZpdHMgdGhhdCBpcyByZS11c2VzIG9wZXJhdGlv bmFsIHByb2NlZHVyZXMgd2hpY2ggYXJlIGluIHBsYWNlIGluIHNlcnZpY2UgcHJvdmlkZXJzIG5l dHdvcmtzIHRvZGF5LiBTbyBleHRlbmRpbmcgdGhlbSBpcyBiZXR0ZXIgdGhhbiBpbnRyb2R1Y2lu ZyBhIGNvbXBsZXRlIG5ldyBzY2hlbWUuDQoNCkZyb206IHNyaWdhbmVzaGtpbmlAZ21haWwuY29t PG1haWx0bzpzcmlnYW5lc2hraW5pQGdtYWlsLmNvbT4gW21haWx0bzpzcmlnYW5lc2hraW5pQGdt YWlsLmNvbV08bWFpbHRvOlttYWlsdG86c3JpZ2FuZXNoa2luaUBnbWFpbC5jb21dPiBPbiBCZWhh bGYgT2YgU3JpZ2FuZXNoIEtpbmkNClNlbnQ6IGRpbnNkYWcgMTEgb2t0b2JlciAyMDExIDIyOjIx DQpUbzogSGVuZGVyaWNreCwgV2ltIChXaW0pDQpDYzogQ2xhcmVuY2UgRmlsc2ZpbHM7IHJ0Z3dn QGlldGYub3JnPG1haWx0bzpydGd3Z0BpZXRmLm9yZz47IFN0ZXdhcnQgQnJ5YW50IChzdGJyeWFu dCk7IFNvLCBOaW5nOyBpbWMuc2hhbmRAZ29vZ2xlbWFpbC5jb208bWFpbHRvOmltYy5zaGFuZEBn b29nbGVtYWlsLmNvbT4NClN1YmplY3Q6IFJlOiBSZW1vdGUgTEZBDQoNCkFib3V0IHJlbGF0ZWQg d29yayAtDQoNCkF0IHRoZSBsYXN0IElFVEYgd2UgcHJlc2VudGVkIGRyYWZ0LWtpbmktbXBscy1m cnItbGRwIHRoYXQgYWRkcmVzc2VzIGFkZGl0aW9uYWwgY2FzZXMgd2hlcmUgYmVzaWRlcyB1c2lu ZyBhIHByaW1hcnkgTFNQIHRvIGEgcmVtb3RlIExTUiBzdWNoIHRoYXQgdHJhZmZpYyBkb2VzIG5v dCBsb29wIGJhY2ssIGl0IGhhbmRsZXMgU1JMRyBhcyB3ZWxsLg0KDQpPbiBUdWUsIE9jdCAxMSwg MjAxMSBhdCA5OjEwIEFNLCBIZW5kZXJpY2t4LCBXaW0gKFdpbSkgPHdpbS5oZW5kZXJpY2t4QGFs Y2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29t Pj4gd3JvdGU6DQpDbGFyZW5jZSB5ZXMgSSBzYXcgdGhpcyBpbiB0aGUgbGFzdCBJRVRGIGFuZCBp IGJlbGlldmUgdGhpcyBoYXMgYSBsb3Qgb2YgdmFsdWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IHJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnLWJvdW5jZXNA aWV0Zi5vcmc+IFttYWlsdG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRnd2ctYm91 bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBDbGFyZW5jZSBGaWxzZmlscw0KU2VudDogZGlu c2RhZyAxMSBva3RvYmVyIDIwMTEgMTg6MDkNClRvOiBydGd3Z0BpZXRmLm9yZzxtYWlsdG86cnRn d2dAaWV0Zi5vcmc+OyBTdGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpOyBTbywgTmluZzsgaW1jLnNo YW5kQGdvb2dsZW1haWwuY29tPG1haWx0bzppbWMuc2hhbmRAZ29vZ2xlbWFpbC5jb20+DQpTdWJq ZWN0OiBSZW1vdGUgTEZBDQoNClBsZWFzZSBmaW5kIHRoZSBmb2xsb3dpbmcgc3VibWlzc2lvbiBj b21wbGVtZW50aW5nIHRoZSBMRkEgdGVjaG5vbG9neToNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9p ZC9kcmFmdC1zaGFuZC1yZW1vdGUtbGZhLTAwLnR4dA0KDQpJdCBkcmFzdGljYWxseSBleHRlbmRz IHRoZSBjb3ZlcmFnZSBvZiBMRkEgd2hpbGUga2VlcGluZyBpdHMgc2ltcGxpY2l0eS4NCg0KQ2hl ZXJzLA0KQ2xhcmVuY2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpydGd3ZyBtYWlsaW5nIGxpc3QNCnJ0Z3dnQGlldGYub3JnPG1haWx0bzpydGd3Z0Bp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2cNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGd3ZyBtYWls aW5nIGxpc3QNCnJ0Z3dnQGlldGYub3JnPG1haWx0bzpydGd3Z0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2cNCg0KDQoNCi0tDQotIFNyaQ0K --_000_6665BC1FEA04AB47B1F75FA641C43BC08F27A3DBFHDP1LUMXC7V41u_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFu Zz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgYWdyZWUuwqAgT3BlcmF0 b3JzIGhhdmUgYmVlbiBob2xkaW5nIGJhY2sgdGhlIGRlcGxveW1lbnQgb2YgTEZBIGJlY2F1c2Ug b2YgdGhvc2UgcmVhc29ucyBXaW0gc3RhdGVkLiDCoMKgUmVtb3RlIExGQSBzb2x2ZXMgdGhvc2Ug cHJvYmxlbXMuwqAgSXQgc2hvdWxkIGhlbHAgdG8gc3BlZWQgdXAgdGhlIExGQSBkZXBsb3ltZW50 IGluIHRoZSBmaWVsZC7CoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5CZXN0 IHJlZ2FyZHMsPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ TmluZyBTbzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VmVyaXpvbiBDb3Jwb3Jh dGUgVGVjaG5vbG9neTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+KG9mZmljZSkgOTcyLTcyOS03OTA1PC9zcGFuPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz4oQ2VsbCkgOTcyLTk1NS0wOTE0PC9zcGFuPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+IEhlbmRlcmlja3gsIFdpbSAoV2ltKSBbbWFpbHRvOndpbS5oZW5kZXJpY2t4QGFsY2F0 ZWwtbHVjZW50LmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE9jdG9iZXIgMTIsIDIw MTEgMTI6MzEgQU08YnI+PGI+VG86PC9iPiBTcmlnYW5lc2ggS2luaTxicj48Yj5DYzo8L2I+IENs YXJlbmNlIEZpbHNmaWxzOyBydGd3Z0BpZXRmLm9yZzsgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50 KTsgU28sIE5pbmc7IGltYy5zaGFuZEBnb29nbGVtYWlsLmNvbTxicj48Yj5TdWJqZWN0OjwvYj4g UkU6IFJlbW90ZSBMRkE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPkkgc3RpbGwgYmVsaWV2ZSByZW1vdGUgTEZBIGhhcyBtb3JlIG1lcml0 cyBmb3IgdGhlIHNlcnZpY2UgcHJvdmlkZXJzIHdobyBkZXBsb3kgTEZBIGFuZCB3YW50IHRvIGlu Y3JlYXNlIHRoZSBjb3ZlcmFnZS4gSXQgaXMgbm90IGFib3V0IFNSTEcgb3Igbm90LiBJdCBpcyBh Ym91dCBjb3ZlcmFnZSBhbmQgcmVtb3RlIExGQSBoYXMgdGhlIGJlbmVmaXRzIHRoYXQgaXMgcmUt dXNlcyBvcGVyYXRpb25hbCBwcm9jZWR1cmVzIHdoaWNoIGFyZSBpbiBwbGFjZSBpbiBzZXJ2aWNl IHByb3ZpZGVycyBuZXR3b3JrcyB0b2RheS4gU28gZXh0ZW5kaW5nIHRoZW0gaXMgYmV0dGVyIHRo YW4gaW50cm9kdWNpbmcgYSBjb21wbGV0ZSBuZXcgc2NoZW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1h bD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiA8YSBocmVmPSJtYWlsdG86c3Jp Z2FuZXNoa2luaUBnbWFpbC5jb20iPnNyaWdhbmVzaGtpbmlAZ21haWwuY29tPC9hPiA8YSBocmVm PSJtYWlsdG86W21haWx0bzpzcmlnYW5lc2hraW5pQGdtYWlsLmNvbV0iPlttYWlsdG86c3JpZ2Fu ZXNoa2luaUBnbWFpbC5jb21dPC9hPiA8Yj5PbiBCZWhhbGYgT2YgPC9iPlNyaWdhbmVzaCBLaW5p PGJyPjxiPlNlbnQ6PC9iPiBkaW5zZGFnIDExIG9rdG9iZXIgMjAxMSAyMjoyMTxicj48Yj5Ubzo8 L2I+IEhlbmRlcmlja3gsIFdpbSAoV2ltKTxicj48Yj5DYzo8L2I+IENsYXJlbmNlIEZpbHNmaWxz OyA8YSBocmVmPSJtYWlsdG86cnRnd2dAaWV0Zi5vcmciPnJ0Z3dnQGlldGYub3JnPC9hPjsgU3Rl d2FydCBCcnlhbnQgKHN0YnJ5YW50KTsgU28sIE5pbmc7IDxhIGhyZWY9Im1haWx0bzppbWMuc2hh bmRAZ29vZ2xlbWFpbC5jb20iPmltYy5zaGFuZEBnb29nbGVtYWlsLmNvbTwvYT48YnI+PGI+U3Vi amVjdDo8L2I+IFJlOiBSZW1vdGUgTEZBPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+QWJv dXQgcmVsYXRlZCB3b3JrIC08bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5BdCB0aGUg bGFzdCBJRVRGIHdlIHByZXNlbnRlZCBkcmFmdC1raW5pLW1wbHMtZnJyLWxkcCB0aGF0IGFkZHJl c3NlcyZuYnNwO2FkZGl0aW9uYWwgY2FzZXMgd2hlcmUgYmVzaWRlcyB1c2luZyBhIHByaW1hcnkg TFNQIHRvIGEgcmVtb3RlIExTUiBzdWNoIHRoYXQgdHJhZmZpYyBkb2VzIG5vdCBsb29wIGJhY2ss IGl0IGhhbmRsZXMgU1JMRyBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ T24gVHVlLCBPY3QgMTEsIDIwMTEgYXQgOToxMCBBTSwgSGVuZGVyaWNreCwgV2ltIChXaW0pICZs dDs8YSBocmVmPSJtYWlsdG86d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tIj53aW0u aGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+Q2xhcmVuY2UgeWVzIEkgc2F3IHRoaXMgaW4gdGhlIGxhc3Qg SUVURiBhbmQgaSBiZWxpZXZlIHRoaXMgaGFzIGEgbG90IG9mIHZhbHVlPG86cD48L286cD48L3A+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+RnJvbTogPGEgaHJlZj0ibWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmciPnJ0Z3dn LWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnJ0Z3dnLWJvdW5j ZXNAaWV0Zi5vcmciPnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgQ2xh cmVuY2UgRmlsc2ZpbHM8YnI+U2VudDogZGluc2RhZyAxMSBva3RvYmVyIDIwMTEgMTg6MDk8YnI+ VG86IDxhIGhyZWY9Im1haWx0bzpydGd3Z0BpZXRmLm9yZyI+cnRnd2dAaWV0Zi5vcmc8L2E+OyBT dGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpOyBTbywgTmluZzsgPGEgaHJlZj0ibWFpbHRvOmltYy5z aGFuZEBnb29nbGVtYWlsLmNvbSI+aW1jLnNoYW5kQGdvb2dsZW1haWwuY29tPC9hPjxicj5TdWJq ZWN0OiBSZW1vdGUgTEZBPGJyPjxicj5QbGVhc2UgZmluZCB0aGUgZm9sbG93aW5nIHN1Ym1pc3Np b24gY29tcGxlbWVudGluZyB0aGUgTEZBIHRlY2hub2xvZ3k6PGJyPjxicj48YSBocmVmPSJodHRw Oi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXNoYW5kLXJlbW90ZS1sZmEtMDAudHh0IiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1zaGFuZC1yZW1vdGUtbGZhLTAw LnR4dDwvYT48YnI+PGJyPkl0IGRyYXN0aWNhbGx5IGV4dGVuZHMgdGhlIGNvdmVyYWdlIG9mIExG QSB3aGlsZSBrZWVwaW5nIGl0cyBzaW1wbGljaXR5Ljxicj48YnI+Q2hlZXJzLDxicj5DbGFyZW5j ZTxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5y dGd3ZyBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOnJ0Z3dnQGlldGYub3JnIj5ydGd3 Z0BpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGd3ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRnd2c8L2E+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPnJ0Z3dnIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86 cnRnd2dAaWV0Zi5vcmciPnJ0Z3dnQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3ZzwvYT48bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxiciBjbGVhcj1hbGw+PG86 cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0tIDxicj4tIFNyaTxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_6665BC1FEA04AB47B1F75FA641C43BC08F27A3DBFHDP1LUMXC7V41u_-- From akatlas@gmail.com Wed Oct 12 07:54:11 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D14821F8BC4 for ; Wed, 12 Oct 2011 07:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7BKqIlxeK1h for ; Wed, 12 Oct 2011 07:54:10 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 31AF721F8BC5 for ; Wed, 12 Oct 2011 07:54:10 -0700 (PDT) Received: by pzk37 with SMTP id 37so202701pzk.9 for ; Wed, 12 Oct 2011 07:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CPKmNFQEbsvcgYLKYuALOO0JYjRR1N5fdDnGmeVjqlM=; b=P4q9l0VSD6jmPDtM4jvjo42t9xt0Uwao6RcCn0z5UA4FPaZnX4c3VaqKTH0vB7iDqK jDxf5KmVGdYJb+MdrKYicxVZ2cRaDthZsNflkrImJHRH4NfWMpJwEAIh8/BfOZKvXI42 9mgcUCC9A2Y/aSKYSdRAtqd/YBDmmnaADJRqo= MIME-Version: 1.0 Received: by 10.68.38.169 with SMTP id h9mr1626307pbk.113.1318431248756; Wed, 12 Oct 2011 07:54:08 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Wed, 12 Oct 2011 07:54:08 -0700 (PDT) In-Reply-To: <6665BC1FEA04AB47B1F75FA641C43BC08F27A3DB@FHDP1LUMXC7V41.us.one.verizon.com> References: <4E946A07.80403@cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671ADD9B44@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D671ADD9BC8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <6665BC1FEA04AB47B1F75FA641C43BC08F27A3DB@FHDP1LUMXC7V41.us.one.verizon.com> Date: Wed, 12 Oct 2011 10:54:08 -0400 Message-ID: Subject: Re: Remote LFA From: Alia Atlas To: "So, Ning" Content-Type: multipart/alternative; boundary=bcaec520f1bd3e2ef704af1b32f0 Cc: "imc.shand@googlemail.com" , "Stewart Bryant \(stbryant\)" , "rtgwg@ietf.org" , Sriganesh Kini X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 14:54:11 -0000 --bcaec520f1bd3e2ef704af1b32f0 Content-Type: text/plain; charset=ISO-8859-1 When RTGWG had this same discussion a number of years ago, the consensus was that we wanted a solution that provided 100% coverage. At the time, of course, we were discussing both PQ (of which Remote LFA is a subset) and U-turn alternates. Now, we have two options that provide 100% coverage - NotVia, which has proved too heavy-weight, and MRT, which is being actively investigated. I don't believe that the requirements and reasons for 100% coverage that were made a few years ago have changed. Alia On Wed, Oct 12, 2011 at 10:38 AM, So, Ning wrote: > I agree. Operators have been holding back the deployment of LFA because of > those reasons Wim stated. Remote LFA solves those problems. It should > help to speed up the LFA deployment in the field. **** > > ** ** > > **** > > Best regards,**** > > **** > > Ning So**** > > Verizon Corporate Technology**** > > (office) 972-729-7905**** > > (Cell) 972-955-0914**** > > **** > > ** ** > > *From:* Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] > *Sent:* Wednesday, October 12, 2011 12:31 AM > *To:* Sriganesh Kini > > *Cc:* Clarence Filsfils; rtgwg@ietf.org; Stewart Bryant (stbryant); So, > Ning; imc.shand@googlemail.com > *Subject:* RE: Remote LFA**** > > ** ** > > I still believe remote LFA has more merits for the service providers who > deploy LFA and want to increase the coverage. It is not about SRLG or not. > It is about coverage and remote LFA has the benefits that is re-uses > operational procedures which are in place in service providers networks > today. So extending them is better than introducing a complete new scheme. > **** > > ** ** > > *From:* sriganeshkini@gmail.com [mailto:sriganeshkini@gmail.com] *On > Behalf Of *Sriganesh Kini > *Sent:* dinsdag 11 oktober 2011 22:21 > *To:* Henderickx, Wim (Wim) > *Cc:* Clarence Filsfils; rtgwg@ietf.org; Stewart Bryant (stbryant); So, > Ning; imc.shand@googlemail.com > *Subject:* Re: Remote LFA**** > > ** ** > > About related work -**** > > ** ** > > At the last IETF we presented draft-kini-mpls-frr-ldp that > addresses additional cases where besides using a primary LSP to a remote LSR > such that traffic does not loop back, it handles SRLG as well.**** > > ** ** > > On Tue, Oct 11, 2011 at 9:10 AM, Henderickx, Wim (Wim) < > wim.henderickx@alcatel-lucent.com> wrote:**** > > Clarence yes I saw this in the last IETF and i believe this has a lot of > value**** > > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Clarence Filsfils > Sent: dinsdag 11 oktober 2011 18:09 > To: rtgwg@ietf.org; Stewart Bryant (stbryant); So, Ning; > imc.shand@googlemail.com > Subject: Remote LFA > > Please find the following submission complementing the LFA technology: > > http://www.ietf.org/id/draft-shand-remote-lfa-00.txt > > It drastically extends the coverage of LFA while keeping its simplicity. > > Cheers, > Clarence > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg**** > > > > **** > > ** ** > > -- > - Sri**** > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > --bcaec520f1bd3e2ef704af1b32f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable When RTGWG had this same discussion a number of years ago, the consensus wa= s that we wanted a solution that provided 100% coverage.=A0 At the time, of= course, we were discussing both PQ (of which Remote LFA is a subset) and U= -turn alternates.

Now, we have two options that provide 100% coverage - NotVia, which has= proved too heavy-weight, and MRT, which is being actively investigated.
I don't believe that the requirements and reasons for 100% coverag= e that were made a few years ago have changed.

Alia

On Wed, Oct 12, 2011 at 10:38 AM= , So, Ning <nin= g.so@verizon.com> wrote:

I agree.=A0 Operators ha= ve been holding back the deployment of LFA because of those reasons Wim sta= ted. =A0=A0Remote LFA solves those problems.=A0 It should help to speed up = the LFA deployment in the field.=A0

=A0

=A0

<= span style=3D"font-size:10.0pt;color:#1F497D">Best regards,

=A0

Ning So

Veriz= on Corporate Technology

(office) 972-729-7905

(Cell= ) 972= -955-0914<= u>

=A0

=A0

Fr= om: Henderickx, Wim (Wim) [mail= to:w= im.henderickx@alcatel-lucent.com]
Sent: Wednesday, October 12, 2011 12:31 AM
To: Sriganesh K= ini


Cc: Clarence Filsfils; rtgwg@ietf.org; Stewart Br= yant (stbryant); So, Ning; imc.shand@googlemail.com
Subject: RE: Remote LFA

<= div>

=A0

I still = believe remote LFA has more merits for the service providers who deploy LFA= and want to increase the coverage. It is not about SRLG or not. It is abou= t coverage and remote LFA has the benefits that is re-uses operational proc= edures which are in place in service providers networks today. So extending= them is better than introducing a complete new scheme.

=A0

From: sriganeshkini@gmail.c= om [mailto:sriganeshkini@gmail.com] On Behalf Of Sriganesh Kini Sent: dinsdag 11 oktober 2011 22:21
To: Henderickx, Wim (W= im)
Cc: Clarence Filsfils; rtgwg@ietf.org; Stewart Bryant (stbryant); So, Ning; imc.shand@googlem= ail.com
Subject: Re: Remote LFA

=A0

About related work -

=A0

At the last IETF we presented draft-kini-mpls-frr-ldp that addresses=A0addi= tional cases where besides using a primary LSP to a remote LSR such that tr= affic does not loop back, it handles SRLG as well.

=A0

On Tue, Oct 11, 2011 at 9:10 AM, Henderickx, Wim (Wim) <wim.henderickx@alc= atel-lucent.com> wrote:

Clarence yes I saw this in the last IETF and i belie= ve this has a lot of value


-----Original Message-----
From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] = On Behalf Of Clarence Filsfils
Sent: dinsdag 11 oktober 2011 18:09
To: rtgwg@ietf.org; Stewart Bryant (stbryant); So, Ning= ; imc.shand@g= ooglemail.com
Subject: Remote LFA

Please find the following submission complementi= ng the LFA technology:

http://www.ietf.org/id/draft-shand-re= mote-lfa-00.txt

It drastically extends the coverage of LFA while keeping its simplicity= .

Cheers,
Clarence
___________________________________________= ____
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg
_________________________= ______________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg



=

=A0

--
- Sri


________________________= _______________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg


--bcaec520f1bd3e2ef704af1b32f0-- From Andras.Csaszar@ericsson.com Wed Oct 12 08:11:01 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA8821F8B82 for ; Wed, 12 Oct 2011 08:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM4WxmYfNpk8 for ; Wed, 12 Oct 2011 08:11:00 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0631C21F8AEC for ; Wed, 12 Oct 2011 08:10:59 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-b7-4e95ae02b2e4 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 24.2F.13753.20EA59E4; Wed, 12 Oct 2011 17:10:58 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([153.88.115.184]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 12 Oct 2011 17:10:58 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: Alia Atlas , "rtgwg@ietf.org" Date: Wed, 12 Oct 2011 17:10:57 +0200 Subject: RE: Remote LFA Thread-Topic: Remote LFA Thread-Index: AcyI7tJr3jYIBW1+RwOugFS4BD35PgAAes+Q Message-ID: <8DCD771BDA4A394E9BCBA8932E839297403C933DA8@ESESSCMS0363.eemea.ericsson.se> References: <4E946A07.80403@cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671ADD9B44@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D671ADD9BC8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <6665BC1FEA04AB47B1F75FA641C43BC08F27A3DB@FHDP1LUMXC7V41.us.one.verizon.com> In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: multipart/alternative; boundary="_000_8DCD771BDA4A394E9BCBA8932E839297403C933DA8ESESSCMS0363e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 15:11:01 -0000 --_000_8DCD771BDA4A394E9BCBA8932E839297403C933DA8ESESSCMS0363e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please don't forget IPFRR-FN which is actively being investigated, too. :-) If one is not aiming for 100% coverage, then there is LFA the coverage of w= hich can be improved significantly with network tweaking (e.g. cost optimis= ation). Andr=E1s ________________________________ From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of A= lia Atlas Sent: 2011. okt=F3ber 12. 16:54 To: So, Ning Cc: imc.shand@googlemail.com; Stewart Bryant (stbryant); rtgwg@ietf.org; Sr= iganesh Kini Subject: Re: Remote LFA When RTGWG had this same discussion a number of years ago, the consensus wa= s that we wanted a solution that provided 100% coverage. At the time, of c= ourse, we were discussing both PQ (of which Remote LFA is a subset) and U-t= urn alternates. Now, we have two options that provide 100% coverage - NotVia, which has pro= ved too heavy-weight, and MRT, which is being actively investigated. I don't believe that the requirements and reasons for 100% coverage that we= re made a few years ago have changed. Alia On Wed, Oct 12, 2011 at 10:38 AM, So, Ning > wrote: I agree. Operators have been holding back the deployment of LFA because of= those reasons Wim stated. Remote LFA solves those problems. It should h= elp to speed up the LFA deployment in the field. Best regards, Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Wednesday, October 12, 2011 12:31 AM To: Sriganesh Kini Cc: Clarence Filsfils; rtgwg@ietf.org; Stewart Bryan= t (stbryant); So, Ning; imc.shand@googlemail.com Subject: RE: Remote LFA I still believe remote LFA has more merits for the service providers who de= ploy LFA and want to increase the coverage. It is not about SRLG or not. It= is about coverage and remote LFA has the benefits that is re-uses operatio= nal procedures which are in place in service providers networks today. So e= xtending them is better than introducing a complete new scheme. From: sriganeshkini@gmail.com [mailto:sriga= neshkini@gmail.com] On Behalf Of S= riganesh Kini Sent: dinsdag 11 oktober 2011 22:21 To: Henderickx, Wim (Wim) Cc: Clarence Filsfils; rtgwg@ietf.org; Stewart Bryan= t (stbryant); So, Ning; imc.shand@googlemail.com Subject: Re: Remote LFA About related work - At the last IETF we presented draft-kini-mpls-frr-ldp that addresses additi= onal cases where besides using a primary LSP to a remote LSR such that traf= fic does not loop back, it handles SRLG as well. On Tue, Oct 11, 2011 at 9:10 AM, Henderickx, Wim (Wim) > wrote: Clarence yes I saw this in the last IETF and i believe this has a lot of va= lue -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-b= ounces@ietf.org] On Behalf Of Clarence Filsf= ils Sent: dinsdag 11 oktober 2011 18:09 To: rtgwg@ietf.org; Stewart Bryant (stbryant); So, N= ing; imc.shand@googlemail.com Subject: Remote LFA Please find the following submission complementing the LFA technology: http://www.ietf.org/id/draft-shand-remote-lfa-00.txt It drastically extends the coverage of LFA while keeping its simplicity. Cheers, Clarence _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg -- - Sri _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_8DCD771BDA4A394E9BCBA8932E839297403C933DA8ESESSCMS0363e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Please don't forget IPFRR-FN which is actively b= eing=20 investigated, too. :-)
 
If one is not aiming for 100% coverage, then the= re is=20 LFA the coverage of which can be improved significantly with network tweaki= ng=20 (e.g. cost optimisation).
 
Andr=E1s
 

From: rtgwg-bounces@ietf.org=20 [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alia Atlas
Sent= :=20 2011. okt=F3ber 12. 16:54
To: So, Ning
Cc:=20 imc.shand@googlemail.com; Stewart Bryant (stbryant); rtgwg@ietf.org; Srig= anesh=20 Kini
Subject: Re: Remote LFA

When RTGWG had this same discussion a number of years ago, the= =20 consensus was that we wanted a solution that provided 100% coverage. = ; At=20 the time, of course, we were discussing both PQ (of which Remote LFA is a= =20 subset) and U-turn alternates.

Now, we have two options that provi= de=20 100% coverage - NotVia, which has proved too heavy-weight, and MRT, which= is=20 being actively investigated.

I don't believe that the requirements= and=20 reasons for 100% coverage that were made a few years ago have=20 changed.

Alia

On Wed, Oct 12, 2011 at 10:38 AM, So, Ning <ning.so@verizon.com>=20 wrote:

I= =20 agree.  Operators have been holding back the deployment of LFA bec= ause=20 of those reasons Wim stated.   Remote LFA solves those=20 problems.  It should help to speed up the LFA deployment in the=20 field. 

 

 

Be= st=20 regards,

 

Ni= ng=20 So

Ve= rizon=20 Corporate Technology

(o= ffice) 972-729-7905

(C= ell) 972-955-0914

 

 

From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent:= =20 Wednesday, October 12, 2011 12:31 AM
To: Sriganesh Kini


Cc: Clarence Filsfils; rtgwg@ietf.org; Stew= art=20 Bryant (stbryant); So, Ning; imc.shand@googlemail.com
Subject: R= E:=20 Remote LFA

 

I = still=20 believe remote LFA has more merits for the service providers who deploy= LFA=20 and want to increase the coverage. It is not about SRLG or not. It is a= bout=20 coverage and remote LFA has the benefits that is re-uses operational=20 procedures which are in place in service providers networks today. So=20 extending them is better than introducing a complete new=20 scheme.

 

From: sriganeshkini@gmail.com [mailto:sriganeshkini@gmail.com] On Behalf Of=20 Sriganesh Kini
Sent: dinsdag 11 oktober 2011=20 22:21
To: Henderickx, Wim (Wim)
Cc: Clarence Filsfi= ls;=20 rtgwg@ietf.org; S= tewart=20 Bryant (stbryant); So, Ning; imc.shand@googlemail.com
Subject: Re: Rem= ote=20 LFA

 

About related work -

 

At the last IETF we presented draft-kini-mpls-frr-= ldp=20 that addresses additional cases where besides using a primary LSP = to a=20 remote LSR such that traffic does not loop back, it handles SRLG as=20 well.

 

On Tue, Oct 11, 2011 at 9:10 AM, Henderickx, Wim (= Wim)=20 <wim.henderickx@alcatel-lucent.com>=20 wrote:

Clarence yes I saw this in the last IETF and i bel= ieve=20 this has a lot of value


-----Original Message-----
From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Clarence=20 Filsfils
Sent: dinsdag 11 oktober 2011 18:09
To: rtgwg@ietf.org; Stew= art=20 Bryant (stbryant); So, Ning; imc.shand@googlemail.com
Subject: Remote=20 LFA

Please find the following submission complementing the LFA=20 technology:

http://www.ietf.org/id/draft-shand-remote-lfa-00.txt

It=20 drastically extends the coverage of LFA while keeping its=20 simplicity.

Cheers,
Clarence
_____________________________= __________________
rtgwg=20 mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
____= ___________________________________________
rtgwg=20 mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg<= U>



 

--
-=20 Sri


____= ___________________________________________
rtgwg=20 mailing list
rtgwg@ietf.orghttps://www.ietf.org/mailman/listinfo/rtgwg

=
--_000_8DCD771BDA4A394E9BCBA8932E839297403C933DA8ESESSCMS0363e_-- From akatlas@gmail.com Mon Oct 24 08:03:40 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F215021F8CCD for ; Mon, 24 Oct 2011 08:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sJPwGM5B290 for ; Mon, 24 Oct 2011 08:03:39 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 70C6921F8CD2 for ; Mon, 24 Oct 2011 08:03:39 -0700 (PDT) Received: by pzk34 with SMTP id 34so17157576pzk.9 for ; Mon, 24 Oct 2011 08:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=uxv7X+nX6pCRaXa69UaHv1YZEADllgRau7Q/Qx1k7Uo=; b=QwwgmseuL0wNfqtnePQboCx5H+/jbtuycH8uxhPWsBCA+TM6svcbfOGfHzgeCewDi/ 0fucwnHtpEmgHk5zTCfKEwv1Z1k21fZuSII2hKoysgsgV6vm3f8MYXg+DXNnILDY8xKF 4YaXbP6xNtj52kb7hvio46f5K04RfGfMricvQ= MIME-Version: 1.0 Received: by 10.68.73.232 with SMTP id o8mr22073544pbv.82.1319468619246; Mon, 24 Oct 2011 08:03:39 -0700 (PDT) Received: by 10.143.82.12 with HTTP; Mon, 24 Oct 2011 08:03:39 -0700 (PDT) Date: Mon, 24 Oct 2011 11:03:39 -0400 Message-ID: Subject: Requests for RTGWG agenda items From: Alia Atlas To: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=f46d041390f557ab4104b00cba52 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 15:03:41 -0000 --f46d041390f557ab4104b00cba52 Content-Type: text/plain; charset=ISO-8859-1 Please sent in your requests for RTGWG agenda items. We need to finalize the agenda by Nov 2. RTGWG will be meeting Thurs Nov 17 1300-1500 Afternoon Session I Thanks, Alia --f46d041390f557ab4104b00cba52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please sent in your requests for RTGWG agenda items.
We need to finalize= the agenda by Nov 2.

RTGWG will be meeting
=A0=A0 Thurs Nov 17 <= br>=A0=A0 1300-1500 Afternoon Session I

Thanks,
Alia
--f46d041390f557ab4104b00cba52-- From akatlas@gmail.com Mon Oct 24 15:23:30 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B127821F8C14 for ; Mon, 24 Oct 2011 15:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFqzbsG9-ayf for ; Mon, 24 Oct 2011 15:23:30 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11CBF21F8C11 for ; Mon, 24 Oct 2011 15:23:29 -0700 (PDT) Received: by iabn5 with SMTP id n5so9655795iab.31 for ; Mon, 24 Oct 2011 15:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=eFtDbXPDmolYSpmFcoSK6kqOCqQYKNlv+V3v+bwpOOE=; b=i02b4rkyGX7Gm5WmTJqU+k1nZIGimG3vhW5ZaJ1JwTytyE0dc1p6pnz+Qud1udPd9W 9ejr4XAHHnLeT3FFA1M5Pj+1DAu3+R1f1Fqufkv+3n86+FDBhEff9HafvUwT+9E6PZwB 9DyFOaBFfhYIflA1GM4oKRSsXkCXb5vtZ7zAY= MIME-Version: 1.0 Received: by 10.68.10.34 with SMTP id f2mr9427319pbb.116.1319495009296; Mon, 24 Oct 2011 15:23:29 -0700 (PDT) Received: by 10.143.82.12 with HTTP; Mon, 24 Oct 2011 15:23:29 -0700 (PDT) Date: Mon, 24 Oct 2011 18:23:29 -0400 Message-ID: Subject: MRT algorithm draft submitted From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 22:23:30 -0000 We have just submitted a draft describing the algorithm (with the associated logic and the minimal graph theory needed to understand it). The draft is draft-enyedi-rtgwg-mrt-frr-algorithm. Any feedback on the algorithm or draft would be appreciated. Thanks, Alia From bashandy@cisco.com Sun Oct 30 19:11:40 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643631F0C5A for ; Sun, 30 Oct 2011 19:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FlgY4RdrfWO for ; Sun, 30 Oct 2011 19:11:39 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 786591F0C35 for ; Sun, 30 Oct 2011 19:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=10162; q=dns/txt; s=iport; t=1320027099; x=1321236699; h=message-id:date:from:mime-version:to:subject; bh=EJrj2z+1wzn86MpuViXKQfwBt7d/TUWkge9TPfRq/p0=; b=ZY2npaWJa+X8fZiQIRhZcHuSo7p1KkgnPul3FkNvvYcNjgCJ+xirmneU XUg5rb5MoXV+Kx3jjlgE3rwXbw0c8rMS2AIhOtWTkmdouyDUFZPlCaqwW H5gnpGLqVc8TEqS9makTbh8hVeWdgOlkX0wlOR6F/8C0Gty1mJZ5vHRoV 0=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.69,428,1315180800"; d="asc'?scan'208,217";a="11306670" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 31 Oct 2011 02:11:39 +0000 Received: from [10.21.87.231] ([10.21.87.231]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9V2Bddl031630; Mon, 31 Oct 2011 02:11:39 GMT Message-ID: <4EAE03DB.5090505@cisco.com> Date: Sun, 30 Oct 2011 19:11:39 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Fwd: New Version Notification for draft-bashandy-bgp-edge-node-frr-01.txt X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC5C127D5569F12C2C8E6A9FC" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 02:11:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC5C127D5569F12C2C8E6A9FC Content-Type: multipart/alternative; boundary="------------070509010409030507050400" This is a multi-part message in MIME format. --------------070509010409030507050400 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is a draft that proposes a mechanism by which traffic can be re-routed to a pre-calculated repair egress PE if the primary egress PE becomes disconnected from the core (e.g. router crash) in a BGP free core without waiting for IGP or BGP to re-converge. The draft does not require any special routers to handle the traffic re-route and does not require core routers to have knowledge about BGP routes The new version only contains editorial modifications I only got one comment from Rob Shakir. His primary concern is that the draft requires allocating multiple prefixes to each PE to be used as BGP Next-hops. This may be a problem for deployments with constrained address space, such as deployments that do not use private addresses as BGP next-hops in BGP_free cores We are working to address Rob's concern All comments are most welcomed Ahmed -------- Original Message -------- Subject: New Version Notification for draft-bashandy-bgp-edge-node-frr-01.txt Date: Fri, 28 Oct 2011 10:50:31 -0700 From: To: Ahmed Bashandy (bashandy) CC: Ahmed Bashandy (bashandy) A new version of I-D, draft-bashandy-bgp-edge-node-frr-01.txt has been successfully submitted by Ahmed Bashandy and posted to the IETF repositor= y. Filename: draft-bashandy-bgp-edge-node-frr Revision: 01 Title: Scalable BGP FRR Protection against Edge Node Failure Creation date: 2011-10-26 WG ID: Individual Submission Number of pages: 17 Abstract: Consider a BGP free core scenario. Suppose the edge BGP speakers PE1, PE2,..., PEn know about a prefix P/p via the external routers CE1, CE2,..., CEm. If the edge router PEi crashes or becomes totally disconnected from the core, it desirable for a penultimate hop route "P" carrying traffic to the failed edge router PEi to immediate= ly restore traffic by re-tunneling packets originally tunneled to PEi and destined to the prefix P/p to one of the other edge routers that advertised P/p, say PEj, until BGP re-converges. In doing so, it is highly desirable to keep the core BGP-free while not imposing restrictions on external connectivity. Thus (1) a core router should not be required to learn any BGP prefix, (2) the size of the forwarding and routing tables in the core routers should be independent of the number of BGP prefixes,(3) there should be no special router (or group of routers) that handles restoring traffic, and (4) there should be no restrictions on what edge routers advertise what prefixes. For labeled prefixes, (5) the penultimate hop router must swap the label advertised by the failed edge router PEi for the prefix P/p with the label advertised for the same prefix by the edge router PEj before re-tunneling the packet to PEj = =20 The IETF Secretariat --------------070509010409030507050400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable New Version Notification for draft-bashandy-bgp-edge-node-frr-01.txt This is a draft that proposes a mechanism by which traffic can be re-routed to a pre-calculated repair egress PE if the primary egress PE becomes disconnected from the core (e.g. router crash) in a BGP free core without waiting for IGP or BGP to re-converge. The draft does not require any special routers to handle the traffic re-route and does not require core routers to have knowledge about BGP routes<= br>
The new version only contains editorial modifications

I only got one comment from Rob Shakir. His primary concern is that the draft requires allocating multiple prefixes to each PE to be used as BGP Next-hops. This may be a problem for deployments with constrained address space, such as=C2=A0 deployments that do not use private addresses as BGP next-hops in BGP_free cores
We are working to address Rob's concern

All comments are most welcomed

Ahmed

-------- Original Message --------
Subje= ct: New Version Notification for draft-bashandy-bgp-edge-node-frr-01.txt
Date:= Fri, 28 Oct 2011 10:50:31 -0700
From:= <internet-drafts@ietf.org>
To: <= /th> Ahmed Bashandy (bashandy) <bashandy@cisco.com>
CC: <= /th> Ahmed Bashandy (bashandy) <bashandy@cisco.com>


New Version Notification for draft-bashandy-bgp-edge-node-frr-01.txt

A new version of I-D, draft-bashandy-bgp-edge-node-frr-01.txt has been successfully submitted by Ahmed Bashandy and posted to the IETF repository.
Filename:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-bashand= y-bgp-edge-node-frr
Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 01
Title:=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sca= lable BGP FRR Protection against Edge Node Failure
Creation date:=C2=A0=C2=A0 2011-10-26
WG ID:=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ind= ividual Submission
Number of pages: 17

Abstract:
Consider a BGP free core scenario. Suppose the edge BGP speakers PE1,
PE2,..., PEn know about a prefix P/p via the external routers CE1,
CE2,..., CEm.=C2=A0 If the edge router PEi crashes or becomes tot= ally
disconnected from the core, it desirable for a penultimate hop route
&quot;P&quot; carrying traffic to the failed edge router PEi to immediately
restore traffic by re-tunneling packets originally tunneled to PEi
and destined to the prefix P/p to one of the other edge routers that
advertised P/p, say PEj, until BGP re-converges. In doing so, it is
highly desirable to keep the core BGP-free while not imposing
= restrictions on external connectivity. Thus (1) a core router should
not be required to learn any BGP prefix, (2) the size of the
forwarding and routing tables in the core routers should be
independent of the number of BGP prefixes,(3) there should be no<= br> special router (or group of routers) that handles restoring traffic,
and (4) there should be no restrictions on what edge routers
advertise what prefixes. For labeled prefixes, (5) the penultimate
hop router must swap the label advertised by the failed edge router
PEi for the prefix P/p with the label advertised for the same prefix
by the edge router PEj before re-tunneling the packet to PEj

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0


The IETF Secretariat

--------------070509010409030507050400-- --------------enigC5C127D5569F12C2C8E6A9FC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOrgPb+G19kFA5zIYRAqveAJ4gg1tVi+WjnBjBjB3Lr0yAaM80HgCdEf7o 4vOzIEbmLARX/iWsJu8dOrQ= =8Nk4 -----END PGP SIGNATURE----- --------------enigC5C127D5569F12C2C8E6A9FC-- From bashandy@cisco.com Sun Oct 30 19:16:58 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEBE11E8095; Sun, 30 Oct 2011 19:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I78LY4K4507o; Sun, 30 Oct 2011 19:16:57 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7F23111E808D; Sun, 30 Oct 2011 19:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=7334; q=dns/txt; s=iport; t=1320027417; x=1321237017; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=VOoKI9mLcNEBIPw0vZk6zpbV79cz7C8LGwnGIp+r8K8=; b=HX+cLbuWsGypaZm9v9bo0cO2Wceo4VTEW0LwGQjgv2zGvR694aRbbcvG Dj3KNLyI5uNoIIh7n44xrSYTcYtP+E4cFMdj+LQf8pPiBGiJXVWPvleqY CGFgLZOhLQ2e0QnTguNxuZcDSaZ/z1ltbh/Z1DHXVekPDO416t7TGlPGA U=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.69,428,1315180800"; d="asc'?scan'208,217";a="10127779" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 31 Oct 2011 02:16:57 +0000 Received: from [10.21.87.231] ([10.21.87.231]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9V2GvQP032262; Mon, 31 Oct 2011 02:16:57 GMT Message-ID: <4EAE0519.4050409@cisco.com> Date: Sun, 30 Oct 2011 19:16:57 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: idr@ietf.org Subject: Re: New Version Notification for draft-bashandy-idr-bgp-repair-label-03.txt References: <20111030232635.4403.33840.idtracker@ietfa.amsl.com> In-Reply-To: <20111030232635.4403.33840.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5D9E62725BC3D89F6147C3B0" Cc: "Burjiz Pithawala \(bpithaw\)" , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 02:16:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5D9E62725BC3D89F6147C3B0 Content-Type: multipart/alternative; boundary="------------040908010106040905060904" This is a multi-part message in MIME format. --------------040908010106040905060904 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is a draft proposing that an egress PE reroutes traffic, without wai= ting for BGP or IGP to re-converge, to another pre-calculated egress PE i= n a BGP-free core when the egress PE detects that the external NH is no l= onger reachable. Because traffic coming from the core is redirected back = to the core, we propose using a specially advertised label to make sure t= hat the traffic does not get re-routed multiple times into the core, thus= avoiding loops. This is a new version of the draft based on comments that we got so far The primary modification from the previous version is that repairing PEs = are only egress PEs=20 All comments are most welcomed Thanks Ahmed On 10/30/2011 4:26 PM, internet-drafts@ietf.org wrote: > > A new version of I-D, draft-bashandy-idr-bgp-repair-label-03.txt has > been successfully submitted by Ahmed Bashandy and posted to the IETF > repository. > > Filename: draft-bashandy-idr-bgp-repair-label > Revision: 03 > Title: Scalable, Loop-Free BGP FRR using Repair Label > Creation date: 2011-10-30 > WG ID: Individual Submission > Number of pages: 13 > > Abstract: > Consider a BGP free core scenario. Suppose the provider edge BGP > speakers PE1, PE2,..., PEn know about a prefix P/p via the external > routers CE1, CE2,..., CEm. If the PE router PEi loses connectivity to > the primary path, it is desirable to immediately restore traffic by > rerouting packets arriving from the core to PEi and destined to the > prefix P/p to one of the other PE routers that advertised P/p, say PEj,= > until BGP re-converges. However if the loss of connectivity of PEi to > the primary path also resulted in the loss of connectivity between PEj > and CEj, rerouting a packet before the control plane converges may > result in a loop. In this document, we propose using a repair label for= > traffic restoration while avoiding loops. We propose advertising the > "repair" label through BGP. > > = =20 > > > The IETF Secretariat > --------------040908010106040905060904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
This is a draft proposing that an egress PE reroutes t=
raffic, without waiting for BGP or IGP to re-converge, to another pre-cal=
culated egress PE in a BGP-free core when the egress PE detects that the =
external NH is no longer reachable. Because traffic coming from the core =
is redirected back to the core, we propose using a specially advertised l=
abel to make sure that the traffic does not get re-routed multiple times =
into the core, thus avoiding loops.

This is a new version of the draft based on comments that we got so far

The primary modification from the previous version is that repairing PEs =
are only egress PEs=20

All comments are most welcomed

Thanks

Ahmed


On 10/30/2011 4:26 PM, internet-drafts@ietf.org wrote:
New Version Notification fordraft-bashandy-idr-bgp-repair-label-03.txt

A new version of I-D, draft-bashandy-idr-bgp-repair-label-03.txt has been successfully submitted by Ahmed Bashandy and posted to the IETF repository.

Filename:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-basha= ndy-idr-bgp-repair-label
Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 03
Title:=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S= calable, Loop-Free BGP FRR using Repair Label
Creation date:=C2=A0=C2=A0 2011-10-30
WG ID:=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= ndividual Submission
Number of pages: 13

Abstract:
Consider a BGP free core scenario. Suppose the provider edge BGP
speakers PE1, PE2,..., PEn know about a prefix P/p via the external
routers CE1, CE2,..., CEm.=C2=A0 If the PE router PEi loses connectivity to
the primary path, it is desirable to immediately restore traffic by
rerouting packets arriving from the core to PEi and destined to the
prefix P/p to one of the other PE routers that advertised P/p, say PEj,
until BGP re-converges. However if the loss of connectivity of PEi to
the primary path also resulted in the loss of connectivity between PEj
and CEj, rerouting a packet before the control plane converges may
result in a loop. In this document, we propose using a repair label for
traffic restoration while avoiding loops. We propose advertising the
&quot;repair&quot; label through BGP.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0


The IETF Secretariat

--------------040908010106040905060904-- --------------enig5D9E62725BC3D89F6147C3B0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOrgUZ+G19kFA5zIYRAhqpAJ9OneGuyz+9VQl5+RBW4tngQcgnRgCZAamF etQN7RQDva/MaohLjkYQF6Q= =vl21 -----END PGP SIGNATURE----- --------------enig5D9E62725BC3D89F6147C3B0--