From acee.lindem@ericsson.com Thu Feb 7 05:57:53 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E3F21F84BB for ; Thu, 7 Feb 2013 05:57:53 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2Xj2ZkZc2lB for ; Thu, 7 Feb 2013 05:57:52 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD4E21F841C for ; Thu, 7 Feb 2013 05:57:52 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-77-5113b2dfcdc6 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 96.81.03705.FD2B3115; Thu, 7 Feb 2013 14:57:51 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 08:57:50 -0500 From: Acee Lindem To: Alexander Vainshtein Thread-Topic: Suppression of frequent OSPF traps Thread-Index: Ac4FMBLXaJkjhGSRQQG4dKYuhwxwxgANPMeA Date: Thu, 7 Feb 2013 13:57:50 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470BDDF9@eusaamb101.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470BDDF9eusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLonXPf+JuFAg65nuhaHD85is5i69QOz Rcu9e+wWM2f8YbRYvfY7mwOrx5TfG1k9Nv07zuixZMlPpgDmKC6blNSczLLUIn27BK6MnW83 sBXsmMVY8frkepYGxnutjF2MnBwSAiYSq9v62SBsMYkL99YD2VwcQgJHGCU2zTvADuEsY5T4 N/k1E0gVm4COxPNH/5hBbBEBa4m5N46DFTELzGKUePv8NthYYQEDiTcX7kAVGUrMu/4VqIgD yDaSeN6nAxJmEVCR+H5xBthMXgFvia0/e8DKhQQCJK6eOwwW5xQIlNj7dg/YdYxA130/tQYs ziwgLnHryXwmiKsFJJbsOc8MYYtKvHz8jxXCVpb4PucRC0R9vsSZrQuZIXYJSpyc+YRlAqPo LCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj6F6rSUObf/DhKxmASPHKkaO0uLUstx0 I8NNjMDYPCbB5riDccEny0OM0hwsSuK8oa4XAoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw Cpbt25ayhtc47XuP67xHnFmSsYYSO05JR1rP+xmxcHpMSNzsTWvbSljva/Ad+jcjMWUdb4GS 7owbR3Okz31y/fzX+XXDqb+3tQ8HOcyr056/8FpzovPx5a+Ovd2isq7qzF193UztzkPLKr9Z b/8YHHTPPuLZtGXMoUf3MFivmeVbFayneO++vhJLcUaioRZzUXEiADItJfObAgAA Cc: "ospf@ietf.org" , Sidd Aanand , Srinivas Goli Subject: Re: [OSPF] Suppression of frequent OSPF traps X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 13:57:53 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470BDDF9eusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha, See inline. On Feb 7, 2013, at 7:38 AM, Alexander Vainshtein wrote: Dear all, My colleagues and I are interested in interpretation of the following text = from RFC 4750 - OSPF Version 2 Management Information Base: ospfIfConfigError NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfIfIpAddress, ospfAddressLessIf, ospfPacketSrc, -- The source IP address ospfConfigErrorType, -- Type of error ospfPacketType } STATUS current DESCRIPTION "An ospfIfConfigError trap signifies that a packet has been received on a non-virtual interface from a router whose configuration parameters conflict with this router's configuration parameters. Note that the event optionMismatch should cause a trap only if it prevents an adjacency from forming." ::=3D { ospfTraps 4 } The highlighted text could be interpreted that the trap is sent every time = an offending packet has been received. This could easily result in an incessant flow of traps (e.g., if you receiv= e offending Hello packets from a misconfigured router on the LAN segment). Hence two questions: 1. Is the interpretation mentioned above valid? Yes. If you don't have rate limiting for your traps, your SNMP implementati= on is broken. Furthermore, an implementation should be allow traps to be se= lectively enabled and disabled. For example, here is the command from my implementation: [local]se-acee(config-ctx)#router ospf 1 [local]se-acee(config-ospf)#snmp traps ? all Enable sending all supported OSPF traps ifauthfailure Enable sending ospfIfAuthFailure traps ifconfigerror Enable sending ospfIfConfigError traps ifrxbadpacket Enable sending ospfIfRxBadPacket traps ifstatechange Enable sending ospfIfStateChange traps maxagelsa Enable sending ospfMaxAgeLsa traps nbrstatechange Enable sending ospfNbrStateChange traps originatelsa Enable sending ospfOriginateLsa traps txretransmit Enable sending ospftxretransmit traps virtifauthfailure Enable sending ospfVirtIfAuthFailure traps virtifconfigerror Enable sending ospfVirtIfConfigError traps virtifrxbadpacket Enable sending ospfVirtIfRxBadPacket traps virtifstatechange Enable sending ospfIfVirtIfStateChange traps virtiftxretransmit Enable sending ospfVirtIfTxRetransmit traps virtnbrstatechange Enable sending ospfVirtNbrStateChange traps Hope this helps, Acee P.S. If you really want to see some traps, enable ospfOriginateLas and ospf= MaxAgeLsa on a core router. 2. If not, what is the valid interpretation and associated expected b= ehavior? Regards, and lots of thanks in advance, Sasha This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_94A203EA12AECE4BA92D42DBFFE0AE470BDDF9eusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <1F8433C23FF5034A9D2EB1CA395D2D13@ericsson.com> Content-Transfer-Encoding: quoted-printable Sasha, 
See inline. 
On Feb 7, 2013, at 7:38 AM, Alexander Vainshtein wrote:

Dear all,
My colleagues and I are interested in interpretation of the following text = from RFC 4750 - OSPF Version 2 Management Information Base:
 
&= nbsp;    ospfIfConfigError NOTIFICATION-TYPE
&= nbsp;         OBJECTS { ospfRouterI= d, -- The originator of the trap
&= nbsp;            osp= fIfIpAddress,
&= nbsp;            osp= fAddressLessIf,
&= nbsp;            osp= fPacketSrc,  -- The source IP address
&= nbsp;            osp= fConfigErrorType, -- Type of error
&= nbsp;            osp= fPacketType
&= nbsp;            }
&= nbsp;         STATUS  &nb= sp;    current
&= nbsp;         DESCRIPTION
&= nbsp;            &qu= ot;An ospfIfConfigError trap signifies that a
  &= nbsp;          packet has been received on a non-virtual
  &= nbsp;          interface from a router whose configuration
  &= nbsp;          parameters conflict with this router's
  &= nbsp;          configuration parameters.  Note that the event
&= nbsp;            opt= ionMismatch should cause a trap only if it
&= nbsp;            pre= vents an adjacency from forming."
&= nbsp;         ::=3D { ospfTraps 4 }=
<= o:p> 
The highlighted text could be interpreted that the trap is sent every time an offending packet ha= s been received.
This could easily result in an incessant flow of traps (e.g., if you receiv= e offending Hello packets from a misconfigured router on the LAN segment).<= o:p>
 
Hence two  questions:
1.       Is the interpreta= tion mentioned above valid?

Yes. If you don't have rate limiting for your traps, your SNMP impleme= ntation is broken. Furthermore, an implementation should be allow traps to = be selectively enabled and disabled. 
For example, here is the command from my implementation:

[local]se-acee(config-ctx)#router ospf 1
[local]se-acee(config-ospf)#snmp traps ?
  all                 Ena= ble sending all supported OSPF traps
  ifauthfailure       Enable sending ospfIfAuthFai= lure traps
  ifconfigerror       Enable sending ospfIfConfigE= rror traps
  ifrxbadpacket       Enable sending ospfIfRxBadPa= cket traps
  ifstatechange       Enable sending ospfIfStateCh= ange traps
  maxagelsa           Enable sending osp= fMaxAgeLsa traps
  nbrstatechange      Enable sending ospfNbrStateC= hange traps
  originatelsa        Enable sending ospfOrig= inateLsa traps
  txretransmit        Enable sending ospftxre= transmit traps
  virtifauthfailure   Enable sending ospfVirtIfAuthFailure t= raps
  virtifconfigerror   Enable sending ospfVirtIfConfigError t= raps
  virtifrxbadpacket   Enable sending ospfVirtIfRxBadPacket t= raps
  virtifstatechange   Enable sending ospfIfVirtIfStateChange= traps
  virtiftxretransmit  Enable sending ospfVirtIfTxRetransmit = traps
  virtnbrstatechange  Enable sending ospfVirtNbrStateChange = traps

Hope this helps,
Acee
P.S. If you really want to see some traps, enable ospfOriginateLas and= ospfMaxAgeLsa on a core router. 



2.       If not, what is t= he valid interpretation and associated expected behavior?
 
Regards, and lots of thanks in advance,
     Sasha
 

This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. = If you have received this transmission in error, please inform us by e-mail= , phone or fax, and then delete the original and all copies thereof.


--_000_94A203EA12AECE4BA92D42DBFFE0AE470BDDF9eusaamb101ericsso_-- From acee.lindem@ericsson.com Mon Feb 11 15:44:57 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732B721F8849; Mon, 11 Feb 2013 15:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_44=1, MIME_BAD_LINEBREAK=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOtNXLpCYkXP; Mon, 11 Feb 2013 15:44:56 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6D75321F8812; Mon, 11 Feb 2013 15:44:56 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-93-51198276a763 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E1.25.03705.67289115; Tue, 12 Feb 2013 00:44:55 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.004; Mon, 11 Feb 2013 18:44:54 -0500 From: Acee Lindem To: Stewart Bryant , Adrian Farrel Thread-Topic: Request for Publication for Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-07 Thread-Index: AQHOCLHKJnw5oS+YW0OHIrY9NCs3Eg== Date: Mon, 11 Feb 2013 23:44:53 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470C202B@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: multipart/mixed; boundary="_004_94A203EA12AECE4BA92D42DBFFE0AE470C202Beusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCIsWRmVeSWpSXmKPExsUyuXSPn255k2Sgwfc2HosfPTeYLf7+3Mpo cerdLWaLC5tXMFnsX9nNaNFy7x67xbmncxgd2D2m/N7I6tFy5C2rx5IlP5k8Vmxeyejx41hY AGsUl01Kak5mWWqRvl0CV8bk/bOZCuaFVmy+f5+1gbEhqIuRk0NCwETi6rxn7BC2mMSFe+vZ uhi5OIQEjjBKnPsykRkkISSwnFHiz09XEJtNQEfi+aN/YHERAR+JldPfgjUzC7xmlHi33BHE FhaolbjZOZkZZJCIQBPQoOXnmCAa9CS+XV/N2MXIwcEioCqx5JQaSJhXwFviTOsksBJGoCO+ n1rDBDFTXOLWk/lMEMeJSDy8eJoNwhaVePn4HyuILQo0su3YGagHlCWWPNnPAtGbKXHhegsz xHxBiZMzn7BMYBSZhWTsLCRls5CUQcTzJeZcmAhVoyOxYPcnNghbW2LZwtfMMPaZA4+haqwl 1j48yYSpJlDi+MVHrLOAPmYWcJb4ulR3FjBUmAXOMkpMub+UGab34+PFUL2KElO6H7IvYORb xchRWpxalptuZLiJEZgyjkmwOe5gXPDJ8hCjNAeLkjhvqOuFACGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2M3c56To/MVvIraUwJVRacn8UafLjbdOaEFa5CIe0P12506L9qoHo+0eeu+Avz I2tjU/ubb71J5yovFn7ksXDlchdx3lqJ8w28zaZNJnPuLJnTEzehTja41X2KW/3PWxr+s5JO er43nvr4rayDJN/3R5GnrEyZ0nozVds85qgY3n3zd7Z0+0ElluKMREMt5qLiRABAMZCJ5wIA AA== Cc: "ospf@ietf.org" , Mohamed Boucadair , "ietf-secretary@ietf.org" Subject: [OSPF] Request for Publication for Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-07 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 23:44:57 -0000 --_004_94A203EA12AECE4BA92D42DBFFE0AE470C202Beusaamb101ericsso_ Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470C202Beusaamb101ericsso_" --_000_94A203EA12AECE4BA92D42DBFFE0AE470C202Beusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OSPF WG is requesting publication of Routing for IPv4-embedded IPv6 Pac= kets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-07. The document shepherd= write-up is attached. Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE470C202Beusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <36ECB917FCD8FD429E7343867D965FCC@ericsson.com> Content-Transfer-Encoding: quoted-printable
The OSPF WG is requesting publication of Routing for IPv4-embedde= d IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-07. The do= cument shepherd write-up is attached. 
Thanks,
Acee
--_000_94A203EA12AECE4BA92D42DBFFE0AE470C202Beusaamb101ericsso_-- --_004_94A203EA12AECE4BA92D42DBFFE0AE470C202Beusaamb101ericsso_ Content-Type: text/plain; name="ospf-wg-ipv4-embedded-ipv6-routing-writeup.txt" Content-Description: ospf-wg-ipv4-embedded-ipv6-routing-writeup.txt Content-Disposition: attachment; filename="ospf-wg-ipv4-embedded-ipv6-routing-writeup.txt"; size=6533; creation-date="Mon, 11 Feb 2013 23:44:53 GMT"; modification-date="Mon, 11 Feb 2013 23:44:53 GMT" Content-ID: Content-Transfer-Encoding: base64 KDEpIFdoYXQgdHlwZSBvZiBSRkMgaXMgYmVpbmcgcmVxdWVzdGVkIChCQ1AsIFByb3Bvc2VkIFN0 YW5kYXJkLA1JbnRlcm5ldCBTdGFuZGFyZCwgSW5mb3JtYXRpb25hbCwgRXhwZXJpbWVudGFsLCBv ciBIaXN0b3JpYyk/ICBXaHkNaXMgdGhpcyB0aGUgcHJvcGVyIHR5cGUgb2YgUkZDPyAgSXMgdGhp cyB0eXBlIG9mIFJGQyBpbmRpY2F0ZWQgaW4gDXRoZSB0aXRsZSBwYWdlIGhlYWRlcj8NDSAgICAg SW5mb3JtYXRpb25hbCANDSgyKSBUaGUgSUVTRyBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgaW5jbHVk ZXMgYSBEb2N1bWVudCBBbm5vdW5jZW1lbnQNV3JpdGUtVXAuIFBsZWFzZSBwcm92aWRlIHN1Y2gg YSBEb2N1bWVudCBBbm5vdW5jZW1lbnQgV3JpdGUtVXAuIFJlY2VudA1leGFtcGxlcyBjYW4gYmUg Zm91bmQgaW4gdGhlICJBY3Rpb24iIGFubm91bmNlbWVudHMgZm9yIGFwcHJvdmVkDWRvY3VtZW50 cy4gVGhlIGFwcHJvdmFsIGFubm91bmNlbWVudCBjb250YWlucyB0aGUgZm9sbG93aW5nIHNlY3Rp b25zOg0NICAgICBUZWNobmljYWwgU3VtbWFyeSANDSAgICAgVGhpcyBkcmFmdCBkZXNjcmliZXMg aG93IHRvIHVzZSBtZWNoYW5pc21zIE9TUEYgbXVsdGktaW5zdGFuY2VzIGFzDSAgICAgZGVzY3Jp YmVkIGluIFJGQyA1ODM4IHRvIHN1cHBvcnQgUkZDIDYwNTIgSVB2NC9JUHY2IHRyYW5zbGF0aW9u DSAgICAgbWVjaGFuaXNtcy4NDSAgICAgV29ya2luZyBHcm91cCBTdW1tYXJ5IA0NICAgICBBbHRo b3VnaCBwcmVzZW50ZWQgYXQgbXVsdGlwbGUgSUVURnMsIHRoZSBkcmFmdCBkaWQgbm90IGdlbmVy YXRlDSAgICAgYSBsb3Qgb2YgY29tbWVudHMuIEF0IG9uZSBwb2ludCwgaXQgaW5jbHVkZWQgY2hh bmdlcyB0byB0aGUgT1NQRnYzDSAgICAgcHJvdG9jb2wgZHVlIHRvIHRoZSBzdWdnZXN0aW9uIHRo YXQgdGhlIElQdjQgZG9tYWlucyBjb3VsZCBiZSANICAgICBhYnN0cmFjdGVkIGFzIE9TUEZ2MyBh cmVhcy4gVGhpcyB3YXMgZGlzY2FyZGVkIGR1ZSB0byB0aGUNICAgICBjb21wbGV4aXR5IGFuZCB0 aGUgZmFjdCB0aGF0IGl0IHdhcyBhYm92ZSBhbmQgYmV5b25kIHRoZSBSRkMgNTgzOCANICAgICBt ZWNoYW5pc21zLiANDSAgICAgRG9jdW1lbnQgUXVhbGl0eSANDSAgICAgVGhlIGRvY3VtZW50IGhh cyBnb25lIHRocm91Z2ggc2V2ZXJhbCBXRyByZXZpZXcgY3ljbGVzIGFuZCANICAgICByZXZpc2lv bnMuIENvbW1lbnRzIHdlcmUgcmVjZWl2ZWQgZnJvbSBzb21lIFdHIG1lbWJlcnMgYXMgd2VsbA0g ICAgIGFzIHRoZSBjaGFpciBvZiB0aGUgQkVIQVZFIFdHLiBUbyB0aGUgYmVzdCBvZiBteSBrbm93 bGVkZ2UsIHRoZXJlDSAgICAgYXJlIG5vIGltcGxlbWVudGF0aW9ucy4gDQ0gICAgIFdlIGFsc28g V0cgbGFzdCBjYWxsZWQgdGhlIGRyYWZ0IGluIHRoZSBCRUhBVkUgV0cgYW5kIHJlY2VpdmVkDSAg ICAgc29tZSBjb21tZW50cyBmcm9tIEJyaWFuIENhcnBlbnRlciByZWxhdGl2ZSB0byBwb3NpdGlv bmluZyB0aGUgZHJhZnQNICAgICB3aXRoIG90aGVyIElQdjQ8LT5JUHY2IHRyYW5zaXRpb24gbWVj aGFuaXNtcy4gVGhlIGxhdGVzdCB2ZXJzaW9uIG9mDSAgICAgdGhlIGRyYWZ0IGNsYXJpZmllcyB0 aGlzLiANDSAgICAgUGVyc29ubmVsICAgICAgDQ0gICAgIEFjZWUgTGluZGVtIGlzIHRoZSBkb2N1 bWVudCBzaGVwaGVyZCBhbmQgU3Rld2FydCBCcnlhbnQgaXMgdGhlIA0gICAgIHJlc3BvbnNpYmxl IEFELiANDSgzKSBCcmllZmx5IGRlc2NyaWJlIHRoZSByZXZpZXcgb2YgdGhpcyBkb2N1bWVudCB0 aGF0IHdhcyBwZXJmb3JtZWQgYnkNdGhlIERvY3VtZW50IFNoZXBoZXJkLiAgSWYgdGhpcyB2ZXJz aW9uIG9mIHRoZSBkb2N1bWVudCBpcyBub3QgcmVhZHkNZm9yIHB1YmxpY2F0aW9uLCBwbGVhc2Ug ZXhwbGFpbiB3aHkgdGhlIGRvY3VtZW50IGlzIGJlaW5nIGZvcndhcmRlZCB0bw10aGUgSUVTRy4N DSAgICBUaGUgZG9jdW1lbnQgd2FzIHByZXNlbnRlZCBpbiBCZWppbmcgYW5kIHdlbnQgdGhyb3Vn aCBzZXZlcmFsIFdHDSAgICByZXZpZXdzLiANDQ0oNCkgRG9lcyB0aGUgZG9jdW1lbnQgU2hlcGhl cmQgaGF2ZSBhbnkgY29uY2VybnMgYWJvdXQgdGhlIGRlcHRoIG9yDWJyZWFkdGggb2YgdGhlIHJl dmlld3MgdGhhdCBoYXZlIGJlZW4gcGVyZm9ybWVkPyANDSAgICBOby4gDQ0NKDUpIERvIHBvcnRp b25zIG9mIHRoZSBkb2N1bWVudCBuZWVkIHJldmlldyBmcm9tIGEgcGFydGljdWxhciBvciBmcm9t DWJyb2FkZXIgcGVyc3BlY3RpdmUsIGUuZy4sIHNlY3VyaXR5LCBvcGVyYXRpb25hbCBjb21wbGV4 aXR5LCBBQUEsIEROUywNREhDUCwgWE1MLCBvciBpbnRlcm5hdGlvbmFsaXphdGlvbj8gSWYgc28s IGRlc2NyaWJlIHRoZSByZXZpZXcgdGhhdA10b29rIHBsYWNlLg0NICAgIE5vLg0NKDYpIERlc2Ny aWJlIGFueSBzcGVjaWZpYyBjb25jZXJucyBvciBpc3N1ZXMgdGhhdCB0aGUgRG9jdW1lbnQgU2hl cGhlcmQNaGFzIHdpdGggdGhpcyBkb2N1bWVudCB0aGF0IHRoZSBSZXNwb25zaWJsZSBBcmVhIERp cmVjdG9yIGFuZC9vciB0aGUNSUVTRyBzaG91bGQgYmUgYXdhcmUgb2Y/IEZvciBleGFtcGxlLCBw ZXJoYXBzIGhlIG9yIHNoZSBpcyB1bmNvbWZvcnRhYmxlDXdpdGggY2VydGFpbiBwYXJ0cyBvZiB0 aGUgZG9jdW1lbnQsIG9yIGhhcyBjb25jZXJucyB3aGV0aGVyIHRoZXJlIHJlYWxseQ1pcyBhIG5l ZWQgZm9yIGl0LiBJbiBhbnkgZXZlbnQsIGlmIHRoZSBpbnRlcmVzdGVkIGNvbW11bml0eSBoYXMN ZGlzY3Vzc2VkIHRob3NlIGlzc3VlcyBhbmQgaGFzIGluZGljYXRlZCB0aGF0IGl0IHN0aWxsIHdp c2hlcyB0byBhZHZhbmNlDXRoZSBkb2N1bWVudCwgZGV0YWlsIHRob3NlIGNvbmNlcm5zIGhlcmUu DQ0gICBOb25lLiANDSg3KSBIYXMgZWFjaCBhdXRob3IgY29uZmlybWVkIHRoYXQgYW55IGFuZCBh bGwgYXBwcm9wcmlhdGUgSVBSDWRpc2Nsb3N1cmVzIHJlcXVpcmVkIGZvciBmdWxsIGNvbmZvcm1h bmNlIHdpdGggdGhlIHByb3Zpc2lvbnMgb2YgQkNQIDc4DWFuZCBCQ1AgNzkgaGF2ZSBhbHJlYWR5 IGJlZW4gZmlsZWQuIElmIG5vdCwgZXhwbGFpbiB3aHkuDQ0gICBZZXMuICAgDQ0oOCkgSGFzIGFu IElQUiBkaXNjbG9zdXJlIGJlZW4gZmlsZWQgdGhhdCByZWZlcmVuY2VzIHRoaXMgZG9jdW1lbnQ/ DUlmIHNvLCBzdW1tYXJpemUgYW55IGRpc2N1c3Npb24gYW5kIGNvbmNsdXNpb24gcmVnYXJkaW5n IHRoZSBJUFINZGlzY2xvc3VyZXMuICAgIA0NICAgIE5vLiANDSg5KSBIb3cgc29saWQgaXMgdGhl IGNvbnNlbnN1cyBvZiB0aGUgaW50ZXJlc3RlZCBjb21tdW5pdHkgYmVoaW5kIHRoaXMNZG9jdW1l bnQ/IERvZXMgaXQgcmVwcmVzZW50IHRoZSBzdHJvbmcgY29uY3VycmVuY2Ugb2YgYSBmZXcgaW5k aXZpZHVhbHMsDXdpdGggb3RoZXJzIGJlaW5nIHNpbGVudCwgb3IgZG9lcyB0aGUgaW50ZXJlc3Rl ZCBjb21tdW5pdHkgYXMgYSB3aG9sZQ11bmRlcnN0YW5kIGFuZCBhZ3JlZSB3aXRoIGl0PyANDSAg IFRoZXJlIGlzIG5vIG9wcG9zaXRpb24gdG8gdGhlIGRyYWZ0LiBUaG9zZSB3aG8gdW5kZXJzdGFu ZA0gICB0aGUgSVB2NC9JUHY2IHRyYW5zaXRpb24gdXNlIGNhc2VzLCBmZWVsIHRoaXMgaXMgYSB2 aWFibGUNICAgYXBwbGljYXRpb24gb2YgdGhlIE9TUEZ2MyBtdWx0aS1pbnN0YW5jZSBtZWNoYW5p c21zLiANDSgxMCkgSGFzIGFueW9uZSB0aHJlYXRlbmVkIGFuIGFwcGVhbCBvciBvdGhlcndpc2Ug aW5kaWNhdGVkIGV4dHJlbWUgDWRpc2NvbnRlbnQ/IElmIHNvLCBwbGVhc2Ugc3VtbWFyaXNlIHRo ZSBhcmVhcyBvZiBjb25mbGljdCBpbiBzZXBhcmF0ZQ1lbWFpbCBtZXNzYWdlcyB0byB0aGUgUmVz cG9uc2libGUgQXJlYSBEaXJlY3Rvci4gKEl0IHNob3VsZCBiZSBpbiBhDXNlcGFyYXRlIGVtYWls IGJlY2F1c2UgdGhpcyBxdWVzdGlvbm5haXJlIGlzIHB1YmxpY2x5IGF2YWlsYWJsZS4pIA0gDSAg IE5vLiANDSgxMSkgSWRlbnRpZnkgYW55IElEIG5pdHMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhh cyBmb3VuZCBpbiB0aGlzDWRvY3VtZW50LiAoU2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvdG9vbHMv aWRuaXRzLyBhbmQgdGhlIEludGVybmV0LURyYWZ0cw1DaGVja2xpc3QpLiBCb2lsZXJwbGF0ZSBj aGVja3MgYXJlIG5vdCBlbm91Z2g7IHRoaXMgY2hlY2sgbmVlZHMgdG8gYmUNdGhvcm91Z2guDQ0g ICBBbGwgYXBwbGljYWJsZSBpZG5pdHMgZXJyb3JzIGFuZCB3YXJuaW5ncyBoYXZlIGJlZW4gcmVz b2x2ZWQuDQ0NKDEyKSBEZXNjcmliZSBob3cgdGhlIGRvY3VtZW50IG1lZXRzIGFueSByZXF1aXJl ZCBmb3JtYWwgcmV2aWV3DWNyaXRlcmlhLCBzdWNoIGFzIHRoZSBNSUIgRG9jdG9yLCBtZWRpYSB0 eXBlLCBhbmQgVVJJIHR5cGUgcmV2aWV3cy4NDSAgIE5vdCBhcHBsaWNhYmxlLiANDSgxMykgSGF2 ZSBhbGwgcmVmZXJlbmNlcyB3aXRoaW4gdGhpcyBkb2N1bWVudCBiZWVuIGlkZW50aWZpZWQgYXMN ZWl0aGVyIG5vcm1hdGl2ZSBvciBpbmZvcm1hdGl2ZT8NDSAgIFllcy4NDSgxNCkgQXJlIHRoZXJl IG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIGRvY3VtZW50cyB0aGF0IGFyZSBub3QgcmVhZHkgZm9y DWFkdmFuY2VtZW50IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5jbGVhciBzdGF0ZT8gSWYgc3Vj aCBub3JtYXRpdmUNcmVmZXJlbmNlcyBleGlzdCwgd2hhdCBpcyB0aGUgcGxhbiBmb3IgdGhlaXIg Y29tcGxldGlvbj8NDSAgICBOby4gDQ0oMTUpIEFyZSB0aGVyZSBkb3dud2FyZCBub3JtYXRpdmUg cmVmZXJlbmNlcyByZWZlcmVuY2VzIChzZWUgUkZDIDM5NjcpPw1JZiBzbywgbGlzdCB0aGVzZSBk b3dud2FyZCByZWZlcmVuY2VzIHRvIHN1cHBvcnQgdGhlIEFyZWEgRGlyZWN0b3IgaW4NdGhlIExh c3QgQ2FsbCBwcm9jZWR1cmUuDQ0gICAgTm8uDQ0oMTYpIFdpbGwgcHVibGljYXRpb24gb2YgdGhp cyBkb2N1bWVudCBjaGFuZ2UgdGhlIHN0YXR1cyBvZiBhbnkgZXhpc3RpbmcNUkZDcz8gQXJlIHRo b3NlIFJGQ3MgbGlzdGVkIG9uIHRoZSB0aXRsZSBwYWdlIGhlYWRlciwgbGlzdGVkIGluIHRoZQ1h YnN0cmFjdCwgYW5kIGRpc2N1c3NlZCBpbiB0aGUgaW50cm9kdWN0aW9uPyBJZiB0aGUgUkZDcyBh cmUgbm90IGxpc3RlZA1pbiB0aGUgQWJzdHJhY3QgYW5kIEludHJvZHVjdGlvbiwgZXhwbGFpbiB3 aHksIGFuZCBwb2ludCB0byB0aGUgcGFydCBvZg10aGUgZG9jdW1lbnQgd2hlcmUgdGhlIHJlbGF0 aW9uc2hpcCBvZiB0aGlzIGRvY3VtZW50IHRvIHRoZSBvdGhlciBSRkNzDWlzIGRpc2N1c3NlZC4g SWYgdGhpcyBpbmZvcm1hdGlvbiBpcyBub3QgaW4gdGhlIGRvY3VtZW50LCBleHBsYWluIHdoeQ10 aGUgaW50ZXJlc3RlZCBjb21tdW5pdHkgY29uc2lkZXJzIGl0IHVubmVjZXNzYXJ5Lg0NICAgIE5v LiANDSgxNykgRGVzY3JpYmUgdGhlIERvY3VtZW50IFNoZXBoZXJkJ3MgcmV2aWV3IG9mIHRoZSBJ QU5BIGNvbnNpZGVyYXRpb25zDXNlY3Rpb24sIGVzcGVjaWFsbHkgd2l0aCByZWdhcmQgdG8gaXRz IGNvbnNpc3RlbmN5IHdpdGggdGhlIGJvZHkgb2YgdGhlDWRvY3VtZW50LiBDb25maXJtIHRoYXQg YWxsIHByb3RvY29sIGV4dGVuc2lvbnMgdGhhdCB0aGUgZG9jdW1lbnQgbWFrZXMNYXJlIGFzc29j aWF0ZWQgd2l0aCB0aGUgYXBwcm9wcmlhdGUgcmVzZXJ2YXRpb25zIGluIElBTkEgcmVnaXN0cmll cy4NQ29uZmlybSB0aGF0IGFueSByZWZlcmVuY2VkIElBTkEgcmVnaXN0cmllcyBoYXZlIGJlZW4g Y2xlYXJseQ1pZGVudGlmaWVkLiBDb25maXJtIHRoYXQgbmV3bHkgY3JlYXRlZCBJQU5BIHJlZ2lz dHJpZXMgaW5jbHVkZSBhDWRldGFpbGVkIHNwZWNpZmljYXRpb24gb2YgdGhlIGluaXRpYWwgY29u dGVudHMgZm9yIHRoZSByZWdpc3RyeSwgdGhhdA1hbGxvY2F0aW9ucyBwcm9jZWR1cmVzIGZvciBm dXR1cmUgcmVnaXN0cmF0aW9ucyBhcmUgZGVmaW5lZCwgYW5kIGENcmVhc29uYWJsZSBuYW1lIGZv ciB0aGUgbmV3IHJlZ2lzdHJ5IGhhcyBiZWVuIHN1Z2dlc3RlZCAoc2VlIFJGQyA1MjI2KS4NDSAg ICBUaGlzIGRvY3VtZW50IGRvZXNuJ3QgcmVxdWlyZSBhbnkgSUFOQSBhY3Rpb25zLiBBIGNvbXBh bmlvbiBkcmFmdA0gICAgY2hhbmdlcyB0aGUgSUFOQSBhbGxvY2F0aW9ucyByYW5nZXMgZm9yIE9T UEZ2MyBJbnN0YW5jZSBJRHMuDQ0oMTgpIExpc3QgYW55IG5ldyBJQU5BIHJlZ2lzdHJpZXMgdGhh dCByZXF1aXJlIEV4cGVydCBSZXZpZXcgZm9yIGZ1dHVyZQ1hbGxvY2F0aW9ucy4gUHJvdmlkZSBh bnkgcHVibGljIGd1aWRhbmNlIHRoYXQgdGhlIElFU0cgd291bGQgZmluZA11c2VmdWwgaW4gc2Vs ZWN0aW5nIHRoZSBJQU5BIEV4cGVydHMgZm9yIHRoZXNlIG5ldyByZWdpc3RyaWVzLg0NICAgICBO b25lLiAgDQ0NKDE5KSBEZXNjcmliZSByZXZpZXdzIGFuZCBhdXRvbWF0ZWQgY2hlY2tzIHBlcmZv cm1lZCBieSB0byB2YWxpZGF0ZQ1zZWN0aW9ucyBvZiB0aGUgZG9jdW1lbnQgd3JpdHRlbiBpbiBh IGZvcm1hbCBsYW5ndWFnZSwgc3VjaCBhcyBYTUwgY29kZSwNQk5GIHJ1bGVzLCBNSUIgZGVmaW5p dGlvbnMsIGV0Yy4NDSAgICAgTm90IEFwcGxpY2FibGUuIA0= --_004_94A203EA12AECE4BA92D42DBFFE0AE470C202Beusaamb101ericsso_-- From chenxibj@cn.ibm.com Tue Feb 12 12:07:49 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACC621F9038 for ; Tue, 12 Feb 2013 12:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, 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 9ogPyy5YmFHW for ; Tue, 12 Feb 2013 12:07:48 -0800 (PST) Received: from e23smtp02.au.ibm.com (e23smtp02.au.ibm.com [202.81.31.144]) by ietfa.amsl.com (Postfix) with ESMTP id 414FE21F8DCF for ; Tue, 12 Feb 2013 12:07:45 -0800 (PST) Received: from /spool/local by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 13 Feb 2013 06:01:45 +1000 Received: from d23dlp02.au.ibm.com (202.81.31.213) by e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 13 Feb 2013 06:01:44 +1000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [9.190.235.21]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id CC7792BB0050 for ; Wed, 13 Feb 2013 07:07:36 +1100 (EST) Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r1CK7ZYt6685140 for ; Wed, 13 Feb 2013 07:07:35 +1100 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r1CK7aPg003773 for ; Wed, 13 Feb 2013 07:07:36 +1100 Received: from d23ml021.cn.ibm.com (d23ml021.cn.ibm.com [9.119.32.97]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r1CK7ZQ1003736 for ; Wed, 13 Feb 2013 07:07:36 +1100 Auto-Submitted: auto-generated From: Xi R Chen To: ospf@ietf.org Message-ID: Date: Wed, 13 Feb 2013 04:06:16 +0800 X-MIMETrack: Serialize by Router on d23ml021/23/M/IBM(Release 8.5.3FP2HF29 | July 24, 2012) at 02/13/2013 04:06:17 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=C7BBF183DFFDE9718f9e8a93df938690918cC7BBF183DFFDE971" Content-Disposition: inline X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13021220-5490-0000-0000-000002F32D36 Subject: [OSPF] AUTO: Xi R Chen is out of the office (returning 02/18/2013) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 20:07:49 -0000 --0__=C7BBF183DFFDE9718f9e8a93df938690918cC7BBF183DFFDE971 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 02/18/2013. I will on duty for CPS on 2/10, 2/12, 2/14 Anything urgent, reach me at +86 13810876541 Note: This is an automated response to your message "OSPF Digest, Vol = 84, Issue 2" sent on 02/13/2013 4:00:18. This is the only notification you will receive while this person is awa= y.= --0__=C7BBF183DFFDE9718f9e8a93df938690918cC7BBF183DFFDE971 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 02= /18/2013.

I will on duty for CPS on 2= /10, 2/12, 2/14
Anything urgent, reach me a= t +86 13810876541


Note: Thi= s is an automated response to your message  "OSPF Digest, Vol 84, Issue 2" sent = on 02/13/2013 4:00:18.

This is t= he only notification you will receive while this person is away.= = --0__=C7BBF183DFFDE9718f9e8a93df938690918cC7BBF183DFFDE971-- From acee.lindem@ericsson.com Tue Feb 19 06:24:31 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4446621F8BF6; Tue, 19 Feb 2013 06:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81riMUu39Bm6; Tue, 19 Feb 2013 06:24:28 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 73E9D21F8873; Tue, 19 Feb 2013 06:24:27 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-a9-51238b1a0441 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 76.A7.03705.A1B83215; Tue, 19 Feb 2013 15:24:27 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 09:24:25 -0500 From: Acee Lindem To: " " Thread-Topic: ISIS TE Metric Extension Discussion (IETF-85 Followup) Thread-Index: AQHODmxXCA5/6zyM6kyuQL6T6MtVQJiBJNBwgABrygA= Date: Tue, 19 Feb 2013 14:24:25 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470DFB49@eusaamb101.ericsson.se> References: In-Reply-To: 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec9tx5FynJpvWhBaX9JKY9DrpShMOt2dYXalBp5UUrFtSn0R 0y1lCklK0po5bWk6YTnK5i1lalCUWnir1LzMO6bZbEgwcjt92Lffy/P7v8//w0Pjot9EAJ2a oeBkGdK0IEpIlGa1Je4NLAqWhM3ocbQ+dBM1PymmkOPHCI66OssFyFBQRqLn5hGAPk+/xVBL owGg1zMDAPVYVkikHYtBDR0PASrMXybQz85eDCnHxwWotq+HQl31hRgytk5h6HtZHjjiw6pm 20lWX7SCsZ++Ogi27G8jydraA9hmzZiAVXYvbw71Gxg7nDcoYFdN+RT7zHaWHV0qFrAbLWqM Vdn94rwuC6OTuLTUbE62//ANYYouvxzPnAy+Mz80IcgFT3eogQcNGTH8pdMCnrfC/nEjpQZC WsR0A1g3YSb5Ry2AUyUjAqdFMaFwbsqBO9mXuQAr7nXgTglnmiioXFvGnAMfJgZqLX/+S8dg zeIAxXMkVL7QkE4mmN3wUWOriz2ZU9A6OuzyRUw8LFlfdFXyYM5DY5XZtRhs1rN/aHD9jzP+ 8Ju1EuNrM1Df1ofz7AcXph0kz8FQb+0geD8U6lrXKJ6jYJfRgvMcAmuqlnC+gzd8/9hKlAB/ jdsKjVtc4xbXuMU1bnEdIOsBnSXnstOTD4SbwObhvIPUUTPQrUVYQCBNBPl7JsT2x4mYZKmC u8VxmZzsuiwrjZNbAEZ7BOQCc9eSeDAso8+7+bgoMbqK/rgvYXJ0RrVFsXrO0Gnfru1FZeIm 0nTparXkYOHKl7nTsxelRTLJm9vGWZtErM9bXIrujtiZVB1fOh+rrU+zeOVcM51Q+dpoQ0Us IF4eurKQo0pXRFXmrrJ1d0OMu+wFqgcneyrX1fe3nbFFvooJIuQp0vA9uEwu/QfXgm3TBgMA AA== Cc: George Swallow , "equinox-ietf@diac24.net" , "isis-wg@ietf.org" , Clarence Filsfils , "nabil.n.bitar@verizon.com" , "kireeti.kompella@gmail.com" , Robert Raszuk , Samita Chakrabarti , Alia Atlas , "dward@bgp.nu" , OSPF List Subject: Re: [OSPF] ISIS TE Metric Extension Discussion (IETF-85 Followup) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 14:24:31 -0000 Hi Spence,=20 Note that the bar for WG last call and request for publication as a standar= ds track RFC is quite a bit higher than for WG adoption (OSPF WG copied). W= e need to have this discussion now and either address the questions surroun= ding the delay metrics or agree that they are out of scope.=20 Having said that, speaking as a WG member of both WGs, I have re-read the d= raft and don't have problems with the guidance given for delay metrics when= these metrics are used for TE.=20 Thanks, Acee=20 On Feb 19, 2013, at 7:58 AM, wrote: > Pls note that the ospf wg has already adopted express path as ospf metric= extensions. >=20 > We really need to stop talking about the fuxh drafts. A) we (john, dave, = alia, myself) are not primary authors, and b) those drafts are "application= " drafts. Pls read my slide deck for more info on that >=20 > Even assuming you don't agree with fuxh or Alias draft (which I support) = then we do NOT need to hold up metric extensions. The metric extensions dra= fts support the others, but are not the same thing >=20 >=20 >=20 >=20 > ----- Original Message ----- > From: Curtis Villamizar [mailto:curtis@occnc.com] > Sent: Tuesday, February 19, 2013 12:42 AM > To: Lou Berger > Cc: Giacalone, Spencer (Financial&Risk); jdrake@juniper.net ; donald.fedyk@alcatel-lucent.com ;= chopps@rawdofmt.org ; isis-wg@ietf.org ; hshah@ciena.com ; acee.lindem@ericsson.com ; curtis@occnc.com ; samita.chakrabarti@= ericsson.com ; nabil.n.bitar@verizon.com <= nabil.n.bitar@verizon.com>; equinox-ietf@diac24.net ; huaimo.chen@huawei.com ; dward@bgp.nu ; swallow@cisco.com ; raszuk@cisco.com ; sprevidi@cisco.com ; kireeti.kompella@gmail.com= ; akatlas@juniper.net ; c= filsfil@cisco.com > Subject: Re: ISIS TE Metric Extension Discussion (IETF-85 Followup) >=20 >=20 > In message <511E40B0.40903@labn.net> > Lou Berger writes: >=20 >> Spencer, >>=20 >> On 2/14/2013 7:19 PM, you wrote: >>> The use case is my network, where I want to setup TE tunnels based on >>> performance, not cost, and I want to re-groom when changes occur, >>> such as when optical path protect kicks in underneath me. >>>=20 >>=20 >> ... >>=20 >>> To your comment about adaptive routing, if you read the draft, it's >>> clear we are aiming at TE tunnel setup/comp, not IGP manipulation >>>=20 >>=20 >> I think you're providing critical context that some may have missed >> during the presentation. A slide or two on use case (rather then just >> the generic nature of the extension) probably would have helped... >>=20 >> WRT the draft, I think referencing the related drafts >> (draft-fuxh-mpls-delay-loss-te-problem-statement and/or >> draft-fuxh-mpls-delay-loss-te-framework) would provide the needed >> pointer for those not familiar with the context. >>=20 >> Lou >=20 >=20 >=20 > My point at IETF-85 which still stands are: >=20 > 1. There needs to be a problem statement, requirements, and > framework providing that context. >=20 > 2. draft-fuxh-mpls-delay-loss-te-problem-statement and/or > draft-fuxh-mpls-delay-loss-te-framework are candidates but in > poor shape. [btw- I emailed the set of authors of > problem-statement about a week or more ago and got no response.] >=20 > 3. As is the requirements of draft-fuxh-mpls-delay-loss-te-* are > not met by the isis or ospf te extensions (for example, a > working and protect relative delay is discussed, which would > require a min delay and max delay, not just a delay which is > implied to be min). >=20 > 4. There are Composite Link requirements that should be met. The > draft-fuxh-mpls-delay-loss-te-* drafts cite this work but > address a subset of the issues related to delay and jitter. For > example, the topic of stability is completely ignored. >=20 > So my points still stand. >=20 > It was premature to move the ospf work to wg. It is premature to move > this to wg. The same issues need to be addressed in both since they > are functionally identical. >=20 > Curtis From equinox@diac24.net Fri Feb 22 03:59:11 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290C521F8782 for ; Fri, 22 Feb 2013 03:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIS77aIAl1CV for ; Fri, 22 Feb 2013 03:59:10 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 714D321F8759 for ; Fri, 22 Feb 2013 03:59:10 -0800 (PST) Received: from jupiter.n2.diac24.net ([2001:8d8:81:5c2::]) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U8rHM-0000eu-QF for ospf@ietf.org; Fri, 22 Feb 2013 12:59:04 +0100 Received: from equinox by jupiter.n2.diac24.net with local-bsmtp (Exim 4.80.1) (envelope-from ) id 1U8rH9-00DYO9-OI for ospf@ietf.org; Fri, 22 Feb 2013 12:58:54 +0100 Date: Fri, 22 Feb 2013 12:48:22 +0100 From: David Lamparter To: "Fred Baker (fred)" Message-ID: <20130222114822.GA3183407@jupiter.n2.diac24.net> References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <51273FE8.7050302@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ole Troan , "isis-chairs@tools.ietf.org" , "ospf@ietf.org" , Ray Hunter , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [OSPF] [homenet] Egress Routing Discussion: Baker model X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:59:11 -0000 On Fri, Feb 22, 2013 at 07:17:04PM +0900, Lorenzo Colitti wrote: > On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter wrote: > > > But given that route determination is a distributed algorithm, and that > > Homenet devices will not always run the latest and greatest code, > > what action should nodes that are running older code take regarding any > > TLV options that they don't understand? > > > > Isn't there a danger that extensibility will lead to more routing loops, > > instability, and black holes? > > Yes. If intermediate devices don't understand SADR, you can get routing > loops. We should document that clearly and find out how to avoid it. [quoting the earler loop sketch for convenience] | If 4. is not given, this scenario will lead to a loop: | All links assumed at equal cost, r2 does not support simplified SADR, | R1,R3,R4 do. | | ISP_A, pfx_A ::/0 ISP_B, pfx_B, ::/0 | | | | R1 ------ r2 ------ R3 ------ R4 | | | Host | | Host now selects an address from pfx_B to reach some site on the | internet. R1 forwards to r2 because the ::/0 from R4 is more specific | on the source. r2 forwards back to R1 because it didn't consider source | specific-ness and just went by lower cost... [/quote] Since I complained about this earlier, I feel obliged to throw possible approaches around. I'm excluding the prefix-assignment-integrated approach to distributing SADR routing information since that would supposedly by design require all participants to support SADR. For both "simple" and "full-blown" OSPFv3 the following loop/interop mechnisms come to my mind: 1. refusing adjacencies between SADR and non-SADR routers. Easily implemented with a Hello bit, this is the crowbar solution. Quite sufficient for homenet I guess, but probably less acceptable for anything else. 2. flagging SADR support in router LSAs/LSPs. Provides enough information to avoid loops. Three things can be done with this information: 2a. install null/reject routes for paths that cross non-SADR routers. Provides adequate failure semantics, instead of looping packets around we get an ICMP unreachable. Easy to implement. Downside: if there really is a non-SADR router, "not working" is now a state that is part of the result set of the dynamic route calculations. Users (and admins) probably do not expect this. 2b. calculate SPF around non-SADR routers Gets us a working network, but at a cost: there may now be 2 different paths to reach some faraway router, one for SADR-routed packets and a different one for non-SADR packets. Depending on how the router performs its SPF calculations, this can be hard to implement correctly - it's essentially a very narrowly and exactly specified case of multitopology routing. 2c. on encountering non-SADR routers, figure whether they'll do the right thing with the packet. ... complicated and of questionable use IMHO. Just listing this for completeness. 2a and 2b can be mixed with each other; packets will get passed along by 2a-type routers until they get discarded at a 2b-type router. My personal opinion at this point is that 2a and 2b should both be specified, with a requirement to indicate support level in the router documentation. We're unlikely to encounter normal OSPFv3 speakers in a plain "production/final" homenet, so they could take the easy way. If this gets implemented on routers for enterprise use, I'd expect 2b behaviour. (With the Baker OSPF/ISIS SADR specs quite independent from homenet as they are right now, I think getting homenet-only solutions in those is an unwise idea; homenet optimisation possibilities like allowing fallback to 2a on the other hand should be acceptable.) -David From fred@cisco.com Fri Feb 22 09:41:45 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAE421F8E4B; Fri, 22 Feb 2013 09:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq18V+UgrOpG; Fri, 22 Feb 2013 09:41:44 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 60FF821F8E3A; Fri, 22 Feb 2013 09:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3318; q=dns/txt; s=iport; t=1361554904; x=1362764504; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QL6KVtFNkCc4WY3XW2BJZJglKP/cmZoNz3bV5182DZA=; b=Y30g1qO0KYxWiWx1ieQ0tdtcd48YV6XThtXIJSxtkPbI8IHziHgV+/Tr 2BzuPbBOYtCDSf+W1XrtfW/CyKQuhONgGfRZRZSnT7x4O6J+C5DfG+zsi LHKeaIXMFpbR3qBdimiMPvlYqd51Nxxd3wTQvAzErr9Xj0txyvaTc+zs3 E=; X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="scan'208";a="180156301" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 22 Feb 2013 17:41:44 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1MHfis7013029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 17:41:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 11:41:43 -0600 From: "Fred Baker (fred)" To: David Lamparter Thread-Topic: [homenet] Egress Routing Discussion: Baker model Thread-Index: AQHOESPgQtloSZFSukSmTv1pgutDzQ== Date: Fri, 22 Feb 2013 17:41:43 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B79F4E1@xmb-rcd-x09.cisco.com> References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <51273FE8.7050302@globis.net> <20130222114822.GA3183407@jupiter.n2.diac24.net> In-Reply-To: <20130222114822.GA3183407@jupiter.n2.diac24.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.246.89] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ole Troan , "isis-chairs@tools.ietf.org" , "ospf@ietf.org" , Ray Hunter , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [OSPF] [homenet] Egress Routing Discussion: Baker model X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:41:45 -0000 inline=20 On Feb 23, 2013, at 12:48 AM, David Lamparter wrote: > For both "simple" and "full-blown" OSPFv3 the following loop/interop > mechnisms come to my mind: >=20 > 1. refusing adjacencies between SADR and non-SADR routers. > Easily implemented with a Hello bit, this is the crowbar solution. > Quite sufficient for homenet I guess, but probably less acceptable > for anything else. >=20 > 2. flagging SADR support in router LSAs/LSPs. > Provides enough information to avoid loops. Three things can be done > with this information: >=20 > 2a. install null/reject routes for paths that cross non-SADR routers. > Provides adequate failure semantics, instead of looping packets > around we get an ICMP unreachable. Easy to implement. > Downside: if there really is a non-SADR router, "not working" is > now a state that is part of the result set of the dynamic route > calculations. Users (and admins) probably do not expect this. >=20 > 2b. calculate SPF around non-SADR routers > Gets us a working network, but at a cost: there may now be 2 > different paths to reach some faraway router, one for SADR-routed > packets and a different one for non-SADR packets. Depending on how > the router performs its SPF calculations, this can be hard to > implement correctly - it's essentially a very narrowly and exactly > specified case of multitopology routing. >=20 > 2c. on encountering non-SADR routers, figure whether they'll do the > right thing with the packet. > ... complicated and of questionable use IMHO. Just listing this > for completeness. >=20 > 2a and 2b can be mixed with each other; packets will get passed along by > 2a-type routers until they get discarded at a 2b-type router. >=20 > My personal opinion at this point is that 2a and 2b should both be > specified, with a requirement to indicate support level in the router > documentation. We're unlikely to encounter normal OSPFv3 speakers in a > plain "production/final" homenet, so they could take the easy way. If > this gets implemented on routers for enterprise use, I'd expect 2b > behaviour. So you want the non-SADR routers to implement a null route, and the SADR ro= uters to route around the non-SADR routers. I'm scratching my head on how the un-updated routers would know to install = a null route if they don't understand the information.=20 I do think it would be straightforward to add a flag to the Hello indicatin= g that they understand such updates, and refusing to neighbor with a router= that doesn't. We have done that for other features. That does mean that ad= ding a router to an area that understands the updates forces an update to a= ll of the routers in an area, which could be a pain when upgrading.=20 Setting a flag in the Router LSA indicating willingness to handle these rou= tes is possible, but takes us in the direction of topological routing. My p= roblem with approaching it as a topology is the implied management overhead= ; we need to know whether to include any given router or link in a given to= pology, and where we might have advertised topology-specific metrics in RFC= 4915, we now want to infer that from a capability flag. ick.=20 From equinox@diac24.net Fri Feb 22 19:05:04 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079B921F8F1C; Fri, 22 Feb 2013 19:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvhKhiy-hfq8; Fri, 22 Feb 2013 19:05:03 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AC521F8F2A; Fri, 22 Feb 2013 19:04:58 -0800 (PST) Received: from jupiter.n2.diac24.net ([2001:8d8:81:5c2::]) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U95Pr-0002bA-Qv; Sat, 23 Feb 2013 04:04:47 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1U95Pe-00EM1J-Ad; Sat, 23 Feb 2013 04:04:37 +0100 Date: Sat, 23 Feb 2013 04:04:34 +0100 From: David Lamparter To: "Fred Baker (fred)" Message-ID: <20130223030434.GD3183407@jupiter.n2.diac24.net> References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <51273FE8.7050302@globis.net> <20130222114822.GA3183407@jupiter.n2.diac24.net> <8C48B86A895913448548E6D15DA7553B79F4E1@xmb-rcd-x09.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C48B86A895913448548E6D15DA7553B79F4E1@xmb-rcd-x09.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ole Troan , "isis-chairs@tools.ietf.org" , Ray Hunter , "ospf@ietf.org" , Lorenzo Colitti , "homenet@ietf.org Group" Subject: Re: [OSPF] [homenet] Egress Routing Discussion: Baker model X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 03:05:04 -0000 also inline On Fri, Feb 22, 2013 at 05:41:43PM +0000, Fred Baker (fred) wrote: > inline > > On Feb 23, 2013, at 12:48 AM, David Lamparter > wrote: > > For both "simple" and "full-blown" OSPFv3 the following loop/interop > > mechnisms come to my mind: > > > > 1. refusing adjacencies between SADR and non-SADR routers. > > Easily implemented with a Hello bit, this is the crowbar solution. > > Quite sufficient for homenet I guess, but probably less acceptable > > for anything else. > > > > 2. flagging SADR support in router LSAs/LSPs. > > Provides enough information to avoid loops. Three things can be done > > with this information: > > > > 2a. install null/reject routes for paths that cross non-SADR routers. > > Provides adequate failure semantics, instead of looping packets > > around we get an ICMP unreachable. Easy to implement. > > Downside: if there really is a non-SADR router, "not working" is > > now a state that is part of the result set of the dynamic route > > calculations. Users (and admins) probably do not expect this. > > > > 2b. calculate SPF around non-SADR routers > > Gets us a working network, but at a cost: there may now be 2 > > different paths to reach some faraway router, one for SADR-routed > > packets and a different one for non-SADR packets. Depending on how > > the router performs its SPF calculations, this can be hard to > > implement correctly - it's essentially a very narrowly and exactly > > specified case of multitopology routing. > > > > 2c. on encountering non-SADR routers, figure whether they'll do the > > right thing with the packet. > > ... complicated and of questionable use IMHO. Just listing this > > for completeness. > > > > 2a and 2b can be mixed with each other; packets will get passed along by > > 2a-type routers until they get discarded at a 2b-type router. > > > > My personal opinion at this point is that 2a and 2b should both be > > specified, with a requirement to indicate support level in the router > > documentation. We're unlikely to encounter normal OSPFv3 speakers in a > > plain "production/final" homenet, so they could take the easy way. If > > this gets implemented on routers for enterprise use, I'd expect 2b > > behaviour. > > > So you want the non-SADR routers to implement a null route, and the > SADR routers to route around the non-SADR routers. No - sorry for not wording this clearly enough. I want SADR routers to notice that they've hit a non-SADR router in their SPF calculation. And if they do, the SADR routers can either install a null route (and keep topological sanity, flagging the route under consideration down as "sorry no can do"), or go the alternate topology way. > I'm scratching my head on how the un-updated routers would know to > install a null route if they don't understand the information. They don't, indeed. > I do think it would be straightforward to add a flag to the Hello > indicating that they understand such updates, and refusing to neighbor > with a router that doesn't. We have done that for other features. That > does mean that adding a router to an area that understands the updates > forces an update to all of the routers in an area, which could be a > pain when upgrading. I think moving this flag to the router LSA is under all circumstances preferable over this. With the null route variant, it gives a painless upgrading path that keeps plain-old destination routing working; SADR can then be put into use when the relevant routers have the support. > Setting a flag in the Router LSA indicating willingness to handle > these routes is possible, but takes us in the direction of topological > routing. My problem with approaching it as a topology is the implied > management overhead; we need to know whether to include any given > router or link in a given topology, and where we might have advertised > topology-specific metrics in RFC 4915, we now want to infer that from > a capability flag. ick. This is exactly why the SADR routers can instead go install a null route, the only thing needed there is checking whether any router on the calculated path doesn't support SADR. FWIW, I think the double topology idea is not completely out of whack, though admittedly complicated and complex. The semantics are reasonably well-defined, it boils down to bifurcating into exactly two topologies, one normal and one SADR. I'm not particularly keen or tacked down on it though. -David P.S.: I can write this up in spec form if desired, I'm relatively new to IETF and have no idea how this works and all. Shall I put some text together for the null route variant and throw it in here? That would as a side effect make it easier to evaluate the idea, I think. From spencer.giacalone@gmail.com Mon Feb 25 16:22:08 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDC721E8181; Mon, 25 Feb 2013 16:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4Z9PIt8iYWa; Mon, 25 Feb 2013 16:22:07 -0800 (PST) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id B106A21E817A; Mon, 25 Feb 2013 16:22:06 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id 14so2822281vea.15 for ; Mon, 25 Feb 2013 16:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=lsWguKHsr/fLAu9nmW0At66JKXWQ9KtSl5NHxT7qHdQ=; b=fe0j+ZvJRpFI5yY9VMikqemqNBj/oKzp5xeVf7bVQTxfluGtxuvCI2UZpOnYylP7zb OH4mbG5A125EvGVMS3CxL4bs3ruYO+rFy96ClrCRIYsxImeXff1KOc1Y5huryQsfkY3c 9YQRddAOcRA+f/COyvfGqTOQ/DWzTQqfEzmxcchsmtedclLfdxDYe33HKFJWsMpmBUDv gK2s8YTs/NXaa60a7BmnkhcwfwTYmDEQnQLjdsEp03w96s3c6hQsv8v+PRT5LSwV8ohP nPF2YKJyLkPO2tJZYNDE7AZtGZ4FgBM9dhsNyCScJDIm01RLzD7aiF9246SXFHI5qepe psTQ== MIME-Version: 1.0 X-Received: by 10.58.12.200 with SMTP id a8mr10829543vec.52.1361838126236; Mon, 25 Feb 2013 16:22:06 -0800 (PST) Received: by 10.220.74.67 with HTTP; Mon, 25 Feb 2013 16:22:06 -0800 (PST) Date: Mon, 25 Feb 2013 19:22:06 -0500 Message-ID: From: Spencer Giacalone To: OSPF List Content-Type: text/plain; charset=ISO-8859-1 Cc: George Swallow , "nabil.n.bitar@verizon.com" , "isis-wg@ietf.org" , Clarence Filsfils , "equinox-ietf@diac24.net" , "dward@bgp.nu" , Robert Raszuk , Samita Chakrabarti , Alia Atlas , "kireeti.kompella@gmail.com" Subject: [OSPF] New Rev OSPF TE Metric Extensions X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 00:22:08 -0000 All, We have posted a new rev of OSPF TE Metric Extensions. The main change in it is the inclusion of some text related to *not* including queue delay in delay calculations. This should help mitigate some of the concerns that were voiced. In my opinion, the concerns around oscillations are already addressed. However we are open to discussing changes to accommodate encoding information related to metric measurement schemes. Please give it a read and comment as needed. Spence From sprevidi@cisco.com Tue Feb 26 00:28:16 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9625921F86C3 for ; Tue, 26 Feb 2013 00:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.932 X-Spam-Level: X-Spam-Status: No, score=-110.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWYtyFZyhc+R for ; Tue, 26 Feb 2013 00:28:16 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E316321F86C5 for ; Tue, 26 Feb 2013 00:28:15 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1Q8SCwK012537 for ; Tue, 26 Feb 2013 09:28:15 +0100 (CET) Received: from dhcp-rom2-bb-gw-vla250-10-147-74-83.cisco.com (dhcp-rom2-bb-gw-vla250-10-147-74-83.cisco.com [10.147.74.83]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1Q8S8co015356; Tue, 26 Feb 2013 09:28:09 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: stefano previdi In-Reply-To: Date: Tue, 26 Feb 2013 09:28:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4119E656-A95D-4542-8CEB-605DE32A34B7@cisco.com> References: To: Spencer Giacalone X-Mailer: Apple Mail (2.1283) Cc: George Swallow , "nabil.n.bitar@verizon.com" , "isis-wg@ietf.org" , Clarence Filsfils , Samita Chakrabarti , "equinox-ietf@diac24.net" , "dward@bgp.nu" , Robert Raszuk , OSPF List , Alia Atlas , "kireeti.kompella@gmail.com" Subject: Re: [OSPF] New Rev OSPF TE Metric Extensions X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 08:28:16 -0000 All, we also posted the ISIS companion draft: = http://www.ietf.org/internet-drafts/draft-previdi-isis-te-metric-extension= s-03.txt with the same changes of the OSPF draft. Thanks. s. On Feb 26, 2013, at 1:22 AM, Spencer Giacalone wrote: > All, >=20 > We have posted a new rev of OSPF TE Metric Extensions. The main change > in it is the inclusion of some text related to *not* including queue > delay in delay calculations. This should help mitigate some of the > concerns that were voiced. >=20 > In my opinion, the concerns around oscillations are already addressed. > However we are open to discussing changes to accommodate encoding > information related to metric measurement schemes. >=20 > Please give it a read and comment as needed. >=20 >=20 > Spence > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20