Re: draft-sajassi-l2vpn-vpls-bridge-interop-03?

anilr@accton.com Tue, 25 July 2006 18:31 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RhA-0002iR-A2; Tue, 25 Jul 2006 14:31:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Rh9-0002g0-2p for l2vpn@ietf.org; Tue, 25 Jul 2006 14:31:51 -0400
Received: from [64.171.8.242] (helo=note-back.accton.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Rh7-0006OU-N2 for l2vpn@ietf.org; Tue, 25 Jul 2006 14:31:51 -0400
To: Vach Kompella <vach.kompella@alcatel.com>
X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001
Message-ID: <OF2FE14BE4.5E8068D2-ON852571B6.0064924E@accton.com>
From: anilr@accton.com
Date: Tue, 25 Jul 2006 14:42:10 -0400
X-MIMETrack: Serialize by Router on note-back/AcctonUS(Release 5.0.8 |June 18, 2001) at 07/25/2006 11:31:59 AM
MIME-Version: 1.0
Content-type: text/plain; charset="big5"
Content-transfer-encoding: base64
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: l2vpn@ietf.org
Subject: Re: draft-sajassi-l2vpn-vpls-bridge-interop-03?
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l2vpn.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
Errors-To: l2vpn-bounces@ietf.org

Vach,

Thanks for your response. I have a comment on one of your answers.

>> Mention is made of several interoperability issues which are
>> not addressed one way or another, e.g. how should various
>> "slow" 802 protocols be dealt with? The answer may be
>> different for different existing protocols, and may be
>> different for unrecognized protocols.
>
> This draft will only capture the issues, and may also include the
> complexities of the problems such as those you mention, but will
> not present solutions for them.

Why is this? It seems to me that different vendors' handling of
interoperability issues with legacy equipment the same way would allow them
to work together to interconnect in a more seamless manner than otherwise.

If a protocol is handled one way by a VPLS node and a different way by its
peer at the other end of the pseudowire, that doesn't sound like it would
be healthy for the protocol. That problem could of course be averted by
using equipment from the same vendor in any given VPLS instance, but I
suspect that's a restriction you don't want.

Regards,
Anil