Minutes for RTGWG at IETF-93
minutes-93-rtgwg-1

Monday, July 20, 2015
        09:00 - 11:30  Morning session I
        Chairs: Jeff Tantsura, Chris Bowers
        Scribe: Ignas Bagdonas ibagdona@gmail.com

1) 09:00-09:10 - WG Status Update
Jeff Tantsura, Chris Bowers
10 minutes

Jeff Tantsura: Status update.
Acee: We got protocol extensions for advertising protocol extension parameters
- will that go to last call soon? Jeff: Yes. Acee: Will get some more people to
look at that in OSPF.

2) 09:10-09:20 - draft-liu-rtgwg-ipipv4-tunnel-yang
Helen Chen
10 minutes

Helen presenting.
[presentation]
This is YANG model for IP to IP tunnels.
Relationship to other models. It is an independent tree, linking to other
models of interfaces and routing. Overview of model structure. Augmented with a
leaf to indicate the actual operational parameter showing the type of the
tunnel. Next steps: we plan to work with authors of both drafts and merge them.

[discussion]
Acee: I noticed the concept of binding interface where you bind on the RFC 7223
interface list. That seems to make an assumption that interface itself is going
to be a tunnel. Shouldn't they be parallel instead of binding to the interface
list? Acee: The other thing is an example of referencing the routing instance
from the tunnel, and there are different ways of doing that. Helen: The binding
interface - I do not agree whether ietf-interfaces is about physical
interfaces, that may be more than that. Benoit: Yesterday during YANG editing
session we were reviewing one tunnel draft. Do you want to have a typedef to
define a tunnel type? Helen: Probably you are talking about this document. We
will take care of it in the next version, I agree it should be a typedef. I do
not know whether it is the right way to do as it makes configuration more
difficult. Helen: This structure will end up allowing to do that. Jeff
Tantsura: Good to see this being discussed on the list. Alia: Tunnel work
belongs to intarea mailing list. Stephane Litkowski: It would be better to
augment the current tunnel document than trying to create this binding
interface. Helen: Will look at that. Chris Bowers: Question to Alia - it would
be useful for people to know where to bring the work in the first place, is it
here or is it in INT-area? Alia: IP in IP tunnels belong to INT area. Checked
with Brian to confirm that. This is about the coordination.

3) 09:20-09:30 - draft-chen-rtgwg-key-table-yang
Helen Chen
10 minutes

Helen presenting.
[presentation]
[discussion]

Acee: This model still augments the key chain model?
Helen: No.
Acee: I still think it would be better if it does. This will allow to attach
policies in a similar way as we do with ACL, routing policy. Versus the
security database model where the database is the center of the universe and
everyone has to query that. There will also be a difference in adoption - one
will be tens of thousands, the other will be just on paper. Helen: I guess you
can map them one to the other. Key chain is restricted to a small set of
routers as it is designed for IGPs. Acee: No. It is a generic policy that you
can attach to any protocol. Helen: But it does not have what other protocols
will need Acee: I agree that some things will need to move to key chains. I do
not agree that because if you allow all the details of the security policy,
that it will permeate better. Acee: In key database model you start with
security, and everything is derived from there. In the chain model, it is a
policy in places where it is needed. Jeff Haas: There was KARP work that was
trying to provide a unified security model. The intent in RFC 7210 is not
necessary what the user will have to interact directly. How are you expecting
people to interact with it? Joel Halpern: When we did RFC 7210, it was an
abstract model. There were questions on how to enable automatic key management.
At that time it seemed good to base that model on the key tables. KARP work
itself was that it will get the model as this one. Jeff Haas: I agree, it has a
flexibility to do that, but writing a model to interact with it, there may be
cases that require splitting the configuration elements into RFC 7210 full
table and then fragments. Uma Chunduri: Thanks for doing the work on mapping
analysis. What is your conclusion about the mapping? Do both have to exist,
both have to match? What is you conclusion? Helen: I think only one needs to
exist, both can exist, but one is needed. Jeff Tantsura: Please take to the
list for further discussions. Acee: Please bring your key tables implementation
to the list.

4) 09:30-09:40 - draft-liu-rtgwg-yang-rip
Xufeng Liu
10 minutes

Xufeng presenting.
[presentation]

[discussion]

Acee: You asked me for comments, apologies for not getting back. I think it is
good to use keychain for this too. Xufeng: We are using the same thing as OSPF
does. Jeff Haas: Wearing my BFD chair hat. BFD WG thinks that they have model
that can be used by other groups, my sense is that you can use it, and provide
feedback if something is missing. RIP might not be the sexy thing to do, but it
can be seen as a simple testing ground for trying new functionality. Acee: I
see your draft still uses the inline method? Xufeng: We use the group. Acee:
That seems to be different from the OSPF then. Jeff Tantsura: From my
perspective this is one of the most complete drafts, and we are getting closer
to a WG adoption.

5) 09:40-09:50 - draft-acee-rtg-yang-key-chain
Yingzhen Qu
10 minutes

Yingzhen presenting.
[presentation]

[discussion]

Acee: We should add attachment point to our operational state, where the
policies are actually used. In my first implementation of policies that would
be easy to get, not sure about the three implementations that I have now with
Cisco. Maybe use an opaque string for attachment policy as opposed to break the
hierarchy that is in the key table? Another thing - if you are going to put key
derivation into the chain, that will be difficult, and not clear whether anyone
will use it. Maybe leave it until then? Yingzhen: There will be discussion
about operational state in this meeting, so we expect to have the answer then.
Acee: Some key people have not come to Prague, so that will likely not happen
here Jeff Haas: For all of our drafts we need to decide on structuring the
things. Try to visualize how the CLI at the least will use it. To get a minimum
amount of related information. It is possible to put a large amount of
information, and then correlate it. Yingzhen: We tried to provide all the
necessary operational state already. Jeff Tantsura: Who has read the draft? Who
think that it is ready for adoption? Please take to the list. Jeff Tantsura:
Has your comment been addressed: Joel Halpern: Yes.

6) 9:50 - 10:00 - draft-shaikh-rtgwg-policy-model
Ina Minei
10 minutes

Ina presenting.
[presentation]

[discussion]

Jeff Haas: I have read BGP model, reviewed the policy model too. I believe that
this draft is the most mature draft in terms of structure. I would urge WG to
pay attention to what is BGP specific, some things are tricky to do, as an
example extended communities. Ina: Jeff, question for you - which WG should be
used for that? Jeff Haas: Many routing implementations use BGP policy for their
plumbing. BGP must have those things, many other components need it too.
Someone will need to coordinate the BGP policy model as seen here with a
routing config model in netmod. Jeff Tantsura: Agree with Jeff's comment.
Stephane Litkowski: This is a good work. You are trying to define IGP actions,
but you define nothing about BGP. What is the boundary, what should we do about
IGP policy extensions? Where do we do IGP extensions - here, or somewhere else?
Ina: That is a good point. Stephane: The usage of tagging - for me a tag is a
local construct, it is not an IGP action, maybe it would be good to extend it.
Ina: Ok. Acee: I like the fact that we split the BGP part from generic policy
part. Apply construct seems to be a good idea to use BGP policy and apply it
via the attachment point. Jeff Tantsura: Who has read the document Who think it
is ready for WG adoption? Really encourage to read it, it is what operators use.

7) 10:00 - 10:10 - draft-li-rtgwg-utunnel-yang
Zhenbin Li
10 minutes

Zhenbin presenting.
[presentation]

[discussion]

Jeff Haas: You seem to provide a very generic framework to define tunnels. We
saw IP in IP tunnels presented already, MPLS and TEAS will have their own
models for their tunnels. Do you see this more of a framework of the tunnels,
or more from an operational perspective? Zhenbin: We focus on tunnel group and
to apply that to multiple tunnels for management purposes. Jeff Haas: It seems
that you are focusing on one use case only, and my recommendation would be to
take a look at a broader set of use cases and make it more generic. There is a
lot of activity in work on YANG for tunnel management, LIME is trying to do
some work on tunnels too, it seems you are taking an aggressive piece of work
to do. Ron Bonica: You are trying to abstract elements from different types of
tunnels and then abstract them. Does that belong to RTG or INT area? There is a
mix of forwarding and signaling elements here. Did you try talking to tunnel
design team? Ron: The thing that you call the tunnel policy - that seems to be
routing policy in fact? Will ?/NTT?: Different tunnels have different
technologies and attributes. Is it necessary to abstract them so much instead
of having separate models for each tunnel type? Zhenbin: The attributes for
tunnels are simple, and therefore we propose to abstract them. Also we focus on
operational side of tunnels too.

8) 10:10 - 11:30 - Routing YANG DT draft-rtgyangdt-rtgwg-device-model
80 minutes

Lou Berger presenting.
[presentation]

There is a wiki. Work is done on github.
Overview of the overall structure. Reasonings behind why certain things are
done in a particular way.

Zhengbin: A VM based device is still a device. Also L2VPN and L3VPN is a
service, why do we refer to L3VPN as a logical network element? Acee: Think of
it along the lines that a VPN is more than just a VRF. Loa: Different
implementations will do things in different ways. Dean: Physical element
provides you data plane separation, logical elements provide separation of
management. You can have default logical element that can be instantiated
multiple times. Andrew Dolganow/ALU: is it possible to share the logical and
physical entities together? Lou: I think that depends on the implementation.
Erik Nordmark: Container vs VM - in the end both can be shared, that is a
different way of implementing things. Loa: if you are in a containerized
environment, the difference is in what host sees. Within container it is easier
to see other entities than in VMs. Jason Stern/ALU. I am struggling with the
logical element concept and how to put that into model. Do we really need to
put logical element instance into the data model? The second thing about the
physical devices - that may end up as needing to define model for every single
device, that may be a scalability issue. Maybe keep it outside of the scope of
the model, and maybe have multiple different NETCONF sessions that provide a
different context for different logical elements? QoS is also outside - what to
do in order to refer to them? DNS policy is another example. Loa: I would like
to go through those point by point. Liu Bing/Huawei: The network instances
represented by VLAN - I think network instances should include VSI too. Loa: We
haven't gotten into detailed conversations yet. Jeff Tantsura: Would be good to
give possibility for authors to continue with the slides before discussion.

Acee presenting.
Lada: There is one substantial problem with this approach - ietf-interfaces is
designed to be a top level container, and you have it shown as a second level.
Do you intent to change RFC 7223 for this? Maybe YANG mount or graph would be
an option that could solve this? This was one option considered for YANG 1.1
but was abandoned. Acee: We didn't really constrain ourselves where things are
today. In the design team we tried to align the existing work to this meta
model. Lada: I think it was Andy Bierman who proposed feature like root. Then
there was any-data which is not as useful. Chris Bowers: Previous questioner
had a comment of 90% of uses of this would be getting to default routing
element and default routing instance - maybe it would be better to make it
easily accessible from the top level? Acee: We thought that there are multiple
use cases for that. There is more functionality than we show here. Chris Hopps:
Adding complexity for the common use case is annoying, but there is another
aspect too of having to add lots of complexity to support the different
functionality. Zhengbin: Regarding network instances - example L3VPN, VSI
belongs to one the same instance, or to other? Acee: That depends on the
implementation. Zhengbin: You have RIB in your model? Does that include MAC RIB
too? Acee: This will be answered in following slides. Igor Bryskin: In your
opinion, is I2RS agent associated with network instance, or network element?
Acee: Instance Dean: The agent is running on the virtual network element, and
you run agent per virtual element, or per device - that is management
separation. Igor: But that is not what Acee said. Loa Andersson: IS-IS and OSPF
can be used for TE, is that covered in the corresponding models? Lou Berger:
IS-IS individual draft includes TE, Loa's question was for the WG drafts. Acee:
True, I only looked ad a subset of drafts. Lou: We need to clarify how each
policy element will be used. Lou: Addressing Robin's comment - I thought we had
it in the drafts, we talked about it, and now checked and it is not there. That
is coming in the later revision. Chris Hopps: An example of copying routes from
unicast RIB to multicast RIB. Jeff Haas: There can also be metaprotocols for
copying RIBs, other things. Dean: A comment on role based access. NETCONF has
NACM, and that should be used.

[discussion]

Chris Bowers: How logical network elements and network instances would look in
the case of PE peering with CE using OSPF and then running over RSVP-TE
tunnels? Where is the hierarchy defined, how it would look like? Lou: CE will
have single logical element and single instance. PE in the context of that
single CE will have a logical network element. Then per VRF each of the
instances that contain the CE. Chris: Where is IS-IS and RSVP come into
picture? Lou: You would have a special instance that represents the core. That
is a good walkthrough example that we should do in the draft. Jeff Haas: I
think this aligns well with what a lot of people do. Having been a victim of
MIB wars, there are a lot of things organizationally great but not necessary
get mapped well into mapping into the tree. Jeff Haas: MIB-2 tree was an
attempt to structure that, but in the end of the day people were just getting
node points without caring much where you will end up in the tree. Similar risk
is with YANG now. A lot of these things are structured naturally, but many of
them (an example of mythical /device) may not. Chris Hopps: One of the goals
was not for CLI, but for automation. Lou: Have some sort of inventory. Jeff
Haas: The problem where things start to break is in handling different
revisions of models. Components need to be revised, and then the hierarchy
starts to break. Benoit: As an OPS AD: This is really good work. Jeff Tantsura:
We can have additional 15 minutes on Wednesday for discussion.

Wrap Up

------------------------------------------------------------------------------------------------------------------------------------

 Wednesday, July 22, 2015
       09:00 - 11:30  Morning session I
       Chairs: Jeff Tantsura, Chris Bowers
       Scribe: Acee Lindem acee@cisco.com

1) Update on MRT work
   draft-ietf-rtgwg-mrt-frr-algorithm
   draft-ietf-rtgwg-mrt-frr-architecture
   draft-bowers-rtgwg-mrt-applicability-to-8021qca
   Chris Bowers

   * See slides
   Loa Andersson: The LDP MRT draft is in MPLS WG. Do you think the
                  algorithm draft is mature enough to progress
                  the LDP draft.
   Chris: Expect to progress the architecture and algorithm drafts
          in next couple months.
   Loa: Please inform the MPLS WG when this happens so we can progress
        the LDP MRT draft.

2) Source/Dest Routing
   draft-lamparter-rtgwg-dst-src-routing
   David Lamparter

   * See slides
   Chris Bowers: Homenet needs this but it is not within their charter.
         Routing WG will call for adoption in the next couple weeks.
   Jeff Tantsura: Need to have a deterministic method for recursive
                  route look up.
   David: I plan to cover the recursive lookup case.

3) VRRP BFD detection
   draft-nitish-vrrp-bfd
   Nitish Gupta

   * See slides
   Santosh Easale: How do you insure VRRP backups are in a
                   consistent state?
   Nitish: Must fallback on VRRP advertisements.
   Jeff Haas: You are limited by the VRRP rate for convergence.
   Santosh: Need to document how this is handled.

4) BFD for P2MP VRRP User Case
   draft-mirsky-bfd-p2mp-vrrpuse-case
   Greg Mirsky

   * See slides
   Jeff Haas: VRRP gaining traction in data center. BFD should
              follow the data plane path it is protecting.
   Greg: Agressive timers in VRRP will expose you to problems
         with multicast.
   Jeff: Explore using VRRP/BFD with link-local multicast. May
         want to merge the draft.
   Greg: Good suggestion. Could do better with IPv6 since it
         includes link-local scope.

5) UDP Overlay Transport for NSH
   draft-kumar-sfc-nsh-udp-transport
   Larry Kreeger

   * See slides
   Alia Atlas: Complexity of draft is around how it is going
      to interact with the security considerations. Have been
      talking to SFC chairs. The draft is probably better in
      the SFC WG.
   Jeff Tantsura: So SFC will update charter to allow this?
   Alia: Yes - if necessary this is what wil be done.

6) Microloop Problem/SPF Backoff
   draft-ietf-rtgwg-backoff-algo
   Bruno Decraene

   * See slides
   Jeff Tantsura: Document updates are a significant improvement.

7) Virtual Multi-Instance
   draft-hegde-rtgwg-virtual-multi-instance
   Shraddha Hegde

   * See slides
   Greg Mirsky: Propose to be applicable to IS-IS and OSPF?
     Why can't you use NBMA to reduce flooding?
   Acee: NBMA doesn't reduce the amount of flooding.
         Operators don't want thousands of areas.
   Shraddha: Configuation is zero-touch and areas per remote
         would not  work for IS-IS.
   Les Ginsberg: What do you want the IETF to standardize?
      There are conceptually similar solutions?
   Shraddha: Procedures are necessary on border routers.
      Default behavior needs to be standardized.
   Pushpais Sarker: Border readers need to agree on behaviors.
   Jeff Haas: Operational practices needed to solve this problem.
        Similar to GROW for BGP. Allows multi-vendor environments.
   Uma Chunduri: Need to describe hub behavior. IS-IS has
        flooding scope RFC. This is required?
   Shraddha: Yes.
   Alia: Both hubs need to advertise the links between them.
         How do you identify the hubs in this topology?
         Could be done with vitual areas as opposed to be
         virtual instances.
   Les: Believes there are existing solutions using this
        technique.  Nothing to be standardized.
   Acee: Declares knowledge of IPR on similar technique to
         do the isolation in IGPs rather than with a separate
         instance.
         http://www.google.com/patents/US20140010117
   Jeff: Go to IGPs for review.

8) IGP bandwidth-based metric
   draft-spallagatti-rtgwg-bandwidth-based-metric
   Santosh P K

   * See slides.
   Chris: Why is there a list of bandwidth prefernces in the
       draft?
   Santosh: Just a choice - open to suggestions.
   Uma: Not needed in draft - internal detail of implementation.
   Jeff Tantsura: Would like to see discussion of this on the list.

9) Routing YANG DT
   draft-rtgyangdt-rtgwg-device-model
   Lou/Acee

   Lou Berger, Acee Lindem, and Chris Hopps reviewed design team
     next step slides. Disagreement expressed among DT members on
     opstate discussion in netmod.
   Jeff Haas: Summarized tradeoffs for where to place
     operational state in yang model.  Advice to DT and Yang models
     is to put both config and operational state in models. Expect
     to have to change the placement of information after openconfig
     and netmod come to an agreement, but don’t let that hold up
     the basic work to address use cases.

    Igor Bryskin: Asked Acee for clarification on his opinion on
     openconfig opstate proposal in netmod.

10) Encapsulation Considerations design team update
    draft-ietf-rtgwg-dt-encap
    Erik Nordmark

    * See slides.
    Jeff Haas: Are the OAM packets privacy impacting?
    Erik: Why is this a problem?
    Jeff: End user cannot tell the mechanisms being used to monitor
          your tunnels.
    Erik: Think I understand but don't have an answer. Will need to
          think about it.
    David Black: If you use UDP source port for entropy, then your
          packets are not reversible. These are transport issues.
    Erik: Changes path but doesn't blackhole the traffic.
    David: There are potential issues.
    Greg Mirsky: You need to support in-band OAM. MPLS has this.
    Erik: This has come up in other contexts.
    David: ECN congestion text is MPLS specific. Need pointer to
        Transport area document.
    Jeff Tantsura: New protocols and encaps need to read this.
        Especially within SFC and NVO3 WGs. Would like Alia to talk
        to transport area.
    Alia: Need to send Transport Area an E-mail indicating that it
        has been adopted and another when it is submitted for
        publication.

    Lou Berger, Acee Lindem, and Chris Hopps reviewed design team next step
    slides: Disagreement expressed among DT members on opstate discussion in
    netmod.

    Jeff Haas (Juniper) summarized tradeoffs for where to place
    operational state in yang model.  Advice to DT and Yang models is
    to put both config and operational state in models. Expect to have
    to change the placement of information after openconfig and netmod
    come to an agreement,
    but don’t let that hold up the basic work to address use cases.

    Igor Bryskin (Adva)  asked Acee for clarification on his opinion
    on openconfig opstate proposal in netmod.