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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]>
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
>
> On Feb 18, 2020, at 20:01, Greg Mirsky <[e-mail]> 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 <[e-mail]>
> 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
>> On Feb 18, 2020, 5:05 PM -0800, Greg Mirsky <[e-mail]>,
>> 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
>> 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 <[e-mail]>
>> wrote:
>>
>>> 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
>>> On Feb 17, 2020, 12:29 PM -0800, Eric Gray <eric.gray=
>>> [e-mail]>, wrote:
>>>
>>> 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=[e-mail]>
>>> *Sent:* Monday, February 10, 2020 12:25 PM
>>> *To:* Eric Gray <[e-mail]>
>>> *Cc:* [e-mail]; Jari Arkko <[e-mail]>
>>> *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=[e-mail]> 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>
>>> .
>>>
>>>
>>>
>>> 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
>>> <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
>>> [e-mail]
>>>
>>> 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>
>>>
>>> --
>>> Teas-ns-dt mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>>>
>>> --
>>> Teas-ns-dt mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>>>
>>