Re: FW: NSSA RFC for OSPFv3
Acee Lindem <acee@REDBACK.COM> Thu, 20 May 2004 21:26 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 RAA26467 for <ospf-archive@LISTS.IETF.ORG>; Thu, 20 May 2004 17:26:40 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00DB8E0B@cherry.ease.lsoft.com>; Thu, 20 May 2004 17:26:39 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 17599054 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 20 May 2004 17:26:37 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 May 2004 17:26:37 -0400
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 7913112E540; Thu, 20 May 2004 14:26:36 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12719-02; Thu, 20 May 2004 14:26:36 -0700 (PDT)
Received: from aceeinspiron (unknown [172.31.253.182]) by prattle.redback.com (Postfix) with SMTP id D872812E545; Thu, 20 May 2004 14:26:34 -0700 (PDT)
References: <JJEPLPDLAOFOMGACOOBPEENBDJAA.harold@ipinfusion.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Virus-Scanned: by amavisd-new at redback.com
Content-Transfer-Encoding: quoted-printable
Message-ID: <01c401c43eb1$1d594660$0302a8c0@aceeinspiron>
Date: Thu, 20 May 2004 17:26:27 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: FW: NSSA RFC for OSPFv3
Comments: To: Harold Rabbie <harold@ipinfusion.com>
Comments: cc: Toshiaki Takada <toshiaki@ipinfusion.com>, Kunihiro Ishiguro <kunihiro@ipinfusion.com>, zhangjp@huawei.com
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable
Hi Harold,
Issues: #1. Yes - this bit should be defined since the router
LSA is fully defined. The position should remain
the same as defined in RFC 3101.
#2. This would be clearer with an explicit statement.
However, it really isn't ambiguous without it since
the relationship between AS external LSAs and NSSA
LSA remains the same.
#3. Same as #2. It would be better with the statement but
is unambiguous without it.
It looks like maybe I should gather all the OSPFv3 errata and
come out with a respin of RFC 2740.
Thanks,
Acee
----- Original Message -----
From: "Harold Rabbie" <harold@ipinfusion.com>
To: <OSPF@PEACH.EASE.LSOFT.COM>; <acee@redback.com>
Cc: "Toshiaki Takada" <toshiaki@ipinfusion.com>; "Kunihiro Ishiguro" <kunihiro@ipinfusion.com>; <zhangjp@huawei.com>
Sent: Thursday, May 20, 2004 4:56 PM
Subject: FW: FW: NSSA RFC for OSPFv3
> Hello Acee,
>
> We were very interested to see your response (below) to Huawei regarding
> implementing NSSA for OSPFv3.
> IP Infusion would like to implement this option, but we're running into a
> couple of undefined issues.
> Perhaps you could let us know your thoughts on these topics:
>
> Issue #1:
> ========
>
> RFC 3101 defines the "Nt" bit in the Router-LSA. But RFC 2740 does not
> describe that bit.
>
> RFC 3101 Router LSA
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | 0 Nt|W|V|E|B| 0 | # links |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> RFC 2740 Router LSA
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | 0 |W|V|E|B| Options |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> In order to implement NSSA for OSPFv3, this bit needs to be defined
> somewhere.
> It could presumably be in the analogous location next to the W bit.
>
> Issue #2:
> ========
>
> Although LSA type ID 7 is reserved for NSSA, RFC 2740 does not define the
> format of a type 7 LSA.
> The RFC could be updated with a statement, for example:
>
> A.4.? NSSA-LSAs
>
> NSSA-LSAs have LS type equal to 0x2007. These LSAs are originated
> by NSSA internal router or NSSA-ABR, and describe destinations
> external to AS but only through NSSA. The NSSA-LSA format is exactly
> the same as AS-external-LSAs.
>
> Issue #3:
> ========
>
> RFC 2740 section 3.8.4 describes how to calculate AS external routes as
> follows:
>
> The IPv6 AS external route calculation proceeds along the same lines
> as the IPv4 calculation in Section 16.4 of [Ref1], with the following
> exceptions:
>
> [Ref1] is Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998
> which doesn't contain any reference to NSSA.
>
> This section could be updated to refer to RFC 3101 as well.
>
> Summary
> =======
>
> 1) Nt bit in Router-LSA is not defined.
> 2) The format for NSSA-LSA is not defined.
> 3) Calculating NSSA external route is not defined.
>
> Many thanks,
>
> Harold Rabbie
> Director of Applications Engineering
> IP Infusion Inc.
> 111 W. St. John St #910, San Jose, CA 95113
> ofc (408)794-1526 cell (408)506-4224 fax (408)278-0521
> Web http://www.ipinfusion.com
> E-mail harold@ipinfusion.com
>
>
> >
> > -----Original Message-----
> > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee
> > Lindem
> > Sent: Wednesday, May 19, 2004 11:14 AM
> > To: OSPF@PEACH.EASE.LSOFT.COM
> > Subject: Re: NSSA RFC
> >
> >
> > Hi 张 江平 ,
> >
> > I don't think we need a new NSSA for OSPFv3 other than RFC 3101.
> >
> > One obvious omission from RFC 2740 is that a forwarding address for
> > an NSSA or AS external LSA must not be a link local address. We'll add
> > this if we ever re-spin RFC 2740.
> >
> > Thanks,
> > Acee
> > ----- Original Message -----
> > From: 张 江平
> > To: OSPF@PEACH.EASE.LSOFT.COM
> > Sent: Tuesday, May 18, 2004 8:22 AM
> > Subject: NSSA RFC
> >
> >
> > Hi all,
> >
> > Does OSPFv3 support NSSA now, RFC2740 has defined the type for NSSA, do
> we
> > need another NSSA rfc the same as RFC3101 for OSPFv3?
> >
> > thanks!
>
> Hi harold,
>
> Ipinfusion don't support NSSA feature, the reason is that no NSSA Draft/RFC
> for OSPFv3,
> I don't think we need another NSSA RFC for OSPFv3, and I confirm with Mr.
> Acee,
> the chairman of IETF OSPF work group. Pls find attached mail for Mr. Acee's
> answer.
>
> Regards,
> Zhang Jiangping
> Huawei Technologies R&D Beijing Branch
> Phone: +86-10-82882249
> Mobile: +86-13301132983
>
- Re: FW: NSSA RFC for OSPFv3 Acee Lindem