Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-31 Thread tony . li
Hi Bruno, Thank you for the clarification. I understand completely what you’re trying to do and I agree that it’s valuable. The downside of your approach is that the Area Leader will now need configuration of a new prefix to advertise as the Node SID. Not unthinkable. What do the Inside Nodes

Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

2020-07-31 Thread Thomas.Graf
Hi Hannes, Thanks a lot for the feedback. Yes, makes completely sense. Will take it for the next update. Best Wishes Thomas From: Hannes Gredler Sent: Wednesday, July 29, 2020 9:31 AM To: Graf Thomas, INI-NET-DCF Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thoma

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-31 Thread Robert Raszuk
> > [WAJ] Such information is for underlay link state and should be flooded > via IGP? The ambiguity arises from IGP summary behavior and should be > solved by itself? > Well if we look at this problem from a distance while on surface it seems like an IGP issue (not to mention some which use BGP a

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-31 Thread bruno.decraene
Hi Tony, Thank you for your reply. Top posting the description of the use case that I have in mind. Ø First off, the Area SID is 100% optional. If you choose not to use it, then the Proxy LSP should be 100% compatible with a standard L2 node. Good. But I think that the idea of the Area SID is

Re: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-31 Thread bruno.decraene
Les, From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Thursday, July 30, 2020 7:29 PM To: DECRAENE Bruno TGI/OLN ; tony...@tony.li; lsr@ietf.org Subject: RE: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt Bruno – One of the reasons to use the Bindi