Les, Thanks for your quick response and changes in the document. Please find my further response below* [Uma]:*
-- Uma C. On Mon, Jun 11, 2018 at 10:00 PM, Les Ginsberg (ginsberg) < [email protected]> wrote: > Uma – > > > > Thanx for the prompt review. > > > > 2. Section 2.1 > > > > a. "The 'Prefix SID' MUST be unique within a given IGP domain (when the > L-flag is not set)." > > > > I see this is conflicting with what's been defined in > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-14, > > section 3.3 - > > "Within an anycast group, all routers in an SR domain MUST > advertise the same prefix with the same SID value." > > > > If you see otherwise please explain why? > > > > *[Les:] This is a misunderstanding on your part.* > > *An anycast prefix may be advertised by multiple nodes, but the Prefix SID > associated with the prefix is the same regardless of which node advertises > it. So there is no contradiction/conflict here.* > > > *[Uma]: I understood the intention.* *This doc says - "The 'Prefix SID' MUST be unique within a given IGP domain (when the L-flag is not set)." * *And it won't give any exception for "anycast group" either in the text or through reference to draft-ietf-spring-segment-routing-14 <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-14>.* > > > b. "A 4 octet index defining.." > > What happens to the computed label value if the index is of 4 octets > value? I am asking this as index can have 4 octets but the eventual label > (SRGB offset + index) would be only 20 bits. > > Can you point (if any) references to https://tools.ietf.org/html/ > draft-ietf-spring-segment-routing-mpls appropriate sections - is this is > addressed there? > > > > *[Les:] See > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-14#section-2.4 > <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-14#section-2.4> > (emphasis added):* > > > > *“ 0 =< I < size. If the index "I" does not satisfy the previous* > > * inequality, **then the label cannot be calculated**.”* > *[Uma]: Thanks for the pointer. I am fine with keeping this at a common place but this document needs a generic reference specifically for some of the conflict/error conditions to that.* > > > 3. Section 2.2.1 > > > > a. "F-Flag: Address-Family flag..." > > > > Not sure why this has to do with encapsulation? What happens if > native IPv4/IPv6 data packet is using this SID with out any encapsulation? > Could you please clarify. > > > > *[Les:] When the packet is forwarded over the specified outgoing interface > it will either have an IPv4 encapsulation or an IPv6 encapsulation i.e., > the payload is encapsulated in the afi specific L3 protocol. * > > *This does not mean that a new AFI specific header is imposed.* > > > *[Uma]: Thanks. I didn't expect payload encapsulation with L3 in IS-IS document. I see this is derived from the base TLV where this sub-TLV belongs to (22/222/223 etc.). This sounded like additional encap and hence my comment.* *But one of my larger point here is why a sub-TLV has to specify/define AF. This is the property of the associated TLV/MT-aware TLV.* *I understand this could be too late to change here but this additional information should not conflict with base while usage. * *One incorrect usage *example* of this sub-TLV with AF unset (IPv4) in TLV 222 with MT-ID=2 (IPv6).* *As it stands this combinations valid/allowed. Perhaps some text around this would be helpful.* > 4. Section 2.2.2 > > > > a. Nit: V and L flags: Content is duplicated and perhaps it can instead > refer to section 2.2.1 > > > > > > *[Les:] The text says:* > > *“ where F, B, V, L, S and P flags are defined in Section 2.2.1.”* > > > > *???* > *[Uma]: Sorry - I should have been more specific. Was referring to duplicated text in Section 2.2.1 and 2.2.2* " * A 3 octet local label where the 20 rightmost bits are used for encoding the label value. In this case the V and L flags MUST be set. * A 4 octet index defining the offset in the SID/Label space advertised by this router using the encodings defined in Section 3.1 <https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16#section-3.1>. In this case V and L flags MUST be unset." > > > > 5. Section 3.2 and Section 2.1 > > > > Could you please clarify what is preferred if multiple prefix-sids > with different algorithm values are advertised for the same SID value? > > > > *[Les:] There is no “preference” here. In order to have algorithm specific > forwarding entries we MUST have different SIDs for each algorithm. A router > will use the SID which matches the algorithm associated with the forwarding > entry.* > *[Uma]: ..and IMO, this should be specified. *
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
