[Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward

[Stewart Bryant <[e-mail]>]

I am sorry that this is a long email, but I wanted to collect the
facts together in one place and set out the complete scene to
the PALS WG.

The critical concern is contained in the following email fragment
from Lizhong:

=======

In RFC4447 and 4447bis, it clearly said:

Using the PWid FEC, each of the two pseudowire endpoints

    independently initiates the setup of a unidirectional LSP.   An

    outgoing LSP and an incoming LSP are bound together into a single

    pseudowire if they have the same PW ID  and PW type.

The behavior is a correct description for LDP-DU mode which PW applies.

And that is also the behavior most vendors implement.

Then in draft-ietf-l2vpn-vpls-pe-etree-09, it says:

A PE that receives a PW label mapping message with an E-Tree Sub-TLV

    from its peer PE, after saving the VLAN information for the PW, MUST

    process it as follows:

.....

3) If the P bit is set

       {

           If the PE is a leaf-only node itself, a label release message

       with a status code "Leaf to Leaf PW released" is sent to the peer

       PE and exit the process;

           Else the PE SHOULD set the Optimized-Mode to TRUE.

       }

That means, if PE1 receiving a label mapping from PE2 with P bit set,

PE1 will send label release. Then PE2 will never send label mapping

again to PE1 even when PE1 changes from leaf-only node to root-leaf 
node. For LDP-DU

mode, PE2 will not send label mapping again when receiving PE1's label 
mapping.

Then the PW will not be setup successfully. Then only way is to 
configure the

same PW on PE2 again.

The correct behavior is, label release message should not be sent.

For PW signaling, the unacceptable of any Interface Parameter will not 
lead to any

label release, but just simply let the PW down in forwarding plane.

========

Andy looked at this from the point of view of the MEF and notes in
private conversation:

=========
In the E-tree service as defined by MEF, you can have one or more roots
and one or more leafs.

In a single E-tree service (think of a multipoint PW with some of the CEs
configured as roots as some as leafs), all leafs and roots receive frames
sent by the roots. All roots receive frames sent by the leafs. However,
leafs may not receive any frames sent by other leafs.

The draft, as written, doesn't bring up an underlying pt-to-pt PWs to
carry frames for the service between PEs that only have leafs attached.
Since the leafs can't sent frames to each other, that is an economical
use of PWs in the network.

Lizhong's point is that this makes it impossible to add a new root to
an existing PE in an E-tree that previously only had leafs.

I agree that would be a problem if there was a requirement to modify
an existing E-tree service. However, this draft has no other mechanisms
to explicitly support E-tree modification, nor is such modification a
requirement of the underlying MEF specification. BTW, since this work
was started, the MEF replaced MEF 6.1 with MEF 6.2, "EVC Ethernet
Services Definitions Phase 3", August, 2014, and that reference should
be updated in the draft.

My opinion is that the draft as it stands is technically correct if you
don't need the ability to reconfigure an existing E-tree service 
dynamically.

==========

Now whilst I can support the idea that dynamic reconfiguration of
E-tree is not needed, I have a concern.

My understanding the text in question is that it is saying that if
A is configured as leaf only, and B which is also configured as
leaf only attempts to configure a PW between them, then A rejects
the PW setup.

That sounds very reasonable to me, since there is a misconfig.

If A did not do the reject, then B would forever be consuming
resource waiting for A and B would have no idea of the
misconfig. That accords with Andy's view above.

However I was worried what would happen if A was misconfigured
as leaf only and the configuration was corrected to root-leaf.
What would in my view be difficult to accept was the need to
take a human, or NMS action at B to recover the situation.
However provided that A closed the LDP session with B
and re-instate it B would then send the mapping message again.
Thus the system is recoverable without needing to visit B which
is in my mind a fundamental requirement since A could have
got into the wrong mode as a result of an error.

The problem I see is if A has a bunch of other PWs with B
they will get torn down in order for A to have the config error
fixed. However if that is a problem you need two LDP sessions
between A and B, one for L2VPN and one for regular PWs.

My inclination is that the draft is basically correct, and that whilst
Lizhong is correct that the PW will not come up without some
action, reconfiguring the PW on B is not the only action
that will cause the PW to come up.

So this comes down to a WG decision in terms of which is the
least unacceptable behaviour - A having to re-cycle the LDP
session, or B wasting resources. I think I prefer the behaviour
proposed in the draft.

A way forward is to leave the logic as written in the draft, but to
add text describing the basis for excluding dynamic re-configuration
as a normal operational mode and to note the actions that need
to be taken when re-configuration is forced for some reason.

Whilst we were pondering what do with the text the chairs
and AD received another proposal from the authors:

======

In general, FEC PWid(0x80) is used in VPLS with manual provisioning,
while Generalized PWid (0x81) is used with auto-discovery.

As discussed in Section 5.2, VLAN mapping parameters can be provisioned
without a signaling protocol, Optimized Mode can also be a parameter
to be provisioned.

The approach we’ve taken in the current draft-ietf-l2vpn-vpls-pe-etree-09
does allow this. Quite a few service providers may prefer to control
all these E-Tree connectivity by themselves.

When E-Tree signaling protocol for PWid FEC is considered, the following
options are also feasible:

a)Disable Optimized mode for FEC PWid(0x80), thus root/leaf role
change in the E-Tree topology will not have any influence on the PW.

b)Add another appendix into the document for the full support of
Optimized mode with FEC PWid(0x80).

The idea is: the PE sends a label mapping firstly and then send a label
request to its peer PEs (so that they will reply with a label mapping
respectively).

Since Optimized mode is an optional piece in the document, I would
regard option a) as a simple tradeoff (as I am aware, E-VPN does not
support Optimized mode for E-Tree either.

========


Thus we have three proposals on the table:

1) Leave the design as it is, but add text to describe the constraint and
what happens if you have to change mode and what to do about it.

2) Exclude optimization in the FEC PWid(0x80) case

3) Add an appendix describing support for the FEC PWid(0x80) case.

My inclination would be to go with option (1) but I seek the views of
the WG, and of course any corrections in my analysis.

- Stewart