Internet Engineering Task Force 111, 29 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF111-PCE-20210729-1900

Description

PCE meeting session at IETF111
2021/07/29 1900

https://datatracker.ietf.org/meeting/111/proceedings/

A

A

Hello, everyone- this is the second session of the past computational element working group draw a fire with us back.

B

Sorry go ahead.

A

Yeah! Okay, great so.

C

A

Usual, you know about all the blue sheets on noteworth, so you should be aware of this we're on thursday. Already for many of you, it's not the first itf meeting. So when we're online, we still have rules to follow, especially about ipr ipr.

A

So please make sure you are aware of those and next please we'll jump quickly to the usual meeting tips we're online but still have recording progress, so make sure to take your name when you want to raise a question, uh draven I'll, try to balance the queue at the mic, so you have the mic button to press if you want to join the queue next, please.

A

So harry is in charge of taking notes if you want to help harry with the minutes, uh trust send the link already in the chat it's already also included in the slides. So this is the kodi md tool, probably you're, already familiar with it. So if you want to help harry, please join the kodi md page thanks for those who did that already during the previous session, so arjun dabashing.

A

You already saw that on monday we moved the last presentation that got dropped from monday because we were out of time. So it's back on the agenda. For today we had five spare minutes, so hopefully we'll manage to achieve the expected schedule today, so presenter. You know that the time allocated to your presentation should include the question and answer. So we try to find the right balance to drive, but please make sure that you don't get your full time consumed by just your slides, because you need to save time for questions thanks next, please.

A

um We're done so samuel is the first one.

D

Hi, I'm samuel siegel from cisco speaking so I'll, be presenting draft about carrying seed algorithm in b, set on below filters of the draft next slide.

D

Please so uh I do I presented it a few times already, so I will just briefly describe motivation and then I will summarize changes which happened after last itif, so uh information about seed algorithm is available on pc or pcc site, for example, and from igp gpos are coming from configuration in case of explicit segment list configuration, but there there was no way to encode it in pset, and basically this draft is taking care of it next slide.

D

Please there are discovering two two main areas, or the first part is about encoding of c d algorithm in the arrow object in previous drought version.

D

uh It was achieved by adding new knight ups and knight types with algorithmic field included that was replaced by optional algorithm fields, which can be included in sr or srv6erl sub-objects, and a new capability was introduced in in open message to indicate if this uh sr, uh if this new algorithm field in as well as rv6, have objectively supported or not in the latest, belgium support for srv6 and also for their sensitive algorithm was introduced, but from a seat algorithm constraint in lsp8. There are no major changes.

D

We just renamed some prefix, it's prefixed statements to just sit statements because of added support for ideas, and since it's already next slide, please.

D

Also, as mentioned uh in period slide, new flag was added uh in srpc capability to indicate support of new algorithm filtering, as other errors object, algorithm flow can be uh can be included only if both speakers, uh speaker and ecb receiver has support next slide. Please.

D

Similarly, new phone was added into srv6 pc capability as well, which is included in part setup type, dlv, an open message to indicate support for algorithmic field, but this time for srv6 subobject. So this is the new s s flat next slide.

D

A new algorithm field included in erl, subject and flag, indicating that length of sub-object needs to be increased by four. So we have this new a flag here and if a flag is set to one then algorithm field is present and length of the length of the arrows object is increased next slide. Please.

D

So for srv6, yellow sub-object, there are similar changes so basically same again, a flat introduced and four bytes included uh at the end of the structure. So there are some optional fields already, and algorithms fields is also optional and it is added at the end of the sub-object, so similar changes for srv6 and next slide. Please.

D

So, in original version of the draft there there are night types created for basically every every existing knight type, just with algorithm field added uh at the end, but that solution was not maintainable from long-term perspective because any any other feature which needs to be supported. A card duplicating of knight types and basically, with addition of srv6 and adsense, is it support. We had to duplicate more than five uh knight types uh and that that was also not future proof solution.

D

So we came with as I as a big extension for sr arrow and srv6ero sub object and that that implicitly covered also ideal, sensitive algorithm.

D

Next slide, please so uh for next steps, uh any comments, any discussion is welcome. uh Basically, we already requested uh adoption and there are some new new members uh who want to want to join the draft, so there will be some new additions and some some new requirements that are done to be added to this specific draft. So additional changes are expected.

D

Any any questions, any comments.

B

B

B

Boris go ahead.

B

Oh uh samuel. uh I had one uh clarification on the word deprecated. This is you are using this in a general sense right, not in sense of that ina code points needs to be deprecated or something like that. It's mostly that you have moving away from nai types and instead changing srero object itself.

D

Yeah yeah correct, basically, uh code points are not allocated yet because the route was not adopted. So so uh we just replaced the original knight types which were introduced in the draft with the new solution with algorithm field and with the dropper like this.

B

E

A little bit or procedural question some working group, I don't remember which one actually requires a new ipr statement if people are joining a draft kind of midway, so samuel said that there are people joining now will pce have that practice and actually require the ipr statement from the new people on a new co-op.

B

uh No for this draft, this is still an individual draft, so we don't have to worry per se about this draft. Yet, though our requirement is the same that movement, any author or any contributor wants to uh like you know, if joins the draft, they should report it to the working group, but I will discuss this with my co-chair and ad and also with other working group who are following this and maybe whole routing wide if we can have a common policy that could be. uh That would be nice.

B

But uh let me discuss this with julian and we'll come back on the mailing list.

E

Okay, that would be good, but you say that it's all only applicable to already adopted documents.

B

I I, as I understood the policy in the other working group, was that it was followed for adopted work. Okay, that's what I understood.

E

B

Thanks are there any other questions for.

B

Samir: okay, thanks.

A

Okay, thank you. Bye, there's a question from boris on the chat, probably because he couldn't use this mic so he's asking. If there are any plans for test implementation.

D

Yes, so uh the whole experimental implementation, at least or in cisco site, just because of the recent change, I assume that there is no other implementation yet so um then, then any other implementation will be ready. Then we definitely can test interoperability.

D

B

Thank you next speaker.

B

F

Hello, can you hear me.

B

F

Okay, thanks- and this is john from tt. My presentation today is the psap extension for sr mpl's entropy label position. Let's please.

F

This drive has been presented and at a itf, 106 and 108, and we get some comments which have been discussed in details on the mailing list. So thanks the comments and suggestions from uh stephen doof, tariq, jambin and jeff is very appreciated, and this slide is the summary of the updates.

F

According to the comments, and so first it is the lsp extending the flag to has been moved to into the draft itf pc lsp extended flex, and it is, it has been just just adopted by working group, so the entropy entropy label document just use a flag from sp extending flex field of the tre.

F

Second, we made some clarifications for the msd and the erld limitation and describes the requirements in pc scenario, for example, as described in rc8662, the ingress load may not fend the minimum erld along the path uh and do not support the computation of the minimum erlds, and so especially in case of inter-domain scenario.

F

Pc will be useful for computing, the minimum er er erld or the position of the entropy labels as well as sr process. We also clarified the ingress uh capability.

F

Multiple pairs may be inserted in their srmps label stack, so the ingress is required to support the capability of inserting multiple, el eris and in pc scenarios. It will need to be advertised in open message from pcc to pc, so we defined ebate to use to uh it used.

F

It is used used to indicate the capability of inserting multiple el iel pairs at pcc, and it also indicates to support the sr path with the position computation from pc and, finally, the er ielts position is calculated at pc for sr pass and the values is uh calculated at pcc for a specific, uh specific traffic flow, and this is the uh uh chance of fought john b lee the comments.

F

uh Let's please.

F

So, let's, let's do the quick scan with the overview of c8662 pro proposed to applying the entropy labels to sr nps networks and provides a criteria to determine the best er ielts placement.

F

Multiple pairs may be inserted in the srmps label stack and the positions should be within the eri e l e rld limbo so, but the ingress may not defend the minimum er ld along the path and does not support the computation.

F

So this document proposed the pc to perform the end-to-end pass computation, as well as the uh entropy label position. uh It will be. It will include the uh include the lambo and the place of the entropy label, especially it is.

F

It is uh useful, especially in inter domain scenario, so, let's uh as the vacation, the pc, uh pc1 and pc2 are responsible to compute the inter domain asl sr pass and the results will be sent back to the load load a, but the ingress from domain 1 cannot get the msd and the erld information of the domain 2..

F

With the approach proposed in our draft pc1 and pc2 may compute the interdomain path with the placement of of the entropy labels, so uh the uh with the uh positions of the entropy labels uh of the two domains, the load a may calculate the eoil values and insert them into their configured positions.

F

F

So we made some extensions for psf. We defined an ebate in srpc capability sub tree and it is carried in open, open object when it is set. It indicates to supported sr pass computation with the entropy label position, and it also indicates that uh it supports the capability of inserting multiple er er ielps. At a pcc, a new e-flag is used from lsp, extended flex field in usb extended flag tle. I just mentioned it indicates that the pcc requests a pc to compute the sr path with the entropy label position.

F

Last night.

F

We've also defined past minimum er er ld dtoe in lsp object. The the value indicates the minimum erld value of the loss known to law along the path the e-bit is uh is used in. uh It's also extended in sri sub-object to it is to indicate the position after this srero subject is the position to insert e-r-I-e-r.

F

Otherwise it can't insult a insert uh ari el after this segment segment. Next, please.

F

So this is other extensions for psep and this document has been discussed many times in details uh at meetings or and on on the main list. Thanks for all your comments and suggestions.

F

Please let me know if it is ready for adoption thanks very much.

B

Are there any questions.

B

But one I have one question: uh can you explain this minimum er ld tlv a little bit? I was not very sure. What's the usage for this dlv is.

F

Okay, this is a new uh update from from last version, because the requirements over after srm ps, entropy label is the uh ingress, can't compute the minimum or can't get the minimum erld after along the path. So um I I want to provide another option uh if the pc can compute the pass minimum er ld for the pcc, the pcc will choose option. uh One option: one is to get the pass minimum er ld and it can determine the uh position and the calculated value uh itself uh option.

F

Two: is the pc uh directly computed the uh positions for the for the egress and the ingress just calculate their uh the value of their entropy label and their insert the label to their positions which the pc calculated.

B

G

Be worth adding.

B

G

B

Draft uh jeff go ahead. Actually we are over time. So keep the questions brief. Please.

H

Third question: you are using word plus consistency itself is peer-to-peer protocol, so information about plus capabilities can only be derived from underlying igp.

F

Correct yes, yes,.

H

So I think, more text with regards to how all these pieces work together would be very good. Thank you.

B

Change go ahead quickly,.

C

Is it is similar to msd, I mean the past minimal er lv?

C

Is it similar to.

I

C

B

uh uh Quan, I think the best thing would be like you know, describe this a little bit better, both in the document and on the mailing list. Yeah.

C

B

Art minimum erld is not very clear so what description you just provided maybe put that in the document, as well as on the list. So, let's move on. Thank you thanks. Everyone.

F

B

Let's move to the multicast uh part of today's agenda: human go.

B

Ahead you if you're.

B

Speaking on you're, there.

B

Maybe let's move.

J

F

J

Just messaged me, I guess his headset is having issue I could try to take over, even though I wasn't prepared for this good and you go ahead, um so I guess I'll kind of wing this um human would have presented this on behalf of the authors. um So this is basically an update to the point to point policy draft next slide, please.

J

So. Basically, the draft started off with a couple different changes to it in terms of how we would decouple and describe replication segments versus the point to multiply policy. In the original draft, we were using euro objects to basically encode downstream replication segments, so with the discussion with dhruv and once again drew. Thank you very much for all your engagement on it. Basically, there was an update suggested by druv to actually wrap the replication segments with the cci object instead of directly using the euro.

J

That justification basically comes from some historical use cases with pce essential control, so the ero objects are still kind of being used, but they're being wrapped in a cci object for the replication segments in transit.

J

So there's a cci id, that's associated with it. Oh I'm. In ranger raises hand before we show: okay, sorry um and basically, just the cci object is wrapping around the euro. So there's still two separate messages for crafting the point of multiply policy in the replication segment.

J

Originally, in one of the earlier drafts, we were using one pc, init message at the root to do this. These have been split up mainly because it makes managing of the actual objects a lot more consistent and easier, and it decouples the point to multiply policy.

J

I guess you could save tunnel requirements and state from the actual forwarding information, which is the replication segment most of the other stuff in the draft is the same as it was before. The euro is still being used. Multi-Pass backup, tlv is used for production.

J

There is updates to the document for mbb descriptions and just general grammatical corrections. uh Next slide, please.

J

So the new replication segment looks like this in terms of the rbnf, so you've got the common header. You've got the srp object. You've got the point of multiple policy lsp object, then we have the cci list and so in front of the cci list. You have the same instruction sets that define in the epc, central control and then within the cci object. That's being wrapped, carries the same path, attributes and multi-path error objects that were described private prior next slide. Please.

J

So, basically, at this moment, we're really just kind of looking for adoption of the draft um the architecture documents that have happened inside of uh pim spring. Those are still moving forward. um So at this moment we're really hoping for peace up to get an option, and I think that was it.

B

Thanks, andrew uh human, if you, if your audio is working and if you want to say something, please do it!

B

No, if there are any questions for andrew.

B

Jeff, I think you were in the queue, maybe because of the previous one.

B

Yes, uh so thank you human thank you andrew for, uh like you know, updating the document and taking the comments into consideration, I think the document is moving in a good direction. So thanks for that and request more people to review this work and give their feedback.

J

So I just have one follow-up question. um I know the pc adoption key is relatively backlogged. um So to get this added into that queue, should we send out a formal request to the list as the next step, or would that be in place.

B

J

B

Go ahead and, uh like you know, requested julian, and I will discuss and update our list.

J

B

B

Okay: next, we have brt.

K

B

Hi ron go ahead.

K

Oh okay, thank you, uh hello, everyone I'm from dtu today. I want to do the privatization about pce princess for brt. Next, please.

K

Yes, this this document specifies exclusive to the pcep that allow a speed for pce to compute and initiate the pass for the pcrt next place.

K

Yes, this is, for instance, in this document we define a set of pcp protocol expenses, including a pcme p capability.

K

The srp optic object, object, yeah, endpoint, object, objective functions, yellow object and our object, a full for uh fear uh kind of the capability of the advertisement. We defines a new past set of type for fear and we also define defense, dlt pce competition, troy to extend spear capability for srp object. We prefer a new path, setup type for bte, and we use this.

K

The p2mt endpoint object body for ipv4 and endpoints of this body for activity 6, which is defined in fc 8306, and in this document we add two new uh two new objects about objective functions and our objects for objective objective functions. We define a new objective functions for past calculate calculation and for our object with defense and plt, our subordinating objects to report ability to pce, and we also defense and beauty yao sabotage to carry a legitimate stream, dsl subdomain and si next. Please.

K

Yeah this is this page, is about the update in way we must draft turn pce, beauty, part and add one more and I think, was co-authors and based on cuemo and the ig comments. We add the objective functions and the are all objects. um Fc6, uh I'm sorry, I've seen five fail. Four one defines a mechanism to specify objective functions that is used by pce when it computes a path for beauty path. A new object of a new objective functions is defined.

K

It can be used by a pce to find a path, a represent represented by a bit policy that has the minimal number of bit steps.

K

We also add our object and the format of the btro object is the same as that of the beauty. Ero object and its actual value is consistent with ero. The pce reports idea t to a pce a sorry. The pcc report ibrt to a pcb by sending a pc a depart message with with our object.

K

Next, please um comet's welcome and it's the working group adoption. It's knowledge of opening group uh adoption queens and we want ask the opengl to call for adoption in the mainland. Thank you.

B

Friends and thanks for working together and merging documents, that's always good. uh Any questions for run.

K

B

C

Discuss the pce, but I mean beer, tea requirements in any working group. I haven't seen that.

B

Chen, can you repeat the question I think.

K

C

Do we have the requirements of a standardized prt standard, something like this.

K

K

C

Think tony p could can't get answered the question because I don't.

L

B

L

um Yeah, hey uh tony p, juniper, uh yes, brte has been adopted quite a long while ago, as a worker, vitamin beer and it's moving forward. It's actually.

F

L

I think in the 80 review uh second observation.

C

L

Okay, a second observation: once I'm on the mic to the chairs, once you adopted this work plus, please choose this formality uh forward. The request of the beer working group for a cross work work group review, so we have all the needs close all, but I think there is enough people involved in this work that you know we don't have any surprises. Thanks.

B

Thanks tony definitely will do uh ran. I had one uh query based on the objective function that you have added. Can you make sure that there is a little bit more description about? What is the use case where this objective function uh would be needed? That's not very clear that why this objective function is being added, and one more comment would be that you should reference rfc 8623, which is the stateful p2mp extension, and I would assume the pc report message.

B

Pc update message would be based on uh those rfc and it's kind of surprising that rfc 8623 is not referenced at all in this document.

K

Okay, thank you. Next, uh we will. We will add this this image in our chat. Thank you.

B

uh Tony, you have another question: go ahead.

L

um Yeah thanks true uh more an observation uh that applies to this draft and I think, to the next draft um uh pce. It's all fine um sure, beer architecture from day one has been prepared to deal with stuff like that. um You know signaling or no igp controller based uh operation.

L

um My observation would be that the flex are called brte capability and rear capability and that's not wide enough, because the controller can be or no a pce can be used in many different models. You know high touch low touch where igp computes, something pc, computes, something you touch all the nodes and program beer.

L

You know bitmask or you just do them on the edge. So I I suggest to the authors to maybe put in the section with general consideration how pc can be used and give these flags a more meaningful name. So when we have other models, other pc extensions, we can differentiate between those things. Thanks.

B

And that's a very good comment. Tony.

B

Okay, let's move on pc-based beer.

B

I

Okay, hi pce experts- I am juan ali from china telecom, I'm going to introduce our draft. His name is pce based beer, pce based bier procedures and protocol extensions. Next page, please, this presentation contains two parts. First, I will introduce 5a proposed pce, beast bier and its solution. In the second part, I will introduce extension for pcp next page.

I

I

Compared with traditional multicast technology, eier doesn't need to establish a multicultural forwarding tree for each multicast traffic and save the multicast flow states which reduce the resource of occupation and efficiency. Large-Scale development of multicast service in sdn scenario, users, don't need to join the multicast tree hub battery cobalt, hope, improving the management efficiency.

I

We specify pcep extensions to optimize the implementation of multicast source registration and relocation, reserve automatic discovery and forwarding control of multicast data by using pcp messages to transmit multicast management signaling. As dear scenario combining with the forwarding characteristic of vier.

I

By using this mechanism, the unifying management of the ier, multiple multicast can be implemented and the impact of bgp updates and controller can be reduced.

I

An example of pce based bir topology for appear to members or controller as pce is shown in this page ingress sends multicast source information to the controller where pc report message for multicast source registration, then the controller respects the registration result to ingress.

I

If the controller accepts the registration, it will save the multicast source information to database and wait for the egress information.

I

The egresses receive itmp or mld message. Cvo, convert, igmp or mld message into pc report message and send them to the controller controller, stitch, speed, strings of ingress and egress together and send a new bid screen to ingress where pc update message informing the ingress how to forward or stop forwarding ingress encapsulates bier header based on bit string and forwards. Multicast data based on bift and vpn information.

I

The number of receivers is regularly synchronized between egress and controller or between controller and ingress. Next page, please.

I

We newly defined a capability flag and four objects to extend the open report and update message for pcp next page. Please.

I

The multicast source registration object, called msr objects is used for the registration and the registration of multicast source, as well as the corresponding response in pc report message and pc update message respectively, flag rbit indicates whether the action of the message is a registration request.

I

Flag a bit indicates whether the request used is successful.

I

Auxiliary data is used to carry authentication information next page. Please.

I

Multicast visual information object, called mri objects is used for joining or leaving a specific sd in pc report message. Flag ask speeds indicates whether to join the requested sd forwarding label is 2 is used for distinguishing receivers at the forwarding layer.

I

Next page, please.

I

Forwarding indication objects, called fi objects is used for informing ingress to forward package of a specific sd2 receivers in pc report message. Flag f bit indicates whether to start forwarding multicast data next page. Please.

I

Multicast receiver, stator objects, called mris objects is used for synchronizing receiver information in report message and update the message in report. Message: number of receivers refers to those connected to egress in a specific sg update messages. The number of receiver refers to all receivers in a specific sg next page. Thank you.

I

In open message, bier multicast capability flag instead for pce ability, tl way in the open object, is newly defined and you need to be set to spot bier multicast report message is usually to optionally include, msr, object, mri object and mrs object. After the path object, update message is extended to optionally, include, msr, object, fi object and mrs object after the path object.

I

Next page. Thank you.

I

That's the main content of this draft any comment our work are welcomed. Thank you.

B

Are there any questions, tony good.

L

um So I repeat the the comments beside you know the flag, uh not being generic enough. In my opinion, I repeat another comment that I already made in the beer working group, since this is slightly different crowd. um The message format here is very dense. uh I would suggest to break it down more with the format in case you want to extend the whole messaging for this uh pc extension. I don't know rather than pack all these fields and boot ups here and hit the end.

B

uh I have one general question uh so far: we have not included this multicast source and multicast group information and psep messages, and one question is that: why do we, if we, if we agree that this is something that is useful for psep to do? Why do we tightly link it to beer? Can we do it in a generic way and where beer is just a sub tlv, and this kind of information can be used for non-beer multicast use cases as well?

B

Why do you call this like some of this, I feel could be generic and only of some part needs to be very beer specific. What do you think about that.

B

Arjun, do you want to.

I

Answer, sorry, I didn't catch your question. Can we discuss this issue in detail in the millions mailing list later sure.

B

I

B

M

M

We will consider the your base, the solution. Okay,.

B

Okay, we are over time so, like make your comments very very brief. Come on. Hopefully, your mic is working now go ahead.

B

I don't think so.

E

B

E

Really intended to ask this question after the next presentation, but since you brought it up, uh I have I have a reflection. We've been working on uh egress and or ingress protection for more than a decade now, and it seems to be kind of finer and finer in detail shouldn't that be time for do some generalization or something uh in this area to kind of capture the what we learned over time, thanks.

B

Yeah thanks good comments. I think this would be pretty good to discuss on the list. So if there are no more questions, let's move on to the next presentation.

G

Hello: everyone, I'm hoymo chan, I'm going to talk about the pc for bat, english protection. Next page.

G

First, let's have a quick overview about the bat increase protection through an example. So here we have a primary ph bt pass, which is from primary english note, p1 to equals note p3 and p4, which is indicated in red color.

G

We also have a backup bft pass, which is from bicarb english node p2 to equals node, pe3 and p4, which is indicated in green color. So in normal operation, traffic source c1 uh sends markers package to pe one.

G

P1 will inc encap the package with bht hat, which encodes the primary path.

G

So when p1 fails so c, one will similar multicast package to bicarbonate, even with those pe two and then pe two will encaps the package with b head encoding, bicarb pass, then the package will be transported along the backer path to the same destinations. Next page.

G

So for inverse production we have a site of behaviors, that's depends on the configuration or the instructions on source and the backup english node, so one size of a behavior is based on uh sourcing, detecting the failure.

G

So another sense of behavior is based on bicarb english nodes, p2, detecting the failure, so the third set is based on both c1 and the p2 detector. Failure of primary english nodes.

G

So for these different behaviors, so we will send the different instructions and the informations to from a controller. So the key here is pce from pc those different informations or instructions to c1 and bicarb english.

G

P2, so uh next next page.

G

So regarding to the information uh to send it to the bicop user from pce, so those information will include, by cap bat pass and on the primary english notes address, because if we want a bank up english note to detect the failure for primary user note, we needed the primary english language address and the idea in addition to that, we may assume that that what kind of traffic will buy copper equals as well transport. So we need a traffic descriptions and sometimes- and then those uh traffic is for some service.

G

So we need to have surface information so next page, so you want to support this kind of production. So we need a negotiated capabilities between the pce and the pcc, which is running on the yin prime bike have used node or on the source series so for the so for the session between the uh pc and the bicarbonate node. So we have some capabilities to support this inverse production, so these are in. This capabilities will also indicate uh give some kind of instructions to the bicarbonate, english node. For example.

G

We will indicate that the black hyper inverse node will detect the failure.

G

That's one option: another case is that the bicarb inversions will make it ready to accept the mud cast package even before the failure and then as soon as I after failure and then the ce will send a package to uh to the back up and member cardwells for the package along the path. So that's one a set of one one capability. Another company is that we need the instructions from pc to the ces. So that's our set of capabilities.

G

G

So this just gives more details uh encodings about uh encoding the information which is send it to the bi-cop english node.

G

So we will put those informations into a one pov, which is called a ba t, pass english protection tlv. So this dlv will contain a flag which indicates whether the bicarb equals no background ingredients will set the forward interactive, make it ready to accept the markers packages and the other information will be included in the software tailor these.

G

So these sub photography will be the english primary english address opportunity and then can be service sabotage, like this page.

B

And you have less than one minute and five slides so.

G

Okay, okay yeah: this is just the details of uh english address sub utility next page, and then this is the service uh uh ids sabotage next page, and then this is a for instructions encoding for the ce, so we indicate whether it's a source detect or source broadcast to boost prime english and backup english next page yeah. That's all any comments and suggestions.

B

Boris go ahead.

B

I can't hear you boris bobbin, maybe you can go.

N

uh Ahead is pawan bhiram juripur, uh I haven't read the draft, I'm sorry, uh but if I understood this right, it seems to be similar to one of the two procedures discussed in rsc8424. Rs844 is an experimental rfc. So is this also being targeted as experimental work.

G

uh Yeah, that's a good question. uh Yeah the human protection is similar to that one, but this one is: uh we need a support from the pc to this is a in the controller sense. We have a controller because the pse, in some scenario, is a controller comfort, so you want to provide a protection for ingress. We need a similar information to the backup ingress mode, so we need extension for pcs, yet those kind of scenarios, for example the different uh behavior, sets that's similar to the english protection. As you mentioned,.

B

However, just to add to it, uh there was a proposal from your you also about sr ingress protection, which had a very similar uh set of procedures. So, going back to what laura also was saying, it might be a good idea to have a common way to do this, rather than have like separate tlb separate objects, doing this separate for segment routing beer- and this thing it's a- is a generic protocol that can be used in various scenarios. So it's good to design this in a generic way, if possible,.

G

Yeah, that's a good suggestion. Yes, uh I accept yeah good. Thank you.

B

Okay, last presentation, from uh which we missed from last night, go ahead.

O

Can you hear me.

O

Can you hear me.

B

O

I can hear you okay, okay, thank you for taking time, okay, hello, everyone and I'm uh from china telecom I'm going to introduce the draft name, the ps7 features and the extensions for vlan-based traffic forwarding.

O

Okay, considering the large-scale development of the ethernet interface, it is possible to use the info contained in the layer 2 frame to simplify the end to end the packet forwarding procedure, so um this document defines b7 extensions for vlan-based traffic, forwarding in native ip network and describes the processes of the data packet forwarding system based on vlan info.

O

The advantage of this mechanism contains three points: the first one it is use the first one. It uses a completely new new address space, the second one. It is suitable for ipv4 and ipv6 networks, and the last one is it can leverage the existing pce technologies as much as possible. Okay, nice. I please.

O

Well, as shown in this figure, the procedures for vlan based traffic forwarding are as follows: um step one. The pc calculates the x plus a explicit route and sends the route information to the pccs through a pc initiate messages step. Two.

O

The ingress pcc, like r3 forms a vlan forwarding routine table vfr for short, uh the transit pcc like r1 and r2, and the egress pcc, like r5 forms a vlan based vlan crossing routine table vcr for short step 3 the packet to be guaranteed, matches the table and then be labeled with corresponding vlan tag and as marks in the red line in this figure step 4, the labeled packet will be further sent to the pcc specific sub-interface identified by the vlan tag and then be forwarded.

O

Okay. Next time, please, um based on the past setup type capability, trv defined in.

O

Ifc8408 and the pcc capabilities subtly defined in p7 extensions for native ip. We newly defined the pc psd and capability flag to indicate the pc psap speakers capability of vlan based traffic, okay, nice eyepiece.

O

Yeah and we updated the p7 messages with the newly defined cci objects and shown in this figure. Okay, that's how it is.

O

um Two new objects are defined in this shaft. One is vlan, forwarding cci object, which is used to set up the specific vlan forwarding path and transfer the packet to the specific hop. Oh okay, next eyepiece, the other, is vlan crossing cci object, which is defined to control the transmission path of the packet by vlan id.

O

That's our please.

O

uh This page shows vlan based forwarding info advertisement procedures for ingress pcc, based on the v line. Forwarding seaside object next. I please.

O

This page shows vlan based crossing info advertisement, procedures for transit and the egress pcc, based down with the vlan crossing seaside, object nasa peace. Okay, that's the main content of this draft. Any comments on our work are welcome. Thank you.

O

I shouldn't go.

B

B

Arjun, we can't hear you.

B

Are there any other questions from anyone else.

M

Yeah, I think the the procedure is newly introduced, so we run to discuss the mechanism on the list.

B

Later I think we are over time, uh so let's continue to discussion on the list. uh Julian any last words.

A

Thank you, everyone for attending on the we wish you a good slash night as time before, and hopefully we may meet face to face next time you go across.

A

B

Indeed, take care bye, bye,.

A