Wednesday, March 5, 2014

1:00 PM

1:04 pm Meeting Started - AD preso


IPR - you will be harassed at every step of doc progression


Agenda re-ordered to match milestones

AD guidance - other WG's (such as OSPF and IS-IS) may accept spring related drafts, will have to be discussed in Spring and WGLC in both groups, cross-posting recommended.  WGLC should not occur until arch doc is completed.


Alia (mic):

new AD commented that codepoint early allocations can be done earlier for these docs


Milestones slide -

Nothing yet, we want to close the early milestones so we are not late.  Want to focus on getting a merged set of use cases WGLC before next IETF.  If there are significant use cases that may affect the arch, need to hear about it soon.

By IETF91, when we will be on beach (except during Spring WG) we need to have stable arch doc  through WGLC for deadline.


1:13 pm Clarence Filsfils -  draft-previdi-spring-problem-statement-00

Even though consensus reached on use case, it included solution so rewritten to remove solution.  So now called problem statement draft, includes use cases from original draft, and cover additional items in charter that were not previously included in draft.

WG adoption?  Or contributions?


welcome chairs request to merge problem statement with FRR and OAM problem statement, we can take AI to do this

Ilya Varlashkin

Would node protection or path protection be covered by any of these problems?


it's included, maybe easier to read reqs in three docs, but welcome merging it back.  Currently in resiliency draft.

Greg Mirsky / Ericsson

 when you say problem statement do you mean requirements?

(audience laughter)

John Scudder

Paraphrase - does it have reqs?


Not sure on proper term, there are a list of reqs in the draft, not sure if should be reqs draft or problem statement document.


OAM has reqs draft not problem statement -


not sure if we need to rename, but it's most important that it covers use cases


when we look at milestones, it talks about OAM requirements and use cases.   We want to merge these drafts.


so problem statement does not include requirements?

(audience laughter)


there is obvious overlap between reqs and use cases.  Use cases are high level requirements, requirements are detailed reqs per specific protocols, like for MPLS, etc.. Does that explain it?


ok, when we get to OAM reqs doc, we'll figure it out


these are the source docs that are proposed to merging, Alvaro and I discussed and important thing is these are right source docs covering right material, don't need to wait for merge b4 adoption, will call for acceptance on the component docs then have merged to become -00.


1:22 pm Pierre Francois - draft-francois-spring-resiliency-use-case-00

How resiliency can be achieved in spring networks and co-existence with existing approaches

1st: Path protection - ingress node has backup path based on adjSID's, installs failover traffic with different set of adjSID's from primary path after detection (for instance through BFD)

2nd: Management free local protection - typical FRR, every node on path has backup path to protect links on a path, goal is 100% coverage, link, node, SRLG, pre-computation by every node expected.  Trying to achieve have transient recovery where backup path is diff than convergence path.


Managed local protection - bypass of default local protection through managed backup paths to meet certain goals by operator.  Could be explicitly configured or through higher level constraint describing properties desired instead of exact path


Co-existence - typically operator may want existing management free protection and for other services use path protection, operator should be able to choose different protection schemes for different services

If configure adjSID bound to link, could say if link local protected or not, one could be local protected, one not.  Choice of which path to use (with what protection scheme) could be made at ingress node.


Greg Mirsky / Ericsson

on first slide end-to-end, is this uni-directional or bi-directional traffic that is supposed to be protected?




Then BFD will not provide protection


I will distinguish in next version



next slide, if you do node protection how can you do local protection if you have no knowledge of path on transit node


2 choices there, detect failure of link, assume node may have failed <cut-off>


how do you select MP?  Must know info on path as multiple possible MP?  Transit node has path information which is excluded from segment routing paradigm.


In previous case you are mixing two slides.  if you have path expression, each expression is list of segments ip dest.  Each has nh intf.  Each node only reacts to top segment, if segment is not reachable, you can use pre-signaled backup path


that can easily create routing loop



no hats on.  what is in doc makes sense for hop by hop, not clear about use case for equivalent of RSVP-TE where segment is next node.  How do you get node protection in that scenario and is it in scope?


that is discussing about solution


no, I'm talking about the use case, is node protection for explicit routing use case in scope for doc or focus on hop by hop we all love.


Can I but in?  If you Alia or anyone else  think there is missing use case, please propose it


just wanted to know if you were trying to cover it


this first one is exactly path protection, two others are local protection only



Does your draft cover case where you have explicit path?


that is management free local protection


But would you do explicit path protection using link or node protection, you exclude it


No, I do not, I will do local protection for just that part of the explicit path <take to list>


Zhenbin Li / Huawai

I agree SR solves some protection issues.  But we should understand what use case we cannot cover with SR.  This use case is full mesh, explicit path, many hops, needs lots of segment, large header.


An operators want it, some vendor say will support this.  I am ok to remove if through consensus.  I agree some folks may not want to do and vendors can't support it, but should be discussed


if this case cannot be implemented, then co-existence may be a mandatory choice.


it's true that if in your network you cannot accommodate that protection type, you will need to deal with it <one more back and forth cut-off>



this is the other draft we want to merge, I know there are some comments, please comment soon on list, we will call for adoption soon.  We will merge this doc if adopted.


please any addition welcome, we believe all comments at mic were covered, but please send suggestion so we can move fwd


1:39 pm Clarence Filsfils - number of draft progress updates

Use case doc - covering history again, had solution in it.  Illustration of solution, so we can't adopt now but we will keep it around until after problem statement.  We will keep maintaining it and change name if necessary.

Segment routing draft - first milestone is problem statement, then 2 IETF from now is arch doc.  This document had consensus but some good feedback from Juniper, and then a new published doc on their side.  We meet with Juniper, we will these two merge documents and after two weeks of discussion by next IETF we hope to get adoption for new document.

IPv6 document - submitted yesterday, I thought we could do better but suggestion that earlier is better so it is published but may not be totally accurate.  Proposed ipv6 header extension and use case docs.  Stefano says actually going to be submitted today or tomorrow.

Last slide is summary of most important drafts published.  Ones that need merge at top.

SR protocol extensions block - will move fwd in the other WG now that permission is there, welcome for comments in IS-IS or OSPF WG.

Last block of drafts -  first draft says MPLS dataplane doesn't need change, 2nd say LDP interop that operators have stated they want.


1:47 pm Ruediger Geib - draft-geib-spring-oam-usecase

First introduced in Berlin, not much change on this slide.  Idea is single monitoring system that can monitor complete MPLS domain.  Monitor needs to be aware of MPLS/routing domain.  Idea is from center system availability of all edge router path issues detectable.  Move packet to place for start of measurement, then take specific path (through segments) to endpoint, then send back to monitor.

Some discussion on list - not important how packet gets to starting point LER, nor important how it gets back to monitor from destination LER.  But path must be available.

To do this: trace all LSPs between source LER and destination LER.  Use RFC4379 type packets, analyze reply and generate segments to use all ECMP paths.

Do traces and injected packets in off peak times as utilizes LER CPU.

Sam Aldrin

you can use existing draft for MPLS proxy lsp ping, what is new?


you can do label stacks with proxy lsp ping?


don't need label stacks you can send out proxy LSP ping


we don't need to specify solution


yes but not a use case if solution exists

Hannes Gredler

you can't do it in recursive fashion, proxy ping for a proxy ping for a proxy ping.


you can specify endpoint and proxy to start


you can't describe path to be probed, it's not recursive, proxy ping not solution

Greg Mirsky

is this really for monitoring to trigger switchover or path verification


this is a tool not specifically for path protection detection but possible


what is the frequency, can you get 300 ms (detection/switchover?)


if domain is small, may be possible, but this depends on your requirement

Name missed / Broadcom

what is application if issue detected?


trigger action

Name missed / Broadcom

can't trigger any action as you don't know where failure is, packet goes through entire network


based on real operations req


will take several minutes to detect this way

Ed Crabbe

few minutes not bad, we do this today (not unique), we do based on minima set of LSPs crossing a link to determine link problem

Name missed / Broadcom

why not run BFD session per LSP

Jen Linkova /  Google

this may not


Take offline - suggestion that this is possible today

Jen Linkova

how do you handle entropy label


use case document, not solution, RFC ???? allows 64 destination with single ping, would like to have for entropy label and other cases


next use case slide, link bundle monitoring via diff adjSID per member, if no reply test all individual links, segment routing allows you to tell which link has issues


this was a use case, next one related, oam requirements for SR net


2:00 pm Greg Mirsky - draft-kumar-spring-sr-oam-requirement-00

try to cover generic oam reqs to both possible SR dataplanes, either from monitoring station or path headend

Next slide - verify ECMP or non-ECMP arbitrary paths, CC/CV = continuity verification or continuity check.

Altogether sixteen reqs - open for discussion/comments or more reqs


Ilya V

given nature of SR, one more req - one node may create loop through constructed label stack, could this be OAM requirement to detect, other packets just continue to flow.


TTL, not OAM function?


for mpls, may not rely on that, is this suitable for an OAM req or do we need more intensive discussion on list


interesting problem, but if someone constructed (it is a valid path)


or bug?


ok, can't detect bugs

Stewart Bryant

could be a feature, lots of use cases use loop


2:05 pm Pierre Francois - draft-francois-segment-routing-ti-lfa-00

Solution doc.

Topology independent FRR using SR, in family of FRR solution in context of SR

Whatever topology, full coverage for link/node failure

SR allows any path, we enforce on loop free

Which path to choose: traditionally would use sub-optimal nodes sometimes that are loop free, now with SR can choose post convergence path and go to core nodes rather than through edge (PE) nodes that otherwise were not loop free alternates.

Post convergence path more in-line with capacity planning model, enforce path that makes sense rather through cross oceanic paths for example that were loop free

With SR no TLDP, so we don't have to combine LFA/RLFA to get full coverage

Motivation was LFA manageability draft - covered cases where LFA path was not ideal, each time operator wanted post convergence path, it's common sense.  Use IGP SPF.

Don't take packet all the way to end, release packet at right place to safely forward onward to destination through figuring new SPF and get to first node that will take you that direction (w/o loop).

Homework - how many segments do we need?  Some analysis on next slide, not in -00 draft.

Link protection - max 2 with symmetric, most in 2 for asymmetric metrics but sometimes longer

Node - never more than 4, rarely more than 2

-01 draft will contain numbers/analysis

Can protect adjSID paths as well by getting it back to endpoint of adjSID through SPF to that node rather than end node

Greg Mirsky

if we change topology and no link CD, then packet will overload DF (loop back through DF link)


yes, this is definition per link topology otherwise would be node protection.  Up to operator which to choose (covered on next slide) based on intent, does it really need to go to next node or not

Summary - full coverage, no TLDP, more flexibility in path we define, use post-convergence paths, 1 implementation, 1 on way, if more please share

Ilya V

go back to protecting adjSID's slide, how do I know only link failed and not node D


that's a choice, if you do link protection only, and node fails may not get what you want


should I do both link and node?


in co-existence discussed - passed to Clarence


a bit out of context, 10 years of history on FRR, this is same as normal FRR for link vs node protection behaviors


other question - u can do link/node/or both


2:24 pm Xiaohu Xu - draft-xu-spring-islands-connection-over-ip-00

Use case draft.

Current arch assumes E2E LSP between SR, if need to deploy in places where non-SR paths in midpoint of SR routers path, desirable to connect these.  With this, only need ingress/egress/service nodes to support SR, others can be IP forwarding only

Option 1 - if adjacent to non-SR router, can fwd over ip-tunnel to remote SR router, limitation cannot be PHP label

Option 2 - router X can advertise ip tunnel to X as adjacent segment

Sarat: how does it know Z supports MPLS

Xiaohu - Z is SR node, advertises


2:29 pm Kireeti Kompella - draft-kini-mpls-spring-entropy-label-00

How do we get right entropy to get ECMP LB?

SR-MPLS uses hierarchy, makes deep labels more likely

Solutions here are options, none are great.  So which option is least evil if LB is important?

Option 1 - entropy label at bottom - popping at top so otherwise may be popped, but may be too deep so

Option 2 - put at every hop, label stack depth is 3x # of tunnel labels

Option 3  - re-useable EL below top of stack label, requires pop then move label there below the next label down

Option 3a - put EL at top of stack, then pop from non-top label, go past ELI and EL and pop 3rd label down

Option 4 - advertise via IGP limit of labels each node can handle, then put EL at specific depth just enough so nodes can still process along path - about 40% savings over option 2

Related work - first covers stuff you should/shouldn't do for MPLS forwarding stacks

2nd is hierarchy related Seamless MPLS case for entropy labels - similar problem not as deep stack

Is it important, what should we do?


thank you for preso, absolutely important for ECMP.  To use analogy, we build tech for fire if it occurs, but it is rare.  Useful work - lots of things to be done to not have fire (reduce likelihood).  Option 4 - not just flooding, but if centralized path program could already take account of capability of label depth per router.  In studies, we don't see this issue often?


my brain is on fire.


I think heard deep label stacks are issue but we should build tech to deal with

Greg Mirsky

we expect entropy label on segment scope?  If we explicitly specify segments, they are only on segment scope.


IM doesn't know where segment is ending


it's up to endpoint of segment to enforce or not enforce Entropy label?


still confused, folks at mic are fighting it out, not getting it

Gregory Cauchie

we are interested in how to LB, have many 10G LAG's

Stefan Orange

clear need, increasing usage of LAG and ECMP, big pipes not cheap, PW's have increasing BW reqs from access PW, need to LB in core


in SR IEEE extensions, can announce N labels for a single link (LAG) and ingress can compute.


LB is stateless, you just suggested state, much work on headend to ECMP


trade-off may be possible in existing hw

Curtis Villamizar

this is equivalent to link bundling

George Swallow

to Greg's question, scope of entropy label is anywhere in scope but node has to advertise


+1, important problem to solve, thinking about Hannes option, but another option, egress PE's could mask off some number of bits for labels they are responsible for.  Flip side this could be very deep in stack.


if you do option 4, and you find all LSR's are capable of N, then you are back to option 1.


yes, if everyone can do 10, but if Geib adds 24 for his use case, not every device may support it


2:50 pm John Scudder - wrapping up

looking forward to more conversation like this on ML so can make progress by Toronto