Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16

[Peter Psenak]

Hi Alvaro,

done.

Have some issues posting the new ospfv2 draft, so requested manual posting.

thanks,
Peter

On 16/11/18 22:40 , Alvaro Retana wrote:

[Took the ops-dir and the ietf@ietf lists off.]

Hi!

Joe makes a really good point below about the TLV types and RFC7770.  It
looks like we all missed it! :-(

To quote Peter (from a message in this thread), "I don't think it is
good to specify the behavior which is described somewhere else.”

Looking at -18, Section 4
(draft-ietf-ospf-ospfv3-segment-routing-extensions) has the exact same
text [*] as Section 3 in draft-ietf-ospf-segment-routing-extensions.
Given that the IANA allocation is done
in draft-ietf-ospf-segment-routing-extensions, and
that draft-ietf-ospf-ospfv3-segment-routing-extensions refers back to
it, then I would like to see the following changes:

(1) In draft-ietf-ospf-segment-routing-extensions, Section 3:


These SR capabilities are advertised in the Router Information Opaque
LSA (defined in [RFC7770]).


These SR capabilities are advertised in the Router Information Opaque
LSA (defined in [RFC7770]).  The TLVs defined below are applicable to
both OSPFv2 and OSPFv3; see also
[ID.ietf-ospf-ospfv3-segment-routing-extensions].

…and add an Informative reference to
draft-ietf-ospf-ospfv3-segment-routing-extensions.

(2) In draft-ietf-ospf-ospfv3-segment-routing-extensions, replace the
entire Section 4 with:

"
Segment Routing requires some additional router capabilities to be
advertised to other routers in the area.

These SR capabilities are advertised in the OSPFv3 Router Information
Opaque LSA (defined in [RFC7770]), and specified in
[ID.ietf-ospf-segment-routing-extensions].
“


Even though draft-ietf-ospf-segment-routing-extensions is already with
the RFC Editor, it is waiting
for draft-ietf-spring-segment-routing-mpls, so we can still make
changes.  Please submit a new version (and send an update of the XML to
the rfc-editor).

I am scheduling draft-ietf-ospf-ospfv3-segment-routing-extensions on the
Dec/6 IESG Telechat.  Please submit an update before the end of this month.

Thanks!!

Alvaro.



[*] Except for the OSPFv3 being specifically called out, and a couple of
other minor points.

On October 30, 2018 at 8:05:27 AM, Peter Psenak (ppse...@cisco.com
) wrote:


> With respect to TLV types 8, 9, 14, and 15, they are defined in
> draft-ietf-ospf-segment-routing-extensions, and it took me a while to figure
> out where you were getting those values and why they weren't spelled out in 
the
> IANA considerations. You have a normative reference to this, which is good,
> but you only mention it with respect to the algorithm parameters. I think
> another mention is required.
>
> I'm going to be pedantic here. According to RFC7770, when a new OSPF Router
> Information LSA TLV is defined, the spec needs to explicitly state if it's
> applicable to OSPFv2, v3, or both. While you reference the TLVs from
> draft-ietf-ospf-segment-routing-extensions, I didn't see that either document
> _explicitly_ states that they are applicable to both.

##PP
added the following to each of the values:

Type: X as defined in [I-D.ietf-ospf-segment-routing-extensions] and
aplicable to OSPFv3.


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

Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16

[Alvaro Retana]

[Took the ops-dir and the ietf@ietf lists off.]

Hi!

Joe makes a really good point below about the TLV types and RFC7770.  It
looks like we all missed it! :-(

To quote Peter (from a message in this thread), "I don't think it is good
to specify the behavior which is described somewhere else.”

Looking at -18, Section 4
(draft-ietf-ospf-ospfv3-segment-routing-extensions) has the exact same text
[*] as Section 3 in draft-ietf-ospf-segment-routing-extensions.  Given that
the IANA allocation is done in draft-ietf-ospf-segment-routing-extensions,
and that draft-ietf-ospf-ospfv3-segment-routing-extensions refers back to
it, then I would like to see the following changes:

(1) In draft-ietf-ospf-segment-routing-extensions, Section 3:


These SR capabilities are advertised in the Router Information Opaque LSA
(defined in [RFC7770]).


These SR capabilities are advertised in the Router Information Opaque LSA
(defined in [RFC7770]).  The TLVs defined below are applicable to both
OSPFv2 and OSPFv3; see also
[ID.ietf-ospf-ospfv3-segment-routing-extensions].

…and add an Informative reference to
draft-ietf-ospf-ospfv3-segment-routing-extensions.

(2) In draft-ietf-ospf-ospfv3-segment-routing-extensions, replace the
entire Section 4 with:

"
Segment Routing requires some additional router capabilities to be
advertised to other routers in the area.

These SR capabilities are advertised in the OSPFv3 Router Information
Opaque LSA (defined in [RFC7770]), and specified in
[ID.ietf-ospf-segment-routing-extensions].
“


Even though draft-ietf-ospf-segment-routing-extensions is already with the
RFC Editor, it is waiting for draft-ietf-spring-segment-routing-mpls, so we
can still make changes.  Please submit a new version (and send an update of
the XML to the rfc-editor).

I am scheduling draft-ietf-ospf-ospfv3-segment-routing-extensions on the
Dec/6 IESG Telechat.  Please submit an update before the end of this month.

Thanks!!

Alvaro.



[*] Except for the OSPFv3 being specifically called out, and a couple of
other minor points.

On October 30, 2018 at 8:05:27 AM, Peter Psenak (ppse...@cisco.com) wrote:

> With respect to TLV types 8, 9, 14, and 15, they are defined in
> draft-ietf-ospf-segment-routing-extensions, and it took me a while to
figure
> out where you were getting those values and why they weren't spelled out
in the
> IANA considerations. You have a normative reference to this, which is
good,
> but you only mention it with respect to the algorithm parameters. I think
> another mention is required.
>
> I'm going to be pedantic here. According to RFC7770, when a new OSPF
Router
> Information LSA TLV is defined, the spec needs to explicitly state if it's

> applicable to OSPFv2, v3, or both. While you reference the TLVs from
> draft-ietf-ospf-segment-routing-extensions, I didn't see that either
document
> _explicitly_ states that they are applicable to both.

##PP
added the following to each of the values:

Type: X as defined in [I-D.ietf-ospf-segment-routing-extensions] and
aplicable to OSPFv3.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16

[Peter Psenak]

Hi Joe,

On 31/10/18 04:15 , Joe Clarke wrote:

On 10/30/18 08:05, Peter Psenak wrote:


I'm going to be pedantic here.  According to RFC7770, when a new OSPF
Router
Information LSA TLV is defined, the spec needs to explicitly state if
it's
applicable to OSPFv2, v3, or both.  While you reference the TLVs from
draft-ietf-ospf-segment-routing-extensions, I didn't see that either
document
_explicitly_ states that they are applicable to both.


##PP
added the following to each of the values:

Type: X as defined in [I-D.ietf-ospf-segment-routing-extensions] and
aplicable to OSPFv3.


Thanks.  But s/aplicable/applicable/ :-)


fixed :)






Section 3.2

"When a router receives multiple overlapping ranges, it MUST
conform to the procedures defined in
[I-D.ietf-spring-segment-routing-mpls]."

It would be useful to include a section pointer here.  I think your
referring
to Section 2.3 where the router ignores the range?   Is it likely that
will
change to something other than "ignore?"  If not, maybe it's just worth
mentioning that here.


##PP
I don't think it is good to specify the behavior which is described
somewhere else. Regarding the section, the
ietf-spring-segment-routing-mpls is still being worked on and the
section may changes. We used the same text in OSPFv2 and ISIS SR drafts.
I would like to be consistent here.


I can agree that copying might be problematic.  But I think a section
ref is good here.  Finding the specific part about "overlapping" in this
document is kind of like a needle in a haystack.  I think it will add to
overall readability.


added the section reference.





Section 3.3

"The originating router MUST NOT advertise overlapping ranges."

You specify what a router should do if it receives overlapping ranges
above.  I
think the same text should be used here, too.


##PP
Here we say that the originating router MUST NOT advertise overlapping
ranges. We can not specify what it should do when it breaks the MUST.


I meant you have used text as to what happens when a router receives
data it should ignore in other parts.  I was asking to use similar text
here.



We specify what other routers should do when they receive overlapping
ranges and we refer it to spring-segment-routing-mpls draft. Again this
is the same as we used in OSPFv3 and ISIS SR extensions. I would like to
keep the consistency here.


Right.  But you don't re-reference that text here.  Again, I'm just
asking for consistent text that references the
spring-segment-routing-mpls drafts.


got it and updated the text.

thanks,
Peter


Joe
.



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

Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16

[Benjamin Kaduk]

On Tue, Oct 30, 2018 at 03:33:21PM +, Acee Lindem (acee) wrote:
> Hi Les,
> 
> On 10/30/18, 11:15 AM, "Les Ginsberg (ginsberg)"  wrote:
> 
> Acee -
> 
> > > Section 3.2
> > >
> > > "When a router receives multiple overlapping ranges, it MUST
> > >conform to the procedures defined in
> > >[I-D.ietf-spring-segment-routing-mpls]."
> > >
> > > It would be useful to include a section pointer here.  I think 
> your referring
> > > to Section 2.3 where the router ignores the range?   Is it likely 
> that will
> > > change to something other than "ignore?"  If not, maybe it's just 
> worth
> > > mentioning that here.
> > 
> > ##PP
> > I don't think it is good to specify the behavior which is described
> > somewhere else. Regarding the section, the
> > ietf-spring-segment-routing-mpls is still being worked on and the
> > section may changes. We used the same text in OSPFv2 and ISIS SR 
> drafts.
> > I would like to be consistent here.
> > 
> > Given that this is a normative reference, I don't think it would create 
> too
> > much of a dependency to include the section in the reference. We've had 
> a
> > protracted discussion (1-2 years) on the whole SID overlap topic in 
> SPRING
> > and I believe we've finally come up with behavior and the specification 
> of
> > such behavior with which everyone agree (or at least doesn't strongly
> > disagree).
> > 
> [Les:] I strongly agree with Peter (and disagree with you).
> Why would we want to risk having an incorrect section reference to a 
> document which is still being revised? This needlessly introduces a 
> dependency such that if the section numbering changes in the SR-MPLS draft we 
> would then have to update the dependent document(s).
> Note this has nothing to do with the SID overlap discussion itself. The 
> compelling reason to NOT discuss this in the IGP documents but simply refer 
> to the document that defines the solution is so that whatever the outcome in 
> SPRING the IGP documents do not also have to be changed.
> 
> While I don't feel as strongly as either of you, this could improve the 
> readability. For example, if you read RFC 8362 you'll see that I have 
> referred extensively to sections in RFC 5340. I may be overoptimistic but I'm 
> hoping we are finally done with the SR-MPLS draft as it is blocking all our 
> LSR SR documents. 

I also agree that specific section references can (in general) aid
readability.  And there's always "[RFC Editor: please check with authors
during AUTH48 that the section reference remains correct]"; we've done
essentially that on a document I was shepherding in the past.

-Benjamin

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

Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16

[Acee Lindem (acee)]

Hi Les,

On 10/30/18, 11:15 AM, "Les Ginsberg (ginsberg)"  wrote:

Acee -

> > Section 3.2
> >
> > "When a router receives multiple overlapping ranges, it MUST
> >conform to the procedures defined in
> >[I-D.ietf-spring-segment-routing-mpls]."
> >
> > It would be useful to include a section pointer here.  I think your 
referring
> > to Section 2.3 where the router ignores the range?   Is it likely 
that will
> > change to something other than "ignore?"  If not, maybe it's just 
worth
> > mentioning that here.
> 
> ##PP
> I don't think it is good to specify the behavior which is described
> somewhere else. Regarding the section, the
> ietf-spring-segment-routing-mpls is still being worked on and the
> section may changes. We used the same text in OSPFv2 and ISIS SR 
drafts.
> I would like to be consistent here.
> 
> Given that this is a normative reference, I don't think it would create 
too
> much of a dependency to include the section in the reference. We've had a
> protracted discussion (1-2 years) on the whole SID overlap topic in SPRING
> and I believe we've finally come up with behavior and the specification of
> such behavior with which everyone agree (or at least doesn't strongly
> disagree).
> 
[Les:] I strongly agree with Peter (and disagree with you).
Why would we want to risk having an incorrect section reference to a 
document which is still being revised? This needlessly introduces a dependency 
such that if the section numbering changes in the SR-MPLS draft we would then 
have to update the dependent document(s).
Note this has nothing to do with the SID overlap discussion itself. The 
compelling reason to NOT discuss this in the IGP documents but simply refer to 
the document that defines the solution is so that whatever the outcome in 
SPRING the IGP documents do not also have to be changed.

While I don't feel as strongly as either of you, this could improve the 
readability. For example, if you read RFC 8362 you'll see that I have referred 
extensively to sections in RFC 5340. I may be overoptimistic but I'm hoping we 
are finally done with the SR-MPLS draft as it is blocking all our LSR SR 
documents. 

Thanks,
Acee

   Les



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

Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16

[Acee Lindem (acee)]

Hi Peter, Joe, et al, 

On 10/30/18, 8:05 AM, "Peter Psenak (ppsenak)"  wrote:

Hi Joe,

thanks for your review, please see inline (##PP):

On 26/10/18 21:42 , Joe Clarke wrote:
> Reviewer: Joe Clarke
> Review result: Has Nits
>
> I have been assigned to review
> draft-ietf-ospf-ospfv3-segment-routing-extensions  on behalf of the ops
> directorate.  This document defines OSPFv3 extensions needed for segment
> routing (SR).  And therein lies my first nit.  While the document begins 
to set
> forth this overarching scope, a small paragraph in section 1 further 
limits it
> to MPLS dataplanes only.  I think perhaps the abstract should be updated 
to
> clarify that.

##PP
Done


> Other items I found are listed below.
>
> Overall, there are a lot of terminology used like RSVP, LDP, LSP, SID, 
etc.  I
> think this document would benefit from a terminology section.

##PP
added


>
> With respect to TLV types 8, 9, 14, and 15, they are defined in
> draft-ietf-ospf-segment-routing-extensions, and it took me a while to 
figure
> out where you were getting those values and why they weren't spelled out 
in the
> IANA considerations.  You have a normative reference to this, which is 
good,
> but you only mention it with respect to the algorithm parameters.  I think
> another mention is required.
>
> I'm going to be pedantic here.  According to RFC7770, when a new OSPF 
Router
> Information LSA TLV is defined, the spec needs to explicitly state if it's
> applicable to OSPFv2, v3, or both.  While you reference the TLVs from
> draft-ietf-ospf-segment-routing-extensions, I didn't see that either 
document
> _explicitly_ states that they are applicable to both.

##PP
added the following to each of the values:

Type: X as defined in [I-D.ietf-ospf-segment-routing-extensions] and 
aplicable to OSPFv3.

>
> ===
>
> Section 2.1
>
> s/length is other then 3 or 4/length is other than 3 or 4/

##PP
fixed

>
> ===
>
> Section 3.2
>
> s/If more then one SID/Label/If more than one SID/label/

##PP
fixed

>
> ===
>
> Section 3.2
>
> "When a router receives multiple overlapping ranges, it MUST
>conform to the procedures defined in
>[I-D.ietf-spring-segment-routing-mpls]."
>
> It would be useful to include a section pointer here.  I think your 
referring
> to Section 2.3 where the router ignores the range?   Is it likely that 
will
> change to something other than "ignore?"  If not, maybe it's just worth
> mentioning that here.

##PP
I don't think it is good to specify the behavior which is described 
somewhere else. Regarding the section, the 
ietf-spring-segment-routing-mpls is still being worked on and the 
section may changes. We used the same text in OSPFv2 and ISIS SR drafts. 
I would like to be consistent here.

Given that this is a normative reference, I don't think it would create too 
much of a dependency to include the section in the reference. We've had a 
protracted discussion (1-2 years) on the whole SID overlap topic in SPRING and 
I believe we've finally come up with behavior and the specification of such 
behavior with which everyone agree (or at least doesn't strongly disagree). 

>
> ===
>
> Section 3.3
>
> s/If more then one SID/Label/If more than one SID/Label/

##PP
fixed.

>
> ===
>
> Section 3.3
>
> "The originating router MUST NOT advertise overlapping ranges."
>
> You specify what a router should do if it receives overlapping ranges 
above.  I
> think the same text should be used here, too.

##PP
Here we say that the originating router MUST NOT advertise overlapping 
ranges. We can not specify what it should do when it breaks the MUST.

We specify what other routers should do when they receive overlapping 
ranges and we refer it to spring-segment-routing-mpls draft. Again this 
is the same as we used in OSPFv3 and ISIS SR extensions. I would like to 
keep the consistency here.

>
> ===
>
> Section 5
>
> "Other bits: Reserved.  These MUST be zero when sent and are
>   ignored when received."
>
> The normative language changes.  In other places you say the bits SHOULD 
be 0.
> I suggest:

##PP
Whenever we refer to "other bits" in the flag fields we use the same 
language.

>
> Other bits: Reserved.  These SHOULD be set to 0 when sent and MUST be 
ignored
> when received.

##PP
this refers to Reserved fields in the TLV (not the bits in a flag field) 
and again is used consistently across document.

I agree. Use "These SHOULD be set to 

Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16

[Peter Psenak]

Hi Joe,

thanks for your review, please see inline (##PP):

On 26/10/18 21:42 , Joe Clarke wrote:

Reviewer: Joe Clarke
Review result: Has Nits

I have been assigned to review
draft-ietf-ospf-ospfv3-segment-routing-extensions  on behalf of the ops
directorate.  This document defines OSPFv3 extensions needed for segment
routing (SR).  And therein lies my first nit.  While the document begins to set
forth this overarching scope, a small paragraph in section 1 further limits it
to MPLS dataplanes only.  I think perhaps the abstract should be updated to
clarify that.


##PP
Done



Other items I found are listed below.

Overall, there are a lot of terminology used like RSVP, LDP, LSP, SID, etc.  I
think this document would benefit from a terminology section.


##PP
added




With respect to TLV types 8, 9, 14, and 15, they are defined in
draft-ietf-ospf-segment-routing-extensions, and it took me a while to figure
out where you were getting those values and why they weren't spelled out in the
IANA considerations.  You have a normative reference to this, which is good,
but you only mention it with respect to the algorithm parameters.  I think
another mention is required.

I'm going to be pedantic here.  According to RFC7770, when a new OSPF Router
Information LSA TLV is defined, the spec needs to explicitly state if it's
applicable to OSPFv2, v3, or both.  While you reference the TLVs from
draft-ietf-ospf-segment-routing-extensions, I didn't see that either document
_explicitly_ states that they are applicable to both.


##PP
added the following to each of the values:

Type: X as defined in [I-D.ietf-ospf-segment-routing-extensions] and 
aplicable to OSPFv3.




===

Section 2.1

s/length is other then 3 or 4/length is other than 3 or 4/


##PP
fixed



===

Section 3.2

s/If more then one SID/Label/If more than one SID/label/


##PP
fixed



===

Section 3.2

"When a router receives multiple overlapping ranges, it MUST
   conform to the procedures defined in
   [I-D.ietf-spring-segment-routing-mpls]."

It would be useful to include a section pointer here.  I think your referring
to Section 2.3 where the router ignores the range?   Is it likely that will
change to something other than "ignore?"  If not, maybe it's just worth
mentioning that here.


##PP
I don't think it is good to specify the behavior which is described 
somewhere else. Regarding the section, the 
ietf-spring-segment-routing-mpls is still being worked on and the 
section may changes. We used the same text in OSPFv2 and ISIS SR drafts. 
I would like to be consistent here.




===

Section 3.3

s/If more then one SID/Label/If more than one SID/Label/


##PP
fixed.



===

Section 3.3

"The originating router MUST NOT advertise overlapping ranges."

You specify what a router should do if it receives overlapping ranges above.  I
think the same text should be used here, too.


##PP
Here we say that the originating router MUST NOT advertise overlapping 
ranges. We can not specify what it should do when it breaks the MUST.


We specify what other routers should do when they receive overlapping 
ranges and we refer it to spring-segment-routing-mpls draft. Again this 
is the same as we used in OSPFv3 and ISIS SR extensions. I would like to 
keep the consistency here.




===

Section 5

"Other bits: Reserved.  These MUST be zero when sent and are
  ignored when received."

The normative language changes.  In other places you say the bits SHOULD be 0.
I suggest:


##PP
Whenever we refer to "other bits" in the flag fields we use the same 
language.




Other bits: Reserved.  These SHOULD be set to 0 when sent and MUST be ignored
when received.


##PP
this refers to Reserved fields in the TLV (not the bits in a flag field) 
and again is used consistently across document.





===

Section 7.4.1

s/state lower then 2-Way/state lower than 2-Way/


##PP
fixed.

thanks,
Peter


===


.



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