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

Boris Hassanov <bhassanov@yahoo.com> Tue, 28 July 2020 19:29 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 B2BF13A0BA5 for <lsvr@ietfa.amsl.com>; Tue, 28 Jul 2020 12:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 jHvE-Lvbc9V6 for <lsvr@ietfa.amsl.com>; Tue, 28 Jul 2020 12:29:08 -0700 (PDT)
Received: from sonic301-3.consmr.mail.bf2.yahoo.com (sonic301-3.consmr.mail.bf2.yahoo.com [74.6.129.42]) (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 C46B73A0BA3 for <lsvr@ietf.org>; Tue, 28 Jul 2020 12:29:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1595964546; bh=F6ULDTenhM4DekZqqvmS61GPvnZ4Wb4EUR9m6jnGDoc=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=XeB/4UyUuxQN40llubBhvCNiGHzdTHSfC6DDc3TRhtir5RR6MDqVpVGnKumpIfqywmHZruVcA/mKv7ewNxVtgSmvyfEevJJTMeWXSMdAz6sI9yAOWlXvqFIXBpwG+ejJzUP2h/yNZ9YoeyVEFF3zxW8UDb4DAJinn92Kz3HEUTjxexd0KVUHG9jU8lPu20d9CtpP/gUjm/lcg9ujti77TJcAxYSLlAhU/5cxrC9XU/BI9UsLGEzJUNvTT3vTl6rSwJXY+fUYWcLsZlt89qJ2BHrSmv91texrQY1eZlORfXCGgN2UHK9PXj2NpVdSdhmrGSNpQfGLr1cnHVasW5Snrw==
X-YMail-OSG: pOBSk18VM1l6Wlv6eazi5egaq82sT7wErnDNMYh9Wpcp3sCrzA0BJpOBBxHSpQk l4GQa.sYxmGb5WgPUxm32pAVCt0h5j1GBRB0P9k4yGID90p25c1NpvowSsefzFJqA4wUA5VEK0gz GC2Li4DoNfNTJD3YS50mVXhfmGr7phFkhcRGTa_fCxgdyjze3jV1c4CR3Lt9.DJn46D4gesHKMM9 wJw9WH.uRG2CtiluB0meWmJujHtRnfc8n6l6QsWsrmj_xBq9HlsWw2Vv1Oc8n.AjvFVx2GiagfuG wM.iX7DGtNCha6qDALw080iLGPgPvRyI4PFHxUCjR.TrqJj3xTFyLhFm5PfkCTb37xSEbnmE_F_p F6P7zEE30w9vnkjPCneCqwKhhN1XPYUmcSBHFxx.gyqWvOyYKqC8IbkpY58deA8qxoqptI3n_xf3 u28jwTJA_sccB26SrJjhMNvKIC0yLiXC6XekgoBY05mZKrenjfxHBjPkGokJXcf1WOMJuP8ew9._ qnTtZRCV9l2zWrRBdsxjhkiVdzQYtzajIsZsdOyuOU3CNbpwzgffIlTJrslQjVNnH9_7znx.GFxF Pg_VT.OhodF_iyReWKOvmiGJLA8VTI6XolpXWRLilohRZlfJTZxHEGveSNpKBDzuggXughkeI2kL 8xrkLUkvXB3UaXQeOIJi1bogncHfiPqyky7A2kAhD_WRU8cMUetMIpXNWHzW3sayeD1cXwNEg_pB hyn6eqYCN4HeZSpjc6qBAjf2H3Hjl9FxpsQA_GOvpZ8O1EyJcKDCwBa1cPqO3kLHeWLp_vJlyhAF IIdGwsuB5hzqofnklieM7N12X1kiqSsBCqvIGAKPx0.P7nOkpcADq3UwyRh.sO8XYMl.hmKPoyy9 .gUdMmsgh0p_Z.iE9V4BKZpuPCbNDM93iZJVYcCj1P4NgEKWRtdQroAXYNiXr7BWYwlOTNu2fek7 R8ZFOiGZvUaDxrkauCJT.U.qcvc1Dlza9sdiixBjF9eDI1khT_18OWYEGsoJR.bBpm2EXGunyoxw 7fT1s.C3yYScd9Ky7z73GC8Epa0kgKjajprqh_VH1yl0JmoPNCtIwciahJYhAF2JKvcvpnv_Xllv 33Ng1Wki2HYGj7p1CC.AD0qnqL41fFAb_UtITKa281FIogINRUXEM8mHqCIGbSZzAoQFjcV.gE3O Ld_nSSUR7bdvyHT93MZ.bfthpdLVVfBdQ5Tq9dFkY6RiwvNXl0.yA1N7Dwe5UcIkq6OxTRkweZju e75hAqQfD_3wZq5.q09dMFpaiwFDRs6AdXJ105tenXrVobIdsNJQg7WkbYFNVe_N2aTilT_KO.vJ V1maYAzm82svynqN9ZOIvL.fS
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Tue, 28 Jul 2020 19:29:06 +0000
Date: Tue, 28 Jul 2020 19:28:50 +0000
From: Boris Hassanov <bhassanov@yahoo.com>
To: Boris Hassanov <bhassanov=40yahoo.com@dmarc.ietf.org>, Keyur Patel <keyur@arrcus.com>, "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: <2056163397.5975691.1595964530203@mail.yahoo.com>
In-Reply-To: <0AF005B3-47CF-4622-B1BE-7043E40ADCAA@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> <183522699.483232.1585518124609@mail.yahoo.com> <0AF005B3-47CF-4622-B1BE-7043E40ADCAA@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_5975690_983024616.1595964530198"
X-Mailer: WebService/1.1.16271 YMailNorrin Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/3oc--2L_ur6Rc-AuxTe75FnWbPg>
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: Tue, 28 Jul 2020 19:29:14 -0000

 Hi Acee,
Sorry for delay. Hope you are fine. Comments inline, BKH>,
Thank you.
SY,Boris

    On Saturday, July 25, 2020, 9:35:45 PM GMT+3, Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org> wrote:  
 
 
Hi Boris, 
 
  
 
From:Lsvr <lsvr-bounces@ietf.org> on behalf of Boris Hassanov <bhassanov=40yahoo.com@dmarc.ietf.org>
Date: Sunday, March 29, 2020 at 5:42 PM
To: Keyur Patel <keyur@arrcus.com>, Boris Hassanov <bhassanov=40yahoo.com@dmarc.ietf.org>, "lsvr@ietf.org" <lsvr@ietf.org>, Gunter Van de Velde <gunter.van_de_velde@nokia.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
Subject: Re: [Lsvr] WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 2020)
 
  
 
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.
  
 
I have two examples in the next revision. 
    BKH> See it, looks okay. 
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 don’t think that multiple links between the same to two switches in the fabric are common either.
   BKH> I see the point of sparse peering, but " the same two BGP speakers" sounds confusing IMO. That is why I would explicitly mention who are those two BGP speakers and which hierarchy level they do belong (i.e. leaf and spine, sub-leaf and leaf etc.), as soon as it will be clear the advantages of sparse peering are also more clearer.

 
I would also add some diagram here showing example of Sparse Peering model.
 
  
 
This is very hard with ASCII art. I’ve added some text. 
  BKH> Yes, drawing it in ASCII would be very challenging. I would only add the reference to section 6.5.1 after this sentence: "each leaf switch would only peer with subset of the spines...". I think it will highlight the practic ogic of Sparse Peering.
 
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.
 
I added the example of prefix aggregation.
  BKH> Agree. 
 
6.5.1 Peer discovery - cannot comment now, need to read those 3 drafts.
 
6.5.2 -yes, agree
 
6.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."
 
  
 I agree and I have changed. 

BKH> No more comments yet. Thank you.
 
  
 
Thanks,

Acee
 
  
 
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>, "lsvr@ietf.org" <lsvr@ietf.org>, 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>, "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
 _______________________________________________
Lsvr mailing list
Lsvr@ietf.org
https://www.ietf.org/mailman/listinfo/lsvr