* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Spring Status Pages

Source Packet Routing in Networking (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2013-Oct-25 —  

IETF-103 spring minutes

Session 2018-11-07 0900-1100: Chitlada 2 - Audio stream - spring chatroom


minutes-103-spring-00 minute

          SPRING WG       Source Packet Routing in Networking
          9:00 - 11:00    Wednesday Morning session I
                          Room: Chitlada 2
                          Bruno Decraene
                          Rob Shakir
          o Administrivia
              - 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
              - 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
          [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
          [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
              - draft-gandhi-spring-sr-mpls-pm-03
              - Rakesh Gandhi                         7 mins        9:18
          [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
              - 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 .
          [Bruno] There is a related document in TEAS
          [Stephane Litkowski] How do you partition resources by allocating new
          [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
          [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
              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
          [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
          [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
          [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
          [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
          [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
          [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
          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
              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
          [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
          [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
          [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

Generated from PyHt script /wg/spring/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -