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

[Yaakov Stein <[e-mail]>]

Kam, 

I snipped out your questions and answer them below.

Y(J)S



>> 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.

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.

>> 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.

> 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?

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.

>> Ron stressed the importance of this feature.

> Would love to know why.

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

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

> Is this by using the EXP bits?

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

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

> 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.

>> Shahram said that he preferred to avoid this, as it would require further
>> IEEE and IETF work.

> 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.

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).

>> Ron and Yaakov raised the point of UDP checksum correction

> This is only for TC right?

Right.