Hi Aijun,
I am not particularly sold on the argument that the configuration
requirements of RFC 5316/RFC 5392 are especially burdensome.
A PCE relies on the TEDB which comprises nodes & links, and it makes
sense to have an inter-AS link represented as a "Link". Moreover,
these links are TE-enable
All
Another way of looking at BGP-LS is that it is an extremely powerful tool
for centralized controller based architectures or hybrid architectures, and
it does not bog down or impact the agility and lightweight aspects of BGP,
as BGP has its overall ability to stack & pile on SAFI's and codepoin
Hi Jeff
Thanks for the detailed analysis and explanation comparison of SR & IP Flex
Algo.
Please see in-line
Me like Flex Algo covered in Chocolate. š
On Sun, Oct 11, 2020 at 5:06 PM Jeff Tantsura
wrote:
> Gyan,
>
> In simple terms - destination lookup would yield a SID (stack) for SR or
> ne
Hi, Dhruv:
Please see my explain to Jeff.
https://mailarchive.ietf.org/arch/msg/lsr/VLufuaGDiRgaflcu58FY_SHnJ7A/
The solutions described in RFC 5316 and RFC 5392 are possible and
straightforward, but they have some constraints, especially for the
operation/configuration of the network.
Best
Hi, Jeff:
Using the solution that similar with Inter-AS-TE-v2
LSA(https://tools.ietf.org/html/rfc5392#section-3.1.1) is straightforward but
has the following constraints:
1. It requires the configuration of the remote-as/remote ASBR ID on border
router, and requires the advertisement of
Iām with Acee here, the presence of a passive interface in a topology is in no
way unambiguously signaling domain boundaries. You could āhack aroundā though,
but that would defeat the purpose of an IETF document.
Keeping it to OSPFv2 (other protocols have similar ways of doing that), Iād
say, us
Speaking WG member:
Hi Gyan, Aijun,
Even if I agreed with your use case assuming a passive interface denotes the
boundary between two domains as shown in figure 1 in your draft (which I
donāt), you still should not be trying to hack the prefixes with what is
inherently link attribute. Can I st
Robert,
On 12/10/2020 13:50, Robert Raszuk wrote:
Hey Peter,
To me the application here is "avoid red links" regardless of choice of
encap in the data plane.
Does it really makeĀ sense to separate advertisements of SR flex-algo vs
IP flex-algo into separateĀ TLVs ?
yes, please look at the b
Hey Peter,
To me the application here is "avoid red links" regardless of choice of
encap in the data plane.
Does it really make sense to separate advertisements of SR flex-algo vs IP
flex-algo into separate TLVs ?
Along the same linkes even for SR data plane can be SR-MPLS or SRv6. So in
the net
Hi Jimmy.
On 12/10/2020 09:12, Dongjie (Jimmy) wrote:
Hi Jeff,
Thanks for your explanation. I understand that for different data plane the
SIDs or IP addresses have different scope, and will not conflict in normal
cases.
My question is more about whether a computation node needs to know and
Ho Ron,
On 10/10/2020 14:47, Ron Bonica wrote:
Hi Jimmie,
Inline.
Ron
Juniper Business Use Only
-Original Message-
From: Dongjie (Jimmy)
Sent: Friday, October 9, 2020 11:06 PM
To: Peter Psenak ; Ron Bonica ; Yingzhen Qu
; Gyan Mishra
Cc: lsr@ietf.org; Jef
Hi Jimmy,
On 10/10/2020 05:05, Dongjie (Jimmy) wrote:
Hi Peter,
Thanks for your reply. It aligns with my understanding of FAD, which is just a
set of constraints for path computation. Thus one Flex-Algo ID could be used
with multiple different data planes. Is this understanding correct?
cor
Hi Gyan,
As far as PCE is concerned, we have the inter-AS link information via
RFC 5316 and RFC 5392. Both of these include a section on PCE's BRPC
procedure for instance.
I see you have other use cases, but it would be good to highlight why
for the PCE use case the above is deficient.
Thanks!
D
Hi Jeff,
Thanks for your explanation. I understand that for different data plane the
SIDs or IP addresses have different scope, and will not conflict in normal
cases.
My question is more about whether a computation node needs to know and check
which data plane is used by the intermediate nodes
14 matches
Mail list logo
