Hi Paolo, Thanks for the reply.
Q2/A2: In fact, disabling/enabling AF separately is not motivated by use cases, in Huawei implementations, the route distinguishers (RDs) of v4 and v6 routes under the same VRF are set independently. Thus, it requires separate PEER UP messages for v4 and v6 AFs. Further, we’d like separate PEER DOWN indications. The V flag of the PER-PEER HEADER for adj-rib-in in RFC 7854 can do the work, however it’s not currently defined in the local rib PER-PEER HEADER. Do you have any suggestion as how to indicate this info in PEER DOWN? Another question pops up: regarding multiple BGP instances, currently for Huawei implementations, we may configure the same router ID and same VRF name under different BGP instances. Thus, the current local-rib PEER UP is not capable of distinguish different BGP instances under certain cases. Do you think adding a new information TLV type indicating the BGP instance name in the PEER UP (similar to the VRF/Table Name) sounds reasonable? BR, Yunan From: Paolo Lucente [mailto:pa...@ntt.net] Sent: Friday, April 05, 2019 4:35 AM To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <guyu...@huawei.com> Cc: grow@ietf.org Subject: Re: [GROW] Questions regarding draft-ietf-grow-bmp-local-rib Hi Yunan, A1: I would carry all supported AFs as part of the same OPEN message. But you could do different, say, emulate a peer for each different AF. A2: I would myself say no (hence my A1 answer). Do you see a use-case for that? A3: If you are positive on A2: would it work for you to emulate a peer for each different AF that you may want to tear down independently of the others? Paolo On 2 Apr 2019, at 06:04, Guyunan (Yunan Gu, IP Technology Research Dept. NW) <guyu...@huawei.com<mailto:guyu...@huawei.com>> wrote: Dear authors of draft-ietf-grow-bmp-local-rib, I have some questions regarding the address family indication in the local-rib PEER DOWN. Section 6.1.1. Multiple Loc-RIB Peers says: “…In some implementations, it might be required to have more than one emulated peer for Loc-RIB to convey different address families for the same Loc-RIB. In this case, the peer distinguisher and BGP ID should be the same since it represents the same Loc-RIB instance. Each emulated peer instance MUST send a PEER UP with the OPEN message indicating the address family capabilities. A BMP receiver MUST process these capabilities to know which peer belongs to which address family…” Q1: Should different address families be carried in the same OPEN message or individual messages with the PEER UP for enabling different address families? Section 5.3. Peer Down Notification says: Peer down notification SHOULD use reason code TBD3. Following the reason is data in TLV format. The following peer Down information TLV type is defined: o Type = 3: VRF/Table Name. The Information field contains an ASCII string whose value MUST be equal to the value of the VRF or table name (e.g. RD instance name) being conveyed. The string size MUST be within the range of 1 to 255 bytes. The VRF/Table Name informational TLV SHOULD be included if it was in the Peer UP. Q2: Is there a strong motivation of disabling different address families under the same VRF separately? Q3: If yes to Q2, then where to carry such information in the PEER DOWN? Thanks. Yunan Best Regards, <image001.png> Dr. Yunan Gu Huawei Technologies Co. Ltd Beijing IP Technology Research Division 156 Beiqing Rd Phone: +86 15001353906 _______________________________________________ GROW mailing list GROW@ietf.org<mailto:GROW@ietf.org> https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
