Re: [Lsr] Secdir last call review of draft-ietf-isis-segment-routing-msd-16

[Les Ginsberg (ginsberg)]

Benjamin -

It is not my intent to engage in a debate with you.

I serve as Designated Expert for a number of IS-IS registries. I consider it my 
responsibility to understand the technical content of the drafts which make 
changes to the registries for which I serve in this role. I do not look for or 
expect technical content in the IANA sections - I only expect them to be 
accurate in terms of the changes requested/completed to the registries.

I have no doubt that we still disagree. If there is some consensus to make 
changes I will certainly listen - but if left up to me I would leave the IANA 
section as is.

   Les

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Wednesday, September 26, 2018 6:21 PM
> To: Les Ginsberg (ginsberg) 
> Cc: David Waltermire ; sec...@ietf.org;
> lsr@ietf.org; i...@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
> Subject: Re: Secdir last call review of draft-ietf-isis-segment-routing-msd-16
> 
> On Wed, Sep 26, 2018 at 11:24:31PM +, Les Ginsberg (ginsberg) wrote:
> > Benjamin -
> >
> >
> >
> > Please review https://tools.ietf.org/html/rfc8126#section-1.1
> >
> >
> >
> > In particular (emphasis added):
> >
> >
> >
> > " The purpose of having a dedicated IANA Considerations section is to
> >
> >provide a single place to collect clear and concise information and
> >
> >instructions for IANA.  Technical documentation should reside in
> >
> >other parts of the document…”
> >
> >
> >
> > I think what you propose is not consistent with the intent of the IANA
> section.
> 
> What about Section 1.1, "guidance describing the conditions under which
> new values should be assigned [...] is needed", or section 1.3's checklist:
> 
>7.  If you're using a policy that requires a designated expert
>(Expert Review or Specification Required), understand Section 5
>and provide review guidance to the designated expert (see
>Section 5.3).
> 
> Section 4.5 (Expert Review) even goes into more detail, though I'll stop
> quoting now.
> 
> -Benjamin
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Secdir last call review of draft-ietf-isis-segment-routing-msd-16

[Benjamin Kaduk]

On Wed, Sep 26, 2018 at 11:24:31PM +, Les Ginsberg (ginsberg) wrote:
> Benjamin -
> 
> 
> 
> Please review https://tools.ietf.org/html/rfc8126#section-1.1
> 
> 
> 
> In particular (emphasis added):
> 
> 
> 
> " The purpose of having a dedicated IANA Considerations section is to
> 
>provide a single place to collect clear and concise information and
> 
>instructions for IANA.  Technical documentation should reside in
> 
>other parts of the document…”
> 
> 
> 
> I think what you propose is not consistent with the intent of the IANA 
> section.

What about Section 1.1, "guidance describing the conditions under which new
values should be assigned [...] is needed", or section 1.3's checklist:

   7.  If you're using a policy that requires a designated expert
   (Expert Review or Specification Required), understand Section 5
   and provide review guidance to the designated expert (see
   Section 5.3).

Section 4.5 (Expert Review) even goes into more detail, though I'll stop
quoting now.

-Benjamin

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

Re: [Lsr] Secdir last call review of draft-ietf-isis-segment-routing-msd-16

[Les Ginsberg (ginsberg)]

Benjamin -



Please review https://tools.ietf.org/html/rfc8126#section-1.1



In particular (emphasis added):



" The purpose of having a dedicated IANA Considerations section is to

   provide a single place to collect clear and concise information and

   instructions for IANA.  Technical documentation should reside in

   other parts of the document…”



I think what you propose is not consistent with the intent of the IANA section.



Thanx.



Les





> -Original Message-

> From: Benjamin Kaduk 

> Sent: Wednesday, September 26, 2018 4:06 PM

> To: Les Ginsberg (ginsberg) 

> Cc: David Waltermire ; sec...@ietf.org;

> lsr@ietf.org; i...@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org

> Subject: Re: Secdir last call review of draft-ietf-isis-segment-routing-msd-16

>

> On Wed, Sep 26, 2018 at 10:59:50PM +, Les Ginsberg (ginsberg) wrote:

> > Benjamin -

> >

> > Responses nline.

> >

> > > -Original Message-

> > > From: Benjamin Kaduk mailto:ka...@mit.edu>>

> > > Sent: Wednesday, September 26, 2018 2:11 PM

> > > To: Les Ginsberg (ginsberg) 
> > > mailto:ginsb...@cisco.com>>

> > > Cc: David Waltermire 
> > > mailto:david.walterm...@nist.gov>>; 
> > > sec...@ietf.org;

> > > lsr@ietf.org; i...@ietf.org;

> > > draft-ietf-isis-segment-routing-msd@ietf.org

> > > Subject: Re: Secdir last call review of

> > > draft-ietf-isis-segment-routing-msd-16

> > >

> > > On Wed, Sep 26, 2018 at 08:45:03PM +, Les Ginsberg (ginsberg)

> wrote:

> > > > David -

> > > >

> > > > Thanx for the review.

> > > > A new version of the draft (17) has been published to address your

> > > comments - subject to my responses below.

> > >

> > > Just in time for me to see the updated version for my IESG review;

> thanks.

> > >

> > > > > -Original Message-

> > > > > From: David Waltermire 
> > > > > mailto:david.walterm...@nist.gov>>

> > > > > Sent: Tuesday, September 25, 2018 12:14 PM

> > > > > To: sec...@ietf.org

> > > > > Cc: lsr@ietf.org; 
> > > > > i...@ietf.org;

> > > > > draft-ietf-isis-segment-routing- 
> > > > > msd@ietf.org

> > > > > Subject: Secdir last call review of

> > > > > draft-ietf-isis-segment-routing-msd-16

> > > > >

> > > > > Reviewer: David Waltermire

> > > > > Review result: Has Issues

> > > > >

> > > > > I have reviewed this document as part of the security

> > > > > directorate's ongoing effort to review all IETF documents being

> > > > > processed by the IESG.  These comments were written primarily

> > > > > for the benefit of the security area directors.

> > > > >  Document editors and WG chairs should treat these comments just

> > > > > like any other last call comments.

> > > > >

> > > > > The summary of the review is Ready with (minor) issues

> > > > >

> > > > > My apologies for the late review on this draft. Overall I found

> > > > > this document to be well-written, and concise.

> > > > >

> > > > > General Comments:

> > > > >

> > > > > This document uses a mix of case around RFC2119 language (e.g.,

> > > > > MAY

> > > may).

> > > > > You should use text from RFC8174 to indicate that lowercase

> > > > > versions of the keywords are not normative, or adjust the case

> > > > > of the lowercase words to ensure there is no confusion.

> > > > >

> > > > [Les:] Section 1.2 does include the standard boilerplate for RFC

> > > 2119/RFC8174.

> > > >

> > > > I checked all the lower case uses of "may" and they are intentional.

> > > > There was one instance of "should" that I changed to uppercase.

> > > >

> > > > > Minor nit: There is some inconsistency in the use of "MSD-Type"

> > > > > (the

> > > > > value) and "MSD type" (the concept). Suggest cleaning this up.

> > > > >

> > > > [Les:] Done

> > > >

> > > > > Specific comments:

> > > > >

> > > > > Section 1:

> > > > >

> > > > > Para 1: s/to insure/to ensure/

> > > >

> > > > [Les:] Done.

> > > >

> > > > >

> > > > > Section 4:

> > > > >

> > > > > The last paragraph establishes a requirement on the registration

> > > > > of an MSD Type to define what the absence of a given MSD Type

> means.

> > > > > This is an important requirement that must be addressed during

> > > > > registration of new MSD Types. IMHO, this requirement should be

> > > > > echoed in the registration information in section 6 to make sure

> > > > > it is not

> > > overlooked.

> > > > >

> > > > [Les:] I disagree. Section 6 is defining exactly what should go

> > > > into the new

> > > IANA registry.

> > > > The definition of "absence" is something that will have to be

> > > > provided in

> > > the documents which define new MSD-types, but that will NOT be

> > > captured in the registry so including this in Section 6 isn’t appropriate.

> > >

> 

Re: [Lsr] Secdir last call review of draft-ietf-isis-segment-routing-msd-16

[Les Ginsberg (ginsberg)]

Benjamin -

Responses nline.

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Wednesday, September 26, 2018 2:11 PM
> To: Les Ginsberg (ginsberg) 
> Cc: David Waltermire ; sec...@ietf.org;
> lsr@ietf.org; i...@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
> Subject: Re: Secdir last call review of draft-ietf-isis-segment-routing-msd-16
> 
> On Wed, Sep 26, 2018 at 08:45:03PM +, Les Ginsberg (ginsberg) wrote:
> > David -
> >
> > Thanx for the review.
> > A new version of the draft (17) has been published to address your
> comments - subject to my responses below.
> 
> Just in time for me to see the updated version for my IESG review; thanks.
> 
> > > -Original Message-
> > > From: David Waltermire 
> > > Sent: Tuesday, September 25, 2018 12:14 PM
> > > To: sec...@ietf.org
> > > Cc: lsr@ietf.org; i...@ietf.org; draft-ietf-isis-segment-routing-
> > > msd@ietf.org
> > > Subject: Secdir last call review of
> > > draft-ietf-isis-segment-routing-msd-16
> > >
> > > Reviewer: David Waltermire
> > > Review result: Has Issues
> > >
> > > I have reviewed this document as part of the security directorate's
> > > ongoing effort to review all IETF documents being processed by the
> > > IESG.  These comments were written primarily for the benefit of the
> > > security area directors.
> > >  Document editors and WG chairs should treat these comments just
> > > like any other last call comments.
> > >
> > > The summary of the review is Ready with (minor) issues
> > >
> > > My apologies for the late review on this draft. Overall I found this
> > > document to be well-written, and concise.
> > >
> > > General Comments:
> > >
> > > This document uses a mix of case around RFC2119 language (e.g., MAY
> may).
> > > You should use text from RFC8174 to indicate that lowercase versions
> > > of the keywords are not normative, or adjust the case of the
> > > lowercase words to ensure there is no confusion.
> > >
> > [Les:] Section 1.2 does include the standard boilerplate for RFC
> 2119/RFC8174.
> >
> > I checked all the lower case uses of "may" and they are intentional.
> > There was one instance of "should" that I changed to uppercase.
> >
> > > Minor nit: There is some inconsistency in the use of "MSD-Type" (the
> > > value) and "MSD type" (the concept). Suggest cleaning this up.
> > >
> > [Les:] Done
> >
> > > Specific comments:
> > >
> > > Section 1:
> > >
> > > Para 1: s/to insure/to ensure/
> >
> > [Les:] Done.
> >
> > >
> > > Section 4:
> > >
> > > The last paragraph establishes a requirement on the registration of
> > > an MSD Type to define what the absence of a given MSD Type means.
> > > This is an important requirement that must be addressed during
> > > registration of new MSD Types. IMHO, this requirement should be
> > > echoed in the registration information in section 6 to make sure it is not
> overlooked.
> > >
> > [Les:] I disagree. Section 6 is defining exactly what should go into the new
> IANA registry.
> > The definition of "absence" is something that will have to be provided in
> the documents which define new MSD-types, but that will NOT be captured
> in the registry so including this in Section 6 isn’t appropriate.
> 
> I think a good way to think about this is as giving guidance to the Experts, 
> that
> they should not approve registration requests that fail to provide this
> information along with the request.  Guidance for the Experts is appropriate
> in the IANA Considerations section.
> (Also, my understanding is that IANA prefers to have a more explicit
> template for new registrations to follow, though I should not try to speak for
> them.)
> 

[Les:] The reason we use "experts" is because we know/expect them to be 
familiar with the documents which define the TLVs (unlike a "general IETF 
reader" whose familiarity with the subject matter may vary).
Repeating what is said in Section 4 in Section 6 only makes sense if you think 
the "expert" only reads IANA sections. Such a person would not be an expert 
IMO. :-)

   Les

> >
> > > Section 6:
> > >
> > > The "Base MPLS Imposition MSD" should reference section 5 of this
> > > document.
> >
> > [Les:] Again - Section 6 is defining what will go into the registry. The 
> > registry
> will reference the document - not a specific section of the document.
> 
> The contents of the "Reference" column for Value 1 can refer to a specific
> section of a document, surely?
> 
> > >
> > > The registration for "Experimental" should be marked as "Reserved
> > > for Experimental Use" or just "Experimental Use" to align with
> > > RFC8126. RFC8126 states that "it is not appropriate for documents to
> > > select explicit values from registries or ranges with this policy".
> > > It might be good to add a note alongside the one on "Designated
> > > Experts" indicating that values from this range are not assignable.
> > >
> > [Les:] I have changed the text to "Experimental Use".
> > I think the rest of your comment is addressed by RF

Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-msd-17: (with COMMENT)

[Les Ginsberg (ginsberg)]

Benjamin -

Responses inline.

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Wednesday, September 26, 2018 2:46 PM
> To: The IESG 
> Cc: draft-ietf-isis-segment-routing-...@ietf.org; Christian Hopps
> ; aretana.i...@gmail.com; lsr-cha...@ietf.org;
> cho...@chopps.org; lsr@ietf.org
> Subject: Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-
> msd-17: (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-isis-segment-routing-msd-17: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/
> 
> 
> 
> --
> COMMENT:
> --
> 
> The shepherd writeup is silent about the WG's discussion of the IPR
> disclosure (but the corresponding ospf draft says this sort of thing is 
> typical
> for LSR drafts).
> 
> Section 3
> 
>The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and
>223 to carry the MSD of the interface associated with the link.  MSD
> 
> Please add the appropriate qualifier (IS-IS?) before the list of TLV numbers.
> 
[Les:] The document is an IS-IS document. Such a statement is therefore 
unnecessary.

>MSD-Value is a number in the range of 0-255.  For all MSD-Types, 0
>represents lack of the ability to support SID stack of any depth; any
>other value represents that of the link.
> 
> It's unclear that there's a referent for "that of the link" to attach to.
> That is, is it better to say "represents the maximum SID depth supported by
> the link" (or similar)?
> 
[Les:] Would you be satisfied with the corresponding text in the OSPF document?

" any other value represents that of the particular link when used as an 
outgoing
   interface."

> Section 6
> 
> As discussed in the secdir review, this section needs to include guidance to
> the Experts to check that the meaning of the absence of an MSD type is
> specified.  Given the text in draft-ietf-ospf-segment-routing-msd that
> attempts to place a similar requirement on future MSD types (but for OSPF
> vs. IS-IS usage thereof), hopefully this guidance can be phrased in an
> appropriately general fashion so as to apply to all places where the 
> registered
> MSD value would be used.
> 
[Les:] I have answered this twice already. :-)

> Section 7
> 
>Advertisement of the additional information defined in this document
>that is false, e.g., an MSD that is incorrect, may result in a path
>computation failing, having a service unavailable, or calculation of
>a path that cannot be supported by the head-end (the node performing
>the imposition).
> 
> In the analogous OSPF document we split out the case of a value that is too
> small and a value that is too large, to describe the different consequences.
> 
> I would also suggest rewording to something like "calculation by the head-
> end of a path that cannot be supported" to avoid the mis-parsing
> "(calculation of a path) (that cannot be supported by the head-end)".
> 

[Les:] I will align w the equivalent OSPF text in the next revision.

   Les

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

Re: [Lsr] Secdir last call review of draft-ietf-isis-segment-routing-msd-16

[Benjamin Kaduk]

On Wed, Sep 26, 2018 at 10:59:50PM +, Les Ginsberg (ginsberg) wrote:
> Benjamin -
> 
> Responses nline.
> 
> > -Original Message-
> > From: Benjamin Kaduk 
> > Sent: Wednesday, September 26, 2018 2:11 PM
> > To: Les Ginsberg (ginsberg) 
> > Cc: David Waltermire ; sec...@ietf.org;
> > lsr@ietf.org; i...@ietf.org; 
> > draft-ietf-isis-segment-routing-msd@ietf.org
> > Subject: Re: Secdir last call review of 
> > draft-ietf-isis-segment-routing-msd-16
> > 
> > On Wed, Sep 26, 2018 at 08:45:03PM +, Les Ginsberg (ginsberg) wrote:
> > > David -
> > >
> > > Thanx for the review.
> > > A new version of the draft (17) has been published to address your
> > comments - subject to my responses below.
> > 
> > Just in time for me to see the updated version for my IESG review; thanks.
> > 
> > > > -Original Message-
> > > > From: David Waltermire 
> > > > Sent: Tuesday, September 25, 2018 12:14 PM
> > > > To: sec...@ietf.org
> > > > Cc: lsr@ietf.org; i...@ietf.org; draft-ietf-isis-segment-routing-
> > > > msd@ietf.org
> > > > Subject: Secdir last call review of
> > > > draft-ietf-isis-segment-routing-msd-16
> > > >
> > > > Reviewer: David Waltermire
> > > > Review result: Has Issues
> > > >
> > > > I have reviewed this document as part of the security directorate's
> > > > ongoing effort to review all IETF documents being processed by the
> > > > IESG.  These comments were written primarily for the benefit of the
> > > > security area directors.
> > > >  Document editors and WG chairs should treat these comments just
> > > > like any other last call comments.
> > > >
> > > > The summary of the review is Ready with (minor) issues
> > > >
> > > > My apologies for the late review on this draft. Overall I found this
> > > > document to be well-written, and concise.
> > > >
> > > > General Comments:
> > > >
> > > > This document uses a mix of case around RFC2119 language (e.g., MAY
> > may).
> > > > You should use text from RFC8174 to indicate that lowercase versions
> > > > of the keywords are not normative, or adjust the case of the
> > > > lowercase words to ensure there is no confusion.
> > > >
> > > [Les:] Section 1.2 does include the standard boilerplate for RFC
> > 2119/RFC8174.
> > >
> > > I checked all the lower case uses of "may" and they are intentional.
> > > There was one instance of "should" that I changed to uppercase.
> > >
> > > > Minor nit: There is some inconsistency in the use of "MSD-Type" (the
> > > > value) and "MSD type" (the concept). Suggest cleaning this up.
> > > >
> > > [Les:] Done
> > >
> > > > Specific comments:
> > > >
> > > > Section 1:
> > > >
> > > > Para 1: s/to insure/to ensure/
> > >
> > > [Les:] Done.
> > >
> > > >
> > > > Section 4:
> > > >
> > > > The last paragraph establishes a requirement on the registration of
> > > > an MSD Type to define what the absence of a given MSD Type means.
> > > > This is an important requirement that must be addressed during
> > > > registration of new MSD Types. IMHO, this requirement should be
> > > > echoed in the registration information in section 6 to make sure it is 
> > > > not
> > overlooked.
> > > >
> > > [Les:] I disagree. Section 6 is defining exactly what should go into the 
> > > new
> > IANA registry.
> > > The definition of "absence" is something that will have to be provided in
> > the documents which define new MSD-types, but that will NOT be captured
> > in the registry so including this in Section 6 isn’t appropriate.
> > 
> > I think a good way to think about this is as giving guidance to the 
> > Experts, that
> > they should not approve registration requests that fail to provide this
> > information along with the request.  Guidance for the Experts is appropriate
> > in the IANA Considerations section.
> > (Also, my understanding is that IANA prefers to have a more explicit
> > template for new registrations to follow, though I should not try to speak 
> > for
> > them.)
> > 
> 
> [Les:] The reason we use "experts" is because we know/expect them to be 
> familiar with the documents which define the TLVs (unlike a "general IETF 
> reader" whose familiarity with the subject matter may vary).
> Repeating what is said in Section 4 in Section 6 only makes sense if you 
> think the "expert" only reads IANA sections. Such a person would not be an 
> expert IMO. :-)

I suspect that the experts would prefer to receive a high proportion of
requests that meet the criteria the experts are going to apply, rather than
constantly telling people they need to go fix the same thing and come back.
It's best practice to be clear about what is required for a successful
registration.

-Benjamin

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

Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-msd-17: (with COMMENT)

[Benjamin Kaduk]

On Wed, Sep 26, 2018 at 03:41:23PM -0700, Alvaro Retana wrote:
> On September 26, 2018 at 5:46:18 PM, Benjamin Kaduk (ka...@mit.edu) wrote:
> 
> Benjamin:
> 
> Hi!
> 
> I don’t see your updated ballot in my archive…hmmm..??
> 
> But I wanted to reply to the additional point.  You wrote:
> 
> ===
> I'm not sure I followed correctly some discussion around the rtgdir
> review, specifically the meaning of the indicated MSD value for SR-enabled
> vs. non-SR-enabled networks.  In particular, I still don't really understand
> why it's okay to use the same codepoint (value 1 as assigned here) for
> the max SID depth in SR-enabled networks and for the max label depth
> in non-SR MPLS networks.  Why couldn't they just be separate MSD Type
> codepoints?
> ===
> 
> The answer is relatively simple: SR doesn’t change the MPLS architecture,
> it just looks at the label stack in a different way by calling the labels a
> segment [rfc8402].  IOW, the SID depth is the same as the max label depth
> because a segment is the same as a label (for the purposes of forwarding
> and considering the max segment/label depth).

That helps, thanks.  I was probably getting confused with some other system
that interspersed the "new type of label" (whatever it was) and other
existing labels.  Maybe entropy labels; I think we read that recently...

I may try to suggest some new text that would help clarify this
relationship, but probably not until after the telechat, and there's no
need to wait for it, regardless.

-Benjamin

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

Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-msd-17: (with COMMENT)

[Alvaro Retana]

On September 26, 2018 at 5:46:18 PM, Benjamin Kaduk (ka...@mit.edu) wrote:

Benjamin:

Hi!

I don’t see your updated ballot in my archive…hmmm..??

But I wanted to reply to the additional point.  You wrote:

===
I'm not sure I followed correctly some discussion around the rtgdir
review, specifically the meaning of the indicated MSD value for SR-enabled
vs. non-SR-enabled networks.  In particular, I still don't really understand
why it's okay to use the same codepoint (value 1 as assigned here) for
the max SID depth in SR-enabled networks and for the max label depth
in non-SR MPLS networks.  Why couldn't they just be separate MSD Type
codepoints?
===

The answer is relatively simple: SR doesn’t change the MPLS architecture,
it just looks at the label stack in a different way by calling the labels a
segment [rfc8402].  IOW, the SID depth is the same as the max label depth
because a segment is the same as a label (for the purposes of forwarding
and considering the max segment/label depth).

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

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-segment-routing-msd-21: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Wed, Sep 26, 2018 at 10:25:54PM +, Acee Lindem (acee) wrote:
> Hi Ben, Authors,
> 
> On 9/26/18, 6:20 PM, "Benjamin Kaduk"  wrote:
> 
> Hi Acee,
> 
> On Wed, Sep 26, 2018 at 10:14:21PM +, Acee Lindem (acee) wrote:
> > Hi Ben, 
> > 
> > On 9/26/18, 6:02 PM, "Benjamin Kaduk"  wrote:
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-ospf-segment-routing-msd-21: Discuss
> > 
> > When responding, please keep the subject line intact and reply to 
> all
> > email addresses included in the To and CC lines. (Feel free to cut 
> this
> > introductory paragraph, however.)
> > 
> > 
> > Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > 
> https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/
> > 
> > 
> > 
> > 
> --
> > DISCUSS:
> > 
> --
> > 
> > This is essentially a process discuss, and hopefully easy to 
> resolve.
> > 
> > In Section 4, we say:
> > 
> >The meaning of the absence of both Node and Link MSD 
> advertisements
> >for a given MSD type is specific to the MSD type.  Generally it 
> can
> >only be inferred that the advertising node does not support
> >advertisement of that MSD type.  However, in some cases the lack 
> of
> >advertisement might imply that the functionality associated with 
> the
> >MSD type is not supported.  The correct interpretation MUST be
> >specified when an MSD type is defined.
> > 
> > I don't think we can make this sort of normative requirement on a 
> registry
> > created by a different document, at least not without updating the 
> registry
> > to also point to this document.
> > 
> > Would you be satisfied if the same text were in both the IS-IS and OSPF 
> document? We really want a copy registry for IGPs (which are really only 
> disseminating the information) to Segment Routing capable routers in the 
> routing domain. 
> 
> I think that depends on which text you're thinking about.  In particular, 
> I
> also asked for the IS-IS document to include in the IANA considerations
> some guidance to the experts that the experts need to check this
> requirement, and I'm not sure if that would result in just adding text to
> the IANA considerations or also removing text from earlier in the 
> document.
> 
> On a slightly different note, we do occasionally have things like "[this
> other document] placed some requirements on [foo].  Those requirements 
> also
> apply here, so we are copying the following paragraph from [this other
> document] below for the convenience of the reader", and I could see a
> copy+reference working here.
> 
> So, if the other document enforces the normative requirement we need, but
> we want to call attention to the requirement in this document as well,
> copying the text with a note about where it came from should suffice.
> 
> I think this is the best path since we want the documents to be independent 
> of one another even though they share the registry and semantics. If we'd 
> have merged the OSPF and IS-IS WGs earlier, we'd have had a single document 
> and have done so with the Flex Algorithm draft.  

Indeed, and sorry for having to toss a stumbling block in the works.

-Benjamin

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

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-segment-routing-msd-21: (with DISCUSS and COMMENT)

[Acee Lindem (acee)]

Hi Ben, Authors,

On 9/26/18, 6:20 PM, "Benjamin Kaduk"  wrote:

Hi Acee,

On Wed, Sep 26, 2018 at 10:14:21PM +, Acee Lindem (acee) wrote:
> Hi Ben, 
> 
> On 9/26/18, 6:02 PM, "Benjamin Kaduk"  wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-ospf-segment-routing-msd-21: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut 
this
> introductory paragraph, however.)
> 
> 
> Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This is essentially a process discuss, and hopefully easy to resolve.
> 
> In Section 4, we say:
> 
>The meaning of the absence of both Node and Link MSD advertisements
>for a given MSD type is specific to the MSD type.  Generally it can
>only be inferred that the advertising node does not support
>advertisement of that MSD type.  However, in some cases the lack of
>advertisement might imply that the functionality associated with 
the
>MSD type is not supported.  The correct interpretation MUST be
>specified when an MSD type is defined.
> 
> I don't think we can make this sort of normative requirement on a 
registry
> created by a different document, at least not without updating the 
registry
> to also point to this document.
> 
> Would you be satisfied if the same text were in both the IS-IS and OSPF 
document? We really want a copy registry for IGPs (which are really only 
disseminating the information) to Segment Routing capable routers in the 
routing domain. 

I think that depends on which text you're thinking about.  In particular, I
also asked for the IS-IS document to include in the IANA considerations
some guidance to the experts that the experts need to check this
requirement, and I'm not sure if that would result in just adding text to
the IANA considerations or also removing text from earlier in the document.

On a slightly different note, we do occasionally have things like "[this
other document] placed some requirements on [foo].  Those requirements also
apply here, so we are copying the following paragraph from [this other
document] below for the convenience of the reader", and I could see a
copy+reference working here.

So, if the other document enforces the normative requirement we need, but
we want to call attention to the requirement in this document as well,
copying the text with a note about where it came from should suffice.

I think this is the best path since we want the documents to be independent of 
one another even though they share the registry and semantics. If we'd have 
merged the OSPF and IS-IS WGs earlier, we'd have had a single document and have 
done so with the Flex Algorithm draft.  

Thanks,
Acee 


Thanks,

Benjamin


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

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-segment-routing-msd-21: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi Acee,

On Wed, Sep 26, 2018 at 10:14:21PM +, Acee Lindem (acee) wrote:
> Hi Ben, 
> 
> On 9/26/18, 6:02 PM, "Benjamin Kaduk"  wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-ospf-segment-routing-msd-21: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This is essentially a process discuss, and hopefully easy to resolve.
> 
> In Section 4, we say:
> 
>The meaning of the absence of both Node and Link MSD advertisements
>for a given MSD type is specific to the MSD type.  Generally it can
>only be inferred that the advertising node does not support
>advertisement of that MSD type.  However, in some cases the lack of
>advertisement might imply that the functionality associated with the
>MSD type is not supported.  The correct interpretation MUST be
>specified when an MSD type is defined.
> 
> I don't think we can make this sort of normative requirement on a registry
> created by a different document, at least not without updating the 
> registry
> to also point to this document.
> 
> Would you be satisfied if the same text were in both the IS-IS and OSPF 
> document? We really want a copy registry for IGPs (which are really only 
> disseminating the information) to Segment Routing capable routers in the 
> routing domain. 

I think that depends on which text you're thinking about.  In particular, I
also asked for the IS-IS document to include in the IANA considerations
some guidance to the experts that the experts need to check this
requirement, and I'm not sure if that would result in just adding text to
the IANA considerations or also removing text from earlier in the document.

On a slightly different note, we do occasionally have things like "[this
other document] placed some requirements on [foo].  Those requirements also
apply here, so we are copying the following paragraph from [this other
document] below for the convenience of the reader", and I could see a
copy+reference working here.

So, if the other document enforces the normative requirement we need, but
we want to call attention to the requirement in this document as well,
copying the text with a note about where it came from should suffice.

Thanks,

Benjamin

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

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-segment-routing-msd-21: (with DISCUSS and COMMENT)

[Acee Lindem (acee)]

Hi Ben, 

On 9/26/18, 6:02 PM, "Benjamin Kaduk"  wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ospf-segment-routing-msd-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/



--
DISCUSS:
--

This is essentially a process discuss, and hopefully easy to resolve.

In Section 4, we say:

   The meaning of the absence of both Node and Link MSD advertisements
   for a given MSD type is specific to the MSD type.  Generally it can
   only be inferred that the advertising node does not support
   advertisement of that MSD type.  However, in some cases the lack of
   advertisement might imply that the functionality associated with the
   MSD type is not supported.  The correct interpretation MUST be
   specified when an MSD type is defined.

I don't think we can make this sort of normative requirement on a registry
created by a different document, at least not without updating the registry
to also point to this document.

Would you be satisfied if the same text were in both the IS-IS and OSPF 
document? We really want a copy registry for IGPs (which are really only 
disseminating the information) to Segment Routing capable routers in the 
routing domain. 

Thanks,
Acee


--
COMMENT:
--

Can SID be expanded on first usage --
https://www.rfc-editor.org/materials/abbrev.expansion.txt does not list it
as "well known".  (It also doesn't appear to list "Segment Identifier" as
one of the expansions.)

This is basically the same thing I said for the IS-IS document that creates
the MSD types registry, but I'm not sure I followed correctly the meaning
of MSD type 1 for SR-enabled vs.  non-SR-enabled networks.  In particular,
I still don't really understand why it's okay to use the same codepoint for
the max SID depth in SR-enabled networks and for the max label depth in
non-SR MPLS networks.  Why couldn't they just be separate MSD Type
codepoints?

Section-by-section comments follow.

Section 2

  If the Node MSD TLV appears in multiple Router
   Information LSAs that have the same flooding scope, the Node MSD TLV
   in the Router Information (RI) LSA with the numerically smallest
   Instance ID MUST be used and subsequent instances of the Node MSD TLV
   MUST be ignored. [...]

Unless there is a sorting requirement I've forgotten about, shouldn't this
be "other" rather than "subsequent"?

Section 6

Thanks for the updates in response to the secdir review; they help a lot.

   If the value is larger than supported - instantiation of a path that
   can't be supported by the head-end (the node performing the SID
   imposition).

This is supposed to mean "(instantiation by the head-end) of a (path that
can't be supported)", not "instantiation of a path (that can't be supported
by the head-end)", right?




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

[Lsr] Last Call: (OSPF LLS Extensions for Local Interface ID Advertisement) to Proposed Standard

[The IESG]

The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'OSPF LLS Extensions for Local Interface
ID Advertisement'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2018-10-10. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   Every OSPF interface is assigned an identifier, Interface ID, which
   uniquely identifies the interface on the router.  In some cases it is
   useful to know the assigned Interface ID on the remote side of the
   adjacency (Remote Interface ID).

   This draft describes the extensions to OSPF link-local signalling to
   advertise the Local Interface Identifier.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ospf-lls-interface-id/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ospf-lls-interface-id/ballot/


No IPR declarations have been submitted directly on this I-D.




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

[Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-segment-routing-msd-21: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ospf-segment-routing-msd-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/



--
DISCUSS:
--

This is essentially a process discuss, and hopefully easy to resolve.

In Section 4, we say:

   The meaning of the absence of both Node and Link MSD advertisements
   for a given MSD type is specific to the MSD type.  Generally it can
   only be inferred that the advertising node does not support
   advertisement of that MSD type.  However, in some cases the lack of
   advertisement might imply that the functionality associated with the
   MSD type is not supported.  The correct interpretation MUST be
   specified when an MSD type is defined.

I don't think we can make this sort of normative requirement on a registry
created by a different document, at least not without updating the registry
to also point to this document.


--
COMMENT:
--

Can SID be expanded on first usage --
https://www.rfc-editor.org/materials/abbrev.expansion.txt does not list it
as "well known".  (It also doesn't appear to list "Segment Identifier" as
one of the expansions.)

This is basically the same thing I said for the IS-IS document that creates
the MSD types registry, but I'm not sure I followed correctly the meaning
of MSD type 1 for SR-enabled vs.  non-SR-enabled networks.  In particular,
I still don't really understand why it's okay to use the same codepoint for
the max SID depth in SR-enabled networks and for the max label depth in
non-SR MPLS networks.  Why couldn't they just be separate MSD Type
codepoints?

Section-by-section comments follow.

Section 2

  If the Node MSD TLV appears in multiple Router
   Information LSAs that have the same flooding scope, the Node MSD TLV
   in the Router Information (RI) LSA with the numerically smallest
   Instance ID MUST be used and subsequent instances of the Node MSD TLV
   MUST be ignored. [...]

Unless there is a sorting requirement I've forgotten about, shouldn't this
be "other" rather than "subsequent"?

Section 6

Thanks for the updates in response to the secdir review; they help a lot.

   If the value is larger than supported - instantiation of a path that
   can't be supported by the head-end (the node performing the SID
   imposition).

This is supposed to mean "(instantiation by the head-end) of a (path that
can't be supported)", not "instantiation of a path (that can't be supported
by the head-end)", right?


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

[Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-msd-17: (with COMMENT)

[Benjamin Kaduk]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-isis-segment-routing-msd-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/



--
COMMENT:
--

The shepherd writeup is silent about the WG's discussion of the IPR
disclosure (but the corresponding ospf draft says this sort of thing is
typical for LSR drafts).

Section 3

   The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and
   223 to carry the MSD of the interface associated with the link.  MSD

Please add the appropriate qualifier (IS-IS?) before the list of TLV
numbers.

   MSD-Value is a number in the range of 0-255.  For all MSD-Types, 0
   represents lack of the ability to support SID stack of any depth; any
   other value represents that of the link.

It's unclear that there's a referent for "that of the link" to attach to.
That is, is it better to say "represents the maximum SID depth supported by
the link" (or similar)?

Section 6

As discussed in the secdir review, this section needs to include guidance
to the Experts to check that the meaning of the absence of an MSD type is
specified.  Given the text in draft-ietf-ospf-segment-routing-msd that
attempts to place a similar requirement on future MSD types (but for OSPF
vs. IS-IS usage thereof), hopefully this guidance can be phrased in an
appropriately general fashion so as to apply to all places where the
registered MSD value would be used.

Section 7

   Advertisement of the additional information defined in this document
   that is false, e.g., an MSD that is incorrect, may result in a path
   computation failing, having a service unavailable, or calculation of
   a path that cannot be supported by the head-end (the node performing
   the imposition).

In the analogous OSPF document we split out the case of a value that is too
small and a value that is too large, to describe the different
consequences.

I would also suggest rewording to something like "calculation by the
head-end of a path that cannot be supported" to avoid the mis-parsing
"(calculation of a path) (that cannot be supported by the head-end)".


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

Re: [Lsr] Secdir last call review of draft-ietf-isis-segment-routing-msd-16

[Benjamin Kaduk]

On Wed, Sep 26, 2018 at 08:45:03PM +, Les Ginsberg (ginsberg) wrote:
> David -
> 
> Thanx for the review.
> A new version of the draft (17) has been published to address your comments - 
> subject to my responses below.

Just in time for me to see the updated version for my IESG review; thanks.

> > -Original Message-
> > From: David Waltermire 
> > Sent: Tuesday, September 25, 2018 12:14 PM
> > To: sec...@ietf.org
> > Cc: lsr@ietf.org; i...@ietf.org; draft-ietf-isis-segment-routing-
> > msd@ietf.org
> > Subject: Secdir last call review of draft-ietf-isis-segment-routing-msd-16
> > 
> > Reviewer: David Waltermire
> > Review result: Has Issues
> > 
> > I have reviewed this document as part of the security directorate's ongoing
> > effort to review all IETF documents being processed by the IESG.  These
> > comments were written primarily for the benefit of the security area
> > directors.
> >  Document editors and WG chairs should treat these comments just like any
> > other last call comments.
> > 
> > The summary of the review is Ready with (minor) issues
> > 
> > My apologies for the late review on this draft. Overall I found this 
> > document
> > to be well-written, and concise.
> > 
> > General Comments:
> > 
> > This document uses a mix of case around RFC2119 language (e.g., MAY may).
> > You should use text from RFC8174 to indicate that lowercase versions of the
> > keywords are not normative, or adjust the case of the lowercase words to
> > ensure there is no confusion.
> > 
> [Les:] Section 1.2 does include the standard boilerplate for RFC 2119/RFC8174.
> 
> I checked all the lower case uses of "may" and they are intentional.
> There was one instance of "should" that I changed to uppercase.
> 
> > Minor nit: There is some inconsistency in the use of "MSD-Type" (the value)
> > and "MSD type" (the concept). Suggest cleaning this up.
> > 
> [Les:] Done
> 
> > Specific comments:
> > 
> > Section 1:
> > 
> > Para 1: s/to insure/to ensure/
> 
> [Les:] Done.
> 
> > 
> > Section 4:
> > 
> > The last paragraph establishes a requirement on the registration of an MSD
> > Type to define what the absence of a given MSD Type means. This is an
> > important requirement that must be addressed during registration of new
> > MSD Types. IMHO, this requirement should be echoed in the registration
> > information in section 6 to make sure it is not overlooked.
> >
> [Les:] I disagree. Section 6 is defining exactly what should go into the new 
> IANA registry.
> The definition of "absence" is something that will have to be provided in the 
> documents which define new MSD-types, but that will NOT be captured in the 
> registry so including this in Section 6 isn’t appropriate.

I think a good way to think about this is as giving guidance to the
Experts, that they should not approve registration requests that fail to
provide this information along with the request.  Guidance for the Experts
is appropriate in the IANA Considerations section.
(Also, my understanding is that IANA prefers to have a more explicit
template for new registrations to follow, though I should not try to speak
for them.)

>  
> > Section 6:
> > 
> > The "Base MPLS Imposition MSD" should reference section 5 of this
> > document.
> 
> [Les:] Again - Section 6 is defining what will go into the registry. The 
> registry will reference the document - not a specific section of the document.

The contents of the "Reference" column for Value 1 can refer to a specific
section of a document, surely?

> > 
> > The registration for "Experimental" should be marked as "Reserved for
> > Experimental Use" or just "Experimental Use" to align with RFC8126. RFC8126
> > states that "it is not appropriate for documents to select explicit values 
> > from
> > registries or ranges with this policy". It might be good to add a note 
> > alongside
> > the one on "Designated Experts" indicating that values from this range are
> > not assignable.
> > 
> [Les:] I have changed the text to "Experimental Use".
> I think the rest of your comment is addressed by RFC 8126 - which is 
> referenced.
> 
> > The "Interior Gateway Protocol (IGP) Parameters" registry has the
> > "Standards Action" policy assigned. The new "IGP MSD Types" sub-registry
> > does not have the "Standards Action" policy. Was this intentional? If so, 
> > this
> > should be explained. This is also confusing since the guidance for expert
> > reviewers in
> > RFC7370 implies that registrations are based on the "RFC Required" or
> > "Standards Action" policies.
> >
> [Les:] IS-IS registries are typically Expert Review. This derives from 
> considerations related to the liason with ISO JTC 1/SC6 (RFC 3563).
> OSPF registries are typically Standards Action.
> 
> As IGP Parameters was defined by draft-ietf-ospf-segment-routing-extensions, 
> it is Standards Action.
> But as MSD-Types is being defined in an IS-IS draft...
> 
> Please learn to live with this.
> It isn’t a significant issue in my view.
> 
>

Re: [Lsr] Secdir last call review of draft-ietf-isis-segment-routing-msd-16

[Les Ginsberg (ginsberg)]

David -

Thanx for the review.
A new version of the draft (17) has been published to address your comments - 
subject to my responses below.

> -Original Message-
> From: David Waltermire 
> Sent: Tuesday, September 25, 2018 12:14 PM
> To: sec...@ietf.org
> Cc: lsr@ietf.org; i...@ietf.org; draft-ietf-isis-segment-routing-
> msd@ietf.org
> Subject: Secdir last call review of draft-ietf-isis-segment-routing-msd-16
> 
> Reviewer: David Waltermire
> Review result: Has Issues
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area
> directors.
>  Document editors and WG chairs should treat these comments just like any
> other last call comments.
> 
> The summary of the review is Ready with (minor) issues
> 
> My apologies for the late review on this draft. Overall I found this document
> to be well-written, and concise.
> 
> General Comments:
> 
> This document uses a mix of case around RFC2119 language (e.g., MAY may).
> You should use text from RFC8174 to indicate that lowercase versions of the
> keywords are not normative, or adjust the case of the lowercase words to
> ensure there is no confusion.
> 
[Les:] Section 1.2 does include the standard boilerplate for RFC 2119/RFC8174.

I checked all the lower case uses of "may" and they are intentional.
There was one instance of "should" that I changed to uppercase.

> Minor nit: There is some inconsistency in the use of "MSD-Type" (the value)
> and "MSD type" (the concept). Suggest cleaning this up.
> 
[Les:] Done

> Specific comments:
> 
> Section 1:
> 
> Para 1: s/to insure/to ensure/

[Les:] Done.

> 
> Section 4:
> 
> The last paragraph establishes a requirement on the registration of an MSD
> Type to define what the absence of a given MSD Type means. This is an
> important requirement that must be addressed during registration of new
> MSD Types. IMHO, this requirement should be echoed in the registration
> information in section 6 to make sure it is not overlooked.
>
[Les:] I disagree. Section 6 is defining exactly what should go into the new 
IANA registry.
The definition of "absence" is something that will have to be provided in the 
documents which define new MSD-types, but that will NOT be captured in the 
registry so including this in Section 6 isn’t appropriate.

 
> Section 6:
> 
> The "Base MPLS Imposition MSD" should reference section 5 of this
> document.

[Les:] Again - Section 6 is defining what will go into the registry. The 
registry will reference the document - not a specific section of the document.

> 
> The registration for "Experimental" should be marked as "Reserved for
> Experimental Use" or just "Experimental Use" to align with RFC8126. RFC8126
> states that "it is not appropriate for documents to select explicit values 
> from
> registries or ranges with this policy". It might be good to add a note 
> alongside
> the one on "Designated Experts" indicating that values from this range are
> not assignable.
> 
[Les:] I have changed the text to "Experimental Use".
I think the rest of your comment is addressed by RFC 8126 - which is referenced.

> The "Interior Gateway Protocol (IGP) Parameters" registry has the
> "Standards Action" policy assigned. The new "IGP MSD Types" sub-registry
> does not have the "Standards Action" policy. Was this intentional? If so, this
> should be explained. This is also confusing since the guidance for expert
> reviewers in
> RFC7370 implies that registrations are based on the "RFC Required" or
> "Standards Action" policies.
>
[Les:] IS-IS registries are typically Expert Review. This derives from 
considerations related to the liason with ISO JTC 1/SC6 (RFC 3563).
OSPF registries are typically Standards Action.

As IGP Parameters was defined by draft-ietf-ospf-segment-routing-extensions, it 
is Standards Action.
But as MSD-Types is being defined in an IS-IS draft...

Please learn to live with this.
It isn’t a significant issue in my view.


 
> Section 7:
> 
> The security considerations in RFC7981 ask that security considerations
> around the disclosure and modification of this type of information is
> described in extensions. This has been done, but RFC7981 also asks that an
> integrity mechanism be provided if there is a high risk resulting from
> modification of capability information. There is no discussion in the
> document's security consideration about the nature of risk in this case and
> why an integrity mechanism is not needed. It seems like false information
> can be used to cause a denial of service regarding computed paths. This
> sounds like having this happen could be bad. I am not an expert on routing
> protocols, so I am not sure if this is an issue. How bad and likely is such a 
> risk?
> 

[Les:] The integrity mechanism is (as you point out) discussed in the Security 
section of RFC 7981 - which is referenced 

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

[Jeff Tantsura]

Gents,

Thanks for the great review!

Both drafts are on the Telechat tomorrow, would be great to come to the 
agreement, so ospf draft could be updated before tomorrow’s call.

Regards,
Jeff

> On Sep 26, 2018, at 13:21, Les Ginsberg (ginsberg)  wrote:
> 
> Julien -
> 
> Thanx for the additional comments.
> V17 has been published to address these - subject to my responses below.
> See Les2
> 
>> -Original Message-
>> From: rtg-dir  On Behalf Of Julien Meuric
>> Sent: Monday, September 24, 2018 8:12 AM
>> To: Les Ginsberg (ginsberg) ; rtg-...@ietf.org
>> Cc: lsr@ietf.org; rtg-...@ietf.org; draft-ietf-isis-segment-routing- 
>> m...@ietf.org
>> Subject: Re: [RTG-DIR] RtgDir Review: 
>> draft-ietf-isis-segment-routing-msd-15
>> 
>> Hi Les,
>> 
>> Thanks for you feedback. Please find some responses, marked [JM] below.
>> You may consider the trimmed ones as resolved. For others, please keep 
>> in mind that the directorate's purpose is to improve documents'
>> readability before publication, as opposed to store clarification in 
>> mailing list archives.
>> 
> [Les2:]  I fully appreciate both the purpose of the review and the effort you 
> have put in. Yours is one of the better reviews I have seen in my years...
> If I push back it is not because I do not value your input - but simply 
> because I disagree. :-)
> 
>> Julien
>> 
>> 
>> Sep. 24, 2018 - ginsb...@cisco.com:
>>> Julien -
>>> 
>>> Thanx for your detailed review - and your patience in waiting for a
>> response (I returned from vacation only a few days ago).
>>> 
>>> I have published V16 of the draft which addresses your comments 
>>> except
>> as noted inline below.
>>> 
>>> 
 -Original Message-
 From: Julien Meuric 
 Sent: Monday, September 10, 2018 8:28 AM
 
>> 
 
 - The abstract uses the acronym "SID", however:
* It should be expanded at first use,
* It should be defined, e.g. by adding a (normative) reference 
 to RFC 8402 (at least in the introduction),
* The SR context is missing and should be explicitly mentioned 
 (adding a phrase such as "in a Segment Routing-enabled network" 
 would
>> be enough).
>>> 
>>> [Les:] SID has been added to the terminology section and a reference 
>>> to
>> RFC 8402 added.
>>> However, I don’t think "SR context" is missing. The first sentence 
>>> of the Introduction starts with
>>> 
>>> " When Segment Routing (SR) paths are computed..."
>>> 
>> [JM] I fully agree about the introduction, but my comment was about 
>> the abstract where the SR context needs to be guessed from the use of 
>> the "SID" terminology: an explicit phrase would be welcome to a rookie 
>> reading the abstract.
>> 
> [Les2:] I have modified the abstract.
> 
 
 - OLD
   Path Computation Element Protocol (PCEP) SR extensions draft
   [I-D.ietf-pce-segment-routing] signals MSD in SR Path 
 Computation
   Element (PCE) Capability TLV and METRIC Object.
  NEW
   The Path Computation Element communication Protocol (PCEP) SR
   extension document [I-D.ietf-pce-segment-routing] defines how to
   signal MSD using the SR-PCE-CAPABILITY sub-TLV (per node) and
   the METRIC object (per request).
 
>>> [Les:] I have updated this and included a reference to RFC 5440 
>>> where
>> METRIC object was first defined.
>>> 
>> [JM] Even better about METRIC. Consistently, "SR Path Computation 
>> Element
>> (PCE) Capability TLV" still remains a loose phrase, the technical name 
>> from [I- D.ietf-pce-segment-routing] is "SR-PCE-CAPABILITY", which 
>> avoids ambiguity.
>> 
> 
> [Les2:] I removed naming the specific TLVs and replaced it with " Path  
> Computation Element Protocol (PCEP)".
> I think this is better than mentioning specific TLV names - particularly 
> since one of them is part of a draft and the TLV name might change before the 
> document becomes an RFC. So any possible naming inconsistency is now 
> eliminated.
> 
>>> 
 - The introduction says that the solution to complement BGP-LS lies 
 in IS-IS (the OSPF draft claiming the counterpart on its side). 
 This is a bit rough, the sentence 2 paragraph below already does 
 the necessary scoping job: "This document defines an extension to 
 >>> here>". I suggest to temper the early sentence by rephrasing the
 beginning of page 3 into: "MSD capabilities should be advertised by 
 every router in the network involved in the IGP."
 
>>> [Les:] The draft says
>>> 
>>> " MSD capabilities should be
>>>   advertised by every Intermediate System to Intermediate System(IS-IS)
>>>   router in the network."
>>> 
>>> which I believe meets your suggestion.
>>> 
>> [JM] My comment was exactly starting from there. Let me rephrase:
>> - This I-D says "should be advertised by every IS-IS router";
>> - draft-ietf-ospf-segment-routing-msd says "should be advertised by 
>> every OSPF router".
>> Now that we have a single LSR WG, I suggest to drop these competing 
>> wo

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

[Les Ginsberg (ginsberg)]

Julien -

Thanx for the additional comments.
V17 has been published to address these - subject to my responses below.
See Les2

> -Original Message-
> From: rtg-dir  On Behalf Of Julien Meuric
> Sent: Monday, September 24, 2018 8:12 AM
> To: Les Ginsberg (ginsberg) ; rtg-...@ietf.org
> Cc: lsr@ietf.org; rtg-...@ietf.org; draft-ietf-isis-segment-routing- 
> m...@ietf.org
> Subject: Re: [RTG-DIR] RtgDir Review: 
> draft-ietf-isis-segment-routing-msd-15
> 
> Hi Les,
> 
> Thanks for you feedback. Please find some responses, marked [JM] below.
> You may consider the trimmed ones as resolved. For others, please keep 
> in mind that the directorate's purpose is to improve documents'
> readability before publication, as opposed to store clarification in 
> mailing list archives.
> 
[Les2:]  I fully appreciate both the purpose of the review and the effort you 
have put in. Yours is one of the better reviews I have seen in my years...
If I push back it is not because I do not value your input - but simply because 
I disagree. :-)

> Julien
> 
> 
> Sep. 24, 2018 - ginsb...@cisco.com:
> > Julien -
> >
> > Thanx for your detailed review - and your patience in waiting for a
> response (I returned from vacation only a few days ago).
> >
> > I have published V16 of the draft which addresses your comments 
> > except
> as noted inline below.
> >
> >
> >> -Original Message-
> >> From: Julien Meuric 
> >> Sent: Monday, September 10, 2018 8:28 AM
> >>
> 
> >>
> >> - The abstract uses the acronym "SID", however:
> >> * It should be expanded at first use,
> >> * It should be defined, e.g. by adding a (normative) reference 
> >> to RFC 8402 (at least in the introduction),
> >> * The SR context is missing and should be explicitly mentioned 
> >> (adding a phrase such as "in a Segment Routing-enabled network" 
> >> would
> be enough).
> >
> > [Les:] SID has been added to the terminology section and a reference 
> > to
> RFC 8402 added.
> > However, I don’t think "SR context" is missing. The first sentence 
> > of the Introduction starts with
> >
> > " When Segment Routing (SR) paths are computed..."
> >
> [JM] I fully agree about the introduction, but my comment was about 
> the abstract where the SR context needs to be guessed from the use of 
> the "SID" terminology: an explicit phrase would be welcome to a rookie 
> reading the abstract.
> 
[Les2:] I have modified the abstract.

> >>
> >> - OLD
> >>Path Computation Element Protocol (PCEP) SR extensions draft
> >>[I-D.ietf-pce-segment-routing] signals MSD in SR Path 
> >> Computation
> >>Element (PCE) Capability TLV and METRIC Object.
> >>   NEW
> >>The Path Computation Element communication Protocol (PCEP) SR
> >>extension document [I-D.ietf-pce-segment-routing] defines how to
> >>signal MSD using the SR-PCE-CAPABILITY sub-TLV (per node) and
> >>the METRIC object (per request).
> >>
> > [Les:] I have updated this and included a reference to RFC 5440 
> > where
> METRIC object was first defined.
> >
> [JM] Even better about METRIC. Consistently, "SR Path Computation 
> Element
> (PCE) Capability TLV" still remains a loose phrase, the technical name 
> from [I- D.ietf-pce-segment-routing] is "SR-PCE-CAPABILITY", which 
> avoids ambiguity.
> 

[Les2:] I removed naming the specific TLVs and replaced it with " Path  
Computation Element Protocol (PCEP)".
I think this is better than mentioning specific TLV names - particularly since 
one of them is part of a draft and the TLV name might change before the 
document becomes an RFC. So any possible naming inconsistency is now eliminated.

> >
> >> - The introduction says that the solution to complement BGP-LS lies 
> >> in IS-IS (the OSPF draft claiming the counterpart on its side). 
> >> This is a bit rough, the sentence 2 paragraph below already does 
> >> the necessary scoping job: "This document defines an extension to 
> >>  >> here>". I suggest to temper the early sentence by rephrasing the
> >> beginning of page 3 into: "MSD capabilities should be advertised by 
> >> every router in the network involved in the IGP."
> >>
> > [Les:] The draft says
> >
> > " MSD capabilities should be
> >advertised by every Intermediate System to Intermediate System(IS-IS)
> >router in the network."
> >
> > which I believe meets your suggestion.
> >
> [JM] My comment was exactly starting from there. Let me rephrase:
> - This I-D says "should be advertised by every IS-IS router";
> - draft-ietf-ospf-segment-routing-msd says "should be advertised by 
> every OSPF router".
> Now that we have a single LSR WG, I suggest to drop these competing 
> wordings and consider a more consensual "should be advertised in the IGP".
> Both documents already include a sentence "This document defines an 
> extension to IS-IS/OSPF" at the end of their introduction, which is 
> enough to define the scope.
> 
[Les2:] Sorry - here I will pushback. 
If the initial version of the MSD drafts had been written aft

[Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-17.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Signaling MSD (Maximum SID Depth) using IS-IS
Authors : Jeff Tantsura
  Uma Chunduri
  Sam Aldrin
  Les Ginsberg
Filename: draft-ietf-isis-segment-routing-msd-17.txt
Pages   : 10
Date: 2018-09-26

Abstract:
   This document defines a way for an Intermediate System to
   Intermediate System (IS-IS) router to advertise multiple types of
   supported Maximum SID Depths (MSDs) at node and/or link granularity.
   Such advertisements allow entities (e.g., centralized controllers) to
   determine whether a particular SID stack can be supported in a given
   network.  This document only defines one type of MSD (Base MPLS
   Imposition), but defines an encoding that can support other MSD
   types.  This document focuses on MSD use in a Segment Routing enabled
   network, but MSD may also be useful when Segment Routing is not
   enabled.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-msd-17
https://datatracker.ietf.org/doc/html/draft-ietf-isis-segment-routing-msd-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-segment-routing-msd-17


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [Lsr] AD Review of draft-ietf-isis-reverse-metric-11

[Alvaro Retana]

On September 24, 2018 at 9:35:06 PM, Naiming Shen (naiming) (
naim...@cisco.com) wrote:

Naiming:

Hi!

Thank you for your detailed review on this draft, I’ll try to reply to the
comments
inline below, and the proposed document diff is attached at the end. Let me
know
if you would like to have other formats.

In general, the diffs look good to me.  But I do have some more comments
below.

Once we iron those out and you post an update I will start the IETF Last
Call.

Thanks!

Alvaro.




Note that I read -11, but -12 was published in the interim -- so I'm
putting this comment up here.  The only change in -12 is the addition (in
the IANA Considerations section) of "a new registry for sub-TLVs of the
Reverse Metric TLV".  Why do we need this new registry?  The description
(in §2) of the use of this sub-TLV already references rfc5305 (where a TE
Default Metric sub-TLV is already defined), so it seemed somewhat natural
to me to simply reuse that sub-TLV here.  From the discussion on the list,
I understand the intent to "future proof", even if no other applications
come to mind.  If that is the path we want to go, then we'll need a
complete description of the new sub-TLV as well. [Some of my comments
bellow assume the existing sub-TLV from rfc5305.]


 With the email exchange from you and Les, I assume I keep the same
as in the version 12 on this sub-TLV registry.

Yes.

However, I need you to add a description of the sub-TLV in this document.
Right now there is a reference to rfc5305, but as Les explained, even
though these sub-TLVs look the same, they are really different.  When doing
so, the references to rfc5305 (for the sub-TLV) would not be needed.





172   octet field containing an IS-IS Metric Value, and a 1 octet Traffic
173   Engineering (TE) sub-TLV length field representing the length of a

[minor] Even though it is the only one used, the sub-TLV length field is
not the "Traffic Engineering (TE) sub-TLV length field”.


 Ok, remove the TE sub-TLV wording.

The new text still has the same wording: s/1 octet Traffic Engineering (TE)
sub-TLV length field/1 octet sub-TLV length field


174   variable number of Extended Intermediate System (IS) Reachability
175   sub-TLVs.  If the "sub-TLV len" is non-zero, then the Value field
176   MUST also contain one or more Extended IS Reachability sub-TLVs.

[minor] I'm guessing that by "Extended IS Reachability sub-TLVs" you really
mean the sub-TLVs for the Extended IS Reachability TLV, right?  Please at
least put in a reference to rfc5305.


 Will reference to the rfc5305.

Going back to Les’ explanation of the need for a new registry.  This
document only defined type 18, so in reality the other sub-TLVs from
rfc5305 shouldn’t be used.

Suggestion:

OLD> If the "sub-TLV len” is non-zero, then the Value field MUST also
contain one or more Extended IS Reachability sub-TLVs [RFC5305].

NEW> If the "sub-TLV len” is non-zero, then the Value field MUST also
contain one or more sub-TLVs.


178   The Reverse Metric TLV is optional.  The Reverse Metric TLV may be
179   present in any IS-IS Hello PDU.  A sender MUST only transmit a single
180   Reverse Metric TLV in a IS-IS Hello PDU.  If a received IS-IS Hello
181   PDU contains more than one Reverse Metric TLV, an implementation
182   SHOULD ignore all the Reverse Metric TLVs and treat it as an error
183   condition.

[nit] The first two sentences sound redundant to me.


 OK.


[major] The text above is not specific about which PDUs can include the
Reverse Metric TLV.  The text does say that it is optional and that it may
be in an IIH once...but it doesn't say anything about other PDUs.  The IANA
Considerations section contains the attributes to be included in the
registry, but those are not Normative.


 Added other PDU MUST ignore it.

I saw the new text.  Thanks for being explicit about the TLV being used in
an IIH.

Les also pointed to the following in ISO 10589: “TLVs received in a
non-permitted PDU MUST be ignored.”  That means that the last sentence in
the new text ("If an IS-IS node received of IS-IS Reverse Metric TLV  in
the PDU other than the IS-IS Hello PDU, this TLV MUST be ignored.”) is
redundant.




406   When the link TE metric is raised to (2^24 - 1) [RFC5817], either
due
407   to the reverse-metric mechanism or by explicit user configuration,
408   this SHOULD immediately trigger the CSPF re-calculation to move
the
409   TE traffic away from that link.  It is RECOMMENDED also that the
CSPF
410   does the immediate CSPF re-calculation when the TE metric is
raised
411   to (2^24 - 2) to be the last resort link.

[major] These Normative statements are ok, but just for the case where the
metric is raised because of the reverse metric, and not for the explicit
configuration case.  This document is specifying the behavior of the
reverse metric, not the general configuration response.  IOW, if someone
doesn't read this document, then there's no way for the general case