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

[Gyan Mishra <[e-mail]>]

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
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*