Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 2 Apr 2012 04:56:28 -0500

Hi Maarten-
 
 How does a node know that two requests are of equal priority?  Is this
somehow configured a priori on the MSP endpoints?

eric

> -----Original Message-----
> From: Maarten vissers [mailto:[email-masked]]
> Sent: Thursday, March 29, 2012 3:06 PM
> To: Maarten vissers; Eric Osborne (eosborne); Gregory Mirsky;
> [email-masked]; Yaacov Weingarten; [email-masked]
> Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
> 
> Below is a copy of the equal priority text in G.873.1 (OTN linear
> protection):
> 
> 8.10	Equal priority requests
> In general, once a switch has been completed due to a request, it will
not
> be overridden by another request of the same priority (first come,
first
> served behaviour). When equal priority requests occur simultaneously,
the
> conflict is resolved in favour of the request with the lowest entity
> number. In bidirectional switching, a request received over the APS
> channel with a lower entity number will always override an identical
> priority local request with a higher entity number. Equal priority
> requests for the same entity number from both sides of a bidirectional
> protection group are both considered valid, and equivalent to a
received
> "RR" from a near-end processing standpoint.
> 
> Regards,
> Maarten
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Maarten vissers
> Sent: donderdag 29 maart 2012 14:54
> To: Eric Osborne (eosborne); Gregory Mirsky; [email-masked];
Yaacov
> Weingarten; [email-masked]
> Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01
> 
> 1:n protection in a transport network at the path layer is not a very
> common protection switching application. This is due to the fact that
1:n
> protection requires n+1 diverse routed paths. How many of those
diverse
> routed paths will be available in typical transport networks? Not
many...
> very often two diverse routed paths is all you can get... and this is
only
> truly guaranteed over time if the network domain is organized as
separate
> A and a B networks. Otherwise maintenance on the network may result in
> temporary rerouting of virtual links, resulting in routing W and P
> connections over the same fiber, node or duct.
> 
> With n>2, separate networks can not be used and one has to find n+1
> diverse routed paths through the network and guarantee that neither
> maintenance activities, nor network upgrades result in rerouting of
the
> virtual links so that W and P connections pass through the same fiber,
> node or duct.
> 
> 1:n protection has been used in SDH/SONET for SDH/SONET regenerator
> protection (1:7 and 1:11 systems, in early 90's) and for SDH line card
> protection (end of 90's).
> 
> Regards,
> Maarten
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Eric Osborne (eosborne)
> Sent: donderdag 29 maart 2012 14:31
> To: Gregory Mirsky; [email-masked]; Yaacov Weingarten;
> [email-masked]
> Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01
> 
> I still go back to my point that since only one W can ever use P,
there
> really is no such thing as 'equal priority'.  We must have a priority
> scheme, whether it is the channel number in Fpath or whether it's some
> other mechanism, so that we know that Wi always beats Wj no matter
what
> order the events occur in.
> 
> We had initially discussed leaving the exact priority scheme to the
> protection endpoints, but I see now that that may not work well across
> vendors.
> 
> I think we have a few choices:
> 
> 1) some sort of explicit priority field
> 2) define priority as the FPath value, lower is better (as Maarten
> points out, this is the current practice in SDH).
> 
> Either one of these have costs to them.
> 
> Doing #1 leaves us with a potential mismatch; if LER-A thinks W2 has
> prio1 and LER-Z thinks W3 has prio1, sorting this out is messy, and in
> locking mode means nobody is protected until both ends converge.  This
> also makes things (potentially) very dynamic which is, I think, not
what
> we want in a protocol that has to converge in real time.
> 
> Doing #2 means that if I have W1...W5 already provisioned and I want
to
> add W3.1, I need to reprovision W4 and W5, which may be disruptive.
How
> often does this sort of thing happen in transport networks?  Is it a
> real problem?
> 
> 
> 
> 
> eric
> 
> > -----Original Message-----
> > From: Gregory Mirsky [mailto:[email-masked]]
> > Sent: Thursday, March 29, 2012 2:21 PM
> > To: Eric Osborne (eosborne); [email-masked]; Yaacov
Weingarten;
> > [email-masked]
> > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
> >
> >
> > Hi Eric,
> > I agree with your logic and that current document handles scenario
you
> > present (prioties of simulteneously failed paths are different)
well.
> But
> > I still am concerned with case when priorities of Wi and Wj are
equal.
> If
> > you think that it might present a problem, then I see two possible
> ways to
> > address:
> > - disallow multiple LSPs being assigned equal priority (not the best
> way);
> > - define tiebreaking rule(s).
> >
> > 	Regards,
> > 		Greg
> >
> > -----Original Message-----
> > From: Eric Osborne (eosborne) [mailto:[email-masked]]
> > Sent: Thursday, March 29, 2012 5:11 AM
> > To: Gregory Mirsky; [email-masked]; Yaacov Weingarten;
> > [email-masked]
> > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
> >
> > Let me rewrite the messages a little bit in your example.  Rather
than
> > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the
LSPs
> in
> > question.  And let's also say that the priority of Wi > Wj, just as
> you
> > have done.
> >
> > I also note that setting Path==0 means you're using locking mode.
> This is
> > certainly a valid case, I just want to confirm that it's your
> intention?
> >
> > at t0, no failure.
> >
> > at t1,
> >   LER-A sends SF(Wi,0) to LER-Z
> >     AND
> >   LER-Z sends SF(Wj,0) to LER-Z
> >
> > at t2, LER-A receives SF(Wj,0).  It ignores it, since it has already
> > decided that Wi needs the protect channel.
> >
> > LER-Z also receives SF(Wi,0).  This is either exactly at t2, or at
t3,
> > shortly after t2.
> >
> > LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a
> > unidirectional locking preemption case, as in section 3.3.3.2 of the
> > draft.  LER-Z responds to the SF(Wi,0) with NR(Wi,0).  This is what
> > 3.3.3.2 describes as LER-A's behavior at t1.
> >
> > In this way, both LER-A and LER-Z converge on protecting Wi.  Since
it
> is
> > locking, no transmission of packets takes place since neither side
had
> > ACKd the other side's SF.
> >
> > Does that reflect your question, and does it answer it?
> >
> >
> >
> >
> >
> > eric
> >
> > > -----Original Message-----
> > > From: Gregory Mirsky [mailto:[email-masked]]
> > > Sent: Thursday, March 29, 2012 1:51 PM
> > > To: Eric Osborne (eosborne); [email-masked]; Yaacov
> Weingarten;
> > > [email-masked]
> > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
> > >
> > > Hi Eric,
> > > Below is scenario that in my view would benefit from a tiebreaking
> > rule.
> > > Would appreciate your consideration and feedback whether this is
> > realistic
> > > and not breaking PSC:
> > > - Assume that LSP P is not being used or used by working path of
> > priority
> > > N;
> > > - LER-A detects failure of working path Wi of priority M, where M
>
> N,
> > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath;
> > > - almost simulteneously, at least before it receives SF from
LER-A,
> > LER-Z
> > > detects failure of Wj that has priority M. LER-Z sends SF(1,0)
> listing
> > Wj
> > > as Fpath;
> > > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) ==
> > Priority(Wj)
> > > would not change to protecting Wi path;
> > > - LER-A receives SF(1,0) from LER-Z and for the same reason would
> keep
> > Wi
> > > as path to protect.
> > > Is that sequence, scenario correct? Would LER-A and LER-Z converge
> on
> > > selecting one path they'd protect?
> > >
> > > 	Regards,
> > >  		Greg
> > >
> > > -----Original Message-----
> > > From: Eric Osborne (eosborne) [mailto:[email-masked]]
> > > Sent: Thursday, March 29, 2012 4:38 AM
> > > To: Gregory Mirsky; [email-masked]; Yaacov Weingarten;
> > > [email-masked]
> > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
> > >
> > >
> > > > EO#  I would argue that one should not have LSPs of the "same
> > > priority".
> > > > There must be a tiebreaker that can handle all possible
conflicts,
> > no
> > > > matter what order or how many failures.  Once there is a
> > deterministic
> > > > mechanism for all cases, it means that all LSPs are of different
> > > priority.
> > > >
> > > > GIM>> Tiebreaking would be used only in case of simulteneous
> failure
> > > of
> > > > two working paths of equal priority. Otherwise, equal priority
> would
> > > not
> > > > preempt one that is already is using the protection path, i.e.
> FIFO
> > > will
> > > > fully work in this case.
> > >
> > >
> > > I think the behavior you describe is more about SMP than 1:n.  In
> 1:n
> > we'd
> > > always made the assumption that, in a given protection domain,
only
> a
> > > single W can be protected at a time.  To do otherwise (say, W1 and
> W2
> > > using P) is not possible using PSC signaling since we can only
> > indicate a
> > > single LSP in the FPath field.
> > >
> > > Nothing precludes multiple protection domains from using the same
> > > underlying link and/or same endpoints, but that's a network design
> > > consideration.
> > >
> > >
> > >
> > >
> > > eric
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Maarten vissers <[email-masked]>
Date: Mon, 2 Apr 2012 10:06:03 +0000

Hi Eric,

The standard specifies the priority order of requests. E.g. in G.873.1 (OTN linear protection, http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.873.1-201107-I!!PDF-E&type=items) the following specification is included:

      8.3       Request type
The request types that may be reflected in the APS bytes are the "standard" types traditionally supported by protection switching for SONET and SDH. These requests reflect the highest priority condition, command, or state (see Tables 2 and 3). In the case of unidirectional switching, this is the highest priority value determined from the near end only. In bidirectional switching, the local request will be indicated only in the case where it is as high or higher than any request received from the far end over the APS channel. In bidirectional switching, when the far end request has the highest priority, the near end will signal Reverse Request.

Table 2/G.873.1 - Request/state priorities with APS protocol

Request/state   Priority
Lockout for Protection (LoP)    1 (highest)
Signal Fail (SF) - protection   2 (see 8.9)
Forced Switch (FS)      3
Signal Fail (SF) - working      4
Signal Degrade (SD)     5
Manual Switch (MS)      6
Wait-to-Restore (WTR)   7
Exercise (EXER) 8
Reverse Request (RR)    9
Do Not Revert (DNR)     10
No Request (NR) 11 (lowest)

Table 3/G.873.1 - Request/state priorities without APS protocol

Request/state   Priority
Lockout for Protection (LoP)    1 (highest)
Forced Switch (FS)      2
Signal Fail (SF)        3
Signal Degrade (SD)     4
Manual Switch (MS)      5
Wait-to-Restore (WTR)   6
Do Not Revert (DNR)     7
No Request (NR) 8 (lowest)

Regards,
Maarten

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]]
Sent: maandag 2 april 2012 11:56
To: Maarten vissers; Gregory Mirsky; [email-masked]; Yaacov Weingarten; [email-masked]
Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01

Hi Maarten-

eric

not
first
the
received
Of
Yaacov
1:n
diverse
many...
only
separate
the
Of
there
what
what
to
How
Weingarten;
you
well.
equal.
than
LSPs
t3,
it
had
LER-A,
conflicts,
only

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 2 Apr 2012 05:49:58 -0500

Sure, but what we're trying to address here is the requirement for 1:n.

As I understand (1:1)^n it's just a set of 1:1 protection sessions provisioned by some central box with knowledge of the potential conflicts between other boxes.  This isn't something we need new state machines or packet formats for, and thus doesn't seem like something we need to standardize.  FRR, although it is different from any of the transport-style protection methods, has been provisioned like this for years.

eric

> From: 류정동 [mailto:[email-masked]]
> Sent: Monday, April 02, 2012 6:28 AM
> Subject: RE: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01
> 
> Hi,
> 
> For packet networks, if one ever wants to have n working connections be
> protected by 1 protection connection,
> (1:1)^n is more appropriate.
> 
> Jeong-dong
> 
> 
> 
> 
> -----원본 메시지-----
> From: "Maarten vissers" <[email-masked]>
> From Date: 2012-04-02 오후 7:06:03
> To: "Eric Osborne (eosborne)" <[email-masked]>, "Gregory Mirsky"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, "Yaacov Weingarten" <[email-masked]>,
> "[email-masked]" <[email-masked]>
> Cc:
> The standard specifies the priority order of requests. E.g. in G.873.1
> (OTN linear protection,
> http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.873.1-201107-
> I!!PDF-E&type=items <http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-
> REC-G.873.1-201107-I!!PDF-E&type=items> ) the following specification is
> included:
> 
> 8.3     Request type
> The request types that may be reflected in the APS bytes are the
> "standard" types traditionally supported by protection switching for SONET
> and SDH. These requests reflect the highest priority condition, command,
> or state (see Tables 2 and 3). In the case of unidirectional switching,
> this is the highest priority value determined from the near end only. In
> bidirectional switching, the local request will be indicated only in the
> case where it is as high or higher than any request received from the far
> end over the APS channel. In bidirectional switching, when the far end
> request has the highest priority, the near end will signal Reverse
> Request.
> Table 2/G.873.1 ? Request/state priorities with APS protocol
> Request/state	 Priority
> Signal Fail (SF) ? protection	 2 (see 8.9)
> Forced Switch (FS)	 3
> Signal Fail (SF) ? working	 4
> Signal Degrade (SD)	 5
> Manual Switch (MS)	 6
> Wait-to-Restore (WTR)	 7
> Exercise (EXER)	 8
> Reverse Request (RR)	 9
> Do Not Revert (DNR)	 10
> Table 3/G.873.1 ? Request/state priorities without APS protocol
> Request/state	 Priority
> <http://umail.etri.re.kr/External_ReadCheck.aspx?email=[email-masked]&
> name=Eric+Osborne+(eosborne)&fromemail=[email-masked]&messageid=%3C342138
> [email-masked]%3E>

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 2 Apr 2012 05:57:07 -0500

I'm not sure that answers my question, although it may be that it does
and I don't understand it.

I think what you're talking about is the alarm hierarchy; that is, if I
get both LOP and FS on the same LSP, FS 'wins'.  We have this behavior
in 1:1 PSC already.  What we're trying to sort out with 1:n is what
happens when two LSPs encounter the same failure condition.

If Wx and Wy both get SF, only one of them can be protected in 1:n.  In
order to decide which one we need something deterministic.  Talking
about 'priority' and 'tie-breakers' as if they were different makes no
sense in this context.  If two LSPs are of the same priority due to a
priority config on a network device, the tie-breaker will be something
else.  As you and others have suggested, we can require the nodes to
rely on the signaled FPath value, standardizing the fact that the lower
value is alway of better priority.

The question Greg originally raised was essentially "how do we know what
that priority scheme is?"  Our answer heretofore in the 1:n drafts has
been "depends on the device, and both devices have to agree" but the
more I look at it the more that doesn't make sense.

I think what we need is something akin to what you pointed out earlier
is already done in MSP; lower numeric value for FPath always wins.

eric

> Sent: Monday, April 02, 2012 6:06 AM
Yaacov
> I!!PDF-E&type=items
<http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-

---

From: Maarten vissers <[email-masked]>
Date: Mon, 2 Apr 2012 11:34:16 +0000

(1:1)^n is also used in MPLS-TP's 1:n protection...

Due to the use of a SPME as means to implement PW or LSP TCM, there exists a client/server-like relationship between the original PW and the SPME, or the original LSP and the SPME. 

This client/server-like relationship supports aggregation of the n Protection PW [n Protection LSP] signals into a single Protection SPME signal. 

At the SPME level you now have a 1:n protection architecture, while at the original PW [LSP] level you have a (1:1)^n protection architecture variant in which the protection connection monitoring is not performed on a per PW [LSP] protection connection [(1:1)^n SNC/S], but instead on the server-like SPME protection connection [(1:1)^n SNCG/I]. I suggest that we add this (1:1)^n SNCG/I to G.808.1.

Regards,
Maarten

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]] 
Sent: maandag 2 april 2012 12:50
To: 류정동; Maarten vissers; Gregory Mirsky; [email-masked]; Yaacov Weingarten; [email-masked]
Subject: RE: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01

eric

---

From: Maarten vissers <[email-masked]>
Date: Mon, 2 Apr 2012 12:14:32 +0000

Hi Eric,

I see where I misunderstood you. "request" in protection switching context is a reserved term for me.

What you are looking for is the assignment of what is called "entity number"s: W1, W2, W3, .. 

These entity numbers are assigned by connection management (NMS or control plane) when it sets up the protected connections. Both sides have to be configured with the same entity numbers, otherwise the APS protocol will fail. 

Because these entity numbers are present, one can re-use those numbers to express a priority order between Wi and Wj as specified in e.g. G.873.1. See below:

-----------------
[G.873.1] 8.10	Equal priority requests specifies the following:

-	In general, once a switch has been completed due to a request,
	it will not be overridden by another request of the same priority
	(first come, first served behaviour). 

-	When equal priority requests occur simultaneously, the conflict 
	is resolved in favour of the request with the lowest entity number. 
	# In bidirectional switching, a request received over the APS channel
	  with a lower entity number will always override an identical priority
	  local request with a higher entity number. 
	# Equal priority requests for the same entity number from both
	  sides of a bidirectional protection group are both considered
	  valid, and equivalent to a received "RR" from a near-end processing
	  standpoint.
-----------------

Regards,
Maarten

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]] 
Sent: maandag 2 april 2012 12:57
To: Maarten vissers; Gregory Mirsky; [email-masked]; Yaacov Weingarten; [email-masked]
Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01

eric

Yaacov

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 2 Apr 2012 16:57:46 -0400

Dear Maarten, Eric, et al.,
I think that "entity number" is good term to use from now in the discussion. Would you agree?
I think that the first bullet of the Maarten's quote is already present in the discussed document. Now, IMHO, we need to select what represents entity number and add appropriate description to case of simultaneous failure detection of two paths of equal priority. I think that Eric suggested to use Fpath's index as entity number. I think it is good solution to my question.

        Regards,
                Greg

-----Original Message-----
From: Maarten vissers [mailto:[email-masked]]
Sent: Monday, April 02, 2012 5:15 AM
To: Eric Osborne (eosborne); Gregory Mirsky; [email-masked]; Yaacov Weingarten; [email-masked]
Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01

Hi Eric,

-----------------

Regards,
Maarten

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]]
Sent: maandag 2 april 2012 12:57
To: Maarten vissers; Gregory Mirsky; [email-masked]; Yaacov Weingarten; [email-masked]
Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01

I'm not sure that answers my question, although it may be that it does and I don't understand it.

I think what you're talking about is the alarm hierarchy; that is, if I get both LOP and FS on the same LSP, FS 'wins'.  We have this behavior in 1:1 PSC already.  What we're trying to sort out with 1:n is what happens when two LSPs encounter the same failure condition.

If Wx and Wy both get SF, only one of them can be protected in 1:n.  In order to decide which one we need something deterministic.  Talking about 'priority' and 'tie-breakers' as if they were different makes no sense in this context.  If two LSPs are of the same priority due to a priority config on a network device, the tie-breaker will be something else.  As you and others have suggested, we can require the nodes to rely on the signaled FPath value, standardizing the fact that the lower value is alway of better priority.

The question Greg originally raised was essentially "how do we know what that priority scheme is?"  Our answer heretofore in the 1:n drafts has been "depends on the device, and both devices have to agree" but the more I look at it the more that doesn't make sense.

I think what we need is something akin to what you pointed out earlier is already done in MSP; lower numeric value for FPath always wins.

eric

Yaacov

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 3 Apr 2012 06:58:03 -0500

Hi Greg-

  I'm not sure I like 'entity number'.  This requires us to define the
working LSPs as 'entities' and we hadn't done so either in this draft or
in PSC (nor, for that matter, anywhere in TP as far as I can see).
What's wrong with just calling it 'priority'?

  As far as your second point, I still don't think I quite get it.  If
we use FPath as the priority for a given W-LSP, how will we ever get two
W-LSPs of the same priority in the same protection domain?  You cannot
have two LSPs with FPath=6, as there is no way to tell them apart.  In
other words, FPath is both the identifier *and* the priority, and since
the identifier must be unique in a given protection domain the priority
is thus unique.

  We could introduce the idea that operators may configure priorities
and that these need to be know a priori, but that's what we started with
in the 1ton draft.  The concern was raised that this can lead to interop
issues.  I see two ways out of this:

1) we specify in 1ton that an implementation MUST allow the operator to
configure a priority in the range 1..X  (perhaps 1..65535?) and that
this priority MUST be the same on both ends or else it is a misconfig.
The P-LSP for a given domain is, by definition, either priority 0 or
above the fray when it comes to priority.

2) we specify that an LSP's FPath is its priority, as I've described
above.

You seem to be suggesting we require both, and I'm not clear how that
would work.

eric

> Sent: Monday, April 02, 2012 4:58 PM
> To: Maarten vissers; Eric Osborne (eosborne); [email-masked];
> Yaacov Weingarten; [email-masked]
> I think that the first bullet of the Maarten's quote is already
present in
> the discussed document. Now, IMHO, we need to select what represents
> entity number and add appropriate description to case of simultaneous
> failure detection of two paths of equal priority. I think that Eric
> suggested to use Fpath's index as entity number. I think it is good
> solution to my question.
> 
>         Regards,
>                 Greg
> 
Yaacov
> I see where I misunderstood you. "request" in protection switching
context
> is a reserved term for me.
> 
> These entity numbers are assigned by connection management (NMS or
control
> plane) when it sets up the protected connections. Both sides have to
be
> configured with the same entity numbers, otherwise the APS protocol
will
> fail.
> 
> Because these entity numbers are present, one can re-use those numbers
to
> express a priority order between Wi and Wj as specified in e.g.
G.873.1.
> See below:
and
> I don't understand it.
in
> 1:1 PSC already.  What we're trying to sort out with 1:n is what
happens
> when two LSPs encounter the same failure condition.
> 
about
> 'priority' and 'tie-breakers' as if they were different makes no sense
in
> this context.  If two LSPs are of the same priority due to a priority
> config on a network device, the tie-breaker will be something else.
As
> you and others have suggested, we can require the nodes to rely on the
> signaled FPath value, standardizing the fact that the lower value is
alway
> of better priority.
more
> I look at it the more that doesn't make sense.
> 
is
> already done in MSP; lower numeric value for FPath always wins.
> 
> 
> 
> 
> 
> eric
> 
> > REC-G.873.1-201107-I!!PDF-E&type=items> ) the following
specification
> > this is the highest priority value determined from the near end
only.
> In
> > case where it is as high or higher than any request received from
the
> far
> > > A and a B networks. Otherwise maintenance on the network may
result
> > > prio1 and LER-Z thinks W3 has prio1, sorting this out is messy,
and
> > > > > - LER-A detects failure of working path Wi of priority M,
where
> M

---

From: Yaacov Weingarten <[email-masked]>
Date: Tue, 3 Apr 2012 22:40:18 +0300

Eric, et.al., hi

I am not sure what the confusion is - I think your first option is the
proper way for us to go, i.e. the operator can configure a "priority" for
an LSP that must be coordinated with both endpoints, and possibly causing a
misconfiguration error - this process [i.e. of assigning the priorities and
checking for misconfiguration] should be out-of-scope of the 1:n draft.
 The Path identifier (1..127) is only used as a "tiebreaker" in case two
working paths are simultaneously reporting an error condition that needs to
be protected.  This "tiebreaker" definition could be documented in the I-D
to address Greg's original comments.

Just my opinion,

yaacov

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 3 Apr 2012 16:13:11 -0400

Dear Yaacov, et al.,
Path Identifier is a reference to one of N LSPs that share the protection LSP. LER that recieves PSCv.2 (do we need acronym to differentiate Linear Protection PSC message from PSC message in 1:n?) need to find failed LSP priority. I think it might be reasonable to signal priority of failed path along with the Failed Path Index in a TLV, hence making it mandatory in PSCv.2.

    Regards,
        Greg

________________________________
From: Yaacov Weingarten [mailto:[email-masked]]
Sent: Tuesday, April 03, 2012 12:40 PM
To: Eric Osborne (eosborne)
Cc: Gregory Mirsky; Maarten vissers; [email-masked]; [email-masked]
Subject: Re: Comments on draft-ezy-mpls-1ton-protection-01

Eric, et.al<http://et.al>., hi

I am not sure what the confusion is - I think your first option is the proper way for us to go, i.e. the operator can configure a "priority" for an LSP that must be coordinated with both endpoints, and possibly causing a misconfiguration error - this process [i.e. of assigning the priorities and checking for misconfiguration] should be out-of-scope of the 1:n draft.  The Path identifier (1..127) is only used as a "tiebreaker" in case two working paths are simultaneously reporting an error condition that needs to be protected.  This "tiebreaker" definition could be documented in the I-D to address Greg's original comments.

Just my opinion,

yaacov

On Tue, Apr 3, 2012 at 2:58 PM, Eric Osborne (eosborne) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg-

eric

> From: Gregory Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
> To: Maarten vissers; Eric Osborne (eosborne); [email-masked]<mailto:[email-masked]>;
> Yaacov Weingarten; [email-masked]<mailto:[email-masked]>
present in
> From: Maarten vissers [mailto:[email-masked]<mailto:[email-masked]>]
> To: Eric Osborne (eosborne); Gregory Mirsky; [email-masked]<mailto:[email-masked]>;
Yaacov
> Weingarten; [email-masked]<mailto:[email-masked]>
context
control
be
will
to
G.873.1.
> From: Eric Osborne (eosborne) [mailto:[email-masked]<mailto:[email-masked]>]
> To: Maarten vissers; Gregory Mirsky; [email-masked]<mailto:[email-masked]>; Yaacov
> Weingarten; [email-masked]<mailto:[email-masked]>
and
in
happens
about
in
As
alway
more
is
> > From: Maarten vissers [mailto:[email-masked]<mailto:[email-masked]>]
> > To: Eric Osborne (eosborne); Gregory Mirsky; [email-masked]<mailto:[email-masked]>;
> Yaacov
> > Weingarten; [email-masked]<mailto:[email-masked]>
specification
only.
the
> > From: Eric Osborne (eosborne) [mailto:[email-masked]<mailto:[email-masked]>]
> > To: Maarten vissers; Gregory Mirsky; [email-masked]<mailto:[email-masked]>; Yaacov
> > Weingarten; [email-masked]<mailto:[email-masked]>
> > > From: Maarten vissers [mailto:[email-masked]<mailto:[email-masked]>]
> > > [email-masked]<mailto:[email-masked]>; Yaacov Weingarten; [email-masked]<mailto:[email-masked]>
> > > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
Behalf
> > > To: Eric Osborne (eosborne); Gregory Mirsky;
[email-masked]<mailto:[email-masked]>;
> > Yaacov
> > > Weingarten; [email-masked]<mailto:[email-masked]>
result
> > > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
Behalf
> > > To: Gregory Mirsky; [email-masked]<mailto:[email-masked]>; Yaacov Weingarten;
> > > [email-masked]<mailto:[email-masked]>
and
> > > > From: Gregory Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
> > > > To: Eric Osborne (eosborne); [email-masked]<mailto:[email-masked]>; Yaacov
> > Weingarten;
> > > > [email-masked]<mailto:[email-masked]>
> > > > From: Eric Osborne (eosborne) [mailto:[email-masked]<mailto:[email-masked]>]
> > > > To: Gregory Mirsky; [email-masked]<mailto:[email-masked]>; Yaacov Weingarten;
> > > > [email-masked]<mailto:[email-masked]>
> > > > > From: Gregory Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
> > > > > To: Eric Osborne (eosborne); [email-masked]<mailto:[email-masked]>; Yaacov
> > > Weingarten;
> > > > > [email-masked]<mailto:[email-masked]>
where
> > > > > From: Eric Osborne (eosborne) [mailto:[email-masked]<mailto:[email-masked]>]
> > > > > To: Gregory Mirsky; [email-masked]<mailto:[email-masked]>; Yaacov Weingarten;
> > > > > [email-masked]<mailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]>

---

From: Yaacov Weingarten <[email-masked]>
Date: Wed, 4 Apr 2012 15:39:05 +0300

Greg, hi

I see problems with the suggestion that each endpoint include the priority
of the working path in the PSC message -

1. If both endpoints are coordinated on the priority of the different
working paths then there is no difference between adding the priority to
the message or letting the endpoints make the decision based on their
configuration.  However, if there is a misconfiguration such that the
priority for Wj is different at LER-A and LER-Z then including the priority
in the message could cause problems.  Let's consider the scenario that was
described earlier in this thread - where one endpoint is reporting a SF on
Wj and the other endpoint is reporting a SF on Wk. We may end up with a
conflict between the endpoints as to which working path is being protected
at the point where a decision needs to be made!

2. PSC, as defined in RFC6378, is a simple protocol that has a
few idiosyncrasies - one of which is that the messages are constantly being
sent, adding the priority TLV is just additional chatter that will be using
up bandwidth on the protection path.

3. Another characteristic of PSC is that each endpoint continues to report
in the FPath field the identity of the working path that is currently
triggering that endpoint.  This may mean, e.g. in the case of
unidirectional faults or operator commands,  that the FPath of the messages
from the two endpoints may be different, e.g. LER-A may be sending SF(j,k)
while LER-Z is sending SF(k,k), and the question is whether the priority is
for the FPath or the Path field?

4. Keeping in mind that 1:n protection domain is characterized  by all n+1
paths having the same endpoints, I feel that dealing with the priorities at
the configuration level is just simpler, and defining the tiebreaker based
on the FPath index is rather straightforward.

For your consideration,
yaacov

On Tue, Apr 3, 2012 at 11:13 PM, Gregory Mirsky <[email-masked]
> wrote:

> **
> Dear Yaacov, et al.,
> Path Identifier is a reference to one of N LSPs that share the protection
> LSP. LER that recieves PSCv.2 (do we need acronym to differentiate Linear
> Protection PSC message from PSC message in 1:n?) need to find failed LSP
> priority. I think it might be reasonable to signal priority of failed path
> along with the Failed Path Index in a TLV, hence making it mandatory in
> PSCv.2.
>
>     Regards,
>         Greg
>
>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 4 Apr 2012 21:07:53 -0400

Hi Yaacov,
thank you for your detailed analysis. I agree with your arguments but would note that Path priority has to be checked first in the scenario we're discusing - simultaneous detection of bi-directional failure. PSC format v.2 implicitly, by FPath, refers to priority of a failed path (let's call it FPriority). And without explicitly signaling FPriority LER might end up in confused state if priorities of protected paths were misconfigured. I'm proposing to make signaling of FPriority explicit to expedite tiebraking and help to troubleshoot misconfiguration.

    Regards,
        Greg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaacov Weingarten
Sent: Wednesday, April 04, 2012 5:39 AM
To: [email-masked]
Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01

Greg, hi

I see problems with the suggestion that each endpoint include the priority of the working path in the PSC message -

1. If both endpoints are coordinated on the priority of the different working paths then there is no difference between adding the priority to the message or letting the endpoints make the decision based on their configuration.  However, if there is a misconfiguration such that the priority for Wj is different at LER-A and LER-Z then including the priority in the message could cause problems.  Let's consider the scenario that was described earlier in this thread - where one endpoint is reporting a SF on Wj and the other endpoint is reporting a SF on Wk. We may end up with a conflict between the endpoints as to which working path is being protected at the point where a decision needs to be made!

2. PSC, as defined in RFC6378, is a simple protocol that has a few idiosyncrasies - one of which is that the messages are constantly being sent, adding the priority TLV is just additional chatter that will be using up bandwidth on the protection path.

3. Another characteristic of PSC is that each endpoint continues to report in the FPath field the identity of the working path that is currently triggering that endpoint.  This may mean, e.g. in the case of unidirectional faults or operator commands,  that the FPath of the messages from the two endpoints may be different, e.g. LER-A may be sending SF(j,k) while LER-Z is sending SF(k,k), and the question is whether the priority is for the FPath or the Path field?

4. Keeping in mind that 1:n protection domain is characterized  by all n+1 paths having the same endpoints, I feel that dealing with the priorities at the configuration level is just simpler, and defining the tiebreaker based on the FPath index is rather straightforward.

For your consideration,
yaacov

On Tue, Apr 3, 2012 at 11:13 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Dear Yaacov, et al.,
Path Identifier is a reference to one of N LSPs that share the protection LSP. LER that recieves PSCv.2 (do we need acronym to differentiate Linear Protection PSC message from PSC message in 1:n?) need to find failed LSP priority. I think it might be reasonable to signal priority of failed path along with the Failed Path Index in a TLV, hence making it mandatory in PSCv.2.

    Regards,
        Greg