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:[email protected]]
Sent: Thursday, October 08, 2015 1:47 PM
To: Jeffrey (Zhaohui) Zhang <[email protected]>; [email protected]
Cc: [email protected]
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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
