Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[sridhar santhanam]

Hi All,
  I support the adoption of this draft.

Thanks,
Sridhar.S


>
> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: 11 February 2019 16:15
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
> Subject: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR
> poll.
>
>
> Hi Folks,
>
> We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.
>
> The aim of this document is to describe the problem space and standardize
> a way to signal dynamic flooding information. It does not standardize any
> specific algorithm for flooding topology creation.
>
> Authors please respond indicating if you are aware of any IPR related to
> this work.
>
> We also have another draft (draft-cc-lsr-flooding-reduction-01) that
> started as a distributed flooding topology algorithm and morphed into that
> plus competing ideas on signaling of flooding topology information. The
> intent after adoption of draft-li-lsr-dynamic-flooding-02 is two-fold. One,
> the WG can discuss adding any signaling ideas from this work to the adopted
> signaling draft (with proper attribution given as appropriate), and two,
> for the authors of draft-cc-lsr-flooding-reduction-01 to publish a new
> document without the signaling portion and instead focus on their flooding
> topology algorithm. This new focused document can be considered in parallel
> along with the other algorithm work that has been proposed.
>
> Flooding topology creation is seen as a hard problem for which we don't
> expect a one-size-fits-all solution. Taking the steps outlined above will
> help us move forward on the solutions.
>
> Thanks,
> Chris & Acee.
> LSR WG Chairs.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[Ketan Talaulikar (ketant)]

I support the adoption of this draft by the WG.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 11 February 2019 16:15
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
Subject: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.


Hi Folks,

We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.

The aim of this document is to describe the problem space and standardize a way 
to signal dynamic flooding information. It does not standardize any specific 
algorithm for flooding topology creation.

Authors please respond indicating if you are aware of any IPR related to this 
work.

We also have another draft (draft-cc-lsr-flooding-reduction-01) that started as 
a distributed flooding topology algorithm and morphed into that plus competing 
ideas on signaling of flooding topology information. The intent after adoption 
of draft-li-lsr-dynamic-flooding-02 is two-fold. One, the WG can discuss adding 
any signaling ideas from this work to the adopted signaling draft (with proper 
attribution given as appropriate), and two, for the authors of 
draft-cc-lsr-flooding-reduction-01 to publish a new document without the 
signaling portion and instead focus on their flooding topology algorithm. This 
new focused document can be considered in parallel along with the other 
algorithm work that has been proposed.

Flooding topology creation is seen as a hard problem for which we don't expect 
a one-size-fits-all solution. Taking the steps outlined above will help us move 
forward on the solutions.

Thanks,
Chris & Acee.
LSR WG Chairs.

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

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

[Ketan Talaulikar (ketant)]

Hi All,

The updates to the version 05 of the draft largely address my comments.

Please check inline below for some further comments.


From: Alexander Okonnikov 
Sent: 08 February 2019 15:56
To: Acee Lindem (acee) 
Cc: lsr@ietf.org; draft-ietf-ospf-xaf...@ietf.org; Gunter Van de Velde 
; Ketan Talaulikar (ketant) 
Subject: Re: [Lsr] "OSPF Routing with Cross-Address Family Traffic Engineering 
Tunnels" - draft-ietf-ospf-xaf-te-05

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"?
[KT] I believe this should be “routing protocol”?
Is it passenger protocol of RSVP-TE LSPs, protocol used as a transport for RSVP 
signaling, protocol for which OSPFv2/OSPFv3 calculate routes?  What does mean 
"TEDB is limited to IPv4/IPv6"? Is it limited to choose IPv4/IPv6 as a 
transport for RSVP-TE LSP signaling?

"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.
[KT] Yes. I believe the authors are referring to limitations in use of IGP 
shortcuts across AFs.

Authors provide description of possible solution with common Router ID. I 
propose similar solution with advertising both Router IDs (OSPFv2 and OSPFv3) 
in both instances (OSPFv2 and OSPFv3). Latter overcomes issues with correctness 
of configuration and out of sync. Also, I don't understand how can possible 
solution with common Router ID have problem with different placement of ABRs in 
OSPFv2 and OSPFv3. We are talking about intra-area LSPs, hence tail-end router 
should be within area in both instances.
[KT] Using common Router IDs and advertising across each AFs is an option, but 
personally, I find the use of Node Attribute TLV provides better flexibility.

Thanks,
Ketan


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?

"If the Node Attribute TLV carries both the Node IPv4 Local Address sub-TLV and 
the Node IPv6 Local Address sub-TLV, then the X-AF component MUST be considered 
for the consolidated calculation of MPLS TE LSPs."

The same.


Thanks.



31 янв. 2019 г., в 2:03, Acee Lindem (acee) 
mailto:a...@cisco.com>> написал(а):

Hi Gunter, Alex, Ketan,
I hoping everyone who commenting on the previous version is happy with the 
version. I’m extending the WG last call another week to see if we have any 
objections to this version.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Acee 
Lindem mailto:a...@cisco.com>>
Date: Monday, January 7, 2019 at 11:47 AM
To: "lsr@ietf.org" mailto:lsr@ietf.org>>
Cc: "draft-ietf-ospf-xaf...@ietf.org" 
mailto:draft-ietf-ospf-xaf...@ietf.org>>
Subject: [Lsr] "OSPF Routing with Cross-Address Family Traffic Engineering 
Tunnels" - draft-ietf-ospf-xaf-te-05

This begins an LSR WG last call for the subject draft. Please send your
comments to this list prior to 12:00 AM GMT, January 22nd, 2019.

Note that the second IPR poll was completed in December.

Thanks,
Acee

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