Re: [Idr] draft-vandevelde-idr-bgp-ls-segment-routing-rld-03 - 2 week WG Adoption call (6/14 to 6/28)

guntervandeveldecc@icloud.com Thu, 15 June 2017 09:09 UTC

Return-Path: <guntervandeveldecc@icloud.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 363AB129BBE; Thu, 15 Jun 2017 02:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.499
X-Spam-Level:
X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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=icloud.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 ANz5fYygkdSQ; Thu, 15 Jun 2017 02:09:32 -0700 (PDT)
Received: from pv33p00im-asmtp003.me.com (pv33p00im-asmtp003.me.com [17.142.194.252]) (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 194DF129BBD; Thu, 15 Jun 2017 02:09:32 -0700 (PDT)
Received: from process-dkim-sign-daemon.pv33p00im-asmtp003.me.com by pv33p00im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0ORK00100ZSQY800@pv33p00im-asmtp003.me.com>; Thu, 15 Jun 2017 09:09:30 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1497517769; bh=apwhoKoLA2StTTHDzvodbyqu5cHSHJTHjJkd/cjPXMQ=; h=Date:From:To:Message-id:Subject:MIME-version:Content-type; b=UYi5SsBz5kYKqWYweKuAVbU8p2uXOBMQnjM4w3C9UJlwJMLDOt3XwNXVLdtCyIS0T 9Y+9bOKsoRagILXcXzstV6hSKCdHBm+MTOdS8ps1qlGD9+farkFvYPSuEl8AFmz6EG YK2qk5rpI1x1A3zIk5bi2Nfz2k6teS30DQIm6GKDlyT9tG0caYhtyJV6VWCnX4hOUo I7fIBb8luNhSRIoWpUJx5vxFHTLvDEPEeCbyE1p7fxsd9y1xeN4HNCsw4n+26jTlhX lUHC9KQRcOrdSuA49rm1CwLy5rtcr3EUIapJkWids7/jKwuZaDTN62DLEuiM1xNiYi rpG6j4SqpA5Jg==
Received: from icloud.com ([127.0.0.1]) by pv33p00im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0ORL00PHV03L5F10@pv33p00im-asmtp003.me.com>; Thu, 15 Jun 2017 09:09:25 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-15_03:,, signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1706150161
Date: Thu, 15 Jun 2017 09:09:21 +0000
From: guntervandeveldecc@icloud.com
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, Susan Hares <shares@ndzh.com>, 'idr wg' <idr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: idr-chairs@ietf.org, draft-vandevelde-idr-bgp-ls-segment-routing-rld@ietf.org
Message-id: <246E99BEEE5D0AE6.c378463c-77b3-4e66-8f14-ed8fecc1fa6e@mail.outlook.com>
In-reply-to: <A7DCB7ED-DB66-46B6-BA03-5A3E0A2DBD6F@gmail.com>
References: <01aa01d2e56d$2f177c70$8d467550$@ndzh.com> <a0f4c81cc456435398a26fca5a830e96@XCH-ALN-008.cisco.com> <A7DCB7ED-DB66-46B6-BA03-5A3E0A2DBD6F@gmail.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="----=_Part_782_1997784981.1497517761110"
X-Mailer: Outlook for iOS and Android
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/fYaogQONBAQqVQh68opvjHGPUSQ>
Subject: Re: [Idr] draft-vandevelde-idr-bgp-ls-segment-routing-rld-03 - 2 week WG Adoption call (6/14 to 6/28)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 15 Jun 2017 09:09:34 -0000

Indeed, i feel no big issue in merging the documents... the question i do ask myself is that for IGP (for both ospf and isis) there is an individual draft to signal MSD and another for RLD... i feel that for consistency maybe 2 documents for BGP seem also logical. However i'm not that strongly against merging the documents either.




If we do decide for a merger of documents then lets maybe not call it either MSD or RLD as that will be confusing to people that read the IGP documents... Maybe something as SDS (Segment Depth Signaling) makes more sense? Small change to reduce confusion and  provides potential future extensibility if needed).




G/




Get Outlook for Android







From: Jeff Tantsura


Sent: Thursday, June 15, 10:50


Subject: Re: [Idr] draft-vandevelde-idr-bgp-ls-segment-routing-rld-03 - 2 week WG Adoption call (6/14 to 6/28)


To: Ketan Talaulikar (ketant), Susan Hares, 'idr wg'


Cc: idr-chairs@ietf.org, draft-vandevelde-idr-bgp-ls-segment-routing-rld@ietf.org






Ketan,




 




I’m of the same opinion, wrt IGP’s – RLD has been there for quite some time already: draft-ietf-(ospf|isis)-mpls-elc




 




Cheers,




Jeff




From: Idr <idr-bounces@ietf.org> on behalf of "Ketan Talaulikar (ketant)" <ketant@cisco.com>


Date: Wednesday, June 14, 2017 at 20:32


To: Susan Hares <shares@ndzh.com>, 'idr wg' <idr@ietf.org>


Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "draft-vandevelde-idr-bgp-ls-segment-routing-rld@ietf.org" <draft-vandevelde-idr-bgp-ls-segment-routing-rld@ietf.org>


Subject: Re: [Idr] draft-vandevelde-idr-bgp-ls-segment-routing-rld-03 - 2 week WG Adoption call (6/14 to 6/28)




 




This document is useful, however I would like to suggest if the authors could consider merging this with draft-tantsura-idr-bgp-ls-segment-routing-msd where the RLD becomes another MSD sub-type. I believe draft-tantsura-idr-bgp-ls-segment-routing-msd provides a much better extensible mechanism for signalling of other such label limits at link and node level. Not to mention, this also is more efficient encoding.




 




While I am not sure if similar would be possible at this stage in the under-lying IGPs, but it is perhaps not too late to consider for BGP-LS protocol?




 




Thanks,




Ketan




 




From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares


Sent: 15 June 2017 05:50


To: 'idr wg' <idr@ietf.org>


Cc: idr-chairs@ietf.org; draft-vandevelde-idr-bgp-ls-segment-routing-rld@ietf.org


Subject: [Idr] draft-vandevelde-idr-bgp-ls-segment-routing-rld-03 - 2 week WG Adoption call (6/14 to 6/28)




 




This begins a 2 week WG adoption call for draft-vandevelde-idr-bgp-ls-segment-routing-rld-03 (6/14/2017 to 6/28/2017).    The chairs would appreciate if the operators would indicate whether they would deploy this draft.   




 




The authors should within the first 5 days do the following: 




1)       Send a statement to the WG indicating whether you know of any IPR 




2)       Indicate whether you know of existing implementations 




3)       Please respond to the IDR list questions on a daily basis 




 




Sue Hares and John Scudder 




 




_______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr