Re: [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

"Stefano Previdi (sprevidi)" <sprevidi@cisco.com> Tue, 03 November 2015 15:23 UTC

Return-Path: <sprevidi@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611AD1A1EFE; Tue, 3 Nov 2015 07:23:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQ0uFwNoaskO; Tue, 3 Nov 2015 07:23:41 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71491A1EF7; Tue, 3 Nov 2015 07:23:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10018; q=dns/txt; s=iport; t=1446564220; x=1447773820; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=H73psq39cXqxPvW1vmQlljsOGB8mnGO8diL4tny8mE4=; b=NROy/SAK6GEnRttWCWy9457nz59notivZPZIAMpyRTOfab/8Frgj8TsC g9ZT31rclEhNmM1wcvjNCnE6k/0eJAaeSPjVnxr8lx3DHHPJFoHX0wZMY aFtbUQeiJR+/arwPE7lowg9OmfWqVKD42pW37/C5UikqahlzuaXp8/BJy s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D+AQBU0ThW/4kNJK1egztTbwa9SQENgV0XCoVzAhyBHjgUAQEBAQEBAYEKhDUBAQEDAQEBASAROgsFCwIBCBgCAiYCAgIlCxUQAgQOBYgmCA2wVZByAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASBEIVUghCCboRxgwUxgRQFh0SPAgGIDIUWgVqSEYhSAR8BAUKCER2BVnKEd4EHAQEB
X-IronPort-AV: E=Sophos;i="5.20,239,1444694400"; d="scan'208";a="47216023"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2015 15:23:16 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA3FNFOv014307 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Nov 2015 15:23:16 GMT
Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 10:23:14 -0500
Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.000; Tue, 3 Nov 2015 10:23:14 -0500
From: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
To: Eric C Rosen <erosen@juniper.net>
Thread-Topic: [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01
Thread-Index: AQHRDQaNSu+O5jvuAkmSupOY8ZJPb56K0N6A
Date: Tue, 03 Nov 2015 15:23:14 +0000
Message-ID: <7580D432-CB5A-4E9C-ABC4-0F9FDBC68505@cisco.com>
References: <56294416.8030807@juniper.net>
In-Reply-To: <56294416.8030807@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.78.21]
Content-Type: text/plain; charset="utf-8"
Content-ID: <1D4498BB9909BC4CBCB2668F049983EC@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/vCvWISezLxgG55xOMjkakRPjdj4>
Cc: idr wg <idr@ietf.org>, SPRING WG <spring@ietf.org>
Subject: Re: [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2015 15:23:43 -0000

Hi Eric,

sorry for coming back late to you. I’ll go through our suggestions asap.

Thanks.
s.


> On Oct 22, 2015, at 10:16 PM, Eric C Rosen <erosen@juniper.net> wrote:
> 
> I'd like to make some suggestions for textual changes to sections 3.1 and 
> 4.3 of draft-ietf-idr-prefix-sid.  The main purpose of these suggestions is 
> to clarify the use of the Originator SRGB TLV, and to remove what I 
> think is an excessive and distracting amount of repetition about the 
> inadvisability of allowing different nodes to use different SRGBs. 
> 
> My proposal for the text of these sections follows.  In addition to the 
> changes I mentioned above, some typos in the original text are fixed, and 
> there is a suggestion (explained below in brackets) for slightly modifying 
> the text about the AFI/SAFIs with which the Prefix-SID attribute may be 
> used.  A few other explanations can be found in brackets below inside the 
> proposed text. 
> 
> -------------------- 
> 
> 3.1.  MPLS Prefix Segment 
> 
>    In this document, we specify "MPLS Prefix Segments" only for BGP routes 
>    that have an AFI/SAFI of 1/4 or 2/4.  The applicability of MPLS prefix 
>    segments to other AFI/SAFIs is outside the scope of this document. 
> 
> [The original text said "A Multiprotocol BGP labeled IPv4/IPv6 Unicast 
> ([RFC3107]) session type is required", I don't think that is quite precise. 
> If a session has multiple AFI/SAFIs, including 1/4, I don't think we want to 
> say that the attribute can be placed in any UPDATE on that session.  Also, 
> it's not quite accurate to say that RFC3107 is restricted to 1/4 and 2/4; 
> RFC3107 doesn't mention the AFI.  And we may want to leave it open that the 
> Prefix Segment notion may eventually be applied somehow to SAFI-128 routes.] 
> 
>    The BGP Prefix Segment is realized on the MPLS dataplane in the 
>    following way: 
> 
>       As described in [I-D.ietf-spring-segment-routing-msdc] the 
>       operator assigns a globally unique "index", L_I, to a locally 
>       sourced prefix of a BGP speaker N which is advertised to all other 
>       BGP speakers in the SR domain. 
> 
>       According to [I-D.ietf-spring-segment-routing], each BGP speaker 
>       is configured with a label block called the Segment Routing Global 
>       Block (SRGB).  (While it is recommended to use the same SRGB across 
>       all the nodes within the SR domain, the SRGB of a node is a local 
>       property and could be different on different speakers). 
> 
>       The index L_I is a 32 bit offset in the SRGB.  Each BGP speaker 
>       derives its local MPLS label, L, by adding L_I to the start value 
>       of its own SRGB, and programs L in its MPLS dataplane as its 
>       incoming/local label for the prefix.  (See section 5.1 for more 
>       details.) 
> 
> [Added reference to section 5.1.] 
> 
>       The outgoing label for the prefix is found in the NLRI of the 
>       Multiprotocol BGP labeled IPv4/IPv6 Unicast prefix advertisement. 
>       The index L_I is only used as a hint to derive the local/incoming 
>       label. 
> 
>    Section 4.1 of this document specifies the Label-Index TLV of the BGP 
>    Prefix-SID attribute; this TLV can be used to advertise the label index 
>    of a given prefix. 
> 
>    If the BGP speakers are not all configured with the same SRGB, and if 
>    traffic-engineering within the SR domain is required, each node may be 
>    required to advertise its local SRGB.  One way of advertising the local 
>    SRGB is to use the segment routing extensions of BGP-LS 
>    (draft-gredler-idr-bgp-ls-segment-routing-ext-00.txt). An alternative 
>    option is to use the Originator SRGB TLV of the prefix-SID attribute, as 
>    specified in Section 4.3 of this document. 
> 
> [Rearranged last paragraphs slightly to improve flow, imo.] 
> 
> 
> 
> 4.3.  Originator SRGB TLV 
> 
>    The Originator SRGB TLV is an optional TLV and has the following 
>    format: 
> 
>      0                   1 2                   3 
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>     |     Type      |          Length               | Flags      | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>     |     Flags     | 
>     +-+-+-+-+-+-+-+-+ 
> 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>     |         SRGB 1 (6 octets)                                     | 
>     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>     |                               | 
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>     |         SRGB n (6 octets)                                     | 
>     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>     |                               | 
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> 
> [I can rarely get the ascii art to render correctly, but the diagram above 
> is supposed to be unchanged from what appears in the draft.] 
> 
>    where: 
> 
>    o  Type is 3. 
> 
>    o  Length is the total length of the value portion of the TLV: 2 + 
>       multiple of 6. 
> 
>    o  Flags: 16 bits of flags.  None are defined in this document. 
>       Flags SHOULD be clear on transmission and MUST be ignored at 
>       reception. 
> 
>    o  SRGB: 3 octets of base followed by 3 octets of range.  Note that the 
>       SRGB field MAY appear multiple times.  If the SRGB field appears 
>       multiple times, the SRGB consists of multiple ranges.  The meaning of 
>       an SRGB with multiple ranges is explained in Section 3.2 ("SID/Label 
>       Range TLV") of [I-D.ietf-ospf-segment-routing-extensions]. 
> 
> [Added some text about the semantics of the SRGB field appearing multiple 
> times, with reference to a document that actually explains it.] 
> 
>    When a BGP speaker attaches a Prefix-SID attribute to a given route, the 
>    Originator SRGB TLV MUST NOT be included in the attribute unless the 
>    following conditions hold: 
> 
>    - The prefix field of the route's NLRI contains a host address (i.e., a 
>      /32 IPv4 address or a /128 IPv6 address). 
> 
>    - The value of the Originator SRGB TLV specifies the SRGB of the node 
>      that is identified by the prefix field of the NLRI. 
> 
> [This paragraph and bullet items are added in order to make clear just what 
> the semantics of the TLV are.] 
> 
>    If a BGP route is received that contains a Prefix-SID attribute with an 
>    Originator SRGB TLV, but the prefix field of the NLRI does not contain a 
>    host address, the attribute SHOULD be regarded as malformed. If a 
>    Prefix-SID attribute contains more than one SRGB TLV, it SHOULD be 
>    regarded as malformed.  See section 7 for the treatment of a malformed 
>    Prefix-SID attribute. 
> 
>    When a route carrying the Prefix-SID attribute is propagated, the 
>    Originator SRGB TLV (if present) MUST NOT be changed. 
> 
> ----------------- 
> 
> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr