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