Subject: [TICTOC] minutes of TICTOC conference call - Jan 18, 2011

From: Yaakov Stein <[email-masked]>
Date: Tue, 18 Jan 2011 17:44:34 +0000

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 in maturing,
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.

---

From: "Hing-Kam (Kam) Lam" <[email-masked]>
Date: Wed, 19 Jan 2011 05:28:44 +0530

Hi Yaakov,

Thanks for the minutes.

I have a few questions.

> Shahram said that LDP of the PWE3 control protocol needed to be added due to
> the possibility of PHP'ing the tunnel label.

I did not understand this point.

> port capabilities description.

I would like to understand the utility of such a description. Either
the box is capable of doing TC correction, or it cant. I dont believe
this capability is required per port. Would appreciate if someone can
explain us why?

> Ron stressed the importance of this feature.

Would love to know why.

> Yaakov said that prioritization (e.g., EF) could indeed be covered in a BCP

Is this by using the EXP bits?

> but if BC was required for PTP or NTP, then the techniques defined here were

You would also require this draft if you did TC.

> Shahram said that he preferred to avoid this, as it would require further

Isnt the draft already supporting all encapsulations? In Fig 2 UDP, IP
are all optional. I assumed that it meant that we support all
encapsulations. Also the fact that RSVP was signalling the start of
the PTP packet (which is neat!) indicated that we support everything.
I seem to be missing something here.

> Ron and Yaakov raised the point of UDP checksum correction

This is only for TC right?

> We don't need to finalize all the open items first.

I agree.

Kam

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 19 Jan 2011 17:37:13 +0000

Kam, 

I snipped out your questions and answer them below.

Y(J)S

> I did not understand this point.

If the tunnel label is PHP'ed, then the packet arrives with only a PW label.
We now have to know if this label indicates a timing flow.

> this capability is required per port. Would appreciate if someone can

Why do you think that a box must be capable of handling timing packets
on every port ?  Frequently ports are on modules that can be inserted,
and if only a small fraction of the network needs timing support,
there is little reason to upgrade all the modules.

However, I'll let Ron argue this point.

> Would love to know why.

Explained above. As far as I see, it is simpley a matter of economics.

> Is this by using the EXP bits?

Yes, for E-LSPs. But it could be by label.

> You would also require this draft if you did TC.

That is what "still" means.  You ALWAYS need this draft (or something else)
for TC, but you would still need it for BC, and may need it for prioritization.

> I seem to be missing something here.

Look carefully. There is a figure for UDP/IP , and one for a PW
with either pure Ethernet or UDP/IP over Ethernet.
There is no pure MPLS (without either Ethernet or IP).

> This is only for TC right?

Right.