Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 27 December 2019 19:29 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D07120909 for <spring@ietfa.amsl.com>; Fri, 27 Dec 2019 11:29:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUQUse4ohkZu for <spring@ietfa.amsl.com>; Fri, 27 Dec 2019 11:29:09 -0800 (PST)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602ED1208E0 for <spring@ietf.org>; Fri, 27 Dec 2019 11:29:08 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id xBRJT2kY028473; Fri, 27 Dec 2019 19:29:02 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B0C5C22044; Fri, 27 Dec 2019 19:29:02 +0000 (GMT)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id 9BF9B22042; Fri, 27 Dec 2019 19:29:02 +0000 (GMT)
Received: from LAPTOPK7AS653V (185-58-55-221.customers.tirolnet.com [185.58.55.221] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id xBRJSXtP003884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Dec 2019 19:29:02 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Pablo Camarillo \(pcamaril\)'" <pcamaril@cisco.com>
Cc: <spring@ietf.org>
References: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <035701d5ac4d$a3ea7ad0$ebbf7070$@olddog.co.uk> <0CB8E109-95E3-4A75-BCEF-1186817F68CE@cisco.com> <062c01d5b06f$bf4b76f0$3de264d0$@olddog.co.uk> <E46E18A8-BAD4-4B62-A1DC-4F315BE79E60@cisco.com>
In-Reply-To: <E46E18A8-BAD4-4B62-A1DC-4F315BE79E60@cisco.com>
Date: Fri, 27 Dec 2019 19:28:33 -0000
Organization: Old Dog Consulting
Message-ID: <000f01d5bceb$e56dc350$b04949f0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKiVutP/sPEol3Kl3K9aNZrJmBKoAKU5q/XAgYPVnEB0w+WwgG5XkwopfPETVA=
Content-Language: en-gb
X-Originating-IP: 185.58.55.221
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25132.002
X-TM-AS-Result: No--17.349-10.0-31-10
X-imss-scan-details: No--17.349-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25132.002
X-TMASE-Result: 10--17.349000-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtGyoI+bK8UPQnFPUrVDm6jt1WwSQLxOvlUTvdh6VFADyTPL 4IpXLngeGTMtyR+11BAOTuh/VaLhzEl1QBuOVAUMaPXXRVSBBovIEQTlh1/QMVhs8uimgHNCJkK /E7btc7NA/wDjVQ3ooD6Ot1kkU6saSnUqDs/R//UD2WXLXdz+AQZyESFXAljfe7ijHq7g9obTZ9 Wt1IEO+BRx762Th3kz74stnIm4P8Bqh+ZwiDQlS5K9FvwQx1hFfLNHMurfykhTpFNEkr6HJsmWT +h5S9Ng2gkDLfDgF4ml8brZMAV8Y2As6CFGKh4grdLFFKR7dulpFbUvmRjLcgbYcy9YQl6eXZrp mK5A+7T7nGGoxPDfng1Vne6ruInSPmKDzjF+t1BxPA6arkYp0GQBrQiRNt2IqPGqHIPGZiNDAvn /gQtzahwgoGMJ+H2zYx1rfvEm9E3dszRFwcTb57zgL/eLACDEuoKFNtn4sqP+7KZICEbEshxpgC zz8XrXkkJ8gFxhltjGGYg3mTSEyVveAk06OSKsbWgRGvgWOREft0d48Iev3+QydRUvl3QTAEOxG w6OfA3VoERDD5Sflnc1ZaiuhQysD+bxlHlzfzUHIUJsejWV9CIk3dpe5X+hvjdkdo+07/6A2U4D oCTZiO1wbykd6xTu5u2idQTviR8WUcwJqSCXncBfYoduOb6LSkWlzdsmIx75w23Kuluq0bnKeol HNmVg5q5c/gQ8dUgKNPLapsvgO7/KM1zCNPCMAI0UpQvEYJm/yN2q8U674pm7qvjz9eAEBTybns JRoKb4t7Ggrzlk7iMc2ott4KOcBsdYbEqwgW6eAiCmPx4NwFkMvWAuahr8i2QFaYS1v20qtq5d3 cxkNQwWxr7XDKH8lExlQIQeRG0=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/IOA_4nlNPacD2v7Jue2dkGeOABk>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Dec 2019 19:29:12 -0000

Thanks Pablo and Happy Imminent New Year.

> I have reviewed your suggested changes and incorporated them
> in the latest revision of the document. 

Great. I will try to pull that and review it soon.

> Please see below inline for more detail.

[snipped]
     
    >> 4.1
    >>
    >> I was surprised by...
    >>
    >>  S01. When an SRH is processed {
    >>  S02.   If (Segments Left == 0) {
    >>  S03.      Send an ICMP Parameter Problem message to the Source Address
    >>               Code TBD-SRH (SR Upper-layer Header Error),
    >>               Pointer set to the offset of the upper-layer header,
    >>               interrupt packet processing and discard the packet
    >>  S04.   }
    >>  S05.   If (IPv6 Hop Limit <= 1) {
    >>  S06.      Send an ICMP Time Exceeded message to the Source Address,
    >>               Code 0 (Hop limit exceeded in transit),
    >>               interrupt packet processing and discard the packet
    >>  S07.   }
    >>
    >> Are you sure that Hop Limit processing is left so late? Isn't it one of
    >> the first things done with a packet before even the SRH is discovered to
    >> be present?
    >
    > PC: Is there any difference on the hop limit check if I do it two lines earlier? 
    > I believe that the end result is the same.
     
    It makes a difference which ICMP error is sent. I would argue that you shouldn't be looking at the SRH of a packet when the Hop Limit has expired.

PC: I've checked with the SRH draft and the ICMP check is the last check happening in the pseudocode. I would tend to agree that this should be the last thing done once you have determined that the packet needs to be forwarded. 

AF: So, just to check I understand what you are saying. If a packet arrives with Hop Limit already at zero you would still look inside the SRH?
  
    >> 4.1 (and other sections)
    >> 
    >> I spent rather too much time trying to work out
    >> 
    >>  S08.   max_LE = (Hdr Ext Len / 2) - 1
    >>  S09.   If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
    >> 
    >> As far as I can see, for an SRH,
    >> 
    >>   Hdr Ext Len = 7 + (16 * (Last Entry + 1) ) + sum(all TLV lengths)
    >> 
    >> So, while I see that you want to check that Last Entry doesn't point out
    >> beyond the end of the SRH, I don't see how your computation of max_LE 
    >> helps.
    >> 
    >> What have I missed?
    > 
    > PC: How do you propose to check whether Last Entry value exceeds
    > the maximum possible theoretical Last Entry value?
    > The only information you have is the Header Extension Length. Based
    > on this I compute the maximum theoretical Last Entry possible value,
    > and then just compare the values.
    >
    > Maybe I am the one who have missed something. If you have a simpler
    > proposal please let me know.
    
    OK, we agree that the right thing to do is work out the largest possible Last Entry value (max_LE) and compare it to the actual Last Entry value. That is good.
    
    I also agree that all you have in hand is the Header Extension Length (Hdr Ext Len)
    
    I just don't think that you are computing the right value for max_LE using max_LE = (Hdr Ext Len / 2) - 1.
    
    I would agree that max_LE < (Hdr Ext Len / 2) - 1  so that comparing Last Entry with that value provides a check. I just don't think it is a very precise check.
    
    Perhaps my understanding of the actual value of Hdr Ext Len is incorrect, but if I am right, then you could probably get closer to a good number.
   
PC: Ok. I rechecked it and I believe that we cannot get any better than that.
[RFC8200]
Hdr Ext Len         8-bit unsigned integer.  Length of the Routing
                              header in 8-octet units, not including the
                              first 8 octets.
[draft-ietf-6man-segment-routing-header-26]
o  Last Entry: contains the index (zero based), in the Segment List,
   of the last element of the Segment List.

Let us consider an SRH containing k SIDs and 0 or more TLVs.
Hdr Ext Len >= k x (16 / 8) = k x 2
Last Entry = k - 1

Isolating k on one side of each equation:
k <= Hdr Ext Len / 2
k = Last Entry + 1

Combining the two equations together:
Last Entry + 1 <= Hdr Ext Len / 2

Isolating Last Entry on one side of the equation:
Last Entry <= Hdr Ext Len / 2 - 1

Further note that, if no TLV is present, we have:
Last Entry = Hdr Ext Len / 2 - 1

PC: If I'm still missing the point let me know!

AF: Very (very) sorry. My bad.
I entirely missed " Length of the Routing header *in*8-octet*units*, not including the first 8 octets"
Now I feel stupid.

    >> 6.1
    >> 
    >> I agree with this section, but I am concerned that you are updating 
    >> draft-ietf-6man-segment-routing-header by adding normative language to
    >> describe nodes that process the SRH. Does that mean you should use an
    >> "Updates" clause in the document header?
    >>  
    >> After describing CNT-1 and CNt-2 you say...
    >> 
    >>   Furthermore, an SRv6 capable node maintains an aggregate counter
    >>   CNT-3 tracking the IPv6 traffic that was received with a destination
    >>   address matching a local interface address that is not a locally
    >>   instantiated SID and the next-header is SRH with SL>0.
    >> 
    >> That looks like s/maintains/MUST maintain/ unless you have a reference
    >> for the assertion that it does maintain CNT-3.
    >
    > PC: I disagree that this is an update to the SRH. The SRH defines a
    > header and one type of segment processing.
    > Defining a counter is not related to the SRH at all.
     
    Well, perhaps you didn't just say what you meant to say because the text I quoted most clearly says that the counter is counting events related to the SRH.
    
    But to the point: the document says...
       Any SRv6 capable node SHOULD implement the following set of combined
       counters (packets and bytes):
    "Any SRv6 capable node" is clearly in the scope of draft-ietf-6man-segment-routing-header

PC: This document talks of the processing and behaviours of SRv6. And hence the counters are included in this draft.

AF: Last try before I give up on this one (you may be relieved to know).
Does every device that supports SRv6 have to support this document? I had formed the impression not: that is a simple SRv6 routing node functions fine without this document (even if this document also describes it's behaviour). But, in the quoted text you are adding description of function for all "SRv6 capable nodes" that is not described elsewhere. So either:
- it is not possible to have an SRv6 capable node prior to this draft
or
- you are updating some other document that describes SRv6 capable nodes

Many thanks for the work,
Adrian