Subject: Re: [mpls] Draft on Shared Mesh Protection

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 7 Dec 2011 13:57:57 -0600

Hi Dave, Greg-

  I think one thing that's missing from your proposal but which is in
the other shared mesh proposals is the ability to notify a node which
depends on the existence of a protection path that its protection path
is not available.  This capability exists in the other SMP proposals
currently floating around, as well as rfc4872.

  If you had two business classes, BC1 > BC2, if the LSPs in BC2 failed
and were using the protection path then the LSPs in BC1 failed and
needed to boot some or all of the BC2 LSPs from the protection domain,
how would that work?  Would an implementation continue to transmit both
BC1 and BC2 and let QoS sort it out?  

  Could you use something akin to soft preemption?  Perhaps a reserved
bit in the Fault Management message akin to AIS or LDI that said
"protection unavailable due to preemption" that would flow back to the
ultimate headend?

eric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> David Allan I
> Sent: Monday, November 28, 2011 12:52 PM
> To: [email-masked]
> Subject: [mpls] Draft on Shared Mesh Protection
> 
> I'd like to draw the WGs attention to "A framework for the use of
SPMEs for
> shared mesh protection"
> 
> http://datatracker.ietf.org/doc/draft-allan-spme-smp-fmwk/
> <http://datatracker.ietf.org/doc/draft-allan-spme-smp-fmwk/>
> 
> This differs from other proposals in this space in that it focuses on
> implementing business policy via packet level preemption vs. path
level
> preemption.
> 
> We believe there are a lot of operational and implementation
complexities
> that can be avoided with such an approach as it merely becomes a
planning
> exercise combined with existing kit.
> 
> The actual behavior is to degrade pre-empted services vs. completely
> blocking them as the selector is the SPME TC bits, and not a protocol.
> However the implication is there is no explicit notification to the
endpoints of
> preempted services that the degredation is happening. They would have
to
> infer this from PM or CC failure...
> 
> The authors would seek operator feedback on whether explicit
notification is
> a real requirement, noting that this goes hand in hand with "your
service has
> been completely preempted...". We would be similarly interested if
there is
> room for the WG to consider both approaches...
> 
> Much thanks
> Dave & Greg
> 
> 
>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 7 Dec 2011 21:16:40 -0500

Hi Eric,
Thank you for your interest in the proposal.
We view that monitoring of protection path availability is function of OAM. Either CC/CV, LM or more likely combination of both can be used to monitor the protection paths. If an explicit signalling in data plane to be used, then I'm concerned that because sizing of an SPME is arbitrary we ultimately might end up with re-implementing RSVP-TE signalling in the data plane.
I think that a section on cooperation between OAM and SMP with SPME can be added to the dociment.

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Osborne (eosborne)
Sent: Wednesday, December 07, 2011 11:58 AM
To: David Allan I; [email-masked]
Subject: Re: [mpls] Draft on Shared Mesh Protection

Hi Dave, Greg-

  I think one thing that's missing from your proposal but which is in the other shared mesh proposals is the ability to notify a node which depends on the existence of a protection path that its protection path is not available.  This capability exists in the other SMP proposals currently floating around, as well as rfc4872.

  If you had two business classes, BC1 > BC2, if the LSPs in BC2 failed and were using the protection path then the LSPs in BC1 failed and needed to boot some or all of the BC2 LSPs from the protection domain, how would that work?  Would an implementation continue to transmit both
BC1 and BC2 and let QoS sort it out?  

  Could you use something akin to soft preemption?  Perhaps a reserved bit in the Fault Management message akin to AIS or LDI that said "protection unavailable due to preemption" that would flow back to the ultimate headend?

eric

Of
SPMEs for
level
complexities
planning
endpoints of
to
notification is
service has
there is
> room for the WG to consider both approaches...
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Thu, 8 Dec 2011 10:04:09 -0600

Hi Greg-

  Inline

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Wednesday, December 07, 2011 9:17 PM
> To: Eric Osborne (eosborne); David Allan I; [email-masked]
> Subject: RE: Draft on Shared Mesh Protection
> 
> Hi Eric,
> We view that monitoring of protection path availability is function of
OAM.
> Either CC/CV, LM or more likely combination of both can be used to
monitor
> the protection paths. If an explicit signalling in data plane to be
used, then I'm
> concerned that because sizing of an SPME is arbitrary we ultimately
might
> end up with re-implementing RSVP-TE signalling in the data plane.

It seems that there are two differences between your proposal and the
others floating around:

1) the assumption that the protection path can be of arbitrary size.
The other SMP proposals seem to be 1:n shared mesh, where all of the n
things are the same size.

2) the need to notify the headend that it is, under certain
circumstances, unprotected

It may be worth emphasizing and discussing those differences in the
draft....I think that we (the WG) need to come up with a solid set of
requirements for shared mesh protection before we start defining it.  

eric

> I think that a section on cooperation between OAM and SMP with SPME
can
> be added to the dociment.
> 
> 	Regards,
> 		Greg
> 
Of
> Eric Osborne (eosborne)
the other
> shared mesh proposals is the ability to notify a node which depends on
the
> existence of a protection path that its protection path is not
available.  This
> capability exists in the other SMP proposals currently floating
around, as well
> as rfc4872.
> 
>   If you had two business classes, BC1 > BC2, if the LSPs in BC2
failed and were
> using the protection path then the LSPs in BC1 failed and needed to
boot
> some or all of the BC2 LSPs from the protection domain, how would that
> work?  Would an implementation continue to transmit both
bit
> in the Fault Management message akin to AIS or LDI that said
"protection
> unavailable due to preemption" that would flow back to the ultimate
> headend?
> 
> 
> 
> eric
> 
> 
>

---

From: David Allan I <[email-masked]>
Date: Thu, 8 Dec 2011 11:31:48 -0500

HI Eric:

I'd expand the delta list a bit and also editorialize while at it.... 

1) the assumption that the protection path can be of arbitrary size.
The other SMP proposals seem to be 1:n shared mesh, where all of the n things are the same size.

We were operating on the premise that imposing the constraints on what could utilize shared mesh (e.g. only a set of LSPs dimensions to the same size) and requiring a usefully significant span of co-routedness (such that pairwise selectors could be both co-located and coordinated) would dramatically decrease the utility of any attempt to share protection bandwidth. Of course once you allow arbitrary size, then possible preemption outcomes becomes combinatorial vs. simply a "pick one from column B" and not easily defined and made deterministic.

So we allow arbitrary size AND eliminate the co-routed requirement as well as NOT picking on specific LSPs, we share the pain.

2) the need to notify the headend that it is, under certain circumstances, unprotected

As our proposal would see degredation of the set of lower priority LSPs vs. preemption of one of them, it would require OAM in the form of CC/CV or LM for a degraded LSP to figure it out and make the call that the service had become untenable. We also assumed this was a static environment so if a higher priority service preempted the lower one, it was pretty much expected to "suck it up", and if one genuinely wanted more complex response (e.g. shift from protection switching to restoration) you needed a control plane and that stuff is actually done and dusted anyway. 

The alternative being to overdimension and over-provision the network so one can permit the IMO "rather bizzare" capability to cascade preemptive behavior. If the bandwidth and business case existed to do that "pre-planned" I'd simply offer fully committed protection resources to each business priority. 

My 2 cents
Dave

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]] 
Sent: Thursday, December 08, 2011 5:04 PM
To: Gregory Mirsky; David Allan I; [email-masked]
Subject: RE: Draft on Shared Mesh Protection

Hi Greg-

  Inline

OAM.
monitor
used, then I'm
might
> end up with re-implementing RSVP-TE signalling in the data plane.

It seems that there are two differences between your proposal and the others floating around:

1) the assumption that the protection path can be of arbitrary size.
The other SMP proposals seem to be 1:n shared mesh, where all of the n things are the same size.

2) the need to notify the headend that it is, under certain circumstances, unprotected

It may be worth emphasizing and discussing those differences in the draft....I think that we (the WG) need to come up with a solid set of requirements for shared mesh protection before we start defining it.  

eric

can
Of
the other
the
available.  This
around, as well
failed and were
boot
bit
"protection