IETF Logo Mail Archive

Re: [spring] [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

Peter Psenak <ppsenak@cisco.com> Mon, 06 April 2020 11:03 UTC

Return-Path: <ppsenak@cisco.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 B14433A0E59; Mon, 6 Apr 2020 04:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.601
X-Spam-Level:
X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no 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 kf09OQU7ZfRO; Mon, 6 Apr 2020 04:03:13 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69AD23A0E57; Mon, 6 Apr 2020 04:03:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48673; q=dns/txt; s=iport; t=1586170992; x=1587380592; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=arxlknEgARtI0sqgaTnq3M3zfqUwNbM4CqracaeRafU=; b=XEyUn8GYuzgcsXkmfjfkLrhryN3CnxhUDbEtOfi6MO/jQSDd2uBEYqC2 re1GLZvgEhc1qvXZPEz75HetLZ2Q50R000Zs93+W0HQxdR1Q0dX6G8gf/ j6OmUvRsa4WIokZZUeV1GXoJOBNKGSKR3fTNNgl4BHCoOz8j0jaQzShTU I=;
X-IronPort-AV: E=Sophos;i="5.72,350,1580774400"; d="scan'208";a="25020871"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Apr 2020 11:03:10 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 036B391d023330; Mon, 6 Apr 2020 11:03:10 GMT
To: Chris Bowers <chrisbowers.ietf@gmail.com>
Cc: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, SPRING WG List <spring@ietf.org>, Bruno Decraene <bruno.decraene@orange.com>
References: <CAHzoHbtmJGB8QY==A5EMzzSwh+8bQjhbVgPBjA3kHJGxpCD_zA@mail.gmail.com> <MW3PR11MB4570EDAE9E6AF17C9CCC9899C1E80@MW3PR11MB4570.namprd11.prod.outlook.com> <7453_1582899837_5E59227C_7453_80_1_53C29892C857584299CBF5D05346208A48DD14BA@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CAHzoHbu4k15xJ2mnwp=9Xa400gQBtBY=OaSh6sh3_8E_t30sdA@mail.gmail.com> <MW3PR11MB4570E85308182AEA3D9E1BDBC1E50@MW3PR11MB4570.namprd11.prod.outlook.com> <CAHzoHbu3tNPv+=Fs-4o-PKxXhjt6tBReiyuyGVvFpdaVuJvqSA@mail.gmail.com> <MW3PR11MB457046873C2D009073459CCBC1FD0@MW3PR11MB4570.namprd11.prod.outlook.com> <CAHzoHbumzM76CFZCp+ec_OHvo+NCbMRRhtx7evGuw=DrZk1rZA@mail.gmail.com> <4bf64ede-c20b-2269-af11-1dffc5328935@cisco.com> <CAHzoHbv3k2Thri-hx=FYOYFXEgqDXQagLzJjC8XQ2btgYgey0Q@mail.gmail.com> <84b355a9-d3ce-af0e-ae60-f765aab4ec63@cisco.com> <CAHzoHbsdkd7p2RdyZ2Y3_e1XTLTn=zt+GKbmGYmaAYjsNC=hNg@mail.gmail.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <b5d0a98a-28e4-13c1-961f-fa93eb5c09af@cisco.com>
Date: Mon, 06 Apr 2020 13:03:09 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <CAHzoHbsdkd7p2RdyZ2Y3_e1XTLTn=zt+GKbmGYmaAYjsNC=hNg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/hhuQDKcEtdw4Gdl8tnU8U9m88dY>
Subject: Re: [spring] [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions
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: Mon, 06 Apr 2020 11:03:17 -0000

Chris,

On 01/04/2020 21:58, Chris Bowers wrote:
> Peter,
> 
> There seem to be two disconnects in this discussion.
> 
> 1) The response below implies that the encodings in 
> draft-ietf-lsr-isis-srv6-extensions are supposed represent the case 
> where the locators are allocated from several different IPv6 address 
> blocks (for example, blocks S1/s1 through Sn/sn). However, 
> draft-ietf-spring-srv6-network-programming and 
> draft-ietf-6man-segment-routing-header only discuss the case where the 
> locators are allocated from a single block (S/s).  If an implementation 
> is expected to properly encode the case where locators are allocated 
> from several different IPv6 address blocks, then I think that case 
> should be explicitly described in these documents.


There is no statement in draft-ietf-spring-srv6-network-programming that 
the block is unique. As an example, Iliad authorized me to indicate that 
their SRv6 deployment involves several blocks.


> 
> 2)   The response below says "To be able to find out where the func and 
> arg are located, you need to know the LOC length, e.g. Block and Node 
> length."  However, the SRv6 SID Structure Sub-Sub-TLV is carried within 
> the SRv6 End SID, SRv6 End.X SID, and the SRv6 LAN End.X SID Sub-TLVs, 
> which are carried within the SRv6 Locator TLV.  

not really. SRv6 End.X SID, and the SRv6 LAN End.X SID Sub-TLVs are 
advertised in the IS Reachability TLVs (22, 23, 222, 223, 141), not in 
SRv6 Locator TLV.

thanks,
Peter


> The  SRv6 Locator TLV 
> has a Loc-Size field.  Why would the value of the LOC length computed as 
> the sum of the Block and Node length ever be different from the value in 
> the Loc-Size field?
> 
> Chris
> 
> 
> On Wed, Mar 25, 2020 at 9:49 AM Peter Psenak <ppsenak@cisco.com 
> <mailto:ppsenak@cisco.com>> wrote:
> 
>     Chris,
> 
>     please see inline:
> 
> 
>     On 23/03/2020 17:39, Chris Bowers wrote:
>      > Peter,
>      >
>      > The proposed SRv6 SID Structure Sub-Sub-TLV has several problems.
>      >
>      > 1) As discussed in item#3 below, it is not clear that flooding LB
>      > Length, LN Length, Fun. Length, and Arg. Length to all ISIS
>     speakers is
>      > really the right approach.  However, if the WG determines that it
>     is the
>      > right approach, the current encodings of this information in the
>      > proposed SRv6 SID Structure Sub-Sub-TLV are problematic.  As
>     discussed
>      > earlier in this thread, a network operator may choose to not
>     allocate
>      > all locators from a single block, so LB Length and LN Length may
>     not be
>      > well-defined.
> 
>     I'm not sure what do you mean by not "well defined". For every SID you
>     need to know the LOC (B+N) part. If you guarantee that it is the
>     same on
>     all nodes, you know it from the local config, otherwise, you advertise
>     it with a SID.
> 
>      > The current encoding of the SRv6 SID Structure
>      > Sub-Sub-TLV makes it difficult to represent this situation.  The
>     simple
>      > thing to do for nodes that don't have a well-defined value of LB
>     Length
>      > and LN Length would be to not advertise a value for LB Length and LN
>      > Length.  However, since the currently proposed SRv6 SID Structure
>      > Sub-Sub-TLV combines LB Length, LN Length, Fun. Length, and Arg.
>     Length
>      > into a single sub-sub-TLV, if a node wants to advertise values
>     for Fun.
>      > Length and Arg. Length, it also has to advertise values for LB
>     Length
>      > and LN Length.  It seems like a better approach would be to have
>      > different sub-sub-TLVs, one for  LB Length and LN Length, and a
>     separate
>      > one for Fun. Length and Arg. Length to be able to better
>     represent this
>      > situation.
> 
> 
>     I'm afraid you are missing an important point.
> 
>     SRv6 SID is defined as LOC:FUNCT:ARG, where LOC is represented as B:N.
>     To be able to find out where the func and arg are located, you need to
>     know the LOC length, e.g. Block and Node length. Advertising just Func
>     and Arg length does not help.
> 
> 
>      >
>      > 2) Now consider the situation where a network operator chooses to
>      > allocate all locators from a single block, so that LB Length and LN
>      > Length are well-defined across the network.  A given node should
>      > presumably advertise its own understanding of LB Length and LN
>     Length.
>      > A given node's understanding of LB Length and LN Length is a
>     property of
>      > the node.  It is not a property of a given End SID.  The currently
>      > proposed SRv6 SID Structure Sub-Sub-TLV however is carried within
>     each
>      > End SID Sub-TLV.  With the currently proposed encoding,
>     presumably an
>      > implementation is expected to send the exact same values of LB
>     Length
>      > and LN Length for all of the End SIDs that it advertises.  Not
>     only is
>      > this inefficient, but it creates the need for logic to decide
>     what to do
>      > when different End SIDs advertised by the same node carry different
>      > values of LB Length and LN Length in their sub-sub-TLVs.  It
>     seems like
>      > a better approach would be for a given node to advertise its
>      > understanding of the value of LB Length and LN Length in a
>     sub-TLV of
>      > the Router Capability TLV.
> 
>     When we design the encoding, we have to define it such, that it
>     supports
>     all possible use cases. We can not design the encoding that works for
>     single use case (allocate all locators from a single block) and does
>     not
>     work for others - different block from different node, multiple blocks
>     on a single node (e.g. border node), which are all valid.
> 
>      >
>      > 3) At this point, the only use case that has been proposed for
>     flooding
>      > the LB Length, LN Length, Fun. Length, and Arg. Length to all ISIS
>      > speakers is to make it more convenient for BGP-LS to get those
>     values to
>      > an external controller as part of a topology feed from any ISIS
>     node.
>      > No use case has been proposed for ISIS speakers themselves to
>     make use
>      > of the information.  It seems like a more scalable approach would
>     be to
>      > use BGP-LS sessions to collect the information from the subset of
>     nodes
>      > that actually produce the relevant information.  So far there are
>     no End
>      > SIDs defined that are advertised in ISIS that have a non-zero Arg.
>      > Length.  If an End SID with non-zero Arg. Length were to be
>     proposed in
>      > the future as needing to be flooded to all ISIS nodes, it seems
>     likely
>      > that the new End SID would also be advertised using the BGP
>     IP/VPN/EVPN
>      > control plane.   So it seems like a viable alternative for this
>      > hypothetical future End SID would be to have the subset of nodes
>     that
>      > have non-zero Arg. Length values communicate to an external
>     controller
>      > via  BGP sessions. I think the WG needs a more detailed
>     discussion of a
>      > concrete use case in order to determine whether flooding LB
>     Length, LN
>      > Length, Fun. Length, and Arg. Length to all ISIS speakers is
>     really the
>      > right approach.
> 
>     there are networks, where BGP is not deployed on all nodes, only on a
>     few nodes that re-distribute the information to BGP-LS. In such case we
>     need the IGP to distribute this data.
> 
>     Argument that "it seems likely that the new End SID would also be
>     advertised using the BGP IP/VPN/EVPN" is a wishful thinking that we can
>     not based our encoding on.
> 
> 
>      >
>      > Given the lack of a compelling use case for flooding LB Length, LN
>      > Length, Fun. Length, and Arg. Length to all ISIS speakers and the
>      > problems with the currently proposed encodings for doing that, I
>     think
>      > that the SRv6 SID Structure Sub-Sub-TLV should be removed from
>      > draft-ietf-lsr-isis-srv6-extensions. A mechanism for flooding LB
>     Length,
>      > LN Length, Fun. Length, and Arg. Length to all ISIS speakers can be
>      > defined in a future document.
> 
>     The security use case has already been pointed out earlier in this
>     thread:
> 
>     https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5
> 
>     Given the arguments I mentioned above, I respectfully disagree with the
>     removal of the SID Structure Sub-Sub-TLV from the ISIS SRv6 draft.
> 
>     thanks,
>     Peter
> 
> 
>      >
>      > Thanks,
>      > Chris
>      >
>      > On Fri, Mar 13, 2020 at 5:02 AM Peter Psenak <ppsenak@cisco.com
>     <mailto:ppsenak@cisco.com>
>      > <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>> wrote:
>      >
>      >     Hi Chris,
>      >
>      >     On 12/03/2020 15:58, Chris Bowers wrote:
>      >      > Peter,
>      >      >
>      >      > I think that the SRv6 SID Structure Sub-Sub-TLV should be
>     removed
>      >     from
>      >      > draft-ietf-lsr-isis-srv6-extensions.  I think that we should
>      >     leave the
>      >      > ability to include sub-sub-TLVs in the SRv6 End SID Sub-TLV,
>      >     End.X SID
>      >      > Sub-TLV, and LAN End.X SID Sub-TLV in the encodings for those
>      >     sub-TLVs.
>      >      >
>      >      > I don't think that the current text describing the SRv6 SID
>      >     Structure
>      >      > Sub-Sub-TLV would result in interoperable
>     implementations.  Based
>      >     on the
>      >
>      >     SRv6 base spec defines SID B, L, A, F.
>      >
>      >     SRv6 protocol specs are advertising these values with the
>     SRv6 SID,
>      >     they
>      >     don't use them. The usage is outside of the scope of the protocol
>      >     drafts. What exactly is the problem?
>      >
>      >     thanks,
>      >     Peter
>      >
>      >
>      >      > discussion with Ketan below, it appears that use cases for
>     ISIS
>      >     speakers
>      >      > receiving advertised values of LB Length, LN Length, Fun.
>     Length,
>      >     and
>      >      > Arg. Length are not currently well-defined.    So I think it
>      >     makes sense
>      >      > to defer the definition of the SRv6 SID Structure
>     Sub-Sub-TLV to a
>      >      > future document.
>      >      >
>      >      > Thanks,
>      >      > Chris
>      >      >
>      >      > On Thu, Mar 12, 2020 at 6:02 AM Ketan Talaulikar (ketant)
>      >      > <ketant@cisco.com <mailto:ketant@cisco.com>
>     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>>
>      >     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>
>     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>>>> wrote:
>      >      >
>      >      >     Hi Chris,____
>      >      >
>      >      >     __ __
>      >      >
>      >      >     Dropping the
>     draft-ietf-spring-srv6-network-programming authors
>      >      >     since we are now back to discussing the ISIS
>     extensions.____
>      >      >
>      >      >     __ __
>      >      >
>      >      >     Please check inline below.____
>      >      >
>      >      >     __ __
>      >      >
>      >      >     *From:*Chris Bowers <chrisbowers.ietf@gmail.com
>     <mailto:chrisbowers.ietf@gmail.com>
>      >     <mailto:chrisbowers.ietf@gmail.com
>     <mailto:chrisbowers.ietf@gmail.com>>
>      >      >     <mailto:chrisbowers.ietf@gmail.com
>     <mailto:chrisbowers.ietf@gmail.com>
>      >     <mailto:chrisbowers.ietf@gmail.com
>     <mailto:chrisbowers.ietf@gmail.com>>>>
>      >      >     *Sent:* 05 March 2020 21:53
>      >      >     *To:* Ketan Talaulikar (ketant) <ketant@cisco.com
>     <mailto:ketant@cisco.com>
>      >     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>>
>      >      >     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>
>     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>>>>
>      >      >     *Cc:* Ketan Talaulikar (ketant) <ketant@cisco.com
>     <mailto:ketant@cisco.com>
>      >     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>>
>      >      >     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>
>     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>>>>;
>      > lsr@ietf.org <mailto:lsr@ietf.org> <mailto:lsr@ietf.org
>     <mailto:lsr@ietf.org>> <mailto:lsr@ietf.org <mailto:lsr@ietf.org>
>      >     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>;
>      >      >     SPRING WG List <spring@ietf.org
>     <mailto:spring@ietf.org> <mailto:spring@ietf.org
>     <mailto:spring@ietf.org>>
>      >     <mailto:spring@ietf.org <mailto:spring@ietf.org>
>     <mailto:spring@ietf.org <mailto:spring@ietf.org>>>>;
>      >      >     draft-ietf-spring-srv6-network-programming
>      >      >     <draft-ietf-spring-srv6-network-programming@ietf.org
>     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org>
>      >     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org
>     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org>>
>      >      >   
>       <mailto:draft-ietf-spring-srv6-network-programming@ietf.org
>     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org>
>      >     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org
>     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org>>>>; Peter
>      >      >     Psenak (ppsenak) <ppsenak@cisco.com
>     <mailto:ppsenak@cisco.com>
>      >     <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>
>     <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>
>      >     <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>>>;
>      >      >     Bruno Decraene <bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com>
>      >     <mailto:bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com>>
>      >      >     <mailto:bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com>
>      >     <mailto:bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com>>>>
>      >      >     *Subject:* Re: [Lsr] clarification of locator block and
>      >     locator node
>      >      >     in draft-ietf-spring-srv6-network-programming and
>      >      >     draft-ietf-lsr-isis-srv6-extensions____
>      >      >
>      >      >     __ __
>      >      >
>      >      >     Ketan,____
>      >      >
>      >      >     __ __
>      >      >
>      >      >     See inline [CB].____
>      >      >
>      >      >     __ __
>      >      >
>      >      >     On Wed, Mar 4, 2020 at 12:36 AM Ketan Talaulikar (ketant)
>      >      >     <ketant@cisco.com <mailto:ketant@cisco.com>
>     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>>
>      >     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>
>     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>>>> wrote:____
>      >      >
>      >      >         Hi Chris,____
>      >      >
>      >      >         ____
>      >      >
>      >      >         You are right in that there is no assumption that
>     all SRv6
>      >      >         locators in a domain are allocated from the same
>     block.
>      >      >         Therefore knowing the blocks used in the domain is
>      >     useful.____
>      >      >
>      >      >     ____
>      >      >
>      >      >     [CB] Since you refer to "blocks" (plural) in this
>     sentence,
>      >     are you
>      >      >     saying that in the scenario where all SRv6 locators in a
>      >     domain are
>      >      >     not allocated from the same block, you would expect
>     different
>      >      >     routers in the same domain to advertise different
>     values of B
>      >     and N?
>      >      >     ____
>      >      >
>      >      >     */[KT] While personally I believe it would not be the
>     usual
>      >     case, it
>      >      >     is left to the operator.____/*
>      >      >
>      >      >     */__ __/*
>      >      >
>      >      >     For example, assume we have a network where all SRv6
>     locators
>      >     in a
>      >      >     domain are not allocated from the same block.  Router A
>      >     advertises
>      >      >     an SRv6 Locator TLV with locator = 2000::/64, and an
>     SRv6 End SID
>      >      >     sub-TLV with some endpoint behavior. Router B
>     advertises an SRv6
>      >      >     Locator TLV with locator = 3000::/64, and an SRv6 End
>     SID sub-TLV
>      >      >     with some endpoint behavior. What should routers A and B
>      >     advertise
>      >      >     as the values of B and N in their SRv6 SID Structure
>      >     Sub-Sub-TLVs ?____
>      >      >
>      >      >     */[KT] It is difficult for me to figure out what the block
>      >     and node
>      >      >     parts are with such an addressing./*____
>      >      >
>      >      >     ____
>      >      >
>      >      >         ____
>      >      >
>      >      >         The IGP drafts covers the advertisement of the B and N
>      >     parts of
>      >      >         the locally configured locator on the node via
>     IGPs. On the
>      >      >         receiver side, the IGP may not really do much with
>     this
>      >      >         information, however it enables propagation of this
>      >     information
>      >      >         from all nodes in the network to be advertised out
>     via BGP-LS
>      >      >         (or other mechanisms) as part of the topology
>     feed. Once
>      >     this is
>      >      >         part of the topology feed, it enables use-cases on
>      >     controllers
>      >      >         to perform network wide validation of the SRv6 SID
>     block
>      >      >         provisioning and can also help in automation of
>     the security
>      >      >         aspects described in
>      >      >
>      >
>     https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5____
>      >      >
>      >      >         ____
>      >      >
>      >      >     [CB] If an ISIS speaker is not expected to do anything
>     with B
>      >     and N,
>      >      >     then I think the text in
>     draft-ietf-lsr-isis-srv6-extensions
>      >     needs
>      >      >     to clarify this.  I have a similar observation about Fun.
>      >     Length and
>      >      >     Arg. Length in the SRv6 SID Structure Sub-Sub-TLV . 
>     As far
>      >     as I can
>      >      >     tell, none of the endpoint behaviors that are currently
>      >     specified to
>      >      >     be carried in ISIS End, End.X, and LAN End.X SIDs sub-TLVs
>      >     uses an
>      >      >     Argument, so there is never a case where an SRv6 SID
>     Structure
>      >      >     Sub-Sub-TLV should have a non-zero value for Arg.
>     Length. What
>      >      >     should an ISIS speaker do if it receives a non-zero
>     value of the
>      >      >     Arg. Length for an endpoint behavior that doesn't use an
>      >     argument?
>      >      >     Are there any use cases envisioned where an ISIS
>     speaker needs to
>      >      >     know the Arg. Length ? ____
>      >      >
>      >      >     */[KT] The behaviors currently listed in the draft do
>     not have an
>      >      >     argument nor is the use of B and N required for them.
>     We cannot
>      >      >     preclude a future use-case or extension where such
>     behaviors
>      >      >     introduced are also applicable to ISIS. So IMHO ruling
>     such
>      >     aspects
>      >      >     out might not be the right thing to do from a protocol
>      >     extensibility
>      >      >     perspective.____/*
>      >      >
>      >      >     */__ __/*
>      >      >
>      >      >     */Thanks,____/*
>      >      >
>      >      >     */Ketan/*____
>      >      >
>      >      >     __ __
>      >      >
>      >      >         Thanks,____
>      >      >
>      >      >         Ketan____
>      >      >
>      >      >         ____
>      >      >
>      >      >         *From:*Chris Bowers <chrisbowers.ietf@gmail.com
>     <mailto:chrisbowers.ietf@gmail.com>
>      >     <mailto:chrisbowers.ietf@gmail.com
>     <mailto:chrisbowers.ietf@gmail.com>>
>      >      >         <mailto:chrisbowers.ietf@gmail.com
>     <mailto:chrisbowers.ietf@gmail.com>
>      >     <mailto:chrisbowers.ietf@gmail.com
>     <mailto:chrisbowers.ietf@gmail.com>>>>
>      >      >         *Sent:* 02 March 2020 23:39
>      >      >         *To:* Ketan Talaulikar (ketant) <ketant@cisco.com
>     <mailto:ketant@cisco.com>
>      >     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>>
>      >      >         <mailto:ketant@cisco.com <mailto:ketant@cisco.com>
>     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>>>>
>      >      >         *Cc:* Ketan Talaulikar (ketant)
>      >      >         <ketant=40cisco.com@dmarc.ietf.org
>     <mailto:40cisco.com@dmarc.ietf.org>
>      >     <mailto:40cisco.com@dmarc.ietf.org
>     <mailto:40cisco.com@dmarc.ietf.org>>
>      >      >         <mailto:40cisco..com@dmarc.ietf.org
>     <mailto:40cisco..com@dmarc.ietf.org>
>      >     <mailto:40cisco..com@dmarc.ietf.org
>     <mailto:40cisco..com@dmarc.ietf.org>>>>; lsr@ietf.org
>     <mailto:lsr@ietf.org>
>      >     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>
>      >      >         <mailto:lsr@ietf.org <mailto:lsr@ietf.org>
>     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>; SPRING WG
>      >     List <spring@ietf.org <mailto:spring@ietf.org>
>     <mailto:spring@ietf.org <mailto:spring@ietf.org>>
>      >      >         <mailto:spring@ietf.org <mailto:spring@ietf.org>
>     <mailto:spring@ietf.org <mailto:spring@ietf.org>>>>;
>      >      >         draft-ietf-spring-srv6-network-programming
>      >      >       
>       <draft-ietf-spring-srv6-network-programming@ietf.org
>     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org>
>      >     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org
>     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org>>
>      >      >
>      >       <mailto:draft-ietf-spring-srv6-network-programming@ietf.org
>     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org>
>      >     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org
>     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org>>>>;
>      >      >         Peter Psenak (ppsenak) <ppsenak@cisco.com
>     <mailto:ppsenak@cisco.com>
>      >     <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>
>      >      >         <mailto:ppsenak@cisco.com
>     <mailto:ppsenak@cisco.com> <mailto:ppsenak@cisco.com
>     <mailto:ppsenak@cisco.com>>>>;
>      >     Bruno Decraene
>      >      >         <bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com>
>      >     <mailto:bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com>>
>     <mailto:bruno.decraene@orange.com <mailto:bruno.decraene@orange.com>
>      >     <mailto:bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com>>>>
>      >      >         *Subject:* Re: [Lsr] clarification of locator
>     block and
>      >     locator
>      >      >         node in draft-ietf-spring-srv6-network-programming and
>      >      >         draft-ietf-lsr-isis-srv6-extensions____
>      >      >
>      >      >         ____
>      >      >
>      >      >         Ketan,____
>      >      >
>      >      >         ____
>      >      >
>      >      >         Based on current documents, allocating all SRv6
>     locators
>      >     used in
>      >      >         a domain from a single block is optional.____
>      >      >
>      >      >         ____
>      >      >
>      >      >         However, assuming for the moment that a network
>     operator has
>      >      >         chosen to allocate all SRv6 locators used in a
>     domain from a
>      >      >         single block, so that there is a well-defined
>     value of B
>      >     and N
>      >      >         across a domain, what is the use of having a
>     router advertise
>      >      >         its own understanding of these two values?  And
>     what is a
>      >      >         receiver supposed to do with this information?____
>      >      >
>      >      >         ____
>      >      >
>      >      >         Thanks,____
>      >      >
>      >      >         Chris____
>      >      >
>      >      >         ____
>      >      >
>      >      >         On Fri, Feb 28, 2020 at 8:23 AM
>      >     <bruno.decraene@orange.com <mailto:bruno.decraene@orange.com>
>     <mailto:bruno.decraene@orange.com <mailto:bruno.decraene@orange.com>>
>      >      >         <mailto:bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com>
>      >     <mailto:bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com>>>> wrote:____
>      >      >
>      >      >             Hi Ketan,____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Thanks fort the follow up.____
>      >      >
>      >      >             Clarification inline [Bruno]____
>      >      >
>      >      >             ____
>      >      >
>      >      >             *From**:*Ketan Talaulikar (ketant)
>      >     [mailto:ketant@cisco.com <mailto:ketant@cisco.com>
>     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>>
>      >      >             <mailto:ketant@cisco.com
>     <mailto:ketant@cisco.com> <mailto:ketant@cisco.com
>     <mailto:ketant@cisco.com>>>]
>      >      >             *Sent:* Friday, February 28, 2020 11:11 AM
>      >      >             *To:* DECRAENE Bruno TGI/OLN; Ketan Talaulikar
>     (ketant);
>      >      >             Chris Bowers
>      >      >             *Cc:* lsr@ietf.org <mailto:lsr@ietf.org>
>     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>
>      >     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>
>     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>; SPRING WG List;
>      >      >             draft-ietf-spring-srv6-network-programming;
>     Peter Psenak
>      >      >             (ppsenak)
>      >      >             *Subject:* RE: [Lsr] clarification of locator
>     block and
>      >      >             locator node in
>      >     draft-ietf-spring-srv6-network-programming
>      >      >             and draft-ietf-lsr-isis-srv6-extensions____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Hi Bruno,____
>      >      >
>      >      >             ____
>      >      >
>      >      >             I believe the description and usage of Locator is
>      >     very well
>      >      >             described and covered in the net-pgm draft as
>     also the
>      >      >             corresponding IGP extensions. Is the question
>     is more
>      >     about
>      >      >             the “block” part of it (what is not in the
>     block part
>      >     is in
>      >      >             the node part as per the text in the net-pgm
>     draft)?____
>      >      >
>      >      >             ____
>      >      >
>      >      >             The “block” is again not a new thing. Please
>     check the
>      >      >             following:____
>      >      >
>      >      >             Under
>      >      >
>      >
>     https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5
>      >      >             … look for “block”____
>      >      >
>      >      > https://tools.ietf.org/html/rfc8402#section-2 … look under
>      >      >             SRGB for SRv6____
>      >      >
>      >      >             ____
>      >      >
>      >      >             [Bruno]____
>      >      >
>      >      >             To clarify, my question was not specific to
>     “block” but
>      >      >             related to the usage, by the receiver, of the
>     following
>      >      >             piece of information:____
>      >      >
>      >      >             ____
>      >      >
>      >      >                    LB Length: SRv6 SID Locator Block
>     length____
>      >      >
>      >      >                    LN Length: SRv6 SID Locator Node length____
>      >      >
>      >      >                    Fun. Length: SRv6 SID Function length____
>      >      >
>      >      >                    Arg. Length: SRv6 SID Arguments length____
>      >      >
>      >      >             ____
>      >      >
>      >      >             ____
>      >      >
>      >      >             So perhaps I don’t get Chris’s point and would
>     wait
>      >     for him
>      >      >             to clarify.____
>      >      >
>      >      >             [Bruno] I’ll leave this to Chris.____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Thanks,____
>      >      >
>      >      >             Ketan____
>      >      >
>      >      >             ____
>      >      >
>      >      >             *From:*Lsr <lsr-bounces@ietf.org
>     <mailto:lsr-bounces@ietf.org>
>      >     <mailto:lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>>
>      >      >             <mailto:lsr-bounces@ietf.org
>     <mailto:lsr-bounces@ietf.org>
>      >     <mailto:lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>>>>
>     *On Behalf Of
>      >      >             *bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com>
>      >     <mailto:bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com>>
>     <mailto:bruno.decraene@orange.com <mailto:bruno.decraene@orange.com>
>      >     <mailto:bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com>>>
>      >      >             *Sent:* 28 February 2020 14:34
>      >      >             *To:* Ketan Talaulikar (ketant)
>      >      >             <ketant=40cisco.com@dmarc.ietf.org
>     <mailto:40cisco.com@dmarc.ietf.org>
>      >     <mailto:40cisco.com@dmarc.ietf.org
>     <mailto:40cisco.com@dmarc.ietf.org>>
>      >      >             <mailto:40cisco..com@dmarc.ietf.org
>     <mailto:40cisco..com@dmarc.ietf.org>
>      >     <mailto:40cisco..com@dmarc.ietf.org
>     <mailto:40cisco..com@dmarc.ietf.org>>>>; Chris Bowers
>      >      >             <chrisbowers.ietf@gmail.com
>     <mailto:chrisbowers.ietf@gmail.com>
>      >     <mailto:chrisbowers.ietf@gmail.com
>     <mailto:chrisbowers.ietf@gmail.com>>
>      >     <mailto:chrisbowers.ietf@gmail.com
>     <mailto:chrisbowers.ietf@gmail.com>
>     <mailto:chrisbowers.ietf@gmail.com
>     <mailto:chrisbowers.ietf@gmail.com>>>>
>      >      >             *Cc:* lsr@ietf.org <mailto:lsr@ietf.org>
>     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>
>      >     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>
>     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>; SPRING WG List
>      >      >             <spring@ietf.org <mailto:spring@ietf.org>
>     <mailto:spring@ietf.org <mailto:spring@ietf.org>>
>      >     <mailto:spring@ietf.org <mailto:spring@ietf.org>
>     <mailto:spring@ietf.org <mailto:spring@ietf.org>>>>;
>      >      >             draft-ietf-spring-srv6-network-programming
>      >      >           
>       <draft-ietf-spring-srv6-network-programming@ietf.org
>     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org>
>      >     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org
>     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org>>
>      >      >
>      >       <mailto:draft-ietf-spring-srv6-network-programming@ietf.org
>     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org>
>      >     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org
>     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org>>>>;
>      >      >             Peter Psenak (ppsenak) <ppsenak@cisco.com
>     <mailto:ppsenak@cisco.com>
>      >     <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>
>      >      >             <mailto:ppsenak@cisco.com
>     <mailto:ppsenak@cisco.com> <mailto:ppsenak@cisco.com
>     <mailto:ppsenak@cisco.com>>>>
>      >      >             *Subject:* Re: [Lsr] clarification of locator
>     block and
>      >      >             locator node in
>      >     draft-ietf-spring-srv6-network-programming
>      >      >             and draft-ietf-lsr-isis-srv6-extensions____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Hi Ketan,____
>      >      >
>      >      >             ____
>      >      >
>      >      >             ____
>      >      >
>      >      >             ____
>      >      >
>      >      >             *From:*Lsr [mailto:lsr-bounces@ietf.org
>     <mailto:lsr-bounces@ietf.org>
>      >     <mailto:lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>>]
>     *On Behalf Of
>      >      >             *Ketan Talaulikar (ketant)
>      >      >             *Sent:* Friday, February 28, 2020 6:30 AM____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Hi Chris,____
>      >      >
>      >      >             ____
>      >      >
>      >      >             I agree with Peter and I would suggest to drop
>     LSR since
>      >      >             this is not a protocol specific thing.____
>      >      >
>      >      >             ____
>      >      >
>      >      >             I believe the text in
>      >      >             draft-ietf-spring-srv6-network-programming clears
>      >     says what
>      >      >             locator block and locator node are. What more
>     details
>      >     do you
>      >      >             think are required?____
>      >      >
>      >      >             ____
>      >      >
>      >      >             [Bruno] Speaking as an individual, the draft could
>      >     possibly
>      >      >             clarify the usage of these information/fields
>     by the
>      >      >             receiver. Possibly using the same name/term (e.g.
>      >     SRv6 SID
>      >      >             Locator Block length) to ease the references
>     between both
>      >      >             drafts.____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Thanks,____
>      >      >
>      >      >             --Bruno____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Thanks,____
>      >      >
>      >      >             Ketan____
>      >      >
>      >      >             ____
>      >      >
>      >      >             *From:*Lsr <lsr-bounces@ietf.org
>     <mailto:lsr-bounces@ietf.org>
>      >     <mailto:lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>>
>      >      >             <mailto:lsr-bounces@ietf.org
>     <mailto:lsr-bounces@ietf.org>
>      >     <mailto:lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>>>>
>     *On Behalf Of *Chris Bowers
>      >      >             *Sent:* 27 February 2020 22:46
>      >      >             *To:* lsr@ietf.org <mailto:lsr@ietf.org>
>     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>
>      >     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>
>     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>; SPRING WG List
>      >      >             <spring@ietf.org <mailto:spring@ietf.org>
>     <mailto:spring@ietf.org <mailto:spring@ietf.org>>
>      >     <mailto:spring@ietf.org <mailto:spring@ietf.org>
>     <mailto:spring@ietf.org <mailto:spring@ietf.org>>>>
>      >      >             *Cc:* Peter Psenak (ppsenak)
>     <ppsenak@cisco.com <mailto:ppsenak@cisco.com>
>      >     <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>
>      >      >             <mailto:ppsenak@cisco.com
>     <mailto:ppsenak@cisco.com> <mailto:ppsenak@cisco.com
>     <mailto:ppsenak@cisco.com>>>>
>      >      >             *Subject:* [Lsr] clarification of locator
>     block and
>      >     locator
>      >      >             node in
>     draft-ietf-spring-srv6-network-programming and
>      >      >             draft-ietf-lsr-isis-srv6-extensions____
>      >      >
>      >      >             ____
>      >      >
>      >      >             SPRING and LSR WGs,____
>      >      >
>      >      >             ____
>      >      >
>      >      >             I think that we need a much more detailed
>     description
>      >     of the
>      >      >             locator block and locator node in either
>      >      >             draft-ietf-spring-srv6-network-programming or
>      >      >             draft-ietf-lsr-isis-srv6-extensions.  See
>     original email
>      >      >             below.____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Thanks,____
>      >      >
>      >      >             Chris____
>      >      >
>      >      >             ____
>      >      >
>      >      >             On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak
>      >      >             <ppsenak@cisco.com <mailto:ppsenak@cisco.com>
>     <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>
>      >     <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>
>     <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>>> wrote:____
>      >      >
>      >      >                 Hi Chris,
>      >      >
>      >      >                 On 27/02/2020 17:54, Chris Bowers wrote:
>      >      >                  > LSR WG,
>      >      >                  >
>      >      >                  > Section 9 of
>      >     draft-ietf-lsr-isis-srv6-extensions-05
>      >      >                 defines the  SRv6
>      >      >                  > SID Structure Sub-Sub-TLV. In
>     particular, it
>      >     defines
>      >      >                 encoding for the
>      >      >                  > locator block length and the locator
>     node length.
>      >      >                 The text refers to
>      >      >                  >
>     [I-D.ietf-spring-srv6-network-programming] for the
>      >      >                 definition of these
>      >      >                  > concepts.
>      >      >                  >
>      >      >                  > As far as I can tell, the only reference to
>      >     locator
>      >      >                 block and locator
>      >      >                  > node in
>      >     draft-ietf-spring-srv6-network-programming-10
>      >      >                 is section 3.1
>      >      >                  > which has the following text:
>      >      >                  >
>      >      >                  >     A locator may be represented as B:N
>     where B is
>      >      >                 the SRv6 SID block
>      >      >                  >     (IPv6 subnet allocated for SRv6
>     SIDs by the
>      >      >                 operator) and N is the
>      >      >                  >     identifier of the parent node
>      >     instantiating the
>      >      >                 SID...
>      >      >                  >
>      >      >                  > I think that we need a much more detailed
>      >     description
>      >      >                 of the locator
>      >      >                  > block and locator node.
>      >      >
>      >      >                 sure, but that would be in the
>      >      >               
>       draft-ietf-spring-srv6-network-programming-10, not in
>      >      >                 draft-ietf-lsr-isis-srv6-extensions, as
>     these are
>      >     not a
>      >      >                 protocol
>      >      >                 specific constructs.
>      >      >
>      >      >                 thanks,
>      >      >                 Peter
>      >      >
>      >      >                  >
>      >      >                  > Thanks,
>      >      >                  >
>      >      >                  > Chris
>      >      >                  > ____
>      >      >
>      >      >
>      >     
>       _____________________________________________________________________________________________________________________________
>      >      >
>      >      >             ____
>      >      >
>      >      >             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.____
>      >      >
>      >      >
>      >     
>       _____________________________________________________________________________________________________________________________
>      >      >
>      >      >             ____
>      >      >
>      >      >             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.____
>      >      >
>      >
>

v2.23.0 | Report a Bug | By Email