[spring] C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)

[Alvaro Retana]

Dear 6man WG:

As you may be aware, the spring WG is in the process of advancing
draft-ietf-spring-srv6-srh-compression [1]. The WGLC discussions have
resulted in the need to ask you the following questions (see below)
related to the use/operation of compressed SIDs (C-SIDs).

Please provide any opinions by June 14, 2024.

Thanks!

spring-chairs



§6.5 (Upper-Layer Checksums) explains how to calculate the Upper-Layer
Checksum in the presence of C-SIDs. §9.3 (Upper Layer Checksum
Considerations) discusses the related operational considerations.
For convenience, both sections are reproduced here:

= = draft-ietf-spring-srv6-srh-compression-17 = =

6.5. Upper-Layer Checksums

   The Destination Address used in the IPv6 pseudo-header (Section 8.1
   of [RFC8200]) is that of the ultimate destination.

   At the SR source node, that address will be the Destination Address
   as it is expected to be received by the ultimate destination. When
   the last element in the compressed SID list is a C-SID container,
   this address can be obtained from the last element in the
   uncompressed SID list or by repeatedly applying the segment behavior
   as described in Section 9.2. This applies regardless of whether an
   SRH is present in the IPv6 packet or omitted.

   At the ultimate destination(s), that address will be in the
   Destination Address field of the IPv6 header.

...

9.3. Upper Layer Checksum Considerations

   Upper layer checksums are computed by the originator of an IPv6
   packet and verified by the ultimate destination(s) as it processes
   the upper layer protocol.

   As specified in Section 6.5, SR source nodes originating TCP/UDP
   packets ensure that the upper layer checksum is correctly calculated
   based on the ultimate destination of the session, which may be
   different from the address placed in the IPv6 destination address.
   Such SR source nodes leveraging TCP/UDP offload engines may require
   enhancements to convey the ultimate destination address. These
   implementation enhancements are outside the scope of this document.

   It was reported that some network node implementations, including
   middleboxes such as packet sniffers and one software router
   implementation, may attempt to verify the upper layer checksum of
   transit IPv6 packets. These nodes, if deployed inside the SR domain,
   may fail to verify the upper layer checksum of transit SRv6 traffic,
   possibly resulting in dropped packets or in the inability to carry
   out their function. Making these implementations SRv6 aware in
   general or C-SID aware in particular is out of the scope of this
   document.

= = = = = = = = = = = =


Is this text aligned with §8.1/rfc8200 (Upper-Layer Checksums) [2]?
Does anything need to be added, deleted, changed, or clarified?

Is using C-SIDs in the above scenarios (§9.3) compatible with IPv6
transit node deployments compliant with rfc8200?

Does using C-SIDs as specified above represent a modification to the
IPv6 dataplane? If so, is the modification considered acceptable to
the WG?


[1]
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression


[2] https://datatracker.ietf.org/doc/html/rfc8200#autoid-17
___
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

[spring] Early Allocation for draft-ietf-spring-dhc-distribute-srv6-locator-dhcp

[Alvaro Retana]

Dear spring WG:


[cc’ing the DHC WG + dhc-chairs for information.]


The authors of draft-ietf-spring-dhc-distribute-srv6-locator-dhcp have
requested early allocation of the DHCPv6 Option Codes specified in the
draft.

https://datatracker.ietf.org/doc/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp/


According to rfc7120 (Early IANA Allocation) and in consultation with
the dhc-chairs, we believe the specification is stable enough.  This
message is a call to determine whether the WG has any objection to
requesting early allocation for these codepoints.


Please express your opinion by June 12, 2024.  Be explicit if you
don't believe early allocation is appropriate now.

Thanks!

Alvaro.
(for spring-chairs)

___
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

[spring] Re: IPR confirmation for https://datatracker.ietf.org/doc/draft-bdmgct-spring-srv6-security

[Alvaro Retana]

Hi!

We still haven’t received all the required replies.

We need then to move this document forward.

Thanks!

Alvaro.

On April 2, 2024 at 12:24:38 PM, Joel Halpern (j...@joelhalpern.com) wrote:

Can the authors (and listed contributors) please confirm to the working
group email list that all IPR believed to be relevant which is known to
the author (or contributor) has been disclosed as per the IETF rules.

Once that is done, the chairs will start the working group adoption call
for this document.

thank you,

Joel (and Alvaro and Bruno)

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

[spring] Fwd: [Idr] Interim meeting on 5/20 - On BGP drafts on BGP-LS and SR asking for Adoption

[Alvaro Retana]

FYI

On May 17, 2024 at 12:17:09 PM, Susan Hares (sha...@ndzh.com) wrote:

On Monday 5/20/2024, IDR will be holding an interim meeting from 10-12pm
EDT.



This meeting reviews five drafts for BGP-LS and SR routing.   The details
are below.



Cheerily, Sue Hares





==



Interim meeting date: 5/20

Interim time: 10:00 – 12:00 EDT

Link: https://datatracker.ietf.org/meeting/interim-2024-idr-04/session/idr



Agenda



Agenda IDR Interim on BGP drafts for BGP-LS and Segment Routing



Date: 5/20/2024

Time: 10:00 - 11:30  EDT



0. Agenda Bashing and Chair's slides [5 minutes]



1.SR Policies Extensions for Network Resource Partition in
BGP-LS [15 minutes]

draft-chen-idr-bgp-ls-sr-policy-nrp-05  [TBD]



2.Advertising SID Algorithm Information in BGP [15 minutes]

   draft-peng-idr-segment-routing-te-policy-attr-10 [Yao Liu]



3.BGP Extensions of SR Policy for Headend Behavior [15 minutes]

draft-lin-idr-sr-policy-headend-behavior-03  [Changwang Lin]



4.Segment Routing BGP Egress Peer Engineering over Layer 2
Bundle Members [15 minutes]

draft-lin-idr-sr-epe-over-l2bundle-05 – [Changwang Lin]



5.BGP SR Policy Extensions for template [15 minutes]

draft-zhang-idr-sr-policy-template-03 [TBD]



6. Chair's summary and plans for adoption calls [5 minutes]
___
Idr mailing list -- i...@ietf.org
To unsubscribe send an email to idr-le...@ietf.org
___
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

[spring] Re: [Idr] Question about the draft-filsfils-spring-srv6-net-pgm-insertion

[Alvaro Retana]

Hi!

That draft is not in the adoption queue.

Alvaro.

On May 15, 2024 at 4:13:50 PM, linchangwang (linchangwang.04...@h3c.com)
wrote:

Dear SPRING experts,



It is currently uncertain whether the defined behavior of H.Insert and
H.Insert.Red in the draft-filsfils-spring-srv6-net-pgm-insertion

(
https://www.ietf.org/archive/id/draft-filsfils-spring-srv6-net-pgm-insertion-09.txt
)
will be adopted by the Spring WG.



Is there a plan for adoption at present?



Thanks,

Changwang
-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
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!
___
Idr mailing list -- i...@ietf.org
To unsubscribe send an email to idr-le...@ietf.org
___
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

[spring] Re: request for review and comments

[Alvaro Retana]

Hi!

If you want to formally update other RFCs, you need to do several other
things: include a tag in the header, indicate the update in the Abstract
and Introduction, and indicate what are the text changes (if any) to the
original RFCs.

While I still think the (formal) update is not needed, it may be a
discussion to be had if the document is adopted.

Thanks!

Alvaro.

On May 15, 2024 at 7:51:46 AM, linchangwang (linchangwang.04...@h3c.com)
wrote:

Therefore, the update proposed in section 3.1 is needed.
___
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

[spring] Re: request for review and comments

[Alvaro Retana]

[spring-chair hat off + idr]

Hi!

I took a quick look at the draft -- it uses existing TLVs to convey the
information, which is good.

Given that (IIRC) BGP-LS does not limit TLVs' use as sub-TLVs, rfc9085
already contemplates using the Adjacency SID TLV (as a sub-TLV), and
rfc9086 already says that additional TLVs can be included to describe a
link's characteristics, I find the contents quite obvious.

The update proposed in §3.1 is not needed:

   This document updates [RFC9085] and [RFC9086] to allow the PeerAdj
   SID TLV to be included as a sub-TLV of the L2 Bundle Member
   Attributes TLV.

[I expected something similar in §3.2 about using the SRv6 End.X SID TLV as
a sub-TLV, but that text is not present.  It is not needed anyway.]

My 2c.

Alvaro.

On May 10, 2024 at 5:17:09 AM, li_zhenqi...@hotmail.com (
li_zhenqi...@hotmail.com) wrote:

Dear SPRING experts,

IDR is considering to start the WG adoption call for Segment Routing BGP
Egress Peer Engineering over Layer 2 Bundle. As suggested by IDR WG chair,
we request for review and comments in SPRING. Any discussion, suggestion or
comment is appreciated.

Some information about the draft:

Abstract

There are deployments where the Layer 3 interface on which a BGP peer
session is established is a Layer 2 interface bundle. In order to
allow BGP-EPE to control traffic flows on individual member links of
the underlying Layer 2 bundle, BGP Peering SIDs need to be allocated
to individual bundle member links, and dvertisement of such BGP
Peering SIDs in BGP-LS is required. This document describes how to
support Segment Routing BGP Egress Peer Engineering over Layer 2
bundle.


link

https://datatracker.ietf.org/doc/draft-lin-idr-sr-epe-over-l2bundle/

--
Best Regards,
Zhenqiang Li
China Mobile
li_zhenqi...@hotmail.com
___
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
___
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

[spring] Re: IPR Disclosures for draft-ietf-spring-bfd

[Alvaro Retana]

Hi!

We have now received all the required responses.

Ketan Talaulikar is going to be this document’s shepherd.

Thanks to all!

Alvaro.


On May 6, 2024 at 11:14:27 PM, Wenying Jiang (jiangweny...@chinamobile.com)
wrote:

Hi Alvaro,
I’m not aware of any IPR related to this draft.

BR,
Wenying



邮件原文
*发件人：*Alvaro Retana  
*收件人：*Wenying Jiang  
*抄 送: *spring-chairs ,SPRING WG List  <
spring@ietf.org>,draft-ietf-spring-bfd 
*发送时间：*2024-05-07 05:32:13
*主题：*Re: [spring] IPR Disclosures for draft-ietf-spring-bfd

Thanks for the responses.

I’m adding Wenying specifically because that is the only reply we’re
missing.

Thanks!

Alvaro.

On May 3, 2024 at 12:41:49AM, Jeff Tantsura (jefftant.i...@gmail.com) wrote:

Alvaro,
I’m not aware for any IPR that applies to the draft.

Cheers,
Jeff

On May 2, 2024, at 07:48, iLya Varlashkin 
wrote:


I’m not aware of any undisclosed IPR related to this draft.

Kind regards,
iLya Varlashkin

On Wed, 24 Apr 2024 at 08:17 Greg Mirsky  wrote:

> I am not aware of any undisclosed IPR related to this draft.
> Regards,
> Greg
>
> On Tue, Apr 23, 2024 at 5:39PM Alvaro Retana 
> wrote:
>
>> Dear authors and contributors:
>>
>> Are you aware of any IPR that applies to this draft?
>>
>> If so, has it been disclosed in compliance with IETF IPR rules (see
>> BCP78 and BCP79 for more details)?  For any undisclosed IPR, please
>> provide any additional information you think appropriate.
>>
>> If you are listed as a document author or contributor, please answer
>> the above by responding to this email regardless of whether or not you
>> are aware of any relevant IPR.  This document will only advance to the
>> next stage once a response is received from each listed author and
>> contributor.
>>
>>
>> If you are on the WG email list or attend WG meetings but are not
>> listed as an author or contributor, we remind you of your obligations
>> under the IETF IPR rules, which encourage you to notify the IETF if
>> you are aware of IPR that may be related to this document or to
>> refrain from participating in any contribution or discussion related
>> to your undisclosed IPR.  For more information, please see
>> https://www.ietf.org/standards/ipr/
>>
>> Thank you,
>>
>> Alvaro (for the Chairs)
>>
> ___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

[spring] Re: IPR Disclosures for draft-ietf-spring-bfd

[Alvaro Retana]

Thanks for the responses.

I’m adding Wenying specifically because that is the only reply we’re
missing.

Thanks!

Alvaro.

On May 3, 2024 at 12:41:49 AM, Jeff Tantsura (jefftant.i...@gmail.com)
wrote:

Alvaro,

I’m not aware for any IPR that applies to the draft.

Cheers,
Jeff

On May 2, 2024, at 07:48, iLya Varlashkin 
wrote:


I’m not aware of any undisclosed IPR related to this draft.

Kind regards,
iLya Varlashkin

On Wed, 24 Apr 2024 at 08:17 Greg Mirsky  wrote:

> I am not aware of any undisclosed IPR related to this draft.
>
> Regards,
> Greg
>
> On Tue, Apr 23, 2024 at 5:39 PM Alvaro Retana 
> wrote:
>
>> Dear authors and contributors:
>>
>> Are you aware of any IPR that applies to this draft?
>>
>> If so, has it been disclosed in compliance with IETF IPR rules (see
>> BCP78 and BCP79 for more details)?  For any undisclosed IPR, please
>> provide any additional information you think appropriate.
>>
>> If you are listed as a document author or contributor, please answer
>> the above by responding to this email regardless of whether or not you
>> are aware of any relevant IPR.  This document will only advance to the
>> next stage once a response is received from each listed author and
>> contributor.
>>
>>
>> If you are on the WG email list or attend WG meetings but are not
>> listed as an author or contributor, we remind you of your obligations
>> under the IETF IPR rules, which encourage you to notify the IETF if
>> you are aware of IPR that may be related to this document or to
>> refrain from participating in any contribution or discussion related
>> to your undisclosed IPR.  For more information, please see
>> https://www.ietf.org/standards/ipr/
>>
>> Thank you,
>>
>> Alvaro (for the Chairs)
>>
> ___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

Re: [spring] Relationship betweendraft-cheng-spring-srv6-policy-resource-gurantee anddraft-ietf-spring-resource-aware-segments

[Alvaro Retana]

On April 22, 2024 at 2:46:00 AM, Dongjie (Jimmy) wrote:


Jie:

Hi!


...
> [Jie] In my understanding, both documents propose enhancements to SR to solve
> the requirements for resource guarantee in SR networks.
>
> The essential is that SR SIDs can be used to indicate not only the function
> (or behavior) to be performed, but also to indicate the set of resources used
> to perform the function (or behavior). Thus these SIDs are called
> resource-aware SIDs. From this perspective, it is true that
> draft-ietf-spring-resource-aware-segments is the framework for introducing
> resource-awareness to SR.
>
> As for the solutions for resource-guaranteed SR Policy, there can be
> different approaches to indicate the SIDs are resource-aware:
>
> The first approach is as described in
> draft-ietf-spring-resource-aware-segments, the SR-MPLS SIDs or SRv6 locators
> are associated with a set of network resources, this allows SR SIDs with all
> existing types/behaviors be associated with specific set of network resources
> for packet processing. Thus this draft provides a general solution for
> resource-aware SIDs, which can apply to SR Policies with explicit or loose
> paths, SR Flex-Algo, SR Multi-topology, etc.
>
> The second approach is as described in
> draft-cheng-spring-srv6-policy-resource-gurantee for SRv6, a SRv6 new
> behavior is defined as a variant of End.X, which indicates “End.X with
> specific set of link resource”(maybe the behavior could be renamed as
> End.XNRP?) This approach applies to SRv6 Policies built with End.X SIDs only.
>
> Thus in my view draft-cheng-spring-srv6-policy-resource-gurantee aligns with
> the resource-aware SR framework as specified in
> draft-ietf-spring-resource-aware-segments, while it focuses on a specific use
> case: enhancements to SRv6 Policy explicit paths for resource guarantee, and
> provides an optional extension for that use case.

You seem to be saying that each approach "aligns with the
resource-aware SR framework as specified in
draft-ietf-spring-resource-aware-segments", even if the approach in
draft-cheng-spring-srv6-policy-resource-gurantee is not addressed in
draft-ietf-spring-resource-aware-segments.  Is that your point?

I'm confused because you also say that the solution in
draft-ietf-spring-resource-aware-segments can apply to any scenario
("general solution for resource-aware SIDs, which can apply to SR
Policies with explicit or loose paths, SR Flex-Algo, SR
Multi-topology, etc."), which I assume includes the use case in
draft-cheng-spring-srv6-policy-resource-gurantee.  Is that correct?

If so, why is an approach that "applies to SRv6 Policies built with
End.X SIDs only" needed?


Thanks!

Alvaro.

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

Re: [spring] Relationship betweendraft-cheng-spring-srv6-policy-resource-gurantee anddraft-ietf-spring-resource-aware-segments

[Alvaro Retana]

On April 21, 2024 at 9:56:07 PM, Wenying Jiang wrote:

Wenying:

Hi!


...
> > It is not clear to me that the two mechanisms cannot solve the same
> > use cases.  The difference is in this detail:
> >
> > I-D.cheng-spring-srv6-policy-resource-gurantee: proposes allocating a SID
> >    with the End.NRP behavior for each set of network resources
> >
> > I-D.ietf-spring-resource-aware-segments: proposes allocating a
> >    resource-aware SRv6 Locator for each set of network resources (keeping
> >    the existing behaviors)
> >
> >
> > What use cases cannot be addressed with the existing solution in
> > I-D.ietf-spring-resource-aware-segments?  [To the authors of
> > I-D.ietf-spring-resource-aware-segments: it might be useful explain
> > how the draft addresses the use case in
> > §3/I-D.cheng-spring-srv6-policy-resource-gurantee.]

> [Wenying] The relationship between these two drafts is as follows:
...

It is important for you to clearly and explicitly explain what cannot
be done with the solution in I-D.ietf-spring-resource-aware-segments
that requires your draft.

Continuing to talk about your interpretation of the drafts is not
getting us anywhere.  What use cases cannot be addressed with the
existing solution in I-D.ietf-spring-resource-aware-segments?  Please
be detailed.


>  I-D.ietf-spring-resource-aware-segments serves as a valuable framework
>  document, offering common architectural ground for development without
>  defining any solution itself. It is recognized as a useful framework in
>  providing guidance for development. However, specific solutions are still
>  needed.
>
> On the other hand,I-D.cheng-spring-srv6-policy-resource-gurantee proposes
> specific solutions by defining particular behaviors, such as the End.NRP
> behavior, and presents actual application scenarios. This draft can guide
> deployments, and the SRv6 END.NRP functional mechanism has been implemented
> and verified by China Mobile.
>
> Based on discussions in the mailing list, there is a consensus that
> I-D.ietf-spring-resource-aware-segments functions more as a framework without
> providing specific solutions. Therefore, it may not address the specific use
> cases described in Section 3 of
> I-D.cheng-spring-srv6-policy-resource-gurantee.


[To be clear, a thread in the mailing list can't always be referred to
as "consensus".]


As far as I can see, the framework in
I-D.ietf-spring-resource-aware-segments explains a solution that can
address the specific use case in
I-D.cheng-spring-srv6-policy-resource-gurantee.  Please explain
how/why the framework/solution in
I-D.ietf-spring-resource-aware-segments cannot address that use case.

Note that I-D.ietf-spring-resource-aware-segments proposes allocating
a resource-aware SRv6 Locator for each set of network resources
(keeping the existing behaviors).  OTOH,
I-D.cheng-spring-srv6-policy-resource-gurantee doesn't follow that
guidance because it proposes allocating a SID with the End.NRP
behavior for each set of network resources.

What I'm trying to figure out is whether the extra work is needed.
Again, which cases cannot be addressed using
I-D.ietf-spring-resource-aware-segments?


...
> > The End.NRP behavior is a variation of the End.X behavior.  Will other
> > resource-aware behaviors also need to be defined in the future?
>
> [Wenying] When there are high service quality requirements from customers,
> operators may use network slicing with resource guarantees to ensure the
> expected quality. Typically, the determination of path and resource
> guarantees is made simultaneously to achieve the desired quality assurance
> for the customers.
>
> The End.NRP behavior primarily serves SRv6 Policy strict-path scenarios and
> is a variation of the End.X behavior designed to meet the strict quality
> assurance requirements of the aforementioned customers. Additionally, End.NRP
> can be associated with multiple resources. Currently, there is no immediate
> need to define other variants of the behavior.

I take this explanation to be a "yes" answer to the question: yes,
other resource-aware behaviors will need to be defined in the future.


I am still hoping to hear technical arguments that justify the work.

Thanks!

Alvaro.

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

[spring] BFD in SR-MPLS (draft-ietf-spring-bfd)

[Alvaro Retana]

Dear bfd WG:

The spring WG is moving towards a WGLC of this document:
"Bidirectional Forwarding Detection (BFD) in Segment Routing Networks
Using MPLS Dataplane".  From the Abstract:

   This document defines how to use Label Switched Path (LSP) Ping to
   bootstrap a BFD session, optional control of the selection of a
   segment list as the reverse direction of the BFD session,
   applicability of BFD Demand mode, and Seamless BFD in the SR-MPLS
   domain.  Also, the document describes the use of the BFD Echo function
   with the BFD Control packet payload.


Given the use of BFD, please consider reviewing the draft and
providing comments to the authors/spring WG.

We will cc the bfd WG on the WGLC once it starts.

Thank you!

Alvaro (for the spring-chairs)

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

[spring] BFD in SR-MPLS (draft-ietf-spring-bfd)

[Alvaro Retana]

Dear mpls WG:

The spring WG is moving towards a WGLC of this document:
"Bidirectional Forwarding Detection (BFD) in Segment Routing Networks
Using MPLS Dataplane".  From the Abstract:

   This document defines how to use Label Switched Path (LSP) Ping to
   bootstrap a BFD session, optional control of the selection of a
   segment list as the reverse direction of the BFD session,
   applicability of BFD Demand mode, and Seamless BFD in the SR-MPLS
   domain.  Also, the document describes the use of the BFD Echo function
   with the BFD Control packet payload.


Given the use of LSP Ping and applicability to the MPLS dataplane,
please consider reviewing the draft and providing comments to the
authors/spring WG.

We will cc the mpls WG on the WGLC once it starts.

Thank you!

Alvaro (for the spring-chairs)

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

[spring] IPR Disclosures for draft-ietf-spring-bfd

[Alvaro Retana]

Dear authors and contributors:

Are you aware of any IPR that applies to this draft?

If so, has it been disclosed in compliance with IETF IPR rules (see
BCP78 and BCP79 for more details)?  For any undisclosed IPR, please
provide any additional information you think appropriate.

If you are listed as a document author or contributor, please answer
the above by responding to this email regardless of whether or not you
are aware of any relevant IPR.  This document will only advance to the
next stage once a response is received from each listed author and
contributor.


If you are on the WG email list or attend WG meetings but are not
listed as an author or contributor, we remind you of your obligations
under the IETF IPR rules, which encourage you to notify the IETF if
you are aware of IPR that may be related to this document or to
refrain from participating in any contribution or discussion related
to your undisclosed IPR.  For more information, please see
https://www.ietf.org/standards/ipr/

Thank you,

Alvaro (for the Chairs)

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

Re: [spring] Dependency Issues (WAS: I-D Action: draft-ietf-spring-bfd-09.txt)

[Alvaro Retana]

On April 17, 2024 at 5:49:09 AM, Greg Mirsky wrote:

Greg:

> thank you for pointing out to me that although RFC 8402 defines the
> Anycast-SID, that there's no Anycast-SID sub-TLV in the IANA registry
> Sub-TLVs for TLV Types 1, 16, and 21.  Thus, we remove that paragraph and
> references.

Ok.  Is there any significant loss in functionality or was the use of
anycast "nice to have"?  Just wondering.


> Further more, the authors agreed to changing to the Experimantal track.

Good.  I'll make sure to reflect the change in the datatracker and
when we poll the WG.


> Attached, please find the updated version (I assume that idnit's warning
> about an outdated reference to draft-ietf-mpls-bfd-directed is transitionary
> and get fixed in time).

It will get fixed when you reference the current version. ;-)


> If you agree, I'll upload it instantaneously.

Please go ahead.

I'll start moving the document forward.

Thanks!

Alvaro.

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

Re: [spring] Dependency Issues (WAS: I-D Action: draft-ietf-spring-bfd-09.txt)

[Alvaro Retana]

On April 16, 2024 at 3:55:44 AM, Greg Mirsky wrote:

Greg:

...
> > > > (1) I-D.ietf-spring-mpls-anycast-segments
...
> GIM2>> You're right; the IDR document does not define an Anycast SID (and has
> no reference to the document that does, but that is not our problem now).
> Could we use RFC 8402 as the informational reference? AFAICS, it defines an
> Anycast SID in Terminology section through IGP-Anycast Segment construct:
>
> IGP-Anycast Segment: an IGP-Anycast segment is an IGP-Prefix segment
> that identifies an anycast prefix advertised by a set of routers.
>
> Anycast-SID: the SID of the IGP-Anycast segment.


This is the text we're working with:

   If the target segment is an anycast prefix segment
   ([I-D.ietf-spring-mpls-anycast-segments]) the corresponding Anycast
   SID MUST be included in the Target TLV as the very last sub-TLV.

Yes, rfc8402 could be a replacement -- for what an "anycast prefix segment" is.


As I mentioned before, I did a very light review of the document.
Looking at this sentence a little more...

What is the "Target TLV"?  That name is not used anywhere else.  I
assume it is the same as the "Target FEC TLV" mentioned in the same
section with references to rfc8287 (?).  If so, rfc8287 talks about
the "Target FEC Stack TLV", but doesn't define it; rfc8029 does.
Please use the correct terminology throughout.

Which sub-TLV should be used to carry the information as that "very
last sub-TLV"?  I couldn't find this information in
I-D.ietf-spring-mpls-anycast-segments, rfc8287, or rfc8029, and none
of the sub-TLVs in the registry [1] jump out at me.

[1] 
https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml#sub-tlv-1-16-21


For completion, please add rfc8029 as the reference for the "Target
FEC Stack TLV".  We also need a reference for the sub-TLV.



> > > > (2) I-D.ietf-mpls-bfd-directed
...
> > The only two choices to leave the document "intact" is to change its
> > intended status.
> >
> GIM2>> Thank you for the detailed explanation of the options in front of us.
> Let us think about that and we'll get back with the next step.

Ok.

Thanks!

Alvaro.

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

Re: [spring] Dependency Issues (WAS: I-D Action: draft-ietf-spring-bfd-09.txt)

[Alvaro Retana]

On April 15, 2024 at 5:16:35 PM, Greg Mirsky wrote:


Greg:

...
> > (1) I-D.ietf-spring-mpls-anycast-segments
...
> > Before we try to revive it, is the reference needed? This paragraph
> > is the only one that talks about anycast. Also, it sounds (from the
> > last sentence) as if more could be said about anycast, so perhaps all
> > the considerations can be handled in a future document. (?)
>
> GIM>> I somehow missed that in idnits report. Apologies. I've looked up any
> current IETF document that references the Anycast SID. The only one I have
> found is in Section 5.5 of draft-ietf-idr-bgp-car
> (https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-car/07/). Would changing
> the reference to that draft address your concern?

No.

The mention in draft-ietf-idr-bgp-car is to describe "how Anycast SID
complements and improves the scaling" of the CAR proposal.  It is not
a definition, which is what you need.



> > (2) I-D.ietf-mpls-bfd-directed
> >
> > I-D.ietf-mpls-bfd-directed is a Normative reference and is listed as
> > one of the options in §3 (Use BFD Reverse Path TLV over Segment Routed
> > MPLS Tunnel). However, that document is Experimental, and this one is
> > on the standards track.
> >
> > While downrefs are possible, using I-D.ietf-mpls-bfd-directed is
> > premature. Not only has the document not become an RFC yet, allowing
> > for experience on the experiment to be collected, but the reason for
> > its Experimental status is precisely that the "return path that this
> > session might be less stable than the
> > tunnel being tested" [1].
> >
> > Is the reference required?
> >
> GIM>> In my opinion, if we remove that reference and all that is anchored on
> it, then the document should be changed to Informational because we have taken
> out the Non-FEC TLV and all the IANA requests. Do you see any reasonable way
> forward with that reference?

If the dependency on I-D.ietf-mpls-bfd-directed is so strong, then the
simpler way forward would be to change the status to Experimental (so
they match).

An alternative would be to change the status to Informational, and
leave in the dependency to I-D.ietf-mpls-bfd-directed.  The downref
rules only apply to documents on the standards track.

The IANA registries have ranges that can be used by Informational/Experimental.

In both cases, the only "strange" detail would be that the new
registry would have a couple of "Standards Action" ranges, but I
didn't see anything in rfc8126 that would prohibit that.



> On a somewhat brighter side, draft-ietf-mpls-bfd-directed is close to IESG
> Telechat. And I don't agree (although that is in Shepherd's review) with the
> "return path that this session might be less stable than the tunnel being
> tested," as that came from RtgDir's early review without any substantive
> evidence but as a personal assertion. The reverse path is likely another
> tunnel that is no less stable than the one chosen in the forwarding
> direction. Also, the reported implementation has been in service for several
> years without any problems reported. What would you suggest we do?

The fact that I-D.ietf-mpls-bfd-directed is being processed as
Experimental remains.

The only two choices to leave the document "intact" is to change its
intended status.


Alvaro.

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

[spring] Dependency Issues (WAS: I-D Action: draft-ietf-spring-bfd-09.txt)

[Alvaro Retana]

On January 27, 2024 at 3:00:04 PM, Greg Mirsky wrote:


Greg/authors:

Hi!

> The draft is stable, and the authors believe that it is ready for the WG LC.
> We appreciate your consideration of moving this work forward to the WG LC.


I took a quick look at this document, and we need to address a couple
of dependency-issues before moving closer to WGLC.

[I will provide a more detailed review as we move forward.]


(1) I-D.ietf-spring-mpls-anycast-segments

I-D.ietf-spring-mpls-anycast-segments is listed as an Informative
reference, but it needs to be Normative because it is required in §2:

   If the target segment is an anycast prefix segment
   ([I-D.ietf-spring-mpls-anycast-segments]) the corresponding Anycast
   SID MUST be included in the Target TLV as the very last sub-TLV.
   Also, for BFD Control packet the ingress SR node MUST use precisely
   the same label stack encapsulation, especially Entropy Label
   ([RFC6790]), as for the LSP ping with the BFD Discriminator TLV
that bootstrapped the BFD session. Other operational aspects of using
BFD
   to monitor the continuity of the path to the particular Anycast SID,
   advertised by a group of SR-MPLS capable nodes, will be considered in
   the future versions of the document.

I-D.ietf-spring-mpls-anycast-segments expired almost 4 years ago! :-(

Before we try to revive it, is the reference needed?  This paragraph
is the only one that talks about anycast.  Also, it sounds (from the
last sentence) as if more could be said about anycast, so perhaps all
the considerations can be handled in a future document. (?)


(2) I-D.ietf-mpls-bfd-directed

I-D.ietf-mpls-bfd-directed is a Normative reference and is listed as
one of the options in §3 (Use BFD Reverse Path TLV over Segment Routed
MPLS Tunnel).  However, that document is Experimental, and this one is
on the standards track.

While downrefs are possible, using I-D.ietf-mpls-bfd-directed is
premature.  Not only has the document not become an RFC yet, allowing
for experience on the experiment to be collected, but the reason for
its Experimental status is precisely that the "return path that this
session might be less stable than the
tunnel being tested" [1].

Is the reference required?


Thanks!

Alvaro.


[1] 
https://datatracker.ietf.org/doc/draft-ietf-mpls-bfd-directed/shepherdwriteup/

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

Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

[Alvaro Retana]

Andrew:

Hi!

The question was: "Does anything need to be added, deleted, changed, or
clarified?"  We want to be as specific as possible when we ask 6man for
their feedback.

>From your reply, I see that you are not happy that
§6.5/draft-ietf-spring-srv6-srh-compression doesn't talk about calculating
the upper-layer checksum in flight.  Do you think anything should/could be
added, deleted, changed, or clarified?  Do you have a specific text
proposal?

We plan to highlight the difference between
§6.5/draft-ietf-spring-srv6-srh-compression and §8.1/rfc8200 when we ask
6man for feedback.  I guess (please don't make me guess!) that you would
like 6man to comment on whether that difference represents an issue from
their point of view.  That is the purpose of consulting with them.

There is a separate thread on the topic of mandating the SRH.  Please
comment there too.

Thanks!

Alvaro.

On April 3, 2024 at 9:16:37 AM, Andrew Alston - IETF (
andrew-i...@liquid.tech) wrote:

As requested,



My original email on this topic quoted below – but first some thoughts on
how we could fix this.



   1. We could mandate the imposition of an HBH and then state that the
   draft updates 8200 with adequate text and with 6man agreement – this would
   allow for correct checksumming
   2. We could mandate SRH – though I think this would still require the
   document to note that it updates 8200 and contain text as to how
   3. We could draft and propose a BIS in 6man to update 8200 to cater for
   this – and then make the BIS normative to this draft – meaning that they
   get clustered by the editor such that one does not move without the other.



So I’ve given a lot of thought to the checksum issue – and here is where my
thinking is currently sitting.



 Quoted original email on this topic below 



Firstly – RFC8200 does not mention the word middlebox or middleware
anywhere.  Nor does RFC8200 specify anywhere that the checksum should not
be verifable in flight.



Indeed, section 8.1 actually details how to handle extension headers as
well – in order to make the checksum valid (Last paragraph page 27)



Now, while there are specific uses cases for in flight validation of
checksums which I’m not at liberty to discuss here, surfice to say that
they exist and stem from the need to verify that packet changes aren’t
occuring in flight – I believe that’s kinda besides the point.  The point
here is that as it stands, the draft violates RFC8200.  This leaves two
options in my view a.) Either update 8200 – with the agreement of 6man – or
pass an RFC8200 BIS through 6man.



Either way – if you are violating a standard held by another working group
– and this does violate section 8.1 – you should be updating the standard
that is being violated or alternatively BIS’ing it to avoid the
violation.   But both require that 6man is in full agreement, since SPRING
is not chartered to make updates or violate standards put forward by
another working group.  Hence – my suggestion would be to take this to 6man
and go through the process, though at minimum I fail to see how this cannot
update RFC8200.



In fact, let me be clear here – any attempt to pass this document WITHOUT
correct review by 6man will result in an appeal.



Thanks



Andrew



 End of quoted email 



Thanks



Andrew





* Internal All Employees From: *Alvaro Retana 
*Date: *Wednesday, 3 April 2024 at 15:40
*To: *Andrew Alston - IETF , SPRING WG List <
spring@ietf.org>
*Cc: *spring-cha...@ietf.org 
*Subject: *Re: [spring] C-SIDs and upper layer checksums
(draft-ietf-spring-srv6-srh-compression)

CAUTION: This email has originated from a free email service commonly used
for personal email services, please be guided accordingly especially if
this email is asking to click links or share information.


On April 3, 2024 at 7:59:20 AM, Andrew Alston - IETF wrote:

> Just a clarification – I believe my comments on section 6.5 have been well
> documented in other threads – would you like them duplicated here for
> clarity?

Yes, we do.

Thanks!

Alvaro.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

[Alvaro Retana]

On April 3, 2024 at 7:59:20 AM, Andrew Alston - IETF wrote:

> Just a clarification – I believe my comments on section 6.5 have been well
> documented in other threads – would you like them duplicated here for
> clarity?

Yes, we do.

Thanks!

Alvaro.

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

Re: [spring] Relationship between draft-cheng-spring-srv6-policy-resource-gurantee and draft-ietf-spring-resource-aware-segments

[Alvaro Retana]

On October 24, 2023 at 9:35:32 PM, 姜文颖 wrote:

[Your reply had changed the subject, so my filters didn't catch it.
:-(  Changing the subject back to the original.]


Wenying:

Hi!

Following up from the discussion @ IETF 119.

...
> > Do we need this new extension, or is
> > I-D.ietf-spring-resource-aware-segments enough? Why do we need a separate
> > document? Should the use case defined here be part of the already adopted
> > document?
>
> [WenYing] RFC8986 Section 4.2 End.X forwards to an endpoint with
> cross-connect to a 'layer-3 adjacency', as well as L2 bundle members of an
> L3 LAG interface.
>
> I-D.ietf-spring-resource-aware-segments extends the SR paradigm by
> associating SIDs with network resource attributes, but specific behaviors
> and actual application application scenarios are not defined.
>
> Compared to end.X, the forwarding behavior has been changed, according to
> RFC8986, we need to clearly define its behavior to make the forwarding
> instructions clear.
>
> This document defines the following behavior:
>
> Any SID instance of End.NRP behavior is associated with two sets：J1 and J2.
>
> J1：one or more L3 adjacencies
>
> J2：NRP of J1
>
> The End.NRP SID therefore can be used to build SR paths or virtual networks
> with a set of reserved network resources.
>
> It can be used to identify the set of network resources allocated on the
> segments for packet processing.


I understand that you're defining a new behavior.  However, your
description (last two sentences above) mirrors what
I-D.ietf-spring-resource-aware-segments already defines:

   The resource-aware SIDs retain their original forwarding semantics, but
   with the additional semantics to identify the set of network resources
   available for the packet processing and forwarding action. The resource-
   aware SIDs can therefore be used to build SR paths or virtual networks with
   a set of reserved network resources.


It is not clear to me that the two mechanisms cannot solve the same
use cases.  The difference is in this detail:

I-D.cheng-spring-srv6-policy-resource-gurantee: proposes allocating a SID
   with the End.NRP behavior for each set of network resources

I-D.ietf-spring-resource-aware-segments: proposes allocating a resource-aware
   SRv6 Locator for each set of network resources (keeping the existing
   behaviors)



What use cases cannot be addressed with the existing solution in
I-D.ietf-spring-resource-aware-segments?  [To the authors of
I-D.ietf-spring-resource-aware-segments: it might be useful explain
how the draft addresses the use case in
§3/I-D.cheng-spring-srv6-policy-resource-gurantee.]


The End.NRP behavior is a variation of the End.X behavior.  Will other
resource-aware behaviors also need to be defined in the future?


As mentioned before:


> > I expect to hear technical arguments that clarify the relationship and
> > justify having a separate document. I also expect other WG
> > participants (not just the authors) to express their opinions.

Thanks!

Alvaro.

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

Re: [spring] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

[Alvaro Retana]

[Moving this conversation up on your mailbox. :-) ]

[Thanks, Robert and Tom for your input!]


We want to hear from more of you, including the authors. Even if you
already expressed your opinion in a different thread, please chime in here.

We will collect feedback until the end of this week.

Thanks!

Alvaro.

On March 28, 2024 at 8:06:18 AM, Alvaro Retana (aretana.i...@gmail.com)
wrote:


Focusing on the C-SID draft, some have suggested requiring the presence of
the SRH whenever C-SIDs are used. Please discuss whether that is the
desired behavior (or not) -- please be specific when debating the benefits
or consequences of either behavior.

Please keep the related (but independent) discussion of requiring the SRH
whenever SRv6 is used separate. This larger topic may impact several
documents and is better handled in a different thread (with 6man and spring
included).

Thanks!

Alvaro
-- for spring-chairs
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

[Alvaro Retana]

[Moving this message up on everyone’s mailbox.]

Dear WG:

We have received no replies to this request.  If no changes are needed to
§6.5 then that is ok, but if you have a different opinion please speak up.

Thanks!

Alvaro.

On March 28, 2024 at 8:04:30 AM, Alvaro Retana (aretana.i...@gmail.com)
wrote:


Section 6.5 of draft-ietf-spring-srv6-srh-compression describes the
behavior when an originating node inside an SRv6 domain creates a packet
with a C-SID as the final destination. This description differs from the
text in Section 8.1 of RFC8200.

We plan to send the draft to the 6man WG for review and explicitly
highlight this difference.

Please comment on the text in Section 6.5. Does anything need to be added,
deleted, changed, or clarified?

We want to ask for feedback soon; please send comments on this topic by
April 5th.

Thanks!

Alvaro.
-- for spring-chairs
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

[Alvaro Retana]

Focusing on the C-SID draft, some have suggested requiring the
presence of the SRH whenever C-SIDs are used. Please discuss whether
that is the desired behavior (or not) -- please be specific when
debating the benefits or consequences of either behavior.

Please keep the related (but independent) discussion of requiring the
SRH whenever SRv6 is used separate. This larger topic may impact
several documents and is better handled in a different thread (with
6man and spring included).

Thanks!

Alvaro
-- for spring-chairs

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

[spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

[Alvaro Retana]

Section 6.5 of draft-ietf-spring-srv6-srh-compression describes the
behavior when an originating node inside an SRv6 domain creates a
packet with a C-SID as the final destination. This description differs
from the text in Section 8.1 of RFC8200.

We plan to send the draft to the 6man WG for review and explicitly
highlight this difference.

Please comment on the text in Section 6.5. Does anything need to be
added, deleted, changed, or clarified?

We want to ask for feedback soon; please send comments on this topic
by April 5th.

Thanks!

Alvaro.
-- for spring-chairs

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

[spring] Separating Threads (draft-ietf-spring-srv6-srh-compression)

[Alvaro Retana]

Dear WG:

While the chairs strongly appreciate the engagement in the discussions
around the SRv6 compression draft, several topics have gotten tangled,
and the subject lines do not help track the conversation. Following
this note will be two messages intended to serve as an anchor for
separate aspects of the discussion related to this document.  If we
get the descriptions wrong, please correct us.  If there are other
concerns (quite likely, given the engagement), please start separate
threads.

One discussion aspect has been whether SRv6 should have a distinct
Ethertype. The intarea WG has discussed an existing proposal [1]. To
avoid fragmentation, please move the discussion on this topic to the
intarea mailing list. Copying spring and 6man is appropriate. We note
that various descriptions on email have been unclear as to what is
required of whom ([1] has a specific proposal). Please be clear about
what is proposed/requested.

Thanks!

Alvaro
-- for spring-chairs


[1] https://datatracker.ietf.org/doc/draft-raviolli-intarea-trusted-domain-srv6/

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

Re: [spring] [EXTERNAL] Re: Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Alvaro Retana]

Hi!

This discussion has now moved beyond the specifics of this document
(subject line) and spring's scope.

Please move the discussion to a new thread where both spring and 6man are cc'd.

Thanks!

Alvaro.

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

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Alvaro Retana]

On March 18, 2024 at 10:49:39 AM, Francois Clad wrote:


Francois:

Hi!  Thanks for the update!

> Detailed replies inline. These include your follow-up comments as well as the
> review items that we missed in the first pass.
>
> Please let us know if you have any further feedback.

I have some suggestions below, please consider them for the next revision.


Thanks!

Alvaro.


...
> > I know that this document is not a deployment guide and that it cannot
> > cover all cases. But the current guidance is basically non-existent
> > given the large amount of choice.
>
> There are likely to various other considerations besides the C-SID lengths.
> They may be a mix of technical and/or non-technical. Perhaps the SRv6 Ops
> forum will produce some deployment and operational guidelines for the
> technical aspects. It is not in the scope of this document to serve as a
> deployment or design guide.

At lease please include that ("There are likely to various other
considerations besides the C-SID lengths. They may be a mix of
technical and/or non-technical.") somewhere.

I seem to be the only person asking for additional information, so I
may be in the rough.  However, I don't consider waiting for a future
document a good solution.

Let's move on.



...
> > > > 1094 The segment list that the SR source node pushes onto the packet 
> > > > MUST
> > > > 1095 comply with the rules in Section 6.3 and Section 6.4 and result in 
> > > > a
> > > > 1096 path equivalent to the original segment list.
> > > >
> > > > [major] "MUST...result in a path equivalent to the original segment
> > > > list"
> > > >
> > > > How is a "path equivalent to the original" defined? The next
> > > > paragraph mentions "a compressed segment list of equal or shorter
> > > > length than the uncompressed segment list". What does the length
> > > > refer to -- the number of Segment Lists in the SRH, the size of the
> > > > SRH, or something else?
> > >
> > > We clarified in revision -13 that this is "the same forwarding path".
> > >
> > > The length of a segment list is the number of elements that it contains.
> > >
> > > > 1098 If an SR source node chooses to compress the segment list, one 
> > > > method
> > > > 1099 is described below for illustrative purposes. Any other method
> > > > 1100 producing a compressed segment list of equal or shorter length than
> > > > 1101 the uncompressed segment list is compliant.
> >
> > The requirement is: "MUST...result in the same forwarding path as the
> > original segment list." BUT a method that produces "a compressed
> > segment list of equal or shorter length than the uncompressed segment
> > list is compliant".
> >
> > I understand the intent, but given that it is a requirement, how can
> > "the same forwarding path" be enforced? If the path is loose, how can
> > "the same forwarding path" be guaranteed?
> >
> > Suggestion>
> >
> > The segment list that the SR source node pushes onto the packet MUST
> > comply with the rules in Section 6.3 and Section 6.4 and should result
> > in the same forwarding path as the original segment list.
>
> That's a good point. However, "should result in the same forwarding path" may
> be too loose.
>
> How about "MUST [...] result in the same *set of possible forwarding paths*
> as the original segment list"?

I've been reading this sentence over and over...let's take a step
back.  This is how the text has evolved: "The segment list that the SR
source node pushes onto the packet MUST...result in "

-11: "a path equivalent to the original segment list."

-13: "the same forwarding path as the original segment list."

-14: "the same set of possible forwarding paths as the original segment list."


I was getting stuck on the question of "how can the MUST be enforced
as the packets are forwarded through a *path*?"  But that's the wrong
question.

The "original segment list" includes the SR Policy that represent the
path (in the form of SIDs = segment endpoints) that must be followed.
The compressed segment list must result in a path with the same
segments/segment endpoints (as the "original segment list").  Is that
the correct interpretation?

The requirement (a path with the same segments/segment endpoints) can
only be enforced at the SR Source Node -- it can't be enforced in
transit (in the forwarding path) or at the last segment router.

Suggestion>

   The segment list that the SR source node pushes onto the packet
   MUST...result in the same SR Policy as the original segment list.

Thoughts?



...
> > 1242 6.3. Rules for segment lists containing NEXT-C-SID flavor SIDs
...
> > 1262 6.4. Rules for segment lists containing REPLACE-C-SID flavor SIDs
...
> > [major] Are these requirements validated at any point? For example,
> > if rule #3 is not implemented and the next Segment List is not "a
> > REPLACE-C-SID container in packed format". Which node enforces the
> > fact that the specification is not followed? It seems to me that the
> > only node in that position would be 

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Alvaro Retana]

Tom:

Hi!

I understand your point.

I put the option out there because it came up at last week’s spring meeting
and it should be discussed.

Thanks!

Alvaro.


On March 25, 2024 at 2:58:48 PM, Tom Herbert (t...@herbertland.com) wrote:

On Mon, Mar 25, 2024 at 11:17 AM Alvaro Retana 
wrote:
>
> FWIW, I agree with most of what Joel wrote. ;-)
>
> I see another path forward: Given that the issue is constrained to an SR
domain, the draft could also point out the issues as operational/deployment
considerations. Operators can then make an informed decision on whether
they want to/can use C-SIDs without an SRH in their network. This path
forward (or leaving it out of scope, as Joel suggests below) is something
the spring WG can reach consensus on by itself (i.e., without needing to
consult or agree with other WGs).

Alvaro,.

This wouldn't be robust and would seem to violate the "be conservative
in what you send clause". Punting this to the operators doesn't seem
practical either, in an even moderately large network they wouldn't be
able to know all the potential problems they might hit in devices.
They're about one misconfiguration away from having to debug a rather
unpleasant problem. For instance, if operator gets a packet trace from
a router they would see a whole bunch of packets with bad checksums,
but they would have no way of knowing if these were cases of segment
routing or actually corrupted packets.

Tom
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Alvaro Retana]

FWIW, I agree with most of what Joel wrote. ;-)

I see another path forward: Given that the issue is constrained to an SR
domain, the draft could also point out the issues as operational/deployment
considerations. Operators can then make an informed decision on whether
they want to/can use C-SIDs without an SRH in their network. This path
forward (or leaving it out of scope, as Joel suggests below) is something
the spring WG can reach consensus on by itself (i.e., without needing to
consult or agree with other WGs).

Other solutions that may require updates to rfc8200 or, at least,
consultation with 6man may also be possible. Those solutions should be
discussed with both WGs. While this topic has been discussed before, I
suggest at least using a different thread (with a better subject line).

Thanks!

Alvaro.

On March 25, 2024 at 1:25:57 PM, Joel Halpern (j...@joelhalpern.com) wrote:

(Speaking technically as an individual, but noting that Alvaro and I are
the responsible chairrs who will have to resolve any technical standards
incompatibility.  And I have not talked with Alvaro.  So I may be putting
my foot in my mouth.)

As I understand it, the current view is that the compressed SID draft
permists the case where a single container represents the SR policy.  If
that contianer is using uSID, and if the packet is going between two hosts
in the SRv6 domain, then the SRH may be omitted and no encapsulation is
needed.

In that case, the sending host needs to compute the checksum based on what
the receiver will see.  It can do that, and there is text in the draft to
do so.  There are however two related issues.  First, that direction for
computing the upper layer checksum does not match what RFC 8200 says.  If
indeed that is a change to 8200, then that needs to be indicated somehow,
and presumably approved by 6man.  related to that, any intermediate node
looking at the packet will see an apparently ordinary IPv6 packet whose
upper layer checksum is incorrect.

Tom Herbert, if I am understanding him correctly, is arguing that since the
shifting of the uSID container is essentially  a DA rewrite, the operation
is sufficiently similar to NAT that one should expect the NAT device to
correct the checksum (which is a different repair than the current
compression draft calls for.)

As far as I can tell, this intradomain, non-SRH, uSID case is intendedd to
be supported by the compression solution.  (Another option for the WG would
be to declare that out of scope, but I have not seen evidence the WG wants
that restriction.)  If so, we need to reach agreement on what we expect of
this case, and where it needs to be documented.

Yours,

Joel M. Halpern

PS: Ron has suggested that a HbH optioncould be used to address the
inconsistency.  I do not yet understand the desired behavior there.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Alvaro Retana]

Andrew:

Hi!

Your position is clear.

As I entioned at the spring meeting last week, the 6man-chairs (and
int-ads) are aware of this document.

Also, we will be asking 6man for review/comments soon.

Thanks!

Alvaro.

On March 25, 2024 at 8:05:35 AM, Andrew Alston - IETF (
andrew-ietf=40liquid.t...@dmarc.ietf.org) wrote:

So I’ve given a lot of thought to the checksum issue – and here is where my
thinking is currently sitting.



Firstly – RFC8200 does not mention the word middlebox or middleware
anywhere.  Nor does RFC8200 specify anywhere that the checksum should not
be verifable in flight.



Indeed, section 8.1 actually details how to handle extension headers as
well – in order to make the checksum valid (Last paragraph page 27)



Now, while there are specific uses cases for in flight validation of
checksums which I’m not at liberty to discuss here, surfice to say that
they exist and stem from the need to verify that packet changes aren’t
occuring in flight – I believe that’s kinda besides the point.  The point
here is that as it stands, the draft violates RFC8200.  This leaves two
options in my view a.) Either update 8200 – with the agreement of 6man – or
pass an RFC8200 BIS through 6man.



Either way – if you are violating a standard held by another working group
– and this does violate section 8.1 – you should be updating the standard
that is being violated or alternatively BIS’ing it to avoid the
violation.   But both require that 6man is in full agreement, since SPRING
is not chartered to make updates or violate standards put forward by
another working group.  Hence – my suggestion would be to take this to 6man
and go through the process, though at minimum I fail to see how this cannot
update RFC8200.



In fact, let me be clear here – any attempt to pass this document WITHOUT
correct review by 6man will result in an appeal.



Thanks



Andrew







* Internal All Employees From: *spring  on behalf
of Francois Clad 
*Date: *Monday, 18 March 2024 at 17:50
*To: *Alvaro Retana 
*Cc: *SPRING WG List 
*Subject: *Re: [spring] Chair Review of
draft-ietf-spring-srv6-srh-compression-11

Some people who received this message don't often get email from
fclad.i...@gmail.com. Learn why this is important
<https://aka.ms/LearnAboutSenderIdentification>

CAUTION: This email has originated from a free email service commonly used
for personal email services, please be guided accordingly especially if
this email is asking to click links or share information.



Dear Alvaro,



We have integrated the remainder of your feedback in revision -14.



Detailed replies inline. These include your follow-up comments as well as
the review items that we missed in the first pass.



Please let us know if you have any further feedback.



Thanks,

Francois



> ...

> > > Operational Considerations/Guidance

> > >

> > > Dhruv brought up [1] the point of providing "guidance on when to use

> > > which flavor and with which C-SID lengths". I fully agree! The

> > > document contains (mostly in §4) recommendations, for example, about

> > > LBL and C-SID lengths, even if any other value is possible. IOW, the

> > > possibilities are endless! Please provide more operational

> > > considerations on how an operator can evaluate their needs and select

> > > the appropriate flavor/value for their deployment.

> >

> > We added a paragraph providing such operational guidance in revision
-12, and

> > further clarified it in revision -13.

> >

> > | SRv6 is intended for use in a variety of networks that require

> > | different prefix lengths and SID numbering spaces. Each of the two

> > | flavors introduced in this document comes with its own

> > | recommendations for Locator-Block and C-SID length, as specified in

> > | Section 4.1 and Section 4.2. These flavors are best suited for

> > | different environments, depending on the requirements of the network.

> > | For instance, larger C-SID lengths may be more suitable for networks

> > | requiring ample SID numbering space, while smaller C-SID lengths are

> > | better for compression efficiency. The two compression flavors allow

> > | the compressed segment list encoding to adapt to a range of

> > | requirements, with support for multiple compression levels. Network

> > | operators can choose the flavor that best suits their use case,

> > | deployment design, and network scale.

>

> I don't consider this paragraph enough.  I understand that "different

> environments, depending on the requirements of the network" *may*

> result in a different choice.  I want to understand how "operators can

> choose the flavor that best suits their use case, deployment design,

> and network scale."

>

> Let me illustrate with a

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Alvaro Retana]

On March 4, 2024 at 6:46:33 AM, Huzhibo wrote:

Zhibo:

Hi!

...
> ->HZB:rfc8754 or rfc8986 only defines that Processing is not changed by
> this document. This is only a general description of the standard SRv6, not a
> mandatory specification.

rfc8754 and rfc8986 are the SRv6 specifications!  Not changing the
behavior by not forwarding packets that con't have a corresponding FIB
entry is not a suggestion, it is the expected behavior.


> ->HZB:Of course, as you said, the new endpoint behavior defined in this
> document has been posted to the Spring group discussion.

Maybe I missed that, can you please point me to the thread?



...
> -> HZB :In normal operations...The specific operations of PE3 are as
> follows,This section does not describe the PSP endpoint behavior, but the
> VPN SID endpoint behavior.We will clarify in the next version.

Note that one of the concerns is that the behavior results in some of
the SIDs being skipped, its relationship to the current standards, and
the issues that it may bring up.


Thanks!

Alvaro.

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

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Alvaro Retana]

On February 29, 2024 at 12:50:46 PM, Francois Clad wrote:

Francois:

Hi!

> We have integrated those changes as part of revisions -12 and -13 of the
> document. Please find our detailed replies inline.

I have put comments below as well, and deleted any parts were we agree
or no more discussion is needed.

BTW, it looks like my review may have been truncated: you replied up
to line 1203, but it keeps going.  Take a look at the complete review
here: https://mailarchive.ietf.org/arch/msg/spring/scPK_7Cc8-G2aKbDWQV3sQnC9VA/

Thanks!

Alvaro.


...
> > Operational Considerations/Guidance
> >
> > Dhruv brought up [1] the point of providing "guidance on when to use
> > which flavor and with which C-SID lengths". I fully agree! The
> > document contains (mostly in §4) recommendations, for example, about
> > LBL and C-SID lengths, even if any other value is possible. IOW, the
> > possibilities are endless! Please provide more operational
> > considerations on how an operator can evaluate their needs and select
> > the appropriate flavor/value for their deployment.
>
> We added a paragraph providing such operational guidance in revision -12, and
> further clarified it in revision -13.
>
> | SRv6 is intended for use in a variety of networks that require
> | different prefix lengths and SID numbering spaces. Each of the two
> | flavors introduced in this document comes with its own
> | recommendations for Locator-Block and C-SID length, as specified in
> | Section 4.1 and Section 4.2. These flavors are best suited for
> | different environments, depending on the requirements of the network.
> | For instance, larger C-SID lengths may be more suitable for networks
> | requiring ample SID numbering space, while smaller C-SID lengths are
> | better for compression efficiency. The two compression flavors allow
> | the compressed segment list encoding to adapt to a range of
> | requirements, with support for multiple compression levels. Network
> | operators can choose the flavor that best suits their use case,
> | deployment design, and network scale.

I don't consider this paragraph enough.  I understand that "different
environments, depending on the requirements of the network" *may*
result in a different choice.  I want to understand how "operators can
choose the flavor that best suits their use case, deployment design,
and network scale."

Let me illustrate with an example.  The text above says that "larger
C-SID lengths may be more suitable for networks requiring ample SID
numbering space, while smaller C-SID lengths are better for
compression efficiency".  Ok, what are my choices?

   §4.1: "An implementation MUST support...a 16-bit C-SID length (LNFL) for
          NEXT-C-SID flavor SIDs, and may support any other...C-SID length."

   §4.2: "This document defines the REPLACE-C-SID flavor for 16-bit and 32-bit
          C-SID lengths (LNFL). An implementation MUST support a 32-bit C-SID
          length for REPLACE-C-SID flavor SIDs."

Judging from the *required* implementations, it looks like if an
operator wants a C-SID length that is "better for compression
efficiency" then it should use the NEXT-C-SID flavor (because 16-bit
may only be supported there).

However, if we assume that vendors will offer other options, for
example 16-bit C-SIDs for the REPLACE-C-SID flavor, what next?  Which
C-SID should I chose?

I know that this document is not a deployment guide and that it cannot
cover all cases.  But the current guidance is basically non-existent
given the large amount of choice.



...
> > [major] "SHOULD use a consistent Locator-Block length and C-SID length
> > for all SIDs of the SR domain"
> >
> > When is it ok to not be consistent? IOW, why is this recommended and
> > not required? What are the effects of not being consistent?
>
> Deployments may use any Locator-Block and C-SID length. However, the C-SID
> compression relies on common Locator-Block and consistent C-SID length, so
> using inconsistent ones, while possible, will lead to reduced compression
> efficiency.

Please add this information to the draft.  Note that clarifying this
option is good operational guidance.  Also, it appears several times
in the document.

"Because you can doesn't mean you should."



...
> > 362 An SR segment endpoint node instantiating a SID with the NEXT-C-SID
> > 363 flavor MUST accept any Argument value for that SID.
> >
> > [major] Does this also mean that any future behavior cannot make use
> > of an Argument? IOW, behaviors like End.DT2M cannot be used with the
> > NEXT-C-SID flavor. If so, please be explicit about it.
>
> This statement does not impose any requirement on future behaviors.
>
> The argument of the NEXT-C-SID flavor SIDs defined in this document only
> contains the following C-SIDs in the container, for which an endpoint node
> must accept any value.
>
> A future document defining another NEXT-C-SID flavor SID whose argument
> contains other pieces of information will need to define the structure of

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Alvaro Retana]

Hi!

Now that the terminology is a little more precise, I also looked at the
document and found a couple of cases where SIDs are skipped by SRv6 segment
endpoints, which is what Ketan is really concerned about (?).

These cases (see below) do not align with rfc8754 or rfc8986.  IMO, any
proposed deviation from the existing specifications should be discussed in
spring (for rfc8986) or 6man (for rfc8754), and formal Updates to those
RFCs may be needed.

Thanks!

Alvaro.


(1) From §3.3 (Procedure on the Penultimate Endpoint):

   IF the primary outbound interface used to forward the packet failed
   or there is no FIB entry for forwarding the packet, the detailed
   processing to be performed by the penultimate node is as follows:

 IF SL = 1 THEN
SL decreases by 1 and becomes 0;
Update the IPv6 DA with Segment List[0];
FIB lookup on the updated DA;
Forward the packet according to the matched entry;


There seem to be two cases here: "the primary outbound interface used to
forward the packet failed" and "there is no FIB entry for forwarding the
packet".  I assume (?) they are grouped because the result is that there is
no FIB entry for the destination -- IOW, the link going down results in no
alternate path available.

rfc8754 covers this case:

   4.3.4. FIB Entry Is a No Match

  Processing is not changed by this document.


The result of a non-existent FIB entry is to drop the packet, not to
forward it, as mentioned above.  Changing that action requires an Update to
rfc8754 (and others).

As Bruno pointed out, questions related to "how does the node know" come up.



(2) The operation described in this draft depends on P2 (Figure 3) taking
on the role of the "Penultimate Endpoint".  But the SRH used to illustrate
is "< A1:1::1, A2:1::A100, A3:1::B100, A4:1::B100>", which results in P2
being in the Segment List[2] position.

Also, PE3 also has penultimate endpoint functions in the draft.

rfc8754 and rfc8986 have explicit definitions of what the penultimate
segment endpoint is, and the use of P2 doesn't match any of them:

rfc8754:

   Segment List[0..n]: 128-bit IPv6 addresses representing the nth
  segment in the Segment List. The Segment List is encoded starting
  from the last segment of the SR Policy. That is, the first element
  of the Segment List (Segment List[0]) contains the last segment of
  the SR Policy, the second element contains the penultimate segment
  of the SR Policy, and so on.


rfc8986:

   A PSP-flavored SID is used by the SR source node when it needs to
   instruct the penultimate SR Segment Endpoint Node listed in the SRH
   to remove the SRH from the IPv6 header.
   ...
   A penultimate SR Segment Endpoint Node is one that, as part of the
   SID processing, copies the last SID from the SRH into the IPv6
   Destination Address and decrements the Segments Left value from one
   to zero.

   The PSP operation only takes place at a penultimate SR Segment
   Endpoint Node and does not happen at any transit node. When a SID of
   PSP flavor is processed at a non-penultimate SR Segment Endpoint
   Node, the PSP behavior is not performed as described in the
   pseudocode below since Segments Left would not be zero.


There are both terminology (using "penultimate" to describe any node other
than the one at Segment List[1]) and operation changes that would be
required in rfc8754 and rfc8986.



(3) From §4:

   In normal operations...The specific operations of PE3 are as follows:

   1) Remove the outer packet header and all its extension headers.

   2) Look up the FIB table according to the destination address of the
  original packet.

   3) Send the packet to CE2 according to the FIB entry.


First, much more is needed to explain the operation (codifying with
pseudocode as all the other SRH-related operations).  The PSP flavor is
specified in §4.16.1.2/rfc8986; it includes "S14. Update IPv6 DA with
Segment List[Segments Left]" (not the "destination address of the original
packet", as indicated above).

Changing how the PSP flavor works in "normal operations" would require an
Update of rfc8986.  Note that this draft doesn't indicate how P2 would know
the proposed process would have to be used (vs existing cases).

On February 25, 2024 at 12:44:18 AM, Yingzhen Qu (yingzhen.i...@gmail.com)
wrote:

Dear SPRING WG and chairs,

I'd like to bring your attention to this adoption call happening in the
RTGWG WG.

The draft describes a SRv6 egress node protection mechanism in multi-home
scenarios. As Ketan has commented in his email below the proposal requires
a P router to process SRH with new endpoint behavior.

We'd like to get your comments about the proposed extensions. Please send
your reply to both the SPRING and RTGWG mailing lists.

Thanks,
Yingzhen

On Wed, Feb 21, 2024 at 8:06 AM Ketan Talaulikar 
wrote:

> Hi Yingzhen/All,
>
> I have some concerns regarding the adoption of this document.
>
>
> - Do 

[spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Alvaro Retana]

Dear authors:

In parallel with the WGLC I have reviewed this document.  Thank you
for the work you've put into it so far.

I have several comments (in-line below) that I would like to see
addressed.  In general, I think my comments should be relatively easy
to address.  I want to highlight one point up-front:

Operational Considerations/Guidance

   Dhruv brought up [1] the point of providing "guidance on when to use
   which flavor and with which C-SID lengths".  I fully agree!  The
   document contains (mostly in §4) recommendations, for example, about
   LBL and C-SID lengths, even if any other value is possible.  IOW, the
   possibilities are endless!  Please provide more operational
   considerations on how an operator can evaluate their needs and select
   the appropriate flavor/value for their deployment.

   I included some in-line comments below.


Thanks!

Alvaro.


[1] https://mailarchive.ietf.org/arch/msg/spring/p3GGcuoqOjHaLjrJJaQpKzURTn0



[Line numbers from idnits]

...
142 1.  Introduction
...
160    The flavors defined in this document leverage the SRv6 data plane
161    defined in [RFC8754] and [RFC8986], and are compatible with the SRv6
162    control plane extensions for IS-IS [RFC9352], OSPF [RFC9513], and BGP
163    [RFC9252].

[minor] rfc9252 is about SRv6-based BGP services -- is it the best
(general) BGP reference to use at this point?



165 2.  Terminology
...
188    *  C-SID sequence: A group of one or more consecutive segment list
189       entries carrying the common Locator-Block and at least one C-SID
190       container.

[minor] It seems to me that this definition is a little off -- looking
at it from the point of view of a "C-SID sequence" having to be a
sequence of C-SIDs, not a of segment list entries.

> Suggestion:

   *  C-SID sequence: A group of one or more consecutive C-SIDs sharing
      a common Locator-Block and at least one C-SID container.


192    *  Uncompressed SID sequence: A group of one or more uncompressed
193       SIDs in a segment list.

[minor] The definition of a "C-SID sequence" pointed at the fact that
a sequence is "consecutive".  Is that the case here too?



...
229 3.  Basic Concepts
...
246    A segment list can be encoded in the packet header using any
247    combination of compressed and uncompressed sequences.  The C-SID
248    sequences leverage the flavors defined in this document, while the
249    uncompressed sequences use behaviors and flavors defined in other
250    documents, such as [RFC8986].  An SR source node constructs and
251    compresses the SID-list depending on the capabilities of each SR
252    segment endpoint node that the packet should traverse, as well as its
253    own compression capabilities.

[minor] "An SR source node constructs and compresses the SID-list
depending on the capabilities of each SR segment endpoint node that
the packet should traverse..."

Which "capabilities of each SR segment endpoint node" are you
referring to?  How does the SR source node learn about them?  Later in
the text you talk about advertising the C-SIDs and the SRv6 SID
Structure, but those are not "node capabilities".



...
261 4.  SR Segment Endpoint Flavors
...
291    The SIDs of both flavors can co-exist in the same SR domain, on the
292    same SR segment endpoint node, and even in the same segment list.
293    However, it is RECOMMENDED, for ease of operation, that a single
294    compressed encoding flavor be used in a given routing domain.  In a
295    multi-domain deployment, different flavors MAY be used in different
296    routing domains of the SR domain.

[major] s/MAY/may

The fact that two flavors exist allows for different ones being used
in different routing domains.  IOW, the use of "MAY" doesn't add any
normative value.



...
311 4.1.  NEXT-C-SID Flavor

313    A C-SID sequence using the NEXT-C-SID flavor comprises one or more
314    C-SID containers.  Each C-SID container is a fully formed 128-bit
315    SID.  It carries a Locator-Block followed by a series of C-SIDs.  The
316    Locator-Node and Function of the C-SID container are those of the
317    first C-SID, and its Argument is the contiguous series of subsequent
318    C-SIDs.  The second C-SID is encoded in the most significant bits of
319    the C-SID container Argument, the third C-SID is encoded in the bits
320    of the Argument that immediately follow the second C-SID, and so on.
321    When all C-SIDs have the same length, a C-SID container can carry up
322    to K C-SIDs, where K is computed as floor((128-LBL)/LNFL).  Each
323    C-SID container for NEXT-C-SID is independent, such that contiguous
324    C-SID containers in a C-SID sequence can be considered as separate
325    C-SID sequences.

[major] It should be specified that any remaining bits MUST be 0-padded.


[major] Please 

Re: [spring] Mail regarding draft-ietf-spring-sr-policy-yang

[Alvaro Retana]

[Adding Shunwan explicitly because the message bounced.]

On January 9, 2024 at 1:12:19 PM, Alvaro Retana (aretana.i...@gmail.com)
wrote:



Dear authors:

I hope you're all doing well.

This document expired in March/2023, but I haven't seen anything from you
on the list since the last update.

Are you still interested in proceeding with this work?  If so, please post
an update with fewer front-page authors (5 maximum).  Also, please let the
WG know your plan to move the work forward.

Given that this is a WG draft and other drafts depend on it, we'll look for
new authors to continue if you are no longer interested.

Either way, please let us know by January 24, 2024.

Thanks!

Alvaro.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] Mail regarding draft-ietf-spring-srv6-yang

[Alvaro Retana]

Dear authors:

I hope you're all doing well.

This document expired in March/2023, but I haven't seen anything from
you on the list since the last update.

Are you still interested in proceeding with this work?  If so, please
post an update with fewer front-page authors (5 maximum).  Also,
please let the WG know your plan to move the work forward.

Given that this is a WG draft and other drafts depend on it, we'll
look for new authors to continue if you are no longer interested.

Either way, please let us know by January 24, 2024.

Thanks!

Alvaro.

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

[spring] Mail regarding draft-ietf-spring-sr-policy-yang

[Alvaro Retana]

Dear authors:

I hope you're all doing well.

This document expired in March/2023, but I haven't seen anything from
you on the list since the last update.

Are you still interested in proceeding with this work?  If so, please
post an update with fewer front-page authors (5 maximum).  Also,
please let the WG know your plan to move the work forward.

Given that this is a WG draft and other drafts depend on it, we'll
look for new authors to continue if you are no longer interested.

Either way, please let us know by January 24, 2024.

Thanks!

Alvaro.

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

Re: [spring] Missing review material for the 15-minute slot for SRv6 Security Considerations (was: Re: SPRING Session Agenda for 118)

[Alvaro Retana]

On November 2, 2023 at 5:25:37 AM, Zafar Ali (zali) wrote:


Zafar:

Hi!

> It is odd that design team [1] has a 15-minute prime slot in SPRING agenda
> while it has not produced any draft (see
> https://www.rfc-editor.org/rfc/rfc2418.html#section-3.1).

Let me start by saying that the authors of the upcoming security
consideration draft are not part of a design team.  As you can see in
the message you mentioned [a], and in the preceding one [b], we
purposefully asked for volunteers to be authors.


>From [a]:

   SRv6 security and this document are on the radar of the IESG, making
   them a high-priority work item for the WG.  We expect the work to be
   progressed, presented, and reviewed in a timely manner, which should
   include periodic updates and discussions on the list and at in-person
   and virtual interim meetings (as needed).

As chairs we took the liberty to prioritize an update at the upcoming
meeting -- it should be important to all of us.

You will have an opportunity to comment on the agenda in Prague and
about the contents as the document progresses through the process.


Nick already replied to you about the state of the draft.  We all know
this is not the first time authors miss the deadline.



> When SRv6 compression design team was formed, a design team mailer was
> created which was open to the WG. This is not the case for this design team.
> Overall, the WG members has no visibility of the work done by the design
> team.

Again, this is not a design team.  The development of this document is
happening in the same way that any other group of authors would do it.
Nick pointed you to their repository.



> I do not think the WG is ready to participate effectively for the 15-minute
> slot in SPRING.

As Nick mentioned, the time next week will mostly be used to ask for
"eyeballs and input".  We are far from any decision that may need to
be made by the WG (adoption, for example).  Also, I expect most of the
discussion to happen on the list.


Alvaro.


[a] https://mailarchive.ietf.org/arch/msg/spring/8xH7XOEYLAo2r7Pn9fyP_CdOfqs/

[b] https://mailarchive.ietf.org/arch/msg/spring/SxNKw2kWw3W3sHoyY32ngRexzeU/


> [1] The design team was formed on September 1, 2023 
> (https://mailarchive.ietf.org/arch/msg/spring/8xH7XOEYLAo2r7Pn9fyP_CdOfqs/)

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

Re: [spring] spring WG Adoption Call for draft-cheng-dhc-distribute-srv6-locator-by-dhcp

[Alvaro Retana]

Hi!

This messages closed the adoption call for this draft.  There has been
sufficient support and the authors have addressed the concerns what were
brought up successfully. The document is adopted.

Authors: Please submit a replacement draft
(draft-ietf-spring-dhc-distribute-srv6-locator-by-dhcp).  The submission
window should open again during IETF 118.

Thanks!

Alvaro.

On July 5, 2023 at 8:00:03 AM, Alvaro Retana (aretana.i...@gmail.com) wrote:


Dear WG:

This message starts a two-week adoption call for
draft-cheng-dhc-distribute-srv6-locator-by-dhcp, ending on July/19.  It
"describes the method of assigning locators to SRv6 Endpoints through
DHCPv6".


https://datatracker.ietf.org/doc/draft-cheng-spring-distribute-srv6-locator-by-dhcp/



Please review the draft and consider whether you support its adoption by
the WG.  Please share any thoughts with the list to indicate support or
opposition -- this is not a vote.

If you are willing to provide a more in-depth review, please state it
explicitly to give the chairs an indication of the energy level in the
working group willing to work on the document.

WG adoption is the start of the process.  The fundamental question is
whether you agree the proposal is worth the WG's time to work on and
whether this draft represents a good starting point.  The chairs are
particularly interested in hearing the opinion of people who are not
authors of the document.

Thanks!

Alvaro (for the Chairs)
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] IPR Poll for draft-cheng-dhc-distribute-srv6-locator-by-dhcp (adoption)

[Alvaro Retana]

Hi!

We’re still missing a response to this poll from Geng Zhang (cc’d).

Please reply so we can move on with this document.

Thanks!

Alvaro.

On July 5, 2023 at 8:01:01 AM, Alvaro Retana (aretana.i...@gmail.com) wrote:


Dear authors:

Are you aware of any IPR that applies to this draft?

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
BCP78 and BCP79 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
answer the above by responding to this email regardless of whether or not
you are aware of any relevant IPR.  This document will not advance to the
next stage until a response is received from each author.


If you are on the WG email list or attend WG meetings but are not listed as
an author or contributor, we remind you of your obligations under the IETF
IPR rules, which encourage you to notify the IETF if you are aware of IPR
of others on an IETF contribution or to refrain from participating in any
contribution or discussion related to your undisclosed IPR.  For more
information, please see https://www.ietf.org/standards/ipr/

Thank you,

Alvaro (for the Chairs)
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Relationship betweendraft-cheng-spring-srv6-policy-resource-gurantee anddraft-ietf-spring-resource-aware-segments

[Alvaro Retana]

On October 12, 2023 at 11:37:01 PM, 姜文颖 wrote:


WenYing:

Hi!


> We received the similar comments before IETF 107 [1] and the authors of both
> drafts had worked together to resolve it in the latest version. We has
> clarified the scope in draft-cheng and has changed the name of the draft to
> "draft-cheng-spring-srv6-policy-resource-guarantee" to better differentiate
> the two drafts. The authors of both drafts have reached a consensus and
> recommend that WG proceed with them separately.

Consensus needs to be reached within the WG, not between authors.
This thread is precisely so the WG Chairs can determine what the WG
considers the best path forward.


The scope and new name didn't help me with my questions: "Is this
document an instantiation of a use case already covered by
I-D.ietf-spring-resource-aware-segments, or is it a new application?
Do we need this new extension, or is
I-D.ietf-spring-resource-aware-segments enough? Why do we need a
separate document? Should the use case defined here be part of the
already adopted document?"

I expect to hear technical arguments that clarify the relationship and
justify having a separate document.  I also expect other WG
participants (not just the authors) to express their opinions.



> The main differences are as follows：
>
> Draft #1 draft-ietf-spring-resource-aware-segments
>
> This draft extends the SR paradigm by associating SIDs with network resource
> attributes，and specific behaviors and actual application application
> scenarios are not defined.
>
>
> Draft #2 draft-cheng-spring-srv6-policy-resource-gurantee
>
> Based on draft-ietf-spring-resource-aware-segments，This draft further defines
> specific behaviors, and actual application application scenarios for End.NRP
> behavior. This draft can provide guidance when deploying. The SRv6 END.NRP
> functional mechanism has a running code, and China Mobile has completed the
> verification of this function.

Based on this characterization, let me ask for a little more detail
(related to the original questions):

- draft-cheng-spring-srv6-policy-resource-gurantee "draft further
defines specific behaviors, and actual application", so it is not
defining a new concept -- it is providing additional details
(behaviors/applications) not present in
draft-ietf-spring-resource-aware-segments.  Is this a correct
assessment?

- draft-cheng-spring-srv6-policy-resource-gurantee defines a new
behavior (END.NRP).  Why is this new behavior needed?  Why can't the
same (or similar) result not be achieved using
draft-ietf-spring-resource-aware-segments (and existing behaviors)?

- If the additional details are necessary, why do we need a separate
document?  IOW, why can't these details be added to
draft-ietf-spring-resource-aware-segments?


To be clear.  Because this document is closely related to an
already-adopted WG document, we (chairs) must be diligent about any
overlap.  That is the primary purpose of these questions, given that
you asked for adoption.

Even though this document is far from needing an Implementation
Description [1], please add text to the draft describing the existing
code.  Note that existing code does not guarantee adoption.


Thanks!

Alvaro.


[1] https://wiki.ietf.org/en/group/spring/WG_Policies

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

[spring] Relationship between draft-cheng-spring-srv6-policy-resource-gurantee and draft-ietf-spring-resource-aware-segments

[Alvaro Retana]

Dear authors (of draft-cheng-spring-srv6-policy-resource-gurantee):

Hi!

Building on Jie's comments at IETF 115 [1] and this text from the
Introduction: "On the basis of
[I-D.ietf-spring-resource-aware-segments], this document defines a new
SRv6 Endpoint behavior...", please clarify the relationship between
these 2 documents.

Is this document an instantiation of a use case already covered by
I-D.ietf-spring-resource-aware-segments, or is it a new application?
Do we need this new extension, or is
I-D.ietf-spring-resource-aware-segments enough?  Why do we need a
separate document?  Should the use case defined here be part of the
already adopted document?

We (chairs) would like to hear comments from the authors of both
documents and the WG in general.

Thanks!

Alvaro.

[1] 
https://datatracker.ietf.org/doc/minutes-115-spring/#network-resource-programming-with-srv6-10-mins

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

Re: [spring] Fw:New Version Notificationfordraft-cheng-spring-srv6-resource-programming-01.txt

[Alvaro Retana]

WenYing:

Hi!

I have added this draft to the adoption queue in the WG’s wiki:
https://wiki.ietf.org/en/group/spring

In the meantime, we would like to see more comments from the list.

Also, the Security Considerations are empty.  Please work on appropriate
text.

Thanks!

Alvaro.

On September 28, 2023 at 2:40:31 AM, 姜文颖 (jiangweny...@chinamobile.com)
wrote:

Hi Chairs and WG，



We have updated the draft and addressed all the comments received. The
draft is stable, and we hope to ask for WG adoption.



1.  According to Jie's comments:

  Changed the draft name from draft-cheng-spring-srv6-resource-programming
(Network Resource Programming with SRv6)  to

  draft-cheng-spring-srv6-policy-resource-gurantee-00( Resource Guarantee
for SRv6 Policies),


https://datatracker.ietf.org/doc/draft-cheng-spring-srv6-policy-resource-gurantee/

  Due to the name change, it is version 00.



2.  According to the comments from 115th meeting and maillist:

  Add reference: ietf-spring-resource-aware-segments

  Improve Use Cases for End.NRP behavior section

--Update to leased line as use case.

  Addressed review comments from several WG participants.



Any comments are welcomed.



BR

WenYing



邮件原文
*发件人：*Weiqiang Cheng 
*收件人：*"'Dongjie \\(Jimmy\\)'" ,'spring' <
spring@ietf.org>
*抄 送: *(无)
*发送时间：*2023-03-13 18:33:44
*主题：*
Re: [spring] Fw:New Version
Notificationfordraft-cheng-spring-srv6-resource-programming-01.txt

Hi Jie,

Thanks a lot.

We can consider a proper name in next revision.



To Group,

We’ve addressed all the comments and the draft is stable.

We hope to ask for WG adoption.

Any comments are welcomed.



B.R.

Weiqiang Cheng





*发件人:* Dongjie (Jimmy) [mailto:jie.d...@huawei.com]
*发送时间:* 2023年3月13日 14:41
*收件人:* Weiqiang Cheng; spring
*主题:* RE: [spring] Fw:New Version Notification
fordraft-cheng-spring-srv6-resource-programming-01.txt



Hi Weiqiang,



Thanks for addressing my comments made on IETF 115 meeting, it is good to
see this version refers to draft-ietf-spring-resource-aware-segments.



This document focuses on introducing resource guarantee to SR policies,
which is one of the use cases of resource-aware segments. It may be easier
for the readers if the document name could reflect its scope better.



Best regards,

Jie



*From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Weiqiang
Cheng
*Sent:* Friday, March 10, 2023 11:20 AM
*To:* spring 
*Subject:* [spring] Fw:New Version Notification
fordraft-cheng-spring-srv6-resource-programming-01.txt



Hi all,



We have updated the
https://datatracker.ietf.org/doc/draft-cheng-spring-srv6-resource-programming/
based
on the comments from 115th meeting and maillist.

This draft defines a new SRv6 Endpoint behavior which can be used to
associate with a set of network resource partition (e.g. bandwidth, buffer
and queue resources ).  Any comments are welcomed.

To Jie Dong, we captured your comment in jabber, we also have addressed
your comments.  Please review it. Thanks.



BR,

Weiqiang



原始邮件 来自 internet-drafts 发送日期： Thu Mar 09 22:04:37 GMT+08:00
2023 至 ： Changwang Lin ,Detao Zhao ,Jiang Wenying ,Ran Chen ,Weiqiang Cheng
,Wenying Jiang 主题： New Version Notification for
draft-cheng-spring-srv6-resource-programming-01.txt A new version of I-D,
draft-cheng-spring-srv6-resource-programming-01.txt has been successfully
submitted by Wenying Jiang and posted to the IETF repository. Name:
draft-cheng-spring-srv6-resource-programming Revision: 01 Title: Network
Resource Programming with SRv6 Document date: 2023-03-09 Group: Individual
Submission Pages: 8 URL:
https://www.ietf.org/archive/id/draft-cheng-spring-srv6-resource-programming-01.txt
Status:
https://datatracker.ietf.org/doc/draft-cheng-spring-srv6-resource-programming/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-cheng-spring-srv6-resource-programming
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-cheng-spring-srv6-resource-programming-01
Abstract: This document defines a new SRv6 network function which can be
used for SRv6 Network Resource Programming. The IETF Secretariat






祝好！

**

姜文颖

中国移动通信研究院 基础网络技术研究所

地址：北京市西城区宣武门西大街32号（100053）

Email：jiangweny...@chinamobile.com

电话：15801696688-34257，13810389325

**
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Performance Measurement using STAMP for SR Merge (draft-ietf-spring-stamp-srpm + draft-gandhi-spring-enhanced-srpm)

[Alvaro Retana]

Hi!

No objections were received.  The authors can go ahead with the merge.

Thanks!

Alvaro.

On August 31, 2023 at 11:57:54 AM, Alvaro Retana (aretana.i...@gmail.com)
wrote:


Dear WG:

As discussed at the WG meeting in San Francisco [1], the authors of
draft-gandhi-spring-enhanced-srpm [2] have requested merging the procedure
defined there into draft-ietf-spring-stamp-srpm [3] [4].

There wasn't any objection to doing so during the meeting.  If anyone
objects to the merge, please reply to this message explaining your
reasons.  This call will close on September 8, 2023.

Thanks!

Alvaro (for the Chairs)



[1]
https://datatracker.ietf.org/doc/minutes-117-spring/#1000-enhanced-performance-measurement-using-simple-twamp-in-segment-routing-networks-15-mins


[2] https://datatracker.ietf.org/doc/html/draft-gandhi-spring-enhanced-srpm


[3] https://datatracker.ietf.org/doc/html/draft-ietf-spring-stamp-srpm

[4]
https://datatracker.ietf.org/meeting/117/materials/slides-117-spring-enhanced-performance-measurement-using-simple-twamp-in-segment-routing-networks-00
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] SRv6 Security Considerations (author team)

[Alvaro Retana]

Dear WG:

We received a good set of volunteers to serve as authors in developing
a document to provide a solid security analysis of SRv6 [1].  Thank
you to all who volunteered!

This is the team the chairs selected:

  Nick Buraglio
  Luis Contreras
  Fernando Gont
  Tal Mizrahi
  Tian Tong


While, as with any other document, the WG will decide on its adoption
and eventual progress, what follows are specifics related to the
chairs' expectations:

(1) The work will consider SRv6 as specified in RFC8402 (Segment Routing
    Architecture), RFC8754 (IPv6 Segment Routing Header (SRH)), RFC8986
    (Segment Routing over IPv6 (SRv6) Network Programming), and other related
    RFCs.  It should consider security-related topics not covered in those
    existing RFCs or that may need further coverage.

(2) The objective is to identify threats, analyze potential mitigation
    mechanisms, and highlight gaps that may affect the deployment of SRv6.
    The proposal of solutions to close any gaps is outside the scope of the
    document.

(3) The document should limit itself to an analysis of SRv6 and not compare it
    with other technologies.


As a first step, the authors will define a high-level outline of the
topics to be covered.   A description of a threat model is a necessary
component.

SRv6 security and this document are on the radar of the IESG, making
them a high-priority work item for the WG.  We expect the work to be
progressed, presented, and reviewed in a timely manner, which should
include periodic updates and discussions on the list and at in-person
and virtual interim meetings (as needed).


Thanks!

Alvaro (for the Chairs)

[1] https://mailarchive.ietf.org/arch/msg/spring/SxNKw2kWw3W3sHoyY32ngRexzeU/

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

[spring] Performance Measurement using STAMP for SR Merge (draft-ietf-spring-stamp-srpm + draft-gandhi-spring-enhanced-srpm)

[Alvaro Retana]

Dear WG:

As discussed at the WG meeting in San Francisco [1], the authors of
draft-gandhi-spring-enhanced-srpm [2] have requested merging the
procedure defined there into draft-ietf-spring-stamp-srpm [3] [4].

There wasn't any objection to doing so during the meeting.  If anyone
objects to the merge, please reply to this message explaining your
reasons.  This call will close on September 8, 2023.

Thanks!

Alvaro (for the Chairs)



[1] 
https://datatracker.ietf.org/doc/minutes-117-spring/#1000-enhanced-performance-measurement-using-simple-twamp-in-segment-routing-networks-15-mins

[2] https://datatracker.ietf.org/doc/html/draft-gandhi-spring-enhanced-srpm

[3] https://datatracker.ietf.org/doc/html/draft-ietf-spring-stamp-srpm

[4] 
https://datatracker.ietf.org/meeting/117/materials/slides-117-spring-enhanced-performance-measurement-using-simple-twamp-in-segment-routing-networks-00

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

[spring] Call for Authors: SRv6 Security Considerations

[Alvaro Retana]

Dear WG:

As mentioned at last week's meeting in San Francisco [1], the WG will produce a
document to provide a solid security analysis of SRv6.  It will examine SRv6 as
currently specified, identify threats, analyze mitigation mechanisms, and
highlight gaps, but not propose solutions.

The chairs will select a team of five authors to write this document.  As with
any other document, the WG will decide on its adoption and eventual progress.


If you want to serve as an author, please email the WG chairs *only* (no need
to cc the WG list).  If you believe there are reasons to select you that we may
not be aware of, please include them in your email.

This call is open until EOD on August 23, 2023.


Thanks!

Alvaro (for the Chairs)


[1] 
https://datatracker.ietf.org/meeting/117/materials/slides-117-spring-chairs-00.pdf

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

Re: [spring] Question regarding draft-ietf-spring-srv6-srh-compression

[Alvaro Retana]

On August 2, 2023 at 1:59:13 AM, Tal Mizrahi wrote:

Tal:

Hi!

> A question to the chairs: is the L4 checksum issue something that can
> be resolved in SPRING, or does it have to go through 6MAN?

If the resolution requires an update to rfc8200, 6man has to be
involved.  This document (a spring document) should be able to contain
the update, but we will need 6man to be involved.

We will cc 6man in the eventual WGLC.  In the meantime, please start a
separate thread (with an updated subject) explaining the issue and cc
both spring and 6man.

Thanks!

Alvaro.

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

Re: [spring] SPRING Session Agenda for 117

[Alvaro Retana]

[Thanks Shuping!]

To all the authors/presenters:

If your draft hasn’t had significant discussion on the list, please take
time to share the proposal/updates *before* the meeting.  Doing so should
facilitate the conversation in San Francisco.

Thanks!

Alvaro.

On July 11, 2023 at 11:31:39 PM, Pengshuping (Peng Shuping) (
pengshup...@huawei.com) wrote:

Dear all,

The SPRING Agenda is posted. The associated drafts are also linked.
https://datatracker.ietf.org/meeting/117/materials/agenda-117-spring-00

If any amendment is needed, please get in touch.

To all the presenters, please directly upload your slides
https://datatracker.ietf.org/meeting/117/session/30537/slides or send them
to the spring-cha...@ietf.org before Monday
evening. Please be aware that the number of slides should be compatible
with the number of minutes on the agenda (e.g. max 6 slides with content
for a 10 minutes slot)=
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] IPR Poll for draft-cheng-dhc-distribute-srv6-locator-by-dhcp (adoption)

[Alvaro Retana]

Dear authors:

Are you aware of any IPR that applies to this draft?

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 BCP78 and BCP79 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 answer the above by responding to this email regardless of
whether or not you are aware of any relevant IPR.  This document will
not advance to the next stage until a response is received from each
author.


If you are on the WG email list or attend WG meetings but are not
listed as an author or contributor, we remind you of your obligations
under the IETF IPR rules, which encourage you to notify the IETF if
you are aware of IPR of others on an IETF contribution or to refrain
from participating in any contribution or discussion related to your
undisclosed IPR.  For more information, please see
https://www.ietf.org/standards/ipr/

Thank you,

Alvaro (for the Chairs)

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

[spring] spring WG Adoption Call for draft-cheng-dhc-distribute-srv6-locator-by-dhcp

[Alvaro Retana]

Dear WG:

This message starts a two-week adoption call for
draft-cheng-dhc-distribute-srv6-locator-by-dhcp, ending on July/19.
It "describes the method of assigning locators to SRv6 Endpoints
through DHCPv6".

   
https://datatracker.ietf.org/doc/draft-cheng-spring-distribute-srv6-locator-by-dhcp/


Please review the draft and consider whether you support its adoption
by the WG.  Please share any thoughts with the list to indicate
support or opposition -- this is not a vote.

If you are willing to provide a more in-depth review, please state it
explicitly to give the chairs an indication of the energy level in the
working group willing to work on the document.

WG adoption is the start of the process.  The fundamental question is
whether you agree the proposal is worth the WG's time to work on and
whether this draft represents a good starting point.  The chairs are
particularly interested in hearing the opinion of people who are not
authors of the document.

Thanks!

Alvaro (for the Chairs)

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

Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT)

[Alvaro Retana]

On March 5, 2022 at 5:29:36 AM, Ketan Talaulikar wrote:

Ketan:

Hi!

> We have also just posted an update to address some of the comments below and
> from other ADs.
>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-19

That version addresses my DISCUSS -- I'm clearing.  I have one reply
in the comments below.


Thanks!

Alvaro.

...
> > > > (7) §2.4: "When signaling is via PCEP...the AS number SHOULD be set to
> > > > 0 by default when not available or known."
> > > >
> > > > When is it ok for the ASN to not be set to 0 (when not available or
> > > > known)? If that possibility exists, the PCE can use any value
> > > > (including the real number or a random one). What issues exist with
> > > > uncoordinated (or rogue) PCEs using potentially arbitrary ASNs?
> > > >
> > > > Why is this action recommended and not required?
> > >
> > > KT> AFAIR PCEP signaling does not carry AS number. So this is a
> > > recommendation, though a local policy or a future PCEP extension could
> > > change that and we don't want to preclude it.
> >
...
> > If the ASN can be signaled, when is it ok for it to not be set to 0
> > (when not available or known)? If that possibility exists, the PCE
> > can use any value (including the real number or a random one). What
> > issues exist with uncoordinated (or rogue) PCEs using potentially
> > arbitrary ASNs?
>
> KT> I will leave this question for the PCEP WG if and when they decide to add
> support for ASN to be signaled. It does not make any impact from this
> specification perspective since it is only used to identify the originator.

The impact on this document it that it is specifying the behavior
Normatively  - let's eliminate that.

Suggestion>
   If signaling via PCEP, it is the IPv4 or IPv6 address of the PCE and
   the AS number is expected to be set to 0 by default when not available
   or known.

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

Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT)

[Alvaro Retana]

On February 17, 2022 at 10:06:39 AM, Ketan Talaulikar wrote:


Ketan:

Hi!

I am looking at -18.  Thanks for adding the Updates tag -- you need to
also add text to the Introduction about the update.

Comments inline...


> > --
> > DISCUSS:
> > --
...
> > Besides the general topic of clarifying and updating what an SR Policy is,
> > this document also includes other items that were not present in rfc8402;
> > the list includes:
> >
> > §2.1: "SR Policy MUST be identified through the tuple  > endpoint>."   There's not even a mention of "color" in rfc8402.
> >
> > §2.1: "The headend is specified as an IPv4 or IPv6 address and is expected
> > to be unique in the domain." Neither the mechanism to identify a node nor
> > the expectation is present in rfc8402.
> >
> > §2.1: "The endpoint is specified as an IPv4 or IPv6 address and is expected
> > to be unique in the domain." Same as above.
>
> KT> Yes, these are the constructs of SR Policy that are specified by this
> document.
>
> >
> >
> > The SR Database is a new element not in the base architecture. The text in
> > §3 says that "use of the SR-DB for computation and validation of SR
> > Policies is outside the scope of this document", but it is then mentioned
> > and used in §5.1/§5.2.
>
> KT> The computation algorithm and related discussions about the use of SR-DB
> were asked to be moved out of this standards track document during the WG
> process. Those informational sections were moved into
> draft-filsfils-spring-sr-policy-considerations and kept as a reference in
> this document. The reference in 5.1 and 5.2 is about validation of segments
> and as a result the segment-list and candidate path. The validation of the
> "objective" and constraints of the SR Policy was deemed to be outside the
> scope of the document. There were several discussions on and off-list at the
> IETF meetings in this regard. Perhaps this thread gives a good summary:
> https://mailarchive.ietf.org/arch/msg/spring/W8q3wW0damd4XgG-2cH_qzDeA6E/

It's ok if the SR-DB is out of scope.

§3 does say that "use of the SR-DB for computation and validation of
SR Policies is outside the scope of this document."  But that (using
the DB for validation) is different than leaving validation completely
out of scope.  In fact, the text in §5.1 doesn't leave segment-list
validation (for example) out of scope when it says this:

   The SR Policy headend does not compute the Segment-List.  The SR Policy
   headend only confirms its validity.

Or when it requires the validation explicitly: "A Segment-List of an
explicit candidate path MUST be declared invalid..."


Leaving the validation out of scope may have been what was intended,
but it is not what the document says.  It is also not clear to me
whether the intent was to leave out of scope how to use the DB (as the
text in §3 says), or to completely leave it out.

The thread was not that easy to follow, with most message being about
support.  Can you point me to where the out-of-scope decision was
reached?  Alternatively, the Chairs can confirm.



> > Accordingly, the added details require additional Security and Manageability
> > considerations.
>
> KT> Could you please clarify/explain a bit further what you feel is missing?

For example, for this construct of the SR Policy specified in this
document: "The headend is specified as an IPv4 or IPv6 address and is
expected to be unique in the domain." (§2.1)

What new security and/or manageability considerations does it
introduce?  Can there be a mixture of IPv4 and IPv6 addresses
identifying headends/endpoints?  What happens if there are duplicate
identifiers?  How can it be detected?  Can a rogue node intercept (or
perhaps attract) the traffic of an SR Policy if it advertises one of
these addresses?  ...

Some of the answers may be "nothing", or the issues may be carried
over from rfc8402 -- in those cases, please at least point that out.



...
> > (2) §5.1:
> >
> > Types A or B MUST be used for the SIDs for which the reachability
> > cannot be verified. Note that the first SID MUST always be reachable
> > regardless of its type.
> >
> > These two requirements and the text in the description of these types
> > ("...does not require the headend to perform SID resolution.") results in a
> > contradiction: Types A and B are not to be resolved, but if they are the
> > first SID then they MUST. If it's not a contradiction, then Types A and B
> > would not be allowed to be the first SID, which is not correct because the
> > most straightforward mechanism to define a path is to list SR-MPLS Labels
> > or SRv6 SIDs.
>
> KT> I don't see a contradiction here. "Types A or B MUST be used for the SIDs
> for which the reachability cannot be verified." is not the same as saying
> "Type A or B are not to be resolved".

True.  However, the description of both types say that "This 

[spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT)

[Alvaro Retana via Datatracker]

Alvaro Retana has entered the following ballot position for
draft-ietf-spring-segment-routing-policy-17: Discuss

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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/



--
DISCUSS:
--

(1) This specification should formally Update rfc8402.

What is the relationship between this document and rfc8402?  If this document
details the concept introduced in rfc8402, why isn't there a formal Update
relationship?

Even the initial definition of SR Policy in this document (§2) doesn't match
what rfc8402 says.  This document defines it as "a framework that enables the
instantiation of an ordered list of segments", while rfc8402 states it is "an
ordered list of segments."  In §2.2, this document uses the term
"segment-list" for that.

Besides the general topic of clarifying and updating what an SR Policy is, this
document also includes other items that were not present in rfc8402; the list
includes:

   §2.1: "SR Policy MUST be identified through the tuple ."   There's not even a mention of "color" in rfc8402.

   §2.1: "The headend is specified as an IPv4 or IPv6 address and is expected
   to be unique in the domain."  Neither the mechanism to identify a node nor
   the expectation is present in rfc8402.

   §2.1: "The endpoint is specified as an IPv4 or IPv6 address and is expected
   to be unique in the domain."   Same as above.


The SR Database is a new element not in the base architecture.  The text in §3
says that "use of the SR-DB for computation and validation of SR Policies is
outside the scope of this document", but it is then mentioned and used in
§5.1/§5.2.


Accordingly, the added details require additional Security and Manageability
considerations.


I couldn't find a related discussion in the archive.  If I missed it, please
point me in the right direction.



(2) §5.1:

   Types A or B MUST be used for the SIDs for which the reachability
   cannot be verified.  Note that the first SID MUST always be reachable
   regardless of its type.

These two requirements and the text in the description of these types ("...does
not require the headend to perform SID resolution.") results in a
contradiction: Types A and B are not to be resolved, but if they are the first
SID then they MUST.  If it's not a contradiction, then Types A and B would not
be allowed to be the first SID, which is not correct because the most
straightforward mechanism to define a path is to list SR-MPLS Labels or SRv6
SIDs.


--
COMMENT:
--

(0) I support John's DISCUSS.


(1) Is the specification of a headend/endpoint mandatory?  IOW, should the text
in §2.1 about the headend/endpoint being identified by a unique IPv4 or IPv6
address be normative?


(2) §2.1: "An implementation MAY allow the assignment of a symbolic name
comprising of printable ASCII [RFC0020] [RFC5234] characters"

Why are you normatively limiting the name to be represented in ASCII?  Please
internationalize it - use UTF-8.

§2.6 also has similar text.


(3) §2.1: "Such symbolic names MAY identify an SR Policy when the naming scheme
ensures uniqueness."  In this case, the "MAY" is just stating a fact.
s/MAY/may


(4) §2.1: "An SR Policy MAY have multiple names...in the scenario where the
headend receives different SR Policy names"   Describing multiple names as the
case where multiple names are received is not helpful.


(5) §2.2: "the endpoints of the constituent SR Policies and the parent SR Policy
MUST be identical"  To avoid confusion, by "endpoints" you mean "headend and
endpoint", right?


(6) §2.3:

   A headend MAY be informed about a candidate path for an SR Policy
by various means including...

It seems like the "MAY" is only stating a fact -- if so, then s/MAY/may


(7) §2.4: "When signaling is via PCEP...the AS number SHOULD be set to 0 by
default when not available or known."

When is it ok for the ASN to not be set to 0 (when not available or known)?
If that possibility exists, the PCE can use any value (including the real
number or a random one).  What issues exist with uncoordinated (or rogue) PCEs
using potentially arbitrary ASNs?

Why is this action recommended and not required?


(8) This paragra

Re: [spring] Alvaro Retana's No Objection on draft-ietf-spring-sr-yang-29: (with COMMENT)

[Alvaro Retana]

Hi!

The changes look good to me.

Thanks!

Alvaro.

On January 25, 2021 at 11:50:44 PM, Yingzhen Qu (yingzhen...@futurewei.com)
wrote:

Hi Alvaro,

Thank you for your thorough review and comments. We just published version
-30 to address IESG review comments. Please see detailed answers below
inline.

Please let us know if you have more comments.

Thanks,
Yingzhen

On Jan 20, 2021, at 7:36 AM, Alvaro Retana via Datatracker 
wrote:

Alvaro Retana has entered the following ballot position for
draft-ietf-spring-sr-yang-29: 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.htmldata=04%7C01%7Cyingzhen.qu%40futurewei.com%7Cf34b1809d0074d6584b008d8bd591adb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637467537718756918%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=UzYBQkG%2F7WWwviq2NjV6Ws41jzkK6cHXIbgkGMONDS8%3Dreserved=0
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-sr-yang%2Fdata=04%7C01%7Cyingzhen.qu%40futurewei.com%7Cf34b1809d0074d6584b008d8bd591adb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637467537718756918%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vKOEndcJtpxSOMYmSRfeNPcObJygZiXHl7Eo2gn3M9A%3Dreserved=0



--
COMMENT:
--

(1) I have a significant concern about the incomplete representation of the
MSD in this document.  Even though the model is incomplete, I am not
balloting
DISCUSS because this point should be easy to address.

grouping max-sid-depth {
  description
"Maximum SID Depth (MSD) operational state grouping.";
  leaf node-msd {
type uint8;
description
  "Node MSD is the lowest MSD supported by the node.";
  }
  container link-msds {
description
  "MSD supported by an individual interface.";
list link-msds {
  key "interface";
  description
"List of link MSDs.";
  leaf interface {
type if:interface-ref;
description
  "Reference to device interface.";
  }
  leaf msd {
type uint8;
description
  "MSD supported by the interface.";
  }
}
  }
}


(a) While there is a "type" mentioned, that seems to correspond to the
MSD-Value.  The MSD-Type is not included above.

(b) Note that the MSD is really a pair of MSD-Type/MSD-Value.  The
description
above, even if extended to also include the MSD-Type, seems to allow for a
single pair, where multiple could be advertised per node/link.

(c) The ERLD (entropy-readable-label-depth, for which references should be
included) is advertised in the IGPs using the same mechanism as the MSD:
using
the ERLD-MSD type.  IOW, the separation of the ERLD from the MSD in the
module
is redundant/incorrect.

(d) MSD is a good example of a feature that is common to both the MPLS and
IPv6 dataplanes and should be in the common part of the model, not defined
separately for each.

[Yingzhen]: we had a discussion among the authors, and we decided to remove
the MSD and ERLD status from this SR-MPLS base model.
The consensus is that although MSD and ERLD are related with SR, they’re
not SR specific.

>From RFC 8491:

MSD advertisements MAY be useful even if Segment Routing itself is
not enabled.


We will submit a new YANG module which augments the base MPLS module (RFC
8960) with MSD info.

(2) §3: "Module ietf-segment-routing-common defines generic types and
groupings that SHOULD be reused by IGP extension modules."  The SHOULD is
out
place because the module is either supported or not, if it isn't then there
is
no effect on interoperability because the IGP extension module presumably
chose a different option.  s/that SHOULD/to

[Yingzhen]: fixed.

(3) §3: There should be a representation of the ietf-segment-routing-common
module in this section.

[Yingzhen]: I suppose you mean YANG tree diagram here.
ietf-segment-routing-common module only has definitions,
identities and groupings, and typically we don’t generate separate trees
for groupings. Their trees are shown in places
where groupings are being used.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] Alvaro Retana's No Objection on draft-ietf-spring-sr-yang-29: (with COMMENT)

[Alvaro Retana via Datatracker]

Alvaro Retana has entered the following ballot position for
draft-ietf-spring-sr-yang-29: 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-spring-sr-yang/



--
COMMENT:
--

(1) I have a significant concern about the incomplete representation of the
MSD in this document.  Even though the model is incomplete, I am not balloting
DISCUSS because this point should be easy to address.

 grouping max-sid-depth {
   description
 "Maximum SID Depth (MSD) operational state grouping.";
   leaf node-msd {
 type uint8;
 description
   "Node MSD is the lowest MSD supported by the node.";
   }
   container link-msds {
 description
   "MSD supported by an individual interface.";
 list link-msds {
   key "interface";
   description
 "List of link MSDs.";
   leaf interface {
 type if:interface-ref;
 description
   "Reference to device interface.";
   }
   leaf msd {
 type uint8;
 description
   "MSD supported by the interface.";
   }
 }
   }
 }


(a) While there is a "type" mentioned, that seems to correspond to the
MSD-Value.  The MSD-Type is not included above.

(b) Note that the MSD is really a pair of MSD-Type/MSD-Value.  The description
above, even if extended to also include the MSD-Type, seems to allow for a
single pair, where multiple could be advertised per node/link.

(c) The ERLD (entropy-readable-label-depth, for which references should be
included) is advertised in the IGPs using the same mechanism as the MSD: using
the ERLD-MSD type.  IOW, the separation of the ERLD from the MSD in the module
is redundant/incorrect.

(d) MSD is a good example of a feature that is common to both the MPLS and
IPv6 dataplanes and should be in the common part of the model, not defined
separately for each.

(2) §3: "Module ietf-segment-routing-common defines generic types and
groupings that SHOULD be reused by IGP extension modules."  The SHOULD is out
place because the module is either supported or not, if it isn't then there is
no effect on interoperability because the IGP extension module presumably
chose a different option.  s/that SHOULD/to

(3) §3: There should be a representation of the ietf-segment-routing-common
module in this section.



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

Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

[Alvaro Retana]

Thanks Pablo!

I’m clearing my DISCUSS.

Alvaro.

On October 7, 2020 at 12:08:27 PM, Pablo Camarillo (pcamaril) (
pcama...@cisco.com) wrote:

Note that we have just posted rev24 as per the comments below.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

[Alvaro Retana]

On September 30, 2020 at 9:18:37 AM, Pablo Camarillo wrote:


Pablo:

Hi!

Just leaving below the points I still want to talk about.

Thanks!

Alvaro.


...
> > --
> > DISCUSS:
> > --
...
> > (1b) It would be nice if the behavior in §4.1.1 were also specified
> > using pseudocode...
...
> §4.1.1 is called from different places, while processing different
> behaviors. Is it expected that the "local configuration" will cover each
> behavior individually, or will the operator be able to configure a single
> policy for all? In either case, it would be good to mention it.
>
[PC2] In the document we've left 'local configuration' up to an
[PC2] implementation. Whether an implementation implements the local
[PC2] configuration on an interface as an ACL or globally for all SIDs or per
[PC2] SID via some API is not for this document to decide, and has no impact
[PC2] on interoperability.

True, it has no impact on interoperability, but it can have an impact
on the operation of the network.  While not including details about
local configuration, I would like to see some guidance on the
definition of proper policies.  For example, considering your example
of allowing ICMPv6, OAM may be important, but forwarding a packet that
is not in line with the behavior would not be.

Along those lines, the headend policy should be consistent with the
behavior and any local configuration.  This expectation should also be
mentioned somewhere.


...
> > (3) The description of the flavors in §4.16 is also unclear.
> ...
> For an endpoint behavior that indicates more than one flavor, which one
> should be applied?
>
> For some of the behaviors, 29 (End with PSP) for example, the flavor
> used seems to depend on the number of SLs: if received with SL == 0, then
> the flavor is USD, but if received with SL == 1 then use PSP. But for other
> behaviors, 30 (End with USP) for example, which flavor should be applied
> if both are supported?
>
[PC2] When a behavior (e.g. End) is combined with one or more flavors (e.g.
[PC2] USP & USD), their combined pseudocode is what determines the packet
[PC2] processing. In the specific example of USP (when SL=0), the
[PC2] pseudocode would end up first removing the processed SRH and then,
[PC2] depending on the next upper-layer header, also removing the outer IPv6
[PC2] encapsulation header if/when there is an inner IP packet.

Oh, it's the combination; that is not mentioned anywhere.

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

Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

[Alvaro Retana]

On September 25, 2020 at 2:28:53 PM, Pablo Camarillo wrote:


Pablo:

Hi!

I still have a couple of comments related to the DISCUSS portion.  And
some non-blocking comments later on.

I looked at -22.

Thanks!

Alvaro.


> --
> DISCUSS:
> --

I think we need some more discussion on 1c, 3b, 3d.

3e-3g can be resolved with a more text on the expected types of use
cases.  See more below.


...
> (1b) It would be nice if the behavior in §4.1.1 were also specified using
> pseudocode. As written, I am not sure if the intent is to process any
> upper-layer header or only specific ones. Is the objective for this
> operation to be similar to the one in §4.3.1.2/rfc8754? Please be specific
> on what is meant by "allowed by local configuration".
>
[PC] Yes, we can structure the text in 4.1.1 in pseudocode form. The
[PC] processing is not the same as RFC8754/Section 4.3.1.2. The “allowed by
[PC] local configuration” is to enable the processing of only specific types
[PC] of Upper-layer Headers for packets addressed to an SRv6 SID of the
[PC] specific behaviors. E.g. An operator may not wish to have BGP sessions
[PC] (or in general any TCP traffic) destined to a local SID, but may want to
[PC] enable ICMPv6 packet processing for OAM purposes.
...

§4.1.1 is called from different places, while processing different
behaviors.  Is it expected that the "local configuration" will cover
each behavior individually, or will the operator be able to configure
a single policy for all?  In either case, it would be good to mention
it.



...
> (1c) §4.4/§4.6: S01 of the second piece of pseudocode is an instruction for
> processing a non-IPv6 upper header. However, earlier in that section, it is
> specified that the SID "is associated with one or more L3 IPv6
> adjacencies/an IPv6 FIB table". How can the upper header not be IPv6 if the
> specification explicitly says it has to be?
>
[PC] The pseudocode is convoluted. I propose to turn it around for 4.4, 4.5,
[PC] 4.6 and 4.7. As an example with 4.4:
...

I still have the same question.  For example, in §4.4/End.DX6, I don't
understand under which conditions the upper-layer won't be IPv6.

The behavior in §4.1.1 now starts by saying: "Upper-Layer Header type
is allowed by local configuration".  Same question: For example, for
End.DX6, when would something other than IPv6 be allowed by local
configuration?

It seems to me that if the behavior "is associated with one or more L3
IPv6 adjacencies", then the contents should either be IPv6 or be
discarded. Otherwise the sender may include something else (IPv4, for
example) and it may be forwarded...

I may be missing something obvious, I just don't know what.

[Similar concerns for other sections where the payload is sent to
§4.1.1 if the contents don't match what the behavior expects.]



...
> (3) The description of the flavors in §4.16 is also unclear.
...
> (3b) If a behavior with more than one flavor is signaled, how should the
> receiving node determine which one to apply? I guess that the application of
> behaviors 4 or 29 depends on the number of SLs -- the expected behavior
> should be clearly specified.
>
[PC] The segment endpoint node receiving a packet destined to a SID with
[PC] behavior 4 applies only the processing associated with the SID (I.e.
[PC] behavior 4).

Sorry, I mixed up some of the terminology.  Let me try this one again.

For an endpoint behavior that indicates more than one flavor, which
one should be applied?

For some of the behaviors, 29 (End with PSP) for example, the
flavor used seems to depend on the number of SLs: if received with SL
== 0, then the flavor is USD, but if received with SL == 1 then use
PSP.  But for other behaviors, 30 (End with USP) for example,
which flavor should be applied if both are supported?



...
> (3d) §4.16.1.2:
>
> When a SID of PSP-flavor is processed at a non-penultimate SR Segment
> Endpoint Node, the PSP behavior is not performed as described in the
> pseudocode below since Segments Left would not be zero.
>
> For example, for the End behavior, I'm assuming that behavior 1 is performed
> instead of 2 (or 4, or 29, or 31) if SL != 0. Should this be done even if
> the node did not advertise the non-PSP flavor?
>
[PC] If a SID of END behavior (1) is instantiated at a segment endpoint node,
[PC] a packet destined to that SID will only ever be processed with behavior
[PC] 1.

Redo:  If the SID used indicates behavior 2 (End with PSP), but the
node is the last one (not the penultimate one), then what should it
do?  This result is probably an error from the sender.  Should the
receiver drop the packet, or process as behavior 1?   Assuming that
the node instantiated SIDs for both behaviors.



...
> (3e) §4.16.2 describes the USP flavor, which is one where the endpoint
> consumes the packet by processing the next header. I don't understand how
> 

[spring] Alvaro Retana's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

[Alvaro Retana via Datatracker]

Alvaro Retana has entered the following ballot position for
draft-ietf-spring-srv6-network-programming-20: Discuss

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-spring-srv6-network-programming/



--
DISCUSS:
--

I am balloting DISCUSS because I find the document unclear and lacking proper
technical details around significant functionality, as reflected in my first 3
points.  The fourth point is related to the registration policy (which doesn't
match the definition in rfc8126), and my last point is for the IESG to consider.

(1) Pseudocode and normative behavior

The use of pseudocode was chosen as the mechanism to specify behavior, as
explained in §4:

   An implementation of the pseudocode is compliant as long as the externally
   observable wire protocol is as described by the pseudocode.

Clarity in the pseudocode is essential because it is used to determine
compliance.  Several places need improvement:

(1a) In §4.1/§4.13/§4.15, the pseudocode is missing an ELSE after S04, to
include the error conditions if SL != 0.  A check for an error condition when
SL is decremented is also needed.  As written, the pseudocode could process the
packet (SL == 0) *and* send an ICMP time exceeded message... :-(

I'm using as a reference the pseudocode in §4.3.1.1/rfc8754, which includes the
same initial statement.

(1b) It would be nice if the behavior in §4.1.1 were also specified using
pseudocode.  As written, I am not sure if the intent is to process any
upper-layer header or only specific ones.  Is the objective for this operation
to be similar to the one in §4.3.1.2/rfc8754?  Please be specific on what is
meant by "allowed by local configuration".

[Note: this point by itself is not DISCUSS-worthy, but §4.1.1 is used, for
different reasons, in some of the other items I point to below.  That is why I
include it here.]

(1c) §4.4/§4.6: S01 of the second piece of pseudocode is an instruction for
processing a non-IPv6 upper header.  However, earlier in that section, it is
specified that the SID "is associated with one or more L3 IPv6 adjacencies/an
IPv6 FIB table".  How can the upper header not be IPv6 if the specification
explicitly says it has to be?

(1d) §4.5/§4.7 have the same issue but related to IPv4.

(1e) §4.9 also has the same issue when it specifies that "End.DX2 SID...is
associated with one outgoing interface I", but allows for the processing of
non-ethernet payloads which could then be forwarded through a different
outgoing interface.

(1f) §4.11/§4.12 allows the processing of non-ethernet payloads, which will not
be "associated with an L2 Table T" as described.

(2) §4.12 describes the only behavior that can carry an ARG.  I don't
understand how it works:

  Arg.FE2 is encoded in the SID as an (k*x)-bit value.  These bits
  represent a list of up to k OIFs, each identified with an x-bit
  value.  Values k and x are defined on a per End.DT2M SID basis.  The
  interface identifier 0 indicates an empty entry in the interface
  list.

Let's assume a router has 10 possible OIFs, and the operator uses 4-bit values
to identify them; then, the ARG would take 40 bits of the SID.  Is that how the
math works?

Assuming my interpretation is correct, for 20 OIFs and 5-bit values we would
need 100 bits.  Considering the examples in §3.2, where a /64 is allocated to a
router, this behavior wouldn't have enough bits!  I realize that maybe a better
encoding would be to use a 20-bit field, each representing an interface. 
However, there would still be a limit of < 64 OIFs.  Am I missing something?

I'm trying to ultimately get to the fact that there are limits to this
behavior, but they are not described in the document.  Please clearly explain
any limitations and any possible workaround.

(3) The description of the flavors in §4.16 is also unclear.

The section starts with this introduction:

   The PSP, USP and USD flavors are variants of the End, End.X and End.T
   behaviors.  For each of these behaviors these flavors MAY be
   supported for a SID either individually or in combinations.

By being "variants", I interpret that the behavior is different than what is
specified in §4.1.

(3a) Some of the behaviors, as listed in Table 4, include an indication of the
flavors.  How are the values interpreted?  For example, the Table lists 8
different behaviors related to End:

| 1   | 0x0001 |   End (no PSP, no USP)  |[This.

Re: [spring] Appeal to the IESG re WGLC of draft-ietf-spring-srv6-network-programming

[Alvaro Retana]

On June 3, 2020 at 1:16:48 AM, Fernando Gont wrote:


Fernando:

Hi!  How are you?


...
> Note: I fail to see your analysis regarding technical objection #3: Your
> analysis focuses on RFC8200 (the focus of technical objection #2), but
> doesn't even mention RFC8754 (the relevant RFC for technical objection #3).

In relation to technical point 3, the concern you pointed at [SR-V]
was resolved in draft-ietf-spring-srv6-network-programming-12
[diff11-12] with text suggested by Brian Carpenter [SR-VA] on the same
thread.  Given that the resolution is also related to the
interpretation of RFC 8200 we decided to group the responses.  We
should have mentioned this fact before.


> For the sake of transparency, while I haven't talked to my fellow
> Appellants about your response, I for one plan to Appeal to the IAB to
> resolve this issue. That said, I'd appreciate your response to the
> comments made above.

Except for the clarification above, it is not the intent of the IESG
to reply to your other comments at this time. We have already provided
carefully considered responses to all points raised in your appeal. We
do not believe that continuing the discussion will be conducive to a
faster resolution or lead to a different outcome.


Take care!

Alvaro - for the IESG



[SR-V] https://mailarchive.ietf.org/arch/msg/spring/Xrcclo0s4pnug9upG9rUinYMv1I/

[diff11-12] 
https://www.ietf.org/rfcdiff?url1=draft-ietf-spring-srv6-network-programming-11=draft-ietf-spring-srv6-network-programming-12

[SR-VA] 
https://mailarchive.ietf.org/arch/msg/spring/QVcsNS_XfRA927S3piCJ4SDYY3k/

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

[spring] Automated Disclaimers (RE: Request to close…)

[Alvaro Retana]

On March 2, 2020 at 1:21:25 PM, S Moonesamy wrote:

[Changed the subject to better reflect the topic and for easier tracking.]


SM:

Hi!  How are you?

> I sent a message to the SPRING Working Group Chairs. The reply which
> I received from a person who is listed as one of the SPRING Working
> Group Chairs contains the following footer:
>
> "This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the
> sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that
> have been modified, changed or falsified."
>
> From what I understand, the IESG position on automated disclaimers
> was that they are not applicable within the context of BCP 9. Was
> there a change to that?

I looked at BCP 9, but didn't find anything related to your question.
If I missed it, please point me in the right direction.  I think you
may be referring to BCP 78.

Specifically, rfc5378 (Rights Contributors Provide to the IETF Trust) reads:

   5.2.  Confidentiality Obligations

   No information or document that is subject to any requirement of
   confidentiality or any restriction on its dissemination may be
   submitted as a Contribution or otherwise considered in any part of
   the IETF Standards Process, and there must be no assumption of any
   confidentiality obligation with respect to any Contribution.  Each
   Contributor agrees that any statement in a Contribution, whether
   generated automatically or otherwise, that states or implies that the
   Contribution is confidential or subject to any privilege, can be
   disregarded for all purposes, and will be of no force or effect.


Note that this section is clearly only talking about statements in a
Contribution (I pasted the definition of "Contribution" below, from
the same RFC).

If you have other general questions or concerns about this topic, it
might be more productive to separate them into their own thread.

Regards,

Alvaro.



>From rfc5378/§1:

a. "Contribution": any submission to the IETF intended by the
   Contributor for publication as all or part of an Internet-Draft or
   RFC (except for RFC Editor Contributions described in Section 4
   below) and any statement made within the context of an IETF
   activity.  Such statements include oral statements in IETF
   sessions as well as written and electronic communications, made at
   any time or place, that are addressed to:

   o the IETF plenary session,
   o any IETF working group or portion thereof,
   o any Birds of a Feather (BOF) session,
   o the IESG, or any member thereof on behalf of the IESG,
   o the IAB, or any member thereof on behalf of the IAB,
   o any IETF mailing list, including the IETF list itself, any
     working group or design team list, or any other list functioning
     under IETF auspices,
   o the RFC Editor or the Internet-Drafts function (except for RFC
     Editor Contributions, as described in Section 4 below).

   Statements made outside of an IETF session, mailing list, or other
   function, that are clearly not intended to be input to an IETF
   activity, group, or function are not IETF Contributions in the
   context of this document.

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

Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-exten

[Alvaro Retana]

On April 10, 2019 at 5:46:56 PM, Vigoureux, Martin (Nokia -
FR/Paris-Saclay) (martin.vigour...@nokia.com) wrote:

Martin:

Hi!

It looks to me that you don’t disagree with what is written in the draft
but rather with the fact that the draft may suggest that IGPs should do
things which are in fact not specified in the IGPs drafts. I think this
point covers 1.1 to 1.4

Assuming that I’m correct, I believe that in order to clear the
misunderstanding authors could simply remove the sentence: “IGPs with SR
extensions...are examples of MCCs.”.

…and probably clean up some other text, for example, §2.10.1
references I-D.ietf-isis-segment-routing-extensions specifically.

Bottom line, I think you’re right.

On 1.5. I don’t think there is a conflict. It does not contradict 8402. It
is not saying “An IGP Node-SID SHOULD NOT be associated with a prefix …”

The way I see it is that this is a belt and suspenders approach. The base
req says MUST NOT and this req says “check if this req is respected”.

I read this document as saying “check, but you may have reasons not to”…
 IMHO, there’s no reason to specify the behavior here again, if it’s
already specified in rfc8402.

Of course this is only my view. I expect authors to have their own.

I’m sure they will. ;-)

Thanks!

Alvaro.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] Fwd: Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-exte

[Alvaro Retana]

Hi!

I just entered a DISCUSS position related
to draft-ietf-spring-segment-routing-mpls (see below).  I believe that the
issue needs to be solved in conjunction with the IGP extension drafts, so
I’m copying the authors/shepherds/chairs here.

Thanks!

Alvaro.

On April 10, 2019 at 4:25:22 PM, Alvaro Retana via Datatracker (
nore...@ietf.org) wrote:

--
DISCUSS:
--

(1) This first point is a cross-document DISCUSS. In short, the assumptions
in
this document about what an MCC is responsible for are not in line with the
corresponding IGP drafts for OSPF [1][2] and IS-IS [3]. This misalignment
must
be resolved before any of these documents are published.

[Note: I'll start a thread with the corresponding WGS, Authors, Shepherds,
Chairs and ADs. Let's please discuss this point there.]

This document uses the following definition in §2: "We call "MPLS Control
Plane
Client (MCC)" any control plane entity installing forwarding entries in the
MPLS data plane. IGPs with SR extensions...are examples of MCCs."

The focus of the IGP drafts is on the transport of the SR information, and
not
on other functions (see below). Which component is responsible for what is
the
point that needs clarification -- either in this document, the IGP drafts,
or
both.

These are some specific cases:

(1.1) §2.4 (Mapping a SID Index to an MPLS label): "The following rules
MUST be
applied by the MCC when calculating the MPLS label value corresponding the
SID
index value "I"." There's nothing in the IGP extension documents that point
at
this set of rules, and only a passing reference in the OSPF documents about
outgoing labels.

(1.2) §2.5 (Incoming Label Collision) also assumes more functions from an
MCC
than what the IGP documents do. For example: "Within an MCC, apply
tie-breaking rules to select one FEC only and assign the label to it."

(1.3) §2.8 also expects work by the IGPs: "the MCC is responsible for
downloading the correct label value to FIB"...in this case not just
calculating
the label, but installing it in the FIB.

(1.4) §2.10.1: "The method by which the MCC on router "R0" determines that
PUSH
or CONTINUE operation must be applied using the SID "Si" is beyond the
scope of
this document. An example of a method to determine the SID "Si" for PUSH
operation is the case where IS-IS
[I-D.ietf-isis-segment-routing-extensions]..." Note that the IS-IS draft (or

the OSPF ones, for that matter) don't talk about how to determine the
operation
-- if that is out of scope of this document, then where is it specified?

(1.5) From §2:

An implementation SHOULD check that an IGP node-SID is not associated
with a prefix that is owned by more than one router within the same
routing domain. If so, it SHOULD NOT use this Node-SID, MAY use
another one if available, and SHOULD log an error.

rfc8402 reads (§3.2): "An IGP Node-SID MUST NOT be associated with a prefix
that is owned by more than one router within the same routing domain." The
text above is not in line with that (MUST NOT vs SHOULD). Also, how can
"SHOULD check" be Normatively enforced?

Both sentences above seem to be trying to specify a behavior for the IGPs.

[1] https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions
[2]
https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions

[3] https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT)

[Alvaro Retana via Datatracker]

Alvaro Retana has entered the following ballot position for
draft-ietf-spring-segment-routing-mpls-19: Discuss

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-spring-segment-routing-mpls/



--
DISCUSS:
--

(1) This first point is a cross-document DISCUSS.  In short, the assumptions in
this document about what an MCC is responsible for are not in line with the
corresponding IGP drafts for OSPF [1][2] and IS-IS [3].  This misalignment must
be resolved before any of these documents are published.

[Note: I'll start a thread with the corresponding WGS, Authors, Shepherds,
Chairs and ADs.  Let's please discuss this point there.]

This document uses the following definition in §2: "We call "MPLS Control Plane
Client (MCC)" any control plane entity installing forwarding entries in the
MPLS data plane.  IGPs with SR extensions...are examples of MCCs."

The focus of the IGP drafts is on the transport of the SR information, and not
on other functions (see below).  Which component is responsible for what is the
point that needs clarification -- either in this document, the IGP drafts, or
both.

These are some specific cases:

(1.1) §2.4 (Mapping a SID Index to an MPLS label): "The following rules MUST be
applied by the MCC when calculating the MPLS label value corresponding the SID
index value "I"."  There's nothing in the IGP extension documents that point at
this set of rules, and only a passing reference in the OSPF documents about
outgoing labels.

(1.2) §2.5 (Incoming Label Collision) also assumes more functions from an MCC
than what the IGP documents do.  For example: "Within an MCC, apply
tie-breaking rules to select one FEC only and assign the label to it."

(1.3) §2.8 also expects work by the IGPs: "the MCC is responsible for
downloading the correct label value to FIB"...in this case not just calculating
the label, but installing it in the FIB.

(1.4) §2.10.1: "The method by which the MCC on router "R0" determines that PUSH
or CONTINUE operation must be applied using the SID "Si" is beyond the scope of
this document. An example of a method to determine the SID "Si" for PUSH
operation is the case where IS-IS
[I-D.ietf-isis-segment-routing-extensions]..." Note that the IS-IS draft (or
the OSPF ones, for that matter) don't talk about how to determine the operation
-- if that is out of scope of this document, then where is it specified?

(1.5) From §2:

   An implementation SHOULD check that an IGP node-SID is not associated
   with a prefix that is owned by more than one router within the same
   routing domain. If so, it SHOULD NOT use this Node-SID, MAY use
   another one if available, and SHOULD log an error.

rfc8402 reads (§3.2): "An IGP Node-SID MUST NOT be associated with a prefix
that is owned by more than one router within the same routing domain."  The
text above is not in line with that (MUST NOT vs SHOULD).  Also, how can
"SHOULD check" be Normatively enforced?

Both sentences above seem to be trying to specify a behavior for the IGPs.

[1] https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions
[2]
https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions
[3] https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions

(2) §2.5.1: According to §2.5, a "tie-breaking rule MUST be deterministic". 
However, the specification of the default rules are not: the first step uses
the administrative distance, but the specification says that "the FEC types are
ordered using the default administrative distance ordering defined by the
implementation"...and later that the "user SHOULD ensure that the same
administrative distance preference is used on all routers".  The combination of
different implementations and the lack of an absolute requirement to ensure
consistency can easily be non-deterministic.

This point is related to the text in §2.6 which talks about how "the ingress
node MUST resolve" collisions the same way.  Because of the lack of an absolute
requirement for consistency, this "MUST" doesn't guarantee the same result.

Also related is this text in §2.5.1: "All routers in a routing domain SHOULD
use the same tie-breaking rules to maximize forwarding consistency."  When
would all routers not use the same rules?  It seems to me that forwarding
consistency is

Re: [spring] Last Call: (BGP-LS extensions for Segment Routing BGP Egress Peer Engineering) to Proposed Standard

[Alvaro Retana]

FYI...

On April 3, 2019 at 12:30:39 PM, The IESG (iesg-secret...@ietf.org) wrote:


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'BGP-LS extensions for Segment Routing
BGP
Egress Peer Engineering'
 as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2019-04-17. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning
of
the Subject line to allow automated sorting.

Abstract


Segment Routing (SR) leverages source routing. A node steers a
packet through a controlled set of instructions, called segments, by
prepending the packet with an SR header. A segment can represent any
instruction, topological or service-based. SR segments allow
steering a flow through any topological path and service chain while
maintaining per-flow state only at the ingress node of the SR domain.

This document describes an extension to BGP Link State (BGP-LS) for
advertisement of BGP Peering Segments along with their BGP peering
node information so that efficient BGP Egress Peer Engineering (EPE)
policies and strategies can be computed based on Segment Routing.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ballot/

The following IPR Declarations may be related to this I-D:

https://datatracker.ietf.org/ipr/2721/
https://datatracker.ietf.org/ipr/2611/
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Error Handling for BGP-LS with Segment Routing

[Alvaro Retana]

On January 8, 2019 at 9:33:49 AM, bruno.decra...@orange.com (
bruno.decra...@orange.com) wrote:

Bruno:

Hi!



But I’m wondering why error handling is that specific to BGP-LS.

It is just in this thread...

Why is that point not been raised on, let’s say,
draft-ietf-ospf-ospfv3-segment-routing-extensions which is currently under
IESG review? I can see that the specific are (a bit) different, but the big
picture seems the same: the information is incomplete, how do we handle
this?

[AD Note:  draft-ietf-ospf-ospfv3-segment-routing-extensions is pending a
new revision to clear an outstanding DISCUSS.  If you (or anyone) has
specific issues about this document, please let me know as I’m ready to
approve the publication.]

I didn’t specifically raise the question of error handling for BGP-LS with
SR against the current document I’m reviewing
(draft-ietf-idr-bgp-ls-segment-routing-ext) because I don’t think the
solution explicitly belongs there…so I started the discussion on the
idr/spring lists.  If there are issues with the OSPFv3 transport then the
solution probably doesn’t belong in the extensions draft.

[This part of the discussion belongs on a different list…] I think that the
link state protocols have different characteristics (than BGP-LS) when it
comes to try to ensure common information between the nodes: reliability at
the LSA/LSP level, db synchronization, etc..  That difference brought me to
not bring up the question of incomplete information when I was reviewing
the SR extension drafts.  I may of course be missing an important piece.
If this point needs to be discussed, we should move to lsr.

Then, I’m not sure that the problem is specific/limited to SR/SID
information.

Right.

I think it’s easier to discuss specific problems first and then
generalize…than start with the general problem.  That is one of the reasons
for this thread.  In the specific case of BGP-LS, rfc7752 makes assumptions
about  about the nature of the information, which I think are broken with
SR…. I think there’s an SR-specific issue that needs to be addressed
somewhere.

As you mentioned before, other applications, like lsvr, could have the same
issues.

Thanks!

Alvaro.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Error Handling for BGP-LS with Segment Routing

[Alvaro Retana]

On January 4, 2019 at 3:48:38 PM, Rob Shakir (ro...@google.com) wrote:

The alternative approach is to have an "Operational Considerations" section
of draft-ietf-idr-bgp-ls-segment-routing-ext that simply points out this
consideration. i.e., something like:

We would need something like it in every bgp-ls-sr draft…or a pointer back
to draft-ietf-idr-bgp-ls-segment-routing-ext...

"Since the error handling approach defined in RFC7752 specifies 'attribute
discard' as the error handling mechanism for BGP-LS, systems implemented
using BGP-LS for discovery of topological attributes used for path
calculation MUST consider their mode of operation based on incomplete data
being received (due to attribute discard). If an assumption of strong
consistency between the BGP-LS receiver, and the network's topology is
made, system designers and operators SHOULD consider means to detect
erroneous attributes being discarded on a session and act accordingly."


Taking this approach doesn't say "hey, let's change this", and also doesn't
say "here's what the system should do", it just makes sure designers and
operators are aware of the consideration. That said, this is rather
implementation specific.


[This is probably not the right place to wordsmith, but I don’t know how
“MUST/SHOULD consider” can be normatively enforced.]

Because it is implementation/deployment specific, some examples of the
cases where there could be more (or less) potential issues would be ideal.
As Robert’s example: "In my view SR controller is mainly used as
optimization not as critical element - well at least in the deployment
models I would personally recommend to use.”

This last part could end up making the document significantly longer…and it
doesn’t really give me a warm fuzzy feeling adding it after WGLC…to an idr
document...and without it being properly reviewed by the spring WG.  But
these are details we can take care of as we move forward [*].

Thanks!

Alvaro.

[*] I haven’t finished my AD Review
of draft-ietf-idr-bgp-ls-segment-routing-ext.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Error Handling for BGP-LS with Segment Routing

[Alvaro Retana]

On January 3, 2019 at 5:40:23 PM, Rob Shakir (ro...@google.com) wrote:

Describing these compromises is, of course, a good idea. However, it's not
clear where this description would go -- we don't really have a document
that describes this overall system and how it might be implemented today
.


Right…

I started reviewing the documents with BGP-LS extensions for SR…starting
with draft-ietf-idr-bgp-ls-segment-routing-ext, which is the first BGP-LS
extensions document to be sent for Publication where the application is
explicitly to "construct the end-to-end path (with its associated SIDs)
that need to be applied to an incoming packet to achieve the desired
end-to-end forwarding”.  All other BGP-LS extension documents have in
general followed the “informative” tone of rfc7752.

I don’t necessarily think that the description of the system belongs
there…but there’s no other place to put it, at least not currently.  The SR
Problem Statement (rfc7855) and the SR Architecture (rfc8402) both just
make general statements about the need to support centralized and hybrid
(and distributed, of course) control planes — they don’t go into more
specifics…

…

Alvaro.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Error Handling for BGP-LS with Segment Routing

[Alvaro Retana]

Rob:

Hi!

I don’t think I said it before:  speaking as a WG participant...

I want to pick up on a point you make below, which I agree with: "any
topology discovery mechanism (whether used in real-time or not) needs to
define how it handles cases where it might end up with missing
information”….

BGP-LS only defines a mechanism through which it may miss information, but
not how to handle it — or maybe it does (?): by using attribute discard it
just accepts that the information might be missing going forward…and
doesn’t attempt to do anything.  Maybe this quote is true: "Doing Nothing
Often Leads to the Very Best Something” — Winnie the Pooh

That action may be ok in the general case…but I think that doing nothing
may not be enough/appropriate for an application like SR, because it is
explicitly calculating paths….


The point I’m trying to bring up is not necessarily treat-as-withdraw vs.
attribute discard…. But, first, is attribute discard
enough/appropriate/good for a BGP-LS application such as SR?  If it isn’t,
second, is there a different approach that would be better?  Maybe we then
come to a point where something can change…or accept the limitations of the
system and be clear about them.  I fully realize that I may be the only one
who thinks there’s an issue…

Thanks!!

Alvaro.


On December 21, 2018 at 11:23:16 AM, Rob Shakir (ro...@google.com) wrote:

Alvaro,

I think this is one of the difficulties of overloading a protocol like BGP
with different datasets -- it's not simple to say how particular attributes
are actually going to be used within a protocol deployment. This was one of
the things that was noted in 7606 -- i.e., I can make *any* attribute
really affect forwarding if I write a policy that accepts/rejects some
UPDATE based on the presence of that attribute.

In general, any topology discovery mechanism (whether used in real-time or
not) needs to define how it handles cases where it might end up with
missing information. Let's consider what the different mechanisms for
discovery we have are today:

   - IGP listening -- in this case, if we have some malformed IS-IS TLV,
   then we might end up discarding this information (whether it be at the
   listening node, or a device that didn't flood it earlier in the chain) --
   meaning that we know that we have some potential gap in the topology.
   - Streaming telemetry -- speaking particularly to gNMI for LSDB
   streaming encoded using the OpenConfig model, here, we are tolerant to
   getting as much information as can be parsed, and have a way to carry
   unknown TLVs (which might include those that cannot be successfully parsed)
   as binary data to the external consumer. This means that the approach is
   "as complete data as possible", but has the same characteristic that we can
   also end up having the potential to lose data.
   - BGP-LS with attribute discard -- this has some information loss, since
   we'll have some attributes that could be malformed in the input data, and
   we discard them at the receiver.

It doesn't seem to me that, given the source of the data is the IGP, and we
might have information discarded there -- that we can really guarantee
strong consistency of an off-box view of the network, since we can't
guarantee strong consistency across the IGP domain itself.

Thus, I'm not sure that the issue that is being highlighted here actually
makes a difference when we're considering the overall system design -- we
always need to deal with the fact that the view of the network at the path
computing node might not match exactly the network's current state in the
presence of malformed protocol messages. One motivation for having the LSDB
via streaming telemetry is the ability to provide such validation ("do all
nodes within my IGP domain, including listeners, have a consistent view of
the state of the network?").

If the discussion is "should we adopt treat-as-withdraw vs. attribute
discard?" -- I don't think that from the system perspective there is really
any difference between the two in this situation. We still have the same
potentially inconsistent view of the network.

For these reasons, I'd err on leaving this unchanged in the current
specification(s).

Cheers,
r.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Error Handling for BGP-LS with Segment Routing

[Alvaro Retana]

On December 18, 2018 at 6:23:19 PM, Robert Raszuk (rras...@gmail.com) wrote:

Robert:

Hi!

What comes as #1 question to your points is a comparison of SR controller
with regular BGP RR.

I think it is safe to assume that error handling on SR controller would be
no more aggressive then on RRs. So if there is error the updates may be
dropped on the RRs itself, logged and proper NOC alarm generated.

IMO this is no different regardless if you use SR with BGP-LS or just plane
regular BGP routing.

In general, I agree that error handling should be the same regardless of
the type of BGP speaker (RR, controller, PE, whatever).

So unless your goal here is to point out the deficiency of BGP error
handling RFC I am not sure what is so specific to BGP-LS and SR.

No, the goal is not to point at any deficiency in the error handling RFC.
I just replied to Bruno saying: " I don’t want to rehash the discussion
from rfc7606 about the types of approached and whether there should be more
or not (or what those could be)…. I’m just pointing out that I think the
current approach is not the right one for all applications.”

When BGP-LS was defined, it was noted that the "information present in this
document carries purely application-level data that has no immediate
corresponding forwarding state impact.”  I think that SR has a direct
impact on the forwarding state of the network.  That is what is specific
about BGP-LS+SR.


To be clear, this thread is about using BGP-LS with applications that have
an impact on forwarding/route selection in the network, like SR (Bruno
pointed at lsvr and there may be others).  It is not about about the error
handling approaches (rfc7606) or BGP sessions in general…just that specific
application.

Thanks for helping me clarify what I mean.  Hopefully this makes more
sense. ;-)

Alvaro.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Error Handling for BGP-LS with Segment Routing

[Alvaro Retana]

On December 18, 2018 at 6:10:21 PM, bruno.decra...@orange.com (
bruno.decra...@orange.com) wrote:

Bruno:

Hi!




1) shouldn’t BGP-LS error handling be also discussed in the LSVR WG?

https://tools.ietf.org/html/draft-ietf-lsvr-bgp-spf-03#section-5.7 does not
seem to cover this.

And this document was under WGLC till yesterday.

Yes, good point.

I wanted to focus on SR’s use, but I think you’re right to point out that
other applications may have the same needs.  I think/hope that people on
the lsvr list are also on the idr list (at least), so I’ll forward a
pointer to this thread just in case.


2) Regarding BGP-LS error handling, it’s not clear to me that “treat as
withdraw” would be “safer” than “Attribute Discard”. “Session reset” is
safer from an inconsistency standpoint but definitely also “has a direct
effect on how traffic is forwarded in the network” and a sever one.

[Not sure about the ending “…and a sever one”.]

I agree.  I don’t want to rehash the discussion from rfc7606 about the
types of approached and whether there should be more or not (or what those
could be)…. I’m just pointing out that I think the current approach is not
the right one for all applications.

3)

> The BGP-LS extensions for SR (e.g.
draft-ietf-idr-bgp-ls-segment-routing-ext) are, as explained in that draft,
used so that "an external component (e.g., a controller) then can collect
SR information from across an SR domain and construct the end-to-end path
(with its associated SIDs) that need to be applied to an incoming packet to
achieve the desired end-to-end forwarding."



> To me, that obviously implies that use of BGP-LS for SR has a direct
effect on how traffic is forwarded in the network.  Does any one see it
differently?



a) IMHO that implication would be the same without SR, e.g., with RSVP-TE.
In fact, the effect on how traffic is forwarded is coming from the PCE
computation using partial/incorrect topology information, not how the
forwarding is enforced.

b) IMHO RFC7606 was more concerned about forwarding loops/black holing
–especially for IBGP-, rather than changing the path of the traffic..
(as ““treat as withdraw “ or “sessions reset” would also have “a
direct effect on how traffic is forwarded in the network”.) Note that
the latter quote is not from RFC760 which uses the terms  “no effect
on route selection or installation” which is a bit different.

Interpreting the difference between “a direct effect on how traffic is
forwarded in the network” and  “no effect on route selection or
installation” is part of the reason this topic is not straight forward.

To me, in the BGP-LS+SR context, because the controller *installs* the
source route at the ingress router, the two phrases apply.

However, other interpretations are possible…which is one of the reasons for
this thread.  For example, during the rfc7752 discussion, a point was made
that the controller (being at the receiving end of the BGP session) would
not have to worry about the effects of attribute discard because any loss
of information would not have an effect on how it (the controller) selected
or installed routes.  That argument is not completely flawed (the
controller does not use the BGP-LS itself for routing), but (my personal
opinion) is that the use of the information (in later programming the
network) is what is important.


c) Coming back to SR, quickly looking at the ToC, the discard of the
SID simply means that the SID can”t be used by the SR source/ingress
node. The discard of the SR node attribute means that the node can’t
be used to forward a global segment. The use of flex-algo is a bit
more touchy as discarding the support for a flex algo will change the
routing along this flex algo. But only from the perspective of the
BGP-LS consumer, so this would not create forwarding loops/black hole,
but only a non expected routing path.

Which ToC?

You’re right…but only if the information is discarded when it was initially
learned.  If the error occurs later, when the information was changing for
example, there is the possibility that the controller will want to use a
node that shouldn’t be used any more….or be calculating
not-the-best-routes.  Sub-optimal routes are not great and may not matter
too much (compared to loops, for example), but some users may have specific
business objectives (application performance, for instance) tied to the
definition of the paths…it will be important to them.


4)  I haven’t checked but it’s not clear to me that IS-IS has a perfect
(better?) error handling.

If you want to discuss this, please do it in the lsr WG. :-)



5) BGP-LS and IS-IS have chosen a different granularity to advertise the
LSDB (per link/node vs oer LSP) which very likely will result in a
different error handling hence a different vision of the topology. This
looks like day 1 design choice for BGP-LS, so difficult to address.

Yes…

Thanks!

Alvaro.
___
spring mailing list

[spring] Error Handling for BGP-LS with Segment Routing

[Alvaro Retana]

Dear idr and spring WGs:

tl;dr  I don't think that BGP-LS, with error handling as specified
("attribute discard"), can provide the robustness that an application (like
SR), with direct impact on the forwarding in the network, needs.  [Jump to
the bottom for discussion.]


The BGP-LS extensions for SR (e.g.
draft-ietf-idr-bgp-ls-segment-routing-ext) are, as explained in that draft,
used so that "an external component (e.g., a controller) then can collect
SR information from across an SR domain and construct the end-to-end path
(with its associated SIDs) that need to be applied to an incoming packet to
achieve the desired end-to-end forwarding."

To me, that obviously implies that use of BGP-LS for SR has a direct effect
on how traffic is forwarded in the network.  Does any one see it
differently?


The error handling mechanism specified in rfc7752 is "attribute discard"
[rfc7606].  If an error is detected, then the information in the controller
may be, at best, incomplete, but it could also be out of date...resulting
in "segment routes" that don't follow the best available path or that may
even end in a black hole.

It seems clear to me that this is one of the cases that rfc7606 warned
about:

   o  Attribute discard: In this approach, the malformed attribute MUST
  be discarded and the UPDATE message continues to be processed.
  This approach MUST NOT be used except in the case of an attribute
  that has no effect on route selection or installation.

  ...
   For any malformed attribute that is handled by the "attribute
   discard" instead of the "treat-as-withdraw" approach, it is critical
   to consider the potential impact of doing so.  In particular, if the
   attribute in question has or may have an effect on route selection or
   installation, the presumption is that discarding it is unsafe unless
   careful analysis proves otherwise.  The analysis should take into
   account the tradeoff between preserving connectivity and potential
   side effects.


There was a related discussion as a result of my AD review of
draft-ietf-idr-ls-distribution (= rfc7606) [1][2].  At that time (2015),
the consensus on the list was (paraphrasing): if there's a malformed
attribute we won't be able to recover, but that's ok because BGP-LS is
"purely application-level data that has no immediate corresponding
forwarding state impact", and there won't be an impact on critical AFI/SAFI
for network operations.   No one else argued against that...so I ended up
in the rough...

I think the situation has now changed because BGP-LS is carrying SR
information that is used to define paths in the network -- even if
isolation exists, as described in rfc7752:

 ...Furthermore, it is anticipated that
   distribution of this NLRI will be handled by dedicated route
   reflectors providing a level of isolation and fault containment
   between different NLRI types.

the BGP-LS information could still be incomplete, stale, etc..


After all that...  I don't think that BGP-LS, with error handling as
specified ("attribute discard"), can provide the robustness that an
application (like SR), with direct impact on the forwarding in the network,
needs.

What now?  I see several potential paths forward (there are probably more):

(1) "fix" BGP-LS to mandate (MUST) isolation and change the error handling
approach

(2) change the error handling approach...maybe just when used with SR

(3) the controller should only use the SR information received from routing
protocols (IGP/BGP, e.g. draft-ietf-idr-bgp-prefix-sid)

(4) ..??


I didn't find a specific discussion about this topic in the archive...but I
may have missed it in between other related ones.  If I did, please point
me to it.

Thoughts/ideas/comments?

Thanks!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/idr/FomvQV2DqjaaRiAcLYLn3LcIdYM
[2] https://mailarchive.ietf.org/arch/msg/idr/wbPNQ-HM2NeR75gR2Or948J9o1I
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Tsv-art] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08

[Alvaro Retana]

On October 29, 2018 at 11:34:13 AM, Mirja Kuehlewind (IETF) (
i...@kuehlewind.net) wrote:

Hi!

FWIW, I agree with Mirja and her proposal below.  Not only does it sound
like this Informational document is talking about items that should be out
of scope, but the first paragraph in §7 says that it talks about "how the
problems described above (in section 3) could be solved using the segment
routing concept.”  To me, these are examples and (as the text also
mentions) "only parts of the solution”.

Let’s please wrap this document up!

Thanks!

Alvaro.


this still sounds very much like inventing a new mechanism which seem a bit
out of scope for this document. However, after all bandwidth requirements
might not be known or are very dynamic because of congestion control or
adaption mechanism in the application (e.g. adaptive video traffic), and
therefore there it is still the same problem that it is no reasonable to
make decision based on this very dynamic metric.

The text below sounds like you are rather interested to a) distinguish
elephant from mice flows and b) understand if the elephant flow has a
maximum bandwidth cap (because it's application-limited). These are
different information and might be more useful for your case. However, I
still think having this discussion in this level of details goes beyond the
scope of the document.

What’s about just saying something like, a central host can collect
per-flow information, either from the host directly or measurement on the
path, and use this information to impact routing. I would, however, also
like to see a note/warning in this context that metrics that are changing
very dynamically should not be used as input for routing decisions.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-ldp-interop-13: (with DISCUSS and COMMENT)

[Alvaro Retana]

Ahmed: Ping!!

We’re really close…

Alvaro.

On July 26, 2018 at 4:27:25 PM, Benjamin Kaduk (ka...@mit.edu) wrote:

Hi Ahmed,

Thanks for posting the update (and sorry for only getting to it now).

The two specific points I raised in my DISCUSS ballot are properly
addressed, but before I go clear that I was hoping you could help me
remember why the following text was removed when going from -13 to -14:

[...] Because this document recognizes that
miscofiguration and/or programming may result in false or conflicting
label binding advertisements, thereby compromising traffic
forwarding, the document recommends strict configuration/
programmability control as well as montoring the SID advertised and
log/error messages by the operator to avoid or at least significantly
minimize the possibility of such risk.

I couldn't find anything in my email history that helped jog my memory.

Thanks,

Benjamin

On Mon, Jul 16, 2018 at 02:10:37PM -0700, Ahmed Bashandy wrote:
> Hi,
>
> I just posted version 14
>
https://www.ietf.org/id/draft-ietf-spring-segment-routing-ldp-interop-14.txt
>
> Thanks
>
> Ahmed
>
>
>
> On 7/10/18 7:11 AM, Benjamin Kaduk wrote:
> > Hi Bruno,
> >
> > Thanks for the additional clarifications in the suggested text -- it
looks
> > good to me, so you and Ahmed should please go ahead with it (once
> > submissions open up again).
> >
> > -Benjamin
> >
> > On Tue, Jul 10, 2018 at 12:49:28PM +, bruno.decra...@orange.com
wrote:
> >> Hi Benjamin,
> >>
> >> Thanks for the discussion.
> >> Please see inline [Bruno2]
> >>
> >>> From: Benjamin Kaduk [mailto:ka...@mit.edu]
> >> > Sent: Tuesday, July 10, 2018 12:53 AM
> >> > On Mon, Jul 09, 2018 at 12:36:20PM +, bruno.decra...@orange.com
wrote:
> >> > > Hi Benjamin,
> >> > >
> >> > > Thanks for your comments.
> >> > > Please see inline another addition to Ahmed's answer. [Bruno]
> >> > >
> >> > > > From: Ahmed Bashandy [mailto:abashandy.i...@gmail.com]
> >> > > > Sent: Monday, July 09, 2018 2:30 AM
> >> > > >
> >> > > > Hi
> >> > > > Thanks for the review
> >> > > >
> >> > > > See reply to the comment at #Ahmed
> >> > > >
> >> > > > Ahmed
> >> > > >
> >> > > >
> >> > > > On 6/20/18 9:40 AM, Benjamin Kaduk wrote:
> >> > > > > Benjamin Kaduk has entered the following ballot position for
> >> > > > > draft-ietf-spring-segment-routing-ldp-interop-13: Discuss
> >> > > > >
> >> > > > > 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-spring-segment-routing-ldp-interop/
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
--
> >> > > > > DISCUSS:
> >> > > > >
--
> >> > > > >
> >> > > > > I may be missing something, but I don't see anything that says
whether the
> >> > > > > preference field introduced in Section 3.2.3 uses larger
values or smaller
> >> > > > > values for more-preferred SRMSes.
> >> > > > #Ahmed:
> >> > > > If I understand this statement correctly, the concern is about
which
> >> > > > label(s) get assigned to which prefix(es). This concern is
addressed as
> >> > > > follows
> >> > > >
> >> > > > From the MPLS architecture point of view, there is nothing wrong
in
> >> > > > having multiple labels for the same prefix. Segment routing in
general
> >> > > > and this document in particular did not introduce this behavior
nor did
> >> > > > they prohibit/restrict/relax it. For example, an implementation
that
> >> > > > allows the operator to locally assign multiple local labels to
the same
> >> > > > prefix may continue to apply this behavior whether the platform
supports
> >> > > > segment routing or not, in which case it is up to the
implementation
> >> > > > and/or the configuration affecting the MPLS forwarding plane to
specify
> >> > > > how to behave when multiple labels are assigned to the same
prefix. Such
> >> > > > behavior is a general MPLS behavior that outside the scope of
and is not
> >> > > > modified by segment routing.
> >> > > >
> >> > > > However the opposite, where the same label gets assigned to
multiple
> >> > > > prefixes resulting in label collision is problematic. This
document
> >> > > > prohibits label collision resulting from the use of SRMS (which
is
> >> > > > introduced by this document) in the first bullet starting at the
3rd
> >> > > > line of page 12:
> >> > > >   "-  If there is an incoming label collision as specified in
> >> > > >   [I-D.ietf-spring-segment-routing-mpls] , apply 

Re: [spring] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08

[Alvaro Retana]

Thanks Martin!

On June 6, 2018 at 3:14:45 PM, Martin Stiemerling (mls.i...@gmail.com)
wrote:

Hi Alvaro, all,

Thanks for addressing my concerns.

This version is good to go from my side.

Kind regards,

;Martin

Am 30.05.18 um 21:55 schrieb Alvaro Retana:
> Martin:
> br/>> Hi!!  How are you?
> br/>> Gaurav just posted a revision.  Please takke a look and let us know
if br/>> the changes address your concerrns or not.
> br/>>
https://www.ietf.org/rfcdiff??url2=draft-ietf-spring-segment-routing-msdc-09
> br/>> Thanks!!!
> br/>> Alvaro. <
> br/>> On May 25, 2018 at 12:08:46 PM, Gaurav Dawra ((gdawra.i...@gmail.com
br/>> <mailto:gdawra.ietf@@gmail.com>) wrote:
> br/>>> Hi Martin, <
>>
>> Thanks for review. I will post the new version. Hopefully, it will
br/>>> address all your comments and we can close thhis review.
>>
>> Any updates on below response?
>>
>> Cheers,
>>
>> Gaurav
>>
>> Sent from my iPhone
>>
>> On May 23, 2018, at 4:17 AM, Gaurav Dawra >>
<mailto:gdawra.ietf@@gmail.com>> wrote:
>>
>>> Hi Martin,
>>>
>>> Thanks for the review. Any further comments here ? I will post the
br/>>>> new version soon. <
>>>
>>> Cheers,
>>>
>>> Gaurav
>>>
>>> Sent from my iPhone
>>>
>>> On May 16, 2018, at 7:44 PM, Gaurav Dawra >>> <mailto:gdawra.ietf@@gmail.com>> wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> Apologies from my end we had few internal authors conversations on
br/>>>>> the points you have raised. <
>>>>
>>>> Please find below my response. I will be happy to discuss further,
br/>>>>> if needed. <
>>>>
>>>>  inline...
>>>>
>>>>> On Apr 9, 2018, at 7:58 AM, Martin Stiemerling >>>>> <mailto:mls.ii...@gmail.com>> wrote:
>>>>>
>>>>> Hi Gaurav,
>>>>>
>>>>> This got lost on my end, sorry for this. The filter just moved
br/>>>>>> these messages out of my sight... :-/
>>>>>
>>>>> Am 15.02.18 um 05:47 schrieb Gaurav Dawra:
>>>>>> Hey Martin,
>>>>>> Sorry for late reply. Please see some comments inline[Gaurav]
>>>>>>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling br/>>>>>>>>
mailto:mls.i...@gmail.com> br/>>>>>>>>; > wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I've reviewed this document as part of the transport area review
br/>>>>>>>> team's ongoing effort to review key IETF documents. These
br/>>>>>>> comments were written primarily for the transport area
directors, br/>>>>>>>> but are copied to the doocument's authors for their
information br/>>>>>>>&> and to allow them to address any issues raised.
When done at the
>>>>>>> time of IETF Last Call, the authors should consider this review
br/>>>>>>>> together with any other last-call comments they receive. Please
br/>>>&>>>>> always CC tsv-art@… if you reply to or forward this review.
>>>>>>>
>>>>>>> Summary:
>>>>>>> This draft has serious issues in Section 7.1, 7.2 and in one part
br/>>>>>>>> of Secction3, described in the review, and needs to be
rethought. br/>>&>>>>>> The other sections are good AFAIK.
>>>>>>>
>>>>>>>
>>>>>>> Technicals:
>>>>>>> The overall draft looks ok, but the three points below look
br/>>>>>>>> strange and need a fix before publication IMHO:
>>>>>>>
>>>>>>> Both Sections, 7.1. and 7.2., are describing ideas, but not well
br/>>>>>>>> proven funcationality and not even safe to use functionality.
br/>>>&>>>>> Both are some sort discussing that different paths in the
network br/>>>>>>>> could be used by the eend host traffic. This sounds
pretty much br/>>>>>>> like the Path Aware Networking Proposed
Research Group br/>>>>>>> (https://irtf.org/panrg) and hints to the
fact that there is no br/>>>>>>>> commonly understannd and accepted
engineering solution in this space.
>>>>&g

Re: [spring] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08

[Alvaro Retana]

Martin:

Hi!  How are you?

Gaurav just posted a revision.  Please take a look and let us know if the
changes address your concerns or not.

https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-msdc-09

Thanks!!

Alvaro.

On May 25, 2018 at 12:08:46 PM, Gaurav Dawra (gdawra.i...@gmail.com) wrote:

Hi Martin,

Thanks for review. I will post the new version. Hopefully, it will address
all your comments and we can close this review.

Any updates on below response?

Cheers,

Gaurav

Sent from my iPhone

On May 23, 2018, at 4:17 AM, Gaurav Dawra  wrote:

Hi Martin,

Thanks for the review. Any further comments here ? I will post the new
version soon.

Cheers,

Gaurav

Sent from my iPhone

On May 16, 2018, at 7:44 PM, Gaurav Dawra  wrote:

Hi Martin,

Apologies from my end we had few internal authors conversations on the
points you have raised.

Please find below my response. I will be happy to discuss further, if
needed.

 inline...

On Apr 9, 2018, at 7:58 AM, Martin Stiemerling  wrote:

Hi Gaurav,

This got lost on my end, sorry for this. The filter just moved these
messages out of my sight... :-/

Am 15.02.18 um 05:47 schrieb Gaurav Dawra:

Hey Martin,
Sorry for late reply. Please see some comments inline[Gaurav]

On Jan 9, 2018, at 2:25 PM, Martin Stiemerling mailto:mls.i...@gmail.com >> wrote:

Hi all,

I've reviewed this document as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address any
issues raised. When done at the time of IETF Last Call, the authors should
consider this review together with any other last-call comments they
receive. Please always CC tsv-art@… if you reply to or forward this review.

Summary:
This draft has serious issues in Section 7.1, 7.2 and in one part of
Section3, described in the review, and needs to be rethought. The other
sections are good AFAIK.


Technicals:
The overall draft looks ok, but the three points below look strange and
need a fix before publication IMHO:

Both Sections, 7.1. and 7.2., are describing ideas, but not well proven
funcationality and not even safe to use functionality. Both are some sort
discussing that different paths in the network could be used by the end
host traffic. This sounds pretty much like the Path Aware Networking
Proposed Research Group (https://irtf.org/panrg) and hints to the fact that
there is no commonly understand and accepted engineering solution in this
space.

Section 7.1:
[KANDULA04] is a really old reference that hasn't been followed up in
recent times and even worse there is no evidence that this is going to work
good enough or stable enough under real Internet traffic. Additionally, it
is more than unclear how any modern TCP implementation will react to this

[Gaurav] Will get back on this.


I will reply to the other email dicussing this.

 I have replied to other thread.



Section 7.2:
This section describes an idea without detailing too much about any further
aspects. Further it changes the commonly accepted notion of what an end
host can do with the network. At best this would require a good definition
of what an end host in your setting is, e.g., a highly modified piece of
(at least) software that usually not found in OS availble on the market
(yet?)
Further communicating instantaneous path characteristics to a central point
is potentially a bad idea, as the data is already outdated when reported by
any node.

[Gaurav] I believe Authors are trying to highlight that Host which is
defined in (https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15)
can influence the traffic based on the Calculations locally or jointly with
the controller. Implementations can decide how much Centralized -vs-
localized control is allowed at Host based on performance data collection.


Performance data collection (monitoring?) isn't crucial when it comes to
timely (actually real-time) reaction. However, this section isn't just
about performance data collection as it is about "Performance-aware
routing" this seems to try to interact in real-time with the network
behavior of TCP. This isn't even close to acceptable.

I would be ok to say that it is useful to collect performance data for
offline analysis and improvement of the data network. However, this is at
completely different magnitues of time scales.

I would recommend to remove the TCP part from this section entirely.

Ack, will update in next rev:

Section will read like this:

;


*   Knowing the path associated with flows/packets, the end host may*

*   deduce certain characteristics of the path on its own, and*

*   additionally use the information supplied with path information*

*   pushed from the controller or received via pull request.  The host*

*   may further share its path observations with the centralized agent,*

*   so that the latter may keep up-to-date 

Re: [spring] AD Review of draft-ietf-spring-segment-routing-ldp-interop-09

[Alvaro Retana]

On April 11, 2018 at 10:22:46 PM, Ahmed Bashandy (abashandy.i...@gmail.com)
wrote:

Ahmed:

Hi!  How are you?

I still have a couple of comments below…but nothing that should hold up
process at this point.  I’ll start the IETF Last Call.

Thanks!

Alvaro.



M2.1.2. "At least one SRMS MUST be present in the routing domain.
Multiple SRMSs SHOULD be present for redundancy.”  These MUST|SHOULD seem
to indicate a statement of fact.  Again, from a specification point of
view, what can be enforced?  s/MUST|SHOULD/must|should. Note also that in
7.2 the text says that "Multiple SRMSs can be provisioned in a network for
redundancy.”, which seems to be the right thing (no Normative language).

#Ahmed
I removed these two statements. Instead I modified the 3rd paragraph in
Section 4.2 to indicate that there must be at least one SRMS server in the
domain

The modification of that 3rd paragraph now reads: "At least one SRMS server
MUST exist in a routing domain…”, which really just moved the issue I was
pointing to from 4.2.1 to 4.2.  As I asked before, how can that “MUST” be
enforced?

Note that the sentence following this new text says: "Multiple SRMSs may be
present in the same network (for redundancy).”  I think that’s the right
way to express what is needed (no Normative language).


M2.2. Section 7.2. says that "a preference mechanism may also be used among
SRMSs so to deploy a primary/secondary SRMS scheme”…but no other details
are included.  This document is where the SRMS is first defined, so I would
expect this detail to also be included here.  I note that Section 3.1. (SID
Preference) of draft-ietf-spring-conflict-resolution contains the
preference specification. Please move that section to this document.

Ahmed: agreed. But since section 7.2 is under the manageability
consideration, IMO it should really not contain much specification.
Instead, I modified section  4.2.2 specify how to prefer SRMS
advertisements and removed section 7.2 completely. Section 7.2 in version
11 is section 7.3 in version 10

Ok.

I see that some of the text came from §3.1 in
draft-ietf-spring-conflict-resolution, but not all of that section made it
— specifically the part about the implicit preference values.  Why?

I didn’t check, but I’m assuming that the text that was moved here is not
also in draft-ietf-spring-segment-routing-mpls.  Is that true?




M4. Security Considerations.  I tend to agree that this document doesn’t
introduce anything new…but it does specify something different.  The base
SR-related advertisement by an IGP is done for the segments belonging to
the local node, but the SRMS lets a node (any node, multiple nodes) adverse
any mapping (for nodes that may be anywhere in the network) which may
result in conflicting advertisements (in the best case), or even false
ones.  Cryptographic authentication (any any other current security
mechanisms in IGPs) only verify that the information was not changed, but
it doesn’t validate the information itself, which can then lead to
conflicting and or false advertisements, which could “compromise traffic
forwarding”.  You should at least recognize that the risk exists, even if
no specific mitigation (except maybe strict configuration/programmability
control by the operator) can be mentioned.

#Ahmed: Agreed. Added text to indicate what you mentioned

Thanks for adding some text…but I think you should still say more.  The
risk is of course that a rogue router can inject any mapping it wants:
logging, control, etc..help avoid mistakes, but it doesn’t help in the case
where the incorrect/false mapping is advertised on purpose.  This last case
is something I would like to see mentioned explicitly.




P2. Please add References for "RSVP-TE, BGP 3107, VPNv4”.   BTW, note that
rfc3107 has been obsoleted by rfc8277 — you make references to “BGP3107”
routes/label.

#Ahmed Removed VPNv4 and added references to the others

I think that by "BGP [RFC8277]” you really didn’t meant just “BGP”, but
“BGP and Labeled Address Prefixes” (or something like that)..

There are still 4 occurrences of “BGP3107".
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] IETF 101 minutes

[Alvaro Retana]

Correct link:
https://datatracker.ietf.org/meeting/101/materials/minutes-101-spring-00

:-)

On April 16, 2018 at 10:21:00 AM, bruno.decra...@orange.com (
bruno.decra...@orange.com) wrote:

Hi all,



Minutes have been uploaded.

https://datatracker.ietf.org/meeting/100/materials/minutes-100-spring-00



For each agenda item, there is also an URL to the video.



Please review and correct as needed.



Many thanks to the anonymous minute taker.



--Bruno, Rob

_

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 may contain confidential or
privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
Thank you.

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

Re: [spring] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08

[Alvaro Retana]

[Adding Mirja to this thread, since she is the AD holding the DISCUSS on
this document.]

Mirja:

Hi!

Please take a look at the thread below — I still haven’t seen a reply from
Martin.

Thanks!

Alvaro.

On March 9, 2018 at 7:23:28 AM, Gaurav Dawra (gdawra.i...@gmail.com) wrote:

Hi, Martin,

Friendly Reminder for your feedback to close this review.

Cheers,

Gaurav


On Thu, Mar 1, 2018 at 7:01 AM, Gaurav Dawra  wrote:

> Hey Martin,
>
> Seeking your feedback here. Regarding Section 7.1, The intent of the
> document is to describe one suggestive way and do not attempt to
> standardize any suggested mechanisms based considering the Informational
> nature. Authors do not attempt to fully solve – but to indicate how SR
> helps towards this.The details of how the hosts figure out what paths to
> take through the network such that the TCP and application are not affected
> is outside the scope of this document.
>
> Would you prefer to add perhaps - “details outside the scope” or “this is
> one of the ways” or something else?
>
> Cheers,
>
> Gaurav
>
>
> On Wed, Feb 14, 2018 at 8:47 PM, Gaurav Dawra 
> wrote:
>
>> Hey Martin,
>>
>> Sorry for late reply. Please see some comments inline[Gaurav]
>>
>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling 
>> wrote:
>>
>> Hi all,
>>
>> I've reviewed this document as part of the transport area review team's
>> ongoing effort to review key IETF documents. These comments were written
>> primarily for the transport area directors, but are copied to the
>> document's authors for their information and to allow them to address any
>> issues raised. When done at the time of IETF Last Call, the authors should
>> consider this review together with any other last-call comments they
>> receive. Please always CC tsv-art@… if you reply to or forward this
>> review.
>>
>> Summary:
>> This draft has serious issues in Section 7.1, 7.2 and in one part of
>> Section3, described in the review, and needs to be rethought. The other
>> sections are good AFAIK.
>>
>>
>> Technicals:
>> The overall draft looks ok, but the three points below look strange and
>> need a fix before publication IMHO:
>>
>> Both Sections, 7.1. and 7.2., are describing ideas, but not well proven
>> funcationality and not even safe to use functionality. Both are some sort
>> discussing that different paths in the network could be used by the end
>> host traffic. This sounds pretty much like the Path Aware Networking
>> Proposed Research Group (https://irtf.org/panrg) and hints to the fact
>> that there is no commonly understand and accepted engineering solution in
>> this space.
>>
>> Section 7.1:
>> [KANDULA04] is a really old reference that hasn't been followed up in
>> recent times and even worse there is no evidence that this is going to work
>> good enough or stable enough under real Internet traffic. Additionally, it
>> is more than unclear how any modern TCP implementation will react to this
>>
>> [Gaurav] Will get back on this.
>>
>>
>> Section 7.2:
>> This section describes an idea without detailing too much about any
>> further aspects. Further it changes the commonly accepted notion of what an
>> end host can do with the network. At best this would require a good
>> definition of what an end host in your setting is, e.g., a highly modified
>> piece of (at least) software that usually not found in OS availble on the
>> market (yet?)
>> Further communicating instantaneous path characteristics to a central
>> point is potentially a bad idea, as the data is already outdated when
>> reported by any node.
>>
>> [Gaurav] I believe Authors are trying to highlight that Host which is
>> defined in (https://tools.ietf.org/html/draft-ietf-spring-segment-routi
>> ng-15) can influence the traffic based on the Calculations locally or
>> jointly with the controller. Implementations can decide how much
>> Centralized -vs- localized control is allowed at Host based on performance
>> data collection.
>>
>>
>> Section 3, 3rd bullet point:
>> It is the foundation of TCP that the network is regarded as a black box
>> and that you infer from the transmission of packets what the current state
>> of the network path is. Inferring network path metrics (you mention SRTT,
>> MSS, CWND ) is a bad idea, as this would required that all paths exhibit
>> this and if not what is going to happen?
>> It could be an interesting research field to change many points in TCP's
>> behavior, but this once again points to the fact that this not the IETF
>> works but IRTF or elsewhere.
>>
>> [Gaurav] Martin, Authors are trying to suggest that TCP is rightly
>> treating Network as Black Box. Authors are implying per path performance
>> metrics as not cached. Is there some change in text you are suggesting?
>>
>> Cheers,
>>
>> Gaurav
>>
>>
>> Kind regards,
>>
>>  Martin
>>
>> ___
>> spring mailing list
>> spring@ietf.org
>> 

Re: [spring] AD Review of draft-ietf-spring-segment-routing-ldp-interop-09

[Alvaro Retana]

Dear authors:

I just saw the refresh of this draft posted (to -10) — there were no
changes in it, or an answer to this message.  It has now been more than 3
months.  Is there a plan to at least respond to the comments?

Thanks!

Alvaro.

On December 20, 2017 at 7:36:54 PM, Alvaro Retana (aretana.i...@gmail.com)
wrote:

Dear authors:

I just finished reading this document.  I have some Major comments below
that I would like to see addressed before starting the IETF LC.

Thanks for your work on this document.

Alvaro.


Major:

M1. From Section 2: "An MCC, operating at node N, MUST ensure that the
incoming label it installs in the MPLS data plane of Node N has been
uniquely allocated to himself.”  I’m sure this sentence is not meant as a
new Normative statement for all MCCs, right?  I think that the “MUST” is
out of place since the text is really stating a fact.  s/MUST/must


M2. SRMS Definition and Operation

M2.1. Section 4.2.1. (SR to LDP Behavior) uses normative language to
describe the operation of the SRMS in ways that I think are not needed for
interoperability.

M2.1.1. "The SRMS MUST be configured by the operator in order to
advertise Node-SIDs
on behalf of non-SR nodes.”  Section 4.2 already says that "The mappings
advertised by one or more SRMSs result from local policy information
configured by the operator.”, so the sentence in 4.2.1 is at best
redundant.  In any case, what can be enforced from a specification point of
view by that “MUST”?  s/MUST/must

M2.1.2. "At least one SRMS MUST be present in the routing domain.
Multiple SRMSs
SHOULD be present for redundancy.”  These MUST|SHOULD seem to indicate a
statement of fact.  Again, from a specification point of view, what can be
enforced?  s/MUST|SHOULD/must|should. Note also that in 7.2 the text says
that "Multiple SRMSs can be provisioned in a network for redundancy.”,
which seems to be the right thing (no Normative language).

M2.2. Section 7.2. says that "a preference mechanism may also be used among
SRMSs so to deploy a primary/secondary SRMS scheme”…but no other details
are included.  This document is where the SRMS is first defined, so I would
expect this detail to also be included here.  I note that Section 3.1. (SID
Preference) of draft-ietf-spring-conflict-resolution contains the
preference specification. Please move that section to this document.

M2.3. Section 7.2 also says that: "When the SRMS advertise mappings, an
implementation SHOULD provide a mechanism through which the operator
determines which of the IP2MPLS mappings are preferred among the one
advertised by the SRMS and the ones advertised by LDP.”  First off, I think
that the SHOULD is out of place because it is not specifying any specific
action (the mechanism is not explicit). Second, this statement (with the
Normative SHOULD) is in conflict with (from 2.2. (IP2MPLS co-existence)):
"if both LDP and SR propose an IP to MPLS entry (IP2MPLS) for the same IP
prefix, then the LDP route SHOULD be selected.”  Solution: s/SHOULD/should


M3. Manageability Considerations

M3.1. The text in Section 7.1. (SR and LDP co-existence) is almost the same
as in Section 2.2. (IP2MPLS co-existence); the difference is that 7.1’s
first bullet says that "by default the LDP route MUST be selected”, while
2.2 uses SHOULD instead.  Which one is it?  Obviously, having the same text
is two places adds nothing to the document — please consolidate.

M3.2. [minor] The last bullet in 7.1/2.2 says that the "policy MAY be
locally defined.  There is no requirement that all routers use the same
policy.”  Given that in this case “all routers” really refers to the edge
nodes (at the IP2MPLS boundary), it seems like it makes sense that either
choice could be ok.  Maybe I’m wrong, but I’m guessing that giving
preference to LDP (MUST/SHOULD above) has to do with the assumption that it
is supported everywhere, while SR might not yet be…so it supports the
migration case in Section 3.  Is that a reasonable guess?  It would be
nice, to provide some justification for the default LDP preference so that
operators have a better idea of when it might be ok to use SR instead.


M4. Security Considerations.  I tend to agree that this document doesn’t
introduce anything new…but it does specify something different.  The base
SR-related advertisement by an IGP is done for the segments belonging to
the local node, but the SRMS lets a node (any node, multiple nodes) adverse
any mapping (for nodes that may be anywhere in the network) which may
result in conflicting advertisements (in the best case), or even false
ones.  Cryptographic authentication (any any other current security
mechanisms in IGPs) only verify that the information was not changed, but
it doesn’t validate the information itself, which can then lead to
conflicting and or false advertisements, which could “compromise traffic
forwarding”.  You should at least recognize that the risk exists, even if
no spec

[spring] Fwd: [PANRG] PAN(P)RG Agenda for IETF101

[Alvaro Retana]

FYI…

There is a presentation on Segment Routing in the agenda.

Alvaro.

On March 8, 2018 at 10:13:48 AM, Brian Trammell (IETF) (i...@trammell.ch)
wrote:

Greetings, all,

I've posted a draft meeting agenda for PAN(P)RG at IETF 101 at
https://datatracker.ietf.org/meeting/101/materials/agenda-101-panrg.html

We'll have a few presentations on mostly-IETF work related to path aware
networking, including two related to the IETF TAPS WG, which is discussing
interface work closely related to Laurent Chuat's presentation at our last
meeting in Singapore.

Following this, we'll have a discussion we'd decided to have back in
Prague, but hadn't scheduled yet -- Spencer Dawkins collecting bad ideas in
transport signaling. These, we hope, will point us toward spaces of path
properties it probably doesn't make much sense to explore.

Following that, I'd like to have some discussion about next steps for the
RG -- we have a set of questions, updated after Singapore, at
https://datatracker.ietf.org/doc/draft-trammell-panrg-questions/ -- so
please think about which questions we should focus on (or others not yet
listed there).

Many thanks, cheers, and see you in London!

Brian (as co-chair, PAN(P)RG)
___
Panrg mailing list
pa...@irtf.org
https://www.irtf.org/mailman/listinfo/panrg


signature.asc
Description: Binary data
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] I-D Action: draft-ietf-spring-segment-routing-mpls-12.txt

[Alvaro Retana]

Dear authors:

I still haven’t seen a satisfactory reply to my AD Review of this document
[1].  The latest version doubled (!) the size of the document (between
versions -10 and -12)[2] without proper justification, or (more
importantly!) discussion on the list.

I am returning the document to the WG for proper discussion of the proposed
changes.

Alvaro.

[1]
https://mailarchive.ietf.org/arch/msg/spring/97KtDebyroHfuNvllpNVb0s66H8/?qid=630f4b40ce9622377f9d39fe84fdab1a

[2]
https://www.ietf.org/rfcdiff?url1=draft-ietf-spring-segment-routing-mpls-10=draft-ietf-spring-segment-routing-mpls-12


On February 23, 2018 at 8:06:56 AM, internet-dra...@ietf.org (
internet-dra...@ietf.org) wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Source Packet Routing in Networking WG of
the IETF.

Title : Segment Routing with MPLS data plane
Authors : Ahmed Bashandy
Clarence Filsfils
Stefano Previdi
Bruno Decraene
Stephane Litkowski
Rob Shakir
Filename : draft-ietf-spring-segment-routing-mpls-12.txt
Pages : 24
Date : 2018-02-23

Abstract:
Segment Routing (SR) leverages the source routing paradigm. A node
steers a packet through a controlled set of instructions, called
segments, by prepending the packet with an SR header. In the MPLS
dataplane, the SR header is instantiated through a label stack. This
document specifies the forwarding behavior to allow instantiating SR
over the MPLS dataplane.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-12
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-mpls-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-mpls-12


Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] New spring WG Co-Chair

[Alvaro Retana]

Dear spring WG:

As all of you already know, Martin has been selected as a Routing AD
starting next month at IETF 101 in London.  He will step down as spring
co-chair then.  Martin: thank you for the focused effort you have dedicated
to this WG — we all look forward to working with you in your new role.
Congratulations!

In consultation with Bruno and the other ADs, we have asked Rob Shakir to
take on the role of spring Co-Chair.  Rob currently works at Google and has
been a long time participant in the IETF.

I am adding Rob as a third Chair to facilitate the transition.  The
expectation is that he will fully take over for Martin at IETF 101.
Welcome Rob!

Rob can be reached at ro...@google.com.

Thanks!

Alvaro.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SPRING WG

[Alvaro Retana]

Gaurav: First of all, thank you for your eagerness to serve!


Dear WG:

As I’m sure everyone already knows, Martin has been selected by the nomcom
to serve as Routing Area Director [1].  He will start his new job during
IETF 101.  Yes, Martin will not continue as spring co-Chair once he becomes
an AD.

The other RTG ADs (including Martin), Bruno and I have already started our
work to select a replacement.  We expect to come to a decision soon,
certainly before the meeting in London.   To be clear, Chairs are not
elected by the WG, the selection is at the discretion of the AD [rfc2418].

If anyone wants to talk about the process, please contact me directly.

Thanks!

Alvaro.

[1]
https://www.ietf.org/blog/nomcom-2017-2018-announcement-nomcom-selections/?primary_topic=5;



On February 17, 2018 at 4:22:34 PM, Gaurav Dawra (gda...@linkedin.com)
wrote:

> Hi, Spring WG,
>
> We have heard that position for SPRING Co-Chair may be coming open soon.
> If that's the case and if SPRING WG is looking to elect another Co-Chair, I
> would like to volunteer to put forward my nomination.
>
> I have been involved in SR for several years and have co-authored several
> drafts already – I am well versed with the operator, vendor and technology
> requirements and would like to volunteer to help to move the WG charter
> forward.
>
> Cheers,
>
> Gaurav
>
> Sent from Outlook  for iOS
>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Kathleen Moriarty's Discuss on draft-ietf-spring-segment-routing-13: (with DISCUSS)

[Alvaro Retana]

Kathleen:

Hi!

When you get a chance, please take a look at Les’ updates.

Thanks!

Alvaro.

On January 12, 2018 at 6:06:24 PM, Les Ginsberg (ginsberg) (
ginsb...@cisco.com) wrote:

Kathleen -

I propose the following addition to the end of Section 8.

"The use of best practices to reduce the risk of tampering within
the trusted domain is important. Such practices are discussed in
[RFC4381] and are applicable to both SR-MPLS and SRv6."

Les


> -Original Message-
> From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
> Sent: Friday, January 12, 2018 10:58 AM
> To: Alvaro Retana <aretana.i...@gmail.com>
> Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; The IESG
> <i...@ietf.org>; spring@ietf.org; spring-cha...@ietf.org;
draft-ietf-spring-
> segment-rout...@ietf.org; martin.vigour...@nokia.com
> Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-spring-segment-
> routing-13: (with DISCUSS)
>
> Hi, Alvaro!
>
> Thanks for bringing this to my attention, the message from Les slipped
> through the cracks.
>
> On Thu, Jan 11, 2018 at 4:57 PM, Alvaro Retana <aretana.i...@gmail.com>
> wrote:
> > Kathleen:
> >
> > Hi!
> >
> > Any thoughts on the update to this document?
> >
> > Thanks!
> >
> > Alvaro.
> >
> > On December 20, 2017 at 6:42:02 PM, Les Ginsberg (ginsberg)
> > (ginsb...@cisco.com) wrote:
> >
> > Kathleen -
> >
> > Thanx for the review.
> > V14 has been published and it attempts to address the Security
> > concerns raised by you and others.
> > Look forward to your feedback.
> >
> > Inline.
> >
> >> -Original Message-
> >> From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
> >> Sent: Wednesday, December 13, 2017 7:55 PM
> >> To: The IESG <i...@ietf.org>
> >> Cc: draft-ietf-spring-segment-rout...@ietf.org;
> >> aretana.i...@gmail.com; spring-cha...@ietf.org;
> >> martin.vigour...@nokia.com; spring@ietf.org
> >> Subject: Kathleen Moriarty's Discuss on
> >> draft-ietf-spring-segment-routing-
> >> 13: (with DISCUSS)
> >>
> >> Kathleen Moriarty has entered the following ballot position for
> >> draft-ietf-spring-segment-routing-13: Discuss
> >>
> >> 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-spring-segment-routing/
> >>
> >>
> >>
> >> -
> >> -
> >> DISCUSS:
> >> -
> >> -
> >>
> >> While I understand the assumption that following the capabilities of
> >> existing protocols that incorporate similar functionality is okay,
> >> I'd like to walk through the security properties left off in the
> >> security considerations section to prevent tampering and see what can
> >> be done to correct that or minimally to list out the considerations.
> >>
> >> There's a few places in the security considerations section to call
> >> out specifically.
> >>
> >> Section 8.1:
> >> "The received information is validated using existing control plane
> >> protocols providing authentication and security mechanisms. Segment
> >> Routing does not define any additional security mechanism in existing
> >> control plane protocols."
> >>
> >> For MPLS what "security mechanisms" are referred to in this text? It
> >> would be helpful to list any properties explicitly or drop this
> >> phrase if there are no additional security mechanisms. Since segment
> >> routing lists an explicit list of segments (I see that this can be
> >> done with MPLS labels and you note it is already exposed), why is
> >> there no mention of integrity protection and origin authentication to
> >> prevent tampering? I think EKR's comment is already hinting at this
> >> with his comments on IPv6, but I'd like to see explicit text to
> >> preferably fix this gap in the architecture, but minima

Re: [spring] Kathleen Moriarty's Discuss on draft-ietf-spring-segment-routing-13: (with DISCUSS)

[Alvaro Retana]

Kathleen:

Hi!

Any thoughts on the update to this document?

Thanks!

Alvaro.

On December 20, 2017 at 6:42:02 PM, Les Ginsberg (ginsberg) (
ginsb...@cisco.com) wrote:

Kathleen -

Thanx for the review.
V14 has been published and it attempts to address the Security concerns
raised by you and others.
Look forward to your feedback.

Inline.

> -Original Message-
> From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
> Sent: Wednesday, December 13, 2017 7:55 PM
> To: The IESG 
> Cc: draft-ietf-spring-segment-rout...@ietf.org; aretana.i...@gmail.com;
> spring-cha...@ietf.org; martin.vigour...@nokia.com; spring@ietf.org
> Subject: Kathleen Moriarty's Discuss on
draft-ietf-spring-segment-routing-
> 13: (with DISCUSS)
>
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-spring-segment-routing-13: Discuss
>
> 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-spring-segment-routing/
>
>
>
> --
> DISCUSS:
> --
>
> While I understand the assumption that following the capabilities of
existing
> protocols that incorporate similar functionality is okay, I'd like to
walk through
> the security properties left off in the security considerations section
to
> prevent tampering and see what can be done to correct that or minimally
to
> list out the considerations.
>
> There's a few places in the security considerations section to call out
> specifically.
>
> Section 8.1:
> "The received information is validated using
> existing control plane protocols providing authentication and
> security mechanisms. Segment Routing does not define any additional
> security mechanism in existing control plane protocols."
>
> For MPLS what "security mechanisms" are referred to in this text? It
would
> be helpful to list any properties explicitly or drop this phrase if there
are no
> additional security mechanisms. Since segment routing lists an explicit
list of
> segments (I see that this can be done with MPLS labels and you note it is
> already exposed), why is there no mention of integrity protection and
origin
> authentication to prevent tampering? I think EKR's comment is already
> hinting at this with his comments on IPv6, but I'd like to see explicit
text to
> preferably fix this gap in the architecture, but minimally to document it
and
> the associated security threats that result from this gap for MPLS and
IPv6.
>

[Les:] We have reemphasized that SR is designed to be used within a trusted
domain. As such, any attacker who sees a segment list already has breached
the domain protections.

> Section 8.2:
>
> "From a network protection standpoint, there is an assumed trust model
> such that any node adding an SRH to the packet is assumed to be
> allowed to do so. Therefore, by default, the explicit routing
> information MUST NOT be leaked through the boundaries of the
> administered domain. Segment Routing extensions that have been
> defined in various protocols, leverage the security mechanisms of
> these protocols such as encryption, authentication, filtering, etc."
>
> This document focuses on the same threats as the MPLS use cases with no
> mention of tampering or mitigations. Text should be added to describe how
> origin authentication and integrity are provided in the source routing
header
> for IPv6 with the associated threats or to describe this gap if a
solution does
> not exist. I have not read the draft referred to at the start of this
section, so I
> don't know if it addresses the concern or not. In any case, this document
> isn't complete without some text on tampering considerations within your
> trusted domain.
>
[Les:] The architecture draft is NOT proposing support of SRH introduced
outside the domain of trust. Such support is an exception to the
architecture. When done the use of origin authentication would be
appropriate, but such an exception is not being described nor advocated in
this document.

Les

> Thank you.
>
>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Alissa Cooper's Discuss on draft-ietf-spring-segment-routing-13: (with DISCUSS and COMMENT)

[Alvaro Retana]

Alissa:

Hi!

Any thoughts on the update to this document?

Thanks!

Alvaro.

On December 20, 2017 at 6:18:13 PM, Les Ginsberg (ginsberg) (
ginsb...@cisco.com) wrote:

Alissa -

Thanx for the review.
V14 has been published and it attempts to address the Security concerns
raised by you and others.
Look forward to your feedback.

Inline.

> -Original Message-
> From: Alissa Cooper [mailto:ali...@cooperw.in]
> Sent: Wednesday, December 13, 2017 10:42 AM
> To: The IESG 
> Cc: draft-ietf-spring-segment-rout...@ietf.org; aretana.i...@gmail.com;
> spring-cha...@ietf.org; martin.vigour...@nokia.com; spring@ietf.org
> Subject: Alissa Cooper's Discuss on draft-ietf-spring-segment-routing-13:
> (with DISCUSS and COMMENT)
>
> Alissa Cooper has entered the following ballot position for
> draft-ietf-spring-segment-routing-13: Discuss
>
> 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-spring-segment-routing/
>
>
>
> --
> DISCUSS:
> --
>
> I ended up reading draft-ietf-6man-segment-routing-header in tandem with
> this document, and I have a question arising out of that. The trust model
for
> SRv6 outlined in this document appears to be one of reliance on the fact
that
> an SRH will only ever be inserted and appear within a single
administrative
> domain.
> But Section 5.2.2 of draft-ietf-6man-segment-routing-header talks about
an
> SRH being inserted by a device outside of the segment routing domain.
> Which is correct? I think this is an important question because the whole
> trust model for the SR information seems to rely on out-of-band trust
> between participating nodes.
>
> I also think this is important because there is no discussion in this
document
> of the impact of the inclusion of the SR metadata on the fingerprinting
of the
> device that inserted it. Section 5.1.4 of
draft-ietf-6man-segment-routing-
> header sort of alludes to this but seems to equate the capabilities of an
> active attacker (who can conduct a traceroute) with a passive attacker
who
> could passively collect topology/fingerprinting information simply by
> observing SRHes flowing by on the network. If the limitation to a single
> administrative domain is meant to prevent such a passive attack (not sure
if
> that is really true, but perhaps the document assumes it?), that's
another
> reason that the existence of such a limitation needs to be clarified.
>
>
[Les:] We share a common concern regarding trust issues. The architecture
draft speaks to the default policy of only allowing trusted sources to
insert SRH.
The 6man draft currently discusses exceptions under the protection of
authentication. I don’t see that as a contradiction.
The risk/reward of allowing such exceptions can (and should) be discussed
in the review of the 6man draft, but I am not convinced the architecture
draft needs to speak to this since it is a clearly stated exception to the
base trust model.

The point that SR is intended to operate within a trusted domain has been
clarified/reemphasized in the Security section changes.

Les



> --
> COMMENT:
> --
>
>
> Per my DISCUSS comment, I think this document needs to include some
> considerations concerning the additional metadata that SRv6 adds to the
> packet.
> This has implications not just for passive observers but also for any
node that
> logs the SRH.
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] AD Review of draft-ietf-spring-segment-routing-ldp-interop-09

[Alvaro Retana]

Dear authors:

I just finished reading this document.  I have some Major comments below
that I would like to see addressed before starting the IETF LC.

Thanks for your work on this document.

Alvaro.


Major:

M1. From Section 2: "An MCC, operating at node N, MUST ensure that the
incoming label it installs in the MPLS data plane of Node N has been
uniquely allocated to himself.”  I’m sure this sentence is not meant as a
new Normative statement for all MCCs, right?  I think that the “MUST” is
out of place since the text is really stating a fact.  s/MUST/must


M2. SRMS Definition and Operation

M2.1. Section 4.2.1. (SR to LDP Behavior) uses normative language to
describe the operation of the SRMS in ways that I think are not needed for
interoperability.

M2.1.1. "The SRMS MUST be configured by the operator in order to
advertise Node-SIDs
on behalf of non-SR nodes.”  Section 4.2 already says that "The mappings
advertised by one or more SRMSs result from local policy information
configured by the operator.”, so the sentence in 4.2.1 is at best
redundant.  In any case, what can be enforced from a specification point of
view by that “MUST”?  s/MUST/must

M2.1.2. "At least one SRMS MUST be present in the routing domain.
Multiple SRMSs
SHOULD be present for redundancy.”  These MUST|SHOULD seem to indicate a
statement of fact.  Again, from a specification point of view, what can be
enforced?  s/MUST|SHOULD/must|should. Note also that in 7.2 the text says
that "Multiple SRMSs can be provisioned in a network for redundancy.”,
which seems to be the right thing (no Normative language).

M2.2. Section 7.2. says that "a preference mechanism may also be used among
SRMSs so to deploy a primary/secondary SRMS scheme”…but no other details
are included.  This document is where the SRMS is first defined, so I would
expect this detail to also be included here.  I note that Section 3.1. (SID
Preference) of draft-ietf-spring-conflict-resolution contains the
preference specification. Please move that section to this document.

M2.3. Section 7.2 also says that: "When the SRMS advertise mappings, an
implementation SHOULD provide a mechanism through which the operator
determines which of the IP2MPLS mappings are preferred among the one
advertised by the SRMS and the ones advertised by LDP.”  First off, I think
that the SHOULD is out of place because it is not specifying any specific
action (the mechanism is not explicit). Second, this statement (with the
Normative SHOULD) is in conflict with (from 2.2. (IP2MPLS co-existence)):
"if both LDP and SR propose an IP to MPLS entry (IP2MPLS) for the same IP
prefix, then the LDP route SHOULD be selected.”  Solution: s/SHOULD/should


M3. Manageability Considerations

M3.1. The text in Section 7.1. (SR and LDP co-existence) is almost the same
as in Section 2.2. (IP2MPLS co-existence); the difference is that 7.1’s
first bullet says that "by default the LDP route MUST be selected”, while
2.2 uses SHOULD instead.  Which one is it?  Obviously, having the same text
is two places adds nothing to the document — please consolidate.

M3.2. [minor] The last bullet in 7.1/2.2 says that the "policy MAY be
locally defined.  There is no requirement that all routers use the same
policy.”  Given that in this case “all routers” really refers to the edge
nodes (at the IP2MPLS boundary), it seems like it makes sense that either
choice could be ok.  Maybe I’m wrong, but I’m guessing that giving
preference to LDP (MUST/SHOULD above) has to do with the assumption that it
is supported everywhere, while SR might not yet be…so it supports the
migration case in Section 3.  Is that a reasonable guess?  It would be
nice, to provide some justification for the default LDP preference so that
operators have a better idea of when it might be ok to use SR instead.


M4. Security Considerations.  I tend to agree that this document doesn’t
introduce anything new…but it does specify something different.  The base
SR-related advertisement by an IGP is done for the segments belonging to
the local node, but the SRMS lets a node (any node, multiple nodes) adverse
any mapping (for nodes that may be anywhere in the network) which may
result in conflicting advertisements (in the best case), or even false
ones.  Cryptographic authentication (any any other current security
mechanisms in IGPs) only verify that the information was not changed, but
it doesn’t validate the information itself, which can then lead to
conflicting and or false advertisements, which could “compromise traffic
forwarding”.  You should at least recognize that the risk exists, even if
no specific mitigation (except maybe strict configuration/programmability
control by the operator) can be mentioned.


M5. References:  These references don’t need to be Normative and can be
made Informative:
I-D.ietf-isis-segment-routing-extensions,
I-D.ietf-ospf-ospfv3-segment-routing-extensions,
I-D.ietf-ospf-segment-routing-extensions.
 OTOH, this one should be Normative: RFC5036

Re: [spring] Mirja Kühlewind's No Objection on draft-ietf-spring-ipv6-use-cases-11: (with COMMENT)

[Alvaro Retana]

On December 14, 2017 at 7:35:10 AM, Mirja Kühlewind (i...@kuehlewind.net)
wrote:

Mirja:

Hi!

Minor question regarding SPRING in Core networks (section 2.5): Why is SR
here
bettter than MPLS (which I guess is used today
 for this use case)? In
general
it would probably have been nice to also talk a bit about how this is
better/different than existing technologies.

In reality that part is not about SRv6 vs MPLS.  Instead, it’s about the
fact that people do use IP-only (no MPLS) infrastructure in some cases.
IOW, the use cases in this document should provide justification for
functionality needed above a plain IP network.

Thanks!

Alvaro.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Adam Roach's No Objection on draft-ietf-spring-segment-routing-13: (with COMMENT)

[Alvaro Retana]

On December 13, 2017 at 9:58:42 AM, Adam Roach (a...@nostrum.com) wrote:

Adam:

Hi!

Thanks to everyone who put in work on this document. I do note that the
list of
authors is over the five-author recommended limit. I checked both the ballot

and the shepherd write-up, and was a little surprised not to find an
explanation of why this document is exceptional in this regard.

This document, and most of the spring-related ones, has really been a group
effort with important contributions from a significant number of people.
You will notice that in most cases I have exercised my discretion in
allowing more than 5 authors in the front page, while many contributors
have been moved to their own section, precisely because of the level and
significance of the contributions.

Thanks!

Alvaro.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] AD Review of draft-ietf-spring-segment-routing-mpls-10

[Alvaro Retana]

Ahmed:

Hi!

It’s been almost a month, and I haven’t seen a reply from you.

I will send the document back to the WG by the end of this week.

Thanks!

Alvaro.

On November 2, 2017 at 6:49:10 PM, Alvaro Retana (aretana.i...@gmail.com)
wrote:

On October 30, 2017 at 2:12:18 PM, Ahmed Bashandy (bashandy) (
basha...@cisco.com ) wrote:

Ahmed:

Hi!  How are you?

...

The main questions/concerns that I have related to this document is not
just for the authors, but for the Shepherd and the Chairs too.

Q1. Why is this document on the Standards Track? From the Introduction:
“This drafts describes how Segment Routing operates on top of the MPLS data
plane.”  Describes, yes.  On the other hand, the Shepherd’s write-up says
that it “specifies the generic functions of the architecture” – I don’t see
a specification, just a description.  As such, I think this document should
be Informational.

#Ahmed: The new version of the draft specifies many things that are
applicable to instantiation of SR over MPLS

I’ll take your answer as confirming that the old version (-10) wasn’t
really specifying anything.

For this new version (-11), can you please be specific on what these “many
things” are?

I see some new Normative Language in the new 2.x sub-sections.  I have some
specific comments on that:

Q1.A. Section 2.2. (SID Representation in the MPLS Forwarding Plane):

The MCC MUST ensure that any label value corresponding to any SID it
   installs in the forwarding plane follows the following rules:

   o  The label value MUST be unique within the router on which the MCC
  is running. i.e. the label MUST only be used to represent the SID.

   o  The label value MUST NOT be identical to or within the range of
  any reserved label value or range [reserved-MPLS
<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-11#ref-reserved-MPLS>],
respectively.

These seem to be new requirements for the MCCs. Given that the
protocol extensions (and LDP) are defined (in Section 2) as MCCs, how
are they supposed to follow these rules, specially the first one? As
far as I can tell, the IGP extensions (for example) can carry
Label/SID information from an advertising node, so I don’t know how a
local MCC (remote to that advertising node, which is locally
"installing forwarding entries in the MPLS data plane”) can guarantee
what the label is used for (“only used to represent the SID”). Maybe
I’m missing something and this is already specified somewhere else…??

The second rule is just what the MPLS Architecture already specifies, no
nothing new, right? BTW, the link in the reserved-MPLS reference doesn’t
work — a better reference might be rfc3032 or rfc7274.


Q1.B. Section 2.3. (Segment Routing Global Block and Local Block):

The following rules apply to the list of MPLS ranges representing the
   SRGB

   o  The list of label ranges MUST only be used to instantiate global
  SIDs into the MPLS forwarding plane

   o  Every range in the list of ranges specifying the SRGB MUST NOT
  cover or overlap with a reserved label value or range [reserved-
  MPLS], respectively.
 . . .
   Just like SRGB, the SRLB need not be a single
   contiguous range of label, except the SRGB MUST only be used to
   instantiate global SIDs into the MPLS forwarding plane.


The first rule (and the text below them) points to the global nature of the
SR *global* Block. The architecture document already says that "In SR-MPLS,
SRGB is a local property of a node and identifies the set of local labels
reserved for global segments.” Nothing new specified here.


  Q1.C. Section 2.4. (Mapping a SID
Index to an MPLS label) introduces an algorithm to calculate the label
value.  Note that the architecture document now includes an algorithm
(in Section 3.1.2) as well — the algorithm in this document doesn’t
look to be the same, but even if it is, it would be confusing to
specify the same thing in two places.


  Q1.D. The rest of the sub-sections seem to rehash
forwarding behaviors, which, because of the fact that the MPLS
architecture is not changing, seem to add nothing interesting or
important to this document.

 Having said all that, I still don’t see a clear justification for
this document to be in the Standards Track.

Q2. Section 2. (MPLS Instantiation of Segment Routing) is the only one with
any real content…but there are only a couple of things in it that are not
in the Architecture document: the introduction of the SRLB, and some words
about the index – both of which should be really explained in the
Architecture document, and not here.  I wonder what the value of publishing
this document really is.  What long-term archival value does it provide?

#Ahmed: The long term plan is to move details of MPLS-specific
specifications to this document and keep the architecture document more
general

The “long term plan” ??  What do you mean?  The architecture document is
already i

Re: [spring] AD Review of draft-ietf-spring-segment-routing-12

[Alvaro Retana]

Les:

Hi!

I don’t think I got a reply on the IPR question below.

Thanks!

Alvaro.

On November 1, 2017 at 3:55:00 PM, Alvaro Retana (aretana.i...@gmail.com)
wrote:

Les:

Hi!

Apologies for the long delay in responding. The transference of the pen
from Stefano resulted in a longer delay than it should have.

Thanks for taking this on!

As a new author: are you aware of any undeclared IPR for this document?
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] AD Review of draft-ietf-spring-segment-routing-central-epe-06

[Alvaro Retana]

On October 30, 2017 at 1:53:07 AM, Gaurav Dawra (gdawra) (gda...@cisco.com)
wrote:

Gaurav:

Hi!  Thanks for taking over this document!

I have some remaining comments below, please take a look.  I’m starting the
IETF Last Call, which will be extended to account for the IETF meeting and
the US Holidays.

Thanks!

Alvaro.


...

M2.3. “The solution SHOULD minimize the need for new BGP capabilities at
the ingress PEs.”  What is the explicit requirement, that needs the
“SHOULD”, from an interoperability point of view?

 At Ingress PE, this requirement covers that there is need for some
minimal configuration or protocol extension for Egress Engineering.

Ok, but (1) the text doesn’t talk about configuration (just capabilities),
and (2) I really think that Normative Language should not be used in this
case because there’s really nothing that can be enforced: “SHOULD” means
that “there may exist valid reasons in particular circumstances to ignore a
particular item”, so there’s nothing that can be done if an extension or
configuration is justified.  Please s/SHOULD/should.


M2.4. “The solution MUST accommodate an ingress BGP-EPE policy at an
ingress PE or directly at a source host within the domain.”  “MUST
accommodate”??  What are you looking for?  The ability to program at those
points?  The ability to instantiate any policy?

 Solution MUST cover the ability to accommodate instantiation and
programming of the BGP-EPE policy at Ingress.

How about this:

New>

The solution MUST support the definition of an ingress BGP-EPE policy at
either the ingress PE or at the source of the traffic.

(I took “host” out because I assume that a PE in the other network is also
a valid place.)

...

P2. The examples in Sections 3.x seem incomplete and inaccurate to me.
Also, the names used don’t match what is specified in
draft-ietf-idr-bgpls-segment-routing-epe.  In general, please be consistent
with the names!  For example:



Section 3.1. (PeerNode SID to D):

“

   Descriptors:



   o  Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1



   o  Peer Descriptors (peer BGP router-ID, peer ASN): 192.0.2.4, AS2



   o  Link Descriptors (IP interface address, neighbor IP address):

  2001:db8:cd::c, 2001:db8:cd::d



   Attributes:



   o  PeerNode SID: 1012

“



Comments>

- Section 5.1 in draft-ietf-idr-bgpls-segment-routing-epe uses “Local Node
Descriptor” instead of simply “Node Descriptor”, and the BGP-LS ID is
missing above.

- s/Peer Descriptors/Remote Node Descriptor

- The Link Descriptor uses the terms “IPv6 Interface Address” and “IPv6
Neighbor Address”…

- s/Attributes/Link Attribute

  ACK> Will compare and address in next update.

3.2-3.5 were not updated with the IPv6 names.


...

P4. References:

- Please add a reference for BMP and IPFIX.

- Put the reference to BGP-LS on first mention (and not just way down in
Section 9).

- Replace the reference to RFC3107 with draft-ietf-mpls-rfc3107bis – and it
can be made Informative.

Not all the references were updated, and rfc3107bis is now rfc8277 anyway.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] AD Review of draft-ietf-spring-segment-routing-mpls-10

[Alvaro Retana]

 On October 30, 2017 at 2:12:18 PM, Ahmed Bashandy (bashandy) (
basha...@cisco.com ) wrote:

Ahmed:

Hi!  How are you?

...

The main questions/concerns that I have related to this document is not
just for the authors, but for the Shepherd and the Chairs too.

Q1. Why is this document on the Standards Track? From the Introduction:
“This drafts describes how Segment Routing operates on top of the MPLS data
plane.”  Describes, yes.  On the other hand, the Shepherd’s write-up says
that it “specifies the generic functions of the architecture” – I don’t see
a specification, just a description.  As such, I think this document should
be Informational.

#Ahmed: The new version of the draft specifies many things that are
applicable to instantiation of SR over MPLS

I’ll take your answer as confirming that the old version (-10) wasn’t
really specifying anything.

For this new version (-11), can you please be specific on what these “many
things” are?

I see some new Normative Language in the new 2.x sub-sections.  I have some
specific comments on that:

Q1.A. Section 2.2. (SID Representation in the MPLS Forwarding Plane):

   The MCC MUST ensure that any label value corresponding to any SID it
   installs in the forwarding plane follows the following rules:

   o  The label value MUST be unique within the router on which the MCC
  is running. i.e. the label MUST only be used to represent the SID.

   o  The label value MUST NOT be identical to or within the range of
  any reserved label value or range [reserved-MPLS
],
respectively.

These seem to be new requirements for the MCCs. Given that the
protocol extensions (and LDP) are defined (in Section 2) as MCCs, how
are they supposed to follow these rules, specially the first one? As
far as I can tell, the IGP extensions (for example) can carry
Label/SID information from an advertising node, so I don’t know how a
local MCC (remote to that advertising node, which is locally
"installing forwarding entries in the MPLS data plane”) can guarantee
what the label is used for (“only used to represent the SID”). Maybe
I’m missing something and this is already specified somewhere else…??

The second rule is just what the MPLS Architecture already specifies, no
nothing new, right? BTW, the link in the reserved-MPLS reference doesn’t
work — a better reference might be rfc3032 or rfc7274.


Q1.B. Section 2.3. (Segment Routing Global Block and Local Block):

   The following rules apply to the list of MPLS ranges representing the
   SRGB

   o  The list of label ranges MUST only be used to instantiate global
  SIDs into the MPLS forwarding plane

   o  Every range in the list of ranges specifying the SRGB MUST NOT
  cover or overlap with a reserved label value or range [reserved-
  MPLS], respectively.
 . . .
   Just like SRGB, the SRLB need not be a single
   contiguous range of label, except the SRGB MUST only be used to
   instantiate global SIDs into the MPLS forwarding plane.


The first rule (and the text below them) points to the global nature of the
SR *global* Block. The architecture document already says that "In SR-MPLS,
SRGB is a local property of a node and identifies the set of local labels
reserved for global segments.” Nothing new specified here.


 Q1.C. Section 2.4. (Mapping a SID
Index to an MPLS label) introduces an algorithm to calculate the label
value.  Note that the architecture document now includes an algorithm
(in Section 3.1.2) as well — the algorithm in this document doesn’t
look to be the same, but even if it is, it would be confusing to
specify the same thing in two places.


 Q1.D. The rest of the sub-sections seem to rehash
forwarding behaviors, which, because of the fact that the MPLS
architecture is not changing, seem to add nothing interesting or
important to this document.

 Having said all that, I still don’t see a clear justification for
this document to be in the Standards Track.

 Q2. Section 2. (MPLS Instantiation of Segment Routing) is the only one
with any real content…but there are only a couple of things in it that are
not in the Architecture document: the introduction of the SRLB, and some
words about the index – both of which should be really explained in the
Architecture document, and not here.  I wonder what the value of publishing
this document really is.  What long-term archival value does it provide?

#Ahmed: The long term plan is to move details of MPLS-specific
specifications to this document and keep the architecture document more
general

The “long term plan” ??  What do you mean?  The architecture document is
already in IETF Last Call — are you saying that both documents still
require more changes and are not ready for publication?  I really hope that
is not what you mean.

In any case, you did not answer my question about the value of the document
as is.  No 

Re: [spring] AD Review of draft-ietf-spring-segment-routing-12

[Alvaro Retana]

On November 2, 2017 at 7:59:31 AM, stefano previdi (stef...@previdi.net)
wrote:

Stefano:

Hi!

> I would also strongly recommend that you include a Deployment/Operations
Section.


what exactly would you expect to find in such section ? We have the
Manageability section which illustrates how SR can be managed. An
operation/deployment section will have to be exhaustive and illustrative on
the different use-cases that SR addresses and hence can become pretty large.


To my view, the draft focuses on architecture, not on deployment or
operation. These are mostly described in the different use-cases drafts.

Expectations: take a look at rfc5706.  There’s a lot in there, including
manageability, which this document already has.  To be specific, a couple
of things come to mind:

- considerations about when/why the same SRGB should be used.  The text
says that it is “strongly recommended”, but it would be nice to explain
further the pros/cons.

- considerations about deciding when/why someone may decide to sub-divide
the network into multiple domains vs keeping just one.  Is it a scalability
issue, or just operational simplicity?


Note that the use case documents justify the need for Segment Routing, they
don’t talk about how to deploy it.  The concepts above (SRGB and SR Domain)
are presented in this document and statements are made about them but no
further explanation is given — that is why I would strongly recommend (that
is not a MUST) that you include a Deployment/Operations Considerations
Section.

Thanks!

Alvaro.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] AD Review of draft-ietf-spring-segment-routing-12

[Alvaro Retana]

 On October 28, 2017 at 10:51:52 AM, Les Ginsberg (ginsberg) (
ginsb...@cisco.com ) wrote:

Les:

Hi!

Apologies for the long delay in responding. The transference of the pen
from Stefano resulted in a longer delay than it should have.

Thanks for taking this on!

As a new author: are you aware of any undeclared IPR for this document?

A new version has been published which addresses your comments. Specific
replies inline.

My replies (to what I think still needs work or answers to questions) are
below.

In general, I think that the definition of “SR Domain” still needs work.  I
would also strongly recommend that you include a Deployment/Operations
Section.

The update looks like a lot of changes: more than 400 lines (according to
rfcdiff) — but I think they are mostly clarifying.  Instead of returning
the document to the WG, I am going to start an IETF Last Call for this
document — it will be extended (4 weeks) to account for the upcoming
meeting in Singapore, US Holidays and to give the WG an opportunity to
re-review.

Thanks!

Alvaro.


...

Major:



M1. The Introduction mentions several types of segments, and it says that
the LDP LSP, RSVP-TE LSP, and BGP LSP segments are “illustrated in
[I-D.ietf-spring-segment-routing-mpls]”.  But that is only true for the
first two, for which examples are shown.  Where are these segment types
defined?  The definition, and not the examples, is the Major issue here.
This document being the main architecture document should include the
complete description.  BTW, the list is only about the “MPLS
instantiation”, are there similar types of segments for IP?



[Les:] The list has been modified – but some definitions will still be
found in [I-D.ietf-spring-segment-routing-mpls] where it makes sense to do
so. We prefer that so that we do not duplicate definitions.

Ok — I would have preferred the definitions to show up here, but it’s ok,
as long at they are defined somewhere.

I went to look at the most recent version
of I-D.ietf-spring-segment-routing-mpls (-11), but there’s no definition of
those segments.   :-(I’ll take a look at that document and see if
they’re needed.



M2. From Section 2. (Terminology): “Using the same SRGB on all nodes within
the SR domain ease operations and troubleshooting and is expected to be a
deployment guideline.”  It is “expected to be a deployment guideline”
where/when??  Given that this document is the general architecture, I
figured that maybe draft-ietf-spring-segment-routing-mpls contained that
deployment recommendation, but all that document says is: “As described in
[I-D.ietf-spring-segment-routing], using the same SRGB on all nodes within
the SR domain eases operations and troubleshooting and is expected to be a
deployment guideline.”  So…where are the Deployment/Operational
considerations related to the SRGB?  I note that neither document
(draft-ietf-spring-segment-routing or
draft-ietf-spring-segment-routing-mpls) include them.  I would expect some
information to be in this (general) document and other more specific
information (like the considerations about using the same SRGB) to be in
the more specific document (draft-ietf-spring-segment-routing-mpls, in this
case).



[Les:] Definition of the SRGB has been enhanced and the definition of an SR
Domain has been introduced and discussed. We hope this clarifies deployment
considerations as regards SRGB/SRLB.

SR Domain was already defined — the difference seems to be the somewhat
nebulous new text:

   Segment Routing Domain (SR Domain)...If multiple protocol instances are
   deployed, the SR domain most commonly includes all of the protocol
   instances in a single SR domain.  However, some deployments may wish
   to sub-divide the network into multiple SR domains, each of which
   includes one or more protocol instances.  It is expected that all
   nodes in an SR Domain are managed by the same administrative entity.

…which makes the definition depend on itself: "SR domain most commonly
includes all of the protocol instances in a single SR domain” (the domain
includes all the instances in the domain)…

Note that one of the point above was the lack of Deployment/Operational
Considerations in this document — the added text above opens the door even
more for such considerations: when would someone decide to sub-divide the
network into multiple domains?  What might the considerations be?

As for the SRGB definition, you did take out the part about “using the same
SRGB…is expected to be a deployment guideline” and changed it to it being
“strongly recommended”.  I still have the same question as before: what are
the Deployment/Operational considerations related to the SRGB?  You did
keep the text about how it “eases operations and troubleshooting”, but
didn’t provide guidance related on when/why.

BTW, 3.1.2 says that "Where possible, it is recommended that a consistent
SRGB be configured on all nodes in an SR Domain.” — I’m assuming
“consistent” is the same as “the same”...

In 

Re: [spring] AD Review of draft-ietf-spring-segment-routing-12

[Alvaro Retana]

Dear authors:

 

Hi!

 

It’s been 2 months since I sent out this review and I still haven’t heard 
anything back (not even an ACK!) from you.  What is the plan to address the 
comments and move this work forward?

 

Thanks!

 

Alvaro.

 

From: spring <spring-boun...@ietf.org> on behalf of Alvaro Retana 
<aret...@cisco.com>
Date: Thursday, August 10, 2017 at 3:00 PM
To: "draft-ietf-spring-segment-rout...@ietf.org" 
<draft-ietf-spring-segment-rout...@ietf.org>
Cc: "spring-cha...@ietf.org" <spring-cha...@ietf.org>, "spring@ietf.org" 
<spring@ietf.org>, Martin Vigoureux <martin.vigour...@nokia.com>
Subject: [spring] AD Review of draft-ietf-spring-segment-routing-12

 

Dear authors:

 

I just finished reviewing this document – sorry for the delay in processing.  
Thanks for all the work you’ve but into this document!

 

I have some significant concerns (see below for details).  In general, the 
document presents an incomplete view of the architecture: details about 
important pieces are barely mentioned or not fully described, as is the case of 
the role of a central controller (PCE), and the BGP and Binding Segments.  

 

Also, some of the architectural details are predicated on specific bits defined 
in the extensions, where this document should describe the general operation 
and leave the details (like bit names) to the extensions.  Note that I’m not 
asking that you don’t mention the extensions – pointing to them is fine --, I’m 
asking you to define the functionality in general and not as a function of the 
extensions.  For an example, see point M5.1. below.

 

I will wait for at least the Major comments to be addressed before starting the 
IETF Last Call.

 

Thanks!

 

Alvaro.

 

 

 

Major:

 

M1. The Introduction mentions several types of segments, and it says that the 
LDP LSP, RSVP-TE LSP, and BGP LSP segments are “illustrated in 
[I-D.ietf-spring-segment-routing-mpls]”.  But that is only true for the first 
two, for which examples are shown.  Where are these segment types defined?  The 
definition, and not the examples, is the Major issue here.  This document being 
the main architecture document should include the complete description.  BTW, 
the list is only about the “MPLS instantiation”, are there similar types of 
segments for IP?

 

 

M2. From Section 2. (Terminology): “Using the same SRGB on all nodes within the 
SR domain ease operations and troubleshooting and is expected to be a 
deployment guideline.”  It is “expected to be a deployment guideline” 
where/when??  Given that this document is the general architecture, I figured 
that maybe draft-ietf-spring-segment-routing-mpls contained that deployment 
recommendation, but all that document says is: “As described in 
[I-D.ietf-spring-segment-routing], using the same SRGB on all nodes within the 
SR domain eases operations and troubleshooting and is expected to be a 
deployment guideline.”  So…where are the Deployment/Operational considerations 
related to the SRGB?  I note that neither document 
(draft-ietf-spring-segment-routing or draft-ietf-spring-segment-routing-mpls) 
include them.  I would expect some information to be in this (general) document 
and other more specific information (like the considerations about using the 
same SRGB) to be in the more specific document 
(draft-ietf-spring-segment-routing-mpls, in this case).

 

M2.1.  The example illustrated in Figure 2 would be a great place to 
demonstrate the value of having the same SRGB.  In fact, the text now shows 
things not working and it even warns by saying that “using anycast segment 
without configuring the same SRGB on nodes belonging to the same device group 
may lead to misrouting”, but no explanation of how it should be done the right 
way.

 

 

M3. From Section 2. (Terminology): “…a global segment is represented by a 
globally-unique index.”  

 

M3.1.  I couldn’t find anywhere a discussion about the use of the index.  When 
it is discussed in 3.1.2, it seems to be an understood concept: “A Prefix-SID 
is allocated in the form of an index in the SRGB…”  Even if straightforward, I 
think the concept of the index should be explained (maybe with an example) and 
not assumed.  I again went to look at draft-ietf-spring-segment-routing-mpls, 
but that document just points back to this one: “The notion of indexed global 
segment, defined in [I-D.ietf-spring-segment-routing]…” 

 

M3.2. I assume that “globally-unique index” is really unique to the SR Domain, 
right?  I ask this question because “globally-unique IPv6 address” has a 
different connotation (as in unique world-wide, not just inside a domain).  
Please clarify.

 

M3.3.  Note that the latest version (-10) of 
draft-ietf-spring-segment-routing-mpls introduced the SR Local Block (SRLB) 
which is not defined in this document.  I mention it here because it was 
introduced right after the pointer about the index…

 

 

M4. S

[spring] AD Review of draft-ietf-spring-segment-routing-msdc-05

[Alvaro Retana (aretana)]

Dear authors:

I just finished reading this document.  Thanks for a clear and straight forward 
draft!

I have some comments (see below).  The main one is about the inclusion of hosts 
as defining the source routed path, without them being explicitly called out in 
the draft-ietf-spring-segment-routing.  Knowing that some of the authors 
overlap, please make sure there are no holes in the Architecture.  I will start 
the IETF LC once this item is addressed, and a revised ID is produced do 
address the other comments, as needed.

Thanks!

Alvaro.


Major:

M1. As with draft-ietf-spring-segment-routing-central-epe, it worries me that 
hosts are called out as being able to define the source routed path.  Please 
make sure that the Architecture document has some text about the use of hosts – 
maybe constrained to the case where the hosts can be programmed.  Section 6 
provides some good text for that.


Minor:

P1. “service chain”: please remove to avoid confusion with SFC (same comment as 
for all the SR documents).

P2. References:
- s/rfc3107/draft-ietf-mpls-rfc3107bis
- The references to I-D.ietf-spring-segment-routing-central-epe and rfc7938 
should be Normative.

P3. There are 2 instances of using rfc2119 language, I don’t think that either 
is needed because you’re really paraphrasing other documents.  IOW, I recommend 
you take the Normative language off.

P3.1. Section 4.2.1. (Control Plane): “The implicit-null label in the NLRI 
tells Node10 that it is the penultimate hop and MUST pop the top label…”  This 
is normal MPLS operation, so the MUST is really not introducing anything new, 
just paraphrasing the MPLS architecture.  Instead of the MUST, a reference to 
MPLS would be more than enough.  s/MUST/must

P3.2. Section 11. (Manageability Considerations): “As recommended in 
[I-D.ietf-spring-segment-routing], the same SRGB SHOULD be allocated in all 
nodes…”   The Architecture document doesn’t (yet) make that recommendation 
explicitly, but a pointer to it should be enough.  s/SHOULD/should

P4. Section 4.2.4. (Global BGP Prefix Segment through the fabric): “…a packet 
with top label 16011 received by any node in the fabric…and the label 16011 is 
penultimate-popped at Node10”, or at Node9, right?

P5. Section 4.3: “…and with the BGP-Prefix-SID attribute extension defined in 
this document”; that was not defined in this document.

P6. Section 4.3. (iBGP Labeled Unicast (RFC3107)) contains this text: “AIGP 
metric ([RFC7311]) is likely applied to the BGP-Prefix-SID as part of a 
large-scale multi-domain design such as Seamless MPLS 
[I-D.ietf-mpls-seamless-mpls].“  This paragraph sounds random to me as there is 
no further explanation of the use, impact, advantages, etc.  Neither 
AIGP/Seamless MPLS is mentioned again in the document, nor in 
draft-ietf-idr-bgp-prefix-sid or rfc7938.  Please either expand the 
concepts/use or delete this paragraph.

P7. Section 5. (Applying Segment Routing in the DC with IPv6 dataplane): “Node5 
originates 2001:DB8::5/128 with the attached BGP-Prefix-SID advertising the 
support of the Segment Routing extension header (SRH, 
[I-D.ietf-6man-segment-routing-header])…”   draft-ietf-idr-bgp-prefix-sid says 
nothing explicitly about the BGP-Prefix-SID Attribute advertising support for 
the SRH – maybe it should, but it doesn’t.

NEW>
   Node5 originates 2001:DB8::5/128 with the attached BGP-Prefix-SID
  for IPv6 packets destined to
   segment 2001:DB8::5 ([I-D.ietf-idr-bgp-prefix-sid]).

Instead, put the reference later in the same section where it says “…sending 
IPv6 packets with a SRH extension header…”.


Nits:

N1. s/BGP4/BGP-4

N2. Section 3: “Further in this document…”  A reference to Section 7 would be 
nice.

N3. s/index11)/index11

N4. It would have been nice to illustrate the operation in 4.2.x using IPv6 
addresses.

N5. Throughout most of the document the nodes are referred to as Nodex, but 
there are a couple of places where Torx is used.  Even though these nodes have 
been identified as ToRs, it would be nice to be consistent to avoid confusion.

N6. Section 7: s/problems describe above/problems described above   Also, 
putting a reference back to Section 3 would be nice.

N7. The content in Section 7 is good, and the DC example helps in the 
illustration – but the applicability is not just constrained to it.  It might 
be a good idea to add at note at the start mentioning the broader applicability.

N8. Please avoid using “we”.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring