* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

6man Status Pages

IPv6 Maintenance (Active WG)
Int Area: Éric Vyncke, Erik Kline | 2007-Sep-25 —  

IETF-108 6man minutes

Session 2020-07-28 1100-1240: Room 2 - Audio stream - 6man chatroom
Session 2020-07-31 1300-1350: Room 4 - Audio stream - 6man chatroom


minutes-108-6man-05 minute

          Minutes 6MAN Working Group at IETF 108Tuesday, 11:00 - 12:40 UTC, 28
          July 2020
          Friday, 13:00 - 13:50 UTC, 31 July 2020Chairs: Bob Hinden, Ole TroanMinute
          taker: Barbara Stark, George Michaelson
          Jabber Scribe: None
          AD: Erik KlineAgenda - Tuesday, 11:00 - 12:40 UTC, 28 July
          2020Introduction, Agenda Bashing, Document Status, Chairs, 5 min.Working
          Group DraftsIPv6 Application of the Alternate Marking Method,
          Giuseppe Fioccola, 10 min.Improving the Robustness of Stateless
          Address Autoconfiguration (SLAAC) to Flash Renumbering Events,
          draft-ietf-6man-slaac-renum, Fernando Gont, 35 min.Gratuitous
          Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop
          Routers, draft-ietf-6man-grand, Jen Linkova, 15 min.Active Individual
          DraftsTransmission of IPv6 Packets over Overlay Multilink Network (OMNI)
          Interfaces, draft-templin-6man-omni-interface, Fred Templin, 20 min.New
          Individual Drafts (as time allows)Self-configuring Stub Networks: Problem
          Statement, draft-lemon-stub-networks-ps , Ted Lemon, 15 min.Agenda -
          Friday, 13:00 - 13:50 UTC, 31 July 2020Introduction, Agenda Bashing,
          Chairs, 5 min.Working Group DraftsIPv6 Minimum Path MTU Hop-by-Hop Option,
          draft-ietf-6man-mtu-option , Ana Custura, Gorry Fairhurst, 15 min.New
          Individual Drafts (as time allows)Attribution Option for Extension Header
          Insertion, draft-herbert-6man-eh-attrib , Tom Herbert, 10 min.BIER in IPv6
          (BIERin6), draft-zhang-bier-bierin6 , Jeffrey Zhang, 10 min.Carrying VTN
          Identifier in IPv6 Extension Header, draft-dong-6man-enhanced-vpn-vtn-id
          , Jie Dong, 10 min.IPv6 hosts detection, draft-li-6man-6hosts-detection
          , Jiang Li, 5 min.Tuesday NotesIntroduction, Agenda Bashing, Document
          StatusChair Slides: Introduction, Agenda Bashing, Document StatusBob
          walked through the chair slides. There was no jabber scribe volunteer
          but Ole opined perhaps we don’t need one.No Agenda Bashing occurred.Ole
          does document status. 1 doc in edit queue (ICMPv6) temp address extensions
          submitted to IESG. nothing in last call
          Two in WGLC. OAM doc passed all outstanding comments, ready to
          advance.Two WG docs, path MTU (friday) and the alternate marking method
          (talked to later)Two “contentiuous” last calls: the compact routing
          header. statement sent out as shown “impasse” awaiting SPRING
          WG outcomes. Timeline issues. planned to report, IETF109/110.Andrew:
          (Liquid Telcom) Question the timeline. Been following. Status in SPRING
          “at best” is IETF110. Leaves me concerned. Quite a way away, doc
          has been around a while. Do we have to sit and wait until IETF110,
          CRH is likely to go full production, in code/routers in the next month
          or two. deployed, functional. To have to sit around and wait… more
          development on something outside of the IETF -> problems later on. What
          to do, if we cannot bring timeframe forward?Bob: I was expecting a
          report to be available in September, and agree that timeline is longer
          than desired. We are discussing this with ADs and understand your
          concern.Ron: Do we have a “red line date” of when we say we’ll
          wait no longer.Bob: No. We were expecting something sooner this was news
          to us when we heard it on Monday’s Spring w.g. session.Ron: Can you
          publish a date?Bob/Ole: No.Joel Halpern (in jabber): The SPRING chairs
          have suggested that a first report should occur in mid-September. SPRING
          obviously can not tell 6man when we will have a final answer or whether or
          how long to wait.Cheng Li (in jabber): Though the time line is the rough
          consensus of the first meeting of the DT, but we will try to speed up for
          sure.Ron: No date / no answer is the same as refusing to do.Ole: adopted
          “robustness for SLAAC”  (on agenda later) other comments?Fernando:
          when describing result of consensus process, there was consensus/agreement
          to work on problem but not solution. I went through comments on the ML,
          there were 2-3 comments with concerns with one specific section of the
          document but what I have seen so far, is not ‘objections’ against
          the rest of the document. When it comes to some of the objections made,
          they were vague. ‘its fragile’ when I asked for clarifications, hard
          to agree or disagree with a vague statement. But during my presentation
          we can focus on the topic and people can raise them.IPv6 Application
          of the Alternate Marking Method (Giuseppe Fioccola)SlidesIgor:
          (Akamai) I think this is important to have loss information, an
          dit has been presented in TSWG multiple times, great there is more
          thinking in 6MAN. Concerned that the thinking right now is purely about
          controlled domains: limited area. Very important to have loss information
          especially in the presence of encrypted protocols in the wide, e2e in the
          internet. Non-optional flowMarkingID could be considered by many people as
          a privacy concern. Looks like in context of Transports which provide flow
          identification themselves may not be neccessary to be mandatory. Second:
          we call it “loss-bit” better to call it ‘upstream-loss-bit’ and
          in TSWG we had an additional bit for ‘downstream-loss’ -additional
          bit is useful. Have draft to show how to do it for any generic transport
          protocol keeping track of loss.Giuseppe: Thank you. Regarding the last
          comment. We don’t have loss bit measurements. It doesn’t make sense
          because this is just one direction. If you want to make 2 directions,
          you have to make it work. It is not bi-directional.Igor: I recommend you
          review our draft. Upstream loss bit is also sent in the same direction
          as downstream. You do not need to observe any return traffic.  It is
          the same sender sending additional markings for upstream loss in this
          direction. I invite you to read the draft again.Bob take to the list, have
          to manage time.Improving the Reaction of IPv6 SLAAC to Flash Renumbering
          Events (Fernando Gont)SlidesFernando: Start with question I wanted to ask
          before (during chair slides): You mentioned there was consensus to work
          on a problem but not the solution. I went through the mailing list and
          there were concerns with specific sections but didn’t see objections
          against the rest of the document. Some of the objections that were made
          were vague (e.g., this is fragile). When I pushed for specifics, people
          did not provide specifics.Bob: we want to see specific text, and the WG
          response to that.Fernando proceeds with going through slides. He pauses
          after slide 2 to see if there are comments.Dave Thaler: slide looks
          ok to me as long as one thing is true: is it the case that a host only
          extends the lifetime and never reduces it on receipt of a PIO? One router
          counting down to zero, but not quite zero yet, confirm host always uses
          the maximum across RAs I think its fine then.Fernando: We underspecified
          it in that respect. But we should be explicit and use the maximum, as
          you say.On slide 7…Dave Thaler: You mean this is a previous PIO from
          that particular routerFernando: YesJen: I am confused here, is it more
          or less the same algorithm you had in the text before adoption?Fernando:
          Yes. What we are doing is discussing…Jen: this algorithm looks a bit
          ‘fragile’ in the event of data being lost or multiple RA. Not sure
          what it means for existing implementations.Fernando: I’m not sure why
          you think it is fragile. Can you elaborate?Jen: I will take to the list,
          I am just confused, a lot of disagreement about this particular section
          before adoption so not sure why you propose the same text again.Fernando:
          What the chairs suggested is that the group would discuss each of the
          mitigations in the doc. If you look at doc, you will see that none
          of the mitigations in these slides are in the doc. I am presenting
          the proposed mitigations here for people to agree / disagree. I would
          appreciate if you elaborate on scenario where things might break because
          it’s difficult to respond if I don’t know what you mean.Ted Lemon:
          Do we actually have any data about this? The question that Fernando and
          Jen is debating is not a theoretical question, we could collect data
          and see if this is a real problem or not. I wonder if this presentation
          and the draft has been motivated by data which can be looked at which
          would help. Have you formally collected data in a manner which can be
          analysed? difficult to answer the questions unless there is data to refer
          to.Fernando: What specific data are you referring to? What would you like
          to see measurered?Ted: We could do some data collection on IPv6 networks,
          notice if RA are being missed or not. prefixes lost. and then implement
          this algorithm, run on devices, see what happens. Do we loose PIO’s
          which shouldn’t have been lost?Fernando: When you say “losing PIO”
          do you mean flash renumbering occurs or RAs get lost…?Ted: we know
          on a flash renumbering event there is going to be issues. But, if we
          did this thing, this mitigation, what would happen… you could set up
          some code, ‘how often do I miss a PIO’ if I ran this algorithm how
          often would I lose my prefix. it would be nice to have the dataFernando:
          OK. Point taken.Dave Thaler: looking back at RFC4861. if I have a bunch of
          off-link prefixes, can be split across multiple RA instances… each with
          a subset of options. what do you want to happen in that case?Fernando:
          What would happen is, when you receive 1 it would reduce the lifetime
          but then things will continue normally. The algorithm does accommodate
          situation where you split the RAs. This is not on the slides. But we
          can discuss.Moving on to slide 9…Fernando: please describe scenario,
          what you have in mind where things might break. To find something that
          we missed, or we think the scenario can be mitigated or not a problem,
          in order to tell.Bob: Thank you. We will continue on the email list. We
          can go forward from that, and discuss indivual issues there.Gratuitous
          Neighbor Discovery. Creating Neighbor Cache Entries on First-Hop Routers
          (Jen Linkova)slidesDave Thaler: I have a vague recollection that I asked
          a question at a previous IETF meeting, but can’t find any discussion in
          this doc. Does this require the host and the router to BOTH change, so it
          may be a long time before it has any impact? Have you looked at having
          the router do something that works with existing hosts?Jen: initially
          we had one draft (in v6ops) discussing all possible things we might do,
          then the document discussed pro’s and con’s and the document said…
          “do this” -the document had to be published together. AFAIK there
          are implementations on the router which are doing this. Node SHOULD not
          … does not say MUST NOT The only thing you can do without making any
          changes on the host, could start ND for that address. the problems with
          that is, if you have 2 routers on the network e.g. first hop redundency
          there is no guarantee same router used for exit traffic. requirement
          discussed, want all routers to have this, to see GUA packet There are
          different things you can do, not prohibited by RFC, this one we have
          to update, nothing prevents you from reading v6 RFC (ND cache draft)
          and doing.Dave: I think you’re saying the answer to my question is
          in the v6ops draft and not in this one and you expect these 2 drafts to
          proceed at the same time, and reference each other. Thanks. That answers
          my question.Ole: need another round on the mailing list before we advance
          this document.Bob: May have to move Ted’s talk to Friday unless Fred
          can reduce time in his upcoming presentation.Overlay Multilink Network
          (OMNI) Interface – IETF Update and Status (Fred Templin)slidesBob:
          Ole and I have discussed. There is a lot. We will ask mailing list if
          there is interest in forming a design team to work on this. I think
          it will require detailed work and there isn’t enough traffic on the
          list. So we will proceed that way unless we hear otherwise.Éric Vyncke
          (AD): I just wanted to confirm what we discussed with Bob and Ole. Also
          it looks like doc has changed since November when I last read it. The
          doc is quite complex. Is there any chance you can separate into multiple
          docs to make things easier to swallow?Fred: already have this (work) as
          two documents. Also in the (related) mobility spec, we don’t have as
          a topic for discussion, we have functions separated out. I believe all
          the pieces in the OMNI spec need to be there.Éric: OK I need to review
          again. And we need to start adoption call and get design team.Bob: OK,
          we will start that later in this week.Self-configuring Stub Networks:
          Problem Statement (Ted Lemon)slidesTed: Taking to ‘INT’ area but
          wanted this on 6MAN radarOle: We can continue on mailing list. We are
          almost out of time. But are there any quick questions now?Alexander
          Petrescu: This IPv4 target: where does it come from?Ted: some people
          don’t have native IPv6 connectivity, so we still need to make that
          work in principle. you may not even need IPv4 connectivity in any case,
          may operate locally in the home, in the building infrastructure, but
          in the case of devices which do need to connect to cloud services I
          think it is neccessary to support IPv4.Wrap UpBob: Thank you. We will
          see you all on Friday.Friday NotesOle and Bob opened the Friday session
          and displayed the agenda for this session.slidesIPv6 Minimum Path MTU
          Hop-by-Hop Option (Ana Custura)slidesÉric Vyncke: Thank you. My concern
          is there is a headend bias. Can you comment?Ana: Yes, we would love
          to diversifu the test setup. We would like to do this with web servers
          as well.Éric: I would like to get a wall of shame of people dropping
          those legal packets. Just a personal comment.Ana: We are working with
          Comcast to resolve this.Toerless: The Linux API header says extensions
          can be received.Ana: there needs to be code added to define this specific
          option. There is no generic option.Gorry/Bob: Ana and Gorry are planning
          to revise the doc to bring it back to the WG.Attribution Option for
          Extension Header Insertion (Tom Herbert)SlidesErik Kline: Asking
          about the assertion that inserting errors doesn’t change the ECMP
          processing .Tom: If devices are doing that it will still work. If not,
          they are breaking IPv6.Erik: No guarantee that header insertion will
          not break header insertion.Tom: We are not changing any of the fields
          used by ECMP.Erik: But you may be considering too much information.Tom:
          I think this is the so-called parsing buffer issue. But this should be in
          a controlled domain where the admin can address the issue.BIER in IPv6
          (BIERin6) (Jeffrey Zhang)SlidesÉric Vyncke: I was wondering – it’s
          not really an extension header you are requesting. It’s more like a
          transport header. Is 6man the right place?Jefffrey: This is in bier, but
          I wanted to present to 6man to get comments.Éric: We may want to involve
          transport and routing.Jeffrey: bier is just a payload.Toerless: If this
          is just information to 6man, that’s ok. But if there is a request for
          more I would like to understand better.Jingrong Xie: (could not quite
          hear)–there is no difference of IPv6 next header for upper-layer or IPv4
          protocol.Jeffrey: You are correct. I made a mistake in that slide.Carrying
          VTN Identifier in IPv6 Extension Header (Jie Dong)SlidesIn middle of
          presentation…Joel Halpern: This draft assumes a new header is needed
          and then finds a convoluted solution. But I challenge the premise that
          a new identifier to be processed in the network is needed.Jie: I would
          like to finish the presentation first. (continues with presentation)Bob:
          (before completion of presentation) We need to wrap this up. I think you
          should answer Joel’s question now, rather than explaining the proposed
          solution in more detail.Jie: I answered in email. This is different
          kind of identifier. Different concept and different functionality.Bob:
          Thank you. Continue on mailing list.IPv6 hosts detection (Jiang
          Li)[Slides](https://datatracker.ietf.org/meeting/10d defer further
          discussion to mailing list.
          We are out of time.Meeting Adjorned

Generated from PyHt script /wg/6man/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -