Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

[Hannes Gredler <[e-mail]>]

hi zhenqiang,

i am further puzzled by your formulation "IP prefix" -
in BGP-LS there is no such thing as an "IP prefix" per se.

there is:
  -node-NLRIs
  -link-NLRIs
  -prefix-NLRIs

the "prefix-NRLI" is not so much used to advertise a prefix for routing,
its being used for advertising an association between a BGP next-hop
and a particular node.

/hannes

On Wed, Sep 03, 2014 at 11:41:38AM +0800, [e-mail] wrote:
|    RD should be followed by the IP prefix as specified in RFC4364.
|    Here in this draft, RD is follwed by the link state NLRI. Link state NLRI
|    has its own format. See the following example, the 24-bit-long IP prefix
|    is far away from RD.
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     |            NLRI Type = 3         |     Total NLRI Length         |
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     |                                                               |
|    +                       Route Distinguisher                     +
|     |                                                               |
|    +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    | Protocol-ID |
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    | Identifier |
|    | (64 bits) |
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    // Local Node Descriptor (variable) //
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    | Type = 265                            | Length |
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    | Prefix Length = 24 | IP Prefix (variable) //
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    The following format for the above example is consistent with RFC4364 in
|    my opinion.
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     |            NLRI Type = 3         |     Total NLRI Length         |
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    | Protocol-ID |
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    | Identifier |
|    | (64 bits) |
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    // Local Node Descriptor (variable) //
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    | Type = 265                            | Length |
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    | Prefix Length = 88 | IP Prefix (variable) = RD followed by the
|    24-bit-long prefix //
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 
|    --------------------------------------------------------------------------
| 
|    [e-mail]
| 
| 
|      From: [1]Saikat Ray (sairay)
|      Date: 2014-09-03 11:23
|      To: [2][e-mail]; [3]Hannes Gredler
|      CC: [4]'idr wg'; [5]Susan Hares; [6]'John G. Scudder'
|      Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and
|      draft-ietf-idr-ls-distribut-impl
|      Sorry, I do not understand your point. In BGP-LS as well, the RD field
|      is right after the route-type and the length:
|        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         |            NLRI Type          |     Total NLRI Length         |
|         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         |                                                               |
|         +                       Route Distinguisher                     +
|         |                                                               |
|         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         |                                                               |
|         //                  Link-State NLRI (variable)                 //
|         |                                                               |
|         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      From: "[7][e-mail]" <[8][e-mail]>
|      Date: Tuesday, September 2, 2014 at 7:39 PM
|      To: sairay <[9][e-mail]>, Hannes Gredler
|      <[10][e-mail]>
|      Cc: "[11][e-mail]" <[12][e-mail]>, "[13][e-mail]"
|      <[14][e-mail]>, 'John Scudder' <[15][e-mail]>
|      Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and
|      draft-ietf-idr-ls-distribut-impl
|      But the postion of RD in RFC6514 is AFTER type field and length field,
|      not before those fields. Taken Intra-AS I-PMSI A-D Route as an example,
|      +-----------------------------------+
|      | Route Type (1 octet) = 1  |
|      +-----------------------------------+
|      | Length (1 octet) |
|      +-----------------------------------+
|      | RD (8 octets) |
|      +-----------------------------------+
|      | Originating Router’s IP Addr |
|      +-----------------------------------+
| 
|    --------------------------------------------------------------------------
| 
|      [16][e-mail]
| 
| 
|        From: [17]Saikat Ray (sairay)
|        Date: 2014-09-03 10:24
|        To: [18][e-mail]; [19]Hannes Gredler
|        CC: [20]'idr wg'; [21]Susan Hares; [22]'John G. Scudder'
|        Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and
|        draft-ietf-idr-ls-distribut-impl
|        From: "[23][e-mail]"
|        <[24][e-mail]>
|        Date: Tuesday, September 2, 2014 at 7:18 PM
|        To: sairay <[25][e-mail]>, Hannes Gredler
|        <[26][e-mail]>
|        Cc: "[27][e-mail]" <[28][e-mail]>, "[29][e-mail]"
|        <[30][e-mail]>, 'John Scudder' <[31][e-mail]>
|        Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and
|        draft-ietf-idr-ls-distribut-impl
|        Placing the type field before the length field is fine for me.
|        The encoding format for RD in this draft is not consistent with
|        RFC4364. This is the question. RFC6514 says "The Route Distinguisher
|        (RD) is encoded as described in [RFC4364]", please see section 4 of
|        RFC6514.
|        [SR] That statement in RFC6514 refers to how the 8 bytes of the
|        route-distinguisher field are encoded (different RD types, values,
|        etc.), not to the position of RD field in the NLRI.
|        I agree with you for the advantage to put the RD before other fields.
|        I raise this quesiton just for clarification.
| 
|    --------------------------------------------------------------------------
| 
|        [32][e-mail]
| 
| 
|          From: [33]Saikat Ray (sairay)
|          Date: 2014-09-03 05:03
|          To: [34][e-mail]; [35]Hannes Gredler
|          CC: [36]'idr wg'; [37]Susan Hares; [38]'John G. Scudder'
|          Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and
|          draft-ietf-idr-ls-distribut-impl
|          Hi Zhenqiang:
|          For the NLRIs that uses a "type" field, such as MVPN (see RFC6514),
|          the convention is to encode the type field before the length field.
|          This allows for greatest flexibility for future extensions. In
|          BGP-LS, we have used the same convention.
|          Other than that, the RD is for the entire bgp-ls object (be it a
|          Node, Link or Prefix). So placing the RD field before other fields
|          is logically accurate.
|          Thanks.
|          From: "[39][e-mail]"
|          <[40][e-mail]>
|          Date: Tuesday, September 2, 2014 at 4:21 AM
|          To: Hannes Gredler <[41][e-mail]>
|          Cc: "[42][e-mail]" <[43][e-mail]>, "[44][e-mail]"
|          <[45][e-mail]>, 'John Scudder' <[46][e-mail]>
|          Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and
|          draft-ietf-idr-ls-distribut-impl
|          Hi Hannes,
|          One example to explain the differences. One VPN route with prefix
|          length 24 is carried in the NRLI.
|          The format this draft specified is as follows.
|          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           |            NLRI Type = 3         |     Total NLRI Length
|          |
|          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           |                                                               |
|          +                       Route Distinguisher                     +
|           |                                                               |
|          +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          | Protocol-ID |
|          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          | Identifier |
|          | (64 bits) |
|          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          // Local Node Descriptor (variable) //
|          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          | Type = 265                            | Length |
|          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          | Prefix Length = 24 | IP Prefix (variable) //
|          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          The format RFC4363 specified is as follows.
|          +---------------------------------------------------------+
|          | Address Family Identifier (2 octets) |
|          +---------------------------------------------------------+
|          | Subsequent Address Family Identifier (1 octet) |
|          +---------------------------------------------------------+
|          | Length of Next Hop Network Address (1 octet) |
|          +---------------------------------------------------------+
|          | Network Address of Next Hop (variable) |
|          +---------------------------------------------------------+
|          | Reserved (1 octet) |
|          +---------------------------------------------------------+
|          | Prefix Length = 88 |  IP Prefix (variable) = RD followed by IP
|          prefix //
|          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
| 
|    --------------------------------------------------------------------------
| 
|          [47][e-mail]
| 
| 
|            From: [48]Hannes Gredler
|            Date: 2014-09-02 16:35
|            To: [49][e-mail]
|            CC: [50]Uma Chunduri; [51]'idr wg'; [52]'John G. Scudder';
|            [53]Susan Hares
|            Subject: Re: RE: [Idr] WG LC for draft-ietf-idr-ls-distribution
|            and draft-ietf-idr-ls-distribut-impl
|            hi zhenqiang,
| 
|            On Tue, Sep 02, 2014 at 04:12:58PM +0800,
|            [54][e-mail] wrote:
|            |    Two types of link state NLRIs are defined in section 3.2 of
|            this
|            |    draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 / SAFI 128
|            for VPN.
| 
|            correct;
| 
|            |    My question is about AFI 16388 / SAFI 128 NLRI. From the
|            figure in page 9
|            |    of draft version 5, we can see that RD is put before link
|            state NLRI.
| 
| 
|            from
|            [55]http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-05#section-3.2
| 
|            this is the NLRI format for AFI 16388 / SAFI 71 (unicast)
| 
|                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
| 
|            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |            NLRI Type          |     Total NLRI Length
|            |
| 
|            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |
|            |
|               //                  Link-State NLRI (variable)
|            //
|               |
|            |
| 
|            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 
|            and this is the NLRI format for AFI 16388 / SAFI 128 (VPN-unicast)
| 
|                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
| 
|            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |            NLRI Type          |     Total NLRI Length
|            |
| 
|            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |
|            |
|               +                       Route Distinguisher
|            +
|               |
|            |
| 
|            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |
|            |
|               //                  Link-State NLRI (variable)
|            //
|               |
|            |
| 
|            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 
| 
| 
|            |    The link state NLRI field in this figure contains the IP
|            prefix. As RFC4364
|            |    specifies, the VPN routes should be carried in the NLRI
|            prepending with
|            |    RD.
| 
|            that is what we do - i fail to see the offending part with respect
|            to RFC4364.
| 
|            /hannes
| 
|            |
|            |      From: [1]Hannes Gredler
|            |      Date: 2014-09-02 15:29
|            |      To: [2][56][e-mail]; [3]Uma Chunduri
|            |      CC: [4]'idr wg'; [5]'John G. Scudder'; [6]Susan Hares
|            |      Subject: RE: Re: [Idr] WG LC for
|            draft-ietf-idr-ls-distribution and
|            |      draft-ietf-idr-ls-distribut-impl
|            |
|            |      hi zhenqiang,
|            |
|            |      The Route-distinguisher's purpose is to add 64-bits of
|            disambiguating
|            |      entropy to the NLRI, such
|            |
|            |      that the route-reflectors do not "swallow" that path as
|            part of the
|            |      best-path election
|            |
|            |      procedure. The link-state NLRI (encapsulated in MP_REACH/
|            MP UNREACH PA)
|            |
|            |      is a RD-less version of the vpn-link-state NLRI.
|            |
|            |      In a certain way these correspond to RFC3107 / RFC4364 NLRI
|            formats.
|            |
|            |      The former is a RD-less version of the latter.
|            |
|            |      On your question "Why do't you put RD in IP Reachability
|            Information,
|            |      just prepending RD with IP prefix as RFC4364 specifies." -
|            This is
|            |      actually what we *are* doing - we put the RD before the
|            link-state NLRI
|            |      inside the MP_REACH/MP_UNREACH Attribute.
|            |
|            |      HTH,
|            |
|            |      /hannes
|            |
|            |
|            --------------------------------------------------------------------------
|            |
|            |      From: [57][e-mail]
|            <[58][e-mail]>
|            |      Sent: Tuesday, September 02, 2014 8:44
|            |      To: Hannes Gredler; Uma Chunduri
|            |      Cc: 'idr wg'; 'John G. Scudder'; Susan Hares
|            |      Subject: Re: Re: [Idr] WG LC for
|            draft-ietf-idr-ls-distribution and
|            |      draft-ietf-idr-ls-distribut-impl
|            |
|            |      One question about the VPN Link-State NLRI in section 3.2.
|            Why do you
|            |      put the RD before link state NRLI? Why do't you put RD in
|            IP
|            |      Reachability Information, just preprending RD with IP
|            prefix as RFC4364
|            |      specifies.
|            |
|            |
|            --------------------------------------------------------------------------
|            |
|            |      [59][e-mail]
|            |
|            |
|            |        From: [7]Hannes Gredler
|            |        Date: 2014-09-02 02:05
|            |        To: [8]Uma Chunduri
|            |        CC: [9][60][e-mail]; [10]'John G. Scudder'; [11]Susan
|            Hares
|            |        Subject: Re: [Idr] WG LC for
|            draft-ietf-idr-ls-distribution and
|            |        draft-ietf-idr-ls-distribut-impl
|            |        hi uma,
|            |
|            |        see comments/responses inline:
|            |
|            |        On Wed, Aug 27, 2014 at 11:07:01AM +0000, Uma Chunduri
|            wrote:
|            |        |    Support.
|            |        |
|            |        |    I see, hierarchy is WELL  defined when multiple
|            instances of IGP
|            |        with
|            |        |    multiple AFs are running. Good work.
|            |        |
|            |        |
|            |        |
|            |        |    Have following Qs:
|            |        |
|            |        |    1.       Any discussion of the delay introduced by
|            BGP (packing,
|            |        update
|            |        |    generation, processing etc..) to transport the LS
|            information
|            |        |
|            |        |    especially, when LSDB is changing faster perhaps
|            with large
|            |        number of
|            |        |    nodes/links inside an AS and with multiple ASes) to
|            the
|            |        controller will be
|            |        |    useful.
|            |
|            |        this is highly implementation dependent; -
|            |        some vendors do the packaging of BGP updates entirely
|            event-driven
|            |        and others pack things up and have a worst case delay
|            between
|            |        the trigger event and the BGP update. the protocol
|            |        itself does not prohibit/limit the propagation speed.
|            |        (in fact it can be shown that sometimes updates
|            |        travel faster on the (dataplane forwarded) iBGP mesh,
|            |        rather than propgate using the hop-by-hop control-plane
|            flooding
|            |        protocol)
|            |
|            |        |                 A note on the sensitivity of this delay
|            to the
|            |        consumer
|            |        |    (applications) at the controller  can be helpful. I
|            saw very
|            |        little
|            |        |    discussion in Section 6 (6.1.5)
|            |
|            |        difficiult - its hard to have some sort of general
|            comment as things
|            |        are
|            |        highly implementation dependent.
|            |
|            |
|            |        |    2.       This document encompasses pretty much both
|            OSPF and ISIS
|            |        |    extensions done till date. How it will keep up with
|            future
|            |        extensions in
|            |        |    OSPF/ISIS.
|            |
|            |        we have set up an IANA registries for the carriers of
|            information.
|            |        it is expected by authors of "topological relevant" IGP
|            extensions
|            |        to supply also BGP-LS extensions.
|            |
|            |        |    A mechanism in place would be helpful. My suggestion
|            would be-
|            |        the
|            |        |    respective IGP documents should assess the impact
|            and define
|            |        |
|            |        |    corresponding new TLVs for BGP LS? But how this can
|            be enforced?
|            |
|            |        i have no idea - today its entirely voluntary.
|            |
|            |        |    3.       Section 4, gives glimpse what's possible
|            and the node
|            |        aggregating
|            |        |    the links obviously need to tinker the LSDB to
|            represent the same
|            |        |    correctly.
|            |        |
|            |        |    Some more details would be helpful to represent the
|            changes on
|            |        |    aggregation/de-aggregation subsequently.
|            |
|            |        this may quickly get you into the "abstracted topology
|            models"
|            |        discussion that keeps emerging  periodically. -
|            |        we did not want to stop progress on the protocol by
|            arguing
|            |        "whats the right abstraction model" and have agreed
|            |        on the minimalistic nature of the section as-is.
|            |
|            |
|            |        |    4.       Section 6.2 has empty sub-sections and
|            TBDs.
|            |
|            |        right ... so suggest to remove section 6.2 altogether.
|            |
|            |        |    5.       It's good to see Implementation report shed
|            light on
|            |        performance
|            |        |    seen with multiple ASes.
|            |        |
|            |        |    6.       It's good to see if any application of
|            policy on LSDB is
|            |        done
|            |        |    (one of the primary drivers of the specification).
|            |
|            |
|            |        thanks,
|            |
|            |
|            |        /hannes
|            |
|            |        |
|            |        |    From: Idr [[61]mailto:[e-mail]] On
|            Behalf Of Susan Hares
|            |        |    Sent: Tuesday, August 26, 2014 11:37 AM
|            |        |    To: [62][e-mail]
|            |        |    Cc: 'John G. Scudder'; [63][e-mail]
|            |        |    Subject: [Idr] WG LC for
|            draft-ietf-idr-ls-distribution and
|            |        |    draft-ietf-idr-ls-distribut-impl
|            |        |
|            |        |
|            |        |
|            |        |    This is a WG LC for
|            |        |
|            |        |
|            |        |
|            |        |
|            |
|            [1][64]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/
|            |        |
|            |        |
|            |
|            [2][65]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/
|            |        |
|            |        |
|            |        |
|            |        |    Please respond with comments and "support or no
|            support."  This
|            |        WG LC also
|            |        |    includes a request for the authors to provide IPR on
|            the subject.
|            |        |
|            |        |
|            |        |
|            |        |    Please note: due to the European vacations in
|            August, we are
|            |        bundling
|            |        |    these three reviews into the next two weeks (these
|            two drafts and
|            |        |    draft-ietf-as-migration).   The chairs would like
|            feedback (list
|            |        or
|            |        |    private email) whether the three WG LC s impact
|            anyone's ability
|            |        to review
|            |        |    these drafts carefully.
|            |        |
|            |        |
|            |        |
|            |        |    Thank you,
|            |        |
|            |        |
|            |        |
|            |        |    Sue Hares and John Scudder