Re: [Isis-wg] Re: Inconsistent view of routers over a LAN

Cheng-Yin Lee <Cheng-Yin.Lee@ALCATEL.COM> Wed, 11 June 2003 22:29 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07268 for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Jun 2003 18:29:15 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00A0EBFC@cherry.ease.lsoft.com>; Wed, 11 Jun 2003 18:29:15 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45342252 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 11 Jun 2003 18:29:12 -0400
Received: from 192.75.23.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 11 Jun 2003 18:29:12 -0400
Received: (qmail 3390 invoked from network); 11 Jun 2003 22:31:47 -0000
Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by kanmx2.ca.alcatel.com with SMTP; 11 Jun 2003 22:31:47 -0000
Received: from alcatel.com ([138.120.62.63]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HGC94M00.5RB; Wed, 11 Jun 2003 18:29:10 -0400
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <D2EC481073504E498A8DB9C0687E8CAF067D31A6@EXCHANGE0-0.na.procket.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <3EE7AD2E.B9773CEF@alcatel.com>
Date: Wed, 11 Jun 2003 18:29:02 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Cheng-Yin Lee <Cheng-Yin.Lee@ALCATEL.COM>
Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN
Comments: To: Tony Li <Tony.Li@procket.com>
Comments: cc: Jeff Learman <jlearman@cisco.com>, isis-wg@ietf.org, Acee Lindem <acee@redback.com>, l2vpn@ietf.org
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Tony, Naiming,
Thanks for clarifying this further and providing suggestions.

I would agree that it's better to use point-to-point links (or OSPF's
multipoint) when there are such problems.
As known, this is not a problem in a real LAN segment or emulated LAN
segment, provided by a bridged LAN (bridging over real LAN segments) or
bridging over circuits.
As has been brought up in the OSPF/IS-IS mailing lists, it is when the
emulated LAN (broadcast network) uses an approach whereby a full-meshed
of communication is required and there is a requirement that every
communication channel is working that this becomes a problem for routing
(and for bridges too).

There have been some proposals to overcome the problems in the
full-meshed approach, e.g. disabling the emulated LAN when one or more
connectivity loss is detected or artificially partitioning the emulated
LAN, or engineer the transport network in such a way that communication
failure never/rarely happens from the perspective of the user of the
service (e.g. routers).
More protocol mechanisms (and perhaps some heuristics) may be used to
emulate a proper LAN failure, but I think it not easy to get this
working (it also raises the question, is this the only compelling way),
in particular because of race/timing issues.
Can an operator engineer a network such that the pseudo-wire or
communications never or "rarely" fail from the perspective of
routers/bridges? What is the cost and effectiveness (backup and
rerouting pseudo-wire may not be sufficient as there can be many other
reasons why communication is lost) in this case?

I hope the L2VPN WG would consider these service issues as carefully as
L2VPN discovery protocols because even the best L2VPN discovery
protocols cannot help if the L2VPN service itself does not work well
with routers and bridges.

Thanks
Cheng-Yin

Tony Li wrote:
>
> Folks,
>
> In particular, if there is a disconnect on a broadcast medium
> between two routers and neither is the DR, then the two routers
> will present a black hole between them.  This problem has been
> seen before in real life and is Not Pretty.
>
> For this reason alone, I would encourage you to model any L2
> solution as a number of point-to-point links.
>
> Regards,
> Tony


Naiming Shen wrote:
>
> i don't think l2vpn wg needs to do much. when use link-state igp
> in those places, ALWAYS assume it's unreliable. just use p2p. period.
>

>
> |    -----Original Message-----
> |    From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com]
> |    Sent: Tuesday, June 10, 2003 1:43 PM
> |    To: Tony Li
> |    Cc: Jeff Learman; Mailing List; isis-wg@ietf.org; Acee
> |    Lindem; l2vpn@ietf.org
> |    Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN
> |
> |
> |    Jeff, Tony, Acee,
> |    Thanks for your clarification.
> |    L2VPN WG is defining emulated LAN (and broadcast network
> |    for IP traffic)
> |    service over IP/MPLS network and some of the mechanims
> |    being defined can
> |    result in loss of communication among a subset of routers on the
> |    emulated LAN (even if all the nodes in the underlying
> |    IP/MPLS transport
> |    network are reachable).
> |    Some of the discussions have been how tolerable are
> |    routing protocols to
> |    this type of problem, if it is worth fixing some L2VPN WG
> |    mechanisms to
> |    prevent this problem, how feasible are these L2VPN
> |    solutions, are these
> |    not well-known problems ...
> |
> |    I hope the L2VPN WG would consider these issues and
> |    requirements in the
> |    L2VPN solutions.
> |    Perhaps a more detailed understanding of how things
> |    work/don't work may
> |    help L2VPN WG develop/appreciate solutios that will work well with
> |    routers for e.g, in case of (i) below, what would an
> |    emulated LAN user
> |    observe in the routed network (is this predictable/unpredictable?)
> |
> |    Thanks
> |    Cheng-Yin
> |    p.s I have cced l2vpn, but pls feel free to respond only
> |    to the relevant
> |    WG as is appropriate.
> |
> |    Tony Li wrote:
> |    >
> |    > We should also point out that in case i) things are
> |    truly broken and
> |    > in case ii) the DR will not form an adjacency with A and
> |    the protocols
> |    > will be able to tell that things are broken.
> |    >
> |    > Tony
> |    >
> |    > |    -----Original Message-----
> |    > |    From: Jeff Learman [mailto:jlearman@cisco.com]
> |    > |    Sent: Tuesday, June 10, 2003 9:29 AM
> |    > |    To: Cheng-Yin.Lee@alcatel.com
> |    > |    Cc: Mailing List; isis-wg@ietf.org
> |    > |    Subject: Re: [Isis-wg] Re: Inconsistent view of
> |    routers over a LAN
> |    > |
> |    > |
> |    > |
> |    > |    This violates the transitivity requirement stated
> |    in ISO 10589.
> |    > |    You can't run ISIS on a subnetwork where this happens.
> |    > |    At least, that's the theory ;)
> |    > |
> |    > |    At 11:52 AM 6/10/2003, Cheng-Yin Lee wrote:
> |    > |    >Hello,
> |    > |    >Just got some private responses, perhaps I should clarify.
> |    > |    >This is in context of an emulated LAN, and I am not
> |    > |    looking for a fix in
> |    > |    >routing protocols.
> |    > |    >
> |    > |    >Thanks
> |    > |    >Cheng-Yin
> |    > |    >
> |    > |    >Cheng-Yin Lee wrote:
> |    > |    >>
> |    > |    >> Hello,
> |    > |    >> What happens if for some reason Router A can't reach
> |    > |    Router B, but
> |    > |    >> Router C can reach A & B (and vice-versa), when
> |    Router A,B,C are
> |    > |    >> connected over a broadcast network or LAN.
> |    > |    >>
> |    > |    >> E.g. in the case for (OSPF and IS-IS) where:
> |    > |    >> i) C is the DR
> |    > |    >> ii) B is the DR
> |    > |    >>
> |    > |    >> Thanks
> |    > |    >> Cheng-Yin
> |
> |
> |    > Hi Cheng-Yin,
> |    >
> |    > What I've recommended in the past for these situations
> |    is to force
> |    > the routing protocol to view the underlying network as a P2MP
> |    > (Point-to-Multi-Point) network. Many vendors support this. For
> |    > example, in our implementation you'd simply configure:
> |    >
> |    >    router ospf 1
> |    >     area 0
> |    >      interface backbone
> |    >       network-type point-to-multipoint
> |    >                o
> |    >                o
> |    >           < the rest of the OSPF config>
> |    >                o
> |    >
> |    > Good Luck,
> |    > Acee
> |
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www1.ietf.org/mailman/listinfo/isis-wg