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

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

Nitin,

For the first issue, I think you're saying that <NEXTHOP_IDENTIFIER> is the "nexthop identifier". Now it's clear.


For the second issue, I did get <nexthop-chain-identifier> and <nexthop-chain-member-identifier> mixed up in the info model, but that's because the following from data model, which is confusing at least if not incorrect:
  grouping nexthop-chain-member {   <-- member here
    description
      "One nexthop content for a route.";
    leaf nexthop-chain-id{          <-- chain here
      type uint32;
      mandatory true;
    }



Still, what's the difference/relationship between the following?



- <NEXTHOP_CHAIN_ID> and nexthop-identifier for the chain nexthop? That's my original question.

- <NEXTHOP_CHAIN_MEMBER_ID> and nextop-identifier for the chain member?



For the third issue, precisely because we don't have tunnel decap for other tunnels, why having a label pop for MPLS :)



BTW, a nit:


   A modify-able object is one whose contents can be changed without
   having to change objects that depend on it and without affecting any
   data forwarding.



When you change the nexthop content, the data forwarding will definitely be affected - it's what you want. The "and without affecting any data forwarding" should be removed - what you want to emphasize is that you don't have to change the objects that depend on it (and the text does do that already).



Jeffrey

From: Nitin Bahadur [mailto:[e-mail]]
Sent: Thursday, October 08, 2015 1:47 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-07 - WG LC from (10/6 to 10/20/2015)



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 :)

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