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

V6ops Status Pages

IPv6 Operations (Active WG)
Ops Area: Robert Wilton, Warren Kumari | 2002-Aug-22 —  
Chairs
 
 


IETF-112 v6ops minutes


Minutes

minutes-112-v6ops-01 minutes



          1 IPv6 Operations and IPv6 Maintenance Joint Meeting - IETF 112
          Thursday, November 11, 2021 14:30-15:30 UTC
          * Chairs: Ron Bonica, Fred Baker
          * Minute taker: Barbara Stark, Giuseppe Fioccola
          * Jabber Scribe: none
          * Jabber Room:Êv6ops@jabber.ietf.org
          * AD: Warren Kumari
          Friday, November 12, 2021 12:00-14:00 UTC (joint with 6man)
          * Chairs: Ole Tr¿an, Ron Bonica, Fred Baker, Bob Hinden
          * Minute taker: Barbara Stark, Shuping Peng
          * Jabber Scribe: none
          * Jabber Room:Êv6ops@jabber.ietf.org
          * ADs: Warren Kumari, Erik Kline
          Meetecho:
          * Thursday
          session:Êhttps://meetings.conf.meetecho.com/ietf112/?group=v6ops&short=&item=1
          
          * Friday
          session:Êhttps://meetings.conf.meetecho.com/ietf112/?group=v6ops&short=&item=2
          
          2 Agenda
          Thursday, November 11, 2021 14:30-15:30 UTC
          * Administrivia
          * Pros and Cons of IPv6 Transition Technologies for IPv4aaS
          (draft-ietf-v6ops-transition-comparison)
          * Scalability of IPv6 Transition Technologies for IPv4aaS
          (draft-lencse-v6ops-transition-scalability)
          * Isolating Hosts in Layer-2 and Layer-3 to Simplify ND and IPv6 First-Hop
          Deployments (draft-xiao-v6ops-nd-deployment-guidelines
          Friday, November 12, 2021 12:00-14:00 UTC
          * Administrivia (5 minutes)
          * Goals of this meeting (10 minutes)
          * Requirement and solution drafts
          o Operational Issues with Processing of the Hop-by-Hop Options Header,
          draft-ietf-v6ops-hbh (20 min)
          o IPv6 Hop-by-Hop Options Processing Procedures,
          draft-hinden-6man-hbh-processing (20 min)
          o Limits on Sending and Processing IPv6 Extension Headers,
          draft-herbert-6man-eh-limits (20 min)
          * Lightening talks on use-cases (20 minutes, strictly limited to 5
          minutes and 3 slides per talk)
          o IPv6 Minimum Path MTU Hop-by-Hop Option, draft-hinden-6man-mtu-option
          o Approaches on Supporting IOAM in IPv6, draft-song-ippm-ioam-ipv6-support
          
          o Carrying Virtual Transport Network (VTN) Identifier in IPv6 Extension,
          draft-dong-6man-enhanced-vpn-vtn-id
          o IPv6 Application of the Alternate Marking Method,
          draft-ietf-6man-ipv6-alt-mark
          * Structured group discussion of the following questions (25 minutes)
          o Do we want to proceed with rehabilitation of the HBH?
          o Do we want to take some other action (e.g., deprecate the HBH Option)?
          o Do we need to reexamine currently defined HBH options?
          o Do we want to deprecate selected HBH options?
          o What work / documents need to progress to make this happen?
          3 Thursday Notes
          4 Administrivia
          Notewell was displayed. There was no other administrivia, no chair slides
          displayed, and the chairs went straight into presentations.
          5 Pros and Cons of IPv6 Transition Technologies for IPv4aaS
          Draft:Êdraft-ietf-v6ops-transition-comparison
          Gabor Lencse presented. Slides:ÊScalability of IPv6 Transition
          Technologies for IPv4aaS
          There were no comments
          Ron: We will start WGLC next week.
          6 Scalability of IPv6 Transition Technologies for IPv4aaS
          Draft:Êdraft-ietf-v6ops-transition-comparison
          Gabor Lencse presented. Slides:ÊPros and Cons of IPv6 Transition
          Technologies for IPv4aaS
          Gabor: We would appreciate feedback.
          Ron: Comments? There are no comments. Note that Fred Baker (co-chair)
          is having problems connecting to Meetecho.
          7 Isolating Hosts in Layer-2 and Layer-3 to Simplify ND and IPv6 First-Hop
          Deployments
          Draft:Êdraft-xiao-v6ops-nd-deployment-guidelines
          XiPeng Xiao presented. Slides:ÊIsolating Hosts in Layer-2 and Layer-3
          to Simplify ND and IPv6 First-Hop Deployments
          Dave Thaler: Good presentation. Thank you. There is an IAB RFC that you
          could reference: RFC 4903. I noticed that was not in list of references.
          XiPeng: Thank you. We will look and add to the references.
          Nalini Elkins: This is a big area of confusion. I will have various
          people take a look at this who manage private networks and we will
          provide feedback.
          XiPeng: Thanks.
          Jen Linkova: Thank you. Very interesting. Especially interested in
          L2 isolation. How does isolation help with poisoning the router? If I
          look at this from enterprise perspective, IÕm not sure if there is a
          solution. Do you have any deployment recommendations?
          XiPeng: If you do L2 isolation, you may require many interfaces. Even
          if you do L2 isolation, other hosts may still poison therouter. I agree
          with you. L2 isolation does not automatically solve problems. You also
          need to enhance the router. If we look at L2 isolation and unique prefix
          Ð all of this requires the router have additional capabilities. Our
          draft talks about where it is and isnÕt appropriate to introduce many
          interfaces. So donÕt do it where it isnÕt appropriate.
          Jen: Are you talking about existing technology that could be used to
          enhace the router?
          XiPeng: RFC 8273 authors say that implementation exists. But the
          implementation is not clearly specified (what routers need to do). I think
          we need a draft that says what routers need to do to support RFC 8273.
          Erik Kline: IÕm concerned with how much discussion of Wireless ND there
          is. When operators discover there is no Wireless ND (WiND) implementations
          I think there will be concern.
          XiPeng: There are some WiND RFCs published by IETF. I will discuss more
          with you offline to understand better.
          Erik: You do mention it is appropriate for 6lo cases, but I donÕt think
          this will be clear to an operator.
          XiPeng: Some operators are starting to to do IoT, so I do want to
          understand how to address your concern.
          Pascal Thubet: WeÕve never resolved whether that was applicable. We need
          to study.
          Ron: Can the 3 of you get together to determine whether or how WiND
          should be included?
          Pascal: I do think it could be useful.
          Erik: I think itÕs fair to include it. But more guidance needs to be
          provided to operators.
          8 Close Thursday
          Ron: We have the Friday session tomorrow. Are there any other comments
          or topics for today? No.
          9 Friday Notes
          10 Administrivia
          Ole Tr¿an presented the first few slides. Slides:ÊJoint Meeting Note
          Well and Agenda
          No-one bashed the agenda.
          11 Goals of this meeting
          Ron Bonica presented. Slides:ÊChair Slides
          12 Operational Issues with Processing of the Hop-by-Hop Options Header,
          draft-ietf-v6ops-hbh
          Gyan Mishra presented. Slides:ÊOperational Issues with Processing of
          the Hop-by-Hop Options Header
          Ron: To stay on agenda we will hold questions until the 25 minute Q&A
          time at end of this session.
          13 IPv6 Hop-by-Hop Options Processing Procedures,
          draft-hinden-6man-hbh-processing
          Bob Hinden and Gorry Fairhurst presented. Slides:ÊIPv6 Hop-by-Hop Options
          Processing Procedures
          Bob: Want to add that there needs to be compelling use case for a specific
          HBH option that would encourage it to be deployed Internet-wide.
          Ole: We will hold further discussion to end of this session.
          14 Limits on Sending and Processing IPv6 Extension Headers,
          draft-herbert-6man-eh-limits
          Tom Herbert presented. Slides:ÊExtension Header Limits
          Ole: Thank you, Tom. We will now start the use case talks.
          15 IPv6 Minimum Path MTU Hop-by-Hop Option, draft-hinden-6man-mtu-option
          Gorry Fairhurst presented. Slides:ÊIPv6 Minimum Path MTU Hop-by-Hop
          Option
          16 Approaches on Supporting IOAM in IPv6,
          draft-song-ippm-ioam-ipv6-support
          Haoyu Song presented. Slides:Êdraft-song-ippm-ioam-ipv6-support-02
          17 IPv6 Application of the Alternate Marking Method,
          draft-ietf-6man-ipv6-alt-mark
          This presentation was moved before ÒCarrying Virtual Transport Network
          (VTN) Identifier in IPv6 ExtensionÓ to allow Jie Dong time to fix audio
          issues.
          Giuseppe Fioccola presented. Slides:ÊHBH Use Case: IPv6 Application of
          the Alternate Marking Method
          18 Carrying Virtual Transport Network (VTN) Identifier in IPv6 Extension,
          draft-dong-6man-enhanced-vpn-vtn-id
          Jie Dong presented. Slides:ÊCarrying VTN Identifier in IPv6 Extension
          Header
          19 Structured group discussion of the following questions
          20 Do we want to proceed with rehabilitation of the HBH?
          Displayed last slide of:ÊChair Slides
          Eduard Vasilenko: I donÕt think itÕs possible to enforce use. If there
          is no business case, people will still ignore it. Enforcement is not a
          good idea. The 2nd type of solution is to restrict number. But if there
          is not case for 1, limiting to No more than n will not help. IÕm against
          any restriction. 3rd type of solution is to change the architecture Ð
          characterize some options as going to control plane and others to data
          plane. In general, IÕm supportive and think it makes sense to try.
          Tom Herbert: In BobÕs draft you mentioned that in RFC 8200 it made no
          impact when that change was made. Do you have data to shpw that was true?
          Bob: Use of HBH has not occurred.
          Tom: Do you have evidence that previous practices have not changed?
          Bob: We documented the current state Ð what was happening in practice.
          Ron: Default for most routers is to punt to the control plane. Otherwise,
          they drop. I know of at least one vendor who allows ignoring the header.
          Tom: Having router vendors ignore instead of drop would get us halfway
          there.
          Pascal Thubert: HBH is useful and can contain useful information. But
          most useful cases are in limited domains. What is meant by Internet-wide
          usage? Interest is across much of people who use the Internet. Does that
          count?
          Ron: I donÕt think so.
          Shuping Peng: Thank you for having this session. Several colleagues
          did present use cases. You can see from drafts there are 3 operators
          who want to use HBH header but currently have to block it. We are
          looking to solutions described in BobÕs draft. In our draft, we also
          talk about migration strategy. We need to talk about how to use it in
          a real network. Make sure we can co-exist with current set of devices.
          Jen Linkova: There are definitely people who want to make this work. So
          there is no reason to talk about deprecation. We should talk about how
          to make these usable. Find use case for them and then solution. But
          donÕt try to solve in absence of use case.
          Cheng Li: We need these. Customers want this.
          Chongfeng Xie: I support work because it can support many functions
          (IOAM, etc.). HBH has not been widely used, but this does not mean that
          operators are opposed. They donÕt know how to use them because theyÕre
          new. We should also consider manufacturers in this draft.
          Warren Kumari: I was going to save this for the end. When we oroginally
          plannned this session, I was concerned with how session would go. IÕm
          happy and impressed with attitude and willingness to move forward,
          Jie Dong: I support work on HBH header. We already have several use
          cases for limited domain. Before considering larger Internet-wide case
          we need to work on these.
          Ron: IÕm opening up for further discussion. Assuming we go forward with
          the work, IÕd like to look at last 2 questions:
          * Do we need to reexamine currently defined HBH options?
          * What work / documents need to progress to make this happen?
          Gorry Fairhurst: Surely we can find dead wood in current options. Some
          of what we have in RFC series isnÕt used. We may find that odd-sized
          things donÕt exist.
          Ron: Getting rid of dead wood doesnÕt do much except Router Alert
          option. How do people feel about deprecating that?
          Shuping Peng: Whether to deprecate Ð IÕm not sure how we want to do
          this? You never know. Regarding document nd work Ð the requirements
          were just mentioned. In our draft we have dedicated a section on these
          requirements. YouÕre welcome to join us to help make it more reasonable
          and guide solutions.
          Eduard: Reading RFCs is a research project because you have to go through
          references. ItÕs a huge job. In Wi-Fi they try to use a single primary
          document. ItÕs possible to take a single document and read everything. So
          they have thousands of pages. ItÕs madness Ð the opposite extreme. You
          shouldnÕt have to be an expert to understand.
          ƒric Vyncke: I want HBH routing. IÕm unsure of deprecation of some
          options. They wonÕt be removed from old routers. Maybe we could go for
          BCP to not enable them? MLD snooping may still be required.
          Ron: What does deprecate actually mean? I think it means it can still
          be used, but new protocols cannot use it. Does it mean more?
          ƒric: Important question. I will have to look into that.
          Bob: It usually means what Ron said. A deprecation document can define
          what it means in that context.
          Erik Kline: And it means no re-allocation. Speaking as AD, we should
          have adoption calls for one or more of the drafts presented today.
          Warren: Deprecate is like ÒupdatesÓ. No-one knows what it means so you
          need to explain inside the document where you use the term.
          Bob: Queue is clearing. Final comments?
          Erik Kline: Thank you all (chairs and presenters) for taking time for
          this and making a good effort.
          Ron: Chairs, are there any next steps you would like to mention?
          Fred Baker: I asked Tom to write a draft for 6man for a BCP for ignoring
          HBH options. That is a part of the path forward.
          Ron: With no hats on Ð I think we probably need something like 3
          documents we saw at beginning of this session: requirements, use cases,
          limitations. Do we need a house-cleaning document, to deprecate dead
          wood?
          Fred: I agree that deprecation draft would be good.
          Bob: I do think it would be better to write requirements, evaluations
          of each current HBH option in a draft would be good, rather than just
          in email. Also, I think this has been a useful session.
          Gorry: I wanted to come back to meaning of deprecation for MLD and Router
          Alerts. I think there is something useful to write down.
          
          



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