Subject: [mpls] mpls-open-dt: ancillary data commens

From: Toerless Eckert <[email-masked]>
Date: Thu, 12 Aug 2021 18:04:30 +0200

a) Suggest to replace:
   Types of ancillary data
   with
   Positioning of ancillary data

   Types is an overloaded term and make me for example foremost think it means semantics.
   Positioning should hopefully be more precisely describin what this point describes.

b) Wrt the discuss on control plane learned ancillary data,

   i suggest to add the following a new section:

---
Source of semantics 

   The semantic of or associated with ancillary data can come from different sources 
   depending on scope of the ancillary data semantic:
   - network wide
     - by standard
     - through network-wide control plane 
   - per-class
     - through control plane
   - per-flow
     - through per-flow control plane

   Consistency for network-wide control plane was raised as core new issue,
   unclar if e.g.: IGP eventual consistency is suficient here.

   For per-class control plane (e.g. DSCP/EXP static config) and per-flow control plane 
   (e.g. RSVP-TE signaling) we have accepted models.
---

Cheers
    Toerless

---

From: Loa Andersson <[email-masked]>
Date: Fri, 13 Aug 2021 12:19:55 +0200

Toerless,

I got your point, after thinking a bit, and not really convinced about 
the overload of "type". But I agree that "implicit", in-stack", and 
"after BoS" designates good "types", so I agree to change along thge 
lines you suggested, though I don't think changing the header only is 
enough.

First:

What about:

OLD
Types of ancillary data

    We have (tentatively) three different types of ancillary data

    - implicit, the indicator is sufficient, and a node knows what to do
      just because the indicator is there
    - "in-stack-data", the ancillary data is in the stack accompanying
      the indicator
    - "after the BoS", the ancillary data is found after the label stack

    Note: There might be a fourth possibility - the ancillary data is
    carried as part of the packet pay-load, but for the time being I'd
    like to excluded that method.
NEW
Positioning of ancillary data

    We have (tentatively) three different to include (position) ancillary
    data in an MPLS packet.

    - implicit, the indicator is sufficient, and a node knows what to do
      just because the indicator is there
    - "in-stack-data", the ancillary data is in the stack accompanying
      the indicator
    - "after the BoS", the ancillary data is found after the label stack

    Note: There might be a fourth possibility - the ancillary data is
    carried as part of the packet pay-load, but for the time being I'd
    like to excluded that method.
END

Does this work?

Second:

You had a comment about regardless how the ancillary data are 
positioned, it can be used to inform that there are data conveyed to the 
node by the control plane or that has been configured. I think that was 
intended to replace the "Note:" above.

Can you try to write a text.

/Loa

-- 

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

---

From: Loa Andersson <[email-masked]>
Date: Fri, 13 Aug 2021 14:24:23 +0200

Toerless, DT,

I accidently omitted two words, uppdated below. 

Sent from my iPhone

> On 13 Aug 2021, at 12:20, Loa Andersson <[email-masked]> wrote:
> 
> Toerless,
> 
> I got your point, after thinking a bit, and not really convinced about the overload of "type". But I agree that "implicit", in-stack", and "after BoS"
does not
>  designates good "types", so I agree to change along thge lines you suggested, though I don't think changing the header only is enough.

/Loa
> You had a comment about regardless how the ancillary data are positioned, it can be used to inform that there are data conveyed to the node by the control plane or that has been configured. I think that was intended to replace the "Note:" above.
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls