Subject: [i2rs] information models for your review

From: "Susan Hares" <[email-masked]>
Date: Mon, 7 Jul 2014 19:28:45 -0400

My co-authors and I wish feedback on the I2RS informational models: 

1)      Draft-hares-i2rs-info-model-policy

Contains: Basic Network Policy IM 

                   Policy-Based Routing IM

                   I2RS Local configuration

http://datatracker.ietf.org/doc/draft-hares-i2rs-info-model-policy/

2)      Draft-hares-bgp-im-00 

BGP informational model

http://datatracker.ietf.org/doc/draft-hares-i2rs-bgp-im/

3)      Draft hares-i2rs-info-model-service-topo-01

SFC Topology IM,  TED IM 

http://datatracker.ietf.org/doc/draft-hares-i2rs-info-model-service-topo/

4)      Draft-hares-dunbar-i2rs-sfc-policy-im 

SFC Policies 

http://datatracker.ietf.org/doc/draft-hares-dunbar-i2rs-sfc-policy-im/

We look forward to your feedback on these models.

Sue Hares

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 16 Jul 2014 16:27:34 +0000

Susan,

Jeff Zhang and I've reviewed info model policy draft.

One general comment (and I'm repeating somebody else). Didn't we decide to use YANG for all modeling? I see you use RBNF, so it would be nice to have YANG models in the draft.

On Jul 7, 2014, at 7:28 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

In I2RS Local Config Information Model (I2RS-LC IM) there is a typo

and provides quick local access to polies

/polies/policies

In fig 5, both arrows go from action to condition. I couldn't figure out what is the meaning of use two arrows pointing to same direction.

What's the relationship between policy rule and policy? E.g., in the following:

  The elements of the Policy Rule information model are as follows:

  o  A policy can in turn be part of a hierarchy of policies, building
     on top of other policies.  Each policy is captured in its own
     level, distinguished via a policy-identity.

Is the "policy" a "policy rule" or "policy group"?

In the following:

  o  A condition contains a variable and a value and use a match
     operator, to connect variable with value.  An examples of an
     operator might be a" IP ADDRESS AS RESOLVED BYDNS" or "Set to a
     member".

The example is rather confusing for a match operator.

Page 12 typo

IP ADDRESS AS RESOLVED /BYDNS/BY DNS

What's the difference between priority and precedence?

       <Policy-Rule_priority> ::= INTEGER (0..250);
       <Policy-Rule_precedence> :;= INTEGER (0..250);

Policy constraints may be exchanged by routing protocols while updating routing information.
This can cause the routing protocols to constantly updated information, as the policy might be in direct conflict with routing protocol configuration on another device(s). Why do you want to do it? I'm in favor on policies applying only on the device where policies are explicitly applied.

Is section 3.5 complete?

For the following:

  o  PRB Default RIB - default forwarding FIB.

Is it talking about FIB or RIB? It's conflicting.

In figure 7 on page 18, there is no relation between condition and rule, as in fig 5. Shouldn't in all rules the relation between condition and action be the same? If condition met, follow by the action?

On page 22, why is the

Local Policy Information Model abbreviated with LB IM

it got me confused reading below, as I was expecting LP IM.

The PBR IM seems incoherent:

4.2.  PBR-RIB definition

  ...   Each PBR RIB has the following:

  o  PRB RIB NAME
  o  PBR Route-entry

  The Route entry in a PRB has the following information:

  o  match field - as in the RIB IM route

  o  order_list PBR route list with each entry having: a) next-hops, b)
     PBR route attributes, and c) vendor-attributes

  The PRB route attributes include QOS Attributes as show in the policy
  list below.

It talks about route entries in PBR RIBs, with the same match field as in the regular RIB IM, i.e. route prefixes. It then talks about each entry has ordered list of "PBR route" with next-hops and PRB route and vendor-attributes.

So I assume the PBR route attributes are related to policies. However, the rest of the text does not have a coherent connection with that. In fact, the above conflicts with section 4.6.

Additionally, is the QOS attributes mentioned above for matching or action? Is QoS specific to PBR?

Figure 7 shows QoS action only. It shows "PBR Condition" but that is not elaborated.

I can understand that a PBR rule extends a Policy Rule, but I don't understand how "QoS action" and "Forward Action" extend "PBR action". Those two seem to be part of the "PBR action"?

What does it mean by "Nexthop Type 'extends' Nexthop Variable"?

>From the following in section 4.4:

       <Policy-Rule_Match_Node_PBR-IM> ::= <IPv4_QoS_Node_Matches>
                      | <IPv6_QoS_Node_Matches>

It seems that PBR is all about QoS?

Why do we have the following three things that actually are the same?

          <IPv4_QoS_Node_matches> = <IPv4-QOS_Matches>
          <IPv4_QoS_Value_matches> = <IPv4-QOS_Matches>

What does the following mean?

       <Policy-Rule_Match_Operator_PBR-IM> ::= [<Longest-prefix>]
                  | [<Exact>]
                  | [(<IPv4-RANGE> <IPv4-Low> <IPv4-High>)]
                  | [(<IPv6-RANGE> <IPv6-Low> <IPv6-High>)]
                  | [(<LENGTH-Range> <LENGTH_Low> <LENGTH_High>)]

Jeff and Dean

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 16 Jul 2014 15:03:39 -0400

Dean,

> One general comment (and I'm repeating somebody else). Didn't we decide to use YANG for all modeling? I see you use RBNF, so it would be nice to have YANG models in the draft.

We adopted Yang as our data modeling language.  Ed and I will be having a
discussion with our AD at the upcoming IETF to see about getting our charter
formally updated to permit data models.

We are also likely to want at least some high level info models for our yang
modules.  That practice seems to be present elsewhere as well.

That said, info models are a perfectly reasonable way to start such a
discussion, especially for something that would require a lot of pre-req
material if we tried to code for Yang from day 1.  If we did, there would be
a lot of stubs saying "this ties us to the <foo> component, whose Yang
module has yet to be written".

Thanks also for submitting your comments.  

I would like to draw the WG's attention to a github repository I threw
together for my own end of comments.  In such large drafts, sometimes being
able to submit comments in-line along with editorial fixes can be
challenging.

https://github.com/jhaas-pfrc/i2rs/tree/jhaas/edits01

While I'm not totally signing up to maintain this repository for general
editing purposes yet, please feel free to clone it for your own comments.
The master branch tracks the current published XML files published by the
IETF.  The branch above is where I've suggested my edits.  The actual edits
can be seen in this part of the history:

https://github.com/jhaas-pfrc/i2rs/commit/3994b35b561b040c9381c5104ebf7a728ed326e2

I have edits for the BGP-IM in progress as well.

-- Jeff (Haas)

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 17 Jul 2014 15:22:15 -0400

Dean:

Thank you for the review. Just a brief note,  In the next version of the
document I will gladly provide yang modeling.  I will provide more responses
in a few hours. 

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Wednesday, July 16, 2014 12:28 PM
To: Susan Hares
Cc: <[email-masked]>; Edward Crabbe; Alia Atlas; Jeffrey (Zhaohui) Zhang;
Jeffrey Haas; [email-masked]
Subject: Re: [i2rs] information models for your review

Susan, 

One general comment (and I'm repeating somebody else). Didn't we decide to
use YANG for all modeling? I see you use RBNF, so it would be nice to have
YANG models in the draft.

On Jul 7, 2014, at 7:28 PM, Susan Hares <[email-masked]> wrote:

                   Policy-Based Routing IM

                   I2RS Local configuration

 <http://datatracker.ietf.org/doc/draft-hares-i2rs-info-model-policy/>
http://datatracker.ietf.org/doc/draft-hares-i2rs-info-model-policy/

 
/polies/policies
 
In fig 5, both arrows go from action to condition. I couldn't figure out
what is the meaning of use two arrows pointing to same direction. 
 
What's the relationship between policy rule and policy? E.g., in the
following:

In the following:

 
Page 12 typo

Policy constraints may be exchanged by routing protocols while updating
routing information.
This can cause the routing protocols to constantly updated information, as
the policy might be in direct conflict with routing protocol configuration
on another device(s). Why do you want to do it? I'm in favor on policies
applying only on the device where policies are explicitly applied.
 
Is section 3.5 complete?

For the following:

 
In figure 7 on page 18, there is no relation between condition and rule, as
in fig 5. Shouldn't in all rules the relation between condition and action
be the same? If condition met, follow by the action?
 
On page 22, why is the 

 

4.2.  PBR-RIB definition

  o  PRB RIB NAME
  o  PBR Route-entry

It talks about route entries in PBR RIBs, with the same match field as in
the regular RIB IM, i.e. route prefixes. It then talks about each entry has
ordered list of "PBR route" with next-hops and PRB route and
vendor-attributes.

So I assume the PBR route attributes are related to policies. However, the
rest of the text does not have a coherent connection with that. In fact, the
above conflicts with section 4.6.

Additionally, is the QOS attributes mentioned above for matching or action?
Is QoS specific to PBR?

Figure 7 shows QoS action only. It shows "PBR Condition" but that is not
elaborated.

I can understand that a PBR rule extends a Policy Rule, but I don't
understand how "QoS action" and "Forward Action" extend "PBR action". Those
two seem to be part of the "PBR action"?

 
Jeff and Dean