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

From: Uma Chunduri <[email-masked]>
Date: Mon, 11 Jun 2018 18:27:27 -0700

Dear Authors,

I have done shepherd  review of  draft-ietf-isis-segment-routing-extensions-16
document as requested by LSR chairs. First, I would like to thank all the
the authors and contributors on this document.
I have few minor comments below  and would be great if authors take a look
at these.

=====

A. I see few ID nits (comments and warnings). Please fix  those.

B. For the record: (as this would come up soon) : Currently there are 8
front page authors and please indicate why this document should be given
exception w.r.t 5 co-authors norm, that is being followed in general.

1. Abstract & Section 1

a.

   "These segments are   advertised by the link-state routing protocols
(IS-IS and OSPF)."

   I see more than LSR protocols e.g.
https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-07

   Also not sure if this statement is necessary. Please either correct or
remove this.

b.

   "Two    types of segments are defined, Prefix segments and Adjacency
segments."

   This document defines more than these two if you include Section 2.4
(SID/Label Binding TLV). Section 2 is much better

   where all types in this document are described as well as
[I-D.ietf-spring-segment-routing]
is referred for other types.

   In that sense the above statement looks incomplete/repetitive.

 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?

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?

c. "A Prefix-SID sub-TLV is associated to a prefix advertised by a node    and
MAY be present in any of the following TLVs:"

     Nit: Perhaps the list should include Section 2.5 too.

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.

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

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?
--
Uma C.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 12 Jun 2018 05:00:00 +0000

Uma –

Thanx for the prompt review.

I have attached proposed diffs to address some of your comments.

Additional responses inline.

From: Uma Chunduri <[email-masked]>
Sent: Monday, June 11, 2018 6:27 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: draft-ietf-isis-segment-routing-extensions-16 - Shepherd review comments

Dear Authors,

I have done shepherd  review of  draft-ietf-isis-segment-routing-extensions-16 document as requested by LSR chairs. First, I would like to thank all the the authors and contributors on this document.
I have few minor comments below  and would be great if authors take a look at these.

=====

A. I see few ID nits (comments and warnings). Please fix  those.
B. For the record: (as this would come up soon) : Currently there are 8  front page authors and please indicate why this document should be given exception w.r.t 5 co-authors norm, that is being followed in general.

[Les:] This will be addressed after discussion among the authors – thanx for the reminder. ☺

1. Abstract & Section 1

a.
   "These segments are   advertised by the link-state routing protocols (IS-IS and OSPF)."

   I see more than LSR protocols e.g. https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-07
   Also not sure if this statement is necessary. Please either correct or remove this.

[Les:] The abstract and introduction state “within IGP topologies”.  In that context I believe limiting the protocols mentioned to IGPs is appropriate.

b.
   "Two    types of segments are defined, Prefix segments and Adjacency   segments."

   This document defines more than these two if you include Section 2.4 (SID/Label Binding TLV). Section 2 is much better
   where all types in this document are described as well as   [I-D.ietf-spring-segment-routing] is referred for other types.
   In that sense the above statement looks incomplete/repetitive.

[Les:] I have revised the text in this section – see attached diffs.

 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."

[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.

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.”

c. "A Prefix-SID sub-TLV is associated to a prefix advertised by a node    and MAY be present in any of the following TLVs:"

     Nit: Perhaps the list should include Section 2.5 too.
[Les:] Added a reference to 2.5 as well. See attached diffs. Thanx.

3. Section 2.2.1

     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.

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.”

???

    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.

     Les

--
Uma C.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 12 Jun 2018 05:05:10 +0000

Uma –

One item I forgot…there are no meaningful nits.
Idnits reports:

-- Looks like a reference, but probably isn't: '100' on line 1009
     'SRGB = [100, 199]...'

  -- Looks like a reference, but probably isn't: '199' on line 1009
     'SRGB = [100, 199]...'

  -- Looks like a reference, but probably isn't: '1000' on line 1010
     '[1000, 1099]...'

  -- Looks like a reference, but probably isn't: '1099' on line 1010
     '[1000, 1099]...'

  -- Looks like a reference, but probably isn't: '500' on line 1011
     '[500, 599]...'

  -- Looks like a reference, but probably isn't: '599' on line 1011
     '[500, 599]...'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589'

The fact that idnits looks at everything enclosed in [] as a reference does not mean the text requires revision.
Idnits also does not allow that a non-RFC document can be a normative reference – but clearly ISO 10589 is a normative reference.

Thanx.

   Les

From: Les Ginsberg (ginsberg)
Sent: Monday, June 11, 2018 10:00 PM
To: Uma Chunduri <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: draft-ietf-isis-segment-routing-extensions-16 - Shepherd review comments

Uma –

From: Uma Chunduri <[email-masked]<mailto:[email-masked]>>
Sent: Monday, June 11, 2018 6:27 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: draft-ietf-isis-segment-routing-extensions-16 - Shepherd review comments

Dear Authors,

=====

1. Abstract & Section 1

a.

b.

 2. Section 2.1

3. Section 2.2.1

4. Section 2.2.2

[Les:] The text says:

???

     Les

--
Uma C.

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 12 Jun 2018 10:14:57 -0700

Uma,

Wrt number of authors, if I recall correctly (I don’t have pointers to the discussion anymore), given the lengths and involvement of the authors currently on the front page, as an exception - both ospf and isis sr drafts would keep the initial number of authors.

Thanks,
Jeff

> On Jun 11, 2018, at 22:05, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Uma –
>  

[jeff] indeed, we have used variety of non-RFC documents as normative references in the past, this should be acceptable in this case.
> To: Uma Chunduri <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> From: Uma Chunduri <[email-masked] <mailto:[email-masked]>> 
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> [Les:] This will be addressed after discussion among the authors – thanx for the reminder. J
>  
> 1. Abstract & Section 1
>  
> a.
>    I see more than LSR protocols e.g. https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-07 <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-07>
>    I see this is conflicting with what's been defined in https://tools.ietf.org/html/draft-ietf-spring-segment-routing-14 <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-14>,
> section 3.3 -
> Can you point (if any)  references to https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls <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):
>

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 12 Jun 2018 11:08:50 -0700

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-masked]> wrote:

>    "Within an anycast group, all routers in an SR domain MUST
> advertise  the same prefix with the same SID value."
>
>
>
> *[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>.*

> 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.*

>      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:] 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."

>     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. *

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 12 Jun 2018 11:13:04 -0700

Hi Jeff,

Thanks for your response. I would note the same but this is obviously with
Chairs and responsible AD's discretion.

Hi Les,

Thank you and I am fine here.

--
Uma C.

On Tue, Jun 12, 2018 at 10:14 AM, Jeff Tantsura <[email-masked]> wrote:

> Uma,
>
> Wrt number of authors, if I recall correctly (I don’t have pointers to the
> discussion anymore), given the lengths and involvement of the authors
> currently on the front page, as an exception - both ospf and isis sr drafts
> would keep the initial number of authors.
>
> Thanks,
> Jeff
>
> The fact that idnits looks at everything enclosed in [] as a reference
> does not mean the text requires revision.
> Idnits also does not allow that a non-RFC document can be a normative
> reference – but clearly ISO 10589 is a normative reference.
>
>
> [jeff] indeed, we have used variety of non-RFC documents as normative
> references in the past, this should be acceptable in this case.
>
>
> Thanx.
>
>    Les
>
>
> *From:* Les Ginsberg (ginsberg)
> *Sent:* Monday, June 11, 2018 10:00 PM
> *To:* Uma Chunduri <[email-masked]>; [email-masked]
> *Cc:* [email-masked]; l
> [email-masked]; [email-masked]
> *Subject:* RE: draft-ietf-isis-segment-routing-extensions-16 - Shepherd
> review comments
>
> Uma –
>
> *From:* Uma Chunduri <[email-masked]>
> *Sent:* Monday, June 11, 2018 6:27 PM
> *To:* [email-masked]
> *Cc:* [email-masked]; l
> [email-masked]; [email-masked]
> *Subject:* draft-ietf-isis-segment-routing-extensions-16 - Shepherd
> review comments
>
> Dear Authors,
>
> *[Les:] This will be addressed after discussion among the authors – thanx
> for the reminder. **J*
>
> 1. Abstract & Section 1
>
> a.
> *[Les:] The abstract and introduction state “within IGP topologies”.  In
> that context I believe limiting the protocols mentioned to IGPs is
> appropriate.*
>
> b.
> [I-D.ietf-spring-segment-routing] is referred for other types.
> *[Les:] I have revised the text in this section – see attached diffs.*
>
>  2. Section 2.1
>
> 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):*
>
> c. "A Prefix-SID sub-TLV is associated to a prefix advertised by a node
>    and MAY be present in any of the following TLVs:"
>
> *[Les:] Added a reference to 2.5 as well. See attached diffs. Thanx.*
>
> 3. Section 2.2.1
>
> *     Les*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 13 Jun 2018 07:03:59 +0000

Uma –

Responses inline.

From: Uma Chunduri <[email-masked]>
Sent: Tuesday, June 12, 2018 11:09 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:
Uma –

 2. Section 2.1

[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)

[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

[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

[Les:] The text says:

???

[Uma]: Sorry - I should have been more specific. Was referring to duplicated text in Section 2.2.1 and 2.2.2

 "

         be set.

         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.

[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

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 15 Jun 2018 09:21:09 -0700

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) <
[email-masked]> wrote:

> *Sent:* Tuesday, June 12, 2018 11:09 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: draft-ietf-isis-segment-routing-extensions-16 - Shepherd
> review comments
>
>
>
> Les,
>
>
>
> *This doc says - **"The 'Prefix SID' MUST   be unique within a given IGP
> *[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)*
>
>
>
>
>
> *[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
>
>
>
> *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.*
>
> *[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
>
>
>
>          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.*
>
>
>
>
>
> *[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
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 15 Jun 2018 17:11:17 +0000

Uma –

Thank you.

I have posted a new version (17) with the previously provided changes.

   Les

Sent: Friday, June 15, 2018 9:21 AM

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) <[email-masked]<mailto:[email-masked]>> wrote:
Uma –

Responses inline.

From: Uma Chunduri <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, June 12, 2018 11:09 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-isis-segment-routing-extensions-16 - Shepherd review comments

Les,

--
Uma C.

 2. Section 2.1

[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)

3. Section 2.2.1

4. Section 2.2.2

[Les:] The text says:

???

 "

         be set.

   Les