Hi Aijun,
here's my comments:
The purpose of this draft is to advertise passive links.
1. I'm not sure the problem needs to be solved by IGPs. I tend to
believe ietf-idr-bgpls-inter-as-topology-ext is sufficient.
2. the solution that you proposed is wrong. You are trying to derive
topologic
Joel, Ketan,
On 28/09/2020 15:25, Ketan Talaulikar (ketant) wrote:
Hi Joel,
Please check inline below.
-Original Message-
From: Lsr On Behalf Of Joel M. Halpern
Sent: 25 September 2020 19:08
To: Ketan Talaulikar (ketant) ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isi
Hi, Peter:
Thanks for your comments.
1. For BGP-LS deployment, there normally only be one router that within the
IGP domain to report the topology information, this router should know such
passive links which exists mainly on other border routers via the IGP
protocol. This is main reason to extens
Hi Aijun,
On 29/09/2020 11:07, Aijun Wang wrote:
Hi, Peter:
Thanks for your comments.
1. For BGP-LS deployment, there normally only be one router that within the
IGP domain to report the topology information, this router should know such
passive links which exists mainly on other border routers
Speaking as WG member:
Hi Aijun, Peter,
I agree with Peter - one of the main motivations for having areas is to
abstract the topology within the area. Now you're trying to supplant this -
one topological detail at a time with ill-conceived IGP features.
Thanks,
Acee
On 9/29/20, 5:15 AM, "Lsr
Please review and comment
Ron
Juniper Business Use Only
> -Original Message-
> From: internet-dra...@ietf.org
> Sent: Tuesday, September 29, 2020 9:36 AM
> To: Parag Kaneriya ; Shraddha Hegde
> ; Ron Bonica ; Rajesh M
> ; William Britto A J
>
Ron,
This is nice. It makes it clear that constraint based path computation need not
have MPLS overhead
for those that don’t want it.
One thing that you don’t talk about is how this gets used, tho that may be
blindingly obvious: you’ll need
all nodes placing their prefixes in the RIB/FIB, wher
Thanks for the clarifications to Peter and Ketan. (I now understand
what I missed about the control for END.DT2M.)
It seems that as currently laid out, the document appears to define the
encoding for END.T, but does not provide enough information to use it?
Which suggests that we should eith
Not sure whether the use case that the underlay network and the overlay
network that belong to two different administrations is within this scope
? or has it already been covered by some other draft or RFCs? Assuming
there are multiple underlay paths from A to B. Overlay would like to
influence u
Hi Tom,
We can add the references. See ACEE>.
On 8/13/20, 6:03 AM, "Lsr on behalf of tom petch" wrote:
From: Lsr on behalf of internet-dra...@ietf.org
Sent: 13 August 2020 05:37
I said before that it was tough to review because of a lack of references
in the YANG module and
Hi, Acee and Peter:
Passive interface is mainly used at the edge of the network, where the
unnumbered interface will not be used.
And the information to flag the passive interfaces is for positioning the area
boundary, not conflict with the abstract capabilities of the area inside.
Best Regard
Hi.
Associating multiple algorithms with a given prefix is an interesting topic,
and I think this can simplify the complexity of FlexAlgo. I wonder if the
author would consider using cases with multiple algorithms with a given prefix.
Thanks
ZHibo
-Original Message-
From: Lsr [mailto:
I am missing something in this discussion of multiple algorithms.
My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is
that you need to associated a forwarding label (e.g. MPLS label or IPv6
address) with a specific algorithm so that you can compute the next hope
for the forw
Hi Joel:
For details about the method defined in RFC 6550. It uses the HBH option to
carry the RPLInstaceID. The RPLInstaceID and FlexAlgoID are similar.
Thanks
Zhibo
-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Joel M. Halpern
Sent: Wednesday, Septem
14 matches
Mail list logo
