[OSPF] Fwd: New Version Notification for draft-gredler-ospf-label-advertisement-02.txt

Hannes Gredler <hannes@juniper.net> Mon, 06 May 2013 16:45 UTC

Return-Path: <hannes@juniper.net>
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 CB2AB21F8EFD for <ospf@ietfa.amsl.com>; Mon, 6 May 2013 09:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.467
X-Spam-Level:
X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, 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 0uUhTAcXBPXC for <ospf@ietfa.amsl.com>; Mon, 6 May 2013 09:44:58 -0700 (PDT)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id D67D221F912C for <ospf@ietf.org>; Mon, 6 May 2013 09:44:55 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUYfeBxagWLN9MyV14gcmCW5SxwEniNki@postini.com; Mon, 06 May 2013 09:44:55 PDT
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, 6 May 2013 09:43:24 -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; Mon, 6 May 2013 09:43:24 -0700
Received: from co1outboundpool.messaging.microsoft.com (216.32.180.185) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 May 2013 09:54:06 -0700
Received: from mail82-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE040.bigfish.com (10.243.66.105) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 May 2013 16:43:21 +0000
Received: from mail82-co1 (localhost [127.0.0.1]) by mail82-co1-R.bigfish.com (Postfix) with ESMTP id CDA9F8A0849 for <ospf@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Mon, 6 May 2013 16:43:20 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); (null); H:BL2PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -31
X-BigFish: PS-31(zf7Iz9371I936eI1454Iec9I1432I72dMzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dh8275chz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1155h)
Received: from mail82-co1 (localhost.localdomain [127.0.0.1]) by mail82-co1 (MessageSwitch) id 1367858598786698_15254; Mon, 6 May 2013 16:43:18 +0000 (UTC)
Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.245]) by mail82-co1.bigfish.com (Postfix) with ESMTP id BA5BB7C00AD; Mon, 6 May 2013 16:43:18 +0000 (UTC)
Received: from BL2PRD0512HT002.namprd05.prod.outlook.com (157.56.242.197) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 6 May 2013 16:43:18 +0000
Received: from agalvin-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.233.35) with Microsoft SMTP Server (TLS) id 14.16.305.3; Mon, 6 May 2013 16:43:14 +0000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Apple Message framework v1283)
From: Hannes Gredler <hannes@juniper.net>
Date: Mon, 06 May 2013 18:43:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-ID: <9B23BF6F-9020-41CC-A8F4-56C2F97C2A65@juniper.net>
References: <20130506163455.12024.14339.idtracker@ietfa.amsl.com>
To: ospf@ietf.org
X-Mailer: Apple Mail (2.1283)
X-Originating-IP: [193.110.54.36]
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%AMAZON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%VERIZON.COM$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-FOPE-CONNECTOR: Id%12219$Dn%LEVEL3.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
Cc: Tom Scholl <tscholl@amazon.com>, Shane Amante <Shane.Amante@Level3.com>, Luay Jalil <luay.jalil@verizon.com>
Subject: [OSPF] Fwd: New Version Notification for draft-gredler-ospf-label-advertisement-02.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2013 16:45:03 -0000

Dear OSPF working group,

have posted a new version of the OSPF label advertisement draft.
the major changes between -00 to -02 are:

-support for signaling Bypass (FRR) Labels
-support for SPT labels using RFC4761 'VPLS' style label block
 advertisements. this is mainly to comply to RFC3031 which
 mandates that label allocation is a strict local procedure,
 and still not loose the comfort of getting an
 automatically provided transport mesh (similar to LDP).

 This provides similar functionality like first mentioned in
 http://tools.ietf.org/id/draft-tian-mpls-lsp-source-route-01.txt
 *without* the need of an RFC 3031 architectural violation.

 The advertised label blocks allow in addition to specify a particular
 rfc4195 topology-ID and an algorithm (e.g. SPT). we got feedback
 that having a pluggable algorithm (e.g., but not limited to: MRT)
 would solve a couple of practical use cases for
 'infrastructure LSPs' in the area of make-before break, ordered FIB,
 etc.

the authors are looking for feedback and suggested text changes
to improve the draft. - please help us to make it better ;-)

as a vehicle to foster open collaboration we are VCing our work in github.
feel free to clone the repository at:
https://github.com/hannesgredler/draft-gredler-ospf-label-advertisement.git
send us pull requests with your suggested changes (or diffs using email);

thanks,

/hannes

Begin forwarded message:

> From: <internet-drafts@ietf.org>
> Subject: New Version Notification for draft-gredler-ospf-label-advertisement-02.txt
> Date: May 6, 2013 6:34:55 PM GMT+02:00
> To: Tom Scholl <tscholl@amazon.com>, Hannes Gredler <hannes@juniper.net>, Shane Amante <shane@level3.net>, Luay Jalil <luay.jalil@verizon.com>
> 
> 
> A new version of I-D, draft-gredler-ospf-label-advertisement-02.txt
> has been successfully submitted by Hannes Gredler and posted to the
> IETF repository.
> 
> Filename:	 draft-gredler-ospf-label-advertisement
> Revision:	 02
> Title:		 Advertising MPLS labels in OSPF
> Creation date:	 2013-05-06
> Group:		 Individual Submission
> Number of pages: 27
> URL:             http://www.ietf.org/internet-drafts/draft-gredler-ospf-label-advertisement-02.txt
> Status:          http://datatracker.ietf.org/doc/draft-gredler-ospf-label-advertisement
> Htmlized:        http://tools.ietf.org/html/draft-gredler-ospf-label-advertisement-02
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-gredler-ospf-label-advertisement-02
> 
> Abstract:
>   Historically MPLS label distribution was driven by protocols like
>   LDP, RSVP and LBGP.  All of those protocols are session oriented.  In
>   order to obtain label binding for a given destination FEC from a
>   given router one needs first to establish an LDP/RSVP/LBGP session
>   with that router.
> 
>   Advertising MPLS labels in IGPs
>   [I-D.gredler-rtgwg-igp-label-advertisement] describes several use
>   cases where utilizing the flooding machinery of link-state protocols
>   for MPLS label distribution allows to obtain the binding without
>   requiring to establish an LDP/RSVP/LBGP session with that router.
> 
>   This document describes the protocol extension to distribute MPLS
>   label bindings by the OSPFv2 and OSPFv3 protocol.
> 
> 
> 
> 
> 
> The IETF Secretariat
> 
>