Re: [bess] Suggestion on v4-only/v6-only drafts
Gyan Mishra <hayabusagsm@gmail.com> Wed, 16 November 2022 21:09 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 E29A0C1522B4 for <bess@ietfa.amsl.com>; Wed, 16 Nov 2022 13:09:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.092
X-Spam-Level:
X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, 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 gZY4KK-mJw6I for <bess@ietfa.amsl.com>; Wed, 16 Nov 2022 13:09:50 -0800 (PST)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 60528C14F749 for <bess@ietf.org>; Wed, 16 Nov 2022 13:09:50 -0800 (PST)
Received: by mail-qt1-x829.google.com with SMTP id fz10so11568366qtb.3 for <bess@ietf.org>; Wed, 16 Nov 2022 13:09:50 -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=rWbTY6MnO8Q0kVoFJZV7xZwFWrEB5k0dKWRF1A7KYsI=; b=Z7tO1XewCC0qmHNaCQWMgdt1WyPFLOzS4rUgI8Qc77pxDALKA0dCOxbL3pxVY0azgm b95ERGEdynMIvcwb92nS9zPKnpIUvlE6dbWM/NTTx8Or6rroc8xXvWyV/CHWIhpdJ62L 5yCP4Mc7ZBfWYThFvfLf86zkJcWLIIsznUyDkLrt5+CT2p4Q3EHRUqR6yLDHjoAxuMoO Tb4Ko1Vz0fgmJ3NBItUguxKGP81cawsY7kcXzgJIyivA/qroUwvrLO2dyRJE0yS7bqT1 HAXhKvTq5N7PeO/fYw6HRaAmd8QD+MEpJcYZzyaXk1HDWDneyGPpBT+1rePpYN7QLjdd jX4A==
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=rWbTY6MnO8Q0kVoFJZV7xZwFWrEB5k0dKWRF1A7KYsI=; b=hKiVp8MgmbWrIgV+B1q3VF0l31C/lmM98NsQZGJpcWJcQb1dodRkiFSLWyyA0P+rpN J+3Mf4KkWlyfNEzT9k11N4T6QbY1lSnjG4IHb7kH7WSejRkgM1+IjX1oM4NiPBPCxER/ uFetOt+Qzy0AWZQXjhMJuajGXRldRKgDP3mdipGG8gGstr+OXPI12I9FlBjxHNHix45A Nr6VMIlyGjfJPt3SeM7Ee0pG6kgQyCwpI1nODRR0ZDoaSGl7Jo9SFzP9VwvTOult8buo 803UrdncdM+XMyBA/+ccMmsYCWYSzlPuhwwqg+hJ8eJ1O59c/Zrtt1k6qKa4qTYBVMmB MeQQ==
X-Gm-Message-State: ANoB5plS7oFM89O/yTQaxv3Utj7vyf2c5Lxiw3JnxRiEBpzS+Q4MkCwU XLsNHxpqvb/u7ag/d5Ay3Eab6wPKWh61Fkgyx2U=
X-Google-Smtp-Source: AA0mqf7wpZmv0pVYX1/KanSFDjjtyr1Z3hK2aRfOzBws1Qgl+UzsiRM6I0GASuI6AJQZ1ux9UP/s4ROVMpN62L8k/7Q=
X-Received: by 2002:ac8:5a54:0:b0:3a5:9170:458e with SMTP id o20-20020ac85a54000000b003a59170458emr22987501qta.509.1668632988504; Wed, 16 Nov 2022 13:09:48 -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> <CABNhwV3jz0YodqufSX==mqHhhDS7g-p0WL+Xd2C2-SQEu9X_EA@mail.gmail.com> <SJ0PR84MB2110B2ED766CF279D202D99694079@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM>
In-Reply-To: <SJ0PR84MB2110B2ED766CF279D202D99694079@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 16 Nov 2022 16:09:36 -0500
Message-ID: <CABNhwV1TU=EYAOcusw7Y9tP4EWKwCBYTqN7C5apLNry7P8X4KA@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="0000000000008ae0de05ed9ce417"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/0FfboRPr0jo-i52dbohaMzfl8vU>
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 21:09:55 -0000
Thanks Saumya! On Wed, Nov 16, 2022 at 5:25 AM Dikshit, Saumya <saumya.dikshit@hpe.com> wrote: > Thanks Gyan. Will aim to review-in the SR specific pieces in due course. > > > > Regards, > > Saumya. > > > > *From:* Gyan Mishra [mailto:hayabusagsm@gmail.com] > *Sent:* Wednesday, November 16, 2022 6:23 AM > *To:* Dikshit, Saumya <saumya.dikshit@hpe.com> > *Cc:* BESS <bess@ietf.org>; Ketan Talaulikar <ketant.ietf@gmail.com>; > Robert Raszuk <robert@raszuk.net> > *Subject:* Re: [bess] Suggestion on v4-only/v6-only drafts > > > > > > 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* > > > > -- > > [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*
- [bess] Suggestion on v4-only/v6-only drafts Ketan Talaulikar
- Re: [bess] Suggestion on v4-only/v6-only drafts Robert Raszuk
- Re: [bess] Suggestion on v4-only/v6-only drafts Ketan Talaulikar
- Re: [bess] Suggestion on v4-only/v6-only drafts Robert Raszuk
- Re: [bess] Suggestion on v4-only/v6-only drafts Gyan Mishra
- Re: [bess] Suggestion on v4-only/v6-only drafts Gyan Mishra
- Re: [bess] Suggestion on v4-only/v6-only drafts Robert Raszuk
- Re: [bess] Suggestion on v4-only/v6-only drafts Gyan Mishra
- Re: [bess] Suggestion on v4-only/v6-only drafts Robert Raszuk
- Re: [bess] Suggestion on v4-only/v6-only drafts Gyan Mishra
- Re: [bess] Suggestion on v4-only/v6-only drafts Dikshit, Saumya
- Re: [bess] Suggestion on v4-only/v6-only drafts Gyan Mishra
- Re: [bess] Suggestion on v4-only/v6-only drafts Dikshit, Saumya
- Re: [bess] Suggestion on v4-only/v6-only drafts Gyan Mishra