Subject: [mpls] Today's MPLS Open DT meeting cancelled

From: Loa Andersson <[email-masked]>
Date: Thu, 21 Oct 2021 15:52:12 +0200

Folks,

We have just learned that Matthew can't make today's meeting. In a short 
consultation with the other chairs we agree that we don't want to take 
the requirement discussion without Matthew. We therefore decided to 
postpone the meeting one week.

/Loa
-- 

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

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 21 Oct 2021 07:23:10 -0700

Agree we should wait for Matthew on the requirements discussion, but we can still have the meeting today and talk about the PSD Directive.  I’m ready.

> On Oct 21, 2021, at 06:52, Loa Andersson <[email-masked]> wrote:
> 
> Folks,
> 
> We have just learned that Matthew can't make today's meeting. In a short consultation with the other chairs we agree that we don't want to take the requirement discussion without Matthew. We therefore decided to postpone the meeting one week.
> 
> /Loa
> -- 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Loa Andersson <[email-masked]>
Date: Wed, 27 Oct 2021 17:03:36 +0200

Kireeti,

Sorry for late response.

One reason why we setup the agenda as we did for last week (1) 
requrements and (2 )PSD Directive (if time allows), was that we wanted 
to the requirements first. Then the discussion on the requirements 
disappeared it was natural to cancel the meeting.

There are also a few question that I wanted to think about before going 
ahead with the PSD directive.

First, the design directive should be a guideline the keeps solutions 
within a sound architectural boundary. Your text seem to be describing 
one particulate solution.

We  should not confuse a design directive with the specification. For 
the design directive is enough if we say "you can't place PSD that 
belongs to more than one FA/NF afteer the label with the BoS bit set".

The rest is specification and should go into ID/RFC.

Second, we should not anticipate wg consensus or actually 
specifications. There are currently more than one proposal, on for 
example how the indicators should work.

For example the FAI proposal works with one flag field, and let the 
implementation figure out what is in the PSD. The NFI proposal is 
different, and I not entirely clear how it works. I think it is one flag 
field for actions/function that generate ISD and NoD, and two flag 
fields (end-to-end and hop-by-hop) for actions/functions that generate PSD.

Your design directive seems to anticipate that we will go with the FAI 
proposal, but we need to wait to take that decision.

The design directive don't need that decision "don't place more than one 
set of PSD after the BoS" is independent of how the PSD is generated.

/Loa

--

---

From: John E Drake <[email-masked]>
Date: Wed, 27 Oct 2021 15:39:25 +0000

Hi,

Comments inline below.

Yours Irrespectively,

John

Juniper Business Use Only

> -----Original Message-----
> From: mpls <[email-masked]> On Behalf Of Loa Andersson
> Sent: Wednesday, October 27, 2021 11:04 AM
> To: Kireeti Kompella <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; DetNet Chairs
> <[email-masked]>
> Subject: Re: [mpls] Today's MPLS Open DT meeting cancelled
> 
> [External Email. Be cautious of content]
> 
> 
> Kireeti,
> 
> Sorry for late response.
> 
> One reason why we setup the agenda as we did for last week (1) requrements
> and (2 )PSD Directive (if time allows), was that we wanted to the requirements
> first. Then the discussion on the requirements disappeared it was natural to
> cancel the meeting.
> 
> There are also a few question that I wanted to think about before going ahead
> with the PSD directive.
> 
> First, the design directive should be a guideline the keeps solutions within a
> sound architectural boundary. Your text seem to be describing one particulate
> solution.
> 
> We  should not confuse a design directive with the specification. For the design
> directive is enough if we say "you can't place PSD that belongs to more than one
> FA/NF afteer the label with the BoS bit set".
> 
> Second, we should not anticipate wg consensus or actually specifications. There
> are currently more than one proposal, on for example how the indicators should
> work.
> 
> implementation figure out what is in the PSD. The NFI proposal is different, and I
> not entirely clear how it works. I think it is one flag field for actions/function
> that generate ISD and NoD, and two flag fields (end-to-end and hop-by-hop) for
> actions/functions that generate PSD.

[JD]   I was proposing two sets of network function flags, one for hop-by-hop and one for end-to-end, each with its own SPL.  There is also this:

"When defining a network function, it is necessary to define whether that function is hop-by-hop, processed by every transit node on the packet's path from ingress  node to egress node, or end-to-end, processed only by the  egress node, whether that function requires ancillary data and if so, what is that ancillary data and whether it should be placed in label stack entries (LSE) or after the BoS (BoS data).  If a given network function is directly related to forwarding and requires ancillary data, that data SHOULD be placed in LSEs."

Which means that no flags are needed to indicate that there is ancillary data either in the label stack or after it because that is part of the definition of each network function.

At a given point in time there will be N defined contiguous network functions.  In a given packet there will be a set of M network functions whose flags are set, where size of (M) <= N.

Within M, X is the set of network functions that don't require ancillary data, Y is the set of network of network functions that require ancillary data in the label stack, and Z is set of network functions that require ancillary data after the BoS.  So, size of (X  + Y + Z)  <=  M.

The ancillary data for the network functions in Y is in the label stack after the network function flags, in the same order as the elements in Y

The ancillary data for the network functions in Z is after the BoS in the same order as the elements in Z

> 
> Your design directive seems to anticipate that we will go with the FAI proposal,
> but we need to wait to take that decision.
> 
> The design directive don't need that decision "don't place more than one set of
> PSD after the BoS" is independent of how the PSD is generated.
> 
> /Loa
> 
> 
> > Agree we should wait for Matthew on the requirements discussion, but we can
> still have the meeting today and talk about the PSD Directive.  I’m ready.
> >
> consultation with the other chairs we agree that we don't want to take the
> requirement discussion without Matthew. We therefore decided to postpone
> the meeting one week.
> >>
> >> /Loa
> >> --
> >>
> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpl
> >> s__;!!NEt6yMaO-
> gk!VOOEx1wPdisviodhEGqZIv5BjRP6AKzMGDWu6MTf47ae8JrihrL
> >> eE7jtceSgBUg$
> >
> 
> --
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!
> NEt6yMaO-
> gk!VOOEx1wPdisviodhEGqZIv5BjRP6AKzMGDWu6MTf47ae8JrihrLeE7jtceSgBUg$

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 27 Oct 2021 17:16:46 -0700

Good points.  See inline for more.

> On Oct 27, 2021, at 08:03, Loa Andersson <[email-masked]> wrote:
> 
> Kireeti,
> 
> Sorry for late response.
> 
> One reason why we setup the agenda as we did for last week (1) requrements and (2 )PSD Directive (if time allows), was that we wanted to the requirements first. Then the discussion on the requirements disappeared it was natural to cancel the meeting.

That makes sense, but we’ve had many months of discussion without the requirements ...

> There are also a few question that I wanted to think about before going ahead with the PSD directive.
> 
> First, the design directive should be a guideline the keeps solutions within a sound architectural boundary. Your text seem to be describing one particulate solution.
> 
> We  should not confuse a design directive with the specification. For the design directive is enough if we say "you can't place PSD that belongs to more than one FA/NF afteer the label with the BoS bit set".

Fair point.  I can rewrite this to be more neutral, or provide input.

Specifically, I will update the text in Backward Compatibility of https://trac.ietf.org/trac/mpls/wiki/encap-rev2 <https://trac.ietf.org/trac/mpls/wiki/encap-rev2> to be solution-neutral.

> Second, we should not anticipate wg consensus or actually specifications. There are currently more than one proposal, on for example how the indicators should work.
> 
> For example the FAI proposal works with one flag field, and let the implementation figure out what is in the PSD. The NFI proposal is different, and I not entirely clear how it works. I think it is one flag field for actions/function that generate ISD and NoD, and two flag fields (end-to-end and hop-by-hop) for actions/functions that generate PSD.

I think it’s architecturally more sound to have the PSD be self-describing, independent of the details of the solution (FAI or otherwise).  But point taken.

> Your design directive seems to anticipate that we will go with the FAI proposal, but we need to wait to take that decision.

Not really, although it may seem so.  It’s easier for me to work with concrete examples, but once I have that, I can generalize.

:k

> The design directive don't need that decision "don't place more than one set of PSD after the BoS" is independent of how the PSD is generated.
> 
> /Loa
> 
>