Re: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

[Gyan Mishra <[e-mail]>]

Thank you Kaliraj for your valuable feedback.

We will take it back to the team.

Kind Regards

Gyan

On Tue, Apr 13, 2021 at 11:06 PM Kaliraj Vairavakkalai <[e-mail]>
wrote:

> 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 <[e-mail]>
> *Date: *Tuesday, April 13, 2021 at 7:28 PM
> *To: *Kaliraj Vairavakkalai <[e-mail]>
> *Cc: *Bocci, Matthew (Nokia - GB) <[e-mail]>, [e-mail]
> <[e-mail]>,
> [e-mail] <
> [e-mail]>
> *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 <[e-mail]>
> 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 <[e-mail]>
> *Date: *Tuesday, April 13, 2021 at 6:33 PM
> *To: *Kaliraj Vairavakkalai <[e-mail]>
> *Cc: *Bocci, Matthew (Nokia - GB) <[e-mail]>, [e-mail]
> <[e-mail]>,
> [e-mail] <
> [e-mail]>
> *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=
> [e-mail]> 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 <[e-mail]> on behalf of Bocci, Matthew (Nokia -
> GB) <[e-mail]>
> *Date: *Tuesday, April 13, 2021 at 2:37 AM
> *To: *[e-mail] <
> [e-mail]>,
> [e-mail] <[e-mail]>
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!TRrLASKRAwVabaAjaYw6GycMgvRCOcZqwEzLB_gdI291NWcjL4Q0mbwkgIZm1nQb$>
>
> --
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!TRrLASKRAwVabaAjaYw6GycMgvRCOcZqwEzLB_gdI291NWcjL4Q0mbwkgPTYJFvQ$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
>
>
> Juniper Business Use Only
>
> --
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!TTV94R9E06kpmjVoI73JYVMmBTOp-iWcwhdDM_-JifrYJPOZW074fHPa5xzFZ_t_$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> Juniper Business Use Only
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*