Hi Yaakov and all, Because of a trip, I can not attend this conference call. I tend to agree that there was still a lot of deep correction, and the encapsulation can be a pure MPLS mode (without UDP/IP or Ethernet). Such kind of encapsulation would be more effective.
What's more, as I posted on this list, the fat label in PWE3 encapsulation should be not be used in this draft. Regards Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 18 Jan 2011 17:44:34 +0000 > From: Yaakov Stein <[email protected]> > Subject: [TICTOC] minutes of TICTOC conference call - Jan 18, 2011 > To: "[email protected]" <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > TICTOC conference call > 18 January, 2011 > Participating : > Karen (hosted WebEx), Yaakov (minutes scribe), Shahram, Stefano, > Manav, Greg, Ron Cohen, Tal Mizrahi, Peter Roberts > > Karen opened the call, stating that the main item for discussion was > the new version of the 1588overmpls draft, > with management and security issues after that if time allowed. > > Yaakov mentioned the main problems he identified with the draft : > 1) a wording issue regarding whether the LSR support was mandatory > (Shahram said it wasn't) > 2) whether NTP would be covered in the same draft > 3) why only OSPF and RSVP were covered, and not IS-IS and LDP. > > Shahram said that NTP and IS-IS were not covered due to lack of expertise. > Manav said that IS-IS could certainly be added. > Shahram said that LDP of the PWE3 control protocol needed to be > added due to the possibility of PHP'ing the tunnel label. > > Yaakov asked whether the wording on page 10 "the top label" was intentional, > and Shahram explained that it was! There needed to be only a single > PW per tunnel, > and if there were multiple labels in the stack, the top one needed > to be signaled. > This saves DPI (but Yaakov stated that there was still a lot of deep > correction). > > Ron asked whether the draft could be extended to handle LSRs that > did not support TC correction on ALL ports, > but only on those needed for the timing flow. This would require > additional port capabilities description. > Manav said that this could be done in OSPF-TE. > Ron stressed the importance of this feature. > > Stefano asked why this draft was limited to PTP and not (for example) NTP. > Ron said that the entire idea was to support the TC correction field, > and that prioritization could be accomplished without a new draft. > Yaakov said that prioritization (e.g., EF) could indeed be covered > in a BCP rather than a PS RFC, > but if BC was required for PTP or NTP, then the techniques defined > here were still needed. > Manav suggested that NTP was so different that it should be handled > in a separate draft. > Karen said that it was preferable to have a single draft to ensure > consistency. > Shahram proposed that Yaakov write a problem statement for NTP, and > afterwards it could be decided > if this could be added to this draft, or if a separate document was needed. > > Ron stated that the encapsulation was general enough to support a > pure MPLS mode (without UDP/IP or Ethernet). > Shahram said that he preferred to avoid this, as it would require > further IEEE and IETF work. > Ron said that the IEEE already granted authority to the IETF to > devise such an encapsulation. > Yaakov said that only a simple PWE3 draft would be needed to define > a new PW type. > It was decided that this needed to be discussed further. > > Ron and Yaakov raised the point of UDP checksum correction > (FCS correction for retention mode is mentioned in the draft, but > not UDP checksum). > Shahram asked if checksum is mandatory. > Yaakov replied that it is optional in IPv4, but mandatory in IPv6. > Shahram asked whether the checksum could be corrected rather than > recalculated. > Yaakov said yes. > Shahram said that since the UDP mode over IPv6 is supported by the > available chipsets, > apparently they already do the correction. > > Ron asked how the OAM packets that are carried in the same tunnel > are identified. > Yaakov asked if it is always in a VCCV channel. > Shahram said that for the Ethernet PW approach it was VCCV (either > BFD or LSP ping) > while for the UDP/IP it was via UDP port number. > Ron asked for clear text to be added, so that later on new packet > types could be added. > > Karen said that we want to advance this draft to WG draft before the > next meeting. > We don't need to finalize all the open items first. > Shahram and Manav reiterated that this draft has been a long time inmaturing, > and that its handling should be expedited. > > At this point there were only 5 minutes left, and there was no time > to start a new topic. > > Karen announced that the next conference call would be the third > Tuesday in Feb (Feb 15th). > Stefano said that this would fall during the ITU-T meeting. > Yaakov said that this could still work if interested Q13 > participants joined after the sessions. > Stefano said that this would require the call being 1 hour later > (18:00 Geneva time), > and only if there were no late joint meetings planned. > > Action items : > 1) Yaakov will send a mail to the list with an explanation of what > was needed for NTP > 2) Shahram and Manav will respin the draft as a WG draft as soon as > permission is given. > 3) Needed changes: > a) fix wording on mandatory nature of 1588 support > b) add IS-IS text, or at least a place-holder for such text > c) add LDP-4447 text, or at least a place holder for such text > d) fix up the IANA considerations section > e) add text regarding per-port support, or an editor's note that > this needs to be covered > f) add text on UDP checksum correction > g) add text explaining how OAM packets are separated from PTP > ones (ASCII art? pseudocode?) > h) fixes mentioned on list (border clock, transparent clocking, ...) > 4) Stefano will check whether Feb 15th at 18:00 Geneva time is suitable. > 5) Karen will set up another meeting accordingly. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://www.ietf.org/mail- > archive/web/tictoc/attachments/20110118/9893cfab/attachment.htm> > > ------------------------------ > > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc > > > End of TICTOC Digest, Vol 50, Issue 28 > ************************************** > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
