Minutes IETF105: spring
minutes-105-spring-00
| Meeting Minutes | Source Packet Routing in Networking (spring) WG | |
|---|---|---|
| Date and time | 2019-07-24 14:00 | |
| Title | Minutes IETF105: spring | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2019-08-04 |
minutes-105-spring-00
`
SPRING WG - Source Packet Routing in Networking
Wednesday, July 24, 2019
10:00 - 12:00 Wednesday Morning Session 1
Room: Laurier
Chairs:
Bruno Decraene <bruno.decraene@orange.com>
Rob Shakir <robjs@google.com>
===============================================================================
o Administrivia
(Concerning criteria for slots in SPRING WG sessions.)
[Acee Lindem] WG can request reviews from Routing Directorate at
each of these stages.
[Bob Hinden] 6man has a process to have 5 mins, 3 content slides
and no discussion for -00 drafts. This could be a way
forward.
o SRv6 Network Programming (10:10)
[Kamran Raza] Mostly update from IETF102. Next: align with SRH
(6man-routing-header).
Issues: ENH defintion (to be aligned with
6man-routing-header); NH 59 (discussion on the list, no
consensus)
[Bob Hinden] "No next header" has a clear meaning. Should not be
reused.
Request new allocation
[Joel Halpern] The WG cannot adopt the document with the use of ENH
59. There
are exisitng uses which this is in violation of. Must
use an alternate value.
[(Unknown)] Cannot insert extension headers into packet without
encapsulation.
[Lorenzo Colitti] We should think about the amount of address space that
we
need for this solution. Draft says that there is a /32
per router which seems very expensive. Examples use
lots. We should give examples that guide operators to
use a reasonable amount of address space. Draft should
also consider what a /reasonable/ amount of address
space - and evaluate whether this is doable. If we
decide that we need to have a /8 then it would use
significant amount of the Internet's IPv6.
[Darren Dukes] This is just an example used for brevity.
[Lorenzo Colitti] If the examples are a /32, then we should expect that
people use /32s
-- the examples should
be more reasonable.
[Jen Linkova] +1 to Lorenzo statement. Draft may be confusing v4 and
v6 because of
/32 usage :) No justification for /32 and people follow
examples from the draft. Need more details on
requirements
[Andrew Alston] Since this isn't scoped per router, then other elements
(e.g., containers)
might need this space too. This makes the usage even
worse. +1 on looking at the real address space
requirements.
[Stewart Bryant] About 100 types in the regsitry. Think about
introducing SHIM. [Ron Bonica] ENH referred to as a "upper layer
header" - suggest to use the same
terminology. When ENH does not follow SRH, then need to
look down the packet, including sometimes need to
decrypt. Could put this in the destination options.
[Darren Dukes] Pseudocode in SRH draft walks through the procedure for
looking at
headers. This draft needs to adopt this.
[Ron Bonica] Need to look way beyond routing header. Complexity goes
away if you use
option in destination header
[Bruno Decraene] Suggestion to use new header - will be followed up.
o Using DHCP to Manage Node and Ring SID Assignment (10:29)
[Kireeti Kompella] Just a proposal.Some types of SIDs need to be unique.
SIDs should be
consistently assigned to routers at the start (not a
MUST but preference). Any router will make a unicast
request a SID type it wants. Once assigned by DHCP
server, it can be advertised via IGP. Timers for lease
and for how long to preserve (sticky) the allocation to
a node. Useful no Node, Anycast, Ring, SRv6+, etc SIDs.
[? via Jabber] How does this work when we need two SIDs per device?
[Kireeti Kompella] If you want 2 SIDs for the same prefix, probably need
to use extension [Robert Raszuk] Why not use LISP rather than DHCP?
[Kireeti Kompella] DHCP is good tool for making allocations. Well suited
for this. Can use SRMS too. [Jeff T] Looks like option 82. You
don't need to create configuraiton on the server.
Just make it ephemeral
[Kireeti Kompella] Problem is making sure SIDs don't clash. SRGB
management is not an issue. [Stephane Litkowski] Flex Algo, ??? [Kireeti
Kompella] This is similar to the request for multiple SIDs -- we would
perhaps extend
the DHCP request to be able to make requests for
specific algorithms.
[Stephane L] Regarding manual allocation, we have a resource
allocation that is automated. [Kireeti Kompella] Important to make a
recommendation, not a requirement. [Robin] Had already proposed
a solution based on PCEP and BGP to do SID allocation
as well as other parameters. When proposed this in
BGP/PCEP then there were some challenges around whether
values were dynamic. If this is also applicable to
SRv6, then the IPv6 addresses could also be allocated
by DHCP.
[Kireeti Kompella] Agreed, but people think that IPv6 loopback address
needs to be known in advance,
not dynamically allocated.
[Tom Herbert] DHCP is clever about backup servers and use boradcast
for things. Rely on this. [Kireeti Kompella] ACK
o IPv6 Support for Segment Routing: SRv6+ (10:44)
[Ron Bonica] SRV6+ - make a distinction between topology instruction
and service instruction.
Topological: service ingress node. Service: service
egress node. Reasons for decoupling: use most
appropriate extenstion headers (RH affects routing, DOH
affects processing beyond routing). Header of one type
not polluted by information from other types. There is
a complete implementation on Linux and Juniper JUNOS
PoC is coming. Next: SPRING WG adoption, 6MAN adoption
[Robin] Is there any control plane work for this?
[Ron B] Yes, there is associated control plane work. There are
proposals in LSR and IDR
for the extensions that are required. OSPF is missing.
[Robin] The information that is carried by SRH and CRH is the
same information. Do we
need a new set of specifications to cover this?
[Ron B] Is the incremental improvement of SRv6+ vs. SRv6
something that's worth it.
Will leave this to the WG to discuss.
[Robin] If you compress the header, you need to introduce state
in the forwarding plane. [Ron B] There is additional state per
SID, not per path. Look at the IS-IS draft. [Robin] [Ron B] Are
you saying that you support 10 SIDs today? [Jim Guichard] Mentioned no
TLVs required. Plenty of use cases for carrying metadata in the
packet, today in the SRH. If metadata is before the
routing header, then there might be significant
preamble before forwarding
[Ron B] Not trying to compete with NSH. If metadata is big
enough, use NSH. [Jim] If you hsve significant metadata then
this will be an issue. Some other options,
uSID and another proposal has been submitted. We need
to compare the two approaches.
[Tony Przygienda] 5G bandwidth is not free. Number of headers will affect
economic (bandwidth).
There is benefit to having separate transport and
service layers, which this introduces. This has been
the way that we scale networks typically. Supportive of
this approach.
[Gaurav] Don't see any reason for having another header.
[Ron B] Technical arguments against this -- rather than there
is another solution already.
Encouraging improvement over things we have today.
[Tom Herbert] Is it a replacement for SR MPLS? Is it complementary?
[Ron B] It is complementary. SRV6+ mimics SR-MPLS where SRv6
diverges. [Tom Herbert] Does "+" mean that this is a superset? [Bob
Hinden] As 6man co-chair, would like to understand whether SPRING is
interested in this work.
A clear message would be useful to ensure that 6man
spends time usefully.
[Wim Hendrickx] With SRv6 implementations with full flexibility will
have penalties for
implementations. Question - for the WG - likely we need
an optimisation on top of SRH which is more performant
(does not have the penalty). Question to the WG is
whether we should adopt multiple of them. Draft in MPLS
with MPLSoUDP which does the same thing as is being
proposed here. We'll end up implementing all of them,
which causes confusion/additional cost in the market.
[Ron B] There are 3 ways to go: have a shoot-out between
options, we can try merge options
or allow all to grow and let market decide.
[Wim] Believes that there is an optimisation needed -- would
prefer to come up with a
single way to go.
[Andrew Alston] Overhead of SRH is not negligible based on the the
analysis. Cannot justify
deployment of SRGH because of the cost. Inflating IGP
is another concern.
[Robin] There may be other ways to solve this - e.g., BSID. We
must understand the
requirement -- there are other ways that this might be
solved.
[Mach Chen] It is different from existing SRv6 so use different
name, rather than calling
this SRv6.
[Ron B] We can rename it to whatever you'd like.
[David Melman] Identify with the issue of large SID lists. Isn't
SR-MPLS over IP already a
solution for this?
[Ron B] That's an argument for removing both SRv6 and SRv6+. :)
Some operators need SRv6. [David] SR-MPLS over SRv6 is over IP.
[Bruno] SRv6 SRH already exists and been worked on 5 years.
Need to understand the problem
before proposing the solution and commiting to work.
[Ron B] Move the conversation to the list.
[Alvaro R] Want to understand the approach here, should we hold
the work that is already
in 6man whilst we understand what the constraints are?
[Rob S] What is the problem trying to be solved, what are the
constraints? We can then
figure out what it is we want to progress through the
working group. We'd like to avoid SRv6+, SRv6++,
SRv6+++ whilst continually confusing the industry.
[Alvaro R] With that in mind, then should we talk with Suresh and
say to hold SRv6 until such
time that we've decided what to do about these new
proposals?
[Rob S] It's not clear that this is what Ron was asking for.
Read this as wanting an
optimisation on SRv6, rather than a wholly new solution.
[Ron B] Careful to be neutral about SRv6, asking for an
assurance that we are not ossified
with respect to SRv6, and we can continue to discuss
the changes that we might make for this.
[Suresh] Needs clarification how SRv6+ affects 6man. Current
plan of record is that SRv6
will proceed to IESG. Going forward, 6man will also
work on additional SRv6 extensions which have been
gated by SRH. If there is a change to this required
then 6man/INT area would like to understand this ASAP.
o Network Programming Extension: SRv6 uSID Instruction (11:20)
[Bruno D] Many of the comments on CRH apply to this draft too. We
need to define a problem. [Daniel V] There are deployments that
will support it. [Bruno] We knew SRH length when we defined
SRH. What has changed here? [Darren Dukes] It doesn't change how SRH
works. This is just another SID - normal operation for SRv6 [Bruno D]
It changes the forwarding. [Darren Dukes] We re-use the SRH (ref
pseudocode). This is just another SID which has its own
behaviours.
[Bruno D] It doesn't mean we don't change anything from v6
standpoint. Need to ensure
alignment with 6man.
[Cheng Li] It is a right direction to enhance SRv6, but the
solution is not flexible enough.
It only supports loose TE. Prefix has changed from 16b
to 32b that affects existing allocations, all the
addresses are burned in that block. Too expensive.
Implementation should be done for normal SID and uSID
when a new SID is defined. Also, per SID routes
advertisement is a problem. Why not use huawei's
proposal? One update for all SIDs, forever, no need to
update for new SIDs.No routes are needed as well. <?>
[Daniel] Take this offline, multiple points.
[Andrew Alston] Responding to "just another SID type". It's not. If
it's just another SID, then
would not need to be distributed to every node in a way
that this needs to be installed in the IPv6 FIB. IGP
impact may have significant consequences. Nice that
this works on legacy hardware, but legacy devices are
small FIB devices -- so whilst we tradeoff support
here, we also load those edge devices. Must think of
this as an address not just a new SID.
[Daniel V] IGP scale can be addressed via some techniques. Other
comments to be addressed
on the list/offline
[Andrew A] I In order to reduce FIB then we use L1/L2 etc. Can you
explain how L1/L2 stitching
whilst preserving the ability to steer across both,
without flooding L2?
[Daniel V] Take it offline
[Kamran Raza] Techniques where can advertise one prefix. Will
continue to advertise IPv6 prefixes. [Stephane L] Question to WG
Chairs: Regarding information needed to define a problem. Important
aspect is extra cost for ASIC production. Do you expect
vendors to answer this? Take a survey with the vendors?
[Rob S] We know it's not gonna be perfect but there are some
known constraints. [Jeff T] There is a means to be able to
advertise SID depth capabilities into the IGP
through MSD. This information exposes the capabilities.
[Bruno D] There is a draft for IPv6 too that covers this -- at
which point this will
be public.
[Ron B] You retain the trace where the packet has been. Is this
possible in uSID? [Daniel V] Yes. Draft covers this. [Kamran R]
SRv6 has it. [Ron B] Why is it in the routing header
given it doesn't affect routing? [Daniel V] Move it to the list.
[Gaurav] This is a step in the right direction. Handles the MTU
restriction. [Jen L] How much address space is needed here? Not
clear in the draft. Where does the
address space come from? Worried about use of public
address space without sufficient justification.
[Daniel V] It does apply to many types of prefixes. Will be
clarified in next version. [Shraddha] <some type of SID> Is this
also a uSID? [Kamran R] This will be covered by feature work in
the draft [Robin] Can we use a binding SID solution? [Peter
Psenak] There is no difference between dvertigin uSID and
normal/regular SID. Would
like to learn about the concerns.
[Ron Bonica] If we can put SIDs into the SRH, then what do we need
uSIDs for? [Darren D] Draft already covers whether SRH is added or
not. No discussion to be had here? [Ron B] (addressed to
Alvaro) If there are new interactions between uSID and other SIDs
-- how far is the network programming draft from being
mature?
[Bruno D] Current uSID draft is a -01 presentation, currently
there is no interaction
with the working group drafts.
[Daniel V] If you can contribute to the uSID then we can work
these items out.
o TTL Procedures for SR-TE Paths in Label Switched SR-TE Paths. (11:42)
[Zafar Ali] Do we need to document the way that this should work?
[Shraddha H] It is not clear from the existing documents. PHP
behavior needs to change
so clarification is required.
[Zafar Ali] Did you receive comments that this needed clarification?
[Shraddha H] Comments from operators and also from the last
presentation @IETF. [Lou Berger] Might be a comment for MPLS WG.
Would be useful to clarify on what SR-TE is.
We need a definition of SR-TE. Chairs should also
clarify what SR-TE is.
[Shraddha H] ACK.
o Operations, Administration and Maintenance (OAM) in
Segment Routing Networks with IPv6 Data Plane (SRv6) (11:50)
[Zafar A] Summary: Implementations exist. Verfied interop. NEXT:
Ask for SPRING WG adoption. [Bruno] We were waiting for SRH to
be completed. But we don't really care where this is done.
Since this changes SRH then 6man has the priority.
Chairs will discuss with the 6man chairs to determine
whether this is something that they will adopt.
o Segment Routing with MPLS Data Plane Encapsulation for
In-Situ OAM Data (11:57)
[Rakesh Gandhi] NEXT: Updates regarding hashing and hop-by-hop IOAM. Ask
for SPRING WG adoption. [Bruno D] Was it presented to MPLS WG?
[Rakesh G] Yes. [Bruno D] [Jeff T] IPR concerns. Will
request review from Ericsson [?] Why do we need this work?
The following drafts were not presented due to running out of time in the WG
session.
o SRH Encapsulation for iOAM
o PMS/Head-End Based MPLS Ping and Traceroute in Inter-AS
SR Networks
o BGP-LS Extensions for Inter-AS TE using EPE-Based
Mechanisms
o YANG Data Model for IS-IS SRv6