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

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

From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, September 2, 2014 at 7:18 PM
To: sairay <[e-mail]<mailto:[e-mail]>>, 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: 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.

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

From: Saikat Ray (sairay)<mailto:[e-mail]>
Date: 2014-09-03 05:03
To: [e-mail]<mailto:[e-mail]>; Hannes Gredler<mailto:[e-mail]>
CC: 'idr wg'<mailto:[e-mail]>; Susan Hares<mailto:[e-mail]>; 'John G. Scudder'<mailto:[e-mail]>
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: "[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]