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

From: <[email-masked]>
Date: Mon, 1 Sep 2014 09:30:17 +0000

Support

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, August 26, 2014 20:37
To: [email-masked]
Cc: 'John G. Scudder'; [email-masked]
Subject: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

This is a WG LC for

  http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/

  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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 1 Sep 2014 20:05:18 +0200

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:[email-masked]] On Behalf Of Susan Hares
|    Sent: Tuesday, August 26, 2014 11:37 AM
|    To: [email-masked]
|    Cc: 'John G. Scudder'; [email-masked]
|    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
| [email-masked]
| https://www.ietf.org/mailman/listinfo/idr

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 2 Sep 2014 14:44:36 +0800

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.

[email-masked]
 
From: Hannes Gredler
Date: 2014-09-02 02:05
To: Uma Chunduri
CC: [email-masked]; 'John G. Scudder'; Susan Hares
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl
hi uma,

 

 

 

 

thanks,

/hannes
 
| 

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 2 Sep 2014 07:29:28 +0000

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: [email-masked] <[email-masked]>
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

________________________________
[email-masked]

From: Hannes Gredler<mailto:[email-masked]>
Date: 2014-09-02 02:05
To: Uma Chunduri<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>; 'John G. Scudder'<mailto:[email-masked]>; Susan Hares<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl
hi uma,

thanks,

/hannes

|

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 2 Sep 2014 16:12:58 +0800

Thanks Hannes,

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.
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. 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.

From: Hannes Gredler
Date: 2014-09-02 15:29
To: [email-masked]; 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
hi zhenqiang,

HTH,

/hannes

 
From: Hannes Gredler
Date: 2014-09-02 02:05
To: Uma Chunduri

 

 

 

 

thanks,

/hannes
 
|

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 2 Sep 2014 10:35:27 +0200

hi zhenqiang,

On Tue, Sep 02, 2014 at 04:12:58PM +0800, [email-masked] 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][email-masked]; [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: [email-masked] <[email-masked]>
|      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.
| 
|    --------------------------------------------------------------------------
| 
|      [email-masked]
| 
| 
|        From: [7]Hannes Gredler
|        Date: 2014-09-02 02:05
|        To: [8]Uma Chunduri
|        CC: [9][email-masked]; [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:[email-masked]] On Behalf Of Susan Hares
|        |    Sent: Tuesday, August 26, 2014 11:37 AM
|        |    To: [email-masked]
|        |    Cc: 'John G. Scudder'; [email-masked]
|        |    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
|        | [email-masked]
|        | https://www.ietf.org/mailman/listinfo/idr
| 
|        _______________________________________________
|        Idr mailing list
|        [email-masked]
|        https://www.ietf.org/mailman/listinfo/idr
| 
| 
| References
| 
|    Visible links
|    1. mailto:[email-masked]
|    2. mailto:[email-masked]
|    3. mailto:[email-masked]
|    4. mailto:[email-masked]
|    5. mailto:[email-masked]
|    6. mailto:[email-masked]
|    7. mailto:[email-masked]
|    8. mailto:[email-masked]
|    9. mailto:[email-masked]
|   10. mailto:[email-masked]
|   11. mailto:[email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 2 Sep 2014 19:21:24 +0800

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 // 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++

From: Hannes Gredler
Date: 2014-09-02 16:35
To: [email-masked]
CC: Uma Chunduri; '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
hi zhenqiang,

correct;

 
 
    0                   1                   2                   3

    0                   1                   2                   3

 
 
/hannes
 
|

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 2 Sep 2014 12:00:01 +0000

Hi Hannes,

On #1 ==> Sure.
                  Delay could be from Update generation not on transmission.
                  Though it's one hop from RR to Controller it's hop-by-hop till that point to  the IGP on RR!
                  In general, TE Metric extensions on LS could very sensitive to this delay (link delay/bandwidth). 
                  Some generic comment on this would be useful for future readers.
         #2 ==> So it's on IGP folk who are proposing extensions - may be a note would be good here too on what kind of changes you are seeking/interested.
Thx.      
--
Uma C.

-----Original Message-----
From: Hannes Gredler [mailto:[email-masked]] 
Sent: Monday, September 01, 2014 11:05 AM
To: Uma Chunduri
Cc: Susan Hares; [email-masked]; 'John G. Scudder'
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

hi uma,

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)

difficiult - its hard to have some sort of general comment as things are highly implementation dependent.

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.

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.

thanks,

/hannes

| 
| [2]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl
| /
|    2.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 2 Sep 2014 10:53:46 -0400

On Tue, Aug 26, 2014 at 02:37:04PM -0400, Susan Hares wrote:
> 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. 

I support this draft being published.

One nit noted during review is that the various figures do not have any
labeling but are at some points in the HTML document referred to by number.
E.g. "figure 33".

-- Jeff

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Tue, 2 Sep 2014 21:03:27 +0000

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: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 2, 2014 at 4:21 AM
To: Hannes Gredler <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'John Scudder' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

Hi Hannes,

________________________________
[email-masked]<mailto:[email-masked]>

From: Hannes Gredler<mailto:[email-masked]>
Date: 2014-09-02 16:35
To: [email-masked]<mailto:[email-masked]>
CC: Uma Chunduri<mailto:[email-masked]>; 'idr wg'<mailto:[email-masked]>; 'John G. Scudder'<mailto:[email-masked]>; Susan Hares<mailto:[email-masked]>
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, [email-masked]<mailto:[email-masked]> 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;

    0                   1                   2                   3

    0                   1                   2                   3

/hannes

|
|      To: [2][email-masked]<mailto:[email-masked]>; [3]Uma Chunduri
|      From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
|      [email-masked]<mailto:[email-masked]>
|        CC: [9][email-masked]<mailto:[email-masked]>; [10]'John G. Scudder'; [11]Susan Hares
|        |    To: [email-masked]<mailto:[email-masked]>
|        |    Cc: 'John G. Scudder'; [email-masked]<mailto:[email-masked]>
|        | [email-masked]<mailto:[email-masked]>
|        [email-masked]<mailto:[email-masked]>

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 3 Sep 2014 10:18:50 +0800

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.

I agree with you for the advantage to put the RD before other fields. I raise this quesiton just for clarification.

From: Saikat Ray (sairay)
Date: 2014-09-03 05:03
To: [email-masked]; Hannes Gredler
CC: 'idr wg'; Susan Hares; 'John G. Scudder'
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl
Hi Zhenqiang:

Thanks.

From: "[email-masked]" <[email-masked]>
Date: Tuesday, September 2, 2014 at 4:21 AM
To: Hannes Gredler <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, 'John Scudder' <[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

Hi Hannes,

 
From: Hannes Gredler
Date: 2014-09-02 16:35

correct;

 
 
    0                   1                   2                   3

    0                   1                   2                   3

 
 
/hannes
 
|