Subject: [GROW] TLV support for BMP Route Monitoring and Peer Down Messages

From: Paolo Lucente <[email-masked]>
Date: Tue, 2 Jul 2019 11:35:29 +0000

Dearests,

We have submitted https://www.ietf.org/id/draft-lucente-bmp-tlv-00.txt . We would like to get opportunity to present it in Montreal and would much welcome feedback on list meanwhile. Abstract below for your convenience:

===
   Most of the message types defined by the BGP Monitoring Protocol
   (BMP) do provision for optional trailing data; however Route
   Monitoring message (to provide a snapshot of the monitored Routing
   Information Base) and Peer Down message (to indicate that a peering
   session was terminated) do not.  Supporting optional data in TLV
   format across all BMP message types allows for an homogeneous and
   extensible surface that would be useful for the most different use-
   cases that need to convey additional data to a BMP station.  While
   this document does not want to cover any specific utilization
   scenario, it defines a simple way to support optional TLV data in all
   message types.
===

Paolo

---

From: Camilo Cardona <[email-masked]>
Date: Fri, 5 Jul 2019 22:04:14 -0500

Hello GROW,

We just submitted draft https://www.ietf.org/id/draft-cppy-grow-bmp-path-marking-tlv-00.txt. The idea of the draft is to signal the state of the path in the FIB using the mechanism described in draft-lucente-bmp-tlv-00 (https://www.ietf.org/id/draft-lucente-bmp-tlv-00.txt), which was introduced this week. 

Feedback is, as always, welcome. 

If possible, we would like to have a couple of minutes to present it in Montreal (probably better if done next to the presentation of  draft-lucente-bmp-tlv-00).

A good part of this document was inspired by other draft, https://tools.ietf.org/html/draft-bgp-path-marking-00, that we proposed some years ago. In that draft, similar information was signaled using communities. Back then, there were some concerns of this data potentially messing with the BGP decision process, something that should not be a problem when using BMP.

Thanks,
Camilo Cardona

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 11 Jul 2019 11:29:21 +0000

Hi all,

Thank you for introducing this very useful draft.

Few comments:

#1
1.  Introduction

   For a given prefix, multiple paths with different path status, e.g.,
   the "best-path", the "best-external-path" and so on, may co-exist in
   the BGP module upon the local policy processing.  In addition, during
...
[Shunwan] How to convey multiple paths from BMP Client to BMP Server? 
I did not see a description of the relevant mechanism in this draft.

#2
2.1.  Path Type
                     +--------+----------------------+
                     | Value  | Path type            |
                     +-------------------------------+
                     | 0x0000 | Unknown              |
                     | 0x0001 | Best path            |
                     | 0x0002 | Best external path   |
                     | 0x0004 | Primary path         |
                     | 0x0008 | Backup path          |
                     | 0x0010 | Non-installed path   |
                     | 0x0020 | Unreachable next-hop |
                     +--------+----------------------+

                          Table 1: Path Type
[Shunwan] 
Since Path Type has 4 octets space, The Value in above table should be in 4-octet-style.
Regarding "Unreachable next-hop",  if I understand correctly, should it be "Unreachable NLRI" ? 

Thanks,
Shunwan

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of Camilo Cardona
Sent: Saturday, July 06, 2019 11:04 AM
To: [email-masked] [email-masked] <[email-masked]>
Cc: [email-masked]
Subject: [GROW] Path marking using BMP - TLVs

Hello GROW,

Thanks,
Camilo Cardona

_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 11 Jul 2019 12:25:11 +0000

Hi all,

I have read this document and think it is a good proposal for BMP.

Few comments:

#1
      TLV support for BMP Route Monitoring and Peer Down Messages
                        draft-lucente-bmp-tlv-00
[Shunwan] draft-lucente-bmp-tlv-00 should be draft-lucente-grow-bmp-tlv-00

#2
Abstract

…
[Shunwan] “Peer Down message (to indicate that a peering session was terminated)” is not so precise,  Peer Down message with Reason 5 can be used to indicate that the BGP session not been monitoring again but it’s not terminated yet（still alive）.

#3
4.3.  TLV data in Peer Down

   The Peer Down Notification message type is defined in Section 4.9
   [RFC7854].  TLV data MAY now follow any Reason code.

[Shunwan]
Section 5.3. of draft-ietf-grow-bmp-local-rib has already introduced a new reason code to convey VRF/Table Name TLV, but it’s not intended to be used for the other scenarios if I understand correctly.
I think it is important to introduce a generic mechanism for Peer Down message to use TLVs in this document.

Thanks,
Shunwan

From: GROW [mailto:[email-masked]] On Behalf Of Paolo Lucente
Sent: Tuesday, July 02, 2019 7:35 PM
To: [email-masked] [email-masked] <[email-masked]>
Subject: [GROW] TLV support for BMP Route Monitoring and Peer Down Messages

Dearests,

===

Paolo

---

From: Camilo Cardona <[email-masked]>
Date: Thu, 11 Jul 2019 12:30:55 -0500

Hi Shunwan,

Thanks for the comments, answers inline.

Camilo

> On 11 Jul 2019, at 06:29, Zhuangshunwan <[email-masked]> wrote:
> 
> Hi all,
> 

[Camilo] We rely on the mechanism described in draft https://www.ietf.org/id/draft-lucente-bmp-tlv-00.txt <https://www.ietf.org/id/draft-lucente-bmp-tlv-00.txt> for this, specifically on the TLV of the RM msg proposed there. We mention this on the abstract and on the first paragraph of section 2. If there is anything not clear there, please let us know.
> 2.1.  Path Type

[Camilo] I see the point, yes.
> Regarding "Unreachable next-hop",  if I understand correctly, should it be "Unreachable NLRI" ? 
[Camilo] Here we specifically try to signal that a path’s next-hop is not reachable, therefore invaliding the path.

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 12 Jul 2019 01:32:38 +0000

Hi Camilo,

Thanks for your quick response, please check my reply inline with [Shunwan2].

BR,
Shunwan

From: Camilo Cardona [mailto:[email-masked]]
Sent: Friday, July 12, 2019 1:31 AM
To: Zhuangshunwan <[email-masked]>
Cc: [email-masked] [email-masked] <[email-masked]>; [email-masked]
Subject: Re: [GROW] Path marking using BMP - TLVs

Hi Shunwan,

Camilo

On 11 Jul 2019, at 06:29, Zhuangshunwan <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Few comments:

#1
1.  Introduction

[Camilo] We rely on the mechanism described in draft https://www.ietf.org/id/draft-lucente-bmp-tlv-00.txt for this, specifically on the TLV of the RM msg proposed there. We mention this on the abstract and on the first paragraph of section 2. If there is anything not clear there, please let us know.

[Shunwan2] I read draft-lucente-bmp-tlv-00 and find that section 4.2 of it says:
“
4.2.  TLV data in Route Monitoring

   The Route Monitoring message type is defined in Section 4.6
   [RFC7854].  The BGP Update PDU Section 4.3 [RFC4271] MAY be followed
   by TLV data.  This document defines the following new codes to help
   stateless parsing of BGP Update PDUs:

   o  Type = TBD1: the BGP Update PDU is encoded with support for
      4-octet AS number capability RFC 6793 [RFC6793], value MUST be
      boolean.

   o  Type = TBD2: the BGP Update PDU is encoded with ADD-PATH
      capability RFC 7911 [RFC7911], value MUST be boolean.

   o  Type = TBD3: the BGP Update PDU is encoded with Multiple Labels
      capability RFC 8277 [RFC8277], value MUST be boolean.
”
If I understand correctly, when we need to convey multiple paths from BMP Client to BMP Server, the BGP Update PDU should support BGP Add-Path [RFC7911] .

#2
2.1.  Path Type

                         Table 1: Path Type
[Shunwan]

[Shunwan2]
This draft says:
“
   Lastly, all paths that are considered unreachable are marked as
   'Unreachable next-hop'.  Unreachable paths may be sent only in
   special cases.
”
If we treat these remaining cases as not being able to reach the next hop routers via these receiving paths, it is ok for me.

Thanks,
Shunwan

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of Camilo Cardona
Sent: Saturday, July 06, 2019 11:04 AM
To: [email-masked]<mailto:[email-masked]> [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [GROW] Path marking using BMP - TLVs

Hello GROW,

Thanks,
Camilo Cardona

_______________________________________________
GROW mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/grow

---

From: Paolo Lucente <[email-masked]>
Date: Fri, 12 Jul 2019 11:00:50 +0000

Hi Shunwan,

Inline:

On 12 Jul 2019, at 03:32, Zhuangshunwan <[email-masked]<mailto:[email-masked]>> wrote:

[ .. ]

You are entirely right. In draft-cppy-grow-bmp-path-marking-tlv there is no mention of the add-path tlv, as defined in draft-lucente-(grow)-bmp-tlv, in case the BGP UPDATE PDU features add-path in order to carry multiple paths from a BMP client to a BMP server. A clear case in which the two works are not in complete sync; i will take care of update draft-cppy-grow-bmp-path-marking-tlv mentioning this.

Paolo

---

From: <[email-masked]>
Date: Fri, 12 Jul 2019 12:44:24 +0000

Hi Camilo, Paulo and Yunan,

Thank you very much for this exciting and very useful draft. This will make draft-ietf-grow-bmp-local-rib even more useful. On top of having access to all (not only to the best) BGP paths in BGP local RIB, thanks to this draft, we will finally understand how these BGP paths are installed in RIB/FIB. We will be able to get an network wide overview on which routers which paths have redundancy and which not. And that with ONE single query in big data.

One remark I like to add to complete all the possible path types. In section 2.1 Path Type, could you add ECMP (Equal-Cost Multipath) as path type and under Section 2.2 Reason String, the reason why it is considered ECMP. 

For BGP Equal-Cost Multipath reasons, please refer to this current draft:
https://www.ietf.org/id/draft-lapukhov-bgp-ecmp-considerations-02.txt

Kind regards
Thomas Graf
____________________________________________________________________________
Network Engineer
Datacenter Functions
Telefon	+41-58-223 84 01
Mobile	+41-79-728 80 12
[email-masked]
____________________________________________________________________________
Swisscom (Schweiz) AG
IT, Network & Infrastructure
Datacenter Functions
Binzring 17
8045 Zürich
www.swisscom.com
Postadresse:
Binzring 17
8045 Zürich

-----Original Message-----
From: GROW <[email-masked]> On Behalf Of Camilo Cardona
Sent: Saturday, July 6, 2019 5:04 AM
To: [email-masked] [email-masked] <[email-masked]>
Cc: [email-masked]
Subject: [GROW] Path marking using BMP - TLVs

Hello GROW,

Thanks,
Camilo Cardona

---

From: Paolo Lucente <[email-masked]>
Date: Fri, 12 Jul 2019 17:06:48 +0000

Hi Shunwan,

Thank you for your support and answers inline as “Paolo":

On 11 Jul 2019, at 14:25, Zhuangshunwan <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Few comments:

#1

[Paolo] You are right, i am fixing this for the next version of the document. I hope there will be a way to do this smoothly without having to re-submit the -00. Since submission is now locked, this is something i will take care of after Montreal.

#2
Abstract

[Paolo] Ack, good point. We may think to relax the wording but thing is i simply borrowed that terminology from RFC7854 section 4.9 (Peer Down Notification, see first paragraph).

#3

[Shunwan]

[Paolo] You got the scope of VRF/Table Name TLV specified in draft-ietf-grow-bmp-local-rib correct. And ”to introduce a generic mechanism for Peer Down message to use TLVs” is precisely one of the purposes of this document. Unfortunately the path forward is not without perils since Peer Down currently allows append extra data - and only to some reason codes - not necessarily in TLV format. There are multiple solutions to this aspect (not specified in the current document, which was intentionally left bland on this part for a start), from more extreme (define a new message type) to duplicate existing reason codes mandating extra data to be in TLV format, and i myself would like to receive feedback too (and indeed discuss in Montreal).

Paolo

---

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Mon, 15 Jul 2019 09:52:19 +0000

Hi Thomas,

Thanks a lot for your comments on the draft, and your elaboration on the usage of Path Marking TLV!

Regarding your suggestion of adding a "ECMP" path type, well, the currently defined "0x0004 -- Primary Path" path type should do the work. In fact, the so-called "Primary Path" in this draft refers to all the ECMP paths (including the "Best path"). Of course, we can further work on the naming.  

Thanks for sharing the ECMP reference: raft-lapukhov-bgp-ecmp-considerations-02. May I ask the use case for your proposal of adding "the reason why it is considered ECMP" reason string? Well, it's easy for me to understand that users may wonder why a path is "non-best". Do you have any specific reason string in mind for the ECMP paths?

BR,

Yunan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, July 12, 2019 8:44 PM
To: [email-masked]; [email-masked]; [email-masked]; Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]>
Cc: [email-masked]
Subject: RE: [GROW] Path marking using BMP - TLVs

Kind regards
Thomas Graf

-----Original Message-----
From: GROW <[email-masked]> On Behalf Of Camilo Cardona
Sent: Saturday, July 6, 2019 5:04 AM
To: [email-masked] [email-masked] <[email-masked]>
Cc: [email-masked]
Subject: [GROW] Path marking using BMP - TLVs

Hello GROW,

Thanks,
Camilo Cardona

---

From: <[email-masked]>
Date: Tue, 16 Jul 2019 08:06:54 +0000

Hi Yunan,

> Regarding your suggestion of adding a "ECMP" path type, well, the currently defined "0x0004 -- Primary Path" path type should do the work. In fact, the so-called "Primary Path" in this draft refers…

Just to clarify. There can be multiple primary paths and one of it will be the best path as well. Correct? If yes perfect. Thank you.

> May I ask the use case for your proposal of adding "the reason why it is considered ECMP" reason string?
When troubleshooting BGP, one of the most use cases are why a path is not installed for forwarding. One reason can be because of various configuration knobs such as:

Configuration Guide - IP Unicast Routing - BGP Configuration - Configuring BGP Load Balancing
https://support.huawei.com/enterprise/en/doc/EDOC1100004198/19f9347b/configuring-bgp-load-balancing

- maximum load-balancing (maximum-path)
- load-balancing as-path-relax

At the end we will search within BMP local-RIB collected metrics the same way as you would do on CLI described in this document. The big difference is that we will do it across all the routing contexts and across the network. Thus, much more efficiently.

Configuration Guide - IP Unicast Routing - BGP Configuration - Verifying the BGP Route Selection and Load Balancing Configuration
https://support.huawei.com/enterprise/en/doc/EDOC1100004198/6efe04ed/verifying-the-bgp-route-selection-and-load-balancing-configuration

I always have the closed loop operation in mind as well. What BMP metrics do I need so that I can trigger a configuration change to achieve the desired intend. The intend is that I want a certain selection of paths be ECMP. Two possible use cases can happen:

- To many are installed. Some of them are undesired.
- To less are installed. Some should but aren't.

If they are not installed, we should see them in "Non-installed path" or perhaps "Backup path" or "Best external path".

> Do you have any specific reason string in mind for the ECMP paths?
If they are installed then it would be great to understand in the ECMP decision process of the router within the routing context which was the last decision step. For instance:

- AS-PATH relax
- eBGP multipath
- iBGP multipath
- eiBGP multipath

draft-lapukhov-bgp-ecmp-considerations-02 shows what possibilities we have.

If we see a route marked as ECMP with "eBGP multipath" but was not intend to be part of ECMP, we could remove the configuration line "maximum load-balancing ebgp" and verify if desired route is now marked as "Non-installed path" or perhaps "Backup path" or "Best external path".

I hope this makes sense. Feedback very welcome. 

Kind regards
Thomas Graf

-----Original Message-----
From: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]> 
Sent: Monday, July 15, 2019 11:52 AM
To: Graf Thomas, INI-ONE-WSN-DCF <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [GROW] Path marking using BMP - TLVs

Hi Thomas,

BR,

Yunan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, July 12, 2019 8:44 PM
To: [email-masked]; [email-masked]; [email-masked]; Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]>
Cc: [email-masked]
Subject: RE: [GROW] Path marking using BMP - TLVs

Kind regards
Thomas Graf

-----Original Message-----
From: GROW <[email-masked]> On Behalf Of Camilo Cardona
Sent: Saturday, July 6, 2019 5:04 AM
To: [email-masked] [email-masked] <[email-masked]>
Cc: [email-masked]
Subject: [GROW] Path marking using BMP - TLVs

Hello GROW,

Thanks,
Camilo Cardona