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

[Pushpasis Sarkar]

Hi Acee,

LOL.. Might as well be 'link-on-break'.. :)

Anyways graceful-link-shutdown seems to be the most agreed upon.

Thanks and regards,
-Pushpasis


On Tue, Jan 9, 2018 at 9:29 PM, Acee Lindem (acee) <a...@cisco.com> wrote:

> Hi Pushpasis, Shraddha, et al,
>
> From: Pushpasis Sarkar <pushpasis.i...@gmail.com>
> Date: Monday, January 8, 2018 at 12:22 PM
> To: Bruno Decraene <bruno.decra...@orange.com>
> Cc: Shraddha Hegde <shrad...@juniper.net>, Acee Lindem <a...@cisco.com>,
> "Les Ginsberg (ginsberg)" <ginsb...@cisco.com>, "Ketan Talaulikar
> (ketant)" <ket...@cisco.com>, "Joel M. Halpern" <j...@joelhalpern.com>, "
> gen-art@ietf.org" <gen-art@ietf.org>, OSPF WG List <o...@ietf.org>, "
> i...@ietf.org" <i...@ietf.org>, "draft-ietf-ospf-link-
> overload@ietf.org" <draft-ietf-ospf-link-overload@ietf.org>
> Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11
> Resent-From: <alias-boun...@ietf.org>
> Resent-To: Shraddha Hegde <shrad...@juniper.net>, Pushpasis Sarkar <
> pushpasis.i...@gmail.com>, Hannes Gredler <han...@gredler.at>, <
> mnand...@ebay.com>, Luay Jalil <luay.ja...@verizon.com>, Acee Lindem <
> a...@cisco.com>, <a...@cisco.com>, Alvaro Retana <aretana.i...@gmail.com>,
> Deborah Brungard <db3...@att.com>, Alia Atlas <akat...@gmail.com>, Acee
> Lindem <a...@cisco.com>
> Resent-Date: Monday, January 8, 2018 at 12:22 PM
>
> Hi Joel et al,
>
> +1 for 'graceful-link-shutdown'.
>
>
> I think we are converging on this. I must admit that it is much better
> than “link-overload”. Although Les raises a good point that this behavior
> could be used for other use cases, subsequent discussions have indicated
> that these could be handled differently.
>
>
> Another possibility may be 'link-decommission'..
>
>
> This implies too much permanence. If you decommission something, you are
> more or less retiring It which is not this use case. This is more of giving
> the link a rest. Maybe we could use the there term “Link on Leave” or LOL
> state ;^).
>
> Thanks,
> Acee
>
>
> Thanks and regards
> -Pushpasis
>
> On Mon, Jan 8, 2018 at 7:09 PM, <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 <a...@cisco.com>]
>> *Sent:* Friday, January 5, 2018 6:50 PM
>> *To:* 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.
>> a...@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>
>> *Date: *Thursday, January 4, 2018 at 11:56 PM
>> *To: *"Ketan Talaulikar (ketant)" <ket...@cisco.com>, Acee Lindem <
>> a...@cisco.com>, "Joel M. Halpern" <j...@joelhalpern.com>, "
>> gen-art@ietf.org" <gen-art@ietf.org>
>> *Cc: *OSPF WG List <o...@ietf.org>, "i...@ietf.org" <i...@ietf.org>, "
>> draft-ietf-ospf-link-overload@ietf.org" <
>> 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.
>>
>>
>>
>>

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

[Pushpasis Sarkar]

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,  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) ; Ketan Talaulikar
> (ketant) ; Joel Halpern ;
> gen-art@ietf.org
> *Cc:* o...@ietf.org; i...@ietf.org; draft-ietf-ospf-link-overload.
> a...@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)" 
> *Date: *Thursday, January 4, 2018 at 11:56 PM
> *To: *"Ketan Talaulikar (ketant)" , Acee Lindem <
> a...@cisco.com>, "Joel M. Halpern" , "
> gen-art@ietf.org" 
> *Cc: *OSPF WG List , "i...@ietf.org" , "
> draft-ietf-ospf-link-overload@ietf.org"  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) ; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; Joel Halpern ; gen-art@ietf.org
> *Cc:* o...@ietf.org; i...@ietf.org; draft-ietf-ospf-link-overload.
> a...@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) ; Joel Halpern <
> j...@joelhalpern.com>; gen-art@ietf.org
> *Cc:* o...@ietf.org; i...@ietf.org; draft-ietf-ospf-link-overload.
> a...@ietf.org
> *Subject:* Re: [OSPF] Genart last call review of
> draft-ietf-ospf-link-overload-11
>
>
>
> Hi Les,
>
>
>
> *From: *"Les Ginsberg (ginsberg)" 
> *Date: *Thursday, January 4, 2018 at 9:26 PM
> *To: *Acee Lindem , "Joel M. Halpern" ,
> "gen-art@ietf.org" 
> *Cc: *OSPF WG List , "i...@ietf.org" , "
> draft-ietf-ospf-link-overload@ietf.org"  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 

Re: [Gen-art] Gen-ART Telechat Call review of draft-ietf-rtgwg-rlfa-node-protection-10

[Pushpasis Sarkar]

Hi Meral,

Thanks a lot for your review once again.

Regards,
-Pushpasis

On Thu, Jan 19, 2017 at 12:14 AM, Meral Shirazipour <
meral.shirazip...@ericsson.com> wrote:

> 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  area/gen/trac/wiki/GenArtfaq>.
>
>
>
> Document: draft-ietf-rtgwg-rlfa-node-protection-10
>
> Reviewer: Meral Shirazipour
>
> Review Date: 2017-01-18
>
> IETF LC End Date: 2017-01-04 (extension 2017-01-11)
>
> IESG Telechat date: 2017-01-05  (extension 2017-01-19)
>
>
>
> Summary: This draft is ready to be published as Standards RFC.
>
>
>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
>
>
>
>
> 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] Gen-ART Last Call review of draft-ietf-rtgwg-rlfa-node-protection-09

[Pushpasis Sarkar]

Hi Meral,

I have addressed all your comments and uploaded version 10. Thanks once
again for the detailed review. Please let me know if you have any further
comments.

Thanks and regards,
-Pushpasis

On Thu, Dec 29, 2016 at 10:33 PM, Meral Shirazipour <
meral.shirazip...@ericsson.com> wrote:

> Hi,
>
>   Many thanks for the response.
>
>
>
> Best Regards,
>
> Meral
>
>
>
> *From:* Pushpasis Sarkar [mailto:pushpasis.i...@gmail.com]
> *Sent:* Thursday, December 29, 2016 12:20 AM
> *To:* Meral Shirazipour <meral.shirazip...@ericsson.com>
> *Cc:* draft-ietf-rtgwg-rlfa-node-protection@tools.ietf.org;
> gen-art@ietf.org
> *Subject:* Re: Gen-ART Last Call review of draft-ietf-rtgwg-rlfa-node-
> protection-09
>
>
>
> Hi Meral,
>
>
>
> First, many many thanks to you for the detailed review comments. :)
>
>
>
> Next, please find few replies inline. Rest of the comments has been
> accepted as is, and will be addressed soon.
>
>
>
> Thanks
>
> -Pushpasis
>
>
>
>
>
> On Wed, Dec 28, 2016 at 11:03 PM, Meral Shirazipour <
> meral.shirazip...@ericsson.com> wrote:
>
> 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-rtgwg-rlfa-node-protection-09
>
> Reviewer: Meral Shirazipour
>
> Review Date: 2016-12-28
>
> IETF LC End Date:   2017-01-04 (extension 2017-01-11)
>
> IESG Telechat date: 2017-01-05 (extended)
>
>
>
>
>
> Summary:
>
> This draft is ready to be published as Standards Track RFC but I have
> comments.
>
>
>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
>
>
> -Please spell out Loop-Free Alternate (LFA), Shortest Path First (SPF) at
> first use.
>
>
>
> -typo in draft header:
>
> "Internet-Draft   R-LFA Node-Protection and ManageabiltyDecember 2016"
>
> "Manageabilty"--should be-->"Manageability"
>
>
>
> -Same typo in Section 3 header: "Manageabilty of Remote-LFA Alternate
> Paths"
>
> "Manageabilty"--should be-->"Manageability"
>
>
>
> -[Page 6] Section 2.2.3.
>
> "on any of the shortest path", path -->"paths"
>
>
>
> -[Page 6] Section 2.2.3.
>
> "from the node Y to primary nexthop E":
>
> "one ECMP path from the node Y":
>
> -->the example in this draft did not use the letter Y for any nodes. Would
> it be clearer to say node Y is defined in Section 2.2.4?
>
>
>
> -Few occurences of "w.r.t to ", the "to" is redundant.
>
>
>
> -[Page 1], "can be utilised "--->"can be utilized"
>
>
>
> -[Page 9], Section 2.3
>
> "Sections Section 2.3.1 and Section 2.3.2 shows "--->"Section 2.3.1 and
> Section 2.3.2 show"
>
>
>
> -[Page 11], "To determine wether"--->"To determine whether"
>
>
>
> -[Page 11], "primary nexthop node"-->"primary nexthop nodes"
>
>
>
> -[Page 13], "choose only the ones that does"--->"choose only the ones that
> do"
>
>
>
> -[Page 13], "not gaurantee"--->"not guarantee"
>
>
>
> -[Page 14], "Figure 7: Toplogy with multiple ECMP primary
> nexthops"--->"Figure 7: Topology with multiple ECMP primary nexthops"
>
>
>
> -[Page 14], "node-proecting"--->"node-protecting"
>
>
>
> -[Page 15], "paths tp PQ-node R2"--->"paths to PQ-node R2"
>
>
>
> -[Page 16], "gaurantees node-protection"--->"guarantees node-protection"
>
>
>
> -[Page 17],  "above example above"--->"above example"
>
>
>
> -[Page 17], "also allow user"--->"also allow the user"
>
>
>
> -[Page 18], "the the computing">"the computing"
>
>
>
> -[Page 18], "in section Section 2.3.2.">"in Section 2.3.2." (2
> occurrences)
>
>
>
> -[Page 18], "in section Section 2.3 the">"in Section 2.3 the"
>
>
>
> -[Page 18], "i.e from ">"i.e. from "
>
>
>
> -[Page 18], "two 

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-rtgwg-rlfa-node-protection-09

[Pushpasis Sarkar]

Hi Meral,

First, many many thanks to you for the detailed review comments. :)

Next, please find few replies inline. Rest of the comments has been
accepted as is, and will be addressed soon.

Thanks
-Pushpasis


On Wed, Dec 28, 2016 at 11:03 PM, Meral Shirazipour <
meral.shirazip...@ericsson.com> wrote:

> 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-rtgwg-rlfa-node-protection-09
>
> Reviewer: Meral Shirazipour
>
> Review Date: 2016-12-28
>
> IETF LC End Date:   2017-01-04 (extension 2017-01-11)
>
> IESG Telechat date: 2017-01-05 (extended)
>
>
>
>
>
> Summary:
>
> This draft is ready to be published as Standards Track RFC but I have
> comments.
>
>
>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
>
>
> -Please spell out Loop-Free Alternate (LFA), Shortest Path First (SPF) at
> first use.
>
>
>
> -typo in draft header:
>
> "Internet-Draft   R-LFA Node-Protection and ManageabiltyDecember 2016"
>
> "Manageabilty"--should be-->"Manageability"
>
>
>
> -Same typo in Section 3 header: "Manageabilty of Remote-LFA Alternate
> Paths"
>
> "Manageabilty"--should be-->"Manageability"
>
>
>
> -[Page 6] Section 2.2.3.
>
> "on any of the shortest path", path -->"paths"
>
>
>
> -[Page 6] Section 2.2.3.
>
> "from the node Y to primary nexthop E":
>
> "one ECMP path from the node Y":
>
> -->the example in this draft did not use the letter Y for any nodes. Would
> it be clearer to say node Y is defined in Section 2.2.4?
>
>
>
> -Few occurences of "w.r.t to ", the "to" is redundant.
>
>
>
> -[Page 1], "can be utilised "--->"can be utilized"
>
>
>
> -[Page 9], Section 2.3
>
> "Sections Section 2.3.1 and Section 2.3.2 shows "--->"Section 2.3.1 and
> Section 2.3.2 show"
>
>
>
> -[Page 11], "To determine wether"--->"To determine whether"
>
>
>
> -[Page 11], "primary nexthop node"-->"primary nexthop nodes"
>
>
>
> -[Page 13], "choose only the ones that does"--->"choose only the ones that
> do"
>
>
>
> -[Page 13], "not gaurantee"--->"not guarantee"
>
>
>
> -[Page 14], "Figure 7: Toplogy with multiple ECMP primary
> nexthops"--->"Figure 7: Topology with multiple ECMP primary nexthops"
>
>
>
> -[Page 14], "node-proecting"--->"node-protecting"
>
>
>
> -[Page 15], "paths tp PQ-node R2"--->"paths to PQ-node R2"
>
>
>
> -[Page 16], "gaurantees node-protection"--->"guarantees node-protection"
>
>
>
> -[Page 17],  "above example above"--->"above example"
>
>
>
> -[Page 17], "also allow user"--->"also allow the user"
>
>
>
> -[Page 18], "the the computing">"the computing"
>
>
>
> -[Page 18], "in section Section 2.3.2.">"in Section 2.3.2." (2
> occurrences)
>
>
>
> -[Page 18], "in section Section 2.3 the">"in Section 2.3 the"
>
>
>
> -[Page 18], "i.e from ">"i.e. from "
>
>
>
> -[Page 18], "two Remote-LFA alternate path"--->"two Remote-LFA alternate
> paths"
>
>
>
> -[Page 19], "the approach proposed"->"the proposed approach "
>
>
>
> -[Page 19], "is needed keep ">"is needed to keep"
>
>
>
> -[Page 19], "entire toplogy">"entire topology"
>
>
>
> -General: Is there any proof or extensive simulation that has proved that
> the mechanism proposed works for various network topologies and not only
> the one shown in the examples?
>
>
>
[Pushpasis] These mechanisms has been implemented (by atleast one vendor,
to my knowledge) and has been extensively tested in few of the operator's
network. As is the case with L-FA (RFC 5286) and R-LFA(RFC 7490)
specifications, these mechanisms either provide you with a backup
alternate, or does not. But if a backup is verified using these mechanism,
it is 100% guaranteed to be loop-free. As you might be already be aware of,
R-LFA is more suited towards ring-like network topologies. None of these
mechanisms always provide 100% backup coverage (i.e. they do not always let
you discover all the possible/feasible backup paths). But depending on
actual topologies, they can provide coverage somewhere between 100%-86%.
You may want to refer to RFC 7490 section 9. Please let me know if you need
any further information on this.

Thanks
-Pushpasis


>
>
>
> 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] Gen-ART Telechat review of draft-ietf-isis-node-admin-tag-10

[Pushpasis Sarkar]

Hi Peter,

I have uploaded version-11 addressing all the comments below. Please let 
me know if you have any more comments.


Thanks and Regards,

-Pushpasis


On 5/4/16 2:32 AM, Peter Yee wrote:

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 background on Gen-ART,
please see the FAQ at


Document: draft-ietf-isis-node-admin-tag-10
Reviewer: Peter Yee
Review Date: May 3, 2016
IETF LC End Date: April 29, 2016
IESG Telechat date: May 5, 2016

Summary: This draft is basically ready for publication as a Standards Track
RFC, but has an issue and some nits that should be fixed/considered before
publication. [Ready with issues]

This draft defines a means to carry additional per-node administrative tags
with the IS-IS protocol.  These tags can be used along with local policy to
simplify the management of routing and path selection.  This specification
gives informative examples of such tag usage but does not otherwise
prescribe the meaning of the tags.

Major issues: None

Minor issues:

Page 5, section 4.2, 2nd paragraph, 1st sentence: The sentence states:
"Being part of the Router CAPABILITY TLV, the node administrative tag
sub-TLV MUST be reasonably small and stable."  If you're going to make this
a MUST, you've got to at least give a definition of "reasonably small" and
perhaps even "stable" in the context of this specification.  As it stands,
there's no test for whether the MUST is enforceable or understandable
between parties.

Nits:

General:

The use of capitalization of Node administrative tag varies throughout the
document.  It seems clear that you mean for it to be written as "Node
Administrative Tag" when referring to the name of sub-TLV.  For other uses,
I would suggest using "node administrative tag" (all lower case)
consistently.  Use that to replace "Node administrative tag".

Specific:

  Page 3, 1st paragraph after the labeled items at the top, 3rd sentence:
change the first "TLV" to "sub-TLV".

Page 3, Section 2, 2nd paragraph: append a comma after "another".

Page 3, Section 3, 1st paragraph, 1st sentence: change "a" before "IS-IS" to
"an".

Page 3, Section 3, 1st paragraph, 2nd sentence: change "Capablity" to
"CAPABILITY".

Page 3, Section 3, 1st paragraph, 3rd sentence: change "Operator" to "An
operator".  Change "diiferent" to "different".

Page 3, Section 3, 2nd paragraph, 1st sentence: insert "the" before "Node".

Page 3, Section 3, 2nd paragraph, 2nd sentence: change "topology specific"
to "topology-specific".  (That is to say, swap the space for a hyphen.)

Page 4, Section 3.1, Value definition: insert "node" before
"administrative".

Page 4, Section 4.1, 1st sentence: change "Node" to "node".  (See general
nit.)

Page 4, Section 4.1, 3rd sentence: delete the space after the slash and
before regulations.

Page 5, 3rd full paragraph, 4th sentence: delete the spaces after closing
parenthesis and the terminating period.

Page 6, Section 4.3, 1st paragraph, 2nd sentence: change "Node" to "node".
(See general nit.)  Change the first "TLVs" to "sub-TLVs".

Page 6, Section 4.3, 2nd paragraph, 2nd sentence: delete the space before
the comma.

Page 6, Section 5, 1st paragraph, 1st sentence: change "Node" to "node".
(See general nit.)

Page 6, Section 5, 1st paragraph, 4th sentence: change "Following" to "The
following".

Page 6, Section 5, 1st paragraph, 5th sentence: change "section-3" to
"section 3".

Page 7, Section 6, 2nd paragraph, the comma should be rejoined with the
closing parenthesis.

Page 7, Section 7, 1st paragraph, 3rd sentence: change "is" to "are".

Page 7, Section 8, 1st paragraph, 2nd sentence: delete "The" before "YANG".
With the change in the rest of the sentence, "The" becomes superfluous.

Page 8, Section 9: change "Capabality" to "CAPABILITY".



___
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-node-admin-tag-10

[Pushpasis Sarkar]

Hi Peter,

Sorry for the late reply. Was not doing well..

Once again, thanks a lot for the detailed review comments. I will 
address them very soon..


Thanks
-Pushpasis



On 5/4/16 2:32 AM, Peter Yee wrote:

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 background on Gen-ART,
please see the FAQ at


Document: draft-ietf-isis-node-admin-tag-10
Reviewer: Peter Yee
Review Date: May 3, 2016
IETF LC End Date: April 29, 2016
IESG Telechat date: May 5, 2016

Summary: This draft is basically ready for publication as a Standards Track
RFC, but has an issue and some nits that should be fixed/considered before
publication. [Ready with issues]

This draft defines a means to carry additional per-node administrative tags
with the IS-IS protocol.  These tags can be used along with local policy to
simplify the management of routing and path selection.  This specification
gives informative examples of such tag usage but does not otherwise
prescribe the meaning of the tags.

Major issues: None

Minor issues:

Page 5, section 4.2, 2nd paragraph, 1st sentence: The sentence states:
"Being part of the Router CAPABILITY TLV, the node administrative tag
sub-TLV MUST be reasonably small and stable."  If you're going to make this
a MUST, you've got to at least give a definition of "reasonably small" and
perhaps even "stable" in the context of this specification.  As it stands,
there's no test for whether the MUST is enforceable or understandable
between parties.

Nits:

General:

The use of capitalization of Node administrative tag varies throughout the
document.  It seems clear that you mean for it to be written as "Node
Administrative Tag" when referring to the name of sub-TLV.  For other uses,
I would suggest using "node administrative tag" (all lower case)
consistently.  Use that to replace "Node administrative tag".

Specific:

  Page 3, 1st paragraph after the labeled items at the top, 3rd sentence:
change the first "TLV" to "sub-TLV".

Page 3, Section 2, 2nd paragraph: append a comma after "another".

Page 3, Section 3, 1st paragraph, 1st sentence: change "a" before "IS-IS" to
"an".

Page 3, Section 3, 1st paragraph, 2nd sentence: change "Capablity" to
"CAPABILITY".

Page 3, Section 3, 1st paragraph, 3rd sentence: change "Operator" to "An
operator".  Change "diiferent" to "different".

Page 3, Section 3, 2nd paragraph, 1st sentence: insert "the" before "Node".

Page 3, Section 3, 2nd paragraph, 2nd sentence: change "topology specific"
to "topology-specific".  (That is to say, swap the space for a hyphen.)

Page 4, Section 3.1, Value definition: insert "node" before
"administrative".

Page 4, Section 4.1, 1st sentence: change "Node" to "node".  (See general
nit.)

Page 4, Section 4.1, 3rd sentence: delete the space after the slash and
before regulations.

Page 5, 3rd full paragraph, 4th sentence: delete the spaces after closing
parenthesis and the terminating period.

Page 6, Section 4.3, 1st paragraph, 2nd sentence: change "Node" to "node".
(See general nit.)  Change the first "TLVs" to "sub-TLVs".

Page 6, Section 4.3, 2nd paragraph, 2nd sentence: delete the space before
the comma.

Page 6, Section 5, 1st paragraph, 1st sentence: change "Node" to "node".
(See general nit.)

Page 6, Section 5, 1st paragraph, 4th sentence: change "Following" to "The
following".

Page 6, Section 5, 1st paragraph, 5th sentence: change "section-3" to
"section 3".

Page 7, Section 6, 2nd paragraph, the comma should be rejoined with the
closing parenthesis.

Page 7, Section 7, 1st paragraph, 3rd sentence: change "is" to "are".

Page 7, Section 8, 1st paragraph, 2nd sentence: delete "The" before "YANG".
With the change in the rest of the sentence, "The" becomes superfluous.

Page 8, Section 9: change "Capabality" to "CAPABILITY".



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

Re: [Gen-art] Gen-ART LC review of draft-ietf-isis-node-admin-tag-08

[Pushpasis Sarkar]

Hi Peter,

Please find comments inline..

Thanks and Regards,
-Pushpasis

On Tuesday 03 May 2016 10:07 AM, Peter Yee wrote:

Pushpasis,

See my replies below prefaced with PEY>.

Thanks.
-Peter

-Original Message-
From: Pushpasis Sarkar [mailto:pushpasis.i...@gmail.com]
Sent: Monday, May 02, 2016 10:35 AM
To: Peter Yee; draft-ietf-isis-node-admin-tag@ietf.org
Cc: gen-art@ietf.org; i...@ietf.org
Subject: Re: Gen-ART LC review of draft-ietf-isis-node-admin-tag-08

Hi Peter,

Once again many many thanks for the detailed review comments. Please find
few comments inline. Unless otherwise there is a counter-comment the comment
is accepted and will be addressed in the next version to be uploaded soon.

Thanks and Regards,
-Pushpasis

On 4/30/16 2:11 PM, Peter Yee wrote:

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 comment.  For background on Gen-ART, please see
the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Document: draft-ietf-isis-node-admin-tag-08
Reviewer: Peter Yee
Review Date: April 27, 2016
IETF LC End Date: April 29, 2016
IESG Telechat date: May 5, 2016

Summary: This draft is basically ready for publication as a Standards
Track RFC, but has some issues that should be fixed/considered before

publication.

[Ready with issues]

This draft defines a means to carry additional per-node administrative
tags with the IS-IS protocol.  These tags can be used along with local
policy to simplify the management of routing and path selection.  This
specification gives informative examples of such tag usage but does
not otherwise prescribe the meaning of the tags.

This review was generated prior to the release of draft -09 (but not
keyed in until April 29th), but many of the issues and nits noted
below remain in draft -09.  Obviously, some of my comments no longer
apply.  I'll address draft -09 specifically for the telechat review,
but you should look at the points here prior to that review to save
time.  Given that draft -09 substantially reduces Section 5, I've
removed my comments regarding that section as well as in a few other

places.

Major issues: None

Minor issues:

Page 4, last partial paragraph: the number 63 is given for the maximum
number of per-node administrative tags that can be carried in a sub-TLV.
Given the maximum length of a sub-TLV is 250 octets (and 2 octets are
otherwise used by type and length), I would argue that the correct
number here is 62 (62*4 = 248).  Also, I would delete the text starting at

"and".

In all cases, when more than 62 tags are used, a single sub-TLV will
not provide sufficient space.

[Pushpasis] AFAIK, maximum length of sub-TLV is 255 (because length field if
1 byte). If you take out 2 bytes for length and value, we have
253 bytes left.. 253 divided by 4byte = 63 (63x4=252).. Let me know if my
understanding is wrong.

PEY>RFC 4971 (Section 2) gives this text: "Set of optional sub-TLVs (0-250
octets)".  My interpretation was that the Router CAPABILITY TLV can have a
length of 5-255 octets, of which 4 are the router ID and 1 is the flags,
leaving up to 250 octets for the sub-TLVs.
[PS2] You are totally right.. I overlooked the structure of the Rtr Cap 
Tlv itself. I will make the changes.

Page 5, 1st partial paragraph, 1st full sentence: Sub-TLV values are
given here as cumulative.  Is there any need or desire to be able to
subtract tags?  How would a router disassociate itself from a tag that
was no longer relevant to the router?  This ability is implied in
Section 4.3, 2nd paragraph, but that conflicts with the statement
given here.  In general, I believe the ability to reset the flooded
tags associated with a router or to delete a tag is underspecified.

[Pushpasis] Assuming the comment is on the following sentence..
"Such occurrence of the 'Node
 Administrative Tag' sub-TLV does not cancel previous announcements,
 but rather is cumulative."

The reference here to "previous announcements" is not the ones received in
the previous instances of the same LSP fragment but to the ones received in
other TLVs in same or different LSP fragments originated by the same
router... What it essentially mean is that if a router originates 3
node-admin-tag TLVs in three different LSP fragments.. the later ones do not
cancel/override the previous ones but are rather considered all together..
in an additive manner.. Perhaps I will add a line or two clarify the same..
I also see RFC has altogether removed the stanza in the final RFC
edition.. Will that be fine too with you for this draft?

PEY> Alignment with RFC  makes sense, given that the general concept is
to do the same thing for each of the routing protocols.

Alternatively, I can propose the fo

Re: [Gen-art] Gen-ART LC review of draft-ietf-isis-node-admin-tag-08

[Pushpasis Sarkar]

Hi Peter,

Once again many many thanks for the detailed review comments. Please 
find few comments inline. Unless otherwise there is a counter-comment 
the comment is accepted and will be addressed in the next version to be 
uploaded soon.


Thanks and Regards,
-Pushpasis

On 4/30/16 2:11 PM, Peter Yee wrote:

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
comment.  For background on Gen-ART, please see the FAQ at


Document: draft-ietf-isis-node-admin-tag-08
Reviewer: Peter Yee
Review Date: April 27, 2016
IETF LC End Date: April 29, 2016
IESG Telechat date: May 5, 2016

Summary: This draft is basically ready for publication as a Standards Track
RFC, but has some issues that should be fixed/considered before publication.
[Ready with issues]

This draft defines a means to carry additional per-node administrative tags
with the IS-IS protocol.  These tags can be used along with local policy to
simplify the management of routing and path selection.  This specification
gives informative examples of such tag usage but does not otherwise
prescribe the meaning of the tags.

This review was generated prior to the release of draft -09 (but not keyed
in until April 29th), but many of the issues and nits noted below remain in
draft -09.  Obviously, some of my comments no longer apply.  I'll address
draft -09 specifically for the telechat review, but you should look at the
points here prior to that review to save time.  Given that draft -09
substantially reduces Section 5, I've removed my comments regarding that
section as well as in a few other places.

Major issues: None

Minor issues:

Page 4, last partial paragraph: the number 63 is given for the maximum
number of per-node administrative tags that can be carried in a sub-TLV.
Given the maximum length of a sub-TLV is 250 octets (and 2 octets are
otherwise used by type and length), I would argue that the correct number
here is 62 (62*4 = 248).  Also, I would delete the text starting at "and".
In all cases, when more than 62 tags are used, a single sub-TLV will not
provide sufficient space.
[Pushpasis] AFAIK, maximum length of sub-TLV is 255 (because length 
field if 1 byte). If you take out 2 bytes for length and value, we have 
253 bytes left.. 253 divided by 4byte = 63 (63x4=252).. Let me know if 
my understanding is wrong.


Page 5, 1st partial paragraph, 1st full sentence: Sub-TLV values are given
here as cumulative.  Is there any need or desire to be able to subtract
tags?  How would a router disassociate itself from a tag that was no longer
relevant to the router?  This ability is implied in Section 4.3, 2nd
paragraph, but that conflicts with the statement given here.  In general, I
believe the ability to reset the flooded tags associated with a router or to
delete a tag is underspecified.

[Pushpasis] Assuming the comment is on the following sentence..
"Such occurrence of the 'Node
   Administrative Tag' sub-TLV does not cancel previous announcements,
   but rather is cumulative."

The reference here to "previous announcements" is not the ones received 
in the previous instances of the same LSP fragment but to the ones 
received in other TLVs in same or different LSP fragments originated by 
the same router... What it essentially mean is that if a router 
originates 3 node-admin-tag TLVs in three different LSP fragments.. the 
later ones do not cancel/override the previous ones but are rather 
considered all together.. in an additive manner.. Perhaps I will add a 
line or two clarify the same.. I also see RFC has altogether removed 
the stanza in the final RFC edition.. Will that be fine too with you for 
this draft?


Alternatively, I can propose the following clarifying text... If it 
makes any sense to you :)


"Such occurrence of a
'Node Administrative Tag' sub-TLV, found in a LSP fragment received 
recently, does not cancel
the one(s) received in any recent versions of other LSP fragments 
originated by the same
router. Instead, all the 'Node Administrative Tag' sub-TLVs found 
in all the LSP fragments
originated by the same originating router, should be treated as 
cumulative."




Page 6, 1st partial paragraph, 1st sentence: Care to define "reasonably
small"?  Previously, the ability to send more than 63 (or perhaps 62, see
above) tags was specified in section 3.1.  What's the limit to
reasonableness?  (Not that an exact number seems to matter at all for the
purposes of this specification, which is agnostic to the specific number or
the use of the tags.)
[Pushpasis] I see the only way to resolve this comment is by removing 
the stanza being referred to in the last comment..


Page 6, Section 4.3, 2nd paragraph: This paragraph implies that a large set
(greater than 62 at least) of sub-TLVs will have to 

Re: [Gen-art] Gen-ART LC review of draft-ietf-isis-node-admin-tag-08

[Pushpasis Sarkar]

Hi Peter,

Thanks a lot for the comments. I will address them soon in the next version.

Best Regards,
-Pushpasis

On Saturday 30 April 2016 02:11 PM, Peter Yee wrote:

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
comment.  For background on Gen-ART, please see the FAQ at


Document: draft-ietf-isis-node-admin-tag-08
Reviewer: Peter Yee
Review Date: April 27, 2016
IETF LC End Date: April 29, 2016
IESG Telechat date: May 5, 2016

Summary: This draft is basically ready for publication as a Standards Track
RFC, but has some issues that should be fixed/considered before publication.
[Ready with issues]

This draft defines a means to carry additional per-node administrative tags
with the IS-IS protocol.  These tags can be used along with local policy to
simplify the management of routing and path selection.  This specification
gives informative examples of such tag usage but does not otherwise
prescribe the meaning of the tags.

This review was generated prior to the release of draft -09 (but not keyed
in until April 29th), but many of the issues and nits noted below remain in
draft -09.  Obviously, some of my comments no longer apply.  I'll address
draft -09 specifically for the telechat review, but you should look at the
points here prior to that review to save time.  Given that draft -09
substantially reduces Section 5, I've removed my comments regarding that
section as well as in a few other places.

Major issues: None

Minor issues:

Page 4, last partial paragraph: the number 63 is given for the maximum
number of per-node administrative tags that can be carried in a sub-TLV.
Given the maximum length of a sub-TLV is 250 octets (and 2 octets are
otherwise used by type and length), I would argue that the correct number
here is 62 (62*4 = 248).  Also, I would delete the text starting at "and".
In all cases, when more than 62 tags are used, a single sub-TLV will not
provide sufficient space.

Page 5, 1st partial paragraph, 1st full sentence: Sub-TLV values are given
here as cumulative.  Is there any need or desire to be able to subtract
tags?  How would a router disassociate itself from a tag that was no longer
relevant to the router?  This ability is implied in Section 4.3, 2nd
paragraph, but that conflicts with the statement given here.  In general, I
believe the ability to reset the flooded tags associated with a router or to
delete a tag is underspecified.

Page 6, 1st partial paragraph, 1st sentence: Care to define "reasonably
small"?  Previously, the ability to send more than 63 (or perhaps 62, see
above) tags was specified in section 3.1.  What's the limit to
reasonableness?  (Not that an exact number seems to matter at all for the
purposes of this specification, which is agnostic to the specific number or
the use of the tags.)

Page 6, Section 4.3, 2nd paragraph: This paragraph implies that a large set
(greater than 62 at least) of sub-TLVs will have to be sent in multiple
Router CAPABILITY TLVs and those TLVs must(?) occur in a single Link-State
PDU.  Or how is the receiving router to know that it has the complete set of
tags?  Also, the implication seems to be that while section 3.1 indicates a
strictly cumulative capability, there must be someway of terminating those
cumulative changes and allowing a reset.  What is that signaling mechanism?

Nits:

General:

The use of capitalization of Per-node administrative tag varies throughout
the document.  It seems clear that you mean for it to be written as
"Per-node Administrative Tag" when referring to the name of sub-TLV.  For
other uses, I would suggest using "per-node administrative tag"
consistently.  Use that to replace "Per-node administrative tag".

Separate parenthetical elements from the preceding and following words with
a space.  These aren't function calls. ;-)

Replace any use of "per-node admin tag" with "per-node administrative tag".
The shortening is fine for the document header which would otherwise become
unreadable.

And change all of my references to "per-node" to "node", since draft -09
drops the "per-". :-)

Replace "TLV 242" with "the Router CAPABILITY TLV".

Specific:

  Page 1, Abstract:  delete the first comma in the Abstract.

Page 3, first paragraph after the lettered items, 3rd sentence: insert "the"
before "Router".

Page 3, Section 2, 1st sentence: change "Tag" to "tag".

Page 3, Section 2, 3rd sentence: insert "a" before "certain".

Page  3, Section 3, 1st paragraph, 1st sentence: change "TLV-242" to "TLV
(IS-IS TLV type 242)" and delete the closing parenthesis after "[RFC4971".

Page 3, Section 3, 1st paragraph, 3rd sentence: change "the same" to "it".
Change "they" to "it".  Change "specfied" to "specified".  Insert "the"
before "originating".  Delete "the" before "other".

Page 3,