Minutes IETF100: rtgwg
minutes-100-rtgwg-00

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
draft-cuspdt-rtgwg-cusp-requirements
draft-cuspdt-rtgwg-cu-separation-bng-deployment
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
examples?

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
faster.

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
requirements.

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,

[presentation]

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
available.

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


[discussion]

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
information.

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
interwork.

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.

[presentation]

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
ADs.


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

Aditya presenting.

[presentation]

[discussion]

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
again.

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
understands.

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

CB: We agree.

Donald: [audio unusable].

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


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

Stewart presenting.

[presentation]

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
driven.

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
needed?

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,
slicing.

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,

[presentation]

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?

[discussion]

JT: Looking forward for your hackathon project.

Wrap Up:
Jeff, Chris

JT: See you all in London.