Subject: [Teas-ns-dt] Notes for today's NS-DT meeting

From: Eric Gray <[email-masked]>
Date: Mon, 10 Feb 2020 17:15:07 +0000

Are available at: https://etherpad.ietf.org/p/ns-dt-notes-feb10.

Please review these notes and either add to them anything we discussed at the meeting, or send comments to me.

Jari, later this week, could you push these to the GitHub repository at: https://github.com/teas-wg/teas-ns-dt/tree/master/notes (in md format, I guess)?

--
Eric

---

From: John E Drake <[email-masked]>
Date: Mon, 10 Feb 2020 17:24:51 +0000

Hi,

Wrt protection isolation, if you have dedicated 1+1 protection you still have the switchover time, so this is the minimum service interruption with hard isolation.  If you have packet switching (soft isolation) there are a range of technologies that provide a range of service disruption times.

Sent from my iPhone

On Feb 10, 2020, at 12:15 PM, Eric Gray <eric.gray=[email-masked]> wrote:

Are available at: https://etherpad.ietf.org/p/ns-dt-notes-feb10<https://urldefense.com/v3/__https://etherpad.ietf.org/p/ns-dt-notes-feb10__;!!NEt6yMaO-gk!R9MKmiaYXBuhuTZBYpZvNsiVYjnzH2xbzR2wZ5WPPMspWRsv7tVCr1efC9sXFr8$>.

--
Eric
--
Teas-ns-dt mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas-ns-dt__;!!NEt6yMaO-gk!R9MKmiaYXBuhuTZBYpZvNsiVYjnzH2xbzR2wZ5WPPMspWRsv7tVCr1efVwcxTqI$

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Feb 2020 18:44:32 +0000

Thanks for the notes! They are now also in GitHub at https://github.com/teas-wg/teas-ns-dt/blob/master/notes/notes-2020-02-10.md

If there are comments either Eric or me can take those into account and edit as needed.

Jari

---

From: Shunsuke Homma <[email-masked]>
Date: Tue, 11 Feb 2020 09:25:14 +0900

Thanks Eric and Jari for taking a note and uploaded it on the Github.

I gave some changes on the github. Please  check them, and  let me know if
my changes  are  wrong.
https://github.com/teas-wg/teas-ns-dt/commit/d9f8f7046246ba0c3658b8a2a01fcc1a5b8b0532

On Tue, Feb 11, 2020 at 3:44 AM Jari Arkko <jari.arkko=
[email-masked]> wrote:

> Thanks for the notes! They are now also in GitHub at
> https://github.com/teas-wg/teas-ns-dt/blob/master/notes/notes-2020-02-10.md
>
>
>
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 10 Feb 2020 19:13:14 -0800

Hi Eric,
I think there might be auto-complete being used that caused

There was little to know discussion of "reachability isolation.

s/know/no/?

Regards,
Greg

On Mon, Feb 10, 2020 at 9:15 AM Eric Gray <eric.gray=
[email-masked]> wrote:

> Jari, later this week, could you push these to the GitHub repository at:
> https://github.com/teas-wg/teas-ns-dt/tree/master/notes (in md format, I
> guess)?
>
>
>
> --
>
> Eric
> --
> Teas-ns-dt mailing list
> [email-masked]

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 11 Feb 2020 06:10:10 +0000

Hi Jari,

I added some notes to the meeting minutes yesterday, the pull request can be found at: https://github.com/teas-wg/teas-ns-dt/pull/7/commits/3ae186015bb022e8565647b3ee73ff9e65bda823

Thanks.

Best regards,
Jie

From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: Tuesday, February 11, 2020 2:45 AM
To: Eric Gray <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] Notes for today's NS-DT meeting

Jari

---

From: Eric Gray <[email-masked]>
Date: Mon, 17 Feb 2020 20:29:28 +0000

John,

              With 1+1 protection, the sender sends traffic on both the working and protection path, so quite often – while there is a “switchover time” – it is basically a “name-changing” event (the protection path becomes the working path, but nothing else changes without operator intervention) and it is quite often the case that no traffic is impacted.  In other words, the switchover time is irrelevant, as long as it is not so long that a second failure may occur before the switchover is reported to the operator.

              Note that the technology being defined in DetNet, uses packet replication and elimination, which is analogous to 1+1 protection in that sense.  In addition, 1+1 protection is defined for label switching as well.  In fact, 1+1 protection can be applied in any technology that allows for establishing diverse alternative paths.

              Hence, a choice to use packet-switching should be orthogonal to a choice to use 1+1 protection.  And none of these choices has very much to do with “isolation.”

              What you are probably referring to is a distinction between either 1+1 or 1:1, and 1:N or M:N protection – primarily because there is no dedicated protection path in either of the latter two cases.  Either there is 1 protection path for N working paths, or there are M protection paths for N working paths (where M is assumed to be less than N) in those cases, so a switchover may be non-trivial and (possibly) performance impacting.

              For example, not having a dedicated alternative path in the 1:N case means that – if two working path connections fail both will see performance degradation.  Similarly, for the M:N case, if M+1 out of the N working paths fail, the users for at least two of the failed paths will see some performance loss.

              But I fail to see how any of these are inherently cases involving “isolation.”

              One thing I have heard of is using the term “protection isolation” to mean isolation of alternative paths, ensuring that a single failure does not take more than one working or protection path down.  But this is (possibly) more commonly referred to as “shared risk avoidance.”

--
Eric

From: John E Drake <jdrake=[email-masked]>
Sent: Monday, February 10, 2020 12:25 PM
To: Eric Gray <[email-masked]>
Cc: [email-masked]; Jari Arkko <[email-masked]>
Subject: Re: [Teas-ns-dt] Notes for today's NS-DT meeting
Importance: High

Hi,

Sent from my iPhone

On Feb 10, 2020, at 12:15 PM, Eric Gray <eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>> wrote:

Are available at: https://etherpad.ietf.org/p/ns-dt-notes-feb10<https://protect2.fireeye.com/v1/url?k=4896fa91-141f5558-4896ba0a-0cc47ad93e1c-a95572c8cb9519ed&q=1&e=138ed022-c29c-4668-bda7-71975eb05cd5&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fetherpad.ietf.org%2Fp%2Fns-dt-notes-feb10__%3B%21%21NEt6yMaO-gk%21R9MKmiaYXBuhuTZBYpZvNsiVYjnzH2xbzR2wZ5WPPMspWRsv7tVCr1efC9sXFr8%24>.

Jari, later this week, could you push these to the GitHub repository at: https://github.com/teas-wg/teas-ns-dt/tree/master/notes<https://protect2.fireeye.com/v1/url?k=060f429c-5a86ed55-060f0207-0cc47ad93e1c-2d4397becaf63c66&q=1&e=138ed022-c29c-4668-bda7-71975eb05cd5&u=https%3A%2F%2Fgithub.com%2Fteas-wg%2Fteas-ns-dt%2Ftree%2Fmaster%2Fnotes> (in md format, I guess)?

--
Eric
--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas-ns-dt__;!!NEt6yMaO-gk!R9MKmiaYXBuhuTZBYpZvNsiVYjnzH2xbzR2wZ5WPPMspWRsv7tVCr1efVwcxTqI$<https://protect2.fireeye.com/v1/url?k=e6e8e9e1-ba614628-e6e8a97a-0cc47ad93e1c-b7c1747faaad98e8&q=1&e=138ed022-c29c-4668-bda7-71975eb05cd5&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-dt__%3B%21%21NEt6yMaO-gk%21R9MKmiaYXBuhuTZBYpZvNsiVYjnzH2xbzR2wZ5WPPMspWRsv7tVCr1efVwcxTqI%24>

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 18 Feb 2020 13:07:40 -0800

Eric,

I disagree with you, also reference to DetNet is not applicable here, they replicate because they follow TSN logic.
In general 1+1 (1:1) protection means that the secondary (protecting) path available is equal in its characteristics to the primary, whether they share fate is an additional property and could have many different semantics (from shared line-card to shared fiber duct).
It is very uncommon to send traffic on both, protected and protecting paths, often protecting path carries other traffic that would be pushed out based on priorities.
As a separate note - we need to discuss unidirectional vs bidirectional protection,  since they have different times to repair, in bidirectional case as long as return path has not been recovered forward path is considered down.

Cheers,
Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 18 Feb 2020 17:05:24 -0800

Hi Jeff,
I do agree with Eric's characterization of 1+1, m:n, and 1:n (1:1 being the
special case of the former). G.808.1 (attached) gives a good overview of
protection architectures and I think that we can use that as the foundation
and the dictionary when talking about protection in the network slicing.
For example, section 7.1 explains 1+1 protection as follows:

In the 1+1 architecture type, a protection transport entity is dedicated as
a backup facility to the
working transport entity with the normal traffic signal bridged onto the
protection transport entity at
the source endpoint of the protected domain. The normal traffic on working
and protection transport
entities is transmitted simultaneously to the sink endpoint of the
protected domain where a selection
between the working and protection transport entity is made,

The next section explains the architecture of 1:n protection scheme:

In the 1:n architecture type, a dedicated protection transport entity is a
shared backup facility for n
working transport entities. The bandwidth of the protection transport
entity should be allocated in
such a way that it may be possible to protect any of the n working
transport entities in case the
protection transport entity is available.

One of the differences between 1+1 and 1:n/1:1 is that in the latter the
protection path may be used to carry extra traffic given that it will be
affected when the working path fails or deemed degraded below a
pre-determined level.
On the second point, regarding differences in the protection and switchover
of unidirectional vs. bi-directional line, I believe that it is better to
address the bi-directional (viewed as a single object) and consider the
unidirectional protection as the special case of the former.

On Tue, Feb 18, 2020 at 1:08 PM Jeff Tantsura <[email-masked]>
wrote:

> In general 1+1 (1:1) protection means that the secondary (protecting) path
> available is equal in its characteristics to the primary, whether they
> share fate is an additional property and could have many different
> semantics (from shared line-card to shared fiber duct).
> It is very uncommon to send traffic on both, protected and protecting
> paths, often protecting path carries other traffic that would be pushed out
> based on priorities.
> As a separate note - we need to discuss unidirectional vs bidirectional
> protection,  since they have different times to repair, in bidirectional
> case as long as return path has not been recovered forward path is
> considered down.
>
> Cheers,
> Jeff
>               With 1+1 protection, the sender sends traffic on both the
> working and protection path, so quite often – while there is a “switchover
> time” – it is basically a “name-changing” event (the protection path
> becomes the working path, but nothing else changes without operator
> intervention) and it is quite often the case that no traffic is impacted.
> In other words, the switchover time is irrelevant, as long as it is not so
> long that a second failure may occur before the switchover is reported to
> the operator.
>
>
>
>               Note that the technology being defined in DetNet, uses
> packet replication and elimination, which is analogous to 1+1 protection in
> that sense.  In addition, 1+1 protection is defined for label switching as
> well.  In fact, 1+1 protection can be applied in any technology that allows
> for establishing diverse alternative paths.
>
>
>
>               Hence, a choice to use packet-switching should be orthogonal
> to a choice to use 1+1 protection.  And none of these choices has very much
> to do with “isolation.”
>
>
>
>               What you are probably referring to is a distinction between
> either 1+1 or 1:1, and 1:N or M:N protection – primarily because there is
> no dedicated protection path in either of the latter two cases.  Either
> there is 1 protection path for N working paths, or there are M protection
> paths for N working paths (where M is assumed to be less than N) in those
> cases, so a switchover may be non-trivial and (possibly) performance
> impacting.
>
>
>
>               For example, not having a dedicated alternative path in the
> 1:N case means that – if two working path connections fail both will see
> performance degradation.  Similarly, for the M:N case, if M+1 out of the N
> working paths fail, the users for at least two of the failed paths will see
> some performance loss.
>
>
>
>               One thing I have heard of is using the term “protection
> isolation” to mean isolation of alternative paths, ensuring that a single
> failure does not take more than one working or protection path down.  But
> this is (possibly) more commonly referred to as “shared risk avoidance.”
>
>
>
> --
>
> Eric
>
>
>
> *From:* John E Drake <jdrake=[email-masked]>
> *Sent:* Monday, February 10, 2020 12:25 PM
> *To:* Eric Gray <[email-masked]>
> *Cc:* [email-masked]; Jari Arkko <[email-masked]>
> *Subject:* Re: [Teas-ns-dt] Notes for today's NS-DT meeting
> *Importance:* High
>
>
>
> Hi,
>
>
>
> Wrt protection isolation, if you have dedicated 1+1 protection you still
> have the switchover time, so this is the minimum service interruption with
> hard isolation.  If you have packet switching (soft isolation) there are a
> range of technologies that provide a range of service disruption times.
>
>
>
> Sent from my iPhone
>
>
>
> On Feb 10, 2020, at 12:15 PM, Eric Gray <
> eric.gray=[email-masked]> wrote:
>
> 
>
> Are available at: https://etherpad.ietf.org/p/ns-dt-notes-feb10
> <https://protect2.fireeye.com/v1/url?k=4896fa91-141f5558-4896ba0a-0cc47ad93e1c-a95572c8cb9519ed&q=1&e=138ed022-c29c-4668-bda7-71975eb05cd5&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fetherpad.ietf.org%2Fp%2Fns-dt-notes-feb10__%3B%21%21NEt6yMaO-gk%21R9MKmiaYXBuhuTZBYpZvNsiVYjnzH2xbzR2wZ5WPPMspWRsv7tVCr1efC9sXFr8%24>
> .
>
>
>
> https://github.com/teas-wg/teas-ns-dt/tree/master/notes
> <https://protect2.fireeye.com/v1/url?k=060f429c-5a86ed55-060f0207-0cc47ad93e1c-2d4397becaf63c66&q=1&e=138ed022-c29c-4668-bda7-71975eb05cd5&u=https%3A%2F%2Fgithub.com%2Fteas-wg%2Fteas-ns-dt%2Ftree%2Fmaster%2Fnotes>
> (in md format, I guess)?
>
>
>
> --
>
> Eric
>
> --
> Teas-ns-dt mailing list
> [email-masked]
>
> <https://protect2.fireeye.com/v1/url?k=e6e8e9e1-ba614628-e6e8a97a-0cc47ad93e1c-b7c1747faaad98e8&q=1&e=138ed022-c29c-4668-bda7-71975eb05cd5&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-dt__%3B%21%21NEt6yMaO-gk%21R9MKmiaYXBuhuTZBYpZvNsiVYjnzH2xbzR2wZ5WPPMspWRsv7tVCr1efVwcxTqI%24>
>
> --
> Teas-ns-dt mailing list
> [email-masked]

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 18 Feb 2020 18:29:31 -0800

Hi Greg,

My point was specifically to replication, the definitions are fine, however “dedicated” is perhaps applicable to optical networking but not to IP/MPLS.

Cheers,
Jeff
On Feb 18, 2020, 5:05 PM -0800, Greg Mirsky <[email-masked]>, wrote:
> Hi Jeff,
> I do agree with Eric's characterization of 1+1, m:n, and 1:n (1:1 being the special case of the former). G.808.1 (attached) gives a good overview of protection architectures and I think that we can use that as the foundation and the dictionary when talking about protection in the network slicing. For example, section 7.1 explains 1+1 protection as follows:
> > In the 1+1 architecture type, a protection transport entity is dedicated as a backup facility to the
> > working transport entity with the normal traffic signal bridged onto the protection transport entity at
> > the source endpoint of the protected domain. The normal traffic on working and protection transport
> > entities is transmitted simultaneously to the sink endpoint of the protected domain where a selection
> > In the 1:n architecture type, a dedicated protection transport entity is a shared backup facility for n
> > working transport entities. The bandwidth of the protection transport entity should be allocated in
> > such a way that it may be possible to protect any of the n working transport entities in case the
> One of the differences between 1+1 and 1:n/1:1 is that in the latter the protection path may be used to carry extra traffic given that it will be affected when the working path fails or deemed degraded below a pre-determined level.
> On the second point, regarding differences in the protection and switchover of unidirectional vs. bi-directional line, I believe that it is better to address the bi-directional (viewed as a single object) and consider the unidirectional protection as the special case of the former.
>
> > On Tue, Feb 18, 2020 at 1:08 PM Jeff Tantsura <[email-masked]> wrote:
> > > Eric,
> > >

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 18 Feb 2020 20:01:04 -0800

Hi Jeff,
thank you for the clarification it helped a lot. I think that in IP/MPLS,
i.e. without the ability to signal an explicit path, e2e protection cannot
be realized but only local protection can be. I'd note that any protection
scheme, 1+1 or 1:n, is based on pre-computed and instantiated in the data
plane paths. Hence is the difference between protection and restoration,
which is based on the control plane and its convergence.

Regards,
Greg

On Tue, Feb 18, 2020 at 6:29 PM Jeff Tantsura <[email-masked]>
wrote:

> Hi Greg,
>
> My point was specifically to replication, the definitions are fine,
> however “dedicated” is perhaps applicable to optical networking but not
> to IP/MPLS.
>
> Cheers,
> Jeff
> I do agree with Eric's characterization of 1+1, m:n, and 1:n (1:1 being
> the special case of the former). G.808.1 (attached) gives a good overview
> of protection architectures and I think that we can use that as the
> foundation and the dictionary when talking about protection in the network
> slicing. For example, section 7.1 explains 1+1 protection as follows:
>
> On the second point, regarding differences in the protection and
> switchover of unidirectional vs. bi-directional line, I believe that it is
> better to address the bi-directional (viewed as a single object) and
> consider the unidirectional protection as the special case of the former.
>
>> I disagree with you, also reference to DetNet is not applicable here,
>> they replicate because they follow TSN logic.
>> In general 1+1 (1:1) protection means that the secondary (protecting)
>> path available is equal in its characteristics to the primary, whether they
>>               Hence, a choice to use packet-switching should be
>> orthogonal to a choice to use 1+1 protection.  And none of these choices
>> has very much to do with “isolation.”
>>
>>
>>

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 18 Feb 2020 20:32:33 -0800

Greg,

In RSVT-TE case the protecting path is indeed pre-signaled and instantiated in forwarding however enforcement is often done by other means (reservation is soft).
In SR-TE case behavior is defined hop-by-hop (SID->action mappings are local), enforcement is always done by other means.

Regards,
Jeff

> On Feb 18, 2020, at 20:01, Greg Mirsky <[email-masked]> wrote:
> 
> 
> Hi Jeff,
> thank you for the clarification it helped a lot. I think that in IP/MPLS, i.e. without the ability to signal an explicit path, e2e protection cannot be realized but only local protection can be. I'd note that any protection scheme, 1+1 or 1:n, is based on pre-computed and instantiated in the data plane paths. Hence is the difference between protection and restoration, which is based on the control plane and its convergence.
> 
> Regards,
> Greg
> 
>> On Tue, Feb 18, 2020 at 6:29 PM Jeff Tantsura <[email-masked]> wrote:
>> Hi Greg,
>>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 18 Feb 2020 20:52:25 -0800

H Jeff,
could you please clarify what is included in "enforcement"? Obviously,
protection depends on the failure detection mechanism. Also, a mechanism to
select working and protecting paths (could be centralized or distributed)
based on the configuration of the protection domain. Then, a protocol to
coordinate a switchover at the endpoints is necessary. Is that what is
included in the enforcement of protection?

Regards,
Greg

On Tue, Feb 18, 2020 at 8:32 PM Jeff Tantsura <[email-masked]>
wrote:

> Greg,
>
> In RSVT-TE case the protecting path is indeed pre-signaled and
> instantiated in forwarding however enforcement is often done by other means
> (reservation is soft).
> In SR-TE case behavior is defined hop-by-hop (SID->action mappings are
> local), enforcement is always done by other means.
>
> Regards,
> Jeff
>
>>>               What you are probably referring to is a distinction
>>> between either 1+1 or 1:1, and 1:N or M:N protection – primarily because
>>> there is no dedicated protection path in either of the latter two cases.
>>> Either there is 1 protection path for N working paths, or there are M
>>> protection paths for N working paths (where M is assumed to be less than N)
>>> in those cases, so a switchover may be non-trivial and (possibly)
>>> performance impacting.
>>>
>>>
>>>
>>>               For example, not having a dedicated alternative path in
>>> the 1:N case means that – if two working path connections fail both will
>>> see performance degradation.  Similarly, for the M:N case, if M+1 out of
>>> the N working paths fail, the users for at least two of the failed paths
>>> will see some performance loss.
>>>
>>>
>>>

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 20 Feb 2020 09:26:41 -0500

I'd agree with Eric on the following statement within the context of

> But I fail to see how any of these are inherently cases involving
“isolation.”

I'd say that the scope of the "isolation" is important when we mention the
"isolation". In the context of protection or recovery, the isolation is
used as a technique between links or paths, but all these links or paths
are "isolated" (or "disjoined") within the same customer's topology
(meaning that they are in the same slice). In the context of slicing, the
scope of "isolation" is between customers (or slices).

Thanks,
- Xufeng

On Tue, Feb 18, 2020 at 11:52 PM Greg Mirsky <[email-masked]> wrote:

>>>> Wrt protection isolation, if you have dedicated 1+1 protection you
>>>> still have the switchover time, so this is the minimum service interruption
>>>> with hard isolation.  If you have packet switching (soft isolation) there
>>>> are a range of technologies that provide a range of service disruption
>>>> times.
>>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>>
>>>>
>>>> Jari, later this week, could you push these to the GitHub repository
>>>> at: https://github.com/teas-wg/teas-ns-dt/tree/master/notes