View on https://notes.ietf.org/notes-ietf-121-teas
WG ICS: https://datatracker.ietf.org/meeting/121/session/33397.ics
Datatracker: https://datatracker.ietf.org/group/teas/about/
13:00-15:00 Europe - Dublin Time
https://www.timeanddate.com/worldclock/converter.html?iso=20241108T130000&p1=78
Room: Liffey Hall 2 -- https://datatracker.ietf.org/meeting/121/floor-plan?room=liffey-hall-2
Materials: https://datatracker.ietf.org/meeting/121/session/teas
Note taking: https://notes.ietf.org/notes-ietf-121-teas
Onsite tool: https://meetings.conf.meetecho.com/onsite121/?session=33397
Video stream: https://meetings.conf.meetecho.com/ietf121/?session=33397
Audio stream: https://mp3.conf.meetecho.com/ietf121/33397.m3u
Zuilip: https://zulip.ietf.org/#narrow/stream/teas
ICS: https://datatracker.ietf.org/meeting/121/session/teas.ics
Recording: http://www.meetecho.com/ietf121/recordings#TEAS
YouTube: https://www.youtube.com/watch?v=ks5JvAgBGLw
(Regarding TE topology profile)
[Vishnu Pavan Beeram]: We would like draw the WG's attention to the TE topology profile work because of the on-going discussions in NMOP and the Hackathon which is on the agenda. There has also been a side meeting on profiles.
[Italo Busi]: We had a side meeting to share ideas for the problem statements for YANG profiles and filtered views. There was some interest, more on the filtered views than on the profiles. An issue for this has been opened in YANG-next github and we can start discussion on the NETMOD WG mailing list. Some people have implemented manually defined profiles with no issues but some concerns have been raised on the need for some automated way to define the profiles.
(Regarding L3 and Packet TE topology)
[Vishnu Pavan Beeram]: There was a request to move the packet-te specific augments to another draft. Authors had previously stated that they do not see the need for a separate document to carry this small set of augmentations. But some clarification text can be added to the Introduction to accurately specify the scope of the document.
[Xufeng Liu]: There is no change in the authors' stance.
[Vishnu Pavan Beeram]: The issue is that the discussion on the packet-te specific augments does not appear until we get to section 3. Some text in the introduction could help. Please provide some text proposal on the list.
[Italo Busi]: I would also suggest updating the title of the document. The name of the I-D is also confusing but this will no longer be an issue after it is published as an RFC. A more accurate name would help in avoiding confusion.
[Vishnu Pavan Beeram]: We would need at least one more revision before lining this up for WG LC.
[Vishnu Pavan Beeram]: The diagrams in the document need to be fixed before we take the document to WGLC. Currently, there are "refer to the figure in the pdf version" placeholders sprinkled all over the doc, but there is no pdf version available.
[Xufeng Liu]: This has become a problem because the submission tool does not support pdf format for submission anymore.
[Dhruv Dhody]: There is a tool from Martin Thomson to translate ASCII diagram into SVG. I will work with you.
[Xufeng Liu]: The issue here is that the diagrams have been made with powerpoint.
[Vishnu Pavan Beeram]: We will sort this out offline.
(Regarding co-existence of SAP and TE Topology)
[Oscar Gonzalez de Dios]: (As one of the authors of the SAP topology model) It is important to clarify the role/purpose of each model. I will provide some text to clarify this.
[Vishnu Pavan Beeram]: Please start a discussion thread on the list for this open item.
[Vishnu Pavan Beeram]: We will wait for the next revision and then send a liaison to 3GPP seeking review and feedback.
[Vishnu Pavan Beeram]: We don't need to rush this document through the WG process. We can afford to wait for the other relevant/dependent documents to mature and then see if any updates are necessary for this document.
[Greg Mirsky]: Regarding having different NRP Dataplane ID lengths for different data-plane types, there is an advantage to have a single length. There is a related document in 6MAN WG, where authors have asked for WGLC. It is premature to do the WGLC in 6MAN WG without converging on this length discussion in TEAS WG.
[Tarek Saad]: Agree that the discussion on this hasn't closed. We would like to seek more opinions on this.
[Greg Mirskly]: We should reach out to both 6MAN and MPLS WGs for this.
[Vishnu Pavan Beeram]: We have an active thread on the list on this very topic. We have received some comments in support for different lengths. If there are opposing opinions, please do chime in on the discussion thread and state your concerns. After we draw consensus on this, we will provide the necessary inputs to to both 6MAN and MPLS WGs.
[Zafar Ali]: Agree with Greg on length consistency. Regarding the "strict" match indicator, this is generic and should not tied to NRP.
[Tarek Saad]: I has previously raised a concern on the change made in rev-04 that deviates from the WG agreement to not rely on routing protocols to carry per NRP state information. Can you clarify this?
[Jie Dong]: We still acknowledge the agreement and will work with you to improve the text.
[Zafar Ali]: I would like to re-assert the point and get clarity on this point in the document.
[Vishnu Pavan Beeram]: There should be no change to the original WG stance. Please open a thread with a pointer to the contentious text and propose text changes to address the concern.
Polls:
Applicability of ACTN to POI service assurance. Is there interest in the working group in this topic?
Total participants: 54
Yes: 14
No: 0
No opinion: 12
Is draft-poitdt-teas-actn-poi-assurance a good starting point for tackling the topic?
Total participants: 53
Yes: 12
No: 0
No opinion: 12
[Vishnu Pavan Beeram]: This is good feedback. We will take it to the list.
[Adrian Farrel]: Thank You for the work. Much needed work. The document should obsolete RFC2747 and not RFC3097.
[Tony Li]: We will fix it. (Chairs' Note - The Introduction does say that the document obsoletes both RFC2747 and RFC3097)
[Adrian Farrel]: We should send a note to TSVWG because they have an interest in base RSVP and keep them in loop; We should also send a note to SAAG WG and ask for review and feedback regarding key management.
[Tony Li]: We can ask.
[Adrian Farrel]: RFC6151 is a good reference to add for the advice against MD5.
[Tony Li]: We will add.
[Vishnu Pavan Beeram]: The "Keyed message digest" field in the original INTEGRITY object is not rigid. Since this is the only field in the object, I believe the authors's intent was to use the size of the object itself to determine the length of this field. That said, I agree that having an explicit length field is useful.
[Tony Li]: That may have been the authors' intent, but there is no explicit text stating this.
[Vishnu Pavan Beeram]: Thanks for the backwards compatibility section. It makes it clear that we don't need a new C-TYPE.
[Vishnu Pavan Beeram] (as chair): As the document progresses, we will keep TSVWG and SAAG WG in the loop.
Poll:
Is there interest in RSVP-TE authentication 2.0?
Total participants: 52
Yes: 10
No: 1
No opinion: 8
[Vishnu Pavan Beeram]: Good feedback. We will take it to the list.
[Zafar Ali]: Not related to this draft. While we look at enhancing RSVP Authentication, I would like us to look at doing something for "Flow Control" in RSVP.
[Vishnu Pavan Beeram]: I would encourage you to look at RFC2961 and the more recent RFC8370 which introduced "Per Peer Flow Control" in RSVP.
(This was presented in the NMOP WG as well)
[Oscar Gonzalez de Dios]: Do you already have any plans for the next Hackathon?
[Henry Yu]: We would look at doing something that would help do an "apples-to-apples" comparison with the other modeling work (for Digital Map) being done in NMOP WG.
[Oscar Gonzalez de Dios]: It would also be useful to do a similar exercise for other models that the WG is developing.