Re: Concerns about ripv2 "subsumption"
Fred Baker <fbaker@acc.com> Fri, 13 November 1992 01:01 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19927;
12 Nov 92 20:01 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19923;
12 Nov 92 20:01 EST
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa02610;
12 Nov 92 20:03 EST
Received: by atlas.xylogics.com id AA01914 (5.65c/UK-2.1-921001);
Thu, 12 Nov 1992 20:03:01 -0500
Received: from SAFFRON.ACC.COM by atlas.xylogics.com with SMTP
id AA01915 (5.65c/UK-2.1-921001); Thu, 12 Nov 1992 20:02:54 -0500
Received: by saffron.acc.com (4.1/SMI-4.1)
id AA20778; Thu, 12 Nov 92 17:01:38 PST
Date: Thu, 12 Nov 92 17:01:38 PST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker <fbaker@acc.com>
Message-Id: <9211130101.AA20778@saffron.acc.com>
To: jnc@ginger.lcs.mit.edu
Subject: Re: Concerns about ripv2 "subsumption"
Cc: ietf-rip@xylogics.com
Route Subsumption was my suggestion. If there are legitimate concerns with it - and yes, OSPF uses manual configuration at area boundaries for this - I am willing to see an eraser appear out of the sky and make it dissappear. Fred
- Concerns about ripv2 "subsumption" Dennis Ferguson
- Re: Concerns about ripv2 "subsumption" Noel Chiappa
- Re: Concerns about ripv2 "subsumption" Fred Baker
- Concerns about ripv2 "subsumption" Gary Scott Malkin
- Re: Concerns about ripv2 "subsumption" Dennis Ferguson