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

Gyan Mishra <hayabusagsm@gmail.com> Wed, 16 November 2022 00:53 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CD1C1526E7 for <bess@ietfa.amsl.com>; Tue, 15 Nov 2022 16:53:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 4rPakWfYTTxT for <bess@ietfa.amsl.com>; Tue, 15 Nov 2022 16:53:23 -0800 (PST)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 96744C152594 for <bess@ietf.org>; Tue, 15 Nov 2022 16:53:23 -0800 (PST)
Received: by mail-qt1-x82e.google.com with SMTP id w9so33266qtv.13 for <bess@ietf.org>; Tue, 15 Nov 2022 16:53:23 -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=WfCe/WRSup9W1fJpcjY6Miw9ldn2zVWKYFPn5CEXSSo=; b=W3+TBcUooz3lPjpdUeOsTnbLCa2NjRpvGPEMY415+xXjYWc7D95Tp8b0LAK16vTDt5 m+gJF46rJ+DCdx7E+tsGCVbW8i1pZAsoXNp+a3ZqgVNK4veeAYs/4aapEGAyc5W3nEMm 5gyBq8jYHY7h4Td6NC9a51wb04rJe7BTq/HqN6WHJ6oxxyYZluSkymH3imQDcjVDM9Sy g1UCGSEgRMwX//wJ+aV7lclCBLbVggXHkidtN36UOfuuEs7RGpOesC7iDyNOTBapawNn nw74vnxSh82DCMcr/P57EjE3wq3KW1fYCZmA/CDB4thbfA+IqdKc8Wdxi5g0NUawe1Dg Lcrg==
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=WfCe/WRSup9W1fJpcjY6Miw9ldn2zVWKYFPn5CEXSSo=; b=JF8rtddqO9QN8z9ahw35gvcG5W4O2VkmgwtHEq1sHcJprNFhWGjcqvGsXY598S7w/K kmk06gqLkuwDQpqhSb/H7XY5zk5KUXKFUiFWCCt2qutKxwvAXSNVUdf/xKhx0m+KuBDa RrknspXTEI9jf8khA0keAMP7rnWvl56LQB/Dz1CgWHRoXtwDXKXPTLHa6HQUUT/nDLzX 4aXhDMtMbKe3ky3ZEFYl4Hex7WclLNdwnBIh8XcbwaLqOYEV15UDR/c+KBO/zFEM0TWX nTqt8gvpy0W+QK4s8pKUH6DXVmYQVnYitHm+BB8y0G9Ot/3c4upCGvrI7QLXT1M+v+rX TilQ==
X-Gm-Message-State: ANoB5pnWJmpxilfgaFZo/wnEjsye59RQQB1MQER0AXrFqt14yoMUfy8Z TfGmoLmKP/R92+YsrBPWzePJwaRJjIcTyoYJLLE=
X-Google-Smtp-Source: AA0mqf4ejI1zvOMeelvf2OOa9oqGLJ5t0sxP2kt+3MNuD5+TvjG35Hc1BaDCvLOyx26cDNP/aSvyKoG76jbaxtiwJYQ=
X-Received: by 2002:a05:622a:1808:b0:3a5:3628:4304 with SMTP id t8-20020a05622a180800b003a536284304mr18951463qtc.517.1668560001761; Tue, 15 Nov 2022 16:53:21 -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> <SJ0PR84MB211071BF2AC6E1DC9F0EF5C294049@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM>
In-Reply-To: <SJ0PR84MB211071BF2AC6E1DC9F0EF5C294049@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 15 Nov 2022 19:53:09 -0500
Message-ID: <CABNhwV3jz0YodqufSX==mqHhhDS7g-p0WL+Xd2C2-SQEu9X_EA@mail.gmail.com>
To: "Dikshit, Saumya" <saumya.dikshit@hpe.com>
Cc: BESS <bess@ietf.org>, Ketan Talaulikar <ketant.ietf@gmail.com>, Robert Raszuk <robert@raszuk.net>
Content-Type: multipart/related; boundary="00000000000031d2cd05ed8be6d1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/lTIM_xOWpHLE70AK4tPhPi222G4>
Subject: Re: [bess] Suggestion on v4-only/v6-only drafts
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2022 00:53:27 -0000

Hi Saumya

Thank you for your support.

Responses in-line

Thank you

On Tue, Nov 15, 2022 at 1:37 PM Dikshit, Saumya <saumya.dikshit@hpe.com>
wrote:

> Hello Bess member,
>
>
>
> I support the adoption of this draft as a WG document.
>
>
>
> Hello Gyan et all,
>
>
>
> I have following comments from the fleeting parse of the first half of the
> draft with tag [SD]
>
>
>
> >>>>The Ingress and Egress PE Label Stack on the 4PE router
>
>    contains the Service label with Bottom of Stack "S" bit set and
>
>    contains the IPv4 NLRI prefixes "labeled" using BGP-LU, IPv4 Address
>
>    Family Identifier (AFI) IPv4 (value 1) Subsequent Address Family
>
>    Identifier (SAFI)(value 4).
>
> [SD] I think we need to mention label-space may be distinct/common for
> each AF/SAFI.
>
>  Gyan> Good point and Will add in next revision
>
>
>
> >>>> The 4PE design is fully applicable to both full mesh BGP peering
>
>    between all Ingress and Egress PE's as well as when Route Reflectors
>
>    are utilized as per BGP specification
>
> [SD] You may want to use the term Route-servers as Route reflectors a
> typical for iBGP peering
>
> Gyan> Here I am describing the PE to RR peering which would be iBGP
> however their could be case as well for eBGP which I will clarify and add
> RS scenario
>
> >>>>the 4PE
>
>    design described in this document, all such systems MUST support
>
>    building the topmost transport label tunneling using IPv6-signaled
>
>    MPLS LSPs established by LDP [RFC5036
> <https://datatracker.ietf.org/doc/html/rfc5036>] or Resource Reservation
>
>    Protocol (RSVP-TE) [RFC3209
> <https://datatracker.ietf.org/doc/html/rfc3209>].
>
> [SD] Is underlay a better mention here, instead of “topmost transport
> Label tunneling”.
>
> More so, a signaling purists may indicate, that LDP may just form a so
> called LSP, whereas, RSVP-TE signals a “TE tunnel”.
>
>  Gyan> Agreed and easier to read using underlay
>
> >>>>While this design concept could theoretically operate in some
>
>    situations using a single level of labels,
>
> [SD] should this be underlay labels and not related to ipv4 prefix labels
>
>  Gyan> Yes I will fix
>
> >>>> Therefore, on MPLS links that are used for
>
>    transport of IPv4, as per the 4PE approach, and that do not support
>
>    link-specific fragmentation and reassembly, the MTU must be
>
>    configured to at least 576 octets plus the MPLS label stack
>
>    encapsulation overhead bytes.
>
> [SD]For any underlay build upon ipv6, the min mtu size should be a
> function of 1280. There is a mention of same in the following text, but not
> here.
>
>
>
> >>>> This is
>
>    because, according to [RFC4443
> <https://datatracker.ietf.org/doc/html/rfc4443>], the core router will
> build an ICMP
>
>    "Unreachable " message filled with the invoking packet up to 576
>
>    bytes,
>
  Gyan> You are correct 1280 min for IPv6 underlay will fix.

> [SD] The term “core router”, is it referring to an lsr in the underlay
> path (LSP or RSVP-TE tunnel). Kindly make it clear.
>
> Gyan> Will do
>
> >>>>  In the 4PE design with Segment Routing SR-MPLS architecture [RFC8660 <https://datatracker.ietf.org/doc/html/rfc8660>]
>
>    the design is identical as the IPv6 signaled LSP from ingress PE to
>
>    egress PE is identical but now with underlay traffic steering
>
>    capabilities.
>
> [SD] Needs paraphrasing.
>
>  Gyan> Will do
>
> >>> Nitties
>
> Basic Spell checks are missing.
>
>  Gyan-> Will fix
>

Thank you!!

> Regards,
>
> Saumya.
>
>
>
>
>
> *From:* BESS [mailto:bess-bounces@ietf.org <bess-bounces@ietf.org>] *On
> Behalf Of *Gyan Mishra
> *Sent:* Saturday, November 12, 2022 4:43 AM
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* BESS <bess@ietf.org>; Ketan Talaulikar <ketant.ietf@gmail.com>
> *Subject:* Re: [bess] Suggestion on v4-only/v6-only drafts
>
>
>
> 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:
>
>
>
> [image: image.png]
>
>
>
> 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/
>
>
>
> 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/
>
>
>
> 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/
>
>
>
>
>
> 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.] <http://www.verizon.com/>
>
> *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
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *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.] <http://www.verizon.com/>
>
> *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*