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

[Les Ginsberg (ginsberg)]

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 ; lsr@ietf.org
Cc: draft-ietf-isis-segment-routing-extensi...@ietf.org; lsr-cha...@ietf.org; 
lsr-...@ietf.org
Subject: RE: draft-ietf-isis-segment-routing-extensions-16 - Shepherd review 
comments

Uma –

Thanx for the prompt review.

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

Additional responses inline.


From: Uma Chunduri mailto:umac.i...@gmail.com>>
Sent: Monday, June 11, 2018 6:27 PM
To: lsr@ietf.org
Cc: 
draft-ietf-isis-segment-routing-extensi...@ietf.org;
 lsr-cha...@ietf.org; 
lsr-...@ietf.org
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.
   "Twotypes 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."

   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.


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 nodeand 
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

a. "F-Flag: A

Re: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up)

[Henderickx, Wim (Nokia - BE/Antwerp)]

I am not aware of IPR related to this draft

From: Lsr  on behalf of Hannes Gredler 
Date: Tuesday, 12 June 2018 at 04:44
To: Uma Chunduri 
Cc: "lsr@ietf.org" 
Subject: Re: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 
(Shepherd write-up)

i am not aware of undisclosed IPR.

On 11.06.2018, at 21:18, Uma Chunduri 
mailto:umac.i...@gmail.com>> wrote:
Dear All,

Are you aware of any IPR that applies to
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16 ?

Sending this email as suggested by LSR chairs - as this was not noticed 
during/around WGLC.

===
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)..

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.
===

--
Uma C.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up)

[Hannes Gredler]

i am not aware of undisclosed IPR.

> On 11.06.2018, at 21:18, Uma Chunduri  wrote:
> 
> Dear All,
> 
> Are you aware of any IPR that applies to 
> https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16 ? 
> 
> Sending this email as suggested by LSR chairs - as this was not noticed 
> during/around WGLC.
> 
> ===
> If so, has this IPR been disclosed in compliance with IETF IPR rules 
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
> 
> If you are listed as a document author or contributor please respond
> to this email regardless of whether or not you are aware of any
> relevant IPR. *The response needs to be sent to the LSR WG mailing
> list.* The document will not advance to the next stage until a
> response has been received from each author and contributor.
> 
> If you are on the LSR WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of
> any IPR that has not yet been disclosed in conformance with IETF rules.
> ===
> 
> --
> Uma C.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Uma Chunduri]

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.

   "Twotypes 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 nodeand
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.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up)

[Ahmed Bashandy]

I am not aware of any IPR other than what has not been already disclosed.

Thanks

Ahmed


On 6/11/18 1:50 PM, Les Ginsberg (ginsberg) wrote:


I am not aware of any IPR other than what has already been disclosed.

Les

*From:*Lsr  *On Behalf Of *Uma Chunduri
*Sent:* Monday, June 11, 2018 12:18 PM
*To:* lsr@ietf.org
*Subject:* [Lsr] IPR Poll on 
draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up)


Dear All,

Are you aware of any IPR that applies to

https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16 
?


Sending this email as suggested by LSR chairs - as this was not 
noticed during/around WGLC.


===

If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond

to this email regardless of whether or not you are aware of any

relevant IPR. *The response needs to be sent to the LSR WG mailing

list.* The document will not advance to the next stage until a

response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of

any IPR that has not yet been disclosed in conformance with IETF rules.

===

--

Uma C.



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up)

[Les Ginsberg (ginsberg)]

I am not aware of any IPR other than what has already been disclosed.

   Les


From: Lsr  On Behalf Of Uma Chunduri
Sent: Monday, June 11, 2018 12:18 PM
To: lsr@ietf.org
Subject: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 
(Shepherd write-up)

Dear All,

Are you aware of any IPR that applies to
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16 ?

Sending this email as suggested by LSR chairs - as this was not noticed 
during/around WGLC.

===
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.
===

--
Uma C.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up)

[Jeff Tantsura]

Uma,

 

I’m not aware of any IPR that has not been previously disclosed. 

 

Cheers,

Jeff

From: Lsr  on behalf of Uma Chunduri 

Date: Monday, June 11, 2018 at 12:18
To: 
Subject: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 
(Shepherd write-up)

 

Dear All,

 

Are you aware of any IPR that applies to 

https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16 ? 

 

Sending this email as suggested by LSR chairs - as this was not noticed 
during/around WGLC.

 

===

If so, has this IPR been disclosed in compliance with IETF IPR rules 

(see RFCs 3979, 4879, 3669 and 5378 for more details).

 

If you are listed as a document author or contributor please respond

to this email regardless of whether or not you are aware of any

relevant IPR. *The response needs to be sent to the LSR WG mailing

list.* The document will not advance to the next stage until a

response has been received from each author and contributor.

 

If you are on the LSR WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of

any IPR that has not yet been disclosed in conformance with IETF rules.

===

 

--

Uma C.

___ Lsr mailing list Lsr@ietf.org 
https://www.ietf.org/mailman/listinfo/lsr 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up)

[bruno.decraene]

I’m not aware of non-disclosed IPR.

Regards,
--Bruno,


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Uma Chunduri
Sent: Monday, June 11, 2018 9:18 PM
To: lsr@ietf.org
Subject: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 
(Shepherd write-up)

Dear All,

Are you aware of any IPR that applies to
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16 ?

Sending this email as suggested by LSR chairs - as this was not noticed 
during/around WGLC.

===
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.
===

--
Uma C.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up)

[Uma Chunduri]

Dear All,

Are you aware of any IPR that applies to
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16 ?

Sending this email as suggested by LSR chairs - as this was not noticed
during/around WGLC.

===
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.
===

--
Uma C.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Gentle Reminder!!!Re: draft-ietf-isis-te-app: Clarification on Application Identifier bits

[Les Ginsberg (ginsberg)]

Mahend –

In regards to IPv4/IPv6, in IS-IS there are two ways to support this:

1)Multi-topology mode

Here there are topology specific neighbor advertisements and therefore topology 
specific link attribute advertisements. Hence no benefit from having 
afi-specific bits.

2)Single topology mode

Both address-families are supported on a single topology. Every link in the 
topology MUST support both address families for this configuration to work.
So although we do not have afi specific neighbors, the topology congruence 
argues against any need for AFI specific link attribute advertisements.

As regards SR-MPLS/SRv6, I expect that – other than as a transition strategy – 
we won’t have deployments where both technologies are in use for IPv6.  (You 
certainly could have SR-MPLS for IPv4 and SRv6 for IPv6.) Therefore, in 
combination with MT, there does not seem to be a use case for different 
advertisements for SR-MPLS/SRv6.

(BTW, the same arguments hold for OSPF – and even more so because there would 
be different instances of the protocol for each address family.)

   Les


From: Mahend Negi 
Sent: Saturday, June 09, 2018 7:35 PM
To: draft-ietf-isis-te-...@ietf.org
Cc: lsr@ietf.org; stef...@previdi.net; Les Ginsberg (ginsberg) 
; jdr...@juniper.net
Subject: Gentle Reminder!!!Re: draft-ietf-isis-te-app: Clarification on 
Application Identifier bits

Dear Authors,

Could you please help me with the query.

Please confirm about the new bit for SRv6-TE applications.
We are working on this draft implementation.

Regards,
Mahendra
On Wed, Jun 6, 2018, 11:49 Mahend Negi 
mailto:mahend.i...@gmail.com>> wrote:

Dear Authors,
I seek few clarifications on "Application Identifier bits".

As defined in the draft:


R-bit: RSVP-TE

S-bit: Segment Routing Traffic Engineering

F-bit: Loop Free Alternate

X-bit: Flex-Algo



Am I right, when I say:

R-bit: For RSVP-TE on IPv6 and IPv4 networks.

S-bit: For SR MPLS and SRv6-TE applications.



I think a bit to be allocated for SRv6-TE applications?

Not sure about RSVP-TE IPv6 case.

If you please your opinion.



Regards,

Mahendra
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr