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).
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.
NB> I sent my interpretation in a separate email.
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².
NB> Will make it SHOULD in both places.
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.
NB> Fixed.
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.
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>
|
<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.
NB> Yeah. This is a bug introduced in version -06 of the draft. I¹ll remove
the first match condition.
<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?
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.
<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?
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>.
<nexthop-chain> ::= <nexthop-chain-member> ...
<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>
NB> I¹ll address this in a separate email.
-----------------------------
<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?
NB> There was no easy place to put the POP operation. One option would have
been to define <tunnel-decap>.
-----------------------------
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>))
NB> YesFixed.
Thanks
Nitin
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
