Agenda: (75 minutes 10:00 - 11:15am)
1) A review of draft-zhdankin-idr-bgp-cfg-00 (Keyur Patel) [30 minutes]
WG Discussion:
2) Overview of Policy Yang drafts in IETF (Sue Hares) [10 minutes]
http://tools.ietf.org/html/draft-shaikh-rtgwg-policy-model-00
http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
http://datatracker.ietf.org/doc/draft-wang-netmod-yang-policy-dm/
http://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-info-model/
http://datatracker.ietf.org/doc/draft-hareskini-i2rs-pbr-info-model/
WG discussion:
3) Discussion comparing 2 BGP Yang modules [30 minutes]
draft-zhdankin-idr-bgp-cfg-00
https://github.com/YangModels/yang/tree/master/experimental/openconfig
Questions for the discussion:
3.1) Should we use base-BGP versus extension (Yang augmentation) approach?
If so, what is the minimal subset?
WG Discussion:
3.2) Does the container form provide values when:
a) pulling the status of a BGP neighbor or a group of neighbors
b) Status by AFI/SAFI
WG Discussion:
4) Summary and Next steps (5 minutes)
Recording is at:
https://ietf.webex.com/ietf/ldr.php?RCID=dad5cf872d4469f95ad00b0330f8e9d8
Notes:
10:04 Meeting begins
Keyur presenting on zhdankin
10:11 Major differences slide -- "I can do more flexible queries using a container"
No l3vpn
10:14 Sue notes Anees not present due to illness but he conveyed that they're working to coordinate drafts
10:16 Slides done. Soliciting WG feedback on containers vs. lists at various levels (address family, neighbor, etc)
Q/A
10:17
Jeff: Like use of groups for AFs. Please check published version vs. repo, though. You're missing a linkage.
Sue: Did you check the 1/26 version?
Jeff: Looked at IDR version -00. It's the most recent published.
Jeff: It's very comprehensive but cisco-heavy. Will work for those who have copy-pasted cisco UI. At least cisco-specific is factored out to different modules. What is consensus among non-cisco contributors?
Keyur: It's not cisco specific. Doesn't map to any cisco releases. Aimed at protocol needs. Happy to adjust to make it more generic as needed. Please raise specific points.
Jeff: Making certain constructs generic is very tricky. Again, the question is for other contributors.
Sue: I believe it's about 90% applicable to Huawei. Walked through other implementations, I was concerned about two -- Juniper due to underlying policy constructs, we'll cover policy next -- (second one not clear -- open source?) Second point, pushback from openconfig was to cut scope.
Keyur: Ericsson provided similar feedback -- good mapping to their backend. Feedback from ALU -- haven't gotten negative, will ask Adam Simpson again. But where we've missed on generalizing properly please bring it up and we'll move it to an implementation-specific draft or fix it.
Jeff: Wasn't exactly meant as a criticism, seeking information. Thanks.
Sue: I'll post my comparison notes or can post them on a wiki. Should I?
Jeff: Please do.
Sue: Containers help a lot.
Sue: Rapidly moving to convergence to single BGP Yang base model.
10:25
Anees: Still reviewing points of difference with other implementors. If there's no issue with other implementations we'll make some changes to OC model. Want to avoid making changes to accommodate one implementation while setting others back. Will take a few more weeks to close out those discussions.
Keyur: In general we want to strive for a simpler back end knowing that Yang supports enough complexity. Idea is back end to be simple and scalable to support queries at scale. Main thing we want is to agree on containerizing major structures.
Anees: Way we've approached this is not only back end but also what makes sense from the consumption end. There are some drawbacks to adding additional containers -- stuttering, paths used to set variables. If there's consensus around this structure I'm fine, but let's remember isn't not just the back end that matters, also the front end.
Jeff: Future extensions will impact whether containers are better or worse. As an exercise, make up a fake AFI or SAFI to exercise how you extend one model or the other. Might expose interesting characteristics.
10:29
Sue presenting on policy
10:32 Anees: we really want a generic framework for routing policy. BGP-specific parts live in BGP model. Operators generally prefer routing polcies in one place, not mixed with other protocols or policies.
Keyur: Us too. Initial focus in resolving BGP differences. Want to keep forwarding and routing policies separate. Devil in the details, e.g. what kind of regex to use, etc. Q.v. ASPath ORF experience. Nothing finalized.
10:34 continuing with "Suggestions" slide
Sue/Anees discussing where to do work.
Anees: Don't put everything called "policy" in one place. Forwarding policy is fundamentally different from routing policy.
Sue: I'm suggesting best place to put routing policy is rtgwg. Doesn't seem like it should be in BGP. If it's not generic, don't pull it into IDR.
Sue: I thought forwarding + routing might be beneficial, but we will discuss on mailing list.
Sue: Any q's on policy models?
Acee: I agree that packet and routing policy shouldn't be mixed.
Alia: Netmod ACL draft is in WGLC in Netmod. Please express opinions as appropriate.
Acee: Currently doesn't say it expresses routing policy, just says "it could".
Dean: That's on purpose.
Alia: My point is just that it needs review now.
Anees: We've structured model so BGP-specific part of framework is in IDR draft, augments RTGWG generic framework.
Sue: Great. That's what I intended to say.
Sue: EVPN needs some thought. Is it forwarding? Is it routing?
Jeff: Even if we're considering BGP-specific policy, they should be in different modules, so they can be revved independently. Second reason, some implementations let you use BGP-specific components in a non-BGP context, e.g. static route with a community.
10:42
Questions for the discussion:
3.1) Should we use base-BGP versus extension (Yang augmentation) approach?
If so, what is the minimal subset?
WG Discussion:
Jeff: We do want to have a minimal overlapping set.
Sue: OC has minimal set operators want supported.
Anees: Yeah, model is based on review of our own configs. In some places there were outliers (vendor- or operator-specific) and we agreed to handle those via augmentation.
Jeff: BGP MIB experience taught us that BGP is a large number of RFCs, not everyone implements them all, the core feature set however is more than just RFC 4271. It would be nice to see in both of the Yang modules more use of "if feature". Would allow more extension with compliance with core model.
Anees: We haven't explicitly done the work of wrapping things that way. Don't intend to have vendor specific.
Keyur: I list what RFCs both drafts support (in my slides). Reviewed both drafts, major vendor implementations. Wny not call that a "baseline"?
Jeff: There may be special-purpose BGP devices. For example suppose there's a device that doesn't support MVPNs. Draft-zhdankin would fail a config for a device that doesn't support them.
Keyur: There's no MVPN in the base drafts. Drafts support MP-BGP.
Jeff: Those base RFCs make sense in a particular service provider environment.
Keyur: For example, RR or Confederations. MVPNs is a good example of something that should be enabled as a "feature". But that will span multiple models, not just BGP.
Keyur: Most RFCs covered by most implementations, so why not?
Jeff: Q to chairs: are we going to standardize a model that has a large feature set required?
Sue: We need other communities with other requirements to speak up.
.John: Jeff is asking what is the base BGP functional set. We've avoided this by submitting lots of extension drafts.
I do not want to answer the question - yes/no without studying it. I do want to say that if someone put two different models,
and one had a restrict base and one had a large base, and the modules were equal. I want the smaller base and applicable.
The reason BGP has been around for so many years is that it fits in so many niches. We should try to keep the flexibility.
Keyur: Both of the drafts have the same base and same base support. We have make afi-safi containers.
I'm fully in-sync that the minimimum (BGP, RR-Clusters,
Jeff: Both of
Jeff: You can make the core modules more option-friendly by adding the keyword "feature".
Anees: In OC we have lots of different user profiles -- SP, Cloud, etc. Union of use cases.
Jeff: I agree with the common union is the right way. By using the If-Feature to allow all the smaller implementations to not allow.
John: The largest possible based provides a barrier to entry to small implementatoins.
Jeff: This If-Feature will allow the future features.
Sue: Is there a cost for the feature?
Jeff: IF-Features provides the protocol mechanism, and the ability for the query devices to know what hte
John: Is this the right time to send text.
Alexander: The main question - what are the block of things that should be marked as optional? One the features are clear, the
Jeff: There will be debate about the fine point. The course points are some address family support
Robert: What is the definition of a major implementation?
Jeff: Yang provides the ability to have a grand union.
Keyur: I've looked at Quagga and all support: community, RR, Confederation, and multi-protocol.
3.2) Does the container form provide values when:
a) pulling the status of a BGP neighbor or a group of neighbors
b) Status by AFI/SAFI
(no comments)