Minutes IETF100: rtgwg

Meeting Minutes Routing Area Working Group (rtgwg) WG
Title Minutes IETF100: rtgwg
State Active
Other versions plain text
Last updated 2017-12-07

Meeting Minutes

   Chairs:    Jeff Tantsura (jefftant.ietf@gmail.com)
           Chris Bowers (cbowers@juniper.net)
Secretary: Yingzhen Qu (yingzhen.ietf@gmail.com)

Monday, November 13, 2017

9:30-12:00 	Monday Morning session I ; Canning

RTG    rtgwg       Routing Area Working Group 

Chairs: Jeff Tantsura, Chris Bowers

1) 09:30-09:40 - WG Status Update
Jeff Tantsura (JT), Chris Bowers(CB)
10 minutes

CB: note well, IPR disclose, administration. thanks to note takers, and 
we'd like someone to help with Jabber. 

we have two sessions, Mon and Thur. More core items on Monday, possible 
intake areas on Thursday. We may move a few things around. 

there is a BOF on Wed, DCrouting, lot of iscussions in RTGWG will happen 
in BOF. 

Docs that passed WGLC: ready to be published. RIP and VRRP need to be 
updated to be NMDA compatible. LNE and NI Yang are in WGLC. these were 
done by design team. 

existing WG documents: draft-ietf-rtg-dt-encap expired, but still 
useful, so plan to publish it. it still needs more work on MPLS. 

2) 09:40-09:50 - draft-mirsky-bfd-p2mp-vrrp-use-case   
Greg Mirsky
10 minutes

Greg presenting. next steps: comments are welcome. we're not channging 
anything in BFD. 

CB: it will be good to get some clarification on the IPR. 

Greg: my personal opinion with this change there is a way to implement 
without affecting the IPR. 

CB: the IPR needs to be disclosed, so the WG can decide whether the work 
around is enough. 

Greg: I could possibly reach out to reach out to IPR holder. 

CB: the IPR was disclosed for draft-nitish-vrrp-bfd. 

greg: we have another draft, bfd multipoint which had IPR disclosure. 

cb: so the IPR disclosed was for the other draft. we'll take it offline 
and get this ironed out before we put this up for WG adoption.

3) 09:50-10:00 - draft-adubey-bfd-service-redundancy
Ankur Dubey 
10 minutes
Ankur presenting.

Jeff: general comments: the presentation should have more details with 
use cases. Please include BFD wg, and perhaps that is the right place to 
do this work. 

4) 10:00-10:20 - draft-ietf-rtgwg-enterprise-pa-multihoming
Jen Linkova
20 minutes

JT: Is there a need to solicit comments in v6ops or other WGs? 

Jen: No, this is purely related to router behavior, it has nothing 
changing in scope for v6ops. Indded, all comments are welcome. 

JT: please ask for comments on mailing list. 

Jen: I posted on the mailing list. Any comments are appreciated. 

5) 10:20-10:35 - Requirements of the protocols between CP and UP and
CU-separated BNG device deployment model
Shujun Hu
15 minutes
Shujun presenting.

Jeff: any question? please go to slide 5. this could work with Geneve instead.

6) 10:35-11:20 - RTG-DT-YANG-Arch YANG drafts updates and discussion
RTG-DT-YANG-Arch team
45 minutes

Lou presenting.  Plan is to close disband this design team before IETF 101, 
since main goals have been achieved.

Lou: Question to shepherd - do we need to have both non-NMDA and NMDA 

Yingzhen: The document currently has only non-NMDA examples, would be 
good to have both. 

Sue Hares: IDR chair in this case. I have some issues in revision in IDR 
bgp model has a non-nmda model. 

Lou: the current guidance: if you make a change that's not backward 
compatible, you have to change the model name. if I do routing-config-2, 
how do I know it replace routing-config? the document header is not 
shown in yang model. I'm more focused on the solution. if you're not 
talking about version of drafts, it's different. 

Sue: I'm considering the implementation phase. 

Alia: how do we as routing area continue to update and extend yang 
models? that piece is not nailed down yet. we need to talk about it. 

Benoit: I have 30 mins in Netmod talk about it. 

Dean: IETF should consider what models should be done. so it might be 

Benoit: it's not routing issue. it's industry/yang issue. 

Lou: we should inform Netmod ow to handle it. 

Benoit: there are different areas dealing with yang models. there should 
be common requirement. 

Lou: I am not certain that this WG will worry about other areas 

Dean presenting implementation examples. 

Lou: for operations, how many of you are using LNEs? what's the main use 
case for logical router? 

Rick Taylor: LNE is to reduce complexity. it's easy to use. 

Stephane: we're not using LNE now. we're only separating the routing 
part, but we're looking at full separation. Running lots of services on 
the same device are complicated, so maybe in future. 

Dean: it simplifies configuration. 

Stephane L: not just configuration. one particular feature may prevent 
you from using a version or upgrade. 

Jeff: thanks for sharing the experience. 

Lou presenting.

Jeff: thanks for the DT for doing the work.
Lou: we have talked to people doing LNE and NI implementations.
Once we have more implementations, we will have more experience.

Wrap up:
See you on Thursday.

Thursday, November 16, 2017

13:30-15:30 	Thursday Afternoon session I 

RTG    rtgwg       Routing Area Working Group ; Canning

Chairs: Jeff Tantsura, Chris Bowers

JT: Welcome to second RTGWG session. Please note an updated Note Well. 
Any contribution is covered by it. 

JT: Before we start - we need to make a decision. 

CB: There is one document that we reviewed on Monday - it has been 
dormant for several months. This is policy routing model that originally 
was produced a couple of years ago that uses Openconfig paradigm. This 
model is not in NMDA compatible, it is not the direction that the IETF 
is going. It is still a useful model. It does not show under the 
documents of RTGWG, it is still there and is still a WG document. We 
have several options that we can go here. Option 1 is that we do 
nothing. If we do not think that this work is useful. Second - to use 
this existing draft as a starting point and evolve it into NMDA model. 
The third option is to create a new draft in a NMDA compatible option. 
There is a similar issue that occurred with one of the BGP models. If we 
find a space for this we need to figure out how to move forward. 

Sue: I would speak against option 1. I would speak for option 2 or 3. 

Acee: We need this to be deployable solution in all routing protocols. 
As somebody who has implemented policy - I would like to work on this. 

CB: Sue, to clarify - you said 1 and 2 but meant 2 and 3? 

?: Does somebody deploy routing protocols without policy? Option 2 and 3 
is a question of politics. We can reuse many things in current document, 
we can make in NMDA compatible. 

JT: To explain - it is not compatible with our advise on how to do 
datastore model. 

Sue: IDR BGP model is holding on this. I have solicited on moving this. 
We hope to get BGP model that depends on this in 2 weeks. Please move 
fast. We have a prototype one. 

JT: The plan is to contact the authors of original draft and ask whether 
they want to make a version 2 IETF document. If they say no we will move 
to option 3 acknowledging their work. 

Sue: Is that []? 

JT: What I said is that we are going to contact the authors. 

Rob Wilton: The actual convergence is actually done. The actual pushback 
is option 3. 

JT: We fully acknowledge the work that the authors did. We would like to 
use approach 2 before approach 3. 

1) 13:30-14:10 - IETF technologies supporting virtualization and slicing
Jari Arkko
40 minutes

Jari presenting, 


The background for this work is the growth of work on virtualized 
network solutions and data models. We are frustrated of discussion 
around Netslices. It is a nice concept but not precisely defined, does 
not look at what is existing. Existing technologies could be reused - we 
need to understand that. Terminology is important but it should not 
drive the technical means. There is a big role for software too. What is 
the role of protocols and standards and software. Possible new work - 
what should IETF be working in this space? 

Greg Mirsky: One of the NS use cases is ultra reliable and low latency 
services and that is where PM and SLA assurance is a critical thing. We 
do have some PM protocols here at IETF, it would be interesting how that 
works end to end. Where do you think it belongs? Maybe we do not need 
new protocols but we need to see how it works. Services are so critical 
that we cannot operate the network in a way that the service is not 

Jari: You bring up a very good point. It will require new work on special 


Dean: When you mention SLAs - that is a slippery slope. You have packet 
SLAs and business SLAs. Which ones do you want to discuss? This is one 
thing that we would need much more input, reach on NANOG, RIPE and get 
the input on this aspect. Create new liaisons to exchange that 

Jari: When I mentioned SLAs I was meaning the context of aligning 
industry and terminology. 

?/UCL: I have some confusions brought up with your slides - you 
mentioned virtualization, VPN, NS quite a lot - do you see those as 
interchangeable or separate concepts? You say there is frustration that 
people are not building on what is existing. 

Jari: The terms that I used have many possible meanings, I cannot say 
that they are the same thing. I try to speak on the general topic area 
that is network virtualization, but it also covers resource reservations 
and service guarantees. 

?: Second one was on cross domain issue. 

Jari: I think there are many people that think that cross domain is the 
right thing to do. I do not say that we should not do it but it is 
demanding. Or maybe I am wrong and it is easy. 

Adrian: The third bullet - the ability to specify the underlying VPN - 
do you mean specifying this at service level or network level? 

JT: Interdomain in general is not an issue for IETF, we have been doing 
it for many years. We haven’t been doing interdomain connectivity 
across services. Maybe service level API would be the right level to 

Adrian: Work out the right level of abstraction and then specify. 

JT: There is service level work at IETF interacting with [] well 
established []. For this particular use case []. It is much more 
complicated [] [audio unusable] 

Adrian: Terminology - I would like to see short concise definition of 
NS. It may be a target trying to define NS. 

Jari: I was thinking of more fundamental pieces of terminology. It would 
be difficult to find it. 

CB: Cutting the mike line. 

Georg Mayer: I am 3GPP liaison to IETF. Discussing it this way is a very 
good approach, it allows us a possibility to bring things in. We have a 
tight schedule at 3GPP, we see NS affecting us, it affects CN and Radio 
part, it also affects the management part. We need to sort the internal 
communication needs, how much can we participate in that work soon I am 
unable to answer. 

Jie Dong: There are some emerging services that require guaranteed 
performance together with existing services. Tailored network. Another 
point - consider NS in different layers of the network. What existing 
network technology can provide and not the layers match together. 

Georgios Karagiannis: I assume the alignment of the concepts and 
technologies - it is also the case? Looking to 3GPP that is focusing on 
NS - there are some concepts that are already similar. 3GPP has work 
that is somehow similar to what you plan to do. How to ensure that we 
are not competing? 

JT: I would not say that their template are a data model. There is work 
to be done to align. They are not the same things. We need to speak the 
same language, and the idea of this draft is to provide enough thinking 
to people who understand the technologies on what can be done. 

Jari: It is important that we can point people to the future revisions. 

JT: We expect a lot of inter-SDO management. 

Alex Galis: I am very encouraged by this presentation. 

Jari: []. 

Alex: Virtualizing systems. IETF FORCES WG has shown that it is possible 
to partition the resources for a purpose. SDN allows for partitioning 
the resources of the network dynamically and managing flows. [audio 
unusable]. I would like to highlight differences where slices are 
substantial. Slices are driven by services. For a slice you need 
specialized infrastructure to support that service well. 

CB: We need to wrap up. Complete your question. 

Alex: Where do you see this additional work, not only partition the 
resources but also services, as a package. 

Jari: That is a good point. I do not have an answer at this time. 

Alex: More discussion offline. 

Jari: We will discuss this further on the list. 

JT: This is work in progress. This is work to help other people to 
understand what the IETF is doing. 

2) 14:10-14:20 - draft-ding-netmod-arp-yang-model
Xiaojian Ding (remote)
10 minutes

Xiaojian presenting. 


CB: I am not sure we understood which model this is conflicting with? 
You mentioned the specific model. 

Xiaojian: []. 

CB: It is not sure that it is clear for people. 

Acee: Interface model. 

CB: I want to jump in - this model is pretty good fit for RTGWG. 
Technically when I think of ARP it is not RTG but INT area, but in this 
draft you are talking about ARP functionality on routers. It is a good 
fit to consider for adoption in RTGWG. You have brought it to the right 
place and presented it here. I would suggest to change the name of the 
draft, to add -rtgwg- into it. 

Xiaojian: []. 

CB: Out of time for this presentation. Would be good to take the 
comments and responses. Make the changes, post that draft, and describe 
the comments that you are addressing. 

JT: Please make sure that you draft complies to NMDA. 

Alia: ARP is INT area and not RTG, I would like to verify this with INT 

3) 14:20-14:30 - Fast failure detection in VRRP with Point to Point BFD
Aditya Dogra
10 minutes

Aditya presenting. 



CB: We have reached the point of WG adoption and the consensus was to 
adopt the other draft except the IPR issues. We will do a quick 
evaluation and then poll the WG for consensus for WG adoption. 

Greg: I appreciate your consideration. I know that IPR is very sensitive 
in IETF, and would like to reiterate what was said in the first session 
- authors believe to the best of their knowledge that the state of the 
disclosed IPR does not cover the version. 

CB: This is a new draft, part of the adoption poll - we will separate 
the adoption poll and IPR poll. If there is any IPR that applies to 
p-t-p draft we expect that to be disclosed already. 

Greg: It was stated in the presentation that the drafts are now split 

CB: I understand that. Now that the drafts are split, I expect that the 
p-t-p draft will not have any IPR disclosed on it. 

Aditya: []. 

CB: If that was the point of separating the drafts - if that is not the 
case please disclose the IPR on this draft if it exists. 

Greg: There is one problem with once the IPR is disclosed and it is no 
longer applicable to the draft, there is no mechanism to withdraw the 
IPR disclosure. 

CB: Lou, our IPR consultant will give a comment. 

Lou: It is my understanding if you create a draft [] as soon as you make 
a derivative you have inherited the IPR. 

CB: We haven’t done anything to do that. 

Stewart: []. 

CB: []. 

Lou: I think you can say that IPR does not apply. 

CB: I disagree with that. 

CB: We can look at how [] we can write an explanation what the WG 

Lou: This is a WG document, how to progress. Document WG decision on IPR 

CB: We agree. 

Donald: [audio unusable]. 

CB: It is quite complicated. We will discuss and figure out the path 

4) 14:30-15:00 - draft-bryant-rtgwg-enhanced-vpn
Stewart Bryant
30 minutes

Stewart presenting. 


Greg: We had very interesting discussion - I want to point that traffic 
engineering does not necessary have to deliver low latency. It can be 
provided by the physical layer - FlexE for example. 

Stewart: FlexE is one candidate solution, it is over-allocating 
bandwidth. We need solution in packet space too - Detnet. 

Greg: We should try to look for the solution that is good, if there is 
not solution we need to solve it other way. 

JT: A question on terminology - you call it virtual network a point to 
point service. It has to be point to point if it is segment routing 

Stewart: More generic name for the technology would be useful. 

Ahmed: Let’s take the blue slice – []. 

Stewart: You need to reserve resources first. 

Ahmed: []. 

Stewart: It depends whether there is enough of resources to do it. 

Ahmed: You are defeating the purpose of SR. Suppose you have 100 
services - then I need to create 100 slices. 

Stewart: []. 

Ahmed: It does not have state. 

Stewart: I do not commit the state until I actually use it. It needs to 
provide signals to the ingress. 

Ahmed: If I need to have 1000 services, I need 1000 colors. It is not 
clear how you are integrating them. 

Jie Dong: This is for emerging services that require high bandwidth 
guarantee. This is a mechanism to provide resource mechanism, and you 
can do aggregation. 

Stewart: RSVP requires a single label end to end, this allow us to have 
fewer as you have an ability to share. 

Lou: What is the new work here? It is really good stuff, but what new is 

Stewart: This is a different view to what Jari is doing - see what the 
technologies are. 

Lou: There was TE WG for that. There is a document in MPLS WG on that 
too. It is not clear where this should be discussed. You want to use the 
stuff that MPLS uses. 

JT: It is an attempt to derive particular behavior. 

?/Cisco: I have presented SR for SFC, I have the same comment as Lou. 
What is new here instead of taking the new ideas and creating the state 
in the network that we do not need. You take all the ideas of SFC, 

Stewart: We try to show how we put components together. 

Tal: Bandwidth resource reservation is not enough - what is missing? 

Stewart: You have services competing for it in order not to affect 
latency. Maybe we could do better flow filtering, but without that we 
need to have some separation of traffic. This is about isolation. 

Greg: I think that it would be helpful if we set common dictionary that 
is already is being used in other areas that work on NS. With SDN there 
is LSO. It is a part of lifecycle. You do not throw and hope that it 
works. You have a certain process that you need to follow. Part of that 
is service activation testing. In Detnet, in some scenarios there are 
very stringent requirements on bandwidth and latency, I would like to 
understand that NS itself does set stringent requirements. There are 
best effort requirements mostly. 

Stewart: I agree with you. Focusing on stuff that needs to be added in. 

Greg: This is only part of NS use cases. 

Stewart: It is not necessary NS at all. 

Greg: Stringent requirements are part of use cases. 

?: This is traffic engineering, discussing this would be appropriate. 
There is a work that tries to find a general approach for this approach. 
Should be independent from what underlay is. 

Stewart: Building models and configuring - yes, it has to be 
independent, but the underlay is relevant to the design. 

?: If you keep the traffic that you allocate for different services. 

Stewart: Only if you have right properties and even then not certainly 
as it is statistical. 

?: []. 

Stewart: It depends on various uses. 

Stewart: It depends on isolation requirements. 

?: If you have excess bandwidth reserved and there is no other traffic 
but no congestion. 

Stewart: That is not good enough as that is statistical. 

Wim: There are two purposes of this draft - one is to put everything 
together. Second is how you do the resource allocation. That is a new 
work potentially. If you have virtual link that has specific resources, 
you have the semantics of SR today to allocate specific resources. What 
you do not have today is a mechanism to allocate SIDs related to queues 
and link properties. That is a potential new work. My suggestion would 
be to have focus on signaling in MPLS or SPRING WGs for signaling 

JT: It is to show that a label can be used as a metadata. It does not 
introduce new functionality. It is useful work but at this point you do 
not try to define new protocols. 

Stewart: I am trying to show what is missing for this solution. 

Ahmed: You want to guarantee service for traffic that has burstiness in 
it. It has nothing to do with SR, it is not specific to VPN or SFC. We 
should focus on specific problem. 

Jie: This draft is an architecture of the whole solution. 

Gunter: The missing requirement - some of physical resources cannot be 
separated from L3 perspective. Is there a reason why this was left out? 
There is not requirement to take into account different physical 
resources in the network. 

5) 15:00-15:15 - draft-wcg-i2rs-cu-separation-infor-model
Ariel Gu
15 minutes

Ariel presenting, 


Rob Wilton: You are talking about the information model or YANG model? 

Ariel: []. [audio unusable] 

Sue: I2RS WG chair - the reason why we encouraged them to do information 
model - this is not configuration based. I2RS is completing the work and 
is trying to send the completing work elsewhere. 

Dean: What you say control plane separation - are you also saying for 
separation of PPPeE or management functions as RADIUS and DHCP pools? 

Ariel: []. 

Dean: It would be good to clarify which functions you are referring to. 

Ariel: We have another draft related to architecture. 

?: DMM WG is working on separation of mobile gateways. 

CB: Could you post that to RTGWG list? 


JT: Looking forward for your hackathon project. 

Wrap Up:
Jeff, Chris

JT: See you all in London.