From nobody Fri Jun 11 03:10:10 2021 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 575503A31E0 for ; Fri, 11 Jun 2021 03:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uG-Cki17D9XG for ; Fri, 11 Jun 2021 03:10:02 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CFC03A31E2 for ; Fri, 11 Jun 2021 03:10:02 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id p17so7764972lfc.6 for ; Fri, 11 Jun 2021 03:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0tD9bFXhQOh5w5AzbeKRij5+Ea9Iu7tZugBCFmtIMJY=; b=a2RgeMIZMVdqDS/gxAWXNtPuUGw/tFzX2L7lkCF+4vnn5aWRYoBVshm5LDDclhTJOF 5Ne/cNlTaRrFXOBrFeMSN1n/iiAuS8q0q3Dc5cFznWZR7alOZao5N+zptIWaK3YFyTXe iQb4PzGjdIRd2eqb5L2ju35JHA3hDuhY4NvrWRn24mkktTolh0iSe0AJj+T88hen4Pnl pwtWj7FZcPsgmLoF9E/7BSS7rW+lcZPUc4Lyxuj//U7FsIMmQ9o2/i9PAuPDKuhjNGSO bdyxJ4M2s+8oW5OTT3oP4A2MaZdjZoISDhMV0dBOjtYEIlBROziEhg2ggjm0+ZtuNIq8 ZT6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0tD9bFXhQOh5w5AzbeKRij5+Ea9Iu7tZugBCFmtIMJY=; b=N7TWgtmCnXo6hCAsRjBGoohgv26IOUDSSB/U7buprgjRbE3tKDH4hv45h1HcAf81Hh i+exWEyF4qrnKv0WQb1uZzh2RPpb3meBpEAvfFHMy8ilSG/4Kt/gZw08upNfnsqGbhO0 ju+aPzxk9TJOcLm0y+1smiSjtethZVtYUZZCfkv9kzTXfbLAFy2+WpURGesIURgx6fE7 JXan9Gpgao6VMyGO+D5a4YF8WTcNnAzT5BO7c4BCJU4aTDf9dYtPNcRDpDa8rOg9/sTP jvmng2drsWwBdnnZxvZ0jSRLugAVPLqvvWXPDaIebqe2iEdtLeLP4Xgk9dj4C6/geCTU lfuA== X-Gm-Message-State: AOAM530TjDXEGljjlpCV0Ukrq9Kvb6pzddl39MrtizUUpfn+Dl016u4y fgvMHxi5TnyPrhT5BziP0L/uXcmkhH2hQHdTi+efkw== X-Google-Smtp-Source: ABdhPJxcFbOw0G2ZIb2uc8Yr66K5mPRmECJTBI+fAOW4Y7TrFs6QextDQX0FKPqJ/NoHOEDbHgeajANj54i9cEf38M8= X-Received: by 2002:a05:6512:304b:: with SMTP id b11mr2250975lfb.581.1623406198576; Fri, 11 Jun 2021 03:09:58 -0700 (PDT) MIME-Version: 1.0 References: <162340175034.6148.8928864955067799770@ietfa.amsl.com> In-Reply-To: <162340175034.6148.8928864955067799770@ietfa.amsl.com> From: Robert Raszuk Date: Fri, 11 Jun 2021 12:09:47 +0200 Message-ID: To: Kaliraj Vairavakkalai , minto@juniper.net Cc: "idr@ietf. org" Content-Type: multipart/alternative; boundary="000000000000caef7f05c47ab5fe" Archived-At: Subject: [Idr] Fwd: I-D Action: draft-kaliraj-idr-multinexthop-attribute-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 10:10:08 -0000 --000000000000caef7f05c47ab5fe Content-Type: text/plain; charset="UTF-8" Dear authors, I have read yr draft with interest as some perhaps recall we have discussed this topic in the past number of times. Cosmetics: 1. First nit - why do you say label must be 3107bis label ? (3.4.2. Labeled IP nexthop) MPLS label is a label and I am not sure how one method of label distribution matter here. 2a. What is PNH ? It first occurs in section 3 as "PNH-Len" or "PNH-address", but it is never explained in the draft. Is this Path Next Hop ? 2b. Would it be better to call this new attribute MNH MultiNextHop ? Tech: 3. In section 3.1.1 you describe how to assure that NH in MP_REACH is also part of MultiNext Hop Attribute. But I do not see any discussion on how to treat or ignore next hops in MP_REACH when a new attribute is present and is valid. 4. In section 3.1.2 you define behaviour of RR advertising paths from non MultiNexthop paths and those which carry new attributes ... But you should make it clear that this is only about 9.1.2.2 step in best path selection (or candidate selection). There can be other criteria before we even get to that step. 5. Now the most important question - how do you plan to handle atomic withdraws ? I assume the plan is to readvertise the path with MNH - the removed next hop. So by implicit withdraw this next hop will be removed. The draft is silent on this. Now if the removed next hop was selected by some receivers as best (due to 9.1.2.2) and it was not arriving as part of MP_REACH this proposal require significant implementation changes on how BGP best path selection is triggered, how it runs, how it populates results to the RIB/FIB. I think a new section is needed in detailed discussing the withdraws. 6. How do you envision max-prefix safety knobs to work here ? On the surface it may seem orthogonal - but it is not. Today folks use this to protect infrastructure from for example operator's mistakes. Here one received path may fill the MNH attribute with 100s of next hops and as being optional and transitive will be distributed to all routers all over the world. 7. Observe that metric to next hops is dynamic. So some implementations capable of next hop tracking register with RIB all next hops and each time metric changes they get a call back. Here we are effectively talking about exploding this 10x or 100x or more ... Many thx, Robert ---------- Forwarded message --------- From: Date: Fri, Jun 11, 2021 at 10:56 AM Subject: I-D Action: draft-kaliraj-idr-multinexthop-attribute-01.txt To: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP MultiNexthop attribute Authors : Kaliraj Vairavakkalai Minto Jeyananth Filename : draft-kaliraj-idr-multinexthop-attribute-01.txt Pages : 12 Date : 2021-06-11 Abstract: Today, a BGP speaker can advertise one nexthop for a set of NLRIs in an Update. This nexthop can be encoded in either the BGP-Nexthop attribute (code 3), or inside the MP_REACH attribute (code 14). For cases where multiple nexthops need to be advertised, BGP-Addpath is used. Though Addpath allows basic ability to advertise multiple- nexthops, it does not allow the sender to specify desired relationship between the multiple nexthops being advertised e.g., relative-preference, type of load-balancing. These are local decisions at the receiving speaker based on path-selection between the various additional-paths, which may tie-break on some arbitrary step like Router-Id. Some scenarios with a BGP-free core may benefit from having a mechanism, where egress-node can signal multiple-nexthops along with their relationship to ingress nodes. This document defines a new BGP attribute "MultiNexthop" that can be used for this purpose. This attribute can be used for both labeled and unlabled BGP families. For labeled-families, it is used for a different purpose in "downstream allocation" case than "upstream allocation" scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-multinexthop-attribute-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-kaliraj-idr-multinexthop-attribute-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --000000000000caef7f05c47ab5fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear authors,

I have rea= d yr draft with interest as some perhaps recall we have discussed this topi= c in the past number of times.=C2=A0

Cosmetics:

1. First nit - why do you say label must be 3107bis= =C2=A0label ? (3.4.2.=C2=A0 Labeled IP nexthop) MPLS label is a label and I= am not sure how one method of label distribution matter here.=C2=A0
<= div>
2a. What is PNH ? It first occurs in section 3 as "= PNH-Len" or "PNH-address", but it is never explained=C2=A0in= the draft. Is this Path Next Hop ?=C2=A0

2b. Woul= d it be better to call this new attribute MNH MultiNextHop ?=C2=A0

Tech:=C2=A0

3. In section 3.1.1 y= ou describe how to assure=C2=A0that NH in MP_REACH is also part of MultiNex= t Hop Attribute. But I do not see any discussion on how to treat or ignore = next hops in MP_REACH when a new attribute is present and is valid.=C2=A0

4. In section 3.1.2 you define behaviour of RR adve= rtising=C2=A0paths from non MultiNexthop paths and those which carry new at= tributes ... But you should make it clear that this is only about 9.1.2.2 s= tep in best path selection (or candidate selection). There can be other cri= teria before we even get to that step.=C2=A0

5. No= w the most important question - how do you plan to handle atomic withdraws = ? I assume the plan is to readvertise=C2=A0the path with MNH - the removed = next hop. So by implicit withdraw this next hop will be removed. The draft = is silent on this. Now if the removed next hop was selected by some receive= rs as best (due to 9.1.2.2) and it was not arriving as part of MP_REACH thi= s proposal require significant implementation changes on how BGP best path = selection is triggered, how it runs, how it populates results to the RIB/FI= B. I think a new section is needed in detailed discussing the withdraws.

6. How do you envision max-prefix safety knobs to wo= rk here ? On the surface it may seem orthogonal - but it is not. Today folk= s use this to protect infrastructure from for example operator's mistak= es. Here one received path may fill the MNH attribute with 100s of next hop= s and as being optional and transitive will be distributed to all routers a= ll over the world.=C2=A0

7. Observe that metric to= next hops is dynamic. So some implementations capable of next hop tracking= register with RIB all next hops and each time metric changes they get a ca= ll back. Here we are effectively talking about exploding this 10x or 100x o= r more ...=C2=A0

Many thx,
Robert
<= div>

---------- Forwarded message ---------
From: = <internet-drafts@ietf.org>
Date: Fri, Jun 11, 2021 at 10:56 AM
Subject: I-D Action:= draft-kaliraj-idr-multinexthop-attribute-01.txt
To: <i-d-announce@ietf.org>


<= br> A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= BGP MultiNexthop attribute
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Kali= raj Vairavakkalai
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Minto Jeyananth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-kal= iraj-idr-multinexthop-attribute-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 12
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-06-11

Abstract:
=C2=A0 =C2=A0Today, a BGP speaker can advertise one nexthop for a set of NL= RIs in
=C2=A0 =C2=A0an Update.=C2=A0 This nexthop can be encoded in either the BGP= -Nexthop
=C2=A0 =C2=A0attribute (code 3), or inside the MP_REACH attribute (code 14)= .

=C2=A0 =C2=A0For cases where multiple nexthops need to be advertised, BGP-A= ddpath
=C2=A0 =C2=A0is used.=C2=A0 Though Addpath allows basic ability to advertis= e multiple-
=C2=A0 =C2=A0nexthops, it does not allow the sender to specify desired
=C2=A0 =C2=A0relationship between the multiple nexthops being advertised e.= g.,
=C2=A0 =C2=A0relative-preference, type of load-balancing.=C2=A0 These are l= ocal
=C2=A0 =C2=A0decisions at the receiving speaker based on path-selection bet= ween
=C2=A0 =C2=A0the various additional-paths, which may tie-break on some arbi= trary
=C2=A0 =C2=A0step like Router-Id.

=C2=A0 =C2=A0Some scenarios with a BGP-free core may benefit from having a<= br> =C2=A0 =C2=A0mechanism, where egress-node can signal multiple-nexthops alon= g with
=C2=A0 =C2=A0their relationship to ingress nodes.=C2=A0 This document defin= es a new BGP
=C2=A0 =C2=A0attribute "MultiNexthop" that can be used for this p= urpose.

=C2=A0 =C2=A0This attribute can be used for both labeled and unlabled BGP =C2=A0 =C2=A0families.=C2=A0 For labeled-families, it is used for a differe= nt purpose
=C2=A0 =C2=A0in "downstream allocation" case than "upstream = allocation" scenarios.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.o= rg/doc/draft-kaliraj-idr-multinexthop-attribute/

There is also an htmlized version available at:
https://datatracker= .ietf.org/doc/html/draft-kaliraj-idr-multinexthop-attribute-01

A diff from the previous version is available at:
https://www.ietf.org/= rfcdiff?url2=3Ddraft-kaliraj-idr-multinexthop-attribute-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--000000000000caef7f05c47ab5fe--