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

["Acee Lindem (acee)" <[e-mail]>]

Hi Boris,
See inline prefaced by ACEE>.

From: Lsvr <[e-mail]> on behalf of Boris Hassanov <bhassanov=[e-mail]>
Date: Tuesday, July 28, 2020 at 3:29 PM
To: Boris Hassanov <bhassanov=[e-mail]>, Keyur Patel <[e-mail]>, "[e-mail]" <[e-mail]>, Gunter Van de Velde <[e-mail]>, "Acee Lindem (acee)" <acee=[e-mail]>
Subject: Re: [Lsvr] WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 2020)

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=[e-mail]> wrote:



Hi Boris,



From: Lsvr <[e-mail]> on behalf of Boris Hassanov <bhassanov=[e-mail]>
Date: Sunday, March 29, 2020 at 5:42 PM
To: Keyur Patel <[e-mail]>, Boris Hassanov <bhassanov=[e-mail]>, "[e-mail]" <[e-mail]>, Gunter Van de Velde <[e-mail]>, "Acee Lindem (acee)" <acee=[e-mail]>
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.

ACEE>I attempted to clarify this in the -07 version.



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.

ACEE>You mean 6.2.1 below – right?
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 logic 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.

ACEE> Thanks much for review,
Acee



Thanks,

Acee



SY,

Boris



On Wednesday, March 25, 2020, 12:34:28 AM GMT+3, Acee Lindem (acee) <acee=[e-mail]> wrote:





Hi Boris,

Please take a look at the -05 version. I’ve incorporated your comments.

Thanks,

Acee



From: Lsvr <[e-mail]> on behalf of Keyur Patel <[e-mail]>
Date: Tuesday, January 21, 2020 at 10:45 PM
To: Boris Hassanov <bhassanov=[e-mail]>, "[e-mail]" <[e-mail]>, Gunter Van de Velde <[e-mail]>
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 <[e-mail]> on behalf of Boris Hassanov <bhassanov=[e-mail]>
Date: Tuesday, January 21, 2020 at 7:35 AM
To: "[e-mail]" <[e-mail]>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[e-mail]>
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) <[e-mail]> 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 <[e-mail]> On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Tuesday, January 7, 2020 16:39
To: [e-mail]
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lsvr

_______________________________________________
Lsvr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lsvr
_______________________________________________
Lsvr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lsvr