Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-11.txt>

"Darren Dukes (ddukes)" <ddukes@cisco.com> Thu, 05 April 2018 22:38 UTC

Return-Path: <ddukes@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A571267BB for <ipv6@ietfa.amsl.com>; Thu, 5 Apr 2018 15:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 lGogrGjjs2xB for <ipv6@ietfa.amsl.com>; Thu, 5 Apr 2018 15:38:32 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBAE9120454 for <ipv6@ietf.org>; Thu, 5 Apr 2018 15:38:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=73736; q=dns/txt; s=iport; t=1522967912; x=1524177512; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yVdAHch2BuskfuB9zBAK3vydR9270yoS7BLctRICnIg=; b=XzdcnQyelrOBqR1R3iN7kSvnzKEIXuUPRpkVcby9pUat7dC14CCSiNwL ZlvWdJyIm9LYoL5+2HWuznqEKZ02yC1PD8C5E+QgkfU1vdFCgnTgk2EQ1 wOaCzifAzNXL60AebxV3yevB61TJHwq9TyJA2xQ8LMsLPMrAeFjHwApKF U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DFAACupMZa/5xdJa1dGQEBAQEBAQEBAQEBAQcBAQEBAYJNdWFvKAqDVYgAjQqBUyGBD4Zhi3SBegsjhGACGoIUITQYAQIBAQEBAQECbBwMhSIBAQEBAx0GSwsMBAIBCA4DBAEBIQEGAwICAh8RFAkIAgQOBYQpTAMVD6skghyHEg2BK4IgBYdqgVQ/gS4MglaCT0IEGIRCMIIkAocliSWGSiwIAoVRhWGCfYEyiwuHKYFxPIYGAhETAYEkARw4gVJwFToqAYIYhXyKUm+MPQGBFgEB
X-IronPort-AV: E=Sophos; i="5.48,412,1517875200"; d="scan'208,217"; a="94287411"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2018 22:38:30 +0000
Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w35McU53009510 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Apr 2018 22:38:30 GMT
Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 5 Apr 2018 17:38:29 -0500
Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1320.000; Thu, 5 Apr 2018 17:38:29 -0500
From: "Darren Dukes (ddukes)" <ddukes@cisco.com>
To: Ron Bonica <rbonica@juniper.net>
CC: stefano previdi <stefano@previdi.net>, IPv6 List <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-11.txt>
Thread-Topic: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-11.txt>
Thread-Index: AQHTzRXAIX2T3+Ty60GW4CyjmsseSaPy/agAgAAZnwA=
Date: Thu, 05 Apr 2018 22:38:29 +0000
Message-ID: <7042FA53-AEC8-4428-BFAB-5777E524381E@cisco.com>
References: <20160428004904.25189.43047.idtracker@ietfa.amsl.com> <FB1C6E49-81F7-49DD-8E8B-2C0C4735071B@gmail.com> <SN6PR05MB424035B6FECB0057676067B1AEA40@SN6PR05MB4240.namprd05.prod.outlook.com> <87EAF1D7-FC8A-4661-990E-ECCF4AA7C12E@previdi.net> <SN6PR05MB42406D76603C4D7E1B3BE321AEBB0@SN6PR05MB4240.namprd05.prod.outlook.com> <11D3A431-705F-49F8-8F8B-F0668B9289B8@cisco.com> <SN6PR05MB4240DCD7B55FAAE93D31BF75AEBB0@SN6PR05MB4240.namprd05.prod.outlook.com>
In-Reply-To: <SN6PR05MB4240DCD7B55FAAE93D31BF75AEBB0@SN6PR05MB4240.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.192.95]
Content-Type: multipart/alternative; boundary="_000_7042FA53AEC84428BFAB5777E524381Eciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/qGw5ZmIWyGqrgFq61-mc1_Zvcuo>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2018 22:38:36 -0000

See inline.

On Apr 5, 2018, at 5:06 PM, Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>> wrote:

Darren,

Thanks! I am feeling much better than yesterday!

I think that we are getting to the bottom of that subtle difference between SL in RFC 8200 and SL in draft-ietf-6man-segment-routing-header.

In RFC 8200, a node receives a packet that satisfies the following conditions:

- IPv6 Destination Address is local to the node
- Packet contains a Routing Extension Header
- Routing Extension Header SL value is equal to 0

The correct behavior is to skip over the Routing Extension Header and process the next header. The Routing Extension Header has already been completely processed by upstream nodes. In fact it doesn't even matter if the node recognizes the Routing Extension Type. The node will skip over it, regardless of its type.

Agreed

In draft-ietf-6man-segment-routing-header, a node receives a packet that satisfies the same conditions.

The required behavior is to process the instruction in Segment List [0].

You are still incorrect here, this doesn’t match the text in the draft. You certainly don’t match the END processing in Section 4.1.

The required behavior is to process the instruction in the DA (which happens to be the same as Segment List[0] when SL=0)
We always process the instruction in the DA as mentioned in Section 4.1.
The Segment List is used to put the next instruction in the destination address and forward.  That’s it.

Darren

When I has done this, the Routing Extension Header will be completely processed. The node better recognize the SRH, because skipping the instruction might be dangerous.

The difference between SL in RFC 8200 and SL in draft-ietf-6man-segment-routing is subtle, but significant.

                                                                        Ron

-----Original Message-----
From: Darren Dukes (ddukes) <ddukes@cisco.com<mailto:ddukes@cisco.com>>
Sent: Thursday, April 5, 2018 3:39 PM
To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Cc: stefano previdi <stefano@previdi.net<mailto:stefano@previdi.net>>; IPv6 List <ipv6@ietf.org<mailto:ipv6@ietf.org>>; Bob
Hinden <bob.hinden@gmail.com<mailto:bob.hinden@gmail.com>>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-
header-11.txt>

Hi Ron, I’m glad you’re feeling a bit better.



Your analysis of SL is not correct.  Both 2460, 8200 and SRH say the same thing
for SL==0 but you’re getting stuck on what 'the index, in the Segment List, of
the next segment to inspect’ means.



Using the same example from 2460 section 4.4 but modifying for the
Segment List[] defined in SRH.



As the packet travels from S to I1:

       Source Address = S                  Hdr Ext Len = 6

       Destination Address = I1            Segments Left = 3

                                           Segment List[0] = D

                                           Segment List[1] = I3

                                           Segment List[2] = I2

                                           Segment List[3] = I1

  As the packet travels from I1 to I2:

       Source Address = S                  Hdr Ext Len = 6

       Destination Address = I2            Segments Left = 2

                                           Segment List[0] = D

                                           Segment List[1] = I3

                                           Segment List[2] = I2

                                           Segment List[3] = I1

 As the packet travels from I2 to I3:

       Source Address = S                  Hdr Ext Len = 6

       Destination Address = I3            Segments Left = 1

                                           Segment List[0] = D

                                           Segment List[1] = I3

                                           Segment List[2] = I2

                                           Segment List[3] = I1

  As the packet travels from I3 to D:

       Source Address = S                  Hdr Ext Len = 6

       Destination Address = D             Segments Left = 0

                                           Segment List[0] = D

                                           Segment List[1] = I3

                                           Segment List[2] = I2

                                           Segment List[3] = I1

SL always points to the "next segment to inspect", that segment is also in the
Destination Address.

For example between I1 and I2, the next segment to inspect is I2, the SL==2
which is the index in Segment List of I2.

The same is true for I3 to D where SL==0, the next segment to inspect is D,
but the SRH need not be processed because SL==0.



Section 4.1 of SRH shows this quite clearly in its description of the END
function where SL is decremented then the Segment at SRH[SL] is used to
update the Destination Address.

1. IF SegmentsLeft > 0 THEN

2.    decrement SL

3.    update the IPv6 DA with SRH[SL]

4.    FIB lookup on updated DA

5.    forward accordingly to the matched entry

8.  ELSE

7.    drop the packet





I hope this clears up the confusion.



Darren



On Apr 5, 2018, at 2:44 PM, Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>> wrote:



Hi Stephano,



I'm glad you asked this question. RFC 8200 and draft-ietf-6man-segment-
routing-header define Segments Left (SL) differently. The difference is a bit
subtle and took me a few readings to catch.



RFC 8200 defines SL as follows:



"8-bit unsigned integer.  Number of route  segments remaining, i.e.,
number of explicitly listed intermediate nodes still to be visited before
reaching the final destination."



Therefore, if a packet arrives at a node and the following conditions are
true, the node skips over the Routing Extension Header and processes the
next header:



- The packets IPv6 Destination address is local to the node

- The packet contains a Routing Extension Header

- The SL value in the Routing Extension Header is equal to 0



In RFC 2460, Routing Extension Type RH0 was compliant with this behavior.
The description of RHO (RFC 2460, Section 4.4) explains how RH0 used to
process SL, offering pseudocode and an example. Between the publication
of RFC 2460 and RFC 8200, RHO was deprecated for other reasons. Therefore,
the detailed example of SL handling was not brought forward into RFC 8200.



But even though this example was not brought forward into RFC 8200, it
explains why RFC 8200 says:



"If, while processing a received packet, a node encounters a Routing
header with an unrecognized Routing Type value, the required behavior of
the node depends on the value of the Segments Left field, as  follows:



If Segments Left is zero, the node must ignore the Routing header and
proceed to process the next header in the packet, whose type is identified
by the Next Header field in the Routing header.



If Segments Left is non-zero, the node must discard the packet and  send
an ICMP Parameter Problem, Code 0, message to the packet's Source
Address, pointing to the unrecognized Routing Type."



This is because an SL value of 0 means that the Routing Extension Header
has already been completely processed by upstream nodes. Even if the node
recognized the Routing Type, it still would skip over it.



By contrast, draft-ietf-6man-segment-routing header defines the
Segments Left as follows:



"Defined in [RFC8200], it contains the index, in the Segment List, of the
next segment to inspect.  Segments Left  is decremented at each segment.



Therefore, if a packet arrives at a node and the following conditions are
true, the node processes Segment[0]:



- The packets IPv6 Destination address is local to the node

- The packet contains a Routing Extension Header

- The SL value in the Routing Extension Header is equal to 0



This is different from the behavior described in RFC 8200 and 2460. It also
raises two questions:



- If the node doesn't recognize SRH, is it safe to ignore the SRH, as
recommended by RFC 8200

- If the node does recognize SRH and the segment requires decapsulation
and forwarding, are Extension Headers that follow SRH (e.g. Fragment,
Destination Options) ignored?



                                                           Ron





-----Original Message-----

From: stefano previdi <stefano@previdi.net<mailto:stefano@previdi.net>>

Sent: Thursday, April 5, 2018 5:30 AM

To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>

Cc: Bob Hinden <bob.hinden@gmail.com<mailto:bob.hinden@gmail.com>>; IPv6 List <ipv6@ietf.org<mailto:ipv6@ietf.org>>

Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-

header-11.txt>



Ron,



on comment 5:





Section 2.2 SRv6 Segment (Comment 5)



According to RFC 8200:



"If, while processing a received packet, a node encounters a Routing

header with an unrecognized Routing Type value, the required behavior
of

the node depends on the value of the Segments Left field, as follows:



-  If Segments Left is zero, the node must ignore the Routing header and

proceed to process the next header in the packet, whose type is
identified

by the Next Header field in the Routing header.



-  If Segments Left is non-zero, the node must discard the packet and
send

an ICMP Parameter Problem, Code 0, message to the packet's Source

Address, pointing to the unrecognized Routing Type."



This is safe, so long as all Routing Extension Types use SL == 0  to indicate

that the Routing Extension Header has been completely processed. It is
may

not be safe when SL == 0 means that one more segment needs to be

processed.



In the SRH, SL == 0 indicates that one more segment needs to be

processed.





sorry, I don’t understand.



Can you point me the text in draft-ietf-6man-segment-routing-header
that

states that ?



If it’s the case it should be obviously corrected.



SL==0 means the packet is traveling within the last segment.



draft-ietf-6man-segment-routing-header does not modify the semantic
of

“Segments Left”.



It does modify the way segment list is encoded (that’s one of the reason
it’s

a different routing header type) but not the "Segments Left” field
semantic.



s.











--------------------------------------------------------------------

IETF IPv6 working group mailing list

ipv6@ietf.org<mailto:ipv6@ietf.org>

Administrative Requests:
https://urldefense.proofpoint.com/v2/url?u=https-
3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6S
cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
AWF2EfpHcAwrDThKP8&m=WmPR-
DmQkiyFhWqdRohhiCg015eX46xGJmHofETXsM0&s=7bmAIXTGfcwjaJMMnP
w7zYDgOQmzyIQ66CYofnt72Dw&e=

--------------------------------------------------------------------