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

Gyan Mishra <hayabusagsm@gmail.com> Tue, 15 November 2022 00:21 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221A1C14CE35 for <idr@ietfa.amsl.com>; Mon, 14 Nov 2022 16:21:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.083
X-Spam-Level:
X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wvfd2uy8b3n7 for <idr@ietfa.amsl.com>; Mon, 14 Nov 2022 16:21:36 -0800 (PST)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B668C14CF13 for <idr@ietf.org>; Mon, 14 Nov 2022 16:21:36 -0800 (PST)
Received: by mail-qk1-x731.google.com with SMTP id d8so5363482qki.13 for <idr@ietf.org>; Mon, 14 Nov 2022 16:21:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ecH/Rt3jCGbexEb0EzrjRqlLp2Dy5SNqT5kT9E2wVLc=; b=mZ2o/VEnVf3pKvStrkzlcLKYr4cONQIxhhBUuSnSQUvchOhFHAL5iDfV183L3KyeZE 38bxSfmGHSLYK0oD8DWwFKvMtxiyJeTcINw8jvRBKiRY2oYqLqjTABfPJ3xaweSCQK7N PbBBhRapnEsM2LlLy/F/AFecrgHSjKesCI/uugDcJDbJ14aEqV4htLHIe6W991xoGNf1 Wz6CSb4gB4Nd9fwLAKF1bWR8pdsMOz55t1vy/Fc66dTqgGvbuB7oZdq63KNYx8K/hXdF /V3N4Lw9Pm+O+h9ujxwqqWfbkSRXnysiQ0OW8tsCG4Ie8M4ei23Fuj1RVs7VsHivzndu lBRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ecH/Rt3jCGbexEb0EzrjRqlLp2Dy5SNqT5kT9E2wVLc=; b=VkA8s3gH43KfbeW6iWxIIjLSKXLfbP3Ikwlow8nuORgX0G+r+0F5Lb9gf9co8IxsN3 TDkJNb52kCUv8nhHqedx6kgWEmwLSFKC1WIe0mfvcb+pupEjSkwmfyI9f/5Fk30AisqH Maw018al6z3KvR3DmfRjjNUqJZ1akGlE0Nt9KShIKJQyll4luhuhsCG0C/So++IyLBm2 7lPOgYRGiRFxi/gnAVq72ABX+9a0GzfoAKFpRYblYqBOQ5GZRn8zzmdBgrotSXdOOs6M bb7jkY9oQqKpETAT7Zob4bJXH1lEVV9q5KW/CctDpt6T2ziPBUiostfg/jNDxkO1ysKP h8vw==
X-Gm-Message-State: ANoB5pmD7KKhsycqXzKeSqyXDtzpiZ7KDQtnceO9uAq7IkKZcnvHAh/O lw+ET8SSmE1acSSIfybq2qebZwG2MD6mlOcTgjxLd+Ro
X-Google-Smtp-Source: AA0mqf59J3OIOdWaDYemG4Gchn390uNT6nVmoNcdvGl85XX7ZzbTSsh3RjBJFY/FQpzts11dHoJpF3auavEA9OG32Y8=
X-Received: by 2002:a05:620a:16d1:b0:6fa:156e:44c0 with SMTP id a17-20020a05620a16d100b006fa156e44c0mr13325291qkn.293.1668471694503; Mon, 14 Nov 2022 16:21:34 -0800 (PST)
MIME-Version: 1.0
References: <CAH6gdPzcMxor9hZy=+hS5oZPB_onU45-vh-ijm1jD2WPb0y+Gw@mail.gmail.com> <CABNhwV3bF=J7HDZ1Z3vxiJcLGcxOkXst+S1+1DHkdBQ+VdcbMA@mail.gmail.com> <CAOj+MMHMGd=7iBOQd=wUhjUJ3dPfHgY1+sf22AzpadoqCCdMrg@mail.gmail.com> <CABNhwV2F=-vh2irbz3GR+jr=j09AfxzfquTr8usjyZsYywrK=w@mail.gmail.com> <CAOj+MMHxQts0nkLuUo0vPezawK5F7m0Y1hhuQboQxCty+N4p4g@mail.gmail.com> <CABNhwV1-7EsS9aX11sAoSFezcDn0w_FNerAYkFTZ9GmDArVyvA@mail.gmail.com> <CAOj+MMETJFHaPp-n8unaw9zu51q+n--WL-9EeY-_1taEU3Q8-w@mail.gmail.com> <CABNhwV2r-n+EBzMS381kvXopFjM=WxcDg7x9eY5JsYxcY4uaHA@mail.gmail.com> <CAEfhRrxaxsbSfi3UWanzo5k0Dg0rwzMfjOjnp_jycr4aNc+8Ow@mail.gmail.com> <CABNhwV2qc3QOHB3HAcwuQAYO9oU8ZrVXfgq58yat-aEU9OnneQ@mail.gmail.com> <CAEfhRrxV=v5PdvvHRK8ijW-TgKumBZzBT+r6FJ=neQZyScgKeQ@mail.gmail.com> <CABNhwV29-Q5ReV3N-1W+H_RZXi-hPfSkgB5gojgywX4qNULwLg@mail.gmail.com> <CABNhwV27vA7bcuTYzrG8vfc5R=fbEJ_4c0YJn4Jex7ruFy2pLw@mail.gmail.com> <CAEfhRrxcGzm3GThXe1bqoqTHi1t4W2gY55Zf3BLEAjgiZ2VZiA@mail.gmail.com> <CABNhwV0_r9As9v9PZURmYC0nz0xrwv2+kx2C=1c7+--=m2X03g@mail.gmail.com> <CAEfhRrz4X9rbKZM0gMChUXbS6LxmEW_GWR6kD6gqUwNv4na0YA@mail.gmail.com> <CABNhwV1VBUaHhLwzxDnSW0Yns-pZ7C0H+5kHc2iMQn8VwPxW0A@mail.gmail.com> <E5F02060-8F2A-4D90-9BEF-AD3C69C5DD1B@futurewei.com>
In-Reply-To: <E5F02060-8F2A-4D90-9BEF-AD3C69C5DD1B@futurewei.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 14 Nov 2022 19:19:05 -0500
Message-ID: <CABNhwV3dqfL2T_MakZ3Ebq+X4wbZHDjg=UaNGcpGJPvnMpTHLg@mail.gmail.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: Igor Malyushkin <gmalyushkin@gmail.com>, Robert Raszuk <robert@raszuk.net>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ab321f05ed77569f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/CfrAJHwkVvwQ683f4UfN4MzLU1s>
Subject: Re: [Idr] [bess] Suggestion on v4-only/v6-only drafts
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2022 00:21:41 -0000

Hi Linda

Thank you

Responses in-line

On Mon, Nov 14, 2022 at 5:10 PM Linda Dunbar <linda.dunbar@futurewei.com>
wrote:

> 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?
>
> This is similar to 4VPE / VPNv4 SAFI 1/128 where the PE receives the IPv4
prefixes from the CE natively in the global table instead of VRF for VPN
and then are advertised to the RR using IPv4 labeled unicast 1/4 with RFC
8950 next hop encoding 16/32 byte and all PEs receive the route with the
IPv6 next hop encoding.  So the IPv6 ingress PE router IPv6 address is not
known at all to the IPv4 island.  The ingress PE is tunneling the IPv4
packets over the IPv6 core with 2 level label stack.


>    - 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?
>
> Yes so what that means is the 4PE routers convey their IPv6 address as BGP
next hop as over the service label LSP tunnel over the IPv6 core so the
service label bottom of stack in this case 4PE labeled unicast 1/4 has IPv6
next hop encoding 16/32 byte per RFC 8950.  This is similar to VPN SAFI 128
where the next hop is conveyed using service label LSP tunnel over the IPV6
core is the egress PE next hop which is an IPv6 address.  So the routers in
the IPv4 domain do not see the IPv6 next hop.  The traffic is tunneled over
IPv6 transport LSP built over the IPv6 core.  So we have a 2 level label
stack.  The transport tunnel topmost label is from ingress PE to egress PE
built to tunnel the IPv4 packets.  This is no different then VPN SAFI 128
1/128 over an IPv6 core, but now it’s global table routes tunneled as
labeled unicast SAFI 1/4 over the IPv6 transport LSP


>    - When the IPv6 core is SRv6, how does the IPv6 ingress node determine
>    the Func and Arg for the packets entering the SRv6 domain?
>
> This is described in RFC 9252 BGP overlay service see section 5.3.  So
> basically the egress PE signals the Ingres PE SRv6-BE with overlay service
> route or SRv6-TE SLA with RFC 9012 TEA VPN coloring which maps to SR policy
> intent for underlay steering and the SRv6 L3 service SID  is encoded into
> FUNC field for the packets entering the SRv6 domain. The mechanism for the
> BGP encoding for global table 4PE is similar to VPN SAFI 128 encoding  the
> FUNC field of the SRv6 SID is encoded into the SRv6 Service SID  L3 Service
> TLV BGP Prefix SID encoding data sub sub TLV for endpoint behavior End.DT4,
> End.DX4, End.DT46.  Section 2 SRv6 Service TLV describes the SRv6 L3
> service TLV encoding for the SRv6 BGP service overlay equivalent
> functionality provided by MPLS label when you receive a L3 service route.
> SRv6 PGM RFC 8986 describes the endpoint behaviors for 4PE  global routing.
>
.
>
> Linda
>
>
>
> *From: *Idr <idr-bounces@ietf.org> on behalf of Gyan Mishra <
> hayabusagsm@gmail.com>
> *Date: *Sunday, November 13, 2022 at 8:09 PM
> *To: *Igor Malyushkin <gmalyushkin@gmail.com>
> *Cc: *Robert Raszuk <robert@raszuk.net>, "idr@ietf. org" <idr@ietf.org>
> *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 <gmalyushkin@gmail.com>
> 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%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598681631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VhQ514SJa8ZkQGhKTs5Nd55XawirtHht7ebJ3b07l28%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 <hayabusagsm@gmail.com>:
>
>
>
> 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 <gmalyushkin@gmail.com>
> wrote:
>
> Ok, please see my explanation below.
>
>
>
> вс, 13 нояб. 2022 г. в 21:12, Gyan Mishra <hayabusagsm@gmail.com>:
>
>
>
> 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 <hayabusagsm@gmail.com> wrote:
>
>
>
> Hi Igor
>
>
>
> Please see in-line Gyan2>
>
>
>
> On Sat, Nov 12, 2022 at 7:44 PM Igor Malyushkin <gmalyushkin@gmail.com>
> wrote:
>
> Hi Gyan, please see the inline.
>
>
>
> вс, 13 нояб. 2022 г. в 01:39, Gyan Mishra <hayabusagsm@gmail.com>:
>
> 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 <gmalyushkin@gmail.com>
> 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%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598681631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=n436c8UBPtdCVlo1Obs1H7ymOHAf%2B3Nn28R8zeXgN%2Bo%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%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598681631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y4LzSkdLpHcs5xjyAiirFzpeHdIR7K1KJs15W61L7k8%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%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598681631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IaXbGWOkaZnp8N3lUwReANT2n1SiSg8Yv4Iqof26DD4%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%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598681631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hYVIzHOH0x0M49qwd88uljqz0DhsBCHQO0WWjOQ2B%2BI%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%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598681631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lhTN9NrutC6gvdLhlMiSqTSbUlR4W5Y2ZrPG1r74isU%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%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598681631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SMquvREQ7FLhEAtF8Oors%2F6eBbHLk0mtA5fOd33dko0%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%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598681631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2LdHsS3Q6YZdXM4xoaiIHdWRqnFKGVYkl%2FqEvJ3flso%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 <hayabusagsm@gmail.com>:
>
>
>
> 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 <robert@raszuk.net> 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 <hayabusagsm@gmail.com>
> wrote:
>
> Robert
>
>
>
> On Fri, Nov 11, 2022 at 4:49 PM Robert Raszuk <robert@raszuk.net> 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 <hayabusagsm@gmail.com>
> 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 <robert@raszuk.net> 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%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598681631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IfyGxGyiRif%2F4gV4eABeVLff3FE%2F1cAA9cWgj7KUU%2BU%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%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598681631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mzygRSY8RCDSwYf2XbkSW0T33%2F9GdC394OTwA3e8yNA%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%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598681631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LhnUUQZka57BZ%2F3p3L0Z4T1zwfD4if4ZlGYf%2Bo1av9E%3D&reserved=0>
>
>
>
>
>
> Many Thanks
>
>
>
> Gyan
>
>
>
> On Fri, Nov 11, 2022 at 6:19 AM Ketan Talaulikar <ketant.ietf@gmail.com>
> 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)
>
>
>
> IMHO, that would facilitate an appropriate focussed review of the
> content/proposals.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598681631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qdxNtCtcfYHA5AK8DCHKLUHiVn9Ostd46iPQ7RK7%2FZY%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598681631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RQ7%2FGP5At9KtCmO%2FWq8zVQED57DHeiay34xQQh6epR4%3D&reserved=0>
>
> --
>
> [image: Image removed by sender.]
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598681631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qdxNtCtcfYHA5AK8DCHKLUHiVn9Ostd46iPQ7RK7%2FZY%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598681631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qdxNtCtcfYHA5AK8DCHKLUHiVn9Ostd46iPQ7RK7%2FZY%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598837933%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=p%2FH737LADRkcfPiNeqCWgSO0XQtM1pbhjm4GjAYpIDE%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598837933%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZpRW2ephEFrFSG2xlQ8nRbvZlXQ9NNscYFDQjezH75w%3D&reserved=0>
>
> --
>
> [image: Image removed by sender.]
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598837933%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=p%2FH737LADRkcfPiNeqCWgSO0XQtM1pbhjm4GjAYpIDE%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598837933%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=p%2FH737LADRkcfPiNeqCWgSO0XQtM1pbhjm4GjAYpIDE%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598837933%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=p%2FH737LADRkcfPiNeqCWgSO0XQtM1pbhjm4GjAYpIDE%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598837933%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=p%2FH737LADRkcfPiNeqCWgSO0XQtM1pbhjm4GjAYpIDE%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C190a25b5bf8a45ad7a6908dac5e53938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638039885598837933%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=p%2FH737LADRkcfPiNeqCWgSO0XQtM1pbhjm4GjAYpIDE%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*