[Lsr] IETF 108 LSR Presentation Slot Requests

[Yingzhen Qu]

Hi all,



We're now accepting agenda request for the LSR Working Grouping meeting
IETF 108. Please send your requests to lsr-cha...@ietf.org indicating draft
name, speaker, and desired duration (covering presentation and discussion).



LSR session is scheduled on Thursday, July 30th, 14:10-15:50 UTC.



Thanks,

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

[Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-00.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   : Area Proxy for IS-IS
Authors : Tony Li
  Sarah Chen
  Vivek Ilangovan
  Gyan S. Mishra
Filename: draft-ietf-lsr-isis-area-proxy-00.txt
Pages   : 20
Date: 2020-06-29

Abstract:
   Link state routing protocols have hierarchical abstraction already
   built into them.  However, when lower levels are used for transit,
   they must expose their internal topologies to each other, leading to
   scale issues.

   To avoid this, this document discusses extensions to the IS-IS
   routing protocol that would allow level 1 areas to provide transit,
   yet only inject an abstraction of the level 1 topology into level 2.
   Each level 1 area is represented as a single level 2 node, thereby
   enabling greater scale.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-00
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-00


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] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

[Les Ginsberg (ginsberg)]

Tony –

Inline.

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Monday, June 29, 2020 2:37 PM
To: Les Ginsberg (ginsberg) 
Cc: Hannes Gredler ; 
draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Comments on Requested Codepoints for 
draft-li-lsr-isis-area-proxy



Hi Les,



On Jun 29, 2020, at 2:13 PM, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Tony –

OLD:
1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Inside Node TLV - Top level TLV

3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID

4)Area Segment SID - Top Level TLV

NEW: (Please check my interpretation)

1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID
   Sub-TLV Inside Node ???

3)Area Segment SID - Top Level TLV

Am I correct so far??


Yes, exactly.  Inside node would be a sub-TLV or a flag, TBD.


If so, a couple more comments/suggestions:

a)Could the Area Proxy TLV become a bit more generic and allow advertisement of 
the capability (implied by presence of the TLV)?
If  so, the Router Capability sub-TLV could go away.


Speaking just for myself, ok, that seems reasonable and doable.



b)If the Area Segment SID is (as you suggest) a generic thing not specific to 
Area Proxy, then I would point you to 
https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.1


?  Your pointer is to the flags field of the SID/Label Binding TLV.

[Les:] Yes – as the suggestion would be to add another flag definition.


This allows SIDs to be advertised in the SID Binding TLV for a special purpose 
(see the Mirror SID). One could imagine another flag bit to indicate this is an 
Area SID.


You’re suggesting a bit in the flags, the range would be unused, and a prefix 
length of 0? Then the actual SID would be in the SID/Label sub-TLV?

[Les:]Range could be specified as ignored in this case. Prefix length would be 
0.
The SID would be – as you say – advertised in the SID/Label sub-TLV – as with 
all other SIDs.


I think this would need to be vetted with SR  folks


That will happen, regardless of how we proceed.



– but I would like to avoid advertising a SID in a way different from all other 
SIDs i.e., SIDs currently are always a sub-TLV of some top level TLV – whether 
it be Prefix Reachability (Prefix-SID), IS Neighbor (Adjacency SID), or Binding 
SID (Mirror SID).


We were trying to extend the current design consistently with existing SIDs.  
As the Prefix SID and Adjacency SID were top level, it made sense to continue 
that approach.  The approach of the Binding SID TLV would seem to mix all 
semantics into one encoding and seems inconsistent and complicated with respect 
to the other SIDs.  If this was the intent, shouldn’t prefix and adjacency SIDs 
be encoded in this TLV as well?
[Les:] Prefix/adjacency SIDs are sub-TLVs of TLVs 135 and 22 respectively.

There’s only three available bits (plus one octet) here.  Aren’t we concerned 
about running out of bits if we go this direction?
[Les:] I am not. It is a question of whether SR sees this as a useful type of 
SID. If so, it merits a bit.

   Les

Tony

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

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

[tony . li]

Hi Les,


> On Jun 29, 2020, at 2:13 PM, Les Ginsberg (ginsberg)  
> wrote:
> 
> Tony –
>  
> OLD:
> 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV
>  
> 2)Inside Node TLV - Top level TLV
>  
> 3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
>Sub-TLV Area Proxy System ID
>Sub-TLV Area Segment SID
>  
> 4)Area Segment SID - Top Level TLV
>  
> NEW: (Please check my interpretation)
>  
> 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV
>  
> 2)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
>Sub-TLV Area Proxy System ID
>Sub-TLV Area Segment SID
>Sub-TLV Inside Node ???
>  
> 3)Area Segment SID - Top Level TLV
>  
> Am I correct so far??


Yes, exactly.  Inside node would be a sub-TLV or a flag, TBD.

 
> If so, a couple more comments/suggestions:
>  
> a)Could the Area Proxy TLV become a bit more generic and allow advertisement 
> of the capability (implied by presence of the TLV)?
> If  so, the Router Capability sub-TLV could go away.


Speaking just for myself, ok, that seems reasonable and doable.


> b)If the Area Segment SID is (as you suggest) a generic thing not specific to 
> Area Proxy, then I would point you to 
> https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.1 
> 

?  Your pointer is to the flags field of the SID/Label Binding TLV.


> This allows SIDs to be advertised in the SID Binding TLV for a special 
> purpose (see the Mirror SID). One could imagine another flag bit to indicate 
> this is an Area SID.


You’re suggesting a bit in the flags, the range would be unused, and a prefix 
length of 0? Then the actual SID would be in the SID/Label sub-TLV?


> I think this would need to be vetted with SR  folks


That will happen, regardless of how we proceed.


> – but I would like to avoid advertising a SID in a way different from all 
> other SIDs i.e., SIDs currently are always a sub-TLV of some top level TLV – 
> whether it be Prefix Reachability (Prefix-SID), IS Neighbor (Adjacency SID), 
> or Binding SID (Mirror SID).


We were trying to extend the current design consistently with existing SIDs.  
As the Prefix SID and Adjacency SID were top level, it made sense to continue 
that approach.  The approach of the Binding SID TLV would seem to mix all 
semantics into one encoding and seems inconsistent and complicated with respect 
to the other SIDs.  If this was the intent, shouldn’t prefix and adjacency SIDs 
be encoded in this TLV as well?

There’s only three available bits (plus one octet) here.  Aren’t we concerned 
about running out of bits if we go this direction?

Tony

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

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

[Les Ginsberg (ginsberg)]

Tony –

OLD:
1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Inside Node TLV - Top level TLV

3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID

4)Area Segment SID - Top Level TLV

NEW: (Please check my interpretation)

1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID
   Sub-TLV Inside Node ???

3)Area Segment SID - Top Level TLV

Am I correct so far??

If so, a couple more comments/suggestions:

a)Could the Area Proxy TLV become a bit more generic and allow advertisement of 
the capability (implied by presence of the TLV)?
If  so, the Router Capability sub-TLV could go away.

b)If the Area Segment SID is (as you suggest) a generic thing not specific to 
Area Proxy, then I would point you to 
https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.1
This allows SIDs to be advertised in the SID Binding TLV for a special purpose 
(see the Mirror SID). One could imagine another flag bit to indicate this is an 
Area SID.
I think this would need to be vetted with SR  folks – but I would like to avoid 
advertising a SID in a way different from all other SIDs i.e., SIDs currently 
are always a sub-TLV of some top level TLV – whether it be Prefix Reachability 
(Prefix-SID), IS Neighbor (Adjacency SID), or Binding SID (Mirror SID).

   Les


From: Tony Li  On Behalf Of tony...@tony.li
Sent: Monday, June 29, 2020 12:52 PM
To: Hannes Gredler 
Cc: Les Ginsberg (ginsberg) ; 
draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Comments on Requested Codepoints for 
draft-li-lsr-isis-area-proxy



Hi,

The authors have conferred and we would like to propose the following changes:

- The semantics of the Inside Node TLV will be folded into the Area Proxy TLV.

- The Area Proxy TLV will have its scope expanded to include pseudonodes.

- No change to the Area Segment SID TLV encoding.

Comments?   Especially from our Designated Experts?

Regards,
Sarah, Vivek, Gyan, and Tony



On Jun 25, 2020, at 12:04 PM, tony...@tony.li wrote:


Hi Hannes,

Thanks for your comments.  We will propose an alternate encoding.

Tony



On Jun 25, 2020, at 10:47 AM, Hannes Gredler 
mailto:han...@gredler.at>> wrote:

Hi Tony,

I do share Les’ concerns on burning top-level 8-bit code point space at this 
point.

At this point it is not me to judge wether CAP TLV or GENAPP TLV or something 
else should be a more appropriate place.
Please let's have a WG discussion on this.

Thanks,

/hannes


On 21.06.2020, at 18:50, tony...@tony.li wrote:


Les,

We don’t have to resolve this now.
One of my motivations for sending this was related to Early Allocation of code 
points. Since you have already asked once, I am assuming that if WG adoption is 
achieved it will be swiftly followed by an early allocation request – and as 
one of the Designated Experts I wanted to share my concerns sooner rather than 
later.


I appreciate that.  Do others share Les’ perspective on the relative tradeoffs? 
 Especially our other Desginated Experts?


Would this argue for advertising “this is a boundary circuit” in pseudo-node 
LSPs for boundary circuits rather than advertising “inside” on all inside 
pseudo-nodes?

You could do it that way.  It inverts the semantics and inverts the deployment. 
 Logically, it should have the same effect.  However, it then is seen by 
outside nodes.  Since they need not support Area Proxy, this seemed like a 
riskier approach, thus we opted for marking inside pseudonodes.

[Les:] My point was largely motivated by the statement in the draft:

“Area Proxy Boundary multi-access circuits (i.e.  Ethernets in LAN
   mode) with multiple Inside Edge Routers on them are not supported.”

So it seems advantageous to be able to prevent this from happening – which 
requires some signaling on the circuit in question.



I think that the case that you’re concerned about is already easily detected.  
Recall that an Inside Edge router will generate IIH’s onto a boundary circuit 
using the Proxy system ID.  Thus, if an Inside Edge router receives an IIH with 
a source address of it’s own proxy system id, then it has encountered this 
issue.

Tony


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

The work is adopted.

Authors, please resubmit with new name draft-ietf-lsr-flood-reflection and 
updating the track to experimental.

Thanks,
Chris.

> On Jun 10, 2020, at 3:28 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
> 



signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] The LSR WG has placed draft-przygienda-lsr-flood-reflection in state "Adopted by a WG"

[IETF Secretariat]

The LSR WG has placed draft-przygienda-lsr-flood-reflection in state
Adopted by a WG (entered by Christian Hopps)

The document is available at
https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection/

Comment:
Adopted for experimental track.

___
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

[Christian Hopps]

The work is adopted.

Authors, please resubmit with new name draft-ietf-lsr-isis-area-proxy and 
updating the track to experimental.

Thanks,
Chris.

> On Jun 10, 2020, at 3:27 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
> 



signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] The LSR WG has placed draft-li-lsr-isis-area-proxy in state "Adopted by a WG"

[IETF Secretariat]

The LSR WG has placed draft-li-lsr-isis-area-proxy in state
Adopted by a WG (entered by Christian Hopps)

The document is available at
https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/

Comment:
Adopted for experimental track.

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

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

[tony . li]

Hi,

The authors have conferred and we would like to propose the following changes:

- The semantics of the Inside Node TLV will be folded into the Area Proxy TLV.

- The Area Proxy TLV will have its scope expanded to include pseudonodes.

- No change to the Area Segment SID TLV encoding.

Comments?   Especially from our Designated Experts?

Regards,
Sarah, Vivek, Gyan, and Tony


> On Jun 25, 2020, at 12:04 PM, tony...@tony.li wrote:
> 
> 
> Hi Hannes,
> 
> Thanks for your comments.  We will propose an alternate encoding.
> 
> Tony
> 
> 
>> On Jun 25, 2020, at 10:47 AM, Hannes Gredler > > wrote:
>> 
>> Hi Tony,
>> 
>> I do share Les’ concerns on burning top-level 8-bit code point space at this 
>> point.
>> 
>> At this point it is not me to judge wether CAP TLV or GENAPP TLV or 
>> something else should be a more appropriate place.
>> Please let's have a WG discussion on this.
>> 
>> Thanks,
>> 
>> /hannes
>> 
>>> On 21.06.2020, at 18:50, tony...@tony.li  wrote:
>>> 
>>> 
>>> Les,
>>> 
 We don’t have to resolve this now.
 One of my motivations for sending this was related to Early Allocation of 
 code points. Since you have already asked once, I am assuming that if WG 
 adoption is achieved it will be swiftly followed by an early allocation 
 request – and as one of the Designated Experts I wanted to share my 
 concerns sooner rather than later.
>>> 
>>> 
>>> I appreciate that.  Do others share Les’ perspective on the relative 
>>> tradeoffs?  Especially our other Desginated Experts?
>>> 
>>> 
 Would this argue for advertising “this is a boundary circuit” in 
 pseudo-node LSPs for boundary circuits rather than advertising “inside” on 
 all inside pseudo-nodes?
   
 You could do it that way.  It inverts the semantics and inverts the 
 deployment.  Logically, it should have the same effect.  However, it then 
 is seen by outside nodes.  Since they need not support Area Proxy, this 
 seemed like a riskier approach, thus we opted for marking inside 
 pseudonodes.
  
 [Les:] My point was largely motivated by the statement in the draft:
  
 “Area Proxy Boundary multi-access circuits (i.e.  Ethernets in LAN
mode) with multiple Inside Edge Routers on them are not supported.”
  
 So it seems advantageous to be able to prevent this from happening – which 
 requires some signaling on the circuit in question.
>>> 
>>> 
>>> 
>>> I think that the case that you’re concerned about is already easily 
>>> detected.  Recall that an Inside Edge router will generate IIH’s onto a 
>>> boundary circuit using the Proxy system ID.  Thus, if an Inside Edge router 
>>> receives an IIH with a source address of it’s own proxy system id, then it 
>>> has encountered this issue.
>>> 
>>> Tony
>>> 
>>> 
>>> ___
>>> 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-19.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 Application-Specific Link Attributes
Authors : Les Ginsberg
  Peter Psenak
  Stefano Previdi
  Wim Henderickx
  John Drake
Filename: draft-ietf-isis-te-app-19.txt
Pages   : 22
Date: 2020-06-29

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-19
https://datatracker.ietf.org/doc/html/draft-ietf-isis-te-app-19

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


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] I-D Action: draft-ietf-lsr-ospf-reverse-metric-01.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   : OSPF Reverse Metric
Authors : Ketan Talaulikar
  Peter Psenak
  Hugh Johnston
Filename: draft-ietf-lsr-ospf-reverse-metric-01.txt
Pages   : 12
Date: 2020-06-29

Abstract:
   This document specifies the extensions to OSPF that enables a router
   to signal to its neighbor the metric that the neighbor should use
   towards itself using link-local advertisement between them.  The
   signalling of this reverse metric, to be used on link(s) towards
   itself, allows a router to influence the amount of traffic flowing
   towards itself and in certain use-cases enables routers to maintain
   symmetric metric on both sides of a link between them.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospf-reverse-metric-01
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-reverse-metric-01


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