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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

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:[e-mail]] On Behalf Of Susan Hares
Sent: Tuesday, October 06, 2015 8:36 PM
To: [e-mail]
Cc: 'Nitin Bahadur' <[e-mail]>; [e-mail]
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/

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