[OSPF] WG Last Call for OSPF Link-local Signaling -draft-ietf-ospf-l= ls-04.txt

Hi Acee,<= /DIV>

Generally, the draft looks=20 useful/good. One question: TLVs 32768-65535 are marked for Private Us= e=20 -- what is the method for distinguishing the meaning for these TL= Vs=20 when two different implementations utilize the same Private Use=20 TLV? Should OUI be placed in the first 3 octets? If so, can the = I-D=20 capture this?

Thanks,

Jonathan Sadler

From: ospf-bounces@ietf.org on behalf o= f Acee=20 Lindem
Sent: Fri 2/15/2008 11:15 AM
To: OSPF=20 List
Subject: [OSPF] WG Last Call for OSPF Link-local Signaling=20 -draft-ietf-ospf-lls-04.txt

This starts the WG last call for the subject document. Th= e=20 target
status is Proposed Standard.
The WG last call will begin=20 today and will end March 1st, 2008 at
12:00 AM EST. Note that a=20 previous revision (not including OSPFv3) of
this protocol extensio= n was=20 published as an experimental RFC=20 4813.

Thanks,
Acee
___________________________________________= ____
OSPF=20 mailing list
OSPF@ietf.org
http://www.ietf.org/mail= man/listinfo/ospf

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C87002.508FBB4B-- --===============1311867538== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf --===============1311867538==-- From ospf-bounces@ietf.org Fri Feb 15 11:10:10 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B66A28D1DA; Fri, 15 Feb 2008 11:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[AWL=-0.503, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 1O3oPsHLt2zP; Fri, 15 Feb 2008 11:10:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76BFA28D06C; Fri, 15 Feb 2008 11:10:09 -0800 (PST) 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 EC51528D06C for ; Fri, 15 Feb 2008 11:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 KpmQoq1YM3kz for ; Fri, 15 Feb 2008 11:10:07 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 00E7528D1DA for ; Fri, 15 Feb 2008 11:10:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C9D8BCA97A; Fri, 15 Feb 2008 11:11:27 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27333-06; Fri, 15 Feb 2008 11:11:27 -0800 (PST) Received: from [???????IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 5A5F7CA979; Fri, 15 Feb 2008 11:11:27 -0800 (PST) In-Reply-To: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <09BDC1B6-E728-48BD-8778-3EAF7BF8EFE9@redback.com> From: Acee Lindem Date: Fri, 15 Feb 2008 14:11:26 -0500 To: "Vishwas Manral" X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Vishwas, I suppose I should let the authors respond first but here are my thoughts (speaking as a WG member). On Feb 15, 2008, at 12:41 PM, Vishwas Manral wrote: > Hi Acee, > > I like the generic mechanism talked about in the document. I however > think the document does not describe how to treat TLV's if a TLV is > not understood. If you see all other newer specs for example RFC5036 > for LDP, you will notice they have the first 2 bits defining how to > treat a packet if there is an unknown TLV. LLS is optional so the TLVs should have no impact on whether or not the OSPF packet itself is accepted. The document probably should state: 1) That the described TLVs MUST be supported. 2) What to do if an unknown TLV is encountered. The choices are: a. Simply ignore it - this is what people have implemented. b. Ignore the whole LLS block c. Ignore the whole LLS block contingent on the type encoding I vote for a. > > The document says the block can only be attached to Hello and DD > packets, I would prefer the signaling to be able to be attached to any > packets. Thus making OSPF packets truly extensible. I think that since this is "Link-Local" signaling, hello and DD packets make the most sense. In fact, at one time I had argued to limit it to hellos but the authors said there were cases where appending the signaling to the next DD would result in the signaling being communicated faster. However, since a hello can safely be sent at any time, I still feel limiting it to hello would be better :^). > > The document talks about not doing a checksum if the Crytographic > security is present. I think it enhances security as well as > simplifies code if we calculate the checksum in all cases. This is consistent to what is done for OSPF cryptographic authentication for the packet itself. I see no reason not to do the same for LLS or to effectively checksum it twice when authentication is configured. > Also the > document seems to think that MD5 is the only cryptographic > authentication method present and explicitly mentions it. The same > needs to be removed. Infact if we hear the view on MD5 it is closer > to: > > * Use of MD5, ciphers with a strength of 56 bits or less should be > avoided in almost all circumstances. Use of ciphers with key sizes of > 64 bits or less should be discontinued as soon as is practicable. Agree - it should be written to cover further authentication mechanisms. > > quoting from a mail in the SAAG list. > > Also as routers that do not understand LLS may receive the packets, we > have to make sure to state that we need to take care changes made due > to LLS block TLV's do not affect the basic routing when interacting > with non-LLS routers. This will be a helpful guidance for any future > extensions to LLS TLV's. A statement along these lines should be included as well. Thanks, Acee > > Thanks, > Vishwas > > On Fri, Feb 15, 2008 at 9:15 AM, Acee Lindem wrote: >> This starts the WG last call for the subject document. The target >> status is Proposed Standard. >> The WG last call will begin today and will end March 1st, 2008 at >> 12:00 AM EST. Note that a previous revision (not including >> OSPFv3) of >> this protocol extension was published as an experimental RFC 4813. >> >> Thanks, >> Acee >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> http://www.ietf.org/mailman/listinfo/ospf >> _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Feb 15 11:31:26 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57AF228D19E; Fri, 15 Feb 2008 11:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[AWL=-0.952, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, 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 7xxoE9X-Got9; Fri, 15 Feb 2008 11:31:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4554128D2E9; Fri, 15 Feb 2008 11:31:25 -0800 (PST) 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 EE0723A6AFB for ; Fri, 15 Feb 2008 11:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 91sd1g9b7lM4 for ; Fri, 15 Feb 2008 11:31:23 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id EE11A28D317 for ; Fri, 15 Feb 2008 11:30:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B3D1EBFAE71; Fri, 15 Feb 2008 11:32:17 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31716-10; Fri, 15 Feb 2008 11:32:17 -0800 (PST) Received: from [???????IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 08DBDBFAE77; Fri, 15 Feb 2008 11:32:16 -0800 (PST) In-Reply-To: References:

Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <2CFCF516-6ED0-424B-8ECA-19D2DE4502BD@redback.com> From: Acee Lindem Date: Fri, 15 Feb 2008 14:32:15 -0500 To: "Sadler, Jonathan B." X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling -draft-ietf-ospf-lls-04.txt 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: , Content-Type: multipart/mixed; boundary="===============0711283368==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============0711283368== Content-Type: multipart/alternative; boundary=Apple-Mail-5--689047217 --Apple-Mail-5--689047217 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Jonathan, You've pointed out what I see as a problem with many experimental and private IANA ranges. I agree with the solution you suggest is what should be done - the vendor code should be required as the first 4 octets of the value field in TLVs in the experimental/vendor range. This is also consistent with other OSPF IANA ranges defined in RFC 4940. Thanks, Acee On Feb 15, 2008, at 1:41 PM, Sadler, Jonathan B. wrote: > Hi Acee, > > Generally, the draft looks useful/good. One question: TLVs > 32768-65535 are marked for Private Use -- what is the method for > distinguishing the meaning for these TLVs when two different > implementations utilize the same Private Use TLV? Should OUI be > placed in the first 3 octets? If so, can the I-D capture this? > > Thanks, > > Jonathan Sadler > > From: ospf-bounces@ietf.org on behalf of Acee Lindem > Sent: Fri 2/15/2008 11:15 AM > To: OSPF List > Subject: [OSPF] WG Last Call for OSPF Link-local Signaling -draft- > ietf-ospf-lls-04.txt > > This starts the WG last call for the subject document. The target > status is Proposed Standard. > The WG last call will begin today and will end March 1st, 2008 at > 12:00 AM EST. Note that a previous revision (not including OSPFv3) of > this protocol extension was published as an experimental RFC 4813. > > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > http://www.ietf.org/mailman/listinfo/ospf > > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the reader > of this message is not the intended recipient, or an employee > or agent responsible for delivering this message to the > intended recipient, you are hereby notified that any reproduction, > dissemination or distribution of this communication is strictly > prohibited. If you have received this communication in error, > please notify us immediately by replying to the message and > deleting it from your computer. Thank you. Tellabs > ============================================================ --Apple-Mail-5--689047217 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Jonathan,

You've pointed out what I see as a problem with many = experimental and private IANA ranges. I agree with the solution you = suggest is what should be done - the vendor code should be required as = the first 4 octets of the value field in TLVs in the experimental/vendor = range. This is also consistent with other OSPF IANA ranges defined in = RFC 4940.=A0

Thanks,

Acee=A0

On Feb 15, 2008, at = 1:41 PM, Sadler, Jonathan B. wrote:

=

Hi Acee,

=A0

Generally, the draft looks = useful/good.=A0 One question: TLVs 32768-65535 are marked for Private = Use --=A0what is the method for distinguishing the=A0meaning for these = TLVs when two different implementations utilize the same Private Use = TLV?=A0=A0Should OUI be placed in the first 3 octets? If so, can the I-D = capture this?

=A0

Thanks,

=A0

Jonathan Sadler

From: ospf-bounces@ietf.org on = behalf of Acee Lindem
Sent: Fri 2/15/2008 11:15 = AM
To: OSPF List
Subject: [OSPF] WG Last Call for = OSPF Link-local Signaling = -draft-ietf-ospf-lls-04.txt

This starts the WG last call for the subject document. The = target=A0
status is Proposed Standard.
The WG last call will begin = today and will end March 1st, 2008 at=A0
12:00 AM EST. Note that a = previous revision (not including OSPFv3) of=A0
this protocol = extension was published as an experimental RFC = 4813.

Thanks,
Acee
__________________________________________= _____
OSPF mailing list
OSPF@ietf.org
http://www.ietf.org/mai= lman/listinfo/ospf
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

= --Apple-Mail-5--689047217-- --===============0711283368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf --===============0711283368==-- From ospf-bounces@ietf.org Fri Feb 15 11:36:06 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A335628D339; Fri, 15 Feb 2008 11:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.026 X-Spam-Level: X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 tIsOqkAA1pnJ; Fri, 15 Feb 2008 11:36:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC373A6AFB; Fri, 15 Feb 2008 11:36:05 -0800 (PST) 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 7C2683A6AE0 for ; Fri, 15 Feb 2008 11:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 DgV7zwQ4vw2l for ; Fri, 15 Feb 2008 11:36:03 -0800 (PST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by core3.amsl.com (Postfix) with ESMTP id 678F63A6AA7 for ; Fri, 15 Feb 2008 11:36:03 -0800 (PST) Received: by wr-out-0506.google.com with SMTP id 50so1549215wri.25 for ; Fri, 15 Feb 2008 11:37:23 -0800 (PST) Received: by 10.142.241.10 with SMTP id o10mr2512593wfh.165.1203104242414; Fri, 15 Feb 2008 11:37:22 -0800 (PST) Received: by 10.143.164.14 with HTTP; Fri, 15 Feb 2008 11:37:22 -0800 (PST) Message-ID: <77ead0ec0802151137k7f4690d3i3421fe32cf6669f1@mail.gmail.com> Date: Fri, 15 Feb 2008 11:37:22 -0800 From: "Vishwas Manral" To: "Acee Lindem" In-Reply-To: <09BDC1B6-E728-48BD-8778-3EAF7BF8EFE9@redback.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> <09BDC1B6-E728-48BD-8778-3EAF7BF8EFE9@redback.com> Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Acee, > > I like the generic mechanism talked about in the document. I however > > think the document does not describe how to treat TLV's if a TLV is > > not understood. If you see all other newer specs for example RFC5036 > > for LDP, you will notice they have the first 2 bits defining how to > > treat a packet if there is an unknown TLV. > > LLS is optional so the TLVs should have no impact on whether or not > the OSPF packet itself is accepted. The document probably should state: > > 1) That the described TLVs MUST be supported. > 2) What to do if an unknown TLV is encountered. The choices are: > a. Simply ignore it - this is what people have implemented. > b. Ignore the whole LLS block > c. Ignore the whole LLS block contingent on the type encoding > > I vote for a. By having this we are forcing a behavior on future TLV's, they all have to be optionally understood. We cannot enforce a behavior of drop a packet if the TLV is not understood. By using the first 2 bits of the TLV's to signal this behavior we could get such behavior for the future. In my view such signalling may be possible in the future. > > The document says the block can only be attached to Hello and DD > > packets, I would prefer the signaling to be able to be attached to any > > packets. Thus making OSPF packets truly extensible. > > I think that since this is "Link-Local" signaling, hello and DD > packets make the most sense. In fact, at one time I had argued to > limit it to hellos but the authors said there were cases where > appending the signaling to the next DD would result in the signaling > being communicated faster. However, since a hello can safely be sent > at any time, I still feel limiting it to hello would be better :^). I do not see a reason to not allow LLS to packets other than Hello and DD. Its all about future extensibility here. We should try to be future proof by allowing the same. If a TLV is not expected in a packet it can anyway be ignored. > > The document talks about not doing a checksum if the Crytographic > > security is present. I think it enhances security as well as > > simplifies code if we calculate the checksum in all cases. > > This is consistent to what is done for OSPF cryptographic > authentication for the packet itself. I see no reason not to do the > same for LLS or to effectively checksum it twice when authentication > is configured. I agree it is consistent. I however see no benefits in the approach, though I can point out problems with it. If we are making a new standard we could as well rectify the same. Thanks, Vishwas > > Thanks, > Acee > > > > > > > > Thanks, > > Vishwas > > > > On Fri, Feb 15, 2008 at 9:15 AM, Acee Lindem wrote: > >> This starts the WG last call for the subject document. The target > >> status is Proposed Standard. > >> The WG last call will begin today and will end March 1st, 2008 at > >> 12:00 AM EST. Note that a previous revision (not including > >> OSPFv3) of > >> this protocol extension was published as an experimental RFC 4813. > >> > >> Thanks, > >> Acee > >> _______________________________________________ > >> OSPF mailing list > >> OSPF@ietf.org > >> http://www.ietf.org/mailman/listinfo/ospf > >> > > _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sun Feb 17 18:31:56 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACC823A6BBA; Sun, 17 Feb 2008 18:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 N7DbF-uJ6N+J; Sun, 17 Feb 2008 18:31:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80CB13A6BBF; Sun, 17 Feb 2008 18:31:55 -0800 (PST) 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 B8D133A6BBF for ; Sun, 17 Feb 2008 18:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 XtvBLIYKKRuQ for ; Sun, 17 Feb 2008 18:31:53 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id C14F33A6BBA for ; Sun, 17 Feb 2008 18:31:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 2672058AB1E; Sun, 17 Feb 2008 18:31:52 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16294-08; Sun, 17 Feb 2008 18:31:52 -0800 (PST) Received: from [*2?????IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 843A258AB1D; Sun, 17 Feb 2008 18:31:51 -0800 (PST) In-Reply-To: <77ead0ec0802151137k7f4690d3i3421fe32cf6669f1@mail.gmail.com> References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> <09BDC1B6-E728-48BD-8778-3EAF7BF8EFE9@redback.com> <77ead0ec0802151137k7f4690d3i3421fe32cf6669f1@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Acee Lindem Date: Sun, 17 Feb 2008 21:31:50 -0500 To: Vishwas Manral X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Vishwas, On Feb 15, 2008, at 2:37 PM, Vishwas Manral wrote: > Hi Acee, > >>> I like the generic mechanism talked about in the document. I however >>> think the document does not describe how to treat TLV's if a TLV is >>> not understood. If you see all other newer specs for example RFC5036 >>> for LDP, you will notice they have the first 2 bits defining how to >>> treat a packet if there is an unknown TLV. >> >> LLS is optional so the TLVs should have no impact on whether or not >> the OSPF packet itself is accepted. The document probably should >> state: >> >> 1) That the described TLVs MUST be supported. >> 2) What to do if an unknown TLV is encountered. The choices are: >> a. Simply ignore it - this is what people have implemented. >> b. Ignore the whole LLS block >> c. Ignore the whole LLS block contingent on the type encoding >> >> I vote for a. > By having this we are forcing a behavior on future TLV's, they all > have to be optionally understood. We cannot enforce a behavior of drop > a packet if the TLV is not understood. You're missing the point that LLS is optional. There will be routers that don't support LLS that will process packets independent of what TLVs that are sent. Hence, there shouldn't be OSPF routers that understand LLS that drop the OSPF packet contingent on not understanding an LLS TLV. > By using the first 2 bits of > the TLV's to signal this behavior we could get such behavior for the > future. In my view such signalling may be possible in the future. > >>> The document says the block can only be attached to Hello and DD >>> packets, I would prefer the signaling to be able to be attached >>> to any >>> packets. Thus making OSPF packets truly extensible. >> >> I think that since this is "Link-Local" signaling, hello and DD >> packets make the most sense. In fact, at one time I had argued to >> limit it to hellos but the authors said there were cases where >> appending the signaling to the next DD would result in the signaling >> being communicated faster. However, since a hello can safely be sent >> at any time, I still feel limiting it to hello would be better :^). > I do not see a reason to not allow LLS to packets other than Hello and > DD. Its all about future extensibility here. We should try to be > future proof by allowing the same. If a TLV is not expected in a > packet it can anyway be ignored. This doesn't come for free. What types of things do you see LLS being used to signal on the other packet types? The same or different as hello and DD? This is for one hop signaling. > >>> The document talks about not doing a checksum if the Crytographic >>> security is present. I think it enhances security as well as >>> simplifies code if we calculate the checksum in all cases. >> >> This is consistent to what is done for OSPF cryptographic >> authentication for the packet itself. I see no reason not to do the >> same for LLS or to effectively checksum it twice when authentication >> is configured. > I agree it is consistent. I however see no benefits in the > approach, though > I can point out problems with it. Ok - what are they? A cryptographic HMAC hash is likely to be stronger than the standard inet checksum. The only advantage I can see is that you'll know the when there is a checksum error rather than an authentication failure. IMHO, doing both just for this advantage isn't a very good engineering trade-off at all. Sort of like taking both a bath and a shower on the hopes you might get a little cleaner. Acee > If we are making a new standard we could > as well rectify the same. > > > Thanks, > Vishwas > >> >> Thanks, >> Acee >> >> >> >> >>> >>> Thanks, >>> Vishwas >>> >>> On Fri, Feb 15, 2008 at 9:15 AM, Acee Lindem >>> wrote: >>>> This starts the WG last call for the subject document. The target >>>> status is Proposed Standard. >>>> The WG last call will begin today and will end March 1st, 2008 at >>>> 12:00 AM EST. Note that a previous revision (not including >>>> OSPFv3) of >>>> this protocol extension was published as an experimental RFC 4813. >>>> >>>> Thanks, >>>> Acee >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> http://www.ietf.org/mailman/listinfo/ospf >>>> >> >> _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Feb 18 09:35:46 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6893A68FE; Mon, 18 Feb 2008 09:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 WzKxxzkQ72ZY; Mon, 18 Feb 2008 09:35:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23A528C444; Mon, 18 Feb 2008 09:35:45 -0800 (PST) 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 D601528C450 for ; Mon, 18 Feb 2008 09:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 FSJHiodU6mKm for ; Mon, 18 Feb 2008 09:35:43 -0800 (PST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by core3.amsl.com (Postfix) with ESMTP id BE30328C43F for ; Mon, 18 Feb 2008 09:35:42 -0800 (PST) Received: by wr-out-0506.google.com with SMTP id 50so2126531wri.25 for ; Mon, 18 Feb 2008 09:35:40 -0800 (PST) Received: by 10.142.98.18 with SMTP id v18mr4550148wfb.61.1203356139349; Mon, 18 Feb 2008 09:35:39 -0800 (PST) Received: by 10.143.164.14 with HTTP; Mon, 18 Feb 2008 09:35:39 -0800 (PST) Message-ID: <77ead0ec0802180935x11e92eecub901fdf63b1d391@mail.gmail.com> Date: Mon, 18 Feb 2008 09:35:39 -0800 From: "Vishwas Manral" To: "Acee Lindem" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> <09BDC1B6-E728-48BD-8778-3EAF7BF8EFE9@redback.com> <77ead0ec0802151137k7f4690d3i3421fe32cf6669f1@mail.gmail.com> Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Acee, > > By having this we are forcing a behavior on future TLV's, they all > > have to be optionally understood. We cannot enforce a behavior of drop > > a packet if the TLV is not understood. > > You're missing the point that LLS is optional. There will be routers > that don't support LLS that will process packets independent of what > TLVs that are sent. Hence, there shouldn't be OSPF routers that > understand LLS that drop the OSPF packet contingent on not > understanding an LLS TLV. I agree LLS is currently optional, but like the Optional Opaque LSA functionality, it will become an important part of most functionality. One of the main issues I note about OSPF is that the packets and information elements are not scalable, unlike TLV based protocols. I think LLS mitigates this limitation. > > By using the first 2 bits of > > the TLV's to signal this behavior we could get such behavior for the > > future. In my view such signalling may be possible in the future. > > > >>> The document says the block can only be attached to Hello and DD > >>> packets, I would prefer the signaling to be able to be attached > >>> to any > >>> packets. Thus making OSPF packets truly extensible. > >> > >> I think that since this is "Link-Local" signaling, hello and DD > >> packets make the most sense. In fact, at one time I had argued to > >> limit it to hellos but the authors said there were cases where > >> appending the signaling to the next DD would result in the signaling > >> being communicated faster. However, since a hello can safely be sent > >> at any time, I still feel limiting it to hello would be better :^). > > I do not see a reason to not allow LLS to packets other than Hello and > > DD. Its all about future extensibility here. We should try to be > > future proof by allowing the same. If a TLV is not expected in a > > packet it can anyway be ignored. > > This doesn't come for free. What types of things do you see LLS being > used to signal on the other packet types? The same or different as > hello and DD? This is for one hop signaling. All OSPF packets are one hop signaled, unlike IS-IS, where the same LSP needs to be flooded through the domain. > >>> The document talks about not doing a checksum if the Crytographic > >>> security is present. I think it enhances security as well as > >>> simplifies code if we calculate the checksum in all cases. > >> > >> This is consistent to what is done for OSPF cryptographic > >> authentication for the packet itself. I see no reason not to do the > >> same for LLS or to effectively checksum it twice when authentication > >> is configured. > > I agree it is consistent. I however see no benefits in the > > approach, though > > I can point out problems with it. > > Ok - what are they? A cryptographic HMAC hash is likely to be > stronger than the standard inet checksum. The only advantage I can > see is that you'll know the when there is a checksum error rather > than an authentication failure. IMHO, doing both just for this > advantage isn't a very good engineering trade-off at all. Sort of > like taking both a bath and a shower on the hopes you might get a > little cleaner. Actually the currently known attacks in MD5 are done using keeping some fields as constant (like say some fields in the packet which will lead to the undesired behavior) and trying all random combinations of the other fields to get the same value of Hash. This however will not be possible for the Checksum field, as any random combination will not qualify for a valid checksum. That said I am ok, if we can leave the behavior as is. Thanks, Vishwas > > > > > If we are making a new standard we could > > as well rectify the same. > > > > > > Thanks, > > Vishwas > > > >> > >> Thanks, > >> Acee > >> > >> > >> > >> > >>> > >>> Thanks, > >>> Vishwas > >>> > >>> On Fri, Feb 15, 2008 at 9:15 AM, Acee Lindem > >>> wrote: > >>>> This starts the WG last call for the subject document. The target > >>>> status is Proposed Standard. > >>>> The WG last call will begin today and will end March 1st, 2008 at > >>>> 12:00 AM EST. Note that a previous revision (not including > >>>> OSPFv3) of > >>>> this protocol extension was published as an experimental RFC 4813. > >>>> > >>>> Thanks, > >>>> Acee > >>>> _______________________________________________ > >>>> OSPF mailing list > >>>> OSPF@ietf.org > >>>> http://www.ietf.org/mailman/listinfo/ospf > >>>> > >> > >> > > _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Feb 18 10:28:38 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5861728C3FE; Mon, 18 Feb 2008 10:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-2.171, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 QOfn9kTvC0R7; Mon, 18 Feb 2008 10:28:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F67F28C3FA; Mon, 18 Feb 2008 10:28:37 -0800 (PST) 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 25BBF28C3FE for ; Mon, 18 Feb 2008 10:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 RshzJOHEGbCK for ; Mon, 18 Feb 2008 10:28:35 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 465DE28C35F for ; Mon, 18 Feb 2008 10:28:35 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 18 Feb 2008 10:28:33 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1IISXXh013879; Mon, 18 Feb 2008 10:28:33 -0800 Received: from akr-lnx (akr-lnx.cisco.com [171.71.54.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1IISXvo023851; Mon, 18 Feb 2008 18:28:33 GMT Date: Mon, 18 Feb 2008 10:28:33 -0800 (PST) From: Abhay Roy To: Vishwas Manral In-Reply-To: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> Message-ID: References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> MIME-Version: 1.0 Authentication-Results: sj-dkim-3; header.From=akr@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Vishwas, Thanks for your comments. Please see inline: On 02/15/08-0800 at 9:41am, Vishwas Manral writes: > Hi Acee, > > I like the generic mechanism talked about in the document. I however > think the document does not describe how to treat TLV's if a TLV is > not understood. If you see all other newer specs for example RFC5036 > for LDP, you will notice they have the first 2 bits defining how to > treat a packet if there is an unknown TLV. Looking at some previous TLV usage in OSPF specs (e.g. rfc3630), I think all we need to add is "Unrecognized TLV types are ignored." I will add this text in section 2.3. > The document says the block can only be attached to Hello and DD > packets, I would prefer the signaling to be able to be attached to any > packets. Thus making OSPF packets truly extensible. Initially we only wanted it in Hello packets. But then we found some use case for DD packets (rfc 4812). Sending LLS with any packet type is technically feasible, but would require separate documentation when such a need arises. I would prefer to not include it in here at this time, since there is no known use case. > The document talks about not doing a checksum if the Crytographic > security is present. I think it enhances security as well as > simplifies code if we calculate the checksum in all cases. Also the > document seems to think that MD5 is the only cryptographic > authentication method present and explicitly mentions it. The same > needs to be removed. Infact if we hear the view on MD5 it is closer > to: > > * Use of MD5, ciphers with a strength of 56 bits or less should be > avoided in almost all circumstances. Use of ciphers with key sizes of > 64 bits or less should be discontinued as soon as is practicable. I will remove direct references to MD5, so that it's equally applicable to any available cryptographic authentication. > quoting from a mail in the SAAG list. > > Also as routers that do not understand LLS may receive the packets, we > have to make sure to state that we need to take care changes made due > to LLS block TLV's do not affect the basic routing when interacting > with non-LLS routers. This will be a helpful guidance for any future > extensions to LLS TLV's. Sure, I will add something to this effect.. Regards, -Abhay > Thanks, > Vishwas > > On Fri, Feb 15, 2008 at 9:15 AM, Acee Lindem wrote: >> This starts the WG last call for the subject document. The target >> status is Proposed Standard. >> The WG last call will begin today and will end March 1st, 2008 at >> 12:00 AM EST. Note that a previous revision (not including OSPFv3) of >> this protocol extension was published as an experimental RFC 4813. >> >> Thanks, >> Acee >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> http://www.ietf.org/mailman/listinfo/ospf >> > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > http://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Feb 18 10:52:41 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1683F28C500; Mon, 18 Feb 2008 10:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 XrX5wr6ruYSz; Mon, 18 Feb 2008 10:52:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E263A6CE0; Mon, 18 Feb 2008 10:52:38 -0800 (PST) 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 AAF753A6D20 for ; Mon, 18 Feb 2008 10:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 2BgimM2OUTgp for ; Mon, 18 Feb 2008 10:52:36 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C13493A68AA for ; Mon, 18 Feb 2008 10:52:36 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 18 Feb 2008 10:52:34 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1IIqW7P018952; Mon, 18 Feb 2008 10:52:32 -0800 Received: from [171.71.139.47] (dhcp-171-71-139-47.cisco.com [171.71.139.47]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1IIqWuL006572; Mon, 18 Feb 2008 18:52:32 GMT Message-ID: <47B9D3EB.7010809@cisco.com> Date: Mon, 18 Feb 2008 10:52:27 -0800 From: Liem Nguyen User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Vishwas Manral References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> <09BDC1B6-E728-48BD-8778-3EAF7BF8EFE9@redback.com> <77ead0ec0802151137k7f4690d3i3421fe32cf6669f1@mail.gmail.com> <77ead0ec0802180935x11e92eecub901fdf63b1d391@mail.gmail.com> In-Reply-To: <77ead0ec0802180935x11e92eecub901fdf63b1d391@mail.gmail.com> Authentication-Results: sj-dkim-3; header.From=lhnguyen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Vishwas, Vishwas Manral wrote: >>>>> The document says the block can only be attached to Hello and DD >>>>> packets, I would prefer the signaling to be able to be attached >>>>> to any >>>>> packets. Thus making OSPF packets truly extensible. >>>>> >>>> I think that since this is "Link-Local" signaling, hello and DD >>>> packets make the most sense. In fact, at one time I had argued to >>>> limit it to hellos but the authors said there were cases where >>>> appending the signaling to the next DD would result in the signaling >>>> being communicated faster. However, since a hello can safely be sent >>>> at any time, I still feel limiting it to hello would be better :^). >>>> >>> I do not see a reason to not allow LLS to packets other than Hello and >>> DD. Its all about future extensibility here. We should try to be >>> future proof by allowing the same. If a TLV is not expected in a >>> packet it can anyway be ignored. >>> >> This doesn't come for free. What types of things do you see LLS being >> used to signal on the other packet types? The same or different as >> hello and DD? This is for one hop signaling. >> > All OSPF packets are one hop signaled, unlike IS-IS, where the same > LSP needs to be flooded through the domain. > > Given that the Options field is primarily useful in Hello and DBD packets (which is required to convey the presence of LLS block), I see no benefit in having LLS in other packet types. Thanks, Liem _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Feb 18 11:00:50 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1603628C3DE; Mon, 18 Feb 2008 11:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 icyR1rfWoq23; Mon, 18 Feb 2008 11:00:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20A7928C3C0; Mon, 18 Feb 2008 11:00:48 -0800 (PST) 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 973E028C464 for ; Mon, 18 Feb 2008 11:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 6TsLJkcFR1iT for ; Mon, 18 Feb 2008 11:00:45 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.181]) by core3.amsl.com (Postfix) with ESMTP id 1B70B28C4DB for ; Mon, 18 Feb 2008 11:00:16 -0800 (PST) Received: by el-out-1112.google.com with SMTP id j27so1235582elf.25 for ; Mon, 18 Feb 2008 11:00:14 -0800 (PST) Received: by 10.142.72.21 with SMTP id u21mr4619108wfa.82.1203361213574; Mon, 18 Feb 2008 11:00:13 -0800 (PST) Received: by 10.143.164.14 with HTTP; Mon, 18 Feb 2008 11:00:13 -0800 (PST) Message-ID: <77ead0ec0802181100j4a910fefm27ce10451ec1b4d@mail.gmail.com> Date: Mon, 18 Feb 2008 11:00:13 -0800 From: "Vishwas Manral" To: "Liem Nguyen" In-Reply-To: <47B9D3EB.7010809@cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> <09BDC1B6-E728-48BD-8778-3EAF7BF8EFE9@redback.com> <77ead0ec0802151137k7f4690d3i3421fe32cf6669f1@mail.gmail.com> <77ead0ec0802180935x11e92eecub901fdf63b1d391@mail.gmail.com> <47B9D3EB.7010809@cisco.com> Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Liem, Like I gave the example of Opaque LSA's where we created an Opaque mechanism which could be used for all packets, I envision that the LLS would be a general mechanism to add additional information to the OSPF header, just like Opaque LSA's allowed further information exchanged. Thanks, Vishwas On Feb 18, 2008 10:52 AM, Liem Nguyen wrote: > Hi Vishwas, > > > Vishwas Manral wrote: > >>>>> The document says the block can only be attached to Hello and DD > >>>>> packets, I would prefer the signaling to be able to be attached > >>>>> to any > >>>>> packets. Thus making OSPF packets truly extensible. > >>>>> > >>>> I think that since this is "Link-Local" signaling, hello and DD > >>>> packets make the most sense. In fact, at one time I had argued to > >>>> limit it to hellos but the authors said there were cases where > >>>> appending the signaling to the next DD would result in the signaling > >>>> being communicated faster. However, since a hello can safely be sent > >>>> at any time, I still feel limiting it to hello would be better :^). > >>>> > >>> I do not see a reason to not allow LLS to packets other than Hello and > >>> DD. Its all about future extensibility here. We should try to be > >>> future proof by allowing the same. If a TLV is not expected in a > >>> packet it can anyway be ignored. > >>> > >> This doesn't come for free. What types of things do you see LLS being > >> used to signal on the other packet types? The same or different as > >> hello and DD? This is for one hop signaling. > >> > > All OSPF packets are one hop signaled, unlike IS-IS, where the same > > LSP needs to be flooded through the domain. > > > > > > Given that the Options field is primarily useful in Hello and DBD > packets (which is required to convey > the presence of LLS block), I see no benefit in having LLS in other > packet types. > > Thanks, > Liem > _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Feb 18 11:06:57 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CC23A6D7E; Mon, 18 Feb 2008 11:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=-2.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 1EUHZYvVOyFi; Mon, 18 Feb 2008 11:06:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7880B28C47C; Mon, 18 Feb 2008 11:06:55 -0800 (PST) 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 03E733A6BD9 for ; Mon, 18 Feb 2008 11:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 pXdY9u-ao1xc for ; Mon, 18 Feb 2008 11:06:49 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 812CA3A6D73 for ; Mon, 18 Feb 2008 11:05:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,372,1199692800"; d="scan'208";a="13323396" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 18 Feb 2008 11:05:54 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1IJ5saw025656; Mon, 18 Feb 2008 11:05:54 -0800 Received: from [171.71.139.47] (dhcp-171-71-139-47.cisco.com [171.71.139.47]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1IJ5qJg028974; Mon, 18 Feb 2008 19:05:52 GMT Message-ID: <47B9D70B.70000@cisco.com> Date: Mon, 18 Feb 2008 11:05:47 -0800 From: Liem Nguyen User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Vishwas Manral References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> <09BDC1B6-E728-48BD-8778-3EAF7BF8EFE9@redback.com> <77ead0ec0802151137k7f4690d3i3421fe32cf6669f1@mail.gmail.com> <77ead0ec0802180935x11e92eecub901fdf63b1d391@mail.gmail.com> <47B9D3EB.7010809@cisco.com> <77ead0ec0802181100j4a910fefm27ce10451ec1b4d@mail.gmail.com> In-Reply-To: <77ead0ec0802181100j4a910fefm27ce10451ec1b4d@mail.gmail.com> Authentication-Results: sj-dkim-2; header.From=lhnguyen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Vishwas, Vishwas Manral wrote: > Hi Liem, > > Like I gave the example of Opaque LSA's where we created an Opaque > mechanism which could be used for all packets, I envision that the LLS > would be a general mechanism to add additional information to the OSPF > header, just like Opaque LSA's allowed further information exchanged. > Thanks for the comments. True, for Opaque. But given that this is a link-local signaling mechanism, I don't foresee a need where additional information can't be conveyed with either Hello or DBD packets. Liem _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Feb 18 11:10:54 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4633A6D59; Mon, 18 Feb 2008 11:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.166 X-Spam-Level: X-Spam-Status: No, score=-1.166 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 CVRBkL-e5n99; Mon, 18 Feb 2008 11:10:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5272E3A6D20; Mon, 18 Feb 2008 11:10:53 -0800 (PST) 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 531EE3A68C1 for ; Mon, 18 Feb 2008 11:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 7naLtDWoWiBs for ; Mon, 18 Feb 2008 11:10:51 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by core3.amsl.com (Postfix) with ESMTP id D74CA3A6C75 for ; Mon, 18 Feb 2008 11:10:50 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id u2so754291uge.46 for ; Mon, 18 Feb 2008 11:10:48 -0800 (PST) Received: by 10.142.180.17 with SMTP id c17mr4632819wff.83.1203361846201; Mon, 18 Feb 2008 11:10:46 -0800 (PST) Received: by 10.143.164.14 with HTTP; Mon, 18 Feb 2008 11:10:46 -0800 (PST) Message-ID: <77ead0ec0802181110x23ed95e7p2cb22ca8db66a387@mail.gmail.com> Date: Mon, 18 Feb 2008 11:10:46 -0800 From: "Vishwas Manral" To: "Liem Nguyen" In-Reply-To: <47B9D70B.70000@cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> <09BDC1B6-E728-48BD-8778-3EAF7BF8EFE9@redback.com> <77ead0ec0802151137k7f4690d3i3421fe32cf6669f1@mail.gmail.com> <77ead0ec0802180935x11e92eecub901fdf63b1d391@mail.gmail.com> <47B9D3EB.7010809@cisco.com> <77ead0ec0802181100j4a910fefm27ce10451ec1b4d@mail.gmail.com> <47B9D70B.70000@cisco.com> Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Liem, I would say its a difference of vision of where we see LLS heading to between us. However in my view if we allow the functionality, we do not create any new issues (besides of course any security issues which may result), however extending this in the future would create issues in the future. Thanks, Vishwas On Feb 18, 2008 11:05 AM, Liem Nguyen wrote: > Hi Vishwas, > > > Vishwas Manral wrote: > > Hi Liem, > > > > Like I gave the example of Opaque LSA's where we created an Opaque > > mechanism which could be used for all packets, I envision that the LLS > > would be a general mechanism to add additional information to the OSPF > > header, just like Opaque LSA's allowed further information exchanged. > > > > Thanks for the comments. > True, for Opaque. But given that this is a link-local signaling > mechanism, I don't foresee a need > where additional information can't be conveyed with either Hello or DBD > packets. > > Liem > > _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Feb 18 11:22:02 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F79A28C400; Mon, 18 Feb 2008 11:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-1.239, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 4z2ocQSfIGWG; Mon, 18 Feb 2008 11:22:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51E603A68A0; Mon, 18 Feb 2008 11:22:00 -0800 (PST) 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 4A53F3A68A0 for ; Mon, 18 Feb 2008 11:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 T7PlfwnDsaj8 for ; Mon, 18 Feb 2008 11:21:58 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 758DA3A686C for ; Mon, 18 Feb 2008 11:21:58 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 18 Feb 2008 11:21:56 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1IJLu0a013804; Mon, 18 Feb 2008 11:21:56 -0800 Received: from akr-lnx (akr-lnx.cisco.com [171.71.54.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1IJLtvo013838; Mon, 18 Feb 2008 19:21:55 GMT Date: Mon, 18 Feb 2008 11:21:55 -0800 (PST) From: Abhay Roy To: Acee Lindem In-Reply-To: <2CFCF516-6ED0-424B-8ECA-19D2DE4502BD@redback.com> Message-ID: References:

<2CFCF516-6ED0-424B-8ECA-19D2DE4502BD@redback.com> MIME-Version: 1.0 Authentication-Results: sj-dkim-4; header.From=akr@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: OSPF List , "Sadler, Jonathan B." Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling -draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Jonathan/Acee, Thanks for your comments. We will add some text based on rfc4940 on using vendor code to help distinguish them. Regards, -Abhay On 02/15/08-0500 at 2:32pm, Acee Lindem writes: > Hi Jonathan, > You've pointed out what I see as a problem with many experimental and private > IANA ranges. I agree with the solution you suggest is what should be done - > the vendor code should be required as the first 4 octets of the value field > in TLVs in the experimental/vendor range. This is also consistent with other > OSPF IANA ranges defined in RFC 4940. > Thanks, > Acee > > On Feb 15, 2008, at 1:41 PM, Sadler, Jonathan B. wrote: > >> Hi Acee, >> >> Generally, the draft looks useful/good. One question: TLVs 32768-65535 are >> marked for Private Use -- what is the method for distinguishing the meaning >> for these TLVs when two different implementations utilize the same Private >> Use TLV? Should OUI be placed in the first 3 octets? If so, can the I-D >> capture this? >> >> Thanks, >> >> Jonathan Sadler >> >> From: ospf-bounces@ietf.org on behalf of Acee Lindem >> Sent: Fri 2/15/2008 11:15 AM >> To: OSPF List >> Subject: [OSPF] WG Last Call for OSPF Link-local Signaling >> -draft-ietf-ospf-lls-04.txt >> >> This starts the WG last call for the subject document. The target >> status is Proposed Standard. >> The WG last call will begin today and will end March 1st, 2008 at >> 12:00 AM EST. Note that a previous revision (not including OSPFv3) of >> this protocol extension was published as an experimental RFC 4813. >> >> Thanks, >> Acee >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> http://www.ietf.org/mailman/listinfo/ospf >> >> ============================================================ >> The information contained in this message may be privileged >> and confidential and protected from disclosure. If the reader >> of this message is not the intended recipient, or an employee >> or agent responsible for delivering this message to the >> intended recipient, you are hereby notified that any reproduction, >> dissemination or distribution of this communication is strictly >> prohibited. If you have received this communication in error, >> please notify us immediately by replying to the message and >> deleting it from your computer. Thank you. Tellabs >> ============================================================ > _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Feb 18 11:49:58 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA7328C364; Mon, 18 Feb 2008 11:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 tjmvSBvIsfOj; Mon, 18 Feb 2008 11:49:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39E328C5AF; Mon, 18 Feb 2008 11:48:28 -0800 (PST) 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 17E7728C586 for ; Mon, 18 Feb 2008 11:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 k6LG3A0xPyUd for ; Mon, 18 Feb 2008 11:48:24 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 760FC3A6D86 for ; Mon, 18 Feb 2008 11:47:33 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 18 Feb 2008 11:47:31 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1IJlV8c025985; Mon, 18 Feb 2008 11:47:31 -0800 Received: from [171.71.139.47] (dhcp-171-71-139-47.cisco.com [171.71.139.47]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1IJlVvn006695; Mon, 18 Feb 2008 19:47:31 GMT Message-ID: <47B9E0CD.7030001@cisco.com> Date: Mon, 18 Feb 2008 11:47:25 -0800 From: Liem Nguyen User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Vishwas Manral References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> <09BDC1B6-E728-48BD-8778-3EAF7BF8EFE9@redback.com> <77ead0ec0802151137k7f4690d3i3421fe32cf6669f1@mail.gmail.com> <77ead0ec0802180935x11e92eecub901fdf63b1d391@mail.gmail.com> <47B9D3EB.7010809@cisco.com> <77ead0ec0802181100j4a910fefm27ce10451ec1b4d@mail.gmail.com> <47B9D70B.70000@cisco.com> <77ead0ec0802181110x23ed95e7p2cb22ca8db66a387@mail.gmail.com> In-Reply-To: <77ead0ec0802181110x23ed95e7p2cb22ca8db66a387@mail.gmail.com> Authentication-Results: sj-dkim-2; header.From=lhnguyen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Vishwas, Yes, vision is getting more blurry at my age :-) But back to this link local signaling, the other packet types we are talking about are LS update/ack/req. Do you really think we would need to provide additional unique header information for these (BTW, we have none today)? I understand the extensibility angle, but it doesn't seem warranted in this case. We may have to agree to differ. Thanks, Liem Vishwas Manral wrote: > Hi Liem, > > I would say its a difference of vision of where we see LLS heading to > between us. However in my view if we allow the functionality, we do > not create any new issues (besides of course any security issues which > may result), however extending this in the future would create issues > in the future. > > Thanks, > Vishwas > > On Feb 18, 2008 11:05 AM, Liem Nguyen wrote: > >> Hi Vishwas, >> >> >> Vishwas Manral wrote: >> >>> Hi Liem, >>> >>> Like I gave the example of Opaque LSA's where we created an Opaque >>> mechanism which could be used for all packets, I envision that the LLS >>> would be a general mechanism to add additional information to the OSPF >>> header, just like Opaque LSA's allowed further information exchanged. >>> >>> >> Thanks for the comments. >> True, for Opaque. But given that this is a link-local signaling >> mechanism, I don't foresee a need >> where additional information can't be conveyed with either Hello or DBD >> packets. >> >> Liem >> >> >> > > _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Feb 18 11:58:08 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14CBE28C3D2; Mon, 18 Feb 2008 11:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 t073Dz1QO3bO; Mon, 18 Feb 2008 11:58:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF08A28C542; Mon, 18 Feb 2008 11:57:59 -0800 (PST) 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 34BA228C539 for ; Mon, 18 Feb 2008 11:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 jOs+X+Aa9h69 for ; Mon, 18 Feb 2008 11:57:57 -0800 (PST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by core3.amsl.com (Postfix) with ESMTP id 4FABE28C47C for ; Mon, 18 Feb 2008 11:57:52 -0800 (PST) Received: by wr-out-0506.google.com with SMTP id 50so2239132wri.25 for ; Mon, 18 Feb 2008 11:57:49 -0800 (PST) Received: by 10.142.171.6 with SMTP id t6mr4666195wfe.150.1203364668884; Mon, 18 Feb 2008 11:57:48 -0800 (PST) Received: by 10.143.164.14 with HTTP; Mon, 18 Feb 2008 11:57:48 -0800 (PST) Message-ID: <77ead0ec0802181157u2a36271dy794bb32e8ea1b495@mail.gmail.com> Date: Mon, 18 Feb 2008 11:57:48 -0800 From: "Vishwas Manral" To: "Abhay Roy" , "Liem Nguyen" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Abhay/ Leim, > > I like the generic mechanism talked about in the document. I however > > think the document does not describe how to treat TLV's if a TLV is > > not understood. If you see all other newer specs for example RFC5036 > > for LDP, you will notice they have the first 2 bits defining how to > > treat a packet if there is an unknown TLV. I would think now that we have defined TLV's, we could add information like first bit telling what to do with the packet (LLS part of the packet) if the TLV is not . I just noticed a draft in ISIS today (Multi Instance), which is using a different set of addresses because there is no way in the TLV to signal that in case you do not understand it drop the packet (and in case of the wrong packet being communicated there will be issues). If we had just had the bits in the TLV properly used in IS-IS we could have a simple addition to make the thing work in all cases. It doesnt spoil anything to do some work which may not create a problem for now, but may be helpful in the future. There are however other issues in IS-IS as the TLV type and length fields are heavily constrained. Thanks, Vishwas > Looking at some previous TLV usage in OSPF specs (e.g. > rfc3630), I think all we need to add is "Unrecognized TLV > types are ignored." I will add this text in section 2.3. > > > The document says the block can only be attached to Hello and DD > > packets, I would prefer the signaling to be able to be attached to any > > packets. Thus making OSPF packets truly extensible. > > Initially we only wanted it in Hello packets. But then we > found some use case for DD packets (rfc 4812). Sending LLS > with any packet type is technically feasible, but would > require separate documentation when such a need arises. I > would prefer to not include it in here at this time, since > there is no known use case. > > > The document talks about not doing a checksum if the Crytographic > > security is present. I think it enhances security as well as > > simplifies code if we calculate the checksum in all cases. Also the > > document seems to think that MD5 is the only cryptographic > > authentication method present and explicitly mentions it. The same > > needs to be removed. Infact if we hear the view on MD5 it is closer > > to: > > > > * Use of MD5, ciphers with a strength of 56 bits or less should be > > avoided in almost all circumstances. Use of ciphers with key sizes of > > 64 bits or less should be discontinued as soon as is practicable. > > I will remove direct references to MD5, so that it's equally > applicable to any available cryptographic authentication. > > > quoting from a mail in the SAAG list. > > > > Also as routers that do not understand LLS may receive the packets, we > > have to make sure to state that we need to take care changes made due > > to LLS block TLV's do not affect the basic routing when interacting > > with non-LLS routers. This will be a helpful guidance for any future > > extensions to LLS TLV's. > > Sure, I will add something to this effect.. > > Regards, > -Abhay > > > > > Thanks, > > Vishwas > > > > On Fri, Feb 15, 2008 at 9:15 AM, Acee Lindem wrote: > >> This starts the WG last call for the subject document. The target > >> status is Proposed Standard. > >> The WG last call will begin today and will end March 1st, 2008 at > >> 12:00 AM EST. Note that a previous revision (not including OSPFv3) of > >> this protocol extension was published as an experimental RFC 4813. > >> > >> Thanks, > >> Acee > >> _______________________________________________ > >> OSPF mailing list > >> OSPF@ietf.org > >> http://www.ietf.org/mailman/listinfo/ospf > >> > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > http://www.ietf.org/mailman/listinfo/ospf > > > _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Feb 18 12:12:24 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E45928C4A1; Mon, 18 Feb 2008 12:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[AWL=-1.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 w1PMG9ZfYxpi; Mon, 18 Feb 2008 12:12:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9152928C551; Mon, 18 Feb 2008 12:12:17 -0800 (PST) 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 9FBCC28C535 for ; Mon, 18 Feb 2008 12:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 jPeGWPNaqnJ7 for ; Mon, 18 Feb 2008 12:12:15 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id F15C03A68A6 for ; Mon, 18 Feb 2008 12:12:14 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 18 Feb 2008 12:12:13 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1IKCDx8031123; Mon, 18 Feb 2008 12:12:13 -0800 Received: from akr-lnx (akr-lnx.cisco.com [171.71.54.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1IKCCvo029724; Mon, 18 Feb 2008 20:12:12 GMT Date: Mon, 18 Feb 2008 12:12:12 -0800 (PST) From: Abhay Roy To: Vishwas Manral In-Reply-To: <77ead0ec0802181157u2a36271dy794bb32e8ea1b495@mail.gmail.com> Message-ID: References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> <77ead0ec0802181157u2a36271dy794bb32e8ea1b495@mail.gmail.com> MIME-Version: 1.0 Authentication-Results: sj-dkim-2; header.From=akr@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org On 02/18/08-0800 at 11:57am, Vishwas Manral writes: > Hi Abhay/ Leim, > >>> I like the generic mechanism talked about in the document. I however >>> think the document does not describe how to treat TLV's if a TLV is >>> not understood. If you see all other newer specs for example RFC5036 >>> for LDP, you will notice they have the first 2 bits defining how to >>> treat a packet if there is an unknown TLV. > I would think now that we have defined TLV's, we could add information > like first bit telling what to do with the packet (LLS part of the > packet) if the TLV is not . Hmm.. TLV having bits on what to do with the packet? Given that LLS is optional, I am afraid, it can't be used to have policies which end up dropping the packet. So I think we are OK with just adding the verbiage about ignoring unknown TLVs. > I just noticed a draft in ISIS today (Multi Instance), which is using > a different set of addresses because there is no way in the TLV to > signal that in case you do not understand it drop the packet (and in > case of the wrong packet being communicated there will be issues). ISIS is trying to add Instance ID's like OSPFv3 has. And since it didn't have it from day one in the base packet header, we came up with the IID TLV solution. Regards, -Abhay > If we had just had the bits in the TLV properly used in > IS-IS we could have a simple addition to make the thing > work in all cases. It doesnt spoil anything to do some > work which may not create a problem for now, but may be > helpful in the future. > > There are however other issues in IS-IS as the TLV type > and length fields are heavily constrained. > > Thanks, > Vishwas > >> Looking at some previous TLV usage in OSPF specs (e.g. >> rfc3630), I think all we need to add is "Unrecognized TLV >> types are ignored." I will add this text in section 2.3. >> >>> The document says the block can only be attached to Hello and DD >>> packets, I would prefer the signaling to be able to be attached to any >>> packets. Thus making OSPF packets truly extensible. >> >> Initially we only wanted it in Hello packets. But then we >> found some use case for DD packets (rfc 4812). Sending LLS >> with any packet type is technically feasible, but would >> require separate documentation when such a need arises. I >> would prefer to not include it in here at this time, since >> there is no known use case. >> >>> The document talks about not doing a checksum if the Crytographic >>> security is present. I think it enhances security as well as >>> simplifies code if we calculate the checksum in all cases. Also the >>> document seems to think that MD5 is the only cryptographic >>> authentication method present and explicitly mentions it. The same >>> needs to be removed. Infact if we hear the view on MD5 it is closer >>> to: >>> >>> * Use of MD5, ciphers with a strength of 56 bits or less should be >>> avoided in almost all circumstances. Use of ciphers with key sizes of >>> 64 bits or less should be discontinued as soon as is practicable. >> >> I will remove direct references to MD5, so that it's equally >> applicable to any available cryptographic authentication. >> >>> quoting from a mail in the SAAG list. >>> >>> Also as routers that do not understand LLS may receive the packets, we >>> have to make sure to state that we need to take care changes made due >>> to LLS block TLV's do not affect the basic routing when interacting >>> with non-LLS routers. This will be a helpful guidance for any future >>> extensions to LLS TLV's. >> >> Sure, I will add something to this effect.. >> >> Regards, >> -Abhay >> >> >> >>> Thanks, >>> Vishwas >>> >>> On Fri, Feb 15, 2008 at 9:15 AM, Acee Lindem wrote: >>>> This starts the WG last call for the subject document. The target >>>> status is Proposed Standard. >>>> The WG last call will begin today and will end March 1st, 2008 at >>>> 12:00 AM EST. Note that a previous revision (not including OSPFv3) of >>>> this protocol extension was published as an experimental RFC 4813. >>>> >>>> Thanks, >>>> Acee >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> http://www.ietf.org/mailman/listinfo/ospf >>>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> http://www.ietf.org/mailman/listinfo/ospf >>> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Feb 18 12:18:23 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A04C28C57E; Mon, 18 Feb 2008 12:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 UYnVScdH5T6h; Mon, 18 Feb 2008 12:18:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE43928C542; Mon, 18 Feb 2008 12:18:10 -0800 (PST) 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 A1E8328C520 for ; Mon, 18 Feb 2008 12:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 QcLQUdQxl+GM for ; Mon, 18 Feb 2008 12:18:07 -0800 (PST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by core3.amsl.com (Postfix) with ESMTP id C85383A6D6E for ; Mon, 18 Feb 2008 12:17:56 -0800 (PST) Received: by wr-out-0506.google.com with SMTP id 50so2255522wri.25 for ; Mon, 18 Feb 2008 12:17:53 -0800 (PST) Received: by 10.142.12.14 with SMTP id 14mr4678578wfl.152.1203365872891; Mon, 18 Feb 2008 12:17:52 -0800 (PST) Received: by 10.143.164.14 with HTTP; Mon, 18 Feb 2008 12:17:52 -0800 (PST) Message-ID: <77ead0ec0802181217r207ebee4i8160189bc18af2d@mail.gmail.com> Date: Mon, 18 Feb 2008 12:17:52 -0800 From: "Vishwas Manral" To: "Abhay Roy" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> <77ead0ec0802181157u2a36271dy794bb32e8ea1b495@mail.gmail.com> Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Abhay, Yes, LLS is optional. However we can ask for behaviors like do not look at the LLS packet itself if you do not recognize the TLV and we will have optional behavior, by just using 1 bit (which anyway may not have been used). > ISIS is trying to add Instance ID's like OSPFv3 has. And > since it didn't have it from day one in the base packet > header, we came up with the IID TLV solution. Correct and they had to take the drastic measure of using a different address. If they again have another feature where they do not want connections to be formed for a particular TLV they will need another address again. If they had just had a bit in the TLV to say, do not look at the packet/ ignore the TLV if the TLV is unrecognized, the behavior would just be adding a new TLV. This is very normal in most new protocols - check the LDP RFC5036. Note that not much changes for current implementations as such. Thanks, Vishwas On Feb 18, 2008 12:12 PM, Abhay Roy wrote: > On 02/18/08-0800 at 11:57am, Vishwas Manral writes: > > > Hi Abhay/ Leim, > > > >>> I like the generic mechanism talked about in the document. I however > >>> think the document does not describe how to treat TLV's if a TLV is > >>> not understood. If you see all other newer specs for example RFC5036 > >>> for LDP, you will notice they have the first 2 bits defining how to > >>> treat a packet if there is an unknown TLV. > > I would think now that we have defined TLV's, we could add information > > like first bit telling what to do with the packet (LLS part of the > > packet) if the TLV is not . > > Hmm.. TLV having bits on what to do with the packet? Given > that LLS is optional, I am afraid, it can't be used to have > policies which end up dropping the packet. > > So I think we are OK with just adding the verbiage about > ignoring unknown TLVs. > > > I just noticed a draft in ISIS today (Multi Instance), which is using > > a different set of addresses because there is no way in the TLV to > > signal that in case you do not understand it drop the packet (and in > > case of the wrong packet being communicated there will be issues). > > ISIS is trying to add Instance ID's like OSPFv3 has. And > since it didn't have it from day one in the base packet > header, we came up with the IID TLV solution. > > Regards, > -Abhay > > > > If we had just had the bits in the TLV properly used in > > IS-IS we could have a simple addition to make the thing > > work in all cases. It doesnt spoil anything to do some > > work which may not create a problem for now, but may be > > helpful in the future. > > > > There are however other issues in IS-IS as the TLV type > > and length fields are heavily constrained. > > > > Thanks, > > Vishwas > > > >> Looking at some previous TLV usage in OSPF specs (e.g. > >> rfc3630), I think all we need to add is "Unrecognized TLV > >> types are ignored." I will add this text in section 2.3. > >> > >>> The document says the block can only be attached to Hello and DD > >>> packets, I would prefer the signaling to be able to be attached to any > >>> packets. Thus making OSPF packets truly extensible. > >> > >> Initially we only wanted it in Hello packets. But then we > >> found some use case for DD packets (rfc 4812). Sending LLS > >> with any packet type is technically feasible, but would > >> require separate documentation when such a need arises. I > >> would prefer to not include it in here at this time, since > >> there is no known use case. > >> > >>> The document talks about not doing a checksum if the Crytographic > >>> security is present. I think it enhances security as well as > >>> simplifies code if we calculate the checksum in all cases. Also the > >>> document seems to think that MD5 is the only cryptographic > >>> authentication method present and explicitly mentions it. The same > >>> needs to be removed. Infact if we hear the view on MD5 it is closer > >>> to: > >>> > >>> * Use of MD5, ciphers with a strength of 56 bits or less should be > >>> avoided in almost all circumstances. Use of ciphers with key sizes of > >>> 64 bits or less should be discontinued as soon as is practicable. > >> > >> I will remove direct references to MD5, so that it's equally > >> applicable to any available cryptographic authentication. > >> > >>> quoting from a mail in the SAAG list. > >>> > >>> Also as routers that do not understand LLS may receive the packets, we > >>> have to make sure to state that we need to take care changes made due > >>> to LLS block TLV's do not affect the basic routing when interacting > >>> with non-LLS routers. This will be a helpful guidance for any future > >>> extensions to LLS TLV's. > >> > >> Sure, I will add something to this effect.. > >> > >> Regards, > >> -Abhay > >> > >> > >> > >>> Thanks, > >>> Vishwas > >>> > >>> On Fri, Feb 15, 2008 at 9:15 AM, Acee Lindem wrote: > >>>> This starts the WG last call for the subject document. The target > >>>> status is Proposed Standard. > >>>> The WG last call will begin today and will end March 1st, 2008 at > >>>> 12:00 AM EST. Note that a previous revision (not including OSPFv3) of > >>>> this protocol extension was published as an experimental RFC 4813. > >>>> > >>>> Thanks, > >>>> Acee > >>>> _______________________________________________ > >>>> OSPF mailing list > >>>> OSPF@ietf.org > >>>> http://www.ietf.org/mailman/listinfo/ospf > >>>> > >>> _______________________________________________ > >>> OSPF mailing list > >>> OSPF@ietf.org > >>> http://www.ietf.org/mailman/listinfo/ospf > >>> > >> > > > _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Feb 18 13:07:51 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC23428C571; Mon, 18 Feb 2008 13:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=-1.172, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 E4Bp5NxIbczu; Mon, 18 Feb 2008 13:07:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7319D3A6D5F; Mon, 18 Feb 2008 13:07:49 -0800 (PST) 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 A1CCC28C32B for ; Mon, 18 Feb 2008 13:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 Cuuq0xjOeNn2 for ; Mon, 18 Feb 2008 13:07:47 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6D70328C489 for ; Mon, 18 Feb 2008 13:07:46 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 18 Feb 2008 13:07:44 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1IL7iOc014536; Mon, 18 Feb 2008 13:07:44 -0800 Received: from akr-lnx (akr-lnx.cisco.com [171.71.54.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1IL7gvo011020; Mon, 18 Feb 2008 21:07:42 GMT Date: Mon, 18 Feb 2008 13:07:42 -0800 (PST) From: Abhay Roy To: Vishwas Manral In-Reply-To: <77ead0ec0802181217r207ebee4i8160189bc18af2d@mail.gmail.com> Message-ID: References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> <77ead0ec0802181157u2a36271dy794bb32e8ea1b495@mail.gmail.com> <77ead0ec0802181217r207ebee4i8160189bc18af2d@mail.gmail.com> MIME-Version: 1.0 Authentication-Results: sj-dkim-1; header.From=akr@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Vishwas, I am having hard time understanding the use case when one of the "new" TLVs someone invents will ask all receivers to stop process all the "old" TLVs. I propose we wait for such innovations to come down the line v/s try to sneak something in here at last call.. Also, lets take the ISIS discussion to isis working group.. Regards, -Abhay On 02/18/08-0800 at 12:17pm, Vishwas Manral writes: > Hi Abhay, > > Yes, LLS is optional. However we can ask for behaviors like do not > look at the LLS packet itself if you do not recognize the TLV and we > will have optional behavior, by just using 1 bit (which anyway may not > have been used). > >> ISIS is trying to add Instance ID's like OSPFv3 has. And >> since it didn't have it from day one in the base packet >> header, we came up with the IID TLV solution. > Correct and they had to take the drastic measure of using a different > address. If they again have another feature where they do not want > connections to be formed for a particular TLV they will need another > address again. If they had just had a bit in the TLV to say, do not > look at the packet/ ignore the TLV if the TLV is unrecognized, the > behavior would just be adding a new TLV. This is very normal in most > new protocols - check the LDP RFC5036. Note that not much changes for > current implementations as such. > > Thanks, > Vishwas > > On Feb 18, 2008 12:12 PM, Abhay Roy wrote: >> On 02/18/08-0800 at 11:57am, Vishwas Manral writes: >> >>> Hi Abhay/ Leim, >>> >>>>> I like the generic mechanism talked about in the document. I however >>>>> think the document does not describe how to treat TLV's if a TLV is >>>>> not understood. If you see all other newer specs for example RFC5036 >>>>> for LDP, you will notice they have the first 2 bits defining how to >>>>> treat a packet if there is an unknown TLV. >>> I would think now that we have defined TLV's, we could add information >>> like first bit telling what to do with the packet (LLS part of the >>> packet) if the TLV is not . >> >> Hmm.. TLV having bits on what to do with the packet? Given >> that LLS is optional, I am afraid, it can't be used to have >> policies which end up dropping the packet. >> >> So I think we are OK with just adding the verbiage about >> ignoring unknown TLVs. >> >>> I just noticed a draft in ISIS today (Multi Instance), which is using >>> a different set of addresses because there is no way in the TLV to >>> signal that in case you do not understand it drop the packet (and in >>> case of the wrong packet being communicated there will be issues). >> >> ISIS is trying to add Instance ID's like OSPFv3 has. And >> since it didn't have it from day one in the base packet >> header, we came up with the IID TLV solution. >> >> Regards, >> -Abhay >> >> >>> If we had just had the bits in the TLV properly used in >>> IS-IS we could have a simple addition to make the thing >>> work in all cases. It doesnt spoil anything to do some >>> work which may not create a problem for now, but may be >>> helpful in the future. >>> >>> There are however other issues in IS-IS as the TLV type >>> and length fields are heavily constrained. >>> >>> Thanks, >>> Vishwas >>> >>>> Looking at some previous TLV usage in OSPF specs (e.g. >>>> rfc3630), I think all we need to add is "Unrecognized TLV >>>> types are ignored." I will add this text in section 2.3. >>>> >>>>> The document says the block can only be attached to Hello and DD >>>>> packets, I would prefer the signaling to be able to be attached to any >>>>> packets. Thus making OSPF packets truly extensible. >>>> >>>> Initially we only wanted it in Hello packets. But then we >>>> found some use case for DD packets (rfc 4812). Sending LLS >>>> with any packet type is technically feasible, but would >>>> require separate documentation when such a need arises. I >>>> would prefer to not include it in here at this time, since >>>> there is no known use case. >>>> >>>>> The document talks about not doing a checksum if the Crytographic >>>>> security is present. I think it enhances security as well as >>>>> simplifies code if we calculate the checksum in all cases. Also the >>>>> document seems to think that MD5 is the only cryptographic >>>>> authentication method present and explicitly mentions it. The same >>>>> needs to be removed. Infact if we hear the view on MD5 it is closer >>>>> to: >>>>> >>>>> * Use of MD5, ciphers with a strength of 56 bits or less should be >>>>> avoided in almost all circumstances. Use of ciphers with key sizes of >>>>> 64 bits or less should be discontinued as soon as is practicable. >>>> >>>> I will remove direct references to MD5, so that it's equally >>>> applicable to any available cryptographic authentication. >>>> >>>>> quoting from a mail in the SAAG list. >>>>> >>>>> Also as routers that do not understand LLS may receive the packets, we >>>>> have to make sure to state that we need to take care changes made due >>>>> to LLS block TLV's do not affect the basic routing when interacting >>>>> with non-LLS routers. This will be a helpful guidance for any future >>>>> extensions to LLS TLV's. >>>> >>>> Sure, I will add something to this effect.. >>>> >>>> Regards, >>>> -Abhay >>>> >>>> >>>> >>>>> Thanks, >>>>> Vishwas >>>>> >>>>> On Fri, Feb 15, 2008 at 9:15 AM, Acee Lindem wrote: >>>>>> This starts the WG last call for the subject document. The target >>>>>> status is Proposed Standard. >>>>>> The WG last call will begin today and will end March 1st, 2008 at >>>>>> 12:00 AM EST. Note that a previous revision (not including OSPFv3) of >>>>>> this protocol extension was published as an experimental RFC 4813. >>>>>> >>>>>> Thanks, >>>>>> Acee >>>>>> _______________________________________________ >>>>>> OSPF mailing list >>>>>> OSPF@ietf.org >>>>>> http://www.ietf.org/mailman/listinfo/ospf >>>>>> >>>>> _______________________________________________ >>>>> OSPF mailing list >>>>> OSPF@ietf.org >>>>> http://www.ietf.org/mailman/listinfo/ospf >>>>> >>>> >>> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Feb 18 13:41:08 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44AFF28C4FF; Mon, 18 Feb 2008 13:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.686 X-Spam-Level: X-Spam-Status: No, score=-0.686 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 LVmpxfyjljj7; Mon, 18 Feb 2008 13:41:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E788C28C3BE; Mon, 18 Feb 2008 13:41:06 -0800 (PST) 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 D27B228C364 for ; Mon, 18 Feb 2008 13:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 V9qUYdjKb0SS for ; Mon, 18 Feb 2008 13:41:04 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.176]) by core3.amsl.com (Postfix) with ESMTP id D9F233A6D98 for ; Mon, 18 Feb 2008 13:41:02 -0800 (PST) Received: by el-out-1112.google.com with SMTP id j27so1312491elf.25 for ; Mon, 18 Feb 2008 13:40:56 -0800 (PST) Received: by 10.142.128.6 with SMTP id a6mr4751573wfd.138.1203370856043; Mon, 18 Feb 2008 13:40:56 -0800 (PST) Received: by 10.143.164.14 with HTTP; Mon, 18 Feb 2008 13:40:55 -0800 (PST) Message-ID: <77ead0ec0802181340s1b34822bk213b3537e1eb87fa@mail.gmail.com> Date: Mon, 18 Feb 2008 13:40:55 -0800 From: "Vishwas Manral" To: "Abhay Roy" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> <77ead0ec0802181157u2a36271dy794bb32e8ea1b495@mail.gmail.com> <77ead0ec0802181217r207ebee4i8160189bc18af2d@mail.gmail.com> Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Abhay, The IS-IS talk was just to learn lessons in OSPf from other protocols which in this case is IS-IS. Thanks, Vishwas On Feb 18, 2008 1:07 PM, Abhay Roy wrote: > Hi Vishwas, > > I am having hard time understanding the use case when one of > the "new" TLVs someone invents will ask all receivers to > stop process all the "old" TLVs. I propose we wait for > such innovations to come down the line v/s try to sneak > something in here at last call.. > > Also, lets take the ISIS discussion to isis working group.. > > Regards, > -Abhay > > > On 02/18/08-0800 at 12:17pm, Vishwas Manral writes: > > > Hi Abhay, > > > > Yes, LLS is optional. However we can ask for behaviors like do not > > look at the LLS packet itself if you do not recognize the TLV and we > > will have optional behavior, by just using 1 bit (which anyway may not > > have been used). > > > >> ISIS is trying to add Instance ID's like OSPFv3 has. And > >> since it didn't have it from day one in the base packet > >> header, we came up with the IID TLV solution. > > Correct and they had to take the drastic measure of using a different > > address. If they again have another feature where they do not want > > connections to be formed for a particular TLV they will need another > > address again. If they had just had a bit in the TLV to say, do not > > look at the packet/ ignore the TLV if the TLV is unrecognized, the > > behavior would just be adding a new TLV. This is very normal in most > > new protocols - check the LDP RFC5036. Note that not much changes for > > current implementations as such. > > > > Thanks, > > Vishwas > > > > On Feb 18, 2008 12:12 PM, Abhay Roy wrote: > >> On 02/18/08-0800 at 11:57am, Vishwas Manral writes: > >> > >>> Hi Abhay/ Leim, > >>> > >>>>> I like the generic mechanism talked about in the document. I however > >>>>> think the document does not describe how to treat TLV's if a TLV is > >>>>> not understood. If you see all other newer specs for example RFC5036 > >>>>> for LDP, you will notice they have the first 2 bits defining how to > >>>>> treat a packet if there is an unknown TLV. > >>> I would think now that we have defined TLV's, we could add information > >>> like first bit telling what to do with the packet (LLS part of the > >>> packet) if the TLV is not . > >> > >> Hmm.. TLV having bits on what to do with the packet? Given > >> that LLS is optional, I am afraid, it can't be used to have > >> policies which end up dropping the packet. > >> > >> So I think we are OK with just adding the verbiage about > >> ignoring unknown TLVs. > >> > >>> I just noticed a draft in ISIS today (Multi Instance), which is using > >>> a different set of addresses because there is no way in the TLV to > >>> signal that in case you do not understand it drop the packet (and in > >>> case of the wrong packet being communicated there will be issues). > >> > >> ISIS is trying to add Instance ID's like OSPFv3 has. And > >> since it didn't have it from day one in the base packet > >> header, we came up with the IID TLV solution. > >> > >> Regards, > >> -Abhay > >> > >> > >>> If we had just had the bits in the TLV properly used in > >>> IS-IS we could have a simple addition to make the thing > >>> work in all cases. It doesnt spoil anything to do some > >>> work which may not create a problem for now, but may be > >>> helpful in the future. > >>> > >>> There are however other issues in IS-IS as the TLV type > >>> and length fields are heavily constrained. > >>> > >>> Thanks, > >>> Vishwas > >>> > >>>> Looking at some previous TLV usage in OSPF specs (e.g. > >>>> rfc3630), I think all we need to add is "Unrecognized TLV > >>>> types are ignored." I will add this text in section 2.3. > >>>> > >>>>> The document says the block can only be attached to Hello and DD > >>>>> packets, I would prefer the signaling to be able to be attached to any > >>>>> packets. Thus making OSPF packets truly extensible. > >>>> > >>>> Initially we only wanted it in Hello packets. But then we > >>>> found some use case for DD packets (rfc 4812). Sending LLS > >>>> with any packet type is technically feasible, but would > >>>> require separate documentation when such a need arises. I > >>>> would prefer to not include it in here at this time, since > >>>> there is no known use case. > >>>> > >>>>> The document talks about not doing a checksum if the Crytographic > >>>>> security is present. I think it enhances security as well as > >>>>> simplifies code if we calculate the checksum in all cases. Also the > >>>>> document seems to think that MD5 is the only cryptographic > >>>>> authentication method present and explicitly mentions it. The same > >>>>> needs to be removed. Infact if we hear the view on MD5 it is closer > >>>>> to: > >>>>> > >>>>> * Use of MD5, ciphers with a strength of 56 bits or less should be > >>>>> avoided in almost all circumstances. Use of ciphers with key sizes of > >>>>> 64 bits or less should be discontinued as soon as is practicable. > >>>> > >>>> I will remove direct references to MD5, so that it's equally > >>>> applicable to any available cryptographic authentication. > >>>> > >>>>> quoting from a mail in the SAAG list. > >>>>> > >>>>> Also as routers that do not understand LLS may receive the packets, we > >>>>> have to make sure to state that we need to take care changes made due > >>>>> to LLS block TLV's do not affect the basic routing when interacting > >>>>> with non-LLS routers. This will be a helpful guidance for any future > >>>>> extensions to LLS TLV's. > >>>> > >>>> Sure, I will add something to this effect.. > >>>> > >>>> Regards, > >>>> -Abhay > >>>> > >>>> > >>>> > >>>>> Thanks, > >>>>> Vishwas > >>>>> > >>>>> On Fri, Feb 15, 2008 at 9:15 AM, Acee Lindem wrote: > >>>>>> This starts the WG last call for the subject document. The target > >>>>>> status is Proposed Standard. > >>>>>> The WG last call will begin today and will end March 1st, 2008 at > >>>>>> 12:00 AM EST. Note that a previous revision (not including OSPFv3) of > >>>>>> this protocol extension was published as an experimental RFC 4813. > >>>>>> > >>>>>> Thanks, > >>>>>> Acee > >>>>>> _______________________________________________ > >>>>>> OSPF mailing list > >>>>>> OSPF@ietf.org > >>>>>> http://www.ietf.org/mailman/listinfo/ospf > >>>>>> > >>>>> _______________________________________________ > >>>>> OSPF mailing list > >>>>> OSPF@ietf.org > >>>>> http://www.ietf.org/mailman/listinfo/ospf > >>>>> > >>>> > >>> > >> > > > _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Feb 19 10:29:45 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E35428C64E; Tue, 19 Feb 2008 10:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 x5LiK8jfabrr; Tue, 19 Feb 2008 10:29:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE833A6B1A; Tue, 19 Feb 2008 10:29:44 -0800 (PST) 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 7D8363A68D3 for ; Tue, 19 Feb 2008 10:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 zjjHajCFo8pF for ; Tue, 19 Feb 2008 10:29:42 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 7E4D53A6B1A for ; Tue, 19 Feb 2008 10:29:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 9D059C36027; Tue, 19 Feb 2008 10:29:39 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31145-10; Tue, 19 Feb 2008 10:29:39 -0800 (PST) Received: from [r???????p??`?6?$IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id BB8C0C36025; Tue, 19 Feb 2008 10:29:37 -0800 (PST) In-Reply-To: References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> <77ead0ec0802181157u2a36271dy794bb32e8ea1b495@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <046209EC-E485-4488-B526-77EEBAF33848@redback.com> From: Acee Lindem Date: Tue, 19 Feb 2008 13:29:36 -0500 To: Abhay Roy X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org I agree. Acee On Feb 18, 2008, at 3:12 PM, Abhay Roy wrote: > On 02/18/08-0800 at 11:57am, Vishwas Manral writes: > >> Hi Abhay/ Leim, >> >>>> I like the generic mechanism talked about in the document. I >>>> however >>>> think the document does not describe how to treat TLV's if a TLV is >>>> not understood. If you see all other newer specs for example >>>> RFC5036 >>>> for LDP, you will notice they have the first 2 bits defining how to >>>> treat a packet if there is an unknown TLV. >> I would think now that we have defined TLV's, we could add >> information >> like first bit telling what to do with the packet (LLS part of the >> packet) if the TLV is not . > > Hmm.. TLV having bits on what to do with the packet? Given > that LLS is optional, I am afraid, it can't be used to have > policies which end up dropping the packet. > > So I think we are OK with just adding the verbiage about > ignoring unknown TLVs. > >> I just noticed a draft in ISIS today (Multi Instance), which is using >> a different set of addresses because there is no way in the TLV to >> signal that in case you do not understand it drop the packet (and in >> case of the wrong packet being communicated there will be issues). > > ISIS is trying to add Instance ID's like OSPFv3 has. And > since it didn't have it from day one in the base packet > header, we came up with the IID TLV solution. > > Regards, > -Abhay > >> If we had just had the bits in the TLV properly used in >> IS-IS we could have a simple addition to make the thing >> work in all cases. It doesnt spoil anything to do some >> work which may not create a problem for now, but may be >> helpful in the future. >> >> There are however other issues in IS-IS as the TLV type >> and length fields are heavily constrained. >> >> Thanks, >> Vishwas >> >>> Looking at some previous TLV usage in OSPF specs (e.g. >>> rfc3630), I think all we need to add is "Unrecognized TLV >>> types are ignored." I will add this text in section 2.3. >>> >>>> The document says the block can only be attached to Hello and DD >>>> packets, I would prefer the signaling to be able to be attached >>>> to any >>>> packets. Thus making OSPF packets truly extensible. >>> >>> Initially we only wanted it in Hello packets. But then we >>> found some use case for DD packets (rfc 4812). Sending LLS >>> with any packet type is technically feasible, but would >>> require separate documentation when such a need arises. I >>> would prefer to not include it in here at this time, since >>> there is no known use case. >>> >>>> The document talks about not doing a checksum if the Crytographic >>>> security is present. I think it enhances security as well as >>>> simplifies code if we calculate the checksum in all cases. Also the >>>> document seems to think that MD5 is the only cryptographic >>>> authentication method present and explicitly mentions it. The same >>>> needs to be removed. Infact if we hear the view on MD5 it is closer >>>> to: >>>> >>>> * Use of MD5, ciphers with a strength of 56 bits or less should be >>>> avoided in almost all circumstances. Use of ciphers with key >>>> sizes of >>>> 64 bits or less should be discontinued as soon as is practicable. >>> >>> I will remove direct references to MD5, so that it's equally >>> applicable to any available cryptographic authentication. >>> >>>> quoting from a mail in the SAAG list. >>>> >>>> Also as routers that do not understand LLS may receive the >>>> packets, we >>>> have to make sure to state that we need to take care changes >>>> made due >>>> to LLS block TLV's do not affect the basic routing when interacting >>>> with non-LLS routers. This will be a helpful guidance for any >>>> future >>>> extensions to LLS TLV's. >>> >>> Sure, I will add something to this effect.. >>> >>> Regards, >>> -Abhay >>> >>> >>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Fri, Feb 15, 2008 at 9:15 AM, Acee Lindem >>>> wrote: >>>>> This starts the WG last call for the subject document. The target >>>>> status is Proposed Standard. >>>>> The WG last call will begin today and will end March 1st, 2008 at >>>>> 12:00 AM EST. Note that a previous revision (not including >>>>> OSPFv3) of >>>>> this protocol extension was published as an experimental RFC >>>>> 4813. >>>>> >>>>> Thanks, >>>>> Acee >>>>> _______________________________________________ >>>>> OSPF mailing list >>>>> OSPF@ietf.org >>>>> http://www.ietf.org/mailman/listinfo/ospf >>>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> http://www.ietf.org/mailman/listinfo/ospf >>>> >>> >> _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Feb 22 09:35:01 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB97928C334; Fri, 22 Feb 2008 09:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_31=0.6, 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 a3wxbyUoWGpx; Fri, 22 Feb 2008 09:35:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B085428C3BB; Fri, 22 Feb 2008 09:34:31 -0800 (PST) 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 5473428C334 for ; Fri, 22 Feb 2008 09:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 aTVK8hN4QA-t for ; Fri, 22 Feb 2008 09:34:28 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 764B828C7A6 for ; Fri, 22 Feb 2008 09:32:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UV+lhLkrfApvC7M7YJPnz1QdiV5NeyJH1/Ksj7S75XKfHFjMeRi4fKdynhiUie56; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.246.21.85] (helo=earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JSbkk-0003W6-9H; Fri, 22 Feb 2008 12:32:07 -0500 Message-ID: <47BF0851.C6C736D5@earthlink.net> Date: Fri, 22 Feb 2008 09:37:21 -0800 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Vincent Nogues References: <010a01c8755a$9a4d6910$0602320a@ouest.teamlog.intra> X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79705e0b402cc310c92c467c27b2e8ac36350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.21.85 Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF scalability 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: , Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Vincent Nogues, This email is intended to be vender neutral discussions wrt OSPF. IMO, if the more dynamic links are separated and associated with one or more separate areas, then convergence time should improve and the amount of CPU resources should decrease. I do not have a rule of thumb on the number of routers in an area, but without BMA type links, this number seems excessive for a single area. Mitchell Erblich ------------------ > Vincent Nogues wrote: > = > Dears, > = > = > = > I have a network made up 180 Cisco routers (3825 series). They are > meshed with about 300 links. These links are quite heterogeneous in > terms of bandwidth (between 2Mb/s and 8Mb/s). The network is quite > dynamic, i.e. some links are regularly added or removed. There are > also about 500 external routes injected in this network. The routers > implement the following services: access-list and route-map, QoS and > shaping, dot1Q encapsulation, 4 OSPF processes, BGP, SNMP. > = > = > = > My questions are: > = > =FC Is it recommended to integrate these 180 routers in a single > OSPF area (area 0.0.0.0)? > = > =FC Have someone already experienced such an issue and do you know > if the 3825 routers are able to compute (in terms of CPU or memory) > all these OSPF routes in a reasonable time (i.e. Convergence time less > than 1 minute)? > = > = > = > I would like to know if my network will be reliable with such an > important number of routers in a single area. > = > = > = > Thanks in advance, > = > = > = > --------------------------------------------------- > = > Vincent NOGUES > = > --------------------------------------------------- > = > TEAMLOG > = > 12A, rue du P=E2tis Tatelin > = > 35700 RENNES > = > Standard : 02.99.12.71.71 > = > Fax : 02.99.12.71.72 > = > www.teamlog.com - vno@teamlog.com > = > --------------------------------------------------- > = > Ligne directe : 02.99.12.53.60 > = > --------------------------------------------------- > [Image] > = > ATTENTION : Ce message et toutes les pi=E8ces jointes (ci-apr=E8s le > "message") sont confidentiels et strictement r=E9serv=E9s aux > destinataires qui proc=E8deront aux v=E9rifications appropri=E9es en mati= =E8re > de virus. Toute utilisation ou diffusion non autoris=E9e est interdite. > Tout message =E9lectronique est susceptible d'alt=E9ration. L'auteur de ce > message et le Groupe TEAMLOG d=E9clinent toute responsabilit=E9 au titre > de ce message s'il a =E9t=E9 alt=E9r=E9, d=E9form=E9, falsifi=E9 ou ind= =FBment utilis=E9 > par des tiers, ou encore s'il a caus=E9 tout dommage ou perte de toute > nature. > Si vous n'=EAtes pas destinataire de ce message, merci de le d=E9truire > imm=E9diatement et d'avertir l'exp=E9diteur. > *********************************** > WARNING : This message and any attachments (the "message") are > confidential and strictly intended for their addressees, who will > conduct appropriate virus checks. Any unauthorised use or > dissemination is prohibited. > Messages are susceptible to alteration. The author of this message or > TEAMLOG Group shall not be liable for the message if altered, changed, > falsified or unduly used by third parties, or for any damage or loss. > If you are not receiver of this message, please cancel it immediately > and inform the sender. > = > = > = > --------------------------------------------------------------- > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > http://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Feb 25 08:16:36 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93AC228C5DD; Mon, 25 Feb 2008 08:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.415 X-Spam-Level: **** X-Spam-Status: No, score=4.415 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_31=0.6, MIME_HTML_MOSTLY=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 XzX5fL8kwi99; Mon, 25 Feb 2008 08:16:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B1C28C4FC; Mon, 25 Feb 2008 08:15:47 -0800 (PST) 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 D911D3A6A41 for ; Mon, 25 Feb 2008 08:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 RgesoQdtV971 for ; Mon, 25 Feb 2008 08:15:43 -0800 (PST) Received: from mail1-rennes1.teamlog.fr (smtp-rennes1.teamlog.com [194.206.222.69]) by core3.amsl.com (Postfix) with ESMTP id CE28428C60B for ; Mon, 25 Feb 2008 08:15:09 -0800 (PST) Received: from teamlog.com by paris.teamlog.com (x.x.x/x.x.x) with ESMTP id m1PGEs1T015428; Mon, 25 Feb 2008 17:14:55 +0100 From: "Vincent Nogues" To: "'Erblichs'" References: <010a01c8755a$9a4d6910$0602320a@ouest.teamlog.intra> <47BF0851.C6C736D5@earthlink.net> Date: Mon, 25 Feb 2008 17:16:25 +0100 Message-ID: <002401c877c9$c60a1320$1b02320a@ouest.teamlog.intra> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach1etM1jZkl6R6xQNSqI6zYlfg1qwCTkSuw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47BF0851.C6C736D5@earthlink.net> Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF scalability 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: , Content-Type: multipart/mixed; boundary="===============1729474313==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============1729474313== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C877D2.27CE7B20" This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C877D2.27CE7B20 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Dear, =20 Thank you for your answer.=20 =20 > This email is intended to be vender neutral discussions > wrt OSPF. IMO, if the more dynamic links are separated > and associated with one or more separate areas, then > convergence time should improve and the amount of CPU > resources should decrease. =20 =20 I agree with you that the separation of the dynamic links should improve = the performance.=20 =20 =20 > I do not have a rule of thumb on the number of routers > in an area, but without BMA type links, this number seems > excessive for a single area. =20 =20 What do you mean by < without BMA type links > ? =20 Thanks in advance Vincent NOGUES =20 =20 > Vincent Nogues wrote: >=20 > Dears, >=20 >=20 >=20 > I have a network made up 180 Cisco routers (3825 series). They are > meshed with about 300 links. These links are quite heterogeneous in > terms of bandwidth (between 2Mb/s and 8Mb/s). The network is quite > dynamic, i.e. some links are regularly added or removed. There are > also about 500 external routes injected in this network. The routers > implement the following services: access-list and route-map, QoS and > shaping, dot1Q encapsulation, 4 OSPF processes, BGP, SNMP. >=20 >=20 >=20 > My questions are: >=20 > =FC Is it recommended to integrate these 180 routers in a single > OSPF area (area 0.0.0.0)? >=20 > =FC Have someone already experienced such an issue and do you = know > if the 3825 routers are able to compute (in terms of CPU or memory) > all these OSPF routes in a reasonable time (i.e. Convergence time less > than 1 minute)? >=20 >=20 >=20 > I would like to know if my network will be reliable with such an > important number of routers in a single area. >=20 >=20 >=20 > Thanks in advance, >=20 >=20 >=20 > --------------------------------------------------- >=20 > Vincent NOGUES >=20 > --------------------------------------------------- >=20 > TEAMLOG >=20 > 12A, rue du P=E2tis Tatelin >=20 > 35700 RENNES >=20 > Standard : 02.99.12.71.71 >=20 > Fax : 02.99.12.71.72 >=20 > www.teamlog.com - vno@teamlog.com >=20 > --------------------------------------------------- >=20 > Ligne directe : 02.99.12.53.60 >=20 > --------------------------------------------------- > [Image] >=20 > ATTENTION : Ce message et toutes les pi=E8ces jointes (ci-apr=E8s le > "message") sont confidentiels et strictement r=E9serv=E9s aux > destinataires qui proc=E8deront aux v=E9rifications appropri=E9es en = mati=E8re > de virus. Toute utilisation ou diffusion non autoris=E9e est = interdite. > Tout message =E9lectronique est susceptible d'alt=E9ration. L'auteur = de ce > message et le Groupe TEAMLOG d=E9clinent toute responsabilit=E9 au = titre > de ce message s'il a =E9t=E9 alt=E9r=E9, d=E9form=E9, falsifi=E9 ou = ind=FBment utilis=E9 > par des tiers, ou encore s'il a caus=E9 tout dommage ou perte de toute > nature. > Si vous n'=EAtes pas destinataire de ce message, merci de le = d=E9truire > imm=E9diatement et d'avertir l'exp=E9diteur. > *********************************** > WARNING : This message and any attachments (the "message") are > confidential and strictly intended for their addressees, who will > conduct appropriate virus checks. Any unauthorised use or > dissemination is prohibited. > Messages are susceptible to alteration. The author of this message or > TEAMLOG Group shall not be liable for the message if altered, changed, > falsified or unduly used by third parties, or for any damage or loss. > If you are not receiver of this message, please cancel it immediately > and inform the sender. >=20 >=20 >=20 > --------------------------------------------------------------- > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > http://www.ietf.org/mailman/listinfo/ospf ------=_NextPart_000_0025_01C877D2.27CE7B20 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Dear,

Thank you for your answer.

> =A0=A0=A0=A0=A0=A0=A0=A0This email is intended to be vender = neutral discussions

>=A0=A0=A0=A0=A0=A0=A0=A0 wrt OSPF. IMO, if the more dynamic = links are separated

>=A0=A0=A0=A0=A0=A0=A0=A0 and associated with one or more = separate areas, then

>=A0=A0=A0=A0=A0=A0=A0=A0 convergence time should improve and = the amount of CPU

>=A0=A0=A0=A0=A0=A0=A0=A0 resources should = decrease.

I agree with you that the separation of the dynamic links should improve the performance.

>=A0=A0=A0=A0=A0=A0=A0=A0 I do not have a rule of thumb on = the number of routers

>=A0=A0=A0=A0=A0=A0=A0=A0 in an area, but without BMA type = links, this number seems

>=A0=A0=A0=A0=A0=A0=A0=A0 excessive for a single = area.

What do you mean by = « without BMA type links » ?

Thanks in = advance

Vincent = NOGUES

> Vincent Nogues wrote:

> Dears,

> I have a network made up 180 Cisco routers (3825 series). = They are

> meshed with about 300 links. These links are quite = heterogeneous in

> terms of bandwidth (between 2Mb/s and 8Mb/s). The network = is quite

> dynamic, i.e. some links are regularly added or removed. = There are

> also about 500 external routes injected in this network. = The routers

> implement the following services: access-list and = route-map, QoS and

> shaping, dot1Q encapsulation, 4 OSPF processes, BGP, = SNMP.

> My questions are:

> =FC=A0=A0=A0=A0=A0=A0 Is it recommended to integrate these = 180 routers in a single

> OSPF area (area 0.0.0.0)?

> =FC=A0=A0=A0=A0=A0=A0 Have someone already experienced such = an issue and do you know

> if the 3825 routers are able to compute (in terms of CPU or memory)

> all these OSPF routes in a reasonable time (i.e. = Convergence time less

> than 1 minute)?

> I would like to know if my network will be reliable with = such an

> important number of routers in a single = area.

> Thanks in advance,

> = ---------------------------------------------------

> Vincent NOGUES

> = ---------------------------------------------------

> TEAMLOG

> 12A, rue du P=E2tis Tatelin

> 35700 RENNES

> Standard : 02.99.12.71.71

> Fax : 02.99.12.71.72

> www.teamlog.com - = vno@teamlog.com

> = ---------------------------------------------------

> Ligne directe : 02.99.12.53.60

> = ---------------------------------------------------

> [Image]

> ATTENTION : Ce message et toutes les pi=E8ces jointes = (ci-apr=E8s le

> "message") sont confidentiels et strictement = r=E9serv=E9s aux

> destinataires qui proc=E8deront aux v=E9rifications = appropri=E9es en mati=E8re

> de virus. Toute utilisation ou diffusion non autoris=E9e = est interdite.

> Tout message =E9lectronique est susceptible d'alt=E9ration. = L'auteur de ce

> message et le Groupe TEAMLOG d=E9clinent toute = responsabilit=E9 au titre

> de ce message s'il a =E9t=E9 alt=E9r=E9, d=E9form=E9, = falsifi=E9 ou ind=FBment utilis=E9

> par des tiers, ou encore s'il a caus=E9 tout dommage ou = perte de toute

> nature.

> Si vous n'=EAtes pas destinataire de ce message, merci de = le d=E9truire

> imm=E9diatement et d'avertir = l'exp=E9diteur.

> = ***********************************

> WARNING : This message and any attachments (the "message") are

> confidential and strictly intended for their addressees, = who will

> conduct appropriate virus checks. Any unauthorised use = or

> dissemination is prohibited.

> Messages are susceptible to alteration. The author of this = message or

> TEAMLOG Group shall not be liable for the message if = altered, changed,

> falsified or unduly used by third parties, or for any = damage or loss.

> If you are not receiver of this message, please cancel it immediately

> and inform the sender.

>=A0=A0=A0=A0 ---------------------------------------------------------------

> = _______________________________________________<= /p>

> OSPF mailing list

> OSPF@ietf.org

> = http://www.ietf.org/mailman/listinfo/ospf

------=_NextPart_000_0025_01C877D2.27CE7B20-- --===============1729474313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf --===============1729474313==-- From ospf-bounces@ietf.org Mon Feb 25 16:48:53 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F0EC28CBD3; Mon, 25 Feb 2008 16:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 OqnBQFMgI-yS; Mon, 25 Feb 2008 16:48:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1258E28C8E2; Mon, 25 Feb 2008 15:29:11 -0800 (PST) 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 18C2828C8DA for ; Mon, 25 Feb 2008 15:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 QSNlrGOxaNDX for ; Mon, 25 Feb 2008 15:29:08 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 6C3473A6DCE for ; Mon, 25 Feb 2008 15:20:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 0151068014C; Mon, 25 Feb 2008 15:20:38 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12518-04; Mon, 25 Feb 2008 15:20:37 -0800 (PST) Received: from [???????IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 5ADC868014B; Mon, 25 Feb 2008 15:20:37 -0800 (PST) In-Reply-To: <77ead0ec0802151137k7f4690d3i3421fe32cf6669f1@mail.gmail.com> References: <77ead0ec0802150941x6051c740ued3b9236e63e52e9@mail.gmail.com> <09BDC1B6-E728-48BD-8778-3EAF7BF8EFE9@redback.com> <77ead0ec0802151137k7f4690d3i3421fe32cf6669f1@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <328FD2F9-0578-461B-A8BF-F3F10D6C6592@redback.com> From: Acee Lindem Date: Mon, 25 Feb 2008 18:20:36 -0500 To: Vishwas Manral X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Vishwas, On Feb 15, 2008, at 2:37 PM, Vishwas Manral wrote: > Hi Acee, > >>> I like the generic mechanism talked about in the document. I however >>> think the document does not describe how to treat TLV's if a TLV is >>> not understood. If you see all other newer specs for example RFC5036 >>> for LDP, you will notice they have the first 2 bits defining how to >>> treat a packet if there is an unknown TLV. >> >> LLS is optional so the TLVs should have no impact on whether or not >> the OSPF packet itself is accepted. The document probably should >> state: >> >> 1) That the described TLVs MUST be supported. >> 2) What to do if an unknown TLV is encountered. The choices are: >> a. Simply ignore it - this is what people have implemented. >> b. Ignore the whole LLS block >> c. Ignore the whole LLS block contingent on the type encoding >> >> I vote for a. > By having this we are forcing a behavior on future TLV's, they all > have to be optionally understood. We cannot enforce a behavior of drop > a packet if the TLV is not understood. By using the first 2 bits of > the TLV's to signal this behavior we could get such behavior for the > future. In my view such signalling may be possible in the future. LLS is a backward compatible extension. Hence, we're not dropping packets based on understanding TLVs. > >>> The document says the block can only be attached to Hello and DD >>> packets, I would prefer the signaling to be able to be attached >>> to any >>> packets. Thus making OSPF packets truly extensible. >> >> I think that since this is "Link-Local" signaling, hello and DD >> packets make the most sense. In fact, at one time I had argued to >> limit it to hellos but the authors said there were cases where >> appending the signaling to the next DD would result in the signaling >> being communicated faster. However, since a hello can safely be sent >> at any time, I still feel limiting it to hello would be better :^). > I do not see a reason to not allow LLS to packets other than Hello and > DD. Its all about future extensibility here. We should try to be > future proof by allowing the same. If a TLV is not expected in a > packet it can anyway be ignored. I discussed this with on of the authors and if you are going to use LLS on other packet types, than it would probably be for a different set of things than we signal today. Hence, we're going to defer this until such signaling is required. I can't see putting this burden on the specification when we don't have a requirement. Thanks, Acee > >>> The document talks about not doing a checksum if the Crytographic >>> security is present. I think it enhances security as well as >>> simplifies code if we calculate the checksum in all cases. >> >> This is consistent to what is done for OSPF cryptographic >> authentication for the packet itself. I see no reason not to do the >> same for LLS or to effectively checksum it twice when authentication >> is configured. > I agree it is consistent. I however see no benefits in the > approach, though > I can point out problems with it. If we are making a new standard > we could > as well rectify the same. > > > Thanks, > Vishwas > >> >> Thanks, >> Acee >> >> >> >> >>> >>> Thanks, >>> Vishwas >>> >>> On Fri, Feb 15, 2008 at 9:15 AM, Acee Lindem >>> wrote: >>>> This starts the WG last call for the subject document. The target >>>> status is Proposed Standard. >>>> The WG last call will begin today and will end March 1st, 2008 at >>>> 12:00 AM EST. Note that a previous revision (not including >>>> OSPFv3) of >>>> this protocol extension was published as an experimental RFC 4813. >>>> >>>> Thanks, >>>> Acee >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> http://www.ietf.org/mailman/listinfo/ospf >>>> >> >> _______________________________________________ OSPF mailing list OSPF@ietf.org http://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Feb 26 18:40:21 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C1F928C339; Tue, 26 Feb 2008 18:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-0.961, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 FezCPnp7Gwya; Tue, 26 Feb 2008 18:40:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760553A68F1; Tue, 26 Feb 2008 18:40:20 -0800 (PST) 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 EE2593A68F1 for ; Tue, 26 Feb 2008 18:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 dBxg2JMuDjGt for ; Tue, 26 Feb 2008 18:40:18 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 2267B3A6804 for ; Tue, 26 Feb 2008 18:40:17 -0800 (PST) Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Tue, 26 Feb 2008 18:40:09 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Feb 2008 18:23:51 -0800 Received: from [172.24.24.192] (nsheth-xp-lt.jnpr.net [172.24.24.192]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m1R2Npq63358 for ; Tue, 26 Feb 2008 18:23:51 -0800 (PST) (envelope-from nsheth@juniper.net) Message-ID: <47C4C9B5.2030502@juniper.net> Date: Tue, 26 Feb 2008 18:23:49 -0800 From: Nischal Sheth User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: OSPF List