Subject: [i2rs] draft-ietf-i2rs-rib-info-model-07 - WG LC from (10/6 to 10/20/2015)

From: "Susan Hares" <[email-masked]>
Date: Tue, 6 Oct 2015 20:36:08 -0400

This begins a 2 week WG LC on draft-ietf-i2rs-rib-info-model-07.txt.   You
can obtain the document by going to: 

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

The question you should consider: 

1)      Does this RIB info-model work will for read query and write query
for small number of routes (1-10 routes)?

2)      Does this RIB info-model work for a large number of routes 100,000
routes?  

3)      Is the next-hop methodology support everything you wish in the I2RS
RIB? 

4)      The default mode for I2RS transport is a secure encrypted transport.
Does this information model need to have any portion of the model available
over an insecure transport? 

Sue Hares

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 7 Oct 2015 15:43:11 +0000

Support,

Linda

From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, October 06, 2015 7:36 PM
To: [email-masked]
Cc: 'Nitin Bahadur'; [email-masked]
Subject: [i2rs] draft-ietf-i2rs-rib-info-model-07 - WG LC from (10/6 to 10/20/2015)

This begins a 2 week WG LC on draft-ietf-i2rs-rib-info-model-07.txt.   You can obtain the document by going to:
http://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/

1)      Does this RIB info-model work will for read query and write query for small number of routes (1-10 routes)?

2)      Does this RIB info-model work for a large number of routes 100,000 routes?

3)      Is the next-hop methodology support everything you wish in the I2RS RIB?

4)      The default mode for I2RS transport is a secure encrypted transport.  Does this information model need to have any portion of the model available over an insecure transport?

Sue Hares

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 7 Oct 2015 15:58:57 +0000

I have following questions/comments. I'll have a separate email on Sue's question 3).

   When writing an object to a RIB, the external entity SHOULD try to

   write all dependencies of the object prior to sending that object.

   The data-model MUST support requesting identifiers for nexthops and

   collecting the identifiers back in the response.

Apparently this is different from Sue's understanding (see other email thread "RE: [i2rs] RIB Info/Data model questions: nexthop-id", so this needs to be straightened out.

   The RIB data-model SHOULD support

   a way to optionally receive a nexthop identifier for a given nexthop.

Earlier it says "MUST" and now it's "SHOULD".

2.4.3.  Nexthop content

   At the lowest level, a nexthop can be one of:

   o  identifier: This is an identifier returned by the network device

      representing another nexthop or another nexthop chain.

"or another nexthop chain" should be removed. "another nexthop" covers everything.

   o  tunnel encap: This can be an encap representing an IP tunnel or

      MPLS tunnel or others as defined in this document.  An optional

      egress interface can be specified to indicate which interface to

      send the packet out on.  The egress interface is useful when the

      network device contains Ethernet interfaces and one needs to

      perform address resolution for the IP packet.

I don't think an egress interface should be part of the tunnel encap. The egress interface and optionally a nbr address should be in a separate chain member.

2.4.3's title is "nexthop content" but it focuses on nexthops at the "lowest level". 2.4.4 is about "special nexthops" and that should be folded into 2.4.3 (since special nexthops are at the "lowest level").

       <match> ::= <route-type> (<ipv4-route> | <ipv6-route> | <mpls-route> |

                           <mac-route> | <interface-route>)

       <match> ::= <IPV4> <ipv4-route> | <IPV6> <ipv6-route> |

             <MPLS> <MPLS_LABEL> | <IEEE_MAC> <MAC_ADDRESS> |

             <INTERFACE> <INTERFACE_IDENTIFIER>

We have two rules for <match> here. They are equivalent and one should be removed.

       <ip-route-type> ::= <SRC> | <DEST> | <DEST_SRC>

Is there a real need for <src> routes? What's the real difference between <src> and <dest> routes?

    <nexthop-base> ::= <nexthop-special> | <nexthop-chain>

    <nexthop-chain> ::= <nexthop-chain-member> ...

    <nexthop-chain-identifier> ::= <NEXTHOP_CHAIN_NAME> |

                                <NEXTHOP_CHAIN_ID>

When would you use "chain_name"? What's the difference/relationship between <NEXTHOP_CHAIN_ID> and nexthop-identifier?

    <nexthop-chain-member> ::= <nexthop-chain-member-identifier> |

                <EGRESS_INTERFACE> |

                <ipv4-address> | <ipv6-address> |

                (<EGRESS_INTERFACE> (<ipv4-address> | <ipv6-address>)) |

                (<EGRESS_INTERFACE> <IEEE_MAC_ADDRESS>) |

                (<tunnel-encap> [<EGRESS_INTERFACE>]) |

                <logical-tunnel> |

                <RIB_NAME>)

The above model makes it that even the very basic nexthops are defined through nexthop-chain - unnecessary twist and it leads to unnatural representation when it comes to the data model (e.g. the chain is a list and each list entry has a client-assigned ID as key).

As section 2.4.2 alluded to, all the above "nexthop-chain-member" are just basic nexthops shoulder to shoulder with "nexthop-special". Therefore, the following model would be more natural?

  <nexthop> ::= <nexthop-base> |

                <nexthop-chain> |      <-- new

                <nexthop-replicate> |

                <nexthop-lb> |

                <nexthop-protection>

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

                     <nexthop-identifier> |

                     <egress-interface> |

                     ...

                     <logical-tunnel> |

                     <RIB_NAME>

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

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

<mpls-header> ::= (<mpls-label-operation> ...)

<mpls-label-operation> ::= (<MPLS_PUSH> <MPLS_LABEL> [<S_BIT>]

                            [<TOS_VALUE>] [<TTL_VALUE>]) |

                            (<MPLS_POP> [<TTL_ACTION>])

<mpls-header> is part of <tunnel-encap> - so <MPLS_POP> does not make sense?

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

   A backup can also have another backup.  In such a case, the list will

   look like:

   <nexthop> ::= <NEXTHOP_PROTECTION> (<1> <nexthop>

                 <2> <nexthop> <3> <nexthop>)

Unless it meant "A PRIMAY can also have another backup", shouldn't the above be the following?

      <nexthop> :: = <NEXTHOP_PROTECTION> (<1> <nexthhop> <2> <NEXTHOP_PROTECTION>(<1> <nexthop> <2> <nexhop>))

Jeffrey

From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, October 06, 2015 8:36 PM
To: [email-masked]
Cc: 'Nitin Bahadur' <[email-masked]>; [email-masked]
Subject: [i2rs] draft-ietf-i2rs-rib-info-model-07 - WG LC from (10/6 to 10/20/2015)

Sue Hares

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 07 Oct 2015 17:08:04 -0700

Hi Jeffrey,

   Thanks for combing through this. I¹ve addressed the discrepancies. See
NB> below.

> I have following questions/comments. I¹ll have a separate email on Sue¹s
question 3).

Apparently this is different from Sue¹s understanding (see other email
thread ³RE: [i2rs] RIB Info/Data model questions: nexthop-id², so this needs
to be straightened out.

NB> I sent my interpretation in a separate email.

Earlier it says ³MUST² and now it¹s ³SHOULD².

NB> Will make it SHOULD in both places.

2.4.3.  Nexthop content

³or another nexthop chain² should be removed. ³another nexthop² covers
everything.
 
NB> Fixed.

I don¹t think an egress interface should be part of the tunnel encap. The
egress interface and optionally a nbr address should be in a separate chain
member.

NB> The egress interface is ³not² part of the tunnel encap definition.
Tunnel-encap is defined as:

<tunnel-encap> ::= (<IPV4> <ipv4-header>) |
                   (<IPV6> <ipv6-header>) |
                   (<MPLS> <mpls-header>) |
                   (<GRE> <gre-header>) |
                   (<VXLAN> <vxlan-header>) |
                   (<NVGRE> <nvgre-header>)

What the above paragraph is referring to is the below statement in the
grammar:
<nexthop-chain-member> :: Š
                                                   (<tunnel-encap>
[<EGRESS_INTERFACE>]) |

The goal here was to clearly specify what combination of options make sense.

2.4.3¹s title is ³nexthop content² but it focuses on nexthops at the ³lowest
level². 2.4.4 is about ³special nexthops² and that should be folded into
2.4.3 (since special nexthops are at the ³lowest level²).

NB> Even though special nexthops are at the lowest level, I feel it is
important to call out what the special nexthops are. I don¹t think it
changes the content or organization of the draft if it is in a separate
sub-section.

       <match> ::= <route-type> (<ipv4-route> | <ipv6-route> | <mpls-route>
|
 
We have two rules for <match> here. They are equivalent and one should be
removed.

NB> Yeah. This is a bug introduced in version -06 of the draft. I¹ll remove
the first match condition.

Is there a real need for <src> routes? What¹s the real difference between
<src> and <dest> routes?
 
NB> Source routes are useful for source-based routing. For example, route
all packets coming from 10.0.0.1/16 to somewhere. Dest routes are regular
routes based on where the packet is intended for. DEST_SRC routes are a
combination of the two.

 
When would you use "chain_name"? What's the difference/relationship between
<NEXTHOP_CHAIN_ID> and nexthop-identifier?
 
NB>  Removed CHAIN_NAME. CHAIN_NAME and CHAIN_ID were one and the same
thing. Nexthop-identifier (as referenced in Section 4) is really something
like a <NEXTHOP_IDENTIFIER> that identifies a particular <nexthop>. I have
changed ³nexthop-identifier² to ³nexthop identifier² to remove confusion
that it is a special term. <NEXTHOP_CHAIN_ID> is something that identifies a
<nexthop-chain>.

 
The above model makes it that even the very basic nexthops are defined
through nexthop-chain  unnecessary twist and it leads to unnatural
representation when it comes to the data model (e.g. the chain is a list and
each list entry has a client-assigned ID as key).
 
As section 2.4.2 alluded to, all the above ³nexthop-chain-member² are just
basic nexthops shoulder to shoulder with ³nexthop-special². Therefore, the
following model would be more natural?

                     Š
                     <logical-tunnel> |
                     <RIB_NAME>
 
  <nexthop-chain> ::= <nexthop>Š
 
NB> I¹ll address this in a separate email.

 
 
NB> There was no easy place to put the POP operation. One option would have
been to define <tunnel-decap>.

 
 
Unless it meant ³A PRIMAY can also have another backup², shouldn¹t the above
be the following?
 
      <nexthop> :: = <NEXTHOP_PROTECTION> (<1> <nexthhop> <2>
<NEXTHOP_PROTECTION>(<1> <nexthop> <2> <nexhop>))

NB> YesŠFixed.

Thanks
Nitin

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 8 Oct 2015 09:56:31 +0000

Hi Nitin,

Please see zzh> below.

NB> What the above paragraph is referring to is the below statement in the grammar:
<nexthop-chain-member> :: ...
                                                   (<tunnel-encap> [<EGRESS_INTERFACE>]) |

 Zzh> The same comment still applies. A chain is a list of chain-members; a chain-member could be an <egress-interface> [<address>]; so from the grammar pov, <egress-interface> should not be there. If you want to specify what combination of options make sense, how do you say <logical-tunnel><rib_name> (and many others) does not make sense?

                                <NEXTHOP_CHAIN_ID>

NB>  Removed CHAIN_NAME. CHAIN_NAME and CHAIN_ID were one and the same thing. Nexthop-identifier (as referenced in Section 4) is really something like a <NEXTHOP_IDENTIFIER> that identifies a particular <nexthop>. I have changed "nexthop-identifier" to "nexthop identifier" to remove confusion that it is a special term. <NEXTHOP_CHAIN_ID> is something that identifies a <nexthop-chain>.

Zzh> Can you clarify "nexthop-identifier ... is ... like a <NEXTHOP_IDENTIFIER>". <NEXTHOP_IDENTIFIER> is not defined in the spec. If  you say "<NEXTHOP_IDENTIFIER> is nexthop identifier as referenced in section 4" then it's clear :)
Zzh> I don't understand why you say "<NEXTHOP_CHAIN_ID> is something that identifies a <nexthop-chain>". <NEXTHOP_CHAIN_ID> is part of the following, so why would it identify a chain (vs. a chain member) .

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

NB> There was no easy place to put the POP operation. One option would have been to define <tunnel-decap>.

Zzh> I think that option is better.

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 08 Oct 2015 10:47:16 -0700

Zzh> Can you clarify ³nexthop-identifier Š is Š like a
<NEXTHOP_IDENTIFIER>². <NEXTHOP_IDENTIFIER> is not defined in the spec. If
you say ³<NEXTHOP_IDENTIFIER> is nexthop identifier as referenced in section
4² then it¹s clear J

I left the reference and definition of <NEXTHOP_IDENTIFIER> to the
data-model draft. There is nothing in the grammar that references it, so
defining it did not make sense. Section 2.4.3 has:

identifier: This is an identifier returned by the network device

Section 4 has:

routes that use a nexthop that is identified by a nexthop identifier should
be

   unaffected when the contents of that nexthop changes.

So I¹m not clear where to define/reference these terminals. I¹m hoping the
data-model does a good job at incorporating this :)

Zzh> I don¹t understand why you say ³<NEXTHOP_CHAIN_ID> is something that
identifies a <nexthop-chain>². <NEXTHOP_CHAIN_ID> is part of the following,
so why would it identify a chain (vs. a chain member) .

I¹m unclear what your concern is or how you would like it re-worded. The way
I see it, a NEXTHOP_CHAIN_ID  is the ID for a chain. And a
NEXTHOP_CHAIN_MEMBER_ID (not defined or referenced) should be the ID for a
chain-member.

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

The macro issue IMO is do we need to support a tunnel-decap for all kinds of
tunnels. If yes, then it makes sense to make changes all over the draft to
support this. If not, then it looks like a big hammer to me. I¹m fine with
whatever the WG wants.

Thanks
Nitin

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 8 Oct 2015 18:47:53 +0000

Nitin,

For the first issue, I think you're saying that <NEXTHOP_IDENTIFIER> is the "nexthop identifier". Now it's clear.

For the second issue, I did get <nexthop-chain-identifier> and <nexthop-chain-member-identifier> mixed up in the info model, but that's because the following from data model, which is confusing at least if not incorrect:
  grouping nexthop-chain-member {   <-- member here
    description
      "One nexthop content for a route.";
    leaf nexthop-chain-id{          <-- chain here
      type uint32;
      mandatory true;
    }

Still, what's the difference/relationship between the following?

- <NEXTHOP_CHAIN_ID> and nexthop-identifier for the chain nexthop? That's my original question.

- <NEXTHOP_CHAIN_MEMBER_ID> and nextop-identifier for the chain member?

For the third issue, precisely because we don't have tunnel decap for other tunnels, why having a label pop for MPLS :)

BTW, a nit:

   A modify-able object is one whose contents can be changed without
   having to change objects that depend on it and without affecting any
   data forwarding.

When you change the nexthop content, the data forwarding will definitely be affected - it's what you want. The "and without affecting any data forwarding" should be removed - what you want to emphasize is that you don't have to change the objects that depend on it (and the text does do that already).

Jeffrey

From: Nitin Bahadur [mailto:[email-masked]]
Sent: Thursday, October 08, 2015 1:47 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-07 - WG LC from (10/6 to 10/20/2015)

I left the reference and definition of <NEXTHOP_IDENTIFIER> to the data-model draft. There is nothing in the grammar that references it, so defining it did not make sense. Section 2.4.3 has:

Section 4 has:

routes that use a nexthop that is identified by a nexthop identifier should be

So I'm not clear where to define/reference these terminals. I'm hoping the data-model does a good job at incorporating this :)

I'm unclear what your concern is or how you would like it re-worded. The way I see it, a NEXTHOP_CHAIN_ID  is the ID for a chain. And a NEXTHOP_CHAIN_MEMBER_ID (not defined or referenced) should be the ID for a chain-member.

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

The macro issue IMO is do we need to support a tunnel-decap for all kinds of tunnels. If yes, then it makes sense to make changes all over the draft to support this. If not, then it looks like a big hammer to me. I'm fine with whatever the WG wants.

Thanks
Nitin

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 13 Oct 2015 14:35:25 -0700

NB> Removed.

 

Will add <tunnel-decap>

Thanks
Nitin