IETF90 - Spring
Wednesday, July 23, 2014
1:01 PM
Administrivia
Chairs 10 minutes
- Note Well
- Scribe
- Blue Sheets
- Document Status
1:02 pm Meeting Started -
start chairs, Note Well, etc..
1:04 pm - meeting paused, no audio to remote participants
1:05 pm - (Re-)Start.
o Segment Routing Architecture
http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-04
http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-mpls-02
Stefano Previdi 5 minutes
http://tools.ietf.org/html/draft-ietf-spring-problem-statement-01
Stefano Previdi
1:05 pm - Start:
Problem statement draft - thinks ready for next stage
Arch draft - simplified terminology, more readable, moved ipv6 and mpls dataplane sections out to those drafts
MPLS draft - added interop sections
LDP interop draft - added sections on interop
Use cases draft - may be renamed, not top priority to sort out
1:09 pm - Q&A:
John Scudder - I think next step is to last call (probably means adopt) the documents
Stefano - I think arch doc is stable enough for adoption, some phrasing updates
John Scudder - if it's coming soon we should start poll after, otherwise let's just do it
Alvaro - any significant concerns on problem statement?
No comments from room.
Alvaro - great
o IPv6 Segment Routing Activities during Bits-n-Bytes
John Brzozowski 10 minutes
1:12 pm:
John B - we encourage to come and take a look at Bits and Bytes on Thursday night to show multiple independent implementations, not only within an AS but across Internet, work based on SRH draft on first slide
Want to show nothing adverse happens when non-SR capable infra in mix
Stretch goal to show fetching segment ID's using NC/Yang
Participants slide - brought a cable network here to bits and bytes, stretch goal to show controller type activity
1:18 pm - Autonomous SR slide show two networks over big-I Internet:
SR-SR
Introduce cable network - purple on these slides show SR capable path
Last picture slide shows a completely unique path for SR for this traffic flow
1:19 pm - Q&A:
Alvaro - Thursday night?
Yes, in concert hall at bits and bytes.
o Spring Use Case Updates
http://tools.ietf.org/html/draft-ietf-spring-ipv6-use-cases-01
Roberta Maglione
Total 15 minutes
1:21 pm - Roberta presenting:
MPLS may not be present everywhere (home network)
These use cases on slide, on ML there was also some use case around a dual stack network wanting to go only IPv6 but gaps for MPLS on IPv6 only network in graph.
1:23 pm - Use cases slide:
-01 differences as described in ipv6-only draft, added Wes George's comments and reference
1:25 pm Q&A:
Jen Linkova (Google) - in dual stack networks you said IPv6 MPLS is not possible, I disagree
Roberta - we may (inaudible)
Jen Linkova - I already run IPv6 on my LSPs today
Wes George: yes (answering Jen), but that is not same as IPv6 only MPLS network.
Hannes Gredler (Juniper) - put back slide for use cases, I have question on Core network case, do you assume HW support for that?
Stefano Previdi (Cisco) - yes
Hannes - good luck
Robin (Huawei) - in SR in DC, do you use IPv6 in the DC network?
Roberta - yes, to use IPv6 SR paradigm to send traffic to diff services. Remember that only the destination address has to understand the header.
Robin - is it popular to use IPv6 in DC? My analysis is it mostly use L2 for solution.
Ron Bonica (Juniper) - the question on Spring in Core, are you considering FRR support?
Roberta: yes
Ron - have you thought of HW implications of that?
Stefano - yes
Luyuan - comment on DC L2 question, many DC's are L3
Robin - inaudible - something about overlay
Alvaro - according to our milestones we should move fwd soon, please have discussions on ML so we can think about moving forward
http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-00j
Bruno Decraene
1:31 pm:
Change to make solution agnostic in last rev, added bypass protection approach.
Two options (slide 2) - bypass, merge back to original path ASAP or shortest path, detour then shortest path to destination
Next slide - sometimes does not fit SP requirement, for instance SLRG, or you may not want to protect P-P link with through PE path, these reqs can be managed via explicit path or high-level constraints
4 total options (section 3/4 in draft)
1:35 pm - Q&A:
Alvaro - who read:
Many hands raised.
Alvaro - good, we want to keep up with our milestones, please comment on ML
o OAM Use Case
http://tools.ietf.org/html/draft-geib-spring-oam-usecase-01
Carlos Pignataro 10 minutes
1:35 pm - Nagendra Kumar from Cisco presenting not Carlos:
Can monitor from single PMS - don't need much control plane interaction
Slide 2- Good discussion on ML, we got comment that it looks like solution doc, going to fix to make more like use case doc
Should we make it more generic to cover both dataplanes, not just MPLS?
Greg Mirsky (Ericsson) - on diagram slide - how critical is use of PMS in this solution? Why not use model described in LMAP working group.
Nagendra - It's possible, if there is another server, we could re-use it instead of PMS centralized server.
Greg - you may have positive negative links between PMS and link you really want to observe.
Ed Crabbe (Google) - disagree, if you have multiple probe systems, and you have unique path set of total path set on given link, you are able to uniquely identify failed link
Alvaro - comments?
o Service Function Chaining Use Case for SPRING
http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02
Xiaohu Xu 20 minutes
1:41 pm:
Assume you are familiar with SFC - here are terms on slide 1. NF/SFF are mandatory terms, there are not used in current draft
Motivation of draft - traffic needs to be steered to SN. Seems obvious Spring can be utilized to do this steering. SFC could be represented by ordered list of labels or IPv6 headers, only covering MPLS to simplify discussion.
Slide (encoding the SFP) - SN should use locally allocated label, could use global label but doesn't need to do that.
If SN are separated by IP networks, IP tunnels (MPLS over GRE) can be used between SNs.
Some people in SFC WG prefer to encode SFC instead of SFP in labelled packet.
1:48 pm- Encoding SFC (slide):
To encode this, global label should be used for a given SF. SN must be able to resolve next SN in SF.
MPLS technology can be deployed in IP, MPLS or Ethernet as MPLS VPN technology is transport independent.
To allocate global label for SF, for people who understand global label in SR, this is easy to understand.
1:52 pm - Q&A:
Cienna - what is maximum number of labels you need to support this?
Xiahou - it depends
If you use MPLS label for solution, what about metadata.
Xiahou - if metadata is carried on MPLS packet only, this is out of scope of this draft, many ways to transport this
Jeff Tantsura (Ericsson): If SF label block context based, why does it have to be unique?
Xiahou - no difference to SR usage?
John Scudder: I have a question - this is no different from global label in arch right, we are trying to focus on use cases that drive development of technology, does this use case provide any new requirements. As member of WG, if this doesn't drive any new reqs, not sure if needed as WG doc.
Xiahou - I feel it's a very valid use case for Spring
John: not saying it's not valid, just use cases that give us a set representative of the technology requirements
o Segment Routing in IP RAN use case
http://tools.ietf.org/html/draft-kh-spring-ip-ran-use-case-01
Bhumip Khasnabish 15 minutes
1:57 pm:
Here is general IP RAN diagram.
Next slide IP RAN requirements
SR can simplify E2E LSP establishment, FRR, policy.
Next slide example of how it could be used (diagram).
Controller support needs.
Soliciting comments from SP who are thinking about SR for IP RAN, still gathering requirements.
2:00 pm - Q&A:
Greg Mirsky - you mention transport, in RAN, transport is bidirectional, how do you deal with SR not having bidir constructs
Bhumip - need to explore that, there are different paradigrms, please send email to distro for discussion
Greg - does your use case mean SR needs to support bidir constructs
Bhumip - yes
Ahmed Bashandy (Cisco) - read draft, think requirements are satisfied in existing drafts.
Robin (Huawei) - I think re: SR in IP RAN, I think IP RAN is diff from Core network, more nodes in ring topology, I proposed same requirements in Seamless MPLS draft. I think depth of MPLS label may be challenge for HW. 2nd - fast reroute - in ring topology may need more segments for backup path, same challenge for HW.
Stewart Bryant - in order for not infinite # of use cases. Think chairs should specify above and beyond base doc whether there are new reqs, otherwise don't need to publish doc.
Alvaro - we need to see clear difference in doc before considering.
o Segment Routing Centralized Egress Peer Engineering
http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-central-epe-02
Stefano Previdi 10 minutes
2:04 pm -
If you read draft (slide 2), central-epe redefines problem statement diagram to focus on the connectivity between the AS or between AS and outside world (AS, peers, interfaces), we want to describe/model this.
Draft assumes centralized controller.
Ref diagram slide - we want to diverge from normal bestpath exit point based on resources on exit point. Want to influence load balancing strategy from Router C to these interfaces in diagram.
Next slide shows this - want to interfere with existing BGP scheme, want to be able to override for exceptions. Needs to know topology, resources available at egress point so controller can tell ingress not just how to exit but what egress interface for instance.
Obviously you don’t' want to keep state across path, just state where needed, where decision is taken at ingress.
eBGP peering topo slide - need to send appropriate information (ints / ints to same peer, AS, etc..) to controller. Each of these resources can have a label assigned. Router C (exit point) will install these labels in FIB and the instruction.
BGP EPE slide - we have submitted in IDR a draft to send info to controller via BGP-LS as this is made for advertising topo info in BGP. We didn't invent a new TLV, just invented new context to say this is not IGP topo, this is EPE topo.
Controller Decision slide (2:12) - controller has all visibility necessary, should have performance info and business policy, etc.. But those aspects out of scope, we don't mandate the way to do these things in draft.
Next slide shows controller using PCEP (example, not mandated) to program path info at ingress, could use BGP-3107 or other methods, none mandated.
Conclusion - EPE does not interfere with iBGP deployment, any scheme is fine. Stateless in network, just about controller make right decision, translate to label, instruct ingress.
2:15 Q&A -
Hannes - suggestion, for arch draft, maybe beneficial to document why BGP-3107 for managing load across inter-as links is not sufficient.
Stefano - yes, can consider adding to document.
Robin (Huawei)- just need clarification on slide - automation of segment ID allocation.
Stefano - go back to Automated BGP Peering SID allocation (slide) - all labels here are locally significant to C (egress peering router depicted on slide).
George Swallow - two comments, to Hannes comment, some SPs for whatever reason set NHS, you could do a lot more if you exposed neighbor NH, w/o need something more. 2nd comment - you say doesn't impact iBGP, this you could introduce into SP that runs any combination of LDP/RSVP-TE and get all the benefit.
Stefano - absolutely
o BFD Directed Return Path
http://tools.ietf.org/html/draft-mirsky-mpls-bfd-directed-00
Greg Mirsky 10 minutes
2:18 pm:
When monitoring uni-tunnel with bidir OAM, ingress cannot reliably detect failure of path, returned path may be disjoint. Hence we get false positives. This topo diagram shows S reaching R, return path is different by IGP shortest path.
Proposed solution slide - suggest use extension TLV to BFD, sub-TLV would specify return path to be utilized for BFD return path. This introduces two return path SR TLV's. Following slide shows formats of sub-TLV.
If dataplane is IPv6, then diff sub-TLV. RFC 7110 describes how you can use these new sub-TLVs.
2:23 Q&A - none
o MPLS Path Programming
http://tools.ietf.org/html/draft-li-spring-mpls-path-programming-00
Zhenbin Li (Robin) 10 minutes
2:23 pm -
Slide 3 - shows we already have flexible label (different protocols) stack in MPLS, here are two examples of normal use cases, one is 5 labels. History shows limited programmability, label was for reachability, 2nd issue is limited path calc capability in distributed environment.
Rob Shakir - in diagram, BGP prefix label is really context label, depends on label allocation scheme, could be identifier of table.
Stewart Bryant - not sure why source label is listed as if it exists which is point of contention
Robin - draft exists, not standard
Any path can be programmed once central controller exists. Propose two things - easier to allocate label for more purpose than reachability, easy to calculate MPLS path in global view.
Here we propose use cases for Service Oriented path programming.
Here is a diagram showing various labels in unicast MPLS path programming.
Multicast use case - use source label for example.
In end, ingress PE will be very important for Service Oriented path programming, so BGP is important tool to program such path.
2:43 pm - requirements slide
2:44 Q&A -
Luyuan Fang (Microsoft) - on slide 13, disagree that segment routing is typical solution, 2nd comment - so many labels, on slide 11, we want to minimize # of labels. Also we want to minimize protocol extensions, otherwise network becomes more complicated.
Robin - In my opinion, depth of label stack is not problem of this draft. Label stack depends on your requirement.
Rob Shakir - section 3.2 gap analysis for segment routing - doesn't seem to identify many gaps. What do you want Spring WG to do? I don't see anything for Spring WG in draft.
Robin - from my point of view, the service requirements exist.
Rob - as a SP, the document does not have any service requirements, if we standardize this, I'm not sure what new thing I get.
John - I agree with what Rob said, if anything is actionable it's on the Requirements slide, but it doesn't say Spring, it seems like for BGP. I'm not sure what right WG for controller to client protocol but this is not the group.
Robin: maybe this WG should take the task
Alvaro: not time for talking about re-charting, let's move to open MIC for 9 minutes
OPEN MIC
2:51 pm:
Bhumpin - want to know if WG is interested in OpenFlow/Spring interworking. Raise of hands for heard of OpenFlow.
(lot's of hands raised)
How many for interworking with Spring.
(three hands)
I encourage you to look at draft once published and send comments.
2:53 pm - meeting adjourned.