Re: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT)

Alvaro Retana <> Thu, 21 January 2021 19:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D9B03A0A3E; Thu, 21 Jan 2021 11:12:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fm8uldt1EOJl; Thu, 21 Jan 2021 11:12:36 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B0F4C3A0A26; Thu, 21 Jan 2021 11:12:35 -0800 (PST)
Received: by with SMTP id g1so3828455edu.4; Thu, 21 Jan 2021 11:12:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=GChXH+8/gMWTeKxzITGhHpUnaEwl+atiunAzU8fI3Gg=; b=Xm1d9s9OgfGIxKCn5QfS8FeoRPAFZhOlXiSx4neNZoEdg2I0ilBEElsWvJ4vP9/qFl sxyhInUrSv9r0HtVChaz3yJ052Leai4h3jD/cQymwD1fVU62cJ5WDPEy2BGWTCA9T6Lr QcR5S9WggbcQFr6dU3MypMxdDzmRh7plS8lUWPCwI9JIw9GvCtW4S29ixprJqiXRtXZ5 RslVCZL/wfLR3+SINe9gO4t15FbYjh4lnJFt+0Je7CfvU++oL1C3oqm5a4am0tdztt/H 1q9r0Uz5xHNIoDH+ZwWkhTvEqFmAlNW8/oE5P5dSt4+dK9iEHGbH3ayaH15LFyEeO+7B thig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=GChXH+8/gMWTeKxzITGhHpUnaEwl+atiunAzU8fI3Gg=; b=n7PJcyE+0CUgDuH5sClzudMSfI9VuWM2l9sfkvteZ45vq7AHZEqsXfRktJ2Dx3NsLC XuCoxQx1ERSKqJ3BWYfJBNe6GmIheQzuIQBTaskKKGN8Swdm6pFV8WiuUcCjK1vNQHF+ Vsd6hiYOUEWm/R/IFR3q3tMjgtZNzf/worDBy3/I+TVL5lVdHWm4x+buwqNd2q7C8zsf fihPSkJaumTJTxsYJMvqVTFag/OHihcUyNTPFnFV22CWfOOLpJ+LL/No4fhJYPA/C5Cp YFW/P16SXhy8la/dgE+F0Hna+2woW74VBgPW/DSo87ICp/czfwSKdZioRJsCfGnxtFK1 +N2w==
X-Gm-Message-State: AOAM530sJrFllqkFwlaNXy6TrLjq/RXSGl2tTXA8OLbq9ig0OtVMKmjl aYMVx//YFxvSy9txPFhGeizl4dtTHpMFcQIUgFI=
X-Google-Smtp-Source: ABdhPJwkzEwhBo2w93DEPg8sMK1NOjXPiXuRU6EriABl57+y6oz0E8eVMzYVs1RHsE2qOKisR/j/uQmmiDfryd132og=
X-Received: by 2002:aa7:cdc7:: with SMTP id h7mr487856edw.353.1611256353881; Thu, 21 Jan 2021 11:12:33 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 21 Jan 2021 11:12:33 -0800
From: Alvaro Retana <>
In-Reply-To: <001901d6efaa$650f7940$2f2e6bc0$>
References: <> <001901d6efaa$650f7940$2f2e6bc0$>
MIME-Version: 1.0
Date: Thu, 21 Jan 2021 11:12:32 -0800
Message-ID: <>
To: Aijun Wang <>, The IESG <>
Cc:,, Lou Berger <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Jan 2021 19:12:38 -0000

On January 20, 2021 at 11:03:42 PM, Aijun Wang wrote:


Hi!  How are you?

> I have updated the draft accordingly and will upload the new version
> together with comments from other experts.

That's fine.  I look forward to seeing the updated text -- in the
meantime, I have some replies below.



> > (1) In general, the solution presented seems to assume that there will be
> > an independent E2E physical path per priority group/set of prefixes. As
> > the number of groups/sets increases, the probability of finding node-
> > disjoint paths across a network diminishes significantly. Link-disjoint
> > paths can also have issues. I would like to see a discussion about the
> > required disjointness, and considerations for reusing links/nodes.
> [WAJ] Yes, the group/set of prefixes may have some joint nodes/links on
> their optimal paths, but this will not lead to some issues, because PCE can
> ensure such path fulfill the QoS requirements of the application, based on
> the existing traffic of previous assigned group/set of prefixes.
> That is to say, the E2E path will be calculated independently based on the
> network real situation, but the path(nodes/links) may/will be shared by
> these prefixes set.
> The last but one paragraph in section 3 has some discussion for such
> scenarios as: "If, for example, there is bi-directional priority traffic
> from another address pair (for example prefix PF13/PF23), and the total
> volume of priority traffic does not exceed the capacity of the previously
> provisioned physical links, one need only advertise the newly added source/
> destination prefixes via the BGP session 2. The bi-directional traffic
> between PF13/PF23 will go through the same assigned dedicated physical links
> as the traffic between PF12/PF22." Is that enough, or add more descriptions
> in section 7.1?

I think more should be added because the text you quoted maintains the
physical separation, which is one of the things that prompted me to
make a comment.  Being clear about the possibility of sharing links,
paths, etc. is needed.

> > (2) §6: "Different BGP sessions are used mainly for the clarification of
> > the network prefixes, which can be differentiated via the different BGP
> > nexthop."
> > I would be interested to understand why simply advertising a different
> > NEXT_HOP, while maintaining a single BGP session was discarded as part of
> > the solution. As you mention in this sentence, the real differentiator is
> > the next hop -- if the advertised prefixes are always different then
> > changing the NEXT_HOP should also be a valid solution. Given that this
> > document defines the architecture, and that the PCEP extensions will be
> > based on it, it would be ideal if alternate implementations (minimally
> > different in this case) were not precluded.
> >
> > [Disclaimer: I haven't looked at I-D.ietf-pce-pcep-extension-native-ip in
> > detail, but it looks like using a single BGP session is not supported. :-(]
> [WAJ] We have also discussed the solution that using only one BGP session
> but change the NEXT_HOP offline, and actually there is one expired draft
> (
> to propose this. The reason that we does not follow this direction are the
> followings:
> A: Using different sessions is more management and understandable.

I don't agree with this point -- I think it is always relative:
multiple sessions imply management overhead, and the operator has to
be aware of the different next-hops anyway.

> B: The traffic will always be assured bidirectional, using BGP session can
> easily match the source/destination pair.

Is that a requirement?  For many applications the QoS-type
requirements are not always bidirectional, along with the load, etc.

I'm not advocating for you to change the solution, but to not
eliminate the possibility of using a single session -- if that is what
the operator wants.

> > (4) §7.2: "If one node on the optimal path fails, the priority traffic
> > will fall over to the best-effort forwarding path." This statement is only
> > true/possible if the prefixes associated with the priority traffic are
> > also advertised through the BGP sessions associated with the best-effort
> > path...or if there is an alternate path to the corresponding next-hop.
> > Neither of these options is explained in §3-5.
> [WAJ] There is an alternate path to the corresponding next-hop. Actually,
> such path will be learned via IGP. The "explicit peer route" from PCE has
> higher preference than the IGP path.
> If acceptable, I can add the above description into the section 7.2

Yes.  It would be ideal if this was explained *before* §7,
specifically where the architecture is explained.

> > (5) This document provides a description of the architecture, and as
> > mentioned in §6: "Details...are out of scope of this draft and will be
> > described in a separate document [I-D.ietf-pce-pcep-extension-native-ip]."
> > However, the description depends on the extensions/behavior from
> > I-D.ietf-pce-pcep-extension-native-ip in a couple of places:
> >
> > §5:
> > o PCE sends the route information to the routers (R1,R2,R4,R7 in
> > Figure 3) on the forwarding path via PCEP
> > [I-D.ietf-pce-pcep-extension-native-ip], to build the path to the
> > BGP next-hop of the advertised prefixes.
> [WAJ] How about change the sentence to " PCE sends the route information to
> the routers (R1,R2,R4,R7 in Figure 3) on the forwarding path via PCEP, for
> example, as that described in "I-D.ietf-pce-pcep-extension-native-ip", to
> build the path to the BGP next-hop of the advertised prefixes"
> > §7.3:
> > Not every router within the network needs to support the PCEP
> > extension defined in [I-D.ietf-pce-pcep-extension-native-ip]
> > simultaneously.
> [WAJ] How about change the sentence to " Not every router within the network
> needs to support the PCEP extension, for example, as that defined in
> [I-D.ietf-pce-pcep-extension-native-ip] simultaneously."
> > These references make I-D.ietf-pce-pcep-extension-native-ip a normative
> > reference because it is necessary to implement the architecture. Please
> > write these two paragraphs in a solution-neutral way (using
> > I-D.ietf-pce-pcep-extension-native-ip as an example is ok).

After reading your proposed text, I would prefer if
I-D.ietf-pce-pcep-extension-native-ip was not mentioned in either

> > (6) §5: "PCE sends the prefixes information to the PCC for advertising
> > different prefixes via the specified BGP session." Specifically, I think
> > you mean the RR. s/PCC/RR
> [WAJ] Here the PCE should send the prefixes information directly to the PCC,
> not RR. RR is just used to by PCC, to advertised such prefixes to other BGP
> peer(also PCC)

I see.  This is the only place where PCC is used (as part of the
description), and given the number of routers in Figure 3, it is not
clear which router you're referring to.  I think the sentence still
needs clarity.