Re: [Idr] [bess] Suggestion on v4-only/v6-only drafts

[Gyan Mishra <[e-mail]>]

Hi Huaimo

Thank you for the feedback I will fix and update accordingly in the next
revision.

Thank you

Gyan

On Tue, Nov 15, 2022 at 12:34 PM Huaimo Chen <[e-mail]>
wrote:

> Hi Gyan,
>
>     The draft is useful and should be moved forward.
>
>     I have the following comments:
>     1. On page 5, in the paragraph starting with "The 4PE router receiving
> ...", it seems better to rephrase the definition of Egress 4PE router.
>     2.  On page 10, there are two paragraphs starting with "In the 4PE
> design over ...", it seems better to merge or simplify them.
>     3.  On page 10 and page 11, there are following sentences:
> The "FUNCTION" part of the
>    SRv6 SID now carries the overlay 4PE BGP-LU IPv4 Labeled prefix ...
>   It seems better to change "FUNCTION" to "ARGS"
>
> Best Regards,
> Huaimo
> ------------------------------
> *From:* Idr <[e-mail]> on behalf of Linda Dunbar <
> [e-mail]>
> *Sent:* Monday, November 14, 2022 5:10 PM
> *To:* Gyan Mishra <[e-mail]>; Igor Malyushkin <
> [e-mail]>
> *Cc:* Robert Raszuk <[e-mail]>; idr@ietf. org <[e-mail]>
>
> *Subject:* Re: [Idr] [bess] Suggestion on v4-only/v6-only drafts
>
>
> Gyan,
>
>
>
> I think the draft is beneficial and deserves to be adopted by WG.
>
>
>
> Just have a few questions:
>
>
>
>    - Does the IPv6 ingress router’s IPv6 address visible to any nodes
>    within IPv4 islands?
>    - Page 5 says “the 4PE routers convey their IPv6 address as the BGP
>    Next Hop for the advertised IPv4 prefixes.  Does it mean routers within the
>    IPv4 domain see the IPv6 address as NextHop?  How do IPv4 routers forward
>    based on IPv6 addresses?
>    - When the IPv6 core is SRv6, how does the IPv6 ingress node determine
>    the Func and Arg for the packets entering the SRv6 domain?
>
>
>
> Linda
>
>
>
> *From: *Idr <[e-mail]> on behalf of Gyan Mishra <
> [e-mail]>
> *Date: *Sunday, November 13, 2022 at 8:09 PM
> *To: *Igor Malyushkin <[e-mail]>
> *Cc: *Robert Raszuk <[e-mail]>, "idr@ietf. org" <[e-mail]>
> *Subject: *Re: [Idr] [bess] Suggestion on v4-only/v6-only drafts
>
>
>
> Hi Igor
>
>
>
> This was a really productive discussion and thank you for all of your
> feedback and comments on the draft.
>
>
>
> Responses in-line
>
>
>
> On Sun, Nov 13, 2022 at 4:18 PM Igor Malyushkin <[e-mail]>
> wrote:
>
> Hi Gyan.
>
>
>
> > Thank you for the detailed explanation!
>
> You are welcome :)
>
> > So this is an optimization that can apply to 6PE and as now as we
> develop 4PE add this option where you have a single CE next hop label for
> the bottom of stack label but then you don’t have to label all the CE
> prefixes and can keep unlabeled.
>
>
>
>
>
> Precisely. We've done it for 6PE to achieve fast convergence among other
> things (also for IPv4 too but the core was IPv4 native).
>
>
>
>    Gyan> Excellent!  I see, so for native IPv4 core prefixes where you are
> doing global table native IPv4 to the CE edge also applying same concept
> instead of labeling all the CE IPv4 prefixes just label the CE next hop
> prefix so you have a 2 label label stack.
>
>
>
> Could this optimization be applied to all the 4PE inter-as option B and C
> where the PE address is labeled only instead of all the prefixes?
>
>
>
> Most Excellent!  Great optimization!
>
>
>
>
>
> Actually, my curiosity about EPE wasn't useless. You have asked me to show
> you where vendors implement 6PE over IPv6 unicast. Please, note your link:
>
> https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/bgp-egress-traffic-engineering.html#id-configuring-egress-peer-traffic-engineering-by-using-bgp-labeled-unicast-and-enabling
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.juniper.net%2Fdocumentation%2Fus%2Fen%2Fsoftware%2Fjunos%2Fbgp%2Ftopics%2Ftopic-map%2Fbgp-egress-traffic-engineering.html%23id-configuring-egress-peer-traffic-engineering-by-using-bgp-labeled-unicast-and-enabling&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cebf83eeab09a4f1924cc08dac68d2721%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638040606870609110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fIP1eSkzmuNacPJ21owVfHDDotV1KtCNtoLburH6VW4%3D&reserved=0>
>
>
> First, as you can see they advertise some ARP routes which are based on
> BGP peer address (egress-te knob, I consider it a very inflexible way to
> advertise next-hop based route, Nokia does the same, but we have that we
> have). So that is exactly what I supposed with LU routes for NH but not for
> prefixes themselves. Second, they advertise IPv6 reachability over IPv4
> sessions via the IPv6 unicast family (to preserve the original next-hop)
> and the ARP route over IPv6 labeled unicast family. So, this is an example
> of 6PE with IPv6 unicast I believe.
>
> *Last but not least advertising tons of IPv4 LU can create some problems
> with filtration/leaking between unicast RIB and the Tunnels Table (note
> they use rib inet.3 for all BGP LSP which is good).*
>
>
>
> Gyan> I just read it and I see the IPv6 unicast 6PE carried on BGP-LU EPE.
> Are you saying the ARP routes in inet.3 for BGP LU EPE /32 or /128 routes
> is the CE next hop connected interface host routes for MPLS forwarding.  I
> agree and this is identical to how Cisco does it same ARP routes for BGP-LU
> for inter-as options B and C and BGP-LU EPE using a host static route.  I
> think that is semantically the same as what you described as “CE address
> next hop” arbitrary labeling concept to create that service label 2nd level
> in the label stack - and then not have to LU advertise all the v4 or v6
> prefixes as labeled and just use 1/1 or 2/1 unicast SAFI.
>
>
>
> I agree and I have seen SAFI 4 and 1  in the same RIB with Cisco and other
> vendors making filtering and troubleshooting more complex where Juniper
> separates SAFI 1 and 4 into separate rib inet.0 and inet.3.
>
>
> > I think at a minimum we want the two-level label stack.
>
> Yes. But I want you to pay attention to the "Option C" case. Inside an
> operator domain (if we don't stitch BGP LSP to something else) there will
> be three labels and the bottom one will be absolutely pointless (ok, PE can
> advertise "3" for IPv4 LU routes here but anyway).
>
>
>
>    Gyan> For Option C you would AFIK you would have a 2 level label stack
> transport label BGP-LU and the service label which could be either label
> all IPv4 prefixes as described in the draft or just the PE inter-as link
> address and advertise all the prefixes unlabeled.  I think in that case is
> you as well labeled all the prefixes as well you would end up with a 3
> level label stack not desirable agreed.  So in the draft scenario or in
> your CE address only labeling scenario you end up with a 2 level label
> stack.
>
>
>
> > This can be alleviated of course with explicit null.
> Actually, I consider 0, 2, and 3 are harmful. Why don't we always use
> arbitrary labels nowadays? But it's my personal pain.
>
>
>
>     Gyan> With L2 or L3 VPN you have at a minimum minimum of 2 label label
> stack.  If you do global table native routing SAFI 1 MPLS then a single
> label label.  With FRR or  LFA/RLFA/TI-LFA you end up with additional
> labels 3+.  The depth of the label stack is not the issue - it’s moreso LU
> on every prefix scan be problematic.  I think arbitrary  labeling next hop
> CE address label makes sense and provides a great optimization.  Seems very
> similar along the lines of VPN per-VRF of per-CE label allocation modes
> optimization as compare to per prefix.
>
>
> >  Thoughts?
>
> I'm glad that the 4PE document will be more flexible than the 6PE.
>
>
>
>     Gyan> Thanks again for all the detailed comments and feedback.  Yes as
> you have pointed out I agree and will make 4PE more flexible.
>
>
>
> But I still think that at least I as an engineer have all the necessary
> documents for 4PE.
>
>
>
>    Gyan> Perfect!
>
>
>
> But if you want to build the new document around the "two labels" pivotal
> I'm not against it.
>
>
>
>    Gyan> I will update this draft in the next revision.
>
>
>
>    I will add the 4PE optimization- arbitrary style per CE next hop
> service label connected interface ARP route  and not labeling service
> prefixes advertised for intra-as and inter-as 4PE.  So we will have net-net
> change is the existing draft option plus  your option. I will make the two
> options a Should normative language flexibility.
>
>
> > Would you like to join the draft as co-author?
> Thank you for that opportunity, but I prefer to be a spectator :)
>
>
>
>
>
>
>
>    Gyan>  Many Thanks for all your feedback!
>
>
>
> вс, 13 нояб. 2022 г. в 22:38, Gyan Mishra <[e-mail]>:
>
>
>
> Hi Igor
>
>
>
> Thank you for the detailed explanation!
>
>
>
> So this is an optimization that can apply to 6PE and as now as we develop
> 4PE add this option where you have a single CE next hop label for the
> bottom of stack label but then you don’t have to label all the CE prefixes
> and can keep unlabeled.
>
>
>
> I like it and thank you for bringing up!
>
>
>
> I can update the draft with this option and we can make it part of the
> standard.
>
>
>
> We can relax the relax the BGP-LU 1/4 option and can state both two level
> label stack options and if there is any other permutations we can add to
> the draft as well.
>
>
>
> I think at a minimum we want the two level label stack.
>
>
>
> I don’t think we want a single level label stack as the issue mentioned
> with exposed IPv4 packet hitting a IPv6 P node and being dropped.  This can
> be alleviated of course with explicit null.  So I could add this as an
> option as well but with the requirement of explicit null.
>
>
>
> Thoughts?
>
>
>
> Would you like to join the draft as co-author?
>
>
>
> Many Thanks!
>
>
>
> Gyan
>
>
>
> On Sun, Nov 13, 2022 at 2:49 PM Igor Malyushkin <[e-mail]>
> wrote:
>
> Ok, please see my explanation below.
>
>
>
> вс, 13 нояб. 2022 г. в 21:12, Gyan Mishra <[e-mail]>:
>
>
>
> Hi Igor
>
>
>
> In your last response I did not see a comment on the section highlighted
> excerpt below where I mentioned the protocol mismatch where on the PHP node
> when the label is popped it other then the QOS EXP scheduling issue as well
> it exposes the native IPv4 packet that that cannot be forwarded as the core
> is IPv6 only.  The workaround is you could do explicit null pipe mode to
> retain the topmost label, however the implicit null PHP should indeed work
> as well on its own without having to use explicit null.
>
>
>
> That is the reason for labeling the IPv4 prefixes being tunneled.
>
>
>
> Please share your thoughts and comments on below and I am responding to
> your last email.
>
>
>
> Except below
>
>
>
> How would you have 2 labels in the label stack if you use SAFI 1 1/1 IPv4
> Unicast as that would be “native IPv4 packets” non labeled no MPLS shim.
>
> [IM] As I pointed out a couple of times we will use a BGP tunnel toward
> the NH address of an IPv4 unicast route. So there will be two labels: one
> for BGP LSP, and another for LDP/RSVP LSP.
>
> So as I said before and the reason for the standardization is that if you
> don’t label the IPv4 prefixes from the IPv4 island being tunneled over the
> IPv6 LSP then on the PHP node when the transport label is popped implicit
> null value 3, the native IPv4 packet is exposed and is forwarded from the
> egress P PHP node w/ PHB scheduling broken as EXP match cannot occur
> without the IPv4 prefixes being labeled IPv4 LU.  That is a requirement for
> 4PE to work w/o breaking QOS EXP scheduling and is the procedure that must
> be followed for any 4PE implementations.
>
> [IM] Again, we will preserve two labels. In your case, you allocate a
> label for the IPv4 label unicast packet with the customer's prefixes. I
> suggest allocating a label for the IPv4 label uncast with the customer's
> next hop. In your case recursion is two-level, in my is three-level. If the
> P node pops the transport label there still will be the label of the
> labeled unicast packet in both schemes. But my scheme has several benefits
> and doesn't require to advertise tons of the customer's prefixes via
> labeled unicast. I can highlight some more issues with this, but most of
> them are vendor-dependent so I'm not sure that they are applicable to this
> discussion. And again, both methods can be deployed depending on the
> requirements. Also, there are other possible options, and they can probably
> have their own benefits. The problem is in the wording that requires
> advertising all with SAFI 4 family, I don't have problems with the
> requirement of two labels.
>
>
>
> So It’s not just breaking QOS EXP scheduling as once the PHP POP  happens
> on the PHP node for 6PE the native IPv6 packet is exposed and that cannot
> be forwarded as the core is a per standard design following RFC 5545
> Softwire mesh framework a single protocol IPv4 only core so the IPv6 packet
> is dropped and cannot be forwarded.
>
>
>
> As well for 4PE It’s not just breaking QOS EXP scheduling as once the PHP
> POP  happens on the PHP node the show stopper deal breakers is that  the
> native IPv4 packet is exposed and that cannot be forwarded as the core is a
> per standard design following RFC 5545 Softwire mesh framework a single
> protocol IPv6 only core so the then the IPV4 packet is dropped and cannot
> be forwarded.
>
> [IM] These statements are based on the assumption that we can't have two
> labels in the stack. As I described above we can.
>
>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Sun, Nov 13, 2022 at 3:29 AM Gyan Mishra <[e-mail]> wrote:
>
>
>
> Hi Igor
>
>
>
> Please see in-line Gyan2>
>
>
>
> On Sat, Nov 12, 2022 at 7:44 PM Igor Malyushkin <[e-mail]>
> wrote:
>
> Hi Gyan, please see the inline.
>
>
>
> вс, 13 нояб. 2022 г. в 01:39, Gyan Mishra <[e-mail]>:
>
> Hi Igor
>
>
>
> Thank you for your comments
>
>
>
> Understood that 4PE has been implemented by most vendors, however a
> standards specification has not been written till now and standardization
> of this draft would ensure interoperability as many operators have mix
> vendor environments.
>
>
>
> Responses in-line
>
>
>
> Thanks
>
>
>
> On Sat, Nov 12, 2022 at 5:31 PM Igor Malyushkin <[e-mail]>
> wrote:
>
> Hi gents,
>
> I found this conversation curious and started reading the document
> (draft-mishra-idr-v4-islands-v6-core-4pe-02). First, I skipped the section
> about SRv6 because I'm not good at this technology. Maybe the deal is this
> section because I couldn't find anything new in the rest of the document to
> put it into the Standard Track category. It more looks like a list of best
> practices to fire up 4PE in the network.
>
>
>
>    Gyan> The reason for standardization is to ensure that the process and
> procedures implemented by each vendor is the same to ensure
> interoperability
>
>  [IM] Could you please describe the process and the procedures? It's not
> clear to me.
>
>
>
> Gyan2> 4PE procedure is described in detail in section 3 and 4.
>
>
>
> Spreading the reachability over BGP with a different next-hop family is
> well written in 8950.
>
>
>
> Gyan2>  Here we are not just spreading the reachability over different
> next hops per RFC 8950.
>
> There is more to 4PE then just the transport tunnel.
>
>
>
> Signaling and pointing tunnels toward the next hops aren't new too.
>
>
>
> Gyan2> There is nothing special about the  IPv6 transport LSP towards the
> egress next hops as that’s is typical to carry and service.  What is
> critical is the 2 level label stack.
>
>
>
> Other things look like the best practices that don't alter any protocol or
> technology. Can you highlight what exactly requires standardization?
>
>
>
> Gyan2> What we are standardizing with the 4PE procedure is a two level
> label stack that you have the  topmost transport IPv6 LSP signaling the
> egress next hop to carry the service label IPv4 LU prefixes so all the IPv4
> prefixes must have a label binding.
>
>
>
> E.g., in the Security section, you state "The extensions defined in this
> document...", which extensions?
>
>
>
>    Gyan2> Sorry that was in error, I will fix in the next revision.  This
> specification uses existing mechanisms with a new procedure for 4PE.
>
>
>
> Of course, 4PE is already a well-known design pattern that has been
> implemented in lots of network OS and moreover implemented in production
> networks.
>
>
>
> Gyan> 4PE is well known however it has not been standardized so this would
> make it standard across all vendor implementations
>
> [IM] It depends on the goal of this "standard". 4PE just as 6PE is the
> design-matter thing, we can implement 6PE in several ways with the standard
> building blocks (8950 and other things).
>
>
>
>     Gyan2> The goal of the standard is to have a set procedure for 4PE
> that would be standardized. I disagree that 6PE RFC 4798 is a
> “design-matter” thing as it is standards track document and if it were a
> “design-matter” thing there would have been no need for RFC 4798.  I don’t
> know of any vendor that implements 6PE in several ways.  There has only
> been one method to implement 6PE and that is following RFC 4798 which all
> implementations use SAFI 4 IPv6 labeled unicast 2/4.
>
>
>
> Cisco
>
>
> https://community.cisco.com/t5/service-providers-knowledge-base/6pe-with-ibgp-ios-xr-example/ta-p/3149743
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.cisco.com%2Ft5%2Fservice-providers-knowledge-base%2F6pe-with-ibgp-ios-xr-example%2Fta-p%2F3149743&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cebf83eeab09a4f1924cc08dac68d2721%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638040606870609110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nuRB%2Fr8%2B%2F7XM4t4eJbjgPULIeowh93Kvo2RRmz30IFc%3D&reserved=0>
>
>
>
> Juniper
>
>
> https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/topic-map/ipv6-o-ipv4-tunnels.html
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.juniper.net%2Fdocumentation%2Fus%2Fen%2Fsoftware%2Fjunos%2Fmpls%2Ftopics%2Ftopic-map%2Fipv6-o-ipv4-tunnels.html&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cebf83eeab09a4f1924cc08dac68d2721%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638040606870609110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3Nyzv2dLlaQTAZ4%2BCGuupZGmiwxv5YFUpJk8sLeQ3gk%3D&reserved=0>
>
>
>
> Nokia
>
>
> https://infocenter.nokia.com/public/7750SR225R1A/index.jsp?topic=%2Fcom.nokia.Router_Configuration_Guide%2Fipv6_provider_e-d10e2482.html
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Finfocenter.nokia.com%2Fpublic%2F7750SR225R1A%2Findex.jsp%3Ftopic%3D%252Fcom.nokia.Router_Configuration_Guide%252Fipv6_provider_e-d10e2482.html&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cebf83eeab09a4f1924cc08dac68d2721%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638040606870609110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=k789eLkbnvxt%2F%2BTQhMlELlxU%2BqcD7vVr0%2BVx8sIqugQ%3D&reserved=0>
>
>
>
> Arista
>
>
> https://www.arista.com/en/um-eos/eos-border-gateway-protocol-bgp?searchword=eos%20section%2035%204%20is%20is%20commands
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.arista.com%2Fen%2Fum-eos%2Feos-border-gateway-protocol-bgp%3Fsearchword%3Deos%2520section%252035%25204%2520is%2520is%2520commands&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cebf83eeab09a4f1924cc08dac68d2721%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638040606870609110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OZKRH5QzB4csMZd8iS%2Fi%2BnsEXkAeUR9qoqGvc%2B31Xcw%3D&reserved=0>
>
>
>
> Please sent me a link of proof of a single vendor that has implemented 6PE
> using IPv6 unicast?
>
>
>
> Personally, I'm not against having a BCP document that combines everything
> about 4PE together if the authors want to perpetuate the abbreviation.
>
>
>
> Gyan> I think the process and procedures can be standardized with the
> normative language as written to ensure vendor interoperability.  Existing
> mechanisms are used however the draft defines procedures to be followed and
> that is what would be standardized.
>
> [IM] Again, I believe we should clarify the point where interop issues can
> arise and then solve them for the document that describes the mechanism
> that is the root of the problem.
>
>
>
>     Gyan2> You have hit right on the interoperability issue where you have
> brought up that it’s a design matter to use SAFI 4 IPv4 LU and have the
> choice to use SAFI 1 IPv4 Unicast.  So that is the crux of 4PE that the
> IPv4 prefixes must be labeled.  That’s a main reason for standardization
> that the IPV4 LU must be used.
>
>
>
> The second thing is about wording/writing. I don't want to seem rude or
> something but it was challenging for me to read the document. I believe it
> should be rewritten in a clearer way.
>
>
>
> Gyan> No worries, I can work with the authors to clean up the writing and
> thank you for the feedback.
>
> [IM] Thanks!
>
>
>
> Talking about the 4PE and after reading this document I disagree with the
> idea to use LU as the only way to spread reachability (actually I prefer
> almost not to use it for this task it better suits LSP signaling).
>
>
>
> Gyan>  The reason for the  BGP LU label binding of all the IPV4 prefixes
> tunneled over the core is for the PHP node exposing the native IPv4 packet
> which would not have the EXP marking PHB scheduling.
>
> [IM] This is possible without the distribution of IPv4 routes with labels.
> I can distribute just a single route toward their next hop which is the
> best thing BGP-LU does. The label stack would have two labels.
>
>
>
> Gyan2> I am not following.  BGP LU allocates and advertises all the
> prefixes with labels.  When you distribute a single route as SAFI 1 it does
> not have a label but if you distribute a SAFI 4 route it does have a label
> and is LU.
>
>
>
> This is exactly what is done in 6PE as it as well uses BGP-LU for the same
> reason labeling all the IPv6 prefixes tunneled.  This is a good example and
> reason for standardization.
>
> [IM] 6PE can be done without labeled unicast at all if talk about the
> interconnection of IPv6 islands over IPv4 core. That's why I said -- this
> is a design matter.
>
>
>
> Gyan2> I don’t see how that’s possible without breaking QOS EXP PHB
> scheduling on the PHP egress PE.  You argument is the reason for
> standardization.  If we go down the path you are describing that this is a
> “design thing” and implement however you like we would have all sorts of
> interoperability issues.
>
>
>
> If one vendor labeled the tunneled prefixes and another vendor
> implementation did not we would run into issues.
>
> [IM] And this is a good thing (I mean having several ways to make things
> done). You should require your vendor to support both options or don't buy
> gear from a vendor who can't do it.
>
>
>
> Gyan2> As I said your argument for keeping things open and a “design
> thing” is a reason for standardization as was done with 6PE and you can see
> all vendors have implemented exactly that using IPv6 LU and not IPv6
> Unicast to connect IPv6 islands over an IPv4 core.
>
>
>
> We have not had at least in North America and Europe many networks that
> have migrated to IPv6 core so have not seen interoperability issues however
> as more operators now start to migrate to an IPV6 data plane ..MPLS,
> SR-MPLS, SRV6 we could have issues so I think it’s important to get this
> standardized.
>
>  [IM] Yes we ran over lots of such issues too but all of them were pieces
> of some concrete technology.
>
>
>
> This approach governs me to always bind any reachability to a PE but not
> to a CE.
>
>
>
> Gyan> Yes for an important reason for the PHP node POP and forwarding
> native IPv4 packet and breaking EXP scheduling on the last hop to the
> egress PE
>
>  [IM] As I pointed out previously there is no difference if we don't
> distribute reachability without labels and if we use BGP tunnels to NH over
> underlay tunnels (RSVP, LDP, whatever).
>
>
>
> How can I implement EPE this way?
>
>
>
> Gyan> You can still implement EPE with BGP-LU SR EPE or EPE w/o SR
>
> [IM] Could you please describe the case without SR?
>
>
>
>    Gyan2> With EPE the ingress PE signals the egress next hop and which
> hop to be used via centralized controller PCE / BGP-LS and can be done
> using RSVP-TE or SR for EPE
>
>
>
> Juniper example
>
>
>
>
> https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/bgp-egress-traffic-engineering.html
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.juniper.net%2Fdocumentation%2Fus%2Fen%2Fsoftware%2Fjunos%2Fbgp%2Ftopics%2Ftopic-map%2Fbgp-egress-traffic-engineering.html&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cebf83eeab09a4f1924cc08dac68d2721%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638040606870609110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0NbmMMidlpsoRXuAL42KQBFuHTxTDvxRvzO14CU9Yys%3D&reserved=0>
>
>
>
>
>
> What if I want to advertise IPv4 prefixes with vanilla IPv4 (1/1) with
> IPv4-encoded NH (let's say with the CE address) and propagate this NH as
> IPv4 LU with the IPv6 NH?
>
>
>
> Sure that would work fine.  That is exactly what is stated in the draft as
> the process for 4PE.
>
>  [IM] Your document requires me to use BGP-LU for IPv4 reachability
> dissemination, I don't see why I need to resolve an IPv4 LU route over
> another IPv4 LU.
>
>
>
>    Gyan> I think you are getting 6PE and 4PE mixed up.  With 6PE you have
> a IPv4 transport LSP tunnel IPv4 next hop and IPv6 prefixes distributed as
> labeled within the tunnel.  With 4PE you have a IPv6 transport LSP tunnel
> IPv6 next hop and IP4 prefixes distributed as labeled within the tunnel.
>
>
>
> I see a lot of "MUST" preventing me from doing so.
>
>
>
>    Where ? Please quote the line or paragraph
>
> [IM] Let's dig into the third section.
>
> 1. *Exchange IPv4 reachability information* among 4PE Ingress and Egress
> PE routers using MP- BGP [RFC2545
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-mishra-idr-v4-islands-v6-core-4pe-02.html%23RFC2545&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cebf83eeab09a4f1924cc08dac68d2721%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638040606870609110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HCysns90ywZ4toXoFuCsx6zhDh54sGJ3Ku%2FLwPG2Q%2F4%3D&reserved=0>
> ]:
>
> In doing so, the 4PE routers convey *their IPv6 address* as the BGP Next
> Hop for the advertised IPv4 prefixes.
>
> [IM] What if I don't have any IPv6 addresses on PE-CE interfaces and I
> don't want to use the loopback IPv6 address?
>
>
>
>     Gyan2> The PE-CE interface in this 4PE use case is IPv4 islands over
> an IPv6 core so the Island CEs are IPv4 attached PE-CE.  So here we are
> conveying the IPv6 address which is the ingress and egress PE loopback to
> build the transport IPv6 LSP to advertise the IPv4 LU prefixes being
> tunneled.
>
> The Subsequence Address Family Identifier (SAFI) used in MP-BGP *MUST be
> the "label" SAFI (value 4)* as defined in [RFC8277
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-mishra-idr-v4-islands-v6-core-4pe-02.html%23RFC8277&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cebf83eeab09a4f1924cc08dac68d2721%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638040606870609110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2mcheo8zcZ6paxn%2FqBukoxI54GtyVYAItpgulhV4%2B%2Fc%3D&reserved=0>] called
> BGP Labeled Unicast (BGP-LU).
>
> [IM] Why can't it be SAFI 1? Why MUST I always use SAFI 4? I don't want.
> (Again, I still can have two labels in the stack).
>
>
>
>    Gyan2> How would you have 2 labels in the label stack if you use SAFI 1
> 1/1 IPv4 Unicast as that would be “native IPv4 packets” non labeled no MPLS
> shim. So as I said before and the reason for the standardization is that if
> you don’t label the IPv4 prefixes from the IPv4 island being tunneled over
> the IPv6 LSP then on the PHP node when the transport label is popped
> implicit null value 3, the native IPv4 packet is exposed and is forwarded
> from the egress P PHP node w/ PHB scheduling broken as EXP match cannot
> occur without the IPv4 prefixes being labeled IPv4 LU.  That is a
> requirement for 4PE to work w/o breaking QOS EXP scheduling and is the
> procedure that must be followed for any 4PE implementations.
>
>
>
> So It’s not just breaking QOS EXP scheduling as once the PHP POP  happens
> on the PHP node for 6PE the native IPv6 packet is exposed and that cannot
> be forwarded as the core is a per standard design following RFC 5545
> Softwire mesh framework a single protocol IPv4 only core so the IPv6 packet
> is dropped and cannot be forwarded.
>
>
>
> As well for 4PE It’s not just breaking QOS EXP scheduling as once the PHP
> POP  happens on the PHP node the show stopper deal breakers is that  the
> native IPv4 packet is exposed and that cannot be forwarded as the core is a
> per standard design following RFC 5545 Softwire mesh framework a single
> protocol IPv6 only core so the then the IPV4 packet is dropped and cannot
> be forwarded.
>
>
>
> As well is discussed in the draft even if IPv6 explicit null is used Pipe
> mode RFC 3270 MPLS Diffserv, explicit null label cannot carry a native IPv4
> packet SAFI 1 and would be dropped and would have to be LU labeled IPv4
> packets or the packets would get dropped.  In a global table routing
> scenario IPv4 packets tunneled over an IPv4 core don’t have to be labeled
> as it will break QOS EXP on the PHP node but in this case the native IPv4
> packet is exposed and can still be forwarded and not dropped as all the
> core P nodes are IPv4 enabled core, as with the 6PE encapsulation mismatch
> and resulting IPv6 packets being dropped.  Similarly In a global table
> routing scenario IPv6 packets tunneled over an IPv6 core don’t have to be
> labeled as it will break QOS EXP on the PHP node but in this case the
> native IPv6 packet is exposed and can still be forwarded and not dropped as
> all the P nodes are IPv6 enabled core, as with the 4PE encapsulation
> mismatch and resulting IPv4 packets being dropped.  The “design thing”
> scenario does come into play here with what I described above where the CE
> packet protocol matches the core protocol then you have the option to label
> or not label the packets.  Some vendors have the ability to match on both
> dscp and exp so even when the PHP POP and forward happens on the PHP node
> the router can schedule based on DSCP and if the label is present switch
> gears and schedule match on EXP.  So based on what is supported in the
> protocol matching scenario can decide to label or not label the customer
> traffic ingressing the core.
>
>
>
> ***I hope what I said above really helps clarify and cleans up any
> confusion and I can as well make these points more clear in the draft***
>
>
>
> So to reiterate the show stopper and why the packets being tunneled over
> the core must be labeled must have the MPLS shim for label switching and
> forwarding is the protocol mismatch scenario that happens when the native
> packet gets exposed after the PHP POP and the P / PE all core nodes are
> IPv6 only - IPv6 only core for 4PE scenario and IPv4 only - IPV4 only core
> for 6PE scenario.
>
>
>
>
>
> That's why I said that we don't have to have the exact way to do things. I
> agree that is good to describe the necessity of having two labels and why
> but I don't think that it's the standard matter how I reach this goal,
> which family I will use, and so on.
>
>
>
> Gyan2> As I said your argument for SAFI 1 is the main reason why we need
> to have 4PE procedure to use SAFI 4 IPv4 labeled unicast so that all
> implementations of 4PE must follow the standard specification for
> interoperability.
>
>
>
>
>
>
>
> Thank you
>
>
>
>
>
> сб, 12 нояб. 2022 г. в 02:08, Gyan Mishra <[e-mail]>:
>
>
>
> Thanks Robert for your feedback on the draft.
>
>
>
> Dear IDR
>
>
>
> Please review the draft and provide feedback.
>
>
>
> Thank you
>
>
>
> Gyan
>
>
>
> On Fri, Nov 11, 2022 at 6:46 PM Robert Raszuk <[e-mail]> wrote:
>
> Gyan,
>
>
>
> Returning today from London I did read the draft. It's a great example of
> how IETF documents should *NOT* be written. 47 references says it all. You
> are mixing pieces from completely different areas all in one place.
>
>
>
> Indeed I encourage everyone to read this draft and submit an opinion to
> the list before WG takes any action on it.
>
>
>
> > You mean IPv6 mapped IPv4 address.
>
>
>
> No, I meant what I wrote.
>
>
>
> Kind regards,
>
> R.
>
>
>
>
>
> On Sat, Nov 12, 2022 at 12:13 AM Gyan Mishra <[e-mail]>
> wrote:
>
> Robert
>
>
>
> On Fri, Nov 11, 2022 at 4:49 PM Robert Raszuk <[e-mail]> wrote:
>
> Gyan,
>
>
>
> RFC8950 is all that is required to be standardized in IDR for connecting
> ipv4 sites over ipv6 core from the perspective of BGP extension to
> propagate reachability in the control plane. /* Btw as stated in my
> previous note even that is not needed if we would solve the requirement
> using v4 mapped v6 addresses. */
>
>
>
>    Gyan> 4PE as well as 6PE is more then just reachability extension next
> hop encoding.  Please read the draft and then provide me some feedback as
> it goes over all different inter-as scenarios as well as details
> requirements for 2 level label stack related BGP-LU labeled unicast
> labeling binding of all the IPv4 prefixes.  As well as implicit null PHP
> and explicit null case for RFC 3270 pipe mode support etc.
>
>
>
> You mean IPv6 mapped IPv4 address.  That has always been very confusing
> for troubleshooting as the next hop should follow the core protocol used
> for reachability and not the NLRI which would have been done backwards with
> IPv6 mapped IPv4 address and who knows what that would encode you look
> like..  for IPv4 core IPv6 NLRI over and IPv4 next hop is IPv4 mapped IPv6
> address ::FFFF:10.0.0.1.  That was one of the main reasons for encoding
>  simplicity to change to IPv6 address follows the core protocol in RFC 8950
> and not use IPv6 mapped IPv4 address.  Since the mapped address is not a
> legitimate address extra coding hooks need to be done to make it routable
> based on the embedded PE loopback in the next hop address.  All avoided and
> confusion avoided by using RFC 8950 style next hop encoding and not using a
> mapped address.
>
>
>
> > This draft also defines critical extensibility to segment routing
> SR-MPLS and SRv6 which did
>
> > not exist when 6PE RFC 4798 was developed.
>
>
>
> IDR does not standardize SR-MPLS nor SRv6.
>
>
>
>     Gyan> I am not standardizing SR as here just providing extensibility
> of the specification to support Segment Routing.
>
>
>
> > RFC 8950 as stated defines only  the next hop encoding and for example
> does not define
>
> > BGP MPLS VPN RFC 4659 AFI/SAFI 2/128 specification nor does it define
> BGP LU
>
> > RFC 8277 specification  AFI /SAFI 2/4….
>
>
>
> This is all defined in stated above documents.
>
>
>
>     Gyan> My point here is that AFI/SAFI 2/128 and 2/4 use RFC 8950 which
> only defines the next hop encoding for the AFI/SAFI and not the
> specification for the AFI/SAFI and thus the RFC.  RFC 4798 6PE uses IPv4
> mapped IPv6 next hop encoding which does not have a next hop encoding
> specification but still does have an RFC for 6PE.  Even if a next hop
> encoding standard existed, that would just be for the next hop encoding,
> does not mean that a standard for 6PE is not necessary for interoperability
> as is the case here.
>
>
>
> IDR drafts focus on required protocol extensions to BGP. I do not see any
> new protocol extensions in this draft anyway.
>
>
>
> Gyan> 6PE RFC 4798 as well does not have a IANA code point allocation for
> a protocol extension, however it does define a procedure and process of how
> 6PE works which is why it was still standardized so ensure interoperability
> between vendor implementations.  There are many more examples as such that
> have
>
>
>
> Regards,
>
> R.
>
>
>
>
>
> On Fri, Nov 11, 2022 at 10:38 PM Gyan Mishra <[e-mail]>
> wrote:
>
>
>
> Robert
>
>
>
> RFC 8950 only defines only the IPv4 NLRI over IPv6 next hop encoding IANA
> BGP capability code point 5 that updates RFC 5549 next hop encoding for
> SAFI 128 and 129 where the 8 byte RD set to 0 was left of the next hop
> encoding specification.
>
>
>
> RFC 8950 as stated defines only  the next hop encoding and for example
> does not define BGP MPLS VPN RFC 4659 AFI/SAFI 2/128 specification nor does
> it define BGP LU RFC 8277 specification  AFI /SAFI 2/4….
>
>
>
> The next hop encoding is just component of the overall 4PE specification
> which did exist till this draft was published.  There are vendors that have
> implemented 4PE which may or may not even be called 4PE, and this draft
> defines the name “4PE” and what it means form a specification perspective
> and thus would ensure the standardization of all implementations to ensure
> interoperability.
>
>
>
> As operators start migrating their core to IPv6 this does become a big
> deal as most operators have multi vendor environments and so this comes to
> the surface as a hot topic to ensure interoperability.
>
>
>
> This draft also defines critical extensibility to segment routing SR-MPLS
> and SRv6 which did not exist when 6PE RFC 4798 was developed.
>
>
>
> Many Thanks
>
>
>
> Gyan
>
>
>
> On Fri, Nov 11, 2022 at 3:56 PM Robert Raszuk <[e-mail]> wrote:
>
> Gyan,
>
>
>
> IDR draft:
>
>
>
> The 4PE draft connecting IPv4 islands over an IPv6 core  over the global
> table is similar in semantics to 6PE RFC 4798 which connects IPv6 islands
> over an IPv4 core over the global table and the draft is extensible to
> SR-MPLS and SRv6. There currently is not a standard for 4PE so this draft
> would standardize 4PE for vendor  interoperability.
>
>
>
> Not true.
>
>
>
> Quote from RFC8950:
>
>
>
> *Error! Filename not specified.*
>
>
>
> I do not see anything your draft would add to it.
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
> https://datatracker.ietf.org/doc/draft-mishra-idr-v4-islands-v6-core-4pe/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mishra-idr-v4-islands-v6-core-4pe%2F&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cebf83eeab09a4f1924cc08dac68d2721%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638040606870609110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=siyCIJyLD%2FefG5RJ75BStxHONtHaN1gP1j7cHNTXFck%3D&reserved=0>
>
>
>
> BESS drafts - these drafts are completely different from IDR 4PE draft.
>
>
>
> I have already combined two of the drafts into one for the IPv4-Only PE
> All SAFI draft
>
>
>
>
> https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4-only-pe-design-all-safi/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mishra-bess-ipv4-only-pe-design-all-safi%2F&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cebf83eeab09a4f1924cc08dac68d2721%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638040606870765321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GG%2Bna6ZoeEoKbC2F0zEKxe0B2Ln%2Fs%2BRWVTdl%2B4uwvJ8%3D&reserved=0>
>
>
>
> IPv6 Only PE Design BCP draft below was adopted  last year and the new
> draft extensible to ALL SAFI Standards Track below I plan to progress
> separately.  As one is BCP and the other Standards track I don’t think they
> could be combined and even if they were combined into the super set all
> SAFI that would have to go through adoption process again anyway so I plan
> to keep separate.
>
>
>
> This draft I will queue up for adoption call.
>
>
>
>
> https://datatracker.ietf.org/doc/draft-mishra-bess-ipv6-only-pe-design-all-safi/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mishra-bess-ipv6-only-pe-design-all-safi%2F&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cebf83eeab09a4f1924cc08dac68d2721%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638040606870765321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GZ%2BnTsl5DZx9bjh5dEgAe5bFI9ZJBNGOAdD16Q%2FQndY%3D&reserved=0>
>
>
>
>
>
> Many Thanks
>
>
>
> Gyan
>
>
>
> On Fri, Nov 11, 2022 at 6:19 AM Ketan Talaulikar <[e-mail]>
> wrote:
>
> Hi Gyan,
>
>
>
> Sharing a couple of suggestions here for your 5 drafts (4 in BESS + 1 in
> IDR) as we lost time due to the audio issues:
>
>
>
> (1) put the portions to be standardized (very focussed/small hopefully) in
> one single draft and post/share with both IDR and BESS since you are
> changing NH encoding (from what I heard?)
>
> (2) all other informational/BCP material could be combined in a single
> draft (perhaps the existing BESS WG draft)
>
>
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*