Draft Minutes IETF 84 Thursday August 2nd - Agenda Discussion - Sept 29th interim meeting dicussion. Fred B - Q - how many folks would be at ripe anyway A - order of a dozen Ron Bonica - Q - asking question of are there drafts that we would want to discuss with a larger community 20-25ish hands Date is noted as Saturday, September 29th 1. Design Guidelines for IPv6 Networks 29-Jun-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-6.pdf Tim C - As one of the authors of 5375 there's a been a lot of deplyment since then Fred B - with respect to 5375 should people who want make changes to it file erratum on it? Dan Y - this document would be worthwhile - security considerations should be infilled. Brian H (jabber) - Is someone proposing to use the errata system as an issue tracker? Joel J - (parphrasing Fred)@brian - fred, but not exactly Joel J (mic) - Is this a style guide from one person's view or a survey of existing design styles? Fred B - icp guidance - is it time to last call it? Supported additional work on the document - Eric Kline, Eric Nygren, Dan York 2. IPv6 Guidance for Internet Content and Application Service Providers 10-Jul-12, (no slides required) Fred B- (discussion of last call on mailing list after the meeting) 3. Service Provider Wi-Fi Services Over Residential Architectures 29-Apr-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-7.pdf Dan Y - it's in interesting draft - is this a v6ops doc ? Fred B - does this document belong here ? (poll) we don't really have a viewpoint in paris there was some interest. continue to work it with interested parties and we'll see where that goes. 4. Enterprise Incremental IPv6 16-Jul-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-0.pdf Fred B - most recent guidance in this area is rfc 4852 historically what the ietf has recomeded a pa prefix you recomended pi I take it you have an opinion Number of people at mic - Tim C, Lorenzo C, Bob H, Fred B- document should talk about different options Lorenzo C - Using two prefixes is not multihoming ... NPT in Japan is a use case of how a pig can fly if there are enough economics behind it Eric K - disable security extentions - disagree as phrased Tim C - - reviewing where we are in current practice allows us to idenitfy shortcomings Merike K - I like this work. there's probably other general guidelines that you can point out differing opinions on. Philip M - second bullet question about isis vs ospf Lorenzo C - ospfv3 is a similar protocol not the same. point-3 I don't agree with - there are other ways in v6. no comfortable making a recomnedation feels - like it started a here's what we did morphed into here's how we did it Mark A - Lots of enterprises knock out icmp completely, just doesn't work completely Tim C - 4860 talks about filtering policy K K C - is the document too ambitious> Fred B - Perception is that a document of this class is desired Want three operators who have deployed ipv6 to review and comment on the draft. Those who want it to become a working group draft hum (some in favor) (none opposed) 5. A Reference Framework for DC Migration to IPv6 19-Jun-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-1.pdf Dan Y - I think it's another good one. Make a comment to the chairs, that this is a package of a documents. we should harmonize some names. Philip M - Just a question - does that apply to wireline incremental? Lorenzo C - Full disclusre wee did do this (nat64) but it was 2008 and our own infrastrucure - in a multitenetant there's no way to pipe this in. Joel J - we shouldn't say that it's a sustainable solution. Diego L - this is certainly switchable Warren K - This doesn't work for use but does that mean it doesn't work for anyone. Lorenzo C - we should talk about what wording we can use to to gain consensus on it. place mautrity level on non—equal footing with 2 and 3 Fred B - hum for wg acceptance (some in favor), (none opposed.0 Return to discussion of: 1. Design Guidelines for IPv6 Networks 29-Jun-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-6.pdf due to remaining time. Discussion of dedicated v6 vs v4/v6 circuits/vlans/pseudowires Boris Y (telus) - consistency of quos control (by address family) Lorenzo C- Option b only exists because of bad job a specifiy per interface protocol counters. Tim C - Just another example when mentioning that tradeoff (vendor gap) Bill F - Hardware issue, it's in the 2006 spec discussion of link local addressing: Lorenzo C - It breaks traceroute - e.g. when there are multiple links. (e.g. because you don't see the hashingtake place. Marc B - would be great to have one but I doubt the level of consensus will reise to than inclusive of nanog/ Fred B - expect to see ongoing work - should we be adopting this? hum? (more in favor than opposed) not strog though. lets continue working it Friday August 3nd Semantic IPv6 Prefix 16-Jul-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-4.pdf George M - outside of your locous of control it can't be trusted - Fred B - help me understand the semantics of ip addressing at a car manufacturer, they want to embedd the vin number or building number they don't seem to have the same problems as you're looking at. Give me a use case Shen Jaing - they have a different understanding of use case George M- a pragmatic dicision was made to walk from the tla model. there was an architure that put proscriptive labels on addresses Wes G - Renumbering is not an easy thing difficulty of merging two addressing planes Dan Y - You have a security section with no security considerations. Tim C - at the heart of it an address planning issue. pros/cons for this sort of approach. K K C - Implied suggestion that applications become aware of address semantics. Seem like a really bad idea. Fred B - As soon sa you put semantics in an address by defintion you're revealing information. NAT64 Operational Experiences 4-Jul-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-2.pdf Cameron Byrne presenting Dan Y - thinks it's goo to have a document like this we know this in operational use Wes George - would I recomend it? compared to nat444 absolutely inherent mistrust of things that don't perpetuate what we've already done yes this does work. it's not a corner case. C B - 6145 46 44 great for box builders this doc sets this in context for an operational network Dan York - I think it's exactly the sort of doc we should have Fred B - right now not a wg document do we want to do that hum (many in favor) (none opposed.) Cameron B - I'd say it needs more work prioro to last call 464XLAT: Combination of Stateful and Stateless Translation 2-Jul-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-5.pdf Lorenzo C - didn't understand the distinction can you explain the clat is assigned a real v6 address where the dest is synthesized Fred B - As one of the authors of 6052 - I might have to do a stateful thing or I imght have an embdded v4 address there's a neccestiy packets go to the service to which they are intended Remi D - Question on the iana section Ron B - It's fine Lorenzo C - It's fine and it came from your request for a special interface id if it's a procedural problem then we can not do it. Remi D - keeping it simlifies the design. On the question of bcp vs informational? Lorenzo C - You don't have to do dap?(DAD) for those address because they're reserved. I don't have strong opinion. Remi D - double translation loses transparency. Cameron B - We have taken care in the document that this is not the greatest solution but it fills the gap. This is a way to operationalize nat64 dns64 to meet our customers needs. Lorenzo C - The work in softwire is higher quality but it's signficantly harder to deploy. lets unblock turning on v6 in the network. Lorenzo C - It is the best current practice within a narrow usage case - Dave T - Nothing new to speficy new or algorythms. do this, bcp Fred B - if it goes bcp it's bcp in a use case. applicabiltiy statement. Ron B - put the statement in the bcp Fred B - we did adopt this as a wg document. hum we'll take this to wg last call (some in favor none opposed.) hum in favor of bcp/informational/experimental (Some for bcp, some for informational, none for experimental) IPv6 over ATM Interworking Function 16-Jul-12, http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-3.pdf Fred B - question - internet architecturel has a defined internetworking function (a router) which you didn't use. Jiexin Zhang - don't know how to answer this Wes G - Where did you find a dslam that does atm but speaks ipv6 Jiexin Zhang - Came from from china telecom. Lorenzo C - A large number of these devices are doing ipoe which doesn't support v6. I think you might be willing to replace the bng and do you want. Fred B - I will invite you to discuss it on the list.