Subject: Re: [sfc] Mirja Kühlewind's Discuss on draft-ietf-sfc-nsh-24: (with DISCUSS and COMMENT)

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 5 Oct 2017 14:29:32 +0200

Hi Carlos,

thanks for you reply. Please see inline.

> Am 27.09.2017 um 21:13 schrieb Carlos Pignataro (cpignata) <[email-masked]>:
> 
> Thank you, Mirja, for these questions and details.
> 
> Please find follow-ups inline.
> 
>> On Sep 27, 2017, at 1:02 PM, Mirja Kühlewind <[email-masked]> wrote:
>> 
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-sfc-nsh-24: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> I have a couple of comments on the design. I know, as always in IESG review
>> state, it's probably too late to make any changes to the actual header format,
>> therefore most of my comments are actually in the comment section below. I
>> still decided to note them so at least people can consider these points.
>> However, there are a few things that I need clarification for before
>> publication, which I note in this section:
>> 
>> 1) Sec 2.2
>> "SF/SFF/SFC Proxy/Classifier implementations that do not support SFC
>> OAM procedures SHOULD discard packets with O bit set, but MAY support
>> a configurable parameter to enable forwarding received SFC OAM
>> packets unmodified to the next element in the chain.  Forwarding OAM
>> packets unmodified by SFC elements that do not support SFC OAM
>> procedures may be acceptable for a subset of OAM functions, but can
>> result in unexpected outcomes for others; thus, it is recommended to
>> analyze the impact of forwarding an OAM packet for all OAM functions
>> prior to enabling this behavior.  The configurable parameter MUST be
>> disabled by default."
>> This part is really unclear to me and I believe needs to be further specified.
>> Where should this configurable parameter be? In the Context header? Why don't
>> you just use one of the unassigned bit to indicate if an unknown (OAM) packet
>> should be forwarded or not?
> 
> The configurable parameter refers to a configuration state and device operational state variable, and not a data plane packet field.
> 
> In other words, the default is drop. But if the setting `configure sff forward oam` then it is forwarded.
> 
> I will say that this was a strong contentious point in the WG process to keep this configuration option (although my personal preference was not to have it, the WG was loud on it.)
> 
>> Moreover, I also disagree with this text. If there
>> is a bit/a way to indicate if a not supported OAM packet should be forwarded or
>> not, it should just be defined like this, while any considerations if that bit
>> should be set or not depend on the OAM function itself and do not need to be
>> discussed here.
> 
> I think the disagreement comes from believing the config option is a data plane bit.

Yes, I misunderstood the intention here. For me the text was/is written quite confusingly (which might be the result of the long wg discussion). Let me try to make an attempt to rephrase. Feel free to use any of this or not:

„By default OAM support MUST be disabled. Therefore a SF/SFF/SFC Proxy/Classifier, that is not explicitly configured to support OAM, MUST discards packets with the O bit set. An implementation MAY provide a configurable parameter to enable the forwarding of received SFC OAM packets to the next element in the chain. If OAM support is enabled, OAM packets MUST be forwarded unmodified. Forwarding OAM packets by SFC elements that do not itself support SFC OAM procedures may be acceptable for a subset of OAM functions, but can result in unexpected outcomes for others; thus, it is recommended to analyze the impact of forwarding an OAM packet for all OAM functions prior to enabling this behavior.“

One part of my confusion was mixing up the fact that packet should not be send unmodified with the configuration to forward or not. Splitting that in a separate sentence as proposed above helps for my understanding a lot.

> 
>> Finally, it is not well explained what an OAM packet is at all.
> 
> If it helps, although it seems redundant, we can add a pointer to RFC 6291 or RFC 7276.

Yes that would definitely help.

>  
> 
>> Is that a 'fake' packet that is generated by the operator to actively test the
>> (potentially newly configured) SFP? If so, why does a SF need to know if a
>> packet is an OAM packet or not?
> 
> It is an OAM packet, which can include connectivity verification, continuity check, performance management, etc. It could be a synthetic packet, or, well, an OAM packet :-)
> 
>> Usually it's a bad idea to use different kind
>> of traffic for testing compared to what will be used in operations. Please
>> provide more explanation here!
> 
> I am not sure how to address this, since the definition of OAM for SFP is outside the scope. 
> 
> Data plane protocols use an 'interception marker’ to differentiate them from actual traffic, in the context of Active or Hybrid OAM (as opposed to Passive OAM).
> 
Okay.

>> 
>> 2) section 2.4
>> "An SFC-aware SF MUST receive the data semantics first in order to
>> process the data placed in the mandatory context field.  The data
>> semantics include both the allocation schema and the meaning of the
>> included data.  How an SFC-aware SF gets the data semantics is
>> outside the scope of this specification."
>> This is really confusing to me. I think this is what you need an actually data
>> semantics aka type field for in the base header. Or is there an actual reason
>> to not put this information directly in the base header where it is need but
>> instead assuming some magical way this information may take to reach the node?
> 
> Believe it or not, no magic involved. It’s called “control plane” which is out of scope.
> 
>> If the assumption is that the SF is configured to know based of the SFI what
>> the content of the context header has to be,
> 
> No, the assumption is not that an SF “is configured”. And the assumption is not that the SF knows what the content of the context header is.
> 
> The assumption is that the SF needs to receive the data semantics before processing the data plane packet.
> 
>> you a) need to say that in the
>> draft,
> 
> The document says what it means and means what it says in this regards. If you find the text confusing, we can try to clarify it somehow.
> 
>> and b) that's really error-prone because it's really hard to tell if the
>> conext header actually holds the information that you need or just random crap
> 
> Is “crap” a technical term here?
> 
>> (of course depending of the expected data type of this information). In short,
>> I think you really need a type field somewhere here.
> 
> Mirja, there’s self-describing data and non-self-descriving data. Both have their place and can be used based on what a protocol is optimizing. This text described a use of the latter.
> 
>> In any case, you really
>> need to explain this more! Also, the text further says: "An SF or SFC Proxy
>> that does not know the format or semantics of the
>> Context Header for an NSH with MD Type 1 MUST discard any packet with
>> such an NSH…"
> 
> I keep reading these couple of sentences and I understand what they say. So I am not positive at this point how to help out.
> 
>> How does the SFC proxy know that it knows the format or not if there is no type
>> field or identifier that indicates what the format should be?
> 
> Same as the first sentence you included in this DISCUSS item #2: 
> 
> "An SFC-aware SF MUST receive the data semantics first in order to
> process the data placed in the mandatory context field.”
> 
> Since an SFC proxy acts as an SFC-aware SF. That is clear in the document.
> 
> That said, I will add the following to make it unambiguously clear:
> 
> 
> "An SFC-aware SF or SF Proxy MUST receive the data semantics first in order to
> process the data placed in the mandatory context field.”
> 
> And 
> 
> OLD:
> included data.  How an SFC-aware SF gets the data semantics is
> outside the scope of this specification.”
> 
> NEW:
> included data.  How an SFC-aware SF or SFC Proxy gets the data semantics is
> outside the scope of this specification.“

The problem is, even if I have received some semantics how do I know that I have the right semantics?

> 
>> 
>> Also, a related question from me: why is the context header present in all
>> types of NSH if there is no use for it defined in this document yet? Why is
>> there no fixed length NSH without a context header then?
> 
> This document defines two Context Header Types: fixed size, and TLV-based. There is not need, as far as the WG had concluded, for a fixed size no metadata MD Type. 
> 
> What you describe can be achieved with MD Type 2 Length = 2.

In this case I don’t really understand why Type 1 is needed for. This is not a blocking point but maybe the draft could explain, what kind of optimizations are expected with Type 1/why is it useful..?

> 
>> 
>> 3) Section 2.5.1:
>> "If multiple instances of the same metadata are included in an NSH
>> packet, but the definition of that context header does not allow for
>> it, the SFC-aware SF MUST process the first instance and ignore
>> subsequent instances."
>> This seems error prone to me. If the same metadata appears multiple where it
>> should not, that seems clearly like an error case for me. Just using the first
>> one and proceed normally might not be the right thing to do. In any case I
>> think such an occasion should at least be logged.
> 
> OK, will add optional logging and error counting of the potentially error case event.
> 
>> If the multiple instances are
>> just a copy of each other and carry the same information, it's probably okay to
>> use that information and proceed. If the different instances carry different
>> information, it maybe a bit dangerous to just use the first one and ignore
>> others silently. In this case I would rather recommend to drop the packet…
>> 
>> 4) In line with the second comment from the tsv-art review (thanks Wes!), I
>> don't really understand why this documents says (sec 6) that there can be
>> multiple next hops for the same SFP or SFs can be traversed in a different
>> order. May understanding (from a quick look at RFC7665) would be that, if those
>> things are needed e.g. for load balancing, then one should define different
>> SFPs and the Classifier must have the knowledge that two SFP are equivalent and
>> select them respectively.
> 
> Not really. Like you said, for LB.
> 
>> The reason why I'm really concerned about this is
>> that usually a number of packets below to a flow and all packets belonging to
>> the same flow just ideally take the same route. But usually only the Classifier
>> has a notion of what a flow is and respectively will assign the SFI to the
>> packets belonging to the same flow. If now any SF on the path can more or less
>> randomly decided to forward packet belong to the same flow to one or another
>> next nodes, I would assume that this is not only a problem for the flow, e.g.
>> reordering, but also for SF itself in many cases.
> 
> https://tools.ietf.org/html/rfc7665#section-5.5

That’s fine in theory. In reality, especially e.g. for the web server case you need to make sure that all packets belonging to the same flow go to the same element. I thought it would actually be easier to use different SFPs such that only the Classifier must be flow-aware. If that’s not the case other nodes also need to be flow-aware and keep flow state. This must be mention in the document! 

> 
> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Further considerations:
>> 
>> 1) I don't really see why a TTL in the base header is needed. I mostly
>> understand why there is the Service Index in service header, also I think there
>> should be better mean to validate that you SFP is correct and I ideally you
>> should really not need this. However, loop prevention can be provided by both
>> mechanism and moreover there is probably also often a TTL in the encapsulation
>> protocol and loop prevention should really be a function of that forwarding
>> protocol and not the NSH.
> 
> The WG had a strong voice on the need of this field.
> 
> (I do not disagree with you)
> 
> But there are cases where SI is not decremented, nor is the encapsulation-level TTL.

Which are these cases?

> 
>> 
>> 2) I don't see why you need the type field in the base header. This is fully
>> redundant because because all you need is the length field. If the length is
>> 0x2 it is what you have defined as type 1 if the length field is larger it is
>> type 2.
> 
> Thanks for the attempt at overloading, but no. Length = 6?

What?

> 
>> I also don't see the need for any other types in future because you
>> also have the version field;
> 
> NO.
> 
> We do *not* want to bump up the Version field for the whole protocol when potentially adding a new MD Type.

Why? Using a new version does have to be something complicated/heavy. If you don’t use it for such cases, when would you use it then?

> 
>> if you need anything else you should go or
>> probably have to go for a new version. Note that the general probably with
>> unnecessary redundancy is that is add complexity. If you keep this redundancy
>> you have to separately handle and implement the case(s) where the type is 1 but
>> the length is larger than expected. If at all you could probably just use one
>> bit to indicate that the length field is present and if not the length is 0x2.
>> However, saving bits does not really seem to be a concern for you, so that
>> might not actually be an advantage.
> 
> I did not fully follow the train of branching pros and cons in your statement, but like you said earlier, there’s running code on this and would not be productive to define a different similar protocol.

Yes, I know. This is why these are only comments.
> 
>> 
>> 3) sec 2.5.1
>> "Unassigned bit: One unassigned bit is available for future use.  This
>> bit MUST NOT be set, and MUST be ignored on receipt."
>> Is there an actual reason to have an unassigned bit here?
> 
> I am not sure I understand the question.
> 
> The header is 32-bit aligned, and there’s less fields defined that available bits in a 32-bit word… 
> 
Why do you define this bit instead of just having one more bit for length field (where this bit was ‚stolen‘ from). If there is no use case for this bit, I don’t understand why this was done...

>> Because I would
>> assume that the type already provided enough flexibility for way to extend the
>> metadata format in any way needed.
>> 
> 
> ?
> 
>> 4) Also section 2.5.1:
>> "   Length: Indicates the length of the variable metadata, in bytes.  In
>> case the metadata length is not an integer number of 4-byte words,
>> the sender MUST add pad bytes immediately following the last metadata
>> byte to extend the metadata to an integer number of 4-byte words.
>> The receiver MUST round up the length field to the nearest 4-byte
>> word boundary, to locate and process the next field in the packet."
>> Your definition of the length field might be more error-prone than needed. It
>> would probably be easier to simply define the length as 4-byte words, and the 
>> type of course defines the content of the metadata field and as such can simply
>> define which part of the total metadata field holds certain data of a certain
>> type and with part is padding.
>> 
> 
> Thank you. See above.
> 
>> 5) And finally I have to say it is unclear to me why the SFI and SI field are
>> described as a separate header. Given they have to be present in all SFH,
> 
> What is “SFH”?

meant NSH… too make three-letter acronym in my life… 

> 
>> I
>> would consider them as two fields of the base header. But it is after all
>> really just an editorial issue. However, all this together with my previous
>> comments makes the protocol spec actually much more complicated than it needs
>> to be…
> 
> Noted.
> 
>> 
>> 6) I also have to agree to the last comment of the tsv-art review: I think it
>> would have been nicer to not only described the NSH but also define mappings to
>> a set of possible encapsulations because I would assume that for each
>> encapsulation there are a couple specific considerations that need to be made
>> to make things work successfully. I don't think that all encapsulations can be
>> captured by general consideration and I cannot make up my mind to go through
>> all cases in my head to figure out if there are things that needs to be noted.
>> 
>> 
> 
> OK.
> 
> Thanks again,
> 
> Carlos.
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 5 Oct 2017 08:45:35 -0400

Hi Mirja,

On Thu, Oct 5, 2017 at 8:29 AM, Mirja Kuehlewind (IETF) <[email-masked]
> wrote:

> > The configurable parameter refers to a configuration state and device
> operational state variable, and not a data plane packet field.
> >
> > I will say that this was a strong contentious point in the WG process to
> keep this configuration option (although my personal preference was not to
> have it, the WG was loud on it.)
> >
> Yes, I misunderstood the intention here. For me the text was/is written
> quite confusingly (which might be the result of the long wg discussion).
> Let me try to make an attempt to rephrase. Feel free to use any of this or
> not:
>
> „By default OAM support MUST be disabled. Therefore a SF/SFF/SFC
> Proxy/Classifier, that is not explicitly configured to support OAM, MUST
> discards packets with the O bit set. An implementation MAY provide a
> configurable parameter to enable the forwarding of received SFC OAM packets
> to the next element in the chain. If OAM support is enabled, OAM packets
> MUST be forwarded unmodified. Forwarding OAM packets by SFC elements that
> do not itself support SFC OAM procedures may be acceptable for a subset of
> OAM functions, but can result in unexpected outcomes for others; thus, it
> is recommended to analyze the impact of forwarding an OAM packet for all
> OAM functions prior to enabling this behavior.“
>
> One part of my confusion was mixing up the fact that packet should not be
> send unmodified with the configuration to forward or not. Splitting that in
> a separate sentence as proposed above helps for my understanding a lot.
>
> >
> > It is an OAM packet, which can include connectivity verification,
> continuity check, performance management, etc. It could be a synthetic
> packet, or, well, an OAM packet :-)
> >
> > Data plane protocols use an 'interception marker’ to differentiate them
> from actual traffic, in the context of Active or Hybrid OAM (as opposed to
> Passive OAM).
> >
> Okay.
>
>
> >>
> >> 2) section 2.4
> > No, the assumption is not that an SF “is configured”. And the assumption
> is not that the SF knows what the content of the context header is.
> >
> > The document says what it means and means what it says in this regards.
> If you find the text confusing, we can try to clarify it somehow.
> >
> > Mirja, there’s self-describing data and non-self-descriving data. Both
> have their place and can be used based on what a protocol is optimizing.
> This text described a use of the latter.
> >
> >> In any case, you really
> > I keep reading these couple of sentences and I understand what they say.
> So I am not positive at this point how to help out.
> >

The control-plane would pass the semantic associated with the particular
Service Function Path.

> > This document defines two Context Header Types: fixed size, and
> TLV-based. There is not need, as far as the WG had concluded, for a fixed
> size no metadata MD Type.
> >
> In this case I don’t really understand why Type 1 is needed for. This is
> not a blocking point but maybe the draft could explain, what kind of
> optimizations are expected with Type 1/why is it useful..?
>

It is an optimization for some hardware processing. The two types are part
of a compromise discussion that happened a number of years ago.

> That’s fine in theory. In reality, especially e.g. for the web server case
> you need to make sure that all packets belonging to the same flow go to the
> same element. I thought it would actually be easier to use different SFPs
> such that only the Classifier must be flow-aware. If that’s not the case
> other nodes also need to be flow-aware and keep flow state. This must be
> mention in the document!

The architecture is clear that the assignment of flows to particular
Service Functions can happen at a variety of different points.  One of the
motivations for carrying meta-data is to allow a classifier to insert
information identifying a particular flow so that all its packets can be
properly load-balanced to the same Service Function.  If the Classifier
does this, then there is not a need for every load-balancing element to do
reclassification.

> > But there are cases where SI is not decremented, nor is the

The Service Index is always decremented by the Service Function.
Since a Classifier can overwrite with a new SFP and SI, it is possible, in
theory, to get loops
where a packet moves along the new SFP and then gets reclassified back into
the loop.
The Service Index terminates loops within a particular SFP.
The TTL terminates loops within the service overlay plane - regardless of
how many different
SFPs that may involve.

It is a subtle, but critical, technical necessity that was recognized and
added about 10 months ago.

> > Thanks for the attempt at overloading, but no. Length = 6?

An MD-type 2 packet might have a length of 6 because of 4 32-byte words of
TLV
meta-data value.  It isn't possible to use the length to disambiguate.

> Why? Using a new version does have to be something complicated/heavy. If
> you don’t use it for such cases, when would you use it then?
>

The flexibility in these fields and having a version number is for
future-proofing. Once an encapsulation is burnt
into silicon, it is extremely hard to go back and add such things in.

Regards,
Alia

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 5 Oct 2017 14:49:41 +0000

Hi Mirja,

Rev -26, which just posted, adds a pointer to RFC6291 as per your response below (to clear DISCUSS item #1), and everything else is addressed below by Alia and me (all other DISCUSS items and all COMMENTs).
Rev -26 also incorporates the pending changes from Benoit and most of Ben’s.

Please see inline.

On Oct 5, 2017, at 8:45 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mirja,

On Thu, Oct 5, 2017 at 8:29 AM, Mirja Kuehlewind (IETF) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Carlos,

> Am 27.09.2017 um 21:13 schrieb Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>>:
>
>> On Sep 27, 2017, at 1:02 PM, Mirja Kühlewind <[email-masked]<mailto:[email-masked]>> wrote:
>>

I am glad that now you understand the intention, and this issue is addressed.

Thanks for the attempt at rewriting.

That paragraph is balancing in quite a delicate equilibrium. It is, as you gathered, the result of long arduous WG discussions. Consequently I am most hesitant to make any changes to it.

OK, done.

Okay.

Thanks.

The control-plane would pass the semantic associated with the particular Service Function Path.

It is an optimization for some hardware processing. The two types are part of a compromise discussion that happened a number of years ago.

What Alia said. (With thanks to Alia)

The architecture is clear that the assignment of flows to particular Service Functions can happen at a variety of different points.  One of the motivations for carrying meta-data is to allow a classifier to insert information identifying a particular flow so that all its packets can be properly load-balanced to the same Service Function.  If the Classifier does this, then there is not a need for every load-balancing element to do reclassification.

Again, what Alia said.

I trust these are now clear for you now.

Which are these cases?

The Service Index is always decremented by the Service Function.
Since a Classifier can overwrite with a new SFP and SI, it is possible, in theory, to get loops
where a packet moves along the new SFP and then gets reclassified back into the loop.
The Service Index terminates loops within a particular SFP.
The TTL terminates loops within the service overlay plane - regardless of how many different
SFPs that may involve.

It is a subtle, but critical, technical necessity that was recognized and added about 10 months ago.

Exactly.

What?

An MD-type 2 packet might have a length of 6 because of 4 32-byte words of TLV
meta-data value.  It isn't possible to use the length to disambiguate.

Exactly.

And even if it were possible, why overload? What if we have an MD Type 3 proposal?

The flexibility in these fields and having a version number is for future-proofing. Once an encapsulation is burnt
into silicon, it is extremely hard to go back and add such things in.

Right. And thanks again Alia.

— Carlos.

Regards,
Alia

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 16 Oct 2017 11:33:47 +0200

Hi Carlos, hi all,

I will clear my discus now because the remaining point are more on the clarification side then warrant a discuss.

However, I would still like to further comment because I have to say that I find some comments still not appropriately addressed. 

[snip]
>> One part of my confusion was mixing up the fact that packet should not be send unmodified with the configuration to forward or not. Splitting that in a separate sentence as proposed above helps fo…

I still think the text in the draft is every unclear. I wouldn’t want to require you at all to use my proposed wording but I wanted to demonstrate with the proposed text what the unclear points are. The difference in my text is a) that is clearly says MUST if configured respectively (instead of using a very blurry SHOULD here). I guess the alternative could actually be to not use any normative language. And b) don’t mix up the fact that the data should not be changed with the fact that they should forwarded or not. I think that was the part where most of the confusing came from for me. 

I understand that much discussion has happen about this. And I don’t propose to change the statements your make here. But marking an attempt to improve clarity, especially as this was so confusing that it even let to a discuss from my side, can never hurt!

[snip]

>> The control-plane would pass the semantic associated with the particular Service Function Path.

My question was not at all, how a node would receive the information. The question is how does the node know that these information actually fits to the ones provided in the packet, and can confirm that these information are not not outdated or provided wrongly. My thinking was that is would be much more error-save to provide information about the semantics in the packet itself. However, this is not the was the protocol was designed right now. Maybe it is still worth to provide further discussion on what to do if the semantics are not provided or do not match the expected data in the packet (e.g. data has different size, unexpected values -> these are at least cases that are easy to detect).

[snip]

> I trust these are now clear for you now.

It was always clear but this seems just more complicated than needed. I still think it would be much cleaner and less error-prone if you just assign different paths for these cases; that would also save you a lot of the problems with two different TTL fields. However, I guess it much to late to change this now unfortunately.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 16 Oct 2017 14:31:33 +0000

Hi, Mirja,

Thanks for your response, please see inline.

> On Oct 16, 2017, at 5:33 AM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi Carlos, hi all,
> 
> I will clear my discus now

OK. Thanks.

> because the remaining point are more on the clarification side then warrant a discuss.
> 

Well, it is very difficult maintaining a productive DISCUSSion over email when your response comes with an 11-day RTT delay, after two unicast KA nudges…

That said, 

> I still think the text in the draft is every unclear. I wouldn’t want to require you at all to use my proposed wording but I wanted to demonstrate with the proposed text what the unclear points are…

What is confusing to me is your explanation above. Your proposed text changed meaning actually. But regardless, those two things are not mixed up. I do understand everyone has a preference. I do to. But there really is nothing technically incorrect with that text, beyond ‘it confuses Mirja’, even when the prose might not be Pulitzer Prize quality.

> I understand that much discussion has happen about this. And I don’t propose to change the statements your make here.

OK. Thanks. As I said, this specific paragraph captures and holds a delicate balance of design-by-committee. There’s only two such paragraphs in this whole document, I believe, and this is one. 

> But marking an attempt to improve clarity, especially as this was so confusing that it even let to a discuss from my side, can never hurt!
> 

Actually, it can substantially hurt. That’s the reason why I am hesitant to change it.

> My question was not at all, how a node would receive the information. The question is how does the node know that these information actually fits to the ones provided in the packet, and can confirm that these information are not not outdated or provided wrongly. My thinking was that is would be much more error-save to provide information about the semantics in the packet itself.

Again, I understand you are suggesting a self-describing packet. You can do that with MD Type 2. MD Type 1 cannot afford it.

> However, this is not the was the protocol was designed right now. Maybe it is still worth to provide further discussion on what to do if the semantics are not provided or do not match the expected data in the packet (e.g. data has different size

Mirja, the data size is fixed.

> , unexpected values -> these are at least cases that are easy to detect).

Since the document does not concern itself with the content of that data, as clearly written down, I guess this discussion is interesting but out of scope.

> It was always clear but this seems just more complicated than needed. I still think it would be much cleaner and less error-prone if you just assign different paths for these cases; that would also…

Yes.

"Early Cross-Functional Engagement and Input" is, in my most humble opinion, one of the two or three largest missed opportunities in the IETF as a whole. And it seems to me that it’s moving towards more division instead of more integration. That is, also, outside the scope of this particular document.

But someone in the IESG might want to do something instead of putting a late DISCUSS :-)

Thanks again!

— Carlos.