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 <kali...@juniper.net> 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 <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> > 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> > *Date: *Tuesday, April 13, 2021 at 6:33 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]* > > > > 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> 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> on behalf of Bocci, Matthew (Nokia - > GB) <matthew.bo...@nokia.com> > *Date: *Tuesday, April 13, 2021 at 2:37 AM > *To: *draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org < > draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org>, > bess@ietf.org <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 > 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 gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > *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 gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > *M 301 502-1347* > > > > Juniper Business Use Only > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
