Awesome thanks Colin! W On Thu, Jul 15, 2021 at 5:03 AM Colin Petrie <co...@spakka.net> wrote: > > I checked the encoding of the attribute, the errata looks correct to me > also. > > Thanks, > Colin > > > > > On 13/07/2021 15:22, Warren Kumari wrote: > > [ - RFC Editor (for clutter) ] > > > > Dear GROW, > > > > AFAICT, this errata is correct, and should be Verified, but I'd like > > some confirmation / double-checkin'. > > > > Note that there is already a somewhat related errata: > > https://www.rfc-editor.org/errata_search.php?rfc=6396&rec_status=0 > > > > Please let me know by Friday (July 16th) if you disagree with the Errata. > > W > > > > On Tue, Jul 13, 2021 at 9:01 AM RFC Errata System > > <rfc-edi...@rfc-editor.org> wrote: > >> > >> The following errata report has been submitted for RFC6396, > >> "Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> https://www.rfc-editor.org/errata/eid6640 > >> > >> -------------------------------------- > >> Type: Technical > >> Reported by: Claudio Jeker <cje...@diehard.n-r-g.com> > >> > >> Section: Appendix A > >> > >> Original Text > >> ------------- > >> | BGP Path Attributes = > >> > >> 40 01 01 00 50 02 00 0e 02 03 00 00 fb f0 00 00 > >> fb ff 00 00 fb f6 80 0e 2b 00 02 01 20 20 01 0d > >> b8 00 0d 00 ff 00 00 00 00 00 00 01 87 fe 80 00 > >> 00 00 00 00 00 02 12 f2 ff fe 9f 1b 00 00 00 20 > >> 20 01 0d b8 > >> > >> Figure 19: MRT RIB_IPV6_UNICAST Example > >> > >> The contents of the BGP Path Attribute field above are as follows: > >> > >> ORIGIN: IGP > >> ASPATH: 64496 64511 64502 > >> MP_REACH_NLRI(IPv6 Unicast) > >> NEXT_HOP: 2001:db8:d:ff::187 > >> NEXT_HOP: fe80::212:f2ff:fe9f:1b00 > >> NLRI: 2001:0DB8::/32 > >> > >> Figure 20: BGP Path Attribute Contents > >> > >> > >> Corrected Text > >> -------------- > >> | BGP Path Attributes = > >> > >> 40 01 01 00 50 02 00 0e 02 03 00 00 fb f0 00 00 > >> fb ff 00 00 fb f6 80 0e 21 20 20 01 0d b8 00 0d > >> 00 ff 00 00 00 00 00 00 01 87 fe 80 00 00 00 00 > >> 00 00 02 12 f2 ff fe 9f 1b 00 > >> > >> Figure 19: MRT RIB_IPV6_UNICAST Example > >> > >> The contents of the BGP Path Attribute field above are as follows: > >> > >> ORIGIN: IGP > >> ASPATH: 64496 64511 64502 > >> MP_REACH_NLRI(IPv6 Unicast) > >> NEXT_HOP: 2001:db8:d:ff::187 > >> NEXT_HOP: fe80::212:f2ff:fe9f:1b00 > >> > >> Figure 20: BGP Path Attribute Contents > >> > >> > >> Notes > >> ----- > >> The encoding of the MP_REACH_NLRI attribute is not in the form according > >> to Section 4.3.4. RIB Entries: > >> > >> There is one exception to the encoding of BGP attributes for the BGP > >> MP_REACH_NLRI attribute (BGP Type Code 14) [RFC4760]. Since the AFI, > >> SAFI, and NLRI information is already encoded in the RIB Entry Header > >> or RIB_GENERIC Entry Header, only the Next Hop Address Length and > >> Next Hop Address fields are included. The Reserved field is omitted. > >> The attribute length is also adjusted to reflect only the length of > >> the Next Hop Address Length and Next Hop Address fields. > >> > >> The example includes a full MP_REACH_NLRI attribute. This is a common > >> issue with TABLE_DUMP_V2 and parsers need to implement a workaround to > >> support the broken form. > >> > >> One way of solving this is to compare the attribute length of > >> MP_REACH_NLRI with the first byte of the attribute. > >> If the value of the first byte is equal to the attribute lenght - 1 then > >> it is the RFC encoding else assume that a full MP_REACH_NLRI attribute was > >> dumped in which case the parser needs to skip the first 3 bytes to get to > >> the nexthop. > >> > >> Instructions: > >> ------------- > >> This erratum is currently posted as "Reported". If necessary, please > >> use "Reply All" to discuss whether it should be verified or > >> rejected. When a decision is reached, the verifying party > >> can log in to change the status and edit the report, if necessary. > >> > >> -------------------------------------- > >> RFC6396 (draft-ietf-grow-mrt-17) > >> -------------------------------------- > >> Title : Multi-Threaded Routing Toolkit (MRT) Routing > >> Information Export Format > >> Publication Date : October 2011 > >> Author(s) : L. Blunk, M. Karir, C. Labovitz > >> Category : PROPOSED STANDARD > >> Source : Global Routing Operations > >> Area : Operations and Management > >> Stream : IETF > >> Verifying Party : IESG > > > > > > >
-- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
