Subject: [i2rs] draft-ietf-i2rs-rib-info-model-02

From: "Susan Hares" <[email-masked]>
Date: Sun, 20 Apr 2014 17:31:09 -0400

Nitin, Ron, Kini, Jan: 

1)      Is Section 7 of your document normative or informative? 

2)      Your grammar seems wordy/inconsistent in the repetition of the next
hop below 

Your RIB grammar on page 17 states: 

<nexthop-list> ::= <special-nexthop> | 

                                ((nexthop-list-member>) | 

                                 (<nexthop-list-member> . | <nexthop-list>))

<nexthop-list-member> ::= (<nexthop-chain> | 

<nexthop-chain-identifier>)

[<nexthop-list-member-attributes>]

<nexthop-chain>::= (<nexthop> .) 

Questions: Why do you have nexthop-list-member listed twice?  Why list
<nexthop-list> twice? Is this readability or technical matter? 

Why not: 

<nexthop-list>::= ((<special-nexthop> | (nexthop-list-member) . ) . 

Why not: 

<nexthop-list-member> ::= (((<nexthop-chain-identifier> | (<nexthops> .
))[<nexthop-list-member-attributes]) ). 

Were you trying to name the chains? 

3)      Two variables seem orphaned: 

Multicast-source-ipv4-address ::= <IPv4_ADDRESS> <IPV4_PREFIX_LENGTH>

Multicast-source-ipv6-address ::= <IPv6_ADDRESS> <IPv6_PREFIX_LENGTH>

         Did I miss someplace where they attached to the normative section
6. 

           You indicated the PIM paths can be chains (section 7.3), but you
do not give the normative section. 

Sue Hares

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 20 Apr 2014 18:00:09 -0400

Nitin, Ron, Kini and Jan:

I forgot to ask question on the grammar: 

<special-nexthop> :: = <DISCARD> | <DISCARD_WITH_ERROR> | (<RECEIVE>
[COS_VALUE] [<rate-limiter>]) 

Rater limited is not defined.  Is there a reason why this would be in a
standard document without a definition?  Did I miss something on the list? 

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Sunday, April 20, 2014 5:31 PM
To: [email-masked]
Cc: 'Jeffrey Haas'; [email-masked]; Alia Atlas
Subject: [i2rs] draft-ietf-i2rs-rib-info-model-02

Nitin, Ron, Kini, Jan: 

Why not: 

Why not: 

Sue Hares

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 20 Apr 2014 18:12:39 -0400

Did you replace the nexthop-address and not remove this text? 

   <nexthop-address> ::= (<IPv4> <ipv4-address>) |

                         (<IPV6> <ipv6-address>) |

                         (<IEEE_MAC> <IEEE_MAC_ADDRESS>)

The paper only his this definition once?

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Sunday, April 20, 2014 6:00 PM
To: [email-masked]
Cc: 'Jeffrey Haas'; [email-masked]; 'Alia Atlas'
Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02

Sue 

Nitin, Ron, Kini, Jan: 

Why not: 

Why not: 

Sue Hares

---

From: Nitin Bahadur <[email-masked]>
Date: Sun, 20 Apr 2014 20:21:55 -0700

Hi Sue,

We should remove it from the base document. The intent was that anything
that goes to the control plane should be rate-limited to prevent a DOS
attack. We had talked internally that the specification of a rate-limiter
was out of scope of this document, but keeping this in the doc would ensure
that implementors assigned a (fixed value initially?) rate-limiter of some
sorts.

We can remove that from the grammar and just add/keep relevant text to make
the intentions more clear.

Thanks
nitin

From:  Susan Hares <[email-masked]>
Date:  Sunday, April 20, 2014 at 3:00 PM
To:  <[email-masked]>
Cc:  'Jeffrey Haas' <[email-masked]>, <[email-masked]>, 'Alia Atlas'
<[email-masked]>
Subject:  Re: [i2rs] draft-ietf-i2rs-rib-info-model-02

>                                  (<nexthop-list-member> Š | <nexthop-list>))
>  
> <nexthop-chain>::= (<nexthop> Š)
>  
> <nexthop-list>::= ((<special-nexthop> | (nexthop-list-member) Š ) Š
>  
> Why not: 
> <nexthop-list-member> ::= (((<nexthop-chain-identifier> | (<nexthops> Š
> ))[<nexthop-list-member-attributes]) )Š
>  
>          Did I miss someplace where they attached to the normative section 6.
>            You indicated the PIM paths can be chains (section 7.3), but you do
> not give the normative section.
>  
> Sue Hares 
>  
> _______________________________________________ i2rs mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/i2rs

---

From: Nitin Bahadur <[email-masked]>
Date: Mon, 28 Apr 2014 22:48:09 -0700

This will be removed in the next rev.

Thanks
NItin

From:  Susan Hares <[email-masked]>
Date:  Sunday, April 20, 2014 at 3:12 PM
To:  <[email-masked]>
Cc:  'Jeffrey Haas' <[email-masked]>, <[email-masked]>, 'Alia Atlas'
<[email-masked]>
Subject:  Re: [i2rs] draft-ietf-i2rs-rib-info-model-02

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 30 Apr 2014 12:00:52 -0700

Hi Sue,

From:  Susan Hares <[email-masked]>
Date:  Sunday, April 20, 2014 at 2:31 PM
To:  <[email-masked]>
Cc:  'Jeffrey Haas' <[email-masked]>, <[email-masked]>, Alia Atlas
<[email-masked]>
Subject:  [i2rs] draft-ietf-i2rs-rib-info-model-02

> 1)      Is Section 7 of your document normative or informative?

Section 7 is informative.

> <nexthop-list>::= ((<special-nexthop> | (nexthop-list-member) Š ) Š

Good question. It¹s a technical matter. The above (and below) format is
needed to satisfy certain types of nexthops. I will list each of them.

([<nexthop-list-member> ... ] <nexthop-list> )) ===> recursion.

What you get from this is a way to perform the following actions on a given
packet:

* RECEIVE (send to local host)    AND
* Replicate to interface-1 and interface-2   AND
* Load-balance among interface-3 and interface-4

> Were you trying to name the chains?

The <nexthop-chain> tag acts like an enclosing tag for a list of next hops.
It also indicates that the nexthops are related and should be treated as a
chain to be applied one after the other to the same packet. Nothing magic.
What it also allows (down the road) is to maintain an association of
nexthop-chain contents to a chain-ID. And when a network-device supports
nexthop-chain-IDs, the controller can replace the chain with just it¹s ID.
Maintaining just a list of nexthops makes it harder for a controller to
correlate whether 2 nexthops-list-members are effectively the same (without
a bunch of crazy comparisons and sorting).

Nexthop-chain tag also allows ease of understanding for Section 7.2.5.

> not give the normative section.

These are going to be removed.

Now that you have understood a lot of the IM model, looking forward to an
implementation of the same :-)

Thanks
Nitin

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Apr 2014 16:25:33 -0400

Nitin: 

Thanks for the detailed response. 

From: Nitin Bahadur [mailto:[email-masked]] 
Sent: Wednesday, April 30, 2014 3:01 PM
To: Susan Hares; [email-masked]
Cc: 'Jeffrey Haas'; [email-masked]; Alia Atlas
Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02

Hi Sue,

Nitin, Ron, Kini, Jan: 

 

Ok, then the RIB grammar stands alone. 

Why not: 

[Nitin on]

Good question. It's a technical matter. The above (and below) format is
needed to satisfy certain types of nexthops. I will list each of them.

[Nitin off] 

[Sue on] 

This functionality was evident from your earlier helpful email.  However,
your previous email stated you tagged this per next-hop.  Did I understand
each nexthop can have the following flags: 

1)      Special nexthops: discard, discard_with_error, receive

2)       Protection_preference (primary/back-up), load_balance_weight (ecmp)

If so, then I do not understand why the recursion in lists.  These are just
list of nexthops with flags. 

nexthop-list-member::=  (flags) (nexthop) 

Or 

<nexthop-list-member> ::= [(<SPECIAL_NEXT_HOP> | <PROTECTION_PREFERENCE> |
<LOADBALANCE>) ] 

                                               (<nexthop>)

Are you trying to apply the flag Meta data is applying to the next hop
chain?  

[Sue]

 

Why not: 

 

[Nitin on ] 

nexthop-chain-IDs, the controller can replace the chain with just it's ID.

[nitin off]

[Sue on] 

Ok - the assumption that a nexthop-chain-list identifier would be always
associated with start of chain was not clear.  Could you tell me where I
missed that piece of information (other than the grammar - which has it
optional). 

Why does the grammar not say: 

<nexthop-chain-list>::= <nexthop-chain-identifier>  (<nexthop>.) 
<nexthop-list-member>::=<nexthop-chain-list>
[<nexthop-list-member-attributes>]

<nexthop-list>:: == (<nexthop-chain-list> .) 

[Nitin]: Now that you have understood a lot of the IM model, looking forward
to an implementation of the same :-)

Thanks Nitin

[Sue]:   I found a lot of these issues when starting at the UML drawings and
then trying to retro-fit your UML. 

              It's all about assumptions - let's clear up the last and come
to agreement the RBNF.  

                Once we get an agreed-upon RBNF text, I will like to suggest
a UML equivalent. 

Thanks for your responses. 

Sue 

PS - I am working with developers. See my co-authors on the UML work.