Re: [Teas] AD review: draft-ietf-teas-network-assigned-upstream-label

Vishnu Pavan Beeram <vishnupavan@gmail.com> Sun, 12 November 2017 20:50 UTC

Return-Path: <vishnupavan@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 39BFF120724; Sun, 12 Nov 2017 12:50:36 -0800 (PST)
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 TJLaP7WiUNjr; Sun, 12 Nov 2017 12:50:33 -0800 (PST)
Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 D641B124319; Sun, 12 Nov 2017 12:50:33 -0800 (PST)
Received: by mail-pg0-x230.google.com with SMTP id j16so5672537pgn.9; Sun, 12 Nov 2017 12:50:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PHAjAga1W2PqPbTyGYBqD5ejak9xHxu4p7ezBEY0rFQ=; b=OBSXQNXd181z42oMMrGn149qJB1sDUFsE14SNn9Wu5no88/0LEJBqPWVGZa1nHVLGJ kujmFZ8koTHdBPfsaZ6GEcozST4O5mbTAWlnsS7ixDlXALvJ81ndnCWfhCRJOhZ1d6BX zxSmUXX60/EujZrTBiSnXHz6jbYqkNiP9oJLoe2bGJJgsLoTVL+QQge6BWNDVP7ZAcZF Djym9eDX79EWLCX2/QpwA1wSHmju5n0ux53RRJKDyvlnctjdZ99SC9zY/25Va1TBi2tu xAWV6yV4/qWD/h5sQ54dE99XOnVESNGNu1sVKo9FPqkVJVHvLMqlaErL3ITV/SKm/lLZ Nqkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PHAjAga1W2PqPbTyGYBqD5ejak9xHxu4p7ezBEY0rFQ=; b=Vnzuo5cJ1IoJKvYvi09vnvHBv/6l1K33jLgRvFurj9LrewRHpvddfWR+m5OyZDKY0O UvwTS7C6GGfQ7wzLiIuE9qtdYHsN2Xamvqu5/fZFpUmzX5kaePF9LqkHSBjcaxC4ywW+ 1RdVKRvzph29MnFhDBd6IZLjI/OOcn+Pw7n0IcjRBt3A2Ph9oiefm8EQPNbtv/Jlkq03 5sNBm/7vMMxY8lGUYjY3CKlisieijCzGNks3CeQJaU3OaX25SC1Rrsbqmk5/iuNy5B0r +PK5Qk8BuZqK2lqiE34ce5T46ciifyREnTlibDnfBlJL0WrWlWVDh4nDnWEZ9pmJL+sR j/2Q==
X-Gm-Message-State: AJaThX5IOIK5ArrAbm3vct+lzQ5yMH1rw4sN5DjNkTVcjjHEXGe8yqni cIlDvQWauuN8mN33GyvhX8ATGx5zNbMsaPSsUh01zQ==
X-Google-Smtp-Source: AGs4zMZhW1u/ePrWvbnfpNinOSupZU55YppE4C5aOapUPoaOb13NpSY2j6VcH65qqld/6oiqBcR96N2pQdbRxeNychA=
X-Received: by 10.98.19.23 with SMTP id b23mr7441200pfj.63.1510519833401; Sun, 12 Nov 2017 12:50:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.171.15 with HTTP; Sun, 12 Nov 2017 12:50:32 -0800 (PST)
In-Reply-To: <F64C10EAA68C8044B33656FA214632C87CE53D71@MISOUT7MSGUSRDE.ITServices.sbc.com>
References: <F64C10EAA68C8044B33656FA214632C87CE53D71@MISOUT7MSGUSRDE.ITServices.sbc.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Sun, 12 Nov 2017 15:50:32 -0500
Message-ID: <CA+YzgTtfBkEYjXu8NqNGa5WXJBi1SoS5W7Ot9as=dtvbjhUSTA@mail.gmail.com>
To: "BRUNGARD, DEBORAH A" <db3546@att.com>
Cc: "draft-ietf-teas-network-assigned-upstream-label@ietf.org" <draft-ietf-teas-network-assigned-upstream-label@ietf.org>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="001a1147676a189dc8055dcf4e29"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/guzQM7tUGC0Vdb-zQjQifeq2FQQ>
Subject: Re: [Teas] AD review: draft-ietf-teas-network-assigned-upstream-label
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 12 Nov 2017 20:50:36 -0000

Deborah, Hi!

We posted a new revision (-09) to address the comments below. Please go
through the diffs (
https://tools.ietf.org/rfcdiff?url2=draft-ietf-teas-network-assigned-upstream-label-09.txt)
and let us know if the changes adequately address the comments.

Please see inline for more responses (prefixed VPB)

Regards,
-Pavan (on behalf of the authors)

On Tue, Aug 22, 2017 at 6:27 PM, BRUNGARD, DEBORAH A <db3546@att.com> wrote:

> Hi,
>
> I've reviewed this draft and after discussing with your Chairs a bit on
> it, I have the following comments:
>
> - I think you need to create an IANA registry for this label if you want
> to ensure it does not get used in an implementation. For example, MPLS has
> registries for "special purpose label values". While this is only one
> value, I suggest a similar top-level registry, with an entry for this draft.
>

[VPB] Added an IANA request for a new subregistry (Please see Section 6).


> - the draft refers to an implementation survey as justifying there are no
> backward compatibility concerns with the choice of this label. But there
> was no implementation survey. I think today's RFC3473 procedures will have
> an upstream node rejecting this label if returned to it and no data traffic
> will be transmitted. So this should prevent any harm. I recommend being
> more concise in the backward compatibility section on the processing.
>

[VPB] Removed the "ambiguous" text in the "Backwards Compatibility" section
(Please see Sections 2.1 [second paragraph] and 2.2).


> - Currently the draft updates RFC3473. I think it also updates RFC3471 and
> RFC6205 (especially as the example in the draft is WSON and this draft
> requires a modification of RFC6205 procedures). And you need to clearly
> identify what it is that you are updating in this document vs. the previous
> documents.
>

[VPB] Updated the "Updates" attribute and added relevant supporting text
(Please see Abstract and Section 1 [second paragraph]).


>
> - The draft is a bit too short:-) You need to have proper sections on
> Procedures and Label Format. The current Processing section is not
> sufficient. There's more in the use case, than in the Processing section.
>

[VPB] Added a figure for the "Label format". Added some text clarifying the
scope of the procedures -- it now explicitly states that the scope is
limited to the exchange and processing of messages between an upstream node
and its immediate downstream node. Added more details to the
error-processing procedures. The draft may still appear to a bit short on
text -- but it is just the nature of the change being proposed (the only
thing that is being proposed here is a new value for the existing
UPSTREAM_LABEL object).


> - Considering the changes for the above, I recommend for your Chairs to
> have a short (1 week) WG Last Call on the updated draft. If can do SOON
> (Adrian's definition:-)), I'll leave it as "AD Evaluation", if drags out,
> I'll send it back to the WG.
>
> Thanks,
> Deborah
>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>