Re: [Lsr] IPR Poll for "IS-IS TE Attributes per application" - draft-ietf-isis-te-app-06.txt (adding contributors)

[Ketan Talaulikar (ketant)]

Hello,

I am not aware of any IPR that applies to this draft.

Thanks,
Ketan

From: Acee Lindem (acee)
Sent: 11 April 2019 03:06
To: draft-ietf-isis-te-...@ietf.org; Ketan Talaulikar (ketant) 
; Acee Lindem (acee) ; Hannes Gredler 

Cc: lsr@ietf.org
Subject: IPR Poll for "IS-IS TE Attributes per application" - 
draft-ietf-isis-te-app-06.txt (adding contributors)

Authors, Contributors,

Are you aware of any IPR that applies to draft-ietf-isis-te-app-06.txt?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


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

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

[tony . li]

Hi Huaimo,

Thank you for the example, this helps a lot.  It’s clearer and I think it will 
help illuminate many things.  Of course, it also generates more questions.

In your algorithm you’re computing the full backup path to provide connectivity 
between the previously connected nodes (e.g., R0 - R2) and not just between the 
partitioned pieces of the FT.  In this case, you would enable both R1-R2 and 
R2-R9.  Yet, all of those nodes are still connected on the FT.  Isn’t this 
inefficient?  Moreover, since we’re enabling more flooding than is necessary, 
isn’t this somewhat risky?

If we look at we’re proposing in the draft, each of R0, R1, R2, and R3 would 
recognize that they have a neighbor that is not part of their partition.  They 
would then enable temporary flooding on R0 - R1 and R2 - R3.
Either link would seem to be sufficient.  Adding both is of course more risky, 
but without global coordination, it would be difficult to optimize further.

The latter approach still seems like a simpler and more efficient solution. 

Regards,
Tony


> On Apr 10, 2019, at 1:29 PM, Huaimo Chen  wrote:
> 
> Hi Tony,
>  
> Thank you very much for your comments and questions.
>  
> An example with Figures for computing a unique backup path for each failure 
> on FT and enabling temporary flooding on the backup path is illustrated in 
> the file attached. 
>  
> The algorithm/procedure is triggered when two or more failures on the FT 
> happen at almost the same time.
>  
> At first, for each of the failures, a deterministic backup path is computed. 
> For example, if the link between R0 and R2, and the link between R3 and R9 on 
> the FT failed at almost the same time, a backup path for link R0-R2 and a 
> backup path for link R3-R9 are computed.
>  
> And then, temporary flooding over the links on these backup paths are 
> enabled. These backup paths fix the FT split.
>  
> (Note: In this case, one of the backup paths may be redundant. This may be 
> optimized in the future if needed.)
>  
> For a failure on the FT (e.g., the failure of the link R0-R2, assume that 
> R0’s ID < R2’s ID) and two end nodes of the failure, a deterministic/unique 
> backup path from the (source) node with smaller ID (e.g., node R0) to the 
> (destination) node with larger ID (e.g., node R2) is computed by each node in 
> following steps:
>  
> 1.   Obtaining all the minimum hop count paths from the source to the 
> destination (e.g., from R0 to R2);
> 2.   If there is only one minimum hop count path, then this path is the 
> unique backup path; otherwise, from multiple backup paths, selecting the one 
> with the links having smaller or smallest remote node ID along the direction 
> from the destination to the source (e.g., from R2 to R0). Starting from the 
> destination node (e.g., node R2) of the backup paths, if there are multiple 
> links on the backup paths (i.e., there are two or more links attached to the 
> destination node on the backup paths), the link with the smaller or smallest 
> remote node ID is selected. From the remote node X (e.g., R1) of the link 
> selected, if there are multiple links on the backup paths (i.e., there are 
> two or more links attached to node X on the backup paths except for the link 
> between the destination and node X), the link with the smaller or smallest 
> remote node ID is selected. This process continues until the source node 
> (e.g., node R0) of the backup path is reached. We have a unique backup path 
> for the failure. 
>  
> A backup path for a failure is enabled for temporary flooding by every node 
> Rk on the backup path as follows:
> Rk adds its local links on the backup path to the FT temporarily if they are 
> not on the FT. (e.g., node R2 on the backup path R0-R1-R2 adds its local link 
> R2-R1 on the backup path to the FT temporarily since its local link R2-R1 is 
> not on the FT).
> (Note: any other nodes, which are not on the backup path, do not do anything).
>  
> The backup path connects the two end nodes of the failure on the FT. When the 
> FT is split by two or more failures on the FT, the backup paths for the 
> failures fix the FT split.
>  
> For discussions: one option (called option A) is that the algorithm/procedure 
> is triggered by one/any failure. Another option (called option B) is that the 
> algorithm/procedure is triggered by two or more failures happening at almost 
> the same time. Option B is the one described above. Option A seems simpler. 
> It fix the FT split by two or more failures. But for one failure, its work 
> may not be needed. 
>  
> Best Regards,
> Huaimo
> From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
> Sent: Tuesday, April 9, 2019 12:41 PM
> To: Huaimo Chen 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Min Links for Multiple Failures on Flooding Topology
>  
>  
> Hi Huaimo,
>  
> Thank you for your discussion.  Unfortunately, I (and apparently others) are 
> still not following you. We need you to be very 

Re: [Lsr] Working Group Last Call for "IS-IS TE Attributes per application" - draft-ietf-isis-te-app-06.txt (Corrected Author Alias)

[Jeff Tantsura]

Yes/support 

Regards,
Jeff

> On Apr 10, 2019, at 23:24, Acee Lindem (acee)  wrote:
> 
>  LSR Working Group,
>  
> This begins a two week  WG last call for the subject document. Please enter 
> your support or objection to the document before 12:00 AM (EDT) on Wednesday, 
> April 25th, 2019.
>  
> Thanks,
> Acee 
>  
>  
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-extensio

[Alvaro Retana]

On April 10, 2019 at 5:46:56 PM, Vigoureux, Martin (Nokia -
FR/Paris-Saclay) (martin.vigour...@nokia.com) wrote:

Martin:

Hi!

It looks to me that you don’t disagree with what is written in the draft
but rather with the fact that the draft may suggest that IGPs should do
things which are in fact not specified in the IGPs drafts. I think this
point covers 1.1 to 1.4

Assuming that I’m correct, I believe that in order to clear the
misunderstanding authors could simply remove the sentence: “IGPs with SR
extensions...are examples of MCCs.”.

…and probably clean up some other text, for example, §2.10.1
references I-D.ietf-isis-segment-routing-extensions specifically.

Bottom line, I think you’re right.

On 1.5. I don’t think there is a conflict. It does not contradict 8402. It
is not saying “An IGP Node-SID SHOULD NOT be associated with a prefix …”

The way I see it is that this is a belt and suspenders approach. The base
req says MUST NOT and this req says “check if this req is respected”.

I read this document as saying “check, but you may have reasons not to”…
 IMHO, there’s no reason to specify the behavior here again, if it’s
already specified in rfc8402.

Of course this is only my view. I expect authors to have their own.

I’m sure they will. ;-)

Thanks!

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

Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-extensio

[Vigoureux, Martin (Nokia - FR/Paris-Saclay)]

Alvaro,

Thanks for your review. I’m not sure whether I should reply here or on the 
iesg’s list.
It looks to me that you don’t disagree with what is written in the draft but 
rather with the fact that the draft may suggest that IGPs should do things 
which are in fact not specified in the IGPs drafts. I think this point covers 
1.1 to 1.4
Assuming that I’m correct, I believe that in order to clear the 
misunderstanding authors could simply remove the sentence: “IGPs with SR 
extensions...are examples of MCCs.”.

On 1.5. I don’t think there is a conflict. It does not contradict 8402. It is 
not saying “An IGP Node-SID SHOULD NOT be associated with a prefix …”
The way I see it is that this is a belt and suspenders approach. The base req 
says MUST NOT and this req says “check if this req is respected”.

Of course this is only my view. I expect authors to have their own.

-m


From: Alvaro Retana 
Sent: Wednesday, April 10, 2019 22:31
To: draft-ietf-spring-segment-routing-mpls@ietf.org; 
draft-ietf-ospf-segment-routing-extensions@ietf.org; 
draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org; 
draft-ietf-isis-segment-routing-extensions@ietf.org
Cc: SPRING WG ; lsr@ietf.org
Subject: Fwd: Alvaro Retana's Discuss on 
draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) 
(draft-ietf-ospf-segment-routing-extensions / 
draft-ietf-ospf-ospfv3-segment-routing-extensions / 
draft-ietf-isis-segment-routing-extensions)

Hi!

I just entered a DISCUSS position related to 
draft-ietf-spring-segment-routing-mpls (see below).  I believe that the issue 
needs to be solved in conjunction with the IGP extension drafts, so I’m copying 
the authors/shepherds/chairs here.

Thanks!

Alvaro.


On April 10, 2019 at 4:25:22 PM, Alvaro Retana via Datatracker 
(nore...@ietf.org) wrote:
--
DISCUSS:
--

(1) This first point is a cross-document DISCUSS. In short, the assumptions in
this document about what an MCC is responsible for are not in line with the
corresponding IGP drafts for OSPF [1][2] and IS-IS [3]. This misalignment must
be resolved before any of these documents are published.

[Note: I'll start a thread with the corresponding WGS, Authors, Shepherds,
Chairs and ADs. Let's please discuss this point there.]

This document uses the following definition in §2: "We call "MPLS Control Plane
Client (MCC)" any control plane entity installing forwarding entries in the
MPLS data plane. IGPs with SR extensions...are examples of MCCs."

The focus of the IGP drafts is on the transport of the SR information, and not
on other functions (see below). Which component is responsible for what is the
point that needs clarification -- either in this document, the IGP drafts, or
both.

These are some specific cases:

(1.1) §2.4 (Mapping a SID Index to an MPLS label): "The following rules MUST be
applied by the MCC when calculating the MPLS label value corresponding the SID
index value "I"." There's nothing in the IGP extension documents that point at
this set of rules, and only a passing reference in the OSPF documents about
outgoing labels.

(1.2) §2.5 (Incoming Label Collision) also assumes more functions from an MCC
than what the IGP documents do. For example: "Within an MCC, apply
tie-breaking rules to select one FEC only and assign the label to it."

(1.3) §2.8 also expects work by the IGPs: "the MCC is responsible for
downloading the correct label value to FIB"...in this case not just calculating
the label, but installing it in the FIB.

(1.4) §2.10.1: "The method by which the MCC on router "R0" determines that PUSH
or CONTINUE operation must be applied using the SID "Si" is beyond the scope of
this document. An example of a method to determine the SID "Si" for PUSH
operation is the case where IS-IS
[I-D.ietf-isis-segment-routing-extensions]..." Note that the IS-IS draft (or
the OSPF ones, for that matter) don't talk about how to determine the operation
-- if that is out of scope of this document, then where is it specified?

(1.5) From §2:

An implementation SHOULD check that an IGP node-SID is not associated
with a prefix that is owned by more than one router within the same
routing domain. If so, it SHOULD NOT use this Node-SID, MAY use
another one if available, and SHOULD log an error.

rfc8402 reads (§3.2): "An IGP Node-SID MUST NOT be associated with a prefix
that is owned by more than one router within the same routing domain." The
text above is not in line with that (MUST NOT vs SHOULD). Also, how can
"SHOULD check" be Normatively enforced?

Both sentences above seem to be trying to specify a behavior for the IGPs.

[1] https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions
[2]
https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions
[3] 

[Lsr] IPR Poll for "IS-IS TE Attributes per application" - draft-ietf-isis-te-app-06.txt (adding contributors)

[Acee Lindem (acee)]

Authors, Contributors,

Are you aware of any IPR that applies to draft-ietf-isis-te-app-06.txt?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


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

[Lsr] IPR Poll for "IS-IS TE Attributes per application" - draft-ietf-isis-te-app-06.txt

[Acee Lindem (acee)]

Authors,

Are you aware of any IPR that applies to draft-ietf-isis-te-app-06.txt?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


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

[Lsr] Working Group Last Call for "IS-IS TE Attributes per application" - draft-ietf-isis-te-app-06.txt (Corrected Author Alias)

[Acee Lindem (acee)]

 LSR Working Group,

This begins a two week  WG last call for the subject document. Please enter 
your support or objection to the document before 12:00 AM (EDT) on Wednesday, 
April 25th, 2019.

Thanks,
Acee


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

[Lsr] Working Group Last Call for "IS-IS TE Attributes per application" - draft-ietf-isis-te-app-06.txt

[Acee Lindem (acee)]

 LSR Working Group,

This begins a two week  WG last call for the subject document. Please enter 
your support or objection to the document before 12:00 AM (EDT) on Wednesday, 
April 25th, 2019.

Thanks,
Acee


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

[Lsr] Fwd: Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-extensi

[Alvaro Retana]

Hi!

I just entered a DISCUSS position related
to draft-ietf-spring-segment-routing-mpls (see below).  I believe that the
issue needs to be solved in conjunction with the IGP extension drafts, so
I’m copying the authors/shepherds/chairs here.

Thanks!

Alvaro.

On April 10, 2019 at 4:25:22 PM, Alvaro Retana via Datatracker (
nore...@ietf.org) wrote:

--
DISCUSS:
--

(1) This first point is a cross-document DISCUSS. In short, the assumptions
in
this document about what an MCC is responsible for are not in line with the
corresponding IGP drafts for OSPF [1][2] and IS-IS [3]. This misalignment
must
be resolved before any of these documents are published.

[Note: I'll start a thread with the corresponding WGS, Authors, Shepherds,
Chairs and ADs. Let's please discuss this point there.]

This document uses the following definition in §2: "We call "MPLS Control
Plane
Client (MCC)" any control plane entity installing forwarding entries in the
MPLS data plane. IGPs with SR extensions...are examples of MCCs."

The focus of the IGP drafts is on the transport of the SR information, and
not
on other functions (see below). Which component is responsible for what is
the
point that needs clarification -- either in this document, the IGP drafts,
or
both.

These are some specific cases:

(1.1) §2.4 (Mapping a SID Index to an MPLS label): "The following rules
MUST be
applied by the MCC when calculating the MPLS label value corresponding the
SID
index value "I"." There's nothing in the IGP extension documents that point
at
this set of rules, and only a passing reference in the OSPF documents about
outgoing labels.

(1.2) §2.5 (Incoming Label Collision) also assumes more functions from an
MCC
than what the IGP documents do. For example: "Within an MCC, apply
tie-breaking rules to select one FEC only and assign the label to it."

(1.3) §2.8 also expects work by the IGPs: "the MCC is responsible for
downloading the correct label value to FIB"...in this case not just
calculating
the label, but installing it in the FIB.

(1.4) §2.10.1: "The method by which the MCC on router "R0" determines that
PUSH
or CONTINUE operation must be applied using the SID "Si" is beyond the
scope of
this document. An example of a method to determine the SID "Si" for PUSH
operation is the case where IS-IS
[I-D.ietf-isis-segment-routing-extensions]..." Note that the IS-IS draft (or

the OSPF ones, for that matter) don't talk about how to determine the
operation
-- if that is out of scope of this document, then where is it specified?

(1.5) From §2:

An implementation SHOULD check that an IGP node-SID is not associated
with a prefix that is owned by more than one router within the same
routing domain. If so, it SHOULD NOT use this Node-SID, MAY use
another one if available, and SHOULD log an error.

rfc8402 reads (§3.2): "An IGP Node-SID MUST NOT be associated with a prefix
that is owned by more than one router within the same routing domain." The
text above is not in line with that (MUST NOT vs SHOULD). Also, how can
"SHOULD check" be Normatively enforced?

Both sentences above seem to be trying to specify a behavior for the IGPs.

[1] https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions
[2]
https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions

[3] https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Fwd: Open issues with Dynamic Flooding

[tony . li]

Hi Dave,

> So for my edification/education, this is a general behavior that in the 
> absence of any specific algorithm is postulated.  (?)


Yes.


> The piece I do not quite get is "adding until fixed".  Is the working 
> assumption that things have broken down to the point that there is no 
> synchronization of the topology and the repairs are "blind”?


Yes.  We are using a centralized algorithm and have had multiple near 
simultaneous failures that have partitioned the flooding topology. While the 
area leader can (and probably will) compute a new flooding topology that 
repairs everything, it cannot be easily distributed across the partition of the 
flooding topology.


> Hence "adding until fixed" is adding until IGP exchange appears to have  
> minimized the changes in the LSDB from some previous state of the FT or some 
> other criteria?  


Adding links temporarily to the FT should restore flooding, at which point an 
updated FT from the area leader can easily propagate.

Note that this is a convergence time issue: the new FT could slowly propagate, 
but it does require that each node at the partition unpack the new FT, install 
it, and then perform synchronization on the new links before proceeding.

Tony

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

Re: [Lsr] Fwd: Open issues with Dynamic Flooding

[David Allan I]

Hi Tony:

So for my edification/education, this is a general behavior that in the absence 
of any specific algorithm is postulated.  (?)

The piece I do not quite get is "adding until fixed".  Is the working 
assumption that things have broken down to the point that there is no 
synchronization of the topology and the repairs are "blind"? Hence "adding 
until fixed" is adding until IGP exchange appears to have  minimized the 
changes in the LSDB from some previous state of the FT or some other criteria?  

Just checking
Dave

-Original Message-
From: Lsr  On Behalf Of tony...@tony.li
Sent: Tuesday, April 9, 2019 12:13 PM
To: Huaimo Chen 
Cc: Les Ginsberg ; lsr@ietf.org
Subject: Re: [Lsr] Fwd: Open issues with Dynamic Flooding


Hi Huaimo,

>For "add temporary flooding in a rate limited manner", can you give some 
> details about how does the rate limit manner work for fixing a FT split?


Nodes that have adjacencies that appear to be crossing the FT partition can 
enable temporary flooding on that circuit. This will hopefully repair the 
partition.  If not, the node waits awhile, and then adds another link to the 
FT.  Iterate until healed.


> how does each node get the rate limit?


Rate limiting causes each node to do so ’slowly’, where the exact values for 
the rate limiting are implementation specific.


> Will every node add temporary flooding on a given number of links 
> independently?


No, not every node.  Only those that have an adjacency with a node that appears 
to not be on the FT.


> If so, there are lots of links to be added into the FT temporarily for fixing 
> the FT split.


Yes, because this is a distributed algorithm without any centralized 
coordination, you can easily imagine circumstances where there are many links 
that could repair the partition and thus many temporary additions could be 
made. This is why some feel that rate limiting is wise.


> This may cause some issues.


This may be an understatement. :-)

Tony

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


smime.p7s
Description: S/MIME cryptographic signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr