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>.
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
representing another nexthop or another nexthop chain.
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) .
<nexthop-chain> ::= <nexthop-chain-member> ...
<nexthop-chain-identifier> ::= <NEXTHOP_CHAIN_NAME> |
<NEXTHOP_CHAIN_ID>
<nexthop-chain-member> ::= <nexthop-chain-member-identifier> |
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.
------------------------
<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>.
Zzh> I think that option is better.
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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
