Skip to main content

Minutes IETF106: 6man
minutes-106-6man-01

Meeting Minutes IPv6 Maintenance (6man) WG
Date and time 2019-11-21 05:30
Title Minutes IETF106: 6man
State Active
Other versions plain text
Last updated 2019-12-04

minutes-106-6man-01
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

    None.

Active Individual Drafts

    In-Flight IPv6 Extension Header Insertion Considered Harmful,
    draft-smith-6man-in-flight-eh-insertion-harmful , Mark Smith, 20
    min.

    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)

    None.

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:
https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-introduction-agenda-bashing-document-status
--------------------------------------------------------------------------------

Chairs reviewed status of 6MAN working group documents.

Next Steps in RFC8200 Fragmentation Errata
Bob Hinden presented slides:
https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-next-steps-in-rfc8200-fragmentation-errata
--------------------------------------------------------------------------------

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:
https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-operations-administration-and-maintenance-oam-in-segment-routing-networks-with-ipv6-data-plane-srv6
---------------------------------------------------------------------

Erik Kline: Do you have collaborators for running different sorts of
tests.

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:
https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-operations-administration-and-maintenance-oam-in-segment-routing-networks-with-ipv6-data-plane-srv6
---------------------------------------------------------------------------

Ole: I found that unless you are quite versed in SR and SPRING you might
find this hard to read.

How many have read? <hands raised> 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
WGLC.

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
references.

Zafar: Yes. My understanding is the reference is going through WGLC.

Pablo:

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:
https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-gratuitous-neighbor-discovery-creating-neighbor-cache-entries-on-first-hop-routers

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
change.

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
solution.

Jen: Some will not be done. I can put in text they were considered and
discarded.

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
solution.

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
(draft-fz-6man-ipv6-alt-mark-01) Giuseppe Fioccala presented slides:
https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-ipv6-application-of-the-alternate-marking-method-draft-fz-6man-ipv6-alt-mark-01
------------------------------

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? <some hands> We'll figure this out on the
mailing list.

IPv6 Formal Anycast Addresses and Functional Anycast Addresses
Mark Smith presented slides:
https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-ipv6-formal-anycast-addresses-and-functional-anycast-addresses
------------------------------------

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.

Jen:

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:
https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-asymmetric-ipv6-for-iot-networks
-----------------------------------

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?

Ole:

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
addresses.

Bob: I looked at the draft and in the beginning it referenced "User Plane
Protocol and Architectural Analysis on 3GPP 5G System"
<draft-ietf-dmm-5g-uplane-analysis> 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:
https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-support-postcard-based-telemetry-for-srv6-oam
------------------------------------------------------------------------

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
encapsulated.

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:
https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessb-in-flight-ipv6-extension-header-insertion-considered-harmful
---------------------------------------------------------------------------

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:
https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessb-deployments-with-insertion-of-ipv6-segment-routing-headers
---------------------------------------------------------------------------

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 are
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
SR-domain?

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
failure.

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.

Darren:

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
endpoints.

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.

<Darren finally gets to Conclusion slide so no more interruption ;-)>

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
mind.

Darren: Since we're in the debate portion of the event...

<Mark arrives to the front of the room with another mic in hand, so now
both Darren and Mark have mics>

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.

<applause at the end>

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
it.

Suresh: I'm kind of ok with the direction that Darren's draft is now
taking.

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
documents.

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
------------------------------------------------------------------------