[Lsr] RFC 8668 on Advertising Layer 2 Bundle Member Link Attributes in IS-IS

2019-12-06 Thread rfc-editor 
A new Request for Comments is now available in online RFC libraries.


RFC 8668

Title:  Advertising Layer 2 Bundle Member 
Link Attributes in IS-IS 
Author: L. Ginsberg, Ed.,
A. Bashandy, 
C. Filsfils,
M. Nanduri,
E. Aries
Status: Standards Track
Stream: IETF
Date:   December 2019
Mailbox:ginsb...@cisco.com, 
abashandy.i...@gmail.com, 
c...@cisco.com,
mohan.nand...@oracle.com, 
e...@arrcus.com
Pages:  17
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-isis-l2bundles-07.txt

URL:https://www.rfc-editor.org/info/rfc8668

DOI:10.17487/RFC8668

There are deployments where the Layer 3 interface on which IS-IS
operates is a Layer 2 interface bundle. Existing IS-IS advertisements
only support advertising link attributes of the Layer 3 interface. If
entities external to IS-IS wish to control traffic flows on the
individual physical links that comprise the Layer 2 interface bundle,
link attribute information about the bundle members is required.

This document introduces the ability for IS-IS to advertise the link
attributes of Layer 2 (L2) Bundle Members.

This document is a product of the IS-IS for IP Internets Working Group of the 
IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

[Lsr] RFC 8666 on OSPFv3 Extensions for Segment Routing

2019-12-06 Thread rfc-editor 
A new Request for Comments is now available in online RFC libraries.


RFC 8666

Title:  OSPFv3 Extensions for Segment Routing 
Author: P. Psenak, Ed.,
S. Previdi, Ed.
Status: Standards Track
Stream: IETF
Date:   December 2019
Mailbox:ppse...@cisco.com, 
stef...@previdi.net
Pages:  18
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-ospf-ospfv3-segment-routing-extensions-23.txt

URL:https://www.rfc-editor.org/info/rfc8666

DOI:10.17487/RFC8666

Segment Routing (SR) allows a flexible definition of end-to-end paths
within IGP topologies by encoding paths as sequences of topological
subpaths called "segments". These segments are advertised by the
link-state routing protocols (IS-IS and OSPF).

This document describes the OSPFv3 extensions required for Segment
Routing with the MPLS data plane.

This document is a product of the Link State Routing Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

[Lsr] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-lsr-flex-algo

2019-12-06 Thread IETF Secretariat 
Dear Peter Psenak, Shraddha Hegde, Clarence Filsfils, Ketan Talaulikar, Arkadiy 
Gulko:


An IPR disclosure that pertains to your Internet-Draft entitled "IGP Flexible
Algorithm" (draft-ietf-lsr-flex-algo) was submitted to the IETF Secretariat
on 2019-12-05 and has been posted on the "IETF Page of Intellectual Property
Rights Disclosures" (https://datatracker.ietf.org/ipr/3910/). The title of
the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR
related to draft-ietf-lsr-flex-algo"


Thank you

IETF Secretariat

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

Re: [Lsr] some doubts about RFC3101

2019-12-06 Thread Acee Lindem (acee) 
Hi Meicong,
The problem is that the subnet 128.185.1.0/255.255.255.0 is seemly in two 
places in the network. It is both an intra-area subnet withins the NSSA and a 
directly attached subnet on one of the ASBR’s OSPF interfaces. The ASBR should 
not advertise it as a forwarding address if it is not a directly attached 
subnet on an OSPF interface. Refer to section 2.3 in RFC 2328.
Thanks,
Acee

From: meicong 
Date: Thursday, December 5, 2019 at 8:40 PM
To: Acee Lindem , "lsr@ietf.org" 
Subject: Re: [Lsr] some doubts about RFC3101

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

[Lsr] some doubts about RFC3101

2019-12-06 Thread 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