Hi Camilo, Thanks for your quick response, please check my reply inline with [Shunwan2].
BR, Shunwan From: Camilo Cardona [mailto:[email protected]] Sent: Friday, July 12, 2019 1:31 AM To: Zhuangshunwan <[email protected]> Cc: [email protected] [email protected] <[email protected]>; [email protected] Subject: Re: [GROW] Path marking using BMP - TLVs Hi Shunwan, Thanks for the comments, answers inline. Camilo On 11 Jul 2019, at 06:29, Zhuangshunwan <[email protected]<mailto:[email protected]>> wrote: 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. [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 +--------+----------------------+ | 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. [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. [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 protected]] On Behalf Of Camilo Cardona Sent: Saturday, July 06, 2019 11:04 AM To: [email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: [GROW] Path marking using BMP - TLVs 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 _______________________________________________ GROW mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
