IETF89 - Spring WG minutes

IETF89 - SPRING

Wednesday, March 5, 2014

1:00 PM

1:04 pm Meeting Started - AD preso

Alvaro:

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?

Clarence	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?
Clarence	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?
Clarence	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.
Greg	OAM has reqs draft not problem statement -
Alvaro	not sure if we need to rename, but it's most important that it covers use cases
Alvaro	when we look at milestones, it talks about OAM requirements and use cases. We want to merge these drafts.
Greg	so problem statement does not include requirements? (audience laughter)
John	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?
Greg	ok, when we get to OAM reqs doc, we'll figure it out
John	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?
Pierre	Uni-directional
Greg	Then BFD will not provide protection
Pierre	I will distinguish in next version

Greg	next slide, if you do node protection how can you do local protection if you have no knowledge of path on transit node
Pierre	2 choices there, detect failure of link, assume node may have failed <cut-off>
Greg	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.
Clarence	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
Greg	that can easily create routing loop

Alia	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?
Pierre	that is discussing about solution
Alia	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.
John	Can I but in? If you Alia or anyone else think there is missing use case, please propose it
Alia	just wanted to know if you were trying to cover it
Pierre	this first one is exactly path protection, two others are local protection only

Ilya	Does your draft cover case where you have explicit path?
Pierre	that is management free local protection
Ilya	But would you do explicit path protection using link or node protection, you exclude it
Pierre	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.
Pierre	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
Zhenbin	if this case cannot be implemented, then co-existence may be a mandatory choice.
Pierre	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>

Alvaro	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.
Clarence	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?
Geib	you can do label stacks with proxy lsp ping?
Sam	don't need label stacks you can send out proxy LSP ping
Alvaro	we don't need to specify solution
Sam	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.
Sam	you can specify endpoint and proxy to start
Hannes	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
Geib	this is a tool not specifically for path protection detection but possible
Greg	what is the frequency, can you get 300 ms (detection/switchover?)
Geib	if domain is small, may be possible, but this depends on your requirement
Name missed / Broadcom	what is application if issue detected?
Geib	trigger action
Name missed / Broadcom	can't trigger any action as you don't know where failure is, packet goes through entire network
Geib	based on real operations req
Sharon	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
Alvaro	Take offline - suggestion that this is possible today
Jen Linkova	how do you handle entropy label
Geib	use case document, not solution, RFC ???? allows 64 destination with single ping, would like to have for entropy label and other cases
Geib	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
Alvaro	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.
Greg	TTL, not OAM function?
Ilya	for mpls, may not rely on that, is this suitable for an OAM req or do we need more intensive discussion on list
Greg	interesting problem, but if someone constructed (it is a valid path)
Ilya	or bug?
Greg	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)
Pierre	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
Pierre	that's a choice, if you do link protection only, and node fails may not get what you want
Ilya	should I do both link and node?
Pierre	in co-existence discussed - passed to Clarence
Clarence	a bit out of context, 10 years of history on FRR, this is same as normal FRR for link vs node protection behaviors
Clarence	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?

Clarence	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?
Kireeti	my brain is on fire.
John	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.
Sri	IM doesn't know where segment is ending
Greg	it's up to endpoint of segment to enforce or not enforce Entropy label?
Kireeti	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
Hannes	in SR IEEE extensions, can announce N labels for a single link (LAG) and ingress can compute.
Kireeti	LB is stateless, you just suggested state, much work on headend to ECMP
Hannes	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
Shane	+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.
Curtis	if you do option 4, and you find all LSR's are capable of N, then you are back to option 1.
Kireeti	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