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

[Uma Chunduri <[e-mail]>]

Les, Co-authors and WG,

Though there is a scope for minor improvements in the text, I am fine  if
you choose not to update further -  based on the responses below.

I have no further comments and initial version of the write-up has been
updated.


BR,

--
Uma C.

On Wed, Jun 13, 2018 at 12:03 AM, Les Ginsberg (ginsberg) <
[e-mail]> wrote:

> Uma –
>
>
>
> Responses inline.
>
>
>
> *From:* Uma Chunduri <[e-mail]>
> *Sent:* Tuesday, June 12, 2018 11:09 AM
> *To:* Les Ginsberg (ginsberg) <[e-mail]>
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> *Subject:* Re: draft-ietf-isis-segment-routing-extensions-16 - Shepherd
> review comments
>
>
>
> 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>.*
>
>
>
>
>
> *[Les:] If both Node A and Node B advertise (1.1.1.1/32
> <http://1.1.1.1/32>, SID 100) this is NOT a conflict. This is expected
> behavior for an anycast address.*
>
>
>
> *Examples of conflicts:*
>
>
>
> *Node A (1.1.1.1/32 <http://1.1.1.1/32>, SID 100)*
>
> *Node B (1.1.1.1/32 <http://1.1.1.1/32>, SID 200)*
>
> *(Different SIDs for the same prefix)*
>
>
>
> *Node A (1.1.1.1/32 <http://1.1.1.1/32>, SID 100)*
>
> *Node B (2.2.2.2/32 <http://2.2.2.2/32>, SID 100)*
>
> *(Same SID for different prefixes)*
>
>
>
>
>
> 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.*
>
>
>
> *[Les:] WE have deliberately kept any discussion of handling of conflicts
> (now identified as “collisions”)  out of the IGP drafts. Please see
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-14#section-2.5
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-14#section-2.5>
> for discussion of this topic – which is not protocol specific.*
>
>
>
>
>
> 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.*
>
>
>
> *[Les:] Consider the case of single topology IPv6 support. Here, a single
> IS Neighbor advertisement is used in support of IPv4 and IPv6. The
> indication of which SID is used for which address-family is therefore
> required.*
>
> *Although it is a common practice to have a 1-1 mapping between topologies
> and address-families, this is not required. 1-1 mapping  is commonly
> assumed because of the reserved MTIDs defined in RFC 5120, but a single
> topology may be used to support multiple address families. MTID 0 support
> for IPv6 is the most common example.*
>
>
>
>
>
> 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."
>
>
>
> *[Les:] What you suggest could be done. IMO it does not improve the readability of the document.*
>
> *If there is some consensus for your suggestion I am willing to make such a change – but at this point I prefer to leave the text as is.*
>
>
>
>
>
> 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. *
>
>
>
> *[Les:] I am not clear on what you think needs to specified. As the notion
> of “preference” is not relevant why would we introduce it?*
>
>
>
>    Les
>
>
>