Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Gyan Mishra <hayabusagsm@gmail.com> Mon, 16 November 2020 14:00 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5044F3A1009; Mon, 16 Nov 2020 06:00:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ll6Ebu3vHmYu; Mon, 16 Nov 2020 06:00:23 -0800 (PST)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 A54993A1007; Mon, 16 Nov 2020 06:00:23 -0800 (PST)
Received: by mail-pl1-x62d.google.com with SMTP id 35so4266483ple.12; Mon, 16 Nov 2020 06:00:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sO2icbvAC7Wiks+7G1/4DEHP9LcuXhaitXH9u6uJ5O4=; b=YtbnY/WH4Lg0Rr500pt8zorHvDjTuwg7K2xYq7bFrHT78Tn5FFk0C4ExcYUgMuEhrr RaYjdiRuEvq4nlV0jWl/Joe55jZ3YIcN0D9h0kAuq21xm+xaaKGN7R9wKifl7269U/Ku u9RAnJHxMPA5cK/4RW5y31l9uoy9+DondNsTtRk6JEeXMfPwM9xq5nXmsPKefyRtK7Z+ w7uZdD8iBiEWw8qfySEZu2lQMvG1CxCGHQCjKiE7xylrwA2AP/GEWoT4m3GFM8/AXah7 qwWAvNTV7SrlRI9R35j30fqHzfMd9pVShnVDwlF87Qqza2WMI+Or8qm502Xc0SIB22ct x6VQ==
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=sO2icbvAC7Wiks+7G1/4DEHP9LcuXhaitXH9u6uJ5O4=; b=L9ApW7nJ59xyOAFmPovPLh1JbuMHkNk/CSkqnEFeNmAx8DUBV/aQyABs7RS8zBJscE s0bgk6Q7V2x/2eJb09+ogNNMuKxuOC5kQD2zti4JphidwQVRbz+AqzxM8U7sLoU1EHHd roehu14kuSR8y4DBT9K9OlsTEpcxx6U2nu6KpW6b4dBypogU32z6/A2CJHK98UdncOL+ zbmYqEGkl+Pmf8QV/UttNz0cneELvGXmLYhdZpcKTgG5gp7p2pbBJihyTlwziap6Avc2 HfsrNoAx4wHTb9jO0Xl2zcb14nmMKBG8mSvyDOjF8r8h+w5G+oKgTA5NtQoDP6jbv6vn d+0g==
X-Gm-Message-State: AOAM532Fk7JrkEKiYCcsu5cqvdYPnEM8IQkRC21JqOSSvkQR4uexata8 Ke27BiiJwkWbi1BvWjPXyR5cxgpXxUvml/6WCPA=
X-Google-Smtp-Source: ABdhPJx48mtk31YqAbidVPIaUl8WJOvqgirdX+H5fGfGZXJaT7TOgbPKGMgX6+EmlL4x55fDcSczfmT/Ac2hy2Lf0Es=
X-Received: by 2002:a17:902:6a84:b029:d8:c8a9:e04d with SMTP id n4-20020a1709026a84b02900d8c8a9e04dmr13481987plk.74.1605535221474; Mon, 16 Nov 2020 06:00:21 -0800 (PST)
MIME-Version: 1.0
References: <MW3PR11MB4570CD7427F273656C5BCD9AC1E30@MW3PR11MB4570.namprd11.prod.outlook.com> <F774E667-40EF-4440-BBCB-B5032FB9DBA6@gmail.com>
In-Reply-To: <F774E667-40EF-4440-BBCB-B5032FB9DBA6@gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 16 Nov 2020 09:00:09 -0500
Message-ID: <CABNhwV2KweVenaB_XzDvaNeZ3v3OmCfPhW46CQ-dfUjjf_sr6Q@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "Stephane Litkowski (slitkows)" <slitkows@cisco.com>, Susan Hares <shares@ndzh.com>, idr@ietf.org, lsr@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008cea0305b439cc96"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/mD9AjftOMoMSKpuffjGgwVys-jU>
Subject: Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2020 14:00:27 -0000

 I support WG adoption and agree Ketan’s doc is good start.

On Mon, Nov 16, 2020 at 5:38 AM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> Sue,
>
> Ketan’s draft would be a great starting point.
>
> Regards,
> Jeff
>
> On Nov 16, 2020, at 00:04, Ketan Talaulikar (ketant) <ketant@cisco.com>
> wrote:
>
> 
>
> Hi Sue,
>
>
>
> I was referring to
> https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/
>
>
>
> Seeing the interest in the WG to progress BGP-LS advertisements in
> BGP-only networks, I would request for the WG to consider adoption of the
> above draft. I believe the problem statement of the draft is clear and
> acknowledge that it needs updates. So I will leave it to the chairs’
> judgement if it is in a good enough state for adoption 😊
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Susan Hares <shares@ndzh.com>
> *Sent:* 16 November 2020 11:40
> *To:* 'Jeff Tantsura' <jefftant.ietf@gmail.com>om>; Les Ginsberg (ginsberg) <
> ginsberg@cisco.com>
> *Cc:* Ketan Talaulikar (ketant) <ketant@cisco.com>om>; Stephane Litkowski
> (slitkows) <slitkows@cisco.com>om>; idr@ietf.org; Acee Lindem (acee) <
> acee@cisco.com>gt;; lsr@ietf.org
> *Subject:* RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> Jeff:
>
>
>
> I agree your BGP-LS only deployment in the MSD document were not well
> defined.
>
>
>
> Starting a new set of work to define BGP-LS use in BGP-only is important.
> If this document start the process to refine how BGP-only works, this will
> help defined this usage.   I stand by the agreement that the BGP-LS that
> exposes the OSPF/ISIS Link MTU proposal can be adopted in LSR.  However,
> this discussion has confirmed that the BGP-LS support for BGP-only needs
> some BGP focus.
>
>
>
> If there are other drafts on this topic, it would be good to suggest this
> drafts on the list.   Ketan suggested he had one.
>
>
>
> Cheers, Sue
>
>
>
>
>
> *From:* Jeff Tantsura [mailto:jefftant.ietf@gmail.com
> <jefftant.ietf@gmail.com>]
> *Sent:* Friday, November 13, 2020 8:52 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Ketan Talaulikar (ketant); Susan Hares; Stephane Litkowski
> (slitkows); idr@ietf.org; Acee Lindem (acee); lsr@ietf.org
> *Subject:* Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> To add to Les’s point of BGP only scenario, during MSD IESG reviews,
> BGP-LS only deployment was found not well characterized and had been
> removed from the draft. It will require much better discussion to have it
> included.
>
> Regards,
>
> Jeff
>
>
>
> On Nov 13, 2020, at 15:57, Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> wrote:
>
> 
>
> The points which Ketan has made regarding the use of MTU advertisements
> defined in RFC 7176 are very valid. Indeed, the contents of the sub-TLV
> defined in https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend
> upon the TRILL specific MTU-probe/MTU-ack procedures defined in
> https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures
> are not currently applicable to non-TRILL environments.
>
>
>
> So, there are no existing IGP advertisements defined which can support the
> goals of this draft.
>
>
>
> As Ketan has also indicated, there is no discussion in the draft of how a
> BGP only network (for example) could provide the information of interest.
>
>
>
> From my perspective, WG adoption of this draft in ANY WG is premature.
>
> This might be a useful functionality to have – but at the moment we simply
> have an idea with no definition of how to implement/deploy it.
>
>
>
> So I therefore oppose WG adoption of this draft by IDR.
>
>
>
> Continuing the discussion is certainly useful – and I would encourage the
> current authors to investigate and propose relevant mechanisms in all the
> protocols of interest in some future version of the draft.
>
> At that point we could then have a far more meaningful WG adoption call.
>
>
>
>    Les
>
>
>
>
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of *Ketan Talaulikar
> (ketant)
> *Sent:* Friday, November 13, 2020 1:35 AM
> *To:* Susan Hares <shares@ndzh.com>om>; 'Jeff Tantsura' <
> jefftant.ietf@gmail.com>gt;; 'Stephane Litkowski (slitkows)' <
> slitkows=40cisco.com@dmarc.ietf.org>gt;; idr@ietf.org; 'Acee Lindem (acee)' <
> acee=40cisco.com@dmarc.ietf.org>
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> Hi Authors,
>
>
>
> I believe this work is useful and should be taken up. It has value in
> providing the link MTU as part of the topology information via BGP-LS.
> However, as pointed out by others on this thread, the draft should remain
> scoped to just that – i.e. providing link MTU information. The discussion
> related to Path MTU and applicability to SR networks are best left outside
> the scope of this standards track draft.
>
>
>
> Hi Sue,
>
>
>
> I would support the points made by Acee for not taking up this draft in
> IDR WG and instead doing this in LSR.
>
>
>
> Besides the missing coverage for OSPFv2/v3, there are also issues with how
> this would work with ISIS. The reference to the ISIS Trill specification
> points to this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if
> you see, there is more here than just the MTU value. What is more critical
> is the ISIS procedures (in non-Trill deployments) on how this value is
> determined. Please do not mix the following :
>
>
>
> The MTU sub-TLV is used to optionally announce the MTU of a link as
>
>    specified in [RFC6325], Section 4.2.4.4
> <https://tools.ietf.org/html/rfc6325#section-4.2.4.4>.
>
>
>
> Are the authors trying to specify that these Trill procedures for testing
> MTU need to be adopted for regular ISIS deployments.
>
>
>
> My take is that while the ISIS TLV defined for Trill may be re-used in
> normal ISIS deployments, its usage and procedures need to be specified.
> Copying the LSR WG so that I may be corrected if I am wrong here.
>
>
>
> Coming to the point of BGP-only networks, the draft has zero text related
> to that scenario. Moreover, the procedures for BGP-LS advertisements in BGP
> only fabric need to be specified as a base. The
> https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/
> was my attempt to specify those procedures and it would be great if the IDR
> WG could review and provide feedback to this document and consider for
> adoption so we can cover the BGP-only networks.
>
>
>
> I would also like to offer support/help to the authors in adding the
> necessary OSPFv2/v3 support for the same in an LSR draft where we could
> tackle both the IGPs and BGP-LS encoding and procedures together.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of *Susan Hares
> *Sent:* 13 November 2020 00:20
> *To:* 'Jeff Tantsura' <jefftant.ietf@gmail.com>om>; 'Stephane Litkowski
> (slitkows)' <slitkows=40cisco.com@dmarc.ietf.org>rg>; idr@ietf.org; 'Acee
> Lindem (acee)' <acee=40cisco.com@dmarc.ietf.org>
> *Subject:* Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> Jeff and Authors of draft-zhu-idr-bgp-ls-path-mtu:
>
>
>
> I do believe the authors agreed to renaming the draft.
>
>
>
> Does the name:   draft-xxx-idr-bgp-ls-link-mtu work for
>
> the authors and interested IDR participants.
>
>
>
> As the end of 12 days of the 14 day WG LC, this draft appears
>
> to have general consensus from the WG as a useful draft.
>
>
>
> I plan to allow 2 more days of comment, but at this point
>
> it appears the WG wishes to adopt this draft.
>
>
>
> Here’s my understanding of the best way forward:
>
>
>
> If LSR adopts a version of the draft, IDR will allow the
>
> LSR WG to be the main source as long as cross-working
>
> review occurs so the BGP-only function can be reviewed.
>
>
>
> Please continue to comment on the draft and
>
> the planned progression.
>
>
>
> Cheers,  Sue
>
>
>
> *From:* Jeff Tantsura [mailto:jefftant.ietf@gmail.com
> <jefftant.ietf@gmail.com>]
> *Sent:* Thursday, November 12, 2020 12:53 PM
> *To:* Susan Hares; Stephane Litkowski (slitkows); idr@ietf.org; Acee
> Lindem (acee)
> *Subject:* Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> +1 to everything Acee said
>
>
>
> Cheers,
>
> Jeff
>
> On Nov 10, 2020, 1:01 PM -0800, Acee Lindem (acee) <
> acee=40cisco.com@dmarc.ietf.org>gt;, wrote:
>
> Speaking as an IDR WG member:
>
>
>
> The name of the draft is wrong – the extension is for a Link MTU and not a
> path MTU.
>
>
>
> Speaking as LSR Chair:
>
>
>
> We could this in LSR as there is currently no MTU advertisement in the
> LSAs for OSPFv2 and OSPFv3. Implementations already make use of this
> information as it is used in the OSPF DBD packets and for LSA packing. Of
> course, we’d require a more accurate draft name and title.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From:* Idr <idr-bounces@ietf.org> on behalf of Susan Hares <
> shares@ndzh.com>
> *Date:* Monday, November 9, 2020 at 4:20 PM
> *To:* "'Stephane Litkowski (slitkows)'" <
> slitkows=40cisco.com@dmarc.ietf.org>gt;, IDR List <idr@ietf.org>
> *Subject:* Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> Stephane:
>
>
>
> My second message to this thread asked a few questions about the
> technology.
>
>
>
> This information can be more than IGP information.   If SR segments
> statically defined (static or direct interfaces) tunnels and pass the
> endpoints via BGP tunnel-encaps draft with SR Policy tunnel type, this can
> just be BGP.
>
>
>
> I’ll keep this WG adoption call going until we can be sure if:  1) it
> something LSR wants to standardize, and 2) whether there is a BGP only
> case.   It is clear to me that standardizing MTU for a SR segments with
> stacked tunnel segments passed by BGP was useful.
>
>
>
> The authors should be the ones to propose this in LSR.
>
>
>
> Cheers,  Sue
>
>
>
> *From:* Idr [mailto:idr-bounces@ietf.org <idr-bounces@ietf.org>] *On
> Behalf Of* Stephane Litkowski (slitkows)
> *Sent:* Monday, November 9, 2020 4:28 AM
> *To:* Susan Hares; idr@ietf.org
> *Subject:* Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> Hi Sue,
>
>
>
> > The purpose behind this mechanism is to reduce administrative work
> rather than to reduce the review on drafts.
>
>
>
> That’s exactly my point. If we don’t do OSPF extension now and in the same
> draft, we leave a gap that will require a new draft for a very very small
> extension. Just adds process overhead for nothing…
>
>
>
>
>
> Stephane
>
>
>
>
>
> *From:* Susan Hares <shares@ndzh.com>
> *Sent:* lundi 9 novembre 2020 10:10
> *To:* Stephane Litkowski (slitkows) <slitkows@cisco.com>om>; idr@ietf.org
> *Subject:* RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> Stephane:
>
>
>
> I want to pick up on your email from two points:
>
>
>
> 1)  Why not do everything in LSR?
>
> <WG-chair hat>
>
> If the feature comes with interest in doing all 3 (ISIS, OSPF, and BGP-LS
> data gathering), then the authors may select to do everything in LSR rather
> than have 2 or 3 drafts to maintain.
>
>
>
> This is optional and the mechanism may not fit every draft.   The drafts
> may also start out adopted and vetted in LSR and IDR.    The purpose behind
> this mechanism is to reduce administrative work rather than to reduce the
> review on drafts.
>
>
>
> </wg-chair hat off>
>
>
>
>
>
> 2) TRILL implementations of IS-IS has some MTU subTLV -
>
>
>
> If you are interested in whether this has been implemented in TRILL, you
> might want to check with Donald Eastlake.   My vague and foggy recollection
> is that had some implementations or came from pre-TRILL implementations.
>
>
>
>
>
> Cheers, Susan Hares
>
>
>
>
>
>
>
> *From:* Stephane Litkowski (slitkows) [mailto:slitkows@cisco.com
> <slitkows@cisco.com>]
> *Sent:* Wednesday, November 4, 2020 3:03 AM
> *To:* Susan Hares; idr@ietf.org
> *Subject:* RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> Hi,
>
>
>
> “a) Are there ways to pass IGP link MTUs in
>
> the IGPs?  If so, is this needed in BGP-LS”
>
>
>
> This is a valid point, most of the time BGP-LS is feeded by IGP LSDBs (of
> course there are other ways too). While I see that IS-IS has some MTU
> subTLV coming from TRILL RFC7176 (possibly never been implemented), I don’t
> see anything for OSPF (I’m not an OSPF expert, so I may have missed it).
>
> Shouldn’t this be checked and validated with LSR WG before adopting ?
>
>
>
>
>
> Stephane
>
>
>
>
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of* Susan Hares
> *Sent:* lundi 2 novembre 2020 06:04
> *To:* idr@ietf.org
> *Subject:* [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020
> to 11/16/2020)
>
>
>
> This begins a 2 week WG adoption call for
>
> draft-zhu-idr-bgp-ls-path-mtu-04.txt (11/1 – 11/16/2020).
>
>
>
> The authors should send in an IPR statement for this draft
>
> by 11/5 so the WG can include the IPR status in their decision.
>
>
>
> You can access the draft at:
>
> https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/
>
>
>
> Since this draft is reference by an existing IDR draft
>
> I’ve included a bit of background below to help you place
>
> this draft into the larger context of the SR additions to BGP-LS
>
> and the draft-ietf-idr-tunnel-encaps-19.txt.
>
>
>
> This draft does continue BGP-LS additions.  if you
>
> are opposed to any BGP-LS additions rather than
>
> this specific addition, please make that clear in your
>
> comment in this discussion.
>
>
>
> The authors requested a WG adoption at IETF 108.
>
> The IDR co-chairs thank the authors for their patience.
>
> This draft has been delayed by process of having a
>
> new document shepherd (Sue Hares) come up to speed
>
> on draft-ietf-idr-tunnel-encapsulation.
>
>
>
> Cheers, Sue
>
>
>
> Background
>
> ===========
>
> Segment Routing technology creates SR tunnels that are
>
> directly overlaid on MPLS or SRv6.  While existing MPLS technology
>
> (LDP and RSV-TE) provides mechanisms to negotiate path MTU
>
> based on individual link MTU limits, the Segment Routing (SR)
>
> on BGP-LS Link Attribute does not pass information on
>
> MTU size per link.
>
>
>
> draft-ietf-idr-sr-policy-path-mtu-02.txt sends PATH MTU
>
> information in the tunnel-encapsulation attribute for the tunnel type
>
> SR-Policy that handles segment routing (SR) paths.
>
> However, it lacks the information to create a reasonable
>
> Path size since the BGP-LS Link Attribute does distribute
>
> this information.
>
>
>
> The draft proposes adding a new sub-TLV for MTU size
>
> to the BGP-LS Link Attribute TLV, and
>
> draft-ietf-idr-sr-policy-path-mtu-02.txt mentions this
>
> draft as one possible way to distribute the per link
>
> MTU.
>
>
>
> Questions for the authors might be:
>
> a) Are there ways to pass IGP link MTUs in
>
> the IGPs?  If so, is this needed in BGP-LS
>
>
>
> b) What other mechanisms pass link MTU?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD