Robert,
On 18/11/2021 11:33, Robert Raszuk wrote:
Les, All,
One thing to keep in mind in this entire discussion is the reality of
compute nodes becoming L3 routing nodes in many new architectures. The
protocol which is used between TORs and such compute nodes is almost
always BGP. That means that no matter what we do in the IGP we will not
avoid using BGP for propagating both service reachability and next hop
reachability of such service.
In all discussions so far I have not seen an indication that the
proposed solution covers the above case. If I have compute's next hops
covered by the summary and that compute goes down would I signal it in
the IGP across areas/levels ?
If the IGP is aware of the reachability of the compute's next hop and it
summarizes such reachability between areas/domains, it can for sure
notify about such compute's next hop becoming unreachable.
On the other hand TORs do not go down that much. So if we are to proceed
with IGP based signalling of lost reachability I highly encourage to
consider real problems and keep in mind scalability aspects in the event
someone would like to punch holes in the summaries also based on
specific compute nodes going down. Yes often BFD compute to TOR runs BFD
so can be a trigger.
first, we are not necessarily punching holes. At least with the event
notification it does not leave any state, so "punching a hole in
summary" is not the correct description of it. Second, remote PE going
down may not be a very frequent event, but it is a possible event and
there are existing solution that covers it. We are trying to extend the
coverage for the case where network is using the summarization.
thanks,
Peter
We as networking people often put a wall between network and compute ...
well in reality there is no wall there any more**. So what we build must
consider service end to end not only traditional routers to be really
effective.
Thx,
R.
PS. ** I came to know a few week's back that some well known financial
company is joining network and compute teams into one.
On Thu, Nov 18, 2021 at 3:47 AM Les Ginsberg (ginsberg)
<[email protected]
<mailto:[email protected]>> wrote:
Tony –____
__ __
Inline.____
__ __
*From:* Tony Li <[email protected]
<mailto:[email protected]>> *On Behalf Of *Tony Li
*Sent:* Wednesday, November 17, 2021 5:24 PM
*To:* Les Ginsberg (ginsberg) <[email protected]
<mailto:[email protected]>>
*Cc:* Gyan Mishra <[email protected]
<mailto:[email protected]>>; Aijun Wang
<[email protected] <mailto:[email protected]>>;
[email protected] <mailto:[email protected]>; Christian Hopps
<[email protected] <mailto:[email protected]>>; Acee Lindem (acee)
<[email protected] <mailto:[email protected]>>; Tony Przygienda
<[email protected] <mailto:[email protected]>>
*Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE:
IETF 112 LSR Meeting Minutes____
__ __
__ __
Les,____
__ __
That’s easy. The summary covers all addresses of all of the nodes
(hosts and routers) in the area. It also may cover addresses within
the summary that are not currently assigned. This is intentional
since by advertising a summary, we gain scalability. The summary
provides aggregated reachability throughout the network.____
__ __
Reachability and path selection is the responsibility of the IGP,
not liveness.____
__ __
Should we not advertise a summary because a single address in the
summary is not assigned? No, it is up to correspondents to
determine if the address is populated.____
__ __
Should we punch holes in our summary for unassigned addresses? No,
that would kill scalability.____
__ __
Should we punch holes in our summary for host failures? That would
kill scalability too and drag the IGP out of its role. ____
__ __
Why would we then punch holes in the summary for member routers?
Just because we can? ____
*/[LES:] No. We are doing it to improve convergence AND retain
scalability.____/*
*/__ __/*
Should we corrupt the architecture just because we can? There are
other, architecturally appropriate solutions available. How about
we just use them?____
__ __
*/[LES:] What are you proposing?____/*
*/__ __/*
*/ Les____/*
__ __
Regards,____
Tony____
__ __
__ __
__ __
On Nov 17, 2021, at 5:08 PM, Les Ginsberg (ginsberg)
<[email protected]
<mailto:[email protected]>> wrote:____
__ __
I think the discussion about using a separate instance is a
distraction and we shouldn’t be debating that right now.____
____
The legitimate question is whether folks see it as appropriate
to have an IGP based solution for the problem. How to do it
using the IGP is only a meaningful question if we are
considering using the IGP at all.____
____
In that context…it is clear that it is a legitimate use of the
IGP to advertise summary addresses.____
It is also a legitimate use of the IGPs to advertise all the
individual prefixes covered by a summary if the network operator
chooses not to summarize.____
It therefore seems to me to quite legitimate for the IGP to
advertise both a summary and changes to the reachability of
individual destinations covered by the summary. This is still a
type of prefix reachability advertisement.____
____
It would help me if the folks who think this is NOT a legitimate
use of an IGP could explain why in the context of the above.____
____
Thanx.____
____
Les____
____
*From:*Lsr <[email protected]
<mailto:[email protected]>>*On Behalf Of*Gyan Mishra
*Sent:*Wednesday, November 17, 2021 4:32 PM
*To:*Aijun Wang <[email protected]
<mailto:[email protected]>>
*Cc:*Les Ginsberg (ginsberg)
<[email protected]
<mailto:[email protected]>>;[email protected]
<mailto:[email protected]>; Christian Hopps <[email protected]
<mailto:[email protected]>>; Tony Przygienda
<[email protected] <mailto:[email protected]>>; Acee Lindem
(acee) <[email protected]
<mailto:[email protected]>>
*Subject:*Re: [Lsr]【Responses for Comments on PUAM Draft】RE:
IETF 112 LSR Meeting Minutes____
____
____
With MT separate control plane common data plane or Multi
Instance separate control plane and separate data plane.____
____
In both transport instance styles peeling the event notification
into a separate instance or topology how do this discrete
transport instance or topology interact with the main instance
or topology.____
____
The answer is it can’t.____
____
As Aijun as well as Peter have discussed the problem this is an
inherent issue with use of summarization and these are two
solutions to solbe this real world issue to make summarization
viable for operators.____
____
Gyan____
Verizon Inc____
____
On Wed, Nov 17, 2021 at 6:10 PM Aijun Wang
<[email protected] <mailto:[email protected]>>
wrote:____
Hi, Christian:
Would you like to describe how to solve the problem via
using the transport instance? The detail interaction process
within the node and the deployment overhead analysis?
If there is no such information, it is doubt whether your
judgment is correct or not, it is also unconvincing. Welcome
also Tony gives the explanation before making the
assertions, as we done for PUAM solution.
Aijun Wang
China Telecom
> On Nov 17, 2021, at 22:59, Christian Hopps
<[email protected] <mailto:[email protected]>> wrote:
>
>
>
>> On Nov 16, 2021, at 10:36 PM, Aijun Wang
<[email protected]
<mailto:[email protected]>> wrote:
>>
>> Hi,
>>
>> The followings are the responses for the comments on
PUAM
draft(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08)
>>
>> Les: The comment I want to make, I think the
discussion on the
>> list highlighted the fact that there's an open
question,
>> independent of whether we use the prefix
unreachable
>> draft or the Event Notification draft, as to
whether this
>> problem should be solved by the IGP or whether
it should be
>> solved by BGP, or in some other way. And I
think the logical
>> way to proceed on this is to get the consensus
of the working
>> group as to whether an IGP solution is desired
first, then
>> after we reach consensus on that, then we can
start talking
>> about which approach is the better approach.
Which one
>> should be adopted?
>>【WAJ】The problem is occurred due to the summary action
by the ABR router in IGP, it should be solved by IGP itself.
>> As discussed earlier on the list, the possible use case
is not limited to BGP fast convergence.
>> Based on the above considerations, it is not
appropriated solved via BGP.
>>
>> Chris H: Chair hat on. You've been asking for adoption
for a while.
>> The event notification draft is new. I agree
with Les that
>> in a perfect world that would be the case, but
asking for
>> adoption is one way to answer the question. It
may be not
>> the perfect way to answer that question, but it
is one way.
>> I agree without my chair hat on, I'm not sure
we need this,
>> but it's not for me to say by fiat. Acee did
put something
>> out on the list to try to engage people again.
And I don't
>> think a lot got said.
>>【WAJ】we have several round discussions for this topic
but there is always no conclusion at the end.
>> Can the expert that reluctant to accept the new
idea to give some specific questions/problems for the
current solution?
>> Or else it is not helpful for the solve of the
existing problem.
>> Initiate the adoption call maybe the best way to
let the experts express their opinions?
>> We would like to hear the specific and detail
comments for the current solutions, not just general comments.
>>
>> Acee: I didn't see much support other than from the
authors. I
>> saw one non-author support on the event
notification.
>>【WAJ】Does anyone not agree what we analyze/summarize at
the presentation material for the two solutions?
(https://datatracker.ietf.org/meeting/112/materials/slides-112-lsr-05-puam-stublink-00.pdf,
the 5th slide)
>>
>> Chris: Everyone has a right to ask for an adoption.
Everyone has a
>> right to say we shouldn't adopt this and there
are the
>> reasons. We've let people to express opinions,
without
>> seeing a lot of negative opinions it's hard not
to just grant
>> the adoption call.
>>【WAJ】I agree.
>>
>> Tony P: I think this is all making a trash can out of
the IGP. One
>> possible solution is to ban or encouraged maybe
everyone with
>> these kind of suggestions to go towards the
service instance
>> stuff or whatever we call it, which I think is
a good idea.
>> Just run a power line up and much lower
priority. Don't trash
>> the main protocol that holds the whole thing
together.
>>【WAJ】Do you consider the deployment complexity for
independent service instance to transfer such thing? And
also the interaction on the device among the main IGP
instance and the service instances? It’s the fault of the
main protocol, and should be solved by the main protocol.
>>
>> Chris: Great comment for the adoption call. As a WG
member, I agree.
>
> This makes it seem like I'm saying that I agree with your
response. I'd strike that "As a WG member, I agree".
>
> Thanks,
> Chris.
>
>
>>
>>
>>
>> From:[email protected]
<mailto:[email protected]><[email protected]
<mailto:[email protected]>> On Behalf Of Acee Lindem (acee)
>> Sent: Wednesday, November 17, 2021 2:56 AM
>> To:[email protected] <mailto:[email protected]>
>> Subject: [Lsr] IETF 112 LSR Meeting Minutes
>>
>> The IETF 112 LSR Meeting Minutes have been uploaded.
Thanks to Yingzhen Qu for taking them!!!
>>
>>https://datatracker.ietf.org/meeting/112/materials/minutes-112-lsr-00
>>
>> The IETF 112 LSR Meeting MeetEcho recording is available
here:
>>
>>https://play.conf.meetecho.com/Playout/?session=IETF112-LSR-20211111-1200
>>
>> Thanks,
>> Acee
>
_______________________________________________
Lsr mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr____
--____
<~WRD0000.jpg> <http://www.verizon.com/>____
*Gyan Mishra*____
/Network Solutions Architect /____
/[email protected]
<mailto:[email protected]>/____
/M 301 502-1347/____
____
_______________________________________________
Lsr mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr____
__ __
_______________________________________________
Lsr mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
