Subject: [mpls] Mode negotiation for PSC

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Thu, 8 Aug 2013 12:34:25 +0000

As per last Friday's presentation in Berlin (http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt), we will be adding "ITU Mode" to PSC to allow for behaviors that satisfy both IETF and ITU requirements.  This mode will be backward-compatible and negotiated using PSC TLVs.  

The drafts in that ppt define five capabilities which separate ITU mode from IETF mode.  IETF mode is defined as the absence of these five capabilities, and ITU mode is defined as the use of all five of these capabilities.  It may help to think of IETF mode as 00000 and ITU mode as 11111.  The mechanism to define and negotiate these modes will have room for expansion past five bits, so if we ever decide we need more capabilities negotiation in PSC (shared mesh?  m:n?  other fancy stuff?) we can.  

As of right now we are only discussing two modes, but it is possible to define a mode which is some combination of these five things other than 00000 or 11111.  So a mode is really the set of negotiated capabilities between two devices.

There are two ways we can negotiate the use of one more or the other:

1) Each node announces the mode that it wants, and if the other side doesn't want exactly the same mode then PSC will not function.  That is, both nodes say "my mode is 0bxxxxx" (for now, either 00000 or 11111) and if both nodes don't say the same thing then they complain to the operator and refuse to function.

Advantage: easy, and if both ends are in a single administrative domain I expect the operator to be able to configure both ends to match.

Disadvantage: tricky if we ever start talking about modes other than 00000 or 11111.  I don't want a node to say "I support mode 00000, mode 00001, mode 00010, mode 00011, .... mode 11111" because if we add a few more capabilities we could end up announcing the support of hundreds or thousands of modes.  Does not allow PSC to come up unless the modes match on both sides, even if there is some common subset they could both agree on.

or

2) Each node announces the set of capabilities that it can support along with the ones that it requires, and if the two nodes can find a common subset of features then they will converge on those features in PSC.

Advantage: flexible.  If two endpoints can find a common feature subset (see example below) then they will come up.

Disadvantage: more complex code, easier to get wrong and converge on a undesirable subset.

Examples of each negotiation method are below, both for clarity and to demonstrate that method #2 works.  My question for the WG is, which one would people prefer, and why?

eric

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

Examples
========
All examples are between two nodes, A and Z.  These examples focus on the actual negotiation, not on the necessary TLV bits to enable the negotiation.

Example of method 1
-------------------
Node A sends a single TLV to Node Z containg the mode bitmap.  Node Z sends the same to A.  Call them A.Mode and Z.Mode.  If they do not match then some default behavior happens - either PSC doesn't come up or they default to one predetermined mode.

A.mode = Z. mode = 00000
A->Z: "I am configured for mode 00000"
Z->A: "I am configured for mode 00000"

This results in PSC coming up in IETF mode.

A.mode = Z.mode = 11111
A->Z: "I am configured for mode 11111"
Z->A: "I am configured for mode 11111"

This results in PSC coming up in ITU mode.

A.mode != Z.mode (say, 00001 and 00010)
A->Z: "I am configured for mode 00001"
Z->A: "I am configured for mode 00010"

PSC does not come up.

Example of method 2
-------------------
Both Node A and Node Z announce two things - Capabilities and Mask.
Capabilities is a bitmap of the capabilities that are supported.
Mask is a mask of don't-care bits against the Capabilities string.  A 0 in Mask means "I don't care if we do this capability or not", and a 1 means "we must (or must not) agree on this capability in order to come up".

A.capabilities = 00000
A.mask         = 00000

This says "I am capable of supporting all capabilities and I don't care if we do any of them or not"

A.capabilities = 00000
A.mask         = 11111

This says "We must not use any of the optional capabilities" - Capabilities bits are all zero, and Mask bits say "we must agree that the corresponding capability is zero".  This is 'IETF mode'.

A.capabilities = 11111
A.mask         = 11111

This is 'ITU Mode'

Where it gets complicated (or awesome, depending on your perspective) is when you have various subsets.  Consider:

A.Capabilities == 01100
A.Mask == 01100

Z.Capabilities == 01110
Z.Mask == 01110

Negotiation procedures.
Each side does:

res = (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask)
res = (01100 & 01110) ^ (01110 & 01100)
res = (01100) ^ (01100)
res = 00000

if res == 0 then it is possible for both sides to find a common subset that they support.
This common subset is called the 'negotiated set', and is determined by:

negotiated_set = A.Capabilities | B.Capabilities
negotiated_set = 01100 | 01110 
negotiated_set = 01100

if res != 0 then it is impossible to find a subset that the two ends can agree on, and PSC will never come up.

Once each side computes the negotiated set, they signal it and PSC starts to work.

---

From: Loa Andersson <[email-masked]>
Date: Mon, 12 Aug 2013 10:27:22 +0200

Eric,

On 2013-08-08 14:34, Eric Osborne (eosborne) wrote:
<snip>

> Example of method 2

Why is this not

  A.capabilities = 11111
  A.mask         = 00000

?

/Loa

> This says "I am capable of supporting all capabilities and I don't care if we do any of them or not"
<snip>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 12 Aug 2013 22:08:48 +0200

Hej Loa,

You wondered:

>> Mask is a mask of don't-care bits against the Capabilities string.  A
>> 0 in Mask means "I don't care if we do this capability or not", and a
>> 1 means "we must (or must not) agree on this capability in order to
>> come up".
>>
>> A.capabilities = 00000
>> A.mask         = 00000
>
> Why is this not
>
>   A.capabilities = 11111
>   A.mask         = 00000
>
> ?

This latter is indeed what node A should indicate for
  "I am capable of supporting all capabilities and I don't
   care if we do any of them or not"

Regards, Huub.

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样

---

From: [email-masked]
Date: Thu, 15 Aug 2013 13:00:37 -0400

Hi Eric,

I have only seen one message on this thread so I will venture an opinion.

My preference is for option 1 - no negotiation.

My reasons are:

Keep it simple!

The major reason that network operator's have given for requesting these 
enhanced capabilities is to maintain compatibility with existing linear 
protection schemes. Within the network of a single operator my assumption 
is that they want, above all else, consistent operation.  Therefore, I 
suspect that we will see two "camps" with either all options active or no 
options active.

Interconnection of "transport" connections between network operators is 
normally only allowed within the frame work of an agreement between the 
operators. As part of that agreement they would need to define the linear 
protection options that would be used. The operational differences would 
be confined to the links that provide the interconnection between networks 
of the different operators. The appropriate protection options would be 
configured (as defined by the agreement) when the protected connection is 
set-up.

Negotiation would allow the possibility of a variety of protection options 
being active in the network which would result in inconsistent behaviour 
which would create operational complexity.

Regards,

Malcolm

"Eric Osborne (eosborne)" <[email-masked]> 
Sent by: [email-masked]
08/08/2013 08:34 AM

To
"[email-masked]" <[email-masked]>
cc

Subject
[mpls] Mode negotiation for PSC

As per last Friday's presentation in Berlin (
http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt), we will 
be adding "ITU Mode" to PSC to allow for behaviors that satisfy both IETF 
and ITU requirements.  This mode will be backward-compatible and 
negotiated using PSC TLVs. 

The drafts in that ppt define five capabilities which separate ITU mode 
from IETF mode.  IETF mode is defined as the absence of these five 
capabilities, and ITU mode is defined as the use of all five of these 
capabilities.  It may help to think of IETF mode as 00000 and ITU mode as 
11111.  The mechanism to define and negotiate these modes will have room 
for expansion past five bits, so if we ever decide we need more 
capabilities negotiation in PSC (shared mesh?  m:n?  other fancy stuff?) 
we can. 

As of right now we are only discussing two modes, but it is possible to 
define a mode which is some combination of these five things other than 
00000 or 11111.  So a mode is really the set of negotiated capabilities 
between two devices.

1) Each node announces the mode that it wants, and if the other side 
doesn't want exactly the same mode then PSC will not function.  That is, 
both nodes say "my mode is 0bxxxxx" (for now, either 00000 or 11111) and 
if both nodes don't say the same thing then they complain to the operator 
and refuse to function.

Advantage: easy, and if both ends are in a single administrative domain I 
expect the operator to be able to configure both ends to match.

Disadvantage: tricky if we ever start talking about modes other than 00000 
or 11111.  I don't want a node to say "I support mode 00000, mode 00001, 
mode 00010, mode 00011, .... mode 11111" because if we add a few more 
capabilities we could end up announcing the support of hundreds or 
thousands of modes.  Does not allow PSC to come up unless the modes match 
on both sides, even if there is some common subset they could both agree 
on.

or

2) Each node announces the set of capabilities that it can support along 
with the ones that it requires, and if the two nodes can find a common 
subset of features then they will converge on those features in PSC.

Advantage: flexible.  If two endpoints can find a common feature subset 
(see example below) then they will come up.

Disadvantage: more complex code, easier to get wrong and converge on a 
undesirable subset.

Examples of each negotiation method are below, both for clarity and to 
demonstrate that method #2 works.  My question for the WG is, which one 
would people prefer, and why?

eric

Examples
========
All examples are between two nodes, A and Z.  These examples focus on the 
actual negotiation, not on the necessary TLV bits to enable the 
negotiation.

Example of method 1
-------------------
Node A sends a single TLV to Node Z containg the mode bitmap.  Node Z 
sends the same to A.  Call them A.Mode and Z.Mode.  If they do not match 
then some default behavior happens - either PSC doesn't come up or they 
default to one predetermined mode.

A.mode = Z. mode = 00000

A.mode = Z.mode = 11111

PSC does not come up.

Example of method 2
-------------------
Both Node A and Node Z announce two things - Capabilities and Mask.
Capabilities is a bitmap of the capabilities that are supported.
Mask is a mask of don't-care bits against the Capabilities string.  A 0 in 
Mask means "I don't care if we do this capability or not", and a 1 means 
"we must (or must not) agree on this capability in order to come up".

A.capabilities = 00000
A.mask         = 00000

This says "I am capable of supporting all capabilities and I don't care if 
we do any of them or not"

A.capabilities = 00000
A.mask         = 11111

This says "We must not use any of the optional capabilities" - 
Capabilities bits are all zero, and Mask bits say "we must agree that the 
corresponding capability is zero".  This is 'IETF mode'.

A.capabilities = 11111
A.mask         = 11111

This is 'ITU Mode'

Where it gets complicated (or awesome, depending on your perspective) is 
when you have various subsets.  Consider:

A.Capabilities == 01100
A.Mask == 01100

Z.Capabilities == 01110
Z.Mask == 01110

Negotiation procedures.
Each side does:

if res == 0 then it is possible for both sides to find a common subset 
that they support.
This common subset is called the 'negotiated set', and is determined by:

if res != 0 then it is impossible to find a subset that the two ends can 
agree on, and PSC will never come up.

Once each side computes the negotiated set, they signal it and PSC starts 
to work.
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 15 Aug 2013 21:12:13 +0200

Hello Malcolm,

I also support the first way of "negotiation" described by Eric.

In addition to your reasons:

This way is very easy to test, it passes or it fails.
If it passes both ends were provisioned correctly,
if it fails the provisioning was wrong, the report can
include the received set of options for verification.

This works also in case the operator provisions only a subset of
all supported options. There is also no need to advertise multiple
modes as Eric describes.

Best regards, Huub.
===================

> protection schemes. Within the network of a single operator my
> assumption is that they want, above all else, consistent operation.
>   Therefore, I suspect that we will see two "camps" with either all
> options active or no options active.
>
> operators. As part of that agreement they would need to define the
> linear protection options that would be used. The operational
> differences would be confined to the links that provide the
> interconnection between networks of the different operators. The
> appropriate protection options would be configured (as defined by the
> agreement) when the protected connection is set-up.
>
> Negotiation would allow the possibility of a variety of protection
> options being active in the network which would result in inconsistent
> behaviour which would create operational complexity.
>
> Regards,
>
> Malcolm
>
>
>
>
> *"Eric Osborne (eosborne)" <[email-masked]>*
> As per last Friday's presentation in Berlin
> (http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt), we
> will be adding "ITU Mode" to PSC to allow for behaviors that satisfy
> both IETF and ITU requirements.  This mode will be backward-compatible
> and negotiated using PSC TLVs.
>
> capabilities.  It may help to think of IETF mode as 00000 and ITU mode
> as 11111.  The mechanism to define and negotiate these modes will have
> room for expansion past five bits, so if we ever decide we need more
> if both nodes don't say the same thing then they complain to the
> operator and refuse to function.
>
> Advantage: easy, and if both ends are in a single administrative domain
> I expect the operator to be able to configure both ends to match.
>
> Disadvantage: tricky if we ever start talking about modes other than
> 00000 or 11111.  I don't want a node to say "I support mode 00000, mode
> 00001, mode 00010, mode 00011, .... mode 11111" because if we add a few
> more capabilities we could end up announcing the support of hundreds or
> thousands of modes.  Does not allow PSC to come up unless the modes
> match on both sides, even if there is some common subset they could both
> agree on.
>
>
> or
>
>
> All examples are between two nodes, A and Z.  These examples focus on
> the actual negotiation, not on the necessary TLV bits to enable the
> negotiation.
>
> Example of method 1
> -------------------
> Mask is a mask of don't-care bits against the Capabilities string.  A 0
> in Mask means "I don't care if we do this capability or not", and a 1
> means "we must (or must not) agree on this capability in order to come up".
>
> A.capabilities = 00000
> A.mask         = 00000
>
> Capabilities bits are all zero, and Mask bits say "we must agree that
> the corresponding capability is zero".  This is 'IETF mode'.
>
> A.capabilities = 11111
> A.mask         = 11111
>
> This is 'ITU Mode'
>

---

From: Yuji Tochio <[email-masked]>
Date: Fri, 16 Aug 2013 08:14:39 +0900

Hi Eric and all

My preference is option 1 and I also ask for the No negotioation.
Rather than (As well as) negotiation, the configuration to NE can also safisty
the case in transport network.

Regards, Yuji

(2013/08/16 2:00), [email-masked] wrote:
> The major reason that network operator's have given for requesting these enhanced capabilities is to maintain compatibility with existing linear protection
> schemes. Within the network of a single operator my assumption is that they want, above all else, consistent operation. Therefore, I suspect that we will see
> two "camps" with either all options active or no options active.
>
> Interconnection of "transport" connections between network operators is normally only allowed within the frame work of an agreement between the operators. As
> part of that agreement they would need to define the linear protection options that would be used. The operational differences would be confined to the links
> that provide the interconnection between networks of the different operators. The appropriate protection options would be configured (as defined by the
> Negotiation would allow the possibility of a variety of protection options being active in the network which would result in inconsistent behaviour which
> would create operational complexity.
>
> Regards,
>
> Malcolm
>
>
>
>
> As per last Friday's presentation in Berlin (http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt), we will be adding "ITU Mode" to PSC to allow
> for behaviors that satisfy both IETF and ITU requirements. This mode will be backward-compatible and negotiated using PSC TLVs.
>
> The drafts in that ppt define five capabilities which separate ITU mode from IETF mode. IETF mode is defined as the absence of these five capabilities, and
> ITU mode is defined as the use of all five of these capabilities. It may help to think of IETF mode as 00000 and ITU mode as 11111. The mechanism to define
> and negotiate these modes will have room for expansion past five bits, so if we ever decide we need more capabilities negotiation in PSC (shared mesh? m:n?
> other fancy stuff?) we can.
>
> As of right now we are only discussing two modes, but it is possible to define a mode which is some combination of these five things other than 00000 or
> 11111. So a mode is really the set of negotiated capabilities between two devices.
>
> 1) Each node announces the mode that it wants, and if the other side doesn't want exactly the same mode then PSC will not function. That is, both nodes say
> "my mode is 0bxxxxx" (for now, either 00000 or 11111) and if both nodes don't say the same thing then they complain to the operator and refuse to function.
>
> Disadvantage: tricky if we ever start talking about modes other than 00000 or 11111. I don't want a node to say "I support mode 00000, mode 00001, mode 00010,
> mode 00011, .... mode 11111" because if we add a few more capabilities we could end up announcing the support of hundreds or thousands of modes. Does not
> allow PSC to come up unless the modes match on both sides, even if there is some common subset they could both agree on.
>
>
> or
>
>
> 2) Each node announces the set of capabilities that it can support along with the ones that it requires, and if the two nodes can find a common subset of
> features then they will converge on those features in PSC.
>
> Node A sends a single TLV to Node Z containg the mode bitmap. Node Z sends the same to A. Call them A.Mode and Z.Mode. If they do not match then some default
> behavior happens - either PSC doesn't come up or they default to one predetermined mode.
>
> A.mode = Z. mode = 00000
> Mask is a mask of don't-care bits against the Capabilities string. A 0 in Mask means "I don't care if we do this capability or not", and a 1 means "we must
> (or must not) agree on this capability in order to come up".
>
> A.capabilities = 00000
> A.mask = 00000
>
> This says "We must not use any of the optional capabilities" - Capabilities bits are all zero, and Mask bits say "we must agree that the corresponding
> capability is zero". This is 'IETF mode'.
>
> A.capabilities = 11111
> A.mask = 11111
>
> This is 'ITU Mode'
>

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Fri, 16 Aug 2013 20:48:49 +0000

Hi Loa- 

  See inline

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Monday, August 12, 2013 1:27 AM
> To: Eric Osborne (eosborne)
> Cc: [email-masked]
> Subject: Re: [mpls] Mode negotiation for PSC
> 
> Eric,
> 
> 
> 
> 0 in Mask means "I don't care if we do this capability or not", and a 1

Althought I didn't put it in my email, a capabilties of 1 and mask of 0 is illegal.  This is partly because it makes no sense ("I require this capability but I don't care if we do it or not") and partly because there's a case which doesn't converge right:

If I have 11111/00000 on one side and 00000/00000 on the other I end up with

A.cap = 11111, A.mask = 00000
Z.cap = 00000, Z.mask = 00000

res = (111111 & 00000) ^ (00000 & 00000)
res = 11111 ^ 00000 = 11111

and if res != 0 then the nodes can't converge on a common subset, even though there are 2^5 combinations that would work for both nodes.

eric

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Fri, 16 Aug 2013 20:48:50 +0000

Hi Malcolm-

  Thanks for this.  A few comments inline.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, August 15, 2013 1:01 PM
> Cc: [email-masked]; [email-masked]

That's what it looks like now.  But I'm not terribly good at predicting what people will never, ever do.  I could see an implementation which wants to support, say, MS-W but none of the other options.

> agreement) when the protected connection is set-up.

PSC has bits to indicate the protection type and revertive mode, and the logic we're going to add n draft-osborne explains what happens if two sides disagree.  Is this not a form of negotiatoin?

> behaviour which would create operational complexity.

It is possible for one side to declare intransigence by setting the mask bits to all 1s.  This indicates that the Capabilities advertised by that node must match exactly in order for things to work.  The two modes I think we'll see first are:

Cap=00000, Mask=11111
Cap=11111, Mask=11111

and these two will never agree on a mode since the mask of all 1s gives neither side any room to move.

I'm not against the simpler mode, I just want to make sure that you understand that it is possible to achieve that using the proposed negotiation method.

eric

> 08/08/2013 08:34 AM To
> (http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt
> <http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt> ), we
> <https://www.ietf.org/mailman/listinfo/mpls>
>

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Mon, 19 Aug 2013 13:20:22 +0000

Eric, it is a little bit confusing.

See [JR] inline...

________________________________
From : "Eric Osborne (eosborne)" <[email-masked]>
Sent : 2013-08-17 05:49:16 ( +09:00 )
To : Loa Andersson <[email-masked]>
Cc : [email-masked] <[email-masked]>
Subject : Re: [mpls] Mode negotiation for PSC

Hi Loa-

See inline

Althought I didn't put it in my email, a capabilties of 1 and mask of 0 is illegal. This is partly because it makes no sense ("I require this capability but I don't care if we do it or not") and partly because there's a case which doesn't converge right:
[JR] The meaning of cap=11111 and mask=00000 would be "I am capable of all five things but I don't care if we do it or not"

res = (111111 & 00000) ^ (00000 & 00000)
res = 11111 ^ 00000 = 11111
[JR] The answer for (11111 & 00000) should be 00000. And the final result of 00000 ^ 00000 will be 00000.

[JR] Now, two ends will operate without any capabilities.

eric

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Mon, 19 Aug 2013 14:41:34 +0000

Eric,

In the negotiation procedure of Method 2, you seem to be assuming that if one side has a capability, then it can also operate without that particular capability, because with the following caps/masks for A and Z:
"A.Capabilities == 01100
A.Mask == 01100
Z.Capabilities == 01110
Z.Mask == 01110"
you concluded "negotiated_set = 01100"

However, that assumption is not true in general.
Depending on the nature of the capability, we would need a completely different set of state machines to support the case that disables the capability.

Best regards,

Jeong-dong

________________________________
From : "Eric Osborne (eosborne)" <[email-masked]>
Sent : 2013-08-08 21:34:55 ( +09:00 )
To : [email-masked] <[email-masked]>
Cc :
Subject : [mpls] Mode negotiation for PSC

or

eric

Examples
========

Example of method 1
-------------------

A.mode = Z. mode = 00000

A.mode = Z.mode = 11111

PSC does not come up.

Example of method 2
-------------------

A.capabilities = 00000
A.mask = 00000

A.capabilities = 00000
A.mask = 11111

A.capabilities = 11111
A.mask = 11111

This is 'ITU Mode'

A.Capabilities == 01100
A.Mask == 01100

Z.Capabilities == 01110
Z.Mask == 01110

Negotiation procedures.
Each side does:

---

From: Eric Gray <[email-masked]>
Date: Tue, 20 Aug 2013 18:41:49 +0000

Eric (Osborne),

	While I agree that we don't want to try to predict what will never ever
happen, there is more than a little bit of an issue with designing for all possible
cases.

	Before we can really get away with any approach that could conceivably
include N^2 combinations of options, we need to describe what each of these
possibilities means, and how devices with arbitrary disagreement for the options
resolve the differences.

	And - while we're trying to cover the possible cases for known modes, 
should we also try to allow for coverage of future (thus unknown) modes?

	Is this worth the trouble?  Are there use cases to support this, or are we
embarking on an academic exercise?

	What we really need now is a simple binary indicator.  If we feel that any
negotiation is required, then it should be trivial.  If there is disagreement, then
everbody falls-back to a default mode.

	But I am not convinced that any form of negotiation is required.

	In this discussion, I am reminded that at least part of the discussion that
got us on the road of having two modes had to do with limited negotiation in the
case where PSC parameters did not match.  I believe that the decision was that
reporting the inconsistency to the operator was sufficient from the perspective 
of any of us in the IETF, and that this was not sufficient to folks used to dealing 
with APS.

	So, are we switching from what was essentially non-negotiation of PSC
parameters to negotiation of PSC modes?  Seems counter-intuitive to me...

--
Eric (Gray)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Osborne (eosborne)
Sent: Friday, August 16, 2013 4:49 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Mode negotiation for PSC

Hi Malcolm-

> The major reason that network operator's have given for requesting 
> these enhanced capabilities is to maintain compatibility with existing 
> linear protection schemes. Within the network of a single operator my 

> Interconnection of "transport" connections between network operators 
> is normally only allowed within the frame work of an agreement between 
> the operators. As part of that agreement they would need to define the 

Cap=00000, Mask=11111
Cap=11111, Mask=11111

eric

> 
> Regards,
> 
> Malcolm
> 
> 
> 
> 
> 
> "Eric Osborne (eosborne)" <[email-masked]> Sent by: 
> [email-masked]
> 
> 08/08/2013 08:34 AM To
> <http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt> ), 
> we will be adding "ITU Mode" to PSC to allow for behaviors that 
> satisfy both IETF and ITU requirements.  This mode will be 
> backward-compatible and negotiated using PSC TLVs.
> 
> The drafts in that ppt define five capabilities which separate ITU 
> mode from IETF mode.  IETF mode is defined as the absence of these 
> five capabilities, and ITU mode is defined as the use of all five of 
> these capabilities.  It may help to think of IETF mode as 00000 and 
> ITU mode as 11111.  The mechanism to define and negotiate these modes 
> will have room for expansion past five bits, so if we ever decide we 
> need more capabilities negotiation in PSC (shared mesh?  m:n?  other 
> fancy stuff?) we can.
> 
> As of right now we are only discussing two modes, but it is possible 
> to define a mode which is some combination of these five things other 
> than
> 00000 or 11111.  So a mode is really the set of negotiated 
> capabilities between two devices.
> 
> doesn't want exactly the same mode then PSC will not function.  That 
> is, both nodes say "my mode is 0bxxxxx" (for now, either 00000 or 
> 11111) and if both nodes don't say the same thing then they complain 
> to the operator and refuse to function.
> 
> Advantage: easy, and if both ends are in a single administrative 
> domain I expect the operator to be able to configure both ends to match.
> 
> 00000 or 11111.  I don't want a node to say "I support mode 00000, 
> mode 00001, mode 00010, mode 00011, .... mode 11111" because if we add 
> a few more capabilities we could end up announcing the support of 
> hundreds or thousands of modes.  Does not allow PSC to come up unless 
> the modes match on both sides, even if there is some common subset 
> they could both agree on.
> 
> 
> or
> 
> 
> 2) Each node announces the set of capabilities that it can support 
> along with the ones that it requires, and if the two nodes can find a 
> common subset of features then they will converge on those features in PSC.
> 
> Advantage: flexible.  If two endpoints can find a common feature 
> subset (see example below) then they will come up.
> 
> demonstrate that method #2 works.  My question for the WG is, which 
> one would people prefer, and why?
> 
> 
> 
> 
> 
> 
> eric
> 
> 
> sends the same to A.  Call them A.Mode and Z.Mode.  If they do not 
> match then some default behavior happens - either PSC doesn't come up 
> or they default to one predetermined mode.
> 
> A.mode = Z. mode = 00000
> Where it gets complicated (or awesome, depending on your perspective) 
> is when you have various subsets.  Consider:
> 
> A.Capabilities == 01100
> A.Mask == 01100
> 
> Z.Capabilities == 01110
> Z.Mask == 01110
> 
> 
> Negotiation procedures.
> Each side does:
> 
> 
> res = (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask) res = 
> (01100 & 01110) ^ (01110 & 01100) res = (01100) ^ (01100) res = 00000
> 
> negotiated_set = A.Capabilities | B.Capabilities negotiated_set = 
> 01100 | 01110 negotiated_set = 01100
> 
> if res != 0 then it is impossible to find a subset that the two ends 
> can agree on, and PSC will never come up.
>

---

From: [email-masked]
Date: Wed, 21 Aug 2013 11:43:53 -0400

Hi Eric (Gray),

I agree that we should not negotiate PSC modes "on the fly", since 
selecting different options will result in different behaviour in the 
network any negotiation should involve a human i..e reporting the miss 
match is all that we need to do.

As I pointed out below "negotiation" of the PSC options should take place 
before the LSP is set-up, PSC should only check that the options selected 
match (and report a miss match).

Regards,

Malcolm

Eric Gray <[email-masked]> 
20/08/2013 02:41 PM

To
"Eric Osborne (eosborne)" <[email-masked]>, "[email-masked]" 
<[email-masked]>
cc
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
Subject
RE: [mpls] Mode negotiation for PSC

Eric (Osborne),

                 While I agree that we don't want to try to predict what 
will never ever
happen, there is more than a little bit of an issue with designing for all 
possible
cases.

                 Before we can really get away with any approach that 
could conceivably
include N^2 combinations of options, we need to describe what each of 
these
possibilities means, and how devices with arbitrary disagreement for the 
options
resolve the differences.

                 And - while we're trying to cover the possible cases for 
known modes, 
should we also try to allow for coverage of future (thus unknown) modes?

                 Is this worth the trouble?  Are there use cases to 
support this, or are we
embarking on an academic exercise?

                 What we really need now is a simple binary indicator.  If 
we feel that any
negotiation is required, then it should be trivial.  If there is 
disagreement, then
everbody falls-back to a default mode.

                 But I am not convinced that any form of negotiation is 
required.

                 In this discussion, I am reminded that at least part of 
the discussion that
got us on the road of having two modes had to do with limited negotiation 
in the
case where PSC parameters did not match.  I believe that the decision was 
that
reporting the inconsistency to the operator was sufficient from the 
perspective 
of any of us in the IETF, and that this was not sufficient to folks used 
to dealing 
with APS.

                 So, are we switching from what was essentially 
non-negotiation of PSC
parameters to negotiation of PSC modes?  Seems counter-intuitive to me...

--
Eric (Gray)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Eric Osborne (eosborne)

Hi Malcolm-

> options active or no options active.

That's what it looks like now.  But I'm not terribly good at predicting 
what people will never, ever do.  I could see an implementation which 
wants to support, say, MS-W but none of the other options.

> agreement) when the protected connection is set-up.

PSC has bits to indicate the protection type and revertive mode, and the 
logic we're going to add n draft-osborne explains what happens if two 
sides disagree.  Is this not a form of negotiatoin?

> behaviour which would create operational complexity.

It is possible for one side to declare intransigence by setting the mask 
bits to all 1s.  This indicates that the Capabilities advertised by that 
node must match exactly in order for things to work.  The two modes I 
think we'll see first are:

Cap=00000, Mask=11111
Cap=11111, Mask=11111

and these two will never agree on a mode since the mask of all 1s gives 
neither side any room to move.

I'm not against the simpler mode, I just want to make sure that you 
understand that it is possible to achieve that using the proposed 
negotiation method.

eric

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 22 Aug 2013 13:27:25 +0100

Maybe don't call it "negotiation" if no negotiation is to be allowed.
 
Call in "mode confirmation" or something?
 
Adrian
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 21 August 2013 16:44
To: Eric Gray
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Mode negotiation for PSC
 
Hi Eric (Gray), 

I agree that we should not negotiate PSC modes "on the fly", since selecting
different options will result in different behaviour in the network any
negotiation should involve a human i..e reporting the miss match is all that we
need to do. 

As I pointed out below "negotiation" of the PSC options should take place before
the LSP is set-up, PSC should only check that the options selected match (and
report a miss match). 

Regards, 

Malcolm 

To

cc
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

Subject

Eric (Osborne),

                While I agree that we don't want to try to predict what will
never ever
happen, there is more than a little bit of an issue with designing for all
possible
cases.

                Before we can really get away with any approach that could
conceivably
include N^2 combinations of options, we need to describe what each of these
possibilities means, and how devices with arbitrary disagreement for the options
resolve the differences.

                And - while we're trying to cover the possible cases for known
modes, 
should we also try to allow for coverage of future (thus unknown) modes?

                Is this worth the trouble?  Are there use cases to support this,
or are we
embarking on an academic exercise?

                What we really need now is a simple binary indicator.  If we
feel that any
negotiation is required, then it should be trivial.  If there is disagreement,
then
everbody falls-back to a default mode.

                In this discussion, I am reminded that at least part of the
discussion that
got us on the road of having two modes had to do with limited negotiation in the
case where PSC parameters did not match.  I believe that the decision was that
reporting the inconsistency to the operator was sufficient from the perspective 
of any of us in the IETF, and that this was not sufficient to folks used to
dealing 
with APS.

                So, are we switching from what was essentially non-negotiation
of PSC
parameters to negotiation of PSC modes?  Seems counter-intuitive to me...

--
Eric (Gray)

-----Original Message-----
From: [email-masked] [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of Eric Osborne (eosborne)
Sent: Friday, August 16, 2013 4:49 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Mode negotiation for PSC

Hi Malcolm-

> From: [email-masked] [ <mailto:[email-masked]>
mailto:[email-masked]]
> options active or no options active.

That's what it looks like now.  But I'm not terribly good at predicting what
people will never, ever do.  I could see an implementation which wants to
support, say, MS-W but none of the other options.

> agreement) when the protected connection is set-up.

PSC has bits to indicate the protection type and revertive mode, and the logic
we're going to add n draft-osborne explains what happens if two sides disagree.
Is this not a form of negotiatoin?

> behaviour which would create operational complexity.

It is possible for one side to declare intransigence by setting the mask bits to
all 1s.  This indicates that the Capabilities advertised by that node must match
exactly in order for things to work.  The two modes I think we'll see first are:

Cap=00000, Mask=11111
Cap=11111, Mask=11111

and these two will never agree on a mode since the mask of all 1s gives neither
side any room to move.

I'm not against the simpler mode, I just want to make sure that you understand
that it is possible to achieve that using the proposed negotiation method.

eric

> ( <http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt>
http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt
> < <http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt>
http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt> ), 
> < <https://www.ietf.org/mailman/listinfo/mpls>
https://www.ietf.org/mailman/listinfo/mpls>

---

From: Eric Gray <[email-masked]>
Date: Thu, 22 Aug 2013 13:35:48 +0000

Malcolm,

                Agreed.  See continuing discussion thread on why we might not want to
call this "negotiation."  There is no negotiation if an exact match is required...

--
Eric

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 21, 2013 11:44 AM
To: Eric Gray
Cc: Eric Osborne (eosborne); [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] Mode negotiation for PSC
Importance: High

Hi Eric (Gray),

I agree that we should not negotiate PSC modes "on the fly", since selecting different options will result in different behaviour in the network any negotiation should involve a human i..e reporting the miss match is all that we need to do.

As I pointed out below "negotiation" of the PSC options should take place before the LSP is set-up, PSC should only check that the options selected match (and report a miss match).

Regards,

Malcolm

Eric Gray <[email-masked]<mailto:[email-masked]>>

20/08/2013 02:41 PM

To

"Eric Osborne (eosborne)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

cc

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Subject

Eric (Osborne),

--
Eric (Gray)

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Eric Osborne (eosborne)
Sent: Friday, August 16, 2013 4:49 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Mode negotiation for PSC

Hi Malcolm-

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Cap=00000, Mask=11111
Cap=11111, Mask=11111

eric

>
> Regards,
>
> Malcolm
>
>
>
>
>
> "Eric Osborne (eosborne)" <[email-masked]<mailto:[email-masked]>> Sent by:
> [email-masked]<mailto:[email-masked]>
>
> 08/08/2013 08:34 AM To
> "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> cc
> Subject
> [email-masked]<mailto:[email-masked]>

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

---

From: [email-masked]
Date: Thu, 22 Aug 2013 10:15:07 -0400

Hi Eric (Gray)

I agree, if we conclude that we do not want to support negotiation in the 
PSC protocol we should call this "option confirmation" as Adrian 
suggested.  The term "mode" is already used in RFC6378 e.g. revertive 
mode, non-revertive mode etc.

Regards,

Malcolm

22/08/2013 09:35 AM

To
"[email-masked]" <[email-masked]>
cc
"Eric Osborne (eosborne)" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject
RE: [mpls] Mode negotiation for PSC

Malcolm,
 
                Agreed.  See continuing discussion thread on why we might 
not want to 
call this "negotiation."  There is no negotiation if an exact match is 
required…
 
--
Eric
 
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 21, 2013 11:44 AM
To: Eric Gray
Cc: Eric Osborne (eosborne); [email-masked]; [email-masked]; 
[email-masked]
Subject: RE: [mpls] Mode negotiation for PSC
Importance: High
 
Hi Eric (Gray), 

Regards, 

Malcolm 

To
"Eric Osborne (eosborne)" <[email-masked]>, "[email-masked]" 
<[email-masked]> 
cc
"[email-masked]" <[email-masked]>, "[email-masked]" <
[email-masked]> 
Subject
RE: [mpls] Mode negotiation for PSC

Eric (Osborne),

                Is this worth the trouble?  Are there use cases to support 
this, or are we
embarking on an academic exercise?

--
Eric (Gray)

-----Original Message-----

Hi Malcolm-

Cap=00000, Mask=11111
Cap=11111, Mask=11111

eric

---

From: Loa Andersson <[email-masked]>
Date: Thu, 22 Aug 2013 16:29:35 +0200

Folks,

(chair hat off).

This is possible well covered ground, but an innocent question from
someone are doing the duck-trick.

Would it make sense for a implementation to only support a of the
functions?

I think I've heard both yes and not to that question.

/Loa

On 2013-08-22 16:15, [email-masked] wrote:
> Hi Eric (Gray)
>
> I agree, if we conclude that we do not want to support negotiation in
> the PSC protocol we should call this "option confirmation" as Adrian
> *Eric Gray <[email-masked]>*
>
> 22/08/2013 09:35 AM
>
> 	
> To
> *From:* [email-masked] [mailto:[email-masked]] *
> Sent:* Wednesday, August 21, 2013 11:44 AM*
> To:* Eric Gray*
> Cc:* Eric Osborne (eosborne); [email-masked]; [email-masked];
> [email-masked]*
> Subject:* RE: [mpls] Mode negotiation for PSC*
> Importance:* High
>
> Hi Eric (Gray),
>
> As I pointed out below "negotiation" of the PSC options should take
> place before the LSP is set-up, PSC should only check that the options
> selected match (and report a miss match).
>
> Regards,
>
> Malcolm
>
> *Eric Gray <[email-masked]* <mailto:[email-masked]>*>*
>
> 20/08/2013 02:41 PM
>
> 	
> To
> 	"Eric Osborne (eosborne)" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> cc
> 	"[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> Subject
> From: [email-masked]
> <mailto:[email-masked]>[_mailto:[email-masked]] On Behalf
> Of Eric Osborne (eosborne)
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
>  > From: [email-masked]
> <mailto:[email-masked]>[_mailto:[email-masked]]
>  > Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
>  > "Eric Osborne (eosborne)" <[email-masked]
> <mailto:[email-masked]>> Sent by:
>  > [email-masked] <mailto:[email-masked]>
>  >
>  > 08/08/2013 08:34 AM To
>  > "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
>  > cc
>  > Subject
>  > (_http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt_
>  > <_http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt_> ),
>  > [email-masked] <mailto:[email-masked]>
>  > _https://www.ietf.org/mailman/listinfo/mpls_
>  > <_https://www.ietf.org/mailman/listinfo/mpls_>
>  >
>
> mpls mailing list_
> [email-masked] <mailto:[email-masked]>_
> __https://www.ietf.org/mailman/listinfo/mpls_
>
>

--

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 22 Aug 2013 15:39:31 +0000

Hi Adrian, et. al,
or perhaps we can call it "mode advertisement if each LER only to announce, advertise its PSC capabilities. As I understand, in Option 1 an LER would not inform its peer of whether it thinks that PSC capabilities match. Thus there might not be "confirmation" part in the process.

                Regards,
                                Greg

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Thursday, August 22, 2013 5:27 AM
To: [email-masked]; Eric Gray
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Mode negotiation for PSC

Adrian

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 21 August 2013 16:44
To: Eric Gray
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Mode negotiation for PSC

Hi Eric (Gray),

Regards,

Malcolm

20/08/2013 02:41 PM

To

cc

Subject

Eric (Osborne),

--
Eric (Gray)

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Eric Osborne (eosborne)
Sent: Friday, August 16, 2013 4:49 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Mode negotiation for PSC

Hi Malcolm-

Cap=00000, Mask=11111
Cap=11111, Mask=11111

eric