Skip to main content

Minutes for SPRING at IETF-95
minutes-95-spring-1

Meeting Minutes Source Packet Routing in Networking (spring) WG
Date and time 2016-04-05 17:00
Title Minutes for SPRING at IETF-95
State Active
Other versions plain text
Last updated 2016-04-15

minutes-95-spring-1
Source Packet Routing in Networking (SPRING) WG

        Tuesday, April 5, 2016
        14:00-16:00  Tuesday Afternoon session I
        Room:  Buen Ayre C

Chairs: John Scudder <jgs@juniper.net>
        Bruno Decraene <bruno.decraene@orange.com>

o Administrativia                                          15 minutes - actual
start 2:03 pm local
    http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=220

  Chairs
 - Note Well
 - Scribe
 - Blue Sheets
 - Document Status

John Scudder>
Note well
Problem statement received a number of comments from IESG, hoping to resolve by
end of week. Arch doc, completed WGLC, making some changes proactively based on
feedback from IESG on problem statement, if changes are large, we may do
another WGLC. OAM use case - authors have asked for it to be last called, will
do this week. Two more use case docs, working on trying to move them forward
due to IESG request to get reqs to them before the architecture document.

No Q&A.

o SR drafts update                                         20 minutes  - actual
start 2:08 pm local
    http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=525
        https://www.ietf.org/proceedings/95/slides/slides-95-spring-0.pdf

  Stefano Previdi

SP> Problem statement draft close to resolving all comments, large number
detailed on slide 2.  Removed some text on comparison between RSVP and SR,
clarified a number of sections and put pointer to IPv6 SR draft.  Moved a
number of requirements from SHOULD to MUST and added some text that SR is
referring to the label stack.  On next slide, a number of comments received
that we have not addressed in the draft - explanations on the slide.  First
item out of scope for draft, other document (resiliency draft).  Don't plan on
changing terminology from SPRING to SR.  On the TE use case draft, we had a
draft, WG should let us know if we should resurrect TE use case description as
it's expired.  Most comments received are addressed in the actual
implementation drafts so it's not felt to add value to the problem-statement
draft. One comment on problem statement draft is whether or not we need a draft
for something that is in architecture, implemented by multiple vendors and
deployed.  Since a lot of work was put into these drafts, authors would like to
continue to advance them however.

Next slide has 3 other use case drafts which we are waiting for problem
statement to go first, they describe various other use cases.

On architecture drafts - still addressing some comments on segment-routing
draft as John Scudder mentioned (from IESG), and working through comments on
IPv6 and MPLS dataplane as well.

Two other documents are pending for WG evaluation.  There was little feedback
on the draft-filsfills-spring-sr-recursive-info draft, please comment.  large
scale interconnect has update but missed IETF cut-off window.

o Segment Routing Conflict Resolution                      20 minutes - actual
start 2:19 pm local
 http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=1170
 https://www.ietf.org/proceedings/95/slides/slides-95-spring-1.pdf

  draft-ginsberg-spring-conflict-resolution-01
  Les Ginsberg

Les Ginsberg> version 00 presented last IETF, have not done update but had
discussions on list, will be soon.  Goal is to address conflicts since SR
identifiers are global in scope.  Two issues that draft addresses: First - when
multiple SRGB ranges overlap advertised by sendor, agreement has been reached
on list email (not currently in draft).  If overlapping ranges, ignore all SRGB
from that node. Second issue - prefix SID conflict advertised by multiple
nodes, conflicts could occur.  Two options thought of, ignore all
advertisements that are conflicting or apply some preference rule for which to
use.  Draft is currently agnostic. Ignore is easy to diagnose but impacts all
destinations.  Preference rule may allow traffic forwarding but may be hard to
diagnose and may not be noticed right away. Slide 8 reviews terminology to
discuss these options further.  Two kinds of conflict - prefix conflict (two
prefixes same SID), or SID conflict (SID has been mapped to multiple prefixes).
 Preifx conflict is intra topology/VRF. SID conflict is inter-topology/VRF. If
preference rule implemented not based on source of advertisement, only content
of advertisement.  All routers must have consistent database and conflict
resolution only applies to actually advertised (vs configured) information.
Preference rule proposal (not current in draft -00) - smaller range wins,
biases choice towards prefix advertisements (typically /32 or /128) vs SRMS
advertisements.  However if you are doing LDP interop via SRMS mapping, you may
have case during migration where a non-SR node has config added for advertising
SID's and may still want to use SRMS mapping vs locally configured (possibly
incorrect) information. So, if you detect a conflict, what does the
implementation do - 3 choices are outlined:
    1. Quarentine - last entry that has conflict (the one bad entry) is
    excluded from use. 2. Overlap only - break entries up to avoid the conflict
    and only exclude the conflicting ranges after fragmenting.
        2. Ignore - ignore all conflicting entries.

Q&A: started 2:34 pm local
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=2030

Acee> If you quarantine or ignore entries, would you bring them back if the
entries change and the conflict disapear. LG> Yes. Anytime the entries change,
the policy is re-applied. Alvaro Retina> - why IPv4 over IPv6 in 2nd rule? LG>
Don't care. We'll follow consensus. Alvaro Retina> In general, that's the
direction. Jeff Tansura> would be good to hear from SP's on whether we should
use this preference rule?  We should get some concensus on this ASAP due to
implementations deployed already. Certain implementations already doing types
of selection. John> Is your point is that we need to hurry up. Jeff Tansura>
Yes, if possible. Uma Chunduri (Ericsson)> Why do we have to compare mapping
server prefixes with other SID prefixes? These two are different. Some
implementation may not support mapping server. LG> Even if doesn't have mapping
server, if you have a deployment rule has to identify preference for this. Wim
Henderickx (Nokia)> We believe Quarentine is our prefered option: simple
implementation and some benefits that we are trying to achieve. Bruno Decraene
(Orange, as WG contributor)> Question on slide 7 - why do you say it's easier
to diagnose preference rule versus ignore, either way notification can go to SP
about conflict (from implementation). LG> We don't have to agree on this, but
we have to agree on preference policy. BD> But why do you say this? LG> Because
the traffic if ignored will all be dropped, so will be noticed sooner. BD> So
you mean it's easier to detect. Then I disagree we have to drop all this
traffic to do detection, most operators will catch it even if you drop some of
the endpoints traffic. JT> We are listening, which is why we proposed the
overlap only implementation (fragmenting the ranges). LG> Yes, we want to agree
on the preference rule and the policy to apply. - in my opinion, we should use
quarentine which minimizes some of the damage and is easier to implement vs the
overlap only which is complex. Shraddha Hegde - Juniper Networks> I agree with
putting smaller range at top, on the policy side, i think overlap gives maximum
advantage to operators, I think that should be the preferred one. Acee Lindem -
Cisco> I agree with Les that Quarentine is simpler, this is an error case, we
shouldn't have a lot of complexity in the solution. John Hardwick - Metaswith >
I highly prefer quarantine. BD> Improved compared to -00. Better to give
preference to prefix SID. With quarentine you can still blackhole a lot of PE,
but at least it's the LDP/non-SR ones, and this set should reduce as SR gets
deployed. But I need to read draft carefully, this is the right direction. JS>
Bruno - question for you - in BGP we took simple approach for 20 years but the
error cases were not as exceptional as we thought they were so we had to do
more complex error handling.  What do we think about (rarity) of this case? BD>
I think for anything that can be done as an operator CLI error, this will
likely happen at some point, it will not be that exceptional. I need read/think
more about the draft. LG> This is not an implementation specification on how to
store the active or excluded entries in overlap case, this doesn't specify
that. Acee> I think this is very different from BGP error handling or
redistribution errors.  In this case mapping servers are in same domain, and
unlike redistribution SID are explicitly configured, not dynamically created
based on state.   This would only happen with two mapping servers configured
differently in the same admin domain. JS> Nothing could go wrong (sarcasm). BD>
Errors can happen, like in migration cases.  They can happen for a number of
reasons (operator or implementation). JT> We will incorporate errors into the
Yang model and notifications if found. SH>> Different SID coming for same
prefix, one coming from SRMS and one prefix SID example. SRMS wil typically
advertise a range covering both SR capable and LDP/SR non capable nodes. With
Quarantine, a single error on a prefix SID will exclude the whole SRMS range.
LG> For any rule we can make, it will not always make optimal decision for some
example of misconfiguration. Stewart Bryant (Meetecho chat)>could you get the
problem under a failover condition between two config servers? If so the you
might needlessly take out a large slice of the network while you resolve this.
I agree with the need for robustness LG> We are asking for adoption when we
release -01 which includes the various options presented today, we just want to
take it on as WG even if we don't have concensus yet on which options to
choose, expect -01 in next week. Chris Bowers> In -01, present the
possibilities but make it clear that it's not yet decided but up to the WG to
decide. LG> Point taken.

o A Framework for Computed Multicast applied to MPLS based Segment Routing
  https://www.ietf.org/proceedings/95/slides/slides-95-spring-2.pdf
  http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=3540

  draft-allan-spring-mpls-multicast-framework-00           15 minutes - actual
  start 2:59 pm local David Allan

David> This draft is about multicast over MPLS SR, may be able to work for IPv6
SR but have not investigated.  Describes how we can make multicast trees that
are explicit or loose, and able to use SR dataplane to implement.  This draft
requires all nodes can make same decisions about multicast trees by putting
this information in the IGP.  If we combine this with unicast tunneling
approach, there are benefits.  For instance since we are putting in IGP,
topology change is only messaging required.  Large state reduction, 30% of
bandwidth savings in most deployments, re-use existing MPLS dataplane.  Since
using tunnels, don't need to do full computation. Tree generation in this
appraoch is a bit complicated.  To be ECMP friendly we need to make sure no
duplicate packets are sent, by creating a minimum cost trees.  We need a unique
solution per S,G tree. Tree pruning - two types of prunes - if we fully resolve
tree are known to produce minimum cost tree, this will sort out 97% of leaves. 
Second type is described as best guesses for those that weren't resolved with
first approach, with good guesses only a small set will need a fix to tunnel to
a neighboring node.  This is computationally intensive but advantage is less
state.  This approach has less state sync between control and data plane
however. Next slide has graph with proof of concept code results.  Run on
laptop, resolves 1.2M endpoints/sec in a thousand node network.

So far have described making minimum cost trees, to do a strict tree, we just
concatonat loose trees, we do this as a strict or loose tree can be strictly
loop free, but a hybrid tree can't guarentee this. However by having unique SID
per tree, and describing the cross points / way points with that SID, we can
specify the tree as a unique item in IGP.  This is -00, future drafts for IGP
extensions and interworking with existing mechanisms, goal is standard track.

Q&A
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=3540

Greg / Cisco - what is the problem trying to be solved by this?
DA> this creates minimum cost trees with minimum messaging.
Greg> The challenge is the flow state itself, just minimizing doesn't get rid
of it.  I'm wondering if are really looking at the fundamental issues with
multicast rather just moving the problem into SPRING. DA> I had this approach
from SPB, and Spring has some advantages over SPB. Greg> I'm not sure about the
30% bandwidth savings either, I think we should try to get rid of the
requirement of messaging in multicast. DA> Are you referring to BIER? Greg>
Yes. DA> My understanding is the bandwidth savings requires entropy and level
lookups. Greg> Replication is the challenge, there are implementations that can
do the lookups for BIER. DA> I think the most optimum approach is minimum cost,
least hops. Greg> Use a subdomain. DA> I tried prototyping BIER, it adds a lot
of complexity to dataplane, compared to control plane, technology trends aren't
friendly to dataplane changes. Greg> I don't doubt your experience, but talking
to silicon vendors, they don't want more state, so they think BIER is a net
advantage. Chris Juniper> More on how this works, for a loose tree, you would
just go into tree with single label, for a combined tree you would use a stack?
DA> No, I have waypoints where I cross connect the labels, I can't put a 2D
thing into a 1D label. Chris> add more details on this in draft.

o Packet-Optical Integration in Segment Routing            20 minutes - actual
start 03:17 pm local
  https://www.ietf.org/proceedings/95/slides/slides-95-spring-3.pdf
  http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=7116

  draft-anand-spring-poi-sr-00
  Sanjoy Bardhan

Sanjoy> Goal to expose optical elements into the IGP.  Use existing IGPs and
scale for metro and DC edge scenarios. Next slide, A/B/E/F packet, D/E are
packet/optical gateways, they will advertise different optical paths they have
available with specific characteristics.  Packet optical gateway announces
itself to IGP domain, and announces transport segments as opaque transport
segments.  POG map label on packet side to right forwarding action optically.
Changes will be required for segment-routing-extensions (IS-IS) draft as well
as changes for OSPF/BGP-LS, and PCEP-LS to communicate this new information.
Packet header slide - an opaque sub type could be signalling an L0 or L1.  For
segment routing extensions added a flag to say node could perform packet
optical gateway function.

Q&A - 3:26 pm local
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=7620

Daniele Ceccarelli (Ericsson)> Are the optical paths pre-provisioned or dynamic?
SB> There is GMPLS in core
DC> Are these paths pre-provisioned or can I provision through this mechanism
new paths? SB> Pre-provisoned. Acee> What information would the PCE use of this
new information, not clear. SB> Bandwidth/latency/protection vs
restoration/other optical nature characteristics. Acee> Not defined in draft
today. SB> Outside scope of draft, but potentially. Wim Henderickx (Nokia)>
There is binding TLV in SR, could you use that framework as start for this? SB>
We could take a look at that. Stefano> We tried this recently with last attempt
L2 bundles in IS-IS draft.  I think this is a good idea to get more information
about L3 adjacencies.  I think this makes sense, but you should look at what is
already being done in various IGP working groups. JT> I think binding TLV is
the right approach for this requirement. Igor Huawei> In TLS(TEAS?) working
group we have idea of not permitted link. This is not a novel solution. SB>
These are not IP links, the goal is to adv. Just want to bring this discussion
into using SR solution space. Acee> Today you are using GMPLS. Igor> The
optical path you have to consider whether you can actually use this path as an
IP link, it has to have that capability. Stefano> You only want to give the
optical characteritics of the IP links in the topology. We can already
advertise multiple Adjency SID for an IP link. SB> Yes. Stefano> Seems you need
multi-adjacency SID for each optical path under the IP link. SB> The main thing
we want to avoid is increasing the number of links in the topology. Richee?> In
PCE, we have inter-layer model for connecting optical layer, we should talk
about existing similar ideas. SB> Yes, after this discussion, we need to start
discussion. Richee> Better to use PCEP implementations for sharing this
information between layers. SB> Optical link characteristics need to be gotten
by PCE. Richee> We have PCEP for that. Rajiv Asati Cisco> I'm scratching head
on putting this information into routing domain, isn't main reason to get this
information to PCE. SB> Yes, main reason, other reason is that adjancency is
not a standard IGP adjancency so not part of path calc.  Headend can look at
domain ID's that are part of segment list and make decisions (out of scope of
draft). Rajiv> Controller can tell headend already this information. SB> This
is the policy part of it, for future use.

o Node Protection for SR-TE Paths                          10 minutes - actual
start at 3:40 pm local
  https://www.ietf.org/proceedings/95/slides/slides-95-spring-4.pdf
  http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=8460

  draft-hegde-spring-node-protection-for-sr-te-paths-00
  Shraddha Hegde

Shraddha> Since midpoints don't maint state, you don't know which LSPs are
traversing the midpoint.  With RSVP, you have this information so you know the
nexthop node (NHN).  Point of local repair (PLR) needs to find the next node in
label stack.  When you build explicit paths using node SID's, if one of the
nodes in that path goes down, without looking at next label in stack it's not
possible to figure out where to forward traffic.  SR must look at next label to
forward to, diagram shows explicit path to R5 by using one extra label to send
traffic through R8.  If SRGB is different on R8, R7 needs to forward packet
that has 3005 1008 on stack, needs to understand 3005 using node R8 SRGB.  If
you build context tables for all neighbors to understand each nodes SRGB +
index to get label understanding.  However SPF needs to be done individually
for those neighbors so that understanding of forwarding decision is known as
well.  So to build this context table, R7 builds context table for all prefixes
that would forward to R8 to be able to provide FRR protection.  For Adj-SID's
the method for building the context table is similiar but includes all
Adj-SID's advertised by the protected node. For Binding SID's, if R2 advertises
a binding SID to R4 (could be RSVP-TE or some other technology), R1 would have
to look into context table of R2 and do corresponding actions.

o Tunnel Segment in Segment Routing                        10 minutes - actual
start at 03:53 local
  https://www.ietf.org/proceedings/95/slides/slides-95-spring-5.pdf
  http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=9285

  draft-li-spring-tunnel-segment-01
  Xia Chen

Xia> Due to lack of time, I will go right to comparison between tunnel segment
and binding segment.  Many types of segment types in architecture.  Two
scenarios in architecture, mapping server or tunnel headend binding segments. 
This draft has another type, tunnel segment.  This has 3 use cases, reduce SR
stack size, span non-SR domains, or support multiple services.  Can be RSVP-TE
tunnel, SR-TE tunnel or IP tunnel, first two types can have primary/secondary
paths. Comparison slide - tunnel segment can carry more information than LSP
segment.  LSP segment has to readvertise if the paths change for the RSVP-TE
LSP, tunnel segment is stable, does not need re-advertisement.  It also carries
further info of tunnel identifier and tunnel attributes. Require extensions to
IGP to carry additional information of tunnel segment, next slide shows all
related drafts required to fully support tunnel segment in all protocols.

Meeting closed - 4:01 pm local