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
>