Subject: [Lsvr] WG Adoption Call for draft-keyupate-lsvr-bgp-spf-00 (April 6 to April 20

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 6 Apr 2018 15:36:11 +0000

This begins a 2 week WG Adoption Call for "draft-keyupate-lsvr-bgp-spf-00 " from April 6th to April 20th .

During your discussion in the WG Adoption Call, the chairs are looking for more context as only a 'yeh' or 'ney'.

please indicate the following things:

1)           Support to adopt draft "draft-keyupate-lsvr-bgp-spf-00 as LSVR WG document?

2)            Do you feel "draft-keyupate-lsvr-bgp-spf-00" complies to the LSVR charter, please explain if you think it does not conform to the LSVR charter?

3)            Are there any technical issues with this draft?

4)           Which are current pain-points in the draft requiring additional content and technical attention?

5)            What is missing from this draft?

For your quick access to this draft, find the link below:

https://datatracker.ietf.org/doc/draft-keyupate-lsvr-bgp-spf/

Please find that during the WG Adoption Call process, three persons kindly volunteered in-depth review and provide on-list comments:

  * Mankamana Mishra

  * Boris Hassanov

  * Jacob Uecker

Kind Regards,

Victor & Gunter

co-chairs LSVR WG

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Apr 2018 13:24:04 -0700

> This begins a 2 week WG Adoption Call for
> "draft-keyupate-lsvr-bgp-spf-00 " from April 6th to April 20th .

have read once, not deeply.  idea looks useful.  doc looks within normal
bounds.

> 2) Do you feel "draft-keyupate-lsvr-bgp-spf-00" complies to the LSVR
>    charter

yes

> 3) Are there any technical issues with this draft?

i need to read more thoroughly; but am not going to waste my time unless
it is a wg draft

> 5) What is missing from this draft?

oh pfui!  i think it should be adopted.  enough.

randy

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Sun, 8 Apr 2018 19:18:01 +0000

From: Gunter VAN DE VELDE <[email-masked]>
Date: Friday, 6 April 2018 at 17:36
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Boris Hassanov <[email-masked]>, Jacob Uecker <[email-masked]>, "Mankamana Mishra (mankamis)" <[email-masked]>
Subject: WG Adoption Call for draft-keyupate-lsvr-bgp-spf-00 (April 6 to April 20
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Friday, 6 April 2018 at 17:36

Yes as co-author.

Yes, I have the feeling the charter is build for it

No

Nothing I can think of

Reviews from multiple people

  * Mankamana Mishra

  * Boris Hassanov

  * Jacob Uecker

Kind Regards,

Victor & Gunter

co-chairs LSVR WG

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 8 Apr 2018 21:11:58 +0000

From: Gunter Van de Velde <[email-masked]>
Date: Friday, April 6, 2018 at 11:36 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Boris Hassanov <[email-masked]>, Jacob Uecker <[email-masked]>, "Mankamana Mishra (mankamis)" <[email-masked]>
Subject: WG Adoption Call for draft-keyupate-lsvr-bgp-spf-00 (April 6 to April 20
Resent-From: <[email-masked]>
Resent-To: Keyur Patel <[email-masked]>, Acee Lindem <[email-masked]>, Shawn Zandi <[email-masked]>, Wim Henderickx <[email-masked]>
Resent-Date: Friday, April 6, 2018 at 11:36 AM

 

Yes – as co-author. 

Yes. 

Inevitably. However, they are not clear at this point. 

Changes to the BGP decision process – are they described in enough detail and are they enough to spend convergence.  

No.  

Thanks,
Acee

 
 
Kind Regards,
 
Victor & Gunter
co-chairs LSVR WG

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Wed, 11 Apr 2018 05:47:14 +0000

Support the adoption of document. and here are some initial comments. if there is anything else, i would post it in list.

1)           Support to adopt draft "draft-keyupate-lsvr-bgp-spf-00 as LSVR WG document?
Yes
2)            Do you feel "draft-keyupate-lsvr-bgp-spf-00" complies to the LSVR charter, please explain if you think it does not conform to the LSVR charter?
Yes
3)            Are there any technical issues with this draft?
Nothing as of now which would prevent it to be adopted as WG document .
4)           Which are current pain-points in the draft requiring additional content and technical attention?
Adding some more text about case where some of the speaker not supporting this specification would be good.
5)            What is missing from this draft?
Nothing as of now.

Comment: Section  1.1<https://tools.ietf.org/html/draft-keyupate-lsvr-bgp-spf-00#section-1.1>. BGP Shortest Path First (SPF) Motivation talks about

   Another potential advantage of BGP SPF is that both IPv6 and IPv4 can
   be supported in the same address family using the same topology.
   Although not described in this version of the document, multi-
   topology extensions can be used to support separate IPv4, IPv6,
   unicast, and multicast topologies while sharing the same NLRI

are there plan to add more text in this area ?

Editorial comment:
5.1<https://tools.ietf.org/html/draft-keyupate-lsvr-bgp-spf-00#section-5.1>.  Phase-1 BGP NLRI Selection

2.  If the Sequence-Number TLV is present in the BGP-LS Attribute,

       then the NLIR with the most recent, i.e., highest sequence number  >>>>> I assume it was NLRI

Mankamana

On Apr 6, 2018, at 8:36 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>> wrote:

Kind Regards,

Victor & Gunter
co-chairs LSVR WG

---

From: Keyur Patel <[email-masked]>
Date: Wed, 11 Apr 2018 16:18:18 +0000

Hi Mankamana,

Thank you for the document review and support.

My comments are inlined #Keyur

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Tuesday, April 10, 2018 at 10:47 PM
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Boris Hassanov <[email-masked]>, Jacob Uecker <[email-masked]>
Subject: Re: WG Adoption Call for draft-keyupate-lsvr-bgp-spf-00 (April 6 to April 20
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Shawn Zandi <[email-masked]>, <[email-masked]>
Resent-Date: Tuesday, April 10, 2018 at 10:47 PM

#Keyur: Ack. Will do it in next revision.

#Keyur: If there is specific text you like us to add in draft for this section then please do let us know.

Regards,
Keyur

Editorial comment:

Mankamana

Kind Regards,

Victor & Gunter
co-chairs LSVR WG

---

From: Jacob Uecker <[email-masked]>
Date: Tue, 17 Apr 2018 10:04:34 -0700

Hi,

Responses to questions:
Yes
Yes
- 5. See below

As a network operator, my focus tended to be from that frame of reference. 

I had similar questions about additions to the multi topology sections but since that’s been asked and answered, there’s nothing I can add of substance.

Operationally, I’m interested in Section 2 - the different peering models and how I might go about deciding how I’d setup my LSVR peers. As stated, Section 2.1 follows peering deployment models show in RFC7938. It has the added advantage of coupling the physical link state and peering status. If we lose the link, we lose the peer and convergence is relatively rapid. However, it uses a lot of sessions, more configuration etc. So I’m interested in 2.2 and 2.3. However the stated interactions between the link state and peering state are “accomplished outside the scope of the document”. That seems to me to have a big operational impact but I understand if it’s intentionally set apart for discussion somewhere else or left up the vendor implementation. Is that the case?

Section 5, very last sentence says “Application of policy would not be prevented but would normally not be necessary”. What kinds of policy? What can I manipulate and why would I would want to? Maybe something for another document? 

Thanks,
Jacob

> On Apr 6, 2018, at 8:36 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]> wrote:
> 
>  
> https://datatracker.ietf.org/doc/draft-keyupate-lsvr-bgp-spf/ <https://datatracker.ietf.org/doc/draft-keyupate-lsvr-bgp-spf/>
>

---

From: Keyur Patel <[email-masked]>
Date: Tue, 17 Apr 2018 21:29:07 +0000

Hi Jacob,

Many thanks for the review and feedback.

From: Jacob Uecker <[email-masked]>
Date: Tuesday, April 17, 2018 at 10:04 AM
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Boris Hassanov <[email-masked]>, "Mankamana Mishra (mankamis)" <[email-masked]>
Subject: Re: WG Adoption Call for draft-keyupate-lsvr-bgp-spf-00 (April 6 to April 20
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Shawn Zandi <[email-masked]>, <[email-masked]>
Resent-Date: Tuesday, April 17, 2018 at 10:04 AM

Hi,

Responses to questions:

  1.  Yes
  2.  Yes
  3.  - 5. See below

#Keyur: One could track the link state and peering sessions over links using protocols like BFD. We could make an explicit reference to BFD usage if that helps.

#Keyur: The reference was for all standard BGP policies. The draft extensions do not impose any restrictions on the policy usage (AFAIK). 😊

Regards,
Keyur

Regards,
Keyur

Thanks,
Jacob

Kind Regards,

Victor & Gunter
co-chairs LSVR WG

---

From: Neeraj Malhotra <[email-masked]>
Date: Tue, 17 Apr 2018 18:14:00 -0700

Hi,

yes

> 2)            Do you feel "draft-keyupate-lsvr-bgp-spf-00" complies to
> the LSVR charter, please explain if you think it does not conform to the
> LSVR charter?
>
yes

> 3)            Are there any technical issues with this draft?
from cursory reading, no obvious issues with existing content

> 4)           Which are current pain-points in the draft requiring
> additional content and technical attention?
>
some more detail with respect to fast convergence applications such as
LFA-FRR, TI-LFA (especially in a Clos) would be useful.

> 5)            What is missing from this draft?
additional material detailing deployment use cases (both intra and
inter-DC) would be useful.

Thanks,
Neeraj

---

From: Keyur Patel <[email-masked]>
Date: Wed, 18 Apr 2018 16:59:20 +0000

Hi Neeraj,

Thanks for the review and feedback. We will try and cover use-cases in more details in the next draft revision.

Regards,
Keyur

From: Neeraj Malhotra <[email-masked]>
Date: Tuesday, April 17, 2018 at 6:14 PM
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Boris Hassanov <[email-masked]>, "Mankamana Mishra (mankamis)" <[email-masked]>, Jacob Uecker <[email-masked]>
Subject: Re: [Lsvr] WG Adoption Call for draft-keyupate-lsvr-bgp-spf-00 (April 6 to April 20
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Shawn Zandi <[email-masked]>, <[email-masked]>
Resent-Date: Tuesday, April 17, 2018 at 6:14 PM

Hi,

yes

4)           Which are current pain-points in the draft requiring additional content and technical attention?
some more detail with respect to fast convergence applications such as LFA-FRR, TI-LFA (especially in a Clos) would be useful.

5)            What is missing from this draft?
additional material detailing deployment use cases (both intra and inter-DC) would be useful.

Thanks,
Neeraj

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 19 Apr 2018 07:29:28 +0000

Please find a kind reminder regarding this WG Adoption call.

G/

From: Lsvr [mailto:[email-masked]] On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Friday, April 6, 2018 17:36
To: [email-masked]
Cc: [email-masked]; Boris Hassanov <[email-masked]>; Mankamana Mishra (mankamis) <[email-masked]>; Jacob Uecker <[email-masked]>
Subject: [Lsvr] WG Adoption Call for draft-keyupate-lsvr-bgp-spf-00 (April 6 to April 20

  * Mankamana Mishra

  * Boris Hassanov

  * Jacob Uecker

Kind Regards,

Victor & Gunter

co-chairs LSVR WG

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 20 Apr 2018 14:46:17 +0000

Relaying draft review mail on behalf of Boris Hassanov regarding WG Adoption Call onto LSVR WG:

-------------

From: Boris Hassanov [mailto:[email-masked]]
Sent: Thursday, April 19, 2018 23:28
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Subject: Re: Review and support for the WG adoption call

Regarding draft, here are my comments (sorry for being last one), provided as is (may be too long...)

Firstly, I think that draft direction continues the development of very important work of RFC7752 that defines new NLRI for link state information and new attribute so now all vendors say about BGP-LS support.

I personally fully support the idea of usage BGP as single routing protocol on LSDC that is described in RFC7938 (although that would require significant level of BGP config and monitoring automation). That is required to use EBGP with different (private) ASNs and make routing decision based on AS_PATH. I would also add here BGP large communities (RFC8092) as additional tool that could be used together with BGP in LSDC.

draft-keyupate-lsvr-bgp-spf makes one step further and tries to combine BGP-LS and SPF.

IMO, of course it is much better to have several variants of routing solutions for MSDCs but anyway we would compare them, so that is why I think it could be good to have comparison with RFC7938 approach.

As i understand the key moment and difference with traditional BGP- based routing is modification of BGP decision process (RFC4271, degree of preference, route selection) towards SPF-calculation.

The draft justifies that such approach will provide mutual benefits of BGP (TCP, no flooding, less NLRI updates) and IGP (ECMP, fast convergence, IP FRR) in single solution.

The draft introduces BGP-LS-SPF and BGP-LS-SPF-VPN AFI/SAFI (by the way there is misprint in 3:

The BGP-LS-SPF (AF 16388 / SAFI TBD1)

SPF capability is encoded as new Node Attribute TLV.

The draft says that beauty and simplification is in modified decision process.

Personally I would slightly re-phrase paragraph 5 (Decision process with SPF algorithm) to make the explanation more simple and clear. It is very important piece but now sounds a bit confusing.

For example, let's have a look to these 2 paragraphs:

When BGP-LS-SPF NLRI is received, all that is required is to   determine whether it is the best-path by examining the Node-ID and sequence number as described in Section 5.1<https://tools.ietf.org/html/draft-keyupate-lsvr-bgp-spf-00#section-5.1>.  If the best-path NLRI had changed, it will be advertised to other BGP-LS-SPF peers.  If the attributes have changed (other than the sequence number), a BGP SPF calculation will be scheduled.  However, a changed best-path can be advertised to other peer immediately and propagation of changes can approach IGP convergence times.

The SPF based Decision process starts with selecting only those Node NLRI whose SPF capability TLV matches with the local BGP speaker's SPF capability TLV value.  Since Link-State NLRI always contains the local descriptor [RFC7752<https://tools.ietf.org/html/rfc7752>], it will only be originated by a single BGP speaker in the BGP routing domain.  These selected Node NLRI and their Link/Prefix NLRI are used to build a directed graph during the SPF computation.  The best paths for BGP prefixes are installed as result of the SPF process.

IMO, the 2nd one should be new 1st, the 'old' 1st should be 2nd. Also 1st paragraph above is written in the way that is confusing, IMO. 'If the  best-path NLRI had changed....' - why it was changed, by whom? etc.

'Changed best-path can be advertised to other peer immediately and propagation of changes can approach IGP convergence times' - I would to see here more info about how it could be accomplished, what should we do for that if it is still BGP with his timers etc.

In 5.1 :"

The modified Decision Process with SPF algorithm uses the metric from Link and Prefix NLRI Attribute TLVs [RFC7752<https://tools.ietf.org/html/rfc7752>]"

How it uses this metric? please elaborate more.

In 5.1. the draft says ' the NEXT_HOP attribute value is preserved and validated'

But in Part 5.3 :

All BGP peers that support SPF extensions would locally compute the

   NEXT_HOP values as result of the SPF process.  As a result, the

   NEXT_HOP attribute is always ignored on receipt.  However BGP

   speakers should set the NEXT_HOP address according to the NEXT_HOP

   attribute rules mentioned in [RFC4271<https://tools.ietf.org/html/rfc4271>].

Where do we tell how NEXT_HOP value is derived from SPF process?

I personally would add some simple topology as example and  show how BGP with SPF will calculate SPF and NEXT_HOP.

The last thing that I want to bring is the following: this approach would require significant modification of BGP existing stack. Did you estimate the efforts for that as well as for supporting backward compatibility?

In RFC7938 we can also have sort of SPF but based on AS-PATH length, if we would encode link information and properties in large community, for example, can't it be more simple (from implementation) way to do similar job?

In overall I like the direction of your thoughts and attempt to marry BGP and IGP:)

Thank you.

SY,
Boris

---------------

From: Lsvr [mailto:[email-masked]] On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Thursday, April 19, 2018 09:29
To: [email-masked]
Cc: [email-masked]; Boris Hassanov <[email-masked]>; Mankamana Mishra (mankamis) <[email-masked]>; Jacob Uecker <[email-masked]>
Subject: Re: [Lsvr] WG Adoption Call for draft-keyupate-lsvr-bgp-spf-00 (April 6 to April 20

G/

From: Lsvr [mailto:[email-masked]] On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Friday, April 6, 2018 17:36
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Boris Hassanov <[email-masked]<mailto:[email-masked]>>; Mankamana Mishra (mankamis) <[email-masked]<mailto:[email-masked]>>; Jacob Uecker <[email-masked]<mailto:[email-masked]>>
Subject: [Lsvr] WG Adoption Call for draft-keyupate-lsvr-bgp-spf-00 (April 6 to April 20

  * Mankamana Mishra

  * Boris Hassanov

  * Jacob Uecker

Kind Regards,

Victor & Gunter

co-chairs LSVR WG

---

From: Keyur Patel <[email-masked]>
Date: Fri, 20 Apr 2018 18:01:15 +0000

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Friday, April 6, 2018 at 8:36 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Boris Hassanov <[email-masked]>, Jacob Uecker <[email-masked]>, "Mankamana Mishra (mankamis)" <[email-masked]>
Subject: WG Adoption Call for draft-keyupate-lsvr-bgp-spf-00 (April 6 to April 20
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Shawn Zandi <[email-masked]>, <[email-masked]>
Resent-Date: Friday, April 6, 2018 at 8:36 AM

#Keyur: Yes. Support as a co-author.

#Keyur: Yes.

#Keyur: None that I can think off. 😉

#Keyur: Clarifications on bestpath decision process and deployment scenarios.

Regards,

Keyur

  * Mankamana Mishra

  * Boris Hassanov

  * Jacob Uecker

Kind Regards,

Victor & Gunter

co-chairs LSVR WG

---

From: Yingzhen Qu <[email-masked]>
Date: Fri, 20 Apr 2018 11:14:10 -0700

Hi,

I support the adoption of this draft.

Thanks,
Yingzhen

On Fri, Apr 6, 2018 at 8:36 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <
[email-masked]> wrote:

> Please find that during the WG Adoption Call process, three persons kindly
> volunteered in-depth review and provide on-list comments:
>
>   * Mankamana Mishra
>
>   * Boris Hassanov
>
>   * Jacob Uecker
>
>
>
> Kind Regards,
>
>
>
> Victor & Gunter
>
> co-chairs LSVR WG
>
>
>
> _______________________________________________
> Lsvr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsvr
>
>

---

From: Boris Hassanov <[email-masked]>
Date: Fri, 20 Apr 2018 20:04:39 +0000 (UTC)

Hi all,

1) Yes, I support WG adoption of draft-keyupate-lsvr-bgp-spf
2) Yes, I think it complies
3-5) Gunter forwarded my comments   

Thanks.

SY,
Boris

    On Friday, April 6, 2018, 6:36:14 PM GMT+3, Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]> wrote:  

 

 

 

 

 

 
  * Mankamana Mishra
 
  * Boris Hassanov
 
  * Jacob Uecker

Kind Regards,

Victor & Gunter
 
co-chairs LSVR WG

---

From: Keyur Patel <[email-masked]>
Date: Fri, 20 Apr 2018 21:56:14 +0000

Hi Boris,

Thanks the comments and the feedback. We will address them in next draft revision. 😊

Regards,
Keyur

From: Boris Hassanov <[email-masked]>
Date: Friday, April 20, 2018 at 1:04 PM
To: "[email-masked]" <[email-masked]>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Jacob Uecker <[email-masked]>, "Mankamana Mishra (mankamis)" <[email-masked]>
Subject: Re: WG Adoption Call for draft-keyupate-lsvr-bgp-spf-00 (April 6 to April 20
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Shawn Zandi <[email-masked]>, <[email-masked]>
Resent-Date: Friday, April 20, 2018 at 1:04 PM

Hi all,

Thanks.

SY,
Boris

  * Mankamana Mishra

  * Boris Hassanov

  * Jacob Uecker

Kind Regards,

Victor & Gunter

co-chairs LSVR WG

---

From: Pushpasis Sarkar <[email-masked]>
Date: Sun, 22 Apr 2018 12:18:36 +0530

Hi Van,

I support WG adoption of this draft.

Thanks
-Pushpasis