Skip to main content

Minutes interim-2020-6man-01: Tue 07:30
minutes-interim-2020-6man-01-202003310730-00

Meeting Minutes IPv6 Maintenance (6man) WG
Date and time 2020-03-31 14:30
Title Minutes interim-2020-6man-01: Tue 07:30
State Active
Other versions plain text
Last updated 2020-04-16

minutes-interim-2020-6man-01-202003310730-00
6MAN Working Group  - Virtual Vancouver
IETF Meeting  14:30 - 16:30 (UTC), 31 March 2020, Tuesday

Chairs: Bob Hinden, Ole Trøan
Minute taker:  Barbara Stark
Jabber Scribe: TBD

Jabber Room: 6man@jabber.ietf.org
Webex:  https://ietf.webex.com/ietf/j.php?MTID=m34712748394253ee72466def184033a6

================================================================================

Agenda - 14:30 - 16:30 UTC, 31 March 2020, Tuesday

   Introduction, Agenda Bashing, Document Status, Chairs, 10 min.

Working Group Drafts

   Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on
   First-Hop Routers,  draft-ietf-6man-grand-00  , Jen Linkova, 15 min.

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

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

Active Individual Drafts

   IPv6 Application of the Alternate Marking Method,
   draft-fz-6man-ipv6-alt-mark  , Giuseppe Fioccola, 15 min.

   Transmission of IPv6 Packets over Overlay Multilink Network (OMNI)
   Interfaces,  draft-templin-6man-omni-interface  , Fred L Templin,
   20min.

   Improving the Robustness of Stateless Address Autoconfiguration
   (SLAAC) to Flash Renumbering Events, draft-gont-6man-slaac-renum
   Fernando Gont, 15 min.

   Problem Statement Regarding IP Address Usage,
   draft-gont-6man-address-usage-recommendations  , Fernando Gont, 10
   min.

************************************

Chair Intro
https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-introduction-agenda-bashing-document-status

No-one bashed the agenda.

************************************

Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on
First-Hop Routers,  draft-ietf-6man-grand-00  , Jen Linkova

Jen Linkova presented slides:
https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-gratuitous-neighbor-discovery-creating-neighbor-cache-entries-on-first-hop-routers

There were no questions for Jen. Discussion between Ole and Jen around
when to do WGLC vis-a-vis WGLC on the problem statement draft in v6ops.

The problem statement draft is informative and this is normative.
Warren Kumari:

Fernando Gont: The problem statement draft is useful and it might be
useful to WGLC together.

Ole Trøan: Bob and I will take AI to coordinate with v6ops to do WGLC on
both

Bob Hinden: Note that sometime requirements docs don't get published
because it's sometimes harder to get consensus on requirements. But we'll
talk to v6ops.

ACTION: Chairs will check with v6ops chairs about coordinating w.g. last
call.

***********************************

Privacy Extensions for Stateless Address Autoconfiguration in IPv6,
draft-ietf-6man-rfc4941bis  , Chairs & Fernando Gont

Fernando Gont presented slides:
https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-temporary-address-extensions-for-stateless-address-autoconfiguration-in-ipv6

Ole Trøan: Have WGLC comments been sufficiently addressed? We'll confirm
on list, but you can speak up now if you think that isn't the case.

Alex Petrescu: Is this privacy about the address or the IID?

Fernando Gont: I tried to stay away from privacy and this draft is about
addresses and not IIDs. Privacy means different things for different
people, so staying away from that term. This draft is about temporary
addresses. Apps may can determine their own needs for temp addresses.

Alex Petrescu: Privacy does have many different interpretations. My
question was whether this draft said anything about IID. But OK.

Fernando Gont: This mechanism does help with privacy in some scenarios.

Loganaden (Logan) Velvindron: On FreeBSD / OpenBSD side, there are no
problems or objections from the implementation side.

Ole Trøan: No further comments on queue. We will confirm on list, but we
seem ready to ship this document.

ACTION: Verify issues have been resolved, then plan to advance to the
IESG for publication.

*************************************

Operations, Administration, and Maintenance (OAM) in Segment Routing
Networks with IPv6 Data plane (SRv6), draft-ietf-6man-spring-srv6-oam  ,
Zafar Ali

Zafar Ali presented slides:
https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-srv6-oam-draft-ali-spring-srv6

Joel Halpern: You said you added illustrations to address my comments. You did
add illustrations but the description does not address my comment. The document
needs to address what the router actually has to do when the O bit is set. The
text does not describe this.

Zafar Ali: How the device implements this is up to the device.

Joel: You need to specify what the external observable behavior is wrt the O
bit.

Zafar: It will make copy of packet for telemetry operation.

Joel: That's not observable.

Bob: Joel, can you propose text?

Joel: I cannot because I don't know what the observable behavior is
supposed to be.

Zafar: The pseudocode is normative behavior.

Joel: No, the pseudocode is internal. You need to specify external
expected behavior.

Zafar: Happy to have call with you and discuss.

Joel: I understand sendtext is normal response. But with current text I
don't know what to tell my implementers to implement.

Zafar: This is being implemented. We should have call, because I don't
know what you expect.

Joel: I am happy to talk to you further. I don't think this can progress
until it is solved.

Ole: We should take to list. If there are others who see same problem as
Joel it would be helpful if they can express perceived problem. It would
be good to get other PoV.

Greg Mirsky: I did not read latest version, so I haven't seen latest
changes. I think your interpretation of RFC 7799 is incorrect. O-bit,
according to the definition or active, passive, and "in between"
OAM,would be an example of the hybrid OAM method. I also think what you
are trying to achieve with O-bit is achievable with current iOAM (in-situ
OAM). I want to continue our discussion on difference in approaches of
using O-bit and iOAM. I would also like to participate in discussion with

Joel because I have similar concern.

Zafar: I think this is terminology problem. The purpose is to get data
from specific endpoints.

Ron Bonica: You're just sending an IP packet and that's it. So the first
is, ... and then ... Is that right? Presence of SRH will change
result. If packet has extension header, ping won't get through.

Zafar: Fair comment.

Ron: How do we fix it?

Zafar: Can take to mailing list. We will come back to it.

<There was additional clarification by Joel of his issue on jabber.>
<For jabber log: https://www.ietf.org/jabber/logs/6man/2020-03-31.html
 between times 15:27 - 15:48 UTC.>
<note-taker audio dropped, so subsequent discussion not recorded, until...>

On Next Steps slide... Discussing use of GitHub.

Ole: We're still experimenting with use of GH. It's not meeting all
expectations yet. Need new rev of draft.

***************************************************

IPv6 Application of the Alternate Marking Method,
draft-fz-6man-ipv6-alt-mark  , Giuseppe Fioccola

Giuseppe Fioccola presented:
https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-ipv6-application-of-the-alternate-marking-method

Ron Bonica: It might be good to mark this draft as experimental.

Giuseppe: We are just talking about methodology that is transport
agnostic. But this is standard track because in the mentioned use case we
are just trying to do the same in IPv6 as what is already done for
(IPv4?).

Ron: It's not clear to me that the experiment is concluded. Would you
mind using experimental code points?

Giuseppe: The experiment is completed. We cannot fully deploy this until
it goes beyond experimental. We already have limited experimental
deployment. We need Standards Track.

Ole: Need to continue this discussion on list.

Éric Vyncke: I want to understand more about using hop-by-hop extension
header. This requires more resources from router because of need to
remember end-to-end.

Giuseppe: I know hop-by-hop is not recommended. But the internal gate
nodes only need to read and not handle or notify others. So this can be
simply managed.

Éric V: Please pay attention to this.

Erik Kline (no hat): Similar to Eric's comment, I was wondering if there
was value in having both?

Giuseppe: Yes, the scope of the draft is the general option. But the
draft also mentioned other case. For now we can concentrate on both of
these options.

Erik K: It wasn't clear if you were specifying to use just one, or both.

Giuseppe: The intent is to leave it to implementers. But if draft is
adopted, we can discuss further.

*************************************************

Transmission of IPv6 Packets over Overlay Multilink Network (OMNI)
Interfaces,  draft-templin-6man-omni-interface  , Fred L Templin

Fred Templin presented slides:
https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-transmission-of-ipv6-packets-over-overlay-multilink-network-omni-interfaces

Alexandre Petrescu: Several questions. I have written them in jabber for
reference. It looks like mobile prefix fits well in IID. Could mobile
prefix be longer?

Fred: We've said that for prefixes up to 64, it goes in IID. For prefixes
longer than 64, we've said additional bits appear in bits 10-63. Because
we have prefix length of 10, that lets us use these additional bits.

Erik Kline (not hats): If we set aside MTU reassembly, is there any
reason this couldn't be just a regular router?

Fred: So you're asking whether virtual interface model could be lifted?

Erik: assuming reassembly issue could be punted to lower layer.

Fred: I have additional charts we don't have time for. Please look at
these because I describe there why we need to do it this way. And then
please take to mailing list.

Erik: There seems to be a certain fate-sharing about needing the link to
be up. But I will look at your slides and comment on list.

S. DaSilva: What is relationship to other IETF drafts?

Fred: We're looking at mobility solution that isn't widely know to IETF
participants. But OMNI interface would just be triggered by air-to-ground
interface. Meant to be a generic interface.

Bob: This is work in progress. I would like to see more justification for
why parts of the proposed solution are necessary and why existing
standards cannot be used. But we will discuss this on the list.

***************************************************

Improving the Robustness of Stateless Address Autoconfiguration (SLAAC)
to Flash Renumbering Events, draft-gont-6man-slaac-renum  Fernando Gont

Fernando Gont presented:
https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-improving-the-reaction-of-ipv6-slaac-to-flash-renumbering-events

Jen Linkova: <speaking to slide 4>  Does this mean if router A advertises
zero lifetime and 2nd router advertises ... then prefix will be
immediately deprecated?

Fernando:

Jen: I think it's dangerous when you have 2 routers and both are
advertising.

Fernando: I'm not sure we have considered that specific case. We'll take
to list.

Philip Homburg: This is important. But it seems the routers Fernando is
working with are fragile wrt ULAs. Newer routers have separate processing
for ULAs. This doesn't seem to work to me.

Ole: Important comment. We need to make sure we don't end up with a less
robust protocol.

Eric Vyncke: On slide 6, it's typical for PIO to be sent multiple
times. RAs are not sent every minute or so. Frequency is much
higher. With this algorithm, frequency may need to be reduced.

Fernando: Both algorithms consider that all options may not be in same
message. We don't set preferred lifetime to zero immediately. We set to 5
seconds so 2nd RA can be sent with other specifics.

You can accommodate use cases by setting values as on this slide.

Eric V:This is defeating purpose of your draft. But if you're aware, we
can work on this.

Fernando: I haven't actually seen case with multiple RAs. I've been
working with Tim (Winters).

Eric V: We can take this offline.

Richard Patterson: We need to look at some other options.

Ole: There have been useful comments on list.

********************************************************

Ole: We've run out of time so will skip last presentation.

Bob: This has worked rather well. We will consider scheduling another
call. We'll be in touch on that.

********************************************************
Meeting Adjourned
********************************************************