* 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, Suresh Krishnan | 2007-Sep-25 —  

IETF-106 6man minutes

Session 2019-11-21 1330-1530: Sophia - Audio stream - 6man chatroom
Session 2019-11-21 1740-1840: Sophia - Audio stream - 6man chatroom


minutes-106-6man-01 minute

          6MAN Working Group - Singapore IETF Meeting
          13:30 - 15:30, 21 November 2019, Thursday Afternoon Session I, Sophia
          17:40 - 18:40, 21 November 2019, Thursday Afternoon Session III, Sophia
          Chairs: Bob Hinden, Ole Trøan
          Minute taker: Barbara Stark
          Jabber Scribe: Peng Shuping
          Jabber Room: 6man@jabber.ietf.org
          Meetecho: https://www.meetecho.com/ietf106/6man
          Agenda - 13:30 - 15:30, 21 November 2019, Thursday Afternoon Session
          I, Sophia
          Introduction, Agenda Bashing, Document Status, Chairs, 10 min.
          Working Group Drafts
              Next Steps in RFC8200 Fragmentation Errata, RFC8200 Errata , Bob
              Hinden / Ole Trøan, 15 min.
              Path MTU Hop-by-Hop Option Update, draft-ietf-6man-mtu-option , Gorry
              Fairhurst / Bob Hinden, 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
              Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on
              First-Hop Routers, draft-linkova-6man-grand , Jen Linkova, 15 min.
              IPv6 Extension Header for the Alternate Marking Method,
              draft-fz-6man-ipv6-alt-mark , Giuseppe Fioccala, 15 min.
              IPv6 Formal Anycast Addresses and Functional Anycast Addresses,
              draft-smith-6man-form-func-anycast-addresses , Mark Smith, 20 min.
          New Individual Drafts (as time allows)
              Asymmetric IPv6 for IoT Networks, draft-jiang-asymmetric-ipv6 ,
              Guangpeng Li, 10 min.
              Support Postcard-Based Telemetry for SRv6 OAM
              draft-song-6man-srv6-pbt , Haoyu Song, 10 min.
          Agenda - 17:40 - 18:40, 21 November 2019, Thursday Afternoon Session
          III, Sophia
          Introduction, Agenda Bashing, Chairs, 5 min.
          Working Group Drafts
          Active Individual Drafts
              In-Flight IPv6 Extension Header Insertion Considered Harmful,
              draft-smith-6man-in-flight-eh-insertion-harmful , Mark Smith, 20
              SRH insertion within an SR Domain,
              draft-voyer-6man-extension-header-insertion , Darren Dukes, 20 min.
              Working Group Discussion on Header Insertion, , Chairs, Mark Smith,
              Darren Dukes, 15 minutes.
          New Individual Drafts (as time allows)
          Agenda Requests Received, Not Scheduled
              Problem Statement and Use Cases of Application-aware IPv6 Networking,
              draft-li-apn6-problem-statement-usecases , Shuping Peng.
              Unified Identifier usecase in IPv6 Segment Routing Networks,
              draft-wmsaxw-6man-usid-id-use , Weiqiang Cheng.
              SRm6, (various drafts), Ron Bonica.
              SRv6 OAM, draft-ali-spring-ioam-srv6 , Zafar Ali.
          ==================== Session 1 ====================
          Introduction, Agenda Bashing, Document Status
          Chairs presented chair slides:
          Chairs reviewed status of 6MAN working group documents.
          Next Steps in RFC8200 Fragmentation Errata
          Bob Hinden presented slides:
          Ole Trøan: I'd like people to review and see if this is right.
          Éric Vyncke: On one of the slides you showed the reassembled packet
          [slide 17]. Is this really the right way?
          Bob: We considered various ways. Figures are helpful, but it's important
          to read the text.  This is also consistent with the style in RFC2460.
          Suresh Krishnan: Should we put a timer on it and verify by end of year?
          Bob: OK. When should I file the new errata?
          Suresh: Let's do it by end of year.
          Ole: Thank you.
          No objections to proceeding with the plan in the room.
          ACTION:  Chairs will do a last call on the list and then proceed with the
          plan shown in the presentation.
          IPv6 Minimum Path MTU Hop-by-Hop Option Update
          Bob Hinden and Gorry Fairhurst presented slides in tandem:
          Erik Kline: Do you have collaborators for running different sorts of
          Gorry: Our measurements were set up to measure from different vantage
          points. We'd love to work with you.
          Cheng Li: is it a mechanism to be used for OAM packets or data packets?
          Bob: Not intended to be maximum packet. Please read the draft, it
          specified in the draft.
          Operations, Administration, and Maintenance (OAM) in Segment Routing
          Networks with IPv6 Data plane (SRv6)
          Zafar Ali presented slides:
          Ole: I found that unless you are quite versed in SR and SPRING you might
          find this hard to read.
          How many have read?  Quite a few.  We need to consider
          overlap with other WGs and get review from them.
          Suresh: I think SPRING is important, but others can be handled after
          Ole: This document has to do with network programming?
          Zafar: No, I think these are independent.
          Suresh: You understand that there are problems with unpublished normative
          Zafar: Yes. My understanding is the reference is going through WGLC.
          Suresh: They're going to go with early allocation.
          ACTION:  Chairs will start a w.g. last call for this draft on the list.
          Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on
          First-Hop Routers
          Jen Linkova presented slides:
          Erik Kline:
          Jen: If ... we don't update the cache
          Erik Nordmark: This doesn't specify whether you have overrides. Oh wait,
          it's in the draft. We need to read the draft.
          Dave Thaler: For router behavior, I think any router that does this is
          ok. [slide on Proposed Changes] Bottom have I can't comment on. Top half
          is ok.
          Jen: There was a suggestion made on the list that this was a protocol
          Dave: I looked carefully at RFCs and think this is ok. You're adding a
          2nd condition which the RFC doesn't address.
          Erik Nordmark:
          Ole: NA will be sent to all hosts?
          Jen: It needs to be sent to all routers, but ok to send to all
          hosts. Don't want to add to noise.
          Dave: For the part you show in proposal it makes sense. But for other? Do
          we want all these documented? Might it encourage people to pursue these?
          Jen: It shows history.
          Bob: Recommendation is to remove non-pursued options from draft.
          Suresh: It's not clear in draft about whether...
          Ole: We want to get consensus of the WG. Hum *against* objection. Does
          anyone think this is a bad idea?
          Éric V: I like this. I'm not against it. But it needs a precise
          Jen: Some will not be done. I can put in text they were considered and
          Ole: We'll pick one solution.
          Fred Baker: Are you saying Jen should let draft in v6ops expire?
          Bob: It will go away, and there will be replacement draft with one
          Dave: So -00 version will always be available with older stuff but -01
          and beyond will only have one option.
          Ole: I don't think we need hum to confirm adoption? But will confirm all
          this on the list.
          Chairs did Hum for non-adoption.   No objections
          ACTION:  Chairs will confirm adoption of this draft on the mailing list.
          IPv6 Application of the Alternate Marking Method
          Giuseppe Fioccala presented slides:
          Ole: What is relationship between work in IPPM and this?
          Giuseppe: In IPPM the drafts are only for measurement. They can't make
          the protocol change.
          Ole: So 6man defines TLV format and IPPM does what?
          Giuseppe: The protocol-specific applications are made in 6man but
          methodology in IPPM.
          Ole: How many people have read?  We'll figure this out on the
          mailing list.
          IPv6 Formal Anycast Addresses and Functional Anycast Addresses
          Mark Smith presented slides:
          Bob: We'd like comments.
          Rajiv Asati: We could keep boundaries with way existing allocations are
          done. I'm not sure about this.
          Erik Kline: Operationally, what's the difference in using one of these
          and using a regular GUA.
          Mark: I think it would be useful to me to know its an anycast
          address. Not having it be globally reachable would also be an advantage.
          Erik Kline:
          Michael Richardson: I like it. One of your use cases doesn't work if the
          address isn't announce-able to the rest of the world. So maybe there are 2
          allocated spaces. We have a need for anycast address in homenet space,
          too. We want a special magic address that you don't have to hardcode.
          Mark: I'm working on including more use cases in the draft.
          Jen: The biggest problem with anycast is load balancing.
          Mark: I think idea of using multicast protocols is interesting.
          Jordi Palet: One of the advantages I see with current anycast is that it
          isn't differentiated.
          Mark: Right, so you don't have to do anything to implement. Just treat
          like unicast.
          Jordi: But I think that's a real advantage of current unicast anycast.
          Ole: Continue discussion on the mailing list.
          Asymmetric IPv6 for IoT Networks
          Guangpeng Li presented slides:
          Ole: Whatdoes the packet look like for the application?  Is it compressed
          on the IoT side, or a regular IPv6 packet?
          Brian Carpenter: You mean below or above the API?
          Brian: That's a good question. My preference would be to use a standard
          packet header.
          Ole: It has info that you can actually compress the header.
          Fred Baker: This takes us back to a discussion from before IPv6 was
          standardized. My first question is how the host knows where the edge of
          the network is. I'm not sure a host has that visibility.
          Brian: It knows the address is in the domain. Which is which is signaled
          in the packet.
          Fred: How does a host know what to send.
          Brian: It doesn't need to. It can use short addresses over long
          Bob: I looked at the draft and in the beginning it referenced "User Plane
          Protocol and Architectural Analysis on 3GPP 5G System"
           to jusify the approach taken in the
          draft.  However, this document didn't describe problems the problems this
          draft is addressing. So I don't know what use case is.  Is this a problem
          that needs to be solved?
          Brian: That's why we took this to 6lo, too. The draft needs more
          context. People who aren't in the 6lo world don't understand.
          Suresh: I think the draft isn't clear, and it's not just not
          understanding 6lo. I think this needs to happen somewhere else and not
          6man. But I don't know if there's room for yet another format. It's not
          clear the overhead is that big.
          Guangpeng: Maybe because we're used to the RA and ...
          Suresh: Use case isn't clear.
          Eric V: May we assume the node needs a short address?
          Brian: Good question. Need to make sure ...
          Rajiv: If we could verify how low MTU needs to be and resources required
          that would help. Also how high does n go? Could it be as low as 2 bytes
          or as high as 128?
          Guangpeng: We'll introduce local names into it for 2nd one. And to
          network it will still be small.
          Bob:  Please continue on mailing list.
          Support Postcard-Based Telemetry for SRv6 OAM
          Haoyu Song presented slides:
          Suresh: Not as AD. I think the idea of having a marking in the protocol
          isn't going to work. It needs to be outside the payload. Doesn't work.
          Haoyu: Why?
          Suresh: Let's say you have packet flowing into system and you want to
          collect telemetry. Where is the signal?
          Haoyu: This is a general method that can be applied to any protocol. This
          is a proposal for how to apply to SRH.
          Suresh: If you don't have SRH how do you do this?
          Haoyu: If you don't have SRH you just...
          Darren: I don't know about IPPM part but I don't know or understand what
          the special something is that needs to happen.
          Zhenbin Li: I think this is useful in many ways. I think it can also be
          used with IPCP.
          Haoyu: I agree with the use case. I think it's the same requirement from
          the data center and a common solution can be found.
          : Is this related to the data center server? We need to figure out
          whether ?? as a use case is something we want to solve. You need to
          describe use cases.
          Suresh: I understand why you want to do this for forced telemetry but not
          for other protocols. I don't think this is a scalable approach.
          Haoyu: Not saying it applies to every protocol.
          : This is very specific. Why restrict to this specific use case? Why not
          do this in the IPv6 main header?
          Haoyu: If you look at draft, it describes how it can be applied to other
          protocols. In here, we want to describe how to apply to OAM in SRv6. If
          you want to apply to other networks you do need to find place for mark.
          : But why not in IPv6 header?
          Haoyu: Don't have good idea of how to do that -- where to put the mark.
          Brian: Not sure ...
          Haoyu: Overhead issue if we introduce new header.
          Brian: Your solution is overly general in space where everything is
          Ole: Discuss more in the list. We have one more session.
          ==================== Session 2 ==========================
          Chairs requested that except for clarifying question, all all other
          questions and comments to be asked after the two presentations.
          In-Flight IPv6 Extension Header Insertion Considered Harmful
          Mark Smith presented slides:
          Clarifying questions allowed.
          Darren: Did you read draft-?
          Mark: Yes.
          Darren: How is this solution related to that draft?
          Darren: So what you were talking about with inserted headers sent across
          the Internet aren't really relevant?
          Darren: what part of the presentation was related to the insertion versus
          having EH on the path?
          Chairs: Darren, please present your presentation.
          Deployments With Insertion of IPv6 Segment Routing Headers
          Darren Dukes presented slides:
          Bob: Can you please explain what the dots and such mean in your diagrams
          (on IP header of traffic traversing the SR domain)? The two presentations
          using different ways of representing traversal of packets.
          Darren: '*' are for delimiting the domain, the [] delimit a router with
          the router ID inside.
          Andrew Alston: you refer often to SR domain. Can you specify what is a
          Darren: Please read the drafts.
          Greg Mirksy: [about TILFA] is it switchover for one tunnel or for
          multiple tunnels ?
          Darren: That's more of a feature thing. In the products I'm aware of, any
          traffic in a node that fails, the path is recomputed at the point of
          Greg: But your next segment can be several nodes away, so how do you know
          it has failed?
          Darren: I don't care. It's tunneled, so that will get me around any link
          failures.For purpose of this presentation we need to take it as fact.
          Greg: No. I don't know where your numbers come from.
          Darren: Is your problem with how SRH is inserted? It's feature specific
          thing -- how the numbers are created.
          Ole Troan: are you stating that node 3 will not insert SRH?
          Darren: In the L3 DPM example there is no need for SRH header. If there
          were traffic engineering also applied you would need SR header.
          Bernie Volz: are there other EH removed ?
          Darren: it is up to the inserting node to specify the SID identifying
          which router will remove the header.
          Shuping (channeling jabber - Srihari Ramachandra): When SRH is inserted
          at PLR will the SA be changed to PLR node ?if its not changed and if
          there is a problem along the backup path that requires ICMPv6 packet
          generation, where this ICMPv6 packet reach. Since SA is not changed, will
          it reach the PLR or original Source node ?
          Darren: No.
          Andrew Sullivan: in large SRH domain with 1000's of links, what happens
          if there are multiple failure, then how many SRH will be stacked up ?
          Which will be the final MTU ?
          Darren: Read the draft and see how the path is computed. I can send you
          link to the draft.
          Mark Smith: in the VPN service slide, I will make node 3 and 4 the tunnel
          Darren: Yeah, let's hold onto that and not forget you suggested that.
          Cheng Li: is the SRH inserted and removed with the SR domain. I think
          this is a good idea.
          Joel Halpern: it is not because you are violating a RFC is not a good
          reason to ask 6MAN to change a RFC.
          Darren: You have options to do encapsulation. You can make sure extension
          doesn't escape the domain.
          Ole: we move away from clarification to a debate
          Suresh as AD: to respond to Joel, it is now informational, then it is no
          more changing a RFC. And this change from PS to informal, changed my
          Darren: Since we're in the debate portion of the event...
          Shuping (channeling jabber - Srihari Ramachandra): followup question to
          SA is not updated at PLR, if there is an issue with MTU, what is expected
          by the node 3 when it tries to send the packet again ?
          Darren: version 8 fixes this
          Shuping (channeling jabber - Zhenqiang Li ): Clarification question: I
          just want to make sure that the operaters you mentioned deployed SRH
          insertion not purely SRH? if so, could you please add the SRH insertion
          scenarios in the deployment draft.
          Erik Kline: ask a question about performance about encaps vs EH insert
          Darren: The TLVs can be changeable in the header. We didn't go that way
          but I understand your point.
          Erik Nordmark: in term protection, you talk about inject prefix, did you
          also protect from packet leaving the packet with a specific DA ?
          Darren: Brian had a similar comment. How do you make sure at the egress
          edge how I make sure I'm not sending a packet that doesn't belong there.
          Robin (Zhenbin) Li: SR domain and Internet are different and have
          different requirements.
          Mark: Some of this comes from claiming to follow RFC8200 but then not
          following it. This isn't really IPv6.
          Darren: RFCs are often open to be amended. And there may be exception
          within one domain.
          Mark: I'm not surprised you put MPLS up there. In MPLS, imagine 2 LSRs
          with Ethernet between them ... that's sort of like having IPv6 routers
          between the IPv6 hosts.
          Darren: So you're saying build tunnels between every node.
          Mark: Yes.
          Darren: I don't like that.
          Jen Linkova: I remember having the same discussion when preparing RFC
          8200. Mark's I-D says "SRH insertion is harmful" while the slides are
          about "SRH removal". And they also applies if the SRH was inserted by the
          SOURCE of the packet (so not insertion).
          Mark: Bumping the spec, I wouldn't consider to be SRH insertion.
          Jen: But all the problems caused are the same for both of you. The
          problem is about not removing.
          Darren: Jen is right.
          Mark: Sure.
          Jen: I think your (Mark) document is confusing.
          Mark: it is all about finding the consequences of it.
          Robin Li: follow RFC is nice but we should listen to the requirements.
          Darren: This is within an SR domain.
          Robin: we have running code with operators deploying.
          Mark: The thing to keep in mind is this is a broader 6man issue.
          Darren: your slides do not consider SRH inserted in a SR-domain and what
          you describe is SRH over the Internet. There is little relevance to the
          sRH insert draft.
          Mark: In your SR domain are you talking about ...
          Bob: I have conclusions. Thank you. This was, quite good.
          Bob: As someone said earlier, this is the default case and you're not
          allowed to do insertion. But if someone writes a draft saying how to do
          it, we could consider it. Thank you Mark for creating a draft that starts
          writing down the issues. Now we can consider rationally. But we're not
          done yet. I think both of these things can exist at the same time. There
          is room for both to be considered.
          Suresh: Bob, you called what I wanted to say. Problems in the Internet
          (dixit Mark) are relevant for the Internet. The ask is not to change RFC
          8200 with version -08. Changing RFC 8200 is probably more difficult as it
          must work on the Internet.
          Bob: And the -08 came out recently and I haven't had a chance to read
          Suresh: I'm kind of ok with the direction that Darren's draft is now
          Erik Nordmark: did not realize that de-encapsulation will occur whether
          it is due to insertion.
          Suresh: That was one of the things that was removed from the SRH draft.
          Erik Kline: Q for Suresh: is it possible to publish both documents ?
          Bob: That was the point I was making.  We can take on and publish both
          Suresh: yes as there is no real disagreement between the two. The 2
          documents can be published along each other.
          Erik: I don't disagree.
          Bob: This was a constructive session. We're not done with this topic.
          Both documents can progress, both need more work.
          Meeting Adjourned

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