Re: [Lsr] Éric Vyncke's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)

[Acee Lindem (acee)]

Hi Eric,


On 5/11/20, 3:50 PM, "Eric Vyncke (evyncke)"  wrote:

Peter,

I will have a look for Alvaro's reply to Barry's comment then :)

https://mailarchive.ietf.org/arch/msg/lsr/EcufJn28CFrGkfQ2k6LUOYBcZXc/

Thanks,
Acee

The suggested text below will fix the nit indeed.

Thank you

-éric

-Original Message-
From: Peter Psenak 
Date: Monday, 11 May 2020 at 19:14
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-isis-mpls-...@ietf.org" 
, "lsr-cha...@ietf.org" 
, "lsr@ietf.org" , "Acee Lindem (acee)" 
, "aretana.i...@gmail.com" 
Subject: Re: Éric Vyncke's No Objection on draft-ietf-isis-mpls-elc-12: 
(with COMMENT)

Hi Eric,

please see inline:

On 11/05/2020 18:02, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-isis-mpls-elc-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut 
this
> introductory paragraph, however.)
> 
> 
> Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thank you for the work put into this document. The document is easy 
to read.
> 
> Like other ADs, I wonder why the IS-IS and OSPF are separate 
documents.

Alvaro has responded to similar query from Barry Leiba.

> 
> Please find below one NIT.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == NIT ==
> 
> -- section 4 --
> The "one" is ambiguous in "the router MUST advertise the smallest 
one." even if
> we can guess that it is not "interface" ;-)

ok, what would you like to say instead "one"?

Would this be better:

If a router has multiple interfaces with different capabilities of 
reading the maximum label stack depth, the router MUST advertise the 
smallest value found across all of its interfaces.

thanks,
Peter


> 
> 
> 
> 
> 



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Éric Vyncke's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)

[Eric Vyncke (evyncke)]

Peter,

I will have a look for Alvaro's reply to Barry's comment then :)

The suggested text below will fix the nit indeed.

Thank you

-éric

-Original Message-
From: Peter Psenak 
Date: Monday, 11 May 2020 at 19:14
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-isis-mpls-...@ietf.org" , 
"lsr-cha...@ietf.org" , "lsr@ietf.org" , 
"Acee Lindem (acee)" , "aretana.i...@gmail.com" 

Subject: Re: Éric Vyncke's No Objection on draft-ietf-isis-mpls-elc-12: (with 
COMMENT)

Hi Eric,

please see inline:

On 11/05/2020 18:02, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-isis-mpls-elc-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thank you for the work put into this document. The document is easy to 
read.
> 
> Like other ADs, I wonder why the IS-IS and OSPF are separate documents.

Alvaro has responded to similar query from Barry Leiba.

> 
> Please find below one NIT.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == NIT ==
> 
> -- section 4 --
> The "one" is ambiguous in "the router MUST advertise the smallest one." 
even if
> we can guess that it is not "interface" ;-)

ok, what would you like to say instead "one"?

Would this be better:

If a router has multiple interfaces with different capabilities of 
reading the maximum label stack depth, the router MUST advertise the 
smallest value found across all of its interfaces.

thanks,
Peter


> 
> 
> 
> 
> 


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

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

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

[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: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

[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 assu

Re: [Lsr] Éric Vyncke's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

[Peter Psenak]

Hi Eric,

please see inline:

On 11/05/2020 17:55, Éric Vyncke via Datatracker wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-ospf-mpls-elc-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/



--
COMMENT:
--

Thank you for the work put into this document. The document is easy to read.

Please find below one non-blocking COMMENTs and two NITs.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENT ==

For my own curiosity, is there a possibility that a router receives conflicting
node capability via OSPFv2 and OSPFv3 (assuming that both are running over the
same network and using the same router-ID over OSPFv2 and OSPFv3) ?


that would be a bug likely, as the capability is not specific to any of 
the protocol and they only act as messengers. But we can not mandate any 
cross protocols checking either.




== NITS ==

-- section 4 --
The "one" is ambiguous in "the router MUST advertise the smallest one." even if
we can guess that it is not "interface" ;-)

-- Sections 3 & 4 --
Is there a meaningful difference between the "advertizing" of section 3 and the
"signaling" of section 4?


not really. In IGPs we tend to use "advertise" more. If you prefer, I 
can change all to "advertise" or to "signal" for consistency.


thanks,
Peter











___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Éric Vyncke's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)

[Peter Psenak]

Hi Eric,

please see inline:

On 11/05/2020 18:02, Éric Vyncke via Datatracker wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-isis-mpls-elc-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/



--
COMMENT:
--

Thank you for the work put into this document. The document is easy to read.

Like other ADs, I wonder why the IS-IS and OSPF are separate documents.


Alvaro has responded to similar query from Barry Leiba.



Please find below one NIT.

I hope that this helps to improve the document,

Regards,

-éric

== NIT ==

-- section 4 --
The "one" is ambiguous in "the router MUST advertise the smallest one." even if
we can guess that it is not "interface" ;-)


ok, what would you like to say instead "one"?

Would this be better:

If a router has multiple interfaces with different capabilities of 
reading the maximum label stack depth, the router MUST advertise the 
smallest value found across all of its interfaces.


thanks,
Peter










___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04

[tony . li]

Hi Xuesong,

> Thank you for giving detailed proof, and it is very helpful to understand the 
> mechanism.
> As I understand, it is showed in the proof that if there is proper temporary 
> flooding in R = E - E* - E’, same connectivity could be achieved by the 
> flooding topology F’ just as G’. I agree with this.


I’m glad it helped.


> The problem for me now is how to enable the temporary flooding properly.
> Here is an example:
> 
> The solid line presents the physical link inside flooding topology, and the 
> dashed line presents the physical link out of flooding topology.
> From the view of me, when multipoint failure happens, node 3 is supposed to 
> enable the temporary flooding between 3 and 4, in order to connect with the 
> nodes inside the red box, while the other dashed line between node 1 and node 
> nobody is not supposed to do temporary flooding although node 1 is connected 
> to the failed link directly.
> It seems a little unclear for me about how the node itself could decide 
> whether a dashed line should do temporary flooding or not in this case.


The problem that you’re asking about is partition detection.

To explain this, I’ve taken the liberty of adding some more labels to your 
diagram.

To start, each node has its link state database and the flooding topology.  
Each node should receive link state updates from nodes in its partition, but 
will not receive updates from other nodes, thus the link state database is 
partially inconsistent and must be treated with care.

For example, node 2 will see updates from nodes 1, 6, and 7, informing it of 
the failure, but it will not receive an update from node 8.

Now, the job of each node is try to compute the partitions of the flooding 
topology.  In particular, each node needs to understand which nodes are in its 
partition. A node cannot know all of the partitions that exist, but it turns 
out that that’s irrelevant.

Once a node understands which nodes are in its partition, then it is a simple 
matter to see which links should be enabled for temporary flooding.  If a 
neighbor is in the same partition (e.g., nodes 1 and 5), then adding the link 
adds no value. If the neighbor is not in the same partition (e.g., nodes 3 and 
4), then it becomes a recovery link.

The actual computation of the partitions is straightforward, with one caveat: 
we always want to perform a two-way check for connectivity.  An implementation 
should be doing this during SPF already, so this should be familiar. The reason 
for doing this is quite clear: in node 2’s link state database (LSDB), the LSP 
for node 8 will show connectivity to node 1 even after the failure. However, 
node 1’s LSP will clearly show that the adjacency has failed.  We can only 
infer connectivity when we see both sides of the adjacency are up.

Given this, the specific algorithm that you choose is an implementation detail. 
 You could do a breadth-first search or a depth-first search. Our 
implementation chooses to walk the entire flooding topology, building a tree of 
the partitions that it detects. [IPR note: we have a IPR claim for this 
approach, with the “don’t sue us, we won’t sue you” terms.]

I hope this helps.

Regards,
Tony


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Éric Vyncke's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-isis-mpls-elc-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/



--
COMMENT:
--

Thank you for the work put into this document. The document is easy to read.

Like other ADs, I wonder why the IS-IS and OSPF are separate documents.

Please find below one NIT.

I hope that this helps to improve the document,

Regards,

-éric

== NIT ==

-- section 4 --
The "one" is ambiguous in "the router MUST advertise the smallest one." even if
we can guess that it is not "interface" ;-)



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Éric Vyncke's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-ospf-mpls-elc-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/



--
COMMENT:
--

Thank you for the work put into this document. The document is easy to read.

Please find below one non-blocking COMMENTs and two NITs.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENT ==

For my own curiosity, is there a possibility that a router receives conflicting
node capability via OSPFv2 and OSPFv3 (assuming that both are running over the
same network and using the same router-ID over OSPFv2 and OSPFv3) ?

== NITS ==

-- section 4 --
The "one" is ambiguous in "the router MUST advertise the smallest one." even if
we can guess that it is not "interface" ;-)

-- Sections 3 & 4 --
Is there a meaningful difference between the "advertizing" of section 3 and the
"signaling" of section 4?



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04

[Gengxuesong (Geng Xuesong)]

Hi Tony,

Thank you for giving detailed proof, and it is very helpful to understand the 
mechanism.
As I understand, it is showed in the proof that if there is proper temporary 
flooding in R = E - E* - E’, same connectivity could be achieved by the 
flooding topology F’ just as G’. I agree with this.
The problem for me now is how to enable the temporary flooding properly.
Here is an example:
[1AB72D8D-D69C-4047-9E89-5F6062EB6526]
The solid line presents the physical link inside flooding topology, and the 
dashed line presents the physical link out of flooding topology.
From the view of me, when multipoint failure happens, node 3 is supposed to 
enable the temporary flooding between 3 and 4, in order to connect with the 
nodes inside the red box, while the other dashed line between node 1 and node 
nobody is not supposed to do temporary flooding although node 1 is connected to 
the failed link directly.
It seems a little unclear for me about how the node itself could decide whether 
a dashed line should do temporary flooding or not in this case.


Best Regards
Xuesong


From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Sunday, May 10, 2020 1:18 AM
To: Gengxuesong (Geng Xuesong) 
Cc: sarahc...@arista.com; lsr@ietf.org
Subject: Re: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04


Hi Xuesong,


Thank you for your work about Flooding Reduction mechanism. I think it is very 
useful for IGP scalability.


Thank you, we very much appreciate that.


When Sarah giving presentation for draft-chen-lsr-dynamic-flooding-algorithm-00 
in LSR interim meeting, I raised a question about how to handle multipoint 
failure in the flooding topology. I remembered that 
draft-ietf-lsr-dynamic-flooding-04 was mentioned. I have read this draft, 
especially section 6.8.11 and temporary flooding relevant content. I think it 
is a valid method logically. (We have tried to raise some examples to challenge 
this method, but in all these cases, this method works) Considering that 
reliability of IGP is crucial for deployment, we are still wondering whether 
some mathematical proof is necessary (or possible) to guarantee that, in all 
the possible scenarios, proper convergence could be achieved when using 
flooding reduction algorithm, just as traditional IGP mechanism. The proof may 
be case by case depending on the flooding reduction algorithm, but we think 
even some example or clue about how to do this will be very helpful.


A proof? Ok, I can try to be rigorous, but it’s been a very long time. I 
apologize in advance to Kireeti, Mr. Myers, Mr. Douglas, and Prof. Greever for 
what follows.


Definition: Let G=(V, E) be a finite graph. F=(V, E’) is a ‘flooding topology’ 
on G if E’ is a subset of E and F is connected.


We normally have other properties for flooding topologies, such as being 
bi-connected, relatively sparse, minimal diameter, and minimal degree, but 
those properties are not relevant for this proof.


Definition: Let C=(V*, E*), V* a subset of V, E* a subset of E, be the ‘cut’ of 
G. This represents the failures in the topology. Let G’ = G - C, the topology 
after failure, and let F’ = F - C, be the flooding topology after failure.


Definition: Let R = E - E* - E’. This is the set of 'recovery edges': edges 
that have not failed and are not part of the flooding topology.


Corollary: R is finite.

Proof: G is finite, by definition. Therefore E is finite, E* must be finite, 
and E’ is finite.


Lemma 1: If G’ is connected, then F’ + R is connected.

Proof:

G’ = G - C = (V, E) - (V*, E*) = (V - V*, E - E*).

F’ + R = (F - C) + (E - E* - E’) = (V, E’) - (V*, E*) + (E - E* - E’) = ( V - 
V*, E’ - E* ) + ( E - E* - E’) = ( V - V*, E’ - E* + E - E* - E’ ) = ( V - V*, 
E - E* - E* ) = ( V - V*, E - E* ) = G’.

Q.E.D.


Lemma 2: If G’ is connected, then incrementally adding edges from R to F’ will 
yield a connected flooding topology.

Proof: By induction. Let R’ be a subset of R. Induction property: Either F' + 
R’ is connected, or R’ is a proper subset of R.

Base case: R’ is the empty set. If F’ is connected, then F’ + R’ is connected 
and the property is satisfied. If F’ + R’ is not connected, R’ is empty, which 
is a proper subset of R.

Induction case: Let r be a recovery edge in R - R’ (i.e., a new edge to add).  
If F’ + R’ is connected, then the property is satisfied already. If F’ + R’ + r 
is connected, the property is satisfied. If R’ + r = R, then by Lemma 1, the 
property is satisfied. Otherwise, R’ + r != R, and the property is satisfied. 
By our corollary, the induction must terminate.

Q.E.D.



Bugs, questions, and comments are welcome.

Regards,
Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr