Agreed. If the label allocated for 1/128 route is different from the 2/128 route, even if the routes share the same nexthop, then the label can potentially be used to distinguish whether we need v4 or v6 forwarding.
That means the label allocation in control-plane may need to consider the AFI also as part of the key, beside the nexthop, when doing per-nexthop label allocation. The platforms that don’t support peaking into the mpls-packet in forwarding-plane may need to implement such a label allocation scheme in control-plane. But another thing is: given no v4-interface-address exists towards the CE, whether pointing a label towards v4-forwarding is possible is another question. Forwarding-experts of the concerned platform may have a better idea. Hence the suggestion on asking the respective platform-owners to confirm the scenario is supported. They may use either same-label or different labels for v4,v6; whichever method works for the platform. Thanks Kaliraj From: Gyan Mishra <hayabusa...@gmail.com> Date: Tuesday, April 13, 2021 at 7:28 PM To: Kaliraj Vairavakkalai <kali...@juniper.net> Cc: Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com>, bess@ietf.org <bess@ietf.org>, draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org <draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org> Subject: Re: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03 [External Email. Be cautious of content] Thanks Kaliraj for clarification. Good point. I will add comments to section 3 and 4 related to this. If the control plane for IPv4 and IPv6 can remain separate for SAFI 128 or 129, the data plane would then know the payload as the data plane forwarding would follow the control plane AFI and would not need the deep packet inspection into the MPLS payload. Agreed? This will all be included in the testing to determine the optimal overall solution. Kind Regards Gyan On Tue, Apr 13, 2021 at 9:59 PM Kaliraj Vairavakkalai <kali...@juniper.net<mailto:kali...@juniper.net>> wrote: Thanks Gyan, Just a minor clarification: I am less concerned about control-plane, that may just work. My comment about platform-dependency was about whether the Pop-n-Forward forwarding will work for the MPLS label. E.g. if same label is used for both v4,v6 routes, then in forwarding plane, the box may need to peak into the mpls payload traffic, to determine whether it needs to send a v4 or v6 pkt towards the CE. Whether the platform supports such forwarding ability is the question. Thanks Kaliraj From: Gyan Mishra <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>> Date: Tuesday, April 13, 2021 at 6:33 PM To: Kaliraj Vairavakkalai <kali...@juniper.net<mailto:kali...@juniper.net>> Cc: Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org<mailto:draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org> <draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org<mailto:draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org>> Subject: Re: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03 [External Email. Be cautious of content] Hi Kaliraj Thank you for your comments. Responses in-line Many thanks Gyan On Tue, Apr 13, 2021 at 7:33 PM Kaliraj Vairavakkalai <kaliraj=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>> wrote: I support adoption of this draft. I have a couple of comments: In section 6, “Changes resulting from a single IPv6 transport peer carrying IPv4 NLRI and IPv6 NLRI below:” It may be worth noting that this model may have some change to feature that use Pop-n-Forward MPLS-label forwarding. There may be some platform specific nuances. Pop-n-Forward is used by features like EPE and L3VPN (per-nexthop label). EPE is an IPv4/v6-Unicast feature, so it may be in-scope even if we consider L3VPN currently out of scope. Gyan> From the edge perspective PE-CE edge peering is in scope for any softwire mesh framework where IPv4 edge is transported over an IPv6-Only core which could be an IP, MPLS, SR. So all the middle core flavors IP, MPLS, SR are in scope for the single IPv6 peer PE-CE edge. We also have to take into account L3 VPN per CE aggregate label as now that would be both IPv4 and IPv6 versus per prefix label. Today, v4 routes and v6 routes get a different EPE-label/VPN-label, because of different v4/v6 EBGP peering. Gyan> Agreed with the separate edge PE-CE IPv4 and IPv6 peers, IPv4 prefixes have VPN label PE-RR and are carried in AFI/SAFI 1/28 and IPv6 edge prefixes VPN label PE-RR are carried in AFI/SAFI 2/128. With single IPv6-transport, v4 and v6 routes may allocate the same MPLS-label, as it is the same v6-nexthop. So whether a platform supports such MPLS-in-IP[v4/v6] forwarding for both v4 and v6 traffic when using a single nexthop is a question.. Gyan> Agreed. With a single IPv6 edge PE-CE peer for both IPv4 and IPv6 NLRI , IPv4 and IPv6 edge prefixes may have the same VPN label PE-RR using AFI/SAFI 2/128 for both IPv4 and IPv6 prefixes. So the platform specific question is if both IPv4 and IPv6 NLRI AFI/SAFI 1/1 and 2/1 - can they both be carried by the same VPN label PE-RR peer AFI/SAFI 2/128. So the PE-RR VPN-IPv4 that was carrying IPv4 NLRI would not be needed as IPv4 NLRI would be carried by AFI/SAFI 2/128. So this will be in scope as part of the interoperability testing to ensure that by combining the IPv4 and IPv6 NLRI at the edge over IPv6 transport the caveat is that in a VPN overlay PE-RR VPN label VPN-IPv6 AFI/SAFI 2/128 will now have to carry both IPv4 and IPv6 NLRI. We would also QA test if it’s possible to keep the VPN label separate for v4 and v6 if possible, so even though the edge is a single IPv6 peer to have separate VPN label and peer PE-RR as before with IPv4 NLRI using VPN-IPv4 AFI/SAFI 1/128 and IPv6 NLRI using VPN-IPv6 AFI/SAFI 2/128. I will expand on this in the section 3. I wonder if the test-cases could be broken down into more granular pieces: V4 route with V6 nexthop (single-hop EBGP). V4 route with V6 nexthop (multi-hop EBGP). V4 route with V6 nexthop (multi-hop IBGP, tunneled) MPLS route with V6 nexthop (single-hop away) MPLS route with V6 nexthop (multi-hop away) Where the MPLS payload can be either v4 or v6. Gyan> Agreed. I will add all the permutations of scenarios to section 3. Different platforms of the same vendor may have different capabilities. So draft may need to record as part of test-results, which specific platforms were tested. Gyan> Agreed. We will record platform and code revisions tested. Thanks Kaliraj From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>> Date: Tuesday, April 13, 2021 at 2:37 AM To: draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org<mailto:draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org> <draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org<mailto:draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Subject: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03 [External Email. Be cautious of content] Hello, This email begins a two-weeks WG adoption poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03 [1]. Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this document, 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 an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document will not progress without answers from all of the authors and contributors. Currently, there are no IPR disclosures against this document. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on April 27th 2021. Regards, Matthew and Stephane [1] https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/__;!!NEt6yMaO-gk!RHh1RdZRCsfZX-7cqzDM-y25JSr4cNV_xgzlk2PNsQtpUO2Zm72Z_T66Yr6hkkZv$> Juniper Business Use Only _______________________________________________ BESS mailing list BESS@ietf.org<mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!TRrLASKRAwVabaAjaYw6GycMgvRCOcZqwEzLB_gdI291NWcjL4Q0mbwkgIZm1nQb$> -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!TRrLASKRAwVabaAjaYw6GycMgvRCOcZqwEzLB_gdI291NWcjL4Q0mbwkgPTYJFvQ$> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> M 301 502-1347 Juniper Business Use Only -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!TTV94R9E06kpmjVoI73JYVMmBTOp-iWcwhdDM_-JifrYJPOZW074fHPa5xzFZ_t_$> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> M 301 502-1347 Juniper Business Use Only
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
