Minutes interim-2020-6man-02: Tue 15:00
minutes-interim-2020-6man-02-202005051500-01

Meeting Minutes IPv6 Maintenance (6man) WG
Title Minutes interim-2020-6man-02: Tue 15:00
State Active
Other versions plain text
Last updated 2020-05-12

Meeting Minutes
minutes-interim-2020-6man-02-202005051500

   6MAN Working Group  - Virtual 6MAN Meeting
  15:00 - 16:59  PDT, 5 May 2020 / 22:00 - 23:59  UTC, 5 May 2020

Chairs: Bob Hinden, Ole Trøan

Minute taker:  Barbara Stark
Jabber Scribe: None
Jabber Room: 6man@jabber.ietf.org

Notes: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-6man-02

Webex:
 https://ietf.webex.com/ietf/j.php?MTID=mfb47282545035a32e6894000fc1fe9ae
 Meeting number (access code): 614 075 168
 Meeting password: 7yTjrtbnT72

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

Agenda - 15:00 - 17:00  PDT, 5 May 202

Introduction, Agenda Bashing, Chairs, 5 min.

The IPv6 Compressed Routing Header (CRH),  draft-bonica-6man-comp-rtg-hdr
, Ron Bonica, 15 min.

Generalized SRv6 Network Programming,
draft-cl-spring-generalized-srv6-np , Weiqiang Cheng and Robin Li, 15
min.

Generalized Segment Routing Header,  draft-lc-6man-generalized-srh ,
Weiqiang Cheng and Robin Li, 15 min.

Inserting, Processing And Deleting IPv6 Extension Headers,
draft-bonica-6man-ext-hdr-update   , Ron Bonica, 15 min.

The IPv6 Tunnel Payload Forwarding (TPF) Option,
draft-bonica-6man-vpn-dest-opt  , Ron Bonica, 15 min.

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

Introduction, Agenda Bashing, Chairs, 5 min.
Chair slides from prior interim:
https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-introduction-agenda-bashing-document-status

Ole asked if there was any comments to the agenda.

Question from Sander about whether there would be a call for adoption of
Fernando's draft. Confirmed there would be.

--------------------------

The IPv6 Compressed Routing Header (CRH),  draft-bonica-6man-comp-rtg-hdr
, Ron Bonica, 15 min.

https://datatracker.ietf.org/meeting/interim-2020-6man-02/materials/slides-interim-2020-6man-02-sessa-the-ipv6-compressed-routing-header-crh

Darren Dukes: You talk a lot about routing header type zero. Do you
intend for this to be a replacement?

Ron:

Darren: These are kind of like an address translator to use as an opaque
identifier to convert to IPv6 addresses. And these identifiers need to be
configured and distributed around the network.

Ron:

Darren: It's going to need

Ron: It will have information and that info will have an IPv6 address.

Darren: So that will be someone else's IPv6 address? And the node will
need that identifier.

Ron: You can use a routing protocol, or PFCP.

Darren: So distribution could be through a routing protocol like
OSPF. Has anyone shown that to work.

Ron:

Darren: So could these be like IPv4 address identifiers?

Ron: With 16 bits you could only go to 65k. But that's not what I had in
mind.

Darren: If 6man adopts, would you also expect 6man to adopt other work
that goes with this?

Ron: No

Bob: 6man doesn't do that.

Darren: Is this being used on the global Internet?

Ron: You don't want this on the global Internet.

Darren: Where is the domain for this defined? What are the constraints?

Ron: Let's say some operator is operating this node. That operator would
have the domain.

Darren: Will there be documentation describing how the domains work?

Z ?: It has been mentioned that there are differences between your
solution and other architectures. I think there is a need for an
architecture document explaining how everything is put together. There
were also scale and complexity issues mentioned that you have not
addressed.

Ron: It is false that  ? was required. Many customers are comfortable
with proprietary MIBs. Customer doesn't really care about some of these
things. Customers are asking for this.

Z: Why not do MPLS?

Ron: I have datacenter customers who don't want to use MPLS.

Bob: We have a long queue and need to get to other questions.

Eric Vyncke: On one slide you mentioned issue with OAM. Can you say what
this is about? It isn't in the draft.

Ron: I don't need a special OAM doc. OAM works exactly like it has in the
past with PING and TRACEROUTE.

Eric: Section on ICMPv6 isn't needed and suggestion to remove. It's also
unclear whether ...

Zhenbin (Robin) Li: I think this has a lot of relation to SR work. I
think this is a new header. Second comment is there is relationship with
LSR and routing protocols. I think more explanation is needed so we can
understand why certain things are needed.

Ron: Are you saying you think we need an architecture document?

Zhenbin/Robin: I think just the parts that are 6man work need to be
included.

Cheng Li:  Is there any other use case than compression?

Ron: I have customer who cannot afford additional routing header.

Cheng: We have multiple compression solutions here, and I think those
should be worked before adoption.

Jen Linkova: I read and liked the draft.

?:

Andrew Alston: As operator actively looking at CRH, I don't want
complexity of some of what's in SRV6 stuff and will never run it. I like
the simplicity of this.

Jim Guichard: Question on index mapping on the FIB. You said it mapped to
IPv6 address. How do you deal with case where multiple routers use the
same index on IPv6 address.

Ron: There is a 52 on it. A different IPv6 address is used.

Jim: How do I know which next hop to send to? If I have different routers
assigning the same index, how do I do the lookup?

Ron: 52 on that node will be unique. A FIB has no local treatment.

Srihari Sangli: I think 6man is the right place for this work and I like
it for its simplicity.

Bob: Thank you Ron. I think it's too early for adoption call.

Ron: What is needed to get to adoption call.

Bob: I can't answer right now.

Ron: Can I ask on list?

Bob: OK.

Ole: Related to what's going on in spring.

-----------------------------------------------------------------------------------

Generalized SRv6 Network Programming,
draft-cl-spring-generalized-srv6-np , Weiqiang Cheng and Robin Li, 15
min.

https://datatracker.ietf.org/meeting/interim-2020-6man-02/materials/slides-interim-2020-6man-02-sessa-generalized-srv6

Eric Vyncke:  How do we know if it's IPv6 address info or MPLS info?

Robin: It's IPv6 information.

Eric: It's my understanding you were packing a lot of info in 128
bits. How does a router know what is in those 128 bits.

Robin: Please got to slide "G-SID : SRv6 SID ..." Here is what can be
contained. This is a generalized SID.

Eric: Please make it clear in the draft. Thank you for the explanation.

Andrew Alston: I see a lot of complexity here. How do you know which SID
is SID has complexity. There is so much info packed together that I
wonder about complexity for operator to actually use this.

Robin: From our point of view we recommend SRv6. But to support various
requirements we need all of these options. I think the complexity is due
to requirements and cannot be avoided.

Gyan Mishra: This looks like a softwire framework? It seems like softwire
techniques can accomplish the same goal with less complexity.

Robin:

Gyan: If you have SRv6 with MPLS then you can do that in a core, but this
also gives you other options if you use a binding SID, etc.

Bob: We're out of time and moving on to next. Sander?

Sander Steffann: How do you handle the "segments left" value with
compression ? Will you cover this in your next presentation?

Robin: Yes, for the other cases please read the corresponding drafts

Sander: Thx.

-----------------------------------------------------------------------------------

Generalized Segment Routing Header,  draft-lc-6man-generalized-srh ,
Weiqiang Cheng and Robin Li, 15 min.

https://datatracker.ietf.org/meeting/interim-2020-6man-02/materials/slides-interim-2020-6man-02-sessa-generalized-srh

Joel Halpern: Even with SRv6 you have to be careful. With this mod of
SRH, if you make a mistake, the type won't help. They don't understand
bits they are required to ignore if they don't understand.

Robin: But I think you don't need that to understand this header.

Gyan: With this feature... Could you use this in the core in places where
SRv6 had issues? Like when you have a long chain with extended path?

Robin: I think ...

Gyan: But if in core instead of on edge, where you're tunneling over a
core, is this an option instead of SRv6? Or not made for core?

Robin: I think this is not for core.

Andrew Alston: You've referred multiple times to this being a stepping
stone to full SRv6. Do you see this as being something that will live a
long time?

Robin: I thing this will last a long time.

-----------------------------------------------------------------------------------

The IPv6 Tunnel Payload Forwarding (TPF) Option,
draft-bonica-6man-vpn-dest-opt  , Ron Bonica, 15 min.

https://datatracker.ietf.org/meeting/interim-2020-6man-02/materials/slides-interim-2020-6man-02-sessa-the-ipv6-tunnel-payload-forwarding-tpf-option

Sander: I like the building blocks of this. Protocols using these
building blocks will need architecture documents, but for 6man defining
the building blocks is the scope.

Darren Dukes: Can you explain where the domain lives on the Internet?

Ron:

Dan Voyer: On slide 6, what are these special procedures you're talking
about?

Ron: Those are TBD. The only 2 parties that need to know are tunnel
ingress and egress. Between them, they could define up to 2 dozen
behaviors. In the future. No need to be specified here.

Z Zhang: I like generality of this approach. It's simple and
generic. That's important.

Zafar Ali: I agree with Sander that there is a need for an
architecture. If you look at 6man charter, it's not chartered to do major
changes to IPv6. You are referencing

Sander disagreed on this quote in the chat, this reference to architecture is
not what he said Ron: No, RFC 2473 is architecture.

Zafar Ali: No, that's not true.

Ron: There is an architecture and tis is independent of the CRH. Yes the
other proposal uses both of these, but it is not the only thing that uses
this. The 6man working group should not be prevented from defining
another destination option or segment header without spring permission.

Shuping Peng: Routing requirements should come from Routing area.

Ron: I'll circulate this in Routing area.

Ole: We haven't figured out how to ask for adoption on this platform
(WebEx). We'll take that offline.

-----------------------------------------------------------

Inserting, Processing And Deleting IPv6 Extension Headers,
draft-bonica-6man-ext-hdr-update   , Ron Bonica, 15 min.

https://datatracker.ietf.org/meeting/interim-2020-6man-02/materials/slides-interim-2020-6man-02-sessa-inserting-processing-and-deleting-ipv6-extension-headers

Ron: I'm good with starting discussion on the list.

Bob: Go back to slide with original 8200 text. I think you're just trying
to clarify what is meant by Destination Address?

Ron: Yes.

Bob: I think if WG wants to do this, simpler text could be used.

Ron: Yes. Whatever works.

Jen Linkova: I would be against explicitly blocking certain scenarios and
would prefer to define how to do them safely.

Ron: OK.

Sander: On slide with 8200 text. I have always found parts of this
confusing. I think along delivery packet header needs everything in the
delivery path. I think if we just declare that any node in path includes
all routing headers and then do what Jen said, that would be good. I
think we need to confirm what this says about the delivery path.

Ron: I do think this is ambiguous and it's understandable why spring WG
interpreted that way.

Ole: I do think it's important to clarify.

Darren: I don't read it that way. ippm WG is doing something similar in a
domain in one of their drafts. I think we need to explain how to do it
safely.

Ron: We did mention to them there was a security consideration. But I
think this is different. Inside your domain you can do whatever you
want.

Darren: No we don't just do whatever we want. We need to explain risks of
doing things certain way.

Ron: I don't think that's a good idea.

Eric Vyncke: We do like innovation. You raise concerns, but I suggest not
making doc about forbidding things forever, you write what needs to
happen in certain cases in order not to break network.

Ron: I'm sure you're aware there are things that can be changed along
path. There is room there for intermediate node to do things.

Eric: I'm more thinking about form of doc. Don't try to prevent
forever. Note the things that must be kept working and avoid to break
things.

Dan Voyer: Can you be specific about what you see from spring and
elsewhere that violates this?

Ron: I can see a hop-by-hop option. You can design a routing header with
immutable fields in it.

Zafar: I agree with Jen and Eric. There should be room for
innovation.

Suresh Krishnan: If you look at header format, it doesn't have to be
Destination Address. I would do like Jen suggests. See what
breaks. That's what we need to guard against. Look at proposals on their
own merits.

Fernando Gont: I think it's clear based on comments that intent should be
clarified. I think it should be possible with erratum. But just
clarify. In response to Darren, I don't think there is "IPv6 for data
centers". Just IPv6. And I don't think this will prevent
innovation. Write draft and change current behavior.

Andrew Alston: I want to understand what Darren said that it's up to
drafts to explain why they need this. But I don't think it's ok for
someone in other WGs to write whatever they want. 6man can't abdicate
it's responsibilities. I agree with Jen that we need to explain what
rules are to prevent certain things from happening. But until there is
consensus to change, status quo remains. We cannot leave this as
free-for-all -- that would be abdication. We must clarify it.

Bob: This topic will go on, on the list. Thank you everyone for
attending. Especially those in time zones where it's past midnight. We
may schedule other interim meeting.

========================================================================
Meeting Adjourned
========================================================================