[Teas] Comments on draft-ietf-mpls-rsvp-shared-labels

Matt Hartley <mhartley.ietf@gmail.com> Wed, 19 September 2018 15:44 UTC

Return-Path: <mhartley.ietf@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C416130DC9; Wed, 19 Sep 2018 08:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 8aEB5gRLSTEW; Wed, 19 Sep 2018 08:44:04 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EACF130E46; Wed, 19 Sep 2018 08:44:04 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id g2-v6so2870832plo.2; Wed, 19 Sep 2018 08:44:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=cQtIQfU7yPLGycEOZjpY9XUbSpeUZNY7/wR4v5995qg=; b=SxZk5eya1yhb6fZkuodZr5xqBZzbu3jk8gdmroxKfuqIzF7yT1jAN6sLpRiQYgfTca REOEvuZkrdqswR1lIL+wzaNOmbljpw0inQ51BsZBkXOKmVxpBwBPdqsDAsyVoS3Fcl9Q nXuCXPMxKdRyzJCrZ0qOcae8N7RdBEtfYqsgXOER8+Io4fhl4KjPpp7/UyPSwStLBIZl Lxd6sW2w+aLsBCmSM3QYhMCl9NbbNXLR7C4Hgui1sQDHoOMiGist4QMv4Sqrz9vlhNqn 05pGpsxW5C5OKZ+YNjRraJaXxclxnsvrK2yq32F4IlHEZEbi50kJhhyghlgzWjAHvLW3 t+0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=cQtIQfU7yPLGycEOZjpY9XUbSpeUZNY7/wR4v5995qg=; b=QmPIov35Ct2thSiWQNabewvAPoFTFCSicV1flTn9aSf84f9Vvt5hmY+U9Pox8Pjzph eugSRKuGDYqf3Es1bLdHIjNYhwSjBKzguJgCrlDzomzhzdA4FVRMwiO1pJZg/mi7RgY7 +qq+5ygf6Nn2vVR8CqLhKsFaebICAmtweINQxaFXJjNKCmRC92A3VqmTLQXwMSXUSLwx xSZQIbvaHKGHV9wcmnWDItQ/bUGPNLRKFu89D6RUwAfKkQCM4QhCLU6KWV39vecjPCc1 Y1epuFibX9E1JZhe4Y6vAwrdwiTNJdbLPRWj8cZMc0Mhg7gXmg0A6BkAUlSJ7di51yB5 nn8A==
X-Gm-Message-State: APzg51A3CZG6Yw+7g6MfckhUF22BZWLX08WkHm2U8Iq2p1fwnDKRjDxv gOpeciCf6zGy0cgK+TfeMQOr2AhbGj1bVThyBx0bwHS7
X-Google-Smtp-Source: ANB0VdZvbcE2rDBO4lBcv1XqurmkXIqbPSzP3aB6zD6YnZpaw6KgwVImHpROOcD0/Qhw1sm8JHqNH4b2yybZmGMMuEc=
X-Received: by 2002:a17:902:e20d:: with SMTP id ce13-v6mr18830748plb.47.1537371843677; Wed, 19 Sep 2018 08:44:03 -0700 (PDT)
MIME-Version: 1.0
From: Matt Hartley <mhartley.ietf@gmail.com>
Date: Wed, 19 Sep 2018 11:43:52 -0400
Message-ID: <CAKfnWBj5hWjGX0D5kuq6ya9p=0csB1C2h_-B6ZVhXpMm0=B6sw@mail.gmail.com>
To: draft-ietf-mpls-rsvp-shared-labels@ietf.org
Cc: mpls@ietf.org, teas@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a1509c05763b46f4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/_UPrLGiUqh7xROu3WU3zWxUFU5U>
Subject: [Teas] Comments on draft-ietf-mpls-rsvp-shared-labels
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Sep 2018 15:44:07 -0000

Authors,

A couple of comments on this. Apologies for leaving it until WGLC, but I
hadn't read the draft previously...

It's fairly clear while reading the draft that delegating label stack
imposition makes node-protection... difficult. The draft explicitly
declines to address the issue, but I see that we now have
draft-chandra-mpls-rsvp-shared-labels-np which addresses this issue. Would
it make sense to combine the two documents so that we have a more complete
shared-label solution? I think it would be better if we could... but this
is more of a preference on my side if the authors feel they'd prefer to get
the base technology standardized earlier.

At the end of section 4, you mention that an ingress node might want to
avoid creating a shared-label LSP which will have a deeper label stack than
it can handle by using delegation or reverting to standard RSVP-TE.
Hopefully implementations will have the sense to avoid signalling
shared-label LSPs like this, but I think it might be worth being more
assertive about this and making it a SHOULD NOT or even a MUST NOT.

Something the draft doesn't address at all (unless I missed it) is how this
works with loose-hop expansion. There seems to be an implicit assumption
that the ingress node calculates the entire path and can therefore request
delegation nodes to keep the label stack manageable if need be, but once
loose hops are in play this is no longer possible and you could quite
easily end up with a label stack that exceeds the ingress node's
capabilities. I think it would be worth adding some text to address this;
maybe specify that a node performing loose-hop expansion on a shared-label
LSP must also act as a delegation node for the segment of the path that it
expands, although there are other solutions too.

Cheers

Matt