Re: [Detnet] Rtgdir last call review of draft-ietf-detnet-mpls-04

[Balázs Varga A <[e-mail]>]

Hi Carlos/Stewart,
Thanks for the comments/nits and starting to sort them out.
We have started to work on the received comment.
I will be back with a follow-up on these and the rest items as well.  
Many thanks & Cheers
Bala'zs

-----Original Message-----
From: Carlos Pignataro (cpignata) <[e-mail]> 
Sent: Tuesday, December 24, 2019 10:16 PM
To: Stewart Bryant <[e-mail]>
Cc: Routing Directorate <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Rtgdir last call review of draft-ietf-detnet-mpls-04

Hi, Stewart,

> 2019/12/24 午前9:26、Stewart Bryant <[e-mail]>のメール:
> 
> 
> 
>> On 24 Dec 2019, at 00:03, Carlos Pignataro via Datatracker <[e-mail]> wrote:
>> 
>> 
>> 3.1.  Layers of DetNet Data Plane
>> 
>>   The DetNet control word (d-CW)
>>   conforms to the Generic PW MPLS Control Word (PWMCW) defined in
>>   [RFC4385].
>> 
>> Yes, but why not the Preferred CW?
>> 
> 
> Hi Carlos
> 
> Thanks for the review.

Anytime!

> Just picking up a couple of points at this stage,

Sure, happy to follow-up on the rest at a later time.

> 
> The PCW only supports a 16bit sequence number and it has the skip zero auto-signalling of active S/N feature.
> 
> This was a problem for DetNet because:
> 
> - We were worried about S/N rollover frequency in some applications and so we wanted the option of a larger S/N.
> 
> - We wanted to have the option to propagate the S/N from the payload to the transport to simplify the implementation in some cases. These applications have a non-skip zero S/N. Skip zero is an irritation to implement and we should probably have signalled in in PWs.
> 
> As you note in is only a preferred design for PWs, DetNet is not 
> constrained by that and there were good reasons to adopt this 
> alternate approach,
> 
> 

My main point is that, all that you say above, is not in the draft. The spec seems underspecified — including what’s in-order, out-of-order, which specific application layer (or some higher layer) sequencing schemes might map to, etc.

> 
>> 4.1.  DetNet Over MPLS Encapsulation Components
>> 
>>   The LSP used to forward the DetNet packet may be of any type (MPLS-
>>   LDP, MPLS-TE, MPLS-TP [RFC5921], or MPLS-SR
>>   [I-D.ietf-spring-segment-routing-mpls]).
>> 
>> I am not sure of the value of this statement for an "MPLS Dataplane" document.
>> Further, are these "LSP Types" and if so where are the different 
>> types ennumerated? Does this mean that static binding LSPs and BGP 
>> signaled cannto be used? T-LDP does not work? "SDN Assigned"? I 
>> recommend removing this, since it can confuse and does not add much.
> 
> I think it just needs a “for example” and I think that it needs to be made clear that the design is not restricted to a single method of establishing an LSP nor to the characteristics and constraints that go with those LSPs.

It would be a good start to made that clear and qualify the list. Still, what are “LSP Types”? Does it really add to ennumerate some and not others, even if “for-example”ing it?

> 
>> 
>> 4.3.  OAM Indication
>> 
>> It is important to have the OAM Indication, but what type of OAM 
>> packets can run on top of this AcH? I found it interesting that for 
>> example there is not reference or citation to RFC 8029.
>> 
> 
> Work has started on OAM, for example draft-mirsky-detnet-mpls-oam-00
> 
> The OAM for DetNet will be more complex than the OAM for a classical P2P or P2MP LSP (or PW) because of the PREOF function. There is nothing in the data plane that precludes us using on of the existing OAM indicators (GAL or 0001 ACH), but I think that it is important to thing through the subtleties. Thus I think it is OK to make progress on the elements of the data plane that we can nail down, and leave. The OAM as follow-up work.
> 

I believe being explicit rather than implicit about scoping things out adds to clarity.

Do you expect an equal number of DetNet documents concerning themselves with OAM, as there are dataplane docs?

> 
>> 
>> 
>> Also, outdated reference: draft-ietf-spring-segment-routing-mpls has 
>> been published as RFC 8660
> 
> This will get picked up on the next resin as part of the Nits check.
> 

Thanks!

Happy Holidays :-)

Carlos.

> Best regards
> 
> Stewart