IETF91 - Spring
9:02 am - starting meeting - John Scudder speaking
o Administrivia
Chairs 10 minutes
- Note Well
- Scribe
- Blue Sheets
- Milestones Review
Waiting on IPR for architecture document
o Remote Hub Experiment
Alvaro 5 minutes
9:05 am - Alvaro speaking
Experiment of remote participants via video today in Spring (3 remote conference rooms in various LATAM locations on screen, 7 total).
IAOC approved IETF 95 in Buenos Aires at plenary, only 2nd time we are meeting South of Equator. First time in Latin America
IETF-LAC formed to increase participation
Goal: to have consistent participation from Latin America through and beyond IETF95
A regional mailing list has been formed to discuss IETF ideas in local language.
Try to form localized hubs of IETF interest in various areas of LATAM.
Choose to do this experiment due to newness of Spring, Alvaro's role as chair and research focus of some of the LATAM interested parties.
o IPv6 Segment Routing Update - 9:15 am starting
https://tools.ietf.org/html/draft-previdi-6man-segment-routing-header
https://tools.ietf.org/html/draft-vyncke-6man-segment-routing-security
Stefano Previdi 15 minutes
Stefano: slide - 2 terminology - SR-MPLS - dataplance MPLS. SR-MPLS-IPV4/V6 - using v4 or v6 for control plane. However this draft is SR-IPv6, IPv6 control plane with IPv6 dataplane.
9:17 am - slide 3 - SR architecture is dataplane agnostic
9:18 am - slide 4 - new use case added to update ipv6 use cases, then two 6man docs, one on header, other on security
9:19 am - slide 6 - new EH, diff from MPLS dataplane that node address = SID so don't need to map prefix SID separately
9:21 - slide 7, header slide, similar to routing header type 0. most important fields are next segment and last segment and segment list (made out of 128 bit ipv6 address packet must traverse) and a pointers to next and last segment. Policy list can be identified as following 128 bit from last segment pointer.
9:23 - slide 8 - 3 element types, ingress, egress, original source address. SA is where enters SR domain, there was some thought that we may want original source address if we were to change it in flight, not sure if use case is there or not for that. HMAC for security (optional). Processing - read next segment, put it on the next DA, move pointer for next segment down.
Only nodes that are the DA should look at SRH, others MUST ignore. Only routers that must process.
9:25 - Uma / Ericsson - question on slide 7 - would be good if draft discussed expected header lengths, fixed, and variable size, especially with HMAC.
Stefano - only next segment changes, all pushing is just at ingress, whole header is kept through SR domain.
Uma - what is the size of this header costing us?
Stefano - not good to change size of header during path lifetime, and use cases can show path of packet path. Very nice feature to have.
Fred Baker - if you change the packet, there is a memory copy, expensive
Eric V / Cisco - we can't change due to HMAC - we only on the non-variable fields that don't change on path.
Slide 9 - deprecation of header type 0 motivated by security concerns
9:34 - Slide 10 - packet walk - A/C/F/H SR capable, rest vanilla IPv6. at ingress A a SRH list for TE engineered path on arrows with original DA replaced by C, B just sees as normal packet going to C, on and on through H, last router H has flag that cleans up SRH and remove it before forwarding to non-SR capable Y. Same principle as MPLS.
Slide 11/12 - overlays - video delivery demo'd using similar topology at IETF Toronto. SR can just be done on edges, core could be IPv6/MPLS or anything else only SR nodes needed at edges.
Slide 13/14 - slight changes on 6man-segment-routing-header, only to policy semantics, not to forwarding. Interop demonstrated @IETF90 with first video cache that could honor request delivers it, otherwise continue forwarding.
Slide 15 - another SR case, Openstack VM isolation. Policy list elements could identify location/DC/tenant where packet entered network and where supposed to exit. Then policy can be applied based on where entered to stop certain egress as an example. Does not impact forwarding in network.
9:40 am Q&A:
Wes George - you may want to consider removing list rather than maintaining SR segment list in header, there may be hardware concerns on how far can look into packet even with pointer. Some examples on how to work around…
Stefano: something to think about, but doubt solution of changing header is better than the problem presented. Changing header may be way more expensive for HW.
Wes: show your work if you have done analysis.
John Brzozowski / Comcast - good point Wes, we understand entire infra won't be SR capable. We recognize not everything will be SR capable to same depth.
Xiaohu / Huawai - 32 bit SID, there is some need for and for mapping, this could be concern?
Stefano - I think we never published a draft with a solution of mapping SID that are not IPv6, just some discussions but so far not use case.
Xiaohu - why not just use ordered list of labels?
Stefano - not sure what you are saying that would be MPLS?
Saikat Ray / Cisco: MPLS label as SID I think he is saying, but problem is he won't know IPv6 next IP mapping
Stefano: There is advantage of not having control plane mapping server to map SID to IPv6 address
John (chair) - take offline
9:48 - Jen Linkova / Google - draft confusing in two sections - adjSID may have address that are not part of global address space, then later it says adjSID has global significance, we may have backbones based on link-local.
Stefano - may be text problem, you can use local significant (link-local) address if it's only directly connected to the processing node.
Jen: you are saying it's theoretically possible for link-local if they are known somehow. Still showing on your header 3 policy elements, but you say 4 policy elements - might want to make consistent
Stefano - yes, we didn't have use for 4 yet.
Jen: what about Load balancing?
Stefano - yes you may need to go deeper in packet for transport ports or something else in header for entropy, in fact you could even add entropy in IPv6 address directly.
Jen: another use for flow label (sarcasm)?
Stefano - well, yeah, but 128 bit is plenty to find some bits for that
Jen: you may want to specify in doc if your router is not compliant with RFC 2460?
David Mozes / Mellanox: does SR support hybrid mode?
Stefano: not sure I understand question, not needed on every node.
David: what if you are SR destination in the list and you don’t want to change header, just fwd as non-SR behavior.
Stefano: no, not allowed, router must be SR capable if it's the DA due to segment list.
9:53 - Hannes Gredler / Juniper - you said possible to use link-local via adjSID? How does it learn these address?
Stefano - controller
Mark Townsley / - LB we have been thinking about (Jen's question). We find tunneling to be worst case. This is a general problem due to less entropy due to DA not being real endpoint. It's a general issue we need to pursue (not just SR related).
Alankar / Comcast - if you are in the list as SR capable but don't really understand it, can you fall back to regular forwarding.
Stefano - packet is dropped as said before, router is broken.
Ron Bonica / Juniper - it's possible link-local in segment routing header, it's also possible in IPv6 to have same link-local on multiple links
Stefano - controller would have to know if this is automatic or not, this is not mandatory/recommended but you can use if controller handles the de-conflict, it will just be more difficult
o SPRING OpenFlow Interworking Requirements - 9:58 am
http://tools.ietf.org/html/draft-khc-spring-openflow-interworking-req
Bhumip Khasnanish 10 minutes
10:00 am - listed high level requirements of OpenFlow/Spring interconnection
Arch slide - showing 3 controllers, BGP/OpenFlow/Spring controller - what interfaces do we need between controllers?
10:02 - What's Next slide - want comments/thoughts on control domain and interfaces, looking for contributors and reviewers
10:02 Q&A -
Shahram Davari / Broadcom - are controller same server/VM.
Bhumip - could be.
Sharon - why need standard, you want to standardize between controllers?
Bhumip - yes, want to make sure these messages are standardized
Shahram - I don't understand, what do you want standardize (on slide)?
Not sure - we have BGP-LS and other interfaces for this.
Sharon - SP's have expressed concern, that's why I bring it here.
o BGP-Prefix Segment in large-scale data centers - 10:05 am
https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-msdc
Saikat Ray 20 minutes
10:05 am - slide 2 - no new requirements here in use case, in IDR SR extensions to BGP presented.
Slide 3 - describe SRGB, not required that they are same, just for example in draft, here is topology
Slide 4 - loopback associated with label index, new BGP attribute label index attribute, since you are forwarding actual label, you don't need the SRGB block flooded, packet walk. Node 10 normally allocates local label dynamically, if you do receive label index attribute due to new attribute, he does offset of label index to use that specific local label. Label index keeps forwarding since it's optional transitive and each node along path in diagram computes its own local if it supports attribute based on its local SRGB.
Slide 5 - if node 7 not SR capable, still does dynamic allocated label as normal BGP 3107, and transits the attribute he doesn't understand.
10:16 am Q&A:
Hannes - how does node 4 know that node 7 does not support SR?
Saikat - doesn’t have to know.
Hannes - but he would black hole SRGB block?
Saikat - he has the exact label upstream has allocated, whether SR or not, local label is not same as remote label (3107)
John Scudder - so far - this is exactly identical to 3107?
Saikat - yes, only value is local labels can be assigned to SR index value
Bhumip - can't be openflow switch, you have not looked at openflow switch in this draft?
Saikat - no, we don't know if any special consideration to be made
Uma / Ericsson - SRGB block not used on all them
Saikat - SRGB blocks may not be same, you can't make that assumption.
Albert Tian / Ericsson - question about stacking - how do other nodes use the stack?
Saikat - not showing stacking yet
Kireeti / Juniper - why is this better than BGP 3107? Advertise into IGP?
Saikat - this is BGP, there is no IGP in this deployment model
Keyur / Cisco - just to clarify 3107 allows binding label already, this just allows local label to be assigned more deterministically based on local SRGB
Hannes - now I understand the what, just not why, this seems just as good as vanilla 3107
(back and forth between Hannes and Saikat about usefulness of transitive attribute for local label allocation)
Keyur - it's optionally transitive attribute, it's meant for partial deployments, if node doesn't understand than local label can be dynamically assigned but other nodes will still get distributed to SR.
Hannes - no way for non-supporting nodes to signal such
Saikat - BGP-LS not required to controller if all nodes support this, there is no IGP. BGP-LS sends link-state, not necessarily from IGP in this case BGP links.
Not sure - you can't pack updates right?
Saikat - true
10:33 am - capacity optimization slide - Anycast
10:36 Q&A:
Hannes - same SRGB is not necessarily possible (listed as benefit), in interop not possible to use same SRGB.
Saikat - not necessarily possible, more possible than more advantage in deployment
10:40 - John Scudder if 3107 in same or SRGB different on some boxes may not be simpler.
10:45 - Alvaro - work has to add something to architecture requirements, if it doesn't change architecture then not likely to adopt use case drafts
10:49 - Hannes - can we send SRGB to do this properly like we do in IGP's?
Saikat - must keep 3107 intact?
Hannes - let's do another AFI or something to do this properly?
Saikat - I don't see why this is improper?
Hannes - this is *language*
Saikat - I don't need to know the remote SRGB blocks for forwarding
Albert Tian - if one of nodes does not support global SRGB?
Saikat - don't need to know label, just loopback address. You need the labels of any intermediate hops that you want to TE to in the segment list (label stack).
o Bidirectional Forwarding Detection (BFD) Directed Return Path - 1
http://tools.ietf.org/html/draft-mirsky-mpls-bfd-directed
Greg Mirsky 5 minutes
Update to draft from last meeting, beneficial to control reverse path, co-route with forward in some cases. Will be working with authors of MPLS BFD extension enhancement document and hope to have updated document for Dallas meeting so we can get MPLS WG adoption in Dallas.
No Q&A.
o Entropy labels for source routed stacked tunnels
https://tools.ietf.org/html/draft-kini-mpls-spring-entropy-label
Jeff Tantsura 15 minutes
10:58 - New authors/discussion, added readable label depth (RLD) describes maximum segment labels that LSR can support, push ELI/EL as deep as possible while staying within RLD.
WG acceptance?
10:59 Q & A -
Sam Aldrin / Huawei - what happens if RLD not supported?
Jeff - load balancing gets worse, if you can't support it or cannot read it, we will advertise RLD in IGP extensions
Sam - but if ingress doesn't have information from all nodes on path (all LSRs don't support extensions)? Also - claim there is no implication for OAM.
Jeff - we can privately discuss, there are implications to OAM.
Carlos Pignataro/Cisco - do you advertise per-interface RLD or per-router?
Jeff - yes, different interfaces have different support so per-interface
Sam - yes, if different interfaces won't it add complexity to the algorithms to solve per-interface. I think it is quite complex and we should avoid talking about adoption until this solves.
Jeff - practically your SPF becomes CSPF since it contains RLD in calculation
Ahmed Bashandy / Cisco - regarding RLD per interface, various by ingress / egress / type / combination of both, it will be quite hard to advertise a correct value per interface, would be better to advertise per platform a LCD.
Rob Shakir / BT - I agree with Ahmed, it may not be visible, I think it may have to be lowest common denominator per node
Nobo Akiya /Cisco - I echo what Sam Aldrin said about OAM, need to beef up section and mention RFC7325, multiple ELI/EL in stack, what is way to forward. If not followed by all LSR's OAM is going to be broken.
Carlos - you mention this is least evil solution, I think it remains to be seen. Maybe deeper analysis.
Rob - we put all options in draft with reasoning on why this selected over other options, welcome to more options or comments on our analysis
Kireeti - missed discussion, just came in, if question on whether RLD be nodal or per-interface, should be nodal please.
Jeff - from implication standpoint, agree, practically could be problem
11:08 - John Scudder - we are late, closing meeting.