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

[Alexander Okonnikov]

Hi Anton,

I tend to agree with Ketan, but with slightly different proposal. Would not it 
be simpler to advertise IPv6 Router Address TLV (TLV type 3) by OSPFv2 Opaque 
LSA (in addition to advertising of Router Address TLV) and to advertise Router 
Address TLV (TLV type 1) by OSPFv3 Intra-Area-TE-LSA (in addition to 
advertising IPv6 Router Address TLV)? In this case we can identify the same 
router represented by OSPFv2 and OSPFv3 and don't need the extension provided 
by the draft.

Regarding calculation of LSPs towards non-TE addresses - head-end uses non-TE 
address in order to determine TE Router ID of the tail-end (which holds that 
non-TE address); then head-end uses TE RID in CSPF calculation (though it will, 
probably, use that non-TE address as a destination in RSVP-TE signaling). 
Hence, head-end can hold mapping of destination IP of an LSP to corresponding 
TE RID of tail-end. Then, if the same head-end attempts to calculate LSP using 
TEDB from OSPFv3 (OSPFv2), it will be able to determine whether LSP already 
have been signaled using OSPFv2 (OSPFv3) TEDB.

Also, the draft several times says about using TEDB(s) for calculation of LSPs 
and, on the other hand, for using LSPs for calculation of OSPF routes. Per my 
understanding these are two different independent tasks - calculation of LSPs 
and their usage. The second task is what defined by RFC 3906, and you want to 
extend it such that SPF for one AF can utilise LSPs as shortcuts, created for 
other AF. My understanding that these two tasks need to be discussed 
separately. It could be two different documents, or two different sections of 
the same one.

Thank you.

> 25 окт. 2018 г., в 19:57, Anton Smirnov  написал(а):
> 
>Hi Ketan,
> 
> 1. I am not sure I understood the question. Your example says "using the TE 
> topology from OSPFv2 to compute a tunnel". In that case TE router ID is an 
> IPv4 address. So no, advertising IPv6 address won't help to identify the 
> tunnel.
> 2. my opinion (not discussed with other authors): RFC 3906 is Informational 
> RFC, so it is not mandatory for implementation to follow. I think we can 
> insert mention to that RFC somewhere in the Introduction but wording should 
> be sufficiently weak (like "one possible example of route computation 
> algorithm...").
> ---
> Anton
> 
> On 10/24/18 12:06, Ketan Talaulikar (ketant) wrote:
>> Hello All,
>>  
>> I support this simple but important extension.
>>  
>> A couple of minor comments on the draft:
>>  
>> 1) Sec 3 says
>>  
>>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.  In general, OSPF SHOULD advertise
>>the IP address listed in the Router Address TLV [RFC3630 
>> ] [RFC5329 
>> ]
>>of the X-AF instance maintaining the MPLS TE database, plus any
>>additional local addresses advertised by the X-AF OSPF instance in
>>its Node Local Address sub-TLVs.  An implementation MAY advertise
>>other local X-AF addresses.
>>  
>> Generally speaking, should the IP address (TE router ID in common terms) 
>> which is candidate for inclusion in the Router Address TLV not be a MUST 
>> candidate for X-AF advertisement?
>>  
>> I also have a question about the first statement with the SHOULD in it. 
>> Consider we are using the TE topology from OSPFv2 to compute a tunnel for 
>> use with OSPFv3. Any IPv6 addresses associated with the OSPFv3 instance on a 
>> router would be advertised as a Node attribute and would not help identify a 
>> specific link. So practically, if any IPv6 addresses (if at all) were to be 
>> used for CSPF then it would just identify the node – in this case, isn’t 
>> advertising the IPv6 address (TE router ID used in Router Address TLV) 
>> sufficient?
>>  
>> For practical deployment, it think it would help if this was clarified that 
>> we really need only the TE Router ID Address to go X-AF in most/general 
>> cases and not the others?
>>  
>> 2) Isn’t the mapping algorithm in Sec 3 actually going to be used for 
>> IGP short-cut use-case with its reference to the IGP cost of the tunnel? If 
>> so, would a reference to rfc3906 be helpful in this document.
>>  
>> Thanks,
>> Ketan
>>  
>> From: Lsr   On Behalf Of 
>> Acee Lindem (acee)
>> Sent: 23 October 2018 03:55
>> To: lsr@ietf.org 
>> Subject: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering 
>> Tunnels - draft-ietf-ospf-xaf-te-04.txt
>>  
>> This begins an LSR WG last call for the subject draft. Please send your 
>> comments to this list prior to 12:00 AM GMT, November 13th , 2018. While its 
>> only an 8 page document, I added an extra week due to the IETF. Please let 
>> me know if anyone needs any more time.
>>  
>> 

[Lsr] IETF 103 Preliminary Agenda

[Acee Lindem (acee)]

Please see the IETF 103 Preliminary LSR Agenda:

https://datatracker.ietf.org/meeting/103/materials/agenda-103-lsr-01

Note that we’re going to need to stick to the agenda so please plan your 
presentations accordingly. I see some of the presenters on the agenda who are 
notorious for using all their time and only being on slide 2 – this won’t be 
tolerated at IETF 103.

Thanks,
Acee
___
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-04.txt

[Anton Smirnov]

   Hi Ketan,

1. I am not sure I understood the question. Your example says "using the 
TE topology from OSPFv2 to compute a tunnel". In that case TE router ID 
is an IPv4 address. So no, advertising IPv6 address won't help to 
identify the tunnel.


2. my opinion (not discussed with other authors): RFC 3906 is 
Informational RFC, so it is not mandatory for implementation to follow. 
I think we can insert mention to that RFC somewhere in the Introduction 
but wording should be sufficiently weak (like "one possible example of 
route computation algorithm...").


---
Anton

On 10/24/18 12:06, Ketan Talaulikar (ketant) wrote:


Hello All,

I support this simple but important extension.

A couple of minor comments on the draft:

1)Sec 3 says

   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.  In general, OSPF SHOULD advertise
   the IP address listed in the Router Address TLV [RFC3630 
] [RFC5329 
]

   of the X-AF instance maintaining the MPLS TE database, plus any
   additional local addresses advertised by the X-AF OSPF instance in
   its Node Local Address sub-TLVs.  An implementation MAY advertise
   other local X-AF addresses.

Generally speaking, should the IP address (TE router ID in common 
terms) which is candidate for inclusion in the Router Address TLV not 
be a MUST candidate for X-AF advertisement?


I also have a question about the first statement with the SHOULD in 
it. Consider we are using the TE topology from OSPFv2 to compute a 
tunnel for use with OSPFv3. Any IPv6 addresses associated with the 
OSPFv3 instance on a router would be advertised as a Node attribute 
and would not help identify a specific link. So practically, if any 
IPv6 addresses (if at all) were to be used for CSPF then it would just 
identify the node – in this case, isn’t advertising the IPv6 address 
(TE router ID used in Router Address TLV) sufficient?


For practical deployment, it think it would help if this was clarified 
that we really need only the TE Router ID Address to go X-AF in 
most/general cases and not the others?


2)Isn’t the mapping algorithm in Sec 3 actually going to be used for 
IGP short-cut use-case with its reference to the IGP cost of the 
tunnel? If so, would a reference to rfc3906 be helpful in this document.


Thanks,

Ketan

*From:*Lsr  *On Behalf Of *Acee Lindem (acee)
*Sent:* 23 October 2018 03:55
*To:* lsr@ietf.org
*Subject:* [Lsr] OSPF Routing with Cross-Address Family Traffic 
Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt


This begins an LSR WG last call for the subject draft. Please send 
your comments to this list prior to 12:00 AM GMT, November 13^th , 
2018. While its only an 8 page document, I added an extra week due to 
the IETF. Please let me know if anyone needs any more time.


https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/

Thanks,
Acee



___
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] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt

[Anton Smirnov]

   Hi Gunter,

   we agree with the proposed change and will make it in the next 
revision, probably even rephrase this sentence.


---
Anton


On 10/24/18 12:59, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:


Looks fine. One item I would like to see changed (or at least discussed)

I have a problem with chapter3 – Para6 – Point 1 :

EXISTING:

If T's destination IP address is from the same address family as
the computing OSPF instance,*then the tunnel must have been*
*signaled based on MPLS TE information propagated in the same OSPF*
*instance*.  Process the tunnel as per [RFC3630 
] or [RFC5329 
].

PROPOSED:

If T's destination IP address is from the same address family as
the computing OSPF instance,*then *process the tunnel as per [RFC3630 
] or [RFC5329 
].

MOTIVATION:

I do not understand why to restrict the tunnel to be signaled with 
only info from same OSPF instance. If there is tunnel available 
(different instance, or even other routing protocol), it should be 
able to be used.


G/

*From:*Lsr  *On Behalf Of *Acee Lindem (acee)
*Sent:* Tuesday, October 23, 2018 00:25
*To:* lsr@ietf.org
*Subject:* [Lsr] OSPF Routing with Cross-Address Family Traffic 
Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt


This begins an LSR WG last call for the subject draft. Please send 
your comments to this list prior to 12:00 AM GMT, November 13^th , 
2018. While its only an 8 page document, I added an extra week due to 
the IETF. Please let me know if anyone needs any more time.


https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/

Thanks,
Acee



___
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] Benjamin Kaduk's No Objection on draft-ietf-ospf-lls-interface-id-08: (with COMMENT)

[Acee Lindem (acee)]

Hi Ben, 

On 10/25/18, 8:22 AM, "Benjamin Kaduk"  wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ospf-lls-interface-id-08: 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-lls-interface-id/



--
COMMENT:
--

Sending a new type of information to the peer usually involves a privacy
considerations analysis.  I don't expect there to be anything worrisome
here, but some text in the document indicating that the analysis has been
done would be reassuring.

Can you suggest some text? I was thinking:

   Since the scope of the interface ID is limited to the advertising OSPF 
router 
   uniquely identifying links, there are no privacy concerns associated with its
   advertisement.

Thanks,
Acee





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

[Lsr] Benjamin Kaduk's No Objection on draft-ietf-ospf-lls-interface-id-08: (with COMMENT)

[Benjamin Kaduk]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ospf-lls-interface-id-08: 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-lls-interface-id/



--
COMMENT:
--

Sending a new type of information to the peer usually involves a privacy
considerations analysis.  I don't expect there to be anything worrisome
here, but some text in the document indicating that the analysis has been
done would be reassuring.


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

Re: [Lsr] Martin Vigoureux's No Objection on draft-ietf-ospf-lls-interface-id-08: (with COMMENT)

[Vigoureux, Martin (Nokia - FR/Paris-Saclay)]

This is indeed an absolutely not critical comment. Please address it 
whenever you feel is appropriate.

-m

Le 2018-10-25 à 11:54, Acee Lindem (acee) a écrit :
> Hi Peter, Martin,
> We can address these comments after the draft is IESG approved and on the RFC 
> Editor queue as long as they don't change the normative specifications. I'm 
> hoping this simple and draft which has an existing implementation will be 
> approved.
> Thanks,
> Acee
> 
> On 10/25/18, 4:54 AM, "Peter Psenak (ppsenak)"  wrote:
> 
>  Hi Martin,
>  
>  I have addressed your comment, bu I'm unable to publish the updated
>  version at this point as the submission is closed till November 3rd.
>  
>  thanks,
>  Peter
>  
>  
>  On 23/10/18 11:15 , Martin Vigoureux wrote:
>  > Martin Vigoureux has entered the following ballot position for
>  > draft-ietf-ospf-lls-interface-id-08: 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-lls-interface-id/
>  >
>  >
>  >
>  > --
>  > COMMENT:
>  > --
>  >
>  > Hello,
>  >
>  > thank you for this document. I have only one comment which is picking 
> up a typo:
>  >
>  > s/a way to advertise and use and use them for Generalized Multi-/a way 
> to
>  > advertise and use them for Generalized Multi-/
>  >
>  >
>  > .
>  >
>  
>  
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Martin Vigoureux's No Objection on draft-ietf-ospf-lls-interface-id-08: (with COMMENT)

[Acee Lindem (acee)]

Hi Peter, Martin, 
We can address these comments after the draft is IESG approved and on the RFC 
Editor queue as long as they don't change the normative specifications. I'm 
hoping this simple and draft which has an existing implementation will be 
approved. 
Thanks,
Acee 

On 10/25/18, 4:54 AM, "Peter Psenak (ppsenak)"  wrote:

Hi Martin,

I have addressed your comment, bu I'm unable to publish the updated 
version at this point as the submission is closed till November 3rd.

thanks,
Peter


On 23/10/18 11:15 , Martin Vigoureux wrote:
> Martin Vigoureux has entered the following ballot position for
> draft-ietf-ospf-lls-interface-id-08: 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-lls-interface-id/
>
>
>
> --
> COMMENT:
> --
>
> Hello,
>
> thank you for this document. I have only one comment which is picking up 
a typo:
>
> s/a way to advertise and use and use them for Generalized Multi-/a way to
> advertise and use them for Generalized Multi-/
>
>
> .
>



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

Re: [Lsr] Martin Vigoureux's No Objection on draft-ietf-ospf-lls-interface-id-08: (with COMMENT)

[Peter Psenak]

Hi Martin,

I have addressed your comment, bu I'm unable to publish the updated 
version at this point as the submission is closed till November 3rd.


thanks,
Peter


On 23/10/18 11:15 , Martin Vigoureux wrote:

Martin Vigoureux has entered the following ballot position for
draft-ietf-ospf-lls-interface-id-08: 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-lls-interface-id/



--
COMMENT:
--

Hello,

thank you for this document. I have only one comment which is picking up a typo:

s/a way to advertise and use and use them for Generalized Multi-/a way to
advertise and use them for Generalized Multi-/


.



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