Subject: Re: [Isis-wg] Flooding priority in FS-LSP

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 5 Aug 2013 20:49:51 +0000

Changwang -

Thanx for your comments.
I am copying the WG - and also changed the Subject line - as comments on the FS-LSP draft are most welcome but are of interest to the full WG.

The goal of the IS-IS Update process has always been to propagate LSPs in a timely manner while also providing controls to prevent flooding storms. And the protocol has done quite well in this regard even in the context of the faster convergence requirements that have become the norm in many deployments. Historically the need for having different flooding priorities for individual LSPs has not arisen.

One of the capabilities FS-LSP provides is the ability to have a much larger set of LSPs generated by a single system (64K vs the present limitation of 256). And one of the use cases for this is the need to advertise a much larger number of leaf node advertisements. In that context, one can imagine that a topology change may be associated with both a change in IS-neighbor advertisement and the addition/removal of a large # of leaf node advertisements. This could then require update of multiple LSPs - but it is desirable to flood the IS-neighbor changes at a higher priority because they potentially have a much greater impact - and if the number of LSPs modified is large the value for priority flooding becomes more significant. However, priority flooding adds complexity into implementations and needs to be introduced with caution. The fact that we see some value in supporting priority flooding does not automatically lead to the conclusion that it is desirable to support multiple levels of priority. In the end we still want propagation of all LSP changes to happen quickly. So I think a modest proposal (high and normal priority) is both sufficient and prudent.

   Les

> 
> Les,
>    I am Changwang Lin , from H3C company.
> 
>    It is a great happy for me and Haifeng to see you in the berlin isis-wg
> meeting.
>    Time is short, we don't have more time to discuss about this draft and
> other is-is problems.
> 
> 
>    I hope we can discuss more is-is problem in email.
> 
>    draft-ginsberg-isis-fs-lsp-01：
>        in FS-LSP, you define flood-scope LSP: |P|  Scope                | ,
>        Scope - Bits 1-7 define the flooding scope.
>        P - Bit 8 - Priority Bit
> 
>    My question：why use only one bit for Priority, maybe we have more than one
> flood priority just like prefix-calculation priority.
>                Maybe we can define like these:
> 
> 
>       +-+-+-+-+-+-+-+-+
>       | P |R|R| SCOPE |
>       +-+-+-+-+-+-+-+-+
> 
>       P- Bit 8-7
>       R-Bit 5-6，Reserve for other pursose.
>       Scope - Bits 1-4 define the flooding scope.
> 
> 
> Best regards,
> -Changwang
> 
>

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 6 Aug 2013 10:01:40 +0200

<WG-chair hat off>
in the past we have more run into 'lack of space',
rather than 'what is a more optimal way of draining LSP queues"
issues.

therefore i'd be more in favor of more FS bits rather than priority classes.
- one level of flood-priority discrimination seems sufficient to me.

/hannes

On Aug 5, 2013, at 10:49 PM, Les Ginsberg (ginsberg) wrote:

> One of the capabilities FS-LSP provides is the ability to have a much larger set of LSPs generated by a single system (64K vs the present limitation of 256). And one of the use cases for this is the need to advertise a much larger number of leaf node advertisements. In that context, one can imagine that a topology change may be associated with both a change in IS-neighbor advertisement and the addition/removal of a large # of leaf node advertisements. This could then require update of multiple LSPs - but it is desirable to flood the IS-neighbor changes at a higher priority because they potentially have a much greater impact - and if the number of LSPs modified is large the value for priority flooding becomes more significant. However, priority flooding adds complexity into implementations and needs to be introduced with caution. The fact that we see some value in supporting priority flooding does not automatically lead to the conclusion that it is desirable to support multipl
> e levels of priority. In the end we still want propagation of all LSP changes to happen quickly. So I think a modest proposal (high and normal priority) is both sufficient and prudent.
> 
>   Les
> 
>> 
>> Les,
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
> 
>

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 6 Aug 2013 17:26:54 +0200

we have proof point in existing implementations that
flooding priority and RIB/FIB prefix prioritization are orthogonal things.
i.e. you can implement RIB/FIB prefix priorization without any flooding prioritization.

my read of the FS draft is that the authors would like to differentiate
routing vs. non-routing relevant fragments and hence the need for a single
bit, to make sure rowing data gets sufficient service, while IS-IS is
used for dissemination of non-routing state.

/hannes

On Aug 6, 2013, at 4:22 PM, a wrote:
>      
>     I agree that lack of space in LSP head in the past. I think the capabilities FS-LSP is good chance 
> for us to extending space not only for flood-scope but also other purposes in further.
> 
>       Now  we use the spf prefix-priority  to change the sequence of prefix updates to the RIB after an SPF is run. ISIS installs prefixes in the   
>    RIB according to the following priority order: Critical > High > Medium > Low. 
>      So I think the flood-priority is same as spf prefix-priority. One level of flood-priority is not enough.

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 7 Aug 2013 17:12:12 +0200

On Aug 7, 2013, at 9:55 AM, [email-masked] wrote:
> 
>        Since we put priority bit on LSP, why not reserve more bits?

because one bit is enough to discriminate routing from non-routing information.

>        In one LSP fragment, may be some topology information carried by IS-neighbor TLV, some Ipv4 leaf information carried by IS-EXTEND-REACH-TLV,
>    some Ipv6 leaf information carried by IS-IPv6-READCH-TLV, or multi-topology TLV, and other information TLV.
>    We can classify diffierent TLV with different flooding priority in different LSP fragments and flooding the higher priority LSP first.

what you are suggesting above has got implications how you advertise those TLV information.
since the 'priority' bits have per fragment scope and the examples above have
per object scope what you need to do is to advertise all objects of a certain priority
into a dedicated fragment. i am not sure if the authors of the FS draft had this
in mind.

>    Flooding priority and prefix priority are orthogonal things, but we can make them working together as the following usecase:
> 
>    R1-----R2-------R4
>          |
>          |
>          R3
> 
>    When R1 and R3 send different prefixs to R4,
>    Traffic streams from R4 to R1(destination is prefix R1 sending to R4), R4 to R3(destination is prefix R3 sending to R4) at the same time,
>    Demand: the traffic stream from R4 to R1 convergence time is short than R4 to R3.
>        In R2: spf prefix-priority and LSP flood priority may be configured together, Then R4 can receive high priority prefix first,and also calculate them priori
> 

another option would be to use local-repair (LFA, R-LFA) technology such that
the actual speed of control-plane messages and routing-protocol
convergence does not matter, since traffic can be kept flowing on the
backup path. 

> -----邮件原件-----
> 发件人: Hannes Gredler [mailto:[email-masked]]
> 发送时间: 2013年8月6日 23:27
> 收件人: a
> 抄送: [email-masked]; [email-masked]; linchangwang 04414
> 主题: Re: [Isis-wg] Flooding priority in FS-LSP
> 
> we have proof point in existing implementations that flooding priority and RIB/FIB prefix prioritization are orthogonal things.
> my read of the FS draft is that the authors would like to differentiate routing vs. non-routing relevant fragments and hence the need for a single bit, to make sure rowing data gets sufficient service, while IS-IS is used for dissemination of non-routing state.
> 
> /hannes
> 
>>    I agree that lack of space in LSP head in the past. I think the
>> capabilities FS-LSP is good chance for us to extending space not only for flood-scope but also other purposes in further.
>> 
> -------------------------------------------------------------------------------------------------------------------------------------
> 本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出
> 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
> 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
> 邮件！
> This e-mail and its attachments contain confidential information from H3C, which is
> intended only for the person or entity whose address is listed above. Any use of the
> information contained herein in any way (including, but not limited to, total or partial
> disclosure, reproduction, or dissemination) by persons other than the intended
> recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
> by phone or email immediately and delete it!