Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

["Ogaki, Kenichi" <[e-mail]>]

Hi Pavan,

Thanks for your prompt reply.

I understood.

>The solution architecture leaves room for an implementation to overload the NRP-ID and use it as a FAS – but that is strictly an implementation choice.

For the purpose to simplify the management as I wrote, the draft should describe this implementation examples/scenarios/options, but it's not restricted. 

Thanks,
Kenichi

-----Original Message-----
From: Vishnu Pavan Beeram <[e-mail]> 
Sent: Friday, February 25, 2022 12:04 AM
To: 大垣 健一 <[e-mail]>
Cc: Lou Berger <[e-mail]>; TEAS WG <[e-mail]>; TEAS WG Chairs <[e-mail]>; [e-mail]
Subject: ***フリーメール*** Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Kenichi, Hi!

 

Thanks for the review! This draft discusses the use of Network Resource Partition (NRP) to support a Slice-Flow Aggregate. The NRP identifier is unique within an NRP domain and is meant for use in the control/management plane to identify the resources associated with the NRP (this should be the identifier used in any relevant control-plane protocol extensions). 

 

The NRP-ID is not the same as Flow-Aggregate Selector (FAS). The FAS is quite simply the marking in the data plane packet that identifies a Slice-Flow Aggregate. The same Slice-Flow Aggregate may be identified by multiple Flow-Aggregate Selectors (see the example in Section 5.1.1 where a range of VPN service labels – each acting as a FAS – select the same Slice-Flow Aggregate). The solution architecture leaves room for an implementation to overload the NRP-ID and use it as a FAS – but that is strictly an implementation choice.

 

And yes, we do expect all other related work to eventually align and adhere to what is specified in this document.

 

Regards,

-Pavan (as co-author)


On Thu, Feb 24, 2022 at 3:14 AM Ogaki, Kenichi <[e-mail] <mailto:[e-mail]> > wrote:


	Hi Authors,
	
	I'd just like to clarify.
	Comparing Fig. 5 in draft-ietf-teas-ietf-network-slices-05 with Fig. 1 in this draft, I understand that this draft also describes one of solutions realizing Network Resource Partition(NRP).
	If my understanding is correct, NRP-ID is essentially same as FASL and "Slice Aggregate ID" described at Fig.5 in draft-bestbar-lsr-slice-aware-te-00.
	From an operational perspective, it's burden to manage many slice related components and the mappings of these components, e.g. connectivity matrix <-> IETF network slice <-> Slice-flow Aggregate <-> FAS <-> NRP.
	Do authors have any thought to at least unify these identifiers in a series of bestbar drafts. Or, is there any reason not able to unify these?
	
	Thanks,
	Kenichi
	-----Original Message-----
	From: Teas <[e-mail] <mailto:[e-mail]> > On Behalf Of Lou Berger
	Sent: Friday, February 18, 2022 10:28 PM
	To: TEAS WG <[e-mail] <mailto:[e-mail]> >
	Cc: TEAS WG Chairs <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
	Subject: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
	
	Hello,
	
	This email begins a 2-week adoption poll for:
	https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/
	
	Please note that IPR has been disclosed on this document:
	https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas-ns-packet
	
	Please voice your support or objections to adoption on the list by the end of the day (any time zone) March 4.
	
	Thank you,
	Lou (as Co-chair)
	
	_______________________________________________
	Teas mailing list
	[e-mail] <mailto:[e-mail]> 
	https://www.ietf.org/mailman/listinfo/teas
	_______________________________________________
	Teas mailing list
	[e-mail] <mailto:[e-mail]> 
	https://www.ietf.org/mailman/listinfo/teas