Re: [Lsr] draft-ietf-isis-segment-routing-extensions-16 - Shepherd review comments

[Uma Chunduri <[e-mail]>]

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) <
[e-mail]> 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. *