Minutes IETF103: spring
minutes-103-spring-00

SPRING WG       Source Packet Routing in Networking

9:00 - 11:00    Wednesday Morning session I
                Room: Chitlada 2

Chairs:
                Bruno Decraene <bruno.decraene@orange.com>
                Rob Shakir <robjs@google.com>

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

o Administrivia
Chairs
    - Note well
    - Scribe
    - Blue Sheets
    - Document Status                       10 mins       9:00

[Zafar Ali] The charter does not specify that we cannot progress SRv6 docs.
There will be a backlog if we block on this. [Bruno Decraene] Protocol
extenstions must be worked on in routing protocol groups [Zafar] SPRING should
not make this blocking work. [Bruno Decraene] Progression expected in 1-2
months [Martin] This doesn't mean that you can't work on your doc. This is just
for adoption. [Bruno] We can assume that this will be adopted -- so there will
be meeting slots, and support for advancing - but it won't be advanced until
such time as we have SRH progressed in 6man. [Zafar] There will be private
discussion on this work -- this will cause stability issues for adopters and
implementers. [Rob] Private discussion is only driven by authors - please
discuss on the list. [Martin] We do not drive the pace of SRv6 work in 6man.

----------------------
o UDP Path for In-Band Performance Measurement for Segment Routed Networks
    - draft-gandhi-spring-udp-pm-02
    - Rakesh Gandhi                         8 mins        9:10   [9:18]

 Draft was also presented at IPPM.
 Authors requested working group adoption.

[Greg Mirsky] Using well known UDP ports creates a new vector in an attack and
draft doesn't include security considerations. Working group document (STAMP)
in IPPM regarding properties in the draft so why to reinvent the wheel. [Rakesh
Gandhi] [Greg] Why not use TWAMP-light? There's existing implementations. 6374
works fine for SR-MPLS but not SRv6. [Rakesh] SR has both SR MPLS and v6 so
you're not gonna ramp TWAMP on some nodes. 6374 has been around but STAMP (?)
is new and not deployed yet [Greg] STAMP is backward compatible [Stewart
Bryant] 7876 in early version had defined ports and there was a pushback -
policy is to avoid well known port allocation. Use dynamic ports [Rakesh] We
would otherwise need to add negotiation per-LSP ping. [Stewart] You should have
an initial discussion with the port allocation folks to understand whether this
is a possibility, otherwise there'll be re-engineering required as happened
with 7876. [Sam Aldrin] Are you making sure Anycast is covered? [Rakesh] Needs
discussion [Sam] What are you doing at the egress node? How is it punted at the
egress? [Rakesh] UDP header is exposed. It is in the payload not in the stack.
Label header only till the egress [Greg] Return path TLV already in BFD draft.
Consider reusing. [Rakesh] We can make the specification similar -- IANA
allocation will still be required. [Greg] In SRv6 if you don't have integrity
protection/security then this will be a challenge. [Rakesh] We can add that.
[Bruno] follow up in the list

----------------------
o Performance Measurement in Segment Routing Networks with MPLS Data Plane
    - draft-gandhi-spring-sr-mpls-pm-03
    - Rakesh Gandhi                         7 mins        9:18       [9:30]

[Stewart Bryant] Colored packet marking? This worked in MPLS-TP since there was
no ECMP - and needs some extension in MPLS for this. [Rakesh] Yes, this relies
on the coloured marking. It does rely on the extensions in MPLS. [Stewart] Do
we need twice as many Node-SIDs? (e.g. synonymous flow) [Rakesh] It only needs
to be unique on the egress (local SID works) [Stewart] It needs to be unique
for each possible source. [Greg Mirsky] Other methods than inband probes?
[Rakesh] Can be done out of band. [Greg] This method is stated to be in-band,
but is there actually an alternative to having in-band for effective OAM?
[Rakesh] End to end delay measurement the same as the actual traffic. [Greg]
This doesn't need a draft as it is required [Robin] Should it be carried in
SPRING on MPLS WG? [Rob Shakir] Needs discussion

----------------------
o Resilient MPLS Rings
    - draft-kompella-spring-rmr-00          10 mins       9:25        [9:40]
    - Kireeti Kompella

No comments

----------------------
o Segment Routing for Enhanced VPN Service
    - draft-dong-spring-sr-for-enhanced-vpn-02
    - Jie Dong                              10 mins       9:35 .      [9:47]


[Bruno] There is a related document in TEAS (draft-dong-teas-enhanced-vpn).
[Stephane Litkowski] How do you partition resources by allocating new SIDs?
[Jie Dong] Multiple technologies in the forwarding plane
[Stephane] So it is separate logical link (for example VLAN)
[Jie] Can be logical link or can be hidden from routing protocol
[Stephane] similar than LAG members
[Jie] yes, similar to that
[Ketan] There is a virtual network defined here. How are these networks
constructed and resources grouped? [Jie] Clarification -- you mean, how do you
know that SIDs are grouped to form a network? [Ketan] Flex Algo has different
algorithms for prefixes. How do you achieve that? [Jie] One approach is to use
multi-topology to associate link+node SIDs (using MT-ID). [Ketan] Would be
useful to clarify if this is related only to MT. Scalability analysis of how
many partitions would be useful. [Lou Berger] What the underlying resource that
an instruction maps to is dependent upon modelling. It can be queues in the
hardware, or separate links etc. There will be scaling considerations required.
MT-ID is only one option for different topologies - controller can know this
without IGP extensions. TEAS draft should not discuss these trade-offs, but
rather SPRING draft should link the use cases, such that then TEAS is able to
map to the implementation. [Stephane] If you want to partition using queues you
can use DSCP bits today [Lou] This has scaling limitations since the namespace
is limited. [Bruno] Could you consider what the partitioning approach is, and
analyse the scalability of your approach. [Jie] We can cover this following the
meeting and post to the list. [Jeff Tantsura] You need to figure out how to
interact between the number of services and number of loopbacks (one next-hop
per service).

----------------------
o Path Segment in MPLS-Based Segment Routing Network
    - draft-cheng-spring-mpls-path-segment-03
    - Mach Chen                             10 mins       9:45        [10:03]

    Authors requested working group adoption.

[Greg Mirsky] I see that you have parallel work on SRv6. You could consider
having a single document covering path segment for both SR-MPLS and SRv6, since
the issues are likely to be the same. Not sure that removing 2 ID labels brings
advantages. Some segments may require more SIDs.. [Mach Chen] Ack [Sam Aldrin]
This adds a lot of complexity. Why do we need to do this? Adding more labels is
not the right solution. [Mach] The use case is for performance measurement of
real traffic -- where you need to identify the path at the egress. [Sam] Who is
encoding the label stack? [Mach] The ingress imposes, but the egress allocates
it. You need a controller to allocate the labels here. If you want to solve
this then you need additional labels. [Sam] What if you need performance data
on the intermediate nodes? [Mach] It is for egress only. There are other
solutions for the transit stats (not this draft) [Ketan Talaulikar] We should
review the use cases in more depth to figure out where this is applicable, or
required. Not required for delay measurement. You said that the Path Segment
needs to be allocated from the SRGB or SRLB, but it is not clear why this is
required? [Mach] You can get label from SRGB or SRLB [Ketan] Why not local
label (outside SRGB or SRLB)? [Mach] We can just use a dynamic label at the
egress. [Jeff Tantsura] Concerns about ability to support it across many
platforms. [Mach] Since this is just at the egress, then the existing label
stack has been popped already. [Jeff] Ericsson owns an IPR on this. [Ron
Bonica] Given in SRv6 you don't POP labels, why do you do this? [Mach] Agree
that this is not necessarily needed in SRv6, since we can use SRH to understand
this. It's not hardware-friendly to use the SRH. The Path Segment would be an
identifier. [Ron] The destination node can use this to reconstruct the label
stack. Can't every node generate the whole label stack from the Path Segment --
didn't you just re-invent the RSVP-TE/LDP label?

----------------------
o TTL Procedures for SR-TE Paths
    - draft-arora-mpls-spring-ttl-procedures-srte-paths-00
    - Shraddha Hegde                        10 mins       9:55      [10:19]

[Greg Mirsky] We have LSP ping for SR (8287). Section 5 explicitly discussed
TTL handling for traceroute. Why do you think it's needed to have another
document? Would it be good to update 8287? [Shraddha Hegde] RFC8287 is not very
clear on PHP. Updating 8287 is logistics. [Lou Berger] Question as to whether
this is SR-TE vs. just SR. [Shraddha] This is an issue where you have stacked
labels. [Lou] There isn't a definition of SR-TE, which causes confusion.
[Bruno] SR-TE is a stack of labels. [Lou] If this had said a stack of labels
then there would be less confusion. [Shraddha] Definition for SRTE is not the
objective of this draft. [Lou] So remove it [Bruno] We can say SR-policy
instead. [] Question about the rule of not copying TTL from outer to inner
label if outer TTL is greater (loop prevention). Is there any document
specifying this? [Shraddha] It is a common/best practice. Not found in any RFC
or draft. Even if you copy, traceroute would not work. [Sam Aldrin] The problem
is real. When you send an Echo Request then the DDMAP is not necessarily there.
Instead of DDMAP you might be better to encode into a new return code.
[Shraddha] Thought about introducing new return code but concerned about
backward compatibility issues

----------------------
o EPE OAM
    - draft-hegde-mpls-spring-epe-oam-00
    - Shraddha Hegde                        7 mins        10:05

    Authors requested adoption

[Zafar Ali] in peer mode sid. peer could be in different ASes. There is a
problem with the encoding [Shraddha Hegde] You can group links and repeat. Not
optimized [Zafar] May be cases where the local the interface might not be known
to the sender. Ping may end in a different AS -- there might not be a reverse
path.

----------------------
o LSP Ping/Traceroute for Segment Routing SIDs with MPLS Data Plane
    - draft-nainar-mpls-spring-lsp-ping-sids-00
    - Zafar Ali                             7 mins        10:12    [10:46]

Will work with Shradda to see if we can collaborate or merge, as this is some
overlap.

----------------------
o NSH and Segment Routing Integration for SFC
    - draft-guichard-spring-nsh-sr-00
    - Jim Guichard                          5 mins        10:19    [10:49]

    Authors requested WG adoption - but are OK to discuss in Prague.

[Bruno] existing encaps for NSH in IPv6? Do you expect it to be different than
SRv6? [Jim] No, no [Bruno] NSH encaps in IPv6/SRv6 better discussed in 6MAN
[Jim] good point

----------------------
o BFD for Segment Routing Policies for TE
    - draft-ali-spring-bfd-sr-policy-02
    - Zafar Ali                             5 mins        10:24    [10:52]

[Zafar] Skipped based on chairs discussion on merging with draft-mirsky.

----------------------
o OAM in Segment Routing Networks with IPv6 Data Plane
    - draft-ali-spring-srv6-oam-02
    - Zafar Ali                             5 mins        10:29

    Requested adoption in SPRING.

[Bruno] You can't self allocate code-points.
[Zafar] We will need to respin the draft to replace with TBD.
[Martin]  You need to respin this draft rapidly because otherwise folks reading
it will think that these code points are allocated. Please do this. [Zafar]
We'll do this. [Greg Mirsky] Nice that you demonstrate that existing tools
work. There is no need to use an O-bit [Zafar Ali] [Greg] If node has TTL
expired you look into payload. If it has no TTL expiration, you don't look into
O-bit (???) Suggest to remove O-bit from this document [Zafar] There are
multiple use cases for O-bit.
...
[Zafar] There is no need for the node processing TTL expiry to understand the
SRH, there is detail in the document. The node generating the error will
process and send back the packet. [Greg] Based on this, why do we need the
O-bit? [Zafar] The O-bit means that we can do per-segment ping and traceroute.
[Greg] OAM functionality is being defined in two places - both in the flag, and
the UDP port. This causes confusion. Suggest that [the authors] read the
document on iOAM that was published before Montréal. This removes the
ambiguity. [Bruno] Please take this to the list. Greg, please start a mail on
the list. [Greg] Glad that the O-bit has been removed. [Zafar] It hasn't been
removed, just moved into the other draft.

--

o Segment Routing Header Encapsulation for In-Situ OAM Data
    - draft-ali-spring-ioam-srv6-00
    - Zafar Ali                             10 mins       10:34

Skipped, out of time.

o OAM for Service Programming with Segment Routing
    - draft-ali-spring-sr-service-programming-oam-00
    - Zafar Ali                             10 mins       10:44

Skipped, out of time.


        Speaker Shuffling Time                      6 mins
Total                                       120 mins