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