, 2020 11:46 PM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee) ; Bruno Decraene
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Hi Les,
1)Invent a new type of SID which is associated with an area.
In this case some variation of encodings defined in V2 of the draft
Hi Les,
> 1)Invent a new type of SID which is associated with an area.
> In this case some variation of encodings defined in V2 of the draft are
> appropriate.
But these aren’t backward compatible, which operators clearly want.
> 2)Use a reachable address to get to the area. That address
: Tony Li
Sent: Thursday, August 06, 2020 2:42 PM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee) ; Bruno Decraene
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Les,
Not sure why this needs to be explained.
Because we are not communicating well. We are each making
Les,
> Not sure why this needs to be explained.
Because we are not communicating well. We are each making unstated assumptions
that do not mesh.
When we do not communicate, it’s time to double check the basics.
> Whether you are doing label forwarding or IP forwarding, the path of the
>
Hi Tony
See section 3.3.1 of RFC 8402 SR Architecture
https://tools.ietf.org/html/rfc8402#section-3.3.1
It has a nice graphical explanation of SR-MPLS Anycast usage.
The concept of Anycast SID is similar to Multicast group GDA conceptually
and similar to IGP routing anycast construct of
would not like to go down that path…
Les
From: Tony Li
Sent: Thursday, August 06, 2020 9:32 AM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee) ; Bruno Decraene
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Les,
There then remains the question as to whether
Les,
> There then remains the question as to whether the “Area Prefix” is anycast
> or unicast i.e., is it common to all IERs or is it unique to whomever gets
> elected Area Leader?
>
> Does it matter? We have no clear semantics for this prefix. A difference that
> makes no difference is
Tony -
From: Tony Li
Sent: Wednesday, August 05, 2020 4:26 PM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee) ; Bruno Decraene
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Les,
This would make the Area Prefix mandatory for Area Proxy, which is not desired.
We
Les,
> This would make the Area Prefix mandatory for Area Proxy, which is not
> desired. We would prefer it to remain optional and thus part of the Area SID
> sub-TLV.
>
> [Les2:] You can advertise the Area Prefix in an optional sub-TLV – just as
> you did with the Area SID. That is what I
Tony -
From: Tony Li
Sent: Wednesday, August 05, 2020 1:08 PM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee) ; Bruno Decraene
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Les,
a)Advertise the “Area Prefix” in the Area Proxy TLV – much as we do a router-id
today
Hi Bruno
>From an operators perspective your creative idea of using the existing SR
machinery using the node SID to advertise the Area SID in the Proxy LSP is
very attractive to be able to support the feature immediately without
requiring a feature upgrade to support.
This idea really helps the
Les,
> a)Advertise the “Area Prefix” in the Area Proxy TLV – much as we do a
> router-id today in the Router-ID TLV.
This would make the Area Prefix mandatory for Area Proxy, which is not desired.
We would prefer it to remain optional and thus part of the Area SID sub-TLV.
> b)The
Acee -
From: Acee Lindem (acee)
Sent: Wednesday, August 05, 2020 12:31 PM
To: Tony Li ; Bruno Decraene
Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Hi Tony, Bruno, Les,
From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of To
Hi Tony, Bruno, Les,
From: Lsr on behalf of Tony Li
Date: Tuesday, August 4, 2020 at 11:26 AM
To: Bruno Decraene
Cc: "Les Ginsberg (ginsberg)" , "lsr@ietf.org"
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Hi Bruno,
[Bruno] Agreed so far.
Do we agree that
Hi Bruno,
>
> [Bruno] Agreed so far.
> Do we agree that draft-ietf-lsr-isis-area-proxy uses the SID/Label sub-TLV?
> We both agree that this sub-TLV has no mention of the global flag nor the
> routing algoto be used.
So far, we do NOT have agreement on that. Your argument yesterday
Behalf Of
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Tuesday, August 04, 2020 5:45 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Hi,
I may be missing something but the SR Binding SID TLV extension is not clear
to me.
1)
Bruno -
Please see inline.
From: Lsr On Behalf Of bruno.decra...@orange.com
Sent: Tuesday, August 04, 2020 5:45 AM
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Hi,
I may be missing something but the SR Binding SID TLV extension is not clear
to me.
1. It does
Hi,
I may be missing something but the SR Binding SID TLV extension is not clear
to me.
1) It does not seem compliant with RFC 8667
Draft says that the advertisement has: T-flag set, M & A flags cleared,
SID/Label sub-TLV present, Prefix-SID sub-TLV NOT present
The following
to be consistent with its use in PSP logic - OK -
but I think this is unnecessary.
Les
From: Lsr On Behalf Of bruno.decra...@orange.com
Sent: Thursday, July 30, 2020 9:46 AM
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Hi authors,
Please find below some feedback for information
Hi authors,
Please find below some feedback for information. Feel free to ignore.
4.4.13. The Area SID
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.13
"The following extensions to the Binding TLV are defined in order to
support Area SID:
A new flag
20 matches
Mail list logo