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

[Stewart Bryant <[e-mail]>]

 From my perspective, and with due regard as to where we are, option one
is the one that I would prefer to move things along.

That would not preclude us introducing another RFC at a later date if
there are further operational considerations or alternatives that there
is a consensus to support.

Do we have consensus to move forward with option 1?

Stewart



On 09/10/2015 13:02, Jiangyuanlong wrote:
>
> 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
>
>
>
> _______________________________________________
> Pals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pals