[v6ops] draft minutes, ietf84 thursday 0900.

[joel jaeggli <[e-mail]>]

Draft Minutes

IETF 84

Thursday August 2nd

- Agenda Discussion

- Sept 29th interim meeting dicussion.

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, <draft-matthews-v6ops-design-guidelines>
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 (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, <draft-ietf-v6ops-icp-guidance>
(no slides required)

Fred -
(discussion of last call on mailing list after the meeting)

3. Service Provider Wi-Fi Services Over Residential Architectures
29-Apr-12, <draft-gundavelli-v6ops-community-wifi-svcs>
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 -
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, <draft-chkpvc-enterprise-incremental-ipv6>
http://tools.ietf.org/agenda/84/slides/slides-84-v6ops-0.pdf

Fred -
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 -
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 -
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, <draft-lopez-v6ops-dc-ipv6>
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 - jsut 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 - 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, <draft-matthews-v6ops-design-guidelines>
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-
a breaks traceroute - e.g. when there are multiple links. (e.g. because 
you don't see the hashingtake place.

Marc blanchett -
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