Subject: Re: [mpls] Open Design Team online meeting on Thursday (2021-07-01 )

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 1 Jul 2021 21:45:42 +0000

Hi,

As not able to record for the call, I took notes:
https://trac.ietf.org/trac/mpls/wiki/2021-07-01-agenda

These are draft - if corrections/clarifications, either edit the page directly or send to me.

Deborah

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Loa Andersson
Sent: Monday, June 28, 2021 1:55 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: [mpls] Open Design Team online meeting on Thursday (2021-07-01 )

Open Design Team,

I have uploaded the agenda for the meeting on Thursday.

https://urldefense.com/v3/__https://trac.ietf.org/trac/mpls/wiki/2021-07-01-agenda__;!!BhdT!0ZHtABhwKXizz5pKeU9RnIBsAbvJC82V7hvxcSP3yHCuDi-S0L5QvRr6rWS0zn8$ 

/Loa
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!BhdT!0ZHtABhwKXizz5pKeU9RnIBsAbvJC82V7hvxcSP3yHCuDi-S0L5QvRr6CECNoIk$

---

From: John E Drake <[email-masked]>
Date: Fri, 2 Jul 2021 12:26:02 +0000

Loa,

I think the idea of including multiple indicator/pointer labels in an MPLS label stack is ill-considered.  As I understand it, the reasoning is that some transit LSRs may not be able to reach the BoS, so we will place these indicator/pointer labels in the MPLS label stack at positions where they can be read by all transit routers, except of course, by those transit routers that don't understand them.  However, the semantics of these indicator/pointer labels are go to the BoS and act upon data subsequent to it.  If a transit LSR isn't able to reach BoS, how can it do this?  (It should be noted that RFC 8662 doesn't have this problem because it places the actionable data at multiple places in the MPLS label stack.)

I think the conclusion has to be that these indicator/pointer labels have to appear once in an MPLS label stack in the vicinity of the BoS and we live with the fact that some transit LSRs won't be able to read or act upon them.

Also, why are we adding these new capabilities strictly to MPLS?  Aren't there requirements for these new capabilities in non-MPLS environments?  If they were added in a non-MPLS specific manner, they would work in an MPLS environment without having to change MPLS.  

Yours Irrespectively,

John

Juniper Business Use Only

> [External Email. Be cautious of content]
> 
> 
> Open Design Team,
> 
> https://urldefense.com/v3/__https://trac.ietf.org/trac/mpls/wiki/2021-07-01-
> agenda__;!!NEt6yMaO-gk!V6pEM-
> DX6SAK1Iku6Y6c8wN5YqFiHv8FnKKuu7l0qYT_ElLhd2UC6KhD7-8jKvo$
> 
> /Loa
> --
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!
> NEt6yMaO-gk!V6pEM-
> DX6SAK1Iku6Y6c8wN5YqFiHv8FnKKuu7l0qYT_ElLhd2UC6KhDsDrBWBo$

---

From: Haoyu Song <[email-masked]>
Date: Fri, 2 Jul 2021 18:04:50 +0000

Hi John,

I agree with you.  And the MPLS EH solution we proposed is aligned with IPv6 EH (same structure, same protocol code numbers); the similar mechanism can be extended to anywhere else if needed.

Best regards,
Haoyu

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of John E Drake
Sent: Friday, July 2, 2021 5:26 AM
To: Loa Andersson <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: Re: [mpls] Open Design Team online meeting on Thursday (2021-07-01 )

Loa,

Yours Irrespectively,

John

> Cc: [email-masked]; [email-masked]; 
> [email-masked]; DetNet Chairs <[email-masked]>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fmpls%2Fwiki%2
> F2021-07-01-&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C7c22a39c5
> f6f4fe0074508d93d549adf%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6
> 37608255867719065%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6QBCGRnkcgVuR3
> kDzazsNaR33uFXocJ0g691PanTh8s%3D&amp;reserved=0
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls__&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C7c22a39c5f6f4fe0074508d93d549adf%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637608255867719065%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wJszvYQ893KUbL6V5j%2Bj1Ul0BHrk0KVPEJPwmvm1T6k%3D&amp;reserved=0;!!
> NEt6yMaO-gk!V6pEM-

_______________________________________________
mpls mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C7c22a39c5f6f4fe0074508d93d549adf%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637608255867719065%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=YacAI2LkGjGG%2FqLpZvk9Ma1n7eEcvqlsXvnQB7GyRZQ%3D&amp;reserved=0

---

From: Loa Andersson <[email-masked]>
Date: Fri, 2 Jul 2021 23:34:23 +0200

John,

Please see inline.

On 02/07/2021 14:26, John E Drake wrote:
> Loa,
> 
> I think the idea of including multiple indicator/pointer labels in an MPLS label stack is ill-considered.

Yes, the thought has struck me. I.e. I have not been pushing "all" these 
proposals because I think we need to carefully discuss and take 
decisions in the working group.

   As I understand it, the reasoning is that some transit LSRs may not 
be able to reach the BoS, so we will place these indicator/pointer 
labels in the MPLS label stack at positions where they can be read by 
all transit routers, except of course, by those transit routers that 
don't understand them.

I think that that is a true description for the GAL, but I have not seem 
the same proposal for for example FAI.

However, for GAL I have seen two different proposals

- the first is what you describe above; a copy of the GAL already in the
   stack is introduced "higher up" in the stack

- the second is to add a second unique GAL, pointing to a second
   different ACH

   However, the semantics of these indicator/pointer labels are go to 
the BoS and act upon data subsequent to it.  If a transit LSR isn't able 
to reach BoS, how can it do this?  (It should be noted that RFC 8662 
doesn't have this problem because it places the actionable data at 
multiple places in the MPLS label stack.)

I agree that this is not straightforward, quite a bit of design is 
needed, and might not be worth the effort. Another point we should agree on

> I think the conclusion has to be that these indicator/pointer labels have to appear once in an MPLS label stack in the vicinity of the BoS and we live with the fact that some transit LSRs won't be…

Does that mean that only a GAL or a FAI can be present in a label stack?

A similar problem is that the FAI has several flag, with your reasoning 
it seems to me that for a single FAI we will aloow only one flags might 
be set.

> Also, why are we adding these new capabilities strictly to MPLS?  Aren't there requirements for these new capabilities in non-MPLS environments?  If they were added in a non-MPLS specific manner, t…

Well, this has not been discussed in detail, but I note that is very 
likely that the opposite statement also might be true "If they were 
added in an MPLS specific manner, they would work in a non-MPLS 
environment without further any further changes to that environment.

/Loa

--