Re: [Lsr] some doubts about RFC3101

[meicong]

Hi Acee,
Thanks for your answer.
In the example,
If the type-5 lsa is originated by the ASBR that in the normal area,
the other router in the normal area will use the type-5 lsa,
for the ASBR is reachable in the normal area,
and there is (128.185.1.0, 0xff00) inter-area route that be orignated by 
the abr in routing table of  other router,
and the calculated result for the type-5 lsa is path to the abr,
but there is no path on the abr, because the route (128.185.1.0, 0xff00) is 
intra-route of Nssa area on the abr.
In the scenario, the fowarding address is advertised by differnet router in 
different capable area with different netmask.
It maybe fall under a configed error, but the result of the calculate result 
seems wrong.
What is your opinion for it?
Regards

发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2019年12月5日 20:40
收件人: meicong ; lsr@ietf.org
主题: Re: [Lsr] some doubts about RFC3101

Hi Meicong,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
meicong mailto:meic...@huawei.com>>
Date: Thursday, December 5, 2019 at 4:48 AM
To: "lsr@ietf.org" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-ospf-nssa-upd...@ietf.org"
 
mailto:draft-ietf-ospf-nssa-upd...@ietf.org>>
Subject: [Lsr] some doubts about RFC3101


Hi All,
Could you please provide clarification for following section 2.5.(3) in rfc3101.

  If the forwarding address is non-zero look up the forwarding
  address in the routing table.  For a Type-5 LSA the matching
  routing table entry must specify an intra-area or inter-area
  path through a Type-5 capable area.  For a Type-7 LSA the
  matching routing table entry must specify an intra-area path
  through the LSA's originating NSSA.  If no such path exists
  then do nothing with this LSA and consider the next in the
  list.
  [NSSA]

In the section, the matching routing table entry of the forwarding address is 
limited("an intra-area or inter-area path through a Type-5 capable area" or "an 
intra-area path through the LSA's originating NSSA").
If the best matching routing table entry for the forwarding address does not 
match the limited, the secondory best matching routing table entry should be 
find or not?

e.g., the forwarding address of a Type-5 LSA is 128.185.1.1,
and there are two routing table entry int the routing table on the abr,
(128.185.1.0, 0xff00) intra-area route of the NSSA area,
(128.185.0.0, 0x) intra-area route of the normal area(Type-5 capable 
area),
The path of the forwarding address should be consider as exist or not?

The short answer is no. The OSPF AS-External LSA should not be used since the 
forwarding address is not reachable through a normal area. As one would expect, 
the route lookup is always a longest prefix lookup. Note that having NSSA 
routes implies that the computing OSPF router is an ABR with both normal and 
NSSA area(s). One would expect that prefix being computed would also have a 
corresponding OSPF NSSA LSA that would satisfy the reachability check. If not, 
something in the OSPF routing design is broken.

Hope this helps,
Acee



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

Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-ospf-ospfv2-hbit-11: (with COMMENT)

[Benjamin Kaduk]

On Wed, Dec 04, 2019 at 10:22:53AM -0800, Padma Pillay-Esnault wrote:
> Hi Ben
> 
> Thanks for your thorough review.
> 
> See below PPE for my comments
> 
> On Tue, Dec 3, 2019 at 5:45 PM Benjamin Kaduk via Datatracker <
> nore...@ietf.org> wrote:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-ospf-ospfv2-hbit-11: 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-ospfv2-hbit/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > Abstract
> >
> >The Open Shortest Path First Version 2 (OSPFv2) does not have a
> >mechanism for a node to repel transit traffic if it is on the
> >shortest path.  This document defines a bit (Host-bit) that enables a
> >
> > nit: I suggest to add "protocol" after "(OSPFv2)" to match the definite
> > article "The".
> >
> > PPE - ok
> 
> 
> > Section 1
> >
> >The OSPFv2 specifies a Shortest Path First (SPF) algorithm that
> >
> > (same nit about adding "protocol")
> >
> > PPE - ok
> 
> 
> >This functionality is particularly useful for a number of use cases:
> >
> > nit: "this functionality" seems to refer to "the SPF algorithm that
> > identifies transit verticies based on their adjacencies", so I suggest
> > rewording to "such functionality would be useful" or "A mechanism to
> > move traffic away from the shortest path" or similar.
> >
> > PPE - ok will change as you suggest
> 
> Suggested NEW:
> "A mechanism to move traffic away from the shortest path is particularly
> useful for a number of use cases:"

Thanks!

> 
> > Section 4
> >
> > I suggest noting that the (lettered) sub-procedures of step (2) remain
> > unchanged.
> >
> > PPE - The original format of OSPF rfc2328 steps for SPF calculation was
> kept for clarity. Would a sentence to that effect work?

I think so.  Basically, if a reader treats "step (2)" as including the
lettered sub-procedures, then our replacement version has stripped off all
the sub-procedures and not replaced them.  So we need to tell the reader
that we don't mean to include the sub-procedures in what is being replaced.

> 
> 
> > Section 5
> >
> >In normal operation, there is no guarantee that the RI LSA will reach
> >all routers in an area in a timely manner, which may result in
> >forwarding loops in partial deployments.  For example, if a new
> >router joins an area, which previously had only H-bit capable routers
> >with H-bit set then it may take some time for the RI to propagate to
> >all routers.
> >
> > It's currently only implicit that this new router does not support the
> > H-bit; shall we make it explicit?
> >
> 
> PPE - ok
> 
> Suggested NEW:
>  If a new router without H-bit support joins an area, which previously had
> only H-bit capable routers
>  with H-bit set then it may take some time for the RI to propagate to all
> routers.
> 
> 
> 
> >o  All routers supporting H-Bit MUST check all the RI LSAs of nodes
> >   in the area before actively running the modified SPF to account
> >   for the H-bit in order to verify that all routers are in routing
> >   capability.  If any router does not advertise the Host Router
> >
> > nit: the grammar here is a little wonky, particularly for "all routers
> > are in routing capability" but perhaps also for "to account for the
> > H-bit".
> >
> > PPE -  agree
> 
> Suggested NEW:
> All routers supporting H-Bit MUST check all the RI LSAs of nodes in the
> area before actively
> running the modified SPF in order to verify that all routers in the area
> support the H-bit capability.

Looks good.

> 
> Section 6
> >
> >When calculating the path to an OSPF AS-External-LSA or NSSA-LSA
> >[RFC3101] with a Type-2 metric, [...]
> >
> > nit: is this saying "calculating the path to [an LSA]"?  That's not a
> > usage I'm familiar with; can the AS-External-LSA or NSSA-LSA really
> > serve as a destination in this sense?
> >
> > PPE - suggest adding the word " prefix" which was implicit here.

Thanks!

> 
> > Section 7
> >
> > Thank you for phrasing this as "this document requests the IANA to
> > assign", since until these specific values are officially assigned we
> > are technically "squatting" on them.  (The respective registration
> > policies of Standards Action and IETF Review give us pretty good control
> > that nothing else is going to swoop in on them, though.)
> >
> >
> >
> Let me know if these changes address your comments

They look good, 

[Lsr] IETF 106 LSR Working Group Meeting Minutes

[Acee Lindem (acee)]

I’ve uploaded the IETF 106 LSR minutes at 
https://datatracker.ietf.org/meeting/106/materials/minutes-106-lsr-00

Please send me any additions or corrections. Thanks much to Yingzhen Qu for 
compiling the minutes. As you can see, we had quite a lot of lively discussion 
during the sessions – especially with respect to IS-IS flooding flow-control 
mechanisms.

As I stated at the end of the second WG session – let’s keep this energy going 
between IETFs.

Thanks,
Acee

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

Re: [Lsr] "YANG Module for IS-IS Reverse Metric" - draft-hopps-lsr-yang-isis-reverse-metric-02

[tony . li]

I support WG adoption of this document.

Tony


> On Nov 25, 2019, at 4:27 AM, Acee Lindem (acee)  wrote:
> 
> This begins a two week LSR Working Group adoption call for the subject 
> document.
>  
> https://datatracker.ietf.org/doc/draft-hopps-lsr-yang-isis-reverse-metric/ 
> 
>  
> Please indicate your support or objection to adoption to the LSR list 
> (lsr@ietf.org ) prior to 12:00 AM UTC on December 10th, 
> 2019.
>  
> Thanks,
> 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] Barry Leiba's No Objection on draft-ietf-ospf-ospfv2-hbit-11: (with COMMENT)

[Barry Leiba]

Thanks, Padma... the new paragraph now seems completely clear to me!
Thanks for the work on this.

Barry

On Thu, Dec 5, 2019 at 1:03 AM Padma Pillay-Esnault
 wrote:
>
> Hi Barry
>
> Thank you for your review
>
> See below PPE for my comments
>
> On Wed, Dec 4, 2019 at 12:47 PM Barry Leiba via Datatracker 
>  wrote:
>>
>> Barry Leiba has entered the following ballot position for
>> draft-ietf-ospf-ospfv2-hbit-11: 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-ospfv2-hbit/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> I'm going to complain about some wording in Section 5 that Ben already called
>> out, but I'll try to put in some specific suggestions for corrections here:
>>
>>In normal operation, there is no guarantee that the RI LSA will reach
>>all routers in an area in a timely manner, which may result in
>>forwarding loops in partial deployments.
>>
>> This wording makes it sound exactly the opposite of what you mean, that if 
>> the
>> RI LSA *does* reach all routers in a timely manner it can cause forwarding
>> loops.  I suggest this:
>>
>> NEW
>>In normal operation, it is possible that the RI LSA will fail to
>>reach all routers in an area in a timely manner.  That can result
>>in forwarding loops in partial deployments.
>> END
>>
> PPE - See below for the whole paragraph change.
>
>>
>>For example, if a new
>>router joins an area, which previously had only H-bit capable routers
>>with H-bit set then it may take some time for the RI to propagate to
>>all routers.
>>
>> First, change "area, which" to "area that" (no comma).  That fixes a usage
>> problem.
>>
>> But second, Ben and I are both unsure whether you mean that the new router 
>> does
>> or doesn't support the H bit, or whether it matters.  Maybe the right 
>> approach
>> here is to say a little more about what happens.  Something like this (adjust
>> as needed to make it correct):
>>
>> NEW
>>For example, if a new
>>router joins an area that previously had only H-bit capable routers
>>with H-bit set then it may take some time for the RI to propagate to
>>all routers.  While it is propagating, the area as a whole is unsure of
>>the status of the new router, and that can cause 
>> END
>>
>
> PPE - I see what you mean.
> See below combining your suggestion and the one I made to Ben earlier.
>
> Suggested NEW (whole paragraph):
> In normal operation, it is possible that the RI LSA will fail to reach all 
> routers in an area in a timely manner.  For example, if a new router without 
> H-bit support joins an area that previously had only H-bit capable routers 
> with H-bit set then it may take some time for the RI to propagate to all 
> routers. While it is propagating, the routers in the area will gradually 
> detect the presence of a router not supporting the capability and revert back 
> to normal SPF calculation. During the propagation time, the area as a whole 
> is unsure of the status of the new router, and that can cause temporary 
> transient loops.
>  END
>
>>o  All routers, with the H-bit set, MUST advertise all of the
>>   router's non-stub links with a metric equal to MaxLinkMetric
>>
>> Both commas need to be removed here.
>
>
> PPE - ok
>>
>>
>>o  All routers supporting H-Bit MUST check all the RI LSAs of nodes
>>   in the area before actively running the modified SPF to account
>>   for the H-bit in order to verify that all routers are in routing
>>   capability.
>>
>> This is very awkwardly worded and is really hard to decipher.  I *think* you
>> mean to say this:
>>
>> NEW
>>o  All routers supporting the H-Bit MUST check the RI LSAs of all
>>   nodes in the area to verify that all nodes support the H-Bit before
>>   actively using the H-Bit feature.
>> END
>
>
>>
>> Did I get that right?
>>
>
> PPE - Yes you did. I will adopt the suggestion above. It is close to what I 
> suggested to Ben earlier.
>
> Let me know if this addresses all your comments
>
> Padma

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

Re: [Lsr] some doubts about RFC3101

[Acee Lindem (acee)]

Hi Meicong,

From: Lsr  on behalf of meicong 
Date: Thursday, December 5, 2019 at 4:48 AM
To: "lsr@ietf.org" 
Cc: "draft-ietf-ospf-nssa-upd...@ietf.org" 

Subject: [Lsr] some doubts about RFC3101


Hi All,
Could you please provide clarification for following section 2.5.(3) in rfc3101.

  If the forwarding address is non-zero look up the forwarding
  address in the routing table.  For a Type-5 LSA the matching
  routing table entry must specify an intra-area or inter-area
  path through a Type-5 capable area.  For a Type-7 LSA the
  matching routing table entry must specify an intra-area path
  through the LSA's originating NSSA.  If no such path exists
  then do nothing with this LSA and consider the next in the
  list.
  [NSSA]

In the section, the matching routing table entry of the forwarding address is 
limited("an intra-area or inter-area path through a Type-5 capable area" or "an 
intra-area path through the LSA's originating NSSA").
If the best matching routing table entry for the forwarding address does not 
match the limited, the secondory best matching routing table entry should be 
find or not?

e.g., the forwarding address of a Type-5 LSA is 128.185.1.1,
and there are two routing table entry int the routing table on the abr,
(128.185.1.0, 0xff00) intra-area route of the NSSA area,
(128.185.0.0, 0x) intra-area route of the normal area(Type-5 capable 
area),
The path of the forwarding address should be consider as exist or not?

The short answer is no. The OSPF AS-External LSA should not be used since the 
forwarding address is not reachable through a normal area. As one would expect, 
the route lookup is always a longest prefix lookup. Note that having NSSA 
routes implies that the computing OSPF router is an ABR with both normal and 
NSSA area(s). One would expect that prefix being computed would also have a 
corresponding OSPF NSSA LSA that would satisfy the reachability check. If not, 
something in the OSPF routing design is broken.

Hope this helps,
Acee



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

[Lsr] some doubts about RFC3101

[meicong]

Hi All,
Could you please provide clarification for following section 2.5.(3) in rfc3101.

  If the forwarding address is non-zero look up the forwarding
  address in the routing table.  For a Type-5 LSA the matching
  routing table entry must specify an intra-area or inter-area
  path through a Type-5 capable area.  For a Type-7 LSA the
  matching routing table entry must specify an intra-area path
  through the LSA's originating NSSA.  If no such path exists
  then do nothing with this LSA and consider the next in the
  list.
  [NSSA]

In the section, the matching routing table entry of the forwarding address is 
limited("an intra-area or inter-area path through a Type-5 capable area" or "an 
intra-area path through the LSA's originating NSSA").
If the best matching routing table entry for the forwarding address does not 
match the limited, the secondory best matching routing table entry should be 
find or not?

e.g., the forwarding address of a Type-5 LSA is 128.185.1.1,
and there are two routing table entry int the routing table on the abr,
(128.185.1.0, 0xff00) intra-area route of the NSSA area,
(128.185.0.0, 0x) intra-area route of the normal area(Type-5 capable 
area),
The path of the forwarding address should be consider as exist or not?

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

Re: [Lsr] "YANG Module for IS-IS Reverse Metric" - draft-hopps-lsr-yang-isis-reverse-metric-02

[Ketan Talaulikar (ketant)]

+1 – I also support the adoption of this document by the WG.

Thanks,
Ketan

From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: 05 December 2019 11:13
To: Acee Lindem (acee) ; lsr@ietf.org
Cc: Christian Hopps 
Subject: Re: [Lsr] "YANG Module for IS-IS Reverse Metric" - 
draft-hopps-lsr-yang-isis-reverse-metric-02

I support adoption of this necessary work.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Monday, November 25, 2019 4:27 AM
To: lsr@ietf.org
Cc: Christian Hopps mailto:cho...@chopps.org>>
Subject: [Lsr] "YANG Module for IS-IS Reverse Metric" - 
draft-hopps-lsr-yang-isis-reverse-metric-02

This begins a two week LSR Working Group adoption call for the subject document.

https://datatracker.ietf.org/doc/draft-hopps-lsr-yang-isis-reverse-metric/

Please indicate your support or objection to adoption to the LSR list 
(lsr@ietf.org) prior to 12:00 AM UTC on December 10th, 
2019.

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