MIME-Version: 1.0
In-Reply-To: <CAHiKxWgoZOjsT89SdVkH=xAFAPBM3Po7Z3apZ+vUMXxWzFzy4Q@mail.gmail.com>
References: <CAHiKxWhFdmBPK4rM1WcXbk+0N4utR6Y5j98xK_Zy7OPY5TGK4Q@mail.gmail.com>
 <CAK+d4xsReG3yji_zV_qA4NGE1OZfiQdL4oDkXD3QtQVPWE2=DA@mail.gmail.com>
 <F9336571731ADE42A5397FC831CEAA02097A99@FRIDWPPMB001.ecitele.com>
 <CAHiKxWhS8808ok7KtYabCQ6gqR0ttCeZH+h7rgZ-DbRw7x5H=w@mail.gmail.com>
 <F9336571731ADE42A5397FC831CEAA0209872F@FRIDWPPMB001.ecitele.com>
 <CAHiKxWgoZOjsT89SdVkH=xAFAPBM3Po7Z3apZ+vUMXxWzFzy4Q@mail.gmail.com>
From: "Andrew G. Malis" <amalis@gmail.com>
Date: Fri, 6 Jul 2012 14:47:58 -0400
Message-ID: <CAK+d4xsVDif-zZJ0=hud9cdFwr1xURVrJRfA86p9JRS4HL+3WA@mail.gmail.com>
To: David Meyer <dmm@1-4-5.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Vladimir Kleiner <Vladimir.Kleiner@ecitele.com>,
 Andrew Sergeev <Andrew.Sergeev@ecitele.com>,
 Idan Kaspit <Idan.Kaspit@ecitele.com>,
 Mishael Wexler <Mishael.Wexler@ecitele.com>, Jan Medved <jmedved@cisco.com>,
 "pwe3@ietf.org" <pwe3@ietf.org>, Andrew McLachlan <andrew@happypig.org>,
 Rotem Cohen <Rotem.Cohen@ecitele.com>
Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please
Precedence: list

Dave,

One other comment that just occurred to me as you're working on your
update - the current revision of the draft obviously only works with
single-segment PWs, but that's not explicitly stated anywhere, other
than being alluded to in the title of figure 1. You may wish to make
that restriction explicit, unless you do intend to include MS-PWs in a
future revision, in which case that should be made clear as well.

Cheers,
Andy

On Fri, Jul 6, 2012 at 2:35 PM, David Meyer <dmm@1-4-5.net> wrote:
> 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
> <Alexander.Vainshtein@ecitele.com> 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 tex=
t more readable.
>>
>> Regards,
>>      Sasha
>>
>> ________________________________________
>> From: David Meyer [dmm@1-4-5.net]
>> Sent: Friday, July 06, 2012 4:59 PM
>> To: Alexander Vainshtein
>> Cc: Andrew G. Malis; Jan Medved; Andrew McLachlan; pwe3@ietf.org; Mishae=
l Wexler; Rotem Cohen; Gideon Agmon; Andrew Sergeev; Idan Kaspit; Vladimir =
Kleiner
>> Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review pl=
ease
>>
>> Alexander,
>>
>>
>> On Tue, Jul 3, 2012 at 10:05 PM, Alexander Vainshtein
>> <Alexander.Vainshtein@ecitele.com> wrote:
>>> Andy and all,
>>>
>>> I've looked up the draft in question, and I have some comments/question=
s 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 dra=
ft
>>> should indicate that the method proposed there is an alternative not ju=
st to
>>> PW signaling via T-LDP (as Andy has said) but also to static PW setup u=
sing
>>> 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), b=
ut of the Management Plane - and, to the best of my understanding, so is Op=
enFlow. But putting terminology aside, the PWE3 MIBs provide a certain abst=
ract model of the PW endpoints that is integrated with the existing model f=
or MPLS etc.
>> Your draft seems to offer an alternative abstract model that seems to mi=
x PW and MPLS functionality.
>>
>> --- snipped --
>>
>>> The PWs run in in MPLS (or MPLS-TP) tunnels in order to improve scalabi=
lity of
>>> P routers, because the same tunnel between a given pair of PEs can be s=
hared
>>> by multiple PW instances. It is not clear from the text how such sharin=
g 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 t=
unnel LSP are fate-sharing in the PSN core, and the model should IMHO refle=
ct this fact explicitly. E.g., the protection switch is applied to tunnel L=
SPs, 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 comple=
te a protection switch triggered by the tunnel LSP failure should not depen=
d upon the number of PWs using this tunnel LSP). IMHO and FWIW the model wh=
ere each PW uses its individual "transport virtual ports" does not make thi=
s easy (if at all possible) even if you allow sharing of labels between the=
e ports. Or do I miss something?
>>
>> --- snipped to the end ---
>> This e-mail message is intended for the recipient only and contains info=
rmation 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.
>>