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

Mach Chen <> Sat, 18 April 2020 03:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5DB9D3A0E96; Fri, 17 Apr 2020 20:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iBMLjrgsvIn3; Fri, 17 Apr 2020 20:30:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 914D13A0E8D; Fri, 17 Apr 2020 20:30:12 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 4711F62EAC16074CE84A; Sat, 18 Apr 2020 04:30:10 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.487.0; Sat, 18 Apr 2020 04:30:09 +0100
Received: from ([]) by ([]) with mapi id 14.03.0487.000; Sat, 18 Apr 2020 11:30:03 +0800
From: Mach Chen <>
To: Alvaro Retana <>, "<>" <>
CC: "" <>, IDR List <>, "" <>
Thread-Topic: RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt
Thread-Index: AdYUgufIha3uMI7HSMyOkGGdwgKyaQANmQuAABrRsaA=
Date: Sat, 18 Apr 2020 03:30:02 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE80dggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt
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: Sat, 18 Apr 2020 03:30:22 -0000

Hi Alvaro,

Technically, according to Table 2 of RFC 7752, the source of BGP-LS information can be from IGP, Direct or Static configuration. And the rules in question are not specified in the IGP RFCs, I personally think they are essential. It’s pity that we did not catch it when progressing those RFCs. I do agree this document may not be the perfect place to specify  those rules, but with the current situation, to write down something here is better than do nothing.

Best regards,

From: Alvaro Retana []
Sent: Saturday, April 18, 2020 5:09 AM
To: <> <>; Mach Chen <>
Cc:; IDR List <>;
Subject: Re: RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt


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!


On April 17, 2020 at 3:38:55 AM, Mach Chen (<>) 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.