Re: [spring] draft-voyer-spring-sr-replication-segment-03

bruno.decraene@orange.com Wed, 15 July 2020 18:02 UTC

Return-Path: <bruno.decraene@orange.com>
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 226C53A0A47; Wed, 15 Jul 2020 11:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 MJ2gB_XXssiq; Wed, 15 Jul 2020 11:02:22 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2323E3A0943; Wed, 15 Jul 2020 11:02:22 -0700 (PDT)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4B6QFm5phgzCrWT; Wed, 15 Jul 2020 20:02:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1594836140; bh=rHaeP1/2QrSm22SaC+ZZDiupgmaNe/7ngFZhgRuYnTQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=B0b6EoRDPNrKXRzWfdAsxfrLVXyWMttwAWtSGuUYIAJZqdBkL3yN5j/SqjlkJdidO JayVPEthnyGvh/hC7100jjENIPU0rDpEbwlFckII411ObXgxfEhl1Idu365lwkoK4S BKxl1pxWMe/g4vgb9M/K/p2M/vvuCIlhRIKLn5ENPgn3LKjQmwN2L108PLN8MTu9SA 3WfmUFvKCmxgyBuCtpm3aOxGts/LMHstAjR47UlUKnIIJlwu+q1S65OBCBAoVeiZVO qEKQ/zGQQIzwyUNBJWsICgUaFXD8ifora7OUL1GkyEtwVTSJgizebfv7yszW/pUrva 0Us+vLnVa+f3Q==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4B6QFm56twzDq88; Wed, 15 Jul 2020 20:02:20 +0200 (CEST)
From: bruno.decraene@orange.com
To: Rishabh Parekh <rishabhp@gmail.com>
CC: "draft-voyer-spring-sr-replication-segment@ietf.org" <draft-voyer-spring-sr-replication-segment@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] draft-voyer-spring-sr-replication-segment-03
Thread-Index: AQHWVX+HVDrO2IutvkaXZ/7FKJYDSKkIvGtg
Date: Wed, 15 Jul 2020 18:02:20 +0000
Message-ID: <10757_1594836140_5F0F44AC_10757_226_1_53C29892C857584299CBF5D05346208A48EDF693@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <3632_1594220860_5F05E13C_3632_134_1_53C29892C857584299CBF5D05346208A48ECD7AA@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CABjMoXbqhmkhxJQr9NwXJW8C5KhR_hp-AvMks6ZgJgtQ9fi92Q@mail.gmail.com>
In-Reply-To: <CABjMoXbqhmkhxJQr9NwXJW8C5KhR_hp-AvMks6ZgJgtQ9fi92Q@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/NBw622KDBqUbdKg6qokfdFObMT4>
Subject: Re: [spring] draft-voyer-spring-sr-replication-segment-03
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: Wed, 15 Jul 2020 18:02:30 -0000

Rishabh,

Thanks for answers and new -04
Please see inline [Bruno]

Still speaking as an individual WG member.


> -----Original Message-----
> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Rishabh Parekh
> Sent: Thursday, July 9, 2020 1:28 AM
> To: DECRAENE Bruno TGI/OLN <bruno.decraene@orange.com>
> Cc: draft-voyer-spring-sr-replication-segment@ietf.org; spring@ietf.org
> Subject: Re: [spring] draft-voyer-spring-sr-replication-segment-03
> 
> Bruno,
> Replies inline
> 
> > ---
> >
> > "A SR Replication segment allows a packet to be replicated from a
> replication node to downstream nodes."
> >
> > May be adding "Each downstream node is reached by using a unicast
> segment or SR policy."
> >
> > (otherwise, the building of a multicast tree seem possibly within the scope)
> >
> >
> If the downstream node is directly connected, we don't need a unicast
> segment or SR policy to reach that node, just an interface to that
> node is sufficient.

[Bruno] Agreed, in this specific case, you don't need the SID on the _packet_. 
- Still the PCE/configuration CLI/YANG need a way to identify this interface and it could be via a SID (e.g. both local adjacency SID and global nodes SID (assuming PHP) seems to work, depending on needs)
- It seems to me that SR Policy draft is in the same situation, and they still call this an SR Policy.
But that's a detail.
 
[...]
 
> >
> > -------
> >
> > " o  When the Active Segment [RFC8402] is the Replication SID.  In this
> >
> >       case, the operation for a replicated copy is CONTINUE."
> >
> >
> >
> > "CONTINUE" would mean that the segment is not a local segment.
> >
> > So the document really needs to clarify whether the replication
> SID/segment is a local segment, or a global segment, or something new to be
> defined..
> >
> >
> The CONTINUE operation just captures the label swap for each
> replication, with just the Downstream Replication SID in the simplest
> case.

"CONTINUE: the active segment is not completed; hence, it remains
   active.  In SR-MPLS, the CONTINUE operation is implemented as a SWAP
   of the top label [RFC3031].  In SRv6, this is the plain IPv6
   forwarding action of a regular IPv6 packet according to its
   destination address."
https://tools.ietf.org/html/rfc8402#section-2

1) SR terminology
Given that I think that we agreed that the replication segment is a local segment (i.e. local to one node), I don't see how it could continue once used. As we used it on the single node which understand it, it needs to be terminated (NEXT).

2) Data plane
2.a) SR-MPLS
I don't see a label swap. I see a pop of the BSID/replication SID and a push of the list of SID in the SR-policy. As described in  https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-08#section-8.3
"Let us assume that headend H has a valid SR Policy P of Segment-List
   <S1, S2, S3> and BSID B.

   When H receives a packet K with label stack <B, L2, L3>, H pops B and
   pushes <S1, S2, S3> and forwards the resulting packet according to
   SID S1."

2.b) SRv6
Quoting RFC 8402 (above): "In SRv6, this is the plain IPv6
   forwarding action of a regular IPv6 packet according to its
   destination address"
I don't see how this can translate in a specific SR action (here "replication" on the replication node. ) But since there is no SRv6 specific text in the draft, it's hard to guess.


Note that my understanding seems to match your new text/illustration in appendix: there is no CONTINUE operation on a replication SID. Only NEXT operation:
" R2, as Leaf, performs NEXT operation, pops R-SID2 label and delivers the payload."
"R6, as Leaf, performs NEXT operation, pops R-SID1 label and delivers the payload." 
"R7, as Leaf, performs NEXT operation, pops R-SID7 label and delivers the payload."

BTW, there may be two typos in the draft:
"R6, as Leaf, performs NEXT operation, pops R-SID1 label and delivers the payload."
:s/R-SID1/R-SID6

OLD:    Replication State:
                R2: <R-SID1->L12>"

NEW:    Replication State:
                R2: <R-SID2, L12>"
 
Thanks,
Regards,
--Bruno

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.