Hi Xiaohu,
If a given BFR/NVE is in multiple sub-domain, then the info that is
carried
is necessary I think.
Best regards,
Sandy
Xuxiaohu <[email protected]> 写于 2015/10/13 15:45:57:
> Hi Linda,
>
> You could piggyback the VN info on the BIER info. However, it would
> result in unnecessary data redundancy since there may be multiple
> <sub-domain, BFR-id> pairs for a given BFR/NVE.
>
> Best regards,
> Xiaohu
>
> From: [email protected] [mailto:[email protected]]
> Sent: Tuesday, October 13, 2015 3:16 PM
> To: Xuxiaohu
> Cc: [email protected]; BIER; fangwei hu; [email protected]; Zheng Zhang
> Subject: Re: [Bier] New Version Notification for draft-wang-bier-
> vxlan-use-case-00.txt
>
> Hi Xiaohu,
>
> Thanks very much for your comments and clarification.
>
> As mentioned in bier-use-cases, there is no doubt that BIER can be
> used in NVO3 efficiently to steer BUM traffic. As the foundation of
> BIER in NVO3, then extends the BIER control plane to carry VXLAN-
> specific information to form the mapping between VXLAN network
> identifier and bitstring. This stands to reason.
>
> On the other hand, you mentioned a related draft and I read it, I
> find it is kind of differentiated from my draft. Your draft aims to
> extend IS-IS to support NVEs auto-discovery, after that, each NVE
> knows where the other NVEs are, then use ingress replication or
> other methods to forward the BUM traffic.
>
> So we still would like to say IGP/BGP extension for VXLAN-specific
> information together with BIER-specific information is an
> interesting method in NVO3 :)
>
> Thanks,
>
> Best Wishes,
> Linda Wang
>
>
>
>
>
>
> Hi Linda,
>
> To form the mapping between VXLAN network identifier and bitstring,
> you could actually use the following two kinds of mappings: 1) the
> mapping between VNIs and NVEs; 2) the mapping between NVEs and BRF-
> ids. For the latter, there have been corresponding drafts as
> mentioned in your draft. As for the former (i.e., VPN/VN membership
> auto-discovery), it belongs to the scope of NVO3 WG. As for how to
> extend ISIS/OSPF for VPN/VN membership auto-discovery, there was a
> related draft
(https://tools.ietf.org/html/draft-xu-nvo3-isis-cp-00#page-4
> ). Unfortunately, it seems that the NVo3 WG has no interest in
> defining ISIS/OSPF based distributed control plane protocols up till
now.
>
> Best regards,
> Xiaohu
>
> From: BIER [mailto:[email protected]] On Behalf Of
[email protected]
> Sent: Tuesday, October 13, 2015 10:18 AM
> To: [email protected]
> Cc: Cui Wang; Zheng Zhang; fangwei hu
> Subject: Re: [Bier] New Version Notification for draft-wang-bier-
> vxlan-use-case-00.txt
>
> Dear all,
>
> A new draft about how to use BIER in data centers as well as how to
> extend IGP/BGP protocol to discovery remote NVEs in data centers to
> form the mapping between VXLAN network identifier and bitstring has
> been submitted. Wish you can pay attention to this draft and
> continue the discussion as the te-arch draft :)
>
> Any comments are welcome:)
>
> Best Wishes,
> Linda Wang
>
>
> [email protected] 写于 2015/10/12 17:03:30:
>
> > [email protected]
> > 2015/10/12 17:03
> >
> > 收件人
> >
> > "fangwei hu" <[email protected]>, "Cui Wang"
> > <[email protected]>, "Fangwei Hu" <[email protected]>, "Zheng
> > Zhang" <[email protected]>,
> >
> > 抄送
> >
> > 主题
> >
> > New Version Notification for draft-wang-bier-vxlan-use-case-00.txt
> >
> >
> > A new version of I-D, draft-wang-bier-vxlan-use-case-00.txt
> > has been successfully submitted by Cui Wang and posted to the
> > IETF repository.
> >
> > Name: draft-wang-bier-vxlan-use-case
> > Revision: 00
> > Title: BIER Use Case in VxLAN
> > Document date: 2015-10-11
> > Group: Individual Submission
> > Pages: 16
> > URL: https://www.ietf.org/internet-drafts/draft-wang-
> > bier-vxlan-use-case-00.txt
> > Status: https://datatracker.ietf.org/doc/draft-wang-bier-
> > vxlan-use-case/
> > Htmlized: https://tools.ietf.org/html/draft-wang-bier-vxlan-
> use-case-00
> >
> >
> > Abstract:
> > Bit Index Explicit Replication (BIER) is an architecture that
> > provides optimal multicast forwarding through a "BIER domain"
without
> > requiring intermediate routers to maintain any multicast related
per-
> > flow state. BIER also does not require any explicit tree-building
> > protocol for its operation. A multicast data packet enters a BIER
> > domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
> > BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
> > The BFIR router adds a BIER header to the packet. The BIER header
> > contains a bit-string in which each bit represents exactly one BFER
> > to forward the packet to. The set of BFERs to which the multicast
> > packet needs to be forwarded is expressed by setting the bits that
> > correspond to those routers in the BIER header.
> >
> > This document tries to describe the drawbacks of how BUM services
are
> > deployed in current data centers, and proposes how to take full
> > advantage of BIER to implement BUM services in data centers.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> > _______________________________________________
> BIER mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bier
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
