Re: [Lsr] I-D Action: draft-ietf-isis-te-app-15.txt

[Murray S. Kucherawy]

Hi Les,

Sorry for missing that.  There's often a torrent of email right before
a telechat and this got lost in there.

On Thu, Jun 11, 2020 at 11:19 AM Les Ginsberg (ginsberg)
 wrote:
> [Les:] IS-IS registries are guided by RFC 7370 (referenced in Section 7 and 
> in 
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml
>   ) - which does provide guidance to the experts.
> There is some additional guidance in Section 7.3 because we want codepoints 
> in the existing "sub-TLV of TLVs 22, 23, 25, 141, 222, and 223" registry to 
> be in sync with the new registry whenever possible.
> For Section 7.5 there really isn’t anything else to say beyond what RFC 7370 
> says.

Apologies, you're correct.  I didn't connect the text in Section 7
with 7.5 for some reason.  I think I was simply struck by the fact
that 7.3 was explicit while 7.5 wasn't.

I'll update my position now.  Thank you for setting me straight.

-MSK

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

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Sarah Chen]

I am not aware of any other related IPR, except for the one Tony mentioned:
https://datatracker.ietf.org/ipr/4016/ .

Thanks,
Sarah

On Thu, Jun 11, 2020 at 12:46 PM Acee Lindem (acee)  wrote:

> Thanks Sarah – as a co-author, please state your awareness of IPR..
>
> Acee
>
>
>
> *From: *Sarah Chen 
> *Date: *Thursday, June 11, 2020 at 2:34 PM
> *To: *Robert Raszuk 
> *Cc: *Christian Hopps , "lsr@ietf.org" ,
> "lsr-...@ietf.org" , "lsr-cha...@ietf.org" <
> lsr-cha...@ietf.org>
> *Subject: *Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06
> *Resent-From: *
> *Resent-To: *Christian Hopps , Acee Lindem <
> a...@cisco.com>, Yingzhen Qu 
> *Resent-Date: *Thursday, June 11, 2020 at 2:33 PM
>
>
>
> Support, as co-author.
>
>
>
> Thanks,
>
> Sarah
>
>
>
> On Thu, Jun 11, 2020 at 2:33 AM Robert Raszuk  wrote:
>
> Support.
>
>
>
> Thx,
>
> R.
>
>
>
> On Wed, Jun 10, 2020 at 9:28 PM Christian Hopps  wrote:
>
> This begins a 2 week WG adoption call for the following draft:
>
>   https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/
>
> The draft would be adopted on the Experimental track.
>
> Please indicate your support or objection by June 24, 2020.
>
> Authors, please respond to the list indicating whether you are aware of
> any IPR that applies to this draft.
>
> Thanks,
> Chris and 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
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Les Ginsberg (ginsberg)]

Ben -

Sorry - there was a typo - correct specification number is ISO 10589.
It is freely available here: 
https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html 

   Les

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Thursday, June 11, 2020 1:01 PM
> To: Les Ginsberg (ginsberg) 
> Cc: The IESG ; draft-ietf-isis-te-...@ietf.org; lsr-
> cha...@ietf.org; lsr@ietf.org; Acee Lindem (acee) ;
> aretana.i...@gmail.com
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with
> DISCUSS and COMMENT)
> 
> Hi Les,
> 
> On Thu, Jun 11, 2020 at 04:48:00PM +, Les Ginsberg (ginsberg) wrote:
> > Benjamin -
> >
> >
> >
> > Thanx for your review.
> >
> > Responses inline.
> >
> >
> >
> > > -Original Message-
> >
> > > From: Benjamin Kaduk via Datatracker 
> >
> > > Sent: Thursday, June 11, 2020 12:42 AM
> >
> > > To: The IESG 
> >
> > > Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; 
> > > Acee
> >
> > > Lindem (acee) ; aretana.i...@gmail.com; Acee Lindem
> >
> > > (acee) 
> >
> > > Subject: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with
> DISCUSS
> >
> > > and COMMENT)
> >
> > >
> >
> > > Benjamin Kaduk has entered the following ballot position for
> >
> > > draft-ietf-isis-te-app-14: Discuss
> >
> > >
> >
> > > 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-isis-te-app/
> >
> > >
> >
> > >
> >
> > >
> >
> > > --
> >
> > > DISCUSS:
> >
> > > --
> >
> > >
> >
> > > My apologies if this is super-obvious and I'm just missing it ... but
> >
> > > Section 4.3 dictates that part of the value for the application-specific
> >
> > > SRLG TLV is a "Neighbor System-ID + pseudo-node ID (7 octets)".  Where
> >
> > > are these defined?  (We don't exactly say that we're reusing the
> structure
> >
> > > from, e.g., TLV 138, which I note refers to the seventh octet as
> >
> > > "pseudonode number", not "pseudo-node ID".  Similarly for the
> >
> > > interpretation of the SRLG value(s).  Do we just need to reference that
> >
> > > we're reusing the encoding from RFC 5307 (or similar) or are some
> >
> > > changes needed?
> >
> > >
> >
> > [Les:] “system ID” and “pseudo-node ID” derive from the IS-IS base
> specification [ISO 19589]
> 
> Ah, so definitely "super-obvious", and just a consequence of my never
> actually getting my hands on a copy of ISO 19589 (obvious paths seem to ask
> for 200 CHF).
> 
> Sorry for the noise; I will go clear now (and will respond to the comment
> section later).
> 
> -Ben
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi Les,

On Thu, Jun 11, 2020 at 04:48:00PM +, Les Ginsberg (ginsberg) wrote:
> Benjamin -
> 
> 
> 
> Thanx for your review.
> 
> Responses inline.
> 
> 
> 
> > -Original Message-
> 
> > From: Benjamin Kaduk via Datatracker 
> 
> > Sent: Thursday, June 11, 2020 12:42 AM
> 
> > To: The IESG 
> 
> > Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee
> 
> > Lindem (acee) ; aretana.i...@gmail.com; Acee Lindem
> 
> > (acee) 
> 
> > Subject: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with 
> > DISCUSS
> 
> > and COMMENT)
> 
> >
> 
> > Benjamin Kaduk has entered the following ballot position for
> 
> > draft-ietf-isis-te-app-14: Discuss
> 
> >
> 
> > 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-isis-te-app/
> 
> >
> 
> >
> 
> >
> 
> > --
> 
> > DISCUSS:
> 
> > --
> 
> >
> 
> > My apologies if this is super-obvious and I'm just missing it ... but
> 
> > Section 4.3 dictates that part of the value for the application-specific
> 
> > SRLG TLV is a "Neighbor System-ID + pseudo-node ID (7 octets)".  Where
> 
> > are these defined?  (We don't exactly say that we're reusing the structure
> 
> > from, e.g., TLV 138, which I note refers to the seventh octet as
> 
> > "pseudonode number", not "pseudo-node ID".  Similarly for the
> 
> > interpretation of the SRLG value(s).  Do we just need to reference that
> 
> > we're reusing the encoding from RFC 5307 (or similar) or are some
> 
> > changes needed?
> 
> >
> 
> [Les:] “system ID” and “pseudo-node ID” derive from the IS-IS base 
> specification [ISO 19589]

Ah, so definitely "super-obvious", and just a consequence of my never
actually getting my hands on a copy of ISO 19589 (obvious paths seem to ask
for 200 CHF).

Sorry for the noise; I will go clear now (and will respond to the comment
section later).

-Ben

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

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Acee Lindem (acee)]

Thanks Sarah – as a co-author, please state your awareness of IPR.
Acee

From: Sarah Chen 
Date: Thursday, June 11, 2020 at 2:34 PM
To: Robert Raszuk 
Cc: Christian Hopps , "lsr@ietf.org" , 
"lsr-...@ietf.org" , "lsr-cha...@ietf.org" 

Subject: Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06
Resent-From: 
Resent-To: Christian Hopps , Acee Lindem , 
Yingzhen Qu 
Resent-Date: Thursday, June 11, 2020 at 2:33 PM

Support, as co-author.

Thanks,
Sarah

On Thu, Jun 11, 2020 at 2:33 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Support.

Thx,
R.

On Wed, Jun 10, 2020 at 9:28 PM Christian Hopps 
mailto:cho...@chopps.org>> wrote:
This begins a 2 week WG adoption call for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/

The draft would be adopted on the Experimental track.

Please indicate your support or objection by June 24, 2020.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and 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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

[Jordan Head]

Support.

The draft identifies and addresses the problem, and quite cleanly I might add.

Jordan Head

On 6/10/20, 3:29 PM, "Lsr on behalf of Christian Hopps"  wrote:

[External Email. Be cautious of content]


This begins a 2 week WG adoption call for the following draft:

  
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection__;!!NEt6yMaO-gk!WcIjGwXb7biFdhbdSv8WhQa86HqfdhAiVT-T4gE68NjQ9_Uii9O_HMCdksRshic$

The draft would be adopted on the Experimental track.

Please indicate your support or objection by June 24, 2020.

Authors, please respond to the list indicating whether you are aware of any 
IPR that applies to this draft.

Thanks,
Chris and Acee.
___
Lsr mailing list
Lsr@ietf.org

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!WcIjGwXb7biFdhbdSv8WhQa86HqfdhAiVT-T4gE68NjQ9_Uii9O_HMCdWR4R6q4$


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

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Sarah Chen]

Support, as co-author.

Thanks,
Sarah

On Thu, Jun 11, 2020 at 2:33 AM Robert Raszuk  wrote:

> Support.
>
> Thx,
> R.
>
> On Wed, Jun 10, 2020 at 9:28 PM Christian Hopps  wrote:
>
>> This begins a 2 week WG adoption call for the following draft:
>>
>>   https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/
>>
>> The draft would be adopted on the Experimental track.
>>
>> Please indicate your support or objection by June 24, 2020.
>>
>> Authors, please respond to the list indicating whether you are aware of
>> any IPR that applies to this draft.
>>
>> Thanks,
>> Chris and 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
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] I-D Action: draft-ietf-isis-te-app-15.txt

[Les Ginsberg (ginsberg)]

Murray -

You never replied to my response to your comments - otherwise we could have 
continued the discussion in that thread.

What I replied there on this point was:

[Les:] IS-IS registries are guided by RFC 7370 (referenced in Section 7 and in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml  
) - which does provide guidance to the experts.
There is some additional guidance in Section 7.3 because we want codepoints in 
the existing "sub-TLV of TLVs 22, 23, 25, 141, 222, and 223" registry to be in 
sync with the new registry whenever possible.
For Section 7.5 there really isn’t anything else to say beyond what RFC 7370 
says.

   Les


> -Original Message-
> From: Murray S. Kucherawy 
> Sent: Thursday, June 11, 2020 11:05 AM
> To: Les Ginsberg (ginsberg) 
> Cc: lsr@ietf.org; Martin Duke ; Rob Wilton
> (rwilton) ; Roman Danyliw ; Deborah
> Brungard ; Benjamin Kaduk 
> Subject: Re: [Lsr] I-D Action: draft-ietf-isis-te-app-15.txt
> 
> Hi Les,
> 
> I'm afraid I don't see how this revision resolves my DISCUSS point,
> which is that Section 7.5 creates a registry under "Expert Review"
> terms; BCP 26 pushes the point that such a registry definition should
> include guidance to the Designated Expert about how to handle new
> applications, but Section 7.5 doesn't.
> 
> On the other hand, Section 7.3 gets this right; note its last paragraph.
> 
> For that matter, BCP 26 recommends including a "Change Controller"
> column, but neither registry created here does so.  Is that
> intentional?
> 
> https://tools.ietf.org/html/bcp26#section-4.5
> 
> -MSK
> 
> On Thu, Jun 11, 2020 at 10:16 AM Les Ginsberg (ginsberg)
>  wrote:
> >
> > Folks -
> >
> > This update to the draft addresses comments from the following IESG
> reviewers:
> >
> > Murray Kucherawy
> > Martin Duke
> > Rob Wilton
> > Roman Danyliw
> > Deborah Brungard
> > Benjamin Kaduk
> >
> > It also includes grammatical corrections related to the use of "which/that".
> >
> > A special thank you to Acee Lindem for his tireless efforts to improve my
> grammar.
> >
> >   Les
> >
> > > -Original Message-
> > > From: Lsr  On Behalf Of internet-dra...@ietf.org
> > > Sent: Thursday, June 11, 2020 10:06 AM
> > > To: i-d-annou...@ietf.org
> > > Cc: lsr@ietf.org
> > > Subject: [Lsr] I-D Action: draft-ietf-isis-te-app-15.txt
> > >
> > >
> > > 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   : IS-IS TE Attributes per application
> > > Authors : Les Ginsberg
> > >   Peter Psenak
> > >   Stefano Previdi
> > >   Wim Henderickx
> > >   John Drake
> > >   Filename: draft-ietf-isis-te-app-15.txt
> > >   Pages   : 21
> > >   Date: 2020-06-11
> > >
> > > Abstract:
> > >Existing traffic engineering related link attribute advertisements
> > >have been defined and are used in RSVP-TE deployments.  Since the
> > >original RSVP-TE use case was defined, additional applications (e.g.,
> > >Segment Routing Policy, Loop Free Alternate) that also make use of
> > >the link attribute advertisements have been defined . In cases where
> > >multiple applications wish to make use of these link attributes, the
> > >current advertisements do not support application specific values for
> > >a given attribute, nor do they support indication of which
> > >applications are using the advertised value for a given link.  This
> > >document introduces new link attribute advertisements that address
> > >both of these shortcomings.
> > >
> > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/
> > >
> > > There are also htmlized versions available at:
> > > https://tools.ietf.org/html/draft-ietf-isis-te-app-15
> > > https://datatracker.ietf.org/doc/html/draft-ietf-isis-te-app-15
> > >
> > > A diff from the previous version is available at:
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-te-app-15
> > >
> > >
> > > 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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

[Christian Hopps]

As you are an author please provide the requested feedback on IPR.

Thanks,
Chris.

> On Jun 11, 2020, at 1:19 PM, Lee, Yiu  wrote:
> 
> Supported previously and support now to adopt this draft as Experimental 
> track.
> 
> On 6/10/20, 3:28 PM, "Lsr on behalf of Christian Hopps" 
>  wrote:
> 
>This begins a 2 week WG adoption call for the following draft:
> 
>  
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection__;!!CQl3mcHX2A!Wvc4ZhBJ0lg7kMhLROfmvJ9oqsIFnxb7RxEonglDJO1hoOcohBd0gTK9G2SBpfU$
> 
>The draft would be adopted on the Experimental track.
> 
>Please indicate your support or objection by June 24, 2020.
> 
>Authors, please respond to the list indicating whether you are aware of 
> any IPR that applies to this draft.
> 
>Thanks,
>Chris and Acee.
>___
>Lsr mailing list
>Lsr@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!CQl3mcHX2A!Wvc4ZhBJ0lg7kMhLROfmvJ9oqsIFnxb7RxEonglDJO1hoOcohBd0gTK98dpWojk$
> 

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

Re: [Lsr] I-D Action: draft-ietf-isis-te-app-15.txt

[Murray S. Kucherawy]

Hi Les,

I'm afraid I don't see how this revision resolves my DISCUSS point,
which is that Section 7.5 creates a registry under "Expert Review"
terms; BCP 26 pushes the point that such a registry definition should
include guidance to the Designated Expert about how to handle new
applications, but Section 7.5 doesn't.

On the other hand, Section 7.3 gets this right; note its last paragraph.

For that matter, BCP 26 recommends including a "Change Controller"
column, but neither registry created here does so.  Is that
intentional?

https://tools.ietf.org/html/bcp26#section-4.5

-MSK

On Thu, Jun 11, 2020 at 10:16 AM Les Ginsberg (ginsberg)
 wrote:
>
> Folks -
>
> This update to the draft addresses comments from the following IESG reviewers:
>
> Murray Kucherawy
> Martin Duke
> Rob Wilton
> Roman Danyliw
> Deborah Brungard
> Benjamin Kaduk
>
> It also includes grammatical corrections related to the use of "which/that".
>
> A special thank you to Acee Lindem for his tireless efforts to improve my 
> grammar.
>
>   Les
>
> > -Original Message-
> > From: Lsr  On Behalf Of internet-dra...@ietf.org
> > Sent: Thursday, June 11, 2020 10:06 AM
> > To: i-d-annou...@ietf.org
> > Cc: lsr@ietf.org
> > Subject: [Lsr] I-D Action: draft-ietf-isis-te-app-15.txt
> >
> >
> > 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   : IS-IS TE Attributes per application
> > Authors : Les Ginsberg
> >   Peter Psenak
> >   Stefano Previdi
> >   Wim Henderickx
> >   John Drake
> >   Filename: draft-ietf-isis-te-app-15.txt
> >   Pages   : 21
> >   Date: 2020-06-11
> >
> > Abstract:
> >Existing traffic engineering related link attribute advertisements
> >have been defined and are used in RSVP-TE deployments.  Since the
> >original RSVP-TE use case was defined, additional applications (e.g.,
> >Segment Routing Policy, Loop Free Alternate) that also make use of
> >the link attribute advertisements have been defined . In cases where
> >multiple applications wish to make use of these link attributes, the
> >current advertisements do not support application specific values for
> >a given attribute, nor do they support indication of which
> >applications are using the advertised value for a given link.  This
> >document introduces new link attribute advertisements that address
> >both of these shortcomings.
> >
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-isis-te-app-15
> > https://datatracker.ietf.org/doc/html/draft-ietf-isis-te-app-15
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-te-app-15
> >
> >
> > 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

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

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

[Lee, Yiu]

Supported previously and support now to adopt this draft as Experimental track.

On 6/10/20, 3:28 PM, "Lsr on behalf of Christian Hopps"  wrote:

This begins a 2 week WG adoption call for the following draft:

  
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection__;!!CQl3mcHX2A!Wvc4ZhBJ0lg7kMhLROfmvJ9oqsIFnxb7RxEonglDJO1hoOcohBd0gTK9G2SBpfU$

The draft would be adopted on the Experimental track.

Please indicate your support or objection by June 24, 2020.

Authors, please respond to the list indicating whether you are aware of any 
IPR that applies to this draft.

Thanks,
Chris and Acee.
___
Lsr mailing list
Lsr@ietf.org

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!CQl3mcHX2A!Wvc4ZhBJ0lg7kMhLROfmvJ9oqsIFnxb7RxEonglDJO1hoOcohBd0gTK98dpWojk$

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

Re: [Lsr] I-D Action: draft-ietf-isis-te-app-15.txt

[Les Ginsberg (ginsberg)]

Folks -

This update to the draft addresses comments from the following IESG reviewers:

Murray Kucherawy
Martin Duke
Rob Wilton
Roman Danyliw
Deborah Brungard
Benjamin Kaduk

It also includes grammatical corrections related to the use of "which/that".

A special thank you to Acee Lindem for his tireless efforts to improve my 
grammar.

  Les

> -Original Message-
> From: Lsr  On Behalf Of internet-dra...@ietf.org
> Sent: Thursday, June 11, 2020 10:06 AM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-isis-te-app-15.txt
> 
> 
> 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   : IS-IS TE Attributes per application
> Authors : Les Ginsberg
>   Peter Psenak
>   Stefano Previdi
>   Wim Henderickx
>   John Drake
>   Filename: draft-ietf-isis-te-app-15.txt
>   Pages   : 21
>   Date: 2020-06-11
> 
> Abstract:
>Existing traffic engineering related link attribute advertisements
>have been defined and are used in RSVP-TE deployments.  Since the
>original RSVP-TE use case was defined, additional applications (e.g.,
>Segment Routing Policy, Loop Free Alternate) that also make use of
>the link attribute advertisements have been defined . In cases where
>multiple applications wish to make use of these link attributes, the
>current advertisements do not support application specific values for
>a given attribute, nor do they support indication of which
>applications are using the advertised value for a given link.  This
>document introduces new link attribute advertisements that address
>both of these shortcomings.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-isis-te-app-15
> https://datatracker.ietf.org/doc/html/draft-ietf-isis-te-app-15
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-te-app-15
> 
> 
> 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

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

[Lsr] I-D Action: draft-ietf-isis-te-app-15.txt

[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   : IS-IS TE Attributes per application
Authors : Les Ginsberg
  Peter Psenak
  Stefano Previdi
  Wim Henderickx
  John Drake
Filename: draft-ietf-isis-te-app-15.txt
Pages   : 21
Date: 2020-06-11

Abstract:
   Existing traffic engineering related link attribute advertisements
   have been defined and are used in RSVP-TE deployments.  Since the
   original RSVP-TE use case was defined, additional applications (e.g.,
   Segment Routing Policy, Loop Free Alternate) that also make use of
   the link attribute advertisements have been defined . In cases where
   multiple applications wish to make use of these link attributes, the
   current advertisements do not support application specific values for
   a given attribute, nor do they support indication of which
   applications are using the advertised value for a given link.  This
   document introduces new link attribute advertisements that address
   both of these shortcomings.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-isis-te-app-15
https://datatracker.ietf.org/doc/html/draft-ietf-isis-te-app-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-te-app-15


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] Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Les Ginsberg (ginsberg)]

Benjamin -



Thanx for your review.

Responses inline.



> -Original Message-

> From: Benjamin Kaduk via Datatracker 

> Sent: Thursday, June 11, 2020 12:42 AM

> To: The IESG 

> Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee

> Lindem (acee) ; aretana.i...@gmail.com; Acee Lindem

> (acee) 

> Subject: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS

> and COMMENT)

>

> Benjamin Kaduk has entered the following ballot position for

> draft-ietf-isis-te-app-14: Discuss

>

> 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-isis-te-app/

>

>

>

> --

> DISCUSS:

> --

>

> My apologies if this is super-obvious and I'm just missing it ... but

> Section 4.3 dictates that part of the value for the application-specific

> SRLG TLV is a "Neighbor System-ID + pseudo-node ID (7 octets)".  Where

> are these defined?  (We don't exactly say that we're reusing the structure

> from, e.g., TLV 138, which I note refers to the seventh octet as

> "pseudonode number", not "pseudo-node ID".  Similarly for the

> interpretation of the SRLG value(s).  Do we just need to reference that

> we're reusing the encoding from RFC 5307 (or similar) or are some

> changes needed?

>

[Les:] “system ID” and “pseudo-node ID” derive from the IS-IS base 
specification [ISO 19589]



>

> --

> COMMENT:

> --

>

> What is the scope over which the user-defined application bits are

> defined/allocated?



[Les:] Sorry – I do not understand this question.



>

> And, a general question, just to check my understanding: if I do need to

> specify different values of a given attribute for different

> applications, I do that by putting multiple copies of the new sub-TLV in

> TLV 22/23/etc., with the flags set according to which application the

> contained attributes apply to?  (Mostly I ask because I forget what the

> rules are for having multiple instances of a given TLV/sub-TLV as

> siblings in the same container.)

>

[Les:] You are correct.

Whether multiple occurrences of the same sub-TLV is allowed is codepoint 
specific.

Section 4.2 states:



“Multiple Application Specific Link Attribute sub-TLVs for the same

   link MAY be advertised.”



> Section 3.1

>

> Maybe mention (again, I know) that this is only the subset of sub-TLVs

> that are used for RSVP-TE?



[Les:] The point of Section 3.1 is to list the legacy sub-TLVs which are 
relevant to this draft. There are other sub-TLVs defined in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223

which are not relevant – but categorizing them as “not used by RSVP-TE” 
wouldn’t be completely accurate. For example, endpoint addresses (codepoints 
6,8,12,13) are quite relevant to RSVP-TE as they are required to uniquely 
identify the link – but they aren’t in the set of sub-sub-TLVs being defined.



>

> Section 4.2

>

>When the L-flag is set in the Application Identifier Bit Mask, all of

>the applications specified in the bit mask MUST use the legacy

>advertisements for the corresponding link found in TLVs 22, 23, 25,

>141, 222, and 223 or TLV 138 or TLV 139 as appropriate.  Link

>

> nit(?): is this "found in sub-TLVs of TLVs 22, [...]"?

[Les:] The top level TLVs are the containers in which link advertisements are 
present. A given link advertisement consists of the fixed portion of the TLV 
and a set of sub-TLVs.

I think the existing text is correct.



>

>attribute sub-sub-TLVs for the corresponding link attributes MUST NOT

>be advertised for the set of applications specified in the Standard/

>User Application Identifier Bit Masks and all such advertisements

>MUST be ignored on receipt.

>

> Does this apply to just the (sub-)TLV with the L-flag set, or to other

> instances of that (sub-)TLV as well?

>

[Les:] The scope is the set of sub-TLVs associated with the same link and the 
same application(s).



>For a given application, the setting of the L-flag MUST be the same

>in all sub-TLVs for a given link.  In cases where this constraint is

>violated, the L-flag MUST be considered set for this application.

>

> editorial: I suggest "the L-flag MUST be considered set for this

> application for all sub-TLVs on the link in 

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

[Melchior Aelmans]

Hi,

As stated previously I support adoption of this draft.

Cheers,
Melchior

On Wed, Jun 10, 2020 at 9:29 PM Christian Hopps  wrote:

> This begins a 2 week WG adoption call for the following draft:
>
>   https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection
>
> The draft would be adopted on the Experimental track.
>
> Please indicate your support or objection by June 24, 2020.
>
> Authors, please respond to the list indicating whether you are aware of
> any IPR that applies to this draft.
>
> Thanks,
> Chris and 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] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Les Ginsberg (ginsberg)]

Deborah -



Thanx for your review.

Responses inline.



> -Original Message-

> From: Deborah Brungard via Datatracker 

> Sent: Wednesday, June 10, 2020 3:17 PM

> To: The IESG 

> Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee

> Lindem (acee) ; aretana.i...@gmail.com; Acee Lindem

> (acee) 

> Subject: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with

> DISCUSS and COMMENT)

>

> Deborah Brungard has entered the following ballot position for

> draft-ietf-isis-te-app-14: Discuss

>

> 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-isis-te-app/

>

>

>

> --

> DISCUSS:

> --

>

> This should be simple to resolve - the use of the SR-TE term is

> out-of-alignment with other drafts, spring and idr. Suggest: Segment Routing

> Traffic Engineering/s/Segment Routing Policy and SRTE/s/SR Policy.

>

[Les:] Peter and I have discussed this suggestion. We have agreed to change 
“SRTE” to “SR Policy” in both drafts.



>

> --

> COMMENT:

> --

>

> I found this document a bit easier to read than the OSPF one. Though it also

> seems (implementation) confused on 1:1 association of signaling over a link

> with data use of the link and so the confusion on what application to support

> on the link. As I noted on the OSPF one, it would be much clearer to simply

> discuss the main problem (to me) - the ability to support advertisement of

> application specific values?

>

[Les:] There are two issues which this draft is addressing – as detailed in the 
Introduction:



1)Unambiguously indicate which  advertisements are to be used by a given 
application



2)Support advertisement of application specific values



Both are important.



> I don't see any discussion on the dark bandwidth problem or the security

> problems identified in RFC8426? It would be helpful if the draft pointed to

> the

> RFC8426 solution.

>

[Les:] I see RFC8426 and this document as complementary. RFC8426 discusses the 
operational challenges when multiple applications (specifically RSVP-TE and SR 
Policy) are deployed in the same network.

This document is defining new encodings in support of application specific 
advertisements, which eliminate ambiguity as to how to pair link attribute 
advertisements with applications.

Discussing dark bandwidth issues seems out of scope for this document.



   Les



>


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

Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)

[Les Ginsberg (ginsberg)]

Roman -



Thanx for the review.

Responses inline.



> -Original Message-

> From: Roman Danyliw via Datatracker 

> Sent: Wednesday, June 10, 2020 3:05 PM

> To: The IESG 

> Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee

> Lindem (acee) ; aretana.i...@gmail.com; Acee Lindem

> (acee) 

> Subject: Roman Danyliw's No Objection on draft-ietf-isis-te-app-14: (with

> COMMENT)

>

> Roman Danyliw has entered the following ballot position for

> draft-ietf-isis-te-app-14: 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-isis-te-app/

>

>

>

> --

> COMMENT:

> --

>

> (revised)

> ** Section 4.1.  As I understand it, the SABM can be of 0 – 8 octets in 
> length.

> The SABM Length field represents that length and has 7 bits to do that.

> However, the maximum number of bits needed to represent 8 is only 4 bits.

> What’s the thinking on those three extra bits?  Should they be marked as

> reserved?  I would have the same question for the UDABM mask.

>

[Les:] The limitation for the xABM length to be no more than 8 bytes was 
introduced only recently based on a review comment.

The concern was that without a limit, it would be theoretically possible for 
the ABM itself to consume the full sub-TLV space, leaving no room for the 
actual link attribute advertisements.

There are existing implementations of this draft which have been deployed. 
Changing the interpretation of (some of) the  bits would not be backwards 
compatible.

I do not think the small space savings would be worth the trouble.



You are the third reviewer to ask about this.

(Tongue-in-cheek)  I am impressed with the (oxymoron alert…) “abundance of 
frugality”. 



> ** Section 6.2.  I didn’t follow what it means to send the sub-TLV in Section

> 4.2 with a zero length SABM Length and UDABM Length – that is two empty

> bitmasks?  Is that permitted?  What would it convey?

>

[Les:] Clearly 0 length masks are permitted since we specify a length of 0 as 
valid.

And usage is described in Sections 4.2 and 6.2 – any application can use such 
advertisements.

What specifically is your question?





> ** Section 8.  Per “Tampering with the information defined in this document

> may

> have an effect on applications using it, including impacting Traffic

> Engineering.”, I have no disagreement with this statement.  However, I

> would

> recommend adding a brief statement what is the security impact of

> “impacting

> Traffic Engineering”.

>

> ** Section 8.  Per “This is similar in nature to the impacts associated  with

> (for example) [RFC5305]”, what specific text in RFC5305 was envisioned?  The

> SecCon section (Section 6) of RFC5305 contains only one sentence that points

> to

> RFC5304?

>

[Les:] I have added a reference to RFC8570 – whose Security section has a good 
discussion of impacts to TE.

I have removed the reference to RFC5305. It seemed unnecessary after 
referencing RFC8570 and – as you point out – it does not discuss security 
issues in any detail.



> ** Section 8.  Consider using the editorial framing of the first paragraph of

> Section 13 in draft-ietf-ospf-te-link-attr-reuse to introduce how the RFC5304

> applies here.

>

[Les:] Done



> ** Editorial

> -- Section 3.  Editorial.  Consider providing a reference for the registries

> instead of an inline URL.

>

[Les:] Yes – this has been done. Another reviewer also requested this.



> -- Section 4.1.  The rendering of the sub-TLV diagram was split between Page

> 6

> and 7 when this draft is read in TXT format.  IMO, it would be more readable

> if

> it was on one page.

>

[Les:] I prefer to leave this to the RFC Editor.

> -- Per Section 4.1.  Editorial.  Per “See the following section for a

> description …”, please explicitly name the section.

>

[Les:] Done



> -- Section 4.2.  Typo. s/Identifer/Identifier/



[Les:] Done



   Les



>

>


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

Re: [Lsr] Robert Wilton's Discuss on draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS)

[Rob Wilton (rwilton)]

Hi Peter,

Please see inline ...

I think that there is probably just one point of confusion/ambiguity that needs 
to be resolved.

> -Original Message-
> From: Peter Psenak 
> Sent: 11 June 2020 11:30
> To: Rob Wilton (rwilton) ; Alvaro Retana
> 
> Cc: Acee Lindem (acee) ; draft-ietf-ospf-te-link-attr-
> re...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Yingzhen Qu
> ; The IESG 
> Subject: Re: Robert Wilton's Discuss on draft-ietf-ospf-te-link-attr-
> reuse-14: (with DISCUSS)
> 
> Hi Rob,
> 
> 
> thanks for your comments, please see inline (##PP)
> 
> On 10/06/2020 19:18, Rob Wilton (rwilton) wrote:
> > Hi Alvaro,
> >
> >
> >> -Original Message-
> >> From: Alvaro Retana 
> >> Sent: 10 June 2020 16:49
> >> To: Rob Wilton (rwilton) 
> >> Cc: Acee Lindem (acee) ; draft-ietf-ospf-te-link-attr-
> >> re...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Yingzhen Qu
> >> ; The IESG 
> >> Subject: Re: Robert Wilton's Discuss on draft-ietf-ospf-te-link-attr-
> >> reuse-14: (with DISCUSS)
> >>
> >> On June 10, 2020 at 10:32:09 AM, Robert Wilton wrote:
> >>
> >>
> >> Rob:
> >>
> >> Hi!
> >>
> >> Thanks for the review.
> >>
> >> I’m replying for the authors as I think that your
> >> questions/suggestions should be easy to address.  Please see below.
> > [RW]
> >
> > Yes, hopefully.
> >
> >>
> >>
> >> Thanks!
> >>
> >>
> >> Alvaro.
> >>
> >>
> >>> --
> >>> DISCUSS:
> >>> --
> >>>
> >>> I found parts of this document hard to understand, but I'm not
> familiar
> >> with
> >>> the specifics of the protocols.
> >>>
> >>> This discuss is in the vein of "I think that folks might struggle to
> >>> implement this correctly/consistently". In particular I had some
> >>> questions/concerns about section 5 which, if clarified, would probably
> >> help
> >>> this document.
> >>>
> >>> In Section 5:
> >>>
> >>> The ASLA sub-TLV is an optional sub-TLV and can appear multiple times
> >>> in the OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV. The ASLA
> >>> sub-TLV MUST be used for advertisement of the link attributes listed
> >>> at the end on this section if these are advertised inside OSPFv2
> >>> Extended Link TLV and OSPFv3 Router-Link TLV. It has the following
> >>> format:
> >>>
> >>> I think that it would be useful to clarify when/why the ASLA sub-TLV
> can
> >> be
> >>> included multiple times. I.e. when different applications want to
> >> control
> >>> different link attributes.
> >>
> >> That sounds like a simple addition.
> 
> ##PP
> Updated as:
> 
> 
> The ASLA sub-TLV is an optional sub-TLV of OSPFv2 Extended Link TLV and
> OSPFv3 Router-Link TLV. Multiple ASLA sub-TLVs can be present in its
> parent TLV when different applications want to control different link
> attributes or when different value of the same attribute needs to be
> advertised by multiple applications.
> 
[RW] 

That looks fine.



> >>
> >>
> >>
> >>> Standard Application Identifier Bits are defined/sent starting with
> >>> Bit 0. Undefined bits which are transmitted MUST be transmitted as 0
> >>> and MUST be ignored on receipt. Bits that are not transmitted MUST
> >>> be treated as if they are set to 0 on receipt. Bits that are not
> >>> supported by an implementation MUST be ignored on receipt.
> >>>
> >>> It was not clear to me what it means if the SABM (or UDABM) fields are
> >>> entirely empty. This paragraph states that they are treated as if they
> >> are
> >>> 0, but sections 8 and 11 imply that if the field is omitted then it
> acts
> >> as
> >>> if all applications are allowed. Section 12.2 implies that if the
> field
> >> is
> >>> omitted then it is as if all applications are allowed unless there
> there
> >> is
> >>> another ASLA with the given application bit set, in which case it is
> >> treated
> >>> as being a 0 again. I think that this document would be helped if the
> >>> specific behaviour was defined in section 5, retaining the
> >>> justification/clarification in the subsequent sections.
> >>
> >> Empty is different than omitted.
> >>
> >> Omitted (the length of the field is 0) means: "these attributed apply
> >> to all applications, so I'm not even going to bother setting the
> >> bits".
> > [RW]
> >
> > I don’t particularly like this as the solution, since if feels
> inconsistent to me.  I.e. if you don’t advertise a bit always treat it as
> zero, unless you don’t say anything at all, in which case treat it as 1.
> I would have preferred for it to have an explicit flag bit in the ASLA TLV
> to indicate that all applications are supported ... more below (see *).
> >
> >>
> >>
> >> Empty (the field is present, but all the bits are set to 0) means that
> >> the sender is saying that "no application applies to this set of
> >> attributes".  I can't think of a circumstance when a sender would do
> >> this, as it is basically an empty announcement: it doesn't apply to
> >> 

[Lsr] Deborah Brungard's Discuss on draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS and COMMENT)

[Deborah Brungard via Datatracker]

Deborah Brungard has entered the following ballot position for
draft-ietf-ospf-te-link-attr-reuse-14: Discuss

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-te-link-attr-reuse/



--
DISCUSS:
--

This should be simple to resolve - the use of the SR-TE term is
out-of-alignment with other drafts, spring and idr. Suggest: Segment Routing
Traffic Engineering/s/Segment Routing Policy and SRTE/s/SR Policy.

And this should be obvious, the abstract justifies the need for this document
because routers assume RSVP-TE on a link based on an OSPF advertisement. But
that's an implementation shortcut and needs to be noted as that. Sure, it was
ok when everything was RSVP/RSVP-TE. But let's not make it a "BCP". This needs
to be corrected to say "Some implementations..". I would suggest aligning this
abstract with the ISIS draft and move this paragraph to later in the document.


--
COMMENT:
--

As Warren noted, the draft is very difficult to read.

The specific problem (to me) is the ability to support advertisement of
application specific values? And, to say, new applications MUST NOT make use of
RSVP-TE LSA advertisements which is causing confusion for (some)
implementations. It would help to make this more clearer and not muddy with
implementation woes.

I don't see any discussion on the dark bandwidth problem or the security
problems identified in RFC8426? It would be helpful if the draft pointed to the
RFC8426 solution.



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

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS and COMMENT)

[Peter Psenak]

Deborah,


please see inline (##PP)

On 11/06/2020 14:00, BRUNGARD, DEBORAH A wrote:

Hi Peter,

Thanks - in-line-
Deborah

-Original Message-
From: Peter Psenak 
Sent: Thursday, June 11, 2020 7:00 AM
To: BRUNGARD, DEBORAH A ; The IESG 
Cc: draft-ietf-ospf-te-link-attr-re...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee 
Lindem ; Yingzhen Qu ; 
aretana.i...@gmail.com
Subject: Re: Deborah Brungard's Discuss on 
draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS and COMMENT)

Hi Deborah,

thanks for your comments, please see inline (##P):



--
COMMENT:
--

As Warren noted, the draft is very difficult to read.

This doesn't parse:
"As soon as the router that is an RSVP-TE head-end sees the link attribute being
 advertised for that link, it assumes RSVP-TE is enabled on that link,
 even though it is not.  If such RSVP-TE head-end router tries to
 setup an RSVP-TE path via that link it will result in the path setup
 failure."
It seems there is the assumption the link is congruent with the signaling
(maybe some implementations do but not per spec). Maybe this is needed by some
implementations, but the draft seems to make it a "general problem".


##PP
It is a general problem. RSVP-TE and IGP topologies do not need to be
congruent. All major vendors' implementation derive the link
participation in the RSVP-TE topology from the presence of the RSVP-TE
link attributes. So this is one of the two problems this draft solves.
##DB
That's too bad - sad. But as you say it is an implementation problem - that's my concern on having 
these sentences in this document - we will be giving visibility to it as if it is a 
"BCP". I think this needs to be prefaced as "Some implementations". As I said, 
I find this confusing and detracts from the (hopefully) main aim of the document. I'll redo my 
Discuss to add this qualifier as I do think we need to accurately say this is an implementation 
problem.


##PP
it is not the implementation problem.

There is no standardized way to derive the RSVP-TE traffic engineering 
topology.


For example, RFC3630 says:

  "The extensions provide a way of describing the traffic engineering
   topology (including bandwidth and administrative constraints) and
   distributing this information within a given OSPF area.  This
   topology does not necessarily match the regular routed topology,"

but it does not provide any mechanism how the traffic engineering 
topology is derived. So we have a problem, where implementations picked 
a method to fill the void in the specification.




##PP
how is RFC8426 relevant in the context of this draft?
##DB
Advertising bandwidth per an application will not solve the "big problem" - 
dark bandwidth accounting. While not part of the advertisement, as we already have an RFC 
on it, it would be helpful to our user community to point to it.


##PP
we are not trying to solve the "dark bandwidth accounting", so I see no 
relevance between this draft and RFC8426.


thanks,
Peter



thanks,
Peter








___
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] Deborah Brungard's Discuss on draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS and COMMENT)

[BRUNGARD, DEBORAH A]

Hi Peter,

Thanks - in-line-
Deborah

-Original Message-
From: Peter Psenak  
Sent: Thursday, June 11, 2020 7:00 AM
To: BRUNGARD, DEBORAH A ; The IESG 
Cc: draft-ietf-ospf-te-link-attr-re...@ietf.org; lsr-cha...@ietf.org; 
lsr@ietf.org; Acee Lindem ; Yingzhen Qu 
; aretana.i...@gmail.com
Subject: Re: Deborah Brungard's Discuss on 
draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS and COMMENT)

Hi Deborah,

thanks for your comments, please see inline (##P):

> 
> --
> COMMENT:
> --
> 
> As Warren noted, the draft is very difficult to read.
> 
> This doesn't parse:
> "As soon as the router that is an RSVP-TE head-end sees the link attribute 
> being
> advertised for that link, it assumes RSVP-TE is enabled on that link,
> even though it is not.  If such RSVP-TE head-end router tries to
> setup an RSVP-TE path via that link it will result in the path setup
> failure."
> It seems there is the assumption the link is congruent with the signaling
> (maybe some implementations do but not per spec). Maybe this is needed by some
> implementations, but the draft seems to make it a "general problem".

##PP
It is a general problem. RSVP-TE and IGP topologies do not need to be 
congruent. All major vendors' implementation derive the link 
participation in the RSVP-TE topology from the presence of the RSVP-TE 
link attributes. So this is one of the two problems this draft solves.
##DB
That's too bad - sad. But as you say it is an implementation problem - that's 
my concern on having these sentences in this document - we will be giving 
visibility to it as if it is a "BCP". I think this needs to be prefaced as 
"Some implementations". As I said, I find this confusing and detracts from the 
(hopefully) main aim of the document. I'll redo my Discuss to add this 
qualifier as I do think we need to accurately say this is an implementation 
problem.
##PP
how is RFC8426 relevant in the context of this draft?
##DB
Advertising bandwidth per an application will not solve the "big problem" - 
dark bandwidth accounting. While not part of the advertisement, as we already 
have an RFC on it, it would be helpful to our user community to point to it.

thanks,
Peter
> 
> 
> 
> 
> 

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

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS and COMMENT)

[Peter Psenak]

Hi Deborah,

thanks for your comments, please see inline (##P):

On 10/06/2020 23:57, Deborah Brungard via Datatracker wrote:

Deborah Brungard has entered the following ballot position for
draft-ietf-ospf-te-link-attr-reuse-14: Discuss

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-te-link-attr-reuse/



--
DISCUSS:
--

This should be simple to resolve - the use of the SR-TE term is
out-of-alignment with other drafts, spring and idr. Suggest: Segment Routing
Traffic Engineering/s/Segment Routing Policy and SRTE/s/SR Policy.


--
COMMENT:
--

As Warren noted, the draft is very difficult to read.

This doesn't parse:
"As soon as the router that is an RSVP-TE head-end sees the link attribute being
advertised for that link, it assumes RSVP-TE is enabled on that link,
even though it is not.  If such RSVP-TE head-end router tries to
setup an RSVP-TE path via that link it will result in the path setup
failure."
It seems there is the assumption the link is congruent with the signaling
(maybe some implementations do but not per spec). Maybe this is needed by some
implementations, but the draft seems to make it a "general problem".


##PP
It is a general problem. RSVP-TE and IGP topologies do not need to be 
congruent. All major vendors' implementation derive the link 
participation in the RSVP-TE topology from the presence of the RSVP-TE 
link attributes. So this is one of the two problems this draft solves.




But I don't think this is really the intention of the draft - even section 4.1
says duplication would be only in "rare cases". The specific problem (to me) is
the ability to support advertisement of application specific values? 


##PP
that is the second problem that the draft is addressing.




And, to
say, new applications MUST NOT make use of RSVP-TE LSA advertisements which is
causing confusion for (some) implementations. It would help to make this more
clearer and not muddy with implementation woes.


##PP
I don't know how to make it any more clear. There is an existing text in 
the draft:


   In recent years new applications have been introduced which have use
   cases for many of the link attributes historically used by RSVP-TE.
   Such applications include Segment Routing Traffic Engineering (SRTE)
   [I-D.ietf-spring-segment-routing-policy] and Loop Free Alternates
   (LFA) [RFC5286].  This has introduced ambiguity in that if a
   deployment includes a mix of RSVP-TE support and SRTE support (for
   example) it is not possible to unambiguously indicate which
   advertisements are to be used by RSVP-TE and which advertisements are
   to be used by SRTE.  If the topologies are fully congruent this may
   not be an issue, but any incongruence leads to ambiguity.

   An example where this ambiguity causes a problem is a network in
   which RSVP-TE is enabled only on a subset of its links.  A link
   attribute is advertised for the purpose of another application (e.g.
   SRTE) for a link that is not enabled for RSV-TE.  As soon as the
   router that is an RSVP-TE head-end sees the link attribute being
   advertised for that link, it assumes RSVP-TE is enabled on that link,
   even though it is not.  If such RSVP-TE head-end router tries to
   setup an RSVP-TE path via that link it will result in the path setup
   failure.

   An additional issue arises in cases where both applications are
   supported on a link but the link attribute values associated with
   each application differ.  Current advertisements do not support
   advertising application specific values for the same attribute on a
   specific link.

   This document defines extensions which address these issues.

If above is not sufficient, please suggest a text that would make it clear.



I don't see any discussion on the dark bandwidth problem or the security
problems identified in RFC8426? It would be helpful if the draft pointed to the
RFC8426 solution.


##PP
how is RFC8426 relevant in the context of this draft?

thanks,
Peter








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

Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-ospf-te-link-attr-reuse-14: (with COMMENT)

[Peter Psenak]

Hi Roman,

thanks for your comments, please see inline (##PP):

On 10/06/2020 23:58, Roman Danyliw via Datatracker wrote:

Roman Danyliw has entered the following ballot position for
draft-ietf-ospf-te-link-attr-reuse-14: 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-te-link-attr-reuse/



--
COMMENT:
--

(revised)
** Section 5.  (same comment as raised about Section 4.1. of
draft-ietf-isis-te-app) If the possible values of SABM Length and UDABM Length
are 0, 4 and 8, and these are stored literally, why are 8 bits required?  Could
they be reallocated to the Reserved field?


##PP
We did not limit the size at the beginning, but later due to limited
size of ISIS TLVs we limited it to 8 bytes to leave some space for the
attributes itself (draft-ietf-isis-te-app). We wanted to keep the
consistency between ISIS and OSPF which also helps BGP-LS. 8 octets
should be future-proof enough (64 apps).

We keep the byte for the SABM and UDABM lengths to avoid problems of
existing implementation.




** Section 13. (same comment as raised about Section 4.1. of
draft-ietf-isis-te-app) Per “Tampering with the information defined in this
document may have an effect on applications using it, including impacting
Traffic Engineering.”, I have no disagreement with this statement.  However, I
would recommend adding a brief statement what is the security impact of
“impacting Traffic Engineering”.


##PP
TE is one of the applications using link attributes for selecting the 
explicit paths. Messing around with advertisement of the link attributes 
that TE uses may affect the TE path selection.


I modified as:

  "including impacting Traffic
   Engineering that uses various link attributes for its path
   computation."

Would that be good enough?



** Section 13.  Per "This is similar in nature to the impacts associated with
(for example) [RFC3630]", what specific text in RFC3630 was envisioned.  I
didn't follow the link.


Here's the text from the RFC3630:

  "However,
   tampering with TE LSAs may have an effect on traffic engineering
   computations, and it is suggested that any mechanisms used for
   securing the transmission of normal OSPF LSAs be applied equally to
   all Opaque LSAs, including the TE LSAs specified here"

thanks,
Peter










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

Re: [Lsr] Robert Wilton's Discuss on draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS)

[Peter Psenak]

Hi Rob,


thanks for your comments, please see inline (##PP)

On 10/06/2020 19:18, Rob Wilton (rwilton) wrote:

Hi Alvaro,



-Original Message-
From: Alvaro Retana 
Sent: 10 June 2020 16:49
To: Rob Wilton (rwilton) 
Cc: Acee Lindem (acee) ; draft-ietf-ospf-te-link-attr-
re...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Yingzhen Qu
; The IESG 
Subject: Re: Robert Wilton's Discuss on draft-ietf-ospf-te-link-attr-
reuse-14: (with DISCUSS)

On June 10, 2020 at 10:32:09 AM, Robert Wilton wrote:


Rob:

Hi!

Thanks for the review.

I’m replying for the authors as I think that your
questions/suggestions should be easy to address.  Please see below.

[RW]

Yes, hopefully.




Thanks!


Alvaro.



--
DISCUSS:
--

I found parts of this document hard to understand, but I'm not familiar

with

the specifics of the protocols.

This discuss is in the vein of "I think that folks might struggle to
implement this correctly/consistently". In particular I had some
questions/concerns about section 5 which, if clarified, would probably

help

this document.

In Section 5:

The ASLA sub-TLV is an optional sub-TLV and can appear multiple times
in the OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV. The ASLA
sub-TLV MUST be used for advertisement of the link attributes listed
at the end on this section if these are advertised inside OSPFv2
Extended Link TLV and OSPFv3 Router-Link TLV. It has the following
format:

I think that it would be useful to clarify when/why the ASLA sub-TLV can

be

included multiple times. I.e. when different applications want to

control

different link attributes.


That sounds like a simple addition.


##PP
Updated as:


The ASLA sub-TLV is an optional sub-TLV of OSPFv2 Extended Link TLV and
OSPFv3 Router-Link TLV. Multiple ASLA sub-TLVs can be present in its 
parent TLV when different applications want to control different link 
attributes or when different value of the same attribute needs to be 
advertised by multiple applications.







Standard Application Identifier Bits are defined/sent starting with
Bit 0. Undefined bits which are transmitted MUST be transmitted as 0
and MUST be ignored on receipt. Bits that are not transmitted MUST
be treated as if they are set to 0 on receipt. Bits that are not
supported by an implementation MUST be ignored on receipt.

It was not clear to me what it means if the SABM (or UDABM) fields are
entirely empty. This paragraph states that they are treated as if they

are

0, but sections 8 and 11 imply that if the field is omitted then it acts

as

if all applications are allowed. Section 12.2 implies that if the field

is

omitted then it is as if all applications are allowed unless there there

is

another ASLA with the given application bit set, in which case it is

treated

as being a 0 again. I think that this document would be helped if the
specific behaviour was defined in section 5, retaining the
justification/clarification in the subsequent sections.


Empty is different than omitted.

Omitted (the length of the field is 0) means: "these attributed apply
to all applications, so I'm not even going to bother setting the
bits".

[RW]

I don’t particularly like this as the solution, since if feels inconsistent to 
me.  I.e. if you don’t advertise a bit always treat it as zero, unless you 
don’t say anything at all, in which case treat it as 1.  I would have preferred 
for it to have an explicit flag bit in the ASLA TLV to indicate that all 
applications are supported ... more below (see *).




Empty (the field is present, but all the bits are set to 0) means that
the sender is saying that "no application applies to this set of
attributes".  I can't think of a circumstance when a sender would do
this, as it is basically an empty announcement: it doesn't apply to
anythingbut it is also not wrong and would simply not be used.

[RW]

I agree.  Arguably, the document could state that at least one bit in the SABM 
or UDABM flags SHOULD be set.





OTOH, there is a case where the sender can set a bit (or more) for an
application it supports (maybe a new one) -- if the receiver doesn't
support that application it will then ignore the bit, and it will look
as if nothing was set: none of the supported applications (at the
receiver) match.  Again, the receiver will simply not use the
information.

[RW]

This is okay with me.

But it is this text in section 12.2 that seems to define different/complicated 
semantics:

12.2.  Use of Zero Length Application Identifier Bit Masks

If link attributes are advertised associated with zero length
Application Identifier Bit Masks for both standard applications and
user defined applications, then any Standard Application and/or any
User Defined Application is permitted to use that set of link
attributes so long as there is not another set of attributes

[Lsr] FW: Nomcom 2020-2021 Second Call For Volunteers

[Acee Lindem (acee)]

FYI – Please consider volunteering for NOMCOM.

Thanks,
Acee


Begin forwarded message:
From: NomCom Chair 2020 
Date: June 10, 2020 at 1:55:21 PM CDT
To: IETF Announcement List 
Cc: "i...@ietf.org" 
Subject: Nomcom 2020-2021 Second Call For Volunteers
This is the second sending of the call for volunteers for the 2020-2021 NomCom.

I wanted to mention a few updates from the previous email (sent 2 weeks ago):
- I've fixed the URL at the bottom of the email to point to 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_nomcom_2020_=DwIDaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=ZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI=NgIu-7Ij0nEdsFcbJOLcl2M56RxyREhLAtcaHLatD34=
  instead of /2019/. This was a test to see if anyone was paying attention. 
Apparently, some people were. ;)
- The IETF 108 registration form includes a checkbox that will let you 
volunteer. You can use this instead of emailing me, when you register for IETF 
108.
- I currently have 39 volunteers. Last year had 149. I need more volunteers!
-
The IETF NomCom appoints people to fill the open slots on the LLC, IETF Trust, 
the IAB, and the IESG.

Ten voting members for the NomCom are selected in a verifiably random way from 
a pool of volunteers. The more volunteers, the better chance we have of 
choosing a random yet representative cross section of the IETF population.

The details of the operation of the NomCom can be found in BCP 10 (RFC 8713). 
RFC 3797 details the selection algorithm.

Special for this year (and only this year), we also have RFC 8788 (one-off 
update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer:

 Members of the IETF community must have attended at least three of
 the last five in-person IETF meetings in order to volunteer.

 The five meetings are the five most recent in-person meetings that
 ended prior to the date on which the solicitation for NomCom
 volunteers was submitted for distribution to the IETF community.
 Because no IETF 107 in-person meeting was held, for the 2020-2021
 Nominating Committee those five meetings are IETFs
   102 [Montreal, Canada; July 2018],
   103 [Bangkok, Thailand; November 2018],
   104 [Prague, Czech Republic; March 2019],
   105 [Montreal, Canada; July 2019], and
   106 [Singapore; November 2019].

Keep in mind that eligibility is based on in-person attendance at the five 
listed meetings. You can check your eligibility at: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_registration_nomcom.py=DwIDaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=ZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI=7_9x9PPoUIajJs2AnUFYg0KnEg8gkD3Jnwf1v079EQo=
 .

If you qualify, please volunteer. Before you decide to volunteer, please 
remember that anyone appointed to this NomCom will not be considered as a 
candidate for any of the positions that the 2020 - 2021 NomCom is responsible 
for filling.

People commonly volunteer by ticking the box on IETF registration forms. The 
IETF 106 form did not ask whether people were willing to volunteer. IETF 107 
did ask, but all those registrations were canceled. I have asked the 
Secretariat if it is possible to get the list if volunteers from canceled IETF 
107 registrations. If that list is available, I will contact all who are 
verified as eligible. But given the uncertainty of this process, I would 
encourage people to volunteer directly (see the bottom of this email for 
instructions). Thank you for volunteering!

The list of people and posts whose terms end with the March 2021 IETF meeting, 
and thus the positions for which this NomCom is responsible, are

IETF Trust:
   Joel Halpern

LLC:
   Maja Andjelkovic

IAB:
   Jari Arkko
   Jeff Tantsura
   Mark Nottingham
   Stephen Farrell
   Wes Hardaker
   Zhenbin Li

IESG:
   Alissa Cooper, IETF Chair/GEN AD
   Alvaro Retana, RTG AD
   Barry Leiba, ART AD
   Deborah Brungard, RTG AD
   Éric Vyncke, INT AD
   Magnus Westerlund, TSV AD
   Roman Danyliw, SEC AD
   Warren Kumari, OPS AD

All appointments are for 2 years. The Routing area has 3 ADs and the General 
area has 1; all other areas have 2 ADs. Thus, all areas (that have more than 
one AD) have at least one continuing AD.

The primary activity for this NomCom will begin in July 2020 and should be 
completed in January 2021.  The NomCom will have regularly scheduled conference 
calls to ensure progress. There will be activities to collect requirements from 
the community, review candidate questionnaires, review feedback from community 
members about candidates, and talk to candidates.

While being a NomCom member does require some time commitment it is also a very 
rewarding experience.

As a member of the NomCom it is very important that you be willing and able to 
attend either videoconference or in-person meetings (which may not happen) 
during 14-20 November (IETF 109 - 

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Robert Raszuk]

Support.

Thx,
R.

On Wed, Jun 10, 2020 at 9:28 PM Christian Hopps  wrote:

> This begins a 2 week WG adoption call for the following draft:
>
>   https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/
>
> The draft would be adopted on the Experimental track.
>
> Please indicate your support or objection by June 24, 2020.
>
> Authors, please respond to the list indicating whether you are aware of
> any IPR that applies to this draft.
>
> Thanks,
> Chris and 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] Murray Kucherawy's No Objection on draft-ietf-ospf-te-link-attr-reuse-14: (with COMMENT)

[Peter Psenak]

Thanks Acee, I fixed them all.

Peter

On 09/06/2020 16:59, Acee Lindem (acee) wrote:

Hi Peter, Murray,

On 6/9/20, 6:53 AM, "Peter Psenak"  wrote:

 Hi Murray,

 thanks for your comments, please see inline:

 On 08/06/2020 08:00, Murray Kucherawy via Datatracker wrote:
 > Murray Kucherawy has entered the following ballot position for
 > draft-ietf-ospf-te-link-attr-reuse-14: 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-te-link-attr-reuse/
 >
 >
 >
 > --
 > COMMENT:
 > --
 >
 > Three main things from me:
 >
 > (1) I found I'm in agreement below with some of the points raised in the 
posted
 > OPSDIR review.  Please give that another once-over.

 which ones in particular? I've responded to all of them, so it's hard
 for me to figure out which ones do you have in mind.

I think I've changed all the instances where "which" was being used with a 
defining clause. See attached diff.

Thanks,
Acee

 >
 > (2) A grammatical point: I think nearly every instance in this document 
of
 > "which" should be replaced by "that".

 I let this be checked by the English language experts :)

 >
 > (3) In Section 12.3.3, I don't think it's appropriate to use MUST-type 
language
 > to constrain future document authors.

 What we are saying is that if there is a router in the network that does
 not understand this new way of advertising the link attributes, all
 routers MUST continue to advertise it in the old way (on top of possibly
 advertising new way). What constrain would this pose to future documents?


 >
 > And now, my nit-storm:
 >
 > Section 1:
 > * "... attribute advertisements - examples of which ..." -- hyphen 
should be a
 > comma * "... for a link that is not enabled for RSV-TE." -- s/RSV/RSVP/ * 
"...
 > path via that link it will result ..." -- comma after "link"

 fixed.

 >
 > Section 3:
 > * Please define, or provide a reference for, "GMPLS".


 fixed

 >
 > Section 4.1:
 > * "... not inspected by OSPF, that acts as ..." -- s/that/which instead/
 >

 fixed

 > Section 5:
 > * Several changes to this paragraph suggested:
 > OLD:
 > On top of advertising the link attributes for standardized
 > applications, link attributes can be advertised for the purpose of
 > application that is not defined as standardized one.  We call such
 > application a user defined application.  What such application might
 > be is not subject to the standardization and is outside of the scope
 > of this specification.
 > NEW:
 > On top of advertising the link attributes for standardized
 > applications, link attributes can be advertised for the purpose of
 > applications that are not standardized.  We call such an
 > application a "User Defined Application" or "UDA".  These 
applications are
 > not subject to standardization and are outside of the scope
 > of this specification.

 done.

 >
 > * Is the snapshot of the current content of the Link Attribute 
Application
 > Identifier Registry needed?  The rest of the document doesn't seem to 
reference
 > it. *

 I believe it is useful to mention it here.


 "... to advertise all UDAs." -- although it's fairly clear at this point
 > what a UDA is, I suggest defining it somewhere above, maybe by hanging 
it off
 > one of the other places where the full name is used such as in the 
paragraph
 > above


 I thought the edited paragraph

 "On top of advertising the link attributes for standardized
 applications"

 defines UDAs clearly.



 >
 > Section 6.1:
 > * Please expand "IPFRR" on first use.

 done

 >
 > Section 6.2:
 > * "All these can be used ..." -- s/All/All of/

 fixed.

 >
 > Section 11:
 > * "- e.g.  RSVP-TE -" -- comma after "e.g."
 > * "... one need to make sure ..." -- s/need/needs/
 > * "... applications, where the enablement ..." -- remove comma
 > * "... such application - e.g.  LFA." -- change to "such application.  An
 > example of this is LFA."

 fixed

 >
 > Section 12.3.4:
 > * "Link attributes that are NOT allowed  ..." -- s/NOT/not/

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[bruno.decraene]

Hi Chris, Acee,

I support adoption.
I've provided comments on the draft a couple of days ago.

Regards,
--Bruno

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Wednesday, June 10, 2020 9:28 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps
Subject: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

This begins a 2 week WG adoption call for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/

The draft would be adopted on the Experimental track.

Please indicate your support or objection by June 24, 2020.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee.

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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-isis-te-app-14: Discuss

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-isis-te-app/



--
DISCUSS:
--

My apologies if this is super-obvious and I'm just missing it ... but
Section 4.3 dictates that part of the value for the application-specific
SRLG TLV is a "Neighbor System-ID + pseudo-node ID (7 octets)".  Where
are these defined?  (We don't exactly say that we're reusing the structure
from, e.g., TLV 138, which I note refers to the seventh octet as
"pseudonode number", not "pseudo-node ID".  Similarly for the
interpretation of the SRLG value(s).  Do we just need to reference that
we're reusing the encoding from RFC 5307 (or similar) or are some
changes needed?


--
COMMENT:
--

What is the scope over which the user-defined application bits are
defined/allocated?

And, a general question, just to check my understanding: if I do need to
specify different values of a given attribute for different
applications, I do that by putting multiple copies of the new sub-TLV in
TLV 22/23/etc., with the flags set according to which application the
contained attributes apply to?  (Mostly I ask because I forget what the
rules are for having multiple instances of a given TLV/sub-TLV as
siblings in the same container.)

Section 3.1

Maybe mention (again, I know) that this is only the subset of sub-TLVs
that are used for RSVP-TE?

Section 4.2

   When the L-flag is set in the Application Identifier Bit Mask, all of
   the applications specified in the bit mask MUST use the legacy
   advertisements for the corresponding link found in TLVs 22, 23, 25,
   141, 222, and 223 or TLV 138 or TLV 139 as appropriate.  Link

nit(?): is this "found in sub-TLVs of TLVs 22, [...]"?

   attribute sub-sub-TLVs for the corresponding link attributes MUST NOT
   be advertised for the set of applications specified in the Standard/
   User Application Identifier Bit Masks and all such advertisements
   MUST be ignored on receipt.

Does this apply to just the (sub-)TLV with the L-flag set, or to other
instances of that (sub-)TLV as well?

   For a given application, the setting of the L-flag MUST be the same
   in all sub-TLVs for a given link.  In cases where this constraint is
   violated, the L-flag MUST be considered set for this application.

editorial: I suggest "the L-flag MUST be considered set for this
application for all sub-TLVs on the link in question".

   If link attributes are advertised associated with zero length
   Application Identifier Bit Masks for both standard applications and
   user defined applications, then any Standard Application and/or any

Do we need to talk about conflicts if there are multiple such sub-TLVs
for the link in question (that contain different values in the
sub-sub-TLV(s))?

   User Defined Application is permitted to use that set of link
   attributes so long as there is not another set of attributes
   advertised on that same link which is associated with a non-zero
   length Application Identifier Bit Mask with a matching Application
   Identifier Bit set.

nit: this phrasing of "matching Application Identifier Bit set" does not
seem as clear as it could be that the bit for the application in
question is what's checked (though I have a hard time believing that
someone would accidentally misinterpret the meaning).

   the link attribute sub-sub-TLV code points.  This document defines a
   sub-sub-TLV for each of the existing sub-TLVs listed in Section 3.1
   except as noted below.  The format of the sub-sub-TLVs matches the

Just to check that I'm matching things up properly: this leaves the only
attributes that do not have some form of exception noted as
administrative group, extended administrative group, and TE default
metric?

Section 4.2.1

   Maximum link bandwidth is an application independent attribute of the
   link.  When advertised using the Application Specific Link Attributes
   sub-TLV, multiple values for the same link MUST NOT be advertised.
   This can be accomplished most efficiently by having a single
   advertisement for a given link where the Application Identifier Bit
   Mask identifies all the applications which are making use of the
   value for that link.

If I want the same maximum link bandwidth to apply to all applications,
couldn't I just put it in a