Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt

Igor Bryskin <i_bryskin@yahoo.com> Sun, 07 February 2021 18:58 UTC

Return-Path: <i_bryskin@yahoo.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27823A1214 for <teas@ietfa.amsl.com>; Sun, 7 Feb 2021 10:58:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 Yfe2bfuy_9DE for <teas@ietfa.amsl.com>; Sun, 7 Feb 2021 10:58:53 -0800 (PST)
Received: from sonic317-32.consmr.mail.ne1.yahoo.com (sonic317-32.consmr.mail.ne1.yahoo.com [66.163.184.43]) (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 34EE03A1213 for <teas@ietf.org>; Sun, 7 Feb 2021 10:58:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612724332; bh=TNzMT2jPVUz15iq48UvFO1sjN2//0DlXsgJY5ATc3Z0=; h=From:To:CC:Subject:Date:References:In-Reply-To:From:Subject:Reply-To; b=MUWfftGrW3Fp1s3BLu8p1s788TYH1sV2G+rLrLS4tknw623a+XOPUUbpUMpmhwtdHNG8UiSa/VAUy8EpmPOBi5cQWJU63HD8UcQwqrymaFw6JnfGsCVpH7VDP+y2Bb+BftDV5BlAO3awOr45K/xCs1/X6vyxK2/qmlrctstse+lXRYdzD6VaWVn51NrePbww70U0NcS8DDlwN0RcmSYQHzevv9NAmXcmokvxH9n9l9ccUi4rS1RF/3ieChAJ1V419lDTkUAR1n0+NAzLUAsDDG1qTqjsqAl7S+V+t++lrVI/hRFbmsfLtm8sZvt1NabCNUthgRb+mSDikoxbHcqldg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612724332; bh=u5YXA0tLyUOqNoPCUzm/tQ/7PvBwK/wIw+7uk9bJRe8=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=luq7I4EL2RzYtBVpG7DItYUTQT7/slN7bR7eyhLpR/TKiuYbc1d/cG9W8jAsUKPSIOVwFbRS6ykJCD3sjnnxvVk8AUD5p4zmfS4Hawx+Pd2oZmi/wCMtb6aNKPA+5JBInhDzefnWr8CrJThR8aqEecHXHAYFMGRESlXkyN/apOVNGSZ5HXPAjMOUr0OxjT6eYuFJg5ehYPB2X0GXFrYsxwRkgh/mwOGU15TFWd3niBnHsUJuLmvPUUvwq+t+DrUrx4+SlLxD6xM19QRUm4lbpYKWQwXfL7YSkAvdKA/+Pm/jkWycLBIRxkEN+SArfOTGvk1/S6JzzyDF7MnLoV7GJw==
X-YMail-OSG: FZ1tixAVM1mP79kLWo4kX0sPgZaonv54G5e_aEQEFB3.x2.2kgOudFmZpd8CiUG dp5ZXQxYjavVt6FTgXqZgHZSKY7Z7EhiN8i5Yc10in7fCdMtAPzxcgiiL_iWXsfhqi0Kk61yYoXw Ass3lSehzXmadIVncPkJQUgjYhBCWxgKEbL1MdfBLEiqChm9sbmjkCbSYs7reELVy_U6Q5GOfFV7 GsTnYXioB3SKh5aikeZfxFpR6QNy9VQa5XBFoREQJLX8Fo82xkwu13kBu4dn5bud21xiFyFVxiJO XgSgjK7WOyu7m2bVwVVSOO2zKvY3oZZXMc2bUHv1gIHdidD8S.bk.lGpFovL181JuEY09KFQF9O4 4UrhC1P5.8qCI0vzg1S3ZM.TVHysHP4n1Wtqwb8F6v8ecDm2Opmw05U18ZLNqH4f__.0bQ1f42kL BI9YHfLpNCQPFEOfYqCG5eHvsswWUOhkXB0IlPJjHMEQvpQKrbAt3hx9DENhb7EslcMfo9R6CWcx T_9rWWTwyPbf0sE8n5GmuDvnXs0iR.OLCroXpgCyDdMRuKvK7EcNm84Be7FnDa1yCIYSOwOIkF5K jvEsVdHVFpFayIGxbd2N7MaLMLH.gf9ooCPRbZAgh1_mf7QtL0hvyBki1zgalbFA2ylFbl2gTHlN XHGiWEFKHk5Kdmcd67uuZUbVnxwTyYH7KbmeAS8m1ssMkH4fnUorbEx7i7H62GjbrBji2NFV5RxU FIryWV8ZOu8Ipq9Fw3Grs2xX8OdMXvOevbozRzXyXkIa5Wozepj5MH0FjLwP259iP8YZxk0i8i96 k48IYsumDFQoiETmzXGYSVYIbPYPmGXI4JmUXdRsdxjh3YL_GAwMQYOu_8C_ANAbZBiCOna275HJ .EW4NhjCDPG4PEasBbMSwF_LYpoqceuofObgK1gjSY.Z7SiopRLO8OUyCQNBXQV7xH1PkyBJNZVb GDV879b2iX6BXhsRvyqL4r6LWvuxUFTnrkebRSd3rJojrRJmJ2khetx.tGYFE8pAS1YGaZdGM5fY q6m4LJcvJwCYifdorc6xpS.3dbTUm8bhKwNDKyDFblTWTeqm2pV6dMQJ4t6DrVn8gjUHiiSgdVha 5D6ToIH.vMg1rZpQFdQObrYvjxyO84W027XTm2uQ5inB3kVTIYBi3rKq2ahqztAgt2QGhEF0Wr8c GzvfkOTe.nZjn4dYjVvX6K.FYVtvAq3UszgKeDjrLOPCVDbhgRNW.RPMHO8vacdPvPrnB4644Pzo qTtUJj3FaXR6_lA8wbIRbxoXRTHfTq6_E9YQDSDfKaBPw5BTig5ASLW4vCLFwqO5DMrvxZLevUI8 .0HhCzcMhDB_6kUXczO_DnC0kxVtH3p1ciIS75DCWhqJ80QFv.3Dk5VxoBWOCJ4W.GQwQViMQ5yJ oHj8R8Kl85m_qoyPgJ.Xodm_jTWJ2Oy9L6R0zDJgc8GFA_aZOvC6nGkWCga.16HPdcX83KxkGxQm Q8iaZQSQm3cRugkTKAhMZMFtLCO2Ye9gmnTSiCtOz1.M89jYjgWQoFjhpJaYsX.SUdgvs6mMbpOg zzSP0aOn03lefMycm5CuMEPyqSqwiPdfSxkKpQwh04aE0m0kzbHOABOm36t4x3IGF0R.qfOfgK7P Z8.xD23TlzHAckKFdAm1UYW1DSpXFjitxdgTXgI.llIn1xW5TvG.gxXyXPDVNbbzGiaw.G6RBxKs J1z8TLmkZqKml3odZDbxBJFVOTBDe_1m28_6Yk0f0Zyni616Svlb7x50eCKeAYu0ACsG9aqmP9Ed 2_oNP1TondSMgVi4fJPKcX.0H5Z2uD1_z5fkJjueOeAWH3HzZf284DgXl99kJAq0bQml6mrhXmxc PbraiI_4JKICSHlX2d6AB4GHYj3zrCiCku59e1kzeuVqd4lmUhbkOPVWjESejKJ8Ywget7Rqy3xd nPt9TsbYqzPQwwDmXpHYM0i0fQpOc0PhwlO7rFZFypYLet3ITinIW.2GhvgGnV7JRvd4AxkNm4oH mpGwf59AkxNvHuEhGlMN7rk8eJ4iKKrBzgs67ZLosoxgu07wMWvJrCppxIaXgqbV3nSHtePfuM4h YHZm3kg0q1Cf991evH8V_a7WRFdNFe.byHz_GVqVfPGvo7ix8JAnCikK43frx61Fa4OFUuSSpj6o xPVp6M0nuFBKOQnoP_iCmku.Qa6.AEd0wsbvgvdVx0xemKZsA5sieUYVJYghgqfe46d7_Joy6elD 51Q7ErjoUk_xB50CBlE2OLFjbu6h3bJvemeaC6d8qKDxxHV1qSm4z0gK.uThEZJRwkYM3ztWrVwo QCP66h7b.XvVKLkZExnuyZJWrYYi3PmbOEhDQxIt_.7v8CQls7ya5E2pSaHKfx6yCyg2GHdoAnpT 7DL0ZcWQUYoSLLw1gHwznOZmvnzpyT89mWAEaLkIyBk7N2nD_6j0T3T04j8il6VLKpogIlnayT14 kvWoSxKTjOcX8qDa6Aw8xUFXfUvuUQ1ycPaXWNRq7WXTS9ou6DzGFm8nSc.rGAIRgXQnBGtNCfBy dCC82i00xVxx2KLg9ors84xUSTFJWbcscNmiPo48afg62PS6dfpP7PWUhK.GcUTo12_D9M2BWMf_ c2SfivCqko_r9gn2fFcY_zJ5Jq5v5HIbSOypow34bYDOZpEn1UJ8wkxQpARmZSleV_vIcLzwmgC. Ng86s8WNShqUs5Q_mMkqiAtVDRQwdO9OBB1NW0dmYribC2DiX0LkfTXch8p0dVUz70zdHRmMYbVp vlrRNPJea.a.xhnN97yjb6_XaH_8i1JV49xOWy4HKOaCuDnBQixpu6LXXzZGFvJlWP0chrkF22KD eTbYnsJlslvbjFkB0.yCSQZzZQxjxoTPKIDsy6ZVVNoCKzmsxybslDac.7l2OnQSgiU661.Q2TE0 j
X-Sonic-MF: <i_bryskin@yahoo.com>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Sun, 7 Feb 2021 18:58:52 +0000
Received: by smtp421.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ccee465716cc3f3bfaad2d93c6601b9f; Sun, 07 Feb 2021 18:58:51 +0000 (UTC)
From: Igor Bryskin <i_bryskin@yahoo.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
CC: Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org>, Gyan Mishra <hayabusagsm@gmail.com>, TEAS WG <teas@ietf.org>, "draft-bestbar-teas-ns-packet@ietf.org" <draft-bestbar-teas-ns-packet@ietf.org>
Thread-Topic: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt
Thread-Index: ATAyMzcwz1nVZ13L8uB/thznweqMNTNGMjQ3UVJUcWlRVFcxN8bm4pNmgAAyJgCAAB+cfA==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Sun, 7 Feb 2021 18:58:49 +0000
Message-ID: <BN6PR16MB1683185500A8DF1FDE745D6FA0B09@BN6PR16MB1683.namprd16.prod.outlook.com>
References: <160866255058.12375.3624366295025144530@ietfa.amsl.com> <B5853097-0690-45E9-9123-6F74FBCC4F03@juniper.net> <CABNhwV1u=iiK_2PQTKCquDbVwXanbTfB7U5GEzNRcgNY=iHhqQ@mail.gmail.com> <CA+YzgTvrk7bXDzyChjy1HORbAdb6XWLhaWpZP=gTbXUhTs3+3Q@mail.gmail.com> <BN6PR16MB1683FD38A7080E2BDAC114B0A0B09@BN6PR16MB1683.namprd16.prod.outlook.com>, <CA+YzgTuqj7W7=oz3M1m7Pys9P5xSPm9+QCA1WRPiYUoyBhbWDQ@mail.gmail.com>
In-Reply-To: <CA+YzgTuqj7W7=oz3M1m7Pys9P5xSPm9+QCA1WRPiYUoyBhbWDQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1683185500A8DF1FDE745D6FA0B09BN6PR16MB1683namp_"
MIME-Version: 1.0
X-Mailer: WebService/1.1.17648 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Apache-HttpAsyncClient/4.1.4 (Java/11.0.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/rhOthhFUa-77PgBf0EZl81zObUs>
Subject: Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Feb 2021 18:58:56 -0000

Pavan,

I assume:
- that a node, generally speaking, needs to make a forwarding decision based on the packet's slice topology;
- said topology may change dynamically, and so is the slice membership in the slice aggregate.
Therefore. It is better, in my opinion, to carry slice ID in packets and let nodes (re-)define slice aggregate membership independently.

Igor

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Teas <teas-bounces@ietf.org> on behalf of Vishnu Pavan Beeram <vishnupavan@gmail.com>
Sent: Sunday, February 7, 2021, 11:48 AM
To: Igor Bryskin
Cc: Tarek Saad; Gyan Mishra; TEAS WG; draft-bestbar-teas-ns-packet@ietf.org
Subject: Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt

Igor, Hi!

Please see inline.

Regards,
-Pavan (as a co-author)

On Sun, Feb 7, 2021 at 8:03 AM Igor Bryskin <i_bryskin@yahoo.com<mailto:i_bryskin@yahoo.com>> wrote:
Gyan and Pavan,

When a packet arrives at a node participating in a multi-slice network, the packet needs to be treated and *routed* according to the slice it belongs to. Because the physical data link over which the packet has arrived could be used by more than one slices, the packet needs to carry somewhere the slice ID. IMHO because the slice topology may dynamically change, it would be simpler and cleaner to carry the slice ID, rather than slice aggregate ID, as suggested by the draft.

[VPB] The packet needs to carry some identifier that would help determine the specific forwarding treatment (scheduling and drop policy) to be applied before the packet is forwarded further (this is not needed in the "Control Plane Slice Policy" mode). In the model that is proposed in the draft, we have one or more IETF Network Slices mapped onto a single slice aggregate and each slice aggregate has a specific Per Hop Behavior associated with it. In other words, the packet needs to carry an identifier that maps onto the slice aggregate. Also note that in the proposed model, multiple slice aggregates can map onto the same topology.


I also agree with Gyan that the COS field may not be the best choice for the task.

[VPB] I'm not sure what you mean by the COS field here.  If there is a need to allow differentiation of forwarding treatments for packets within a slice aggregate, the slice aggregate traffic may further carry a Diffserv Class Selector.


Regards,
Igor

Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> on behalf of Vishnu Pavan Beeram <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>
Sent: Thursday, February 4, 2021 3:49:37 PM
To: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Cc: Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>>; draft-bestbar-teas-ns-packet@ietf.org<mailto:draft-bestbar-teas-ns-packet@ietf.org> <draft-bestbar-teas-ns-packet@ietf.org<mailto:draft-bestbar-teas-ns-packet@ietf.org>>; TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Subject: Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt

Gyan, Hi!

Thanks for taking the time to review the document. Please see inline for responses (prefixed VPB).

Regards,
-Pavan (as a co-author)

On Wed, Feb 3, 2021 at 8:14 PM Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote:


Dear authors

I reviewed the draft and have some comments.

I noticed the draft  name and throughout the document it mentions Network Slice in IP/MPLS networks and wonder if it would be more appropriate to say network slice in SR/MPLS networks.  As NS involves traffic steering either RSVP-TE or SR steering my thoughts are it would be appropriate

[VPB] I’m not sure if I understood the comment. As you are aware, Segment Routing can be instantiated on MPLS or IPv6 dataplanes. The solution proposed in draft-bestbar-teas-ns-packet is intended for realizing network slicing in IP(v4/v6) / MPLS networks. The proposed solution works with any type of path control technology (e.g.RSVP-TE paths, SR paths, FlexAlgo paths). If you are interested in how the proposed solution works in SR deployments, please refer to draft-bestbar-spring-scalable-ns.


This drafts main focus it seems is an example of NS using QOS CS selector marking Differential service to be used for network slicing.


[VPB] Not really. The focus in this document is on the Slice Policy construct which includes rules that control the following slice aggregate attributes:
- Data plane policies (Slice Selectors, QOS profiles)
- Control plane policies (Guaranteed BW, Reservation priorities)
- Topology membership policies (Customized/Pre-defined)

There are 3 types of Slice Policy Modes depending on how/where the shared network resources are partitioned –
(1) Data Plane Slice Policy Mode
(2) Control Plane Slice Policy Mode
(3) Data and Control Plane Slice Policy Mode

In modes (1) and (3), a Slice Selector (SS) is carried in the packet to identify the slice aggregate and apply specific forwarding treatment (scheduling treatment and drop probability). But this is not needed in mode (2).

In my mind QOS is completely orthogonal to the concept of network slicing.  QOS involves shared resources and traffic classification and scheduling based on shared pipe resources which is completely orthogonal to network slicing which is a cross section of underlying resources involving a degree of isolation during provisioning to meet a customer  SLA.  QOS has been around for a long time and the big downside to QOS is that it is independent of underlying network resources.

When QOS PHB scheduling occurs based on CS AF or EF selector, packet are marked at the edge of trust boundary and PHB hop by hop scheduled matching dscp value providing bandwidth guarantees for profile traffic at or below the scheduling bandwidth which is based on the shared physical link.



[VPB] As noted above, it is certainly possible for a network slicing solution to be put together without requiring a specific per-hop-behavior to be applied on packets belonging to a slice aggregate (we refer to this as “Control Plane Slice Policy Mode” - Section 4.2 of draft-bestbar-teas-ns-packet-01). However, there are cases where the Slice service requires strict QOS guarantees and differentiation from other traffic – this is where the Data Plane Slice Policy Mode comes into play.

Kind Regards

Gyan


On Tue, Dec 22, 2020 at 1:59 PM Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:

Hi WG,



We have published a new revision of this draft (just in time for your holidays reading).

The changes include:

  *   additional co-authors have joined
  *   introduction of new terms “slice policy” and “slice aggregate”
  *   editorial nits to align with new terms introduced



As usual, reviews and comments are welcome.



Regards,

Tarek (on behalf of co-authors)





On 12/22/20, 1:42 PM, "internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>" <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> wrote:



    [External Email. Be cautious of content]





    A new version of I-D, draft-bestbar-teas-ns-packet-01.txt

    has been successfully submitted by Tarek Saad and posted to the

    IETF repository.



    Name:           draft-bestbar-teas-ns-packet

    Revision:       01

    Title:          Realizing Network Slices in IP/MPLS Networks

    Document date:  2020-12-22

    Group:          Individual Submission

    Pages:          27

    URL:            https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bestbar-teas-ns-packet-01.txt__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPzvuhQQRw$

    Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPwWnIEvoQ$

    Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPxBddbTdg$

    Htmlized:       https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bestbar-teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPznNKoLDg$

    Diff:           https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-bestbar-teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPzsN9oeaw$



    Abstract:

       Network slicing provides the ability to partition a physical network

       into multiple logical networks of varying sizes, structures, and

       functions so that each slice can be dedicated to specific services or

       customers.  Network slices need to operate in parallel while

       providing slice elasticity in terms of network resource allocation.

       The Differentiated Service (Diffserv) model allows for carrying

       multiple services on top of a single physical network by relying on

       compliant nodes to apply specific forwarding treatment (scheduling

       and drop policy) on to packets that carry the respective Diffserv

       code point.  This document proposes a solution based on the Diffserv

       model to realize network slicing in IP/MPLS networks.









    Please note that it may take a couple of minutes from the time of submission

    until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.



    The IETF Secretariat






Juniper Business Use Only

_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas