Subject: Re: comments on draft-ietf-rtgwg-remote-lfa-05

From: Stewart Bryant <[email-masked]>
Date: Wed, 24 Sep 2014 18:52:54 +0100

Chris

I now have this as

Since normal link state routing takes into account the IS-IS overload bit,
[RFC6987] and costing out of links as described in [RFC5286], the forward
SPFs performed by the PLR rooted at the neighbors of the PLR also
need to take this into account. A repair tunnel path from a neighbor
of the PLR to a repair tunnel endpoint will generally avoid the nodes and
links excluded by the IGP overload/costing out rules. However, there
are two situations where this behavior may result in a repair path
traversing a link or router that should be excluded:

1. When the first hop on the repair tunnel path (from the PLR to
a direct neighbor) does not follow the IGP shortest path. In this
case, the PLR MUST NOT use a repair tunnel path whose first
hop is along a link whose cost or reverse cost is LSInfinity (for OSPF)
or the maximum cost (for IS-IS) or, has the overload bit set (for IS-IS)

2. The IS-IS overload bit and the mechanism of  [RFC6987]
only prevent transit traffic from traversing a node. They do
not prevent traffic destined to a node. The per-neighbor
forwards SPFs using the standard IGP overload rules will not
prevent a PLR from choosing a repair tunnel endpoint that is
advertising a desire to not carry transit traffic. Therefore, the
PLR MUST NOT use a repair tunnel endpoint with the IS-IS
overload bit set, or where all outgoing interfaces have the
cost set to LSInfinity for OSPF.

Please can you verify that I have not done anything bad in the
editing.

I am trying to figure out if I need more OSPF and ISIS refs. I could
argue that anyone that needs to implement this will know them
and anyone that needs the ref should not be implementing it :)
However I am not sure the IESG will agree :)

Stewart

On 30/05/2014 13:28, Stewart Bryant wrote:
> Chris
>
> I would like to take this together with final review coments
> from the WGCs
>
> Stewart
>
> On 28/05/2014 19:54, Chris Bowers wrote:
>>
>> See inline [CB] for comment on the new section 4.4.
>>
>> Chris
>>
>> *From:*Stewart Bryant [mailto:[email-masked]]
>> *Sent:* Friday, May 23, 2014 10:11 AM
>> *To:* Chris Bowers; [email-masked]
>> *Subject:* Re: comments on draft-ietf-rtgwg-remote-lfa-05
>>
>> On 23/05/2014 13:43, Chris Bowers wrote:
>>
>>     Authors,
>>
>>     Below are two comments on draft-ietf-rtgwg-remote-lfa-05.
>>
>>     1) A section should be added to the document clarifying what the
>>     expected behavior is for RLFA when routers advertise themselves
>>     as not desiring to carry transit traffic or links have been
>>     costed out.    RFC5286 has a useful section on this topic
>>     entitled "Interactions with IS-IS Overload, RFC 3137, and Costed
>>     Out Links". The current document would benefit from additional
>>     clarity in this topic.
>>
>> New section 4.4.
>>
>> The consideration concerning interactions with IS-IS Overload, 
>> [RFC3137],
>> and costed out links as described in [RFC5286] apply. In selecting a PQ
>> node a PLR MUST exclude any candidate that is reachable (including 
>> via ECMP)
>> from the PLR via a path subject to one of the above exclusions.
>> The method of determining the exclusion is a local matter.
>>
>> [CB] I think the following text explains the expected behavior more 
>> clearly.
>>
>> "Since normal IGP routing takes into account the IS-IS overload bit , 
>> RFC 3137, and costing out of links, the forward SPFs performed by the 
>> PLR rooted at neighbors of the PLR also need to take this into 
>> account.  Therefore a repair tunnel path from a neighbor of the PLR 
>> to a repair tunnel endpoint will generally avoid the nodes and links 
>> excluded by the IGP overload/costing out rules.  However, there are 
>> two situations where this behavior may result in a repair path 
>> traversing  a link or router that should be excluded.
>>
>> 1) The first hop on the repair tunnel path (from the PLR to a direct 
>> neighbor) does not necessarily follow the IGP shortest path.   
>> Therefore, the PLR MUST NOT use a repair tunnel path whose first hop 
>> is along a link whose cost or reverse cost is LSInfinity (for OSPF) 
>> or the maximum cost (for IS-IS) or, has the overload bit set (for 
>> IS-IS).
>>
>> 2) The IS-IS overload bit and the mechanism of RFC 3137 only prevent 
>> transit traffic from traversing a node.  It does not prevent traffic 
>> destined to a node.  So the per-neighbor forwards SPFs using standard 
>> IGP overload rules will not prevent  a PLR from choosing a repair 
>> tunnel endpoint that is advertising a desire to not carry transit 
>> traffic.  Therefore, the PLR MUST NOT use a repair tunnel endpoint 
>> with the IS-IS overload bit set (or all outgoing interfaces with cost 
>> set to LSInfinity for OSPF).  "
>>
>>     2) The current document doesn't appear to say anything about the
>>     expected behavior of RLFA when the IGP has multiple areas or
>>     levels.  It would be useful to either address this topic, or
>>     explicitly narrow the scope of the document to describing the
>>     behavior when the IGP has a single area or level.
>>
>> I have added to the bottom of the intro:
>>
>> This document considers the case when the repair path is confined to 
>> either a
>> single area or to the level two routing domain. In all other cases, 
>> the chosen
>> PQ node should be regarded as a tunnel adjacency of the repairing node,
>> and the considerations  described in Section 6 of [RFC5286] taken
>> into account.
>>
>> - Stewart
>>
>
>
> -- 
> For corporate legal information go to:
>
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 25 Sep 2014 19:35:22 +0000

[WG Chair hat off.]

Stewart:

Hi!

One of the things that we changed in rfc6987 wrt rfc3137 is a definition of a new architectural constant to avoid confusion on the interpretation of LSInfinity.  The new name is 'MaxLinkMetric', so please change that.

Also in –07, Section 4.4 still includes 'RFC 3137' in the title.

Thanks!

Alvaro.

On 9/24/14 1:52 PM, "Stewart Bryant (stbryant)" <[email-masked]<mailto:[email-masked]>> wrote:

Chris

I now have this as

Stewart

Stewart

Chris

From: Stewart Bryant [mailto:[email-masked]]
Sent: Friday, May 23, 2014 10:11 AM
To: Chris Bowers; [email-masked]<mailto:[email-masked]>
Subject: Re: comments on draft-ietf-rtgwg-remote-lfa-05

1) A section should be added to the document clarifying what the expected behavior is for RLFA when routers advertise themselves as not desiring to carry transit traffic or links have been costed out.    RFC5286 has a useful section on this topic entitled “Interactions with IS-IS Overload, RFC 3137, and Costed Out Links”.  The current document would benefit from additional clarity in this topic.
New section 4.4.

The consideration concerning interactions with IS-IS Overload, [RFC3137],
and costed out links as described in [RFC5286] apply. In selecting a PQ
node a PLR MUST exclude any candidate that is reachable (including via ECMP)
from the PLR via a path subject to one of the above exclusions.
The method of determining the exclusion is a local matter.

[CB] I think the following text explains the expected behavior more clearly.

“Since normal IGP routing takes into account the IS-IS overload bit , RFC 3137, and costing out of links, the forward SPFs performed by the PLR rooted at neighbors of the PLR also need to take this into account.  Therefore a repair tunnel path from a neighbor of the PLR to a repair tunnel endpoint will generally avoid the nodes and links excluded by the IGP overload/costing out rules.  However, there are two situations where this behavior may result in a repair path traversing  a link or router that should be excluded.

1) The first hop on the repair tunnel path (from the PLR to a direct neighbor) does not necessarily follow the IGP shortest path.   Therefore, the PLR MUST NOT use a repair tunnel path whose first hop is along a link whose cost or reverse cost is LSInfinity (for OSPF) or the maximum cost (for IS-IS) or, has the overload bit set (for IS-IS).

2) The IS-IS overload bit and the mechanism of RFC 3137 only prevent transit traffic from traversing a node.  It does not prevent traffic destined to a node.  So the per-neighbor forwards SPFs using standard IGP overload rules will not prevent  a PLR from choosing a repair tunnel endpoint that is advertising a desire to not carry transit traffic.  Therefore, the PLR MUST NOT use a repair tunnel endpoint with the IS-IS overload bit set (or all outgoing interfaces with cost set to LSInfinity for OSPF).  “

2) The current document doesn’t appear to say anything about the expected behavior of RLFA when the IGP has multiple areas or levels.  It would be useful to either address this topic, or explicitly narrow the scope of the document to describing the behavior when the IGP has a single area or level.
I have added to the bottom of the intro:

This document considers the case when the repair path is confined to either a
single area or to the level two routing domain. In all other cases, the chosen
PQ node should be regarded as a tunnel adjacency of the repairing node,
and the considerations  described in Section 6 of [RFC5286] taken
into account.

- Stewart

---

From: Chris Bowers <[email-masked]>
Date: Thu, 25 Sep 2014 23:00:58 +0000

Stewart,

In general it looks good.

The generic reference to RFC5286 in the first paragraph does not seem helpful to me. In my opinion, it should either be more specific or omitted.

In the third paragraph, "per-neighbor forwards SPFs"  should be "per-neighbor forward SPFs"  (an error in my original text).

Chris

From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, September 24, 2014 12:53 PM
To: Chris Bowers; [email-masked]
Subject: Re: comments on draft-ietf-rtgwg-remote-lfa-05

Chris

I now have this as

Stewart

Stewart

Chris

1) A section should be added to the document clarifying what the expected behavior is for RLFA when routers advertise themselves as not desiring to carry transit traffic or links have been costed out.    RFC5286 has a useful section on this topic entitled "Interactions with IS-IS Overload, RFC 3137, and Costed Out Links".  The current document would benefit from additional clarity in this topic.
New section 4.4.

"Since normal IGP routing takes into account the IS-IS overload bit , RFC 3137, and costing out of links, the forward SPFs performed by the PLR rooted at neighbors of the PLR also need to take this into account.  Therefore a repair tunnel path from a neighbor of the PLR to a repair tunnel endpoint will generally avoid the nodes and links excluded by the IGP overload/costing out rules.  However, there are two situations where this behavior may result in a repair path traversing  a link or router that should be excluded.

2) The IS-IS overload bit and the mechanism of RFC 3137 only prevent transit traffic from traversing a node.  It does not prevent traffic destined to a node.  So the per-neighbor forwards SPFs using standard IGP overload rules will not prevent  a PLR from choosing a repair tunnel endpoint that is advertising a desire to not carry transit traffic.  Therefore, the PLR MUST NOT use a repair tunnel endpoint with the IS-IS overload bit set (or all outgoing interfaces with cost set to LSInfinity for OSPF).  "

2) The current document doesn't appear to say anything about the expected behavior of RLFA when the IGP has multiple areas or levels.  It would be useful to either address this topic, or explicitly narrow the scope of the document to describing the behavior when the IGP has a single area or level.
I have added to the bottom of the intro:

- Stewart

--

--

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Sep 2014 17:53:34 +0100

On 26/09/2014 00:00, Chris Bowers wrote:
> The generic reference to RFC5286 in the first paragraph does not seem 
> helpful to me. In my opinion, it should either be more specific or 
> omitted.
>
Ref to Section 3.5
>
> In the third paragraph, “per-neighbor forwards SPFs”  should be 
> “per-neighbor forward SPFs”  (an error in my original text).
>
Done

Thanks

Stewart
> *Sent:* Wednesday, September 24, 2014 12:53 PM
>         *To:* Chris Bowers; [email-masked] <mailto:[email-masked]>
>             1) A section should be added to the document clarifying
>             what the expected behavior is for RLFA when routers
>             advertise themselves as not desiring to carry transit
>             traffic or links have been costed out. RFC5286 has a
>             useful section on this topic entitled “Interactions with
>             IS-IS Overload, RFC 3137, and Costed Out Links”.  The
>             current document would benefit from additional clarity in
>             this topic.
>
>         New section 4.4.
>
>         “Since normal IGP routing takes into account the IS-IS
>         overload bit , RFC 3137, and costing out of links, the forward
>         SPFs performed by the PLR rooted at neighbors of the PLR also
>         need to take this into account.  Therefore a repair tunnel
>         path from a neighbor of the PLR to a repair tunnel endpoint
>         will generally avoid the nodes and links excluded by the IGP
>         overload/costing out rules. However, there are two situations
>         where this behavior may result in a repair path traversing  a
>         link or router that should be excluded.
>
>         1) The first hop on the repair tunnel path (from the PLR to a
>         direct neighbor) does not necessarily follow the IGP shortest
>         path.   Therefore, the PLR MUST NOT use a repair tunnel path
>         whose first hop is along a link whose cost or reverse cost is
>         LSInfinity (for OSPF) or the maximum cost (for IS-IS) or, has
>         the overload bit set (for IS-IS).
>
>         2) The IS-IS overload bit and the mechanism of RFC 3137 only
>         prevent transit traffic from traversing a node.  It does not
>         prevent traffic destined to a node.  So the per-neighbor
>         forwards SPFs using standard IGP overload rules will not
>         advertising a desire to not carry transit traffic.  Therefore,
>         the PLR MUST NOT use a repair tunnel endpoint with the IS-IS
>         overload bit set (or all outgoing interfaces with cost set to
>         LSInfinity for OSPF).  “
>
>             2) The current document doesn’t appear to say anything
>             about the expected behavior of RLFA when the IGP has
>             multiple areas or levels.  It would be useful to either
>             address this topic, or explicitly narrow the scope of the
>             document to describing the behavior when the IGP has a
>             single area or level.
>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Sep 2014 17:54:24 +0100

Done.

Stewart

On 25/09/2014 20:35, Alvaro Retana (aretana) wrote:
> [WG Chair hat off.]
>
> Stewart:
>
> Hi!
>
> One of the things that we changed in rfc6987 wrt rfc3137 is a 
> definition of a new architectural constant to avoid confusion on the 
> interpretation of LSInfinity.  The new name is 'MaxLinkMetric', so 
> please change that.
>