IETF Logo Mail Archive

Re: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt

Alvaro Retana <aretana.ietf@gmail.com> Fri, 17 April 2020 21:08 UTC

Return-Path: <aretana.ietf@gmail.com>
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 E0F863A060A; Fri, 17 Apr 2020 14:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=gmail.com
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 8SnbYdt9r-MC; Fri, 17 Apr 2020 14:08:38 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 397A33A05A4; Fri, 17 Apr 2020 14:08:37 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id k13so3392673wrw.7; Fri, 17 Apr 2020 14:08:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=AInDLumEJ9y9QQtm9TXTH7Bw0lLekZp1HhrVq+V7Y/c=; b=pqr/FmlLHFi6kiDnXW3XOAJeqidDBWCpgZVkDRA/5XPv+jqrFJVnw4zxiCJv3tqJFz B0KL34JQJ/wY08T7OKAHuwkbkGdCe4wgwCaDrtMo/AxcWrpMyzKe48AG3byMWkWGtH+i I6IpKy5eUuY2PzaLmylg/DULvW7re8RViE+4OohyToxFvEQP7aNDxgZHaY3GG6DkgbAi nPzWSz7A0VC0kSfRwP0Ph6eph8DPQX/WWNzDvZcz/MNwjkNOtB+Ifhmn5cS8V9irB9rU eE8NF1M/bbdtQaHCdrYWYJinBg0FbexrhA2w5c1twJ/B1vqdz7IosHlWj967B1Sh/zdk 3ftw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=AInDLumEJ9y9QQtm9TXTH7Bw0lLekZp1HhrVq+V7Y/c=; b=G5l3Igp2rivf+zeXBFdFZ5csHPapq0Ols4jQCycrkXgK648VkhAeo4KIjoihTbyW3w 89SarDUZmGkvD2PWZ7qFvVFUKvxkjnGrNddE6JfoJwJPPyu6HyMKCEAy+iINJ09FMVvq d4aUyaiuSNPBKd8F/ufPVt95J3A2rzYY8c9csyiafdjj8m+o6mpc+vgaLAC/TLi/L2cu 234jGU1CMJlFPcM8IK9Nug2C0a/wRXfIf3+1IW/OwnJL8v8B7nVmeB2zkMzVhZQkLe6V 1yYNHb1ikliDVMP5nNMIGyUt4hZTOkzSUykwfpQM89D2OFXNASWLzpvmC3v5TdaNKtZ3 /Sbw==
X-Gm-Message-State: AGi0PubY2T1BHeLxFAfGKdg7Yd1DZVQDsN4Dn/KxUq31+/3jySL0MdZz t0AcEEC/ng221kJ9QYSvPmTC+GKeQZGQ3WuOKywCsCjT
X-Google-Smtp-Source: APiQypI+5varLGUWVnL8mi3qqJL0x+wQ0KHAVl/yF80w6HVSZWbPw2ZlaggFdre+6IcDOeBGupaM8kgljSUhyEUEobk=
X-Received: by 2002:a5d:65c4:: with SMTP id e4mr5416059wrw.147.1587157714495; Fri, 17 Apr 2020 14:08:34 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 17 Apr 2020 14:08:33 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AAB4AB@dggeml510-mbx.china.huawei.com>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AAB4AB@dggeml510-mbx.china.huawei.com>
MIME-Version: 1.0
Date: Fri, 17 Apr 2020 14:08:33 -0700
Message-ID: <CAMMESsxTnqRBBh13+n0UgQ5oMgd729Rd-RdEZ1mnM5eb0XduFA@mail.gmail.com>
To: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, Mach Chen <mach.chen@huawei.com>
Cc: "draft-ietf-idr-bgp-ls-segment-routing-msd.all@ietf.org" <draft-ietf-idr-bgp-ls-segment-routing-msd.all@ietf.org>, IDR List <idr@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c6706205a382f366"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ogu2bwf8CrGO9b2HkZWGNUIFBuw>
Subject: Re: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Apr 2020 21:08:44 -0000

Mach:

Hi!  How are you?

Thanks for the review!!

Keep in mind that BGP-LS simply transports the information from the IGPs,
so the ability to carry multiple instances/multiple values depends on the
specification of the MSD itself, and any rules in the corresponding IGP
RFCs.  IOW, specifying that behavior for BGP-LS in this document is not
needed.


Take care!

Alvaro.

On April 17, 2020 at 3:38:55 AM, Mach Chen (mach.chen@huawei.com) wrote:

Minor Issues:
The Node MSD TLV and Link MSD TLV are designed to be able to carry multiple
MSDs. I guess this is designed for future extensibility, where a Node may
have multiple types of MSD, right? But for each type, is it allowed to
carry multiple instances of MSD-Type/MSD-Value pair or only one instance?
For whichever case, there need some text to describe the rule about the
sending and receiving procedures. For example, when multiple instances
allowed, how does a node decide which instance takes effect; if only one
instance allowed and multiple instances received, how to handle this,
discard the whole TLV, or only the first instance takes effect and the rest
ignored.

v2.23.0 | Report a Bug | By Email