Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Robert Raszuk <robert@raszuk.net> Mon, 02 December 2019 09:49 UTC

Return-Path: <robert@raszuk.net>
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 D70BE1200E6 for <spring@ietfa.amsl.com>; Mon, 2 Dec 2019 01:49:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 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, HTTPS_HTTP_MISMATCH=0.1, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 8uh1OU2VUdUZ for <spring@ietfa.amsl.com>; Mon, 2 Dec 2019 01:49:43 -0800 (PST)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8E11200D7 for <spring@ietf.org>; Mon, 2 Dec 2019 01:49:42 -0800 (PST)
Received: by mail-qk1-x729.google.com with SMTP id c124so27489065qkg.0 for <spring@ietf.org>; Mon, 02 Dec 2019 01:49:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KxuiNkIBbzU+FuKfMCKC7PBN61R17o1iDCt6MpAlHqk=; b=TaYyzUxU9+Aa5Zm+ROijF2DokSSCjBZtB3vX0Hrv5hix3t51KHxDvfPIXUa9uWb6Wx d9pJKH/NnxLjBGlXobHEIkPP5pucxN7ds5sk3Jk4Rxudu5RXOb4oeevxcVI1vkfhKcV5 v5Trrl4brl4SBzdZAzhXKwEduJSaDLor+sfERx7qGAoASQPLFsm5bUJuWZCQB2GGQJKW NIP0MADuqd2/PBRcJBhvFG4VaPMUfsPYf7NoxpNcWExLbYlkzyoAru8nOfiY0CdSPH5a GjOwElS9LBIlWbu3O1rk37FF+4SiZnzAvrrupUUyZ/IOGcDPJNSbptfF7XKxDMWAzens Coqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KxuiNkIBbzU+FuKfMCKC7PBN61R17o1iDCt6MpAlHqk=; b=hxxRAiNaBSfntVqJ4yx+ERffHQz8uCwk7+LDDXH6hshz5RQ/sS0tH+eMHcKH+P6sK6 7PeIrZFEJqomqyqd6O2W2UL7Qk1boiXdRA+V+kaT0t+5UPmEuPArnaVliRoQ70bOJrBc Qub6cUgeoOdlWpm/IQ5YgHDP9uuItTzKuo/X92MVC4zf3104G495c2Qhy7KXn1jSXdu8 UPtTg9sBhGSRi8QNo3YLNWRaLDrXHa16WkFrdz6qR9vjOLfM2yYT4jB9wSKM7zCTWGY9 azk4X+gXyIJnS6oXcRxXw2XNMkQyUGr50IHENW1r9RS+DE0ZhDaGuxOdTYj3P6VNrI9F 63ug==
X-Gm-Message-State: APjAAAWrg/cwb1D/b91jC6QYBpGXtnKOxWy9hSf0FhIWD9NjWd3i6ALo qASHXEpZnh6vYm+r4zNVTJzOTcIXlJSGQTEjWMNYsA==
X-Google-Smtp-Source: APXvYqzzbfE5EXm8V2dsDLxcBmP37fLQeSe8ZNFe2AAA/RUuo9ZEuqSPwyAOAvd+NBS30K77xJ3H9dB3TLpGN+KZ3p0=
X-Received: by 2002:a37:62d2:: with SMTP id w201mr30470413qkb.445.1575280181381; Mon, 02 Dec 2019 01:49:41 -0800 (PST)
MIME-Version: 1.0
References: <BYAPR05MB394365C9E4719913BEC0809CD5490@BYAPR05MB3943.namprd05.prod.outlook.com> <CAOj+MMFOueodpR-06AN47aND6_9WJAwPaXMTaP-0nzd0HCVzKA@mail.gmail.com> <AM0PR03MB382893DAFDE830D24EE7FAD49D480@AM0PR03MB3828.eurprd03.prod.outlook.com> <CAOj+MMFzrMBTbQbRXrnN0HTNm=uH+HF_LGggVZ3WUtAzGQSNgQ@mail.gmail.com> <VI1PR03MB383986D0D2E66226BFDEDF839D480@VI1PR03MB3839.eurprd03.prod.outlook.com> <AM0PR03MB3828FD21B1D69E3CB74F3AE49D480@AM0PR03MB3828.eurprd03.prod.outlook.com> <BYAPR05MB3943CE8749F824CDDA88F3C8D5430@BYAPR05MB3943.namprd05.prod.outlook.com> <AM0PR03MB3828F1161645C155DA569F099D430@AM0PR03MB3828.eurprd03.prod.outlook.com> <BYAPR05MB394390FE9BEAC8D0CA71DECED5430@BYAPR05MB3943.namprd05.prod.outlook.com> <DBBPR03MB5415486F24D2C9B6338611BEEE430@DBBPR03MB5415.eurprd03.prod.outlook.com>
In-Reply-To: <DBBPR03MB5415486F24D2C9B6338611BEEE430@DBBPR03MB5415.eurprd03.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 2 Dec 2019 10:49:31 +0100
Message-ID: <CAOj+MME2EM52zF8j0N6+8kYpkPz2AN2JP0uMP4JYZcxOgXqGcw@mail.gmail.com>
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Cc: Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "spring@ietf.org" <spring@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a223b50598b57f1c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/pYDPUB87HKbdRvR0J1_joUt-Uvc>
Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths
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, 02 Dec 2019 09:49:46 -0000

On Mon, Dec 2, 2019 at 10:28 AM Andrew Alston <
Andrew.Alston@liquidtelecom.com> wrote:

Currently the biggest issue that I see with S-BFD based protection – which
> is something we use in production is as follows:
>
>
>
> Unless I’m mistaken – there is absolutely no way to tie S-BFD based
> protection with BGP injected SR-TE pathing
>


Well I am not sure what you call " BGP injected SR-TE pathing" but if you
are looking for validation of BGP paths that has been supported by some
vendors for a loooong time. Hint: you allocate different next hop for your
SR-TE endpoints and voila.

Btw - not an ietf topic, but an implementation request / vendor's feature.

Besides, since you are talking about headend what you are describing is
path protection ... this draft talks about node protection which is a
completely different thing.

Cheers,
r.



> Node validation as defined in the SR-TE drafts is limited to presence in
> the IGP
>
> Since SR-TE path injection may be done through reflectors – using target
> communities – the point of communication into the network is not
> necessarily the head end of the tunnel and the point of injection may be
> entirely unaware of the implications of the path that’s being inserted.
>
>
>
> By utilizing what is contained in this draft to build context tables at
> the head end of an inserted tunnel on an automated basis – this solves a
> problem that currently exists that S-BFD simply cannot solve without
> modification to the srte policy insertion drafts that would allow for
> automated building of S-BFD checks – which in and of itself could prove
> challenging considering the complexity of this.
>
>
>
> That is not to say in any way that both s-bfd and potentially other
> mechanisms do not have use cases – but as an operator – this draft would
> certainly provide a better mechanism for constant path validation than
> anything we currently have (which is based on steered packets that leave
> the controller and return to the controller through the use of SR packets
> and binding sids).
>
>
>
> Just my 2c
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Shraddha Hegde
> *Sent:* Monday, 2 December 2019 10:24
> *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> *Cc:* spring@ietf.org; rtg-bfd@ietf.org; Robert Raszuk <robert@raszuk.net>et>;
> rtgwg@ietf.org
> *Subject:* Re: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> Sasha,
>
>
>
> We are in agreement on separating the trigger from the protection
> mechanism.
>
>
>
> > In any case I think that it woyld make sense to separate the protection
> scheme proposed in the draft from specific triggers for its activation
> >similar to how this has been done in MPLS Egress Protection Framework
> draft.
>
>
>
> I’ll add text in the next revision for this.
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> *From:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> *Sent:* Monday, December 2, 2019 12:24 PM
> *To:* Shraddha Hegde <shraddha@juniper.net>
> *Cc:* spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org; Robert Raszuk <
> robert@raszuk.net>
> *Subject:* Re: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> Shraddha,
>
> Lots of thanks for athe tesponse.
>
>
>
> I probably did not express myself clearly enough. I will try to fix thst
> now, and I apologise in advance for a long email.
>
>
>
> I have not been speaking about end-yo-end protecyion, only about local
> protection against failure of an intermediate (a.k.a. pinned) node of an SR
> path and, specifically, triggers for such protection. This context has been
> actually defined by Robert in his original comment.
>
>
>
> To the best of my understanding, Robert's concern was that failure of the
> link beteeen the pinned node of a SR path and its adjacency (the
> penultimate node of the Segment represented by the Node SID of the pinned
> node) is not a good enough indication of the pinned node failure.
>
>
>
> I agree with this statement even if my understanding of a good indication
> differs from Robert's:
>
> - I think that it is not sufficiently specific and therefore could result
> in flapping (local node protection activated and then released)
>
> -Robert's concern, to the best of my understanding, was that it could miss
> some failures (e.g. the Fabric failure).
>
>
>
> Therefore I have suggested two possibilities for more specific and more
> rrliabke detection of failure of the pinned node by its adjacency:
>
>
>
> 1. Run a multi-hop IP BFD session between the peniltimate node ans the
> pinned ones using prefixes acting as Node SIDs of this pair.  This wiuld
> ignore link failures but locally detect such node failurs as power-down or
> crash.
>
>
>
> 2.  Run S-BFD sessions to all other adjacencies of the pinned node using
> in each case a list of two SIDs: the protected Adj-SID to the pinned node
> followed by tge Node SID of the other adjacency, ans declare pinned node
> failure when all these sessions fail. This would again ignore failure of
> the link between the penultimate node and the pinned node but detect
> various real failures of the pinned node, e.g. failure of its Fabric.
>
>
>
> In any case I think that it woyld make sense to separate the protection
> scheme proposed in the draft from specific triggers for its activation
> similar to how this has been done in MPLS Egress Protection Framework draft.
>
>
>
> My 2c.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Get Outlook for Android
> <https://urldefense.com/v3/__https:/aka.ms/ghei36__;!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH6GPZiIH$>
>
>
> ------------------------------
>
> *From:* Shraddha Hegde <shraddha@juniper.net>
> *Sent:* Monday, December 2, 2019, 06:10
> *To:* Alexander Vainshtein; Robert Raszuk
> *Cc:* spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org
> *Subject:* RE: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> Robert/Sasha,
>
>
>
>
>
> S-BFD based mechanism is  head-end triggered protection. It is not a local
> protection.
>
> S-BFD mechanism is orthogonal to the mechanism described in this draft and
> an operator can
>
> choose what kind of protection makes more sense to his/her network.
>
>
>
> In many cases, node-protecting backup path will be different from
> link-protecting/SRLG protecting backup path.
>
> If you really want to use link-protecting backup path when link fails and
> node protecting backup path when node fails,
>
> You will have to download both link protecting and node-protecting backup
> paths in FIB and detect which
>
> failure really happened and have the ability in hardware to use
> appropriate backup path. None of these
>
> is in the scope of this document.
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> *From:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> *Sent:* Saturday, November 23, 2019 8:15 PM
> *To:* Robert Raszuk <robert@raszuk.net>et>; Shraddha Hegde <
> shraddha@juniper.net>
> *Cc:* spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org
> *Subject:* Re: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> Robert,
>
> On the second thought, for the purpose of this draft (i.e. in the scope of
> SR) it is possible to implement your suggestion by running S-BFD sessions
> between R7 (as the initiator) and each other adjacency of R8  (acting as
> Reflectors) of a SR policy with list of two SIDs:
>
> - protected adjacency between R7 and R8
>
> - Node SID of the specific "other" adjacency  of R8.
>
>
>
> If all these sessions fail, R7 can reliably consider R8 as failed.
>
>
>
> I am not sure this would be much better than multi-hop IP BFD, and it
> looks much more complicated to me.
>
>
>
>
>
> What do you think?
>
>
>
>
>
>
>
>
>
> Get Outlook for Android
> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3MR8y7CviGLkS3kzg1UybRv6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Faka.ms*2Fghei36__*3B*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgnYBhAbc*24__;JSUlJSUlJSUlJSUl!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH1YVygZC$>
>
>
> ------------------------------
>
> *From:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> *Sent:* Saturday, November 23, 2019, 13:15
> *To:* Robert Raszuk; Shraddha Hegde
> *Cc:* spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org
> *Subject:* Re: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> Robert,
>
> Lots of thanks for a prompt response.
>
>
>
> I respectfully disagree with your statement that BFD implementation  is
> usually offloaded to the HW of the ingress line card.  I do not think this
> can wor for MH BFD sessions because the ingress and egress line cards are
> not known in advance and change with the routing changes
>
> A good  multi-hop BFD implementation should be ready to overcome this..
> There are many ways to achieve that. A naive implementation that runs in SW
> of the control card is also possible of course. And they would sensd and
> receive packets
>
>
>
> My 2c.
>
> Get Outlook for Android
> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3MR8y7CviGLkS3kzg1UybRv6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Faka.ms*2Fghei36__*3B*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgnYBhAbc*24__;JSUlJSUlJSUlJSUl!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH1YVygZC$>
>
>
> ------------------------------
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Saturday, November 23, 2019, 12:37
> *To:* Alexander Vainshtein; Shraddha Hegde
> *Cc:* spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org
> *Subject:* Re: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> Hi Sasha,
>
>
>
> On the surface your suggestion may look cool - but if you zoom in - I do
> not think it will work in practice.
>
>
>
> See - one of the biggest value of BFD is its offload to line card's
> hardware. And in most cases it is ingress line card to the box. So if you
> instruct such hardware to respond to SID address loopback you still did not
> gain much in terms of detection router's fabric failures, remote LC failure
> or control plane issues which could soon result in box failure. The
> catalogue of router failures is of course much more colorful.
>
>
>
> If you ask BFD to be responded by RP/RE it no longer has the BFD
> advantage.
>
>
>
> IMHO the best way to detect node failure is actually to send the probes
> *across* the node under test to its peers.
>
>
>
> The way I would think of establishing such m-hop sessions would be fully
> automated with one knob per IGP adj. ex: "bfd detect-node-failure [max N]"
> where local BFD subsystem would create N sessions to IGP peers of the node
> we are to protect. LSDB has those peers so no new protocol extension is
> needed, perhaps even no new IETF draft is required :). N would be the limit
> of such sessions in case the node under protection has say 10s of peers.
> Default could be perhaps even 1.
>
>
>
> Thx,
>
> Robert.
>
>
>
>
>
> On Sat, Nov 23, 2019 at 10:00 AM Alexander Vainshtein <
> Alexander.Vainshtein@ecitele.com> wrote:
>
> Shraddha, Robert and all,
>
> Regarding Robert's question:
>
> I wonder if multi-hop IP BFD session with addresses used as /32 (or /128)
> prefixes serving as Nose SIDs of R8 and R7 respectively could be used as
> such a trigger by R7? Such a session would not respond to link failures,
> and I find it problematic to imagine a scenario when it would be kept UP in
> the case of a real node failure.
>
>
>
> Of course such a session would have to be slow enough not to react to link
> failures. But it still couks be much faster than IGP conversion IMHO.
>
>
>
> My 2c,
>
> Sasha
>
>
>
> Such
>
>
>
>
>
> Get Outlook for Android
> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3NbK72q2ca668aVyMaT7Esn6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3CfVQPtBYBAPbHUSngEVNQD6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Faka.ms*2A2Fghei36__*3BJSUlJQ*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0Vmgujy50EN*24__;JSUlJSUlJSUlJSUlJSUlJSUl!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH7q73pAh$>
>
>
> ------------------------------
>
> *From:* spring <spring-bounces@ietf.org> on behalf of Robert Raszuk <
> robert@raszuk.net>
> *Sent:* Friday, November 22, 2019, 11:22
> *To:* Shraddha Hegde
> *Cc:* spring@ietf.org; rtgwg@ietf.org
> *Subject:* Re: [spring] Draft for Node protection of intermediate nodes
> in SR Paths
>
>
>
> Hi Shraddha,
>
>
>
> I have one question to the document.
>
>
>
> As you know the critical element for the effective protection of any
> scheme is the failure detection. On that your draft seems to have just one
> little paragraph:
>
>
>
>    Note that R7 activates the node-protecting backup path when it
>
>    detects that the link to R8 has failed.  R7 does not know that node
>
>    R8 has actually failed.  However, the node-protecting backup path is
>
>    computed assuming that the failure of the link to R8 implies that R8
>
>    has failed.
>
>
>
> Well IMO this is not enough. Specifically there can be a lot of types of
> node failure when link is still up. Moreover there can be even running BFD
> across the link just fine when say fabric failure occurs at R8.
>
>
>
> While this is not solely issue with this draft, it is our common IETF
> failure to provide correct means of detecting end to end path or fragments
> of path failures (I am specifically not calling them segment here :).
>
>
>
> For example I propose that to effectively detect R8 failure as node
> failure which is the topic of your proposal a mechanism is clearly defined
> and includes bi-dir data plane probes send between R7-R9, R3-R7, R4-R7,
> R4-R9, R3-R9
>
>
>
> Many thx,
>
> Robert.
>
>
>
>
>
> On Fri, Nov 22, 2019 at 4:38 AM Shraddha Hegde <shraddha=
> 40juniper.net@dmarc.ietf..org <40juniper.net@dmarc.ietf.org>> wrote:
>
> WG,
>
>
>
> This is the draft I pointed out that talks about solutions for providing
> node-protection.
>
> It covers Anycast case as well as keeping forwarding plane longer.
>
>
> https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-05
> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3HvrzHXwAou2JruETj6jcyF6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F375SW6TBGPi2mN7V9YeVWGg6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Ftools.ietf.org*2A2Fhtml*2A2Fdraft-hegde-spring-node-protection-for-sr-te-paths-05__*3BJSUlJSU*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0Vmgg0xmj_C*24__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH9RfbOqT$>
>
>
>
> Review and comments solicited.
>
>
>
> Rgds
>
> Shraddha
>
>
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
> <https://urldefense.com/v3/__https:/clicktime.symantec.com/37ZvNSMSAddpxDGDQPm7oVA6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F35M9j5zHTaSYRwVh5RP6xcB6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Fwww.ietf.org*2A2Fmailman*2A2Flistinfo*2A2Frtgwg__*3BJSUlJSUl*218WoA6RjC81c*21Xo-D7e5MfUeTOyV17KUflgSI002KCmsw_EjxLc9pxA6sJ1EbrioDE0VmgvV9Y4sM*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!QAhYaA0qhoUZ3yxQWl05Ap12CMR-J-RTL_O_d_wKElC5ktZrPekfTDhLH_pG5Prx$>
>
>
>
>
>
>
> ___________________________________________________________________________
>
> This e-mail message is intended for the recipient only and contains
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
> received this
> transmission in error, please inform us by e-mail, phone or fax, and then
> delete the original
> and all copies thereof.
> ___________________________________________________________________________
>
>
>
>
> ___________________________________________________________________________
>
> This e-mail message is intended for the recipient only and contains
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
> received this
> transmission in error, please inform us by e-mail, phone or fax, and then
> delete the original
> and all copies thereof.
> ___________________________________________________________________________
>