Re: [Lsvr] WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 2020)

Boris Hassanov <bhassanov@yahoo.com> Sun, 29 March 2020 21:42 UTC

Return-Path: <bhassanov@yahoo.com>
X-Original-To: lsvr@ietfa.amsl.com
Delivered-To: lsvr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABB93A0D7D for <lsvr@ietfa.amsl.com>; Sun, 29 Mar 2020 14:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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, RCVD_IN_MSPIKE_H2=-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=yahoo.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 7uWNECcy23lD for <lsvr@ietfa.amsl.com>; Sun, 29 Mar 2020 14:42:07 -0700 (PDT)
Received: from sonic316-12.consmr.mail.bf2.yahoo.com (sonic316-12.consmr.mail.bf2.yahoo.com [74.6.130.122]) (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 53A043A0D7B for <lsvr@ietf.org>; Sun, 29 Mar 2020 14:42:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1585518126; bh=yPtx63oguoIPH3/c4up+K2XO2KMQf4mV28ZIwv3qv14=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=UfQCPY92FcUEykZngOLuPUuVhX4N1WyRe7G4fErHUwtLWdYST5z2lYpe/z1mRz44Ms5u9UpfGp9ZSf4SgrO8WZ0eY+khuYLEFcaOZmx/aw98TuSOu9tuRXJ8DXtImEHOiH+C/T8JrGeEsmsip8ZTiygb6wCUfxHvh9HVmMAyJEKbORDlWTZrimrwP28IGFed5N0rJ0unhPrE6BVDHdUYs91F/GFGoEMF7HlCKUrYf5Spn6QcuyRHamB2PRTTXTnAPtRvfYmgYeUIXyGwrPKB2kdoHvEH40HouijNv4zQKBOwXF2MxA/ELnN6PqFBw02hNR2n6QaNPLD46uYAjeUveQ==
X-YMail-OSG: J2hEpBMVM1ms5keOexIcHXnH87dbbafGmLvVRIfQUqmsOndLpcMSzWZeglM8GY1 TDJ88JkfAHXBLvey6O8ZnLiTkQ8YaoEu6FWJ5V8qyu3F.OiKd4N2tVeRsxAEZGmSBNTPBePgd4A8 mwesnU9gcpsWmnImdhTMOmtkuzcZRsLSgxsy4g5QlkjLoEtns4Z.d9BpIIJPo56V1NfXTq.F3F.l ppahAWZcbx3VvGUlZZn6CuuEflzwKedigfKzPTHcYK5qTsIP4JVFwIyNBUCzeTMBmqW75_Fvse.V 4LZgj1uTXjxoxSZvY_z7DS13MtwZRzsebsFnXGB_yiXogIWxnHszYpKlFiQo6jXo7Sd04FTYlIiU OgBI_UJV1xrGywjrdkmk5x1iWda8h3T0xcQbZswa.mqCnLdvT7neMsysh_p4RnAwnD2T7lIKYRcN Wa7i3xTbWkaj7CzO8w9vXwZw7hKuADlebwMKcWrtXe59RnBuXbNyJELvdWcHtirgdqQ3jgfWQUgZ CPgTb9Q_FNLNrevIToatDlyEg9Q6SX_CHssf7QdqW8cDMFz_37M.dD6UEsUy.C57UiVIszwF3ec1 BrnH.Vy_4APssap8hL3liLgz87fAzhAnLe1ijUnfH2P3jUV.kKvHfxlCsSBnFjI3zjuUBCD6PPzR 6cs4eEFA.Q7rLZNFceUmrVE.givdu6ypOTiGpYYxvMEiC5Rav7_3deBFOa3RjQMtKZLfJZfH8ex8 BWVQJNKMI_GLAhk_dNPb6Ve3R0H54dbnnUMEng3DQUdp5izgCjnba7RqNhCUr20jKcEVx5p9phAb 1n_sv8IUjqp1tMxSKC5pFf2legzFtTvGZ2tmJczOknFJFP6194N6Z9YV1LN_lg6bh5YrdOi9ee9x sSP_QusdIf3812pE_p2vCOO_7GwqqMCvvctCi1F6Qp1xtLUJ6Up1CmKSbc80v7cTLTF8SYK4QwOP DIiDGD0Y9stQfkbT90cqDHwUyA3bRBjWYm3UDaFQRTHCwP2wBH7c3KhgXw7DaHBYwO44lhrOGSp6 5qmhtXGOXMFMk0WHrI7gfrdp2_Vs5o2cnE_mp7KTyLGU_N8KT6_nIclfQyAtHlRsWJTxF41X9PQz 143XcF00aRETFurVU3EvEY8Ht7ISUaGIijxj9OoKWjQ9immjFRFeSXR6JMWGjOh7HaKNvMK.QanW AAL3rZ9MXnPfBGwl1xcP_kQSQq8zpEREaezYzCdZ2qCn9M_hxo4Woh3ZjxMPKD1RZ6M5yieGMrAU 88vXDYWSrc0XmF.zs2sPQAV_dt7aRD02VDPY0oRE9dYlzJt2JEjl_1uSTXRs.wAJzmqlh61oZQbr q21mm9Ni4JnMvXre4AkmiPPiNmw--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Sun, 29 Mar 2020 21:42:06 +0000
Date: Sun, 29 Mar 2020 21:42:04 +0000 (UTC)
From: Boris Hassanov <bhassanov@yahoo.com>
To: Keyur Patel <keyur@arrcus.com>, Boris Hassanov <bhassanov=40yahoo.com@dmarc.ietf.org>, "lsvr@ietf.org" <lsvr@ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
Message-ID: <183522699.483232.1585518124609@mail.yahoo.com>
In-Reply-To: <93CD7CD4-C50B-40F2-B9BB-7C8D018254DC@cisco.com>
References: <AM6PR07MB482349E2CC33B30A35F7D0A9E03F0@AM6PR07MB4823.eurprd07.prod.outlook.com> <AM6PR07MB482383564D43B71545F8F411E0360@AM6PR07MB4823.eurprd07.prod.outlook.com> <513025242.9878512.1579620926598@mail.yahoo.com> <077EC01A-0CE6-411D-98D2-B7689D11B071@arrcus.com> <93CD7CD4-C50B-40F2-B9BB-7C8D018254DC@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_483231_737025343.1585518124605"
X-Mailer: WebService/1.1.15555 YMailNorrin Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/xiIKL0PZLvRB9-5H1wpbxj9d5pM>
Subject: Re: [Lsvr] WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 2020)
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Vector Routing <lsvr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsvr>, <mailto:lsvr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsvr/>
List-Post: <mailto:lsvr@ietf.org>
List-Help: <mailto:lsvr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsvr>, <mailto:lsvr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Mar 2020 21:42:09 -0000

 Hi Acee and all,Thank you. Hope that you all are okay.
Yes, I read the new version, some comments are below:6.1.1 says: "Rather, additional NLRI attributes can be advertised in the BGP-LS SPF AFI/SAFI as required."  IMO, some examples of such attributes are needed after that.
6.2.1 "However, this use case is not very useful since parallel layer-3 links between the same two BGP routers are rare in CLOS or Fat-Tree topologies." IMO, would be good to change as "...the two BGP routers of the same level (leaf-leaf, spine-spine)"I would also add some diagram here showing example of Sparse Peering model.
6.3 BGP Spine/Leaf Topology Policy
This paragraph does not say much about - what kind of policy is needed, why etc.There is the statement that BGP policy can be applied at any level, that it is not needed to advertise BGP-LS NLRI in northbound direction from leaves to spine and an example.
May be I just did not get it, but what is the main message here about topology policy?
6.5.1 Peer discovery - cannot comment now, need to read those 3 drafts.6.5.2 -yes, agree6.5.3 - I would change from:"This would normally be done on a central controller but distributed consistency checking is not precluded." to "This would normally be done on central controller or other management tool which can be used for fabric data paths verification."

SY,Boris

     On Wednesday, March 25, 2020, 12:34:28 AM GMT+3, Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org> wrote:  
 
 
Hi Boris, 
 
Please take a look at the -05 version. I’ve incorporated your comments.
 
Thanks,
 
Acee
 
  
 
From:Lsvr <lsvr-bounces@ietf.org> on behalf of Keyur Patel <keyur@arrcus.com>
Date: Tuesday, January 21, 2020 at 10:45 PM
To: Boris Hassanov <bhassanov=40yahoo.com@dmarc.ietf.org>rg>, "lsvr@ietf.org" <lsvr@ietf.org>rg>, Gunter Van de Velde <gunter.van_de_velde@nokia.com>
Subject: Re: [Lsvr] WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 2020)
 
  
 
Hi Boris,
 
 
 
Thanks for your comments and detail review.😊
 
 
 
Ack on all three. We will cover it in next revision.
 
 
 
Regards,
 
Keyur
 
 
 
From:Lsvr <lsvr-bounces@ietf.org> on behalf of Boris Hassanov <bhassanov=40yahoo.com@dmarc.ietf.org>
Date: Tuesday, January 21, 2020 at 7:35 AM
To: "lsvr@ietf.org" <lsvr@ietf.org>rg>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
Subject: Re: [Lsvr] WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 2020)
 
 
 
Hi Gunter and all,
 
 
 
Sorry for the late reply.
 
I read the draft and personally support its publication.
 
 
 
Few comments for the next updated version:
 
1) The References part needs to be updated since there are newer versions of those drafts are available.
 
2)  Can RFC 5549 approach be incorporated for simplification of BGP connected graph configuration and creation? There is example of such implementation  for kind of BGP unnumbered peering configuration so it could be useful here too, IMO.
 
3) I think that LSVR/BGP-LS SPF has another very important use case: using of  of real topology information of CLOS network for monitoring and troubleshooting instead of using home-made tools for topology verification... Can we extend the draft for such case in the the next version?
 
 
 
Thanks.
 
 
 
SY,
 
Boris
 
 
 
 
 
 
 
 
 
On Thursday, January 16, 2020, 9:45:40 AM GMT+3, Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com> wrote:
 
 
 
 
 
Tuesday 21 January is approaching soon.
 
If you read the draft, please post your comments on document readiness and completeness.
 
 
 
Be well,
 
G/
 
 
 
From: Lsvr <lsvr-bounces@ietf.org>On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Tuesday, January 7, 2020 16:39
To: lsvr@ietf.org
Subject: [Lsvr] WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 2020)
 
 
 Hi All,       The LSVR WG initiates a working group last call for "draft-ietf-lsvr-applicability-04". Please send your comments to the list before Tuesday January 21.    https://datatracker.ietf.org/doc/draft-ietf-lsvr-applicability/    All, please reply on-list indicating if you're aware of an implementation. If not already completed, please reply on-list indicating if you're aware of any relevant IPR.    Brgds, Gunter & Victor LSVR WG co-chairs 
 
 
_______________________________________________
Lsvr mailing list
Lsvr@ietf.org
https://www.ietf.org/mailman/listinfo/lsvr
 _______________________________________________
Lsvr mailing list
Lsvr@ietf.org
https://www.ietf.org/mailman/listinfo/lsvr