Subject: Re: [Idr] AD Review: draft-ietf-idr-ls-distribution

From: Alia Atlas <[email-masked]>
Date: Tue, 29 Sep 2015 10:35:24 -0400

It has been about 6 months since I did my review of
draft-ietf-idr-ls-distribution-10
and I don't see the comments addressed in draft-ietf-ls-distribution-11.

Of course, Alvaro is now the responsible AD for IDR - and may have his own
comments as well.

It's very sad when a draft is held up for this long due to editors' not
responding.
None of my comments were blocking issues, which is why I was willing to run
the IETF Last Call in parallel, but I did and do expect a response.

Regards,
Alia

On Wed, Mar 18, 2015 at 12:43 PM, Alia Atlas <[email-masked]> wrote:

> As is customary upon receiving a publication request, I have done my AD
> review of draft-ietf-idr-ls-distribution.  First, thanks for the hard work
> on this very useful and non-trivial specification.  Second, I have found a
> number of clarifications and issues that I would like to see resolved in
> the draft.
>
> I will start an IETF Last Call so that you can get additional comments in
> parallel.  Because of the upcoming IETF, I expect this to run longer -
> ending April 8.
>
>
> 1) In Sec 3.2, 3rd paragraph last sentence, it says:
> "This is done as specified in [RFC4760], by using capability code 1
> (multi-protocol BGP), with an AFI 16388 / SAFI 71 and AFI 16388 / SAFI
> TBD for the VPN flavor."   Could you please turn this into non-colloquial
> language with clear requirements language?  Can one support "the VPN
> flavor" but not the regular?
>
> 2) On p. 9, the Route Distinguisher is introduced and its length is
> included - but no reference is given nor length specified.  Could you
> please provide both?
>
> 3) In Sec 3.2.1, second paragraph, it says "We use Autonomous System (AS)
> Number and BGP-LS Identifier (Paragraph 2) in order to disambiguate the
> Router-IDs, as described in Section 3.2.1.1."
> I suspect that "Paragraph 2" is intended to refer to the last paragraph on
> p. 11 - but that isn't a clear way to reference it; also the Identifier is
> not referred to as a "BGP-LS Identifier" but merely an Identifier.  Also,
> instead of "we" perhaps "BGP-LS".
>
> 4) In Sec 3.2.2, I see that link descriptors are actually only a
> unidirectional representation.  Could you please mention this when the link
> NLRI is introduced?
>
> 5) In the NLRI format, I see a 64 bit identifier. From the discussion
> (last paragraph in p. 11), it looks like this 64-bit identifier is intended
> to be the 5-bit "Routing Universe Identifier" which is supposed to indicate
> the protocol plus routing instance???
>
> 5) In Sec 3.2.1.4: I see the OSPF Area-ID listed.  How are IS-IS levels
> handled?  I see the Node Attribute TLV (1027) but this seems to require
> that a link would have to have its remote and local nodes looked up to find
> the associated IS-IS Area Identifier.  What would be actually really useful
> is to describe, in the introduction, the different handling for IS-IS and
> OSPF in the encapsulations and why they differ.
>
> 6) In Sec 3.2.2  3rd from last paragraph:  Can both IPv4 AND IPv6
> addresses both be included in the link descriptor?  Presumably the same
> logic that prevents the link local/remote identifiers from being included
> would apply?  Also, why are the neighbor addresses included for the Link
> Descriptor when the remote node's descriptor should already be in the
> Remote Node Descriptor?
>
> 7) In Sec 3.2.3.1:  It says "The OSPF Route Type field values are defined
> in the OSPF protocol, and can be one of the following".  Could you please
> add a reference to which version of OSPF and what field you are
> describing?  I suspect it is the LSA types and they are different values
> between OSPFv2 and OSPFv3.  This section could benefit from some clarity.
>
> 8) In Sec 3.3.1.2:  Please add a reference and describe what an "Area
> Identifier (variable)" is.
>
> 9) Sec 3.3.1.5:  I like the idea of this - but an example or two in terms
> of encoding/parsing would be useful.  You have a couple pointers - but it
> could use another level of explanation.
>
> 10) Sec 3.3.2.2:  I am not clear what the rationale for deciding what
> protocols to include here is.  For instance, is mLDP considered a different
> protocol or a subset of LDP?  I would like to see a short paragraph
> discussing how this information might be used or what criteria would be
> applied to decide if another protocol should be added.  8 bits is a pretty
> small space...
>
> 11) Sec 3.3.2.3:  " If a source protocol (e.g. IS-IS) does not support a
> Metric width of 32 bits then the high order octet MUST be set to zero."
> Surely you mean that if the source protocol supports a metric width shorter
> than 32 bits, then the metric is placed in the bottom of the word and the
> high order bits from the supported metric width to 32 MUST be set to 0.  As
> written, it assumes that any source protocol that doesn't support 32 bits
> of metric must support exactly 24 bits.
>
> 12) Sec 3.3.2.5:  Please correct the sentence that claims "Note that
> there is no SRLG TLV in OSPF-TE".  A simple browsing in the IANA registry  (
> http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xhtml#subtlv2
> ) clearly shows it defined:
> 16Shared Risk Link Group (variable)[RFC4203
> <http://www.iana.org/go/rfc4203>]
> 13) Sec 3.3.3.1:  How large are the bit fields that are mashed together
> from IS-IS and OSPF to form the IGP Flags TLV?  Can you please add some
> guidance on when new flags should be allocated?
>
> 14) Sec 3.3.3.2 and Sec 3.3.3.3:  Please add a reference for OSPF TAGs.  draft-acee-ospf-admin-tags-01
> seems to be the corresponding one.  I think that the reference can be
> Informational.
>
> 15) Sec 3.3.3.4:  The reference to RFC5305 is, I presume to Section 4.
> That would be useful to clarify since it isn't easy to find.  Similarly,
> where does the information come from in OSPF?  Could you please add a
> reference?
>
> 16) Sec 3.5:  Can you please provide more guidance here around what
> Protocol-ID to use for inter-AS links - particularly if they are not in the
> IGP?  Are there any issues around the Protocol-ID implying the format for
> data that an inter-AS link might have?
>
> 17) Sec 5 IANA Considerations:  There are several fields (i.e. MPLS
> protocols, IGP Flags, etc) that are not included in the IANA
> Considerations.  The authors and document shepherd should go through and
> describe how each field that is not managed by IANA would have additional
> values added - or whether that isn't expected and why.
>
> 18) Sec 6.2.1:  I assume that by "does not mandate", the authors mean
> "we're not doing it now"?  It's clearly absurd and ludicrous to think that
> BGP-LS wouldn't need some type of extensions - whether that is
> topology-related YANG models or something else.  Please figure out what you
> want to say other than "someone else's problem" and put it in here.
>
> Thanks again for the hard work so far,
> Alia
>
>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 29 Sep 2015 11:18:13 -0400

Alia: 

Thank you for running the IETF LC in parallel.  I was also surprised that the authors took so long to clean up all the responses.  Hannes was actively cleaning up the errors until the end of August, but due to vacation/leaving Juniper has not responded. 

Adrian Farrel has agreed today to pick up the token for the authors and complete the edits on this draft.  Alvaro had a few extra comments on the draft which need to be completed.   Adrian is copied on this message so that his resulting draft will also pick up these comments. 

Sue Hares 

From: Idr [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Tuesday, September 29, 2015 10:35 AM
To: [email-masked]; idr@ietf. org
Subject: Re: [Idr] AD Review: draft-ietf-idr-ls-distribution

It has been about 6 months since I did my review of draft-ietf-idr-ls-distribution-10

comments as well.

It's very sad when a draft is held up for this long due to editors' not responding.

Regards,

Alia

As is customary upon receiving a publication request, I have done my AD review of draft-ietf-idr-ls-distribution.  First, thanks for the hard work on this very useful and non-trivial specification.  Second, I have found a number of clarifications and issues that I would like to see resolved in the draft.

I will start an IETF Last Call so that you can get additional comments in parallel.  Because of the upcoming IETF, I expect this to run longer - ending April 8.  

"This is done as specified in [RFC4760], by using capability code 1 (multi-protocol BGP), with an AFI 16388 / SAFI 71 and AFI 16388 / SAFI TBD for the VPN flavor."   Could you please turn this into non-colloquial language with clear requirements language?  Can one support "the VPN flavor" but not the regular?  

2) On p. 9, the Route Distinguisher is introduced and its length is included - but no reference is given nor length specified.  Could you please provide both?

3) In Sec 3.2.1, second paragraph, it says "We use Autonomous System (AS) Number and BGP-LS Identifier (Paragraph 2) in order to disambiguate the Router-IDs, as described in Section 3.2.1.1."

I suspect that "Paragraph 2" is intended to refer to the last paragraph on p. 11 - but that isn't a clear way to reference it; also the Identifier is not referred to as a "BGP-LS Identifier" but merely an Identifier.  Also, instead of "we" perhaps "BGP-LS".

4) In Sec 3.2.2, I see that link descriptors are actually only a unidirectional representation.  Could you please mention this when the link NLRI is introduced?

5) In the NLRI format, I see a 64 bit identifier. From the discussion (last paragraph in p. 11), it looks like this 64-bit identifier is intended to be the 5-bit "Routing Universe Identifier" which is supposed to indicate the protocol plus routing instance???

5) In Sec 3.2.1.4: I see the OSPF Area-ID listed.  How are IS-IS levels handled?  I see the Node Attribute TLV (1027) but this seems to require that a link would have to have its remote and local nodes looked up to find the associated IS-IS Area Identifier.  What would be actually really useful is to describe, in the introduction, the different handling for IS-IS and OSPF in the encapsulations and why they differ.  

6) In Sec 3.2.2  3rd from last paragraph:  Can both IPv4 AND IPv6 addresses both be included in the link descriptor?  Presumably the same logic that prevents the link local/remote identifiers from being included would apply?  Also, why are the neighbor addresses included for the Link Descriptor when the remote node's descriptor should already be in the Remote Node Descriptor?  

7) In Sec 3.2.3.1:  It says "The OSPF Route Type field values are defined in the OSPF protocol, and can be one of the following".  Could you please add a reference to which version of OSPF and what field you are describing?  I suspect it is the LSA types and they are different values between OSPFv2 and OSPFv3.  This section could benefit from some clarity.

8) In Sec 3.3.1.2:  Please add a reference and describe what an "Area Identifier (variable)" is.  

9) Sec 3.3.1.5:  I like the idea of this - but an example or two in terms of encoding/parsing would be useful.  You have a couple pointers - but it could use another level of explanation.

10) Sec 3.3.2.2:  I am not clear what the rationale for deciding what protocols to include here is.  For instance, is mLDP considered a different protocol or a subset of LDP?  I would like to see a short paragraph discussing how this information might be used or what criteria would be applied to decide if another protocol should be added.  8 bits is a pretty small space...

11) Sec 3.3.2.3:  " If a source protocol (e.g. IS-IS) does not support a Metric width of 32 bits then the high order octet MUST be set to zero."   Surely you mean that if the source protocol supports a metric width shorter than 32 bits, then the metric is placed in the bottom of the word and the high order bits from the supported metric width to 32 MUST be set to 0.  As written, it assumes that any source protocol that doesn't support 32 bits of metric must support exactly 24 bits.

12) Sec 3.3.2.5:  Please correct the sentence that claims "Note that there is no SRLG TLV in OSPF-TE".  A simple browsing in the IANA registry  (http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xhtml#subtlv2 ) clearly shows it defined:

16

Shared Risk Link Group (variable)

[RFC4203 <http://www.iana.org/go/rfc4203> ]

13) Sec 3.3.3.1:  How large are the bit fields that are mashed together from IS-IS and OSPF to form the IGP Flags TLV?  Can you please add some guidance on when new flags should be allocated?

14) Sec 3.3.3.2 and Sec 3.3.3.3:  Please add a reference for OSPF TAGs.  draft-acee-ospf-admin-tags-01 seems to be the corresponding one.  I think that the reference can be Informational.

15) Sec 3.3.3.4:  The reference to RFC5305 is, I presume to Section 4.  That would be useful to clarify since it isn't easy to find.  Similarly, where does the information come from in OSPF?  Could you please add a reference?

16) Sec 3.5:  Can you please provide more guidance here around what Protocol-ID to use for inter-AS links - particularly if they are not in the IGP?  Are there any issues around the Protocol-ID implying the format for data that an inter-AS link might have? 

17) Sec 5 IANA Considerations:  There are several fields (i.e. MPLS protocols, IGP Flags, etc) that are not included in the IANA Considerations.  The authors and document shepherd should go through and describe how each field that is not managed by IANA would have additional values added - or whether that isn't expected and why.

18) Sec 6.2.1:  I assume that by "does not mandate", the authors mean "we're not doing it now"?  It's clearly absurd and ludicrous to think that BGP-LS wouldn't need some type of extensions - whether that is topology-related YANG models or something else.  Please figure out what you want to say other than "someone else's problem" and put it in here.

Alia

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 29 Sep 2015 17:48:59 +0100

Hi Alia,
 
Since the thing that triggered you to send this mail was me investigating the
status and promising to pick up the comments, I think you can rely on the emails
getting answered soon.
 
Adrian
 
  _____  

From: Alia Atlas
Sent: 29 September 2015 15:35:24 (UTC) Dublin, Edinburgh, Lisbon, London
To: [email-masked]; idr@ietf. org
Subject: Re: AD Review: draft-ietf-idr-ls-distribution
It has been about 6 months since I did my review of
draft-ietf-idr-ls-distribution-10 
and I don't see the comments addressed in draft-ietf-ls-distribution-11.

 
Regards,
Alia
 
On Wed, Mar 18, 2015 at 12:43 PM, Alia Atlas <[email-masked]> wrote:
As is customary upon receiving a publication request, I have done my AD review
of draft-ietf-idr-ls-distribution.  First, thanks for the hard work on this very
useful and non-trivial specification.  Second, I have found a number of
clarifications and issues that I would like to see resolved in the draft.
 
I will start an IETF Last Call so that you can get additional comments in
parallel.  Because of the upcoming IETF, I expect this to run longer - ending
April 8.  

1) In Sec 3.2, 3rd paragraph last sentence, it says:
"This is done as specified in [RFC4760], by using capability code 1
(multi-protocol BGP), with an AFI 16388 / SAFI 71 and AFI 16388 / SAFI TBD for
the VPN flavor."   Could you please turn this into non-colloquial language with
clear requirements language?  Can one support "the VPN flavor" but not the
regular?  
 
2) On p. 9, the Route Distinguisher is introduced and its length is included -
but no reference is given nor length specified.  Could you please provide both?
 
3) In Sec 3.2.1, second paragraph, it says "We use Autonomous System (AS) Number
and BGP-LS Identifier (Paragraph 2) in order to disambiguate the Router-IDs, as
described in Section 3.2.1.1."
I suspect that "Paragraph 2" is intended to refer to the last paragraph on p. 11
- but that isn't a clear way to reference it; also the Identifier is not
referred to as a "BGP-LS Identifier" but merely an Identifier.  Also, instead of
"we" perhaps "BGP-LS".
 
4) In Sec 3.2.2, I see that link descriptors are actually only a unidirectional
representation.  Could you please mention this when the link NLRI is introduced?
 
5) In the NLRI format, I see a 64 bit identifier. From the discussion (last
paragraph in p. 11), it looks like this 64-bit identifier is intended to be the
5-bit "Routing Universe Identifier" which is supposed to indicate the protocol
plus routing instance???
 
5) In Sec 3.2.1.4: I see the OSPF Area-ID listed.  How are IS-IS levels handled?
I see the Node Attribute TLV (1027) but this seems to require that a link would
have to have its remote and local nodes looked up to find the associated IS-IS
Area Identifier.  What would be actually really useful is to describe, in the
introduction, the different handling for IS-IS and OSPF in the encapsulations
and why they differ.  
 
6) In Sec 3.2.2  3rd from last paragraph:  Can both IPv4 AND IPv6 addresses both
be included in the link descriptor?  Presumably the same logic that prevents the
link local/remote identifiers from being included would apply?  Also, why are
the neighbor addresses included for the Link Descriptor when the remote node's
descriptor should already be in the Remote Node Descriptor?  
 
7) In Sec 3.2.3.1:  It says "The OSPF Route Type field values are defined in the
OSPF protocol, and can be one of the following".  Could you please add a
reference to which version of OSPF and what field you are describing?  I suspect
it is the LSA types and they are different values between OSPFv2 and OSPFv3.
This section could benefit from some clarity.
 
8) In Sec 3.3.1.2:  Please add a reference and describe what an "Area Identifier
(variable)" is.  
9) Sec 3.3.1.5:  I like the idea of this - but an example or two in terms of
encoding/parsing would be useful.  You have a couple pointers - but it could use
another level of explanation.
 
10) Sec 3.3.2.2:  I am not clear what the rationale for deciding what protocols
to include here is.  For instance, is mLDP considered a different protocol or a
subset of LDP?  I would like to see a short paragraph discussing how this
information might be used or what criteria would be applied to decide if another
protocol should be added.  8 bits is a pretty small space...
 
11) Sec 3.3.2.3:  " If a source protocol (e.g. IS-IS) does not support a Metric
width of 32 bits then the high order octet MUST be set to zero."   Surely you
mean that if the source protocol supports a metric width shorter than 32 bits,
then the metric is placed in the bottom of the word and the high order bits from
the supported metric width to 32 MUST be set to 0.  As written, it assumes that
any source protocol that doesn't support 32 bits of metric must support exactly
24 bits.
 
12) Sec 3.3.2.5:  Please correct the sentence that claims "Note that there is no
SRLG TLV in OSPF-TE".  A simple browsing in the IANA registry
(http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xht
ml#subtlv2 ) clearly shows it defined:

16
Shared Risk Link Group (variable)
[RFC4203 <http://www.iana.org/go/rfc4203> ]
13) Sec 3.3.3.1:  How large are the bit fields that are mashed together from
IS-IS and OSPF to form the IGP Flags TLV?  Can you please add some guidance on
when new flags should be allocated?
 
14) Sec 3.3.3.2 and Sec 3.3.3.3:  Please add a reference for OSPF TAGs.
draft-acee-ospf-admin-tags-01 seems to be the corresponding one.  I think that
the reference can be Informational.
 
15) Sec 3.3.3.4:  The reference to RFC5305 is, I presume to Section 4.  That
would be useful to clarify since it isn't easy to find.  Similarly, where does
the information come from in OSPF?  Could you please add a reference?
 
16) Sec 3.5:  Can you please provide more guidance here around what Protocol-ID
to use for inter-AS links - particularly if they are not in the IGP?  Are there
any issues around the Protocol-ID implying the format for data that an inter-AS
link might have? 
 
17) Sec 5 IANA Considerations:  There are several fields (i.e. MPLS protocols,
IGP Flags, etc) that are not included in the IANA Considerations.  The authors
and document shepherd should go through and describe how each field that is not
managed by IANA would have additional values added - or whether that isn't
expected and why.
 
18) Sec 6.2.1:  I assume that by "does not mandate", the authors mean "we're not
doing it now"?  It's clearly absurd and ludicrous to think that BGP-LS wouldn't
need some type of extensions - whether that is topology-related YANG models or
something else.  Please figure out what you want to say other than "someone
else's problem" and put it in here.

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Wed, 30 Sep 2015 15:31:36 +0000

Thanks, Adrian. Much appreciated.

/Jan

From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Reply-To: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 29, 2015 at 9:48 AM
To: Alia Atlas <[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]>>
Subject: RE: AD Review: draft-ietf-idr-ls-distribution

Hi Alia,

Since the thing that triggered you to send this mail was me investigating the status and promising to pick up the comments, I think you can rely on the emails getting answered soon.

Adrian

________________________________
From: Alia Atlas
Sent: 29 September 2015 15:35:24 (UTC) Dublin, Edinburgh, Lisbon, London
To: [email-masked]<mailto:[email-masked]>; idr@ietf. org
Subject: Re: AD Review: draft-ietf-idr-ls-distribution
It has been about 6 months since I did my review of draft-ietf-idr-ls-distribution-10
and I don't see the comments addressed in draft-ietf-ls-distribution-11.

Regards,
Alia

On Wed, Mar 18, 2015 at 12:43 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
As is customary upon receiving a publication request, I have done my AD review of draft-ietf-idr-ls-distribution.  First, thanks for the hard work on this very useful and non-trivial specification.  Second, I have found a number of clarifications and issues that I would like to see resolved in the draft.

5) In Sec 3.2.1.4<http://3.2.1.4>: I see the OSPF Area-ID listed.  How are IS-IS levels handled?  I see the Node Attribute TLV (1027) but this seems to require that a link would have to have its remote and local nodes looked up to find the associated IS-IS Area Identifier.  What would be actually really useful is to describe, in the introduction, the different handling for IS-IS and OSPF in the encapsulations and why they differ.

7) In Sec 3.2.3.1<http://3.2.3.1>:  It says "The OSPF Route Type field values are defined in the OSPF protocol, and can be one of the following".  Could you please add a reference to which version of OSPF and what field you are describing?  I suspect it is the LSA types and they are different values between OSPFv2 and OSPFv3.  This section could benefit from some clarity.

8) In Sec 3.3.1.2<http://3.3.1.2>:  Please add a reference and describe what an "Area Identifier (variable)" is.
9) Sec 3.3.1.5<http://3.3.1.5>:  I like the idea of this - but an example or two in terms of encoding/parsing would be useful.  You have a couple pointers - but it could use another level of explanation.

10) Sec 3.3.2.2<http://3.3.2.2>:  I am not clear what the rationale for deciding what protocols to include here is.  For instance, is mLDP considered a different protocol or a subset of LDP?  I would like to see a short paragraph discussing how this information might be used or what criteria would be applied to decide if another protocol should be added.  8 bits is a pretty small space...

11) Sec 3.3.2.3<http://3.3.2.3>:  " If a source protocol (e.g. IS-IS) does not support a Metric width of 32 bits then the high order octet MUST be set to zero."   Surely you mean that if the source protocol supports a metric width shorter than 32 bits, then the metric is placed in the bottom of the word and the high order bits from the supported metric width to 32 MUST be set to 0.  As written, it assumes that any source protocol that doesn't support 32 bits of metric must support exactly 24 bits.

12) Sec 3.3.2.5<http://3.3.2.5>:  Please correct the sentence that claims "Note that there is no SRLG TLV in OSPF-TE".  A simple browsing in the IANA registry  (http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xhtml#subtlv2 ) clearly shows it defined:
16

[RFC4203<http://www.iana.org/go/rfc4203>]

13) Sec 3.3.3.1<http://3.3.3.1>:  How large are the bit fields that are mashed together from IS-IS and OSPF to form the IGP Flags TLV?  Can you please add some guidance on when new flags should be allocated?

14) Sec 3.3.3.2 and Sec 3.3.3.3<http://3.3.3.3>:  Please add a reference for OSPF TAGs.  draft-acee-ospf-admin-tags-01 seems to be the corresponding one.  I think that the reference can be Informational.

15) Sec 3.3.3.4<http://3.3.3.4>:  The reference to RFC5305 is, I presume to Section 4.  That would be useful to clarify since it isn't easy to find.  Similarly, where does the information come from in OSPF?  Could you please add a reference?