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 protected]] On Behalf Of Susan Hares
Sent: Tuesday, October 06, 2015 8:36 PM
To: [email protected]
Cc: 'Nitin Bahadur' <[email protected]>; [email protected]
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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
