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

Minutes SPRING:

o WG Status
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_SPRING&chapter=chapter_1&t=300

o SR drafts update: Stefano
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_SPRING&chapter=chapter_1&t=650
Q&A: None

o Segment Routing Conflict Resolution:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_SPRING&chapter=chapter_1&t=915
draft-ietf-spring-conflict-resolution-01
  Les Ginsberg

Les:
Next thing: spin a new version of the draft.
Asking for feedback from vendors on implementation complexity and from network
operator on network impact.

Q&A:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_SPRING&chapter=chapter_1&t=2130

Robert: if we want to override SRMS with SDN controller, what happens in this
case?
Les: it matters how you utilise SRMS. If you try to minimise the impact
of misconfiguration, preferring the SMS entries allow simpler
implementation. SRMS was not envisioned as a provisioning tool, but this has
evolved. Operators should have a view on this, input would be appreciated
Robert: SRMS would provide updates on purpose, goal is to control the network
Stefano: SRMS have been extended in ISIS/OSPF, so the q is if we define
something else than routing protocol for SRMS. the conflict is what we try to
get to in this draft Bruno (as individual contributor): network availability
impact has been improved, so thx for that, the slides are different from the
draft though Les: a lot of the changes are not reflected in the draft yet, but
we intend to update it based on input we get and potential consensus. Bruno: I
would like a new version of the draft Les: prefers to wait till we get more
input and potentially reach consensus. Bruno: We need to make it clear in this
case we need input on the presentation + slides Bruno: slide 19, with the new
policy the mapping server is preferred. As a consequence, for operator using
LDP interoperability, there would be little point in configuring SID on each
router, since they would always be quarantine. That's a change that could be
indicated. In quarantine, the prefix SID is ignored. How to handle MPLS PHP
since since the flags are in the prefix SID (and not in the SRMS). Les: if we
still need prefix SID for PHP flag we could still use it for PHP flags Bruno:
this should be clarified in the draft Shraddha: OSPF draft says prefix is
preferred which conflicts to the proposal of slide 19 Les: goal is to get
agreement on the proposal and we will reflect this in the relevant drafts Rob:
If SRMS wins, Prefix SID are not used/verified. Switching off SRMS (at some
point) becomes risky as may reveal old mis-configurations. But I don't want to
keep using SRMS for ever. Les: this is the info what we need Wim: as Nokia we
prefer the ignore overlap over quarantine approach given it maximise forwarding
in case of conflict. Bruno (as individual contributor): Slide 19. We also need
to see how we use weight in the proposed new revised preference rule. If weight
is after "larger range wins", the weight is not very strong as only applicable
if both ranges are the same. If weight is before "larger range wins", the large
range may be quarantine, with a significant impact on the network availability.
Les: if we incorporate weight, the left scenario of slide 19 was easy: we
assign weight 0 on prefix. If we take the new proposal on slide 19 it needs to
be discussed Bruno: This will influence the operator decision, depending on
what we do with weight. Les: based on input, if the decision is quarantine we
can discuss what we do with weight

o Packet-Optical Integration in Segment Routing:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_SPRING&chapter=chapter_1&t=3300
draft-anand-spring-poi-sr-01
  Sanjoy Bardhan
Q&A:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_SPRING&chapter=chapter_1&t=3600

Bruno: clarification. what is the difference between a POG and a regular LSR?
Sanjay: a POG is a device that terminate packet and maps to the optical
network. O1, O2 are not visible in the packet network normally. In SR we
now have visibility when we do this.
Bruno: Which nodes are in the packet's domain IGP?
Sanjay: A, B, E, E are in the packets IGP. D and C are not.
Bruno: existing LSR does this as well
Rob: what is the difference compared to forwarding adjacencies?
Jeff: it is an abstracted way of advertising the optical GMPLS paths in
the packet domain
Rob: this looks the same way as the RSVP forwarding adjacencies
Jeff: think of multi-layer PCE
Rob: i believe it is comparable, why is there a difference for this and
what we have e.g. in RSVP FA
Sanjay: Yes, it is comparable. But the paths have different characteristics
which should be taken into account for a E2E PCE calculation Rob: it is still
the same as RSVP forwarding adjacencies. So why do we need something new in the
protocol to handle this differently? Jeff: There is additional meta data we'd
like to distribute.

o OAM Requirements for Transport Segments:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_SPRING&chapter=chapter_1&t=4020
draft-bardhan-spring-poi-sr-oam-00
  Sanjoy Bardhan

http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_SPRING&chapter=chapter_1&t=4480

Q&A:
Carlos: 2 comments that can be responded on the mailing list:
Why would we have a set of req, for this specific part of Segment routing that
doesn’t apply generally. You list requirement with solutions. This looks odd,
or even more reverse engineering of requirements.

o A Framework for Computed Multicast applied to MPLS based Segment
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_SPRING&chapter=chapter_1&t=4560
Routing: draft-allan-spring-mpls-multicast-framework-01
  David Allan

Also presented in PIM WG. We'll also present in OSPF and IS-IS.

http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_SPRING&chapter=chapter_1&t=5155
Q&A:
Robert: how do you plan to glue this into PIM. Whats the plan?
John: If the answer is long, please take it to the list.
David: answer will be taken to the list
David: how many people read this. rather small audience that should go up

o A scalable and topology aware MPLS data plane monitoring system
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_SPRING&chapter=chapter_1&t=5220
  draft-leipnitz-spring-pms-implementation-report-00
  Raik Leipnitz
Q&A:

Bruno: Implementations reports are usually published in the wiki. I've added a
link. Ruediger: clarification, the current implementation is using LDP, but the
label stack is using the SR concept. We would welcome review on the oam-use
case draft, during WGLC. Ahmed: Nice work. suggest couple of extensions. Try to
do the tests for layer 2 Link Aggregation group, we have a draft on this. On
top we should also try to do the same with Ipv6 forwarding plane. Ruediger:
We'de like but our testbed is MPLS LDP based.

o In-band OAM for SPRING
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_SPRING&chapter=chapter_1&t=6230

  draft-brockners-inband-oam-requirements-00
  draft-brockners-inband-oam-data-00
  draft-brockners-inband-oam-transport-00
  draft-brockners-proof-of-transit-00.txt
  Shwetha Bhandari

Already presented in SFC WG.

Q&A:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_SPRING&chapter=chapter_1&t=6780
Ruediger: is this for BackBone network or mainly for Data Center
Shwetha: We have a software implementation. It's mostly in NFV land with
service chaining + also applies to network overlays. Ruediger: don’t know that
the draft is making this explicit. Would be good to clarify the use cases,
applicability. Shwetha: invite you to help polish John: do we need to provision
a distinct secret per service path? Shwetha: yes this is the idea John: maybe
it does not apply well to any path, flow, this will not scale.