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

[Lizhong Jin <[e-mail]>]

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.

Regards
Lizhong



> ---------- Forwarded message ----------
> From: Stewart Bryant <[e-mail]>
> To: "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>
> Cc: "[e-mail]" <[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]
> https://www.ietf.org/mailman/listinfo/pals
>
>