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

Source Packet Routing in Networking (SPRING) WG

Tuesday, July 21, 2015
13:00-15:00	Afternoon session I
Grand Hilton Ballroom

=====================================================

CHAIR(s):  Bruno Decraene <bruno.decraene@orange.com>
           John Scudder <jgs@juniper.net>
           
Scribe: John Scudder <jgs@juniper.net>
Time stamps are approximate offsets into audio recording, not 
wall clock. (Very approximate, it turns out the software I was
using for MP3 playback is pretty horrible.)

Agenda:

o Administrivia
  Chairs                                                 10 minutes

  - Note Well
  - Scribe
  - Blue Sheets
  - Document Status

o Update on WG drafts                                    10 minutes
  Stefano Previdi

o YANG Data Model for Segment Routing                    10 minutes
  draft-litkowski-spring-sr-yang-00
  Stéphane Litkowski

o Anycast Segments in MPLS based SPRING                  20 minutes
  draft-psarkar-spring-mpls-anycast-segments-00
  Pushpasis Sarkar

o Advertising Per-Algorithm Label Blocks                 10 minutes
  draft-bowers-spring-adv-per-algorithm-label-blocks
  Chris Bowers

o SPRING SID Allocation                                  10 minutes
  draft-lw-spring-sid-allocation
  Ting Liao
  
o Interconnecting Millions Of Endpoints With Segment Routing
  draft-filsfils-spring-large-scale-interconnect      
  Dennis Cai                                      If time available
      
Speaker Shuffling Time                                    5 minutes

Total                                             1 hour 15 minutes

=====================================================

0:09 
o Administrivia
  Chairs                                                 
 
No Q/C

-----------------------------------------------------
0:24
o Update on WG drafts                                   
  Stefano Previdi

0:38
Jeff Tantsura: Suggest moving TI-LFA to RTGWG.

-----------------------------------------------------
0:49
o YANG Data Model for Segment Routing
  draft-litkowski-spring-sr-yang-00
  Stéphane Litkowski
  
No Q/C

-----------------------------------------------------
1:09
o Anycast Segments in MPLS based SPRING
  draft-psarkar-spring-mpls-anycast-segments-00
  Pushpasis Sarkar

1:30
Uma Chunduri: (in step 4) proposal is to use the index as the label?
Pushpasis: yes
Uma: not explicitly mentioned
Pushpasis: it's in the pseudo-code. sometimes you might have multiple anycast 
segments followed by one another. pseudo-code looks complex but covers such
scenarios. 
Uma: index has an associated label
Pushpasis: it's motivated by the problem statement. A1 and A2 (slide 1) all
they have in common is the index of the destination, their labels may be 
different
Uma: hardware has to support indexed label lookup
1:35
Stefano Previdi: Interesting solution. No arguments. But a simpler solution 
is if you support a common srgb
<laughter>
Uma: common srgb is impractical
Stefano: it's mostly there. mostly.
Pushpasis: If we could do a common srgb, this problem wouldn't exist. But,
it's a practical problem between vendors.
John Scudder (as WG participant): "If we had ham, we could have ham and eggs, 
if we had eggs"
Hannes Gredler: "it would be really great if we would all be rich, so let's
declare we're all rich". This draft is about remedying the differences that
arise in practice.
Stefano: technically this makes sense, and is solid. just seems to me common 
srgb would be easy
Stéphane Litkowski: If everyone has common srgb, there's no need of index,
just do domain-wide labels.
1:38
Wim Hendrickx: This proposal requires all routers be modified, even if they
support common srgb. Can we do this w/o modifying such platforms?
Pushpasis: We're hoping to fix that in -01, based on hallway conversations.
Agree it's desirable since it eliminates the need for recursive label
lookup.

-----------------------------------------------------
1:43
o Advertising Per-Algorithm Label Blocks                 10 minutes
  draft-bowers-spring-adv-per-algorithm-label-blocks
  Chris Bowers

2:00 
Stefano: what's the advantage again? option 2 reduces the size of the 
srgb?
Chris: no. but yes! there's an example in the draft, using a 100 node
network, then adding a second algorithm, then adding ten more nodes.
take a look at that example. You end up with a fragmented label space.
One solution is start out with a very large label space, but it's 
wasteful.
Stefano: an implementation that has no problem with a large block 
shouldn't even need to worry about it.
Chris: It's not an issue with the size of the srgb...
Uma: this is a per-instance srgb, say only 200 labels, even though the box
(protocol) can support say 10,000, right?
Chris: right. it automates the management of the label space, compared to 
forcing you to manually manage unique, tightly packed index values.
2:05
John Scudder (as co-chair): There hasn't been much discussion on the list.
How many have read it?
<quite a few>
... OK, many of you have read it but weren't moved to comment on it. All
right.
Stefano: My comment was I don't see a practical need.
John: You guys don't sound like you have a meeting of minds about the nature
of the problem based on discussion at mic. Didn't sound as much like a 
disagreement about solution as about problem. That was my reading anyway.
2:07
Hannes: the practical advantage is you don't have to assign 27 different
indexes to a node for taking part in different algos. simplifies deployment
because a node has one index independent of number of algos. (E.g. delay-
optimised spt, metric-optimised spt, MRT, etc). Just one index per node.
Stefano: 27? who runs a network with 27 different algos?
Hannes: How would you know? You were the one who told me we'd never run more
than one, now we already have two.
Stefano: But 27?
John: Do we have to obsess about the number 27? Would 3 be sufficient to
illustrate?
2:10
Les Ginsberg: various reasons you might need multiple sids, say multi-topo.
this doesn't address it.
Chris: Uma suggested mtid. you'd then have a per-mtid, per-algo label block.
Les: mt isn't multi-algo
Chris: you'd leave the algo as zero
Les: so now you CAN advertise algo zero in the new sub-tlv?
Chris: it's a proposal, yes. there are a lot of backwards-compatibility 
approaches. WG should discuss the approach to use.
Les: if this is useful, it has to be generally applicable, not just MRT.
Chris: we'll be adding multi-topology to this. I'd appreciate your feedback
on mtid.
2:12
Tarek Saad (?) cisco: with option 2, I'm potentially assigning unused labels, 
with option 1 I can potentially assign labels or not, per-interface and 
per-algo
Chris: yes, although it's a lot of micro-management of label space and sids.
But is that a realistic problem? And by the way, I would appreciate actual 
comments on the draft and additions to work this out.
2:15
Ahmed bashandy: seems to me this is equivalent to automatically assigning 
different prefix-sids to different protocols.
Chris: you mean algos?
Ahmed: yes. 16-18k algo0, 18-20k algo1. That's one way of looking at it. 
Another is index 0 = algo0, index 2k = algo1. What's the difference? 
Chris: these node index values need to be unique and tightly packed. label
blocks ... these still can be concatenated label blocks. either way you have
complete flexibility.
Ahmed: I can too. Prefix 1.1.1 has index0 for algo0, index 2k for algo1. Or
keep index0 and assign it two srgbs. What's the diff?
Chris: reasonable scenarios create equivalent lfibs. the management overhead
of deploying the two are dramatically different.
Ahmed: I translated the proposal to automatic assignment of unique sids 
for different algos. All I have to do is instead of index0 for same pfx in 
different algos, I...
Chris: I'd like to see a fully-worked out version. The devil's in the details.
John Scudder (as scribe): hard to summarize for the notes, please put in email
Chris: if that's how the WG wants to go, we should document the convention.
The details are important.
Ahmed: the advantage of this proposal is to relieve the user of configuration 
overhead. I can do that implementation-specific, with the current spec.
Chris: Please put it in an email.
Ahmed: OK
2:22
Dmitry Afanasiev (?) Yandex: you're trying to pack too much into a
single label. They're stackable, so how about an algo- or topo-selector
label?
Chris: that's a different question. it's part of the base arch to use a 
single label. Your issue is reasonable but relates to the base arch.
Dmitry: would be nice to put a use case in the draft
Chris: the isis draft does show differnt algos
Dmitry: if you have 10s of k's of nodes, you don't want to duplicate your
global block size. For example, in DC using MPLS, you've got a lot of nodes.
Chris: that's orthogonal to options 1 or 2.
2:29
Greg Mirsky: might be interesting to look at "synonymous label", will be 
discussed in mpls wg later this week. You can assign specific actions but
they'll be treated the same in the forwarding plane. (we might change the 
name.)
Chris: yes, I just sent you an email suggesting "surrogate"
Greg: Or "associated"
2:29
Stéphane Litkowski: Getting back to Ahmed's point, from an operational
PoV it's really important to keep the addition of a new algo simple.
today with the current behavior of having to reassign an new SID value
per node is painful, it's can't be easily automated. OSS interaction is
painful. Simplifying this is good. I don't have a clear
opinion of options 1 vs 2, but making it easy to manage addition of
algos DOES need to be simple. A specific proposal from Ahmed would help.
2:31
Pushpasis: Chris's main point is that when we add an algo, the only overhead
we need is to allocate a new label block. <summarizes proposal> getting back
to Stéphane's example, I think option 2 is a better fit.

-----------------------------------------------------
2:33
o SPRING SID Allocation
  draft-lw-spring-sid-allocation
  Ting Liao

2:52
John Scudder (as WG contributor): You're using the IGP as a vehicle to remotely
configure the SID. No different from using the IGP as a channel to configure
any other option on the "zero-touch" router. My q to you (and to anyone who
looks after IGPs): Is this appropriate use of IGPs? Or should we look at 
something else, like Yang?
Ting: ...?
John: To rephrase as a comment, this seems like not a natural use of the IGP.
There might be a better way to configure the SID.
Martin Horneffer: I agree. Please don't put extra stuff in the igp. I don't want
to run into scalability and performance problems with the IGP.
Ting: ...
Rafal Szarecki: Mapping seems challenging. Seems pretty random. if you
do what you suggest if you put a new router in later, you'd have to
reallocate sids, cross-network churn, impractical. maybe there's a better way of 
mapping that's stable; less random
Pushpasis: this isn't a good use of the igp. IGP is for state, not config.
John Scudder (as co-chair): You asked about WG adoption. re WG adoption, 
polls room, how many read? 
<not many>
John: based on that, we can't get an accurate sense of the room. please ask on 
the mailing list.

-----------------------------------------------------
3:00
o Interconnecting Millions Of Endpoints With Segment Routing
  draft-filsfils-spring-large-scale-interconnect      
  Dennis Cai                                      If time available

3:16 
Acee Lindem: if you had a boundary node servicing multiple nodes, it would need
a unique sid per domain?
Dennis: yes
Dennis: greenfield/brownfield
3:18
Li Zhenbin (Robin): different areas are igp area or bgp AS?
Dennis: igp instances. not areas.
Robin: multiple areas give the scalability. not the tunnel solution.
Dennis: 70k access nodes. seamless mpls today. trying to provide seamless
mpls benefits without full mpls stack. just run the igp, plus central controller.
Robin: how many te tunnels on each ingress router?
Dennis: TE tunnels are optional. shortest-path otherwise.
Robin: huge number of TE tunnels.
Dennis: label stack doesn't imply TE. Let's not discuss implementation details.
3:26
Luyuan Fang: you know about hsdn draft. what's the arch difference
between this and hsdn?
Dennis: difficult for me to answer. I've tried reading your draft several times,
I still don't get it.
<laughter>
Luyuan: I think you got the gist. we scale to tens of millions of end points. 
label stack, identify path and destination. there may be some differences, but
hsdn we still allow use of multiple protocols for label distribution. So what's 
the major difference? are you validating the hsdn architecture?
Dennis: I don't know.
Luyuan: I want to answer Robin about TE. You partition into areas small enough 
that the number of possible paths are limited. see also sigcomm paper on hsdn.
Robin: something about scalability (not properly mic'd)
Giles Heron: this is just a hybrid approach to scaling by stacking labels,
Robin is at 50000 feet, lyuuan 10000 feet, dennis 5000 feet, different
layers of abstraction
Rafal Szarecki: why global srgb? has to be?
Dennis: it's a global *index*. indices are global within their region but there
may be reuse across multiple regions.
Rafal: Do you assume node-sid is globally unique?
Dennis: Core is unique. Leaf not.
Rafal: So I need sid->label mapping, plus some kind of leaf ID.
Dennis: Something like that, yes.

-----------------------------------------------------
3:32
meeting ends