Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Shraddha Hegde]

Peter,


Thanks for the conclusion on adding L-bit clarification in the 
draft-ietf-lsr-flex-algo.

Snip to open comments.

> Note that earlier versions of this document did not mandate use of 
> ASLA TLVs and hence may not inter-operate with early implementations that use 
> legacy advertisements."

>it is not true that "earlier versions of this document" did not 
mandate ASLA.


>https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00__;!!NEt6yMaO-
  >gk!RUa9k_d9lRrtd0sWrxv0etOr8GgsX8OFkI2_dSn0NHSFhML69iDpCNENxE2fpgF3$ , 
which only supported the >  >include/exclude Admin Groups, clearly stated:

https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/
https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/

https://mailarchive.ietf.org/arch/browse/lsr/?q=LSR%20Working%20Group%20Adoption%20Poll%20for%20Flex%20Algorithm%20Drafts

The above two drafts were polled for WG adoption. These two drafts did not have 
any reference to te-app draft.

There was no discussion in the WG about ASLA TLV during the adoption call. When 
the WG adopted draft was posted, that merged the ISIS and OSPF drafts and the 
non-backward compatible text mandating ASLA TLV was introduced. The link to 
this draft, you have copied in the mail above.


I think it is fair to warn the operators on the possible inter-op issues this 
could cause.
I would like to see the above sentence added to the draft.


Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Thursday, September 3, 2020 1:25 PM
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[External Email. Be cautious of content]


Hi Shraddha,

On 03/09/2020 05:39, Shraddha Hegde wrote:
> Peter,
>
> In order to make the document clearer on this point, I would like the 
> text below to be added to section 11 to make it explicit that setting the 
> L-bit is valid for flex-algo for ISIS.
>
> =
> Section 11.
>
> “The ASLA TLV in ISIS supports the L-Bit as described in section 4.2 
> of [draft-ietf-isis-te-app]. When the L-bit is set, applications MUST 
> use legacy advertisements for that link. Flex algorithm application 
> MUST support sending and receiving link attributes with ASLA TLV having L-bit 
> set.


I can add the above, although, it's clear from the draft-ietf-isis-te-app that 
L-bit with legacy advertisement MAY be used for any app.

>
> Note that earlier versions of this document did not mandate use of 
> ASLA TLVs and hence may not inter-operate with early implementations that use 
> legacy advertisements."

it is not true that "earlier versions of this document" did not mandate ASLA.

https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00__;!!NEt6yMaO-gk!RUa9k_d9lRrtd0sWrxv0etOr8GgsX8OFkI2_dSn0NHSFhML69iDpCNENxE2fpgF3$
 , which only supported the include/exclude Admin Groups, clearly stated:


9.  Advertisement of Link Attributes for Flex-Algorithm

Various link include or exclude rules can be part of the Flex-
Algorithm definition.  These rules use Admin Groups (AG) as defined
in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG)
as defined in [RFC7308].

To advertise a link affinity in a form of the AG or EAG that is used
during Flex-Algorithm calculation, an Application Specific Link
Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV
of Extended Link TLV as described in
[I-D.ietf-ospf-te-link-attr-reuse] MUST be used.  The advertisement
MUST indicate that it is usable by the Flex-Algorithm application.


thanks,
Peter



> 
>
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Peter Psenak 
> Sent: Wednesday, September 2, 2020 2:43 PM
> To: Shraddha Hegde ; olivier.dug...@orange.com; 
> tony...@tony.li; Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; 
> Acee Lindem (acee) 
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>
> [External Email. Be cautious of content]
>
>
> Hi Shraddha,
>
> please see inline:
>
>
> On 02/09/2020 06:45, Shraddha Hegde wrote:
>> Peter,
>>
>> It is worthwhile to note the history of the flex-algo draft and the 
>> te-app draft and how many  backward incompatible changes have been 
>> introduced in the course of the flex-algo draft.
>>
>> The original drafts of flex-algo did not mention the te-app draft and 
>> was completely based on legacy advertisements.
>> Two years ago, after the working group adopted the original drafts 
>> without the ASLA TLV, the text was changed to require the ASLA TLV.
>
> draft-ietf-lsr-flex-algo-00, whi

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi Peter,

> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Thursday, September 3, 2020 9:55 AM
> 
> Hi Shraddha,
> 
> On 03/09/2020 05:39, Shraddha Hegde wrote:
> > Peter,
> >
> > In order to make the document clearer on this point, I would like the text
> below to be added
> > to section 11 to make it explicit that setting the L-bit is valid for 
> > flex-algo for
> ISIS.
> >
> > =
> > Section 11.
> >
> > “The ASLA TLV in ISIS supports the L-Bit as described in section 4.2 of
> > [draft-ietf-isis-te-app]. When the L-bit is set, applications MUST use
> > legacy advertisements for that link. Flex algorithm application MUST
> support
> > sending and receiving link attributes with ASLA TLV having L-bit set.
> 
> 
> I can add the above, 

Yes please. (It's not clear to me whether "can add" means "will add" or "could 
add". So better safe than sorry).

Also in §5.1:

" 1: Min Unidirectional Link Delay as defined in [RFC8570],
 section 4.2, encoded in the Application Specific Link
 Attributes Sub-TLV [I-D.ietf-isis-te-app]."

It could be read as the delay (value) needs to be encoded in the ASLA 
Attributes Sub-TLV, while when the L-bit is set, the delay (value) is encoded 
in the RFC8570 sub-TLV.
So in order to avoid interop issues, I'd appreciate if you could clarify.
May be :s/in/as per
Or :s/./or in the RFC8570 Sub-TLV when the ASLA L-Flag is set.
Or whatever change at your preference. 

Then same comment for Metric-Type 2 (TE Metric), in the next sentence.


Thank you,
Regards,
--Bruno


> although, it's clear from the
> draft-ietf-isis-te-app that L-bit with legacy advertisement MAY be used
> for any app.
> 
> >
> > Note that earlier versions of this document did not mandate use of ASLA
> TLVs
> > and hence may not inter-operate with early implementations that use
> legacy advertisements."
> 
> it is not true that "earlier versions of this document" did not mandate
> ASLA.
> 
> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00, which only
> supported the include/exclude Admin Groups, clearly stated:
> 
> 
> 9.  Advertisement of Link Attributes for Flex-Algorithm
> 
> Various link include or exclude rules can be part of the Flex-
> Algorithm definition.  These rules use Admin Groups (AG) as defined
> in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG)
> as defined in [RFC7308].
> 
> To advertise a link affinity in a form of the AG or EAG that is used
> during Flex-Algorithm calculation, an Application Specific Link
> Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV
> of Extended Link TLV as described in
> [I-D.ietf-ospf-te-link-attr-reuse] MUST be used.  The advertisement
> MUST indicate that it is usable by the Flex-Algorithm application.
> 
> 
> thanks,
> Peter
> 
> 
> 
> > 
> >
> >
> > Rgds
> > Shraddha
> >
> >
> > Juniper Business Use Only
> >
> > -Original Message-
> > From: Peter Psenak 
> > Sent: Wednesday, September 2, 2020 2:43 PM
> > To: Shraddha Hegde ;
> olivier.dug...@orange.com; tony...@tony.li; Robert Raszuk
> 
> > Cc: Christian Hopps ; draft-ietf-lsr-flex-
> algo@ietf.org; Les Ginsberg (ginsberg)
> ; lsr@ietf.org; lsr-...@ietf.org;
> Acee Lindem (acee) 
> > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi Shraddha,
> >
> > please see inline:
> >
> >
> > On 02/09/2020 06:45, Shraddha Hegde wrote:
> >> Peter,
> >>
> >> It is worthwhile to note the history of the flex-algo draft and the
> >> te-app draft and how many  backward incompatible changes have been
> >> introduced in the course of the flex-algo draft.
> >>
> >> The original drafts of flex-algo did not mention the te-app draft and
> >> was completely based on legacy advertisements.
> >> Two years ago, after the working group adopted the original drafts
> >> without the ASLA TLV, the text was changed to require the ASLA TLV.
> >
> > draft-ietf-lsr-flex-algo-00, which was the initial version of the WG
> document already mandated the ASLA usage. I don't believe we have to go
> back to the individual drafts that predated the WG version.
> >
> >>
> >>
> >> ASLA TLV had the L-Bit and it was always valid to advertise link
> >> attributes for flex-algo with L-bit set which means the link
> >> attributes could still be sent in legacy TLVs.
> >> In a conversation last year, you had agreed that advertising link
> >> attributes with L-bit set is valid for Flex-algo.
> >
> >
> > what we say in flex-algo draft in section 11 is:
> >
> >  "Link attribute advertisements that are to be used during Flex-
> >  Algorithm calculation MUST use the Application-Specific Link
> >  Attribute (ASLA) advertisements defined in [I-D.ietf-isis-te-app] or
> >  [I-D.ietf-ospf-te-link-attr-reuse]."
> >
> > ietf-isis-te-app clearly allows the app specific value of the attribute to 
> > be
> advertised in legacy TLV

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[tony . li]

Hi Bruno,


> At this point, area proxy spec is clear with regards to nominal behavior. So 
> indeed we are discussing error handling / transitions. (and thank you for 
> considering those cases, much appreciated).
>  
> From memory, my understanding is the area proxy nominal behaviour requires:
> -  All routers in the area are L1 & L2
> -  All inside routers advertise the area proxy TLV
> -  An area leader advertises the Area Proxy System Identifier Sub-TLV


Something that we’re not allowed to talk about in the spec is that we’re 
assuming that ALL routers in the Inside Area are configured to enable Area 
Proxy.  Partial configuration is a misconfiguration or transitional to full 
configuration.

 
> If the above is not fulfilled, what is the expected behaviour? There is a 
> priori 2 options:
> -  A) Return to regular IS-IS behaviour. i.e. all L2 LSPs from inside 
> routers are flooded to L2 outside routers
> o   Pro: no new behaviour/code as this is regular IS-IS. Correct transit 
> forwarding across the area.
> o   Con: suddenly increase size of L2 LSDB
> -  B) Keep filtering L2 LSP from inside routers
> o   Pro: no sudden increase of L2 LSDB size
> o   Con: transit traffic is partially dropped (if area LSP advertised while 
> some routers are L1 only), no transit is possible (if area LSP is not 
> advertised), or partial transit (some inside edge node do not advertise the 
> area proxy TLV).
> §  Lack of transit is not an issue if there is a backup proxy area (e.g. a 
> proxy area a replace a big single chassis).  It’s likely an issue is there is 
> no backup proxy area (e.g. the area has built-in redundancy (e.g. spife/leaf) 
> hence there is no need for another/backup proxy area. Network operator needs 
> to be well aware in order to choose the correct design (rather than 
> experience a bad surprise)
>  
> That’s an open question.
> As this point I do not have a preference, although naively I had “A” in mind. 
> From your below answer, I think that you have “B” in mind. 


Yes. Given the above assumption, we want to assume transition.


> A priori the choice may be dependent on the missing condition.
> Possibly this could be clarified in a “operational consideration” or “error 
> handling” section for network operator to be aware of the behaviour under 
> failure/transition condition.


I’m open to suggestions and/or contributions.


> FYI, I’m considering such failure to be plausible over the years as all it 
> need is one L1 router to boot and not advertise the area proxy TLV or be 
> configured as L1 only.


30 years of doing this says that any crazy thing is possible and WILL happen 
somewhere, someplace in the fullness of time. Yes, ok, withdrawing the Proxy 
LSP in these cases is probably not optimal.  What should we say instead? Some 
failures are clearly fatal, some are not. What’s the right thing to do without 
a dissertation worth of analysis and special cases?

Tony


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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[bruno.decraene]

Hi Tony,

Thanks for your reply.
At this point, area proxy spec is clear with regards to nominal behavior. So 
indeed we are discussing error handling / transitions. (and thank you for 
considering those cases, much appreciated).

From memory, my understanding is the area proxy nominal behaviour requires:

-  All routers in the area are L1 & L2

-  All inside routers advertise the area proxy TLV

-  An area leader advertises the Area Proxy System Identifier Sub-TLV

If the above is not fulfilled, what is the expected behaviour? There is a 
priori 2 options:

-  A) Return to regular IS-IS behaviour. i.e. all L2 LSPs from inside 
routers are flooded to L2 outside routers

o   Pro: no new behaviour/code as this is regular IS-IS. Correct transit 
forwarding across the area.

o   Con: suddenly increase size of L2 LSDB

-  B) Keep filtering L2 LSP from inside routers

o   Pro: no sudden increase of L2 LSDB size

o   Con: transit traffic is partially dropped (if area LSP advertised while 
some routers are L1 only), no transit is possible (if area LSP is not 
advertised), or partial transit (some inside edge node do not advertise the 
area proxy TLV).

§  Lack of transit is not an issue if there is a backup proxy area (e.g. a 
proxy area a replace a big single chassis).  It’s likely an issue is there is 
no backup proxy area (e.g. the area has built-in redundancy (e.g. spife/leaf) 
hence there is no need for another/backup proxy area. Network operator needs to 
be well aware in order to choose the correct design (rather than experience a 
bad surprise)

That’s an open question.
As this point I do not have a preference, although naively I had “A” in mind. 
From your below answer, I think that you have “B” in mind.
A priori the choice may be dependent on the missing condition.
Possibly this could be clarified in a “operational consideration” or “error 
handling” section for network operator to be aware of the behaviour under 
failure/transition condition.
FYI, I’m considering such failure to be plausible over the years as all it need 
is one L1 router to boot and not advertise the area proxy TLV or be configured 
as L1 only.

Regards,
--Bruno
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Saturday, September 5, 2020 2:43 AM
To: DECRAENE Bruno TGI/OLN 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi Bruno,



“A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an 
Outside Router. »
Agreed (so far)

“A Level 2 LSP with a source system identifier that is found in the Level 1 
LSDB MUST NOT be flooded to an Outside Router.”
I’m not sure to agree.
If that LSP carries the Area Proxy TLV, the previous rule is enough.
If that LSP does not carry the Area Proxy TLV, then no Area Leader advertise 
the Area Proxy System Identifier Sub-TLV and hence the new Area Proxy is not 
enabled. In which case I feel that normal IS-IS flooding should occur, and 
L1-L2 nodes should have their L2 LSP flooded.
So, I would propose to remove that sentence which doesn’t seem needed.


This was intentional. We are trying to protect against a case where a router 
boots and has not yet processed its full configuration yet.  It could easily 
generate an LSP prior to adding the Area Proxy TLV.
This could also happen during the transition to Area Proxy, where an Inside 
Node has not yet been configured for Area Proxy.

We are trying to prevent flooding of its LSP to the Outside Area because that 
may confuse other L2 nodes.


“A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an 
Outside Router. »
I think we additionally need that an Area Leader advertise the Area Proxy 
System Identifier Sub-TLV.


We already say:

  The Area Leader has several responsibilities.  First, it MUST
   inject the Area Proxy System Identifier into the Level 2
   LSDB.



Otherwise, hence the new Area Proxy is not enabled. I which case I feel that 
normal IS-IS flooding should occur, and L1-L2 nodes should have their L1 & L2 
LSP flooded.
That condition would seem application to the whole section 5.2 or even to the 
whole section 5



Again, we want to restrict flooding if Area Proxy is configured, even if it’s 
not fully enabled.  Again, we’re just trying to make the transition as smooth 
as possible.


Tony



_

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 

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

[Robert Raszuk]

Hi Aijun,

> the BGP next-hop is reachable

Nope you missed the crux of the message.

The next hop will be unreachable in the *source area/level. *That would be
where the BGP service route withdraw or aggregate withdraw would originate
at. Same as PUA.

Best,
Robert.


On Mon, Sep 7, 2020 at 11:31 AM Aijun Wang 
wrote:

> Hi, Robert:
>
> For BGP next-hop tracking, it will help when the BGP next-hop is
> unreachable. But in our situation, the BGP next-hop is reachable, but
> should pass another ABR.
>
> Then, in such situation, the mechanism of BGP next-hop tracking will not
> take effect?
>
> And thanks for your draft information, maybe we can refer to it later J
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of 
> *Robert
> Raszuk
> *Sent:* Monday, September 7, 2020 4:54 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Peter Psenak ;
> Huzhibo ; Aijun Wang ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Xiaoyaqun <
> xiaoya...@huawei.com>; Tony Przygienda 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun,
>
> *[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for
> the hold of PUA information on the nodes) among the area.*
>
> *If one node connect to the network after the disappearance of the PUA
> destination,  there will be no services can be established/run on these
> failure node/link prefix. *
>
> *It**’s the same as the beginning, as not all of the prefixes can be
> reachable within the summary address.*
>
>
>
> From my pov the only advantage of negative routes in IGP would be to very
> quickly invalidate service routes (within the IGP domain) typically carried
> by BGP.
>
>
>
> When this is accomplished the PUA can indeed time out with no harm.
>
>
>
> Said this - now considering tools like next hop tracking which can trigger
> withdraw or aggregated withdraw(*) proposal in src area I am  really
> curious how much (if anything) we would be gaining here.
>
>
>
> (*) The original proposal for this was written over 15 years ago:
> https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could
> extend it with next hop which would be the same as IGP PUA prefix.
>
>
>
> Kind regards,
> Robert
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Hi, Robert:

For BGP next-hop tracking, it will help when the BGP next-hop is unreachable. 
But in our situation, the BGP next-hop is reachable, but should pass another 
ABR.

Then, in such situation, the mechanism of BGP next-hop tracking will not take 
effect?

And thanks for your draft information, maybe we can refer to it later J

 

Best Regards

 

Aijun Wang

China Telecom

 

 

From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Robert 
Raszuk
Sent: Monday, September 7, 2020 4:54 PM
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
; Peter Psenak ; 
Huzhibo ; Aijun Wang ; lsr 
; Acee Lindem (acee) ; Xiaoyaqun 
; Tony Przygienda 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Hi Aijun,

[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for the 
hold of PUA information on the nodes) among the area.

If one node connect to the network after the disappearance of the PUA 
destination,  there will be no services can be established/run on these failure 
node/link prefix. 

It’s the same as the beginning, as not all of the prefixes can be reachable 
within the summary address.

 

>From my pov the only advantage of negative routes in IGP would be to very 
>quickly invalidate service routes (within the IGP domain) typically carried by 
>BGP. 

 

When this is accomplished the PUA can indeed time out with no harm. 

 

Said this - now considering tools like next hop tracking which can trigger 
withdraw or aggregated withdraw(*) proposal in src area I am  really curious 
how much (if anything) we would be gaining here. 

 

(*) The original proposal for this was written over 15 years ago: 
https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could extend it 
with next hop which would be the same as IGP PUA prefix. 

 

Kind regards,
Robert

 

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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[bruno.decraene]

Hi Tony,

Thanks for your reply.
All good to me.

Thanks,
--Bruno


From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Saturday, September 5, 2020 2:18 AM
To: DECRAENE Bruno TGI/OLN 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi Bruno,

Thank you for your comments.

1)

OLD: The
   advertisement in the Proxy LSP informs the remainder of the network
   that packets directed to the SID will be forwarded by one of the
   Inside Edge Nodes and the Area SID will be consumed.

NEW:

The

   advertisement in the Proxy LSP informs the outside area

   that packets directed to the SID will be forwarded to one of the

   Inside Edge Nodes and the Area SID will be consumed.

Motivation:
1)  More precise/descriptive and use the terminology defined in the draft
2)  The SID is a priori global in the outside area and hence will be 
forwarded by all nodes in the outside area (and not just by the Inside Edge 
Nodes). The destination is anycast to/toward any Inside Edge node.


Ok.



2)
§ 4.3.2.  The Area SID Sub-TLV

The Area SID Sub-TLV allows the Area Leader to advertise a prefix and

   SID



§4.4.13.  The Area SID

  The Area Leader SHOULD advertise the Area SID information in the

   Proxy LSP as a Node SID as defined in [RFC8667] Section 
2.1.


RFC8667 requires that for a Node SID, the prefix be an IP address (/32 or /138) 
(rather than an IP prefix of an arbitrary length) [1].
[1] https://tools.ietf.org/html/rfc8667#section-2.1.1.2

You may want to refer to this restriction when defining the Area SID Sub-TLV in 
section 4.3.2 . e.g. :s/advertise a prefix/advertise an IP address. 
Alternatively open the option to advertise a prefix SID without the N-Flag if 
this is a prefix.


We are implicitly doing that by permitting a prefix.



3)
1 typo in -04 :s/ Inisde/ Inside


Fixed, thanks.



4)
OLD:
The Area Leader will generate a Proxy LSP that must be flooded across
   the Inside Area.  Inside Routers MUST ignore the contents of the
   Proxy LSP other than for flooding

My personal preference would be
NEW
The Area Leader will generate a Proxy LSP that will be flooded across
   the Inside Area.  Inside Routers MUST ignore the contents of LSP(s) 
originated with the Area Proxy System Identifier other than for flooding.

Motivation:
a)  Clarify that no new behavior is involved
b)  Specifies how the proxy LSP is to be identified as a proxy LSP.



?  Ignoring the contents of an LSP is a new behavior.  I propose something 
slightly different:

  The Area Leader will generate a Proxy LSP that will be
  flooded across the Inside Area.  Inside Routers MUST ignore
  the contents of the Proxy LSP other than for flooding.  The
  Proxy LSP uses the Area Proxy System Identifier as its Source
  ID.




5) Open question: is the Area Proxy LSP to be advertised/read from L1 or L2 
LSP/LSDB or both?

“All routers within the Inside Area speak Level 1 and Level 2 IS-IS on all of 
the links within the topology.”
OK.

“A node advertises the Area Proxy TLV in its L2 LSP”
So my reading/guessing is that the Area Proxy TLV is only sent in the L2 LSP of 
all Inside routers. (i.e. not in the L1 LSP).
If so:
-  Can you clarify the behavior when an Area Proxy TLV is received in 
an L1 LSP? (e.g. ignore, and if not, what is the behavior when the TLV is 
different in L1 and L2).


We already say:

   The Area Leader MUST advertise the Area Proxy System
   Identifier Sub-TLV when it observes that all Inside Routers
   are advertising the Area Proxy TLV.

The statement that you quote is pretty clear that the Area Proxy TLV is found 
in the L2 LSP.  I take it that you feel that this is insufficient.
I propose to add:

 Nodes MUST NOT advertise the Area Proxy TLV in a L1 LSP. Nodes MUST
  ignore the Area Proxy TLV if it is found in a L1 LSP.



-  “they will advertise the Area Proxy TLV.” May be adding “in their L2 
LSP”


Ok.



-  “All Inside Edge Routers learn the Area Proxy System Identifier from 
the Level 1 LSDB”. I would have assumed  “from the Area Proxy TLV advertised in 
the level 2 LSDB.  So it may be a typo or I’m missing something, which is very 
possible.


That was a bug, thanks.  I changed it to: “ … from the Area Proxy TLV 
advertised by the Area Leader … “



o   “it MUST inject   the Area Proxy System Identifier into the Level 1 LSDB.” 
Same comment.


Also a bug.  Should be L2.  Fixed.


Thanks for the detailed review!


Tony


_

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'exped

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

[Robert Raszuk]

Hi Aijun,

> *[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for
> the hold of PUA information on the nodes) among the area.*
>
> *If one node connect to the network after the disappearance of the PUA
> destination,  there will be no services can be established/run on these
> failure node/link prefix. *
>
> *It’s the same as the beginning, as not all of the prefixes can be
> reachable within the summary address.*
>
>
>From my pov the only advantage of negative routes in IGP would be to very
quickly invalidate service routes (within the IGP domain) typically carried
by BGP.

When this is accomplished the PUA can indeed time out with no harm.

Said this - now considering tools like next hop tracking which can trigger
withdraw or aggregated withdraw(*) proposal in src area I am  really
curious how much (if anything) we would be gaining here.

(*) The original proposal for this was written over 15 years ago:
https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could extend
it with next hop which would be the same as IGP PUA prefix.

Kind regards,
Robert
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr