Re: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

"Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com> Tue, 24 July 2012 16:22 UTC

Return-Path: <pranjal.dutta@alcatel-lucent.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCAB21F8694 for <mpls@ietfa.amsl.com>; Tue, 24 Jul 2012 09:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.932
X-Spam-Level:
X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=-1.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+Zd4GY1SF9l for <mpls@ietfa.amsl.com>; Tue, 24 Jul 2012 09:22:55 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9625721F8691 for <mpls@ietf.org>; Tue, 24 Jul 2012 09:22:54 -0700 (PDT)
Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q6OGMkh5001639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jul 2012 11:22:48 -0500 (CDT)
Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6OGMjmQ029159 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Jul 2012 21:52:45 +0530
Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 24 Jul 2012 21:52:44 +0530
From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>
To: Lizhong Jin <lizhong.jin@zte.com.cn>
Date: Tue, 24 Jul 2012 21:52:42 +0530
Thread-Topic: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03
Thread-Index: Ac1pdMddjjHZ7T3MSp2/Jbk9N9+DLAAQjvpA
Message-ID: <C584046466ED224CA92C1BC3313B963E09F2162AC5@INBANSXCHMBSA3.in.alcatel-lucent.com>
References: <C584046466ED224CA92C1BC3313B963E09F2162860@INBANSXCHMBSA3.in.alcatel-lucent.com> <OFA29F2706.7E4EA55C-ON48257A45.002AD16A-48257A45.002D842C@zte.com.cn>
In-Reply-To: <OFA29F2706.7E4EA55C-ON48257A45.002AD16A-48257A45.002D842C@zte.com.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E09F2162AC5INBANSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: "mpls@ietf.org" <mpls@ietf.org>, Giles Heron <giheron@cisco.com>, Thomas Nadeau <tnadeau@juniper.net>, Ross Callon <rcallon@juniper.net>
Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jul 2012 16:23:00 -0000

Hi Lizhong,


[Lizhong] My concern is tracking of T-LDP hello source address by BFD or LDP session (on condition that transport address is same as hello address) could not substitue the liveness of the UDP connection of hello adjacency. For example, when LDP session is setup, and hello adjacency has negotiated to infinite time, althought the hello address is IP reachable, but if UDP port '646' is incorrectly closed or some other UDP problem accured, the hello adjacency in fact is down, but you could not detect this with infinite hold time. Then I mean hello reduction should be used with caution that the UDP will not accure any potential problem. Maybe I missed something.

Yes, you are correct. If there is a bug in S/w that closes port 646 accidentally and then with hello reduction it would take long time to detect. But if a port 646 is closed accidently by a peer but without gracefully shutting down LDP session then don't we already have a bigger problem? In that way we can contest
against many solutions that has a bottom line for resilience against bugs. This is a good point you raised and we would mention it explicitly in the draft. Note
that when LDP is deployed in large scale MPLS access, aggregation, seamless MPLS etc the priority is resilience for adjacencies. There are special
techniques that an implementation can adopt (e.g H/w assisted) to provide such resilience but there are cost functions associated with and we may not
be able to take uniform view of LDP in general.

Thanks,
Pranjal

________________________________
From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn]
Sent: Tuesday, July 24, 2012 1:17 AM
To: Dutta, Pranjal K (Pranjal)
Cc: Giles Heron; loa@pi.nu; VIGOUREUX, MARTIN (MARTIN); Markus Jork; mpls@ietf.org; Ross Callon; swallow@cisco.com; Thomas.Beckhaus@telekom.de; Thomas Nadeau
Subject: RE: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03


Hi Pranjal,
Thanks for the prompt response. See inline below.

Regards
Lizhong


"Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com> wrote 2012/07/24 10:37:54:

> Hi Lizhong,
>                   Thanks for review. Please refer my answers inline.
>
> Cheers,
> Pranjal
>
> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn]
> Sent: Monday, July 23, 2012 2:13 AM
> To: Dutta, Pranjal K (Pranjal); mpls@ietf.org; Thomas Nadeau; Giles Heron
> Cc: loa@pi.nu; VIGOUREUX, MARTIN (MARTIN); Markus Jork; Ross Callon;
> swallow@cisco.com; Thomas.Beckhaus@telekom.de
> Subject: Re: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03
>
>
> Hi all,
> I've reviewed this draft, and have two comments that need to be clarifed:
> 1. Target Hello tracks the liveness of hello adjacency, while LDP
> keepalive tracks the liveness of session. Do you mean it is not
> necessary to track the liveness of hello adjacency, or substitute it
> with liveness tracking of session? Hello address maybe different
> with trasport address.
>
> [Pranjal]  It depends on case by case. For example when transport
> address of the LDP session is different from the IP addresses used
> to exchange t-ldp hellos, then probably it is not RECOMMENDED to use
> hello reduction procedures, since sessions keepallives are not
> really substitute of "reachability" or "liveliness" of the
> adjacency. Alternately it is possible to track the reachability of
> t-ldp sources by means of other fast protocols (e.g BFD and others etc).
> In such a case, the t-ldp hellos could be redundant after initial
> discovery done and session set-up is complete. When peers are
> asymmetric w.r.t hello reduction support (one peer supports while
> the other does not), then the situation falls back to what we have
> with RFC 5036.
[Lizhong] My concern is tracking of T-LDP hello source address by BFD or LDP session (on condition that transport address is same as hello address) could not substitue the liveness of the UDP connection of hello adjacency. For example, when LDP session is setup, and hello adjacency has negotiated to infinite time, althought the hello address is IP reachable, but if UDP port '646' is incorrectly closed or some other UDP problem accured, the hello adjacency in fact is down, but you could not detect this with infinite hold time. Then I mean hello reduction should be used with caution that the UDP will not accure any potential problem. Maybe I missed something.

>
>
> 2. Target hellos are not only used for liveness track, but also
> parameter negotiation and updating. When negotiated to infinite,
> what time interval would be used to send the updated hello (e.g,
> hello with new Optional Parameters in potential draft-pdutta-mpls-
> ldp-adj-capability) message? UDP hello is not reliable, would be
> renegotiated to configured hello hold time first?
>
> [Pranjal] An updated hello can be sent at any time (whenever any
> param is changed to reflect the change to peer) without any changes
> in "current"
> hold time (e.g infinite) that was advertised in the last hello
> message. Means it is not necessary to fallback to configured hold
> time and restart the reduction process (in fact not desirable). For
> example, it could be changes in one or more hello adjacency
> capabilities as described in the aforementioned draft or could be
> any of the existing standard params such as configSeqNum etc. Since
> hellos are not reliable, after any parameter change an implementation
> may send a set of hellos (let's say 5) at configured intervals (or
> faster) to reflect the change. But those hellos would continue to
> advertise infinite hold time
> and would fall back to reduced rate after those 5 packets are sent.
[Lizhong] It is clear now, thank you.

>
> However, changes like IPV4 or IPV6 transport address etc may restart
> the session that can result in starting hello reduction from scratch.
>
> I agree that in its current state draft doesn't describe the
> solution and its flexibilities in adequate detail. We would
> definitely address those.
[Lizhong] Thank you.

>
>
> Summary of review:
> a. whether the document is coherent?
> Good description on the motivation, need more detail in technical
> description (e.g, refer to my second comment).
>
> b. is it useful?
> Yes.
>
> d. is technically sound ?
> Need some clarification.
>
> e. is ready to be considered for WG adoption ?
> After clarification, it should be ready for WG adoption.
>
> Regards
> Lizhong
>
>
> Ross Callon <rcallon@juniper.net> wrote 2012/07/18 05:49:55:
>
> > Markus, Lizhong, Thomas;
> >
> > You have been selected as an MPLS Review team reviewers for
> > draft-pdutta-mpls-tldp-hello-reduce-03
> >
> > Note to authors: You have been CC'd on this email so that you can know that
> > this review is going on. However, please do not review your own document.
> >
> > Reviews should comment on whether the document is coherent, is it useful
> > (ie, is it likely to be actually useful in operational networks), and is
> > the document technically sound?  We are interested in knowing whether the
> > document is ready to be considered for WG adoption (ie, it doesn't have to
> > be perfect at this point, but should be a good start).
> >
> > Reviews should be sent to the document authors, WG co-chairs and secretary,
> > and CC'd to the MPLS WG email list. If necessary, comments may be sent
> > privately to only the WG chairs.
> >
> > Are you able to review this draft by August 3, 2012 (ie, the end
> of the IETF
> > meeting in Vancouver)? We understand that this is somewhat short
> notice and
> > that you might have something else to do the week of the IETF, so let us
> > know if you need slightly more time.
> >
> > Thanks, Ross
> > (as MPLS WG chair)
> >
> > PS: I noticed that Tom Nadeau's email address listed in the draft is
> > out of date. This email is being CC'd to his updated address.
> >