Re: [Idr] 答复: draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Jeff Tantsura <> Fri, 10 May 2019 19:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C65391200C1; Fri, 10 May 2019 12:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NfVXCXkSx8wJ; Fri, 10 May 2019 12:28:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8814512006D; Fri, 10 May 2019 12:28:35 -0700 (PDT)
Received: by with SMTP id y3so3279183plp.0; Fri, 10 May 2019 12:28:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=UvoGv8Fs9Kgj4CDzzb6MUZ6jiG2MvzF9dgQbP96RB3E=; b=OPuYWHa4K/QmcXxtSMQG2CdIJ3AdT4uZCdzqyEe0xa7EfRzlIjuSWGZD2eYqZjU63s PTdT2urlrKyEt1s4ckxBGPZrIUdgGr2o0IdtiYMLVDMZi42e6rg00Zkro5hVsFKu2CiJ ZoE5zwU4cG6AuLIcuVSYCwZKE/OhcsEDb2iqxSuRzDvKUsqW+R2HnukUeJDn+7C5QF+k 7amOtG1WtsOzuxmo/v291upjqsyq4zGXPlaB2EhCF5F8GnQkLN9xPqXkakOsjK1M664W qfW7UnXQqt+FMRHwwOCevZ37WCTAozTfOplPdz1Sq+jrRizCAQPUGnwi425T0/sYkdLT bz8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=UvoGv8Fs9Kgj4CDzzb6MUZ6jiG2MvzF9dgQbP96RB3E=; b=LURV1ok+p8tLaEtHkA5z1DmBIp0ZUBXvgwZki9DEFDzD8X4pPisMNMy/WExmBVIZnU SMjwZqan7b/OyCZAxy5sOdiYkDjxZ3AUBO07jsHvAQXpp3OgHfXfxDR4F4ac2A4XS5dz F2UiWAB0C//MU7c5wbOYS902PomgRMcHeE792Nsj3vPintmexCJ7KW7IQ8wSApR3vuSN 09eV6F70MtoSNNbXRFXT6ZINMch8Hw763/n41VFwduaiSMZ6l1Cs7QztjKikABcwv0Cz s4ElrcS8HxyYVUMMvKPTtdqyr8XzCoHaZjACqfNLvdStWKw3/XLsHuGt5znQUNBTfqD9 LG6g==
X-Gm-Message-State: APjAAAUmBthdYRvXTNTnwu02jUnuQme61byxsv9Q0WUMGnmzBCLxPUQF vXR6xMr0uUtlBTArXTJFWf0=
X-Google-Smtp-Source: APXvYqxVHTyEjOqhNZYvizdWGc0xVxeAqpvc2643F58WKS6wFvUIrK5EiUYRXM3IeL/J2b9CLM2nJg==
X-Received: by 2002:a17:902:4643:: with SMTP id o61mr14992819pld.95.1557516514969; Fri, 10 May 2019 12:28:34 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id z19sm7038666pgk.28.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 May 2019 12:28:34 -0700 (PDT)
Date: Fri, 10 May 2019 12:28:27 -0700
From: Jeff Tantsura <>
To: Lizhenbin <>, li zhenqiang <>, Susan Hares <>,, "Acee Lindem (acee)" <>, Aijun Wang <>
Cc: draft-ietf-teas-enhanced-vpn <>, draft-dong-lsr-sr-enhanced-vpn <>
Message-ID: <6a0f8fa0-ea00-49af-a292-92dc002dca8b@Spark>
In-Reply-To: <007701d50603$deeeacf0$9ccc06d0$>
References: <013301d4f5ef$b1b51310$151f3930$> <> <> <> <1f9be143-eeb5-4385-9ec3-392581f05a59@Spark> <007701d50603$deeeacf0$9ccc06d0$>
X-Readdle-Message-ID: 6a0f8fa0-ea00-49af-a292-92dc002dca8b@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5cd5d0e0_23f9c13c_4d59"
Archived-At: <>
Subject: Re: [Idr] 答复: draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call
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, 10 May 2019 19:28:39 -0000

Hi Aijun,

philosophical part:
"As protocol designers, before we propose any changes/additions(increasing complexity), we should always do trade-off analysis (and if you haven’t found any, you haven’t looked well enough :)) that should include full life cycle of the change you are proposing, in context of the draft discussed, at least - configuration/operation/decommission."

To also bring the comparison with draft-ietf-idr-segment-routing-te-policy.
There’s fundamental difference of what the 2 drafts are proposing
draft-ietf-idr-segment-routing-te-policy is used to distribute policies that augment reachabiity, which is clearly day 2 operation, creates ephemeral state and is reasonably in scope of BGP
draft-wu-idr-bgp-segment-allocation-ext is used to configure devices, which is clearly a day 0 operation and hence creates operational state, which is IMO is very much out of scope.
How do you verify that operational state is the intended one (configurational), e.g. SIDs distributed are accepted, instantiated, installed, etc? How do you remove/change the state?
What happens on reload?

On May 8, 2019, 6:09 PM -0700, Aijun Wang <>, wrote:
> Hi, Jeff:
> Actually, it is more acceptable to use BGP-LS to report the topology info and use the PCEP to do the control work. But as described in this draft, there are situations that the network deployed only the BGP, then this draft wants to find some solution to these scenarios.  I think such capability is supplementary to the portfolio of provisioning tools.
> We have ever paid more attention to the NETCONF/YANG for the configuration work. But as I knew, the implementations of these standardization YANGs are not as ideal as we have imaged.  The TLV extensions mechanism may be more optimistic to fulfill the newly requirements, as that done in IGP, BGP and PCEP.
> Best Regards.
> Aijun Wang
> Network R&D and Operation Support Department
> China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
> 发件人: Jeff Tantsura []
> 发送时间: 2019年5月9日 2:24
> 收件人: Lizhenbin; li zhenqiang; Susan Hares;; Acee Lindem (acee)
> 抄送: draft-ietf-teas-enhanced-vpn; draft-dong-lsr-sr-enhanced-vpn
> 主题: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call
> Hi,
> We shouldn’t be doing things just because we can...
> Can we use BGP-LS for provisioning? - yes, we can.. Should we?  - We better not to, BGP is not a suitable technology to do the work proposed, it doesn’t have proper feedback mechanics built in and can’t semantically validate the change made (as the opposite of for example PCEP). There’s quite some difference between distribution of: reachability (primarily job of BGP), policies (BGP does this opportunistically) and configuration (BGP is wrong tool).
> In general - management plane is a much more suitable way to do so, netconf as an example.
> To Acee’s point - life cycle management becomes an issue, operational/derived states inconstancies at scale are not easy to troubleshoot, and without single source of truth simply impossible.
> Cheers,
> Jeff
> On May 7, 2019, 7:03 AM -0700, Acee Lindem (acee) <>, wrote:
> Hi Robin, Huaimo,
> I agree that it is possible to use BGP-LS to provision these SIDs spaces. In the case of the Flow-Spec and SR TE Policy Address Families, these AFs were conceived for the purpose of dynamic provisioning. Now, if we are going to expand the original purpose of BGP-LS to include provisioning, we should have some compelling technical reasons to repurpose it. One reason not to do it is that it adds yet another source of truth for configuration.  With each source one adds more complexity to the implementations.
> As Ketan commented, you will need to define the life the SID allocation relative to both the BGP-LS session and the network device state. For example, is it ephemeral similar to the I2RS data store? You could reference Sue’s presentation on the preference of Flow-Spec data from multiple sources as a good example.
> Thanks,
> Acee
> From: Idr <> on behalf of Robin Li <>
> Date: Sunday, May 5, 2019 at 9:37 PM
> To: li zhenqiang <>, Susan Hares <>, IDR List <>
> Cc: draft-ietf-teas-enhanced-vpn <>, draft-dong-lsr-sr-enhanced-vpn <>
> Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call
> Hi Zhenqiang,
> Please refer to my reply inline.
> Best Regards,
> Zhenbin (Robin)
> From: Idr [] On Behalf Of li zhenqiang
> Sent: Wednesday, April 24, 2019 3:51 PM
> To: Susan Hares <>;
> Cc: draft-ietf-teas-enhanced-vpn <>; draft-dong-lsr-sr-enhanced-vpn <>
> Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call
> Hi Sue and All,
> Zhenqiang Li from China Mobile.
> I see the value to allocate SIDs in a centralized way, especially for the SIDs representing network resources as proposed in and
> However, I want to know why BGP-LS is chosen to to complete this work, not PCEP or netconf? BGP-LS is mainly used to collect information from network, other than configure network from a controller.
> [Robin]
> 1. To be honest, there is much concern about the standardization process, inter-operability, performance on Netconf/YANG. It is necessary to think about the other option. Just like topology collection, there existed the way to use SNMP/MIB or Netconf/YANG to collect topology info from the network, later BGP-LS was proposed.
> 2. There is already PCE work to allocate SID in the centralized way (Refer to PCECC work proposed by But there truly exists the BGP-only scenarios. It is difficult to introduce one more control protocol which may increase the complexity of network operation and maintenance. That is the reason why we introduced the BGP extension to allocate SID which also can reduce the possible complexity.
> 3. For the possible methods of BGP extensions for the purpose, there can be other way such as introducing a new AFI/SAFI, etc. But we think the BGP-LS extension may be the easiest way. Since BGP-LS can collect info of all kinds of SIDs from the network devices to the controller, it is only to define a TLV/Sub-TLV to indicate the SID allocation from the controller to the network devices. All the existing TLV/Sub-TLV using by BGP-LS will be reused without any change. If use other ways, there has to define some new TLVs/Sub-TLVs or the transition from the corresponding BGP-LS TLV/Sub-TLVs to the new TLVs/Sub-TLVs. But the option is open. We would like to solicit comments from BGPers.
> Best Regards,
> Zhenqiang Li
> >
> > From: Susan Hares
> > Date: 2019-04-18 22:04
> > To:
> > Subject: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call
> > This begins a 2 week WG Adoption call for draft-wu-idr-bgp-segment-allocation-ext-02.txt.  You can access the draft at:
> >
> >
> >
> > In your comments, consider:
> >
> > 1)      Does this draft mechanisms for  extending BGP-LS to provide IDs for allocation provide a beneficial addition to BGP mechanisms for segment routing?
> > 2)      Is the mechanism well-formed enough to adopted as a WG draft?
> > 3)      Do you see any problems with using these IDs for flow redirection?
> > 4)      Do you support extending BGP-LS?
> > 5)      Should we provide an early allocation for this technology?
> > 6)      Do you know of any early implementations?
> >
> > By answering these questions during WG Adoption call, you will help John and I determine what issues need to be considered prior to finalizing this WG draft.    Your answer will help us increase the speed of processing BGP-LS drafts.
> >
> > If enough people indicate that they wish an early allocation upon adoption, I will then send this early allocation to Alvaro.
> >
> > Sue Hares
> >
> > PS – I’m trying new methods of WG adoption calls to help speed up the process in IDR WG.   Please send any thoughts on these new methods to me or John.
> _______________________________________________
> Idr mailing list