Minutes IETF104: 6man
minutes-104-6man-02

6MAN Working Group  - Prague IETF Meeting
Monday, 25 March 2019, 09:00-11:00, Congress Hall 2
Friday, 29 March 2019, 09:00-10:30, Congress Hall 1

Note takers: Barbara Stark, Massimiliano Stucchi
Jabber: Éric Vyncke

Jabber Room: 6man@jabber.ietf.org
Meetecho: https://www.meetecho.com/ietf104/6man

------------------------------------------------------------------
------------------------------------------------------------------

Agenda - 25 March 2019

Introduction, Agenda Bashing, Document Status, Chairs, 5 min.
6MAN use of Github Discussion, Chairs, 5 min.

Working Group Drafts

   IPv6 Router Advertisement IPv6-Only Flag, draft-ietf-6man-ipv6only-flag ,
   Bob Hinden, 15 min.

   Privacy Extensions for Stateless Address Autoconfiguration in IPv6,
   draft-ietf-6man-rfc4941bis , Fernando Gont, 30 min.

   Discovering PREF64 in Router Advertisements,
   draft-pref64folks-6man-ra-pref64 , Jen Linkova, 15 min.

   IPv6 Segment Routing Header (SRH),
   draft-ietf-6man-segment-routing-header , Darren Dukes, 30 min.

Active Individual Drafts

   Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering
   Events, draft-gont-6man-slaac-renum , Fernando Gont, 20 min.

   Operations, Administration, and Maintenance (OAM) in Segment Routing
   Networks with IPv6 Data plane (SRv6), draft-ali-spring-srv6-oam ,
   Zafar Ali, 5 min.

Agenda - 29 March 2019

   Introduction, Agenda Bashing, Chairs, 5 min.

Working Group Drafts

   IPv6 Segment Routing Header (SRH),
   draft-ietf-6man-segment-routing-header , Darren Dukes, 10 min.

Active Individual Drafts

  The Universal IPv6 Router Advertisement Option (experiment),
  draft-troan-6man-universal-ra-option , Ole Trøan, 15 min.

  Path MTU Hop-by-Hop Option, draft-hinden-6man-mtu-option , Gorry
  Fairhurst / Bob Hinden, 15 min.

New Individual Drafts

   The IPv6 Compressed Routing Header (CRH),
   draft-bonica-6man-comp-rtg-hdr , Ron Bonica, 5 min.

   The IPv6 Virtual Private Network (VPN) Context Information Option,
   draft-bonica-6man-vpn-dest-opt , Ron Bonica, 5min.

   OAM Capabilities for IPv6, draft-bonica-6man-oam , Ron Bonica, 5min.

   The IPv6 Segment Endpoint Option, draft-bonica-6man-seg-end-opt , Ron
   Bonica, 5min.

   In-situ OAM IPv6 Options, draft-ioametal-ippm-6man-ioam-ipv6-options ,
   Frank Brockners, 5 min.

   Deployment Considerations for In-situ OAM with IPv6 Options,
   draft-ioametal-ippm-6man-ioam-ipv6-deployment , Frank Brockners, 5
   min.

--------------------------------------------------------------
Introduction, Agenda Bashing, Document Status, Chairs, 5 min.
--------------------------------------------------------------

Chairs: Bob Hinden, Ole Trøan

Slides:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessa-introduction-agenda-bashing-00

No questions were asked.

--------------------------------------------------------------
6MAN use of Github Discussion, Chairs, 5 min.
--------------------------------------------------------------

Eric Vyncke: Suresh is supportive of the approach, as long as
participants are not blocked by not using github.

Alissa Cooper: The tutorial materials are all available, and such is the
recording.  If people are interested, they can look at it.

Ole: People should try it out.

There were no more questions or comments.

--------------------------------------------------------------
Working Group Drafts
--------------------------------------------------------------

--------------------------------------------------------------
IPv6 Router Advertisement IPv6-Only Flag,  draft-ietf-6man-ipv6only-flag,
Bob Hinden, 15 min.
--------------------------------------------------------------

Bob Hinden presents:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessa-ipv6-ra-ipv6-only-flag-01

Jen Linkova: The document is nice and ready.  Just one comment.  I had
the strange idea of using it in a dual-stacked network.  There is a use
case for this, moving IPv6-capable devices to use IPv6 only.  Can we
relax section 3 to a SHOULD ?

Bob: I'm not sure. We tried to make it support different environments but
need to see.

Tim Chown: I would assume legacy devices wouldn't understand the flag
anyway, so it should work.

Bob: That's a good point.

Jen Linkova:  That's the whole idea.  New devices will be moved to IPv6
only and old devices will keep IPv4.  This is a suggestion so that they
move to IPv6, and move to IPV6 as much as possible.

Bob: That's not the way we were thinking about it, but I think it could
be used for that. We could add some text. But it is an IPv6-only link and
we want to turn off background chatter.

There were no more questions nor comments.

Ole: Thinking loudly. Do we want to do a further call for this to get it
advanced ?  Let's do a call on that.

Hum: There were many hums in favor of advancing this document to the
IESG.   No humming was audible in opposition.   Ole will confirm on the
mailing list.

--------------------------------------------------------------
Privacy Extensions for Stateless Address Autoconfiguration in IPv6,
draft-ietf-6man-rfc4941bis, Fernando Gont, 30 min.
--------------------------------------------------------------

Fernando Gont presents:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessa-privacy-extensions-for-stateless-address-autoconfiguration-in-ipv6-bis-00

Christian Huitema:  There is a problem in using time for randomisation
because in practise you want your address to remain stable for some
duration.  This is something we saw in mac address randomisation where
it's nice to go back to a network and keep the same address.  What is the
"stable time" you want ?  It has to be part of what you're trying to do
there.

Fernando: We have that question, too. Let's say your just using a simple
random number generator with no time parameters. What happens if you
disconnect and then reconnect again? I think it's a broader issue than
just the timer.

Christian Huitema: I'm not advocating timer.  The discussion of this
issue and balancing the solution.  WE could not use time at all ans we
can assume the randomisation comes from timing.

Fernando: I think that even if we use this time parameter from RFC7217 --
do we want more than one and recommend one? Or do we remove the rest?
What does WG want to do?

Ole: Do any implementers of RFC4941 care either way?

Erik Kline: I think I have a preference for keeping a reference to pure
randomness as a possible option.  Let's leave it up to the Operating
system to understand if they are connecting to the same network and want
to keep a previous address.

Fernando: So you think it should be up to the implementation as to what to do?

Erik Kline: It's up to the host, if it's decides to do DNA. Management is
separate from address generation.

Fernando: Agreed.

Erik: You can have as many algorithms as you want.  Keep one as pure
randomness.

Fernando: So we keep the whole set and don't recommend any one.

Erik: Fine for me.

Dave Plonka: I am also in favor the simpler option of randomisation.  I
want to mention in maprg we have figured you can use privacy addresses to
estimate the number of hosts in a network.  You want to guarantee
anonymity.  If you use straight up randomisation you can reduce the
chances of figuring out the number of hosts, so it has advantages.

Fernando: You also want to keep the 2 algorithms?

Dave: I like the first.

Fernando: There are 2 separate questions. Do we want to remove the
description of one of the operations? Do we want to recommend one? Eric
suggested keeping both.

Dave: I'm in favor of recommending the former for anonymisation counting
feature.  I think it's a nice feature.

Ole: We could do a hum for each. We should ask people if ready to make
choice or take to mailing list. How many have read this document
recently? <few hands> OK, we will take to mailing list.

Fernando: Okay.

Ole:  We would like to have reviewers.  Asking for volunteers. Christian
and another volunteered. Ron ?

Fernando: Another question I'd like to get input on is whether we should
keep algorithm requirements in body or in an appendix?

Ole: Anyone? <no-one came to the mic> Take to the list.

Fernando [slide 5]: Thoughts?

Erik Kline: I vote in favor for "on by default"

Fernando: This could go as question to the list as well.

Tim Chown: When you say requirements, are you meaning the requirements
from the host point of view or from the management point of view ?

Fernando: One of the issues with 4941 was when they switch to another
link but keep same ID. So we recommend you should switch to new ID when
certain things happen.

Tim: Part of that is doing it predictably.

Fernando:  In a sense this is left to the implementation, I guess.  There
are a number of things changing from one implementation to another.  Some
OSes might want to generate a new temporary address for a specific
application

Tim:  I want to maximise the privacy of the user, considering how much
that would impact the management of the network.

Fernando: I think it should be mostly up to the host implementation. But
there is a trade-off. We have BCP about availability of addresses and
that might include a recommendation.

Tim: If the outcome is that the host can generate as many addresses as it
wants, maybe we should have some paragraphs about it.  It's an
opportunity to move the tradeoffs one way or another.

Fernando: Probably if we try to impose constraints it might benefit an
endpoint, but we already have a BCP for that.

Tim: Okay, thanks.

Ole: Would you mind moving this doc to github?

Fernando: Yes!

Ole: Thanks!

--------------------------------------------------------------
Discovering PREF64 in Router Advertisements,
draft-pref64folks-6man-ra-pref64, Jen Linkova, 15 min.
--------------------------------------------------------------

Jen Linkova presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessa-discovering-pref64-in-router-advertisements-00

Mohamed Boucadair: I assume the info in slide 3. I don't think this is a
good idea to justify having a new option in RA.

Jen:  SLAAC is designed to provide information to hosts for basic
connectivity.  I don't think a SIP Proxy (the example carried by Mohamed)
is required for a host to have connectivity.  In the future we see other
use cases, we might consider other RA Options.

Mohamed: That's OK. But other operators can decide, for example that you
want to do it a different way. Maybe we don't worry about it because it's
too esoteric. We have all of these options, and I wasn't against it at
the time. But RFCs need to be updated to recommend all as a whole. There
are some networks where you don't need to discover the NAT64
support. It's not needed for an IPv6 only network.

Jen: May I ask you two questions ?  Are you suggesting we should update
other RFCs ?  And second, we have other RA options.  Should we stop using
them because we have other ways to provide this information to the host ?

Mohamed: We decided previously as a WG not to provide a way to configure
NAT64 option. But at this point we need to decide to do things the right
way.

Suresh: there are options that should be there such as the nat64 prefix
and route options.  Others are not needed.

Éric reading from jabber on behalf of Suresh: My view is that if the
config information is fate sharing with the router it needs to be in the
RA. If not it needs to be in DHCPv6. The DNS and NAT64 are border cases
that could be argued that they are basic connectivity primitives. I don't
think that will extend to SIP servers.

Dave Thaler: On the topic of 7050, I don't think it should be absolute.
They are different use cases.  I don't know how many people have secure
RAs deployed, but that RFC is for people who have a specific use case
where they configure RAs in a network with a different management.  My
point is that it does not make sense to make it obsolete.

Jen: I can guarantee that my host gets RAs only from my router with SeND.

Dave T:  IF you don't have SeND, how is it more secure than 7050 ?

Jen: I cannot guarantee when DNS comes from outside. But I can guarantee
RA security.

Dave T: If you can prevent host-to-host, then you can prevent this use
case from happening.

Erik Kline:  The RA option allows you to not have DNS64 at all.  You can
do it on the device and not have to talk to a DNS64 server.

Jen: It is important not to deal with the primitives themselves.

Erik: In fact that is part of service discovery does with DNS

Jen:  This should be configured on the router which is hard.  We can
allow all that information to share fate with routers.

<moving on to next slide, slide 6 and beyond on improvement suggestions>

Mark Andrews: If we go down the variable RA I think we could do the same
exact thing we do with length. You don't have to include the exclusion in
the option itself.

Jen: Yes, that does make sense.  If we use approach number two and we
expand it to have additional information.

Martin Hunek: Is the option able to transfer to the CPE ?  I have a
similar draft, and I was wondering if it's possible to transfer through a
router.

Jen:  I guess your suggestion is to include the option in RAs sent
downstream.  That's a good idea.

There were no more questions nor comments.

--------------------------------------------------------------
IPv6 Segment Routing Header (SRH),
draft-ietf-6man-segment-routing-header, Darren Dukes, 30 min.
--------------------------------------------------------------
Darren presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessa-segment-routing-header-00

Erik Nordmark : do you know which subset of these does encapsulation compared
to the previous ones ?

Darren: All of these implementations are encapsulated.

Tom Herbert:  Why are TLVs required in the SR header as opposed to using
.  If you do have TLVs in the SR header, why are they different from
hop-by-hop options and routing options ?  I think the idea was that SR
headers could be added and removed.  Is this still the intention ?  and
in case, why would they be different from hop by hop and routing ?

Darren: First question answer: As we add more TLVs, those nodes have to
look further into header and have to do additional work to process
header. With TLV in segment header, that's not a requirement. Second
question: When you're defining the list, keeping the options in a single
segment header combined with additional processing overhead is reason to
keep them where they are.

Joel Halpern: I don't see where the current docu draws distinction on
kinds of segments.  You might have non interoperable implementations.p

Darren:  This draft is designing the base for other parts to be built
upon.

Joel:  This thing about processing or not TLVs seems to be strange.

Darren: The current text says that it's left to local policy, which is
open to clarification.

Joel: It doesn't reach the optimization you're citing.

Darren: I think I described the technical reasons.

Saturo Matsushima: ?

Eric Vyncke from Jabber (Mikael Abrahamsson): Please elaborate on the MTU
handling/discovery you mentioned, and what to look for in the drafts to
find this?

Darren: I don't think I mentioned it.

Chang Li: I think if we put TLVs inside the SRH, how are we handling
processing ?  Actually we have several implementations ready (Huawei) and
we hope to address all the issues as soon as possible.

Darren:

Zafar Ali: Coming back to TLVs, I have a draft that ...  You only need to
look for the TLV in the header if you need to modify it in some cases. ?

Tom Herbert: It's up to local policy to process TLVs.  An implementation
could decide to handle them whenever and wherever they want, and this
seems to be too open.  I would like to implement this without having to
make assumptions about local policies.  The definition of TLVs themselves
is too open-ended and people could come up with their own implementations
and claim they're still conformant.

Zhenbin Li: Depends on the SRS. My suggestion is ...

Darren: OK

Ron Bonica:  This discussion has been going on for a long time.  Maybe a
good thing to do would be to leave the door open to do it later when we
better understand TLVs and requirements.

Darren: OK. I would think defining it now and defining the base now but
allowing for those options to be brought out would be valuable.

Ron:  We have an interest in getting this doc published quickly.  The
best we can do is to leave the controversial parts out and publish it.

Zafar Ali: I don't understand this. I wish it would be spelled out in
this draft. There is a point where we need to separate the political from
the reality of the work. We seem to be stuck with this TLV.

Ron: How many TLVs are defined today ?

Zafar: <lists some of them>

Darren: If we were to use the same logic, destination options would not
have been published.  WE define things so we can build on them and build
products on them.  Definitions are buing built.

Ron: You're asking to do the design part backwards.

Darren: You do the best you can with the information you have now.  You
get closer to the right solution as you go.

Zhenbin Li: I think the design of this is proper for the service. There
is already an initiative to support. I think it is proper for SRS to
behave as described in draft.

Zafar Ali: Not all the cases could be defined.

Ole: I'm not sure how to proceed.  It seems TLVs are the biggest
discussion topic, and it has been for quite some time.  If I recall
correctly, the groups did ask you to add HMAC.  If you have ideas, please
propose text and clarifications.  We can't specify TLVs that don't exist,
though.  I don't think we have any way to close this now, so let's let
the discussion continue during the week.  We will have a friday session
to summarise.

Darren:  Those people with open issues, please get back to me and get to
work.

--------------------------------------------------------------
Active Individual Drafts  Reaction of Stateless Address Autoconfiguration
(SLAAC) to Renumbering Events,  draft-gont-6man-slaac-renum, Fernando
Gont, 20 min.
--------------------------------------------------------------

Fernando presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessa-slaacs-reaction-to-renumbering-events-00

Timothy Winters: It is allowed to invalidate lifetime under 2 hours.
Some people from flash renumbering invalidate lifetime under 2 hours.
This is to prevent dos attacks.

Fernando: You say they don't allow?

Timothy: If you set it to a day and then you reduce it 5 seconds, it will
be adjusted to 2 hours.

Fernando: That is a question for CE Router if what you say is so.

Timothy: That's what you would have to put in there.  Distinguish cases
above and below 2 hours.

Richard Patterson: Preferred lifetime can be reduced to less than two
hours, and this solves the problem.  The suggestion only solves the
problem of having too many addresses in deprecated state bound to one
interface.

Fernando: There are 2 things. If you cannot keep the addresses, and ...

Richard:  Is that such a big problem ?

Fernando: Not a big problem

Andrew McGregor: On the reduced PIO lifetimes.  I don't remember if
there's anything in any RFC that says that you should set the lifetime on
a router to half of the lifetime of the lease it got from its router, but
I think it should.

Fernando: I think only requirement that is out there is lifetime of PIO
should never be undefined.

Andrew: I think it should be done.

Tim Chown: I want to echo what Richard said.  I remember many years ago
we had the issues of hosts forming 6to4 addresses.  We had daemons send
out RAs with 0 lifetime deprecating the addresses. The problem here is
there are lots of things you could do that would be "hacky", but some of
them are going to cause more harm than what they're trying to fix.

Fernando: In the situation where CE Routers don't do that... it's unclear
that this is the case. If we get a new PIO, first we change the
preference of the other. But maybe first check whether prefix is still
valid by sending packet to yourself. So if you want a more conservative
reaction, that's fine.

Tim: I think it would be good to document these heuristics.

Fernando: What we have in the ID is we only unprefer or remove the
address if it has been advertised by that same router.  In this case we
disassociate the prefix with the specific router.

Jen: I also am concerned with the hacky workarounds for broken routers.
IT's a solution that's too heavy.  I think changing the default of
preferred and valid lifetimes makes sense.  We should have done it a long
time ago. This would solve most of the problems.  We definitely need to
change defaults, it would help.  Regarding the problem of not being able
to talk to on-link prefixes, I don't think we need to tweak it.  Shall we
think about something like happy eyeballs for source addresses ?

Erik Nordmark: Which devices do we think it makes sense tweaking ?  Shall
we write down a set of rules ?  It's not clear about how much energy to
put into this stuff and how much people should look at this
implementation.  We should look at the best approaches to look forward.

Jinmei Takuya: In this particular model the router would just copy what
it gets from prefix delegation.  If we have to apply something, that
would be the prefix delegation lifetime.

Tim Chown: Maybe we could define 3 categories of things that need to be
done. Implementations, things that can be done, and  ?

--------------------------------------------------------------
Operations, Administration, and Maintenance (OAM) in Segment Routing
Networks with IPv6 Data plane (SRv6), draft-ali-spring-srv6-oam, Zafar
Ali, 5 min.
--------------------------------------------------------------

Zafar presented: (no slides uploaded yet)

Ole: We have discussed it, and we will hold off, then we'll make an adoption
call on the list.

Blue sheets did not make it to everyone.

--------------------------------------------------------------
END of the first session
--------------------------------------------------------------

--------------------------------------------------------------
BEGINNING of the second session
--------------------------------------------------------------

--------------------------------------------------------------
Introduction, Agenda Bashing, Chairs, 5 min.
--------------------------------------------------------------

Bob Hinden presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-introduction-agenda-bashing-00

There were no questions nor comments

--------------------------------------------------------------
IPv6 Segment Routing Header (SRH),
draft-ietf-6man-segment-routing-header, Darren Dukes, 10 min.
--------------------------------------------------------------

Darren Dukes presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-segment-routing-followup-00

Ole: We'll consider this iteration of WGLC done and issue a new WGLC just
to be sure there are no new comments, after you publish the new draft.

Darren:  We will have version -18 out very soon.  Early next week.

Ole: If there's anyone with an issue on this draft, please let us know
now.

Ole: <noting lack of people at mic> OK I think we're done now.

Darren: Thank you everyone.

The chairs plan to start a new working group last call once a new draft
is out that closes the open issues.

--------------------------------------------------------------
The Universal IPv6 Router Advertisement Option (experiment),
draft-troan-6man-universal-ra-option, Ole Trøan, 15 min.
--------------------------------------------------------------

Ole Troan presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-universal-ra-00

Jen Linkova: I like the idea because I can get support much faster on the
router side. This would simplify specifying the option. But how do we
define what the host is supposed todo?

Ole: There's nothing here that prevents you from adding other
information.

Jen: What the host does with the option is not really open for
discussion.

Erik Kline: Text in this document says if you don't understand an option,
ignore it. But yes, specifying host behavior is an issue.

Ole: For that particular one I don't think the document helps either.
It's down to the implementations.  I would be happy with a single line of
text.

Jen: I'm talking about host doing unpredictable stuff when it does
receive an option.

Tommy Pauly: I'm one of the PVD authors.  In general I think it's a good
mechanism. I would love to see it used, especially if all you really need
on the host is simple.  In case of PVD specifically, it's a bit more
complex, and it has an impact on host behaviour.  I think one of the
things you want to do with PVD is to have more options to extend
behaviour there.  I don't think switching PVD to one of these is
something you want to do.

Ole: I wouldn't expect PVDs not to have a stable reference.

Mikael: One of the use cases for PVDs is for when you don't understand
something.  We would need to cover all of the cases.  If I want to send a
PIO, I would need to define a PIO here.

Ole: That's already here. This is an experiment. You do whatever you
like.

Erik: I realize now we need an R flag.  I support the extensibility of
this.  I do think if this is popular and successful.  We need to fix some
things, such as the data types.

Ole: Yes. The reason is we decide where to put things.

Erik:You already have something that could take from reading a server and
turn it into a DHCP option.

Ole: You need a little more parsing but it would be nice not to require
implementation changes. It would be a little more than 50 lines of code.

David Lamparter: We should consider that having something in here does
not mean it's not adopted.  We have to decide from here if we want to
create a specific option and then go ahead with it.

Ole:

Éric Vyncke: I like the idea. Your option is interesting. You are really
looking for something that will stand forever or you will get no
implementation.

Jen: Two comments: I'm trying to think about deployment scenarios.  This
means I have to duplicate everything between standard parts and this.

Ole: I would expect it to be in a new option in a universal RA.  Jen: I'm
in favor of experiments.  This looks a bit short.  Getting something
supported on router platform might take longer than what you are
thinking.

Ole: We have 2 implementations already. There was one done at the
hackathon and another.

Erik: I forgot to say that there are some conflicts between what is in
RAs and somewhere.  I will send a pull request with text.  My perspective
is that the things that need to use the network belong in RAs.  An
example from earlier this week is the SIP Proxy.

Ole: We have an infinite namespace. The network operator should only do
options that make sense for the network.

Alex: I generally support the way it is presented.  The way to address
it seems appropriate.  Is it intended to be router to host or could it be
router to router ?

Ole: The RA mechanism is by definition routed to the host. There is a
question of whether we want to have some means for the host to send
something back. It depends on what you mean by a router is a router.

Alex: I will take this question to the list to explain router-to-router.
With respect to judging success.  Sometimes it comes from availability of
platforms.  We see JSON, we see CDDL, I think I saw ASN.1.  IS the
discussion on the format still open, or is it closed.

Bob<chair>: I'd like to have us not discussing the format. If we decide
to do this we can discuss the format.

Tim Chown: I support this.  My concern is that you might generate or need
extra RAs, with the obvious consequences.  There's a cliff in the
document that you have left open.

Ole: The second page of the slides shows the github URL.

Tim: It would be nice to have an appendix with the list of RA options
that did not make it.

Ole: These are the ones that are on our schedule now. <showed
implementations / candidates page of slide deck -- the last slide>

Tim: I think the point is that this is something that removes barriers.
Ole: I don't know what else is out there. We have what is currently
known.

David Lamparter: I would be happy to implement this on FRR if I could
find the libraries.

Mikael: I'd like us to look into the interfaces when we talk about the
MTU. Some of this is about Wi-Fi and multicast. If we think we will send
more unsolicited RAs, I'd like us to think about that.

Ole: I think that's also one reason I proposed it as an experiment.  We
can learn a lot from this.

Mikael: If we think this might turn into several kB of info, it might be
good to keep it out of the RA. Like DNS-SD. We should decide what goes
here and what goes there.

Ole: I could have a picture of my family sent on the local link.

Darren Dukes:  This looks like fun.

Suresh Krishnan <on Meetecho>: How do you handle conflicts ?  Some
information could come from DHCP.  I would like to see more text about
sending information through different means and handling issues.

Ole: Yes. Pull request welcome. <Suresh didn't want to do PR>

OK... I'll take that as an order.

Bob <chair>: I think this is going to be popular.  There will be lots of
new things.  We need to be careful about what we specify.  There's a lot
to learn here, but when we get it going, we won't be able to stop it.

There were no more questions nor comments.

--------------------------------------------------------------
Path MTU Hop-by-Hop Option,  draft-hinden-6man-mtu-option, Gorry
Fairhurst/Bob Hinden, 15 min.
--------------------------------------------------------------
Bob Hinden and Gorry Fairhurst jointly presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-path-mtu-hop-by-hop-option-01

Jen: To get feedback you can have destination unreachable. I think this
is quite cool.

Gorry: I'm not that ambitious.

Erik: I'm going to suggest some text. Getting this bubbled up to the app
is good.

Mikael:

Fred Templin: RFC 1053 tried to do exactly the same thing. I think they
were on the right track and I think you are too. It's good to have that
history lesson.

Gorry

David Lamparter: I did a check of the Linux code and it doesn't look at
some items. This may be hard to change.

Bob: You are correct.  That's the status quo today.  If we can show that
this is compelling, than it would encourage people to use it.

David: Right but let me also make the argument that we need to make it as
easy as possible for routers to implement and I'm not sure this is the
way to do that. There may be other ways.

Ole: I wanted to do performance tests during the hackathon.  I'll try to
get that work done and publish that.

Shwetha Bhandari: It would be important to know if option changed.

Gorry: Yes.  We want to do stuff in this space.  However, I think this is
only a hint.

Igor Lubashev: You said transport needs to be reliable and mentioned
QUIC. Another transport in use is TCP. Wat do you think about opening it
up and offering choice after handshake?

Gorry:  So you want to renegotiate MSS when you find something bigger ?

Igor: This thing would be for asymmetric path.

Gorry:  You tell it how much space you have.  I understand what you're
saying.  We could do it.  Let's talk later.

Tom Jones: Question on implementation. Some work at hackathon. This will
not be horrific -- we can do this.

Mikael:  In my 20 years I've seen ICMP expired packets go from being
handle by the cpu to going down to specific silicon.  Have you thought
about where this is going to be handled ?

Bob: Not yet. Good question.

Mikael:   They can look 128bytes into the packet.  If you can do this at
higher speed, there are going to be high pps with hop-by-hop options to
be treated

Bob: And then there's another question of whether you put them
occasionally or in all packets.

Mikael:  We want to make this silicon friendly.

Magnus: I like that you're doing this.  I'm very worried about where you
want to do the processing.

Erik: It could be that some devices can easily handle this and other
devices won't. Something else is you may send this in parallel with
others to the host.

Bob provided hackathon readout. Feedback welcome.

Ole: This is good work. Please provide feedback and experiment with
implementation.

--------------------------------------------------------------
The IPv6 Compressed Routing Header (CRH), draft-bonica-6man-comp-rtg-hdr,
Ron Bonica, 5 min.
--------------------------------------------------------------
Ron Bonica presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-the-ipv6-compressed-routing-header-crh-01

There was no time for discussion.

--------------------------------------------------------------
The IPv6 Virtual Private Network (VPN) Context Information Option,
draft-bonica-6man-vpn-dest-opt, Ron Bonica, 5min.
--------------------------------------------------------------

Rob Bonica presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-the-ipv6-virtual-private-network-vpn-context-information-option-00

There was no time for discussion.

--------------------------------------------------------------
OAM Capabilities for IPv6,  draft-bonica-6man-oam, Ron Bonica, 5min.
--------------------------------------------------------------
Ron Bonica presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-operations-administration-and-maintenance-oam-in-segment-routing-networks-with-ipv6-data-plane-srv6-00

There was no time for discussion.

--------------------------------------------------------------
The IPv6 Segment Endpoint Option,  draft-bonica-6man-seg-end-opt, Ron Bonica,
5min.
--------------------------------------------------------------

Ron Bonica presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-the-ipv6-segment-endpoint-option-00

There was no time for discussion.

Ole: We think we should take questions at the end of all the lightning
talks for people to ask questions on all of the presented topics. But you
[Ron} still get beer for doing your talk quickly.

--------------------------------------------------------------
In-situ OAM IPv6 Options,  draft-ioametal-ippm-6man-ioam-ipv6-options,
Frank Brockners, 5 min.
--------------------------------------------------------------

Franck Brockners presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-in-situ-oam-ioam-in-ipv6-and-deployment-considerations-for-in-situ-oam-with-ipv6-options-00

Tommy Pauly: Yes, I think the question and feedback we'd like to get is
what is the most appropriate way to do this work. What do we do here in
6man or in our group. We're ok doing this work in IPPM. But if 6man
thinks it should be done here, that's ok. Let us know where.

Franck: Thank you.

Shuping Peng:  I think we all agree.  We are proposing to put the OAM
data in the hop-by-hop option.  If we look at EH, that's before the RH.
The data along the path is going to become very large.  That will damage
the performance in the data plane.  We also have done the same talks on
the same topic.  We didn't get the slot, but we're going to present in
the next session in RTT.  We would like to contribute more on this
topic.

Ole: We have 10 minutes left in this session. You can ask questions for
Franck or Ron.

<all the subsequent discussion was directed at Franck>

Mikael: Go back to considerations.  When I read this, I thought that none
of this is true with the proposed approach.  It violates all these 6.  I
think I misunderstand something.

Franck: We're trying to mitigate these concerns. If there are other
options to consider, we'd like to know. We want to deal with changes in
most modest and operationally friendly way.

Mikael: Are you going to continue this in v6ops ?

Franck:  Right now the core of the work is in ippm. There are lots of
documents.

Suresh: I think this should go in IPPM and 6man gets final say on whether
it works.

Mikael:  If you want operational feedback, v6ops would be a better
place.

Mirja Kühlewind: We want feedback. Please give it to us. So either you
make a decision that this is important to you and you want to work it, or
give it to ippm.

Ole <chair>: I think we're happy to have this in ippm.

Mirja: Can we maybe find someone to do an in-depth review ?

Igor: This is a document for all the OAM drafts.  Please don't include
options to send packets elsewhere.  This could be a vector for reflected
amplification attacks.

Franck: There are things that are mixed up right now. Take and record or
take something from packet and send it somewhere.

Igor: Local node is fine.

Franck:  We should find a way to consolidate these things, and put them
in a dedicated draft to address them.

Igor: Internet is a dangerous place.

Gorry: Some of the basic questions are the same Bob and I had.  I am not
sure how we can get the clue for both issues at the same place.  We
should work together, and learn from the same experience.

Franck: We should make sure ippm and 6man are not scheduled att the same time.

Ole:  We will put that on the conflict list.

--------------------------------------------------------------------
Meeting Adjourned
--------------------------------------------------------------------