Re: [Lsr] "OSPF Routing with Cross-Address Family Traffic Engineering Tunnels" - draft-ietf-ospf-xaf-te-05

2019-02-27 Thread Anton Smirnov 

   Hi Alexander,
   see some answers inline.

---
Anton


On 02/08/19 11:25, Alexander Okonnikov wrote:

Hi Acee,

For me current version doesn't change the solution. My comments are follow:

1.  Introduction

"TE Extensions to OSPFv2 [RFC3630] and OSPFv3 [RFC5329] have been 
described to support intra-area TE in IPv4 and IPv6 networks, 
respectively.  In both cases, the TE database provides a tight coupling 
between the routed protocol and advertised TE signaling information.  In 
other words, any use of the TE link state database is limited to IPv4 
for OSPFv2 [RFC2328] and IPv6 for OSPFv3 [RFC5340]."


What is meant for "routed protocol"? Is it passenger protocol of RSVP-TE 
LSPs, protocol used as a transport for RSVP signaling, protocol for 
which OSPFv2/OSPFv3 calculate routes?



"Routed protocol" here refers to "protocol for which OSPFv2/OSPFv3 
calculate routes".
Words "routed protocol" signify protocol that is subject of somebody's 
action, so this wording should exclude options like "protocol used as a 
transport for RSVP signaling" (here protocol is object, not subject).



>  What does mean "TEDB is limited
> to IPv4/IPv6"? Is it limited to choose IPv4/IPv6 as a transport for
> RSVP-TE LSP signaling?

Among other things selection of [RFC3630] versus [RFC5329] defines if 
IPv4 or IPv6 will be used as a transport for RSVP-TE LSP signaling. But 
not limited to only this, all other IPv4 vs IPv6 selections become 
predefined. As it is written in the draft, currently there exists "a 
tight coupling between the routed protocol and advertised TE signaling 
information".




"For example, an LSP created based on MPLS TE information propagated by 
an OSPFv2 instance can be used to transport both IPv4 and IPv6 traffic, 
as opposed to using both OSPFv2 and OSPFv3 to provision a separate LSP 
for each address family."


An LSP created based on TEDB from OSPFv2 can be used to transport IPv4 
and IPv6 without extensions, proposed in the draft. We are not obligated 
to signal RSVP-TE LSPs from OSPFv2 TEDB for IPv4 traffic and other 
RSVP-TE LSPs from OSPFv3 TEDB for IPv6 traffic. RSVP-TE LSPs signaled 
based on TEDB from either - OSPFv2 or OSPFv3 - can be used for transport 
either - IPv4 or IPv6 - traffic. I.e. payload of RSVP-TE LSP and 
transport protocol for its signaling are not obligated to be the same. I 
guess that authors meant that an LSP, based on MPLS TE from OSPFv2, can 
be used for calculation of shortcuts by OSPFv2, and not by OSPFv3.




Correct. Both the description of what protocol can go over what tunnel 
and interpretation of the text are correct.




3.  Operation

"A node that implements X-AF routing SHOULD advertise, in the 
corresponding Node Local Address sub-TLV, all X-AF IPv4 and IPv6 
addresses local to the router that can be used by Constrained SPF (CSPF) 
to calculate MPLS TE LSPs."


 From section 1 we assume that X-AF is used for calculation of 
shortcuts. Why does the draft say here about calculation of TE LSPs by CSPF?




CSPF as part of the whole procedure computing MPLS TE path among other 
things is defined in terms what IP addresses it uses to define tunnel 
tail-end. Reference to the CSPF is made to define set of IP addresses 
that would be of interest to X-AF algorithm.


---
Anton

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

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01

2019-02-27 Thread Huaimo Chen 
Support.

Best Regards,
Huaimo
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Huzhibo
Sent: Wednesday, February 27, 2019 5:09 AM
To: lsr@ietf.org; a...@cisco.com
Subject: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for 
PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01

Support.It is useful for collect cross-area IGP topologies

Ths
Zhibo Hu

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
peng.sha...@zte.com.cn
Sent: Wednesday, February 27, 2019 4:36 PM
To: a...@cisco.com
Cc: lsr@ietf.org
Subject: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for 
PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01


Support, as this draft provide useful originial source router-id of prefix, as 
the same as RFC7794.

For topology deducing, it seems too hard to work according to current 
description in the document. For example, It is hard to represent mulptile 
links between two nodes if we only know two node-id information but lack of 
interface IP address or interface-id that is link attribute not be included in 
prefix flooding, thus there is no way to consider which link could be contained 
in which TE path, also, so many TE parameters of link need to be supplied for 
the deducing topology, TE metric, bandwidth, etc. Maybe there already have a 
complete solution but just not describe detailedly in document.



Thanks

Deccan(Shaofu peng)






原始邮件
发件人：AceeLindem(acee) mailto:a...@cisco.com>>
收件人：lsr@ietf.org mailto:lsr@ietf.org>>;
日 期 ：2019年02月13日 21:26
主 题 ：[Lsr] Working Group Adoption Poll for "OSPF Extension for 
PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.

All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

Thanks,
Acee



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

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01

2019-02-27 Thread Huzhibo 
Support.It is useful for collect cross-area IGP topologies

Ths
Zhibo Hu

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of peng.sha...@zte.com.cn
Sent: Wednesday, February 27, 2019 4:36 PM
To: a...@cisco.com
Cc: lsr@ietf.org
Subject: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for 
PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01


Support, as this draft provide useful originial source router-id of prefix, as 
the same as RFC7794.

For topology deducing, it seems too hard to work according to current 
description in the document. For example, It is hard to represent mulptile 
links between two nodes if we only know two node-id information but lack of 
interface IP address or interface-id that is link attribute not be included in 
prefix flooding, thus there is no way to consider which link could be contained 
in which TE path, also, so many TE parameters of link need to be supplied for 
the deducing topology, TE metric, bandwidth, etc. Maybe there already have a 
complete solution but just not describe detailedly in document.



Thanks

Deccan(Shaofu peng)






原始邮件
发件人：AceeLindem(acee) mailto:a...@cisco.com>>
收件人：lsr@ietf.org mailto:lsr@ietf.org>>;
日 期 ：2019年02月13日 21:26
主 题 ：[Lsr] Working Group Adoption Poll for "OSPF Extension for 
PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.

All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

Thanks,
Acee



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

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01

2019-02-27 Thread peng.shaofu 
Support, as this draft provide useful originial source router-id of prefix, as 
the same as RFC7794.


For topology deducing, it seems too hard to work according to current 
description in the document. For example, It is hard to represent mulptile 
links between two nodes if we only know two node-id information but lack of 
interface IP address or interface-id that is link attribute not be included in 
prefix flooding, thus there is no way to consider which link could be contained 
in which TE path, also, so many TE parameters of link need to be supplied for 
the deducing topology, TE metric, bandwidth, etc. Maybe there already have a 
complete solution but just not describe detailedly in document. 






Thanks


Deccan(Shaofu peng)



















原始邮件



发件人：AceeLindem(acee) 
收件人：lsr@ietf.org ;
日 期 ：2019年02月13日 21:26
主 题 ：[Lsr] Working Group Adoption Poll for "OSPF Extension for 
PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01


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

  

This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.


 


All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext


It is listed multiple times but references the same CN201810650141.


 


Thanks,


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