From klsrini@huawei.com Wed Apr 7 05:26:11 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153713A6927 for ; Wed, 7 Apr 2010 05:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiJKw1Zww5zQ for ; Wed, 7 Apr 2010 05:26:09 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9E50D3A6920 for ; Wed, 7 Apr 2010 05:26:04 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0I00GE2AHT16@szxga04-in.huawei.com> for ospf@ietf.org; Wed, 07 Apr 2010 20:25:06 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0I00CCXAHTY6@szxga04-in.huawei.com> for ospf@ietf.org; Wed, 07 Apr 2010 20:25:05 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0I004PJAHRPN@szxml04-in.huawei.com> for ospf@ietf.org; Wed, 07 Apr 2010 20:25:05 +0800 (CST) Date: Wed, 07 Apr 2010 17:55:02 +0530 From: Srinivasan K L In-reply-to: <4B63C7D4.1070901@cisco.com> To: 'Padma Pillay-Esnault' Message-id: <001401cad64d$59bbdbb0$1f01120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_K/MX88zr9W6R1TjoHNdFLg)" Thread-index: Acqhb4GG6dhuCne0RqGI0915dQ4PUQ027hQA References: <4B63C7D4.1070901@cisco.com> Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 12:26:11 -0000 This is a multi-part message in MIME format. --Boundary_(ID_K/MX88zr9W6R1TjoHNdFLg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I have a question about section 4.3.2.2 of draft-ietf-l3vpn-ospfv3-pece-05.txt. The section reads: 4.3.2.2. OSPF Intra-Area Route A route is advertised as an intra-area route using an Intra-Area- Prefix (type 0x2009) LSA only when sham links are used, as described in Section 5. Otherwise routes are advertised as either inter-area (Section 4.3.2.1) or external/NSSA (Sections 4.3.2.3) routes My question is: Are there any new Intra-Area prefix LSAs advertised beyond those that existed before the sham links were used ? I understand that the sham links allows the Intra-Area Prefix to flow into this site from other sites, and these prefixes result in intra-area routes. Regards, Srini. **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Padma Pillay-Esnault Sent: Saturday, January 30, 2010 11:17 AM To: Ross Callon; Adrian Farrel; acee.lindem@ericsson.com; Abhay Roy (akr); Peter Psenak (ppsenak) Cc: jdoyle@doyleassociates.net; Ertekin, Emre [USA]; ospf@ietf.org; pete@pollere.net Subject: Re: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' Thanks to everyone for their thorough review. Assessing the different review comments on the flexibility of assigning domain ID on a per-OSPF-Instance or a per-VRF basis, the authors think offering a single approach will greatly improve the document's clarity. The sections 4.1, 4.1.1, 4.1.2, 4.3, 4.3.1, 4.3.2.1, 4.3.2.3 will be modified to reflect assigning Domain ID per OSPF-instance only. See below for other proposed changes and suggestions from reviews of the wg. Section 3.1 OSPFv3 Specificities "For an IPv6 MPLS/VPN architecture where customers interface to providers through OSPFv3, traditional BGP/OSPF interactions specify that VPN-IPv6 reachability information redistributed into OSPFv3 will be expressed as an AS-External OSPFv3 LSAs. Instead, it may be desirable to view these LSAs as AS-internal (inter-area-prefix, and intra-area-prefix) LSAs." Proposed change "For an IPv6 MPLS/VPN architecture where customers interface to providers through OSPFv3, traditional BGP/OSPF interactions specify that VPN-IPv6 reachability information redistributed into OSPFv3 will be expressed as an AS-External OSPFv3 LSAs. Instead, it may be desirable to view these LSAs as inter-area-prefix LSAs." Remove paragraph, "To distinguish between routes originated from different OSPFv3 instances, an Instance ID field is carried in a newly-defined OSPFv3 Route Extended Community attribute." Section 4.3.2.2. OSPF Intra-Area Route "A route is advertised from a PE to a CE as an intra-area route using an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used, as described in Section 5. Otherwise routes are advertised as either inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes." Proposed Changes "A route is advertised as an intra-area route using an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used, as described in Section 5. Otherwise routes are advertised as either inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes." Section 4.4 OSPFv3 Route Extended Communities Attribute " 0x50 External 0x2005 AS-external-LSA" Proposed change " 0x50 External 0x4005 AS-external-LSA" Section 4.5.1. OSPFv3 Down Bit " Similarly, the DN-bit must be set in inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these are originated from a PE to a CE, to prevent those prefixes from being re-advertised into BGP. " Proposed change " Similarly, the DN-bit MUST be set in inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these are originated from a PE to a CE, to prevent those prefixes from being re-advertised into BGP. " Section 5 OSPFv3 Sham Links "Sham link endpoint addresses MUST be distributed by BGP as routeable VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As specified in [rfc4577], these endpoint addresses MUST NOT be advertised by OSPFv3." changed to "Sham link endpoint addresses MUST be distributed by BGP as routeable VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As specified in section 4.2.7.1 of [rfc4577], these endpoint addresses MUST NOT be advertised by OSPFv3; if there is no BGP route to the Sham Link Endpoint Address, that address is to appear unreachable, so that the sham link appears to be down." Section 5.1 Creating A Sham link Remove the paragraph. "One difference from Section 4.2.7.3 of [rfc4577] is the addition of Type 0x2009 intra-area-prefix LSAs, and the flooding of these LSAs across the sham link. Furthermore, where prefixes associated with OSPFv2 sham links are advertised in Type-1 LSAs, prefixes associated with OSPFv3 sham links are advertised as OSPFv3 Type 0x2009 LSAs. This change is required based on [rfc5340], which states that loopback interfaces are advertised in intra-area-prefix LSAs." Suggestions OSPFv3 Options : 1 byte The Options field indicates if the route carries a type-1 or type-2 metric. Setting the least significant bit in the field indicates that the route carries a External type-2 metric. #### When talking of bit positions, it's always better to show the bitfield, and name the bit(s) being allocated. For e.g. see section A.2 of rfc5340. PPE : Only the least significant bit is set to indicate the presence of a type-2 metric we felt this was sufficient. If you feel this would make things clearer, we can make the change. #### We also need an IANA registry for: #### - Option bits (allocate the one's we need here) #### - Route Type (only a few values are currently permitted) PPE: While I feel it is not needed for the Options bit, an IANA registry for the route types could be added. I will defer to the ADs on this matter. Regards, The authors --Boundary_(ID_K/MX88zr9W6R1TjoHNdFLg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

 

I have a question about section = 4.3.2.2 of draft-ietf-l3vpn-ospfv3-pece-05.txt. The section = reads:

 

4.3.2.2.  OSPF Intra-Area = Route

 

   A route is advertised as an intra-area route using an = Intra-Area-

   Prefix (type 0x2009) LSA only when sham links are used, as = described

   in Section 5.  Otherwise routes are advertised as either = inter-area

   (Section 4.3.2.1) or external/NSSA (Sections 4.3.2.3) = routes

 

My question is: Are there any new Intra-Area prefix LSAs advertised beyond those that existed before the = sham links were used ?  I understand that the sham links allows the = Intra-Area Prefix to flow into this site from other sites, and these prefixes = result in intra-area routes.

 

Regards,

Srini.

***********************************= ****************************************************
This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not = limited to, total or partial disclosure, reproduction, or dissemination) by = persons other than the intended recipient's) is prohibited. If you receive this = e-mail in error, please notify the sender by phone or email immediately and = delete it!

From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] = On Behalf Of Padma = Pillay-Esnault
Sent: Saturday, January = 30, 2010 11:17 AM
To: Ross Callon; Adrian = Farrel; acee.lindem@ericsson.com; Abhay Roy (akr); Peter Psenak (ppsenak)
Cc: = jdoyle@doyleassociates.net; Ertekin, Emre [USA]; ospf@ietf.org; pete@pollere.net
Subject: Re: [OSPF] OSPF = WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing = protocol'

 


Thanks to everyone for their thorough review.

Assessing the different review comments on the flexibility of
assigning domain ID on a per-OSPF-Instance or a per-VRF basis,  =
the authors think offering a single approach will greatly improve the document's
clarity. The sections 4.1, 4.1.1, 4.1.2, 4.3, 4.3.1, 4.3.2.1, 4.3.2.3 =
will be modified to reflect assigning Domain ID per OSPF-instance = only.

See below for other proposed changes and suggestions from reviews of the = wg.

Section 3.1 OSPFv3 Specificities

"For an IPv6 MPLS/VPN architecture where customers interface to
providers through OSPFv3, traditional BGP/OSPF interactions
specify that VPN-IPv6 reachability information redistributed into
OSPFv3 will be expressed as an AS-External OSPFv3 LSAs.  = Instead,
it may be desirable to view these LSAs as AS-internal = (inter-area-prefix,
and intra-area-prefix) LSAs."

Proposed change

"For an IPv6 MPLS/VPN = architecture where customers interface to
providers through OSPFv3, traditional BGP/OSPF interactions
specify that VPN-IPv6 reachability information redistributed into
OSPFv3 will be expressed as an AS-External OSPFv3 LSAs.  = Instead,
it may be desirable to view these LSAs as inter-area-prefix = LSAs."

Remove paragraph,

"To distinguish between routes originated from different
 OSPFv3 instances, an Instance ID field is carried in a
newly-defined OSPFv3 Route Extended Community attribute."

Section 4.3.2.2.  OSPF Intra-Area Route

"A route is advertised from a PE to a CE as an intra-area route = using
an Intra-Area-Prefix (type 0x2009) LSA only when sham links are = used,
as described in Section 5.  Otherwise routes are advertised as = either
inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) = routes."

Proposed Changes

"A route is advertised as an intra-area route using
an Intra-Area-Prefix (type 0x2009) LSA only when sham links are = used,
as described in Section 5.  Otherwise routes are advertised as = either
inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) = routes."

Section 4.4 OSPFv3 = Route Extended Communities Attribute

"  0x50     External           0x2005   AS-external-LSA"

Proposed change

"  = 0x50     External           0x4005   AS-external-LSA"

Section 4.5.1.  OSPFv3 Down Bit

   "  Similarly, the DN-bit must be set in inter-area-prefix-LSAs,
   NSSA-LSAs and AS-External-LSAs, when these
   are originated from a PE to a CE, to prevent those prefixes = from
   being re-advertised into BGP.  "

Proposed change

  " Similarly, the DN-bit = MUST be set in inter-area-prefix-LSAs,
   NSSA-LSAs and AS-External-LSAs, when these
   are originated from a PE to a CE, to prevent those prefixes = from
   being re-advertised into BGP.  "

Section 5 OSPFv3 Sham Links

"Sham link endpoint addresses MUST be distributed by BGP as = routeable
VPN IPv6 addresses whose IPv6 address prefix is 128 bits long.  = As
specified in [rfc4577], these endpoint addresses MUST NOT be
advertised by OSPFv3."

changed to

"Sham link endpoint addresses = MUST be distributed by BGP as routeable
  VPN IPv6 addresses whose IPv6 address prefix is 128 bits = long.  As
specified in section 4.2.7.1 of [rfc4577], these endpoint
addresses MUST NOT be advertised by OSPFv3; if there is no BGP route
to the Sham Link Endpoint Address, that address is to appear = unreachable,
so that the sham link appears to be down."

Section 5.1 Creating A Sham link

Remove the paragraph.

"One difference from Section 4.2.7.3 of [rfc4577] is the addition = of
Type 0x2009 intra-area-prefix LSAs, and the flooding of these LSAs
across the sham link.  Furthermore, where prefixes associated = with
OSPFv2 sham links are advertised in Type-1 LSAs, prefixes associated
with OSPFv3 sham links are advertised as OSPFv3 Type 0x2009 LSAs.
This change is required based on [rfc5340], which states that
loopback interfaces are advertised in intra-area-prefix LSAs."

Suggestions

      OSPFv3 Options =
: 1 byte
 
      The Options =
field indicates if the route carries a type-1 =
or
      type-2 =
metric.  Setting the least significant bit in the =
field
      indicates that =
the route carries a External type-2 =
metric.


#### When talking of bit positions, it's always better to show the = bitfield, and name the bit(s) being allocated. For e.g. see section A.2 of = rfc5340.
PPE : Only the least significant bit is set to indicate the presence = of  a type-2 metric we felt this was sufficient. If you feel this would make = things clearer, we can make the change.


#### We also = need an IANA registry for:
####  - Option bits (allocate the one's we need here)
####  - Route Type (only a few values are currently = permitted)

PPE: While I feel it is not needed for the = Options bit,  an IANA registry for the route types could be added.  I = will defer to the ADs on this matter.

Regards,

The authors

--Boundary_(ID_K/MX88zr9W6R1TjoHNdFLg)-- From acee.lindem@ericsson.com Wed Apr 7 15:06:42 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752E03A691F for ; Wed, 7 Apr 2010 15:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e5sGKzA3IuG for ; Wed, 7 Apr 2010 15:06:41 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 545DB3A67D7 for ; Wed, 7 Apr 2010 15:06:41 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o37MAdBg023523; Wed, 7 Apr 2010 17:10:39 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.98]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 7 Apr 2010 18:06:36 -0400 From: Acee Lindem To: Peter Psenak Date: Wed, 7 Apr 2010 18:06:34 -0400 Thread-Topic: [OSPF] draft-ietf-l3vpn-ospfv3-pece-05 - ext. community Thread-Index: AcrWnpb1JVXl9O5KTTeNW2O1zH96yw== Message-ID: <6AD92899-95CB-4585-90EA-0A4CF30797E9@ericsson.com> References: <4BB310CA.8040902@cisco.com> In-Reply-To: <4BB310CA.8040902@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-ietf-l3vpn-ospfv3-pece-05 - ext. community X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 22:06:42 -0000 Hi Peter,=20 While I don't see it as a show-stopper, I think you raise a valid point now= that the format of the communities is identical. Of the alternatives you s= uggest, I'd vote for using the existing encodings and have them simply refe= r to the LSA by name rather than number, e.g., Network-LSA rather than Type= 2 LSA.=20 Thanks, Acee=20 On Mar 31, 2010, at 5:07 AM, Peter Psenak wrote: > Bringing this up to the WG list to get the feedback. The discussion is=20 > about the usage of the BGP extended communities as defined for OSPFv2=20 > versus the definition of the new one in the context of the OSPFv3 PE-CE. >=20 >=20 > - draft-ietf-l3vpn-ospfv3-pece-05 defines a new OSPFv3 Route Extended=20 > Communities Attribute, which carries the exact same information as the=20 > original OSPF ext. communities defined in RFC4577. >=20 > - given that most vendors that will implement=20 > draft-ietf-l3vpn-ospfv3-pece-05 have already implemented RFC4577,=20 > reusing the communities defined there would make sense. >=20 > - from the operational perspective people are familiar with the original= =20 > OSPF communities from the VPNv4 deployments, so they would appreciate=20 > the familiarity with those. >=20 > - in the last WG meeting an argument has been used that the route-types=20 > encoding in 4.4 of draft-ietf-l3vpn-ospfv3-pece-05 does not match the=20 > one defined for OSPFv2 in 4.2.6. of RFC4577. The Route Type filed in=20 > OSPF Route Type Extended Communities Attribute as defined in RFC4577 has= =20 > enough space to use the encoding as defined in=20 > draft-ietf-l3vpn-ospfv3-pece-05 and there would be no collision. An=20 > alternative is to use the route-types as defined for OSPFv2=20 > (intra/inter/external/nssa) that match OSPFv3 route-types anyway - there= =20 > is no need to carry the LSA type in this context. >=20 > - draft-ietf-l3vpn-ospfv3-pece-05 uses the IPv6 Address Specific BGP=20 > Extended Community Attribute (RFC5701) that was defined specifically to=20 > carry the IPv6 address. Not sure if it's usage as a placeholder for=20 > opaque data was the intention of RFC570 as such. >=20 > - other protocols are reusing the originally defined communities in IPv6= =20 > VPN context. >=20 >=20 > thanks, > Peter > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Fri Apr 16 13:44:23 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A3E28C1A1 for ; Fri, 16 Apr 2010 13:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.227 X-Spam-Level: X-Spam-Status: No, score=-4.227 tagged_above=-999 required=5 tests=[AWL=-1.628, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWVxw3iyPx0F for ; Fri, 16 Apr 2010 13:44:22 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 29F4D28C14A for ; Fri, 16 Apr 2010 13:44:22 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3GKiEJn010278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 16 Apr 2010 15:44:14 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.98]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 16 Apr 2010 16:44:14 -0400 From: Acee Lindem To: "ospf@ietf.org" Date: Fri, 16 Apr 2010 16:44:12 -0400 Thread-Topic: OSPFv2 No Transit Capability - draft-pillay-esnault-ospf-rbit-00 Thread-Index: AcrdpZKMZIK396i5QO6TENCdF7rjkA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] OSPFv2 No Transit Capability - draft-pillay-esnault-ospf-rbit-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 20:44:23 -0000 At the OSPF WG meeting in Anaheim, the subject draft was presented and ther= e seemed to be some interest in such a capability (similar to the overload = bit in ISIS). Please indicate whether or not you support making this draft = a WG document.=20 http://www.ietf.org/id/draft-pillay-esnault-ospf-rbit-00.txt Thanks, Acee - (as OSPF WG Co-chair) = From eeeesti@gmail.com Mon Apr 19 05:47:08 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097113A6A36 for ; Mon, 19 Apr 2010 05:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.512 X-Spam-Level: X-Spam-Status: No, score=0.512 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmZJCVQwceS1 for ; Mon, 19 Apr 2010 05:47:07 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 203AC3A69D6 for ; Mon, 19 Apr 2010 05:47:07 -0700 (PDT) Received: by pwj2 with SMTP id 2so3258164pwj.31 for ; Mon, 19 Apr 2010 05:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:received :message-id:subject:to:content-type; bh=s/ZAh/I8/SIe9sPoFjkrUk39FVlJxpu1/bkGQq2op14=; b=Dg8xEUexdOAqT2+ORQVdZWLpR7NcWMP1j5ab5jND0StAgQ/BXvTVbpyUfA2ONKFQt7 Rd6DsxvGEBApr/SMLJNLNUhuB7ogv4+ttOiG3BjGEJtEzrGBm77QSJC+QsqE1vDDehXC lV1uJ1jNFsev10cpDEhl3GlqP2+Ahd6btHZJM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=u1XzSpS/OXXTDtMYPJYdTWECh/frq0kt23SlUK2wgRNQtOuwGnhzRheutNo5ZGUVXq KdZLDlI/1UnfZS2ZJlDr8JgCP+4n3/4eIu1oPitpdOh+zcySZLOVRQCsKgfOq53W5Zgd G1ntw2AlfW2lwG+P6q3TBn+B3WHue4LhfXK74= MIME-Version: 1.0 Received: by 10.231.159.199 with HTTP; Mon, 19 Apr 2010 05:46:36 -0700 (PDT) From: "Sergio Luis O. B. Correia" Date: Mon, 19 Apr 2010 09:46:36 -0300 Received: by 10.114.33.26 with SMTP id g26mr3711347wag.216.1271681216252; Mon, 19 Apr 2010 05:46:56 -0700 (PDT) Message-ID: To: ospf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OSPF] OSPFv2 LS checksum question X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 12:47:08 -0000 Hello all, I am trying to calculate the LS checksum regarding the following LSA header [1], but I am not able to get the 0x389d after applying Fletcher's checksum. RFC 2328, section 12.1.7 says the LS checksum field is the checksum of the complete LS header, excepting the LS Age field. For the LS Header shown in [1], what would I use as input for the checksum algorithm? I am merely excluding the two first bytes (LS Age field) and using the LS checksum field as zero in this calculation, like this: 02 01 c0 a8 aa 03 c0 a8 aa 03 80 00 00 02 00 00 00 30 but it's giving me wrong results (not 0x389d). I believe I am doing something wrong, but I don't know what. Could someone point me the right way to perform this calculations? Thanks in advance, sergio. -- [1] LSA Header: LS Age: 1 seconds Options: 0x02 Link-State Advertisement Type: Router-LSA (0x01) Link-State ID: 192.168.170.3 (0xc0a8aa03) Advertising Router: 192.168.170.3 (0xc0a8aa03) LS Sequence Number: 0x80000002 LS Checksum: 0x389d Length: 48 (0x30) And follows the LSA header, as shown in wireshark: 00 01 02 01 c0 a8 aa 03 c0 a8 aa 03 80 00 00 02 38 9d 00 30 From acee.lindem@ericsson.com Mon Apr 19 09:05:12 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82F83A6AF1 for ; Mon, 19 Apr 2010 09:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.684 X-Spam-Level: X-Spam-Status: No, score=-3.684 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjI3tNvZnJks for ; Mon, 19 Apr 2010 09:05:11 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 05A9228C42F for ; Mon, 19 Apr 2010 08:47:16 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3JFl6j7009304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 Apr 2010 10:47:07 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.98]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 19 Apr 2010 11:47:05 -0400 From: Acee Lindem To: "Sergio Luis O. B. Correia" Date: Mon, 19 Apr 2010 11:47:04 -0400 Thread-Topic: [OSPF] OSPFv2 LS checksum question Thread-Index: Acrf14/Wi+E5s/SWQJKhFU7za5Xw4w== Message-ID: <02F45E41-CEB2-4107-AAB3-BD2DD4C17401@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPFv2 LS checksum question X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 16:05:12 -0000 Hi Sergio, On Apr 19, 2010, at 8:46 AM, Sergio Luis O. B. Correia wrote: > Hello all, >=20 > I am trying to calculate the LS checksum regarding the following LSA > header [1], but I am not able to get the 0x389d after applying > Fletcher's checksum. >=20 > RFC 2328, section 12.1.7 says the LS checksum field is the checksum of > the complete LS header, excepting the LS Age field. For the LS Header > shown in [1], what would I use as input for the checksum algorithm? RFC 2328 doesn't say that - it says "the complete contents of the LSA, exce= pting the LS age field". So, if you're only using the LSA header, you're c= ertain to get the wrong result.=20 Hope this helps, Acee=20 >=20 > I am merely excluding the two first bytes (LS Age field) and using the > LS checksum field as zero in this calculation, like this: >=20 > 02 01 c0 a8 aa 03 c0 a8 aa 03 80 00 00 02 00 00 00 30 >=20 > but it's giving me wrong results (not 0x389d). I believe I am doing > something wrong, but I don't know what. Could someone point me the > right way to perform this calculations? >=20 > Thanks in advance, > sergio. >=20 >=20 > -- > [1] LSA Header: >=20 > LS Age: 1 seconds > Options: 0x02 > Link-State Advertisement Type: Router-LSA (0x01) > Link-State ID: 192.168.170.3 (0xc0a8aa03) > Advertising Router: 192.168.170.3 (0xc0a8aa03) > LS Sequence Number: 0x80000002 > LS Checksum: 0x389d > Length: 48 (0x30) >=20 > And follows the LSA header, as shown in wireshark: >=20 > 00 01 02 01 c0 a8 aa 03 c0 a8 aa 03 80 00 00 02 38 9d 00 30 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From eeeesti@gmail.com Tue Apr 20 14:47:09 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D1D3A68D8 for ; Tue, 20 Apr 2010 14:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.214 X-Spam-Level: X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5 tests=[AWL=0.896, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwQI2Szjm8Sv for ; Tue, 20 Apr 2010 14:47:08 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 048733A68C4 for ; Tue, 20 Apr 2010 14:47:07 -0700 (PDT) Received: by iwn27 with SMTP id 27so1467334iwn.5 for ; Tue, 20 Apr 2010 14:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=MjahDQ9FZv34UnoueAy+ReKzQZ1RmQS5oXJonZI9eEo=; b=ZE+WH9H8oDhQxknEX2OUeAb1AT2CAsZzid0CkjPlQX1T0ammm6yPV0FhRzIPONeID5 SVWdaCUGjDpsKLcqJHtqRcAiCKymrBXlR1e0tWPYaBRcctngsyo6SoJ0M3qtxKUQMDlT huwOrFfrX0LaTrdoDwvsJnkEKwVfbyUY1W5Zc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=eBpnlhVmf1IX3wW1ilt1eupBhQYTBs3q1SdI0AGELGf66wQVdRGAaA9YDwsiv8su4K sGn6aPmvb+Qp6Q2kexsnz+jv60IGPIBAE8I+znfPYvIoL/XtMZDykCBztHsF8BN4tWez YxFOf5FOHQh4WYIoCTQZRGgDDE6xLIhAb4a7g= MIME-Version: 1.0 Received: by 10.231.168.139 with HTTP; Tue, 20 Apr 2010 14:46:36 -0700 (PDT) In-Reply-To: <02F45E41-CEB2-4107-AAB3-BD2DD4C17401@ericsson.com> References: <02F45E41-CEB2-4107-AAB3-BD2DD4C17401@ericsson.com> From: "Sergio Luis O. B. Correia" Date: Tue, 20 Apr 2010 18:46:36 -0300 Received: by 10.231.172.203 with SMTP id m11mr2572525ibz.15.1271800016330; Tue, 20 Apr 2010 14:46:56 -0700 (PDT) Message-ID: To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPFv2 LS checksum question X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 21:47:09 -0000 Hello, Acee. indeed, I had misread the text. Thanks for pointing out! greetings, sergio On Mon, Apr 19, 2010 at 12:47 PM, Acee Lindem wr= ote: > Hi Sergio, > > On Apr 19, 2010, at 8:46 AM, Sergio Luis O. B. Correia wrote: > >> Hello all, >> >> I am trying to calculate the LS checksum regarding the following LSA >> header [1], but I am not able to get the 0x389d after applying >> Fletcher's checksum. >> >> RFC 2328, section 12.1.7 says the LS checksum field is the checksum of >> the complete LS header, excepting the LS Age field. For the LS Header >> shown in [1], what would I use as input for the checksum algorithm? > > RFC 2328 doesn't say that - it says "the complete contents of the LSA, ex= cepting the LS age field". =A0So, if you're only using the LSA header, you'= re certain to get the wrong result. > > Hope this helps, > Acee > > > > > > >> >> I am merely excluding the two first bytes (LS Age field) and using the >> LS checksum field as zero in this calculation, like this: >> >> 02 01 c0 a8 aa 03 c0 a8 aa 03 80 00 00 02 00 00 00 30 >> >> but it's giving me wrong results (not 0x389d). I believe I am doing >> something wrong, but I don't know what. Could someone point me the >> right way to perform this calculations? >> >> Thanks in advance, >> sergio. >> >> >> -- >> [1] LSA Header: >> >> LS Age: 1 seconds >> Options: 0x02 >> Link-State Advertisement Type: Router-LSA (0x01) >> Link-State ID: 192.168.170.3 (0xc0a8aa03) >> Advertising Router: 192.168.170.3 (0xc0a8aa03) >> LS Sequence Number: 0x80000002 >> LS Checksum: 0x389d >> Length: 48 (0x30) >> >> And follows the LSA header, as shown in wireshark: >> >> 00 01 02 01 c0 a8 aa 03 c0 a8 aa 03 80 00 00 02 38 9d 00 30 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > From wwwrun@rfc-editor.org Tue Apr 20 16:58:46 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60B6B3A6BEA; Tue, 20 Apr 2010 16:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgug9tR1ZDFn; Tue, 20 Apr 2010 16:58:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 9614F3A6BBD; Tue, 20 Apr 2010 16:58:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3442EE07FB; Tue, 20 Apr 2010 16:58:34 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100420235834.3442EE07FB@rfc-editor.org> Date: Tue, 20 Apr 2010 16:58:34 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] RFC 5838 on Support of Address Families in OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 23:58:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5838 Title: Support of Address Families in OSPFv3 Author: A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes, R. Aggarwal Status: Standards Track Stream: IETF Date: April 2010 Mailbox: acee.lindem@ericsson.com, smirtora@cisco.com, akr@cisco.com, mjbarnes@cisco.com, rahul@juniper.net Pages: 13 Characters: 26193 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ospf-af-alt-10.txt URL: http://www.rfc-editor.org/rfc/rfc5838.txt This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances. It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs. [STANDARDS TRACK] This document is a product of the Open Shortest Path First IGP Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC