Hi Dale, Thank you for your review of the document. Please, see my comments inline. The document has been edited, but since the datatracker is closed it will take some time until the changes are online. Cheers Christoph -- Christoph Loibl c@xxxxxx | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > > Nits/editorial comments: > > 3.1. Type 1 - Destination IPv6 Prefix > 3.2. Type 2 - Source IPv6 Prefix > > Unlike IPv4, it is plausible that a set of flows could be determined > by two contiguous sections of an address, e.g., an initial prefix and > a subset of bits within an embedded IPv4 address. By > draft-ietf-idr-rfc5575bis-26 section 4.2, an IPv6 flow specification > may not contain two Destination IPv6 Prefix or two Source IPv6 Prefix > components, so this type of selection cannot be specified. A single Flow Specificaton NLRI "rule" can only contain a single destination (Type1) and a single source prefix (Type 2). However you can have multiple FS rules "like firewall rules" matching different src/dst pairs. > > 1. Ordering of Flow Specifications > > If the offsets are not equal, the lowest offset has > precedence, as this flow matches the most significant bit. > > "as this flow" should be "as this flow specification" Edited as suggested. > > 1. Validation Procedure > a) A destination prefix component with offset=0 is embedded in the > Flow Specification > > I note that this requirement has no functional effect, as a > destination prefix with length = 0 can always be added to a flow > specification without effect. However, this observation also applies > to IPv4 flow specifications, so I assume it has been given due > consideration. A length=0 destination-prefix (IPv4 or IPv6 FS) would match every destination prefix. This will only validate if the BGP neighbor announces a default route and you are only following this single route (very unlikely though). -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
