Re: [Int-area] [v6ops] draft-patterson-intarea-ipoe-health-04 Post-IETF102 Discussion

"STARK, BARBARA H" <bs7652@att.com> Tue, 31 July 2018 18:50 UTC

Return-Path: <bs7652@att.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F24130E60; Tue, 31 Jul 2018 11:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBlR1-kdspjW; Tue, 31 Jul 2018 11:50:39 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1008D126CC7; Tue, 31 Jul 2018 11:50:38 -0700 (PDT)
Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w6VIjSeH014170; Tue, 31 Jul 2018 14:50:37 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2kjvxggp9q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Jul 2018 14:50:37 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w6VIoafp023874; Tue, 31 Jul 2018 14:50:36 -0400
Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w6VIoTKH023663; Tue, 31 Jul 2018 14:50:30 -0400
Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id D3FCA4048B41; Tue, 31 Jul 2018 18:50:29 +0000 (GMT)
Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30486.vci.att.com (Service) with ESMTPS id BB8C140002A3; Tue, 31 Jul 2018 18:50:29 +0000 (GMT)
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0408.000; Tue, 31 Jul 2018 14:50:29 -0400
From: "STARK, BARBARA H" <bs7652@att.com>
To: "'Richard Patterson'" <richard@helix.net.nz>, "int-area@ietf.org" <int-area@ietf.org>, "v6ops@ietf.org list" <v6ops@ietf.org>
Thread-Topic: [v6ops] draft-patterson-intarea-ipoe-health-04 Post-IETF102 Discussion
Thread-Index: AQHUKORT/DgFkM3jE0igdjSQtvrHfqSpkFkg
Date: Tue, 31 Jul 2018 18:50:28 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DE61603@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <CAHL_VyBF7Pwo5oFchffhkLMF+8kR1RurNG6QGwYhJT_HjqXf9A@mail.gmail.com>
In-Reply-To: <CAHL_VyBF7Pwo5oFchffhkLMF+8kR1RurNG6QGwYhJT_HjqXf9A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.61.166.232]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-31_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807310172
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/yghhi7MfZe7LoVea3SwuAPgfbcU>
Subject: Re: [Int-area] [v6ops] draft-patterson-intarea-ipoe-health-04 Post-IETF102 Discussion
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jul 2018 18:50:42 -0000

I went to my internal experts and had a chat with them about this draft. Here is some feedback on the draft.

Everyone I talked to agrees that keeping the IPoE "connection" up on access loops is important. [This relates to my saying at the v6ops session that Richard was right about this being a problem that he needs to solve in his network.]

However...
The consensus view here is that BFD Echo, when implemented as described in RFC 5881 and BBF specs, works. I don't have anyone asking for something more complex than what has already been specified in BBF TR-146 (and TR-124 for CPE, with management by TR-069 and the TR-181 data model parameters). There is no requirement here for manual configuration, DHCP configuration, or alternate DHCP mechanisms (Renew, Reconfigure, Rebind).

Getting vendors (CPE and BNG) to implement BFD Echo as currently specified is painful. Defining something more complex (BFD Echo plus DHCP options plus other configuration parameters and various methods of configuring) is unlikely to be easier to get implemented. Defining something that doesn't work as well as BFD Echo is undesirable.

It was the BNG vendors who said they preferred the current BFD Echo solution. Getting CE router vendors to implement is indeed very difficult. Convincing vendors to implement is definitely the most difficult aspect of BFD Echo.

A comment about CE routers: Although our CE routers do BFD Echo, we have (in our labs) experimented with implementing a CE router on a Linux kernel and discovered the kernel would not accept packets with a source address belonging to itself. [The BFD echo is an IP packet with the destination and source IPv4 addresses being identical and belonging to the CE router, because of BCP 38.] This is just a comment for anyone wanting to experiment. Our CE routers do support BFD Echo.

Here is a quote related to DHCP Renew and Reconfigure: "The Renew and Reconfigure approaches are useless as we found when we looked at that.  It doesn't help with an unplanned migration where the subscriber access is moved (e.g., card or node failure requiring rehoming a DSLAM to a BNG different port or node).  In those cases you can't send a Renew or Reconfigure since the IP context for the subscriber is lost."

To summarize:
I / we don't support Renew / Reconfigure or Rebind as options for what to do when BFD Echo indicates failure of connectivity. No need for DHCP Option to configure behavior for when BFD Echo fails. I / we do support BFD Echo. I / we are neutral on the creation of DHCP options to configure BFD Echo (TR-069/TR-181 configuration is ok for us).

More comments in-line, below.

Barbara

> -----Original Message-----
> From: Richard Patterson
> 
> Following on from the Q&As and hallway chats at IETF102, I've captured a few
> questions for further discussion on the lists.
> 
> - BFD Echo: Still requires a full BFD implementation.  Do we continue to
> specify BFD Echo specifically, as per TR-146, or do we rather specify a new
> "loopback" packet format to perform the same function, without full BFD.

BFD Echo works, and has been successfully implemented by many vendors. I / we see no need to define a new mechanism.

> - Complexity:  Do we need to define all 4 Behaviours?  Would it help with
> adoption if we remove the Renew and Rebind behaviours, and focus on the
> latter 2 behaviours that are more likely to facilitate session
> re-establishment?   (Perhaps combine behaviours 0,1,2 in to a
> converged method?  i.e., attempt a single renew, and rebind before moving
> to solicit/discover)

No, this complexity is not needed. Renew/Reconfigure is not useful. Rebind is also not needed. CE router does not need to be triggered -- failure of BFD Echo is sufficient trigger getting DHCPv4 and RS/RA/DHCPv6 processes started. 
 
> - Complexity2: Do we need to define 3 different health check methods?
> BFD Echo-style, ARP/ND, and Passive.    I think that BFD Echo-style
> and active ARP/ND checks are both worthwhile specify, but dropping passive
> checks for simplicity is probably a good idea.

No, we don't need complexity. Only one mechanism is needed. BFD Echo works.
 
> - Engage Vendors: Current behaviour of silently discarding of Renew
> messages is seen as a violation of RFC2131.  I agree that vendors could
> implement authentication on Renews, with additional complexity of
> validating current and pass lease-state.  It doesn't entirely mitigate the
> problem, but would expedite client recovery somewhat.

I / we don't support additional IPv4 DHCPv4 mandates on CE routers.
 
> - Engage Broadband Forum:  Discuss the problem and current limitations with
> their recommendations in TR-146, perhaps help drive a Broadband Forum
> equivalent of a -bis.

The best way to engage BBF is direct communication. IETF WGs and liaisons have very little influence in getting BBF to do work. Individuals (especially individuals willing to step up and be an editor or find someone to be an editor) are significantly more influential. If you want to try to get something done, I suggest you directly talk to Dave Allen and David Sinicrope (both of Ericsson, where Dave Allen chairs the BBF group who does BNG requirements and David Sinicrope is the BBF-IETF liaison officer). I am engaged in BBF CE router ("residential gateway", TR-124) specs, but am not willing to be a champion for this. What you really need to be successful with BBF is more ISPs (at BBF) to support you and/or your CE router and BNG vendors. I don't recommend trying to get v6ops or int-area to try to drive BBF for you. 

> I think engaging BBF is a good thing to happen anyway, but there are
> additional features of this draft, such as configurability and signalling of
> parameters via the DHCP option, and alternative behaviours.
> Do people think that these additional features warrant progressing this draft
> or something similar within the IETF, or should focus be shifted to working
> with the BBF on simply amending their TR-146?

I think the understanding of this problem at IETF is in short supply. The BNG and non-DOCSIS ISP CE router vendor experts and non-DOCSIS ISP access network experts are at BBF. I don't support progressing this draft in IETF.

As a final note -- for any solution to be meaningful (wherever the work is done), the vendor representatives who can commit to implementing must be engaged.