Subject: draft-ietf-6man-segment-routing-header issue #62- examples

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 Apr 2018 09:32:49 +0100

Hi,
 
You asked for some specific examples to support issue #62.
 
The issue was that in Section 3.1 there is a lot of MUST language but no indication of what a node should do if it discovers a violation.
 
To some extent the problem has been reduced by your reducing the volume of 3.1 (by dropping some of the TLVs), but it does remain.
 
The problems arise when a sending implementation is not conformant and violates a MUST. The receiver needs to know whether the error can be ignored, and if not, what it must do (drop the packet, fix the error, log an error, send icmp, etc.)
 
For example, 3.1.1
      Padding TLVs are optional and more than one Padding TLV MUST NOT
      appear in the SRH.
Consider a packet that is otherwise well formed but where there are two Pad0 rather than a PadN with length 0.
 
      When present, a single Pad0 or PadN TLV MUST appear as the last
      TLV before the HMAC TLV (if HMAC TLV is present).
Consider a packet where the HMAC is followed by a PadN
What would happen if a PadN had Length=6?
 
3.1.2
   o  If the HMAC TLV is present, the SRH H-Flag (Figure 2) MUST be set.
      Nodes processing SRH SHOULD process the HMAC TLV only when the
      H-Flag is set, and local policy.
   o  When the H-flag is set in the SRH, the router inspecting the SRH
      MUST find the HMAC TLV in the last 38 octets of the SRH.
This is clearer because it covers one of the two errors:
1. H-flag not set, HMAC present. You cover this although it would be clearer to say "SHOULD NOT process if flag not set" rather than "SHOULD process only when flag set"
2. H-flag set, HMAC not present. Obviously you can't process an HMAC that isn't there, but this is an error case: what should the node do?
 
Darren, these are just examples and you need to catch every "MUST". You might be able to do this with a catch-all: for example, "In all cases, if a processing node discover that a packet is malformed because the sending node has violated an encoding rule as defined in the following sections, the processing node MUST wave its hands in the air and scream."
 
Cheers,
Adrian
 
From: Darren Dukes (ddukes) [mailto:[email-masked]] 
Sent: 23 April 2018 21:48
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: WG last call review of draft-ietf-6man-segment-routing-header
 
Hi Adrian.  Thanks for your review of rev11. 
 
The following issue numbers were open by you and are closed in revision revision 12. Please respond to this email acknowledging the closures so Bob can record it.
 <https://trac.ietf.org/trac/6man/ticket/57> #57,  <https://trac.ietf.org/trac/6man/ticket/58> #58,  <https://trac.ietf.org/trac/6man/ticket/59> #59,  <https://trac.ietf.org/trac/6man/ticket/60> #60,  <https://trac.ietf.org/trac/6man/ticket/61> #61,  <https://trac.ietf.org/trac/6man/ticket/63> #63, 
 
 <https://trac.ietf.org/trac/6man/ticket/62> #62 is not closed yet, sending me specific examples would be useful.
 
 <https://trac.ietf.org/trac/6man/ticket/64> #64 Still open.  It contains your minor issues/Nits.  19 of which are fixed/resolvable in rev12, 6 remain open.  I’ll send a separate email on this.
 
Thanks!
 Darren