Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Dhruv Dhody]

Hi Ketan

Thanks for handling the comments. Just a final comment on the
security/manageability considerations that explains my reasoning. I would
let you/shepherd take a call!

This draft describes the SR Policy with a common informational model which
has proven to be quite useful. I would like to see this approach extended
to also capture the security and manageability aspects in a
protocol-agnostic way. The configuration of SR policy, the verification
rules, SR-DB handling, various policies that control active path selection,
are all common and should be listed in this I-D. You could also give clear
requirements for the protocols to build on. There have been cases where the
protocols have differed leading to issues. Having a section in this I-D
that lays out clearly for protocols would be useful. As the work is
distributed across WG, IMHO having a SPRING WG consensus on such a text
would be nice.

Just my 2 paisa :)
Stay Safe!

Thanks!
Dhruv


On Thu, Apr 29, 2021 at 7:40 PM Ketan Talaulikar (ketant) 
wrote:

> Hi Dhruv,
>
>
>
> Please check inline below.
>
>
>
> *From:* Dhruv Dhody 
> *Sent:* 29 April 2021 15:46
> *To:* Ketan Talaulikar (ketant) 
> *Cc:* James Guichard ; spring@ietf.org;
> spring-cha...@ietf.org
> *Subject:* Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy
>
>
>
> Hi Ketan,
>
>
>
> Thanks for the discussion. Sniping to -
>
>
>
>
>
> If a node is identified by multiple addresses, from the point of view of
> the SR policy they would be considered as different nodes, correct?
>
> *[KT] This relates to the computation of SR Policy which is outside the
> scope of this document. There was some text around computation aspects in
> an earlier version of the draft that has been moved into
> draft-filsfils-spring-sr-policy-considerations around the WG adoption time.
> To answer your question, the endpoint address can be mapped to a node which
> becomes the tail-end and then path is computed to that node. In that case,
> multiple addresses may all map to a single node. This would be an
> implementation aspect.*
>
>
>
> [Dhruv]: I was thinking from the SR policy identification point of view,
> i.e.  and  will be
> considered as different SR policies even though H1-IP1 and H1-IP2 belong to
> the same headend H1.
>
> *[KT] Yes, they would be different SR Policies.*
>
>
>
>
> - Section 2.3, What are the 8-bit values for the Protocol-Origin, is there
> an existing registry that is used here? Is it -
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4
> , should it be listed in this document perhaps?
>
> *[KT] These are not code points but suggested default values for the
> Priority assigned to each protocol. An implementation may use a completely
> different scheme and/or make theme configurable. I see that
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2
> 
> does not clearly indicate this and perhaps the authors should clarify that
> the Protocol Origin in that PCEP TLV is used to tweak/signal the Priority
> value to be used for that particular CP in the tiebreaker.*
>
>
>
>
> [Dhruv]: I am referring to this text -
>
>Protocol-Origin of a candidate path is an 8-bit value which
>identifies the component or protocol that originates or signals the
>candidate path.
>
> Which says that an "8-bit value" identifies the protocol as PCEP, BGP,
> etc. What you are describing is the priority associated with the protocol.
> I feel the term "Protocol-Origin" and "Protocol-Origin Priority" is used
> interchangeably, leading to this misunderstanding.
>
> To confirm, in the example - Candidate-path CP1  originator = 100:1.1.1.1, discriminator = 1>. The value 20 identify BGP or
> the Priority value associated with BGP? I am assuming it is the priority!
>
> In which case some cleanup of text is needed to make things clear.
>
> *[KT] I see your point. The use of “priority” and that too inconsistently
> might be the cause for the confusion. Will clean-up the text around this.*
>
>
>
>
> - Section 10, It might be a good idea to acknowledge security
> considerations from the SR policy architecture point of view: how various
> SR policy parameters and attributes could be exploited to make a headend to
> forward the traffic incorrectly. It is better to add details that clearly
> show that the authors/WG have given it a thought and analyzed the
> implications.
>
> *[KT] As a reminder the SR Policy has been introduced in RFC8402 which
> covers these aspects of incorrect routing and other challenges associated
> with source routing. This document is only providing the details of the
> implementation construct/framework for the SR Policy.*
>
>
>
>
>
> [Dhruv]: In my reading, RFC 8402 security considerations are focused on
> the data plane and not much on the interaction between the controller and
> SR nodes where the SR p

[spring] 答复: 答复: Comments on draft-geng-spring-sr-redundancy-protection

[Yangfan (IP Standard)]

Hi Jeffrey,
I add some explanations start with Fan3>>.
BTW, from 1st to 5th May, I will be on Labor Day holiday and may not be 
available to respond in time. ☺
Best regards,
Fan


发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
发送时间: 2021年4月30日 3:06
收件人: Yangfan (IP Standard) ; Rishabh Parekh 

抄送: Gengxuesong (Geng Xuesong) ; Rishabh Parekh 
(riparekh) ; Arvind Venkateswaran (arvvenka) 
; spring@ietf.org
主题: RE: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

Hi Yangfan,

Let me pull up a few points to the top, and respond with zzh4>.


Zzh3> No. Just put the your merging segment after the replication segment. The 
only change to replication segment is that for the replication node, you may 
augment it with the semantics of adding FI/SN. No other changes at all.

Fan2>> Draft-ietf-spring-sr-replication-segment states“Notice that the segment 
on the leaf node is still referred to as a Replication segment for the purpose 
of generalization.” In other word, segment on merging node is always 
replication segment, no way to perform the merging behavior defined in merging 
segment.
Fan3>> I see your point. I will explain it by taking an example. Let’s say we 
have a path starts from A to D, A is redundancy node and D is elimination node. 
In between there are two paths A-B-D and A-C-D.
You were assuming Node B and C are the downstream nodes, followed by 
elimination node D.
I have different thought that D is the downstream node, B and C are not aware 
of any state or capability for redundancy protection, only A and D are aware of 
redundancy protection.
In your design, not only the redundancy node and elimination node are involved, 
the nodes preceding the elimination node on different paths should also be 
involved and further managed by controller. IMHO it is complicated.
Another pending issue here is at the downstream node B or C, the MPLS label or 
IPv6+SRH header is removed, how to concatenate with merging segment is not 
clear for me.

Zzh4> draft-geng has a merging segment defined:
   … two types of
   Segment including Redundancy Segment and Merging Segment are
   introduced.
Zzh4> The discussions in this email thread is only about using/augmenting the 
replication segment for the redundancy segment. It does not replace the merging 
segment. In the redundancy use case, there will be a merging segment after the 
replication segment, and it is the merging segment not the leaf node’s 
replication segment that does the merging.


Fan2>> IMHO SR P2MP policy and Tree-SID is totally unnecessary for redundancy 
protection.  SR P2MP policy is identified by tuple . The two 
parameters are meaningless and inappropriate for redundancy protection service. 
There isn’t a tree or root at all.

Zzh4> In a network that provides redundancy protection, you will likely need 
multiple replication nodes (for traffic from different sources); on each 
replication node, you will likely need different replication behaviors (e.g., 
replicating to different downstream nodes because traffic could be going to 
different destinations).
Zzh4> You will also need to advertise those binding SIDs for the 
replication/redundancy segments, whether they are advertised by routing 
protocols or simply programmed from controllers, so that an upstream node can 
correctly put in a redundancy/replication SID. For that, you will either use a 
control plane identifier (e.g.,  in case of replication 
segment) or simply use the SID itself as the control plane identifier.
Zzh4> So far, separate control plane identifiers are normally used (e.g. prefix 
for a SID, endpoint addresses for a P2P policy, or  for a 
p2mp policy). I assume something similar would be needed for redundancy segment 
if you insist not to reuse/augment the replication segment, but you can see 
that replication segment already provides all you need.
Fan3>> Yes, you are right, in control plane redundancy SID itself is the 
identifier. Similar to replication segment, Redundancy segment is also a 
Binding SID associated to a Redundancy Policy, which is identified through the 
tuple . Different from SR P2MP 
policy, SR policy key structure  and the semantics is 
not changed. The particular color value is used to identify the redundancy ID. 
No separate identifier is imported.

Zzh4> Even if you simply use the SID itself as the control plane identifier, a 
p2mp tree (and its replication segments) can already be set up that way – 
please see 
https://tools.ietf.org/html/draft-ietf-bess-bgp-multicast-controller-06#section-3.3.2.
Fan3>> I admit R-SID itself can be building blocks for a replication use case, 
but the control plane is designed for multicast only. BGP MVPN family may not 
even be used if there is only redundancy protection required.
Zzh4> Talking about the signaling, we only need one sub-tlv added to existing 
replication segment signaling to indicate that FI/SN should be added.
Zzh4> Jeffrey

From: Yangfan (IP Standard) 
mailto:shirley.yang...@hu

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Satoru Matsushima]

Thanks Ketan-san, yes it looks good to me.

Cheers,
--satoru

> On Apr 29, 2021, at 23:14, Ketan Talaulikar (ketant)  wrote:
> 
> 
> Hi Satoru-san,
>  
> Thanks for your review and comment.
>  
> I believe your point is to also cover SRv6 BSID and to that I would propose 
> the following text :
>  
> When the active candidate path has a specified BSID, the SR Policy uses that 
> BSID if this value (label in MPLS, IPv6 address in SRv6) is available (i.e., 
> not associated with any other usage: e.g. to another MPLS client, to another 
> SRv6 client, to another SID, to another SR Policy, outside the range of SRv6 
> Locators).
>  
> Thanks,
> Ketan
>  
> From: spring  On Behalf Of Satoru Matsushima
> Sent: 29 April 2021 18:36
> To: spring-cha...@ietf.org
> Cc: James Guichard ; spring@ietf.org
> Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy
>  
> Hi spring chairs, 
>  
> I think that the document is ready to move forward.
>  
> Here one minor comment is bellow:
>  
> Section 6.2 says on BSID as follow:
>  
>When the active candidate path has a specified BSID, the SR Policy
>uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is
>available (i.e., not associated with any other usage: e.g. to another
>MPLS client, to another SID, to another SR Policy).
>  
> My suggestion for that above text as follow:
>  
>When the active candidate path has a specified BSID, the SR Policy
>uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is
>available (i.e., not associated with any other usage: e.g. to another
>MPLS client, to another SID, to another SR Policy, within the range of 
> locators in SRv6).
>  
> Best regards,
> --satoru
> 
> 
> On Apr 16, 2021, at 3:57, James Guichard  
> wrote:
> 
> 
> Dear WG:
>  
> This email starts a 2 week Working Group Last Call for 
> draft-ietf-spring-segment-routing-policy [1].
>  
> Please read this document if you haven’t read the most recent version and 
> send your comments to the SPRING WG list no later than April 29th 2021.
>  
> If you are raising a point which you expect will be specifically debated on 
> the mailing list, consider using a specific email/thread for this point.
>  
> Lastly, if you are an author or contributors for this document please 
> response to the IPR call in the previous email thread.
>  
> Thanks!
>  
> Jim, Joel & Bruno
>  
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
>  
>  
>  
> ___
> 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

[spring] I-D Action: draft-gandhi-spring-stamp-srpm-06.txt

[internet-drafts]

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   : Performance Measurement Using Simple TWAMP (STAMP) 
for Segment Routing Networks
Authors : Rakesh Gandhi
  Clarence Filsfils
  Daniel Voyer
  Mach(Guoyi) Chen
  Bart Janssens
  Richard Foote
Filename: draft-gandhi-spring-stamp-srpm-06.txt
Pages   : 23
Date: 2021-04-29

Abstract:
   Segment Routing (SR) leverages the source routing paradigm.  SR is
   applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
   (SRv6) data planes.  This document describes procedures for
   Performance Measurement in SR networks using the mechanisms defined
   in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and
   its optional extensions defined in RFC 8972 and further augmented in
   draft-gandhi-ippm-stamp-srpm.  The procedure described is applicable
   to SR-MPLS and SRv6 data planes and is used for both links and end-
   to-end SR paths including SR Policies.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-gandhi-spring-stamp-srpm/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-06
https://datatracker.ietf.org/doc/html/draft-gandhi-spring-stamp-srpm-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-gandhi-spring-stamp-srpm-06


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/


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

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Nandan Saha]

Hi WG, chairs,
 I support the publication of this draft. It's comprehensive and has
implementations that are deployed.

Thanks,
Nandan

On Thu, Apr 15, 2021 at 11:57 AM James Guichard <
james.n.guich...@futurewei.com> wrote:

> Dear WG:
>
>
>
> This email starts a 2 week Working Group Last Call for
> draft-ietf-spring-segment-routing-policy [1].
>
>
>
> Please read this document if you haven’t read the most recent version and
> send your comments to the SPRING WG list no later than April 29th 2021.
>
>
>
> If you are raising a point which you expect will be specifically debated
> on the mailing list, consider using a specific email/thread for this point.
>
>
>
> Lastly, if you are an author or contributors for this document please
> response to the IPR call in the previous email thread.
>
>
>
> Thanks!
>
>
>
> Jim, Joel & Bruno
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
>
>
>
>
>
>
> ___
> 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] 答复: Comments on draft-geng-spring-sr-redundancy-protection

[Jeffrey (Zhaohui) Zhang]

Hi Yangfan,

Let me pull up a few points to the top, and respond with zzh4>.


Zzh3> No. Just put the your merging segment after the replication segment. The 
only change to replication segment is that for the replication node, you may 
augment it with the semantics of adding FI/SN. No other changes at all.

Fan2>> Draft-ietf-spring-sr-replication-segment states“Notice that the segment 
on the leaf node is still referred to as a Replication segment for the purpose 
of generalization.” In other word, segment on merging node is always 
replication segment, no way to perform the merging behavior defined in merging 
segment.

Zzh4> draft-geng has a merging segment defined:
   … two types of
   Segment including Redundancy Segment and Merging Segment are
   introduced.
Zzh4> The discussions in this email thread is only about using/augmenting the 
replication segment for the redundancy segment. It does not replace the merging 
segment. In the redundancy use case, there will be a merging segment after the 
replication segment, and it is the merging segment not the leaf node’s 
replication segment that does the merging.


Fan2>> IMHO SR P2MP policy and Tree-SID is totally unnecessary for redundancy 
protection.  SR P2MP policy is identified by tuple . The two 
parameters are meaningless and inappropriate for redundancy protection service. 
There isn’t a tree or root at all.

Zzh4> In a network that provides redundancy protection, you will likely need 
multiple replication nodes (for traffic from different sources); on each 
replication node, you will likely need different replication behaviors (e.g., 
replicating to different downstream nodes because traffic could be going to 
different destinations).
Zzh4> You will also need to advertise those binding SIDs for the 
replication/redundancy segments, whether they are advertised by routing 
protocols or simply programmed from controllers, so that an upstream node can 
correctly put in a redundancy/replication SID. For that, you will either use a 
control plane identifier (e.g.,  in case of replication 
segment) or simply use the SID itself as the control plane identifier.
Zzh4> So far, separate control plane identifiers are normally used (e.g. prefix 
for a SID, endpoint addresses for a P2P policy, or  for a 
p2mp policy). I assume something similar would be needed for redundancy segment 
if you insist not to reuse/augment the replication segment, but you can see 
that replication segment already provides all you need.
Zzh4> Even if you simply use the SID itself as the control plane identifier, a 
p2mp tree (and its replication segments) can already be set up that way – 
please see 
https://tools.ietf.org/html/draft-ietf-bess-bgp-multicast-controller-06#section-3.3.2.
Zzh4> Talking about the signaling, we only need one sub-tlv added to existing 
replication segment signaling to indicate that FI/SN should be added.
Zzh4> Jeffrey

From: Yangfan (IP Standard) 
Sent: Thursday, April 29, 2021 6:31 AM
To: Jeffrey (Zhaohui) Zhang ; Rishabh Parekh 

Cc: Gengxuesong (Geng Xuesong) ; Rishabh Parekh 
(riparekh) ; Arvind Venkateswaran (arvvenka) 
; spring@ietf.org
Subject: 答复: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

[External Email. Be cautious of content]

Hi Jeffrey,
Please see inline reply starts with Fan2>>.
Regards,
Fan


-邮件原件-
发件人: spring [mailto:spring-boun...@ietf.org] 代表 Jeffrey (Zhaohui) Zhang
发送时间: 2021年3月26日 3:19
收件人: Gengxuesong (Geng Xuesong) 
mailto:gengxues...@huawei.com>>; 
spring@ietf.org; Rishabh Parekh (riparekh) 
mailto:ripar...@cisco.com>>; Arvind Venkateswaran 
(arvvenka) mailto:arvve...@cisco.com>>
主题: [spring] Comments on draft-geng-spring-sr-redundancy-protection



Hi Xuesong, Mach, Fan,

Some comments/questions on the proposal.

1. We don't need an additional "redundancy segment" for the replication 
semantics. Existing "replication segment" 
(draft-ietf-spring-sr-replication-segment) can be used as is, especially for 
the scenario where the original header already carries (FI, SN) information.

--[FY1]: three considerations here:

a). For the scenario you mentioned, that is correct, redundancy segment and 
replication segment share a common behavior of "packet duplication". The 
significant difference between two segments is the behavior of adding FI and 
SN. Unfortunately, there is no application in SRv6 required to carry (FI,SN) 
information in IPv6 header, which results in a more common scenario is where 
the original packet doesn't carry (FI, SN). So the current design of redundancy 
segment is based on this scenario.

 Zzh> Since the presentation talked about scenario where the (FI, SN) 
information is already carried, it is fair to discuss that in my initial 
comments; I understand that you want to focus on the other scenario, and that’s 
fine – see later comments below.

Fan1>> Before we dive into the detailed design, I would like to come back to 
discuss the two scenarios first

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Richard Vallee (rvallee)]

This is an important draft. I have reviewed the draft and believe it is ready 
for publication.

Many thanks for the authors and everyone helping to get that far.

Richard

From: spring  on behalf of James Guichard 

Date: Thursday, April 15, 2021 at 2:57 PM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




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

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Matt Anderson]

After having read the first few revisions awhile back, duly impressed with
the scope, clarity, and utility of the document, I've read the latest draft
and support this document moving to publication.

On Thu, Apr 15, 2021 at 2:57 PM James Guichard <
james.n.guich...@futurewei.com> wrote:

> Dear WG:
>
>
>
> This email starts a 2 week Working Group Last Call for
> draft-ietf-spring-segment-routing-policy [1].
>
>
>
> Please read this document if you haven’t read the most recent version and
> send your comments to the SPRING WG list no later than April 29th 2021.
>
>
>
> If you are raising a point which you expect will be specifically debated
> on the mailing list, consider using a specific email/thread for this point.
>
>
>
> Lastly, if you are an author or contributors for this document please
> response to the IPR call in the previous email thread.
>
>
>
> Thanks!
>
>
>
> Jim, Joel & Bruno
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>


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

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Stone, Andrew (Nokia - CA/Ottawa)]

Looks good to me, thanks Ketan!

Andrew

From: "Ketan Talaulikar (ketant)" 
Date: Thursday, April 29, 2021 at 1:57 AM
To: "Stone, Andrew (Nokia - CA/Ottawa)" , James 
Guichard , "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: RE: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi Andrew,

Thanks for your review and comments.

We can update that text to clarify as below:

When BGP SR Policy is the Protocol-Origin, the BGP process receiving the route 
provides the distinguisher (refer to Section 2.1 of 
[I-D.ietf-idr-segment-routing-te-policy]) as the discriminator.

I’ll also make the clarification on the role of the distinguisher in BGP SRTE 
in the draft-ietf-idr-segment-routing-te-policy of which I am also a co-author.

Thanks,
Ketan

From: spring  On Behalf Of Stone, Andrew (Nokia - 
CA/Ottawa)
Sent: 29 April 2021 11:12
To: James Guichard ; spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hello Chairs, WG and Authors

I think there may need to be a wording adjustment required to the BGP related 
text in section 2.5, for more clarity regarding the use of BGP distinguisher in 
place of discriminator:


   When BGP SR Policy is the Protocol-Origin, it is the distinguisher

   (refer to Section 2.1 of 
[I-D.ietf-idr-segment-routing-te-policy]).

The sentence seems to be focused on the context of a headend node importing SR 
policy from BGP into an SR Policy module, and could be interpreted differently 
(and incorrectly) when applied in the context of a controller defined SR Policy 
which is then injected into BGP. I have spoken to Ketan regarding this, so may 
be updated shortly. (additional clarification in idr document may also come).

Aside from that, I support WGLC adoption. The document describes the behaviour 
and associated contexts within the SR Policy model well, and it’s an important 
draft to have finalized.

Thanks
Andrew

From: spring  on behalf of James Guichard 

Date: Thursday, April 15, 2021 at 2:57 PM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




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

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Kamran Raza (skraza)]

Looking at the latest rev of this important draft, I support the publication of 
it.
Rgds,
--
Kamran

From: spring  on behalf of James Guichard 

Date: Thursday, April 15, 2021 at 2:57 PM
To: spring@ietf.org 
Cc: spring-cha...@ietf.org 
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy
Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




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

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Ketan Talaulikar (ketant)]

Hi Satoru-san,

Thanks for your review and comment.

I believe your point is to also cover SRv6 BSID and to that I would propose the 
following text :

When the active candidate path has a specified BSID, the SR Policy uses that 
BSID if this value (label in MPLS, IPv6 address in SRv6) is available (i.e., 
not associated with any other usage: e.g. to another MPLS client, to another 
SRv6 client, to another SID, to another SR Policy, outside the range of SRv6 
Locators).

Thanks,
Ketan

From: spring  On Behalf Of Satoru Matsushima
Sent: 29 April 2021 18:36
To: spring-cha...@ietf.org
Cc: James Guichard ; spring@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi spring chairs,

I think that the document is ready to move forward.

Here one minor comment is bellow:

Section 6.2 says on BSID as follow:


   When the active candidate path has a specified BSID, the SR Policy

   uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is

   available (i.e., not associated with any other usage: e.g. to another

   MPLS client, to another SID, to another SR Policy).

My suggestion for that above text as follow:


   When the active candidate path has a specified BSID, the SR Policy

   uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is

   available (i.e., not associated with any other usage: e.g. to another

   MPLS client, to another SID, to another SR Policy, within the range of 
locators in SRv6).

Best regards,
--satoru


On Apr 16, 2021, at 3:57, James Guichard 
mailto:james.n.guich...@futurewei.com>> wrote:

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




___
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] WGLC for draft-ietf-spring-segment-routing-policy

[Mike Koldychev (mkoldych)]

I have read the latest version of the document and I believe it is ready for 
publication. The document is very detailed and useful as it allows different 
implementations to follow the same information model for SR Policy.

Thanks,
Mike.

From: spring  On Behalf Of James Guichard
Sent: Thursday, April 15, 2021 2:57 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven't read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




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

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Ketan Talaulikar (ketant)]

Hi Dhruv,

Please check inline below.

From: Dhruv Dhody 
Sent: 29 April 2021 15:46
To: Ketan Talaulikar (ketant) 
Cc: James Guichard ; spring@ietf.org; 
spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi Ketan,

Thanks for the discussion. Sniping to -


If a node is identified by multiple addresses, from the point of view of the SR 
policy they would be considered as different nodes, correct?
[KT] This relates to the computation of SR Policy which is outside the scope of 
this document. There was some text around computation aspects in an earlier 
version of the draft that has been moved into 
draft-filsfils-spring-sr-policy-considerations around the WG adoption time. To 
answer your question, the endpoint address can be mapped to a node which 
becomes the tail-end and then path is computed to that node. In that case, 
multiple addresses may all map to a single node. This would be an 
implementation aspect.

[Dhruv]: I was thinking from the SR policy identification point of view, i.e. 
 and  will be considered as 
different SR policies even though H1-IP1 and H1-IP2 belong to the same headend 
H1.
[KT] Yes, they would be different SR Policies.


- Section 2.3, What are the 8-bit values for the Protocol-Origin, is there an 
existing registry that is used here? Is it - 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4
 , should it be listed in this document perhaps?
[KT] These are not code points but suggested default values for the Priority 
assigned to each protocol. An implementation may use a completely different 
scheme and/or make theme configurable. I see that 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2
 does not clearly indicate this and perhaps the authors should clarify that the 
Protocol Origin in that PCEP TLV is used to tweak/signal the Priority value to 
be used for that particular CP in the tiebreaker.


[Dhruv]: I am referring to this text -

   Protocol-Origin of a candidate path is an 8-bit value which
   identifies the component or protocol that originates or signals the
   candidate path.

Which says that an "8-bit value" identifies the protocol as PCEP, BGP, etc. 
What you are describing is the priority associated with the protocol. I feel 
the term "Protocol-Origin" and "Protocol-Origin Priority" is used 
interchangeably, leading to this misunderstanding.

To confirm, in the example - Candidate-path CP1 . The value 20 identify BGP or the 
Priority value associated with BGP? I am assuming it is the priority!

In which case some cleanup of text is needed to make things clear.
[KT] I see your point. The use of “priority” and that too inconsistently might 
be the cause for the confusion. Will clean-up the text around this.


- Section 10, It might be a good idea to acknowledge security considerations 
from the SR policy architecture point of view: how various SR policy parameters 
and attributes could be exploited to make a headend to forward the traffic 
incorrectly. It is better to add details that clearly show that the authors/WG 
have given it a thought and analyzed the implications.
[KT] As a reminder the SR Policy has been introduced in RFC8402 which covers 
these aspects of incorrect routing and other challenges associated with source 
routing. This document is only providing the details of the implementation 
construct/framework for the SR Policy.


[Dhruv]: In my reading, RFC 8402 security considerations are focused on the 
data plane and not much on the interaction between the controller and SR nodes 
where the SR policy architecture comes in.
[KT] This document does not cover the actual protocols used for interactions 
between controller and routers – that is covered via PCEP and BGP documents.


- Section 11, What is the range of the value for Segment Types? A-Z only? It 
would be good to be clear about this. With A-K already allocated, worth 
thinking if this is too restrictive and not future-proof. Perhaps we could 
think of the value as a string that is currently populated with a single 
alphabetic character.
[KT] String can become freeform. How about A-Z, then AA-AZ … ZA-ZZ – that 
should be a large enough space?

[Dhruv]: That works. Maybe you could add this to the table to clearly indicate 
the range:
L-Z: Unassigned
AA-ZZ: Unassigned
[KT] I’ll try to describe this in the text since the AA-ZZ might not be very 
clear.


Related question: is there a value in putting aside a few of these for 
Experimental Use?
[KT] I don’t think so because these are not signaled in any protocol.


- Since the I-D talks about policy configuration, explicit candidate paths, 
verification, SR-DB, etc. I don't want to add work for the authors but I do 
feel in this case a dedicated manageability consideration section would be 
useful :)
[KT] Good catch. I will add it. It is not much work really since we need to 
point to RFC8402 which introduced the SR Polic

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Satoru Matsushima]

Hi spring chairs, 

I think that the document is ready to move forward.

Here one minor comment is bellow:

Section 6.2 says on BSID as follow:

   When the active candidate path has a specified BSID, the SR Policy
   uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is
   available (i.e., not associated with any other usage: e.g. to another
   MPLS client, to another SID, to another SR Policy).

My suggestion for that above text as follow:

   When the active candidate path has a specified BSID, the SR Policy
   uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is
   available (i.e., not associated with any other usage: e.g. to another
   MPLS client, to another SID, to another SR Policy, within the range of 
locators in SRv6).

Best regards,
--satoru

> On Apr 16, 2021, at 3:57, James Guichard  
> wrote:
> 
> Dear WG:
>  
> This email starts a 2 week Working Group Last Call for 
> draft-ietf-spring-segment-routing-policy [1].
>  
> Please read this document if you haven’t read the most recent version and 
> send your comments to the SPRING WG list no later than April 29th 2021.
>  
> If you are raising a point which you expect will be specifically debated on 
> the mailing list, consider using a specific email/thread for this point.
>  
> Lastly, if you are an author or contributors for this document please 
> response to the IPR call in the previous email thread.
>  
> Thanks!
>  
> Jim, Joel & Bruno
>  
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
>  
>  
>  
> ___
> 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

[spring] 答复: 答复: Comments on draft-geng-spring-sr-redundancy-protection

[Yangfan (IP Standard)]

Hi Jeffrey,
Please see inline reply starts with Fan2>>.
Regards,
Fan


-邮件原件-
发件人: spring [mailto:spring-boun...@ietf.org] 代表 Jeffrey (Zhaohui) Zhang
发送时间: 2021年3月26日 3:19
收件人: Gengxuesong (Geng Xuesong) 
mailto:gengxues...@huawei.com>>; 
spring@ietf.org; Rishabh Parekh (riparekh) 
mailto:ripar...@cisco.com>>; Arvind Venkateswaran 
(arvvenka) mailto:arvve...@cisco.com>>
主题: [spring] Comments on draft-geng-spring-sr-redundancy-protection



Hi Xuesong, Mach, Fan,

Some comments/questions on the proposal.

1. We don't need an additional "redundancy segment" for the replication 
semantics. Existing "replication segment" 
(draft-ietf-spring-sr-replication-segment) can be used as is, especially for 
the scenario where the original header already carries (FI, SN) information.

--[FY1]: three considerations here:

a). For the scenario you mentioned, that is correct, redundancy segment and 
replication segment share a common behavior of "packet duplication". The 
significant difference between two segments is the behavior of adding FI and 
SN. Unfortunately, there is no application in SRv6 required to carry (FI,SN) 
information in IPv6 header, which results in a more common scenario is where 
the original packet doesn't carry (FI, SN). So the current design of redundancy 
segment is based on this scenario.

 Zzh> Since the presentation talked about scenario where the (FI, SN) 
information is already carried, it is fair to discuss that in my initial 
comments; I understand that you want to focus on the other scenario, and that’s 
fine – see later comments below.

Fan1>> Before we dive into the detailed design, I would like to come back to 
discuss the two scenarios first. Before the traffic is about to be replicated,  
we name scenario 1 is the traffic has Flow Identification (FI) already:

In this case, FI could be carried either as IPv6 Flow Label in IPv6 basic 
header or in other EH TLVs. RFC6437 specifies the usage of Flow Label for 
stateless load distribution, and many existing implementations follow. Since 
redundancy protection and ECMP can be needed in the network at the same time,  
flow label is not possible to act with two semantics unless RFC6437 is 
extended. In other word, at present flow label cannot be used to carry FI for 
redundancy protection.

To carry FI in IPv6 EH TLVs, currently there is no RFC specifies it or similar 
idea. It is just based on imagination. The only reason I can understand is that 
controller has already recognized this flow to perform redundancy protection 
somewhere, but the replication is not planned to happen at headend. So it 
assigns FI at the headend in SRv6 policy together with SID list.  The potential 
reason could be the headend does not have branches itself, SID list represents 
an E2E path for the service, but the multiple redundant paths only exist as a 
subnet of the entire service path, or bandwidth saving in network. If it is the 
case, it just means two choices to assign FI, either at headend or redundancy 
node. Under this circumstance, we should discuss which place is better to mark 
FI into packet. In the draft, we insist on adding FI at redundancy node, as FI 
is not necessarily to be globally managed. So it comes back to the second 
scenario- there is no FI in packet. All in all, there is only one scenario, 
where FI is to be encapsulated at the redundancy node, not before.

I didn’t put SN here, because actually FI and SN are different. It is 
reasonable to assign FI from controller, as FI is flow-based parameter. But SN 
should be encapsulated on the endpoint itself as it is a packet-based 
parameter. Based on this, I am afraid no one will choose to assign FI at 
headend, then separately add SN and replicate packet at the redundancy node.

Thus, for redundancy protection, both (FI,SN) adding and packet replication 
should be included in the endpoint behavior of redundancy segment.

Zzh3> In the above long paragraphs you explain why you think it is better to 
add FI/SN at the replication node. Even in the case where the (FI,SN) is added 
at the replication node, using replication segment augmented with semantics of 
adding (FI,SN) still works well.

Fan2>> No problem. It is important to understand the actual scenario, so that 
redundancy protection can be properly designed based on correct assumptions .

Zzh3> As for whether it is desired to add FI/SN at the headend, I would say 
there are certainly good reasons to do so, but I will defer that to a separate 
discussion.

Fan2>> Sure, expect to start this topic.

Fan>> I read the draft of replication segment, and have two questions if 
replication segment is used in redundancy protection.

1) I believe merging node should be as the downstream node, since the nodes in 
precedence of merging node should not be redundancy protection aware. In this 
case, there will be at least two identical downstream nodes. In replication 
segment, there is no definition of such a situa

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Dhruv Dhody]

Hi Ketan,

Thanks for the discussion. Sniping to -


>
>
> If a node is identified by multiple addresses, from the point of view of
> the SR policy they would be considered as different nodes, correct?
>
> *[KT] This relates to the computation of SR Policy which is outside the
> scope of this document. There was some text around computation aspects in
> an earlier version of the draft that has been moved into
> draft-filsfils-spring-sr-policy-considerations around the WG adoption time.
> To answer your question, the endpoint address can be mapped to a node which
> becomes the tail-end and then path is computed to that node. In that case,
> multiple addresses may all map to a single node. This would be an
> implementation aspect.*
>

[Dhruv]: I was thinking from the SR policy identification point of view,
i.e.  and  will be
considered as different SR policies even though H1-IP1 and H1-IP2 belong to
the same headend H1.


> - Section 2.3, What are the 8-bit values for the Protocol-Origin, is
> there an existing registry that is used here? Is it -
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4
> , should it be listed in this document perhaps?
>
> *[KT] These are not code points but suggested default values for the
> Priority assigned to each protocol. An implementation may use a completely
> different scheme and/or make theme configurable. I see that
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2
> 
> does not clearly indicate this and perhaps the authors should clarify that
> the Protocol Origin in that PCEP TLV is used to tweak/signal the Priority
> value to be used for that particular CP in the tiebreaker.*
>
>
>
[Dhruv]: I am referring to this text -

   Protocol-Origin of a candidate path is an 8-bit value which
   identifies the component or protocol that originates or signals the
   candidate path.

Which says that an "8-bit value" identifies the protocol as PCEP, BGP, etc.
What you are describing is the priority associated with the protocol. I
feel the term "Protocol-Origin" and "Protocol-Origin Priority" is used
interchangeably, leading to this misunderstanding.

To confirm, in the example - Candidate-path CP1 . The value 20 identify BGP or
the Priority value associated with BGP? I am assuming it is the priority!

In which case some cleanup of text is needed to make things clear.


>
> - Section 10, It might be a good idea to acknowledge security
> considerations from the SR policy architecture point of view: how various
> SR policy parameters and attributes could be exploited to make a headend to
> forward the traffic incorrectly. It is better to add details that clearly
> show that the authors/WG have given it a thought and analyzed the
> implications.
>
> *[KT] As a reminder the SR Policy has been introduced in RFC8402 which
> covers these aspects of incorrect routing and other challenges associated
> with source routing. This document is only providing the details of the
> implementation construct/framework for the SR Policy.*
>
>
>
[Dhruv]: In my reading, RFC 8402 security considerations are focused on the
data plane and not much on the interaction between the controller and SR
nodes where the SR policy architecture comes in.



> - Section 11, What is the range of the value for Segment Types? A-Z only?
> It would be good to be clear about this. With A-K already allocated, worth
> thinking if this is too restrictive and not future-proof. Perhaps we could
> think of the value as a string that is currently populated with a single
> alphabetic character.
>
> *[KT] String can become freeform. How about A-Z, then AA-AZ … ZA-ZZ – that
> should be a large enough space?*
>
>
[Dhruv]: That works. Maybe you could add this to the table to clearly
indicate the range:
L-Z: Unassigned
AA-ZZ: Unassigned

Related question: is there a value in putting aside a few of these for
Experimental Use?


>
> - Since the I-D talks about policy configuration, explicit candidate
> paths, verification, SR-DB, etc. I don't want to add work for the authors
> but I do feel in this case a dedicated manageability consideration section
> would be useful :)
>
> *[KT] Good catch. I will add it. It is not much work really since we need
> to point to RFC8402 which introduced the SR Policy and an informative
> reference to draft-ietf-spring-sr-policy-yang that the WG is already
> working on.*
>
>
>
[Dhruv]: That helps, but also think in lines of documenting some key
considerations as per
https://datatracker.ietf.org/doc/html/rfc5706#section-2


> Hope the authors and WG find these suggestions useful.
>
> *[KT] Yes, definitely.*
>
>
Thanks!
Dhruv



>
>
> *Thanks,*
>
> *Ketan*
>
> Thanks!
> Dhruv
>
> On Fri, Apr 16, 2021 at 12:27 AM James Guichard <
> james.n.guich...@futurewei.com> wrote:
>
> Dear WG:
>
>
>
> This email starts a 2 week Working Grou

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Ketan Talaulikar (ketant)]

Hi Dhruv,

Thanks for your detail review and great comments/feedback.

Please check inline bellow.

From: spring  On Behalf Of Dhruv Dhody
Sent: 29 April 2021 11:51
To: James Guichard 
Cc: spring@ietf.org; spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi WG, Authors,

Support publication. The document reads well and describes key concepts 
clearly. Just some friendly suggestions for the authors to consider -

- IMHO introduction section should be expanded as it can provide helpful clues 
to new-bees, our published document is not just for the insiders.
[KT] RFC8402 provides the more broader and generalized introduction for SR 
Policy while this document is quite focussed on the details of the 
implementation and steering concepts. I will add some text in the introduction 
to point the reader to RFC8402 for the broader overview.

- Section 2.1, is there any guidance for the IP address for the headend and 
endpoint?
[KT] Nothing specific – especially so it is not construed as being normative. 
Generally, the IP address associated with the endpoint node (e.g. Router ID) 
may be the most appropriate for use or in other cases, the IP address that is 
set as the BGP next-hop for Service Routes may be used. So it is very use-case 
specific.

If a node is identified by multiple addresses, from the point of view of the SR 
policy they would be considered as different nodes, correct?
[KT] This relates to the computation of SR Policy which is outside the scope of 
this document. There was some text around computation aspects in an earlier 
version of the draft that has been moved into 
draft-filsfils-spring-sr-policy-considerations around the WG adoption time. To 
answer your question, the endpoint address can be mapped to a node which 
becomes the tail-end and then path is computed to that node. In that case, 
multiple addresses may all map to a single node. This would be an 
implementation aspect.

- Section 2.1, I am worried that the use of the noun "intent" to describe 
'color'. It does not align with the other use of the term in industry/NMRG. I 
see 'SLA associated with color' in other places. There was a jabber discussion 
in 110, maybe I am in rough here but wanted to reconfirm!
[KT] In this context, intent is the objective and that objective may be for 
carrying traffic to meet a specific SLA. This is conveyed by color. I will try 
to clarify this further in the text.

- Section 2.3, Reference to RFC 8664 for PCEP is wrong here, as  is signalled via draft-ietf-pce-segment-routing-policy-cp instead.
[KT] RFC8664 does specify in its intro that it is for signaling of SR Policy 
CP. However, the ability signal multiple CPs and signaling of color was 
introduced by the draft-ietf-pce-segment-routing-policy-cp. So perhaps we 
should use both references? I will update for the PCEP draft reference where 
appropriate.

- Section 2.3, What are the 8-bit values for the Protocol-Origin, is there an 
existing registry that is used here? Is it - 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4
 , should it be listed in this document perhaps?
[KT] These are not code points but suggested default values for the Priority 
assigned to each protocol. An implementation may use a completely different 
scheme and/or make theme configurable. I see that 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2
 does not clearly indicate this and perhaps the authors should clarify that the 
Protocol Origin in that PCEP TLV is used to tweak/signal the Priority value to 
be used for that particular CP in the tiebreaker.

- Section 2.4, For ASN, maybe add "If 2-byte ASNs are in use, the low-order 16 
bits MUST be used, and the high-order bits MUST be set to zero.". For IPv4 Node 
Address, I would suggest adding the high-order bits MUST be set to zero!
[KT] Ack – will update that.

- Section 2.5, in draft-ietf-pce-segment-routing-policy-cp, no further 
clarification is given about the Discriminator and it simply points to this 
I-D. This draft says it is left for the future for PCEP. Since the I-D says 
tuple  uniquely identifies a 
candidate path; we need to specify clearly how to populate the discriminator 
value in PCEP in this I-D or in PCE WG I-D (it cant be left for the future 
IMHO)!
[KT] I can see that 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2
 does allow for signaling the Discriminator value as part of PCEP TLV. I will 
put an informative reference to that document instead of “future”.

- Section 2.7, we need to say that preference is a 32-bit value (as done for 
other fields).
[KT] Ack

- Section 2.11, why only a SHOULD and not MUST in "Only the active candidate 
path SHOULD be used for forwarding traffic that is being steered onto that 
policy."?
[KT] It is a SHOULD to allow for a non-active or second best CP to be used in 
FRR scenarios – Sec 9.