From jouni.nospam@gmail.com  Wed Jan  8 03:23:22 2014
Return-Path: <jouni.nospam@gmail.com>
X-Original-To: dir-coord@ietfa.amsl.com
Delivered-To: dir-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB891AE34A for <dir-coord@ietfa.amsl.com>; Wed,  8 Jan 2014 03:23:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9oU1J39l2UC for <dir-coord@ietfa.amsl.com>; Wed,  8 Jan 2014 03:23:17 -0800 (PST)
Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 10DF31AE354 for <dir-coord@ietf.org>; Wed,  8 Jan 2014 03:23:10 -0800 (PST)
Received: by mail-bk0-f43.google.com with SMTP id mz12so623229bkb.2 for <dir-coord@ietf.org>; Wed, 08 Jan 2014 03:23:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=/owqi54y+C1Hqtal4/lk5RoovZ9Y12tNLt7whOFHlas=; b=aatns2A2vyCxCROY4CrfUyA01F9jCylnVIubEjxAXNLDEDfK1Nnp0jCRosqh8R8j7z L6Zem+3sRGLz+ERAsMk5hiwfYF3RDNtleYWvV7UOkHNFXXaJ0frE5v8GOFYvdlH5Z3u0 jx14W4xaTcLbnQvO/HrBRb3P6nr6FHSHETgeOv37uBQWobpLKcgJJy79ks+P+cEa14g9 GMCwAESavEzBhBmYUdGTGNeS0OFfkeUCnVAxddfH44dYaktQOreDRvanyzkdIQiIwrHK HWKaPg1ew5SZIUIEwh4UPwaWhRdzFR9jRhCY6JqHrV3u3MyOa9DeeLFtRKcp5XfYJZs9 XJQQ==
X-Received: by 10.204.59.198 with SMTP id m6mr77095bkh.177.1389180181225; Wed, 08 Jan 2014 03:23:01 -0800 (PST)
Received: from ?IPv6:2001:6e8:480:60:a1de:2b70:4c9f:29ad? ([2001:6e8:480:60:a1de:2b70:4c9f:29ad]) by mx.google.com with ESMTPSA id mf4sm1580360bkb.7.2014.01.08.03.23.00 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jan 2014 03:23:00 -0800 (PST)
From: Jouni Korhonen <jouni.nospam@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 8 Jan 2014 13:23:00 +0200
Message-Id: <E54934B6-B9B1-4F03-A59B-C322475C0098@gmail.com>
To: "dir-coord@ietf.org" <dir-coord@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Cc: Mauricio Sanchez <mauricio.sanchez@hp.com>
Subject: [dir-coord] IP & transport directorate to review draft-ietf-radext-radius-fragmentation-02
X-BeenThere: dir-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is an e-mail alias for the organisers of IETF directorates." <dir-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dir-coord>, <mailto:dir-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dir-coord/>
List-Post: <mailto:dir-coord@ietf.org>
List-Help: <mailto:dir-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dir-coord>, <mailto:dir-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 11:23:22 -0000

Dear dir-coord,

RADEXT is having soon another WGLC on the draft "Support of fragmentation of
RADIUS packets" (draft-ietf-radext-radius-fragmentation-02), which defines a
fragmentation mechanism for UDP-based RADIUS authorization messages over 4K
of size. I'd like to get review comments from both IP and transport
directorate on this point solution for UDP-based RADIUS transport.

- Jouni (RADEXT co-chair)

From bclaise@cisco.com  Wed Jan  8 23:30:53 2014
Return-Path: <bclaise@cisco.com>
X-Original-To: dir-coord@ietfa.amsl.com
Delivered-To: dir-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707F91AE104 for <dir-coord@ietfa.amsl.com>; Wed,  8 Jan 2014 23:30:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.038
X-Spam-Level: 
X-Spam-Status: No, score=-15.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLDuh9liE8zi for <dir-coord@ietfa.amsl.com>; Wed,  8 Jan 2014 23:30:51 -0800 (PST)
Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 37B251AE100 for <dir-coord@ietf.org>; Wed,  8 Jan 2014 23:30:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8533; q=dns/txt; s=iport; t=1389252641; x=1390462241; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Oed5QOOz6fY1O81Gw2Y5OYfPNjZelEMGzd0Yeun6wdM=; b=BipW5GXs8IvJ5k2CWNPQijSn7dxMmEi+aGHThrrm0oeB9Rzy/H2g4y8t 0glzr2FTjPh6ycvC9KyF9UTAl3IQglKMaMeW7huoRubM7u5hWYy/F+DmX hBAq1oGCOuvdzXGYb7XMjAlmRr0q/xYzxK7UpVEe46Pm9lPENEsnCi2yW w=;
X-IronPort-AV: E=Sophos;i="4.95,629,1384300800"; d="scan'208,217";a="37851405"
Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 09 Jan 2014 07:30:39 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s097UasO022881; Thu, 9 Jan 2014 07:30:37 GMT
Message-ID: <52CE501C.6030709@cisco.com>
Date: Thu, 09 Jan 2014 08:30:36 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Susan Hares <shares@ndzh.com>, ops-ads@tools.ietf.org, "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>, Tina TSOU <Tina.Tsou.Zouting@huawei.com>, "dir-coord@ietf.org" <dir-coord@ietf.org>
References: <01ae01cf0cf7$29b3ac10$7d1b0430$@ndzh.com>
In-Reply-To: <01ae01cf0cf7$29b3ac10$7d1b0430$@ndzh.com>
Content-Type: multipart/alternative; boundary="------------030006070808030700010202"
Cc: "John G. Scudder" <jgs@juniper.net>, "'John G. Scudder'" <jgs@bgp.nu>
Subject: Re: [dir-coord] Early OPS-IDR Review requested of draft-ietf-idr-aigp
X-BeenThere: dir-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is an e-mail alias for the organisers of IETF directorates." <dir-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dir-coord>, <mailto:dir-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dir-coord/>
List-Post: <mailto:dir-coord@ietf.org>
List-Help: <mailto:dir-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dir-coord>, <mailto:dir-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 07:30:53 -0000

This is a multi-part message in MIME format.
--------------030006070808030700010202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gunter, Tina,

[copying "dir-coord@ietf.org" <dir-coord@ietf.org>, as this is the way 
to request early reviews. Not sure if this is important though]

Can you please allocate an OPS reviewer for this document, and flag this 
as early review.

Thanks and regards, Benoit
>
> Benoit and Joel:
>
> Would you do an earlier review on the draft:
>
> http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/
>
> This draft allows multiple-AS Networks to make better path selections 
> within networks.  Please find someone with experience in BGP 
> deployment in large networks to review.  It has 3 implementation and 
> has seen deployment.  I do not have the details on the "deployment", 
> but Eric Rosen might.
>
> I cannot review the draft as I am the document shepherd.
>
> During our WG LC, we did not do a IPR last call so it is in a 2 week 
> IPR last call.  I anticipate that the draft will pop out of IPR last 
> call and be sent to the IESG on 1/22 for a telechat scheduling.
>
> Sue Hares
>
> Technical Discussion
>
>    Routing protocols that have been designed to run within a single
>
>    administrative domain ("IGPs") generally do so by assigning a metric
>
>    to each link, and then choosing as the installed path between two
>
>    nodes the path for which the total distance (sum of the metric of
>
>    each link along the path) is minimized. BGP, designed to provide
>
>    routing over a large number of independent administrative domains
>
>    ("autonomous systems"), does not make its path selection decisions
>
>    through the use of a metric.  It is generally recognized that any
>
>    attempt to do so would incur significant scalability problems, as
>
>    well as inter-administration coordination problems.  However, there
>
>    are deployments in which a single administration runs several
>
>    contiguous BGP networks.  In such cases, it can be desirable, within
>
>    that single administrative domain, for BGP to select paths based on a
>
>    metric, just as an IGP would do.  The purpose of this document is to
>
>    provide a specification for doing so.
>


--------------030006070808030700010202
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Gunter, Tina,<br>
      <br>
      [copying <a class="moz-txt-link-rfc2396E" href="mailto:dir-coord@ietf.org">"dir-coord@ietf.org"</a> <a class="moz-txt-link-rfc2396E" href="mailto:dir-coord@ietf.org">&lt;dir-coord@ietf.org&gt;</a>, as this
      is the way to request early reviews. Not sure if this is important
      though]<br>
      <br>
      Can you please allocate an OPS reviewer for this document, and
      flag this as early review.<br>
      <br>
      Thanks and regards, Benoit <br>
    </div>
    <blockquote cite="mid:01ae01cf0cf7$29b3ac10$7d1b0430$@ndzh.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 14 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">Benoit and Joel: <o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">Would you do an earlier review on the
          draft: <o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"><a moz-do-not-send="true"
            href="http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/">http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/</a><o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">This draft allows multiple-AS Networks to
          make better path selections within networks. &nbsp;Please find
          someone with experience in BGP deployment in large networks to
          review. &nbsp;It has 3 implementation and has seen deployment.&nbsp; I
          do not have the details on the &#8220;deployment&#8221;, but Eric Rosen
          might. <o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">I cannot review the draft as I am the
          document shepherd. <o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">During our WG LC, we did not do a IPR last
          call so it is in a 2 week IPR last call.&nbsp; I anticipate that
          the draft will pop out of IPR last call and be sent to the
          IESG on 1/22 for a telechat scheduling. <o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">Sue Hares<o:p></o:p></p>
        <p class="MsoNormal"> <o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">Technical Discussion<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp; Routing protocols that have been
          designed to run within a single<o:p></o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp; administrative domain ("IGPs") generally
          do so by assigning a metric<o:p></o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp; to each link, and then choosing as the
          installed path between two<o:p></o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp; nodes the path for which the total
          distance (sum of the metric of<o:p></o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp; each link along the path) is minimized.&nbsp;
          BGP, designed to provide<o:p></o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp; routing over a large number of
          independent administrative domains<o:p></o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp; ("autonomous systems"), does not make
          its path selection decisions<o:p></o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp; through the use of a metric.&nbsp; It is
          generally recognized that any<o:p></o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp; attempt to do so would incur significant
          scalability problems, as<o:p></o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp; well as inter-administration
          coordination problems.&nbsp; However, there<o:p></o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp; are deployments in which a single
          administration runs several<o:p></o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp; contiguous BGP networks.&nbsp; In such cases,
          it can be desirable, within<o:p></o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp; that single administrative domain, for
          BGP to select paths based on a<o:p></o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp; metric, just as an IGP would do.&nbsp; The
          purpose of this document is to<o:p></o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp; provide a specification for doing so.<o:p></o:p></p>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------030006070808030700010202--