5.1. Independent
Mode:
PW endpoint nodes
independently select which PWs are eligible to become active and which are
not. They advertise the corresponding Active or Standby preferential
forwarding status for each PW. Each PW endpoint compares local and remote status
bits and uses the PW that is UP at both endpoints and that advertised Active
preferential forwarding status at both the local and remote endpoints.
In this mode of operation,
the preferential forwarding status indicates the preferred forwarding state of
each endpoint but the actual forwarding state of the PW is the result of the
comparison of the local and remote forwarding status
bits.
If more than one PW
qualifies for the Active state, each PW endpoint MUST implement a common
mechanism to choose the PW for forwarding. The default mechanism MUST be
supported by all implementations and operates as follows:
1.
For
FEC128 PW, the PW with the lowest pw-id value is
selected.
2.
For
FEC129 PW, each PW in a redundant set is uniquely identified at each PE using
the following triplet: AGI::SAII::TAII. The unsigned integer form of the
concatenated word can be used in the comparison. However, the SAII and TAII
values as seen on a PE node are the mirror values of what the peer PE node sees.
To have both PE nodes compare the same value we propose that the PE with the
lowest system IP address use the unsigned integer form of AGI::SAII::TAII while
the PE with the highest system IP address use the unsigned integer form of
AGI::TAII::SAII. This way, both PEs will compare the same values. The PW which
corresponds to the minimum of the compared values across all PWs in the
redundant is selected.
Note 1: in the case where
the system IP address is not known, it is recommended to implement the optional
active PW selection mechanism described next.
Note 2: in the case of
segmented PW, the operator needs to make sure that the pw-id or AGI::SAII::TAII
of the redundant PWs within the first and last segment are ordered consistently
such that the same end-to-end MS-PW gets selected. Otherwise, it is recommended
to implement the optional active PW selection mechanism described
next.
The PW endpoints MAY also
implement the following optional active PW selection mechanism.
1.
If the
PW endpoint is configured with the precedence parameter on each PW in the
redundant set, it must select the PW with the lowest configured precedence
value.
2.
If the
PW endpoint is configured with one PW as primary and one or more PWs as
secondary, it must select the primary PW in preference to all secondary PWs. If
a primary PW is not available, it must use the secondary PW with the lowest
precedence value. If the primary PW becomes available, a PW endpoint must revert
to it immediately or after the expiration of a configurable
delay.
3.
This
active PW selection mechanism assumes the precedence parameter values are
configured consistently at both PW endpoints and that unique values are assigned
to the PWs in the same redundancy set to achieve tie-breaking using this
mechanism.
There are scenarios with
dual-homing of a CE to PE nodes where each PE node needs to advertise Active
preferential forwarding status on more than one PW in the redundancy set.
However, a PE MUST always select a single PW for forwarding using the above
active PW selection algorithm. An example of such a case is described in 15.2.
.
There are scenarios where
each PE needs to advertize Active preferential forwarding status on a single PW
in the redundancy set. In order to ensure that both PE nodes make the same
selection, they MUST use the above active PW selection algorithm to determine
the PW eligible for active state. An example of such a case is
described in 15.5. .
In steady state with
consistent configuration, a PE will always find an active PW. However, it is
possible that such a PW is not found due to a mis-configuration. In the event
that an active PW is not found, a management indication SHOULD be generated. If
a management indication for failure to find an active PW was generated and an
active PW is subsequently found, a management indication should be generated, so
clearing the previous failure indication. Additionally, a PE may use the
optional request switchover procedures described in Section 6.3. to have both PE
nodes switch to a common PW.
There may also be transient
conditions where endpoints do not share a common view of the Active/Standby
state of the PWs. This could be caused by propagation delay of the T-LDP status
messages between endpoints. In this case, the behavior of the receiving endpoint
is outside the scope of this document.
Thus, in this mode of
operation, the following definition of Active and Standby PW states
apply:
o
Active State
A PW is considered to be in
Active state when the PW labels are exchanged between its two endpoints and the
status bits exchanged between the endpoints indicate the PW is UP and its
preferential forwarding status is Active at both endpoints. In this state user
traffic can flow over the PW in both directions. As described in Section 5.1. ,
the PE nodes must implement a common mechanism to select one PW for forwarding
in case multiple PWs qualify for the Active state.
o
Standby State
A PW is considered to be in Standby state when the PW labels are exchanged between its two endpoints, but the Preferential Forwarding status bits exchanged indicate the PW preferential forwarding status is Standby at one or both endpoints. In this state the endpoints MUST NOT forward data traffic over the PW but MAY allow PW OAM packets, e.g., Virtual Connection Connectivity Verification (VCCV) packets [10], to be sent and received in order to test the liveliness of standby PWs. The endpoints of the PW may also allow the forwarding of specific control plane packets of applications using the PW. The specification of applications and the allowed control plane packets is outside the scope of this document. If the PW is a spoke in H-VPLS, any MAC addresses learned via the PW SHOULD be flushed when it transitions to Standby state according to the procedures in RFC4762 [3] and [9].
From: Aissaoui, Mustapha (Mustapha)
Sent: Thursday, March 22, 2012 11:59 AM
To: 'pwe3@xxxxxxxx'; Daniel Cohn
Cc: 'stbryant@xxxxxxxxx'; 'draft-ietf-pwe3-redundancy-bit@xxxxxxxxxxxxxx'; 'ietf@xxxxxxxx'; 'Andrew G. Malis'
Subject: RE: [PWE3] Last Call: <draft-ietf-pwe3-redundancy-bit-06.txt> (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard
If more than one PW qualifies for the Active
state, each PW endpoint MUST implement a common mechanism to choose the PW for
forwarding. The default mechanism MUST be supported by all implementations and
operates as follows:
1.
For FEC128 PW, the PW with the
lowest pw-id value is selected.
2.
For FEC129 PW, each PW in a
redundant set is uniquely identified at each PE using the following triplet:
AGI::SAII::TAII. The unsigned integer form of the concatenated word can be used
in the comparison. However, the SAII and TAII values as seen on a PE node are
the mirror values of what the peer PE node sees. To have both PE nodes compare
the same value we propose that the PE with the lowest system IP address use the
unsigned integer form of AGI::SAII::TAII while the PE with the highest system IP
address use the unsigned integer form of AGI::TAII::SAII. This way, both PEs
will compare the same values. The PW which corresponds to the minimum of the
compared values across all PWs in the redundant is
selected.
Note 1: in the case where the system IP address
is not known, it is recommended to implement the optional active PW
selection mechanism described next.
Note 2: in the case of segmented PW, the
operator needs to make sure that the pw-id or AGI::SAII::TAII of the redundant
PWs within the first and last segment are ordered consistently such that the
same end-to-end MS-PW gets selected. Otherwise, it is recommended to implement
the optional active PW selection mechanism described
next.
The PW endpoints MAY also implement the
following optional active PW selection mechanism.
1.
If the PW endpoint is configured
with the precedence parameter on each PW in the redundant set, it must select
the PW with the lowest configured precedence value.
2.
If the PW endpoint is configured
with one PW as primary and one or more PWs as secondary, it must select the
primary PW in preference to all secondary PWs. If a primary PW is not available,
it must use the secondary PW with the lowest precedence value. If the primary PW
becomes available, a PW endpoint must revert to it immediately or after the
expiration of a configurable delay.
3.
This active PW selection
mechanism assumes the precedence parameter values are configured consistently at
both PW endpoints and that unique values are assigned to the PWs in the same
redundancy set to achieve tie-breaking using this
mechanism.
If more than one PW qualify for the Active
state, the Master PW endpoint node selects one. There is no requirement to
specify a default active PW selection mechanism in this case but for consistency
across implementations, the Master PW endpoint SHOULD implement the default
active PW selection mechanism described in Section 5.1.
If the Master PW endpoint implements the
optional active PW selection mechanism based on primay/secondary and precedence
parameters, it MUST follow the following behaviour:
1.
If the PW endpoint is
configured with the precedence parameter on each PW in the redundant set,
it must select the PW with the lowest configured precedence
value.
2.
If the PW endpoint is
configured with one PW as primary and one or more PWs as secondary, it must
select the primary PW in preference to all secondary PWs. If a primary PW
is not available, it must use the secondary PW with the lowest precedence
value. If the primary PW becomes available, a PW endpoint must revert to it
immediately or after the expiration of a configurable
delay.
From: Aissaoui, Mustapha (Mustapha)
Sent: Wednesday, March 07, 2012 12:56 PM
To: Andrew G. Malis
Cc: stbryant@xxxxxxxxx; draft-ietf-pwe3-redundancy-bit@xxxxxxxxxxxxxx; pwe3@xxxxxxxx; ietf@xxxxxxxx
Subject: RE: [PWE3] Last Call: <draft-ietf-pwe3-redundancy-bit-06.txt> (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard
From: Andrew G. Malis [mailto:amalis@xxxxxxxxx]
Sent: Wednesday, March 07, 2012 12:53 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: stbryant@xxxxxxxxx; draft-ietf-pwe3-redundancy-bit@xxxxxxxxxxxxxx; pwe3@xxxxxxxx; ietf@xxxxxxxx
Subject: Re: [PWE3] Last Call: <draft-ietf-pwe3-redundancy-bit-06.txt> (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard
You might want to wait for any other LC comments before updating.
Thanks,
Andy
Ooops. Thank you for pointing this out Stewart. I will make the update and publish a new revision.
Mustapha.
-----Original Message-----
From: Stewart Bryant [mailto:stbryant@xxxxxxxxx]
Sent: Wednesday, March 07, 2012 12:48 PM
To: draft-ietf-pwe3-redundancy-bit@xxxxxxxxxxxxxx
Cc: ietf@xxxxxxxx; pwe3@xxxxxxxx
Subject: Re: Last Call: <draft-ietf-pwe3-redundancy-bit-06.txt> (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard
Authors
There was on point that I notice that you did not address from the AD review and so I am picking it up as a LC comment:
In section 10 you say:
"This document makes the following update to the PwOperStatusTC
textual convention in RFC5542 [8]: "
This update should be recorded in the metadata (top left front page) and it is usual to put a one line note in the abstract.
Stewart
On 07/03/2012 17:00, The IESG wrote:
> The IESG has received a request from the Pseudowire Emulation Edge to
> Edge WG (pwe3) to consider the following document:
> - 'Pseudowire Preferential Forwarding Status Bit'
> <draft-ietf-pwe3-redundancy-bit-06.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@xxxxxxxx mailing lists by 2012-03-21. Exceptionally, comments may
> be sent to iesg@xxxxxxxx instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
> This document describes a mechanism for standby status signaling of
> redundant pseudowires (PWs) between their termination points. A set
> of redundant PWs is configured between provider edge (PE) nodes in
> single-segment pseudowire (SS-PW) applications, or between
> terminating provider edge (T-PE) nodes in multi-segment pseudowire
> (MS-PW) applications.
>
> In order for the PE/T-PE nodes to indicate the preferred PW to use
> for forwarding PW packets to one another, a new status bit is needed
> to indicate a preferential forwarding status of Active or Standby for
> each PW in a redundant set.
>
> In addition, a second status bit is defined to allow peer PE nodes to
> coordinate a switchover operation of the PW.
>
>
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
--
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
_______________________________________________
pwe3 mailing list
pwe3@xxxxxxxx
https://www.ietf.org/mailman/listinfo/pwe3