Subject: [Isis-wg] New draft draft-heqian-isis-link-overload-00.txt is provided.

From: heqian 24209 <[email-masked]>
Date: Thu, 20 Oct 2005 23:45:51 +0800

Hi guys,

I have just written one draft. It is about avoiding packet lost when IS-IS is using with LDP (Label Distrute Protocol) in MPLS network.

Details are in the document. It is in attachment. Please refer.

Any question and suggestion are warmly welcome.

Regards,
Heqian
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 20 Oct 2005 18:12:14 +0200

heqian,

there are already implementations out that fix the IGP/LDP desync problem
by advertising the link with MAX_METRIC until LDP startup is complete;
doing so, has the nice property that it is downwards compatible;

/hannes

heqian 24209 wrote:
> ------------------------------------------------------------------------
> 
> 
> Internet Engineering Task Force                                   HeQian
> INTERNET-DRAFT                                                   XiongYi
> Expires Apr 2006                                     Huawei Technologies
>                                                             October 2005
> 
> 
>                        Link Overload Attribute in IS-IS
>                    <draft-heqian-isis-link-overload-00.txt>
> 
> 
> Status of this Memo
> 
>    This memo provides information for the Internet community.  It does
>    not specify an Internet standard of any kind.  Distribution of this
>    memo is unlimited.
> 
> 
> Copyright Notice
> 
>    Copyright (C) The Internet Society 2005. All Rights Reserved.
> 
> 
> Abstract
> 
>    This document describes a mechanism that can be employed in
>    Intermediate System to Intermediate System (IS-IS) networks
>    in order to decrease the data loss associated with Label
>    Distribution Protocol (LDP) during transient network conditions.
> 
> 
> 1. Introduction
> 
>    In many networks, the ISP uses MPLS to carry the data in PEs between
>    CEs and LDP is used to create LSP (Label Switch Path). When IS-IS
>    work with LDP, IS-IS always convergence faster than LDP, which can
>    cause data losing when the data is transfering by LSP (Label Switch
>    Path) in some cases. This document tries to find out a method to
>    solve this interactional problem.
> 
> 
> 2. Discussion
> 
>    This document describes a mechanism that can be employed in IS-IS [1,
>    2] networks in order to avoid transition to a newly available path
>    until other associated protocols such as LDP have been established
>    its session.
> 
>    The benefits of such a mechanism can be realized when considering the
>    following scenario depicted in Figure 1.
> 
> 
>                                +-----+
>                    +-----------| RTB |-----------+
>                    |           +-----+           |
>                    |                             |
>                 +-----+                       +-----+
>        CE.Src---| RTA |                       | RTD |---CE.Dst
>                 +-----+                       +-----+
>                    |                             |
>                    |           +-----+           |
>                    +-----------| RTC |-----------+
>                                +-----+
> 
>                  Figure 1: Example Network Topology
> 
>    IS-IS is running on all the routers as IGP. The path of RTA->RTB->RTD
>    has more priority than RTA->RTC->RTD.
>    
>    CE.Src and CE.Dst are in same VPN. LDP sessions are created between
>    each two routers and one LSP of RTA->RTB->RTD is created. The data are
>    transmitted between two CEs by using the LSP created by LDP.
>    
>    If the state of the link between RTB and RTD changes to DOWN, the next
>    hop of the routes to RTD on RTA will change from RTB to RTC. According
>    to this change, LDP will remove the LSP (RTA->RTB->RTD) and try to
>    create the LSP of RTA->RTC->RTD. Since the LDP sessions are already
>    created between RTA and RTC, RTC and RTD, the LSP (RTA->RTC->RTD) can
>    be created very quikly (about 10's of milli seconds). In this case,
>    the data flow between CE.Src and CE.Dst will be lost only in the
>    period IS-IS updating the network and LDP creating the LSP.
>    
>    Then, assume the state of the link between RTB and RTD changes to UP,
>    the next hop of the routes to RTD on RTA will change back from RTC to
>    RTB. According to this change, LDP will remove the LSP (RTA->RTC->RTD)
>    and try to create the LSP of RTA->RTB->RTD. But at this time, the LDP
>    session between RTB and RTD has not been established, the LSP
>    (RTA->RTB->RTD) can be created till the LDP session between RTB and
>    RTD established. The LDP session establishes slow (about 10's of
>    seconds), this will delay the creation of LSP (RTA->RTB->RTD). In this
>    case, the data flow between CE.Src and CE.Dst will be lost for a long
>    time (at least the time of establishing LDP session).
> 
> 3.  Approach
> 
>    Now we introduce one method to solve the problem.
> 
> 3.1.  Link-Overload property
> 
>    One link property called link overload is required. This property can
>    be carried by any type of IS-IS TLV descripting adjacency.
>    
>    For TLV 2 (IS Neighbor TLV)[1], we can use the eighth bit of default
>    metric, this bit is already sighned to up/down bit, but it is never
>    used for TLV 2. So we can use this bit to carry the Link-Overload
>    property.
>    
>    For TLV 22 (Extended IS Reachability TLV)[3], we can define a new sub
>    tlv named Link-Overload, sub-type is 3 (to be assigned by IANA) and
>    has a length of 1 octets.
>    
>    For MT TLV 222 (MT Intermediate Systems TLV)[4], since this TLV only
>    adds 2 octects (for reserved bits and MT ID) before TLV 22, we can use
>    same method as what we extended for TLV 22.
>    
>    For convernions, we call all these three TLV as Neighbor TLV.
>    
>    This sub-TLV is OPTIONAL and MAY appear at most once for a single IS
>    Neighbor TLV.
> 
> 3.2.  When to start sending the Link-Overload property
> 
>    When the adjacency established on a link, the implementation should
>    check if LDP is enabled on the link and check the LDP's session status.
>    If the LDP session is not established, then the Link-Overload property
>    SHOULD be set in the Neighbor TLV.
> 
> 3.3.  How to use the Link-Overload property on the non-connected routers
> 
>    RTA and RTC are non-connected to the link RTB<->RTD routers. RTB and
>    RTD establish new adjancency and send out the new LSPs with
>    Link-Overload property. When RTA and RTC receive the new LSPs, RTA and
>    RTC will signal a new SPF accroding to the changes. When the SPF is
>    scheduled, the link with Link-Overload property should be ignored.
>    
>    The routes, used by LDP to create LSP (Label Switch Path), will not
>    change during this time. Then the LSP (Label Switch Path) will not
>    change.
> 
> 3.4.  How to use the Link-Overload property on the connected routers
> 
>    RTB and RTD are connected to the link RTB<->RTD routers. When these
>    two routers generate and receive the new LSPs, SPF will be scheduled.
>    When the SPF run, the link with Link-Overload property should be used
>    only when the router is calculating the routes advertised by the other
>    router. For example, when RTB calculates the routes advertised by RTD,
>    the link RTB<->RTD SHOULD be used. And RTB SHOULD NOT calculates other
>    routes via the link.
>    
>    RTB and RTD calculate the routes advertised by each other. These
>    routes can be used for LDP to establish session.
>    
>    According to the algrithm above, only the routes for establishing LDP
>    session will change back at this moment. The other routes, used by LDP
>    to create LSP (Label Switch Path), will not change. So the LSP (Label
>    Switch Path) will not change, and data transmission between RTA and
>    RTD will still use the LSP (Label Switch Path) through RTA->RTC->RTD.
> 
> 3.5.  When to stop sending the Link-Overload property
> 
>    When the LDP session created, LDP SHOULD give a message to IS-IS.
>    Based on this message, IS-IS SHOULD remove the Link-Overload property
>    from the Neighbor TLV and generate new LSP. After the database
>    synchronised, all the routers schedule a normal SPF calculation once.
>    All the routes will change back to the path RTA->RTB->RTD. LDP will
>    remove the LSP (RTA->RTC->RTD) and create the new LSP (RTA->RTB->RTD).
>    Since the LDP session is already established on the link RTB<->RTD,
>    the creation of LSP (RTA->RTB->RTD) will be very fast (about 10's
>    milli seconds). According to this method, the data losting could be
>    reduced much during the link RTB<->RTD changes back to UP status.
>    
>    If there is problem for LDP to send a message to IS-IS, IS-IS could
>    not recover to the normal state. To avoid this, IS-IS can start a
>    timer when the adjacency created, and when the timer expires, stop
>    sending the Link-Overload property.
> 
> 
> 4. Deployment Considerations
> 
>    A router not supporting the Link-Overload sub-TLV MUST just silently
>    ignore this sub-TLV.
> 
>    Since the Link-Overload property is used in IS-IS SPF calculation,
>    some routers in the routing domain don't support the Link-Overload
>    property can cause loops or black holes. 
> 
> 
> 5. Potential Alternatives
> 
>    This extention needs all routers to support in the routing domain.
>    When there are some routers who do not support the Link-Overload
>    property, the way described below can be used.
> 
>    The connected routers don't send the Neighbor TLV when adjacency comes
>    to UP if LDP session is not established. The non-connected routers will
>    not know the adjacency, then, all the routes in non-connected routers
>    will not change. The connected routers SHOULD start a SPF calculation.
>    During the calculation, the adjacency SHOULD be used this adjacency
>    SHOULD be used in it's calculation but ignore the two way check. The
>    routes for establishing the LDP session can be calculated by this way.
>    
>    So, this method can compatible with the routers who do not support the
>    Link-Overload property. The only constriction is that the connected
>    router have to support this method both.
> 
> 
> 6. Security Considerations
> 
>    The Link-Overload property defined within this document describes an
>    addition to the IS-IS Neighbor TLV and does not impact the security
>    mechanism of the IS-IS protocol.
> 
> 
> 7. Acknowledgements
> 
>    The authors would like to thank Lixia Zhang, XiongYi, ZhangRenhai and
>    LiDefeng for their useful comments.
> 
> 
> 8. References
> 
>    [1] ISO, "Intermediate system to Intermediate system routing
>        information exchange protocol for use in conjunction with the
>        Protocol for providing the Connectionless-mode Network Service
>        (ISO 8473)," ISO/IEC 10589:1992.
> 
>    [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195,
>        December 1990.
> 
>    [3] Li, T. and H. Smit, "IS-IS extensions for Traffic Engineering"
>        RFC 3906, October 2004.
> 
>    [4] Tony Przygienda, Naiming Shen and Nischal Sheth, "M-ISIS: Multi
>        Topology (MT) Routing in IS-IS" Draft draft-ietf-isis-wg-multi-
>        topology-10, May 2005.
> 
> 
> 9. Author's Address
> 
>    HeQian
>    Beijing Institution of Huawei Technologies, China.
>    Phone: 86-010-82882012
>    EMail: [email-masked]
>  
> 
> 
> ------------------------------------------------------------------------
>

---

From: stefano previdi <[email-masked]>
Date: Fri, 21 Oct 2005 12:20:01 +0200

> doing so, has the nice property that it is downwards compatible;

... and need not any extension...

s.

>
> /hannes
>
> heqian 24209 wrote:
>> Hi guys,
>> I have just written one draft. It is about avoiding packet lost when  
>> IS-IS is using with LDP (Label Distrute Protocol) in MPLS network.
>> INTERNET-DRAFT                                                    
>> XiongYi
>>                                                             October  
>> 2005
>>    property can cause loops or black holes. 5. Potential Alternatives