magma@conference.ietf.jabber.com - 2002/11/20
[11:21] %% paul.knight has arrived.
[11:22] <paul.knight> Agenda bashing
[11:23] <paul.knight> Document status
[11:24] <paul.knight> Question (Haixiang He) state information for host tracking of multiple routers
[11:25] <paul.knight> If many hosts on first link, state info may be huge... Is this documented?
[11:26] <paul.knight> Take this to mailing list.....
[11:27] <paul.knight> Msniff on proxy.... messages have to be relayed.
[11:28] <paul.knight> Bill Fenner (who has much shorter hair this time): discuss more on list.
[11:29] <paul.knight> Charter update ... Brian Haberman
[11:35] <paul.knight> discussion: combined or separate MIBs for v4 and v6 versions
[11:36] <paul.knight> nobody else in the meeting is in the jabber session. Guess multicast people aren't multitasking....
[11:36] <paul.knight> IGMP/MLD snooping - Haberman
[11:37] <paul.knight> This is just informational
[11:39] <paul.knight> Q: forwarding rules on shared segments ... First guy's rules on the shared segment will take precedence. Why was this approach taken?
[11:40] <paul.knight> Bill : This sounds wrong...
[11:42] <paul.knight> Haixian He: draft needs to document case with two upstream routers.
[11:42] <paul.knight> Q: what will happen when version changes (IGMPv7, for instance)
[11:43] <paul.knight> A: (Brian) maybe move to layer2-agnostic approach, maybe move away from snooping in the long run
[11:45] <paul.knight> Brian: maybe a disclaimer Bill: it makes a lot of sense. We are saying this is the best way we know how to do it now.
[11:45] <paul.knight> Bill: Point out that this breaks layering
[11:47] <paul.knight> MCOP - Soini
[11:54] %% paul.knight has left.
[11:55] %% paul.knight has arrived.
[12:02] <paul.knight> questions, comments: assumption is that access info is too large or too dynamic to push down ahead of time - ?
[12:03] <paul.knight> A: right ... will add as an assumption
[12:03] <paul.knight> (other points missed)
[12:05] <paul.knight> Q: why not use an existing protocol?
[12:06] <paul.knight> Comment: This is for communication between router and server; maybe it should be in AAA or somethng like that.
[12:06] <paul.knight> Concerns: I'm not convinced that for many services the client's IP address is a good identifier.
[12:07] %% tbamonti has arrived.
[12:08] <paul.knight> Comment: Something like this is needed, but I agree with Dan, it needs something beyond IP address as an identifier.
[12:09] <paul.knight> Comment: defining address ranges needs to be handled, like poking holes in an address range.
[12:10] <paul.knight> Brian: from floor: if you are getting DHCP address (or even hard configured), can get some cookie to give back to prove identity. There is also other work looking at this issue, too.
[12:11] <paul.knight> My opinion is that we need to decide on the problem first before proposing a protocol to solve it.
[12:12] %% paul.knight has left.
[12:12] %% paul.knight has arrived.
[12:13] <paul.knight> "My opinion" was Brian's opinion...
[12:13] <paul.knight> Brian Weil: We need to consider the threat model, define it.
[12:13] <paul.knight> Next presentation:
[12:14] <paul.knight> IGAP: IGMP for user Authentication Protocol - Hayashi
[12:16] <paul.knight> Model discussion, needs of content providers and network service providers
[12:19] <paul.knight> IGAP is only used between edge router and broadband users.
[12:19] %% john loughney has arrived.
[12:20] <paul.knight> design considerations: based on IGMPv2 initially; keep protocol modifications as small as possible; NOT address interaction between edge routers and back-end AAA functions.
[12:21] %% john loughney has left.
[12:23] <paul.knight> Questions: why make change between user and router.?
[12:23] %% tbamonti has left.
[12:24] <paul.knight> Answer: Authentication is user-based, not IP address. For example, I can use my user ID at my home or when I go to visit my friend's house which also has broadband connection. So the user ID information carried in the IGMP message allows this.
[12:25] <paul.knight> Q: I don't think a system based on IGMPv2 is a waste of time except as a historical document.
[12:27] <paul.knight> A: We wanted to use an existing base, but it can be adapted on IGMPv3.
[12:30] <paul.knight> Brian H: Thi is asking an applicaiton level protocol to do too much (not good paraphrase)
[12:31] %% mrose has arrived.
[12:31] <paul.knight> A: please read the draft carefully. - The capabilities which IGAP can provide are needed in the market.
[12:33] <paul.knight> The features it provides are not addressed by other work.
[12:34] <paul.knight> Wassim Tawbi: existing AAA services don't address control of multicast in a straightforward way, and tie it to the multicast group information
[12:36] <paul.knight> q: I don't see why multicast is unique here. It's a piggybacking access control onto the multicast protocols.
[12:37] <paul.knight> A: this does address key multicast issue, making sure joins do not pull extra bandwidth if they are not authorized to join.
[12:38] <paul.knight> Dave Allan: This model addresses assuring the delivery of the service in a way which is not addressed elsewhere.
[12:41] %% paul.knight has left.
[12:41] %% paul.knight has arrived.
[12:42] <paul.knight> Dave Allan: The service provides a way to bookend the delivery, to prove it was delivered over a specific part of the network.
[12:43] <paul.knight> Thomas hardjono: There needs to be a group of people to address this issue. (bad paraphrase; Exodus threw me out again!)
[12:59] %% mrose has left.
[13:19] %% paul.knight has left.