Hi, Acee:
Except the corner cases of unnumbered interface, would you like to illustrate
other scenarios that the process does not apply?
As mentioned in last mail, knowing the passive interfaces can assist the nodes
or controller know the boundaries of the network.
Aijun Wang
China Telecom
>
Ron -
Interesting proposal.
A few mundane - but I think still important - comments.
New IS-IS TLVs
There is no need to have two TLVs for each address-family - one for MTID #0 and
one for all non-zero MTIDs. One TLV/AF will suffice.
The reason we have separate TLVs today
This version addresses Tom Petch's comments.
Thanks,
Acee
On 9/30/20, 11:08 AM, "Lsr on behalf of internet-dra...@ietf.org"
wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Link State Routing WG of the IETF.
Peter,
Granted - you can do this with MPLS encapsulation.
But if you are doing native IP forwarding or SRv6 I am still unclear.
Imagine you get allocated by RIR say IPv4 /16 or IPv6 /32.
So you take some part of that block and use it for flex algo next hops ..
flood it via IGP and have flex
Hi Muthu,
Thanks for the review.
An interface can be associated with, at most, one Flexible Algorithm. Likewise,
an IP address can be associated with, at most, one Flexible Algorithm.
I tried to express this in the text below, but probably didn't do a very good
job. If you can think of a
Robert,
On 30/09/2020 16:28, Robert Raszuk wrote:
Peter,
Let's see if we are talking about the same thing ...
Take SRv6 as example ... You can run flex algorithm only on selected
segment endpoints as you do encap and dst rewrite. So rest of the
network (P/transit routers) do not need to
Hi Tom,
See inline . I've addressed your comments in 05.
On 9/30/20, 6:14 AM, "tom petch" wrote:
From: Acee Lindem (acee)
Sent: 29 September 2020 22:44
Hi Tom,
We can add the references. See ACEE>.
Yes please - it will make it easier for me to review
On
Hi,
While it is possible to define algorithm-specific IP reachability TLVs to
advertise IP Prefixes associated with different algorithms, this would
introduce several new IS-IS top TLVs. One quick question is: can similar
function be provided with extensions to existing IP reachability TLVs
Peter,
Let's see if we are talking about the same thing ...
Take SRv6 as example ... You can run flex algorithm only on selected
segment endpoints as you do encap and dst rewrite. So rest of the network
(P/transit routers) do not need to have a clue about any flex-algo
other then plain old SPF.
A quick question:
If an IP address and a Flexible Algorithm are associated with the
same interface, they are also associated with one another. An IP
address MAY be associated with, at most, one interface.
If multiple IP addresses and multiple flexible algorithms are associated
with a
Hi Robert,
On 30/09/2020 09:28, Robert Raszuk wrote:
Hi,
> It uses the HBH option
Currently Ron's proposal seems to work well for both IPv4 and IPv6
addresses. I hope this discussion will not try to derail it to IPv6 only
track.
I see no issue with loopback to flexible algorithm mapping
Hi Joel,
On 30/09/2020 06:04, Joel M. Halpern wrote:
I am missing something in this discussion of multiple algorithms.
not really.
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
Hi Aijun,
Other than your ill-conceived topology discovery heuristic, what other possible
reason would there be for associating the passive attribute with a prefix?
Thanks,
Acee
On 9/29/20, 10:39 PM, "Aijun Wang" wrote:
Hi, Acee and Peter:
Passive interface is mainly used at the
From: Acee Lindem (acee)
Sent: 29 September 2020 22:44
Hi Tom,
We can add the references. See ACEE>.
Yes please - it will make it easier for me to review
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
Hi Aijun,
we have made a similar discussion in the context of the Appendix A of
draft-ietf-lsr-ospf-prefix-originator. I have made it very clear that
using IP reachability advertisement to derive any topological data is
incorrect and broken. Same applies here. I'm not going to change my
Hi,
> It uses the HBH option
Currently Ron's proposal seems to work well for both IPv4 and IPv6
addresses. I hope this discussion will not try to derail it to IPv6 only
track.
I see no issue with loopback to flexible algorithm mapping in 1:1 fashion.
I do however see some issues in deploying
16 matches
Mail list logo
