Re: [Lsr] Alissa Cooper's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

[Alissa Cooper]

Thanks!
Alissa

> On May 21, 2020, at 3:51 AM, Peter Psenak  wrote:
> 
> Hi Alissa,
> 
> On 20/05/2020 21:57, Alissa Cooper via Datatracker wrote:
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-ospf-mpls-elc-13: No Objection
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/
>> --
>> COMMENT:
>> --
>> I wasn't clear on where the  thread ended up from the Gen-ART review, but I'm
>> nevertheless suggesting some text below to resolve the main sticking point.
>> OLD
>> If the router supports ELs on all of its interfaces, it SHOULD advertise the
>> ELC with every local host prefix it advertises in OSPF.
>> NEW
>> If the router supports ELs on all of its interfaces, it SHOULD advertise the
>> ELC with every local host prefix it advertises in OSPF. The absence of these
>> advertisements implies that advertisement of the ELC is not supported.
> 
> I added the suggested text, plus I added "OSPF" at the end. So the text is:
> 
> "If the router supports ELs on all of its interfaces, it SHOULD advertise the 
> ELC with every local host prefix it advertises in OSPF. The absence of these 
> advertisements implies that advertisement of the ELC is not supported in 
> OSPF."
> 
> I added similar text to ISIS ELC draft.
> 
> thanks,
> Peter
> 
>> Not sure if that matches the intent though.

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

[Lsr] Alissa Cooper's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

[Alissa Cooper via Datatracker]

Alissa Cooper has entered the following ballot position for
draft-ietf-ospf-mpls-elc-13: No Objection

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


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


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



--
COMMENT:
--

I wasn't clear on where the  thread ended up from the Gen-ART review, but I'm
nevertheless suggesting some text below to resolve the main sticking point.

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

NEW
If the router supports ELs on all of its interfaces, it SHOULD advertise the
ELC with every local host prefix it advertises in OSPF. The absence of these
advertisements implies that advertisement of the ELC is not supported.

Not sure if that matches the intent though.



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

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

[Alissa Cooper]

Mohit, thanks for your review. Acee, thanks for your responses. I entered a No 
Objection ballot.

Alissa


> On Apr 29, 2020, at 7:26 AM, Acee Lindem (acee) 
>  wrote:
> 
> Hi Mohit, 
>  
> From: Mohit Sethi M  >
> Date: Wednesday, April 29, 2020 at 2:29 AM
> To: Acee Lindem mailto:a...@cisco.com>>, "gen-...@ietf.org 
> " mailto:gen-...@ietf.org>>
> Cc: "lsr@ietf.org "  >, "draft-ietf-isis-mpls-elc@ietf.org 
> " 
>  >, "last-c...@ietf.org 
> " mailto:last-c...@ietf.org>>
> Subject: Re: Genart last call review of draft-ietf-isis-mpls-elc-11
>  
> HI Acee,
> 
> On 4/24/20 3:38 PM, Acee Lindem (acee) wrote:
>> Hi Mohit,
>>  
>> Speaking as document shepherd. See inline. 
>>  
>> On 4/24/20, 3:39 AM, "Mohit Sethi via Datatracker"  
>>  wrote:
>>  
>> Reviewer: Mohit Sethi
>> 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-mpls-elc-11
>> Reviewer: Mohit Sethi
>> Review Date: 2020-04-24
>> IETF LC End Date: 2020-05-05
>> IESG Telechat date: Not scheduled for a telechat
>>  
>> Summary: This document specifies how Entropy Label Capability (ELC) and 
>> Entropy
>> Readable Label Depth (ERLD) are advertised using IS-IS. For advertising 
>> ELC, a
>> flag in the Prefix Attribute Flags is used. For advertising ERLD, a Node 
>> MSD
>> Advertisement is used.
>>  
>> Major issues:
>>  
>> Minor issues: The document is short and straightforward. For someone 
>> like me
>> who is not familiar with the routing area, would it make sense to 
>> explain why
>> signalling ELC information with MPLS is not sufficient (or what are the
>> benefits of advertising with IS-IS)?
>>  
>> I guess I'm wondering what you mean "signaling ELC information with MPLS"? 
>> With segment routing, the IGPs can be the only choice for signaling ELC 
>> capability. I don’t believe this comment requires any action. 
> I hope that you don't expect a gen-art reviewer to be an expert on every 
> topic. I certainly am NOT on expert on routing. I interpreted the following 
> text in the draft:
> 
>> It also
>>introduces the concept of Entropy Label Capability (ELC) and defines
>>the signaling of this capability via MPLS signaling protocols.
> to imply that signaling ELC information with MPLS is possible but this draft 
> defines a mechanism for signaling the same information with IS-IS. Maybe the 
> need for this is very obvious for those in the routing domain in which case 
> ignoring my comment is perfectly fine. 
>  
> Even though you are not an expert on routing, you should realize that “with 
> MPLS” and “via MPLS signaling protocols” have very different connotations. If 
> you reference section 3 of the reference document [RFC6790], you’ll the MPLS 
> signaling protocols currently supporting ELC signaling. As I stated 
> previously, with segment routing none of these protocols are required for 
> deployment.
>  
> Thanks,
> Acee
> --Mohit
> 
>>  
>> Thanks,
>> Acee
>>  
>>  
>> Nits/editorial comments:
>>  
>> In section 3, "used as the ECL  Flag" should perhaps be "used as the ELC 
>> Flag"?
>> In section 4, "IANA for EARLD-MSD" should perhaps be "IANA for ERLD-MSD"?
>> In section 6, "ECL Flag (E-flag)." should perhaps be "ELC Flag 
>> (E-flag)."?
>>  
>>  
>>  
> ___
> Gen-art mailing list
> gen-...@ietf.org 
> https://www.ietf.org/mailman/listinfo/gen-art 
> 

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

Re: [Lsr] [Gen-art] Genart last call review of draft-ietf-ospf-ospfv2-hbit-10

[Alissa Cooper]

Mohit, thanks for your review. Authors, thanks for your responses. I entered a 
No Objection ballot.

Alissa

> On Oct 31, 2019, at 4:08 AM, Mohit Sethi via Datatracker  
> wrote:
> 
> Reviewer: Mohit Sethi
> Review result: Ready
> 
> 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-ospf-ospfv2-hbit-10
> Reviewer: Mohit Sethi
> Review Date: 2019-10-31
> IETF LC End Date: 2019-11-07
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> This document uses a bit in the link state advertisement (LSA) sent from
> routers to indicate that they are hosts which will not forward transit 
> traffic.
> The document is READY for publication.
> 
> Major issues:
> 
> Minor issues:
> I think the document would benefit from some more discussion on what happens 
> if
> a router that is repelling traffic is on the only path to some destinations?
> How is this handled? Is it fair to say that H-bit is only a best effort way of
> repelling traffic and does not guarantee that the transit traffic is actually
> interrupted?
> 
> Any reason that this is only done for OSPFv2 and not v3? Are there ways of
> achieving this functionality (of repelling transit traffic) already in v3?
> 
> Nits/editorial comments:
> - Please expand acronyms like NSSA and LSAs on first usage.
> - Abstract has stray " symbol.
> -  The list in the acknowledgements section could benefit from an Oxford 
> comma:
> Abhay Roy, David Ward, Burjiz Pithawala, and Michael Barnes for their 
> comments.
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [Lsr] [Gen-art] Genart last call review of draft-ietf-isis-yang-isis-cfg-37

[Alissa Cooper]

Stewart, thanks for your review. Acee, thanks for your response. I entered a No 
Objection ballot.

Alissa


> On Sep 20, 2019, at 3:22 PM, Acee Lindem (acee)  wrote:
> 
> Thanks Stewart - we will fix this nit in the -38 version. 
> Acee
> 
> On 9/18/19, 10:14 AM, "Stewart Bryant via Datatracker"  
> wrote:
> 
>Reviewer: Stewart Bryant
>Review result: Ready
> 
>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-yang-isis-cfg-??
>Reviewer: Stewart Bryant
>Review Date: 2019-09-18
>IETF LC End Date: 2019-09-23
>IESG Telechat date: Not scheduled for a telechat
> 
>Summary: A true magnum opus. Well written and from a GENART point of view 
> ready
>to be published. I have not checked the YANG syntax, and have only checked 
> that
>the configuration symantics look plausible. I assume that specalist YANG 
> and
>Routing reviewers will look at that detail.
> 
>Major issues: None
> 
>Minor issues: None
> 
>Nits/editorial comments:
>   This document defines a YANG data model that can be used to configure
>   and manage IS-IS protocol on network elements.
> 
>SB> s/manage/manage the/
> 
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

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

[Alissa Cooper]

Russ, thanks for your review. Les, thanks for addressing the review comments. I 
entered a No Objection ballot.

Alissa


> On Aug 16, 2019, at 5:05 PM, Russ Housley  wrote:
> 
>>> 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
> 
> Cool.
> 
>>> 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.
> 
> Sure.  That makes sense.
> 
>>> 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.
> 
> I just fetched the -05 version.  The revised paragraph looks good to me.
> 
> Russ
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [Lsr] Alissa Cooper's No Objection on draft-ietf-ospf-yang-26: (with COMMENT)

[Alissa Cooper]

Hi Acee,

> On Aug 21, 2019, at 1:01 PM, Acee Lindem (acee)  wrote:
> 
> Hi Alissa,
> 
> On 8/21/19, 9:29 AM, "Alissa Cooper via Datatracker"  
> wrote:
> 
>Alissa Cooper has entered the following ballot position for
>draft-ietf-ospf-yang-26: No Objection
> 
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
> 
> 
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
> 
> 
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/
> 
> 
> 
>--
>COMMENT:
>--
> 
>Per the Gen-ART review, I think 2.3 may be a little clearer if it were to 
> say
>"The field 'version' is used to indicate the OSPF LSA version and is 
> mandatory."
> 
> This change has already been made in response to the Gen-ART review.

My specific suggestion was to include “LSA” after “OSPF” since that seemed to 
be the source of the confusion.

Best,
Alissa

> 
> 2.3.  OSPFv2 and OSPFv3
> 
>   The data model defined herein supports both OSPFv2 and OSPFv3.
> 
>   The field 'version' is used to indicate the OSPF version and is
>   mandatory.  Based on the configured version, the data model varies to
>   accommodate the differences between OSPFv2 and OSPFv3.
> 
> Thanks,
> Acee
> 
>I did not review this entire document but I'm balloting based on the 
> Gen-ART
>review.
> 
> 
> 
> 

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

Re: [Lsr] [Gen-art] Genart last call review of draft-ietf-ospf-xaf-te-06

[Alissa Cooper]

Roni, thanks for your review. I entered a No Objection ballot.

Alissa


> On Jun 30, 2019, at 7:27 AM, Roni Even via Datatracker  
> wrote:
> 
> Reviewer: Roni Even
> Review result: Ready
> 
> 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-ospf-xaf-te-??
> Reviewer: Roni Even
> Review Date: 2019-06-30
> IETF LC End Date: 2019-07-11
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document is ready for publication as a standard track RFC
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

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

[Alissa Cooper]

Erik, thanks for your review. Les, thanks for the updates. I entered a No 
Objection ballot.

Alissa

> On Apr 18, 2019, at 12:26 AM, Les Ginsberg (ginsberg)  
> wrote:
> 
> 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-...@ietf.org
>> Cc: lsr@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-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

[Lsr] Alissa Cooper's No Objection on draft-ietf-lsr-isis-rfc7810bis-03: (with COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-lsr-isis-rfc7810bis-03: No Objection

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


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


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



--
COMMENT:
--

In section 13 it seems a little awkward to reference the "first version" and
"second version" of the document since they will be published with different
RFC numbers. Might be clearer to say RFC 7810 in the first instance and "this
document" in the second instance.


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

[Lsr] Alissa Cooper's No Objection on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-ospf-ospfv3-segment-routing-extensions-20: No Objection

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


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


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



--
COMMENT:
--

Please use the RFC 8147 boilerplate rather than the RFC 2119 boilerplate.


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

Re: [Lsr] [Gen-art] Genart last call review of draft-ietf-isis-reverse-metric-15

[Alissa Cooper]

Stewart, thanks for your review. Naiming, thanks for your responses. I have 
entered a No Objection ballot.

Alissa

> On Oct 21, 2018, at 5:21 PM, Naiming Shen (naiming)  wrote:
> 
> 
> Hi Stewart,
> 
> Thanks for detailed review and comments, please see some
> replies inline. the modified version diff is attached, please reivew.
> 
> thanks.
> - Naiming
> 
> 
> 
>> On Oct 17, 2018, at 8:59 AM, Stewart Bryant  wrote:
>> 
>> Reviewer: Stewart Bryant
>> 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-reverse-metric-15
>> Reviewer: Stewart Bryant
>> Review Date: 2018-10-17
>> IETF LC End Date: 2018-10-17
>> IESG Telechat date: 2018-11-21
>> 
>> Summary: Generally a well written document, but some earlier text on what a
>> reverse metric is and what it does would be very helpful to the reader. Also
>> the reader is left with the impression that the use of this gives disruption
>> free network changes, and yet it does not discuss microloops.
>> 
>> Major issues: None
>> 
>> Minor issues:
>> 1.2.  Distributed Forwarding Planes
>> 
>> 
>> Temporarily signaling
>>  the 'Reverse Metric' over this link to discourage the traffic via the
>> 
>> SB> I know it's always chicken and egg, but it would be useful if a
>> SB> clearer definition of reverse metric were provided before you
>> SB> explained its use.
> 
>  I have added a paragraph at the beginning of the Introduction section
> 
>> 
>>  corresponding line-card will help to reduce the traffic loss in the
>>  network.  In the meantime, the remote PE routers will select a
>>  different set of PE routers for the BGP best path calculation or use
>>  a different link towards the same PE router on which a line-card is
>>  resetting.
>> 
>> SB> Remember that when you change paths you have to deal with
>> SB> microloops.
> 
>  Well, this ‘reverse metric’ is just like a normal IS-IS metric change.
>  and microloops is implied. This document does not create new
>  condition or trying to address the issue. It assumes final convergence
>  state will be reached for the mentioned use cases.
> 
>> 
>> ===
>> 
>> 1.5.  IS-IS Reverse Metric
>> 
>>  This document uses the routing protocol itself as the transport
>>  mechanism to allow one IS-IS router to advertise a "reverse metric"
>>  in an IS-IS Hello (IIH) PDU to an adjacent node on a point-to-point
>>  or multi-access LAN link.  This would allow the provisioning to be
>>  performed only on a single node, setting a "reverse metric" on a link
>>  and have traffic bidirectionally shift away from that link gracefully
>>  to alternate, viable paths.
>> 
>> SB> Again you need to be much clearer what a reverse metric is before
>> SB> you cite the use cases and advantages.
> 
>  added a new paragraph.
> 
>> 
>> ===
>> 
>> 3.1.  Processing Changes to Default Metric
>> 
>>  It is important to use the same IS-IS metric type on both ends of the
>>  link and in the entire IS-IS area or level.
>> 
>> SB> Isn't the point about links redundant given that it needs to be the
>> SB> same in the area/the level
> 
>   This sentence is talking about it does not deal with the case of
>  one side of the link uses IS-IS wide metric, but the other side
>  of the link uses a narrow metric. It is saying it’s broken and we
>  don’t support such a mixup, thus ‘reverse-metric’ also does not handle.
> 
>> 
>>  On the receiving side of
>>  the 'reverse-metric' TLV, the accumulated value of configured metric
>>  and the reverse-metric needs to be limited to 63 in "narrow" metric
>>  mode and to (2^24 - 2) in "wide" metric mode.
>>  This applies to both
>>  the Default Metric of Extended IS Reachability TLV and the Traffic
>>  Engineering Default Metric sub-TLV in LSP or Pseudonode LSP for the
>>  "wide" metric mode case.  If the "U" bit is present in the flags, the
>>  accumulated metric value is to be limited to (2^24 - 1) for both the
>>  normal link metric and Traffic Engineering metric in IS-IS "wide"
>>  metric mode.
>> 
>> SB> A clarifying note explaining the different usage of 2^24 - 1 and
>> SB> 2^24 - 2 would be helpful to the reader.
> 
>  Yes, added a sentence in the TLV definition part to describe them
>  in some detail.
> 
>> 
>> =
>> 3.2.  Multi-Topology IS-IS Support on Point-to-point links
>> 
>>  The Reverse Metric TLV is applicable to Multi-Topology IS-IS (M-ISIS)
>>  [RFC5120].  On point-to-point links, if an IS-IS router is configured
>>  for M-ISIS, it MUST send only a single Reverse Metric TLV in IIH PDUs
>>  toward its neighbor(s) on the designated link.
>> 
>> SB> Might you not want to use this on a topology by topology basis?
>> SB> For example you