Minutes for SPRING at IETF-94
minutes-94-spring-2

Source Packet Routing in Networking (SPRING) WG

Tuesday, November  3, 2015
09:00-10:30  Tuesday Morning session I
Room 303

o Administrivia

    Chairs                                                 10 minutes - actual
    start 09:00

John Scudder: Note: note well, some docs in last call, problem statement to
IESG, moving fast to save time for presos.

o Update on WG drafts                                    10 minutes - actual
start 09:02

    Roberta Maglione

Roberta Maglione: presenting on behalf of Stefano who couldn't make it -
updates to various drafts: segment-routing-problem-statement - version 5, fixed
IP addressing. segment routing - version 6, added clarifications on anycast,
domain definition, fixed ip addresses, still some comments coming in next rev.
segment-routing-mpls - version 2 only fix typo's segment-routing-ldp-interop -
just accepted as WG doc, some comments from Sasha need to be integrated still
(add some use cases, update refs, see list archive) segment-routing-msdc - just
accepted as WG doc, fixed author list segment-routing-central-epe - just
accepted as WG doc, fixed authors list, fixed ip addressing
filfils-spring-sr-recursive-info - just published -01 with new co-author, allow
prefix to be resolved to SID allocated to different node, couple of use cases -
node could have multiple loopback address and forward traffic to different
nodes based on which service (one service per loopback) or to different
interfaces locally attached per service.  requires new TLV to specify different
SID's. francois-spring-segment-routing-ti-lfa - moved to RTGWG, renamed (still
individual draft)

Q&A started at 09:10
Robin Li/Huawei: Interoperability between LDP and SR - not sure my concerns
have been addressed with this draft - may be issues with LDP DU (downstream
unsolicited mode) that have not been taken into account.  Need to bound the
scenarios as there are many of them, and focus on interoperability of the most
important ones. Roberta: 4 known implementations so be specific about what
problems you have seen on the list. Robin: can you confirm they cover all these
use cases? Roberta: we need to understand your concerns better. Chris
Bowers/Juniper: would be useful to have implementation report that lists what
features are in various implementations. That would be used as a basis for
checking how particular aspects are addressed. John Scudder: we will create a
space in the SPRING wiki to host implementation reports (as done in IDR). Jeff
Tantsura: orange published MPLS conference paper last year, there are some
(other?) industry presentations on interoperability as well. Roberta: I was
referring to what was presented in MPLS world congress forum. Robin: 2nd
comment - in RTG area meeting AD expressed concern (actually Alvaro) about use
case drafts in routing area meeting (scribe note: no clear direction was given
in the area open meeting on the resolution on whether use case docs should be
published - would be dealt case by case per Alia) John Scudder: we encourage
people not to just publish use case documents. If there are interesting and new
use cases that cannot be addressed via current use cases documents then time
can be spent on publishing corresponding use cases documents. We can take this
to the mailing list and continue the discussion there.

o Anycast Segments in MPLS based SPRING                  20 minutes start 09:16
        Meetecho 0:16:00
        http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF94_SPRING&chapter=chapter_1&t=960
    http://tools.ietf.org/html?draft=draft-psarkar-spring-mpls-anycast-segments-01
    Pushpasis Sarkar

Common Anycast SRGB (CA-SRGB) - new term we have defined - defines majority
network devices use a single SRGB - you can define this to help
interoperability across implementations as a vendor.  The scope since last
revision has been reduced to anycast prefix originators that don't have same
SRGB as CA-SRGB.  The diagram depicts two nodes that have 8000-9000, two with
different ranges, so 8000-9000 operator would configure as CA-SRGB.  other
nodes would implement virtual lookup table to map the label derived from
applying the index to the CA-SRGB and create mapping to local (real) SRGB on
these nodes - depicted on bottom of slide. typo on right side mapping table on
diagram in slide 7 - incoming 8080 should have mapped to outgoing label
6080(R2), not 8080. anycast devices from those not sharing CA-SRGB need to
lookup 2 labels (anycast Label --> Virtual LFIB; Second label lookuped in the
V-LFIB)

Q&A started at 09:25   Meetecho 0:26:00

Robin Li/Huawei: This use case seems to be useful. How do you plan to provision
the anycast segments? By means of some automation? Pushpasis: You put the same
IP anycast address and SID on all the nodes involved. Shahram Davari: are you
proposing any changes to MPLS dataplane? Pushpasis: this draft requires
recursive label lookup Shahram: that's a change Pushpasis: lot's of
implementations do this already, like for L3VPN Shahram: big change Pushpasis:
I don't think so, but there may be some hardware that may not support (no
agreement) Shahram: recursive label lookup anybody can do, it's the recursive
look up on a different database which is difficult Martin Horneffer: This
proposal lets devices which can configure a CA-SRGB stay with it. Only devices
not supporting the CA-SRGB would need to implement the virtual LFIB in order to
still support anycast segments. This really is the best solution possible
Shahram: I advise not to go that route and just mandate everything use same
SRGB John: we can't reopen the discussion on whether this is a global label -
resolved discussion in beginning of SR

o Addressing SID conflicts                               15 minutes - 09:30
        Meetecho 0:31:00
        http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF94_SPRING&chapter=chapter_1&t=1830
    http://tools.ietf.org/html?draft=draft-ginsberg-spring-conflict-resolution-00

    Les Ginsberg

It's important to reach consensus on usage conflicts that may occur due to
mis-configuration - so far no consensus reached, so we unblocked IGP drafts w/o
resolution to move forward and we want to try to resolve in Protocol
Independent group (Spring). first rev may not be agreeable, published to get
input. draft tries to be agnostic on approach - but may have not done this well
and we may have choose wrong approach based on comments - we presumed most
common case of issue is mis-configuring a new range alternate proposal - reject
entire config - validation is already done by implementation before allocating
labels - so this should be ok in practice as a pre-check by implementation 2nd
issue draft discusses - not going to cover today (slide 4 detail) - example on
slide 5 we cover two types of conflicts - prefix conflict (different SID's for
same prefix) and sid conflict (same SID for multiple prefixes) - if you don't
like the names, please send feedback.  in prefix conflict if scoped to VRF,
will only be scoped to VRF.  in SID conflict is across VRF's so is wider scope.
two approaches to resolve conflicts (slide 6)

    1st approach - either ignore all things in conflict (good as causes visible
    issue - all things impacted, operator becomes aware quickly) - downside to
    that approach is larger traffic impact.

    2nd approach - use preference rule of some sort to choose one over the
    other, some traffic may still be delivered, but may be harder to diagnose. 
    draft just presents - does not pick approach yet, but does give some ideas
    (slide 7) on what types of restrictions there are on preference based
    rules: don't use source (as ABR may be scoping visibility), same for route
    type.  last issue - prefix advertisements via SRMS - should configure both
    when making choice.

more thoughts on preference on slide 8 - no way to know for sure which is
correct, no guarantee all traffic can be delivered. Priorities for choosing
approach: detect, report, consistent behavior, don't over engineer a solution
to conflicts, very minor emphasis should be placed on resolution behavior than
the 4 top priorities. looking for feedback and to resolve longstanding issue -
asking for adoption as we really want WG to work this issue since IGP groups
could not reach consensus.

Q&A started at 09:43   Meetecho 0:42:50

Acee Lindem/Cisco: as OSPF WG chair, support this. Detecting is the hard part,
resolving afterwards is simpler. John: is that with your OSPF WG hat on? Acee:
yes. Although we could WGLC the OSPF draft without waiting for this, it would
be better to have it resolved before. Pushpasis: conflict resolution - I think
ignore option is better. Next comment - relaxing the check for SID conflict
when N flag set to 1. If we just relax we should be fine and still be detecting
misconfigurations even without implementing something complex. Les: I think
this is a different issue. Pushpasis: I am talking about mapping multiple
loopback addresses to a single SID - like on slide 5 this would create an issue
for this application. Les: this draft talks about the conflicts within the
legitimate advertisements, I don't think this issue is not worth discussing,
but not in context for this draft. Pushpasis: Won't be an issue if you would
treat this case as a non-conflict. John Scudder: I think Les is saying he does
not want to define what a conflict is. That is not a normative formalism. Les:
I think no. The advertisements are syntactically erroneous. Pushpasis: my point
is I'm trying to exclude this scenario from being defined as a conflict. Les:
we have other drafts that look into that, but I still think we need to talk
about that here too, wouldn't want to put in this draft. Wim Hendrickx: most of
these issues are showing up when you configure something. This can be avoided
by enforcing local checks. Trying to avoid these issues may be simpler. Try to
minimize the impact instead of adding in the complexity of trying to determine
what to use. We all try to minimize the impact in case of conflict, so as such
we (ALU) prefer to select one of the entry in conflict rather than to ignore
all of them. Important to have this draft to have deterministic behaviours
across different vendors. Les: I would agree, prevent problems from ever
occurring is optimal. Jeff Tansura: support adoption, service providers may
have different approach (prefer or ignore). This is an operational problem.
Bruno Decraene/Orange: Speaking as an independent contributor and a network
operator, this is important work but the draft should evaluate more the
consequences of these conflicts on the network traffic.  On slide 9, I think
should have another priority to evaluate the consequences on the customer
traffic after first three.  I am concerned with the mapping server
advertisements - single message containing multiple advertisements. Single
error there may affect multiple mappings and thus affect large number of
customer prefixes. Bruno: Second point - what you have written is right on
slide 8, but that is one part of the picture. On bullet 1, I do not know the
intent of the network operator that advertised me the prefix, but do we need to
know the intent to make a choice? On bullet 2, no matter which prefix is chosen
out of multiple, we cannot guarantee that the traffic will be operational. But
that's not a reason to try to reduce the consequences. (in general supports
resolution preference versus drop to lower impact to customers - thinks draft
is not balanced on this in his reading) My reading of the draft is that one
opinion is being pushed. There may be other ones too. Les: i think we agree on
a lot more than we disagree, so let's continue discussion. Bruno: it is
important to address these points, i think we should fix before adoption. Les:
could you address on the list specifically those two points on the list if they
are blocking adoption? Bruno: I'm not saying it's blocking, just should be
discussed. John Scudder: what I hear initial approach was - here is a bunch of
solutions, and we will place one on the table. Seems that we need to add other
approaches too. If you have comments, please send text. Shane Amante: network
operator - draft needs to move forward, but could what be considered a
misconfiguration actually in some networks be a merger/transition activity
configured deliberately? Les: there was a discussion in WG about problems
associated with mergers, SID conflicts, different protocols used, etc. We
agreed that we need to support that and protocol specific contexts and
redistribution need to be addressed for transition scenarios. But that is not
the subject of this draft. Shane: I understand if you are talking about
different IGP's in the networks, but if same IGP in both networks and there is
conflicts, I don't know if this draft is right place or another but should be
addressed. Les: merging two networks it does not mean that IS-IS is on one and
OSPF in another. It is about instances of the same in different domains. Shane:
OK, but let's see what WG thinks. John: flashback to IDR related issues - short
summary - spent many years trying to keep simple by just cycling session if we
couldn't understand, then operators beat us into changing (RFC7606: Revised
Error Handling). I would like to encourage the WG to consider that experience
before arbitrary deciding to do the thing that's easiest for the programmers.
Les: You survived those last 20 years somehow. :-)

o Advertising Per-Algorithm Label Blocks                 15 minutes - 10:01
        Meetecho 01:01:20
        http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF94_SPRING&chapter=chapter_1&t=3680
    http://tools.ietf.org/html?draft=draft-bowers-spring-adv-per-algorithm-label-blocks-02

    Chris Bowers

Chris presenting, made changes since Praque - added Uma (co-author) and added
multi-topology not just multiple algos. slide 1 - bit of review - this is
normal computation any implementation has to do to figure out label for SPF
routing to destination (add label block for neighbor + index advertised by dest
to get label for sending to that neighbor). slide 2 - two ways to implement
 option 1 - one big label block, assign different node index for every dest /
 algo / topology combination option 2 - one node index, different label block
 for topo/algo pairing
slide 3 - meant to be provocative to show the clean ordering of option 2 versus
option 1 (view in color or eyesore looking at numbers).  only showing 6 nodes
for simplicity but could be thousand nodes (imagining operator leaving some
space for an additional few nodes and topo/algo pair for network
growth/change).  option 1 deliberately shown very poor but illustrates any
organization has to be imposed externally (by operator through CLI - possibly
proposed by Les on list).  so next slide shows option 1 can be similar to
option 2 once configured like it with operator per node configured offsets (per
algo/topo). case for option 2 vs option 1 - SR doesn't need targeted LDP (to
exchange labels between remote nodes) good but needs assignment of node index
which is bad.  generalizing SR to other topos/algos makes it more bad since
there is even more configuration complexity.  option 2 makes it less conf
complexity as less for operator to configure since don't need to do algo/topo
offsets. when I first saw SR algo support - i thought elegant use case for MRT
label distribution - but less attractive if you have to configure offset. next
slide shows sub-TLV req'd to support exchanging this information (in IS-IS). 
non-zero values only - zero values (default algo/topo only in current SR TLV)

Q&A started at 10:16   Meetecho 01:16:20

Ahmed Bashandy/Cisco: In slide 'Label computation', option 2, I would suggest
having something like "offset,t". Regarding the configuration, you still need
to maintain SRGB per algo/topo configs instead of offsets there, isn't it about
the same? Chris: per algorithm per topology label blocks are locally
significant, whereas offsets need to be non-conflicting. Option 2 does not
require that label blocks are unique per router. Ahmed: but it can be
fragmented too. Chris: Yes. I have it as example as single continuous block,
but it can be fragmented. Ahmed: In option 1 it needs to be the same block and
offset per topology, that is the only complexity that I can see. Chris: if you
look in the draft there are more complicated scenarios I didn't discuss.  so
far we have assumed that we can allocate a single large block on each
implementation to cover the network needs (may not be true). Ahmed: Let's go by
example of option 2. I can allocate 10 SRGBs for 10 topologies, but use offset.
Chris: That seems to be even more complicated. You are saying you would
advertise multiple ranges? Ahmed: This seems to be a local verification
mechanisms on the CLI level, do I really need to add functionality to the
protocol? Modifying the protocol to advertise that informations seems to add
complexity? Chris: there is no way to stop operator making mistake by
configuring wrong offsets on different boxes in network. Ahmed: do we need to
modify all protocols to prevent operator mistake? Chris: I think if we had put
this in originally no one would be arguing about it, but we are now at a stage
to think about supporting multi-algo/topos long term. Les Ginsberg: I have a
more fundamental issue. It seems what you are proposing here invalidates the
current way of advertising SIDs. Your proposal is that you have the same prefix
and SID per protocol per topology, and that is not backwards compatible with
the current way of advertising prefixes and SIDs. Chris: I am happy to add text
that clarifies how this works, but in deployments everything currently has a=0,
t=0. John: we are mostly out of time. Les: Prefix reachability advertisement
includes one topology and one algorithm id. Chris: set to zero - I will propose
some more text on backward compatibility. John: please resolve this offline.
John: take to list or hallway time Ahmed: it seems like folks keep posing
issues with draft and you fix the nit, but seems overkill for just operator
mis-config

o Interconnecting Millions Of Endpoints With Segment Routing

    http://tools.ietf.org/html?draft=draft-filsfils-spring-large-scale-interconnect

    Dennis Cai                                           10-15 minutes

Not covered due to time, may be scheduled as a virtual interim meeting per John
S.

o Tunnel Segment in Segment Routing

    http://tools.ietf.org/html?draft=draft-li-spring-tunnel-segment-00

    Robin Li                                                10 minutes

Not covered due to time, may be scheduled as a virtual interim meeting per John
S.

Meeting concluded 10:27.