From nobody Mon Mar 13 12:10:50 2023 Return-Path: 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 47D77C16B5AD; Mon, 13 Mar 2023 12:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 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, HTTPS_HTTP_MISMATCH=0.1, 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 fas3caQnxUI3; Mon, 13 Mar 2023 12:10:45 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 79ECAC13632C; Mon, 13 Mar 2023 12:10:12 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id bd34so8308278pfb.3; Mon, 13 Mar 2023 12:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678734612; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yvkvKC28c+Cn+TnkoMTuMvko+VLR8TtztDidK3YVHeU=; b=onzIG7z4Gm8+xt5SVQZYrEBC3ScB9bNHDJoTKLI19JlCxOPt1UPrPXwJQ8xSsqNof1 l7Hw/mTq/eRLPWgkRUkmojjYy8jX7GoDcdraBa5mM6QC/AJUOsMFWmq5V/eP2eBiiRVi 550k8jewJDrcoUuCu5SBnHGiaK8PC8d4u/pp2w7Wfi2Gf/tIVOa0FD06lNFdAxEh9Db7 UNY00SaYNK8P/OsOn81i9d5oPerfqBncjSyR7avXR7a5nfyZ3KIRH3Qi5LS4/J+CamiM HJR+/IlySITFCRfiQg1kp0wxSpi9bOH7QYX1e5GNAODIL8ZyTntiGEZFpw+a/J8t+s8R mw3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678734612; 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=yvkvKC28c+Cn+TnkoMTuMvko+VLR8TtztDidK3YVHeU=; b=aJtM8IzHujbDn7OdT8hnfg1IEw8xfFi/7rCS06qD+OqGMIrEAP9jHkYLl/J+AaxLPh N82GqdK5+QyMQOvWl1rVf8jaYm+YMAT+SbjoPGjYPIn64E0/biaOYQUtfth4ORFBrow/ 1anKRHdlsACGia3OTZ7dA9BDniM9lojdPZE2n/ZZKqkGzju2u0LmVILiRPtC/Gr9cC7T yUmWzWXrRZ2YejU+Bqtt0yd9elbEjWg+guP+B5V65B0cS9o+NCnZWVhjlNXEM0ocSwOY z7Bc1ggRckHrLwQjtNGfdC7QhLrwedD5F7X3w6CsmCePam9CTJRJGpxYuocsLP/Z2Qud yPAA== X-Gm-Message-State: AO0yUKWIAt1XCmc3E/6urHZQbLr0ksjpy79qfYZgMTr/RYyVBzFCSGgr 4gN362iffvYS0wBvjRK+2NE+GuI3+Gsd2LmLJVs= X-Google-Smtp-Source: AK7set/FcM1kPe26eWLu5U8Ltu3Y7aROcF1vvOpaw1KlTyxjc0Qed1ye6rEmfQ79hihpu/LLVs/Yd8XDjcC/zPIH7ag= X-Received: by 2002:a62:1c13:0:b0:622:c6ad:b373 with SMTP id c19-20020a621c13000000b00622c6adb373mr2558302pfc.3.1678734611864; Mon, 13 Mar 2023 12:10:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Igor Malyushkin Date: Mon, 13 Mar 2023 23:10:00 +0400 Message-ID: To: "UTTARO, JAMES" Cc: Robert Raszuk , Alvaro Retana , "idr@ietf.org" , "draft-uttaro-idr-bgp-oad@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003665fd05f6ccdcd5" Archived-At: Subject: Re: [Idr] One Administrative Domain using BGP (Fwd: I-D Action: draft-uttaro-idr-bgp-oad-00.txt) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2023 19:10:49 -0000 --0000000000003665fd05f6ccdcd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable James, Looks like my reading of the document wasn't careful enough. Despite from one point of view collapsing all OAD's ASN into a single on the edge may solve some problems, I don't think that's a good idea. At first, I wasn't sure about the intention of this draft on this point. So there aren't any limiting concerns from my side now. =D0=BF=D0=BD, 13 =D0=BC=D0=B0=D1=80. 2023=E2=80=AF=D0=B3. =D0=B2 23:02, UTT= ARO, JAMES : > *Igor,* > > > > * We still have all the ASNs today. Are you suggesting we > collapse them all into one AS ? There are significant obstacles to going = in > that direction.. Not sure I understand the concern is there a limit that > you are suggesting? What is the pain point(s)?* > > > > *Thanks,* > > * Jim Uttaro* > > > > *From:* Igor Malyushkin > *Sent:* Monday, March 13, 2023 1:17 PM > *To:* UTTARO, JAMES > *Cc:* Robert Raszuk ; Alvaro Retana < > alvaro.retana@futurewei.com>; idr@ietf.org; > draft-uttaro-idr-bgp-oad@ietf.org > *Subject:* Re: [Idr] One Administrative Domain using BGP (Fwd: I-D > Action: draft-uttaro-idr-bgp-oad-00.txt) > > > > Hi folks, > > Another sad outcome of having multiple ASes united into a single > administrative domain is a longer AS_PATH which includes all OAD ASNs. On > the one hand, it's perilous to crop arbitrary ASN from the AS_PATH, but o= n > the other hand, sometimes longer AS_PATH values cause a lot of pain. > > > > =D0=BF=D0=BD, 13 =D0=BC=D0=B0=D1=80. 2023=E2=80=AF=D0=B3. =D0=B2 21:06, U= TTARO, JAMES : > > *Robert, * > > > > *eBGP-OAD sessions would by default propagate all non-transitive > attributes that exist and ones created in the future. As operators we wi= ll > decide which ones we would like to see disseminated across our > administrative domains.. * > > > > *Thanks,* > > * Jim Uttaro* > > *From:* Robert Raszuk > *Sent:* Monday, March 13, 2023 12:51 PM > *To:* Alvaro Retana > *Cc:* idr@ietf.org; draft-uttaro-idr-bgp-oad@ietf.org > *Subject:* Re: [Idr] One Administrative Domain using BGP (Fwd: I-D > Action: draft-uttaro-idr-bgp-oad-00.txt) > > > > Hi, > > > > Not sure what you mean by "allow all". Some BGP attributes are only for > IBGP and some only for EBGP. With that what does it mean > considering future protocol extensions ? > > > > Thx, > > R. > > > > On Mon, Mar 13, 2023 at 5:40=E2=80=AFPM Alvaro Retana > wrote: > > On March 13, 2023 at 12:09:26 PM, Robert Raszuk wrote: > > > Robert: > > Hi! > > > Today a lot of implementations already support features like > > next-hop-unchanged on EBGP, or AIGP attribute etc ... > > > > Would it not be just much cleaner to enumerate explicitly those feature= s > on > > today's EBGP sessions between ASNs under the same administrative domain= s > ? > > > > Practical aspect is that while you can define the expected behaviour of > OAD > > session today - but tomorrow we will likely introduce more BGP protocol= s > > extensions which will not going to be reflected in this OAD document. S= o > it is > > going to be really hard to keep track on what sides really intend to do > when > > declaring on their edge OAD session type. > > > > IMHO explicitly enabling exceptions for plane EBGP sessions will be far > more > > practical approach. > > The intent is for the EBGP-OAD session to "allow all" so that as new > extensions are introduces we don't need to update the document. ;-) For > specific applications an operator may want to only propagate certain > extensions -- that can be controlled through policy. > > Any exceptions or different behavior to be called out in the draft should > be for specific items only. > > > There are possibly multiple ways to obtain the same (or similar) outcome. > :-) > > Thanks! > > Alvaro. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > --0000000000003665fd05f6ccdcd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
James,

Looks like my reading of the document wasn&#= 39;t careful enough. Despite from one point=C2=A0of view collapsing all OAD= 's ASN into a single on the edge may solve some problems, I don't t= hink=C2=A0that's a good idea. At first, I wasn't sure about the int= ention of this draft on this point. So there aren't any limiting concer= ns from my side now.

=D0=BF=D0=BD, 13 =D0=BC=D0=B0=D1=80. 2023=E2=80=AF= =D0=B3. =D0=B2 23:02, UTTARO, JAMES <j= u1738@att.com>:

Igor,

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 We still have al= l the ASNs today. Are you suggesting we collapse them all into one AS ? The= re are significant obstacles to going in that direction.. Not sure I unders= tand the concern is there a limit that you are suggesting? What is the pain point(s)?

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Jim Uttaro

=C2=A0

From: Igor Malyushkin <gmalyushkin@gmail.com>
Sent: Monday, March 13, 2023 1:17 PM
To: UTTARO, JAMES <ju1738@att.com>
Cc: Robert Raszuk <robert@raszuk.net>; Alvaro Retana <alvaro.retana@futurewei.com= >; idr@ietf.org; <= a href=3D"mailto:draft-uttaro-idr-bgp-oad@ietf.org" target=3D"_blank">draft= -uttaro-idr-bgp-oad@ietf.org
Subject: Re: [Idr] One Administrative Domain using BGP (Fwd: I-D Act= ion: draft-uttaro-idr-bgp-oad-00.txt)

=C2=A0

Hi folks,

Another sad outcome of having multiple ASes united into a single administra= tive domain is a longer AS_PATH which includes all OAD ASNs. On the one han= d, it's perilous to crop arbitrary ASN from the AS_PATH, but on the oth= er hand, sometimes longer AS_PATH values cause a lot of pain.

=C2=A0

=D0=BF=D0=BD, 13 =D0=BC=D0=B0=D1=80. 2023=E2=80=AF= =D0=B3. =D0=B2 21:06, UTTARO, JAMES <ju1738@att.com>:

Robert,

=C2=A0

eBGP-OAD sessions w= ould by default propagate all non-transitive attributes that exist and ones= created in the future.=C2=A0 As operators we will decide which ones we wou= ld like to see disseminated across our administrative domains..

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Jim Uttaro

From: Robert Raszuk <robert@raszuk.net>
Sent: Monday, March 13, 2023 12:51 PM
To: Alvaro Retana <alvaro.retana@futurewei.com>
Cc: idr@ietf.org; draft-uttaro-idr-bgp-oad@ietf.org
Subject: Re: [Idr] One Administrative Domain using BGP (Fwd: I-D Act= ion: draft-uttaro-idr-bgp-oad-00.txt)

=C2=A0

Hi,

=C2=A0

Not sure what you=C2=A0mean by "allow all"= . Some BGP attributes=C2=A0are only for IBGP and some only for EBGP. With t= hat what does it mean considering=C2=A0future=C2=A0protocol extensions ?=

=C2=A0

Thx,

R.

=C2=A0

On Mon, Mar 13, 2023 at 5:40=E2=80=AFPM Alvaro Retan= a <alva= ro.retana@futurewei.com> wrote:

On March 13, 2023 at 12:09:26 PM, Robert Raszuk wrot= e:


Robert:

Hi!

> Today a lot of implementations already support features like
> next-hop-unchanged on EBGP, or AIGP attribute etc ...
>
> Would it not be just much cleaner to enumerate explicitly those featur= es on
> today's EBGP sessions between ASNs under the same administrative d= omains ?
>
> Practical aspect is that while you can define the expected behaviour o= f OAD
> session today - but tomorrow we will likely introduce more BGP protoco= ls
> extensions which will not going to be reflected in this OAD document. = So it is
> going to be really hard to keep track on what sides really intend to d= o when
> declaring on their edge OAD session type.
>
> IMHO explicitly enabling exceptions for plane EBGP sessions will be fa= r more
> practical approach.

The intent is for the EBGP-OAD session to "allow all" so that as = new extensions are introduces we don't need to update the document. ;-)= =C2=A0For specific applications an operator may want to only propagate cer= tain extensions -- that can be controlled through policy.=C2=A0

Any exceptions or different behavior to be called out in the draft should b= e for specific items only.


There are possibly multiple ways to obtain the same (or similar) outcome. := -)

Thanks!

Alvaro.=C2=A0

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/lis= tinfo/idr

--0000000000003665fd05f6ccdcd5--