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

[Alvaro Retana <[e-mail]>]

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

Aijun:

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.

Thanks!

Alvaro.


...
> > (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
> (https://datatracker.ietf.org/doc/html/draft-huang-teas-bgp-community-pce-00)
> 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
sentence.




> > (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.