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

[Loa Andersson <[e-mail]>]

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 able to read or act upon them.

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, they would work in an MPLS environment without having to change MPLS.

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

> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
>> -----Original Message-----
>> From: mpls <[e-mail]> On Behalf Of Loa Andersson
>> Sent: Monday, June 28, 2021 1:55 PM
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail]; DetNet
>> Chairs <[e-mail]>
>> Subject: [mpls] Open Design Team online meeting on Thursday (2021-07-01 )
>>
>> [External Email. Be cautious of content]
>>
>>
>> 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__;!!NEt6yMaO-gk!V6pEM-
>> DX6SAK1Iku6Y6c8wN5YqFiHv8FnKKuu7l0qYT_ElLhd2UC6KhD7-8jKvo$
>>
>> /Loa
>> --
>>
>> Loa Andersson                        email: [e-mail]
>> Senior MPLS Expert                          [e-mail]
>> Bronze Dragon Consulting             phone: [phone]
>>
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!
>> NEt6yMaO-gk!V6pEM-
>> DX6SAK1Iku6Y6c8wN5YqFiHv8FnKKuu7l0qYT_ElLhd2UC6KhDsDrBWBo$

-- 

Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]