Subject: Re: [mpls] Comments on draft-weingarten-mpls-smp-requirements-00.txt

From: Yaacov Weingarten <[email-masked]>
Date: Mon, 6 Aug 2012 15:56:32 +0300

Hi,

Thank you for your comments.  Please see my comments inline below.

BR,
yaacov

On Tue, Jul 17, 2012 at 11:51 PM, Pablo Frank <[email-masked]> wrote:

> Good draft and certainly something that needs to be done before we can
> start discussing specific solutions.
>
> Only a few comments / questions:
>
> - In 4.1.1, if one is operating in an MPLS-TP network that requires
> exclusive use of the protection resources, doesn't this SHOULD requirement
> become a MUST requirement?
>

yw>> Sorry - but could you explain more fully this comment.

> - Nit: you might want to avoid using the "query" verb in the title of
> 4.1.1 because it subtly suggests some kind of protocol messaging is
> required.  I would use the more generic verb "checking" or "verifying".
>
yw>> Sounds OK to me.

> - In 4.3, there is no suggestion for what should happen if one or more
> failing paths in an MPLS-TP network are of equal priority.  I presume it
> will be some kind of first-come, first-serve requirement but this will
> bring up the question of how to break ties.
>
yw>> This could be resolved along the lines that it was addressed in the
1:n protection

> - Also in 4.3, there is an allowance for a high priority path and a lower
> priority path to temporarily share the protection resources while
> preemption is taking place.  Two questions:
>
> - Is the ingress node to the shared segment expected to discard excess
> traffic now that the protection-path is temporarily oversubscribed?
>
> yw>> this would most probably follow standard MPLS behavior as described
elsewhere

> - If not, how do we ensure that other transport paths are unaffected?
>
> - The first paragraph of 4.4 appears to contradict 4.1.1.  4.4 seems to
> suggest that one MUST switch the traffic onto the protection path first and
> then get notified if there's not enough resources.  That's probably okay in
> the general case.  But in an MPLS-TP network, I don't think it's a good
> idea to blindly switch low priority traffic onto the protection path and
> possibly disrupt a high priority path that is already using that resource.
>
yw>> This is dependent upon the actual mechanism that is developed by the
WG.  For example, one suggestion for the mechanism has notifications sent
to lower priority working paths making the protection path unavailable if
it is in use by a high-priority working path.

> - In section 4.5, there's an attempt to define "protection switching time"
> as not including preemption time.  I don't think end-users really care
> about "protection switching time".  They care about recovery time and IMO,
> that should also include fault detection time (although it doesn't per RFC
> 5654) and any preemption time.
>
yw>> we do try to work within the accepted definitions of the IETF!

>
> regards,
> Pablo
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Pablo Frank <[email-masked]>
Date: Fri, 10 Aug 2012 10:23:26 -0400

Hi Yaacov,

Some more comments inline... PF>>

On Mon, Aug 6, 2012 at 8:56 AM, Yaacov Weingarten <[email-masked]> wrote:

> On Tue, Jul 17, 2012 at 11:51 PM, Pablo Frank <[email-masked]>wrote:
>

PF>>  If you're trying to meet RFC 5654 req 58b in particular, I would
think you MUST validate that enough protection resources are available (or
are preemptible) to carry 100% of the service traffic that is being
restored.  In existing transport networks (i.e. OTN / sonet), this is
typically done before you switch traffic to the protection path.  From a
solution perspective, I think you'll probably want to leverage something
like the locking mode that is being proposed for the 1:n draft.

- Nit: you might want to avoid using the "query" verb in the title of 4.1.1
>> because it subtly suggests some kind of protocol messaging is required.  I
>> would use the more generic verb "checking" or "verifying".
>>
> yw>> Sounds OK to me.
>

PF>> Except that you guys removed separate path priority from the latest
version of the 1:n draft.  In the latest version, each path has a strict
priority defined by its path ID so ties were not possible.  I don't think
that solution will work for SMP because I have a hard time seeing how all
the various endpoints involved in a shared mesh could coordinate
non-overlapping path IDs, while at the same time not exceeding the limit of
255 path IDs.

>> yw>> this would most probably follow standard MPLS behavior as described

PF>> I guess I'll ask what is the standard behaviour?  And is it applicable
to MPLS-TP networks?

>> - In section 4.5, there's an attempt to define "protection switching
>> time" as not including preemption time.  I don't think end-users really
>> care about "protection switching time".  They care about recovery time and
>> IMO, that should also include fault detection time (although it doesn't per
>> RFC 5654) and any preemption time.
>>

PF>> I guess there's two separate comments here that I kinda conflated
together.  One was more of a gripe: why did we exclude fault detection time
from the 50ms restoration time requirement in RFC 5654?  I know that my
customers measure only one thing: how many ms of traffic do they lose after
a breakage.  I don't get a free pass on the ~10ms it takes for BFD to
detect the failure.  According to RFC 5654, I could use 60sec CCMs and
still meet the 50ms requirement!

The 2nd comment was really about this draft now trying to exclude
preemption time from restoration time as well.  IMO, if it takes a few
seconds for a high priority service to finish preempting a lower priority
service, then we haven't met the 50ms restoration time requirement.
 Especially since it's typically my higher priority services that want 50ms
restoration times in the first place, so they'll be more often in a
position to preempt.  In other words, I think we want preemption to be fast
and is a critical component of protection switching.

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 15 Aug 2012 18:45:23 -0400

Dear Pablo, Yaacov, et al.,
I've been following discussion with great deal of interest. I have some questions in addition to ones being brought up by Pablo:

 *
Section 1.2 refers to operator's desire to have service restoration more expedient than one achievable with control plane. I haven't seen any quantative information to compare with. What is "expedient enough" for SMP?
 *
Section 3.1 desrcibes, what can be called, "instant determinism" in regard to SMP resource avaialability. I think that there's not enough reasoning to conclude that almost instanteneous update of SMP resources avaialability is required.
 *
In the last sentence of Section 3.1 non-control plane coordination of shared resources presented as another requirement. And again I can not find how we come to such conclusion, where the source of this requirement. Would existing control plane signaling solution be sufficient for a MPLS network?
 *
I've noticed that many requirements being referred to MPLS-TP, not MPLS, networks. Would that be a good reason to narrow scope of the document to MPLS-TP networks only, starting with the name of the document?

    Regards,
        Greg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pablo Frank
Sent: Friday, August 10, 2012 7:23 AM
To: Yaacov Weingarten
Cc: [email-masked]
Subject: Re: [mpls] Comments on draft-weingarten-mpls-smp-requirements-00.txt

Hi Yaacov,

On Mon, Aug 6, 2012 at 8:56 AM, Yaacov Weingarten <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

BR,
yaacov

On Tue, Jul 17, 2012 at 11:51 PM, Pablo Frank <[email-masked]<mailto:[email-masked]>> wrote:
Good draft and certainly something that needs to be done before we can start discussing specific solutions.

- In 4.1.1, if one is operating in an MPLS-TP network that requires exclusive use of the protection resources, doesn't this SHOULD requirement become a MUST requirement?

PF>>  If you're trying to meet RFC 5654 req 58b in particular, I would think you MUST validate that enough protection resources are available (or are preemptible) to carry 100% of the service traffic that is being restored.  In existing transport networks (i.e. OTN / sonet), this is typically done before you switch traffic to the protection path.  From a solution perspective, I think you'll probably want to leverage something like the locking mode that is being proposed for the 1:n draft.

- Nit: you might want to avoid using the "query" verb in the title of 4.1.1 because it subtly suggests some kind of protocol messaging is required.  I would use the more generic verb "checking" or "verifying".
yw>> Sounds OK to me.
- In 4.3, there is no suggestion for what should happen if one or more failing paths in an MPLS-TP network are of equal priority.  I presume it will be some kind of first-come, first-serve requirement but this will bring up the question of how to break ties.
yw>> This could be resolved along the lines that it was addressed in the 1:n protection

PF>> Except that you guys removed separate path priority from the latest version of the 1:n draft.  In the latest version, each path has a strict priority defined by its path ID so ties were not possible.  I don't think that solution will work for SMP because I have a hard time seeing how all the various endpoints involved in a shared mesh could coordinate non-overlapping path IDs, while at the same time not exceeding the limit of 255 path IDs.

- Also in 4.3, there is an allowance for a high priority path and a lower priority path to temporarily share the protection resources while preemption is taking place.  Two questions:
- Is the ingress node to the shared segment expected to discard excess traffic now that the protection-path is temporarily oversubscribed?
yw>> this would most probably follow standard MPLS behavior as described elsewhere

PF>> I guess I'll ask what is the standard behaviour?  And is it applicable to MPLS-TP networks?

- If not, how do we ensure that other transport paths are unaffected?
- The first paragraph of 4.4 appears to contradict 4.1.1.  4.4 seems to suggest that one MUST switch the traffic onto the protection path first and then get notified if there's not enough resources.  That's probably okay in the general case.  But in an MPLS-TP network, I don't think it's a good idea to blindly switch low priority traffic onto the protection path and possibly disrupt a high priority path that is already using that resource.
yw>> This is dependent upon the actual mechanism that is developed by the WG.  For example, one suggestion for the mechanism has notifications sent to lower priority working paths making the protection path unavailable if it is in use by a high-priority working path.

- In section 4.5, there's an attempt to define "protection switching time" as not including preemption time.  I don't think end-users really care about "protection switching time".  They care about recovery time and IMO, that should also include fault detection time (although it doesn't per RFC 5654) and any preemption time.
yw>> we do try to work within the accepted definitions of the IETF!

PF>> I guess there's two separate comments here that I kinda conflated together.  One was more of a gripe: why did we exclude fault detection time from the 50ms restoration time requirement in RFC 5654?  I know that my customers measure only one thing: how many ms of traffic do they lose after a breakage.  I don't get a free pass on the ~10ms it takes for BFD to detect the failure.  According to RFC 5654, I could use 60sec CCMs and still meet the 50ms requirement!

The 2nd comment was really about this draft now trying to exclude preemption time from restoration time as well.  IMO, if it takes a few seconds for a high priority service to finish preempting a lower priority service, then we haven't met the 50ms restoration time requirement.  Especially since it's typically my higher priority services that want 50ms restoration times in the first place, so they'll be more often in a position to preempt.  In other words, I think we want preemption to be fast and is a critical component of protection switching.

regards,
Pablo

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: [email-masked]
Date: Mon, 20 Aug 2012 19:02:41 +0800

Greg, snipped

In the last sentence of Section 3.1 non-control plane coordination of 
shared resources presented as another requirement. And again I can not 
find how we come to such conclusion, where the source of this requirement. 
Would existing control plane signaling solution be sufficient for a MPLS 
network? 

<Fei> I do not think the existing control plane (defined in RFC4872) is 
sufficient for a MPLS network, and there is an analysis in the draft 
http://tools.ietf.org/html/draft-he-ccamp-notification-shared-mesh-protection-00. 

Best regards

Fei

Gregory Mirsky <[email-masked]> 
发件人:  [email-masked]
2012-08-16 06:45

收件人
Pablo Frank <[email-masked]>, Yaacov Weingarten <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [mpls] Comments on draft-weingarten-mpls-smp-requirements-00.txt

Dear Pablo, Yaacov, et al.,
I've been following discussion with great deal of interest. I have some 
questions in addition to ones being brought up by Pablo:
Section 1.2 refers to operator's desire to have service restoration more 
expedient than one achievable with control plane. I haven't seen any 
quantative information to compare with. What is "expedient enough" for 
SMP?
Section 3.1 desrcibes, what can be called, "instant determinism" in regard 
to SMP resource avaialability. I think that there's not enough reasoning 
to conclude that almost instanteneous update of SMP resources 
avaialability is required.
In the last sentence of Section 3.1 non-control plane coordination of 
shared resources presented as another requirement. And again I can not 
find how we come to such conclusion, where the source of this requirement. 
Would existing control plane signaling solution be sufficient for a MPLS 
network?
I've noticed that many requirements being referred to MPLS-TP, not MPLS, 
networks. Would that be a good reason to narrow scope of the document to 
MPLS-TP networks only, starting with the name of the document?
    Regards,
        Greg

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Pablo Frank
Sent: Friday, August 10, 2012 7:23 AM
To: Yaacov Weingarten
Cc: [email-masked]
Subject: Re: [mpls] Comments on 
draft-weingarten-mpls-smp-requirements-00.txt

Hi Yaacov, 

On Mon, Aug 6, 2012 at 8:56 AM, Yaacov Weingarten <[email-masked]> 
wrote:
Hi, 

BR,
yaacov

On Tue, Jul 17, 2012 at 11:51 PM, Pablo Frank <[email-masked]> 
wrote:
Good draft and certainly something that needs to be done before we can 
start discussing specific solutions. 

non-overlapping path IDs, while at the same time not exceeding the limit 
of 255 path IDs.

PF>> I guess I'll ask what is the standard behaviour?  And is it 
applicable to MPLS-TP networks?
 
- If not, how do we ensure that other transport paths are unaffected?
- The first paragraph of 4.4 appears to contradict 4.1.1.  4.4 seems to 
suggest that one MUST switch the traffic onto the protection path first 
and then get notified if there's not enough resources.  That's probably 
okay in the general case.  But in an MPLS-TP network, I don't think it's a 
good idea to blindly switch low priority traffic onto the protection path 
and possibly disrupt a high priority path that is already using that 
resource.
yw>> This is dependent upon the actual mechanism that is developed by the 
WG.  For example, one suggestion for the mechanism has notifications sent 
to lower priority working paths making the protection path unavailable if 
it is in use by a high-priority working path.

PF>> I guess there's two separate comments here that I kinda conflated 
together.  One was more of a gripe: why did we exclude fault detection 
time from the 50ms restoration time requirement in RFC 5654?  I know that 
my customers measure only one thing: how many ms of traffic do they lose 
after a breakage.  I don't get a free pass on the ~10ms it takes for BFD 
to detect the failure.  According to RFC 5654, I could use 60sec CCMs and 
still meet the 50ms requirement!

The 2nd comment was really about this draft now trying to exclude 
preemption time from restoration time as well.  IMO, if it takes a few 
seconds for a high priority service to finish preempting a lower priority 
service, then we haven't met the 50ms restoration time requirement. 
Especially since it's typically my higher priority services that want 50ms 
restoration times in the first place, so they'll be more often in a 
position to preempt.  In other words, I think we want preemption to be 
fast and is a critical component of protection switching. 

regards,
Pablo

---

From: David Allan I <[email-masked]>
Date: Tue, 21 Aug 2012 13:29:01 -0400

Hi Fei:

I see "a" proposed solution in the draft you reference, but not a problem statement or analsys.

The preemption could simply be performed at node E. Currently the model is that the LERs need to notify node E when the P path is being used, and E needs to notify the LERs of the current state of the shared resource.  This appears to depend on the preempted LSR to "do the right thing" and leads to an IMO unreasonable window of contention for the shared resources.

IMO E should be doing the preemption, and I've still not really seen a need for head end notification of preemption unless one starts planning backups for backups.

If you have more information, could you elaborable?
Dave

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, August 20, 2012 4:03 AM
To: Gregory Mirsky
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Comments on draft-weingarten-mpls-smp-requirements-00.txt

Greg, snipped

 *   In the last sentence of Section 3.1 non-control plane coordination of shared resources presented as another requirement. And again I can not find how we come to such conclusion, where the source of this requirement. Would existing control plane signaling solution be sufficient for a MPLS network?

<Fei> I do not think the existing control plane (defined in RFC4872) is sufficient for a MPLS network, and there is an analysis in the draft http://tools.ietf.org/html/draft-he-ccamp-notification-shared-mesh-protection-00.

Best regards

Fei

2012-08-16 06:45

收件人

 *   Section 1.2 refers to operator's desire to have service restoration more expedient than one achievable with control plane. I haven't seen any quantative information to compare with. What is "expedient enough" for SMP?
 *   Section 3.1 desrcibes, what can be called, "instant determinism" in regard to SMP resource avaialability. I think that there's not enough reasoning to conclude that almost instanteneous update of SMP resources avaialability is required.
 *   In the last sentence of Section 3.1 non-control plane coordination of shared resources presented as another requirement. And again I can not find how we come to such conclusion, where the source of this requirement. Would existing control plane signaling solution be sufficient for a MPLS network?
 *   I've noticed that many requirements being referred to MPLS-TP, not MPLS, networks. Would that be a good reason to narrow scope of the document to MPLS-TP networks only, starting with the name of the document?

    Regards,
        Greg

Hi Yaacov,

BR,
yaacov

regards,
Pablo

---

From: [email-masked]
Date: Tue, 28 Aug 2012 10:51:47 +0800

Hi Dave

Sorry for the delayed response, see my notes tagged with <fei>

Thanks

Fei

David Allan I <[email-masked]> 
2012-08-22 01:29

收件人
"[email-masked]" <[email-masked]>, Gregory Mirsky 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
RE: [mpls] Comments on draft-weingarten-mpls-smp-requirements-00.txt

Hi Fei:
 
I see "a" proposed solution in the draft you reference, but not a problem 
statement or analsysis

<fei>  The proposed solution is base on the control plane extensions, and 
the problem statement said " [RFC4872] defines the shared mesh restoration 
schemes based on
   control plane extensions, but does not cover the shared mesh protection 
scenarios."
 
The preemption could simply be performed at node E. Currently the model is 
that the LERs need to notify node E when the P path is being used, and E 
needs to notify the LERs of the current state of the shared resource. This 
appears to depend on the preempted LSR to "do the right thing" and leads 
to an IMO unreasonable window of contention for the shared resources.

  <fei> Preemption means that  there will be a window of contention, why 
it is unreasonable?

IMO E should be doing the preemption, and I've still not really seen a 
need for head end notification of preemption unless one starts planning 
backups for backups.

  <fei> IMHO, there are two priorities need to be handled in shared mesh 
protection scenarios, the path priority and the service priority (PHB). If 
node E does the preemption, how to 
deal with the path priority, which is not carried in traffic packet. 

[email-masked]

Greg, snipped 

<Fei> I do not think the existing control plane (defined in RFC4872) is 
sufficient for a MPLS network, and there is an analysis in the draft 
http://tools.ietf.org/html/draft-he-ccamp-notification-shared-mesh-protection-00
. 

Best regards 

Fei 

收件人

Hi Yaacov, 

BR, 
yaacov

 

regards, 
Pablo

---

From: David Allan I <[email-masked]>
Date: Tue, 28 Aug 2012 01:48:16 -0400

HI Fei:

You wrote:
 <fei> IMHO, there are two priorities need to be handled in shared mesh protection scenarios, the path priority and the service priority (PHB). If node E does the preemption, how to
deal with the path priority, which is not carried in traffic packet.
My understanding of your proposal is that via control plane exchange, E knows the path priority. Certainly the ingresses are unaware of each other without a coordination mechanism which as currently described is notifications originating with E. My suggestion is that the E as the preemption point has sufficient knowledge to perform this function, and would do it with less latency than head end notification and the head end as the preemption point. It has the added plus of not being dependent on the head end not being brain dead....

I hope this helps
Dave

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 28, 2012 5:52 AM
To: David Allan I
Cc: Gregory Mirsky; [email-masked]
Subject: RE: [mpls] Comments on draft-weingarten-mpls-smp-requirements-00.txt

Hi Dave

Thanks

Fei

2012-08-22 01:29

收件人
"[email-masked]" <[email-masked]>, Gregory Mirsky <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
RE: [mpls] Comments on draft-weingarten-mpls-smp-requirements-00.txt

Hi Fei:

I see "a" proposed solution in the draft you reference, but not a problem statement or analsysis

<fei>  The proposed solution is base on the control plane extensions, and the problem statement said " [RFC4872] defines the shared mesh restoration schemes based on
  control plane extensions, but does not cover the shared mesh  protection scenarios."

  <fei> Preemption means that  there will be a window of contention, why it is unreasonable?

  <fei> IMHO, there are two priorities need to be handled in shared mesh protection scenarios, the path priority and the service priority (PHB). If node E does the preemption, how to
deal with the path priority, which is not carried in traffic packet.

Greg, snipped

Best regards

Fei

2012-08-16 06:45

收件人

    Regards,
       Greg

Hi Yaacov,

BR,
yaacov

regards,
Pablo

---

From: [email-masked]
Date: Tue, 28 Aug 2012 14:30:33 +0800

Hi Dave

Thank you for your nice response

See in line with <fei1>

Thanks

Fei

2012-08-28 13:48

收件人
"[email-masked]" <[email-masked]>
抄送
Gregory Mirsky <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
RE: [mpls] Comments on draft-weingarten-mpls-smp-requirements-00.txt

HI Fei:
 
You wrote:
 <fei> IMHO, there are two priorities need to be handled in shared mesh 
protection scenarios, the path priority and the service priority (PHB). If 
node E does the preemption, how to 
deal with the path priority, which is not carried in traffic packet. 
My understanding of your proposal is that via control plane exchange, E 
knows the path priority. Certainly the ingresses are unaware of each other 
without a coordination mechanism which as currently described is 
notifications originating with E. My suggestion is that the E as the 
preemption point has sufficient knowledge to perform this function, and 
would do it with less latency than head end notification and the head end 
as the preemption point. It has the added plus of not being dependent on 
the head end not being brain dead....

 <fei1> Ok, I think I understand your idea now.  IMHO,  although the 
requirements are coming from MPLS-TP, the standard had better covering the 
other scenarios. Consider the ODU2 path as the shared path segment, and 
the node E as the preemption point (just as you said).

t0 H-E-F-G-K as the protecting path are protecting the work path H-I-J-K
t1 A-B-C-D is broken, node A switches the traffic to A-E
t2 node E switches the crossconnect from H-E to A-E (path A-B-C-D has 
higher priority than H-I-J-K)

However, node G can not make sure to switch the crossconnect from G-K to 
G-D simultaneously as at node E. Misconnection will happen.

I hope this helps
Dave

Subject: RE: [mpls] Comments on 

Hi Dave 

Thanks 

Fei 

收件人

Hi Fei: 

  

  

Greg, snipped 

Best regards 

Fei 

收件人

Hi Yaacov, 

BR, 
yaacov

 

regards, 
Pablo

---

From: David Allan I <[email-masked]>
Date: Tue, 28 Aug 2012 02:35:15 -0400

For circuit technology I agree, resource consumption and connectivity are linked and coordination is required. But that still suggests that all preemption activity is or can be confined to the shared part of the path. In that regard I think we are digressing from the original issues...which was any requirement for head end notification.

Dave

Sent: Tuesday, August 28, 2012 9:31 AM

Hi Dave

See in line with <fei1>

Thanks

Fei

2012-08-28 13:48

收件人
"[email-masked]" <[email-masked]>
抄送
Gregory Mirsky <[email-masked]>, "[email-masked]" <[email-masked]>
主题
RE: [mpls] Comments on draft-weingarten-mpls-smp-requirements-00.txt

HI Fei:

You wrote:

 <fei1> Ok, I think I understand your idea now.  IMHO,  although the requirements are coming from MPLS-TP, the standard had better covering the other scenarios. Consider the ODU2 path as the shared path segment, and the node E as the preemption point (just as you said).

t0 H-E-F-G-K as the protecting path are protecting the work path H-I-J-K
t1 A-B-C-D is broken, node A switches the traffic to A-E
t2 node E switches the crossconnect from H-E to A-E (path A-B-C-D has higher priority than H-I-J-K)

However, node G can not make sure to switch the crossconnect from G-K to G-D simultaneously as at node E. Misconnection will happen.

I hope this helps
Dave

Hi Dave

Thanks

Fei

2012-08-22 01:29

收件人

Hi Fei:

Greg, snipped

Best regards

Fei

2012-08-16 06:45

收件人

    Regards,
      Greg

Hi Yaacov,

BR,
yaacov

regards,
Pablo

---

From: [email-masked]
Date: Tue, 28 Aug 2012 14:49:46 +0800

Dave, 

For MPLS networks, I agree with you that node E can pre-store the path 
priority and do the switch and notification. :-)

If we consider a uniform mechanism for the backbone networks (MPLS-TP, 
OTN, SONE/SDH, WSON), I tend to think head end notification wins.

Hope this clarify my opinion

regards

Fei

2012-08-28 14:35

收件人

For circuit technology I agree, resource consumption and connectivity are 
linked and coordination is required. But that still suggests that all 
preemption activity is or can be confined to the shared part of the path. 
In that regard I think we are digressing from the original issues...which 
was any requirement for head end notification.
 
Dave

Hi Dave 

See in line with <fei1> 

Thanks 

Fei 

收件人

HI Fei: 
  
You wrote: 

I hope this helps 
Dave 

Hi Dave 

Thanks 

Fei 

收件人

Hi Fei: 

 

 <fei> Preemption means that  there will be a window of contention, why it 
is unreasonable? 

 

Greg, snipped 

Best regards 

Fei 

收件人

Hi Yaacov, 

BR, 
yaacov

regards, 
Pablo