Re: [Gen-art] Genart last call review of draft-ietf-ospf-mpls-elc-13

2020-05-19 Thread Peter Psenak 

Elwyn,

On 18/05/2020 23:02, elwynd wrote:

Hi.

I am not convinced by the discussion that has ensued from my review.

s3, para 3:

If the router supports ELs on all of its interfaces, it SHOULD
advertise the ELC with every local host prefix it advertises in OSPF.

- Both Acee amd I didn't immediately understand that 'every local host prefix' 
was not every
   prefix that the router might advertise.  It would be good to explain that 
this is the case.


what exactly needs to be explained? The local property of the prefix?



- As I previously stated, with a SHOULD it ought to be explained why one might 
not want to
   advertise the ELC with some subset of the local host prefixes.


SHOUDL is used not to say that one does it for subset of host prefixes, 
but rather because MUST can not be used for reasons mentioned earlier.


From the functionality perspective it is sufficient to advertise it 
with a single local prefix. We specified for "every local prefix" to 
make it simpler.




- Given that there are now two sets of prefixes, would/SHOULD/MUST ELC be 
advertised with the
   prefixes that are not local host prefixes?


no, only with local host prefixes. I can add  "MUST NOT be advertised 
with any other prefix" if that's what you are after.





s4, para 3:

The absence of ERLD-MSD advertisements indicates only that the
advertising node does not support advertisement of this capability.

Firstly, I cannot see why this statement or its absence might affect other EL 
mechanisms that
don't use OSPF to do signaling of ELC.


It does not. All we say that if it is not advertised by OSPF, it means 
the router does not support the advertisement in OSPF. Nothing else. It 
has no effect on any other mechanisms that might be used to derive these 
capabilities.




If I understand RFC 8662 correctly, if OSPF is being used to distribute ELC 
adverts and the ERLD
is not advertised by OSPF, then either the ERLD has to be supplied by other 
means or it will
effectively default to zero.

Thus, I would suggest that the paragraph above should be replaced with:

Advertisement of ERLD via OSPF using ERLD-MSD is OPTIONAL.  If a router 
does not advertise
ERLD, then the EL positioning calculations described in [RFC8662] will 
assume a vaue of zero
for the ERLD of this router unless a different value is supplied by 
alternative means.


I don't think we should be specifying anything that belongs to RFC8662 
here in this draft. What we specify in this draft is how to advertise 
something in OSPF, not how this is being used, because this information 
is not used by OSPF. The usage of this info is outside of the scope of 
this draft and if anything needs to be added in that regard it should be 
done by updating the RFC8662.


regards,
Peter





Regards,

Elwyn

Sent from Samsung tablet.



 Original message 
From: "Acee Lindem (acee)" 
Date: 14/05/2020 21:43 (GMT+00:00)
To: Alvaro Retana , "Peter Psenak (ppsenak)" 
, Elwyn Davies , gen-art@ietf.org

Cc: last-c...@ietf.org, draft-ietf-ospf-mpls-elc@ietf.org, l...@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-mpls-elc-13

Hi Alvaro, Elwyn,

*From: *Alvaro Retana 
*Date: *Thursday, May 14, 2020 at 3:46 PM
*To: *Acee Lindem , "Peter Psenak (ppsenak)" 
, Elwyn Davies , 
"gen-art@ietf.org" 
*Cc: *"last-c...@ietf.org" , 
"draft-ietf-ospf-mpls-elc@ietf.org" 
, "l...@ietf.org" 

*Subject: *Re: Genart last call review of draft-ietf-ospf-mpls-elc-13

Hi!

Yes, we cannot specify something that routers unaware of this 
specification should or shouldn’t do.


I believe that Elwyn’s point is this: *if a router supports this 
specification* then when would it not advertise the ELC?  IOW, the 
specification only obviously applies to implementations that support it 
— in that case I would think that if a router supports ELs on all of its 
interfaces then it would always advertise the ELC, right?


That’s true – but not advertising the OSPF capability could imply that 
either ELC MSD or advertisement of the OSPF capability is not supported. 
Although I might not have worded it as such, that was clear to me from 
the text. Feel free to recommend alternate text if you feel it is 
necessary.


Thanks,

Acee

Thanks!

Alvaro.

On May 11, 2020 at 3:18:34 PM, Acee Lindem (acee) (a...@cisco.com 
) wrote:


Note that the optionality of ERLD-MSD advertisements appears on
reflection to be a more serious issue than just an editorial nit.

So what would you suggest? There are existing implementations that
support multipath forwarding entropy using MPLS entropy labels but
do not signal that capability in OSPF. We can't have a document that
retroactively mandates that they signal it. This wouldn't be
backward compatible. How can you possibly see this as a serious issue?



___
Gen-art mailing list
Gen-art@ietf.org

Re: [Gen-art] Genart last call review of draft-ietf-ospf-mpls-elc-13

2020-05-18 Thread elwynd 
Hi.I am not convinced by the discussion that has ensued from my review.s3, para 
3:    If the router supports ELs on all of its interfaces, it SHOULD
   advertise the ELC with every local host prefix it advertises in OSPF.
- Both Acee amd I didn't immediately understand that 'every local host prefix' 
was not every 
  prefix that the router might advertise.  It would be good to explain that 
this is the case.- As I previously stated, with a SHOULD it ought to be 
explained why one might not want to
  advertise the ELC with some subset of the local host prefixes.- Given that 
there are now two sets of prefixes, would/SHOULD/MUST ELC be advertised with 
the 
  prefixes that are not local host prefixes?s4, para 3:   The absence of 
ERLD-MSD advertisements indicates only that the
   advertising node does not support advertisement of this capability.Firstly, 
I cannot see why this statement or its absence might affect other EL mechanisms 
that
don't use OSPF to do signaling of ELC.  If I understand RFC 8662 correctly, if 
OSPF is being used to distribute ELC adverts and the ERLD 
is not advertised by OSPF, then either the ERLD has to be supplied by other 
means or it will 
effectively default to zero.Thus, I would suggest that the paragraph above 
should be replaced with:   Advertisement of ERLD via OSPF using ERLD-MSD is 
OPTIONAL.  If a router does not advertise 
   ERLD, then the EL positioning calculations described in [RFC8662] will 
assume a vaue of zero
   for the ERLD of this router unless a different value is supplied by 
alternative means. Regards,ElwynSent from Samsung tablet.
 Original message From: "Acee Lindem (acee)"  
Date: 14/05/2020  21:43  (GMT+00:00) To: Alvaro Retana 
, "Peter Psenak (ppsenak)" , Elwyn 
Davies , gen-art@ietf.org Cc: last-c...@ietf.org, 
draft-ietf-ospf-mpls-elc@ietf.org, l...@ietf.org Subject: Re: Genart last 
call review of draft-ietf-ospf-mpls-elc-13 

Hi Alvaro, Elwyn, 
 

From:
Alvaro Retana 
Date: Thursday, May 14, 2020 at 3:46 PM
To: Acee Lindem , "Peter Psenak (ppsenak)" , 
Elwyn Davies , "gen-art@ietf.org" 
Cc: "last-c...@ietf.org" , 
"draft-ietf-ospf-mpls-elc@ietf.org" 
, "l...@ietf.org" 
Subject: Re: Genart last call review of draft-ietf-ospf-mpls-elc-13


 


Hi!


 


Yes, we cannot specify something that routers unaware of this specification 
should or shouldn’t do.


 


I believe that Elwyn’s point is this: *if a router supports this specification* 
then when would it not advertise the ELC?  IOW, the specification only obviously
 applies to implementations that support it — in that case I would think that 
if a router supports ELs on all of its interfaces then it would always 
advertise the ELC, right?
 
That’s true – but not advertising the OSPF capability could imply that either 
ELC MSD or advertisement of the OSPF capability is not supported. Although I 
might not have worded it as such, that was clear to me from the text. Feel free 
to
 recommend alternate text if you feel it is necessary. 
 
Thanks,
Acee


 


Thanks!


 


Alvaro.

 
On May 11, 2020 at 3:18:34 PM, Acee Lindem (acee) (a...@cisco.com) wrote:


Note that the optionality of ERLD-MSD advertisements appears on 
reflection to be a more serious issue than just an editorial nit. 

So what would you suggest? There are existing implementations that support 
multipath forwarding entropy using MPLS entropy labels but do not signal that 
capability in OSPF. We can't have a document that retroactively mandates
 that they signal it. This wouldn't be backward compatible. How can you 
possibly see this as a serious issue? 



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-ospf-mpls-elc-13

2020-05-14 Thread Acee Lindem (acee) 
Hi Alvaro, Elwyn,

From: Alvaro Retana 
Date: Thursday, May 14, 2020 at 3:46 PM
To: Acee Lindem , "Peter Psenak (ppsenak)" , 
Elwyn Davies , "gen-art@ietf.org" 
Cc: "last-c...@ietf.org" , 
"draft-ietf-ospf-mpls-elc@ietf.org" 
, "l...@ietf.org" 
Subject: Re: Genart last call review of draft-ietf-ospf-mpls-elc-13

Hi!

Yes, we cannot specify something that routers unaware of this specification 
should or shouldn’t do.

I believe that Elwyn’s point is this: *if a router supports this specification* 
then when would it not advertise the ELC?  IOW, the specification only 
obviously applies to implementations that support it — in that case I would 
think that if a router supports ELs on all of its interfaces then it would 
always advertise the ELC, right?

That’s true – but not advertising the OSPF capability could imply that either 
ELC MSD or advertisement of the OSPF capability is not supported. Although I 
might not have worded it as such, that was clear to me from the text. Feel free 
to recommend alternate text if you feel it is necessary.

Thanks,
Acee

Thanks!

Alvaro.


On May 11, 2020 at 3:18:34 PM, Acee Lindem (acee) 
(a...@cisco.com) wrote:
Note that the optionality of ERLD-MSD advertisements appears on
reflection to be a more serious issue than just an editorial nit.

So what would you suggest? There are existing implementations that support 
multipath forwarding entropy using MPLS entropy labels but do not signal that 
capability in OSPF. We can't have a document that retroactively mandates that 
they signal it. This wouldn't be backward compatible. How can you possibly see 
this as a serious issue?
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-ospf-mpls-elc-13

2020-05-14 Thread Alvaro Retana 
Hi!

Yes, we cannot specify something that routers unaware of this specification
should or shouldn’t do.

I believe that Elwyn’s point is this: *if a router supports this
specification* then when would it not advertise the ELC?  IOW, the
specification only obviously applies to implementations that support it —
in that case I would think that if a router supports ELs on all of its
interfaces then it would always advertise the ELC, right?


Thanks!

Alvaro.

On May 11, 2020 at 3:18:34 PM, Acee Lindem (acee) (a...@cisco.com) wrote:

Note that the optionality of ERLD-MSD advertisements appears on
reflection to be a more serious issue than just an editorial nit.

So what would you suggest? There are existing implementations that support
multipath forwarding entropy using MPLS entropy labels but do not signal
that capability in OSPF. We can't have a document that retroactively
mandates that they signal it. This wouldn't be backward compatible. How can
you possibly see this as a serious issue?
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-ospf-mpls-elc-13

2020-05-11 Thread Acee Lindem (acee) 
Hi Elwyn, 

On 5/11/20, 2:10 PM, "Elwyn Davies"  wrote:

Hi, Peter.

In the light of some of your responses here, I would just like to 
clarify that one of the reasons for gen-art reviews is to try and make 
extremely complicated technical documents more accessible for those who 
are not as deeply embedded in the jargon and technicalities of the 
subject as well as making sure that readers can quickly determine 
whether a document is relevant to work that they are doing.

Please take this into account when considering your further actions.

Note that the optionality of ERLD-MSD advertisements appears on 
reflection to be a more serious issue than just an editorial nit.

So what would you suggest? There are existing implementations that support 
multipath forwarding entropy using MPLS entropy labels but do not signal that 
capability in OSPF. We can't have a document that retroactively mandates that 
they signal it. This wouldn't be backward compatible. How can you possibly see 
this as a serious issue? 

Thanks,
Acee


Regards,

Elwyn

On 07/05/2020 08:53, Peter Psenak wrote:

> Hi Elwyn,
>
> please see inline:
>
> On 06/05/2020 16:25, Elwyn Davies via Datatracker wrote:
>> Reviewer: Elwyn Davies
>> Review result: Ready with Nits
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> .
>>
>> Document: draft-ietf-ospf-mpls-elc-13
>> Reviewer: Elwyn Davies
>> Review Date: 2020-05-06
>> IETF LC End Date: 2020-05-05
>> IESG Telechat date: 2020-05-21
>>
>> Summary:
>> Ready with nits.  Aside:  I have to say that the convolutions and
>> cross-referencing of doing the OSPF and IS-IS  extensions plus BGP-LS 
>> added to
>> the cross-linking with MPLS is leading to mind-blowing complexity.  
>> Sooner or
>> later something is going to blow up here!
>>
>> Major issues:
>> None
>>
>> Minor issues:
>> None
>>
>> Nits/editorial comments:
>>
>> Abstract and title :  The application to BGP-LS (s5) is not mentioned 
>> in the
>> abstract or the title.  Also the first use of BGP-LS needs to be 
>> expanded.
>
> Why would the BGP-LS need to be mentioned in the abstract?
At present BGP-LS is the subject of a separate document and this 
document extends the BGP add-on called BGP-LS as well as OSPF v2 and 
v3.  It is therefor important that implementers of BGP-LS can easily 
find documents that are relevant to their work.
>
> I have expanded the first use of BGP-LS
>
>>
>> Abstract: s/tunnel/LSP/
>
> done
>
>>
>> s1: Suggest s/SR-MPLS/Segment Routing with the MPLS Data Plane/
>>
>> s1: Query:  As a non-expert in this area, I was wondering if the 
>> signalling
>> capability is or will be implemented in IS-IS?  A brief comment on 
>> the status
>> wrt IS-IS would be helpful.  [It turns out that you already reference 
>> the
>> document that implements this later in this draft.]
>
> yes, it is being added to ISIS. Yes, this draft reference the ISIS 
> draft. I see no reason to to include ISIS draft status in this 
> document though.
As has been mentioned in other reviews of this document and the 
corresponding IS-IS document, having two documents that cover this 
extension is not very desirable.  As a non-expert, but who knows that 
OSPF and IS-IS provide closely related functionality, one gets to this 
point in the document and wonders why OSPF and not IS-IS. If the WG does 
not bite the bullet and combine the drafts, it would be highly desirable 
to point out that the same functionality is being proposed for all three 
protocols
>
>
>>
>> s1, last sentence: s/it's/it is/
>
> done
>
>>
>> s3: It would be a good idea to expand 'prefix' to 'address prefix
>> advertisement' on its first occurrence here.  Thereafter 'prefix' is 
>> fine by me.
>
> "prefix" is being used in almost all OSPF and ISIS document, we never 
> use address prefix.
Really? Revisiting RFC 2328 (OSPFv2) we see that prefix is not used at 
all and in RFC 5340 (OSPF for IPv6)  the term prefix is introduced as 
'IP address prefix'.  In order to make it clear of what this is a 
prefix, and what is going on here, expanding the initial usage is highly 
desirable.
>
>
>>
>> s3, para 3: Why would a router not advertise the ELC with all 
>> prefixes?  Can
>> you say why this ought not to be a MUST.
>
>

Re: [Gen-art] Genart last call review of draft-ietf-ospf-mpls-elc-13

2020-05-11 Thread Peter Psenak 

Hi Elwyn,

please see inline (##PP)


On 11/05/2020 19:37, Elwyn Davies wrote:

Hi, Peter.

In the light of some of your responses here, I would just like to
clarify that one of the reasons for gen-art reviews is to try and make
extremely complicated technical documents more accessible for those who
are not as deeply embedded in the jargon and technicalities of the
subject as well as making sure that readers can quickly determine
whether a document is relevant to work that they are doing.

Please take this into account when considering your further actions.

Note that the optionality of ERLD-MSD advertisements appears on
reflection to be a more serious issue than just an editorial nit.

Regards,

Elwyn

On 07/05/2020 08:53, Peter Psenak wrote:


Hi Elwyn,

please see inline:

On 06/05/2020 16:25, Elwyn Davies via Datatracker wrote:

Reviewer: Elwyn Davies
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-ospf-mpls-elc-13
Reviewer: Elwyn Davies
Review Date: 2020-05-06
IETF LC End Date: 2020-05-05
IESG Telechat date: 2020-05-21

Summary:
Ready with nits.  Aside:  I have to say that the convolutions and
cross-referencing of doing the OSPF and IS-IS  extensions plus BGP-LS
added to
the cross-linking with MPLS is leading to mind-blowing complexity.
Sooner or
later something is going to blow up here!

Major issues:
None

Minor issues:
None

Nits/editorial comments:

Abstract and title :  The application to BGP-LS (s5) is not mentioned
in the
abstract or the title.  Also the first use of BGP-LS needs to be
expanded.


Why would the BGP-LS need to be mentioned in the abstract?

At present BGP-LS is the subject of a separate document and this
document extends the BGP add-on called BGP-LS as well as OSPF v2 and
v3.  It is therefor important that implementers of BGP-LS can easily
find documents that are relevant to their work.


##PP
not that I necessarily agree, but let me add it.



I have expanded the first use of BGP-LS



Abstract: s/tunnel/LSP/


done



s1: Suggest s/SR-MPLS/Segment Routing with the MPLS Data Plane/

s1: Query:  As a non-expert in this area, I was wondering if the
signalling
capability is or will be implemented in IS-IS?  A brief comment on
the status
wrt IS-IS would be helpful.  [It turns out that you already reference
the
document that implements this later in this draft.]


yes, it is being added to ISIS. Yes, this draft reference the ISIS
draft. I see no reason to to include ISIS draft status in this
document though.

As has been mentioned in other reviews of this document and the
corresponding IS-IS document, having two documents that cover this
extension is not very desirable.  As a non-expert, but who knows that
OSPF and IS-IS provide closely related functionality, one gets to this
point in the document and wonders why OSPF and not IS-IS. If the WG does
not bite the bullet and combine the drafts, it would be highly desirable
to point out that the same functionality is being proposed for all three
protocols


##PP

Alvaro has responded to this already. Please have a look at his response 
to Barry Leiba's comments.


All I would add is that we have had many separate RFCs for OSPF and ISIS 
specifying the same functional extension in the past. I see no reason 
why that would suddenly became an issue.









s1, last sentence: s/it's/it is/


done



s3: It would be a good idea to expand 'prefix' to 'address prefix
advertisement' on its first occurrence here.  Thereafter 'prefix' is
fine by me.


"prefix" is being used in almost all OSPF and ISIS document, we never
use address prefix.

Really? Revisiting RFC 2328 (OSPFv2) we see that prefix is not used at
all and in RFC 5340 (OSPF for IPv6)  the term prefix is introduced as
'IP address prefix'.  In order to make it clear of what this is a
prefix, and what is going on here, expanding the initial usage is highly
desirable.



well, one can argue that we have "OSPFv2 Extended Prefix TLV", not the 
"OSPFv2 Extended Address Prefix TLV" and "OSPFv3 PrefixOptions" rather 
than "OSPFv3 AddressPrefixOptions"







s3, para 3: Why would a router not advertise the ELC with all
prefixes?  Can
you say why this ought not to be a MUST.


advertising ELC property with prefix advertisement is optional. We can
not mandate it. It would make all routers not advertising this data
violating this spec.

Er, no.  Nothing is said or would be said about routers that do not
support ELC at all or do not support it on all interfaces.  I am
assuming that it is not intended to make implementation of this
capability mandatory in all OSPF deployments. I was trying to understand
why a router that satisfies the previous condition so that it is

Re: [Gen-art] Genart last call review of draft-ietf-ospf-mpls-elc-13

2020-05-11 Thread Elwyn Davies 

Hi, Peter.

In the light of some of your responses here, I would just like to 
clarify that one of the reasons for gen-art reviews is to try and make 
extremely complicated technical documents more accessible for those who 
are not as deeply embedded in the jargon and technicalities of the 
subject as well as making sure that readers can quickly determine 
whether a document is relevant to work that they are doing.


Please take this into account when considering your further actions.

Note that the optionality of ERLD-MSD advertisements appears on 
reflection to be a more serious issue than just an editorial nit.


Regards,

Elwyn

On 07/05/2020 08:53, Peter Psenak wrote:


Hi Elwyn,

please see inline:

On 06/05/2020 16:25, Elwyn Davies via Datatracker wrote:

Reviewer: Elwyn Davies
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-ospf-mpls-elc-13
Reviewer: Elwyn Davies
Review Date: 2020-05-06
IETF LC End Date: 2020-05-05
IESG Telechat date: 2020-05-21

Summary:
Ready with nits.  Aside:  I have to say that the convolutions and
cross-referencing of doing the OSPF and IS-IS  extensions plus BGP-LS 
added to
the cross-linking with MPLS is leading to mind-blowing complexity.  
Sooner or

later something is going to blow up here!

Major issues:
None

Minor issues:
None

Nits/editorial comments:

Abstract and title :  The application to BGP-LS (s5) is not mentioned 
in the
abstract or the title.  Also the first use of BGP-LS needs to be 
expanded.


Why would the BGP-LS need to be mentioned in the abstract?
At present BGP-LS is the subject of a separate document and this 
document extends the BGP add-on called BGP-LS as well as OSPF v2 and 
v3.  It is therefor important that implementers of BGP-LS can easily 
find documents that are relevant to their work.


I have expanded the first use of BGP-LS



Abstract: s/tunnel/LSP/


done



s1: Suggest s/SR-MPLS/Segment Routing with the MPLS Data Plane/

s1: Query:  As a non-expert in this area, I was wondering if the 
signalling
capability is or will be implemented in IS-IS?  A brief comment on 
the status
wrt IS-IS would be helpful.  [It turns out that you already reference 
the

document that implements this later in this draft.]


yes, it is being added to ISIS. Yes, this draft reference the ISIS 
draft. I see no reason to to include ISIS draft status in this 
document though.
As has been mentioned in other reviews of this document and the 
corresponding IS-IS document, having two documents that cover this 
extension is not very desirable.  As a non-expert, but who knows that 
OSPF and IS-IS provide closely related functionality, one gets to this 
point in the document and wonders why OSPF and not IS-IS. If the WG does 
not bite the bullet and combine the drafts, it would be highly desirable 
to point out that the same functionality is being proposed for all three 
protocols





s1, last sentence: s/it's/it is/


done



s3: It would be a good idea to expand 'prefix' to 'address prefix
advertisement' on its first occurrence here.  Thereafter 'prefix' is 
fine by me.


"prefix" is being used in almost all OSPF and ISIS document, we never 
use address prefix.
Really? Revisiting RFC 2328 (OSPFv2) we see that prefix is not used at 
all and in RFC 5340 (OSPF for IPv6)  the term prefix is introduced as 
'IP address prefix'.  In order to make it clear of what this is a 
prefix, and what is going on here, expanding the initial usage is highly 
desirable.





s3, para 3: Why would a router not advertise the ELC with all 
prefixes?  Can

you say why this ought not to be a MUST.


advertising ELC property with prefix advertisement is optional. We can
not mandate it. It would make all routers not advertising this data
violating this spec.
Er, no.  Nothing is said or would be said about routers that do not 
support ELC at all or do not support it on all interfaces.  I am 
assuming that it is not intended to make implementation of this 
capability mandatory in all OSPF deployments. I was trying to understand 
why a router that satisfies the previous condition so that it is 
legitimate for it to announce ELC with any IP address prefix might wish 
to only announce it with some prefixes and not others.  This is an 
interesting question for implementers as the SHOULD implies that an 
implementation has to provide a configuration option on a per prefix basis




s4, para 3: In that case, what does the absence signify?  Should we 
care?


the absence of ERLD-MSD advertisements only indicates that a node
does not support advertisement of ERLD

It can not be interpreted that ERLD is not supported.  Old nodes that do
not advertise ERLD-MSD can not be

Re: [Gen-art] Genart last call review of draft-ietf-ospf-mpls-elc-13

2020-05-07 Thread Peter Psenak 

Hi Elwyn,

please see inline:

On 06/05/2020 16:25, Elwyn Davies via Datatracker wrote:

Reviewer: Elwyn Davies
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-ospf-mpls-elc-13
Reviewer: Elwyn Davies
Review Date: 2020-05-06
IETF LC End Date: 2020-05-05
IESG Telechat date: 2020-05-21

Summary:
Ready with nits.  Aside:  I have to say that the convolutions and
cross-referencing of doing the OSPF and IS-IS  extensions plus BGP-LS added to
the cross-linking with MPLS is leading to mind-blowing complexity.  Sooner or
later something is going to blow up here!

Major issues:
None

Minor issues:
None

Nits/editorial comments:

Abstract and title :  The application to BGP-LS (s5) is not mentioned in the
abstract or the title.  Also the first use of BGP-LS needs to be expanded.


Why would the BGP-LS need to be mentioned in the abstract?

I have expanded the first use of BGP-LS



Abstract: s/tunnel/LSP/


done



s1: Suggest s/SR-MPLS/Segment Routing with the MPLS Data Plane/

s1: Query:  As a non-expert in this area, I was wondering if the signalling
capability is or will be implemented in IS-IS?  A brief comment on the status
wrt IS-IS would be helpful.  [It turns out that you already reference the
document that implements this later in this draft.]


yes, it is being added to ISIS. Yes, this draft reference the ISIS 
draft. I see no reason to to include ISIS draft status in this document 
though.





s1, last sentence: s/it's/it is/


done



s3: It would be a good idea to expand 'prefix' to 'address prefix
advertisement' on its first occurrence here.  Thereafter 'prefix' is fine by me.


"prefix" is being used in almost all OSPF and ISIS document, we never 
use address prefix.





s3, para 3: Why would a router not advertise the ELC with all prefixes?  Can
you say why this ought not to be a MUST.


advertising ELC property with prefix advertisement is optional. We can
not mandate it. It would make all routers not advertising this data
violating this spec.



s4, para 3: In that case, what does the absence signify?  Should we care?


the absence of ERLD-MSD advertisements only indicates that a node
does not support advertisement of ERLD

It can not be interpreted that ERLD is not supported.  Old nodes that do
not advertise ERLD-MSD can not be assumed not to support non-zero ERLD.




s4, para 4:
This needs a correction and a reference to where the Link MSD Sub-TLV is
defined.  As a matter of interest, is there any reason why this should be sent
in an OSPF context?  If not why not just prohibit sending it? If it is received
should it provoke an error rather than being ignored? OLD: When the ERLD
MSD-Type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV, it MUST be
ignored. NEW:
  When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV
  [RFC8476], it MUST be ignored.


done.


ENDS

s5:  This section needs to be rewritten to be 'future proof' rather than
referring to the temporary allocations.  A note about the temporary allocations
can be added with a RFC Editor note requesting its removal on final publication.


I suppose you meant section 6 - IANA Considerations.

I have updated the IANA section.

thanks,
Peter








___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-ospf-mpls-elc-13

2020-05-06 Thread Elwyn Davies via Datatracker 
Reviewer: Elwyn Davies
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-ospf-mpls-elc-13
Reviewer: Elwyn Davies
Review Date: 2020-05-06
IETF LC End Date: 2020-05-05
IESG Telechat date: 2020-05-21

Summary:
Ready with nits.  Aside:  I have to say that the convolutions and
cross-referencing of doing the OSPF and IS-IS  extensions plus BGP-LS added to
the cross-linking with MPLS is leading to mind-blowing complexity.  Sooner or
later something is going to blow up here!

Major issues:
None

Minor issues:
None

Nits/editorial comments:

Abstract and title :  The application to BGP-LS (s5) is not mentioned in the
abstract or the title.  Also the first use of BGP-LS needs to be expanded.

Abstract: s/tunnel/LSP/

s1: Suggest s/SR-MPLS/Segment Routing with the MPLS Data Plane/

s1: Query:  As a non-expert in this area, I was wondering if the signalling
capability is or will be implemented in IS-IS?  A brief comment on the status
wrt IS-IS would be helpful.  [It turns out that you already reference the
document that implements this later in this draft.]

s1, last sentence: s/it's/it is/

s3: It would be a good idea to expand 'prefix' to 'address prefix
advertisement' on its first occurrence here.  Thereafter 'prefix' is fine by me.

s3, para 3: Why would a router not advertise the ELC with all prefixes?  Can
you say why this ought not to be a MUST.

s4, para 3: In that case, what does the absence signify?  Should we care?

s4, para 4:
This needs a correction and a reference to where the Link MSD Sub-TLV is
defined.  As a matter of interest, is there any reason why this should be sent
in an OSPF context?  If not why not just prohibit sending it? If it is received
should it provoke an error rather than being ignored? OLD: When the ERLD
MSD-Type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV, it MUST be
ignored. NEW:
 When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV
 [RFC8476], it MUST be ignored.
ENDS

s5:  This section needs to be rewritten to be 'future proof' rather than
referring to the temporary allocations.  A note about the temporary allocations
can be added with a RFC Editor note requesting its removal on final publication.



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art