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

["Saikat Ray (sairay)" <[e-mail]>]

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: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, September 2, 2014 at 4:21 AM
To: Hannes Gredler <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, 'John Scudder' <[e-mail]<mailto:[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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++

________________________________
[e-mail]<mailto:[e-mail]>

From: Hannes Gredler<mailto:[e-mail]>
Date: 2014-09-02 16:35
To: [e-mail]<mailto:[e-mail]>
CC: Uma Chunduri<mailto:[e-mail]>; 'idr wg'<mailto:[e-mail]>; 'John G. Scudder'<mailto:[e-mail]>; Susan Hares<mailto:[e-mail]>
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, [e-mail]<mailto:[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 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][e-mail]<mailto:[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: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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.
|
|    --------------------------------------------------------------------------
|
|      [e-mail]<mailto:[e-mail]>
|
|
|        From: [7]Hannes Gredler
|        Date: 2014-09-02 02:05
|        To: [8]Uma Chunduri
|        CC: [9][e-mail]<mailto:[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 [mailto:[e-mail]] On Behalf Of Susan Hares
|        |    Sent: Tuesday, August 26, 2014 11:37 AM
|        |    To: [e-mail]<mailto:[e-mail]>
|        |    Cc: 'John G. Scudder'; [e-mail]<mailto:[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]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/
|        |
|        |
|        [2]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
|        |
|        | References
|        |
|        |    Visible links
|        |    1.
|        http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/
|        |    2.
|        http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/
|
|        | _______________________________________________
|        | Idr mailing list
|        | [e-mail]<mailto:[e-mail]>
|        | https://www.ietf.org/mailman/listinfo/idr
|
|        _______________________________________________
|        Idr mailing list
|        [e-mail]<mailto:[e-mail]>
|        https://www.ietf.org/mailman/listinfo/idr
|
|
| References
|
|    Visible links
|    1. mailto:[e-mail]
|    2. mailto:[e-mail]
|    3. mailto:[e-mail]
|    4. mailto:[e-mail]
|    5. mailto:[e-mail]
|    6. mailto:[e-mail]
|    7. mailto:[e-mail]
|    8. mailto:[e-mail]
|    9. mailto:[e-mail]
|   10. mailto:[e-mail]
|   11. mailto:[e-mail]