Re: [DMM] Copying Traffic in FPC

[Marco Liebsch]

You think about something like flow sampling, correct? From FPC protocol point 
of view, I don’t see
issues with adding such properties. AFAIK there is even some support from data 
plane nodes, so
enforcement of these properties should work.

Now, I understand you’re requesting control on which traffic should be probed. 
In that case a
new property should be added. The associated attribute should then also 
indicate how often
packets should be probed (Every 1min, ever 1000th packet, whatever).
Since the forwarding of the copy packet is different than for the actual data 
packet, the
probe property should also indicate a destination, where the copy should be 
sent to.
That’s the protocol part and it should be feasible if wanted.

Is it the C-Plane function that is aware of policies for packet probes? To 
exploit such extension,
it should be, otherwise the probe configuration may be accomplished via a 
different interface.

Thanks,
Marco



From: Lyle Bertz [mailto:lyleb551...@gmail.com]
Sent: Dienstag, 6. Oktober 2015 17:38
To: draft-ietf-dmm-fpc-c...@ietf.org; dmm@ietf.org
Subject: Copying Traffic in FPC

When looking at the latest draft I was curious about how copying for the 
purpose of troubleshooting / probes would be supported?

My thought would be some sort of property on a port that copies the traffic and 
notes the PRT that it could be forwarded to.

Could we support this use case (I am not married to the suggestion above) in 
the specification given its importance to trouble management?   This is easy 
enough to support in underlying DPN technologies such as SDN and I see no 
reason to not specify it in FPC and avoid using yet another protocol for 
forwarding.

Comments / Thoughts would be appreciated on this matter.

Thank you.

Lyle
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] New Version Notification for draft-jhlee-dmm-dnpp-00.txt

[Jouni]

I would love to see the security considerations for this proposal and more 
discussion on the reliability of this method. Also what happens if the access 
router cannot add filters for the “deprecated network prefix” i.e. the prefix 
does not belong to the new link from routing point of view?

- Jouni


> On 08 Oct 2015, at 09:53, Jong-Hyouk Lee  wrote:
> 
> Hello,
> 
> For the mobile node moved from a previous network to a new network, the 
> access router (having a forwarding function) at the new network may need to 
> obtain the previous network prefix information (i.e., deprecated network 
> prefix information at the new network) of the mobile node for data packet 
> forwarding of the mobile node. The draft introduces new extensions to router 
> advertisement (RA) and router solicitation (RS) messages.  The extension to 
> RS messages is used by the mobile node to provide the previous network prefix 
> information to an access router. The extension to RA messages is used by the 
> access router to request the previous network prefix information in a RS 
> message.
> 
> Comments on the draft “deprecated network prefix provision" are welcome.
> 
> J.
> --
> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
> Protocol Engineering Lab., Sangmyung University
> 
> #email: jonghy...@gmail.com
> #webpage: https://sites.google.com/site/hurryon
> 
>> Begin forwarded message:
>> 
>> From: internet-dra...@ietf.org
>> Subject: New Version Notification for draft-jhlee-dmm-dnpp-00.txt
>> Date: October 9, 2015 at 1:19:25 AM GMT+9
>> To: "Jong-Hyouk Lee" , "Zhiwei Yan" 
>> , "Jong-Hyouk Lee" , "Zhiwei Yan" 
>> 
>> 
>> 
>> A new version of I-D, draft-jhlee-dmm-dnpp-00.txt
>> has been successfully submitted by Jong-Hyouk Lee and posted to the
>> IETF repository.
>> 
>> Name:draft-jhlee-dmm-dnpp
>> Revision:00
>> Title:   Deprecated Network Prefix Provision
>> Document date:   2015-10-08
>> Group:   Individual Submission
>> Pages:   5
>> URL:
>> https://www.ietf.org/internet-drafts/draft-jhlee-dmm-dnpp-00.txt
>> Status: https://datatracker.ietf.org/doc/draft-jhlee-dmm-dnpp/
>> Htmlized:   https://tools.ietf.org/html/draft-jhlee-dmm-dnpp-00
>> 
>> 
>> Abstract:
>>   This document introduces new extensions to router advertisement and
>>   router solicitation messages.  The extensions are used to provide a
>>   mobile node's deprecated network prefix information to an access
>>   router.  This document updates [RFC4861].
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
>> 
>> 
>> 
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm