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

[John E Drake <[e-mail]>]

Hi,

Comments inline below.

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: mpls <[e-mail]> On Behalf Of Loa Andersson
> Sent: Wednesday, October 27, 2021 11:04 AM
> To: Kireeti Kompella <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; DetNet Chairs
> <[e-mail]>
> 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".
> 
> 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.

[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
> 
> 
> On 21/10/2021 16:23, Kireeti Kompella wrote:
> > 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 <[e-mail]> 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
> >> --
> >>
> >> 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/mpl
> >> s__;!!NEt6yMaO-
> gk!VOOEx1wPdisviodhEGqZIv5BjRP6AKzMGDWu6MTf47ae8JrihrL
> >> eE7jtceSgBUg$
> >
> 
> --
> 
> 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!VOOEx1wPdisviodhEGqZIv5BjRP6AKzMGDWu6MTf47ae8JrihrLeE7jtceSgBUg$