From nobody Tue Oct 4 21:16:06 2022 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190CDC1524C0; Tue, 4 Oct 2022 21:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-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 aroDZtk0HRNQ; Tue, 4 Oct 2022 21:15:57 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 57DE8C14F736; Tue, 4 Oct 2022 21:15:57 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id o7so9596562qkj.10; Tue, 04 Oct 2022 21:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date; bh=Fso6qE5J59scFDbftOz0z7brPMyGKci8iGZy5agCQxw=; b=fkGNfvvonrSz/cYYJ0QrSB0UFhEViqdkDolFFtTzIHNaoQ620qfClaVRNzQ9nAZm9S vNCfEzD2mmEZVHlBrUy/JwnoNfCcZtX23fYjOee3azX3zkaIvuGKEb5C6oRZm4uApXf/ TYePiH0paJOKj9RMZNhaRFGteYeKmpr6n5P5RpPIvZb9NmvJ5A4K4egzXuOokwUmjLwi JttnVj8KiYLk5TOZfiRWzna9DQ10j3faBSdAk29qwPdNeO4qdqu8kPIp1gDIHlM9O4Z5 HnO0Yw6bMpwPpELYMQ2Cxi7IKz33B29Ov2mvHOV+nH5q2Ncu0cxqf2mtC6TmGb2x9ubg GOMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=Fso6qE5J59scFDbftOz0z7brPMyGKci8iGZy5agCQxw=; b=WwBbao0XCDAGf5DUb2Yid3KtrPjNEbwA8uNW8LztIpU9QJFemTQzsPhyaz3/oFWpDv RBU9WPSgLiB6Ofes0JFK25BHvKTir4eiEEqqZvrGjCn+RKH5hJjgjY9zTIgJeNph5VFk lEZsatdRhCXu5pzdEsc07oChfYSlOMayHLvsM6Z+OZzk4YP0eGb5L2f95DF0OfC4qJm3 /kQfOpRZ+ZKens1lcDYWS18Z0riXMyZw1URDp0hjj58Bz1MZhaRIOn1rJspCSWWkQYag +WYb+OADIf0QffoIzpQO2KeZU/+se/SC1r+IFBvZ1oUWhM+Oag8kvnCiRG4J5JxtQmcr Gb3w== X-Gm-Message-State: ACrzQf3ynhLNdLHKc0vR2zX3wc9+ZUkRh7nvzJaJtIBr2bliatEkZypj GkR7Zof8lE0SBAzLQKdDPWo= X-Google-Smtp-Source: AMsMyM7Rdu7y4Ooh6Bz30ThdXu9+W9kBYaEJixoWAGosC95jWQvPZUwUe33fytagQ2s9r6N97i12FQ== X-Received: by 2002:a05:620a:2987:b0:6ce:c029:5f03 with SMTP id r7-20020a05620a298700b006cec0295f03mr19178913qkp.157.1664943356182; Tue, 04 Oct 2022 21:15:56 -0700 (PDT) Received: from smtpclient.apple (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id s5-20020a05620a0bc500b006cfa7b944fdsm16587793qki.16.2022.10.04.21.15.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Oct 2022 21:15:55 -0700 (PDT) From: Suresh Krishnan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DE5BBAE7-B5A1-4227-8553-BC085A48BF23" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Wed, 5 Oct 2022 00:15:54 -0400 In-Reply-To: <8e5df75fad76464eaa11d2cd155751ae@huawei.com> Cc: "buraglio@es.net" , Gyan Mishra , SPRING WG List , 6man , "spring-chairs@ietf.org" , "draft-ietf-6man-sids.authors@ietf.org" , 6man Chairs <6man-chairs@ietf.org> To: Vasilenko Eduard References: <2f640b1d-3178-c3ca-7af2-cc6059413724@gmail.com> <8e5df75fad76464eaa11d2cd155751ae@huawei.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [spring] 6MAN WGLC: draft-ietf-6man-sids X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2022 04:16:02 -0000 --Apple-Mail=_DE5BBAE7-B5A1-4227-8553-BC085A48BF23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ed/Nick/Mark/Michael/Robert/Gyan, I have noted the valuable points you brought up regarding the format, = and operational properties of the prefix. They are all extremely = relevant to the discussion of the operational guidelines mentioned at = the end of section 5. I will try to put these together for a potential = presentation for discussion during IETF 115 (venue TBD). Thanks Suresh > On Oct 4, 2022, at 1:27 PM, Vasilenko Eduard = wrote: >=20 > Does it make sense to develop prefix randomization inside this new = SRv6 block? (like for fd/8) > Or else it may happen the same as for fc/8 =E2=80=93 it is not used = because no one organization has been found to accept the registry = duties. > Ed/ > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Nick Buraglio > Sent: Tuesday, October 4, 2022 6:44 PM > To: Gyan Mishra > Cc: SPRING WG List ; 6man ; = spring-chairs@ietf.org; draft-ietf-6man-sids.authors@ietf.org; 6man = Chairs <6man-chairs@ietf.org> > Subject: Re: 6MAN WGLC: draft-ietf-6man-sids > =20 >=20 > ---- > nb > =20 > =20 > On Thu, Sep 29, 2022 at 11:16 AM Gyan Mishra > wrote: > Brian > =20 > On Thu, Sep 29, 2022 at 5:50 AM Brian Carpenter = > = wrote: > No Gyan, fc00::/7 is not available for carving. fc00::/8 is on reserve = for the dreamt-of centrally registered ULA prefixes, and fd00::/8 is = fully committed. > =20 > If SRV6 is important, it could justify its own prefix. > =20 > =20 > Gyan> As using either GUA or ULA for SRV6 block provides = flexibility for operators, I agree that SRv6 can justify its own global = block as the /16 being allocated with this draft. I think we should = augment the draft to add a dedicated ULA bock maybe same /16 size would = be reasonable. Since there is not an IANA ULA registry since ULA is = private, as the compressed SID violates RFC 4291, I think maybe a draft = at least that defines the dedicated /16 block for ULA for SRV6 use is a = good idea. > =20 > I would caution against use of ULA for this for a number of reasons, = not the least of which is the fact that ULA is allocated as Brian = mentioned prior. A dedicated block solves both the issue of potential = overlap with site specific use of ULA (which admittedly is probably = unlikely), but also creates a clear visual indicator as well as an = easier programmatic implementation by using something that should never = occur elsewhere in the network topology. Also, using non GUA blocks = further complicates inter-domain efforts which is not a show stopper, = but is definitely notable in that SR block allocation now needs to be = coordinated further than internally. =20 > =20 > =20 > =20 > One of the major benefits as I mentioned for ULA over GUA is that ULA = is not internet routable and that mitigates any possibility of security = issues with SRV6 SID leaking to the internet. > =20 > This is a legitimate use case, and with the lack of SRH4 filtering = capabilities in platforms I have looked at (admittedly not everything) = this is an operational concern, however, I suspect that will be = addressed and should be part of a best practices recommendation for = anyone not attempting to do inter-domain SRv6 provisioning regardless of = SRv6 SID choices. It feels a little like the model of using RFC1918 = space as a mechanism to further "air-gap" the control plane - which I = have totally done in the past, so no judgement - just an observation. = Not illegitimate, but definitely needs a bit of forethought, which in = many cases it does not get.=20 > As an operator, my response would be "why not both?". A dedicated = block ofnon-ULA space for use when required / desired and perhaps a bit = of verbiage on operational considerations for filtering at network edges = when GUA is in play? Similar concerns are covered in section 4.1 but = stop short of filtering the header.*** > =20 > =20 > =20 > *** my experience with this is largely lab-focused and incomplete = having only tested a few platforms and software packages, so I fully = admit that I may be missing information or misunderstanding. IIRC, one = platform could filter RH0 and none did 4. > =20 > =20 > Thoughts? > =20 > Regards, > Brian Carpenter > (via tiny screen & keyboard)=20 > =20 > =20 > On Thu, 29 Sep 2022, 19:45 Gyan Mishra, > wrote: > =20 > =20 > On Wed, Sep 28, 2022 at 11:31 PM Brian E Carpenter = > = wrote: > On 29-Sep-22 16:06, Gyan Mishra wrote: > ... >=20 > > We should qualify the IANA request to make the /16 non internet = routable identical to ULA addressing. > >=20 > > If that is what we desire then why don=E2=80=99t we make it standard = BCP to always use ULA for the operators SRV6 domain. >=20 > I don't believe that a /48 would be enough, but it is required, to = conform with RFC4193. > =20 > Gyan> Understood. Most operators would like to use ULA for SRV6 = deployments so do we need to carve out block out of ULA space just as we = are doing for GUA to conform with RFC 4291. ULA has is a big enough = block FC00::/7 so we could carve a block out of that. Does not need to = be as large a block allocation for SIDs as it would not be advertised to = the internet does not require to be globally unique. >=20 >=20 > Brian >=20 > > We would not have to burn up a /16 unnecessarily. > >=20 > >=20 > > Kind Regards > >=20 > > Gyan > >=20 > > On Sat, Sep 17, 2022 at 4:00 AM Jen Linkova >> wrote: > >=20 > > Hello, > >=20 > > This email starts the 6man Working Group Last Call for the = "Segment > > Identifiers in SRv6" draft > > (https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids = >). > >=20 > > The WGLC ends on Tue, Oct 4, 23:59:59 UTC. > >=20 > > As the document is closely related to the work in the SPRING = WG, we'd > > like the SPRING WG to review the document and discuss the = following > > questions: > >=20 > > - the action items required from SPRING (Section 4.1 and 4.2 of = the > > draft, = https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids-01#section-4 = = >= ) > > [*]. Would it make sense to merge those open issues with the = 'Open > > Issues' section of > > the SPRING document? > > - whether the document needs more guidance regarding = routability of > > /16 or such requirements shall belong to some other document? = In > > particular, shall we specify that it MUST NOT be in the DFZ? Or > > setting 'Globally Reachable =3D false' in the registry should be > > sufficient? The current idea is that the prefix needs to fail = closed > > and not be routable by default. > >=20 > > [*] The draft currently refers to the individual submission = instead of > > = https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ = = = = > > > - the link will be updated in the next revision. > >=20 > > Please review the draft and send your comments to the list/ > >=20 > > --=20 > > SY, Jen Linkova aka Furry > >=20 > > = -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > > Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 = > > > = -------------------------------------------------------------------- > >=20 > > --=20 > >=20 > > > > >=20 > > *Gyan Mishra* > >=20 > > /Network Solutions A//rchitect / > >=20 > > /Email gyan.s.mishra@verizon.com = >// > > / > >=20 > > /M 301 502-1347 > >=20 > > / > >=20 > >=20 > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 = > > -------------------------------------------------------------------- > --=20 > = > Gyan Mishra = > Network Solutions Architect=C2=A0 = > Email=C2=A0gyan.s.mishra@verizon.com = > M 301 502-1347 = > =C2=A0 = > -- = > = Gyan Mishra > Network Solutions Architect=C2=A0 > Email=C2=A0gyan.s.mishra@verizon.com > M 301 502-1347 >=20 > = > =C2=A0 = > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests:=C2=A0https://www.ietf.org/mailman/listinfo/ipv6= > -------------------------------------------------------------------- = > =E1=90=A7 = --Apple-Mail=_DE5BBAE7-B5A1-4227-8553-BC085A48BF23 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ed/Nick/Mark/Michael/Robert/Gyan,
  I have noted the = valuable points you brought up regarding the format, and operational = properties of the prefix. They are all extremely relevant to the = discussion of the operational guidelines mentioned at the end of = section 5. I will try to put these together for a potential presentation = for discussion during IETF 115 (venue TBD).

Thanks
Suresh

On Oct 4, 2022, at 1:27 PM, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:

Does it make sense to develop prefix = randomization inside this new SRv6 block? (like for fd/8)
Or else it may happen = the same as for fc/8 =E2=80=93 it is not used because no one = organization has been found to accept the registry duties.
Ed/
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf = Of Nick = Buraglio
Sent: Tuesday, October 4, 2022 = 6:44 PM
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: SPRING WG List <spring@ietf.org>; 6man = <ipv6@ietf.org>; = spring-chairs@ietf.org; draft-ietf-6man-sids.authors@ietf.org; 6man Chairs <6man-chairs@ietf.org>
Subject: Re: 6MAN WGLC: = draft-ietf-6man-sids
 

----
nb
 
 
On Thu, Sep 29, 2022 at 11:16 AM Gyan = Mishra <hayabusagsm@gmail.com> wrote:
Brian
 
On Thu, Sep 29, 2022 at = 5:50 AM Brian Carpenter <brian.e.carpenter@gmail.com> wrote:
No Gyan, fc00::/7 is not available for carving. fc00::/8 is = on reserve for the dreamt-of centrally registered ULA prefixes, and = fd00::/8 is fully committed.
 
If SRV6 is important, it could justify = its own prefix.
 
 
   Gyan> As using either = GUA or ULA for SRV6 block provides flexibility for operators, I agree = that SRv6 can justify its own global block as the /16 being allocated = with this draft.  I think we should augment the draft to add a = dedicated ULA bock maybe same /16 size would be reasonable.  Since = there is not an IANA ULA registry since ULA is private, as the = compressed SID violates RFC 4291, I think maybe a draft at least that = defines the dedicated /16 block for ULA for SRV6 use is a good idea.
 
I would caution against use of ULA for = this for a number of reasons, not the least of which is the fact that = ULA is allocated as Brian mentioned prior. A dedicated block solves both = the issue of potential overlap with site specific use of ULA (which = admittedly is probably unlikely), but also creates a clear visual = indicator as well as an easier programmatic implementation by using = something that should never occur elsewhere in the network topology. = Also, using non GUA blocks further complicates inter-domain efforts = which is not a show stopper, but is definitely notable in that SR block = allocation now needs to be coordinated further than internally.  =  
 
 
 
One of the major benefits as I mentioned = for ULA over GUA is that ULA is not internet routable and that mitigates = any possibility of security issues with SRV6 SID leaking to the = internet.
 
This is a legitimate use case, and with = the lack of SRH4 filtering capabilities in platforms I have looked at = (admittedly not everything) this is an operational concern, however, I = suspect that will be addressed and should be part of a best practices = recommendation for anyone not attempting to do inter-domain SRv6 = provisioning regardless of SRv6 SID choices.  It feels a little = like the model of using RFC1918 space as a mechanism to further = "air-gap" the control plane - which I have totally done in the past, so = no judgement - just an observation. Not illegitimate, but definitely = needs a bit of forethought, which in many cases it does not = get. 
As an operator, my = response would be "why not both?". A dedicated block ofnon-ULA space for use when required = / desired and perhaps a bit of verbiage on operational considerations = for filtering at network edges when GUA is in play?  Similar = concerns are covered in section 4.1 but stop short of filtering the = header.***
 
 
 
*** my experience with this is largely = lab-focused and incomplete having only tested a few platforms and = software packages, so I fully admit that I may be missing information or = misunderstanding. IIRC, one platform could filter RH0 and none did = 4.
 
 
Thoughts?
 
Regards,
    Brian Carpenter
    (via tiny screen & keyboard) 
    
 
On Thu, 29 = Sep 2022, 19:45 Gyan Mishra, <hayabusagsm@gmail.com> wrote:
 
 
On Wed, Sep 28, 2022 at = 11:31 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On = 29-Sep-22 16:06, Gyan Mishra wrote:
...

> We should qualify the IANA request to make the /16 non = internet routable identical to ULA addressing.
> 
> If that = is what we desire then why don=E2=80=99t we make it standard BCP to = always use ULA for the operators SRV6 domain.

I don't believe that a /48 would be enough, but it is = required, to conform with RFC4193.
 
    Gyan> Understood.  = Most operators would like to use ULA for SRV6 deployments so do we need = to carve out block out of ULA space just as we are doing for GUA to = conform with RFC 4291.  ULA has is a big enough block FC00::/7 so = we could carve a block out of that.  Does not need to be as large a = block allocation for SIDs as it would not be advertised to the internet = does not require to be globally unique.


    Brian

> We would not have to burn up a /16 unnecessarily.
> 
> 
> Kind Regards
> 
> Gyan
> 
> On Sat, Sep 17, 2022 at 4:00 AM Jen Linkova <furry13@gmail.com <mailto:furry13@gmail.com>> wrote:
> 
>  =    Hello,
> 
>  =    This email starts the 6man Working Group Last Call for the = "Segment
>     Identifiers in SRv6" = draft
>     (https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids&= lt;https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids&= gt;).
> 
>  =    The WGLC ends on Tue, Oct 4, 23:59:59 UTC.
> 
>       As the document is closely = related to the work in the SPRING WG, we'd
>  =    like the SPRING WG to review the document and discuss the = following
>     questions:
> 
>     - the action items required from = SPRING (Section 4.1 and 4.2 of the
>    =  draft, https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids-01#s= ection-4 <https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids-01#s= ection-4>)
>     [*]. Would it = make sense to merge those open issues with the 'Open
>     Issues' section of
>     the SPRING document?
>     -  whether the document needs = more guidance regarding routability of
>    =  /16 or such requirements shall belong to some other = document?  In
>    =  particular,  shall we specify that it MUST NOT be in the DFZ? = Or
>     setting 'Globally Reachable =3D = false' in the registry should be
>    =  sufficient? The current idea is that the prefix needs to fail = closed
>     and not be routable by = default.
> 
>  =    [*] The draft currently refers to the individual submission = instead of
>     https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-com= pression/ <https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-com= pression/>
>       - the = link will be updated in the next revision.
> 
>  =    Please review the draft and send your comments to the = list/
> 
>  =    -- 
>     SY, Jen Linkova aka Furry
> 
>    =  --------------------------------------------------------------------=
>     IETF IPv6 working group mailing = list
>     ipv6@ietf.org <mailto:ipv6@ietf.org>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
>    =  --------------------------------------------------------------------=
> 
> -- 
> 
> <http://www.verizon.com/>> 
> *Gyan Mishra*
> 
> = /Network Solutions A//rchitect /
> 
> = /Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>//
> /
> 
> /M 301 502-1347
> 
> /
> 
> 
> 
> = --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> = --------------------------------------------------------------------
-- 

Gyan Mishra
Network Solutions Architect 
Email gyan.s.mishra@verizon.com

M 301 502-1347

 
--

Gyan = Mishra
Network Solutions Architect 

M= 301 502-1347


 
---------------------------------------------------------------= -----
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative = Requests: https://www.ietf.org/mailman/listinfo/ipv6
---------------------------------------------------------------= -----
=E1=90=A7
=

= --Apple-Mail=_DE5BBAE7-B5A1-4227-8553-BC085A48BF23--