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

[Aijun Wang <[e-mail]>]

Hi, Alvaro:

Thanks for your comments, will upload the updated version in short time for experts' final review.

Thanks for your efforts.
Detail response inline below[WAJ]


Best Regards

Aijun Wang
China Telecom


-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Friday, January 22, 2021 3:13 AM
To: Aijun Wang <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; Lou Berger <[e-mail]>; [e-mail]
Subject: RE: Alvaro Retana's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT)

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.
[WAJ] Add one sentence in bullet part of the section 5, as the followings:
"The priority traffic may share some links or nodes, if passing the shared links or nodes can meet the requirement of application. When the priority traffic prefixes were changed but the total volume of priority traffic does not exceed the physical capacity of the previous E2E path, the PCE needs only change the prefixed advertised via the edge routers (R1,R7 in Figure 3)."


> > (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.
[WAJ] There is another reason for using the BGP session, not directly the nexthop-------If we want to change the nexthop of some prefixes on the existing BGP session, we should first get existing underlay BGP session info, which required other interactive process with the PCC. Define one or more new BGP sessions on the devices, will be easily deployed and less conflicted with the existing BGP session.

> 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.
[WAJ] Will consider later, if there is some quick/easy method to get the underlay BGP session information.   


...
> > (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.
[WAJ] Add related description in the bullet part of section 5, as the following:

"PCE sends the route information to the routers (R1,R2,R4,R7 in Figure 3) on the forwarding path via PCEP, for example, as described in  , to build the path to the BGP next-hop of the advertised prefixes. The path to these BGP next-hop will also be learned via the IGP protocol, but the route from the PCEP has the higher preference. Such design can assure the IGP path to the BGP next-hop can be used to protect the path assigned by PCE."


> > (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.
[WAJ] OK, will follow the advices from Deborah in another mail.


> > (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.
[WAJ] Change the sentence as " PCE sends the prefixes information to the PCC(edge routers that have established BGP sessions) for advertising different prefixes via the specified BGP session."