The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Neil,

    No.  RFC3036 describes basic LDP and it is not necessary that
extensions to this protocol are also interoperable for this protocol
itself to advance.  Otherwise it would be impossible to advance
anything.

You wrote:

>Loa,
>
>How does this square with the recent mail posting on LDP resiliency from
>Philip Matthews...see attached?
>
>I am thinking specifically about the interoperability combinations
>mentioned....seems like some more need adding.
>
>regards, Neil
>
>>-----Original Message-----
>>From: Loa Andersson [mailto:loa.andersson@utfors.se]
>>Sent: 20 December 2001 13:05
>>To: mpls@UU.NET
>>Cc: George Swallow; sob@harvard.edu; bwijnen@lucent.com; Bob 
>>Thomas; Loa
>>Andersson
>>Subject: Initiating the process to take LPD to draft standard
>>
>>
>>
>>All,
>>
>>We have been notified by the AD's that it is time to advance LDP
>>(RFC3036) from proposed standard to draft standard.
>>
>>A formal requirement on an IETF protocol to advance to draft standard
>>is that there be at least two interoperable implementations of the
>>specification.
>>
>>This is a request for information about LDP implementations.  Please
>>send the information to:
>>
>>    Bob Thomas <rhthomas@cisco.com>
>>    Loa Andersson <loa.andersson@utfors.se>
>>
>>RFC3036 defines several modes of label distribution and allows an
>>implementation to support one or more of the modes. In addition, 
>>RFC3036 specifies optional behavior. Therefore we need information 
>>about the label distribution modes and optional behavior
>>supported by each implementation.  
>>
>>We ask that the information supplied include which of the following
>>label distribution modes are supported:
>>
>>       Advertisement             Retention      Control
>>
>>    1. Downstream Unsolicited    Ordered        Liberal
>>    2. Downstream Unsolicited    Ordered        Conservative
>>    3. Downstream Unsolicited    Independent    Liberal
>>    4. Downstream Unsolicited    Independent    Conservative
>>
>>    5. Downstream on Demand      Ordered        Liberal
>>    6. Downstream on Demand      Ordered        Conservative
>>    7. Downstream on Demand      Independent    Liberal
>>    8. Downstream on Demand      Independent    Conservative
>>
>>as well as optional features, such as loop detection, optional
>>TLVs, etc., supported by the implementation.  Also, please feel free
>>to include any additional material believed to be relevant.
>>
>>We also need information on interoperability testing and deployment
>>status in order to address the requirement of "two independent and
>>interoperable implementations".
>>
>>
>>Thanks,
>>Bob and Loa
>>
>
>
> ------------------------------------------------------------------------
>
> Subject:
>
> Drafts on LDP Resiliency
> From:
>
> pmatthews@hyperchip.com
> Date:
>
> Wed, 19 Dec 2001 03:56:15 -0000
> To:
>
> mpls@UU.NET
>
>
>For over a year now, the MPLS WG has been working on 
>a draft (draft-ietf-mpls-ldp-ft-02.txt) which describes 
>how to keep LSPs set up using LDP alive across control 
>plane restarts and activity switches. 
>
>At the recent MPLS WG meeting in Salt Lake City, 
>two new drafts were presented that proposed new approaches 
>to this subject. 
>
>The groups behind these three drafts met after the meeting 
>with George Swallow (co-chair), Scott Bradner and Bert Wijnen 
>(Area Directors) to discuss the pros and cons of the various 
>proposals and how best to move forward. 
>
>For pros and cons, we came up with the following list: 
>
>* draft-smith-mpls-ldp-restart-00.txt 
>  Aimed at edge routers doing VPNs and L2 Circuit 
>  Emulation where all LSPs originate or terminate on the box, 
>  and LSPs are pretty static. 
>  Pros: 
>      - Only a very small amount of re-signaling after a restart 
>        or switchover. 
>  Cons: 
>      - Must save LDP state across restart/switchover. 
>      - LSPs after last checkpoint are lost and need re-signaling. 
>
>* draft-leelanivas-ldp-restart-01.txt 
>  Aimed at routers which cannot save LDP state across a restart/switchover. 
>  Pros: 
>      - Works for transit lsps, as well as originating/terminating lsps. 
>  Cons: 
>      - Must re-signal all lsps. (People are divided as to how bad this 
>        really is, but it does take time and effort). 
>
>* draft-ietf-mpls-ldp-ft-02.txt 
>  Aimes to give good switchover performance. 
>  Pros: 
>      - Little signaling after a switchover. 
>      - Works for transit and orig/term lsps. 
>  Cons: 
>      - Must save LDP state across a restart/switchover. 
>      - May be harder to implement than the Smith draft when starting 
>        from an existing non-FT LDP implementation. 
>
>We agreed on the following approach for moving forward: 
>
>* The draft-smith-mpls-ldp-restart-00.txt draft will be 
>  combined with the current WG doc (draft-ietf-mpls-ldp-ft-02.txt). 
>  At a minimum, the Smith draft will be added as an alternative 
>  approach using the same basic technique, but we will attempt 
>  to integrate the two approaches as much as possible. 
>  Adrian Farrel has some ideas for this. 
>
>* The draft-leelanivas-ldp-restart-01.txt draft will continue 
>  as a separate draft for now, since the technique is uses is 
>  quite different from the other two. 
>
>* Both drafts will be enhanced with applicability statements 
>  that clearly states when each approach is appropriate. 
>
>- Philip 
>
>
>