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

Matt Hartley <mhartley.ietf@gmail.com> Fri, 21 September 2018 15:05 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 4303C130E55; Fri, 21 Sep 2018 08:05:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 DoLsoCb9cpx9; Fri, 21 Sep 2018 08:05:02 -0700 (PDT)
Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 BCA6612777C; Fri, 21 Sep 2018 08:05:02 -0700 (PDT)
Received: by mail-pg1-x52d.google.com with SMTP id d19-v6so6200212pgv.1; Fri, 21 Sep 2018 08:05:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OiBGQAsOHigHWcxg8xgMGGtLNXG/pczH5+iH6i8MOnE=; b=TTo4wbHD6cpwI8aatWuv4GMSoldMsZ6TZY5vgctD9clQFOT2TEhDgQGfWtjBzb+sT3 62SOso4C+f76KoWVRRag2lIk4YiJkkoWTbVK/Mzvy2117ftxIz2imVLZM5l1VSbeNH0U Kx7+Z24igyxXMOoGSBeXkwLiIHGAEQf+rMxGqg90s01SAX6oSR/AYVu5OB00eMsH3pfN 8xVzWYnl2OudicIrrTnz1+GP721L4yikD0rUg8ERFzEfiVamqunmIJbojP+nbYdLi8Mr HttWNaqemmvvuCwF5SSD9k2Pya9plKr2L5DfXwLbvywCtNX2c7moymmdet/56nU3jJ8v tPHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OiBGQAsOHigHWcxg8xgMGGtLNXG/pczH5+iH6i8MOnE=; b=lIntTjOAsryAuhfJKRAKy9yI42vKVY/fG12fPqKt0z2TQZLiQUC5nRO43Xeo4FA4OH qNTFrCoiRABvCoGtMR4gSs6oZI+ko3Gp47IleeqPJ2RUgJUHd2S/S0Hoo12HcEgBNfJu Vx1fu4++frF9Nk+q58FPKfh0RG/7CqCYdxYWzur63UbZPpLAVD/gBthUH2PnJhALJC8N umc9w6Q+pEEPD/PUld8B+Q12jnE4xPCwDz7Cc2GPBE3wvw2Og8kzmFxaDCdSKsYu2M6Y Wmn/FuRZxt5HDg5piFSyCCO0SSmoll+XnApet1hc1O8gZRq2AlNTn86Mdmtj9obpAhO2 oyCg==
X-Gm-Message-State: APzg51CQfQj6+esnvBaqG0kofjdXejAWTTo6BUfsHb5CDSu5EpdZbM0G 0m58MXOgPFRcfVkcR8lnl6dVqFSLCbTE89UdPck=
X-Google-Smtp-Source: ANB0VdZ0TQ9ii/GZ5m/6aFEHAVZ1jSn+RGFo4hrtxmyfv6Di5Qai5ppsftZtOwELdHCSjT+Ns4CJw4932t/L79Cedf8=
X-Received: by 2002:a63:d74f:: with SMTP id w15-v6mr42040727pgi.306.1537542302302; Fri, 21 Sep 2018 08:05:02 -0700 (PDT)
MIME-Version: 1.0
References: <CAKfnWBj5hWjGX0D5kuq6ya9p=0csB1C2h_-B6ZVhXpMm0=B6sw@mail.gmail.com> <CAKfnWBh9_JG6OWpRRUQFCweEDNKc3BgFgKr-kEJEk1AKX+1=8g@mail.gmail.com> <CA+YzgTv0hP0xY=RU9Q82mrM1bKJofZMP78Bam4VvECvWtpUrVg@mail.gmail.com>
In-Reply-To: <CA+YzgTv0hP0xY=RU9Q82mrM1bKJofZMP78Bam4VvECvWtpUrVg@mail.gmail.com>
From: Matt Hartley <mhartley.ietf@gmail.com>
Date: Fri, 21 Sep 2018 11:04:50 -0400
Message-ID: <CAKfnWBj7EH7BaBNOvjP1=PCNdekfH2ESQXM4r2_aatnMt-skvw@mail.gmail.com>
To: vishnupavan@gmail.com
Cc: draft-ietf-mpls-rsvp-shared-labels@ietf.org, mpls@ietf.org, teas@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c1868d057662f6e4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/CfYfA8_P6HOY-XrKYjFvgnWqmkE>
Subject: Re: [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: Fri, 21 Sep 2018 15:05:11 -0000

Pavan,

On Thu, Sep 20, 2018 at 7:16 PM Vishnu Pavan Beeram <vishnupavan@gmail.com>
wrote:

> Matt, Hi!
>
> Please see inline (prefixed VPB).
>
> Regards,
> -Pavan
>
>
> On Thu, Sep 20, 2018 at 2:25 PM Matt Hartley <mhartley.ietf@gmail.com>
> wrote:
>
>> One more thing...
>>
>> Obviously none of this works unless you have label recording in the RRO.
>> That's requested in the session attribute flags (0x02). Should we add a
>> line to say that this MUST be set if you want to use shared labels?
>>
>
> [VPB] Yes, it is obvious that label recording is mandatory. Please see the
> text in Section 9.2.
>
>
>
>    Bit Number 16 (Early allocation by IANA): TE Link Label
>
>
>
>    The presence of this in the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES
>
>    object of a Path message indicates that the ingress has requested/
>
>    mandated the use and *recording* of TE link labels at all hops along
>
>    the path of this LSP.
>
>
>
> Label recording is requested/mandated by setting the “TE Link Label” bit
> in the Attribute Flags TLV of the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES
> object of a Path message. So, even if a PATH message comes in without the
> 0x02 flag set in the SESSION_ATTRIBUTES object and with the above bit set
> in the Attribute Flags TLV, the implementation should treat it as a label
> recording request/mandate.
>

This is fine if you're using an LSP_REQUIRED_ATTRIBUTES object, because a
node that doesn't understand this will generate a Path-Error. But if you
use LSP_ATTRIBUTES, you can't guarantee that every node along the path will
have processed and understood this, and a node that doesn't process this
won't know it should record labels in the RRO.

Given that there seems to be a desire to use TE link labels in situations
where not all nodes support this document, I think you need to either set
the SESSION_ATTRIBUTES flag too, or explain how a node that hasn't
processed this object knows that it should record labels.

Cheers

Matt


>
>
>>
>> Cheers
>>
>> Matt
>>
>> On Wed, Sep 19, 2018 at 11:43 AM Matt Hartley <mhartley.ietf@gmail.com>
>> wrote:
>>
>>> 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
>>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
>>
>