[Lsr] I-D Action: draft-ietf-lsr-ospf-admin-tags-10.txt

[internet-drafts]

Internet-Draft draft-ietf-lsr-ospf-admin-tags-10.txt is now available. It is a
work item of the Link State Routing (LSR) WG of the IETF.

   Title:   Extensions to OSPF for Advertising Prefix Administrative Tags
   Authors: Acee Lindem
Peter Psenak
Yingzhen Qu
   Name:draft-ietf-lsr-ospf-admin-tags-10.txt
   Pages:   19
   Dates:   2023-11-19

Abstract:

   It is useful for routers in OSPFv2 and OSPFv3 routing domains to be
   able to associate tags with prefixes.  Previously, OSPFv2 and OSPFv3
   were relegated to a single tag and only for AS External and Not-So-
   Stubby-Area (NSSA) prefixes.  With the flexible encodings provided by
   OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs,
   multiple administrative tags may be advertised for all types of
   prefixes.  These administrative tags can be used for many
   applications including route redistribution policy, selective prefix
   prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection,
   and many others.

   The ISIS protocol supports a similar mechanism that is described in
   RFC 5130.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-admin-tags-10.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-ospf-admin-tags-10

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date)

[Les Ginsberg (ginsberg)]

I support adoption of this draft.

It is a reasonable (and well proven) solution to a real world problem.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Friday, November 17, 2023 8:02 AM
> To: Lsr 
> Cc: draft-chen-lsr-prefix-extended-fl...@ietf.org
> Subject: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and
> OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date)
> 
> LSR WG,
> 
> This starts the Working Group adoption call for 
> draft-chen-lsr-prefix-extended-
> flags-03. Please send your
> support or objection to this list before December 9th, 2023. The extra week is
> to allow for the US Thanksgiving holiday.
> 
> 
> 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] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date)

[zhang.zheng]

Support the adoption. 
Thanks,
Sandy











Original


From: AceeLindem 
To: Lsr ;
Cc: draft-chen-lsr-prefix-extended-fl...@ietf.org 
;
Date: 2023年11月18日 00:02
Subject: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and 
OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date)


LSR WG,  
 
This starts the Working Group adoption call for 
draft-chen-lsr-prefix-extended-flags-03. Please send your  
support or objection to this list before December 9th, 2023. The extra week is 
to allow for the US Thanksgiving holiday.  
 
 
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] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date)

[Mengxiao.Chen]

Hi Acee and WG,

I support the adoption of this draft. It can solve the problem of insufficient 
prefix flags.

Thanks,
Mengxiao

-Original Message-
From: Lsr  On Behalf Of Acee Lindem
Sent: Saturday, November 18, 2023 12:02 AM
To: Lsr 
Cc: draft-chen-lsr-prefix-extended-fl...@ietf.org
Subject: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and 
OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date)

LSR WG,

This starts the Working Group adoption call for 
draft-chen-lsr-prefix-extended-flags-03. Please send your
support or objection to this list before December 9th, 2023. The extra week is 
to allow for the US Thanksgiving holiday.


Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: Technical questions for draft about unreachable prefixes announcement

[Aijun Wang]

Hi, Ketan:

 

Please think it further:

 

No Prefix Originator--à Orphan Prefix-àThe associated prefix is unreachable

 

I am wondering why the WG select the detour way to standardize the solution……

 

发件人: Ketan Talaulikar [mailto:ketant.i...@gmail.com] 
发送时间: 2023年11月17日 21:44
收件人: Aijun Wang 
抄送: Les Ginsberg (ginsberg) ; John Drake 
; Peter Psenak (ppsenak) 
; lsr@ietf.org
主题: Re: [Lsr] Technical questions for draft about unreachable prefixes 
announcement

 

By this logic, when the Prefix Originator is set to 0.0.0.0, it means there is 
no Prefix Originator ... ;-)

 

Not sure why we are even arguing about this :-(

 

 

On Wed, Nov 15, 2023 at 1:50 PM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Ketan:

 

The logic is that why we can set router-id equal to 0.0.0.0 to indicate some 
information in some standards, but we can’t set prefix originator information 
to 0.0.0.0 to indicate the prefix is unreachable?

 

Here are again two examples for the usages of router-id’s value as 0.0.0.0 to 
indicate some information, one is for OSPF another is for IS-IS:

1) For OSPF: https://www.rfc-editor.org/rfc/rfc5340.html#appendix-A.3.2

 

Designated Router ID
   The sending router's view of the identity of the Designated Router for this 
network.  The Designated Router is identified by its Router ID.  It is set to 
0.0.0.0 if there is no Designated Router.
 
Backup Designated Router ID
   The sending router's view of the identity of the Backup Designated Router 
for this network.  The Backup Designated Router is identified by its IP Router 
ID.  It is set to 0.0.0.0 if there is no Backup Designated Router.

 

2) For IS-IS: https://www.rfc-editor.org/rfc/rfc7981.html#appendix-A

 

If the originating node does not support IPv4, then the reserved value 0.0.0.0 
MUST be used in the Router ID field, and the IPv6 TE Router ID sub-TLV [RFC5316 
 ] MUST be present in the TLV.

 

What I insist is that there are already containers that can be used to indicate 
the unreachable information, why we pursue other non-existing, non-standard 
container?

Aijun Wang

China Telecom





On Nov 7, 2023, at 18:16, Ketan Talaulikar mailto:ketant.i...@gmail.com> > wrote:



Hi Aijun,

 

I am not sure what "logic" you are looking for while being somewhat dismissive 
of the arguments/logic provided.

 

Let us agree to disagree.

 

At least I've concluded that it is no more fruitful for me to try to convince 
you. C'est la vie ...

 

Thanks,

Ketan

 

 

On Tue, Nov 7, 2023 at 11:08 AM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Ketan:

 

There are many examples within IETF that special values has special meanings, 
please see:

 

1) 
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

2) 
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

 

3) 
https://www.iana.org/assignments/iana-as-numbers-special-registry/iana-as-numbers-special-registry.xhtml

 

4) LS-Infinity

 

Then, please state clearly that why we cannot define specific value for prefix 
originator to indicate the unreachability.

 

We need the logic that supports your conclusions. Until now, none.

 

Or anyone else can elaborate the logic more clearly?

 

Aijun Wang

China Telecom





On Nov 7, 2023, at 10:19, Ketan Talaulikar mailto:ketant.i...@gmail.com> > wrote:



Hi Aijun,

 

I realize that continuing this argument with you is futile. 

 

However, perhaps one last response that I would address not to you but for 
other WG members (if any one is still following this thread).

 

On Tue, Nov 7, 2023 at 9:54 AM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Ketan and Les:

 

There are two sub-TLVs to indicate the source information of the prefix within 
OSPF——“Prefix Source OSPF Router ID” and “Prefix Source OSPF Router Address”

 

What’s you refer to is the first sub-TLV, for the second sub-TLV, we haven’t 
such statements, this is also true for IS-IS,  as Les pointed out.

 

KT> I am not a lawyer. The semantics for Prefix Source OSPF Router Address 
should be clear to anyone that reads the procedures in Sec 3.

 

 

 

So, contrary to your happiness :) this give us the room to define the specific 
value to indicate “unreachability”.

 

And, to Ketan again, until now, you don’t explain clearly that if we can’t 
define specific value for “unreachability” why can we define the specific value 
for “LS-Infinity”?

 

KT> For LS-Infinity - please read RFC2328.

 

Thanks,

Ketan

 

 

Aijun Wang

China Telecom





On Nov 7, 2023, at 09:23, Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org> > 
wrote:

 

Ketan –

 

I am very happy to be wrong in this case. 

We are in full agreement.

 

Les

 

 

From: Lsr mailto:lsr-boun...@ietf.org> > On Behalf Of 
Ketan Talaulikar
Sent: Monday, November 6, 2023 11:52 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> 

[Lsr] 答复: WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date)

[zhao.detao]

Hi Acee and WG，
I support the adoption as co-author. The feature is really useful and the draft 
is ready for WG adoption. 








赵德涛
软件平台开发一部/有线研究院/有线产品经营部
 
中兴通讯股份有限公司
南京市紫荆花路68号南研一期, 邮编: 210012
T: +86 15951883174  M: +86 15951883174
E: zhao.de...@zte.com.cn




Original


From: AceeLindem 
To: Acee Lindem ;
Cc: Lsr ;draft-chen-lsr-prefix-extended-fl...@ietf.org 
;
Date: 2023年11月18日 00:09
Subject: 答复: WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" 
- draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date)

Speaking as WG Member:
 
I support WG adoption. These simple extensions for OSPFv2 and OSPFv3 are 
required for consistent, concise, and extendible advertisement of binary prefix 
attributes.  
 
Thanks,
Acee
 
> On Nov 17, 2023, at 11:01 AM, Acee Lindem  wrote:
>  
> LSR WG,  
>  
> This starts the Working Group adoption call for 
> draft-chen-lsr-prefix-extended-flags-03. Please send your  
> support or objection to this list before December 9th, 2023. The extra week 
> is to allow for the US Thanksgiving holiday.  
>  
>  
> Thanks,
> Acee___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date)

[chen.ran]

Hi Acee and WG，
I support the adoption as co-author. The feature is really useful and the draft 
is ready for WG adoption. 

Best Regards,
Ran


Original


From: AceeLindem 
To: Lsr ;
Cc: draft-chen-lsr-prefix-extended-fl...@ietf.org 
;
Date: 2023年11月18日 00:02
Subject: WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - 
draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date)

LSR WG,  
 
This starts the Working Group adoption call for 
draft-chen-lsr-prefix-extended-flags-03. Please send your  
support or objection to this list before December 9th, 2023. The extra week is 
to allow for the US Thanksgiving holiday.  
 
 
Thanks,
Acee___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [yang-doctors] draft-ietf-isis-sr-yang and draft-ietf-ospf-sr-yang

[Rahman]

Hi Yingzhen,On PTO right now. I’ll review when I get back.Regards,Reshad.Sent from my iPhoneOn Nov 19, 2023, at 7:20 PM, Yingzhen Qu  wrote:Hi Reshad,I've submitted an updated version of both the drafts, and tried to align the two models. Please review and let me know what you think.Thanks,YingzhenOn Tue, Nov 14, 2023 at 1:42 PM Acee Lindem  wrote:

> On Nov 14, 2023, at 10:32 AM, Mahesh Jethanandani  wrote:
> 
> Hi Acee,
> 
> Can the commonality extend to having a common grouping that is used by both the models?

No - see my response to Reshad. 

Acee


> 
> Cheers.
> 
>> On Nov 14, 2023, at 8:10 AM, Acee Lindem  wrote:
>> 
>> Thanks Reshad - are there any other notable discrepancies? 
>> 
>> Thanks,
>> Acee
>> 
>>> On Nov 14, 2023, at 9:55 AM, Reshad Rahman 40yahoo@dmarc.ietf.org> wrote:
>>> 
>>> Hi,
>>> 
>>> My suggestion is that authors of these 2 documents spend some time together to try to align the 2 documents. After that we can do YD review.
>>> 
>>> Regards,
>>> Reshad.
>>> 
>>> On Wednesday, November 1, 2023, 10:58:56 AM EDT, Reshad Rahman  wrote: 
>>> 
>>> 
>>> Hi,
>>> 
>>> Background: those 2 documents have just been assigned YD review, I am reviewing OSPF and Jan is reviewing ISIS.
>>> 
>>> Was an effort made to keep those 2 documents aligned/in-sync where possible/desirable? My expectation is that the SR specifics would be near-identical in the 2 documents. e.g. shouldn't the capabilities for the 2 protocols be very similar.
>>> Here are some differences which don't seem justified:
>>> - sr-algorithm in ISIS is a uint8 and in OSPF is an identityref
>>> - range-size is a uint32 in ISIS and is a uint24 in OSPF
>>> 
>>> 
>>> augment /rt:routing/rt:control-plane-protocols
>>> /rt:control-plane-protocol/isis:isis/isis:database
>>> /isis:levels/isis:lsp/isis:router-capabilities:
>>> +--ro sr-capability
>>> | +--ro sr-capability
>>> | | +--ro sr-capability-bits* identityref
>>> | +--ro global-blocks
>>> | +--ro global-block* []
>>> | +--ro range-size? uint32
>>> | +--ro sid-sub-tlv
>>> | +--ro sid? uint32
>>> +--ro sr-algorithms
>>> | +--ro sr-algorithm* uint8
>>> +--ro local-blocks
>>> | +--ro local-block* []
>>> | +--ro range-size? uint32
>>> | +--ro sid-sub-tlv
>>> | +--ro sid? uint32
>>> +--ro srms-preference
>>> +--ro preference? uint8
>>> 
>>> augment /rt:routing/rt:control-plane-protocols
>>> /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
>>> /ospf:interfaces/ospf:interface/ospf:database
>>> /ospf:link-scope-lsa-type/ospf:link-scope-lsas
>>> /ospf:link-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2
>>> /ospf:body/ospf:opaque/ospf:ri-opaque:
>>> +--ro sr-algorithm-tlv
>>> | +--ro sr-algorithm* identityref
>>> +--ro sid-range-tlvs
>>> | +--ro sid-range-tlv* []
>>> | +--ro range-size? rt-types:uint24
>>> | +--ro sid-sub-tlv
>>> | +--ro sid? uint32
>>> +--ro local-block-tlvs
>>> | +--ro local-block-tlv* []
>>> | +--ro range-size? rt-types:uint24
>>> | +--ro sid-sub-tlv
>>> | +--ro sid? uint32
>>> +--ro srms-preference-tlv
>>> +--ro preference? uint8
>>> 
>>> 
>>> 
>>> Disclaimer: I don't follow LSR...
>>> 
>>> Regards,
>>> Reshad.
>>> ___
>>> yang-doctors mailing list
>>> yang-doct...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/yang-doctors
>> 
>> ___
>> yang-doctors mailing list
>> yang-doct...@ietf.org
>> https://www.ietf.org/mailman/listinfo/yang-doctors
> 
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com
> 
> 
> 
> 
> 
> 

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

___Lsr mailing listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [yang-doctors] draft-ietf-isis-sr-yang and draft-ietf-ospf-sr-yang

[Yingzhen Qu]

Hi Reshad,

I've submitted an updated version of both the drafts, and tried to
align the two models. Please review and let me know what you think.

Thanks,
Yingzhen

On Tue, Nov 14, 2023 at 1:42 PM Acee Lindem  wrote:

>
>
> > On Nov 14, 2023, at 10:32 AM, Mahesh Jethanandani <
> mjethanand...@gmail.com> wrote:
> >
> > Hi Acee,
> >
> > Can the commonality extend to having a common grouping that is used by
> both the models?
>
> No - see my response to Reshad.
>
> Acee
>
>
> >
> > Cheers.
> >
> >> On Nov 14, 2023, at 8:10 AM, Acee Lindem  wrote:
> >>
> >> Thanks Reshad - are there any other notable discrepancies?
> >>
> >> Thanks,
> >> Acee
> >>
> >>> On Nov 14, 2023, at 9:55 AM, Reshad Rahman  40yahoo@dmarc.ietf.org> wrote:
> >>>
> >>> Hi,
> >>>
> >>> My suggestion is that authors of these 2 documents spend some time
> together to try to align the 2 documents. After that we can do YD review.
> >>>
> >>> Regards,
> >>> Reshad.
> >>>
> >>> On Wednesday, November 1, 2023, 10:58:56 AM EDT, Reshad Rahman <
> res...@yahoo.com> wrote:
> >>>
> >>>
> >>> Hi,
> >>>
> >>> Background: those 2 documents have just been assigned YD review, I am
> reviewing OSPF and Jan is reviewing ISIS.
> >>>
> >>> Was an effort made to keep those 2 documents aligned/in-sync where
> possible/desirable? My expectation is that the SR specifics would be
> near-identical in the 2 documents. e.g. shouldn't the capabilities for the
> 2 protocols be very similar.
> >>> Here are some differences which don't seem justified:
> >>> - sr-algorithm in ISIS is a uint8 and in OSPF is an identityref
> >>> - range-size is a uint32 in ISIS and is a uint24 in OSPF
> >>>
> >>>
> >>> augment /rt:routing/rt:control-plane-protocols
> >>> /rt:control-plane-protocol/isis:isis/isis:database
> >>> /isis:levels/isis:lsp/isis:router-capabilities:
> >>> +--ro sr-capability
> >>> | +--ro sr-capability
> >>> | | +--ro sr-capability-bits* identityref
> >>> | +--ro global-blocks
> >>> | +--ro global-block* []
> >>> | +--ro range-size? uint32
> >>> | +--ro sid-sub-tlv
> >>> | +--ro sid? uint32
> >>> +--ro sr-algorithms
> >>> | +--ro sr-algorithm* uint8
> >>> +--ro local-blocks
> >>> | +--ro local-block* []
> >>> | +--ro range-size? uint32
> >>> | +--ro sid-sub-tlv
> >>> | +--ro sid? uint32
> >>> +--ro srms-preference
> >>> +--ro preference? uint8
> >>>
> >>> augment /rt:routing/rt:control-plane-protocols
> >>> /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
> >>> /ospf:interfaces/ospf:interface/ospf:database
> >>> /ospf:link-scope-lsa-type/ospf:link-scope-lsas
> >>> /ospf:link-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2
> >>> /ospf:body/ospf:opaque/ospf:ri-opaque:
> >>> +--ro sr-algorithm-tlv
> >>> | +--ro sr-algorithm* identityref
> >>> +--ro sid-range-tlvs
> >>> | +--ro sid-range-tlv* []
> >>> | +--ro range-size? rt-types:uint24
> >>> | +--ro sid-sub-tlv
> >>> | +--ro sid? uint32
> >>> +--ro local-block-tlvs
> >>> | +--ro local-block-tlv* []
> >>> | +--ro range-size? rt-types:uint24
> >>> | +--ro sid-sub-tlv
> >>> | +--ro sid? uint32
> >>> +--ro srms-preference-tlv
> >>> +--ro preference? uint8
> >>>
> >>>
> >>>
> >>> Disclaimer: I don't follow LSR...
> >>>
> >>> Regards,
> >>> Reshad.
> >>> ___
> >>> yang-doctors mailing list
> >>> yang-doct...@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/yang-doctors
> >>
> >> ___
> >> yang-doctors mailing list
> >> yang-doct...@ietf.org
> >> https://www.ietf.org/mailman/listinfo/yang-doctors
> >
> >
> > Mahesh Jethanandani
> > mjethanand...@gmail.com
> >
> >
> >
> >
> >
> >
>
> ___
> 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

[Lsr] I-D Action: draft-ietf-isis-sr-yang-17.txt

[internet-drafts]

Internet-Draft draft-ietf-isis-sr-yang-17.txt is now available. It is a work
item of the Link State Routing (LSR) WG of the IETF.

   Title:   A YANG Data Model for IS-IS Segment Routing
   Authors: Stephane Litkowski
Yingzhen Qu
Pushpasis Sarkar
Ing-Wher Chen
Jeff Tantsura
   Name:draft-ietf-isis-sr-yang-17.txt
   Pages:   31
   Dates:   2023-11-19

Abstract:

   This document defines a YANG data module that can be used to
   configure and manage IS-IS Segment Routing for MPLS data plane.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-isis-sr-yang/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-isis-sr-yang-17.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-isis-sr-yang-17

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

[Lsr] I-D Action: draft-ietf-ospf-sr-yang-22.txt

[internet-drafts]

Internet-Draft draft-ietf-ospf-sr-yang-22.txt is now available. It is a work
item of the Link State Routing (LSR) WG of the IETF.

   Title:   A YANG Data Model for OSPF Segment Routing
   Authors: Yingzhen Qu
Acee Lindem
Jeffrey Zhang
Ing-Wher Chen
   Name:draft-ietf-ospf-sr-yang-22.txt
   Pages:   44
   Dates:   2023-11-19

Abstract:

   This document defines a YANG data module that can be used to
   configure and manage OSPF Extensions for Segment Routing.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-ospf-sr-yang-22.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ospf-sr-yang-22

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Gaurav Halwasia]

I support WG adoption of this draft.

Thanks,
Gaurav



Juniper Business Use Only

From: Lsr  on behalf of Yingzhen Qu 

Date: Friday, 17 November 2023 at 10:54 PM
To: draft-pkaneria-lsr-multi-...@ietf.org 
, lsr 
Subject: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)
[External Email. Be cautious of content]

Hi,

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS 
(ietf.org)

Please send your support or objection to the list before December 9th, 2023. An 
extra week is allowed for the US Thanksgiving holiday.

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

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Peter Psenak]

Hi Yingzhen,

I support the adoption. Multiple implementations already support what 
the draft is proposing.


thanks,
Peter


On 17/11/2023 18:23, Yingzhen Qu wrote:

Hi,

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org) 



Please send your support or objection to the list before December 9th, 
2023. An extra week is allowed for the US Thanksgiving holiday.


Thanks,
Yingzhen


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

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Parag Kaneriya]

I support adoption as co-author.




Juniper Business Use Only
From: Acee Lindem 
Sent: Friday, November 17, 2023 11:01 PM
To: Yingzhen Qu 
Cc: draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 
- 12/09/2023)

[External Email. Be cautious of content]

Speaking as WG member:

This draft has already resulted in a lot of good discussion and iteration. I 
support adoption as formalization of the existing solution with configuration, 
protocol level capability reporting, and IANA multi-TLV specification.

Thanks,
Acee


On Nov 17, 2023, at 12:23, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:

Hi,

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS 
(ietf.org)

Please send your support or objection to the list before December 9th, 2023. An 
extra week is allowed for the US Thanksgiving holiday.

Thanks,
Yingzhen
___
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] IPR Poll for draft-pkaneria-lsr-multi-tlv

[Parag Kaneriya]

"No, I'm not aware of any IPR that applies to this draft"




Juniper Business Use Only
From: Yingzhen Qu 
Sent: Friday, November 17, 2023 10:31 PM
To: draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Cc: lsr-chairs 
Subject: IPR Poll for draft-pkaneria-lsr-multi-tlv

[External Email. Be cautious of content]

Hi,


This is an IPR call for draft-pkaneria-lsr-multi-tlv 
(draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS 
(ietf.org))


The authors and contributors please respond to this IPR call.



Please state either:

"No, I'm not aware of any IPR that applies to this draft"

or

"Yes, I'm aware of IPR that applies to this draft"



If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3669, 5378 and 8179 for more details)?



If yes to the above, please state either:



"Yes, the IPR has been disclosed in compliance with IETF IPR rules"

or

"No, the IPR has not been disclosed"



If you answer no, please provide any additional details you think

appropriate.



If you are listed as a document author or contributor please respond

to this email regardless of whether or not you are aware of any

relevant IPR. The response needs to be sent to the LSR WG mailing

list. The document will not advance to the next stage until a

response has been received from each author and contributor.



If you are on the LSR WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of

any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,

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