Re: [bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03

Questions/comments for the symmetric  model:

  Each NVE advertises an RT-2 route with two Route Targets (one
   corresponding to its MAC-VRF and the other corresponding to its IP-
   VRF. Furthermore, the RT-2 is advertised with two BGP Extended
   Communities. The first BGP Extended Community identifies the tunnel
   type per section 4.5 of [TUNNEL-ENCAP] and the second BGP Extended
   Community includes the MAC address of the NVE (e.g., MACx for NVE1 or
   MACy for NVE2) as defined in section 6.1.

Is the first EC needed for MPLS encapsulation? For intra-subnet forwarding using MPLS, there is no need for such EC; inter-subnet should not be different in that regard?

   In this symmetric IRB scenario, inter-subnet traffic between NVEs
   will always use the IP-VRF VNID/MPLS label. For instance, traffic
   from TS2 to TS4 will be encapsulated by NVE1 using NVE2's IP-VRF
   VNID/MPLS label, as long as TS4's host IP is present in NVE1's IP-
   VRF.

Because IP-VRF VNID/MPLS label is always used and IP lookup is done after removing the Ethernet header, the Ethernet header is really not useful? while with vxlan the ether header is always present, do we really need to signal the egress NVE's system mac address and put it in the ether header (since the header is not used to identify the IP VRF anywaty)? If this is because of certain hardware property (i.e., with vxlan certain chips always look up dst mac first no matter what), then it should be made clear. If the egress NVE does require a valid system mac address of its own is required, it can signal that via the EC; otherwise it does not have to and the ingress NVE should be free to put anything in the ether header?

5.2 IRB forwarding on NVEs for Subnets behind Tenant Systems

Should this section be moved to the prefix-advertisement draft?

Jeffrey

> -----Original Message-----
> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Martin Vigoureux
> Sent: Monday, February 13, 2017 5:07 PM
> To: BESS <bess@ietf.org>
> Subject: [bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03
> 
> Hello Working Group,
> 
> This email starts a Working Group Last Call on
> draft-ietf-bess-evpn-inter-subnet-forwarding-03 [1] which is considered
> mature and ready for a final working group review.
> Note that this call is longer than usual because we are pushing two
> correlated documents together.
> 
> Please read this document if you haven't read the most recent
> version yet, and send your comments to the list, no later than
> *5th of March*.
> Note that this is *not only* a call for comments on the document; it is
> also a call for support (or not) to publish this document as a Proposed
> Standard RFC.
> 
> *Coincidentally*, we are also polling for knowledge of any IPR that
> applies to draft-ietf-bess-evpn-inter-subnet-forwarding, to ensure that
> IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979,
> 4879, 3669 and 5378 for more details).
> 
> *If* you are listed as a document author or contributor of
> draft-ietf-bess-evpn-inter-subnet-forwarding-03 please respond to this
> email and indicate whether or not you are aware of any relevant IPR.
> 
> Note that, as of today, no IPR has been disclosed against this document
> or its earlier versions.
> 
> We are also polling for knowledge of implementations of part or all of
> what this document specifies. This information is expected as per [2].
> Please inform the mailing list, or the chairs, or only one of the chairs.
> 
> Thank you,
> M&T
> 
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/
> [2]
> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
> 
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess