Re: [mpls] Update to the bullets on the first page of my review of draft-song-mpls-extension-header-09

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

Loa,

Comments inline below.

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: mpls <[e-mail]> On Behalf Of Loa Andersson
> Sent: Monday, September 5, 2022 4:00 AM
> To: Tony Li <[e-mail]>; Haoyu Song <[e-mail]>
> Cc: [e-mail]; [e-mail]; mpls-
> [e-mail]; [e-mail]; DetNet Chairs <[e-mail]>
> Subject: Re: [mpls] Update to the bullets on the first page of my review of draft-
> song-mpls-extension-header-09
> 
> [External Email. Be cautious of content]
> 
> 
> Tony and Haoyu,
> 
> Inlime plz.
> 
> On 2022-08-31 00:58, Tony Li wrote:
> >
> > Hi Haoyu,
> >
> > Well, we’ve already pretty clearly said that we will have a number of different
> scopes.
> 
> While I agree  that there need to be "a number of different scopes" for network
> actions, I can't really find where we "pretty clearly said that". Is it documented
> anywhere? If not where should we document it?

[JD]  I think it's in both the requirements and framework drafts.

However, in this discussion I 'm not sure 'scope' is the correct term.  What we're really discussing is that a set of network actions
may have produce different results depending upon the order in which they are executed.  We have already discussed this to
some extent and what we need to decide how flexible we want to be, viz, to we want a set of network actions to be performed in
a single pre-defined order or do we want a set of network actions to be performed in an arbitrary order specified within a packet?

Once we have decided this, we need to update the framework draft accordingly.  I think Tony has already asked that this topic be
discussed in a future DT meeting  

> 
> > Clearly if two actions do not have intersecting scopes, then there’s no issue.
> 
> agreed
> >
> > However, we’re going to have actions with interesecting scopes.
> 
> Yes, I can't see how that could be avoided.
> 
> > Now, you COULD, as you say ‘infer’ an ordering, but that leaves open the
> possibility of misinterpretation on the part of an implementer.
> >
> > So, I agree that the headers need not be arranged in processing order,
> 
> "arranged" in what meaning, in the packet? in the registry? or?
> 
> If we have a encapsulation with the where one header carries a NH, the that
> packet is processed first, and the NH-packet second, right?
> 
> 
> but we do need a deterministic, specified order of operations.
> 
> agreed, what I wonder is if we can have for example a processing order of
> NA1(psd)->NA2(isd)->N3(psd)?
> 
> If we can, doesn't have to be captured in requirements, framework and solution
> specifications?

[JD]  Your example, above, is not about order but rather about bouncing between in-stack and post-stack ancillary data.  The framework draft says that
when a network action is defined, its defining RFC has to indicate whether it has ancillary data, what is that ancillary data, and whether that ancillary data
is in-stack, post-stack, or both.   So, your example, above, is already covered.

> 
> /Loa
> Otherwise, we just get a mess.
> >
> > Tony
> >
> >
> >> On Aug 30, 2022, at 3:44 PM, Haoyu Song <[e-mail]>
> wrote:
> >>
> >> Hi Tony,
> >>
> >> What I mean is that the header parsing and processing should not be mixed
> together. The headers are parsed in the order the headers appear in a packet,
> but the processing order doesn't need to be strictly in this order.
> >>
> >> For example, an IOAM header may need to be processed at both ingress side
> and egress, and yet some other actions are only processed at ingress side and
> some others only at egress side. There can be hardly any clear order here.
> >>
> >> Even if some actions have some inter-dependency (we need some solid use
> case examples here in the context of MNA), it can infer some header processing
> order that the implementation should follow, but still it doesn't mean the
> headers must also be arranged in the processing order.
> >>
> >> Best regards,
> >> Haoyu
> >>
> >> -----Original Message-----
> >> From: Tony Li <[e-mail]> On Behalf Of Tony Li
> >> Sent: Tuesday, August 30, 2022 12:11 PM
> >> To: Haoyu Song <[e-mail]>
> >> Cc: Loa Andersson <[e-mail]>; Tianran Zhou <[e-mail]>;
> >> [e-mail]; [e-mail];
> >> [e-mail]; [e-mail]; DetNet Chairs
> >> <[e-mail]>
> >> Subject: Re: [mpls] Update to the bullets on the first page of my
> >> review of draft-song-mpls-extension-header-09
> >>
> >>
> >> Hi Haoyu,
> >>
> >>> How is the desired order communicated?
> >>>
> >>> [HS] The desired order is an implementation issue for device vendor. It
> doesn't need to be communicated or dicated by standard.
> >>
> >>
> >> So that means that an operator and buy box X, use it, replace it with box Y
> and suddenly get a completely different result?
> >>
> >> Suppose that a packet has two actions encoded.  One is to increment a
> counter, the other has an error and causes the packet to be dropped. Is it ok if
> box X drops before counting and box Y counts before dropping?
> >>
> >> The ideal of orthogonal semantics would be wonderful, but the reality is that
> we can’t guarantee that, especially in the face of user-defined actions.
> >>
> >> So, how would a head-end encode options to achieve a given intent if each
> box has its own unique interpretation of the semantics?
> >>
> >> What if the semantics drift over software releases?  Does the head end have
> to know the definitive behavior of every box and every release?
> >>
> >> Tony
> >>
> >
> 
> --
> 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!DE3A4WPvD5Wt36f1wcuFlSMMtNoltQbpRSox1eEzkCAjKVOgKjSVZKBOXyt8rG
> -d-ZQlXM2oWA$