i2rs-interim-oct-10-2015-minutes

NAME and CHAIN_

<nexthop> ::=3D =
<nexthop-protection>
<nexthop> ::=3D <NEXTHOP_PROTECTION> =
(<NEXTHOP_PREFERENCE> <nexthop>
        &nb=
sp;        =
     (<NEXTHOP_PREFERENCE> =
<nexthop>)...)
<nexthop> ::=3D <NEXTHOP_PROTECTION> =
(<NEXTHOP_PREFERENCE> <nexthop>
        &nb=
sp;           &nbs=
p; (<NEXTHOP_PREFERENCE> =
<nexthop>))
<nexthop> ::=3D <NEXTHOP_PROTECTION> =
((<NEXTHOP_PREFERENCE> =
<nexthop-base>
        &nb=
sp;         =
    (<NEXTHOP_PREFERENCE> =
<nexthop-base>))
<nexthop> ::=3D <NEXTHOP_PROTECTION> =
(<1> <interface-primary>
        &nb=
sp;           &nbs=
p; (<2> <interface-backup>))
Traffic =
can be load-balanced among multiple primary nexthops and =
a
single backup.  In such a case, the nexthop =
will look like:

   <nexthop> ::=3D =
<NEXTHOP_PROTECTION> (<1>
        &nb=
sp;        =
(<NEXTHOP_LOAD_BALANCE>
        &nb=
sp;         =
(<NEXTHOP_LB_WEIGHT> =
<nexthop-base>
        &nb=
sp;         =
(<NEXTHOP_LB_WEIGHT> <nexthop-base>) =
...))
        &nb=
sp;          <2> =
<nexthop-base>)
<nex=
thop> ::=3D <nexthop-protection>
<nex=
thop> ::=3D <NEXTHOP_PROTECTION> (<NEXTHOP_PREFERENCE> <n=
exthop>
 &=
nbsp;           &nbs=
p;        (<NEXTHOP_PREFERENCE> &l=
t;nexthop>)...)
<nex=
thop> ::=3D <NEXTHOP_PROTECTION> (<NEXTHOP_PREFERENCE> <n=
exthop>
 &=
nbsp;           &nbs=
p;        (<NEXTHOP_PREFERENCE> &l=
t;nexthop>))
<nex=
thop> ::=3D <NEXTHOP_PROTECTION> ((<NEXTHOP_PREFERENCE> <=
nexthop-base>
 &=
nbsp;           &nbs=
p;        (<NEXTHOP_PREFERENCE> &l=
t;nexthop-base>))
<nex=
thop> ::=3D <NEXTHOP_PROTECTION> (<1> <interface-primary&=
gt;
 &=
nbsp;           &nbs=
p;        (<2> <interface-backu=
p>))
Traffic=
 can be load-balanced among multiple primary nexthops and a
single =
backup.  In such a case, the nexthop will look like:=

&n=
bsp;
 &=
nbsp; <nexthop> ::=3D <NEXTHOP_PROTECTION> (<1>
 &=
nbsp;           &nbs=
p;   (<NEXTHOP_LOAD_BALANCE>
 &=
nbsp;           &nbs=
p;    (<NEXTHOP_LB_WEIGHT> <nexthop-base>
 &=
nbsp;           &nbs=
p;    (<NEXTHOP_LB_WEIGHT> <nexthop-base>) ...))=

 &=
nbsp;           &nbs=
p;     <2> <nexthop-base>)
<nex=
thop> ::=3D <nexthop-protection>
<nex=
thop> ::=3D <NEXTHOP_PROTECTION> (<NEXTHOP_PREFERENCE> <n=
exthop>
 &=
nbsp;           &nbs=
p;        (<NEXTHOP_PREFERENCE> &l=
t;nexthop>)...)
<nex=
thop> ::=3D <NEXTHOP_PROTECTION> (<NEXTHOP_PREFERENCE> <n=
exthop>
 &=
nbsp;           &nbs=
p;        (<NEXTHOP_PREFERENCE> &l=
t;nexthop>))
<nex=
thop> ::=3D <NEXTHOP_PROTECTION> ((<NEXTHOP_PREFERENCE> <=
nexthop-base>
 &=
nbsp;           &nbs=
p;        (<NEXTHOP_PREFERENCE> &l=
t;nexthop-base>))
<nex=
thop> ::=3D <NEXTHOP_PROTECTION> (<1> <interface-primary&=
gt;
 &=
nbsp;           &nbs=
p;        (<2> <interface-backu=
p>))
Traffic=
 can be load-balanced among multiple primary nexthops and a
single =
backup.  In such a case, the nexthop will look like:=

&n=
bsp;
 &=
nbsp; <nexthop> ::=3D <NEXTHOP_PROTECTION> (<1>
 &=
nbsp;           &nbs=
p;   (<NEXTHOP_LOAD_BALANCE>
 &=
nbsp;           &nbs=
p;    (<NEXTHOP_LB_WEIGHT> <nexthop-base>
 &=
nbsp;           &nbs=
p;    (<NEXTHOP_LB_WEIGHT> <nexthop-base>) ...))=

 &=
nbsp;           &nbs=
p;     <2> <nexthop-base>)
For the second issue, I did get <n=
exthop-chain-identifier> and <nexthop-chain-member-identifier> mixed up in the info model, but that’s because the following from da=
ta model, which is confusing at least if not incorrect:
  grouping nexthop-chain-member { &n=
bsp;
&=
szlig; member here
    description
      "One nexth=
op content for a route.";
    leaf nexthop-chain-id{ =
;        
&=
szlig; chain here
      type uint32;
      mandatory true;=

    }

Still, what’s the difference/relationship between=
 the following?

- <NEXTHOP_CHAIN_ID> and ne=
xthop-identifier for the chain nexthop? That’s my original question.<=
o:p>
- <NEXTHOP_CHAIN_MEMBER_ID>=
 and nextop-identifier for the chain member?

For the third issue, precisely because we don’t h=
ave tunnel decap for other tunnels, why having a label pop for MPLS =
J

BTW, a nit:

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

When you change the nexthop content, the data forwardin=
g 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 objec=
ts that depend on it (and the text does do that already).=

Jeffrey

From: Nitin Bahadur [mailto:nitin_bahadur@yah=
oo.com] 

Sent: Thursday, October 08, 2015 1:47 PM

To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; i2rs@ietf.or=
g

Cc: sriganesh.kini@ericsson.com

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

&n=
bsp;

When would you use "chain_nam=
e"? 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. Nex=
thop-identifier (as referenced in Section 4) is
 really something like a <NEXTHOP_IDENTIFIER> that identifies a parti=
cular <nexthop>. I have changed “nexthop-identifier” to &=
#8220;nexthop identifier” to remove confusion that it is a special te=
rm. <NEXTHOP_CHAIN_ID> is something that identifies a <=
;nexthop-chain>.

Zzh> Can you clarify “nexth=
op-identifier … is … like a <NEXTHOP_IDENTIFIER>”. =
<NEXTHOP_IDENTIFIER> is not defined in the spec. If  you say =
220;<NEXTHOP_IDENTIFIER>
 is nexthop identifier as referenced in section 4” then it’s cl=
ear J

&n=
bsp;

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 sen=
se. Section 2.4.3 has:<=
o:p>

&n=
bsp;

id=
entifier: This is an
identifier returned by the networ=
k device
      =
representing another nexthop or another nexthop chain.

&n=
bsp;

Section 4 has:

&n=
bsp;

routes that use a nex=
thop that is identified by a nexthop identifier should be
   unaffect=
ed when the contents of that nexthop changes.

&n=
bsp;

So I’m not clear w=
here to define/reference these terminals. I’m hoping the data-model d=
oes a good job at incorporating this :)

&n=
bsp;

Zzh> I don’t understand why=
 you say “<NEX=
THOP_CHAIN_ID> is something that identifies a <nexthop-ch=
ain>”.
<NEXTHOP_CHAIN_ID> is part of th=
e following, so why would it identify a chain (vs. a chain member) .=

<nexthop-chain> ::=3D <nexthop-chain-member> ...=

<nexthop-chain-identifier> ::=3D <NEXTHOP_CHAIN_NAM=
E> |
          =
            &nb=
sp;         <NEXTHOP_CHAIN_ID>=
;
<nexthop-chain-member> ::=3D <nexthop-chain-member-=
identifier> | =

&n=
bsp;

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 NEX=
THOP_CHAIN_MEMBER_ID (not defined or referenced)
 should be the ID for a chain-member.

&n=
bsp;

&n=
bsp;

------------------------

<mpls-header> ::=3D (<mpls-=
label-operation> ...)
<mpls-label-operation> ::=3D (=
<MPLS_PUSH> <MPLS_LABEL> [<S_BIT>]
      =
            &nb=
sp;         [<TOS_VALUE>] [&l=
t;TTL_VALUE>]) |
      =
            &nb=
sp;         (<MPLS_POP> [<=
TTL_ACTION>])

<mpls-header> is part of <=
;tunnel-encap> - so <MPLS_POP> does not make sense?

NB> There was no e=
asy place to put the POP operation. One option would have been to define &l=
t;tunnel-decap>.

Zzh> I think that option is bet=
ter.

&n=
bsp;

The macro issue IMO is do we need to support a tunne=
l-decap for all kinds of tunnels. If yes, then it makes sense to make chang=
es all over the draft to support this. If not, then it looks like a bi=
g hammer to me. I’m fine with whatever
 the WG wants.

Thanks

Nitin