Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please

[David Meyer <[e-mail]>]

Excellent comments/clarifications Sasha. Thanks, really appreciate it
and I'll work this into the next rev (working on that now).

--dmm


On Fri, Jul 6, 2012 at 11:29 AM, Alexander Vainshtein
<[e-mail]> wrote:
> David,
> Please see a couple of comments inline below. Hopefully they clarify my position.
>
> I have snipped some fragments of your response to make the remaining text more readable.
>
> Regards,
>      Sasha
>
> ________________________________________
> From: David Meyer [[e-mail]]
> Sent: Friday, July 06, 2012 4:59 PM
> To: Alexander Vainshtein
> Cc: Andrew G. Malis; Jan Medved; Andrew McLachlan; [e-mail]; Mishael Wexler; Rotem Cohen; Gideon Agmon; Andrew Sergeev; Idan Kaspit; Vladimir Kleiner
> Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please
>
> Alexander,
>
>
> On Tue, Jul 3, 2012 at 10:05 PM, Alexander Vainshtein
> <[e-mail]> wrote:
>> Andy and all,
>>
>> I've looked up the draft in question, and I have some comments/questions in
>> addition to Andy's:
>>
>> The PWE3 WG has defined multiple MIBs that can be used for PW setup and
>> teardown by a      management application (MPLS-TP or not). IMO the draft
>> should indicate that the method proposed there is an alternative not just to
>> PW signaling via T-LDP (as Andy has said) but also to static PW setup using
>> these MIBs.
>
> As I mentioned, the draft did not intended to provide an alternate
> control plane; hopefully that will be clear in the next rev. I'll add
> some text around the point you make WRT MIBs above.
>
> [[Sasha]] Well, MIBs are not part of control plane (at least, for me), but of the Management Plane - and, to the best of my understanding, so is OpenFlow. But putting terminology aside, the PWE3 MIBs provide a certain abstract model of the PW endpoints that is integrated with the existing model for MPLS etc.
> Your draft seems to offer an alternative abstract model that seems to mix PW and MPLS functionality.
>
> --- snipped --
>
>> The PWs run in in MPLS (or MPLS-TP) tunnels in order to improve scalability of
>> P routers, because the same tunnel between a given pair of PEs can be shared
>> by multiple PW instances. It is not clear from the text how such sharing can
>> be accommodated in the proposed OF switch model.
>
> Humm, here is nothing that stops the "transport virtual port" from
> sharing transport labels if that is appropriate. Perhaps I'm not
> understanding your point?
>
> [[Sasha]] What is important is that multiple PWs sharing a common MPLS tunnel LSP are fate-sharing in the PSN core, and the model should IMHO reflect this fact explicitly. E.g., the protection switch is applied to tunnel LSPs, not to individual PWs. This affects both the management aspects (e.g., failures of individual PWs sharing a tunnel LSP should be suppressed when the tuneel LSP fails) and the data plane (e.g., the time it takes to complete a protection switch triggered by the tunnel LSP failure should not depend upon the number of PWs using this tunnel LSP). IMHO and FWIW the model where each PW uses its individual "transport virtual ports" does not make this easy (if at all possible) even if you allow sharing of labels between thee ports. Or do I miss something?
>
> --- snipped to the end ---
> This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
>