Skip to main content

Minutes for RTGWG at IETF-94
minutes-94-rtgwg-2

Meeting Minutes Routing Area Working Group (rtgwg) WG
Date and time 2015-11-05 06:20
Title Minutes for RTGWG at IETF-94
State Active
Other versions plain text
Last updated 2015-11-23

minutes-94-rtgwg-2
Routing Area Open Meeting (rtgarea)
IETF 94 (Yokohama) Agenda
Monday, November 2nd, 15:20-16:40

Chairs: Jeff Tantsura, Chris Bower
Scribe: Acee Lindem (acee@cisco.com)
WG Status Web Page: http://tools.ietf.org/wg/rtgwg/

1) WG Status Update (See slides)
      Jeff Tantsura, Chris Bowers

2) BGP Flow-Spec Indirection-ID Redirect (See slides)
      draft-vandevelde-idr-flowspec-path-redirect
      Gunter Van de Velde

      Robin Li: How is the Indirection ID allocated?
      Gunter: Depends on the usecase.
      Robin: What is the usecase.
      Keyur Patel: Envision multiple hetrogeneous forwarding planes.
         Provides a tunnel abstraction layer through the
         Indirection ID.
      Robin: Indirection ID configured on controller?
      Gunter: It can be manual config or orchestrated.
      Robin: Has concerns with deployment? Segment Routing tunnel
             provisioning has been proposed in SPRING WG.
      Alia Atlas (No hats): Indirection ID - Is this exactly the same
             as the Nexthop ID defined in I2RS RIB model. Should be
             aligned with this model as it solves the same problem.
      Wim Henderick: This can be more than jsut the nexthop.
      Keyur: The Indirection ID may not be ephemeral like I2RS
             Nexthop ID.
      Jeff (No hats): Seems to be a Policy ID rather than an
             Indirection ID. We need to work across WGs to define
             routing policies.

3) BGP Prefix-Independent Convergence (See Slides)
      draft-bashandy-rtgwg-bgp-pic
      Ahmed Bashandy

      Tony Przygienda: Interesting work but what track?
      Ahmed: Written as informational.
      Jeff: Should be informational. Need to add more
            use cases to the draft.
      Tony: Definitely a good document to educate service
            providers.
      Ahmed: BGP multipath is a bigger discussion and did
             not want to get into it in this level of
             complexity in this document.

4) Microloop Avoidance Segment Routing
      draft-hegde-rtgwg-microloop-avoidance-using-spring
      Pushpais Sarker
      Anil Kumar: Why does it loop since the backup is an LFA?
      Pushpasis: The micro-loop is post convergence.
      Tony: How would trigger cut-over to SR tunnel?
      Acee Lindem: How do you avoid microloops when the nodes
        return to the routed path?
      Pushais: It works.
      Jeff: Service Provider - would you be willing to deploy something like
      this? Bruno Decraene: Yes we need a solution for microloops avoidance,
      otherwise negates the benefits of IPFRR. Jeff: We all agree we need a
      solution. The question is at what cost?
         I would really like you read the draft and see if it’s applicable and
         be willing to deploy something like that.
      Acee: I now see that this will work since after the  convergence delay
      since there is no loop for
         either the tunnel to PLR path or post convergence path.

5) Segment Routing MRT
      draft-agv-rtgwg-spring-segment-routing-mrt
      Anil Kumar S N
      Chris Bowers: Have some comments to share offline.

6) YANG Key-Chain Model
      draft-acee-rtg-yang-key-chain
      Yingzhen Qu
      Jeff: Will be presented in Security Open Meeting.
      Acee: New features are the result of discussions with
       Brian Weis.
      Dan Bogdanovic: Lifetime will be in reusable type.
      Acee: Needs to meet our requirements for a key
            lifetime.
      Yingzhen: Will look at incorporating model.

7) RIB Extensions
      draft-acee-rtgwg-yang-rib-extend
      Yingzhen Qu
      Jeff Haas (I2RS Chair): I2RS Model models have a lot of
        overlapp. Please talk to the authors for alignment.
      Dean: Look at device meta-model.
      Jeff: Augment with weight.
      Dean: RIB Model - Make it less layer 3 specific.
      Yingzhen: We will work to align all the RIB models

THURSDAY, November 5, 2015
1520-1720  Afternoon Session II
Room 304        RTG    rtgwg       Routing Area Working Group WG

Chairs: Jeff Tantsura, Chris Bowers

WG Status Web Page: http://tools.ietf.org/wg/rtgwg/

1) draft-liu-rtgwg-yang-vrrp (See Slides)
   Xufeng Liu

   Jeff: How many have read?
   Jeff: Please review the model. VRRP is deployed all over.

2) draft-liang-rtgwg-staticrt-yang-cfg
   Gang Yan

   Jeff Haas: Lots of existing work.
   Sue: I2RS model covers all this - why are you not looking
    at this model?
   Jeff: Please look at existing work in this area.

3) OpenConfig models (See slides)
   Anees Shaikh
   -- draft-ietf-rtgwg-policy-model
   -- draft-openconfig-rtgwg-local-routing
   Jeff Haas: Why is this not extending ietf-cfg?
   Alia Atlas: Please look at the I2RS RIB model. It covers
      policy.
   Anees Shaikh: Where does it this overlapp?
   Sue Hares: Can help with I2RS RIB model.
   Alia: It has what is needed.
   Rob Shaikh: OpenConfig is focused on the operational models SPs
     use for managing their networks.
   Anees: We have looked at the RIB model.
   Robin Li: Need clarification on I2RS models?
   Anees: Can not answer that question.
   Derek Yeung: Question on policy - where is the instance
    identification in the policy model?
   Rob: Doesn't support this yet. Do we generically do it or do
    we do it in protocols using the polies?
   Jeff Tantsura: Needs to add more notifications when a route
    goes away.
   Anees: Continuing to modify model.

   -- draft-openconfig-rtgwg-network-instance
   Rob Shakir
   Jeff Haas: Both models have context.
   Rob: Goal would be to support both of them.
   Jeff: Default become difficult.
   Rob: Defaults are not specified.
   Jeff: Does it make sense to have two models for slice of
     routes and operational route table.
   Acee: Can we do this with one model for a device?
   Rob: It will be very difficult to align a complex device
     with ietf-routing? OpenConfig needs to get this out
     there and get experience.
   Alia: We know there is complexity and we need experience
     in deployments. Maybe we should target different ranges
     of functions.
   Rob: Maybe we can provide some use cases.
   Kireeti Kopella: Very supportive of this work. You say you
     aren't asking for adoption but in essence you are. Are
     you asking the IETF to throw away what has been done
     so far?
   Alia: It is possible that some models are applicable in
     areas and not others. The IETF is where we come together
     and ask for consensus.
   Kireeti: Potentially we should throw away the IETF models?
     Maybe you should provide a vendor neutral model?
   Rob: This is a usable set of functions.

4) 16:05-16:25 - unified tunnel model discussion
   -- draft-li-rtgwg-utunnel-yang
   -- draft-li-rtgwg-tunnel-policy-yang
   -- draft-wwz-netmod-yang-tunnel-cfg
   -- draft-zheng-intarea-gre-yang
   -- draft-liu-intarea-gre-tunnel-yang
   -- draft-liu-intarea-ipipv4-tunnel-yang
   Zhenbin Li

   Jeff Haas: Unification is needed? Have you presented in INT area
    and SEC area?
   David Black: What is an IP tunnel?
   Robin: Tunnel with IP encapsulation.
   David: An IP tunnel is defined by having an IP header? Go to the
    INT Area. Is there an IP endpoint at ingress? Many tunnels with
    UDP tunnel in the shim.
   Jeff: Take other questions to the list.

5) 16:25 - 16:35 - draft-chen-rtgwg-resource-management-yang
   Xia Chen
   Acee: There is overlap with the SR YANG model.
   Xia: Does cover all the usage of labels.
   Robin: There are requirements for management of resources that
    span multiple WGs. Will send mail to the RTGWG list.
   Dean Bogdanovic: Is this for resources on the device or in the
    network? There are many ways to view this.
   Lou Berger: There is already work in MPLS and TEAS for label
    management.

6) 16:35 - 16:50 - draft-mwnpkazcap-rtgwg-common-oam
   Greg Mirsky
   Yuji: How does this relate to the LIME WG?
   Greg: The charter of the LIME is data model. This is about
     creating protocol instruments?
   Alia Atlas: This is protocol work and belongs here in Routing.
   Tony Prygienda: For technology to be successful, OAM is critical.
     It won't be easy and support this work.
   Greg: Come to BIER to discuss OAM mechanism resulting from
     recommendations of the DT.
   Chris Bowers: Overlap of LIME is not just YANG model. They are
     also chartered to do an OAM architecture.
   Alia: The right thing to do is to get the design team going on
     the OAM work for the different encapsulations. I'll discuss
     where to do it with Beniot.

7) 16:50-17:00 - draft-nitish-vrrp-bfd
   Greg Mirsky

8) 17:00 - 17:20 - Routing YANG DT update draft-rtgyangdt-rtgwg-device-model
   Acee Lindem

   Robin Li: this work of consolidating the models is important. Would like to
   clarify the network instance part,
     and service related aspects - QoS, etc, and how that maps to the network
     instance?
   Acee: [...]. This is on a logical element level, and then you bind that to
   the logical instance context,
     as it needs to have address, interface, etc defined. have you looked into
     the draft?
   Robin: not the latest.
   Alia: this is good work. Eventually there will need to be things other than
   routing.
     Trying to define all is a large job. We need to get some consensus on how
     to integrate other things from operations side into this.
   Acee: the logical network changes define the amount of work in structuring
   the model, how to augment it, Lou: we are discussing that with people
   outisde RTG already, that has been discussed in netmod.
     There are some things happening in parallel. There is a big issue how long
     we wait for the right answer vs the current answer.
   Chris Hopps/DT: we discussed that in netmod, and they think that we should
   not have everything underneath. There is an ed to have things that just
   work, but that will reuqirem changes. Lou: we will likely end up doing two
   parts at once and see which works; Dean: if you have one device and separate
   management domains ...... Lou: last 4 speakerts were DT memebers JeffH: I am
   not a DT memeber. Issue with openconfig - community based view of teh system.
      In SNMP there is a problem of addressing the instance. Second problem -
      there are SNMP systems that have multiple FIBs?? and relaying between   
      them is tricky? [???]
   Acee: proprietary community strings ...
   JeffH: Would suggest to have individual moudules and make those
   multi-instance Lou: we should have a long discussion on that, JeffH: you may
   need something much lighter for that. You will have a view of the networkm a
   view of interfaces, a view of BGP, etc, Acee: that does not exist today?
   Alia: two things - 1. it feels that there is a lot of concern on structure.
   Loa: we need what I call sun? ? Alia: getting perfect organizational
   structure will be infeasible. Contention between different models not being
   able to reference other models?
      Differentiate models per device class.
   Alia: 2nd point. This is important for operators. You may nit be happy about
   reviewing YANG, but please contribute. Dean: DT is heavy on vendors and
   extremely light on operators. Lou: is you are an operator and you acer about
   it , wou would like to hear about this.
      There are many constrains, this is not greenfield design.
      There are tradeoffs between havig somethign soon vs having it perfect.
      Major point - how we    satisfy both the LNEs and .... . We will continue
      documenting the LNE approach. Also we would like to get an answer that
      addresses
   ChrisB: operator wants to make a comment, we are out of time.
   Ruediger: looking at the many dioscussions that we had in this sesion I see
   some indications for part of the community is still learning the technology.
      For operators, they are more of the leading edge? than on the trailing?
      A bit more  of consideration that can be adapted as we are learning would
      be adequate than saying 'speak now and close your mouth forever later'.
   Lou: the approach of solving the problem without the beaytoiful stricture
   would be definitely good.

   JeffT: out of time, ending session.