From mailman-admin@ietf.org Sun Feb 1 09:02:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11022 for ; Sun, 1 Feb 2004 09:02:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnIAs-0002Zx-NT for ssm-archive@lists.ietf.org; Sun, 01 Feb 2004 09:02:10 -0500 Date: Sun, 01 Feb 2004 09:02:10 -0500 Message-ID: <20040201140210.1364.2035.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ssm-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ssm-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ssm-archive@lists.ietf.org: List Password // URL ---- -------- ssm@ietf.org mifemu https://www1.ietf.org/mailman/options/ssm/ssm-archive%40lists.ietf.org From exim@www1.ietf.org Sun Feb 1 10:10:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21673 for ; Sun, 1 Feb 2004 10:10:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnJE5-0003Ht-Ak for ssm-archive@odin.ietf.org; Sun, 01 Feb 2004 10:09:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i11F9XPI012633 for ssm-archive@odin.ietf.org; Sun, 1 Feb 2004 10:09:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnJE5-0003Hg-6T for ssm-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 10:09:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21382 for ; Sun, 1 Feb 2004 10:09:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnJE2-0003dz-00 for ssm-web-archive@ietf.org; Sun, 01 Feb 2004 10:09:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnIft-0002yD-00 for ssm-web-archive@ietf.org; Sun, 01 Feb 2004 09:34:16 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AnIP8-0006hK-00 for ssm-web-archive@ietf.org; Sun, 01 Feb 2004 09:16:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AnIGa-0004Xp-VL for ssm-web-archive@ietf.org; Sun, 01 Feb 2004 09:08:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnIGZ-000096-LC for ssm-web-archive@ietf.org; Sun, 01 Feb 2004 09:08:03 -0500 Date: Sun, 01 Feb 2004 09:08:03 -0500 Message-ID: <20040201140803.1364.71218.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ssm-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ssm-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ssm-web-archive@ietf.org: List Password // URL ---- -------- ssm@ietf.org daemut https://www1.ietf.org/mailman/options/ssm/ssm-web-archive%40ietf.org From ssm-admin@ietf.org Mon Feb 2 02:30:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22824 for ; Mon, 2 Feb 2004 02:30:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnYWx-00058F-7D; Mon, 02 Feb 2004 02:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnYWG-000562-Jy for ssm@optimus.ietf.org; Mon, 02 Feb 2004 02:29:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22763 for ; Mon, 2 Feb 2004 02:29:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnYWC-0005Jg-00 for ssm@ietf.org; Mon, 02 Feb 2004 02:29:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnYVE-0005DY-00 for ssm@ietf.org; Mon, 02 Feb 2004 02:28:17 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AnYUH-00054Q-00 for ssm@ietf.org; Mon, 02 Feb 2004 02:27:17 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 01 Feb 2004 23:33:12 +0000 Received: from holbrook-laptop.cisco.com (sjc-vpn4-17.cisco.com [10.21.80.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i127QkgD023069 for ; Sun, 1 Feb 2004 23:26:46 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 6A5BF10B834; Sun, 1 Feb 2004 23:28:23 -0800 (PST) From: Hugh Holbrook To: ssm@ietf.org Reply-To: holbrook@cisco.com Message-Id: <20040202072823.6A5BF10B834@holbrook-laptop.cisco.com> Date: Sun, 1 Feb 2004 23:28:23 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [ssm] minutes from ssm ietf-58 in mpls Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Hi, folks. The minutes were posted in the online proceedings (http://www.ietf.org/proceedings/03nov/index.html), but I realize now that I never sent them to the mailing list. So here you go. Sorry for the delayed post. -Hugh and Supratik. -------------------------------- Agenda bashing - Hugh Presentation - Admin scoping and SSM - Hugh beau williamson: what we are seeing more and more now is extension of 239/8 down into admin scopes inside the private address space, multiple limited scopes hugh: yes, some applies recursively as well. isidor: scoped range - you don't mean group range, right? hugh: not , a scoped range is a scoped set of channels, defined by source mask, destination mask, source and destination simultaneously, etc. beau: why would you put a filter on a stub region? hugh: for example, if an enterprise, not transiting anything, does not want information to leak out, e.g., CEO giving a speech. beau: misunderstanding definition of stub - thought that stub is like a multi-access network with hosts on it. hugh: no this is more of an AS sense of a stub, a much larger topological stub. isidor: about blocking joins, I think it would be more in line with the PIM spec if instead of ignoring joins, you actually store the joins but actually don't translate them into forwarding state. because eventually if you change the filter, you may want to use existing join state that you may have. hugh: yes. dino: ssm on 232/8 - is that assuming the type of routing protocol that will be used for those ranges. so if you are using a dense-mode protocol you cannot filter joins. hugh: if you are using dense-mode protocol at the boundary, then that is a good point, you have to filter the traffic. The draft says that you have to prevent the traffic from going out - either by filtering joins or filtering traffic. dino: so it will be nice for the spec to say that you can do control plane or data plane filtering. hugh: yes, out of curiousity, is anybody doing SSM with dense mode? hugh: some other alternatives not mentioned in the draft - includes allowing the address range to float in 232/8. a lot of entities need to know of this range. isidor: and you still need to the API to request a scoped address. hugh: yes, so this a property of any proposal. hugh: so how do you make this consistent. Another choice is to fix a range within 232/8. Cannot make it too small to avoid collapsing on a small set of ethernet addresses. hugh: comments?? toerless: would like to see the first option (above) to be considered as an alternative. We are not talking ssm-specific, but ipv4-specific. there is not much of a problem with allocating 239 range configured properly. that is much of the ssm we are seeing today. with the proposal, you have to understan how to correctly configure the filters. the normal approach of allocating an address range is simpler. would not want ssm to be restricted to 232/8. hugh: not suggesting not doing ssm outside 232/8, but there are certain ramifications, would not want the ietf to go down the path. beau: two things - one is the ability to use 232/8 as SSM or not; other is the use of filtering other than group-based. hugh: the draft actually addresses the second point. beau: it leads to a discussion of the second point. can you explain the group-based bi-directional boundary approach is inadequate, and we have to have the uni-directional, more elaborate filtering mechanism? what problem are you fixing. isidor: the bi-directional one breaks the transit case. hugh: the destination-based breaks the transit case; and the bi-directional breaks the case that you want to listen to a source outside your domain. beau: don't see how it is different from an ASM model when you switch over to a shortest path tree. if you have a domain boundary on a group address range, you are going to block either the data flow or the control packet flow from entering or leaving the boundary. This is already implemented, and it works. hugh: I decide that I am putting all my company stuff on an internal source 232.239, and decide to block it. Now there is an external source transmitting interesting stuff, and I don't want to block it from coming in. pekka: don't see a problem in the transit case. don't see why a transit AS would want to block. other problem - how to do it v6, because v6 already has scoping, so would this be useful? two issues - whether we want to do something like this for v6, and do we want to be able to scope ssm v6 multicast with the source and destination in global scope. hugh: if you want to do the latter, then you have to do something like this p roposal. dave thaler: about the two proposals. if the first one requires additional protocol stuff, then hugh's proposal is better. the problem with the current draft is title - should say ipv4. hugh: could apply to v6. dave: don't want it to apply to v6. other thing - there is nothing that says that it is illegal for the app to use the include mode in the 239 range. brian haberman: like this proposal better. gets rid of the machinery. for v6, we are better off using the scope in the multicast address. so change the title, no other problem. john meylor: as long as the app can use include mode in 239 range, then that is the most important component brought out in the draft, because after that you can do pretty much anything in your own admin domain. key thing to specify that if you are doing anything outside of 239 in a transit networl, then you allow for transit to pass through. toerless: scope identified by group range is simpler, hugh's option is doable but complex. it is doable, academically interesting. don't need it for v6. this pr hugh: what do you want? toerless: don't want anything coming out of this process that is more complex. hugh: source filtering only in transit case, otherwise always destination. what would you do? toerless: a draft should outline all the alternatives for scoping for v4 multicast, without expressing a preference for any one. would go for 239/8 sub-ranges that are allocated by local authorities. dino: if you had group range filtering only, would that make you happy? toerless: yes. dino: just say you can optionally do source-based filtering as well. john meylor: the important point here - whatever range we scope on, when you arrive on a transit network, you can predict your behavior. in the scoped domain, as long as you can use include mode in the application, you can pretty much do what you want. nothing that the ietf has to dictate about that. nothing that precludes toerless point other than if you are going to recommend that within the 232 range you have scoped behavior, then you have to make it clear to the transit provider that if they are going to apply scoped behavior on the 232 range, they have to allow for transit. and that is what dictates the uni-directional filter. hugh: agreed. pekka: seems like if we do ssm inside 239, we will also have to leave the option to specify in the protocol stack where we want to do ssm. would be much better to glue those in when you design the protocol. an option may be to use 231, will that be better. hugh: well we could take half of 232. toerless: for v4, one additional scope for a private enterprise,maybe that is a simple compromise to give leeway to people that design protocols and cannot be bothered with the ssm range. not a strong argument, but if that is what the ietf wants... hugh: not just the protocols, reduces configuration burden. toerless: limiting the scope of the application is a primary security concerns of every scoped definition. so putting effort into that is considered a part of the securities definition of a network. so there is not that much of a problem getting work done on that as opposed to other work on multicast. beau: we are not gaining anything. the only advantage is that we have two range - inter-domain 232/8 always transit. the other is a well-known for ssm but private. don't care where it comes from. still have the problem of configuring the network. hugh: reduces the problem of where to configure for ssm behaviour. beua: no it doesn't because inside an enterprise you will have different scopes, and those boundaries are going to be arbitrary. so there is a lot of admin going on in terms of where the boundaries. hugh: but this avoids configuring other things like RPs, DRs. this is not necessarily to ease the configuration of boundaries. beau: so, lock it down into two - inter-domain and intra-domain (carve up the way you want) and then use group-based boundaries. unknown (used to be an operator): don't mess with 239, because it will be nice to sketch out a scenario where a router gets shipped out to an enterprise which by default would have useful behaviour, e.g., 239 is admin scoped, etc. i.e., something reasonable out of the box, if the enterprise wants something more clever, they can do it. toerless: how about just to be able the same scope boundaries in a dual mode network simply use the high-order 4 bits of the third byte to have the same scope levels as an ipv6 so that you can use the same boundaries when you will be building an enterprise network hugh: guess you are cutting your address space down. toerless: how many channels do you need? hug: there is an ethernet collision issue. toerless: well, the ietf made a decision about v6. tradeoff between simplicity and freedom. boundaries not that simple. dave thaler: half convinced, half not that there is an issue. what do we expect the apps to do? first, the app has to pick an address G and there has to be a filter in the router. which happens first? hugh: filter in the router. dave : in that case, how does the app pick an address? hugh: either the user has to know, CLI or on the box or something. Or you have a protocol mechanism. dave: don't like either of those. that is why it is good to pick a sub-range of 232/8 or 239. hugh: but it is not good as an application user to rely on scoping simply because the ietf says so. dave: true. if you use 231/8, you can use the same subnetting scheme, which is what ipv6 is doing for different types of prefixes. your breakdown within the /8 could be the same. what is the scoped divisions for 239 - there is a protocol for that. 50% convinced of toerless and beau's point. in your proposal, you _have_ to do coordination. hugh: anyone has a sense how it is difficult to get a /8 for multicast. toerless: just worried that if it does not say clearly that other address ranges must be supported to allow for scoping, then this may fall over. in the end, there may be apps that can only do ssm with additional protocols in 232. bit paranoid, but has been known to happen in the past. hugh: is the concept of a /25 too hard? can we split the space in half? would be backward compatible with anyone doing ssm today. tom: thinking of deployment, if you want to go to admin scoped you have to configure border routers. already done in 239 range, so let people do what they want there. hugh: gotta worry whether things like msnip - would it work in 239 space? tom: we have the ability to configure additional range of ssm space - then we have to configure all routers. beau; but you already have a problem like that today. you still have people building ASM/bidir admin scoped ranges inside the 239 range. so how do communicate and configure the application so that it uses the appropriate scoped range address for (1)what the app was designed to do (2) what the network administrator wants the scope to be for that particular app. so...pick some ranges in 239 so that you can do the same. you have to configure the routers to let them know which range within 239, which you have to do at the boundaries. so it is a part of the configuration. louis: but the no. of boundaries is smaller than all routers. toerless: ssm in ip4 with admin scoping must have all the benefits of global scope, not partial suppirt. End of presentation - admin scoping and SSM. Presentation: SSM architecture draft and IPR - Hugh hugh: possible next steps for ssm - comments?? toerless: go forward. to what degree does the risk factor also apply to other protocols - e.g., igmpv3. or take PIM - if you get an (S,G) from IGMP, does it fall under the IPR. and that could be ASM not even SSM. hugh: could be interpreted to cover any case where receiver specifies source. toerless: so include mode in igmpv3. hugh: yes. alex: if it is standardized, then licenses will be available. does not say what if it is not standardized. tom: if they are not claiming igmpv3 and pim, then why this? hugh: they are only required to notify if they know specific technology is IPR-impacted. tom: by not notifying, they are giving up their rights. hugh: not true. pekka: they are not required to give any terms or disclose anything unless they take par in the deliberations reg. the technology. not sure if people from apple have been talking about igmp or ssm, etc. They are probably giving it away for free, they don't have to. The reason that they are doing this for ssm not igmp is that they picked something source-specific. Personal belief: must not go for proposed standard. try to gather more information. try to get royalty-free, see later how to proceed. hugh: approached apple, not very receptive. bill fenner: what is different from if apple had waited until after the rfc came out. pekka: not much of difference. qn here : now that we know about it, should we do something. depends on how much of backchannel with apple. dino: claims are very general - e.g. transmitting data with a computer, joining group. patent was filed in 94, first pim rfc in 97. bill: options are: investigate validity or force them to license. only judge can judge validity. it is a judgement call, not for us. so remove validity from the table. not going to say that this patent is invalid. on licensing tierms, we have no leverage. dino: apple lawyers are not stupid - have to go after ciso, microsoft. bill; they don't have to go after anyone, pick and choose what they want to enforce. can't see any forward progress with step 2 (checking validity). pekka: is there any chance of prior art? bill: very little, based on the timing. hugh: maybe we can dig up some emails? bill: prior art in itself does not do anything. it is the opinion of the judge taking prior art into account. brian haberman: only choice seems 1. so go on, and see what they do. hugh: need two implementations to fo to draft standard. need license for implementations, at which point the decision will be automatically made. john meylor: go forward. toerless: can the text be changed to be less specific to the IPR. hugh: not likely to work. bill: is there anyone who would absolutely not implement it if there was IPR onit? it is in bsd. pekka: would not put it in linux. unknown: has anyone licensed? bill: don't know. apple supports open source. hugh: incredibly strong licensing statement for W3C. pekka: regarding w3C, members of w3C have been arm-twisted to provide royalty-free statements, the process here is different. alex: to move forward, ask the room: who believes that the group is ready to make a decision, and who believes that we need more information and discuss at the next meeting. john meylor: nothing illegal to move it to proposed standard. what needs to be thought about is whether people would want to implement the draft after that? do people think there is anything wrong with the document? else, go forward. hugh: who thinks we need more time 2 hands hugh: who thinks we should go forward numerous hands hugh: who thinks we have enough information to decide not to go forward. none. hugh: so we will take this discussion to the list. _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From exim@www1.ietf.org Mon Feb 2 02:31:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22985 for ; Mon, 2 Feb 2004 02:31:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnYYH-0005TT-Vj for ssm-archive@odin.ietf.org; Mon, 02 Feb 2004 02:31:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i127VPXh021042 for ssm-archive@odin.ietf.org; Mon, 2 Feb 2004 02:31:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnYYH-0005TJ-HV for ssm-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 02:31:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22974 for ; Mon, 2 Feb 2004 02:31:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnYYD-0005cI-00 for ssm-web-archive@ietf.org; Mon, 02 Feb 2004 02:31:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnYXF-0005X6-00 for ssm-web-archive@ietf.org; Mon, 02 Feb 2004 02:30:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnYX0-0005ST-00 for ssm-web-archive@ietf.org; Mon, 02 Feb 2004 02:30:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnYWx-00058F-7D; Mon, 02 Feb 2004 02:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnYWG-000562-Jy for ssm@optimus.ietf.org; Mon, 02 Feb 2004 02:29:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22763 for ; Mon, 2 Feb 2004 02:29:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnYWC-0005Jg-00 for ssm@ietf.org; Mon, 02 Feb 2004 02:29:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnYVE-0005DY-00 for ssm@ietf.org; Mon, 02 Feb 2004 02:28:17 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AnYUH-00054Q-00 for ssm@ietf.org; Mon, 02 Feb 2004 02:27:17 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 01 Feb 2004 23:33:12 +0000 Received: from holbrook-laptop.cisco.com (sjc-vpn4-17.cisco.com [10.21.80.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i127QkgD023069 for ; Sun, 1 Feb 2004 23:26:46 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 6A5BF10B834; Sun, 1 Feb 2004 23:28:23 -0800 (PST) From: Hugh Holbrook To: ssm@ietf.org Reply-To: holbrook@cisco.com Message-Id: <20040202072823.6A5BF10B834@holbrook-laptop.cisco.com> Date: Sun, 1 Feb 2004 23:28:23 -0800 (PST) Subject: [ssm] minutes from ssm ietf-58 in mpls Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, folks. The minutes were posted in the online proceedings (http://www.ietf.org/proceedings/03nov/index.html), but I realize now that I never sent them to the mailing list. So here you go. Sorry for the delayed post. -Hugh and Supratik. -------------------------------- Agenda bashing - Hugh Presentation - Admin scoping and SSM - Hugh beau williamson: what we are seeing more and more now is extension of 239/8 down into admin scopes inside the private address space, multiple limited scopes hugh: yes, some applies recursively as well. isidor: scoped range - you don't mean group range, right? hugh: not , a scoped range is a scoped set of channels, defined by source mask, destination mask, source and destination simultaneously, etc. beau: why would you put a filter on a stub region? hugh: for example, if an enterprise, not transiting anything, does not want information to leak out, e.g., CEO giving a speech. beau: misunderstanding definition of stub - thought that stub is like a multi-access network with hosts on it. hugh: no this is more of an AS sense of a stub, a much larger topological stub. isidor: about blocking joins, I think it would be more in line with the PIM spec if instead of ignoring joins, you actually store the joins but actually don't translate them into forwarding state. because eventually if you change the filter, you may want to use existing join state that you may have. hugh: yes. dino: ssm on 232/8 - is that assuming the type of routing protocol that will be used for those ranges. so if you are using a dense-mode protocol you cannot filter joins. hugh: if you are using dense-mode protocol at the boundary, then that is a good point, you have to filter the traffic. The draft says that you have to prevent the traffic from going out - either by filtering joins or filtering traffic. dino: so it will be nice for the spec to say that you can do control plane or data plane filtering. hugh: yes, out of curiousity, is anybody doing SSM with dense mode? hugh: some other alternatives not mentioned in the draft - includes allowing the address range to float in 232/8. a lot of entities need to know of this range. isidor: and you still need to the API to request a scoped address. hugh: yes, so this a property of any proposal. hugh: so how do you make this consistent. Another choice is to fix a range within 232/8. Cannot make it too small to avoid collapsing on a small set of ethernet addresses. hugh: comments?? toerless: would like to see the first option (above) to be considered as an alternative. We are not talking ssm-specific, but ipv4-specific. there is not much of a problem with allocating 239 range configured properly. that is much of the ssm we are seeing today. with the proposal, you have to understan how to correctly configure the filters. the normal approach of allocating an address range is simpler. would not want ssm to be restricted to 232/8. hugh: not suggesting not doing ssm outside 232/8, but there are certain ramifications, would not want the ietf to go down the path. beau: two things - one is the ability to use 232/8 as SSM or not; other is the use of filtering other than group-based. hugh: the draft actually addresses the second point. beau: it leads to a discussion of the second point. can you explain the group-based bi-directional boundary approach is inadequate, and we have to have the uni-directional, more elaborate filtering mechanism? what problem are you fixing. isidor: the bi-directional one breaks the transit case. hugh: the destination-based breaks the transit case; and the bi-directional breaks the case that you want to listen to a source outside your domain. beau: don't see how it is different from an ASM model when you switch over to a shortest path tree. if you have a domain boundary on a group address range, you are going to block either the data flow or the control packet flow from entering or leaving the boundary. This is already implemented, and it works. hugh: I decide that I am putting all my company stuff on an internal source 232.239, and decide to block it. Now there is an external source transmitting interesting stuff, and I don't want to block it from coming in. pekka: don't see a problem in the transit case. don't see why a transit AS would want to block. other problem - how to do it v6, because v6 already has scoping, so would this be useful? two issues - whether we want to do something like this for v6, and do we want to be able to scope ssm v6 multicast with the source and destination in global scope. hugh: if you want to do the latter, then you have to do something like this p roposal. dave thaler: about the two proposals. if the first one requires additional protocol stuff, then hugh's proposal is better. the problem with the current draft is title - should say ipv4. hugh: could apply to v6. dave: don't want it to apply to v6. other thing - there is nothing that says that it is illegal for the app to use the include mode in the 239 range. brian haberman: like this proposal better. gets rid of the machinery. for v6, we are better off using the scope in the multicast address. so change the title, no other problem. john meylor: as long as the app can use include mode in 239 range, then that is the most important component brought out in the draft, because after that you can do pretty much anything in your own admin domain. key thing to specify that if you are doing anything outside of 239 in a transit networl, then you allow for transit to pass through. toerless: scope identified by group range is simpler, hugh's option is doable but complex. it is doable, academically interesting. don't need it for v6. this pr hugh: what do you want? toerless: don't want anything coming out of this process that is more complex. hugh: source filtering only in transit case, otherwise always destination. what would you do? toerless: a draft should outline all the alternatives for scoping for v4 multicast, without expressing a preference for any one. would go for 239/8 sub-ranges that are allocated by local authorities. dino: if you had group range filtering only, would that make you happy? toerless: yes. dino: just say you can optionally do source-based filtering as well. john meylor: the important point here - whatever range we scope on, when you arrive on a transit network, you can predict your behavior. in the scoped domain, as long as you can use include mode in the application, you can pretty much do what you want. nothing that the ietf has to dictate about that. nothing that precludes toerless point other than if you are going to recommend that within the 232 range you have scoped behavior, then you have to make it clear to the transit provider that if they are going to apply scoped behavior on the 232 range, they have to allow for transit. and that is what dictates the uni-directional filter. hugh: agreed. pekka: seems like if we do ssm inside 239, we will also have to leave the option to specify in the protocol stack where we want to do ssm. would be much better to glue those in when you design the protocol. an option may be to use 231, will that be better. hugh: well we could take half of 232. toerless: for v4, one additional scope for a private enterprise,maybe that is a simple compromise to give leeway to people that design protocols and cannot be bothered with the ssm range. not a strong argument, but if that is what the ietf wants... hugh: not just the protocols, reduces configuration burden. toerless: limiting the scope of the application is a primary security concerns of every scoped definition. so putting effort into that is considered a part of the securities definition of a network. so there is not that much of a problem getting work done on that as opposed to other work on multicast. beau: we are not gaining anything. the only advantage is that we have two range - inter-domain 232/8 always transit. the other is a well-known for ssm but private. don't care where it comes from. still have the problem of configuring the network. hugh: reduces the problem of where to configure for ssm behaviour. beua: no it doesn't because inside an enterprise you will have different scopes, and those boundaries are going to be arbitrary. so there is a lot of admin going on in terms of where the boundaries. hugh: but this avoids configuring other things like RPs, DRs. this is not necessarily to ease the configuration of boundaries. beau: so, lock it down into two - inter-domain and intra-domain (carve up the way you want) and then use group-based boundaries. unknown (used to be an operator): don't mess with 239, because it will be nice to sketch out a scenario where a router gets shipped out to an enterprise which by default would have useful behaviour, e.g., 239 is admin scoped, etc. i.e., something reasonable out of the box, if the enterprise wants something more clever, they can do it. toerless: how about just to be able the same scope boundaries in a dual mode network simply use the high-order 4 bits of the third byte to have the same scope levels as an ipv6 so that you can use the same boundaries when you will be building an enterprise network hugh: guess you are cutting your address space down. toerless: how many channels do you need? hug: there is an ethernet collision issue. toerless: well, the ietf made a decision about v6. tradeoff between simplicity and freedom. boundaries not that simple. dave thaler: half convinced, half not that there is an issue. what do we expect the apps to do? first, the app has to pick an address G and there has to be a filter in the router. which happens first? hugh: filter in the router. dave : in that case, how does the app pick an address? hugh: either the user has to know, CLI or on the box or something. Or you have a protocol mechanism. dave: don't like either of those. that is why it is good to pick a sub-range of 232/8 or 239. hugh: but it is not good as an application user to rely on scoping simply because the ietf says so. dave: true. if you use 231/8, you can use the same subnetting scheme, which is what ipv6 is doing for different types of prefixes. your breakdown within the /8 could be the same. what is the scoped divisions for 239 - there is a protocol for that. 50% convinced of toerless and beau's point. in your proposal, you _have_ to do coordination. hugh: anyone has a sense how it is difficult to get a /8 for multicast. toerless: just worried that if it does not say clearly that other address ranges must be supported to allow for scoping, then this may fall over. in the end, there may be apps that can only do ssm with additional protocols in 232. bit paranoid, but has been known to happen in the past. hugh: is the concept of a /25 too hard? can we split the space in half? would be backward compatible with anyone doing ssm today. tom: thinking of deployment, if you want to go to admin scoped you have to configure border routers. already done in 239 range, so let people do what they want there. hugh: gotta worry whether things like msnip - would it work in 239 space? tom: we have the ability to configure additional range of ssm space - then we have to configure all routers. beau; but you already have a problem like that today. you still have people building ASM/bidir admin scoped ranges inside the 239 range. so how do communicate and configure the application so that it uses the appropriate scoped range address for (1)what the app was designed to do (2) what the network administrator wants the scope to be for that particular app. so...pick some ranges in 239 so that you can do the same. you have to configure the routers to let them know which range within 239, which you have to do at the boundaries. so it is a part of the configuration. louis: but the no. of boundaries is smaller than all routers. toerless: ssm in ip4 with admin scoping must have all the benefits of global scope, not partial suppirt. End of presentation - admin scoping and SSM. Presentation: SSM architecture draft and IPR - Hugh hugh: possible next steps for ssm - comments?? toerless: go forward. to what degree does the risk factor also apply to other protocols - e.g., igmpv3. or take PIM - if you get an (S,G) from IGMP, does it fall under the IPR. and that could be ASM not even SSM. hugh: could be interpreted to cover any case where receiver specifies source. toerless: so include mode in igmpv3. hugh: yes. alex: if it is standardized, then licenses will be available. does not say what if it is not standardized. tom: if they are not claiming igmpv3 and pim, then why this? hugh: they are only required to notify if they know specific technology is IPR-impacted. tom: by not notifying, they are giving up their rights. hugh: not true. pekka: they are not required to give any terms or disclose anything unless they take par in the deliberations reg. the technology. not sure if people from apple have been talking about igmp or ssm, etc. They are probably giving it away for free, they don't have to. The reason that they are doing this for ssm not igmp is that they picked something source-specific. Personal belief: must not go for proposed standard. try to gather more information. try to get royalty-free, see later how to proceed. hugh: approached apple, not very receptive. bill fenner: what is different from if apple had waited until after the rfc came out. pekka: not much of difference. qn here : now that we know about it, should we do something. depends on how much of backchannel with apple. dino: claims are very general - e.g. transmitting data with a computer, joining group. patent was filed in 94, first pim rfc in 97. bill: options are: investigate validity or force them to license. only judge can judge validity. it is a judgement call, not for us. so remove validity from the table. not going to say that this patent is invalid. on licensing tierms, we have no leverage. dino: apple lawyers are not stupid - have to go after ciso, microsoft. bill; they don't have to go after anyone, pick and choose what they want to enforce. can't see any forward progress with step 2 (checking validity). pekka: is there any chance of prior art? bill: very little, based on the timing. hugh: maybe we can dig up some emails? bill: prior art in itself does not do anything. it is the opinion of the judge taking prior art into account. brian haberman: only choice seems 1. so go on, and see what they do. hugh: need two implementations to fo to draft standard. need license for implementations, at which point the decision will be automatically made. john meylor: go forward. toerless: can the text be changed to be less specific to the IPR. hugh: not likely to work. bill: is there anyone who would absolutely not implement it if there was IPR onit? it is in bsd. pekka: would not put it in linux. unknown: has anyone licensed? bill: don't know. apple supports open source. hugh: incredibly strong licensing statement for W3C. pekka: regarding w3C, members of w3C have been arm-twisted to provide royalty-free statements, the process here is different. alex: to move forward, ask the room: who believes that the group is ready to make a decision, and who believes that we need more information and discuss at the next meeting. john meylor: nothing illegal to move it to proposed standard. what needs to be thought about is whether people would want to implement the draft after that? do people think there is anything wrong with the document? else, go forward. hugh: who thinks we need more time 2 hands hugh: who thinks we should go forward numerous hands hugh: who thinks we have enough information to decide not to go forward. none. hugh: so we will take this discussion to the list. _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Thu Feb 12 01:48:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27633 for ; Thu, 12 Feb 2004 01:48:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAdl-0001xz-HM; Thu, 12 Feb 2004 01:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAdj-0001xa-1x for ssm@optimus.ietf.org; Thu, 12 Feb 2004 01:47:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27608 for ; Thu, 12 Feb 2004 01:47:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArAdf-0004CB-00 for ssm@ietf.org; Thu, 12 Feb 2004 01:47:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArAck-000473-00 for ssm@ietf.org; Thu, 12 Feb 2004 01:46:59 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ArAc4-0003xP-00; Thu, 12 Feb 2004 01:46:16 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2004 22:53:28 +0000 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1C6jau7013976; Wed, 11 Feb 2004 22:45:45 -0800 (PST) Received: from holbrook-laptop.cisco.com (gorilla.cisco.com [171.69.23.149]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APC77846; Wed, 11 Feb 2004 22:43:46 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id BDBD910B834; Wed, 11 Feb 2004 22:45:31 -0800 (PST) From: Hugh Holbrook To: ssm@ietf.org Cc: rtg-dir@ietf.org, zinin@psg.com, fenner@research.att.com, holbrook@cisco.com, supratik@sprintlabs.com Reply-To: holbrook@cisco.com Message-Id: <20040212064531.BDBD910B834@holbrook-laptop.cisco.com> Date: Wed, 11 Feb 2004 22:45:31 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ssm] last call for draft-ietf-ssm-arch-04.txt Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Hello everyone., At the last meeting of SSM (in Minneapolis, IETF-58) we had a discussion about draft-ietf-ssm-arch-04.txt that I am hoping we can now bring to a close. In Minneapolis, we discussed whether the draft was ready to advance to the IESG as a STD track document. The discussion centered around the point of whether the IPR claim statement put forth by Apple should delay the document from being advanced to the IESG for consideration as a Proposed Standard. There was clear consensus that the draft was ready to advance on technical grounds. The primary argument made for not advancing the document, was that, by not advancing at this time, we might have a better chance of getting the IPR claimant to change their licensing statement. However, we did not come up with any concrete ideas for achieving this or any explanation of how the delay would help. All but two people who spoke up were of the opinion that the document should advance immediately. It is the opinion of the chairs that the consensus in the room (two dissenting voices acknowledged) was to advance the document. So the purpose of this mail is to ratify that decision on the mailing list, so we can get moving with the next phase of the process. If anyone on the list has reason to think that the standardization process should be delayed, then please speak up now with your reasons. After two weeks with no dissent, this document will be submitted to the IESG for consideration as a Proposed Standard. Thanks! -Hugh and Supratik _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From exim@www1.ietf.org Thu Feb 12 01:50:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27734 for ; Thu, 12 Feb 2004 01:50:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAfe-00024R-Tz for ssm-archive@odin.ietf.org; Thu, 12 Feb 2004 01:49:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C6nwU0007953 for ssm-archive@odin.ietf.org; Thu, 12 Feb 2004 01:49:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAfe-00024C-Pz for ssm-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 01:49:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27717 for ; Thu, 12 Feb 2004 01:49:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArAfb-0004Ns-00 for ssm-web-archive@ietf.org; Thu, 12 Feb 2004 01:49:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArAef-0004IQ-00 for ssm-web-archive@ietf.org; Thu, 12 Feb 2004 01:48:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArAdm-0004DE-00 for ssm-web-archive@ietf.org; Thu, 12 Feb 2004 01:48:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAdl-0001xz-HM; Thu, 12 Feb 2004 01:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAdj-0001xa-1x for ssm@optimus.ietf.org; Thu, 12 Feb 2004 01:47:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27608 for ; Thu, 12 Feb 2004 01:47:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArAdf-0004CB-00 for ssm@ietf.org; Thu, 12 Feb 2004 01:47:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArAck-000473-00 for ssm@ietf.org; Thu, 12 Feb 2004 01:46:59 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ArAc4-0003xP-00; Thu, 12 Feb 2004 01:46:16 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2004 22:53:28 +0000 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1C6jau7013976; Wed, 11 Feb 2004 22:45:45 -0800 (PST) Received: from holbrook-laptop.cisco.com (gorilla.cisco.com [171.69.23.149]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APC77846; Wed, 11 Feb 2004 22:43:46 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id BDBD910B834; Wed, 11 Feb 2004 22:45:31 -0800 (PST) From: Hugh Holbrook To: ssm@ietf.org Cc: rtg-dir@ietf.org, zinin@psg.com, fenner@research.att.com, holbrook@cisco.com, supratik@sprintlabs.com Reply-To: holbrook@cisco.com Message-Id: <20040212064531.BDBD910B834@holbrook-laptop.cisco.com> Date: Wed, 11 Feb 2004 22:45:31 -0800 (PST) Subject: [ssm] last call for draft-ietf-ssm-arch-04.txt Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hello everyone., At the last meeting of SSM (in Minneapolis, IETF-58) we had a discussion about draft-ietf-ssm-arch-04.txt that I am hoping we can now bring to a close. In Minneapolis, we discussed whether the draft was ready to advance to the IESG as a STD track document. The discussion centered around the point of whether the IPR claim statement put forth by Apple should delay the document from being advanced to the IESG for consideration as a Proposed Standard. There was clear consensus that the draft was ready to advance on technical grounds. The primary argument made for not advancing the document, was that, by not advancing at this time, we might have a better chance of getting the IPR claimant to change their licensing statement. However, we did not come up with any concrete ideas for achieving this or any explanation of how the delay would help. All but two people who spoke up were of the opinion that the document should advance immediately. It is the opinion of the chairs that the consensus in the room (two dissenting voices acknowledged) was to advance the document. So the purpose of this mail is to ratify that decision on the mailing list, so we can get moving with the next phase of the process. If anyone on the list has reason to think that the standardization process should be delayed, then please speak up now with your reasons. After two weeks with no dissent, this document will be submitted to the IESG for consideration as a Proposed Standard. Thanks! -Hugh and Supratik _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Tue Feb 17 03:33:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16625 for ; Tue, 17 Feb 2004 03:33:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0f8-0004tJ-Lg; Tue, 17 Feb 2004 03:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0eS-0004nR-Gd for ssm@optimus.ietf.org; Tue, 17 Feb 2004 03:32:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16554 for ; Tue, 17 Feb 2004 03:32:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At0eQ-0001ZW-00 for ssm@ietf.org; Tue, 17 Feb 2004 03:32:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At0d8-0001T9-00 for ssm@ietf.org; Tue, 17 Feb 2004 03:30:59 -0500 Received: from cosmos.kaist.ac.kr ([192.249.24.2]) by ietf-mx with esmtp (Exim 4.12) id 1At0ch-0001Pl-00 for ssm@ietf.org; Tue, 17 Feb 2004 03:30:31 -0500 Received: from cosmos.kaist.ac.kr (localhost.kaist.ac.kr [127.0.0.1]) by cosmos.kaist.ac.kr (8.12.2/8.9.3) with ESMTP id i1H8FvSD002959; Tue, 17 Feb 2004 17:15:57 +0900 (KST) Received: (from hkpark@localhost) by cosmos.kaist.ac.kr (8.12.2/8.12.2/Submit) id i1H8FuBk002958; Tue, 17 Feb 2004 17:15:56 +0900 (KST) (envelope-from hkpark) Message-ID: <20040217171556.E2599@cosmos.kaist.ac.kr> Date: Tue, 17 Feb 2004 17:15:56 +0900 From: Heonkyu Park To: ssm@ietf.org Cc: Heonkyu Park Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ssm] unscribe this maillist Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , unscribe this maillist, thank you _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From exim@www1.ietf.org Tue Feb 17 03:35:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16746 for ; Tue, 17 Feb 2004 03:35:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0h9-0005HD-UA for ssm-archive@odin.ietf.org; Tue, 17 Feb 2004 03:35:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H8Z7DR020277 for ssm-archive@odin.ietf.org; Tue, 17 Feb 2004 03:35:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0h9-0005Gy-J9 for ssm-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 03:35:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16717 for ; Tue, 17 Feb 2004 03:35:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At0h7-0001z1-00 for ssm-web-archive@ietf.org; Tue, 17 Feb 2004 03:35:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At0g9-0001pL-00 for ssm-web-archive@ietf.org; Tue, 17 Feb 2004 03:34:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At0fA-0001g1-00 for ssm-web-archive@ietf.org; Tue, 17 Feb 2004 03:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0f8-0004tJ-Lg; Tue, 17 Feb 2004 03:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0eS-0004nR-Gd for ssm@optimus.ietf.org; Tue, 17 Feb 2004 03:32:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16554 for ; Tue, 17 Feb 2004 03:32:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At0eQ-0001ZW-00 for ssm@ietf.org; Tue, 17 Feb 2004 03:32:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At0d8-0001T9-00 for ssm@ietf.org; Tue, 17 Feb 2004 03:30:59 -0500 Received: from cosmos.kaist.ac.kr ([192.249.24.2]) by ietf-mx with esmtp (Exim 4.12) id 1At0ch-0001Pl-00 for ssm@ietf.org; Tue, 17 Feb 2004 03:30:31 -0500 Received: from cosmos.kaist.ac.kr (localhost.kaist.ac.kr [127.0.0.1]) by cosmos.kaist.ac.kr (8.12.2/8.9.3) with ESMTP id i1H8FvSD002959; Tue, 17 Feb 2004 17:15:57 +0900 (KST) Received: (from hkpark@localhost) by cosmos.kaist.ac.kr (8.12.2/8.12.2/Submit) id i1H8FuBk002958; Tue, 17 Feb 2004 17:15:56 +0900 (KST) (envelope-from hkpark) Message-ID: <20040217171556.E2599@cosmos.kaist.ac.kr> Date: Tue, 17 Feb 2004 17:15:56 +0900 From: Heonkyu Park To: ssm@ietf.org Cc: Heonkyu Park Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i Subject: [ssm] unscribe this maillist Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 unscribe this maillist, thank you _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Feb 18 09:14:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11668 for ; Wed, 18 Feb 2004 09:14:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSSf-0001I3-2G; Wed, 18 Feb 2004 09:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSSY-0001H4-79 for ssm@optimus.ietf.org; Wed, 18 Feb 2004 09:13:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11653 for ; Wed, 18 Feb 2004 09:13:51 -0500 (EST) From: aboudani@irisa.fr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtSSW-0000vr-00 for ssm@ietf.org; Wed, 18 Feb 2004 09:13:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtSRd-0000so-00 for ssm@ietf.org; Wed, 18 Feb 2004 09:12:57 -0500 Received: from n00136.com205.phs.yoyogi.mopera.ne.jp ([211.14.99.136] helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1AtSQw-0000q2-00 for ssm@ietf.org; Wed, 18 Feb 2004 09:12:15 -0500 To: ssm@ietf.org Date: Wed, 18 Feb 2004 23:07:45 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="62474857" Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.6 required=5.0 tests=MSGID_FROM_MTA_SHORT, NO_REAL_NAME autolearn=no version=2.60 Subject: [ssm] stolen Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , --62474857 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit you feel the same --62474857 Content-Type: application/x-zip-compressed; name="friend.zip" Content-Disposition: attachment; filename="friend.zip" Content-Transfer-Encoding: base64 --62474857-- _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From exim@www1.ietf.org Wed Feb 18 09:16:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11764 for ; Wed, 18 Feb 2004 09:16:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSUf-0001Pg-9t for ssm-archive@odin.ietf.org; Wed, 18 Feb 2004 09:16:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IEG53u005428 for ssm-archive@odin.ietf.org; Wed, 18 Feb 2004 09:16:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSUf-0001PT-4t for ssm-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 09:16:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11741 for ; Wed, 18 Feb 2004 09:16:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtSUd-00016T-00 for ssm-web-archive@ietf.org; Wed, 18 Feb 2004 09:16:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtSTg-000126-00 for ssm-web-archive@ietf.org; Wed, 18 Feb 2004 09:15:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtSSj-0000xz-00 for ssm-web-archive@ietf.org; Wed, 18 Feb 2004 09:14:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSSf-0001I3-2G; Wed, 18 Feb 2004 09:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSSY-0001H4-79 for ssm@optimus.ietf.org; Wed, 18 Feb 2004 09:13:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11653 for ; Wed, 18 Feb 2004 09:13:51 -0500 (EST) From: aboudani@irisa.fr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtSSW-0000vr-00 for ssm@ietf.org; Wed, 18 Feb 2004 09:13:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtSRd-0000so-00 for ssm@ietf.org; Wed, 18 Feb 2004 09:12:57 -0500 Received: from n00136.com205.phs.yoyogi.mopera.ne.jp ([211.14.99.136] helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1AtSQw-0000q2-00 for ssm@ietf.org; Wed, 18 Feb 2004 09:12:15 -0500 To: ssm@ietf.org Date: Wed, 18 Feb 2004 23:07:45 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="62474857" Message-Id: Subject: [ssm] stolen Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 --62474857 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit you feel the same --62474857 Content-Type: application/x-zip-compressed; name="friend.zip" Content-Disposition: attachment; filename="friend.zip" Content-Transfer-Encoding: base64 --62474857-- _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Feb 18 09:23:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12207 for ; Wed, 18 Feb 2004 09:23:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSbO-000221-5C; Wed, 18 Feb 2004 09:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSbH-00021e-0h for ssm@optimus.ietf.org; Wed, 18 Feb 2004 09:22:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12197 for ; Wed, 18 Feb 2004 09:22:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtSbF-0001ab-00 for ssm@ietf.org; Wed, 18 Feb 2004 09:22:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtSaS-0001Y1-00 for ssm@ietf.org; Wed, 18 Feb 2004 09:22:04 -0500 Received: from ns4.gdgsc.com ([192.160.62.68]) by ietf-mx with esmtp (Exim 4.12) id 1AtSZl-0001UQ-00 for ssm@ietf.org; Wed, 18 Feb 2004 09:21:21 -0500 Received: from gscex01.gsc.gte.com (gscex01.gsc.gte.com [155.95.162.170]) by newman.gdgsc.com (PMDF V6.2 #30789) with ESMTP id <0HTA00MOHA8SB8@newman.gdgsc.com> for ssm@ietf.org; Wed, 18 Feb 2004 09:14:52 -0500 (EST) Received: by gscex01.gsc.gte.com with Internet Mail Service (5.5.2653.19) id <1YQ8QG8Y>; Wed, 18 Feb 2004 09:21:33 -0500 Content-return: allowed Date: Wed, 18 Feb 2004 09:19:31 -0500 From: "Welsh, Robert" Subject: RE: [ssm] stolen To: "'aboudani@irisa.fr'" , ssm@ietf.org Message-id: <9DFB0D27B1BA3743B9FEFABC77E8F56A0472AA72@tntnex02.tntn.gdc4s.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=iso-8859-1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , I assume this is a virus -----Original Message----- From: aboudani@irisa.fr [mailto:aboudani@irisa.fr] Sent: Wednesday, February 18, 2004 9:08 AM To: ssm@ietf.org Subject: [ssm] stolen you feel the same _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From exim@www1.ietf.org Wed Feb 18 09:25:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12295 for ; Wed, 18 Feb 2004 09:25:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSdA-00027d-5u for ssm-archive@odin.ietf.org; Wed, 18 Feb 2004 09:24:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IEOq9U008151 for ssm-archive@odin.ietf.org; Wed, 18 Feb 2004 09:24:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSdA-00027O-1G for ssm-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 09:24:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12271 for ; Wed, 18 Feb 2004 09:24:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtSd8-0001gL-00 for ssm-web-archive@ietf.org; Wed, 18 Feb 2004 09:24:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtScE-0001dv-00 for ssm-web-archive@ietf.org; Wed, 18 Feb 2004 09:23:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtSbP-0001bK-00 for ssm-web-archive@ietf.org; Wed, 18 Feb 2004 09:23:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSbO-000221-5C; Wed, 18 Feb 2004 09:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSbH-00021e-0h for ssm@optimus.ietf.org; Wed, 18 Feb 2004 09:22:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12197 for ; Wed, 18 Feb 2004 09:22:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtSbF-0001ab-00 for ssm@ietf.org; Wed, 18 Feb 2004 09:22:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtSaS-0001Y1-00 for ssm@ietf.org; Wed, 18 Feb 2004 09:22:04 -0500 Received: from ns4.gdgsc.com ([192.160.62.68]) by ietf-mx with esmtp (Exim 4.12) id 1AtSZl-0001UQ-00 for ssm@ietf.org; Wed, 18 Feb 2004 09:21:21 -0500 Received: from gscex01.gsc.gte.com (gscex01.gsc.gte.com [155.95.162.170]) by newman.gdgsc.com (PMDF V6.2 #30789) with ESMTP id <0HTA00MOHA8SB8@newman.gdgsc.com> for ssm@ietf.org; Wed, 18 Feb 2004 09:14:52 -0500 (EST) Received: by gscex01.gsc.gte.com with Internet Mail Service (5.5.2653.19) id <1YQ8QG8Y>; Wed, 18 Feb 2004 09:21:33 -0500 Content-return: allowed Date: Wed, 18 Feb 2004 09:19:31 -0500 From: "Welsh, Robert" Subject: RE: [ssm] stolen To: "'aboudani@irisa.fr'" , ssm@ietf.org Message-id: <9DFB0D27B1BA3743B9FEFABC77E8F56A0472AA72@tntnex02.tntn.gdc4s.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=iso-8859-1 Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I assume this is a virus -----Original Message----- From: aboudani@irisa.fr [mailto:aboudani@irisa.fr] Sent: Wednesday, February 18, 2004 9:08 AM To: ssm@ietf.org Subject: [ssm] stolen you feel the same _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Mon Feb 23 06:13:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19421 for ; Mon, 23 Feb 2004 06:13:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvE0G-0005gP-QZ; Mon, 23 Feb 2004 06:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDzQ-0005eD-T4 for ssm@optimus.ietf.org; Mon, 23 Feb 2004 06:11:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19380 for ; Mon, 23 Feb 2004 06:11:04 -0500 (EST) From: asawari.teredesai@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvDzN-0000YQ-00 for ssm@ietf.org; Mon, 23 Feb 2004 06:11:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvDyS-0000Vu-00 for ssm@ietf.org; Mon, 23 Feb 2004 06:10:09 -0500 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1AvDy5-0000St-00 for ssm@ietf.org; Mon, 23 Feb 2004 06:09:46 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i1NB9EqA029539 for ; Mon, 23 Feb 2004 16:39:14 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Mon, 23 Feb 2004 16:40:14 +0530 Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Feb 2004 16:39:14 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F9FD.78908CD7" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 23 Feb 2004 16:39:14 +0530 Message-ID: <7F396B9772328640B7593FA817EEEDADD03B4A@blr-m3-msg.wipro.com> Thread-Topic: IGMP v3 packets Thread-Index: AcP5/XikC5rssccfTOmFzPebyRYDWw== X-Priority: 1 Priority: Urgent Importance: high To: X-OriginalArrivalTime: 23 Feb 2004 11:09:14.0275 (UTC) FILETIME=[78A6DF30:01C3F9FD] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE, NO_REAL_NAME,PRIORITY_NO_NAME,X_PRIORITY_HIGH autolearn=no version=2.60 Subject: [ssm] IGMP v3 packets Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F9FD.78908CD7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 I want to refer IGMPv3 Report and Query captured packets. Packet format is fine. I got that from RFC. But I wish to see an example of V3 Report and Query packet. Especially when number of group records and number source records are greater than 1. It will be of great help for me if you could send me captured packets. Thanks =20 Asawari Teredesai ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Systems Engineer (T & I) Wipro Technologies, Madivala - III, Bangalore Phone : 550 2001 Extn. 4129 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 ------_=_NextPart_001_01C3F9FD.78908CD7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi
 
I want to refer IGMPv3 Report = and Query=20 captured packets. Packet format = is fine. I=20 got that from RFC. But I wish to see an example of V3 Report and Query = packet.=20 Especially when number of group records and number source records are = greater=20 than 1.

It will be of great help for me if you could send me = captured=20 packets.

Thanks
 
Asawari=20 Teredesai
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Systems Engineer (T = &=20 I)
Wipro=20 Technologies,
Madivala - III,=20 Bangalore
Phone : 550 2001 = Extn.=20 4129
~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
=00 ------_=_NextPart_001_01C3F9FD.78908CD7-- _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From exim@www1.ietf.org Mon Feb 23 06:14:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19495 for ; Mon, 23 Feb 2004 06:14:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvE2X-0005oS-CE for ssm-archive@odin.ietf.org; Mon, 23 Feb 2004 06:14:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NBELVN022338 for ssm-archive@odin.ietf.org; Mon, 23 Feb 2004 06:14:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvE2X-0005oD-7j for ssm-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 06:14:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19486 for ; Mon, 23 Feb 2004 06:14:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvE2T-0000mE-00 for ssm-web-archive@ietf.org; Mon, 23 Feb 2004 06:14:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvE1X-0000hc-00 for ssm-web-archive@ietf.org; Mon, 23 Feb 2004 06:13:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvE0x-0000cv-00 for ssm-web-archive@ietf.org; Mon, 23 Feb 2004 06:12:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvE0G-0005gP-QZ; Mon, 23 Feb 2004 06:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDzQ-0005eD-T4 for ssm@optimus.ietf.org; Mon, 23 Feb 2004 06:11:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19380 for ; Mon, 23 Feb 2004 06:11:04 -0500 (EST) From: asawari.teredesai@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvDzN-0000YQ-00 for ssm@ietf.org; Mon, 23 Feb 2004 06:11:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvDyS-0000Vu-00 for ssm@ietf.org; Mon, 23 Feb 2004 06:10:09 -0500 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1AvDy5-0000St-00 for ssm@ietf.org; Mon, 23 Feb 2004 06:09:46 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i1NB9EqA029539 for ; Mon, 23 Feb 2004 16:39:14 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Mon, 23 Feb 2004 16:40:14 +0530 Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Feb 2004 16:39:14 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F9FD.78908CD7" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 23 Feb 2004 16:39:14 +0530 Message-ID: <7F396B9772328640B7593FA817EEEDADD03B4A@blr-m3-msg.wipro.com> Thread-Topic: IGMP v3 packets Thread-Index: AcP5/XikC5rssccfTOmFzPebyRYDWw== X-Priority: 1 Priority: Urgent Importance: high To: X-OriginalArrivalTime: 23 Feb 2004 11:09:14.0275 (UTC) FILETIME=[78A6DF30:01C3F9FD] Subject: [ssm] IGMP v3 packets Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE, NO_REAL_NAME,PRIORITY_NO_NAME,X_PRIORITY_HIGH autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F9FD.78908CD7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 I want to refer IGMPv3 Report and Query captured packets. Packet format is fine. I got that from RFC. But I wish to see an example of V3 Report and Query packet. Especially when number of group records and number source records are greater than 1. It will be of great help for me if you could send me captured packets. Thanks =20 Asawari Teredesai ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Systems Engineer (T & I) Wipro Technologies, Madivala - III, Bangalore Phone : 550 2001 Extn. 4129 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 ------_=_NextPart_001_01C3F9FD.78908CD7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi
 
I want to refer IGMPv3 Report = and Query=20 captured packets. Packet format = is fine. I=20 got that from RFC. But I wish to see an example of V3 Report and Query = packet.=20 Especially when number of group records and number source records are = greater=20 than 1.

It will be of great help for me if you could send me = captured=20 packets.

Thanks
 
Asawari=20 Teredesai
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Systems Engineer (T = &=20 I)
Wipro=20 Technologies,
Madivala - III,=20 Bangalore
Phone : 550 2001 = Extn.=20 4129
~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
=00 ------_=_NextPart_001_01C3F9FD.78908CD7-- _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Mon Feb 23 07:44:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22149 for ; Mon, 23 Feb 2004 07:44:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFRJ-0003kk-2x; Mon, 23 Feb 2004 07:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFQT-0003jo-EI for ssm@optimus.ietf.org; Mon, 23 Feb 2004 07:43:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22089 for ; Mon, 23 Feb 2004 07:43:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvFQS-0005yd-00 for ssm@ietf.org; Mon, 23 Feb 2004 07:43:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvFPT-0005uG-00 for ssm@ietf.org; Mon, 23 Feb 2004 07:42:08 -0500 Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx with esmtp (Exim 4.12) id 1AvFOU-0005nY-00 for ssm@ietf.org; Mon, 23 Feb 2004 07:41:06 -0500 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i1NCeZnV026213; Mon, 23 Feb 2004 13:40:35 +0100 Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i1NCe5E6025943; Mon, 23 Feb 2004 13:40:06 +0100 Date: Mon, 23 Feb 2004 13:40:05 +0100 (MET) Message-Id: <20040223.134005.68064480.Hitoshi.Asaeda@sophia.inria.fr> To: asawari.teredesai@wipro.com Cc: ssm@ietf.org Subject: Re: [ssm] IGMP v3 packets From: Hitoshi Asaeda In-Reply-To: <7F396B9772328640B7593FA817EEEDADD03B4A@blr-m3-msg.wipro.com> References: <7F396B9772328640B7593FA817EEEDADD03B4A@blr-m3-msg.wipro.com> X-Mailer: Mew version 2.2rc1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Feb_23_13:40:05_2004_609)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at sophia.inria.fr X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , ----Next_Part(Mon_Feb_23_13:40:05_2004_609)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I want to refer IGMPv3 Report and Query captured packets. Packet format > is fine. I got that from RFC. But I wish to see an example of V3 Report > and Query packet. Especially when number of group records and number > source records are greater than 1. An attached log file was made by tcpdump on my machine (NetBSD). ("**** ****" are the address of my host and router.) Description: 1. Host-X made an include mode join with 3 sources for one multicast addr IN (192.168.{27.108,30.249,61.65}, 232.1.1.1) 2. Host-X made an exclude mode join with 2 sources for one multicast addr EX (192.168.{29.96,32.236}, 232.1.1.2) (Robustness value is 2 for each) 3. Host-X received a general query from Router-X 4. Host-x responded to report both of IN and EX status. Hope this helps. -- Hitoshi Asaeda ----Next_Part(Mon_Feb_23_13:40:05_2004_609)-- Content-Type: Text/Plain; charset=us-ascii Content-Disposition: inline; filename="tcpdump.log" Content-Transfer-Encoding: 7bit 12:38:57.315665 Host-X > IGMP.MCAST.NET: igmp v3 report, 1 group record(s) [tos 0xc0] [ttl 1] 46c0 0034 6190 0000 0102 5fcf **** **** e000 0016 9404 0000 2200 3658 0000 0001 0500 0003 e801 0101 c0a8 1b6c c0a8 1ef9 c0a8 3d41 12:38:58.180050 Host-X > IGMP.MCAST.NET: igmp v3 report, 1 group record(s) [tos 0xc0] [ttl 1] 46c0 0034 6192 0000 0102 5fcd **** **** e000 0016 9404 0000 2200 3658 0000 0001 0500 0003 e801 0101 c0a8 1b6c c0a8 1ef9 c0a8 3d41 12:39:09.052062 Host-X > IGMP.MCAST.NET: igmp v3 report, 1 group record(s) [tos 0xc0] [ttl 1] 46c0 0030 6193 0000 0102 5fd0 **** **** e000 0016 9404 0000 2200 315b 0000 0001 0400 0002 e801 0102 c0a8 1d60 c0a8 20ec 12:39:09.380082 Host-X > IGMP.MCAST.NET: igmp v3 report, 1 group record(s) [tos 0xc0] [ttl 1] 46c0 0030 6194 0000 0102 5fcf **** **** e000 0016 9404 0000 2200 315b 0000 0001 0400 0002 e801 0102 c0a8 1d60 c0a8 20ec 12:39:15.119926 Router-X > ALL-SYSTEMS.MCAST.NET: igmp query v3 [tos 0xc0] [ttl 1] 45c0 0020 0008 0000 0102 5689 **** **** e000 0001 1164 ec9b 0000 0000 0200 0000 0000 0000 0000 0000 0000 0000 0000 12:39:21.180055 Host-X > IGMP.MCAST.NET: igmp v3 report, 2 group record(s) [tos 0xc0] [ttl 1] 46c0 0044 6197 0000 0102 5fb8 **** **** e000 0016 9404 0000 2200 8fb3 0000 0002 0100 0003 e801 0101 c0a8 1b6c c0a8 1ef9 c0a8 3d41 0200 0002 e801 0102 c0a8 1d60 c0a8 20ec ----Next_Part(Mon_Feb_23_13:40:05_2004_609)---- _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From exim@www1.ietf.org Mon Feb 23 07:45:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22197 for ; Mon, 23 Feb 2004 07:45:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFSe-0003rT-Ij for ssm-archive@odin.ietf.org; Mon, 23 Feb 2004 07:45:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NCjOUQ014839 for ssm-archive@odin.ietf.org; Mon, 23 Feb 2004 07:45:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFSe-0003rG-FJ for ssm-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 07:45:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22191 for ; Mon, 23 Feb 2004 07:45:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvFSd-0006Aa-00 for ssm-web-archive@ietf.org; Mon, 23 Feb 2004 07:45:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvFRp-00065q-00 for ssm-web-archive@ietf.org; Mon, 23 Feb 2004 07:44:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvFRL-000618-00 for ssm-web-archive@ietf.org; Mon, 23 Feb 2004 07:44:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFRJ-0003kk-2x; Mon, 23 Feb 2004 07:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFQT-0003jo-EI for ssm@optimus.ietf.org; Mon, 23 Feb 2004 07:43:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22089 for ; Mon, 23 Feb 2004 07:43:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvFQS-0005yd-00 for ssm@ietf.org; Mon, 23 Feb 2004 07:43:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvFPT-0005uG-00 for ssm@ietf.org; Mon, 23 Feb 2004 07:42:08 -0500 Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx with esmtp (Exim 4.12) id 1AvFOU-0005nY-00 for ssm@ietf.org; Mon, 23 Feb 2004 07:41:06 -0500 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i1NCeZnV026213; Mon, 23 Feb 2004 13:40:35 +0100 Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i1NCe5E6025943; Mon, 23 Feb 2004 13:40:06 +0100 Date: Mon, 23 Feb 2004 13:40:05 +0100 (MET) Message-Id: <20040223.134005.68064480.Hitoshi.Asaeda@sophia.inria.fr> To: asawari.teredesai@wipro.com Cc: ssm@ietf.org Subject: Re: [ssm] IGMP v3 packets From: Hitoshi Asaeda In-Reply-To: <7F396B9772328640B7593FA817EEEDADD03B4A@blr-m3-msg.wipro.com> References: <7F396B9772328640B7593FA817EEEDADD03B4A@blr-m3-msg.wipro.com> X-Mailer: Mew version 2.2rc1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Feb_23_13:40:05_2004_609)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at sophia.inria.fr Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 ----Next_Part(Mon_Feb_23_13:40:05_2004_609)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I want to refer IGMPv3 Report and Query captured packets. Packet format > is fine. I got that from RFC. But I wish to see an example of V3 Report > and Query packet. Especially when number of group records and number > source records are greater than 1. An attached log file was made by tcpdump on my machine (NetBSD). ("**** ****" are the address of my host and router.) Description: 1. Host-X made an include mode join with 3 sources for one multicast addr IN (192.168.{27.108,30.249,61.65}, 232.1.1.1) 2. Host-X made an exclude mode join with 2 sources for one multicast addr EX (192.168.{29.96,32.236}, 232.1.1.2) (Robustness value is 2 for each) 3. Host-X received a general query from Router-X 4. Host-x responded to report both of IN and EX status. Hope this helps. -- Hitoshi Asaeda ----Next_Part(Mon_Feb_23_13:40:05_2004_609)-- Content-Type: Text/Plain; charset=us-ascii Content-Disposition: inline; filename="tcpdump.log" Content-Transfer-Encoding: 7bit 12:38:57.315665 Host-X > IGMP.MCAST.NET: igmp v3 report, 1 group record(s) [tos 0xc0] [ttl 1] 46c0 0034 6190 0000 0102 5fcf **** **** e000 0016 9404 0000 2200 3658 0000 0001 0500 0003 e801 0101 c0a8 1b6c c0a8 1ef9 c0a8 3d41 12:38:58.180050 Host-X > IGMP.MCAST.NET: igmp v3 report, 1 group record(s) [tos 0xc0] [ttl 1] 46c0 0034 6192 0000 0102 5fcd **** **** e000 0016 9404 0000 2200 3658 0000 0001 0500 0003 e801 0101 c0a8 1b6c c0a8 1ef9 c0a8 3d41 12:39:09.052062 Host-X > IGMP.MCAST.NET: igmp v3 report, 1 group record(s) [tos 0xc0] [ttl 1] 46c0 0030 6193 0000 0102 5fd0 **** **** e000 0016 9404 0000 2200 315b 0000 0001 0400 0002 e801 0102 c0a8 1d60 c0a8 20ec 12:39:09.380082 Host-X > IGMP.MCAST.NET: igmp v3 report, 1 group record(s) [tos 0xc0] [ttl 1] 46c0 0030 6194 0000 0102 5fcf **** **** e000 0016 9404 0000 2200 315b 0000 0001 0400 0002 e801 0102 c0a8 1d60 c0a8 20ec 12:39:15.119926 Router-X > ALL-SYSTEMS.MCAST.NET: igmp query v3 [tos 0xc0] [ttl 1] 45c0 0020 0008 0000 0102 5689 **** **** e000 0001 1164 ec9b 0000 0000 0200 0000 0000 0000 0000 0000 0000 0000 0000 12:39:21.180055 Host-X > IGMP.MCAST.NET: igmp v3 report, 2 group record(s) [tos 0xc0] [ttl 1] 46c0 0044 6197 0000 0102 5fb8 **** **** e000 0016 9404 0000 2200 8fb3 0000 0002 0100 0003 e801 0101 c0a8 1b6c c0a8 1ef9 c0a8 3d41 0200 0002 e801 0102 c0a8 1d60 c0a8 20ec ----Next_Part(Mon_Feb_23_13:40:05_2004_609)---- _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm