Re: [mpls] Mode negotiation for PSC

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)" <eosborne@cisco.com>
Sent : 2013-08-08 21:34:55 ( +09:00 )
To : mpls@ietf.org <mpls@ietf.org>
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.

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.
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls