We don’t have domain-wide labels. We have domain-wide indices. The same index
is represented with different label values by different hosts, depending on
their SRGBs.
pdm
From: spring <[email protected]> On Behalf Of Robert Raszuk
Sent: Friday, June 8, 2018 9:59 AM
To: Alexander Vainshtein <[email protected]>
Cc: [email protected]; Xiejingrong <[email protected]>; Michael McBride
<[email protected]>; Rob Shakir <[email protected]>;
Zafar Ali (zali) <[email protected]>; Eric C Rosen <[email protected]>; Voyer,
Daniel <[email protected]>
Subject: Re: [spring] Updating the SPRING WG Charter
Sasha,
> because usage of domain-wide labels has been discussed many times in the past
> and rejected by the MPLS WG.
That comment I quite do not follow. Entire concept of SR-MPLS is based on
domain wide labels (distributed via IGP or OOB) and my description applies to
SR based networks with both MPLS as well as v6 encap.
In other words we already have domain wide MPLS labels to indicate various
types of segments. What I proposed would at most require perhaps new type which
would embed node + replication function..
Thx,
R.
On Fri, Jun 8, 2018 at 4:53 PM, Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
wrote:
Robert,
I concur with Eric.
I also think that the scenarios you describe as relevant for
SR-fan-out/SR-spray (“applications which on one side do not really require full
multicast yet they would benefit with content to be send once from server and
arrived at two or more caches”) strongly resembles IGMP/MLD Proxy applications
(RFC
4605<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4605&data=02%7C01%7Cpamattes%40microsoft.com%7C555c978a313441d9e0f508d5cd506e42%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636640667691087492&sdata=I1uK8l1aISD61f8E%2BH2Mt10v8RQ1W%2Bh2bS4pl%2BB%2BgOw%3D&reserved=0>).
Is such an analogy correct?
Last but not least, it seems that your description of SR-fan-out mandates usage
of domain-wide labels (mentioned by Eric as well_. If this is indeed so, I
consider this as a stopper because usage of domain-wide labels has been
discussed many times in the past and rejected by the MPLS WG.
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email:
[email protected]<mailto:[email protected]>
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of Robert Raszuk
Sent: Thursday, June 7, 2018 7:04 PM
To: Eric C Rosen <[email protected]<mailto:[email protected]>>
Cc: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; Xiejingrong
<[email protected]<mailto:[email protected]>>; Michael McBride
<[email protected]<mailto:[email protected]>>; Rob Shakir
<[email protected]<mailto:[email protected]>>; Zafar
Ali (zali) <[email protected]<mailto:[email protected]>>; Voyer, Daniel
<[email protected]<mailto:[email protected]>>
Subject: Re: [spring] Updating the SPRING WG Charter
Hi Eric,
The way I look at this is really not from the perspective of true dynamic
multicast with tree building etc .. .I look at this as anchor points to
replicate unicast flows into two or more endpoints maybe once or twice in
entire domain.
So for sure if you would try to apply this technique to distribute traditional
multicast there is tons of things which can go wrong and you are better off
with BIER.
But there are applications which on one side do not really require full
multicast yet they would benefit with content to be send once from server and
arrived at two or more caches. Maybe we just don't have the right name for it
in networking yet :)
Cheers,
R.
On Thu, Jun 7, 2018 at 5:52 PM, Eric C Rosen
<[email protected]<mailto:[email protected]>> wrote:
On 6/7/2018 10:55 AM, Robert Raszuk wrote:
Imagine a segment with embedded meaning that packets received with such value X
should be replicated to interfaces Y & Z. Such decision can be configured from
controller or locally computed.
Nothing there is per-path as well as nothing there is per flow or per multicast
group. It is a local function.
How can you say "nothing there per-path"? The label X represents a multicast
tree, and thus constitutes per-path state. If some packets need to go to Y
and Z, some need to go to Y, Z, and W, some need to go to Y, U, and V, etc.,
you obviously need a different label for each different multicast tree, and
appropriate per-tree state.
Using a controller to set up multicast paths may be a good idea in some
scenarios, but let's not pretend it doesn't create per-path state in the
router. Per-path (per-tree) is not the same as per-flow or per-group, of
course, but that's true of any technique that aggregates flows into multicast
tunnels.
Note also that if the label X is domain-wide unique and there is no RPF check,
there is the possibility of nasty multicast loops. These is some discussion of
this in draft-zzhang-bess-bgp-multicast-controller-00.
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains information
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received
this
transmission in error, please inform us by e-mail, phone or fax, and then
delete the original
and all copies thereof.
___________________________________________________________________________
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
