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

[Nitin Bahadur <[e-mail]>]

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