Re: [trill] 答复: Re: Comments on draft-ietf-trill-cmt-00

[Donald Eastlake <[e-mail]>]

Hi Hongun,

On Thu, Oct 18, 2012 at 8:00 AM, <[e-mail]> wrote:
>
> Hi Donald,
>
> Thanks for your explanation.
>
> > Then you need RPFC entries at every other RBridge
> > for ingress RBv and those 6 tree. You don't need entries for RBv and 8
> > tree, which wastes RPFC state.
>
> I agree you on this point.
>
> > And if you only have entries for RBv and less than 6 trees, some TRILL
> > Data packets will be improperly discarded due to the RPFC.
>
> I think you are right. Now my question is whether or not there are 6
> acceptable RPFC entries for RBv at each RBridge port at a given other
> RBridge, each entry for RBv and each of those 6 trees. In my mind,
> no same acceptable RPFC entries for an ingress RBridge (neither a physical
> RBridge nor RBv) are permitted existing at different ports at one given
> RBridge.

Right.

If you view the information at a port as just a table of the allowed
combinations of ingress nickname and tree at that port, then there are
six entries for RBv and the trees. But these six entries could be one
each at six different ports or all at one port or anything in between
depending on the topology and tree structures. Most likely, if you
have many ports on a TRILL switch, most of them would have no RPFC
entries for RBv ingress in this case.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Best Regards,
> Zhai Hongjun
> """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
> No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
>
> Zhai Hongjun
>
> Tel: [phone]
> Email: [e-mail]
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
>
>
>
>
> Donald Eastlake <[e-mail]>
> 发件人:  [e-mail]
>
> 2012-10-18 11:41
>
> 收件人
> [e-mail]
> 抄送
> [e-mail]
> 主题
> Re: [trill] Comments on draft-ietf-trill-cmt-00
>
>
>
>
>
> Hi,
>
> On Sun, Oct 14, 2012 at 11:34 PM, <[e-mail]> wrote:
> >
> > Hi Donald，
> >
> > > - The draft should be clear that when doing the RPFC for a
> > > multi-destination TRILL Data packet ingressed with a virtual RBridge
> > > nickname, the RPFC must assume that the TRILL Data packet might use
> > > any of the trees that any of the RBk might use.
> >
> > Do you mean that RBn ignores the egress nickname in a received
> > multi-destinaion TRILL data packet with a virtual RBridge nickname
> > when it does RPFC for that packet in that case? Or if I am wrong,
> > please give a clearer explanation on that sentence by using an example.
>
> One way to look at the RPFC is that at each RBridge port there is a
> table of pairs of acceptable { ingress nickname, tree } where tree is
> the egress nickname in a multi-destination TRILL Data packet. Say RB1
> is not going to use all of the distribution trees being computed for a
> campus. Then RB1 can optionally list the tress it is going to use.
> This will reduce the amount of RPFC state at all the other RBridges in
> the campus because instead of having an entry for some port for
> ingress RB1 paired with every tree it only needs entries for ingress
> RB1 paired with the trees RB1 says it might use.
>
> Say a virtual RBridge RBv is in use as in the CMT draft. Then the edge
> group RBridges, when converting a frame off the link to a TRILL Data
> packet, will use RBv as the ingress nickname. Say you have 8 trees
> being calculated for a campus and three edge group RBridges each using
> two different trees. So the edge group RBridges all together only use
> 6 different trees. Then you need RPFC entries at every other RBridge
> for ingress RBv and those 6 tree. You don't need entries for RBv and 8
> tree, which wastes RPFC state. And if you only have entries for RBv
> and less than 6 trees, some TRILL Data packets will be improperly
> discarded due to the RPFC.
>
> Thanks,
> Donald
> =============================
> Donald E. Eastlake 3rd   [phone] (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> [e-mail]
>
> > Best Regards,
> > Zhai Hongjun
> > """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> > Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
> > No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
> >
> > Zhai Hongjun
> >
> > Tel: [phone]
> > Email: [e-mail]
> > """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> >
> >
> >
> >
> > Donald Eastlake <[e-mail]>
> > 发件人:  [e-mail]
> >
> > 2012-10-13 23:15
> >
> > 收件人
> > [e-mail]
> > 抄送
> > 主题
> > [trill] Comments on draft-ietf-trill-cmt-00
> >
> >
> >
> >
> >
> > There are my personal comments on draft-ietf-trill-cmt-00. I suggest
> > that after these and the few other comments have been handled, the -01
> > version be WG Last Called.
> >
> > - Some acronyms need to be spelled out on first use.
> >
> > - I think Figure 1 and Figure 2 are a bit muddled and should be
> > clarified to show separate connections from each RBk to each CEn. It
> > is also not clear to me why "DRB" occurs in the figures and I think it
> > should be dropped.
> >
> > - The draft should be clear that when doing the RPFC for a
> > multi-destination TRILL Data packet ingressed with a virtual RBridge
> > nickname, the RPFC must assume that the TRILL Data packet might use
> > any of the trees that any of the RBk might use.
> >
> > - The could be problems if a virtual RBridge nickname was taken away
> > by a real RBridge somewhere else in the campus that is higher priority
> > to hold a nickname. Perhaps the draft should suggest that virtual
> > RBridge nicknames are usually configured  and should be held with
> > maximum priority with with configured or unconfigured priority ranges,
> > as appropriate...
> >
> > - I think it should be possible to use the Affinity Sub-TLV to change
> > the structure of multi-destination distribution trees in places other
> > than at the edge. So they should be valid as long as they do not
> > conflict even if the requested child is a real RBridge. But, of
> > course, the requested child has to be an adjacent RBridge and the
> > draft should say what it would mean if some RBridge lists, as a
> > requested child for some tree, its parent in that tree.
> >
> > Thanks,
> > Donald
> > =============================
> > Donald E. Eastlake 3rd   [phone] (cell)
> > 155 Beaver Street, Milford, MA 01757 USA
> > [e-mail]
> > _______________________________________________
> > trill mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/trill
> >
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill
>