Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6071B2E3C for ; Sat, 26 Sep 2015 07:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 zkJkzn61pFHE for ; Sat, 26 Sep 2015 07:24:09 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137911B2E38 for ; Sat, 26 Sep 2015 07:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50117; q=dns/txt; s=iport; t=1443277448; x=1444487048; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=W+muRsKeoPjHnxnVxuHQvkFXIGF3lvknwN/dulHRw2k=; b=OuRdjjPYZmqhA/vSUV+/uXpJstG8FMR/VpKOkJuFPBwIOcMYl6tEys6y msd5h8HlWrRLgeYu4DaoPFdV1kW466v/YogaRM++xTSl6cIuqNlVwah8j GA1OBnlxdB5xxUh4MnGdHpuQhOrbrYj9oddlzTiUdXarRleC6zqDPLKPr k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AYAgChqQZW/49dJa1dgldNVGkGhS64CAENgXuEIIFZAoEfOBQBAQEBAQEBgQqEJAEBAQQnBj4ODAIEAQgRAwEBASEBBiIGERQJCAIEAQ0FiBkDEg3GSg2FDAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEBIpmgQaCUIFRCRACASQBBxMNBAcGhCYFhzEDhnuHQQGFFIYKgXCBT4Q2jHh8g1mDbAEfAQFCghEcgVRxh1kCBRkHHIEFAQEB X-IronPort-AV: E=Sophos; i="5.17,592,1437436800"; d="scan'208,217"; a="30396174" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP; 26 Sep 2015 14:24:07 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t8QEO7HQ029722 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 26 Sep 2015 14:24:07 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 26 Sep 2015 09:24:06 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.000; Sat, 26 Sep 2015 09:24:06 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "Dutta, Pranjal K (Pranjal)" , "Loa Andersson" , Curtis Villamizar , "vishwas.manral@gmail.com" , Lizhong Jin , "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping Thread-Index: AQHQ6uZThyQvT/8dOEmUFCIze73HOJ5OavkAgACd6gA= Date: Sat, 26 Sep 2015 14:24:06 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.223.145] Content-Type: multipart/alternative; boundary="_000_D22C229D81CEFnaikumarciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 14:24:13 -0000 --_000_D22C229D81CEFnaikumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Pranjal, Thanks for the review and comments. We will address the same and will updat= e back. Thanks, Nagendra From: , "Pranjal K (Pranjal)" > Date: Friday, September 25, 2015 at 8:58 PM To: Loa Andersson >, Curtis Villamizar >, "vishwas.manral@gmail.com" >, Lizhong Jin >, "dra= ft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" >, = "mpls-chairs@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping Resent-From: > Resent-To: >, > Resent-Date: Friday, September 25, 2015 at 8:58 PM Hi, I have been asked by the WG chairs for MPLS-RT review on this draft. I= have reviewed the version https://tools.ietf.org/html/draft-kumarkini-mpl= s-spring-lsp-ping-04 and following are my review comments. 1. Section 4.1 on the problem definition: This section falls short of = discussing various critical fault scenarios in detail. For example, following is an important case. +--------+ | L2 | R3-------R6 / \ / \ R1----R2 R7----R8 \ / \ / R4-------R5 9136 --> Adjacency Segment ID from R3 to R6 over link L1. 9236 --> Adjacency Segment ID from R3 to R6 over link L2. 9124 --> Adjacency segment ID from R2 to R4. 9123 --> Adjacency Segment ID from R2 to R3. 9145 --> Adjacency Segment ID from R4 to R5. 9157 --> Adjacency segment ID from R5 to R7. 9178 --> Adjacency segment ID from R7 to R8. 9167 --> Adjacency segment ID from R6 to R7. Let's say R1 originates a packet with the following label stack: 9123 + 9136 + 9167 + 9178 + Payload R2 pops Adjacency Segment ID 9123 and forwards the packet to the correct= next-hop link R2-R3. But R2 is malfunctioning such that it also pops 9136. Thus R3 receives the Adjacency Segment ID 9167. By quirk of fate Label/9= 167 =3D label/9236 because both labels are locally significant to advertisi= ng nodes. As a result, R3 forwards the packet to R6 over link L2. R6 receives 9178= and drops the packet after finding no state programmed for 9178. The packe= t traverses the intended path till R6 whereas the problem is at R2. Similarly, instead of POPPing unwanted labels the malfunctioning node co= uld PUSH unwanted labels. Such issues may not be due to wrong programming b= y control plane (or data plane out of sync) and can happen due to a few bit flips on faulty h/w o= r memory. 2. Sections 5.1 and 5.2: the target FEC stack TLV for a prefix SID MUS= T include the SID index value and not just the address to be sure this gets= checked for overlaps or errors of assigning the SID index value. 3. Section 6: The DSMAP should not be supported with SR and SR-TE LSP.= The DDMAP is required because of the hierarchical nature of the LSP. See n= ext comment for more details. 4. Section 7.1: I think what is missing upfront in the document is the= modeling in MPLS OAM of a SR or SR-TE LSP. Basically, it should be modeled= as a hierarchical LSP which MUST use the DDMAP TLV with the FEC Stack Chan= ge sub-TLV to operate correctly. The following operations are supported: a. A node/prefix SID label that is swapped at an LSR results in the n= ormal return code of 8 "Label switched at stack-depth " as per RFC 43= 79. b. A node/prefix SID label which is popped at an LSR results in a FEC = stack change TLV operation of =93POP=94 as per RFC 6424. c. An adjacency SID label popped at an LSR results in a FEC stack cha= nge TLV operation of =93POP=94 as per RFC 6424. In other words, we are mode= ling the swap operation into a implicit NULL label as a POP to simplify the= tracing operation with DDMAP. 5. Section 7.1: The text under paragraph titled =93Traceroute=94 is ve= ry ambiguous and confusing and it may suggest that new behavior is being de= scribed. In fact, there is nothing new to add here and the behavior of the = FEC stack change sub-TLV is as per RFC 6424. All what is needed is a clear = description of the modeling of the SR/SR-TE LSP as per comment above. For example, let's apply the procedures in this section to the fault scen= ario I had discussed in comment 1). 5.1. R1 initiates Echo Request with TTL=3D1 carrying Targeted FEC stack 9= 123 + 9136 + 9167 + 9178. From the procedures it is not clear whether R1 w= ould send DSMAP/DDMAP TLV containing the Label stack. IMO, it MUST send Label stack - withou= t it R2 can't validate if received data plane label stack is same as in rec= eived DSMAP/DDMAP (see later in 5.5). 5.2 R2 responds with Echo reply containing FEC stack change/pop for 9123= . 5.3. R1 initiates Echo Request with TTL=3D2 carrying Targeted FEC stack 9= 136 + 9167 + 9178 and DSMAP/DDMAP containing corresponding label stack 9136 + 9167 + 9178. The data plane label stack is 9123 + 9136 + 9167= + 9178. 5.4. The malfunctioning node R2 forwards the packet to R3 with data-plane= label stack 9167 + 9178. 5.5. R3 validates from received Targeted FEC stack that 9136 is the indee= d an advertised Adjacency ID and corresponding label in DSMAP/DDMAP is corr= ect. However the label stack received in data plane does not correspond to the label stack in = DSMAP - this is a key point and there is no mention of it in the draft. Thu= s R3 responds with label_stack_validation failure which indicates a data plane fault in R2. 6. Section 7.2: the popping of the adjacency SID label is performed by= the node which assigned it and it is this node which generates the FEC sta= ck change sub-TLV with the operation of POP. 7. Section 7.3: while I agree that the implicit NULL label value for t= he adjacency SID should not be used because the downstream LSR has no conte= xt for the adjacency SID of his upstream neighbor (adjacency SIDs are local= ly significant only) but for node SID with PHP, the downstream node has con= text and actually signaled PHP flag in the prefix SID sub-TLV. Implicit-Nul= l value is thus valid for node SID. 8. Section 7.4: This section needs to be written to cover the cases of= regular swapping of node/prefix SID and the popping of node SID or adjacen= cy SID when receiving the FEC stack change sub-TLV. Also, what is exactly = =93Best return code to 10=94? 9. Section 7.5: I do not think this section belongs here. If there are= recommendations for TTL setting for hierarchical LSPs, they sure are not s= pecific to SR/SR-TE LSP. 10. In Section 5 =93Three new sub-TLVs are defined for TLVs type 1, 16 and 21.=94 It is not clear what is meant by TLVs type 1,16 and 21. Suggest to make exp= licit references. 11. One missing point in MPLS-OAM so far is to let the originator of a Trac= eroute know that responding node is currently exercising FRR backup next-ho= p (because primary has failed). AFAIK, this is not covered in any MPLS OAM extensions so far. It is go= od to address this in SR context. Summary ------------- 1) Whether the document is coherent - Yes 2) is it useful (i.e, is it likely to be actually useful in operational net= works) - Yes 3) Is the document technically sound? - Need precise modeling of MPLS-OAM of a SR/SR-TE LSP. Need to precisely = describe procedures in the context of SR/SR-TE LSP and applicability of RF= C 4379, 6424. 4) Whether the document is ready to be considered for WG adoption - It is a good start but I would like to see the concerns addressed befor= e publishing the WG draft. Thanks, Pranjal -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Wednesday, September 09, 2015 3:00 AM To: Curtis Villamizar; vishwas.manral@gmail.com; Dutta, Pranjal K (Pranjal); Lizhong Jin; draft-kumarkini-mpls-spring= -lsp-ping@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: Fwd: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping Resending, Vishwas mail bounced and forgot to include the authors and my co= -chairs. /Loa Curtis, Vishwas, Pranjal, and Lizhong, You have be selected as MPLS-RT reviewers for draft-kumarkini- mpls-spring-= lsp-ping. Note to authors: You have been CC'd on this email so that you can know that= this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (i= e, is it likely to be actually useful in operational networks), and is the = document technically sound? We are interested in knowing whether the document is ready to be considered= for WG adoption (ie, it doesn't have to be perfect at this point, but shou= ld be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secreta= ry, and CC'd to the MPLS WG email list. If necessary, comments may be sent = privately to only the WG chairs. If you have technical comments you should try to be explicit about what nee= ds to be resolved before adopting it as a working group document, and what = can wait until the document is a working group document and the working gro= up has the revision control. Are you able to review this draft by September 25, 2015? Please respond in = a timely fashion. Thanks, Loa (as MPLS WG chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 --_000_D22C229D81CEFnaikumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Pranjal,

Thanks for the review and comments. We will address the same and will = update back.

Thanks,
Nagendra

From: <Dutta>, "Pranjal = K (Pranjal)" <p= ranjal.dutta@alcatel-lucent.com>
Date: Friday, September 25, 2015 at= 8:58 PM
To: Loa Andersson <loa@pi.nu>, Curtis Villamizar <curtis@occnc.com>, "vishwas.manral@gmail.com" <vishwas.manral@gmail.com>, Lizhong Jin <lizho.jin@gmail.com= >, "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" &= lt;d= raft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org>, "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>
Cc: "mpls@ietf.org" <mpls@i= etf.org>
Subject: RE: MPLS-RT review of draf= t-kumarkini-mpls-spring-lsp-ping
Resent-From: <pranjal.dutta@alcatel-lucent.com><= br> Resent-To: <draft-kumarkini-mpls-spring-ls= p-ping@ietf.org>, <mpls-c= hairs@ietf.org>
Resent-Date: Friday, September 25, = 2015 at 8:58 PM

Hi,

     I have been asked by the WG chairs for MPLS-RT review on = this draft. I have reviewed the version  https://tools.ietf.org/h= tml/draft-kumarkini-mpls-spring-lsp-ping-04 and following are my review comments.

 

1.= &n= bsp;     Section 4.1 on the problem definition: This= section falls short of discussing various critical fault scenarios in deta= il.

 

For example, following is an important case.

 

 

        &= nbsp;         +--------+

        &= nbsp;         |   L2 = ;  |

        &= nbsp;         R3-------R6

        &= nbsp;        /    &n= bsp;      \

        &= nbsp;       /     &n= bsp;       \

        R1----= R2            &= nbsp;  R7----R8

         =        \     &n= bsp;       /

        &= nbsp;        \    &n= bsp;      /

        &= nbsp;         R4-------R5

 

    9136 --> Adjacency Segment = ID from R3 to R6 over link L1.

    9236 --> Adjacency Segment = ID from R3 to R6 over link L2.

    9124 --> Adjacency segment = ID from R2 to R4.

    9123 --> Adjacency Segment = ID from R2 to R3.

    9145 --> Adjacency Segment = ID from R4 to R5.

    9157 --> Adjacency segment = ID from R5 to R7.

    9178 --> Adjacency segment = ID from R7 to R8.

    9167 --> Adjacency segment = ID from R6 to R7.

 

Let's say R1 originates a packet with the following = label stack:

 

   9123 + 9136 + 9167 + 9178 &= #43; Payload

 

   R2 pops Adjacency Segment ID 9123 and f= orwards the packet to the correct next-hop link R2-R3. But R2 is malfunctio= ning such that it also pops 9136.

   Thus R3 receives the Adjacency Seg= ment ID 9167. By quirk of fate Label/9167 =3D label/9236 because both label= s are locally significant to advertising nodes.   

   As a result, R3 forwards the packe= t to R6 over link L2. R6 receives 9178 and drops the packet after finding n= o state programmed for 9178. The packet

   traverses the intended path till R= 6 whereas the problem is at R2.

 

   Similarly, instead of POPPing unwanted = labels the malfunctioning node could PUSH unwanted labels. Such issues may = not be due to wrong programming by control plane (or data
   plane out of sync) and can happen due to a few bit flips = on faulty h/w or memory.

 

2.= &n= bsp;     Sections 5.1 and 5.2: the target FEC stack = TLV for a prefix SID MUST include the SID index value and not just the addr= ess to be sure this gets checked for overlaps or errors of assigning the SID index value.

 <= /p>

3.= &n= bsp;     Section 6: The DSMAP should not be supporte= d with SR and SR-TE LSP. The DDMAP is required because of the hierarchical = nature of the LSP. See next comment for more details.

 <= /p>

4.= &n= bsp;     Section 7.1: I think what is missing upfron= t in the document is the modeling in MPLS OAM of a SR or SR-TE LSP. Basical= ly, it should be modeled as a hierarchical LSP which MUST use the DDMAP TLV with the FEC Stack Change sub-TLV to oper= ate correctly. The following operations are supported:

 <= /p>

a.= &n= bsp;      A node/prefix SID label that is swapped at = an LSR results in the normal return code of 8  "Label switched at= stack-depth <RSC>" as per RFC 4379.

b.= &n= bsp;     A node/prefix SID label which is popped at = an LSR results in a FEC stack change TLV operation of =93POP=94 as per RFC = 6424.

c.= &n= bsp;      An adjacency SID label popped at an LSR res= ults in a FEC stack change TLV operation of =93POP=94 as per RFC 6424. In o= ther words, we are modeling the swap operation into a implicit NULL label as a POP to simplify the tracing operation with= DDMAP.

 =

5.= &n= bsp;     Section 7.1: The text under paragraph title= d =93Traceroute=94 is very ambiguous and confusing and it may suggest that = new behavior is being described. In fact, there is nothing new to add here and the behavior of the FEC stack change = sub-TLV is as per RFC 6424. All what is needed is a clear description of th= e modeling of the SR/SR-TE LSP as per comment above.

 

  For example, let's apply the procedures in this section to the fault scenar= io I had discussed in comment 1).

 

  5.1. R1 initiates Echo Request with TTL=3D1 c= arrying Targeted FEC stack 9123 + 9136 + 9167 + 9178. From the = procedures it is not clear  whether R1 would send DSMAP/DDMAP TLV
         containing the Label = stack. IMO, it MUST send Label stack - without it R2 can't validate if rece= ived data plane label stack is same as in received DSMAP/DDMAP (see later i= n 5.5).

 

  5.2  R2 responds with Echo reply contain= ing FEC stack change/pop for 9123.

    

  5.3. R1 initiates Echo Request with TTL= =3D2 carrying Targeted FEC stack 9136 + 9167 + 9178 and DSMAP/DDMAP= containing corresponding label stack

       9136 += 9167 + 9178. The data plane label stack is 9123 + 9136 + 9167 = + 9178.

    

  5.4. The malfunctioning node R2 forwards= the packet to R3 with data-plane label stack 9167 + 9178.

 

  5.5. R3 validates from received Targeted FEC = stack that 9136 is the indeed an advertised Adjacency ID and corresponding = label in DSMAP/DDMAP is correct. However the label stack
          received in dat= a plane does not correspond to the label stack in DSMAP - this is a key poi= nt and there is no mention of it in the draft. Thus R3 responds with label_= stack_validation
         failure which indicat= es a data plane fault in R2.  

 <= /p>

6.= &n= bsp;     Section 7.2: the popping of the adjacency S= ID label is performed by the node which assigned it and it is this node whi= ch generates the FEC stack change sub-TLV with the operation of POP.

 <= /p>

7.= &n= bsp;     Section 7.3: while I agree that the implici= t NULL label value for the adjacency SID should not be used because the dow= nstream LSR has no context for the adjacency SID of his upstream neighbor (adjacency SIDs are locally signifi= cant only) but for node SID with PHP, the downstream node has context and a= ctually signaled PHP flag in the prefix SID sub-TLV. Implicit-Null value is= thus valid for node SID.

 

8.= &n= bsp;     Section 7.4: This section needs to be writt= en to cover the cases of regular swapping of node/prefix SID and the poppin= g of node SID or adjacency SID when receiving the FEC stack change sub-TLV. Also, what is exactly =93Best retu= rn code to 10=94?

 

9.= &n= bsp;     Section 7.5: I do not think this section be= longs here. If there are recommendations for TTL setting for hierarchical L= SPs, they sure are not specific to SR/SR-TE LSP.

 

 

10= .&= nbsp; In Section 5

 

=93Three new sub-TLVs are defined for TLVs type 1, 1= 6 and 21.=94

It is not clear what is meant by TLVs type 1,16 and = 21. Suggest to make explicit references.

 

11. One missing point in MPLS-OAM so far is to let t= he originator of a Traceroute know that responding node is currently exerci= sing FRR backup next-hop (because primary has failed).
     AFAIK, this is not covered in any MPLS OAM ex= tensions so far. It is good to address this in SR context.

 

Summary

-------------

 

1) Whether the document is coherent

  - Yes

 

2) is it useful (i.e, is it likely to be actually us= eful in operational networks)

 

  - Yes

 

3) Is the document technically sound?

 

  - Need precise modeling of MPLS-OAM of a SR/S= R-TE LSP. Need to precisely describe procedures in the context of  SR/= SR-TE LSP and applicability of RFC 4379, 6424.

 

4) Whether the document is ready to be considered fo= r WG adoption

  - It is a good start but I would like to= see the concerns addressed before publishing the WG draft.

 

Thanks,

Pranjal

 

 

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.nu] Sent: Wednesday, September 09, 2015 3:00 AM
To: Curtis Villamizar; vishwas.= manral@gmail.com; Dutta, Pranjal K (Pranjal); Lizhong Jin; draf= t-kumarkini-mpls-spring-lsp-ping@tools.ietf.org; mpls-chairs@tools.ietf.org
Subject: Fwd: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping

 

Resending, Vishwas mail bounced and forgot to inc= lude the authors and my co-chairs.

 

/Loa

 

Curtis, Vishwas, Pranjal, and Lizhong,=

 

You have be selected as MPLS-RT reviewers for dra= ft-kumarkini- mpls-spring-lsp-ping.

 

Note to authors: You have been CC'd on this email= so that you can know that this review is going on. However, please do not = review your own document.

 

Reviews should comment on whether the document is= coherent, is it useful (ie, is it likely to be actually useful in operatio= nal networks), and is the document technically sound?

 

We are interested in knowing whether the document= is ready to be considered for WG adoption (ie, it doesn't have to be perfe= ct at this point, but should be a good start).

 

Reviews should be sent to the document authors, W= G co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necess= ary, comments may be sent privately to only the WG chairs.

 

If you have technical comments you should try to = be explicit about what needs to be resolved before adopting it as a working= group document, and what can wait until the document is a working group do= cument and the working group has the revision control.

 

Are you able to review this draft by September 25= , 2015? Please respond in a timely fashion.

 

Thanks, Loa

(as MPLS WG chair)

 

 

 

--

 

 

Loa Andersson      =             &nb= sp;     email: loa@mail01.huawei.com=

Senior MPLS Expert     &= nbsp;           &nbs= p;        loa@pi.nu<= o:p>

Huawei Technologies (consultant)   = ;  phone: +46 739 81 21 64

 

--

 

 

Loa Andersson      =             &nb= sp;     email: loa@mail01.huawei.com=

Senior MPLS Expert     &= nbsp;           &nbs= p;        loa@pi.nu<= o:p>

Huawei Technologies (consultant)   = ;  phone: +46 739 81 21 64

 

 

 --_000_D22C229D81CEFnaikumarciscocom_--