RE: [spring] “SRV6+” complexity in forwarding

Regarding RFC6554, I think it is a good example for us to discuss compression.

C-SID follows the similar thought of RFC6554, which reduces the same part of SRv6 SID while only carries the different part.

This mechanism does not introduce new type of SID function, but only enhances the encoding efficiency of SRH. https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00

Welcome to review our document, and we will update it very soon.

Best regards,
Cheng

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Friday, September 20, 2019 3:50 AM
To: Reji Thomas <rejithomas.d@gmail.com>
Cc: xiechf@chinatelecom.cn; SPRING WG <spring@ietf.org>; 6man <6man@ietf.org>; Dirk Steinberg <dirk@lapishills.com>; Rob Shakir <robjs@google.com>; Tarek Saad <tsaad.net@gmail.com>; Srihari Sangli <ssangli=40juniper.net@dmarc.ietf.org>
Subject: Re: [spring] “SRV6+” complexity in forwarding

Hi Reji,

Notice what it says: " ... explicitly listed intermediate nodes ... "

CRH which is used in SRv6+ does not explicitly list intermediate nodes so I do not think the procedures in IPv6 spec apply as the way you interpret them.

But I am i no way authoritative ... still learning IPv6 and this thread become great education.

An real example where those procedure apply is documented in RFC6554 which does put the addresses explicitly.

Many thx,
Robert.

On Thu, Sep 19, 2019 at 9:14 PM Reji Thomas <rejithomas.d@gmail.com<mailto:rejithomas.d@gmail.com>> wrote:
Hi Robert,

>>I do not know what is the difference between IPv6 Destination Address in the fixed header and "final destination". Where do you carry "final destination" address ?

See Section 4.4 in RFC 8200.  Hope its clear what's the final destination and the context in which it is used.

      Segments Left       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.

Regards

Reji

On Thu, Sep 19, 2019 at 10:26 PM Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:
IPv6 fixed header has only one destination address. So TE midpoint is either a packet's destination or not. It can not be both.

I do not know what is the difference between IPv6 Destination Address in the fixed header and "final destination". Where do you carry "final destination" address ?

Many  thx,
R.

On Thu, Sep 19, 2019 at 6:17 PM Reji Thomas <rejithomas.d@gmail.com<mailto:rejithomas.d@gmail.com>> wrote:

Hi Robert,

>>Well the crux of the matter is that you still need to process all EHs at each IPv6 destination which here means each transit node per RFC8200

 From RFC 8200 that doesn't seem to be the case or at least as I understand. See  Section 4.1 note 1 and note 3. Am I missing something?

IPv6 header

      Hop-by-Hop Options header

      Destination Options header (note 1)

      Routing header

      Fragment header

      Authentication header (note 2)

      Encapsulating Security Payload header (note 2)

      Destination Options header (note 3)

      Upper-Layer header

      note 1: for options to be processed by the first destination that

              appears in the IPv6 Destination Address field plus

              subsequent destinations listed in the Routing header.

      note 2: additional recommendations regarding the relative order of

              the Authentication and Encapsulating Security Payload

              headers are given in [RFC4303<https://tools.ietf.org/html/rfc4303>].

      note 3: for options to be processed only by the final destination

              of the packet.

Regards
Reji

On Thu, Sep 19, 2019 at 9:00 PM Robert Raszuk <rraszuk@gmail.com<mailto:rraszuk@gmail.com>> wrote:

I disagree. PPSI and PSSI leverages the DOHs in IPv6 architecture better. The SRv6+ drafts explain the usecases better FYI.

Well the crux of the matter is that you still need to process all EHs at each IPv6 destination which here means each transit node per RFC8200. That is regardless what any other spec says .... unfortunately.

Best,
R.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring