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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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]<mailto:[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, 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, SID 100)
Node B (1.1.1.1/32, SID 200)
(Different SIDs for the same prefix)

Node A (1.1.1.1/32, SID 100)
Node B (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 (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 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