From stbryant@cisco.com Tue Jul 2 10:07:55 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D11D21F8415 for ; Tue, 2 Jul 2013 10:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsiHquCj7bcB for ; Tue, 2 Jul 2013 10:07:49 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A36CF21F84B2 for ; Tue, 2 Jul 2013 10:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7815; q=dns/txt; s=iport; t=1372784864; x=1373994464; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=05pS0ZDU9COBT6NbcAjze8nlmsPk3QuV70GUXJajApw=; b=JfXAitCJsxvxal//6xK9dA322Y1m4u4Bxz/0ijVsRVsGDVymfO3nDQja Qce9Dy5TTODp47albTurm7PzLuB18JWjR/IVVxn+3DgxLVs6POe3/urjJ ZTZ+CrpSYVxJkq8BZbxEpz8CkDisSRRxO6BethyTCOYIhSMfwTXTqTTKg Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAAwI01GQ/khR/2dsb2JhbABagwmJX7N3gnOBBRZ0giQBAQR4ARALIRYPCQMCAQIBRQYNAQcBAYgLvDuOI4E3B4NrA5N3g1KRRYMSgWg X-IronPort-AV: E=Sophos;i="4.87,982,1363132800"; d="scan'208,217";a="83881566" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 02 Jul 2013 17:07:31 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r62H7Tb5019417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 17:07:29 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r62H7S02007050; Tue, 2 Jul 2013 18:07:28 +0100 (BST) Message-ID: <51D308D0.5090707@cisco.com> Date: Tue, 02 Jul 2013 18:07:28 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Levente Csikor Subject: Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions References: <94A203EA12AECE4BA92D42DBFFE0AE47189620@eusaamb101.ericsson.se> <51CAE915.4020304@tmit.bme.hu> In-Reply-To: <51CAE915.4020304@tmit.bme.hu> Content-Type: multipart/alternative; boundary="------------080802000802050802080709" Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "rtgwg-chairs@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 17:07:55 -0000 This is a multi-part message in MIME format. --------------080802000802050802080709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 26/06/2013 14:13, Levente Csikor wrote: Levente In each case below the conditions are surely fulfilled if n=e thus I think that in each case the condition needs to be changed to : some node n!={s or e} > In order to not to read our full papers and searching the answers, I > copied here the relevant parts: > *Link-protecting rLFA condition:* > For source /s/, destination /d/, and next-hop /e/, some node /n/ /!= > s,d/ is a link-protecting remote LFA for the /s-d/ pair if and only if > /dist(s, n) < dist(s, e) + dist(e, n)/ (1) > /dist(n, d) < dist(n, s) + dist(s, d)/ (2) > In these equations, one can easily see, that (1) defines the P-space, > while (2) is the condition of Q-space. Furthermore, with these > formalized conditions, one can easily observe, that (2) is actually > the basic loop-free criterion of pure LFA. > > *Link-protecting rLFA condition with extended P-space:* > For source /s/, destination /d/, and next-hop /e/, some node /n != > s,d/ is an extended link-protecting remote LFA for the /s-d/ pair if > and only if > /?v ? neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)/// > /dist(n, d) < dist(n, s) + dist(s, d) . / > > *Node-protecting rLFA condition:* > For source /s/, destination /d/, and next-hop /e/, some /n != s,d/ is > a node-protecting remote LFA for the /s-d/ pair if and only if > /dist(s,n) < dist(s,e) + dist(e,n)/// (3) > /dist(n,d) < dist(n,e) + dist(e,d) / (4) > As it was in the case of link protection, here, (3) defines the > P-space, while (4) characterize the Q-space. > Here, two important observations can be made, which are the followings: > - P-space does not depend on the protection scheme (i.e., link or > node protection) SB> That falls directly out of the definition of P-space SB> since in link you cannot traverse the link to e and in SB> node only get to e if you traverse the link to e SB> thus the exclusion of the link to e applies in both cases > - (4) again is the basic node-protecting loop-free criterion of pure LFA. > > *Node-protecting rLFA condition with extended P-space:* > For source /s/, destination /d/, and next-hop /e/, some node /n != > s,d/ is an extended node-protecting remote LFA for the /s-d/ pair if > and only if > /?v ? neigh(s) : dist(v, n) < dist(v, e) + dist(e, n)/ > /dist(n, d) < dist(n, e) + dist(e, d) ./ > > Despite the fact that we only considered unit cost networks, the > formal definitions above are *true for any arbitrary weighted network.* SB> I do not see where the unit costs come into the text above. It looks SB> like it is already expressed in terms of arbitrary cost. SB> Additionally in order to limit the number of SPFs to a practical SB> level, we normally suggest that the repair target in not d, but SB> instead is e (in the link case) or next hop of e (node case). SB> Anyway I will work on some text. - Stewart --------------080802000802050802080709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 26/06/2013 14:13, Levente Csikor wrote:

Levente

In each case below the conditions are surely fulfilled if n=e
thus I think that in each case the condition needs to be
changed to :

some node n!={s or e}
In order to not to read our full papers and searching the answers, I copied here the relevant parts:
Link-protecting rLFA condition:
For source s, destination d, and next-hop e, some node n != s,d is a link-protecting remote LFA for the s-d pair  if and only if
  dist(s, n) < dist(s, e) + dist(e, n)  (1)
  dist(n, d) < dist(n, s) + dist(s, d)  (2)
In these equations, one can easily see, that (1) defines the P-space, while (2) is the condition of Q-space. Furthermore, with these formalized conditions, one can easily observe, that (2) is actually the basic loop-free criterion of pure LFA.

Link-protecting rLFA condition with extended P-space:
For source s, destination d, and next-hop e, some node n != s,d is an extended link-protecting remote LFA for the s-d pair if and only if
∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)    
dist(n, d) < dist(n, s) + dist(s, d) .                                             

Node-protecting rLFA condition:
For source s, destination d, and next-hop e, some n != s,d is a node-protecting remote LFA for the s-d pair if and only if
dist(s,n) < dist(s,e) + dist(e,n)      (3)
dist(n,d) < dist(n,e) + dist(e,d)     (4)
As it was in the case of link protection, here, (3) defines the P-space, while (4) characterize the Q-space.
Here, two important observations can be made, which are the followings:
 - P-space does not depend on the protection scheme (i.e., link or node protection)
SB> That falls directly out of the definition of P-space
SB> since in link you cannot traverse the link to e and in
SB> node only get to e if you traverse the link to e
SB> thus the exclusion of the link to e applies in both cases
 - (4) again is the basic node-protecting loop-free criterion of pure LFA.

Node-protecting rLFA condition with extended P-space:
For source s, destination d, and next-hop e, some node n != s,d is an extended node-protecting remote LFA for the s-d pair if and only if
∃v ∈ neigh(s) : dist(v, n) < dist(v, e) + dist(e, n)
dist(n, d) < dist(n, e) + dist(e, d) .

Despite the fact that we only considered unit cost networks, the formal definitions above are true for any arbitrary weighted network.
SB> I do not see where the unit costs come into the text above. It looks
SB> like it is already expressed in terms of arbitrary cost.

SB> Additionally in order to limit the number of SPFs to a practical
SB> level, we normally suggest that the repair target in not d, but
SB> instead is e (in the link case) or next hop of e (node case).

SB> Anyway I will work on some text.

- Stewart
--------------080802000802050802080709-- From csikor@tmit.bme.hu Tue Jul 2 13:03:59 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3A721F9B21 for ; Tue, 2 Jul 2013 13:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.197 X-Spam-Level: * X-Spam-Status: No, score=1.197 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4IGOAxm9GMp for ; Tue, 2 Jul 2013 13:03:53 -0700 (PDT) Received: from ruby.tmit.bme.hu (ruby.tmit.bme.hu [152.66.245.193]) by ietfa.amsl.com (Postfix) with ESMTP id 1744A21F9B1A for ; Tue, 2 Jul 2013 13:03:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ruby.tmit.bme.hu (Postfix) with ESMTP id 65DBE87351; Tue, 2 Jul 2013 22:03:50 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at tmit.bme.hu Received: from ruby.tmit.bme.hu ([127.0.0.1]) by localhost (ruby.tmit.bme.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbgkvmen6vhe; Tue, 2 Jul 2013 22:03:31 +0200 (CEST) Received: from anyo.tmit.bme.hu (anyo.tmit.bme.hu [152.66.246.7]) by ruby.tmit.bme.hu (Postfix) with ESMTP id 6D0E687346; Tue, 2 Jul 2013 22:03:30 +0200 (CEST) Received: from [192.168.89.138] (5403A50D.catv.pool.telekom.hu [84.3.165.13]) (authenticated bits=0) by anyo.tmit.bme.hu (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r62K3SQr007465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Jul 2013 22:03:28 +0200 Message-ID: <51D3320C.1040703@tmit.bme.hu> Date: Tue, 02 Jul 2013 22:03:24 +0200 From: Levente Csikor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stbryant@cisco.com Subject: Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions References: <94A203EA12AECE4BA92D42DBFFE0AE47189620@eusaamb101.ericsson.se> <51CAE915.4020304@tmit.bme.hu> <51D308D0.5090707@cisco.com> In-Reply-To: <51D308D0.5090707@cisco.com> Content-Type: multipart/alternative; boundary="------------050706090607090702090503" Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "rtgwg-chairs@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 20:03:59 -0000 This is a multi-part message in MIME format. --------------050706090607090702090503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Stewart, thanks for comments, see minecomments inline. On 07/02/2013 07:07 PM, Stewart Bryant wrote: > On 26/06/2013 14:13, Levente Csikor wrote: > > Levente > > In each case below the conditions are surely fulfilled if n=e > thus I think that in each case the condition needs to be > changed to : > > some node n!={s or e} LC> Yes, you have right that e should be excluded from the set of examined nodes, but in the first case below, it does not surely fulfill the condition, LC> but it would conflict, since assume that n=e := X, then we would get that LC> dist(s,X) < dist(s,X) + dist(X,X), where obviously the last component is zero! LC> Moreover, if next-hop e (,which is not the destination) became unreachable because of the failed link, then node s could not tunnel the traffic to e LC> again, since it would use the failed link. If we could do that, we need one more label in the label stack, since we would need to reach some other LC> node t, then we would need a tunnel from node t to node e, and then the remaining shortest path from node e to the destination. LC> On the other hand, I think that node d has to remain in the set of "non-analyzed" nodes, i.e., some node n!={s,e,d}, since according to the draft, if LC> we could tunnel the traffic directly to the destination (the case when n=d) "then conventional LFA would have been sufficient to effect the repair." >> In order to not to read our full papers and searching the answers, I >> copied here the relevant parts: >> *Link-protecting rLFA condition:* >> For source /s/, destination /d/, and next-hop /e/, some node /n/ /!= >> s,d/ is a link-protecting remote LFA for the /s-d/ pair if and only if >> /dist(s, n) < dist(s, e) + dist(e, n)/ (1) >> /dist(n, d) < dist(n, s) + dist(s, d)/ (2) >> In these equations, one can easily see, that (1) defines the P-space, >> while (2) is the condition of Q-space. Furthermore, with these >> formalized conditions, one can easily observe, that (2) is actually >> the basic loop-free criterion of pure LFA. >> >> *Link-protecting rLFA condition with extended P-space:* >> For source /s/, destination /d/, and next-hop /e/, some node /n != >> s,d/ is an extended link-protecting remote LFA for the /s-d/ pair if >> and only if >> /?v ? neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)/// >> /dist(n, d) < dist(n, s) + dist(s, d) . / >> >> *Node-protecting rLFA condition:* >> For source /s/, destination /d/, and next-hop /e/, some /n != s,d/ is >> a node-protecting remote LFA for the /s-d/ pair if and only if >> /dist(s,n) < dist(s,e) + dist(e,n)/// (3) >> /dist(n,d) < dist(n,e) + dist(e,d) / (4) >> As it was in the case of link protection, here, (3) defines the >> P-space, while (4) characterize the Q-space. >> Here, two important observations can be made, which are the followings: >> - P-space does not depend on the protection scheme (i.e., link or >> node protection) > SB> That falls directly out of the definition of P-space > SB> since in link you cannot traverse the link to e and in > SB> node only get to e if you traverse the link to e > SB> thus the exclusion of the link to e applies in both cases LC> Yes it is kind of obvious observation, which falls out of the definition of P-space, but I think that this could be noted in the draft, since if someone tries LC> to determine how much SPF,rSPF or even all-pair SP calculations are needed, then it is good to remember that for P-space, we could deal with the LC> same amount of calculations in both protection cases. >> - (4) again is the basic node-protecting loop-free criterion of pure >> LFA. >> >> *Node-protecting rLFA condition with extended P-space:* >> For source /s/, destination /d/, and next-hop /e/, some node /n != >> s,d/ is an extended node-protecting remote LFA for the /s-d/ pair if >> and only if >> /?v ? neigh(s) : dist(v, n) < dist(v, e) + dist(e, n)/ >> /dist(n, d) < dist(n, e) + dist(e, d) ./ >> >> Despite the fact that we only considered unit cost networks, the >> formal definitions above are *true for any arbitrary weighted network.* > SB> I do not see where the unit costs come into the text above. It looks > SB> like it is already expressed in terms of arbitrary cost. LC> Since in our papers, we only dealt with unit cost networks, therefore I wanted to emphasize that these results are true for any arbitrary weighted network. (However, you have right about the fact that if the conditions are expressed by distance functions, they will definitely true with any link cost settings :) ) > > SB> Additionally in order to limit the number of SPFs to a practical > SB> level, we normally suggest that the repair target in not d, but > SB> instead is e (in the link case) or next hop of e (node case). > > SB> Anyway I will work on some text. > LC> Thanks. > - Stewart Regards, Levente --------------050706090607090702090503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Stewart,
thanks for comments, see mine comments inline.
On 07/02/2013 07:07 PM, Stewart Bryant wrote:
On 26/06/2013 14:13, Levente Csikor wrote:

Levente

In each case below the conditions are surely fulfilled if n=e
thus I think that in each case the condition needs to be
changed to :

some node n!={s or e}
LC> Yes, you have right that e should be excluded from the set of examined nodes, but in the first case below, it does not surely fulfill the condition,
LC> but it would conflict, since assume that n=e := X, then we would get that
LC> dist(s,X) < dist(s,X) + dist(X,X), where obviously the last component is zero!
LC> Moreover, if next-hop e (,which  is not the destination) became unreachable because of the failed link, then node s could not tunnel the traffic to e
LC> again, since it would use the failed link. If we could do that, we need one more label in the label stack, since we would need to reach some other
LC> node t, then we would need a tunnel from node t to node e, and then the remaining shortest path from node e to the destination.


LC> On the other hand, I think that node d has to remain in the set of "non-analyzed" nodes, i.e., some node n!={s,e,d}, since according to the draft, if
LC> we could tunnel the traffic directly to the destination (the case when n=d) "then conventional LFA would have been sufficient to effect the repair."

    

      

        In order to not to read our full papers and searching the
        answers, I copied here the relevant parts:

        Link-protecting rLFA condition:

        For source s, destination d, and next-hop e,
        some node n != s,d is a link-protecting remote
        LFA for the s-d pair  if and only if

          dist(s, n) < dist(s, e) + dist(e, n)  (1)

          dist(n, d) < dist(n, s) + dist(s, d)  (2)

        In these equations, one can easily see, that (1) defines the
        P-space, while (2) is the condition of Q-space. Furthermore,
        with these formalized conditions, one can easily observe, that
        (2) is actually the basic loop-free criterion of pure LFA.

        

        Link-protecting rLFA condition with extended P-space:

        For source s, destination d, and next-hop e,
        some node n != s,d is an extended link-protecting remote
        LFA for the s-d pair if and only if

        ∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) +
          dist(e, n)     

        dist(n, d) < dist(n, s) + dist(s, d) .               
                                      

        

        Node-protecting rLFA condition:

        For source s, destination d, and next-hop e,
        some n != s,d is a node-protecting remote LFA for the s-d
        pair if and only if

        dist(s,n) < dist(s,e) + dist(e,n)      (3)

        dist(n,d) < dist(n,e) + dist(e,d)     (4)

        As it was in the case of link protection, here, (3) defines the
        P-space, while (4) characterize the Q-space.

        Here, two important observations can be made, which are the
        followings: 

         - P-space does not depend on the protection scheme (i.e., link
        or node protection)

      

      SB> That falls directly out of the definition of P-space

      SB> since in link you cannot traverse the link to e and in

      SB> node only get to e if you traverse the link to e

      SB> thus the exclusion of the link to e applies in both cases

    

    LC> Yes it is kind of obvious observation, which falls out of the
    definition of P-space, but I think that this could be noted in the
    draft, since if someone tries 

    LC> to determine how much SPF,rSPF or even all-pair SP
    calculations are needed, then it is good to remember that for
    P-space, we could deal with the 

    LC> same amount of calculations in both protection cases.

    

    

      

         - (4) again is the basic node-protecting loop-free criterion of
        pure LFA.

        

        Node-protecting rLFA condition with extended P-space:

        For source s, destination d, and next-hop e,
        some node n != s,d is an extended node-protecting remote
        LFA for the s-d pair if and only if

        ∃v ∈ neigh(s) : dist(v, n) < dist(v, e) + dist(e, n)

        dist(n, d) < dist(n, e) + dist(e, d) .

        

      

      

        Despite the fact that we only considered unit cost networks, the
        formal definitions above are true for any arbitrary
            weighted network.

      

      SB> I do not see where the unit costs come into the text above.
      It looks 

      SB> like it is already expressed in terms of arbitrary cost.

    

    LC> Since in our papers, we only dealt with unit cost networks,
    therefore I wanted to emphasize that these results are true for any
    arbitrary weighted network. (However, you have right about the fact
    that if the conditions are expressed by distance functions, they
    will definitely true with any link cost settings :) )

    

    
 

      SB> Additionally in order to limit the number of SPFs to a
      practical

      SB> level, we normally suggest that the repair target in not d,
      but

      SB> instead is e (in the link case) or next hop of e (node
      case).

      

      SB> Anyway I will work on some text.

      

    

    LC> Thanks.

    
 -
      Stewart

    

    

    Regards,

    Levente

  


--------------050706090607090702090503--

From akatlas@juniper.net  Tue Jul  2 14:17:41 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C265021F9017 for ; Tue,  2 Jul 2013 14:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.029
X-Spam-Level: 
X-Spam-Status: No, score=-0.029 tagged_above=-999 required=5 tests=[AWL=0.437,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eu-vdHM38h4h for ; Tue,  2 Jul 2013 14:17:35 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id F283421F901A for ; Tue,  2 Jul 2013 14:17:34 -0700 (PDT)
Received: from mail159-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE033.bigfish.com (10.243.66.98) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Jul 2013 21:17:34 +0000
Received: from mail159-co1 (localhost [127.0.0.1])	by mail159-co1-R.bigfish.com (Postfix) with ESMTP id 593851C0196	for ; Tue,  2 Jul 2013 21:17:34 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail159-co1: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=akatlas@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail159-co1 (localhost.localdomain [127.0.0.1]) by mail159-co1 (MessageSwitch) id 1372799852146054_15552; Tue,  2 Jul 2013 21:17:32 +0000 (UTC)
Received: from CO1EHSMHS023.bigfish.com (unknown [10.243.78.246])	by mail159-co1.bigfish.com (Postfix) with ESMTP id 20376C80050	for ; Tue,  2 Jul 2013 21:17:32 +0000 (UTC)
Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.53) by CO1EHSMHS023.bigfish.com (10.243.66.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Jul 2013 21:17:31 +0000
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 2 Jul 2013 14:17:30 -0700
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 2 Jul 2013 14:17:30 -0700
Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.14) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 2 Jul 2013 14:29:18 -0700
Received: from mail181-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Jul 2013 21:17:29 +0000
Received: from mail181-tx2 (localhost [127.0.0.1])	by mail181-tx2-R.bigfish.com (Postfix) with ESMTP id 3A4CC1A0BAE	for ; Tue,  2 Jul 2013 21:17:29 +0000 (UTC)
Received: from mail181-tx2 (localhost.localdomain [127.0.0.1]) by mail181-tx2 (MessageSwitch) id 1372799847275651_3646; Tue,  2 Jul 2013 21:17:27 +0000 (UTC)
Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.251])	by mail181-tx2.bigfish.com (Postfix) with ESMTP id 33DFC420077	for ; Tue,  2 Jul 2013 21:17:27 +0000 (UTC)
Received: from BY2PRD0510HT003.namprd05.prod.outlook.com (157.56.236.101) by TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Jul 2013 21:17:27 +0000
Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.169]) by BY2PRD0510HT003.namprd05.prod.outlook.com ([10.255.84.38]) with mapi id 14.16.0324.000; Tue, 2 Jul 2013 21:17:26 +0000
From: Alia Atlas 
To: "rtgwg@ietf.org" 
Subject: draft submission deadline - July 15  24:00 UTC
Thread-Topic: draft submission deadline - July 15  24:00 UTC
Thread-Index: Ac53aRsh0gKZeybHQ3Od/7QgV46rwgAAGglA
Date: Tue, 2 Jul 2013 21:17:26 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.232.2]
Content-Type: multipart/alternative; boundary="_000_D1CF735B7C7B744582438550F826E01B35138C57BY2PRD0510MB389_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-OriginatorOrg: juniper.net
X-Mailman-Approved-At: Tue, 02 Jul 2013 14:18:42 -0700
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 02 Jul 2013 21:17:41 -0000

--_000_D1CF735B7C7B744582438550F826E01B35138C57BY2PRD0510MB389_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In what may be happy news for some of you, I just learned that the IESG has=
 merged the two internet-draft deadlines.  Both initial document (-00) and =
final documents can be submitted until July 15.

But remember that we'd all like to read your fascinating ideas and mull the=
m over - so sooner is still better :)

Alia


--_000_D1CF735B7C7B744582438550F826E01B35138C57BY2PRD0510MB389_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











In what may be happy news for some of you, I just learned that the IES=
G has merged the two internet-draft deadlines.  Both initial document =
(-00) and final documents can be submitted until July 15.


 


But remember that we’d all like to read your fascinating ideas a=
nd mull them over – so sooner is still better J


 


Alia


 





--_000_D1CF735B7C7B744582438550F826E01B35138C57BY2PRD0510MB389_--

From akatlas@gmail.com  Fri Jul  5 14:30:34 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D263021F9EE2 for ; Fri,  5 Jul 2013 14:30:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qno-NAcfq2xL for ; Fri,  5 Jul 2013 14:30:34 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD5D21F9A6B for ; Fri,  5 Jul 2013 14:30:30 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id ar20so6376049iec.35 for ; Fri, 05 Jul 2013 14:30:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bfQYuhXthO32dtxa9RWQKbu5MPivH23ZpQvpNQ58suY=; b=l44KT/1VeEjWJgUMfBWTSwvwT/zV81XBf6rxDBiorPKWmVXt/OAuHlBh12oPVlLDk5 vmuQZD37xXJKZ1oYEIRFLQtuK0LXQfMPUOQa+Y13TVm8zPXKn9iLZPEoAodZV5gRhD+P ImikGUt73RcKQLZVtQYXVt6SbVBF1mKplCO7E+JWLW+ZdCz+TtYzYIp9W8DDSUjwcqSm UKLisWkZRNDNCdOE8cwktsXR3zUnDyMT0vCsrWkSYXkV+ONfCGgsu7JpIl7GCR8FPqWh qEj15pevDxUGjfmDYw59rRr/Jaih/EggVc2P0VW8eE72WCxXOMcHWvYK4GJnHvJt93yr n5Hg==
MIME-Version: 1.0
X-Received: by 10.50.67.111 with SMTP id m15mr5069121igt.54.1373059829620; Fri, 05 Jul 2013 14:30:29 -0700 (PDT)
Received: by 10.64.47.168 with HTTP; Fri, 5 Jul 2013 14:30:29 -0700 (PDT)
Date: Fri, 5 Jul 2013 17:30:29 -0400
Message-ID: 
Subject: rtgwg scheduled for Friday, Afternoon Session 1
From: Alia Atlas 
To: "rtgwg@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7bd7524466673004e0ca67ef
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Jul 2013 21:30:34 -0000

--047d7bd7524466673004e0ca67ef
Content-Type: text/plain; charset=ISO-8859-1

Just a heads-up for those who haven't planned their travel yet; rtgwg is
scheduled for the first Friday afternoon session.

Remember that discussion on the list is very valuable (not just
face-to-face time) and that IETF is increasingly full with many conflicts
between working groups.

Alia

--047d7bd7524466673004e0ca67ef
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Just a heads-up for those who haven't planned their tr=
avel yet; rtgwg is scheduled for the first Friday afternoon session.
Remember that discussion on the list is very valuable (not jus=
t face-to-face time) and that IETF is increasingly full with many conflicts=
 between working groups.



Alia


--047d7bd7524466673004e0ca67ef--

From akatlas@gmail.com  Fri Jul  5 17:27:11 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719BD21F9E6A for ; Fri,  5 Jul 2013 17:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxezuXRkkcLO for ; Fri,  5 Jul 2013 17:27:10 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1142921F9E66 for ; Fri,  5 Jul 2013 17:27:10 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id e11so6571231iej.1 for ; Fri, 05 Jul 2013 17:27:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=i09C7spV7/nSVUw+YJxucSM8N0EpGk61AcyfJHxdZVI=; b=lia5a8Z3DNZAnhyoo36CrFWzGxLoQAIMQE1tBCOr5MnFwejS8xiHkLApRRHp+ZSHWG uKPOxJh2ix99rraE1BH40yHcJKox2P1x7XjAi/i+AOVX8GqTMZBOoYFQO1qv3ZrwxZcv 3Vgo2+YGaReh9NVBajwi78VFZhxB1mr1Ip0sLASXMU2E60sCE0pRnV6swOvortuxc+NS Xq4bzrK9/JVk4jvR/0ZAVSZv8wQmHqZ+Qbxmtlwbkeaqjk4Ttn0A0unLCeYUNc3KNqKC TSdTiEC4B2nNxSLELrtLk3tjZXAlkrthBe0/yUlOSlzk2NQlFQPYY7orU5+0lBRibZJR rUVA==
MIME-Version: 1.0
X-Received: by 10.50.67.111 with SMTP id m15mr5214887igt.54.1373070429651; Fri, 05 Jul 2013 17:27:09 -0700 (PDT)
Received: by 10.64.47.168 with HTTP; Fri, 5 Jul 2013 17:27:09 -0700 (PDT)
In-Reply-To: <20130706002000.640.24427.idtracker@ietfa.amsl.com>
References: <20130706002000.640.24427.idtracker@ietfa.amsl.com>
Date: Fri, 5 Jul 2013 20:27:09 -0400
Message-ID: 
Subject: Fwd: IETF 87 Final Agenda
From: Alia Atlas 
To: "rtgwg@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7bd7524436066704e0ccdfe5
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 06 Jul 2013 00:27:11 -0000

--047d7bd7524436066704e0ccdfe5
Content-Type: text/plain; charset=ISO-8859-1

Note that rtgwg is scheduled for:  Friday Afternoon Session I and II
*
*
We'll close the IETF meeting ;-)

Alia

---------- Forwarded message ----------
From: IETF Agenda 
Date: Fri, Jul 5, 2013 at 8:20 PM
Subject: IETF 87 Final Agenda
To: IETF Announcement List 
Cc: ietf@ietf.org



87th IETF Meeting - Berlin, Germany
July 28 - August 2, 2013

The final agenda has been posted.

https://datatracker.ietf.org/meeting/87/agenda.html
https://datatracker.ietf.org/meeting/87/agenda.txt

While this is considered the final agenda for printing, changes may
be made to the agenda up until and during the meeting. Updates will be
reflected on the web version of the agenda.

Information about the 87th IETF meeting in Berlin, Germany can be found
here: https://www.ietf.org/meeting/87/index.html

Thank you and see you in Berlin!

Sincerely,

The IETF Secretariat

--047d7bd7524436066704e0ccdfe5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Note that rtgwg is scheduled for: =A0Friday Afternoon Session I and II

<=
font color=3D"#000000">We'll close the IETF meeting ;-)



<=
font face=3D"arial, helvetica, clean, sans-serif">Alia


---------- Forwarded me=
ssage ----------
From: IETF Agenda <agenda@ietf.org&g=
t;

Date: Fri, Jul 5, 2013 at 8:20 PM
Subject: IETF 87 Final Agenda
To: I=
ETF Announcement List <ietf-an=
nounce@ietf.org>
Cc: ietf@ietf.o=
rg





87th IETF Meeting - Berlin, Germany

July 28 - August 2, 2013



The final agenda has been posted.



https://datatracker.ietf.org/meeting/87/agenda.html

https://datatracker.ietf.org/meeting/87/agenda.txt



While this is considered the final agenda for printing, changes may

be made to the agenda up until and during the meeting. Updates will be refl=
ected on the web version of the agenda.



Information about the 87th IETF meeting in Berlin, Germany can be found her=
e: https://www.ietf.org/meeting/87/index.html



Thank you and see you in Berlin!



Sincerely,



The IETF Secretariat





--047d7bd7524436066704e0ccdfe5--

From akatlas@juniper.net  Mon Jul  8 12:31:19 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A8021F9C19 for ; Mon,  8 Jul 2013 12:31:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.207
X-Spam-Level: 
X-Spam-Status: No, score=0.207 tagged_above=-999 required=5 tests=[AWL=-0.327,  BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xXd4jlLVpRl for ; Mon,  8 Jul 2013 12:31:12 -0700 (PDT)
Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by ietfa.amsl.com (Postfix) with ESMTP id D9A5821F9C17 for ; Mon,  8 Jul 2013 12:31:11 -0700 (PDT)
Received: from mail117-db9-R.bigfish.com (10.174.16.247) by DB9EHSOBE001.bigfish.com (10.174.14.64) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 19:31:10 +0000
Received: from mail117-db9 (localhost [127.0.0.1])	by mail117-db9-R.bigfish.com (Postfix) with ESMTP id C43021A0056	for ; Mon,  8 Jul 2013 19:31:10 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: 12
X-BigFish: VPS12(z329eq6celzc85fh4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail117-db9: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=akatlas@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail117-db9 (localhost.localdomain [127.0.0.1]) by mail117-db9 (MessageSwitch) id 1373311867749547_7951; Mon,  8 Jul 2013 19:31:07 +0000 (UTC)
Received: from DB9EHSMHS025.bigfish.com (unknown [10.174.16.228])	by mail117-db9.bigfish.com (Postfix) with ESMTP id AE917460046	for ; Mon,  8 Jul 2013 19:31:07 +0000 (UTC)
Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.50) by DB9EHSMHS025.bigfish.com (10.174.14.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 8 Jul 2013 19:31:03 +0000
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Jul 2013 12:30:21 -0700
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 8 Jul 2013 12:30:20 -0700
Received: from DB8EHSOBE020.bigfish.com (213.199.154.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 8 Jul 2013 12:34:07 -0700
Received: from mail80-db8-R.bigfish.com (10.174.8.235) by DB8EHSOBE020.bigfish.com (10.174.4.83) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 19:30:18 +0000
Received: from mail80-db8 (localhost [127.0.0.1])	by mail80-db8-R.bigfish.com (Postfix) with ESMTP id A17D0D6022F	for ; Mon,  8 Jul 2013 19:30:18 +0000 (UTC)
Received: from mail80-db8 (localhost.localdomain [127.0.0.1]) by mail80-db8 (MessageSwitch) id 137331181796571_972; Mon,  8 Jul 2013 19:30:17 +0000 (UTC)
Received: from DB8EHSMHS031.bigfish.com (unknown [10.174.8.246])	by mail80-db8.bigfish.com (Postfix) with ESMTP id 132D3DA0147	for ; Mon,  8 Jul 2013 19:30:17 +0000 (UTC)
Received: from BY2PRD0510HT002.namprd05.prod.outlook.com (157.56.236.101) by DB8EHSMHS031.bigfish.com (10.174.4.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 8 Jul 2013 19:30:16 +0000
Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.169]) by BY2PRD0510HT002.namprd05.prod.outlook.com ([10.255.84.37]) with mapi id 14.16.0324.000; Mon, 8 Jul 2013 19:30:02 +0000
From: Alia Atlas 
To: "rtgwg@ietf.org" 
Subject: IETF-87 agenda topics for rtgwg
Thread-Topic: IETF-87 agenda topics for rtgwg
Thread-Index: AQHOfBGKLPwqqPSPcUKo80xZSEBxog==
Date: Mon, 8 Jul 2013 19:30:01 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.232.2]
Content-Type: multipart/alternative; boundary="_000_D1CF735B7C7B744582438550F826E01B3513C6CBBY2PRD0510MB389_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Jul 2013 19:31:19 -0000

--_000_D1CF735B7C7B744582438550F826E01B3513C6CBBY2PRD0510MB389_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I2RS is scheduled to meet on Friday, August 2 from 11:20-13:30.  Please for=
ward any I2RS agenda items you have to Alvaro and myself.  The deadline is =
July 16 - but earlier is better.    Our WG agenda is due on July 17.  We do=
 require an internet-draft (with planned-to-be very rare exceptions).

For accepted presentations, please provide your slides by July 31 10pm CET.

Finally, if you request an agenda slot, please do so by replying to this me=
ssage and don't change the subject line.

Thanks,
Alia


--_000_D1CF735B7C7B744582438550F826E01B3513C6CBBY2PRD0510MB389_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I2RS is scheduled to meet on Friday, August 2 from 11:20-13:30.  =
Please forward any I2RS agenda items you have to Alvaro and myself.  T=
he deadline is July 16 – but earlier is better.    Our=
 WG agenda is due on July 17.  We do require an internet-draft
(with planned-to-be very rare exceptions).


 


For accepted presentations, please provide your slides by July 31 10pm=
 CET.


 


Finall=
y, if you request an agenda slot, please do so by replying to this message =
and don't change the subject line.


 =



Thanks=
,


Alia


 





--_000_D1CF735B7C7B744582438550F826E01B3513C6CBBY2PRD0510MB389_--

From akatlas@juniper.net  Mon Jul  8 12:32:33 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3304721F9C61 for ; Mon,  8 Jul 2013 12:32:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.207
X-Spam-Level: 
X-Spam-Status: No, score=0.207 tagged_above=-999 required=5 tests=[AWL=-0.327,  BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqvaJV94pWZU for ; Mon,  8 Jul 2013 12:32:33 -0700 (PDT)
Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by ietfa.amsl.com (Postfix) with ESMTP id 02E0C21F9C5D for ; Mon,  8 Jul 2013 12:32:29 -0700 (PDT)
Received: from mail7-db9-R.bigfish.com (10.174.16.242) by DB9EHSOBE019.bigfish.com (10.174.14.82) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 19:32:29 +0000
Received: from mail7-db9 (localhost [127.0.0.1])	by mail7-db9-R.bigfish.com (Postfix) with ESMTP id 00F2790011A	for ; Mon,  8 Jul 2013 19:32:29 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: 12
X-BigFish: VPS12(z329eq6celzc85fh4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail7-db9: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=akatlas@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail7-db9 (localhost.localdomain [127.0.0.1]) by mail7-db9 (MessageSwitch) id 1373311945850081_29506; Mon,  8 Jul 2013 19:32:25 +0000 (UTC)
Received: from DB9EHSMHS025.bigfish.com (unknown [10.174.16.229])	by mail7-db9.bigfish.com (Postfix) with ESMTP id BFA14A0004D	for ; Mon,  8 Jul 2013 19:32:25 +0000 (UTC)
Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.50) by DB9EHSMHS025.bigfish.com (10.174.14.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 8 Jul 2013 19:31:03 +0000
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Jul 2013 12:30:21 -0700
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 8 Jul 2013 12:30:20 -0700
Received: from DB8EHSOBE020.bigfish.com (213.199.154.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 8 Jul 2013 12:34:07 -0700
Received: from mail80-db8-R.bigfish.com (10.174.8.235) by DB8EHSOBE020.bigfish.com (10.174.4.83) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 19:30:18 +0000
Received: from mail80-db8 (localhost [127.0.0.1])	by mail80-db8-R.bigfish.com (Postfix) with ESMTP id A17D0D6022F	for ; Mon,  8 Jul 2013 19:30:18 +0000 (UTC)
Received: from mail80-db8 (localhost.localdomain [127.0.0.1]) by mail80-db8 (MessageSwitch) id 137331181796571_972; Mon,  8 Jul 2013 19:30:17 +0000 (UTC)
Received: from DB8EHSMHS031.bigfish.com (unknown [10.174.8.246])	by mail80-db8.bigfish.com (Postfix) with ESMTP id 132D3DA0147	for ; Mon,  8 Jul 2013 19:30:17 +0000 (UTC)
Received: from BY2PRD0510HT002.namprd05.prod.outlook.com (157.56.236.101) by DB8EHSMHS031.bigfish.com (10.174.4.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 8 Jul 2013 19:30:16 +0000
Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.169]) by BY2PRD0510HT002.namprd05.prod.outlook.com ([10.255.84.37]) with mapi id 14.16.0324.000; Mon, 8 Jul 2013 19:30:02 +0000
From: Alia Atlas 
To: "rtgwg@ietf.org" 
Subject: IETF-87 agenda topics for rtgwg
Thread-Topic: IETF-87 agenda topics for rtgwg
Thread-Index: AQHOfBGKLPwqqPSPcUKo80xZSEBxog==
Date: Mon, 8 Jul 2013 19:30:01 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.232.2]
Content-Type: multipart/alternative; boundary="_000_D1CF735B7C7B744582438550F826E01B3513C6CBBY2PRD0510MB389_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Jul 2013 19:32:33 -0000

--_000_D1CF735B7C7B744582438550F826E01B3513C6CBBY2PRD0510MB389_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I2RS is scheduled to meet on Friday, August 2 from 11:20-13:30.  Please for=
ward any I2RS agenda items you have to Alvaro and myself.  The deadline is =
July 16 - but earlier is better.    Our WG agenda is due on July 17.  We do=
 require an internet-draft (with planned-to-be very rare exceptions).

For accepted presentations, please provide your slides by July 31 10pm CET.

Finally, if you request an agenda slot, please do so by replying to this me=
ssage and don't change the subject line.

Thanks,
Alia


--_000_D1CF735B7C7B744582438550F826E01B3513C6CBBY2PRD0510MB389_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I2RS is scheduled to meet on Friday, August 2 from 11:20-13:30.  =
Please forward any I2RS agenda items you have to Alvaro and myself.  T=
he deadline is July 16 – but earlier is better.    Our=
 WG agenda is due on July 17.  We do require an internet-draft
(with planned-to-be very rare exceptions).


 


For accepted presentations, please provide your slides by July 31 10pm=
 CET.


 


Finall=
y, if you request an agenda slot, please do so by replying to this message =
and don't change the subject line.


 =



Thanks=
,


Alia


 





--_000_D1CF735B7C7B744582438550F826E01B3513C6CBBY2PRD0510MB389_--

From akatlas@juniper.net  Mon Jul  8 12:32:41 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FB921F9C8B for ; Mon,  8 Jul 2013 12:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.76
X-Spam-Level: 
X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[AWL=1.706,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2Vk3Tt7N3Qy for ; Mon,  8 Jul 2013 12:32:34 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id BD58521F9C81 for ; Mon,  8 Jul 2013 12:32:34 -0700 (PDT)
Received: from mail78-co9-R.bigfish.com (10.236.132.239) by CO9EHSOBE040.bigfish.com (10.236.130.103) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 19:32:34 +0000
Received: from mail78-co9 (localhost [127.0.0.1])	by mail78-co9-R.bigfish.com (Postfix) with ESMTP id CFE13A0193	for ; Mon,  8 Jul 2013 19:32:33 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: 12
X-BigFish: VPS12(z329eq6celzc85fh4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail78-co9: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=akatlas@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail78-co9 (localhost.localdomain [127.0.0.1]) by mail78-co9 (MessageSwitch) id 1373311951625124_29785; Mon,  8 Jul 2013 19:32:31 +0000 (UTC)
Received: from CO9EHSMHS001.bigfish.com (unknown [10.236.132.237])	by mail78-co9.bigfish.com (Postfix) with ESMTP id 956BD2E0061	for ; Mon,  8 Jul 2013 19:32:31 +0000 (UTC)
Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.51) by CO9EHSMHS001.bigfish.com (10.236.130.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Jul 2013 19:32:31 +0000
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Jul 2013 12:32:30 -0700
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 8 Jul 2013 12:32:30 -0700
Received: from CO9EHSOBE021.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 8 Jul 2013 12:36:16 -0700
Received: from mail189-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE021.bigfish.com (10.236.130.84) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 19:32:29 +0000
Received: from mail189-co9 (localhost [127.0.0.1])	by mail189-co9-R.bigfish.com (Postfix) with ESMTP id 42BAEC8018C	for ; Mon,  8 Jul 2013 19:32:29 +0000 (UTC)
Received: from mail189-co9 (localhost.localdomain [127.0.0.1]) by mail189-co9 (MessageSwitch) id 1373311947574555_984; Mon,  8 Jul 2013 19:32:27 +0000 (UTC)
Received: from CO9EHSMHS014.bigfish.com (unknown [10.236.132.239])	by mail189-co9.bigfish.com (Postfix) with ESMTP id 7FFDD740061	for ; Mon,  8 Jul 2013 19:32:27 +0000 (UTC)
Received: from BY2PRD0510HT002.namprd05.prod.outlook.com (157.56.236.101) by CO9EHSMHS014.bigfish.com (10.236.130.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Jul 2013 19:32:23 +0000
Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.169]) by BY2PRD0510HT002.namprd05.prod.outlook.com ([10.255.84.37]) with mapi id 14.16.0324.000; Mon, 8 Jul 2013 19:32:17 +0000
From: Alia Atlas 
To: "rtgwg@ietf.org" 
Subject: IETF-87 agenda topics for rtgwg
Thread-Topic: IETF-87 agenda topics for rtgwg
Thread-Index: AQHOfBHbG8nhuiIN2ECgO+nqIhjF+Q==
Date: Mon, 8 Jul 2013 19:32:17 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.232.2]
Content-Type: multipart/alternative; boundary="_000_D1CF735B7C7B744582438550F826E01B3513C6DBBY2PRD0510MB389_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-OriginatorOrg: juniper.net
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Jul 2013 19:32:41 -0000

--_000_D1CF735B7C7B744582438550F826E01B3513C6DBBY2PRD0510MB389_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

RTGWG is scheduled to meet on Friday, August 2 from 11:20-13:30.  Please fo=
rward any RTGWG agenda items you have to Alvaro and myself.  The deadline i=
s July 16 - but earlier is better.    Our WG agenda is due on July 17.  We =
do require an internet-draft (with planned-to-be very rare exceptions).

For accepted presentations, please provide your slides by July 31 10pm CET.

Finally, if you request an agenda slot, please do so by replying to this me=
ssage and don't change the subject line.

Thanks,
Alia

P.S.  Sorry for the cut-n-paste errors of I2RS instead of RTGWG.  There is =
little uniqueness in these reminders...


--_000_D1CF735B7C7B744582438550F826E01B3513C6DBBY2PRD0510MB389_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











RTGWG is scheduled to meet on Friday, August 2 from 11:20-13:30. =
 Please forward any RTGWG agenda items you have to Alvaro and myself. =
 The deadline is July 16 – but earlier is better.    O=
ur WG agenda is due on July 17.  We do require an internet-draft
(with planned-to-be very rare exceptions).


 


For accepted presentations, please provide your slides by July 31 10pm=
 CET.


 


Finall=
y, if you request an agenda slot, please do so by replying to this message =
and don't change the subject line.


 =



Thanks=
,


Alia


 


P.S.  Sorry for the cut-n-paste errors of I2RS instead of RTGWG.&=
nbsp; There is little uniqueness in these reminders…


 





--_000_D1CF735B7C7B744582438550F826E01B3513C6DBBY2PRD0510MB389_--

From psarkar@juniper.net  Wed Jul 10 00:38:49 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2BC21F9F81 for ; Wed, 10 Jul 2013 00:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.686
X-Spam-Level: 
X-Spam-Status: No, score=-0.686 tagged_above=-999 required=5 tests=[AWL=-1.260, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdgMQurvCevl for ; Wed, 10 Jul 2013 00:38:43 -0700 (PDT)
Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 205CB21F9F6A for ; Wed, 10 Jul 2013 00:38:43 -0700 (PDT)
Received: from mail9-db9-R.bigfish.com (10.174.16.246) by DB9EHSOBE021.bigfish.com (10.174.14.84) with Microsoft SMTP Server id 14.1.225.22; Wed, 10 Jul 2013 07:38:38 +0000
Received: from mail9-db9 (localhost [127.0.0.1])	by mail9-db9-R.bigfish.com (Postfix) with ESMTP id 11D7FC801BF	for ; Wed, 10 Jul 2013 07:38:38 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: -25
X-BigFish: VPS-25(zz9371I936eI1454I542I14ffIzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail9-db9: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=psarkar@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail9-db9 (localhost.localdomain [127.0.0.1]) by mail9-db9 (MessageSwitch) id 1373441915986845_6344; Wed, 10 Jul 2013 07:38:35 +0000 (UTC)
Received: from DB9EHSMHS009.bigfish.com (unknown [10.174.16.251])	by mail9-db9.bigfish.com (Postfix) with ESMTP id E2FA4920046	for ; Wed, 10 Jul 2013 07:38:35 +0000 (UTC)
Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.53) by DB9EHSMHS009.bigfish.com (10.174.14.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 10 Jul 2013 07:38:35 +0000
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Jul 2013 00:38:34 -0700
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 10 Jul 2013 00:38:34 -0700
Received: from CO9EHSOBE018.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 10 Jul 2013 00:42:17 -0700
Received: from mail99-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE018.bigfish.com (10.236.130.81) with Microsoft SMTP Server id 14.1.225.22; Wed, 10 Jul 2013 07:38:33 +0000
Received: from mail99-co9 (localhost [127.0.0.1])	by mail99-co9-R.bigfish.com (Postfix) with ESMTP id A46F64A008A	for ; Wed, 10 Jul 2013 07:38:33 +0000 (UTC)
Received: from mail99-co9 (localhost.localdomain [127.0.0.1]) by mail99-co9 (MessageSwitch) id 1373441911977195_19219; Wed, 10 Jul 2013 07:38:31 +0000 (UTC)
Received: from CO9EHSMHS023.bigfish.com (unknown [10.236.132.245])	by mail99-co9.bigfish.com (Postfix) with ESMTP id E1400E0050	for ; Wed, 10 Jul 2013 07:38:31 +0000 (UTC)
Received: from BY2PRD0510HT004.namprd05.prod.outlook.com (157.56.236.101) by CO9EHSMHS023.bigfish.com (10.236.130.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Jul 2013 07:38:31 +0000
Received: from BY2PRD0510MB376.namprd05.prod.outlook.com ([169.254.5.169]) by BY2PRD0510HT004.namprd05.prod.outlook.com ([10.255.84.39]) with mapi id 14.16.0324.000; Wed, 10 Jul 2013 07:38:30 +0000
From: Pushpasis Sarkar 
To: "rtgwg@ietf.org" 
Subject: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt
Thread-Topic: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt
Thread-Index: AQHOfIKn6PGYkVy4YEiyAgNUiLNeeJlddVYQgAASSEA=
Date: Wed, 10 Jul 2013 07:38:29 +0000
Message-ID: <59B7D431F843564FBE967123924AD2AB0FD6AF2E@BY2PRD0510MB376.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [116.197.178.91]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: Harish Raghuveer 
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Jul 2013 07:38:49 -0000

SGkgQWxsLA0KDQpZZXN0ZXJkYXkgd2UgcG9zdGVkIGEgbmV3IGRyYWZ0IG9uIFJlbW90ZS1MRkEg
Tm9kZSBQcm90ZWN0aW9uIGFuZCBNYW5hZ2VhYmlsaXR5IGFuZCB3b3VsZCBsaWtlIHRvIGhlYXIg
eW91ciB2aWV3cyBvbiBpdC4gUGxlYXNlIGZlZWwgZnJlZSB0byByYWlzZSBhbnkgc3VnZ2VzdGlv
bi9jb21tZW50IG9uIHRoZSBjb250ZW50Lg0KDQpCZXN0IFJlZ2FyZHMsDQpQdXNocGFzaXMNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y
ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUdWVzZGF5LCBKdWx5
IDA5LCAyMDEzIDI6MjggUE0NClRvOiBIYXJpc2ggUmFnaHV2ZWVyOyBTaHJhZGRoYSBIZWdkZTsg
SGFubmVzIEdyZWRsZXI7IFB1c2hwYXNpcyBTYXJrYXI7IHBzYXJrYXJADQpTdWJqZWN0OiBOZXcg
VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXBzYXJrYXItcnRnd2ctcmxmYS1ub2RlLXBy
b3RlY3Rpb24tMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXBzYXJrYXIt
cnRnd2ctcmxmYS1ub2RlLXByb3RlY3Rpb24tMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg
c3VibWl0dGVkIGJ5IFB1c2hwYXNpcyBTYXJrYXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv
c2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXBzYXJrYXItcnRnd2ctcmxmYS1ub2RlLXByb3Rl
Y3Rpb24NClJldmlzaW9uOgkgMDENClRpdGxlOgkJIE5vZGUgUHJvdGVjdGluZyBSLUxGQSBhbmQg
TWFuYWdlYWJpbGl0eQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDctMDgNCkdyb3VwOgkJIEluZGl2
aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMQ0KVVJMOiAgICAgICAgICAgICBo
dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wc2Fya2FyLXJ0Z3dnLXJs
ZmEtbm9kZS1wcm90ZWN0aW9uLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBzYXJrYXItcnRnd2ctcmxmYS1ub2RlLXByb3RlY3Rp
b24NCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcHNh
cmthci1ydGd3Zy1ybGZhLW5vZGUtcHJvdGVjdGlvbi0wMQ0KRGlmZjogICAgICAgICAgICBodHRw
Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1wc2Fya2FyLXJ0Z3dnLXJsZmEtbm9k
ZS1wcm90ZWN0aW9uLTAxDQoNCkFic3RyYWN0Og0KICAgVGhlIGxvb3AtZnJlZSBhbHRlcm5hdGVz
IGNvbXB1dGVkIGZvbGxvd2luZyB0aGUgY3VycmVudCBSZW1vdGUtTEZBDQogICBbSS1ELmlldGYt
cnRnd2ctcmVtb3RlLWxmYV0gc3BlY2lmaWNhdGlvbiBnYXVyYW50ZWVzIG9ubHkgbGluay0NCiAg
IHByb3RlY3Rpb24uICBUaGUgcmVzdWx0aW5nIFJlbW90ZS1MRkEgbmV4dGhvcHMgKGFsc28gY2Fs
bGVkIFBRLQ0KICAgbm9kZXMpLCBtYXkgbm90IGdhdXJhbnRlZSBub2RlLXByb3RlY3Rpb24gZm9y
IGFsbCBkZXN0aW5hdGlvbnMgYmVpbmcNCiAgIHByb3RlY3RlZCBieSBpdC4NCg0KICAgVGhpcyBk
b2N1bWVudCBkZXNjcmliZXMgcHJvY2VkdXJlcyBmb3IgZGV0ZXJtaW5pbmcgaWYgYSBnaXZlbiBQ
US1ub2RlDQogICBwcm92aWRlcyBub2RlLXByb3RlY3Rpb24gZm9yIGEgc3BlY2lmaWMgZGVzdGlu
YXRpb24gb3Igbm90LiAgVGhlDQogICBkb2N1bWVudCBhbHNvIHNob3dzIGhvdyB0aGUgc2FtZSBw
cm9jZWR1cmUgY2FuIGJlIHV0aWxpc2VkIGZvcg0KICAgY29sbGVjdGlvbiBvZiBjb21wbGV0ZSBj
aGFyYWN0ZXJpc3RpY3MgZm9yIGFsdGVybmF0ZSBwYXRocy4NCiAgIEtub3dsZWRnZSBhYm91dCB0
aGUgY2hhcmFjdGVyaXN0aWNzIG9mIGFsbCBhbHRlcm5hdGUgcGF0aCBpcw0KICAgcHJlY3Vyc29y
eSB0byBhcHBseSBvcGVyYXRvciBkZWZpbmVkIHBvbGljeSBmb3IgZWxpbWluYXRpbmcgcGF0aHMg
bm90DQogICBmaXR0aW5nIGNvbnN0cmFpbnRzLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0K



From psarkar@juniper.net  Wed Jul 10 00:55:55 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5D521F9CDC for ; Wed, 10 Jul 2013 00:55:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.766
X-Spam-Level: 
X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoFKxE1E+KEp for ; Wed, 10 Jul 2013 00:55:50 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 02A5321F9CBF for ; Wed, 10 Jul 2013 00:55:49 -0700 (PDT)
Received: from mail182-co1-R.bigfish.com (10.243.78.250) by CO1EHSOBE017.bigfish.com (10.243.66.80) with Microsoft SMTP Server id 14.1.225.22; Wed, 10 Jul 2013 07:55:49 +0000
Received: from mail182-co1 (localhost [127.0.0.1])	by mail182-co1-R.bigfish.com (Postfix) with ESMTP id 77108880055	for ; Wed, 10 Jul 2013 07:55:49 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: -25
X-BigFish: VPS-25(zz9371I936eI1454I542I14ffIzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail182-co1: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=psarkar@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail182-co1 (localhost.localdomain [127.0.0.1]) by mail182-co1 (MessageSwitch) id 1373442947414526_23823; Wed, 10 Jul 2013 07:55:47 +0000 (UTC)
Received: from CO1EHSMHS029.bigfish.com (unknown [10.243.78.234])	by mail182-co1.bigfish.com (Postfix) with ESMTP id 61BD680057	for ; Wed, 10 Jul 2013 07:55:47 +0000 (UTC)
Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.51) by CO1EHSMHS029.bigfish.com (10.243.66.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Jul 2013 07:55:47 +0000
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Jul 2013 00:55:46 -0700
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 10 Jul 2013 00:55:46 -0700
Received: from co1outboundpool.messaging.microsoft.com (216.32.180.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 10 Jul 2013 01:08:28 -0700
Received: from mail121-co1-R.bigfish.com (10.243.78.243) by CO1EHSOBE040.bigfish.com (10.243.66.105) with Microsoft SMTP Server id 14.1.225.22; Wed, 10 Jul 2013 07:55:45 +0000
Received: from mail121-co1 (localhost [127.0.0.1])	by mail121-co1-R.bigfish.com (Postfix) with ESMTP id 784BB7C00F8	for ; Wed, 10 Jul 2013 07:55:45 +0000 (UTC)
Received: from mail121-co1 (localhost.localdomain [127.0.0.1]) by mail121-co1 (MessageSwitch) id 1373442943182253_21058; Wed, 10 Jul 2013 07:55:43 +0000 (UTC)
Received: from CO1EHSMHS025.bigfish.com (unknown [10.243.78.254])	by mail121-co1.bigfish.com (Postfix) with ESMTP id 1FACDA40055	for ; Wed, 10 Jul 2013 07:55:43 +0000 (UTC)
Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by CO1EHSMHS025.bigfish.com (10.243.66.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Jul 2013 07:55:39 +0000
Received: from BY2PRD0510MB376.namprd05.prod.outlook.com ([169.254.5.169]) by BY2PRD0510HT005.namprd05.prod.outlook.com ([10.255.84.40]) with mapi id 14.16.0324.000; Wed, 10 Jul 2013 07:55:39 +0000
From: Pushpasis Sarkar 
To: "rtgwg@ietf.org" 
Subject: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt
Thread-Topic: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt
Thread-Index: AQHOfIKn6PGYkVy4YEiyAgNUiLNeeJlddVYQgAASSECAAAOigA==
Date: Wed, 10 Jul 2013 07:55:38 +0000
Message-ID: <59B7D431F843564FBE967123924AD2AB0FD6AF52@BY2PRD0510MB376.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [116.197.178.91]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-OriginatorOrg: juniper.net
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Jul 2013 07:55:56 -0000

SGkgQWxsLA0KDQpZZXN0ZXJkYXkgd2UgcG9zdGVkIGEgbmV3IGRyYWZ0IG9uIFJlbW90ZS1MRkEg
Tm9kZSBQcm90ZWN0aW9uIGFuZCBNYW5hZ2VhYmlsaXR5IGFuZCB3b3VsZCBsaWtlIHRvIGhlYXIg
eW91ciB2aWV3cyBvbiBpdC4gUGxlYXNlIGZlZWwgZnJlZSB0byByYWlzZSBhbnkgc3VnZ2VzdGlv
bi9jb21tZW50IG9uIHRoZSBjb250ZW50Lg0KDQpCZXN0IFJlZ2FyZHMsCQ0KUHVzaHBhc2lzDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v
cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVHVlc2RheSwgSnVs
eSAwOSwgMjAxMyAyOjI4IFBNDQpUbzogSGFyaXNoIFJhZ2h1dmVlcjsgU2hyYWRkaGEgSGVnZGU7
IEhhbm5lcyBHcmVkbGVyOyBQdXNocGFzaXMgU2Fya2FyOyBwc2Fya2FyQA0KU3ViamVjdDogTmV3
IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1wc2Fya2FyLXJ0Z3dnLXJsZmEtbm9kZS1w
cm90ZWN0aW9uLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1wc2Fya2Fy
LXJ0Z3dnLXJsZmEtbm9kZS1wcm90ZWN0aW9uLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5
IHN1Ym1pdHRlZCBieSBQdXNocGFzaXMgU2Fya2FyIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw
b3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1wc2Fya2FyLXJ0Z3dnLXJsZmEtbm9kZS1wcm90
ZWN0aW9uDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBOb2RlIFByb3RlY3RpbmcgUi1MRkEgYW5k
IE1hbmFnZWFiaWxpdHkNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA3LTA4DQpHcm91cDoJCSBJbmRp
dmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTENClVSTDogICAgICAgICAgICAg
aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcHNhcmthci1ydGd3Zy1y
bGZhLW5vZGUtcHJvdGVjdGlvbi0wMS50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wc2Fya2FyLXJ0Z3dnLXJsZmEtbm9kZS1wcm90ZWN0
aW9uDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBz
YXJrYXItcnRnd2ctcmxmYS1ub2RlLXByb3RlY3Rpb24tMDENCkRpZmY6ICAgICAgICAgICAgaHR0
cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcHNhcmthci1ydGd3Zy1ybGZhLW5v
ZGUtcHJvdGVjdGlvbi0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoZSBsb29wLWZyZWUgYWx0ZXJuYXRl
cyBjb21wdXRlZCBmb2xsb3dpbmcgdGhlIGN1cnJlbnQgUmVtb3RlLUxGQQ0KICAgW0ktRC5pZXRm
LXJ0Z3dnLXJlbW90ZS1sZmFdIHNwZWNpZmljYXRpb24gZ2F1cmFudGVlcyBvbmx5IGxpbmstDQog
ICBwcm90ZWN0aW9uLiAgVGhlIHJlc3VsdGluZyBSZW1vdGUtTEZBIG5leHRob3BzIChhbHNvIGNh
bGxlZCBQUS0NCiAgIG5vZGVzKSwgbWF5IG5vdCBnYXVyYW50ZWUgbm9kZS1wcm90ZWN0aW9uIGZv
ciBhbGwgZGVzdGluYXRpb25zIGJlaW5nDQogICBwcm90ZWN0ZWQgYnkgaXQuDQoNCiAgIFRoaXMg
ZG9jdW1lbnQgZGVzY3JpYmVzIHByb2NlZHVyZXMgZm9yIGRldGVybWluaW5nIGlmIGEgZ2l2ZW4g
UFEtbm9kZQ0KICAgcHJvdmlkZXMgbm9kZS1wcm90ZWN0aW9uIGZvciBhIHNwZWNpZmljIGRlc3Rp
bmF0aW9uIG9yIG5vdC4gIFRoZQ0KICAgZG9jdW1lbnQgYWxzbyBzaG93cyBob3cgdGhlIHNhbWUg
cHJvY2VkdXJlIGNhbiBiZSB1dGlsaXNlZCBmb3INCiAgIGNvbGxlY3Rpb24gb2YgY29tcGxldGUg
Y2hhcmFjdGVyaXN0aWNzIGZvciBhbHRlcm5hdGUgcGF0aHMuDQogICBLbm93bGVkZ2UgYWJvdXQg
dGhlIGNoYXJhY3RlcmlzdGljcyBvZiBhbGwgYWx0ZXJuYXRlIHBhdGggaXMNCiAgIHByZWN1cnNv
cnkgdG8gYXBwbHkgb3BlcmF0b3IgZGVmaW5lZCBwb2xpY3kgZm9yIGVsaW1pbmF0aW5nIHBhdGhz
IG5vdA0KICAgZml0dGluZyBjb25zdHJhaW50cy4NCg0KDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCg==



From russw@riw.us  Wed Jul 10 05:33:06 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7091111E812D for ; Wed, 10 Jul 2013 05:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.16
X-Spam-Level: 
X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[AWL=-0.975,  BAYES_40=-0.185]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IliKHQHIlo9a for ; Wed, 10 Jul 2013 05:33:00 -0700 (PDT)
Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0138A21F9AFE for ; Wed, 10 Jul 2013 05:32:51 -0700 (PDT)
Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1UwtZi-0007mL-DC; Wed, 10 Jul 2013 05:32:50 -0700
From: "Russ White" 
To: "'Pushpasis Sarkar'" , 
References: <59B7D431F843564FBE967123924AD2AB0FD6AF52@BY2PRD0510MB376.namprd05.prod.outlook.com>
In-Reply-To: <59B7D431F843564FBE967123924AD2AB0FD6AF52@BY2PRD0510MB376.namprd05.prod.outlook.com>
Subject: RE: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt
Date: Wed, 10 Jul 2013 08:33:03 -0400
Message-ID: <009a01ce7d69$a01c2440$e0546cc0$@riw.us>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQLQgvtJ/Gj+vEkBTJCSoa2T+hHc85dZzL5Q
Content-Language: en-us
X-Antivirus-Scanner: Seems clean.  You should still use an Antivirus Scanner
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Jul 2013 12:33:06 -0000

> Yesterday we posted a new draft on Remote-LFA Node Protection and
> Manageability and would like to hear your views on it. Please feel free to
> raise any suggestion/comment on the content.

Very interesting... I was trying to work out if this might also provide
better coverage in non-planar topologies, or even if there might be a way to
extend this to finding flooding domain boundaries, and hence to being able
to at least route to alternate boundary routers, rather than leaving things
completely unprotected. Haven't had the chance to sit down and go through
these areas in detail, but it's probably worth thinking about.

:-)

Russ




From psarkar@juniper.net  Wed Jul 10 07:18:53 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D840E21E8085 for ; Wed, 10 Jul 2013 07:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Level: 
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[AWL=-0.734, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 453mMH-V5M+s for ; Wed, 10 Jul 2013 07:18:47 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id A9DC621E8054 for ; Wed, 10 Jul 2013 07:18:46 -0700 (PDT)
Received: from mail201-db8-R.bigfish.com (10.174.8.227) by DB8EHSOBE030.bigfish.com (10.174.4.93) with Microsoft SMTP Server id 14.1.225.22; Wed, 10 Jul 2013 14:18:45 +0000
Received: from mail201-db8 (localhost [127.0.0.1])	by mail201-db8-R.bigfish.com (Postfix) with ESMTP id C5126BA010C	for ; Wed, 10 Jul 2013 14:18:45 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: -22
X-BigFish: VPS-22(zz9371I542Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail201-db8: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=psarkar@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail201-db8 (localhost.localdomain [127.0.0.1]) by mail201-db8 (MessageSwitch) id 1373465923773224_1419; Wed, 10 Jul 2013 14:18:43 +0000 (UTC)
Received: from DB8EHSMHS018.bigfish.com (unknown [10.174.8.243])	by mail201-db8.bigfish.com (Postfix) with ESMTP id B8307980045	for ; Wed, 10 Jul 2013 14:18:43 +0000 (UTC)
Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.53) by DB8EHSMHS018.bigfish.com (10.174.4.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 10 Jul 2013 14:18:39 +0000
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Jul 2013 07:18:04 -0700
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 10 Jul 2013 07:18:04 -0700
Received: from va3outboundpool.messaging.microsoft.com (216.32.180.11) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 10 Jul 2013 07:30:43 -0700
Received: from mail148-va3-R.bigfish.com (10.7.14.234) by VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id 14.1.225.22; Wed, 10 Jul 2013 14:18:00 +0000
Received: from mail148-va3 (localhost [127.0.0.1])	by mail148-va3-R.bigfish.com (Postfix) with ESMTP id 6FEBF4C02DC	for ; Wed, 10 Jul 2013 14:18:00 +0000 (UTC)
Received: from mail148-va3 (localhost.localdomain [127.0.0.1]) by mail148-va3 (MessageSwitch) id 137346587911014_6976; Wed, 10 Jul 2013 14:17:59 +0000 (UTC)
Received: from VA3EHSMHS033.bigfish.com (unknown [10.7.14.232])	by mail148-va3.bigfish.com (Postfix) with ESMTP id E16BC3E004B; Wed, 10 Jul 2013 14:17:58 +0000 (UTC)
Received: from BY2PRD0510HT003.namprd05.prod.outlook.com (157.56.236.101) by VA3EHSMHS033.bigfish.com (10.7.99.43) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Jul 2013 14:17:53 +0000
Received: from BY2PRD0510MB376.namprd05.prod.outlook.com ([169.254.5.169]) by BY2PRD0510HT003.namprd05.prod.outlook.com ([10.255.84.38]) with mapi id 14.16.0324.000; Wed, 10 Jul 2013 14:17:51 +0000
From: Pushpasis Sarkar 
To: Russ White , "rtgwg@ietf.org" 
Subject: RE: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt
Thread-Topic: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt
Thread-Index: AQHOfIKn6PGYkVy4YEiyAgNUiLNeeJlddVYQgAASSECAAAOigIAATviAgAAYTqA=
Date: Wed, 10 Jul 2013 14:17:51 +0000
Message-ID: <59B7D431F843564FBE967123924AD2AB0FD6C133@BY2PRD0510MB376.namprd05.prod.outlook.com>
References: <59B7D431F843564FBE967123924AD2AB0FD6AF52@BY2PRD0510MB376.namprd05.prod.outlook.com> <009a01ce7d69$a01c2440$e0546cc0$@riw.us>
In-Reply-To: <009a01ce7d69$a01c2440$e0546cc0$@riw.us>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [116.197.178.91]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%RIW.US$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Jul 2013 14:18:54 -0000

Hi Russ,

Good to know that you found it interesting. Theoretically the mechanism pro=
posed in our draft does not find more coverage than what standard R-LFA doe=
s.=20

However we would also like to hear more on your idea on how this can be ext=
ended to find better coverage in non-planar topologies (not sure I understo=
od the problem statement). Illustrating with an example (if possible) will =
help us understand the problem. And then probably can start thinking on suc=
h possibility :)

Thanks and Regards,
-Pushpasis



-----Original Message-----
From: Russ White [mailto:russw@riw.us]=20
Sent: Wednesday, July 10, 2013 6:03 PM
To: Pushpasis Sarkar; rtgwg@ietf.org
Subject: RE: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-=
01.txt


> Yesterday we posted a new draft on Remote-LFA Node Protection and=20
> Manageability and would like to hear your views on it. Please feel=20
> free to raise any suggestion/comment on the content.

Very interesting... I was trying to work out if this might also provide bet=
ter coverage in non-planar topologies, or even if there might be a way to e=
xtend this to finding flooding domain boundaries, and hence to being able t=
o at least route to alternate boundary routers, rather than leaving things =
completely unprotected. Haven't had the chance to sit down and go through t=
hese areas in detail, but it's probably worth thinking about.

:-)

Russ








From internet-drafts@ietf.org  Thu Jul 11 16:05:14 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58F811E81CE; Thu, 11 Jul 2013 16:05:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level: 
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbC4pNSgadu5; Thu, 11 Jul 2013 16:05:14 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2795411E8136; Thu, 11 Jul 2013 16:05:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action: draft-ietf-rtgwg-cl-requirement-11.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130711230513.18815.9697.idtracker@ietfa.amsl.com>
Date: Thu, 11 Jul 2013 16:05:13 -0700
Cc: rtgwg@ietf.org
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Jul 2013 23:05:15 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Routing Area Working Group Working Group =
of the IETF.

	Title           : Requirements for Advanced Multipath in MPLS Networks
	Author(s)       : Curtis Villamizar
                          Dave McDysan
                          So Ning
                          Andrew Malis
                          Lucy Yong
	Filename        : draft-ietf-rtgwg-cl-requirement-11.txt
	Pages           : 16
	Date            : 2013-07-11

Abstract:
   This document provides a set of requirements for Advanced Multipath
   in MPLS Networks.

   Advanced Multipath is a formalization of multipath techniques
   currently in use in IP and MPLS networks and a set of extensions to
   existing multipath techniques.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-requirement

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-cl-requirement-11


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From ke-kumaki@kddi.com  Thu Jul 11 20:23:19 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C011D11E80E7 for ; Thu, 11 Jul 2013 20:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xidmI4Kghmjp for ; Thu, 11 Jul 2013 20:23:15 -0700 (PDT)
Received: from UTMC1104.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4EC11E80A2 for ; Thu, 11 Jul 2013 20:23:14 -0700 (PDT)
Received: from UTMC1136 (unknown [10.5.16.207]) by UTMC1104.kddi.com (Postfix) with SMTP id 6F37B2958 for ; Fri, 12 Jul 2013 12:22:54 +0900 (JST)
Received: from UTMC1124.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id EA0981C10 for ; Fri, 12 Jul 2013 12:22:49 +0900 (JST)
Received: from LTMC1004.kddi.com (unknown [10.5.16.215]) by UTMC1124.kddi.com (Postfix) with ESMTP id CF0481B96 for ; Fri, 12 Jul 2013 12:22:49 +0900 (JST)
Received: from LTMC1004.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1004.kddi.com  with ESMTP id r6C3MnPc002407 for ; Fri, 12 Jul 2013 12:22:49 +0900
Received: from LTMC1004.kddi.com.mid_19227597 (localhost.localdomain [127.0.0.1]) by LTMC1004.kddi.com  with ESMTP id r6C3MLcL002239 for ; Fri, 12 Jul 2013 12:22:22 +0900
Received: from KDDI1202PC0730 ([10.200.129.120] [10.200.129.120]) by post-zip.kddi.com with ESMTPA; Fri, 12 Jul 2013 12:22:21 +0900
From: "Kenji Kumaki" 
To: 
References: <20130711083436.6145.25676.idtracker@ietfa.amsl.com>
In-Reply-To: <20130711083436.6145.25676.idtracker@ietfa.amsl.com>
Subject: FW: I-D Action: draft-kumaki-vnef-01.txt
Date: Fri, 12 Jul 2013 12:22:21 +0900
Message-Id: <001e01ce7eaf$057344e0$1059cea0$@kddi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGXn1SWBQARtZZn4rfHXCQRs0/DnpnOEC1Q
Content-Language: ja
X-SA-MID: 19227597
X-WAuditID: 1307121222500000617786
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Jul 2013 03:23:19 -0000

Hi,

We submitted the following draft. WG comments would be highly appreciated.
Actually, we want to know if this draft should be discussed in this WG.

Thanks,
Kenji


---
Kenji Kumaki,Ph.D. 
Head of IP & Optical Core Networks
IP Transport Network Development Department



-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: Thursday, July 11, 2013 5:35 PM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-kumaki-vnef-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title           : A Virtualized Network Element Framework
	Author(s)       : Kenji Kumaki
                          Pradosh Mohapatra
                          David Meyer
                          Kannan Varadhan
                          Zafar Ali
	Filename        : draft-kumaki-vnef-01.txt
	Pages           : 16
	Date            : 2013-07-11

Abstract:
   This document outlines a new architectural paradigm of virtualizing
   the service provider networks and its associated engineering
   requirements.  The framework is referred to as the virtual network
   element framework (VNEF) in the document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-kumaki-vnef

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-kumaki-vnef-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-kumaki-vnef-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From internet-drafts@ietf.org  Fri Jul 12 10:36:50 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A6121F9F1D; Fri, 12 Jul 2013 10:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.533
X-Spam-Level: 
X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL5pgqwZ1IKE; Fri, 12 Jul 2013 10:36:49 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD2B21F9E22; Fri, 12 Jul 2013 10:36:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action: draft-ietf-rtgwg-mrt-frr-architecture-03.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130712173649.16498.51457.idtracker@ietfa.amsl.com>
Date: Fri, 12 Jul 2013 10:36:49 -0700
Cc: rtgwg@ietf.org
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Jul 2013 17:36:50 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Routing Area Working Group Working Group =
of the IETF.

	Title           : An Architecture for IP/LDP Fast-Reroute Using Maximally =
Redundant Trees
	Author(s)       : Alia Atlas
                          Robert Kebler
                          Gabor Sandor Enyedi
                          Andras Csaszar
                          Jeff Tantsura
                          Maciek Konstantynowicz
                          Russ White
	Filename        : draft-ietf-rtgwg-mrt-frr-architecture-03.txt
	Pages           : 29
	Date            : 2013-07-12

Abstract:
   With increasing deployment of Loop-Free Alternates (LFA) [RFC5286],
   it is clear that a complete solution for IP and LDP Fast-Reroute is
   required.  This specification provides that solution.  IP/LDP Fast-
   Reroute with Maximally Redundant Trees (MRT-FRR) is a technology that
   gives link-protection and node-protection with 100% coverage in any
   network topology that is still connected after the failure.

   MRT removes all need to engineer for coverage.  MRT is also extremely
   computationally efficient.  For any router in the network, the MRT
   computation is less than the LFA computation for a node with three or
   more neighbors.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-architecture

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-mrt-frr-architecture-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-mrt-frr-architecture-03


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From akatlas@juniper.net  Fri Jul 12 10:40:39 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159F111E8171 for ; Fri, 12 Jul 2013 10:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.583
X-Spam-Level: 
X-Spam-Status: No, score=0.583 tagged_above=-999 required=5 tests=[AWL=0.009,  BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSMbmJvC7xFh for ; Fri, 12 Jul 2013 10:40:34 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id 88A3011E817D for ; Fri, 12 Jul 2013 10:40:30 -0700 (PDT)
Received: from mail55-db8-R.bigfish.com (10.174.8.250) by DB8EHSOBE036.bigfish.com (10.174.4.99) with Microsoft SMTP Server id 14.1.225.22; Fri, 12 Jul 2013 17:40:29 +0000
Received: from mail55-db8 (localhost [127.0.0.1])	by mail55-db8-R.bigfish.com (Postfix) with ESMTP id 743103A03B2	for ; Fri, 12 Jul 2013 17:40:29 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: -24
X-BigFish: VPS-24(zz9371I936eI542I4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail55-db8: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=akatlas@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail55-db8 (localhost.localdomain [127.0.0.1]) by mail55-db8 (MessageSwitch) id 1373650827205351_1742; Fri, 12 Jul 2013 17:40:27 +0000 (UTC)
Received: from DB8EHSMHS006.bigfish.com (unknown [10.174.8.243])	by mail55-db8.bigfish.com (Postfix) with ESMTP id 24B22380071	for ; Fri, 12 Jul 2013 17:40:27 +0000 (UTC)
Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.52) by DB8EHSMHS006.bigfish.com (10.174.4.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 12 Jul 2013 17:40:25 +0000
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 12 Jul 2013 10:40:22 -0700
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 12 Jul 2013 10:40:21 -0700
Received: from va3outboundpool.messaging.microsoft.com (216.32.180.14) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 12 Jul 2013 10:53:02 -0700
Received: from mail102-va3-R.bigfish.com (10.7.14.234) by VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id 14.1.225.22; Fri, 12 Jul 2013 17:40:20 +0000
Received: from mail102-va3 (localhost [127.0.0.1])	by mail102-va3-R.bigfish.com (Postfix) with ESMTP id C3A4F6036F	for ; Fri, 12 Jul 2013 17:40:20 +0000 (UTC)
Received: from mail102-va3 (localhost.localdomain [127.0.0.1]) by mail102-va3 (MessageSwitch) id 1373650806122049_27963; Fri, 12 Jul 2013 17:40:06 +0000 (UTC)
Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.231])	by mail102-va3.bigfish.com (Postfix) with ESMTP id 0FA8DC008E	for ; Fri, 12 Jul 2013 17:40:06 +0000 (UTC)
Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 12 Jul 2013 17:40:05 +0000
Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.99]) by BY2PRD0510HT005.namprd05.prod.outlook.com ([10.255.84.40]) with mapi id 14.16.0324.000; Fri, 12 Jul 2013 17:39:50 +0000
From: Alia Atlas 
To: "rtgwg@ietf.org" 
Subject: FW: New Version Notification for draft-ietf-rtgwg-mrt-frr-architecture-03.txt
Thread-Topic: New Version Notification for draft-ietf-rtgwg-mrt-frr-architecture-03.txt
Thread-Index: AQHOfyaVPC0NLGE3C0ag/yQGBXs5tZlhTvlg
Date: Fri, 12 Jul 2013 17:39:49 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.232.2]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Jul 2013 17:40:39 -0000

KHdnLWNoYWlyIGhhdCBvZmYpDQoNCkknZCBiZSBpbnRlcmVzdGVkIGluIGZlZWRiYWNrIGFuZCBy
ZXZpZXcgb2YgdGhlIHVwZGF0ZWQgZHJhZnQtaWV0Zi1ydGd3Zy1tcnQtZnJyLWFyY2hpdGVjdHVy
ZS0wMy4gICBJdCBoYXMgYmVlbiBzaWduaWZpY2FudGx5IHJld3JpdHRlbiBhbmQgc29tZSBzaW1w
bGlmaWNhdGlvbnMgbWFkZS4NCkkgdGhpbmsgaXQgbm93IGRlc2NyaWJlcyBhIGZ1bGx5IGltcGxl
bWVudGFibGUgc29sdXRpb24uDQoNClRoYW5rcywNCkFsaWENCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0
LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIEp1bHkgMTIsIDIwMTMgMTozNyBQTQ0K
VG86IEdhYm9yIFNhbmRvciBFbnZlZGk7IEFuZHJhcyBDc2FzemFyOyBBbGlhIEF0bGFzOyBNYWNp
ZWsgS29uc3RhbnR5bm93aWN6OyBKZWZmIFRhbnRzdXJhOyBSb2JlcnQgS2VibGVyOyBSdXNzIFdo
aXRlOyBHYWJvciBTYW5kb3IgRW55ZWRpOyBBbmRyYXMgQ3Nhc3phcg0KU3ViamVjdDogTmV3IFZl
cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXJ0Z3dnLW1ydC1mcnItYXJjaGl0ZWN0
dXJlLTAzLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXJ0Z3dnLW1y
dC1mcnItYXJjaGl0ZWN0dXJlLTAzLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl
ZCBieSBBbGlhIEF0bGFzIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmls
ZW5hbWU6CSBkcmFmdC1pZXRmLXJ0Z3dnLW1ydC1mcnItYXJjaGl0ZWN0dXJlDQpSZXZpc2lvbjoJ
IDAzDQpUaXRsZToJCSBBbiBBcmNoaXRlY3R1cmUgZm9yIElQL0xEUCBGYXN0LVJlcm91dGUgVXNp
bmcgTWF4aW1hbGx5IFJlZHVuZGFudCBUcmVlcw0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDctMTIN
Ckdyb3VwOgkJIHJ0Z3dnDQpOdW1iZXIgb2YgcGFnZXM6IDI5DQpVUkw6ICAgICAgICAgICAgIGh0
dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcnRnd2ctbXJ0LWZy
ci1hcmNoaXRlY3R1cmUtMDMudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tl
ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGd3Zy1tcnQtZnJyLWFyY2hpdGVjdHVyZQ0KSHRt
bGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Z3dn
LW1ydC1mcnItYXJjaGl0ZWN0dXJlLTAzDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0
Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcnRnd2ctbXJ0LWZyci1hcmNoaXRlY3R1cmUt
MDMNCg0KQWJzdHJhY3Q6DQogICBXaXRoIGluY3JlYXNpbmcgZGVwbG95bWVudCBvZiBMb29wLUZy
ZWUgQWx0ZXJuYXRlcyAoTEZBKSBbUkZDNTI4Nl0sDQogICBpdCBpcyBjbGVhciB0aGF0IGEgY29t
cGxldGUgc29sdXRpb24gZm9yIElQIGFuZCBMRFAgRmFzdC1SZXJvdXRlIGlzDQogICByZXF1aXJl
ZC4gIFRoaXMgc3BlY2lmaWNhdGlvbiBwcm92aWRlcyB0aGF0IHNvbHV0aW9uLiAgSVAvTERQIEZh
c3QtDQogICBSZXJvdXRlIHdpdGggTWF4aW1hbGx5IFJlZHVuZGFudCBUcmVlcyAoTVJULUZSUikg
aXMgYSB0ZWNobm9sb2d5IHRoYXQNCiAgIGdpdmVzIGxpbmstcHJvdGVjdGlvbiBhbmQgbm9kZS1w
cm90ZWN0aW9uIHdpdGggMTAwJSBjb3ZlcmFnZSBpbiBhbnkNCiAgIG5ldHdvcmsgdG9wb2xvZ3kg
dGhhdCBpcyBzdGlsbCBjb25uZWN0ZWQgYWZ0ZXIgdGhlIGZhaWx1cmUuDQoNCiAgIE1SVCByZW1v
dmVzIGFsbCBuZWVkIHRvIGVuZ2luZWVyIGZvciBjb3ZlcmFnZS4gIE1SVCBpcyBhbHNvIGV4dHJl
bWVseQ0KICAgY29tcHV0YXRpb25hbGx5IGVmZmljaWVudC4gIEZvciBhbnkgcm91dGVyIGluIHRo
ZSBuZXR3b3JrLCB0aGUgTVJUDQogICBjb21wdXRhdGlvbiBpcyBsZXNzIHRoYW4gdGhlIExGQSBj
b21wdXRhdGlvbiBmb3IgYSBub2RlIHdpdGggdGhyZWUgb3INCiAgIG1vcmUgbmVpZ2hib3JzLg0K
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K
DQoNCg==



From internet-drafts@ietf.org  Sat Jul 13 18:19:13 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAC821F9EF3; Sat, 13 Jul 2013 18:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level: 
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51DkDwaiq9zL; Sat, 13 Jul 2013 18:19:13 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1EE421F9DD5; Sat, 13 Jul 2013 18:19:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action: draft-ietf-rtgwg-cl-use-cases-04.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130714011912.11968.14468.idtracker@ietfa.amsl.com>
Date: Sat, 13 Jul 2013 18:19:12 -0700
Cc: rtgwg@ietf.org
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 14 Jul 2013 01:19:13 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Routing Area Working Group Working Group =
of the IETF.

	Title           : Advannced Multipath Use Cases and Design Considerations
	Author(s)       : So Ning
                          Andrew Malis
                          Dave McDysan
                          Lucy Yong
                          Curtis Villamizar
	Filename        : draft-ietf-rtgwg-cl-use-cases-04.txt
	Pages           : 25
	Date            : 2013-07-13

Abstract:
   This document provides a set of use cases and design considerations
   for Advanced Multipath.

   Advanced Multipath is a formalization of multipath techniques
   currently in use in IP and MPLS networks and a set of extensions to
   existing multipath techniques.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-use-cases

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-cl-use-cases-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-cl-use-cases-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From curtis@ipv6.occnc.com  Sat Jul 13 20:43:27 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D2921F9B53 for ; Sat, 13 Jul 2013 20:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.011
X-Spam-Level: *
X-Spam-Status: No, score=1.011 tagged_above=-999 required=5 tests=[AWL=-0.256,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  MISSING_SUBJECT=1.762, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k94YYNLnXuhy for ; Sat, 13 Jul 2013 20:43:23 -0700 (PDT)
Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 1B50621F9F9B for ; Sat, 13 Jul 2013 20:43:22 -0700 (PDT)
Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r6E3g36s013502; Sat, 13 Jul 2013 23:42:03 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201307140342.r6E3g36s013502@gateway1.orleans.occnc.com>
To: rtgwg@ietf.org
Subject: 
From: Curtis Villamizar 
Date: Sat, 13 Jul 2013 23:42:03 -0400
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: curtis@ipv6.occnc.com
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 14 Jul 2013 03:43:27 -0000

RTGWG,

The Composite Link work is being renamed to Advanced Multipath.  This
is a result of the Routing Directorate (RtgDir) Review and a decision
made by the Responsible AD.

The concern over use of the terms NPO and Composite Link were that
both terms are defined by the ITU-T and were being used differently.

The use of NPO in these document was clearly in conflict with the
strict definition of NPO in Y.1540 and Y.1541.  The term "Performance
Objective" is now defined and used in its place.

The term Composite Link is defined in G.800.  Its use in these
documents was very similar, but excluding inverse-multiplexing.  It
could be interpretted by ITU-T that IETF is redefining Composite Link,
a term that they may feel is theirs much as IETF has insisted that
MPLS is to be defined by IETF.  The IETF does not want to expend
political capital on this, hence the name change.

The new draft-ietf-rtgwg-cl-requirement-11 "Requirements for Advanced
Multipath in MPLS Networks" reflects other comments and discussion
following the RtgDir review.

The new draft-ietf-rtgwg-cl-use-cases-04 "Advannced Multipath Use
Cases and Design Considerations" has been edited to remove the use of
the terms NPO and Composite Link, to move definitions to the
Requirements draft, and to move the "Assumptions" section from the
Requirements draft to the Use Cases draft.

I will try to have the Framework draft updated by the Tuesday
deadline.  Changes will also reflect the progress on performance
metrics (delay, jitter, loss) in the OSPF, ISIS, and TE-express-path
drafts.

Curtis


------- Forwarded Messages

From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action: draft-ietf-rtgwg-cl-requirement-11.txt
Message-ID: <20130711230513.18815.9697.idtracker@ietfa.amsl.com>
Date: Thu, 11 Jul 2013 16:05:13 -0700
Cc: rtgwg@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts
directories.  This draft is a work item of the Routing Area Working
Group Working Group of the IETF.

	Title           : Requirements for Advanced Multipath in MPLS
			  Networks
	Author(s)       : Curtis Villamizar
                          Dave McDysan
                          So Ning
                          Andrew Malis
                          Lucy Yong
	Filename        : draft-ietf-rtgwg-cl-requirement-11.txt
	Pages           : 16
	Date            : 2013-07-11

Abstract:
   This document provides a set of requirements for Advanced Multipath
   in MPLS Networks.

   Advanced Multipath is a formalization of multipath techniques
   currently in use in IP and MPLS networks and a set of extensions to
   existing multipath techniques.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-requirement

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-cl-requirement-11


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

------- Message 2

From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action: draft-ietf-rtgwg-cl-use-cases-04.txt
Message-ID: <20130714011912.11968.14468.idtracker@ietfa.amsl.com>
Date: Sat, 13 Jul 2013 18:19:12 -0700
Cc: rtgwg@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts
 directories.  This draft is a work item of the Routing Area Working
 Group Working Group of the IETF.

	Title           : Advannced Multipath Use Cases and Design
			  Considerations
	Author(s)       : So Ning
                          Andrew Malis
                          Dave McDysan
                          Lucy Yong
                          Curtis Villamizar
	Filename        : draft-ietf-rtgwg-cl-use-cases-04.txt
	Pages           : 25
	Date            : 2013-07-13

Abstract:
   This document provides a set of use cases and design considerations
   for Advanced Multipath.

   Advanced Multipath is a formalization of multipath techniques
   currently in use in IP and MPLS networks and a set of extensions to
   existing multipath techniques.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-use-cases

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-cl-use-cases-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-cl-use-cases-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

------- End of Forwarded Messages


From internet-drafts@ietf.org  Mon Jul 15 12:33:06 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF9011E81DD; Mon, 15 Jul 2013 12:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.536
X-Spam-Level: 
X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLG0KyO6TGvg; Mon, 15 Jul 2013 12:33:05 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF3421E811D; Mon, 15 Jul 2013 12:32:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action: draft-ietf-rtgwg-cl-framework-04.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130715193244.31272.77332.idtracker@ietfa.amsl.com>
Date: Mon, 15 Jul 2013 12:32:44 -0700
Cc: rtgwg@ietf.org
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jul 2013 19:33:07 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Routing Area Working Group Working Group =
of the IETF.

	Title           : Advanced Multipath Framework in MPLS
	Author(s)       : So Ning
                          Dave McDysan
                          Eric Osborne
                          Lucy Yong
                          Curtis Villamizar
	Filename        : draft-ietf-rtgwg-cl-framework-04.txt
	Pages           : 43
	Date            : 2013-07-15

Abstract:
   This document specifies a framework for support of Advanced Multipath
   in MPLS networks.  As defined in this framework, an Advanced
   Multipath consists of a group of homogenous or non-homogenous links
   that have the same forward adjacency (FA) and can be considered as a
   single TE link or an IP link when advertised into IGP routing.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-framework

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-cl-framework-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-cl-framework-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From curtis@ipv6.occnc.com  Mon Jul 15 12:49:42 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BA121E817D for ; Mon, 15 Jul 2013 12:49:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.181
X-Spam-Level: 
X-Spam-Status: No, score=0.181 tagged_above=-999 required=5 tests=[AWL=0.676,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLBVjxCoKqqJ for ; Mon, 15 Jul 2013 12:49:38 -0700 (PDT)
Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id E861221E8173 for ; Mon, 15 Jul 2013 12:49:32 -0700 (PDT)
Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r6FJmCRe032959; Mon, 15 Jul 2013 15:48:13 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201307151948.r6FJmCRe032959@gateway1.orleans.occnc.com>
To: rtgwg@ietf.org
Subject: draft-ietf-rtgwg-cl-framework-04
From: Curtis Villamizar 
Date: Mon, 15 Jul 2013 15:48:12 -0400
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: curtis@ipv6.occnc.com
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jul 2013 19:49:42 -0000

There were some minor changes to what is now called the "Advanced
Multipath Framework in MPLS".  Mostly the changes reflect the
terminology changes made in the Requirements and Use Cases drafts.

Note that the "Assumptions" section moved from Requirements to Use
Cases and therefore one of the bullet items in the Issues section is
gone.

Curtis


------- Forwarded Message

From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action: draft-ietf-rtgwg-cl-framework-04.txt
Message-ID: <20130715193244.31272.77332.idtracker@ietfa.amsl.com>
Date: Mon, 15 Jul 2013 12:32:44 -0700
Cc: rtgwg@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts
 directories.  This draft is a work item of the Routing Area Working
 Group Working Group of the IETF.

	Title           : Advanced Multipath Framework in MPLS
	Author(s)       : So Ning
                          Dave McDysan
                          Eric Osborne
                          Lucy Yong
                          Curtis Villamizar
	Filename        : draft-ietf-rtgwg-cl-framework-04.txt
	Pages           : 43
	Date            : 2013-07-15

Abstract:
   This document specifies a framework for support of Advanced Multipath
   in MPLS networks.  As defined in this framework, an Advanced
   Multipath consists of a group of homogenous or non-homogenous links
   that have the same forward adjacency (FA) and can be considered as a
   single TE link or an IP link when advertised into IGP routing.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-framework

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-cl-framework-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-cl-framework-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

------- End of Forwarded Message


From akatlas@juniper.net  Mon Jul 15 16:25:19 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6DF11E81CC for ; Mon, 15 Jul 2013 16:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.133
X-Spam-Level: 
X-Spam-Status: No, score=-0.133 tagged_above=-999 required=5 tests=[AWL=0.333,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yb7aF7Erwg50 for ; Mon, 15 Jul 2013 16:25:14 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id E0FA721F9E0A for ; Mon, 15 Jul 2013 16:25:13 -0700 (PDT)
Received: from mail137-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.22; Mon, 15 Jul 2013 23:25:13 +0000
Received: from mail137-co1 (localhost [127.0.0.1])	by mail137-co1-R.bigfish.com (Postfix) with ESMTP id 3DA293800B6	for ; Mon, 15 Jul 2013 23:25:13 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: -22
X-BigFish: PS-22(zf7Izbb2dI9371I936eIc85fhzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL17326ah18c673h18de19h8275bh8275dhz2fh2a8h683h839hd24hf0ah10d2h1288h12a5h12bdh137ah1441h1537h153bh162dh1631h1758h18deh18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh17ej1155h)
Received-SPF: pass (mail137-co1: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=akatlas@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail137-co1 (localhost.localdomain [127.0.0.1]) by mail137-co1 (MessageSwitch) id 1373930710712551_19029; Mon, 15 Jul 2013 23:25:10 +0000 (UTC)
Received: from CO1EHSMHS028.bigfish.com (unknown [10.243.78.249])	by mail137-co1.bigfish.com (Postfix) with ESMTP id A0D2544020A	for ; Mon, 15 Jul 2013 23:25:10 +0000 (UTC)
Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.50) by CO1EHSMHS028.bigfish.com (10.243.66.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 15 Jul 2013 23:25:10 +0000
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 15 Jul 2013 16:25:09 -0700
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.123.3; Mon, 15 Jul 2013 16:25:09 -0700
Received: from va3outboundpool.messaging.microsoft.com (216.32.180.14) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 15 Jul 2013 16:29:40 -0700
Received: from mail50-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.22; Mon, 15 Jul 2013 23:25:08 +0000
Received: from mail50-va3 (localhost [127.0.0.1])	by mail50-va3-R.bigfish.com (Postfix) with ESMTP id 39B063002FD	for ; Mon, 15 Jul 2013 23:25:08 +0000 (UTC)
Received: from mail50-va3 (localhost.localdomain [127.0.0.1]) by mail50-va3 (MessageSwitch) id 1373930706560934_4277; Mon, 15 Jul 2013 23:25:06 +0000 (UTC)
Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.232])	by mail50-va3.bigfish.com (Postfix) with ESMTP id 832B22E0238	for ; Mon, 15 Jul 2013 23:25:06 +0000 (UTC)
Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 15 Jul 2013 23:24:59 +0000
Received: from CH1PRD0510MB392.namprd05.prod.outlook.com ([169.254.6.46]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0329.000; Mon, 15 Jul 2013 23:24:58 +0000
From: Alia Atlas 
To: "rtgwg@ietf.org" 
Subject: Fwd: New Version Notification for draft-enyedi-rtgwg-mrt-frr-algorithm-03.txt
Thread-Topic: New Version Notification for draft-enyedi-rtgwg-mrt-frr-algorithm-03.txt
Thread-Index: AQHOgbHYZH7siLJxbEmkGhbiE/bVkJlmYaZ5
Date: Mon, 15 Jul 2013 23:24:58 +0000
Message-ID: 
References: <20130715231910.14147.19328.idtracker@ietfa.amsl.com>
In-Reply-To: <20130715231910.14147.19328.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [::]
Content-Type: multipart/alternative; boundary="_000_asukrf5p5uqypw91tr23sat61373930688121emailandroidcom_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-OriginatorOrg: juniper.net
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Alia Atlas 
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jul 2013 23:25:19 -0000

--_000_asukrf5p5uqypw91tr23sat61373930688121emailandroidcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

(WG chair hat off)

We have updated draft-enyedi-rtgwg-mrt-frr-algorithm-03.txt and added an an=
alysis and comparison.

Discussion would be welcome.
Regards,
Alia



-------- Original message --------
From: internet-drafts@ietf.org
Date: 07/15/2013 4:20 PM (GMT-08:00)
To: Gabor Sandor Envedi ,Andras Csaszar <=
andras.csaszar@ericsson.com>,Alia Atlas ,"cbowers@" ,Abishek Gopalan ,C=
hris Bowers ,Andras Csaszar ,Gabor Sandor Enyedi 
Subject: New Version Notification for draft-enyedi-rtgwg-mrt-frr-algorithm-=
03.txt



A new version of I-D, draft-enyedi-rtgwg-mrt-frr-algorithm-03.txt
has been successfully submitted by Gabor Sandor Enyedi and posted to the
IETF repository.

Filename:        draft-enyedi-rtgwg-mrt-frr-algorithm
Revision:        03
Title:           Algorithms for computing Maximally Redundant Trees for IP/=
LDP Fast- Reroute
Creation date:   2013-07-15
Group:           Individual Submission
Number of pages: 51
URL:             http://www.ietf.org/internet-drafts/draft-enyedi-rtgwg-mrt=
-frr-algorithm-03.txt
Status:          http://datatracker.ietf.org/doc/draft-enyedi-rtgwg-mrt-frr=
-algorithm
Htmlized:        http://tools.ietf.org/html/draft-enyedi-rtgwg-mrt-frr-algo=
rithm-03
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-enyedi-rtgwg-mrt-=
frr-algorithm-03

Abstract:
   A complete solution for IP and LDP Fast-Reroute using Maximally
   Redundant Trees is presented in [I-D.ietf-rtgwg-mrt-frr-
   architecture].  This document defines the associated MRT Lowpoint
   algorithm that is used in the default MRT profile to compute both the
   necessary Maximally Redundant Trees with their associated next-hops
   and the alternates to select for MRT-FRR.




The IETF Secretariat




--_000_asukrf5p5uqypw91tr23sat61373930688121emailandroidcom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









(WG chair hat off)






We have updated draft-enyedi-rtgwg-mrt-frr-algorithm-03.txt and added =
an analysis and comparison. 







Discussion would be welcome. 


Regards,


Alia







-------- Original message --------

From: internet-drafts@ietf.org 

Date: 07/15/2013 4:20 PM (GMT-08:00) 

To: Gabor Sandor Envedi <Gabor.Sandor.Enyedi@ericsson.com>,Andras Csa=
szar <andras.csaszar@ericsson.com>,Alia Atlas <akatlas@juniper.net=
>,"cbowers@" <juniper.net.cbowers@juniper.net>,Abishek G=
opalan <abishek@ece.arizona.edu>,Chris Bowers <cbowers@juniper.net=
>,Andras
 Csaszar <Andras.Csaszar@ericsson.com>,Gabor Sandor Enyedi <gabor.=
sandor.enyedi@ericsson.com>


Subject: New Version Notification for draft-enyedi-rtgwg-mrt-frr-algorithm-=
03.txt












A new version of I-D, draft-enyedi-rtgwg-mrt-frr-algorithm-03.txt

has been successfully submitted by Gabor Sandor Enyedi and posted to the
IETF repository.



Filename:        draft-enyedi-rtgwg-mrt-=
frr-algorithm

Revision:        03

Title:           Algorith=
ms for computing Maximally Redundant Trees for IP/LDP Fast- Reroute

Creation date:   2013-07-15

Group:           Individu=
al Submission

Number of pages: 51

URL:            =
; 
http://www.ietf.org/internet-drafts/draft-enyedi-rtgwg-mrt-frr-algorithm-03=
.txt

Status:          
http://datatracker.ietf.org/doc/draft-enyedi-rtgwg-mrt-frr-algorithm
Htmlized:        
http://tools.ietf.org/html/draft-enyedi-rtgwg-mrt-frr-algorithm-03

Diff:            
http://www.ietf.org/rfcdiff?url2=3Ddraft-enyedi-rtgwg-mrt-frr-algorithm-03<=
/a>



Abstract:

   A complete solution for IP and LDP Fast-Reroute using Maximall=
y

   Redundant Trees is presented in [I-D.ietf-rtgwg-mrt-frr-

   architecture].  This document defines the associated MRT =
Lowpoint

   algorithm that is used in the default MRT profile to compute b=
oth the

   necessary Maximally Redundant Trees with their associated next=
-hops

   and the alternates to select for MRT-FRR.



            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
      






The IETF Secretariat













--_000_asukrf5p5uqypw91tr23sat61373930688121emailandroidcom_--

From aretana@cisco.com  Wed Jul 17 17:19:57 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDEA21F95BD for ; Wed, 17 Jul 2013 17:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+0G8VtD7v0m for ; Wed, 17 Jul 2013 17:19:52 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 17D1C21F92C2 for ; Wed, 17 Jul 2013 17:19:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2928; q=dns/txt; s=iport; t=1374106792; x=1375316392; h=from:to:subject:date:message-id:mime-version; bh=IA2o5/qorvb7nh4WPOKJsDYMRZsHTc6I6IsCK4wM5oo=; b=UDKXVvSixJCUXSp7D0w8MukkovnQSdGhQOsp70d8HO64aLZ3S2biP8kF BMXrNydRq+3OYad6vZVo+NYoD5Igyf3w/8vc+2hEklPE7snyq2Ij13kyS Ut9S7oYEp0SuxfoPxbM9l82FVdJX9u9nb2ikfEZHB79GwDLYxv8ShlB8h k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoQFAA0z51GtJXG8/2dsb2JhbABagkJENFCCP74AgRAWdIIlAQSBCwEMHlYnBBsBiAcMlWWgR49Jg0VuA6kpgxKCKA
X-IronPort-AV: E=Sophos;i="4.89,688,1367971200";  d="scan'208,217";a="236012005"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jul 2013 00:19:41 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6I0Jfdh028486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Jul 2013 00:19:41 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.152]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 19:19:41 -0500
From: "Alvaro Retana (aretana)" 
To: "rtgwg@ietf.org" 
Subject: rtgwg Draft Agenda
Thread-Topic: rtgwg Draft Agenda
Thread-Index: AQHOg0x/WEoprbJoq06EmGTTt0HL+g==
Date: Thu, 18 Jul 2013 00:19:41 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.221.23]
Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E27C6FB46xmbalnx15ciscoc_"
MIME-Version: 1.0
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jul 2013 00:19:57 -0000

--_000_BBD66FD99311804F80324E8139B3C94E27C6FB46xmbalnx15ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi!

I just posted the rtgwg Draft Agenda for the meeting in Berlin.

http://www.ietf.org/proceedings/87/agenda/agenda-87-rtgwg

As a reminder, we're scheduled to meet on Friday at 11:20am-1:30pm.

If I missed your request, please let both Alia and I know.

Please provide your slides by July 31 at 10pm CET.  It would also be great =
if you started a discussion of your work on the list.

Thanks!

Alvaro.

--_000_BBD66FD99311804F80324E8139B3C94E27C6FB46xmbalnx15ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <0EAA218F6D82624ABE34B6E2D1B1F421@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi!







I just posted the rtgwg Draft Agenda for the meeting in Berlin.













As a reminder, we're scheduled to meet on Friday at 11:20am-1:30pm.







If I missed your request, please let both Alia and I know.







Please provide your slides by July 31 at 10pm CET.  It would also be =
great if you started a discussion of your work on the list.







Thanks!







Alvaro.




--_000_BBD66FD99311804F80324E8139B3C94E27C6FB46xmbalnx15ciscoc_--

From akatlas@gmail.com  Thu Jul 25 08:35:44 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C23721F9675 for ; Thu, 25 Jul 2013 08:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.48
X-Spam-Level: 
X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YInW3N6LymTs for ; Thu, 25 Jul 2013 08:35:43 -0700 (PDT)
Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 94D2521F9B5B for ; Thu, 25 Jul 2013 08:35:29 -0700 (PDT)
Received: by mail-ob0-f182.google.com with SMTP id wo10so1860254obc.27 for ; Thu, 25 Jul 2013 08:35:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SKVPZkGejCIoIYlxhTWGNTG6GS5oxrYXcOW/gVpTVl0=; b=0MA/b5Mjf20WW5+c1Md338Xs2Amg3DC76TIsgWE+hz04UcjAQ8Uzq9UNK+PTY4BU6b n5RLM2FQMjFBKRtQ6uykXy4j9EWwWilXtKCOFsdchS/g+rrVnmJ2zxaUWgWOzkpbvomD kuwhoi5dm9EJirPXLKKYGejbAhFqUKT+9Bu/Cj/0TZVnMHsiX6T7tLW+gEleSO+Re2EW kXvo2CnRhhZI3OEBxLGvWDrFQUK2hjvpSAGsIVTiJ6GvBzwoJ6iwt026rmjniFE6/XYl cmJDTVKWNn+tMAcjOxneGUUuHaMIrfEKjqXexA4vxUDNoCFLpdY1JqpK9fYw/CLDJlYQ 3xsQ==
MIME-Version: 1.0
X-Received: by 10.50.67.20 with SMTP id j20mr398276igt.36.1374766528087; Thu, 25 Jul 2013 08:35:28 -0700 (PDT)
Received: by 10.64.8.19 with HTTP; Thu, 25 Jul 2013 08:35:28 -0700 (PDT)
Date: Thu, 25 Jul 2013 11:35:28 -0400
Message-ID: 
Subject: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
From: Alia Atlas 
To: "rtgwg@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7bdc0f428e540f04e257c632
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2013 15:35:44 -0000

--047d7bdc0f428e540f04e257c632
Content-Type: text/plain; charset=ISO-8859-1

We are likely to add this draft to the list to be discussed in the meeting.
 It is discussing some general problems with MTU configuration between
vendors.  While it discusses this for ISIS, some aspects also apply to OSPF.

Basically, there are three problems:

a) Some implementations use L2 MTU and others use the L3 MTU
b) Different implementations pad and check for different lengths.
 Consequences are that ISIS sessions do not make it to Up.
c) Different numbers of MPLS labels are assumed as the max, resulting in
fragmentation, and there are generally no controls for it.

http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/

Thanks,
Alia

--047d7bdc0f428e540f04e257c632
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


We are likely to add this draft to the list to be dis=
cussed in the meeting. =A0It is discussing some general problems with MTU c=
onfiguration between vendors. =A0While it discusses this for ISIS, some asp=
ects also apply to OSPF.



Basically, there are three problems:

a) Some implementations use L2 MTU and others use the L3 MTU
b) Different implementations pad and check for different lengths. =A0Con=
sequences are that ISIS sessions do not make it to Up.


c) Different numbers of MPLS labels are assumed as the max, resulting =
in fragmentation, and there are generally no controls for it.
http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/


Thanks,
Alia


--047d7bdc0f428e540f04e257c632--

From tony.li@tony.li  Thu Jul 25 09:06:32 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E6921F941F for ; Thu, 25 Jul 2013 09:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.437
X-Spam-Level: 
X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVPcgMk+UHmY for ; Thu, 25 Jul 2013 09:06:28 -0700 (PDT)
Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id 27BE921F9943 for ; Thu, 25 Jul 2013 09:06:22 -0700 (PDT)
Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta02.emeryville.ca.mail.comcast.net with comcast id 4d1Y1m0020QkzPwA2g6M8n; Thu, 25 Jul 2013 16:06:21 +0000
Received: from [10.47.2.130] ([173.245.93.156]) by omta02.emeryville.ca.mail.comcast.net with comcast id 4g4B1m0023NRPAd8Ng4Dwk; Thu, 25 Jul 2013 16:04:20 +0000
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
From: Tony Li 
In-Reply-To: 
Date: Thu, 25 Jul 2013 09:04:10 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <44303AFD-34F5-482A-B0B9-71D4D6F9B8E0@tony.li>
References: 
To: Alia Atlas 
X-Mailer: Apple Mail (2.1508)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374768381; bh=FWg7ZJSkZQdjpL3goJ6l9z2QvO/f3iHd4UDg9VhTnxw=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=JHjfpZZoRd9qxRZ5czkMK7fQ1E7sCtiZWhqGA340siowPwgM1coVxOpCHnJ6ohhjl 7cb42A5uHULdFfiH2iQAjsKGjZCHa9ldXTU9z+mI5um8oIzHjyhybffdzH+tnkG2d9 zjLwTgYqQFP8fYFwwN71qhnwYP1XVvSdk+y3TxDwEEEFIlZPRQ/CTD8TIrkFw96ise SA8YOc71Ps40uo2QRW6sm8DMPjpAhMNDFr0uI3CeJn1F7P9wDh6c+Xl6ORJ+SiB3Yt ydNEhMOSKNG6N3NZfjFqN5jQo8+jqHnlQaYHKBKvE6rHxPmpV3eHwnrKX2YDfvBToY XrcSlXbCPAEAQ==
Cc: "rtgwg@ietf.org" 
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2013 16:06:32 -0000

On Jul 25, 2013, at 8:35 AM, Alia Atlas  wrote:

> We are likely to add this draft to the list to be discussed in the =
meeting.  It is discussing some general problems with MTU configuration =
between vendors.  While it discusses this for ISIS, some aspects also =
apply to OSPF.
>=20
> Basically, there are three problems:
>=20
> a) Some implementations use L2 MTU and others use the L3 MTU
> b) Different implementations pad and check for different lengths.  =
Consequences are that ISIS sessions do not make it to Up.
> c) Different numbers of MPLS labels are assumed as the max, resulting =
in fragmentation, and there are generally no controls for it.
>=20
> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/


I'm interested in understanding what the authors would like to see from =
this.   It would be well outside of the IETF's charter to say that =
implementations must configure MTU in only one manner.

At best, I see this document as saying 'be consistent', which seems like =
spitting upwind.

Tony


From akatlas@gmail.com  Thu Jul 25 09:19:18 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A8421F99BA for ; Thu, 25 Jul 2013 09:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level: 
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6hhmDy55Fib for ; Thu, 25 Jul 2013 09:19:17 -0700 (PDT)
Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id EC82E21F99AF for ; Thu, 25 Jul 2013 09:19:16 -0700 (PDT)
Received: by mail-oa0-f48.google.com with SMTP id f4so4708476oah.7 for ; Thu, 25 Jul 2013 09:19:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wxoqSZ0kxMcvhGl8Gc7nUFNlmFERV2YLMr3PeCq7aco=; b=wZXV0ThYIVdMTY5TCDcJ8bHRXBoJ0tThTPfMZAstcLQ2Xx4p7/RMSj2jls/i1wNuJ2 2hLm/DeDYEW52Ps5MKxD/i030/F+QaIFn88Jr9ebQiv5gw5IVXNHXC8MVfykI1CYBLgq 7stWI4jsjha7xwffdYOt3ftQYD4qCeAD5Z20yGeC4APZ+HhxkKzOSUfOrLyZhlYUw3bN Ozevb/wJVbmqPRzU/OOLokleYwmbHy+PM7KFTHPHb2Exq/3S07SLDjl/vXzQhGC85Ehq 5fRI5S7EIStBem2qpd1H/j68Qs5YtAyaBJMDjFfVGiha0nqbHYaItfF2AiSa8x3EUv6+ Mryw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wxoqSZ0kxMcvhGl8Gc7nUFNlmFERV2YLMr3PeCq7aco=; b=O91gFxyF2x1B3SFB6yy4DLwYMXRUpjx91c/LEX2ud65r6V7yO1ZnIGd/uhMeJRJ/bs MPHZSv6q10jG1ctalGkZ8LYp7DFRL7v399Thx1wyRY47t2/JJBawcyLSApdHgbKGh3ho yVvothTx3NEli2lj/6/goBL4NwjzgbYH9WsVjxbpnennoI/tKuIBPOhYRviafnNnPvTV 7xcE4VoTeDdRTI79WK+9mlUcIpLRuCA+iug90r3hMTBUXUUm2Q28Dy0dwzPaj5IB4y6/ G7FuL5HeuiRvulzr3hYUdiP2rSsaOEPAWdvTdAh6hUZTD+0+u9YMb+jDS5qHmaZ2mdbm Dniw==
MIME-Version: 1.0
X-Received: by 10.50.22.105 with SMTP id c9mr421843igf.36.1374769154618; Thu, 25 Jul 2013 09:19:14 -0700 (PDT)
Received: by 10.64.8.19 with HTTP; Thu, 25 Jul 2013 09:19:14 -0700 (PDT)
In-Reply-To: <44303AFD-34F5-482A-B0B9-71D4D6F9B8E0@tony.li>
References:  <44303AFD-34F5-482A-B0B9-71D4D6F9B8E0@tony.li>
Date: Thu, 25 Jul 2013 12:19:14 -0400
Message-ID: 
Subject: Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
From: Alia Atlas 
To: Tony Li 
Content-Type: multipart/alternative; boundary=047d7b10cd831bff1604e2586340
Cc: "rtgwg@ietf.org" 
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2013 16:19:18 -0000

--047d7b10cd831bff1604e2586340
Content-Type: text/plain; charset=ISO-8859-1

Yes - my thought is perhaps a BCP??  It's clearly an interoperability
problem.  What is interesting is to discuss the issue and see what could be
done.

Alia

P.S.  Thanks for the quick reading and response!


On Thu, Jul 25, 2013 at 12:04 PM, Tony Li  wrote:

>
> On Jul 25, 2013, at 8:35 AM, Alia Atlas  wrote:
>
> > We are likely to add this draft to the list to be discussed in the
> meeting.  It is discussing some general problems with MTU configuration
> between vendors.  While it discusses this for ISIS, some aspects also apply
> to OSPF.
> >
> > Basically, there are three problems:
> >
> > a) Some implementations use L2 MTU and others use the L3 MTU
> > b) Different implementations pad and check for different lengths.
>  Consequences are that ISIS sessions do not make it to Up.
> > c) Different numbers of MPLS labels are assumed as the max, resulting in
> fragmentation, and there are generally no controls for it.
> >
> > http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/
>
>
> I'm interested in understanding what the authors would like to see from
> this.   It would be well outside of the IETF's charter to say that
> implementations must configure MTU in only one manner.
>
> At best, I see this document as saying 'be consistent', which seems like
> spitting upwind.
>
> Tony
>
>

--047d7b10cd831bff1604e2586340
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Yes - my thought is perhaps a BCP?? =A0It's clearly an=
 interoperability problem. =A0What is interesting is to discuss the issue a=
nd see what could be done.

Alia

P.S. =A0Thanks for the quick reading and response!




On Thu,=
 Jul 25, 2013 at 12:04 PM, Tony Li <tony.li@tony.li> wrote:




On Jul 25, 2013, at 8:35 AM, Alia Atlas <akatlas@gmail.com> wrote:



> We are likely to add this draft to the list to be discussed in the mee=
ting. =A0It is discussing some general problems with MTU configuration betw=
een vendors. =A0While it discusses this for ISIS, some aspects also apply t=
o OSPF.


>

> Basically, there are three problems:

>

> a) Some implementations use L2 MTU and others use the L3 MTU

> b) Different implementations pad and check for different lengths. =A0C=
onsequences are that ISIS sessions do not make it to Up.

> c) Different numbers of MPLS labels are assumed as the max, resulting =
in fragmentation, and there are generally no controls for it.

>

> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-=
config-ps/






I'm interested in understanding what the authors would like=
 to see from this. =A0 It would be well outside of the IETF's charter t=
o say that implementations must configure MTU in only one manner.



At best, I see this document as saying 'be consistent', which seems=
 like spitting upwind.



Tony







--047d7b10cd831bff1604e2586340--

From bradd@ntt.net  Thu Jul 25 09:27:17 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAE021F9962 for ; Thu, 25 Jul 2013 09:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CtVik9Yos4C for ; Thu, 25 Jul 2013 09:27:13 -0700 (PDT)
Received: from shaolin.ameri.ca (shaolin.ameri.ca [206.239.7.162]) by ietfa.amsl.com (Postfix) with ESMTP id B902521F994B for ; Thu, 25 Jul 2013 09:27:13 -0700 (PDT)
Received: from sierra.ameri.ca (sierra.ameri.ca [IPv6:2001:418:8004:1::171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bradd) by shaolin.ameri.ca (Postfix) with ESMTPSA id 4CC6A2A0ECE; Thu, 25 Jul 2013 16:27:12 +0000 (UTC)
Date: Thu, 25 Jul 2013 12:27:10 -0400
From: brad dreisbach 
To: Alia Atlas 
Subject: Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
Message-ID: <20130725162710.GE9685@sierra.ameri.ca>
References:  <44303AFD-34F5-482A-B0B9-71D4D6F9B8E0@tony.li> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-PGPkey: https://compton.ameri.ca/~bradd/pgp/bradd@us.ntt.net.9EA8EAFE.dsa.gpg
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "rtgwg@ietf.org" 
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2013 16:27:17 -0000

On Thu, Jul 25, 2013 at 12:19:14PM -0400, Alia Atlas wrote:
> Yes - my thought is perhaps a BCP??  It's clearly an interoperability
> problem.  What is interesting is to discuss the issue and see what could be
> done.

I think an informational rfc/draft outlining the differences in implentations 
would be more appropriate than a BCP.

> 
> Alia
> 
> P.S.  Thanks for the quick reading and response!
> 
> 
> On Thu, Jul 25, 2013 at 12:04 PM, Tony Li  wrote:
> 
> >
> > On Jul 25, 2013, at 8:35 AM, Alia Atlas  wrote:
> >
> > > We are likely to add this draft to the list to be discussed in the
> > meeting.  It is discussing some general problems with MTU configuration
> > between vendors.  While it discusses this for ISIS, some aspects also apply
> > to OSPF.
> > >
> > > Basically, there are three problems:
> > >
> > > a) Some implementations use L2 MTU and others use the L3 MTU
> > > b) Different implementations pad and check for different lengths.
> >  Consequences are that ISIS sessions do not make it to Up.
> > > c) Different numbers of MPLS labels are assumed as the max, resulting in
> > fragmentation, and there are generally no controls for it.
> > >
> > > http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/
> >
> >
> > I'm interested in understanding what the authors would like to see from
> > this.   It would be well outside of the IETF's charter to say that
> > implementations must configure MTU in only one manner.
> >
> > At best, I see this document as saying 'be consistent', which seems like
> > spitting upwind.
> >
> > Tony
> >
> >

> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg


From cpignata@cisco.com  Thu Jul 25 10:54:41 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A243921F8B04 for ; Thu, 25 Jul 2013 10:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uTjXtr4l4am for ; Thu, 25 Jul 2013 10:54:36 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 98B3321F994B for ; Thu, 25 Jul 2013 10:54:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6672; q=dns/txt; s=iport; t=1374774868; x=1375984468; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=X/70Xqa2/E3XCWAybSvuX78NA4tdN/17SmD/DYagOZM=; b=O4yMQSzpwvmY6qPDyECE/MW7RO8RB8Z4jAL+ZjEGvs2H1XCIuGDEA0+l V9vUeqTXNtdt2wfzv0dwiVIgtnCjuBBGu6hzO67JfqFXVy5+szX9P76xq O8FMFaJHSRua+FkCAhleZRkzipypMUaDeOTH5g6emqfCgNYat0NAQRBjQ 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqkFABJl8VGtJV2a/2dsb2JhbABbgwY1UKtoiTaIQoEXFnSCJAEBAQMBAQEBawsFCwIBCA4UHQchBgsUEQIEDgUIh3YDCQYMsRENiF6NFYI3MQeDEm4DiHKNBIMSin6FJoFbgTmCKg
X-IronPort-AV: E=Sophos;i="4.89,744,1367971200";  d="scan'208,217";a="239503077"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jul 2013 17:54:27 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6PHsRi3003525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jul 2013 17:54:27 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 12:54:26 -0500
From: "Carlos Pignataro (cpignata)" 
To: Alia Atlas 
Subject: Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
Thread-Topic: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
Thread-Index: AQHOiUyjjn1kJqZqc0CvF2iLpQ0x2Zl14moAgAAENgCAABqYgA==
Date: Thu, 25 Jul 2013 17:54:25 +0000
Message-ID: <95067C434CE250468B77282634C96ED322D51E08@xmb-aln-x02.cisco.com>
References:  <44303AFD-34F5-482A-B0B9-71D4D6F9B8E0@tony.li> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.102.157.229]
Content-Type: multipart/alternative; boundary="_000_95067C434CE250468B77282634C96ED322D51E08xmbalnx02ciscoc_"
MIME-Version: 1.0
Cc: "rtgwg@ietf.org" 
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2013 17:54:41 -0000

--_000_95067C434CE250468B77282634C96ED322D51E08xmbalnx02ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Alia,

The fact that different vendors use different interpretations of "MTU" in a=
 configuration interface (some L3, some L2 (with/without FCS)) is well know=
n and accounted for while configuring. Many of those config interfaces show=
 "hardware mtu", "protocol mtu", and other proxies for naming labels to imp=
ly which encaps included. There seems to be lots of publicly available docu=
mentation about this.

I was also wondering what the expected output or goal is. Would publishing =
an RFC achieve the goal stated in the I-D?

   for all vender to standardize the MTU configuration in IP
   network and MPLS network.

Or are existing RFCs + vendors' documentation + discussion lists archives e=
nough?

Thanks,

-- Carlos.

On Jul 25, 2013, at 12:19 PM, Alia Atlas > wrote:

Yes - my thought is perhaps a BCP??  It's clearly an interoperability probl=
em.  What is interesting is to discuss the issue and see what could be done=
.

Alia

P.S.  Thanks for the quick reading and response!


On Thu, Jul 25, 2013 at 12:04 PM, Tony Li > wrote:

On Jul 25, 2013, at 8:35 AM, Alia Atlas > wrote:

> We are likely to add this draft to the list to be discussed in the meetin=
g.  It is discussing some general problems with MTU configuration between v=
endors.  While it discusses this for ISIS, some aspects also apply to OSPF.
>
> Basically, there are three problems:
>
> a) Some implementations use L2 MTU and others use the L3 MTU
> b) Different implementations pad and check for different lengths.  Conseq=
uences are that ISIS sessions do not make it to Up.
> c) Different numbers of MPLS labels are assumed as the max, resulting in =
fragmentation, and there are generally no controls for it.
>
> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/


I'm interested in understanding what the authors would like to see from thi=
s.   It would be well outside of the IETF's charter to say that implementat=
ions must configure MTU in only one manner.

At best, I see this document as saying 'be consistent', which seems like sp=
itting upwind.

Tony


_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg


--_000_95067C434CE250468B77282634C96ED322D51E08xmbalnx02ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <2381D49876D00243993CF35286522B40@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable






Alia,






The fact that different vendors use different interpretations of "=
;MTU" in a configuration interface (some L3, some L2 (with/without FCS=
)) is well known and accounted for while configuring. Many of those config =
interfaces show "hardware mtu", "protocol
 mtu", and other proxies for naming labels to imply which encaps inclu=
ded. There seems to be lots of publicly available documentation about this.=








I was also wondering what the expected output or goal is. Would publis=
hing an RFC achieve the goal stated in the I-D?




   for all vender to standardize the MTU configurati=
on in IP
   network and MPLS network.


Or are existing RFCs + vendors' documentation + discussion lis=
ts archives enough?









Thanks,







-- Carlos.







On Jul 25, 2013, at 12:19 PM, Alia Atlas <akatlas@gmail.com> wrote:






Yes - my thought is perhaps a BCP??  It's clearly an =
interoperability problem.  What is interesting is to discuss the issue=
 and see what could be done.






Alia







P.S.  Thanks for the quick reading and response!









On Thu, Jul 25, 2013 at 12:04 PM, Tony Li 
<tony.li@tony.li> wrote:








On Jul 25, 2013, at 8:35 AM, Alia Atlas <akatlas@gmail.com> wrote:



> We are likely to add this draft to the list to be discussed in the mee=
ting.  It is discussing some general problems with MTU configuration b=
etween vendors.  While it discusses this for ISIS, some aspects also a=
pply to OSPF.

>

> Basically, there are three problems:

>

> a) Some implementations use L2 MTU and others use the L3 MTU

> b) Different implementations pad and check for different lengths. &nbs=
p;Consequences are that ISIS sessions do not make it to Up.

> c) Different numbers of MPLS labels are assumed as the max, resulting =
in fragmentation, and there are generally no controls for it.

>

> 
http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/









I'm interested in understanding what the authors would like to see from thi=
s.   It would be well outside of the IETF's charter to say that implem=
entations must configure MTU in only one manner.



At best, I see this document as saying 'be consistent', which seems like sp=
itting upwind.



Tony











_______________________________________________

rtgwg mailing list

rtgwg@ietf.org

https://www.ietf.org/mailman/listinfo/rtgwg












--_000_95067C434CE250468B77282634C96ED322D51E08xmbalnx02ciscoc_--

From akatlas@gmail.com  Thu Jul 25 11:24:41 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E731921F8618 for ; Thu, 25 Jul 2013 11:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Level: 
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RIHMf6jw0Hc for ; Thu, 25 Jul 2013 11:24:40 -0700 (PDT)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id D918C21F85BB for ; Thu, 25 Jul 2013 11:24:39 -0700 (PDT)
Received: by mail-ob0-f169.google.com with SMTP id up14so2294746obb.14 for ; Thu, 25 Jul 2013 11:24:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cPUFVK2TuNLMK+XQchF8IRPPSkBe+mAqIFlN+Xhr/NE=; b=TD/fIaqiS/fiJVmLIDAvw7ElOn2OONYC+mLsJNW4uLLkOadNqp07pekYPpXzLnCQ6C Nu0vC5iclcfwhCeQkzS8aAkcdxSVYZqddE9pseIfiwsDKiXivCM0c09jmQnhewVGzuI4 eeVndKg96biAe3U1e+CP/+TFXv0A6xQ4mN8AbYumloBwV2w+RK8CHomaHvORmqzEjHML CcfPXLku1034OYdsuG76SaGxQJ3zv23iaiJaOETWvBrHfDCrrfKsUNe+scWAOSseirEw WTyB0S3fdUZpGtFD2DsZ4UN5oBX116ncnfxhRrGUsrq+9UL9OKdi5fnh8Hpj1I34DMgu pODg==
MIME-Version: 1.0
X-Received: by 10.42.80.9 with SMTP id t9mr20662058ick.14.1374776679317; Thu, 25 Jul 2013 11:24:39 -0700 (PDT)
Received: by 10.64.8.19 with HTTP; Thu, 25 Jul 2013 11:24:39 -0700 (PDT)
Received: by 10.64.8.19 with HTTP; Thu, 25 Jul 2013 11:24:39 -0700 (PDT)
In-Reply-To: <95067C434CE250468B77282634C96ED322D51E08@xmb-aln-x02.cisco.com>
References:  <44303AFD-34F5-482A-B0B9-71D4D6F9B8E0@tony.li>  <95067C434CE250468B77282634C96ED322D51E08@xmb-aln-x02.cisco.com>
Date: Thu, 25 Jul 2013 14:24:39 -0400
Message-ID: 
Subject: Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
From: Alia Atlas 
To: Carlos Pignataro 
Content-Type: multipart/alternative; boundary=20cf300e52cf9df15d04e25a2392
Cc: rtgwg@ietf.org
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2013 18:24:41 -0000

--20cf300e52cf9df15d04e25a2392
Content-Type: text/plain; charset=ISO-8859-1

Carlos,

I'm not surprised that there is lots of vendor documentation.  It's
something that has been around for a while.   The question is whether there
is anything that might benefit from documentation.   The size of label
stack, in particular,  might be interesting...

Point is to have the discussion.

Alia
On Jul 25, 2013 1:54 PM, "Carlos Pignataro (cpignata)" 
wrote:

>  Alia,
>
>  The fact that different vendors use different interpretations of "MTU"
> in a configuration interface (some L3, some L2 (with/without FCS)) is well
> known and accounted for while configuring. Many of those config interfaces
> show "hardware mtu", "protocol mtu", and other proxies for naming labels to
> imply which encaps included. There seems to be lots of publicly available
> documentation about this.
>
>  I was also wondering what the expected output or goal is. Would
> publishing an RFC achieve the goal stated in the I-D?
>
>    for all vender to standardize the MTU configuration in IP
>    network and MPLS network.
>
> Or are existing RFCs + vendors' documentation + discussion lists archives
> enough?
>
>  Thanks,
>
>  -- Carlos.
>
>  On Jul 25, 2013, at 12:19 PM, Alia Atlas  wrote:
>
>  Yes - my thought is perhaps a BCP??  It's clearly an interoperability
> problem.  What is interesting is to discuss the issue and see what could be
> done.
>
>  Alia
>
>  P.S.  Thanks for the quick reading and response!
>
>
> On Thu, Jul 25, 2013 at 12:04 PM, Tony Li  wrote:
>
>>
>> On Jul 25, 2013, at 8:35 AM, Alia Atlas  wrote:
>>
>> > We are likely to add this draft to the list to be discussed in the
>> meeting.  It is discussing some general problems with MTU configuration
>> between vendors.  While it discusses this for ISIS, some aspects also apply
>> to OSPF.
>> >
>> > Basically, there are three problems:
>> >
>> > a) Some implementations use L2 MTU and others use the L3 MTU
>> > b) Different implementations pad and check for different lengths.
>>  Consequences are that ISIS sessions do not make it to Up.
>> > c) Different numbers of MPLS labels are assumed as the max, resulting
>> in fragmentation, and there are generally no controls for it.
>> >
>> > http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/
>>
>>
>>  I'm interested in understanding what the authors would like to see from
>> this.   It would be well outside of the IETF's charter to say that
>> implementations must configure MTU in only one manner.
>>
>> At best, I see this document as saying 'be consistent', which seems like
>> spitting upwind.
>>
>> Tony
>>
>>
>  _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>
>
>

--20cf300e52cf9df15d04e25a2392
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Carlos,


I'm not surprised that there is lots of vendor documenta=
tion.=A0 It's something that has been around for a while.=A0=A0 The que=
stion is whether there is anything that might benefit from documentation.=
=A0=A0 The size of label stack, in particular,=A0 might be interesting...


Point is to have the discussion. 


Alia


On Jul 25, 2013 1:54 PM, "Carlos Pignataro =
(cpignata)" <cpignata@cisco.c=
om> wrote:







Alia,






The fact that different vendors use different interpretations of "=
;MTU" in a configuration interface (some L3, some L2 (with/without FCS=
)) is well known and accounted for while configuring. Many of those config =
interfaces show "hardware mtu", "protocol
 mtu", and other proxies for naming labels to imply which encaps inclu=
ded. There seems to be lots of publicly available documentation about this.=








I was also wondering what the expected output or goal is. Would publis=
hing an RFC achieve the goal stated in the I-D?




   for all vender to standardize the MTU configuration in IP
   network and MPLS network.


Or are existing RFCs + vendors' documentation + discussion lists a=
rchives enough?









Thanks,







-- Carlos.







On Jul 25, 2013, at 12:19 PM, Alia Atlas <akatlas@gmail.com> wrote:






Yes - my thought is perhaps a BCP?? =A0It's clearly an=
 interoperability problem. =A0What is interesting is to discuss the issue a=
nd see what could be done.






Alia







P.S. =A0Thanks for the quick reading and response!









On Thu, Jul 25, 2013 at 12:04 PM, Tony Li 
<tony.li@tony.li> wrote:








On Jul 25, 2013, at 8:35 AM, Alia Atlas <akatlas@gmail.com> wrote:



> We are likely to add this draft to the list to be discussed in the mee=
ting. =A0It is discussing some general problems with MTU configuration betw=
een vendors. =A0While it discusses this for ISIS, some aspects also apply t=
o OSPF.


>

> Basically, there are three problems:

>

> a) Some implementations use L2 MTU and others use the L3 MTU

> b) Different implementations pad and check for different lengths. =A0C=
onsequences are that ISIS sessions do not make it to Up.

> c) Different numbers of MPLS labels are assumed as the max, resulting =
in fragmentation, and there are generally no controls for it.

>

> 
http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/









I'm interested in understanding what the authors would like to see from=
 this. =A0 It would be well outside of the IETF's charter to say that i=
mplementations must configure MTU in only one manner.



At best, I see this document as saying 'be consistent', which seems=
 like spitting upwind.



Tony











_______________________________________________

rtgwg mailing list

rtgwg@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/rtgwg















--20cf300e52cf9df15d04e25a2392--

From jeff.tantsura@ericsson.com  Thu Jul 25 12:31:50 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4B421F9371 for ; Thu, 25 Jul 2013 12:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.299,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mICnIpp8NyiV for ; Thu, 25 Jul 2013 12:31:46 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id D27C121F8C72 for ; Thu, 25 Jul 2013 12:31:45 -0700 (PDT)
X-AuditID: c618062d-b7fc36d0000032ea-a0-51f17d204f0a
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 4E.FB.13034.02D71F15; Thu, 25 Jul 2013 21:31:44 +0200 (CEST)
Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Thu, 25 Jul 2013 15:31:44 -0400
From: Jeff Tantsura 
To: Alia Atlas 
Subject: Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
Thread-Topic: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
Thread-Index: AQHOiUyqQ+3XWCQX7kCsfb6bXF3yT5l10acAgAAENQCAABqYgIAACHOA///PryA=
Date: Thu, 25 Jul 2013 19:31:43 +0000
Message-ID: <8FBB1A9B-C64A-444B-8170-17A01F26A38A@ericsson.com>
References:  <44303AFD-34F5-482A-B0B9-71D4D6F9B8E0@tony.li>  <95067C434CE250468B77282634C96ED322D51E08@xmb-aln-x02.cisco.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_8FBB1A9BC64A444B817017A01F26A38Aericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyuXRPuK5C7cdAg3drzC0+PbzEbPHp3Q4W iwtvfjM7MHtM+b2R1WPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgypjw/zpLwQb3insvbrE1 MM616WLk5JAQMJGYOuUJM4QtJnHh3nq2LkYuDiGBo4wSnyctZ4VwljNKfHz+kB2kik3AQOL/ t+MsXYwcHCICShJTXwqDhJkFfCQOHD4CViIsEC1xZtdlsKEiAjESz2ZeZIQo95No3yEGEmYR UJVY9/E1E4jNK2Av8f7DdXaIVReYJO7cOgs2h1MgUOLr6ddsIDYj0HHfT61hgtglLnHryXwm iKMFJJbsOQ/1gKjEy8f/WCFqkiVmPzvGDrFAUOLkzCcsExhFZiFpn4WkbBaSMoi4jsSC3Z/Y IGxtiWULXzPD2GcOPGZCFl/AyL6KkaO0OLUsN93IYBMjMKKOSbDp7mDc89LyEKM0B4uSOO8q vTOBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhbvhqY+L8o7BRX37Re1TFqw+XjJWfOW/Le VCzaLWVZe9jpchtbcmPQSlUDrUdKfI2KEWYbJVeeLtCN1Ir4GLBqBf+nNcs4pfNMbnsn5lgn e3HqsWt3yF1O2/P7/TvGLA5D57nz64+aOZwRMZPqmrV9ff2pOXlGLxTPTe303fz977euXyv2 KiqxFGckGmoxFxUnAgAd2OtBdgIAAA==
Cc: Carlos Pignataro , "rtgwg@ietf.org" 
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2013 19:31:50 -0000

--_000_8FBB1A9BC64A444B817017A01F26A38Aericssoncom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Alia,

Would be great to have documented how different vendors interpret MTU, btw =
most also have implemented different flavors of "ignore mtu" knobs for thei=
r IGPs.
Both informational or BCP would do.

Regards,
Jeff

On Jul 25, 2013, at 8:24 PM, "Alia Atlas" > wrote:


Carlos,

I'm not surprised that there is lots of vendor documentation.  It's somethi=
ng that has been around for a while.   The question is whether there is any=
thing that might benefit from documentation.   The size of label stack, in =
particular,  might be interesting...

Point is to have the discussion.

Alia

On Jul 25, 2013 1:54 PM, "Carlos Pignataro (cpignata)" > wrote:
Alia,

The fact that different vendors use different interpretations of "MTU" in a=
 configuration interface (some L3, some L2 (with/without FCS)) is well know=
n and accounted for while configuring. Many of those config interfaces show=
 "hardware mtu", "protocol mtu", and other proxies for naming labels to imp=
ly which encaps included. There seems to be lots of publicly available docu=
mentation about this.

I was also wondering what the expected output or goal is. Would publishing =
an RFC achieve the goal stated in the I-D?

   for all vender to standardize the MTU configuration in IP
   network and MPLS network.

Or are existing RFCs + vendors' documentation + discussion lists archives e=
nough?

Thanks,

-- Carlos.

On Jul 25, 2013, at 12:19 PM, Alia Atlas > wrote:

Yes - my thought is perhaps a BCP??  It's clearly an interoperability probl=
em.  What is interesting is to discuss the issue and see what could be done=
.

Alia

P.S.  Thanks for the quick reading and response!


On Thu, Jul 25, 2013 at 12:04 PM, Tony Li > wrote:

On Jul 25, 2013, at 8:35 AM, Alia Atlas > wrote:

> We are likely to add this draft to the list to be discussed in the meetin=
g.  It is discussing some general problems with MTU configuration between v=
endors.  While it discusses this for ISIS, some aspects also apply to OSPF.
>
> Basically, there are three problems:
>
> a) Some implementations use L2 MTU and others use the L3 MTU
> b) Different implementations pad and check for different lengths.  Conseq=
uences are that ISIS sessions do not make it to Up.
> c) Different numbers of MPLS labels are assumed as the max, resulting in =
fragmentation, and there are generally no controls for it.
>
> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/


I'm interested in understanding what the authors would like to see from thi=
s.   It would be well outside of the IETF's charter to say that implementat=
ions must configure MTU in only one manner.

At best, I see this document as saying 'be consistent', which seems like sp=
itting upwind.

Tony


_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

--_000_8FBB1A9BC64A444B817017A01F26A38Aericssoncom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Alia,







Would be great to have documented how different vendors interpret MTU,=
 btw most also have implemented different flavors of "ignore mtu"=
 knobs for their IGPs.


Both informational or BCP would do.




Regards,

Jeff






On Jul 25, 2013, at 8:24 PM, "Alia Atlas" <akatlas@gmail.com> wrote:










Carlos,


I'm not surprised that there is lots of vendor documentation=
.  It's something that has been around for a while.   The qu=
estion is whether there is anything that might benefit from documentation.&=
nbsp;  The size of label stack, in particular,  might
 be interesting...


Point is to have the discussion. 


Alia


On Jul 25, 2013 1:54 PM, "Carlos Pignataro =
(cpignata)" <cpignata@cisco.c=
om> wrote:




Alia,






The fact that different vendors use different interpretations of "=
;MTU" in a configuration interface (some L3, some L2 (with/without FCS=
)) is well known and accounted for while configuring. Many of those config =
interfaces show "hardware mtu", "protocol
 mtu", and other proxies for naming labels to imply which encaps inclu=
ded. There seems to be lots of publicly available documentation about this.=








I was also wondering what the expected output or goal is. Would publis=
hing an RFC achieve the goal stated in the I-D?




   for all vender to standardize the MTU configuration in IP
   network and MPLS network.


Or are existing RFCs + vendors' documentation + discussion lis=
ts archives enough?









Thanks,







-- Carlos.







On Jul 25, 2013, at 12:19 PM, Alia Atlas <akatlas@gmail.com> wrote:






Yes - my thought is perhaps a BCP??  It's clearly an =
interoperability problem.  What is interesting is to discuss the issue=
 and see what could be done.






Alia







P.S.  Thanks for the quick reading and response!









On Thu, Jul 25, 2013 at 12:04 PM, Tony Li 
<tony.li@tony.li> wrote:








On Jul 25, 2013, at 8:35 AM, Alia Atlas <akatlas@gmail.com> wrote:



> We are likely to add this draft to the list to be discussed in the mee=
ting.  It is discussing some general problems with MTU configuration b=
etween vendors.  While it discusses this for ISIS, some aspects also a=
pply to OSPF.

>

> Basically, there are three problems:

>

> a) Some implementations use L2 MTU and others use the L3 MTU

> b) Different implementations pad and check for different lengths. &nbs=
p;Consequences are that ISIS sessions do not make it to Up.

> c) Different numbers of MPLS labels are assumed as the max, resulting =
in fragmentation, and there are generally no controls for it.

>

> 
http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/









I'm interested in understanding what the authors would like to see from thi=
s.   It would be well outside of the IETF's charter to say that implem=
entations must configure MTU in only one manner.



At best, I see this document as saying 'be consistent', which seems like sp=
itting upwind.



Tony











_______________________________________________

rtgwg mailing list

rtgwg@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/rtgwg






















_______________________________________________

rtgwg mailing list

rtgwg@ietf.org

https://www.i=
etf.org/mailman/listinfo/rtgwg








--_000_8FBB1A9BC64A444B817017A01F26A38Aericssoncom_--

From cpignata@cisco.com  Thu Jul 25 17:58:58 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4923221F8D73 for ; Thu, 25 Jul 2013 17:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level: 
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvnynZgqsZhC for ; Thu, 25 Jul 2013 17:58:53 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7C77521F8CB0 for ; Thu, 25 Jul 2013 17:58:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11446; q=dns/txt; s=iport; t=1374800333; x=1376009933; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VkUNJ8RA0d1HvBlf3kpdFwdyDYo7QqwANGiAnMT+eBI=; b=in3C6Jp9kKLqXfWP9aO+7pQ6EQizHvp3FPnG7IS4WIQjIAIgTX/voC85 oyL7Z4NIgq81ZwBmTUVmLOjPfe0RKkGnYyzw+MVdn9wQWTSIzvdWD4TUq ETkjJUyQc3bez/Wb7Q7c0QaZY9hOIZDnLKqzRjZpl6oebRruSCxlwk/+W E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqkFAIbJ8VGtJXHB/2dsb2JhbABagwY1UKtsiTaIQoEUFnSCJAEBAQMBAQEBawsFCwIBCA4UHQchBgsUEQIEDgUIh3YDCQYMsBYNiF6NFYI3LQQHgxJuA4hyjQSDEop+hSaBW4E5gio
X-IronPort-AV: E=Sophos;i="4.89,746,1367971200";  d="scan'208,217";a="239631320"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 26 Jul 2013 00:58:30 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6Q0wSeY008627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 00:58:28 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 19:58:28 -0500
From: "Carlos Pignataro (cpignata)" 
To: Alia Atlas 
Subject: Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
Thread-Topic: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
Thread-Index: AQHOiUyjjn1kJqZqc0CvF2iLpQ0x2Zl14moAgAAENgCAABqYgIAACHKAgABuB4A=
Date: Fri, 26 Jul 2013 00:58:27 +0000
Message-ID: <95067C434CE250468B77282634C96ED322D53D3E@xmb-aln-x02.cisco.com>
References:  <44303AFD-34F5-482A-B0B9-71D4D6F9B8E0@tony.li>  <95067C434CE250468B77282634C96ED322D51E08@xmb-aln-x02.cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.117.115.56]
Content-Type: multipart/alternative; boundary="_000_95067C434CE250468B77282634C96ED322D53D3Exmbalnx02ciscoc_"
MIME-Version: 1.0
Cc: "" 
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jul 2013 00:58:58 -0000

--_000_95067C434CE250468B77282634C96ED322D53D3Exmbalnx02ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi, Alia,

On Jul 25, 2013, at 2:24 PM, Alia Atlas > wrote:

Carlos,

I'm not surprised that there is lots of vendor documentation.  It's somethi=
ng that has been around for a while.   The question is whether there is any=
thing that might benefit from documentation.

Yes, I agree. If the goal of the effort is to document existing inconsisten=
cies, my initial reaction is that those are well documented already outside=
 the RFC series, and generally well known. On the other hand, I do not thin=
k that an analysis of the issue will cause harm, of course, and can result =
in a reference of use. However, the excerpt I included below states a diffe=
rent goal, which I do not think is realistic, practical, or backwards-compa=
tible :-)

If the document would aim at cataloging different ways of configuring MTU a=
nd warning users about what commands mean, I would also find more value in =
an analysis of MTU configuration requirements (1812/1122/ospf/isis) in addi=
tion to the mostly empiric approach.


   The size of label stack, in particular,  might be interesting...


I agree that the size of the label stack is interesting -- but I sense that=
 this is a bit of a rathole and orthogonal to MTU configuration for an OSPF=
 adjacency to come up. It does cause fragmentation potentially but not inte=
roperability problems. I wonder if the size of the label stack is/should be=
 included in draft-ietf-mpls-forwarding.

Point is to have the discussion.

Exactly. This is my small contribution to it. :-)

Thanks!

-- Carlos.

Alia

On Jul 25, 2013 1:54 PM, "Carlos Pignataro (cpignata)" > wrote:
Alia,

The fact that different vendors use different interpretations of "MTU" in a=
 configuration interface (some L3, some L2 (with/without FCS)) is well know=
n and accounted for while configuring. Many of those config interfaces show=
 "hardware mtu", "protocol mtu", and other proxies for naming labels to imp=
ly which encaps included. There seems to be lots of publicly available docu=
mentation about this.

I was also wondering what the expected output or goal is. Would publishing =
an RFC achieve the goal stated in the I-D?

   for all vender to standardize the MTU configuration in IP
   network and MPLS network.

Or are existing RFCs + vendors' documentation + discussion lists archives e=
nough?

Thanks,

-- Carlos.

On Jul 25, 2013, at 12:19 PM, Alia Atlas > wrote:

Yes - my thought is perhaps a BCP??  It's clearly an interoperability probl=
em.  What is interesting is to discuss the issue and see what could be done=
.

Alia

P.S.  Thanks for the quick reading and response!


On Thu, Jul 25, 2013 at 12:04 PM, Tony Li > wrote:

On Jul 25, 2013, at 8:35 AM, Alia Atlas > wrote:

> We are likely to add this draft to the list to be discussed in the meetin=
g.  It is discussing some general problems with MTU configuration between v=
endors.  While it discusses this for ISIS, some aspects also apply to OSPF.
>
> Basically, there are three problems:
>
> a) Some implementations use L2 MTU and others use the L3 MTU
> b) Different implementations pad and check for different lengths.  Conseq=
uences are that ISIS sessions do not make it to Up.
> c) Different numbers of MPLS labels are assumed as the max, resulting in =
fragmentation, and there are generally no controls for it.
>
> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/


I'm interested in understanding what the authors would like to see from thi=
s.   It would be well outside of the IETF's charter to say that implementat=
ions must configure MTU in only one manner.

At best, I see this document as saying 'be consistent', which seems like sp=
itting upwind.

Tony


_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg


--_000_95067C434CE250468B77282634C96ED322D53D3Exmbalnx02ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <59E8F2D8E49C96429B77F0E2263FF714@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable






Hi, Alia,






On Jul 25, 2013, at 2:24 PM, Alia Atlas <akatlas@gmail.com> wrote:




Carlos,


I'm not surprised that there is lots of vendor documentation=
.  It's something that has been around for a while.   The qu=
estion is whether there is anything that might benefit from documentation.<=
/p>



Yes, I agree. If the goal of the effort is to document existing incons=
istencies, my initial reaction is that those are well documented already ou=
tside the RFC series, and generally well known. On the other hand, I do not=
 think that an analysis of the issue
 will cause harm, of course, and can result in a reference of use. However,=
 the excerpt I included below states a different goal, which I do not think=
 is realistic, practical, or backwards-compatible :-)







If the document would aim at cataloging different ways of configuring =
MTU and warning users about what commands mean, I would also find more valu=
e in an analysis of MTU configuration requirements (1812/1122/ospf/isis) in=
 addition to the mostly empiric
 approach.









   The size of label stack, in particular,  m=
ight be interesting...













I agree that the size of the label stack is interesting -- but I sense=
 that this is a bit of a rathole and orthogonal to MTU configuration for an=
 OSPF adjacency to come up. It does cause fragmentation potentially but not=
 interoperability problems. I wonder
 if the size of the label stack is/should be included in draft-ietf-mp=
ls-forwarding.




Point is to have the discussion. 




Exactly. This is my small contribution to it. :-)







Thanks!







-- Carlos.




Alia


On Jul 25, 2013 1:54 PM, "Carlos Pignataro =
(cpignata)" <cpignata@cisco.c=
om> wrote:




Alia,






The fact that different vendors use different interpretations of "=
;MTU" in a configuration interface (some L3, some L2 (with/without FCS=
)) is well known and accounted for while configuring. Many of those config =
interfaces show "hardware mtu", "protocol
 mtu", and other proxies for naming labels to imply which encaps inclu=
ded. There seems to be lots of publicly available documentation about this.=








I was also wondering what the expected output or goal is. Would publis=
hing an RFC achieve the goal stated in the I-D?




   for all vender to standardize the MTU configuration in IP
   network and MPLS network.


Or are existing RFCs + vendors' documentation + discussion lis=
ts archives enough?









Thanks,







-- Carlos.







On Jul 25, 2013, at 12:19 PM, Alia Atlas <akatlas@gmail.com> wrote:






Yes - my thought is perhaps a BCP??  It's clearly an =
interoperability problem.  What is interesting is to discuss the issue=
 and see what could be done.






Alia







P.S.  Thanks for the quick reading and response!









On Thu, Jul 25, 2013 at 12:04 PM, Tony Li 
<tony.li@tony.li> wrote:








On Jul 25, 2013, at 8:35 AM, Alia Atlas <akatlas@gmail.com> wrote:



> We are likely to add this draft to the list to be discussed in the mee=
ting.  It is discussing some general problems with MTU configuration b=
etween vendors.  While it discusses this for ISIS, some aspects also a=
pply to OSPF.

>

> Basically, there are three problems:

>

> a) Some implementations use L2 MTU and others use the L3 MTU

> b) Different implementations pad and check for different lengths. &nbs=
p;Consequences are that ISIS sessions do not make it to Up.

> c) Different numbers of MPLS labels are assumed as the max, resulting =
in fragmentation, and there are generally no controls for it.

>

> 
http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/









I'm interested in understanding what the authors would like to see from thi=
s.   It would be well outside of the IETF's charter to say that implem=
entations must configure MTU in only one manner.



At best, I see this document as saying 'be consistent', which seems like sp=
itting upwind.



Tony











_______________________________________________

rtgwg mailing list

rtgwg@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/rtgwg















_______________________________________________

rtgwg mailing list

rtgwg@ietf.org

https://www.ietf.org/mailman/listinfo/rtgwg












--_000_95067C434CE250468B77282634C96ED322D53D3Exmbalnx02ciscoc_--

From curtis@ipv6.occnc.com  Sat Jul 27 08:29:51 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D73021F95EF for ; Sat, 27 Jul 2013 08:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level: 
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gNPm1LAcgfL for ; Sat, 27 Jul 2013 08:29:47 -0700 (PDT)
Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACE121F9546 for ; Sat, 27 Jul 2013 08:29:46 -0700 (PDT)
Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r6RFREA0079281; Sat, 27 Jul 2013 11:27:14 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201307271527.r6RFREA0079281@gateway1.orleans.occnc.com>
To: Alia Atlas 
From: Curtis Villamizar 
Subject: Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
In-reply-to: Your message of "Thu, 25 Jul 2013 11:35:28 EDT." 
Date: Sat, 27 Jul 2013 11:27:14 -0400
Cc: "rtgwg@ietf.org" 
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: curtis@ipv6.occnc.com
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Jul 2013 15:29:51 -0000

In message 
Alia Atlas writes:
 
> We are likely to add this draft to the list to be discussed in the
>  meeting.  It is discussing some general problems with MTU
>  configuration between vendors.  While it discusses this for ISIS,
>  some aspects also apply to OSPF.
>  
> Basically, there are three problems:
>  
> a) Some implementations use L2 MTU and others use the L3 MTU
> b) Different implementations pad and check for different lengths.
>    Consequences are that ISIS sessions do not make it to Up.
> c) Different numbers of MPLS labels are assumed as the max, resulting in
>    fragmentation, and there are generally no controls for it.
>  
> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/
>  
> Thanks,
> Alia


First of all, the IGP issue is unique to ISIS and should be fixed in
ISIS.  ISIS pads the LSPDU fragment to the full MTU to verify that the
full MTU is supported.  THis is a misfeature IMHO, but that is the way
it is.  OSPF does not have this misfeature.

The reason that ISIS does this is that IP fragmentation at full line
rate is considered hard to do for high line rates relative to IP
forwarding.  Some **very** old routers did this in software and would
crash if you gave them a full line rate load of packets to fragment.
The ISIS practice of padding to full MTU predated the existance of
MPLS and any use at all of VLAN by providers (who still rarely use
VLAN and probably never in core).  Many routers today can fragment at
full line rate or close to it for average packet sizes (not
tinygrams).  Some can't, but if the rate is very low, they should be
avoided.  Providers need to test for this.  In modern networks, if
most packets are 1532 or smaller, whether the MTU is somewhat over 4K,
somewhat over 8K, or closer to 9K makes no difference.

TCP has Path MTU Discovery (PMTU) which uses the IP "Do Not Fragment"
bit and looks for the ICMP Would Fragment packets as a hint to lower
the MTU.  ISIS could do the same.

Note: Using TCP PMTU has an issue with some (broken IMHO) firewalls
blocking all ICMP, rather than just blocking forms of ICMP that might
be in some way dangerous.  This problem can be avoided by sending only
some packets with "Do Not Fragment" and using SACK to figure out that
those are consistently getting lost (and not counting that as a drop
but rather as an indication to lower the TCP MSS value).

Instead of trying to figure out the *right* value to configure, the
ISIS protocol needs to get smarter about dealing with different values
of MTU, including small variations created by encapsulation in MPLS.

IMHO this should be resubmited as a problem statement to the ISIS WG.

Most providers have already figured out what *they* need to configure
as the MTU on their links and do so by using either program generated
router configurations or using programs to check router configurations
for some level of consistency.  BTW- the 4470 number dates back to POS
wanting to have a larger MTU than FDDI.

As far as configuring a value of 4470 on all routers without ISIS
changes, the provider must first read the vendor literature to find
out what is counted in the MTU, layer-2 MTU or layer-3 MTU and figure
out whether further encapsulation will impact the effective MTU.
Looking at the default value provides a good hint.

If all the traffic coming into a network is at 1532 MTU (or something
in that range) and the provider just wants headroom for PW and other
labels, whether the MTU on some links is 4470 or 4484 (or 9180) makes
no difference at all.  Therefore inconsistencies in values over about
1600 make no difference at all for such a provider.  A control packet
here or there might get fragmented but everything (except ISIS) should
work with minor inconsistencies in the configured MTU.

Curtis

From jeff.tantsura@ericsson.com  Sat Jul 27 09:38:28 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AF421F909A for ; Sat, 27 Jul 2013 09:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTITgHByIuWL for ; Sat, 27 Jul 2013 09:38:23 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0F521F9133 for ; Sat, 27 Jul 2013 09:38:19 -0700 (PDT)
X-AuditID: c6180641-b7f986d000007a82-17-51f3f77a0589
Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D0.21.31362.A77F3F15; Sat, 27 Jul 2013 18:38:18 +0200 (CEST)
Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Sat, 27 Jul 2013 12:38:18 -0400
From: Jeff Tantsura 
To: "" 
Subject: Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
Thread-Topic: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
Thread-Index: AQHOit3FQ+3XWCQX7kCsfb6bXF3yT5l4uar9
Date: Sat, 27 Jul 2013 16:38:18 +0000
Message-ID: <88F3367D-A533-4790-81BD-4778A68052ED@ericsson.com>
References: Your message of "Thu, 25 Jul 2013 11:35:28 EDT." , <201307271527.r6RFREA0079281@gateway1.orleans.occnc.com>
In-Reply-To: <201307271527.r6RFREA0079281@gateway1.orleans.occnc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyuXRPrG7V98+BBvt6bCw+PbzEbDF51hk2 iwtvfjM7MHvsnHWX3WPJkp9MHsvuX2QLYI7isklJzcksSy3St0vgyljcEV/wTani6abf7A2M 36S7GDk5JARMJBa1rGGEsMUkLtxbz9bFyMUhJHCUUeJE2xdWCGc5o8TqQ03sIFVsAgYS/78d ZwGxRQRMJY5taWYCsZkFXCV+LT4IViMsEC1xZtdlZoiaGIlnMy8yQthGEtMWnAeq5+BgEVCV uPQ6FiTMK2Av8W/CI6jFexgl9px9AzaTE2jm7IPn2UBsRqDrvp9aA7VLXOLWk/lMEFcLSCzZ c54ZwhaVePn4HytEjY7Egt2f2CBsbYllC18zQywTlDg58wnLBEbRWUhGzULSMgtJyywkLQsY WVYxcpQWp5blphsZbmIERsgxCTbHHYwLPlkeYpTmYFES592gdyZQSCA9sSQ1OzW1ILUovqg0 J7X4ECMTB6dUA2Ni+mxZuZ5jgtq6F9d3FDjs8m64nD9bQ4rjyaQkj8blF13fa8wVZbuXdejZ gTvNXQ8m3Pk37d1rweWsRzW0FGJYLj0rX9la4vNzEqtip9DzxhS7iCff27dyu9RmZ6tyMO+d ephhnYpnYpBv0dEm2TdR/yr6/vx0n9yUdPSK1LSDyS9mme3ZlarEUpyRaKjFXFScCABFdZ1t XgIAAA==
Cc: "rtgwg@ietf.org" 
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Jul 2013 16:38:29 -0000

Curtis,

In any known OSPF implementation if MTU on both sides doesn't match OSPF wi=
ll get stuck in Exchange/Exstart.=20

Regards,
Jeff

On Jul 27, 2013, at 5:29 PM, "Curtis Villamizar"  wr=
ote:

>=20
> In message 
> Alia Atlas writes:
>=20
>> We are likely to add this draft to the list to be discussed in the
>> meeting.  It is discussing some general problems with MTU
>> configuration between vendors.  While it discusses this for ISIS,
>> some aspects also apply to OSPF.
>>=20
>> Basically, there are three problems:
>>=20
>> a) Some implementations use L2 MTU and others use the L3 MTU
>> b) Different implementations pad and check for different lengths.
>>   Consequences are that ISIS sessions do not make it to Up.
>> c) Different numbers of MPLS labels are assumed as the max, resulting in
>>   fragmentation, and there are generally no controls for it.
>>=20
>> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/
>>=20
>> Thanks,
>> Alia
>=20
>=20
> First of all, the IGP issue is unique to ISIS and should be fixed in
> ISIS.  ISIS pads the LSPDU fragment to the full MTU to verify that the
> full MTU is supported.  THis is a misfeature IMHO, but that is the way
> it is.  OSPF does not have this misfeature.
>=20
> The reason that ISIS does this is that IP fragmentation at full line
> rate is considered hard to do for high line rates relative to IP
> forwarding.  Some **very** old routers did this in software and would
> crash if you gave them a full line rate load of packets to fragment.
> The ISIS practice of padding to full MTU predated the existance of
> MPLS and any use at all of VLAN by providers (who still rarely use
> VLAN and probably never in core).  Many routers today can fragment at
> full line rate or close to it for average packet sizes (not
> tinygrams).  Some can't, but if the rate is very low, they should be
> avoided.  Providers need to test for this.  In modern networks, if
> most packets are 1532 or smaller, whether the MTU is somewhat over 4K,
> somewhat over 8K, or closer to 9K makes no difference.
>=20
> TCP has Path MTU Discovery (PMTU) which uses the IP "Do Not Fragment"
> bit and looks for the ICMP Would Fragment packets as a hint to lower
> the MTU.  ISIS could do the same.
>=20
> Note: Using TCP PMTU has an issue with some (broken IMHO) firewalls
> blocking all ICMP, rather than just blocking forms of ICMP that might
> be in some way dangerous.  This problem can be avoided by sending only
> some packets with "Do Not Fragment" and using SACK to figure out that
> those are consistently getting lost (and not counting that as a drop
> but rather as an indication to lower the TCP MSS value).
>=20
> Instead of trying to figure out the *right* value to configure, the
> ISIS protocol needs to get smarter about dealing with different values
> of MTU, including small variations created by encapsulation in MPLS.
>=20
> IMHO this should be resubmited as a problem statement to the ISIS WG.
>=20
> Most providers have already figured out what *they* need to configure
> as the MTU on their links and do so by using either program generated
> router configurations or using programs to check router configurations
> for some level of consistency.  BTW- the 4470 number dates back to POS
> wanting to have a larger MTU than FDDI.
>=20
> As far as configuring a value of 4470 on all routers without ISIS
> changes, the provider must first read the vendor literature to find
> out what is counted in the MTU, layer-2 MTU or layer-3 MTU and figure
> out whether further encapsulation will impact the effective MTU.
> Looking at the default value provides a good hint.
>=20
> If all the traffic coming into a network is at 1532 MTU (or something
> in that range) and the provider just wants headroom for PW and other
> labels, whether the MTU on some links is 4470 or 4484 (or 9180) makes
> no difference at all.  Therefore inconsistencies in values over about
> 1600 make no difference at all for such a provider.  A control packet
> here or there might get fragmented but everything (except ISIS) should
> work with minor inconsistencies in the configured MTU.
>=20
> Curtis
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg

From acee.lindem@ericsson.com  Sat Jul 27 12:37:08 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AF611E80EF for ; Sat, 27 Jul 2013 12:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVi4v+Dn-pkh for ; Sat, 27 Jul 2013 12:37:02 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7F98611E80ED for ; Sat, 27 Jul 2013 12:37:02 -0700 (PDT)
X-AuditID: c6180641-b7f986d000007a82-d6-51f4215d6323
Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E8.D2.31362.D5124F15; Sat, 27 Jul 2013 21:37:01 +0200 (CEST)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Sat, 27 Jul 2013 15:37:00 -0400
From: Acee Lindem 
To: Jeff Tantsura 
Subject: Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
Thread-Topic: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
Thread-Index: AQHOit3F/ko1ZoYtgEidCRQN96Zexpl4/LcAgAAx7AA=
Date: Sat, 27 Jul 2013 19:36:59 +0000
Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4702FC022F@eusaamb101.ericsson.se>
References: Your message of "Thu, 25 Jul 2013 11:35:28 EDT." , <201307271527.r6RFREA0079281@gateway1.orleans.occnc.com> <88F3367D-A533-4790-81BD-4778A68052ED@ericsson.com>
In-Reply-To: <88F3367D-A533-4790-81BD-4778A68052ED@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <38EEDAA18201F144AEDE81AB5A09CE2F@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXRPoG6s4pdAg5aJVhaTZ51hs7jw5jez A5PHkiU/mTyW3b/IFsAUxWWTkpqTWZZapG+XwJUx40YXc8E/jYpLj14yNzD+U+hi5OSQEDCR WH7vBjuELSZx4d56ti5GLg4hgaOMEnOe7IVyljNKTJ7ygRWkik1AR+L5o3/MILaIgJ7Evj+d YHFmgSiJvgmXmEBsYYFoiTO7LkPVxEg8m3mREcK2kth5cgEbiM0ioCpx//xRsF5eAV+JHe9O QS37yihxpgvkDA4OTgEHiQefQkBqGIGu+35qDRPELnGJW0/mM0FcLSCxZM95ZghbVOLl43+s ELayxJIn+1kg6nUkFuz+xAZhW0tsO/UB6mZtiWULXzND3CAocXLmE5YJjOKzkKyYhaR9FpL2 WUjaZyFpX8DIuoqRo7Q4tSw33chwEyMwro5JsDnuYFzwyfIQozQHi5I47wa9M4FCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGFd57312PfjvlF2NPw1YJr0oWJRilzlJbPcsg16/8+U9BmE1 LW4a26x/POWv23X5+tWn3PHb996YeVTukfd2d68VMtUnJiVs/LLgn7gRW1zYM4MVD8zWPTRI vKqht7Z014nXMuEGVy+EZneZNZe3cpzKEnw8rSrw8Qm23Sl2zhKZDM1h183WCimxFGckGmox FxUnAgD3SflHeQIAAA==
Cc: "rtgwg@ietf.org" 
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Jul 2013 19:37:08 -0000

Hi Jeff - This is true. Most OSPF implementations provide an option to over=
ride the checking. However, I feel this is ill-advised as you can have adja=
cencies that are fine until there is a flap and the side with the larger MT=
U starts sending maximum size OSPF packets which the other side doesn't rec=
eive. The check was added due to all the MTU problems with ATM Emulated LAN=
s where the ATM Forum chose different MTUs than the emulated LANs.=20
Acee=20

On Jul 27, 2013, at 12:38 PM, Jeff Tantsura wrote:

> Curtis,
>=20
> In any known OSPF implementation if MTU on both sides doesn't match OSPF =
will get stuck in Exchange/Exstart.=20
>=20
> Regards,
> Jeff
>=20
> On Jul 27, 2013, at 5:29 PM, "Curtis Villamizar"  =
wrote:
>=20
>>=20
>> In message 
>> Alia Atlas writes:
>>=20
>>> We are likely to add this draft to the list to be discussed in the
>>> meeting.  It is discussing some general problems with MTU
>>> configuration between vendors.  While it discusses this for ISIS,
>>> some aspects also apply to OSPF.
>>>=20
>>> Basically, there are three problems:
>>>=20
>>> a) Some implementations use L2 MTU and others use the L3 MTU
>>> b) Different implementations pad and check for different lengths.
>>>  Consequences are that ISIS sessions do not make it to Up.
>>> c) Different numbers of MPLS labels are assumed as the max, resulting i=
n
>>>  fragmentation, and there are generally no controls for it.
>>>=20
>>> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/
>>>=20
>>> Thanks,
>>> Alia
>>=20
>>=20
>> First of all, the IGP issue is unique to ISIS and should be fixed in
>> ISIS.  ISIS pads the LSPDU fragment to the full MTU to verify that the
>> full MTU is supported.  THis is a misfeature IMHO, but that is the way
>> it is.  OSPF does not have this misfeature.
>>=20
>> The reason that ISIS does this is that IP fragmentation at full line
>> rate is considered hard to do for high line rates relative to IP
>> forwarding.  Some **very** old routers did this in software and would
>> crash if you gave them a full line rate load of packets to fragment.
>> The ISIS practice of padding to full MTU predated the existance of
>> MPLS and any use at all of VLAN by providers (who still rarely use
>> VLAN and probably never in core).  Many routers today can fragment at
>> full line rate or close to it for average packet sizes (not
>> tinygrams).  Some can't, but if the rate is very low, they should be
>> avoided.  Providers need to test for this.  In modern networks, if
>> most packets are 1532 or smaller, whether the MTU is somewhat over 4K,
>> somewhat over 8K, or closer to 9K makes no difference.
>>=20
>> TCP has Path MTU Discovery (PMTU) which uses the IP "Do Not Fragment"
>> bit and looks for the ICMP Would Fragment packets as a hint to lower
>> the MTU.  ISIS could do the same.
>>=20
>> Note: Using TCP PMTU has an issue with some (broken IMHO) firewalls
>> blocking all ICMP, rather than just blocking forms of ICMP that might
>> be in some way dangerous.  This problem can be avoided by sending only
>> some packets with "Do Not Fragment" and using SACK to figure out that
>> those are consistently getting lost (and not counting that as a drop
>> but rather as an indication to lower the TCP MSS value).
>>=20
>> Instead of trying to figure out the *right* value to configure, the
>> ISIS protocol needs to get smarter about dealing with different values
>> of MTU, including small variations created by encapsulation in MPLS.
>>=20
>> IMHO this should be resubmited as a problem statement to the ISIS WG.
>>=20
>> Most providers have already figured out what *they* need to configure
>> as the MTU on their links and do so by using either program generated
>> router configurations or using programs to check router configurations
>> for some level of consistency.  BTW- the 4470 number dates back to POS
>> wanting to have a larger MTU than FDDI.
>>=20
>> As far as configuring a value of 4470 on all routers without ISIS
>> changes, the provider must first read the vendor literature to find
>> out what is counted in the MTU, layer-2 MTU or layer-3 MTU and figure
>> out whether further encapsulation will impact the effective MTU.
>> Looking at the default value provides a good hint.
>>=20
>> If all the traffic coming into a network is at 1532 MTU (or something
>> in that range) and the provider just wants headroom for PW and other
>> labels, whether the MTU on some links is 4470 or 4484 (or 9180) makes
>> no difference at all.  Therefore inconsistencies in values over about
>> 1600 make no difference at all for such a provider.  A control packet
>> here or there might get fragmented but everything (except ISIS) should
>> work with minor inconsistencies in the configured MTU.
>>=20
>> Curtis
>> _______________________________________________
>> rtgwg mailing list
>> rtgwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtgwg
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg


From cmccvic@live.cn  Sun Jul 28 02:21:26 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBAC21F9D6F for ; Sun, 28 Jul 2013 02:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.472
X-Spam-Level: **
X-Spam-Status: No, score=2.472 tagged_above=-999 required=5 tests=[AWL=3.317,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNcr1BRRwqf5 for ; Sun, 28 Jul 2013 02:21:21 -0700 (PDT)
Received: from bay0-omc3-s13.bay0.hotmail.com (bay0-omc3-s13.bay0.hotmail.com [65.54.190.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5333A21F9D7E for ; Sun, 28 Jul 2013 02:21:21 -0700 (PDT)
Received: from BAY176-W21 ([65.54.190.187]) by bay0-omc3-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 28 Jul 2013 02:21:17 -0700
X-TMN: [DVh8gfMVdGuy8o0X92Hz1IyqDFnhON79]
X-Originating-Email: [cmccvic@live.cn]
Message-ID: 
Content-Type: multipart/alternative; boundary="_c002e4ba-92a0-4fd3-82f4-c69017969762_"
From: LiuVic 
To: "rtgwg@ietf.org" 
Subject: RE: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
Date: Sun, 28 Jul 2013 09:21:17 +0000
Importance: Normal
In-Reply-To: <88F3367D-A533-4790-81BD-4778A68052ED@ericsson.com>
References: Your message of "Thu, 25 Jul 2013 11:35:28 EDT.", , , <201307271527.r6RFREA0079281@gateway1.orleans.occnc.com>, <88F3367D-A533-4790-81BD-4778A68052ED@ericsson.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Jul 2013 09:21:17.0684 (UTC) FILETIME=[D08EC340:01CE8B73]
Cc: "caozhen@chinamobile.com" , "huanglu@chinamobile.com" 
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Jul 2013 09:21:26 -0000

--_c002e4ba-92a0-4fd3-82f4-c69017969762_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgQWxsCgpUaGFua3MgZm9yIHRoZSByZWNlbnQgcmVwbHkgYW5kIGRpc2N1c3Npb24uIE1lYW50
aW1lLCBJoa9tIGEgbmV3Y29tZXIgdG8gSUVURiwgVGhhbmtzIHRvCmV2ZXJ5Ym9keSBmb3IgeW91
ciBraW5kIGNvbW1lbnQgYW5kIGhlbHAuIAoKSSB0aGluayB0aGUgY3VycmVudCBkaXNjdXNzaW9u
IGNhbiBiZQpzdW1tYXJpemVkIGFzOgoKMSwgVGhlIHB1cnBvc2Ugb2YgdGhlIGRyYWZ0IGFuZCBw
b2ludCBvZgpvdXIgZGlzY3Vzc2lvbi4KCiAgICAgID4+VGhlCk1UVSBjb25maWd1cmF0aW9uIGFt
b25nIG11bHRpLXZlbmRvciBuZXR3b3JrcyBpcyBhIHByb2JsZW0gdGhhdCB3ZSBmb3VuZCBvbgpu
ZXR3b3JrIG9wZXJhdGlvbiBhbmQgaW50ZXJvcGVyYWJpbGl0eS4gU28gd2Ugd2FudCB0byB1c2Ug
b3VyIG9ic2VydmF0aW9uIHRvCmFyb3VzZSBldmVyeW9uZaGvcyBhdHRlbnRpb24gb24gdGhpcyBp
c3N1ZS4gTWVhbnRpbWUsIHdlIGhvcGUgdGhhdCB3ZSBjYW4gcmVhY2gKYSBjb21tb24gY29uc2Vu
c3VzIG9uIE1UVSBjb25maWd1cmF0aW9uCmJ5IHRoZSBkaXNjdXNzaW9uLgoKMiwgRXhjaXNpbmcg
YW5hbHlzaXMgb2YgTVRVIGNvbmZpZ3VyYXRpb24gZG9jdW1lbnQuIAoKICAgICA+PlRoYW5rcyBl
dmVyeWJvZHkgcHV0IGZvcndhcmQgbWFueSBjb25zdHJ1Y3RpdmUKY29tbWVudHMuIFRoZXJlIGFy
ZSBsb3RzIG9mIHZlbmRvciBkb2N1bWVudCBvbiB0aGlzIGlzc3Vlcy4gSG93ZXZlciwgZHVyaW5n
IG91cgpuZXR3b3JrIG9wZXJhdGlvbiwgaXShr3MgZWFzeSB0byBjYXVzZSBpbnRlcm9wZXJhYmls
aXR5IHByb2JsZW0gYnkgbWlzbWF0Y2ggdGhlIE1UVQpiZXR3ZWVuIHR3byBkaWZmZXJlbnQgdmVu
ZG9yLiBNb3Jlb3ZlciwgaXShr3MgZWFzeSB0byBjYXVzZSBmcmFnbWVudCBieQptaXN1bmRlcnN0
YW5kaW5nIGFuZCBtaXNjYWxjdWxhdGluZyBvZiBNVFUgY29uZmlndXJhdGlvbi4gSSB3b25kZXIg
aXQncyBub3QgZWFzeSB0byAndW5pZmllZCcgdGhlIGNvbmZpZ3JhdGlvbi4gQnV0IHRocm91Z2gg
b3VyIGRpc2N1c3Npb24sIG1ha2UgdGhpcyBpc3N1ZSBtb3JlIGNsZWFyIGFuZCBvdXRwdXQgYSBt
dWx0aS12ZW5kb3Igb3BlcmF0aW9uIGd1aWRlbGluZSBvbiBNVFUgY29uZmlndXJhdGlvbiBjYW4g
YmUgd29ya2FibGUuIAoKMywgVGhlIHNpemUgb2YgbGFiZWwgc3RhY2suCgogICAgID4+dGhlCmxh
YmVsIHN0YWNrIGluIE1QTFMgTVRVIGRvIGNhdXNlIGZyYWdtZW50YXRpb24sIHNvbWVob3cgaXQg
d2lsbCBjYXVzZQppbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zIGJ5IG1pc21hdGNoIE1UVSBpbiBP
U1BGLgoKIAoKVGhhbmtzCnRvIGV2ZXJ5b25lIGFnYWluIGZvciBjb21tZW50cyEKCiAKCkFsbCB0
aGUKQmVzdCEKClZpYw0KPiBGcm9tOiBqZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbQ0KPiBUbzog
Y3VydGlzQGlwdjYub2NjbmMuY29tDQo+IFN1YmplY3Q6IFJlOiBwbGVhc2UgcmVhZCBhbmQgY29t
bWVudCBvbiB0aGUgTVRVIHByb2JsZW1zIGluCWRyYWZ0LWxpdS1ydGd3Zy1tdHUtY29uZmlnLXBz
DQo+IERhdGU6IFNhdCwgMjcgSnVsIDIwMTMgMTY6Mzg6MTggKzAwMDANCj4gQ0M6IHJ0Z3dnQGll
dGYub3JnDQo+IA0KPiBDdXJ0aXMsDQo+IA0KPiBJbiBhbnkga25vd24gT1NQRiBpbXBsZW1lbnRh
dGlvbiBpZiBNVFUgb24gYm90aCBzaWRlcyBkb2Vzbid0IG1hdGNoIE9TUEYgd2lsbCBnZXQgc3R1
Y2sgaW4gRXhjaGFuZ2UvRXhzdGFydC4gDQo+IA0KPiBSZWdhcmRzLA0KPiBKZWZmDQo+IA0KPiBP
biBKdWwgMjcsIDIwMTMsIGF0IDU6MjkgUE0sICJDdXJ0aXMgVmlsbGFtaXphciIgPGN1cnRpc0Bp
cHY2Lm9jY25jLmNvbT4gd3JvdGU6DQo+IA0KPiA+IA0KPiA+IEluIG1lc3NhZ2UgPENBRzRkMXJk
enBHRkx3MVoxWEZSWWdoMkoxVFNZUzBWTGJONFZtc1FUTEtaMy10VnpwUUBtYWlsLmdtYWlsLmNv
bT4NCj4gPiBBbGlhIEF0bGFzIHdyaXRlczoNCj4gPiANCj4gPj4gV2UgYXJlIGxpa2VseSB0byBh
ZGQgdGhpcyBkcmFmdCB0byB0aGUgbGlzdCB0byBiZSBkaXNjdXNzZWQgaW4gdGhlDQo+ID4+IG1l
ZXRpbmcuICBJdCBpcyBkaXNjdXNzaW5nIHNvbWUgZ2VuZXJhbCBwcm9ibGVtcyB3aXRoIE1UVQ0K
PiA+PiBjb25maWd1cmF0aW9uIGJldHdlZW4gdmVuZG9ycy4gIFdoaWxlIGl0IGRpc2N1c3NlcyB0
aGlzIGZvciBJU0lTLA0KPiA+PiBzb21lIGFzcGVjdHMgYWxzbyBhcHBseSB0byBPU1BGLg0KPiA+
PiANCj4gPj4gQmFzaWNhbGx5LCB0aGVyZSBhcmUgdGhyZWUgcHJvYmxlbXM6DQo+ID4+IA0KPiA+
PiBhKSBTb21lIGltcGxlbWVudGF0aW9ucyB1c2UgTDIgTVRVIGFuZCBvdGhlcnMgdXNlIHRoZSBM
MyBNVFUNCj4gPj4gYikgRGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyBwYWQgYW5kIGNoZWNrIGZv
ciBkaWZmZXJlbnQgbGVuZ3Rocy4NCj4gPj4gICBDb25zZXF1ZW5jZXMgYXJlIHRoYXQgSVNJUyBz
ZXNzaW9ucyBkbyBub3QgbWFrZSBpdCB0byBVcC4NCj4gPj4gYykgRGlmZmVyZW50IG51bWJlcnMg
b2YgTVBMUyBsYWJlbHMgYXJlIGFzc3VtZWQgYXMgdGhlIG1heCwgcmVzdWx0aW5nIGluDQo+ID4+
ICAgZnJhZ21lbnRhdGlvbiwgYW5kIHRoZXJlIGFyZSBnZW5lcmFsbHkgbm8gY29udHJvbHMgZm9y
IGl0Lg0KPiA+PiANCj4gPj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1s
aXUtcnRnd2ctbXR1LWNvbmZpZy1wcy8NCj4gPj4gDQo+ID4+IFRoYW5rcywNCj4gPj4gQWxpYQ0K
PiA+IA0KPiA+IA0KPiA+IEZpcnN0IG9mIGFsbCwgdGhlIElHUCBpc3N1ZSBpcyB1bmlxdWUgdG8g
SVNJUyBhbmQgc2hvdWxkIGJlIGZpeGVkIGluDQo+ID4gSVNJUy4gIElTSVMgcGFkcyB0aGUgTFNQ
RFUgZnJhZ21lbnQgdG8gdGhlIGZ1bGwgTVRVIHRvIHZlcmlmeSB0aGF0IHRoZQ0KPiA+IGZ1bGwg
TVRVIGlzIHN1cHBvcnRlZC4gIFRIaXMgaXMgYSBtaXNmZWF0dXJlIElNSE8sIGJ1dCB0aGF0IGlz
IHRoZSB3YXkNCj4gPiBpdCBpcy4gIE9TUEYgZG9lcyBub3QgaGF2ZSB0aGlzIG1pc2ZlYXR1cmUu
DQo+ID4gDQo+ID4gVGhlIHJlYXNvbiB0aGF0IElTSVMgZG9lcyB0aGlzIGlzIHRoYXQgSVAgZnJh
Z21lbnRhdGlvbiBhdCBmdWxsIGxpbmUNCj4gPiByYXRlIGlzIGNvbnNpZGVyZWQgaGFyZCB0byBk
byBmb3IgaGlnaCBsaW5lIHJhdGVzIHJlbGF0aXZlIHRvIElQDQo+ID4gZm9yd2FyZGluZy4gIFNv
bWUgKip2ZXJ5Kiogb2xkIHJvdXRlcnMgZGlkIHRoaXMgaW4gc29mdHdhcmUgYW5kIHdvdWxkDQo+
ID4gY3Jhc2ggaWYgeW91IGdhdmUgdGhlbSBhIGZ1bGwgbGluZSByYXRlIGxvYWQgb2YgcGFja2V0
cyB0byBmcmFnbWVudC4NCj4gPiBUaGUgSVNJUyBwcmFjdGljZSBvZiBwYWRkaW5nIHRvIGZ1bGwg
TVRVIHByZWRhdGVkIHRoZSBleGlzdGFuY2Ugb2YNCj4gPiBNUExTIGFuZCBhbnkgdXNlIGF0IGFs
bCBvZiBWTEFOIGJ5IHByb3ZpZGVycyAod2hvIHN0aWxsIHJhcmVseSB1c2UNCj4gPiBWTEFOIGFu
ZCBwcm9iYWJseSBuZXZlciBpbiBjb3JlKS4gIE1hbnkgcm91dGVycyB0b2RheSBjYW4gZnJhZ21l
bnQgYXQNCj4gPiBmdWxsIGxpbmUgcmF0ZSBvciBjbG9zZSB0byBpdCBmb3IgYXZlcmFnZSBwYWNr
ZXQgc2l6ZXMgKG5vdA0KPiA+IHRpbnlncmFtcykuICBTb21lIGNhbid0LCBidXQgaWYgdGhlIHJh
dGUgaXMgdmVyeSBsb3csIHRoZXkgc2hvdWxkIGJlDQo+ID4gYXZvaWRlZC4gIFByb3ZpZGVycyBu
ZWVkIHRvIHRlc3QgZm9yIHRoaXMuICBJbiBtb2Rlcm4gbmV0d29ya3MsIGlmDQo+ID4gbW9zdCBw
YWNrZXRzIGFyZSAxNTMyIG9yIHNtYWxsZXIsIHdoZXRoZXIgdGhlIE1UVSBpcyBzb21ld2hhdCBv
dmVyIDRLLA0KPiA+IHNvbWV3aGF0IG92ZXIgOEssIG9yIGNsb3NlciB0byA5SyBtYWtlcyBubyBk
aWZmZXJlbmNlLg0KPiA+IA0KPiA+IFRDUCBoYXMgUGF0aCBNVFUgRGlzY292ZXJ5IChQTVRVKSB3
aGljaCB1c2VzIHRoZSBJUCAiRG8gTm90IEZyYWdtZW50Ig0KPiA+IGJpdCBhbmQgbG9va3MgZm9y
IHRoZSBJQ01QIFdvdWxkIEZyYWdtZW50IHBhY2tldHMgYXMgYSBoaW50IHRvIGxvd2VyDQo+ID4g
dGhlIE1UVS4gIElTSVMgY291bGQgZG8gdGhlIHNhbWUuDQo+ID4gDQo+ID4gTm90ZTogVXNpbmcg
VENQIFBNVFUgaGFzIGFuIGlzc3VlIHdpdGggc29tZSAoYnJva2VuIElNSE8pIGZpcmV3YWxscw0K
PiA+IGJsb2NraW5nIGFsbCBJQ01QLCByYXRoZXIgdGhhbiBqdXN0IGJsb2NraW5nIGZvcm1zIG9m
IElDTVAgdGhhdCBtaWdodA0KPiA+IGJlIGluIHNvbWUgd2F5IGRhbmdlcm91cy4gIFRoaXMgcHJv
YmxlbSBjYW4gYmUgYXZvaWRlZCBieSBzZW5kaW5nIG9ubHkNCj4gPiBzb21lIHBhY2tldHMgd2l0
aCAiRG8gTm90IEZyYWdtZW50IiBhbmQgdXNpbmcgU0FDSyB0byBmaWd1cmUgb3V0IHRoYXQNCj4g
PiB0aG9zZSBhcmUgY29uc2lzdGVudGx5IGdldHRpbmcgbG9zdCAoYW5kIG5vdCBjb3VudGluZyB0
aGF0IGFzIGEgZHJvcA0KPiA+IGJ1dCByYXRoZXIgYXMgYW4gaW5kaWNhdGlvbiB0byBsb3dlciB0
aGUgVENQIE1TUyB2YWx1ZSkuDQo+ID4gDQo+ID4gSW5zdGVhZCBvZiB0cnlpbmcgdG8gZmlndXJl
IG91dCB0aGUgKnJpZ2h0KiB2YWx1ZSB0byBjb25maWd1cmUsIHRoZQ0KPiA+IElTSVMgcHJvdG9j
b2wgbmVlZHMgdG8gZ2V0IHNtYXJ0ZXIgYWJvdXQgZGVhbGluZyB3aXRoIGRpZmZlcmVudCB2YWx1
ZXMNCj4gPiBvZiBNVFUsIGluY2x1ZGluZyBzbWFsbCB2YXJpYXRpb25zIGNyZWF0ZWQgYnkgZW5j
YXBzdWxhdGlvbiBpbiBNUExTLg0KPiA+IA0KPiA+IElNSE8gdGhpcyBzaG91bGQgYmUgcmVzdWJt
aXRlZCBhcyBhIHByb2JsZW0gc3RhdGVtZW50IHRvIHRoZSBJU0lTIFdHLg0KPiA+IA0KPiA+IE1v
c3QgcHJvdmlkZXJzIGhhdmUgYWxyZWFkeSBmaWd1cmVkIG91dCB3aGF0ICp0aGV5KiBuZWVkIHRv
IGNvbmZpZ3VyZQ0KPiA+IGFzIHRoZSBNVFUgb24gdGhlaXIgbGlua3MgYW5kIGRvIHNvIGJ5IHVz
aW5nIGVpdGhlciBwcm9ncmFtIGdlbmVyYXRlZA0KPiA+IHJvdXRlciBjb25maWd1cmF0aW9ucyBv
ciB1c2luZyBwcm9ncmFtcyB0byBjaGVjayByb3V0ZXIgY29uZmlndXJhdGlvbnMNCj4gPiBmb3Ig
c29tZSBsZXZlbCBvZiBjb25zaXN0ZW5jeS4gIEJUVy0gdGhlIDQ0NzAgbnVtYmVyIGRhdGVzIGJh
Y2sgdG8gUE9TDQo+ID4gd2FudGluZyB0byBoYXZlIGEgbGFyZ2VyIE1UVSB0aGFuIEZEREkuDQo+
ID4gDQo+ID4gQXMgZmFyIGFzIGNvbmZpZ3VyaW5nIGEgdmFsdWUgb2YgNDQ3MCBvbiBhbGwgcm91
dGVycyB3aXRob3V0IElTSVMNCj4gPiBjaGFuZ2VzLCB0aGUgcHJvdmlkZXIgbXVzdCBmaXJzdCBy
ZWFkIHRoZSB2ZW5kb3IgbGl0ZXJhdHVyZSB0byBmaW5kDQo+ID4gb3V0IHdoYXQgaXMgY291bnRl
ZCBpbiB0aGUgTVRVLCBsYXllci0yIE1UVSBvciBsYXllci0zIE1UVSBhbmQgZmlndXJlDQo+ID4g
b3V0IHdoZXRoZXIgZnVydGhlciBlbmNhcHN1bGF0aW9uIHdpbGwgaW1wYWN0IHRoZSBlZmZlY3Rp
dmUgTVRVLg0KPiA+IExvb2tpbmcgYXQgdGhlIGRlZmF1bHQgdmFsdWUgcHJvdmlkZXMgYSBnb29k
IGhpbnQuDQo+ID4gDQo+ID4gSWYgYWxsIHRoZSB0cmFmZmljIGNvbWluZyBpbnRvIGEgbmV0d29y
ayBpcyBhdCAxNTMyIE1UVSAob3Igc29tZXRoaW5nDQo+ID4gaW4gdGhhdCByYW5nZSkgYW5kIHRo
ZSBwcm92aWRlciBqdXN0IHdhbnRzIGhlYWRyb29tIGZvciBQVyBhbmQgb3RoZXINCj4gPiBsYWJl
bHMsIHdoZXRoZXIgdGhlIE1UVSBvbiBzb21lIGxpbmtzIGlzIDQ0NzAgb3IgNDQ4NCAob3IgOTE4
MCkgbWFrZXMNCj4gPiBubyBkaWZmZXJlbmNlIGF0IGFsbC4gIFRoZXJlZm9yZSBpbmNvbnNpc3Rl
bmNpZXMgaW4gdmFsdWVzIG92ZXIgYWJvdXQNCj4gPiAxNjAwIG1ha2Ugbm8gZGlmZmVyZW5jZSBh
dCBhbGwgZm9yIHN1Y2ggYSBwcm92aWRlci4gIEEgY29udHJvbCBwYWNrZXQNCj4gPiBoZXJlIG9y
IHRoZXJlIG1pZ2h0IGdldCBmcmFnbWVudGVkIGJ1dCBldmVyeXRoaW5nIChleGNlcHQgSVNJUykg
c2hvdWxkDQo+ID4gd29yayB3aXRoIG1pbm9yIGluY29uc2lzdGVuY2llcyBpbiB0aGUgY29uZmln
dXJlZCBNVFUuDQo+ID4gDQo+ID4gQ3VydGlzDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBydGd3ZyBtYWlsaW5nIGxpc3QNCj4gPiBydGd3
Z0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRn
d2cNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
cnRnd2cgbWFpbGluZyBsaXN0DQo+IHJ0Z3dnQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2cNCiAJCSAJICAgCQkgIA==

--_c002e4ba-92a0-4fd3-82f4-c69017969762_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7
DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv
bnQtZmFtaWx5Os6iyO3RxbraDQp9DQotLT48L3N0eWxlPjwvaGVhZD4NCjxib2R5IGNsYXNzPSdo
bW1lc3NhZ2UnPjxkaXYgZGlyPSdsdHInPjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgYmFja2dyb3VuZC1w
b3NpdGlvbjogaW5pdGlhbCBpbml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0
aWFsOyI+SGkgQWxsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdDtmb250LWZhbWlseTrLzszlO21zby1iaWRpLWZvbnQtZmFtaWx5OsvOzOU7Cm1zby1mb250
LWtlcm5pbmc6MHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+Cgo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBhbGlnbj0ibGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEycHQ7
Ij5UaGFua3MgZm9yIHRoZSByZWNlbnQgcmVwbHkgYW5kIGRpc2N1c3Npb248L3NwYW4+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij4uIE1lYW50aW1lLCBJoa9tIGEg
bmV3Y29tZXIgdG8gSUVURiwgVGhhbmtzIHRvCmV2ZXJ5Ym9keSBmb3IgeW91ciBraW5kIGNvbW1l
bnQgYW5kIGhlbHAuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IGFsaWduPSJsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsi
PkkgdGhpbmsgdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbiBjYW4gYmUKc3VtbWFyaXplZCBhczo8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+Cgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij4xLCBUaGUgcHVycG9zZSBv
ZiB0aGUgZHJhZnQgYW5kIHBvaW50IG9mCm91ciBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4KCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAmZ3Q7Jmd0O1RoZQpNVFUgY29uZmlndXJhdGlvbiBhbW9uZyBtdWx0aS12ZW5kb3IgbmV0d29y
a3MgaXMgYSBwcm9ibGVtIHRoYXQgd2UgZm91bmQgb24KbmV0d29yayBvcGVyYXRpb24gYW5kIGlu
dGVyb3BlcmFiaWxpdHkuIFNvIHdlIHdhbnQgdG8gdXNlIG91ciBvYnNlcnZhdGlvbiB0bwphcm91
c2UgZXZlcnlvbmWhr3MgYXR0ZW50aW9uIG9uIHRoaXMgaXNzdWUuIE1lYW50aW1lLCB3ZSBob3Bl
IHRoYXQgd2UgY2FuIHJlYWNoCmEgY29tbW9uIGNvbnNlbnN1cyBvbiA8L3NwYW4+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij5NVFUgY29uZmlndXJhdGlvbgpieSB0
aGUgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+Cgo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBhbGlnbj0ibGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEycHQ7
Ij4yLCBFeGNpc2luZyBhbmFseXNpcyBvZiBNVFUgY29uZmlndXJhdGlvbiBkb2N1bWVudC4gPG86
cD48L286cD48L3NwYW4+PC9wPgoKPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0
eWxlPSJ0ZXh0LWluZGVudDogMTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOiAxMnB0OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jmd0O1RoYW5rcyBldmVyeWJvZHkg
cHV0IGZvcndhcmQgbWFueSBjb25zdHJ1Y3RpdmUKY29tbWVudHMuIFRoZXJlIGFyZSBsb3RzIG9m
IHZlbmRvciBkb2N1bWVudCBvbiB0aGlzIGlzc3Vlcy4gSG93ZXZlciwgZHVyaW5nIG91cgpuZXR3
b3JrIG9wZXJhdGlvbiwgaXShr3MgZWFzeSB0byBjYXVzZSBpbnRlcm9wZXJhYmlsaXR5IHByb2Js
ZW0gYnkgbWlzbWF0Y2ggdGhlIE1UVQpiZXR3ZWVuIHR3byBkaWZmZXJlbnQgdmVuZG9yLiBNb3Jl
b3ZlciwgaXShr3MgZWFzeSB0byBjYXVzZSBmcmFnbWVudCBieQptaXN1bmRlcnN0YW5kaW5nIGFu
ZCBtaXNjYWxjdWxhdGluZyBvZiBNVFUgY29uZmlndXJhdGlvbi4gSSB3b25kZXIgaXQncyBub3Qg
ZWFzeSB0byAndW5pZmllZCcgdGhlIGNvbmZpZ3JhdGlvbi4gQnV0IHRocm91Z2ggb3VyIGRpc2N1
c3Npb24sIG1ha2UgdGhpcyBpc3N1ZSBtb3JlIGNsZWFyIGFuZCBvdXRwdXQgYSBtdWx0aS12ZW5k
b3Igb3BlcmF0aW9uIGd1aWRlbGluZSBvbiBNVFUgY29uZmlndXJhdGlvbiBjYW4gYmUgd29ya2Fi
bGUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPgoKPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp
Z249ImxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyI+Mywg
VGhlIHNpemUgb2YgbGFiZWwgc3RhY2suPG86cD48L286cD48L3NwYW4+PC9wPgoKPHAgY2xhc3M9
Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWluZGVudDogMTJwdDsiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyI+Jm5ic3A7ICZuYnNwOyAmbmJz
cDsmZ3Q7Jmd0O3RoZQpsYWJlbCBzdGFjayBpbiBNUExTIE1UVSBkbyBjYXVzZSBmcmFnbWVudGF0
aW9uLCBzb21laG93IGl0IHdpbGwgY2F1c2UKaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcyBieSBt
aXNtYXRjaCBNVFUgaW4gT1NQRi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+Cgo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtaW5kZW50OiAxMnB0OyI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9wPgoKPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWluZGVudDogMTJwdDsi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyI+VGhhbmtzCnRvIGV2
ZXJ5b25lIGFnYWluIGZvciBjb21tZW50cyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+Cgo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtaW5kZW50OiAxMnB0OyI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9w
PgoKPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWluZGVudDog
MTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyI+QWxsIHRo
ZQpCZXN0ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu
PSJsZWZ0IiBzdHlsZT0idGV4dC1pbmRlbnQ6IDEycHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZTogMTJwdDsiPlZpYzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48
L286cD48L3NwYW4+PC9wPjxicj48ZGl2PiZndDsgRnJvbTogamVmZi50YW50c3VyYUBlcmljc3Nv
bi5jb208YnI+Jmd0OyBUbzogY3VydGlzQGlwdjYub2NjbmMuY29tPGJyPiZndDsgU3ViamVjdDog
UmU6IHBsZWFzZSByZWFkIGFuZCBjb21tZW50IG9uIHRoZSBNVFUgcHJvYmxlbXMgaW4JZHJhZnQt
bGl1LXJ0Z3dnLW10dS1jb25maWctcHM8YnI+Jmd0OyBEYXRlOiBTYXQsIDI3IEp1bCAyMDEzIDE2
OjM4OjE4ICswMDAwPGJyPiZndDsgQ0M6IHJ0Z3dnQGlldGYub3JnPGJyPiZndDsgPGJyPiZndDsg
Q3VydGlzLDxicj4mZ3Q7IDxicj4mZ3Q7IEluIGFueSBrbm93biBPU1BGIGltcGxlbWVudGF0aW9u
IGlmIE1UVSBvbiBib3RoIHNpZGVzIGRvZXNuJ3QgbWF0Y2ggT1NQRiB3aWxsIGdldCBzdHVjayBp
biBFeGNoYW5nZS9FeHN0YXJ0LiA8YnI+Jmd0OyA8YnI+Jmd0OyBSZWdhcmRzLDxicj4mZ3Q7IEpl
ZmY8YnI+Jmd0OyA8YnI+Jmd0OyBPbiBKdWwgMjcsIDIwMTMsIGF0IDU6MjkgUE0sICJDdXJ0aXMg
VmlsbGFtaXphciIgJmx0O2N1cnRpc0BpcHY2Lm9jY25jLmNvbSZndDsgd3JvdGU6PGJyPiZndDsg
PGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IEluIG1lc3NhZ2UgJmx0O0NBRzRkMXJkenBHRkx3
MVoxWEZSWWdoMkoxVFNZUzBWTGJONFZtc1FUTEtaMy10VnpwUUBtYWlsLmdtYWlsLmNvbSZndDs8
YnI+Jmd0OyAmZ3Q7IEFsaWEgQXRsYXMgd3JpdGVzOjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0
OyZndDsgV2UgYXJlIGxpa2VseSB0byBhZGQgdGhpcyBkcmFmdCB0byB0aGUgbGlzdCB0byBiZSBk
aXNjdXNzZWQgaW4gdGhlPGJyPiZndDsgJmd0OyZndDsgbWVldGluZy4gIEl0IGlzIGRpc2N1c3Np
bmcgc29tZSBnZW5lcmFsIHByb2JsZW1zIHdpdGggTVRVPGJyPiZndDsgJmd0OyZndDsgY29uZmln
dXJhdGlvbiBiZXR3ZWVuIHZlbmRvcnMuICBXaGlsZSBpdCBkaXNjdXNzZXMgdGhpcyBmb3IgSVNJ
Uyw8YnI+Jmd0OyAmZ3Q7Jmd0OyBzb21lIGFzcGVjdHMgYWxzbyBhcHBseSB0byBPU1BGLjxicj4m
Z3Q7ICZndDsmZ3Q7IDxicj4mZ3Q7ICZndDsmZ3Q7IEJhc2ljYWxseSwgdGhlcmUgYXJlIHRocmVl
IHByb2JsZW1zOjxicj4mZ3Q7ICZndDsmZ3Q7IDxicj4mZ3Q7ICZndDsmZ3Q7IGEpIFNvbWUgaW1w
bGVtZW50YXRpb25zIHVzZSBMMiBNVFUgYW5kIG90aGVycyB1c2UgdGhlIEwzIE1UVTxicj4mZ3Q7
ICZndDsmZ3Q7IGIpIERpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgcGFkIGFuZCBjaGVjayBmb3Ig
ZGlmZmVyZW50IGxlbmd0aHMuPGJyPiZndDsgJmd0OyZndDsgICBDb25zZXF1ZW5jZXMgYXJlIHRo
YXQgSVNJUyBzZXNzaW9ucyBkbyBub3QgbWFrZSBpdCB0byBVcC48YnI+Jmd0OyAmZ3Q7Jmd0OyBj
KSBEaWZmZXJlbnQgbnVtYmVycyBvZiBNUExTIGxhYmVscyBhcmUgYXNzdW1lZCBhcyB0aGUgbWF4
LCByZXN1bHRpbmcgaW48YnI+Jmd0OyAmZ3Q7Jmd0OyAgIGZyYWdtZW50YXRpb24sIGFuZCB0aGVy
ZSBhcmUgZ2VuZXJhbGx5IG5vIGNvbnRyb2xzIGZvciBpdC48YnI+Jmd0OyAmZ3Q7Jmd0OyA8YnI+
Jmd0OyAmZ3Q7Jmd0OyBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1y
dGd3Zy1tdHUtY29uZmlnLXBzLzxicj4mZ3Q7ICZndDsmZ3Q7IDxicj4mZ3Q7ICZndDsmZ3Q7IFRo
YW5rcyw8YnI+Jmd0OyAmZ3Q7Jmd0OyBBbGlhPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IDxi
cj4mZ3Q7ICZndDsgRmlyc3Qgb2YgYWxsLCB0aGUgSUdQIGlzc3VlIGlzIHVuaXF1ZSB0byBJU0lT
IGFuZCBzaG91bGQgYmUgZml4ZWQgaW48YnI+Jmd0OyAmZ3Q7IElTSVMuICBJU0lTIHBhZHMgdGhl
IExTUERVIGZyYWdtZW50IHRvIHRoZSBmdWxsIE1UVSB0byB2ZXJpZnkgdGhhdCB0aGU8YnI+Jmd0
OyAmZ3Q7IGZ1bGwgTVRVIGlzIHN1cHBvcnRlZC4gIFRIaXMgaXMgYSBtaXNmZWF0dXJlIElNSE8s
IGJ1dCB0aGF0IGlzIHRoZSB3YXk8YnI+Jmd0OyAmZ3Q7IGl0IGlzLiAgT1NQRiBkb2VzIG5vdCBo
YXZlIHRoaXMgbWlzZmVhdHVyZS48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgVGhlIHJlYXNv
biB0aGF0IElTSVMgZG9lcyB0aGlzIGlzIHRoYXQgSVAgZnJhZ21lbnRhdGlvbiBhdCBmdWxsIGxp
bmU8YnI+Jmd0OyAmZ3Q7IHJhdGUgaXMgY29uc2lkZXJlZCBoYXJkIHRvIGRvIGZvciBoaWdoIGxp
bmUgcmF0ZXMgcmVsYXRpdmUgdG8gSVA8YnI+Jmd0OyAmZ3Q7IGZvcndhcmRpbmcuICBTb21lICoq
dmVyeSoqIG9sZCByb3V0ZXJzIGRpZCB0aGlzIGluIHNvZnR3YXJlIGFuZCB3b3VsZDxicj4mZ3Q7
ICZndDsgY3Jhc2ggaWYgeW91IGdhdmUgdGhlbSBhIGZ1bGwgbGluZSByYXRlIGxvYWQgb2YgcGFj
a2V0cyB0byBmcmFnbWVudC48YnI+Jmd0OyAmZ3Q7IFRoZSBJU0lTIHByYWN0aWNlIG9mIHBhZGRp
bmcgdG8gZnVsbCBNVFUgcHJlZGF0ZWQgdGhlIGV4aXN0YW5jZSBvZjxicj4mZ3Q7ICZndDsgTVBM
UyBhbmQgYW55IHVzZSBhdCBhbGwgb2YgVkxBTiBieSBwcm92aWRlcnMgKHdobyBzdGlsbCByYXJl
bHkgdXNlPGJyPiZndDsgJmd0OyBWTEFOIGFuZCBwcm9iYWJseSBuZXZlciBpbiBjb3JlKS4gIE1h
bnkgcm91dGVycyB0b2RheSBjYW4gZnJhZ21lbnQgYXQ8YnI+Jmd0OyAmZ3Q7IGZ1bGwgbGluZSBy
YXRlIG9yIGNsb3NlIHRvIGl0IGZvciBhdmVyYWdlIHBhY2tldCBzaXplcyAobm90PGJyPiZndDsg
Jmd0OyB0aW55Z3JhbXMpLiAgU29tZSBjYW4ndCwgYnV0IGlmIHRoZSByYXRlIGlzIHZlcnkgbG93
LCB0aGV5IHNob3VsZCBiZTxicj4mZ3Q7ICZndDsgYXZvaWRlZC4gIFByb3ZpZGVycyBuZWVkIHRv
IHRlc3QgZm9yIHRoaXMuICBJbiBtb2Rlcm4gbmV0d29ya3MsIGlmPGJyPiZndDsgJmd0OyBtb3N0
IHBhY2tldHMgYXJlIDE1MzIgb3Igc21hbGxlciwgd2hldGhlciB0aGUgTVRVIGlzIHNvbWV3aGF0
IG92ZXIgNEssPGJyPiZndDsgJmd0OyBzb21ld2hhdCBvdmVyIDhLLCBvciBjbG9zZXIgdG8gOUsg
bWFrZXMgbm8gZGlmZmVyZW5jZS48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgVENQIGhhcyBQ
YXRoIE1UVSBEaXNjb3ZlcnkgKFBNVFUpIHdoaWNoIHVzZXMgdGhlIElQICJEbyBOb3QgRnJhZ21l
bnQiPGJyPiZndDsgJmd0OyBiaXQgYW5kIGxvb2tzIGZvciB0aGUgSUNNUCBXb3VsZCBGcmFnbWVu
dCBwYWNrZXRzIGFzIGEgaGludCB0byBsb3dlcjxicj4mZ3Q7ICZndDsgdGhlIE1UVS4gIElTSVMg
Y291bGQgZG8gdGhlIHNhbWUuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IE5vdGU6IFVzaW5n
IFRDUCBQTVRVIGhhcyBhbiBpc3N1ZSB3aXRoIHNvbWUgKGJyb2tlbiBJTUhPKSBmaXJld2FsbHM8
YnI+Jmd0OyAmZ3Q7IGJsb2NraW5nIGFsbCBJQ01QLCByYXRoZXIgdGhhbiBqdXN0IGJsb2NraW5n
IGZvcm1zIG9mIElDTVAgdGhhdCBtaWdodDxicj4mZ3Q7ICZndDsgYmUgaW4gc29tZSB3YXkgZGFu
Z2Vyb3VzLiAgVGhpcyBwcm9ibGVtIGNhbiBiZSBhdm9pZGVkIGJ5IHNlbmRpbmcgb25seTxicj4m
Z3Q7ICZndDsgc29tZSBwYWNrZXRzIHdpdGggIkRvIE5vdCBGcmFnbWVudCIgYW5kIHVzaW5nIFNB
Q0sgdG8gZmlndXJlIG91dCB0aGF0PGJyPiZndDsgJmd0OyB0aG9zZSBhcmUgY29uc2lzdGVudGx5
IGdldHRpbmcgbG9zdCAoYW5kIG5vdCBjb3VudGluZyB0aGF0IGFzIGEgZHJvcDxicj4mZ3Q7ICZn
dDsgYnV0IHJhdGhlciBhcyBhbiBpbmRpY2F0aW9uIHRvIGxvd2VyIHRoZSBUQ1AgTVNTIHZhbHVl
KS48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgSW5zdGVhZCBvZiB0cnlpbmcgdG8gZmlndXJl
IG91dCB0aGUgKnJpZ2h0KiB2YWx1ZSB0byBjb25maWd1cmUsIHRoZTxicj4mZ3Q7ICZndDsgSVNJ
UyBwcm90b2NvbCBuZWVkcyB0byBnZXQgc21hcnRlciBhYm91dCBkZWFsaW5nIHdpdGggZGlmZmVy
ZW50IHZhbHVlczxicj4mZ3Q7ICZndDsgb2YgTVRVLCBpbmNsdWRpbmcgc21hbGwgdmFyaWF0aW9u
cyBjcmVhdGVkIGJ5IGVuY2Fwc3VsYXRpb24gaW4gTVBMUy48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7
ICZndDsgSU1ITyB0aGlzIHNob3VsZCBiZSByZXN1Ym1pdGVkIGFzIGEgcHJvYmxlbSBzdGF0ZW1l
bnQgdG8gdGhlIElTSVMgV0cuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IE1vc3QgcHJvdmlk
ZXJzIGhhdmUgYWxyZWFkeSBmaWd1cmVkIG91dCB3aGF0ICp0aGV5KiBuZWVkIHRvIGNvbmZpZ3Vy
ZTxicj4mZ3Q7ICZndDsgYXMgdGhlIE1UVSBvbiB0aGVpciBsaW5rcyBhbmQgZG8gc28gYnkgdXNp
bmcgZWl0aGVyIHByb2dyYW0gZ2VuZXJhdGVkPGJyPiZndDsgJmd0OyByb3V0ZXIgY29uZmlndXJh
dGlvbnMgb3IgdXNpbmcgcHJvZ3JhbXMgdG8gY2hlY2sgcm91dGVyIGNvbmZpZ3VyYXRpb25zPGJy
PiZndDsgJmd0OyBmb3Igc29tZSBsZXZlbCBvZiBjb25zaXN0ZW5jeS4gIEJUVy0gdGhlIDQ0NzAg
bnVtYmVyIGRhdGVzIGJhY2sgdG8gUE9TPGJyPiZndDsgJmd0OyB3YW50aW5nIHRvIGhhdmUgYSBs
YXJnZXIgTVRVIHRoYW4gRkRESS48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgQXMgZmFyIGFz
IGNvbmZpZ3VyaW5nIGEgdmFsdWUgb2YgNDQ3MCBvbiBhbGwgcm91dGVycyB3aXRob3V0IElTSVM8
YnI+Jmd0OyAmZ3Q7IGNoYW5nZXMsIHRoZSBwcm92aWRlciBtdXN0IGZpcnN0IHJlYWQgdGhlIHZl
bmRvciBsaXRlcmF0dXJlIHRvIGZpbmQ8YnI+Jmd0OyAmZ3Q7IG91dCB3aGF0IGlzIGNvdW50ZWQg
aW4gdGhlIE1UVSwgbGF5ZXItMiBNVFUgb3IgbGF5ZXItMyBNVFUgYW5kIGZpZ3VyZTxicj4mZ3Q7
ICZndDsgb3V0IHdoZXRoZXIgZnVydGhlciBlbmNhcHN1bGF0aW9uIHdpbGwgaW1wYWN0IHRoZSBl
ZmZlY3RpdmUgTVRVLjxicj4mZ3Q7ICZndDsgTG9va2luZyBhdCB0aGUgZGVmYXVsdCB2YWx1ZSBw
cm92aWRlcyBhIGdvb2QgaGludC48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgSWYgYWxsIHRo
ZSB0cmFmZmljIGNvbWluZyBpbnRvIGEgbmV0d29yayBpcyBhdCAxNTMyIE1UVSAob3Igc29tZXRo
aW5nPGJyPiZndDsgJmd0OyBpbiB0aGF0IHJhbmdlKSBhbmQgdGhlIHByb3ZpZGVyIGp1c3Qgd2Fu
dHMgaGVhZHJvb20gZm9yIFBXIGFuZCBvdGhlcjxicj4mZ3Q7ICZndDsgbGFiZWxzLCB3aGV0aGVy
IHRoZSBNVFUgb24gc29tZSBsaW5rcyBpcyA0NDcwIG9yIDQ0ODQgKG9yIDkxODApIG1ha2VzPGJy
PiZndDsgJmd0OyBubyBkaWZmZXJlbmNlIGF0IGFsbC4gIFRoZXJlZm9yZSBpbmNvbnNpc3RlbmNp
ZXMgaW4gdmFsdWVzIG92ZXIgYWJvdXQ8YnI+Jmd0OyAmZ3Q7IDE2MDAgbWFrZSBubyBkaWZmZXJl
bmNlIGF0IGFsbCBmb3Igc3VjaCBhIHByb3ZpZGVyLiAgQSBjb250cm9sIHBhY2tldDxicj4mZ3Q7
ICZndDsgaGVyZSBvciB0aGVyZSBtaWdodCBnZXQgZnJhZ21lbnRlZCBidXQgZXZlcnl0aGluZyAo
ZXhjZXB0IElTSVMpIHNob3VsZDxicj4mZ3Q7ICZndDsgd29yayB3aXRoIG1pbm9yIGluY29uc2lz
dGVuY2llcyBpbiB0aGUgY29uZmlndXJlZCBNVFUuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7
IEN1cnRpczxicj4mZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnI+Jmd0OyAmZ3Q7IHJ0Z3dnIG1haWxpbmcgbGlzdDxicj4mZ3Q7ICZndDsg
cnRnd2dAaWV0Zi5vcmc8YnI+Jmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vcnRnd2c8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj4mZ3Q7IHJ0Z3dnIG1haWxpbmcgbGlzdDxicj4mZ3Q7IHJ0Z3dnQGll
dGYub3JnPGJyPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3
Zzxicj48L2Rpdj4gCQkgCSAgIAkJICA8L2Rpdj48L2JvZHk+DQo8L2h0bWw+

--_c002e4ba-92a0-4fd3-82f4-c69017969762_--

From jeff.tantsura@ericsson.com  Sun Jul 28 03:20:50 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADB421F9E21 for ; Sun, 28 Jul 2013 03:20:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbBPdU6HkkiH for ; Sun, 28 Jul 2013 03:20:39 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5959D21F9D4C for ; Sun, 28 Jul 2013 03:20:38 -0700 (PDT)
X-AuditID: c6180641-b7f986d000007a82-15-51f4f07572b6
Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D4.98.31362.570F4F15; Sun, 28 Jul 2013 12:20:37 +0200 (CEST)
Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Sun, 28 Jul 2013 06:20:37 -0400
From: Jeff Tantsura 
To: Acee Lindem 
Subject: Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
Thread-Topic: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
Thread-Index: AQHOi3wa3acuRgGyh0WGUXgQuPmRng==
Date: Sun, 28 Jul 2013 10:20:37 +0000
Message-ID: <60DEDD93F5E54B4AB55647B8B6C7483989AB85@eusaamb109.ericsson.se>
In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4702FC022F@eusaamb101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.5.121010
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7BDA99251ED52F4E8235EC434F409DFE@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXRPrG7phy+BBnuWmVlMnnWGzeLCm9/M DkweS5b8ZPJYdv8iWwBTFJdNSmpOZllqkb5dAldG4/avbAXr9ComNk9ga2C8ptrFyMkhIWAi ce5lCxOELSZx4d56NhBbSOAoo8ThV6ZdjFxA9nJGiQ9TPrOAJNgEDCT+fzsOZosIaEl0vv3O DmIzC0RJ9E24BDZIWCBaYsmhuWwQNTESvbPXsEPYehJzLnWB9bIIqEp0PWtgBrF5Bbwl3t+b wQpicwr4SRxrvQo2hxHooO+n1jBBzBeXuPVkPtShAhJL9pxnhrBFJV4+/gfWKwo0v+3YGXaI uLLEkif7WSB6dSQW7P7EBmFbS7y42Q5la0ssW/ga6gZBiZMzn7BMYBSfhWTdLCTts5C0z0LS PgtJ+wJG1lWMHKXFqWW56UaGmxiBUXVMgs1xB+OCT5aHGKU5WJTEeTfonQkUEkhPLEnNTk0t SC2KLyrNSS0+xMjEwSnVwLje9e68P8t+K5Wvlzip0L/m54v3mm2svw4F5Vt0MZ5uOOFyiP3I 1zWPp6/8F5kcZ/KKWchNlX3l73MxL2Te7b//Mk8w7vnbtz8Pzuo7sPT2mtOK7b9Wskqn7b9y oVi+bc6sHpZZUXdW7F/+5R3nN8VvaS/f3nbYmix78sNu9kx5P8unHJvXh98OVWIpzkg01GIu Kk4EAD5qsGN4AgAA
Cc: "rtgwg@ietf.org" 
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Jul 2013 10:20:50 -0000

Hi Acee,

Which is exactly my point, folks who run OSPF would also benefit :)
Would be great to have a document similar to
draft-ietf-pwe3-vccv-impl-survey-results perhaps with vendor's names in it.

Cheers,
Jeff


-----Original Message-----
From: Acee Lindem Lindem III 
Date: Saturday, July 27, 2013 12:36 PM
To: Jeff  Tantsura 
Cc: "" , "rtgwg@ietf.org"

Subject: Re: please read and comment on the MTU problems
in	draft-liu-rtgwg-mtu-config-ps

>Hi Jeff - This is true. Most OSPF implementations provide an option to
>override the checking. However, I feel this is ill-advised as you can
>have adjacencies that are fine until there is a flap and the side with
>the larger MTU starts sending maximum size OSPF packets which the other
>side doesn't receive. The check was added due to all the MTU problems
>with ATM Emulated LANs where the ATM Forum chose different MTUs than the
>emulated LANs.=20
>Acee=20
>
>On Jul 27, 2013, at 12:38 PM, Jeff Tantsura wrote:
>
>> Curtis,
>>=20
>> In any known OSPF implementation if MTU on both sides doesn't match
>>OSPF will get stuck in Exchange/Exstart.
>>=20
>> Regards,
>> Jeff
>>=20
>> On Jul 27, 2013, at 5:29 PM, "Curtis Villamizar"
>> wrote:
>>=20
>>>=20
>>> In message=20
>>>
>>> Alia Atlas writes:
>>>=20
>>>> We are likely to add this draft to the list to be discussed in the
>>>> meeting.  It is discussing some general problems with MTU
>>>> configuration between vendors.  While it discusses this for ISIS,
>>>> some aspects also apply to OSPF.
>>>>=20
>>>> Basically, there are three problems:
>>>>=20
>>>> a) Some implementations use L2 MTU and others use the L3 MTU
>>>> b) Different implementations pad and check for different lengths.
>>>>  Consequences are that ISIS sessions do not make it to Up.
>>>> c) Different numbers of MPLS labels are assumed as the max, resulting
>>>>in
>>>>  fragmentation, and there are generally no controls for it.
>>>>=20
>>>> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/
>>>>=20
>>>> Thanks,
>>>> Alia
>>>=20
>>>=20
>>> First of all, the IGP issue is unique to ISIS and should be fixed in
>>> ISIS.  ISIS pads the LSPDU fragment to the full MTU to verify that the
>>> full MTU is supported.  THis is a misfeature IMHO, but that is the way
>>> it is.  OSPF does not have this misfeature.
>>>=20
>>> The reason that ISIS does this is that IP fragmentation at full line
>>> rate is considered hard to do for high line rates relative to IP
>>> forwarding.  Some **very** old routers did this in software and would
>>> crash if you gave them a full line rate load of packets to fragment.
>>> The ISIS practice of padding to full MTU predated the existance of
>>> MPLS and any use at all of VLAN by providers (who still rarely use
>>> VLAN and probably never in core).  Many routers today can fragment at
>>> full line rate or close to it for average packet sizes (not
>>> tinygrams).  Some can't, but if the rate is very low, they should be
>>> avoided.  Providers need to test for this.  In modern networks, if
>>> most packets are 1532 or smaller, whether the MTU is somewhat over 4K,
>>> somewhat over 8K, or closer to 9K makes no difference.
>>>=20
>>> TCP has Path MTU Discovery (PMTU) which uses the IP "Do Not Fragment"
>>> bit and looks for the ICMP Would Fragment packets as a hint to lower
>>> the MTU.  ISIS could do the same.
>>>=20
>>> Note: Using TCP PMTU has an issue with some (broken IMHO) firewalls
>>> blocking all ICMP, rather than just blocking forms of ICMP that might
>>> be in some way dangerous.  This problem can be avoided by sending only
>>> some packets with "Do Not Fragment" and using SACK to figure out that
>>> those are consistently getting lost (and not counting that as a drop
>>> but rather as an indication to lower the TCP MSS value).
>>>=20
>>> Instead of trying to figure out the *right* value to configure, the
>>> ISIS protocol needs to get smarter about dealing with different values
>>> of MTU, including small variations created by encapsulation in MPLS.
>>>=20
>>> IMHO this should be resubmited as a problem statement to the ISIS WG.
>>>=20
>>> Most providers have already figured out what *they* need to configure
>>> as the MTU on their links and do so by using either program generated
>>> router configurations or using programs to check router configurations
>>> for some level of consistency.  BTW- the 4470 number dates back to POS
>>> wanting to have a larger MTU than FDDI.
>>>=20
>>> As far as configuring a value of 4470 on all routers without ISIS
>>> changes, the provider must first read the vendor literature to find
>>> out what is counted in the MTU, layer-2 MTU or layer-3 MTU and figure
>>> out whether further encapsulation will impact the effective MTU.
>>> Looking at the default value provides a good hint.
>>>=20
>>> If all the traffic coming into a network is at 1532 MTU (or something
>>> in that range) and the provider just wants headroom for PW and other
>>> labels, whether the MTU on some links is 4470 or 4484 (or 9180) makes
>>> no difference at all.  Therefore inconsistencies in values over about
>>> 1600 make no difference at all for such a provider.  A control packet
>>> here or there might get fragmented but everything (except ISIS) should
>>> work with minor inconsistencies in the configured MTU.
>>>=20
>>> Curtis
>>> _______________________________________________
>>> rtgwg mailing list
>>> rtgwg@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtgwg
>> _______________________________________________
>> rtgwg mailing list
>> rtgwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtgwg
>


From akatlas@gmail.com  Sun Jul 28 04:29:47 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F0521F9D2F for ; Sun, 28 Jul 2013 04:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.523
X-Spam-Level: 
X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mng0QU4qXTaC for ; Sun, 28 Jul 2013 04:29:46 -0700 (PDT)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7CF21F8EB3 for ; Sun, 28 Jul 2013 04:29:46 -0700 (PDT)
Received: by mail-ob0-f179.google.com with SMTP id xk17so7223796obc.24 for ; Sun, 28 Jul 2013 04:29:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=P+8lAWrvFfbhARXvh9W4Eu23Ymcakka7ZHnbhnj3/ZI=; b=su2pKkUZvPivaHvBXFQ0wIa7SGSjmt0HtVHI5heFG0lLS9MxrvF4sNDzCBke98+zUN facZm8HLRqLR6VE5Oxa8xziTCcnAw1I2Smql8S31/5MIM27Oes+E1AtxG/QG4UrSwpaU 7bMKvSuq+D/2fdiN/6H1OQCh8CpxZ/kTODLlA8sXDdqEmApF+57pL9DjAmx1rzC1eU1I Z3RGr+S3QvH2vhLZHLGNrR2K/ZDVTRmFh8kUJXnf0ZVt85OrSQ0RkkaT7bxTZ9wPGhO+ 0JBp7zSCC+AOnYaDICCvD28qiYjFZKhxd2TTZZ5I5weFtJFx0wgn6ZUXVlmLAzReyf3Q vQNA==
MIME-Version: 1.0
X-Received: by 10.50.67.20 with SMTP id j20mr585934igt.36.1375010986041; Sun, 28 Jul 2013 04:29:46 -0700 (PDT)
Received: by 10.64.8.19 with HTTP; Sun, 28 Jul 2013 04:29:45 -0700 (PDT)
In-Reply-To: <60DEDD93F5E54B4AB55647B8B6C7483989AB85@eusaamb109.ericsson.se>
References: <94A203EA12AECE4BA92D42DBFFE0AE4702FC022F@eusaamb101.ericsson.se> <60DEDD93F5E54B4AB55647B8B6C7483989AB85@eusaamb109.ericsson.se>
Date: Sun, 28 Jul 2013 07:29:45 -0400
Message-ID: 
Subject: Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps
From: Alia Atlas 
To: "rtgwg@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7bdc0f4262f58a04e290b17c
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Jul 2013 11:29:48 -0000

--047d7bdc0f4262f58a04e290b17c
Content-Type: text/plain; charset=ISO-8859-1

I've added it to the RTGWG agenda.  Please continue to discuss and think
about what, if any, desired outcome there is...

Volunteers as well as opposed to merely commenting  would be helpful.

Alia


On Sun, Jul 28, 2013 at 6:20 AM, Jeff Tantsura
wrote:

> Hi Acee,
>
> Which is exactly my point, folks who run OSPF would also benefit :)
> Would be great to have a document similar to
> draft-ietf-pwe3-vccv-impl-survey-results perhaps with vendor's names in it.
>
> Cheers,
> Jeff
>
>
> -----Original Message-----
> From: Acee Lindem Lindem III 
> Date: Saturday, July 27, 2013 12:36 PM
> To: Jeff  Tantsura 
> Cc: "" , "rtgwg@ietf.org"
> 
> Subject: Re: please read and comment on the MTU problems
> in      draft-liu-rtgwg-mtu-config-ps
>
> >Hi Jeff - This is true. Most OSPF implementations provide an option to
> >override the checking. However, I feel this is ill-advised as you can
> >have adjacencies that are fine until there is a flap and the side with
> >the larger MTU starts sending maximum size OSPF packets which the other
> >side doesn't receive. The check was added due to all the MTU problems
> >with ATM Emulated LANs where the ATM Forum chose different MTUs than the
> >emulated LANs.
> >Acee
> >
> >On Jul 27, 2013, at 12:38 PM, Jeff Tantsura wrote:
> >
> >> Curtis,
> >>
> >> In any known OSPF implementation if MTU on both sides doesn't match
> >>OSPF will get stuck in Exchange/Exstart.
> >>
> >> Regards,
> >> Jeff
> >>
> >> On Jul 27, 2013, at 5:29 PM, "Curtis Villamizar"
> >> wrote:
> >>
> >>>
> >>> In message
> >>>
> >>> Alia Atlas writes:
> >>>
> >>>> We are likely to add this draft to the list to be discussed in the
> >>>> meeting.  It is discussing some general problems with MTU
> >>>> configuration between vendors.  While it discusses this for ISIS,
> >>>> some aspects also apply to OSPF.
> >>>>
> >>>> Basically, there are three problems:
> >>>>
> >>>> a) Some implementations use L2 MTU and others use the L3 MTU
> >>>> b) Different implementations pad and check for different lengths.
> >>>>  Consequences are that ISIS sessions do not make it to Up.
> >>>> c) Different numbers of MPLS labels are assumed as the max, resulting
> >>>>in
> >>>>  fragmentation, and there are generally no controls for it.
> >>>>
> >>>> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/
> >>>>
> >>>> Thanks,
> >>>> Alia
> >>>
> >>>
> >>> First of all, the IGP issue is unique to ISIS and should be fixed in
> >>> ISIS.  ISIS pads the LSPDU fragment to the full MTU to verify that the
> >>> full MTU is supported.  THis is a misfeature IMHO, but that is the way
> >>> it is.  OSPF does not have this misfeature.
> >>>
> >>> The reason that ISIS does this is that IP fragmentation at full line
> >>> rate is considered hard to do for high line rates relative to IP
> >>> forwarding.  Some **very** old routers did this in software and would
> >>> crash if you gave them a full line rate load of packets to fragment.
> >>> The ISIS practice of padding to full MTU predated the existance of
> >>> MPLS and any use at all of VLAN by providers (who still rarely use
> >>> VLAN and probably never in core).  Many routers today can fragment at
> >>> full line rate or close to it for average packet sizes (not
> >>> tinygrams).  Some can't, but if the rate is very low, they should be
> >>> avoided.  Providers need to test for this.  In modern networks, if
> >>> most packets are 1532 or smaller, whether the MTU is somewhat over 4K,
> >>> somewhat over 8K, or closer to 9K makes no difference.
> >>>
> >>> TCP has Path MTU Discovery (PMTU) which uses the IP "Do Not Fragment"
> >>> bit and looks for the ICMP Would Fragment packets as a hint to lower
> >>> the MTU.  ISIS could do the same.
> >>>
> >>> Note: Using TCP PMTU has an issue with some (broken IMHO) firewalls
> >>> blocking all ICMP, rather than just blocking forms of ICMP that might
> >>> be in some way dangerous.  This problem can be avoided by sending only
> >>> some packets with "Do Not Fragment" and using SACK to figure out that
> >>> those are consistently getting lost (and not counting that as a drop
> >>> but rather as an indication to lower the TCP MSS value).
> >>>
> >>> Instead of trying to figure out the *right* value to configure, the
> >>> ISIS protocol needs to get smarter about dealing with different values
> >>> of MTU, including small variations created by encapsulation in MPLS.
> >>>
> >>> IMHO this should be resubmited as a problem statement to the ISIS WG.
> >>>
> >>> Most providers have already figured out what *they* need to configure
> >>> as the MTU on their links and do so by using either program generated
> >>> router configurations or using programs to check router configurations
> >>> for some level of consistency.  BTW- the 4470 number dates back to POS
> >>> wanting to have a larger MTU than FDDI.
> >>>
> >>> As far as configuring a value of 4470 on all routers without ISIS
> >>> changes, the provider must first read the vendor literature to find
> >>> out what is counted in the MTU, layer-2 MTU or layer-3 MTU and figure
> >>> out whether further encapsulation will impact the effective MTU.
> >>> Looking at the default value provides a good hint.
> >>>
> >>> If all the traffic coming into a network is at 1532 MTU (or something
> >>> in that range) and the provider just wants headroom for PW and other
> >>> labels, whether the MTU on some links is 4470 or 4484 (or 9180) makes
> >>> no difference at all.  Therefore inconsistencies in values over about
> >>> 1600 make no difference at all for such a provider.  A control packet
> >>> here or there might get fragmented but everything (except ISIS) should
> >>> work with minor inconsistencies in the configured MTU.
> >>>
> >>> Curtis
> >>> _______________________________________________
> >>> rtgwg mailing list
> >>> rtgwg@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/rtgwg
> >> _______________________________________________
> >> rtgwg mailing list
> >> rtgwg@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtgwg
> >
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>

--047d7bdc0f4262f58a04e290b17c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I've added it to the RTGWG agenda. =A0Please continue =
to discuss and think about what, if any, desired outcome there is...
Volunteers as well as opposed to merely commenting =A0would be=
 helpful.



Alia

On Sun, Jul 28, 2013 at 6:20 AM, Jeff Tantsura=
 <jeff.tantsura@ericsson.com> wrote:


Hi Acee,



Which is exactly my point, folks who run OSPF would also benefit :)

Would be great to have a document similar to

draft-ietf-pwe3-vccv-impl-survey-results perhaps with vendor's names in=
 it.



Cheers,

Jeff






-----Original Message-----

From: Acee Lindem Lindem III <acee.lindem@ericsson.com>

Date: Saturday, July 27, 2013 12:36 PM

To: Jeff =A0Tantsura <jeff=
.tantsura@ericsson.com>

Cc: "<curtis@ipv6.occnc.co=
m>" <curtis@ipv6.oc=
cnc.com>, "rtgwg@ietf.org=
"


<rtgwg@ietf.org>

Subject: Re: please read and comment on the MTU problems

in =A0 =A0 =A0draft-liu-rtgwg-mtu-config-ps




>Hi Jeff - This is true. M=
ost OSPF implementations provide an option to

>override the checking. However, I feel this is ill-advised as you can
>have adjacencies that are fine until there is a flap and the side with<=
br>
>the larger MTU starts sending maximum size OSPF packets which the other=


>side doesn't receive. The check was added due to all the MTU proble=
ms

>with ATM Emulated LANs where the ATM Forum chose different MTUs than th=
e

>emulated LANs.

>Acee

>

>On Jul 27, 2013, at 12:38 PM, Jeff Tantsura wrote:

>

>> Curtis,

>>

>> In any known OSPF implementation if MTU on both sides doesn't =
match

>>OSPF will get stuck in Exchange/Exstart.

>>

>> Regards,

>> Jeff

>>

>> On Jul 27, 2013, at 5:29 PM, "Curtis Villamizar"

>><curtis@ipv6.occnc.com<=
/a>> wrote:

>>

>>>

>>> In message

>>><CAG4d1rdzpGFLw1Z1XFRYgh2J1TSYS0VLbN4VmsQTLKZ3-tV=
zpQ@mail.gmail.com>

>>> Alia Atlas writes:

>>>

>>>> We are likely to add this draft to the list to be discusse=
d in the

>>>> meeting. =A0It is discussing some general problems with MT=
U

>>>> configuration between vendors. =A0While it discusses this =
for ISIS,

>>>> some aspects also apply to OSPF.

>>>>

>>>> Basically, there are three problems:

>>>>

>>>> a) Some implementations use L2 MTU and others use the L3 M=
TU

>>>> b) Different implementations pad and check for different l=
engths.

>>>> =A0Consequences are that ISIS sessions do not make it to U=
p.

>>>> c) Different numbers of MPLS labels are assumed as the max=
, resulting

>>>>in

>>>> =A0fragmentation, and there are generally no controls for =
it.

>>>>

>>>> http://datatracker.ietf.org/doc/draft-li=
u-rtgwg-mtu-config-ps/

>>>>

>>>> Thanks,

>>>> Alia

>>>

>>>

>>> First of all, the IGP issue is unique to ISIS and should be fi=
xed in

>>> ISIS. =A0ISIS pads the LSPDU fragment to the full MTU to verif=
y that the

>>> full MTU is supported. =A0THis is a misfeature IMHO, but that =
is the way

>>> it is. =A0OSPF does not have this misfeature.

>>>

>>> The reason that ISIS does this is that IP fragmentation at ful=
l line

>>> rate is considered hard to do for high line rates relative to =
IP

>>> forwarding. =A0Some **very** old routers did this in software =
and would

>>> crash if you gave them a full line rate load of packets to fra=
gment.

>>> The ISIS practice of padding to full MTU predated the existanc=
e of

>>> MPLS and any use at all of VLAN by providers (who still rarely=
 use

>>> VLAN and probably never in core). =A0Many routers today can fr=
agment at

>>> full line rate or close to it for average packet sizes (not
>>> tinygrams). =A0Some can't, but if the rate is very low, th=
ey should be

>>> avoided. =A0Providers need to test for this. =A0In modern netw=
orks, if

>>> most packets are 1532 or smaller, whether the MTU is somewhat =
over 4K,

>>> somewhat over 8K, or closer to 9K makes no difference.

>>>

>>> TCP has Path MTU Discovery (PMTU) which uses the IP "Do N=
ot Fragment"

>>> bit and looks for the ICMP Would Fragment packets as a hint to=
 lower

>>> the MTU. =A0ISIS could do the same.

>>>

>>> Note: Using TCP PMTU has an issue with some (broken IMHO) fire=
walls

>>> blocking all ICMP, rather than just blocking forms of ICMP tha=
t might

>>> be in some way dangerous. =A0This problem can be avoided by se=
nding only

>>> some packets with "Do Not Fragment" and using SACK t=
o figure out that

>>> those are consistently getting lost (and not counting that as =
a drop

>>> but rather as an indication to lower the TCP MSS value).

>>>

>>> Instead of trying to figure out the *right* value to configure=
, the

>>> ISIS protocol needs to get smarter about dealing with differen=
t values

>>> of MTU, including small variations created by encapsulation in=
 MPLS.

>>>

>>> IMHO this should be resubmited as a problem statement to the I=
SIS WG.

>>>

>>> Most providers have already figured out what *they* need to co=
nfigure

>>> as the MTU on their links and do so by using either program ge=
nerated

>>> router configurations or using programs to check router config=
urations

>>> for some level of consistency. =A0BTW- the 4470 number dates b=
ack to POS

>>> wanting to have a larger MTU than FDDI.

>>>

>>> As far as configuring a value of 4470 on all routers without I=
SIS

>>> changes, the provider must first read the vendor literature to=
 find

>>> out what is counted in the MTU, layer-2 MTU or layer-3 MTU and=
 figure

>>> out whether further encapsulation will impact the effective MT=
U.

>>> Looking at the default value provides a good hint.

>>>

>>> If all the traffic coming into a network is at 1532 MTU (or so=
mething

>>> in that range) and the provider just wants headroom for PW and=
 other

>>> labels, whether the MTU on some links is 4470 or 4484 (or 9180=
) makes

>>> no difference at all. =A0Therefore inconsistencies in values o=
ver about

>>> 1600 make no difference at all for such a provider. =A0A contr=
ol packet

>>> here or there might get fragmented but everything (except ISIS=
) should

>>> work with minor inconsistencies in the configured MTU.

>>>

>>> Curtis

>>> _______________________________________________

>>> rtgwg mailing list

>>> rtgwg@ietf.org

>>> https://www.ietf.org/mailman/listinfo/rtgwg

>> _______________________________________________

>> rtgwg mailing list

>> rtgwg@ietf.org

>> https://www.ietf.org/mailman/listinfo/rtgwg

>



_______________________________________________

rtgwg mailing list

rtgwg@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/rtgwg





--047d7bdc0f4262f58a04e290b17c--

From lars@netapp.com  Sun Jul 28 04:11:03 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E5D21F9CDC for ; Sun, 28 Jul 2013 04:11:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.144
X-Spam-Level: 
X-Spam-Status: No, score=-9.144 tagged_above=-999 required=5 tests=[AWL=1.455,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lx5FAmmnes+Q for ; Sun, 28 Jul 2013 04:10:55 -0700 (PDT)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id E183721F90CC for ; Sun, 28 Jul 2013 04:10:54 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.89,763,1367996400"; d="scan'208";a="76686465"
Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 28 Jul 2013 04:10:54 -0700
Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Sun, 28 Jul 2013 04:10:54 -0700
From: "Eggert, Lars" 
To: "rtgwg@ietf.org" , "rrg@irtf.org" 
Subject: ANRP winner talk on BGP in IRTFOPEN
Thread-Topic: ANRP winner talk on BGP in IRTFOPEN
Thread-Index: AQHOi4MgdxUVZ+bK70CWy+9ojKwmaQ==
Date: Sun, 28 Jul 2013 11:10:53 +0000
Message-ID: <48F3A5A0-E0BB-4622-8285-0C33CFD9A956@netapp.com>
References: <76B78224-2A21-48F2-94ED-FE5CFD32A2BC@netapp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.104.60.115]
Content-Type: text/plain; charset="utf-8"
Content-ID: <8CBA39929292F549A8813F36A107BF8F@hq.netapp.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Mailman-Approved-At: Sun, 28 Jul 2013 04:41:22 -0700
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Jul 2013 11:11:03 -0000

SGksDQoNCnRoZSBmb2xsb3dpbmcgdGFsayBieSBBTlJQIDIwMTMgcHJpemUgd2lubmVyIExhdXJl
bnQgVmFuYmV2ZXIgaXMgcHJvYmFibHkgb2YgaW50ZXJlc3QgdG8gc29tZSByb3V0aW5nIGZvbGtz
LiBUaGUgdGFsayB3aWxsIHN0YXJ0IGF0IGFwcHJveC4gMTA6MDBBTSBvbiBUdWVzZGF5Og0KDQo+
ICAgICoqKiBMQVVSRU5UIFZBTkJFVkVSICoqKiBmb3IgcHJvcG9zaW5nIGEgZnJhbWV3b3JrIHRv
IGFsbG93IHNlYW1sZXNzDQo+ICAgIEJHUCByZWNvbmZpZ3VyYXRpb25zOg0KPiANCj4gICAgICAg
IFN0ZWZhbm8gVmlzc2ljY2hpbywgTGF1cmVudCBWYW5iZXZlciwgQ3Jpc3RlbCBQZWxzc2VyLCBM
dWNhDQo+ICAgICAgICBDaXR0YWRpbmksIFBpZXJyZSBGcmFuY29pcyBhbmQgT2xpdmllciBCb25h
dmVudHVyZS4gSW1wcm92aW5nDQo+ICAgICAgICBOZXR3b3JrIEFnaWxpdHkgd2l0aCBTZWFtbGVz
cyBCR1AgUmVjb27vrIFndXJhdGlvbnMuIFByb2MuIElFRUUvQUNNDQo+ICAgICAgICBUcmFuc2Fj
dGlvbnMgb24gTmV0d29ya2luZyAoVE9OKSwgVG8gQXBwZWFyLg0KPiANCj4gICAgICAgIENoYW5n
aW5nIHRoZSBCR1AgY29uZmlndXJhdGlvbiBpcyBhIGNvbW1vbiAoc29tZXRpbWVzLA0KPiAgICAg
ICAgZGFpbHkpIGV2ZW50IGluIG1hbnkgbmV0d29ya3MuIFdoYXQgaXMgb2Z0ZW4gZm9yZ290dGVu
DQo+ICAgICAgICB0aG91Z2ggaXMgdGhhdCBhbnkgb2Ygc3VjaCBjaGFuZ2VzIGNhbiBjcmVhdGUg
cm91dGluZyBhbmQNCj4gICAgICAgIGZvcndhcmRpbmcgYW5vbWFsaWVzIC0gZXZlbiB3aGVuIGJl
c3QgY3VycmVudCBwcmFjdGljZXMgYXJlDQo+ICAgICAgICBhcHBsaWVkLiBJbiB0aGlzIHByZXNl
bnRhdGlvbiwgd2UgZGVzY3JpYmUgaG93IHRvIGRlcGxveSBhDQo+ICAgICAgICBuZXcgQkdQIGNv
bmZpZ3VyYXRpb24sIHdpdGggbm8gaW1wYWN0IG9uIGRhdGEtcGxhbmUgdHJhZmZpYywNCj4gICAg
ICAgIGJ5IGxldmVyYWdpbmcgdGhlIGFiaWxpdHkgb2YgQkdQIHJvdXRlcnMgdG8gcnVuIHR3bw0K
PiAgICAgICAgaW5kZXBlbmRlbnQgY29udHJvbC1wbGFuZXMuDQoNCkxhcnM=

From akatlas@gmail.com  Sun Jul 28 05:10:19 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F8121F972C for ; Sun, 28 Jul 2013 05:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level: 
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BphIKH1GXrOA for ; Sun, 28 Jul 2013 05:10:18 -0700 (PDT)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id CE51921F9011 for ; Sun, 28 Jul 2013 05:10:17 -0700 (PDT)
Received: by mail-ob0-f169.google.com with SMTP id wc20so1131585obb.28 for ; Sun, 28 Jul 2013 05:10:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TBOOiREguSwl0tLVgQ0GsHxLiiXFVDnavZgsNj1EVeg=; b=TgR5+zP5lrC5/vI+sy6rRujFuWGgjpTf4BysYN6oWuoOXetcCDOmNYqJWpUm/lDYFk qgWhuT2JMRnfkgg02HepnmzHypeCa+vLNQefvFphLSiSwrQ2Nlb5fjEQI1rTBjDz27oA HXlkbBqVQaSkjVmkqBklphutcCnFKMdxElLTKHqMWkNBtXfLUDI0rRJ2/zlYO53hacHN gMnFQe80bmP9OzhN+ZTDZfgEUgXVBaBcd753wDg+pnp8eM0bO9N7JOpLUz+rFdxBKQpX 9gt7ZrQ5xC9BPMFkqkvIshNwwO3EETrxKgXWtIczD8tMNvj/49dQ6hRTBsf83EcrzeCM f0HA==
MIME-Version: 1.0
X-Received: by 10.43.112.198 with SMTP id et6mr21248934icc.4.1375013417114; Sun, 28 Jul 2013 05:10:17 -0700 (PDT)
Received: by 10.64.8.19 with HTTP; Sun, 28 Jul 2013 05:10:17 -0700 (PDT)
Date: Sun, 28 Jul 2013 08:10:17 -0400
Message-ID: 
Subject: looking for comments on draft-ietf-rtgwg-mrt-frr-architecture
From: Alia Atlas 
To: "rtgwg@ietf.org" 
Content-Type: multipart/alternative; boundary=bcaec517204f49e21b04e2914289
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Jul 2013 12:10:19 -0000

--bcaec517204f49e21b04e2914289
Content-Type: text/plain; charset=ISO-8859-1

(WG-chair hat off)

I would be quite interested in any comments, questions, and suggestions for
draft-ietf-rtgwg-mrt-frr-architecture-03.  In this revision, I believe that
it has finalized all the open questions and is presenting a complete and
implementable architecture.  Two associated protocol drafts
(draft-atlas-ospf-mrt-00 and draft-atlas-mpls-ldp-mrt-00) describe the
protocol extensions that I see for the technology.  As indicated in the
architecture draft, I've gone for the idea of MRT profiles.

The associated algorithm draft, draft-enyedi-rtgwg-mrt-frr-algorithm-03,
has also been significantly revised.  It now describes how to handle proxy
nodes for multi-homed prefixes.  It also has the results of our analysis on
real network topologies.

A significant portion of this IETF's rtgwg meeting will be discussing MRT
in various aspects.  I'd really like to have some thoughtful discussion on
the list as well.

Thanks,
Alia

--bcaec517204f49e21b04e2914289
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


(WG-chair hat off)

I would be quite int=
erested in any comments, questions, and suggestions for draft-ietf-rtgwg-mr=
t-frr-architecture-03. =A0In this revision, I believe that it has finalized=
 all the open questions and is presenting a complete and implementable arch=
itecture. =A0Two associated protocol drafts (draft-atlas-ospf-mrt-00 and dr=
aft-atlas-mpls-ldp-mrt-00) describe the protocol extensions that I see for =
the technology. =A0As indicated in the architecture draft, I've gone fo=
r the idea of MRT profiles. =A0



The associated algorithm draft, draft-enyedi-rtgwg-mrt-=
frr-algorithm-03, has also been significantly revised. =A0It now describes =
how to handle proxy nodes for multi-homed prefixes. =A0It also has the resu=
lts of our analysis on real network topologies.



A significant portion of this IETF's rtgwg meeting =
will be discussing MRT in various aspects. =A0I'd really like to have s=
ome thoughtful discussion on the list as well.

Tha=
nks,


Alia


--bcaec517204f49e21b04e2914289--

From akatlas@gmail.com  Sun Jul 28 05:33:29 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6868F21F992E for ; Sun, 28 Jul 2013 05:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level: 
X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQd42uuO8iPM for ; Sun, 28 Jul 2013 05:33:29 -0700 (PDT)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4834321F941F for ; Sun, 28 Jul 2013 05:33:26 -0700 (PDT)
Received: by mail-ob0-f174.google.com with SMTP id wd6so4278024obb.33 for ; Sun, 28 Jul 2013 05:33:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=hGTm5LG/BvRWBckiDLgrCfSjl8IUZ5mZd4M8a8E1yI4=; b=HN1hRAO0vQU6qokdhXtAkoLCM9oFOTxHzPaKRy2WEafnprz4y62uOKTyDH+hRU/8Nl HvuR8VbbNABpmwFu6dp2AenzERt1eZd9De3XkeTjhlnSMs7kXxTFhiRK2OA7Ed/7v+Sq llfFndsAQz1v70fm82ygCmj0j2RXeAe2yBH2bw4rqdrkA5SwECwi9EvN9nNigBPnoobQ 1uCq/mY7c+zRzHdUMDidNxiVlOcfIrs30nL09teTNToEzL+EhRFba5vYrlMghy3tUsRP MGkC5HyxLbpw4bsGpAHfJ80K39YvoFGV5vaGfh8XoXusHQpijFngBCA+N1RHA4CzzALY /I8w==
MIME-Version: 1.0
X-Received: by 10.50.97.102 with SMTP id dz6mr601283igb.5.1375014805610; Sun, 28 Jul 2013 05:33:25 -0700 (PDT)
Received: by 10.64.8.19 with HTTP; Sun, 28 Jul 2013 05:33:25 -0700 (PDT)
Date: Sun, 28 Jul 2013 08:33:25 -0400
Message-ID: 
Subject: status of draft-ietf-rtgwg-cl-requirement
From: Alia Atlas 
To: "rtgwg@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b10ca110ca88904e29195fb
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Jul 2013 12:33:29 -0000

--047d7b10ca110ca88904e29195fb
Content-Type: text/plain; charset=ISO-8859-1

As you may recall, we successfully completed a WGLC on
draft-ietf-rtgwg-cl-requirement-10.  After that, there was concern about
the use of ITU terminology (composite-link and NPO) where the draft was not
actually using the exact meaning specified by the ITU.

Therefore, it was decided to return the draft to the WG for a quick
terminology update (and also to address some other review comments).

The changes in draft-ietf-rtgwg-cl-requirement-11 are largely terminology
and clarifications; FR#1 appears to have been broken up into two separate
requirements.

Since neither Curtis nor Lou Berger can make our Friday rtgwg slot, I'd
strongly encourage conversation here on the list to review and comment on
the updated draft.

I'd like to get it in for WG last call shortly after IETF - and see the
other related work move along as well.

Reviews are critical to complete this Advanced Multipath work in a
reasonable timeframe (well, starting from now - reasonable was passed a
while ago).

Thanks,
Alia

--047d7b10ca110ca88904e29195fb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


As you may recall, we successfully completed a WGLC on dra=
ft-ietf-rtgwg-cl-requirement-10. =A0After that, there was concern about the=
 use of ITU terminology (composite-link and NPO) where the draft was not ac=
tually using the exact meaning specified by the ITU.


Therefore, it was decided to return the draft to the WG for =
a quick terminology update (and also to address some other review comments)=
. =A0

The changes in draft-ietf-rtgwg-cl-requireme=
nt-11 are largely terminology and clarifications; FR#1 appears to have been=
 broken up into two separate requirements.



Since neither Curtis nor Lou Berger can make our Friday=
 rtgwg slot, I'd strongly encourage conversation here on the list to re=
view and comment on the updated draft.

I'd lik=
e to get it in for WG last call shortly after IETF - and see the other rela=
ted work move along as well. =A0



Reviews are critical to complete this Advanced Multipat=
h work in a reasonable timeframe (well, starting from now - reasonable was =
passed a while ago).

Thanks,
Alia




--047d7b10ca110ca88904e29195fb--

From akatlas@gmail.com  Sun Jul 28 06:01:52 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5960421F9D24 for ; Sun, 28 Jul 2013 06:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level: 
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F21gFZh3dpp for ; Sun, 28 Jul 2013 06:01:51 -0700 (PDT)
Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id CD70021F9C2D for ; Sun, 28 Jul 2013 06:01:51 -0700 (PDT)
Received: by mail-oa0-f50.google.com with SMTP id k7so11263379oag.9 for ; Sun, 28 Jul 2013 06:01:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SQK4l1bQp/BbLgxPck1EfukkIiCr1e78+E9WFUxsvwc=; b=r7RWMHdx4nycMQ4gPnP2mTzB9R5yNYEQbB33nq4StIV7naJc+h7ut7Ti2i8Wf3pvEc PbGBfT/O4bybPxinHhs6azjxdJ1pq7eE9F5t32NGuWNcWHJkyZoPQ/rGbjwI2wnBjDEE iYgjvvc/3M4NSYZ4MLL2VVumhVbtofGPGMJfcVnxivSYOqivaSrrGlg0NUyswsbd6JQt Un2oRdP9N1gzCeEZTJjmEH6CaQakiGzOlthvvIZM/yhY6C5H4LNrS1y/hYKal7c7oHDF v/55T56pKeF8OzS8wsEn+vOH9Gqlu3+HT269kCOPtGDZrAGilf1Rfj3WJfESPRAtdBpV +Q/g==
MIME-Version: 1.0
X-Received: by 10.43.65.144 with SMTP id xm16mr20981956icb.112.1375016511377;  Sun, 28 Jul 2013 06:01:51 -0700 (PDT)
Received: by 10.64.8.19 with HTTP; Sun, 28 Jul 2013 06:01:51 -0700 (PDT)
Date: Sun, 28 Jul 2013 09:01:51 -0400
Message-ID: 
Subject: scribe and jabber scribe needed
From: Alia Atlas 
To: "rtgwg@ietf.org" 
Content-Type: multipart/alternative; boundary=bcaec51b1b6fb896c304e291fa89
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Jul 2013 13:01:52 -0000

--bcaec51b1b6fb896c304e291fa89
Content-Type: text/plain; charset=ISO-8859-1

It's not too soon to volunteer to be a scribe or jabber scribe for RTGWG...

We could really use volunteers, particularly, for scribe.  I'd rather have
this dealt with before Friday.

Thanks,
Alia

--bcaec51b1b6fb896c304e291fa89
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


It's not too soon to volunteer to be a scribe or jabbe=
r scribe for RTGWG...

We could really use volunteers, pa=
rticularly, for scribe. =A0I'd rather have this dealt with before Frida=
y.



Thanks,
Alia


--bcaec51b1b6fb896c304e291fa89--

From agmalis@gmail.com  Sun Jul 28 22:24:19 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2006321F9E3F for ; Sun, 28 Jul 2013 22:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTUcsqqlrPxP for ; Sun, 28 Jul 2013 22:24:18 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8CE21F9E2A for ; Sun, 28 Jul 2013 22:24:18 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id z12so4401118wgg.34 for ; Sun, 28 Jul 2013 22:24:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9Kb/EesyqJbJsJ+tvnShNAeUWXY2UR56523Kkq2jcMA=; b=jDQjI4gxc2vYd9UGwbhxZMI1qxKDzzkqUwpQMQNDe6tmVyQ8yh6KjWqvawH/XOqykS F0cmCIHNPQmHzk0lzjxDwo9kDqquBSUU+sEJzFH2b374lCQRU8WapJ9Ko2fMPALhNJKE zoh85rS5MS9AxBY+q1LFhZWnUKkp//aQdIjrSQRYfgwg7V/Ls9RJwst0CCAXQcihj2u6 dfXvGPlmChSAAbV9NhLPhRW0Z8mmKVgtF9KZKEsBjwdyA7kkeNBhnA5zibZE3BmprU0b hMCgKsiuC4VHj6yAC0xditQSZ3sBA2s+liNzNmR7s8N2ph4QvEZUKYCTe8LfK9V2hOdm IHTA==
X-Received: by 10.180.106.226 with SMTP id gx2mr5908365wib.39.1375075457267; Sun, 28 Jul 2013 22:24:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.255.20 with HTTP; Sun, 28 Jul 2013 22:23:57 -0700 (PDT)
In-Reply-To: 
References: 
From: "Andrew G. Malis" 
Date: Mon, 29 Jul 2013 07:23:57 +0200
Message-ID: 
Subject: Re: status of draft-ietf-rtgwg-cl-requirement
To: Alia Atlas 
Content-Type: multipart/alternative; boundary=e89a8f3bad4b2b7c8a04e29fb4ff
Cc: "rtgwg@ietf.org" 
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Jul 2013 05:24:19 -0000

--e89a8f3bad4b2b7c8a04e29fb4ff
Content-Type: text/plain; charset=ISO-8859-1

Alia,

Thanks for the update!

As a co-author, and as it has already passed WGLC and this is just a
terminology update, I think it's ready for the second WGLC.

Thanks,
Andy


On Sun, Jul 28, 2013 at 2:33 PM, Alia Atlas  wrote:

> As you may recall, we successfully completed a WGLC on
> draft-ietf-rtgwg-cl-requirement-10.  After that, there was concern about
> the use of ITU terminology (composite-link and NPO) where the draft was not
> actually using the exact meaning specified by the ITU.
>
> Therefore, it was decided to return the draft to the WG for a quick
> terminology update (and also to address some other review comments).
>
> The changes in draft-ietf-rtgwg-cl-requirement-11 are largely terminology
> and clarifications; FR#1 appears to have been broken up into two separate
> requirements.
>
> Since neither Curtis nor Lou Berger can make our Friday rtgwg slot, I'd
> strongly encourage conversation here on the list to review and comment on
> the updated draft.
>
> I'd like to get it in for WG last call shortly after IETF - and see the
> other related work move along as well.
>
> Reviews are critical to complete this Advanced Multipath work in a
> reasonable timeframe (well, starting from now - reasonable was passed a
> while ago).
>
> Thanks,
> Alia
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>
>

--e89a8f3bad4b2b7c8a04e29fb4ff
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Alia,

Thanks for the update!
As a co-author, and as it has already passed WGLC and this is just a termi=
nology update, I think it's ready for the second WGLC.

Tha=
nks,


Andy


On Sun, Jul 28, 2013 at 2:33 PM, Alia Atlas <akatlas@gmail.com> wrote:



As you may recall, we succe=
ssfully completed a WGLC on draft-ietf-rtgwg-cl-requirement-10. =A0After th=
at, there was concern about the use of ITU terminology (composite-link and =
NPO) where the draft was not actually using the exact meaning specified by =
the ITU.




Therefore, it was decided to return the draft to the WG for =
a quick terminology update (and also to address some other review comments)=
. =A0

The changes in draft-ietf-rtgwg-cl-requireme=
nt-11 are largely terminology and clarifications; FR#1 appears to have been=
 broken up into two separate requirements.





Since neither Curtis nor Lou Berger can make our Friday=
 rtgwg slot, I'd strongly encourage conversation here on the list to re=
view and comment on the updated draft.

I'd lik=
e to get it in for WG last call shortly after IETF - and see the other rela=
ted work move along as well. =A0





Reviews are critical to complete this Advanced Multipat=
h work in a reasonable timeframe (well, starting from now - reasonable was =
passed a while ago).

Thanks,
Alia






_______________________________________________

rtgwg mailing list

rtgwg@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/rtgwg





--e89a8f3bad4b2b7c8a04e29fb4ff--

From cbowers@juniper.net  Tue Jul 30 05:09:17 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2D811E81EC for ; Tue, 30 Jul 2013 05:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.466
X-Spam-Level: 
X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTdwQ7ZhbXS4 for ; Tue, 30 Jul 2013 05:09:10 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA9311E81E8 for ; Tue, 30 Jul 2013 05:09:00 -0700 (PDT)
Received: from mail94-co1-R.bigfish.com (10.243.78.240) by CO1EHSOBE030.bigfish.com (10.243.66.95) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 12:08:59 +0000
Received: from mail94-co1 (localhost [127.0.0.1])	by mail94-co1-R.bigfish.com (Postfix) with ESMTP id E78E4CC01C5	for ; Tue, 30 Jul 2013 12:08:58 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail94-co1: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=cbowers@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; 
X-Forefront-Antispam-Report-Untrusted: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail94-co1 (localhost.localdomain [127.0.0.1]) by mail94-co1 (MessageSwitch) id 1375186137330170_2965; Tue, 30 Jul 2013 12:08:57 +0000 (UTC)
Received: from CO1EHSMHS015.bigfish.com (unknown [10.243.78.247])	by mail94-co1.bigfish.com (Postfix) with ESMTP id 42A0B20047	for ; Tue, 30 Jul 2013 12:08:57 +0000 (UTC)
Received: from P-EMF02-SAC.jnpr.net (66.129.224.54) by CO1EHSMHS015.bigfish.com (10.243.66.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 12:08:54 +0000
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 05:08:52 -0700
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Tue, 30 Jul 2013 05:08:52 -0700
Received: from CO9EHSOBE023.bigfish.com (207.46.163.24) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 05:21:50 -0700
Received: from mail90-co9-R.bigfish.com (10.236.132.235) by CO9EHSOBE023.bigfish.com (10.236.130.86) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 12:08:52 +0000
Received: from mail90-co9 (localhost [127.0.0.1])	by mail90-co9-R.bigfish.com (Postfix) with ESMTP id 07AD118029A	for ; Tue, 30 Jul 2013 12:08:52 +0000 (UTC)
Received: from mail90-co9 (localhost.localdomain [127.0.0.1]) by mail90-co9 (MessageSwitch) id 1375186129318155_17635; Tue, 30 Jul 2013 12:08:49 +0000 (UTC)
Received: from CO9EHSMHS015.bigfish.com (unknown [10.236.132.231])	by mail90-co9.bigfish.com (Postfix) with ESMTP id 3FBFC660077	for ; Tue, 30 Jul 2013 12:08:49 +0000 (UTC)
Received: from BN1PRD0512HT002.namprd05.prod.outlook.com (132.245.2.21) by CO9EHSMHS015.bigfish.com (10.236.130.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 12:08:48 +0000
Received: from BN1PRD0512MB667.namprd05.prod.outlook.com ([169.254.13.150]) by BN1PRD0512HT002.namprd05.prod.outlook.com ([10.255.193.35]) with mapi id 14.16.0341.000; Tue, 30 Jul 2013 12:08:47 +0000
From: Chris Bowers 
To: "rtgwg@ietf.org" 
Subject: issue with cost-based formulation of extended P-space in draft-ietf-rtgwg-remote-lfa-02
Thread-Topic: issue with cost-based formulation of extended P-space in draft-ietf-rtgwg-remote-lfa-02
Thread-Index: Ac6NHYnWHQ3+gAacTG+DkNbXOOyhtw==
Date: Tue, 30 Jul 2013 12:08:47 +0000
Message-ID: <145B98DA3B8D164BA479E1AC5316E6AF1472EDF8@BN1PRD0512MB667.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.224.36]
Content-Type: multipart/alternative; boundary="_000_145B98DA3B8D164BA479E1AC5316E6AF1472EDF8BN1PRD0512MB667_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jul 2013 12:09:18 -0000

--_000_145B98DA3B8D164BA479E1AC5316E6AF1472EDF8BN1PRD0512MB667_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

It appears that the cost-based formulation for determining the extended P-s=
pace in draft-ietf-rtgwg-remote-lfa-02 is incorrect.  In particular, sectio=
n 4.2.2 says:

"In cost terms a router is in extended P-space if the shortest path cost S-=
N->P is strictly less than the shortest path cost S-E->P."

Instead, the requirement should be that the shortest path cost N->P is stri=
ctly less than cost N-S-E->P.

I propose the following text for section 4.2.2.

"In terms of cost, a router Y is in the extended P-space of S with respect =
to the failure of link S-E, if either of the two following conditions is tr=
ue:
(1) D_opt(S,Y) < D_opt(S,E) + D_opt(E,Y)
OR
(2) S has a neighbor N satisfying the inequality:
D_opt(N,Y) < D_opt(N,S) + D_opt(S,E) + D_opt(E,Y)"

This text corrects the error noted above, and it puts both of the criteria =
for determining extended P-space in terms of cost in one place in the text.

Chris


--_000_145B98DA3B8D164BA479E1AC5316E6AF1472EDF8BN1PRD0512MB667_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











It appears that the cost-based formulation for determining the extende=
d P-space in draft-ietf-rtgwg-remote-lfa-02 is incorrect.  In particul=
ar, section 4.2.2 says:


 


“In cost terms a router is in extended P-space if the shortest p=
ath cost S-N->P is strictly less than the shortest path cost S-E->P.&=
#8221;


 


Instead, the requirement should be that the shortest path cost N->P=
 is strictly less than cost N-S-E->P.  


 


I propose the following text for section 4.2.2.


 


“In terms of cost, a router Y is in the extended P-space of S wi=
th respect to the failure of link S-E, if either of the two following condi=
tions is true:


(1) D_opt(S,Y) < D_opt(S,E) + D_opt(E,Y)


OR


(2) S has a neighbor N satisfying the inequality:


D_opt(N,Y) < D_opt(N,S) + D_opt(S,E) + D_opt(E,Y)”

 


This text corrects the error noted above, and it puts both of the crit=
eria for determining extended P-space in terms of cost in one place in the =
text. 


 


Chris


 





--_000_145B98DA3B8D164BA479E1AC5316E6AF1472EDF8BN1PRD0512MB667_--

From wwwrun@rfc-editor.org  Tue Jul 30 07:15:11 2013
Return-Path: 
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210D211E8208; Tue, 30 Jul 2013 07:15:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.281
X-Spam-Level: 
X-Spam-Status: No, score=-102.281 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT12A6S-yqeQ; Tue, 30 Jul 2013 07:15:10 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF4911E8212; Tue, 30 Jul 2013 07:14:44 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 478CE6210F; Tue, 30 Jul 2013 07:11:19 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Subject: RFC 6976 on Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach
From: rfc-editor@rfc-editor.org
Message-Id: <20130730141119.478CE6210F@rfc-editor.org>
Date: Tue, 30 Jul 2013 07:11:19 -0700 (PDT)
Cc: drafts-update-ref@iana.org, rtgwg@ietf.org, rfc-editor@rfc-editor.org
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jul 2013 14:15:11 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6976

        Title:      Framework for Loop-Free Convergence Using 
                    the Ordered Forwarding Information Base (oFIB) 
                    Approach 
        Author:     M. Shand, S. Bryant,
                    S. Previdi, C. Filsfils,
                    P. Francois, O. Bonaventure
        Status:     Informational
        Stream:     IETF
        Date:       July 2013
        Mailbox:    imc.shand@googlemail.com, 
                    stbryant@cisco.com, 
                    sprevidi@cisco.com,
                    cfilsfil@cisco.com, 
                    pierre.francois@imdea.org,  
                    Olivier.Bonaventure@uclouvain.be
        Pages:      28
        Characters: 61011
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-rtgwg-ordered-fib-12.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6976.txt

This document describes an illustrative framework of a mechanism for
use in conjunction with link-state routing protocols that prevents
the transient loops that would otherwise occur during topology
changes.  It does this by correctly sequencing the forwarding
information base (FIB) updates on the routers.

This mechanism can be used in the case of non-urgent (management
action) link or node shutdowns and restarts or link metric changes.
It can also be used in conjunction with a fast reroute mechanism that
converts a sudden link or node failure into a non-urgent topology
change.  This is possible where a complete repair path is provided
for all affected destinations.

After a non-urgent topology change, each router computes a rank that
defines the time at which it can safely update its FIB.  A method for
accelerating this loop-free convergence process by the use of
completion messages is also described.

The technology described in this document has been subject to
extensive simulation using pathological convergence behavior and real
network topologies and costs.  However, the mechanisms described in
this document are purely illustrative of the general approach and do
not constitute a protocol specification.  This document represents a
snapshot of the work of the Routing Area Working Group at the time of
publication and is published as a document of record.  Further work
is needed before implementation or deployment.

This document is a product of the Routing Area Working Group Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC