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

[Jiangyuanlong <[e-mail]>]

Hi all,

We had some discussions on this mechanism when the document was still an individual draft (in fact, when it was being updated to draft-jiang-l2vpn-vpls-pe-etree-03).
Just like Stewart, some service providers were also concerned that this mechanism may result in a great waste of platform labels. For example, in a network with one root PE and 1000 leaf PEs, only 1001 PW labels are needed for the approach in the document; but we will need 1000*999/2=499500 PW labels in all for the proposed mechanism (since leaf to leaf PWs are still allocated). That is the main reason we adopted the current approach.
Therefore, I will regard option 1) as the favorite way forward:
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.

I will be glad to see more inputs to this topic.

Thanks,
Yuanlong



From: Lizhong Jin [mailto:[e-mail]]
Sent: Monday, October 05, 2015 1:05 PM
To: Stewart Bryant (stbryant)
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward

Hi Stewart,
For DU mode, if FEC is created, then label should be allocated. For the vulnerability you mentioned, if I understand your question correctly, the PW label will not be programmed into hardware, but only kept in control plane. So the packet will not be wrongly processed.
The MTU interface Sub-TLV defined in RFC4447 section 6.4 said:

If this parameter does not match

       in both directions of a specific PW, that PW MUST NOT be enabled.
The mechanism I proposed is what have been done for MTU interface sub-TLV.

Regards
Lizhong

On Mon, Oct 5, 2015 at 2:19 AM, Stewart Bryant (stbryant) <[e-mail]<mailto:[e-mail]>> wrote:



On 4 Oct 2015, at 16:43, Lizhong Jin <[e-mail]<mailto:[e-mail]>> wrote:
Hi Stewart,
Thanks for the comment. This is a long email.
You give us three options:

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.

 Then I prefer option 1. Because option2 is not reasonable, and the solution in option3 provided by the author is not the best one.

I would like to provide opition4 for WG to consider:
4) Add description to support for the FEC PWid(0x80) case, in appendix or text I don't care. The solution is:

label release message should not be sent in section 6.1.

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.
Listing

Doesn't that waste labels, which may be a problem in some systems, and create a vulnerability since someone may send a packet with that label which would be processed and sent out of the person egress.

-Stewart


Regards
Lizhong



---------- Forwarded message ----------
From: Stewart Bryant <[e-mail]<mailto:[e-mail]>>
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Fri, 2 Oct 2015 16:41:05 +0100
Subject: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward
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

_______________________________________________
Pals mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pals