Re: [Lsr] IPR Call for "IS-IS Traffic Engineering (TE) Metric Extensions" - draft-ginsberg-lsr-isis-rfc7810bis-00

2018-04-09 Thread Stefano Previdi 
Hi Acee, all,

I'm not aware of any undisclosed IPR related to this draft.

Thanks.
s.

On Mon, Apr 9, 2018, 9:39 PM Acee Lindem (acee)  wrote:

> Authors,
>
>
>
> Are you aware of any IPR that applies to
> draft-ginsberg-lsr-isis-rfc7810bis-00 in addition to the IPR declared on
> RFC 7810:
>
>
>
>
> https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-isis-te-metric-extensions
>
>
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules (see
> RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as a document author or contributor please respond to
> this email regardless of whether or not you are aware of any relevant IPR.
> *The response needs to be sent to the LSR WG mailing list.* The document
> will not advance to the next stage until a response has been received from
> each author and contributor.
>
>
>
> If you are on the LSR WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of any
> IPR that has not yet been disclosed in conformance with IETF rules.
>
>
>
> Thanks,
>
> Acee
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Call for "IS-IS Traffic Engineering (TE) Metric Extensions" - draft-ginsberg-lsr-isis-rfc7810bis-00

2018-04-09 Thread Les Ginsberg (ginsberg) 
I am not aware of any undisclosed IPR.

Les

From: Acee Lindem (acee)
Sent: Monday, April 09, 2018 12:39 PM
To: draft-ginsberg-lsr-isis-rfc7810...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Call for "IS-IS Traffic Engineering (TE) Metric Extensions" - 
draft-ginsberg-lsr-isis-rfc7810bis-00

Authors,

Are you aware of any IPR that applies to draft-ginsberg-lsr-isis-rfc7810bis-00 
in addition to the IPR declared on RFC 7810:

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-isis-te-metric-extensions

If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond to this 
email regardless of whether or not you are aware of any relevant IPR. *The 
response needs to be sent to the LSR WG mailing list.* The document will not 
advance to the next stage until a response has been received from each author 
and contributor.

If you are on the LSR WG email list but are not listed as an author or 
contributor, then please explicitly respond only if you are aware of any IPR 
that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee

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

[Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-10.txt

2018-04-09 Thread internet-drafts 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Signaling MSD (Maximum SID Depth) using IS-IS
Authors : Jeff Tantsura
  Uma Chunduri
  Sam Aldrin
  Les Ginsberg
Filename: draft-ietf-isis-segment-routing-msd-10.txt
Pages   : 9
Date: 2018-04-09

Abstract:
   This document defines a way for an IS-IS Router to advertise multiple
   types of supported Maximum SID Depths (MSDs) at node and/or link
   granularity.  Such advertisements allow entities (e.g., centralized
   controllers) to determine whether a particular SID stack can be
   supported in a given network.  This document only defines one type of
   MSD maximum label imposition, but defines an encoding that can
   support other MSD types.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-msd-10
https://datatracker.ietf.org/doc/html/draft-ietf-isis-segment-routing-msd-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-segment-routing-msd-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" between OSPF and ISIS extension for Segment Routing

2018-04-09 Thread Ketan Talaulikar (ketant) 
Hi Aijun,

As responded previously and also clarified by few others, the 3 IGP protocols 
(ISIS, OSPFv2 and OSPFv3) and BGP-LS are different protocols. Their encodings 
need not be identical. However, their semantics generally are so when it comes 
mapping them into BGP-LS.

At this stage, given the advance state of implementations and deployments for 
all these IGP and BGP-LS drafts involved, I don’t think we can undertake such 
“cosmetic” changes.

However, the draft-ietf-idr-bgp-ls-segment-routing-ext-04 is in WGLC and I can 
definitely take your feedback for any updates in the text or clarifications 
necessary in this document. Note that the procedures for the TLVs where 
mappings were non-trivial are described in the Procedures section - 
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-04#section-3
 . The TLVs you mention below are very trivial and the mapping from IGPs to 
BGP-LS is straightforward so the authors believe the explanation in Section 2 
where each TLV field is described is sufficient.

In the end, I am not sure if any of this helps/addresses implementation defects 
(where the reserved field itself was skipped from the BGP-LS TLV) that you have 
identified in your deployment on the producer side.

Thanks,
Ketan

From: Aijun Wang 
Sent: 08 April 2018 07:02
To: Ketan Talaulikar (ketant) 
Cc: 'Jeffrey Haas' ; lsr@ietf.org; i...@ietf.org
Subject: 答复: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" 
between OSPF and ISIS extension for Segment Routing

Hi, Ketan:

I think there is another reason that causes this semantic error-that is 
there is many similarities for the definition of “Adj-SID Sub-TLV” for ISIS and 
OSPFv3 in the following draft:
https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions-11#section-6.1
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-15#section-2.2.1

but there is no any description in the relevant paragraph to  distinguish them 
in BGP-LS document.
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-04#section-2.2.1


Ketan explained that “ISIS uses 1 byte for type/length and has LSP space 
constraints which you would notice in  the protocol encodings. OSPF doesn’t 
have the same challenge and you would notice how its TLVs tend to be aligned. 
BGP-LS is somewhat similar to OSPF from these size constraints perspective.” 
But when I compared another TLV definition “SRMS Preference TLV” in randomly, I 
found the definition in BGP-LS is different from that both in ISIS and 
OSPFv3.(include the “length” field and “reserved” field) I don’t know there are 
how many inconsistence among them and think this will induce other 
inconsistencies when the vendor implements the BGP-LS protocol.



Can we align these definitions as consistence as possible among them? Or add 
clear distinguish statements for the different IGP protocol?

The consumer can add some detections for such kind semantic errors but the 
better is not to produce them.



Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
发件人: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
发送时间: 2018年4月4日 15:54
收件人: Aijun Wang
抄送: Jeffrey Haas; lsr@ietf.org; 
i...@ietf.org
主题: Re: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" 
between OSPF and ISIS extension for Segment Routing

< including IDR WG where BGP-LS work is being done >

Hi Aijun,

As discussed offline, this is a bug in this particular implementation where it 
is not following the spec properly.

This goes back to the discussion in the IDR WG about the semantic and syntactic 
validation for BGP-LS messages which Jeff had brought up. In this case, my 
understanding was that there was a semantic error in this TLV encoding? The 
consumer (application/BGP speaker) in this case should detect and ignore this 
update – which is what was being done as well in this case?

Thanks,
Ketan

From: Aijun Wang >
Sent: 04 April 2018 07:50
To: 'stefano previdi' >; Peter 
Psenak (ppsenak) >
Cc: lsr@ietf.org; Ketan Talaulikar (ketant) 
>; Acee Lindem (acee) 
>
Subject: 答复: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" 
between OSPF and ISIS extension for Segment Routing


Hi, All:



We have found some inconsistencies for the implementation of BGP-LS protocol 
regarding this “Adj-SID SubTLV ”, please see the following screenshot.

I think we should do some works for the related drafts to clarify this 
ambiguous/easy to be ignored definition.



[cid:image001.png@01D3D00B.E16819F0]



Best