from:"Chengli \(Cheng Li\)"

Re: [spring] Proposed policy on reporting implementation and interoperability

2022-08-21 Thread Chengli (Cheng Li)

Agree with Adrian and Robert, that is also my understanding of implementation 
status section in a draft.

Copy from Adrian’s first email.

- I support the idea of capturing the implementations status of the SPRING work 
during its development and at the time of publication request.
- I am strongly opposed to retaining that information in published RFCs.
- I support am neutral on idea of continuing to record implementation status 
after publication if there is WG consensus.

Thanks,
Cheng


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Saturday, August 20, 2022 11:54 PM
To: Adrian Farrel 
Cc: SPRING WG List 
Subject: Re: [spring] Proposed policy on reporting implementation and 
interoperability

Hi Adrian,

I 100% agree with you.

However what I understood as "Implementation Section" requirement was as simple 
a one paragraph including URL to an IETF wiki page.

Not actual list of vendors and features supported. That would be highly 
inaccurate the moment it is posted.

Many thx,
Robert

On Sat, Aug 20, 2022 at 1:58 PM Adrian Farrel 
mailto:adr...@olddog.co.uk>> wrote:
Hi Joel,

Thanks for bringing this to the WG for discussion.

As one of the authors of RFC 7942 I want to comment on the idea of including 
this “snapshot” status at the time of publication within the published RFC. I 
think this changes the purpose of collecting the information and making it 
public. It moves from being information that is valuable for assessing the 
status of the work, to something that verges on a marketing statement. In 
particular, companies that are able to get into the RFC reporting their 
implementations will, forever, be named in the RFC as known implementations, 
while other companies (perhaps those who waited for consensus before 
implementing) will be excluded. This seems wrong, and while the text you 
propose to include might make it clear that it is just a snapshot at the time 
of publication, it will still be there as a public record. The IETF is not a 
proxy marketing machine, and this information is not useful for the technical 
content of the RFC.

When we wrote 7942, we thought about this quite a lot. That led us to include:
   Authors are requested to add a note to the RFC Editor at the top of
   this section, advising the Editor to remove the entire section before
   publication, as well as the reference to RFC 7942.
But, at the same time, we described other places this information could be 
stored and updated, if that is what the working group wants to do.
Personally, I don’t think it is the IETF’s job to record implementation status 
after publication of an RFC, as this becomes very loaded and commercially 
sensitive. It could be hard to police, and could become contentious.

So, in summary:
- I support the idea of capturing the implementations status of the SPRING work 
during its development and at the time of publication request.
- I am strongly opposed to retaining that information in published RFCs.
- I support am neutral on idea of continuing to record implementation status 
after publication if there is WG consensus.

Thanks,
Adrian

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Joel Halpern
Sent: 03 August 2022 15:45
To: SPRING WG List mailto:spring@ietf.org>>
Subject: [spring] Proposed policy on reporting implementation and 
interoperability


SPRING WG:

At the suggestion of our AD, the WG Chairs have been discussing whether it 
would be helpful to be more explicit, in I-Ds and RFCs we produce, about the 
announced implementations and known interoperability tests that have occurred.  
If the WG agrees, we would like to institute and post on the WG wiki the 
following policy.  The period for discussion and comment runs until 
9-Sept-2022, to allow for folks who are on summer break:

All I-Ds that reach WG last call shall have an implementation section based on, 
but somewhat more than, that described in RFC 7942 (BCP 205, Improving 
Awareness of Running Code: The Implementation Status Section).  Authors are 
asked to collect information about implementations and include what they can 
find out when that information is available for public disclosure.  Documents 
will not be blocked from publication if the authors fill in the section as 
"none report" when they have made an effort to get information and not been 
able to.

There are a couple of important additions to what is called for in RFC 7942.  
We have confirmed with leadership that these changes are acceptable in terms of 
IETF process:

1) We will retain the implementation status section when the draft is published 
as an RFC.  In order to do so, the section will begin with "this is the 
implementation status as reported to the document editors as of "

2) Each implementation description MUST include either a statement that all 
MUST clauses in the draft / RFC are implemented, or a statement as to which 
ones are not implemented.

3) each implementation description may include reports of

[spring] Can you join the spring meeting?

2022-07-27 Thread Chengli (Cheng Li)

Hi Springers,

I can not join the meeting. Only get the following text in the page. Anyone can 
join the meeting?


"the spring room is still closedalmost ready, just a bit more 
patience...Session scheduled for 27 Jul 2022 at 10:00 PM"

https://wws.conf.meetecho.com/conference/?group=spring

Thanks,
Cheng

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

Re: [spring] SR Policy: per-SL reverse

2021-11-14 Thread Chengli (Cheng Li)

Hi Ketan,

I think you are talking something very important.  Also I think describing this 
use case in an information draft will accelerate the progress.

But I think the key to address this problem is that we should sync up among 
SPRING, IDR and PCE, and even LSR WG.

Like SR policy, we have a architecture draft, and then we have a BGP extension 
draft for it. We also have an PCEP draft for it, but PCEP does not support 
multiple ERO/Path at that time. So everything defined in PCE is about LSP 
level/Candidate path level.

For instance, Path Segment, which is defined for identifying an SR path in data 
plane.  In BGP extension [1],  it is an Segment list level extension, while in 
PCEP, it is an LSP/CP level extension[2][3]. After  Mike proposed Multiple 
ERO/Multiple path draft, I think the all the LSP/CP level PCEP extensions 
should have a chance to sync up with BGP extension or SR policy architecture.

I have not known the difference between Reserved SL and bidirectional path, but 
I think a bidirectional path can have the SID list with reversed order. We can 
have more discuss of the use cases.

Thinking about Mike’s extension is mainly about control plane and the path ID 
will not be used in the packet, and the path segment will be used in the 
packet, I see good chances for us to cooperate.

Again, it is the time to sync up among SPRING, PCE, IDR, LSR and 6MAN WGs.



[1]. 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-segment-04#section-3
[2]. https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-path-segment-04
[3]. https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-08



From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Saturday, November 13, 2021 11:21 AM
To: mkoldych=40cisco@dmarc.ietf.org
Cc: Rakesh Gandhi (rgandhi) ; SPRING WG ; 
Chengli (Cheng Li) 
Subject: Re: [spring] SR Policy: per-SL reverse

Hi Mike,

You are right that the SR Policy architecture draft does not talk about reverse 
SLs. But it also doesn't talk about bidirectional paths or aspects like the use 
of association objects for disjoint paths. At one point in time, some of us (WG 
members) were of the view that these aspects may be covered in the standards 
track draft but such topics were moved out to an informational draft 
draft-filsfils-spring-sr-policy-considerations as these were use-cases.

Specifically on the point of "reverse SL", I think that the term is misleading. 
The SLs in a given SR Policy are always ordered in the forward direction (head 
to tail). This is not being changed. That there is another SR Policy with an SL 
having a reverse order of segment is more of a path computation constraint. 
There is no change or update required for this to the SR Policy architecture.

Today, we already have protocol mechanisms defined for various constraints and 
their use-cases - those again are not covered by the SR Policy architecture 
document (some are in the companion information document that we stopped 
updating at a point).

In summary, there is nothing that I see in this new/proposed work that changes 
what we have in the SR Policy document. Whether we need to start a new document 
(not standards but informational in my view as this is a use-case), I leave it 
to the WG and chairs. My preference would be to incorporate such use-cases in 
the existing informational draft if the WG does want to take up this work.

Thanks,
Ketan


On Sat, 13 Nov 2021 at 07:40, Mike Koldychev (mkoldych) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi SPRING WG,

During the PCE session there was a presentation about signaling per-SL (Segment 
List) reverse paths, see 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-03#section-4.5. 
I received comments to bring this up in the SPRING WG.

In the simplest case, you have two SR Policies in opposite directions, 
something like this:

SR policy POL1 
  Candidate-path CP1
SID-List = 

SR policy POL2 
  Candidate-path CP1
SID-List = 

Where  and  are two segment lists that can be considered “opposites” 
of each other, maybe traversing the same links in reverse, or maybe just the 
same nodes, etc.

However, if the SR Policies have multiple segment lists, it gets more 
complicated:

SR policy POL1 
  Candidate-path CP1
SID-List = 
SID-List = 

SR policy POL2 
  Candidate-path CP1
SID-List = 
SID-List = 

Where  and  are opposites, also  and  are opposites.

REQ 1: It should be possible to express that multiple reverse SLs correspond to 
the same forward SL. For example, if the forward SL is using Node Segment(s) 
with ECMP and reverse SLs use Adjacency Segments to cover multiple ECMP paths 
in reverse.

REQ 2: It should be possible to express that SL 1 is a reverse of SL 2, but SL 
2 is *not* a reverse of SL 1. I.e., not mutually reverse.

REQ 3: Having a set of reverse SL(s) associated to every forward SL is useful 
even if there is no actual SR Policy in the r

Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

2021-10-21 Thread Chengli (Cheng Li)

Hi Gyan,

Sorry I don’t understand the case you mentioned. Could you please provide an 
easy example? How a SID will be shifting in a GSID container?

Respect,
Cheng

From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Gyan Mishra
Sent: Friday, October 22, 2021 6:58 AM
To: Darren Dukes (ddukes) 
Cc: spring@ietf.org; i...@ietf.org
Subject: Re: Typo correction Re: Question from SPRING regarding 
draft-filsfilscheng-spring-srv6-srh-compression

Hi Darren

What Greg is asking is if the SID is a prefix SID End and not adjacency SID 
End.x, so now the common prefix is needed to ECMP steer the flow  to the prefix 
SID which uses the common prefix,  which may in this case be mutated due to 
shifting of SIDs in GSID container.

Kind Regards

Gyan
On Thu, Oct 21, 2021 at 10:18 AM Darren Dukes (ddukes) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Greg,

Your question is not clear to me.
Can you try to restate it with the flavors and behaviors from the draft in 
question?

Darren

On 2021-10-20, 4:15 PM, "ipv6" 
mailto:ipv6-boun...@ietf.org>> wrote:

Hi Brian,
I've got some questions about what you've said:
For that reason, the fact that the bottom 64 bits in the
"address" look funny or change is simply irrelevant. They are
invisible to routing (which is done based on the prefix)
and invisible to neighbor discovery (because it never happens).
As I understand it, what you describe is the case of a strict explicit path 
defined using one of the C-SID compression methods. But I am not sure that your 
conclusion also always applies when it is a loose explicit path specified in 
the compressed Segment List. As all C-SIDs share the same prefix, how routing 
can be done based only on that prefix and not using a part of that "funny" 
bottom 64 bits? And if any part of the bottom 64 bits must be used, how one can 
guarantee that CIDR still works in that domain?

Regards,
Greg

On Mon, Oct 18, 2021 at 9:50 PM Brian E Carpenter 
mailto:brian.e.carpen...@gmail.com>> wrote:
Hi,

After reading a lot of messages, I'm going to offer my considered
opinion as a direct response to Joel's OP.

Firstly, I don't believe that in the end this draft raises any
concerns that are *significantly* different than those raised
when RFC 8986 was in draft. As Ted Hardie mentioned, section 5
of RFC 8754 explains that SIDs of any shape or size are only
meaningful within an SR domain. That applies to srh-compression
too.

Secondly, I was concerned about how these strange looking
"addresses" would potentially interfere with normal IPv6
addresses and their handling by normal IPv6 nodes. Well, I
now believe that they won't. The reason is that in the SR model
these "addresses" are *never used for final delivery of IPv6
packets to a host.* All SRv6 participants are routers. The
last hop for a packet whose DA is set to (say) 2001:db8:a:1900::
is *not* the last hop on a LAN, mediated by neighbor discovery
for 2001:db8:a:1900::. It's just a hop from one router to another,
using the entry for 2001:db8:a:1900::/64 in the FIB of the last
router that actually forwards the packet. 2001:db8:a:1900:: is
not assigned to a physical interface so RFC 4861 is never invoked.

Another way to say it is RFC 7608 is the relevant architectural
standard. CIDR rules, even within an SR domain.

For that reason, the fact that the bottom 64 bits in the
"address" look funny or change is simply irrelevant. They are
invisible to routing (which is done based on the prefix)
and invisible to neighbor discovery (because it never happens).

I apologise if this is all obvious to everybody, but I needed
to spell it out for my own understanding.

Now back to Joel's questions:

On 13-Oct-21 20:37, Joel M. Halpern wrote:
> There is a typo in the below which if not understood as a typo would be

> quite confusing.   I wrote that I raised the issue with
> "with the Internet ADs and SPRING chairs".
> That should have read "with the Internet ADs and 6man chairs".
> The SPRING co-chairs are recused, and the charter requirement leads to
> the 6man chairs.  Which is who I talked to.
>
> Also, I am sending a courtesy copy to the routing ADs, which I should
> have done originally.
>
> Thank you and enjoy.
> Yours,
> Joel
>
> On 10/12/2021 11:52 PM, Joel M. Halpern wrote:
>> The SPRING working group is in the midst of an adoption call on
>> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/.
>>
>>
>> The SPRING charter has text that is explicit that modifications to data
>> planes and architectures standardized by other working groups may not be
>> modified in SPRING unless the chairs and ADs responsible for that data

>> plane and / or architecture agree.
>>
>> To complete the context, as my SPRING co-chairs are co-authors on the
>> document in question, they have recused themselves from decisional
>> activities regarding the document.  Therefore, this message is coming
>> just from my as the responsible SPRING co-chair managing this adoption

>> call.
>>
>> As

[spring] 答复: RE： WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

2021-10-13 Thread Chengli (Cheng Li)

Hi Gyan,

Sorry for the late reply. Thank you for reading the draft so carefully, really
appreciated. But I will recommend you to split the comments into small emails
so that we can discuss easily. LOL.
Regarding the illustrations, yes, it can be added later on. And also Francois
provides the example already, please refer to it.

Like you quote from the draft, REPLACE-CSID and NEXT-CSID can supported both
the 16-bit and 32-bit solution, but from the considerations of trade-off of
better compression and easy operation, NEXT-CSID recommends 16-bit and
REPLACE-CSID recommends 32-bit. From the text, you also can see using the
common design of GIB/LIB, both flavors can support 16-bit solution.

From the section 4 in the draft
https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-compression#section-4,
it also states that

It is recommended for ease of operation that a single compressed
encoding flavor be used in a given SRv6 domain. However, in a multi-
domain deployment, different flavors can be used in different
domains.

so we should avoid to mix different length of CSIDs in a single container,
though we can do it.

Thanks,
Cheng

发件人: Gyan Mishra [mailto:hayabusa...@gmail.com]
发送时间: 2021年10月11日 4:23
收件人: Chengli (Cheng Li) ; Francois Clad (fclad)

抄送: James Guichard ; SPRING WG
; Yisong Liu ; spring-chairs

主题: Re: [spring] RE： WG Adoption call for
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Hi Francois, Chengli & authors

Many Thanks for your feedback to the WG on the critical topic interoperability
of the uSID micro-sid 16 bit uSID “NF=Locator/Function combo” 128 bit
container based solution and the G-SRV6 32 bit G-SID “NF=Locator/Function
combo” 4 - 32 bit G-SID in 128 bit container based solution defined as Next and
Replace flavors in the draft.

I am really concerned as to how the next and replace interoperability would
work for adjacent nodes using SID within same or adjacent container.

Section 6.1 mentions that Next flavor recommendation is for 16 bit as the uSID
draft & this draft NF as 16 bit is most optimal uSID size within the uSID
container and Replace flavor recommendation is for 16 bit as the G-SRV6 draft &
this draft NF as 32 bit G-SID is most optimal G-SID size within the G-SID
container.

Please elaborate on this in more detail, as with this draft for next and
replace interoperability, following the SRv6 compression requirements for
optimal hardware forwarding and state efficiency that Next would be recommended
to use 16 bit SID and Replace would be recommended 32 bit SID. Please
elaborate in detail as to why 16 bit is not recommended for replace flavor and
32 bit is not recommended for next flavor for all of the requirements drafts
list of SRv6 compression requirements each one by one and the problems
encountered when not using the recommended SID length.

Thus for next and replace flavor interoperability even possible to work would
require two different SID sizes within the same container interoperability
caveats and now you have to deal with uSID container style using 16 bit SID and
G-SID container style using 32 bit SID.

From the requirements draft, interoperability perspective, the primary
objective is “encapsulation header compression” as that is what we have spent
over a year on with DT finding an optimal compression solution. So here the
lowest common denominator ends up being 32 bit SID and we now have failed the
primary objective of a compression solution.

As far as lowest common denominator is it true that in order to meet all the
requirements draft list of all SRv6 compression requirements both next and
replace have to revert to that lowest common denominator which is 32 bit SID.
If that is true, unfortunately that makes the draft fail the primary objective
of any SRv6 compression solution.

To that end as far as interoperability on Next and Replace interoperability
being the hinge pin of this drafts adoption, as well even if the authors state
that Replace can use 16 bit SID as a possibility, as the 32 bit “NF” G-SID is
recommended for hardware forwarding efficiency and scalability that if 16 bit
were used G-SID would fail the hardware forwarding efficiency and scalability
requirements as well as possibly other requirements which should also be stated
in the draft.

6.1<https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-compression-02#section-6.1>.
C-SID Length

The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A

C-SID length of 16-bit is recommended.

The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths.

A C-SID length of 32-bit is recommended.

The draft should mention the recommendation for common block length for
interoperability. The only block size possible is 48 bit so block size so that
would be a major addressing inflexibility for inter

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

2021-10-13 Thread Chengli (Cheng Li)

Hi SPRING，

Sorry for the late response due to the National days break. It seems like I 
miss a lot of discussion, and it did cost me a lot of time to read all the 
threads.

As a member of the design team, and a person who participates in IETF SR 
standards for a long time,  I know who how difficult for us to get here. Many 
thanks for the contributions from anyone.

From the outputs of DT team, we know that CSID meets all the requirements and 
provide the best performance. As an author of CSID draft, I can say that over 
10 vendors have implemented CSID, which proves that CSID has been adopted by 
the industry very well. Therefore, no matter from the aspect of rough consensus 
and running code, I do think we should adopt CSID and it is the right way for 
sure. Also, from many polls in the mailing list, we also see the consensus of 
using CSID as the basis of SRv6 compression standard.

Till now, many our customers have chosen the CSID as the SRv6 compression 
solution, and some inter-op test and trial deployment have been finished even 
one year ago in CMCC’s lab and live network, and we will have more product 
network deployments in the near future. It proves that CSID can work very well 
in the product network. Many thanks for the customers and partners who choose 
CSID in their networks and products.

There may be some issues discussed in the mailing list, that is good! It also 
proves that people are interested in the topic as well, we are very welcome 
anyone to make the contributions to the solution, and let’s do it together to 
produce a good solution for the industry, that is what we are doing all the 
long way. Therefore, also thanks to the people provide comments in the mailing 
list. Will reply to the mailing list to answer the questions ASAP.

At the end, as an author, the member of the design team, and a person who focus 
on SR standards for a long time, I strongly support the CSID adoption.

Respect,
Cheng



发件人: spring [mailto:spring-boun...@ietf.org] 代表 James Guichard
发送时间: 2021年10月1日 22:05
收件人: SPRING WG 
抄送: spring-cha...@ietf.org
主题: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

The apparent inclination of the working group is to use 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


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

Re: [spring] [Spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

2021-09-28 Thread Chengli (Cheng Li)

Hi Gyan,

Many thanks for your comments. Please see my reply inline.

However, I have not answer all the comments yet. I think it will be better to 
separate the comments into different threads, and we can address them one by 
one.
Again! Thank you for your comments!

Respect,
Cheng



From: Gyan Mishra [mailto:hayabusa...@gmail.com]
Sent: Tuesday, September 28, 2021 5:04 AM
To: SPRING WG ; spring-cha...@ietf.org; j00406941 
; draft-ietf-spring-mpls-path-segm...@ietf.org; 
draft-li-spring-srv6-path-segm...@ietf.org
Subject: RE: [Spring] WGLC for 
https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/


Dear Rakesh & Authors
I replied during WGLC on July 29th supporting publication of this draft, but 
did not hear back from the authors.
I have since added some additional comments in this email related to this 
SR-MPLS draft as well as other Path Segment related drafts and how they 
reference each other as normative references as well as how each of the drafts 
help explain the entire path segment solution and how  SR-MPLS and SRv6 path 
segment solutions related to the extensions for PCE and SR policy updates.

This draft can be very useful for operators and provides an RSVP-TE record 
route style function in a new Path SID that can be leveraged for IOAM PM use 
case as well as BIDIR path association and 1+1 protection solution.

As all of these drafts relate to each other from a SR PSID path segment 
perspective I would like to comment on all of the drafts below as it relates to 
this draft WGLC as well as progressing the other drafts listed below also 
provide some synchronization and parity between the drafts:
All 5 drafts as they define the overall SR Path Segment solution, I believe 
they all should have normative mentions of each of the other drafts.  I 
reviewed all 5 drafts and they do except for any noted below.
[Cheng] Many thanks for your support! Yes, Path Segment can be used in many use 
cases like you mentioned. Well, they may not need to cite each other as 
normative reference I think, we need to discuss one by one. The Data plane 
extension drafts of SR-MPLS & SRv6 Path Segment are the basic drafts. They can 
be the normative referred at the control plane drafts like PCE and BGP, that is 
correct, and we believe we did it. If we miss some reference, you are welcome 
to point it out, many thanks for your help! ☺
I think we do not need to make PCE draft as the normative reference of BGP 
extension draft, and vice versa. Because they are not dependencies between 
these two protocol. Informative reference is the correct choice.

SR Path Segment drafts:
SR-MPLS Path Segment
https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment-05

SRv6 Path Segment
https://datatracker.ietf.org/doc/html/draft-li-spring-srv6-path-segment-07
[Cheng] This has been adopted, and become  
draft-ietf-spring-srv6-path-segment


PCE SR extension for PSID path Segment
https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-path-segment-04

PCE SR extension for BIDIR PSID Path Segment
https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path

SR Policy Path Segment
https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-segment

SR MSD as it applied to SR-MPLS & SRv6 Compression & how Path Segment can be 
used to alleviate MSD issues:
Can the Path Segment solution be used to help with MSD issues for both SR-MPLS  
& SRv6 very long strict paths by being able to reference inter-as paths as 
PSID/BSID sub paths instead of the expanded path?
[Cheng] BSID is using for shortening the SID list, while the Path Segment will 
not be used for this. It is an ID space for path associated services.

SR-MPLS Path Segment - WGLC Review:

https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment-05

Recommendation to update the verbiage to state that 1+1 path protection is an 
SR-MPLS specification optimization using PSID solution.

Since PSID can be used for 1+1 path protection my thoughts are that maybe PSID 
can be used to help overall in MSD SID depth issues on the primary active path 
for very long paths to help with SID depth and reduce the size SID path length 
with PSID/BSID nested sub path segments.
PSID could also be stated as an optimization for MSD issues for very long 
strict paths to help in the reduction of the size of the SID list in an SR-TE 
policy to define the path using the BSID/PSID path vector to compress the 
explicit path.  My thoughts are that Sub paths created by PSID/BSID keys can be 
used for inter-as paths across multiple domains, a similar concept of RFC 4736 
lose hop expansion can be used for longer paths to help compress and cutdown on 
the E2E Path containing all the SIDs.  In cases where the intra-as path is very 
long the path can be broken up into PSID/BSID sub paths regions within a 
domain.  I believe this could apply to both SR-MPLS & SRv6 very long E2E strict

Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

2021-09-24 Thread Chengli (Cheng Li)

Hi Bruno and chairs,

Sure. We will do it ASAP, many thanks for your work!

Respect,
Cheng






李呈 Li Cheng
Mobile: +86-15116983550
Email: c...@huawei.com
发件人：bruno.decraene 
收件人：spring 
抄 送：spring-chairs 
时 间：2021-09-25 00:17:10
主 题：Re: [spring] WG Adoption call - 
draft-srcompdt-spring-compression-requirement - 
draft-srcompdt-spring-compression-analysis

Thanks for the review and feedback.

There is a large support to adopt those two drafts.

Authors, please republish the two drafts as 
draft-ietf-spring-compression-requirement/analysis.
And then address the comment as per WG discussions.

Thanks.
--Jim, Bruno & Joel


From:spring [mailto:spring-boun...@ietf.org] On Behalf 
ofbruno.decra...@orange.com
Sent: Tuesday, September 7, 2021 3:13 PM
To: spring@ietf.org
Subject: [spring] WG Adoption call - 
draft-srcompdt-spring-compression-requirement - 
draft-srcompdt-spring-compression-analysis
Dear WG,


The Design Team has produced two documents:
- A requirement document: draft-srcompdt-spring-compression-requirement
- A solution analysis document: draft-srcompdt-spring-compression-analysis

Both have been presented to the WG and triggered some discussions but are still 
individual documents.
We believe it's now time for the WG to consider taking ownership of those two 
documents.
Note that, especially for those two documents, WG adoption does not necessarily 
mean RFC publication in particular if it turns out that the benefit of long 
term archive would not justify the WG and IESG effort to finalize those two 
documents.


This message starts a 2 week WG adoption call, ending September 20th 2021, for:
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis


After review of the document(s) please indicate support (or not) for WG 
adoption of the document(s) to the mailing list.
Please also provide comments/reasons for your support (or lack thereof) as this 
is a stronger way to indicate your (non) support as this is not a vote.

If you are willing to work on the document(s), please state this explicitly. 
This gives the chairs an indication of the energy level of people in the 
working group willing to work on the document.

Thanks!

Jim, Bruno & Joel


_



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.

_Ce
 message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent doncpas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signalera 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

Re: [spring] Conclusion from WG poll on dataplane solution for compressing segment routing over IPv6

2021-09-10 Thread Chengli (Cheng Li)

Hi Chairs,

After a long-time discussion and many contributions have been made to the 
topic,  I believe we have get the point that we should step forward to adopt 
the CSID draft, therefore, I fully agree with the CSID authors' POV.

Many thanks for your work, it MUST be difficult for you :)
But I still believe that we can address the tough tasks very soon as long as we 
can still move forward.

Thank you again for the excellent work and respect,
Cheng



-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Weiqiang Cheng
Sent: Wednesday, September 8, 2021 11:25 AM
To: 'Joel M. Halpern' ; spring@ietf.org
Subject: Re: [spring] Conclusion from WG poll on dataplane solution for 
compressing segment routing over IPv6

Dear Chairs,

Many thanks for your hard working. 

We are happy to see that the CSID draft has significant interest to be adopted 
as a WG document. 

Regarding the dataplane, the authors believe that the CSID draft contains only 
one dataplane solution with two different flavors[1]: NEXT-CSID-FLAVOR and 
REPLACE-CSID-FLAVOR, rather than two dataplane solutions.

Both the flavors are defined based on the SRv6 data plane(one data plane), and 
the SIDs with these two flavors can be encoded in a single SRH just like we can 
encode PSP Flavor SIDs and USD flavor SIDs together in a SRH.

The inter-op test of CSIDs had been done almost one year ago[2], and everything 
was OK. 

Furthermore, the mechanism defined in the draft has been stable and mature.

With the consensus, the authors hope WG can consider to adopt the CSID draft.

Best regards,
Weiqiang
on behalf of CSID authors

[1]. https://datatracker.ietf.org/doc/html/rfc8986#section-4.16
[2].
https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-co
mpression-02#section-11



-邮件原件-
发件人: spring [mailto:spring-boun...@ietf.org] 代表 Joel M. Halpern
发送时间: 2021年9月7日 01:27
收件人: spring@ietf.org
主题: [spring] Conclusion from WG poll on dataplane solution for compressing 
segment routing over IPv6

Our thanks to the working group members for speaking up clearly.  There is a 
rough (quite clear) consensus for standardizing one dataplane solution to 
compressing segment routing over IPv6.

As chairs, there are some related observations we need to make.
There appears to be significant interest in using the framework in the CSID 
draft for addressing the above.

However, before we issue a call for adoption on that, the chairs would like to 
understand how the working group wants to solve a technical problem.  The CSID 
draft contains two dataplane solutions.  The above rough consensus is for one 
dataplane solution.  Does the working group want to choose one?  Do the authors 
want to suggest that one of the two is the one we should standardize, and get 
working group agreement?
Should we adopt the document, with a note indicating the problem, and solve the 
problem afterwards?  (That itself does not solve the problem, it merely kicks 
it down the road.) Do folks see another means to avoid putting the WG in 
conflict with itself?

As a loosely related side node, the chairs will also observe that we do not see 
an obstacle to informational or experimental publication of other solutions, as 
long as there is sufficient energy in the working group to deal with those.  
Also, only documents for which there is at least one implementation will be 
progressed this way.

Thank you,
Bruno, Jim, and Joel

___
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 mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

2021-09-07 Thread Chengli (Cheng Li)

As an co-author, I support the adoption of the documents since they have been 
discussed deeply.

I will suggest to move the requirements to be published as an RFC, since the 
requirements are not solution related. But I do not suggest to move the 
analysis documents to be published as an RFC, since it may depended on all the 
solutions to be standardized. But anyway, it is an another story.

Clearly, I am willing to work on these two documents.

Many thanks for the contributions from anyone!

Respect,
Cheng



From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Tuesday, September 7, 2021 9:13 PM
To: spring@ietf.org
Subject: [spring] WG Adoption call - 
draft-srcompdt-spring-compression-requirement - 
draft-srcompdt-spring-compression-analysis

Dear WG,


The Design Team has produced two documents:
- A requirement document: draft-srcompdt-spring-compression-requirement
- A solution analysis document: draft-srcompdt-spring-compression-analysis

Both have been presented to the WG and triggered some discussions but are still 
individual documents.
We believe it's now time for the WG to consider taking ownership of those two 
documents.
Note that, especially for those two documents, WG adoption does not necessarily 
mean RFC publication in particular if it turns out that the benefit of long 
term archive would not justify the WG and IESG effort to finalize those two 
documents.


This message starts a 2 week WG adoption call, ending September  20th 2021, for:
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis


After review of the document(s) please indicate support (or not) for WG 
adoption of the document(s) to the mailing list.
Please also provide comments/reasons for your support (or lack thereof) as this 
is a stronger way to indicate your (non) support as this is not a vote.

If you are willing to work on the document(s), please state this explicitly. 
This gives the chairs an indication of the energy level of people in the 
working group willing to work on the document.

Thanks!

Jim, Bruno & Joel


_



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] 答复: SRv6 compression

2021-07-27 Thread Chengli (Cheng Li)

Agree, we should pick one solution to be standardized now, to facilitate the 
network deployment.

And I believe the solution is the one that has been implemented by the most 
vendors in the world, which is CSID.

That would help the industry for sure.

Respect,
Cheng



发件人: spring [mailto:spring-boun...@ietf.org] 代表 Rabadan, Jorge (Nokia - 
US/Mountain View)
发送时间: 2021年7月27日 16:54
收件人: Henderickx, Wim (Nokia - BE/Antwerp) ; 
spring@ietf.org
主题: Re: [spring] SRv6 compression

I agree with Wim’s statement that the precedent in NVO3 *could* apply here too: 
pick one solution as Standard’s track RFC, and once it is done, the others 
might be documented as Informational RFCs if they have implementations.

That would help the industry to move forward.

Thanks.
Jorge


From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Henderickx, Wim (Nokia - BE/Antwerp) 
mailto:wim.henderi...@nokia.com>>
Date: Tuesday, July 27, 2021 at 9:11 AM
To: spring@ietf.org 
mailto:spring@ietf.org>>
Subject: [spring] SRv6 compression
Given the design team accomplished the work on providing requirements and 
analysis to compress an SRv6 SID list, I would recommend we pick 1 solution 
similar to what was done in NVO3 (when we discussed GENEVE, GUE, GPE, etc) 
given this has to be implemented in HW..

I hope we can conclude on this asap and move forward on this topic

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

[spring] 答复: SRv6 SID List compression

2021-07-27 Thread Chengli (Cheng Li)

Hi Gyan,

Many thanks for your comments. Yes it is, we finished the work as required,
really difficult.

I do hope the WG can move forward to make the adoption call of the better/best
solution.

As you know, the vendors and operators have made their choice already, over 10
vendors have implemented C-SID and it has been deploying very fast in the
world. We need to standard it ASAP.

And yes, CSID includes mainly two flavors from G-SRv6 and uSID as you pointed
out.

Many thanks,
Cheng

发件人: spring [mailto:spring-boun...@ietf.org] 代表 Gyan Mishra
发送时间: 2021年7月27日 7:51
收件人: Darren Dukes (ddukes)
抄送: SPRING WG
主题: Re: [spring] SRv6 SID List compression

Dear DT,

Excellent work and many thanks to the design team to come provide the detailed
analysis of the 4 proposals and how they match up with the requirements.

From the analysis it does sound like CSID is the choice by the DT.

SRv6 compression & MSD issue is now finally solved! Excellent news!!

Now it’s just a matter of moving forward with CSID Adoption poll.

From the analysis it does not seem there is any draft that is in close 2nd
place or a close call.

From the analysis draft the two drafts that are combined to create CSID -> I
don’t see it on the Spring WG Datatracker?

https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis-02

The following mechanisms are proposed to compress the SRv6 SID list:

o CSID -
[I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc]
- Describes

two new SRv6 SID flavors, a combination of SID flavors from

[I-D.filsfils-spring-net-pgm-extension-srv6-usid]
and

[I-D.cl-spring-generalized-srv6-for-cmpr]

o CRH -
[I-D.bonica-6man-comp-rtg-hdr]
- Requires two new routing

header types and a label mapping technique.

o VSID -
[I-D.decraene-spring-srv6-vlsid]
- Defines a set of SID

behaviors to access smaller SIDs within the SR header.

o UIDSR -
[I-D.mirsky-6man-unified-id-sr]
- Extends the SRH to carry

MPLS labels or IPv6 addresses.

Below 2 drafts are combined to create CSID??

https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-10

https://datatracker.ietf.org/doc/html/draft-cl-spring-generalized-srv6-for-cmpr-03

Kind Regards

Gyan

On Mon, Jul 26, 2021 at 5:53 PM Darren Dukes (ddukes)
mailto:40cisco@dmarc.ietf.org>> wrote:
I’ll paraphrase what I said in the call...

Today the design team presented analysis of proposals to compress an SRv6 SID
list.
They spent a year building the requirements and completing the analysis, in
depth, with unanimous consensus.
The CSID proposal satisfied all the requirements to the largest degree of any
proposal.
That proposal has multiple implementations, and interoperability, noted in the
draft.
That proposal has a large set of SPRING participants working on it already.

The problem of SRv6 SID list compression is solved, CSID is ready for adoption.

I hope we can conclude this, and choose a single proposal for WG adoption.

Darren

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

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347

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

[spring] 答复: SRv6 compression

2021-07-26 Thread Chengli (Cheng Li)

Hi Tony,

Thanks you for your comments!

For sure, our goal is not to deprecate SRv6 but solving the overhead issue of 
SRv6 so that we can use it better.
That is why we made the effort in the past year and even longer. I believe we 
do not need to state the effort we made in the past many years to finish the 
standard work of SRv6. People know that.

IMHO, what we(our customers and over 10 vendor partners) need is an 
SRv6-capatible solution that is built based on the existing SRv6 tech with 
minor update.

Sure, different solution may have their own standard way and I believe this can 
be handled by the WGs. I respect this.

That is also the point of a standards effort.

Thanks,
Cheng






-邮件原件-
发件人: spring [mailto:spring-boun...@ietf.org] 代表 Tony Li
发送时间: 2021年7月27日 3:56
收件人: spring@ietf.org
主题: [spring] SRv6 compression


Hi,

The chairs ask that we opine on the mailing list, so I’m happy to kick things 
off.

As I noted within the WG meeting, my preference is that we deprecate SRv6. 
Compressing it then becomes moot and there is no issue.

Failing that, the WG needs to come to rough consensus on one mechanism.  That 
is the point of a standards effort.

Tony

___
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 https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

2021-07-07 Thread Chengli (Cheng Li)

As an contributor, I support the WGLC.

I am not aware of any IPR related to this document.

Thanks,
Cheng



From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, July 7, 2021 11:49 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WGLC for 
https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-mpls-path-segment [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 July 21st 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 contributor please response to indicate whether 
you know of any undisclosed IPR related to this document.

Thanks!

Jim, Joel & Bruno

[1] https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/




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

Re: [spring] WG Adoption Call for https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

2021-06-21 Thread Chengli (Cheng Li)

Yes, support. The document describes a mature and useful method for PM in SR 
networking.

Thanks,
Cheng





From: James Guichard [mailto:jguic...@futurewei.com]
Sent: Monday, June 7, 2021 8:35 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 as a WG document. In a previous communication (December 16th 2020), the SPRING 
chairs decided not to adopt 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt into the 
WG until its companion document was accepted by the IPPM WG. This has now 
happened and therefore we feel it is now time to revisit the WG adoption of the 
SPRING document.

Due to the lapse of several months since the initial WG adoption call, the 
chairs would like to start another 2-week WG adoption call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt, ending 
June 21st 2021.

After review of the SPRING document please indicate support (or not) for WG 
adoption to the mailing list. Please also provide comments/reasons for that 
support (or lack thereof) as silence will not be considered as consent.

Thanks!

Jim, Joel & Bruno



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

Re: [spring] [Srcomp] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-06.txt

2021-03-29 Thread Chengli (Cheng Li)

Thanks Weiqiang!

Yes, I think the document is mature for WG adoption.  Let's nail it down, and 
then progress the analysis in parallel.

Respect,
Cheng



-Original Message-
From: Srcomp [mailto:srcomp-boun...@ietf.org] On Behalf Of Weiqiang Cheng
Sent: Monday, March 29, 2021 11:56 AM
To: 'SPRING WG List' 
Cc: 'srcomp' ; spring-cha...@ietf.org
Subject: [Srcomp] FW: New Version Notification for 
draft-srcompdt-spring-compression-requirement-06.txt

Hi Group,
There were some comments on section 5.2 of 
draft-srcomdt-spring-compression-requirements-05 which is about the PS or BCP 
Compliance.
Design team had discussed the comments with group chairs. We believe it is 
about an IETF process, not a technical topic. 
So we removed the chapter and generated -06 revision.

So far, DT have resolved all the comments received and believe the draft is 
mature.

We would like to ask for WG Adoption call for draft.

B.R.
Weiqiang Cheng


-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
发送时间: 2021年3月29日 11:36
收件人: Cheng Li; Chongfeng Xie; Darren Dukes; Peng Shaofu; Ron Bonica; Shaofu 
Peng; Weiqiang Cheng; Wim Henderickx
主题: New Version Notification for 
draft-srcompdt-spring-compression-requirement-06.txt


A new version of I-D, draft-srcompdt-spring-compression-requirement-06.txt
has been successfully submitted by Weiqiang Cheng and posted to the
IETF repository.

Name:   draft-srcompdt-spring-compression-requirement
Revision:   06
Title:  Compressed SRv6 SID List Requirements
Document date:  2021-03-29
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-06.txt
Status: 
https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement
Htmlized:   
https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-06
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-srcompdt-spring-compression-requirement-06

Abstract:
   This document specifies requirements for solutions to compress SRv6
   SID lists.


  


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.

The IETF Secretariat





-- 
Srcomp mailing list
src...@ietf.org
https://www.ietf.org/mailman/listinfo/srcomp
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

2021-02-09 Thread Chengli (Cheng Li)

Hi SPRING,

I have read the document and think it is mature and ready to be adopted.

This document describes how to implement SR-based VTN using resource-aware 
SIDs, which is very helpful for people to understand.

I would like to work on it as well!  :)

Thanks to the authors!
Cheng




From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 7:47 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

This message starts a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ ending 
February 10th 2021.

After review of the document please indicate support (or not) for WG adoption 
to the mailing list and if you are willing to work on the document, please 
state this explicitly. This gives the chairs an indication of the energy level 
of people in the working group willing to work on this document. Please also 
provide comments/reasons for your support (or lack thereof) as this is a 
stronger way to indicate your (non) support as this is not a vote.

Thanks!

Jim, Bruno & Joel



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

Re: [spring] IPR call for draft-ietf-spring-nsh-sr

2021-02-09 Thread Chengli (Cheng Li)

I am aware of an IPR that has been disclosed in the system.

Thanks,
Cheng

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Wednesday, February 10, 2021 2:06 AM
To: spring@ietf.org; draft-ietf-spring-nsh...@ietf.org
Subject: [spring] IPR call for draft-ietf-spring-nsh-sr

Hi authors, contributors, WG

Authors of draft-ietf-spring-nsh-sr have asked for WG last call.
In preparation of the WGLC on draft-ietf-spring-nsh-sr [1], this email starts a 
poll for IPR.

If you are aware of IPR that applies to draft-ietf-spring-nsh-sr please respond 
to this email and keep the mailing list in copy.
If you are aware of IPR, please indicate whether it has been disclosed in 
accordance to the IETF IPR rules (detailed are described in RFCs 3979, 4879, 
3669 and 5378).

If you are an *author or contributor* please respond to this email, on the 
SPRING mailing list, regardless of whether or not you're aware of any IPR.
If you are not an author or contributor, please explicitly respond only if 
you're aware of IPR that has not yet been disclosed.

Thanks,
Regards,
Bruno, Jim, Joel

[1] https://tools.ietf.org/html/draft-ietf-spring-nsh-sr

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Monday, November 2, 2020 4:26 PM
To: spring@ietf.org; 
draft-ietf-spring-nsh...@ietf.org
Subject: [spring] draft-ietf-spring-nsh-sr

Hi authors, WG,

Authors of draft-ietf-spring-nsh-sr have asked for WG last call.
Before initiating it, I've done a review of the draft as document shepherd.
Please find below some comments.

---
It's not crystal clear to me what the scope and the goal of the document are.

-  From the abstract, it's an informative description of two 
applications scenarios

-  From section 5, it's a specification of how to integrate NSH and SR.

o   Although it's only really specified for SRv6 and not SR-MPLS.

Please clarify to update the document as needed.

IdNits reports for 2 errors. [1]
  ** Downref: Normative reference to an Informational RFC: RFC 7665

-  Probably the only really normative reference is in the security 
section. Do you think that a reference to RFC8300 could be used instead (8300 
has a large security consideration section)?

-  I noticed that 8300 had the same issue. What was the feedback from 
AD at the time?

  ** There are 4 instances of too long lines in the document, the longest one
 being 82 characters in excess of 72.
Could you please correct in the next version of the draft?

[1] 
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-spring-nsh-sr-03.txt
-
Abstract

The abstract feels like the document is informational (e.g., This document 
describes two application scenarios")
But the document asks for an IANA allocation requiring a STD track document, so 
the draft needs to be std track.
Do you think that you could add that the document defines the encapsulation of 
NSH for SR-MPLS and SRv6?

The introduction section seems to be coming from the SFC WG.

-  May be adding some text about SPRING?

-  Although this is a personal opinion, I find some sentences a bit 
marketing oriented. Could you please have a look? E.g.

o"The SFC architecture has the merit to not make assumptions"
What about "The SFC architecture does not make assumptions"? This seems more 
neutral.

o"Among all these approaches, the IETF endorsed a transport-independent

- SFC encapsulation scheme: NSH 
[RFC8300]; which is the most mature SFC 
encapsulation solution. »
I'm not sure how much "is the most mature" is true or not. I'm not sure that 
the SPRING WG needs to make such statement nor that it is best placed to make 
such statement.
I'm not sure about "the IETF endorsed a transport-independent  SFC 
encapsulation scheme". Idem with regards to SPRING WG. I'm not sure that this 
is a typical statement in RFC. If so, it feels like the IETF would have equally 
endorsed transport-depending SFC encapsulation scheme. [RFC8595] 
https://tools.ietf.org/html/rfc8595

-  "This design is pragmatic"
Looks like an opinion. Plus I'm not sure that the SPRING WG needs to judge the 
work of the SFC WG.

§2

"The two SR flavors, namely SR-MPLS 
[RFC8660] and SRv6 
[RFC8754],"

May be :s/flavors/data plane

"Further considerations such as simplifying classification at intermediate SFs"
I'm not sure that simplifying classification is the main point of adding NSH. 
RFC8595 does not refers to this. A priori SR supports a single initial 
classification.

§2

"A classifier SHOULD assign an NSH Service Path Identifier (SPI) per

   SR policy so that different traffic flows that use the same NSH

   Service Function Path (SFP) but

Re: [spring] WG Adoption Call Concluded for draft-li-spring-srv6-path-segment-07

2020-11-24 Thread Chengli (Cheng Li)

Many  thanks for Chairs! I am not aware of any IPR disclosures for this 
document.


Thanks,
Cheng


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Tuesday, November 24, 2020 10:57 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call Concluded for 
draft-li-spring-srv6-path-segment-07

Dear WG:

The 3-week WG adoption call for draft 
https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07 has just 
concluded and the chairs agree that enough support was received to approve this 
adoption.

Authors, please resubmit a new document as 
draft-ietf-spring-srv6-path-segment-00. In addition, please indicate whether 
you are aware of any IPR disclosures for this document.

Thanks!

Jim, Joel & Bruno


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

Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment

2020-11-04 Thread Chengli (Cheng Li)

Hi SPRING,

Support as a co-author. SRv6 Path Segment is useful to identify an SRv6 Path, 
so that it can be used in use cases like PM, 1+1 Protection and OAM. I think it 
can be a good basis for Path related services.  Also, comments and 
contributions are welcome!


Many thanks,
Cheng


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, November 4, 2020 1:39 AM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment

Dear WG:

This message starts a 3 week WG adoption call for 
https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, ending 
November 24th 2020. Please note that this document has several changes from 
v-06 that were requested by the SPRING chairs. For this reason, the chairs have 
extended the adoption call for an additional week to allow the WG enough time 
to review these changes before deciding on WG adoption.

After review of the document please indicate support (or not) for WG adoption 
to the mailing list. Please also provide comments/reasons for that support (or 
lack thereof) as silence will not be considered as consent.

Thanks!

Jim, Bruno & Joel





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

Re: [spring] draft-ietf-spring-nsh-sr

2020-11-02 Thread Chengli (Cheng Li)

Agree with Bruno’s comments on section 4.

I think this is more like an Proxy mechanism. Also, I only see NSH over SR-MPLS 
is illustrated in the figure. How about SRv6？

When a packet has to be forwarded to an SF attached to an SFF, the
   SFF performs a lookup on the prefix SID

Prefix SID is only in SR-MPLS. In SRv6, it is a Adj-SID? Or a proxy SID?


   associated with the SF to
   retrieve the next hop context between the SFF and SF (e.g., to
   retrieve the destination MAC address in case native Ethernet
   encapsulation is used between SFF and SF).  How the next hop context
   is populated is out of the scope of this document.

The SFF strips
   the SR information of the packet, updates the SR information, and
   saves it to a cache indexed by the NSH SPI.

It is really like an proxy mechanism. To me, it is a special proxy by using NSH 
as the transport protocol between SFF and SF.
Do we need to define an END.NSH SID or something like this for this?


This saved SR
   information is used to encapsulate and forward the packet(s) coming
   back from the SF.

   When the SF receives the packet, it processes it as usual and sends
   it back to the SFF.  Once the SFF receives this packet, it extracts
   the SR information using the NSH SPI as the index into the cache.
   The SFF then pushes the SR header on top of the NSH header, and
   forwards the packet to the next segment in the segment list.


Best,
Cheng




From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Monday, November 2, 2020 11:26 PM
To: spring@ietf.org; draft-ietf-spring-nsh...@ietf.org
Subject: [spring] draft-ietf-spring-nsh-sr

Hi authors, WG,

Authors of draft-ietf-spring-nsh-sr have asked for WG last call.
Before initiating it, I’ve done a review of the draft as document shepherd.
Please find below some comments.

---
It’s not crystal clear to me what the scope and the goal of the document are.

-  From the abstract, it’s an informative description of two 
applications scenarios

-  From section 5, it’s a specification of how to integrate NSH and SR.

o   Although it’s only really specified for SRv6 and not SR-MPLS.

Please clarify to update the document as needed.


IdNits reports for 2 errors. [1]
  ** Downref: Normative reference to an Informational RFC: RFC 7665

-  Probably the only really normative reference is in the security 
section. Do you think that a reference to RFC8300 could be used instead (8300 
has a large security consideration section)?

-  I noticed that 8300 had the same issue. What was the feedback from 
AD at the time?

  ** There are 4 instances of too long lines in the document, the longest one
 being 82 characters in excess of 72.
Could you please correct in the next version of the draft?

[1] 
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-spring-nsh-sr-03.txt
-
Abstract


The abstract feels like the document is informational (e.g., This document 
describes two application scenarios”)
But the document asks for an IANA allocation requiring a STD track document, so 
the draft needs to be std track.
Do you think that you could add that the document defines the encapsulation of 
NSH for SR-MPLS and SRv6?


The introduction section seems to be coming from the SFC WG.

-  May be adding some text about SPRING?

-  Although this is a personal opinion, I find some sentences a bit 
marketing oriented. Could you please have a look? E.g.

o“The SFC architecture has the merit to not make assumptions”
What about “The SFC architecture does not make assumptions”? This seems more 
neutral.

o“Among all these approaches, the IETF endorsed a transport-independent

- SFC encapsulation scheme: NSH 
[RFC8300]; which is the most mature SFC 
encapsulation solution. >
I’m not sure how much “is the most mature” is true or not. I’m not sure that 
the SPRING WG needs to make such statement nor that it is best placed to make 
such statement.
I’m not sure about “the IETF endorsed a transport-independent  SFC 
encapsulation scheme”. Idem with regards to SPRING WG. I’m not sure that this 
is a typical statement in RFC. If so, it feels like the IETF would have equally 
endorsed transport-depending SFC encapsulation scheme. [RFC8595] 
https://tools.ietf.org/html/rfc8595

-  “This design is pragmatic”
Looks like an opinion. Plus I’m not sure that the SPRING WG needs to judge the 
work of the SFC WG.

§2

“The two SR flavors, namely SR-MPLS 
[RFC8660] and SRv6 
[RFC8754],”

May be :s/flavors/data plane


“Further considerations such as simplifying classification at intermediate SFs”
I’m not sure that simplifying classification is the main point of adding NSH. 
RFC8595 does not refers to this. A priori SR supports a single initial 
classification.



§2

“A classifier

Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03

2020-10-29 Thread Chengli (Cheng Li)

Hi WG,

I have read the document and think this document is useful. Support the 
adoption.

Thanks,
Cheng




From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Thursday, October 22, 2020 8:52 PM
To: spring@ietf.org
Cc: ippm-cha...@ietf.org; spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03

Dear WG:

This message starts a 3 week WG adoption call for 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03, ending November 
12th 2020. Please note that this document has several changes from v-02 that 
were requested by the SPRING and IPPM chairs. For this reason, the chairs have 
extended the adoption call for an additional week to allow the WG enough time 
to review these changes before deciding on WG adoption.

Some background:

Several review comments were received previously for document 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02. The SPRING and 
IPPM chairs considered those comments, and upon review of this version of the 
document, determined the following:


  *   The SPRING document should describe only the procedures relevant to 
SPRING with pointers to non-SPRING document/s that define any extensions. 
Several extensions including Control Code Field Extension for STAMP Messages, 
Loss Measurement Query Message Extensions, Loss Measurement Response Message 
Extensions, Node Address TLV Extensions, and Return Path TLV Extensions were 
included in https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 and 
should be removed from the SPRING document.
  *   The STAMP extensions included in 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 should be 
described in a new document published in the IPPM WG.

These conclusions were discussed with the authors of 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 the result of 
which is the publication of the following two documents:


  *   https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03. The 
subject of this WG adoption call.
  *   https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00. This 
document will be progressed (if determined by the WG) within the IPPM WG.

After review of the SPRING document please indicate support (or not) for WG 
adoption to the mailing list. Please also provide comments/reasons for that 
support (or lack thereof) as silence will not be considered as consent.

Finally, the chairs would like to thank the authors for their efforts in this 
matter.

Thanks!

Jim, Bruno, & Joel
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

2020-10-29 Thread Chengli (Cheng Li)

Hi WG,

Support. However, there are some encoding format changes among versions, hope 
the encoding format can be stable in the following revision ASAP.

Many thanks for the authors' contribution!

Thanks,
Cheng



From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Thursday, October 22, 2020 8:52 PM
To: spring@ietf.org
Cc: ippm-cha...@ietf.org; spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

Dear WG:

This message starts a 3 week WG adoption call for document 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending November 
12th 2020. Please note that this document has several changes from v-10 that 
were requested by the SPRING and IPPM chairs. For this reason, the chairs have 
extended the adoption call for an additional week to allow the WG enough time 
to review these changes before deciding on WG adoption.

Some background:

Several review comments were received previously for document 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and 
IPPM chairs considered those comments, and upon review of this version of the 
document, determined the following:


  *   The SPRING document should describe only the procedures relevant to 
SPRING with pointers to non-SPRING document/s that define any extensions. 
Several extensions including Control Code Field Extension for TWAMP Light 
Messages, Loss Measurement Query Message Extensions, and Loss Measurement 
Response Message Extensions were included in 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and should be 
removed from the SPRING document.
  *   The TWAMP extensions included in 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 should be 
described in a new document published in the IPPM WG.

These conclusions were discussed with the authors of  
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result of 
which is the publication of the following two documents:


  *   https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The 
subject of this WG adoption call.
  *   https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This 
document will be progressed (if determined by the WG) within the IPPM WG.

After review of the SPRING document please indicate support (or not) for WG 
adoption to the mailing list. Please also provide comments/reasons for that 
support (or lack thereof) as silence will not be considered as consent.

Finally, the chairs would like to thank the authors for their efforts in this 
matter.

Thanks!

Jim, Bruno, & Joel





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

Re: [spring] [Idr] questions about draft-ietf-idr-bgpls-srv6-ext-03

2020-09-09 Thread Chengli (Cheng Li)

Hi Ketan and PSF,

Yes, I mean it may be better to add a new section to describe the SRv6 SID 
structure TLV, like section 8, instead of 7.3.

Thanks,
Cheng



From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
Sent: Wednesday, September 9, 2020 3:28 PM
To: ketant=40cisco@dmarc.ietf.org
Cc: Chengli (Cheng Li) ; i...@ietf.org; spring@ietf.org
Subject: Re:[spring] [Idr] questions about draft-ietf-idr-bgpls-srv6-ext-03




Hi Ketan, Cheng,



Thanks for your reply.

I have get clear answer to my questions.

The third question is meaningless once the typo is corrected.



I also suggest that "structure TLV" can not be palced under section 7, as Cheng 
suggested.



Regards,

PSF




原始邮件
发件人：KetanTalaulikar(ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>
收件人：Chengli (Cheng Li) mailto:c...@huawei.com>>;彭少富10053815;
抄送人：i...@ietf.org<mailto:i...@ietf.org> 
mailto:i...@ietf.org>>;spring@ietf.org 
mailto:spring@ietf.org>>;
日 期 ：2020年09月09日 15:07
主 题 ：Re: [spring] [Idr] questions about draft-ietf-idr-bgpls-srv6-ext-03
___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
Hi PSF and Cheng,

Please check inline below.

From: Chengli (Cheng Li) mailto:c...@huawei.com>>
Sent: 07 September 2020 09:49
To: peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>; Ketan Talaulikar 
(ketant) mailto:ket...@cisco.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: [Idr] questions about draft-ietf-idr-bgpls-srv6-ext-03

Hi PSF and Ketan,

IMHO, the SRv6 SID Structure TLV can be included in the sub-TLV field of SRv6 
END.X TLV, SRv6 LAN END.X TLV (for adj SIDs) and SRv6 SID NLRI(for node SIDs). 
So I guess it may be a typo, the SRv6 End should be SRv6 End.X.
[KT] You are correct. It should be End.X and not End. Will fix this typo in the 
next update.

 We can double check the IANA section.

But from the text in Section 7, SRv6 SID attributes,

   This section specifies the new TLVs to be carried in the BGP Link
   State Attribute associated with the BGP-LS SRv6 SID NLRI.

The sub-TLVs defined in this section are associated with the SRv6 SID NLRI, so 
these sub-TLVs are associated with node SIDs.
[KT] This is correct – they are SIDs associated with the node.

Regarding Adj SIDs, the information is included in the Link NLRI. If so, do we 
need to make a new upper level for SRv6 SID Structure sub-TLV? Because it is 
not only apply for node SIDs but also link/adj SIDs.
[KT] I do not understand what you mean by “new upper level for SRv6 SID 
Structure sub-TLV”? Sec 7.3 clearly says how it can be encoded

   It is an optional TLV
   for use in the BGP-LS Attribute for an SRv6 SID NLRI and as an
   optional sub-TLV of the SRv6 End.X, IS-IS SRv6 LAN End.X and OSPFv3
   SRv6 LAN End.X TLVs.
Regarding the second question.  I think,

· an Adj-SID is included in the Link NLRI, with an optional SID 
Structure TLV as a sub-TLV. SRv6 SID NLRI and attributes are not needed to be 
included.
[KT] Correct – we are talking about End.X and LAN End.X here.


· a Node SID is included in the SRv6 SID NLRI, with TLVs like SRv6 
Endpoint Behavior TLV, SRv6 BGP Peer Node SID TLV, SRv6 SID Structure TLV in 
the SRv6 SID attributes to describe the information of the node SID.
[KT] Correct.


[KT] I did not understand the third question from PSF

Thanks,
Ketan

Respect,
Cheng




From: Idr [mailto:idr-boun...@ietf.org]On Behalf Of 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Sent: Monday, September 7, 2020 11:13 AM
To: ket...@cisco.com<mailto:ket...@cisco.com>
Cc: i...@ietf.org<mailto:i...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
Subject: [Idr] questions about draft-ietf-idr-bgpls-srv6-ext-03




Hi Ketan,



I have a question for section 7.3.  SRv6 SID Structure TLV, and hope to get 
your answer.

It described:

SRv6 SID Structure TLV is used to advertise the length of each

   individual part of the SRv6 SID as defined in

   [I-D.ietf-spring-srv6-network-programming].  It is an optional TLV

   for use in the BGP-LS Attribute for an SRv6 SID NLRI and as an

   optional sub-TLV of the SRv6 End, IS-IS SRv6 LAN End.X and OSPFv3

   SRv6 LAN End.X TLVs.  The TLV has the following format:



My question is:

1) Becasue section 7 mentions that "This section specifies the new TLVs to be 
carried in the BGP Link State Attribute associated with the BGP-LS SRv6 SID 
NLRI.",

so, can "structure TLV" be also associated with BGP-LS Link NLRI ?

2) As the description, does it mean that an SRv6 SID NLRI can contain SRv6 SID 
Information TLV for END SID or LAN End.X SID, then "structure TLV" is also 
associated with BGP-LS Link NLRI ?

3) Why the description skip End.X SID ?



Regards,

PSF






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

Re: [spring] [Idr] questions about draft-ietf-idr-bgpls-srv6-ext-03

2020-09-06 Thread Chengli (Cheng Li)

Hi PSF and Ketan,

IMHO, the SRv6 SID Structure TLV can be included in the sub-TLV field of SRv6 
END.X TLV, SRv6 LAN END.X TLV (for adj SIDs) and SRv6 SID NLRI(for node SIDs). 
So I guess it may be a typo, the SRv6 End should be SRv6 End.X.  We can double 
check the IANA section.

But from the text in Section 7, SRv6 SID attributes,

   This section specifies the new TLVs to be carried in the BGP Link
   State Attribute associated with the BGP-LS SRv6 SID NLRI.

The sub-TLVs defined in this section are associated with the SRv6 SID NLRI, so 
these sub-TLVs are associated with node SIDs. Regarding Adj SIDs, the 
information is included in the Link NLRI. If so, do we need to make a new upper 
level for SRv6 SID Structure sub-TLV? Because it is not only apply for node 
SIDs but also link/adj SIDs.



Regarding the second question.  I think,

· an Adj-SID is included in the Link NLRI, with an optional SID 
Structure TLV as a sub-TLV. SRv6 SID NLRI and attributes are not needed to be 
included.

· a Node SID is included in the SRv6 SID NLRI, with TLVs like SRv6 
Endpoint Behavior TLV, SRv6 BGP Peer Node SID TLV, SRv6 SID Structure TLV in 
the SRv6 SID attributes to describe the information of the node SID.



Respect,
Cheng




From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of peng.sha...@zte.com.cn
Sent: Monday, September 7, 2020 11:13 AM
To: ket...@cisco.com
Cc: i...@ietf.org; spring@ietf.org
Subject: [Idr] questions about draft-ietf-idr-bgpls-srv6-ext-03




Hi Ketan,



I have a question for section 7.3.  SRv6 SID Structure TLV, and hope to get 
your answer.

It described:

SRv6 SID Structure TLV is used to advertise the length of each

   individual part of the SRv6 SID as defined in

   [I-D.ietf-spring-srv6-network-programming].  It is an optional TLV

   for use in the BGP-LS Attribute for an SRv6 SID NLRI and as an

   optional sub-TLV of the SRv6 End, IS-IS SRv6 LAN End.X and OSPFv3

   SRv6 LAN End.X TLVs.  The TLV has the following format:



My question is:

1) Becasue section 7 mentions that "This section specifies the new TLVs to be 
carried in the BGP Link State Attribute associated with the BGP-LS SRv6 SID 
NLRI.",

so, can "structure TLV" be also associated with BGP-LS Link NLRI ?

2) As the description, does it mean that an SRv6 SID NLRI can contain SRv6 SID 
Information TLV for END SID or LAN End.X SID, then "structure TLV" is also 
associated with BGP-LS Link NLRI ?

3) Why the description skip End.X SID ?



Regards,

PSF




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

Re: [spring] Spring protection - determining applicability

2020-08-28 Thread Chengli (Cheng Li)

Hi Sasha,

Agree. This is not the topic about to adopt a draft or not. I also support the 
adoption. :)

Regarding the not bypassable flag for prefix SID, thanks for your input. Will 
update the draft after we have enough discussion in the mailing list. Seems 
like we are heading to the same direction, that is wonderful!

Thanks,
Cheng


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Friday, August 28, 2020 3:41 PM
To: Chengli (Cheng Li) ; Alexander Vainshtein 
; Martin Horneffer 
Cc: spring@ietf.org; Robert Raszuk ; 
ext-andrew.als...@liquidtelecom.com ; Shraddha 
Hegde ; Ketan Talaulikar (ketant) 
; Joel M. Halpern 
Subject: Re: [spring] Spring protection - determining applicability

Cheng and all,
A few short comments.


  1.  I support the idea to mark some IGP Prefix SIDs as "not bypassable"
  2.  I think that, while such marking is not yet available  the neighbors of a 
node that advertises itself as a "stub node" in IGP MAY use this as a hint that 
Node SIDs advertised by this node are "not bypassable".
  3.  I do not think that B-flag in the advertisment of Adj-SIDs can be used as 
n indication that it can be bypassed - the current semantics of this flag is 
different.
  4.  At the same time I do not think  that ability to advertise a certain 
Adj-SID as leading to a not bypassable node is needed or would be useful. 
Ability of the operator to exclude acific neighbor from protection would 
suffice, especially in the case of local Adj-SID.
  5.  Last bot not  least, I think that none of the above must be addressed 
befire adoption of the draft as a SPRING WG document.

My 2c,
Sasha

Get Outlook for Android<https://aka.ms/ghei36>


From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Chengli (Cheng Li) mailto:c...@huawei.com>>
Sent: Friday, August 28, 2020, 09:37
To: Alexander Vainshtein; Martin Horneffer
Cc: spring@ietf.org<mailto:spring@ietf.org>; Robert Raszuk; 
ext-andrew.als...@liquidtelecom.com<mailto:ext-andrew.als...@liquidtelecom.com>;
 Shraddha Hegde; Ketan Talaulikar (ketant); Joel M. Halpern
Subject: Re: [spring] Spring protection - determining applicability


Hi Sasha and Martin,

Many thanks for your input. I fully agree with your point of we need to 
consider to advertise the ability of the node to advertise a specific Prefix 
SID it originates as "not eligible for bypass protection".

Also, this extension should be written in a protection document like Martin 
said. We have a strawman draft posed 1 year ago [1], but it has not been 
discussed yet.  The main idea of the draft is to add a no-bypass flag into 
SID(including Prefix SID, and adj-SID). But we are discussing with some experts 
that do we need the No-bypass flag for Adj-SID or not, it seems like we have a 
B flag already.

It is so nice to see this point is raised and discussed. Also, welcome to 
review the document, and hope to have your valuable comments.

Respect,
Cheng

[1]. 
https://tools.ietf.org/html/draft-li-rtgwg-enhanced-ti-lfa-02<https://clicktime.symantec.com/3ANymMuqpegxP1sVdAwdLWH6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-rtgwg-enhanced-ti-lfa-02>


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Tuesday, August 18, 2020 11:44 PM
To: Martin Horneffer mailto:m...@lab.dtag.de>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; Robert Raszuk 
mailto:rob...@raszuk.net>>; 
ext-andrew.als...@liquidtelecom.com<mailto:ext-andrew.als...@liquidtelecom.com> 
mailto:andrew.als...@liquidtelecom.com>>; 
Shraddha Hegde mailto:shrad...@juniper.net>>; Ketan 
Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>; 
Joel M. Halpern mailto:j...@joelhalpern.com>>
Subject: Re: [spring] Spring protection - determining applicability

Martin,
Lots of thanks for an important input to this discussion.

I fully agree with you that ability to turn off the node protection scheme for 
a specific PLR neighbor (i.e., on a specific PLR port) by suitable local 
configuration in the PLR is definitely required. Such an ability would probably 
address most (if not all) scenarios associated with the so-called "service 
nodes" that cannot be bypassed.

I also think that service nodes that cannot be bypassed typically would 
advertise themselves as "stub nodes" in IGP in order to prevent inadvertent 
application of their service function to transit traffic (which could otherwise 
pass thru the service node due to some topology change). Therefore a local 
policy that would exclude IGP neighbors advertising  themselves as stub nodes 
in IGP from the node protection scheme could be also useful.

Last but not least, ability of the node to advertise a specific Prefix SID it 
originates as "not eligible for bypass protection" (e.g., using a new flag in 
the Prefix N

Re: [spring] Spring protection - determining applicability

2020-08-03 Thread Chengli (Cheng Li)

Hi Joel and Mach,

Yes, we should consider to bypass or not bypass the node in different cases.

Like Joel said, we can not skip the firewall, while it can be fine to skip a TE 
node, if the repair path meets the TE SLA requirements.

Regarding these two cases, AFAIK, two documents describes the related mechanisms
* Bypass:  
https://tools.ietf.org/html/draft-chen-bess-srv6-service-bypass-sid-00
* No bypass: https://datatracker.ietf.org/doc/draft-li-rtgwg-enhanced-ti-lfa/

Hope it help the discussion, and comments are welcome! 

Respect,
Cheng



-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Mach Chen
Sent: Monday, August 3, 2020 11:30 AM
To: Joel M. Halpern ; spring@ietf.org
Subject: Re: [spring] Spring protection - determining applicability

Hi Joel,

I think this is a good point that may not be discussed in the past. And I also 
don't think there is a "can be bypassed" indication in the routing 
advertisement for now.

IMHO, the information advertised by routing is neutral, such information (can 
or cannot be bypassed) is more path specific, thus normally the controller 
should be responsible for deciding whether/which SID can be bypassed. 

Best regards,
Mach

> -Original Message-
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Joel M. 
> Halpern
> Sent: Monday, August 3, 2020 7:51 AM
> To: spring@ietf.org
> Subject: [spring] Spring protection - determining applicability
> 
> (WG Chair hat Off, this is merely a note from a slightly confused WG
> participant.)
> 
> I have been reading the various repair drafts, and the various 
> networks programming and service programming draft, and I am trying to 
> figure out one aspect of the combination.
> 
> How does a node that is doing some form of bypass (suppose, for 
> simplicity, it is Node N2 deciding to bypass the next SID for a failed 
> node N3) know that it is safe to do so?
> 
> If the path was just for TE, then it is "safe" if the new path meets 
> the TE criteria.  or maybe it is safe if it is even close, as long as 
> it is not used for too long.
> 
> But what if the node were a Firewall, included to meet legal requirements?
> Or was some other necessary programmatic transform (wince we are 
> deliberately vague about what nodes can do when asked suitably.)
> 
> Is there some "can be bypassed" indication in the routing 
> advertisements that I missed?
> 
> Thank you,
> Yours,
> Joel
> 
> ___
> 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 mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call for draft-raza-spring-srv6-yang

2020-07-14 Thread Chengli (Cheng Li)

Hi SPRING,

Yes I support the document.
YANG model is an important work for SRv6, and the YANG model has reached the 
consensus among vendors and operators, so I support the adoption.

Respect,
C.L


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Tuesday, July 14, 2020 5:52 AM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-raza-spring-srv6-yang

Dear WG:

This email begins a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-raza-spring-srv6-yang/ ending Monday 
27th July 2020.

Please speak up if you support or oppose adopting this document into the WG.. 
Please also provide comments/reasons for that support (or lack thereof). 
Silence will not be considered consent.

Thanks!

Jim, Joel & Bruno





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

Re: [spring] Leadership change

2020-06-14 Thread Chengli (Cheng Li)

Good news to have two  new co-chairs, since there are so many works in SPRING.

Welcome Jim and Joel!  Also, many thanks to Rob for your work and contributions!

Respect!
Cheng





-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Martin Vigoureux
Sent: Monday, June 15, 2020 4:25 AM
To: spring@ietf.org
Cc: 6...@ietf.org; int-...@ietf.org; bruno.decra...@orange.com; 
 ; Rob Shakir ; James 
Guichard ; Joel M. Halpern 

Subject: [spring] Leadership change

WG,

Rob had decided to step down as chair some time ago. There hasn't been any 
formal communication on that so I'd like, first, to thank Rob for his work and 
dedication to the group. Thank you very much Rob.

Since that time, I have been actively looking for one (or two) person(s) to 
replace him. This has proven to be a very challenging endeavour!

But it has finally came to an end.

I am pleased to inform you that I have appointed Jim Guichard and Joel Halpern 
as co-chairs of SPRING WG, alongside Bruno.
Thank you Jim, Thank you Joel, and thank you Bruno.


Martin
as AD for SPRING

___
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] [Idr] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy)

2020-06-01 Thread Chengli (Cheng Li)

Hi Ketan,

Sorry for my delay, I saw the update, and it has addressed my comments, many 
thanks.

Best,
Cheng


From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Monday, May 18, 2020 8:00 PM
To: Robert Raszuk 
Cc: Chengli (Cheng Li) ; 
draft-ietf-spring-segment-routing-pol...@ietf.org; idr wg ; 
SPRING WG ; Fangsheng ; stefano previdi 

Subject: RE: [Idr] Comments: Route Origin Community in SR 
Policy(draft-ietf-spring-segment-routing-policy)

Hi Robert,

You are right that the “Originator” is not used in BGP best path and is just 
for a tie-breaking logic in SRTE between paths from different protocols and 
controllers. I doubt if there is a functional issue here.

I thought that Chengli was bringing in some new/different requirement for the 
“Originator” field for some deployment design. I haven’t seen a 
response/clarification from him as yet, and so perhaps I misunderstood him in 
which case we are ok here.

Thanks,
Ketan

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: 30 April 2020 14:46
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Chengli (Cheng Li) mailto:chengl...@huawei.com>>; 
draft-ietf-spring-segment-routing-pol...@ietf.org<mailto:draft-ietf-spring-segment-routing-pol...@ietf.org>;
 idr wg mailto:i...@ietf.org>>; SPRING WG 
mailto:spring@ietf.org>>; Fangsheng 
mailto:fangsh...@huawei.com>>; stefano previdi 
mailto:stef...@previdi.net>>
Subject: Re: [Idr] Comments: Route Origin Community in SR 
Policy(draft-ietf-spring-segment-routing-policy)

Hi Chengli and Ketan,

Well I think (perhaps to your surprise) the current text is actually correct.

See the overall idea of section 2.4 is not to define the real source of the 
candidate path. That is done in section 2.5 The idea here is to keep multiple 
*paths or versions* of the candidate paths in the local system uniquely.

See if you continue reading section 2.6 demystifies the real objective:


   The tuple  uniquely

   identifies a candidate path.



So the real originator is encoded in discriminator and here it just means the 
peer candidate path was

received from. And if you read on this entire exercise only servers best path 
selection as described in section 2.9.



 the following order until only one valid best path is selected:



   1.  Higher value of Protocol-Origin is selected.



   2.  If specified by configuration, prefer the existing installed

   path.



   3.  Lower value of originator is selected.



   4.  Finally, the higher value of discriminator is selected.

+

  The originator allows an operator to have multiple redundant

  controllers and still maintain a deterministic behaviour over

  which of them are preferred even if they are providing the same

  candidate paths for the same SR policies to the headend.

Thx,
R.

On Thu, Apr 30, 2020 at 10:46 AM Ketan Talaulikar (ketant) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Cheng,

I assume you are recommending the use of Route Origin Extended Community 
(https://tools.ietf.org/html/rfc4360#section-5) for conveying the “Originator” 
when the SR Policy update is propagated over eBGP sessions via other eBGP/iBGP 
sessions instead of direct peering with the headend.

I believe it does address the scenario you describe given that it is expected 
that SR Policy propagation via BGP is happening within a single administrative 
domain even if it comprises of multiple ASes.

Also copying the IDR WG for inputs since this would likely need to be updated 
in draft-ietf-idr-segment-routing-te-policy.

Thanks,
Ketan

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Chengli (Cheng Li)
Sent: 30 April 2020 07:34
To: 
draft-ietf-spring-segment-routing-pol...@ietf.org<mailto:draft-ietf-spring-segment-routing-pol...@ietf.org>
Cc: SPRING WG mailto:spring@ietf.org>>; huruizhao 
mailto:huruiz...@huawei.com>>; Fangsheng 
mailto:fangsh...@huawei.com>>
Subject: [spring] Comments: Route Origin Community in SR 
Policy(draft-ietf-spring-segment-routing-policy)

Hi authors,

In section 2.4 of [draft-ietf-spring-segment-routing-policy-06], introduced how 
the node-address of "Originator of CP(Candidate Path)" is generated when the 
Protocol-Origin is BGP. It says:
“Protocol-Origin is BGP SR Policy, it is provided by the BGP component on 
the headend and is:
 o  the BGP Router ID and ASN of the node/controller signalling the 
candidate path when it has a BGP session to the headend, OR
 o  the BGP Router ID of the eBGP peer signalling the candidate path  along 
with ASN of origin when the signalling is done via one or  more intermediate 
eBGP routers, OR
 o  the BGP Originator ID [RFC4456] and the ASN of the node/controller  
when the signalling is done via one or more route-reflectors over  iBGP 
session.”

In the operator's network, in order to reduce the number of  BGP sessions in 
controller and achieve scalabil

Re: [spring] How SRm6 supports SFC/Segment Endpoint option?

2020-05-26 Thread Chengli (Cheng Li)

Hi Ron,

Thanks for your reply. I think I asked a wrong question, so I change the title 
to be "How SRm6 supports SFC/Segment Endpoint option?"

In Segment endpoint option draft[1], you define PSSI for supporting limited 
Service Chain.
PSSI: Per-Segment Service Instructions, the text is shown below.

"
   SRm6 paths are programmable.  They support several instruction types,
   including Per-Segment Service Instructions (PSSI).  The following are
   examples of PSSIs:
   o  Expose a packet to a firewall policy.
   o  Expose a packet to a sampling policy.
"
I am curious about how can we use PSSI to support Limited Service Chain. As per 
[1], 
"
   PSSI Identifiers identify PSSIs.  They have domain-wide significance.
   When a controller creates a limited service chain, also allocates a
   PSSI Identifier.  It then distributes the following information to
   each node that contributes to the limited service chain:

   o  The PSSI Identifier.
   o  The PSSI that the node should execute when it receives a packet
  that has the PSSI Identifier encoded within it.
"

Q1: How to distribute the PSSI to the nodes on the Service Chain?
Q2: It seems like we have only one PSSI ID for a Service Chain, how to support 
different behaviors at different nodes?  By local configuring the PSSI mapping 
to a specific behavior at node?

You know, I focus on SFC, and my customers want us to provide SFC. I can not 
provide only CRH to them, we need an integrated solution of SFC. 
So it will be much better to know how to support SFC by using CRH and PSSI, it 
will help me and others to evaluate the CRH and SRm6 better. 

Thanks,
Cheng

[1]. https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-07#section-3






-Original Message-
From: Ron Bonica [mailto:rbon...@juniper.net] 
Sent: Monday, May 25, 2020 12:29 PM
To: Chengli (Cheng Li) ; Tom Herbert ; 
Brian E Carpenter 
Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: [spring] How CRH support SFC/Segment Endpoint option?

Cheng,

The CRH doesn't attempt the address SFC. That is beyond the scope or a routing 
header.

  Ron


Juniper Business Use Only

-Original Message-
From: Chengli (Cheng Li) 
Sent: Sunday, May 24, 2020 11:44 PM
To: Ron Bonica ; Tom Herbert ; Brian 
E Carpenter 
Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: [spring] How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]


Hi Ron,

Thank you to share the facts of RFC8200.

Could you please explain how CRH supports SFC by the first Destination Options 
header as you mentioned in you previous email?

Or how to support performing a specific behavior at a specify node along the 
path by using CRH?

You know, when we add an option in the first DOH, it will be processed by all 
the nodes listed in the RH.

Best Regards,
Cheng




-Original Message-
From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Ron Bonica
Sent: Monday, May 25, 2020 11:09 AM
To: Tom Herbert ; Brian E Carpenter 

Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: [spring] How CRH support SFC/Segment Endpoint option?

Folks,

I think that we are all talking past one another. RFC 8200 recommends specific 
ordering of extension headers for a reason.

IPv6 extension header are ordered as follows:

- Headers processed at every node along the delivery path
- Hop-by-hop
- Headers processed at every segment endpoint
- Destination options
- Routing header
- Headers processed at the ultimate destination only
- Fragment header
- Authentication header
- ESP header
- Destination Options header

Note that the Destination Options header is the only extension header that can 
appear twice in a packet. The Destination Options header must immediately 
precede the Routing header or the upper-0layer header.

 If a packet contains a destination options header, a routing header, a 
fragment header, and another destination options header:

- the destination options header that precedes the routing header appears in 
each fragment
- the destination options header that precedes the routing header Is processed 
on each segment endpoint, before the packet is reassembled
- the destination options header that precedes the upper layer header appears 
in the first fragment only
- the destination options header that precedes the upper layer header Is 
processed on the ultimate destination node, after the packet has been 
reassembled

  ROn


Juniper Business Use Only

-Original Message-
From: Tom Herbert 
Sent: Sunday, May 24, 2020 7:56 PM
To: Brian E Carpenter 
Cc: Robert Raszuk ; Ron Bonica ; 
spring@ietf.org; 6man <6...@ietf.org>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]


On

Re: [spring] How CRH support SFC/Segment Endpoint option?

2020-05-24 Thread Chengli (Cheng Li)

Hi Ron,

Thank you to share the facts of RFC8200.

Could you please explain how CRH supports SFC by the first Destination Options 
header as you mentioned in you previous email?

Or how to support performing a specific behavior at a specify node along the 
path by using CRH? 

You know, when we add an option in the first DOH, it will be processed by all 
the nodes listed in the RH. 

Best Regards,
Cheng

-Original Message-
From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Ron Bonica
Sent: Monday, May 25, 2020 11:09 AM
To: Tom Herbert ; Brian E Carpenter 

Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: [spring] How CRH support SFC/Segment Endpoint option?

Folks,

I think that we are all talking past one another. RFC 8200 recommends specific 
ordering of extension headers for a reason.

IPv6 extension header are ordered as follows:

- Headers processed at every node along the delivery path
- Hop-by-hop
- Headers processed at every segment endpoint
- Destination options
- Routing header
- Headers processed at the ultimate destination only
- Fragment header
- Authentication header
- ESP header
- Destination Options header

Note that the Destination Options header is the only extension header that can 
appear twice in a packet. The Destination Options header must immediately 
precede the Routing header or the upper-0layer header.

 If a packet contains a destination options header, a routing header, a 
fragment header, and another destination options header:

- the destination options header that precedes the routing header appears in 
each fragment
- the destination options header that precedes the routing header Is processed 
on each segment endpoint, before the packet is reassembled
- the destination options header that precedes the upper layer header appears 
in the first fragment only
- the destination options header that precedes the upper layer header Is 
processed on the ultimate destination node, after the packet has been 
reassembled

  ROn

Juniper Business Use Only

-Original Message-
From: Tom Herbert 
Sent: Sunday, May 24, 2020 7:56 PM
To: Brian E Carpenter 
Cc: Robert Raszuk ; Ron Bonica ; 
spring@ietf.org; 6man <6...@ietf.org>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

On Sun, May 24, 2020 at 2:51 PM Brian E Carpenter  
wrote:
>
> On 25-May-20 09:08, Tom Herbert wrote:
> > On Sun, May 24, 2020 at 3:23 AM Robert Raszuk  wrote:
> >>
> >> Hi Ron,
> >>
> >> I have one small question on the Destination Option Header you keep 
> >> referencing to carry for example VPN demux instructions.
> >>
> >> As DOH follows Fragment Header it is indeed inspected before CRH.
> >>
> >> So please kindly clarify what is there in the IPv6 packet header which 
> >> would stop each segment endpoint (during the transit over SR anchors)  
> >> which destination is obviously in DA of the arriving packet not to inspect 
> >> DOH and not trying to execute it ?
> >>
> >> If you could please also provide reference to RFC8200 defining it.
> >>
> > Robert,
> >
> > Look at Destination Options before the routing header in RFC8200.
> > These are intended to be processed at every intermediate destination 
> > in the routing header
>
> That intention is not specified in the text, and IMHO cannot be deduced from 
> the text. Hence my comment on draft-bonica-6man-ext-hdr-update.
>
Brian,

I think it can be deduced. Extension headers need to be processed in order, so 
destination options before the routing header must be processed before the 
routing header. If the destination options before the routing were only to be 
processed at the final destination, then we would need to process the routing 
header before processing the destination options in order to determine if the 
destination address is indeed the final destination. More practically, if 
destination options were only to be processed at the final destination then it 
doesn't seem like there would be any material between destination options 
before and those after the routing header (or maybe there was some other intent 
to have two flavors of destination options?)..

I agree that the text could be clarified, It seems like another case of 
potential ambiguity in RFC8200 among the terms destination, destination 
address, final destination, an intermediate destination.
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-herbert-ipv6-update-dest-ops-00__;!!NEt6yMaO-gk!XLLXuigXPE8uDwP4SF5HfRZ1NBlH1w24-GVBjHk_rvCmqCueDLaELLoTDx-wnEK6$
  was an attempt to calirfy this, at least to clarify the significance of a 
modifiable destination option (before the routing header).

Tom

>Brian
>
> > and precede any fragment header.
> >
> > Tom
> >
> >> Keep in mind that in number of networks P routers are also PE routers so 
> >> executing DOH even if CRH

[spring] Reply: RE: How CRH support SFC/Segment Endpoint option?

2020-05-23 Thread Chengli (Cheng Li)

Hi Ron,

Thanks for your reply.

I finally get that CRH only support steering packet along a path.

But I am still curious that how to support a specific function/behavior at the 
specific node by using CRH. Can you please explain that?

Since this is a very basic function we want in the network. SFC needs that, all 
the services needs that if there is any function/service should be performed at 
the middle nodes along the path.

We want to provide an integrated service for our customers, because our 
customers want a integrated solution for providing service, like SFC, VPN, they 
don’t like us to provide a brick that still need to combine with other many 
bricks.

IMHO, when comparing solutions, we should compare the same functionality. So 
could you please provide more info of how CRH supporting services?  It will 
help people to evaluate the CRH, which can help CRH I think.

Thanks,
Cheng









李呈 Cheng Li
Mobile: +86-15116983550
Email: c...@huawei.com<mailto:c...@huawei.com>


From: Ron Bonicamailto:rbon...@juniper.net>>
To: Chengli (Cheng 
Li)mailto:c...@huawei.com>>;6man<6...@ietf.org<mailto:6...@ietf.org>>;springmailto:spring@ietf.org>>
Cc: springmailto:spring@ietf.org>>
Subject: RE: How CRH support SFC/Segment Endpoint option?
Time: 2020-05-24 09:24:55

Cheng,

The CRH is a building block. It has exactly one function. That is, to steer a 
packet along its delivery path.

The CRH does not attempt to deliver parameters or metadata to service function 
instances. It relies on other mechanisms. One possibility is a destination 
options header that precedes the CRH. I am sure that there are other 
mechanisms. CRH should be compatible with all of them.

Personally, I am not an NSH expert. Maybe someone who is can speak up.


  Ron




Juniper Business Use Only
From: Chengli (Cheng Li) 
Sent: Saturday, May 23, 2020 12:59 PM
To: Ron Bonica ; 6man <6...@ietf.org>; spring@ietf.org
Cc: spring@ietf.org
Subject: RE: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

Hi Ron,

Thanks for your reply.

Regarding NSH, are you saying to use CRH as a tunnel transport encapsulation 
between two SFF nodes?
Or we can use a single CRH for steering packet through all the SFF nodes that 
the NSH packet should visit?

Regarding using the first DOH, how to do that without the container design by 
your draft[1]?
Or the same option TLV will bind to different behaviors on different nodes 
according to the node local configuration?

Best,
Cheng


[1]. 
https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04..txt<https://urldefense.com/v3/__https:/tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt__;!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT$>.


From: Ron Bonica [mailto:rbon...@juniper.net]
Sent: Friday, May 22, 2020 10:17 PM
To: Chengli (Cheng Li) mailto:c...@huawei.com>>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>; spring@ietf.org<mailto:spring@ietf.org>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: How CRH support SFC/Segment Endpoint option?

Cheng,

The sole purpose of a Routing header is to steer a packet along a specified 
path to its destination. It shouldn’t attempt to do any more than that.

The CRH does not attempt to deliver service function information to service 
function instances. However, it is compatible with:


  *   The Network Service Header (NSH)
  *   The Destination Options header that precedes the Routing header

Both of these can be used to deliver service function information to service 
function instances.

    
         Ron




Juniper Business Use Only
From: Chengli (Cheng Li) mailto:c...@huawei.com>>
Sent: Friday, May 22, 2020 2:56 AM
To: 6man <6...@ietf.org<mailto:6...@ietf.org>>; 
spring@ietf.org<mailto:spring@ietf.org>; Ron Bonica 
mailto:rbon...@juniper.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

Hi Ron,

When reading the CRH draft, I have a question about how CRH support SFC?

For example, we have a SID List [S1, S2, S3, S4, S5], and S3 is a SFC related 
SID, how to indicate that? By PSSI? [1]

But how to know which segment endpoint node/egress node should process this 
PSSI? At the beginning of the SRm6 design, this is described in [2]. But you 
deleted the containers [2].

Without that, I don’t really understand how SFC can be supported..


Best,
Cheng



[1]. 
https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-4.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01*se

Re: [spring] How CRH support SFC/Segment Endpoint option?

2020-05-23 Thread Chengli (Cheng Li)

Hi Joel,

Sure, you are right, we can use CRH and NSH, but personally, I don't think this 
is a good idea. 

CRH introduce the mapping table to the nodes, and NSH introduce per-SFC/flow 
mapping state again, it is not we want in source routing. 
We want to maintain the states on the edge nodes only instead of all the nodes. 
Not intent to say bad words to NSH, it is a good solution, but we just like 
sourcing routing more, because of the simplicity. 
Using CRH and NSH is too complicated. Why not use SRv6 for SFC?[1], a single 
SRH can solve the problem. Less states on nodes, even less overhead, and 
simpler processing for sure.

But my point is not about NSH, my point is about the second option proposed by 
Ron, how to use the first DOH to support SFC?

or how to support to trigger the specific (service/function) behavior on a 
specific node?

For example, I need to expose the packet to a firewall policy at node 3 ( 5 
nodes for this path, 1,2,3,4,5), so I put a PSSI :expose a packet to a firewall 
policy into the first DOH.
According to RFC8200, all the segment endpoint nodes 1,2,3,4,5 will expose the 
packet to a firewall policy, correct?

Thanks,
Cheng

[1]. https://tools.ietf.org/html/draft-ietf-spring-sr-service-programming-02
[2]. 
https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-4.1

==
4.1.  PSSI

   The PSSI, if present, is executed on the segment egress node.
   Because the path egress node is also a segment egress node, it can
   execute a PSSI.

   The following are examples of PSSIs:

   o  Expose a packet to a firewall policy.

   o  Expose a packet to a sampling policy.

===

-Original Message-
From: Joel M. Halpern [mailto:j...@joelhalpern.com] 
Sent: Sunday, May 24, 2020 1:10 AM
To: Chengli (Cheng Li) ; 6man <6...@ietf.org>; spring@ietf.org
Subject: Re: How CRH support SFC/Segment Endpoint option?

there are a number of Internet Drafts describing a range of ways of using SFC 
NSH with MPLS.  The same choices appear to be available with CRH.  If folks are 
interested, once CRH progresses, it should be a simple task to document that.

Yours,
Joel

On 5/23/2020 12:59 PM, Chengli (Cheng Li) wrote:
> Hi Ron,
> 
> Thanks for your reply.
> 
> Regarding NSH, are you saying to use CRH as a tunnel transport 
> encapsulation between two SFF nodes?
> 
> Or we can use a single CRH for steering packet through all the SFF 
> nodes that the NSH packet should visit?
> 
> Regarding using the first DOH, how to do that without the container 
> design by your draft[1]?
> 
> Or the same option TLV will bind to different behaviors on different 
> nodes according to the node local configuration?
> 
> Best,
> 
> Cheng
> 
> [1]. 
> https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.t
> xt 
> <https://urldefense.com/v3/__https:/tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt__;!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT$>.
> 
> *From:*Ron Bonica [mailto:rbon...@juniper.net]
> *Sent:* Friday, May 22, 2020 10:17 PM
> *To:* Chengli (Cheng Li) ; 6man <6...@ietf.org>; 
> spring@ietf.org
> *Cc:* spring@ietf.org
> *Subject:* RE: How CRH support SFC/Segment Endpoint option?
> 
> Cheng,
> 
> The sole purpose of a Routing header is to steer a packet along a 
> specified path to its destination. It shouldn't attempt to do any more 
> than that.
> 
> The CRH does not attempt to deliver service function information to 
> service function instances. However, it is compatible with:
> 
> -The Network Service Header (NSH)
> 
> -The Destination Options header that precedes the Routing header
> 
> Both of these can be used to deliver service function information to 
> service function instances.
> 
>               
>     
> Ron
> 
> Juniper Business Use Only
> 
> *From:*Chengli (Cheng Li) mailto:c...@huawei.com>>
> *Sent:* Friday, May 22, 2020 2:56 AM
> *To:* 6man <6...@ietf.org <mailto:6...@ietf.org>>; spring@ietf.org 
> <mailto:spring@ietf.org>; Ron Bonica  <mailto:rbon...@juniper.net>>
> *Cc:* spring@ietf.org <mailto:spring@ietf.org>
> *Subject:* How CRH support SFC/Segment Endpoint option?
> 
> *[External Email. Be cautious of content]*
> 
> Hi Ron,
> 
> When reading the CRH draft, I have a question about how CRH support SFC?
> 
> For example, we have a SID List [S1, S2, S3, S4, S5], and S3 is a SFC 
> related SID, how to indicate that? By PSSI? [1]
> 
> But how to know which segment endpoint node/egress node should process 
> this PSSI? At the beginning of the SRm6 design, this is described in 
> [2]. But you deleted the

Re: [spring] How CRH support SFC/Segment Endpoint option?

2020-05-23 Thread Chengli (Cheng Li)

Hi Ron,

Thanks for your reply.

Regarding NSH, are you saying to use CRH as a tunnel transport encapsulation 
between two SFF nodes?
Or we can use a single CRH for steering packet through all the SFF nodes that 
the NSH packet should visit?

Regarding using the first DOH, how to do that without the container design by 
your draft[1]?
Or the same option TLV will bind to different behaviors on different nodes 
according to the node local configuration?

Best,
Cheng


[1]. 
https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04..txt<https://urldefense.com/v3/__https:/tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt__;!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT$>.


From: Ron Bonica [mailto:rbon...@juniper.net]
Sent: Friday, May 22, 2020 10:17 PM
To: Chengli (Cheng Li) ; 6man <6...@ietf.org>; spring@ietf.org
Cc: spring@ietf.org
Subject: RE: How CRH support SFC/Segment Endpoint option?

Cheng,

The sole purpose of a Routing header is to steer a packet along a specified 
path to its destination. It shouldn't attempt to do any more than that.

The CRH does not attempt to deliver service function information to service 
function instances. However, it is compatible with:

-  The Network Service Header (NSH)
-  The Destination Options header that precedes the Routing header

Both of these can be used to deliver service function information to service 
function instances.


 Ron




Juniper Business Use Only
From: Chengli (Cheng Li) mailto:c...@huawei.com>>
Sent: Friday, May 22, 2020 2:56 AM
To: 6man <6...@ietf.org<mailto:6...@ietf.org>>; 
spring@ietf.org<mailto:spring@ietf.org>; Ron Bonica 
mailto:rbon...@juniper.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

Hi Ron,

When reading the CRH draft, I have a question about how CRH support SFC?

For example, we have a SID List [S1, S2, S3, S4, S5], and S3 is a SFC related 
SID, how to indicate that? By PSSI? [1]

But how to know which segment endpoint node/egress node should process this 
PSSI? At the beginning of the SRm6 design, this is described in [2]. But you 
deleted the containers [2].

Without that, I don't really understand how SFC can be supported.


Best,
Cheng



[1]. 
https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-4.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01*section-4.1__;Iw!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwP15i-Xa$>
[2]. 
https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04..txt<https://urldefense.com/v3/__https:/tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt__;!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT$>.


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

[spring] How CRH support SFC/Segment Endpoint option?

2020-05-22 Thread Chengli (Cheng Li)

Hi Ron,

When reading the CRH draft, I have a question about how CRH support SFC?

For example, we have a SID List [S1, S2, S3, S4, S5], and S3 is a SFC related 
SID, how to indicate that? By PSSI? [1]

But how to know which segment endpoint node/egress node should process this 
PSSI? At the beginning of the SRm6 design, this is described in [2]. But you 
deleted the containers [2].

Without that, I don't really understand how SFC can be supported.


Best,
Cheng



[1]. 
https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-4.1
[2]. https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04..txt.


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

Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

2020-05-21 Thread Chengli (Cheng Li)

Well, when I read the latest revision, these terms are modified to other words, 
but still feel similar.

Also, I still see the sentence in Introduction:

“
The CRH allows IPv6 source nodes to specify the path that a packet
   takes to its destination.
“

To Ron,

is it a Source Packet Routing paradigm?

If yes, we should start from SPRING WG?

Things are going so fast and I don’t understand why a reference deletion can 
made such magic happen?  ☹

Best Regards,
Cheng



From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Thursday, May 21, 2020 11:35 PM
To: Ron Bonica ; Robert Raszuk 

Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Ron,

I sensed that you will propose that … hence I already asked this question in my 
last email,

Let me repeat. In rev 10 of the CRH document[1], the following SIDs with 
normative reference to SRm6 were defined but removed in Feb. 2020:
"The following are valid segment types:
   o Adjacency.
   o Node.
   o Binding. "

Your proposed text is consistent on how CRH was positioned since inception till 
Feb. 2020, i.e., for SPRING use-case.
However, the very premise of the current adoption call is use-case beyond 
SPRING.
There is a clear need for documenting a genuine use-case & architecture for CRH 
beyond SPRING, before adoption.

[1] https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10#section-4

Thanks

Regards … Zafar

From: ipv6 mailto:ipv6-boun...@ietf.org>> on behalf of 
Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>
Date: Thursday, May 21, 2020 at 10:19 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: 6man <6...@ietf.org>
Subject: RE: Size of CR in CRH

Robert,

It might makes sense for an operator to:

-  Allocate identifiers that cause packets to traverse a least-cost 
path as if they had domain-wide significance
-  Allocate identifiers that cause packets to traverse specific links 
as strictly node local

This concept also exists in SR-MPLS, where prefix SIDs have domain-wide scope 
and adjacency SIDs have node-local scope.

I will make this more clear in the next draft version.

Ron




Juniper Business Use Only
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Thursday, May 21, 2020 4:34 AM
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: 6man <6...@ietf.org>
Subject: Re: Size of CR in CRH

[External Email. Be cautious of content]

Ron,

> Now recall that identifiers have node local significance.

I was talking about case described in yr draft section 7:


"Applications can:


   o Allocate SIDs so that they have domain-wide significance."

While not a must - it is an option. So I believe my observation stays valid 
till draft either removes that option or describes scaling properties 
differences between both domain wide and local significance of the SIDs.

Thx,
R.


On Thu, May 21, 2020 at 4:01 AM Ron Bonica 
mailto:rbon...@juniper.net>> wrote:
Robert,

Consider the following network:


·  Contains 65,000 routers

·  Each router has 500 directly connected neighbors or fewer

·  Uses 16-bit CRH

In this network, each node might have 65,499 CRH-FIB entries:


·  64,999 CRH-FIB entries cause packets to follow the least-cost path to 
another node in the domain

·  500 CRH-FIB entries cause packets to traverse a specific link to a specific 
neighbor.

As a mnemonic device, an operator might assign identifiers as follows:


·  0-65,000 identify CRH-FIB entries that cause packets to follow the 
least-cost path to another node in the domain

·  65,001 – 65,565 identify CRH-FIB entries that that cause packets to traverse 
a specific link to a specific neighbor.

Now recall that identifiers have node local significance. So, Node A and Node B 
might both have a CRH-FIB entry that is identified by the value 65,001. However:


·  The CRH-FIB entry on Node A causes packets to traverse a particular link 
towards Node X

·  The CRH-FIB entry on Node B causes packets to traverse a different link 
towards Node Y.

I think that this example refutes the premise of your argument, so there is not 
further need to address the conclusion.


 Ron





Juniper Business Use Only
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Wednesday, May 20, 2020 6:20 PM
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: 6man <6...@ietf.org>
Subject: RE: Size of CR in CRH

[External Email. Be cautious of content]

HI,

So just to make sure I understand this analogy of 16 bit -- 2^16 = 65536 nodes. 
I think this is only on paper.

Imagine I have 1000 routers so if I divide the 16 bit space by 1000 I get at 
most 65 local node behaviours if anyone would like to embed such into the SID.

That means that if my router have more then 65 interfaces I am not able to 
steer packets by

Re: [spring] FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-18.txt

2020-05-14 Thread Chengli (Cheng Li)

Agree. I definitely needs time to go through the documents, seems some revision 
are updated.

If we want to solve the overhead of SRv6, we may have some options to be 
discussed. Like G-SRv6[1][2], please focus on the SRv6 compression part, if you 
need to understand it very soon.

For sure, a brand new solution that is not compatible with SRH should be 
discussed further.

Best regards,
Cheng



[1].https://tools.ietf.org/html/draft-cl-spring-generalized-srv6-np-01
[2]. https://tools.ietf.org/html/draft-lc-6man-generalized-srh-00


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, May 14, 2020 5:51 AM
To: Ron Bonica 
Cc: SPRING WG ; 6man <6...@ietf.org>
Subject: Re: [spring] FW: New Version Notification for 
draft-bonica-6man-comp-rtg-hdr-18.txt

WGs,

If someone is to judge a document's maturity level by the number of its version 
iterations with three new versions within the last 3 hours this draft is 
getting really stable pretty fast ! ;-)

But seriously 6man just published SRH RFC8754.

Shouldn't we first get some decent and real operational experience with SRH for 
a year or two before starting a new proposal with a subset of its capabilities ?

If SRH is just too complex, why during the IETF WG process and IETF review that 
was not questioned and addressed ? In my books use of TLVs is a feature not a 
bug.

New proposal to essentially do the same should not be taken on right now - 
instead pragmatic approach would be to take out those elements which are not 
operationally needed or add those which are missing should be worked on after 
some time and RFC8754-bis could be then issued.

Note that if we are just about shorter SIDs like 16 or 32 bits that is possible 
today with the vSID proposal and current SRH format.
https://tools.ietf.org/html/draft-decraene-spring-srv6-vlsid-03

Last - can anyone imagine operational complexity when a network would consist 
of some routers which can only do CRH and some which can only process SRH ? 
Leave alone the fact that both headers are completely incompatible with each 
other.

Many thx,
Robert.


In this draft version, I rename the Routing header type. It was called the 
Compressed Routing Header. Now it is called the Compact Routing Header.

...

A new version of I-D, draft-bonica-6man-comp-rtg-hdr-18.txt
has been successfully submitted by Ron Bonica and posted to the IETF repository.

Name:   draft-bonica-6man-comp-rtg-hdr
Revision:   18
Title:  The IPv6 Compact Routing Header (CRH)
Document date:  2020-05-13
Group:  Individual Submission
Pages:  14
URl: 
https://www.ietf.org/internet-drafts/draft-bonica-6man-comp-rtg-hdr-18.txt
Status: https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr
Htmlized:   https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-18
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-bonica-6man-comp-rtg-hdr-18

Abstract:
   This document defines two new Routing header types.  Collectively,
   they are called the Compact Routing Headers (CRH).  Individually,
   they are called CRH-16 and CRH-32.

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

[spring] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy)

2020-04-29 Thread Chengli (Cheng Li)

Hi authors,

In section 2.4 of [draft-ietf-spring-segment-routing-policy-06], introduced how 
the node-address of "Originator of CP(Candidate Path)" is generated when the 
Protocol-Origin is BGP. It says:
"Protocol-Origin is BGP SR Policy, it is provided by the BGP component on 
the headend and is:
 o  the BGP Router ID and ASN of the node/controller signalling the 
candidate path when it has a BGP session to the headend, OR
 o  the BGP Router ID of the eBGP peer signalling the candidate path  along 
with ASN of origin when the signalling is done via one or  more intermediate 
eBGP routers, OR
 o  the BGP Originator ID [RFC4456] and the ASN of the node/controller  
when the signalling is done via one or more route-reflectors over  iBGP 
session."

In the operator's network, in order to reduce the number of  BGP sessions in 
controller and achieve scalability, the controller only establishes eBGP peer 
with the RR. And the RR establishes iBGP peers with the headends. As mentioned 
in the draft, the headend will use the RR's Router ID as the CP's node-address 
(the signaling is done via route transmission from RR to the headend instead of 
route reflection).  The headend needs to carry the CP's key when reporting the 
SR Policy status to the controller through BGP-LS. And there is a problem that 
the controller may not recognize the key because the node-address is generated 
by the RR node.

For network robustness, two or more RRs are usually deployed. This will 
introduce another problem. When the same CP advertised by the controller is 
delivered to the headend through different RRs, the headend cannot distinguish 
whether it is the same CP because the node-address in the CPs' key  comes from 
different RRs.

To solve these problems,  We recommend carrying the Route Origin Community 
(defined in RFC 4360) directly when the controller advertises BGP routes.  In 
this way, the key  of the CP is determined by the controller and will not 
change during the advertisement of BGP routes.

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

Re: [spring] [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

2020-04-10 Thread Chengli (Cheng Li)

Hi Ketan,

Thanks for your comments! Sure, will add text to describe it. BTW, if we need 
to write a new draft, you are really welcome to do it together!

Best,
Cheng


From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Thursday, April 9, 2020 7:33 PM
To: Chengli (Cheng Li) ; Susan Hares ; 
'IDR List' 
Cc: SPRING WG 
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 
Week WG adoption call (3/30 - 4/13)

Hi Cheng,

Thanks for your responses and clarifications. They help get a better 
understanding for what exactly the authors wish to specify for "Path MTU" for 
SR Policy. Will look forward to normative text with description of computation 
and behaviours expected from both the entity computing this Path MTU value and 
it's handling on the headend. I would request description text in the draft 
instead of a normative reference to RFC3209.

That said, I still don't believe this belongs to an IDR document. The 
draft-li-idr-sr-policy-path-mtu should limit itself to the BGP encodings. I 
would suggest to move the specification of SR Policy Path MTU into a new draft 
positioned in the Spring WG. That IMHO would be the right way to progress this 
work.

Thanks,
Ketan

From: Chengli (Cheng Li) mailto:chengl...@huawei.com>>
Sent: 09 April 2020 16:27
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
Susan Hares mailto:sha...@ndzh.com>>; 'IDR List' 
mailto:i...@ietf.org>>
Cc: SPRING WG mailto:spring@ietf.org>>
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 
Week WG adoption call (3/30 - 4/13)

Hi Ketan,

Thanks for your reply, please see my reply inline.

Cheng



From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Wednesday, April 8, 2020 7:37 PM
To: Chengli (Cheng Li) mailto:chengl...@huawei.com>>; 
Susan Hares mailto:sha...@ndzh.com>>; 'IDR List' 
mailto:i...@ietf.org>>
Cc: SPRING WG mailto:spring@ietf.org>>
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 
Week WG adoption call (3/30 - 4/13)

Hi Cheng,

Please check inline below.

From: Chengli (Cheng Li) mailto:chengl...@huawei.com>>
Sent: 08 April 2020 14:36
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
Susan Hares mailto:sha...@ndzh.com>>; 'IDR List' 
mailto:i...@ietf.org>>
Cc: SPRING WG mailto:spring@ietf.org>>
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 
Week WG adoption call (3/30 - 4/13)

Hi Ketan,

Many thanks for your comments, and sorry for my delay, please see my reply 
inline.

Thanks,
Cheng


From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, April 3, 2020 4:18 PM
To: Susan Hares mailto:sha...@ndzh.com>>; 'IDR List' 
mailto:i...@ietf.org>>
Cc: SPRING WG mailto:spring@ietf.org>>
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 
Week WG adoption call (3/30 - 4/13)

Hello,

I have a few questions for the authors of this draft and some discussion points 
for the WG.

1)  What is precisely the definition of this "path MTU" for an SR Policy? I 
am guessing that it includes all the labels/SIDs that are used for the SR path?
[Cheng] Yes, The Path MTU describes the largest size of the packet, including 
the overhead of Labels/SIDs/IPv6 header/SRH and others.
[KT] Here, "path" is the SR path and the SR path is specified by a label stack. 
So the "payload" over the SR path does not include the SID List use to 
construct the path itself, right? Or do you mean that the "path MTU" is the 
lowest MTU value of all paths over which packet steered over the SR Policy may 
go over?

[Cheng] The path here is the SR path specified by a SID list.  The PMTU is the 
lowest MTU value of the MTU of the Links along the path identified by the SID 
list. It is the largest size of the packet to be sent along the SR path (SID 
List), so it can include the payload, overhead of SR, FRR and may be Binding 
SID (an Binding SID will introduce a new IPv6 encapsulation or a new SRH).

When encapsulating a packet, the length of the payload(inner IP packet or 
something else) should be less than the PMTU minus the overhead of SID 
List/SRH/ FRR overhead and Binding SID overhead, but it is a implementation 
choice.
[KT] Here a "path MTU" object is being defined. It is to be calculated by a 
component X and communicated over BGP protocol to a node/component Y. IMHO we 
cannot leave such things to implementation aspects - this attribute should be 
clearly specified so that both X and Y have the same understanding of what it 
means and how it is to be used.

[Cheng] Well, as I mention above, this value is the largest value of the MTU of 
links along the path. This value can be calculated very precisely. However, 
when we encapsulate the packet, how long  the payload can be, it depends on the 
implement

Re: [spring] [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

2020-04-09 Thread Chengli (Cheng Li)

Hi Ketan,

Thanks for your reply, please see my reply inline.

Cheng



From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Wednesday, April 8, 2020 7:37 PM
To: Chengli (Cheng Li) ; Susan Hares ; 
'IDR List' 
Cc: SPRING WG 
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 
Week WG adoption call (3/30 - 4/13)

Hi Cheng,

Please check inline below.

From: Chengli (Cheng Li) mailto:chengl...@huawei.com>>
Sent: 08 April 2020 14:36
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
Susan Hares mailto:sha...@ndzh.com>>; 'IDR List' 
mailto:i...@ietf.org>>
Cc: SPRING WG mailto:spring@ietf.org>>
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 
Week WG adoption call (3/30 - 4/13)

Hi Ketan,

Many thanks for your comments, and sorry for my delay, please see my reply 
inline.

Thanks,
Cheng


From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, April 3, 2020 4:18 PM
To: Susan Hares mailto:sha...@ndzh.com>>; 'IDR List' 
mailto:i...@ietf.org>>
Cc: SPRING WG mailto:spring@ietf.org>>
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 
Week WG adoption call (3/30 - 4/13)

Hello,

I have a few questions for the authors of this draft and some discussion points 
for the WG.

1)  What is precisely the definition of this "path MTU" for an SR Policy? I 
am guessing that it includes all the labels/SIDs that are used for the SR path?
[Cheng] Yes, The Path MTU describes the largest size of the packet, including 
the overhead of Labels/SIDs/IPv6 header/SRH and others.
[KT] Here, "path" is the SR path and the SR path is specified by a label stack. 
So the "payload" over the SR path does not include the SID List use to 
construct the path itself, right? Or do you mean that the "path MTU" is the 
lowest MTU value of all paths over which packet steered over the SR Policy may 
go over?

[Cheng] The path here is the SR path specified by a SID list.  The PMTU is the 
lowest MTU value of the MTU of the Links along the path identified by the SID 
list. It is the largest size of the packet to be sent along the SR path (SID 
List), so it can include the payload, overhead of SR, FRR and may be Binding 
SID (an Binding SID will introduce a new IPv6 encapsulation or a new SRH).

When encapsulating a packet, the length of the payload(inner IP packet or 
something else) should be less than the PMTU minus the overhead of SID 
List/SRH/ FRR overhead and Binding SID overhead, but it is a implementation 
choice.
[KT] Here a "path MTU" object is being defined. It is to be calculated by a 
component X and communicated over BGP protocol to a node/component Y. IMHO we 
cannot leave such things to implementation aspects - this attribute should be 
clearly specified so that both X and Y have the same understanding of what it 
means and how it is to be used.

[Cheng] Well, as I mention above, this value is the largest value of the MTU of 
links along the path. This value can be calculated very precisely. However, 
when we encapsulate the packet, how long  the payload can be, it depends on the 
implementation.
 For example, device A can encapsulate M byte, and M =  PMTU -  
A(overhead of SR) - B (FRR overhead), and the FRR overhead may be 40 Bytes. But 
for device B, the FRR overhead may be 56 bytes, it depends on the policy.

 But you may be right, we can calculate the TRUE PMTU on X 
(Controller, etc.) , and send it to the device, and the device will use it as 
the longest length of the Payload, that will be fine. We can discuss about this.



2)  While https://tools.ietf.org/html/rfc3209#section-2.6 defines "path 
MTU" for RSVP-TE LSPs, it does describe the procedures for the same for 
handling IP packets/payloads on the headend. It does not cover the scenarios 
where the incoming packets may be themselves labelled.
[Cheng]Well, I may misunderstand the text in 
https://tools.ietf.org/html/rfc3209#section-2.6, but I think it covers the 
scenarios where the incoming packets may be themselves labelled. I may be wrong.

   "
   The following algorithm applies to all unlabeled IP datagrams and to
   any labeled packets which the node knows to be IP datagrams, to which
   labels need to be added before forwarding.  For labeled packets the
   bottom of stack is found, the IP header examined.


   Using the terminology defined in 
[5<https://tools.ietf.org/html/rfc3209#ref-5>], an LSR MUST execute the

   following algorithm:



   1. Let N be the number of bytes in the label stack (i.e, 4 times the

  number of label stack entries) including labels to be added by

  this node.
   "
[KT] May be I misunderstood your proposal then. It seems that the authors want 
the headend to perform the behavior described in RFC3209 Sec 2.6 for SR 
Policies, then pl

Re: [spring] [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

2020-04-09 Thread Chengli (Cheng Li)

Hi Aijun,

Many thanks for your comments, please see my reply inline.

Best regards,
Cheng

From: Aijun Wang [mailto:wangai...@tsinghua.org.cn]
Sent: Thursday, April 9, 2020 12:08 AM
To: Chengli (Cheng Li) 
Cc: Ketan Talaulikar (ketant) ; Susan Hares 
; IDR List ; SPRING WG 
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 
Week WG adoption call (3/30 - 4/13)

Hi, Cheng:
I am considering the following scenarios:
When the size of some packets of one flow are small and do not exceed the PMTU 
value, they are encapsulated upon the corresponding SR policy and will be 
transferred according to the appointed path as expected.
But how about other larger packets within the same flow? Will they be dropped 
or transferred via other non-SR path? If so, will the SR influence the flow’s 
jitter?

[Cheng] The PTMU is the minimum value of the MTU of Links along the path 
identified by the SID list. Therefore, the value of PMTU describes the largest 
size of the packet to be sent along the SR path, including the SR overhead. If 
the received packet is larger than the PMTU – overhead, it will be dropped or 
fragmented. It is similar to RSVP-TE MPLS. 
https://tools.ietf.org/html/rfc3209#section-2.6

PMTU for the path is one useful information but I think current draft has not 
elaborate how to use it in different situations.
[Cheng] Will add text to specify how to handle the value on the ingress node.

Without SR, we can tell the customer the MTU of the network. But with SR, the 
network MTU will be changed based on the path length. Considering this, maybe 
the PMTU that detected by the host will be more convincible?
[Cheng] However, the host can not detect the real PMTU of the network, because 
it can not be aware of the overhead of the SR and others, it will get the 
minimum value of the Link MTU, but, the really PMTU should be the PMTU – N (SR 
overhead or other overhead).

Hope I have answered your questions. Thank you again!

Aijun Wang
China Telecom

On Apr 8, 2020, at 17:07, Chengli (Cheng Li) 
mailto:chengl...@huawei.com>> wrote:

Hi Ketan,

Many thanks for your comments, and sorry for my delay, please see my reply 
inline.

Thanks,
Cheng

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, April 3, 2020 4:18 PM
To: Susan Hares mailto:sha...@ndzh.com>>; 'IDR List' 
mailto:i...@ietf.org>>
Cc: SPRING WG mailto:spring@ietf.org>>
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 
Week WG adoption call (3/30 - 4/13)

Hello,

I have a few questions for the authors of this draft and some discussion points 
for the WG.

1)  What is precisely the definition of this “path MTU” for an SR Policy? I 
am guessing that it includes all the labels/SIDs that are used for the SR path?
[Cheng] Yes, The Path MTU describes the largest size of the packet, including 
the overhead of Labels/SIDs/IPv6 header/SRH and others. When encapsulating a 
packet, the length of the payload(inner IP packet or something else) should be 
less than the PMTU minus the overhead of SID List/SRH/ FRR overhead and Binding 
SID overhead, but it is a implementation choice.

2)  While https://tools.ietf.org/html/rfc3209#section-2.6 defines “path 
MTU” for RSVP-TE LSPs, it does describe the procedures for the same for 
handling IP packets/payloads on the headend. It does not cover the scenarios 
where the incoming packets may be themselves labelled.
[Cheng]Well, I may misunderstand the text in 
https://tools.ietf.org/html/rfc3209#section-2.6, but I think it covers the 
scenarios where the incoming packets may be themselves labelled. I may be wrong.

   “
   The following algorithm applies to all unlabeled IP datagrams and to
   any labeled packets which the node knows to be IP datagrams, to which
   labels need to be added before forwarding.  For labeled packets the
   bottom of stack is found, the IP header examined.

   Using the terminology defined in 
[5<https://tools.ietf.org/html/rfc3209#ref-5>], an LSR MUST execute the

   following algorithm:

   1. Let N be the number of bytes in the label stack (i.e, 4 times the

  number of label stack entries) including labels to be added by

  this node.
   “

3)  Shouldn’t the concept of “path MTU” for SR Policies and its’ 
applicability and operations be first defined in a (Spring WG?) document before 
we introduce its signalling aspects in protocols like BGP? Note that such a 
document would bring in requirements and guidelines for how the value is going 
to be computed and it’s usage for different steering mechanisms over SR 
Policies.
[Cheng] This is a really small but useful and straight forward extensions, it 
might not need to write a draft to describe the requirement instead of adding 
text in the current SR policy architecture draft or it current document.

4)  Finally, specific to the proposed encoding here, would this “path MTU” 
not be more suita

Re: [spring] [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

2020-04-08 Thread Chengli (Cheng Li)

Hi Ketan,

Many thanks for your comments, and sorry for my delay, please see my reply 
inline.

Thanks,
Cheng


From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, April 3, 2020 4:18 PM
To: Susan Hares ; 'IDR List' 
Cc: SPRING WG 
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 
Week WG adoption call (3/30 - 4/13)

Hello,

I have a few questions for the authors of this draft and some discussion points 
for the WG.

1)  What is precisely the definition of this "path MTU" for an SR Policy? I 
am guessing that it includes all the labels/SIDs that are used for the SR path?
[Cheng] Yes, The Path MTU describes the largest size of the packet, including 
the overhead of Labels/SIDs/IPv6 header/SRH and others. When encapsulating a 
packet, the length of the payload(inner IP packet or something else) should be 
less than the PMTU minus the overhead of SID List/SRH/ FRR overhead and Binding 
SID overhead, but it is a implementation choice.

2)  While https://tools.ietf.org/html/rfc3209#section-2.6 defines "path 
MTU" for RSVP-TE LSPs, it does describe the procedures for the same for 
handling IP packets/payloads on the headend. It does not cover the scenarios 
where the incoming packets may be themselves labelled.
[Cheng]Well, I may misunderstand the text in 
https://tools.ietf.org/html/rfc3209#section-2.6, but I think it covers the 
scenarios where the incoming packets may be themselves labelled. I may be wrong.

   "
   The following algorithm applies to all unlabeled IP datagrams and to
   any labeled packets which the node knows to be IP datagrams, to which
   labels need to be added before forwarding.  For labeled packets the
   bottom of stack is found, the IP header examined.


   Using the terminology defined in 
[5], an LSR MUST execute the

   following algorithm:



   1. Let N be the number of bytes in the label stack (i.e, 4 times the

  number of label stack entries) including labels to be added by

  this node.
   "

3)  Shouldn't the concept of "path MTU" for SR Policies and its' 
applicability and operations be first defined in a (Spring WG?) document before 
we introduce its signalling aspects in protocols like BGP? Note that such a 
document would bring in requirements and guidelines for how the value is going 
to be computed and it's usage for different steering mechanisms over SR 
Policies.
[Cheng] This is a really small but useful and straight forward extensions, it 
might not need to write a draft to describe the requirement instead of adding 
text in the current SR policy architecture draft or it current document.



4)  Finally, specific to the proposed encoding here, would this "path MTU" 
not be more suitable on the CP level since each SL may have different size 
label stack and different paths and one does not know which SL would be picked 
for a particular flow? So may be the lowest value computed for all SLs is what 
gets applied to the packets at the CP (i.e. SR Policy) level?
[Cheng] You are correct. The PMTU is defined for SID List. When we talk about 
Path MTU for SR policy, it CAN be the lowest value of the PMTU of SID lists. 
But do we need this value? If we need, then the node can compute it based on 
PMTUs.




Thanks,
Ketan


From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Susan Hares
Sent: 30 March 2020 18:06
To: 'IDR List' mailto:i...@ietf.org>>
Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG 
adoption call (3/30 - 4/13)

This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-03.txt

You can view this draft at:
https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/

This draft distributes path maximum transmission unit for the
SR policy via BGP.

Any discussion regarding on whether one desires
SR Policy should be clearly distinguished from the
Technical discussions on the mechanisms to pass SR policy MTU.

The questions for the people to discuss on this draft are:

1) Is there a need for this mechanism in networks using
MPLS-SR or SR-V6 and SR policy?

2) Are there any error handling issues besides what is being
 Taken care of in RFC7752bis-03.txt

3) Do you think this draft is ready to be adopted?
 In this category, please list any concerns you have
 regarding adoption.  This category can include
 general concerns about BGP-LS, MPLS-SR,
SR-V6, and SR-Policy.

Cheers, Sue Hares





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

Re: [spring] New Version Notification for draft-li-spring-srv6-path-segment-05.txt

2020-03-03 Thread Chengli (Cheng Li)

Hi Forks,

We just updated the SRv6 Path Segment draft, welcome to review it. If you have 
any comments, please feel free to let us know.

Since the content is mature and stable, authors would like to request for WG 
adoption.

Thanks,
Cheng


-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Wednesday, March 4, 2020 10:55 AM
To: Weiqiang Cheng ; Dhruv Dhody 
; Mach Chen ; Chengli (Cheng Li) 
; Mach Chen ; Rakesh Gandhi 

Subject: New Version Notification for draft-li-spring-srv6-path-segment-05.txt


A new version of I-D, draft-li-spring-srv6-path-segment-05.txt
has been successfully submitted by Cheng Li and posted to the IETF repository.

Name:   draft-li-spring-srv6-path-segment
Revision:   05
Title:  Path Segment for SRv6 (Segment Routing in IPv6)
Document date:  2020-03-04
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/internet-drafts/draft-li-spring-srv6-path-segment-05.txt
Status: 
https://datatracker.ietf.org/doc/draft-li-spring-srv6-path-segment/
Htmlized:   https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-05
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-li-spring-srv6-path-segment
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-li-spring-srv6-path-segment-05

Abstract:
   Segment Routing (SR) allows for a flexible definition of end-to-end
   paths by encoding paths as sequences of sub-paths, called "segments".
   Segment routing architecture can be implemented over an MPLS data
   plane as well as an IPv6 data plane.

   Further, Path Segment has been defined in order to identify an SR
   path in SR-MPLS networks, and used for various use-cases such as end-
   to-end SR Path Protection and Performance Measurement (PM) of an SR
   path.  Similar to SR-MPLS, this document defines the Path Segment in
   SRv6 networks in order to identify an SRv6 path.


  


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.

The IETF Secretariat


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

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

2020-03-02 Thread Chengli (Cheng Li)

+1.

Not to make a decision, but to agree with Bruno. Many thanks for your 
information, very useful to me :)

Best Regards,
Cheng



-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Monday, March 2, 2020 8:49 PM
To: S Moonesamy 
Cc: Rob Shakir ; Martin Vigoureux 
; spring@ietf.org; Warren Kumari 
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - 
draft-ietf-spring-srv6-network-programming

Dear S Moonesamy,

Speaking as an individual contributor, please find below a few comments

1) The below email was a private email between a set of persons.
Forwarding it, to a public list without permission is frown upon by the 
Netiquette (if not savoir-vivre, to begin with)

"If the message was a personal message to  you and you are re-posting to a 
group, you should ask permission  first."
https://tools.ietf.org/html/rfc1855

2) While forwarding the email, you have edited it, removing you own original 
email and the context. Context that nobody on the mailing list can be aware of.

"If you are forwarding or re-posting a message you've received, do not change 
the wording."
https://tools.ietf.org/html/rfc1855


I would suggest that next time you want the communication to be public, you 
start it on the public mailing list, so that the whole WG is aware of the whole 
thread.
(Note that this would not change the text in my email)

--Bruno

 
> 
> -Original Message-
> From: S Moonesamy [mailto:sm+i...@elandsys.com]
> Sent: Friday, February 28, 2020 10:36 AM
> To: DECRAENE Bruno TGI/OLN; spring@ietf.org
> Cc: Warren Kumari; Martin Vigoureux; Rob Shakir
> Subject: RE: [spring] Request to close the LC and move forward//RE: 
> WGLC - draft-ietf-spring-srv6-network-programming
> 
> Dear Mr Decraene,
> At 12:58 AM 28-02-2020, bruno.decra...@orange.com wrote:
> >1) People have the right to express, including to hum sometimes, but 
> >decision is not based on the number of "+1".
> >Do you have the impression that the decision is based on some voting 
> >scheme? (Assuming the decision was made in the first place...) If so, 
> >could you please help me see what makes you feel so?
> 
> My comment about the above was a response to the comment at 
> https://mailarchive.ietf.org/arch/msg/spring/nIAqSeZJKq64QHbyy_ZrNqk_C
> Xg/
> 
> >2) As regards to the timing, the duration of the call for comments 
> >has indeed elapsed.
> >If your comment is related to the actual work, as you may have seen, 
> >there has been a high number of comments on the list so there is work 
> >to be done on the resolution of the comments. The more comments, the 
> >more time. The harder the comment, the more time. I can't provide or 
> >force people to provide an ETA for the resolutions of comments. I 
> >think that working on improving the document is more important than a 
> >few weeks delay. BTW, I'm not aware of specific timing requirement to 
> >advance a document to RFC. Closest things I've seen is "SOON" [1] and 
> >"timely" [2]
> 
> I enquired about the working group process.  I don't see anything in 
> the reference to RFC 2026 about Working Group procedures.  The second 
> reference is to an Internet-Draft about the definition of the word 
> "timely".  As far as I am aware, that Internet-Draft is not part of 
> IETF Working Group procedures.
> 
> >If your question is related to formal state, is your point that the 
> >datatracker state should have been moved from " In WG Last Call " to 
> >" Revised I-D Needed - Issue raised by WGLC ". If so, I tend to agree 
> >with you. Could/will also be " Doc Shepherd Follow-up Underway" at 
> >some point.
> >
> >That been said, as I've said on the list, the end of the WG LC is not 
> >the end of the ability for the WG to make technical comments on the 
> >list. [3]. One example may be the latest comment from Chris Bowers.
> >
> >3) Your specific questions been answered, it's not crystal clear to 
> >me what are you trying to achieve with your email. Do you believe the 
> >document should advance faster, slower, not advance? That your 
> >comments were not adequately answered? (although I'm not seen any 
> >comment from your side on the mailing list). Please help me 
> >understand your root concern.
> 
> My question was about when the the Working Group Last Call ends.  I 
> don't view it as appropriate to determine whether the document should 
> advance faster or slower as I am not responsible to make such a determination.
> 
> Regards,
> S. Moonesamy
>

_

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

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

2020-02-26 Thread Chengli (Cheng Li)

+1

Cheng

From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Gengxuesong (Geng 
Xuesong)
Sent: Wednesday, February 26, 2020 8:19 PM
To: Lizhenbin ; bruno.decra...@orange.com; 'SPRING WG 
List' 
Cc: 6...@ietf.org; draft-ietf-spring-srv6-network-programming 

Subject: RE: Request to close the LC and move forward//RE: WGLC - 
draft-ietf-spring-srv6-network-programming

+1

Best Regards
Xuesong
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Lizhenbin
Sent: Wednesday, February 26, 2020 7:55 PM
To: bruno.decra...@orange.com; 'SPRING WG 
List' mailto:spring@ietf.org>>
Cc: 6...@ietf.org; 
draft-ietf-spring-srv6-network-programming 
mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>>
Subject: [spring] Request to close the LC and move forward//RE: WGLC - 
draft-ietf-spring-srv6-network-programming

Hi Bruno and WG,
The LC has lasted for almost 3 months which greatly exceeds the expected 2 
week. In the process all the comments have been resolved while some issues is 
raised again and again with little value.
On the other hand, there have been multiple commercial implementation and 
inter-op test and almost 20 deployments for SRv6 which justify the solution 
proposed by the draft in practice.

We sincerely request to close the LC of the draft and move forward.

Best Regards,
Zhenbin (Robin)

From: bruno.decra...@orange.com 
[mailto:bruno.decra...@orange.com]
Sent: Friday, December 06, 2019 1:15 AM
To: 'SPRING WG List' mailto:spring@ietf.org>>
Cc: 6...@ietf.org; 
draft-ietf-spring-srv6-network-programming 
mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>>
Subject: WGLC - draft-ietf-spring-srv6-network-programming

Hello SPRING,

This email starts a two weeks Working Group Last Call on 
draft-ietf-spring-srv6-network-programming [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 December 20.

You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating 
emails on the 6MAN mailing list for the comments which are only spring 
specifics.

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.

This may help avoiding that the thread become specific to this point and that 
other points get forgotten (or that the thread get converted into parallel 
independent discussions)

Thank you,

Bruno

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05

_

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

Re: [spring] Is srv6 PSP a good idea

2020-02-26 Thread Chengli (Cheng Li)

Agree! I thought these problems have already been closed for a while since we 
have a lot of discussion for a while.

After two months not paying attention to the mailing list, the discussion is 
still there?

Clearly, we had a  lot of discussion already, please refs to the links in the 
below emails. From tech aspect, agree with Jingrong’s POV. Copied below.

Best Regards,
Cheng

Hi Mark,

I think both AH and PSP are optional.

If AH is desired to deploy, then the operator can choose not to use PSP.

If AH is not deployed, and the operator has its requirements of 
incremental-deployment, then the operator can choose to use PSP.

If the already deployed PSP is removed from the draft, then I think it's 
backward for interoperation.

RFC4301:

3.2.  How IPsec Works

   IPsec uses two protocols to provide traffic security services --

   Authentication Header (AH) and Encapsulating Security Payload (ESP).

   Both protocols are described in detail in their respective RFCs

   [Ken05b, Ken05a].  IPsec implementations MUST support ESP and MAY

   support AH. (Support for AH has been downgraded to MAY because

   experience has shown that there are very few contexts in which ESP

   cannot provide the requisite security services.  Note that ESP can be

   used to provide only integrity, without confidentiality, making it

   comparable to AH in most contexts.)

Thanks,

Jingrong

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, February 26, 2020 6:07 PM
To: Mark Smith 
Cc: Ron Bonica ; spring@ietf.org; Joel M. Halpern 
; Pablo Camarillo (pcamaril) 
Subject: Re: [spring] Is srv6 PSP a good idea

So now we have one more to Pablo's list: "Let's not use it as it is hard to 
troubleshoot" ...

Clearly each new tool has a learning curve and no doubt not everyone will know 
how to use it. But does this mean we should stop inventing new things ? IMO for 
someone who is starting to use SRv6 PHP is the least complex operational 
behaviour.

Thx,
R.

On Wed, Feb 26, 2020 at 1:31 AM Mark Smith 
mailto:markzzzsm...@gmail.com>> wrote:
Hi Pablo,

On Sat, 21 Dec 2019 at 04:38, Pablo Camarillo (pcamaril)
mailto:pcama...@cisco.com>> wrote:
>
>  Hi Ron,
>
> I guess we are making some progress here but going in some circles. So far we 
> have moved from “this violates RFC8200” to “there are no use-cases or 
> benefits” to “this is complex for an ASIC” to “what is the benefit again” and 
> now back to “this is complex for an ASIC”.
>

As far as I know, the next header field in both the IPv6 fixed header
and in extension headers is immutable while the packet is travelling
within the network, as is the payload length field in the IPv6 base
fixed header.

Nothing in RFC 8200 modifies those fields while the packet is in
flight between the packet's original source and final destination, nor
is there anything in RFC 8200 that specifies how to do those
modifications and any other discussion about the consequences and
considerations when doing so.

The IPsec AH header is providing integrity checking over fields in the
IPv6 packet that shouldn't be being modified while the packet is
within the network. What is and isn't protected by AH can be seen to
be a specification of what processing on a packet can and cannot occur
while it is in flight across the network towards its final
destination.

Therefore, AH is really a quality assurance mechanism for the network
packet processing that RFC 8200 specifies. The processing of the
packet by the network with or without the use of AH should be the
same. AH should really only be necessary if there is a belief that the
network is likely not to be processing packets in accordance to RFC
8200, either accidentally or intentionally.

Per RFC4302 (IPsec AH),  the following section explicitly states which
fields in the IPv6 header are immutable and are to be protected by AH:

3.3.3.1.2.  ICV Computation for IPv6

3.3.3.1.2.1.  Base Header Fields

   The IPv6 base header fields are classified as follows:

Immutable
   Version
   Payload Length
   Next Header
   Source Address
   Destination Address (without Routing Extension Header)

   Mutable but predictable
   Destination Address (with Routing Extension Header)

   Mutable (zeroed prior to ICV calculation)
   DSCP (6 bits, see RFC2474 [NBBB98])
   ECN (2 bits, see RFC3168 [RFB01])
   Flow Label (*)
   Hop Limit

(*) The flow label described in AHv1 was mutable, and in
RFC 2460 [DH98] was potentially mutable.  To retain
compatibility with existing AH implementations, the
flow label is not included in the ICV in AHv2.

> As for how easy or not something is, the PSP behavior has been implemented 
> and deployed (running code). The use-cases have been described and positively 
> reinforced by operators. I don't think there is any further explanation to 
> provide.
>

"Just

[spring] FW: RE: draft-ietf-spring-srv6-network-programming - 2 week Early Allocation Call

2020-01-03 Thread Chengli (Cheng Li)


Foeget to cc to SPRING WG   :（

Happy  new year!




李呈 Cheng Li
Email: 
chengl...@huawei.com">chengl...@huawei.com<mailto:chengl...@huawei.com>



From: Chengli (Cheng Li)mailto:chengl...@huawei.com>>
To: bruno.decraenemailto:bruno.decra...@orange.com>>
Cc: Lizhenbinmailto:lizhen...@huawei.com>>
Subject: RE: [spring] draft-ietf-spring-srv6-network-programming - 2 week Early 
Allocation Call
Time: 2020-01-03 18:58:26

Yes, support. There are increasingly SRv6 implementations and deployments in 
the world, earlier the allocation better the products.

Regards,
Cheng Li



李呈 Cheng Li
Email: 
chengl...@huawei.com">chengl...@huawei.com<mailto:chengl...@huawei.com>



From: 
bruno.decraenemailto:bruno.decra...@orange.com>>
To: SPRING WGmailto:spring@ietf.org>>
Subject: [spring] draft-ietf-spring-srv6-network-programming - 2 week Early 
Allocation Call
Time: 2019-12-20 00:54:44


Hi SPRING WG,



This begins a 2 week Early Allocation call for a “Ethernet” value from the 
"Protocol Numbers" registry.

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-07#section-9.1

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-07#section-5.3

https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml



In parallel of the Working Group Last Call which is currently running, the 
authors are requesting for early code point allocation from IANA as 
implementations are under way.



The criteria for early allocation are:

   a.  The code points must be from a space designated as "RFC

   Required", "IETF Review", or "Standards Action".  Additionally,

   requests for early assignment of code points from a

   "Specification Required" registry are allowed if the

   specification will be published as an RFC.



   b.  The format, semantics, processing, and other rules related to

   handling the protocol entities defined by the code points

   (henceforth called "specifications") must be adequately described

   in an Internet-Draft.



   c.  The specifications of these code points must be stable; i.e., if

   there is a change, implementations based on the earlier and later

   specifications must be seamlessly interoperable.



   d.  The Working Group chairs and Area Directors (ADs) judge that

   there is sufficient interest in the community for early (pre-RFC)

   implementation and deployment, or that failure to make an early

   allocation might lead to contention for the code point in the

   field.

https://tools.ietf.org/html/rfc7120#section-2



I believe the above conditions are met. (minus the AD judgement which is 
further down in the process)



As a reminder, this topic has mainly been discussed following IETF 105 
(Montréal) both during the meeting and on the mailing list.

During IETF 106 it has been discussed in the IntArea WG. 
https://datatracker.ietf.org/meeting/106/proceedings#intarea



Note that this code point is not to be specific to SRv6. Depending on AD 
guidance, this specific code point even be moved from 
draft-ietf-spring-srv6-network-programming into a specific 1 page draft.



If you support early adoption,  please include “support” along with any 
comments about the draft’s technical solution.



If you do not support early allocation, please include “no support” in your 
email and indicate why.



Thank you,

--Bruno


_

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] Welcome to review draft-li-spring-srv6-security-consideration-03.txt

2019-11-06 Thread Chengli (Cheng Li)

Hi WG, 

We just updated the SRv6 Security Consideration draft.

Since SRv6 is a Segment Routing implementation based on IPv6 data plane, so it 
inherits potential security vulnerabilities from Source Routing in general, and 
also from IPv6.
Our document describes various threats and security concerns related to SRv6 
networks and existing approaches to solve these threats.

We will update the document to add more content of security concerns and 
solutions in the future.

Welcome to review the document, and any comments or questions are welcome.
If you have any security consideration that would like to add in this document, 
please feel free to let me know!

Thanks,
Cheng


-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, November 04, 2019 7:24 PM
To: Lizhenbin ; Maojianwei (Mao) ; 
Chengli (Cheng Li) ; Maojianwei (Mao) 
; Chongfeng Xie ; Hui Tian 
; Chengli (Cheng Li) 
Subject: New Version Notification for 
draft-li-spring-srv6-security-consideration-03.txt


A new version of I-D, draft-li-spring-srv6-security-consideration-03.txt
has been successfully submitted by Jianwei Mao and posted to the IETF 
repository.

Name:   draft-li-spring-srv6-security-consideration
Revision:   03
Title:  Security Considerations for SRv6 Networks
Document date:  2019-11-04
Group:  Individual Submission
Pages:  13
URL:
https://www.ietf.org/internet-drafts/draft-li-spring-srv6-security-consideration-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-li-spring-srv6-security-consideration/
Htmlized:   
https://tools.ietf.org/html/draft-li-spring-srv6-security-consideration-03
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-li-spring-srv6-security-consideration
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-li-spring-srv6-security-consideration-03

Abstract:
   SRv6 inherits potential security vulnerabilities from Source Routing
   in general, and also from IPv6.  This document describes various
   threats and security concerns related to SRv6 networks and existing
   approaches to solve these threats.


  


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.

The IETF Secretariat

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

[spring] Welcome to review draft-li-spring-sr-sfc-control-plane-framework-01.txt

2019-11-06 Thread Chengli (Cheng Li)

Hi SPRING,

We just updated the draft-li-spring-sr-sfc-control-plane-framework-01.

This document describes a framework for constructing SFC based on Segment 
Routing. 
The document reviews the control plane solutions for route distribution of 
service function instance and service function path, and steering packets into 
a service function chain.

Hope this informational draft help people to understand the solutions of SFC 
control plane. 
Welcome to review the document, and any questions or comments, please let us 
know, that will be highly appreciated.

Thanks,
Cheng

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, November 04, 2019 9:30 PM
To: huruizhao ; Ahmed El Sawaf ; 
Chengli (Cheng Li) ; Lizhenbin 
Subject: New Version Notification for 
draft-li-spring-sr-sfc-control-plane-framework-01.txt


A new version of I-D, draft-li-spring-sr-sfc-control-plane-framework-01.txt
has been successfully submitted by Cheng Li and posted to the IETF repository.

Name:   draft-li-spring-sr-sfc-control-plane-framework
Revision:   01
Title:  A Framework for Constructing Service Function Chaining Systems 
Based on Segment Routing
Document date:  2019-11-04
Group:  Individual Submission
Pages:  12
URL:
https://www.ietf.org/internet-drafts/draft-li-spring-sr-sfc-control-plane-framework-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-li-spring-sr-sfc-control-plane-framework/
Htmlized:   
https://tools.ietf.org/html/draft-li-spring-sr-sfc-control-plane-framework-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-li-spring-sr-sfc-control-plane-framework
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-li-spring-sr-sfc-control-plane-framework-01

Abstract:
   Segment Routing (SR) allows for a flexible definition of end-to-end
   paths by encoding paths as sequences of topological sub-paths, called
   "segments".  Segment routing architecture can be implemented over an
   MPLS data plane as well as an IPv6 data plane.

   Service Function Chaining (SFC) provides support for the creation of
   composite services that consist of an ordered set of Service
   Functions (SF) that are to be applied to packets and/or frames
   selected as a result of classification.

   SFC can be implemented based on several technologies, such as Network
   Service Header (NSH) and SR.  This document describes a framework for
   constructing SFC based on Segment Routing.  The document reviews the
   control plane solutions for route distribution of service function
   instance and service function path, and steering packets into a
   service function chain.


  


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.

The IETF Secretariat

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

[spring] Request for WG review and adoption of draft-li-spring-srv6-path-segment-04.txt

2019-11-06 Thread Chengli (Cheng Li)

Hi SPRING,

We just updated the draft-li-spring-srv6-path-segment, major updates:

* add text to clarify why do we need SRv6 Path Segment: 
   
   The segment list may not be a good key to identify an SRv6
   path, since the the length of segment list is flexible according to
   the number of SIDs.  Also, the length of SID list will be too long to
   be a key when it contains many SIDs.  For instance, if packet A uses
   the SRH with 3 SIDs while Packet B uses the SRH with 10 SIDs, the key
   to identify these two paths will be a 384-bits value and a 1280-bits
   value.  A fixed length Path ID at a fixed location will help in processing 
performance.

* move encoding part to draft-li-6man-srv6-path-segment-encap-01

Since the text of this document is stable and mature, we hope to have a WG 
review, and we request for WG adoption.
Any questions or comments are welcome!

Best regards,
Cheng


-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, November 04, 2019 10:53 PM
To: Rakesh Gandhi ; Lizhenbin ; 
Weiqiang Cheng ; Dhruv Dhody 
; Mach Chen ; Dongjie (Jimmy) 
; Mach Chen ; Chengli (Cheng Li) 

Subject: New Version Notification for draft-li-spring-srv6-path-segment-04.txt


A new version of I-D, draft-li-spring-srv6-path-segment-04.txt
has been successfully submitted by Cheng Li and posted to the IETF repository.

Name:   draft-li-spring-srv6-path-segment
Revision:   04
Title:  Path Segment for SRv6 (Segment Routing in IPv6)
Document date:  2019-11-04
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/internet-drafts/draft-li-spring-srv6-path-segment-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-li-spring-srv6-path-segment/
Htmlized:   https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-li-spring-srv6-path-segment
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-li-spring-srv6-path-segment-04

Abstract:
   Segment Routing (SR) allows for a flexible definition of end-to-end
   paths by encoding paths as sequences of sub-paths, called "segments".
   Segment routing architecture can be implemented over an MPLS data
   plane as well as an IPv6 data plane.

   Further, Path Segment has been defined in order to identify an SR
   path in SR-MPLS networks, and used for various use-cases such as end-
   to-end SR Path Protection and Performance Measurement (PM) of an SR
   path.  Similar to SR-MPLS, this document defines the Path Segment in
   SRv6 networks in order to identify an SRv6 path.


  


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.

The IETF Secretariat

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

[spring] 答复: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and draft-li-sr-policy-path-segment-01.txt - 1 week extension [10/14 to 10/21/2019]

2019-10-25 Thread Chengli (Cheng Li)

Hi Susan, IDRers and SPRINGers,

Many thanks for all your work, contributions and attentions.
Your comments help a lot on these documents and me as well for sure.

Will upload the documents ASAP.
Also, I will collect the comments and share to the WGs, as well as the planning 
to refine, and implementation status.

Thanks again! See you guys in Singapore.
Cheng


发件人: Idr [mailto:idr-boun...@ietf.org] 代表 Susan Hares
发送时间: 2019年10月25日 22:33
收件人: 'idr wg' 
主题: Re: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and 
draft-li-sr-policy-path-segment-01.txt - 1 week extension [10/14 to 10/21/2019]

Greeting:

It seems I asked the questions about these two drafts to the correct places 
(IDR and Spring).

These two drafts have enough interest to become IDR WG drafts.  Please submit 
the following:


・   draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt  as 
draft-ietf-idr-bgp-ls-sr-policy-path-segment-0.txt

・   draft-li-sr-policy-path-segment-01.txt as 
draft-ietf-idr-sr-policy-path-segment-00.txt.

The authors should carefully pay attention to the email.

I expect from the authors to send an email to IDR with the following:

a)   a summary of comments received on WG adoption call,

b)  Plans for refining and progressing their drafts, and

c)   status of any implementations.

A big thanks to all who comment on these drafts.  A special thanks to Bruno 
Decraene who provided extra insight on the links to Spring technologies.

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

Re: [spring] [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and draft-li-sr-policy-path-segment-01.txt - 1 week extension [10/14 to 10/21/2019]

2019-10-18 Thread Chengli (Cheng Li)

Hi Katen,

Many thanks for your valuable comments, will update the drafts to address them 
ASAP. Please see my rely inline.

Thank you again!
Cheng


From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, October 18, 2019 1:51 PM
To: Susan Hares ; 'idr wg' ; 'SPRING WG List' 

Subject: Re: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt 
and draft-li-sr-policy-path-segment-01.txt - 1 week extension [10/14 to 
10/21/2019]

Hi Sue,

1)  Should this SR Policy technology be included in BGP for SR-MPLS



Yes. The path segment for MPLS has been defined in Spring and we need the 
corresponding work in BGP to build the solutions based on path segments.

2)  Is this technology a good way to implement the required

Features in BGP?



Yes and do refer to some of the issues pointed in the comments below.


3)  Is this technology ready for adoption?



I have listed down the issues/concerns below. I believe we need to hear the 
responses from the authors on them. The WG/chairs can decide whether to require 
these changes before or after adoption.


4)  Do you have any concerns about adopting this technology?



No (subject to clarifications on the comments below).



My apologies for the delay in review and sharing these comments:

https://datatracker.ietf..org/doc/draft-li-idr-sr-policy-path-segment/

1)  Sec 3 has the following statement which is incorrect. First the Path 
Segment does not identify the SR Policy and the identifiers of SR Policy are 
specified in draft-ietf-spring-segment-routing-policy. What the path segment 
does is identify the specific "SR Path(s)" at the tail-end - this is as per 
draft-ietf-spring-mpls-path-segment. So I think the statement below needs to be 
revised.


Also,

   it can be used for identifying an SR candidate path or an SR Policy

   in some use cases if needed.



[Cheng] You are correct! Will address it later.

2)  The draft proposes to have the ability to encode the Path Segment at 
both the Segment List and Candidate path level. I can understand the signalling 
at the Segment List level, but not sure why we need it also at the CP level? If 
the same Path Segment needs to be shared across Segment Lists then it can be 
specified for each of them?

[Cheng] We aim to provide the capabilities, but your suggestion is right. They 
can be specified for each of them. Let's discuss which one is better later.

3)  Sec 3.1. Both the SR-MPLS and SRv6 path segments are being combined 
here and I am not sure that is appropriate. Since only the SR-MPLS path segment 
document is adopted in WG, we need SPRING WG to evaluate the SRv6 path segment. 
I would suggest to call this "MPLS Path Segment" so that work can proceed 
independently. Down the line, we can introduce another TLV for SRv6 Path 
Segment.



[Cheng] You are right. Do we have any SRv6 related text in the drafts? I 
remember I have removed it. Will check again.


4)  I would also propose to use the TLV encoding that is similar to 
https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-07#section-2.4.3.2.1
 for the MPLS path segment.
[Cheng] Agree. We designed the TLV format to 
draft-ietf-idr-segment-routing-te-policy at the first day. Will update to align 
again.


5)  Sec 4.1. The proposed Bidirectional Path sub-TLV is at the CP level.. 
So does it indicate a single reverse path SL for all the forward path SLs or 
can it have multiple SLs? Why not also do this on the per SL level so that the 
reverse path matches the forward path where necessary? Otherwise it is not 
possible to correlate the forward and reverse SLs.
[Cheng] We plan to update this in the next revision. Right now, we do not 
support to have multiple SID lists, which means per SID list level. That is why 
we need to add weight TLV into the  Bidirectional Path sub-TLV as I mentioned 
in my previous email.
We can discuss on this to design to better solution of 
supporting multiple SID lists for bidirectional path.

6)  I am not sure why the parameters like weight is required in the reverse 
path since weight is for load-balancing when steering into the path.
[Cheng ] For 1:1 correlation, we don't need weight TLV, should discuss more on 
this.


7)  I think either this draft or perhaps more appropriately the 
draft-ietf-spring-mpls-path-segment better describes the usage of the reverse 
path list so that this draft can refer to it. While we are calling this 
"bidirectional", it is actually the reverse path information. There is nothing 
like traditional bidirectional LSP signalling happening here between the two 
end points directly. It is something that is provisioned by a controller.
[Cheng] OK, will do.


8)  Please remove all suggested code points from the draft until we have 
IANA allocations for them.
[Cheng] OK

Re: [spring] draft-ietf-spring-srv6-network-programming: Section 4.16

2019-10-17 Thread Chengli (Cheng Li)

Hi Zhenqiang and Jeol,

As my understanding,  the problem is clear.

the PSP flavor is associated with the penultimate SID in the segment list, 
which may be an END, END.X or END.T. 

The PSP action will be executed after the last SID, which can be an END.Dx SID, 
is updated to the IPv6 DA.

For instance, the PSP action is executed on the node C according to an END.X 
SID with PSP flavor initiated by it, and the updated IPv6 DA is an END.DT4 SID.

AB---C-D


Now the questions are,
1. do we need this flavor? 
2. what is the benefit?
3. what is the pain of removing the SRH without removing the whole IPv6 header? 
 I think we need some explanations on the word "extremely painful".

Use cases are needed.

Cheng


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Joel M. Halpern
Sent: Friday, October 18, 2019 12:14 AM
To: Pablo Camarillo (pcamaril) ; spring@ietf.org
Cc: draft-ietf-spring-srv6-network-programming 

Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Section 4.16

Pretending it is legitimate, let me ask a different aspect of the question.

Removing bytes (aor adding bytes) from arbitrary positions in the middle of a 
packet is generally any extremely painful operation.  Why would we want a 
standard that mandated such an operation?  Savings a few bytes on SR hop (sure, 
several IP router hops) seems a small benefit for such a cost.

Yours,
Joel

On 10/17/2019 12:09 PM, Pablo Camarillo (pcamaril) wrote:
> Hi Joel,
> 
> RFC8200 permits extension header processing, insertion, deletion at a node 
> identified in the Destination Address field of the IPv6 header. This has been 
> discussed in other threads like 
> https://mailarchive.ietf.org/arch/msg/ipv6/Ypnpw-oneCb7W6s41dVZGMok0Nw .
> 
> Thanks,
> Pablo
> 
> -Original Message-
> From: "Joel M. Halpern" 
> Date: Thursday, 17 October 2019 at 15:26
> To: "Pablo Camarillo (pcamaril)" , 
> "spring@ietf.org" 
> Cc: draft-ietf-spring-srv6-network-programming 
> 
> Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: 
> Section 4.16 Resent from:  Resent to: 
> , , , 
> , , 
>  Resent date: Thursday, 17 October 2019 at 15:26
> 
>  Removing a header from an IPv6 packet (without removing the whole IPv6
>  header) is a violation of RFC 8200.
>  
>  As such, it should be removed from the base network programming draft.
>  If you really want it, put it in the new insertion draft.  And justify 
> it.
>  
>  With regard to the example of off-load, the usual practice has been to
>  avoid standardizing off-load behaviors in the IETF.  the NIC vendors
>  come up with all sorts of ways to improve performance that violate the
>  specifications.  We do not endorse that, and leave the need for
>  consenting devices engaging in proprietary communication to them.
>  
>  Yours,
>  Joel
>  
>  On 10/17/2019 5:41 AM, Pablo Camarillo (pcamaril) wrote:
>  > Li,
>  >
>  > Node1's
>  >
>  > Tenant-100 IPv4 table is: T.Encaps with SRv6 Policy   >
>  > B:8:D100::>.
>  >
>  > When 1 receives a packet P from CE-A destined to 20.20.20.20, P 
> looks
>  >
>  > up its tenant-100 IPv4 table and finds an SR-VPN entry 20/8.  As a
>  >
>  > consequence, 1 pushes an outer header with SA=A:1::, DA=B:3:C4::,
>  >
>  > NH=SRH followed by SRH (B:8:D100::, B:3:C4::; SL=1; NH=4). 1 then
>  >
>  > forwards the resulting packet on the interface to 2.
>  >
>  > 2 forwards to 3 along the path to B:3::/32.
>  >
>  > When 3 receives the packet, 3 matches the DA in its "My SID Table"
>  >
>  > and finds the bound function End.X to neighbor 4. 3 notes the PSP
>  >
>  > capability of the SID B:3:C4::. 3 sets the DA to the next SID
>  >
>  > B:8:D100::. As 3 is the penultimate segment hop, it performs PSP 
> and
>  >
>  > pops the SRH. 3 forwards the resulting packet to 4.
>  >
>  > 4, 6 and 7 forwards along the path to B:8::/32.
>  >
>  >When 8 receives the packet, 8 matches the DA in its "My SID Table"
>  >
>  > and finds the bound function End.DT(100).  As a result, 8 decaps 
> the
>  >
>  > outer header, looks up the inner IPv4 DA (20.20.20.20) in 
> tenant-100
>  >
>  > IPv4 table, and forward the (inner) IPv4 packet towards CE-B.
>  >
>  > Node 3 receives the packet SA=A:1::, DA=B:3:C4::,NH=SRH followed by SRH
>  > (B:8:D100::, B:3:C4::; SL=1; NH=4)
>  >
>  > The SID B:3:C4:: is associated with the End.X behavior with PSP 
> support.
>  > Node 3 is going to decrement SL, copy the segment B:8:D100:: into the
>  > IPv6 DA and set the packet’s egress adjacency to J (adjacency 
> associated
>  > with that SID instance). Additionally, (PSP) it will check what is the
>  > SL value in the SRH. If the

Re: [spring] SR-MPLS over IPv6？

2019-09-23 Thread Chengli (Cheng Li)

Oh, I misunderstood the BSID in CRH in last email, sorry for that.

Yes, the SID is not an IPv6 address in CRH, but a 16/32 bit value like MPLS 
label.

Therefore, IMHO, it may not comply with RFC8402: 
https://tools.ietf.org/html/rfc8402#section-3.1.3

If possible, I suggest to change the name of SRv6+, since it is not SRv6 based. 
Something like SR-MPLS over IPv6 maybe better?

Thanks,
Cheng


From: Ron Bonica [mailto:rbon...@juniper.net]
Sent: Monday, September 23, 2019 10:45 PM
To: Chengli (Cheng Li) ; Jeff Tantsura 

Cc: SING Team ; EXT - daniel.bern...@bell.ca 
; SPRING WG List 
Subject: RE: [spring] A note on CRH and on going testing

Cheng,

In SRv6+, it would be very difficult to pollute the architecture because:
-  A SID is either 16-or 32-bits long
-  An IPv6 address is 128-bits long
-  Therefore, it is impossible to copy a SID to an IPv6 address or an 
IPv6 address to a SID
The binding SID will be a 16-or 32-bit topological instruction, found in the 
CRH. Like all topological instructions, it will identify an SFIB entry.

There will be a new SFIB entry type that will contain the following information:
-  An IPv6 Destination Address (to be used in the outer IPv6 header)
-  A list of SIDs (to be used in the CRH
 Ron





Juniper Business Use Only
From: Chengli (Cheng Li) mailto:chengl...@huawei.com>>
Sent: Sunday, September 22, 2019 12:01 AM
To: Ron Bonica mailto:rbon...@juniper.net>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
Subject: RE: [spring] A note on CRH and on going testing

Hi Ron,

Good to hear that. Looking forward to seeing it in the next revision.

But I am curious that is a bind SID in CRH an interface IPv6 address only 
without any other semantics? Just like the other SIDs you mentioned in CRH.

If not, this binding SID should not be introduced in to CRH since it pollutes 
the architecture.

If yes, what’s the standard for an Interface IPv6 address?

Thanks for confirming that BSID is needed in CRH. I totally agree with you.

Best regards,
Cheng


李呈 Cheng Li
Email: chengl...@huawei.com<mailto:chengl...@huawei.com>
From: Ron Bonicamailto:rbon...@juniper.net>>
To: Jeff 
Tantsuramailto:jefftant.i...@gmail.com>>;Chengli 
(Cheng Li)mailto:chengl...@huawei.com>>
Cc: SING 
Teammailto:s.i.n.g.team.0...@gmail.com>>;EXT - 
daniel.berniermailto:daniel.bern...@bell.ca>>;SPRING WG 
Listmailto:spring@ietf.org>>
Subject: RE: [spring] A note on CRH and on going testing
Time: 2019-09-22 04:37:17

Jeff,

After an off-line conversation with the SRv6+ implementors, we decided that it 
would be trivial to add a binding SID to SRv6+. So, we will do that in the next 
version of the draft.

In keeping with RFC 8200, it will prepend only. Since the CRH is short, 
insertion is not needed.


   Ron




Juniper Business Use Only
From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Sent: Saturday, September 21, 2019 4:32 PM
To: Chengli (Cheng Li) mailto:chengl...@huawei.com>>; Ron 
Bonica mailto:rbon...@juniper.net>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
Subject: RE: [spring] A note on CRH and on going testing

Hi Ron,

Thanks for your comments, exactly, BSID MPLS label = CRH value :)

Cheers,
Jeff
On Sep 20, 2019, 11:09 AM -0700, Ron Bonica 
mailto:rbon...@juniper.net>>, wrote:
Hi Jeff,

It would be easy enough to add a binding SID to SRv6+. Given customer demand, I 
would not be averse to adding one.

However, there is another way to get exactly the same behavior on the 
forwarding plane without adding a new SID type.

Assume that on Node N, we have the following SFIB entry:


  *   SID: 123
  *   IPv6 address: 2001:db8::1
  *   SID type: prefix SID

Now assume that was also have the following route on Node N:

2001:db8::1 -> SRv6+ tunnel with specified destination address and CRH

This gives you the same forwarding behavior as a binding SID.

   Ron




Juniper Business Use Only
From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Jeff Tantsura
Sent: Thursday, September 19, 2019 10:53 PM
To: Chengli (Cheng Li) mailto:chengl...@huawei.com>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mai

Re: [spring] A note on CRH and on going testing

2019-09-21 Thread Chengli (Cheng Li)

Hi Ron,

Good to hear that. Looking forward to seeing it in the next revision.

But I am curious that is a bind SID in CRH an interface IPv6 address only 
without any other semantics? Just like the other SIDs you mentioned in CRH.

If not, this binding SID should not be introduced in to CRH since it pollutes 
the architecture.

If yes, what’s the standard for an Interface IPv6 address?

Thanks for confirming that BSID is needed in CRH. I totally agree with you.

Best regards,
Cheng





李呈 Cheng Li
Email: chengl...@huawei.com<mailto:chengl...@huawei.com>



From: Ron Bonicamailto:rbon...@juniper.net>>
To: Jeff 
Tantsuramailto:jefftant.i...@gmail.com>>;Chengli 
(Cheng Li)mailto:chengl...@huawei.com>>
Cc: SING 
Teammailto:s.i.n.g.team.0...@gmail.com>>;EXT - 
daniel.berniermailto:daniel.bern...@bell.ca>>;SPRING WG 
Listmailto:spring@ietf.org>>
Subject: RE: [spring] A note on CRH and on going testing
Time: 2019-09-22 04:37:17

Jeff,

After an off-line conversation with the SRv6+ implementors, we decided that it 
would be trivial to add a binding SID to SRv6+. So, we will do that in the next 
version of the draft.

In keeping with RFC 8200, it will prepend only. Since the CRH is short, 
insertion is not needed.


   Ron




Juniper Business Use Only
From: Jeff Tantsura 
Sent: Saturday, September 21, 2019 4:32 PM
To: Chengli (Cheng Li) ; Ron Bonica 
Cc: SING Team ; EXT - daniel.bern...@bell.ca 
; SPRING WG List 
Subject: RE: [spring] A note on CRH and on going testing

Hi Ron,

Thanks for your comments, exactly, BSID MPLS label = CRH value :)

Cheers,
Jeff
On Sep 20, 2019, 11:09 AM -0700, Ron Bonica 
mailto:rbon...@juniper.net>>, wrote:
Hi Jeff,

It would be easy enough to add a binding SID to SRv6+. Given customer demand, I 
would not be averse to adding one.

However, there is another way to get exactly the same behavior on the 
forwarding plane without adding a new SID type.

Assume that on Node N, we have the following SFIB entry:


  *   SID: 123
  *   IPv6 address: 2001:db8::1
  *   SID type: prefix SID

Now assume that was also have the following route on Node N:

2001:db8::1 -> SRv6+ tunnel with specified destination address and CRH

This gives you the same forwarding behavior as a binding SID.

   Ron




Juniper Business Use Only
From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Jeff Tantsura
Sent: Thursday, September 19, 2019 10:53 PM
To: Chengli (Cheng Li) mailto:chengl...@huawei.com>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
Subject: Re: [spring] A note on CRH and on going testing

There’s number of solutions on the market that extensively use BSID for 
multi-domain as well as multi-layer signaling.

Regards,
Jeff

On Sep 19, 2019, at 19:49, Chengli (Cheng Li) 
mailto:chengl...@huawei.com>> wrote:
+1.

As I mentioned before, Binding SID is not only for shortening SID list.
We should see the important part of binding SID in inter-domain routing,  since 
it hides the details of intra-domain. Security and Privacy are always important.

Since the EH insertion related text will be removed from SRv6 NP draft, I don’t 
think anyone will still say we don’t need binding SID.
Let’s be honest, Encap mode Binding SID is very useful in inter-domain routing. 
It is not secure to share internal info outside a trusted network domain.

Cheng


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Bernier, Daniel
Sent: Thursday, September 19, 2019 11:36 PM
To: SING Team mailto:s.i.n.g.team.0...@gmail.com>>
Cc: 'SPRING WG List' mailto:spring@ietf.org>>
Subject: Re: [spring] A note on CRH and on going testing

+1

This is what we did on our multi-cloud trials.

Encap with Binding SID to avoid inter-domain mapping + I don’t need to have 
some sort of inter-domain alignment of PSSIs

Dan

On 2019-09-19, 11:18 AM, "spring on behalf of SING Team" 
mailto:spring-boun...@ietf.org> on behalf of 
s.i.n.g.team.0...@gmail..com<mailto:s.i.n.g.team.0...@gmail.com>> wrote:

Hi Andrew,

Good to hear that reality experiment :)

But is it secure to share internal SID-IP mappings outside a trusted network 
domain?

Or is there an analogue like Binding SID of SRv6, in SRv6+?

Btw, PSSI and PPSI can not do that now, right?

Best regards,
Moonlight Thoughts


(mail failure, try to cc to spring again.)

On 09/19/2019 17:49, Andrew Alston<mailto:andrew.als...@liquidtelecom.com> 
wrote:
Hi Guys,

I thought this may be of interest in light of discussions around deployments 
and running code - because one of the things we've been testing is inter-domain 
traffic s

Re: [spring] A note on CRH and on going testing

2019-09-19 Thread Chengli (Cheng Li)

Happy to hear that, many thanks Jeff. I think many people are/ will be aware of 
it.   :)

Regards,
Cheng

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Friday, September 20, 2019 10:53 AM
To: Chengli (Cheng Li) 
Cc: Bernier, Daniel ; SING Team 
; SPRING WG List 
Subject: Re: [spring] A note on CRH and on going testing

There’s number of solutions on the market that extensively use BSID for 
multi-domain as well as multi-layer signaling.

Regards,
Jeff

On Sep 19, 2019, at 19:49, Chengli (Cheng Li) 
mailto:chengl...@huawei.com>> wrote:
+1.

As I mentioned before, Binding SID is not only for shortening SID list.
We should see the important part of binding SID in inter-domain routing,  since 
it hides the details of intra-domain. Security and Privacy are always important.

Since the EH insertion related text will be removed from SRv6 NP draft, I don’t 
think anyone will still say we don’t need binding SID.
Let’s be honest, Encap mode Binding SID is very useful in inter-domain routing. 
It is not secure to share internal info outside a trusted network domain.

Cheng

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Bernier, Daniel
Sent: Thursday, September 19, 2019 11:36 PM
To: SING Team mailto:s.i.n.g.team.0...@gmail.com>>
Cc: 'SPRING WG List' mailto:spring@ietf.org>>
Subject: Re: [spring] A note on CRH and on going testing

+1

This is what we did on our multi-cloud trials.

Encap with Binding SID to avoid inter-domain mapping + I don’t need to have 
some sort of inter-domain alignment of PSSIs

Dan

On 2019-09-19, 11:18 AM, "spring on behalf of SING Team" 
mailto:spring-boun...@ietf.org> on behalf of 
s.i.n.g.team.0...@gmail.com<mailto:s.i.n.g.team.0...@gmail.com>> wrote:

Hi Andrew,

Good to hear that reality experiment :)

But is it secure to share internal SID-IP mappings outside a trusted network 
domain?

Or is there an analogue like Binding SID of SRv6, in SRv6+?

Btw, PSSI and PPSI can not do that now, right?

Best regards,
Moonlight Thoughts

(mail failure, try to cc to spring again.)

On 09/19/2019 17:49, Andrew Alston<mailto:andrew.als...@liquidtelecom.com> 
wrote:
Hi Guys,

I thought this may be of interest in light of discussions around deployments 
and running code - because one of the things we've been testing is inter-domain 
traffic steering with CRH on both our DPDK implementation and another 
implementation.

So - the setup we used last night:

6 systems in a lab - one of which linked to the open internet.  Call these S1 
-> S6
3 systems in a lab on the other side of the world - no peering between the 
networks in question.  Call these R1 -> R3

We applied a SID list on S1, that steered S1 -> S2 -> S3 -> S6 -> R1 -> R3, 
with the relevant mappings from the CRH SID's to the underlying addressing (S2 
had a mapping for the SID for S3, S3 had a mapping for the SID corresponding to 
S6, S6 had a mapping for the SID corresponding to R1 etc)

Then we sent some packets - and the test was entirely successful.

What this effectively means is that if two providers agree to share the SID 
mappings - it is possible to steer across one network, out over an open path, 
and across a remote network.  Obviously this relies on the fact that EH's 
aren't being dropped by intermediate providers, but this isn't something we're 
seeing.

Combine this with the BGP signaling draft - and the SID's can then be signaled 
between the providers - work still going on with regards to this for testing 
purposes.  Just as a note - there would be no requirement to share the full SID 
mapping or topologies when doing this with BGP - the requirement would be only 
to share the relevant SID's necessary for the steering.

I can say from our side - with various other providers - this is something that 
we see *immense* use case for - for a whole host of reasons.

Thanks

Andrew

___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/Spring
___
spring mailing list
spring@ietf.org<mailto: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] A note on CRH and on going testing

2019-09-19 Thread Chengli (Cheng Li)

+1.

As I mentioned before, Binding SID is not only for shortening SID list.
We should see the important part of binding SID in inter-domain routing,  since 
it hides the details of intra-domain. Security and Privacy are always important.

Since the EH insertion related text will be removed from SRv6 NP draft, I don’t 
think anyone will still say we don’t need binding SID.
Let’s be honest, Encap mode Binding SID is very useful in inter-domain routing. 
It is not secure to share internal info outside a trusted network domain.

Cheng


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Bernier, Daniel
Sent: Thursday, September 19, 2019 11:36 PM
To: SING Team 
Cc: 'SPRING WG List' 
Subject: Re: [spring] A note on CRH and on going testing

+1

This is what we did on our multi-cloud trials.

Encap with Binding SID to avoid inter-domain mapping + I don’t need to have 
some sort of inter-domain alignment of PSSIs

Dan

On 2019-09-19, 11:18 AM, "spring on behalf of SING Team" 
mailto:spring-boun...@ietf.org> on behalf of 
s.i.n.g.team.0...@gmail.com> wrote:

Hi Andrew,

Good to hear that reality experiment :)

But is it secure to share internal SID-IP mappings outside a trusted network 
domain?

Or is there an analogue like Binding SID of SRv6, in SRv6+?

Btw, PSSI and PPSI can not do that now, right?

Best regards,
Moonlight Thoughts


(mail failure, try to cc to spring again.)

On 09/19/2019 17:49, Andrew Alston 
wrote:
Hi Guys,

I thought this may be of interest in light of discussions around deployments 
and running code - because one of the things we've been testing is inter-domain 
traffic steering with CRH on both our DPDK implementation and another 
implementation.

So - the setup we used last night:

6 systems in a lab - one of which linked to the open internet.  Call these S1 
-> S6
3 systems in a lab on the other side of the world - no peering between the 
networks in question.  Call these R1 -> R3

We applied a SID list on S1, that steered S1 -> S2 -> S3 -> S6 -> R1 -> R3, 
with the relevant mappings from the CRH SID's to the underlying addressing (S2 
had a mapping for the SID for S3, S3 had a mapping for the SID corresponding to 
S6, S6 had a mapping for the SID corresponding to R1 etc)

Then we sent some packets - and the test was entirely successful.

What this effectively means is that if two providers agree to share the SID 
mappings - it is possible to steer across one network, out over an open path, 
and across a remote network.  Obviously this relies on the fact that EH's 
aren't being dropped by intermediate providers, but this isn't something we're 
seeing.

Combine this with the BGP signaling draft - and the SID's can then be signaled 
between the providers - work still going on with regards to this for testing 
purposes.  Just as a note - there would be no requirement to share the full SID 
mapping or topologies when doing this with BGP - the requirement would be only 
to share the relevant SID's necessary for the steering.

I can say from our side - with various other providers - this is something that 
we see *immense* use case for - for a whole host of reasons.

Thanks

Andrew


___
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] Regaining Focus on SRv6 and SRv6+

2019-09-09 Thread Chengli (Cheng Li)

Agree with Jingrong.

Suddenly, I am thinking about a question:
Does SRv6+ bring new value to the networking beyond SRv6?  What's the purpose? 
To compress the Routing header? Then we have many options to do that. Why a new 
RH with brand new routing scheme?

Let's do the standard works together once again, another 5 years? No!  I think 
we should solve the problem based on the existing solution, instead of  
creating a new mechanism.

>From the aspect of information theory, what's the new info added by SRv6+? 
>What is that for? These are the questions should be answered.

If we would like to provide an efficient encoding format, that is all right.. 
Please don't compare the length of RH only, since the length of DOH TLVs should 
be counted as well.
BTW, we already have C-SID, uSID and I believe there may be more options.

I don't think moving info from SRv6 SIDs to DOH TLVs is a good choice. Bad 
Performance of processing TLVs in DOH, and terrible scalability since only 5 
reserved types, or the 37 types when the CHG bit is reused. Also, how many 
bytes can be reduced by CRH. If you compare with C-SID, you will be surprised 
that C-SID provides a more efficient encoding mechanism for SRv6 than CRH.

The first DOH works for the destinations encoded in RH does not mean the info 
CAN NOT be carried in RH for per-segment processing.

How about let's focus on how to reduce the overhead of SRv6, that will be very 
helpful.

Best Regards,
Cheng

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Xiejingrong
Sent: Sunday, September 08, 2019 8:55 AM
To: Ron Bonica ; Robert Raszuk 
; Tom Herbert 
Cc: spring ; 6man <6...@ietf.org>
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+

the CHG bit is meaningful of hop-by-hop options, but is totally meaningless for 
Destination options.

CHG is meaningful for both.
Also I think the use of unique last-5bits of option is just a week 
recommendation.  There is still enough space of 8bit if needed. It's not 
necessary to change interpretation of CHG.

Thanks
Jingrong
From:Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>
To:Robert Raszuk mailto:rob...@raszuk.net>>;Tom Herbert 
mailto:t...@herbertland.com>>
Cc:spring mailto:spring@ietf.org>>;6man 
<6...@ietf.org>
Date:2019-09-08 06:32:00
SubjectRE: [spring] Regaining Focus on SRv6 and SRv6+

Robert,

You may need to rethink your argument. (That is, except for the part where you 
said that I was smart!)

The SRv6+ PPSI does replaces something int SRv6. But it does not replace the 
SRH's tags, flags or TLVs. It replaces the low order bits in the last SID.. 
More specially, it identifies a function to be executed by SR egress node.. It 
replaces functions like END.DT4, END.DT6, END.DX4, END.DX6, etc.)

As Tom says,  the CRH is much simpler to parse that the SRH. It contains only 
five fields, four of which are mandated by RFC 8200. (The other is the SID 
list.)

Unlike TLVs, the PPSI is fixed length (32 bits). It identifies an instruction 
to be executed on the SR egress node. Carries the same information as an MPLS 
service label or the low order bits of the final SID in as SRv6 SID list.

What you say about the IPv6 Option registry being nearly full may be a bit of 
an exaggeration. This is because the CHG bit is meaningful of hop-by-hop 
options, but is totally meaningless for Destination options. So, for 
destination options, the IPv6 option registry is actually 6 bits wide.

Ron

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Saturday, September 7, 2019 5:54 PM
To: Tom Herbert mailto:t...@herbertland.com>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; 
spring@ietf.org; 6...@ietf.org
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+

Dear Tom,

> The most obvious difference, besides SID size, is that SRV6 contains
> TLVs and SRV6+ doesn't.

I was hoping you know that this is not true at all so I skipped commenting on 
that aspect.

Folks promoting SRv6+ are smart and they know how to sell stuff which looks 
simple and innocent on the surface like concept of CRH with just fixed 
label/sid list while hide all complexity under the deep cover and only show 
little corners of it here and there hoping no one will connect the dots.

So what you call "complexity" has been just moved from routing header to 
destination options header and will be defined in number of different documents 
piece by piece.

Just please take a look at the proposal describing per path service 
instructions encoding. It does have Type Length and Value so to me looks like 
TLV structure going into IPv6 header.

4.
  The PPSI Option





   The PPSI Option contains the following fields:



   o  Option Type:

Re: [spring] Regaining Focus on SRv6 and SRv6+

2019-09-06 Thread Chengli (Cheng Li)

Hi Dirk,

Agree with the understanding of MPLS over UDP.

Also, I don’t think the performance of processing TLVs in DOH will be good, 
seems very complicated.

But I will not say which compression mechanism is better, since there maybe 
thousands of them, and we should not discuss this topic before requirements. 
Though we proposed a draft to describe the compressed SRH as well.

Let’s discuss the requirements before solution.

Cheng Li
Email: chengl...@huawei.com

From: Dirk Steinbergmailto:d...@lapishills.com>>
To: Robert Raszukmailto:rob...@raszuk.net>>;SPRING WG 
Listmailto:spring@ietf.org>>
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+
Time: 2019-09-06 22:53:00

I agree with Robert 100%.

If you want to use MPLS with IPv6, fine go ahead and
do so. All you need is already there. No need to
re-invent MPLS over UDP using a different encapsulation
inappropriately named "SRv6+".

SRv6 provides many distinct advantages over MPLS
but nobody is forced to use it. But for those who do,
let us continue to work on advancing SRv6 with uSID.

Cheers
Dirk
If you don't like

On Fri, Sep 6, 2019 at 4:37 PM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Tarek,

> OK, but how about traffic engineering (or source routing) in native IPv6 
> transport?

SRv6 or for that matter SRv6+ works on the basis of swapping dst address in the 
packets. So except segment endpoints all other routers in the domain are basic 
IPv6 nodes. It is native IPv6 transport.

So I look at SR as a service enhancing transport not a transport itself. It is 
IMO very very bad idea to think of SR as a new transport.

If you take that view of SR-MPLS_over_IP your SIDs are just 20 bits strings.. 
The bits sitting are SRH or CRH or just behind UDP header of rfc7510 are the 
exact same bits.

So what technically seems to be trivial by various religious and philosophical 
perspectives is being blown out of proportions with complete loss of real 
technical details under the hood.

Cheers,
R.

On Fri, Sep 6, 2019 at 4:16 PM Tarek Saad 
mailto:tsaad.@gmail.com>> wrote:
Robert,

If I understand your elaborate response, you hint to keeping MPLS as demux for 
services and native IPv4/IPv6 for transport.. which may not address bunch that 
religiously don’t want to enable MPLS.
OK, but how about traffic engineering (or source routing) in native IPv6 
transport? Seems SRv6+ solves that there – and vanilla IPv4/v6 does not.

Regards,
Tarek

From: Robert Raszuk mailto:rras...@gmail.com>>
Date: Friday, September 6, 2019 at 10:09 AM
To: Tarek Saad mailto:tsaad@gmail.com>>
Cc: Ron Bonica 
mailto:40juniper@dmarc.ietf.org>>, 
"spring@ietf.org" 
mailto:spring@ietf.org>>, 
"6...@ietf.org" <6...@ietf.org>
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+

Please see my elaborated note on that .

https://mailarchive.ietf.org/arch/msg/spring/qvRUp8SC2cWeIE5UhhU9aKGtpHM

Cheers,
R.

On Fri, Sep 6, 2019 at 4:03 PM Tarek Saad 
mailto:tsaad@gmail.com>> wrote:
Hi Robert,

>> * If operators choose not to use MPLS transport SR-MPLS can be easily 
>> transported over IPv4 or IPv6 vanilla data plane
I’m little confused about the above argument – given it starts with don’t want 
to use MPLS, can you clarify?

Regards,
Tarek

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Robert Raszuk mailto:rras...@gmail.com>>
Date: Friday, September 6, 2019 at 9:33 AM
To: Ron Bonica 
mailto:40juniper@dmarc.ietf.org>>
Cc: "spring@ietf.org" 
mailto:spring@ietf.org>>, 
"6...@ietf.org" <6...@ietf.org>
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+

Dear Ron,

I think you forgot few main points in the summary:

* Many operators use SR-MPLS successfully and it has been both standardized and 
successfully deployed in the network with interoperable implementations

* The overhead on the data plane of SRv6+ is very comparable to overhead of 
SR-MPLS

* The control plane extensions BGP, IGP are available for SR-MPLS and non are 
available for SRv6+

* SRv6+ requires a new mapping of SIDs to prefixes to be distributed by control 
plane

* If operators choose not to use MPLS transport SR-MPLS can be easily 
transported over IPv4 or IPv6 vanilla data plane

* Extensions for additional applications like L3VPNs or L2VPNs will require 
another set of protocol and implementation changes.

* If there are vendors who do not want to provide SR-MPLS SID mapping to IPv6 
addresses in their control planes let's focus standardization and industry work 
in this direction.

With all of the above I think it would be a serious mistake - at this point of 
time - to continue work on SRv6+ in the IETF.

Thank you,
Robert.

On Fri, Sep 6, 2019 at 3:08 PM Ron Bonica 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
Folks,

We have explored many facets of SRv6 and SRv6,

Re: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)

2019-09-06 Thread Chengli (Cheng Li)

Correct, that is what I want to say. Thanks Ketan for your information.

I think Ron understands the usage of Binding SID very well, but I am very 
curious about why he said there is no need to have a binding SID.



Cheng Li
Email: chengl...@huawei.com



From: Ketan Talaulikar (ketant)mailto:ket...@cisco.com>>
To: Jeff Tantsuramailto:jefftant.i...@gmail.com>>;Ron 
Bonicamailto:rbon...@juniper.net>>
Cc: Rob 
Shakirmailto:ro...@google.com>>;bruno.decraenemailto:bruno.decra...@orange.com>>;SPRING
 WG Listmailto:spring@ietf.org>>;Alexander 
Vainshteinmailto:alexander.vainsht...@ecitele.com>>
Subject: Re: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)
Time: 2019-09-06 13:59:51

I think the key point here is that BSID is not only as a means of “a shorthand 
that can be used to represent a list of SIDs”. Please see 
draft-ietf-spring-segment-routing-policy for the use-cases for BSID (including 
the one pointed by Jeff).

Besides BSID, we also have TI-LFA (draft-ietf-rtgwg-segment-routing-ti-lfa) and 
Microloop Avoidance (draft-bashandy-rtgwg-segment-routing-uloop) that require 
imposition of SID stack. This is for both SR/MPLS and SRv6.

For SRv6, we’ve always had the encap option for such imposition scenarios in 
draft-ietf-spring-srv6-network-programming and suggesting that is nothing new.

In fact, the most widely expected use-case for SRv6 is within a SR domain to 
transport customer packets transparently from an ingress PE to an Egress PE. 
This implies that the customer packets are encapsulated with an outer IPv6 
header (managed by the Service Provider). Insertion is discussed only in this 
context for this outer encap for BSID, TI-LFA, etc. and is something that is 
requested by operators within their network boundaries (e.g. see Robert’s 
emails explaining details). These considerations apply to SRv6 as well as other 
variants.

We (SPRING WG) have obviously to work with 6man to address the issues/concerns 
with IPv6 protocol related to SRH insertion and the authors have indicated the 
same (see Darren’s emails) and Bruno has clearly spelt out the agreement 
between WGs on this matter and the path forward 
(https://mailarchive.ietf.org/arch/msg/spring/ZFm_bQP1-C2f9xJuXtvEd9mLoxU). 
Let’s allow this work to progress in 6man.

Either the above points have not been understood or are being ignored and this 
whole insertion debate at this juncture and on this thread seems motivated to 
digress from the key questions polled by the WG chairs to operators. Seems more 
like an attempt to provoke the so-called “IPv6 orthodoxy” in 6man … which I say 
seem to have met with some success 

Thanks,
Ketan

From: spring  On Behalf Of Jeff Tantsura
Sent: 06 September 2019 10:37
To: Ron Bonica 
Cc: Rob Shakir ; bruno.decra...@orange.com; SPRING WG List 
; Alexander Vainshtein 
Subject: Re: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)

Thanks Ron!

I realize that, my intention was to bring up the case where BSID is currently 
used.
Regards,
Jeff

On Sep 5, 2019, at 21:15, Ron Bonica 
mailto:rbon...@juniper.net>> wrote:
Jeff,

In SRv6+ you can achieve this abstraction without a new SID type. In order to 
do this, network operators:

  *   Associate an IPv6 address with the abstract segment
  *   Instantiate policy on abstract segment ingress nodes. The policy causes 
the abstract segment ingress nodes to encapsulate packets destined for the 
above mentioned IPv6 address in an IPv6 header with its own CRH. This IPv6 
header and CRH define the abstracted segment
Now, the only problem is to get packets to the abstract segment ingress node 
with the right IPv6 destination address. This can be achieved by associated a 
node SID in the original packet with the above mentioned IPv6 address.

And again, if network operators object to this approach, it would be easy 
enough to add a binding SID to SRv6+. However, to date, no operator has 
expressed interest.


Ron



Juniper Business Use Only
From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Sent: Thursday, September 5, 2019 2:10 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
Rob Shakir mailto:ro...@google.com>>; 
bruno.decra...@orange.com; Ron Bonica 
mailto:rbon...@juniper.net>>
Cc: SPRING WG List mailto:spring@ietf.org>>
Subject: Re: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)

Ron,

another, and quite important use of BSID in SR-MPLS is to provide an anchor 
point to another domain/layer and an abstraction to program this layer without 
understanding its semantics.
SR/RSVP-TE or IP/Opto would be a perfect example of that, 
draft-anand-spring-poi-sr describes such case.

Cheers,
Jeff
On Sep 5, 2019, 10:39 AM -0700, Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf..org>>,
 wrote:
Hi Alexander,

SRv6+ does not currently define a

Re: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)

2019-09-06 Thread Chengli (Cheng Li)

Hi Ron,

Binding SID is very useful in inter-domain routing, not only for shortening SID 
list, but also for security and privacy.

So I think Binding SID is a good design for any kind of Source Routing paradigm.

The only problem we should discuss is that how to handle it.But I doubt the 
cost of encapsulating a new IPv6 header.

Regards,
Cheng



Cheng Li
Email: chengl...@huawei.com



From: Ron 
Bonicamailto:rbonica=40juniper@dmarc.ietf.org>>
To: Alexander 
Vainshteinmailto:alexander.vainsht...@ecitele.com>>;Rob
 
Shakirmailto:ro...@google.com>>;bruno.decraenemailto:bruno.decra...@orange.com>>
Cc: SPRING WG Listmailto:spring@ietf.org>>
Subject: Re: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)
Time: 2019-09-06 01:39:25

Hi Alexander,

SRv6+ does not currently define a binding SID. If one were ever needed, it 
would be easy enough to specify and implement. When a segment endpoint 
encountered a binding SID, it would:


  *   Decrement Segments Left
  *   Copy an IPv6 address from the SFIB to the IPv6 destination address
  *   Prepend an IPv6 header with its own CRH to the packet. Information 
required build that header and CRH would be found in the SFIB

However, I don’t think that SRv6+ will ever need a binding SID. A binding SID 
is a shorthand that can be used to represent a list of SIDs. Since SRv6+ SIDs 
are already short, this shorthand isn’t needed.

But, again, if we ever needed a binding SID for another reason, we could add it.


   Ron




Juniper Business Use Only
From: spring  On Behalf Of Alexander Vainshtein
Sent: Wednesday, September 4, 2019 6:49 AM
To: Rob Shakir ; bruno.decra...@orange.com
Cc: SPRING WG List 
Subject: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)

Rob, Bruno and all,
I have a naive question based, most probably, on insufficient understanding of 
SRv6 (not to mention SRv6+).
This question has been prompted by the complaints (on the Beyond SRv6 thread) 
about problems with supporting long lists of 128-bits of SIDs in the IPv6 
Segment Routing Headers, and various approaches to mitigating these complaints.



Section 5 of RFC 
8402
 defines Binding Segments (BSIDs) and says that “he BSID is bound to an SR 
Policy, instantiation of which may involve a list of SIDs.”   It also explains 
that BSIDs facilitate better scalability (among other things) of SR.  And, as 
is appropriate for the architecture document, RFC 8402 does not differentiate 
between SR-MPLS and SRv6 in the definition of Binding segments.



The 
SR-MPLS
 draft (already approved for publication as an RFC)  mentions (e.g., in the 
example in Section A.3.2) that the node that has allocated a BSID label 1023 
for a specific SR policy FEC-1 for which it is the head-end “installs a transit 
MPLS forwarding entry to SWAP incoming label=1023, with outgoing labels and 
outgoing interface determined by the SID-List for FEC1”. This explanation is 
fully compatible with the MPLS architecture where the top label of the label 
stack can be swapped with multiple new labels.



Can somebody please explain how (if at all) are Binding Segments going to be 
supported in SRv6 and/or in SRv6+?

To the best of my (admittedly, limited) understanding of IPv6, no equivalent of 
the SR-MPLS handling of the BSID is allowed with the IPv6 routing headers as 
per RFC 
8200.
 For the reference, the IPv6 Segment Routing 
Header
 draft does not mention Binding SIDs at all.



>From my POV, if Binding segments cannot be supported with SRv6 or SRv6+, a 
>Technical Erratum on 8402 should posted.

Did I miss something here?

Your timely feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office:

[spring] 答复: Approaches to MTU efficiency in SRv6 in todays SPRING session

2019-07-26 Thread Chengli (Cheng Li)

Hi Dirk,

I really agree with on the explanation of SRv6 SID. We also think the design of 
128-bits SRv6 SID is a good idea.

Also, we can not avoid the fact that 128 bits are a little bit long when the 
SID list is long , and the overhead can not be ignore.  We can use the binding 
SID to release the pressure.  But also, if you take a look from another angle, 
you will see that there are some redundant bits in the Segment that can be 
removed. Especially when the common prefix is long. So why not we just get rid 
of the redundant in SID list to get a smaller overhead without any affect on 
the functionalities of SRv6.

Also, one modification for now and the future, for all the SIDs. We only need 
to make once modification and it fits to all SRv6 functionalities. That is what 
we have done in draft 
https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00.


If possible, you can take a look of the section 7, which describes the benefits 
of this solution:
* Seamless integration with SRv6 Network Programming
* Supporting Full Set Functionalities of SRv6
* Control-Plane friendly
* Hardware-friendly
* Efficient MTU overhead(the most important part that all solutions would like 
to solve.)
* Scalable SR TE
* Saving IPv6 address(Burning /16 or 32/bit address in SID space is expensive)

Thanks,
Cheng





发件人: spring [spring-boun...@ietf.org] 代表 Dirk Steinberg [d...@lapishills.com]
发送时间: 2019年7月25日 20:32
收件人: Mark Smith
抄送: SPRING WG
主题: Re: [spring] Approaches to MTU efficiency in SRv6 in todays SPRING session


Am 25.07.2019 um 02:49 schrieb Mark Smith 
mailto:markzzzsm...@gmail.com>>:

On Thu., 25 Jul. 2019, 02:20 Dirk Steinberg, 
mailto:d...@lapishills.com>> wrote:
Hi All,

in todays SPRING session we have heard concerns about
MTU efficiency in certain use cases involving SRv6.

It is true that using 128 bit SRv6 SIDs trades scalability
and flexibility against MTU overhead. There will certainly
be use cases where the additional overhead may be
justified.

I can understand the convenience of SIDs being the same size as the underlying 
layer identifier. However, do they have to be?

128 bit SIDs is literally more SID values than there will ever be IPv6 unicast 
addresses (multicast has 1/8th the space). It's a larger space than the number 
of nodes than can be attached to the entire IPv6 Internet.

What size would SIDs be if they were dimensioned only for the SR functions 
they're being and going to be used for, rather than just being sized to the 
lower layer identifier value?

If MPLS based SIDs are 20 bits, and they do not have any SR functional 
constraints, I think that suggests SIDs can be far smaller than 128 bits, which 
then addresses the overhead problem 128 bit SIDs creates.

It is important to understand that 128 bit SIDs in SRv6
in most cases are semantically equivalent to 2 SIDs in
SR-MPLS. This is because the SID contains both a
locator and a function part (and optionally also an argument).

For example, assuming a 64:64 bit split in SRv6 the 64 bit locator
identifies the router whereas the 64 bit function part identifies
the function (plus optional arguments) which could be a VPN
or an adjacency.

So one SID in SRv6 is equivalent to one transport label plus
one service label in MPLS. For a typical VPN use case that
would be a 2 label stack consisting of the LDP or SR transport
label leading to the egress PE and the VPN label.
The same use case in SRv6 uses only one single SID.

When doing an apples-to-apples comparison of SID sizes
to MPLS label sizes the proper comparison would be
64 bit  (for example, could also be longer or shorter) in SRv6
to 20 bit in MPLS.

The 20 bit label size in MPLS is a serious limitation for
large-scale networks and data centers.

Adding uSID into the picture allows the network architect to make
his own choice regarding the tradeoff between identifier length
and MTU overhead. He may choose to use 64 bits or he can choose
to use 16 bit SRv6 uSIDs. Note that the 16 bit size for uSID is
only an example and in principle the designer could also choose
to use a different length for uSID, i.e. 32 bit.

Also note that when using SRv6 uSID the semantics regarding
locator and function are again like in MPLS, meaning that one
uSID does NOT designate both locator and function but only one
of the two. For a VPN use case you would need 2 uSIDs just like
in MPLS.

Assuming the vendor implementation of 32 bit uSID in SRv6 in
addition to 16 bits uSIDs the network designer would have a full
choice of identifier length: 16 bit, 32 bit (uSID) and 64 bit
(full SRv6 SID).

For other uses cases where MTU efficiency is a major concern
the answer within the SRv6 framework is SRv6 uSID.

Another proposal to address the MTU efficiency problem today
advertised itself as basically using the same semantics as MPLS
encapsulated in IPv6 and also noted that SRv6 deviates from
legacy MPLS regarding label semantics.

This is exactly the point.

Not being

[spring] 答复: Questions about the life span of Path Segment

2019-07-26 Thread Chengli (Cheng Li)

Hi Sasha,

Many thanks for you comments and sorry for my delay. Please see my reply inline.

Cheng


发件人: spring [spring-boun...@ietf.org] 代表 Alexander Vainshtein 
[alexander.vainsht...@ecitele.com]
发送时间: 2019年7月24日 23:27
收件人: draft-ietf-spring-mpls-path-segment.auth...@ietf.org
抄送: spring@ietf.org
主题: [spring] Questions about the life span of Path Segment

Dear colleagues,
I have a couple of questions about the life span of the Path Segment.

Suppose that some entity has computed and instantiated an SR LP that follows a 
specific path from the ingress node to the  egress node across a single IGP 
domain. This path is expressed as a sequence of valid IGP Segments (e.g., Node 
and/or Adjacency segments) .
Suppose also that a Path Segment has been allocated by the egress node for this 
path, and the ingress node is aware of this and inserts the label acting as the 
SID for the Path segments immediately after the last SID of the path.

Now my questions:

1.   What happens to the Path Segment when one of the IGP segments defining 
the original path fails?

a.   To the best of my understanding the path itself becomes invalid

[Cheng] Agree. But IMO, the path segment has the same life circle with the 
associated LSP. so it MAY not be invalid in FRR since the egress, ingress even 
the controller does not know that until the Reroute is triggered, then it 
should be treated as invalid.


b.   Will the Path Segment that identifies the now invalid path be retained 
indefinitely, or would it be invalidated as well and the label acting as its 
SID released?

[Cheng] Honestly, I think it depends on implementation. The the LSP fails, then 
the related Path Segment is invalid. But when the Rerouted LSP is installed, 
the path segment should be allocated, and we don't make any assumption of the 
value of the path segment. It CAN be the same value as the previous one.


2.   Suppose that the entity that has computed and instantiated the 
original path re-computes it and instantiate a new valid path.

a.   Should the new path (that replaces the invalidated original one) be 
allocated with the same Path Segment as the original path, or should a new Path 
Segment be allocated for it?

[Cheng] Same as above. As long as the information is synchronized between the 
controller and the data plane, any value is OK. But the same path segment 
should be recommended.



b.   If the Path Segment allocated for the invalidated path is released 
(see (1b) above), can the label that identified it be re-used as the Path 
Segment ID immediately, or only after some delay?

[Cheng] It depends on the implementation. Just to make sure that the path 
segment can be available.


From my POV the answers to these questions do not depend on the actual method 
by which the Path Segments are allocated and propagated from the egress node to 
the ingress one.
And while my questions explicitly mention IGP Segments that define the SR LSP 
for which the Path Segment is allocated, the desired behavior should not depend 
on the type of segments used in the definition of the path.
[Cheng] Sure.

Your feedback would be highly appreciated.

Regards, and lots of thanks in advance,
[Cheng] Thank you as well for valuable comments.
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] Request for comments of draft-li-6man-srv6-path-segment-encap-00.txt

2019-07-08 Thread Chengli (Cheng Li)

Hi 6man and SPRING,

We submitted a new draft in 6man WG to describe the encoding and processing of 
SRv6 Path Segment, called draft-li-6man-srv6-path-segment-encap-00.txt.

In several use cases, such as binding bidirectional path and end-to-end 
performance measurement the ability to implement path identification is a 
pre-requisite.  

In SRv6, an SRv6 path can be identified by the content of the segment list. 
However, the segment list may not be a good key to identify an SRv6 path, since 
the length of segment list is too long and flexible according to the number of 
SIDs.  Therefore, I-D.li-spring-srv6-path-segment defines SRv6 Path Segment in 
order to identify an SRv6 path.

This document defines the encoding and processing of SRv6 Path Segment in SRv6 
networks.

Welcome to review the document, and hope we can have your valuable comments.

Best Regards,
Cheng


-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, July 08, 2019 9:39 PM
To: Weiqiang Cheng ; Dhruv Dhody 
; Chengli (Cheng Li) ; Lizhenbin 

Subject: New Version Notification for 
draft-li-6man-srv6-path-segment-encap-00.txt


A new version of I-D, draft-li-6man-srv6-path-segment-encap-00.txt
has been successfully submitted by Cheng Li and posted to the IETF repository.

Name:   draft-li-6man-srv6-path-segment-encap
Revision:   00
Title:  Encapsulation of Path Segment in SRv6
Document date:  2019-07-08
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/internet-drafts/draft-li-6man-srv6-path-segment-encap-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-li-6man-srv6-path-segment-encap/
Htmlized:   
https://tools.ietf.org/html/draft-li-6man-srv6-path-segment-encap-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-li-6man-srv6-path-segment-encap


Abstract:
   Segment Routing (SR) allows for a flexible definition of end-to-end
   paths by encoding paths as sequences of sub-paths, called "segments".
   Segment routing architecture can be implemented over IPv6 data plane,
   called SRv6.  In some use-cases such as end-to-end SR Path Protection
   and Performance Measurement (PM), SRv6 path need to be identified.
   This document defines the encoding and processing of Path Segment in
   SRv6 networks.


  


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.

The IETF Secretariat

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

[spring] Welcome to review draft-li-spring-srv6-path-segment-01, comments are always welcome!

2019-06-28 Thread Chengli (Cheng Li)

Hi WG,

We just submitted the new revision of draft-li-spring-srv6-path-segment, 
welcome to review! Comments are always welcome!

SR path should be identify in some use cases like performance measurement(delay 
measurement, etc.).  SR-MPLS Path Segment[1] is proposed by 
draft-ietf-spring-mpls-path-segment-00, which is adopted by our WG recently.

In SRv6, an SRv6 path can be identified by SID list.  However,  the segment 
list may not be a good key to identify an SRv6 path,  since the length of 
segment list is too long and flexible according to the number of SIDs. 

This document proposes SRv6 Path Segment to identify an SRv6 path instead of 
SID list.  

Since the content is stable and mature, we would like to request for WG review 
and ask for WG adoption.

Best Regards,
Cheng

[1] https://tools.ietf.org/html/draft-ietf-spring-mpls-path-segment-00


-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Friday, June 28, 2019 4:04 PM
To: Rakesh Gandhi ; Lizhenbin ; 
Weiqiang Cheng ; Dhruv Dhody 
; Mach Chen ; Dongjie (Jimmy) 
; Mach Chen ; Chengli (Cheng Li) 

Subject: New Version Notification for draft-li-spring-srv6-path-segment-01.txt


A new version of I-D, draft-li-spring-srv6-path-segment-01.txt
has been successfully submitted by Cheng Li and posted to the IETF repository.

Name:   draft-li-spring-srv6-path-segment
Revision:   01
Title:  Path Segment for SRv6 (Segment Routing in IPv6)
Document date:  2019-06-26
Group:  Individual Submission
Pages:  8
URL:
https://www.ietf.org/internet-drafts/draft-li-spring-srv6-path-segment-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-li-spring-srv6-path-segment/
Htmlized:   https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-li-spring-srv6-path-segment
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-li-spring-srv6-path-segment-01

Abstract:
   Segment Routing (SR) allows for a flexible definition of end-to-end
   paths by encoding paths as sequences of topological sub-paths, called
   "segments".  Segment routing architecture can be implemented over an
   MPLS data plane as well as an IPv6 data plane.

   Further, Path Segment has been defined to identify an SR path in SR-
   MPLS networks, and used for various use-cases such as end-to-end SR
   Path Protection and Performance Measurement (PM) of an SR path.
   Similar to SR-MPLS, this document defines Path Segment in SRv6
   networks to identify an SRv6 path.


  


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.

The IETF Secretariat

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

Re: [spring] IPR Poll: draft-xuclad-spring-sr-service-programming

2019-06-28 Thread Chengli (Cheng Li)

Hi Chairs,

I am not aware of any IPR related to this draft.

Best Regards,
Cheng


From: Rob Shakir [mailto:ro...@google.com]
Sent: Thursday, June 27, 2019 2:14 PM
To: draft-xuclad-spring-sr-service-programm...@ietf.org; SPRING WG List 

Subject: IPR Poll: draft-xuclad-spring-sr-service-programming

Hi Authors, SPRING WG,

In parallel to the call for working group adoption for 
draft-xuclad-spring-sr-service-programming we would like to poll for IPR.

If you are aware of IPR that applies to draft-xuclad-sr-service-programming 
please respond to this email. If you are aware of IPR, please indicate whether 
it has been disclosed in accordance to the IETF IPR rules (detailed are 
described in RFCs 3979, 4879, 3669 and 5378).

If you are an author or contributor please respond to this email regardless of 
whether or not you're aware of any IPR. If you are not an author or 
contributor, please explicitly respond only if you're aware of IPR that has not 
yet been disclosed.

This document will not advance into the working group until such time as we 
have received IPR confirmations from all authors and contributors.

Thanks!
Rob & Bruno
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call: draft-guichard-spring-nsh-sr

2019-06-27 Thread Chengli (Cheng Li)

Yes, support. This draft is useful for scenarios where SFs support NSH and do 
not support SR,  and SFFs support SR, which is a common use case in networking 
migration from non-SR to SR.

Well , I think the details of the mechanism should be described in the future 
revision.

Thanks to authors’ contributions!

Regards,
Cheng



From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Thursday, June 27, 2019 2:14 PM
To: SPRING WG List 
Subject: [spring] WG Adoption Call: draft-guichard-spring-nsh-sr

Hi SPRING WG,

This email initiates a two week working group adoption call for 
draft-guichard-spring-nsh-sr. This follows the discussion that we had in the 
last few IETF meetings, and particularly the focused discussion we had at IETF 
104 regarding service chaining and SPRING.

Please indicate your support, comments, or objections for adopting this draft 
by Wednesday July 10th, 2019.. We are particularly interested in hearing from 
WG members who are not authors of this draft, and those folks that are willing 
to spend time working on this draft after adoption.

We are also looking for volunteers who can provide a technical review of the 
content of the draft at a later stage of its progress through the working group 
(e.g., before WGLC).

In parallel - we'll send an IPR poll to the working group and authors. The 
currently disclosed IPR can be found in the 
datatracker.

Thanks!
Rob & Bruno.


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

[spring] A Light Weight iOAM in SRv6 to eliminate the large overhead of IOAM metadata

2019-03-27 Thread Chengli (Cheng Li)

Hi iOAMers,

We proposed a light SRv6 iOAM method in SPRING: 
https://tools.ietf.org/html/draft-li-spring-light-weight-srv6-ioam-00

In our method, the IOAM data can reuse the space of SID list, which won't 
extend the length of header.

It may be a complementary solution to solve the problem of large overhead of 
IOAM packets, which is a pain for hardware.

Hope it help your discussion in IOAM side meetings.

Also copy to Spring and 6man since there two WGs are related to this draft.

Comments and questions are welcome!

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

Re: [spring] How to support OAM on SR networks ?

2019-03-19 Thread Chengli (Cheng Li)

Hi Kals,

Path Segment can be used for identifying a LSP/SR Path in SR-MPLS networks.

With a path segment, use cases like passive Packet loss measurement, 
bidirectional path association can be done in SR-MPLS.

You can read the document of Path Segment[1], which becomes a WG document 
recently.

Basically, a Path Segment is inserted at the bottom of the label stack(as long 
as it can be read by the egress node).

Also, for easier identifying an SRv6 SID list, SR candidate path, SR policy, an 
SRv6 Path Segment is proposed in [2]’

Hope my answers help you.

[1]. https://tools.ietf.org/html/draft-ietf-spring-mpls-path-segment-00
[2]. https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-00

Thanks,
Cheng


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of tech_kals Kals
Sent: Friday, March 15, 2019 1:16 PM
To: Stefano Previdi (sprevidi) ; Clarence Filsfils 
(cfilsfil) ; Ahmed Bashandy (bashandy) 
; Les Ginsberg (ginsberg) ; Peter 
Psenak (ppsenak) ; spring@ietf.org
Subject: Re: [spring] How to support OAM on SR networks ?

please ignore my previous email..


hi,

can someone answer my question please ?

thanks,
kals


On Fri, Mar 15, 2019 at 10:44 AM tech_kals Kals 
mailto:tech.k...@gmail.com>> wrote:
Hi,

Can someone have a look at this issue ?

thanks,
__kals__


On Wed, Mar 13, 2019 at 10:49 AM tech_kals Kals 
mailto:tech.k...@gmail.com>> wrote:
Hi experts,

Am so curious to know about how OAM can be supported on segment-routing 
networks ?



I think, MPLS OAM is not possible with SR as network infrastructure doesn't 
have any LSP state.



With SDN controller in place, do we really need traditional OAM ?

Assume, SDN controller can identify the issue on the network, and it can 
configure an alternate path on the defected node.



If SDN controller can do OAM, but at what cost (like BGP-LS) ?



Thanks,

__Kals__


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

Re: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming

2019-03-13 Thread Chengli (Cheng Li)

Support.

The solution defined in this document has been implemented by several vendors 
and open source data plane,
and I think it is ready to be adopted for better help on implementation.

My comments regarding USD/PSP/USP have been addressed, hope to see the correct 
text in the next version.

Thanks,
Cheng

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Thursday, March 14, 2019 2:50 AM
To: SPRING WG 
Cc: draft-filsfils-spring-srv6-network-programm...@ietf.org
Subject: [spring] Working Group Adoption Call for 
draft-filsfils-spring-srv6-network-programming


Hi SPRING WG,



This email initiates a three week call for working group adoption for 
draft-filsfils-spring-srv6-network-programming. (Three weeks to account for the 
IETF week)



Please indicate your support, comments, or objection, for adopting this draft 
as a working group item by April, 3rd, 2019 (aka 2019-04-03)

We are particularly interested in hearing from working group members that are 
not co-authors of this draft.



We are also looking for volunteers who would be ready to perform a technical 
review of this work at some later stage, such as before or during WG the last 
call.



In parallel to this adoption call, I will send an IPR call for this document. 
We will need all authors and contributors to confirm their IPR position on this 
document.

There is currently 1 IPR filled (2)



(1)  
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07

(2)  
https://datatracker.ietf.org/ipr/search/?id=draft-filsfils-spring-srv6-network-programming=draft





Thank you,

--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

Re: [spring] Working Group Adoption Call for draft-cheng-spring-mpls-path-segment

2019-03-07 Thread Chengli (Cheng Li)

Hi Ketan, 

Thank you for your support and comments, please see my reply inline.

Regards,
Cheng


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Ketan Talaulikar 
(ketant)
Sent: Wednesday, February 27, 2019 12:20 PM
To: bruno.decra...@orange.com; SPRING WG 
Cc: draft-cheng-spring-mpls-path-segm...@ietf.org
Subject: Re: [spring] Working Group Adoption Call for 
draft-cheng-spring-mpls-path-segment

Hello,

I support the adoption of this draft by the WG. I have some comments which I 
would like to bring to the author's and WG though - some of these were raised 
when this draft was presented in Bangkok but I don't see them addressed as yet.

1) Sec 2.
A Path Segment is a single label that is assigned from the Segment
   Routing Local Block (SRLB) or Segment Routing Global Block (SRGB) of
   the egress node of an SR path.

KT> Why can't the Path Segment be allocated from the dynamic MPLS label pool on 
the egress node? Can this be added as discussed in Bangkok? This mode would 
help achieve a good scalability for SR Policies along with the option of using 
SRLB. On the other hand, I do not understand the use-case for allocating Path 
Segments from the SRGB. If there is none, do we want to preclude SRGB usage for 
Path Segments?

[Cheng] Yes, path segment can be allocated from dynamic MPLS lable pool as we 
answered you at Bangkok. We will add text to specify that. Regarding SRGB, We 
won't suggest to allocate path segment from SRGB due to scalability 
consideration, but we don't stop people to do that.


2) Can the authors clarify on the relationship and usage of Path Segment with 
Entropy label 
(https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-12)? There 
are examples of nested segments. Similarly, the draft could use some text to 
discuss the MSD capabilities of the headend when enabling path segment usage.

[Cheng] Regarding EL, I think it can be pushed before or after path segment, it 
does not matter. But we would suggest to place path segment before EL.
Only need to make sure that path segment to be read by the egress node.
Thus, it should be placed after the "routing segment（adj/node/prefix）" pointing 
to the egress node.

Thanks, will add text to describe MSD.


3) This seems SR/MPLS specific to me. Is that correct? If so, why put reference 
to SRv6 documents in there as that would create confusion?
[Cheng] Correct, will delete those references.

Thanks,
Ketan

-Original Message-
From: spring  On Behalf Of bruno.decra...@orange.com
Sent: 20 February 2019 14:34
To: SPRING WG 
Cc: draft-cheng-spring-mpls-path-segm...@ietf.org
Subject: [spring] Working Group Adoption Call for 
draft-cheng-spring-mpls-path-segment

Hi SPRING WG,

This email initiates a two week call for working group adoption for 
draft-cheng-spring-mpls-path-segment.

Please indicate your support, comments, or objection, for adopting this draft 
as a working group item by March 6th 2019.
We are particularly interested in hearing from working group members that are 
not co-authors of this draft.
We are also looking for volunteers who would be ready to perform a technical 
review of this work at some later stage, such as before or during WG the last 
call.

Additionally, there are currently 7 authors listed on this document. Please 
trim this to <= 5 front-page authors, utilising a "Contributors" section if 
required for the others. An approach to achieving this would be to list ~2 
editors as the front-page authors.

In parallel to this adoption call, I will send an IPR call for this document. 
We will need all authors and contributors to confirm their IPR position on this 
document.

(1) https://tools.ietf.org/html/draft-cheng-spring-mpls-path-segment

Thanks,
--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

Re: [spring] draft-filsfils-spring-srv6-network-programming

2019-03-06 Thread Chengli (Cheng Li)

Hi Pablo,

Great!!  Thank you for solving my confusion. It confuses me a long time.

It is very happy to know I am correct.  Haha.

Thanks,
Cheng



From: Pablo Camarillo (pcamaril) [mailto:pcama...@cisco.com]
Sent: Wednesday, March 06, 2019 5:27 PM
To: Chengli (Cheng Li) 
Cc: spring@ietf.org; Lizhenbin 
Subject: Re: draft-filsfils-spring-srv6-network-programming

Hi Cheng,

Thanks for the support. In reply to your questions:
1.- Alignment with the latest SRH draft.
2.- The End, End.X or End.T behaviors cannot be the last SID of the SID list 
unless combined with the USD flavor (or USP) in which case they can be the last 
SID. I will review the text and make the editorial changes if needed to make 
sure this is clear (your last sentence).

Thanks,
Pablo.

From: "Chengli (Cheng Li)" mailto:chengl...@huawei.com>>
Date: Wednesday, 27 February 2019 at 09:31
To: "Pablo Camarillo (pcamaril)" 
mailto:pcama...@cisco.com>>, 
"spring@ietf.org<mailto:spring@ietf.org>" 
mailto:spring@ietf.org>>
Cc: Lizhenbin mailto:lizhen...@huawei.com>>
Subject: RE: draft-filsfils-spring-srv6-network-programming

Support.  The content of these drafts has been stable for a while, I think they 
are ready to progress.

I have some comments regarding to PSP, USP and USD flavors in 
draft-filsfils-spring-srv6-network-programming-07.

1:What is the motivation for introducing the USD flavor?  With USD, 
then the END, END.T and END.X can be the last SID?

2:In 
section-4.1<https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-06#section-4.1>
 , 4.2 and 4.3, the document says that End, End.X, End.T can not be the last 
SID of SID list.

But in 
section-4.21.2<https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-06#section-4.21.2>,
 the End, End.X, and End.T can be the last SID when there is another SRH 
following.

Even, in that case, the last SID of the SID list MUST be SID of 
End, End.X, and End.T, correct?

If End, End.X, End.T can not be the last SID of SID list, then 
USP of End, End.X, End.T can not work.

So I think the text should be: End, End.X, and End.T SID can be the last SID if 
(1) it has USD flavor or (2) it has USP flavor while there is another SRH 
following it.


Thanks,
Cheng

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Pablo Camarillo 
(pcamaril)
Sent: Thursday, February 14, 2019 4:56 PM
To: spring@ietf.org<mailto:spring@ietf.org>
Subject: [spring] draft-filsfils-spring-srv6-network-programming

Dear Spring,

We have submitted a new revision of 
draft-filsfils-spring-srv6-network-programming. There are several minor updates 
to the document, mainly addressing ICMP and having better alignment with SRH 
draft. Also, based on WG feedback, we have split the document moving the 
illustrations into a new informational draft.
As always, any feedback or question is more than welcome.
https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-network-programming/
https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-net-pgm-illustration/

We believe that the content of both drafts is mature and has been stable since 
the first revision in March 2017. We are tracking several opensource and vendor 
proprietary implementations. Some of these have actually participated in a 
public interop more than a year ago.
For these reasons we believe that both documents are ready to progress and be 
adopted by the working group.

Thanks,
Pablo (on behalf of authors)

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

Re: [spring] draft-filsfils-spring-srv6-network-programming

2019-02-27 Thread Chengli (Cheng Li)

Support.  The content of these drafts has been stable for a while, I think they 
are ready to progress.

I have some comments regarding to PSP, USP and USD flavors in 
draft-filsfils-spring-srv6-network-programming-07.

1:What is the motivation for introducing the USD flavor?  With USD, 
then the END, END.T and END.X can be the last SID?

2:In 
section-4.1
 , 4.2 and 4.3, the document says that End, End.X, End.T can not be the last 
SID of SID list.

But in 
section-4.21.2,
 the End, End.X, and End.T can be the last SID when there is another SRH 
following.

Even, in that case, the last SID of the SID list MUST be SID of 
End, End.X, and End.T, correct?

If End, End.X, End.T can not be the last SID of SID list, then 
USP of End, End.X, End.T can not work.

So I think the text should be: End, End.X, and End.T SID can be the last SID if 
(1) it has USD flavor or (2) it has USP flavor while there is another SRH 
following it.

Thanks,
Cheng

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Pablo Camarillo 
(pcamaril)
Sent: Thursday, February 14, 2019 4:56 PM
To: spring@ietf.org
Subject: [spring] draft-filsfils-spring-srv6-network-programming

Dear Spring,

We have submitted a new revision of 
draft-filsfils-spring-srv6-network-programming. There are several minor updates 
to the document, mainly addressing ICMP and having better alignment with SRH 
draft. Also, based on WG feedback, we have split the document moving the 
illustrations into a new informational draft.
As always, any feedback or question is more than welcome.
https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-network-programming/
https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-net-pgm-illustration/

We believe that the content of both drafts is mature and has been stable since 
the first revision in March 2017. We are tracking several opensource and vendor 
proprietary implementations. Some of these have actually participated in a 
public interop more than a year ago.
For these reasons we believe that both documents are ready to progress and be 
adopted by the working group.

Thanks,
Pablo (on behalf of authors)

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

Re: [spring] [mpls] to progress draft-cheng-spring-mpls-path-segment

2019-02-24 Thread Chengli (Cheng Li)

Hi Loa and Greg,

Yes, you are right.

The "B->C SubPath" in the first figure needs to be identical to the "B->C 
SubPath" in the second.

Many thanks for your discussion on this, a very interesting question!

Thanks,
Cheng

-Original Message-
From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Loa Andersson
Sent: Saturday, February 23, 2019 4:16 PM
To: Greg Mirsky 
Cc: m...@ietf.org; spring ; Weiqiang Cheng 
; draft-cheng-spring-mpls-path-segm...@ietf.org
Subject: Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment

Greg,



On 2019-02-23 12:31, Greg Mirsky wrote:
> Hi Loa,
> another tunnel with the Path segment from node C is, in my view, very 
> close to SPME tunnel. The Path segment from C is needed because Path 
> segment from D is not known to the node C, cannot be associated with 
> the right SR-tunnel segment, i.e., tunnel B-C. The fate sharing may be 
> achieved by using exactly the same SIDs as in the A-D tunnel for the 
> B-C segment. And GAL is still BoS on B-C tunnel. Are we getting closer?

Not sure, you lose me somewhere between the "B", "C", "D", "from" and "another".

So let me check I was talking about

So the stack transporting payload from B-C looks like this:

 ++
 ~B->C SubPath~
 ++
 |s-PSID(B->C)|
 ++
 | BSID(C->D) |
 ++
 |e-PSID(A->D)|
 ++
figure 1

The "~" at the top means that there might be more than one label that can be 
popped or swapped, right?

So the stack transporting GACh from B-C looks like this:

 +--+
 ~ B->C SubPath ~
 +--+
 | GAL  |
 +--+
 |  GACh info-1 |
 +--+
 |  GACh info-2 |
 +--+
figure 2

Now my question is the "B->C SubPath" in the first figure identical to the 
"B->C SubPath" in the second figure?
Now
--



> 
> Regards,
> Greg
> 
> On Fri, Feb 22, 2019 at 8:15 PM Loa Andersson  > wrote:
> 
> Greg,
> 
> We are close, though I hope the rules are that GAL is bottom of stack,
> and that a packet with a GACh does not carry user payload.
> 
> I should have said that "if you want a GACg for the
> 
> I don't understand why we need a "new" SR tunnel, the GAL/GACh can
> ride with the GAL as bottom of stack with the label stack for
> Sub-path(B->C), right? If you put it on "another" tunnel, how do
> you guarantee fate sharing?
> 
> /Loa
> 
> /Loa
> 
> On 2019-02-23 11:55, Greg Mirsky wrote:
>  > Hi Loa,
>  > I think it will be similar to SPME and we'll need to have another
>  > SR-tunnel B-C with its own Path segment allocated by node C. But GAL
>  > will still be BoS.
>  >
>  > Regards,
>  > Greg.
>  >
>  > On Fri, Feb 22, 2019 at 6:15 PM Loa Andersson  
>  > >> wrote:
>  >
>  >     Rakesh, authors,
>  >
>  >     I have not been thinking about this too much. But if you look
> at fig 2
>  >     of draft-cheng-spring-mpls-path-segment, and you need a GACh
> between
>  >     A and D, I'd say that the GAL will be at the bottom of stack.
>  >
>  >     What if you need the CACh for the sub-path B to C, where will
> the GAL
>  >     go?
>  >
>  >     /Loa
>  >
>  >
>  >
>  >     On 2019-02-23 09:25, Rakesh Gandhi wrote:
>  >      > Hi Greg,
>  >      >
>  >      > I am not sure if the question has been answered. I would think
>  >     GAL is at
>  >      > the bottom of the label stack.
>  >      >
>  >      > Thanks,
>  >      > Rakesh
>  >      >
>  >      >
>  >      > On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky
>  >     mailto:gregimir...@gmail.com>
> >
>  >      >      >      >
>  >      >     Hi Weiqiang Cheng,
>  >      >     thank you for your expedient response to my questions. The
>  >     document
>  >      >     states that one of the use cases for the Path segment
> is to
>  >     be used
>  >      >     as a performance, packet loss and/or delay,
> measurement session
>  >      >     identifier. I think that RFC 6374 is the most suitable
> for PM
>  >     OAM in
>  >      >     SR-MPLS environment. Of course, the type of the
>  >     encapsulated message
>  >

Re: [spring] to progress draft-cheng-spring-mpls-path-segment

2019-02-13 Thread Chengli (Cheng Li)

+1. 

After reviewing the document , I think the requirement of path segment is clear 
and the solution is reasonable and effective.
Since the content of this draft is stable, I think it is ready for WG adoption 
as well.

Thanks,
Cheng


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Weiqiang Cheng
Sent: Wednesday, February 13, 2019 11:59 AM
To: 'Loa Andersson' ; spring@ietf.org
Cc: draft-cheng-spring-mpls-path-segm...@ietf.org
Subject: Re: [spring] to progress draft-cheng-spring-mpls-path-segment

Hi Loa,
Thank you very much for your review and comments.
The solution in the draft provides a simple and effective way for E2E FM and PM 
in the Telecom application Scenario.
The requirements are valid and all existing comments have been resolved.
We authors also hope WG can adopt draft-cheng-spring-mpls-path-segment as a 
working group document.

B.R.
Weiqiang Cheng

-邮件原件-
发件人: Loa Andersson [mailto:l...@pi.nu] 
发送时间: 2019年2月10日 16:11
收件人: spring@ietf.org; draft-cheng-spring-mpls-path-segm...@ietf.org
主题: to progress draft-cheng-spring-mpls-path-segment

Working Group,

I have reviewed draft-cheng-spring-mpls-path-segment and as far as I can see, 
it is ready for wg adoption.

There were some comments in Bangkok, but due to the many collisions between 
working groups at that meeting I couldn't attend the SPRING f2f.

The minutes are not clear, but as far as I understand, there is nothing that 
can't be resolved in the wg process.

/Loa
-- 


Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64



___
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] I-D Action: draft-li-idr-sr-policy-path-mtu-01.txt

2019-01-03 Thread Chengli (Cheng Li)

Hi Robert,

Thanks for your comments, and happy new year!

Sorry for my delay, please see my reply inline.

Best Regards,
Cheng

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, December 27, 2018 6:31 PM
To: idr@ietf. org 
Cc: SPRING WG 
Subject: Re: [spring] I-D Action: draft-li-idr-sr-policy-path-mtu-01.txt

Authors,

SR policy draft aims to add new SAFI to distribute SR policies aka paths via 
BGP.

However in SR "path" really means single or set of anchor points packets would 
need to traverse to meet required policies, It makes no assumption about nodes 
or links which are not on the SR node list and are places between SR nodes.
[Cheng]Yes, you are right. An SR path means a set of endpoint nodes would need 
to traverse to meet required policies.

Currently in our document, we always assume that the controller calculates the 
path MTU based on BGP/IGP data and gives it to the node.
We may need to state that this would be “the best” approximate value as per the 
information at the controller where controller can consider the path MTU of the 
best paths (in case of loose hops and lower value in case of ECMP(?)).

This approximate PMTU is useful in SR TE scenarios.
For SR BE,  the PMTU of the IGP shortest forwarding path between endpoint nodes 
can be calculated by the controller as long as the Link MTUs can be collected, 
so the controller can get the PMTU of the SR BE path as well.

Your draft (while perhaps theoretically useful) introduces completely new 
dynamics to the SR policy proposal as now the originator of SR policies must 
track atomic link MTUs on how to get from any potential recipient of such 
policies to given list of anchor nodes (SR nodes).
[Cheng] In order to make sure that the PMTU depict the real MTU of the path, it 
should be collected and updated in time.


Even encoding wise the draft as proposed does not meet the stated requirements 
as it mistakenly assumes  that MTU to reach given set of policies would be 
identical from any ingress node.
[Cheng] Sorry, I don't really understand this point, identical from any ingress 
node?
Do you mean SR Policy[E,F,G] can be configured at the headend node A, B and C 
respectively, then the MTU of [E,F,G] is wrongly configured as identical at 
different ingress A, B and C?

Actually, in this case, the PMTUs are different among these SR policies, since 
they are different SR policies.
An SR policy is identified by . The PMTU maybe 
different since the link MTU between the headend node and the first endpoint 
node may be different.

Last - in practice there is no way for the controller or any other oracle to 
know the real MTU since many networks uses emulated circuits as native links 
and the real MTU not only may change every delta time, but is only detectable 
by data plane end to end probes.
[Cheng] Yes, there are some scenarios like that. But most of the cases, the MTU 
should be stable.
Also, E2E probing can be used to get the PMTU. We aim to set the PMTU in the SR 
policy while any useful mechanism to get the MPTU can be used for sure.

We can also allow the probe/controller/SR-Ingress to use data plane path MTU 
discovery technique instead of ‘best’ approximate value with a flag stating the 
source of this information as approximate or measured.

Thanks again!

With that I think this proposal should not be added to SR policy document in 
the current form.

Kind regards,
Robert.


On Thu, Dec 27, 2018 at 9:18 AM 
mailto:internet-dra...@ietf..org>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Segment Routing Path MTU in BGP
Authors : Cheng Li
  Zhenbin Li
Filename: draft-li-idr-sr-policy-path-mtu-01.txt
Pages   : 7
Date: 2018-12-27

Abstract:
   Segment routing is a source routing paradigm that explicitly
   indicates the forwarding path for packets at the ingress node.  An SR
   policy is a set of candidate SR paths consisting of one or more
   segment lists with necessary path attributes.  However, the path
   maximum transmission unit (MTU) information for SR path is not
   available in the SR policy since the SR does not require signaling.
   This document defines extensions to BGP to distribute path MTU
   information within SR policies.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-li-idr-sr-policy-path-mtu-01
https://datatracker.ietf.org/doc/html/draft-li-idr-sr-policy-path-mtu-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-li-idr-sr-policy-path-mtu-01


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.

Re: [spring] SRv6 - SRH in encaps or base header - point 2

2018-11-05 Thread Chengli (Cheng Li)

OK, thanks for your reply. It solves my problems.

Regards,
Cheng

From: Darren Dukes (ddukes)
To: Chengli (Cheng Li)mailto:chengl...@huawei.com>>
Cc: Joel 
Halpernmailto:j...@joelhalpern.com>>;springmailto:spring@ietf.org>>;6man<6...@ietf.org<mailto:6...@ietf.org>>;Lizhenbinmailto:lizhen...@huawei.com>>;Mach
 Chenmailto:mach.c...@huawei.com>>
Subject: Re: SRv6 - SRH in encaps or base header - point 2
Time: 2018-11-06 04:28:18

Yes, SRH insertion is not discussed in this draft and not within its scope.

Darren

> On Nov 4, 2018, at 11:55 PM, Chengli (Cheng Li)  wrote:
>
> so how to use SRH insertion? Out of scope of this draft?
>
> Cheng
>
>
> -邮件原件-
> 发件人: Darren Dukes (ddukes) [mailto:ddu...@cisco.com]
> 发送时间: 2018年11月3日 2:40
> 收件人: Chengli (Cheng Li) 
> 抄送: Joel Halpern ; spring@ietf.org; 6...@ietf.org; 
> Lizhenbin ; Mach Chen 
> 主题: Re: SRv6 - SRH in encaps or base header - point 2
>
> Hello Cheng, thanks for the review!  Please see inline
>
>> On Oct 30, 2018, at 11:41 PM, Chengli (IP Technology Research) 
>>  wrote:
>>
>> Hi Darren,
>>
>> I think the text of encapsulating mode is clear for me. But I still have 
>> some questions of the insertion mode .
>>
>> 1.1 : Node 9 has a choice, encapsulate to node 3 or not.
>> If node 9 does not encapsulate, it will inform the destination of the 
>> segments in the SRH and possibly leak them to intermediate nodes.
>>
>> If there is not indicator to make a choice of encapsulating or not, how the 
>> node to make the choice? Local policy?
>> Or make it the same like the received packet? Encapsulate if received packet 
>> does, else, insert?
>
> A host needs many things to determine how to add an SRH to a packet it is 
> sending to a destination, at least it needs to learn SIDs for nodes and have 
> some logic in place to determine how and when to use a particular segment 
> list… That is well beyond this document and there is and will be more 
> innovative ways of determining when to add a SRH to a packet sourced by a 
> node.
>
> Therefore I’ll say this question is not within scope for this document, it 
> needs to be answered for specific use cases and applications of the SRH.
>
> That said there is ongoing work to define how a node may learn an SR Policy:
> PCEP https://www.ietf.org/id/draft-negi-pce-segment-routing-ipv6-03.txt,
> BGP-TE 
> https://www.ietf.org/id/draft-ietf-idr-segment-routing-te-policy-04.txt,
> or “SDN” methods where some outside controller sets up a segment list via 
> some REST, CLI, netconf/yang interface to satisfy specific use cases.
>
> And when to use it:
> BGP SRv6 services https://www.ietf.org/id/draft-dawra-idr-srv6-vpn-05.txt
>
>
>>
>> 1.2 : How to inform the destination of the segments in the SRH?  Any 
>> indicator in SRH? Or through signaling?
>>
>
>
> Same answer as 1.1.
>
>> 2: Can a normal(non-SID) IPv6 address be added into SID list?
>>
>> I prefer yes.
>>
>> As section 4.3 says, it seems like we can do that.
>>
>>  "When an SRv6-capable node receives an IPv6 packet, it performs a
>>  longest-prefix-match lookup on the packets destination address.  This
>>  lookup can return any of the following:
>>
>>  A FIB entry that represents a locally instantiated SRv6 SID
>>  A FIB entry that represents a local interface, not locally
>>instantiated as an SRv6 SID
>>  A FIB entry that represents a non-local route
>>  No Match
>> "
>> Also, in section 5, we can see A9 can be added in SID list of a SR policy.
>>
>> So for the packet from A9 to A1, the address of A1 can be added as the last 
>> entry of SID list, right?
>>
>> If yes, address of A1 is not an instantiated SID, so not PSP flavor can be 
>> enabled. So the packet will be sent out by carrying the SRH after A1 is 
>> updated to the IPv6 DA.
>> SRH will be leaked to outside of the SR domain, which will bring new 
>> security issues.
>>
>
> Yes as the last segment in a segment list, and as RFC8200 section 4.4 
> describes Routing Header processing when segments left is 0.
>
> It is up to the specific use case to determine if informing the destination 
> or intermediate nodes of the segment list used to reach it is a security risk.
>
> Certainly on the larger internet this is an issue that needs to be 
> considered, but within an enterprise network or within a single providers 
> network crossing multiple domains, or even between providers the disclosure 
> may be acceptable or desired.
>
>>
>> 3: For section 6.

[spring] 答复: SRv6 - SRH in encaps or base header - point 2

2018-11-04 Thread Chengli (Cheng Li)

so how to use SRH insertion? Out of scope of this draft?

Cheng

-邮件原件-
发件人: Darren Dukes (ddukes) [mailto:ddu...@cisco.com] 
发送时间: 2018年11月3日 2:40
收件人: Chengli (Cheng Li) 
抄送: Joel Halpern ; spring@ietf.org; 6...@ietf.org; 
Lizhenbin ; Mach Chen 
主题: Re: SRv6 - SRH in encaps or base header - point 2

Hello Cheng, thanks for the review!  Please see inline

> On Oct 30, 2018, at 11:41 PM, Chengli (IP Technology Research) 
>  wrote:
> 
> Hi Darren,
> 
> I think the text of encapsulating mode is clear for me. But I still have some 
> questions of the insertion mode .
> 
> 1.1 : Node 9 has a choice, encapsulate to node 3 or not. 
> If node 9 does not encapsulate, it will inform the destination of the 
> segments in the SRH and possibly leak them to intermediate nodes.
> 
> If there is not indicator to make a choice of encapsulating or not, how the 
> node to make the choice? Local policy?  
> Or make it the same like the received packet? Encapsulate if received packet 
> does, else, insert?

A host needs many things to determine how to add an SRH to a packet it is 
sending to a destination, at least it needs to learn SIDs for nodes and have 
some logic in place to determine how and when to use a particular segment list… 
That is well beyond this document and there is and will be more innovative ways 
of determining when to add a SRH to a packet sourced by a node.

Therefore I’ll say this question is not within scope for this document, it 
needs to be answered for specific use cases and applications of the SRH.

That said there is ongoing work to define how a node may learn an SR Policy:
PCEP https://www.ietf.org/id/draft-negi-pce-segment-routing-ipv6-03.txt,
BGP-TE https://www.ietf.org/id/draft-ietf-idr-segment-routing-te-policy-04.txt,
or “SDN” methods where some outside controller sets up a segment list via some 
REST, CLI, netconf/yang interface to satisfy specific use cases.

And when to use it:
BGP SRv6 services https://www.ietf.org/id/draft-dawra-idr-srv6-vpn-05.txt

> 
> 1.2 : How to inform the destination of the segments in the SRH?  Any 
> indicator in SRH? Or through signaling? 
> 

Same answer as 1.1.  

> 2: Can a normal(non-SID) IPv6 address be added into SID list?
> 
> I prefer yes.
> 
> As section 4.3 says, it seems like we can do that.
> 
>   "When an SRv6-capable node receives an IPv6 packet, it performs a
>   longest-prefix-match lookup on the packets destination address.  This
>   lookup can return any of the following:
> 
>   A FIB entry that represents a locally instantiated SRv6 SID
>   A FIB entry that represents a local interface, not locally
> instantiated as an SRv6 SID
>   A FIB entry that represents a non-local route
>   No Match
>  "
> Also, in section 5, we can see A9 can be added in SID list of a SR policy.
> 
> So for the packet from A9 to A1, the address of A1 can be added as the last 
> entry of SID list, right? 
> 
> If yes, address of A1 is not an instantiated SID, so not PSP flavor can be 
> enabled. So the packet will be sent out by carrying the SRH after A1 is 
> updated to the IPv6 DA. 
> SRH will be leaked to outside of the SR domain, which will bring new security 
> issues. 
> 

Yes as the last segment in a segment list, and as RFC8200 section 4.4 describes 
Routing Header processing when segments left is 0.

It is up to the specific use case to determine if informing the destination or 
intermediate nodes of the segment list used to reach it is a security risk. 

Certainly on the larger internet this is an issue that needs to be considered, 
but within an enterprise network or within a single providers network crossing 
multiple domains, or even between providers the disclosure may be acceptable or 
desired.

> 
> 3: For section 6.2,
>   Nodes outside the SR Domain cannot be trusted.  SR Domain Ingress
>   routers SHOULD discard packets destined to SIDs within the SR Domain
>   (regardless of the presence of an SRH) to avoid attacks on the SR
>   Domain as described and referenced in [RFC5095]. 
> 
>   As an additional
>   layer of protection, SR Segment Endpoint nodes SHOULD discard packets
>   destined to local SIDs from source addresses not part of the SR
>   Domain.
> 
> For a packet from A1 to A9,  the packet is (A1, A9). Node3 will not drop the 
> packet since the destination is A9 not S9.
> 
> If node 3 insert a SRH in the original IPv6 packet, then the source Address 
> will be A1. And the SID list can be  .
> In this case, the packet will be dropped by node 6, since the source address 
> is not part of the SR domain.  [Section 6.2], right?
> 
> IMHO, there are some problems about insertion mode.

In the context of the SRH draft we do not make any mention or use of SRH 
insertion. I

79 matches

Mail list logo