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

"Stefano Previdi (sprevidi)" <sprevidi@cisco.com> Fri, 06 November 2015 13:18 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 AE25D1A89F2; Fri, 6 Nov 2015 05:18:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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, 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 cHlRa_fpnV-7; Fri, 6 Nov 2015 05:18:21 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FEF21A8A04; Fri, 6 Nov 2015 05:18:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22705; q=dns/txt; s=iport; t=1446815901; x=1448025501; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zaKZ5yGd7e0Jc5kJqopC4h69S1lxWPX8wDPhT8/0ln4=; b=gXoO7GKTVHb/3fEWZ8GOyxjUMHtmLdMOD9CkBGpQybBGu13MVmBH5nDn /W4yhqFgicPbxFTyU++uerCvfGQyTYcdY3KWSbu//j+Wt+y3UspPsEtKb LCMy3ZnzYIBPmpckzlX7vwKJQFIObh0Cx5bUIGjSTDeE+jDJwUwF0jyZj A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D+AQBwpzxW/5BdJa1egztTbwa+IAENgWAXAQmFbwKBOTgUAQEBAQEBAYEKhDYBAQQBAQFrCxACAQg/BycLFBECBA4FiC4NwUIBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZUghCCbogkgRUFh0SLI4NhAYgMhRiBW5IWiFIBHwEBQoIRHYFWcoQNgQcBAQE
X-IronPort-AV: E=Sophos;i="5.20,252,1444694400"; d="scan'208,217";a="205027930"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP; 06 Nov 2015 13:18:20 +0000
Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tA6DIJ2l023919 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Nov 2015 13:18:20 GMT
Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 6 Nov 2015 08:18:19 -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; Fri, 6 Nov 2015 08:18:19 -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+O5jvuAkmSupOY8ZJPb56PZPUA
Date: Fri, 06 Nov 2015 13:18:19 +0000
Message-ID: <5104A350-EA8D-4824-A396-1DC46140BA5D@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.161.25]
Content-Type: multipart/alternative; boundary="_000_5104A350EA8D4824A3961DC46140BA5Dciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/fxCAc0l7CLuT85ACmjqzEAVMb60>
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: Fri, 06 Nov 2015 13:18:24 -0000

Hi Eric,

the proposed text looks good but with one question below.


On Oct 22, 2015, at 10:16 PM, Eric C Rosen <erosen@juniper.net<mailto: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.




why would you need such limitation ? A prefix may have a shorter mask than 32 (or 128) and still be ok for the Originator SRGB to be there.

The Originator-SRGB may only be inserted by the originator of the prefix, maybe we should emphasize that, but the masklength is mostly irrelevant here.

s.




[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<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr