From sekraj@gmail.com Mon Sep 2 01:12:25 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE9711E81CB for ; Mon, 2 Sep 2013 01:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 bb-aqWuOANeB for ; Mon, 2 Sep 2013 01:12:12 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id D6BD011E81CA for ; Mon, 2 Sep 2013 01:11:41 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id m16so6272935ieq.38 for ; Mon, 02 Sep 2013 01:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=06pKAjDihfGt7/EkV6Ffbdo7Q9qbnd7tfNzgLlzARMU=; b=u+ih7QOF3VAmK/ssccur5ncD5B0br1dQYZcIbKI7yuJZEd/Kw547UNsRpUxf/DwN/W PSqCLpnjZIR1SZjyVFi2ifHU/9Q/SRHSngO2fH9JHiQIWbHlWaA7Uh15Oy6YZ/KEukrJ GgBOStAvaAl+7pgLTlR/2NRlVPUbF2gbmuAk5iqABKUp/EPv9YavC92a8gm954cXaLJ0 Hhp7Z3SRkmrdkG8zefSn+N30U1M8CNseTw+0oIDpY9ddp3YoJPVTXAyp3bQm/5/jT4BU XOOZfUSD3iXSditVjuDesuLaFzygam3/JdqGMVhgM6MqmU/P/n9qw0hsDrfuxLSbgA6R BDBg== MIME-Version: 1.0 X-Received: by 10.50.45.34 with SMTP id j2mr11179718igm.13.1378109501210; Mon, 02 Sep 2013 01:11:41 -0700 (PDT) Received: by 10.50.82.4 with HTTP; Mon, 2 Sep 2013 01:11:41 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Sep 2013 13:41:41 +0530 Message-ID: Subject: Re: BFD MIB minimizing notifications From: Rajasekar Kumar To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=089e0122f00c480a3804e5621f48 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 08:12:29 -0000 --089e0122f00c480a3804e5621f48 Content-Type: text/plain; charset=ISO-8859-1 Thanks Nobo. There is a possibility that Implementers might miss the point that sequence of events should not be altered in notifications (or) events should not be combined/fused when a different event was present in between. I think this may not be obvious from existing text, especially if implementer has not done this kind of optimization before. Could some text be added along with an example in notifications section? On Wed, Aug 28, 2013 at 7:03 PM, Nobo Akiya (nobo) wrote: > Hi Rajesekar, > > Unless implementation wants to intentionally suppress rapid state > change(s) and back to original state, it would be incorrect to "fuse" same > state for same index, meaning there'll be two "up" traps for index 2 > whether you optimize or not. > > Without optimization: > - There will be 5 traps. > - 1-up, 2-up, 3-up, 2-down, 2-up > > With optimization: > - There will be 3 traps. > - 1-2-3-up, 2-down, 2-up > > > What is considered as roughly the same time? How long should the > > implementation wait in order to combine the status changes of multiple > > sessions, before generating a notification? > > In general, I would guess that operators do not want the "wait" to be more > than a second, two at the most. > > - Nobo > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > > Behalf Of Rajasekar Kumar > > Sent: Wednesday, August 28, 2013 6:26 AM > > To: rtg-bfd@ietf.org > > Subject: BFD MIB minimizing notifications > > > > Hi > > I am looking at bfdSessUp & bfdSessDown notifications. Draft mentions the > > below. > > "For the > > cases where a contiguous range of sessions > > have transitioned into the up(4) state at roughly > > the same time, the device SHOULD issue a single > > notification for each range of contiguous indexes in > > an effort to minimize the emission of a large number > > of notifications." > > What is considered as roughly the same time? How long should the > > implementation wait in order to combine the status changes of multiple > > sessions, before generating a notification? > > If I assume that the implementation should wait for some amount of time, > > the following problem exists. Suppose there are sessions with indexes > 1, 2, > > 3. All of them move to UP state within the waiting time. Before expiry > of > > waiting time, if session index 2 quickly moves to DOWN, then again to > > UP, bfdSessUp trap will be generated first for session indexes 1,2,3. > After > > this, bfdSessDown will be generated for session index 2. The result is: > the > > order of traps was reversed (With optimization, the order is UP, then > DOWN > > trap. But without optimization, the order would be UP, DOWN, UP) > > Please let me know if I am missing something. > > Thanks > > Rajasekar > --089e0122f00c480a3804e5621f48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Nobo. There is a possibility that Implementers migh= t miss the point that sequence of events should not be altered in notificat= ions (or) events should not be combined/fused when a different event was pr= esent in between. I think this may not be obvious from existing text, espec= ially if implementer has not done this kind of optimization before. Could s= ome text be added along with an example in notifications section?


On Wed,= Aug 28, 2013 at 7:03 PM, Nobo Akiya (nobo) <nobo@cisco.com> = wrote:
Hi Rajesekar,

Unless implementation wants to intentionally suppress rapid state change(s)= and back to original state, it would be incorrect to "fuse" same= state for same index, meaning there'll be two "up" traps for= index 2 whether you optimize or not.

Without optimization:
- There will be 5 traps.
- 1-up, 2-up, 3-up, 2-down, 2-up

With optimization:
- There will be 3 traps.
- 1-2-3-up, 2-down, 2-up

> What is considered as roughly the same time? How long should the
> implementation wait in order to combine the status changes of multiple=
> sessions, before generating a notification?

In general, I would guess that operators do not want the "wait&q= uot; to be more than a second, two at the most.

- Nobo

> -----Original Message-----
> From: rtg-bfd-bounces@ietf= .org [mailto:rtg-bfd-bounce= s@ietf.org] On
> Behalf Of Rajasekar Kumar
> Sent: Wednesday, August 28, 2013 6:26 AM
> To: rtg-bfd@ietf.org
> Subject: BFD MIB minimizing notifications
>
> Hi
> I am looking at bfdSessUp & bfdSessDown notifications. Draft menti= ons the
> below.
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "For the
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cases where a contiguous range of= sessions
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 have transitioned into the up(4) = state at roughly
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the same time, the device SHOULD = issue a single
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 notification for each range of co= ntiguous indexes in
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 an effort to minimize the emissio= n of a large number
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 of notifications."
> What is considered as roughly the same time? How long should the
> implementation wait in order to combine the status changes of multiple=
> sessions, before generating a notification?
> If I assume that the implementation should wait for some amount of tim= e,
> the following problem exists.=A0 Suppose there are sessions with index= es 1, 2,
> 3. All of them move to UP state within the waiting time.=A0 Before exp= iry of
> waiting time, if session index 2 quickly moves to DOWN, then again to<= br> > UP,=A0 bfdSessUp trap will be generated first for session indexes 1,2,= 3. After
> this, bfdSessDown will be generated for session index 2.=A0 The result= is: the
> order of traps was reversed (With optimization, the order is UP, then = DOWN
> trap.=A0 But without optimization, the order would be UP, DOWN, UP) > Please let me know if I am missing something.
> Thanks
> Rajasekar

--089e0122f00c480a3804e5621f48-- From nobo@cisco.com Tue Sep 3 08:04:05 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1602E21E80E6 for ; Tue, 3 Sep 2013 08:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 dWmh+PLxtEAw for ; Tue, 3 Sep 2013 08:03:45 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 24C1C21F942D for ; Tue, 3 Sep 2013 08:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13534; q=dns/txt; s=iport; t=1378220601; x=1379430201; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2I8OXEZQHz+i5U0ZhLg7ZMXxFPeq6/pfzLr9z+zaixw=; b=ZBi5bklPnD4bVk4JKRsF/Sf9rBbf+eN2x+jRZvECu7ACjcK2Z9nWiAUO 7Ke3Gw2GElFRO2LP+iKp259CHlhkX2Kruou6MAfCIHdq0TJvw/+OUKLXY QUFqO03FliCeJp36wYwXTqUVX5HwdHeviBy8+Gl6YUp9uCPXmU/7H0JyN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAEP5JVKtJV2c/2dsb2JhbABbgkMjITVRwHWBKhZ0giQBAQEDAS1KAgUHBAIBCA4DBAEBCx0HIREUCQgCBA4FCIdoAwkGAbA6DYhRjQmCPDEGAQaDF4EAA5QbgXGOIIUvgyCCKg X-IronPort-AV: E=Sophos;i="4.89,1014,1367971200"; d="scan'208,217";a="254985907" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 03 Sep 2013 15:03:11 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r83F3B3i016469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Sep 2013 15:03:11 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 10:03:11 -0500 From: "Nobo Akiya (nobo)" To: Rajasekar Kumar Subject: RE: BFD MIB minimizing notifications Thread-Topic: BFD MIB minimizing notifications Thread-Index: AQHOo9j2nVStK3vLd0ObMXRyT9Uo0pmqmjjQgAfaA4CAAaOkgA== Date: Tue, 3 Sep 2013 15:03:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941DDD5C45xmbalnx01ciscoc_" MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:04:05 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941DDD5C45xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Rajasekar, Think of this trap as a box that takes output form BFD module (state change= s) and generates corresponding SNMP notifications. Each SNMP notification a= llows inclusion of multiple messages (state changes) to minimize number of = total SNMP notifications generated. It should, however, be well understood = that no messages should be misplaced by this box. "combined/fused" really m= eans this box has misplaced some messages. As for adding more texts, I'm ac= tually not convinced adding lengthy explanations for this aspect will benef= it much when it becomes fairly clear once fundamental purpose of BFD MIB is= understood by the reader. With that said, your comment is appreciated. -Nobo From: Rajasekar Kumar [mailto:sekraj@gmail.com] Sent: Monday, September 02, 2013 4:12 AM To: Nobo Akiya (nobo) Cc: rtg-bfd@ietf.org Subject: Re: BFD MIB minimizing notifications Thanks Nobo. There is a possibility that Implementers might miss the point = that sequence of events should not be altered in notifications (or) events = should not be combined/fused when a different event was present in between.= I think this may not be obvious from existing text, especially if implemen= ter has not done this kind of optimization before. Could some text be added= along with an example in notifications section? On Wed, Aug 28, 2013 at 7:03 PM, Nobo Akiya (nobo) > wrote: Hi Rajesekar, Unless implementation wants to intentionally suppress rapid state change(s)= and back to original state, it would be incorrect to "fuse" same state for= same index, meaning there'll be two "up" traps for index 2 whether you opt= imize or not. Without optimization: - There will be 5 traps. - 1-up, 2-up, 3-up, 2-down, 2-up With optimization: - There will be 3 traps. - 1-2-3-up, 2-down, 2-up > What is considered as roughly the same time? How long should the > implementation wait in order to combine the status changes of multiple > sessions, before generating a notification? In general, I would guess that operators do not want the "wait" to be more = than a second, two at the most. - Nobo > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:r= tg-bfd-bounces@ietf.org] On > Behalf Of Rajasekar Kumar > Sent: Wednesday, August 28, 2013 6:26 AM > To: rtg-bfd@ietf.org > Subject: BFD MIB minimizing notifications > > Hi > I am looking at bfdSessUp & bfdSessDown notifications. Draft mentions the > below. > "For the > cases where a contiguous range of sessions > have transitioned into the up(4) state at roughly > the same time, the device SHOULD issue a single > notification for each range of contiguous indexes in > an effort to minimize the emission of a large number > of notifications." > What is considered as roughly the same time? How long should the > implementation wait in order to combine the status changes of multiple > sessions, before generating a notification? > If I assume that the implementation should wait for some amount of time, > the following problem exists. Suppose there are sessions with indexes 1,= 2, > 3. All of them move to UP state within the waiting time. Before expiry o= f > waiting time, if session index 2 quickly moves to DOWN, then again to > UP, bfdSessUp trap will be generated first for session indexes 1,2,3. Af= ter > this, bfdSessDown will be generated for session index 2. The result is: = the > order of traps was reversed (With optimization, the order is UP, then DOW= N > trap. But without optimization, the order would be UP, DOWN, UP) > Please let me know if I am missing something. > Thanks > Rajasekar --_000_CECE764681BE964CBE1DFF78F3CDD3941DDD5C45xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Rajasekar,

 <= /p>

Think of this trap as a b= ox that takes output form BFD module (state changes) and generates correspo= nding SNMP notifications. Each SNMP notification allows inclusion of multiple messages (state changes) to minimize number of total= SNMP notifications generated. It should, however, be well understood that = no messages should be misplaced by this box. “combined/fused” r= eally means this box has misplaced some messages. As for adding more texts, I’m actually not convinced adding lengthy = explanations for this aspect will benefit much when it becomes fairly clear= once fundamental purpose of BFD MIB is understood by the reader.

 <= /p>

With that said, your comm= ent is appreciated.

 <= /p>

-Nobo

 <= /p>

 <= /p>

From: Rajaseka= r Kumar [mailto:sekraj@gmail.com]
Sent: Monday, September 02, 2013 4:12 AM
To: Nobo Akiya (nobo)
Cc: rtg-bfd@ietf.org
Subject: Re: BFD MIB minimizing notifications

 

Thanks Nobo. There is a possibility that Implementer= s might miss the point that sequence of events should not be altered in not= ifications (or) events should not be combined/fused when a different event = was present in between. I think this may not be obvious from existing text, especially if implementer has not d= one this kind of optimization before. Could some text be added along with a= n example in notifications section?

 

On Wed, Aug 28, 2013 at 7:03 PM, Nobo Akiya (nobo) &= lt;nobo@cisco.com&g= t; wrote:

Hi Rajesekar,

Unless implementation wants to intentionally suppress rapid state change(s)= and back to original state, it would be incorrect to "fuse" same= state for same index, meaning there'll be two "up" traps for ind= ex 2 whether you optimize or not.

Without optimization:
- There will be 5 traps.
- 1-up, 2-up, 3-up, 2-down, 2-up

With optimization:
- There will be 3 traps.
- 1-2-3-up, 2-down, 2-up


> What is considered as roughly the same time? How long should the
> implementation wait in order to combine the status changes of multiple=
> sessions, before generating a notification?

In general, I would guess that operators do not want= the "wait" to be more than a second, two at the most.

- Nobo


> -----Original Message-----
> From: rtg-bfd-bounces@ietf= .org [mailto:rtg-bfd-bounce= s@ietf.org] On
> Behalf Of Rajasekar Kumar
> Sent: Wednesday, August 28, 2013 6:26 AM
> To: rtg-bfd@ietf.org
> Subject: BFD MIB minimizing notifications
>
> Hi
> I am looking at bfdSessUp & bfdSessDown notifications. Draft menti= ons the
> below.
>            &nbs= p; "For the
>            &nbs= p; cases where a contiguous range of sessions
>            &nbs= p; have transitioned into the up(4) state at roughly
>            &nbs= p; the same time, the device SHOULD issue a single
>            &nbs= p; notification for each range of contiguous indexes in
>            &nbs= p; an effort to minimize the emission of a large number
>            &nbs= p; of notifications."
> What is considered as roughly the same time? How long should the
> implementation wait in order to combine the status changes of multiple=
> sessions, before generating a notification?
> If I assume that the implementation should wait for some amount of tim= e,
> the following problem exists.  Suppose there are sessions with in= dexes 1, 2,
> 3. All of them move to UP state within the waiting time.  Before = expiry of
> waiting time, if session index 2 quickly moves to DOWN, then again to<= br> > UP,  bfdSessUp trap will be generated first for session indexes 1= ,2,3. After
> this, bfdSessDown will be generated for session index 2.  The res= ult is: the
> order of traps was reversed (With optimization, the order is UP, then = DOWN
> trap.  But without optimization, the order would be UP, DOWN, UP)=
> Please let me know if I am missing something.
> Thanks
> Rajasekar

 

--_000_CECE764681BE964CBE1DFF78F3CDD3941DDD5C45xmbalnx01ciscoc_-- From toms.sanders@gmail.com Tue Sep 3 09:19:10 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA4521E817C for ; Tue, 3 Sep 2013 09:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 fzcL8sfCb9N9 for ; Tue, 3 Sep 2013 09:19:09 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id A2C3B11E80E4 for ; Tue, 3 Sep 2013 09:19:06 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w10so6256895pde.9 for ; Tue, 03 Sep 2013 09:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JRhclcLU1PHIRLjPBDOk5cJ1jhdYwWX7H7iSJTmCwKs=; b=DJP01i7eV7b9zZPuwvy5PiylwukjqMBtzLLBmvcgD6uR7xEh3J6ac+0FHXCOv5ERh+ XBQ4eKnnTj4mnI4+zaGj8YqvdgAhHPX7HgJRpF7z+LVBWuSwLQC0cqLT6aY8N/mtpM3j Ps//372a4kU39hO9WYBARCjNNJ5SopD9DJxMAJksQMO4WmG5IbGXSHk0p7RV5EOogXeO j3p1DwfVV2S29szRAHfqnt/oDfAEZwA14Q5oiu1uFr1zoiJ3exg4ATAViTE7DQ0/Te8k 01OECHMzLLg5nVVo8Bwa/hHNDGgt2X+5H5IzaHCsiSPG/MMOUk5mm2oIY5fx2h+ciBWK XlFw== MIME-Version: 1.0 X-Received: by 10.66.196.168 with SMTP id in8mr32417618pac.18.1378225145347; Tue, 03 Sep 2013 09:19:05 -0700 (PDT) Received: by 10.68.137.102 with HTTP; Tue, 3 Sep 2013 09:19:05 -0700 (PDT) In-Reply-To: References: <20130821145447.28106.64314.idtracker@ietfa.amsl.com> Date: Tue, 3 Sep 2013 21:49:05 +0530 Message-ID: Subject: Re: New Version Notification for draft-akiya-bfd-seamless-base-01.txt From: Tom Sanders To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=047d7bdca8a435848a04e57d0c40 Cc: "David Ward \(wardd\)" , "rtg-bfd@ietf.org" , "Carlos Pignataro \(cpignata\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 16:19:10 -0000 --047d7bdca8a435848a04e57d0c40 Content-Type: text/plain; charset=UTF-8 Nobo et. al, Am i correct in saying that the main idea behind the draft is to create pseudo reflector BFD sessions that respond to the incoming BFD packets without maintaining any BFD neighbor state machine? As a result its only the nodes that initiate BFD packets that need to maintain the session state; the reflector BFD nodes are essentially stateless. While i can see the advantage to some extent, i am really not sure if we indeed need such an extension to BFD! Is maintaining BFD session state really hard when doing BFD in ASICs? Would love to hear what others have to say here. Toms On 21 August 2013 20:51, Nobo Akiya (nobo) wrote: > > Hello BFD WG Members, > > We have published S-BFD Base -01. > > URL: > http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-base-01.txt > Status: > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base > Htmlized: > http://tools.ietf.org/html/draft-akiya-bfd-seamless-base-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-akiya-bfd-seamless-base-01 > > We have reworded several sections to improve the readability aspect. > There are few technical changes as well. If you have read -01, please > visit the diff link to see what has changed. > > Authors are looking into various aspects of S-BFD next. Carlos and myself > will be looking into further defining Segment Routing scenarios (S-BFD SR > draft) and will be seeking some help to on that front. And progress of that > requires the "base" to be solidified, and we are need your help. Please > point out anything that is unclear, confusing and/or questionable. > > Regards, > Authors > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Wednesday, August 21, 2013 10:55 AM > > To: David Ward (wardd); Manav Bhatia; David Ward (wardd); Carlos > > Pignataro (cpignata); Nobo Akiya (nobo) > > Subject: New Version Notification for > draft-akiya-bfd-seamless-base-01.txt > > > > > > A new version of I-D, draft-akiya-bfd-seamless-base-01.txt > > has been successfully submitted by Nobo Akiya and posted to the IETF > > repository. > > > > Filename: draft-akiya-bfd-seamless-base > > Revision: 01 > > Title: Seamless Bidirectional Forwarding Detection (BFD) > with > > MPLS Label Verification Extension > > Creation date: 2013-08-21 > > Group: Individual Submission > > Number of pages: 20 > > URL: > http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless- > > base-01.txt > > Status: > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base > > Htmlized: > http://tools.ietf.org/html/draft-akiya-bfd-seamless-base-01 > > Diff: > http://www.ietf.org/rfcdiff?url2=draft-akiya-bfd-seamless-base- > > 01 > > > > Abstract: > > This document defines a simplified mechanism to use Bidirectional > > Forwarding Detection (BFD) with large portions of negotiation aspects > > eliminated, that allows full and partial reachability verification. > > For MPLS based BFD, extensions to the generic mechanism are defined > > that allows BFD to perform a level of label verification. > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > The IETF Secretariat > > -- Toms. --047d7bdca8a435848a04e57d0c40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nobo et. al,

Am i correct in saying tha= t the main idea behind the draft is to create pseudo reflector BFD sessions= that respond to the incoming BFD packets without maintaining any BFD neigh= bor state machine? As a result its only the nodes that initiate BFD packets= that need to maintain the session state; the reflector BFD nodes are essen= tially stateless.

While i can see the advantage to some extent, i am real= ly not sure if we indeed need such an extension to BFD! Is maintaining BFD = session state really hard when doing BFD in ASICs? Would love to hear what = others have to say here.

Toms


On 21 August 2013 20:51, Nobo Akiya (nobo) <nobo@cisco= .com> wrote:

Hello BFD WG Members,

We have published S-BFD Base -01.

URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-base-01.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatrack= er.ietf.org/doc/draft-akiya-bfd-seamless-base
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/h= tml/draft-akiya-bfd-seamless-base-01
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http:= //www.ietf.org/rfcdiff?url2=3Ddraft-akiya-bfd-seamless-base-01

We have reworded several sections to improve the readability aspect.
There are few technical changes as well. If you have read -01, please visit= the diff link to see what has changed.

Authors are looking into various aspects of S-BFD next. Carlos and myself w= ill be looking into further defining Segment Routing scenarios (S-BFD SR dr= aft) and will be seeking some help to on that front. And progress of that r= equires the "base" to be solidified, and we are need your help. P= lease point out anything that is unclear, confusing and/or questionable.
Regards,
Authors

> -----Original Message-----
> From: internet-drafts@ietf= .org [mailto:internet-draft= s@ietf.org]
> Sent: Wednesday, August 21, 2013 10:55 AM
> To: David Ward (wardd); Manav Bhatia; David Ward (wardd); Carlos
> Pignataro (cpignata); Nobo Akiya (nobo)
> Subject: New Version Notification for draft-akiya-bfd-seamless-base-01= .txt
>
>
> A new version of I-D, draft-akiya-bfd-seamless-base-01.txt
> has been successfully submitted by Nobo Akiya and posted to the IETF > repository.
>
> Filename: =C2=A0 =C2=A0 =C2=A0draft-akiya-bfd-seamless-base
> Revision: =C2=A0 =C2=A0 =C2=A001
> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Seamles= s Bidirectional Forwarding Detection (BFD) with
> MPLS Label Verification Extension
> Creation date: =C2=A0 =C2=A0 =C2=A0 =C2=A0 2013-08-21
> Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individ= ual Submission
> Number of pages: 20
> URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http:/= /www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-
> base-01.txt
> Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://data= tracker.ietf.org/doc/draft-akiya-bfd-seamless-base
> Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.= org/html/draft-akiya-bfd-seamless-base-01
> Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tp://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-bfd-seamless-base-
> 01
>
> Abstract:
> =C2=A0 =C2=A0This document defines a simplified mechanism to use Bidir= ectional
> =C2=A0 =C2=A0Forwarding Detection (BFD) with large portions of negotia= tion aspects
> =C2=A0 =C2=A0eliminated, that allows full and partial reachability ver= ification.
> =C2=A0 =C2=A0For MPLS based BFD, extensions to the generic mechanism a= re defined
> =C2=A0 =C2=A0that allows BFD to perform a level of label verification.=
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat




--
Toms. --047d7bdca8a435848a04e57d0c40-- From nobo@cisco.com Tue Sep 3 19:57:15 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7186321F995F for ; Tue, 3 Sep 2013 19:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Yd6sJER5WWsC for ; Tue, 3 Sep 2013 19:57:10 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A736F21F96ED for ; Tue, 3 Sep 2013 19:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8638; q=dns/txt; s=iport; t=1378263429; x=1379473029; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2hpCqDadfPaxHXbUzeYIYN+Io9UfUFZ6bAHqzMyYKWo=; b=AcPJHbmYNrAdqm372w5SZKzEky0RaHsJK7p8m2vHctjtRdUZUX4ow1Yf snMPvaNcEfAn6/XhYzzRd81r4gcN6o0Ue3VFYp2uEL5e/wwDpLz7437Qz gM0LK4WKn5pDH9XUo0SSLjHXD+xTudGbFKpzEXn7dxdzeiHzs4bc46PfE Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFACegJlKtJXHB/2dsb2JhbABbgwc1SwaDKL4VF4EUFnSCJAEBAQMBIxFDAgUHBAIBBgIRAQMBAQECAgYdAwICAh8RFAECBggCBA4FCAGHZwMJBgcFjEWbTIhIDYhlgSmLYII8FhsHBoJjNIEAA5YMgxiLCIUvgyCBaiQc X-IronPort-AV: E=Sophos;i="4.89,1017,1367971200"; d="scan'208";a="255250150" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 04 Sep 2013 02:57:09 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r842v8UI011496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 02:57:08 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 21:57:08 -0500 From: "Nobo Akiya (nobo)" To: Tom Sanders Subject: RE: New Version Notification for draft-akiya-bfd-seamless-base-01.txt Thread-Topic: New Version Notification for draft-akiya-bfd-seamless-base-01.txt Thread-Index: AQHOnn5l/+pr3RmCiUeQmy2G0jO595mfwJTggBTY34CAAE9PAA== Date: Wed, 4 Sep 2013 02:57:08 +0000 Message-ID: References: <20130821145447.28106.64314.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.84] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "David Ward \(wardd\)" , "rtg-bfd@ietf.org" , "Carlos Pignataro \(cpignata\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 02:57:15 -0000 SGkgVG9tLA0KDQpUaGFuayB5b3UgZm9yIHJlYWRpbmcgYW5kIGNvbW1lbnRpbmcgb24gdGhpcyBk b2N1bWVudCENCg0KPiBBbSBpIGNvcnJlY3QgaW4gc2F5aW5nIHRoYXQgdGhlIG1haW4gaWRlYSBi ZWhpbmQgdGhlIGRyYWZ0IGlzIHRvIGNyZWF0ZQ0KPiBwc2V1ZG8gcmVmbGVjdG9yIEJGRCBzZXNz aW9ucyB0aGF0IHJlc3BvbmQgdG8gdGhlIGluY29taW5nIEJGRCBwYWNrZXRzDQo+IHdpdGhvdXQg bWFpbnRhaW5pbmcgYW55IEJGRCBuZWlnaGJvciBzdGF0ZSBtYWNoaW5lPyBBcyBhIHJlc3VsdCBp dHMgb25seQ0KPiB0aGUgbm9kZXMgdGhhdCBpbml0aWF0ZSBCRkQgcGFja2V0cyB0aGF0IG5lZWQg dG8gbWFpbnRhaW4gdGhlIHNlc3Npb24gc3RhdGU7DQo+IHRoZSByZWZsZWN0b3IgQkZEIG5vZGVz IGFyZSBlc3NlbnRpYWxseSBzdGF0ZWxlc3MuDQoNClNlYW1sZXNzIEJGRCBpcyBzb3J0IG9mIGxp a2UgYmVpbmcgYWJsZSB0byBkbyBCRkQgZWNobyBvdmVyIHNpbmdsZS1ob3AvbXVsdGktaG9wL0lQ L01QTFMvU1IsIGV4Y2VwdCB5b3UgYXJlIHVzaW5nIEJGRCBjb250cm9sIHBhY2tldHMgJiBzZW5k ZXIgY2FuIG9ubHkgZ2V0IHJlc3BvbnNlIGJhY2sgaWYgdHJhbnNtaXR0ZWQgcGFja2V0ICJ1LXR1 cm5zIiBhdCBleHBlY3RlZCBuZXR3b3JrIG5vZGUuIFNvIHllcywgd2hhdCB5b3Ugc3RhdGVkIGlz IGFic29sdXRlbHkgY29ycmVjdC4NCg0KPiBXaGlsZSBpIGNhbiBzZWUgdGhlIGFkdmFudGFnZSB0 byBzb21lIGV4dGVudCwgaSBhbSByZWFsbHkgbm90IHN1cmUgaWYgd2UNCj4gaW5kZWVkIG5lZWQg c3VjaCBhbiBleHRlbnNpb24gdG8gQkZEISBJcyBtYWludGFpbmluZyBCRkQgc2Vzc2lvbiBzdGF0 ZQ0KPiByZWFsbHkgaGFyZCB3aGVuIGRvaW5nIEJGRCBpbiBBU0lDcz8NCg0KTWFpbnRhaW5pbmcg bGVzcyBCRkQgc2Vzc2lvbiBzdGF0ZSBpcyBqdXN0IGEgc2lkZSBlZmZlY3QgaW4gc29tZSBjYXNl cy4NCg0KUHJvcG9zYWwgYnJpbmdzIGZvcnRoIHNldmVyYWwgYmVuZWZpdHMuDQoNCjEuIFByb3Zp ZGVzIGdyZWF0IGNvbnRyb2wgdG8gaW5pdGlhdG9yLg0KICAtIFJlYWNoYWJpbGl0eSB2YWxpZGF0 aW9uIGlzIHZpcnR1YWxseSBpbW1lZGlhdGUgYXMgc2Vzc2lvbiBicmluZ3VwL2Jvb3RzdHJhcCBz ZXF1ZW5jZXMgYXJlIG5vIGxvbmdlciByZXF1aXJlZC4NCiAgLSBJbml0aWF0b3IgY2FuIGNob29z ZSB0byBzdXNwZWN0L3Jlc3VtZSBhdCBpdHMgb3duIHdpbGwgd2l0aG91dCBhZmZlY3RpbmcgcGVl ciBzdGF0ZS4gDQoNCjIuIFNlc3Npb24gbm8gbG9uZ2VyIHRpZWQgdG8gcGFpciBvZiBhZGRyZXNz ZXMuDQogIC0gSW1hZ2luZSBtdWx0aXBsZSB1bm51bWJlcmVkIHR1bm5lbHMgKGV4OiBHUkUpIGJl dHdlZW4gYSBwYWlyIG9mIGxvb3BiYWNrcywgY2FuJ3QgZG8gaXQgd2l0aCBSRkM1ODgxLCB2ZXJ5 IGRpZmZpY3VsdCB3aXRoIFJGQzU4ODMuDQogIC0gQWxsb3dpbmcgQkZEIHJlZHVuZGFuY3kgKGV4 OiBoYXZpbmcgbXVsdGlwbGUgc2Vzc2lvbnMgcGVyIHBhaXIgb2YgYWRkcmVzc2VzKSBpcyBhIGdy ZWF0IGJlbmVmaXQgdG8gcHJvZHVjdHMgd2l0aCBkaXN0cmlidXRlZCBCRkQgYXJjaGl0ZWN0dXJl Lg0KDQozLiBTZXBhcmF0aW9uIG9mIHRyYW5zcG9ydCAoSVAgZHN0IG9yIGxhYmVsIHN0YWNrKSBh bmQgdGFyZ2V0ICh5b3VyIGRpc2NyaW1pbmF0b3IpLg0KICAtIFJlYWNoYWJpbGl0eSBjaGVjayBk b2VzIG5vdCBhbHdheXMgaGF2ZSB0byBiZSBlbmQtdG8tZW5kLg0KDQo0LiBMZXZlbCBvZiBNUExT IGxhYmVsIHZlcmlmaWNhdGlvbi4NCiAgLSBUaGlzIGlzIGEgdG9waWMgbm90IHlldCB3aWRlbHkg ZGlzY3Vzc2VkIChmcm9tIHdoYXQgSSBjYW4gdGVsbCksIGJ1dCBCRkQgYmVpbmcgYWJsZSB0byBw ZXJmb3JtIEFkaiBTSUQgZm9yd2FyZGluZyBjb3JyZWN0bmVzcyBhZGRzIGdyZWF0IHZhbHVlIHRv IFNlZ21lbnQgUm91dGluZy4NCg0KT2YgY291cnNlLCBhcyB5b3Ugc3RhdGVkLCBlZ3Jlc3Mgc3Rh dGUgbWFpbnRlbmFuY2UgaXMgZXNzZW50aWFsbHkgbm90IHJlcXVpcmVkIGZvciB1bmktZGlyZWN0 aW9uYWwgcmVhY2hhYmlsaXR5IGNoZWNrIHNjZW5hcmlvcyAoc3RhdGljIHJvdXRlLCB1bmktZGly ZWN0aW9uYWwgdHVubmVsL0xTUCkuDQoNCkFuZCBvbmUgb2YgbXkgcGVyc29uYWwgZmF2b3JpdGUg YWJvdXQgdGhpcyBwcm9wb3NhbCBpcyB0aGUgZmFjdCBpdCBiZWNvbWVzIGEgYnVpbGRpbmcgYmxv Y2sgZm9yIGZ1cnRoZXIgaW50ZXJlc3RpbmcgcG9zc2liaWxpdGllcy4NCg0KPiBXb3VsZCBsb3Zl IHRvIGhlYXIgd2hhdCBvdGhlcnMgaGF2ZSB0byBzYXkgaGVyZS4NCg0KTWUgdG9vLg0KDQotIE5v Ym8NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUb20gU2FuZGVycyBb bWFpbHRvOnRvbXMuc2FuZGVyc0BnbWFpbC5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJl ciAwMywgMjAxMyAxMjoxOSBQTQ0KPiBUbzogTm9ibyBBa2l5YSAobm9ibykNCj4gQ2M6IHJ0Zy1i ZmRAaWV0Zi5vcmc7IERhdmlkIFdhcmQgKHdhcmRkKTsgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25h dGEpDQo+IFN1YmplY3Q6IFJlOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFr aXlhLWJmZC1zZWFtbGVzcy1iYXNlLQ0KPiAwMS50eHQNCj4gDQo+IE5vYm8gZXQuIGFsLA0KPiAN Cj4gQW0gaSBjb3JyZWN0IGluIHNheWluZyB0aGF0IHRoZSBtYWluIGlkZWEgYmVoaW5kIHRoZSBk cmFmdCBpcyB0byBjcmVhdGUNCj4gcHNldWRvIHJlZmxlY3RvciBCRkQgc2Vzc2lvbnMgdGhhdCBy ZXNwb25kIHRvIHRoZSBpbmNvbWluZyBCRkQgcGFja2V0cw0KPiB3aXRob3V0IG1haW50YWluaW5n IGFueSBCRkQgbmVpZ2hib3Igc3RhdGUgbWFjaGluZT8gQXMgYSByZXN1bHQgaXRzIG9ubHkNCj4g dGhlIG5vZGVzIHRoYXQgaW5pdGlhdGUgQkZEIHBhY2tldHMgdGhhdCBuZWVkIHRvIG1haW50YWlu IHRoZSBzZXNzaW9uIHN0YXRlOw0KPiB0aGUgcmVmbGVjdG9yIEJGRCBub2RlcyBhcmUgZXNzZW50 aWFsbHkgc3RhdGVsZXNzLg0KPiANCj4gV2hpbGUgaSBjYW4gc2VlIHRoZSBhZHZhbnRhZ2UgdG8g c29tZSBleHRlbnQsIGkgYW0gcmVhbGx5IG5vdCBzdXJlIGlmIHdlDQo+IGluZGVlZCBuZWVkIHN1 Y2ggYW4gZXh0ZW5zaW9uIHRvIEJGRCEgSXMgbWFpbnRhaW5pbmcgQkZEIHNlc3Npb24gc3RhdGUN Cj4gcmVhbGx5IGhhcmQgd2hlbiBkb2luZyBCRkQgaW4gQVNJQ3M/IFdvdWxkIGxvdmUgdG8gaGVh ciB3aGF0IG90aGVycyBoYXZlDQo+IHRvIHNheSBoZXJlLg0KPiANCj4gVG9tcw0KPiANCj4gT24g MjEgQXVndXN0IDIwMTMgMjA6NTEsIE5vYm8gQWtpeWEgKG5vYm8pIDxub2JvQGNpc2NvLmNvbT4g d3JvdGU6DQo+IA0KPiBIZWxsbyBCRkQgV0cgTWVtYmVycywNCj4gDQo+IFdlIGhhdmUgcHVibGlz aGVkIFMtQkZEIEJhc2UgLTAxLg0KPiANCj4gVVJMOiDCoCDCoCDCoCDCoCDCoCDCoCBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtDQo+ IGJhc2UtMDEudHh0DQo+IFN0YXR1czogwqAgwqAgwqAgwqAgwqBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1iYXNlDQo+IEh0bWxpemVkOiDC oCDCoCDCoCDCoGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFraXlhLWJmZC1zZWFt bGVzcy1iYXNlLTAxDQo+IERpZmY6IMKgIMKgIMKgIMKgIMKgIMKgaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtDQo+IDAxDQo+IA0K PiBXZSBoYXZlIHJld29yZGVkIHNldmVyYWwgc2VjdGlvbnMgdG8gaW1wcm92ZSB0aGUgcmVhZGFi aWxpdHkgYXNwZWN0Lg0KPiBUaGVyZSBhcmUgZmV3IHRlY2huaWNhbCBjaGFuZ2VzIGFzIHdlbGwu IElmIHlvdSBoYXZlIHJlYWQgLTAxLCBwbGVhc2UgdmlzaXQNCj4gdGhlIGRpZmYgbGluayB0byBz ZWUgd2hhdCBoYXMgY2hhbmdlZC4NCj4gDQo+IEF1dGhvcnMgYXJlIGxvb2tpbmcgaW50byB2YXJp b3VzIGFzcGVjdHMgb2YgUy1CRkQgbmV4dC4gQ2FybG9zIGFuZCBteXNlbGYNCj4gd2lsbCBiZSBs b29raW5nIGludG8gZnVydGhlciBkZWZpbmluZyBTZWdtZW50IFJvdXRpbmcgc2NlbmFyaW9zIChT LUJGRCBTUg0KPiBkcmFmdCkgYW5kIHdpbGwgYmUgc2Vla2luZyBzb21lIGhlbHAgdG8gb24gdGhh dCBmcm9udC4gQW5kIHByb2dyZXNzIG9mIHRoYXQNCj4gcmVxdWlyZXMgdGhlICJiYXNlIiB0byBi ZSBzb2xpZGlmaWVkLCBhbmQgd2UgYXJlIG5lZWQgeW91ciBoZWxwLiBQbGVhc2UNCj4gcG9pbnQg b3V0IGFueXRoaW5nIHRoYXQgaXMgdW5jbGVhciwgY29uZnVzaW5nIGFuZC9vciBxdWVzdGlvbmFi bGUuDQo+IA0KPiBSZWdhcmRzLA0KPiBBdXRob3JzDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDIxLCAy MDEzIDEwOjU1IEFNDQo+ID4gVG86IERhdmlkIFdhcmQgKHdhcmRkKTsgTWFuYXYgQmhhdGlhOyBE YXZpZCBXYXJkICh3YXJkZCk7IENhcmxvcw0KPiA+IFBpZ25hdGFybyAoY3BpZ25hdGEpOyBOb2Jv IEFraXlhIChub2JvKQ0KPiA+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtDQo+IDAxLnR4dA0KPiA+DQo+ID4NCj4gPiBB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtMDEudHh0 DQo+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBOb2JvIEFraXlhIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYNCj4gPiByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gRmlsZW5hbWU6IMKg IMKgIMKgZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UNCj4gPiBSZXZpc2lvbjogwqAgwqAg wqAwMQ0KPiA+IFRpdGxlOiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTZWFtbGVzcyBCaWRpcmVj dGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIHdpdGgNCj4gPiBNUExTIExhYmVsIFZl cmlmaWNhdGlvbiBFeHRlbnNpb24NCj4gPiBDcmVhdGlvbiBkYXRlOiDCoCDCoCDCoCDCoCAyMDEz LTA4LTIxDQo+ID4gR3JvdXA6IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KPiA+IE51bWJlciBvZiBwYWdlczogMjANCj4gPiBVUkw6IMKgIMKgIMKgIMKgIMKg IMKgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFraXlhLWJmZC1z ZWFtbGVzcy0NCj4gPiBiYXNlLTAxLnR4dA0KPiA+IFN0YXR1czogwqAgwqAgwqAgwqAgwqBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1iYXNl DQo+ID4gSHRtbGl6ZWQ6IMKgIMKgIMKgIMKgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtMDENCj4gPiBEaWZmOiDCoCDCoCDCoCDCoCDCoCDC oGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWFraXlhLWJmZC1zZWFtbGVz cy0NCj4gYmFzZS0NCj4gPiAwMQ0KPiA+DQo+ID4gQWJzdHJhY3Q6DQo+ID4gwqAgwqBUaGlzIGRv Y3VtZW50IGRlZmluZXMgYSBzaW1wbGlmaWVkIG1lY2hhbmlzbSB0byB1c2UgQmlkaXJlY3Rpb25h bA0KPiA+IMKgIMKgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgd2l0aCBsYXJnZSBwb3J0aW9u cyBvZiBuZWdvdGlhdGlvbiBhc3BlY3RzDQo+ID4gwqAgwqBlbGltaW5hdGVkLCB0aGF0IGFsbG93 cyBmdWxsIGFuZCBwYXJ0aWFsIHJlYWNoYWJpbGl0eSB2ZXJpZmljYXRpb24uDQo+ID4gwqAgwqBG b3IgTVBMUyBiYXNlZCBCRkQsIGV4dGVuc2lvbnMgdG8gdGhlIGdlbmVyaWMgbWVjaGFuaXNtIGFy ZSBkZWZpbmVkDQo+ID4gwqAgwqB0aGF0IGFsbG93cyBCRkQgdG8gcGVyZm9ybSBhIGxldmVsIG9m IGxhYmVsIHZlcmlmaWNhdGlvbi4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2YNCj4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQNCj4gdG9vbHMuaWV0Zi5vcmcuDQo+ID4NCj4gPiBUaGUgSUVURiBTZWNy ZXRhcmlhdA0KPiANCj4gDQo+IA0KPiANCj4gLS0NCj4gVG9tcy4NCg== From gregory.mirsky@ericsson.com Fri Sep 6 09:02:25 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4185521E8103 for ; Fri, 6 Sep 2013 09:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 lHB4yXom-VjJ for ; Fri, 6 Sep 2013 09:02:16 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 177B721E80C2 for ; Fri, 6 Sep 2013 09:01:29 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-05-5229fc589c5a Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 20.CF.09414.85CF9225; Fri, 6 Sep 2013 18:01:28 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Fri, 6 Sep 2013 12:01:24 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , Tom Sanders Subject: RE: New Version Notification for draft-akiya-bfd-seamless-base-01.txt Thread-Topic: New Version Notification for draft-akiya-bfd-seamless-base-01.txt Thread-Index: AQHOnn5l/+pr3RmCiUeQmy2G0jO595mfwJTggBTIG4CAALJFAIADtw/Q Date: Fri, 6 Sep 2013 16:01:23 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B6E67F4@eusaamb103.ericsson.se> References: <20130821145447.28106.64314.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B6E67F4eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPoG7EH80gg2nbTS0+vdvBYjG7I97i 859tjBZXP61kslg8WcqB1WPK742sHjtn3WX3WLLkJ1MAcxSXTUpqTmZZapG+XQJXxrLfS1kL btxgrDh15wpjA+OfS4xdjJwcEgImEm9/rWOFsMUkLtxbz9bFyMUhJHCUUeLskxeMEM4yRolp a04wg1SxCRhJvNjYww5iiwj4SZzufQVWxCzQziix+OodsISwQIDE0isToYoCJf6/vMkKYbtJ PL23ByzOIqAisfnMEjYQm1fAV2LetVvMENv6mCSOX2kA28YJlLh5dwVYAyPQfd9PrWECsZkF xCVuPZnPBHG3gMSSPeeZIWxRiZeP/0H9oyyx5Ml+Foj6fInLW2CWCUqcnPmEZQKj6Cwko2Yh KZuFpGwWIwdQXFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2LkKC1OLctNNzLYxAiMwGMS bLo7GPe8tDzEKM3BoiTOu0rvTKCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxuQFm30ux/6Y Eiw1k7niuK9Jq1TRxhKZ/ZbPCgWf/bXyPB/bJZgvE7Opkavnu+fEWxlPcg/mlc9z/Hpl3bSN iYYbTX8wXzi7Nm+Z5mH7B78WvXvIw9en8Ux5yaP7V+wvC91iEHqxiUvgYN3nK/U/fmtOZ79V sFg7/t30HdsKF7m+b9smofbydJUSS3FGoqEWc1FxIgCM2qJujgIAAA== Cc: "David Ward \(wardd\)" , "rtg-bfd@ietf.org" , "Carlos Pignataro \(cpignata\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 16:02:25 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B6E67F4eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBOb2JvLCBBdXRob3JzLCBldC4gYWwsDQpJJ2QgbGlrZSB0byBwaWNrIG9uZSBhc3BlY3Qg b2YgdGhlIGNvbnZlcnNhdGlvbi4NCiIgU2VhbWxlc3MgQkZEIGlzIHNvcnQgb2YgbGlrZSBiZWlu ZyBhYmxlIHRvIGRvIEJGRCBlY2hvIG92ZXIgc2luZ2xlLWhvcC9tdWx0aS1ob3AvSVAvTVBMUy9T UiAuLi4iDQpBbmQgaXQgY29uZmlybWVkIG15IGltcHJlc3Npb24gdGhhdCBTZWFtbGVzcyBCRkQg aWRlYSBpcyBzbyBtdWNoIEVjaG8tbGlrZS4gSGVuY2UgbXkgcXVlc3Rpb24gdG8gQXV0aG9ycyBX aHkgbm90IHRvIHVzZSBFY2hvIEJGRCBpbiB0aGUgZmlyc3QgcGxhY2U/IFlvdSd2ZSBjZXJ0YWlu bHkgY29uc2lkZXJlZCB0aGF0IGFuZCBJJ20gdmVyeSBpbnRlcmVzdGVkIHRvIGxlYXJuIHdoeSB5 b3UndmUgZGVjaWRlZCBub3QgdG8gdGFrZSB0aGlzIHBhdGguIHRydWUsIG5ldyByZWdpc3RyaWVz IG1pZ2h0IGJlIHJlcXVpcmVkIGlmIGluZm9ybWF0aW9uIGluIEJGRCBFY2hvIFJlcXVlc3QgZXhw ZWN0ZWQgdG8gYmUgcHJvY2Vzc2VkIGFuZCByZXN1bHRzIHJlcG9ydGVkIGluIEJGRCBFY2hvIFJl cGx5IGJ1dCB3ZSBrbm93IGhvdyB0byBkbyB0aGF0LCB3ZSd2ZSBkb25lIHRoYXQgbWFueSB0aW1l cyBiZWZvcmUuIFNvLCB3aHkgbm90IEJGRCBFY2hvIHRvIGFjaGlldmUgd2hhdCBTZWFtbGVzcyBC RkQgZG9lcz8NCg0KQW5kIGNvdXBsZSBtaW5vciBub3RlczoNCuKAoiAgICAgICBzZWN0aW9uIDEw LjEgb2YgZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtMDEgYW5kIHNlY3Rpb24gNyBvZiBk cmFmdC1ha2l5YS1iZmQtc2VhbWxlc3Mtc3ItMDAgcmVmZXIgdG8gRVhQIGZpZWxkIG9mIGxhYmVs IGVsZW1lbnQgaW4g4oCcKGxhYmVsIHZhbHVlICsgRVhQKeKAnSBidXQgaXQgc2hvdWxkIGJlIFRy YWZmaWMgQ2xhc3MgKFRDKSBmaWVsZCBhcyBpdCBiZWVuIHJlbmFtZWQgaW4gUkZDIDU0NjINCuKA oiAgICAgICBkb27igJl0IHNlZSBtdWNoIG9mIG5vcm1hdGl2ZSBiZWhhdmlvciBkZWZpbmVkIGlu IGRyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1zci0wMCBidXQgbW9yZSBpbmZvcm1hdGlvbmFsLiBQ ZXJoYXBzICBzb21lIHJlLWJhbGFuY2luZyB3b3JrIGJldHdlZW4gQkZELVMgYmFzZSBhbmQgQkZE LVMgZm9yIFNSIHdpbGwgaGVscC4NCg0KICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgICAg IEdyZWcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Zy1iZmQtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IE5vYm8gQWtpeWEgKG5vYm8pDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDMsIDIwMTMgNzo1 NyBQTQ0KVG86IFRvbSBTYW5kZXJzDQpDYzogRGF2aWQgV2FyZCAod2FyZGQpOyBydGctYmZkQGll dGYub3JnOyBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNClN1YmplY3Q6IFJFOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1iYXNlLTAxLnR4 dA0KDQpIaSBUb20sDQoNClRoYW5rIHlvdSBmb3IgcmVhZGluZyBhbmQgY29tbWVudGluZyBvbiB0 aGlzIGRvY3VtZW50IQ0KDQo+IEFtIGkgY29ycmVjdCBpbiBzYXlpbmcgdGhhdCB0aGUgbWFpbiBp ZGVhIGJlaGluZCB0aGUgZHJhZnQgaXMgdG8NCj4gY3JlYXRlIHBzZXVkbyByZWZsZWN0b3IgQkZE IHNlc3Npb25zIHRoYXQgcmVzcG9uZCB0byB0aGUgaW5jb21pbmcgQkZEDQo+IHBhY2tldHMgd2l0 aG91dCBtYWludGFpbmluZyBhbnkgQkZEIG5laWdoYm9yIHN0YXRlIG1hY2hpbmU/IEFzIGENCj4g cmVzdWx0IGl0cyBvbmx5IHRoZSBub2RlcyB0aGF0IGluaXRpYXRlIEJGRCBwYWNrZXRzIHRoYXQg bmVlZCB0bw0KPiBtYWludGFpbiB0aGUgc2Vzc2lvbiBzdGF0ZTsgdGhlIHJlZmxlY3RvciBCRkQg bm9kZXMgYXJlIGVzc2VudGlhbGx5IHN0YXRlbGVzcy4NCg0KU2VhbWxlc3MgQkZEIGlzIHNvcnQg b2YgbGlrZSBiZWluZyBhYmxlIHRvIGRvIEJGRCBlY2hvIG92ZXIgc2luZ2xlLWhvcC9tdWx0aS1o b3AvSVAvTVBMUy9TUiwgZXhjZXB0IHlvdSBhcmUgdXNpbmcgQkZEIGNvbnRyb2wgcGFja2V0cyAm IHNlbmRlciBjYW4gb25seSBnZXQgcmVzcG9uc2UgYmFjayBpZiB0cmFuc21pdHRlZCBwYWNrZXQg InUtdHVybnMiIGF0IGV4cGVjdGVkIG5ldHdvcmsgbm9kZS4gU28geWVzLCB3aGF0IHlvdSBzdGF0 ZWQgaXMgYWJzb2x1dGVseSBjb3JyZWN0Lg0KDQo+IFdoaWxlIGkgY2FuIHNlZSB0aGUgYWR2YW50 YWdlIHRvIHNvbWUgZXh0ZW50LCBpIGFtIHJlYWxseSBub3Qgc3VyZSBpZg0KPiB3ZSBpbmRlZWQg bmVlZCBzdWNoIGFuIGV4dGVuc2lvbiB0byBCRkQhIElzIG1haW50YWluaW5nIEJGRCBzZXNzaW9u DQo+IHN0YXRlIHJlYWxseSBoYXJkIHdoZW4gZG9pbmcgQkZEIGluIEFTSUNzPw0KDQpNYWludGFp bmluZyBsZXNzIEJGRCBzZXNzaW9uIHN0YXRlIGlzIGp1c3QgYSBzaWRlIGVmZmVjdCBpbiBzb21l IGNhc2VzLg0KDQpQcm9wb3NhbCBicmluZ3MgZm9ydGggc2V2ZXJhbCBiZW5lZml0cy4NCg0KMS4g UHJvdmlkZXMgZ3JlYXQgY29udHJvbCB0byBpbml0aWF0b3IuDQogIC0gUmVhY2hhYmlsaXR5IHZh bGlkYXRpb24gaXMgdmlydHVhbGx5IGltbWVkaWF0ZSBhcyBzZXNzaW9uIGJyaW5ndXAvYm9vdHN0 cmFwIHNlcXVlbmNlcyBhcmUgbm8gbG9uZ2VyIHJlcXVpcmVkLg0KICAtIEluaXRpYXRvciBjYW4g Y2hvb3NlIHRvIHN1c3BlY3QvcmVzdW1lIGF0IGl0cyBvd24gd2lsbCB3aXRob3V0IGFmZmVjdGlu ZyBwZWVyIHN0YXRlLg0KDQoyLiBTZXNzaW9uIG5vIGxvbmdlciB0aWVkIHRvIHBhaXIgb2YgYWRk cmVzc2VzLg0KICAtIEltYWdpbmUgbXVsdGlwbGUgdW5udW1iZXJlZCB0dW5uZWxzIChleDogR1JF KSBiZXR3ZWVuIGEgcGFpciBvZiBsb29wYmFja3MsIGNhbid0IGRvIGl0IHdpdGggUkZDNTg4MSwg dmVyeSBkaWZmaWN1bHQgd2l0aCBSRkM1ODgzLg0KICAtIEFsbG93aW5nIEJGRCByZWR1bmRhbmN5 IChleDogaGF2aW5nIG11bHRpcGxlIHNlc3Npb25zIHBlciBwYWlyIG9mIGFkZHJlc3NlcykgaXMg YSBncmVhdCBiZW5lZml0IHRvIHByb2R1Y3RzIHdpdGggZGlzdHJpYnV0ZWQgQkZEIGFyY2hpdGVj dHVyZS4NCg0KMy4gU2VwYXJhdGlvbiBvZiB0cmFuc3BvcnQgKElQIGRzdCBvciBsYWJlbCBzdGFj aykgYW5kIHRhcmdldCAoeW91ciBkaXNjcmltaW5hdG9yKS4NCiAgLSBSZWFjaGFiaWxpdHkgY2hl Y2sgZG9lcyBub3QgYWx3YXlzIGhhdmUgdG8gYmUgZW5kLXRvLWVuZC4NCg0KNC4gTGV2ZWwgb2Yg TVBMUyBsYWJlbCB2ZXJpZmljYXRpb24uDQogIC0gVGhpcyBpcyBhIHRvcGljIG5vdCB5ZXQgd2lk ZWx5IGRpc2N1c3NlZCAoZnJvbSB3aGF0IEkgY2FuIHRlbGwpLCBidXQgQkZEIGJlaW5nIGFibGUg dG8gcGVyZm9ybSBBZGogU0lEIGZvcndhcmRpbmcgY29ycmVjdG5lc3MgYWRkcyBncmVhdCB2YWx1 ZSB0byBTZWdtZW50IFJvdXRpbmcuDQoNCk9mIGNvdXJzZSwgYXMgeW91IHN0YXRlZCwgZWdyZXNz IHN0YXRlIG1haW50ZW5hbmNlIGlzIGVzc2VudGlhbGx5IG5vdCByZXF1aXJlZCBmb3IgdW5pLWRp cmVjdGlvbmFsIHJlYWNoYWJpbGl0eSBjaGVjayBzY2VuYXJpb3MgKHN0YXRpYyByb3V0ZSwgdW5p LWRpcmVjdGlvbmFsIHR1bm5lbC9MU1ApLg0KDQpBbmQgb25lIG9mIG15IHBlcnNvbmFsIGZhdm9y aXRlIGFib3V0IHRoaXMgcHJvcG9zYWwgaXMgdGhlIGZhY3QgaXQgYmVjb21lcyBhIGJ1aWxkaW5n IGJsb2NrIGZvciBmdXJ0aGVyIGludGVyZXN0aW5nIHBvc3NpYmlsaXRpZXMuDQoNCj4gV291bGQg bG92ZSB0byBoZWFyIHdoYXQgb3RoZXJzIGhhdmUgdG8gc2F5IGhlcmUuDQoNCk1lIHRvby4NCg0K LSBOb2JvDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVG9tIFNhbmRl cnMgW21haWx0bzp0b21zLnNhbmRlcnNAZ21haWwuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBTZXB0 ZW1iZXIgMDMsIDIwMTMgMTI6MTkgUE0NCj4gVG86IE5vYm8gQWtpeWEgKG5vYm8pDQo+IENjOiBy dGctYmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3JnPjsgRGF2aWQgV2FyZCAod2Fy ZGQpOyBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNCj4gU3ViamVjdDogUmU6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtIDAx LnR4dA0KPg0KPiBOb2JvIGV0LiBhbCwNCj4NCj4gQW0gaSBjb3JyZWN0IGluIHNheWluZyB0aGF0 IHRoZSBtYWluIGlkZWEgYmVoaW5kIHRoZSBkcmFmdCBpcyB0bw0KPiBjcmVhdGUgcHNldWRvIHJl ZmxlY3RvciBCRkQgc2Vzc2lvbnMgdGhhdCByZXNwb25kIHRvIHRoZSBpbmNvbWluZyBCRkQNCj4g cGFja2V0cyB3aXRob3V0IG1haW50YWluaW5nIGFueSBCRkQgbmVpZ2hib3Igc3RhdGUgbWFjaGlu ZT8gQXMgYQ0KPiByZXN1bHQgaXRzIG9ubHkgdGhlIG5vZGVzIHRoYXQgaW5pdGlhdGUgQkZEIHBh Y2tldHMgdGhhdCBuZWVkIHRvDQo+IG1haW50YWluIHRoZSBzZXNzaW9uIHN0YXRlOyB0aGUgcmVm bGVjdG9yIEJGRCBub2RlcyBhcmUgZXNzZW50aWFsbHkgc3RhdGVsZXNzLg0KPg0KPiBXaGlsZSBp IGNhbiBzZWUgdGhlIGFkdmFudGFnZSB0byBzb21lIGV4dGVudCwgaSBhbSByZWFsbHkgbm90IHN1 cmUgaWYNCj4gd2UgaW5kZWVkIG5lZWQgc3VjaCBhbiBleHRlbnNpb24gdG8gQkZEISBJcyBtYWlu dGFpbmluZyBCRkQgc2Vzc2lvbg0KPiBzdGF0ZSByZWFsbHkgaGFyZCB3aGVuIGRvaW5nIEJGRCBp biBBU0lDcz8gV291bGQgbG92ZSB0byBoZWFyIHdoYXQNCj4gb3RoZXJzIGhhdmUgdG8gc2F5IGhl cmUuDQo+DQo+IFRvbXMNCj4NCj4gT24gMjEgQXVndXN0IDIwMTMgMjA6NTEsIE5vYm8gQWtpeWEg KG5vYm8pIDxub2JvQGNpc2NvLmNvbTxtYWlsdG86bm9ib0BjaXNjby5jb20+PiB3cm90ZToNCj4N Cj4gSGVsbG8gQkZEIFdHIE1lbWJlcnMsDQo+DQo+IFdlIGhhdmUgcHVibGlzaGVkIFMtQkZEIEJh c2UgLTAxLg0KPg0KPiBVUkw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy0NCj4gYmFzZS0wMS50eHQNCj4gU3RhdHVzOg0KPiBo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1i YXNlDQo+IEh0bWxpemVkOg0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ha2l5 YS1iZmQtc2VhbWxlc3MtYmFzZS0wMQ0KPiBEaWZmOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtYmFzZS0NCj4gMDENCj4NCj4gV2Ug aGF2ZSByZXdvcmRlZCBzZXZlcmFsIHNlY3Rpb25zIHRvIGltcHJvdmUgdGhlIHJlYWRhYmlsaXR5 IGFzcGVjdC4NCj4gVGhlcmUgYXJlIGZldyB0ZWNobmljYWwgY2hhbmdlcyBhcyB3ZWxsLiBJZiB5 b3UgaGF2ZSByZWFkIC0wMSwgcGxlYXNlDQo+IHZpc2l0IHRoZSBkaWZmIGxpbmsgdG8gc2VlIHdo YXQgaGFzIGNoYW5nZWQuDQo+DQo+IEF1dGhvcnMgYXJlIGxvb2tpbmcgaW50byB2YXJpb3VzIGFz cGVjdHMgb2YgUy1CRkQgbmV4dC4gQ2FybG9zIGFuZA0KPiBteXNlbGYgd2lsbCBiZSBsb29raW5n IGludG8gZnVydGhlciBkZWZpbmluZyBTZWdtZW50IFJvdXRpbmcgc2NlbmFyaW9zDQo+IChTLUJG RCBTUg0KPiBkcmFmdCkgYW5kIHdpbGwgYmUgc2Vla2luZyBzb21lIGhlbHAgdG8gb24gdGhhdCBm cm9udC4gQW5kIHByb2dyZXNzIG9mDQo+IHRoYXQgcmVxdWlyZXMgdGhlICJiYXNlIiB0byBiZSBz b2xpZGlmaWVkLCBhbmQgd2UgYXJlIG5lZWQgeW91ciBoZWxwLg0KPiBQbGVhc2UgcG9pbnQgb3V0 IGFueXRoaW5nIHRoYXQgaXMgdW5jbGVhciwgY29uZnVzaW5nIGFuZC9vciBxdWVzdGlvbmFibGUu DQo+DQo+IFJlZ2FyZHMsDQo+IEF1dGhvcnMNCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPiBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gPiBT ZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyMSwgMjAxMyAxMDo1NSBBTQ0KPiA+IFRvOiBEYXZpZCBX YXJkICh3YXJkZCk7IE1hbmF2IEJoYXRpYTsgRGF2aWQgV2FyZCAod2FyZGQpOyBDYXJsb3MNCj4g PiBQaWduYXRhcm8gKGNwaWduYXRhKTsgTm9ibyBBa2l5YSAobm9ibykNCj4gPiBTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1iYXNl LQ0KPiAwMS50eHQNCj4gPg0KPiA+DQo+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWFr aXlhLWJmZC1zZWFtbGVzcy1iYXNlLTAxLnR4dA0KPiA+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgTm9ibyBBa2l5YSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGDQo+ID4gcmVwb3Np dG9yeS4NCj4gPg0KPiA+IEZpbGVuYW1lOiAgICAgIGRyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1i YXNlDQo+ID4gUmV2aXNpb246ICAgICAgMDENCj4gPiBUaXRsZTogICAgICAgICAgICAgICAgIFNl YW1sZXNzIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24NCj4gPiAoQkZEKSB3aXRo IE1QTFMgTGFiZWwgVmVyaWZpY2F0aW9uIEV4dGVuc2lvbiBDcmVhdGlvbiBkYXRlOg0KPiA+IDIw MTMtMDgtMjENCj4gPiBHcm91cDogICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lv biBOdW1iZXIgb2YgcGFnZXM6IDIwDQo+ID4gVVJMOg0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy0NCj4gPiBiYXNlLTAxLnR4 dA0KPiA+IFN0YXR1czoNCj4gPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWFraXlhLWJmZC1zZWFtbGVzcy1iYXNlDQo+ID4gSHRtbGl6ZWQ6DQo+ID4gaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtMDENCj4gPiBEaWZm Og0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWFraXlhLWJmZC1z ZWFtbGVzcy0NCj4gYmFzZS0NCj4gPiAwMQ0KPiA+DQo+ID4gQWJzdHJhY3Q6DQo+ID4gICAgVGhp cyBkb2N1bWVudCBkZWZpbmVzIGEgc2ltcGxpZmllZCBtZWNoYW5pc20gdG8gdXNlIEJpZGlyZWN0 aW9uYWwNCj4gPiAgICBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSB3aXRoIGxhcmdlIHBvcnRp b25zIG9mIG5lZ290aWF0aW9uDQo+ID4gYXNwZWN0cw0KPiA+ICAgIGVsaW1pbmF0ZWQsIHRoYXQg YWxsb3dzIGZ1bGwgYW5kIHBhcnRpYWwgcmVhY2hhYmlsaXR5IHZlcmlmaWNhdGlvbi4NCj4gPiAg ICBGb3IgTVBMUyBiYXNlZCBCRkQsIGV4dGVuc2lvbnMgdG8gdGhlIGdlbmVyaWMgbWVjaGFuaXNt IGFyZQ0KPiA+IGRlZmluZWQNCj4gPiAgICB0aGF0IGFsbG93cyBCRkQgdG8gcGVyZm9ybSBhIGxl dmVsIG9mIGxhYmVsIHZlcmlmaWNhdGlvbi4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4g UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2YNCj4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gdG9vbHMuaWV0Zi5vcmcuDQo+ID4NCj4gPiBUaGUgSUVU RiBTZWNyZXRhcmlhdA0KPg0KPg0KPg0KPg0KPiAtLQ0KPiBUb21zLg0KDQo= --_000_7347100B5761DC41A166AC17F22DF1121B6E67F4eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+RGVhciBOb2JvLCBBdXRob3JzLCBldC4gYWwsPC9k aXY+DQo8ZGl2PkknZCBsaWtlIHRvIHBpY2sgb25lIGFzcGVjdCBvZiB0aGUgY29udmVyc2F0aW9u LjwvZGl2Pg0KPGRpdj4mcXVvdDsgU2VhbWxlc3MgQkZEIGlzIHNvcnQgb2YgbGlrZSBiZWluZyBh YmxlIHRvIGRvIEJGRCBlY2hvIG92ZXIgc2luZ2xlLWhvcC9tdWx0aS1ob3AvSVAvTVBMUy9TUiAu Li4mcXVvdDs8L2Rpdj4NCjxkaXY+QW5kIGl0IGNvbmZpcm1lZCBteSBpbXByZXNzaW9uIHRoYXQg U2VhbWxlc3MgQkZEIGlkZWEgaXMgc28gbXVjaCBFY2hvLWxpa2UuIEhlbmNlIG15IHF1ZXN0aW9u IHRvIEF1dGhvcnMgV2h5IG5vdCB0byB1c2UgRWNobyBCRkQgaW4gdGhlIGZpcnN0IHBsYWNlPyBZ b3UndmUgY2VydGFpbmx5IGNvbnNpZGVyZWQgdGhhdCBhbmQgSSdtIHZlcnkgaW50ZXJlc3RlZCB0 byBsZWFybiB3aHkgeW91J3ZlIGRlY2lkZWQgbm90IHRvIHRha2UgdGhpcyBwYXRoLg0KdHJ1ZSwg bmV3IHJlZ2lzdHJpZXMgbWlnaHQgYmUgcmVxdWlyZWQgaWYgaW5mb3JtYXRpb24gaW4gQkZEIEVj aG8gUmVxdWVzdCBleHBlY3RlZCB0byBiZSBwcm9jZXNzZWQgYW5kIHJlc3VsdHMgcmVwb3J0ZWQg aW4gQkZEIEVjaG8gUmVwbHkgYnV0IHdlIGtub3cgaG93IHRvIGRvIHRoYXQsIHdlJ3ZlIGRvbmUg dGhhdCBtYW55IHRpbWVzIGJlZm9yZS4gU28sIHdoeSBub3QgQkZEIEVjaG8gdG8gYWNoaWV2ZSB3 aGF0IFNlYW1sZXNzIEJGRCBkb2VzPzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+QW5k IGNvdXBsZSBtaW5vciBub3Rlczo8L2Rpdj4NCjx1bCBzdHlsZT0ibWFyZ2luOjA7cGFkZGluZy1s ZWZ0OjM2cHQ7Ij4NCjxsaT5zZWN0aW9uIDEwLjEgb2YgZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNz LWJhc2UtMDEgYW5kIHNlY3Rpb24gNyBvZiBkcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3Mtc3ItMDAg cmVmZXIgdG8gRVhQIGZpZWxkIG9mIGxhYmVsIGVsZW1lbnQgaW4g4oCcKGxhYmVsIHZhbHVlICYj NDM7IEVYUCnigJ0gYnV0IGl0IHNob3VsZCBiZSBUcmFmZmljIENsYXNzIChUQykgZmllbGQgYXMg aXQgYmVlbiByZW5hbWVkIGluIFJGQyA1NDYyPC9saT48bGk+ZG9u4oCZdCBzZWUgbXVjaCBvZiBu b3JtYXRpdmUgYmVoYXZpb3IgZGVmaW5lZCBpbiBkcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3Mtc3It MDAgYnV0IG1vcmUgaW5mb3JtYXRpb25hbC4gUGVyaGFwcyZuYnNwOyBzb21lIHJlLWJhbGFuY2lu ZyB3b3JrIGJldHdlZW4gQkZELVMgYmFzZSBhbmQgQkZELVMgZm9yIFNSIHdpbGwgaGVscC48L2xp PjwvdWw+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KDQpGcm9tOiBydGctYmZkLWJvdW5jZXNAaWV0Zi5v cmcgWzxhIGhyZWY9Im1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpydGct YmZkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTm9ibyBBa2l5YSAobm9ibyk8 YnI+DQoNClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwMywgMjAxMyA3OjU3IFBNPGJyPg0KDQpU bzogVG9tIFNhbmRlcnM8YnI+DQoNCkNjOiBEYXZpZCBXYXJkICh3YXJkZCk7IHJ0Zy1iZmRAaWV0 Zi5vcmc7IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKTxicj4NCg0KU3ViamVjdDogUkU6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2Ut MDEudHh0PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5IaSBUb20sPC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGFuayB5b3UgZm9yIHJlYWRpbmcgYW5kIGNvbW1lbnRpbmcg b24gdGhpcyBkb2N1bWVudCE8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsgQW0g aSBjb3JyZWN0IGluIHNheWluZyB0aGF0IHRoZSBtYWluIGlkZWEgYmVoaW5kIHRoZSBkcmFmdCBp cyB0byA8L2Rpdj4NCjxkaXY+Jmd0OyBjcmVhdGUgcHNldWRvIHJlZmxlY3RvciBCRkQgc2Vzc2lv bnMgdGhhdCByZXNwb25kIHRvIHRoZSBpbmNvbWluZyBCRkQgPC9kaXY+DQo8ZGl2PiZndDsgcGFj a2V0cyB3aXRob3V0IG1haW50YWluaW5nIGFueSBCRkQgbmVpZ2hib3Igc3RhdGUgbWFjaGluZT8g QXMgYSA8L2Rpdj4NCjxkaXY+Jmd0OyByZXN1bHQgaXRzIG9ubHkgdGhlIG5vZGVzIHRoYXQgaW5p dGlhdGUgQkZEIHBhY2tldHMgdGhhdCBuZWVkIHRvIDwvZGl2Pg0KPGRpdj4mZ3Q7IG1haW50YWlu IHRoZSBzZXNzaW9uIHN0YXRlOyB0aGUgcmVmbGVjdG9yIEJGRCBub2RlcyBhcmUgZXNzZW50aWFs bHkgc3RhdGVsZXNzLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+U2VhbWxlc3MgQkZE IGlzIHNvcnQgb2YgbGlrZSBiZWluZyBhYmxlIHRvIGRvIEJGRCBlY2hvIG92ZXIgc2luZ2xlLWhv cC9tdWx0aS1ob3AvSVAvTVBMUy9TUiwgZXhjZXB0IHlvdSBhcmUgdXNpbmcgQkZEIGNvbnRyb2wg cGFja2V0cyAmYW1wOyBzZW5kZXIgY2FuIG9ubHkgZ2V0IHJlc3BvbnNlIGJhY2sgaWYgdHJhbnNt aXR0ZWQgcGFja2V0ICZxdW90O3UtdHVybnMmcXVvdDsgYXQgZXhwZWN0ZWQgbmV0d29yayBub2Rl LiBTbyB5ZXMsIHdoYXQgeW91IHN0YXRlZA0KaXMgYWJzb2x1dGVseSBjb3JyZWN0LjwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyBXaGlsZSBpIGNhbiBzZWUgdGhlIGFkdmFudGFn ZSB0byBzb21lIGV4dGVudCwgaSBhbSByZWFsbHkgbm90IHN1cmUgaWYgPC9kaXY+DQo8ZGl2PiZn dDsgd2UgaW5kZWVkIG5lZWQgc3VjaCBhbiBleHRlbnNpb24gdG8gQkZEISBJcyBtYWludGFpbmlu ZyBCRkQgc2Vzc2lvbiA8L2Rpdj4NCjxkaXY+Jmd0OyBzdGF0ZSByZWFsbHkgaGFyZCB3aGVuIGRv aW5nIEJGRCBpbiBBU0lDcz88L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk1haW50YWlu aW5nIGxlc3MgQkZEIHNlc3Npb24gc3RhdGUgaXMganVzdCBhIHNpZGUgZWZmZWN0IGluIHNvbWUg Y2FzZXMuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5Qcm9wb3NhbCBicmluZ3MgZm9y dGggc2V2ZXJhbCBiZW5lZml0cy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PjEuIFBy b3ZpZGVzIGdyZWF0IGNvbnRyb2wgdG8gaW5pdGlhdG9yLjwvZGl2Pg0KPGRpdj4mbmJzcDsgLSBS ZWFjaGFiaWxpdHkgdmFsaWRhdGlvbiBpcyB2aXJ0dWFsbHkgaW1tZWRpYXRlIGFzIHNlc3Npb24g YnJpbmd1cC9ib290c3RyYXAgc2VxdWVuY2VzIGFyZSBubyBsb25nZXIgcmVxdWlyZWQuPC9kaXY+ DQo8ZGl2PiZuYnNwOyAtIEluaXRpYXRvciBjYW4gY2hvb3NlIHRvIHN1c3BlY3QvcmVzdW1lIGF0 IGl0cyBvd24gd2lsbCB3aXRob3V0IGFmZmVjdGluZyBwZWVyIHN0YXRlLiA8L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2PjIuIFNlc3Npb24gbm8gbG9uZ2VyIHRpZWQgdG8gcGFpciBvZiBh ZGRyZXNzZXMuPC9kaXY+DQo8ZGl2PiZuYnNwOyAtIEltYWdpbmUgbXVsdGlwbGUgdW5udW1iZXJl ZCB0dW5uZWxzIChleDogR1JFKSBiZXR3ZWVuIGEgcGFpciBvZiBsb29wYmFja3MsIGNhbid0IGRv IGl0IHdpdGggUkZDNTg4MSwgdmVyeSBkaWZmaWN1bHQgd2l0aCBSRkM1ODgzLjwvZGl2Pg0KPGRp dj4mbmJzcDsgLSBBbGxvd2luZyBCRkQgcmVkdW5kYW5jeSAoZXg6IGhhdmluZyBtdWx0aXBsZSBz ZXNzaW9ucyBwZXIgcGFpciBvZiBhZGRyZXNzZXMpIGlzIGEgZ3JlYXQgYmVuZWZpdCB0byBwcm9k dWN0cyB3aXRoIGRpc3RyaWJ1dGVkIEJGRCBhcmNoaXRlY3R1cmUuPC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj4zLiBTZXBhcmF0aW9uIG9mIHRyYW5zcG9ydCAoSVAgZHN0IG9yIGxhYmVs IHN0YWNrKSBhbmQgdGFyZ2V0ICh5b3VyIGRpc2NyaW1pbmF0b3IpLjwvZGl2Pg0KPGRpdj4mbmJz cDsgLSBSZWFjaGFiaWxpdHkgY2hlY2sgZG9lcyBub3QgYWx3YXlzIGhhdmUgdG8gYmUgZW5kLXRv LWVuZC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PjQuIExldmVsIG9mIE1QTFMgbGFi ZWwgdmVyaWZpY2F0aW9uLjwvZGl2Pg0KPGRpdj4mbmJzcDsgLSBUaGlzIGlzIGEgdG9waWMgbm90 IHlldCB3aWRlbHkgZGlzY3Vzc2VkIChmcm9tIHdoYXQgSSBjYW4gdGVsbCksIGJ1dCBCRkQgYmVp bmcgYWJsZSB0byBwZXJmb3JtIEFkaiBTSUQgZm9yd2FyZGluZyBjb3JyZWN0bmVzcyBhZGRzIGdy ZWF0IHZhbHVlIHRvIFNlZ21lbnQgUm91dGluZy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2Pk9mIGNvdXJzZSwgYXMgeW91IHN0YXRlZCwgZWdyZXNzIHN0YXRlIG1haW50ZW5hbmNlIGlz IGVzc2VudGlhbGx5IG5vdCByZXF1aXJlZCBmb3IgdW5pLWRpcmVjdGlvbmFsIHJlYWNoYWJpbGl0 eSBjaGVjayBzY2VuYXJpb3MgKHN0YXRpYyByb3V0ZSwgdW5pLWRpcmVjdGlvbmFsIHR1bm5lbC9M U1ApLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+QW5kIG9uZSBvZiBteSBwZXJzb25h bCBmYXZvcml0ZSBhYm91dCB0aGlzIHByb3Bvc2FsIGlzIHRoZSBmYWN0IGl0IGJlY29tZXMgYSBi dWlsZGluZyBibG9jayBmb3IgZnVydGhlciBpbnRlcmVzdGluZyBwb3NzaWJpbGl0aWVzLjwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyBXb3VsZCBsb3ZlIHRvIGhlYXIgd2hhdCBv dGhlcnMgaGF2ZSB0byBzYXkgaGVyZS48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk1l IHRvby48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pi0gTm9ibzwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvZGl2Pg0K PGRpdj4mZ3Q7IEZyb206IFRvbSBTYW5kZXJzIFs8YSBocmVmPSJtYWlsdG86dG9tcy5zYW5kZXJz QGdtYWlsLmNvbSI+bWFpbHRvOnRvbXMuc2FuZGVyc0BnbWFpbC5jb208L2E+XTwvZGl2Pg0KPGRp dj4mZ3Q7IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwMywgMjAxMyAxMjoxOSBQTTwvZGl2Pg0K PGRpdj4mZ3Q7IFRvOiBOb2JvIEFraXlhIChub2JvKTwvZGl2Pg0KPGRpdj4mZ3Q7IENjOiA8YSBo cmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+cnRnLWJmZEBpZXRmLm9yZzwvYT47IERhdmlk IFdhcmQgKHdhcmRkKTsgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpPC9kaXY+DQo8ZGl2PiZn dDsgU3ViamVjdDogUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgPC9kaXY+DQo8ZGl2 PiZndDsgZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtIDAxLnR4dDwvZGl2Pg0KPGRpdj4m Z3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IE5vYm8gZXQuIGFsLDwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2 Pg0KPGRpdj4mZ3Q7IEFtIGkgY29ycmVjdCBpbiBzYXlpbmcgdGhhdCB0aGUgbWFpbiBpZGVhIGJl aGluZCB0aGUgZHJhZnQgaXMgdG8gPC9kaXY+DQo8ZGl2PiZndDsgY3JlYXRlIHBzZXVkbyByZWZs ZWN0b3IgQkZEIHNlc3Npb25zIHRoYXQgcmVzcG9uZCB0byB0aGUgaW5jb21pbmcgQkZEIDwvZGl2 Pg0KPGRpdj4mZ3Q7IHBhY2tldHMgd2l0aG91dCBtYWludGFpbmluZyBhbnkgQkZEIG5laWdoYm9y IHN0YXRlIG1hY2hpbmU/IEFzIGEgPC9kaXY+DQo8ZGl2PiZndDsgcmVzdWx0IGl0cyBvbmx5IHRo ZSBub2RlcyB0aGF0IGluaXRpYXRlIEJGRCBwYWNrZXRzIHRoYXQgbmVlZCB0byA8L2Rpdj4NCjxk aXY+Jmd0OyBtYWludGFpbiB0aGUgc2Vzc2lvbiBzdGF0ZTsgdGhlIHJlZmxlY3RvciBCRkQgbm9k ZXMgYXJlIGVzc2VudGlhbGx5IHN0YXRlbGVzcy48L2Rpdj4NCjxkaXY+Jmd0OyA8L2Rpdj4NCjxk aXY+Jmd0OyBXaGlsZSBpIGNhbiBzZWUgdGhlIGFkdmFudGFnZSB0byBzb21lIGV4dGVudCwgaSBh bSByZWFsbHkgbm90IHN1cmUgaWYgPC9kaXY+DQo8ZGl2PiZndDsgd2UgaW5kZWVkIG5lZWQgc3Vj aCBhbiBleHRlbnNpb24gdG8gQkZEISBJcyBtYWludGFpbmluZyBCRkQgc2Vzc2lvbiA8L2Rpdj4N CjxkaXY+Jmd0OyBzdGF0ZSByZWFsbHkgaGFyZCB3aGVuIGRvaW5nIEJGRCBpbiBBU0lDcz8gV291 bGQgbG92ZSB0byBoZWFyIHdoYXQgPC9kaXY+DQo8ZGl2PiZndDsgb3RoZXJzIGhhdmUgdG8gc2F5 IGhlcmUuPC9kaXY+DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsgVG9tczwvZGl2Pg0KPGRp dj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IE9uIDIxIEF1Z3VzdCAyMDEzIDIwOjUxLCBOb2JvIEFr aXlhIChub2JvKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vYm9AY2lzY28uY29tIj5ub2JvQGNpc2Nv LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IEhl bGxvIEJGRCBXRyBNZW1iZXJzLDwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IFdl IGhhdmUgcHVibGlzaGVkIFMtQkZEIEJhc2UgLTAxLjwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0K PGRpdj4mZ3Q7IFVSTDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg PC9kaXY+DQo8ZGl2PiZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLSI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLTwvYT48L2Rpdj4NCjxkaXY+Jmd0 OyBiYXNlLTAxLnR4dDwvZGl2Pg0KPGRpdj4mZ3Q7IFN0YXR1czogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UiPmh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2U8L2E+ PC9kaXY+DQo8ZGl2PiZndDsgSHRtbGl6ZWQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwv ZGl2Pg0KPGRpdj4mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWFraXlhLWJmZC1zZWFtbGVzcy1iYXNlLTAxIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtYmFzZS0wMTwvYT48L2Rpdj4NCjxkaXY+Jmd0OyBEaWZm OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZGl2Pg0KPGRpdj4m Z3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWFraXlh LWJmZC1zZWFtbGVzcy1iYXNlLSI+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7IDAxPC9kaXY+ DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsgV2UgaGF2ZSByZXdvcmRlZCBzZXZlcmFsIHNl Y3Rpb25zIHRvIGltcHJvdmUgdGhlIHJlYWRhYmlsaXR5IGFzcGVjdC48L2Rpdj4NCjxkaXY+Jmd0 OyBUaGVyZSBhcmUgZmV3IHRlY2huaWNhbCBjaGFuZ2VzIGFzIHdlbGwuIElmIHlvdSBoYXZlIHJl YWQgLTAxLCBwbGVhc2UgPC9kaXY+DQo8ZGl2PiZndDsgdmlzaXQgdGhlIGRpZmYgbGluayB0byBz ZWUgd2hhdCBoYXMgY2hhbmdlZC48L2Rpdj4NCjxkaXY+Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0OyBB dXRob3JzIGFyZSBsb29raW5nIGludG8gdmFyaW91cyBhc3BlY3RzIG9mIFMtQkZEIG5leHQuIENh cmxvcyBhbmQgPC9kaXY+DQo8ZGl2PiZndDsgbXlzZWxmIHdpbGwgYmUgbG9va2luZyBpbnRvIGZ1 cnRoZXIgZGVmaW5pbmcgU2VnbWVudCBSb3V0aW5nIHNjZW5hcmlvcyA8L2Rpdj4NCjxkaXY+Jmd0 OyAoUy1CRkQgU1I8L2Rpdj4NCjxkaXY+Jmd0OyBkcmFmdCkgYW5kIHdpbGwgYmUgc2Vla2luZyBz b21lIGhlbHAgdG8gb24gdGhhdCBmcm9udC4gQW5kIHByb2dyZXNzIG9mIDwvZGl2Pg0KPGRpdj4m Z3Q7IHRoYXQgcmVxdWlyZXMgdGhlICZxdW90O2Jhc2UmcXVvdDsgdG8gYmUgc29saWRpZmllZCwg YW5kIHdlIGFyZSBuZWVkIHlvdXIgaGVscC4gPC9kaXY+DQo8ZGl2PiZndDsgUGxlYXNlIHBvaW50 IG91dCBhbnl0aGluZyB0aGF0IGlzIHVuY2xlYXIsIGNvbmZ1c2luZyBhbmQvb3IgcXVlc3Rpb25h YmxlLjwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IFJlZ2FyZHMsPC9kaXY+DQo8 ZGl2PiZndDsgQXV0aG9yczwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IEZyb206IDxh IGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPm1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+XTwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsg U2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjEsIDIwMTMgMTA6NTUgQU08L2Rpdj4NCjxkaXY+Jmd0 OyAmZ3Q7IFRvOiBEYXZpZCBXYXJkICh3YXJkZCk7IE1hbmF2IEJoYXRpYTsgRGF2aWQgV2FyZCAo d2FyZGQpOyBDYXJsb3MgPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBQaWduYXRhcm8gKGNwaWduYXRh KTsgTm9ibyBBa2l5YSAobm9ibyk8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IFN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtPC9k aXY+DQo8ZGl2PiZndDsgMDEudHh0PC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4m Z3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1ha2l5YS1iZmQtc2VhbWxlc3MtYmFzZS0wMS50eHQ8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IGhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTm9ibyBBa2l5YSBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGIDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgcmVwb3NpdG9yeS48L2Rpdj4NCjxkaXY+ Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBGaWxlbmFtZTogJm5ic3A7ICZuYnNwOyAm bmJzcDtkcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtYmFzZTwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsg UmV2aXNpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDE8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IFRp dGxlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IFNlYW1sZXNzIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gPC9kaXY+DQo8 ZGl2PiZndDsgJmd0OyAoQkZEKSB3aXRoIE1QTFMgTGFiZWwgVmVyaWZpY2F0aW9uIEV4dGVuc2lv biBDcmVhdGlvbiBkYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9kaXY+DQo8ZGl2 PiZndDsgJmd0OyAyMDEzLTA4LTIxPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBHcm91cDogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlk dWFsIFN1Ym1pc3Npb24gTnVtYmVyIG9mIHBhZ2VzOiAyMDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsg VVJMOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L2Rpdj4NCjxk aXY+Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy0iPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy08L2E+PC9kaXY+DQo8ZGl2PiZndDsgJmd0 OyBiYXNlLTAxLnR4dDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgU3RhdHVzOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyA8YSBocmVmPSJodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1iYXNl Ij5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVz cy1iYXNlPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgSHRtbGl6ZWQ6ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtMDEiPmh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1iYXNlLTAxPC9hPjwv ZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgRGlmZjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy0iPmh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy08L2E+PC9kaXY+ DQo8ZGl2PiZndDsgYmFzZS08L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IDAxPC9kaXY+DQo8ZGl2PiZn dDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgQWJzdHJhY3Q6PC9kaXY+DQo8ZGl2PiZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc2ltcGxpZmllZCBtZWNo YW5pc20gdG8gdXNlIEJpZGlyZWN0aW9uYWw8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDtGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSB3aXRoIGxhcmdlIHBvcnRpb25zIG9mIG5l Z290aWF0aW9uIDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgYXNwZWN0czwvZGl2Pg0KPGRpdj4mZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwO2VsaW1pbmF0ZWQsIHRoYXQgYWxsb3dzIGZ1bGwgYW5kIHBhcnRp YWwgcmVhY2hhYmlsaXR5IHZlcmlmaWNhdGlvbi48L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDtGb3IgTVBMUyBiYXNlZCBCRkQsIGV4dGVuc2lvbnMgdG8gdGhlIGdlbmVyaWMgbWVj aGFuaXNtIGFyZSA8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IGRlZmluZWQ8L2Rpdj4NCjxkaXY+Jmd0 OyAmZ3Q7ICZuYnNwOyAmbmJzcDt0aGF0IGFsbG93cyBCRkQgdG8gcGVyZm9ybSBhIGxldmVsIG9m IGxhYmVsIHZlcmlmaWNhdGlvbi48L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZn dDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+ DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgPC9kaXY+DQo8 ZGl2PiZndDsgJmd0OyBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQ8L2Rpdj4NCjxkaXY+Jmd0OyB0b29scy5pZXRmLm9yZy48L2Rp dj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBUaGUgSUVURiBTZWNyZXRh cmlhdDwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7 IDwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IC0tPC9kaXY+DQo8ZGl2PiZndDsg VG9tcy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF1121B6E67F4eusaamb103erics_-- From nobo@cisco.com Fri Sep 6 10:47:44 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B9F11E80F4 for ; Fri, 6 Sep 2013 10:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 XR76kRem9myw for ; Fri, 6 Sep 2013 10:47:38 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A60EA11E80F7 for ; Fri, 6 Sep 2013 10:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14660; q=dns/txt; s=iport; t=1378489658; x=1379699258; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Xl7Aok1kdiE8POI3AVyDQ//eTI/M82TghAs7rQq80J0=; b=kjwGbPsvgXRNigZVUAZtOoTcM2S5UAVHfdGoV1KV/Yg+yfgTtXuwzLMM MxZ0L7FKE9eFHh+F3B3k0a9lqg22TNCnTryTS9UekRsJY6mYrJzGRxVbd zqKs4b1jlb24vXTny+mQwlzFmpK8Eu459TVF6bjDaX2YRKDWFnhsosB45 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoFAIAUKlKtJV2Z/2dsb2JhbABbgmYhNUsGgyq+KxeBDxZ0giQBAQEEIxFDAgwEAgEGAhEBAwEBAQICBh0DAgICHxEUAQIGCAIEAQ0FCAGHZwMPAQYFkQ6bTIgrDYh7gSmLZYElgRgWGwcGgmM0gQADlgyDGIsIhS+DIIFqBxcGHA X-IronPort-AV: E=Sophos;i="4.90,855,1371081600"; d="scan'208";a="256545671" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 06 Sep 2013 17:47:37 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r86Hlbkr016099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 17:47:37 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 12:47:37 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , Tom Sanders Subject: RE: New Version Notification for draft-akiya-bfd-seamless-base-01.txt Thread-Topic: New Version Notification for draft-akiya-bfd-seamless-base-01.txt Thread-Index: AQHOnn5l/+pr3RmCiUeQmy2G0jO595mfwJTggBTY34CAAE9PAIAEYr2A//+6qWA= Date: Fri, 6 Sep 2013 17:47:36 +0000 Message-ID: References: <20130821145447.28106.64314.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B6E67F4@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B6E67F4@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "David Ward \(wardd\)" , "rtg-bfd@ietf.org" , "Carlos Pignataro \(cpignata\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 17:47:44 -0000 SGkgR3JlZywNCg0KVGhhbmsgeW91IGZvciBjb21tZW50cy4gTGV0IG1lIHN0YXJ0IHdpdGggbW9y ZSBvYnZpb3VzIHBhcnQuDQoNCklmIHdlIHdlcmUgdG8gdXNlIGV4aXN0aW5nIEJGRCBlY2hvLCB0 aGVuIC4uLg0KDQoxLiBXZSBjYW5ub3QgZG8gcHJvcG9zZWQgbWVjaGFuaXNtIGZvciBJUCBtdWx0 aWhvcCBhcyBkZXN0aW5hdGlvbiBJUCBpcyBzZWxmIChpbml0aWF0b3IpLg0KMi4gSWYgd2Ugd2Vy ZSB0byBzY29wZSB0aGUgcHJvcG9zZWQgbWVjaGFuaXNtIHRvIElQIHNpbmdsZWhvcCBhbmQgTVBM UywgaW5pdGlhdG9yIHJlY2VpdmluZyBiYWNrIEJGRCBlY2hvIGNhbm5vdCBjb25jbHVkZSB0aGF0 IHBhY2tldCB1LXR1cm5lZCBhdCBpbnRlbmRlZCBub2RlLiBGb3IgZXhhbXBsZSwgYnJva2VuIExT UCBjYXVzaW5nIHRyYW5zaXQgbm9kZSB0byBpbmNvcnJlY3RseSBwb3AgdGhlIGxhYmVsIGNhbiBj YXVzZSBwYWNrZXQgdG8gYmUgcmV0dXJuZWQgYmFjayB0byBzZW5kZXIgZHVlIHRvIGRlc3RpbmF0 aW9uIElQIGhhdmluZyBhZGRyZXNzIG9mIGluaXRpYXRvci4NCg0KVGh1cyBkZXNpcmUgZm9yIGEg bWVjaGFuaXNtIHdoZXJlIG9ubHkgaW50ZW5kZWQgdGFyZ2V0IGNhbiAidS10dXJuIiB0aGUgcGFj a2V0IG9yIHNlbmQgdGhlICJwb25nIiBwYWNrZXQuDQoNCkkga25vdyB5b3VyIHF1ZXN0aW9uIHdh cyBub3QgYWJvdXQgYWJvdmUsIGJ1dCBJIGZlbHQgdGhhdCBpdCdsbCBiZSBiZW5lZmljaWFsIHRv IHN0YXRlIHRob3NlIGZpcnN0Lg0KDQpOb3cgdG8geW91ciBhY3R1YWwgcXVlc3Rpb24gLi4uIHRo ZSByZWFzb24gd2h5IGF1dGhvcnMgZGlkIG5vdCB3YW50IHRvIGRlZmluZSBhIG5ldyBwcm90b2Nv bCBvciBldmVuIG5ldyBCRkQgcGFja2V0IGZvcm1hdCAoYXN5bmMgdjEvdjIgb3IgZWNobykgaXMg YmVjYXVzZSB3ZSB3YW50ZWQgdG8gbWF4aW1pemUgdGhlIHJldXNlIG9mIGV4aXN0aW5nIHN0YW5k YXJkICYgaW1wbGVtZW50YXRpb25zLCBhbmQgd2UgY29uY2x1ZGVkIHRoYXQgZXhpc3RpbmcgQkZE IGNvbnRyb2wgaGVhZGVyIGRlZmluaXRpb24gaXMgc3VmZmljaWVudC4gV2UgY2FuIGFkZCB0aGlz IHRvcGljIGludG8gdGhlIGRvY3VtZW50IGlmIHlvdSB0aGluayB0aGlzIHdpbGwgYmUgYmVuZWZp Y2lhbCwgbGV0IHVzIGtub3cuDQoNCj4g4oCiIHNlY3Rpb24gMTAuMSBvZiBkcmFmdC1ha2l5YS1i ZmQtc2VhbWxlc3MtYmFzZS0wMSBhbmQgc2VjdGlvbiA3IG9mIGRyYWZ0LQ0KPiBha2l5YS1iZmQt c2VhbWxlc3Mtc3ItMDAgcmVmZXIgdG8gRVhQIGZpZWxkIG9mIGxhYmVsIGVsZW1lbnQgaW4g4oCc KGxhYmVsIHZhbHVlDQo+ICsgRVhQKeKAnSBidXQgaXQgc2hvdWxkIGJlIFRyYWZmaWMgQ2xhc3Mg KFRDKSBmaWVsZCBhcyBpdCBiZWVuIHJlbmFtZWQgaW4gUkZDDQo+IDU0NjINCg0KWW91IGFyZSBy aWdodCwgdGhhbmtzIGZvciBjYXRjaGluZyB0aGlzLiBXZSB3aWxsIGNvcnJlY3QgdGhpcyBpbiBu ZXh0IHJldmlzaW9uLg0KDQo+IOKAoiBkb27igJl0IHNlZSBtdWNoIG9mIG5vcm1hdGl2ZSBiZWhh dmlvciBkZWZpbmVkIGluIGRyYWZ0LWFraXlhLWJmZC0NCj4gc2VhbWxlc3Mtc3ItMDAgYnV0IG1v cmUgaW5mb3JtYXRpb25hbC4gUGVyaGFwcyAgc29tZSByZS1iYWxhbmNpbmcgd29yaw0KPiBiZXR3 ZWVuIEJGRC1TIGJhc2UgYW5kIEJGRC1TIGZvciBTUiB3aWxsIGhlbHAuDQoNCkdvb2QgY29tbWVu dCwgeWVzIHdlIHdpbGwgd29yayBvbiB0aGlzLg0KDQpJIHdhbnQgdG8gbGVhdmUgb25lIGNvbW1l bnQgYmVmb3JlIHNlbmRpbmcgdGhpcyBlbWFpbCBvZmYuIEluIGFkZGl0aW9ucyB0byBjYXBhYmls aXRpZXMgbGlzdGVkIGFzIHJlcGx5IHRvIFRvbSwgb25jZSBhIG5ldHdvcmsgaGFzIFMtQkZEIHJl ZmxlY3Rpb24gcG9pbnRzIHNldHVwLCBCRkQgcmVhbGx5IGJlY29tZXMgYW4gaW5mcmFzdHJ1Y3R1 cmUgd2hlcmUgZnJlZWRvbSBhbmQgZmxleGliaWxpdHkgYXJlIHByb3ZpZGVkIHRvIGFueSBpbml0 aWF0b3JzIG9uIHdoYXQgY2FuIGJlIGRvbmUuIEFsZXJ0IGRpc2NyaW1pbmF0b3IgZG9jdW1lbnQg aXMganVzdCBvbmUgZXhhbXBsZS4gVGhpcyB1bHRpbWF0ZWx5IHdpbGwgcHJvdmlkZSBiZXR0ZXIg cHJvdGVjdGlvbnMgYW5kIHNlcnZpY2VzIGJ5IHRoZSBCRkQgcHJvdG9jb2wuDQoNCi1Ob2JvDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogR3JlZ29yeSBNaXJza3kgW21h aWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVt YmVyIDA2LCAyMDEzIDEyOjAxIFBNDQo+IFRvOiBOb2JvIEFraXlhIChub2JvKTsgVG9tIFNhbmRl cnMNCj4gQ2M6IERhdmlkIFdhcmQgKHdhcmRkKTsgcnRnLWJmZEBpZXRmLm9yZzsgQ2FybG9zIFBp Z25hdGFybyAoY3BpZ25hdGEpDQo+IFN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1iYXNlLQ0KPiAwMS50eHQNCj4gDQo+IERl YXIgTm9ibywgQXV0aG9ycywgZXQuIGFsLA0KPiBJJ2QgbGlrZSB0byBwaWNrIG9uZSBhc3BlY3Qg b2YgdGhlIGNvbnZlcnNhdGlvbi4NCj4gIiBTZWFtbGVzcyBCRkQgaXMgc29ydCBvZiBsaWtlIGJl aW5nIGFibGUgdG8gZG8gQkZEIGVjaG8gb3ZlciBzaW5nbGUtDQo+IGhvcC9tdWx0aS1ob3AvSVAv TVBMUy9TUiAuLi4iDQo+IEFuZCBpdCBjb25maXJtZWQgbXkgaW1wcmVzc2lvbiB0aGF0IFNlYW1s ZXNzIEJGRCBpZGVhIGlzIHNvIG11Y2ggRWNoby0NCj4gbGlrZS4gSGVuY2UgbXkgcXVlc3Rpb24g dG8gQXV0aG9ycyBXaHkgbm90IHRvIHVzZSBFY2hvIEJGRCBpbiB0aGUgZmlyc3QNCj4gcGxhY2U/ IFlvdSd2ZSBjZXJ0YWlubHkgY29uc2lkZXJlZCB0aGF0IGFuZCBJJ20gdmVyeSBpbnRlcmVzdGVk IHRvIGxlYXJuIHdoeQ0KPiB5b3UndmUgZGVjaWRlZCBub3QgdG8gdGFrZSB0aGlzIHBhdGguIHRy dWUsIG5ldyByZWdpc3RyaWVzIG1pZ2h0IGJlIHJlcXVpcmVkDQo+IGlmIGluZm9ybWF0aW9uIGlu IEJGRCBFY2hvIFJlcXVlc3QgZXhwZWN0ZWQgdG8gYmUgcHJvY2Vzc2VkIGFuZCByZXN1bHRzDQo+ IHJlcG9ydGVkIGluIEJGRCBFY2hvIFJlcGx5IGJ1dCB3ZSBrbm93IGhvdyB0byBkbyB0aGF0LCB3 ZSd2ZSBkb25lIHRoYXQNCj4gbWFueSB0aW1lcyBiZWZvcmUuIFNvLCB3aHkgbm90IEJGRCBFY2hv IHRvIGFjaGlldmUgd2hhdCBTZWFtbGVzcyBCRkQNCj4gZG9lcz8NCj4gDQo+IEFuZCBjb3VwbGUg bWlub3Igbm90ZXM6DQo+IOKAoiBzZWN0aW9uIDEwLjEgb2YgZHJhZnQtYWtpeWEtYmZkLXNlYW1s ZXNzLWJhc2UtMDEgYW5kIHNlY3Rpb24gNyBvZiBkcmFmdC0NCj4gYWtpeWEtYmZkLXNlYW1sZXNz LXNyLTAwIHJlZmVyIHRvIEVYUCBmaWVsZCBvZiBsYWJlbCBlbGVtZW50IGluIOKAnChsYWJlbCB2 YWx1ZQ0KPiArIEVYUCnigJ0gYnV0IGl0IHNob3VsZCBiZSBUcmFmZmljIENsYXNzIChUQykgZmll bGQgYXMgaXQgYmVlbiByZW5hbWVkIGluIFJGQw0KPiA1NDYyDQo+IOKAoiBkb27igJl0IHNlZSBt dWNoIG9mIG5vcm1hdGl2ZSBiZWhhdmlvciBkZWZpbmVkIGluIGRyYWZ0LWFraXlhLWJmZC0NCj4g c2VhbWxlc3Mtc3ItMDAgYnV0IG1vcmUgaW5mb3JtYXRpb25hbC4gUGVyaGFwc8KgIHNvbWUgcmUt YmFsYW5jaW5nIHdvcmsNCj4gYmV0d2VlbiBCRkQtUyBiYXNlIGFuZCBCRkQtUyBmb3IgU1Igd2ls bCBoZWxwLg0KPiANCj4gwqDCoMKgwqDCoMKgwqAgUmVnYXJkcywNCj4gwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIEdyZWcNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IHJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0Bp ZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIE5vYm8gQWtpeWEgKG5vYm8pDQo+IFNlbnQ6IFR1ZXNk YXksIFNlcHRlbWJlciAwMywgMjAxMyA3OjU3IFBNDQo+IFRvOiBUb20gU2FuZGVycw0KPiBDYzog RGF2aWQgV2FyZCAod2FyZGQpOyBydGctYmZkQGlldGYub3JnOyBDYXJsb3MgUGlnbmF0YXJvIChj cGlnbmF0YSkNCj4gU3ViamVjdDogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtDQo+IDAxLnR4dA0KPiANCj4gSGkgVG9tLA0KPiAN Cj4gVGhhbmsgeW91IGZvciByZWFkaW5nIGFuZCBjb21tZW50aW5nIG9uIHRoaXMgZG9jdW1lbnQh DQo+IA0KPiA+IEFtIGkgY29ycmVjdCBpbiBzYXlpbmcgdGhhdCB0aGUgbWFpbiBpZGVhIGJlaGlu ZCB0aGUgZHJhZnQgaXMgdG8NCj4gPiBjcmVhdGUgcHNldWRvIHJlZmxlY3RvciBCRkQgc2Vzc2lv bnMgdGhhdCByZXNwb25kIHRvIHRoZSBpbmNvbWluZyBCRkQNCj4gPiBwYWNrZXRzIHdpdGhvdXQg bWFpbnRhaW5pbmcgYW55IEJGRCBuZWlnaGJvciBzdGF0ZSBtYWNoaW5lPyBBcyBhDQo+ID4gcmVz dWx0IGl0cyBvbmx5IHRoZSBub2RlcyB0aGF0IGluaXRpYXRlIEJGRCBwYWNrZXRzIHRoYXQgbmVl ZCB0bw0KPiA+IG1haW50YWluIHRoZSBzZXNzaW9uIHN0YXRlOyB0aGUgcmVmbGVjdG9yIEJGRCBu b2RlcyBhcmUgZXNzZW50aWFsbHkNCj4gc3RhdGVsZXNzLg0KPiANCj4gU2VhbWxlc3MgQkZEIGlz IHNvcnQgb2YgbGlrZSBiZWluZyBhYmxlIHRvIGRvIEJGRCBlY2hvIG92ZXIgc2luZ2xlLQ0KPiBo b3AvbXVsdGktaG9wL0lQL01QTFMvU1IsIGV4Y2VwdCB5b3UgYXJlIHVzaW5nIEJGRCBjb250cm9s IHBhY2tldHMgJg0KPiBzZW5kZXIgY2FuIG9ubHkgZ2V0IHJlc3BvbnNlIGJhY2sgaWYgdHJhbnNt aXR0ZWQgcGFja2V0ICJ1LXR1cm5zIiBhdA0KPiBleHBlY3RlZCBuZXR3b3JrIG5vZGUuIFNvIHll cywgd2hhdCB5b3Ugc3RhdGVkIGlzIGFic29sdXRlbHkgY29ycmVjdC4NCj4gDQo+ID4gV2hpbGUg aSBjYW4gc2VlIHRoZSBhZHZhbnRhZ2UgdG8gc29tZSBleHRlbnQsIGkgYW0gcmVhbGx5IG5vdCBz dXJlIGlmDQo+ID4gd2UgaW5kZWVkIG5lZWQgc3VjaCBhbiBleHRlbnNpb24gdG8gQkZEISBJcyBt YWludGFpbmluZyBCRkQgc2Vzc2lvbg0KPiA+IHN0YXRlIHJlYWxseSBoYXJkIHdoZW4gZG9pbmcg QkZEIGluIEFTSUNzPw0KPiANCj4gTWFpbnRhaW5pbmcgbGVzcyBCRkQgc2Vzc2lvbiBzdGF0ZSBp cyBqdXN0IGEgc2lkZSBlZmZlY3QgaW4gc29tZSBjYXNlcy4NCj4gDQo+IFByb3Bvc2FsIGJyaW5n cyBmb3J0aCBzZXZlcmFsIGJlbmVmaXRzLg0KPiANCj4gMS4gUHJvdmlkZXMgZ3JlYXQgY29udHJv bCB0byBpbml0aWF0b3IuDQo+IMKgIC0gUmVhY2hhYmlsaXR5IHZhbGlkYXRpb24gaXMgdmlydHVh bGx5IGltbWVkaWF0ZSBhcyBzZXNzaW9uDQo+IGJyaW5ndXAvYm9vdHN0cmFwIHNlcXVlbmNlcyBh cmUgbm8gbG9uZ2VyIHJlcXVpcmVkLg0KPiDCoCAtIEluaXRpYXRvciBjYW4gY2hvb3NlIHRvIHN1 c3BlY3QvcmVzdW1lIGF0IGl0cyBvd24gd2lsbCB3aXRob3V0IGFmZmVjdGluZw0KPiBwZWVyIHN0 YXRlLg0KPiANCj4gMi4gU2Vzc2lvbiBubyBsb25nZXIgdGllZCB0byBwYWlyIG9mIGFkZHJlc3Nl cy4NCj4gwqAgLSBJbWFnaW5lIG11bHRpcGxlIHVubnVtYmVyZWQgdHVubmVscyAoZXg6IEdSRSkg YmV0d2VlbiBhIHBhaXIgb2YNCj4gbG9vcGJhY2tzLCBjYW4ndCBkbyBpdCB3aXRoIFJGQzU4ODEs IHZlcnkgZGlmZmljdWx0IHdpdGggUkZDNTg4My4NCj4gwqAgLSBBbGxvd2luZyBCRkQgcmVkdW5k YW5jeSAoZXg6IGhhdmluZyBtdWx0aXBsZSBzZXNzaW9ucyBwZXIgcGFpciBvZg0KPiBhZGRyZXNz ZXMpIGlzIGEgZ3JlYXQgYmVuZWZpdCB0byBwcm9kdWN0cyB3aXRoIGRpc3RyaWJ1dGVkIEJGRCBh cmNoaXRlY3R1cmUuDQo+IA0KPiAzLiBTZXBhcmF0aW9uIG9mIHRyYW5zcG9ydCAoSVAgZHN0IG9y IGxhYmVsIHN0YWNrKSBhbmQgdGFyZ2V0ICh5b3VyDQo+IGRpc2NyaW1pbmF0b3IpLg0KPiDCoCAt IFJlYWNoYWJpbGl0eSBjaGVjayBkb2VzIG5vdCBhbHdheXMgaGF2ZSB0byBiZSBlbmQtdG8tZW5k Lg0KPiANCj4gNC4gTGV2ZWwgb2YgTVBMUyBsYWJlbCB2ZXJpZmljYXRpb24uDQo+IMKgIC0gVGhp cyBpcyBhIHRvcGljIG5vdCB5ZXQgd2lkZWx5IGRpc2N1c3NlZCAoZnJvbSB3aGF0IEkgY2FuIHRl bGwpLCBidXQgQkZEDQo+IGJlaW5nIGFibGUgdG8gcGVyZm9ybSBBZGogU0lEIGZvcndhcmRpbmcg Y29ycmVjdG5lc3MgYWRkcyBncmVhdCB2YWx1ZSB0bw0KPiBTZWdtZW50IFJvdXRpbmcuDQo+IA0K PiBPZiBjb3Vyc2UsIGFzIHlvdSBzdGF0ZWQsIGVncmVzcyBzdGF0ZSBtYWludGVuYW5jZSBpcyBl c3NlbnRpYWxseSBub3QNCj4gcmVxdWlyZWQgZm9yIHVuaS1kaXJlY3Rpb25hbCByZWFjaGFiaWxp dHkgY2hlY2sgc2NlbmFyaW9zIChzdGF0aWMgcm91dGUsIHVuaS0NCj4gZGlyZWN0aW9uYWwgdHVu bmVsL0xTUCkuDQo+IA0KPiBBbmQgb25lIG9mIG15IHBlcnNvbmFsIGZhdm9yaXRlIGFib3V0IHRo aXMgcHJvcG9zYWwgaXMgdGhlIGZhY3QgaXQgYmVjb21lcyBhDQo+IGJ1aWxkaW5nIGJsb2NrIGZv ciBmdXJ0aGVyIGludGVyZXN0aW5nIHBvc3NpYmlsaXRpZXMuDQo+IA0KPiA+IFdvdWxkIGxvdmUg dG8gaGVhciB3aGF0IG90aGVycyBoYXZlIHRvIHNheSBoZXJlLg0KPiANCj4gTWUgdG9vLg0KPiAN Cj4gLSBOb2JvDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTog VG9tIFNhbmRlcnMgW21haWx0bzp0b21zLnNhbmRlcnNAZ21haWwuY29tXQ0KPiA+IFNlbnQ6IFR1 ZXNkYXksIFNlcHRlbWJlciAwMywgMjAxMyAxMjoxOSBQTQ0KPiA+IFRvOiBOb2JvIEFraXlhIChu b2JvKQ0KPiA+IENjOiBydGctYmZkQGlldGYub3JnOyBEYXZpZCBXYXJkICh3YXJkZCk7IENhcmxv cyBQaWduYXRhcm8gKGNwaWduYXRhKQ0KPiA+IFN1YmplY3Q6IFJlOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yDQo+ID4gZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtIDAxLnR4dA0K PiA+DQo+ID4gTm9ibyBldC4gYWwsDQo+ID4NCj4gPiBBbSBpIGNvcnJlY3QgaW4gc2F5aW5nIHRo YXQgdGhlIG1haW4gaWRlYSBiZWhpbmQgdGhlIGRyYWZ0IGlzIHRvDQo+ID4gY3JlYXRlIHBzZXVk byByZWZsZWN0b3IgQkZEIHNlc3Npb25zIHRoYXQgcmVzcG9uZCB0byB0aGUgaW5jb21pbmcgQkZE DQo+ID4gcGFja2V0cyB3aXRob3V0IG1haW50YWluaW5nIGFueSBCRkQgbmVpZ2hib3Igc3RhdGUg bWFjaGluZT8gQXMgYQ0KPiA+IHJlc3VsdCBpdHMgb25seSB0aGUgbm9kZXMgdGhhdCBpbml0aWF0 ZSBCRkQgcGFja2V0cyB0aGF0IG5lZWQgdG8NCj4gPiBtYWludGFpbiB0aGUgc2Vzc2lvbiBzdGF0 ZTsgdGhlIHJlZmxlY3RvciBCRkQgbm9kZXMgYXJlIGVzc2VudGlhbGx5DQo+IHN0YXRlbGVzcy4N Cj4gPg0KPiA+IFdoaWxlIGkgY2FuIHNlZSB0aGUgYWR2YW50YWdlIHRvIHNvbWUgZXh0ZW50LCBp IGFtIHJlYWxseSBub3Qgc3VyZSBpZg0KPiA+IHdlIGluZGVlZCBuZWVkIHN1Y2ggYW4gZXh0ZW5z aW9uIHRvIEJGRCEgSXMgbWFpbnRhaW5pbmcgQkZEIHNlc3Npb24NCj4gPiBzdGF0ZSByZWFsbHkg aGFyZCB3aGVuIGRvaW5nIEJGRCBpbiBBU0lDcz8gV291bGQgbG92ZSB0byBoZWFyIHdoYXQNCj4g PiBvdGhlcnMgaGF2ZSB0byBzYXkgaGVyZS4NCj4gPg0KPiA+IFRvbXMNCj4gPg0KPiA+IE9uIDIx IEF1Z3VzdCAyMDEzIDIwOjUxLCBOb2JvIEFraXlhIChub2JvKSA8bm9ib0BjaXNjby5jb20+IHdy b3RlOg0KPiA+DQo+ID4gSGVsbG8gQkZEIFdHIE1lbWJlcnMsDQo+ID4NCj4gPiBXZSBoYXZlIHB1 Ymxpc2hlZCBTLUJGRCBCYXNlIC0wMS4NCj4gPg0KPiA+IFVSTDoNCj4gPiBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtDQo+ID4gYmFz ZS0wMS50eHQNCj4gPiBTdGF0dXM6DQo+ID4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtYmFzZQ0KPiA+IEh0bWxpemVkOg0KPiA+IGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1iYXNlLTAxDQo+ ID4gRGlmZjoNCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ha2l5 YS1iZmQtc2VhbWxlc3MtYmFzZS0NCj4gPiAwMQ0KPiA+DQo+ID4gV2UgaGF2ZSByZXdvcmRlZCBz ZXZlcmFsIHNlY3Rpb25zIHRvIGltcHJvdmUgdGhlIHJlYWRhYmlsaXR5IGFzcGVjdC4NCj4gPiBU aGVyZSBhcmUgZmV3IHRlY2huaWNhbCBjaGFuZ2VzIGFzIHdlbGwuIElmIHlvdSBoYXZlIHJlYWQg LTAxLCBwbGVhc2UNCj4gPiB2aXNpdCB0aGUgZGlmZiBsaW5rIHRvIHNlZSB3aGF0IGhhcyBjaGFu Z2VkLg0KPiA+DQo+ID4gQXV0aG9ycyBhcmUgbG9va2luZyBpbnRvIHZhcmlvdXMgYXNwZWN0cyBv ZiBTLUJGRCBuZXh0LiBDYXJsb3MgYW5kDQo+ID4gbXlzZWxmIHdpbGwgYmUgbG9va2luZyBpbnRv IGZ1cnRoZXIgZGVmaW5pbmcgU2VnbWVudCBSb3V0aW5nIHNjZW5hcmlvcw0KPiA+IChTLUJGRCBT Ug0KPiA+IGRyYWZ0KSBhbmQgd2lsbCBiZSBzZWVraW5nIHNvbWUgaGVscCB0byBvbiB0aGF0IGZy b250LiBBbmQgcHJvZ3Jlc3Mgb2YNCj4gPiB0aGF0IHJlcXVpcmVzIHRoZSAiYmFzZSIgdG8gYmUg c29saWRpZmllZCwgYW5kIHdlIGFyZSBuZWVkIHlvdXIgaGVscC4NCj4gPiBQbGVhc2UgcG9pbnQg b3V0IGFueXRoaW5nIHRoYXQgaXMgdW5jbGVhciwgY29uZnVzaW5nIGFuZC9vciBxdWVzdGlvbmFi bGUuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IEF1dGhvcnMNCj4gPg0KPiA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBb bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gPiA+IFNlbnQ6IFdlZG5lc2RheSwg QXVndXN0IDIxLCAyMDEzIDEwOjU1IEFNDQo+ID4gPiBUbzogRGF2aWQgV2FyZCAod2FyZGQpOyBN YW5hdiBCaGF0aWE7IERhdmlkIFdhcmQgKHdhcmRkKTsgQ2FybG9zDQo+ID4gPiBQaWduYXRhcm8g KGNwaWduYXRhKTsgTm9ibyBBa2l5YSAobm9ibykNCj4gPiA+IFN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtDQo+ID4gMDEu dHh0DQo+ID4gPg0KPiA+ID4NCj4gPiA+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ha2l5 YS1iZmQtc2VhbWxlc3MtYmFzZS0wMS50eHQNCj4gPiA+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgTm9ibyBBa2l5YSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGDQo+ID4gPiByZXBv c2l0b3J5Lg0KPiA+ID4NCj4gPiA+IEZpbGVuYW1lOiDCoCDCoCDCoGRyYWZ0LWFraXlhLWJmZC1z ZWFtbGVzcy1iYXNlDQo+ID4gPiBSZXZpc2lvbjogwqAgwqAgwqAwMQ0KPiA+ID4gVGl0bGU6IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNlYW1sZXNzIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBE ZXRlY3Rpb24NCj4gPiA+IChCRkQpIHdpdGggTVBMUyBMYWJlbCBWZXJpZmljYXRpb24gRXh0ZW5z aW9uIENyZWF0aW9uIGRhdGU6DQo+ID4gPiAyMDEzLTA4LTIxDQo+ID4gPiBHcm91cDogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uIE51bWJlciBvZiBwYWdlczog MjANCj4gPiA+IFVSTDoNCj4gPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy0NCj4gPiA+IGJhc2UtMDEudHh0DQo+ID4gPiBTdGF0 dXM6DQo+ID4gPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFraXlhLWJm ZC1zZWFtbGVzcy1iYXNlDQo+ID4gPiBIdG1saXplZDoNCj4gPiA+IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1iYXNlLTAxDQo+ID4gPiBEaWZmOg0K PiA+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYWtpeWEtYmZkLXNl YW1sZXNzLQ0KPiA+IGJhc2UtDQo+ID4gPiAwMQ0KPiA+ID4NCj4gPiA+IEFic3RyYWN0Og0KPiA+ ID4gwqAgwqBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBzaW1wbGlmaWVkIG1lY2hhbmlzbSB0byB1 c2UgQmlkaXJlY3Rpb25hbA0KPiA+ID4gwqAgwqBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSB3 aXRoIGxhcmdlIHBvcnRpb25zIG9mIG5lZ290aWF0aW9uDQo+ID4gPiBhc3BlY3RzDQo+ID4gPiDC oCDCoGVsaW1pbmF0ZWQsIHRoYXQgYWxsb3dzIGZ1bGwgYW5kIHBhcnRpYWwgcmVhY2hhYmlsaXR5 IHZlcmlmaWNhdGlvbi4NCj4gPiA+IMKgIMKgRm9yIE1QTFMgYmFzZWQgQkZELCBleHRlbnNpb25z IHRvIHRoZSBnZW5lcmljIG1lY2hhbmlzbSBhcmUNCj4gPiA+IGRlZmluZWQNCj4gPiA+IMKgIMKg dGhhdCBhbGxvd3MgQkZEIHRvIHBlcmZvcm0gYSBsZXZlbCBvZiBsYWJlbCB2ZXJpZmljYXRpb24u DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IFBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4g PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQNCj4gPiB0b29scy5pZXRmLm9yZy4NCj4gPiA+DQo+ID4gPiBUaGUgSUVURiBTZWNy ZXRhcmlhdA0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0NCj4gPiBUb21zLg0KPiANCg== From nobo@cisco.com Mon Sep 9 13:41:01 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06DF21E80C3 for ; Mon, 9 Sep 2013 13:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 0OX1ITP6-pJ9 for ; Mon, 9 Sep 2013 13:40:56 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6893711E8141 for ; Mon, 9 Sep 2013 13:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2818; q=dns/txt; s=iport; t=1378759256; x=1379968856; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=vl3wtufyhBO0tLN+3OIEkq0ZZapkk1AJXR5JRkjaXas=; b=f7M9CeATQTxetf4g6/he9pdEKpbR5L6bKAKJcNVFRz8JBKf1zIu1P94h qBGpFAIP9PWWQnJ0jU+bu5H/9Gzzb8ElRYcwY2V4NQXH0j4zV8Xrl0aJL bMzXoTbdpZ6rScK4lL0zBIOFnQtYyHwXUuTFvsJtC0DC2JhXUxWhLNAap A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FAAsxLlKtJXHA/2dsb2JhbABbgmYhOFHCHIEmFm0HgicBBDpRASoUQiYBBBuHegELoiCgfI9Pg1WBAAOZJJA3gyCBaiQc X-IronPort-AV: E=Sophos;i="4.90,873,1371081600"; d="scan'208";a="257476417" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 09 Sep 2013 20:40:56 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r89KetQ5007830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Sep 2013 20:40:55 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 15:40:55 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: Segment Routing Implications on BFD Thread-Topic: Segment Routing Implications on BFD Thread-Index: Ac6tmOfDnBampmIzRca85E3i692azg== Date: Mon, 9 Sep 2013 20:40:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 20:41:01 -0000 [speaking as individual contributor] Hello BFD WG Members, STATUS BoF @ Berlin has resulted in conclusion of a new WG formation. Vario= us documents for use-cases and requirements will roll out over time. There is one existing use-case document. http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-use-cases-0= 0 While waiting for other use-cases and requirements documents to roll out, I= wanted to highlight two particular aspects of Segment Routing, based on ab= ove document, that are potential impact to the BFD protocol. 1. Stateless nature of midpoints and tail-ends. RFC5884: a. Defines BFD over MPLS, via using LSP ping as a bootstrap mechanism. b. After BFD session is bootstrapped on tail-end, further LSP ping is optio= nal. c. Cleanup procedures of BFD session on tail-end is not defined. d. Lack of cleanup procedures is most likely because LSP state removal on t= ail-end can trigger removal of corresponding BFD session. MPLS data plane is highly favored for Segment Routing, so I think we want t= o ensure BFD works on SR based MPLS. Difficulty is that there is no LSP sta= te kept on tail-ends, which means BFD has lost the trigger for session remo= val (item d from above). Either we have to define some sort of BFD session = cleanup procedures, or we have to define a mechanism where BFD is also stat= eless on tail-ends. 2. Immediate nature of LSP. Section 5.2.1 of the document describes an approach to dynamically change t= he flow of traffic to different traffic engineered path. If Segment Routing= always mandated that path to use must be pre-created X amount time of befo= re its use, then there are any implications to BFD. I tend to think that Se= gment Routing (and SDN) should be allowed to create and want to use that pa= th immediately to carry traffic. And I also tend to think that there's bene= fit in validating the reachability of path with BFD prior to its use. BFD protocol today has been designed to go down fast but go up slow(er), du= e to initial sedated timer. It takes couple of seconds for BFD sessions to = transition to up state. In addition to this, LSP ping usually has much more= scale/performance constrained implementations. When BFD relies on LSP ping= for bootstrapping, time it takes for scaled number of BFD sessions to go u= p is going to be bound by LSP ping performance, resulting in much longer ti= me than couple of seconds. When it comes to Segment Routing (and SDN), it appears to be very desirable= to have BFD to perform reachability validation immediately when needed. An= d we cannot do that today. =20 I'm very curious to see what everyone is thinks about the two aspects above= , as well as if anybody sees any other potential implications. -Nobo =20 From ding.jianwu@zte.com.cn Tue Sep 10 13:01:28 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E65A21F9A10 for ; Tue, 10 Sep 2013 13:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.624 X-Spam-Level: X-Spam-Status: No, score=-90.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_103=0.327, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] 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 xGveNlrZ-irz for ; Tue, 10 Sep 2013 13:01:23 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1E04F21F866E for ; Tue, 10 Sep 2013 13:00:44 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id B82DF1927FC6 for ; Wed, 11 Sep 2013 04:00:30 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id B8019193A227 for ; Wed, 11 Sep 2013 04:00:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r8AK0NJs033711 for ; Wed, 11 Sep 2013 04:00:24 +0800 (GMT-8) (envelope-from ding.jianwu@zte.com.cn) Subject: =?GB2312?B?tqG9qM7kMTcxMTM5ILK71Nqw7LmrytKhow==?= Auto-Submitted: auto-generated From: ding.jianwu@zte.com.cn To: rtg-bfd@ietf.org Message-ID: Date: Wed, 11 Sep 2013 04:00:23 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-09-11 04:00:23 MIME-Version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: base64 X-MAIL: mse01.zte.com.cn r8AK0NJs033711 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 20:01:28 -0000 DQrO0r2rtNMgMjAxMy0wOS0xMSC/qsq8wOu/qrDsuavK0qOstb0gMjAxMy0wOS0xMiDKsbe1u9ih ow0KDQrO0r2r1Nq72MC01q6687TwuLTE+rXEz/vPoqGjDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3Vy aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBh bnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29u ZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFk ZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRp c2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRp b24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRl bGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1 cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQg YW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNv bmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBh ZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBk aXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0 aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBk ZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg== From jhaas@slice.pfrc.org Wed Sep 18 14:43:27 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4601611E8165 for ; Wed, 18 Sep 2013 14:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.128 X-Spam-Level: X-Spam-Status: No, score=-100.128 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 OsZijoT1nciF for ; Wed, 18 Sep 2013 14:43:22 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDDA11E8142 for ; Wed, 18 Sep 2013 14:43:22 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id AC444C309; Wed, 18 Sep 2013 17:43:21 -0400 (EDT) Date: Wed, 18 Sep 2013 17:43:21 -0400 From: Jeffrey Haas To: Tom Sanders Subject: Re: New Version Notification for draft-akiya-bfd-seamless-base-01.txt Message-ID: <20130918214321.GG8137@pfrc> References: <20130821145447.28106.64314.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "David Ward \(wardd\)" , "rtg-bfd@ietf.org" , "Carlos Pignataro \(cpignata\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 21:43:27 -0000 On Tue, Sep 03, 2013 at 09:49:05PM +0530, Tom Sanders wrote: > While i can see the advantage to some extent, i am really not sure if we > indeed need such an extension to BFD! Is maintaining BFD session state > really hard when doing BFD in ASICs? Would love to hear what others have to > say here. It turns out that the need to actively provision BFD sessions on both sides of a resource is occasionally a significant pain operationally. One of the repeated items that has popped up on the list over the years has been thoughts on auto-provisioning mechanisms. The "seamless" proposal covers a significant part of the auto-provisioning space. It also raises the possibilities of interesting headaches as well, e.g. security. I'd like to request the WG to actively review the use cases covered by the drafts and the suggested implementation. We'll be scheduling a WG session for the upcoming Vancouver IETF and discussing these use cases and proposals will be part of the agenda. With regard to the segment routing (SR) use cases, while they're a reasonable match for the functionality in the drafts, the drafts seem to have enough substance to stand on their own for the time being. This is important because our ADs haven't placed where SR specific work will happen. I'd recommend the working group focus on the non-SR use cases primarily for the time being. A note for the record, since Nobo is an active author on these drafts, I will be the managing chair for matters relating to them. -- Jeff From jhaas@slice.pfrc.org Wed Sep 18 14:48:42 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CE611E81B9 for ; Wed, 18 Sep 2013 14:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.267 X-Spam-Level: X-Spam-Status: No, score=-100.267 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 BwALTOCC8GGk for ; Wed, 18 Sep 2013 14:48:37 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6A85811E81CB for ; Wed, 18 Sep 2013 14:48:37 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 29B82C309; Wed, 18 Sep 2013 17:48:37 -0400 (EDT) Date: Wed, 18 Sep 2013 17:48:37 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Meeting in Vancouver for IETF 88 - Call for Presentations Message-ID: <20130918214837.GH8137@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 21:48:42 -0000 The WG chairs have determined we have enough new work to warrant a meeting at the upcoming IETF in Vancouver. Some items targeted for the agenda: - Usual updates - WGLC results (we'll be issuing WGLC requests shortly) - Seamless BFD - ??? If you have a topic you'd like to discuss at the meeting, please email the chairs. As always, we're looking to keep the sessions short and focused on discussion rather than reading from slides. New proposals should be backed by Internet-Drafts and discussion ideally should be initiated on the mailing list first. -- Jeff and Nobo From jhaas@slice.pfrc.org Wed Sep 18 14:58:07 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1B611E8263 for ; Wed, 18 Sep 2013 14:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.243 X-Spam-Level: X-Spam-Status: No, score=-101.243 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 C4aL8+PSc+l7 for ; Wed, 18 Sep 2013 14:58:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAE811E8275 for ; Wed, 18 Sep 2013 14:58:00 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2F750C309; Wed, 18 Sep 2013 17:57:59 -0400 (EDT) Date: Wed, 18 Sep 2013 17:57:59 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: Discovering IP address to use for uBFD sessions Message-ID: <20130918215759.GI8137@pfrc> References: <51c949f3.c786440a.151a.ffff9ca7@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "rtg-bfd@ietf.org" , "Jeff Haas \(jhaas@juniper.net\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 21:58:07 -0000 On Thu, Jul 11, 2013 at 07:49:11PM +0000, Nobo Akiya (nobo) wrote: > [hat on] > > I had a discussion with Jeff on this topic. > > We have concluded that there isn???t sufficient WG interest to pursue adoption of dynamic address discovery at this time. However note, such work, if interest appears, is in scope for the existing charter. To bump this thread, the seamless BFD proposal may cover this use case. With regard to only BFD on LAG, it was the consensus of the initial developers and authors that configuration was sufficient for the time being and satisfied the original customer use case. But as noted elsewhere, people keep asking about this. :-) -- Jeff From marc@sniff.de Tue Sep 24 06:21:02 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3041F21F970E for ; Tue, 24 Sep 2013 06:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 nu4Nj+UKvkuQ for ; Tue, 24 Sep 2013 06:21:01 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F4621F967F for ; Tue, 24 Sep 2013 06:21:00 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id DA6562AA0F; Tue, 24 Sep 2013 13:20:57 +0000 (GMT) Date: Tue, 24 Sep 2013 15:20:57 +0200 From: Marc Binderberger To: Jeffrey Haas , Nobo Akiya (nobo) Message-ID: <20130924152057726809.4e29884d@sniff.de> In-Reply-To: <20130918215759.GI8137@pfrc> References: <51c949f3.c786440a.151a.ffff9ca7@mx.google.com> <20130918215759.GI8137@pfrc> Subject: Re: Discovering IP address to use for uBFD sessions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Cc: "Jeff Haas \(jhaas@juniper.net\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 13:21:02 -0000 Hello, I think we can play on time regarding this topic. If there are specific requests they may drive the discussion again. Also over time network designs change. Who knows, in a few years the out-of-band synchronization between two network nodes may be a side effect of SDN and the "discovery" comes for free ;-) Not sure how seamless BFD is fitting into scenarios with two-sided BFD like uBFD sessions. Each technology has it's area where it is the right fit; for seamless I see everything that is uni-directional and/or virtual - LSPs, tunnels, etc., as an excellent fit and seamless BFD as probably superior over our existing two-sided BFD. As long as something is fixed - either physical like a wire or fixed configured - I would see the existing BFD as the best fit. Anyway, good discussions are always fine with me :-) Regards, Marc On Wed, 18 Sep 2013 17:57:59 -0400, Jeffrey Haas wrote: > On Thu, Jul 11, 2013 at 07:49:11PM +0000, Nobo Akiya (nobo) wrote: >> [hat on] >> >> I had a discussion with Jeff on this topic. >> >> We have concluded that there isn???t sufficient WG interest to >> pursue adoption of dynamic address discovery at this time. However >> note, such work, if interest appears, is in scope for the existing >> charter. > > To bump this thread, the seamless BFD proposal may cover this use case. > > With regard to only BFD on LAG, it was the consensus of the initial > developers and authors that configuration was sufficient for the time being > and satisfied the original customer use case. But as noted elsewhere, > people keep asking about this. :-) > > -- Jeff > From binnyjeshan@gmail.com Tue Sep 24 08:19:01 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07ECA11E8160 for ; Tue, 24 Sep 2013 08:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 9nNc3bxNEFr8 for ; Tue, 24 Sep 2013 08:19:00 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1D111E8142 for ; Tue, 24 Sep 2013 08:19:00 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id rd3so3820864pab.4 for ; Tue, 24 Sep 2013 08:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:cc:from:subject:date:content-type; bh=W4z0TomMoDZEYYJ7bQubosLr33LszQPGW8MyeXL06Fk=; b=N30vP4+TPRGI5xN/sl039Jj9fQUsDb/+4Tv7a2no/iE6kG0zIUfHJZkFTiJrJXzkZG 7jJKUWBjDyweIMpVefBuWHFdszoMC2kQpF37wRTsn2Aph55SX6AgMNFTyTwwc69MXb3r m3deG7GbOsFqTQdq5ClnMBsl3b6xMfM1/i9Qhj1GNebA9bMNii0w/VhKM7RwDFP76MxS 2MMNfBjpZYWKV7kN7SHRSOYMvH5qU9CCSObkA//e6MZN0SzbNTMz9K4qX9V85lUBGfPP Zgq1A8Wjirk1FvilIpDp9MlXGN86dHo8gq31LEFRRc4rWp+yyDwlpTQYXvuBMiiwetH2 ccyg== X-Received: by 10.68.64.231 with SMTP id r7mr11504460pbs.134.1380035939359; Tue, 24 Sep 2013 08:18:59 -0700 (PDT) Received: from [223.228.17.11] ([223.228.17.11]) by mx.google.com with ESMTPSA id wr5sm9850249pbc.14.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 24 Sep 2013 08:18:58 -0700 (PDT) Message-ID: <5241ad62.a5f2440a.1102.1a0e@mx.google.com> MIME-Version: 1.0 To: Marc Binderberger , Jeffrey Haas , "Nobo Akiya (nobo)" From: Binny Jeshan Subject: RE: Discovering IP address to use for uBFD sessions Date: Tue, 24 Sep 2013 20:49:23 +0530 Content-Type: multipart/alternative; boundary="_6C807736-376E-4EF2-96AC-99C162EDF160_" Cc: "Jeff Haas \(jhaas@juniper.net\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 15:19:01 -0000 --_6C807736-376E-4EF2-96AC-99C162EDF160_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I agree with Marc. Regards, Binny. Sent from Nokia Lumia. -----Original Message----- From: "Marc Binderberger" Sent: =E2=80=8E24-=E2=80=8E09-=E2=80=8E2013 06:51 PM To: "Jeffrey Haas" ; "Nobo Akiya (nobo)" Cc: "Jeff Haas (jhaas@juniper.net)" ; "rtg-bfd@ietf.org"= Subject: Re: Discovering IP address to use for uBFD sessions Hello, I think we can play on time regarding this topic. If there are specific=20 requests they may drive the discussion again. Also over time network=20 designs change. Who knows, in a few years the out-of-band=20 synchronization between two network nodes may be a side effect of SDN=20 and the "discovery" comes for free ;-) Not sure how seamless BFD is fitting into scenarios with two-sided BFD=20 like uBFD sessions. Each technology has it's area where it is the right=20 fit; for seamless I see everything that is uni-directional and/or=20 virtual - LSPs, tunnels, etc., as an excellent fit and seamless BFD as=20 probably superior over our existing two-sided BFD. As long as something=20 is fixed - either physical like a wire or fixed configured - I would=20 see the existing BFD as the best fit. Anyway, good discussions are always fine with me :-) Regards, Marc On Wed, 18 Sep 2013 17:57:59 -0400, Jeffrey Haas wrote: > On Thu, Jul 11, 2013 at 07:49:11PM +0000, Nobo Akiya (nobo) wrote: >> [hat on] >>=20 >> I had a discussion with Jeff on this topic. >>=20 >> We have concluded that there isn???t sufficient WG interest to=20 >> pursue adoption of dynamic address discovery at this time. However=20 >> note, such work, if interest appears, is in scope for the existing=20 >> charter. >=20 > To bump this thread, the seamless BFD proposal may cover this use case. = =20 >=20 > With regard to only BFD on LAG, it was the consensus of the initial > developers and authors that configuration was sufficient for the time bei= ng > and satisfied the original customer use case. But as noted elsewhere, > people keep asking about this. :-) >=20 > -- Jeff >=20 --_6C807736-376E-4EF2-96AC-99C162EDF160_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
I agree wit= h Marc.

Regards,
Binny.

Sent from Nokia Lumia.
From: Marc BinderbergerSent: =E2=80=8E24-=E2=80=8E09-=E2=80=8E2013 06:51 PM
To: Jeffrey Haas; Nobo Akiya (nobo)
Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org
Subject: Re: Discover= ing IP address to use for uBFD sessions

Hello,

I= think we can play on time regarding this topic. If there are specific
= requests they may drive the discussion again. Also over time network
de= signs change. Who knows, in a few years the out-of-band
synchronization= between two network nodes may be a side effect of SDN
and the "discove= ry" comes for free ;-)

Not sure how seamless BFD is fitting into sce= narios with two-sided BFD
like uBFD sessions. Each technology has it's = area where it is the right
fit; for seamless I see everything that is u= ni-directional and/or
virtual - LSPs, tunnels, etc., as an excellent fi= t and seamless BFD as
probably superior over our existing two-sided BFD= . As long as something
is fixed - either physical like a wire or fixed = configured - I would
see the existing BFD as the best fit.


A= nyway, good discussions are always fine with me :-)


Regards, Mar= c




On Wed, 18 Sep 2013 17:57:59 -0400, Jeffrey Haas wrote= :
> On Thu, Jul 11, 2013 at 07:49:11PM +0000, Nobo Akiya (nobo) wrote= :
>> [hat on]
>>
>> I had a discussion with Jef= f on this topic.
>>
>> We have concluded that there isn?= ??t sufficient WG interest to
>> pursue adoption of dynamic addre= ss discovery at this time. However
>> note, such work, if interes= t appears, is in scope for the existing
>> charter.
>
&= gt; To bump this thread, the seamless BFD proposal may cover this use case.=  
>
> With regard to only BFD on LAG, it was the consens= us of the initial
> developers and authors that configuration was suf= ficient for the time being
> and satisfied the original customer use = case.  But as noted elsewhere,
> people keep asking about this. = :-)
>
> -- Jeff
>
= --_6C807736-376E-4EF2-96AC-99C162EDF160_-- From nobo@cisco.com Wed Sep 25 15:51:13 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41B911E810F for ; Wed, 25 Sep 2013 15:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 krjZgOvWrwam for ; Wed, 25 Sep 2013 15:51:07 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB0221F9468 for ; Wed, 25 Sep 2013 15:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5334; q=dns/txt; s=iport; t=1380149461; x=1381359061; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/agWI8m9pCcrMpaoJD6p+cLsYS/KRZ4CSZzftkQvVTI=; b=EZtjFPq+bkAQXgr+bYmzABNmkNxL6/2vi/UlxBgy+98NiMKotsUMW1Np xGJRonb5EoiHo2jQiK6tmY3UrhjLHAiZJYmJx1MPPIpkSFaslUvJLJ4QA Xxf/6JjMNAGjvijVbee3S+U+5+kGPumB01HIEFPIbuIiYiHGtW/xOaoeF c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAHlnQ1KtJV2d/2dsb2JhbABagmYhgQqDKb0rF4EFFnSCJQEBAQMBIxFFBQcEAgEIEQEDAQEBAgIGHQMCAgIfERQBAgYIAgQBDQUIh2wDCQYBqXmITw2JaoEpiz2COhYbBwaCYjWBAAOWE44thTODJIIq X-IronPort-AV: E=Sophos;i="4.90,981,1371081600"; d="scan'208";a="264595589" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 25 Sep 2013 22:51:00 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8PMp0hC000521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 22:51:00 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 17:51:00 -0500 From: "Nobo Akiya (nobo)" To: Binny Jeshan , Marc Binderberger , Jeffrey Haas Subject: RE: Discovering IP address to use for uBFD sessions Thread-Topic: Discovering IP address to use for uBFD sessions Thread-Index: AQHOuTlyw9kYHM4ciEaGS96ovWjjFJnWakTQ Date: Wed, 25 Sep 2013 22:50:59 +0000 Message-ID: References: <5241ad62.a5f2440a.1102.1a0e@mx.google.com> In-Reply-To: <5241ad62.a5f2440a.1102.1a0e@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Jeff Haas \(jhaas@juniper.net\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 22:51:14 -0000 SGkgTWFyYywgQmlubnksIGV0IGFsLA0KDQpJIGFncmVlIHdpdGggeW91ciBzdGF0ZW1lbnQgb2Yg InJpZ2h0IGZpdCIgZm9yIHNlYW1sZXNzIEJGRCBhbmQgZXhpc3RpbmcgQkZELg0KDQo+IEFueXdh eSwgZ29vZCBkaXNjdXNzaW9ucyBhcmUgYWx3YXlzIGZpbmUgd2l0aCBtZSA6LSkNCg0KT2sgOikN Cg0KU2luY2UgU0ROIHdhcyBtZW50aW9uZWQsIHBlcmhhcHMgd2UgY2FuIGRpdmUgYSBiaXQgZnVy dGhlciBpbnRvIHRoYXQgdG9waWMuIEkgY2FuIHNlZSBvbmUgYXBwcm9hY2ggYmVpbmcgdGhhdCBT RE4gcHJvdmlzaW9ucyBCRkQgc2Vzc2lvbnMgb24gbmVjZXNzYXJ5IG5vZGVzLiBPciBpbiBhIG5l dHdvcmsgd2hlcmUgdGhlcmUncyBjbGVhbihlcikgc2VwYXJhdGlvbiBvZiBjb250cm9sIHBsYW5l IGFuZCBkYXRhIHBsYW5lLCB0aGVuIEkgY2FuIGFsc28gc2VlIHBlcm1hbmVudCBtb25pdG9yIHBh Y2tldHMgdG8gYmUgZ2VuZXJhdGVkIGZyb20gdGhlIGNvbnRyb2xsZXIgZGV2aWNlLiBTdWNoIHBh Y2tldHMgY2FuIGFueXRoaW5nIGFzIGxvbmcgYXMgdGhleSBvcmlnaW5hdGUgZnJvbSB0aGUgY29u dHJvbGxlciBkZXZpY2UgYW5kIHRlcm1pbmF0ZXMgYXQgdGhlIGNvbnRyb2xsZXIgZGV2aWNlLiBQ cm9ibGVtIGlzIHRoYXQgcGFja2V0IGluc3RydWN0ZWQgdG8gdGFrZSBhcmJpdHJhcnkgcGF0aCBh bmQgYmFjayB0byBzZWxmIG1ha2VzIGl0IGRpZmZpY3VsdCB0byBndWFyYW50ZWUgdGhhdCBwYWNr ZXQgZGlkICJsb29wIiBhdCBpbnRlbmRlZCBub2RlLiBUaHVzIHRoZXJlJ3MgYSBuZWVkIGZvciBz dWNoIHBlcm1hbmVudCBtb25pdG9yIHBhY2tldCB0byB0YWtlIGFyYml0cmFyeSBwYXRoIHRvIGlu dGVuZGVkIHRhcmdldCwgYW5kIGhhdmUgaW50ZW5kZWQgdGFyZ2V0IGdlbmVyYXRlIGEgcmVzcG9u c2UgcGFja2V0IGJhY2sgdG8gdGhlIGNvbnRyb2xsZXIgZGV2aWNlLiBUaGF0IG1lYW5zIHN1Y2gg cGFja2V0cyBjYW5ub3QgYmUgYW55dGhpbmcsIGJ1dCBtdXN0IGJlIGRlZmluZWQuDQoNClRvIHBs YWNlIG1vcmUgdHdpc3QgaW50byB0aGlzLCBzdGF0aWNhbGx5IHByb3Zpc2lvbmVkIExTUHMgKGFr YSBzdGF0aWMgTFNQLCBNUExTIHN0YXRpYykgaXMgb25lIG5ldHdvcmsgYXJjaGl0ZWN0dXJlIHdo ZXJlIFNETi1saWtlIGlzIGxpa2VseS4gSWYgd2Ugd2FudCB0byB1c2UgQkZEIGluaXRpYXRlZCBm cm9tIGNvbnRyb2xsZXIgZGV2aWNlcywgYXMgYWJvdmUsIHdlIG5lZWQgc29tZXRoaW5nIG1vcmUg dGhhbiBleGlzdGluZyBCRkQuIElmIHdlIHdhbnQgdG8gdXNlIHRyYWRpdGlvbmFsIG1vZGVsIG9m IEJGRCBwcm92aXNpb25lZCBhdCBMU1AgaW5ncmVzcyhlcyksIHRoZW4gZG8gd2Ugd2FudCB0byBy ZXVzZSBSRkM1ODg0IHdpdGggbmV3IEZFQyBkZWZpbmVkIGZvciBzdGF0aWM/IA0KDQpJIHNlZSBT LUJGRCB0byBiZSB0aGUgInJpZ2h0IGZpdCIgZm9yIHRoZXNlIHNjZW5hcmlvcyBhcyB3ZWxsLg0K DQotTm9ibw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJpbm55IEpl c2hhbiBbbWFpbHRvOmJpbm55amVzaGFuQGdtYWlsLmNvbV0NCj4gU2VudDogVHVlc2RheSwgU2Vw dGVtYmVyIDI0LCAyMDEzIDExOjE5IEFNDQo+IFRvOiBNYXJjIEJpbmRlcmJlcmdlcjsgSmVmZnJl eSBIYWFzOyBOb2JvIEFraXlhIChub2JvKQ0KPiBDYzogSmVmZiBIYWFzIChqaGFhc0BqdW5pcGVy Lm5ldCk7IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IERpc2NvdmVyaW5nIElQIGFk ZHJlc3MgdG8gdXNlIGZvciB1QkZEIHNlc3Npb25zDQo+IA0KPiBJIGFncmVlIHdpdGggTWFyYy4N Cj4gDQo+IFJlZ2FyZHMsDQo+IEJpbm55Lg0KPiANCj4gU2VudCBmcm9tIE5va2lhIEx1bWlhLg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IE1hcmMg QmluZGVyYmVyZ2VyDQo+IFNlbnQ6IOKAjjI0LeKAjjA5LeKAjjIwMTMgMDY6NTEgUE0NCj4gVG86 IEplZmZyZXkgSGFhczsgTm9ibyBBa2l5YSAobm9ibykNCj4gQ2M6IEplZmYgSGFhcyAoamhhYXNA anVuaXBlci5uZXQpOyBydGctYmZkQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBEaXNjb3Zlcmlu ZyBJUCBhZGRyZXNzIHRvIHVzZSBmb3IgdUJGRCBzZXNzaW9ucw0KPiBIZWxsbywNCj4gDQo+IEkg dGhpbmsgd2UgY2FuIHBsYXkgb24gdGltZSByZWdhcmRpbmcgdGhpcyB0b3BpYy4gSWYgdGhlcmUg YXJlIHNwZWNpZmljDQo+IHJlcXVlc3RzIHRoZXkgbWF5IGRyaXZlIHRoZSBkaXNjdXNzaW9uIGFn YWluLiBBbHNvIG92ZXIgdGltZSBuZXR3b3JrDQo+IGRlc2lnbnMgY2hhbmdlLiBXaG8ga25vd3Ms IGluIGEgZmV3IHllYXJzIHRoZSBvdXQtb2YtYmFuZA0KPiBzeW5jaHJvbml6YXRpb24gYmV0d2Vl biB0d28gbmV0d29yayBub2RlcyBtYXkgYmUgYSBzaWRlIGVmZmVjdCBvZiBTRE4NCj4gYW5kIHRo ZSAiZGlzY292ZXJ5IiBjb21lcyBmb3IgZnJlZSA7LSkNCj4gDQo+IE5vdCBzdXJlIGhvdyBzZWFt bGVzcyBCRkQgaXMgZml0dGluZyBpbnRvIHNjZW5hcmlvcyB3aXRoIHR3by1zaWRlZCBCRkQNCj4g bGlrZSB1QkZEIHNlc3Npb25zLiBFYWNoIHRlY2hub2xvZ3kgaGFzIGl0J3MgYXJlYSB3aGVyZSBp dCBpcyB0aGUgcmlnaHQNCj4gZml0OyBmb3Igc2VhbWxlc3MgSSBzZWUgZXZlcnl0aGluZyB0aGF0 IGlzIHVuaS1kaXJlY3Rpb25hbCBhbmQvb3INCj4gdmlydHVhbCAtIExTUHMsIHR1bm5lbHMsIGV0 Yy4sIGFzIGFuIGV4Y2VsbGVudCBmaXQgYW5kIHNlYW1sZXNzIEJGRCBhcw0KPiBwcm9iYWJseSBz dXBlcmlvciBvdmVyIG91ciBleGlzdGluZyB0d28tc2lkZWQgQkZELiBBcyBsb25nIGFzIHNvbWV0 aGluZw0KPiBpcyBmaXhlZCAtIGVpdGhlciBwaHlzaWNhbCBsaWtlIGEgd2lyZSBvciBmaXhlZCBj b25maWd1cmVkIC0gSSB3b3VsZA0KPiBzZWUgdGhlIGV4aXN0aW5nIEJGRCBhcyB0aGUgYmVzdCBm aXQuDQo+IA0KPiANCj4gQW55d2F5LCBnb29kIGRpc2N1c3Npb25zIGFyZSBhbHdheXMgZmluZSB3 aXRoIG1lIDotKQ0KPiANCj4gDQo+IFJlZ2FyZHMsIE1hcmMNCj4gDQo+IA0KPiANCj4gDQo+IE9u IFdlZCwgMTggU2VwIDIwMTMgMTc6NTc6NTkgLTA0MDAsIEplZmZyZXkgSGFhcyB3cm90ZToNCj4g PiBPbiBUaHUsIEp1bCAxMSwgMjAxMyBhdCAwNzo0OToxMVBNICswMDAwLCBOb2JvIEFraXlhIChu b2JvKSB3cm90ZToNCj4gPj4gW2hhdCBvbl0NCj4gPj4NCj4gPj4gSSBoYWQgYSBkaXNjdXNzaW9u IHdpdGggSmVmZiBvbiB0aGlzIHRvcGljLg0KPiA+Pg0KPiA+PiBXZSBoYXZlIGNvbmNsdWRlZCB0 aGF0IHRoZXJlIGlzbj8/P3Qgc3VmZmljaWVudCBXRyBpbnRlcmVzdCB0bw0KPiA+PiBwdXJzdWUg YWRvcHRpb24gb2YgZHluYW1pYyBhZGRyZXNzIGRpc2NvdmVyeSBhdCB0aGlzIHRpbWUuIEhvd2V2 ZXINCj4gPj4gbm90ZSwgc3VjaCB3b3JrLCBpZiBpbnRlcmVzdCBhcHBlYXJzLCBpcyBpbiBzY29w ZSBmb3IgdGhlIGV4aXN0aW5nDQo+ID4+IGNoYXJ0ZXIuDQo+ID4NCj4gPiBUbyBidW1wIHRoaXMg dGhyZWFkLCB0aGUgc2VhbWxlc3MgQkZEIHByb3Bvc2FsIG1heSBjb3ZlciB0aGlzIHVzZSBjYXNl Lg0KPiA+DQo+ID4gV2l0aCByZWdhcmQgdG8gb25seSBCRkQgb24gTEFHLCBpdCB3YXMgdGhlIGNv bnNlbnN1cyBvZiB0aGUgaW5pdGlhbA0KPiA+IGRldmVsb3BlcnMgYW5kIGF1dGhvcnMgdGhhdCBj b25maWd1cmF0aW9uIHdhcyBzdWZmaWNpZW50IGZvciB0aGUgdGltZQ0KPiBiZWluZw0KPiA+IGFu ZCBzYXRpc2ZpZWQgdGhlIG9yaWdpbmFsIGN1c3RvbWVyIHVzZSBjYXNlLsKgIEJ1dCBhcyBub3Rl ZCBlbHNld2hlcmUsDQo+ID4gcGVvcGxlIGtlZXAgYXNraW5nIGFib3V0IHRoaXMuIDotKQ0KPiA+ DQo+ID4gLS0gSmVmZg0KPiA+DQo= From glen.kent@gmail.com Wed Sep 25 23:38:55 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C05821F968B for ; Wed, 25 Sep 2013 23:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 4Kp8HBRUlPAR for ; Wed, 25 Sep 2013 23:38:54 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id D4DA621F9FDA for ; Wed, 25 Sep 2013 23:38:47 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id ec20so559023lab.14 for ; Wed, 25 Sep 2013 23:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jsNp1yeabBvPkjgbfd45Hb5UBb2Sr8z/z1cp1EbZ5qs=; b=BmIx2Qk3nP8SGPd2q0tPaBwtMuT0TnO3ITKjNrvQeSwI7/cyAK7CPEgGNN0YNybTVH XFip1xjk42IMh/aVVZYtKDAKgbzszRC35lkamPrCloo5q9QCreD+E7uwqW5eyVM4qeQH jgO8a0fTVzhNlKAsRWg9GHFA0eL1uIND+8A4FJ+JJuACskSrJGOfoYPdGAYDvS1gf/Hy UkwmCji3IVtfPqDX9U9XKFTSdja6k45HUSe/JE7xhfVHDLeo0gRL06PJXjSqoSuSTHLK 9P0eRE62YcMjtHog4o44GVypn4hqSJTGgf8nmAHyblcyuUkblPiMWIKCO+YkcQNafr6f 28oQ== MIME-Version: 1.0 X-Received: by 10.112.181.100 with SMTP id dv4mr469936lbc.34.1380177526187; Wed, 25 Sep 2013 23:38:46 -0700 (PDT) Received: by 10.152.109.76 with HTTP; Wed, 25 Sep 2013 23:38:46 -0700 (PDT) In-Reply-To: References: <5241ad62.a5f2440a.1102.1a0e@mx.google.com> Date: Thu, 26 Sep 2013 12:08:46 +0530 Message-ID: Subject: Re: Discovering IP address to use for uBFD sessions From: Glen Kent To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=001a11c36cde2ce99104e7439f06 Cc: "rtg-bfd@ietf.org" , "Jeff Haas \(jhaas@juniper.net\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 06:38:55 -0000 --001a11c36cde2ce99104e7439f06 Content-Type: text/plain; charset=ISO-8859-1 Nobo, Why cant we use the existing BFD to form sessions between the controller and the terminating routers in non MPLS scenarios (or when static LSPs are provisioned)? I am afraid i did not get that point. If we use the S-BFD, then the controller would be the "client" and the egress routers, the "reflector", is it? What do we gain by using S-BFD there? Glen On Thu, Sep 26, 2013 at 4:20 AM, Nobo Akiya (nobo) wrote: > Hi Marc, Binny, et al, > > I agree with your statement of "right fit" for seamless BFD and existing > BFD. > > > Anyway, good discussions are always fine with me :-) > > Ok :) > > Since SDN was mentioned, perhaps we can dive a bit further into that > topic. I can see one approach being that SDN provisions BFD sessions on > necessary nodes. Or in a network where there's clean(er) separation of > control plane and data plane, then I can also see permanent monitor packets > to be generated from the controller device. Such packets can anything as > long as they originate from the controller device and terminates at the > controller device. Problem is that packet instructed to take arbitrary path > and back to self makes it difficult to guarantee that packet did "loop" at > intended node. Thus there's a need for such permanent monitor packet to > take arbitrary path to intended target, and have intended target generate a > response packet back to the controller device. That means such packets > cannot be anything, but must be defined. > > To place more twist into this, statically provisioned LSPs (aka static > LSP, MPLS static) is one network architecture where SDN-like is likely. If > we want to use BFD initiated from controller devices, as above, we need > something more than existing BFD. If we want to use traditional model of > BFD provisioned at LSP ingress(es), then do we want to reuse RFC5884 with > new FEC defined for static? > > I see S-BFD to be the "right fit" for these scenarios as well. > > -Nobo > > > -----Original Message----- > > From: Binny Jeshan [mailto:binnyjeshan@gmail.com] > > Sent: Tuesday, September 24, 2013 11:19 AM > > To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) > > Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > > Subject: RE: Discovering IP address to use for uBFD sessions > > > > I agree with Marc. > > > > Regards, > > Binny. > > > > Sent from Nokia Lumia. > > ________________________________________ > > From: Marc Binderberger > > Sent: 24-09-2013 06:51 PM > > To: Jeffrey Haas; Nobo Akiya (nobo) > > Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > > Subject: Re: Discovering IP address to use for uBFD sessions > > Hello, > > > > I think we can play on time regarding this topic. If there are specific > > requests they may drive the discussion again. Also over time network > > designs change. Who knows, in a few years the out-of-band > > synchronization between two network nodes may be a side effect of SDN > > and the "discovery" comes for free ;-) > > > > Not sure how seamless BFD is fitting into scenarios with two-sided BFD > > like uBFD sessions. Each technology has it's area where it is the right > > fit; for seamless I see everything that is uni-directional and/or > > virtual - LSPs, tunnels, etc., as an excellent fit and seamless BFD as > > probably superior over our existing two-sided BFD. As long as something > > is fixed - either physical like a wire or fixed configured - I would > > see the existing BFD as the best fit. > > > > > > Anyway, good discussions are always fine with me :-) > > > > > > Regards, Marc > > > > > > > > > > On Wed, 18 Sep 2013 17:57:59 -0400, Jeffrey Haas wrote: > > > On Thu, Jul 11, 2013 at 07:49:11PM +0000, Nobo Akiya (nobo) wrote: > > >> [hat on] > > >> > > >> I had a discussion with Jeff on this topic. > > >> > > >> We have concluded that there isn???t sufficient WG interest to > > >> pursue adoption of dynamic address discovery at this time. However > > >> note, such work, if interest appears, is in scope for the existing > > >> charter. > > > > > > To bump this thread, the seamless BFD proposal may cover this use case. > > > > > > With regard to only BFD on LAG, it was the consensus of the initial > > > developers and authors that configuration was sufficient for the time > > being > > > and satisfied the original customer use case. But as noted elsewhere, > > > people keep asking about this. :-) > > > > > > -- Jeff > > > > --001a11c36cde2ce99104e7439f06 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Nobo,

Why cant we use the existing BFD = to form sessions between the controller and the terminating routers in non = MPLS scenarios (or when static LSPs are provisioned)? I am afraid i did not= get that point.

If we use the S-BFD, then the controller would be the &= quot;client" and the egress routers, the "reflector", is it?=

What do we gain by using S-BFD there?=A0

Glen


On Thu, Sep 26, 2013 at 4:20 AM, Nobo Akiya (nobo) <nobo@cisco.co= m> wrote:
Hi Marc, Binny, et al,

I agree with your statement of "right fit" for seamless BFD and e= xisting BFD.

> Anyway, good discussions are always fine with me :-)

Ok :)

Since SDN was mentioned, perhaps we can dive a bit further into that topic.= I can see one approach being that SDN provisions BFD sessions on necessary= nodes. Or in a network where there's clean(er) separation of control p= lane and data plane, then I can also see permanent monitor packets to be ge= nerated from the controller device. Such packets can anything as long as th= ey originate from the controller device and terminates at the controller de= vice. Problem is that packet instructed to take arbitrary path and back to = self makes it difficult to guarantee that packet did "loop" at in= tended node. Thus there's a need for such permanent monitor packet to t= ake arbitrary path to intended target, and have intended target generate a = response packet back to the controller device. That means such packets cann= ot be anything, but must be defined.

To place more twist into this, statically provisioned LSPs (aka static LSP,= MPLS static) is one network architecture where SDN-like is likely. If we w= ant to use BFD initiated from controller devices, as above, we need somethi= ng more than existing BFD. If we want to use traditional model of BFD provi= sioned at LSP ingress(es), then do we want to reuse RFC5884 with new FEC de= fined for static?

I see S-BFD to be the "right fit" for these scenarios as well.
-Nobo

> -----Original Message-----
> From: Binny Jeshan [mailto:bi= nnyjeshan@gmail.com]
> Sent: Tuesday, September 24, 2013 11:19 AM
> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo)
> Cc: Jeff Haas (jhaas@juniper.net<= /a>); rtg-bfd@ietf.org
> Subject: RE: Discovering IP address to use for= uBFD sessions
>
> I agree with Marc.
>
> Regards,
> Binny.
>
> Sent from Nokia Lumia.
> ________________________________________
> From: Marc Binderberger
> Sent: 24-09-2013 06:51 PM
> To: Jeffrey Haas; Nobo Akiya (nobo)
> Cc: Jeff Haas (jhaas@juniper.net<= /a>); rtg-bfd@ietf.org
> Subject: Re: Discovering IP address to use for uBFD sessions
> Hello,
>
> I think we can play on time regarding this topic. If there are specifi= c
> requests they may drive the discussion again. Also over time network > designs change. Who knows, in a few years the out-of-band
> synchronization between two network nodes may be a side effect of SDN<= br> > and the "discovery" comes for free ;-)
>
> Not sure how seamless BFD is fitting into scenarios with two-sided BFD=
> like uBFD sessions. Each technology has it's area where it is the = right
> fit; for seamless I see everything that is uni-directional and/or
> virtual - LSPs, tunnels, etc., as an excellent fit and seamless BFD as=
> probably superior over our existing two-sided BFD. As long as somethin= g
> is fixed - either physical like a wire or fixed configured - I would > see the existing BFD as the best fit.
>
>
> Anyway, good discussions are always fine with me :-)
>
>
> Regards, Marc
>
>
>
>
> On Wed, 18 Sep 2013 17:57:59 -0400, Jeffrey Haas wrote:
> > On Thu, Jul 11, 2013 at 07:49:11PM +0000, Nobo Akiya (nobo) wrote= :
> >> [hat on]
> >>
> >> I had a discussion with Jeff on this topic.
> >>
> >> We have concluded that there isn???t sufficient WG interest t= o
> >> pursue adoption of dynamic address discovery at this time. Ho= wever
> >> note, such work, if interest appears, is in scope for the exi= sting
> >> charter.
> >
> > To bump this thread, the seamless BFD proposal may cover this use= case.
> >
> > With regard to only BFD on LAG, it was the consensus of the initi= al
> > developers and authors that configuration was sufficient for the = time
> being
> > and satisfied the original customer use case.=A0 But as noted els= ewhere,
> > people keep asking about this. :-)
> >
> > -- Jeff
> >

--001a11c36cde2ce99104e7439f06-- From nobo@cisco.com Thu Sep 26 07:04:41 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A788D21F856A for ; Thu, 26 Sep 2013 07:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] 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 H9Hu6DdBpam8 for ; Thu, 26 Sep 2013 07:04:34 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 30C4821F8578 for ; Thu, 26 Sep 2013 07:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8805; q=dns/txt; s=iport; t=1380204252; x=1381413852; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5b/W1TQAg4NbJ7IaZKTj+Kfra50fO8fXIWpU+100hUM=; b=RNt9HTJJzJgHKB6zwQI2zfHYh28gbBxGRtfvMaTXpMMlKo8ERPMjLNt1 le1/jFOILEI8pSZGKIoUL+LYJkRo4Enhf3IIZ5hocGp/A/N5k18LH9iBj t+uRLToNXi5wjMUgSgf0TNVdpyi966aMrzz+XzvhSjHLif7HFh/Ube1Zz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFALM9RFKtJXHA/2dsb2JhbABbgmYhgQrAU4EkFnSCJQEBAQMBbAoDBQcEAgEIEQEDAQEBCh0HIREUAwYIAgQOBQgTh1kDCQYBsysNiWqMZoI6MQcGgxeBAQOJAY0Tji2FNIMkgWokHA X-IronPort-AV: E=Sophos;i="4.90,986,1371081600"; d="scan'208";a="264822447" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 26 Sep 2013 14:04:07 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8QE47BR005255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 14:04:07 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 09:04:07 -0500 From: "Nobo Akiya (nobo)" To: Glen Kent Subject: RE: Discovering IP address to use for uBFD sessions Thread-Topic: Discovering IP address to use for uBFD sessions Thread-Index: AQHOuTlyw9kYHM4ciEaGS96ovWjjFJnWakTQgAF9NACAABP8EA== Date: Thu, 26 Sep 2013 14:04:06 +0000 Message-ID: References: <5241ad62.a5f2440a.1102.1a0e@mx.google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" , "Jeff Haas \(jhaas@juniper.net\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 14:04:41 -0000 Hi Glen, et al, > scenarios (or when static LSPs are > provisioned)? Allow me to start with this. | C / \ B D | | - A E- \ / G-F | | CON Controller device CON wants to validate LSP{A, B, C} and LSP{E, D, C}. LSP{A, B, C}: Since CON wants to test LSP starting from {A} and terminating= on {C}, label stack imposed by CON should be {A}{C}. LSP{E, D, C}: Since CON wants to test LSP starting from {E} and terminating= on {C}, label stack imposed by CON should be {E}{C}. This results in CON testing 4 paths. LSP{CON, G, A} LSP{A, B, C} LSP{CON, F, E} LSP{E, D, C} If we extend RFC5884 for static LSPs, then we'll have a FEC defined for pre= fix. CON would need to generate 4 LSP pings, corresponding to 4 LSPs mentioned a= bove. - One LSP ping destined for FEC{A}. - One LSP ping for FEC FEC{E}. - Two LSP pings for FEC{C}. 1. Larger number of LSP ping is one concerning point. LSP ping is a really = powerful tool, but many implementations has scale/perf constraints compared= to BFD. In addition: 2. How will {C} differentiate between received LSP ping for LSP{A, B, C} a= nd LSP{E, D, C}? FEC will be the same, source IP address will be the same. 3. LSP ping for LSP{A, B, C} and LSP{E, D, C} may not be in-band. - If CON to C was ECMP, then LSP ping from CON to C for both LSPs could= go on either paths. - If CON to C was non-ECMP, then LSP ping from CON to C for both LSPs w= ill go on one path. Of course for new LSP provisioned from X to C, it could take good chunk of = time for CON to verify the LSP. Some concerns are addressable (2), and some are moot (3) depending on who y= ou ask. But when all is considered, it makes me wonder whether this is a go= od solution. This is an aspect which I'd like to hear from you and others. > If we use the S-BFD, then the controller would be the "client" and the > egress routers, the "reflector", is it? That's correct. > What do we gain by using S-BFD there? No LSP ping is needed. Verification is immediate. Egress stateless (no sessions needed on target nodes). Controller can slow down packet rate, speed up packet rate, stop, resume at= any time. Alert discriminator allows for fault isolation upon failure. In above example, CON can send 4 types of packets. Label{A} Label{A}{C} Label{E} Label{E}{C} For permanent monitor initiated from controller device, there are two gener= al techniques. a. OAM packet that has instruction for forward path as well as reverse path= . - Weakness with this is that it's difficult to guarantee that forward p= ath reached the target. - Strength with this is that reverse path is controlled. - Packet can be any (no standard required). b. OAM packet that has instruction for forward path only. - Strength with this is that there's guarantee that forward path reache= d the target. - Weakness with this is that reverse path isn't controlled. - Packet must be pre-defined (standard required). S-BFD is (b) technique. (a) and (b) complements either other, thus I see va= lue in controller device initiated permanent monitor to provision both. > in non MPLS scenarios In IP scenario, if we want to perform permanent monitor from controller dev= ice, we would have to create a tunnel and pre-route the packet to starting = node, so there's added complexity. It can be done but provisioning BFD (exi= sting or seamless) at starting node still appears attractive. I hope this helps. With that said, S-BFD is still rough around the edges. Couple of authors ar= e actively working on the next revision, but what's defined so far is a goo= d starting point to allow BFD to better fit in some areas where existing BF= D has concerns. -Nobo > -----Original Message----- > From: Glen Kent [mailto:glen.kent@gmail.com] > Sent: Thursday, September 26, 2013 2:39 AM > To: Nobo Akiya (nobo) > Cc: Binny Jeshan; Marc Binderberger; Jeffrey Haas; Jeff Haas > (jhaas@juniper.net); rtg-bfd@ietf.org > Subject: Re: Discovering IP address to use for uBFD sessions >=20 > Nobo, >=20 > Why cant we use the existing BFD to form sessions between the controller > and the terminating routers in non MPLS scenarios (or when static LSPs ar= e > provisioned)? I am afraid i did not get that point. >=20 > If we use the S-BFD, then the controller would be the "client" and the > egress routers, the "reflector", is it? >=20 > What do we gain by using S-BFD there? >=20 > Glen >=20 > On Thu, Sep 26, 2013 at 4:20 AM, Nobo Akiya (nobo) > wrote: > Hi Marc, Binny, et al, >=20 > I agree with your statement of "right fit" for seamless BFD and existing = BFD. >=20 > > Anyway, good discussions are always fine with me :-) > Ok :) >=20 > Since SDN was mentioned, perhaps we can dive a bit further into that topi= c. > I can see one approach being that SDN provisions BFD sessions on necessar= y > nodes. Or in a network where there's clean(er) separation of control plan= e > and data plane, then I can also see permanent monitor packets to be > generated from the controller device. Such packets can anything as long a= s > they originate from the controller device and terminates at the controlle= r > device. Problem is that packet instructed to take arbitrary path and back= to > self makes it difficult to guarantee that packet did "loop" at intended n= ode. > Thus there's a need for such permanent monitor packet to take arbitrary > path to intended target, and have intended target generate a response > packet back to the controller device. That means such packets cannot be > anything, but must be defined. >=20 > To place more twist into this, statically provisioned LSPs (aka static LS= P, > MPLS static) is one network architecture where SDN-like is likely. If we = want > to use BFD initiated from controller devices, as above, we need something > more than existing BFD. If we want to use traditional model of BFD > provisioned at LSP ingress(es), then do we want to reuse RFC5884 with new > FEC defined for static? >=20 > I see S-BFD to be the "right fit" for these scenarios as well. >=20 > -Nobo >=20 > > -----Original Message----- > > From: Binny Jeshan [mailto:binnyjeshan@gmail.com] > > Sent: Tuesday, September 24, 2013 11:19 AM > > To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) > > Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > > Subject: RE: Discovering IP address to use for uBFD sessions > > > > I agree with Marc. > > > > Regards, > > Binny. > > > > Sent from Nokia Lumia. > > ________________________________________ > > From: Marc Binderberger > > Sent: 24-09-2013 06:51 PM > > To: Jeffrey Haas; Nobo Akiya (nobo) > > Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > > Subject: Re: Discovering IP address to use for uBFD sessions > > Hello, > > > > I think we can play on time regarding this topic. If there are specific > > requests they may drive the discussion again. Also over time network > > designs change. Who knows, in a few years the out-of-band > > synchronization between two network nodes may be a side effect of SDN > > and the "discovery" comes for free ;-) > > > > Not sure how seamless BFD is fitting into scenarios with two-sided BFD > > like uBFD sessions. Each technology has it's area where it is the right > > fit; for seamless I see everything that is uni-directional and/or > > virtual - LSPs, tunnels, etc., as an excellent fit and seamless BFD as > > probably superior over our existing two-sided BFD. As long as something > > is fixed - either physical like a wire or fixed configured - I would > > see the existing BFD as the best fit. > > > > > > Anyway, good discussions are always fine with me :-) > > > > > > Regards, Marc > > > > > > > > > > On Wed, 18 Sep 2013 17:57:59 -0400, Jeffrey Haas wrote: > > > On Thu, Jul 11, 2013 at 07:49:11PM +0000, Nobo Akiya (nobo) wrote: > > >> [hat on] > > >> > > >> I had a discussion with Jeff on this topic. > > >> > > >> We have concluded that there isn???t sufficient WG interest to > > >> pursue adoption of dynamic address discovery at this time. However > > >> note, such work, if interest appears, is in scope for the existing > > >> charter. > > > > > > To bump this thread, the seamless BFD proposal may cover this use cas= e. > > > > > > With regard to only BFD on LAG, it was the consensus of the initial > > > developers and authors that configuration was sufficient for the time > > being > > > and satisfied the original customer use case.=A0 But as noted elsewhe= re, > > > people keep asking about this. :-) > > > > > > -- Jeff > > > From marc@sniff.de Fri Sep 27 10:37:51 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0693C11E8103 for ; Fri, 27 Sep 2013 10:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, J_BACKHAIR_31=1, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6] 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 Osl8d8XvrApT for ; Fri, 27 Sep 2013 10:37:50 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4488021F9CDF for ; Fri, 27 Sep 2013 10:37:49 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 16E7F2AA0F; Fri, 27 Sep 2013 17:37:47 +0000 (GMT) Date: Fri, 27 Sep 2013 19:37:46 +0200 From: Marc Binderberger To: Nobo Akiya (nobo) , Glen Kent Message-ID: <20130927193746145209.41391f65@sniff.de> In-Reply-To: References: <5241ad62.a5f2440a.1102.1a0e@mx.google.com> Subject: RE: Discovering IP address to use for uBFD sessions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Cc: "rtg-bfd@ietf.org" , "Jeff Haas \(jhaas@juniper.net\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 17:37:51 -0000 Hello Nobo et al., not sure I agree with the details of the example but I agree with the conclusions ;-) Serious: >> If we use the S-BFD, then the controller would be the "client" and the >> egress routers, the "reflector", is it? > > That's correct. okay, that is possible but not sure I would go with this design :-) Multiple reasons: you want to check A->B->C/E->D->C , not making things more complex with the path CON<->A/E. (this is why in the past one used SNMP to trigger an IP ping between routers from the management station) Also scale for receiving the packets may be challenging - the network device is designed to handle a certain BFD scale and not miss packets under high load - and the need to implement BFD (subset) on the controller. Nevertheless, S-BFD compared to RFC5884 allows for ad-hoc checks to be done simpler. In a "true" SDN style I would expect the controller to activate an API on A to check for the path A->B->C with N packets and would get a report back. So with S-BFD the controller talks to A and E, gets a report, done. With RFC5884 you would need to setup (and tear down) a session between A-C and E-C. Possible but as mentioned in an earlier email by Nobo you then need to handle the "going up" time which is not (upper-)bounded. Killer argument for S-BFD over RFC5884? No but I think it's another reason on top of others. Regards, Marc On Thu, 26 Sep 2013 14:04:06 +0000, Nobo Akiya (nobo) wrote: > Hi Glen, et al, > >> scenarios (or when static LSPs are >> provisioned)? > > Allow me to start with this. > > | > C > / \ > B D > | | > - A E- > \ / > G-F > | | > CON > > Controller device CON wants to validate LSP{A, B, C} and LSP{E, D, C}. > > LSP{A, B, C}: Since CON wants to test LSP starting from {A} and > terminating on {C}, label stack imposed by CON should be {A}{C}. > LSP{E, D, C}: Since CON wants to test LSP starting from {E} and > terminating on {C}, label stack imposed by CON should be {E}{C}. > > This results in CON testing 4 paths. > LSP{CON, G, A} > LSP{A, B, C} > LSP{CON, F, E} > LSP{E, D, C} > > If we extend RFC5884 for static LSPs, then we'll have a FEC defined > for prefix. > CON would need to generate 4 LSP pings, corresponding to 4 LSPs > mentioned above. > - One LSP ping destined for FEC{A}. > - One LSP ping for FEC FEC{E}. > - Two LSP pings for FEC{C}. > > 1. Larger number of LSP ping is one concerning point. LSP ping is a > really powerful tool, but many implementations has scale/perf > constraints compared to BFD. > > In addition: > > 2. How will {C} differentiate between received LSP ping for LSP{A, > B, C} and LSP{E, D, C}? FEC will be the same, source IP address will > be the same. > 3. LSP ping for LSP{A, B, C} and LSP{E, D, C} may not be in-band. > - If CON to C was ECMP, then LSP ping from CON to C for both LSPs > could go on either paths. > - If CON to C was non-ECMP, then LSP ping from CON to C for both > LSPs will go on one path. > > Of course for new LSP provisioned from X to C, it could take good > chunk of time for CON to verify the LSP. > > Some concerns are addressable (2), and some are moot (3) depending on > who you ask. But when all is considered, it makes me wonder whether > this is a good solution. This is an aspect which I'd like to hear > from you and others. > >> If we use the S-BFD, then the controller would be the "client" and the >> egress routers, the "reflector", is it? > > That's correct. > >> What do we gain by using S-BFD there? > > No LSP ping is needed. > Verification is immediate. > Egress stateless (no sessions needed on target nodes). > Controller can slow down packet rate, speed up packet rate, stop, > resume at any time. > Alert discriminator allows for fault isolation upon failure. > > In above example, CON can send 4 types of packets. > Label{A} > Label{A}{C} > Label{E} > Label{E}{C} > > For permanent monitor initiated from controller device, there are two > general techniques. > a. OAM packet that has instruction for forward path as well as reverse path. > - Weakness with this is that it's difficult to guarantee that > forward path reached the target. > - Strength with this is that reverse path is controlled. > - Packet can be any (no standard required). > b. OAM packet that has instruction for forward path only. > - Strength with this is that there's guarantee that forward path > reached the target. > - Weakness with this is that reverse path isn't controlled. > - Packet must be pre-defined (standard required). > > S-BFD is (b) technique. (a) and (b) complements either other, thus I > see value in controller device initiated permanent monitor to > provision both. > >> in non MPLS scenarios > > In IP scenario, if we want to perform permanent monitor from > controller device, we would have to create a tunnel and pre-route the > packet to starting node, so there's added complexity. It can be done > but provisioning BFD (existing or seamless) at starting node still > appears attractive. > > I hope this helps. > > With that said, S-BFD is still rough around the edges. Couple of > authors are actively working on the next revision, but what's defined > so far is a good starting point to allow BFD to better fit in some > areas where existing BFD has concerns. > > -Nobo > >> -----Original Message----- >> From: Glen Kent [mailto:glen.kent@gmail.com] >> Sent: Thursday, September 26, 2013 2:39 AM >> To: Nobo Akiya (nobo) >> Cc: Binny Jeshan; Marc Binderberger; Jeffrey Haas; Jeff Haas >> (jhaas@juniper.net); rtg-bfd@ietf.org >> Subject: Re: Discovering IP address to use for uBFD sessions >> >> Nobo, >> >> Why cant we use the existing BFD to form sessions between the controller >> and the terminating routers in non MPLS scenarios (or when static LSPs are >> provisioned)? I am afraid i did not get that point. >> >> If we use the S-BFD, then the controller would be the "client" and the >> egress routers, the "reflector", is it? >> >> What do we gain by using S-BFD there? >> >> Glen >> >> On Thu, Sep 26, 2013 at 4:20 AM, Nobo Akiya (nobo) >> wrote: >> Hi Marc, Binny, et al, >> >> I agree with your statement of "right fit" for seamless BFD and >> existing BFD. >> >>> Anyway, good discussions are always fine with me :-) >> Ok :) >> >> Since SDN was mentioned, perhaps we can dive a bit further into that topic. >> I can see one approach being that SDN provisions BFD sessions on necessary >> nodes. Or in a network where there's clean(er) separation of control plane >> and data plane, then I can also see permanent monitor packets to be >> generated from the controller device. Such packets can anything as long as >> they originate from the controller device and terminates at the controller >> device. Problem is that packet instructed to take arbitrary path and >> back to >> self makes it difficult to guarantee that packet did "loop" at >> intended node. >> Thus there's a need for such permanent monitor packet to take arbitrary >> path to intended target, and have intended target generate a response >> packet back to the controller device. That means such packets cannot be >> anything, but must be defined. >> >> To place more twist into this, statically provisioned LSPs (aka static LSP, >> MPLS static) is one network architecture where SDN-like is likely. >> If we want >> to use BFD initiated from controller devices, as above, we need something >> more than existing BFD. If we want to use traditional model of BFD >> provisioned at LSP ingress(es), then do we want to reuse RFC5884 with new >> FEC defined for static? >> >> I see S-BFD to be the "right fit" for these scenarios as well. >> >> -Nobo >> >>> -----Original Message----- >>> From: Binny Jeshan [mailto:binnyjeshan@gmail.com] >>> Sent: Tuesday, September 24, 2013 11:19 AM >>> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) >>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org >>> Subject: RE: Discovering IP address to use for uBFD sessions >>> >>> I agree with Marc. >>> >>> Regards, >>> Binny. >>> >>> Sent from Nokia Lumia. >>> ________________________________________ >>> From: Marc Binderberger >>> Sent: 24-09-2013 06:51 PM >>> To: Jeffrey Haas; Nobo Akiya (nobo) >>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org >>> Subject: Re: Discovering IP address to use for uBFD sessions >>> Hello, >>> >>> I think we can play on time regarding this topic. If there are specific >>> requests they may drive the discussion again. Also over time network >>> designs change. Who knows, in a few years the out-of-band >>> synchronization between two network nodes may be a side effect of SDN >>> and the "discovery" comes for free ;-) >>> >>> Not sure how seamless BFD is fitting into scenarios with two-sided BFD >>> like uBFD sessions. Each technology has it's area where it is the right >>> fit; for seamless I see everything that is uni-directional and/or >>> virtual - LSPs, tunnels, etc., as an excellent fit and seamless BFD as >>> probably superior over our existing two-sided BFD. As long as something >>> is fixed - either physical like a wire or fixed configured - I would >>> see the existing BFD as the best fit. >>> >>> >>> Anyway, good discussions are always fine with me :-) >>> >>> >>> Regards, Marc >>> >>> >>> >>> >>> On Wed, 18 Sep 2013 17:57:59 -0400, Jeffrey Haas wrote: >>>> On Thu, Jul 11, 2013 at 07:49:11PM +0000, Nobo Akiya (nobo) wrote: >>>>> [hat on] >>>>> >>>>> I had a discussion with Jeff on this topic. >>>>> >>>>> We have concluded that there isn???t sufficient WG interest to >>>>> pursue adoption of dynamic address discovery at this time. However >>>>> note, such work, if interest appears, is in scope for the existing >>>>> charter. >>>> >>>> To bump this thread, the seamless BFD proposal may cover this use case. >>>> >>>> With regard to only BFD on LAG, it was the consensus of the initial >>>> developers and authors that configuration was sufficient for the time >>> being >>>> and satisfied the original customer use case. But as noted elsewhere, >>>> people keep asking about this. :-) >>>> >>>> -- Jeff >>>> > From nobo@cisco.com Fri Sep 27 14:43:25 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D250421E808C for ; Fri, 27 Sep 2013 14:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, J_BACKHAIR_31=1, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] 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 fzVilRqT-bTE for ; Fri, 27 Sep 2013 14:43:19 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B067821E8053 for ; Fri, 27 Sep 2013 14:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13414; q=dns/txt; s=iport; t=1380318200; x=1381527800; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=K+n38BBvtu6S4rRhCU/+F95s+G05gWDEo1h/544Pq7M=; b=EzTV5d9DGiS5/QukNdn3qhTDrOoE0GiKuLZDk7WP17g0Kz0qiB7O/RRN YVF9BpgsanayArCVSpXARSqhUlUS08OOnOFLtPphlnbUJ0uHuXJlvWnhd jFlFCgqB6MyLmgua2uGyBqGtnIrA7LjoexSLGgMGGZUP0vrgSx6REqcuv 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAHX7RVKtJV2c/2dsb2JhbABbgmYhgQrAU4EhFnSCJQEBAQMBJxMyCgMFBwQCAQgRAQMBAQEKFAkHIREUAwYIAgQBDQUIE4dZAwkGAbAmDYlqjGaBIoEYMQcGgxmBAQOWFo4thTSDJIFqBxcGHA X-IronPort-AV: E=Sophos;i="4.90,996,1371081600"; d="scan'208";a="262501388" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 27 Sep 2013 21:43:19 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8RLhIU8024035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Sep 2013 21:43:18 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 16:43:18 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , Glen Kent Subject: RE: Discovering IP address to use for uBFD sessions Thread-Topic: Discovering IP address to use for uBFD sessions Thread-Index: AQHOuTlyw9kYHM4ciEaGS96ovWjjFJnWakTQgAF9NACAABP8EIACNngA//+0NMA= Date: Fri, 27 Sep 2013 21:43:17 +0000 Message-ID: References: <5241ad62.a5f2440a.1102.1a0e@mx.google.com> <20130927193746145209.41391f65@sniff.de> In-Reply-To: <20130927193746145209.41391f65@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" , Jeff Haas X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 21:43:25 -0000 Hi Marc, et al, Thanks for taking time to respond! > not sure I agree with the details of the example but I agree with the > conclusions ;-) I'm quite glad to hear that actually :) I'm pushing for S-BFD as an infrastructure, by exhibiting some possible use= cases. But exact provisioning model for various technologies, including st= atic LSP, I believe that we will need requirements/discussions and time for= WG/people to converge. > >> If we use the S-BFD, then the controller would be the "client" and > >> the egress routers, the "reflector", is it? > > > > That's correct. >=20 > okay, that is possible but not sure I would go with this design :-) Ok we agree that egress must be reflector. For the question of where is the= initiator, I don't agree nor disagree with you at this point (as indicated= above, I'm not arguing for any particular provisioning model at this point= ). When there are S-BFD reflection points in the network, operator can prov= ision one or the other, or both, or more if required. What you pointed out very well may be for powerful products with rich featu= re set. Although, operators may still desire to run many OAM aspects from c= ontroller device(s), to allow for quicker deployments (removes feature requ= est dependencies to multiple products/vendors) or for other reasons. For lo= wer end products and/or products with minimal feature set, there may not be= a choice but to run OAM from controller device(s). Reasons being those pro= ducts may not have sufficient BFD support, or may not have sufficient BFD s= cale/perf numbers. Implementing just S-BFD reflector sessions will likely b= e far more simpler than implementing various flavors of BFD. If low end pro= ducts can at least implement just S-BFD reflection points, then operators c= an perform much greater permanent monitor in their network centrally. > Killer argument for S-BFD over RFC5884? No but I think it's another reas= on > on top of others. :) -Nobo > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Friday, September 27, 2013 1:38 PM > To: Nobo Akiya (nobo); Glen Kent > Cc: Binny Jeshan; Jeffrey Haas; Jeff Haas; rtg-bfd@ietf.org > Subject: RE: Discovering IP address to use for uBFD sessions >=20 > Hello Nobo et al., >=20 > not sure I agree with the details of the example but I agree with the > conclusions ;-) >=20 > Serious: >=20 > >> If we use the S-BFD, then the controller would be the "client" and > >> the egress routers, the "reflector", is it? > > > > That's correct. >=20 > okay, that is possible but not sure I would go with this design :-) Multi= ple > reasons: you want to check A->B->C/E->D->C , not making things more > complex with the path CON<->A/E. (this is why in the past one used SNMP > to trigger an IP ping between routers from the management > station) Also scale for receiving the packets may be challenging - the > network device is designed to handle a certain BFD scale and not miss > packets under high load - and the need to implement BFD (subset) on the > controller. >=20 > Nevertheless, S-BFD compared to RFC5884 allows for ad-hoc checks to be > done simpler. In a "true" SDN style I would expect the controller to acti= vate > an API on A to check for the path A->B->C with N packets and would get a > report back. So with S-BFD the controller talks to A and E, gets a report= , done. > With RFC5884 you would need to setup (and tear > down) a session between A-C and E-C. Possible but as mentioned in an > earlier email by Nobo you then need to handle the "going up" time which i= s > not (upper-)bounded. >=20 >=20 > Killer argument for S-BFD over RFC5884? No but I think it's another reas= on > on top of others. >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > On Thu, 26 Sep 2013 14:04:06 +0000, Nobo Akiya (nobo) wrote: > > Hi Glen, et al, > > > >> scenarios (or when static LSPs are > >> provisioned)? > > > > Allow me to start with this. > > > > | > > C > > / \ > > B D > > | | > > - A E- > > \ / > > G-F > > | | > > CON > > > > Controller device CON wants to validate LSP{A, B, C} and LSP{E, D, C}. > > > > LSP{A, B, C}: Since CON wants to test LSP starting from {A} and > > terminating on {C}, label stack imposed by CON should be {A}{C}. > > LSP{E, D, C}: Since CON wants to test LSP starting from {E} and > > terminating on {C}, label stack imposed by CON should be {E}{C}. > > > > This results in CON testing 4 paths. > > LSP{CON, G, A} > > LSP{A, B, C} > > LSP{CON, F, E} > > LSP{E, D, C} > > > > If we extend RFC5884 for static LSPs, then we'll have a FEC defined > > for prefix. > > CON would need to generate 4 LSP pings, corresponding to 4 LSPs > > mentioned above. > > - One LSP ping destined for FEC{A}. > > - One LSP ping for FEC FEC{E}. > > - Two LSP pings for FEC{C}. > > > > 1. Larger number of LSP ping is one concerning point. LSP ping is a > > really powerful tool, but many implementations has scale/perf > > constraints compared to BFD. > > > > In addition: > > > > 2. How will {C} differentiate between received LSP ping for LSP{A, > > B, C} and LSP{E, D, C}? FEC will be the same, source IP address will > > be the same. > > 3. LSP ping for LSP{A, B, C} and LSP{E, D, C} may not be in-band. > > - If CON to C was ECMP, then LSP ping from CON to C for both LSPs > > could go on either paths. > > - If CON to C was non-ECMP, then LSP ping from CON to C for both > > LSPs will go on one path. > > > > Of course for new LSP provisioned from X to C, it could take good > > chunk of time for CON to verify the LSP. > > > > Some concerns are addressable (2), and some are moot (3) depending on > > who you ask. But when all is considered, it makes me wonder whether > > this is a good solution. This is an aspect which I'd like to hear > > from you and others. > > > >> If we use the S-BFD, then the controller would be the "client" and the > >> egress routers, the "reflector", is it? > > > > That's correct. > > > >> What do we gain by using S-BFD there? > > > > No LSP ping is needed. > > Verification is immediate. > > Egress stateless (no sessions needed on target nodes). > > Controller can slow down packet rate, speed up packet rate, stop, > > resume at any time. > > Alert discriminator allows for fault isolation upon failure. > > > > In above example, CON can send 4 types of packets. > > Label{A} > > Label{A}{C} > > Label{E} > > Label{E}{C} > > > > For permanent monitor initiated from controller device, there are two > > general techniques. > > a. OAM packet that has instruction for forward path as well as reverse = path. > > - Weakness with this is that it's difficult to guarantee that > > forward path reached the target. > > - Strength with this is that reverse path is controlled. > > - Packet can be any (no standard required). > > b. OAM packet that has instruction for forward path only. > > - Strength with this is that there's guarantee that forward path > > reached the target. > > - Weakness with this is that reverse path isn't controlled. > > - Packet must be pre-defined (standard required). > > > > S-BFD is (b) technique. (a) and (b) complements either other, thus I > > see value in controller device initiated permanent monitor to > > provision both. > > > >> in non MPLS scenarios > > > > In IP scenario, if we want to perform permanent monitor from > > controller device, we would have to create a tunnel and pre-route the > > packet to starting node, so there's added complexity. It can be done > > but provisioning BFD (existing or seamless) at starting node still > > appears attractive. > > > > I hope this helps. > > > > With that said, S-BFD is still rough around the edges. Couple of > > authors are actively working on the next revision, but what's defined > > so far is a good starting point to allow BFD to better fit in some > > areas where existing BFD has concerns. > > > > -Nobo > > > >> -----Original Message----- > >> From: Glen Kent [mailto:glen.kent@gmail.com] > >> Sent: Thursday, September 26, 2013 2:39 AM > >> To: Nobo Akiya (nobo) > >> Cc: Binny Jeshan; Marc Binderberger; Jeffrey Haas; Jeff Haas > >> (jhaas@juniper.net); rtg-bfd@ietf.org > >> Subject: Re: Discovering IP address to use for uBFD sessions > >> > >> Nobo, > >> > >> Why cant we use the existing BFD to form sessions between the > controller > >> and the terminating routers in non MPLS scenarios (or when static LSPs > are > >> provisioned)? I am afraid i did not get that point. > >> > >> If we use the S-BFD, then the controller would be the "client" and the > >> egress routers, the "reflector", is it? > >> > >> What do we gain by using S-BFD there? > >> > >> Glen > >> > >> On Thu, Sep 26, 2013 at 4:20 AM, Nobo Akiya (nobo) > >> wrote: > >> Hi Marc, Binny, et al, > >> > >> I agree with your statement of "right fit" for seamless BFD and > >> existing BFD. > >> > >>> Anyway, good discussions are always fine with me :-) > >> Ok :) > >> > >> Since SDN was mentioned, perhaps we can dive a bit further into that > topic. > >> I can see one approach being that SDN provisions BFD sessions on > necessary > >> nodes. Or in a network where there's clean(er) separation of control > plane > >> and data plane, then I can also see permanent monitor packets to be > >> generated from the controller device. Such packets can anything as lon= g > as > >> they originate from the controller device and terminates at the contro= ller > >> device. Problem is that packet instructed to take arbitrary path and > >> back to > >> self makes it difficult to guarantee that packet did "loop" at > >> intended node. > >> Thus there's a need for such permanent monitor packet to take arbitrar= y > >> path to intended target, and have intended target generate a response > >> packet back to the controller device. That means such packets cannot b= e > >> anything, but must be defined. > >> > >> To place more twist into this, statically provisioned LSPs (aka static= LSP, > >> MPLS static) is one network architecture where SDN-like is likely. > >> If we want > >> to use BFD initiated from controller devices, as above, we need > something > >> more than existing BFD. If we want to use traditional model of BFD > >> provisioned at LSP ingress(es), then do we want to reuse RFC5884 with > new > >> FEC defined for static? > >> > >> I see S-BFD to be the "right fit" for these scenarios as well. > >> > >> -Nobo > >> > >>> -----Original Message----- > >>> From: Binny Jeshan [mailto:binnyjeshan@gmail.com] > >>> Sent: Tuesday, September 24, 2013 11:19 AM > >>> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) > >>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > >>> Subject: RE: Discovering IP address to use for uBFD sessions > >>> > >>> I agree with Marc. > >>> > >>> Regards, > >>> Binny. > >>> > >>> Sent from Nokia Lumia. > >>> ________________________________________ > >>> From: Marc Binderberger > >>> Sent: 24-09-2013 06:51 PM > >>> To: Jeffrey Haas; Nobo Akiya (nobo) > >>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > >>> Subject: Re: Discovering IP address to use for uBFD sessions > >>> Hello, > >>> > >>> I think we can play on time regarding this topic. If there are specif= ic > >>> requests they may drive the discussion again. Also over time network > >>> designs change. Who knows, in a few years the out-of-band > >>> synchronization between two network nodes may be a side effect of > SDN > >>> and the "discovery" comes for free ;-) > >>> > >>> Not sure how seamless BFD is fitting into scenarios with two-sided BF= D > >>> like uBFD sessions. Each technology has it's area where it is the rig= ht > >>> fit; for seamless I see everything that is uni-directional and/or > >>> virtual - LSPs, tunnels, etc., as an excellent fit and seamless BFD a= s > >>> probably superior over our existing two-sided BFD. As long as > something > >>> is fixed - either physical like a wire or fixed configured - I would > >>> see the existing BFD as the best fit. > >>> > >>> > >>> Anyway, good discussions are always fine with me :-) > >>> > >>> > >>> Regards, Marc > >>> > >>> > >>> > >>> > >>> On Wed, 18 Sep 2013 17:57:59 -0400, Jeffrey Haas wrote: > >>>> On Thu, Jul 11, 2013 at 07:49:11PM +0000, Nobo Akiya (nobo) wrote: > >>>>> [hat on] > >>>>> > >>>>> I had a discussion with Jeff on this topic. > >>>>> > >>>>> We have concluded that there isn???t sufficient WG interest to > >>>>> pursue adoption of dynamic address discovery at this time. However > >>>>> note, such work, if interest appears, is in scope for the existing > >>>>> charter. > >>>> > >>>> To bump this thread, the seamless BFD proposal may cover this use > case. > >>>> > >>>> With regard to only BFD on LAG, it was the consensus of the initial > >>>> developers and authors that configuration was sufficient for the tim= e > >>> being > >>>> and satisfied the original customer use case. But as noted elsewher= e, > >>>> people keep asking about this. :-) > >>>> > >>>> -- Jeff > >>>> > >