Minutes IETF106: rtgwg
minutes-106-rtgwg-00

RTGWG Agenda IETF 106
Chairs: Chris Bowers
            Jeff Tantsura
Secretary: Yingzhen Qu

WG Status Web Page: http://tools.ietf.org/wg/rtgwg/
Jabber room: rtgwg@jabber.ietf.org

RTGWG Session 1
Wednesday, 20 Nov 2019, Afternoon Session I 13:30-15:00
Room Name: Padang


13:30
5m
Administrivia
Jeff/Chris

13:35
10m
WG Status Update
Jeff/Chris
draft-ietf-rtgwg-bgp-pic has changed shepherd, and Yingzhen will take over.
Regarding expired draft:
Draft-ietf-rtgwg-segment-routing-ti-lfa: Stephane: we’re in the process of
updating it, but it will take more time.
Yingzhen: both RIB extension model and routing policy model have been stable,
will request last call after this IETF.

13:45
15m
Dynamic Networks to Hybrid Cloud DCs
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/
Linda Dunbar

Stewart:  I don’t understand what you’re proposing. You’re talking about
          proprietary cloud designs which are within the scope of the provider
          to define and modify APIs, we don’t have standard solutions. You can
          design a sim layer that they have to map to, but we can’t map
          proprietary systems.
Linda:    I’m not proposing a solution. I’m just saying it’s a problem, which
          might be out of the scope of IETF. It’s just a problem.
Wim:      you start from problem statement, then you’re mixing SDWAN with
          net2cloud.  You’re putting too much content. You should focus on cloud
          interconnection or SDWAN. From reading the document personally I don’t
          do where you want to go.
Linda:    good suggestion. we’ll focus on net2cloud, taking out SDWAN.
Wim:      focus on two requirements: internet facing services, and private VPN
          use cases. Focus on these two areas and make it clear what needs to
          be done.
Jeff T:   maybe you can consider separating SDWAN work if you consider it’s
          valuable. You’ve put lots of efforts writing it.
Linda:    I’ll write a short draft focusing on problems with net2cloud, not
          SDWAN. If I found some of valuable parts, I will create a separate
          document.

14:00
10m
Application-aware IPv6 Networking (APN6)
Problem statement & usecases and Framework
https://tools.ietf.org/html/draft-li-apn6-problem-statement-usecases-01
https://tools.ietf.org/html/draft-li-apn6-framework-00
Shuping Peng

Wim:      why contain to IPv6 only?
Shuping:  it doesn’t have to be. We will have to do with extensions for
MPLS/IPv4. Wim:      SR has both MPLS and IPv6. is it possible to do with MPLS?
Shuping:  yes, we acknowledge that and we’ve done some analysis. We’d like to
          carry not only ID but also meta data.
Wim:      you can do meta data in SFC.
Robin:    regarding data plane, it’s open. IPv6 seems to be simplest because of
          SRv6, but MPLS and VxLAN based are possible. For SFC, we don’t think
          it’s enough. Meta data is not standardized well.
Wim：      you should make it open although I believe IPv6 is the future.
Erik Kline: I’d suggest removing the revenue related part from the document.
          This has network neutrality issue. In the framework, you have
          application sending metadata that has some serious privacy issues. You
          could end up forcing devices in a large network to DPI their traffic,
          and I don’t see the issues being discussed in these documents. It’s a
          huge problem.
Shuping:  we acknowledge the security and privacy issue, and that’s documented
          in the draft. Some mechanisms such as access control and
          authentications are needed.
Erik Kline: the potential for abuse is not discussed.
Jeff T:   looking at 6man SRH discussion, they’re focusing on a single domain.
          You’re proposing Internet wide?
Shuping:  we could start from a single domain. We discussed with operators and
          they own their networks as well as the applications.
Jeff T:   my point is privacy should be a center work. if you can’t provide
          privacy, technology is not usable.
Shuping:  my understanding of privacy is information exposed by applications,
          and the information can be encrypted, also the applications should be
          authenticated.
Jeff T:   I’d like you make this the center of your work and make it clear how
          you’re going to do it.
Aijun Wang: I think this is useful, and we want to make sure to make the
          applications SLA insurance. there are so many applications, if you use
          application ID and the router may not be able to hold so much
          information. How do you consider this problem?
Shuping:  it depends on the device capability. First, not all applications are
          process this way, only for demanding applications with special needs.
Aijung Wang: for traditional network, we classify applications into several
          categories, and it can be easily deployed. it’s not possible to deploy
          these many different applications.
Shuping:  that’s about how to design the application ID. Currently we have
          segment, and could somehow to categorize traffic into groups.
Doc Montcomery: why can’t you achieve with existing solutions like QoS, is it
          in the draft?
Robin:    yes. There is problem statement in the draft.
Doc:      is your ID global unique?
Shuping:  that depends. It needs to be unique in one domain. And we will need to
          consider multi domain case.
Linda:    I found it’s very useful. Even people are concerned with security
          reasons, we can do something to hide user information. Bring the
          application information into the network is very helpful, and this
          has been discussed in other SDOs. Customers want application based
          forwarding not based on IP address but application ID.

14:10
10m
SRv6 Path Egress Protection
https://datatracker.ietf.org/doc/draft-hu-rtgwg-srv6-egress-protection/
Huaimo Chen

Kereeti:  do you think it will work with SRv6+?
Huaimo:   if SRv6+ progress, we will consider adding support for it.
ChenWeiQiang from China mobile: This is useful. For 4G, China Mobile deployed
          dual home for protection. I think this can be used in future. Can it
          be configured more than more back up?
Huaimo:   we need to consider it.
Aijun:    can the mapping be done automatically? Currently it’s configured.
Huaimo:   it can be manually configured. right now it’s controller environment
          and can be done through controller.
Aijun:    if this can be deployed automatically it can ease the management of
          vpn protection.
Huaimo:   this draft is about basic solution. Based on this, we can extend the
          automatic solution.
Shraddha Hedge: you could use any cast locator, why is it not used here?
Huaimo:   the locator here provides the association of egress node.
Shraddha: just same locator on both PE3 and PE4, and it will be the same SID.
          Anycast locator. You think it works?
Huaimo:   yes.
Jeff T:   for my understanding, you’re providing back up. Unless your primary
          is down, traffic is send to the primary. For anycast, traffic is sent
          to any node.
Huaimo:   I don’t know the exact semantics.
Jeff T:   you’re proposing backup while Shraddha is proposing any cast, and
          there is difference.
Louis Chan: if you want to protect VPN, do you need to look deep into the
          packet? How many labels do you need to read into the stack?
Huaimo:   for vpn, we need more information and the details are in the draft.
Stewart:  we’re not ready. You need to consider whether any cast is better
          solution, and whether you’re compliant with architecture design.
Jeff T:   please use the list to discuss the issues.

14:20
10m
Architecture for Use of BGP as Central Controller
https://datatracker.ietf.org/doc/draft-cth-rtgwg-bgp-control/
Huaimo Chen

John Scudder: why do we need to work on this? People already have been doing
          for some years and seems like we could do just fine without any RFC.
          I would discourage the working group to take it. We don’t need an RFC.
          If you have any convincing reason, please go ahead.
Huaimo:   we’ve been using this for some time. And some document as
          informational might be helpful.
Stephane: I don’t like you use BGP as a controller, it’s a protocol and south
          interface, but not a controller. BGP is just an interface so
          controller could use to program a path, and we already have
          extensions to do so.
Huaimo:   you think we should generalize it?
Stephane: no, we already have controller architecture in IETF.

14:30
30m
I2RS: Mistake or Solution
Dean Bogdanovic

Jeff Hass: former chair of I2RS. this is the undead coming back to haunt you.
           The presentation has lots of excellent points. I2RS failed what we
           want ed to accomplish and end up with models. But we helped NETCONF
           and NETMOD, and lots of work were pushed by I2RS. RIB model got
           upgrade. There are lots of inputs that this failed experiment had in
           terms of pushing on the rest IETF ecosystem to develop good stuff. If
           we don’t solve problem in IETF and vendors will fork off and do their
           own things, and the most successful is Google. Walking dead SNMP is
           returning in many aspects. People are solving exactly the same
           problem as we did in I2RS.
Dean:      I agree with your comments. This slides shows the value coming out
           of I2RS (Initial Services Included in I2RS). I still see controller
           agent, and I’d say let’s remove that and put in appropriate layers
           and decide whoever framework we want to support.
Jeff Hass: I tend agree and I think those things are necessary. My prediction
           as long as we force this work to touch NETCONF it shall fail. People
           in that group do not have an agenda that align with us.
Rob Wilton: we got in NETMOD with Andy and NMDA architecture was we almost got
           to the point of defining what you’d need for I2RS and we didn’t do
           this the small bit at the very end, so the architecture talks about
           how you would do a dynamic datastore but doesn’t define one. I still
           think there’s a small step fro that point of view to enable that
           functionality because the data models have already been written.
           Whether that’s the right thing to do is a very different question.
Dean:      I’ll resist my comment on NMDA architecture.
Jeff T:    what’s your position?
Dean:      we have some models and people are not implementing because some
           models are too big, too complicated. Instead of putting everything
           under the sun, what framework we need to or API, we should be
           flexible. Why can’t we have a FIB model and RIB model and understand
           how the RIB to FIB translation has been done and just compare them
           and know what is my actual state. I have to know may RIB models and
           FIB models from vendors to do things like that to give me a much
           better overview, and what’s actually really on the wire versus some
           other groups are doing. I’m also worried that we’re pushing too much
           a 20 year old technology that was first proposed in November 2002.
           It’s not the friendliest programing tool. Moving forward I’d like
           to see us being more flexible to those new tools and new frameworks.
           Decouple NETCONF from YANG, don’t keep them connected.
Jeff T:    anything actionable for the WG?
Dean:      I’ll write a draft, set of requirements and action items before next
           IETF.
Jeff T:    that would be great. Thank you for your presentation.

RTGWG Session 2
Friday, 22 Nov 2019, Morning Session I 10:00-12:00
Room Name: Padang

10:00
15m
Extended BFD
https://datatracker.ietf.org/doc/draft-mirmin-bfd-extended/
Greg Mirsky

Andrew Gray: how’s micro BFD play into this?
Greg         I don’t know about micro BFD. I know about S-BFD.
Jeff T:      it’s BFD over LAG.
Greg:        BFD LAG spans cross a singe hop session. This extension allows you
             to go over one session. I haven’t thought about it, but I’ll.
Andrew Gray: From our perspective, there would be a fair amount of interest in
             having that either in the negotiation, or the capability
             negotiation.
Greg:        basically the RFC as I remember it create only single hop BFD
             session over constituents session and it has no difference from a
             single BFD session.
Andrew Gray: pretty much yes. But it’s a capability that needs to be enabled on
             both sides. Since we’re already negotiating all the other
             parameters we might be enabled as well.
Greg:        each individual session comes up individually.
Jeff T:      you need to configure it.
Greg:        we will work on it.
Jeff:        micro BFD is useful. You need to consider it.
Tony Li:     we’ve been trying to get BFD into hardware and this makes it
             harder. any other way to do it? Not BFD?
Greg:        I’d like to inherit some good features from BFD, like robustness.
Louis Chan:  you’re piggy backing all TLVs in BFD sessions.
Greg:        not all of them. I don’t see the real need for all of them.
Louis Chan:  if you separate different TLVs into different packets, it’s easy
             to implement.
Greg:        I want to stress there is no requirements to do it in a periodic
             message.

10:15
10m
Gateway Function for Network Slicing
https://www.ietf.org/internet-drafts/draft-homma-rtgwg-slice-gateway-01.txt
Shunsuke Homma

Jeff T:    speaking as a design team member, step # 1 Ii’s better if we can
           align the terms.
Shunsuke:  This document is published in IETF so the terminologies should be
           idea friendly, I’ll do the modifications.
David Allan: I’m trying to understand the relationship between the gateway and
           5G network? How’s that related to various interfaces?
Shunsuke:  slice gateway is not a device but a definition providing a mapping
function to 5G systems. David:     is it in the draft? Shunsuke:  yes Jie Dong:
 I think it’s useful to document the use cases.

 10:25
 15m
ForCES-based BNG
https://tools.ietf.org/html/draft-haleplidis-forces-bng-00
Evangelos Haleplidis

IETF/BBF liaison discussion
Chris B:   there is a liaison from IETF to BBF. Based on the IESG feedback, in
           the future we won’t be allocating time for BNG topic unless there is
           a request from BBF.
Evangelos: This is an IETF solution that can actually support it.
Chris B:   Since you brought it up, let’s have a discussion about the liaison.
Dave:      Speaking as BBF liaison. We’re gonna suspend BNG topics here in IETF.
           For BBF activities, there has been a protocol selection done from
           control plane to user plane, which is PFCP. Topics like this are
           always welcome in that venue.
Evangelos: the importance of this talk is having a data model along with the
           protocol is useful.
David S:   there is also work going on at BBF regarding data model and
           management plane. I can talk to you offline about some details.
Dean B:    I’d like to see a distributed architecture for BNG that should be
           implementation independent unless you really have an implementation
           that you can present the results.
Diego Lopez: our intention was to explore unified access for BNG. Whether it’s
           cable, in genera it’s for the access side and it’s important.
Greg:      Concur with the previous statement. get the requirements whether it’s
           access network specifically.
Jamel Had Salim: how’s the decision was made regarding the liaison?
Chris B:   the liaison is public.
Jamel:     what’s the process of BBF to do this liaison?
Chris B:   let’s take it offline.
David S:   BBF changed their bylaws such that everyone can pay a small fee and
           access the work in progress.
Fengwei Qin: the solution from BBF  is not covering our network situation. We
           can talk after the meeting.
Evangelos: let’s talk after the meeting.
David S:   if there are requirements that’s missing in the BBF, you an still
           submit it there.

Evangelos Presenting…

Louis Chan: to standardize a protocol in between is a very big challenge. There
           are many different vendor implementations, only a small standard
           portion at IETF. There are different line cards, and how you send
           one message to control plane for those line cards?
Evangelos: is the first question how do you standardize the connection to the
           radius server?
Louis:     it’s very vendor specific, and only a small portion is standardized,
           so it’s difficult to standardize the whole thing.
Evangelos: it’s already an IETF standard.
Louis:     you need to translate all the radius from control plane to forwarding
           plane.
Diego:     there is no data path to control path using radius. Radius is a
           subscriber management.
Louis:     there is still enforcement in someway.
Dean B:    having a fixed set of basic primitives then have vendor augment it
           is very useful. Louis mentioned radius is a good example, I like the
           idea, the question is whether there is any implementation? If you
           could explain why this is better? There are other frameworks. I can
           use plenty ways to model it, why this? You need to do the comparison
           why you should use.
Evangelos: ForCES is not only about serialization, it’s an architect that has
           already specific capabilities like HA etc. for other framework, you
           will have to develop these.
Dean B:    except being IETF protocol, I can use existing frameworks.
Diego:     they’re not IETF standard, and this has been deployed.

10:40
10m
SRv6 Deployment Consideration
https://datatracker.ietf.org/doc/draft-tian-spring-srv6-deployment-consideration/
Chongfeng Xie

Dino:     can you put some values about the switchover? How long does it take
          to make the switchover? In seconds or ms?
Chongfeng: it’s in days to get the service up instead of months.
Dino:     did you do any measurement on the switchover time?
Chongfeng: not yet.
Tony Li:  it’s more about VPN. Any real TE?
Chongfeng: no TE yet.
Tony LI;  There are simpler solutions than SRv6. How much bandwidth have you
          wasted to get this VPN?
Chongfeng: the bandwidth is from Gbits to 10Gbits.
Tony Li:  you could have done it with simpler solution. Did you consider how
          much bandwidth wasted?
Robin:    the benefit is to cross multiple domain. the backbone is pure IP and
          it’s difficult for VPN.
Tony:     you could run GRE tunnels.
Robin:    let’s take it offline.
Dino:     how many sids are used in each path?
Robin:    right now only on edge nodes, no SRH yet. In the future no more than
10. David Dai: for the incremental deployment slides, the first step is to
upgrade
          ipv4 to ipv6, and step two is to upgrade edge devices. What if we only
          upgrade ipv6 in the core network, and edge networks are still ipv4,
          how does it work in this scenario?
Chongfeng: in our case, IPv6 has been deployed everywhere, so we’re considering
          this is a better solution than SR-MPLS. For other operators, maybe
          SR-MPLS is a better choice.
David Dai: maybe in some cases, we should update the edge devices first.
Wim:      you’re comparing with MPLS, there are other implementations in IP,
          then your comparisons are not always true. It’s not 100% accurate with
          the capabilities we have at IETF.
Chongfeng: this is not an absolute comparison. In some cases, SR-MPLS has
          advantages.
Wim:      if you want to document how to migrate to SRv6, that’s ok. But if you
          want to do a comparison, better also consider other aspects.
Saturo from SoftBank: thanks for sharing. I’m happy to see SRv6 deployed not
          from green field. In the future, it will be helpful if you include TE,
          or flex-algo that will reduce the SIDs field. Inter-domain flex-algo
          it possible.
Chongfeng: it’s depending on the process of compressed sids.
Saturo:   it’s a bit scary you mentioned compressed SID. For me, 128bits is
fine. Jeff T:   it’s interesting to see the migration from RSVP-TE, and see how
people
          resolve bandwidth reservation.

10:50
10m
SR-TE Path Midpoint Protection
https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding
Huaimo Chen
Zibo Hu

Louis chan: due to micro loop, there is still possible to drop traffic. We can
           talk offline.
Huaimo:    the problem you mentioned is invisible. When N fails, P start FRR
           before IGP convergence.
Louis:     during IGP reconvergence, there is insychronized state, there will
           be packet drops.
Huaimo:    there will be micron-loops but minimum.
Martin:    use any cast can solve the problem, maybe even faster?
Huaimo:    there are issues with any cast.
Martin:    what are the issues?
Huaimo:    we can talk offline with more details.
Stephane:  you can’t always any cast in some network design.
Martin:    any cast works will be useful in some cases.
Huaimo:    any cast might be a solution for egress, and harder for midpoint.
Stephane:  can’t you solve by delaying ? not about your solution. Just try to
           keep your forwarding in your hardware for a couple of seconds.
Chris B:   Stephane is asking why not just delay installing the blackhole? Keep
           the old entry.
Huaimo:    good question, so it’s to delay IP forwarding.
Stephane:  MPLS forwarding. If we just delay to change it, it works. Only keep
           the forwarding plane.
Huaimo:    we need to have some ways to keep the forwarding entry.
Stephane:  I’m not sure you need to keep the control plane.
Huaimo:    we need to let them know to keep the forwarding entry for some time.
Stewart:   presume if you use anycast in the end, all the fast reroute will
           resolve the issue. P discovers it can’t go to N, then it will go to
           N’, which is N1, then C. So any cast would work for a very common
           scenario.
Huaimo:    if you have details using any cast, please propose the details in
           the list.
Dino:      I’d support the idea because if if the SID is an any cast address
           with reroute, then the headend doesn’t have to change the SRH, and
           this is very useful.
Huaimo:    there might be routing loops with any cast and there are other
issues. Stewart:   in real networks with multiple hops, this solution may break
down.
           If you use any cast at exits, then ordinary FRR could deal with any
           failure.
Huaimo:    in theory, and we have pictures showing issues.
Dino:      Please state the issues.
Huaimo:    for egress, I’ve sent those issues to the list. If you’re proposing
           a solution, please give details.
Stewart:   please state the issues related with any cast. Please specify detail
           issues.
Huaimo:    I’ve sent the issues to RTGWG and SPRING.
Cendiz:    wherever you go you will need an anycast and it doesn’t scale.
Jeff T:    the working group is demanding comparison with any cast. The best
           way to address it in the draft, not the list. At least a section with
           comparison and the benefits you’re proposing.
Peter:     just for the any cast. Anycast will protect the egress node, but not
           the node in the middle. If you do any cast, you will need any cast
           for every node.
Dino:      you have link-local to realize your IGP.
Shraddha:  I have a proposal in SPRING talking about using any cast as well as
           the delaying process that Stephane talked about. I’d like everyone
           to take a look.
Louis:     I think we need both solutions.
Jeff T:    we need to decide with SPRING where the work belongs to. We should
           be able to converge solutions.

11:00
5m
YANG Data Model for
ARP
https://tools.ietf.org/html/draft-ietf-rtgwg-arp-yang-model-03 Bo Wu

Jeff Hass: I read several versions of this draft and I’d like to suggest to the
           chairs that this is ready to go three versions ago and WG LC will
           push the completion faster.
Hamasu from Ciena: is static ARP covered?
Bo:        it’s covered.
Jeff T:    I will start the YANG doctor review and the process. Thank you for
           the good work.