from:"Les Ginsberg \(ginsberg\)"

Re: [Gen-art] Genart last call review of draft-ietf-lsr-rfc8919bis-01

2023-05-09 Thread Les Ginsberg (ginsberg)

Robert/John -

I have posted a new version which addresses this issue.
I hope this clears the discussion.

I also (as promised) made the same change to 
https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8920bis/ and posted a new 
version of that document.

   Les


> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Wednesday, May 3, 2023 1:00 PM
> To: Robert Sparks ; John Scudder
> 
> Cc: gen-art@ietf.org; draft-ietf-lsr-rfc8919bis@ietf.org; 
> last-c...@ietf.org;
> l...@ietf.org
> Subject: RE: Genart last call review of draft-ietf-lsr-rfc8919bis-01
> 
> John -
> 
> The solution you propose is fine with me.
> I will update it in the next version.
> As we are still waiting for a few reviews I will wait a bit in case other 
> changes
> are needed.
> 
> I will do the same to https://datatracker.ietf.org/doc/draft-ietf-lsr-
> rfc8920bis/ as well.
> 
>Les
> 
> > -Original Message-
> > From: Robert Sparks 
> > Sent: Wednesday, May 3, 2023 11:18 AM
> > To: John Scudder ; Les Ginsberg (ginsberg)
> > 
> > Cc: gen-art@ietf.org; draft-ietf-lsr-rfc8919bis@ietf.org; last-
> c...@ietf.org;
> > l...@ietf.org
> > Subject: Re: Genart last call review of draft-ietf-lsr-rfc8919bis-01
> >
> >
> > On 5/3/23 1:12 PM, John Scudder wrote:
> > >> On May 3, 2023, at 11:04 AM, Les Ginsberg (ginsberg)
> >  wrote:
> > >>
> > >>> 2) Please reconsider the link to the mailarchive in the RFC. Put it in 
> > >>> the
> > >>> shepherd writeup or in the history in the datatracker as a comment
> > (chairs
> > >>> can
> > >>> do this). Otherwise it adds to the list of URLs that we have to keep
> alive
> > >>> forever.
> > >> [LES:] I am open to whatever the chairs/AD think is appropriate. But
> very
> > few people actually look at the shepherd writeup or Datatracker history.
> > Having it in the document provides context for those readers who are
> > curious as to why the bis changes were made. I don’t think it would be as
> > effective if it were removed from the document.
> > >> I take your point that the URL may someday become stale - but if it did
> > that would apply to the other locations as well.
> > >> The section in which it appears is informational only - it is not a
> normative
> > part of the document - so I am inclined to leave it as is.
> > >> But again, happy to follow consensus on this.
> > > Yeah, I don’t see how adding another layer of indirection makes the
> > problem go away. Perhaps it would be reasonable, though, to change the
> > reference from a bare URL, presented inline, to an Informative reference,
> to
> > the effect of
> > >
> > >   [LSR-MAIL] IETF LSR Mailing List Archive, Tue, 15 June 2021 15:25 UTC,
> > "[Lsr] Proposed Errata for RFCs 8919/8920”, and follow-up messages.
> > >
> > > I don’t know if there is a standard style for this kind of reference, but 
> > > it
> > seems like it might be a cleaner solution. It doesn’t provide one-click 
> > access
> > to the mailing list thread, but neither do some other references, and it
> > should be easy enough for anyone familiar with our mailing list archives or
> > frankly, even anyone who knows how to use a search engine. Also,
> ironically
> > the bare URL doesn’t provide one-click access either, because of how it’s
> > line-broken in the txt rendering.
> > >
> > > Robert, Les, would that approach work for both of you?
> > Yes.
> > >
> > > —John
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-lsr-rfc8919bis-01

2023-05-03 Thread Les Ginsberg (ginsberg)

John -

The solution you propose is fine with me.
I will update it in the next version.
As we are still waiting for a few reviews I will wait a bit in case other 
changes are needed.

I will do the same to 
https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8920bis/ as well.

   Les

> -Original Message-
> From: Robert Sparks 
> Sent: Wednesday, May 3, 2023 11:18 AM
> To: John Scudder ; Les Ginsberg (ginsberg)
> 
> Cc: gen-art@ietf.org; draft-ietf-lsr-rfc8919bis@ietf.org; 
> last-c...@ietf.org;
> l...@ietf.org
> Subject: Re: Genart last call review of draft-ietf-lsr-rfc8919bis-01
> 
> 
> On 5/3/23 1:12 PM, John Scudder wrote:
> >> On May 3, 2023, at 11:04 AM, Les Ginsberg (ginsberg)
>  wrote:
> >>
> >>> 2) Please reconsider the link to the mailarchive in the RFC. Put it in the
> >>> shepherd writeup or in the history in the datatracker as a comment
> (chairs
> >>> can
> >>> do this). Otherwise it adds to the list of URLs that we have to keep alive
> >>> forever.
> >> [LES:] I am open to whatever the chairs/AD think is appropriate. But very
> few people actually look at the shepherd writeup or Datatracker history.
> Having it in the document provides context for those readers who are
> curious as to why the bis changes were made. I don’t think it would be as
> effective if it were removed from the document.
> >> I take your point that the URL may someday become stale - but if it did
> that would apply to the other locations as well.
> >> The section in which it appears is informational only - it is not a 
> >> normative
> part of the document - so I am inclined to leave it as is.
> >> But again, happy to follow consensus on this.
> > Yeah, I don’t see how adding another layer of indirection makes the
> problem go away. Perhaps it would be reasonable, though, to change the
> reference from a bare URL, presented inline, to an Informative reference, to
> the effect of
> >
> > [LSR-MAIL] IETF LSR Mailing List Archive, Tue, 15 June 2021 15:25 UTC,
> "[Lsr] Proposed Errata for RFCs 8919/8920”, and follow-up messages.
> >
> > I don’t know if there is a standard style for this kind of reference, but it
> seems like it might be a cleaner solution. It doesn’t provide one-click access
> to the mailing list thread, but neither do some other references, and it
> should be easy enough for anyone familiar with our mailing list archives or
> frankly, even anyone who knows how to use a search engine. Also, ironically
> the bare URL doesn’t provide one-click access either, because of how it’s
> line-broken in the txt rendering.
> >
> > Robert, Les, would that approach work for both of you?
> Yes.
> >
> > —John
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-lsr-rfc8919bis-01

2023-05-03 Thread Les Ginsberg (ginsberg)

Robert -

Thanx for your review - apologies for the delay in responding.
Please see inline.

> -Original Message-
> From: Robert Sparks via Datatracker 
> Sent: Thursday, April 27, 2023 1:09 PM
> To: gen-art@ietf.org
> Cc: draft-ietf-lsr-rfc8919bis@ietf.org; last-c...@ietf.org; l...@ietf.org
> Subject: Genart last call review of draft-ietf-lsr-rfc8919bis-01
> 
> Reviewer: Robert Sparks
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-lsr-rfc8919bis-01
> Reviewer: Robert Sparks
> Review Date: 2023-04-27
> IETF LC End Date: 2023-05-03
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> Ready for publication as a proposed standard rfc but with nits to consider
> before publication.
> 
> Nits:
> 1) It would be nice to explain when/how the registries got renamed?

[LES:] I do not see that as within scope for this document.
Registry renaming was done across the full set of registries under 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
about a year and a half ago to make them easier to maintain and to provide 
greater consistency in the naming.
It was not done specifically to the registry referenced by this document.

> 
> 2) Please reconsider the link to the mailarchive in the RFC. Put it in the
> shepherd writeup or in the history in the datatracker as a comment (chairs
> can
> do this). Otherwise it adds to the list of URLs that we have to keep alive
> forever.

[LES:] I am open to whatever the chairs/AD think is appropriate. But very few 
people actually look at the shepherd writeup or Datatracker history. Having it 
in the document provides context for those readers who are curious as to why 
the bis changes were made. I don’t think it would be as effective if it were 
removed from the document.
I take your point that the URL may someday become stale - but if it did that 
would apply to the other locations as well.
The section in which it appears is informational only - it is not a normative 
part of the document - so I am inclined to leave it as is.
But again, happy to follow consensus on this.

 Les

> 
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-isis-te-app-13

2020-06-04 Thread Les Ginsberg (ginsberg)

Jouni -

Just to let you know that V14 of the draft was posted today and it includes all 
of the corrections you requested.
Thanx again for your review.

   Les


> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Friday, May 29, 2020 8:02 AM
> To: Jouni Korhonen ; gen-art@ietf.org
> Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; l...@ietf.org
> Subject: RE: Genart last call review of draft-ietf-isis-te-app-13
> 
> Jouni -
> 
> Thanx for the review.
> 
> I have addressed the editorial issues you raised - though I will wait for
> additional comments from other reviewers before publishing a new version.
> 
>Les
> 
> 
> > -Original Message-
> > From: Jouni Korhonen via Datatracker 
> > Sent: Friday, May 29, 2020 6:11 AM
> > To: gen-art@ietf.org
> > Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; l...@ietf.org
> > Subject: Genart last call review of draft-ietf-isis-te-app-13
> >
> > Reviewer: Jouni Korhonen
> > Review result: Ready with Nits
> >
> > I am the assigned Gen-ART reviewer for this draft. The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed
> > by the IESG for the IETF Chair.  Please treat these comments just
> > like any other last call comments.
> >
> > For more information, please see the FAQ at
> >
> > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> >
> > Document: draft-ietf-isis-te-app-??
> > Reviewer: Jouni Korhonen
> > Review Date: 2020-05-29
> > IETF LC End Date: 2020-05-29
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary:
> >
> > Not really my area of expertise, however, I did not spot any issues during
> the
> > review. The document is ready for publication.
> >
> > Major issues:
> >
> > None.
> >
> > Minor issues:
> >
> > None.
> >
> > Nits/editorial comments:
> >
> > * There are spacing issues mostly with parenthesis in the text that the RFC
> > editor likely takes care of. * On line 165 SR is used without expanding it. 
> > The
> > expansion is obvious but the RFC has both "Segment Routing" and "Shared
> > Risk"
> > used with SRxx.. * At least Section 5 has "is NOT" and "does NOT" emphasis
> > used. I would use just "is not" and "does not", since those with "NOT" are
> > not
> > in listed in normal "Requirements Language".
> >

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-isis-te-app-13

2020-05-29 Thread Les Ginsberg (ginsberg)

Jouni -

Thanx for the review.

I have addressed the editorial issues you raised - though I will wait for 
additional comments from other reviewers before publishing a new version.

   Les


> -Original Message-
> From: Jouni Korhonen via Datatracker 
> Sent: Friday, May 29, 2020 6:11 AM
> To: gen-art@ietf.org
> Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; l...@ietf.org
> Subject: Genart last call review of draft-ietf-isis-te-app-13
> 
> Reviewer: Jouni Korhonen
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-isis-te-app-??
> Reviewer: Jouni Korhonen
> Review Date: 2020-05-29
> IETF LC End Date: 2020-05-29
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> Not really my area of expertise, however, I did not spot any issues during the
> review. The document is ready for publication.
> 
> Major issues:
> 
> None.
> 
> Minor issues:
> 
> None.
> 
> Nits/editorial comments:
> 
> * There are spacing issues mostly with parenthesis in the text that the RFC
> editor likely takes care of. * On line 165 SR is used without expanding it. 
> The
> expansion is obvious but the RFC has both "Segment Routing" and "Shared
> Risk"
> used with SRxx.. * At least Section 5 has "is NOT" and "does NOT" emphasis
> used. I would use just "is not" and "does not", since those with "NOT" are
> not
> in listed in normal "Requirements Language".
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

2020-05-14 Thread Les Ginsberg (ginsberg)

Elwyn’s comment was:


I was trying to understand
why a router that satisfies the previous condition so that it is
legitimate for it to announce ELC with any IP address prefix might wish
to only announce it with some prefixes and not others.


The answer to that is clearly stated in the draft (emphasis added):

“If the router supports ELs on all of its interfaces, it SHOULD
   advertise the ELC with every local host prefix it advertises in OSPF.”


What is needed is to know whether traffic routed via a particular node can 
depend upon that node supporting EL.  That info is communicated by advertising 
ELC for the local host prefixes only.
No need to do so for other prefixes.

HTH

   Les


From: Lsr  On Behalf Of Alvaro Retana
Sent: Thursday, May 14, 2020 12:46 PM
To: Acee Lindem (acee) ; Peter Psenak (ppsenak) 
; Elwyn Davies ; gen-art@ietf.org
Cc: l...@ietf.org; last-c...@ietf.org; draft-ietf-ospf-mpls-elc@ietf.org
Subject: Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

Hi!

Yes, we cannot specify something that routers unaware of this specification 
should or shouldn’t do.

I believe that Elwyn’s point is this: *if a router supports this specification* 
then when would it not advertise the ELC?  IOW, the specification only 
obviously applies to implementations that support it — in that case I would 
think that if a router supports ELs on all of its interfaces then it would 
always advertise the ELC, right?


Thanks!

Alvaro.


On May 11, 2020 at 3:18:34 PM, Acee Lindem (acee) 
(a...@cisco.com) wrote:
Note that the optionality of ERLD-MSD advertisements appears on
reflection to be a more serious issue than just an editorial nit.

So what would you suggest? There are existing implementations that support 
multipath forwarding entropy using MPLS entropy labels but do not signal that 
capability in OSPF. We can't have a document that retroactively mandates that 
they signal it. This wouldn't be backward compatible. How can you possibly see 
this as a serious issue?
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-lsr-isis-rfc5306bis-04

2019-08-16 Thread Les Ginsberg (ginsberg)

Russ -

Thanx for the careful review.
I have uploaded V5 of the draft which addresses your comments subject to my 
responses inline.


> -Original Message-
> From: Russ Housley via Datatracker 
> Sent: Thursday, August 15, 2019 2:38 PM
> To: gen-art@ietf.org
> Cc: draft-ietf-lsr-isis-rfc5306bis@ietf.org; i...@ietf.org; l...@ietf.org
> Subject: Genart last call review of draft-ietf-lsr-isis-rfc5306bis-04
> 
> Reviewer: Russ Housley
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-lsr-isis-rfc5306bis-04
> Reviewer: Russ Housley
> Review Date: 2019-08-15
> IETF LC End Date: 2019-08-27
> IESG Telechat date: Unknown
> 
> Summary: Ready with Nits
> 
> Major Concerns:
> 
> None
> 
> 
> Minor Concerns:
> 
> None
> 
> 
> Nits:
> 
> Section 3.2.3: The lettered paragraphs at the top of the section
> begin with lower case letters, but the lettered paragraphs at the
> top of the section begin with upper case letters.  Please be
> consistent.
> 
[Les:] Done

> Section 3.2.3: s/time after which the adjacency will now expire/
> /time after which the adjacency will expire/
> 
[Les:] I left this unchanged.  The text is identical to text in Section 3.2.1 
regarding the RA bit. The point of using "now expire" is to emphasize that the 
expiration time has been adjusted as a result of the RR/PR request.
Hope this is OK with you.

> Section 3.2.3 says:
> 
>... It
>is therefore useful to signal a planned restart (if the forwarding
>plane on the restarting router is maintained) so that ...
> 
> I suggest:
> 
>... If
>the forwarding plane on the restarting router is maintained, it
>is useful to signal a planned restart so that ...

[Les:] I rewrote this paragraph. The term "restart" has been defined in Section 
2 to be associated with a control plane restart which involves maintenance of 
the forwarding plane - so some of the text was redundant. 
I hope the revised text is both more readable and more precise.

   Les

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-isis-segment-routing-extensions-23

2019-04-17 Thread Les Ginsberg (ginsberg)

Erik -

Thanx for the detailed review.
I have published V24 of the draft which addresses all of your comments (and a 
few pending AD review comments from Alvaro).
Some exceptions noted below.

> -Original Message-
> From: Erik Kline via Datatracker 
> Sent: Wednesday, April 17, 2019 7:20 PM
> To: gen-art@ietf.org
> Cc: l...@ietf.org; i...@ietf.org; draft-ietf-isis-segment-routing-
> extensions@ietf.org
> Subject: Genart last call review of 
> draft-ietf-isis-segment-routing-extensions-
> 23
> 
> Reviewer: Erik Kline
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-isis-segment-routing-extensions-??
> Reviewer: Erik Kline
> Review Date: 2019-04-17
> IETF LC End Date: 2019-04-17
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> For what little I know of IS-IS and segment routing, this all seems to make
> general sense.  I simply had some language/style nits (below).
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> # Section 1
> 
> * "SR's control-plane can be applied ..., and do not require...".  It looks
> like the subject of the sentence is "control-plane" and so perhaps "do not"
> should be "does not".
> 
> * s/draft/document/g
> 
> # Section 2.1
> 
> * "Algorithms identifiers" -> "Algorithm identifiers"
> 
> # Section 2.2.2
> 
> * Length: variable
> 
> Should this say "11-12" (1 + 1 + 6 + 3-4)?
> 
[Les:] No. System ID may be a value from 1-8 octets in length (though in 
practice only the value 6 is used). I have clarified the text to mention that 
this field is of "ID Length" (as per ISO 10589).

> * "set of Adj-SID each router" -> "set of Adj-SIDs each router", perhaps.
> 
> # Section 2.3
> 
> s/valu eis/value is/
> 
> # Section 2.4
> 
> Silly, naive question: does the length include the sum of the octets
> representing the sub-TLVs?
>
[Les:] Yes. TLV length includes all of the data contained in the TLV - 
including sub-TLVs.

Les

> # Section 2.4.6
> 
> In example 3, I would recommend s/0xD/0x0D/ & s/0x0/0x00/ & s/0x1/0x01/
> ,
> but perhaps that's just a personal readability thing.
> 
> # Section 3.3
> 
> * "by other components than" -> "by components other than", perhaps.
> 
> * "to know what are the local SIDs" -> "to know what the local SIDs are",
>   perhaps.
> 
> * "The SRLB sub-TLV is used for this purpose...", (instead of "that purpose")
> maybe.
> 
> * "which mechanisms are outside" -> "which are outside", maybe.
> 
> * "the SRLB TLV" -> "the SRLB sub-TLV", I think.
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-idr-te-pm-bgp-15

2018-12-13 Thread Les Ginsberg (ginsberg)

Erik -

Thanx for the review.
Responses inline.

> -Original Message-
> From: Erik Kline 
> Sent: Wednesday, December 12, 2018 11:30 PM
> To: gen-art@ietf.org
> Cc: i...@ietf.org; i...@ietf.org; draft-ietf-idr-te-pm-bgp@ietf.org
> Subject: Genart last call review of draft-ietf-idr-te-pm-bgp-15
> 
> Reviewer: Erik Kline
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-idr-te-pm-bgp-??
> Reviewer: Erik Kline
> Review Date: 2018-12-12
> IETF LC End Date: 2018-12-12
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Seems like a fairly straightforward detailing of TLVs the meanings
> of
> which are defined elsewhere.
> 
> Major issues:  [obvious] A primary normative reference is itself still a 
> draft.
>  I expect they'll get published together.
> 
[Les:] The reference to draft-ietf-lsr-isis-rfc7810bis (rather than current 
RFC7810) was put in at the request of the AD. 
You are correct that this introduces a dependency between this document and 
7810bis and this document will remain in MISSREF state until 7810bis is 
published.
As both drafts are in the review process we do not expect there to be a 
significant delay.

In any case this isn't a "major" issue is it? It seems worthwhile to have the 
reference be to the newer version of 7810 - and this certainly isn’t the only 
case where one document is dependent on another which has yet to be published.


> Minor issues: None.
> 
> Nits/editorial comments: Some wording on Section 3 could use some
> readability
> cleanup, perhaps.
> 
> [1] "represent the state and resources availability" does not somehow scan
> well
> for me. "state and resource availability"? "state and availability of
> resources"?
> 
[Les:] "state and resource availability" is fine with me.

> [2] "are assumed to have all the required security and authentication
> mechanism" also seems like it could read more smoothly.  "are assumed to
> have
> implemented all require security and authentication mechanisms..."?
>
[Les:] How about "assumed to support all the required..."
??

If you are OK with the suggestions I will publish an updated version very soon.

   Les

 
> I'm sure the editors will have better ideas.
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-lsr-isis-rfc7810bis-03

2018-12-09 Thread Les Ginsberg (ginsberg)

Paul -

Thanx for the careful review and the kind words.

   Les


> -Original Message-
> From: Paul Kyzivat 
> Sent: Sunday, December 09, 2018 12:06 PM
> To: draft-ietf-lsr-isis-rfc7810bis@ietf.org
> Cc: General Area Review Team 
> Subject: Gen-ART Last Call review of draft-ietf-lsr-isis-rfc7810bis-03
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed by the
> IESG for the IETF Chair. Please treat these comments just like any other
> last call comments. For more information, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-lsr-isis-rfc7810bis-03
> Reviewer: Paul Kyzivat
> Review Date: 2018-12-09
> IETF LC End Date: 2018-12-12
> IESG Telechat date: ?
> 
> Summary:
> 
> This draft is ready for publication as a Standards Track RFC.
> 
> Issues: None
> 
> It was very easy to review this document because a diff with RFC7810
> showed me everything of note, and this was consistent with Appendix A.
> 
> Changing an RFC in a way that is not backwards compatible is
> problematic, but the authors have clearly considered the issues and find
> this the best of bad alternatives.
> 
> The reference to draft-ietf-idr-te-pm-bgp-14 is now out of date. I'm not
> raising it as a nit because chasing references to drafts is futile and
> this will be fixed by the editor.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [spring] Genart last call review of draft-ietf-spring-segment-routing-ldp-interop-11

2018-05-14 Thread Les Ginsberg (ginsberg)

Joel -

I don’t fully understand the rest of your comment then. You said:

" And that document does appear to define the  SRMS."

(where "that document" refers to draft-ietf-spring-conflict-resolution).

But the conflict resolution document never defined an SRMS - it merely 
described how SRMS advertisements were used in the context of conflict 
resolution.
So if you are unsatisfied with the "SRMS definition" in ldp-interop draft I 
think you need to be more clear as to what you think is lacking.

I leave it to the draft authors to resolve this issue with you.

Les


> -Original Message-
> From: Joel Halpern Direct <jmh.dir...@joelhalpern.com>
> Sent: Monday, May 14, 2018 1:16 PM
> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Joel Halpern
> <j...@joelhalpern.com>; gen-art@ietf.org
> Cc: draft-ietf-spring-segment-routing-ldp-interop@ietf.org;
> spr...@ietf.org; i...@ietf.org
> Subject: Re: [spring] Genart last call review of draft-ietf-spring-segment-
> routing-ldp-interop-11
> 
> Thanks Les.  I wondered if that were the case.
> 
> Looking again at the draft, the problem then is that section 4.2 of the 
> subject
> draft is not a normative definition of an SRMS.  It states the general
> functionality, and then provides an example of how it would work in the
> given scenario.
> 
> If the text were enhanced to be an effective normative definition of an
> SRMS, then that would also resolve the quesiton of the intended status of
> the draft.
> 
> Yours,
> Joel
> 
> On 5/14/18 4:12 PM, Les Ginsberg (ginsberg) wrote:
> > Joel -
> >
> > I am not an author of this draft - but I am an author on the referenced 
> > IS-IS
> draft - which I assume is one of the drafts mentioned in  your comment:
> >
> >>  Server).  Looking at the relevant routing protocol document, they 
> >> point
> to
> >>  https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05 
> >> as
> the
> >>  defining source for the SRMS.
> >
> > The IGP document references in the ldp-interop draft are stale. Newer
> versions of the IGP drafts have been published and they no longer reference
> draft-ietf-spring-conflict-resolution - a draft which is no longer active.
> >
> > HTH
> >
> >  Les
> >
> >
> >> -Original Message-
> >> From: spring <spring-boun...@ietf.org> On Behalf Of Joel Halpern
> >> Sent: Monday, May 14, 2018 1:01 PM
> >> To: gen-art@ietf.org
> >> Cc: draft-ietf-spring-segment-routing-ldp-interop@ietf.org;
> >> spr...@ietf.org; i...@ietf.org
> >> Subject: [spring] Genart last call review of
> >> draft-ietf-spring-segment-routing-
> >> ldp-interop-11
> >>
> >> Reviewer: Joel Halpern
> >> Review result: Ready with Issues
> >>
> >> I am the assigned Gen-ART reviewer for this draft. The General Area
> >> Review Team (Gen-ART) reviews all IETF documents being processed by
> >> the IESG for the IETF Chair.  Please treat these comments just like
> >> any other last call comments.
> >>
> >> For more information, please see the FAQ at
> >>
> >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> >>
> >> Document: draft-ietf-spring-segment-routing-ldp-interop-11
> >> Reviewer: Joel Halpern
> >> Review Date: 2018-05-14
> >> IETF LC End Date: 2018-05-24
> >> IESG Telechat date: Not scheduled for a telechat
> >>
> >> Summary: This document appears to be ready for publication as an RFC.
> >> The question of whether it is an Informational RFC or a Proposed
> >> Standards track RFC is one that the ADs should examine.
> >>
> >> Major issues:
> >>  This document is quite readable, and quite useful.  If my reading 
> >> below
> >>  (minor comment about section 4.2) is wrong, then everything is fine.
> >>  However, reading the text, it does not appear to define SRMS.  Rather,
> it
> >>  describes a good way to use SRMS to achive smooth SR - LDP
> >> integration and
> >>  migration.  As such, this seems to me to be a really good 
> >> Informational
> >>  Document.
> >>
> >> Minor issues:
> >>  Section 4.2 states that it defines the SRMS (Segment Routing Mapping
> >>  Server).  Looking at the relevant routing protocol document, they 
> >> point
> to
> >>  https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05 
> >> as
> the
> >>  defining source for the SRMS.  And that document does appear to
> >> define the
> >>  SRMS.
> >>
> >> Nits/editorial comments:
> >>
> >>
> >> ___
> >> spring mailing list
> >> spr...@ietf.org
> >> https://www.ietf.org/mailman/listinfo/spring
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat Call review of draft-ietf-bier-isis-extensions-06

2018-02-12 Thread Les Ginsberg (ginsberg)

Meral -

Thanx for the review.
Some of your comments have already been addressed in the latest version (07) 
published a few days ago.

Responses inline.

From: Meral Shirazipour [mailto:meral.shirazip...@ericsson.com]
Sent: Monday, February 12, 2018 8:02 PM
To: draft-ietf-bier-isis-extensions@ietf.org; gen-art@ietf.org
Subject: Gen-ART Telechat Call review of draft-ietf-bier-isis-extensions-06

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair. Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.

For more information, please see the FAQ at 
.

Document: draft-ietf-bier-isis-extensions-06
Reviewer: Meral Shirazipour
Review Date: 2018-02-12
IETF LC End Date: 2018-02-22 ?
IESG Telechat date: 2018-02-22

Summary: This draft is ready to be published as Standards Track RFC but I have 
some comments.

Major issues:
Minor issues:
Nits/editorial comments:
-please updated references to latest draft version/RFC number

[Les:] Done in V 07

-Section 2 would be clearer is the definitions introduced only in this document 
are identified as such

[Les:]  I don't think there are any introduced by this document. All of the 
definitions mentioned in Section 2 come from RFC 8279.

-Please spell out  multi topology, sub-domain at  first use for MT SD
[Les:] In Section 4.1 where we introduce the use of  here is what the 
text says (emphasis added):

"Within such a domain, the extensions defined in this document
   advertise BIER information for one or more BIER sub-domains.  Each
   sub-domain is uniquely identified by a subdomain-id.  Each subdomain
   is associated with a single ISIS topology [RFC5120], which may be any
   of the topologies supported by ISIS.  Local configuration controls
   which  pairs are supported by a router."

Do you think further clarification as to the meaning of  is still 
needed??

-[Page 6], "advertisments."--->"advertisements"

[Les:] Corrected in V 07.

-[Page 8], "occurences"--->"occurrences"

[Les:] The section which contains this misspelling was removed in V 07.

   Les

Best Regards,
Meral
---
Meral Shirazipour
Ericsson Research
www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-ospf-link-overload-11

2018-01-08 Thread Les Ginsberg (ginsberg)

If the WG consensus is for “GLS” so be it…but I would like to reemphasize two 
things:

1)There are use cases where the intent is NOT to shutdown the link

2)Once the link is shutdown the extension is no longer used since there is no 
longer an adjacency – so to me it makes a lot more sense to pick a name which 
reflects how the link is to be used while it is still up.

   Les



From: Pushpasis Sarkar [mailto:pushpasis.i...@gmail.com]
Sent: Monday, January 08, 2018 9:22 AM
To: Bruno Decraene <bruno.decra...@orange.com>
Cc: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>; 
Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Ketan Talaulikar (ketant) 
<ket...@cisco.com>; Joel Halpern <j...@joelhalpern.com>; gen-art@ietf.org; 
o...@ietf.org; i...@ietf.org; draft-ietf-ospf-link-overload@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11

Hi Joel et al,

+1 for 'graceful-link-shutdown'. Another possibility may be 
'link-decommission'..

Thanks and regards
-Pushpasis

On Mon, Jan 8, 2018 at 7:09 PM, 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote:


From: Shraddha Hegde
How about “graceful-link-shutdown” ?

Looks good to me.

Also, FYI, for BGP sessions, in the GROW WG we used the term “Graceful BGP 
session shutdown” and named the BGP community “GRACEFUL_SHUTDOWN” so this would 
align on the terminology.
https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-13

Best regards,
--Bruno


Rgds
Shraddha



From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, January 5, 2018 6:50 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; 
Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>; Joel 
Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-art@ietf.org<mailto:gen-art@ietf.org>
Cc: o...@ietf.org<mailto:o...@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11

It is not in “maintenance" mode yet as it is still being used. However, it is 
better than “overload”. “pending-maintenance” is a bit long which is why I 
suggested “pending-shutdown” since “shutdown” is term that vendors have used 
for eons to described an interface that is not in service.
Thanks,
Acee

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Thursday, January 4, 2018 at 11:56 PM
To: "Ketan Talaulikar (ketant)" <ket...@cisco.com<mailto:ket...@cisco.com>>, 
Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-art@ietf.org<mailto:gen-art@ietf.org>" 
<gen-art@ietf.org<mailto:gen-art@ietf.org>>
Cc: OSPF WG List <o...@ietf.org<mailto:o...@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>"
 
<draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Ketan –

“maintenance” I could live with.

“GIR” seems to not be generic enough.

   Les


From: Ketan Talaulikar (ketant)
Sent: Thursday, January 04, 2018 8:09 PM
To: Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; Les Ginsberg 
(ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; Joel Halpern 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-art@ietf.org<mailto:gen-art@ietf.org>
Cc: o...@ietf.org<mailto:o...@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Hello,

May I suggest something more generic like “Maintenance Mode” or “Graceful 
Insertion/Removal (GIR) Mode” which could be defined so as to cover the 
multiple scenarios in question (e.g. pending shutdown, down for repairs, last 
resort due to poor link quality, etc.).

Thanks,
Ketan

From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: 05 January 2018 08:14
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; 
Joel Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-art@ietf.org<mailto:gen-art@ietf.org>
Cc: o...@ietf.org<mailto:o...@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-o

Re: [Gen-art] Genart last call review of draft-ietf-ospf-link-overload-11

2018-01-05 Thread Les Ginsberg (ginsberg)

I think the point here is that the link is not necessarily going to be shutdown 
in all cases.

For example, the operator needs to do some testing of the link. They set 
max-metric to divert traffic, then keep the link up so they can send OAM 
traffic over the link and try to determine what problems may exist.

It is a mistake to assume that this mechanism is always intended to be used as 
a precursor to link shutdown.

   Les


From: Acee Lindem (acee)
Sent: Friday, January 05, 2018 8:47 AM
To: Shraddha Hegde <shrad...@juniper.net>; Les Ginsberg (ginsberg) 
<ginsb...@cisco.com>; Ketan Talaulikar (ketant) <ket...@cisco.com>; Joel 
Halpern <j...@joelhalpern.com>; gen-art@ietf.org
Cc: o...@ietf.org; i...@ietf.org; draft-ietf-ospf-link-overload@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11

Works for me.
Acee

From: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Date: Friday, January 5, 2018 at 11:15 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Les Ginsberg 
(ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, "Ketan Talaulikar 
(ketant)" <ket...@cisco.com<mailto:ket...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-art@ietf.org<mailto:gen-art@ietf.org>" 
<gen-art@ietf.org<mailto:gen-art@ietf.org>>
Cc: OSPF WG List <o...@ietf.org<mailto:o...@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>"
 
<draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

How about “graceful-link-shutdown” ?

Rgds
Shraddha



From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, January 5, 2018 6:50 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; 
Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>; Joel 
Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-art@ietf.org<mailto:gen-art@ietf.org>
Cc: o...@ietf.org<mailto:o...@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11

It is not in “maintenance" mode yet as it is still being used. However, it is 
better than “overload”. “pending-maintenance” is a bit long which is why I 
suggested “pending-shutdown” since “shutdown” is term that vendors have used 
for eons to described an interface that is not in service.
Thanks,
Acee

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Thursday, January 4, 2018 at 11:56 PM
To: "Ketan Talaulikar (ketant)" <ket...@cisco.com<mailto:ket...@cisco.com>>, 
Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-art@ietf.org<mailto:gen-art@ietf.org>" 
<gen-art@ietf.org<mailto:gen-art@ietf.org>>
Cc: OSPF WG List <o...@ietf.org<mailto:o...@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload....@ietf.org>"
 
<draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Ketan –

“maintenance” I could live with.

“GIR” seems to not be generic enough.

   Les


From: Ketan Talaulikar (ketant)
Sent: Thursday, January 04, 2018 8:09 PM
To: Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; Les Ginsberg 
(ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; Joel Halpern 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-art@ietf.org<mailto:gen-art@ietf.org>
Cc: o...@ietf.org<mailto:o...@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload....@ietf.org>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Hello,

May I suggest something more generic like “Maintenance Mode” or “Graceful 
Insertion/Removal (GIR) Mode” which could be defined so as to cover the 
multiple scenarios in question (e.g. pending shutdown, down for repairs, last 
resort due to poor link quality, etc.).

Thanks,
Ketan

From: OSPF [mai

Re: [Gen-art] Genart last call review of draft-ietf-ospf-link-overload-11

2018-01-04 Thread Les Ginsberg (ginsberg)

Ketan –

“maintenance” I could live with.

“GIR” seems to not be generic enough.

   Les


From: Ketan Talaulikar (ketant)
Sent: Thursday, January 04, 2018 8:09 PM
To: Acee Lindem (acee) <a...@cisco.com>; Les Ginsberg (ginsberg) 
<ginsb...@cisco.com>; Joel Halpern <j...@joelhalpern.com>; gen-art@ietf.org
Cc: o...@ietf.org; i...@ietf.org; draft-ietf-ospf-link-overload@ietf.org
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Hello,

May I suggest something more generic like “Maintenance Mode” or “Graceful 
Insertion/Removal (GIR) Mode” which could be defined so as to cover the 
multiple scenarios in question (e.g. pending shutdown, down for repairs, last 
resort due to poor link quality, etc.).

Thanks,
Ketan

From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: 05 January 2018 08:14
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; 
Joel Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-art@ietf.org<mailto:gen-art@ietf.org>
Cc: o...@ietf.org<mailto:o...@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>
Subject: Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

Hi Les,

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Thursday, January 4, 2018 at 9:26 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-art@ietf.org<mailto:gen-art@ietf.org>" 
<gen-art@ietf.org<mailto:gen-art@ietf.org>>
Cc: OSPF WG List <o...@ietf.org<mailto:o...@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>"
 
<draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11


> >Minor issues:

> >I understand the WG likes using the term "overload" for a link

> >being taken

> >out of service.  I think people will learn what we mean.  I do wish

> >we had

> >not chosen to misuse the words in this fashion.  This is much more a

> >graceful-link-close indication (or clsoe-pending indication) than

> >it is an

> >overload indication.

>

> I agree with this comment but I wasn’t sure we’d reach consensus on a

> better alternative. However, after some though and consideration of current

> OSPF router terminology, I’d propose we use the term “Pending-Shutdown”.

> Does anyone not agree that this is a more appropriate moniker for the TLV

> and state?

>

[Les:] I agree with Joel's comment. The use of the term "overload" is 
unfortunate.

But "pending-shutdown" isn’t appealing to me because - at least in most use 
cases - you aren't actually going to shutdown the link. What you are going to 
do is make a link the "link of last resort".

This seems a better choice.

That is not the use case - you are going to take the link down. It is not going 
to be the "link of last resort”, it is the currently the “link of last resort” 
and will imminently be taken down.




The suggestion from Shraddha that this term was borrowed from IS-IS isn't 
accurate. "overload" in IS-IS has a very different meaning - it indicates a 
node either has an incomplete LSDB or (a la RFC 
3277<https://datatracker.ietf.org/doc/rfc3277/> )an incomplete forwarding plane.



The only use of "link overload" in IS-IS occurs in 
https://tools.ietf.org/html/draft-ietf-isis-reverse-metric-07#section-3.6 and 
this was added recently to support the (very useful) TE use case which was 
defined in https://tools.ietf.org/html/draft-ietf-ospf-link-overload-11 . When 
this was done the term "link-overload" was cut and pasted from the OSPF draft. 
I think this should also be changed in the IS-IS draft.

Agreed.

Thanks,
Acee



   Les



> Thanks,

> Acee

> >

> >

> >

>

> ___

> OSPF mailing list

> o...@ietf.org<mailto:o...@ietf.org>

> https://www.ietf.org/mailman/listinfo/ospf
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-ospf-link-overload-11

2018-01-04 Thread Les Ginsberg (ginsberg)

Acee -

From: Acee Lindem (acee)
Sent: Thursday, January 04, 2018 6:44 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Joel Halpern 
<j...@joelhalpern.com>; gen-art@ietf.org
Cc: o...@ietf.org; i...@ietf.org; draft-ietf-ospf-link-overload@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11

Hi Les,

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Thursday, January 4, 2018 at 9:26 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-art@ietf.org<mailto:gen-art@ietf.org>" 
<gen-art@ietf.org<mailto:gen-art@ietf.org>>
Cc: OSPF WG List <o...@ietf.org<mailto:o...@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>"

<draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

> >Minor issues:

> >I understand the WG likes using the term "overload" for a link

> >being taken

> >out of service.  I think people will learn what we mean.  I do wish

> >we had

> >not chosen to misuse the words in this fashion.  This is much more a

> >graceful-link-close indication (or clsoe-pending indication) than

> >it is an

> >overload indication.

>

> I agree with this comment but I wasn’t sure we’d reach consensus on a

> better alternative. However, after some though and consideration of current

> OSPF router terminology, I’d propose we use the term “Pending-Shutdown”.

> Does anyone not agree that this is a more appropriate moniker for the TLV

> and state?

>

[Les:] I agree with Joel's comment. The use of the term "overload" is 
unfortunate.

But "pending-shutdown" isn’t appealing to me because - at least in most use 
cases - you aren't actually going to shutdown the link. What you are going to 
do is make a link the "link of last resort".

This seems a better choice.

That is not the use case - you are going to take the link down. It is not going 
to be the "link of last resort”, it is the currently the “link of last resort” 
and will imminently be taken down.
[Les:] https://tools.ietf.org/html/draft-ietf-ospf-link-overload-11#section-2

2.  Motivation

…
   4.  Allow the link to be used as last resort link to prevent traffic
   disruption when alternate paths are not available.

This is the real value of the protocol extension. If the intention was to take 
the link out of service the extension would not be worth much as the behavioral 
difference between (normal metric->max metric->down) vs (normal metric->down) 
is very small.
This is also consistent with my recollection of the service providers 
motivation when the early versions of isis-reverse-metric were presented. The 
question was asked “why don’t you simply take the link down?” and the response 
was “We don’t want to take the link down – we want it to be the link of last 
resort so that if all else fails we can still use the link to get to the node.”

(As an aside, if the idea was to more gracefully redirect traffic away from the 
link in preparation for taking the link down you would need to use a metric 
offset as the isis-reverse-metric draft does. Then you could direct traffic 
away from the link in incremental steps. I don’t mean to suggest this will be a 
common use case of reverse-metric – but it would at least be useful if the 
intent was to take the link down in a short while).

   Les

The suggestion from Shraddha that this term was borrowed from IS-IS isn't 
accurate. "overload" in IS-IS has a very different meaning - it indicates a 
node either has an incomplete LSDB or (a la RFC 
3277<https://datatracker.ietf.org/doc/rfc3277/> )an incomplete forwarding plane.

The only use of "link overload" in IS-IS occurs in 
https://tools.ietf.org/html/draft-ietf-isis-reverse-metric-07#section-3.6 and 
this was added recently to support the (very useful) TE use case which was 
defined in https://tools.ietf.org/html/draft-ietf-ospf-link-overload-11 . When 
this was done the term "link-overload" was cut and pasted from the OSPF draft. 
I think this should also be changed in the IS-IS draft.

Agreed.

Thanks,
Acee

   Les

> Thanks,

> Acee

> >

> >

> >

>

> ___

> OSPF mailing list

> o...@ietf.org<mailto:o...@ietf.org>

> https://www.ietf.org/mailman/listinfo/ospf
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-ospf-link-overload-11

2018-01-04 Thread Les Ginsberg (ginsberg)

> >Minor issues:

> >I understand the WG likes using the term "overload" for a link

> >being taken

> >out of service.  I think people will learn what we mean.  I do wish

> >we had

> >not chosen to misuse the words in this fashion.  This is much more a

> >graceful-link-close indication (or clsoe-pending indication) than

> >it is an

> >overload indication.

>

> I agree with this comment but I wasn’t sure we’d reach consensus on a

> better alternative. However, after some though and consideration of current

> OSPF router terminology, I’d propose we use the term “Pending-Shutdown”.

> Does anyone not agree that this is a more appropriate moniker for the TLV

> and state?

>

[Les:] I agree with Joel's comment. The use of the term "overload" is 
unfortunate.

But "pending-shutdown" isn’t appealing to me because - at least in most use 
cases - you aren't actually going to shutdown the link. What you are going to 
do is make a link the "link of last resort".

This seems a better choice.



The suggestion from Shraddha that this term was borrowed from IS-IS isn't 
accurate. "overload" in IS-IS has a very different meaning - it indicates a 
node either has an incomplete LSDB or (a la RFC 
3277 )an incomplete forwarding plane.



The only use of "link overload" in IS-IS occurs in 
https://tools.ietf.org/html/draft-ietf-isis-reverse-metric-07#section-3.6 and 
this was added recently to support the (very useful) TE use case which was 
defined in https://tools.ietf.org/html/draft-ietf-ospf-link-overload-11 . When 
this was done the term "link-overload" was cut and pasted from the OSPF draft. 
I think this should also be changed in the IS-IS draft.



   Les



> Thanks,

> Acee

> >

> >

> >

>

> ___

> OSPF mailing list

> o...@ietf.org

> https://www.ietf.org/mailman/listinfo/ospf
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [OSPF] Genart last call review of draft-ietf-ospf-segment-routing-extensions-19

2017-10-12 Thread Les Ginsberg (ginsberg)

In regards to

> > 4. Section 3.3:
> >
> > 'The originating router MUST NOT advertise overlapping ranges.'
> >
> > How are conflicts resolved at receiver?
> 
> SRLB sub-TLV is not used by routers running ISIS. The advertisement is only
> there for the benefit of external entities such as controllers so they can
> determine what labels are available for assignment. We do not define
> controllers behavior in our drafts.
> 
> >
[Les:] SRLB usage is not the same as SRGB usage.

SRLB is a local space for each node to allocate node private labels. There is 
no notion of conflicting usage e.g. Node A can use 1000 as an adj-sid for one 
of its links and Node B can use SID 1000 as an adj-sid for one of its links and 
this is not a conflict. In other words the scope of the SIDs is local to the 
advertising node.

Further, nodes are NOT required to validate that a private SID (such as an 
adj-sid) is allocated from the SRLB of the advertising node - it is legal to 
assign a SID from outside of this space - so - as Peter has indicated - other 
routers do not make use of SRLB advertisements. IT is there for the convenience 
of external entities only.

It should be obvious that advertising overlapping ranges makes the 
advertisement ambiguous. Not sure what else needs to be said.

???

Les



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-isis-mi-bis-02

2017-04-13 Thread Les Ginsberg (ginsberg)

Orit -

It is obvious you spent a lot of time on this review - and I do want to be 
respectful of that.
However, there is a larger context here which I think has a significant bearing 
on handling of many of your comments.

RFC 6822 was published over 4 years ago. Multiple interoperable implementations 
exist. The bis version makes some modest - but significant changes. However, we 
deliberately strived to keep the bis version as consistent as possible with RFC 
6822 in order to minimize the possibility that aspects of the specification 
which had NOT been changed would be reinterpreted simply because the wording 
had changed. So, in cases where you suggest (below) that a different wording is 
desirable I am very reluctant to make such changes because of the above concern.
If I do not indicate any response to a particular comment you can interpret as 
meaning:

"Unnecessary changes relative to RFC 6822 are not desirable."

Inline.

> -Original Message-
> From: Orit Levin [mailto:or...@microsoft.com]
> Sent: Thursday, April 13, 2017 4:59 PM
> To: Les Ginsberg (ginsberg); gen-art@ietf.org
> Cc: i...@ietf.org; draft-ietf-isis-mi-bis@tools.ietf.org
> Subject: RE: Gen-ART Last Call review of draft-ietf-isis-mi-bis-02
> 
> Hi Les,
> Sorry for the delay in response.
> Your feedback was very helpful. Below is a refresh of my comments. I tried
> to make them more pointed and some are new.
> 
> Summary: This draft is "ready with issues" for publication.
> 
> General:
> 1) For implementers who are familiar with the history and the intent of this
> extension, the information in the draft is probably sufficient to serve as a
> check list for implementing a multi-instance IS-IS router. For all other 
> readers,
> the document doesn't contain an overview of the new mode of operation,
> i.e. where the instances are not a configuration and an internal
> implementation choice only, but are exposed through the protocol to
> achieve the stated objective. Lacking such an overview, the reader needs to
> reverse-engineer the logic behind the documented guidance.

[Les:] I am not sure I understand your concern. You seem to be suggesting that 
readers won't know when to use MI and when to simply create multiple non-MI 
instances of the protocol.
The short answer to that is that it is not the purpose of this document to make 
that decision. We have provided some new functionality - it is up to the user 
to decide when it is appropriate to use the new functionality and when it is 
not. We have provided some guidance in Sections 3 and 4 - but this is 
non-normative - as it should be.
But your use of "reverse-engineer" confuses me, so likely I do not understand 
your point.

As regards new vs old readers, the new version of the document provides as much 
(or as little) guidance as RFC 6822 - so I do not see why new readers would 
have any more issues than new readers of RFC 6822 had 4 years ago.


> 2) The draft talks about "extensions" in plural. Based on a single extension 
> on
> the wire and the overall goal of the new mechanism, I would say that it is a
> single extension only.  How many protocol extensions does this document
> define? If they can be clearly separated, then it needs to be clarified
> throughout the document. Otherwise, the language throughout the
> document needs to be changed from "extensions" to "the extention".

[Les:] There are multiple changes in protocol behavior described - hence the 
term extensions is correct.

> 3) Editorial: Please, compare (Diff) the current draft with the published RFC
> 6822. You will find that various RFC Editor corrections got lost in this bis
> document. Some repeating examples of the lost corrections are "instance-
> specific", " topology (or topologies)" and "Type-Length-Value".

[Les:] Noted - thanx.

> My comments below are a result of a reverse-engineering exercise. Please,
> consider incorporating the suggested clarifications to improve the document
> readability. I might have misunderstood some of the parts; in such cases,
> please, provide an alternative text.
> 
> Abstract
> 1) Add clarification: "This document is not backwards compatible with RFC
> 6822."

[Les:] This statement is made explicitly in the Appendix - and I believe that 
is where it belongs for reasons I have previously stated.

> 2) Par. 2, replace the first two sentences with: "Configuration of multiple
> protocol instances within a router allow the isolation of resources associated
> with each instance. This document introduces a new mode of operation
> where the protocol instances are not a matter of configuration only, but are
> exposed through the new protocol extension to achieve the objective stated
> above."
> 3) Par. 3 uses both

Re: [Gen-art] Genart last call review of draft-ietf-isis-auto-conf-04

2017-04-10 Thread Les Ginsberg (ginsberg)

Bing/Robert/Alvaro -

Here is the existing text of the Security Section:

  "In general, the use of authentication is incompatible with auto-
   configuration as it requires some manual configuration.

   For wired deployment, the wired connection itself could be considered
   as an implicit authentication in that unwanted routers are usually
   not able to connect (i.e. there is some kind of physical security in
   place preventing the connection of rogue devices); for wireless
   deployment, the authentication could be achieved at the lower
   wireless link layer."

Proposed revision:

"In the absence of cryptographic authentication it is possible for an attacker 
to inject  a PDU falsely indicating
 there is a duplicate system-id. This may trigger automatic restart of the 
protocol using the duplicate-id
resolution procedures defined in this document. 

Note that the use of authentication is incompatible with auto-
configuration as it requires some manual configuration.

   For wired deployment, the wired connection itself could be considered
   as an implicit authentication in that unwanted routers are usually
   not able to connect (i.e. there is some kind of physical security in
   place preventing the connection of rogue devices); for wireless
   deployment, the authentication could be achieved at the lower
   wireless link layer."

???

   Les

> -Original Message-
> From: Liubing (Leo) [mailto:leo.liub...@huawei.com]
> Sent: Monday, April 10, 2017 3:07 AM
> To: Les Ginsberg (ginsberg); Alvaro Retana (aretana); Robert Sparks; gen-
> a...@ietf.org
> Cc: draft-ietf-isis-auto-conf@ietf.org; i...@ietf.org; isis...@ietf.org
> Subject: RE: Genart last call review of draft-ietf-isis-auto-conf-04
> 
> Hi Rober, Alvaro, and Les,
> 
> In general, the use of authentication is incompatible with auto-
>configuration as it requires some manual configuration.
> 
> > -Original Message-
> > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> > Sent: Saturday, April 08, 2017 6:44 AM
> > To: Alvaro Retana (aretana); Robert Sparks; gen-art@ietf.org
> > Cc: draft-ietf-isis-auto-conf@ietf.org; i...@ietf.org;
> > isis...@ietf.org
> > Subject: RE: Genart last call review of draft-ietf-isis-auto-conf-04
> >
> > Alvaro -
> >
> > Not sure how long we should debate this as the text you are asking for
> > is modest - but one more attempt on my part - not so much to debate
> > whether to add text or not - but to come to a common understanding.
> >
> > > -Original Message-
> > > From: Alvaro Retana (aretana)
> > > Sent: Friday, April 07, 2017 2:45 PM
> > > To: Les Ginsberg (ginsberg); Robert Sparks; gen-art@ietf.org
> > > Cc: draft-ietf-isis-auto-conf@ietf.org; i...@ietf.org;
> > > isis...@ietf.org
> > > Subject: Re: Genart last call review of draft-ietf-isis-auto-conf-04
> > >
> > > On 4/7/17, 5:30 PM, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com>
> > wrote:
> > >
> > > Les:
> > >
> > > Hi!
> > >
> > > > System-id duplication is a problem for any deployment - not just
> > > > autoconfig deployments. And it will be disruptive in any network
> > > > until it is
> > > resolved.
> > > >
> > > > The only thing autoconfig has added is a way to resolve this w/o
> > > > manual intervention. This in no way increases the vulnerability
> > > > nor the disruption the attacker can produce. (Yes - I state that
> > > > quite
> > > intentionally).
> > >
> > > I don’t know about Robert, but that is part of the discussion I
> > > would like to see.
> > >
> > > Yes, duplicate system-ids have always been a potential problem, but
> > > this document introduces a new de-duplication mechanism that results
> > > not just in unsync’d databases, but in restarting adjacencies – so
> > > at least the manifestation of the problem is different.
> > >
> > [Les:] The "problem" exists as long as the duplicate system-ids exist.
> > The recovery mechanism does not introduce new problems - it actually
> > acts to minimize the duration of the problem. One could argue (and I
> > am NOT doing
> > so) that automated resolution could be a benefit in all deployments. I
> > think the issue in non-autoconfig deployments is that since systems
> > have been manually provisioned we cannot assume that network
> operators
> > want us to automatically change the config on one of their boxes.
> > Though, who knows - maybe we will get asked to use this extension
> &g

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-isis-mi-bis-02

2017-04-08 Thread Les Ginsberg (ginsberg)

Orit -

Thanx for the review.
Responses inline.

> -Original Message-
> From: Orit Levin [mailto:or...@microsoft.com]
> Sent: Thursday, April 06, 2017 8:27 PM
> To: gen-art@ietf.org
> Cc: i...@ietf.org; draft-ietf-isis-mi-bis@tools.ietf.org
> Subject: Gen-ART Last Call review of draft-ietf-isis-mi-bis-02
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-isis-mi-bis-02
> Reviewer: Orit Levin
> Review Date: 2017-04-06
> IETF LC End Date: 2017-04-07
> IESG Telechat date: 2017-04-13
> 
> Summary: This draft is "ready with issues" for publication.
> 
> Major issues: None.
> 
> Minor issues:
> 
> 1. Add text explaining the reason (or reasons) for replacing the original RFC
> 6822 from 2012.
> Reason: It is a "bis" draft and there is no mention about it in the text.

[Les:] Note that the latest revision of the draft correctly identifies the 
draft as obsoleting RFC 6822. Previous versions had incorrectly identified this 
as an update to RFC 6822.
This is then the new Standard for the IS-IS MI support.

There are two classes of future readers of this document:

a)Readers who are unfamiliar with RFC 6822. For them what changed between RFC 
6822 and this document is irrelevant. 

b)Readers who are familiar with RFC 6822. For them it is useful to know what 
changed - which is described in Appendix A.

In order not to distract readers of type "a" - as well as to provide an 
"uninterrupted" description of the normative behavior I believe placement of 
the change description in an Appendix improves the readability of the document.

Does this make sense to you?

> 2. In Abstract, state clearly that this standard introduces the support for
> instances vs. other already existing concepts also listed in the Abstract 
> (i.e.,
> circuits, adjacencies,  topologies, etc.).

[Les:] The Abstract currently says:

"This draft describes a mechanism that allows a single router to share
   one or more circuits among multiple Intermediate System To
   Intermediate System (IS-IS) routing protocol instances."

Previous to this extension, a router could have multiple instances of the IS-IS 
protocol, but multiple instance could not be run over the same interface. 
So we are not introducing "instances", but we are introducing the ability to 
enable multiple instances on the same interface.

> Reason: The wording is not clear about what is the new feature vs. what are
> the new benefits vs. what was the original baseline 

>3. Throughout the
> document, use "standard instance" instead of "IID = 0" or "IID #0".
> Reason: Expressions "standard instance", "IID = 0" and "IID #0" are used
> interchangeably throughout the document. It seems that they all refer to the
> same thing - the implementation of the original protocol without the concept
> of instances. Please, correct me if I am wrong.

[Les:]  I don't think this is possible without seriously compromising the 
document. For example:

Section 2.1

" IID #0 is reserved for the standard instance supported by legacy
   systems. "

Changing this to  " Standard instance is reserved for the standard instance ..."

Is clearly nonsensical.

Later in Section 2.1

"When the IID = 0, the list of supported ITIDs MUST NOT be present."

What is being discussed here is what is the correct behavior when an MI-capable 
router sends a PDU associated IID #0 and includes the new IID TLV. 
Replacing this with "When the standard instance..." loses the important point 
that the value of the IID in the IID TLV in this case is "0".

Hope this helps clarify things.

> 4. In section 2 par 3, change "support" and "operates" to "MUST support" to
> use requirements language.

[Les:] I am on the fence as regards this change. Section 2 is an introduction 
to the following sub-sections - which define the normative behavior. But the 
introduction itself is not defining normative behavior - it is providing a 
context in which the protocol extensions defined in the following sub-sections 
can be understood. 

I am more inclined to change the "MAY" used later in the same paragraph you 
mention to "may" so it is consistent with the rest of this section.

???


> 5. In section 2 par 2, change "may" to either "can" or "MAY" to clarify the
> intent.

[Les:] Did you mean Section 2.1 para 2?
If so I agree to the change.

> 6. In section 2.1 par 3, clarify whether IID #0 is ever being used on the 
> wire.

[Les:] There are numerous places in the document where the legal use of IID  #0 
is discussed. I do not understand how a reader would conclude that IID #0 is 
never sent on the wire.

> Explain the concept of the "standard interface" (see previous comment)

[Les:] There is no mention of

Re: [Gen-art] Genart last call review of draft-ietf-isis-auto-conf-04

2017-04-07 Thread Les Ginsberg (ginsberg)

Alvaro -

Not sure how long we should debate this as the text you are asking for is 
modest - but one more attempt on my part - not so much to debate whether to add 
text or not - but to come to a common understanding.

> -Original Message-
> From: Alvaro Retana (aretana)
> Sent: Friday, April 07, 2017 2:45 PM
> To: Les Ginsberg (ginsberg); Robert Sparks; gen-art@ietf.org
> Cc: draft-ietf-isis-auto-conf@ietf.org; i...@ietf.org; isis...@ietf.org
> Subject: Re: Genart last call review of draft-ietf-isis-auto-conf-04
> 
> On 4/7/17, 5:30 PM, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> wrote:
> 
> Les:
> 
> Hi!
> 
> > System-id duplication is a problem for any deployment - not just
> > autoconfig deployments. And it will be disruptive in any network until it is
> resolved.
> >
> > The only thing autoconfig has added is a way to resolve this w/o
> > manual intervention. This in no way increases the vulnerability nor
> > the disruption the attacker can produce. (Yes - I state that quite
> intentionally).
> 
> I don’t know about Robert, but that is part of the discussion I would like to
> see.
> 
> Yes, duplicate system-ids have always been a potential problem, but this
> document introduces a new de-duplication mechanism that results not just
> in unsync’d databases, but in restarting adjacencies – so at least the
> manifestation of the problem is different.
> 
[Les:] The "problem" exists as long as the duplicate system-ids exist. The 
recovery mechanism does not introduce new problems - it actually acts to 
minimize the duration of the problem. One could argue (and I am NOT doing so) 
that automated resolution could be a benefit in all deployments. I think the 
issue in non-autoconfig deployments is that since systems have been manually 
provisioned we cannot assume that network operators want us to automatically 
change the config on one of their boxes. Though, who knows - maybe we will get 
asked to use this extension outside of autoconfig deployments. 

It is necessary to have such a mechanism in autoconfig deployments since there 
is - by default - no manual intervention. But to characterize this as adding 
risk is incorrect IMO.

  Les


> > So you are asking us to repeat a discussion which has already been
> > held in the context of RFC 5304 and RFC 5310.
> >
> > It would be more appropriate to add the normal reference to RFC
> > 5304/5310 in the Security section than what you propose.
> 
> I don’t think it hurts to add a reference to those RFCs, but they are both
> about adding authentication – the problem in this document is exacerbated
> by the fact that there’s no authentication by default.
> 
> The lower layer authentication mechanisms are quite weak, specially
> knowing that, if in a home environment, for example, it may be relatively
> easy to connect to the WiFi network.
> 
> Alvaro.
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-isis-auto-conf-04

2017-04-07 Thread Les Ginsberg (ginsberg)

Robert -

> -Original Message-
> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> Sent: Friday, April 07, 2017 2:18 PM
> To: Les Ginsberg (ginsberg); gen-art@ietf.org
> Cc: draft-ietf-isis-auto-conf@ietf.org; i...@ietf.org; isis...@ietf.org
> Subject: Re: Genart last call review of draft-ietf-isis-auto-conf-04
> 
> 
> 
> On 4/7/17 3:55 PM, Les Ginsberg (ginsberg) wrote:
> > Robert -
> >
> > Thanx for the review.
> > Reply inline.
> >
> >> -Original Message-
> >> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> >> Sent: Friday, April 07, 2017 1:25 PM
> >> To: gen-art@ietf.org
> >> Cc: draft-ietf-isis-auto-conf@ietf.org; i...@ietf.org;
> >> isis...@ietf.org
> >> Subject: Genart last call review of draft-ietf-isis-auto-conf-04
> >>
> >> Reviewer: Robert Sparks
> >> Review result: Ready with Issues
> >>
> >> I am the assigned Gen-ART reviewer for this draft. The General Area
> >> Review Team (Gen-ART) reviews all IETF documents being processed by
> >> the IESG for the IETF Chair.  Please treat these comments just like
> >> any other last call comments.
> >>
> >> For more information, please see the FAQ at
> >>
> >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> >>
> >> Document: draft-ietf-isis-auto-conf-04
> >> Reviewer: Robert Sparks
> >> Review Date: 2017-04-07
> >> IETF LC End Date: 2017-04-10
> >> IESG Telechat date: 2017-04-13
> >>
> >> Summary: Ready for publication as Proposed Standard, but with one
> >> possible thing to add to the security consideration section
> >>
> >> This document is clear and seems straightforward to implement.
> >>
> >> I think, however, there is an attack possibility you should call out
> >> in the security considerations section. As home routers are used as
> >> examples of elements that might use this protocol, consider the case
> >> of a malicious party wanting to deny service in that home.
> >> A suborned device in the home could watch for the protocol, and
> >> present a crafted packet to force the home router(s) to re-start the
> >> autoconfiguration protocol continually (by claiming to be a duplicate
> >> and being careful to make it the routers job to restart).
> >> Having the md5 password configured would mitigate this attack.
> > [Les:] The draft says two things which are relevant:
> >
> > 3.5.1.  Authentication TLV
> >
> > It is RECOMMENDED that IS-IS routers supporting this specification
> > offer an option to explicitly configure a single password for HMAC-
> > MD5 authentication as specified in[RFC5304].
> >
> > 4.  Security Considerations
> >
> > In general, the use of authentication is incompatible with auto-
> > configuration as it requires some manual configuration.
> >
> > It seems to me that these sections adequately cover your point.
> > ???
> They provide the mitigation. They do not call out the risk.
> 
> The current security considerations section says for wired networks, plugging
> into the wire is protection enough, and you don't need to use the
> authentication tlv.  I don't think that's true given the possibility of this 
> attack.
> I suggest discussing the attack in the security considerations section and
> pointing to using the Authentication TLV with it's onerous bit of manual
> configuration as the mitigation.
> 
[Les:] If you insist I am OK with this - but frankly you are twisting my arm. 
:-)
System-id duplication is a problem for any deployment - not just autoconfig 
deployments. And it will be disruptive in any network until it is resolved.
The only thing autoconfig has added is a way to resolve this w/o manual 
intervention. This in no way increases the vulnerability nor the disruption the 
attacker can produce. (Yes - I state that quite intentionally).
So you are asking us to repeat a discussion which has already been held in the 
context of RFC 5304 and RFC 5310.

It would be more appropriate to add the normal reference to RFC 5304/5310 in 
the Security section than what you propose.

   Les

> >
> >  Les
> >

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-isis-auto-conf-04

2017-04-07 Thread Les Ginsberg (ginsberg)

Robert -

Thanx for the review.
Reply inline.

> -Original Message-
> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> Sent: Friday, April 07, 2017 1:25 PM
> To: gen-art@ietf.org
> Cc: draft-ietf-isis-auto-conf@ietf.org; i...@ietf.org; isis...@ietf.org
> Subject: Genart last call review of draft-ietf-isis-auto-conf-04
> 
> Reviewer: Robert Sparks
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-isis-auto-conf-04
> Reviewer: Robert Sparks
> Review Date: 2017-04-07
> IETF LC End Date: 2017-04-10
> IESG Telechat date: 2017-04-13
> 
> Summary: Ready for publication as Proposed Standard, but with one possible
> thing to add to the security consideration section
> 
> This document is clear and seems straightforward to implement.
> 
> I think, however, there is an attack possibility you should call out in the
> security considerations section. As home routers are used as examples of
> elements that might use this protocol, consider the case of a malicious party
> wanting to deny service in that home.
> A suborned device in the home could watch for the protocol, and present a
> crafted packet to force the home router(s) to re-start the autoconfiguration
> protocol continually (by claiming to be a duplicate and being careful to make
> it the routers job to restart).
> Having the md5 password configured would mitigate this attack.

[Les:] The draft says two things which are relevant:

3.5.1.  Authentication TLV

   It is RECOMMENDED that IS-IS routers supporting this specification
   offer an option to explicitly configure a single password for HMAC-
   MD5 authentication as specified in[RFC5304].

4.  Security Considerations

   In general, the use of authentication is incompatible with auto-
   configuration as it requires some manual configuration.

It seems to me that these sections adequately cover your point.
???

Les

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

2017-01-19 Thread Les Ginsberg (ginsberg)

John -

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 2:04 PM
To: Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander Vainshtein; Greg 
Mirsky
Cc: Robert Sparks; m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

Shall we go with a sub-TLV of TLV 22
[Les:] If that is the direction the WG wants to go I am OK with it - but I do 
think this proposal should be sent to the IS-IS WG for comment as well.

and promise to never ever to do this again?

[Les:] LOL...sure!

   Les

Btw, I am extremely sorry that we didn't engage with the IS-IS community and I 
don't know why we didn't.  As I said in an earlier email, we worked pretty 
extensively with Acee on the OSPF aspects and with Lou Berger on the RSVP-TE 
aspects and received a lot of useful feedback from both of them.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 4:55 PM
To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>; Acee Lindem 
(acee) <a...@cisco.com<mailto:a...@cisco.com>>; Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; 
Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: Robert Sparks <rjspa...@nostrum.com<mailto:rjspa...@nostrum.com>>; 
m...@ietf.org<mailto:m...@ietf.org>; gen-art@ietf.org<mailto:gen-art@ietf.org>; 
draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>; 
isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; Abhay Roy (akr) 
<a...@cisco.com<mailto:a...@cisco.com>>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 1:19 PM
To: Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander Vainshtein; Greg 
Mirsky
Cc: Robert Sparks; m...@ietf.org<mailto:m...@ietf.org>; 
gen-art@ietf.org<mailto:gen-art@ietf.org>; 
draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>; 
isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

I understand and I have made the same argument in other contexts and with 
similar results ("... and your point is?").
[Les:] Nice to know I am not completely alone.:-)

It would be good if the authors/WG at least considered a non-IGP approach.
However, if the IGP approach is to be taken, the GENINFO definition currently 
in the draft is unacceptable for reasons I have previously given. So this 
should be reworked - probably to use a sub-TLV of TLV 22 et al.
The other alternative would be to define a GENINFO application that could 
support advertising many interface attributes - I don't think anyone wants to 
go in that direction - certainly not me.

   Les

However, as I indicated in my previous email, RTM would be used as part of the 
network infrastructure as a way to provide time synchronization between the 
nodes in the network, so I would consider it similar to the S-BFDs that Uma and 
you were discussing.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 4:09 PM
To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>; Acee Lindem 
(acee) <a...@cisco.com<mailto:a...@cisco.com>>; Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; 
Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: Robert Sparks <rjspa...@nostrum.com<mailto:rjspa...@nostrum.com>>; 
m...@ietf.org<mailto:m...@ietf.org>; gen-art@ietf.org<mailto:gen-art@ietf.org>; 
draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>; 
isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; Abhay Roy (akr) 
<a...@cisco.com<mailto:a...@cisco.com>>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

The text you have excerpted below was trying to say two things:

1)If you want to advertise this in the IGPs the OSPF style proposal is much 
better from an implementation standpoint than the IS-IS GENAPP proposal

2)There is a larger question as to whether we should be using the IGPs for this 
at all

Statement #1 should not be interpreted to imply that I am advocating using the 
IGPs. :)

That said, we "ALWAYS" end up choosing using the IGPs to do this sort of thing 
- not because it is the "RIGHT" thi

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

2017-01-19 Thread Les Ginsberg (ginsberg)

Eric -

From: Eric Gray [mailto:eric.g...@ericsson.com]
Sent: Thursday, January 19, 2017 12:32 PM
To: Les Ginsberg (ginsberg); Uma Chunduri; John E Drake; Acee Lindem (acee); 
Alexander Vainshtein; Greg Mirsky
Cc: m...@ietf.org; i...@ietf.org; isis-cha...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; Abhay Roy (akr); Robert Sparks
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

It's nice to have a good discussion about technical aspects of 
a proposed standard, even late in the game.
[Les:] There is context you may not have.
"I" only became aware of this because - as one of the Designated Experts for 
IS-IS Registries - I was asked by IANA to approve the allocation of codepoints 
for the GENINFO proposal in the draft.
It would have been better had the IGP WGs been apprised of this draft and asked 
for feedback earlier in the process - but AFAIK that did not happen. This is a 
bit strange given that the draft authors include folks with long experience in 
MPLS/IGP interworking - but I am not trying to place blame. For whatever reason 
this did not happen.

I do appreciate how late in the game this discussion is - but as I do not 
personally follow MPLS drafts in general I was unaware of this draft until the 
IANA request was sent.
Too late to fix this now - but something to be considered in the future when 
there are IGP extensions involved in MPLS Drafts.

But I have some difficulty is seeing how this usage is "clearly 
not TE information."
[Les:] The packet timing capability which you are asking IGPs to advertise is a 
generic capability which could be used for many purposes. The fact that you are 
applying it to MPLS LSPs does not make the capability an MPLS/TE related 
capability.
   Les

This information should allow the head-end of an LSP to select a path based on 
desirable interface capabilities.  For the purposes of accurate time 
information, the best path may not also be the shortest path.  Is this not 
exactly what traffic engineering is about?

As far as extending this argument to the ability to advertise additional link 
capabilities, I can easily imagine scenarios where that would make sense.  But 
nobody is suggesting that every LSR (or router for that matter) either must 
have this capability for every scenario, or that - having the capability - it 
would need to be turned on.

If there is an application or use-case out there that might require advertising 
every conceivable interface capability, then vendors will want to take a look 
at the size of the opportunity represented by that and make a decision as to 
whether or not to support this.

--
Eric

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, January 19, 2017 3:11 PM
To: Uma Chunduri <uma.chund...@huawei.com<mailto:uma.chund...@huawei.com>>; 
John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>; Acee Lindem 
(acee) <a...@cisco.com<mailto:a...@cisco.com>>; Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; 
Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: m...@ietf.org<mailto:m...@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; 
gen-art@ietf.org<mailto:gen-art@ietf.org>; 
draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>;
 Abhay Roy (akr) <a...@cisco.com<mailto:a...@cisco.com>>; Robert Sparks 
<rjspa...@nostrum.com<mailto:rjspa...@nostrum.com>>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Uma -

I readily admit S-BFD descriptors are - strictly speaking - a violation of the 
"non-routing info" policy - this was publicly acknowledged at the time the 
drafts were written. The exception was justified on the basis that:

  o IGPs are BFD clients
  o The S-BFD discriminator information is unique and extremely modest in size

What we have here is a proposal to start advertising non-routing related 
interface attribute information. There is nothing special or unique about RTM - 
it is simply one of many interface attributes which are generic in nature. 
Having agreed to advertise RTM in the IGPs, how would you then determine what 
other interface attributes should/should not be advertised by the IGPs? Take a 
look at your favorite vendors box and see how many interface attributes can be 
configured.
It is also concerning that - when using the IGPs - we flood information which 
must be stored on every node even though the use case for it is limited to a 
much smaller subset.

I think we can and should be smarter in this regard - and given the extensive 
work being done to enhance manageability I would like to see us benefit from 
this.

The authors of draft-ietf-mpls-resid

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

2017-01-19 Thread Les Ginsberg (ginsberg)

John -

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 1:19 PM
To: Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander Vainshtein; Greg 
Mirsky
Cc: Robert Sparks; m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

I understand and I have made the same argument in other contexts and with 
similar results ("... and your point is?").
[Les:] Nice to know I am not completely alone.:-)

It would be good if the authors/WG at least considered a non-IGP approach.
However, if the IGP approach is to be taken, the GENINFO definition currently 
in the draft is unacceptable for reasons I have previously given. So this 
should be reworked - probably to use a sub-TLV of TLV 22 et al.
The other alternative would be to define a GENINFO application that could 
support advertising many interface attributes - I don't think anyone wants to 
go in that direction - certainly not me.

   Les

However, as I indicated in my previous email, RTM would be used as part of the 
network infrastructure as a way to provide time synchronization between the 
nodes in the network, so I would consider it similar to the S-BFDs that Uma and 
you were discussing.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 4:09 PM
To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>; Acee Lindem 
(acee) <a...@cisco.com<mailto:a...@cisco.com>>; Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; 
Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: Robert Sparks <rjspa...@nostrum.com<mailto:rjspa...@nostrum.com>>; 
m...@ietf.org<mailto:m...@ietf.org>; gen-art@ietf.org<mailto:gen-art@ietf.org>; 
draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>; 
isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; Abhay Roy (akr) 
<a...@cisco.com<mailto:a...@cisco.com>>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

The text you have excerpted below was trying to say two things:

1)If you want to advertise this in the IGPs the OSPF style proposal is much 
better from an implementation standpoint than the IS-IS GENAPP proposal

2)There is a larger question as to whether we should be using the IGPs for this 
at all

Statement #1 should not be interpreted to imply that I am advocating using the 
IGPs. :)

That said, we "ALWAYS" end up choosing using the IGPs to do this sort of thing 
- not because it is the "RIGHT" thing to do architecturally - but because it is 
so convenient.

I am just asking for folks to pause and think about this a bit more from an 
architectural perspective.

   Les

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 12:20 PM
To: Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander Vainshtein; Greg 
Mirsky
Cc: Robert Sparks; m...@ietf.org<mailto:m...@ietf.org>; 
gen-art@ietf.org<mailto:gen-art@ietf.org>; 
draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>; 
isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

Comments inline.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 12:25 PM
To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>; Acee Lindem 
(acee) <a...@cisco.com<mailto:a...@cisco.com>>; Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; 
Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: Robert Sparks <rjspa...@nostrum.com<mailto:rjspa...@nostrum.com>>; 
m...@ietf.org<mailto:m...@ietf.org>; gen-art@ietf.org<mailto:gen-art@ietf.org>; 
draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>; 
isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; Abhay Roy (akr) 
<a...@cisco.com<mailto:a...@cisco.com>>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

For me, this raises the age-old question of when it is/is not appropriate to 
use IGPs for flooding information.

This is clearly not TE information - you just happen to be using this in 
conjunction with MPLS - but it is a generic capability. I do not see the IGPs 
as the appropriate mechanism to flood generic interface capabilities. It also, 
as Acee has po

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

2017-01-19 Thread Les Ginsberg (ginsberg)

John -

The text you have excerpted below was trying to say two things:

1)If you want to advertise this in the IGPs the OSPF style proposal is much 
better from an implementation standpoint than the IS-IS GENAPP proposal

2)There is a larger question as to whether we should be using the IGPs for this 
at all

Statement #1 should not be interpreted to imply that I am advocating using the 
IGPs. :)

That said, we "ALWAYS" end up choosing using the IGPs to do this sort of thing 
- not because it is the "RIGHT" thing to do architecturally - but because it is 
so convenient.

I am just asking for folks to pause and think about this a bit more from an 
architectural perspective.

   Les


From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 12:20 PM
To: Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander Vainshtein; Greg 
Mirsky
Cc: Robert Sparks; m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

Comments inline.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 12:25 PM
To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>; Acee Lindem 
(acee) <a...@cisco.com<mailto:a...@cisco.com>>; Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; 
Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: Robert Sparks <rjspa...@nostrum.com<mailto:rjspa...@nostrum.com>>; 
m...@ietf.org<mailto:m...@ietf.org>; gen-art@ietf.org<mailto:gen-art@ietf.org>; 
draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>; 
isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; Abhay Roy (akr) 
<a...@cisco.com<mailto:a...@cisco.com>>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

For me, this raises the age-old question of when it is/is not appropriate to 
use IGPs for flooding information.

This is clearly not TE information - you just happen to be using this in 
conjunction with MPLS - but it is a generic capability. I do not see the IGPs 
as the appropriate mechanism to flood generic interface capabilities. It also, 
as Acee has pointed out, results in flooding information to all nodes in the 
domain when only a few care about it.

[JD]  RTM support as defined in the draft would be used to provide extremely 
accurate time synchronization in an MPLS network so I would suggest that all 
nodes in such a network would be using it and hence that it does belong in the 
IGP.  As an aside, advertising it in the IGP facilitates incremental or partial 
deployment.  Your yesterday's email supports this:

"It would seem more appropriate to treat RTM information either as:

   o an extension to link attribute information already advertised by the IGPs 
(as has been suggested for OSPF) - which would suggest in IS-IS a sub-TLV of 
TLV 22(et al)

or


*As an interface attribute independent of routing protocols which could 
be retrieved utilizing network management tools"

   Les

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 8:54 AM
To: Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les Ginsberg 
(ginsberg)
Cc: Robert Sparks; m...@ietf.org<mailto:m...@ietf.org>; 
gen-art@ietf.org<mailto:gen-art@ietf.org>; 
draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>; 
isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

Relying on an omniscient controller is a non-starter in general and in 
particular because the protocol by which it would learn each node's RTM 
capabilities and distribute them to the other nodes is undefined.  Further, one 
of the ways by which an omniscient controller learns a node's capabilities is 
by snooping the link/state database.

Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:47 AM
To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>; Alexander 
Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; 
Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>; Les Ginsberg 
(ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Cc: Robert Sparks <rjspa...@nostrum.com<mailto:rjspa...@nostrum.com>>; 
m...@ietf.org<mailto:m...@ietf.org>; gen-art@ietf.org<mailto:gen-art@ietf.org>; 
draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-res

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

2017-01-19 Thread Les Ginsberg (ginsberg)

Uma -

I readily admit S-BFD descriptors are - strictly speaking - a violation of the 
"non-routing info" policy - this was publicly acknowledged at the time the 
drafts were written. The exception was justified on the basis that:

  o IGPs are BFD clients
  o The S-BFD discriminator information is unique and extremely modest in size

What we have here is a proposal to start advertising non-routing related 
interface attribute information. There is nothing special or unique about RTM - 
it is simply one of many interface attributes which are generic in nature. 
Having agreed to advertise RTM in the IGPs, how would you then determine what 
other interface attributes should/should not be advertised by the IGPs? Take a 
look at your favorite vendors box and see how many interface attributes can be 
configured.

It is also concerning that - when using the IGPs - we flood information which 
must be stored on every node even though the use case for it is limited to a 
much smaller subset.

I think we can and should be smarter in this regard - and given the extensive 
work being done to enhance manageability I would like to see us benefit from 
this.

The authors of draft-ietf-mpls-residence-time clearly had some thoughts in this 
regard - which is why they proposed to use RFC 6823 (GENAPP) in IS-IS to 
advertise the information -but the proposal in the draft is flawed in this 
regard. If we were to head in the "application" direction I would propose a 
much more generic "application" which is capable of advertising many interface 
attributes. However this goes back to my original concern - whether we want to 
use IGPs to flood interface attribute information unrelated to routing even if 
it is segregated under an application. Remember that RFC 6823 stipulates that a 
separate instance of the protocol (a la RFC 6822) be used for such cases.

   Les


From: Uma Chunduri [mailto:uma.chund...@huawei.com]
Sent: Thursday, January 19, 2017 11:41 AM
To: Les Ginsberg (ginsberg); John E Drake; Acee Lindem (acee); Alexander 
Vainshtein; Greg Mirsky
Cc: Abhay Roy (akr); m...@ietf.org; isis-cha...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; Robert Sparks; i...@ietf.org
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

I support advertising this in IGP.


>This is clearly not TE information -..
>I do not see the IGPs as the appropriate mechanism to flood generic interface 
>capabilities

We have instances where both the above are not met and we flooded information.
https://tools.ietf.org/html/rfc7883 (Les, you co-authored the same!!)
https://tools.ietf.org/html/rfc7880

--
Uma C.

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, January 19, 2017 9:25 AM
To: John E Drake <jdr...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>; 
Alexander Vainshtein <alexander.vainsht...@ecitele.com>; Greg Mirsky 
<gregimir...@gmail.com>
Cc: Abhay Roy (akr) <a...@cisco.com>; m...@ietf.org; isis-cha...@ietf.org; 
gen-art@ietf.org; draft-ietf-mpls-residence-time@ietf.org; Robert Sparks 
<rjspa...@nostrum.com>; i...@ietf.org
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

For me, this raises the age-old question of when it is/is not appropriate to 
use IGPs for flooding information.

This is clearly not TE information - you just happen to be using this in 
conjunction with MPLS - but it is a generic capability. I do not see the IGPs 
as the appropriate mechanism to flood generic interface capabilities. It also, 
as Acee has pointed out, results in flooding information to all nodes in the 
domain when only a few care about it.

   Les

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 8:54 AM
To: Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les Ginsberg 
(ginsberg)
Cc: Robert Sparks; m...@ietf.org<mailto:m...@ietf.org>; 
gen-art@ietf.org<mailto:gen-art@ietf.org>; 
draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>; 
isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

Relying on an omniscient controller is a non-starter in general and in 
particular because the protocol by which it would learn each node's RTM 
capabilities and distribute them to the other nodes is undefined.  Further, one 
of the ways by which an omniscient controller learns a node's capabilities is 
by snooping the link/state database.

Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:47 AM
To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>; Alexander 
Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; 
Greg Mir

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

2017-01-19 Thread Les Ginsberg (ginsberg)

John -

For me, this raises the age-old question of when it is/is not appropriate to 
use IGPs for flooding information.

This is clearly not TE information - you just happen to be using this in 
conjunction with MPLS - but it is a generic capability. I do not see the IGPs 
as the appropriate mechanism to flood generic interface capabilities. It also, 
as Acee has pointed out, results in flooding information to all nodes in the 
domain when only a few care about it.

   Les

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 8:54 AM
To: Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les Ginsberg 
(ginsberg)
Cc: Robert Sparks; m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

Relying on an omniscient controller is a non-starter in general and in 
particular because the protocol by which it would learn each node's RTM 
capabilities and distribute them to the other nodes is undefined.  Further, one 
of the ways by which an omniscient controller learns a node's capabilities is 
by snooping the link/state database.

Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:47 AM
To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>; Alexander 
Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; 
Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>; Les Ginsberg 
(ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Cc: Robert Sparks <rjspa...@nostrum.com<mailto:rjspa...@nostrum.com>>; 
m...@ietf.org<mailto:m...@ietf.org>; gen-art@ietf.org<mailto:gen-art@ietf.org>; 
draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>; 
isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; Abhay Roy (akr) 
<a...@cisco.com<mailto:a...@cisco.com>>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi John,

From: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>
Date: Thursday, January 19, 2017 at 10:43 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>, 
Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, "Les 
Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Cc: Robert Sparks <rjspa...@nostrum.com<mailto:rjspa...@nostrum.com>>, 
"m...@ietf.org<mailto:m...@ietf.org>" <m...@ietf.org<mailto:m...@ietf.org>>, 
"gen-art@ietf.org<mailto:gen-art@ietf.org>" 
<gen-art@ietf.org<mailto:gen-art@ietf.org>>, 
"draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>"
 
<draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>>,
 "i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
"isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>" 
<isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>>, "Abhay Roy (akr)" 
<a...@cisco.com<mailto:a...@cisco.com>>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

We discussed all of this with you over a year ago and used your guidance in 
adding the indication of RTM capability to OSPF.

I'm sorry but I focused mainly on the OSPF protocol aspects then and didn't 
question the use case. This question came up in the IS-IS WG discussions.

Thanks,
Acee


Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:38 AM
To: Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; 
Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>; Les Ginsberg 
(ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Cc: Robert Sparks <rjspa...@nostrum.com<mailto:rjspa...@nostrum.com>>; 
m...@ietf.org<mailto:m...@ietf.org>; gen-art@ietf.org<mailto:gen-art@ietf.org>; 
draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>; 
isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; Abhay Roy (akr) 
<a...@cisco.com<mailto:a...@cisco.com>>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

I guess what we were trying to envision the use case and whether it makes sense 
for all the nodes in the IGP routing domain to have this information. Woul

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

2017-01-19 Thread Les Ginsberg (ginsberg)

Greg –

I am having trouble understanding your response.
The question we are raising is whether we should extend the IGPs to support 
advertising RTM capability – an alternative being to retrieve the capability 
via network management.

Saying that the IGP functionality is optional and/or wouldn’t always be 
advertised doesn’t really answer the question of whether we should or should 
not define the IGP extensions.

Could you respond more directly to this point?

   Les


From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Thursday, January 19, 2017 7:44 AM
To: Acee Lindem (acee)
Cc: Robert Sparks; m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; Les Ginsberg 
(ginsberg); isis-cha...@ietf.org; Abhay Roy (akr)
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi Acee,
the draft defines optional functionality. If an operator has no use neither for 
PTP's Transparent Clock, nor RTM itself as performance metric, then RTM sub-TLV 
would not be included and thus it would not be flooded. Of course, it be right 
to reflect RTM capability through YANG data model, thus allowing SDN scenario 
you've described.

Regards,
Greg

On Wed, Jan 18, 2017 at 2:51 PM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:
Hi Greg,

Although it is a bit late, we’ve had some discussions amongst the IS-IS and 
OSPF chairs and are wondering whether the interface capability belongs in the 
IGPs. This will be flooded throughout the entire routing domain – is it really 
needed on every node or will it the RTM testing be initiated from an omniscient 
NMS client that would know the capabilities of each node or easily query them 
using YANG?

Thanks,
Acee

From: mpls <mpls-boun...@ietf.org<mailto:mpls-boun...@ietf.org>> on behalf of 
Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Date: Wednesday, January 18, 2017 at 1:25 PM
To: Robert Sparks <rjspa...@nostrum.com<mailto:rjspa...@nostrum.com>>
Cc: "m...@ietf.org<mailto:m...@ietf.org>" 
<m...@ietf.org<mailto:m...@ietf.org>>, 
"gen-art@ietf.org<mailto:gen-art@ietf.org>" 
<gen-art@ietf.org<mailto:gen-art@ietf.org>>, 
"draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>"
 
<draft-ietf-mpls-residence-time@ietf.org<mailto:draft-ietf-mpls-residence-time@ietf.org>>,
 "i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi Robert,
thank you for the most expedient review and comments. I'll make changes in 
Section 2 per your suggestion.

Regards,
Greg

On Wed, Jan 18, 2017 at 10:34 AM, Robert Sparks 
<rjspa...@nostrum.com<mailto:rjspa...@nostrum.com>> wrote:

The changes all look good.

I still think you should say something in the document about what "the time of 
packet arrival" and "transmission" means, and call out the point you made about 
being careful to not introduce apparent jitter by not making those measurements 
consistently. (The definitions you point to in your earlier mail from G.8013 
don't really help - they just say "time of packet arrival". Again, the first 
and last bit are likely to be several nanoseconds apart so I think it matters. 
Perhaps you're saying it doesn't matter as long as each node is consistent 
(there will be error in the residence time measurement, but it will be constant 
at each node, so the sum of errors will be constant, and the clocks will be ok?)

Please look at the new first paragraph of section 2 - there's a mix of "as 
case" and "in case" that should be made consistent. I suspect it would be 
easiest to simply say "referred to as using a one-step clock" and "referred to 
as using a two-step clock" or similar.

RjS

On 1/18/17 12:03 PM, Greg Mirsky wrote:
Hi Robert,
Sasha Vainshtein came with elegant idea to address disconnection between 
discussion of one-step and two-step modes that you've pointed out. We've moved 
Section 7 as sub-section into Section 2 now. Attached are updated diff and the 
proposed new version -13.

Regards,
Greg

On Wed, Jan 18, 2017 at 8:13 AM, Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote:
Hi Robert,
once again, thank you for your thorough review and the most detailed comments. 
I've prepared updated version and would greatly appreciate if you review the 
changes and let us know whether your comments been addressed. Attached are diff 
and the new version.

Regards,
Greg

On Wed, Jan 11, 2017 at 7:48 AM, Robert Sparks 
<rjspa...@nostrum.com<mailto:rjspa...@nostrum.com>> wrote:
Reviewer: Robert Sparks
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Tea

Re: [Gen-art] IETF Last Call Gen-Art review of draft-ietf-isis-rfc4971bis-01

2016-08-08 Thread Les Ginsberg (ginsberg)

Dale -

Attached please find an updated version and diffs from previous.
Please let me know if this adequately addresses your comments.

Les

> -Original Message-
> From: Dale R. Worley [mailto:wor...@ariadne.com]
> Sent: Monday, August 08, 2016 8:26 AM
> To: Les Ginsberg (ginsberg)
> Cc: gen-art@ietf.org; i...@ietf.org; draft-ietf-isis-rfc4971bis@ietf.org; 
> isis-
> w...@ietf.org
> Subject: Re: IETF Last Call Gen-Art review of draft-ietf-isis-rfc4971bis-01
> 
> "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> writes:
> > Thanx for your detailed review. I have elected to copy the WG on my
> > reply as you also sent a copy of your review to the WG.
> 
> I'm not sure if it is formally specified, but it seems to me that a Gen-Art
> review really should be copied to the WG.
> 
> > It therefore has to be considered whether making many of the changes
> > you suggest might unintentionally suggest a substantive change where
> > none is intended.
> 
> Of course, my comments are only a review.  Looking over them again, none
> seem to technically critical; the ones with technical content are improving 
> the
> explanations of features that people (seem to be) implementing correctly
> now.  So I don't see any reason to object to minimizing changes from RFC
> 4971.
> 
> > [Les:] You refer here to the extended TLVs defined in RFC 7356 (pretty
> > good find for someone who is not supposed to be an IS-IS expert :-) ).
> 
> I looked at the type codepoint registry, and there were values over 255
> (though unassigned), which was inconsistent with the text of draft-ietf-isis-
> rfc4971bis.  So it was just a matter of tracking down what defined the
> alternative format.
> 
> Dale

Networking Working Group L. Ginsberg
Internet-DraftS. Previdi
Intended status: Standards Track   Cisco Systems
Expires: February 9, 2017M. Chen
Huawei Technologies Co., Ltd
  August 8, 2016

  IS-IS Extensions for Advertising Router Info
   draft-ietf-isis-rfc4971bis-02.txt

Abstract

   This document defines a new optional Intermediate System to
   Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple
   sub-TLVs, which allows a router to announce its capabilities within
   an IS-IS level or the entire routing domain.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 9, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents

Ginsberg, et al.Expires February 9, 2017[Page 1]

Internet-Draft   isis-rfc4971bis August 2016

   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  IS-IS Router CAPABILITY TLV . . . . . . . . . . . . . . . . .   3
   3.  Elements of Procedure . . . . . . . . . . . . . . . . . . . .   4
   4.  Interoperability with Routers Not Supporting the Capability
   TLV . . . . . . . . . . . . . . . . . . . . . .

Re: [Gen-art] Gen-ART review of draft-ietf-isis-remaining-lifetime-02

2016-08-08 Thread Les Ginsberg (ginsberg)

Christer -

I will place a reference in the Introduction - something like:

"[ISO10589} defines the format of a Link State PDU (LSP) which includes a 
Remaining Lifetime field..."

Hope that will suffice.

   Les


From: Christer Holmberg [mailto:christer.holmb...@ericsson.com]
Sent: Monday, August 08, 2016 10:28 AM
To: Les Ginsberg (ginsberg); gen-art@ietf.org; 
draft-ietf-isis-remaining-lifetime@tools.ietf.org
Subject: RE: Gen-ART review of draft-ietf-isis-remaining-lifetime-02

Hi,

>Thanx for your review.
>
>ISO 10589 is the base specification for IS-IS and there is a reference to it 
>in the document.
>This is where you will find details about Link State PDUs.
>
>I would be reluctant to include any sort of summary description of an LSP in 
>this document out of fear that it might be seen as differing from the base 
>protocol specification.

I think it would be useful to place that reference also in the Abstract, and in 
the problem statement, before you start talking about the LSP.

You don't have to add an LSP description, simply a reference so that it is easy 
for me to know where to get more information - without having to look for the 
reference elsewhere in the document :)

Regards,

Christer


From: Christer Holmberg [mailto:christer.holmb...@ericsson.com]
Sent: Saturday, August 06, 2016 10:03 AM
To: gen-art@ietf.org<mailto:gen-art@ietf.org>; 
draft-ietf-isis-remaining-lifetime@tools.ietf.org<mailto:draft-ietf-isis-remaining-lifetime@tools.ietf.org>
Subject: RE: Gen-ART review of draft-ietf-isis-remaining-lifetime-02

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
Document:   draft-ietf-isis-remaining-lifetime-02
Reviewer: Christer Holmberg
Review Date:   6 August 2016
IETF LC End Date:15 August 2016
IETF Telechat Date:N/A

Summary:
The document is well written, and almost ready for publication as a standards 
track RFC, but I have a couple of editorial comments that I'd like the authors 
to address.
Major Issues:None
Minor Issues:None
Editorial Issues:
The Abstract says:
"Corruption of the Remainining Lifetime Field in a Link State PDU can go 
undetected.  In certain scenarios this may cause or exacerbate flooding storms. 
 It is also a possible denial of service attack vector.  This document defines 
a backwards compatible solution to this problem."
...and the first sentence of the Problem Statement says:
"Each Link State PDU (LSP) includes a Remaining Lifetime field."
I have no idea what a Link State PDU is, and there is no introduction to what 
the draft is all about. The text jumps direction into the work.
So, please add a reference to Link State PDU (LSP), and please give a little 
bit of introduction text what context/environment this is all about. I assume 
there is some core document which describes the context/environment where the 
Link State PDU is used?

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-isis-remaining-lifetime-02

2016-08-08 Thread Les Ginsberg (ginsberg)

Christer -

Thanx for your review.

ISO 10589 is the base specification for IS-IS and there is a reference to it in 
the document.
This is where you will find details about Link State PDUs.

I would be reluctant to include any sort of summary description of an LSP in 
this document out of fear that it might be seen as differing from the base 
protocol specification.

I hope this addresses your concerns.

   Les


From: Christer Holmberg [mailto:christer.holmb...@ericsson.com]
Sent: Saturday, August 06, 2016 10:03 AM
To: gen-art@ietf.org; draft-ietf-isis-remaining-lifetime@tools.ietf.org
Subject: RE: Gen-ART review of draft-ietf-isis-remaining-lifetime-02

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at 
Document:   draft-ietf-isis-remaining-lifetime-02
Reviewer: Christer Holmberg
Review Date:   6 August 2016
IETF LC End Date:15 August 2016
IETF Telechat Date:N/A

Summary:
The document is well written, and almost ready for publication as a standards 
track RFC, but I have a couple of editorial comments that I'd like the authors 
to address.
Major Issues:None
Minor Issues:None
Editorial Issues:
The Abstract says:
"Corruption of the Remainining Lifetime Field in a Link State PDU can go 
undetected.  In certain scenarios this may cause or exacerbate flooding storms. 
 It is also a possible denial of service attack vector.  This document defines 
a backwards compatible solution to this problem."
...and the first sentence of the Problem Statement says:
"Each Link State PDU (LSP) includes a Remaining Lifetime field."
I have no idea what a Link State PDU is, and there is no introduction to what 
the draft is all about. The text jumps direction into the work.
So, please add a reference to Link State PDU (LSP), and please give a little 
bit of introduction text what context/environment this is all about. I assume 
there is some core document which describes the context/environment where the 
Link State PDU is used?

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] IETF Last Call Gen-Art review of draft-ietf-isis-rfc4971bis-01

2016-08-08 Thread Les Ginsberg (ginsberg)

Dale -

Thanx for your detailed review. I have elected to copy the WG on my reply as 
you also sent a copy of your review to the WG.

Overall, while I either agree with or have no objection to many of your 
comments, most of them could be applied to RFC 4971 itself. When generating the 
bis version we elected NOT to modify the original RFC except where it was 
necessary to address the issue of an IPv6-only router. It certainly can be 
argued that your suggestions improve the consistency and readability of the 
document, but they also make it deviate from RFC 4971 where no intent to define 
a functional change is intended. It therefore has to be considered whether 
making many of the changes you suggest might unintentionally suggest a 
substantive change where none is intended.

Be interested in your thoughts on this.

After we reach agreement on the above point I will spin a new version 
addressing your comments.

Specific responses inline.

> -Original Message-
> From: Dale R. Worley [mailto:wor...@ariadne.com]
> Sent: Thursday, August 04, 2016 1:00 PM
> To: gen-art@ietf.org; i...@ietf.org; draft-ietf-isis-rfc4971bis@ietf.org
> Subject: IETF Last Call Gen-Art review of draft-ietf-isis-rfc4971bis-01
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-isis-rfc4971bis-01
> Reviewer: Dale R. Worley
> Review Date: 4 August 2016
> IETF LC End Date: 15 August 2016
> IESG Telechat date: 18 August 2016
> 
> Summary:
> 
> This draft is basically ready for publication, but has nits that should be 
> fixed
> before publication.
> 
> * Editorial items
> 
> How is "capability TLV" to be capitalized?  I count the following occurrences 
> of
> the different capitalizations:
> 
> 24 CAPABILITY(IES) TLV(s)
>  5 Capability(ies) TLV(s)
>  4 capability(ies) TLV(s)
> 
> The practice in other RFCs seems to be "Capability TLV".
> 
> This also affects two occurrences of "TLV named CAPABILITY".

[Les:] As "CAPABILITY" was the dominant form in RFC 4971 I would be inclined to 
use that. Also this is the form used in 
http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml

   " IS-IS Router CAPABILITY TLV"

But I agree consistency is desirable no matter what form we choose.

> 
> Abstract
> 
>This document defines a new optional Intermediate System to
>Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple
>sub-TLVs, which allows a router to announce its capabilities within
>an IS-IS level or the entire routing domain.
> 
> I think s/formed of/containing/ -- the TLV also contains the Router ID and
> Flags fields.
> 

[Les:] This text is unchanged from RFC 4971.

> 2.  IS-IS Router CAPABILITY TLV
> 
>The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type,
>1 octet that specifies the number of bytes in the value field, and a
>variable length value field that starts with 4 octets of Router ID,
>indicating the source of the TLV, and followed by 1 octet of flags.
> 
> Should some note be put here that if Capability is used as an extended TLV,
> the type and length are increased to 2 bytes?  That is a general fact about
> TLVs, of course, but strictly, the above sentence isn't always correct.  (Or 
> is
> the "extended" version available only for TLVs at some higher level of the
> hierarchy?)
>

[Les:] You refer here to the extended TLVs defined in RFC 7356  (pretty good 
find for someone who is not supposed to be an IS-IS expert :-) ).
I am reluctant to require IS-IS RFCs in general to have to define both formats. 
That seems unnecessary. I am even more reluctant to do so in a bis version of 
an existing RFC.

 
> I think s/and followed by/followed by/.  The subject of "followed" is
> "4 octets of Router ID", leaving "and" to join "indicating the source of the
> TLV" with "followed by 1 octet of flags", which is not a parallel 
> construction.
> Instead, omit "and" to make the construction "... value field that starts 
> with 4
> octets ... followed by ..."
> 

[Les:] No objection - though again this is the original text from RFC 4971 
which the RFC editor seemed happy with at the time.

> 3.  Elements of Procedure
> 
>Router ID sub-TLV [RFC5316] MUST be present in the TLV.  Router
>CAPABILITY TLVs which have a Router ID of 0.0.0.0 and do NOT have the
>IPv6 TE Router ID sub-TLV present MUST be ignored.
> 
> Given that "ignored" is used later to describe processing of unknown sub-
> TLVs, which must not be interpreted but which may need to be leaked,
> perhaps "ignored" here should be amplified.  Perhaps "ignored, including not
> leaked".

[Les:] Later in the same section where the draft discusses

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-isis-prefix-attributes-03

2016-01-03 Thread Les Ginsberg (ginsberg)

Paul -

Attached is a diff file w the changes I have made to address your comments. 
Please let me know if this suffices.

(co-authors - please let me know if you have any concerns regarding the 
proposed changes)

Thanx.

   Les


> -Original Message-
> From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
> Sent: Sunday, January 03, 2016 12:49 PM
> To: Les Ginsberg (ginsberg); draft-ietf-isis-prefix-attributes@ietf.org
> Cc: General Area Review Team
> Subject: Re: Gen-ART Last Call review of draft-ietf-isis-prefix-attributes-03
> 
> Hi Les,
> 
> Trimming to the relevant points:
> 
> On 1/3/16 9:27 AM, Les Ginsberg (ginsberg) wrote:
> 
> >> Note that at the end of the day my comments are just suggestions. You
> >> can act on them or not. They only become binding if the IESG decides
> >> to raise them.
> >
> > [Les:] I want you to know that I take your comments seriously - binding or
> not. You obviously invested time in reviewing - which I appreciate.
> 
> Thanks. Genart is educational for the reviewers (at least for me) because we
> are usually reviewing things we know nothing about! It often takes some
> sniffing around to gain enough context to do the review.
> 
> But I think that is the point of genart - to get a review from somebody who
> doesn't already know the subject.
> 
> >> Understood. But the abstract will be seen by many (like me) who don't
> >> fall into that category. They are left entirely in the dark about what 
> >> this is
> about.
> >> Might it be something they *ought* to be interested in?
> >> After reading the abstract, the only clue I had about the scope of
> >> this document was the name of the wg from the draft name. And once
> >> this becomes an RFC that won't be available as a hint. I had to look
> >> up isis in the list of WGs to discover that this was in the routing
> >> area. Then I had to do more searching to figure out what IS-IS was about.
> >>
> >
> > [Les:] The title (even once it becomes an RFC) includes "IS-IS".  If you 
> > don't
> know that IS-IS is a routing protocol, do you think that further 
> clarification is
> needed to help you understand that this isn't something which you are
> interested in reading?
> 
> It is sufficient to get people to stop reading and ignore it. Maybe that is
> enough.
> 
> But for the person who goes a step further and pulls the full document and
> still doesn't know, it would be nice to add an informative reference to the
> intro, to a base document for IS-IS. As best I can tell, the likely one is
> RFC1195. For example, revise the first sentence of the intro:
> 
> There are existing use cases for IS-IS [RFC1195] in which knowing
> additional attributes of a network prefix is useful.
> 
> >>> In regards to the term "prefix", you seem to be expecting the
> >>> document to
> >> define that term - but in looking at multiple RFCs I do not see
> >> precedent for that. It is part of the base knowledge that has been
> >> assumed that readers understand . Perhaps this is a bad practice -
> >> but if so there are many documents - not restricted solely to IS-IS
> >> related documents - that could be critiqued on this basis. I would
> >> ask that this comment be viewed in a larger context - I don't think
> >> this particular draft should be asked to deviate from common practice
> without larger guidance from the IETF community.
> >>
> >> Not a definition, just a disambiguation. Simply replacing "prefix"
> >> with "network prefix" would have met my need.
> >>
> >
> > [Les:] You are proposing that "prefix" be replaced by "network prefix"
> throughout the document?
> > This has not been done in any of the existing RFCs that I checked.
> 
> Not everywhere, just one or a few places - say in the abstract and the intro.
> 
> >>> In regards to "references to the Introduction", I emphasize that the
> >> Introduction is neither normative nor exhaustive. It is meant to
> >> provide some examples of cases where the information contained in the
> >> new advertisements could be useful. I therefore find that references
> >> to it would be inappropriate.
> >>
> >> I guess I wasn't clear. I was suggesting that reference(s) be added
> >> to the introduction. (References are not permitted in the abstract,
> >> but they are allowed in the intro.) A reference to the base
> >> specification for the internet version of IS-IS would have helped me.
> >>
> >
> &

Re: [Gen-art] Gen-art LC review: draft-ietf-isis-route-preference-02

2015-11-19 Thread Les Ginsberg (ginsberg)

Jari -

Thanx for the comments.
Inline.

> -Original Message-
> From: Jari Arkko [mailto:jari.ar...@piuha.net]
> Sent: Thursday, November 19, 2015 2:58 AM
> To: Les Ginsberg (ginsberg)
> Cc: Robert Sparks; General Area Review Team; draft-ietf-isis-route-
> preference@ietf.org; i...@ietf.org; isis...@ietf.org
> Subject: Re: [Gen-art] Gen-art LC review: draft-ietf-isis-route-preference-02
> 
> Thanks for the review, Robert.
> 
> Robert's question was good, and your answer Les was spot. What I'm
> wondering is whether it would be useful to add something to the document
> about your answer, Les? Or at the very least, a reference to Appendix A from
> Section 2. And if you add something about transition mechanisms, it could
> simply be "... transition mechanisms (such as configuration setting) ...".
> 
[Les:] The devil is really in the details in this draft - and I appreciate if 
you are not heavily into the protocol details things can be easily 
misinterpreted.

The draft makes one non-backwards compatible change to the protocol - which is 
to eliminate the incorrect " Level 2 down prefix" route type defined in RFC 
5308. This is the change that could require a transition mechanism.

Appendix A documents a real world interoperability issue - but it is NOT 
directly related to RFC 5308. It results from inconsistent interpretation of 
content in RFC 5302/RFC 5305. There is no transition mechanism proposed for 
this as the incompatibility already exists in some deployments. What is needed 
here is for the non-conforming implementations to correct their behavior.

We could mention Appendix A in Section 2 - but it would NOT be related to the 
transition mechanism which is suggested in that section.

(Hope this makes sense)

   Les

> Jari
> 
> On 27 Oct 2015, at 21:41, Les Ginsberg (ginsberg) <ginsb...@cisco.com>
> wrote:
> 
> > Robert -
> >
> > Thanx for the review.
> > Responses inline.
> >
> >> -Original Message-
> >> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> >> Sent: Tuesday, October 27, 2015 12:14 PM
> >> To: General Area Review Team;
> >> draft-ietf-isis-route-preference@ietf.org;
> >> i...@ietf.org; isis...@ietf.org
> >> Subject: Gen-art LC review: draft-ietf-isis-route-preference-02
> >>
> >> I am the assigned Gen-ART reviewer for this draft. The General Area
> >> Review Team (Gen-ART) reviews all IETF documents being processed by
> >> the IESG for the IETF Chair.  Please treat these comments just like
> >> any other last call comments.
> >>
> >> For more information, please see the FAQ at
> >>
> >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> >>
> >> Document: draft-ietf-isis-route-preference
> >> Reviewer: Robert Sparks
> >> Review Date: 27Oct2015
> >> IETF LC End Date: 30Oct2015
> >> IESG Telechat date: Not yet scheduled
> >>
> >> Summary: Ready for publication as Proposed Standard
> >>
> >> This document reads easily despite most of it being detailed lists. I
> >> have no objection to it moving forward, but I would like to check one
> thing:
> >>
> >> The sparsity of detail at the end of section 2, where you call out
> >> potential interoperability issues and suggest that "implementers may
> >> wish to support transition mechanisms" is concerning.  It might be
> >> worth being explicit here about the interoperability issues, and what
> >> a transition mechanism might look like, particularly if there's a
> >> chance of having to deal with a peer that won't implement what's
> described in this draft?
> >>
> > [Les:] Appendix A provides a real-life example of how the interoperability
> issue manifests itself. As far as how a transition mechanism might be
> implemented this gets into non-normative aspects. I have always had a
> strong bias for avoiding non-normative statements in specifications.
> Transition here really means having some configuration knob to specify
> whether old/new behavior should be used. Specifying a CLI is not something
> I would want to put into a standard. For folks who have an IS-IS
> implementation it isn't difficult to figure out how to do this.
> >
> >> Did the group consider defining a couple of new code points and
> >> deprecating these two, to avoid that transition issue?
> >
> > [Les:] This would not help - it would only make things more difficult. You
> would then have to deal with the transition between the old TLV and the
> new TLV - which has a much broader impact because it affects all IPv6 prefix
> reachability advertisements in all deployments - whereas the existing
> problem only occurs in certain deployments (multiple instances of IS-IS on
> the same router with redistribution between the instances at Level-2).
> >
> >   Les
> >
> > ___
> > Gen-art mailing list
> > Gen-art@ietf.org
> > https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Isis-wg] Gen-art LC review draft-ietf-isis-tlv-codepoints-00

2014-07-20 Thread Les Ginsberg (ginsberg)

Robert -

 -Original Message-
 From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Robert Sparks
 Sent: Sunday, July 20, 2014 7:27 AM
 To: draft-ietf-isis-tlv-codepoi...@tools.ietf.org; isis...@ietf.org; General
 Area Review Team
 Subject: [Isis-wg] Gen-art LC review draft-ietf-isis-tlv-codepoints-00

 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at

 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please resolve these comments along with any other Last Call comments
 you may receive.

 Document: draft-ietf-isis-tlv-codepoints-00
 Reviewer: Robert Sparks
 Review Date: 20-Jul-2014
 IETF LC End Date: 25-Jul-2014
 IESG Telechat date: 7-Aug-2014

 Summary: Basically ready for publication, but with process nits for the
 group and the IESG to consider

 Thanks for assembling such a clearly written document.

 The shepherd writeup should have discussed _why_ this document is
 intended for Proposed Standard.
 There is no protocol definition here, and nothing to progress on the
 standards ladder. This is, instead,
 primarily defining process. Why isn't this being progressed as a BCP?

The document does two things:

1)It updates some registries for sub-TLVs defined at 
http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml

As these changes are modifying the format (not the content) of registries used 
by a number of standards track RFCs it needs to be a standards track document.

2)It defines procedures for early allocation of codepoints from the above 
registry.

While an argument could be made that this portion should be BCP, the fact that 
it is combined with #1 requires that the document be Standards track.

 Should this Update any of the RFCs that previously defined these registries?

Yes - it updates the following RFCs: 5130, 5311

   Les

 ___
 Isis-wg mailing list
 isis...@ietf.org
 https://www.ietf.org/mailman/listinfo/isis-wg

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-isis-fs-lsp-01

2014-06-02 Thread Les Ginsberg (ginsberg)

Meral -

Thanx for your review.
Responses inline.

From: Meral Shirazipour [mailto:meral.shirazip...@ericsson.com]
Sent: Monday, June 02, 2014 5:46 PM
To: draft-ietf-isis-fs-lsp@tools.ietf.org; gen-art@ietf.org
Subject: Gen-ART Last Call review of draft-ietf-isis-fs-lsp-01

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments you may 
receive.

Document: draft-ietf-isis-fs-lsp-01
Reviewer: Meral Shirazipour
Review Date: 2014-06-02
IETF LC End Date:   2014-06-03
IESG Telechat date: 2014-06-12

Summary:
This draft is ready to be published as Standard RFC but I have some editorial 
comments.

Nits/editorial comments:
-[Page 5], Section 2, typo , identifes--identifies

LES :Corrected.

-[Pages 8, 10, 12],  typo: sub-TLVss-sub-TLVs

LES: Corrected.

-[page 6] section 2.2, an example would be useful for:

o  The eight bit type is encoded as an unsigned 16 bit integer

LES: I have modified the bullet point to read The eight bit type is encoded as 
an unsigned 16 bit integer where the 8 MSBs are all 0

o  The eight bit length field is replaced by the 16 bit length field

LES: I am not sure what you expect as an example. Because the length field is 
16 bits instead of 8, the length field can take on values greater than 255 - a 
point which which is explicitly made in the next bullet. The  numerical value 
used in the length field in an Extended TLV is not limited to the values used 
in Standard TLVs (= 255) even when the type is a Standard TLV code point.

-[Page 14], Section 5 the sentence could be more readable with the suggested 
change:
old:

Even when all routers in a given scope support FS PDUs, if not all routers in
   the flooding domain for a given scope support that scope flooding of
   the FS-LSPs may be compromised.

suggested:(added , then)

Even when all routers in a given scope support FS PDUs, if not all routers in
   the flooding domain for a given scope support that scope, then flooding of
   the FS-LSPs may be compromised.

LES: Accepted

-Suggestion, when reference to [IS-IS] is made, it would be very useful to 
point to the right section as well, when possible.

LES: There is not a single section which is applicable to the references. In 
most cases there are multiple sections which apply - so I don't think your 
suggestion is practical.

   Les

Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.comhttp://www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-isis-genapp-04

2011-03-15 Thread Les Ginsberg (ginsberg)

 -Original Message-
 From: Ben Campbell [mailto:b...@nostrum.com]
 Sent: Tuesday, March 15, 2011 12:26 PM
 To: draft-ietf-isis-genapp@tools.ietf.org
 Cc: General Area Review Team; The IETF
 Subject: Gen-ART Telechat review of draft-ietf-isis-genapp-04

 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please wait for direction from your document shepherd
 or AD before posting a new version of the draft.

 Document: draft-ietf-isis-genapp-04
 Reviewer: Ben Campbell
 Review Date: 2011-03-15
 IESG Telechat date: 2011-03-17

 Summary: This draft is ready for publication as a proposed standard.

 Major issues:

 None

 Minor issues:

 None

 Nits/editorial comments:

 IDNits still emits some minor warnings and comments--please check.

 -- Security Considerations, 2nd paragraph: It is possible that
 information advertised in a GENINFO TLV by a given Application MAY
 introduce new security issues.

 I assume that was not meant as a normative MAY?

Not intentionally. I am fine with converting this to lower case.

   Les

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt

2010-10-06 Thread Les Ginsberg (ginsberg)

Ben -

Thanx for the review.
Inline.

 -Original Message-
 From: Ben Campbell [mailto:b...@nostrum.com]
 Sent: Tuesday, October 05, 2010 12:06 PM
 To: draft-ietf-isis-genapp@tools.ietf.org; General Area Review
Team
 Cc: The IETF
 Subject: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt

 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please wait for direction from your document shepherd
 or AD before posting a new version of the draft.

 Document: draft-ietf-isis-genapp-03.txt
 Reviewer: Ben Campbell
 Review Date: 05 Oct 2010
 IESG Telechat date: 07 Oct 2010

 Summary:

 The draft is almost ready for publication as a proposed standard, but
I
 have some concerns that I think should be addressed first.

 Major issues:

 -- This draft creates an expansion code point in an IANA registry,
 where the expansion registration requirements are weaker than those of
 the parent registry. This always makes me nervous, as it opens the
 window for end-runs around the registration requirements of the
parent.

 In this particular instance, the parent registry policy is expert
 review while the proposed expansion registry policy is specification
 required. This draft puts normative requirements on the content of
the
 required specifications, and makes additional non-normative statements
 about the intended use of the GENINFO code point. This implies to me
 that the review process needs to do more than determine that
sufficient
 specification exists. Rather, it needs to determine that the criteria
 in this draft are met by that specification. Therefore, I think that
it
 would be appropriate for the GENINFO registry to use the expert
 review policy.

From RFC 5226:

Specification Required - Values and their meanings must be
documented in a permanent and readily available public
specification, in sufficient detail so that interoperability
between independent implementations is possible.  When used,
Specification Required also implies use of a Designated
Expert, who will review the public specification...

We deliberately chose Specification Required because:

a)It requires a public specification
b)It allows the public specification to be other than an RFC
c)It requires expert review

 Minor issues:

 -- section 4.2, 2nd paragraph: Where this is not possible, the two
 affected LSPs SHOULD be flooded as an atomic action

 Any reason that this is not a MUST, since it seems like the safety-net
 behavior for when the aforementioned SHOULD is not  possible to
follow?

It is a recommended behavior. If an implementation does not do this it
does not create an interoperability issue - but it may create
sub-optimal behavior. 

 -- Section 4.3: When information in the two GENINFO TLVs conflicts
i.e
 there are different settings for a given attribute, the procedure used
 to choose which copy shall be used is undefined.

 Should their be normative requirement not to create this undefined
 condition in the first place?

If the revised version of a GENINFO TLV is sent in an LSP with a
different number from the previous version there can be transient
windows where other systems have two copies of information regarding the
same application. This may be unavoidable. For completeness we specify
that the choice of what to do in such transient situations is
implementation specific (undefined). This section does specify ways to
minimize the occurrence/duration of such transient periods.

 -- Security Considerations:

 This seems too lightweight. Is it impossible for GENINFO applications
 to include sensitive information? Are there no security guidelines
that
 should apply to GENINFO application specifications?

We have no way of knowing what type of information might be advertised
by a given application - and we are not limiting what may be advertised.
Clearly the public document which specifies the application would need
to address the security issues it introduces. We cannot do that here.

 Even if the answer is that the underlying IS-IS protocol provides
 sufficient security for any reasonable use of the GENINFO code point,
 it would be worth saying that explicitly.

 Nits/editorial comments:

 -- section 2

 Please expand IS-IS and PDU on first mention.

OK

 -- section 6, last paragraph:

 Expected/desired by whom?

Well, at least by the authors. :-)

 -- Outdated reference for draft-ietf-isis-mi

It was current at the time the draft was written.

   Les

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt

2010-10-06 Thread Les Ginsberg (ginsberg)

Ben -

 -Original Message-
 From: Ben Campbell [mailto:b...@nostrum.com]
 Sent: Wednesday, October 06, 2010 7:10 AM
 To: Les Ginsberg (ginsberg)
 Cc: draft-ietf-isis-genapp@tools.ietf.org; General Area Review
 Team; The IETF
 Subject: Re: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-
 03.txt

 Thanks for the quick response. Comments inline:

 On Oct 6, 2010, at 7:55 AM, Les Ginsberg (ginsberg) wrote:

  Ben -

  Thanx for the review.
  Inline.

  -Original Message-
  From: Ben Campbell [mailto:b...@nostrum.com]
  Sent: Tuesday, October 05, 2010 12:06 PM
  To: draft-ietf-isis-genapp@tools.ietf.org; General Area Review
  Team
  Cc: The IETF
  Subject: Gen-ART LC/Telechat Review of
draft-ietf-isis-genapp-03.txt

  I am the assigned Gen-ART reviewer for this draft. For background
on
  Gen-ART, please see the FAQ at
   http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

  Please wait for direction from your document shepherd
  or AD before posting a new version of the draft.

  Document: draft-ietf-isis-genapp-03.txt
  Reviewer: Ben Campbell
  Review Date: 05 Oct 2010
  IESG Telechat date: 07 Oct 2010

  Summary:

  The draft is almost ready for publication as a proposed standard,
 but
  I
  have some concerns that I think should be addressed first.

  Major issues:

  -- This draft creates an expansion code point in an IANA
registry,
  where the expansion registration requirements are weaker than those
 of
  the parent registry. This always makes me nervous, as it opens the
  window for end-runs around the registration requirements of the
  parent.

  In this particular instance, the parent registry policy is expert
  review while the proposed expansion registry policy is
 specification
  required. This draft puts normative requirements on the content of
  the
  required specifications, and makes additional non-normative
 statements
  about the intended use of the GENINFO code point. This implies to
me
  that the review process needs to do more than determine that
  sufficient
  specification exists. Rather, it needs to determine that the
 criteria
  in this draft are met by that specification. Therefore, I think
that
  it
  would be appropriate for the GENINFO registry to use the expert
  review policy.

  From RFC 5226:

  Specification Required - Values and their meanings must be
 documented in a permanent and readily available public
 specification, in sufficient detail so that
 interoperability
 between independent implementations is possible.  When
 used,
 Specification Required also implies use of a Designated
 Expert, who will review the public specification...

  We deliberately chose Specification Required because:

  a)It requires a public specification
  b)It allows the public specification to be other than an RFC
  c)It requires expert review

 Completing the sentence in your quote: who will review the public
 specification and evaluate whether it is sufficiently clear to allow
 interoperable implementations.

 My understanding of Specification Required is that the expert review
 is merely to ensure that the documentation is sufficiently complete
and
 readable to implement in an interoperable way. That review is not
 intended to ensure compliance to other criteria specified in the
draft.

 However, the draft includes some specific criteria for GENINFO
 applications. If you want the reviewer to enforce those criteria, then
 I think you need at least Expert Review. OTOH, in RFC5226, the
 expert review policy has less to say about the required level of
 documentation, so the draft might require some more meat in that area.

This is a bit distressing - because you are suggesting that RFC 5226
doesn't define a category which is appropriate for our usage - which
means we have to try to define a unique policy. I am not quite sure how
to do that with sufficient authority and minimal controversy.

My understanding is that RFC 5226 is specific to IANA considerations -
so we have attempted to define a clear policy as to how the review of
code point assignments is done.

Beyond that, it seems clear that a given Application specification could
specify behavior that might be seen as undesirable e.g. it could specify
some extremely high rate of updates. Given that we allow application
specification to be defined in public documents from a variety of
sources, I don't see how we could define an enforceable review policy
for the application specifications. It is at the IANA codepoint
allocation that we have control - and certainly it seems within the
purview of an expert to say I think your specification is flawed and I
won't approve the allocation of codepoints until the issues of concern
are addressed.

 I note that while RFC3563, which established the IS-IS TLV Codepoint
 registry, says Expert Review, the review criteria is pretty much
 equivalent to standards action. I'm guessing the only

Re: [Gen-art] Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt

2010-10-06 Thread Les Ginsberg (ginsberg)

Ben -

The points you make below make sense to me - but I am not sure how we
get the stronger review process associated w Expert Review and at the
same time require that some public document exist for each application.
Are you saying that we can require both? I actually thought that was the
intent of Specification Required - but your comments suggest
otherwise.

I really wish RFC 5226 addressed this more robustly...

   Les

 -Original Message-
 From: Ben Campbell [mailto:b...@nostrum.com]
 Sent: Wednesday, October 06, 2010 8:55 AM
 To: Les Ginsberg (ginsberg)
 Cc: draft-ietf-isis-genapp@tools.ietf.org; General Area Review
 Team; The IETF
 Subject: Re: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-
 03.txt
 
 
 On Oct 6, 2010, at 10:14 AM, Les Ginsberg (ginsberg) wrote:
 
 
 [...]
 
 
  From RFC 5226:
 
  Specification Required - Values and their meanings must be
documented in a permanent and readily available public
specification, in sufficient detail so that
  interoperability
between independent implementations is possible.  When
  used,
Specification Required also implies use of a Designated
Expert, who will review the public specification...
 
  We deliberately chose Specification Required because:
 
  a)It requires a public specification
  b)It allows the public specification to be other than an RFC
  c)It requires expert review
 
  Completing the sentence in your quote: who will review the public
  specification and evaluate whether it is sufficiently clear to
allow
  interoperable implementations.
 
  My understanding of Specification Required is that the expert
 review
  is merely to ensure that the documentation is sufficiently complete
  and
  readable to implement in an interoperable way. That review is not
  intended to ensure compliance to other criteria specified in the
  draft.
 
  However, the draft includes some specific criteria for GENINFO
  applications. If you want the reviewer to enforce those criteria,
 then
  I think you need at least Expert Review. OTOH, in RFC5226, the
  expert review policy has less to say about the required level of
  documentation, so the draft might require some more meat in that
 area.
 
 
  This is a bit distressing - because you are suggesting that RFC 5226
  doesn't define a category which is appropriate for our usage - which
  means we have to try to define a unique policy. I am not quite sure
 how
  to do that with sufficient authority and minimal controversy.
 
  My understanding is that RFC 5226 is specific to IANA considerations
 -
  so we have attempted to define a clear policy as to how the review
of
  code point assignments is done.
 
  Beyond that, it seems clear that a given Application specification
 could
  specify behavior that might be seen as undesirable e.g. it could
 specify
  some extremely high rate of updates. Given that we allow application
  specification to be defined in public documents from a variety of
  sources, I don't see how we could define an enforceable review
policy
  for the application specifications. It is at the IANA codepoint
  allocation that we have control - and certainly it seems within the
  purview of an expert to say I think your specification is flawed
and
 I
  won't approve the allocation of codepoints until the issues of
 concern
  are addressed.
 
 
 
 Yes, both specification required and expert review involve expert
 review. But they have significant differences in the scope of the
 review. Specification required means that the expert should review
to
 make sure the specification is clear enough to be implemented in an
 interoperable fashion. It doesn't in any way indicate that the expert
 thinks the code point is good, or that it conforms to the purpose of
 the registry. Certainly, the expert could offer advise on issues, but
 the registrant would not be under any obligation to follow the advise.
 
 Expert Review means that the expert should review a registration to
 make sure that it conforms to the criteria set forth in the document
 that defined the registry. I really think that is what you are looking
 for, particularly from your last sentence above about the expert being
 able to block allocation of a flawed code point.
 
 For example, RFC 3563 calls out Expert Review, and sets a number of
 criteria, one of which is the assertion that registrations require
 standards actions, or that they require publications from  ISO/IEC
 JTC1/SC6 that meant the normal requirements for an RFC.
 
 In your case, I think you need Expert Review, with criteria along the
 lines that registrants must meet the requirements of specification
 required, that it must describe its expected rate of updates (and
that
 this not be excessive), that it must address any security
 considerations, etc.
 
 
  I note that while RFC3563, which established the IS-IS TLV
Codepoint
  registry, says Expert Review, the review criteria is pretty much
  equivalent

Re: [Gen-art] Gen-ART LC review of draft-ietf-isis-wg-extlsp-03.txt

2008-10-27 Thread Les Ginsberg (ginsberg)

Brian -

Thanx for the review - I will work with Danny to get the editorial
issues corrected. Some replies to your non-editorial questions/issues:

Do you want the IESG to also reclassify RFC3786 as Historic?
If so, I suggest saying this explicitly in the Introduction.

LES: I would think obsolete is more appropriate.

The draft uses the phrase Virtual IS without defining it. I see
that RFC3786 defines and uses Virtual System. 

LES: Agreed - we need a definition.

Is it IS-Alias or IS Alias ID? I don't see a reason for having
two names for the same TLV.

LES: Agreed - we'll make this consistent.

What happens when a legacy implementation receives an IS Alias ID,
IS Neighbor Attribute, or MT IS Neighbor Attribute TLV?
Is silent discard specified in the IS-IS standard?

LES: Yes. See ISO 10589 Section 9.5:

Any codes in a received PDU that are not recognised shall be ignored.

Similar text is found in the sections for each PDU type. For example in
Section 9.8:

Any codes in a received LSP that are not recognised are ignored and
passed through unchanged.

   Les


 -Original Message-
 From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
 Sent: Monday, October 27, 2008 5:39 PM
 To: General Area Review Team
 Cc: Ross Callon; [EMAIL PROTECTED]; isis-
 [EMAIL PROTECTED]
 Subject: Gen-ART LC review of draft-ietf-isis-wg-extlsp-03.txt
 
 
 
 
 
 
 
 
 
 
 
 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

44 matches

Mail list logo