Re: [Lsr] IPR Call for draft-ietf-ospf-xaf-te - "OSPF Routing with Cross-Address Family Traffic Engineering Tunnes"

[Michael Barnes]

I am not aware of any IPR related to this document.

Regards,
Michael

On 10/30/2018 10:26 AM, Acee Lindem (acee) wrote:
In preparation for requesting publication, I’m making a second IPR call 
on the subject document.


Are you aware of any IPR that applies to draft-ietf-ospf-xaf-te?

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


There are currently no IPR disclosures against draft-ietf-ospf-xaf-te-04.

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 draft-ietf-ospf-xaf-te - "OSPF Routing with Cross-Address Family Traffic Engineering Tunnes"

[Alvaro Retana]

I am not aware of any IPR related to this document.

Alvaro.


On October 30, 2018 at 1:26:55 PM, Acee Lindem (acee) 
(a...@cisco.com) wrote:
In preparation for requesting publication, I’m making a second IPR call on the 
subject document.

Are you aware of any IPR that applies to draft-ietf-ospf-xaf-te?

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

There are currently no IPR disclosures against draft-ietf-ospf-xaf-te-04.

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] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16

[Peter Psenak]

Hi Joe,

On 31/10/18 04:15 , Joe Clarke wrote:

On 10/30/18 08:05, Peter Psenak wrote:


I'm going to be pedantic here.  According to RFC7770, when a new OSPF
Router
Information LSA TLV is defined, the spec needs to explicitly state if
it's
applicable to OSPFv2, v3, or both.  While you reference the TLVs from
draft-ietf-ospf-segment-routing-extensions, I didn't see that either
document
_explicitly_ states that they are applicable to both.


##PP
added the following to each of the values:

Type: X as defined in [I-D.ietf-ospf-segment-routing-extensions] and
aplicable to OSPFv3.


Thanks.  But s/aplicable/applicable/ :-)


fixed :)






Section 3.2

"When a router receives multiple overlapping ranges, it MUST
conform to the procedures defined in
[I-D.ietf-spring-segment-routing-mpls]."

It would be useful to include a section pointer here.  I think your
referring
to Section 2.3 where the router ignores the range?   Is it likely that
will
change to something other than "ignore?"  If not, maybe it's just worth
mentioning that here.


##PP
I don't think it is good to specify the behavior which is described
somewhere else. Regarding the section, the
ietf-spring-segment-routing-mpls is still being worked on and the
section may changes. We used the same text in OSPFv2 and ISIS SR drafts.
I would like to be consistent here.


I can agree that copying might be problematic.  But I think a section
ref is good here.  Finding the specific part about "overlapping" in this
document is kind of like a needle in a haystack.  I think it will add to
overall readability.


added the section reference.





Section 3.3

"The originating router MUST NOT advertise overlapping ranges."

You specify what a router should do if it receives overlapping ranges
above.  I
think the same text should be used here, too.


##PP
Here we say that the originating router MUST NOT advertise overlapping
ranges. We can not specify what it should do when it breaks the MUST.


I meant you have used text as to what happens when a router receives
data it should ignore in other parts.  I was asking to use similar text
here.



We specify what other routers should do when they receive overlapping
ranges and we refer it to spring-segment-routing-mpls draft. Again this
is the same as we used in OSPFv3 and ISIS SR extensions. I would like to
keep the consistency here.


Right.  But you don't re-reference that text here.  Again, I'm just
asking for consistent text that references the
spring-segment-routing-mpls drafts.


got it and updated the text.

thanks,
Peter


Joe
.



___
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)

[Peter Psenak]

Hi Ben, Acee,

On 31/10/18 02:26 , Benjamin Kaduk wrote:

On Wed, Oct 31, 2018 at 01:21:14AM +, Acee Lindem (acee) wrote:

Hi Ben,

On 10/30/18, 9:09 PM, "Benjamin Kaduk"  wrote:

 On Tue, Oct 30, 2018 at 02:28:12PM +, Acee Lindem (acee) wrote:
 > Hi Ben,
 >
 > On 10/30/18, 10:08 AM, "Benjamin Kaduk"  wrote:
 >
 > Hi Acee,
 >
 > On Thu, Oct 25, 2018 at 01:51:42PM +, Acee Lindem (acee) wrote:
 > > 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:
 >
 > I'm not sure that I could -- I don't have confidence that I 
understand the
 > system well enough to frame something in a complete and correct way.
 >
 > >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.
 >
 > I wonder if there is a step missing to link these together -- that 
the
 > links are generally fixed and immobile, or that the scope of 
distribution
 > is limited to a set of trusted peers, perhaps?
 >
 > The point I'm making is that since the interface ID is only unique for 
the network device, it doesn't provide any clue as to the identity of the device 
owner or traffic transiting the device. Hence, there are no privacy considerations 
associated with extension. It is also true that routing peers are trusted but that 
is a moot point for this extension In the context of privacy.

 Ah, I see; thanks.  How does "The interface ID is locally assigned by the
 advertising OSPF router as a uniquifier and need not be unique in any
 broader context; it is not expected to contain any information about the
 device owner or traffic transiting the device, so there are no privacy
 concerns associated with its advertisement." sound?

Sure - that is clearer. In fact, I realized that it wasn't obvious after explaining it in 
my last Email. I'd avoid "uniquifier" since it isn't in the dictionary yielding:

 The interface ID is assigned by the advertising OSPF router as a locally
 unique identifier and need not be unique in any broader context; it is
 not expected to contain any information about the device owner or
 traffic transiting the device, so there are no privacy concerns
 associated with its advertisement.


Ship it! :)



updated the draft, will submit as soon as the submission reopens.

thanks,
Peter



Thanks,

Benjamin
.



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